계층적 보안 정책 개요

계층적 보안 정책은 Google Cloud Armor 웹 애플리케이션 방화벽(WAF) 및 DDoS 보호 범위를 개별 프로젝트를 넘어 확장하는 보안 정책 카테고리입니다. 조직, 폴더 또는 프로젝트 수준에서 연결됩니다. 이는 백엔드 서비스 또는 백엔드 버킷에 직접 연결되는 서비스 수준 보안 정책과 다릅니다.

조직 또는 폴더 수준에서 계층적 보안 정책을 구성하면 계층 구조의 하위 수준에 있는 프로젝트가 해당 보안 정책을 상속합니다. 이 상속을 통해 조직 내의 모든 프로젝트 또는 여러 프로젝트에 적용할 보안 정책 규칙을 설정할 수 있습니다. 이를 통해 Trusted Cloud by S3NS 환경 전반에서 중앙 집중식으로 일관된 보안을 적용할 수 있습니다.

이 페이지에서는 계층적 보안 정책이 서비스 수준 보안 정책과 어떻게 다른지 설명합니다. 계속하기 전에 보안 정책 개요를 읽고 보안 정책이 작동하는 방식을 이해해야 합니다. 또한 리소스 계층 구조를 숙지하는 것이 좋습니다.

사용 사례

대규모 조직에서는 여러 프로젝트에 걸쳐 보안 정책을 관리하는 것이 복잡하고 시간이 오래 걸릴 수 있습니다. 계층적 보안 정책은 이러한 문제를 해결하는 데 도움이 되는 다음과 같은 이점을 제공합니다.

  • 중앙 집중식 제어: 조직 및 폴더 수준 관리자에게 여러 프로젝트에 걸쳐 보안 정책을 정의하고 적용할 수 있는 기능을 제공합니다.
  • 일관성: 조직 전체에서 일관된 보안 태세를 제공하여 잘못된 구성과 보안 격차의 위험을 줄입니다.
  • 효율성: 다수의 리소스에 동시에 보안 업데이트 및 완화 조치(예: 특정 IP 주소 범위 차단 또는 심각한 취약점 해결)를 간소화합니다.
  • 위임: 계층 구조의 적절한 수준에서 정책을 적용하여 여러 팀 또는 부서에 보안 책임을 위임할 수 있습니다.

이러한 일반 원칙을 조직의 요구사항에 맞게 적용하고 조합할 수 있습니다. 다음과 같은 사용 사례를 고려해 보세요.

  • 조직 전체 IP 주소 차단: 조직의 모든 프로젝트에서 알려진 악성 IP 주소 범위의 트래픽을 차단할 수 있습니다.
  • 지역 기반 제한: 조직 또는 폴더 수준에서 특정 지리적 지역의 트래픽을 제한할 수 있습니다.
  • CVE 완화: 여러 프로젝트에서 심각한 취약점을 완화하기 위해 WAF 규칙을 신속하게 배포할 수 있습니다.
  • 규정 준수 시행: 조직 전체에 일관된 보안 정책을 적용하여 규제 요구사항 준수를 시행할 수 있습니다.
  • 세부적인 액세스 제어: 특정 폴더 내의 모든 리소스에 대한 액세스 권한을 특정 IP 주소 범위 또는 지리적 지역에 부여할 수 있습니다.

기능

계층적 보안 정책은 서비스 수준 보안 정책에서 지원하는 기능의 하위 집합을 지원합니다. 다음 표에서는 계층적 보안 정책 및 서비스 수준 보안 정책과 함께 사용할 수 있는 Google Cloud Armor 기능을 비교합니다.

서비스 수준 전역 백엔드 보안 정책
계층식 백엔드 보안 정책
프런트엔드 유형
  • 전역 외부 애플리케이션 부하 분산기
  • 기본 애플리케이션 부하 분산기
  • 전역 외부 애플리케이션 부하 분산기
  • 기본 애플리케이션 부하 분산기
연결 지점(보호된 리소스) 백엔드 서비스 리소스 계층 구조 노드
규칙 작업
  • 허용
  • 거부
  • 리디렉션(GOOGLE_RECAPTCHA 및 EXTERNAL_302)
  • 제한
  • 비율 기반 차단
  • 허용
  • 거부
  • 리디렉션(EXTERNAL_302만 해당)
  • 다음으로 이동
소스 IP 주소
소스 지역
소스 ASN
봇 관리 (EXTERNAL_302 및 요청 장식만 해당)
레이어 7 필터링
WAF
Google Threat Intelligence
reCAPTCHA
Adaptive Protection
주소 그룹
조직 수준 주소 그룹
Security Command Center
Cloud Monitoring
요청 로깅

계층적 보안 정책의 작동 방식

계층적 보안 정책을 만들 때는 조직 또는 폴더 수준에서 만들며 해당 리소스가 계층적 보안 정책의 소유권을 갖습니다. 계층적 보안 정책을 만든 후에는 보안 정책 규칙이 리소스에 적용되지 않습니다.

그런 다음 계층적 보안 정책을 조직, 폴더 또는 프로젝트와 연결합니다. 이는 정책을 소유한 리소스와 동일할 수 있습니다. 계층적 보안 정책을 리소스와 연결하면 리소스 계층 구조에서 해당 노드에 있는 보호된 리소스와 해당 노드 아래에 있는 보호된 리소스에 보안 정책 규칙이 적용됩니다. 계층적 보안 정책을 연결할 리소스를 결정하는 데 도움이 되도록 각 리소스의 기본 사용 사례 목록을 참고하세요.

  • 조직: 조직 수준 계층적 보안 정책을 기본 유형의 계층적 보안 정책으로 간주합니다. 이러한 정책에는 광범위한 Identity and Access Management(IAM) 권한이 있으며 조직의 모든 노드에 적용됩니다. 연결 중에 --organization 플래그를 사용하여 이러한 리소스를 지정합니다.
  • 폴더: 여러 프로젝트에 동일한 보안 정책 규칙을 적용하되 조직 전체에는 적용하지 않으려면 이러한 계층적 보안 정책을 사용합니다. 연결 중에 --folder 플래그를 사용하여 이러한 리소스를 지정합니다.
  • 프로젝트: 프로젝트의 모든 리소스에 동일한 보안 정책 규칙을 적용해야 하는 경우(예: 여러 백엔드 서비스에 IP 주소 차단 목록 적용) 이 유형의 계층적 보안 정책을 사용합니다. 연결 중에 --project 플래그를 사용하여 이러한 리소스를 지정합니다.
  • 서비스 수준: 각 서비스마다 다른 고유한 보안 정책 규칙이 필요한 경우 서비스 수준 보안 정책을 사용합니다. 각 서비스 수준 보안 정책은 연결된 백엔드 정책에만 규칙을 적용합니다. --project-number 플래그를 사용하여 이러한 리소스를 지정합니다.

계층적 보안 정책당 이러한 플래그 중 하나만 사용할 수 있습니다. 서비스 수준 보안 정책을 구성할 때와 마찬가지로 --name 또는 --type과 같은 나머지 플래그를 지정합니다. 계층식 보안 정책의 작동 방식에 대한 자세한 내용은 다음 목록을 참고하세요.

  • 계층적 보안 정책이 리소스 계층 구조 노드와 연결되면 계층 구조에서 해당 노드보다 낮은 모든 보호 리소스가 정책을 상속합니다.
  • 모든 계층적 보안 정책과 서비스 수준 보안 정책에서 프로젝트의 각 보호 리소스에 적용되는 보안 정책을 볼 수 있습니다. 자세한 내용은 보호된 리소스의 모든 유효한 Google Cloud Armor 규칙 보기를 참고하세요.
  • 계층적 보안 정책을 한 리소스 계층 구조 노드에서 다른 노드로 이동할 수 있습니다. 폴더 구조를 재구성하려는 경우에 이 작업을 실행할 수 있습니다.
  • 폴더나 프로젝트와 같은 리소스 계층 구조 노드를 삭제하면 해당 노드에 연결된 계층적 보안 정책은 해당 리소스 계층 구조 노드에서 정책을 생성한 경우에만 삭제됩니다.
    • 다른 곳에서 보안 정책을 만든 후 노드 아래로 이동한 경우 삭제되지 않습니다.
    • 계층적 보안 정책이 실수로 삭제되지 않도록 하려면 기존 노드를 삭제하기 전에 유지하려는 계층적 보안 정책을 다른 리소스 계층 구조 노드로 이동하는 것이 좋습니다.

규칙 평가 순서

Google Cloud Armor는 다음 순서로 보안 정책을 평가합니다.

  1. 조직 수준 계층식 보안 정책
  2. 폴더 수준 계층식 보안 정책(상위 폴더부터 시작하여 각 하위 폴더로 진행)
  3. 프로젝트 수준 계층적 보안 정책
  4. 서비스 수준 보안 정책

이 규칙 평가 순서는 우선순위가 낮은 계층적 보안 정책이 우선순위가 높은 서비스 수준 보안 정책보다 먼저 평가될 수 있음을 의미합니다. 기존의 우선순위가 높은 서비스 수준 보안 정책 규칙을 신중하게 고려하고 계층적 보안 정책에서 허용되거나 거부된 요청을 Google Cloud Armor에서 평가하지 않는 경우 어떤 일이 발생하는지 생각해 보세요.

goto_next 작업

Google Cloud Armor에는 계층적 보안 정책 전용 규칙 작업인 goto_next 작업이 있습니다. Google Cloud Armor가 이 작업을 적용하면 현재 보안 정책 내의 규칙 평가를 중지하고 다음 보안 정책의 규칙 평가를 시작합니다.

조직 전체에서 요청을 제한하는 데 사용할 규칙이 많은 조직 수준의 계층적 보안 정책이 있다고 가정해 보겠습니다. 특정 IP 주소 범위에서 들어오는 요청이 이러한 조직 전체 규칙 평가를 건너뛰도록 하려고 합니다. 따라서 해당 IP 주소 범위와 일치하는 최상위 우선순위 규칙을 goto_next 작업으로 만듭니다. 해당 IP 주소 범위의 요청은 이 규칙에 따라 먼저 평가되며, 일치 조건을 충족하므로 이 조직 수준 계층적 보안 정책의 다른 규칙에 따라 평가되지 않습니다.

동일한 예에서 goto_next 작업 대신 allow 또는 deny 작업을 사용하면 일치 조건이 충족되는 즉시 요청이 허용되거나 거부됩니다. 이 계층적 평가에 따라 해당 요청에 대해 추가 보안 정책이 평가되지 않습니다.

Google Cloud Armor Enterprise 등록 및 청구 행동

계층적 보안 정책을 연결할 때는 계층적 보안 정책을 상속하는 각 프로젝트가 Cloud Armor Enterprise에 등록되어 있어야 합니다. 여기에는 명시적으로 제외되지 않은 계층적 보안 정책이 있는 조직 또는 폴더의 모든 프로젝트와 계층적 보안 정책이 프로젝트에 직접 연결된 모든 프로젝트가 포함됩니다.

  • Cloud Armor Enterprise Annual을 구독하는 Cloud Billing 계정에 연결된 프로젝트는 아직 등록되지 않은 경우 Cloud Armor Enterprise Annual에 자동으로 등록됩니다.
  • Cloud Armor Enterprise 연간 구독이 없으면 계층적 보안 정책을 상속할 때 프로젝트가 Cloud Armor Enterprise 종량제에 자동으로 등록됩니다. 프로젝트가 Cloud Armor Enterprise 종량제에 자동으로 등록된 후 결제 계정을 Cloud Armor Enterprise 연간에 구독하면 프로젝트가 연간에 자동으로 등록되지 않습니다. Cloud Armor Enterprise 종량제에 대한 자세한 내용은 Google Cloud Armor Standard 및 Cloud Armor Enterprise 비교를 참고하세요.
  • 프로젝트가 Cloud Armor Enterprise에 자동으로 등록된 후에 계층적 보안 정책을 업데이트하여 프로젝트를 제외해도 프로젝트는 자동으로 등록 해제되지 않습니다. 프로젝트를 수동으로 등록 해제하려면 Cloud Armor Enterprise에서 프로젝트 삭제하기를 참고하세요.
  • 상속된 계층적 보안 정책이 있는 동안에는 Cloud Armor Enterprise에서 프로젝트를 삭제할 수 없습니다.

제한사항

계층적 보안 정책에는 다음과 같은 제한사항이 있습니다.

  • 조직에 속하지 않는 프로젝트에는 계층적 보안 정책을 사용할 수 없습니다.
  • 새 프로젝트 또는 최근에 복원된 프로젝트의 경우 프로젝트에 상속된 보안 정책이 전파되는 데 몇 시간이 걸릴 수 있습니다.
  • 최근에 Compute Engine API를 사용 설정한 프로젝트의 경우 이 프로젝트에 상속된 보안 정책이 전파되는 데 몇 시간이 걸릴 수 있습니다.
  • 소유한 계층식 보안 정책에서 사전 구성된 WAF 규칙을 조정할 수 있지만 계층식 보안 정책을 상속하는 서비스의 소유자는 규칙 조정을 실행할 수 없습니다.

다음 단계