국내 보안 인증 제도와 Amazon DynamoDB — 활용 적합성 분석

1. 관계형 데이터베이스와 다른 심사 쟁점

앞서 다룬 국내 보안 인증 제도와 Amazon S3 편과 달리, Amazon DynamoDB는 개인정보와 거래 기록이 구조화된 형태로 상시 조회·변경되는 저장소입니다. 그 결과 심사에서 확인하는 항목의 성격이 달라집니다.

국내 인증 심사와 금융권 점검은 전통적으로 관계형 데이터베이스를 전제로 설계되어 있습니다. 데이터베이스 접근통제 솔루션을 경유한 질의 감사, 데이터베이스 암호화 제품을 통한 컬럼 암호화, 데이터베이스 계정과 애플리케이션 계정의 분리가 대표적입니다. DynamoDB는 이 전제와 맞지 않는 지점이 존재하므로, 동일한 통제 목적을 다른 수단으로 달성했음을 설명할 수 있어야 합니다.

• 데이터베이스 계정이 존재하지 않습니다. 모든 접근은 IAM 자격 증명으로 이루어지므로, 계정 관리 통제는 IAM 통제로 치환하여 증적을 제시해야 합니다.
• 네트워크 경로에 프록시를 삽입하기 어렵습니다. HTTPS 기반 API 호출이므로 SQL 질의를 가로채는 접근통제 장비를 적용할 수 없습니다.
• 스키마가 고정되어 있지 않습니다. 항목마다 속성이 달라질 수 있어, 개인정보 항목의 소재를 파악하는 절차를 별도로 수립해야 합니다.
• 데이터 평면 호출은 기본적으로 기록되지 않습니다. 조회·변경 이력은 별도 설정을 통해서만 확보됩니다.

2. 제도별 적용 가능성 요약

3. 통제 영역별 DynamoDB 구성 구조

국내 제도가 요구하는 네 가지 통제 영역에 대응되는 DynamoDB 및 연계 서비스 구성은 다음과 같습니다. S3와 달리 감사 로그와 장기 보존 영역에서 외부 서비스 연계가 필수적이라는 점이 두드러집니다.

그림 1. 국내 보안 인증 요구사항의 통제 영역과 Amazon DynamoDB 대응 구조

4. 암호화 — 기본 활성화와 증적 사이의 간극

DynamoDB는 모든 테이블에 저장 시 암호화가 기본 적용되며, 이를 해제할 수 없습니다. 그러나 기본값인 AWS 소유 키를 사용하는 경우 키 정책과 사용 이력을 고객이 확인할 수 없습니다. 암호키 생명주기 관리와 키 사용 권한 분리를 요구하는 통제 항목에서는 증적 제출이 어려워집니다. 따라서 심사 대상 테이블은 고객 관리형 키로 전환하는 것이 실무적 기준선입니다.

고유식별정보와 같이 저장 암호화가 의무인 항목은 저장소 계층 암호화만으로 충족을 주장하기보다, 속성 단위 암호화를 함께 적용하는 것이 안전합니다. AWS Database Encryption SDK를 사용하면 지정한 속성만 암호화하고 파티션 키는 평문으로 유지할 수 있습니다.

• 결정적 암호화를 적용한 속성은 동등 비교와 인덱스 사용이 가능하지만, 값의 분포가 노출될 수 있습니다.
• 비결정적 암호화를 적용한 속성은 보호 수준이 높으나 조건 질의와 인덱스 키로 사용할 수 없습니다.
• 서명 기능을 함께 사용하면 항목의 무결성 검증이 가능하여 기록 위·변조 방지 통제에 활용할 수 있습니다.

5. 접근 통제 — 행과 속성 단위 제어

DynamoDB는 데이터베이스 계정이 존재하지 않으므로 계정 관리 통제를 IAM 통제로 치환해야 합니다. 반면 IAM 조건 키를 활용하면 관계형 데이터베이스보다 세밀한 제어가 가능하며, 이는 개인정보 접근 권한을 업무 범위로 제한하도록 요구하는 항목에 직접 대응됩니다.

파티션 키 값 기준으로 자신의 데이터만 조회하도록 제한하는 정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["dynamodb:GetItem", "dynamodb:Query"],
      "Resource": "arn:aws:dynamodb:ap-northeast-2:111122223333:table/Members",
      "Condition": {
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys": ["${aws:userid}"],
          "dynamodb:Attributes": ["memberId", "name", "grade"]
        },
        "StringEquals": { "dynamodb:Select": "SPECIFIC_ATTRIBUTES" }
      }
    }
  ]
}

위 정책은 dynamodb:LeadingKeys로 행 범위를, dynamodb:Attributes로 반환 속성을 제한합니다. 주민등록번호나 연락처와 같은 속성을 정책 수준에서 제외하면, 애플리케이션 결함으로 전체 항목을 조회하더라도 해당 속성이 반환되지 않습니다.

6. 감사 로그 — 기본값으로는 접속기록이 남지 않습니다

DynamoDB에서 가장 빈번하게 지적되는 사항입니다. CloudTrail은 테이블 생성·삭제와 같은 관리 이벤트를 기본 기록하지만, GetItem·Query·PutItem과 같은 데이터 평면 호출은 데이터 이벤트를 별도로 활성화해야 기록됩니다. 이를 설정하지 않은 상태에서는 “누가 어떤 개인정보를 조회했는지”에 대한 기록이 존재하지 않습니다.

7. 보유 기간과 파기 — TTL의 한계

개인정보는 보유 기간이 경과하면 복구·재생되지 않도록 파기해야 합니다. DynamoDB의 TTL은 보유 기간 관리에 유용하지만, 파기 요건을 그대로 충족하지는 않습니다.

• 삭제 시점이 보장되지 않습니다. TTL은 만료 시점 이후 백그라운드 작업으로 삭제되며, 즉시 삭제를 보장하지 않습니다. 만료된 항목이 일정 시간 동안 조회될 수 있습니다.
• 복원 시 되살아납니다. 시점 복구(PITR)와 온디맨드 백업에는 삭제 이전 상태가 포함되므로, 백업 보존 기간이 남아 있는 동안 데이터는 복구 가능한 상태입니다.
• 복제본에 잔존합니다. 글로벌 테이블 구성에서는 복제 지연과 설정 차이에 따라 다른 리전에 항목이 남을 수 있습니다.
• 스트림에 기록이 남습니다. TTL 삭제도 스트림 이벤트로 전달되므로, 하류 저장소에 항목 내용이 전파되었는지 확인해야 합니다.

따라서 파기 절차는 다음과 같이 설계해야 합니다.

1. TTL로 1차 삭제를 수행하고, 만료 이후 조회 요청에 대해서는 애플리케이션에서 만료 여부를 확인하여 응답을 차단합니다.
2. 백업 보존 기간을 보유 기간과 정합하게 설정하여, 백업 만료 시점에 복구 가능성이 소멸되도록 합니다.
3. 스트림 하류 저장소에 동일한 파기 규칙을 적용합니다.
4. 파기 대상 데이터를 별도 테이블과 별도 고객 관리형 키로 분리하고, 최종 파기 시 키를 삭제하여 암호학적 파기를 완결합니다.
5. 파기 수행 결과를 기록으로 남깁니다. 자동 삭제만으로는 파기 수행 사실을 증명하기 어렵습니다.

8. 데이터 소재 — 글로벌 테이블 검토

금융 부문의 국내 소재 요건과 개인정보 국외 이전 규정을 고려하면, 글로벌 테이블은 도입 전 반드시 검토해야 하는 기능입니다. 복제 대상 리전이 국외로 설정되면 데이터가 국외로 전송되며, 이는 별도 고지와 동의 또는 예외 사유를 요구합니다.

• 서울 리전 외 테이블이 존재하지 않는지 조직 전체 계정을 대상으로 점검합니다.
• 서비스 제어 정책(SCP)으로 허용 리전을 제한하여 구조적으로 차단합니다.
• 백업의 리전 간 복사 설정과 DAX 클러스터 위치를 함께 확인합니다.
• 재해 복구 요건이 있는 경우 국내 가용영역 간 구성과 백업 기반 복구로 대체할 수 있는지 검토합니다.

9. 제도별 통합 매핑 표

10. 심사 대비 점검 항목

암호화

• 개인정보·중요정보 처리 테이블이 고객 관리형 키를 사용하는지 확인
• CMK 자동 교체 활성화 및 사용 권한과 관리 권한의 분리 확인
• 고유식별정보 등 의무 대상 항목에 속성 단위 암호화를 적용했는지 확인
• 암호화 속성을 인덱스 키로 사용하지 않는지 확인
• KCMVP 적용 대상 정보에 대해 검증 모듈 기반 사전 암호화 절차를 수립했는지 확인

접근 통제

• IAM 정책에 dynamodb:* 또는 전체 리소스 허용 구문이 없는지 확인
• 민감 속성을 dynamodb:Attributes 조건으로 제외했는지 확인
• VPC 엔드포인트 정책으로 접근 경로를 제한했는지 확인
• 운영자 콘솔 조회 권한이 별도 역할로 분리되고 승인 절차가 있는지 확인
• 분기별 권한 검토 기록이 보관되어 있는지 확인

감사 로그

• 개인정보 처리 테이블에 CloudTrail 데이터 이벤트가 활성화되어 있는지 확인
• 접속기록 보존 기간이 적용 법령 요구 기간(1년 또는 2년) 이상인지 확인
• 처리 목적과 담당자를 포함한 애플리케이션 감사 로그가 존재하는지 확인
• 파티션 키에 식별 정보가 포함되어 로그에 노출되지 않는지 확인
• 스트림 하류 저장소의 보존 기간과 접근 통제를 확인

보존 및 파기

• TTL 설정과 보유 기간 정책이 일치하는지 확인
• 만료 항목에 대한 애플리케이션 차단 로직이 존재하는지 확인
• PITR 및 백업 보존 기간이 보유 기간과 정합한지 확인
• 파기 수행 기록이 별도로 관리되는지 확인
• 불변 보존 요건 대상 기록에 백업 볼트 잠금 또는 S3 Object Lock을 적용했는지 확인

데이터 소재

• 서울 리전 외 테이블이 존재하지 않음을 확인 (SCP로 구조적 차단)
• 글로벌 테이블 복제 대상에 국외 리전이 없음을 확인
• 백업 리전 간 복사 설정을 확인
• 공공 대상 시스템의 경우 CSAP 인증 범위 내 데이터베이스를 사용하고 있는지 확인

11. 결론

Amazon DynamoDB는 국내 보안 인증 제도의 기술적 요건 상당 부분에 대응할 수 있으며, 행·속성 단위 접근 제어는 관계형 데이터베이스보다 정교한 통제를 제공합니다. 반면 다음 세 가지는 설계 단계에서 명확히 처리되어야 합니다.

1. 감사 로그는 기본값으로 남지 않습니다. 데이터 이벤트 활성화와 애플리케이션 감사 로그 설계가 선행되어야 합니다.
2. TTL은 파기가 아닙니다. 백업과 복제본을 포함한 파기 완결 절차와 수행 기록이 필요합니다.
3. 불변 보존 기능이 없습니다. 백업 볼트 잠금 또는 S3 Object Lock과의 이중 구조로 보완해야 합니다.

또한 공공 부문은 CSAP 인증 범위, KCMVP 적용 대상 정보는 검증 암호모듈 사용이라는 제도적 제약이 선행하므로, 저장소 선택 자체가 아키텍처 초기 단계의 의사 결정 사항이 됩니다.

DynamoDB의 컴플라이언스 대응은 테이블 설정 몇 가지로 끝나지 않습니다. 파티션 키 설계, 감사 로그 경로, 백업 보존 기간이 서로 맞물려 있으므로 데이터 모델링 단계에서 함께 결정해야 합니다. 제이씨클라우드는 ISMS-P 및 금융권 요건에 대응하는 데이터 저장소 설계와 컴플라이언스 자동 점검 체계 구축을 지원하고 있습니다.

참고 자료

• 정보보호 및 개인정보보호 관리체계 인증 등에 관한 고시 — 과학기술정보통신부·개인정보보호위원회
• 개인정보의 안전성 확보조치 기준 — 개인정보보호위원회
• 클라우드컴퓨팅서비스 보안인증에 관한 고시 — 과학기술정보통신부
• 전자금융감독규정 및 금융분야 클라우드컴퓨팅서비스 이용 가이드 — 금융위원회·금융보안원
• 암호모듈 검증제도(KCMVP) 안내 — 국가정보원 국가사이버안보센터
• Amazon DynamoDB 개발자 안내서 — 저장 시 암호화, 세분화된 접근 제어, TTL, 시점 복구 항목
• AWS Database Encryption SDK for DynamoDB 개발자 안내서 — AWS 공식 문서

관련 글: 국내 보안 인증 제도와 Amazon S3 · AWS 환경에서 ISMS-P 대응 인프라 구성하기 · AWS Secrets Manager와 Parameter Store 비교