LINE DEVELOPER DAY 2020에서 유휘재 님과 노승헌 님이 발표하신 Manage SSL certificates with secure, reliable system 세션 내용을 옮긴 글입니다.

안녕하세요. Infra Protection 팀에서 컨테이너 보안 기술과 인증서 관리 업무를 담당하고 있는 유휘재입니다. 이번 글에서는 LINE에서 인증서를 관리하는 방법과 시스템, 그리고 기술적인 배경에 대해서 소개하려고 합니다. 

인증서는 어렵고 복잡해서 인증서를 적용하려고 하면 ‘사이퍼 스위트(cipher suite)는 뭐지? 설정은 인터넷에서 검색해서 가져다 쓰면 되나?’와 같은 의문이 생깁니다. 기술은 빠르게 발전해서 배울 것도 많고 신경 쓸 것도 많은데 거기에 보안까지 신경 써야 하죠. 이런 상황에서 인증서를 왜 관리해야 되는지, 이 인증서를 관리하는 방법이 어떻게 변화해왔는지, 이렇게 어렵고 복잡한 인증서를 관리하면서 발생하는 문제를 어떻게 해결해 나가고 있는지 이야기해보겠습니다.

SSL 인증서 사용과 관리

HTTPS는 웹 통신 구간의 표준 프로토콜입니다. 우리는 HTTPS를 구현하기 위해서 SSL(Secure Sockets Layer) 혹은 TLS(Transport Layer Security) 인증서라고 부르는 것을 사용합니다. 그런데 왜 인증서를 사용하고 어디에 쓰는 걸까요? 또한 이것을 잘 관리하는 것은 왜 중요할까요?

SSL 인증서의 역할

SSL 인증서를 이용해서 HTTPS를 제공하는 것에는 크게 두 가지 목적이 있습니다. 하나는 인증서를 통해서 사용자가 연결하는 서버가 정확한 서버임을 증명하는 것이고 또 다른 하나는 그 서버와 주고받는 정보를 암호화해서 안전하게 주고받는 것입니다.

웹 브라우저라고 부르는 사용자 에이전트는 서버와 SSL 인증서 간의 통신 구간을 암호화합니다. 이때 사용하는 게 SSL 인증서인데요. 인증서는 어떻게 만드는 걸까요?

LINE과 같은 서비스 제공 사업자는 발급에 필요한 정보를 생성해서 인증서 발급 기간인 CA(Certificate Authority)로 전달합니다. CA는 루트 인증서의 개인 키로 인증서를 생성해서 암호화합니다. 이렇게 인증서를 생성해서 유효 기간을 검증하기 위해 루트 인증서를 활용하는 과정을 사이닝(signing)이라고 합니다. 공개 키와 개인 키 등이 포함된 인증서 패키지는 서버에 설치해 HTTPS 통신에 활용합니다. 사용자가 서버에 접근하면 서버의 인증서에 포함된 공개 키를 사용자에게 전달합니다. 양쪽에서 서로 다른 키를 사용해 통신하기 때문에 비대칭 암호화 통신이라고 부릅니다. 웹 브라우저는 다양한 CA 인증서를 신뢰할 수 있는 인증서에 저장합니다. 이 CA 인증서에 포함된 공개 키를 이용해 서버 인증서를 검증해서 서버가 신뢰할 수 있는 서버인지를 확인합니다. OCSP(Online Certificate Status Protocol)를 통해서 거절된 인증서를 확인해서 실제 서비스를 제공하고 있는 서버에 연결한 것인지를 확인합니다. 서버에서 전달받은 서버 인증에 포함된 공개 키를 이용해서 비밀 키를 생성하고 이를 다시 서버에 전달해서 웹 브라우저와 서버는 공유한 비밀 키를 이용해 사용자와 서버 간 통신 구간의 암호화라는 목적을 달성할 수 있습니다.

SSL 인증서 사용 과정에서 발생할 수 있는 보안 위협

이런 과정이 문제없이 동작한다면 보안 담당자로서 정말 행복한 일일 겁니다. 하지만 현실은 그렇지 않습니다. 아주 가끔이지만 인증서를 발급하는 CA의 개인 키가 유출되는 사고가 발생하기도 합니다. 실제로 2011년 7월에 DigiNotar라는 인증 기관이 보안 침해 사고를 당했습니다.

이 사고로 다량의 가짜 인증서가 발급됐고 수십만 명이 피해를 봤습니다. 많은 브라우저에서 이 인증서를 신뢰할 수 없는 인증서로 등록했고 수많은 기업들이 인증서를 교체해야만 했으며 결국에는 인증 기관이 파산하는 사태까지 벌어졌습니다.

서버의 개인 키 유출 또한 큰 보안 사고로 이어집니다. PKI(Public Key Infrastructure)는 공개 키와 개인 키를 이용해서 암호화와 복구화를 하는데요. 만약 서버에서 개인 키가 유출되면 크래커들이 이 키를 이용해 사용자들을 기만할 수 있습니다. 

이처럼 SSL 인증서를 사용하는 과정에서 발생할 수 있는 여러 가지 보안 위협들이 있고 이런 사고를 막기 위해서 보안 수준이 높은 프로토콜과 사이퍼 스위트를 사용하고 서버의 개인 키를 안전하게 보관하는 등의 노력을 기울여야 합니다.

SSL 인증서 기술과 표준의 변화

SSL 인증서의 기술과 표준은 계속 진화하며 변화하고 있습니다. 

2020년에 가장 많이 회자되었던 이야기 중 하나는 인증서 유효 기간 단축에 대한 이야기입니다. 요약하면 발급된 모든 인증서는 1년 이상의 유효 기간을 갖지 않아야 한다는 이야기인데요. Apple과 Google 등 주요 기업들에서는 이미 이 정책을 적용하고 있습니다. 인증서를 무료로 사용할 수 없을까라는 요구도 많았는데요. 이 질문에 많은 분들이 Let's Encrypt를 언급합니다. 자동화가 잘 돼있고 업계 표준의 보안 수준을 제공하고 있기 때문에 매일 200만 건 이상의 신청이 몰리며 사용량이 급증하고 있습니다. 마지막으로 보안과 성능은 반비례라는 인식이 허물어지고 있습니다. 0-RTT(Zero Round Trip Time)로 알려진 TLS 1.3의 성능 개선은 적극적인 ECDSA(Elliptic Curve Digital Signature Algorithm)의 사용과 더불어 보안과 성능, 두 가지를 해결할 수 있는 좋은 솔루션이 되고 있습니다. 

변화에 대응하는 LINE

LINE은 SSL 인증서와 관련된 기술의 지속적인 변화를 연구하며 시장의 흐름에 맞춰 LINE 인프라에 적극적으로 활용할 수 있는 방법을 찾고 개선해 나가고 있습니다. LINE에서 사용하고 있는 서버의 수는 메신저의 지속적인 성장과 다양한 신규 서비스 출시가 맞물려 매년 크게 증가하고 있습니다. 2020년 7월 기점으로 물리 서버는 5만 대, 가상 서버는 6만 7천 대 이상을 가동하고 있으며 숫자는 계속 증가하고 있는데요. 증가하는 서버만큼 SSL 인증서 수요 또한 증가하고 있고 이에 따라 관리도 점점 복잡해지고 있습니다. 

인증서는 회사가 제공하는 서비스가 사용자와 만나는 최전선에 있습니다. LINE의 인증서 관리 시스템인 VOYAGER는 개발자가 인증서에 쉽게 접근할 수 있는 채널이자 인증서 안전 관리 체계입니다. 인증서와 관련된 사고가 발생했을 때 그 영향 범위를 빠르게 확인하고 피해를 최소화할 수 있는 방법을 제공하는 시스템입니다. 

VOYAGER

안녕하세요. 서비스 엔지니어링 팀에서 트래픽 업무를 담당하고 있는 노승헌입니다. 앞서 유휘재 님과 함께 SSL 인증을 둘러싼 기술 환경과 현실, 도전 과제들을 살펴봤습니다. VOYAGER는 이런 숙제를 풀기 위해 밑바닥에서부터 필요한 것들을 만들어 나가고 있는 시스템입니다. LINE의 개발자들에게 인증서는 VOYAGER라는 인식을 심어주기 위해 무엇을 바꾸고 무엇을 얻었는지 살펴보겠습니다.

기존 인증서 신청 과정의 문제점

트래픽 관련 업무를 하다 보면 개발 부서와 함께 SSL 인증서를 사용하는 일이 무척 잦습니다. 그런데 인증서 신청과 관련된 문서가 파편화돼 있으며 가이드 또한 제대로 현행화되어 있지 않아 개발 부서에서 인증서를 사용할 때 많은 어려움을 겪고 있었습니다. 또한 절차가 복잡하고 번거롭다 보니 동료에게 인증서를 전달받아 사용하는 일도 빈번하게 발생했습니다.

VOYAGER의 첫 번째 숙제는 복잡한 인증서 접근 권한 획득 절차를 개선하는 것이었습니다. 결재 시스템인 '워크플로'와 문서 관리 시스템인 '위키'라는 두 시스템으로 나뉘어 있는 기존의 프로세스를 어떻게 단일 UI로 바꿀 수 있을지가 저희의 고민이었습니다.

신청자들은 워크플로를 통해서 인증서를 신청하면서 사내에 어떤 인증서가 있는지 파악하기 힘들었습니다. 담당자들은 워크플로를 통해 신청된 정보를 검증하는 것이 쉽지 않았습니다. 이 때문에 별도로 의사소통 채널을 만들어야 했고 이 채널에서 서로 이야기를 주고받는 동안 인증서 발급이 지연되는 문제가 있었습니다.

워크플로를 승인받고 나서는 위키 권한을 획득해야 합니다. 워크플로와 위키가 서로 다른 시스템이었기 때문에 위키 접근 권한을 획득하려면 사람의 손이 필요했습니다. 그 과정에서 종종 위키 권한 설정 오류가 발생해 인증서를 사용하는 데 걸림돌이 되었습니다. 위키에 접근할 수 있게 되면 사용자는 위키에 등록된 인증서 파일을 다운로드합니다. 이때 인증서는 처음 생성할 때 설정된 비밀번호로 암호화된 동일한 파일을 사용했습니다. 어떤 사용자가 어떤 인증서를 다운로드했는지 이력을 관리하기 힘들어 보안 관점에서 문제가 되고 있었고, 한 번 부여된 위키 권한은 지속적으로 관리되지 않아 역시 보안 위험 요소가 되었습니다.

상용 솔루션 도입 검토

이런 불편함과 보안 취약점을 해결하기 위해 인증서 관리 시스템을 도입하자는 의견이 대두됐습니다. 이에 저희는 시장에 나와 있는 다양한 상용 솔루션을 검토했습니다. 상용 솔루션들은 많은 기능을 제공하고 있었고 바로 사용해도 문제없을 정도로 높은 완성도를 갖추고 있었지만 과연 이것이 LINE에 가장 적합한 최선의 해결책인가라는 의문이 들었습니다.

먼저 기능 추가나 변경, 확장이 쉬울지 고민됐습니다. 다양한 사내 시스템과 연동해야 하기 때문에 시스템 연동 개발 통합이 원활할지도 고민됐습니다. SSL 인증서의 특성상 긴급하게 진행되는 업무가 무척 많았는데요. 이런 경우에 문제 상황을 우회할 수 있을지 혹은 빠르게 조치할 수 있을지 역시 고민됐습니다. 이런 고민들이 상용 솔루션을 선택할 것인지 아니면 직접 개발할 것인지를 결정하는 중요한 요인이 됐고, 저희는 직접 개발하는 게 LINE에 더 적합하다는 판단을 내렸습니다.

VOYAGER 개발 

VOYAGER는 사내의 LDAP(Lightweight Directory Access Protocol)과 SSL 연동을 시작으로 사용자 중심의 인증서 관리 체계를 구축해 나갔습니다. 워크플로와 위키로 나뉘어 있던 것을 VOYAGER 단일 UI로 통합했습니다. 필요한 정보를 단일 UI를 통해 파악(valuation)할 수 있었고 보안 팀에서 요구한 DNS 점검 절차도 통합해 낼 수 있었습니다.

이후 워크플로 생성을 자동화해 사용자 경험을 개선했습니다. 사용자가 신청한 인증서는 VOYAGER UI의 내 인증서 목록에 등록합니다. 이를 통해 사용자는 권한과 내가 사용하고 있는 인증서 현황을 쉽게 조회할 수 있고 인증서가 만료되거나 갱신 시점이 도래했을 때 대응하기가 무척 쉬워졌습니다.

저희는 사전에 승인을 획득한 검증된 사용자에 한해서만 인증서에 접근할 수 있도록 허용하고 있고 관리자에게는 권한을 보다 쉽게 회수할 수 있는 절차를 제공했습니다. 사용자가 인증서를 다운로드할 때는 동적으로 생성한 일회용 암호를 사용해 보안 수준을 높였습니다. 또한 제한적이기는 하지만 VOYAGER API를 통해 자동화할 수 있는 기능도 제공하기 시작했습니다.

VOYAGER 구축 후 보안 담당자와 관리자는 현행화된 인증서 사용 현황을 확보할 수 있게 되었습니다. 사용자는 불필요한 권한을 반납함으로써 보다 수준 높은 보안이 보장된 상태에서 인증서를 사용할 수 있게 되었고 책임감도 갖게 되었습니다. 워크플로와 위키로 나뉘어 있을 때는 신속하게 인증서를 사용하는 게 무척 어려웠지만 VOYAGER 단일 UI로 통합하면서 사전 검증에서부터 인증서 배포까지 모든 절차가 단순화됐습니다. 이를 통해 사용자 시나리오를 개선할 수 있었고 인증서 사용에 소요되는 시간을 단축할 수 있었습니다.

또한 그동안 인증서 발급 후 해당 인증서를 사용하는 자원을 관리하는 영역이 그레이존이었는데요. 통합 DB를 구축해 서비스와 도메인, 인증서, 사용자까지 일괄 관리할 수 있게 되었고, 이를 통해 인증서 생애 주기를 관리해 갱신 누락과 같은 단순 장애에 보다 적극적으로 대처할 수 있게 되었습니다.

사내 프라이빗 클라우드 플랫폼과 연계

LINE은 Verda라는 내부 클라우드 플랫폼을 사용하고 있습니다. 

Verda가 제공하는 소프트웨어 로드 밸런서는 프락시(proxy) 모드로 사용하면 SSL의 오프로드(offload) 기능을 활용할 수 있습니다. 이런 경우에 로드 밸런서가 사용하는 인증서도 VOYAGER가 관리하게 되어 개발자는 인증서 사용 유무와 관계없이 개발에만 집중할 수 있는 환경을 보장받을 수 있습니다. 그런데 애플리케이션 특성이나 서비스 상황에 따라서 DSR(Direct Server Return) 모드로 로드 밸런서를 사용하는 경우도 있는데요. 이때는 SSL 관리를 서버에서 직접 해야 하기 때문에 서버에 인증서를 설치해야 하고 이는 관리 부담으로 다가옵니다.

VOYAGER는 서버가 이런 관리 부담을 덜어낼 수 있도록 VOYAGER API를 통해 제한적으로 자동화할 수 있는 체계를 제공하고 있으며 추후 VOYAGER 에이전트를 활용해 인증서 업무를 보다 쉽게 관리할 수 있도록 노력을 기울이고 있습니다.

LINE 개발자들은 물리 장비뿐 아니라 가상 장비와 컨테이너 기술도 적극 활용해 서비스를 개발하고 있습니다. 수시로 생성되고 소멸되는 이런 자원들도 SSL 인증서를 사용하기 때문에 쉽게 관리할 수 있는 방법을 제공해야 합니다. VOYAGER는 VOYAGER 스캐너를 이용해 지속적으로 자원을 탐색하며 보안 점검을 수행하고 있습니다.

인증서의 만료 점검과 취약한 사이퍼 스위트 사용 유무 같은 보안 점검뿐 아니라 보안 수준을 정보화하고 수치화할 수 있도록 점수 시스템을 도입해 모니터링을 강화하고 있습니다.

VOYAGER 시스템 자체 보안 강화

위와 같이 인증서 관리 업무가 VOYAGER로 집중되면서 VOYAGER 시스템 자체의 보안도 무척 중요한 요소가 되었습니다. VOYAGER 시스템은 체계적인 보안 구조를 확립하기 위해 제한된 사용자만 접근 가능한 시큐어 존(secure zone) 시스템을 운영하고 있습니다.

인증서는 KMS(Key Management Service)를 이용해 암호화한 상태로 데이터 베이스에 저장하고 있으며 사용자가 요청할 때마다 메모리에서만 복구해 제공하고 있습니다. 또한 권한 관리를 사용자 단위로 진행해 불필요한 정보 노출을 최소화하고 매번 다운로드할 때마다 일회용 비밀번호를 사용하도록 변경했습니다. 저희는 개발 단계에서 인증서가 유출되지 않도록 테스트 CA를 이용한 개발 관리 체계를 도입했으며 이를 통해 VOYAGER 개발 업무를 진행하고 있습니다.

사용자가 직접 개발하고 관리하는 VOYAGER

사용자들이 자주 사용하며 편리하다고 느끼는 유용한 시스템은 어떻게 만들 수 있을까요. 시스템이 제공하는 기능을 직접 사용하고 운영하는 사람들이 만드는 게 바로 유용한 시스템을 만드는 비결이라고 생각합니다. VOYAGER는 인증서를 직접 사용하는 사람들이 모여서 직접 개발하고 운영하고 있습니다. 흔히 SSL 인증서는 보안에 필요한 것이니 보안 팀이 담당할 것이라고 생각하기 쉽습니다. 하지만 VOYAGER는 보안 조직만 참여해서 만드는 시스템이 아닙니다. VOYAGER는 인증서의 발주와 구매를 담당하는 조직과 Verda와 같은 인프라 관련 조직도 포함해서 다양한 조직의 엔지니어들이 참여해서 만들어 나가고 있는 시스템입니다.

처음 기획 단계부터 각기 다른 팀원들로 구성돼 현재까지 인증서라는 공통분모로 다양한 부서의 엔지니어들이 만드는 시스템의 장점은 정말로 필요한 기능을 만든다는 점입니다. 개발 과정에서 역할이 바뀌기도 하는데요. 보안 엔지니어가 UI를 개선한다거나 구매 운영 팀에서 인증서 발급 절차의 개선점을 제시하기도 합니다. 각자의 전문 분야에 맞게 필요한 기능에 대해 조언하고 피드백을 주고받으며 꼭 필요한 기능을 매우 실용적이고 현실적으로 만들며 개선하고 있습니다. VOYAGER 개발 운영 팀은 하나의 팀으로서 서로 다른 기술적 배경과 역할을 맡고 있지만 각자의 전문 영역에서 신뢰를 쌓아가며 국적과 장소를 넘어선 협업을 이어나가고 있습니다.

향후 계획

VOYAGER가 궁극적으로 지향하는 것은 무엇일까요? 바로 사용자에게 스트레스를 주지 않는 보안입니다. SSL 인증서를 개발자들이 관리하고 사용하는 것은 사실 꽤나 까다롭습니다. 1년에 한두 번 정도 하는 작업이다 보니 익숙하지도 않고 행여나 실수할 경우 서비스에 장애가 발생할까 봐 걱정하기도 합니다. 담당하는 서버가 수십 대 혹은 수백 대 규모라면 그런 걱정이 더욱 클 수밖에 없습니다. 이 과정에서 받는 스트레스는 무척 큽니다. 특히 인증서 관련 장애를 겪어본 개발자라면 더욱 그럴 것입니다. 이에 VOYAGER는 모든 과정을 자동화하는 것을 목표로 삼고 있습니다. VOYAGER 에이전트와 같은 자동화 도구를 통해서 사용자들이 겪고 있는 인증서 관리 스트레스를 줄이고, 관리할 때 노출을 최소화해 잠재적인 장애를 줄여나가고 있습니다.

최종적으로 인증서 사용 신청과 구매, 배포까지의 모든 과정을 자동화해서 시간과 비용을 줄이는 동시에 보안 위험과 장애 발생 요소를 제거함으로써 LINE 개발자분들이 스트레스 받지 않고 개발에만 집중할 수 있도록 하는 것이 VOYAGER 팀의 목표입니다.

마치며

LINE의 VOYAGER는 이제 그 여정을 출발했을 뿐입니다. 태양계로 여행을 떠났던 탐사선 VOYAGER처럼 계속해서 미지의 세계를 탐험해 나가는 VOYAGER 시스템을 그려봅니다. 아래에서 발표 영상도 확인하실 수 있습니다. 긴 글 읽어주셔서 감사합니다.