AWS 기술 블로그
중앙 집중식 및 분산형 비밀 관리 방식 알아보기
이 글은 AWS Security 블로그에게시된 글 (Exploring common centralized and decentralized approaches to secrets management)을 한국어로 번역 및 편집하였습니다.
Amazon Web Services (AWS)의 비밀 관리 전략에 관한 흔한 질문 중 하나는 조직이 비밀을 중앙 집중화해야 하는지입니다. 이 질문은 비밀을 중앙에 저장해야 하는지에 초점을 맞추는 경우가 많지만, 비밀 관리 프로세스를 중앙 집중화할 때 네 가지 측면인 생성, 저장, 교체 그리고 모니터링을 고려해야 합니다. 이 글에서는 비밀 관리의 각 측면을 중앙 집중화하거나 분산화할 때의 장단점에 대해 논의합니다.
비밀의 중앙 집중식 생성
비밀 생성을 중앙화할지 결정할 때는 클라우드에서 인프라를 배포하는 기존 방식을 고려해야 합니다. 현대적인 DevOps 관행은 일부 조직에서 인프라 배포를 위한 골든 패스(golden path)를 사용하는 개발자 포털 및 내부 개발자 플랫폼을 구축하도록 이끌었습니다. 골든 패스를 사용하는 도구를 통해 개발자는 조직 표준을 준수하면서 IaC(Infrastructure as Code)를 통해 셀프서비스 모델로 인프라를 배포할 수 있습니다.
플랫폼 엔지니어링 팀과 같은 중앙 조직이 이러한 골든 패스를 유지 관리합니다. 골든 패스를 유지하고 정의하는 데 사용할 수 있는 서비스의 예로는 AWS Service Catalog와 같은 AWS 서비스나 Backstage.io와 같은 인기 있는 오픈 소스 프로젝트가 있습니다. 이러한 접근 방식을 사용하면 개발자는 애플리케이션 코드에 집중할 수 있고, 플랫폼 엔지니어는 인프라 배포, 보안 제어 그리고 개발자 도구에 집중할 수 있습니다. 골든 패스의 예로는 데이터베이스에 쓰기 작업을 수행하는 마이크로서비스를 위한 템플릿화된 구현을 들 수 있습니다.
예를 들어, 골든 패스는 서비스나 애플리케이션이 AWS Cloud Development Kit (AWS CDK)를 사용하여 구축되고, Amazon Elastic Container Service (Amazon ECS)에서 실행되며, AWS Secrets Manager를 사용하여 데이터베이스 자격 증명을 검색하도록 정의할 수 있습니다. 플랫폼 팀은 비밀의 리소스 정책이 마이크로서비스에서 사용하는 역할에만 액세스를 허용하고 고객 관리형 키로 암호화되도록 보장하는 검사를 구축할 수도 있습니다. 이 패턴은 개발자로부터 배포 과정을 추상화하고 계정 간 리소스 배포를 용이하게 합니다. 이것은 그림 1에 표시된 중앙 집중식 생성 패턴의 한 예입니다.
그림 1: 중앙 집중식 생성을 위한 개발자 포털 배포 패턴 아키텍처 다이어그램
이 접근 방식의 장점은 다음과 같습니다.
- 일관된 명명, 태깅 및 액세스 제어: 비밀이 중앙에서 생성되면 계정, 워크로드, 서비스 또는 데이터 분류를 기반으로 표준 명명 규칙을 적용할 수 있습니다. 이를 통해 속성 기반 액세스 제어(ABAC)와 같은 확장 가능한 패턴을 구현하기가 간편해집니다.
- CI/CD 파이프라인의 최소 권한 검사: IaC 파이프라인 내에서 비밀을 생성할 때 AWS IAM Access Analyzer check-no-new-access API와 같은 API를 사용할 수 있습니다. 배포 파이프라인을 템플릿화할 수 있으므로 개별 팀은 배포 파이프라인을 소유하면서도 조직 표준을 활용할 수 있습니다.
- 플랫폼 엔지니어링 팀과 보안 팀 간 협업 메커니즘 구축: 종종 골든 패스와 서비스 카탈로그로의 전환은 더 나은 개발자 경험과 운영 오버헤드 감소에 대한 요구에 의해 추진됩니다. 이러한 전환의 부산물로 보안 팀은 플랫폼 엔지니어링 팀과 협력하여 이러한 경로에 기본적으로 보안을 구축할 수 있습니다. 이러한 조치의 부수적 효과는 보안 팀이 플랫폼 엔지니어링 팀과 협력하여 이러한 경로에 기본적으로 보안을 구축할 수 있다는 점입니다.
이 접근 방식의 트레이드오프는 다음과 같습니다.
- 이러한 전환에는 시간과 노력이 필요합니다: 풀타임 플랫폼 엔지니어링 또는 DevOps 팀에 투자할 리소스가 없을 수 있습니다. 이와 같이 소프트웨어와 인프라를 중앙에서 프로비저닝하려면 조직의 사용 사례에 적합한 골든 패스 라이브러리를 유지 관리해야 합니다. 조직의 규모에 따라 이것이 실현 가능하지 않을 수 있습니다.
- 골든 패스는 지원하는 서비스의 기능을 따라잡아야 합니다: 이 패턴을 사용하고 있고 의존하는 서비스에서 새로운 기능이 출시되면, 개발자는 해당 기능이 영향을 받는 골든 패스에 추가될 때까지 기다려야 합니다.
내부 개발자 플랫폼 패턴에 대해 자세히 알아보려면 re:Invent 2024 세션인 Elevating the developer experience with Backstage on AWS를 확인하세요.
비밀의 분산형 생성
분산형 모델에서는 애플리케이션 팀이 자체 계정에서 IaC 템플릿과 배포 메커니즘을 소유합니다. 여기서 각 팀은 독립적으로 운영되므로 표준을 코드로 적용하기가 더 어려울 수 있습니다. 그림 2에 표시된 이 패턴을 분산형 생성 패턴이라고 하겠습니다.
그림 2: 비밀의 분산형 생성
이 접근 방식의 장점은 다음과 같습니다.
- 속도: 개발자는 생성 프로세스를 소유하므로 빠르게 움직이고 더 많은 자율성을 가질 수 있습니다. 개별 팀은 중앙 조직에 대한 의존성이 없습니다.
- 유연성: IAM Access Analyzer check-no-new-access API와 같은 기능을 여전히 사용할 수 있지만, 각 팀이 파이프라인에 이를 구현하는 것은 각 팀의 몫입니다.
이 접근 방식의 트레이드오프는 다음과 같습니다.
- 표준화 부족: 중앙 생성 메커니즘을 통해 템플릿화되고 적용되지 않기 때문에 명명 및 태깅 규칙을 적용하기가 더 어려워질 수 있습니다. 액세스 제어 및 리소스 정책이 팀 간에 일관되지 않을 수 있습니다.
- 개발자의 주의 분산: 개발자는 기본 인프라와 배포 파이프라인을 더 많이 관리해야 합니다.
비밀의 중앙 집중식 저장
일부 고객은 비밀을 중앙 계정에 저장하기로 선택하고, 다른 고객은 워크로드가 있는 계정에 비밀을 저장하기로 선택합니다. 그림 3은 비밀의 중앙 집중식 저장 아키텍처를 보여줍니다.
그림 3: 비밀의 중앙 집중식 저장
비밀의 중앙 집중식 저장 장점은 다음과 같습니다.
- 간소화된 모니터링 및 관찰성: 비밀을 단일 계정에 보관하고 중앙 팀이 제어하면 비밀 모니터링을 간소화할 수 있습니다.
비밀의 중앙 집중식 저장 트레이드오프는 다음과 같습니다.
- 추가적인 운영 오버헤드: 계정 간에 비밀을 공유할 때 공유되는 각 비밀에 대해 리소스 정책을 구성해야 합니다.
- AWS KMS 고객 관리형 키의 추가 비용: 계정 간에 비밀을 공유할 때는 AWS Key Management Service(AWS KMS) 고객 관리형 키를 사용해야 합니다. 이를 통해 비밀 액세스에 대한 추가 액세스 제어 계층을 얻을 수 있지만, AWS KMS 요금제에 따라 비용 이 증가합니다. 또한 생성하고 유지 관리해야 하는 정책이 추가됩니다.
- 민감한 데이터의 높은 집중도: 중앙 계정에 비밀을 보관하면 실수로 인한 액세스나 잘못된 구성이 발생할 경우 영향을 받는 리소스의 수가 증가할 수 있습니다.
- 계정 할당량: 중앙 집중식 비밀 계정을 결정하기 전에 AWS 서비스 할당량을 검토 하여 프로덕션 환경에서 할당량에 도달하지 않는지 확인이 필요합니다.
- 서비스 관리형 비밀: Amazon Relational Database Service(Amazon RDS) 또는 Amazon Redshift와 같은 서비스가 사용자를 대신하여 비밀을 관리하는 경우, 이러한 비밀은 비밀과 연결된 리소스와 동일한 계정에 배치됩니다. 서비스 관리형 비밀을 사용하면서 중앙 집중식 비밀 저장을 유지하려면 리소스도 중앙 집중화해야 합니다.
모니터링 및 관찰성을 위해 비밀을 중앙화하는 것에는 장점이 있지만, 많은 고객이 이미 AWS Security Hub, IAM Access Analyzer, AWS Config, Amazon CloudWatch와 같은 서비스를 사용하여 교차 계정 간 관찰성을 확보하고 있습니다. 이러한 서비스를 사용하면 멀티 계정 환경에서 비밀에 대한 중앙 집중식 뷰를 더 쉽게 생성할 수 있습니다.
비밀의 분산형 저장
그림 4에 표시된 분산형 저장 접근 방식에서는 비밀이 액세스가 필요한 워크로드와 동일한 계정에 존재합니다.
그림 4: 비밀의 분산형 저장
비밀의 분산형 저장 장점은 다음과 같습니다.
- 계정 경계 및 논리적 분리: 계정 경계는 AWS에서 워크로드 간의 자연스러운 분리를 제공합니다. 분산된 멀티 계정 환경에서 운영할 때 기본적으로 다른 계정의 비밀에 액세스할 수 없으며, 모든 교차 계정 간 액세스는 소스 계정의 리소스 정책과 대상 계정의 IAM 정책 모두에서 허용되어야 합니다. 리소스 제어 정책을 사용하여 계정 간 비밀 공유를 방지할 수 있습니다.
- AWS KMS 키 선택: 비밀이 계정 간에 공유되지 않는 경우 AWS KMS 고객 관리형 키 또는 AWS 관리형 키를 사용하여 비밀을 암호화할 수 있습니다.
- 애플리케이션 소유자에게 권한 관리 위임: 비밀이 이를 사용해야 하는 애플리케이션과 동일한 계정에 저장되면 애플리케이션 소유자가 비밀 리소스 정책에서 세분화된 권한을 정의합니다.
비밀의 분산형 저장 트레이드오프는 다음과 같습니다.
- 감사 및 모니터링에는 교차 계정 간 배포가 필요합니다: 비밀의 규정 준수 및 상태를 모니터링하는 데 사용되는 도구는 여러 계정에서 작동하고 단일 위치에 정보를 표시해야 합니다. 이는 이 글의 뒷부분에서 설명하는 AWS 네이티브 도구를 통해 간소화됩니다.
- 자동화된 복구 워크플로: 비밀과 관련된 잘못된 구성이나 보안 위험에 대해 경고하는 탐지 제어를 마련할 수 있습니다. 예를 들어, 리소스 정책을 통해 비밀이 조직 경계 외부로 공유될 때 경고를 표시할 수 있습니다. 이러한 워크플로는 멀티 계정 환경에서 더 복잡할 수 있습니다. 그러나 Automated Security Response on AWS 솔루션과 같이 도움이 될 수 있는 샘플이 있습니다.
중앙 집중식 교체
비밀의 생성 및 저장과 마찬가지로 조직은 비밀의 수명 주기 관리 및 교체를 중앙화하는 데 다양한 접근 방식을 취합니다.
그림 5에 표시된 것처럼 수명 주기 관리를 중앙화하면 중앙 팀이 교체를 위한 AWS Lambda 함수를 관리하고 소유합니다. 비밀의 수명 주기 관리를 중앙화하는 것의 장점은 다음과 같습니다.
- 개발자가 교체 함수를 재사용할 수 있습니다: 이 패턴에서 중앙 팀은 다양한 사용 사례를 위한 교체 함수의 공통 라이브러리를 유지 관리합니다. 이에 대한 예는 이 AWS re:Inforce 세션에서 확인할 수 있습니다. 이 방법을 사용하면 애플리케이션 팀은 자체 커스텀 교체 함수를 구축할 필요가 없으며, 데이터베이스 및 타사 소프트웨어 SaaS(Software as a Service) 애플리케이션에 관한 공통 아키텍처 결정의 이점을 누릴 수 있습니다.
- 로깅: 교체 함수 로그를 저장하고 액세스할 때 중앙 집중식 패턴은 단일 위치에서 로그를 관리하는 것을 간소화할 수 있습니다.
그림 5: 비밀의 중앙 집중식 교체
비밀의 수명 주기 관리의 트레이드오프는 다음과 같습니다.
- 추가적인 교차 계정 간 액세스 시나리오: 수명 주기 관리를 중앙화할 때 중앙 계정의 Lambda 함수는 애플리케이션 계정에서 비밀을 생성, 업데이트, 삭제 및 읽을 수 있는 권한이 필요합니다. 이는 비밀 교체를 활성화하는 데 필요한 운영 오버헤드를 증가시킵니다.
- 서비스 할당량: 대규모로 함수를 중앙화할 때 서비스 할당량이 문제가 될 수 있습니다. Lambda 서비스 할당량을 확인하여 프로덕션 환경에서 할당량에 도달하지 않는지 확인하세요.
분산형 교체
그림 6에 표시된 것처럼 교체 함수가 연결된 비밀과 동일한 계정에 존재하는 비밀 수명 주기 관리의 분산화가 더 일반적인 선택입니다.
그림 6: 비밀의 분산형 교체
비밀 수명 주기 관리를 분산화하는 것의 장점은 다음과 같습니다.
- 템플릿화 및 커스터마이징: 개발자는 교체 템플릿을 재사용할 수 있지만 필요에 따라 함수를 조정하여 자신의 요구 사항과 사용 사례를 충족할 수 있습니다.
- 교차 계정 간 액세스 불필요: 비밀의 분산형 교체는 모두 하나의 계정에서 발생하며 교차 계정 간 액세스가 필요하지 않습니다.
교체를 분산화하는 것의 주요 트레이드오프는 다른 계정의 교체 함수에 대한 로그에 중앙 집중식 또는 연합 액세스를 제공해야 한다는 것입니다. 기본적으로 Lambda는 모든 함수 호출에 대한 로그를 자동으로 캡처하여 CloudWatch Logs로 전송합니다. CloudWatch Logs는 로그를 중앙화할 수 있는 몇 가지 방법을 제공하며, 각 방법의 고려사항은 문서에 설명되어 있습니다.
비밀의 중앙 집중식 감사 및 모니터링
비밀의 생성, 저장 및 교체를 위해 선택한 모델에 관계없이 멀티 계정 환경에서 운영할 때는 규정 준수 및 감사 측면을 중앙화 해야합니다. AWS Organizations와의 통합을 통해 AWS Security Hub CSPM을 사용하여 다음을 중앙화할 수 있습니다.
- Secrets Manager와 관련된 AWS Foundational Security Best Practices 조사 결과
- Secrets Manager 비밀에 대한 외부 액세스와 관련된 IAM Access Analyzer 조사 결과
- Secrets Manager 비밀과 관련된 AWS Config 조사 결과
- 비밀에 대한 Amazon GuardDuty 이상 행동 조사 결과
그림 7에 표시된 이 시나리오에서 중앙 집중식 기능은 조직 전체에 대한 가시성을 확보하고 개별 팀은 전체 조직의 상태를 확인할 필요 없이 계정 수준에서 자신의 보안 상태를 확인할 수 있습니다.
AWS CloudTrail 조직 추적을 사용하여 Secrets Manager에 대한 모든 API 호출을 중앙 집중식 위임 관리자 계정으로 전송할 수 있습니다.
그림 7: 중앙 집중식 모니터링 및 감사
비밀의 분산형 감사 및 모니터링
비밀의 중앙 집중식 감사 및 모니터링이 필요하지 않은 조직의 경우, 개별 팀이 비밀과 관련하여 수집할 로그, 활성화할 경고 및 적용할 검사를 결정할 수 있도록 액세스를 구성할 수 있습니다. 이 접근 방식의 장점은 다음과 같습니다.
- 유연성: 개발 팀은 자신에게 가장 적합한 모니터링, 감사 및 로깅 도구를 자유롭게 선택할 수 있습니다.
- 의존성 감소: 개발 팀은 경고 및 모니터링 기능을 위해 중앙 집중식 기능에 의존할 필요가 없습니다.
이 접근 방식의 트레이드오프는 다음과 같습니다.
- 운영 오버헤드: 유사한 목표를 달성하려는 팀에게 중복 작업이 발생할 수 있습니다.
- 교차 계정 간 조사에서 로그 집계의 어려움: 로그, 경고 및 모니터링 기능이 분산되어 있으면 여러 계정에 영향을 미치는 이벤트를 조사하는 것이 더 어려워질 수 있습니다.
통합 구성
대부분의 조직은 자신의 요구 사항을 충족하기 위해 이러한 접근 방식을 조합하여 선택합니다. 예를 들어 중앙 보안 팀이 있고 수백 개의 AWS 계정에서 운영되며 계정 수준에서 격리된 수백 개의 애플리케이션을 보유한 금융 서비스 회사가 있습니다. 이 고객은 다음과 같이 할 수 있습니다.
- 생성 프로세스를 중앙화하여 명명, 태깅 및 액세스 제어에 대한 조직 표준을 적용
- 비밀 저장을 분산화하여 AWS 계정을 액세스의 자연스러운 경계로 사용하고 워크로드가 운영되는 계정에 비밀을 저장하여 애플리케이션 소유자에게 제어권을 위임
- 수명 주기 관리를 분산화하여 애플리케이션 소유자가 자체 교체 함수를 관리할 수 있도록 함
- 감사를 중앙화하여 AWS Config, Security Hub, IAM Access Analyzer와 같은 도구를 사용하여 중앙 보안 팀이 비밀의 보안 상태에 대한 인사이트를 얻을 수 있도록 하면서 애플리케이션 소유자가 제어권을 유지하도록 함
결론
이 글에서는 AWS에서 비밀 관리를 구현할 때 조직이 직면하는 아키텍처 결정인 생성, 저장, 교체 및 모니터링을 살펴보았습니다. 중앙집중식이든 분산형이든 각 접근 방식은 조직의 보안 요구 사항, 운영 모델 및 규모에 부합해야 하는 고유한 장점과 트레이드오프를 제공합니다. 중요한 사항은 다음과 같습니다.
- 조직의 특정 요구 사항과 역량에 따라 비밀 관리 아키텍처를 선택하세요. 모든 상황에 맞는 단일 솔루션은 없습니다.
- 접근 방식에 관계없이 자동화 및 IaC를 사용하여 일관된 보안 제어를 적용하세요.
- AWS 서비스를 통해 포괄적인 모니터링 및 감사 기능을 구현하여 환경 전반에 대한 가시성을 유지하세요.
리소스
AWS Secrets Manager에 대해 자세히 알아보려면 다음 리소스를 확인하세요.