[Cloud Armor 시리즈 2] Cloud Armor 의 보안 규칙 사용하기

Cloud Armor 시리즈는 총 3부로 진행되며 본 블로그는 첫번째 ‘Cloud Armor 정책의 종류와 이해’에 이어 그 두번째인 ‘Cloud Armor 의 보안 규칙 사용하기’ 입니다.

Cloud Armor 의 보안 규칙 구성

Google Cloud Armor 를 시작하기 위해 먼저 보안 정책 (Security Policy) 을 설정 하였다면 (참고 : ‘Cloud Armor 정책의 종류와 이해’ ), 이제 Cloud Armor 가 제공하는 보안 규칙 (Rule) 을 적용 할 차례 입니다. 보안 규칙을 이용하여 유입되는 트래픽 중 조치가 필요한 트래픽을 분류하고, 이에 대한 보호 방법을 적용할 수 있습니다. ‘그림1’ 은 보안 정책과 규칙의 관계 및 동작 구조를 설명하는 그림입니다.

보안 규칙은 크게 2가지인 Condition 과 Action 설정으로 구성 됩니다. Condition 설정은 Cloud Armor 가 보호하고 있는 애플리케이션과 리소스로 유입되는 트래픽 중에서, 어떠한 트래픽을 대상으로 보안 규칙을 적용할지 매치 조건을 선언하는 작업입니다. 그리고 이렇게 조건과 일치하는 트래픽은 Action 설정을 이용하여 조치 방법을 결정할 수 있습니다. 허용/차단 설정이나 Redirect, Rate-limit 등 다양한 조치 방법을 구성할 수 있습니다.

그럼 보안 규칙의 Condition 과 Action 에 대해 좀 더 자세히 살펴보도록 하겠습니다.

Rule - Condition 설정

Condition 은 2가지 모드를 지원하며 기본적인 IP 주소를 사용하여 화이트리스트/블랙리스트 를 구성할 수 있는 Basic Mode 와 L7 기반의 패턴 탐지와 다양한 조건문을 적용할 수 있는 Advanced Mode 로 구성 됩니다.

Advanced Mode 는 Google 에서 만든 오픈소스 기반의 표현 언어인 CEL (Common Expression Language) 을 사용합니다. CEL 은 데이터 표현, 필터링, 검증 등의 구현을 위해 개발 되었으며 Google Cloud 뿐만 아니라 Kubernetes, Envoy 등에서 범용적으로 사용되고 있습니다.

이를 이용하여 애플리케이션 헤더에 대한 다양한 조건과 페이로드 기반의 사용자 규칙 설정이 가능 합니다. CEL 을 이용하여 규칙의 패턴을 작성하는 몇 가지 예제를 확인해 보겠습니다.

• 특정 Geolocation 과 IP 대역 매치 표현

• HTTP 헤더 내에 특정 User-Agent 를 포함하고, 특정 IP 호스트 매치 표현

• HTTP 의 Content-length 가 256 Byte 이거나 그 이하인 매치 표현

• OWASP CRS 3.3 XSS 특정 룰에 대한 매치 표현

• OWASP CRS 3.3 SQLi 의 특정 룰을 예외처리하는 표현

Cloud Armor 의 Advanced Mode 를 이용한 WAF 규칙 구성의 자세한 설명과 예제는 Configure custom rules language attributes | Google Cloud Armor 및 Google Cloud Armor preconfigured WAF rules overview 에서 확인 가능 합니다.

Rule - Action 적용

Condition 설정에서 제공하는 다양한 패턴 매치를 이용하여 특정 트래픽의 접속을 지정하였다면, Action 기능을 이용하여 해당 트래픽에 대한 조치 방법을 구현할 수 있습니다. Action 은 총 5가지의 설정을 제공하며 아래와 같습니다.

• Allow : 해당 Condition 에 매치되는 트래픽을 허용합니다
• Deny : 해당 Condition 에 매치되는 트래픽을 차단합니다.
• Throttle : 설정 된 Interval (초, 분) 동안의 최대 Request count 를 제어할 수 있습니다.
• Rate-based-ban : 설정 된 Interval (초, 분) 동안의 최대 Request count 를 초과하는 클라이언트에 대해 설정 된 Duration (분) 동안 트래픽을 차단합니다.
• Redirect : 해당 Condition 에 매치되는 트래픽을 외부 서버로 리다이렉트 (HTTP 302 Redirect) 하거나, Google reCaptcha 를 이용한 봇넷 탐지를 적용할 수 있습니다.

Throttle 과 Rate-based-ban 의 경우 클라이언트 요청의 HTTP Header, Cookie, Path 등의 값을 사용하여 좀 더 세분화 된 클라이언트 기반의 Rate-limit 기능을 구현할 수 있습니다. 예를 들어 아래 ‘그림3’ 과 같이 Enforce on key configuration 에 ‘X-Forwarded-For IP’ 를 사용할 경우 HTTP 헤더를 확인하여 프록시의 대표 IP 가 아닌 Original IP 단위로 트래픽의 양을 모니터링하고 이에 대한 Action 이 적용되도록 구성할 수 있습니다.

차단 시 클라이언트에게 반환 할 차단 Error 로는 403 (Forbidden), 404 (Not found), 502 (Bad gateway) 중 하나의 Response 를 선택할 수 있으며, Throttle 과 Rate-based-ban 의 경우 429 (Too many request) Error 도 적용 가능합니다.

Rule 설정 시 추가적인 고려사항

Priority : Cloud Armor 의 보안 규칙 (Rule) 은 각 규칙마다 우선순위 (Priority) 를 설정할 수 있습니다. Priority 값이 낮은 규칙이 값이 높은 규칙보다 먼저 평가 됩니다. 그리고 규칙에 의해 평가된 트래픽은 그 다음의 규칙을 적용받지 않습니다. 예를 들어 아래와 같은 규칙이 있다고 가정합니다.

• [Priority 100] IP = 1.2.3.4/32 -> Allow
• [Priority 200] HTTP User-Agent = Chrome -> Deny

만약 IP 1.2.3.4, User-Agent Chrome 이 모두 해당되는 클라이언트가 접속 시, 우선순위가 높은 (Priority 값이 낮은) 규칙에 의해 트래픽은 Allow 되며 우선순위가 낮은 Deny 규칙에 대한 평가는 진행되지 않습니다.

규칙 작성의 순서 : 보안 정책 (Security Policy) 를 생성하면 모든 트래픽에 대해 차단하는 기본 룰이 가장 낮은 우선순위를 갖는 Priority 2,147,483,647 값으로 자동 생성됩니다. 따라서 사용자는 규칙 작성 시 허용할 트래픽의 규칙을 작성하는 것이 필요하며, 이에 앞서 차단이 필요한 정책이 우선 평가되도록 규칙의 우선순위를 고려 할 필요가 있습니다.

Preview Only : 규칙을 작성하고 Preview only 모드를 활성화 하면 규칙에 해당되고 차단이 설정되어 있더라도 트래픽을 허용하며 이에 대한 로그 정보만을 생성합니다. 사용자는 이 기능을 이용하여 우선 규칙에 대한 영향도를 먼저 확인한 후 실제 차단 정책을 적용할 수 있으므로 사용자의 잘못된 정책 설정에 의한 서비스 영향도를 최소화 할 수 있습니다.

Cloud Armor 규칙 적용 예제

한국 (KR) 에서 접속하는 클라이언트 중에서 HTTP Header 의 특정 User-Agent (Hacker) 를 사용하는 트래픽에 대해 403 Forbidden Error 를 이용한 차단 정책을 설정 합니다.

아래와 같이 클라이언트의 IP 가 한국에서 접속할때, 특정 User-Agent 를 가지는 요청에 대해서만 403 Forbidden Error 를 반환하며 접속을 차단하는 것을 확인할 수 있습니다.

마치며

지금까지 Cloud Armor 가 제공하는 보안 규칙(Rule) 을 사용하여 트래픽에 대한 매치 패턴을 설정하고 이에 대한 조치(Action) 을 설정하는 방법과 예제를 확인하였습니다. 사용자는 IP 기반의 간단한 규칙 뿐만 아니라 패킷의 헤더나 페이로드 기반의 규칙을 만들고 이에 대한 조치를 다양하게 구현할 수 있습니다.

보안 정책의 선택, 그리고 보안 규칙을 적용하여 트래픽을 제어하고 애플리케이션을 보호하는 설정을 마쳤다면, 다음 블로그에서는 Cloud Armor 시리즈의 마지막으로 탐지 이벤트를 확인하는 방법에 대해 알아보도록 하겠습니다.