Anthos 보안 세부 계획: 정책 위반 감사 및 모니터링

이 문서에서는 Anthos 클러스터를 감사 및 모니터링하여 클러스터에 연결한 보안 권장사항 및 정책이 위반된 적이 있는지 확인하는 방법을 설명합니다. 여기에서는 정책을 감사 및 모니터링하는 방법과 이유를 간단히 설명하고 이 작업에 사용되는 Google Cloud 제어를 보여줍니다.

이 문서는 Anthos 사용에 관한 처방적 안내를 제공하는 세부 계획 시리즈 중 하나입니다.

소개

클러스터에는 자산에 대한 액세스를 보호하는 데 도움이 되는 정책이 포함되어 있습니다. 이러한 정책 위반 사항을 감사 및 모니터링하여 보안을 향상시킬 수 있습니다. 감사 및 모니터링을 수행하면 클러스터의 현재 상태에 대해 유용한 정보를 얻을 수 있지만 정책을 우회할 수 있는 다른 작업들을 방지하지는 못합니다. 변경을 방지하기 위해서는 정책 시행 단계를 수행해야 합니다.

모니터링은 감사와 비슷하지만 목적이 약간 다릅니다. 일반적인 모니터링 솔루션은 측정항목을 수집하기 위한 방법, 시스템 및 앱 상태를 보기 위한 대시보드, 이상치가 감지되었을 때 알림을 전송하기 위한 방법으로 구성됩니다. 반면 감사는 일반적으로 시스템에 충족하도록 정의한 정책 집합과 대조하여 시스템 상태를 검사하기 위해 사용됩니다.

감사 및 모니터링에 대해서는 다음 요구사항을 고려해야 합니다.

  • 현재 사용 중인 시행 제어 및 이러한 제어가 정책을 위반했는지 감사 혹은 모니터링하는 방법
  • 통합 모니터링 솔루션 또는 분리된 모니터링 솔루션이 필요한지 여부

필요한 보안 제어 이해

이 섹션에서는 다음을 수행하기 위해 필요한 제어에 대해 설명합니다.

  • 정책 시행 가이드에 설명된 대로 정책 시행을 보완하는 감사를 구현합니다.

  • 배포된 위치에 관계없이 Anthos GKE 클러스터와 작동하는 모니터링 솔루션을 구현합니다.

네임스페이스

동일한 정책을 사용해야 하는 리소스에 라벨 지정

네임스페이스를 사용하면 pod, 서비스, 복제 컨트롤러와 같은 클러스터 내의 관련 리소스에 대한 범위를 제공할 수 있습니다. 네임스페이스를 사용하면 관련 리소스에 대한 관리 책임을 하나의 단위로 위임할 수 있습니다. 따라서 네임스페이스는 대부분의 보안 패턴에 필수적입니다.

네임스페이스는 제어 영역 격리를 위한 중요한 기능입니다. 하지만 노드 격리, 데이터 영역 격리, 네트워크 격리는 제공하지 않습니다.

일반적인 방법은 개별 애플리케이션에 대해 네임스페이스를 만드는 것입니다. 예를 들어 애플리케이션의 UI 구성요소에 대해 myapp-frontend 네임스페이스를 만들 수 있습니다.

Anthos Config Management

Anthos 클러스터에 구성 적용

Anthos 클러스터를 관리할 때 권장사항은 등록된 클러스터를 구성과 동기화된 상태로 유지하는 Anthos Config Management를 사용하는 것입니다. 구성저장소에 저장된 YAML 또는 JSON 파일이며, kubectl apply 명령어를 사용하여 클러스터에 수동으로 적용할 수 있는 동일한 유형의 구성 세부정보를 포함합니다. Anthos Config Management를 사용하면 코드형 정책 방식을 채택하여 앱을 관리하듯이 정책 및 인프라 배포를 관리할 수 있습니다.

Anthos Config Management는 선언된 정책의 단일 정보 소스로 사용되는 Git 저장소와 함께 사용합니다. Anthos Config Management는 RBAC, 리소스 할당량, 네임스페이스, 플랫폼 수준 인프라 배포와 같은 액세스 제어 정책을 관리할 수 있습니다. Anthos Config Management는 선언적 방식을 사용해 클러스터 상태를 지속적으로 확인하고 구성에 선언된 상태를 적용하여 정책을 시행합니다.

Anthos Policy Controller

정책 준수 시행

Anthos Policy ControllerOpen Policy Agent(OPA)로 실행되는 CustomResourceDefinition 기반(CRD 기반) 정책을 시행하는 Kubernetes용 동적 허용 컨트롤러입니다.

허용 컨트롤러는 요청이 승인되고 허용된 이후이나 객체가 유지되기 전에 Kubernetes API 서버로의 요청을 가로채는 Kubernetes 플러그인입니다. 허용 컨트롤러를 사용하여 클러스터 사용 방법을 제한할 수 있습니다.

Policy Controller를 사용하려면 제약조건 템플릿에서 제약조건 집합을 선언합니다. 제약조건 템플릿이 클러스터에 배포되었으면 제약조건 템플릿으로 정의된 개별 제약조건 CRD를 만들 수 있습니다.

다음 다이어그램은 Policy Controller가 OPA 제약조건 프레임워크를 사용하여 정책을 정의하고 시행하는 방법을 보여줍니다.

OPA 제약조건 프레임워크는 요청을 수신하고 다른 리소스에 대해 액세스 정책을 시행합니다.

다이어그램에 표시된 항목은 다음과 같습니다.

  1. 제약조건은 제약조건 템플릿에서 생성됩니다.
  2. 정책은 제약조건을 적용하여 클러스터에서 사용 설정됩니다.
  3. 요청이 들어오고 허용 검토가 트리거되면 허용 또는 거부가 결정됩니다.
  4. 지속적인 감사로 정책에 대해 클러스터의 모든 활성 객체를 평가합니다.

Policy Controller를 사용하여 라벨 시행과 같은 커스텀 정책을 시행할 수 있습니다. Policy Controller를 사용하면 PodSecurityPolicies를 사용하여 적용할 수 있는 제약조건을 대부분 적용할 수 있습니다. 하지만 일반적으로는 다음과 같은 이유로 더 적은 운영 오버헤드가 필요합니다.

  • Policy Controller에는 제약조건 템플릿이 포함된 기본 템플릿 라이브러리가 있습니다. 따라서 PodSecurityPolicies에서와 같이 일반 사례에 대해 고유 정책을 작성할 필요가 없습니다.
  • PodSecurityPolicies를 사용할 때와 같이 RoleBindings를 관리할 필요가 없습니다.
  • Policy Controller는 테스트 실행 모드를 지원하므로 제약조건을 적용하기 전에 제약조건의 효과를 검사할 수 있습니다.
  • 정책 범위를 네임스페이스로 지정하여 보다 제한적인 정책을 점진적으로 적용할 수 있습니다. 이것은 예상치 않은 효과가 발생할 수 있는 정책 출시의 노출을 관리하는 카나리아 릴리스 전략과 비슷합니다. 예를 들어 출시했을 때 pod에서 볼륨으로의 액세스가 제한되었지만 pod에 볼륨 액세스가 필요하다는 것이 밝혀질 수 있습니다.
  • Policy Controller는 커스텀 제약조건 또는 Gatekeeper 저장소에 정의된 PodSecurityPolicies 제약조건인지 여부에 관계없이 정책을 적용하기 위한 단일 방법을 제공합니다.

Policy Controller를 사용하여 사용자가 정의하는 정책을 시행하는 방법에 대한 자세한 내용은 Anthos Config Management Policy Controller를 참조하세요.

Kubernetes Engine Operations

GKE 클러스터 모니터링

Kubernetes Engine Operations는 GKE 클러스터를 모니터링하도록 설계되었습니다. Cloud Monitoring 및 Cloud Logging 서비스를 함께 관리하고 GKE 클러스터에 맞게 맞춤설정된 Kubernetes Engine Operations 대시보드를 제공합니다. Kubernetes Engine Operations에는 클러스터, 노드, pod, 컨테이너와 같은 리소스를 나타내는 GKE 모니터링 리소스 집합이 포함되어 있습니다. GKE용 Kubernetes Engine Operations 및 GKE On-Prem 클러스터를 사용 중지할 수 있지만 이 제품들에 대해 사용 설정된 상태를 유지하는 것이 좋습니다.

Security Health Analytics

취약점 식별

Security Health Analytics는 Google Cloud 리소스에서 발생 가능한 구성 오류 및 규정 준수 위반을 식별하고 적절한 교정 조치를 제안하여 사고를 방지하는 데 도움이 됩니다. Security Health Analytics 스캐너는 Security Command Center에서 제공되는 취약점 찾기 유형을 생성합니다. 컨테이너 스캐너 찾기는 GKE 컨테이너 구성과 관련이 있으며 CONTAINER_SCANNER 스캐너 유형에 속합니다.

Pub/Sub와 Security Command Center 통합

알림 앱을 사용하여 Security Command Center에서 검색 결과에 대한 알림을 받을 수 있습니다. 앱이 알림 Pub/Sub 주제를 구독하고 이메일 또는 SMS와 같은 구성된 채널에 알림을 전송합니다.

Cloud 애셋 인벤토리

Google Cloud 리소스 모니터링

Cloud 애셋 인벤토리를 사용하면 실시간 알림을 통해 사용자가 구독한 리소스 및 정책 변경사항을 모니터링할 수 있습니다. 조직, 폴더, 프로젝트 내부에서 또는 사용자가 지정하는 다른 리소스에서 지원되는 리소스 유형정책 유형 변경사항을 모니터링할 수 있습니다. 피드를 생성하여 구독을 설정합니다. 지원되는 애셋 유형에는 GKE 리소스 유형 및 Cloud IAM 정책 유형이 포함됩니다.

방화벽 규칙 및 IAM 정책 변경사항과 같은 보안에 민감한 리소스를 모니터링할 수 있습니다. 이러한 리소스 변경사항은 즉시 Pub/Sub를 통해 알림을 전송하므로 필요에 따라 빠르게 조치를 수행할 수 있습니다.

실시간 알림은 기존 워크로드에 연결됩니다. 이 기능을 사용하면 변경사항이 감지된 후 Cloud 함수 만들기와 같은 작업을 병합하여 리소스 변경사항을 되돌릴 수 있습니다.

Cloud 감사 로그를 사용하여 알림

GKE 클러스터는 Kubernetes Audit LoggingCloud 감사 로그Cloud Logging과 통합합니다. Kubernetes Engine Operations를 사용하여 로그 항목을 기준으로 측정항목을 설정할 수 있습니다. 그런 후 로그 기반 측정항목을 사용하여 알림 정책을 설정할 수 있습니다.

알림 정책은 트리거된 알림 정책을 알리는 방법을 지정할 수 있게 해주는 알림 채널을 지정합니다. 변경사항을 되돌리거나 이메일로 알림을 제공하는 등 응답 조치를 수행하기 위해 Cloud Run 또는 Cloud Functions를 사용하여 알림 핸들러를 설정할 수 있습니다.

총정리

제어를 통합하려면 감사 및 모니터링 요구를 확인합니다. 그런 후 이어지는 단계에 설명된 대로 이 가이드에 설명된 제어 범위와 이를 구성할 단계를 배치합니다.

  1. 클러스터 구성을 시작하려면 먼저 하이브리드 및 멀티 클라우드 모니터링 및 로깅 패턴을 참조하여 필요한 격리 수준을 결정합니다.

  2. 클러스터를 만듭니다. 적용 가능한 클러스터 강화 가이드(GKE 또는 GKE On-Prem)의 안내를 따릅니다. 클러스터를 만들 때는 강화 가이드를 따르고 --enable-network-policy 플래그를 사용해야 합니다. 네트워크 정책이 필요합니다. 이 단계에서는 이후에 클러스터의 pod간에 전송되는 트래픽을 제한하는 방화벽 규칙을 구현할 수 있습니다.

  3. pod에 필요한 네임스페이스 및 라벨을 정의합니다. 이것은 정책 및 Kubernetes 서비스 계정에 사용할 수 있는 이름 범위를 제공합니다.

  4. Anthos Config Management를 사용하여 Policy Controller를 설치합니다.

    정책 가이드 시행에 설명된 안내를 따릅니다.

  5. 요구 사항을 충족하도록 Kubernetes Engine Operations를 구성합니다.

  6. Kubernetes Engine Operations 알림 정책, 알림, 핸들러를 구성합니다.

  7. Cloud 애셋 인벤토리에서 실시간 알림을 구성합니다.

  8. Security Health Analytics 스캔에서 생성되는 컨테이너 검색 결과를 정기적으로 검토하도록 프로세스를 설정합니다.