규칙 평가 순서

규칙 평가는 정책에 설정된 규칙을 사용하여 웹 요청을 허용 또는 거부할지 여부를 결정합니다. 결정을 내릴 때 다음 속성을 고려합니다.

  • 규칙의 우선순위: 정수 값이 작을수록 우선순위가 높습니다.
  • SessionMatcher: 다음 세션 수준 속성과 일치합니다.
    • 소스 머신의 IP 주소
    • 소스 머신의 서비스 계정
    • 소스 머신의 보안 태그
    • 대상 머신의 호스트 이름
  • ApplicationMatcher: 다음 HTTP 요청 속성과 일치합니다.
    • URL
    • 경로
    • 요청 헤더

모든 SessionMatcher 및 ApplicationMatcher 속성의 목록은 SessionMatcher 및 ApplicationMatcher에서 사용 가능한 속성을 참조하세요.

규칙 평가 작동 방식

규칙은 다음 순서로 평가됩니다.

  1. 우선순위가 높은 규칙이 먼저 평가됩니다.
  2. SessionMatcher 및 ApplicationMatcher 속성과 일치하는 우선순위가 가장 높은 규칙이 해당 트래픽에 대해 수행할 작업을 결정합니다.
  3. 요청이 해당 규칙의 SessionMatcher 및 ApplicationMatcher 속성과 일치하지 않으면 우선순위가 가장 높은 다음 규칙이 평가됩니다.
  4. 이 프로세스는 요청과 일치하는 규칙이 발견되거나 모든 규칙이 평가될 때까지 계속됩니다. 일치하는 항목이 없으면 요청이 거부됩니다.

TLS 검사 구성 전

TLS 검사를 구성하기 전에 다음 규칙 평가 시나리오를 이해해야 합니다.

  • 클라이언트는 프록시 서버에 HTTP 요청을 보낼 수 있습니다. 그런 다음 호스트 이름, 소스 ID, HTTP 헤더, 경로를 포함하여 사용 가능한 모든 데이터를 사용하여 요청을 평가합니다.

    요청이 허용되면 HTTP 트래픽이 대상에 전송됩니다. 그러나 요청이 거부되면 HTTP 트래픽이 통과할 수 없습니다.

  • 클라이언트는 프록시에 HTTP CONNECT 요청을 전송하여 대상에 TCP 터널을 설정할 수 있습니다. 이는 클라이언트가 임의의 TCP 트래픽을 전송하거나 HTTPS와 마찬가지로 프록시를 통해 대상과 엔드 투 엔드 TLS 연결을 설정하려는 경우에 수행됩니다.

  • 규칙에 일치하는 SessionMatcher 속성이 있고 ApplicationMatcher 속성이 없는 경우 규칙 평가 결과 트래픽이 허용되고 대상에 대한 터널이 설정된 후 트래픽이 TCP 프록시됩니다. 이는 HTTPS 및 TCP 트래픽에 적용됩니다.

  • 우선순위가 더 높은 규칙이 요청에 대해 취할 작업을 결정할 수 없는 경우 규칙 평가가 계속됩니다. 평가가 ApplicationMatcher 속성이 있는 규칙으로 진행되면 터널링된 트래픽이 HTTP 또는 HTTPS로 해석됩니다.

    기본 데이터가 HTTP 또는 HTTPS가 아니면 연결이 실패합니다.

    기본 데이터가 HTTP이면 호스트 이름, 소스 ID, HTTP 헤더, 경로를 포함하여 요청이 평가됩니다. 평가 결과에 따라 트래픽이 허용되거나 거부됩니다.

  • HTTPS 트래픽의 경우 TLS 검사 플래그가 사용 설정된 경우에만 규칙이 평가됩니다. 그렇지 않으면 규칙을 건너뜁니다.

  • HTTPS 트래픽의 경우 다음 조건이 참인 경우에만 규칙이 검사됩니다.

    • TLS 검사 플래그가 사용 설정되어 있습니다.
    • 트래픽이 SessionMatcher 속성과 일치합니다.

TLS 검사 규칙 구성 권장사항

  • TCP 트래픽을 허용하려면 TCP 트래픽을 허용하는 규칙의 우선순위가 HTTP 트래픽을 허용하는 규칙보다 높아야 합니다.
  • ApplicationMatcher 속성이 있는 규칙은 관련 없는 흐름이 HTTP로 해석되는 것을 최소화하기 위해 SessionMatcher 속성을 사용하여 범위를 좁혀야 합니다.
  • TLS(HTTPS 포함) 트래픽을 허용하지만 TLS 검사를 수행하지 않는 규칙은 TCP 프록시 규칙으로 해석될 수 있습니다.
  • 불필요한 트래픽 TLS 검사를 방지하려면 TLS 검사 규칙이 TLS가 아닌 검사 규칙보다 우선순위가 낮아야 합니다. 또는 일치하지 않는 트래픽에 대해 빠르게 실패하도록 SessionMatcher 속성을 사용하여 TLS 검사 규칙 범위를 좁혀야 합니다.

TLS 검사 규칙 구성 예시

다음 예시에서 두 규칙을 고려하세요.

예 1

이 예시에서는 우선순위가 낮은 다른 규칙이 있다고 가정합니다. 다음 두 가지 규칙을 고려하세요.

  • 규칙 1

    description: do not allow POST requests
priority: 10
basicProfile: DENY
sessionMatcher: true
tlsInspectionEnabled: true
applicationMatcher: request.method == 'POST'

  • 규칙 2

    description: allow TCP proxying from tag 12345 to example.com
priority: 20
basicProfile: ALLOW
sessionMatcher: source.matchTag('tagValues/12345') && host() == 'example.com'

이 예에서 보안 웹 프록시는 두 규칙을 다음과 같이 해석합니다.

  • TCP 트래픽을 허용하지만 특정 유형의 HTTP 요청은 허용하지 않으며 상호 배타적인 것은 TCP 트래픽에 POST 요청이 포함될 수 있기 때문입니다.
  • 규칙 2의 트래픽은 허용되지 않습니다. HTTP 메서드를 평가하기 위해 태그 12345에서 example.com으로의 트래픽을 가로채서 HTTP로 해석되기 때문에 거부됩니다.

  • 규칙 2를 적용하려면 다음 솔루션 중 하나를 사용하세요.

    • 권장: 규칙 2의 우선순위를 더 높은 수준으로 높입니다(우선순위: 5).

    • 허용된 트래픽이 SessionMatcher 속성과 겹치지 않도록 규칙 1의 범위를 지정합니다.

      sessionMatcher: !(source.matchTag('tagValues/12345') && host() == 'example.com')

      겹치는 규칙이 많으면 유지 관리가 어려워지므로 이 솔루션을 권장하지 않습니다.

예 2

다음 두 가지 규칙을 고려하세요.

  • 규칙 1

    description: allow to specific GitHub repository (TLS inspect to match specific path)
priority: 10
basicProfile: ALLOW
sessionMatcher: true
tlsInspectionEnabled: true
applicationMatcher: request.url().startsWith('github.com/grpc/grpc')

  • 규칙 2

    description: allow TCP proxying from tag 12345 to example.com
priority: 20
basicProfile: ALLOW
sessionMatcher: host() == 'bankofamerica.com'

이 예에서 보안 웹 프록시는 두 규칙을 다음과 같이 해석합니다.

  • bankofamerica.com을 대상으로 하는 트래픽을 포함한 모든 트래픽이 TLS에 대해 검사되어 우선순위가 높은 규칙 1의 request.url()과 일치하는지 확인합니다.

  • 규칙 2에서 TLS 검사를 방지하려면 다음 솔루션 중 하나를 사용하면 됩니다.

    • 규칙 2의 우선순위를 더 높은 수준으로 높입니다(우선순위: 5). 따라서 규칙 1을 평가하기 전에 규칙 2가 적용되며 bankofamerica.com의 트래픽은 TLS 검사 없이 허용됩니다.

    • 권장: 규칙 1의 범위를 좁혀서 github.com 도메인에 대해서만 TLS 검사를 허용하세요. 범위를 좁히려면 타겟팅된 sessionMatcher 속성을 추가합니다.

      sessionMatcher: host() == 'github.com'

제한사항

TLS 검사를 구성하기 전에 다음 제한사항을 고려해야 합니다.

  • 서버는 공개 루트 인증서를 사용해야만 확인할 수 있습니다. 루트 인증 기관(CA) 집합은 Mozilla 루트 프로그램을 기반으로 합니다. 인증서 확인 동작은 변경될 수 있으며 웹브라우저에서 인증서를 확인하는 방식에 해당합니다.

    현재 백엔드 확인이 불가능하므로 비공개 또는 자체 서명된 인증서가 있는 서버로의 트래픽을 가로챌 수 없습니다.

  • 보안 웹 프록시는 인증서 해지 목록(CRL) 검사를 실행하지 않습니다.

  • TLS 검사가 작동하려면 클라이언트가 현재 서버 이름 표시(SNI)를 보내야 합니다. SNI는 선택사항인 TLS 사양 확장 프로그램이지만 대부분의 클라이언트에서 기본적으로 사용 설정합니다.

  • 클라이언트에 암호화된 클라이언트 Hello(ECH)(이전의 암호화된 SNI)가 필요한 경우 TLS 검사가 작동하지 않습니다.

    ECH는 클라이언트가 사전 설정된 서버 키를 사용하여 TLS 핸드셰이크의 시작을 암호화할 수 있게 해주는 IETF 표준 초안입니다. TLS 검사는 가로채기 프록시 역할을 하므로 사전 설정된 서버 키에 액세스할 수 없습니다. 따라서 ECH가 작동하지 않습니다.

  • 클라이언트가 비공개 루트 인증서를 신뢰하도록 구성해야 합니다.

  • 비공개 CA 풀에서 CA를 삭제하면 해당 CA에서 서명한 캐시된 인증서가 최대 28시간 동안 제공됩니다. 캐시된 인증서가 사용되지 않도록 하려면 새 CA 풀을 가리키도록 TLS 검사 정책을 업데이트하면 됩니다. 따라서 보안 웹 프록시는 새 인증서를 생성해야 합니다.