보안 OU — 보안 도구 계정

간단한 설문조사를 통해 AWS 보안 참조 아키텍처 (AWS SRA) 의 미래에 영향을 미치세요.

다음 다이어그램은 보안 도구 계정에 구성된 AWS 보안 서비스를 보여줍니다.

Security Tooling 계정은 보안 서비스를 운영하고, AWS 계정을 모니터링하고, 보안 경고 및 대응을 자동화하는 데 전념합니다. 보안 목표에는 다음이 포함됩니다.

• 액세스 제어가 가능한 전용 계정을 제공하여 보안 가드레일에 대한 액세스, 모니터링 및 대응을 관리하십시오.

• 적절한 중앙 집중식 보안 인프라를 유지하여 보안 운영 데이터를 모니터링하고 추적성을 유지하십시오. 탐지, 조사 및 대응은 보안 라이프사이클의 필수적인 부분이며 품질 프로세스, 법률 또는 규정 준수 의무, 위협 식별 및 대응 노력을 지원하는 데 사용될 수 있습니다.

• 암호화 키 및 보안 그룹 설정과 같은 적절한 보안 구성 및 운영에 대한 또 다른 제어 계층을 유지하여 defense-in-depth 조직 전략을 추가로 지원합니다. 이 계정은 보안 운영자가 근무하는 계정입니다. AWS 조직 전체 정보를 보기 위한 읽기 전용/감사 역할은 일반적이지만, 쓰기/수정 역할은 수가 제한되어 엄격하게 제어, 모니터링 및 기록됩니다.

설계 고려 사항

• AWS Control Tower는 기본적으로 보안 OU에 속한 계정을 감사 계정으로 지정합니다. AWS Control Tower 설정 중에 계정 이름을 변경할 수 있습니다.

• 보안 도구 계정을 두 개 이상 보유하는 것이 적절할 수 있습니다. 예를 들어 보안 이벤트 모니터링 및 대응은 전담 팀에 배정되는 경우가 많습니다. 네트워크 보안은 클라우드 인프라 또는 네트워크 팀과 협력하여 자체 계정 및 역할을 보장할 수 있습니다. 이러한 분할은 중앙 집중식 보안 구역을 분리하려는 목적을 유지하고 있으며, 업무 분리, 권한 최소화, 팀 배정의 잠재적 단순성 등을 더욱 강조합니다. AWS Control Tower를 사용하는 경우 보안 OU에 따라 추가 AWS 계정을 생성하는 것이 제한됩니다.

보안 서비스 담당 위임 관리자

Security Tooling 계정은 AWS 계정 전체에서 관리자/구성원 구조로 관리되는 보안 서비스의 관리자 계정 역할을 합니다. 앞서 언급한 바와 같이, 이는 AWS Organizations의 위임 관리자 기능을 통해 처리됩니다. 현재 위임 관리자를 지원하는 AWS SRA의 서비스로는 AWS Config, AWS 방화벽 관리자, 아마존, AWS IAM 액세스 분석기 GuardDuty, 아마존 메이시, AWS 보안 허브, 아마존 디텍티브, AWS 감사 관리자, 아마존 인스펙터, AWS Systems Manager 등이 있습니다. CloudTrail 보안팀은 이러한 서비스의 보안 기능을 관리하고 모든 보안 관련 이벤트 또는 결과를 모니터링합니다.

IAM ID 센터는 회원 계정에 대한 위임 관리를 지원합니다. AWS SRA는 공유 서비스 계정을 IAM ID 센터의 위임된 관리자 계정으로 사용합니다. 자세한 내용은 공유 서비스 계정의 IAM ID 센터 섹션 뒷부분에 설명되어 있습니다.

AWS CloudTrail

CloudTrailAWS는 AWS 계정의 활동에 대한 거버넌스, 규정 준수 및 감사를 지원하는 서비스입니다. 를 사용하면 AWS 인프라 전반의 작업과 관련된 계정 활동을 기록하고, 지속적으로 모니터링하고, 유지할 수 있습니다. CloudTrail CloudTrail 는 AWS Organizations와 통합되며, 이 통합을 통해 AWS 조직의 모든 계정에 대한 모든 이벤트를 기록하는 단일 트레일을 생성할 수 있습니다. 이를 조직 추적이라고 합니다. 조직의 관리 계정 내에서 또는 위임된 관리자 계정에서만 조직 트레일을 생성하고 관리할 수 있습니다. 조직 트레일을 생성하면 지정한 이름의 트레일이 AWS 조직에 속한 모든 AWS 계정에 생성됩니다. 트레일은 AWS 조직의 관리 계정을 포함한 모든 계정의 활동을 기록하고 단일 S3 버킷에 로그를 저장합니다. 이 S3 버킷은 민감하므로 이 안내서 뒷부분의 Amazon S3를 중앙 로그 스토어로 사용 섹션에 설명된 모범 사례에 따라 버킷을 보호해야 합니다. AWS 조직의 모든 계정은 트레일 목록에서 조직 트레일을 볼 수 있습니다. 하지만 회원 AWS 계정은 이 트레일에 대한 보기 전용 액세스 권한을 가집니다. 기본적으로 CloudTrail 콘솔에서 조직 트레일을 생성하면 트레일은 멀티 리전 트레일이 됩니다. 추가 보안 모범 사례는 AWS CloudTrail 설명서를 참조하십시오.

AWS SRA에서 보안 도구 계정은 관리를 위임받은 관리자 계정입니다. CloudTrail 조직 트레일 로그를 저장하는 해당 S3 버킷이 Log Archive 계정에 생성됩니다. 이는 CloudTrail 로그 권한의 관리와 사용을 분리하기 위한 것입니다. 조직 트레일의 로그 파일을 저장하기 위해 S3 버킷을 생성하거나 업데이트하는 방법에 대한 자세한 내용은 AWS CloudTrail 설명서를 참조하십시오.

참고

관리 및 위임된 관리자 계정 모두에서 조직 트레일을 생성하고 관리할 수 있습니다. 하지만 관리 계정에 대한 액세스를 제한하고 사용 가능한 경우 위임된 관리자 기능을 사용하는 것이 가장 좋습니다.

설계 고려 사항

• 멤버 계정에 자체 계정의 CloudTrail 로그 파일에 액세스해야 하는 경우 중앙 S3 버킷에서 조직의 CloudTrail 로그 파일을 선택적으로 공유할 수 있습니다. 하지만 멤버 계정에 계정 로그에 로컬 CloudWatch 로그 그룹이 필요하거나 조직 트레일과 다르게 로그 관리 및 데이터 이벤트 (읽기 전용, 쓰기 전용, 관리 이벤트, 데이터 이벤트) 를 구성하려는 경우 적절한 제어 기능을 갖춘 로컬 트레일을 생성할 수 있습니다. CloudTrail 로컬 계정별 트레일은 추가 비용이 발생합니다.

AWS Security Hub

AWS Security Hub는 AWS의 보안 상태를 포괄적으로 파악하고 보안 업계 표준 및 모범 사례에 따라 환경을 점검할 수 있도록 지원합니다. Security Hub는 AWS 통합 서비스, 지원되는 타사 제품 및 사용자가 사용할 수 있는 기타 사용자 지정 보안 제품 전반에서 보안 데이터를 수집합니다. 이 서비스는 보안 추세를 지속적으로 모니터링 및 분석하고 우선 순위가 가장 높은 보안 문제를 식별하는 데 도움을 줍니다. 수집된 소스 외에도 Security Hub는 하나 이상의 보안 표준에 매핑되는 보안 제어로 대표되는 자체 결과를 생성합니다. 이러한 표준에는 AWS 기본 보안 모범 사례 (FSBP), 인터넷 보안 센터 (CIS) AWS 재단 벤치마크 v1.20 및 v1.4.0, 미국 표준기술연구소 (NIST) SP 800-53 개정 5, 결제 카드 산업 데이터 보안 표준 (PCI DSS) 및 서비스 관리형 표준이 포함됩니다. 현재 보안 표준 목록과 특정 보안 제어에 대한 세부 정보는 Security Hub 설명서의 Security Hub 표준 참조를 참조하십시오.

Security Hub는 AWS Organizations와 통합되어 AWS 조직의 모든 기존 및 미래 계정에 대한 보안 상태 관리를 간소화합니다. 위임된 관리자 계정 (이 경우 Security Tooling) 에서 Security Hub 중앙 구성 기능을 사용하여 Security Hub 서비스, 보안 표준 및 보안 제어를 여러 지역의 조직 계정 및 OU (조직 구성 단위) 에 구성하는 방법을 지정할 수 있습니다. 홈 지역이라고 하는 기본 지역에서 몇 단계만 거치면 이러한 설정을 구성할 수 있습니다. 중앙 구성을 사용하지 않는 경우 각 계정 및 리전에서 개별적으로 Security Hub를 구성해야 합니다. 위임된 관리자는 계정과 OU를 자체 관리형으로 지정하여 구성원이 각 지역에서 개별적으로 설정을 구성할 수 있고, 중앙 관리형으로 지정하여 위임된 관리자가 여러 지역에 걸쳐 구성원 계정 또는 OU를 구성할 수 있습니다. 조직의 모든 계정과 OU를 중앙 관리형, 자체 관리형 또는 이 둘의 조합으로 지정할 수 있습니다. 따라서 일관된 구성을 간단하게 적용하는 동시에 각 OU 및 계정에 맞게 수정할 수 있는 유연성이 제공됩니다.

Security Hub 위임 관리자 계정은 모든 구성원 계정의 조사 결과를 보고, 통찰력을 보고, 세부 정보를 제어할 수도 있습니다. 위임된 관리자 계정 내에 집계 지역을 추가로 지정하여 계정 및 연결된 지역 전반에서 조사 결과를 중앙 집중화할 수 있습니다. 조사 결과는 애그리게이터 지역과 다른 모든 지역 간에 지속적이고 양방향으로 동기화됩니다.

Security Hub는 여러 AWS 서비스와의 통합을 지원합니다. 아마존 GuardDuty, AWS Config, 아마존 메이시, AWS IAM 액세스 분석기, AWS 방화벽 관리자, 아마존 인스펙터, AWS Systems Manager 패치 관리자는 조사 결과를 Security Hub에 제공할 수 있습니다. Security Hub는 AWS 보안 검색 결과 형식 (ASFF) 이라는 표준 형식을 사용하여 조사 결과를 처리합니다. Security Hub는 가장 중요한 제품을 우선 순위로 지정할 수 있도록 모든 통합 제품 간의 조사 결과를 상호 연관시킵니다. Security Hub 검색 결과의 메타데이터를 보강하여 보안 탐지 결과의 컨텍스트를 더 잘 파악하고, 우선 순위를 지정하고, 조치를 취하는 데 도움이 될 수 있습니다. 이 보강은 Security Hub에 수집된 모든 검색 결과에 리소스 태그, 새 AWS 애플리케이션 태그 및 계정 이름 정보를 추가합니다. 이를 통해 자동화 규칙의 결과를 세밀하게 조정하고, 결과 및 통찰력을 검색 또는 필터링하고, 애플리케이션별 보안 상태 상태를 평가할 수 있습니다. 또한 자동화 규칙을 사용하여 결과를 자동으로 업데이트할 수 있습니다. Security Hub는 탐지 결과를 수집할 때 조사 결과 제외, 심각도 변경, 조사 결과에 메모 추가 등 다양한 규칙 조치를 적용할 수 있습니다. 이러한 규칙 조치는 검색 결과가 지정된 기준 (예: 검색 결과와 관련된 리소스 또는 계정 ID, 제목) 과 일치할 때 적용됩니다. 자동화 규칙을 사용하여 ASFF에서 선택한 검색 결과 필드를 업데이트할 수 있습니다. 규칙은 새 결과와 업데이트된 결과 모두에 적용됩니다.

보안 이벤트를 조사하는 동안 Security Hub에서 Amazon Detective로 이동하여 아마존의 조사 결과를 조사할 수 있습니다. GuardDuty Security Hub는 원활한 통합을 위해 위임된 관리자 계정을 Detective (있는 경우) 와 같은 서비스에 맞게 조정할 것을 권장합니다. 예를 들어 Detective와 Security Hub 간에 관리자 계정을 정렬하지 않으면 검색 결과에서 Detective로 탐색할 수 없습니다. 전체 목록은 Security Hub 설명서에서 Security Hub와의 AWS 서비스 통합 개요를 참조하십시오.

Security Hub를 Amazon VPC의 네트워크 액세스 분석기 기능과 함께 사용하면 AWS 네트워크 구성의 규정 준수를 지속적으로 모니터링할 수 있습니다. 이렇게 하면 원치 않는 네트워크 액세스를 차단하고 중요한 리소스의 외부 액세스를 방지하는 데 도움이 됩니다. 아키텍처 및 구현에 대한 자세한 내용은 AWS 블로그 게시물 Amazon VPC 네트워크 액세스 분석기 및 AWS Security Hub를 사용한 네트워크 규정 준수의 지속적 검증을 참조하십시오.

Security Hub는 모니터링 기능 외에도 Amazon과의 통합을 EventBridge 지원하여 특정 발견의 수정을 자동화합니다. 검색 결과 수신 시 취할 사용자 지정 조치를 정의할 수 있습니다. 예를 들어 조사 결과를 티켓팅 시스템 또는 자동 문제 해결 시스템으로 전송하도록 사용자 지정 작업을 구성할 수 있습니다. 추가 논의와 예시는 AWS 블로그 게시물인 AWS Security Hub를 사용한 자동 응답 및 문제 해결 및 Security Hub 자동 응답 및 개선을 위한 AWS 솔루션을 배포하는 방법을 참조하십시오.

Security Hub는 서비스에 연결된 AWS Config 규칙을 사용하여 제어에 대한 대부분의 보안 검사를 수행합니다. 이러한 제어를 지원하려면 Security Hub가 활성화된 각 AWS 지역의 관리자 (또는 위임된 관리자) 계정과 멤버 계정을 포함한 모든 계정에서 AWS Config를 활성화해야 합니다.

설계 고려 사항

• PCI-DSS와 같은 규정 준수 표준이 Security Hub에 이미 있는 경우 완전 관리형 Security Hub 서비스를 사용하는 것이 이를 운영하는 가장 쉬운 방법입니다. 하지만 보안, 운영 또는 비용 최적화 검사를 포함할 수 있는 자체 규정 준수 또는 보안 표준을 구성하려는 경우, AWS Config Conformance Pack은 간소화된 사용자 지정 프로세스를 제공합니다. (AWS Config 및 규정 준수 팩에 대한 자세한 내용은 AWS Config 섹션을 참조하십시오.)

• Security Hub의 일반적인 사용 사례는 다음과 같습니다.

  • 애플리케이션 소유자에게 AWS 리소스의 보안 및 규정 준수 상태를 파악할 수 있는 가시성을 제공하는 대시보드로

  • 보안 운영, 사고 대응자, 위협 사냥꾼이 AWS 계정 및 지역 전반에서 AWS 보안 및 규정 준수 결과를 분류하고 조치를 취하기 위해 사용하는 보안 탐지 결과를 중앙에서 볼 수 있습니다.

  • AWS 계정 및 지역 전반의 보안 및 규정 준수 결과를 집계하여 중앙 집중식 보안 정보 및 이벤트 관리 (SIEM) 또는 기타 보안 오케스트레이션 시스템으로 라우팅합니다.

  설정 방법을 포함하여 이러한 사용 사례에 대한 추가 지침은 블로그 게시물 세 가지 반복되는 Security Hub 사용 패턴 및 배포 방법을 참조하십시오.

구현 예제

AWS SRA 코드 라이브러리는 Security Hub의 샘플 구현을 제공합니다. 여기에는 서비스의 자동 활성화, 회원 계정에 대한 위임 관리 (보안 도구), AWS 조직의 모든 기존 및 미래 계정에 대해 Security Hub를 활성화하는 구성이 포함됩니다.

아마존 GuardDuty

GuardDutyAmazon은 악의적인 활동과 무단 행동을 지속적으로 모니터링하여 AWS 계정과 워크로드를 보호하는 위협 탐지 서비스입니다. 모니터링 및 감사 목적으로는 항상 적절한 로그를 캡처하고 저장해야 하지만 Amazon은 AWS, Amazon VPC 흐름 로그 및 AWS CloudTrail DNS 로그에서 직접 독립적인 데이터 스트림을 GuardDuty 가져옵니다. Amazon S3 버킷 정책을 관리하거나 로그 수집 및 저장 방식을 수정할 필요가 없습니다. GuardDuty권한은 서비스 연결 역할로 관리되며, 비활성화하여 언제든지 취소할 수 있습니다. GuardDuty 따라서 복잡한 구성 없이 서비스를 쉽게 활성화할 수 있으며 IAM 권한 수정 또는 S3 버킷 정책 변경이 서비스 운영에 영향을 미칠 위험을 없앨 수 있습니다.

기본 데이터 소스를 제공하는 것 외에도 보안 탐지 결과를 식별할 수 있는 선택적 기능을 GuardDuty 제공합니다. 여기에는 EKS 보호, RDS 보호, S3 보호, 멀웨어 보호 및 Lambda 보호가 포함됩니다. 새 탐지기의 경우 이러한 선택적 기능이 기본적으로 활성화되지만 EKS 보호는 수동으로 활성화해야 합니다.

• GuardDuty S3 Protection을 사용하면 기본 CloudTrail 관리 이벤트 CloudTrail 외에도 Amazon S3 데이터 이벤트를 GuardDuty 모니터링합니다. 데이터 이벤트를 모니터링하면 객체 수준 API 작업을 GuardDuty 모니터링하여 S3 버킷 내 데이터에 대한 잠재적 보안 위험을 확인할 수 있습니다.

• GuardDuty 멀웨어 보호는 연결된 Amazon Elastic Block Store (Amazon EBS) 볼륨에서 에이전트 없는 스캔을 시작하여 Amazon EC2 인스턴스 또는 컨테이너 워크로드에 멀웨어가 있는지 탐지합니다.

• GuardDuty RDS Protection은 데이터베이스 성능에 영향을 주지 않으면서 Amazon Aurora 데이터베이스에 대한 액세스 활동을 프로파일링하고 모니터링하도록 설계되었습니다.

• GuardDuty EKS 보호에는 EKS 감사 로그 모니터링 및 EKS 런타임 모니터링이 포함됩니다. EKS 감사 로그 모니터링을 사용하면 Amazon EKS 클러스터의 Kubernetes 감사 로그를 GuardDuty 모니터링하고 잠재적으로 악의적이고 의심스러운 활동이 있는지 분석합니다. EKS 런타임 모니터링은 GuardDuty 보안 에이전트 (Amazon EKS 애드온) 를 사용하여 개별 Amazon EKS 워크로드에 대한 런타임 가시성을 제공합니다. GuardDuty 보안 에이전트는 Amazon EKS 클러스터 내에서 잠재적으로 침해된 특정 컨테이너를 식별하는 데 도움을 줍니다. 또한 개별 컨테이너에서 기본 Amazon EC2 호스트 또는 더 광범위한 AWS 환경으로 권한을 에스컬레이션하려는 시도를 감지할 수 있습니다.

GuardDuty AWS Organizations를 통해 모든 계정에서 활성화되며, GuardDuty 위임된 관리자 계정 (이 경우 Security Tooling 계정) 에서 해당 보안 팀이 모든 결과를 확인하고 조치를 취할 수 있습니다. 

AWS Security Hub를 활성화하면 GuardDuty 검색 결과가 자동으로 Security Hub로 전달됩니다. Amazon Detective를 활성화하면 탐지 GuardDuty 결과가 Detective 로그 수집 프로세스에 포함됩니다. GuardDuty 및 Detective는 크로스 서비스 사용자 워크플로를 지원합니다. 이 워크플로우에서는 선택한 검색 결과에서 해당 결과를 조사하기 위한 선별된 시각화 세트가 포함된 Detective 페이지로 리디렉션되는 콘솔의 링크를 GuardDuty 제공합니다. 예를 들어 GuardDuty EventBridge Amazon과 통합하여 새로운 GuardDuty 결과에 대한 GuardDuty 응답 자동화와 같은 모범 사례를 자동화할 수도 있습니다.

구현 예제

AWS SRA 코드 라이브러리는 GuardDuty Amazon의 샘플 구현을 제공합니다. 여기에는 암호화된 S3 버킷 구성, 위임 관리, AWS GuardDuty 조직의 모든 기존 및 미래 계정에 대한 지원이 포함됩니다.

AWS Config

AWS Config는 AWS 계정에서 지원되는 AWS 리소스의 구성을 평가, 감사 및 평가할 수 있는 서비스입니다. AWS Config는 AWS 리소스 구성을 지속적으로 모니터링 및 기록하고 기록된 구성을 원하는 구성과 비교하여 자동으로 평가합니다. 또한 AWS Config를 다른 서비스와 통합하여 자동화된 감사 및 모니터링 파이프라인에서 힘든 작업을 수행할 수 있습니다. 예를 들어, AWS Config는 AWS Secrets Manager에서 개별 비밀의 변경 사항을 모니터링할 수 있습니다. 

AWS Config 규칙을 사용하여 AWS 리소스의 구성 설정을 평가할 수 있습니다. AWS Config는 관리형 규칙이라고 하는 사용자 지정 가능하고 사전 정의된 규칙 라이브러리를 제공하거나 사용자가 직접 사용자 지정 규칙을 작성할 수 있습니다. AWS Config 규칙은 사전 예방 모드 (리소스 배포 전) 또는 탐지 모드 (리소스 배포 후) 에서 실행할 수 있습니다. 구성 변경이 발생할 때, 주기적인 일정에 따라 또는 둘 다에 따라 리소스를 평가할 수 있습니다.

규정 준수 팩은 AWS Config 규칙 및 수정 조치의 모음으로, 계정과 지역 내에서 단일 엔티티로 배포하거나 AWS Organizations에서는 조직 전체에 배포할 수 있습니다. 규정 준수 팩은 AWS Config 관리형 또는 사용자 지정 규칙 및 수정 조치 목록이 포함된 YAML 템플릿을 작성하여 생성됩니다. AWS 환경 평가를 시작하려면 샘플 적합성 팩 템플릿 중 하나를 사용하십시오. 

AWS Config는 AWS Security Hub와 통합되어 AWS Config 관리형 및 사용자 지정 규칙 평가의 결과를 Security Hub로 전송합니다. 

AWS Config 규칙을 AWS Systems Manager와 함께 사용하면 규정을 준수하지 않는 리소스를 효과적으로 수정할 수 있습니다. AWS Systems Manager Explorer를 사용하여 여러 AWS 지역의 AWS 계정에 있는 AWS Config 규칙의 규정 준수 상태를 수집한 다음 Systems Manager 자동화 문서 (런북) 를 사용하여 규정을 준수하지 않는 AWS Config 규칙을 해결합니다. 구현 세부 정보는 AWS Systems Manager Automation 런북을 사용하여 규정을 준수하지 않는 AWS Config 규칙을 수정하는 블로그 게시물을 참조하십시오.

AWS Config 애그리게이터는 AWS Organizations의 여러 계정, 지역 및 조직에 대한 구성 및 규정 준수 데이터를 수집합니다. 애그리게이터 대시보드에는 집계된 리소스의 구성 데이터가 표시됩니다. 인벤토리 및 규정 준수 대시보드는 AWS 계정 전체, AWS 지역 또는 AWS 조직 내 AWS 리소스 구성 및 규정 준수 상태에 대한 필수 최신 정보를 제공합니다. 이를 통해 AWS Config 고급 쿼리를 작성할 필요 없이 AWS 리소스 인벤토리를 시각화하고 평가할 수 있습니다. 리소스별 규정 준수 요약, 리소스를 준수하지 않는 상위 10개 계정, 유형별 실행 중인 EC2 인스턴스와 중지된 EC2 인스턴스 비교, 볼륨 유형 및 크기별 EBS 볼륨과 같은 필수 통찰력을 얻을 수 있습니다.

AWS Control Tower를 사용하여 AWS 조직을 관리하는 경우, AWS Config 규칙 세트를 탐정 가드레일 (필수, 강력 권장 또는 선택으로 분류) 로 배포합니다. 이러한 가드레일을 사용하면 AWS 조직 내 계정 전반에서 리소스를 관리하고 규정 준수를 모니터링할 수 있습니다. 이러한 AWS Config 규칙은 값이 인 aws-control-tower 태그를 자동으로 사용합니다. managed-by-control-tower

보호하려는 리소스가 있는 AWS 조직 및 AWS 리전의 각 멤버 계정에 대해 AWS Config를 활성화해야 합니다. AWS 조직 내 모든 계정의 AWS Config 규칙을 중앙에서 관리 (예: 생성, 업데이트, 삭제) 할 수 있습니다. AWS Config 위임 관리자 계정에서 모든 계정에 공통된 AWS Config 규칙 세트를 배포하고 AWS Config 규칙을 생성하지 말아야 하는 계정을 지정할 수 있습니다. 또한 AWS Config 위임 관리자 계정은 모든 멤버 계정의 리소스 구성 및 규정 준수 데이터를 집계하여 단일 보기를 제공할 수 있습니다. 위임된 관리자 계정의 API를 사용하여 AWS 조직의 구성원 계정이 기본 AWS Config 규칙을 수정할 수 없도록 함으로써 거버넌스를 적용할 수 있습니다.

설계 고려 사항

• AWS Config는 구성 및 규정 준수 변경 알림을 Amazon에 스트리밍합니다. EventBridge 즉, 의 기본 필터링 기능을 사용하여 AWS Config 이벤트를 EventBridge 필터링하여 특정 유형의 알림을 특정 대상으로 라우팅할 수 있습니다. 예를 들어 특정 규칙 또는 리소스 유형에 대한 규정 준수 알림을 특정 이메일 주소로 보내거나 구성 변경 알림을 외부 IT 서비스 관리 (ITSM) 또는 구성 관리 데이터베이스 (CMDB) 도구로 라우팅할 수 있습니다. 자세한 내용은 블로그 게시물 AWS Config 모범 사례를 참조하십시오. 

• AWS Config 사전 규칙 평가를 사용하는 것 외에도 리소스 구성 규정 준수를 사전에 확인하는 policy-as-code 평가 도구인 AWS CloudFormation Guard를 사용할 수 있습니다. AWS CloudFormation Guard 명령줄 인터페이스 (CLI) 는 정책을 코드로 표현하는 데 사용할 수 있는 선언적 도메인 전용 언어 (DSL) 를 제공합니다. 또한, AWS CLI 명령을 사용하여 CloudFormation 변경 세트, JSON 기반 Terraform 구성 파일 또는 쿠버네티스 구성과 같은 JSON 형식 또는 YAML 형식의 구조화된 데이터를 검증할 수 있습니다. 작성 프로세스의 일부로 AWS CloudFormation Guard CLI를 사용하여 로컬에서 평가를 실행하거나 배포 파이프라인 내에서 실행할 수 있습니다. AWS Cloud Development Kit (AWS CDK) 애플리케이션이 있는 경우 cdk-nag를 사용하여 모범 사례를 사전에 확인할 수 있습니다.

구현 예제

AWS SRA 코드 라이브러리는 AWS Config 적합성 팩을 AWS 조직 내 모든 AWS 계정 및 지역에 배포하는 샘플 구현을 제공합니다. AWS Config Aggregator 모듈은 Org Management 계정 내 회원 계정 (보안 도구) 에 관리를 위임한 다음, AWS 조직의 모든 기존 및 향후 계정에 대해 위임된 관리자 계정 내에서 AWS Config Aggregator를 구성함으로써 AWS Config 애그리게이터를 구성할 수 있도록 도와줍니다. AWS Config 컨트롤 타워 관리 계정 모듈을 사용하여 조직 관리 계정 내에서 AWS Config를 활성화할 수 있습니다. AWS Config는 AWS Config를 활성화하지 않습니다.

Amazon Security Lake

Amazon Security Lake는 완전 관리형 보안 데이터 레이크 서비스입니다. Security Lake를 사용하여 AWS 환경, 서비스형 소프트웨어 (SaaS) 공급자, 온프레미스 및 타사 소스의 보안 데이터를 자동으로 중앙 집중화할 수 있습니다. Security Lake를 사용하면 보안 데이터보다 분석 도구 사용을 단순화하는 정규화된 데이터 소스를 구축할 수 있으므로 조직 전체의 보안 상태를 더 완벽하게 이해할 수 있습니다. 데이터 레이크는 Amazon Simple Storage Service(S3) 버킷에서 지원되며, 데이터에 대한 소유권은 사용자에게 있습니다. Security Lake는 AWS, 아마존 VPC, 아마존 Route 53 CloudTrail, 아마존 S3, AWS Lambda, 아마존 EKS 감사 로그를 포함한 AWS 서비스에 대한 로그를 자동으로 수집합니다.

AWS SRA는 로그 아카이브 계정을 Security Lake의 위임된 관리자 계정으로 사용할 것을 권장합니다. 위임된 관리자 계정을 설정하는 방법에 대한 자세한 내용은 보안 OU — 로그 아카이브 계정 섹션의 Amazon Security Lake를 참조하십시오. Security Lake 데이터에 액세스하거나 사용자 지정 ETL (추출, 변환, 로드) 함수를 사용하여 Security Lake 버킷에 기본이 아닌 로그를 작성하려는 보안 팀은 Security Tools 계정 내에서 작업해야 합니다.

Security Lake는 다양한 클라우드 제공업체의 로그, 타사 솔루션의 로그 또는 기타 사용자 지정 로그를 수집할 수 있습니다. 보안 도구 계정을 사용하여 ETL 함수를 수행하여 로그를 개방형 사이버 보안 스키마 프레임워크 (OCSF) 형식으로 변환하고 Apache Parquet 형식으로 파일을 출력하는 것이 좋습니다. Security Lake는 보안 도구 계정 및 AWS Lambda 함수 또는 AWS Glue 크롤러가 지원하는 사용자 지정 소스에 대한 적절한 권한을 가진 계정 간 역할을 생성하여 Security Lake용 S3 버킷에 데이터를 기록합니다.

Security Lake 관리자는 보안 도구 계정을 사용하고 Security Lake가 구독자로서 수집하는 로그에 대한 액세스를 요구하는 보안 팀을 구성해야 합니다. Security Lake는 두 종류의 구독자 액세스를 지원합니다.

• 데이터 액세스 — 구독자는 Security Lake의 Amazon S3 객체에 직접 액세스할 수 있습니다. Security Lake는 인프라 및 권한을 관리합니다. Security Tooling 계정을 Security Lake 데이터 액세스 구독자로 구성하면 Amazon Simple Queue Service (Amazon SQS) 를 통해 Security Lake 버킷의 새 객체에 대한 알림이 계정에 전달되고 Security Lake는 이러한 새 객체에 액세스할 수 있는 권한을 생성합니다.

• 쿼리 액세스 — 구독자는 Amazon Athena와 같은 서비스를 사용하여 S3 버킷의 AWS Lake Formation 테이블에서 소스 데이터를 쿼리할 수 있습니다. AWS Lake Formation을 사용하면 쿼리 액세스가 가능하도록 계정 간 액세스가 자동으로 설정됩니다. 보안 도구 계정을 Security Lake 쿼리 액세스 구독자로 구성하면 해당 계정에는 Security Lake 계정의 로그에 대한 읽기 전용 액세스 권한이 부여됩니다. 이 구독자 유형을 사용하면 AWS 리소스 액세스 관리자 (AWS RAM) 를 통해 보안 레이크 로그 아카이브 계정의 Athena 및 AWS Glue 테이블이 보안 도구 계정과 공유됩니다. 이 기능을 활성화하려면 계정 간 데이터 공유 설정을 버전 3으로 업데이트해야 합니다.

구독자 생성에 대한 자세한 내용은 Security Lake 설명서의 구독자 관리를 참조하십시오.

사용자 지정 소스를 수집하는 모범 사례는 Security Lake 설명서의 사용자 지정 소스에서 데이터 수집을 참조하십시오.

Amazon QuickSight OpenSearch, Amazon 및 SageMaker Amazon을 사용하여 Security Lake에 저장한 보안 데이터에 대한 분석을 설정할 수 있습니다.

설계 고려 사항

애플리케이션 팀이 비즈니스 요구 사항을 충족하기 위해 Security Lake 데이터에 대한 쿼리 액세스 권한이 필요한 경우 Security Lake 관리자는 해당 애플리케이션 계정을 구독자로 구성해야 합니다.

Amazon Macie

Amazon Macie는 기계 학습과 패턴 매칭을 사용하여 AWS의 민감한 데이터를 검색하고 보호하는 데 도움이 되는 완전 관리형 데이터 보안 및 데이터 개인 정보 보호 서비스입니다. 적절한 제어가 시행되도록 하려면 워크로드에서 처리하는 데이터의 유형과 분류를 식별해야 합니다. Macie를 사용하면 민감한 데이터 자동 검색을 수행하고 민감한 데이터 검색 작업을 생성 및 실행하는 두 가지 방법으로 민감한 데이터의 검색 및 보고를 자동화할 수 있습니다. 민감한 데이터 자동 검색을 통해 Macie는 매일 S3 버킷 인벤토리를 평가하고 샘플링 기법을 사용하여 버킷에서 대표적인 S3 객체를 식별하고 선택합니다. 그런 다음 Macie는 선택한 객체를 검색 및 분석하여 민감한 데이터가 있는지 검사합니다. 민감한 데이터 검색 작업은 더 심층적이고 표적화된 분석을 제공합니다. 이 옵션을 사용하면 분석할 S3 버킷, 샘플링 깊이, S3 객체의 속성에서 파생되는 사용자 지정 기준 등 분석의 범위와 심도를 정의합니다. Macie가 버킷의 보안 또는 프라이버시와 관련된 잠재적 문제를 탐지하면 Macie가 정책 조사 결과를 생성합니다. 자동 데이터 검색은 모든 신규 Macie 고객에게 기본적으로 활성화되며, 기존 Macie 고객은 클릭 한 번으로 이를 활성화할 수 있습니다.

Macie는 AWS Organizations를 통해 모든 계정에서 활성화됩니다. 위임된 관리자 계정 (이 경우 Security Tools 계정) 에서 적절한 권한을 가진 주체는 모든 계정에서 Macie를 활성화 또는 일시 중단하고, 멤버 계정이 소유한 버킷에 대한 민감한 데이터 검색 작업을 생성하고, 모든 회원 계정에 대한 모든 정책 결과를 볼 수 있습니다. 민감한 데이터 검색 결과는 민감한 검색 결과 작업을 만든 계정만 볼 수 있습니다. 자세한 내용은 Macie 설명서의 Amazon Macie에서 여러 계정 관리를 참조하십시오.

Macie의 조사 결과는 검토 및 분석을 위해 AWS Security Hub로 전달됩니다. 또한 Macie는 Amazon과 EventBridge 통합하여 경고, 보안 정보 및 이벤트 관리 (SIEM) 시스템에 대한 피드, 자동 수정과 같은 결과에 대한 자동 대응을 용이하게 합니다.

설계 고려 사항

• 관리하는 AWS KMS (AWS Key Management Service) 키로 S3 객체를 암호화하는 경우, Macie가 데이터를 스캔할 수 있도록 Macie 서비스 연결 역할을 KMS 키에 키 사용자로 추가할 수 있습니다.

• Macie는 Amazon S3에서 객체를 스캔하는 데 최적화되어 있습니다. 따라서 Amazon S3에 영구 또는 일시적으로 배치할 수 있는 모든 Macie 지원 객체 유형을 스캔하여 민감한 데이터를 찾을 수 있습니다. 즉, Amazon Relational Database Service (Amazon RDS) 또는 Amazon Aurora 데이터베이스의 주기적 스냅샷 내보내기, 내보낸 Amazon DynamoDB 테이블, 네이티브 또는 타사 애플리케이션에서 추출한 텍스트 파일 등 다른 소스의 데이터를 Amazon S3로 이동하고 Macie에서 평가할 수 있습니다.

구현 예제

AWS SRA 코드 라이브러리는 Amazon Macie의 샘플 구현을 제공합니다. 여기에는 회원 계정에 관리를 위임하고 AWS 조직의 모든 기존 및 향후 계정에 대해 위임된 관리자 계정 내에서 Macie를 구성하는 작업이 포함됩니다. 또한 Macie는 AWS KMS의 고객 관리 키로 암호화된 중앙 S3 버킷으로 결과를 전송하도록 구성되어 있습니다.

AWS IAM 액세스 분석기

AWS 클라우드 도입 여정을 가속화하고 혁신을 지속함에 따라 세분화된 액세스 (권한) 에 대한 엄격한 제어를 유지하고, 액세스 확산을 억제하고, 권한이 효과적으로 사용되도록 하는 것이 중요합니다. 과도한 미사용 액세스는 보안 문제를 야기하고 기업이 최소 권한 원칙을 시행하기 어렵게 만듭니다. 이 원칙은 보안 요구 사항과 운영 및 애플리케이션 개발 요구 사항의 균형을 유지하기 위해 IAM 권한의 크기를 지속적으로 적절하게 조정하는 것을 포함하는 중요한 보안 아키텍처 기둥입니다. 이러한 노력에는 중앙 보안 및 Cloud Center of Excellence (CCoE) 팀과 분산된 개발 팀을 비롯한 여러 이해 관계자가 참여합니다.

AWS IAM Access Analyzer는 엔터프라이즈 보안 표준을 충족하는 데 도움이 되도록 미사용 액세스를 제거하여 세분화된 권한을 효율적으로 설정하고, 의도한 권한을 확인하고, 권한을 세분화하는 도구를 제공합니다. 대시보드와 AWS Security Hub를 통해 외부 및 미사용 액세스 결과를 파악할 수 있습니다. 또한 이벤트 기반 사용자 지정 알림 및 수정 EventBridge 워크플로를 위해 Amazon을 지원합니다.

IAM Access Analyzer의 외부 조사 결과 기능을 사용하면 외부 엔티티와 공유되는 Amazon S3 버킷 또는 IAM 역할과 같은 AWS 조직 및 계정의 리소스를 식별할 수 있습니다. 선택한 AWS 조직 또는 계정을 신뢰 영역이라고 합니다. 분석기는 자동 추론을 사용하여 신뢰 영역 내에서 지원되는 모든 리소스를 분석하고 신뢰 영역 외부에서 리소스에 액세스할 수 있는 보안 주체에 대한 결과를 생성합니다. 이러한 결과는 외부 엔티티와 공유되는 리소스를 식별하고 리소스 권한을 배포하기 전에 정책이 리소스에 대한 공개 및 계정 간 액세스에 미치는 영향을 미리 보는 데 도움이 됩니다.

IAM Access Analyzer 조사 결과는 다음을 포함하여 AWS 조직 및 계정에 부여된 미사용 액세스를 식별하는 데도 도움이 됩니다.

• 미사용 IAM 역할 — 지정된 사용 기간 내에 액세스 활동이 없는 역할.

• 미사용 IAM 사용자, 자격 증명, 액세스 키 — IAM 사용자에게 속하며 AWS 서비스 및 리소스에 액세스하는 데 사용되는 자격 증명입니다.

• 미사용 IAM 정책 및 권한 — 지정된 사용 기간 내에 역할이 사용하지 않은 서비스 수준 및 작업 수준 권한. IAM Access Analyzer는 역할에 연결된 ID 기반 정책을 사용하여 해당 역할이 액세스할 수 있는 서비스와 작업을 결정합니다. 분석기는 모든 서비스 수준 권한에 대해 사용되지 않은 권한을 검토합니다.

IAM Access Analyzer에서 생성된 결과를 사용하여 조직의 정책 및 보안 표준에 따라 의도하지 않았거나 사용되지 않은 액세스를 파악하고 문제를 해결할 수 있습니다. 수정 후에는 다음 번에 분석기를 실행할 때 이러한 결과가 해결된 것으로 표시됩니다. 검색 결과가 의도적인 경우 IAM Access Analyzer에 보관된 것으로 표시하고 보안 위험이 더 큰 다른 검색 결과에 우선 순위를 지정할 수 있습니다. 또한 특정 결과를 자동으로 보관하도록 보관 규칙을 설정할 수 있습니다. 예를 들어, 정기적으로 액세스 권한을 부여한 특정 Amazon S3 버킷에 대한 조사 결과를 자동으로 아카이브하는 아카이브 규칙을 생성할 수 있습니다.

빌더는 IAM Access Analyzer를 사용하여 개발 및 배포 (CI/CD) 프로세스 초기에 자동화된 IAM 정책 검사를 수행하여 기업 보안 표준을 준수할 수 있습니다. IAM Access Analyzer의 사용자 지정 정책 검사 및 정책 검토를 AWS와 CloudFormation 통합하여 개발 팀의 CI/CD 파이프라인의 일부로서 정책 검토를 자동화할 수 있습니다. 여기에는 다음이 포함됩니다.

• IAM 정책 검증 — IAM 액세스 분석기는 IAM 정책 문법 및 AWS 모범 사례에 따라 정책을 검증합니다. 보안 경고, 오류, 일반 경고, 정책 제안 등 정책 검증 검사 결과를 볼 수 있습니다. 현재 100개 이상의 정책 검증 검사가 가능하며, AWS 명령줄 인터페이스 (AWS CLI) 및 API를 사용하여 자동화할 수 있습니다.

• IAM 사용자 지정 정책 검사 — IAM Access Analyzer 사용자 지정 정책 검사는 지정된 보안 표준에 따라 정책을 검증합니다. 사용자 지정 정책 검사는 자동화된 추론을 사용하여 기업 보안 표준을 충족하는지 더 높은 수준의 보증을 제공합니다. 사용자 지정 정책 검사 유형에는 다음이 포함됩니다.

  • 참조 정책 비교: 정책을 편집할 때 기존 정책 버전과 같은 참조 정책과 비교하여 업데이트가 새 액세스를 허용하는지 확인할 수 있습니다. CheckNoNewAccessAPI는 두 정책 (업데이트된 정책과 참조 정책) 을 비교하여 업데이트된 정책으로 인해 참조 정책에 대한 새로운 액세스가 도입되는지 여부를 확인하고 합격 또는 실패 응답을 반환합니다.

  • IAM 작업 목록과 비교: CheckAccessNotGrantedAPI를 사용하여 보안 표준에 정의된 중요 조치 목록에 대한 액세스 권한을 정책에서 부여하지 않는지 확인할 수 있습니다. 이 API는 정책과 최대 100개의 IAM 작업 목록을 가져와 정책에서 하나 이상의 작업을 허용하는지 확인하고 합격 또는 실패 응답을 반환합니다.

보안팀 및 기타 IAM 정책 작성자는 IAM Access Analyzer를 사용하여 IAM 정책 문법 및 보안 표준을 준수하는 정책을 작성할 수 있습니다. 적절한 규모의 정책을 수동으로 작성하면 오류가 발생하기 쉽고 시간이 많이 걸릴 수 있습니다. IAM Access Analyzer 정책 생성 기능은 보안 주체의 액세스 활동을 기반으로 IAM 정책을 작성하는 데 도움이 됩니다. IAM Access Analyzer는 AWS CloudTrail 로그에서 지원되는 서비스를 검토하고 지정된 날짜 범위에서 보안 주체가 사용한 권한이 포함된 정책 템플릿을 생성합니다. 그런 다음 이 템플릿을 사용하여 필요한 권한만 부여하는 세분화된 권한이 포함된 정책을 생성할 수 있습니다.

• 계정에서 액세스 활동을 기반으로 정책을 생성하려면 CloudTrail 추적 기능이 활성화되어 있어야 합니다.

• IAM Access Analyzer는 생성된 정책에서 Amazon S3 데이터 이벤트와 같은 데이터 이벤트에 대한 작업 수준 활동을 식별하지 않습니다.

• iam:PassRole작업은 생성된 정책에 의해 추적되지 않으며 생성된 정책에 CloudTrail 포함되지 않습니다.

액세스 분석기는 AWS Organizations의 위임된 관리자 기능을 통해 보안 도구 계정에 배포됩니다. 위임된 관리자는 AWS 조직을 신뢰 영역으로 삼아 분석기를 만들고 관리할 권한이 있습니다.

설계 고려 사항

• 계정 범위 분석 결과 (계정이 신뢰할 수 있는 경계 역할을 함) 를 얻으려면 각 멤버 계정에 계정 범위 분석기를 생성해야 합니다. 이는 계정 파이프라인의 일부로 수행할 수 있습니다. 계정 범위의 조사 결과는 회원 계정 수준에서 Security Hub로 전달됩니다. 그런 다음 Security Hub 위임 관리자 계정 (보안 도구) 으로 이동합니다.

구현 예제

• AWS SRA 코드 라이브러리는 IAM 액세스 분석기의 샘플 구현을 제공합니다. 위임된 관리자 계정 내에 조직 수준 분석기를 구성하고 각 계정 내에 계정 수준 분석기를 구성하는 방법을 보여줍니다.

• 사용자 지정 정책 검사를 빌더 워크플로에 통합하는 방법에 대한 자세한 내용은 IAM Access Analyzer 사용자 지정 정책 검사를 소개하는 AWS 블로그 게시물을 참조하십시오.

AWS Firewall Manager

AWS Firewall Manager는 여러 계정과 리소스에서 AWS WAF, AWS Shield Advanced, Amazon VPC 보안 그룹, AWS 네트워크 방화벽 및 Route 53 Resolver DNS 방화벽에 대한 관리 및 유지 관리 작업을 단순화하여 네트워크를 보호하는 데 도움이 됩니다. Firewall Manager를 사용하면 AWS WAF 방화벽 규칙, Shield Advanced 보호, Amazon VPC 보안 그룹, AWS 네트워크 방화벽, DNS 방화벽 규칙 그룹 연결을 한 번만 설정할 수 있습니다. 새 계정을 추가하는 즉시 서비스에서 계정과 리소스 전체에 규칙과 보호가 자동으로 적용됩니다.

Firewall Manager는 소수의 특정 계정 및 리소스 대신 전체 AWS 조직을 보호하려는 경우 또는 보호하려는 새 리소스를 자주 추가하는 경우에 특히 유용합니다. Firewall Manager는 보안 정책을 사용하여 배포해야 하는 관련 규칙, 보호 및 작업과 포함하거나 제외할 계정 및 리소스 (태그로 표시) 를 비롯한 일련의 구성을 정의할 수 있도록 합니다. 세분화되고 유연한 구성을 생성하는 동시에 많은 계정과 VPC로 제어를 확장할 수 있습니다. 이러한 정책은 새 계정과 리소스가 생성되는 경우에도 구성한 규칙을 자동으로 일관되게 적용합니다. Firewall Manager는 AWS Organizations를 통해 모든 계정에서 활성화되며, 구성 및 관리는 Firewall Manager가 위임한 관리자 계정 (이 경우에는 보안 도구 계정) 의 적절한 보안 팀이 수행합니다. 

보호하려는 리소스가 포함된 각 AWS 리전에 대해 AWS Config를 활성화해야 합니다. 모든 리소스에 대해 AWS Config를 활성화하지 않으려면 사용하는 Firewall Manager 정책 유형과 관련된 리소스에 대해 AWS Config를 활성화해야 합니다. AWS Security Hub와 Firewall Manager를 둘 다 사용하는 경우, Firewall Manager는 탐지 결과를 Security Hub에 자동으로 전송합니다. Firewall Manager는 규정을 준수하지 않는 리소스와 탐지한 공격에 대한 검색 결과를 생성하여 Security Hub에 결과를 보냅니다. AWS WAF용 Firewall Manager 정책을 설정하면 범위 내 모든 계정에 대해 웹 액세스 제어 목록 (웹 ACL) 에 로깅을 중앙에서 활성화하고 로그를 단일 계정으로 중앙 집중화할 수 있습니다. 

설계 고려 사항

• AWS 조직 내 개별 구성원 계정의 계정 관리자는 특정 요구 사항에 따라 Firewall Manager 관리형 서비스에서 추가 제어 항목 (예: AWS WAF 규칙 및 Amazon VPC 보안 그룹) 을 구성할 수 있습니다.

구현 예제

AWS SRA 코드 라이브러리는 AWS 방화벽 관리자의 샘플 구현을 제공합니다. 위임 관리 (보안 도구) 를 보여주고, 허용된 최대 보안 그룹을 배포하고, 보안 그룹 정책을 구성하고, 여러 WAF 정책을 구성합니다.

아마존 EventBridge

EventBridgeAmazon은 애플리케이션을 다양한 소스의 데이터에 쉽게 연결할 수 있는 서버리스 이벤트 버스 서비스입니다. 보안 자동화에 자주 사용합니다. 모든 데이터 소스에 실시간으로 반응하는 애플리케이션 아키텍처를 구축하기 위해 라우팅 규칙을 설정하여 데이터를 어디로 보낼지 결정할 수 있습니다. 각 계정의 기본 이벤트 버스를 사용하는 것 외에도 사용자 지정 응용 프로그램에서 이벤트를 수신하도록 사용자 지정 이벤트 버스를 만들 수 있습니다. Security Tooling 계정에서 AWS 조직의 다른 계정으로부터 보안 관련 이벤트를 수신할 수 있는 이벤트 버스를 생성할 수 있습니다. 예를 들어, AWS Config 규칙과 Security Hub를 연결하면 보안 데이터를 라우팅하고 GuardDuty, 알림을 생성하고, 문제 해결을 위한 조치를 관리하기 위한 유연하고 자동화된 파이프라인을 생성할 수 있습니다. EventBridge  

설계 고려 사항

• EventBridge 이벤트를 다양한 대상으로 라우팅할 수 있습니다. 보안 작업을 자동화하는 데 유용한 패턴 중 하나는 적절한 조치를 취하는 개별 AWS Lambda 응답자에 특정 이벤트를 연결하는 것입니다. 예를 들어, 특정 상황에서는 퍼블릭 S3 버킷 검색 결과를 버킷 정책을 수정하고 퍼블릭 권한을 제거하는 Lambda 응답기로 라우팅하는 데 사용할 EventBridge 수 있습니다. 이러한 응답기를 조사 플레이북 및 런북에 통합하여 대응 활동을 조정할 수 있습니다.

• 성공적인 보안 운영 팀을 위한 모범 사례는 보안 이벤트 및 조사 결과의 흐름을 티켓 시스템, 버그/이슈 시스템 또는 기타 SIEM (보안 정보 및 이벤트 관리) 시스템과 같은 알림 및 워크플로 시스템에 통합하는 것입니다. 이를 통해 이메일과 정적 보고서의 워크플로를 없애고 이벤트 또는 조사 결과를 전달, 에스컬레이션 및 관리하는 데 도움이 됩니다. 의 유연한 라우팅 기능은 이러한 EventBridge 통합을 가능하게 하는 강력한 원동력입니다.

Amazon Detective

Amazon Detective는 보안 분석가를 위해 보안 탐지 결과 또는 의심스러운 활동의 근본 원인을 간단하게 분석, 조사 및 신속하게 식별할 수 있도록 함으로써 대응형 보안 제어 전략을 지원합니다. Detective는 AWS CloudTrail 로그 및 Amazon VPC 흐름 로그에서 로그인 시도, API 호출, 네트워크 트래픽과 같은 시간 기반 이벤트를 자동으로 추출합니다. Detective를 사용하여 최대 1년 분량의 과거 이벤트 데이터에 액세스할 수 있습니다. Detective는 독립적인 로그 CloudTrail 스트림과 Amazon VPC 흐름 로그를 사용하여 이러한 이벤트를 소비합니다. Detective는 머신 러닝과 시각화를 사용하여 시간 경과에 따른 리소스 동작과 리소스 간의 상호 작용에 대한 통합된 대화형 보기를 생성합니다. 이를 행동 그래프라고 합니다. 동작 그래프를 탐색하여 실패한 로그온 시도 또는 의심스러운 API 호출과 같은 다양한 작업을 검사할 수 있습니다.

Detective는 Amazon Security Lake와 통합되어 보안 분석가가 Security Lake에 저장된 로그를 쿼리하고 검색할 수 있도록 합니다. 이 통합을 사용하면 Detective에서 보안 조사를 수행하는 동안 Security Lake에 저장된 AWS CloudTrail 로그 및 Amazon VPC 흐름 로그에서 추가 정보를 얻을 수 있습니다.

Detective는 또한 런타임 모니터링으로 탐지된 위협을 포함하여 Amazon에서 GuardDuty 탐지한 GuardDuty 결과를 수집합니다. 계정이 Detective를 활성화하면 해당 계정이 행동 그래프의 관리자 계정이 됩니다. Detective를 활성화하기 전에 계정이 최소 48시간 동안 등록되어 GuardDuty 있는지 확인하십시오. 이 요구 사항을 충족하지 않으면 Detective를 활성화할 수 없습니다.

Detective는 단일 보안 침해 이벤트와 관련된 여러 결과를 검색 그룹으로 자동 그룹화합니다. 위협 행위자는 일반적으로 일련의 작업을 수행하여 시간과 리소스에 걸쳐 여러 보안 탐지 결과를 도출합니다. 따라서 여러 개체 및 조사 결과를 포함하는 조사의 출발점은 그룹을 찾는 것입니다. 또한 Detective는 검색 그룹을 자동으로 분석하고 보안 조사를 가속화하는 데 도움이 되는 자연어로 통찰력을 제공하는 생성 AI를 사용하여 검색 결과 그룹 요약을 제공합니다.

Detective는 AWS Organizations와 통합됩니다. 조직 관리 계정은 멤버 계정을 Detective 관리자 계정으로 위임합니다. AWS SRA에서는 이 계정이 보안 도구 계정입니다. Detective 관리자 계정은 조직의 모든 현재 회원 계정을 탐정 회원 계정으로 자동 활성화하고, AWS 조직에 추가되는 대로 새 회원 계정을 추가할 수 있습니다. 또한 Detective 관리자 계정은 현재 AWS 조직에 속하지 않지만 같은 지역 내에 있는 멤버 계정을 초대하여 기본 계정의 행동 그래프에 데이터를 제공할 수 있습니다. 멤버 계정이 초대를 수락하고 활성화되면 Detective는 멤버 계정의 데이터를 수집하고 해당 동작 그래프로 추출하기 시작합니다.

설계 고려 사항

• GuardDuty 및 AWS Security Hub 콘솔에서 Detective로 이동하여 프로필을 찾을 수 있습니다. 이 링크는 조사 프로세스를 간소화하는 데 도움이 될 수 있습니다. 계정은 Detective와 사용자가 피벗하는 서비스 (또는 Security GuardDuty Hub) 의 관리자 계정이어야 합니다. 서비스의 기본 계정이 동일한 경우 통합 링크가 원활하게 작동합니다.

AWS Audit Manager

AWS Audit Manager를 사용하면 AWS 사용을 지속적으로 감사하여 감사를 관리하고 규정 및 업계 표준을 준수하는 방법을 간소화할 수 있습니다. 이를 통해 증거를 수동으로 수집, 검토 및 관리하는 것에서 증거 수집을 자동화하고, 감사 증거의 출처를 추적하는 간단한 방법을 제공하고, 팀워크 협업을 가능하게 하고, 증거 보안 및 무결성을 관리하는 솔루션으로 전환할 수 있습니다. 감사 시기에 Audit Manager는 귀하의 제어에 대한 이해 관계자들의 검토를 관리할 수 있습니다.

Audit Manager를 사용하면 인터넷 보안 센터 (CIS) 벤치마크, CIS AWS Foundation Benchmark, SOC 2 (시스템 및 조직 통제 2), PCI DSS (결제 카드 산업 데이터 보안 표준) 와 같은 사전 구축된 프레임워크를 기준으로 감사할 수 있습니다. 또한 내부 감사를 위한 특정 요구 사항에 따라 표준 또는 사용자 지정 제어를 사용하여 자체 프레임워크를 만들 수 있습니다.

Audit Manager는 네 가지 유형의 증거를 수집합니다. AWS Config 및 AWS Security Hub의 규정 준수 검사 증거, AWS에서 제공하는 관리 이벤트 증거 CloudTrail, AWS service-to-service API 호출에서 얻은 구성 증거 등 세 가지 유형의 증거가 자동화됩니다. 자동화할 수 없는 증거의 경우 Audit Manager를 사용하여 수동 증거를 업로드할 수 있습니다.

참고

Audit Manager는 특정 규정 준수 표준 및 규정 준수 확인과 관련된 증거 수집을 지원합니다. 하지만 규정 준수를 평가하지는 않습니다. 따라서 Audit Manager를 통해 수집된 증거에는 감사에 필요한 운영 프로세스의 세부 정보가 포함되지 않을 수 있습니다. Audit Manager는 법률 고문이나 규정 준수 전문가를 대신할 수 없습니다. 평가 대상 규정 준수 프레임워크에 대한 인증을 받은 타사 평가자의 서비스를 이용하는 것이 좋습니다.

Audit Manager 평가는 AWS 조직의 여러 계정을 대상으로 실행할 수 있습니다. Audit Manager는 증거를 수집하여 AWS Organizations의 위임된 관리자 계정으로 통합합니다. 이 감사 기능은 주로 규정 준수 및 내부 감사 팀에서 사용하며, AWS 계정에 대한 읽기 액세스만 필요합니다.

설계 고려 사항

• Audit Manager는 Security Hub 및 AWS Config와 같은 다른 AWS 보안 서비스를 보완하여 위험 관리 프레임워크를 구현하는 데 도움을 줍니다. Audit Manager는 독립적인 위험 보장 기능을 제공하는 반면, Security Hub는 위험을 감독하는 데 도움이 되며 AWS Config 적합성 팩은 위험 관리를 지원합니다. 내부 감사 협회 (IIA) 에서 개발한 3선 모델에 익숙한 감사 전문가는 이러한 AWS 서비스 조합이 세 가지 방어선을 포괄하는 데 도움이 된다는 점에 유의해야 합니다. 자세한 내용은 AWS 클라우드 운영 및 마이그레이션 블로그에서 2부로 구성된 블로그 시리즈를 참조하십시오.

• Audit Manager가 Security Hub 증거를 수집하려면 두 서비스의 위임된 관리자 계정이 동일한 AWS 계정이어야 합니다. 이러한 이유로 AWS SRA에서는 보안 도구 계정이 Audit Manager의 위임 관리자입니다.

AWS Artifact

AWS Artifact는 보안 도구 계정 내에 호스팅되어 규정 준수 아티팩트 관리 기능을 AWS Org Management 계정과 분리합니다. 꼭 필요한 경우가 아니면 AWS Org Management 계정을 배포에 사용하지 않는 것이 좋기 때문에 이러한 업무 분리가 중요합니다. 대신 회원 계정에 배포를 전달하십시오. 멤버 계정에서 감사 아티팩트 관리를 수행할 수 있고 기능이 보안 및 규정 준수 팀과 긴밀하게 연계되므로 Security Tooling 계정이 AWS Artifact의 관리자 계정으로 지정됩니다. AWS Artifact 보고서를 사용하여 AWS ISO 인증, 결제 카드 산업 (PCI), 시스템 및 조직 규제 (SOC) 보고서와 같은 AWS 보안 및 규정 준수 문서를 다운로드할 수 있습니다.

AWS Artifact는 위임 관리 기능을 지원하지 않습니다. 대신 이 기능을 감사 및 규정 준수 팀과 관련된 Security Tooling 계정의 IAM 역할로만 제한하여 필요에 따라 외부 감사자가 보고서를 다운로드, 검토하고 외부 감사자에게 제공할 수 있도록 할 수 있습니다. 또한 IAM 정책을 통해 특정 IAM 역할이 특정 AWS Artifact 보고서에만 액세스하도록 제한할 수 있습니다. 샘플 IAM 정책은 AWS Artifact 설명서를 참조하십시오.

설계 고려 사항

• 감사 및 규정 준수 팀을 위한 전용 AWS 계정을 선택한 경우 보안 도구 계정과는 별도의 보안 감사 계정에서 AWS Artifact를 호스팅할 수 있습니다. AWS Artifact 보고서는 조직이 문서화된 프로세스를 따르고 있거나 특정 요구 사항을 충족하고 있음을 보여주는 증거를 제공합니다. 감사 아티팩트는 시스템 개발 수명 주기 전반에 걸쳐 수집 및 보관되며 내부 또는 외부 감사 및 평가에서 증거로 사용할 수 있습니다.

AWS KMS

AWS Key Management Service(AWS KMS)를 사용하면 암호화 키를 생성 및 관리하고 광범위한 AWS 서비스와 애플리케이션에서 해당 키의 사용을 제어할 수 있습니다. AWS KMS는 하드웨어 보안 모듈을 사용하여 암호화 키를 보호하는 안전하고 복원력이 뛰어난 서비스입니다. 키 저장, 교체 및 액세스 제어와 같은 주요 자료에 대한 업계 표준 수명 주기 프로세스를 따릅니다. AWS KMS는 암호화 및 서명 키로 데이터를 보호하는 데 도움이 되며, AWS Encryption SDK를 통해 서버 측 암호화와 클라이언트 측 암호화 모두에 사용할 수 있습니다. 보호 및 유연성을 위해 AWS KMS는 고객 관리 키, AWS 관리 키, AWS 소유 키 등 세 가지 유형의 키를 지원합니다. 고객 관리형 키는 사용자가 생성하고 소유하고 관리하는 AWS 계정의 AWS KMS 키입니다. AWS 관리형 키는 AWS KMS와 통합된 AWS 서비스에서 사용자를 대신하여 생성, 관리 및 사용되는 사용자 계정의 AWS KMS 키입니다. AWS 소유 키는 AWS 서비스가 여러 AWS 계정에서 사용하기 위해 소유하고 관리하는 AWS KMS 키 모음입니다. KMS 키 사용에 대한 자세한 내용은 AWS KMS 설명서 및 AWS KMS 암호화 세부 정보를 참조하십시오.

배포 옵션 중 하나는 키와 IAM 정책을 조합하여 애플리케이션 계정에서 키를 사용할 수 있는 권한을 애플리케이션 리소스별로 위임하면서 KMS 키 관리 책임을 단일 계정에 집중시키는 것입니다. 이 접근 방식은 안전하고 관리가 간단하지만, AWS KMS 제한, 계정 서비스 한도, 보안 팀의 운영 키 관리 작업 과제로 인해 문제가 발생할 수 있습니다. 또 다른 배포 옵션은 AWS KMS가 여러 계정에 상주하도록 허용하고 특정 계정의 인프라 및 워크로드를 담당하는 사람들이 자신의 키를 관리하도록 허용하는 분산 모델을 사용하는 것입니다. 이 모델을 사용하면 워크로드 팀이 암호화 키 사용에 대한 더 많은 제어, 유연성 및 민첩성을 확보할 수 있습니다. 또한 API 제한을 피하고, 영향 범위를 하나의 AWS 계정으로만 제한하고, 보고, 감사 및 기타 규정 준수 관련 작업을 간소화합니다. 탈중앙화 모델에서는 가드레일을 배포하고 적용하여 탈중앙화 키를 동일한 방식으로 관리하고 확립된 모범 사례 및 정책에 따라 KMS 키 사용을 감사하도록 하는 것이 중요합니다. 자세한 내용은 AWS Key Management Service 모범 사례 백서를 참조하십시오. AWS SRA는 KMS 키가 사용되는 계정 내에 로컬로 상주하는 분산 키 관리 모델을 권장합니다. 한 계정에서 모든 암호화 기능에 단일 키를 사용하지 않는 것이 좋습니다. 기능 및 데이터 보호 요구 사항에 따라 그리고 최소 권한 원칙을 적용하기 위해 키를 생성할 수 있습니다. 경우에 따라 암호화 권한은 암호 해독 권한과 분리되어 유지되며 관리자는 수명 주기 기능을 관리하지만 자신이 관리하는 키로 데이터를 암호화하거나 해독할 수는 없습니다. 

보안 도구 계정에서 AWS KMS는 AWS 조직에서 관리하는 CloudTrail AWS 조직 트레일과 같은 중앙 집중식 보안 서비스의 암호화를 관리하는 데 사용됩니다.

AWS Private CA

AWS Private Certificate Authority(AWS Private CA) 는 EC2 인스턴스, 컨테이너, IoT 디바이스 및 온프레미스 리소스에 대한 프라이빗 최종 엔티티 TLS 인증서의 수명 주기를 안전하게 관리하는 데 도움이 되는 관리형 사설 CA 서비스입니다. 이를 통해 실행 중인 애플리케이션과의 암호화된 TLS 통신이 가능합니다. 를 사용하면 고유한 CA 계층 구조 (루트 CA를 통해 최종 엔티티 인증서로) 를 만들고 이를 통해 인증서를 발급하여 내부 사용자, 컴퓨터, 애플리케이션, 서비스, 서버 및 기타 장치를 인증하고 컴퓨터 코드에 서명할 수 있습니다. AWS Private CA사설 CA에서 발급한 인증서는 AWS 조직 내에서만 신뢰할 수 있으며 인터넷에서는 신뢰할 수 없습니다.

공개 키 인프라 (PKI) 또는 보안 팀이 모든 PKI 인프라 관리를 담당할 수 있습니다. 여기에는 사설 CA의 관리 및 생성이 포함됩니다. 하지만 워크로드 팀이 인증서 요구 사항을 스스로 충족할 수 있도록 허용하는 조항이 있어야 합니다. AWS SRA는 루트 CA가 보안 도구 계정 내에 호스팅되는 중앙 집중식 CA 계층 구조를 나타냅니다. 루트 CA가 전체 PKI의 기반이기 때문에 보안 팀이 엄격한 보안 제어를 시행할 수 있습니다. 하지만 사설 CA에서 사설 인증서를 생성하는 작업은 AWS Resource Access Manager (AWS RAM) 를 사용하여 애플리케이션 계정에 CA를 공유하는 방식으로 애플리케이션 개발 팀에 위임됩니다. AWS RAM은 계정 간 공유에 필요한 권한을 관리합니다. 따라서 모든 계정에 사설 CA를 둘 필요가 없고 보다 비용 효율적인 배포 방법을 제공합니다. 워크플로 및 구현에 대한 자세한 내용은 블로그 게시물 AWS RAM을 사용하여 AWS Private CA 교차 계정을 공유하는 방법을 참조하십시오.

참고

또한 ACM은 AWS 서비스에 사용할 퍼블릭 TLS 인증서를 프로비저닝, 관리 및 배포하는 데도 도움이 됩니다. 이 기능을 지원하려면 ACM이 공인 인증서를 사용하는 AWS 계정에 있어야 합니다. 이에 대해서는 이 가이드의 뒷부분에 있는 애플리케이션 계정 섹션에서 설명합니다.

설계 고려 사항

• AWS Private CA를 사용하여 최대 5개 수준의 인증 기관 계층 구조를 만들 수 있습니다. 또한 각각이 자체 루트를 가진 계층을 여러 개 만들 수 있습니다. AWS Private CA 계층 구조는 조직의 PKI 디자인을 준수해야 합니다. 그러나 CA 계층 구조를 늘리면 인증 경로의 인증서 수가 늘어나고, 결과적으로 최종 엔터티 인증서의 유효성 검사 시간이 늘어난다는 점에 유의하십시오. 잘 정의된 CA 계층 구조는 각 CA에 적합한 세분화된 보안 제어, 다른 애플리케이션에 하위 CA를 위임하여 관리 작업을 분할하고, 취소 가능한 신뢰가 제한된 CA 사용, 다양한 유효 기간을 정의할 수 있는 기능, 경로 제한을 적용하는 기능 등의 이점을 제공합니다. 루트 CA와 하위 CA가 별도의 AWS 계정에 있는 것이 좋습니다. 를 사용하여 AWS Private CA CA 계층 구조를 계획하는 방법에 대한 자세한 내용은 AWS Private CA 설명서 및 블로그 게시물 자동차 및 제조를 위한 엔터프라이즈 규모 AWS Private CA 계층 구조를 보호하는 방법을 참조하십시오.

• AWS Private CA 기존 CA 계층 구조와 통합할 수 있으므로 현재 사용하고 있는 기존 신뢰 루트와 함께 ACM의 자동화 및 기본 AWS 통합 기능을 사용할 수 있습니다. 온프레미스에서 상위 CA를 AWS Private CA 지원하는 하위 CA를 생성할 수 있습니다. 구현에 대한 자세한 내용은 설명서의 외부 상위 CA에서 서명한 하위 CA 인증서 설치를 참조하십시오. AWS Private CA

Amazon Inspector

Amazon Inspector는 Amazon EC2 인스턴스, Amazon 컨테이너 레지스트리 (Amazon ECR) 의 컨테이너 이미지 및 AWS Lambda 함수를 자동으로 발견하고 스캔하여 알려진 소프트웨어 취약성과 의도하지 않은 네트워크 노출을 찾아내는 자동화된 취약성 관리 서비스입니다.

Amazon Inspector는 리소스를 변경할 때마다 리소스를 자동으로 스캔하여 리소스 수명 주기 전반에 걸쳐 환경을 지속적으로 평가합니다. 리소스 재스캔을 시작하는 이벤트에는 EC2 인스턴스에 새 패키지 설치, 패치 설치, 리소스에 영향을 미치는 새로운 공통 취약성 및 노출 (CVE) 보고서 게시 등이 포함됩니다. Amazon Inspector는 EC2 인스턴스의 운영 체제에 대한 인터넷 보안 센터 (CIS) 벤치마크 평가를 지원합니다.

Amazon Inspector는 Jenkins와 같은 개발자 도구 및 TeamCity 컨테이너 이미지 평가와 통합됩니다. 지속적 통합 및 지속적 전송 (CI/CD) 도구 내에서 컨테이너 이미지의 소프트웨어 취약성을 평가하고 소프트웨어 개발 수명 주기의 초기 단계로 보안을 푸시할 수 있습니다. 평가 결과는 CI/CD 도구의 대시보드에서 확인할 수 있으므로 빌드 차단이나 컨테이너 레지스트리로의 이미지 푸시와 같은 중요한 보안 문제에 대응하여 자동화된 조치를 수행할 수 있습니다. 활성 AWS 계정이 있는 경우, Amazon Inspector 서비스를 활성화할 필요 없이 CI/CD 도구 마켓플레이스에서 Amazon Inspector 플러그인을 설치하고 빌드 파이프라인에 Amazon Inspector 스캔을 추가할 수 있습니다. 이 기능은 AWS, 온프레미스 또는 하이브리드 클라우드 등 어디서나 호스팅되는 CI/CD 도구와 함께 작동하므로 모든 개발 파이프라인에서 단일 솔루션을 일관되게 사용할 수 있습니다. Amazon Inspector가 활성화되면 모든 EC2 인스턴스, Amazon ECR 및 CI/CD 도구의 컨테이너 이미지, AWS Lambda 함수를 대규모로 자동으로 검색하고 알려진 취약성이 있는지 지속적으로 모니터링합니다.

Amazon Inspector의 네트워크 연결성 조사 결과는 인터넷 게이트웨이, VPC 피어링 연결 또는 가상 게이트웨이를 통한 VPN (가상 사설망) 과 같은 VPC 에지에 대한 EC2 인스턴스의 액세스 가능성을 평가합니다. 이러한 규칙은 AWS 네트워크 모니터링을 자동화하고 잘못 관리된 보안 그룹, ACL (액세스 제어 목록), 인터넷 게이트웨이 등을 통해 EC2 인스턴스에 대한 네트워크 액세스가 잘못 구성될 수 있는 위치를 식별하는 데 도움이 됩니다. 자세한 내용은 Amazon Inspector 설명서를 참조하십시오.

Amazon Inspector는 취약성을 식별하거나 네트워크 경로를 열면 조사할 수 있는 결과를 생성합니다. 조사 결과에는 위험 점수, 영향을 받는 리소스, 해결 권장 사항 등 취약성에 대한 포괄적인 세부 정보가 포함됩니다. 위험 점수는 사용자 환경에 맞게 특별히 조정되며, 상황에 맞는 결과를 제공하기 위해 up-to-date CVE 정보를 네트워크 접근성 및 악용 가능성 정보와 같은 시간적 및 환경적 요인과 상호 연관시켜 계산합니다.

취약성을 스캔하려면 AWS Systems Manager 에이전트 (SSM 에이전트) 를 사용하여 AWS Systems Manager에서 EC2 인스턴스를 관리해야 합니다. Amazon ECR 또는 Lambda 함수에서 EC2 인스턴스의 네트워크 연결성 또는 컨테이너 이미지의 취약성 스캔에는 에이전트가 필요하지 않습니다.

Amazon Inspector는 AWS Organizations와 통합되어 있으며 위임 관리를 지원합니다. AWS SRA에서는 보안 도구 계정이 Amazon Inspector의 위임 관리자 계정이 됩니다. Amazon Inspector 위임 관리자 계정은 AWS 조직 구성원의 조사 결과 데이터 및 특정 설정을 관리할 수 있습니다. 여기에는 모든 회원 계정의 집계된 조사 결과 세부 정보 보기, 회원 계정 스캔 활성화 또는 비활성화, AWS 조직 내 스캔한 리소스 검토 등이 포함됩니다.

설계 고려 사항

• Amazon Inspector는 두 서비스가 모두 활성화되면 AWS Security Hub와 자동으로 통합됩니다. 이 통합을 사용하여 Amazon Inspector의 모든 결과를 Security Hub로 전송할 수 있습니다. 그러면 Security Hub가 해당 결과를 보안 상태 분석에 포함시킵니다.

• Amazon Inspector는 탐지 결과, 리소스 적용 범위 변경, 개별 리소스의 초기 스캔에 대한 이벤트를 Amazon으로 자동으로 내보내고 EventBridge, 선택적으로 Amazon Simple Storage Service (Amazon S3) 버킷으로 내보냅니다. 활성 결과를 S3 버킷으로 내보내려면 Amazon Inspector가 검색 결과를 암호화하는 데 사용할 수 있는 AWS KMS 키와 Amazon Inspector에서 객체를 업로드할 수 있는 권한을 가진 S3 버킷이 필요합니다. EventBridge 통합을 통해 기존 보안 및 규정 준수 워크플로의 일부로 거의 실시간으로 결과를 모니터링하고 처리할 수 있습니다. EventBridge 이벤트는 이벤트가 발생한 멤버 계정과 함께 Amazon Inspector의 위임 관리자 계정에도 게시됩니다.

구현 예제

AWS SRA 코드 라이브러리는 Amazon Inspector의 샘플 구현을 제공합니다. 위임 관리 (보안 도구) 를 보여주고 AWS 조직의 모든 기존 및 미래 계정에 대해 Amazon Inspector를 구성합니다.

모든 AWS 계정 내에 공통 보안 서비스 배포

이 참조 자료 앞부분의 AWS 조직 전체에 보안 서비스 적용 섹션에서는 AWS 계정을 보호하는 보안 서비스를 강조했으며, 이러한 서비스 중 다수는 AWS Organizations에서도 구성 및 관리할 수 있다고 언급했습니다. 이러한 서비스 중 일부는 모든 계정에 배포되어야 하며, AWS SRA에서 확인할 수 있습니다. 이를 통해 일관된 가드레일을 사용할 수 있으며 AWS 조직 전체에 중앙 집중식 모니터링, 관리 및 거버넌스를 제공합니다. 

Security Hub GuardDuty, AWS Config, 액세스 분석기 및 AWS CloudTrail 조직 트레일은 모든 계정에 표시됩니다. 처음 세 개는 이전에 관리 계정, 신뢰할 수 있는 액세스 및 위임된 관리자 섹션에서 설명한 위임된 관리자 기능을 지원합니다. CloudTrail 현재는 다른 집계 메커니즘을 사용하고 있습니다.

AWS SRA GitHub코드 리포지토리는 AWS Org Management 계정을 포함한 모든 계정에서 Security Hub GuardDuty, AWS Config, Firewall Manager CloudTrail 및 조직 트레일을 활성화하는 샘플 구현을 제공합니다.

설계 고려 사항

• 특정 계정 구성에는 추가 보안 서비스가 필요할 수 있습니다. 예를 들어, S3 버킷을 관리하는 계정 (애플리케이션 및 로그 아카이브 계정) 에는 Amazon Macie도 포함되어야 하며, 이러한 일반 보안 서비스에서 S3 데이터 이벤트 로깅을 활성화하는 것을 고려해 보십시오. CloudTrail (Macie는 중앙 집중식 구성 및 모니터링을 통해 위임 관리를 지원합니다.) 또 다른 예로 Amazon Inspector를 들 수 있습니다. Amazon Inspector는 EC2 인스턴스 또는 Amazon ECR 이미지를 호스팅하는 계정에만 적용됩니다.

• 이 섹션에서 앞서 설명한 서비스 외에도 AWS SRA에는 AWS Organizations 통합 및 위임 관리자 기능을 지원하는 두 가지 보안 중심 서비스인 Amazon Detective와 AWS Audit Manager가 포함되어 있습니다. 하지만 이러한 서비스는 다음과 같은 시나리오에서 가장 잘 사용되는 것으로 확인되었으므로 계정 기준 설정 권장 서비스에는 포함되지 않습니다.

  • 이러한 기능을 수행하는 전담 팀 또는 리소스 그룹이 있습니다. Detective는 보안 분석가 팀에서 가장 잘 활용되며 Audit Manager는 내부 감사 또는 규정 준수 팀에 유용합니다.

  • 프로젝트를 시작할 때 Security GuardDuty Hub와 같은 핵심 도구 세트에 집중한 다음 추가 기능을 제공하는 서비스를 사용하여 이러한 도구를 구축해야 합니다.