분산 플랫폼 보안 - ID, 비밀 및 키 관리
이는 SaaS 서비스를 구축하고 운영하는 데 필요한 다양한 측면을 다루는 일련의 블로그 중 세 번째 블로그입니다.
- 분산 Kubernetes PaaS를 위한 제어 평면
- 분산 애플리케이션을 위한 글로벌 서비스 메시
- 분산 인프라, 앱 및 데이터를 위한 플랫폼 보안
- 분산 클러스터의 응용 프로그램 및 네트워크 보안
- 전 세계적으로 분산된 플랫폼에서의 관찰 가능성
- 전 세계적으로 분산된 플랫폼의 운영 및 SRE
- 분산 마이크로서비스를 위한 Golang 서비스 프레임워크
제가 처음 블로그에 올린 글 에서는 분산 클라우드를 위한 새로운 플랫폼을 구축하게 된 배경을 설명했습니다. 이 플랫폼을 사용하여 당사 고객은 스마트 제조, 공공 안전을 위한 비디오 포렌식, 알고리즘 트레이딩, 통신사 5G 네트워크 등 복잡하고 다양한 애플리케이션 세트를 구축합니다.
이러한 애플리케이션 중 다수가 미션 크리티컬하므로 고객은 당사가 다중 계층 보안을 제공할 뿐만 아니라 분산 클러스터의 보안을 유지하기 위해 지속적인 개선을 수행할 수 있는 능력도 갖추고 있기를 기대합니다. 이 특정 블로그에서는 여러 클러스터에서 인프라, 애플리케이션 및 데이터를 보호하는 과제를 해결합니다.
TL;DR (요약)
- 사용자와 직원이 애플리케이션에 안전하게 접근할 수 있도록 하는 방법은 비교적 잘 알려져 있습니다(우리는 은행 계좌나 회사 이메일을 접근할 때 매일 이 작업을 수행합니다). 그러나 앱 간 액세스나 앱과 데이터 간 액세스의 경우 검증 과정에 인간이 관여하지 않기 때문에 동일한 작업을 수행하는 것은 쉽지 않습니다.
- 이기종 환경(에지, 다중 클라우드, 네트워크 PoP)에서 앱과 데이터를 보호하려면 ID, 인증 및 권한 부여, 비밀, 키 관리 등 다중 계층 문제를 해결해야 했습니다.
- 이러한 4가지 문제를 해결하는 데는 여러 가지 포인트 솔루션(예: 개별 클라우드 공급업체의 여러 서비스, Hashicorp Vault, SPIFFE/Spire 등)이 있지만, 여러 클라우드 공급업체에서 작동하거나 각 서비스를 원활하게 결합하여 사용하기 편리한 통합 솔루션은 없습니다.
- 개발자 및 DevOps 팀 내에서 이러한 부분을 어떻게 통합할지에 대한 전문성이 부족했기 때문에 플랫폼 팀에서는 이러한 기능을 사용하기 쉬운 통합 솔루션으로 제공하는 것이 필수적이었습니다. 진화하는 보안 환경과 새로운 기술은 이러한 팀에게 필요한 전문 지식이나 모든 변화에 발맞추는 데 필요한 대역폭이 없기 때문에 더욱 어렵게 만들고 있습니다.
- 다중 계층 플랫폼 보안을 제공하는 일환으로 우리는 완전히 새로운 방식으로 세 가지 중요한 문제를 해결하는 새로운 소프트웨어 구성 요소를 구축했습니다. 즉, "거북이가 맨 아래까지"라는 문제가 없는 범용 ID를 안전하게 부트스트래핑하고, 중앙 금고의 손상(골드마인 문제)에 대한 걱정 없이 저장하고 배포할 수 있는 비밀을 제공하며, 저장 중인 데이터의 보안을 용이하게 하는 분산 키 관리를 제공합니다.
보안 문제에 대한 배경
위에서 언급한 대로, 애플리케이션에 대한 사용자 접근(예: 은행 계좌나 이메일에 대한 접근)을 보호하는 문제는 잘 알려져 있습니다. 하지만 앱 간 액세스나 앱과 데이터 간 액세스의 경우 검증 과정에 인간이 개입하지 않기 때문에 동일한 작업을 수행하는 것이 그렇게 간단하지는 않습니다.
애플리케이션이 안전한 방식으로 다른 리소스에 액세스하려면(예: 객체 저장소에 저장된 데이터 또는 다른 애플리케이션에 대한 API 호출 등) 다음이 수행되어야 합니다.
- 신원 — 요청자는 필요한 리소스에 액세스할 때 인증 및 승인 목적으로 사용할 수 있는 검증 가능한 신원을 안전하게 획득해야 합니다. 요청자는 또한 피어의 신원을 확인하는 데 사용할 수 있는 필수 신뢰 앵커를 안전하게 확보해야 합니다.
- 인증 - 주어진 리소스에 액세스하는 과정에서 요청자와 리소스 소유자는 서로의 신원을 안전하게 확인해야 합니다. 피어가 주장한 신원과 제시된 신원을 대조하는 과정을 인증이라고 합니다.
- 승인 — 요청자가 인증되면 리소스에 대한 액세스가 허용되는지 여부를 확인하는 프로세스를 승인이라고 합니다.
인증 프로세스의 일부로, 요청하는 애플리케이션은 PKI 인증서나 비밀(예: 비밀번호) 또는 키 형태로 자신의 신원을 제시할 수 있습니다. 신원 확인을 위해 비밀이나 키를 사용할 때 해결해야 할 두 가지 문제가 있습니다.
- 비밀과 키는 코드에 직접 저장해서는 안 됩니다. 코드에 직접 저장하면 공격 위험이 높아지고, 유출된 키는 큰 문제가 될 수 있습니다.
- 비밀이 외부 금고에 저장되어 있다면 비밀을 얻기 위해 어떤 신원(보통 다른 비밀)을 사용해야 할까요? 그리고 비밀을 얻기 위해 이 신원을 어떻게 보호해야 할까요?
이러한 보안 작업(앱 간 상호작용)을 안정적이고 반복 가능한 방식으로 수행하는 것은 간단한 문제가 아닙니다. 이것이 사소한 일이 아닌 데에는 여러 가지 이유가 있습니다.
- 애플리케이션은 쉽게 복제되고 생성될 수 있습니다(예: 마이크로서비스). 법의학, 감사 또는 관찰 목적으로 필요할 수 있는 각 클론에 고유한 ID를 할당하는 방법은 무엇입니까?
- 애플리케이션 ID는 실행되는 환경에 따라 달라집니다. 예를 들어, 개발 환경과 운영 환경에서 애플리케이션은 동일하지만 각 환경에서 서로 다른 ID가 필요합니다.
- 애플리케이션이 생성되는 인프라가 발각되지 않고 신원이나 비밀, 키를 훔치지 않을 것이라는 신뢰를 구축하려면 어떻게 해야 하나요?
- 중앙 금고를 공격으로부터 보호하고, 이 금고에 저장된 모든 비밀과 열쇠를 안전하게 보호하려면 어떻게 해야 할까?
결과적으로, 역동적인 환경에서 인프라, 애플리케이션 및 데이터를 보호하는 것은 매우 어려운 문제가 되었습니다. 클라우드 제공업체는 이러한 과제에 대처하고 이러한 문제를 해결하기 위한 많은 도구를 제공했지만 다음과 같은 이유로 이를 통합하고 유지 관리하는 것은 쉽지 않습니다.
- 복잡성 - 각 클라우드 공급자는 고객이 여러 서비스를 구성하고 관리하도록 요구합니다. 예를 들어 AWS에서는 메타데이터 서비스, IAM 역할, 서비스 계정, RBAC, KMS 및 비밀 관리자가 있습니다. 각 서비스는 클라우드 제공업체마다 의미, API, 모니터링 측면에서 매우 다릅니다.
- 상호 운용성 - 클라우드 공급자 서비스가 구성되고 운영화되더라도 이러한 서비스 중 어느 것도 상호 운용성을 허용하지 않습니다. 예를 들어, GCP에서 실행되는 VM은 GCP 서비스 계정을 사용하여 할당된 ID를 AWS 리소스에서 인식하지 못하기 때문에 AWS의 리소스에 액세스할 수 없습니다.
- 이기종 환경 - 환경이 퍼블릭 및 프라이빗 클라우드, 또는 여러 퍼블릭 클라우드에 걸쳐 분산되어 있거나, 더 나쁜 경우, 에지에 있는 경우, 비밀번호, 키 등의 비밀을 어떻게 그리고 어디에 저장할 것인지, 중앙에서 저장할 것인지 아니면 분산하여 저장할 것인지가 문제가 됩니다.
- 환경별 - 자격 증명 회전 및/또는 폐기에 대한 솔루션은 각 클라우드 공급자마다 매우 다르지만 에지 클러스터에는 이러한 솔루션이 없습니다.
많은 기업이 단일 클라우드 공급업체에 속해 있어 해당 공급업체의 보안 기본 요소를 관리하고 향상시키는 데 리소스를 투자하는 것만으로도 충분하지만, 우리는 이기종 환경(하이브리드 클라우드와 엣지)에서 운영하고 있으며 이러한 문제를 해결하기 위해 새로운 솔루션을 구축해야 했습니다.
분산 플랫폼 보안을 위한 솔루션
저희 팀은 그림 1에서 볼 수 있듯이 분산 인프라에 존재하는 애플리케이션, 인프라, 데이터에 대한 보안을 제공하는 업무를 맡았습니다.
결과적으로 당사 플랫폼 팀은 엣지, 클라우드 및 네트워크 PoP 전반에서 플랫폼 보안을 제공하기 위해 다음 4가지 측면을 통합하는 새로운 소프트웨어 서비스를 구축하기로 결정했습니다.
- ID 관리 - 우리는 암호화된 보안 및 위조 불가능한 PKI 기반 ID를 애플리케이션뿐만 아니라 이기종 환경(여러 클라우드, 글로벌 PoP, 지리적으로 분산된 에지 위치)에 분산되어 있고 여러 환경(예: 개발자 머신, 단위 테스트, 프로덕션 등)으로 작동하는 인프라에 제공하는 방법을 설명합니다.
- 인증 및 권한 부여 - 당사 인프라는 PKI 기반 ID를 활용하고 사용 중인 통신 프로토콜에 관계없이 모든 통신을 상호 인증하는 마이크로서비스 기반으로 구축됩니다. 또한 권한 부여와 인증을 분리하여 다양한 권한 부여 결정에 공통적인 권한 부여 엔진을 사용하고 정책 구조를 통합할 수 있습니다.
- 비밀 관리 시스템 - 소프트웨어와 고객 워크로드에 필요한 다양한 유형의 비밀(TLS 인증서, 비밀번호, 토큰 등)이 있습니다. 가장 간단한 방법은 모든 비밀을 저장하는 중앙 금고를 도입하는 것이지만, 이 접근 방식은 어떤 침해라도 발생하면 모든 비밀이 공개된다는 단점이 있었습니다. 우리는 일부 단순성을 포기하고 더 높은 수준의 보안을 달성하기 위해 구현한 다른 접근 방식을 설명하겠습니다.
- 키 관리 시스템(KMS) — 데이터 보안은 분산 시스템에 매우 중요하며, 팀에서는 여러 클라우드 공급자 간에 원활하게 작동하는 KMS를 제공해야 했습니다. KMS는 저장 데이터의 대칭 암호화 및 복호화, CSRF 토큰의 HMAC에 사용되는 키를 관리, 버전 관리 및 순환하고 바이너리에 디지털 서명해야 합니다. 이 KMS를 사용하여 보안에 민감한 작업에 대한 기능을 제공하는 방법과 비밀 관리 시스템을 사용하여 대기 시간에 민감한 작업에 대한 기능을 제공하는 방법에 대해 논의하겠습니다.
인프라 및 앱을 위한 위조 불가능한 ID
신원 문제는 근본적인 문제입니다. 신원 문제가 해결되면 많은 보안 문제를 훨씬 쉽게 해결할 수 있기 때문입니다. 그러나 신원을 해결하려면 신원이 무엇을 의미하는지 정의하고 신뢰할 수 있는 방식으로 신원을 발급하는 방법을 알아야 합니다. 암호화폐 괴짜들은 모든 것에 대해 자신만의 해석을 갖고 싶어하며, 신원의 정의도 예외는 아닙니다.
신뢰할 수 있는 기관에서 위임되지 않고 안전한 프로토콜을 통해 암호적으로 인증한, 위조 불가능 하고 암호적으로 검증 가능한 특성의 고유하고 전체적인 집합으로, 사람 또는 사물이 알려지거나 간주되는 것을 구성합니다.
본질적으로 필요한 것은 위조 불가능하고 암호학적으로 검증 가능한 신원을 안전하게 전달하는 것입니다. 이러한 신원 발급은 두 가지 이유로 어렵습니다. 1) 신원 부트스트래핑 및 2) 신뢰의 근원
ID와 관련하여 자주 논의되는 몇 가지 접근 방식이 있습니다. SPIFFE와 Hashicorp Vault입니다. SPIFFE는 우리 시스템에서 신원 문서(X.509 인증서)로 사용할 수 있는 명명 체계입니다. 하지만 이 형식은 이진 데이터를 포함하는 일부 신원 속성에는 적합하지 않습니다. Vault를 사용하여 신원 문서를 발급할 수는 있지만 신원 부트스트래핑 및 신뢰 루트 문제의 과제는 해결하지 못합니다.
- 신원 부트스트래핑 - 실제 생활에서 사람이 태어나면 그 사람의 신원은 출생증명서를 통해 확립됩니다. 이를 통해 논리적으로 개인의 신원을 확인하고, 이 인증서를 사용하여 해당 개인은 여권, 운전면허증 등 추가 신원 인증서를 발급/요청할 수 있습니다. 마찬가지로, 컴퓨팅 세계에서는 애플리케이션(또는 마이크로서비스)을 출시할 때마다 ID를 부트스트래핑해야 합니다. ID 설정은 실행 중인 모든 코드가 다른 서비스와 상호 작용하기 위해 수행해야 하는 첫 번째 단계 중 하나입니다. 또한, 동일한 애플리케이션 코드가 여러 번 다른 환경(개발자 노트북 대 단위 테스트 대 프로덕션)에서 실행될 수 있으므로 이러한 각 실행마다 별도의 부트스트랩 ID를 설정해야 합니다.
- 신뢰의 근원 - 부트스트랩 ID를 발급하는 것은 간단한 프로세스처럼 보일 수 있지만 문제는 누가 이 ID를 프로비저닝할 것인가입니다. 예를 들어, 현실 세계에서 신원 제공은 병원이 특정 날짜+시간에 특정한 사람에게서 아이가 태어났다는 사실을 주장하는 것으로 시작하며, 병원이 적절한 검사를 통해 출생 기록을 작성하고 위조할 수 없다는 가정이 이루어집니다. 결과적으로 출생 기록 문서는 진실의 근원(혹은 신뢰의 뿌리)으로 사용될 수 있습니다. 마찬가지로, 사람이나 자동화된 코드에 의해 애플리케이션이 실행되는 경우, 시작된 애플리케이션의 신원을 검증 가능하게 주장할 수 있는 신뢰 루트가 필요합니다. 이러한 주장은 이후 신청서에 대한 후속 신분 증명서를 생성하는 데 사용될 수 있습니다.
예를 들어, AWS에서 VM이 시작되면 부트스트랩 ID가 제공되고 AWS의 메타데이터 서비스가 신뢰 루트 역할을 합니다. (AWS가 자체 암호화 키를 사용하여 서명한) 신분증은 다음과 같습니다.
instanceId는 시작된 애플리케이션 인스턴스의 고유한 ID를 나타낼 수 있지만, 다른 애플리케이션이 이 특정 인스턴스와 통신하는 데 사용할 수 있는 잘 알려진 이름(myserver.acmecorp.com)에 연결되어야 합니다. 결과적으로 이 AWS 부트스트랩 ID 문서만으로는 충분하지 않지만, 애플리케이션이 다른 애플리케이션과 통신하는 데 사용할 수 있는 또 다른 ID를 발급하는 데 사용할 수 있습니다.
앞서 설명한 대로, 클라우드 공급자 및/또는 엣지 위치 간에 애플리케이션이 통신하고 정보를 공유할 수 있도록 하는 ID를 제공하는 것이 중요했습니다(그림 2). 즉, 이러한 모든 환경에서 작동하는 ID 부트스트래핑과 신뢰 루트를 위한 시스템을 구축해야 한다는 의미였습니다.
Kubernetes를 사용하여 애플리케이션(마이크로서비스와 VM 모두)을 관리하고 조정하므로, 시작된 모든 Pod에 대한 고유한 ID의 부트스트래핑을 Kubernetes의 Pod 생성 프로세스에 연결해야 했습니다. 그림 3은 K8s 웹훅 메커니즘을 사용하여 Pod 생성 프로세스에 연결하는 방법을 보여줍니다. Voucher라고 불리는 이 웹훅은 Wingman 이라는 보안 사이드카를 클러스터에서 생성된 모든 Pod에 주입하고, 신뢰의 루트 로 사용할 수 있는 필수적인 암호화된 서명된 정보도 제공합니다. 이 웹훅은 Wingman이 Volterra의 SaaS 백엔드에 있는 Identity Authority에 X.509 인증서를 요청하는 데 사용하는 단기 서명된 토큰을 제공합니다.
신원 권한은 K8 클러스터 중 하나가 손상된 경우 "폭발 반경"을 최소화하는 방식으로 신원을 생성하는 규칙을 시행합니다. 공통 루트 CA나 K8s 클러스터 연합에 의존하는 다른 많은 솔루션은 폭발 반경을 제한할 수 없습니다. 이는 우리의 설계 결정에 있어서 중요한 요소였습니다.
K8s의 주어진 Pod에 대해 Pod가 생성된 후에 속성이 변경될 수 있습니다. 예를 들어, Pod는 생성된 후에 새 서비스에 연결될 수 있습니다. 이는 새로운 서비스에 맞춰 신원 증명서를 업데이트해야 함을 의미했습니다. Wingman은 K8s API 서버를 추적하는 Voucher를 지속적으로 감시하여 이러한 업데이트가 있는지 확인합니다.
이 메커니즘은 자체 워크로드든 고객 워크로드든 관계없이 플랫폼 전반에서 실행되는 모든 애플리케이션 인스턴스에 고유하고 보편적인 글로벌 ID를 제공합니다. 이러한 고유한 ID와 사이드카(윙맨)는 분산 시스템 전반의 모든 통신, 액세스, 키/비밀을 보호하는 데 사용됩니다.
인증 및 권한 부여
Pod마다 고유한 ID를 갖는 것은 통신 서비스 간 상호 인증을 구현하는 작업을 용이하게 해주므로 좋은 시작입니다. 당사의 기본 인프라는 gRPC, REST, IPSec, BGP 등 다양한 프로토콜을 기반으로 작동하는 여러 서비스로 구성되어 있습니다. 초창기부터 팀은 프로토콜에 관계없이 모든 통신 당사자에 대해 상호 인증 및 통신 보안(암호화된 채널)을 달성하는 목표를 설정했습니다. 이는 또한 특정 프로토콜 집합(예: HTTP/TCP 대 Istio)으로 제한되는 솔루션(예: Istio)에 우리의 신원을 연결할 수 없다는 것을 의미했습니다. IP 기반).
당사 플랫폼은 고객이 원하는 워크로드를 실행할 수 있도록 허용하므로 이러한 워크로드에서 다양한 프로토콜을 실행할 수 있어야 하며 플랫폼이 특정 프로토콜 집합으로 제한된 ID를 제공하여 그 기능을 제한해서는 안 됩니다. 대신 인증은 ID에서 분리되며(Wingman을 통해) 이를 통해 다양한 서비스 메시 기술에 연결하는 것이 가능해집니다. 당사의 서비스 메시 사이드카/데이터플레인(이전 블로그에서 다루었음)은 이 ID를 사용하여 고객 워크로드에 대한 mTLS를 제공합니다.
당사의 많은 인프라 서비스가 Volterra Golang 서비스 프레임워크(향후 블로그에서 설명할 예정)를 사용하여 작성되었기 때문에 Wingman에서 가져온 ID 소비 로직을 프레임워크에 직접 빌드하기로 결정했습니다. 이를 통해 당사 개발자는 mTLS용 서비스 메시 사이드카에 의존하지 않고도 서비스 간 통신을 안전하게 보호할 수 있었습니다.
상호 인증된 보안 채널을 구축한 후의 다음 논리적 단계는 권한 부여입니다. 권한 부여는 요청 수신자(서버)가 식별된 호출자(클라이언트)로부터 오는 요청을 허용할지 여부를 결정하는 프로세스입니다. 요청을 허용하지 않는 데에는 할당량 제한, 권한 등 여러 가지 이유가 있을 수 있습니다. 이러한 이유와 해당 임계값은 동적으로 변하기 때문에 승인을 위한 하드코딩된 규칙(정책) 세트는 당사 플랫폼에 적용할 수 없습니다.
우리는 Open Policy Agent의 엔진을 시작점으로 사용하기로 결정하고 Wingman 사이드카 내에서 권한 부여를 위한 래퍼를 빌드했습니다. 이 래퍼 코드는 관련 정책을 동적으로 가져와서 빠른 평가를 위해 핫 상태로 유지합니다. 인증과 마찬가지로 권한 부여 엔진을 ID(및 인증)에서 분리함으로써 요청 처리의 여러 단계에서 권한 부여 정책을 적용할 수 있게 되었으며, 이는 인증 직후뿐만 아니라 비즈니스 로직의 깊숙한 부분에서도 적용할 수 있게 되었습니다.
Wingman은 고객 워크로드를 포함한 모든 워크로드에 삽입되므로 당사 플랫폼은 기본 제공 기능으로 권한 부여 엔진을 제공합니다. OPA(Open Policy Agent)가 Rego라는 강력한 언어 기반으로 구축되었지만, 우리는 개발자와 고객에게 그 복잡성을 숨기고 싶었습니다. 당사 플랫폼의 모든 정책은 사용자(DevOps)가 Rego를 배울 필요 없이 훨씬 더 이해하기 쉽고 직관적인 정책 구조를 사용하여 정의할 수 있으므로 실수를 피할 수 있습니다. 인증 구성과 유사하게, 우리의 Golang 서비스 프레임워크는 Wingman의 권한 부여 엔진에 연결되어 권한 부여를 위해 Wingman을 자동으로 호출하고 개발자에게 권한 부여의 복잡성을 숨겼습니다.
인증을 위해 고유한 ID(Wingman을 사용하여 발급)를 사용하고, 승인을 위해 프로그래밍 가능한 정책 엔진(Wingman 내부)을 사용하면 mTLS를 사용하여 통신을 보호하고 견고하고 프로그래밍 가능한 정책을 사용하여 모든 액세스를 제어할 수 있습니다.
중앙집중형 금고 없이 비밀 관리
엔지니어들은 매일 코드에 키와 비밀번호를 저장하여 실수로 실수를 저지르고 그 코드가 어떻게든 공개 코드나 아티팩트 저장소로 유출되는지 알고 있습니다. 비밀을 관리하는 일은 어려운 일이며, 사용하기 쉬운 툴킷과 잘 정의된 프로세스가 없다면 개발자는 가장 짧은 경로로만 접근해야 합니다. 그 결과, 회사 창립 초기부터 플랫폼 보안(네트워크 및 앱 보안과 다름) 팀의 사명은 개발자가 "비밀을 어디에 저장해야 하나요? 소스 코드나 아티팩트 또는 ...?"와 같은 질문을 하지 않아도 되도록 하는 것이었습니다.
우리는 플랫폼 구축을 시작했을 때 비밀 관리를 위해 사용 가능한 두 가지 일반적인 접근 방식을 평가했으며, 두 접근 방식 모두 다음과 같은 단점이 있었습니다.
- Kubernetes Secrets — Kubernetes를 사용하고 있으며 Kubernetes에는 비밀 솔루션이 제공되지만 다양한 이유로 특별히 유용하지는 않습니다. 비밀은 저장 상태에서 암호화되지 않고 정책 구성이 포괄적이지 않으며 다중 클러스터 시나리오를 해결하지 못합니다.
- 중앙 집중식 볼트(예: Hashicorp 또는 Cyberark Vault) — 또 다른 접근 방식은 비밀을 중앙에 저장하고 권한이 있는 요청자에게 제공하는 볼트를 사용하는 것입니다. 비밀은 Vault의 암호화된 저장에 사용되는 단일 암호화 키로 보호됩니다. 그러나 이 접근 방식의 문제점은 비밀 관리 시스템이 일반 비밀(암호화된 형태로 저장된 경우에도)에 접근할 수 있으며 시스템이 손상되면 모든 비밀이 공개될 수 있다는 것입니다.
우리의 경우, SaaS 서비스로서, 우리는 고객의 비밀을 보호하기 위해 보다 강력한 방법을 고안해야 했습니다. 어떤 침해로 인해 고객의 비밀이 노출되어서는 안 되기 때문입니다.
결과적으로 우리는 Volterra Blindfold(상표)라고 부르는 새로운 기술을 구현하기로 결정했습니다. 이 기술은 그림 4에서 볼 수 있듯이 보안 사이드카인 Wingman과 함께 작동합니다. 이러한 접근 방식을 사용하면 비밀 소유자가 비밀을 잠그거나 암호화하여 원치 않는 당사자(복호화 서버 포함)에게 비밀이 명확하게 공개되지 않도록 할 수 있습니다. 비밀은 중앙 해독 서버에 저장되지도 않으며, 이러한 설계는 어떤 면에서 서버 설계를 극적으로 단순화합니다.
우리는 사용자에게 완전히 오프라인 환경에서 사용할 수 있는 눈가리개 도구를 제공하며, 이를 통해 비밀(S)을 암호화한 후 배포할 수 있습니다. 예를 들어, 비밀 자체를 워크로드와 함께 저장하고 레지스트리에 업로드할 수 있습니다. 이것이 달성되면 다음 단계를 거쳐야 합니다.
이를 통해 중앙 제어 평면이 비밀에 일반(S)으로 액세스할 수 없는 상황이 방지되고 비밀은 액세스 기간 동안 Pod의 런타임 메모리에서만 사용할 수 있습니다. 또한, 액세스 정책을 적용하여 비밀에 누가 접근할 수 있는지 정의할 수 있습니다. 정책은 애플리케이션 이름, 위치, 규정 준수 수준 등의 ID 속성을 기반으로 정의할 수 있습니다. 이런 식으로 복잡한 작업 부하의 하위 집합을 추출하고 정확한 액세스 제어를 달성할 수 있습니다. 이 정책은 암호화, 블라인딩, 복호화 및 블라인딩 해제 프로세스에 암호학적으로 짜여 있습니다. 즉, 정책의 의도를 무너뜨리는 것은 계산적으로 불가능합니다.
고유한 블라인드 기술을 사용해 각 비밀을 잠그고, 윙맨을 사용해 정책과 위조 불가능한 신원에 따라 각 비밀의 봉인을 해제함으로써 기존 솔루션의 문제점을 극복하고 분산 환경에서 비밀 관리를 제공할 수 있으며, 중앙의 금광이 손상될까 봐 전혀 걱정하지 않아도 됩니다.
분산 시스템을 위한 키 관리
비밀과 키 관리가 같은 문제를 다루는 두 가지 다른 이름처럼 들릴 수 있지만, 둘 사이에는 미묘한(하지만 실제로는 중요한) 차이가 있습니다. 이는 누구에게 묻느냐와 어떻게 솔루션을 구현하고 싶어하느냐에 따라 달라집니다.
비밀이란 비밀로 유지되어야 하며 허가받지 않은 당사자가 접근할 수 없는 정보를 말합니다. 어떤 면에서 암호화 키는 비밀의 특수한 사례입니다. 반면, 키 관리란 일반적으로 민감한 암호화 키 자료를 안전하게 저장하고 자료 사용을 제어하는 시스템을 말합니다. 어떤 경우에는 키 관리 시스템이 키의 원시 바이트를 승인된 당사자에게 배포하여 비밀 관리 시스템과 혼동될 수 있습니다. 그러나 대부분의 경우 키 관리 시스템은 키 자료의 원시 바이트를 실제로 배포하지 않고 대신 권한이 있는 요청자를 위해 작업을 수행하고 작업의 출력만 보냅니다. 많은 키 관리 시스템은 키 자료를 위한 하드웨어 스토리지(예: HSM)로 지원되므로 키가 소프트웨어에 명확하게 노출되는 일이 없습니다.
분산 환경에서는 단일 클라우드 공급자에게도 암호화 키를 관리, 동기화, 순환하는 문제는 매우 어렵고, 현재 솔루션은 오류가 발생하기 쉽고 비효율적이며 심지어 안전하지도 않습니다. 예를 들어, 현재 3개의 AWS 지역을 사용하고 3개 지역 모두에서 동일한 암호화 키를 사용하려면 키를 수동으로 동기화하고 순환해야 합니다. 해당 환경이 여러 클라우드 공급자(공공 및/또는 사설)에 걸쳐 있는 경우 문제는 더욱 심각해집니다. 이 모든 것이 끝나고도 애플리케이션 소유자는 여전히 KMS 기능을 활용하기 위해 복잡한 코드를 작성해야 합니다.
당사 플랫폼은 Wingman 사이드카가 모든 힘든 작업을 수행하고 암호화, 복호화, HMAC, HMAC 검증, 디지털 서명, 서명 검증, 키 가져오기(허용된 경우) 등의 키 관리 요청을 수행하기 위한 애플리케이션에 간단한 인터페이스를 제공함으로써 애플리케이션에서 키 관리의 모든 복잡성을 숨깁니다. 이를 통해 당사의 인프라 서비스와 고객 작업 부하에 대한 주요 관리가 전혀 어렵지 않게 되었습니다.
다음 다이어그램(그림 5)은 Volterra의 KMS가 여러 환경에서 어떻게 작동하는지 보여주고 워크로드가 키 관리 및 암호화 작업을 Wingman 사이드카로 오프로드하도록 돕습니다. 구성에 따라 Wingman은 애플리케이션이 알지 못하는 사이에 키를 캐시하고 캐시를 새로 고칠 수 있습니다. 여기서 가능케 하는 요소는 앞서 소개한 보편적이고 위조 불가능한 정체성입니다. 각 Pod는 위치에 관계없이 전역적으로 고유한 ID를 얻으므로 Volterra KMS 시스템은 암호 키와 암호화, 복호화, HMAC, HMAC 확인, 디지털 서명, 서명 검증과 같은 특정 작업에 대한 액세스 정책을 매우 정확한 방식으로 쉽게 적용할 수 있습니다.
모든 키가 Volterra의 SaaS 백엔드를 통해 관리되므로 이기종 환경에서 실행되는 작업 부하에서는 키 동기화, 회전, 해지 등을 처리할 필요가 없습니다. 모든 저장 데이터 보안 요구 사항에 대해 간단한 Wingman API만 알면 됩니다.
플랫폼 보안 솔루션이 제공하는 이점
다중 계층 플랫폼 보안을 사용하여 완전히 새로운 방식으로 세 가지 중요한 문제에 대한 포괄적인 솔루션을 제공할 수 있었습니다! 우리 시스템은 " 거북이가 바닥까지 내려오는 " 문제가 없는 범용 ID를 안전하게 부트스트랩하고, 골드마인 문제에 대해 걱정하지 않고도 저장하고 배포할 수 있는 비밀을 관리하고, 분산 환경에서 저장된 데이터의 보안을 용이하게 하는 키 관리를 제공할 수 있습니다. 이를 통해 내부 팀과 고객에게 다음과 같은 이점이 생겼습니다.
- 보안 및 규정 준수 - 위조 불가능하고 보편적인 신원, 블라인드, 보안 사이드카(윙맨)는 플랫폼에서 완벽하게 통합되어 자동으로 관리되어 모든 통신을 보호하고, 모든 액세스를 승인하고, 분산 시스템 전반에서 키/비밀을 관리합니다. 이러한 발전을 활용하여 당사와 고객이 규정을 준수하는 데 더 쉽게 활용할 수 있는 보다 강력한 보안 솔루션을 제공할 수 있게 되었습니다.
- 생산성 향상 - DevOps 프로세스 및 서비스 프레임워크에 통합된 보안 솔루션을 사용하면 개발자와 DevOps 팀이 애플리케이션 및 데이터 보안의 핵심 측면에 대해 걱정하지 않고도 결과물에 집중할 수 있습니다.
- 지속적인 진화 - 보안 환경의 변화와 새로운 기술은 Blindfold, Wingman 및 Golang 서비스 프레임워크의 지속적인 진화로 이어집니다. 그 결과, 애플리케이션 로직을 전혀 변경하지 않고도 플랫폼에서 새로운 기능이 자동으로 출시됩니다.
계속됩니다…
이 블로그 시리즈에서는 퍼블릭 클라우드, 프라이빗 네트워크 PoP 및 엣지 사이트의 많은 애플리케이션 클러스터를 활용하여 전 세계적으로 분산된 SaaS 서비스를 구축하고 운영하는 데 필요한 다양한 측면을 다룰 것입니다. 다음은 애플리케이션 및 네트워크 보안 입니다.
우리는 오픈 소스 프로젝트로 이 기능을 더 넓은 커뮤니티에 제공하는 데 도움을 줄 몇몇 자원봉사 개발자와 솔루션 아키텍트를 찾고 있습니다. 재밌는 일에 참여하고 싶은 분은 asingla@volterra.io 로 직접 연락해 주세요!