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