SEC04-BP02 Capture logs, findings, and metrics in standardized locations - AWS Well-Architected Framework

SEC04-BP02 Capture logs, findings, and metrics in standardized locations

보안 팀은 로그와 조사 결과를 바탕으로 무단 활동이나 의도하지 않은 변경을 나타낼 수 있는 이벤트를 분석합니다. 이 분석을 간소화하려면 표준화된 위치에서 보안 로그와 조사 결과를 캡처하세요.  이를 통해 관심 데이터 포인트를 상관관계 분석에 사용할 수 있고 도구 통합을 간소화할 수 있습니다.

원하는 결과: 로그 데이터, 조사 결과 및 지표를 수집, 분석 및 시각화하는 표준화된 접근 방식이 있습니다. 보안 팀은 서로 다른 시스템 전반의 보안 데이터를 효율적으로 분석 및 시각화하고 상관관계를 파악하여 잠재적 보안 이벤트를 발견하고 이상 징후를 식별할 수 있습니다. 보안 정보 및 이벤트 관리(SIEM) 시스템 또는 기타 메커니즘이 통합되어 보안 이벤트의 시기적절한 대응, 추적, 에스컬레이션을 위해 로그 데이터를 쿼리하고 분석합니다.

일반적인 안티 패턴:

  • 팀이 조직의 로깅 전략과 일치하지 않는 로깅 및 지표 수집을 독립적으로 소유하고 관리합니다.

  • 팀에 수집된 데이터의 가시성과 변경을 제한할 수 있는 적절한 액세스 제어 기능이 없습니다.

  • 팀이 데이터 분류 정책의 일부로 보안 로그, 조사 결과 및 지표를 관리하지 않습니다.

  • 팀이 데이터 수집을 구성할 때 데이터 주권 및 현지화 요구 사항을 무시합니다.

이 모범 사례 확립의 이점: 로그 데이터 및 이벤트를 수집하고 쿼리하는 표준화된 로깅 솔루션은 포함된 정보에서 도출되는 인사이트를 개선합니다. 수집된 로그 데이터의 자동화된 수명 주기를 구성하면 로그 스토리지로 인해 발생하는 비용을 줄일 수 있습니다. 팀에서 필요로 하는 데이터의 민감도와 액세스 패턴에 따라 수집된 로그 정보에 대한 세분화된 액세스 제어 기능을 구축할 수 있습니다. 도구를 통합하여 데이터의 상관관계를 파악하고, 데이터를 시각화하고, 데이터에서 인사이트를 도출할 수 있습니다.

이 모범 사례를 따르지 않을 경우 노출 위험도: 중간

구현 가이드

조직 내 AWS 사용량이 증가하면 분산된 워크로드와 환경의 수가 늘어납니다. 이러한 각 워크로드 및 환경은 내부에 활동 데이터를 생성하므로, 보안 운영 측면에서 데이터를 로컬로 캡처하고 저장하기란 어렵습니다. 보안 팀은 보안 정보 및 이벤트 관리(SIEM) 시스템과 같은 도구를 사용하여 분산된 소스에서 데이터를 수집하고 상관관계 파악, 분석 및 대응 워크플로를 거칩니다. 이를 위해서는 다양한 데이터 소스에 액세스하기 위한 복잡한 권한 집합을 관리해야 하고 추출, 전환, 적재(ETL) 프로세스를 운영하는 데 추가 오버헤드가 듭니다.

이러한 문제를 해결하려면 여러 계정을 사용하여 AWS 환경 구성에 설명된 대로 보안 로그 데이터의 모든 관련 소스를 로그 아카이브 계정으로 집계하는 것이 좋습니다. 여기에는 AWS CloudTrail, AWS WAF, Elastic Load Balancing, Amazon Route 53 등의 AWS 서비스가 생성하는 워크로드 및 로그의 모든 보안 관련 데이터가 포함됩니다. 적절한 교차 계정 권한이 있는 별도의 AWS 계정에서 표준화된 위치의 데이터를 캡처하면 몇 가지 이점이 있습니다. 이러한 방식은 손상된 워크로드 및 환경 내에서 로그 변조를 방지하는 데 도움이 되며, 추가 도구를 위한 단일 통합 지점을 제공하고, 데이터 보존 및 수명 주기 구성을 위한 보다 간소화된 모델을 지원합니다.  데이터 주권, 규정 준수 범위 및 기타 규정의 영향을 평가하여 여러 보안 데이터 스토리지와 보존 기간이 필요한지 결정합니다.

로그 및 조사 결과를 쉽게 캡처하고 표준화하려면 로그 아카이브 계정에서 Amazon Security Lake를 평가합니다. CloudTrail, Route 53, Amazon EKS, VPC 흐름 로그와 같은 일반 소스에서 데이터를 자동으로 수집하도록 Security Lake를 구성할 수 있습니다. 또한, AWS Security Hub를 Security Lake에 데이터 소스로 구성하여 Amazon GuardDuty, Amazon Inspector 등의 다른 AWS 서비스의 조사 결과를 로그 데이터와 연관시킬 수 있습니다.  타사 데이터 소스 통합을 사용하거나 사용자 지정 데이터 소스를 구성할 수도 있습니다. 모든 통합은 데이터를 Open Cybersecurity Schema Framework(OCSF) 형식으로 표준화하고 Amazon S3 버킷에 Parquet 파일로 저장되므로, ETL 처리가 필요하지 않습니다

보안 데이터를 표준화된 위치에 저장하면 고급 분석 기능이 제공됩니다. AWS는 AWS 환경에서 작동하는 보안 분석 도구를 로그 아카이브 계정과 별개인 보안 도구 계정에 배포할 것을 권장합니다.  이 접근 방식을 사용하면 로그와 로그 관리 프로세스에 액세스하는 도구와는 별개로 로그 및 로그 관리 프로세스의 무결성과 가용성을 보호하기 위한 제어 기능을 심층적으로 구현할 수 있습니다.  Amazon Athena와 같은 서비스를 사용하여 여러 데이터 소스의 상관관계를 분석하는 온디맨드 쿼리를 실행하는 것을 고려해 보세요. 또한, Amazon QuickSight와 같은 시각화 도구를 통합할 수 있습니다. AI 기반 솔루션은 점점 더 많이 사용되고 있으며, 조사 결과를 사람이 읽을 수 있는 요약 정보와 자연어 상호 작용으로 변환하는 등의 기능을 수행할 수 있습니다.  쿼리를 위한 표준화된 데이터 스토리지 위치를 사용하면 이러한 솔루션을 보다 쉽게 통합할 수 있는 경우가 많습니다.

구현 단계

  1. 로그 아카이브 계정 및 보안 도구 계정을 생성합니다.

    1. AWS Organizations을 사용하여 보안 조직 단위로 로그 아카이브 계정 및 보안 도구 계정을 만듭니다. AWS Control Tower를 사용하여 조직을 관리하는 경우 로그 아카이브 계정 및 보안 도구 계정이 자동으로 생성됩니다. 필요에 따라 이러한 계정에 액세스하고 관리하기 위한 역할 및 권한을 구성합니다.

  2. 표준화된 보안 데이터 위치를 구성합니다.

    1. 표준화된 보안 데이터 위치를 만들기 위한 전략을 결정합니다.  일반적인 데이터 레이크 아키텍처 접근 방식, 타사 데이터 제품 또는 Amazon Security Lake와 같은 옵션을 통해 이를 달성할 수 있습니다. AWS는 적극적으로 사용하지 않을 때도 계정에 대해 설정한 AWS 리전에서 보안 데이터를 캡처할 것을 권장합니다.

  3. 표준화된 위치에 데이터 소스 게시를 구성합니다.

    1. 보안 데이터의 소스를 식별하고 표준화된 위치에 게시하도록 구성합니다. ETL 프로세스를 개발해야 하는 경우와 달리 원하는 형식으로 데이터를 자동으로 내보내는 옵션을 평가합니다. Amazon Security Lake를 사용하면 지원되는 AWS 소스와 통합된 타사 시스템에서 데이터를 수집할 수 있습니다.

  4. 표준화된 위치에 액세스할 수 있는 도구를 구성합니다.

    1. 표준화된 위치에 필요한 액세스 권한을 갖도록 Amazon Athena, Amazon QuickSight, 타사 솔루션 등의 도구를 구성합니다.  해당하는 경우 로그 아카이브 계정에 대한 교차 계정 읽기 권한이 있는 보안 도구 계정에서 작동하도록 관련 도구를 구성합니다. Amazon Security Lake에서 구독자를 생성하여 이러한 도구가 데이터에 액세스할 수 있도록 합니다.

리소스

관련 모범 사례:

관련 문서:

관련 예시:

관련 도구: