기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
보안 OU — 로그 아카이브 계정
| 간단한 설문조사를 |
다음 다이어그램은 Log Archive 계정에 구성된 AWS 보안 서비스를 보여줍니다.
Log Archive 계정은 모든 보안 관련 로그 및 백업을 수집하고 보관하는 데 사용됩니다. 중앙 집중식 로그를 사용하면 Amazon S3 객체 액세스, ID별 무단 활동, IAM 정책 변경 및 민감한 리소스에서 수행되는 기타 중요한 활동을 모니터링, 감사 및 경고할 수 있습니다. 보안 목표는 간단합니다. 즉, 제어 및 자동화되고 모니터링되는 메커니즘을 통해서만 액세스할 수 있고 내구성을 위해 구축된 변경 불가능한 스토리지여야 합니다 (예: 적절한 복제 및 보관 프로세스 사용). 제어를 심층적으로 구현하여 로그 및 로그 관리 프로세스의 무결성과 가용성을 보호할 수 있습니다. 액세스에 사용할 최소 권한 역할을 할당하고 통제된 AWS KMS 키로 로그를 암호화하는 등의 예방적 제어 외에도, AWS Config와 같은 탐지 제어를 사용하여 이러한 권한 수집을 모니터링하고 예상치 못한 변경 사항을 알리고 수정합니다.
설계 고려 사항
-
인프라, 운영 및 워크로드 팀에서 사용하는 운영 로그 데이터는 보안, 감사 및 규정 준수 팀에서 사용하는 로그 데이터와 겹치는 경우가 많습니다. 운영 로그 데이터를 Log Archive 계정에 통합하는 것이 좋습니다. 특정 보안 및 거버넌스 요구 사항에 따라 이 계정에 저장된 운영 로그 데이터를 필터링해야 할 수 있습니다. Log Archive 계정의 운영 로그 데이터에 액세스할 수 있는 사용자를 지정해야 할 수도 있습니다.
로그 유형
AWS SRA에 표시되는 기본 로그에는 CloudTrail (조직 추적), 아마존 VPC 흐름 로그, 아마존 및 AWS WAF의 액세스 로그, CloudFront Amazon Route 53의 DNS 로그가 포함됩니다. 이러한 로그는 사용자, 역할, AWS 서비스 또는 네트워크 개체 (예: IP 주소로 식별) 가 취하거나 시도한 작업에 대한 감사를 제공합니다. 다른 로그 유형 (예: 애플리케이션 로그 또는 데이터베이스 로그) 도 캡처하고 보관할 수 있습니다. 로그 소스 및 로깅 모범 사례에 대한 자세한 내용은 각 서비스의 보안 설명서를 참조하십시오.
중앙 로그 스토어로서의 Amazon S3
많은 AWS 서비스는 기본적으로 또는 독점적으로 Amazon S3에 정보를 기록합니다. Amazon S3에 정보를 기록하는 서비스의 예로는 AWS CloudTrail, 아마존 VPC 플로우 로그, AWS Config, Elastic Load Balancing 등이 있습니다. 즉, 로그 무결성은 S3 객체 무결성을 통해 달성되고, 로그 기밀성은 S3 객체 액세스 제어를 통해 달성되며, 로그 가용성은 S3 객체 잠금, S3 객체 버전 및 S3 수명 주기 규칙을 통해 달성됩니다. 전용 계정에 있는 중앙 집중식 전용 S3 버킷에 정보를 기록하면 몇 개의 버킷으로 이러한 로그를 관리하고 엄격한 보안 제어, 액세스 및 직무 분리를 적용할 수 있습니다.
AWS SRA에서는 Amazon S3에 저장된 기본 로그의 CloudTrail 출처가 되므로 이 섹션에서는 이러한 객체를 보호하는 방법을 설명합니다. 이 지침은 자체 애플리케이션 또는 다른 AWS 서비스에서 생성한 다른 모든 S3 객체에도 적용됩니다. Amazon S3에 높은 무결성, 강력한 액세스 제어, 자동 보존 또는 폐기가 필요한 데이터가 있을 때마다 이러한 패턴을 적용하십시오.
S3 버킷에 업로드되는 모든 새 객체 ( CloudTrail 로그 포함) 는 Amazon S3에서 관리하는 암호화 키 (SSE-S3) 를 사용한 Amazon 서버 측 암호화를 사용하여 기본적으로 암호화됩니다. 이렇게 하면 저장된 데이터를 보호하는 데 도움이 되지만 액세스 제어는 IAM 정책에 의해서만 제어됩니다. 추가 관리형 보안 계층을 제공하려면 모든 보안 S3 버킷에서 관리하는 AWS KMS 키 (SSE-KMS) 를 사용한 서버 측 암호화를 사용할 수 있습니다. 이렇게 하면 두 번째 수준의 액세스 제어가 추가됩니다. 로그 파일을 읽으려면 사용자에게 S3 객체에 대한 Amazon S3 읽기 권한과 관련 키 정책에 따라 복호화할 수 있는 권한을 허용하는 IAM 정책 또는 역할이 적용되어 있어야 합니다.
Amazon S3에 저장된 CloudTrail 로그 객체의 무결성을 보호하거나 검증하는 데 도움이 되는 두 가지 옵션이 있습니다. CloudTrail 로그 파일이 CloudTrail 전송된 후 수정되거나 삭제되었는지 확인하기 위한 로그 파일 무결성 검증을 제공합니다. 다른 옵션은 S3 오브젝트 잠금입니다.
S3 버킷 자체를 보호하는 것 외에도 로깅 서비스 (예: CloudTrail) 및 Log Archive 계정에 대한 최소 권한 원칙을 준수할 수 있습니다. 예를 들어, AWS 관리형 IAM 정책에서 권한을 부여받은 사용자는 AWS 계정에서 가장 민감하고 중요한 감사 기능을 비활성화하거나 재구성할 AWSCloudTrail_FullAccess 수 있습니다. 이 IAM 정책의 적용을 가능한 한 소수의 개인으로 제한하십시오.
AWS Config 및 AWS IAM Access Analyzer에서 제공하는 것과 같은 탐지 제어를 사용하여 예상치 못한 변경이 발생하지 않도록 이 광범위한 예방 제어 집합을 모니터링 (및 경고 및 해결) 할 수 있습니다.
S3 버킷의 보안 모범 사례에 대한 심도 있는 논의는 Amazon S3 설명서, 온라인 테크 토크
구현 예제
AWS SRA 코드 라이브러리는
Amazon Security Lake
AWS SRA는 로그 아카이브 계정을 Amazon Security Lake의 위임된 관리자 계정으로 사용할 것을 권장합니다. 이렇게 하면 Security Lake는 다른 SRA가 권장하는 보안 로그와 동일한 계정의 전용 S3 버킷에서 지원되는 로그를 수집합니다.
로그의 가용성과 로그 관리 프로세스를 보호하려면 Security Lake 서비스 또는 Security Lake에서 소스 또는 구독자를 관리하는 IAM 역할을 통해서만 Security Lake용 S3 버킷에 액세스해야 합니다. 액세스를 위한 최소 권한 역할을 할당하고 통제된 AWS KMS (Key Management Services) 키로 로그를 암호화하는 것과 같은 예방적 제어를 사용하는 것 외에도 AWS Config와 같은 탐지 제어를 사용하여 이러한 권한 수집을 모니터링하고 예상치 못한 변경 사항을 알리고 수정합니다.
Security Lake 관리자는 AWS 조직 전체에서 로그 수집을 활성화할 수 있습니다. 이러한 로그는 Log Archive 계정의 지역 S3 버킷에 저장됩니다. 또한 로그를 중앙 집중화하고 저장 및 분석을 용이하게 하기 위해 Security Lake 관리자는 모든 지역 S3 버킷의 로그를 통합하고 저장하는 롤업 지역을 하나 이상 선택할 수 있습니다. 지원되는 AWS 서비스의 로그는 오픈 사이버 보안 스키마 프레임워크 (OCSF) 라는 표준화된 오픈 소스 스키마로 자동 변환되고 Security Lake S3 버킷에 Apache Parquet 형식으로 저장됩니다. OCSF 지원을 통해 Security Lake는 AWS 및 기타 엔터프라이즈 보안 소스의 보안 데이터를 효율적으로 정규화하고 통합하여 보안 관련 정보의 신뢰할 수 있는 통합 리포지토리를 생성합니다.
Security Lake는 Amazon S3 및 AWS Lambda의 AWS CloudTrail 관리 이벤트 및 CloudTrail 데이터 이벤트와 관련된 로그를 수집할 수 있습니다. Security Lake에서 CloudTrail 관리 이벤트를 수집하려면 읽기 및 쓰기 CloudTrail 관리 이벤트를 수집하는 CloudTrail 다중 지역 조직 트레일이 하나 이상 있어야 합니다. 트레일에 대한 로깅이 활성화되어 있어야 합니다. 다중 지역 트레일은 여러 지역의 로그 파일을 단일 AWS 계정의 단일 S3 버킷으로 전송합니다. 지역이 서로 다른 국가에 있는 경우 데이터 내보내기 요구 사항을 고려하여 다중 지역 트레일을 활성화할 수 있는지 여부를 결정하십시오.
AWS Security Hub는 Security Lake에서 지원되는 네이티브 데이터 소스이므로 Security Lake에 Security Hub 검색 결과를 추가해야 합니다. Security Hub는 다양한 AWS 서비스 및 타사 통합으로부터 결과를 생성합니다. 이러한 결과는 규정 준수 태세의 개요와 AWS 및 AWS 파트너 솔루션에 대한 보안 권장 사항을 따르고 있는지 여부를 파악하는 데 도움이 됩니다.
로그와 이벤트에서 가시성과 실행 가능한 통찰력을 얻으려면 Amazon Athena, Amazon Service, Amazon Quicksight 및 타사 솔루션과 같은 도구를 사용하여 데이터를 쿼리할 수 있습니다. OpenSearch Security Lake 로그 데이터에 액세스해야 하는 사용자는 로그 아카이브 계정에 직접 액세스해서는 안 됩니다. 보안 도구 계정의 데이터에만 액세스해야 합니다. 또는 OpenSearch 서비스와 같은 분석 도구나 보안 정보 및 이벤트 관리 (SIEM) 도구와 같은 타사 도구를 제공하는 다른 AWS 계정이나 온프레미스 위치를 사용할 수 있습니다. QuickSight 데이터에 대한 액세스를 제공하려면 관리자는 Log Archive 계정에서 Security Lake 구독자를 구성하고 데이터에 액세스해야 하는 계정을 쿼리 액세스 구독자로 구성해야 합니다. 자세한 내용은 이 안내서의 보안 OU — 보안 도구 계정 섹션에서 Amazon Security Lake를 참조하십시오.
Security Lake는 서비스에 대한 관리자 액세스를 관리하는 데 도움이 되는 AWS 관리형 정책을 제공합니다. 자세한 내용은 Security Lake 사용 설명서를 참조하십시오. 가장 좋은 방법은 개발 파이프라인을 통해 Security Lake의 구성을 제한하고 AWS 콘솔 또는 AWS 명령줄 인터페이스 (AWS CLI) 를 통한 구성 변경을 방지하는 것입니다. 또한 Security Lake를 관리하는 데 필요한 권한만 제공하도록 엄격한 IAM 정책 및 서비스 제어 정책 (SCP) 을 설정해야 합니다. 이러한 S3 버킷에 대한 직접 액세스를 감지하도록 알림을 구성할 수 있습니다.
