위협 감지 및 모니터링 기능은 Security Command Center에서 기본 제공되는 보안 제어와 보안 관련 활동을 감지하고 대응할 수 있게 해주는 커스텀 솔루션의 조합을 사용하여 제공됩니다.
중앙 집중식 로깅을 통한 보안 및 감사
청사진은 단일 프로젝트에 집계된 로그를 사용하여 Google Cloud 리소스의 변경사항을 추적하고 분석하도록 로깅 기능을 구성합니다.
다음은 청사진이 여러 프로젝트에 있는 여러 소스의 로그를 중앙 집중식 로그 싱크로 집계하는 방법을 보여주는 다이어그램입니다.
다이어그램은 다음을 설명합니다.
- 로그 싱크는 리소스 계층 구조의 모든 프로젝트에서 로그를 집계하도록 조직 노드에서 구성됩니다.
- 필터 조건에 맞는 로그를 다른 스토리지 및 분석 대상으로 전송하도록 여러 로그 싱크가 구성됩니다.
prj-c-logging
프로젝트에는 로그 스토리지 및 분석을 위한 모든 리소스가 포함됩니다.- 선택적으로 SIEM으로 로그를 내보내기 위한 추가 도구를 구성할 수 있습니다.
청사진은 다양한 로그 소스를 사용하고 로그를 중앙 집중식 대상으로 내보낼 수 있도록 로그 싱크 필터에 이러한 로그를 포함시킵니다. 다음 표에서는 로그 소스를 설명합니다.
로그 소스 |
설명 |
---|---|
관리자 활동 감사 로그는 구성, 사용 중지, 제외할 수 없습니다. |
|
시스템 이벤트 감사 로그는 구성, 사용 중지 또는 제외할 수 없습니다. |
|
정책 거부 감사 로그를 구성하거나 사용 중지할 수 없지만 제외 필터를 사용하여 선택적으로 제외할 수 있습니다. |
|
기본적으로 청사진은 데이터 액세스 로그를 사용 설정하지 않습니다. 이러한 로그의 볼륨과 비용이 높을 수 있기 때문입니다. 데이터 액세스 로그를 사용 설정해야 하는지 여부를 결정하려면 워크로드에서 민감한 정보를 처리하는 위치를 평가하고 민감한 정보를 다루는 각 서비스 및 환경에 대해 데이터 액세스 로그를 사용 설정해야 하는지 여부를 고려하세요. |
|
청사진은 모든 서브넷에 VPC 흐름 로그를 사용 설정합니다. 청사진은 비용 절감을 위해 로그의 50%를 샘플링하도록 로그 샘플링을 구성합니다. 추가 서브넷을 만드는 경우 각 서브넷에 VPC 흐름 로그가 사용 설정되어 있는지 확인해야 합니다. |
|
청사진은 모든 방화벽 정책 규칙에 방화벽 규칙 로깅을 사용 설정합니다. 워크로드의 추가 방화벽 정책 규칙을 만드는 경우 새 규칙마다 방화벽 규칙 로깅이 사용 설정되어 있는지 확인해야 합니다. |
|
청사진은 관리형 영역에 대해 Cloud DNS 로그를 사용 설정합니다. 추가 관리형 영역을 만드는 경우 이러한 DNS 로그를 사용 설정해야 합니다. |
|
청사진으로 자동화되지 않은 일회성 사용 설정 단계가 필요합니다. 자세한 내용은 Google Cloud 서비스와 데이터 공유를 참조하세요. |
|
청사진으로 자동화되지 않은 일회성 사용 설정 단계가 필요합니다. 자세한 내용은 액세스 투명성 사용 설정을 참조하세요. |
다음 표에서는 로그 싱크와 청사진에서 지원되는 대상과 함께 사용되는 방법을 설명합니다.
싱크 |
대상 |
목적 |
---|---|---|
|
로그 애널리틱스 및 연결된 BigQuery 데이터 세트가 사용 설정된 Cloud Logging 버킷으로 라우팅되는 로그 |
로그를 적극적으로 분석합니다. 콘솔에서 로그 탐색기를 사용하여 임시 조사를 실행하거나 연결된 BigQuery 데이터 세트를 사용하여 SQL 쿼리, 보고서, 뷰를 작성합니다. |
|
규정 준수, 감사, 이슈 추적 목적으로 로그를 장기간 저장합니다. 선택적으로 필수 데이터 보관에 대한 규정 준수 요구사항이 있는 경우 버킷 잠금을 추가로 구성하는 것이 좋습니다. |
|
|
기존 SIEM과 같은 외부 플랫폼으로 로그를 내보냅니다. 이를 위해서는 다음 메커니즘과 같이 SIEM과 통합하기 위한 추가 작업이 필요합니다.
|
추가 로그 유형을 사용 설정하고 로그 싱크 필터를 작성하는 방법은 로그 범위 지정 도구를 참조하세요.
Security Command Center로 위협 모니터링
조직에서 Google Cloud 리소스에서 위협, 취약점, 잘못된 구성을 자동으로 감지할 수 있도록 Security Command Center 프리미엄을 활성화하는 것이 좋습니다. Security Command Center는 다음을 포함한 여러 소스에서 보안 발견 항목을 만듭니다.
- Security Health Analytics: Google Cloud 리소스에서 일반적인 취약점과 구성 오류를 감지합니다.
- 공격 경로 노출: 다른 Security Command Center 소스에서 감지한 취약점과 잘못된 구성을 기반으로 공격자가 고가치 리소스를 악용할 수 있는 시뮬레이션된 경로를 보여줍니다.
- Event Threat Detection: 로그에 감지 로직 및 독점 위협 인텔리전스를 적용하여 거의 실시간으로 위협을 식별합니다.
- Container Threat Detection: 일반적인 컨테이너 런타임 공격을 감지합니다.
- VM 위협 감지: 가상 머신에서 실행 중인 잠재적 악성 애플리케이션을 감지합니다.
- Web Security Scanner: Compute Engine, App Engine 또는 Google Kubernetes Engine의 웹 대면 애플리케이션에서 OWASP 상위 10개 취약점을 스캔합니다.
Security Command Center에서 다루는 취약점 및 위협에 대한 자세한 내용은 Security Command Center 소스를 참조하세요.
청사진을 배포한 후 Security Command Center를 활성화해야 합니다. 자세한 내용은 조직에 Security Command Center 활성화를 참조하세요.
Security Command Center를 활성화한 후에는 위협을 분류하고 대응할 수 있도록 Security Command Center에서 생성된 발견 항목을 기존 도구 또는 프로세스로 내보내는 것이 좋습니다. 청사진은 이 통합에 사용할 Pub/Sub 주제로 prj-c-scc
프로젝트를 만듭니다. 기존 도구에 따라 다음 방법 중 하나를 사용하여 발견 항목을 내보냅니다.
- 콘솔을 사용하여 Security Command Center에서 직접 보안 발견 항목을 관리하는 경우 팀에서 담당하는 프로젝트의 보안 발견 항목을 보고 관리할 수 있도록 Security Command Center의 폴더 수준 및 프로젝트 수준 역할을 구성합니다.
Google SecOps를 SIEM으로 사용하는 경우 Google Cloud 데이터를 Google SecOps로 수집합니다.
Security Command Center와 통합되는 SIEM 또는 SOAR 도구를 사용하는 경우 Cortex XSOAR, Elastic Stack, ServiceNow, Splunk 또는 QRadar와 데이터를 공유합니다.
Pub/Sub에서 발견 항목을 수집할 수 있는 외부 도구를 사용하는 경우 Pub/Sub로 지속적 내보내기를 구성하고 Pub/Sub 주제에서 발견 항목을 수집하도록 기존 도구를 구성합니다.
로그 기반 측정항목 및 성능 측정항목에 대한 알림
기반 위에 워크로드를 배포하기 시작하면 Cloud Monitoring을 사용하여 성능 측정항목을 측정하는 것이 좋습니다.
청사진은 각 환경에 대해 prj-p-monitoring
과 같은 모니터링 프로젝트를 만듭니다. 이 프로젝트는 여러 프로젝트에서 집계된 성능 측정항목을 수집하기 위한 범위 지정 프로젝트로 구성됩니다. 청사진은 로그 기반 측정항목과 알림 정책이 있는 예시를 배포하여 Cloud Storage 버킷에 적용된 IAM 정책에 변경사항이 있는 경우 이메일 알림을 생성합니다. 이는 Terraform 상태가 포함된 prj-b-seed
프로젝트의 버킷과 같은 민감한 리소스에서 의심스러운 활동을 모니터링하는 데 도움이 됩니다.
보다 일반적으로는 Cloud Monitoring을 사용하여 워크로드 애플리케이션의 성능 측정항목과 상태를 측정할 수도 있습니다. 조직에서 애플리케이션 지원 및 모니터링을 위한 운영 책임에 따라 여러 팀에 대해 보다 세분화된 모니터링 프로젝트를 만들 수 있습니다. 이러한 모니터링 프로젝트를 사용하여 성능 측정항목을 확인하고, 애플리케이션 상태 대시보드를 만들고, 예상 SLO가 충족되지 않을 때 알림을 트리거하세요.
다음 다이어그램은 Cloud Monitoring이 성능 측정항목을 집계하는 방법을 간단히 보여줍니다.
안정성과 가용성을 위해 워크로드를 효과적으로 모니터링하는 방법은 Google의 사이트 안정성 엔지니어링 도서, 특히 분산 시스템 모니터링에 대한 챕터를 참조하세요.
자동화된 로그 분석을 위한 커스텀 솔루션
로그에 대한 커스텀 쿼리를 기반으로 하는 보안 관련 활동에 대한 알림을 만들어야 할 수 있습니다. 커스텀 쿼리는 Google Cloud에서 로그를 분석하고 조사를 필요로 하는 이벤트만 내보내므로 특히 모든 Cloud 로그를 SIEM으로 내보낼 용량이 없는 경우 SIEM의 기능을 보완할 수 있습니다.
청사진은 연결된 BigQuery 데이터 세트를 사용하여 쿼리할 수 있는 로그의 중앙 집중식 소스를 설정하여 이러한 로그 분석을 사용 설정합니다. 이 기능을 자동화하려면 bq-log-alerting
에서 코드 샘플을 구현하고 기반 기능을 확장해야 합니다. 샘플 코드를 사용하면 로그 소스를 정기적으로 쿼리하고 커스텀 발견 항목을 Security Command Center로 전송할 수 있습니다.
다음 다이어그램에서는 자동 로그 분석의 대략적인 흐름을 보여줍니다.
이 다이어그램은 자동 로그 분석의 다음과 같은 개념을 보여줍니다.
- 다양한 소스의 로그가 로그 분석 및 연결된 BigQuery 데이터 세트를 사용하여 중앙 집중식 로그 버킷에 집계됩니다.
- BigQuery 뷰는 모니터링하려는 보안 관련 활동의 로그를 쿼리하도록 구성됩니다.
- Cloud Scheduler는 15분마다 이벤트를 Pub/Sub 주제에 푸시하고 Cloud Functions를 트리거합니다.
- Cloud Functions는 뷰에 새 이벤트를 쿼리합니다. 이벤트를 찾으면 Security Command Center에 커스텀 발견 항목으로 푸시합니다.
- Security Command Center는 새로운 발견 항목에 대한 알림을 다른 Pub/Sub 주제에 게시합니다.
- SIEM과 같은 외부 도구는 Pub/Sub 주제를 구독하여 새 발견 항목을 수집합니다.
샘플에는 잠재적으로 의심스러운 동작을 쿼리하기 위한 몇 가지 사용 사례가 있습니다. 예를 들어 최고 관리자 또는 지정한 기타 높은 권한이 있는 계정 목록에서 로그인, 로깅 설정 변경 또는 네트워크 경로 변경사항이 있습니다. 요구사항에 맞는 새 쿼리 뷰를 작성하여 사용 사례를 확장할 수 있습니다. Google Cloud 로그를 분석하는 데 도움이 되도록 자체 쿼리를 작성하거나 SQL 쿼리 라이브러리에 대한 보안 로그 분석을 참조하세요.
애셋 변경사항에 대응하기 위한 커스텀 솔루션
실시간으로 이벤트에 응답하려면 Cloud 애셋 인벤토리를 사용하여 애셋 변경사항을 모니터링하는 것이 좋습니다. 이 커스텀 솔루션에서는 애셋 피드가 Pub/Sub에 리소스 변경사항에 대한 알림을 실시간으로 트리거하도록 구성되면 Cloud Functions가 커스텀 코드를 실행하여 변경 허용 여부에 따라 자체 비즈니스 로직을 시행합니다.
이 청사진에는 조직 관리자, 소유자, 편집자 등 매우 민감한 역할을 추가하는 IAM 변경사항을 모니터링하는 커스텀 거버넌스 솔루션의 예시가 포함되어 있습니다. 다음 다이어그램에서는 이 솔루션을 설명합니다.
위의 다이어그램에서는 다음과 같은 개념을 보여줍니다.
- 허용 정책에 변경사항이 적용됩니다.
- Cloud 애셋 인벤토리 피드에서 Pub/Sub로 허용 정책 변경사항에 대한 실시간 알림을 전송합니다.
- Pub/Sub가 함수를 트리거합니다.
- Cloud Functions는 커스텀 코드를 실행하여 정책을 시행합니다. 예시 함수에는 변경사항이 조직 관리자, 소유자 또는 편집자 역할을 허용 정책에 추가했는지 평가하는 로직이 있습니다. 이러한 경우 함수는 커스텀 보안 발견 항목을 만들고 Security Command Center로 전송합니다.
- 선택적으로 이 모델을 사용하여 해결 작업을 자동화할 수 있습니다. Cloud Functions에 추가 비즈니스 로직을 작성하여 허용 정책을 이전 상태로 되돌리는 등 발견 항목에 작업을 자동으로 수행합니다.
또한 이 샘플 솔루션에서 사용하는 인프라와 논리를 확장하여 비즈니스에 중요한 다른 이벤트에 커스텀 응답을 추가할 수 있습니다.
다음 단계
- 예방형 제어(이 시리즈의 다음 문서) 읽어보기