통합 SASE 역할 사이버 위협 헌팅

왜 SASE에서 프록시를 사용해야 하나요?

패킷 수준의 보안으로 충분하다고 여겨지던 시대는 지났습니다. 공격의 정교함으로 인해 다양한 종류의 보호를 위해 심층적인 콘텐츠 검사가 필수적으로 요구되고 있습니다. 분산된 인력과 분산된 애플리케이션으로 인해 ID 인식 액세스는 핵심 요구 사항입니다. 이 블로그 게시물에서는 ID 인식 액세스와 관련된 요구 사항을 자세히 살펴봅니다. API/애플리케이션 리소스 수준에서 심층 콘텐츠 검사 및 ID 인식 액세스를 수행하려면 클라이언트 연결 종료, 위협 탐지 및 액세스 제어를 위한 콘텐츠 검사, 프록시를 통한 연결 시작이 필요합니다. 따라서 많은 SASE 솔루션은 프록시를 통해 보안을 구현합니다.

프록시 유형

포워드, 리버스, 투명 등 다양한 유형의 프록시에 대해 들어보셨을 것입니다. 모든 유형의 프록시의 주요 기능은 동일합니다. 높은 수준의 기능이 여기에 나열되어 있습니다.

  • 트래픽 파악하기
  • 클라이언트 연결을 종료합니다.
  • 클라이언트를 인증합니다.
  • 사용자 ID를 가져옵니다.
  • 서버에 대한 연결을 시작합니다.
  • TLS 복호화 및 암호화
  • IP 및 도메인 평판을 확인합니다.
  • ID 기반 액세스 제어를 수행합니다.
  • CASB 기능을 수행합니다.
  • 데이터 손실을 확인하고 손실을 방지하세요.
  • 침입 탐지/방지 기능을 수행합니다.
  • 웹 애플리케이션 방화벽 기능을 수행합니다.
  • 트래픽에서 멀웨어 및 익스플로잇 지표를 찾아 조치를 취하세요.

서로 어떻게 다른지는 다음 요소를 기반으로 합니다:

  • 위협 검사 및 접속 제어를 위한 트래픽 확보
  • 사용자 인증 및 사용자 식별하기

투명 프록시 유형

이 유형에서는 클라이언트와 서버가 프록시의 존재를 알지 못합니다. 이러한 프록시는 트래픽이 통과하는 네트워크 라우터에서 트래픽을 캡처합니다. 네트워크 관리자는 사무실 사용자의 트래픽과 WFH 사용자의 트래픽이 엔터프라이즈 라우팅 엔티티를 통해 전달되도록 할 책임이 있습니다. WFH 사용자의 트래픽이 엔터프라이즈 라우터를 통과하도록 하기 위해 VPN 클라이언트를 활용하여 엔터프라이즈 네트워크에 연결하는 것이 일반적인 관행입니다. SD-WAN의 경우, VPN 터널은 가장 가까운 PoP 위치의 VPN 집중기에서 종료됩니다. 사용자 인증 및 해당 사용자 식별은 다음을 통해 이루어집니다.

  • 명시적 포털
  • 온디맨드 포털
  • VPN 터널 설정
  • TLS 클라이언트 인증서

‘명시적 포털’의 경우 사용자가 능동적으로 포털에 로그인합니다. 포털 서비스는 기업 인증 시스템의 도움을 받아 사용자를 인증합니다. 사용자 자격 증명을 성공적으로 확인하면 사용자의 IP 주소(연결의 소스 IP)를 기록하고 프록시에게 사용자 ID 및 IP 주소 매핑 정보를 알려줍니다. 프록시는 이러한 매핑을 알게 되면 트래픽의 IP 주소에서 사용자를 식별하고 ID 인식 정책 시행을 수행합니다. 사용자가 포털에 사전 인증하지 않고 세션을 시작하면 프록시는 사용자를 포털로 리디렉션할 수 있습니다. 포털 액세스는 온디맨드 방식이므로 이 인증 방법을 온디맨드 포털 인증이라고도 합니다. 한 가지 주의할 점은 사용자를 포털로 리디렉션하는 것은 연결이 HTTP/HTTPS 기반인 경우에만 가능하다는 점입니다. HTTPS의 경우, 리디렉션은 TLS 복호화 이후에만 가능합니다. 기업 소유가 아닌 서비스/사이트에 액세스하는 경우, 기업 소유의 CA 인증서로 서버 인증서를 모방해야 합니다. 또한 사용자가 브라우저를 사용하는 사람이 아닌 경우 리디렉션은 도움이 되지 않습니다. 이러한 주의 사항에도 불구하고 프록시는 여전히 사용자를 인증하고 식별할 수 있는 강력한 방법입니다. 앞서 설명한 것처럼, 기업 네트워크의 일부가 되려면 WFH(재택근무) 사용자가 VPN 터널을 통해 기업 네트워크에 연결해야 합니다. VPN 터널 설정은 이미 사용자 인증을 수행합니다. VPN 집중기는 각 클라이언트에 고유한 사설 IP 주소를 할당합니다. 클라이언트는 VPN 터널을 사용하도록 구성할 수 있으므로 대부분의 연결에서 이 IP 주소를 소스로 사용할 수 있습니다(분할 터널링 비활성화 포함). VPN 집중 업체는 클라이언트에 할당된 IP 주소, 사용자 ID(개시자 ID) 매핑을 외부 당사자에게 광고할 수 있습니다. 프록시는 이 매핑을 사용하여 나중에 클라이언트가 세션을 시작할 때 사용자에 대한 세션을 식별합니다. TLS 세션을 설정한 클라이언트 프로그램에 TLS 클라이언트 인증서가 있는 경우, 이 인증서를 사용하여 사용자를 인증하고 식별할 수 있습니다. 오늘날 SASE에서는 거의 사용되지 않지만 사용 가능한 옵션 중 하나입니다. 투명 프록시 유형의 주요 이점 중 하나는 HTTP/HTTPS뿐만 아니라 모든 프로토콜 트래픽을 캡처할 수 있다는 점입니다. 또 다른 주요 이점은 엔터프라이즈 클라이언트 머신이나 서버 머신에서 특별한 구성이 필요 없다는 점입니다. 이러한 유형의 프록시에는 몇 가지 단점이 있습니다. 트래픽에서 관찰된 IP 주소를 기반으로 사용자를 식별하기 때문에 해당 사용자 컴퓨터의 모든 애플리케이션이 동일한 보안 처리를 받습니다. 다중 사용자 컴퓨터인 경우, 해당 컴퓨터의 모든 사용자에게 동일한 보안 처리/권한이 부여됩니다. 이 IP 주소가 여러 머신을 NAT하는 경우, 해당 NAT IP 주소 뒤에 있는 모든 머신은 동일한 액세스 및 보안 처리를 받습니다. 사용자 노트북이 멀웨어에 감염된 경우를 생각해 보세요. 멀웨어는 사용자가 포털에 로그인하는 동일한 컴퓨터의 일부이므로 해당 사용자에 대해 정의된 것과 동일한 액세스 권한을 얻습니다. 따라서 투명 프록시 유형은 적어도 HTTP/HTTPS 세션에 대해서는 신중하게 사용해야 합니다. 또 다른 단점은 이러한 유형의 프록시를 사용하려면 장치에 VPN 클라이언트가 있어야 한다는 것입니다. 관리형 디바이스에서는 문제가 되지 않지만, 직원 소유 디바이스에 VPN 클라이언트를 설치하도록 직원을 설득하는 것은 어려울 수 있습니다.

정방향 프록시 유형

정방향 프록시는 외부 서비스/사이트와 통신하는 클라이언트 디바이스를 위한 것입니다. 클라이언트 애플리케이션은 외부 서비스와 통신하기 위해 정방향 프록시를 통해 이동하도록 구성됩니다. 클라이언트 애플리케이션은 프록시 FQDN/IP 및 프록시가 수신 대기 중인 포트로 구성됩니다. 투명 프록시의 경우 세션의 소스 및 대상 IP 주소에는 프록시 IP 주소가 없습니다. 정방향 프록시의 경우 클라이언트의 연결은 프록시 IP 주소로, 서버로의 연결은 프록시 IP 주소에서 이루어집니다. PAC 파일은 프록시 설정이 있는 브라우저 등의 클라이언트 애플리케이션을 구성하는 데 사용됩니다. PAC 파일을 사용하면 대상 서비스 도메인에 따라 다양한 프록시로 트래픽 라우팅을 선택할 수 있습니다. PAC 파일은 시스템 관리 솔루션 또는 WPAD(웹 프록시 자동 검색) 서비스를 통해 클라이언트 브라우저에 배포됩니다. 프록시 설정이 있는 클라이언트 애플리케이션은 항상 프록시와 통신합니다. 이것이 바로 포워드 프록시가 트래픽을 캡처하는 방식입니다. HTTPS와 같은 TLS 연결의 경우, 모든 TCP 연결은 “HTTP CONNECT” 트랜잭션으로 시작됩니다. 이 트랜잭션은 클라이언트와 프록시 간에만 이루어집니다. HTTP CONNECT 트랜잭션 이후 클라이언트와 서버 간의 데이터는 프록시에 의해 중개됩니다. “HTTP CONNECT” 트랜잭션에는 프록시가 최종 대상 FQDN과 포트를 결정하는 데 사용하는 값이 있는 호스트 헤더 필드가 있습니다. HTTP2.0의 경우, 모든 스트림 연결은 “HTTP CONNECT” 트랜잭션으로 시작됩니다. 이미 보셨겠지만 프록시가 트래픽을 캡처하기 위해 엔터프라이즈 라우터로 트래픽을 전송할 필요가 없습니다. 즉, 트래픽이 프록시로 직접 이동합니다. 이러한 방식으로 네트워크에 구애받지 않습니다. 또한 포워드 프록시는 프록시 인증 및 프록시 권한 부여 헤더를 통해 사용자를 인증하고 식별할 수 있습니다. TLS 연결의 경우, 이러한 헤더는 HTTP CONNECT 트랜잭션에서 응답과 요청으로 각각 전송됩니다. 한 가지 주의할 점은 사용자 인증 및 식별을 위해 TLS 연결을 복호화할 필요가 없다는 것입니다. 포털 인증이 필요하지 않습니다. 한 가지 추가적인 이점이 있다면 많은 브라우저와 클라이언트 애플리케이션이 프록시 인증의 일부로 Kerberos를 지원한다는 점입니다. 이를 통해 디바이스에 로그인하는 모든 사용자는 추가 로그인 팝업 없이 프록시를 통해 자동으로 자신을 인증할 수 있습니다(SSO라고도 함). 외부 서비스와 통신하는 클라이언트에 정방향 프록시 유형을 사용하면 몇 가지 장점이 있습니다. 그 중 일부는 아래에 나열되어 있습니다.

  • 사용자 인증 및 식별은 결정론적입니다. 투명 프록시 유형의 경우, 사용자가 포털에 대한 사전 인증을 잊어버린 경우 사용자 인증을 위한 온디맨드 포털 또는 캡티브 포털 리디렉션은 TLS 복호화 후에만 가능합니다. 일부 기업에서는 PII를 수집하는 사이트에 대한 TLS 암호 해독을 허용하지 않습니다. 사이트에서 인증서 고정을 채택하는 경우 투명 프록시는 인증서를 모방하지 않을 것으로 예상되므로 TLS 암호 해독이 불가능합니다. 이러한 경우 사용자는 신원 인식 정책 시행을 제공할 수 없습니다. 포워드 프록시 유형에서는 프록시 인증 단계가 TLS 교환 전에 발생하므로 사용자 인증 및 식별이 결정론적입니다.
  • 앞서 설명한 것처럼 정방향 프록시는 네트워크에 구애받지 않으며 클라이언트 애플리케이션이 프록시 설정으로 구성되어 있는 한 모든 네트워크에서 작동할 수 있습니다. 사용자가 재택 근무를 하는 경우에도 장치에 VPN 클라이언트가 있을 필요가 없습니다.
  • 많은 클라이언트 애플리케이션이 Kerberos를 지원하므로 사용자는 SSO 환경을 이용할 수 있습니다.
  • TLS 1.3+의 암호화된 클라이언트 헬로우(ECH)가 업계에서 주목을 받고 있습니다. ECH를 채택하면 SNI가 보이지 않으므로 투명 프록시 유형은 기본적인 URL 필터링 및 접근 제어조차 할 수 없습니다. 포워드 프록시 유형에서는 HTTP CONNECT 트랜잭션으로 인해 프록시는 ECH를 채택하더라도 목적지 FQDN을 알고 있습니다. 즉, 순방향 프록시 유형은 ECH 안전합니다.
  • IP 화이트리스트는 없습니다. 모든 클라이언트 애플리케이션은 프록시를 통해 개별적으로 인증해야 하므로 매우 안전합니다.

단점도 거의 없습니다. HTTP/HTTPS 트래픽에 대해서만 작동합니다. 대부분의 클라이언트 애플리케이션이 프록시 설정을 지원하지만 일부 애플리케이션은 지원하지 않습니다.

역방향 프록시 유형

역방향 프록시는 서버 애플리케이션을 프런트엔드하는 데 사용됩니다. 역방향 프록시는 위협으로부터 서비스를 보호하고, RBAC를 제공하고, TLS 세션을 종료하고, 여러 서비스 인스턴스 간에 트래픽 세션의 부하를 분산하는 데 사용됩니다. DNS 방법을 통해 역방향 프록시 트래픽을 캡처합니다. 직원 또는 일반 사용자에게 노출되는 각 엔터프라이즈 서비스의 FQDN은 역방향 프록시 인스턴스의 IP 주소를 가리키도록 엔터프라이즈 DNS 서버에서 구성됩니다. 이로 인해 사용자가 엔터프라이즈 서비스에 연결을 시도할 때마다 해당 트래픽이 역방향 프록시로 이동합니다. 역방향 프록시는 HTTPS/HTTP 세션도 종료합니다. 이 프로세스의 일부로 사용자를 인증한 다음 OIDC, SAMLv2 및 SPENGO/Kerberos 방법을 통해 세션의 사용자를 식별합니다. 앱 간 통신의 경우, TLS 인증서에서도 사용자를 식별합니다.

SASE 프록시

SASE에 대한 입문서는 SASE 해독하기 블로그 포스팅을 참조하세요. 아시다시피, SASE 솔루션은 클라이언트 보안, SaaS 데이터 보안, 엔터프라이즈 애플리케이션 보안 등 포괄적인 보안을 제공할 것으로 기대됩니다. 신원 인식-SASE 블로그 게시물에 설명된 대로 신원 기반 액세스 제어는 SASE의 핵심 기능입니다. 많은 기업이 HTTP/HTTPS 액세스만으로 운영할 수 있지만, 일부 기업에서는 다른 프로토콜에 대한 액세스 제어도 필요할 수 있습니다. 이러한 요구 사항으로 인해 SASE 프록시는 비 HTTP 트래픽과 프록시 설정을 지원하지 않는 클라이언트 애플리케이션에 대해 투명하게 작동해야 한다고 생각합니다. SASE 프록시는 인터넷 및 SaaS 서비스에 액세스하는 클라이언트 애플리케이션에 대한 정방향 프록시 역할을 수행하여 결정론적 신원 기반 액세스 제어를 제공하고 ECH가 채택될 때 미래에도 대비합니다. SASE 프록시는 엔터프라이즈 애플리케이션을 보호하기 위한 역방향 프록시 역할도 수행합니다. 성공적인 SASE 솔루션을 위해서는 이러한 여러 프록시 유형의 융합이 필요합니다.

  • CTO 인사이트 블로그

    아리아카 CTO 인사이트 블로그 시리즈는 네트워크, 보안 및 SASE 주제에 대한 사고 리더십을 제공합니다.
    아리아카 제품 사양은 아리아카 데이터시트를 참조하세요.