아키텍처의 기초는 독립적인 지역 클러스터가 주권을 유지하면서 글로벌 제어 평면에 참여하는 셀 기반 토폴로지에 있습니다. 각 지역 셀은 HashiCorp Vault 클러스터를 배포하며, Raft 합의 메커니즘을 사용하여 로컬 상태 머신 복제를 수행하고, Thales Luna 또는 AWS CloudHSM과 같은 FIPS 140-2 레벨 3 인증된 HSM 모듈로 뒷받침됩니다. 지역 간 메타데이터 동기화는 궁극적으로 일관된 서비스 검색을 위해 CRDT(Conflict-free Replicated Data Type)를 기반으로 한 갈등이 없는 복제 데이터 유형을 사용하며, 민감한 암호화 작업은 키 자재의 유출을 방지하기 위해 엄격하게 로컬에서 수행됩니다.
동적 자격 증명 회전은 각 컴퓨트 노드에 배포된 SPIRE 에이전트와 함께 SPIFFE(Secure Production Identity Framework For Everyone)를 통합하여 정적 비밀을 제거합니다. 워크로드는 Node 및 Workload attestor에 의해 증명된 암호화된 신원에 바인딩된 단기 JWT 토큰을 통해 인증되며, 이는 컨테이너 재시작이나 구성 재로드 없이 자동 회전을 가능하게 합니다. 이 메커니즘은 비밀의 생명 주기를 며칠에서 몇 분으로 줄여 잠재적인 유출의 폭발 범위를 근본적으로 제한합니다.
즉각적인 철회 전파는 지역 클러스터 간의 gRPC 양방향 스트리밍 연결 위에 SWIM(Scalable Weakly-consistent Infection-style Process Group Membership) 프로토콜을 겹쳐서 작동합니다. 보안 사건이 철회를 촉발할 때, 출처는 메시를 통해 루머를 퍼뜨리며 수백 개의 노드에서 중앙 집중식 조정 병목 현상 없이 수 초 이내에 수렴을 달성합니다. 이 접근법은 클러스터 크기에 따른 선형 오버헤드를 부과하는 전통적인 하트비트 기반 시스템과 대조적입니다.
준수 및 키 세리머니 절차는 클러스터 초기화 또는 재해 복구 중 마스터 키를 재구성하기 위해 여러 운영자가 필요한 Shamir's Secret Sharing을 구현합니다. HSM 클러스터는 엄격한 물리적 및 논리적 보안 경계를 유지하여 암호화되지 않은 개인 키가 하드웨어 경계 외부의 애플리케이션 메모리나 영구 저장소에 존재하지 않도록 보장합니다. 정기적인 키 회전 세리머니는 HSM 경계 내에서 새로운 키 쌍을 생성하기 위해 PKCS#11 작업을 이용하여 소재가 호스트 운영 체제에 노출되지 않도록 합니다.
글로벌 결제 처리기에서의 중요한 침해 대응 중, 하드코딩된 정적 AWS IAM 자격 증명이 Terraform 상태 파일에서 유출되어 공격자에게 3개 대륙의 프로덕션 데이터베이스에 지속적으로 접근할 수 있는 권한을 부여했습니다. 즉각적인 도전 과제는 작업 부하 메쉬에서 연쇄 실패를 유발하지 않으면서 수천 개의 데이터베이스 비밀번호를 동시에 회전시키는 것이었으며, 철회된 자격 증명이 네트워크 분할을 경험하는 지역에서도 즉시 사용 불가능하게 만드는 것이었습니다.
첫 번째 해결책은 기본 AWS 지역에 PostgreSQL 백엔드를 가진 중앙 집중식 HashiCorp Vault 배포를 구현하는 것이었습니다. 이는 CloudWatch Events에 의해 트리거된 Lambda 함수를 이용한 자동 회전을 활용하여 강력한 일관성 보장을 제공하고 감사 로그를 단순화할 수 있었습니다. 하지만 이 접근법은 재앙적인 단일 실패 지점을 도입했습니다. 지역 정전이 발생하면 비밀이 전 세계적으로 접근할 수 없게 되어 99.999% 가용성 SLA를 위반하게 되었습니다. 또한 비밀 검색을 위한 지역 간 대기 시간이 지속적으로 300ms를 초과하여 결제 승인 워크플로우의 100ms 이하 요구 사항을 충족하지 못했습니다.
두 번째 해결책은 연합 제어 평면과 OAuth 2.0 신원 브리징이 있는 클라우드 네이티브 비밀 관리자를 채택하는 것이었습니다 (Secrets Manager, Azure Key Vault, GCP Secret Manager). 이는 뛰어난 지역 가용성과 네이티브 준수 인증을 제공했지만, 허용할 수 없는 공급업체 잠금을 초래하고 클라우드 간 비동기 복제 지연으로 인해 즉각적인 글로벌 철회를 원천적으로 차단했습니다(1-5분). 이기종 환경 간 통합 감사 추적 부재는 또한 PCI DSS 1단계 준수 요건을 복잡하게 하였으며, 포렌식 분석을 위한 진실의 단일 소스를 보장할 수 없었습니다.
세 번째 해결책은 지역 Vault 클러스터에 대해 Raft 합의, SPIFFE/SPIRE 암호화 워크로드 신원, 그리고 gRPC 양방향 스트림을 통한 사용자 정의 전파 철회 프로토콜을 사용하는 셀 기반 토폴로지를 설계했습니다. 이 설계는 독립적으로 운영할 수 있는 지역 셀과 증거 전파를 수 초 이내에 달성하는 보안을 균형 있게 유지할 수 있었습니다. 우리는 이 접근 방식을 선택했는데, 이는 운영의 복잡성에도 불구하고 유일하게 다운타임이 없는 회전 요구 사항을 충족하고 FIPS 140-2 레벨 3 준수를 위해 AWS CloudHSM에 의한 하드웨어 지원 키 관리를 제공했기 때문입니다.
구현 이후, 인프라는 자격 증명 노출 시간을 4시간에서 5초 미만으로 줄였으며, 서비스 저하 없이 us-east-1의 완전한 지역 정전을 성공적으로 견디고 PCI DSS 감사를 통과하여 비밀 관리에 대한 보상 조치를 요구하지 않았습니다.
네트워크 분할 중 비밀 관리에서 CAP 정리가 어떻게 구체적으로 나타나는가? 왜 모든 비밀 작업에 대해 단순히 최종 일관성을 사용할 수 없는가?
분할되는 동안 시스템은 가용성과 일관성 중에서 선택해야 합니다. 비밀 회전 작업의 경우 CP(일관성 우선 가용성) 를 우선시합니다. 왜냐하면 손상 시 이전의 암호화 키를 제공하는 것은 되돌릴 수 없는 보안 노출을 초래하기 때문입니다. 그러나 비철회된 비밀의 읽기 작업에는 AP(가용성 우선 일관성) 동작을 수용할 수 있습니다. 핵심 구분점은 메타데이터 제어 평면(일관성이 있어야 하는)과 데이터 평면 검색(비철회된 유효 비밀을 위해 기간의 내구성을 수용할 수 있는)을 분리하는 것입니다. 지원자들은 종종 모든 비밀 작업이 즉각적인 일관성이 요구된다고 잘못 추정하며, 읽기 복제본이 제한된 노후로 95%의 트래픽을 처리할 수 있다는 미묘함을 놓치며, 철회 확인은 항상 합의 레이어에 도달해야 합니다.
비밀 회전에서 "천둥의 소떼" 문제란 무엇인가? 지수 백오프 및 지터가 대규모에서 이를 해결하는 데 실패하는 이유는 무엇인가?
수천 개의 포드에서 인증서가 동시에 만료될 때(예: UTC 자정), 동시 새로 고침 요청이 Vault 클러스터를 압도합니다. 간단한 지수 후퇴와 완전 지터는 여전히 서로 연관된 재시도 폭풍을 생성합니다. 왜냐하면 Kubernetes 컨트롤러가 종종 포드를 동시에 재시작하기 때문입니다. 해결책은 클라이언트 측에서 Token Bucket 속도 제한을 구현하고 만료 전 6시간 동안 단일 슬로우 알고리즘을 사용하여 갱신 창을 시간 범위에 분배하는 것입니다. 또한 Cubbyhole 인증을 사용하여 응답 랩핑은 임시 토큰을 로컬에 캐시하여 인증 부하를 80% 줄입니다. 지원자들은 클라이언트 측 협력이 필수적임을 놓치며, 서버 측 속도 제한만으로는 연쇄 실패를 초래합니다.
왜 상호 TLS(mTLS)는 제로 신뢰 비밀 관리에서 워크로드 인증에 불충분하며 추가적인 증명 메커니즘이 필요한가?
mTLS는 워크로드가 유효한 인증서를 보유하고 있음을 검증하지만, 워크로드 자체가 배포 이후 손상되지 않았는지 또는 인증서가 손상된 노드에서 유출되지 않았는지 여부를 입증하지 못합니다. 우리는 Kubernetes 노드 신원을 검증하기 위한 Service Account 프로젝션과 포드 레이블 및 이미지 다이제스트를 검증하기 위한 Admission Controllers를 통해 SPIFFE를 구현해야 합니다. 또한 비밀을 특정 하드웨어 인스턴스에 연결하기 위해 TPM(신뢰할 수 있는 플랫폼 모듈) 측정에 바인딩하여 암호화된 자료를 해당 하드웨어에 결합해야 합니다. 지원자들은 전송 보안을 신원 인증과 혼동하며, 비밀 관리에는 요청자의 런타임 상태에 대한 지속적인 검증이 필요함을 놓칩니다.