데이터 보호를 위한 보안 제어 권장 사항 - AWS 권장 가이드
워크로드 수준에서 데이터 분류각 데이터 분류 수준에 대한 제어 설정저장 데이터 암호화전송 중 데이터 암호화Amazon EBS 스냅샷에 대한 퍼블릭 액세스Amazon RDS 스냅샷에 대한 퍼블릭 액세스Amazon RDS, Amazon Redshift 및 AWS DMS 리소스에 대한 퍼블릭 액세스S3 버킷에 대한 퍼블릭 액세스MFA가 S3 버킷 데이터를 삭제하도록 요구VPCs의 OpenSearch Service 도메인KMS 키 삭제 알림KMS 키에 대한 퍼블릭 액세스리스너는 보안 프로토콜을 사용합니다.

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

데이터 보호를 위한 보안 제어 권장 사항

AWS Well-Architected Framework는 데이터 분류, 저장 데이터 보호, 전송 중 데이터 보호의 세 가지 범주로 데이터를 보호하기 위한 모범 사례를 그룹화합니다. 이 섹션의 보안 제어는 데이터 보호를 위한 모범 사례를 구현하는 데 도움이 될 수 있습니다. 클라우드에서 워크로드를 설계하기 전에 이러한 기본 모범 사례를 마련해야 합니다. 데이터 취급 오류를 방지하고 조직, 규제 및 규정 준수 의무를 충족하는 데 도움이 됩니다. 이 섹션의 보안 제어를 사용하여 데이터 보호를 위한 모범 사례를 구현합니다.

워크로드 수준에서 데이터 식별 및 분류

데이터 분류는 중요도와 민감도를 기준으로 네트워크의 데이터를 식별하고 분류하는 프로세스입니다. 이 프로세스는 데이터에 대한 적절한 보호 및 보존 제어를 결정하는 데 도움이 되므로 사이버 보안 위험 관리 전략의 중요한 구성 요소입니다. 데이터 분류는 데이터 중복 빈도를 줄이는 경우가 많습니다. 이렇게 하면 스토리지 및 백업 비용을 줄이고 검색을 가속화할 수 있습니다.

워크로드가 처리 중인 데이터의 유형 및 분류, 관련 비즈니스 프로세스, 데이터가 저장되는 위치, 데이터를 소유한 사람을 이해하는 것이 좋습니다. 데이터 분류는 워크로드 소유자가 민감한 데이터를 저장하는 위치를 식별하고 해당 데이터에 액세스하고 공유하는 방법을 결정하는 데 도움이 됩니다. 태그는 AWS 리소스를 구성하기 위한 메타데이터 역할을 하는 키-값 페어입니다. 태그는 리소스를 관리, 식별, 구성, 검색 및 필터링하는 데 도움이 될 수 있습니다.

자세한 정보는 다음 자료를 참조하세요.

각 데이터 분류 수준에 대한 제어 설정

각 분류 수준에 대한 데이터 보호 제어를 정의합니다. 예를 들어 권장 컨트롤을 사용하여 퍼블릭으로 분류된 데이터를 보호하고 추가 컨트롤을 사용하여 민감한 데이터를 보호합니다. 데이터에 직접 액세스하거나 수동으로 처리할 필요성을 줄이거나 없애는 메커니즘과 도구를 사용합니다. 데이터 식별 및 분류를 자동화하면 잘못 분류, 잘못된 처리, 수정 또는 인적 오류의 위험이 줄어듭니다.

예를 들어 Amazon Macie를 사용하여 Amazon Simple Storage Service(Amazon S3) 버킷에서 개인 식별 정보(PII)와 같은 민감한 데이터를 스캔하는 것이 좋습니다. 또한 Amazon Virtual Private Cloud(Amazon VPC)에서 VPC 흐름 로그를 사용하여 의도하지 않은 데이터 액세스 감지를 자동화할 수 있습니다.

자세한 정보는 다음 자료를 참조하세요.

저장 데이터 암호화

저장 데이터는 스토리지에 있는 데이터와 같이 네트워크에 정지된 데이터입니다. 저장 데이터에 대한 암호화 및 적절한 액세스 제어를 구현하면 무단 액세스 위험을 줄일 수 있습니다. 암호화는 사람이 읽을 수 있는 일반 텍스트 데이터를 암호 텍스트로 변환하는 컴퓨팅 프로세스입니다. 콘텐츠를 사용할 수 있도록 콘텐츠를 다시 일반 텍스트로 복호화하려면 암호화 키가 필요합니다. 에서 AWS Key Management Service (AWS KMS)를 사용하여 데이터를 보호하는 데 도움이 되는 암호화 키를 생성하고 제어할 AWS 클라우드수 있습니다.

에서 설명한 대로 암호화가 필요한 데이터 유형을 지정하는 정책을 생성하는 각 데이터 분류 수준에 대한 제어 설정것이 좋습니다. 암호화해야 하는 데이터와 토큰화 또는 해싱과 같은 다른 기술로 보호해야 하는 데이터를 결정하는 방법에 대한 기준을 포함합니다.

자세한 정보는 다음 자료를 참조하세요.

전송 중 데이터 암호화

전송 중 데이터는 네트워크를 통과하고 있는 데이터입니다. 네트워크 리소스 사이를 이동 중인 데이터를 예로 들 수 있습니다. 보안 TLS 프로토콜 및 암호 제품군을 사용하여 전송 중인 모든 데이터를 암호화합니다. 데이터에 대한 무단 액세스를 방지하기 위해 리소스와 인터넷 간의 네트워크 트래픽을 암호화해야 합니다. 가능하면 TLS를 사용하여 내부 AWS 환경 내의 네트워크 트래픽을 암호화합니다.

자세한 정보는 다음 자료를 참조하세요.

Amazon EBS 스냅샷에 대한 퍼블릭 액세스 차단

Amazon Elastic Block Store(Amazon EBS)는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스와 함께 사용할 수 있는 블록 스토리지 볼륨을 제공합니다. 지정 시간 스냅샷을 만들어 Amazon S3에 Amazon EBS 볼륨의 데이터를 백업할 수 있습니다. 스냅샷을 다른 모든와 공개적으로 공유 AWS 계정하거나 AWS 계정 지정한 개인과 비공개로 공유할 수 있습니다.

Amazon EBS 스냅샷을 공개적으로 공유하지 않는 것이 좋습니다. 이로 인해 민감한 데이터가 실수로 노출될 수 있습니다. 스냅샷을 공유하면 다른 사람에게 스냅샷의 데이터에 대한 액세스 권한을 부여하게 됩니다. 스냅샷은이 모든 데이터를 신뢰하는 사람과만 공유합니다.

자세한 정보는 다음 자료를 참조하세요.

Amazon RDS 스냅샷에 대한 퍼블릭 액세스 차단

Amazon Relational Database Service(Amazon RDS)는에서 관계형 데이터베이스를 설정, 운영 및 확장하는 데 도움이 됩니다 AWS 클라우드. Amazon RDS는 DB 인스턴스의 백업 기간 동안 데이터베이스(DB) 인스턴스 또는 다중 AZ DB 클러스터의 자동 백업을 생성하고 저장합니다. Amazon RDS는 개별 데이터베이스가 아닌 전체 DB 인스턴스를 백업하여 DB 인스턴스의 스토리지 볼륨 스냅샷을 생성합니다. 스냅샷을 복사하거나 DB 인스턴스를 복원할 목적으로 수동 스냅샷을 공유할 수 있습니다.

스냅샷을 퍼블릭으로 공유하는 경우 스냅샷의 데이터 중 프라이빗 데이터나 민감한 데이터가 없는지 확인합니다. 스냅샷이 공개적으로 공유되면 모든 AWS 계정 가 데이터에 액세스할 수 있는 권한을 부여합니다. 이로 인해 Amazon RDS 인스턴스의 데이터가 의도하지 않게 노출될 수 있습니다.

자세한 정보는 다음 자료를 참조하세요.

Amazon RDS, Amazon Redshift 및 AWS DMS 리소스에 대한 퍼블릭 액세스 차단

공개적으로 액세스할 수 있도록 Amazon RDS DB 인스턴스, Amazon Redshift 클러스터 및 AWS Database Migration Service (AWS DMS) 복제 인스턴스를 구성할 수 있습니다. publiclyAccessible 필드 값이 이면 true이러한 리소스에 공개적으로 액세스할 수 있습니다. 퍼블릭 액세스를 허용하면 불필요한 트래픽, 노출 또는 데이터 유출이 발생할 수 있습니다. 이러한 리소스에 대한 퍼블릭 액세스를 허용하지 않는 것이 좋습니다.

AWS Config 규칙 또는 Security Hub 제어를 활성화하여 Amazon RDS DB 인스턴스, AWS DMS 복제 인스턴스 또는 Amazon Redshift 클러스터가 퍼블릭 액세스를 허용하는지 여부를 감지하는 것이 좋습니다.

참고

인스턴스가 프로비저닝된 후에는 AWS DMS 복제 인스턴스에 대한 퍼블릭 액세스 설정을 수정할 수 없습니다. 퍼블릭 액세스 설정을 변경하려면 현재 인스턴스를 삭제한 다음 다시 생성합니다. 다시 생성할 때 공개적으로 액세스할 수 있는 옵션을 선택하지 마세요.

자세한 정보는 다음 자료를 참조하세요.

Amazon S3 버킷에 대한 퍼블릭 액세스 차단

버킷에 공개적으로 액세스할 수 없도록 하는 것이 Amazon S3 보안 모범 사례입니다. 인터넷상의 누군가가 버킷을 읽거나 쓸 수 있도록 명시적으로 요구하지 않는 한 버킷이 공개되지 않도록 해야 합니다. 이렇게 하면 데이터의 무결성과 보안을 보호할 수 있습니다. AWS Config 규칙 및 Security Hub 제어를 사용하여 Amazon S3 버킷이이 모범 사례를 준수하는지 확인할 수 있습니다.

자세한 정보는 다음 자료를 참조하세요.

MFA가 중요한 Amazon S3 버킷의 데이터를 삭제하도록 요구

Amazon S3 버킷에서 S3 버전 관리를 사용하는 경우 선택적으로 MFA(멀티 팩터 인증) Delete를 사용 설정하도록 버킷을 구성하여 다른 보안 계층을 추가할 수 있습니다. 이렇게 하면 버킷 소유자가 버전을 삭제하거나 버킷의 버전 관리 상태를 변경하는 모든 요청에 두 가지 형식의 인증을 포함해야 합니다. 조직에 중요한 데이터가 포함된 버킷의 경우이 기능을 활성화하는 것이 좋습니다. 이렇게 하면 실수로 버킷 및 데이터가 삭제되는 것을 방지할 수 있습니다.

자세한 정보는 다음 자료를 참조하세요.

VPC에서 Amazon OpenSearch Service 도메인 구성

Amazon OpenSearch Service는에서 OpenSearch 클러스터를 배포, 운영 및 확장하는 데 도움이 되는 관리형 서비스입니다 AWS 클라우드. Amazon OpenSearch Service는 OpenSearch 및 레거시 Elasticsearch 오픈 소스 소프트웨어(OSS)를 지원합니다. VPC 내에 배포된 Amazon OpenSearch Service 도메인은 퍼블릭 인터넷을 통과할 필요 없이 프라이빗 AWS 네트워크를 통해 VPC 리소스와 통신할 수 있습니다. 이 구성은 전송 중인 데이터에 대한 액세스를 제한하여 보안 태세를 개선합니다. Amazon OpenSearch Service 도메인을 퍼블릭 서브넷에 연결하지 않고 VPC를 모범 사례에 따라 구성하는 것이 좋습니다.

자세한 정보는 다음 자료를 참조하세요.

AWS KMS key 삭제를 위한 알림 구성

AWS Key Management Service (AWS KMS) 키는 삭제된 후에는 복구할 수 없습니다. KMS 키가 삭제되면 해당 키로 암호화된 데이터는 영구적으로 복구할 수 없습니다. 데이터에 대한 액세스를 유지해야 하는 경우 키를 삭제하기 전에 데이터를 복호화하거나 새 KMS 키로 다시 암호화해야 합니다. 더 이상 사용할 필요가 없다고 확신하는 경우에만 KMS 키를 삭제해야 합니다.

누군가 KMS 키 삭제를 시작하면 알려주는 Amazon CloudWatch 경보를 구성하는 것이 좋습니다. KMS 키를 삭제하는 것은 파괴적이고 잠재적으로 위험하기 때문에는 대기 기간을 설정하고 7~30일 후에 삭제를 예약해야 AWS KMS 합니다. 이렇게 하면 예약된 삭제를 검토하고 필요한 경우 취소할 수 있습니다.

자세한 정보는 다음 자료를 참조하세요.

에 대한 퍼블릭 액세스 차단 AWS KMS keys

키 정책은에 대한 액세스를 제어하는 기본 방법입니다 AWS KMS keys. 모든 KMS 키에는 정확히 하나의 키 정책이 있습니다. KMS 키에 대한 익명 액세스를 허용하면 민감한 데이터가 유출될 수 있습니다. 이러한 리소스에 대한 서명되지 않은 요청을 방지하려면 공개적으로 액세스할 수 있는 KMS 키를 식별하고 액세스 정책을 업데이트하는 것이 좋습니다.

자세한 정보는 다음 자료를 참조하세요.

보안 프로토콜을 사용하도록 로드 밸런서 리스너 구성

Elastic Load Balancing은 수신되는 애플리케이션 트래픽을 여러 대상에 자동으로 분산합니다. 하나 이상의 리스너를 지정하여 들어오는 트래픽을 허용하도록 로드 밸런서를 구성합니다. 리스너는 구성한 프로토콜 및 포트를 사용하여 연결 요청을 확인하는 프로세스입니다. 각 유형의 로드 밸런서는 다양한 프로토콜과 포트를 지원합니다.

  • Application Load Balancer는 애플리케이션 계층에서 라우팅 결정을 내리고 HTTP 또는 HTTPS 프로토콜을 사용합니다.

  • Network Load Balancer는 전송 계층에서 라우팅 결정을 내리고 TCP, TLS, UDP 또는 TCP_UDP 프로토콜을 사용합니다.

  • Classic Load Balancer는 전송 계층(TCP 또는 SSL 프로토콜 사용) 또는 애플리케이션 계층(HTTP 또는 HTTPS 프로토콜 사용)에서 라우팅 결정을 내립니다.

항상 HTTPS 또는 TLS 프로토콜을 사용하는 것이 좋습니다. 이러한 프로토콜은 로드 밸런서가 클라이언트와 대상 간의 트래픽을 암호화하고 복호화할 책임이 있는지 확인합니다.

자세한 정보는 다음 자료를 참조하세요.