cloudflare-gateway

Cloudflare는 MCP 트래픽을 어떻게 탐지하고 보안을 강화하는가 (새 탭에서 열림)

AI 에이전트는 기존 사용자보다 훨씬 빠르고 반복적으로 도구를 호출할 수 있어, 한 번의 잘못된 판단이 대규모 권한 오용으로 확산될 수 있다. MCP는 에이전트가 SaaS, 내부 애플리케이션, API의 도구를 호출하게 해주지만, 승인되지 않은 서버로 직접 연결하는 ‘Shadow MCP’가 일반 HTTPS 트래픽처럼 보일 수 있다는 문제가 있다. 따라서 클라이언트·네트워크·MCP 서버의 각 지점에서 호출을 식별하고, 검사하며, 실행 전 차단하는 다층 통제가 필요하다. ## AI 에이전트가 기존 권한 모델을 바꾸는 이유 - 기존 권한 체계는 사용자가 판단하고, 사람의 속도로만 작업한다는 가정에 기반했다. - AI 에이전트는 판단이 비결정적이며, 같은 도구를 피로 없이 반복 호출할 수 있다. - 잘못된 판단 하나가 사람이 알아차리기 전에 수천 건의 잘못된 작업으로 확대될 수 있다. - 에이전트 연결은 한 줄의 설정만으로 가능해, 직원이 승인 여부를 확인하지 않고 MCP 서버를 사용할 위험이 있다. ## MCP 도구 호출의 구조와 보안 신호 MCP 호출은 시스템의 위치에 따라 세 가지 형태로 나타난다. - 클라이언트 내부에서는 특정 도구와 인자를 호출하기로 한 에이전트의 결정이다. - 네트워크에서는 JSON-RPC 메시지를 담은 HTTP 요청이다. - 서버에서는 실제 도구 핸들러를 실행하는 작업으로 변환된다. - 요청에는 다음과 같은 식별 정보가 포함된다. - `Host`, 경로: 대상 서버 식별 - `Authorization`: 호출자 인증 정보 - `MCP-Protocol-Version`: MCP 프로토콜 버전 - `Mcp-Method`: 수행할 작업 - `Mcp-Name`: 호출할 도구 이름 - `id`: 요청과 응답을 연결하는 식별자 - `params`: 도구 인자 - 특히 `params`에는 검색어, 소스 코드, 고객 데이터, 티켓 생성이나 인프라 변경 지시가 포함될 수 있어 가장 민감하다. - 응답에도 도구가 반환한 민감한 데이터가 포함될 수 있으므로 요청뿐 아니라 응답 검사와 로깅도 중요하다. - MCP는 특정 호스트명이나 `/mcp` 경로를 반드시 요구하지 않기 때문에, 승인되지 않은 직접 연결이 일반 HTTPS API 호출처럼 보일 수 있다. ## 클라이언트 내부 통제 - 모델이 도구를 선택한 뒤 실제 요청으로 직렬화하기 전에 서버, 도구 이름, 인자를 검사할 수 있다. - 승인 목록에 없는 서버를 차단할 수 있다. - 민감한 작업에 사용자 확인을 요구할 수 있다. - 요청이 기기를 떠나기 전에 인자에서 민감한 데이터를 제거할 수 있다. - 네트워크를 사용하지 않는 로컬 `stdio` MCP 서버도 통제할 수 있다. - 단점은 사용하는 모든 MCP 클라이언트마다 통제를 별도로 구현해야 한다는 점이다. - 조직이 클라이언트와 기기를 모두 관리할 때 효과적이지만, 단일 클라이언트의 telemetry만으로는 전체 MCP 사용 현황을 파악할 수 없다. ## 네트워크 경계에서의 탐지와 차단 - 보안 웹 게이트웨이는 요청이 클라이언트를 떠난 뒤 HTTP 트래픽을 관찰한다. - TLS 복호화를 적용하면 사용자와 기기, 대상 서버, MCP 관련 헤더를 함께 식별할 수 있다. - 특정 MCP 클라이언트에 의존하지 않고 관리되는 네트워크 경로의 원격 MCP 트래픽을 폭넓게 탐지할 수 있다. - 승인된 MCP Portal을 거치지 않는 직접 연결을 목적지에 도달하기 전에 차단할 수 있다. - DLP 기능을 사용하면 JSON-RPC 메서드와 인자를 검사해 민감한 데이터 전송을 차단하거나 기록할 수 있다. - 다만 로컬 `stdio` 호출이나 조직 네트워크 밖에서 발생한 트래픽은 볼 수 없다. ## MCP 서버에서의 실행 전 통제 - MCP 서버는 호출자를 인증하고, 메시지를 해석하며, 도구와 인자를 검증한 뒤 실행하는 가장 풍부한 실행 컨텍스트를 가진다. - 도구 핸들러가 실행되기 전에 다음 정책을 적용할 수 있다. - 호출자별 도구 권한 확인 - 호출 횟수 제한 - 인자 검사 - 실행 결과와 승인 여부 기록 - 읽기 작업은 허용하되, 쓰기 작업에는 에이전트 식별 정보와 감사 이벤트를 추가할 수 있다. - 중요 작업은 핸들러 실행 전에 차단해야 하며, 실행 후 로그만 남기는 방식으로는 피해를 예방할 수 없다. - Cloudflare의 WriteGuard는 도구별 위험 등급과 활성화 상태를 사용해 읽기·쓰기·중요 작업을 차등 처리한다. - 서버 측 통제는 사용자가 클라이언트를 바꾸거나 로컬 훅을 비활성화해도 우회하기 어렵다. - 단, 해당 통제를 구현한 MCP 서버만 보호할 수 있다는 한계가 있다. ## Cloudflare One과 MCP Portal의 역할 - Cloudflare One은 검사된 MCP 트래픽을 식별하고, 어떤 사용자와 서버가 생성했는지 보여주는 기능을 제공한다. - 관리 네트워크 경로에서 직접 연결을 통제해 승인된 MCP Portal 경로만 사용하도록 강제할 수 있다. - 이를 통해 관리자는 에이전트가 승인된 경로를 이용하는지, 아니면 MCP Portal을 우회해 서버에 직접 연결하는지 확인할 수 있다. - 네트워크 계층은 가장 넓은 범위의 원격 MCP 연결을 감시하고, 클라이언트와 서버 계층은 요청 내용과 실행 맥락을 더 깊이 통제한다. ## 실용적인 권장 방식 MCP 보안은 한 지점에 의존하기보다 다층으로 구성하는 것이 적절하다. 클라이언트에서는 민감한 요청을 사전 확인하고, 네트워크에서는 Shadow MCP와 Portal 우회 연결을 탐지·차단하며, 서버에서는 도구별 권한·위험 등급·속도 제한을 적용해야 한다. 특히 데이터 변경이나 외부 시스템 조작을 수행하는 도구는 반드시 서버에서 실행 전에 검증하고 감사 로그를 남겨야 한다.

Cloudflare 내부 DNS 정식 출시 (새 탭에서 열림)

Cloudflare Internal DNS는 퍼블릭 DNS와 프라이빗 DNS를 하나의 글로벌 플랫폼과 제어 평면에서 통합하는 서비스다. 이를 통해 스플릿-호라이즌 DNS의 동기화 문제를 줄이고, Zero Trust 정책·감사·가시성을 DNS에도 적용할 수 있다. Cloudflare Gateway를 사용하는 Enterprise 고객은 추가 비용 없이 사용할 수 있으며, 기존 DNS 어플라이언스와 클라우드별 DNS를 대체하는 것을 목표로 한다. ## 기존 내부 DNS 운영의 한계 - 퍼블릭 DNS, 사설 DNS, 클라우드별 DNS가 서로 다른 플랫폼에서 운영되는 경우가 많다. - 시스템마다 보안 정책과 관리 방식이 달라 전체 DNS 구성을 한눈에 파악하기 어렵다. - 스플릿-호라이즌 DNS에서는 같은 호스트명에 대해 내부 사용자와 외부 사용자에게 서로 다른 응답을 제공해야 한다. - 여러 DNS 환경의 레코드를 별도로 관리하면 설정이 서로 어긋나는 드리프트가 발생하고, 장애로 이어질 수 있다. - 레거시 DNS 장비는 하드웨어 교체 주기, 용량 확장, 유지보수 부담을 발생시킨다. ## Cloudflare Internal DNS의 핵심 가치 - 퍼블릭·프라이빗 DNS를 하나의 API, 감사 로그, 정책 관리 체계로 통합한다. - 공유된 존에 여러 DNS 뷰를 적용해 스플릿-호라이즌 DNS를 중복 구성 없이 구현한다. - Cloudflare Gateway의 사용자·기기 기반 정책으로 어떤 DNS 뷰를 사용할지 제어한다. - DNS 질의 필터링, 라우팅, 로깅을 기존 Zero Trust 정책과 동일한 체계로 관리한다. - 1.1.1.1을 운영하는 글로벌 인프라를 활용하므로 별도 장비 설치나 용량 사전 확보가 필요 없다. ## 두 가지 핵심 구성 요소 - **Gateway Resolver** - DNS 재귀 조회와 정책 평가를 담당한다. - 질의를 차단하거나 특정 업스트림으로 전달할 수 있다. - 유연한 조건식, 로깅, 감사 기능을 제공한다. - 정책에 따라 내부 DNS 뷰 또는 퍼블릭 DNS 경로를 선택한다. - **Internal Authoritative DNS** - 프라이빗 리소스의 권한 있는 DNS 레코드를 제공한다. - 애플리케이션, 서비스 엔드포인트, 데이터베이스 등의 내부 존을 관리한다. - Cloudflare의 기존 권한 있는 DNS 플랫폼 위에서 동작한다. ## 주요 객체: 존, 뷰, 리졸버 정책 - **Internal Zone** - 내부 리소스의 권한 있는 레코드를 저장한다. - 예: `corp.internal`, `db.corp.internal`. - **DNS View** - 특정 사용자·기기 그룹이 볼 수 있는 존과 레코드의 해석 맥락을 정의한다. - 내부 사용자에게는 사설 주소를, 외부 사용자에게는 퍼블릭 주소를 제공하는 데 사용된다. - **Resolver Policy** - Gateway에서 질의를 평가하고 특정 DNS View로 전달한다. - 조건에 따라 질의를 허용, 차단하거나 퍼블릭 DNS로 보낼 수 있다. - **Zone Reference** - 하나의 공유 존을 여러 뷰에서 재사용한다. - 동일한 레코드를 뷰마다 복사하지 않으므로 중복과 설정 불일치를 방지한다. ## DNS 질의 처리 과정 - 클라이언트의 질의는 먼저 Gateway Resolver에 도착한다. - 리졸버 정책이 내부 뷰를 지정하면 해당 질의는 Internal Authoritative DNS로 전달된다. - 정책이 질의를 차단하면 응답 없이 삭제된다. - 일치하는 정책이 없으면 1.1.1.1을 통해 퍼블릭 DNS 계층에서 조회한다. - 내부 뷰에서 이름을 찾지 못할 경우 퍼블릭 DNS로 폴백하도록 구성할 수 있어, 클라이언트는 내부·외부 이름을 구분할 필요가 없다. ## DNS 변경 사항의 전파 - 대시보드, Terraform, 직접 API 호출 등 모든 변경은 동일한 DNS Records API를 거친다. - 하나의 쓰기 경로를 사용하므로 변경 이력과 감사를 일관되게 관리할 수 있다. - 변경 내용은 Cloudflare 핵심 데이터센터에 저장되고 검증된 뒤 글로벌 네트워크로 복제된다. - 관련 캐시가 무효화되므로 TTL 만료를 기다리지 않고 수 초 내에 변경 사항이 반영된다. - Terraform 변경도 대시보드나 API 변경과 동일한 전파 경로를 따른다. ## 설정 방법 - Cloudflare 대시보드의 **Networking → Internal DNS**에서 시작한다. - 일반적인 구성 순서는 다음과 같다. 1. 내부 존 생성 2. 내부 DNS 레코드 생성 3. DNS View 생성 후 존 연결 4. Gateway Resolver Policy를 만들어 특정 트래픽을 해당 뷰로 라우팅 - 예시로 `corp.internal` 존을 만들고 `db.corp.internal`을 `10.0.1.50`으로 지정할 수 있다. - Cloudflare API와 Terraform을 모두 사용할 수 있다. - 현재 Cloudflare Gateway를 사용하는 Enterprise 고객이 이용 대상이다. ## Connectivity Cloud와의 통합 - 다음과 같은 DNS 연결 방식과 함께 사용할 수 있다. - Cloudflare One Client(WARP) - DNS over HTTPS(DoH) - DNS over TLS(DoT) - 표준 DNS 53번 포트 - PAC 파일 배포 - Cloudflare WAN - Cloudflare WAN을 사용하면 개별 단말에 One Client를 설치하지 않아도 연결된 네트워크의 장치가 내부 호스트명을 조회할 수 있다. - 원격 사용자, 지사, 데이터센터, 클라우드 환경을 하나의 제어 평면으로 연결해 일관된 DNS 경험을 제공한다. - Internal DNS는 독립적인 DNS 제품이라기보다 Zero Trust와 네트워크 연결을 포함한 Cloudflare Connectivity Cloud의 기능 확장이다. 내부·외부 DNS를 여러 시스템에서 따로 운영하고 있다면, 공유 존과 DNS View를 중심으로 구성을 통합하는 것이 유용하다. 특히 Cloudflare Gateway와 WAN을 이미 사용 중인 조직은 별도 DNS 장비를 줄이고, 정책·감사·전파 경로를 단일화하는 방안을 검토할 만하다.

Cloudflare CASB를 통한 Claude Compliance API 지원 발표 (새 탭에서 열림)

Cloudflare가 Claude Compliance API를 CASB에 통합해, 보안·컴플라이언스 팀이 엔드포인트 에이전트 없이 Claude 사용 현황과 민감정보 노출을 Cloudflare 대시보드에서 모니터링할 수 있게 했다. 이를 통해 Claude의 프로젝트, 파일, 대화, 생성 문서에서 발생하는 보안 문제를 탐지하고, 기존 SaaS 보안 워크플로와 Cloudflare Gateway 정책을 이용해 차단·제한까지 연결할 수 있다. 핵심은 AI 애플리케이션의 사용 데이터를 단순히 차단하는 데서 나아가, 데이터 생성·처리·저장 전 과정을 관리하는 것이다. ## AI 도입에 따른 새로운 보안 과제 - 기존 SaaS와 달리 AI 서비스에서는 사용자가: - 고객 개인정보나 기밀자료를 프롬프트에 입력할 수 있다. - API 키를 실수로 공유하고 장기간 교체하지 않을 수 있다. - 민감정보가 포함된 응답이나 문서를 생성할 수 있다. - 네트워크 계층에서 승인되지 않은 AI 서비스 사용을 차단하는 것만으로는 승인된 서비스 내부의 활동을 파악할 수 없다. - AI 애플리케이션은 데이터를 읽는 것뿐 아니라 생성하고, 여러 시스템과 연결하며, 에이전트나 API를 통해 업무를 수행한다. - 따라서 보안은 API 호출, 데이터 처리, 저장 데이터까지 전체 라이프사이클을 다뤄야 한다. ## Cloudflare의 AI 보안 구성 - **Cloudflare AI Gateway** - 애플리케이션과 Anthropic 같은 AI 제공업체 사이에 위치한다. - 요청, 토큰 사용량, 모델 성능을 관찰한다. - 속도 제한, 응답 캐싱, 세밀한 모델 라우팅을 지원한다. - **Cloudflare Gateway 및 DLP** - AI 트래픽을 검사한다. - 고객 개인정보나 기밀자료가 포함된 프롬프트가 모델에 전달되기 전에 차단할 수 있다. - **Cloudflare Access 및 MCP 서버 포털** - 에이전트가 기업 도구에 연결하는 경로를 보호된 단일 엔드포인트로 통합한다. - 사용자·에이전트별 접근 권한을 제어하고 모든 요청을 감사 로그로 남긴다. - **Cloudflare CASB** - Claude 내부에 저장된 데이터를 검사한다. - 잘못된 공유 설정과 민감정보를 탐지하며 엔드포인트 에이전트를 요구하지 않는다. - 각 기능은 Cloudflare 플랫폼 안에서 연동되므로 여러 보안 서비스나 클라우드 사이를 트래픽이 우회하는 ‘헤어핀’ 구조를 피할 수 있다. ## Claude Compliance API와 CASB 통합 - Claude Compliance API는 Claude 조직, 워크스페이스, 사용량에 관한 보안 관련 데이터를 프로그래밍 방식으로 제공한다. - Cloudflare CASB는 이 API를 사용해 인라인 트래픽 검사나 단말 에이전트 없이 Claude의 보안 문제를 탐지한다. - 탐지 결과는 다른 SaaS 애플리케이션의 보안 결과와 함께 Cloudflare 대시보드에 표시된다. - 결과는 카테고리별로 묶이고 심각도순으로 정렬된다. - 보안팀은 Microsoft 365, Google Workspace, Salesforce와 동일한 방식으로 이슈를 분류하고 담당자를 지정하며 해결할 수 있다. ## 탐지 가능한 Claude 자산과 위험 - **프로젝트** - 조직 전체 또는 특정 사용자·그룹에 공유된 프로젝트를 탐지한다. - **프로젝트 첨부파일** - DLP 정책을 위반하는 파일과 문서를 식별한다. - **채팅 파일** - 사용자가 업로드한 파일과 Claude가 생성한 파일을 검사한다. - **채팅 메시지** - 사용자의 프롬프트와 제공자의 응답에 포함된 민감정보를 탐지한다. - **Artifacts** - Claude가 생성한 문서와 파일의 DLP 정책 위반 여부를 확인한다. ## Claude Enterprise와 Claude Platform 지원 범위 - Claude Enterprise에서는 다음 정보를 확인할 수 있다. - 조직 - 프로젝트 - 채팅 - 역할 - 대화 메시지 - 업로드된 파일 - 대화와 파일은 전용 읽기 전용 엔드포인트를 통해 조회해 데이터 손실 위험을 줄인다. - Claude Platform에서는 다음 이벤트를 계속 제공한다. - 멤버 및 워크스페이스 변경 - API 키 생성 - 파일 생성 및 다운로드 - Activity Feed 지원도 향후 추가될 예정이다. ## 탐지에서 정책 시행까지 - CASB가 민감정보가 포함된 파일 업로드 같은 문제를 발견하면, 해당 결과를 Cloudflare Gateway 정책으로 연결할 수 있다. - 보안팀은 다음과 같은 조치를 취할 수 있다. - 특정 사용자의 Claude 파일 업로드 차단 - Claude 애플리케이션 전체 접근 제한 - 문제가 해결될 때까지 특정 기능만 제한 - 이를 통해 CASB의 사후 가시성을 Gateway의 실시간 인라인 정책 집행으로 확장한다. ## 시작을 위한 조건 - Claude Enterprise 계정이 필요하다. - 조직에 대해 Claude의 Compliance API 접근 권한을 요청해야 한다. - 이후 Cloudflare CASB에서 해당 API 통합을 구성해 Claude 관련 보안 결과를 대시보드에서 확인하는 방식이다. 실무적으로는 Claude 사용을 일괄 차단하기보다, CASB로 민감정보와 과도한 공유를 먼저 식별한 뒤 사용자·그룹·기능별 Gateway 정책으로 단계적으로 제한하는 접근이 적합하다.