이 페이지에서는 Google Cloud Armor 배포 최적화 및 조정 권장사항을 제공합니다.
Google Cloud Armor는 전역 외부 애플리케이션 부하 분산기, 기본 애플리케이션 부하 분산기 또는 외부 프록시 네트워크 부하 분산기와 함께 배포됩니다. Google Cloud Armor를 배포할 때 보호하려는 부하 분산기 백엔드 서비스에 보안 정책을 연결합니다. 보안 정책은 개발자가 미리 구성한 커스텀 규칙의 모음으로 구성됩니다.
보안 정책 및 규칙 생성
다음 섹션에는 새 보안 정책 및 규칙에 대한 권장사항과 추천이 포함되어 있습니다.
규칙 설명 제공
규칙 설명을 사용하여 각 규칙이 생성된 이유와 규칙의 의도된 함수에 대한 추가 컨텍스트를 제공합니다. 설명 필드는 64자로 제한되므로 구성 관리 데이터베이스 또는 기타 저장소에 대한 참조가 컨텍스트를 캡처하는 가장 효율적인 방법입니다.
우선순위 간격 고려
처음에 규칙을 구성할 때 각 규칙 우선순위 값 사이에 최소 10의 간격을 둡니다. 예를 들어 보안 정책의 처음 두 규칙이 각각 우선순위 20과 30일 수 있습니다. 이렇게 하면 필요할 때 더 많은 규칙을 삽입할 수 있습니다. 또한 비슷한 규칙을 블록으로 그룹화하여 그룹 간의 간격을 더 크게 하는 것이 좋습니다.
미리보기 모드 사용
OWASP(Open Web Application Security Project) 서명을 포함한 보안 정책 규칙은 애플리케이션에 예기치 않은 영향을 미칠 수 있습니다. 미리보기 모드를 사용하여 규칙 도입이 프로덕션 트래픽에 부정적인 영향을 미치는지 평가합니다.
Google Cloud Armor Adaptive Protection 사용 설정
Adaptive Protection을 사용 설정하여 애플리케이션을 추가로 보호합니다. Adaptive Protection은 트래픽을 모니터링하고 필요에 따라 새 보안 정책 규칙을 추천합니다. 또한 잠재적 공격에 대한 알림이 적절한 사람에게 제공되도록 알림 정책을 마련하는 것이 좋습니다. Adaptive Protection은 볼륨 보호에 가장 적합합니다. 볼륨이 아닌 공격은 Adaptive Protection을 트리거하지 않을 수 있습니다.
JSON 파싱 사용 설정
애플리케이션이 POST 요청 본문에 JSON 콘텐츠를 보내는 경우 JSON 파싱을 사용 설정해야 합니다. JSON 파싱을 사용 설정하지 않으면 Google Cloud Armor는 사전 구성된 WAF 규칙에 대한 POST 본문의 JSON 콘텐츠를 파싱하지 않으며, 결과에 노이즈가 있고 거짓양성이 발생할 수 있습니다. 자세한 내용은 JSON 파싱을 참조하세요.
로직 테스트
일치 조건이 true로 평가되면 규칙이 트리거됩니다. 예를 들어 일치 조건 origin.region_code == 'AU'는 요청의 리전 코드가 AU이면 true로 평가됩니다. 우선순위가 더 높은 규칙이 true로 평가되는 경우 우선순위가 낮은 규칙의 작업은 무시됩니다. 다음 예시에서 IP 주소 범위 10.10.10.0/24 내의 트래픽을 제외하고 AU 리전의 사용자를 차단하는 보안 정책을 만든다고 가정해 보겠습니다. 두 가지 규칙이 있는 다음 보안 정책을 살펴보세요.
Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: allow
priority: 1
Rule2
expr: origin.region_code == 'AU'
action: deny(403)
priority: 2
이 예시에서 Rule1은 IP 주소 범위 10.10.10.0/24에서 발생하는 트래픽을 허용합니다. Rule1은 우선순위가 더 높은 규칙이므로 이러한 트래픽은 Rule2에 대해 평가되기 전에 허용됩니다. 즉, Google Cloud Armor는 Rule2(또는 기타 나머지 규칙)에 대해 평가하지 않습니다.
Google Cloud Armor 정책을 만들 때 규칙의 로직을 테스트하여 의도한 대로 동작하는지 확인합니다. 이렇게 하려면 합성 트래픽을 생성하여 트래픽을 차단하는 규칙을 이해하고, 결과가 규칙의 설계 결정과 일치하는지 확인하는 것이 좋습니다. 요청이 시스템을 통과하는 방식을 모른다면 미리보기 모드를 사용하여 요청과 일치하는 규칙을 확인하세요.
스캐너의 소스 IP 주소 식별
보안 스캐너는 Google 내부 또는 외부에 위치할 수 있습니다. 애플리케이션의 외부 및 필터링되지 않은 평가를 원하는 경우 다른 규칙에 대해 평가하기 전에 IP 주소(또는 다른 토큰)를 기반으로 트래픽을 명시적으로 허용할 수 있습니다.
보안 정책의 규칙 그룹화 및 정렬
애플리케이션은 고객의 다양한 하위 집합을 제공할 수 있습니다. 다음 예시에서는 특정 지리적 영역 또는 IP 범위에서 발생하는 트래픽을 거부하기 위해 정책의 첫 번째 규칙을 구성합니다. 또한 해당 애플리케이션으로 들어오는 일부 트래픽을 보안 정책의 처리 없이 명시적으로 허용하려고 합니다. 이 예시에서는 가장 높은 우선순위부터 가장 낮은 우선순위까지 다음과 같은 규칙 우선순위 구조를 사용하는 것이 좋습니다.
- 명시적 거부 규칙(ASN, 리전, IP 범위)
- 신뢰할 수 있는 명시적 허용 규칙(스캐너, 신뢰할 수 있는 시스템 - 매우 주의해서 사용)
- 보안 규칙(OWASP, 커스텀 규칙)
- 명시적 허용 규칙(ASN, 헤더 값 유무, IP 범위)
- 기본 거부 규칙
봇 관리에 reCAPTCHA 사용
Google Cloud Armor는 WAF 레이어에서 봇 감지를 위해 Google의 reCAPTCHA와 통합됩니다. 이 통합에서 reCAPTCHA는 reCAPTCHA 토큰을 생성하고 Google Cloud Armor는 reCAPTCHA 대신 토큰 평가 프로세스를 수행합니다. 이렇게 하면 원본 부하가 줄어들고 비용이 절감되며 보안 제어가 백엔드보다 최종 사용자에게 더 가까워집니다. 자세한 내용은 봇 관리 개요를 참조하세요.
비율 제한 임곗값 설정
비율 제한은 악용을 방지하고 크리덴셜 스터핑 또는 L7 DDoS 공격과 같은 대량의 위협을 완화하는 유연하고 유용한 기능입니다. 비율 제한을 처음 배포할 때는 애플리케이션에 적합한 임곗값을 선택하는 것이 중요합니다. 먼저 미리보기 모드에서 시행하는 것이 좋습니다. 트래픽 프로필을 분석하고 이해하면 비율 제한 매개변수를 조정할 수 있습니다. 또한 비율 제한 규칙에 할당하는 우선순위를 고려해야 합니다. 트래픽이 비율 제한 규칙에 따라 평가되기 전에 우선순위가 더 높은 규칙에 의해 명시적으로 허용되거나 거부될 수 있습니다.
규칙 조정
웹 애플리케이션은 공격으로 보이는 요청을 허용할 수 있으며, 사전 구성된 WAF 규칙의 서명과 일치하는 요청을 허용하거나 사용자로 하여금 해당 요청을 보내도록 요구할 수 있습니다. 프로덕션 애플리케이션에서 미리보기 모드를 사용 중지하여 규칙을 승격하기 전에 애플리케이션에 대해 Google Cloud Armor 규칙의 유효성을 검사하고 애플리케이션과 관련이 없는 발견 항목을 확인하는 것이 중요합니다. 다음 섹션에는 사전 구성된 WAF 규칙을 조정하기 위한 권장사항과 추천이 포함되어 있습니다.
사전 구성된 WAF 규칙 민감도 수준 선택
사전 구성된 WAF 규칙을 구현할 때 보안 요구사항 및 타임라인에 따라 적절한 민감도 수준을 선택할 수 있습니다. 조직의 보안 요구사항을 충족해야 하는 대부분의 애플리케이션에서는 민감도 수준 1로 시작하는 것이 좋습니다. 민감도 1로 구성된 규칙은 고품질 서명을 사용하고 규칙의 잠재적 노이즈를 줄입니다. 더 높은 민감도와 관련된 서명은 일부 보호된 애플리케이션에 대해 노이즈가 발생할 수 있는 측면이 있지만 더 많은 악용 시도를 감지하고 방지할 수 있습니다. 그러나 엄격한 보안 요구사항이 적용되는 워크로드는 가장 높은 민감도 수준을 선호할 수 있습니다. 이러한 사용 사례에서는 보안 정책이 프로덕션 단계로 적용되기 전에 조정을 사용하여 해결해야 하는 많은 노이즈 또는 관련성 없는 발견 항목이 있을 수 있습니다.
상세 로깅 사용 설정
특정 WAF 규칙을 트리거하는 요청 속성 및 페이로드에 대한 추가 정보가 필요한 경우 상세 로깅을 사용 설정합니다. 상세 로깅은 요청에서 문제가 되는 부분의 스니펫을 포함하여 특정 규칙을 트리거하는 요청의 세부정보를 제공하므로 Google Cloud Armor의 문제를 해결하고 조정하는 데 유용합니다. 상세 로깅을 사용하면 최종 사용자 요청 콘텐츠가 Cloud Logging에 로깅될 수 있으므로 로그에 최종 사용자 개인 식별 정보가 축적될 수 있습니다. 따라서 장기간 동안 상세 로깅이 사용 설정된 프로덕션 워크로드를 실행하지 않는 것이 좋습니다.
정식 또는 카나리아 규칙 사용
사전 구성된 Google Cloud Armor WAF 규칙에는 정식과 카나리아가 있습니다. 새로운 규칙이 현재 ModSecurity Core Rule Set(CRS)에 추가되면 Google에서는 해당 규칙을 카나리아 규칙 빌드에 게시한 후 정식 규칙 빌드에 자동으로 게시합니다. 카나리아 규칙을 테스트 환경에 배포하여 환경에서의 변경 및 추가에 따른 영향을 확인할 수 있습니다. Google Cloud Armor WAF 규칙 조정 페이지에서 규칙 이름을 확인하여 카나리아 빌드가 정식 빌드와 동기화되었는지 확인할 수 있습니다.
로그 기록 및 모니터링
다음 섹션에는 로깅 및 모니터링을 구성하기 위한 권장사항과 추천이 포함되어 있습니다.
Security Command Center 사용
Google Cloud Armor는 Security Command Center와 자동으로 통합됩니다. Google Cloud Armor는 서로 다른 발견 항목을 Security Command Center로 내보냅니다.
- 허용된 트래픽 급증
- 거부율 증가
웹 보안 담당자가 이러한 발견 항목을 검사해야 합니다.
Cloud Logging 샘플링 레이트 선택
Google Cloud Armor 요청별 로그는 전역 외부 애플리케이션 부하 분산기나 기본 애플리케이션 부하 분산기의 로깅 인프라를 사용합니다. 따라서 Google Cloud Armor 로그 생성에는 부하 분산기에 구성된 로그 샘플링 레이트가 적용됩니다. Google Cloud Armor를 적극적으로 조정하고 구현할 때는 샘플링 레이트를 1로 유지하는 것이 좋습니다. Google Cloud Armor를 조정하고 구현한 후에는 전체 요청 로깅을 사용 설정하는 것이 좋습니다. 그러나 더 느린 속도로 다운샘플링하려고 할 수 있습니다. 전역 외부 애플리케이션 부하 분산기와 기본 애플리케이션 부하 분산기는 기본적으로 로그를 사용 설정하지 않으므로 로깅을 수동으로 사용 설정해야 합니다.
Cloud Monitoring 대시보드 사용
Google Cloud Armor 구성에서 어떤 일이 일어나고 있는지를 명확하게 파악하는 것이 중요합니다. 이를 더 쉽게 하려면 보안 대시보드를 사용하면 됩니다. 또한 Google Cloud Armor 로그를 Logging에서 자체 플랫폼으로 직접 내보낼 수 있습니다. Adaptive Protection을 사용하는 경우 트리거되는 Adaptive Protection 알림의 에스컬레이션 경로가 있어야 합니다.
일반 관리
다음은 Google Cloud Armor 구성을 위한 추가 권장사항과 추천입니다.
Identity and Access Management 액세스 제어 설정
일반적인 Google Cloud IAM 권장사항에 따라 적절한 사용자가 Google Cloud Armor에 대한 액세스 권한을 가지는지 확인하세요. Google Cloud Armor 보안 정책을 구성, 수정, 업데이트, 삭제하려면 Compute 보안 관리자 역할이 필요합니다. 또한 백엔드 서비스에 Google Cloud Armor 보안 정책을 연결하려면 Compute 네트워크 관리자 역할 또는 compute.backendServices.setSecurityPolicy 권한이 필요합니다.
정책 수 최소화
Google Cloud Armor 정책은 여러 백엔드 서비스에서 재사용할 수 있습니다. 재사용 가능한 일관된 보안 정책을 가지는 것이 좋습니다.
Terraform 사용
구성을 쉽게 롤백하고 프로젝트 간에 재현할 수 있도록 하려면 Terraform을 사용하는 것이 좋습니다. Google Cloud Armor에는 정식 버전 기능을 위한 전체 Terraform 통합이 있습니다.
Google Kubernetes Engine으로 Google Cloud Armor 구성
GKE를 사용하는 경우 BackendConfig 매개변수를 통해 Google Cloud Armor 및 기타 인그레스 기능을 구성해야 합니다. 전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기가 인그레스 지점 역할을 하도록 수동으로 구성하지 않는 것이 좋습니다. GKE를 사용하여 Google Cloud Armor를 구성하는 방법에 대한 자세한 내용은 인그레스 기능 구성을 참조하세요.