데이터 보안 및 위험 관리

AWS 환경 내에서는 규정 준수 및 보안 요구 사항이 서로 다른 계정이 있을 수 있습니다. 예를 들어 개발자 샌드박스가 있고 결제 처리와 같이 규제가 엄격한 워크로드를 위한 프로덕션 환경을 호스팅하는 계정이 있을 수 있습니다. 이들을 서로 다른 계정으로 분리하면 별도의 보안 제어를 적용하고 민감한 데이터에 대한 액세스를 제한하고 규제된 워크로드의 감사 범위를 줄일 수 있습니다.

모든 워크로드에 대해 단일 표준을 채택하면 문제가 발생할 수 있습니다. 많은 제어 항목이 환경 전체에 동일하게 적용되지만 특정 규제 프레임워크를 충족할 필요가 없는 계정 및 개인 식별 데이터가 전혀 없는 계정(예: 개발자 샌드박스 또는 워크로드 개발 계정)에는 일부 제어 항목이 과도하거나 관련이 없습니다. 이로 인해 일반적으로 아무 조치도 취하지 않고 분류하고 종료해야 하는 오탐지 보안 결과가 발생하므로 조사해야 할 결과에 대한 노력이 줄어듭니다.

표 11 – 데이터 보안 및 위험 관리 태그의 예

사용 사례	태그 키	이론적 근거	예제 값
인시던트 관리	example-inc:incident- management:escalationlog	지원 팀이 인시던트를 로깅하는 데 사용하는 시스템	jira, servicenow, zendesk
인시던트 관리	example-inc:incident- management:escalationpath	에스컬레이션 경로	ops-center, dev-ops, app-team
데이터 분류	example-inc:data:classification	규정 준수 및 거버넌스를 위한 데이터 분류	Public, Private, Confidential, Restricted
규정 준수	example-inc:compliance:framework	워크로드에 적용되는 규정 준수 프레임워크 식별	PCI-DSS, HIPAA

AWS 환경 전반에 걸쳐 다양한 제어를 수동으로 관리하는 것은 시간이 많이 걸리고 오류가 발생하기 쉽습니다. 다음 단계는 적절한 보안 제어 항목의 배포를 자동화하고 해당 계정의 분류에 따라 리소스 검사를 구성하는 것입니다. 계정과 계정 내 리소스에 태그를 적용하면 제어 항목 배포를 자동화하고 워크로드에 맞게 구성할 수 있습니다.

예:

워크로드에는 Private 값이 있는 example-inc:data:classification 태그가 있는 Amazon S3 버킷이 포함됩니다. 보안 도구 자동화는 AWS Config 규칙 s3-bucket-public-read-prohibited를 배포합니다. Amazon S3 버킷의 퍼블릭 액세스 차단 설정, 버킷 정책, 버킷 액세스 제어 목록(ACL)을 확인하여 버킷 구성이 해당 데이터 분류에 적합한지 확인합니다. 버킷 콘텐츠가 분류와 일치하도록 Amazon Macie를 구성하여 개인 식별 정보(PII)를 확인할 수 있습니다. Amazon Macie를 사용하여 S3 버킷 데이터 분류 검증 블로그에서는 이 패턴을 더 자세히 살펴봅니다.

보험 및 의료와 같은 특정 규제 환경에는 필수 데이터 보존 정책이 적용될 수 있습니다. Amazon S3 수명 주기 정책과 함께 태그를 사용한 데이터 보존은 객체 전환 범위를 다른 스토리지 계층으로 지정하는 효과적이고 간단한 방법이 될 수 있습니다. Amazon S3 수명 주기 규칙을 사용하여 필수 보류 기간이 만료된 후 데이터 삭제를 위해 객체를 만료시킬 수도 있습니다. 이 프로세스에 대한 심층 가이드는 Amazon S3 수명 주기와 함께 객체 태그를 사용하여 데이터 수명 주기 단순화를 참조하세요.

또한 보안 탐지 결과를 분류하거나 처리할 때 태그를 사용하면 조사자에게 위험을 판단하는 데 도움이 되는 중요한 컨텍스트를 제공하고 해당 팀이 결과를 조사하거나 완화하도록 유도하는 데 도움이 될 수 있습니다.