Amazon Security Lake의 데이터 보호 - Amazon Security Lake

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

Amazon Security Lake의 데이터 보호

AWS 공동 책임 모델 공동 책임 모델 이 모델에 설명된 대로 AWS 은 (는) 모두를 실행하는 글로벌 인프라를 보호할 책임이 AWS 클라우드있습니다. 사용자는 인프라에서 호스팅되는 콘텐츠를 관리해야 합니다. 사용하는 AWS 서비스 의 보안 구성과 관리 작업에 대한 책임도 사용자에게 있습니다. 데이터 프라이버시에 대한 자세한 내용은 데이터 프라이버시 FAQ를 참조하세요. 유럽의 데이터 보호에 대한 자세한 내용은 AWS 보안 블로그AWS 공동 책임 모델 및 GDPR 블로그 게시물을 참조하십시오.

데이터 보호를 위해 AWS 계정 자격 증명을 보호하고 AWS IAM Identity Center OR AWS Identity and Access Management (IAM) 을 사용하여 개별 사용자를 설정하는 것이 좋습니다. 이렇게 하면 개별 사용자에게 자신의 직무를 충실히 이행하는 데 필요한 권한만 부여됩니다. 또한 다음과 같은 방법으로 데이터를 보호하는 것이 좋습니다.

  • 각 계정에 멀티 팩터 인증 설정(MFA)을 사용하세요.

  • SSL/TLS를 사용하여 리소스와 통신하세요. AWS TLS 1.2는 필수이며 TLS 1.3를 권장합니다.

  • 를 사용하여 API 및 사용자 활동 로깅을 설정합니다. AWS CloudTrail

  • 포함된 모든 기본 보안 제어와 함께 AWS 암호화 솔루션을 사용하십시오 AWS 서비스.

  • Amazon S3에 저장된 민감한 데이터를 검색하고 보호하는 데 도움이 되는 Amazon Macie와 같은 고급 관리형 보안 서비스를 사용하세요.

  • 명령줄 인터페이스 또는 API를 AWS 통해 액세스할 때 FIPS 140-2로 검증된 암호화 모듈이 필요한 경우 FIPS 엔드포인트를 사용하십시오. 사용 가능한 FIPS 엔드포인트에 대한 자세한 내용은 Federal Information Processing Standard(FIPS) 140-2를 참조하십시오.

고객의 이메일 주소와 같은 기밀 정보나 중요한 정보는 태그나 이름 필드와 같은 자유 양식 필드에 입력하지 않는 것이 좋습니다. 여기에는 콘솔, API 또는 SDK를 AWS 서비스 사용하여 Security Lake 또는 기타 작업을 수행하는 경우가 포함됩니다. AWS CLI AWS 이름에 사용되는 태그 또는 자유 형식 텍스트 필드에 입력하는 모든 데이터는 청구 또는 진단 로그에 사용될 수 있습니다. 외부 서버에 URL을 제공할 때 해당 서버에 대한 요청을 검증하기 위해 보안 인증 정보를 URL에 포함시켜서는 안 됩니다.

저장된 데이터 암호화

Amazon Security Lake는 AWS 암호화 솔루션을 사용하여 저장된 데이터를 안전하게 저장합니다. 원시 보안 로그와 이벤트 데이터는 Security Lake가 관리하는 계정의 멀티테넌트 Amazon Simple Storage Service(S3) 버킷에 저장됩니다. Security Lake는 AWS Key Management Service (AWS KMS) 에서 AWS 소유한 키를 사용하여 이 원시 데이터를 암호화합니다. AWS 소유 키는 AWS 서비스 (이 경우 Security Lake) 가 여러 AWS KMS 계정에서 사용할 수 있도록 소유하고 관리하는 키 모음입니다. AWS

Security Lake는 원시 로그 및 이벤트 데이터에서 추출, 전환, 적재(ETL) 작업을 실행합니다. 처리된 데이터는 Security Lake 서비스 계정에서 암호화된 상태로 유지됩니다.

ETL 작업이 완료되면 Security Lake는 계정에 싱글 테넌트 S3 버킷 (Security Lake를 활성화한 각 AWS 리전 버킷당 하나의 버킷) 을 생성합니다. Security Lake가 싱글 테넌트 S3 버킷에 데이터를 안정적으로 전송할 수 있을 때까지는 데이터가 멀티테넌트 S3 버킷에 일시적으로만 저장됩니다. 싱글 테넌트 버킷에는 Security Lake에 로그 및 이벤트 데이터를 버킷에 쓸 수 있는 권한을 부여하는 리소스 기반 정책이 포함되어 있습니다. S3 버킷의 데이터를 암호화하려면 S3 관리형 암호화 키 또는 고객 관리 키 (에서) 를 선택할 수 있습니다. AWS KMS두 옵션 모두 대칭 암호화를 사용합니다.

KMS 키를 사용하여 데이터를 암호화합니다.

기본적으로 Security Lake가 S3 버킷에 제공하는 데이터는 Amazon S3가 관리하는 암호화 키(SSE-S3)를 사용하는 서버 측 암호화를 사용하여 암호화됩니다. 직접 관리하는 보안 계층을 제공하려면 Security Lake 데이터에 서버 측 AWS KMS 키 암호화 (SSE-KMS) 를 대신 사용할 수 있습니다.

SSE-KMS는 Security Lake 콘솔에서 지원되지 않습니다. Security Lake API 또는 CLI와 함께 SSE-KMS를 사용하려면 먼저 KMS 키를 만들거나 기존 키를 사용해야 합니다. 키에 정책을 연결합니다. 이 키는 Security Lake 데이터를 암호화하고 암호화를 해제할 수 있는 사용자를 결정합니다.

고객 관리형 키를 사용하여 S3 버킷에 기록된 데이터를 암호화하는 경우 다중 지역 키를 선택할 수 없습니다. 고객 관리형 키의 경우 Security Lake는 CreateGrant 요청을 AWS KMS에 전송하여 사용자를 대신하여 권한을 생성합니다. AWS KMS 보조금은 Security Lake에 고객 계정의 KMS 키에 대한 액세스 권한을 부여하는 데 사용됩니다.

Security Lake는 다음 내부 작업에 대해 고객 관리형 키를 사용할 수 있는 권한이 필요합니다.

  • 고객 관리 키로 암호화된 데이터 키를 AWS KMS 생성해 GenerateDataKey 달라는 요청을 보내세요.

  • RetireGrant 요청을 보내세요 AWS KMS. 데이터 레이크를 업데이트하면 이 작업을 통해 ETL 처리를 위해 AWS KMS 키에 추가된 권한을 사용 중지할 수 있습니다.

Security Lake에는 Decrypt 권한이 필요하지 않습니다. 키에 대한 권한이 부여된 사용자가 Security Lake 데이터를 읽는 경우 S3는 암호화를 관리하고 권한이 부여된 사용자는 암호화되지 않은 양식에서 데이터를 읽을 수 있습니다. 하지만 구독자는 소스 데이터를 사용할 수 있는 Decrypt 권한이 필요합니다. 이러한 구독자 권한에 대한 자세한 내용은 Security Lake 구독자의 데이터 액세스 관리 을 참조하십시오.

기존 KMS 키를 사용하여 Security Lake 데이터를 암호화하려면 KMS 키의 키 정책을 수정해야 합니다. 키 정책은 Lake Formation 데이터 레이크 위치와 연결된 IAM 역할이 KMS 키를 사용하여 데이터를 해독하도록 허용해야 합니다. KMS 키의 키 정책을 변경하는 방법에 대한 지침은 개발자 안내서의 키 정책 변경을 참조하십시오. AWS Key Management Service

KMS 키는 권한 부여 요청을 수락하여 키 정책을 생성하거나 적절한 권한이 있는 기존 키 정책을 사용할 때 Security Lake가 키에 액세스하도록 허용할 수 있습니다. 키 정책 생성에 대한 지침은 AWS Key Management Service 개발자 안내서키 정책 생성을 참조하세요.

다음 키 정책을 KMS 키에 연결합니다.

{ "Sid": "Allow use of the key", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::111122223333:role/ExampleRole"} "Action": [ "kms:CreateGrant", "kms:DescribeKey", "kms:GenerateDataKey" ], "Resource": "*" }

고객 관리형 키를 사용할 때 필요한 IAM 권한

Security Lake를 사용하기 위해 생성해야 하는 IAM 역할에 대한 개요는 시작하기: 사전 요구 사항 섹션을 참조하십시오.

사용자 지정 소스 또는 구독자를 추가하면 Security Lake가 계정에 IAM 역할을 생성합니다. 이러한 역할은 다른 IAM ID와 공유하기 위한 것입니다. 이를 통해 사용자 지정 소스는 데이터 레이크에 데이터를 쓰고 구독자는 데이터 레이크의 데이터를 사용할 수 있습니다. 라는 AWS 관리형 정책은 이러한 역할의 권한 경계를 AmazonSecurityLakePermissionsBoundary 설정합니다.

Amazon SQS 대기열 암호화

데이터 레이크를 생성하면 Security Lake가 위임된 Security Lake 관리자 계정에 암호화되지 않은 Amazon Simple Queue Service(Amazon SQS) 대기열 두 개를 생성합니다. 데이터를 보호하려면 이러한 대기열을 암호화해야 합니다. Amazon Simple Queue Service에서 제공하는 기본 서버 측 암호화(SSE)만으로는 충분하지 않습니다. 고객 관리 키 AWS Key Management Service (AWS KMS) 를 생성하여 대기열을 암호화하고 Amazon S3 서비스 보안 주체에게 암호화된 대기열을 사용할 수 있는 권한을 부여해야 합니다. 이러한 권한을 부여하는 방법에 대한 지침은 Amazon S3 이벤트 알림이 서버 측 암호화를 사용하는 Amazon SQS 대기열로 전송되지 않는 이유를 참조하십시오. 지식 센터에서. AWS

Security Lake는 AWS Lambda 데이터에 대한 ETL (추출, 전송, 로드) 작업을 지원하기 때문에 Amazon SQS 대기열에 있는 메시지를 관리할 수 있는 권한도 Lambda에 부여해야 합니다. 자세한 내용은 AWS Lambda 개발자 가이드실행 역할 권한을 참조하세요.

전송 중 암호화

Security Lake는 서비스 간에 전송되는 모든 데이터를 암호화합니다. AWS Security Lake는 전송 계층 보안(TLS) 1.2 암호화 프로토콜을 사용하여 모든 네트워크 간 데이터를 자동으로 암호화하여 서비스에서 전송되는 데이터를 보호합니다. Security Lake API로 전송되는 직접 HTTPS 요청은 AWS 서명 버전 4 알고리즘을 사용하여 서명되어 보안 연결을 설정합니다.