Cloudflare

196 개의 포스트

blog.cloudflare.com

태그로 필터

cloudflare5분 읽기큐레이션 요약

BGP AS PATH의 첫 번째 AS 강제하기

최근 BGP 하이재킹에서 공격자는 사용하지 않는 ASN을 이용해 실제 자신의 ASN을 AS_PATH에서 제거하고, 존재하지 않는 네트워크 경로를 위조하고 있다. RPKI-ROV나 ASPA만으로는 이런 공격을 완전히 막기 어려우므로, 고객이 광고한 경로의 첫 번째 ASN이 실제 BGP 피어의 ASN과 일치하는지 검증하는 **First AS 검사**가 필요하다. 통신사업자는 이 검사를 강제함으로써 위조된 AS_PATH가 상위 네트워크로 전파되는 것을 차단할 수 있다. ## 위조된 AS_PATH를 이용한 경로 하이재킹 - Spamhaus가 보고한 여러 하이재킹 사례에서 공격자는 사용되지 않는 ASN을 활용해 비정상적인 AS_PATH를 만들었다. - 공격 목적은 다음과 같다. - 실제 공격자의 ASN을 경로에서 숨김 - 자신이 해당 prefix의 발신자인 것처럼 위장 - 트래픽을 공격자가 원하는 경로로 유도 - 트래픽 가로채기 또는 추가 공격 수행 - BGP UPDATE의 AS_PATH는 일반적으로 경로를 구성하는 네트워크들의 순서를 나타내지만, BGP 자체는 기본적으로 이 값을 신뢰한다. - 따라서 공격자가 AS_PATH를 조작해도 중간 네트워크가 별도 검증을 하지 않으면 해당 경로가 정상 경로처럼 전파될 수 있다. ## Orange S.A. prefix 사례 - Orange S.A.의 `90.98.0.0/15` prefix에 대해 다음과 같은 경로가 관측됐다. ```text 48237 1299 199524 270118 17072 41128 ``` - AS1299는 Arelion의 Tier 1 네트워크이므로, 경로 오른쪽에 있는 ASN들은 일반적으로 고객-프로바이더 관계를 나타낸다. - 이 경로를 그대로 해석하면 다음과 같은 비정상 관계가 된다. - AS41128: Orange France가 보유하지만 사용되지 않는 ASN - AS17072: 주로 멕시코에서 운영되는 ISP - AS270118: 멕시코 소재 호스팅 사업자 - AS199524: 글로벌 피어링 사업자인 Gcore - 즉, 사용되지 않는 Orange ASN이 멕시코 ISP와 호스팅 사업자를 거쳐 Gcore와 Tier 1 사업자에 연결된 것처럼 보인다. - 이 관계는 현실적으로 매우 부자연스럽기 때문에 AS_PATH가 공격자에 의해 위조됐다고 판단할 수 있다. ## Cloudflare ASN을 포함한 또 다른 사례 - `47.1.0.0/16`, `47.2.0.0/16` 하이재킹에서는 다음 경로가 관측됐다. ```text 199524 270118 17072 13335 36429 ``` - 여기에는 Cloudflare의 ASN인 `13335`가 포함돼 있었지만, Cloudflare는 Charter가 보유한 현재 미사용 ASN `36429`와 직접적인 인접 관계가 없다고 확인했다. - 따라서 Cloudflare ASN은 실제 경로에 참여한 것이 아니라 공격자가 만든 가짜 상위 경로에 포함된 것으로 보인다. - 실제 트래픽은 멕시코 ISP나 Cloudflare를 거치지 않고 Gcore의 시카고 피어링 네트워크 뒤쪽으로 전달됐다. - 이 사례에서는 왼쪽에서 처음으로 신뢰할 수 있는 공통 ASN인 Gcore의 `199524`까지는 실제 전파 경로일 가능성이 높고, 그 오른쪽의 나머지 경로는 위조된 것으로 추정된다. ## 공격자가 사용한 것으로 추정되는 방식 공격자는 다음 순서로 하이재킹을 수행한 것으로 분석된다. - 사용되지 않거나 “parked” 상태인 prefix를 직접 BGP에 광고한다. - 자신의 로컬 ASN을 AS_PATH에서 완전히 제거한다. - 실제로 존재하지 않는 고객-프로바이더 관계를 포함한 가짜 AS_PATH를 구성한다. - 해당 경로를 Gcore와 같은 상위 네트워크에 전달한다. - 상위 네트워크가 고객 ASN과 AS_PATH의 첫 ASN을 검증하지 않으면 경로가 수락된다. - 이후 해당 경로가 상위 프로바이더와 피어를 통해 인터넷 전체로 전파된다. ## First AS 검사의 역할 - BGP 피어가 경로를 광고할 때 AS_PATH의 첫 번째 ASN은 일반적으로 해당 피어의 ASN이어야 한다. - 예를 들어 AS64502가 AS64501로부터 경로를 받았다면, 경로의 첫 ASN이 AS64501인지 확인해야 한다. - 이 검사가 활성화돼 있으면 공격자가 자신의 ASN을 제거한 뒤 다른 ASN으로 시작하는 경로를 광고할 수 없다. - First AS 검사는 다음 공격을 차단하는 데 유용하다. - 자신의 ASN을 AS_PATH에서 제거하는 위조 - 다른 네트워크를 최초 발신자인 것처럼 가장하는 공격 - 가짜 상위 경로를 이용한 트래픽 유인 - BGP의 AS_PATH는 경로 선택과 루프 방지에도 사용된다. - 라우터는 AS_PATH 길이와 정책 등을 바탕으로 최적 경로를 선택한다. - 이미 자신의 ASN을 거친 경로는 루프 방지를 위해 거부할 수 있다. - 운영자는 특정 ASN을 우회하거나 선호하도록 AS_PATH를 정책에 활용할 수 있다. - 하지만 AS_PATH는 원래 신뢰 기반으로 설계됐기 때문에 AS prepend처럼 정상적인 조작도 가능하고, 공격자가 경로를 줄이거나 위조하는 것도 가능하다. ## RPKI-ROV와 ASPA만으로는 부족한 이유 - RPKI ROA는 특정 prefix를 어떤 ASN이 원점(origin)으로 광고할 수 있는지 인증한다. - ASPA는 특정 ASN의 유효한 프로바이더 목록을 선언한다. - 그러나 공격자가 다음 조건을 만족하면 기존 검증을 우회할 가능성이 있다. - RPKI-ROV상 유효한 origin ASN을 AS_PATH에 포함 - 합법적인 ASPA 상위 ASN을 경로에 포함 - 자신의 ASN은 AS_PATH에서 제거 - 예시에서는 AS64506이 ROA를 만들고, ASPA에 유효한 프로바이더로 AS64503을 등록했다. - 공격자 AS64505가 자신의 ASN을 제거하고 AS64506에서 시작하는 것처럼 광고하면, First AS를 검사하지 않는 AS64502는 이를 수락할 수 있다. - 결과적으로 경로가 RPKI-ROV상 유효하고 더 짧은 경로로 보이면서 AS64506으로 향하는 트래픽을 가로챌 수 있다. - 따라서 RPKI와 ASPA는 중요한 보안 수단이지만, 피어 ASN과 AS_PATH 첫 ASN의 일치 여부를 확인하는 First AS 검사를 대체하지 못한다. ## 실용적인 권고 - 모든 BGP 세션에서 First AS 검사를 활성화하고 강제해야 한다. - 고객 경로를 수신할 때 다음을 검증하는 것이 바람직하다. - AS_PATH 첫 ASN이 실제 고객 또는 피어 ASN과 일치하는지 - 고객이 광고할 수 있는 prefix인지 - RPKI-ROV 상태가 유효한지 - ASPA상 프로바이더 관계가 허용되는지 - RPKI-ROV와 ASPA는 origin 및 경로 관계 검증에 사용하고, First AS 검사는 자신의 ASN을 숨긴 경로 위조를 차단하는 방어선으로 함께 운용해야 한다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

코어 유닛 부팅 시간을 몇 시간에서 몇 분으로 단축한 방법

Cloudflare의 핵심 서버가 펌웨어 업데이트 후 부팅에 최대 4시간 걸린 원인은 펌웨어 자체의 치명적 오류가 아니라, UEFI가 네트워크 부트 인터페이스를 순차적으로 탐색하며 각 실패마다 긴 타임아웃을 기다렸기 때문이었다. 서버는 실제로 사용할 IPv6 HTTPS 부트에 도달하기 전에 IPv4 HTTPS와 IPv4 iPXE를 반복 시도했고, 이 과정이 여러 번의 재부팅에 누적됐다. Cloudflare는 하드웨어별 올바른 부트 인터페이스를 사전에 지정하고 설정 검증·재적용 절차를 추가해 이후 부팅 시간을 약 20분에서 1분 이하로 줄였다. ## 네트워크 부트 인터페이스의 역할 - 중앙 데이터센터의 Cloudflare 코어 서버는 운영체제를 로컬 디스크가 아니라 네트워크를 통해 부팅하는 경우가 많다. - 주요 네트워크 부트 방식은 다음과 같다. - **PXE**: 서버가 네트워크에서 부트 환경을 받아오는 전통적인 방식 - **UEFI HTTPS Boot**: UEFI 펌웨어가 HTTPS를 통해 운영체제 파일을 직접 다운로드하는 방식 - Cloudflare는 오픈소스 네트워크 부트 펌웨어인 **iPXE**를 사용한다. - HTTP·HTTPS를 지원한다. - 하드웨어 구성별 프로비저닝과 자동화된 서버 배포를 스크립트로 처리할 수 있다. - 서버와 네트워크 카드의 종류, 용도에 따라 실제로 사용해야 하는 네트워크 부트 인터페이스가 달랐다. ## 원인: 모든 인터페이스를 순차 검색한 선형 탐색 - 펌웨어 업데이트 이후 서버가 운영체제 시작 단계에 도달하지 못하고 장시간 멈췄다. - 직렬 콘솔을 확인한 결과 POST와 하드웨어 초기화는 정상적으로 완료됐다. - 문제는 네트워크 부트 단계에서 발생했다. - IPv4 HTTPS Boot 시도 - 약 5분간 타임아웃 대기 - IPv4 iPXE 시도 - 다시 타임아웃 대기 - 같은 탐색을 반복 - 마지막에 실제로 성공하는 IPv6 HTTPS Boot 실행 - 각 실패한 인터페이스마다 약 5분이 소요됐다. - 올바른 인터페이스에 도달하기 전 네 번의 시도가 누적되면서 한 번의 부팅에 약 20분이 낭비됐다. - 펌웨어 업그레이드는 구성요소별로 여러 차례 재부팅을 필요로 하므로, 서버 한 대당 대기 시간이 거의 4시간까지 늘어났다. - 신규 서버도 첫 부팅부터 같은 타임아웃을 겪어 전체 배포와 유지보수 일정이 지연됐다. ## 해결 방향: 사용할 부트 인터페이스를 미리 지정 - 핵심 해결책은 UEFI가 모든 인터페이스를 추측하며 검색하지 않도록, 하드웨어와 사용 사례에 맞는 네트워크 부트 인터페이스 순서를 미리 선언하는 것이었다. - Cloudflare는 부트 자동화 흐름을 다음 세 단계로 나눠 관리했다. - UEFI 펌웨어 초기화 - PXE 기반 프리부트 단계 - 커널 시작 - 네트워크 인터페이스 순서를 프리부트 PXE 단계 초기에 설정하도록 자동화 순서를 변경했다. - 그 결과 펌웨어 업그레이드 과정에서 반복되던 네트워크 부트 탐색 시간을 줄여 전체 작업 시간을 약 한 시간 단축했다. - 이후의 일반적인 재부팅은 기존 약 20분에서 1분 이하로 감소했다. ## 레거시 UEFI와 설정 초기화 문제 - 부트 순서를 지정하는 과정에는 두 가지 제약이 있었다. - 오래된 UEFI 버전에서는 부트 순서 설정 자체가 지원되지 않았다. - UEFI 펌웨어를 업데이트하면 부트 순서 설정이 초기화되는 경우가 있었다. - 이를 해결하기 위해 자동화 과정에 **상태 검증 단계**를 추가했다. - 설정 변경 후 실제 펌웨어 상태를 확인한다. - 설정이 사라졌거나 변경되었으면 원하는 값을 다시 적용한다. - 필요한 경우 재부팅해 새 설정을 적용한다. - 첫 부팅에는 검증과 재적용 때문에 약간의 추가 시간이 들 수 있지만, 이후 부팅마다 반복되는 긴 인터페이스 탐색을 제거할 수 있었다. ## 벤더가 비활성화한 네트워크 부트 순서 설정 - 자동화 프로그램이 네트워크 부트 우선순위를 읽지 못하는 또 다른 문제가 있었다. - UEFI의 네트워크 부트 설정은 `EFI_IFR_REF3` 구조로 관리되고 있었으며, 필요할 때까지 실제 데이터가 생성되지 않는 **지연 로딩(lazy loading)** 방식이었다. - 이 구조는 BIOS 부팅 시간을 줄이는 데는 도움이 되지만, GUI에서 해당 항목을 직접 열지 않으면 프로그램이 설정 정보를 발견할 수 없게 만들었다. - 그 결과 자동화 도구의 펌웨어 스캔에서 “Network Boot Interface” 항목이 보이지 않았다. - Cloudflare는 하드웨어 벤더와 협력해 고정된 “Boot Order Module”에서 관련 토큰을 활성화했다. - 이 설정은 GUI를 수동으로 열지 않아도 부팅 과정에서 네트워크 부트 인터페이스가 검색·초기화되도록 만들었다. 실용적으로는 네트워크 부트를 사용하는 서버에서 모든 인터페이스를 무조건 탐색하게 두기보다, 하드웨어별 유효한 인터페이스를 명시하고 부팅 후 설정이 유지되는지 자동 검증하는 것이 중요하다. 특히 펌웨어 업데이트처럼 여러 번 재부팅하는 작업에서는 인터페이스 하나당 타임아웃이 전체 유지보수 시간을 크게 늘릴 수 있으므로, UEFI 설정의 지속성·레거시 호환성·벤더별 표현 차이까지 함께 자동화해야 한다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

Cloudflare의 데이터 플랫폼과 그 위에 구축한 AI 에이전트 이야기

Cloudflare는 여러 데이터베이스와 스트림에 흩어진 데이터를 하나의 SQL 인터페이스로 통합하기 위해 데이터 레이크하우스 플랫폼 **Town Lake**를 구축했다. Town Lake는 신선하고 정확한 원천 데이터와 빠른 분석용 샘플 데이터를 함께 제공하며, 권한 관리·PII 탐지·감사 기능을 기본으로 포함한다. 그 위에 자연어로 질문하면 감사 가능한 답을 제공하는 AI 데이터 에이전트 **Skipper**를 구축해 데이터 접근성을 높이려 했다. ## 데이터 파편화와 접근성 문제 - Cloudflare는 초당 10억 건이 넘는 이벤트를 처리하고 330개 이상의 도시, 120개 이상의 국가에서 네트워크를 운영한다. - 데이터가 다음과 같은 다양한 시스템에 분산되어 있었다. - Postgres: 계정 및 업무 메타데이터 - ClickHouse: 분석 이벤트 - BigQuery: 집계 데이터 - R2: 원시 로그 - Kafka: 실시간 이벤트 스트림 - 시스템마다 인증 방식, 쿼리 언어, 보존 기간이 달라 간단한 질문에도 여러 시스템을 알고 있어야 했다. - 올바른 테이블과 조인 방법이 조직 내 암묵지에 의존했다. - 예를 들어 ClickHouse의 사용량 테이블과 Postgres의 고객 차원 테이블을 연결하려면 별도의 고객 ID 변환 규칙을 알아야 했다. - 기존 분석 파이프라인은 초당 7억 건 이상의 이벤트를 처리하기 위해 데이터를 샘플링했다. - 대시보드에는 적합하지만 청구 금액 계산이나 보안 조사처럼 정확한 전체 데이터가 필요한 작업에는 부적합했다. - 일부 내부 리포팅 시스템은 외부 업체와 다른 클라우드에 의존하고 있어 비용과 운영상 종속성도 발생했다. ## 구축 목표 - 적절한 권한과 업무상 필요가 있는 모든 직원이 Cloudflare 데이터를 한곳에서 조회할 수 있도록 했다. - 사용 목적에 따라 서로 다른 데이터 품질을 제공하려 했다. - 청구·보안 조사: 신선하고 정확한 비샘플링 데이터 - 대시보드·탐색: 빠른 응답을 위한 다운샘플링 데이터 - PII를 자동으로 식별하고 민감한 테이블은 기본적으로 제한했다. - 모든 데이터 접근을 감사할 수 있도록 하고, 권한을 일정 기간 동안만 부여하도록 설계했다. - R2, Workers, Cloudflare Access, Workflows 등 Cloudflare 자체 제품 위에 플랫폼을 구축했다. - 최종적으로 SQL을 몰라도 자연어로 데이터를 조회할 수 있는 인터페이스를 제공하는 것이 목표였으며, 이것이 Skipper로 이어졌다. ## Town Lake의 데이터 레이크하우스 구조 Town Lake는 오브젝트 스토리지에 저장된 데이터를 쿼리 엔진으로 조회하고, 메타데이터 계층을 통해 데이터베이스처럼 사용하는 레이크하우스 구조다. - **Apache Trino** - 통합 쿼리 엔진으로 사용된다. - 하나의 SQL 쿼리에서 Postgres, ClickHouse, R2의 Iceberg 테이블을 함께 조인할 수 있다. - 필터를 ClickHouse로 푸시하고, Postgres의 계정 차원 데이터와 R2의 청구 집계 데이터를 결합하는 식으로 쿼리를 최적화한다. - **R2 Data Catalog와 Apache Iceberg** - 차갑거나 따뜻한 데이터를 R2에 저장한다. - Iceberg의 스키마 변경, 시점 조회(time travel), 파티션 변경, 데이터 컴팩션 기능을 활용한다. - 오래된 데이터는 분 단위에서 시간 단위, 다시 일 단위로 집계해 저장 비용을 줄인다. - Parquet 파일을 R2에 저장하면 동일한 데이터를 OLAP 데이터베이스에 보관하는 것보다 비용이 낮다. - **DataHub** - 테이블, 컬럼, 소유 팀, 데이터 계보(lineage), 용어집 정보를 관리한다. - 사용자가 특정 테이블의 의미를 물으면 컬럼 설명, 담당 팀, 상위 입력 테이블, 하위 소비 테이블까지 제공한다. ## 권한 관리와 데이터 거버넌스 - **Lifeguard**가 데이터 접근 제어를 담당한다. - 접근 규칙은 D1에 저장하고, 내부 접근 관리 시스템에서 사용자·그룹 정보를 동적으로 가져온다. - 이 정보를 결합해 JSON 정책을 생성하고 Trino가 HTTP를 통해 읽도록 한다. - Skipper와 Gateway에도 기본적인 권한 정보를 전달해 쿼리가 실행된 뒤가 아니라 진입 단계에서 접근을 차단할 수 있다. - 권한을 업무 목적과 기간에 맞춰 부여함으로써 민감 데이터에 대한 불필요한 상시 접근을 줄인다. - 데이터 접근 기록을 남겨 누가 어떤 데이터에 접근했는지 감사할 수 있도록 했다. ## PII 자동 탐지 - **Skimmer**는 테이블의 모든 컬럼을 지속적으로 검사하는 PII 탐지 스캐너다. - 각 컬럼에서 행을 샘플링하고 Workers AI를 이용해 PII 포함 여부를 분류한다. - 이를 통해 데이터 카탈로그에 민감도 정보를 자동으로 반영하고, 민감한 테이블이나 컬럼의 기본 접근 정책을 강화할 수 있다. ## 자연어 데이터 에이전트 Skipper - Skipper는 Town Lake 위에서 동작하는 AI 데이터 에이전트다. - 사용자가 영어로 질문하면 관련 데이터와 메타데이터를 찾아 SQL 기반 답변을 생성한다. - 데이터 위치, 테이블 구조, 조인 관계, 권한을 사용자가 직접 알 필요를 줄이는 것이 목적이다. - 자연어 질의의 예시는 다음과 같다. - 최근 분기의 매출 기준 상위 100개 고객 조회 - 특정 ASN에서 발생한 고위험 Bot Management 이벤트 검색 - 일정 금액 이상 지출한 고객의 청구 지원 티켓 분석 - 답변은 단순한 생성형 응답이 아니라 데이터에 근거하고 감사 가능한 형태여야 한다는 점이 중요하다. ## 실용적인 시사점 데이터 플랫폼을 구축할 때는 저장소 통합만으로는 충분하지 않다. 통합 쿼리 엔진, 메타데이터 카탈로그, 데이터 계보, 세분화된 권한 관리, PII 탐지, 감사 기능을 함께 설계해야 데이터가 실제 조직 전체에서 활용된다. 또한 정확성이 필요한 업무와 속도가 중요한 분석 업무에 동일한 데이터 처리 방식을 적용하지 않고, 목적에 따라 원천 데이터와 샘플 데이터를 구분하는 전략이 효과적이다.

원문 읽기(새 탭에서 열림)
cloudflare3분 읽기큐레이션 요약

이란의 인터넷이 부분적으로 복구됐음을 Cloudflare Radar 데이터가 보여준다

이란의 인터넷은 약 3개월간 이어진 전국적 차단 이후 2026년 5월 26일부터 부분적으로 복구되기 시작했다. Cloudflare Radar는 트래픽과 DNS 요청이 크게 증가했지만, 최대치가 차단 이전 활동량의 40%에 그쳐 완전한 복구는 아니라고 분석했다. 특히 테헤란과 주요 통신망에 회복이 집중됐고, IPv6 연결은 여전히 사실상 중단된 상태다. ## 첫 번째 전국 인터넷 차단 - 2026년 1월 8일경 첫 번째 전국적 인터넷 차단이 시작됐다. - 이란발 트래픽은 거의 0에 가까운 수준으로 떨어졌다. - 1월 21일과 25일에 일시적으로 트래픽이 회복됐지만 곧 다시 감소했다. - 이후 1월 27일부터 비교적 완전한 회복이 나타났다. ## 두 번째 장기 차단 - 미국과 이스라엘의 공격이 시작된 2월 28일, 두 번째 전국적 차단이 발생했다. - Cloudflare Radar는 현지 시간 오전 10시 30분경부터 트래픽이 급격히 감소한 것을 관측했다. - 트래픽은 기존 수준의 1% 미만으로 떨어졌으며, 소량의 웹·DNS 트래픽만 외부로 전달됐다. - 이 차단은 약 3개월 동안 지속됐다. ## 5월 26일부터 나타난 부분 복구 - 5월 26일 11:00 UTC경부터 웹 트래픽과 DNS 요청이 동시에 증가했다. - 11:45 UTC에 짧은 급증이 있었고, 12:00 UTC 이후에는 꾸준한 증가세가 나타났다. - 직전 일주일과 비교하면 Cloudflare 네트워크를 통과한 데이터량이 약 15배 증가했다. - 밤 시간대에는 트래픽이 감소하고, 5월 27일 현지 오전 6시 30분경부터 다시 증가하는 일중 변동 패턴도 관측됐다. - 이는 실제로 더 많은 사용자가 웹사이트와 온라인 서비스에 접속하기 시작했다는 신호다. ## 테헤란과 주요 통신사에 집중된 회복 - 새로 증가한 HTTP 요청의 91.6%가 수도 테헤란에서 발생했다. - 다른 지역에서도 소폭 증가했지만 테헤란만큼 뚜렷하지 않았다. - Iran TCI, IranCell, RighTel, MCCI 등 주요 인터넷 사업자에서도 트래픽 증가가 나타났다. - Cloudflare는 각 통신망을 ASN(자율 시스템 번호) 단위로 구분해 트래픽 변화를 측정했다. ## DNS 요청 증가가 보여주는 접속 회복 - Cloudflare 공개 DNS 리졸버인 `1.1.1.1`에 대한 요청도 크게 증가했다. - DNS 요청은 사용자가 웹사이트나 온라인 서비스를 찾을 때 발생하므로, 인터넷 이용자 활동의 회복을 보여주는 지표가 된다. - 트래픽 증가와 DNS 요청 증가는 단순한 네트워크 신호가 아니라 실제 사용자 접속이 늘고 있음을 뒷받침한다. ## 아직 제한적인 복구 수준 - 5월 26일 트래픽 최고치는 2026년 관측된 차단 이전 최대 활동량의 약 40%에 불과했다. - 따라서 이번 변화는 전국 인터넷의 완전한 정상화가 아니라 부분적인 복구로 해석된다. - 1월에도 잠시 회복된 뒤 다시 차단된 사례가 있었기 때문에, 현재의 증가세가 일시적일 가능성도 있다. - 향후 며칠간 트래픽이 계속 증가해 차단 이전 기준선에 접근하는지가 중요하다. ## IPv6는 여전히 사실상 중단 - 이란의 발표된 IPv6 주소 공간과 IPv6 트래픽은 여전히 거의 0에 가까운 상태다. - 반면 IPv4 주소 공간 발표는 두 차례의 차단 기간에도 비교적 안정적으로 유지됐다. - IPv4 주소가 글로벌 라우팅 테이블에서 제거되지 않았다는 점은, 이번 차단이 단순한 라우팅 철회 방식이 아니었음을 시사한다. - 애플리케이션 필터링이나 허용 목록(whitelisting) 같은 방식으로 특정 서비스와 연결을 제한했을 가능성이 있다. 이번 변화는 이란의 인터넷이 회복 국면에 들어섰다는 중요한 신호지만, 아직 정상화로 보기는 어렵다. 향후 트래픽 규모, 지역별 분포, IPv6 주소 공간의 복구 여부를 함께 관찰해야 하며, 사용자는 서비스 접근이 다시 제한될 가능성도 고려해야 한다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

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 정책으로 단계적으로 제한하는 접근이 적합하다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

Cloudflare에서 Claude Managed Agents 발표

Cloudflare와 Anthropic은 Claude Managed Agents의 에이전트 루프는 Anthropic에서 실행하고, 코드 실행·샌드박스·네트워크 연결은 Cloudflare에서 처리하는 통합 환경을 공개했습니다. 이를 통해 보안 프록시, 프라이빗 서비스 연결, 샌드박스 관측성, 브라우저 제어, 이메일, 사용자 정의 도구를 기본 제공하면서도 인프라를 직접 통제할 수 있습니다. 특히 작업 특성에 따라 전체 Linux microVM과 가벼운 V8 isolate를 선택해 비용과 확장성을 조절할 수 있다는 점이 핵심입니다. ## Claude Managed Agents의 구조 - Claude Managed Agents는 Anthropic 플랫폼에서 에이전트를 정의하고 실행하는 관리형 환경입니다. - 에이전트는 파일 읽기, 명령 실행, 웹 브라우징, 코드 실행 등을 수행할 수 있습니다. - 프롬프트 캐싱, 대화 압축(compaction), 에이전트 실행 최적화 기능이 내장되어 있습니다. - 기존에는 에이전트 루프와 실행 인프라를 모두 Anthropic 환경에서 운영했지만, 이제 실행 환경을 Cloudflare 등 외부 인프라로 분리할 수 있습니다. - Anthropic이 이를 “두뇌와 손의 분리”라고 설명하듯이: - **두뇌**: Claude의 에이전트 루프 - **손**: 코드 실행, 파일 시스템, 명령 도구, 네트워크 연결을 담당하는 Cloudflare 환경 ## Cloudflare 기반 실행 환경 - Claude Agent가 세션을 시작하면 Cloudflare Workers 기반 컨트롤 플레인에 메시지를 보냅니다. - 컨트롤 플레인은 각 세션에 샌드박스를 할당해 다음 작업을 지원합니다. - 코드 실행 - 애플리케이션 개발 - CLI 도구 실행 - 파일 생성 및 수정 - 세션이 일시 중지되어도 상태가 자동으로 보존됩니다. - VM 기반 샌드박스는 다음과 같이 설정할 수 있습니다. - 인스턴스 크기 조정 - 실행 컨테이너 이미지 사용자 정의 - Cloudflare 대시보드에서 샌드박스 상태를 확인하고 로그를 조회할 수 있습니다. - 로그는 Datadog이나 Splunk 같은 외부 관측성 플랫폼으로 전송할 수 있습니다. - 기본 UI를 통해 실행 중인 샌드박스에 SSH로 접속하고 대화형 셸 세션을 사용할 수 있습니다. ## 기본 제공되는 통합 기능 - **보안 프록시** - 에이전트의 모든 외부 트래픽을 사용자 정의 프록시로 통과시킬 수 있습니다. - 샌드박스 외부에서 인증 정보를 주입해 에이전트가 비밀값을 직접 보지 못하게 할 수 있습니다. - 데이터 유출을 차단하고 외부 서비스와의 상호작용을 관찰할 수 있습니다. - **샌드박스 제어와 관측성** - 상세한 메트릭과 로그를 제공합니다. - 실행 중인 머신에 SSH로 접근할 수 있습니다. - 샌드박스 이미지를 직접 구성할 수 있습니다. - **프라이빗 서비스 연결** - 인터넷에 서비스를 공개하지 않고 내부 API나 데이터베이스에 연결할 수 있습니다. - **브라우저 제어** - 에이전트의 브라우저 세션을 기록하고 감사 추적을 남길 수 있습니다. - 세션 녹화와 human-in-the-loop 승인 흐름을 지원합니다. - **이메일** - 에이전트별 이메일 주소를 부여하고 이메일을 발송할 수 있습니다. - **사용자 정의 도구** - 별도의 인프라 없이 함수를 작성하고 배포해 에이전트 기능을 확장할 수 있습니다. ## microVM과 isolate를 통한 확장성 - 모든 에이전트에 전용 microVM을 할당하면 대규모 동시 실행에서 비용과 자원 낭비가 커질 수 있습니다. - Cloudflare는 두 가지 샌드박스 방식을 제공합니다. - **microVM 기반 샌드박스** - 완전한 Linux 환경을 제공합니다. - 애플리케이션 개발, Linux 기반 도구, 복잡한 코드 실행에 적합합니다. - Cloudflare Containers를 사용할 수 있습니다. - **V8 isolate 기반 샌드박스** - Dynamic Workers와 Codemode를 이용해 임의의 코드를 실행합니다. - 파일 시스템을 제공하면서도 전체 VM보다 가볍습니다. - 수 밀리초 단위로 부팅할 수 있어 비용과 시작 시간이 줄어듭니다. - 에이전트 설정에서 백엔드 유형으로 `isolate`를 선택하면 V8 isolate를 사용할 수 있습니다. - 수만 개 이상의 동시 에이전트가 필요한 경우 isolate 방식이 VM 기반보다 훨씬 높은 확장성을 제공할 수 있습니다. - 반대로 완전한 Linux 환경이나 강한 격리가 필요하면 microVM을 선택하는 것이 적합합니다. ## 보안과 네트워크 제어 - 에이전트가 조직 내부의 데이터와 서비스에 접근할수록 유용성은 높아지지만 보안 위험도 커집니다. - Cloudflare 샌드박스는 아웃바운드 프록시를 통해 외부 서비스와의 통신을 제어할 수 있습니다. - 프록시에서 동적으로 인증하고 비밀값을 요청에 삽입하면, 샌드박스와 에이전트가 실제 자격 증명을 직접 보유하지 않아도 됩니다. - 이를 통해 샌드박스와 외부 서비스 사이에 동적이고 사용자 정의 가능한 zero-trust 인증 구조를 구성할 수 있습니다. - 제공된 글은 이 보안 섹션이 “데이터 유출 방지” 설명 도중 중단되어 있어, 세부 구현이나 설정 방법까지는 확인할 수 없습니다. ## 실용적인 선택 기준 - 단순한 코드 실행과 대규모 동시성이 중요하면 **V8 isolate**를 우선 고려하는 것이 좋습니다. - Linux 도구, 애플리케이션 빌드, 장시간 실행되는 개발 작업이 필요하면 **microVM 또는 Containers**가 적합합니다. - 내부 시스템에 연결할 때는 프록시 기반 인증과 프라이빗 연결을 사용해 비밀값과 서비스를 샌드박스에 직접 노출하지 않는 구성이 권장됩니다. - 운영 환경에서는 Cloudflare 대시보드, 로그 외부 전송, 브라우저 세션 기록을 함께 활용해 에이전트 행동을 지속적으로 감사하는 것이 중요합니다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

프로젝트 글래스윙: Mythos가 우리에게 보여준 것

Mythos Preview는 단순히 취약점을 찾아내는 수준을 넘어, 여러 취약점을 연결해 실제 공격 경로를 구성하고 실행 가능한 증명 코드까지 생성하는 새로운 단계의 보안 도구로 평가된다. 그러나 모델의 자발적 거부는 일관되지 않으며, 탐색적 모델의 높은 오탐률 때문에 대규모 운영에는 별도의 안전장치와 검증·분류 체계가 필요하다. Project Glasswing의 핵심 교훈은 강력한 모델 자체뿐 아니라 이를 통제하고 결과를 검증하는 아키텍처가 함께 발전해야 한다는 점이다. ## Mythos Preview가 달라진 점 - Cloudflare는 Project Glasswing의 일환으로 Mythos Preview를 50개가 넘는 자체 저장소에 적용했다. - 이전 범용 프런티어 모델과의 단순한 성능 비교보다, Mythos가 실제로 수행하는 작업의 성격을 이해하는 것이 중요하다고 설명한다. - 기존 모델도 개별 버그를 발견하거나 영향도를 분석할 수 있었지만, 여러 조각을 하나의 공격으로 연결하는 단계에서 자주 멈췄다. ## 여러 취약점을 연결하는 공격 체인 - 실제 공격은 하나의 버그가 아니라 여러 취약점과 공격 원시 기능을 조합해 완성되는 경우가 많다. - 예를 들어: - use-after-free를 임의 메모리 읽기·쓰기 기능으로 전환 - 제어 흐름 탈취 - ROP(Return-Oriented Programming) 체인 구성 - 최종적으로 시스템 제어권 획득 - Mythos Preview는 낮은 심각도로 분류될 만한 개별 버그들을 결합해 더 심각한 실제 공격 경로를 추론할 수 있었다. - 이러한 추론 과정이 자동화된 스캐너보다는 숙련된 보안 연구자의 작업에 가깝게 나타났다는 점이 두드러졌다. ## 반복 실행을 통한 익스플로잇 증명 - Mythos Preview는 의심되는 취약점을 설명하는 데 그치지 않고, 이를 재현하는 코드를 직접 작성한다. - 생성한 코드를 격리된 scratch 환경에서 컴파일하고 실행해 예상한 동작이 발생하는지 확인한다. - 실패하면 오류 결과를 분석하고 가설을 수정한 뒤 다시 시도한다. - 이 반복 루프를 통해 단순한 “취약할 가능성”과 실제 악용 가능한 취약점을 구분한다. - 따라서 취약점 탐지와 익스플로잇 가능성 입증 사이의 간극을 모델 스스로 줄일 수 있다. ## 정당한 보안 연구에서의 모델 거부 - Project Glasswing에서 제공된 Mythos Preview에는 일반 공개 모델에 적용되는 추가 안전장치가 없었지만, 모델 자체적으로 일부 요청을 거부하는 경향이 나타났다. - 그러나 거부 기준은 일관되지 않았다. - 동일한 코드라도 실행 환경의 사소한 변화에 따라 연구를 허용하거나 거부했다. - 심각한 메모리 버그를 확인한 뒤에도 시연용 익스플로잇 작성은 거부할 수 있었다. - 요청 표현을 바꾸거나 실행 시점을 달리하면 반대 결과가 나오기도 했다. - 이러한 자발적 안전장치는 실제로 존재하지만, 확률적이고 상황 의존적이므로 단독 안전 경계로 사용할 수 없다. - 향후 공개되는 강력한 사이버 보안 모델에는 통제된 연구 환경 밖에서도 사용할 수 있도록 별도의 안전장치가 필요하다. ## 신호 대 잡음 문제와 오탐 - 보안 취약점 분석에서 가장 어려운 일 중 하나는 발견된 문제가 실제인지, 악용 가능한지, 즉시 수정해야 하는지를 판별하는 것이다. - AI 스캐너와 AI가 생성한 코드의 확산은 이 문제를 더욱 악화시켰으며, Cloudflare는 여러 후속 검증 단계를 구축해 대응하고 있다. ### 프로그래밍 언어의 영향 - C와 C++는 메모리를 직접 제어할 수 있어 다음과 같은 취약점이 발생하기 쉽다. - 버퍼 오버플로 - 경계 밖 읽기·쓰기 - 메모리 수명 관리 오류 - Rust와 같은 메모리 안전 언어는 이러한 버그 유형의 상당수를 컴파일 시점에 제거한다. - 실험에서는 메모리 비안전 언어로 작성된 프로젝트에서 오탐이 일관되게 더 많이 발생했다. ### 모델의 탐색 편향 - 숙련된 사람은 발견 내용과 함께 확신 수준을 명확히 제시하지만, 모델은 코드에 문제가 없어도 문제를 찾으려는 경향이 있다. - 결과에는 “가능성이 있다”, “잠재적으로”, “이론상 가능하다”와 같은 추측성 표현이 많이 포함된다. - 탐색 단계에서는 이런 보수적·과잉 탐지 성향이 유용할 수 있다. - 하지만 실제 트리아지 큐에서는 각각의 추측성 결과를 사람이 검증하고 기각해야 하므로, 수천 건으로 확장될 경우 인력과 모델 토큰 비용이 크게 누적된다. ## 실용적인 결론 Mythos Preview 같은 모델은 취약점 후보 발굴을 넘어 공격 체인 구성과 재현 증명까지 수행할 수 있어 보안 연구의 생산성을 크게 높일 수 있다. 다만 결과를 그대로 신뢰해서는 안 되며, 격리된 실행 환경, 다단계 검증, 신뢰도 기반 우선순위화, 일관된 안전 정책을 함께 구축해야 대규모 운영에 적합하다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

청구 파이프라인이 갑자기 느려졌다. 원인은 ClickHouse의 숨겨진 병목이었다

Cloudflare는 ClickHouse의 파티션 키를 `(day)`에서 `(namespace, day)`로 변경해 테넌트별 보존 기간을 지원하려 했지만, 수 주 뒤 청구용 쿼리가 급격히 느려졌다. 디스크 I/O, 메모리, 스캔 행 수, 읽은 파트 수는 정상처럼 보였지만, 실제 원인은 쿼리 실행 전 계획 수립 단계에서 발생한 `MergeTreeData` 뮤텍스 경합이었다. 파티션 수 증가가 개별 쿼리의 읽기량을 늘리지는 않았지만, 모든 쿼리 스레드가 전체 파트 목록을 보호하는 하나의 잠금을 기다리면서 지연이 누적됐다. ## 페타바이트 규모의 Ready-Analytics 플랫폼 - Cloudflare는 수십 개 클러스터에서 100PB 이상의 ClickHouse 데이터를 운영한다. - 내부 팀의 온보딩을 단순화하기 위해 `Ready-Analytics`라는 대규모 공용 테이블을 구축했다. - 데이터는 `namespace`로 구분하고, 표준 스키마에 따라 저장했다. - 기본 키는 `(namespace, indexID, timestamp)`로 구성했다. - `namespace`: 데이터 소유 팀 또는 애플리케이션 구분 - `indexID`: 네임스페이스별 쿼리 패턴에 맞춘 정렬 기준 - `timestamp`: 시간 범위 조회 지원 - 2024년 12월 기준 2PiB 이상, 초당 수백만 행의 데이터가 유입되고 있었다. ## 단일 보존 정책의 한계 - 기존 시스템은 ClickHouse의 네이티브 TTL이 보편화되기 전부터 운영되어 자체 파티션 기반 보존 시스템을 사용했다. - 테이블은 날짜별로 파티셔닝되었고, 31일보다 오래된 파티션을 삭제했다. - 모든 네임스페이스에 동일한 31일 보존 기간이 적용됐다. - 법적·계약상 수년간 데이터를 보관해야 하는 팀과 며칠만 보관하면 되는 팀을 동시에 지원할 수 없었다. - 그 결과 일부 사용 사례는 Ready-Analytics 대신 별도의 테이블과 복잡한 온보딩 절차를 이용해야 했다. ## `(namespace, day)` 파티션으로의 변경 - 검토한 선택지는 두 가지였다. - 네임스페이스마다 별도 테이블을 생성하는 방식 - 기존 파티션 키를 `(day)`에서 `(namespace, day)`로 변경하는 방식 - 별도 테이블 방식은 수천 개의 테이블을 자동으로 생성·관리해야 하므로 운영 복잡도가 컸다. - 최종적으로 `(namespace, day)` 파티션을 선택했다. - 기존 보존 시스템을 재사용할 수 있었다. - 특정 네임스페이스의 오래된 데이터만 선택적으로 삭제할 수 있었다. - 설계 당시에는 전체 데이터 파트 수가 늘어날 것을 알고 있었지만, 모든 쿼리가 특정 `namespace`로 필터링되므로 개별 쿼리가 읽는 파트 수는 변하지 않을 것이라고 판단했다. - 따라서 쿼리 성능도 크게 변하지 않을 것으로 예상했다. - 이 구조는 디스크 사용량을 네임스페이스별로 관리하는 기반도 제공했다. - max-min fairness 알고리즘으로 여유 디스크를 네임스페이스 간에 공유 - 목표 디스크 사용률을 90% 수준으로 유지 - 2025년 1월부터 마이그레이션을 시작했고, ClickHouse의 `Merge` 테이블 기능을 활용해 구 테이블과 신 테이블을 함께 운영하며 데이터를 이전했다. ## 청구 작업에서 드러난 성능 저하 - 2025년 3월 말, 마이그레이션 약 두 달 뒤 청구 팀이 일일 집계 작업의 지연을 보고했다. - 청구 작업은 정해진 시간 내 완료되지 않으면 청구서 발행이 지연되므로 강한 마감 시간이 있었다. - 성능 저하는 점진적으로 심해졌지만 일반적인 원인은 발견되지 않았다. - I/O 문제 없음 - 메모리 부족 없음 - 쿼리별 스캔 행 수 변화 없음 - 읽은 데이터 파트 수 증가 없음 - 전체 클러스터의 파트 수와 평균 `SELECT` 쿼리 시간을 비교한 결과, 두 지표 사이에 뚜렷한 상관관계가 나타났다. - 즉, 쿼리가 직접 읽지 않는 파트라도 테이블에 존재하는 것만으로 성능에 영향을 주고 있었다. ## Flame Graph로 찾은 쿼리 계획 병목 - ClickHouse의 `trace_log`를 이용해 쿼리 실행 중 어떤 코드가 시간을 사용하는지 분석했다. - `trace_log`는 실행 코드뿐 아니라 사용자, 쿼리 ID 등의 메타데이터도 제공해 특정 리프 `SELECT` 쿼리를 대상으로 분석할 수 있었다. - CPU 샘플 기반 Flame Graph에서는 쿼리 계획 단계에 상당한 시간이 소요되는 것이 확인됐다. - 특히 `filterPartsByPartition` 함수가 샘플 CPU 시간의 약 45%를 차지했다. - 파트 제거 휴리스틱의 실행 순서를 바꾸는 패치를 적용했지만 성능 향상은 약 5%에 그쳤다. - 이후 실행 중인 스레드만 측정하는 CPU trace 대신, 대기 중인 스레드까지 포함하는 Real trace를 사용했다. - 그 결과 실제 병목은 CPU 연산이 아니라 잠금 대기임이 밝혀졌다. ## `MergeTreeData` 뮤텍스 경합 - 쿼리 실행 시간의 절반 이상이 `MergeTreeData` 뮤텍스를 획득하기 위해 대기하는 데 사용됐다. - 이 뮤텍스는 테이블의 활성 데이터 파트 목록을 보호한다. - 쿼리 계획을 수립할 때 각 스레드는 읽을 파트를 결정하기 위해 이 파트 목록에 접근해야 한다. - `(namespace, day)` 파티션 도입으로 전체 파트 수가 계속 증가하면서, 파트 목록을 대상으로 하는 계획 수립 작업과 잠금 경쟁도 함께 커졌다. - 따라서 개별 쿼리가 실제로 읽는 파트 수가 동일해도, 전체 테이블의 파트 수 증가만으로 쿼리 지연이 누적될 수 있었다. ## 실용적인 결론 ClickHouse에서 파티션 수는 저장 공간이나 데이터 스캔량뿐 아니라 쿼리 계획 단계의 내부 자료구조와 잠금 경합에도 영향을 준다. 파티션 키를 세분화할 때는 “쿼리당 읽는 파트 수”만 보지 말고 전체 파트 수 증가, 계획 수립 시간, 대기 시간까지 함께 추적해야 하며, CPU trace와 대기 스레드를 포함한 Real trace를 모두 활용하는 것이 중요하다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

Browser Run: 이제 Cloudflare Containers에서 실행되어 더 빠르고 확장성이 뛰어납니다

Browser Run은 Cloudflare Containers 기반으로 재구축되면서 더 높은 처리량, 낮은 지연 시간, 향상된 안정성을 확보했다. 분당 브라우저 생성 한도는 60개, 동시 실행 수는 120개로 늘어 기존보다 4배 향상됐고, Quick Action 응답 시간은 50% 이상 단축됐다. 이 성능 개선의 핵심은 지역별 사전 준비 컨테이너 풀, D1의 트랜잭션 기반 상태 관리, Queues를 활용한 배치 쓰기다. ## Browser Run의 역할 - Cloudflare의 글로벌 네트워크에서 실행되는 헤드리스 브라우저를 프로그래밍 방식으로 제어한다. - 주요 활용 사례: - 웹 애플리케이션의 엔드투엔드 테스트 - 의심스러운 URL의 안전한 조사 - PDF 렌더링 - 스크린샷 캡처와 콘텐츠 추출 - AI 에이전트의 웹 브라우징 - 목표는 자동화 브라우저를 안전하고 대규모로 활용할 수 있는 플랫폼이 되는 것이다. ## 기존 Browser Isolation 인프라의 한계 - 이전에는 Browser Run과 Browser Isolation(BISO)이 인프라를 공유했다. - BISO의 큰 컨테이너 이미지는 브라우저 시작 시간과 개발 속도를 저하시켰다. - BISO 브라우저의 글로벌 분산이 충분하지 않아 지연 시간과 복원력에도 문제가 있었다. - BISO의 장시간·지속적 세션과 Browser Run의 짧고 급격한 트래픽 패턴이 서로 맞지 않아 확장 병목이 발생했다. ## 점진적인 Containers 마이그레이션 - 요청 경로에 Worker를 추가해 일부 사용자에게만 Container 기반 브라우저를 제공하며 마이그레이션을 시작했다. - 기존 BISO 브라우저와 병행 운영하면서 성능을 비교하고 구현 오류를 검증했다. - 적용 순서는 다음과 같았다. - Quick Actions 엔드포인트 - 무료 계정의 Workers 브라우저 바인딩 - 종량제 계정 - 나머지 계약 고객 - 고객이 별도 설정을 변경하거나 Worker를 재배포하지 않아도 전환되도록 했다. ## 지역별 사전 준비 컨테이너 풀 - Durable Object(DO)는 요청에 가까운 위치에 생성될 수 있지만, 연결되는 Container는 지구 반대편에 배치될 수 있다. - 단일 메시지에서는 문제가 작지만, 스크린샷 요청처럼 WebSocket으로 수십 개 메시지를 주고받는 작업에서는 왕복 지연이 누적된다. - 이를 해결하기 위해: - 지역별로 DO 기반 브라우저 컨테이너를 미리 실행해 둔다. - 요청이 들어오면 해당 지역에서 사용자와 가장 가까운 DO-Container 쌍을 선택한다. - 사용자-DO, DO-Container 양쪽의 네트워크 거리를 줄인다. - 브라우저별 글로벌 상태를 관찰하고 수요에 따라 용량을 재배치해야 하므로 추가적인 아키텍처 복잡성이 생겼다. ## Workers KV의 일관성 문제 - 초기에는 각 컨테이너 상태를 Workers KV에 저장했다. - KV는 최종적 일관성을 사용하며, 캐시 TTL 때문에 최대 약 30초 또는 그 이상 오래된 상태를 읽을 수 있었다. - “사용 가능”으로 읽은 컨테이너가 실제 라우팅 시점에는 이미 다른 요청에 할당되는 경쟁 조건이 발생했다. - 이로 인해: - 동일 브라우저의 중복 할당 - 과도한 브라우저 예약 - 급격한 수요 증가에 대한 확장 지연 문제가 생겼다. ## D1을 이용한 원자적 브라우저 할당 - 컨테이너 상태를 KV에서 D1 데이터베이스로 이전했다. - D1은 SQLite 기반 트랜잭션을 제공하므로 브라우저 할당을 원자적으로 처리할 수 있다. - 브라우저는 사용자 간 공유 자원이 아니므로, 한 번 할당되면 독점적으로 사용되어야 한다. - 후보 컨테이너를 선택하고 상태를 `picked`로 변경하는 작업을 하나의 트랜잭션으로 수행해 동시에 두 요청이 같은 브라우저를 차지하는 문제를 방지한다. - 지역별로 D1 샤드를 구성해 위치 기반 컨테이너 관리도 유지했다. ## Queues를 활용한 상태 업데이트 배치 처리 - 수천 개 컨테이너가 5초마다 상태를 갱신하면 데이터베이스 쓰기 부하가 커진다. - 개별 쓰기만 사용하면 초당 약 1,000회 쓰기라는 한계로 인해 지역당 약 5,000개 컨테이너 수준에서 병목이 발생할 수 있다. - 상태 업데이트를 Queues에 모은 뒤 100개 단위로 배치 처리했다. - 배치 쓰기는 개별 쓰기보다 처리 시간이 크게 늘지 않으므로 처리량을 크게 높일 수 있다. - 100개 단위 배치 기준으로 지역당 최대 약 500,000개 컨테이너까지 업데이트할 수 있는 여유를 확보했다. - 각 컨테이너는 5초마다 자신의 상태를 지역별 큐에 기록한다. - 큐 소비자는 다음과 같이 설정했다. - 최대 배치 크기: 100개 - 최대 배치 대기 시간: 1초 - 최대 재시도 횟수: 1회 - 배치 쓰기의 현재 P95 지연 시간은 0.1ms다. ## 성능 개선 결과 - Workers 바인딩을 통한 브라우저 생성량: - 분당 최대 60개 - 동시 실행 브라우저: - 최대 120개 - 이전보다 4배 증가 - Quick Action 응답 시간: - 50% 이상 단축 - 개선 사항은 기존 고객의 코드 변경이나 Worker 재배포 없이 즉시 적용됐다. Cloudflare의 사례는 짧고 급격한 트래픽을 처리하는 시스템에서 최종적 일관성 저장소를 핵심 할당 경로에 사용할 때 발생할 수 있는 문제를 보여준다. 실시간 자원 예약에는 트랜잭션 기반 DB를 사용하고, 빈번한 상태 갱신은 큐와 배치 쓰기로 분리하는 설계가 효과적인 접근이다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

‘idle’이 유휴 상태가 아닐 때: 리눅스 커널 최적화가 QUIC 버그가 된 과정

CUBIC의 혼잡 윈도우(cwnd)가 심각한 손실 이후 최솟값에 고정되어 회복하지 못하는 QUIC 버그가 발견됐다. 손실이 2초 후 완전히 사라졌는데도 quiche의 CUBIC은 회복 상태와 혼잡 회피 상태를 RTT 주기로 반복하며 전송량을 늘리지 못했다. 원인은 Linux TCP CUBIC의 유휴 상태 최적화를 QUIC에 적용하는 과정에서 `bytes_in_flight == 0` 상황이 잘못 해석된 데서 비롯됐으며, 결국 매우 작은 수정으로 문제가 해결됐다. ## CUBIC과 혼잡 윈도우의 역할 - 혼잡 제어 알고리즘(CCA)은 송신자가 네트워크에 동시에 전송할 수 있는 데이터의 상한인 `cwnd`를 조절한다. - `cwnd`가 크면 한 번에 더 많은 데이터를 전송하고, 작으면 전송 속도가 제한된다. - 손실 기반 알고리즘인 CUBIC은 다음과 같은 전제를 따른다. - 패킷 손실이 없으면 네트워크 여유가 있다고 보고 전송률을 증가시킨다. - 패킷 손실이 발생하면 네트워크 용량을 초과했다고 판단해 전송률을 줄인다. - CUBIC은 Linux의 기본 TCP 혼잡 제어기이며, Cloudflare의 QUIC 구현인 quiche에서도 기본값으로 사용된다. ## 재현 조건과 이상 증상 - 문제는 초반에 심각한 패킷 손실이 발생한 뒤 회복하는 통합 테스트에서 발견됐다. - 테스트 조건: - localhost에서 실행되는 HTTP/3 클라이언트와 서버 - RTT 10ms - 10MB 파일 다운로드 - CUBIC 사용 - 연결 시작 후 2초 동안 무작위 30% 패킷 손실 - 이후 패킷 손실 제거 - 10초 타임아웃 - 정상이라면 손실 구간에서 `cwnd`가 감소한 뒤, 손실이 사라지면 다시 증가해 4~5초 안에 다운로드를 완료해야 한다. - 그러나 100회 반복 시 약 60~61%가 10초 안에 완료되지 못했다. ## 손실이 없는데도 회복하지 못한 CUBIC - 2초 이후 패킷 손실은 완전히 사라졌지만 `bytes_in_flight`와 `cwnd`는 계속 최솟값에 머물렀다. - CUBIC은 약 6.7초 동안 회복 상태와 혼잡 회피 상태를 999회 반복했다. - 상태 전환 주기는 약 14ms로, 연결의 RTT 10ms와 비슷했다. - `cwnd`는 2700바이트, 즉 최대 세그먼트 크기의 패킷 2개 수준에 고정됐다. - 다운로드 서버 입장에서는 클라이언트의 ACK가 도착할 때마다 전송 중인 바이트가 0이 되고, 다시 두 패킷을 보내는 과정이 반복됐다. - 이 ACK 기반의 전송 리듬이 CUBIC의 상태 전환을 매 RTT마다 잘못 촉발한 것으로 분석됐다. ## Reno 비교를 통한 CUBIC 특화 문제 확인 - 동일한 테스트를 Reno로 실행한 결과 100% 성공했다. - Reno는 손실이 끝난 뒤 정상적으로 `cwnd`를 증가시키고 다운로드를 완료했다. - 따라서 네트워크 시뮬레이션이나 QUIC 전반의 문제가 아니라 CUBIC 구현의 특정 로직에 문제가 있음을 확인했다. ## Linux TCP의 유휴 상태 최적화 - 문제의 출발점은 2017년 Linux 커널에 적용된 TCP CUBIC 최적화였다. - 기존 구현에서는 CUBIC의 시간 기준점인 `epoch`가 연결 시작 시점과 손실 발생 시점에만 갱신됐다. - 애플리케이션이 오랫동안 유휴 상태에 있다가 다시 전송하면 `현재 시각 - epoch_start` 값이 지나치게 커질 수 있었다. - 그 결과 CUBIC의 목표 전송률과 증가 기울기가 비정상적으로 커지고, `ca->cnt`가 지나치게 작아질 수 있었다. - Linux는 이를 완화하기 위해 `ca->cnt`에 최솟값 2를 적용했으며, 특히 `slow_start_after_idle`이 비활성화된 경우 유휴 후 위험한 cwnd 증가가 발생할 수 있었다. - 이 최적화는 TCP에서 애플리케이션이 전송을 제한한 구간을 혼잡으로 오인하지 않도록 하기 위한 것이었지만, QUIC 구현에 이식되는 과정에서 `bytes_in_flight == 0`인 상황이 예상과 다르게 작동했다. ## 문제의 본질 - CUBIC은 실제 패킷 손실이 없더라도 전송 중인 바이트가 0이 되는 순간을 유휴 또는 특수한 상태로 처리한다. - 하지만 이 테스트에서는 연결이 유휴한 것이 아니라, `cwnd`가 두 패킷으로 제한되어 ACK를 받은 뒤 잠시 `bytes_in_flight`가 0이 되는 상황이 반복됐다. - 결과적으로 CUBIC의 유휴 상태 처리와 회복 상태 전환이 ACK 클록과 결합되어 매 RTT마다 잘못된 상태 변화를 일으켰다. - 그 결과 혼잡 윈도우가 최소값에서 탈출하지 못하고, 손실이 사라진 뒤에도 전송 속도가 회복되지 않았다. ## 실용적인 시사점 - 혼잡 제어 테스트는 정상적인 성장 구간뿐 아니라, `cwnd`가 최솟값으로 떨어진 뒤 회복하는 시나리오도 반드시 포함해야 한다. - `bytes_in_flight == 0`은 실제 애플리케이션 유휴 상태와 ACK 직후의 일시적인 상태를 구분하지 않으면 오판의 원인이 될 수 있다. - TCP 최적화 코드를 QUIC에 이식할 때는 전송 모델과 ACK 처리 방식의 차이를 검증해야 한다. - 이 사례는 상태 전환 횟수와 RTT 상관관계를 관찰하는 qlog 기반 계측이 혼잡 제어 버그를 찾는 데 효과적임을 보여준다.

원문 읽기(새 탭에서 열림)
cloudflare3분 읽기큐레이션 요약

미래를 위한 구축

Cloudflare는 에이전틱 AI 시대에 맞춰 내부 업무·조직·역할을 전면 재설계하기 위해 전 세계 직원 1,100명 이상을 감원한다고 발표했습니다. 이는 개인의 성과나 단순한 비용 절감이 아니라, AI 활용이 급증한 환경에서 회사 운영 방식을 근본적으로 바꾸려는 결정이라는 설명입니다. 회사는 조직 개편을 한 번에 단행해 불확실성을 줄이고, 남은 조직의 속도와 혁신성을 높이겠다고 밝혔습니다. ### 에이전틱 AI 시대에 맞춘 조직 재설계 - Cloudflare는 최근 3개월 동안 사내 AI 사용량이 600% 이상 증가했다고 설명했습니다. - 엔지니어링뿐 아니라 인사, 재무, 마케팅 등 전 부서에서 매일 수천 건의 AI 에이전트 세션을 업무에 활용하고 있습니다. - AI 도구를 고객에게 판매하는 데 그치지 않고, Cloudflare 스스로가 가장 까다로운 AI 고객이 되어야 한다는 입장입니다. - 이에 따라 내부 프로세스, 팀 구조, 직무와 역할을 에이전틱 AI 환경에 맞게 재구성합니다. ### 감원의 성격과 경영진의 책임 - 이번 조치는 1,100명 이상의 글로벌 인력을 줄이는 대규모 구조조정입니다. - 회사는 이를 개인의 역량이나 업무 성과에 대한 평가가 아니며, 단순한 비용 절감도 아니라고 강조했습니다. - 창업자인 Matthew Prince와 Michelle Zatlyn이 직접 모든 직원에게 이메일을 보내며 결정을 전달했습니다. - 관리자나 팀 단위로 소식을 단계적으로 전달하지 않고, 전 직원에게 동시에 안내해 정보의 지연과 혼선을 줄이려 했습니다. - 경영진은 이번 결정을 창업자와 리더가 직접 책임져야 하는 사안으로 규정했습니다. ### 퇴직자를 위한 보상과 지원 - 퇴직자에게 2026년 말까지의 기본급에 해당하는 보상금을 제공합니다. - 미국 직원에게는 의료보험 지원을 2026년 말까지 계속 제공합니다. - 주식 보상은 퇴사 후인 8월 15일까지 베스팅되도록 했습니다. - 근속 1년 미만으로 ‘1년 클리프(cliff)’에 도달하지 못한 직원도 해당 조건을 면제하고, 8월까지 비례 배분된 주식을 받게 됩니다. - 회사는 어려운 결정을 피하는 것이 공감이 아니라, 결정을 내린 뒤 사람을 어떻게 대하는지가 공감이라고 설명했습니다. ### 반복적인 감원 대신 한 번의 결단 - 회사는 여러 분기에 걸쳐 소규모 감원을 반복하거나 구조조정을 장기화하면 직원들의 정서적 불확실성이 커진다고 판단했습니다. - 장기간의 불안정성은 조직의 실행력과 제품 개발을 지연시킬 수 있다고 보았습니다. - 따라서 이번 조치를 한 번에 진행해 퇴직자에게는 즉각적인 명확성을 제공하고, 남은 직원에게는 조직의 안정성을 보장하려 합니다. - 향후 가까운 시일 내에 같은 방식의 추가 감원을 반복하지 않겠다고 밝혔습니다. ### 디지털 기업에서 AI 중심 기업으로의 전환 - Cloudflare는 처음부터 클라우드 기반으로 설계된 디지털 네이티브 기업이었습니다. - 기존 시스템과 관행에 묶인 전통 기업보다 빠르게 성장할 수 있었지만, 이제 시장의 선두 기업이 된 만큼 과거의 업무 방식에 안주할 수 없다고 진단했습니다. - 새 조직은 더 빠르고 혁신적으로 고객 가치를 창출하는 것을 목표로 합니다. - 회사의 사명인 “모두를 위한 더 나은 인터넷 구축”을 지속하기 위해 조직 자체도 미래에 맞게 변화해야 한다고 주장합니다. ### 후속 소통 - Cloudflare는 실적 발표 콘퍼런스콜에서 이번 결정에 대해 추가 설명할 예정이라고 밝혔습니다. - 전사 미팅에서도 직원들에게 직접 발표 내용을 설명하고 질의에 대응할 계획입니다. - 퇴직자들에게는 그동안의 기여에 감사를 표하며, Cloudflare에서 쌓은 경험과 기술이 향후 새로운 기업과 프로젝트를 만드는 데 도움이 될 것이라고 전했습니다. 조직이 AI 중심으로 전환할 때는 기술 도입뿐 아니라 역할, 의사결정 구조, 인력 운영까지 함께 재설계해야 합니다. 다만 대규모 감원은 명확한 전략과 충분한 보상, 투명한 소통이 뒷받침될 때에만 조직의 신뢰와 실행력을 유지할 수 있습니다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

Cloudflare는 “Copy Fail” 리눅스 취약점에 어떻게 대응했나

2026년 4월 29일 공개된 Linux 커널 권한 상승 취약점 “Copy Fail”(CVE-2026-31431)에 대해 Cloudflare는 공개 직후 영향 범위와 탐지 가능성을 분석했다. Cloudflare의 자동화된 커널 업데이트와 기존 행위 기반 탐지 체계 덕분에 취약점 악용을 수분 내 식별할 수 있었으며, 실제 환경·고객 데이터·서비스에는 아무런 영향이 없었다. 핵심 대응은 최신 LTS 커널 패치 적용, 인프라별 노출도 분석, 공격 행위 검증이었다. ## Cloudflare의 Linux 커널 운영 체계 - Cloudflare는 330개 도시에 걸친 대규모 Linux 인프라를 운영한다. - 커뮤니티 Linux LTS 버전을 기반으로 자체 커널을 빌드하며, 여러 LTS 계열을 동시에 사용할 수 있다. - 보안·안정성 업데이트가 반영되면 자동화된 작업이 약 1주일 주기로 내부 커널 빌드를 생성한다. - 새 빌드는 스테이징 데이터센터에서 검증한 뒤, Edge Reboot Release(ERR) 파이프라인을 통해 약 4주 주기로 전 세계 엣지 인프라에 배포·재부팅한다. - CVE가 공개될 때는 수정 사항이 이미 안정화된 LTS 버전에 수 주 전 반영되어 있는 경우가 많아, Cloudflare는 공개 시점에 이미 패치를 배포한 상태인 경우가 많다. - 취약점 공개 당시 대부분의 시스템은 6.12 LTS를 사용했고, 일부는 6.18 LTS로 전환 중이었다. ## AF_ALG와 커널 암호화 API - Linux 커널 암호화 API는 kTLS와 IPsec 같은 기능을 제공한다. - 비권한 사용자 프로세스도 `AF_ALG` 소켓을 통해 암호화·복호화 기능을 요청할 수 있다. - `algif_aead` 모듈은 AEAD 암호 알고리즘을 처리한다. - 일반적인 처리 흐름은 다음과 같다. - `AF_ALG` 소켓을 열고 AEAD 템플릿에 바인딩 - 키를 설정하고 요청 소켓을 생성 - `sendmsg()` 또는 `splice()`로 입력 전달 - `recvmsg()`로 암호화 연산 실행 - 특히 `splice()`는 실제 데이터를 복사하기보다 페이지 캐시의 페이지 참조를 전달하므로, 이번 취약점 악용에 중요한 역할을 했다. ## 페이지 캐시와 인플레이스 암호화의 문제 - Linux 페이지 캐시는 파일 내용을 공유하는 시스템 캐시다. - 페이지 캐시에 있는 파일 페이지가 수정되면, 해당 페이지가 캐시에서 제거되기 전까지 모든 사용자가 수정된 내용을 볼 수 있다. - `algif_aead`는 2017년 성능 개선 과정에서 입력·출력 페이지를 연결해 인플레이스 연산을 수행하도록 최적화됐다. - 그러나 이 구조에는 암호화 알고리즘이 의도된 출력 영역을 넘어 쓰지 못하도록 충분히 제한하는 검증이 없었다. - 그 결과 공격자는 파일의 페이지 캐시를 암호화 scatterlist에 연결해, 파일의 특정 위치에 데이터를 덮어쓸 수 있었다. ## “Copy Fail” 취약점의 작동 원리 - `recvmsg()` 처리 중 `authencesn` 래퍼가 정상적인 출력 영역을 넘어 4바이트를 기록한다. - 공격자는 `splice()`를 이용해 대상 파일의 페이지 캐시 페이지를 scatterlist에 포함시킬 수 있다. - 이때 다음 요소를 공격자가 조절할 수 있다. - 대상 파일: 읽을 수 있는 파일 - 쓰기 위치: `assoclen`과 `splice()` 파라미터로 조정 - 기록 값: `sendmsg()`의 특정 AAD 바이트로 제어 - 기본 공격 대상은 거의 모든 Linux 배포판에 존재하는 setuid-root 바이너리 `/usr/bin/su`다. - 공격자는 해당 파일을 페이지 캐시에 올린 뒤 암호화 API 요청을 구성하고, `recvmsg()` 실행 중 발생하는 범위를 벗어난 쓰기로 바이너리의 코드 영역을 변조한다. - `recvmsg()`가 `-EBADMSG` 오류를 반환하더라도 페이지 캐시에 대한 4바이트 쓰기는 이미 수행될 수 있다. - 이후 변조된 `/usr/bin/su`가 실행되면 setuid 권한으로 인해 삽입된 코드가 root 권한으로 실행될 수 있다. - Linux 업스트림 수정 커밋 `a664bf3d603d`는 문제가 된 2017년 인플레이스 최적화를 되돌려 이 공격 경로를 제거했다. ## Cloudflare의 대응 - 취약점 공개 직후 보안팀과 커널 엔지니어링팀이 병렬로 대응을 시작했다. - 먼저 어떤 커널 버전이 취약한지 확인하고, 각 인프라 구성에서 실제 노출 가능성을 분석했다. - 기존의 자동 커널 빌드·검증·배포 절차를 통해 수정된 LTS 커널을 신속하게 적용할 수 있는 기반을 확보하고 있었다. - 보안팀은 공개된 익스플로잇 기법을 검토해 Cloudflare 환경에서 공격이 가능한지 검증했다. - 기존 행위 기반 탐지 시스템이 `AF_ALG`, `splice()`, 비정상적인 페이지 캐시 조작 등 익스플로잇의 행동 패턴을 수분 내 식별할 수 있음을 확인했다. - 결과적으로 실제 침해, 고객 데이터 노출, 서비스 중단은 발생하지 않았다. ## 실용적인 교훈 - 커널 취약점 대응에서는 단순히 패치를 기다리기보다 자동화된 빌드·테스트·점진적 배포 체계를 평소에 갖추는 것이 중요하다. - LTS 커널을 사용하더라도 여러 버전이 공존할 수 있으므로 자산별 커널 버전과 패치 상태를 지속적으로 관리해야 한다. - 시그니처 기반 탐지만으로는 부족하며, 시스템 호출 조합과 비정상적인 파일·페이지 캐시 접근을 관찰하는 행위 기반 탐지가 효과적이다. - 취약점 공개 직후에는 패치 적용뿐 아니라 익스플로잇 재현, 환경별 노출도 분석, 탐지 검증을 동시에 수행해야 한다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

DNSSEC가 잘못되었을 때: .de TLD 장애에 대응한 방법

2026년 5월 5일, .de TLD 운영자인 DENIC이 잘못된 DNSSEC 서명을 배포하면서 .de 하위 도메인에 대한 DNS 조회가 대규모로 실패했다. Cloudflare의 1.1.1.1은 DNSSEC 규격에 따라 검증에 실패한 응답을 `SERVFAIL`로 처리했지만, 캐시된 레코드를 TTL 이후에도 제공하는 “serve stale”과 DNSSEC 검증 우회 설정으로 영향을 완화했다. 이 대응은 가용성을 높이는 대신 사고 기간 동안 .de 도메인의 위조·변조 위험을 일부 감수하는 선택이었다. ## DNSSEC와 신뢰 체인 - DNSSEC은 DNS 응답의 암호화가 아니라 **무결성과 진위 검증**을 제공한다. - 각 DNS 레코드에는 `RRSIG` 전자서명이 붙으며, 리졸버는 이를 검증해 응답이 변조되지 않았는지 확인한다. - 검증은 루트 영역에서 시작하는 신뢰 체인을 따른다. - 루트 영역이 `.de`를 신뢰한다. - `.de`는 `DS` 레코드를 통해 `example.de` 같은 하위 영역을 신뢰한다. - 체인의 어느 한 지점이라도 깨지면 해당 영역 아래의 모든 도메인이 검증 실패와 `SERVFAIL`을 겪는다. - 일반적으로 다음 두 키를 사용한다. - **ZSK**: 영역 내 DNS 레코드 서명 - **KSK**: ZSK를 서명하며, 부모 영역의 `DS` 레코드가 KSK를 가리킴 - 키 교체 중 새 키가 완전히 배포되지 않았거나, 서명에 사용된 키를 `DNSKEY`에서 확인할 수 없으면 리졸버는 응답을 거부한다. ## .de TLD 장애와 영향 - 2026년 5월 5일 약 19:30 UTC부터 DENIC이 잘못된 DNSSEC 서명을 게시했다. - DNSSEC 검증을 수행하는 리졸버는 해당 서명을 거부하고 `SERVFAIL`을 반환해야 했다. - 1.1.1.1에서도 초기 `SERVFAIL`이 급증했고, 캐시된 레코드가 만료되면서 약 3시간 동안 실패율이 계속 상승했다. - 사용자가 실패한 DNS 조회를 반복하면서 전체 쿼리량도 크게 증가했다. - 실제 사용자 수보다 `SERVFAIL` 요청 수가 더 크게 보일 수 있는데, 동일한 사용자의 재시도가 여러 요청으로 집계되기 때문이다. - `.de`는 세계적으로 많이 조회되는 TLD이므로 장애가 수백만 개 도메인의 접근성에 영향을 줄 가능성이 있었다. ## 캐시된 응답을 계속 제공하는 “serve stale” - 리졸버는 권위 있는 네임서버의 응답을 레코드별 TTL 동안 캐시한다. - 장애가 발생하면 새로 가져온 레코드는 DNSSEC 검증 실패로 `SERVFAIL`이 되지만, 장애 전부터 캐시에 있던 레코드는 여전히 유효한 내용을 담고 있을 수 있다. - 1.1.1.1은 RFC 8767에 정의된 **serve stale** 동작을 사용해, 상위 네임서버 조회가 실패해도 만료된 캐시 레코드를 일정 기간 제공했다. - 이 기능 덕분에 일부 사용자는 장애 중에도 정상적인 `NOERROR` 응답을 받았다. - 캐시된 데이터가 사라질수록 stale 응답이 줄고, 정상 응답률도 점차 낮아졌다. - 즉, 캐시는 장애를 해결하지는 않지만 운영자가 복구할 시간을 벌어 주며 즉각적인 사용자 피해를 줄인다. ## DNSSEC 검증을 우회하는 Negative Trust Anchor - RFC 7646의 **Negative Trust Anchor(NTA)** 는 특정 영역을 일시적으로 DNSSEC 미서명 영역처럼 취급하는 예외 설정이다. - 신뢰 체인이 깨진 경우 해당 영역 아래 응답의 DNSSEC 검증을 생략해 `SERVFAIL`을 피할 수 있다. - TLD 운영자의 설정 오류처럼 하위 도메인 자체에는 문제가 없는 상황이 NTA의 대표적인 사용 사례다. - 이 경우 계속 `SERVFAIL`을 반환하는 것은 실질적인 보안 이득보다 가용성 손실이 더 클 수 있다. ## Cloudflare의 실제 완화 조치 - Cloudflare의 1.1.1.1과 관련 서비스는 `Big Pineapple`이라는 자체 리졸버를 사용한다. - 당시 Cloudflare는 RFC 방식의 네이티브 NTA 기능을 구현하지 않은 상태였다. - 대신 기존 오버라이드 규칙을 활용해 `.de`를 **insecure zone**으로 지정했다. - 결과적으로 `.de` 질의는 DNSSEC이 활성화되지 않은 영역처럼 처리되어 검증 실패에 따른 `SERVFAIL`을 피할 수 있었다. - 이는 형식상 NTA는 아니지만 기능적으로는 동일한 효과를 냈다. - 다만 DNSSEC을 우회하는 동안에는 실제 공격자가 DNS 응답을 변조하더라도 검증으로 차단할 수 없으므로, 가용성과 보안 사이의 의도적인 절충이었다. 장기적으로는 DNSSEC 장애 대응을 위해 serve stale을 활성화하고, 통제된 조건에서 사용할 수 있는 NTA 또는 동등한 예외 메커니즘을 마련하는 것이 권장된다. 단, 검증 우회는 장애 범위와 원인이 명확할 때만 일시적으로 적용하고, 복구 즉시 해제해야 한다.

원문 읽기(새 탭에서 열림)
cloudflare원문

코드 오렌지: ‘작게 실패하기’가 완료되었습니다. 그 결과 더욱 강력해진 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)'함으로써 더 큰 가용성을 보장하는 구조적 변화를 의미합니다. 사용자는 이제 더욱 견고해진 인프라 위에서 예상치 못한 설정 오류나 시스템 장애로부터 보호받으며 서비스를 이용할 수 있습니다.

cloudflare원문

동적 워크플로우 소개: 테넌트를 따르는 내구성 있는 실행 (새 탭에서 열림)

Cloudflare는 멀티테넌트 SaaS나 AI 에이전트처럼 런타임에 코드가 생성되는 환경을 지원하기 위해 'Dynamic Workflows'를 도입했습니다. 이는 기존의 정적 배포 방식에서 벗어나, 각 테넌트가 작성한 고유한 워크플로우 코드를 동적으로 로드하고 실행할 수 있게 해주는 내구성 있는 실행(Durable Execution) 솔루션입니다. 개발자는 이를 통해 개별 테넌트나 세션마다 서로 다른 비즈니스 로직을 가진 워크플로우를 격리된 샌드박스 환경에서 안전하고 신속하게 구동할 수 있습니다. ### 정적 워크플로우 배포의 한계 * 기존 Cloudflare Workflows는 `wrangler.jsonc` 설정 파일에 워크플로우 클래스를 미리 정의해야 하는 정적 바인딩 구조를 가졌습니다. * AI가 사용자별로 코드를 생성하거나, 각 저장소마다 고유한 파이프라인을 갖는 CI/CD 서비스와 같은 현대적인 플랫폼에서는 모든 테넌트의 로직을 미리 정의하는 것이 불가능합니다. * 컴퓨트(Dynamic Workers)와 스토리지(Durable Object Facets)는 이미 동적 배포가 가능해졌으나, 장기 실행이 필요한 워크플로우 영역은 여전히 테넌트별 맞춤화가 어려운 공백으로 남아 있었습니다. ### 동적 워크플로우의 구조와 작동 방식 * `@cloudflare/dynamic-workflows` 라이브러리는 약 300줄의 TypeScript 코드로 구성되며, 'Worker Loader'가 각 테넌트의 코드로 호출을 라우팅하는 역할을 수행합니다. * 워크플로우 엔진이 `run(event, step)` 함수를 호출할 때, 라이브러리는 수 시간 또는 수일 후에도 해당 워크플로우를 생성했던 정확한 테넌트의 코드를 찾아 실행을 재개합니다. * 테넌트는 표준 `WorkflowEntrypoint`를 사용하여 평범한 워크플로우 코드를 작성하며, 자신이 동적으로 관리되는 환경에 있다는 사실을 인지할 필요 없이 독립적인 실행 환경을 보장받습니다. ### 주요 기능 및 기술적 이점 * **기존 기능 완전 계승**: 워크플로우 상태 확인(`.status()`), 일시 중지(`.pause()`), 재시도, 동적 단계 실행, `step.sleep()`을 이용한 장기 대기, `step.waitForEvent()` 등의 모든 기능을 그대로 사용할 수 있습니다. * **고성능 격리 환경**: 싱글 디지트 밀리초(단위 수 밀리초) 내에 격리된 샌드박스 Worker가 생성되어 보안성과 속도를 동시에 확보합니다. * **확장성**: Workflows V2 아키텍처를 기반으로 설계되어, 계정당 초당 300개의 새로운 인스턴스 생성과 최대 50,000개의 동시 인스턴스 처리를 지원하여 에이전트 중심의 서비스 확장에 최적화되어 있습니다. AI 에이전트가 스스로 도구를 작성하고 실행하거나, 고객마다 고유한 비즈니스 자동화 로직을 부여해야 하는 SaaS 플랫폼을 구축 중이라면 Dynamic Workflows가 최적의 대안이 될 것입니다. 이 시스템을 통해 인프라 관리의 부담 없이 테넌트별로 특화된 내구성 있는 워크플로우를 무한히 확장할 수 있습니다.