Terraform을 사용하여 조직에서 GuardDuty Amazon을 자동으로 활성화하십시오. - AWS 권장 가이드
요약사전 조건 및 제한 사항아키텍처도구에픽관련 리소스추가 정보

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

Terraform을 사용하여 조직에서 GuardDuty Amazon을 자동으로 활성화하십시오.

작성자: 아르티 칸난 () AWS

코드 리포지토리: - amazon-guardduty-for-aws organizations-with-terraform

환경: 프로덕션

기술: 보안, ID, 규정 준수 DevOps

워크로드: 기타 모든 워크로드

AWS서비스: 아마존 GuardDuty; AWS 조직

요약

Amazon은 Amazon Web Services (AWS) 계정을 GuardDuty 지속적으로 모니터링하고 위협 인텔리전스를 사용하여 AWS 환경 내에서 예상치 못한 잠재적 악의적 활동을 식별합니다. 여러 AWS 지역에 걸쳐 있는 여러 계정이나 조직을 수동으로 GuardDuty 활성화하거나 AWS 관리 콘솔을 통해 활성화하는 것은 번거로울 수 있습니다. 클라우드에서 다중 계정, 다중 리전 서비스 및 리소스를 프로비저닝하고 관리할 수 있는 Terraform과 같은 코드형 인프라(IaC) 도구를 사용하여 프로세스를 자동화할 수 있습니다.

AWS에서 AWS Organizations를 사용하여 여러 계정을 설정하고 관리할 것을 권장합니다 GuardDuty. 이 패턴은 해당 권장 사항을 준수합니다. 이 접근 방식의 한 가지 이점은 새 계정을 만들거나 조직에 추가할 때 수동 개입 없이 지원되는 모든 지역의 해당 계정에서 자동으로 활성화된다는 GuardDuty 것입니다.

이 패턴은 HashiCorp Terraform을 사용하여 조직의 세 개 이상의 Amazon Web Services (AWS) 계정에 GuardDuty 대해 Amazon을 활성화하는 방법을 보여줍니다. 이 패턴과 함께 제공된 샘플 코드는 다음 사항을 수행합니다.

  • GuardDuty Organizations에서 AWS 대상 조직의 현재 구성원인 모든 AWS 계정에 사용할 수 있습니다.

  • 에서 GuardDuty자동 활성화 기능을 활성화합니다. 이 기능은 향후 GuardDuty 대상 조직에 추가되는 모든 계정을 자동으로 활성화합니다.

  • 활성화하려는 지역을 선택할 수 있습니다. GuardDuty

  • 조직의 보안 계정을 GuardDuty 위임된 관리자로 사용합니다.

  • 로깅 계정에 Amazon Simple Storage Service (Amazon S3) 버킷을 생성하고 이 버킷의 모든 계정에서 집계된 결과를 게시하도록 GuardDuty 구성합니다.

  • 기본적으로 365일 후에 S3 버킷에서 Amazon S3 Glacier Flexible Retrieval 스토리지로 조사 결과를 전환하는 수명 주기 정책 할당

이 샘플 코드를 수동으로 실행할 수도 있고 지속적 통합 및 지속적 전달 (CI/CD) 파이프라인에 통합할 수도 있습니다.

대상 오디언스

이 패턴은 Terraform GuardDuty, Python 및 AWS Organizations를 사용해 본 경험이 있는 사용자에게 권장됩니다.

사전 조건 및 제한 사항

사전 조건 

  • 활성 상태의 AWS 계정.

  • 조직은 AWS Organizations에 설정되며 최소한 다음 세 개의 계정을 포함합니다.

    • 관리 계정 - Terraform 코드를 독립 실행형 또는 CI/CD 파이프라인의 일부로 배포하는 계정입니다. Terraform 상태도 이 계정에 저장됩니다.

    • 보안 계정 - 이 계정은 GuardDuty 위임된 관리자로 사용됩니다. 자세한 내용은 GuardDuty 위임된 관리자를 위한 중요 고려 사항 (GuardDuty 설명서) 을 참조하십시오.

    • 로깅 계정 - 이 계정에는 모든 회원 계정의 집계된 결과를 GuardDuty 게시하는 S3 버킷이 포함되어 있습니다.

    필수 구성으로 조직을 설정하는 방법에 대한 자세한 내용은 계정 구조 만들기 (AWSWell-Architected Labs) 를 참조하십시오.

  • 관리 계정에 Terraform의 상태를 저장하는 원격 백엔드 역할을 하는 Amazon S3 버킷 및 Amazon DynamoDB 테이블. Terraform 상태에 원격 백엔드를 사용하는 방법에 대한 자세한 내용은 S3 백엔드(Terraform 설명서)를 참조하세요. S3 백엔드를 사용하여 원격 상태 관리를 설정하는 코드 샘플은 remote-state-s3-백엔드 (Terraform 레지스트리) 를 참조하십시오. 다음과 같은 요구 사항을 확인합니다.

    • S3 버킷과 DynamoDB 테이블은 동일한 리전에 있어야 합니다.

    • DynamoDB 테이블을 생성할 때 파티션 키는 LockID(대소문자 구분)여야 하고 파티션 키 유형은 문자열이어야 합니다. 기타 모든 테이블 설정은 기본값이어야 합니다. 자세한 내용은 프라이머리 키 정보 및 테이블 생성(DynamoDB 설명서)을 참조하세요.

  • 결과를 게시할 S3 버킷에 대한 액세스 로그를 저장하는 데 사용되는 S3 버킷입니다. GuardDuty 자세한 내용은 Amazon S3 서버 액세스 로깅 활성화(Amazon S3 설명서) 참조하세요. AWSControl Tower 랜딩 존에 배포하는 경우 로그 아카이브 계정의 S3 버킷을 이 용도로 재사용할 수 있습니다.

  • Terraform 버전 0.14.6 이상이 설치 및 구성되어 있습니다. 자세한 내용은 시작하기 — AWS (Terraform 설명서) 를 참조하십시오.

  • Python 버전 3.9.6 이상이 설치 및 구성되었습니다. 자세한 내용은 소스 릴리스(Python 웹사이트)를 참조하세요.

  • AWSSDK파이썬용 (Boto3) 가 설치되어 있습니다. 자세한 내용은 설치(Boto3 설명서)를 참조하세요.

  • jq가 설치 및 구성되었습니다. 자세한 내용은 jq 다운로드(jq 설명서)를 참조하세요.

제한 사항

  • 이 패턴은 macOS 및 Amazon Linux 2 운영 체제를 지원합니다. 이 패턴은 Windows 운영 체제에서 사용할 수 있도록 테스트되지 않았습니다.

    참고: Amazon Linux 2의 지원이 거의 종료되었습니다. 자세한 내용은 Amazon Linux 2를 참조하십시오FAQs.

  • GuardDuty 대상 지역의 어떤 계정에서도 이미 활성화되지 않았어야 합니다.

  • 이 패턴의 IaC 솔루션은 사전 조건을 배포하지 않습니다.

  • 이 패턴은 다음 모범 사례를 준수하는 AWS 착륙 지대를 위해 설계되었습니다.

    • 랜딩 존은 AWS Control Tower를 사용하여 생성되었습니다.

    • 보안 및 로깅에는 별도의 AWS 계정이 사용됩니다.

제품 버전

  • Terraform 버전 0.14.6 이상. 샘플 코드는 버전 1.2.8에서 테스트됩니다.

  • Python 버전 3.9.6 이상.

아키텍처

이 섹션에서는 이 솔루션과 샘플 코드로 설정된 아키텍처를 개략적으로 설명합니다. 다음 다이어그램은 단일 AWS 지역 내에서 조직의 다양한 계정에 배포된 리소스를 보여줍니다.

관리, 보안, 로깅 및 회원 계정의 리소스를 보여주는 아키텍처 다이어그램.

  1. Terraform은 보안 계정과 로깅 계정에 GuardDutyTerraformOrgRoleAWSID 및 Access Management (IAM) 역할을 생성합니다.

  2. Terraform은 로깅 계정의 기본 AWS 지역에 S3 버킷을 생성합니다. 이 버킷은 모든 지역 및 조직 내 모든 계정의 모든 GuardDuty 결과를 집계하는 게시 대상으로 사용됩니다. 또한 Terraform은 S3 버킷의 결과를 암호화하는 데 사용되는 키 관리 서비스 (AWSKMS) 키를 보안 계정에 생성하고 S3 버킷의 결과를 S3 Glacier Flexible Retrieval 스토리지로 자동 보관하도록 구성합니다. AWS

  3. Terraform은 관리 계정에서 보안 계정을 위임 관리자로 지정합니다. GuardDuty 즉, 이제 보안 계정이 관리 계정을 포함한 모든 회원 계정의 GuardDuty 서비스를 관리합니다. 개별 회원 계정은 GuardDuty 혼자서 일시 중지하거나 비활성화할 수 없습니다.

  4. Terraform은 GuardDuty 위임된 관리자를 위해 보안 계정에 GuardDuty 탐지기를 생성합니다.

  5. 아직 활성화되지 않은 경우 Terraform은 S3 보호를 활성화합니다. GuardDuty 자세한 내용은 Amazon에서의 Amazon S3 보호 GuardDuty (GuardDuty 설명서) 를 참조하십시오.

  6. Terraform은 조직의 현재 활성 회원 계정을 모두 회원으로 등록합니다. GuardDuty

  7. Terraform은 GuardDuty 위임된 관리자가 모든 회원 계정의 집계된 결과를 로깅 계정의 S3 버킷에 게시하도록 구성합니다.

  8. Terraform은 선택한 각 지역에 대해 3~7단계를 반복합니다. AWS

자동화 및 규모 조정

제공된 샘플 코드는 자동화된 배포를 위해 CI/CD 파이프라인에 통합할 수 있도록 모듈화되어 있습니다.

도구

AWS서비스

기타 도구 및 서비스

  • HashiCorp Terraform은 코드를 사용하여 클라우드 인프라 및 리소스를 프로비저닝하고 관리하는 데 도움이 되는 명령줄 인터페이스 애플리케이션입니다.

  • Python은 범용 프로그래밍 언어입니다.

  • jq는 파일 작업을 도와주는 명령줄 프로세서입니다. JSON

코드 리포지토리

이 패턴의 코드는 - 저장소에서 GitHub 사용할 수 있습니다. amazon-guardduty-for-aws organizations-with-terraform

에픽

작업설명필요한 기술

리포지토리를 복제합니다.

Bash 쉘에서 다음 명령을 실행합니다. 추가 정보 섹션의 리포지토리 복제에서 GitHub 리포지토리의 데이터가 포함된 전체 명령을 복사할 수 있습니다. URL 이렇게 하면 amazon-guardduty-for-awsorganizations-with-terraform-리포지토리가 복제됩니다 GitHub.

git clone <github-repository-url>
DevOps 엔지니어

Terraform 구성 파일을 편집합니다.

  1. 복제된 리포지토리의 root 폴더에서 다음 명령을 실행하여 configuration.json.sample 파일을 복제합니다.

    cp configuration.json.sample configuration.json

  2. 새 configuration.json 파일을 편집하고 다음 각 변수의 값을 정의합니다.

    • management_acc_id - 관리 계정의 계정 ID입니다.

    • delegated_admin_acc_id - 보안 계정의 계정 ID입니다.

    • logging_acc_id - 로깅 계정의 계정 ID입니다.

    • target_regions— 활성화하려는 AWS 지역의 쉼표로 구분된 목록입니다. GuardDuty

    • organization_id— AWS 활성화하려는 조직의 조직 GuardDuty ID입니다.

    • default_region - Terraform 상태가 관리 계정에 저장되는 리전. 이 지역은 Terraform 백엔드용 S3 버킷 및 DynamoDB 테이블을 배포한 리전과 동일합니다.

    • role_to_assume_for_role_creation— 보안 및 로깅 계정의 새 IAM 역할에 할당하려는 이름. 다음 이야기에서 이 새 역할을 생성합니다. Terraform은 이 역할을 맡아 보안 및 GuardDutyTerraformOrgRole IAM 로깅 계정에 역할을 생성합니다.

    • finding_publishing_frequency— 결과를 S3 버킷에 GuardDuty 게시하는 빈도.

    • guardduty_findings_bucket_region - 게시된 결과를 위한 S3 버킷을 생성하려는 선호 리전.

    • logging_acc_s3_bucket_name - 버킷에 게시되는 S3 버킷의 기본 이름입니다.

    • security_acc_kms_key_alias— AWS KMS 결과를 암호화하는 GuardDuty 데 사용되는 키의 별칭.

    • s3_access_log_bucket_name— 검색 결과에 사용된 S3 버킷에 대한 액세스 로그를 수집하려는 기존 S3 버킷의 이름. GuardDuty 이 버킷은 GuardDuty 검색 결과 버킷과 동일한 AWS 지역에 있어야 합니다.

    • tfm_state_backend_s3_bucket - Terraform 원격 백엔드 상태를 저장할 기존 S3 버킷의 이름.

    • tfm_state_backend_dynamodb_table - Terraform 상태를 잠그기 위한 기존 DynamoDB 테이블의 이름입니다.

  3. 구성 파일을 저장하고 닫습니다.

DevOps 엔지니어, 일반, 테라폼AWS, Python

새 IAM 역할을 위한 CloudFormation 템플릿을 생성하세요.

이 패턴에는 두 개의 CloudFormation 템플릿을 만들 수 있는 IaC 솔루션이 포함되어 있습니다. 이러한 템플릿은 Terraform이 설정 과정에서 사용하는 두 가지 IAM 역할을 생성합니다. 이러한 템플릿은 최소 권한 승인의 보안 모범 사례를 준수합니다.

  1. Bash 쉘의 리포지토리 root 폴더에서 cfn-templates/로 이동합니다. 이 폴더에는 스텁이 있는 CloudFormation 템플릿 파일이 들어 있습니다.

  2. 다음 명령을 실행합니다. 이렇게 하면 스텁이 configuration.json 파일에 입력한 값으로 대체됩니다.

    bash scripts/replace_config_stubs.sh

  3. cfn-templates/폴더에 다음 CloudFormation 템플릿이 생성되었는지 확인합니다.

    • management-account-role.yaml — 이 파일에는 이 패턴을 완료하는 데 필요한 최소 권한이 있는 관리 계정의 IAM 역할 정의 및 관련 권한이 들어 있습니다.

    • role-to-assume-for-role-creation.yaml — 이 파일에는 역할 정의와 보안 및 로깅 계정의 역할에 대한 관련 권한이 들어 있습니다. IAM Terraform은 이러한 계정에서 역할을 생성하기 위해 이 역할을 맡습니다. GuardDutyTerraformOrgRole

DevOps 엔지니어, 일반 AWS

IAM역할 생성.

스택 만들기 (CloudFormation 설명서) 의 지침에 따라 다음을 수행하십시오.

  1. 보안 계정과 role-to-assume-for로깅 계정 모두에 -role-creation.yaml 스택을 배포하십시오.

  2. .yaml 스택을 관리 계정에 배포합니다. management-account-role 스택을 성공적으로 생성하고 CREATE_COMPLETE 스택 상태를 확인하면 출력에서 이 새 역할의 Amazon 리소스 이름 (ARN) 을 기록해 둡니다.

DevOps 엔지니어, 일반 AWS

관리 계정에서 IAM 역할을 맡으세요.

보안 모범 사례로서 진행하기 전에 새 management-account-roleIAM역할을 맡는 것이 좋습니다. AWS명령줄 인터페이스 (AWSCLI) 의 추가 정보 섹션의 관리 계정 IAM 역할 맡기에 명령을 입력합니다.

DevOps 엔지니어, 일반 AWS

설치 스크립트를 실행합니다.

리포지토리 root 폴더에서 다음 명령을 실행하여 설치 스크립트를 시작합니다.

bash scripts/full-setup.sh

full-setup.sh 스크립트는 다음 작업을 수행합니다.

  • 모든 구성 값을 환경 변수로 내보내기

  • 각 Terraform 모듈에 대한 backend.tf 및 terraform.tfvars 코드 파일 생성

  • 를 통해 조직 GuardDuty 내에서 신뢰할 수 있는 액세스를 가능하게 합니다 AWSCLI.

  • 조직 상태를 Terraform 상태로 가져오기

  • 로깅 계정에 결과를 게시하기 위한 S3 버킷 생성

  • 보안 계정의 결과를 암호화하기 위한 AWS KMS 키를 생성합니다.

  • 아키텍처 섹션에 설명된 대로 선택한 모든 지역에서 조직 GuardDuty 전체에서 활성화합니다.

DevOps 엔지니어, Python
작업설명필요한 기술

정리 스크립트를 실행합니다.

이 패턴을 사용하여 조직에서 GuardDuty 활성화한 후 사용하지 않도록 설정하려면 GuardDuty 리포지토리 root 폴더에서 다음 명령을 실행하여 cleanup-gd.sh 스크립트를 시작합니다.

bash scripts/cleanup-gd.sh

이 스크립트는 대상 조직에서 사용하지 않도록 설정하고 GuardDuty , 배포된 리소스를 모두 제거하고, Terraform을 사용하여 활성화하기 전의 이전 상태로 조직을 복원합니다. GuardDuty

참고 이 스크립트는 로컬 및 원격 백엔드에서 Terraform 상태 파일이나 잠금 파일을 제거하지 않습니다. 이 작업을 수행해야 하는 경우 이러한 작업을 수동으로 수행해야 합니다. 또한 이 스크립트는 가져온 조직이나 해당 조직에서 관리하는 계정을 삭제하지 않습니다. 에 대한 신뢰할 수 있는 액세스는 정리 스크립트의 일부로 GuardDuty 비활성화되지 않습니다.

DevOps 엔지니어, 일반, 테라폼AWS, Python

역할 제거IAM.

role-to-assume-for-role-creation.yaml 및 .yaml 템플릿을 사용하여 만든 스택을 삭제합니다. management-account-role CloudFormation 자세한 내용은 스택 삭제 (문서) 를 참조하십시오. CloudFormation

DevOps 엔지니어, 일반 AWS

관련 리소스

AWS문서

AWS마케팅

기타 리소스

추가 정보

리포지토리 복제

다음 명령을 실행하여 리포지토리를 복제합니다. GitHub 

git clone https://github.com/aws-samples/amazon-guardduty-for-aws-organizations-with-terraform

관리 계정 IAM 역할을 맡으세요.

관리 계정에서 IAM 역할을 맡으려면 다음 명령을 실행합니다. ARNIAM역할의 <IAM role ARN> 역할로 바꾸십시오.

export ROLE_CREDENTIALS=$(aws sts assume-role --role-arn <IAM role ARN> --role-session-name AWSCLI-Session --output json)
export AWS_ACCESS_KEY_ID=$(echo $ROLE_CREDENTIALS | jq .Credentials.AccessKeyId | sed 's/"//g')
export AWS_SECRET_ACCESS_KEY=$(echo $ROLE_CREDENTIALS | jq .Credentials.SecretAccessKey | sed 's/"//g')
export AWS_SESSION_TOKEN=$(echo $ROLE_CREDENTIALS | jq .Credentials.SessionToken | sed 's/"//g')