cloudflare2026년 8월 10일

가장 중요한 임무를 지원하는 Cloudflare for Government, FedRAMP Class D(High) 인증 획득 (새 탭에서 열림)

Cloudflare는 공공기관용 서비스인 Cloudflare for Government에서 FedRAMP Class D(High) 인증을 획득했다고 발표했습니다. 이는 미국 정부의 가장 민감한 비기밀 데이터를 처리할 수 있는 높은 수준의 보안·감사·지속적 모니터링 요건을 충족했다는 의미입니다. 또한 이 인증에 사용한 시스템을 기반으로 미 국방부 DoD Impact Level 4(IL4) 승인도 추진하며, 별도 정부용 클라우드가 아닌 글로벌 단일 플랫폼에서 빠른 혁신과 강력한 보안을 제공하겠다는 전략을 강조했습니다. ### FedRAMP High 인증의 의미 - FedRAMP는 미국 연방정부 클라우드 서비스의 보안 평가, 승인, 지속적 모니터링을 표준화한 프로그램입니다. - ‘인증’은 단순한 자체 보안 선언이 아니라 다음 절차를 거친 공식 승인입니다. - 연방기관의 역량 검증 - 후원 기관의 전체 승인 절차 진행 - FedRAMP Program Management Office의 승인 확인 - Cloudflare는 2022년 FedRAMP Moderate 승인을 받았으며, 이번에는 더 높은 수준인 Class D(High)를 획득했습니다. - Moderate는 시스템 침해가 심각한 피해를 일으킬 수 있는 환경에 적용되지만, High는 다음과 같은 국가 핵심 데이터에 적용됩니다. - 법 집행 및 긴급 서비스 데이터 - 금융 시스템 정보 - 국가 안보 관련 데이터 - High 수준에서 보안 통제가 침해되면 인명 피해, 경제적 손실, 국가 안보 위협으로 이어질 수 있어 요구사항과 책임 수준이 크게 높아집니다. ### 분리된 정부용 클라우드의 한계 - 기존 기술 기업들은 공공 부문과 국방 부문을 위해 상용 플랫폼과 분리된 독립 환경을 구축하는 경우가 많았습니다. - 이런 방식은 보안과 규정 준수에는 유리할 수 있지만 다음 문제가 발생했습니다. - 상용 서비스와 정부용 서비스 사이에 기능 격차 발생 - 정부 환경이 최신 기술 적용에서 수년씩 뒤처짐 - 기관이 최신 기능과 엄격한 규정 준수 중 하나를 선택해야 함 - Cloudflare는 정부용 제품을 축소된 별도 플랫폼으로 만들지 않고, 상용 서비스와 동일한 글로벌 네트워크를 기반으로 구축했습니다. ### 하나의 글로벌 네트워크와 소프트웨어 정의 지역성 - Cloudflare는 전 세계 데이터센터에서 동일한 소프트웨어 스택과 서비스를 운영합니다. - FedRAMP High 서비스도 별도 장비나 고립된 네트워크가 아니라 동일한 인프라 위에서 동작합니다. - 핵심 기술은 Data Localization Suite입니다. - 데이터가 어디에서 처리되고 저장되는지 소프트웨어로 세밀하게 제어 - FedRAMP High 환경에서는 트래픽 검사와 처리를 미국 내 데이터센터로만 제한 - 글로벌 네트워크의 확장성과 미국 내 데이터 residency 및 처리 요건을 동시에 충족 - 따라서 연방기관은 기능이 제한된 정부용 버전이 아니라 다음과 같은 최신 기능을 사용할 수 있습니다. - Zero Trust 보안 도구 - 애플리케이션 성능 최적화 - 최신 개발자 플랫폼 기능 - 글로벌 네트워크 기반의 안정성과 확장성 ### DoD IL4 추진과 국방 분야의 혁신 속도 - Cloudflare는 FedRAMP High를 위해 설계한 시스템을 DoD Impact Level 4 승인 기반으로 활용할 계획입니다. - DoD IL4는 통제된 비기밀 정보(Controlled Unclassified Information)를 처리하기 위한 미 국방부의 사이버보안 기준입니다. - 동일한 시스템을 활용하면 국방용 환경을 별도로 구축할 필요가 줄어들고, FedRAMP High와 IL4 요구사항에 대응하는 보안 체계를 재사용할 수 있습니다. - 이를 통해 국방기관이 격리된 정부 클라우드의 느린 배포 주기에 묶이지 않고, 새로운 사이버 위협에 더 빠르게 대응할 수 있다는 것이 Cloudflare의 주장입니다. ### 공공 부문 현대화 전략 - Cloudflare는 이번 인증을 규정 준수 달성 이상의 의미로 설명합니다. - 공공기관이 다음과 같은 현대적 보안·서비스 운영 방식을 도입하도록 지원하는 것이 목표입니다. - Zero Trust 아키텍처 전환 - 정교한 DDoS 공격 방어 - 더 빠르고 복원력 높은 디지털 서비스 제공 - 국가 핵심 애플리케이션의 보안 강화 - 미국 국무부와 상무부 등 기존 연방기관과의 협력도 이번 인증을 계기로 확대할 계획입니다. 실무적으로는 FedRAMP High가 필요한 기관이라면 Cloudflare의 미국 내 데이터 처리 통제, 동일 플랫폼 기반의 최신 기능 제공 여부, 그리고 향후 DoD IL4 승인 진행 상황을 함께 확인하는 것이 적절합니다.

zero-trustcloudflarecloud-securityfedramp+3

cloudflare2026년 8월 5일

Cloudflare, 2026년 SASE 및 SSE 보고서에서 비저너리로 선정된 유일한 벤더 (새 탭에서 열림)

Cloudflare는 2026년 Gartner SASE 및 SSE 매직 쿼드런트에서 모두 비저너리로 선정된 유일한 기업이라고 발표하며, 이를 통합형 아키텍처와 고객 신뢰의 결과로 설명한다. 글은 AI 에이전트, 양자 컴퓨팅, 섀도 앱 확산에 대응하려면 기존 제품을 조합한 SASE가 아니라 민첩하고 프로그래밍 가능한 통합 보안·접속 플랫폼이 필요하다고 주장한다. Cloudflare One은 단일 글로벌 네트워크와 통합 정책 체계를 기반으로 AI 보안, 제로 트러스트, DLP, 포스트퀀텀 암호화를 하나의 플랫폼에서 제공하는 방향을 제시한다. ## SASE와 SSE 시장의 변화 - SSE는 팬데믹 시기 원격 근무 보안을 위한 “SASE의 보안 영역”으로 먼저 확산됐다. - 최근에는 사무실 복귀, AI 에이전트, 섀도 앱, 포스트퀀텀 위협으로 인해 네트워크 연결과 보안을 함께 관리하는 SASE의 중요성이 커지고 있다. - 기업은 과거 아키텍처에 묶인 제품보다 변화 속도에 맞춰 정책과 보호 기능을 확장할 수 있는 플랫폼을 필요로 한다. ## 기존 SASE의 구조적 한계 - **분산된 아키텍처** - 인수합병으로 여러 제품을 결합한 플랫폼은 배포와 정책 관리가 복잡하다. - 사용 사례마다 서로 다른 제품과 엔진을 운영해야 해 보안 공백과 구현 지연이 발생한다. - Cloudflare는 하나의 글로벌 네트워크로 사용자, AI 에이전트, 인프라를 연결하고 보호하는 “connectivity cloud” 접근을 내세운다. - **관리되지 않는 AI 에이전트** - 기존 보안 제품은 사람의 생성형 AI 프롬프트에 집중했지만, AI 에이전트와 MCP 서버의 확산은 충분히 통제하지 못했다. - Cloudflare는 사람과 AI 에이전트를 함께 가시화하고 MCP 서버 사용을 정책으로 관리한다고 설명한다. - AI Gateway와 연동해 사용자·팀·애플리케이션별 추론 비용을 제한할 수 있어 예기치 않은 AI 사용료를 줄일 수 있다. - **이론에 머문 포스트퀀텀 보안** - 포스트퀀텀 암호화를 향후 과제로만 다루는 대신, 주요 온·오프램프에 실제 적용해 “지금 수집하고 나중에 복호화”하는 공격에 대응한다고 주장한다. - 규제 산업은 장기간 보관되는 암호화 데이터를 현재 시점부터 보호해야 한다. - **복잡한 추가 과금** - 기존 업체는 고급 기능을 별도 애드온으로 판매하거나 원격 근무와 사무실 사용에 중복 과금하는 경우가 있다. - Cloudflare는 숨은 비용 없이 예측 가능한 통합 번들을 제공하는 것을 차별점으로 제시한다. ## SASE를 변화시키는 네 가지 기술 압력 - **AI로 만든 내부 앱과 섀도 IT** - 직원이 IT 승인 없이 내부 도구를 빠르게 만드는 “vibe-coded” 앱이 늘어나고 있다. - SASE는 이런 앱에 제로 트러스트 접근 제어, WAF, API 보호, DLP를 자동 적용해야 한다. - AI 프롬프트와 민감 데이터도 보호하면서 개발 속도는 유지해야 한다. - **AI 에이전트 권한 통제** - 사람의 광범위한 권한을 AI 에이전트가 그대로 상속해서는 안 된다. - 에이전트 작업별로 최소 권한의 자격 증명을 발급하고, 의도와 도구 호출량을 분석해 이상 행동을 감지해야 한다. - **포스트퀀텀 민첩성** - 양자 컴퓨팅 발전에 대비해 NIST 표준이 확정되기 전부터 암호화 체계를 교체할 수 있어야 한다. - Cloudflare는 2028년까지 포스트퀀텀 인증을 포함한 완전한 양자 보안 SASE를 제공하겠다는 목표를 제시한다. - **실질적인 아키텍처 통합** - 단순히 여러 제품을 “플랫폼”으로 묶는 것만으로는 통합이 이뤄지지 않는다. - 진정한 통합에는 단일 코드베이스와 통합된 제어·데이터·인프라 플레인이 필요하다. - AI 시대에는 구성 가능성과 프로그래밍 가능성이 실제 아키텍처에 내장되어야 한다. ## Cloudflare의 통합 아키텍처 - Cloudflare는 서로 다른 보안 제품을 조합하는 대신 처음부터 단일 플랫폼으로 구축했다고 설명한다. - 모든 서비스가 글로벌 네트워크의 각 서버에서 실행되므로 특정 보안 장비 간 트래픽을 우회시키는 ‘tromboning’이 줄어든다. - 제품별 용량 계획, 분리된 정책, 복잡한 통합 작업이 필요 없어 새로운 사용 사례를 수개월이 아니라 수일 또는 수주 내 배포할 수 있다는 주장이다. - 제로 트러스트, Gateway, DLP, 신규 사무실 연결 등을 동일한 운영 체계에서 확장할 수 있다. ## AI 도입을 빠르게 보호하는 방식 - AI 보안을 별도 모듈로 추가하지 않고 기존 SASE 정책 언어에 통합한다. - 관리자는 사람의 AI 프롬프트와 에이전트의 MCP 서버 연결을 동일한 정책 체계로 관리할 수 있다. - 새로운 AI 비서나 AI 기반 업무 도구가 도입돼도 보안을 사후에 덧붙이는 대신 기존 제로 트러스트 정책을 즉시 적용할 수 있다. - 단일 아키텍처를 활용해 새로운 AI 보안 기능을 별도 제품 통합 주기 없이 빠르게 배포할 수 있다는 점을 강조한다. ## 사용하기 쉬운 SASE - 기존 SASE는 여러 검사 지점을 거치는 복잡한 트래픽 경로와 제품별 관리 방식 때문에 배포 기간이 길어지는 문제가 있었다. - Cloudflare는 서비스가 동일한 네트워크에서 일관되게 동작하도록 설계해 전문 장비 간 연결과 별도 용량 계획을 줄인다. - 새로운 애플리케이션에 제로 트러스트를 적용하거나 Gateway 트래픽에 DLP를 추가하는 작업을 설정 중심으로 처리할 수 있다고 설명한다. ## 프로그래밍 가능한 SASE - 글은 단순한 GUI 자동화나 제한적인 API를 “프로그래밍 가능성”이라고 부르는 기존 방식을 비판한다. - Cloudflare는 엣지 개발자 플랫폼과 SASE를 결합해 사용자 코드를 SASE 패브릭 안에서 직접 실행할 수 있는 구조를 지향한다. - 이를 통해 실시간 신호를 활용한 접근 결정 등 기업별 맞춤 로직을 기본 제품의 제약을 우회하지 않고 구현할 수 있다고 주장한다. 실무적으로는 SASE 제품을 평가할 때 기능 목록뿐 아니라 단일 정책 체계, AI 에이전트 권한 관리, 포스트퀀텀 전환 능력, 통합 비용 구조, 커스텀 로직 실행 가능성을 함께 확인하는 것이 중요하다.

zero-trustai-securitysasecloudflare-one+3

cloudflare2026년 8월 5일

에이전트 액세스 모델 (새 탭에서 열림)

기업 보안은 네트워크 위치 대신 사용자 신원과 기기 상태를 기준으로 판단하는 Zero Trust로 발전했지만, 에이전트에는 기존 인간 중심 통제가 충분하지 않다. 에이전트는 짧은 작업 단위로 실행되면서도 사람보다 훨씬 빠르게 권한을 행사하고, 여러 시스템과 다른 에이전트를 연쇄 호출할 수 있기 때문이다. 글은 작업 실행 그래프 전체를 신뢰하지 않고 매 행동을 검증하는 **Agent Access Model(AAM)**을 제안하며, 핵심은 판단을 더 정교하게 만드는 것보다 에이전트의 능력 범위를 처음부터 작게 제한하는 데 있다. ## 인간 중심 보안 모델의 한계 - BeyondCorp는 요청이 내부 네트워크에서 왔는지보다 사용자 신원과 기기 상태를 기준으로 접근을 허용해야 한다고 주장했다. - 이 모델은 사람이 주체라는 전제에서 잘 작동했다. - 사람은 비교적 일정한 기기를 사용한다. - 작업 속도가 느리고 접근 요청 빈도가 제한적이다. - 로그인, 기기 상태, 세션 위험도 등을 바탕으로 개별 접근을 판단할 수 있다. - 에이전트는 하나의 서비스가 여러 작업을 처리하며, 데이터베이스·소스 저장소·로그·티켓 시스템·문서 등에 짧은 시간 안에 접근할 수 있다. - 따라서 인간에게 분기별로 검토하던 최소 권한 정책을 에이전트에게는 실시간으로 적용하고 감사 로그로 남겨야 한다. ## 에이전트의 네 가지 특성 - **자격 증명보다 작업 수명이 짧다** - 서비스 계정용 키는 장기간 유지되고 권한 범위가 넓은 경우가 많다. - 에이전트 작업은 몇 분 만에 끝날 수 있지만 토큰이 메모리, 로그, 환경 변수에 남아 재사용될 수 있다. - 자격 증명 수명은 작업 수명과 일치해야 하며, 작업 종료 시 함께 만료되어야 한다. - **사람보다 훨씬 빠르게 행동한다** - 인간 활동을 기준으로 설계한 이상 탐지, 속도 제한, 데이터 유출 방지 기능은 대응 전에 이미 대량의 데이터가 전송될 수 있다. - 데이터베이스 연결과 외부 네트워크가 동시에 있으면 읽은 정보를 즉시 외부 엔드포인트로 전송할 수 있다. - 그러므로 통제는 사후 탐지가 아니라 도구 호출과 네트워크 요청이 발생하는 지점에서 동기적으로 실행되어야 한다. - **프롬프트는 보안 경계가 아니다** - “운영 환경에 접근하지 말라” 같은 지시는 행동 의도를 표현할 뿐 접근을 강제하지 않는다. - 입력 데이터에 삽입된 지시로 에이전트가 조작될 수 있고, 에이전트가 스스로 안전하지 않은 행동을 선택할 수도 있다. - 실제 강제는 도구 호출을 중재하는 하네스와 패킷을 통제하는 네트워크 계층에서 수행해야 한다. - **여러 홉을 거치며 권한을 조합한다** - 한 에이전트가 도구를 호출하고, 그 도구가 다시 다른 에이전트나 API를 호출할 수 있다. - 이 과정에서 원래 요청한 사람, 작업 목적, 허용된 권한의 관계가 사라질 수 있다. - 기존 권한 모델은 단일 위임에는 대응해도 다단계·다중 사용자 위임에는 취약하다. ## 작업 실행 그래프를 기준으로 한 AAM - AAM의 출발점은 “실행 중인 작업 자체를 신뢰하지 말라”는 원칙이다. - 에이전트의 각 행동은 다음 세 가지를 기준으로 매번 인가된다. - 에이전트의 신원 - 해당 에이전트가 수행하도록 승인된 작업 - 작업 실행 그래프가 지금까지 접근한 정책상 중요한 리소스 - 한 행동이 승인되었다고 해서 다음 행동까지 자동으로 승인되지 않는다. - 그래프에 누적된 상태는 이후 사용할 수 있는 권한을 줄일 수만 있으며, 작업 중 권한을 임의로 확대하지 않는다. - Beyond Zero처럼 개별 행동 단위로 판단하는 방식과 결합할 수 있으며, AAM은 판단 엔진이 검토해야 할 권한 범위를 제한한다. ## AAM의 다섯 가지 원칙 - **짧고 작업에 결합된 자격 증명** - 작업 전용 자격 증명을 발급하고 작업 종료 시 만료시킨다. - 탈취된 토큰만으로 재사용할 수 없도록 하네스가 보유한 증명 키에 토큰을 결합한다. - **하네스와 네트워크에서의 강제** - 프롬프트는 의도를 설명하는 수단일 뿐이다. - 도구 호출은 하네스에서, 네트워크 요청은 네트워크 계층에서 정책으로 차단·허용한다. - **예외적인 인간 승인** - 모든 단계마다 사람의 승인을 요구하면 승인 피로와 형식적인 클릭이 발생한다. - 정말 중요한 의사결정에만 인간 승인을 사용해야 한다. - **증거 기반 권한 검토** - 실제 작업 활동을 분석해 작업 템플릿의 권한이 과도한지 부족한지 판단한다. - 검토 후 승인된 변경은 이후 작업에만 적용하며, 현재 실행 중인 작업의 권한을 소급해 확대하지 않는다. - **되돌릴 수 없는 신뢰 감소** - 보호 대상 이벤트가 발생하면 Trust Ratchet이 작업 실행 그래프 전체의 권한을 정책에 따라 제거한다. - 제거된 권한은 현재 작업에서 복구되지 않고, 새롭게 승인된 작업에서만 다시 부여된다. ## 참조 아키텍처와 에이전트 신원 브로커 - AAM 참조 아키텍처는 작업을 직접 통제하는 네 가지 활성 제어와, 증적을 처리하는 두 개의 지원 시스템으로 구성된다. - 지원 시스템에는 다음이 포함된다. - **Agent Activity Log**: 작업 중 발생한 활동을 기록한다. - **Grant Review Loop**: 기록된 증거를 바탕으로 향후 권한 정책을 검토한다. - **Agent Identity Broker**는 작업이 배포될 때 작업 범위가 제한된 검증 가능한 자격 증명을 발급한다. - 자격 증명은 작업 종료 시점보다 늦게 만료되지 않아야 한다. - 자격 증명에는 최소한 다음 관계가 표현된다. - 어떤 에이전트인지 - 누구를 대신하는지 - 어떤 작업을 수행하는지 - 또한 발신자 제약(sender constraint)을 적용해, 자격 증명만 탈취한 공격자가 하네스의 증명 키 없이 재사용하지 못하도록 한다. ## 실용적인 적용 방향 - 에이전트마다 장기 서비스 계정과 광범위한 정적 키를 제공하지 말고, 작업별 단기 자격 증명을 발급하는 것이 우선이다. - 프롬프트의 금지 문구에 의존하지 말고 하네스와 네트워크 계층에서 도구·데이터·외부 전송을 직접 제한해야 한다. - 모든 행동에 인간 승인을 넣기보다 고위험 작업에만 승인 절차를 적용해야 한다. - 활동 로그를 통해 권한 범위를 지속적으로 줄이되, 실행 중인 작업의 권한을 사후에 넓히지 않는 원칙을 유지해야 한다.

zero-trustaccess-controlaudit-loggingleast-privilege+2

cloudflare2026년 8월 5일

Cloudflare OS로 Cloudflare의 업무 방식을 재구상하는 방법 (새 탭에서 열림)

Cloudflare는 AI 에이전트가 업무 방식을 크게 바꿀 만큼 발전했지만, 생산 시스템과 내부·고객 데이터에 대한 통제가 함께 필요하다고 판단했다. 이를 위해 사내 AI 플랫폼인 **Cloudflare OS**를 구축하고, 인간의 책임·최소 권한·조직 맥락 활용을 핵심 원칙으로 삼았다. 엔지니어에게는 코드 품질과 보안을 위한 가드레일을 제공하고, 비엔지니어에게는 개발 도구가 아닌 업무 중심의 직관적인 인터페이스를 제공하려 했다. ## AI 확산과 거버넌스의 필요성 - 영업팀 직원이 AI로 여러 시스템의 API 키와 배포 파이프라인 관리자 권한을 요구하는 “SuperApp”을 만든 것이 문제의 출발점이었다. - 초기에는 정보 검색용 챗봇과 코드 작성 보조 정도로 AI를 제한했지만, 더 강력한 모델과 에이전트 도구가 등장하면서 상황이 급변했다. - 기술·비기술 직군 모두가 AI를 활용해 업무를 자동화하려 했고, 회사는 생산성을 지원하면서도 다음 자산을 보호해야 했다. - 내부 시스템 - 조직 데이터 - 고객 데이터 - 배포 및 운영 환경 - Cloudflare는 Workers, Access 등 기존 개발자·Zero Trust 제품을 조합하고 맞춤형 서비스를 추가해 Cloudflare OS를 구축했다. ## AI 도입을 위한 다섯 가지 원칙 ### 고객 문제 해결이 출발점 - AI를 사용하는 것 자체를 목표로 삼지 않는다. - 먼저 “해야 할 일(jobs to be done)”과 업무의 병목, 고객 대응의 개선 지점을 정의한다. - 그 다음 문제에 적합한 AI 도구를 선택한다. ### 모든 직원에게 도구를 제공 - 초기 AI 에이전트는 터미널, 코드 에디터, Git 저장소 등 개발자 중심의 인터페이스에 집중됐다. - 하지만 모든 직원이 개발 도구를 사용할 필요는 없다. - 직원은 자신의 도메인 전문성을 제공하고, 회사는 누구나 사용할 수 있는 직관적인 플랫폼을 제공해야 한다. ### AI 결과물은 인간이 책임진다 - AI를 팀원으로 간주하지 않고 도구와 도구 제작자로 본다. - AI 결과물의 품질 기준, 테스트 방법, 업무 흐름을 정의하고 검증하는 책임은 사람에게 있다. - 에이전트를 만든 사람이 회사를 떠나면 관리자가 해당 에이전트의 책임을 이어받는다. ### 모델보다 조직 맥락이 중요하다 - Cloudflare용 에이전트는 일반적인 지식뿐 아니라 Cloudflare의 정책, 업무 방식, 시스템 구조를 이해해야 한다. - 따라서 모델 성능 향상과 함께 신뢰할 수 있고 정제된 조직 지식 계층을 구축해야 한다. ### AI 사용 시 권한을 확대하지 않는다 - AI를 통해 시스템 원장에 접근할 때 사용자가 기존보다 더 많은 권한을 가져서는 안 된다. - 에이전트는 업무에 필요한 최소 권한만 가져야 한다. - 에이전트를 다른 사람과 공유할 때도 제작자의 권한이 아니라 사용하는 사람의 권한을 적용해야 한다. - 기존의 역할·기기·지역별 접근 제어와 서드파티 애플리케이션의 보안 설정도 AI 에이전트에 동일하게 적용해야 한다. ## 엔지니어를 위한 가드레일: Engineering Codex - AI가 코드를 매우 빠르게 작성하면서 기존 코드 리뷰 프로세스가 따라가지 못했고, 잘못된 코드도 더 빠르게 생성되는 문제가 생겼다. - Cloudflare는 엔지니어링 원칙과 모범 사례를 담은 권위 있는 가이드인 **Cloudflare Engineering Codex**를 만들었다. - Codex는 단순히 금지 목록을 제시하는 정책이 아니라, 각 영역에서 “어떻게 해야 좋은가”를 제시하는 의견이 반영된 기준이다. - 코드베이스의 각 영역에는 품질 기준에 책임을 지는 도메인 오너가 있다. - Codex는 소프트웨어 개발 생명주기 전반에 적용된다. - 작업 계획 검토 - 기술 설계 검토 - Merge Request 검토 - 장애 보고서 검토 - 최근 4개월 동안 관련 에이전트는 약 25만 건의 잠재적 문제를 발견했고, 1만 6천 건의 병합을 차단했다. - 구현이 시작되기 전 약 600건의 설계에서 아키텍처 문제를 찾아냈다. - 다음 단계는 에이전트가 생성한 결과물을 평가하는 평가 루프를 엔지니어들이 직접 정의할 수 있도록 지원하는 것이다. ## 비엔지니어를 위한 접근 방식의 전환 - 초기에는 엔지니어용 도구에 더 친절한 사용자 인터페이스만 입힌 방식으로 비엔지니어를 지원하려 했다. - 그러나 코드 저장소를 복제하고 `AGENTS.md` 같은 컨텍스트 파일을 추가하는 개발자 중심 방식은 비정형 지식 업무와 잘 맞지 않았다. - 비엔지니어의 업무는 다음과 같은 특징이 있다. - 일회성 결과물을 자주 만든다. - 여러 시스템 원장의 데이터를 함께 사용한다. - 명확한 코드 저장소나 반복 가능한 개발 프로젝트가 없는 경우가 많다. - 개발용 에이전트 환경을 그대로 제공하면 실제 문제보다 더 많은 “바이브 코딩” 앱이 만들어지는 문제가 발생했다. - Cloudflare는 이 접근이 잘못되었음을 인정하고, 사용자가 직접 도구를 조립하게 하기보다 원하지 않는 업무를 “매직 AI 이메일 봇”에 보내도록 하는 업무 중심 인터페이스로 방향을 전환했다. Cloudflare의 경험은 AI 도입에서 모델 선택보다 **권한 설계, 조직 지식의 구조화, 인간의 책임, 사용자별 인터페이스**가 더 중요할 수 있음을 보여준다. 특히 에이전트는 기존 사용자의 권한을 넘지 않도록 설계하고, 직군별 업무 방식에 맞는 도구를 제공하는 것이 안전하고 지속 가능한 도입의 핵심이다.

zero-trustai-agentcloudflare-workerscode-review+2

cloudflare2026년 7월 20일

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 장비를 줄이고, 정책·감사·전파 경로를 단일화하는 방안을 검토할 만하다.

zero-trustdnsterraformcloudflare-gateway+4

cloudflare2026년 7월 7일

Cloudflare, 영국 정부의 사이버 복원력 서약에 자랑스럽게 동참 (새 탭에서 열림)

Cloudflare는 영국 정부의 자발적 사이버 복원력 서약(Cyber Resilience Pledge) 창립 서명기관으로 참여하며, 보안의 대중화·경영진 책임·투명성이라는 원칙을 지지한다고 밝혔다. 이 서약은 기업이 이사회 차원에서 사이버 보안을 관리하고, 공급망 전체의 보안 수준을 높이며, 기본적인 기술 통제를 갖추도록 요구한다. Cloudflare는 보안이 특정 상품이나 대기업만의 영역이 아니라 모든 조직에 기본값으로 제공되어야 하며, 집단 방어를 통해 인터넷 전체의 복원력을 높여야 한다고 주장한다. ## 영국 사이버 복원력 서약의 배경 - 영국 정부가 조직의 기본적인 사이버 보안 거버넌스와 이사회 책임을 강화하기 위해 자발적 프레임워크를 출범시켰다. - 주요 원칙은 다음과 같다. - 보안 기술과 보호 기능의 대중화 - 경영진 및 이사회의 책임 강화 - 사고와 대응 과정에 대한 투명성 확대 - 공급망 전반의 보안 기준 향상 - Cloudflare는 이 서약을 새로운 의무라기보다, 지난 10여 년간 추진해 온 보안 철학을 영국 정부가 공식적으로 확인한 것으로 평가한다. - Cloudflare는 영국 과학·혁신·기술부(DSIT), 국가사이버보안센터(NCSC) 등과 협력해 영국의 디지털 경제 보안을 강화해 왔다. ## 증가하는 사이버 위협과 AI의 영향 - Cloudflare는 2026년 1분기에 전 세계 네트워크에서 하루 평균 2,340억 건의 사이버 위협을 차단했다. - 최근에는 최대 31.4Tbps 규모의 초대형 DDoS 공격을 완화했다. - 2025년 말 기준 영국은 전 세계에서 DDoS 공격 표적이 많은 국가 6위로 올라섰다. - 금융 서비스, 항공, 지방정부 인프라 등에서 애플리케이션 계층 공격이 증가하고 있다. - 영국 사이버 보안 침해 조사에 따르면 지난 1년간 사이버 사고를 경험한 비율은 기업 43%, 자선단체 28%였다. - 프런티어 AI 모델은 공격자의 진입 장벽을 낮추고 다음과 같은 공격을 자동화·고도화하고 있다. - 취약점 자동 탐색 - 대규모 공격 시도 - 더욱 설득력 있는 피싱 캠페인 - 이에 따라 방어 체계도 머신러닝 기반 공격 평가, Zero Trust 접근 제어 등으로 위협 변화에 맞춰 빠르게 발전해야 한다. ## 사이버 복원력은 비즈니스의 기본 요건 - 고객은 공격이나 장애 상황에서도 서비스가 지속적으로 제공되고, 빠르게 응답하며, 신뢰할 수 있기를 기대한다. - 사이버 복원력은 단순히 사고 발생 후 복구하는 능력이 아니다. - 복원력 있는 시스템은 다음을 수행해야 한다. - 위협 신호를 사전에 탐지 - 공격과 장애를 서비스 전체로 확산시키지 않고 흡수 - 운영 과정에서 얻은 교훈을 바탕으로 지속적으로 개선 - 따라서 보안 통제는 복원력을 실현하는 핵심 기반이며, 보안과 복원력은 분리할 수 없는 개념이다. ## 보안을 상품 등급이 아닌 기본값으로 제공 - Cloudflare는 기본적인 보안 기능을 모든 조직이 사용할 수 있어야 한다고 주장한다. - 모든 사용자에게 트래픽 암호화에 필요한 SSL 인증서를 제공했고, 무료 요금제에도 다음 기능을 포함한다. - 공격 규모와 관계없는 무제한 DDoS 보호 - 글로벌 CDN - DNSSEC - 네트워크 전반에 양자내성 암호화를 도입하는 등 인터넷 암호화 기술도 발전시키고 있다. - Project Galileo와 Athenian Project를 통해 취약한 목소리와 공공기관을 보호한다. - 중소기업, 지방정부, 공공서비스, 스타트업도 보안 수준을 높일 수 있어야 서약의 목표인 “사이버 복원력의 최저선”을 높일 수 있다는 취지다. ## 네트워크 전체를 위협 탐지 센서로 활용 - Cloudflare는 전 세계 13,000개 이상의 네트워크와 직접 피어링하며 공격 패턴을 대규모로 관찰한다. - 한 지역에서 발견한 위협 정보와 공격 패턴을 수초 내 네트워크 전체의 방어 규칙에 반영할 수 있다. - 예를 들어 싱가포르 고객을 공격한 위협을 분석해 얻은 규칙이 곧바로 영국 셰필드의 고객 보호에도 활용될 수 있다. - 대규모 가시성은 공격 탐지, 위험 점수 산정, 대응 속도를 개선하고 고객 전체의 복원력을 높인다. ## 스스로 먼저 검증하는 ‘고객 제로’ 원칙 - Cloudflare는 고객에게 제공하는 보안 제품과 인프라를 자체 시스템 보호에도 사용한다. - 내부 애플리케이션 접근에는 다음 통제를 적용한다. - Cloudflare Access와 Gateway - 하드웨어 키 기반 다중 인증 - 기기 보안 상태 점검 - 암호학적으로 검증된 신원 토큰 - 모든 보안 계층을 내부 환경에서 먼저 시험하고, 운영 경험을 제품과 네트워크 개선에 반영한다. - 보안을 특정 팀이나 제품의 책임이 아니라 조직 전반의 운영 방식으로 통합한다. ## 투명한 공개와 사고 이후의 개선 - 사고나 제로데이 취약점이 발생하면 기술적 사후 분석(postmortem)을 공개한다. - 침해 지표(IoC)와 아키텍처 회고를 공유해 다른 조직과 보안 커뮤니티가 동일한 위협에 대비할 수 있도록 한다. - 투명한 공개만으로 끝내지 않고, 사고를 시스템 개선의 계기로 활용한다. - 대규모 장애 이후 진행한 “Code Orange” 작업에서는 다음을 추진했다. - 장애가 전체 시스템으로 번지지 않도록 “작게 실패하는(fail small)” 구조 설계 - 안전한 구성 변경을 강제하는 도구 개발 - 보안 모범 사례의 자동화 - 목표는 같은 유형의 장애가 반복되지 않도록 구조적 원인을 제거하는 것이다. ## 서약이 강조하는 조직 차원의 책임 - 서약은 이사회 책임과 거버넌스, 공급망 보안, 영국 Cyber Essentials 인증과 관련된 기술 요건을 기업이 수용하도록 요구한다. - 대부분의 침해 사고는 패치되지 않은 시스템, 취약한 접근 제어, 부실한 공급업체 관리처럼 이미 알려진 문제에서 발생한다. - 따라서 고도화된 기술만큼 다음과 같은 기본 통제의 광범위한 적용이 중요하다. - 정기적인 패치와 취약점 관리 - 강력한 인증 및 접근 권한 통제 - 공급업체 보안 검토 - 지속적인 모니터링 - 이사회 차원의 위험 관리와 책임 부여 영국의 서약은 사이버 보안을 IT 부서의 단독 과제가 아니라 경영진과 공급망 전체가 함께 책임져야 할 사업 과제로 끌어올린다는 점에서 의미가 있다. 조직은 우선 패치, 인증, 접근 제어, 공급업체 관리 같은 기본 통제를 강화하고, 사고를 숨기기보다 투명하게 공유하며, 보안을 모든 서비스의 기본값으로 설계하는 것이 바람직하다.

zero-trustcloudflarepost-quantum-cryptographycybersecurity+3

cloudflare2026년 6월 17일

Cloudflare One 스택 소개: 에이전트 기반 배포 (새 탭에서 열림)

Cloudflare는 Zero Trust 도입·마이그레이션·운영을 에이전트가 수행하도록 돕는 “Cloudflare One stack”을 공개했습니다. 이 스택은 Cloudflare One 제품 지식, 의사결정 트리, 마이그레이션 로직, API 도구를 제공해 기존 네트워크를 분석하고 안전한 배포 계획과 설정을 생성합니다. 특히 Zscaler·Palo Alto Networks 등 기존 SASE 솔루션에서 Cloudflare로 이전하는 작업을 자동화하고, 운영 중인 환경의 문제 해결까지 지원하는 것이 핵심입니다. ## 네트워크 보안에서의 에이전트 활용 격차 - 조직은 이미 에이전트를 코드 작성, 보안 알림 분류, 업무 자동화에 활용하고 있습니다. - 그러나 에이전트가 조직별 네트워크 토폴로지, 인증 정책, 트래픽 흐름, 기존 공급업체 설정을 자동으로 이해하기는 어렵습니다. - Cloudflare One stack은 이러한 부족한 맥락을 보완하기 위해 Cloudflare 제품에 대한 권위 있고 구체적인 지침을 제공합니다. - 이를 통해 에이전트가 일반적인 API 호출이 아니라 권장된 보안·배포 절차에 따라 작업하도록 합니다. ## Cloudflare One stack의 구성 - 어떤 에이전트와도 사용할 수 있는 스킬 모음으로 제공됩니다. - 두 개의 경량 스킬 파일로 구성됩니다. - `cloudflare-one`: Cloudflare One 구축, 관리, 운영, 문제 해결 - `cloudflare-one-migration`: 다른 SASE 제품에서 Cloudflare로의 마이그레이션 - Cloudflare One 고객 지원 과정에서 축적된 수만 시간의 실무 지식을 기반으로 제작되었습니다. - Cloudflare Code Mode MCP 서버와 함께 사용하면 Cloudflare API에 타입이 지정된 인터페이스로 접근할 수 있습니다. - 에이전트는 실시간 계정 정보를 조회하고, 현재 설정을 검사하며, 검증된 방식으로 변경을 수행할 수 있습니다. ## 지원하는 Cloudflare One 영역 - **Cloudflare Access** - 기존 VPN과 원격 접속 환경을 대체합니다. - 애플리케이션별 인증·인가 정책을 구성합니다. - **Cloudflare Gateway** - 사용자, 네트워크, 디바이스, 데이터를 보호합니다. - **Cloudflare Tunnel·Mesh·WAN** - 애플리케이션과 네트워크 간 연결 방식을 구성합니다. - **마이그레이션** - Zscaler, Palo Alto Networks 등 기존 SASE 공급업체의 개념과 설정을 Cloudflare 방식으로 변환합니다. - **네트워크 다이어그램** - 현재 또는 제안된 네트워크 구조를 시각화합니다. - **운영 및 문제 해결** - Digital Experience Monitoring(DEX)으로 사용자 경험과 지연 문제를 분석합니다. - 트래픽을 바탕으로 보안 규칙을 추천합니다. ## VPN 교체와 신규 배포 절차 에이전트는 기존 VPN 환경을 분석한 뒤 다음과 같은 순서로 Cloudflare 구성을 제안할 수 있습니다. - 기존 VPN 애플리케이션을 목록화하고 각 애플리케이션에 필요한 연결 모델을 식별합니다. - 애플리케이션을 적절한 Cloudflare 구성요소에 매핑합니다. - Self-hosted Access 애플리케이션 - Tunnel 연결 서비스 - Mesh 연결 네트워크 세그먼트 - 서비스 중단을 최소화하도록 단계별 전환 순서를 생성합니다. - 실제 변경 전에 팀이 검토할 수 있는 구성 요약을 제공합니다. ## 공급업체 간 마이그레이션 자동화 - Zscaler Private Access 애플리케이션 정의를 Cloudflare Access 애플리케이션 정의로 변환합니다. - 사용자 그룹과 보안 정책을 Cloudflare Access 정책으로 매핑합니다. - Cloudflare API를 사용해 변환된 리소스를 계정에 생성할 수 있습니다. - 마이그레이션된 항목과 수동 검토가 필요한 예외를 별도로 정리합니다. - 이 로직은 Cloudflare의 Descaler·Deskope 프로그램에 사용된 방식으로, 기업 고객의 이전 작업을 수개월에서 수시간으로 단축한 사례를 바탕으로 합니다. ## 운영 중인 환경의 보안·성능 개선 - 실시간 계정의 트래픽을 분석해 적절한 보안 규칙을 추천합니다. - 기존 Zscaler Private Access 애플리케이션을 Cloudflare의 self-hosted Access 애플리케이션으로 자동 이전할 수 있습니다. - Secure Web Gateway HTTP 로그에서 이상 현상을 조사하고 사용자 문제를 해결할 규칙을 만들 수 있습니다. - DEX 도구를 이용해 사용자 연결 안정성과 지연 시간을 분석하고 개선 조치를 제안합니다. ## 실용적인 결론 Cloudflare One stack은 Zero Trust 전문가의 경험을 에이전트가 활용할 수 있는 구조화된 지식과 도구로 패키징한 제품입니다. 다만 네트워크 정책 변경은 영향 범위가 크므로 에이전트가 생성한 계획과 구성 요약을 먼저 검토하고, 단계적 전환과 수동 승인을 병행하는 방식이 적절합니다.

zero-trustmodel-context-protocolsasecloudflare-access+4

cloudflare2026년 6월 10일

Cloudflare로 퍼블릭 트래픽을 프라이빗 애플리케이션으로 라우팅하기 (새 탭에서 열림)

Cloudflare는 이제 퍼블릭 IP를 노출하지 않고도 인터넷 트래픽을 사설 애플리케이션으로 전달하는 **Application Services for Private Origins**를 제공한다. 이를 통해 사설 네트워크의 내부 API, AI 에이전트 백엔드, MCP 서버, 운영 도구에도 WAF, 봇 관리, 레이트 리미팅, 캐싱, Workers 같은 Cloudflare 기능을 적용할 수 있다. 핵심은 기존 Cloudflare Tunnel, WAN, Mesh 등의 사설 연결 경로를 애플리케이션 프록시 계층과 통합해, 마지막 구간만 사설 네트워크로 전송하는 것이다. ### 퍼블릭 애플리케이션과 프라이빗 애플리케이션의 경계 - 기존에는 퍼블릭 애플리케이션이 CDN·WAF 뒤에, 프라이빗 애플리케이션이 VPN·방화벽·별도 네트워크 스택 뒤에 위치했다. - 내부 API, AI 백엔드, MCP 서버처럼 인터넷에 직접 공개할 필요는 없지만 보안·성능 제어가 필요한 서비스가 늘고 있다. - 기존 방식은 퍼블릭 IP, 방화벽 예외, 커넥터 소프트웨어, 복잡한 네트워크 구성을 요구했다. - 그 결과 프라이빗 애플리케이션은 WAF, 봇 관리, 속도 제한, 캐시, 트래픽 가속, URL 변환, Workers 등의 기능을 활용하기 어려웠다. ### Application Services for Private Origins - 적격 Enterprise 고객을 대상으로 클로즈드 베타로 제공된다. - 사설 오리진을 인터넷에 노출하지 않고도 Cloudflare를 통해 퍼블릭 트래픽을 전달한다. - 다음 기능을 프라이빗 오리진 앞에서 사용할 수 있다. - WAF - 봇 관리 - 레이트 리미팅 - 캐싱 - URL·요청 변환 - Workers - 오리진에 퍼블릭 IP, 인바운드 방화벽 규칙, `cloudflared` 실행을 반드시 요구하지 않는다. ### 하나로 통합되는 사설 네트워크 연결 - 기존 Cloudflare Tunnel, Cloudflare One Client, Cloudflare WAN, Cloudflare Mesh 등의 연결 모델을 활용한다. - Cloudflare의 사설 네트워크 라우팅 계층이 다음 경로를 통합적으로 관리한다. - Cloudflare Tunnel - IPsec·GRE 터널 - CNI 연결 - Cloudflare Mesh - 기타 사설 연결 방식 - 고객은 제품별로 별도 네트워크 스택을 운영하는 대신 API나 대시보드에서 라우팅을 정의할 수 있다. - Workers VPC 바인딩과 Spectrum의 프라이빗 오리진 라우팅도 같은 사설 연결 계층을 사용하게 된다. ### 네 가지 트래픽 조합 Cloudflare는 사용자 위치와 애플리케이션 위치에 따라 트래픽을 네 가지 조합으로 구분한다. - 인터넷 사용자 → 인터넷 애플리케이션: 기존 Cloudflare 프록시 모델 - 프라이빗 네트워크 사용자 → 인터넷 서비스: Cloudflare One 모델 - 인터넷 사용자 → 프라이빗 애플리케이션: 이번에 제공하는 기능 - 프라이빗 네트워크 사용자 → 프라이빗 애플리케이션: 향후 구축 대상 ### DNS 레코드로 활성화하는 프라이빗 라우팅 - 프록시된 A 또는 AAAA 레코드에서 `Use private network routing` 옵션을 활성화한다. - Cloudflare의 WAF, 캐싱, 봇 관리, 레이트 리미팅, Transform Rules는 기존처럼 Cloudflare 네트워크에서 실행된다. - 차이는 오리진으로 향하는 최종 연결만 퍼블릭 인터넷이 아닌 사설 네트워크를 이용한다는 점이다. - 다음 주소 범위는 사설 주소이므로 옵션이 자동 활성화된다. - RFC 1918: `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` - RFC 6598 CGNAT: `100.64.0.0/10` - RFC 4193 IPv6 ULA: `FC00::/7` - 퍼블릭 IP라도 사설 터널을 통해서만 접근할 수 있다면 옵션을 수동으로 활성화할 수 있다. ### API 설정 방식 프라이빗 라우팅은 일반 DNS 레코드에 `use_private_routing` 속성을 추가하는 방식이다. ```json { "type": "A", "name": "app.example.com", "content": "10.0.0.50", "ttl": 300, "proxied": true, "use_private_routing": true } ``` - Cloudflare 프록시는 Origin API에서 오리진 주소와 라우팅 메타데이터를 조회한다. - `use_private_routing: true`가 있으면 프라이빗 IP로 인터넷 연결을 시도하지 않는다. - 대신 IPsec, GRE, Tunnel, CNI, Mesh 등 고객의 기존 연결을 통해 사설 네트워크 라우팅 계층으로 요청을 전달한다. ### HTTP 이외의 서비스 지원 - 이 모델은 웹 애플리케이션뿐 아니라 다양한 프로토콜과 서비스에도 적용된다. - Spectrum을 이용하면 TCP·UDP 기반 서비스도 프라이빗 오리진 뒤에 둘 수 있다. - 데이터베이스 - UDP 로그 수집 엔드포인트 - 기타 비HTTP 서비스 - Workers가 프라이빗 API나 데이터베이스를 직접 호출하는 구성에도 사용할 수 있다. - 공통적으로 Cloudflare가 사용자 트래픽과 사설 네트워크 사이에 위치해 보안, 성능, 라우팅을 통합 제공한다. ### 실용적인 결론 퍼블릭 트래픽을 받아야 하지만 오리진을 인터넷에 공개하고 싶지 않은 조직이라면, 기존 Cloudflare WAN·Tunnel·Mesh 연결을 유지한 채 DNS 레코드의 `use_private_routing`을 활성화하는 방식이 가장 단순하다. 이를 통해 별도의 퍼블릭 로드 밸런서, 역방향 프록시, 다중 TLS 종료 계층을 줄이고 사설 애플리케이션에도 Cloudflare의 보안·성능 기능을 일관되게 적용할 수 있다.

zero-trustcloudflarecloudflare-workersweb-application-firewall+3

cloudflare2026년 5월 1일

코드 오렌지: ‘작게 실패하기’가 완료되었습니다. 그 결과 더욱 강력해진 Cloudflare 네트워크 (새 탭에서 열림)

Cloudflare는 2025년 말 발생했던 두 차례의 대규모 장애를 계기로 추진한 인프라 회복 탄력성 강화 프로젝트인 'Code Orange: Fail Small'을 성공적으로 마무리했습니다. 이번 프로젝트를 통해 설정 변경의 안정성을 확보하고, 장애 발생 시 영향을 최소화하며, 비상 상황에서의 대응 체계를 전면 개편했습니다. 결과적으로 Cloudflare 네트워크는 잠재적인 문제를 조기에 감지하고 격리함으로써 전 세계 사용자에게 더욱 신뢰할 수 있는 서비스를 제공할 수 있게 되었습니다. ### 안전한 설정 변경을 위한 Snapstone 도입 설정 변경이 네트워크 전체에 즉각적으로 반영되어 발생하던 대규모 장애를 방지하기 위해 새로운 배포 매커니즘을 구축했습니다. * **Snapstone 시스템 개발**: 설정을 패키지화하여 단계적으로 배포하고, 실시간 상태 모니터링을 통해 문제가 감지되면 자동으로 롤백하는 통합 관리 도구를 도입했습니다. * **점진적 배포의 표준화**: 과거에는 팀별로 달랐던 배포 방식을 Snapstone으로 통일하여, 데이터 파일이나 글로벌 제어 플래그 등 모든 유형의 설정 변경에 '상태 기반 점진적 배포(Health-mediated deployment)'를 적용합니다. * **리스크 관리 자동화**: 위험한 설정 패턴이 발견되면 이를 Snapstone 관리 대상으로 즉시 편입시켜, 별도의 추가 작업 없이도 안전한 배포 사이클을 보장받을 수 있습니다. ### 장애 영향력 최소화 및 서비스 세분화 장애가 발생하더라도 서비스 전체가 중단되지 않도록 시스템의 구조적 유연성을 높였습니다. * **Fail Open 및 Fail Stale 구현**: 최신 설정을 읽지 못할 경우 마지막으로 정상 작동했던 설정을 사용(Fail Stale)하거나, 일부 기능을 제한하더라도 트래픽 흐름은 유지(Fail Open)하도록 프로그래밍 모델을 개선했습니다. * **고객 코호트별 세분화**: 서비스 실행 환경을 여러 독립적인 세그먼트로 나누어, 무료 사용자 그룹에 먼저 업데이트를 적용하고 점진적으로 확대하는 방식을 도입했습니다. * **폭발 반경(Blast Radius) 제한**: 특정 서비스(예: Workers 런타임)에서 문제가 발생하더라도 전체 네트워크가 아닌 소수의 특정 세그먼트에만 영향이 국한되도록 설계하여 대규모 장애로 확산되는 것을 차단합니다. ### 비상 접근 권한(Break Glass) 및 사고 관리 체계 개편 인프라 장애로 인해 관리 도구 자체가 마비되는 '자기 의존성' 문제를 해결하기 위해 비상 대응 절차를 강화했습니다. * **백업 인증 경로 확보**: 핵심 Zero Trust 보안 툴이 작동하지 않는 극한 상황에서도 시스템에 접근할 수 있도록 18개 주요 서비스에 대한 별도의 비상 인증 경로와 스크립트를 마련했습니다. * **실전 중심의 대응 훈련**: 200명 이상의 엔지니어가 참여하는 대규모 드릴(Drill)을 통해 비상 상황에서의 대응 속도와 숙련도를 높였습니다. * **고객 소통 강화**: 내부 모니터링 데이터가 외부 공지 시스템으로 신속하고 명확하게 전달될 수 있도록 소통 프로세스를 개선하여 장애 시 고객의 불확실성을 해소합니다. Cloudflare의 이번 개선 작업은 단순한 기술적 수정을 넘어, '작게 실패(Fail Small)'함으로써 더 큰 가용성을 보장하는 구조적 변화를 의미합니다. 사용자는 이제 더욱 견고해진 인프라 위에서 예상치 못한 설정 오류나 시스템 장애로부터 보호받으며 서비스를 이용할 수 있습니다.

zero-trustcloudflareincident-managementconfiguration-management+4

cloudflare2026년 4월 20일

우리가 배포하는 플랫폼 위에 내부적으로 구축한 AI 엔지니어링 스택 (새 탭에서 열림)

Cloudflare는 자사 플랫폼의 기술력을 집약한 내부 AI 엔지니어링 스택을 구축하여 전체 R&D 인력의 93%가 AI 도구를 일상적으로 사용하는 환경을 조성했으며, 그 결과 주간 머지 리퀘스트(Merge Request) 수를 약 두 배 가까이 증가시키는 생산성 혁신을 이뤄냈습니다. 이들은 단순한 도구 도입을 넘어 MCP(Model Context Protocol), AI Gateway, Workers AI 등을 결합한 포괄적인 아키텍처를 통해 보안과 운영 효율성을 동시에 확보했습니다. 특히 이번 프로젝트는 실제 고객에게 제공되는 상용 제품들을 내부 워크플로우에 직접 적용하여 그 실효성을 검증했다는 점에서 중요한 기술적 이정표를 제시합니다. ### 통합 플랫폼 및 보안 계층 * **보안 및 인증 관리**: Cloudflare Access를 통한 제로 트러스트 인증으로 보안을 강화하고, 모든 LLM 요청을 AI Gateway로 라우팅하여 중앙 집중식 키 관리, 비용 추적 및 데이터 보존 정책을 적용합니다. * **Workers AI 활용**: 프론티어 모델(OpenAI, Anthropic 등)뿐만 아니라 Workers AI를 통해 Kimi K2.5와 같은 오픈 소스 모델을 병행 운용하며, 특히 보안 에이전트 등의 작업에서 상용 모델 대비 약 77%의 비용 절감 효과를 거두고 있습니다. * **프록시 워커 패턴**: 모든 클라이언트 요청을 단일 프록시 워커를 통해 처리함으로써 클라이언트 설정 변경 없이도 사용자별 권한 부여 및 모델 카탈로그 관리가 가능한 제어 평면(Control Plane)을 구축했습니다. ### 에이전트 기반 인프라와 MCP * **원스톱 온보딩**: `opencode auth login` 명령 하나로 MCP 서버, 에이전트, 명령 및 권한 설정을 자동으로 구성하여 엔지니어가 설정 파일에 손대지 않고도 즉시 AI 도구를 사용할 수 있게 했습니다. * **상태 유지 및 격리 실행**: Durable Objects 기반의 Agents SDK를 사용해 장기 실행되는 에이전트 세션을 관리하며, Sandbox SDK를 통해 에이전트가 생성한 코드를 안전한 격리 환경에서 빌드하고 테스트합니다. * **워크플로우 자동화**: 복잡한 다단계 엔지니어링 작업은 Workflows 기능을 통해 자동화하며, 이는 대규모 리포지토리 전반에 걸친 변경 사항 전파를 효율적으로 지원합니다. ### 지식 체계와 품질 관리 * **기술 지식 그래프**: 오픈소스인 Backstage를 활용해 16,000개 이상의 엔티티를 포함한 지식 그래프를 구축함으로써 에이전트가 조직 내 복잡한 시스템 구조를 정확히 이해할 수 있도록 지원합니다. * **AGENTS.md와 코드 리뷰**: 각 저장소의 컨텍스트를 담은 `AGENTS.md` 파일을 생성하여 에이전트의 정확도를 높이고, CI 파이프라인에 통합된 AI 코드 리뷰어를 통해 급증하는 코드 생산량 속에서도 품질을 유지합니다. Cloudflare의 사례는 AI 도입을 고민하는 기업들에게 '플랫폼 중심 접근법'의 중요성을 시사합니다. 단순한 챗봇 도입이 아니라, 중앙 집중식 게이트웨이를 통한 가시성 확보, 격리된 샌드박스 실행 환경 구축, 그리고 내부 지식 시스템(Backstage 등)과의 결합이 뒷받침될 때 비로소 실제적인 엔지니어링 생산성 향상을 기대할 수 있습니다.

zero-trustdatabase-designci-cdopen-source+4

cloudflare2026년 4월 13일

동적이며 신원 기반의 안전한 샌드박스 인증 (새 탭에서 열림)

AI 에이전트와 같은 신뢰할 수 없는 워크로드를 안전하게 실행하기 위해서는 샌드박스 환경이 필수적이지만, 외부 서비스와의 통신 시 보안과 편의성을 동시에 확보하는 것은 어려운 과제였습니다. 이를 해결하기 위해 도입된 '아웃바운드 워커(outbound Workers)'는 프로그래밍 가능한 이그레스 프록시를 통해 샌드박스 내부로 비밀 키를 노출하지 않고도 안전하고 유연한 인증을 구현합니다. 이 방식은 제로 트러스트 원칙을 준수하면서도 개발자에게 강력한 통제권과 관찰 가능성을 제공하여 AI 워크로드의 보안 수준을 획기적으로 높여줍니다. ### 샌드박스의 핵심 가치와 아웃바운드 워커의 역할 * 샌드박스는 마이크로VM 기술을 활용해 신뢰할 수 없는 사용자나 LLM이 호스트 시스템이나 다른 워크로드를 침해하지 못하도록 격리하는 보안 기능을 제공합니다. * 단순한 격리를 넘어, 사용자가 이전 상태를 빠르게 복구할 수 있는 속도와 플랫폼이 샌드박스 내부 동작을 제어할 수 있는 통제권이 핵심입니다. * 아웃바운드 워커는 샌드박스에서 나가는 모든 트래픽을 가로채는 프록시 역할을 하며, 이를 통해 외부 서비스 연결, 로깅 추가, 동적 인증 주입 등을 프로그래밍 방식으로 처리합니다. ### 기존 에이전트 인증 방식의 문제점 * **표준 API 토큰:** 환경 변수나 파일로 토큰을 직접 주입하는 방식은 가장 단순하지만, 샌드박스가 탈취되거나 에이전트가 실수로 토큰을 노출할 경우 보안에 치명적입니다. * **워크로드 ID 토큰(OIDC):** 보안성은 높으나 많은 외부 서비스가 이를 직접 지원하지 않아, 토큰 교환을 위한 별도의 서비스를 구축해야 하는 등 통합의 유연성이 떨어집니다. * **커스텀 프록시:** 높은 유연성을 제공하지만 모든 트래픽을 효율적이고 동적으로 가로채는 시스템을 직접 설계하고 운영하는 것은 기술적 난이도가 매우 높습니다. ### 아웃바운드 워커를 통한 지능형 인증 매커니즘 * **제로 트러스트 구현:** 샌드박스 내부의 에이전트에게 토큰을 절대 전달하지 않습니다. 대신 프록시 계층에서 요청을 가로채 인증 헤더(예: `x-auth-token`)를 안전하게 삽입합니다. * **세밀한 통제와 관찰:** 자바스크립트 코드를 통해 특정 호스트(예: `github.com`)에 대해서만 인증을 적용하거나, GET 요청 이외의 동작을 차단하고 로깅하는 정책을 손쉽게 설정할 수 있습니다. * **성능과 투명성:** 프록시가 샌드박스와 동일한 머신에서 실행되므로 지연 시간이 거의 없으며, 샌드박스 내부의 워크로드는 프록시의 존재를 모른 채 평소처럼 통신하면 됩니다. * **동적 정책 변경:** 런타임 중에 인증 규칙이나 접근 권한을 즉시 변경할 수 있어, 에이전트의 작업 단계에 따른 유연한 권한 관리가 가능합니다. AI 에이전트가 외부 도구와 상호작용해야 하는 환경을 구축한다면, 에이전트에게 직접 권한을 부여하기보다 아웃바운드 워커와 같은 투명한 프록시 계층을 활용하는 것이 권장됩니다. 이를 통해 보안 사고의 위험을 원천 차단하면서도 개발 복잡성을 획기적으로 줄일 수 있습니다.

zero-trustjavascriptauthenticationhttp-requests+4

cloudflare2026년 3월 16일

레거시 아키텍처에서 Cloudflare One으로의 전환 (새 탭에서 열림)

전통적인 VPN 중심의 레거시 아키텍처에서 제로 트러스트(Zero Trust) 및 SASE 아키텍처로 전환하는 과정은 '빅뱅' 방식의 일괄 마이그레이션이 수반하는 가동 중단 위험 때문에 많은 기업에 큰 부담이 됩니다. Cloudflare와 CDW는 이러한 위험을 줄이기 위해 모든 애플리케이션을 복잡도에 따라 계층화하고, 레거시 앱을 현대적인 보안 계층으로 감싸는 단계적 방법론을 제시합니다. 결과적으로 기업은 서비스 중단 없이 보안 부채를 해결하고, 신원 및 기기 상태 기반의 정교한 보안 태세를 구축할 수 있습니다. ### 단계별 방법론을 통한 마이그레이션 함정 회피 단순히 네트워크 연결 방식만 바꾸는 '리프트 앤 시프트(Lift and Shift)' 방식은 복잡한 애플리케이션 간의 상호 의존성을 간과하여 대규모 장애를 초래할 수 있습니다. * **리스크 기반 계층화:** 모든 애플리케이션을 기술적 복잡도에 따라 분류하고, 현대적인 앱부터 우선 이동하여 동력을 확보한 뒤 복잡한 레거시 시스템을 나중에 제어된 환경에서 전환합니다. * **실패 사례 분석:** 500개 이상의 앱을 한꺼번에 이전하려다 서비스 중단을 겪은 공공 부문 사례를 교훈 삼아, 마이그레이션을 단순 연결 교체가 아닌 '애플리케이션 현대화 프로젝트'로 취급합니다. * **보안 내재화:** 마이그레이션 전략 수립 단계부터 보안 요구사항을 기초 아키텍처에 포함하여, 사후에 보안을 덧붙이는 방식에서 벗어납니다. ### Cloudflare Access와 Tunnel을 활용한 레거시 현대화 레거시 애플리케이션의 코드를 수정하지 않고도 Cloudflare Access를 통해 제로 트러스트 모델을 적용하여 보안 수준을 높일 수 있습니다. * **VPN 경계 대체:** 특정 네트워크 세그먼트 전체에 권한을 주는 VPN 대신, 신원과 기기 상태를 기반으로 모든 개별 요청을 평가하는 모델로 전환합니다. * **Cloudflare Tunnel 활용:** 외부 노출 없이 내부에서 외부로 나가는(Outbound-only) 연결을 생성하여, 레거시 앱에 공인 IP 주소를 부여하지 않고도 안전하게 외부에 노출할 수 있습니다. * **보안 래핑(Wrapping):** 자체 MFA(다요소 인증) 기능이 없는 구형 앱에 SSO 및 하드웨어 기반 MFA를 강제 적용하며, 데이터가 서버에 도달하기 전 엣지(Edge) 단에서 보안 정책을 검증합니다. ### 마이그레이션 전 아키텍처 감사 및 준비 사항 안정적인 전환을 위해 IT 리더는 파일럿 프로젝트 이전에 환경의 기술적 호환성을 철저히 점검해야 합니다. * **ID 제공업체 및 종속성 맵핑:** Okta와 같은 페더레이션 ID 제공업체 활용 여부를 확인하고, 백엔드 데이터베이스나 API 호출 관계를 문서화하여 서비스 단절을 방지합니다. * **전략과 실행 그룹의 분리(Firebreak):** 보안 표준을 설정하는 전략 그룹과 효율성을 중시하는 실행 그룹을 분리하여, 배포 속도 때문에 보안 요건이 무시되지 않도록 합니다. * **세션 지속성 테스트:** 셀룰러 타워 전환 시에도 세션이 유지되어야 하는 앱을 식별하고, Cloudflare의 PMTUD(Dynamic Path MTU Discovery) 기술을 통해 안정적인 연결을 보장합니다. ### 애플리케이션 유형별 마이그레이션 전략 전환에 소요되는 시간과 노력을 기준으로 애플리케이션을 세 가지 티어로 분류하여 현실적인 일정을 수립합니다. * **Tier 0 (SaaS):** 현대적인 인증 프로토콜을 지원하는 앱으로, 클라이언트리스 프록시를 통해 1~3시간 내외로 빠르게 전환 가능합니다. * **Tier 1 (내부 웹 앱):** 현대적 웹 프로토콜을 사용하는 내부 앱으로, Cloudflare Tunnel을 활용해 3~6시간 정도 소요됩니다. * **Tier 2 (비 웹 및 Thick-Client):** 특정 포트나 프로토콜 지원이 필요한 앱으로, Cloudflare One Client와 Tunnel을 병행 배포해야 하며 앱당 4~8시간이 소요됩니다. 성공적인 제로 트러스트 전환을 위해서는 속도보다 **'가시성'과 '단계적 접근'**이 중요합니다. 레거시 시스템을 한꺼번에 교체하려 하기보다, Cloudflare의 엣지 보안 계층으로 기존 앱을 보호하면서 점진적으로 현대화해 나가는 것이 운영 안정성을 확보하는 최선의 방법입니다.

zero-trustdatabase-designcloudflaresase+4

cloudflare2026년 3월 10일

로그 탐색기에서 멀티 (새 탭에서 열림)

Cloudflare Log Explorer는 애플리케이션 서비스와 Cloudflare One(Zero Trust) 포트폴리오를 아우르는 14개 이상의 데이터셋을 통합하여 다중 벡터(multi-vector) 공격에 대한 360도 가시성을 제공합니다. 보안 분석가는 애플리케이션 계층의 HTTP 요청, 네트워크 계층의 DDoS 및 방화벽 로그, 제로 트러스트 인증 이벤트를 상호 연관시켜 분석함으로써 평균 탐지 시간(MTTD)을 획기적으로 단축할 수 있습니다. 결과적으로 이 플랫폼은 정교하게 설계된 다층적 공격의 실체를 신속하게 파악하고 대응할 수 있는 강력한 포렌식 환경을 구축합니다. ### 클라우드 스택 전체를 위한 '비행 기록 장치' * Log Explorer는 애플리케이션의 모든 상호작용, 공격 시도, 성능 병목 현상을 캡처하는 '비행 기록 장치(Flight Recorder)' 역할을 수행하며, 중앙 집중화된 인터페이스를 통해 신속한 조사를 지원합니다. * Cloudflare는 사용자와 서버 사이의 에지(Edge)에서 작동하므로, 요청이 실제 기업 인프라에 도달하기 전에 모든 이벤트를 로깅하여 보안 사각지대를 제거합니다. ### 영역(Zone) 기반의 외부 트래픽 보안 로그 * **HTTP Requests & Firewall Events:** 애플리케이션 계층 트래픽의 기본 기록으로서 세션 활동을 재구성하고, WAF 규칙이나 IP 평판에 의해 차단된 위협의 구체적 증거를 제공합니다. * **DNS & Spectrum Logs:** DNS 캐시 포이즈닝 시도나 도메인 하이재킹을 식별하며, SSH/RDP와 같은 비웹(L4) 프로토콜에 대한 무차별 대입 공격을 모니터링합니다. * **Page Shield & Zaraz Events:** 사이트 내 자바스크립트의 무단 변경을 감시하고 제3자 스크립트의 데이터 상호작용을 감사하여 클라이언트 측 보안과 개인정보 보호를 강화합니다. ### 계정(Account) 기반의 내부 및 제로 트러스트 로그 * **Access & Gateway Logs:** 사용자의 신원 기반 인증 이벤트를 추적하고, 네트워크 전체(DNS/HTTP/L3)의 트래픽을 모니터링하여 섀도우 IT나 악성 페이로드 다운로드를 탐지합니다. * **Magic IDS & IPSec:** 네트워크 계층(L3/L4)에서 침입 탐지 시그니처를 대조하여 알려진 익스플로잇 패턴이나 터널 상태, BGP 라우팅 변경 등을 감시합니다. * **Device Posture & DEX:** 연결된 기기의 보안 준수 상태를 확인하고, 사용자 관점의 성능 지표를 통해 보안 사고와 단순 성능 저하를 구분합니다. * **CASB & Email Security:** SaaS 애플리케이션(Google Drive, MS 365 등)의 설정 오류와 데이터 노출 위험을 진단하고, 게이트웨이 단계에서 피싱 및 이메일 기반 공격 유입을 추적합니다. ### 단계별 공격 탐지 및 포렌식 활용 * **정찰 단계(Reconnaissance) 탐지:** `http_requests` 로그에서 특정 IP가 401, 403, 404 상태 코드를 과도하게 생성하거나 `/.env`, `/wp-admin` 같은 민감한 경로에 접근하는 패턴을 쿼리하여 스캐닝 도구를 식별합니다. * **네트워크 계층 분석:** `magic_ids_detections` 로그를 사용하여 단일 소스 IP가 짧은 시간 내에 여러 포트에서 시그니처 기반 탐지를 유발하는지 분석함으로써 Nmap 스캔이나 SYN 스텔스 스캔을 파악합니다. * **내부 이동 추적:** 자격 증명이 탈취된 경우, `Access` 및 `Audit` 로그를 통해 공격자가 내부 네트워크에서 이동한 경로와 변경한 구성 설정을 추적하여 피해 범위를 확정합니다. 보안 팀은 Log Explorer를 활용해 외부에서 유입되는 정찰 활동부터 내부망에서의 수평 이동(Lateral Movement)에 이르기까지 공격의 전 과정을 단일 플랫폼에서 시각화할 수 있습니다. 특히 다양한 로그 소스를 상호 참조함으로써 개별적으로는 무해해 보이는 활동들이 결합되어 발생하는 정교한 보안 위협을 효과적으로 차단할 것을 권장합니다.

zero-trustcloudflarenetwork-securityhttp-requests+4

cloudflare2026년 3월 9일

복잡성은 선택입니다. SASE (새 탭에서 열림)

제로 트러스트 및 SASE(Secure Access Service Edge) 아키텍처로의 전환은 더 이상 수년이 걸리는 고통스러운 과정이 아니며, 클라우드플레어는 이를 단 몇 주 만에 완료할 수 있는 '선택의 영역'으로 바꾸고 있습니다. Cloudflare One 플랫폼을 통해 복잡한 수동 설정과 레거시 장비의 한계를 극복함으로써, 기업은 기술 부채와 보안 공백을 최소화하고 신속하게 안전한 AI 환경을 구축할 수 있습니다. ### 획기적인 구축 기간 단축: 18개월에서 6주로 * 기존 레거시 SASE 제품을 대규모 조직에 배포하는 데는 통상 18개월이 소요되지만, Cloudflare One을 활용하면 이를 4~6주로 대폭 단축할 수 있습니다. * 복잡한 '마법' 같은 기술 대신 전기나 수도처럼 설치 후 관리가 거의 필요 없는 '노터치(no-touch)' 방식의 보안 인프라를 제공합니다. * 이를 통해 CIO는 장기간의 기술 부채에서 벗어나 비즈니스 본연의 가치 창출에 집중할 수 있는 환경을 마련하게 됩니다. ### 레거시 마이그레이션 실패 원인 분석 및 해결 * 기존 마이그레이션은 단순 하드웨어 교체로 접근하여 데이터가 여러 검사 클러스터를 거치며 발생하는 '트롬본 효과(지연 현상)'와 복잡한 서비스 체이닝 문제를 야기했습니다. * 클라우드플레어는 보안 정책을 물리적 네트워크에서 분리하여 세 가지 핵심 요소를 통해 전환 속도를 높입니다. * **ID 중심의 온램프:** 네트워크 세그먼트를 재구축하는 대신 기존 ID 공급자(IdP) 그룹을 사용하여 액세스를 정의합니다. * **통합 정책 엔진:** SWG(보안 웹 게이트웨이)와 ZTNA(제로 트러스트 네트워크 액세스)를 단일 통과 방식으로 처리하여 관리자의 동기화 수고를 덜어줍니다. * **클라우드 네이티브 커넥터:** `cloudflared`와 같은 경량 데몬을 사용하여 인바운드 방화벽 포트를 열지 않고도 즉각적인 연결을 구현합니다. ### 유연하고 프로그래밍 가능한 확장형 에지 * 고정된 GUI 환경에서 벗어나 소프트웨어 정의 기반의 구성 가능한 플랫폼을 제공하여 특수한 업무 워크플로우를 수용합니다. * 특정 개발팀이 사용하는 Arch Linux와 같은 비표준 환경에서도 맞춤형 패키징(PKGBUILD 등)을 통해 기기 상태 점검(디스크 암호화, 방화벽 상태 등)을 일관되게 적용할 수 있습니다. * 이러한 유연성은 조직 전체의 보안 태세를 유지하면서도 특정 기술 요구 사항을 충족할 수 있게 합니다. ### 안전한 AI 도입을 위한 통합 보안 체계 * SWG의 역할이 단순 URL 차단에서 LLM(대규모 언어 모델)으로 흐르는 데이터 제어로 진화함에 따라, AI 보안 스위트를 통합적으로 제공합니다. * **Shadow AI 가시성:** 대시보드를 통해 네트워크 내에서 사용되는 미승인 타사 AI 도구를 즉시 발견하고 분류합니다. * **AI 신뢰 점수 및 DLP:** 규정 준수 포스처에 따라 AI 모델별로 등급을 매기고, DLP(데이터 손실 방지) 기능을 통해 민감한 소스 코드나 개인정보가 AI 학습 데이터로 유입되는 것을 차단합니다. * **AI용 방화벽:** 외부로 노출된 LLM 엔드포인트를 자동으로 식별하고 프롬프트 인젝션 등의 공격을 차단하여 자체 구축한 AI 앱을 보호합니다. 급변하는 비즈니스 환경에서 보안 마이그레이션의 속도는 곧 경쟁력입니다. 기업은 복잡한 하드웨어 중심의 레거시 방식에서 벗어나, ID 중심의 통합 클라우드 보안 플랫폼을 도입함으로써 제로 트러스트 전환과 안전한 AI 활용이라는 두 마리 토끼를 동시에 잡아야 합니다.

zero-trustdatabase-designcloudflarepostgresql+4

cloudflare2026년 3월 4일

부팅부터 로그인까지 빈틈없는 (새 탭에서 열림)

Cloudflare는 원격 접속 보안의 사각지대를 제거하기 위해 '필수 인증(Mandatory Authentication)'과 '자체 다중 인증(MFA)'이라는 두 가지 새로운 도구를 출시했습니다. 이 기능들은 기기 부팅 시점부터 로그인까지 발생하는 보안 공백을 메워주며, 기존 신뢰 엔진의 한계를 보완하여 지속적인 보안 가동 상태를 유지합니다. 이를 통해 기업은 사용자 편의성을 저해하지 않으면서도 보안 사고 발생 시 피해 범위를 최소화하는 제로 트러스트 환경을 구축할 수 있습니다. ### 설치와 인증 사이의 보안 공백 해소 Cloudflare One Client가 MDM을 통해 설치되었더라도 사용자가 아직 인증하지 않았거나 세션이 만료된 경우, 기기는 가시성 밖의 '어두운 모퉁이'에 놓이게 됩니다. '필수 인증' 기능은 이러한 위험을 다음과 같이 해결합니다. * **기본 인터넷 차단:** 사용자가 활발하게 인증되지 않은 상태에서는 시스템 방화벽을 사용하여 기본적으로 모든 인터넷 트래픽을 차단합니다. * **인증 전용 예외 허용:** 기기 클라이언트의 인증 흐름에 필요한 특정 프로세스 트래픽만을 예외적으로 허용하여 인증을 유도합니다. * **사용자 가이드 제공:** 사용자가 인증 버튼을 직접 찾아 헤매지 않도록 인증 프로세스를 안내하는 프롬프트를 노출합니다. * **플랫폼 지원:** 해당 기능은 Windows용 Cloudflare One 클라이언트에서 우선 지원되며, 향후 다른 플랫폼으로 확대될 예정입니다. ### IdP 의존성을 탈피한 독자적 다중 인증 Okta나 Entra ID 같은 단일 인증(SSO) 서비스는 공격자의 주요 타겟이며, 세션 하이재킹 등에 취약할 수 있습니다. Cloudflare의 독립적 MFA는 네트워크 에지에서 작동하는 '단계별(Step-up) MFA' 역할을 수행합니다. * **이중 신뢰 구조:** 기본 IdP 자격 증명이 침해되더라도 Cloudflare가 관리하는 별도의 인증 계층을 통과해야 하므로 중요 자산에 대한 접근을 효과적으로 방어합니다. * **다양한 인증 수단:** 생체 인식(Windows Hello, Apple Touch ID/Face ID), 보안 키(WebAuthn, FIDO2), 인증 앱을 통한 TOTP 등 현대적인 인증 방식을 모두 지원합니다. * **세밀한 정책 제어:** 채팅 앱은 낮은 수준의 MFA를 허용하고 소스 코드 저장소는 물리 보안 키를 요구하는 등 애플리케이션별로 차등화된 정책을 적용할 수 있습니다. * **레거시 및 외부 협력자 관리:** MFA를 지원하지 않는 오래된 앱에 인증 계층을 추가하거나, 개인 이메일을 사용하는 외부 계약자에게도 강력한 인증을 강제할 수 있습니다. ### 실용적인 권장 사항 기업 보안 책임자는 '필수 인증'을 통해 관리형 기기가 항상 정책의 통제하에 있도록 설정하고, 민감한 내부 데이터베이스나 인프라 접근에는 Cloudflare의 독립적 MFA를 추가로 적용하는 것이 좋습니다. 이러한 방식은 단일 패스워드 유출이 전체 침해로 이어지는 것을 방지하며, 관리자에게는 정책 이행에 대한 확실성을, 사용자에게는 자동화된 보안 경험을 제공합니다.

zero-trustcloudflarenetwork-securitymulti-factor-authentication+3