AWS KMS

디스크, 객체, 데이터베이스를 암호화해야 하는데 키를 파일이나 환경변수로 흩어 놓으면 회전과 접근 감사가 곧 수작업이 됩니다. 데이터는 암호화돼 있어도 키 운영이 허술하면 보호가 오래 가지 않습니다.

암호화 키를 애플리케이션 코드나 설정 파일에 평문으로 두면 Git 이력, 로그, 백업 어디서든 키가 유출될 수 있습니다. 실제로 키가 하드코딩된 채 레포지토리에 올라가 대규모 데이터 유출로 이어진 사고가 반복되었고, 규정 준수 감사에서 키 회전 이력과 접근 기록을 제출하지 못해 실패하는 사례도 흔했습니다. 서비스가 늘어날수록 키마다 누가 쓸 수 있는지, 언제 회전했는지, 폐기는 어떻게 하는지를 각 팀이 따로 관리하는 것은 현실적으로 불가능해졌습니다. 이 운영 부담을 해결하기 위해 클라우드 전체 자원이 공통으로 쓸 수 있는 중앙 키 관리 계층인 KMS가 등장했습니다.

KMS는 고객 관리 키와 정책, 권한 부여를 관리하고 다른 AWS 서비스가 이 키를 사용해 암호화하도록 연결합니다. 키는 HSM(키를 물리적으로 격리된 하드웨어 장치에 보관하는 보안 모듈) 기반으로 보호되어 소프트웨어 수준의 침해에도 키 자체는 노출되지 않습니다. 누가 어떤 키를 언제 사용했는지 CloudTrail에 남겨 감사 흐름까지 이어집니다.

IAM과 KMS는 둘 다 리소스 접근을 통제하는 보안 계층이지만, 통제하는 대상이 다릅니다. IAM은 "이 사용자가 이 S3 버킷에 접근할 수 있는가"처럼 작업 수행 권한을 정하고, KMS는 "이 S3 객체를 어떤 키로 암호화하고 누가 복호화할 수 있는가"처럼 데이터 자체의 암호화 정책을 정합니다. 판단 기준은 이렇습니다. API 호출이 허용되는지 거부되는지가 문제면 IAM 정책을 봐야 하고, 저장된 데이터가 유출되더라도 읽을 수 없게 보호하는 것이 문제면 KMS 키 정책을 봐야 합니다. 실무에서는 IAM으로 접근 권한을 제한하면서 동시에 KMS로 데이터를 암호화해 이중 방어를 구성하는 경우가 많습니다.

S3 버킷에 서버 사이드 암호화를 걸 때 KMS 키를 지정하면, 객체가 저장될 때 자동으로 암호화되고 권한이 있는 요청에만 복호화됩니다. EBS 볼륨을 생성할 때 KMS 키를 선택하면 디스크 전체가 암호화되어 스냅샷이 유출되더라도 키 없이는 읽을 수 없습니다. RDS 인스턴스도 생성 시 KMS 암호화를 켜면 저장 데이터, 자동 백업, Read Replica까지 같은 키 정책으로 보호됩니다. 규정 준수 감사에서 "이 키를 누가 언제 사용했는가"를 증명해야 할 때, CloudTrail에 남는 KMS API 호출 기록이 근거가 됩니다. 자동 키 순환을 켜두면 연 단위로 키가 교체되면서도 이전 키로 암호화된 데이터는 여전히 복호화할 수 있습니다. 누가 어떤 리소스에 접근 가능한지 자체를 결정하는 계층은 아닙니다.