AWS 보안: IAM, KMS, SSM
"안전하게 액세스", "암호화된 데이터", "민감한 정보 관리" 같은 키워드가 나온다면, 오늘 다룰 세 가지 서비스, IAM, KMS, SSM Parameter Store가 정답일 확률이 매우 높습니다.
이 세 서비스는 AWS 보안의 근간을 이루며, 서로 유기적으로 연결되어 작동합니다.
1. IAM (Identity and Access Management) - "누가?" (The Gatekeeper)
IAM은 "누가(Identity) 무엇에(Resource) 접근(Access)할 수 있는지 관리(Management)"하는 서비스입니다. AWS의 모든 서비스에 대한 접근을 제어하는 "경비실" 또는 "출입증 관리소"라고 할 수 있습니다.
핵심 포인트
- User / Group: User는 실제 사람(개발자, 운영자)입니다. Group은 User의 집합입니다. SAA 모범 사례는 User를 Group에 소속시키고, Group에 권한(Policy)을 할당하는 것입니다.
- Policy (정책): "무엇을 할 수 있는지" 정의하는 JSON 문서입니다.
Allow또는Deny로 특정Action(예:s3:GetObject)을 특정Resource(예:my-bucket/*)에 대해 허용하거나 거부합니다. 최소 권한의 원칙(Least Privilege)이 항상 강조됩니다. - Role (역할): SAA 시험에서 가장 중요한 개념입니다. Role은 User가 아닌, AWS 서비스(예: EC2, Lambda)에 부여하는 임시 권한입니다.
SAA 문제 시나리오:
"EC2 인스턴스에서 S3 버킷에 로그를 업로드해야 합니다. 가장 안전한 방법은?"
- (X) 나쁜 답: Access Key를 생성해서 EC2 인스턴스 내의 설정 파일에 저장한다. (키 유출 시 대참사)
- (O) 정답: IAM Role을 생성하여 S3 쓰기 권한을 부여하고, 이 Role을 EC2 인스턴스에 연결한다.
2. KMS (Key Management Service) - "어떻게?" (The Key Maker)
KMS는 "데이터를 어떻게 암호화할 것인지", 즉 암호화 키를 생성하고 관리, 제어하는 서비스입니다. 우리가 직접 키를 보관하는 것이 아니라, KMS에게 "이 키로 암호화해줘", "이 키로 복호화해줘"라고 요청하는 방식입니다.
핵심 포인트
- CMK (Customer Master Key): 모든 것의 시작점입니다. 우리가 KMS에서 생성하고 제어하는 마스터 키입니다. 이 키 자체가 데이터를 직접 암호화하지 않습니다.
- Data Key (데이터 키): 실제 데이터를 암호화하는 키입니다.
- Envelope Encryption (봉투 암호화): SAA에서 KMS를 이해하는 핵심입니다
- 애플리케이션이 KMS에게 "데이터 암호화하게 데이터 키 좀 줘"라고 요청합니다.
- KMS는 (A)암호화되지 않은 데이터 키(Plaintext)와 (B)CMK로 암호화된 데이터 키(Encrypted), 두 개를 생성해서 돌려줍니다.
- 애플리케이션은 (A)로 실제 데이터를 암호화합니다.
- 애플리케이션은 (A)를 즉시 메모리에서 폐기합니다.
- 최종적으로 [암호화된 데이터]와 [(B)암호화된 데이터 키]를 함께 저장합니다.
복호화는 이 과정의 역순입니다. [(B)암호화된 데이터 키]를 KMS에 보내면, KMS가 CMK로 복호화하여 (A)를 돌려주고, 이 (A)로 [암호화된 데이터]를 복호화합니다.
SAA 문제 시나리오:
"S3에 저장된 데이터를 암호화해야 하며, 키에 대한 접근을 감사(Audit)하고 키 교체(Rotation)를 관리해야 합니다."
- 정답: SSE-KMS를 사용합니다. (Server-Side Encryption with KMS). S3가 KMS에게 키를 요청하여 위 봉투 암호화 과정을 수행합니다. EBS 볼륨, RDS 데이터베이스 암호화에도 동일하게 사용됩니다.
3. SSM Parameter Store - "무엇을?" (The Secret Vault)
SSM Parameter Store는 설정 값이나 민감한 정보(비밀번호, API 키)를 안전하게 저장하는 "중앙 설정 관리소"입니다.
핵심 포인트
-
단순 설정 값 저장:
Parameter에/prod/logging-level같은 일반 설정 값을 저장할 수 있습니다. -
비밀번호 등 민감 정보 저장 (SecureString):
- 이것이 핵심입니다. 파라미터를
SecureString타입으로 생성하면, Parameter Store는 KMS와 자동으로 통합되어 해당 값을 암호화해서 저장합니다. - 즉, DB 비밀번호 같은 민감 정보를 소스 코드나 설정 파일에 하드코딩할 필요가 전혀 없습니다.
- 이것이 핵심입니다. 파라미터를
-
IAM과의 연동: EC2나 Lambda가 이 파라미터 값을 읽어오려면, IAM Role에
ssm:GetParameter권한이 있어야 합니다.
SAA 문제 시나리오 :
"애플리케이션이 DB에 연결해야 합니다. DB 자격 증명(password)을 가장 안전하게 관리하고 애플리케이션에 전달하는 방법은?"
- 정답:
- DB 비밀번호를 SSM Parameter Store에
SecureString타입으로 저장합니다. (이때 KMS 키로 암호화됩니다.) - 애플리케이션이 실행되는 EC2 인스턴스에 IAM Role을 부여합니다.
- 이 IAM Role에는 해당 Parameter Store 경로에 대한
ssm:GetParameter권한과, 암호화에 사용된kms:Decrypt권한이 있어야 합니다. - 애플리케이션은 시작 시 AWS SDK를 통해 SSM에서 비밀번호를 안전하게 가져와 메모리에 로드합니다.
- DB 비밀번호를 SSM Parameter Store에
참고: "비밀번호 자동 교체" 기능이 언급된다면 AWS Secrets Manager가 정답입니다. Parameter Store는 자동 교체 기능이 없습니다. 이 차이점을 꼭 기억.
정리
- IAM Role (권한)을 가진 EC2/Lambda가
- SSM Parameter Store (비밀번호 보관소)에 DB 비밀번호를 요청합니다.
- SSM은 이 비밀번호가 KMS (암호화 키)로 암호화되어 있으므로, KMS에게 복호화를 요청하여
- EC2/Lambda에 안전하게 비밀번호를 전달합니다.
