분산 플랫폼 보안 강화 — ID, 비밀 정보 및 키 관리

Ankur Singla

이 글은 당사의 SaaS 서비스를 구축하고 운영하는 데 필요했던 다양한 측면을 다루는 블로그 시리즈의 세 번째 글입니다:

1. 분산형 Kubernetes PaaS를 위한 컨트롤 플레인
2. 분산 애플리케이션을 위한 글로벌 서비스 메시
3. 분산 인프라, 앱 및 데이터를 위한 플랫폼 보안
4. 분산 클러스터의 애플리케이션 및 네트워크 보안
5. 전 세계에 분산된 플랫폼 전반의 관측 가능성
6. 전 세계에 분산된 플랫폼의 운영 및 SRE
7. 분산 마이크로서비스를 위한 Golang 서비스 프레임워크

제가 처음 작성한 블로그 글에서는 분산 클라우드를 위한 새로운 플랫폼을 구축하게 된 배경과 요구 사항을 소개했습니다. 고객들은 이 플랫폼을 활용해 스마트 제조, 공공 안전을 위한 영상 포렌식, 알고리즘 트레이딩, 통신사의 5G 네트워크 등 복잡하고 다양한 애플리케이션을 구축합니다.

이러한 애플리케이션 중 상당수가 미션 크리티컬한 만큼, 고객은 당사가 다계층 보안을 제공할 뿐만 아니라 분산 클러스터를 안전하게 유지하기 위해 지속적으로 개선할 수 있는 역량도 갖추기를 기대합니다. 이 블로그에서는 여러 클러스터에 걸쳐 인프라, 애플리케이션 및 데이터를 보호할 때 직면하는 과제를 다룹니다.

요약

1. 사용자와 직원에게 애플리케이션에 대한 안전한 액세스를 제공하는 방법은 비교적 잘 알려져 있지만(우리는 은행 계좌나 회사 이메일에 접속할 때 매일 이를 수행합니다), 검증 과정에 사람이 관여하지 않는 앱 간 또는 앱과 데이터 간 액세스에 동일한 방식을 적용하는 것은 그리 간단하지 않습니다.
2. 이기종 환경(엣지, 멀티 클라우드 및 네트워크 PoP)에서 앱과 데이터를 보호하려면 다계층 문제를 해결해야 했습니다. — ID, 인증 및 권한 부여, 비밀 정보 및 키 관리
3. 이 네 가지 문제를 해결하기 위한 다양한 개별 솔루션(예: 각 클라우드 제공업체의 여러 서비스, Hashicorp Vault, SPIFFE/Spire 등)이 있지만, 여러 클라우드 제공업체에서 공통으로 작동하거나 사용 편의성을 위해 이러한 서비스를 각각 원활하게 통합하는 솔루션은 존재하지 않습니다.
4. 개발자 및 DevOps 팀에 이러한 요소들을 통합하는 방법에 대한 전문성이 부족했기 때문에, 플랫폼 팀이 이러한 기능을 사용하기 쉬운 통합 솔루션으로 제공하는 것이 필수적이었습니다. 끊임없이 변화하는 보안 환경과 새로운 기술로 인해 이들 팀의 어려움은 더욱 커지고 있습니다. 모든 변화를 따라잡는 데 필요한 전문성과 여력이 부족하기 때문입니다.
5. 다계층 플랫폼 보안을 제공하기 위해, 우리는 세 가지 핵심 문제를 완전히 새로운 방식으로 해결하는 새로운 소프트웨어 구성 요소를 구축했습니다. 즉, ‘끝없이 이어지는 의존성’ 문제 없이 범용 ID를 안전하게 부트스트랩하고, 중앙 볼트의 침해를 걱정할 필요 없이 시크릿을 저장하고 배포하며(금광 문제), 분산형 키 관리를 통해 저장 데이터의 보안을 간소화했습니다.

보안 문제의 배경

앞서 언급했듯이 애플리케이션에 대한 사용자 액세스(예: 은행 계좌나 이메일에 대한 액세스)를 보호하는 문제는 잘 알려져 있습니다. 하지만 앱 간 또는 앱과 데이터 간 액세스의 경우에는 검증 과정에 사람이 관여하지 않기 때문에 동일한 방식으로 보호하기가 그리 간단하지 않습니다.

애플리케이션이 다른 리소스에 안전하게 액세스하려면(예: 객체 스토리지에 저장된 데이터에 액세스하거나 다른 애플리케이션에 API를 호출하는 경우 등) 다음과 같은 과정이 필요합니다:

1. ID — 요청자는 필요한 리소스에 액세스할 때 인증 및 권한 부여에 사용할 수 있는 검증 가능한 ID를 안전하게 획득해야 합니다. 또한 피어의 ID를 검증하는 데 사용할 수 있는 필수 신뢰 앵커를 안전하게 프로비저닝받아야 합니다.
   
2. 인증 — 특정 리소스에 액세스하는 과정에서 요청자와 리소스 소유자는 서로의 신원을 안전하게 확인해야 합니다. 상대방이 주장하는 신원을 제시된 신원 정보와 대조하여 확인하는 과정을 인증이라고 합니다.
   
3. 권한 부여 — 요청자의 인증이 완료된 후 해당 리소스에 대한 접근이 허용되는지 확인하는 과정을 권한 부여라고 합니다.

인증 프로세스의 일부로, 요청 애플리케이션은 PKI 인증서나 비밀 정보(예: 비밀번호) 또는 키의 형태로 자신의 신원을 제시할 수 있습니다. 비밀 정보나 키를 신원 확인에 사용할 때는 다음 두 가지 문제를 해결해야 합니다:

• 비밀 정보와 키를 코드에 직접 저장해서는 안 됩니다. 이는 공격에 쉽게 악용될 수 있으며, 키가 유출되면 심각한 문제가 발생할 수 있기 때문입니다.
• 비밀 정보를 외부 볼트에 저장하는 경우, 비밀 정보를 가져오기 위해 어떤 ID(일반적으로 또 다른 비밀 정보)를 사용해야 하며, 이 ID를 어떻게 안전하게 보호해야 할까요?

이러한 보안 작업(앱 간 상호 작용을 위한 작업)을 안정적이고 반복 가능한 방식으로 수행하는 것은 간단한 문제가 아닙니다. 여기에는 여러 가지 이유가 있습니다:

1. 애플리케이션은 쉽게 복제하고 여러 인스턴스로 생성할 수 있습니다(예: 마이크로서비스). 포렌식, 감사 또는 관측성 확보를 위해 필요할 수 있는 고유한 ID를 각 복제본에 어떻게 부여할 수 있을까요?
2. 애플리케이션 ID는 실행 환경에 따라 달라집니다. 예를 들어 개발 환경과 프로덕션 환경에서 애플리케이션은 동일하지만, 각 환경에서는 서로 다른 ID가 필요합니다.
3. 애플리케이션이 생성되는 인프라가 신원 정보나 비밀 정보 및 키를 몰래 탈취하지 않을 것이라는 신뢰를 어떻게 구축할 수 있을까요?
4. 중앙 볼트를 공격으로부터 보호하고, 이 볼트에 저장된 모든 비밀 정보와 키를 안전하게 지키려면 어떻게 해야 할까요?

따라서 동적인 환경 전반에서 인프라, 애플리케이션 및 데이터를 보호하는 것은 매우 어려운 과제입니다. 클라우드 제공업체들은 이러한 과제에 대응하여 관련 문제를 해결할 수 있는 다양한 도구를 제공해 왔지만, 다음과 같은 이유로 이러한 도구를 통합하고 유지 관리하는 일은 쉽지 않습니다:

• 복잡성 — 각 클라우드 제공업체는 고객이 여러 서비스를 구성하고 관리하도록 요구합니다. 예를 들어 AWS의 경우 메타데이터 서비스, IAM 역할, 서비스 계정, RBAC, KMS 및 Secrets Manager가 있습니다. 이러한 서비스는 의미 체계, API, 모니터링 측면에서 클라우드 제공업체마다 크게 다릅니다.
  
• 상호 운용성 — 클라우드 공급자의 서비스를 구성하고 운영하더라도 이러한 서비스 간에는 상호 운용이 불가능합니다. 예를 들어 GCP에서 실행되는 VM은 GCP 서비스 계정을 통해 할당된 ID를 AWS 리소스가 인식하지 못하므로 AWS의 리소스에 액세스할 수 없습니다.
  
• 이기종 환경 — 환경이 퍼블릭 및 프라이빗 클라우드나 여러 퍼블릭 클라우드에 분산되어 있거나, 더 나쁘게는 엣지에까지 분산되어 있다면 비밀번호, 키 등의 보안 정보를 중앙에 저장할지 아니면 분산하여 저장할지, 그리고 어디에 저장할지가 과제가 됩니다.
  
• 환경별 특성 — 자격 증명 교체 및/또는 폐기 방식은 클라우드 제공업체마다 크게 다르며, 엣지 클러스터에는 이러한 기능이 전혀 없습니다.

많은 기업이 단일 클라우드 공급자만 이용하므로 해당 공급자가 제공하는 기본 보안 기능을 관리하고 강화하는 데 리소스를 투자하는 것만으로도 충분할 수 있지만, 당사는 이기종 환경(하이브리드 클라우드 및 엣지)에서 운영되기 때문에 이러한 문제를 해결할 새로운 솔루션을 구축해야 했습니다.

분산 플랫폼 보안을 위한 솔루션

우리 팀은 그림 1과 같이 분산 인프라 전반에 존재할 수 있는 애플리케이션, 인프라 및 데이터의 보안을 담당했습니다.

그림 1: 분산 플랫폼 보안 — ID, 비밀 정보 및 키 관리

이에 따라 플랫폼 팀은 엣지, 모든 클라우드 및 네트워크 PoP 전반에서 플랫폼 보안을 제공하기 위해 다음 네 가지 요소를 통합한 새로운 소프트웨어 서비스를 구축하기로 결정했습니다:

1. ID 관리 — 애플리케이션뿐만 아니라 이기종 환경(여러 클라우드, 전 세계에 분산된 당사의 PoP, 지리적으로 분산된 엣지 위치)에 배포되어 여러 환경(예: 개발자 머신, 단위 테스트, 프로덕션 등)으로 운영되는 인프라에도 암호학적으로 안전하고 위조할 수 없는 PKI 기반 ID를 제공하는 방법을 설명합니다.
   
2. 인증 및 권한 부여 — 당사의 인프라는 PKI 기반 ID를 사용하는 마이크로서비스로 구축되어 있으며, 사용되는 통신 프로토콜과 관계없이 모든 통신을 상호 인증합니다. 또한 공통 권한 부여 엔진을 다양한 권한 부여 결정에 활용하고 정책 구조를 통합할 수 있도록 권한 부여를 인증과 분리했습니다.
   
3. 비밀 정보 관리 시스템 — 당사 소프트웨어와 고객 워크로드에는 TLS 인증서, 비밀번호, 토큰 등 다양한 유형의 비밀 정보가 필요합니다. 가장 간단한 방법은 모든 비밀 정보를 중앙 집중식 볼트에 저장하는 것이었겠지만, 이 방식은 한 번이라도 침해되면 모든 비밀 정보가 노출된다는 단점이 있습니다. 여기서는 일부 편의성을 포기하는 대신 더 높은 수준의 보안을 달성하기 위해 당사가 구현한 다른 접근 방식을 설명합니다.
   
4. 키 관리 시스템(KMS) — 데이터 보안은 당사의 분산 시스템에서 매우 중요하며, 팀은 여러 클라우드 제공업체에서 원활하게 작동하는 KMS를 구축해야 했습니다. KMS는 저장 데이터의 대칭 암호화 및 복호화, CSRF 토큰의 HMAC 생성, 바이너리의 디지털 서명에 사용되는 키를 관리하고 버전을 지정하며 교체해야 합니다. 이 KMS를 활용한 보안에 민감한 작업과 비밀 관리 시스템을 활용한 지연 시간에 민감한 작업을 모두 지원하는 방법을 살펴보겠습니다.

인프라 및 앱을 위한 위조 불가능한 ID

신원은 근본적인 문제입니다. 신원 문제가 해결되면 많은 보안 과제를 더 쉽게 해결할 수 있기 때문입니다. 하지만 신원 문제를 해결하려면 신원이 무엇을 의미하는지 정의하고, 신뢰할 수 있는 방식으로 신원을 발급하는 방법을 정해야 합니다. 암호 기술 전문가들은 모든 것을 자신만의 관점으로 해석하길 좋아하며, 신원의 정의도 예외는 아닙니다:

개인이나 사물이 무엇으로 알려지거나 간주되는지를 구성하며, 신뢰할 수 있는 기관이 위임되지 않은 안전한 프로토콜을 통해 암호학적으로 인증한 고유하고 완전한 위조 불가능한 동시에 암호학적으로 검증 가능한 특성의 집합.

본질적으로 필요한 것은 위조가 불가능하고 암호학적으로 검증 가능한 신원을 안전하게 제공하는 것입니다. 이러한 신원을 발급하는 데에는 두 가지 어려움이 있습니다. 1) 신원 부트스트래핑 및 2) 신뢰의 근원

아이덴티티와 관련하여 자주 논의되는 접근 방식으로는 SPIFFE와 Hashicorp Vault가 있습니다. SPIFFE는 당사 시스템에서 아이덴티티 문서(X.509 인증서)로 사용할 수 있는 명명 체계이지만, 바이너리 데이터를 포함하는 일부 아이덴티티 속성에는 그 형식이 적합하지 않습니다. Vault를 사용하여 아이덴티티 문서를 발급할 수는 있지만, 아이덴티티 부트스트래핑과 신뢰 루트 문제는 해결하지 못합니다:

1. ID 부트스트래핑 — 현실 세계에서는 사람이 태어나면 출생증명서를 통해 신원이 확립됩니다. 이는 논리적으로 그 사람의 신원을 부트스트래핑하며, 해당 증명서를 사용해 여권, 운전면허증 등의 추가 신분증을 발급받거나 요청할 수 있습니다. 마찬가지로 컴퓨팅 환경에서도 애플리케이션(또는 마이크로서비스)이 실행될 때마다 ID를 부트스트래핑해야 합니다. ID 확립은 실행 중인 코드가 다른 서비스와 상호 작용하기 위해 가장 먼저 수행해야 하는 단계 중 하나입니다. 또한 동일한 애플리케이션 코드가 여러 번, 서로 다른 환경`(개발자 노트북, 단위 테스트, 프로덕션)에서 실행될 수 있으므로, 각 실행마다 별도의 부트스트랩 ID를 확립해야 합니다.
2. 신뢰의 루트 — 부트스트랩 ID를 발급하는 과정은 간단해 보일 수 있지만, 문제는 누가 이 ID를 프로비저닝하느냐입니다. 예를 들어 현실 세계에서 신원 프로비저닝은 병원이 특정 날짜와 시간에 특정인의 아이가 태어났다는 사실을 확인하는 것에서 시작하며, 병원이 적절한 검증을 거쳐 위조할 수 없는 출생 기록을 발급한다는 전제가 깔립니다. 따라서 출생 기록 문서는 신뢰할 수 있는 정보원(또는 신뢰의 루트)으로 사용할 수 있습니다. 마찬가지로 사람이나 자동화된 코드가 애플리케이션을 실행할 때는 실행된 애플리케이션의 ID를 검증 가능한 방식으로 확인해 줄 신뢰의 루트가 필요합니다. 이후 이 확인 정보를 사용하여 애플리케이션의 후속 ID 문서를 생성할 수 있습니다.

예를 들어 AWS에서 VM이 시작되면 부트스트랩 ID가 제공되며, AWS의 메타데이터 서비스가 신뢰 루트 역할을 합니다. AWS가 자체 암호화 키로 서명한 ID 문서는 다음과 같은 형태입니다:

실행된 애플리케이션 인스턴스의 고유 ID를 instanceId가 나타낼 수는 있지만, 다른 애플리케이션이 이 특정 인스턴스와 통신할 때 사용할 잘 알려진 이름(myserver.acmecorp.com)과 연결해야 합니다. 따라서 이 AWS 부트스트랩 ID 문서만으로는 충분하지 않지만, 애플리케이션 간 통신에 사용할 수 있는 또 다른 ID를 발급하는 데 활용할 수 있습니다.

앞서 언급했듯이, 애플리케이션이 여러 클라우드 제공업체 및/또는 엣지 위치에 걸쳐 통신하고 정보를 공유할 수 있도록 하는 ID를 제공하는 것이 매우 중요했습니다(그림 2). 이를 위해 이러한 모든 환경에서 작동하는 ID 부트스트래핑 및 신뢰 루트 시스템을 구축해야 했습니다.

그림 2: 클라우드 제공업체, 네트워크 PoP 및 엣지 간 통신

Kubernetes를 사용하여 애플리케이션(마이크로서비스와 VM 모두)을 관리하고 오케스트레이션하므로, 실행되는 모든 Pod의 고유 ID를 부트스트랩하는 작업을 Kubernetes의 Pod 생성 프로세스에 연동해야 했습니다. 그림 3은 K8s 웹후크 메커니즘을 사용하여 Pod 생성 프로세스에 연동하는 방법을 보여줍니다. Voucher라는 이 웹후크는 Wingman이라는 보안 사이드카를 클러스터에서 생성되는 모든 Pod에 주입하고, 신뢰 루트로 사용할 수 있는 필수 암호화 서명 정보도 제공합니다. 이 웹후크는 Wingman이 Volterra의 SaaS 백엔드에 있는 Identity Authority에 X.509 인증서를 요청할 때 사용하는 수명이 짧은 서명 토큰을 제공합니다.

Identity Authority는 K8s 클러스터 중 하나가 침해되더라도 피해 범위를 최소화할 수 있도록 ID 발급 규칙을 적용합니다. 공통 루트 CA 또는 K8s 클러스터 페더레이션에 의존하는 다른 많은 솔루션은 피해 범위를 제한할 수 없으며, 이는 당사의 설계 결정에 큰 영향을 미친 요인이었습니다.

그림 3: 각 Kubernetes 클러스터의 신뢰 루트

K8s의 특정 Pod는 생성된 후에도 속성이 변경될 수 있습니다. 예를 들어, Pod가 생성된 후 새 서비스에 연결될 수 있습니다. 따라서 ID 인증서에도 새 서비스 정보가 반영되도록 업데이트해야 했습니다. Wingman은 이러한 업데이트를 감지하기 위해 K8s API 서버를 추적하는 Voucher를 지속적으로 모니터링합니다.

이 메커니즘은 자체 워크로드인지 고객 워크로드인지와 관계없이 플랫폼 전반에서 실행되는 모든 애플리케이션 인스턴스에 고유하고 범용적인 글로벌 ID를 부여합니다. 이후 이 고유 ID와 사이드카(Wingman)를 사용하여 분산 시스템 전반의 모든 통신, 액세스 및 키/비밀 정보를 안전하게 보호합니다.

인증 및 권한 부여

Pod마다 고유한 ID를 부여하는 것은 통신하는 서비스 간 상호 인증을 더 쉽게 구현할 수 있게 해 주므로 훌륭한 출발점입니다. 기반 인프라는 gRPC, REST, IPSec, BGP 등 서로 다른 프로토콜을 사용하는 다양한 서비스로 구성되어 있습니다. 팀은 초기부터 프로토콜에 관계없이 통신하는 모든 주체 간에 상호 인증과 통신 보안(암호화된 채널)을 구현하는 것을 목표로 삼았습니다. 이는 또한 특정 프로토콜 집합(예: HTTP/TCP와 IP 기반 프로토콜)만 지원하는 솔루션(예: Istio)에 ID 체계를 종속시킬 수 없다는 의미이기도 했습니다.

또한 당사 플랫폼에서는 고객이 원하는 워크로드를 실행할 수 있으므로, 이러한 워크로드가 다양한 프로토콜을 사용할 수 있다고 예상합니다. 따라서 플랫폼은 특정 프로토콜 집합에 국한된 ID를 제공함으로써 워크로드의 기능을 제한해서는 안 됩니다. 대신 인증은 Wingman을 통해 ID와 분리되며, 이를 통해 다양한 서비스 메시 기술과 연동할 수 있습니다. 이전 블로그에서 다룬 당사의 서비스 메시 사이드카/데이터 플레인은 이 ID를 사용하여 고객 워크로드에 mTLS를 제공합니다.

당사의 자체 인프라 서비스 중 상당수가 Volterra Golang Service Framework(향후 블로그에서 다룰 예정)를 사용해 작성되었기 때문에, Wingman에서 제공하는 ID를 사용하는 로직을 프레임워크에 직접 통합하기로 했습니다. 덕분에 개발자들은 mTLS를 위해 서비스 메시 사이드카에 의존하지 않고도 별도의 설정 없이 서비스 간 통신을 안전하게 보호할 수 있게 되었습니다.

상호 인증된 보안 채널을 구축한 후의 다음 단계는 논리적으로 권한 부여(Authorization)입니다. 이는 요청 수신자(서버)가 식별된 호출자(클라이언트)의 요청을 허용할지 여부를 결정하는 과정입니다. 요청을 허용하지 않는 이유는 할당량 제한, 권한 등 다양할 수 있습니다. 이러한 이유와 임계값은 동적으로 변경되므로, 권한 부여 규칙(정책)을 하드 코딩하는 방식은 처음부터 저희 플랫폼에 적합하지 않았습니다.

우리는 Open Policy Agent의 엔진을 출발점으로 삼아 Wingman 사이드카 내에 권한 부여용 래퍼를 구축하기로 했습니다. 이 래퍼 코드는 관련 정책을 동적으로 가져와 빠르게 평가할 수 있도록 즉시 사용 가능한 상태로 유지합니다. 인증과 마찬가지로 권한 부여 엔진을 ID(및 인증)와 분리함으로써, 인증 직후뿐만 아니라 비즈니스 로직의 깊숙한 부분을 포함한 요청 처리의 여러 단계에서 권한 부여 정책을 적용할 수 있게 되었습니다.

Wingman은 고객의 워크로드를 포함한 모든 워크로드에 삽입되므로, 당사 플랫폼은 권한 부여 엔진을 기본 기능으로 제공합니다. Open Policy Agent(OPA)는 Rego라는 강력한 언어를 기반으로 하지만, 당사는 개발자와 고객이 그 복잡성을 접하지 않도록 하고자 했습니다. 또한 당사 플랫폼의 모든 정책은 훨씬 이해하기 쉽고 직관적인 정책 구조를 사용해 정의할 수 있으므로, 사용자(DevOps)가 Rego를 학습할 필요가 없고 그에 따른 실수도 방지할 수 있습니다. 인증 구성과 마찬가지로, 당사의 Golang 서비스 프레임워크는 권한 부여 시 Wingman을 자동으로 호출하도록 Wingman의 권한 부여 엔진과 연동되어 개발자가 권한 부여의 복잡성을 신경 쓰지 않아도 됩니다.

인증에는 Wingman에서 발급한 고유 ID를 사용하고, 권한 부여에는 Wingman에 내장된 프로그래밍 가능한 정책 엔진을 사용함으로써 mTLS로 통신을 보호하고 강력하면서도 프로그래밍 가능한 정책을 통해 모든 접근을 제어할 수 있습니다.

중앙 집중식 볼트 없는 시크릿 관리

엔지니어들은 매일 무심코 키와 비밀번호를 코드에 저장하는 실수를 저지르며, 이렇게 저장된 정보가 어떤 경로로든 공개 코드 저장소나 아티팩트 저장소에 유입되곤 합니다. 시크릿 관리는 어렵습니다. 사용하기 쉬운 도구와 명확하게 정의된 프로세스가 없다면 개발자는 가장 손쉬운 방법을 택할 수밖에 없습니다. 이에 따라 회사 설립 초기부터 플랫폼 보안(네트워크 및 애플리케이션 보안과는 별개) 팀은 개발자가 “시크릿을 어디에 저장해야 하지? 소스 코드? 아티팩트? 아니면…?”과 같은 고민을 하지 않아도 되도록 하는 것을 사명으로 삼았습니다.

플랫폼 구축을 시작할 당시 시크릿 관리에 사용할 수 있었던 두 가지 일반적인 접근 방식을 검토했지만, 두 방식 모두 몇 가지 단점이 있었습니다:

1. Kubernetes 시크릿 — Kubernetes를 사용하고 있으며 Kubernetes에는 자체 시크릿 솔루션이 포함되어 있지만, 여러 가지 이유로 그다지 유용하지 않습니다. 시크릿은 저장 시 암호화되지 않고, 정책 구성 요소가 포괄적이지 않으며, 멀티 클러스터 시나리오를 해결하지 못합니다.
   
2. 중앙 집중식 Vault(예: Hashicorp 또는 Cyberark Vault) — 또 다른 접근 방식으로는 비밀 정보를 중앙에 저장하고 권한이 있는 요청자에게 제공하는 Vault를 사용할 수도 있습니다. 비밀 정보는 Vault의 암호화 저장소에 사용되는 단일 암호화 키로 보호됩니다. 하지만 이 접근 방식의 문제는 비밀 관리 시스템이 평문 비밀 정보에 접근할 수 있으며(암호화된 형태로 저장되더라도), 시스템이 침해될 경우 모든 비밀 정보가 노출될 수 있다는 점입니다.

저희는 SaaS 서비스를 제공하기 때문에, 시스템이 침해되더라도 고객의 비밀 정보가 노출되지 않도록 이를 보호할 수 있는 더욱 강력한 방법을 마련해야 했습니다.

그 결과, 그림 4와 같이 보안 사이드카인 Wingman과 연동되는 새로운 기술인 Volterra Blindfold(상표)를 구현하기로 했습니다. 이 접근 방식을 사용하면 비밀 정보의 소유자가 원치 않는 어떤 당사자(복호화 서버 포함)에게도 비밀 정보가 평문으로 노출되지 않도록 잠글(암호화할) 수 있습니다. 비밀 정보는 중앙 복호화 서버에도 저장되지 않으며, 이러한 설계는 몇 가지 측면에서 서버 설계를 크게 단순화합니다.

그림 4: 비밀 관리를 위한 Blindfold와 Wingman

사용자가 완전히 오프라인인 환경에서 비밀 정보(S)를 암호화할 수 있도록 blindfold 도구를 제공합니다. 이렇게 암호화된 비밀 정보는 배포할 수 있습니다. 예를 들어 비밀 정보 자체를 워크로드와 함께 저장한 후 레지스트리에 업로드할 수 있습니다. 이 작업이 완료되면 다음 단계를 수행해야 합니다:

이를 통해 중앙 집중식 컨트롤 플레인이 평문 상태의 시크릿(S)에 절대 액세스할 수 없으며, 시크릿은 액세스가 이루어지는 동안에만 Pod의 런타임 메모리에서 사용할 수 있습니다. 또한 액세스 정책을 적용하여 시크릿에 액세스할 수 있는 주체를 지정할 수 있습니다. 정책은 애플리케이션 이름, 위치, 규정 준수 수준 등의 ID 속성을 기반으로 정의할 수 있습니다. 이를 통해 워크로드를 아무리 복잡한 하위 집합으로도 구분하여 정밀한 액세스 제어를 구현할 수 있습니다. 정책은 암호화, 블라인딩, 복호화 및 언블라인딩 프로세스에 암호학적으로 결합되어 있으므로, 정책의 의도를 무력화하는 것은 계산상 불가능합니다.

각 시크릿을 잠그는 고유한 Blindfold 기술과 정책 및 위조 불가능한 ID를 기반으로 각 시크릿의 잠금을 해제하는 Wingman을 활용함으로써, 기존 솔루션의 문제를 극복하고 중앙의 핵심 저장소가 침해될 우려 없이 분산 환경에서 시크릿 관리를 제공할 수 있습니다.

분산 시스템을 위한 키 관리

비밀 정보 관리와 키 관리는 같은 문제를 가리키는 서로 다른 두 가지 명칭처럼 들릴 수 있지만, 누구에게 묻는지와 솔루션을 어떻게 구현하려는지에 따라 둘 사이에는 미묘하지만 실무적으로 중요한 차이가 있습니다.

시크릿은 기밀로 유지되어야 하며 권한이 없는 당사자에게 공개되어서는 안 되는 모든 정보를 의미합니다. 어떤 의미에서 암호화 키는 시크릿의 한 유형입니다. 반면 키 관리는 일반적으로 민감한 암호화 키 자료를 안전하게 저장하고 그 사용을 제어하는 시스템을 의미합니다. 경우에 따라 키 관리 시스템이 권한이 있는 당사자에게 키의 원시 바이트를 제공할 수 있으므로 시크릿 관리 시스템과 혼동되기도 합니다. 그러나 대부분의 경우 키 관리 시스템은 키 자료의 원시 바이트를 직접 제공하지 않고, 권한이 있는 요청자를 대신해 작업을 수행한 후 그 결과만 전송합니다. 또한 많은 키 관리 시스템은 키 자료를 하드웨어 스토리지(예: HSM)에 저장하여 키가 소프트웨어에 평문으로 노출되지 않도록 합니다.

분산 환경에서는 단일 클라우드 제공업체만 사용하는 경우에도 암호화 키를 관리하고 동기화하며 교체하는 일이 매우 어렵고, 현재의 솔루션은 오류가 발생하기 쉽고 비효율적이며 심지어 안전하지 않을 수도 있습니다. 예를 들어 현재 3개의 AWS 리전을 사용하면서 세 리전 모두에서 동일한 암호화 키를 사용하려면 키를 수동으로 동기화하고 교체해야 합니다. 여러 클라우드 제공업체(퍼블릭 및/또는 프라이빗)에 걸쳐 환경이 구성되면 문제는 더욱 심각해집니다. 이 모든 작업을 마친 후에도 애플리케이션 소유자는 이러한 KMS 기능을 활용하기 위해 복잡한 코드를 작성해야 합니다.

당사 플랫폼은 Wingman 사이드카가 모든 복잡한 작업을 처리하도록 하고, 애플리케이션에 암호화, 복호화, HMAC, HMAC 검증, 디지털 서명, 서명 검증, 키 가져오기(허용되는 경우) 등의 키 관리 요청을 위한 간단한 인터페이스를 제공함으로써 키 관리의 모든 복잡성을 애플리케이션으로부터 숨깁니다. 덕분에 자체 인프라 서비스와 고객 워크로드 모두에서 키 관리를 전혀 어렵지 않게 수행할 수 있습니다.

다음 다이어그램(그림 5)은 Volterra의 KMS가 여러 환경에서 어떻게 작동하며, 워크로드가 키 관리 및 암호화 작업을 Wingman 사이드카에 위임하도록 지원하는지를 보여줍니다. 구성에 따라 Wingman은 애플리케이션이 인지하지 못하는 사이에 키를 캐시하고 캐시를 새로 고칠 수 있습니다. 이를 가능하게 하는 핵심 요소는 앞서 소개한 보편적이고 위조 불가능한 ID입니다. 각 Pod는 위치와 관계없이 전역적으로 고유한 ID를 부여받으므로, Volterra KMS 시스템은 암호화 키와 암호화, 복호화, HMAC, HMAC 검증, 디지털 서명, 서명 검증 등의 특정 작업에 액세스 정책을 매우 정확하게 적용할 수 있습니다.

그림 5: SaaS 백엔드의 Wingman 및 KMS 서버

모든 키가 Volterra의 SaaS 백엔드를 통해 관리되므로, 이기종 환경에서 실행되는 워크로드는 키 동기화, 교체, 폐기 등을 직접 처리할 필요가 없습니다. 저장 데이터 보안에 필요한 모든 작업은 간단한 Wingman API만 알면 됩니다.

당사의 플랫폼 보안 솔루션이 제공하는 이점

다계층 플랫폼 보안을 활용하여 세 가지 핵심 문제를 완전히 새로운 방식으로 해결하는 종합 솔루션을 제공할 수 있었습니다! 당사 시스템은 “끝없이 이어지는 거북이” 문제에 빠지지 않는 범용 ID를 안전하게 부트스트랩하고, 골드마인 문제를 걱정할 필요 없이 저장 및 배포할 수 있는 비밀 정보를 관리하며, 분산 환경에서 저장 데이터의 보안을 간소화하는 키 관리 기능을 제공합니다. 이를 통해 내부 팀과 고객 모두 다음과 같은 이점을 얻었습니다:

1. 보안 및 규정 준수 — 위조가 불가능한 범용 ID, Blindfold, 그리고 플랫폼에 완전히 통합되어 자동으로 관리되는 보안 사이드카(Wingman)를 통해 모든 통신을 보호하고, 모든 접근을 승인하며, 분산 시스템 전반의 키와 비밀 정보를 관리합니다. 이러한 기술 발전을 바탕으로 더욱 강력한 보안 솔루션을 제공하여 당사와 고객이 규정 준수 요건을 보다 쉽게 충족할 수 있게 되었습니다.
   
2. 생산성 향상 — DevOps 프로세스 및 서비스 프레임워크에 통합된 보안 솔루션을 사용하면 개발자와 DevOps 팀이 애플리케이션 및 데이터 보안의 핵심 요소를 걱정하지 않고 각자의 결과물에 집중할 수 있습니다.
   
3. 지속적인 발전 — 끊임없이 변화하는 보안 환경과 새로운 기술에 발맞춰 Blindfold, Wingman 및 Golang 서비스 프레임워크도 지속적으로 발전합니다. 그 결과, 애플리케이션 로직을 변경하지 않아도 플랫폼을 통해 새로운 기능이 자동으로 배포됩니다.

계속됩니다…

이 블로그 시리즈에서는 퍼블릭 클라우드의 여러 애플리케이션 클러스터와 자체 사설 네트워크 PoP 및 엣지 사이트를 기반으로 전 세계에 분산된 SaaS 서비스를 구축하고 운영하기까지 필요했던 다양한 요소를 다룹니다. 다음 주제는 애플리케이션 및 네트워크 보안…

이 기능을 오픈 소스 프로젝트로 더 넓은 커뮤니티에 제공할 수 있도록 도와주실 자원봉사 개발자와 솔루션 아키텍트를 찾고 있습니다. 재미있는 프로젝트에 함께하고 싶으시다면 asingla@volterra.io로 직접 연락해 주세요!

작성자 소개

Ankur Singla

Ankur Singla의 다른 블로그 게시물