김대웅 플래티어 IDT부문 책임
3) 다양한 타입의 시크릿 관리
보안이 필요한 모든 데이터를 시크릿이라고 할 수 있다. 데이터는 키와 값만 가지는 단순한 정보일 수도 있지만, SSH 혹은 AWS IAM 사용자와 같은 임시 자격 증명이거나 TLS 인증서, 대용량 파일일 경우도 있어 시크릿의 특성에 맞는 관리가 필요하다.
예를 들어 키-값 시크릿은 단순히 스토리지에 저장 후 사용이 끝나더라도 값을 바꿔 계속해서 갱신하여 사용하는 경우가 대부분이지만 TLS 인증서, SSH 임시 자격증명, 시스템이 사용하는 IAM User나 IAM Role 과 같은 자격증명들도 클라우드 환경에서 관리되어야 하는 시크릿의 한 종류로 생각할 수 있다.
특히 이러한 자격증명 시크릿을 시스템에서 사용하는 경우라면, 외부 시스템이 응용 프로그램에 접속을 시도할 때 보안/시스템 관리자가 미리 설정해 놓은 권한을 부여한 임시 자격 증명을 자동으로 발급해주고, 설정된 TTL 시간이 지나거나 관리자가 지정한 오퍼레이션 수를 넘어가면 명시적으로 자격증명을 갱신하지 않는 이상 삭제할 수 있도록 하는 것이 좋다.
Vault에서는 이렇듯 TTL 이 필요한 시크릿을 ‘동적 시크릿’으로 구분하고 있으며, 동적 시크릿을 발급하는 엔진 중 하나로 데이터베이스 시크릿 엔진이 있다. 이 엔진은 외부 응용 프로그램이 데이터 베이스에 접속을 시도하면 보안/시스템 관리자가 미리 설정해 놓은 권한을 부여한 임시 자격 증명을 발급해준다.
이때 발급된 임시 자격증명은 설정된 TTL 시간이 지나거나 관리자가 지정한 오퍼레이션 수를 넘어가면 명시적으로 자격증명을 갱신(Renew) 하지 않는 이상 삭제되므로, 관리자가 신경 쓰지 않아도 되기 때문에 동적 시크릿을 효율적으로 관리할 수 있게 한다.
4) 시크릿을 중앙 집중형으로 관리
시크릿 관리 도구를 중앙 집중형으로 사용하기 위해서는 반드시 앞서 언급한 1,2,3 번 조건을 만족해야 한다. 추가로 시크릿 관리 도구는 굉장히 많은 클라이언트의 요청을 처리해야 하거나 관리해야 할 시크릿의 양이 드라마틱하게 많아질 수 있기 때문에 반드시 고가용성 및 멀티 리전에서의 다중 클러스터 운영 및 재해복구 능력을 보유해야 한다.
5) EaaS를 통한 암호화 관리
암호화가 필요한 데이터의 사이즈가 큰 경우 (전체 디스크 암호화, 데이터베이스 암호화 또는 파일 암호화 등), 암호화된 정보를 운영중인 시크릿 관리 도구가 아닌 시스템에 저장하고, 필요시 복호화 하는 것이 더 합당하다. 아울러 이 경우에는 아래와 같이 응용 프로그램 내부에 암호화 키를 관리하여 데이터를 암호화 및 복호화 하는데 사용할 수 있다.
EaaS(Encryption as a Service)는 단순히 암호화 및 복호화 기능을 서비스로써 제공받아 응용 프로그램에서 직접 암호화를 수행하지 않고도 암호화 기능을 활용할 수 있도록 도와준다. 이 접근 방식은 암호화를 자체적으로 관리할 리소스가 부족한 고객에게 멀티 클라우드 환경에서 데이터를 보호할 수 있는 방법을 알려준다. 보통 이런 서비스를 제공하는 도구는 암호화 키 로테이션 기능이나 여러 암호화 방식을 지원하기 때문에 레거시 응용 프로그램에 대해 보다 용이하게 효율적인 암호화 적용을 할 수 있다.
뿐만 아니라, 단순히 키를 통한 암호화 및 복호화 기능을 수행해주기 때문에 Vault는 스토리지에 어떤 데이터도 저장하지 않게 되며 아래의 워크플로우를 가지게 된다.
<암호화>
1. 외부 프로그램이 암호화 서비스에 API를 통해 암호화가 필요한 데이터를 전달
2. 암호화 서비스가 해당 정보를 암호화
3. 암호화 서비스가 암호화된 정보를 외부 프로그램에 전달
4. 외부 프로그램이 암호화된 정보를 DB에 저장
<복호화>
1. 외부 프로그램 DB에서 암호화된 데이터를 쿼리
2. 암호화된 데이터를 API를 통해 암호화 서비스에 전송
3. 암호화 서비스는 관리 중인 키를 사용하여 데이터를 복호화 한 후 외부 프로그램에 전송
이와 같이 외부 프로그램은 암호화 키에 직접 액세스 할 수 없으며, 단순히 암호화 서비스에 암호화 및 복호화 요청만 수행하게 된다.
4. 감사 로깅(Audit Logging)
응용 프로그램 접근 관련 보안 문제를 탐지하고 대응하기 위한 ‘감사’ 부분도 이어서 살펴보도록 하자.
멀티 클라우드 환경은 다수의 클라우드 사용자들에게 자원을 제공하기 위해 물리적인 자원을 논리적으로 분할하고 격리하는 멀티테넌시 multitenancy14 환경으로, 공유 문제 발생 가능성이 크고 자원의 공유를 위해 여러 사용자가 쉽게 접근 가능하므로 이용 중인 시크릿에 대한 액세스 정보를 기록하고 추적해야 한다. 이를 잘 활용하면 액세스 로그들을 분석하여 위협을 사전에 예측하거나 감사 로깅을 통해 허가되지 않은 활동을 감지할 뿐만 아니라, 보안 조치를 자동화하여 지속적으로 활용할 수 있다.
클라우드 제공자는 보통 이런 기능을 위해 여러 가지 서비스를 제공해주는데, 대표적으로 AWS CloudTrail15 은 AWS API 요청의 처리내역을 로깅할 수 있으며, 이때 AWS Secret Manager 와 KMS 서비스에 대한 액세스 로깅을 필터링하여 사용할 수 있고, Amazon Detective 서비스는 보안사고 원인을 분석 및 조사 규명하는 서비스로 이용되고 있다.
또한 Amazon GuardDuty16 는 관리형 위협 탐지 및 통지 서비스로, AWS CloudTrail 로그에 대해 에이전트 없이 머신 러닝을 기반으로 이상행동을 탐지할 수 있다.
또 다른 예로 Vault에 발생한 모든 요청 및 응답에 대한 자세한 로그를 보관하는 감사 로깅 기능을 사용하면, 오류를 포함하여 인증 방식, 인증된 사용자가 한 요청, 그리고 요청을 어떻게 처리했는지에 대한 정보를 저장하고 이 중 민감한 정보는 암호화하여 저장된다.
결국 클라우드 상에서 운영되는 응용 프로그램은 위와 같은 서비스나 도구를 API로 연계하여 사용함으로써 민감한 정보에 대한 접근을 지속적으로 기록하고, 모니터링 시스템과 연계하여 문제가 발생하면 이를 자동으로 감지한 후 해결할 수 있도록 설계해야 한다.
마치며
클라우드 인프라는 여러 클라우드에 걸쳐 신뢰도가 낮고 네트워크 경계선이 명확하지 않은 환경에서 정적으로 정의된 기존 호스트 기반 ID가 애플리케이션 기반 ID로 전환되는 것을 의미한다. 전통적인 보안 세계에서 우리는 네트워크가 본질적으로 높은 신뢰라고 가정했고, 외부 방어를 최대한 수행하고 내부에서는 보안에 많은 신경을 쓰지 않아도 되었다. 이런 상황이 클라우드 시대가 본격화되면서 ‘제로 트러스트’ 네트워크 접근법으로 바뀌었고 이제 우리는 내부에서도 보안을 구축해야 하는 시대가 되었다.
이와 관련하여 미국 클라우드 보안 연합은 클라우드 상의 보안을 위해 공통적으로 필요한 사항을 정리하여 ‘서비스로서의 보안’ 형태로 해결할 것을 권고하고 있으며, 관련하여 보안 서비스 모델을 제공하고 있다. 이에 따라 클라우드에서 운영되는 응용 프로그램은 이 보안 서비스 표준에 위배되지 않도록 설계되어야 한다.
이를 위해 클라우드 환경에서 운영되는 응용프로그램은 최소한 ‘자산 식별’과 ‘사용자별 접근 제어’, ‘시크릿에 대한 데이터 보호’ 및 ‘보안 감사’ 부분을 고려하여 설계되어야 하며, 이는 응용 프로그램 내에서 사용자를 인증하고 적절한 권한을 부여하며 철저한 감사를 받는 동시에, 발생하는 각종 민감한 데이터를 보호해야 함을 의미한다.
결국 이런 과제들로 인해 조직이 클라우드로 전환하는 과정에서 마이그레이션 진행에 상당한 진통을 겪을 것으로 예상된다. 클라우드 보안은 클라우드 컴퓨팅 서비스 채택의 주요 저해 요소로 남아 있지만, 반드시 표준 준수를 통해 응용 프로그램에 대한 보안 이슈를 해결해야 하며, 클라우드 보안 서비스 혹은 시크릿 관리 도구와의 연계를 통해 처리하는 것을 권장한다.
소셜댓글