2025년 5월 02일·7분
CDN에서 플랫폼으로: 클라우드플레어 엣지는 어떻게 확장되었나
더 많은 트래픽이 네트워크 퍼리미터로 이동하면서 클라우드플레어의 엣지가 CDN 캐싱에서 보안·개발자 서비스까지 어떻게 확장되었는지 알아보세요.
더 많은 트래픽이 네트워크 퍼리미터로 이동하면서 클라우드플레어의 엣지가 CDN 캐싱에서 보안·개발자 서비스까지 어떻게 확장되었는지 알아보세요.
엣지 네트워크는 많은 도시에 분산된 서버 집합으로, 최종 사용자와 "가깝게" 위치합니다. 모든 요청이 회사의 오리진 서버(또는 클라우드 리전)까지 전부 이동하는 대신, 엣지는 가까운 위치에서 해당 요청에 응답하거나 검사하거나 전달할 수 있습니다.
비유하자면, 모든 질문을 뒤편 사무실에서 처리하는 대신 입구마다 친절한 직원을 배치해 두는 것과 같습니다. 어떤 요청은 즉시 처리될 수 있고(캐시된 파일 제공 등), 어떤 요청은 안전하게 오리진으로 전달됩니다.
퍼리미터는 외부 인터넷 트래픽이 처음으로 귀사의 시스템과 만나는 경계입니다: 웹사이트, 앱, API, 이를 보호하고 라우팅하는 서비스들입니다. 과거 많은 회사는 퍼리미터를 얇은 문턱(DNS와 로드밸런서) 정도로 취급했습니다. 오늘날에는 로그인, API 호출, 봇, 스크래핑, 공격, 갑작스러운 트래픽 스파이크 등 가장 바쁘고 위험한 상호작용이 그곳에서 발생합니다.
더 많은 업무가 온라인으로 이동하고 통합들이 API에 의존함에 따라, 트래픽을 퍼리미터로 유도해 일관된 규칙(성능 최적화, 보안 검사, 접근 통제)을 오리진에 도달하기 전에 적용하는 것이 점점 실용적이 되고 있습니다.
이 글은 다음 흐름을 따라갑니다: 성능 우선(CDN) → 엣지 보안(DDoS, WAF, 봇 제어, 제로 트러스트) → 개발자 도구(사용자 근처에서 코드 실행 및 데이터 처리).
비전문 의사결정자(벤더를 평가하는 구매자, 트레이드오프를 고민하는 창업자, ‘왜’와 ‘무엇이 바뀌는지’가 필요한 PM)를 대상으로 작성되었습니다. 네트워킹 교과서를 읽을 필요는 없습니다.
전통적 CDN(콘텐츠 전송 네트워크)은 간단한 약속에서 시작했습니다: 방문자와 더 가까운 위치에서 콘텐츠를 제공해 웹사이트를 더 빠르게 느끼게 하라는 것. 모든 요청이 오리진 서버(종종 단일 리전이나 데이터센터)까지 이동하는 대신 CDN은 정적 파일(이미지, CSS, JavaScript, 다운로드 등)을 다수의 PoP(Point of Presence)에 보관합니다. 사용자가 파일을 요청하면 CDN이 로컬에서 응답해 지연을 줄이고 오리진의 부담을 덜어줍니다.
핵심적으로 "CDN 전용" 구성이 집중하는 세 가지 결과는:
이 모델은 정적 사이트, 미디어 중심 페이지, 동일한 자산이 반복적으로 요청되는 예측 가능한 트래픽 패턴에 특히 효과적입니다.
초기에는 팀들이 실무적 지표 몇 개로 CDN을 평가했습니다:
이 수치들은 사용자 경험과 인프라 비용에 직접 연결되었기 때문에 중요했습니다.
기본 CDN이라도 요청이 사이트에 도달하는 방식을 바꿉니다. 가장 일반적으로는 DNS를 통해 도입됩니다: 도메인이 CDN을 가리키면 방문자를 가까운 PoP로 라우팅합니다. 그곳에서 CDN은 리버스 프록시로 동작할 수 있습니다—사용자와의 연결을 종료하고 필요 시 오리진과 별도의 연결을 엽니다.
그 “중간에 위치한” 지점이 중요합니다. 제공자가 신뢰할 수 있게 오리진 앞에 자리잡고 엣지에서 트래픽을 처리하면 단순한 파일 캐시를 넘어서 요청을 검사하고 필터링하며 형태를 바꿀 수 있습니다.
많은 현대 제품은 더 이상 대부분 정적 페이지가 아닙니다. 개인화된 콘텐츠, 실시간 업데이트, 인증 흐름, 잦은 쓰기가 있는 동적 애플리케이션입니다. 캐싱이 도움이 되지만 사용자별로 다른 응답, 쿠키나 헤더에 의존하는 경우, 또는 즉각적인 오리진 로직이 필요한 상황에서는 모든 문제를 해결할 수 없습니다.
정적 가속과 동적 애플리케이션 요구 사이의 이 간격이 "CDN"에서 더 넓은 엣지 플랫폼으로의 진화가 시작되는 지점입니다.
인터넷 사용 방식의 큰 변화가 더 많은 요청을 오리진 서버에 닿기 전에 "엣지"(네트워크 퍼리미터)로 밀어넣고 있습니다. 단순히 웹사이트를 빠르게 만드는 문제가 아닙니다—트래픽이 자연스럽게 흐르는 위치의 문제입니다.
HTTPS 전역화는 주요 요인입니다. 대부분의 트래픽이 암호화되면 기업 내부의 네트워크 장비가 이를 쉽게 검사하거나 최적화할 수 없습니다. 대신 조직들은 TLS를 사용자에 더 가까운 엣지 서비스에서 종료하고 관리하는 것을 선호합니다.
API들도 트래픽 형태를 바꿨습니다. 현대 앱은 웹 프론트엔드, 모바일 클라이언트, 파트너 통합, 마이크로서비스에서 끊임없이 작은 요청을 생성합니다. 여기에 봇(긍정적/부정적 모두)이 더해지면 실제 "사용자"가 아닌 엔터티가 큰 비중을 차지하게 되고—트래픽은 애플리케이션 인프라에 닿기 전에 필터링과 속도 제한이 필요해집니다.
또한 모바일 네트워크(가변 지연, 로밍, 재전송)와 SaaS의 확산 현실을 고려하면, 직원과 고객이 더 이상 단일 네트워크 경계 안에 있지 않습니다. 따라서 보안과 성능 결정은 사용자가 실제로 접속하는 위치로 이동합니다.
애플리케이션, 사용자, 서비스가 리전과 클라우드 전반에 분산될 때 규칙을 시행할 신뢰할 만한 단일 지점이 줄어듭니다. 전통적 제어 지점(예: 단일 데이터센터 방화벽)은 더 이상 기본 경로가 되지 않습니다. 엣지는 대부분의 요청을 라우팅할 수 있는 일관된 검사 지점 중 하나가 됩니다.
퍼리미터를 통과하는 트래픽이 많기 때문에 DDoS 필터링, 봇 탐지, WAF 규칙, TLS 설정, 접근 통제 같은 공통 정책을 적용하기에 자연스러운 장소가 됩니다. 이는 각 오리진에서의 의사결정을 줄이고 애플리케이션 전반에 걸쳐 보호를 일관되게 유지합니다.
트래픽을 엣지에 중앙화하면 오리진 IP 숨김과 직접 노출 감소 같은 보안 이점이 있습니다. 대신 의존성이 늘어납니다: 엣지의 가용성과 올바른 설정이 중요해집니다. 많은 팀이 엣지를 단순 캐시가 아닌 핵심 인프라의 일부, 즉 제어 플레인에 가깝게 취급합니다.
실용적 체크리스트는 /blog/how-to-evaluate-an-edge-platform를 참조하세요.
전통적 CDN은 "스마트 캐싱"으로 시작했습니다: 사용자와 가까운 곳에 정적 파일 사본을 저장하고 필요 시 오리진에서 가져오는 방식입니다. 이는 성능에 도움이 되지만 누가 연결을 "소유"하는지를 근본적으로 바꾸지는 않습니다.
큰 변화는 엣지가 단순 캐시를 넘어서 풀 리버스 프록시가 될 때 발생합니다.
리버스 프록시는 웹사이트나 앱 앞에 위치합니다. 사용자는 프록시에 연결하고 프록시는 오리진에 연결합니다. 사용자에게는 프록시가 사이트처럼 보이고, 오리진에는 프록시가 사용자처럼 보입니다.
이 위치는 캐시 전용 동작으로는 불가능한 서비스를 가능하게 합니다—모든 요청을 엣지에서 처리·수정·차단할 수 있기 때문입니다.
엣지가 TLS를 종료하면 암호화된 연결이 먼저 엣지에서 성립합니다. 이는 세 가지 실무적 능력을 만듭니다:
마음속 모델은 다음과 같습니다:
user → edge (reverse proxy) → origin
엣지를 중간에 두면 제어가 중앙화되는데, 이는 종종 목표이기도 합니다: 일관된 보안 정책, 간단한 배포, 각 오리진에서의 예외 감소.
하지만 복잡성과 의존성도 늘어납니다:
이 아키텍처 변화가 CDN을 플랫폼으로 바꿉니다: 엣지가 프록시가 되면 캐시 이상의 많은 일을 할 수 있습니다.
DDoS(분산 서비스 거부) 공격은 간단히 말해 사이트나 앱을 정상 사용자가 접근하지 못하게 할 정도로 트래픽을 압도하려는 시도입니다. 해커가 침입하는 대신 진입로를 막아버리는 식입니다.
많은 DDoS 공격은 대량의 데이터로 IP 주소를 공격해 대역폭을 소모하거나 네트워크 장비를 과부하 시키는 형태입니다. 오리진에서 방어를 기다리면 이미 비용을 치르게 됩니다—업스트림 링크가 포화되고 방화벽이나 로드밸런서가 병목이 될 수 있습니다.
엣지 네트워크는 트래픽이 인터넷에 진입하는 지점에 더 가까운 곳에 방어 용량을 배치하기 때문에 도움이 됩니다. 방어가 분산될수록 공격자가 단일 병목에 몰아넣기 어려워집니다.
제공자가 DDoS 보호를 "흡수하고 필터링"한다고 할 때, 여러 PoP에서 두 가지가 일어납니다:
주요 이점은 공격의 최악 부분을 인프라보다 상류에서 처리해 오리진 네트워크나 클라우드 비용이 피해를 보지 않게 한다는 점입니다.
레이트 리밋은 단일 소스나 특정 행위가 너무 빨리 자원을 소비하지 못하도록 막는 실용적 방법입니다. 예를 들어:
단독으로 모든 DDoS를 막지는 못하지만 남용성 급증을 줄이고 사고 시 핵심 경로를 유지하는 효과적인 압력 완화 장치입니다.
엣지 기반 DDoS 보호를 평가할 때는 다음을 확인하세요:
기본 DDoS 필터링이 자리잡으면 다음 계층은 애플리케이션 자체를 보호하는 것입니다—특히 겉보기엔 "정상"이지만 악의가 담긴 요청들입니다. 여기서 WAF와 봇 관리가 엣지에서 일상적으로 중요한 역할을 합니다.
WAF는 HTTP/S 요청을 검사해 일반적인 남용 패턴을 차단하는 규칙을 적용합니다. 전형적 예시는:
앱이 모든 악성 입력을 잡아내는 것에 의존하는 대신 엣지에서 많은 시도를 걸러 오리진 서버로 가는 위험과 시끄러운 트래픽(불필요한 컴퓨트와 로그)을 줄입니다.
봇은 유용한 것(검색 엔진 크롤러)과 해로운 것(크리덴셜 스터핑, 스크래핑, 재고 훔치기, 가짜 가입)이 있습니다. 차이는 단순한 자동화가 아니라 의도와 행동입니다. 실제 사용자의 세션은 자연스러운 타이밍, 네비게이션 흐름, 브라우저 특성을 가지는 반면, 악성 봇은 높은 빈도의 반복 요청, 엔드포인트 탐색, 사용자 에이전트를 모방하면서도 비정상적으로 행동하는 경우가 많습니다.
엣지는 많은 사이트에서 대량의 데이터를 보기 때문에 다음과 같은 폭넓은 신호를 활용해 더 정교한 판단을 할 수 있습니다:
실용적 롤아웃은 모니터(로그) 모드로 시작해 무엇이 차단될지 먼저 관찰하는 것입니다. 데이터를 사용해 알려진 도구와 파트너에 대한 예외를 조정한 다음 정책을 점진적으로 강화하세요—알림 → 챌린지 → 확정적 차단 순으로 진행하면 오탐을 줄이면서 보안을 빠르게 개선할 수 있습니다.
제로 트러스트는 유행어를 빼면 더 이해하기 쉽습니다: 네트워크를 신뢰하지 말고—각 요청을 검증하라. 사람이 사무실에 있든 호텔 와이파이에 접속하든 홈 네트워크에 있든 접근 결정은 위치가 아니라 정체성, 디바이스 신호, 컨텍스트에 기반해야 합니다.
내부 앱을 사설 네트워크 뒤에 두고 퍼리미터가 유지되길 바라는 대신, 제로 트러스트 접근은 애플리케이션 앞에 위치해 모든 연결 시도를 평가합니다. 일반적 용도는:
액세스 결정이 ID 공급자(SSO), MFA, 그룹 멤버십에 직접 연결되는 것이 핵심 변화입니다. 이러한 검사가 엣지에서 실행되면 지역과 앱 전반에 걸쳐 일관되게 적용할 수 있습니다.
일반적 실수는 제로 트러스트를 VPN 대체로만 보고 거기서 멈추는 것입니다. VPN 제거가 사용성을 개선할 수 있지만, 약한 정체성 관행, 넓은 권한, 누락된 디바이스 검사를 자동으로 고치지는 않습니다.
또 다른 함정은 "한 번 승인하면 계속 신뢰"하는 것입니다. 제로 트러스트는 최소 권한, 세션 시간 제한, 로그 검토(특히 권한이 높은 도구에 대해)가 있을 때 가장 잘 작동합니다.
API는 엣지 네트워크에 큰 영향을 미쳤습니다. 단일 웹사이트는 몇 개의 페이지만 가질 수 있지만 현대 애플리케이션은 모바일 클라이언트, 파트너 통합, 내부 도구, 자동화 작업에서 수십 또는 수백개의 API 엔드포인트를 노출할 수 있습니다. 자동화가 늘어나면 정상 트래픽과 악성 트래픽이 섞여 퍼리미터로 계속 들어옵니다.
API는 예측 가능하고 가치가 높으며 대규모 호출이 쉽습니다: 구조화된 데이터를 반환하고 로그인과 결제를 구동하며 대량 호출이 가능합니다. 따라서 엣지가 요청자 근처에서 API 트래픽을 라우팅, 캐시, 필터링할 수 있다면 지연을 줄이고 오리진을 낭비하는 정크 요청을 피할 수 있습니다.
엣지 플랫폼은 보통 API 게이트웨이 스타일 기능을 제공합니다:
목표는 한 번에 모든 것을 잠그는 것이 아니라 명백히 잘못된 트래픽을 초기에 멈추고 나머지는 관찰하기 쉽게 만드는 것입니다.
API 남용은 전형적 웹 공격과 다르게 보이는 경우가 많습니다:
실무적으로는 세 가지 기능을 우선하세요: 충분한 로그, 토큰별 레이트 리밋(단순 IP 뿐만 아니라), 그리고 명확하고 일관된 오류 응답(개발자가 클라이언트를 빠르게 고치고 보안팀이 실패와 공격을 구분할 수 있게). 이런 기능이 엣지에 내장되면 API가 더 빠르고 오리진에서의 놀람이 줄어듭니다.
엣지 컴퓨트는 요청이 오리진으로 가기 전에 사용자 근처 서버에서 작은 코드 조각을 실행하는 것을 의미합니다. 전통적 CDN이 응답을 단순히 캐시하는 역할만 하던 것과 달리, 엣지는 이제 결정 내리기, 요청 변환, 심지어 현장에서 응답 생성까지 할 수 있습니다.
초기 이익은 대부분 모든 요청에서 빠르게 실행되어야 하는 "얇은 로직"에서 옵니다:
이 작업들이 사용자에 가까운 곳에서 일어나면 오리진 왕복을 줄이고 핵심 시스템의 부하를 낮춰 속도와 신뢰성을 개선합니다.
엣지 컴퓨트는 로직이 가볍고 시간 민감할 때 가장 유용합니다: 라우팅, 접근 게이팅, 트래픽 형태 조정, 지역 간 일관된 규칙 집행 등.
무거운 애플리케이션 로직, 장기 실행 작업, 큰 의존성, 깊은 DB 접근과 강한 일관성이 필요한 작업은 여전히 오리진(또는 중앙 백엔드)이 더 적합합니다.
엣지 런타임은 의도적으로 제약이 있습니다:
실무적 접근은 엣지 컴퓨트를 애플리케이션의 빠른 "프론트 데스크"로 보고—초기 검사와 결정을 처리하고—오리진에는 복잡한 백오피스 작업을 맡기는 것입니다.
엣지 컴퓨트는 이야기의 절반에 불과합니다. 함수가 사용자 근처에서 실행되지만 매 요청마다 먼 리전에서 데이터를 가져와야 한다면 지연 이점의 대부분을 잃습니다—오히려 새로운 장애 지점을 도입할 수도 있습니다. 그래서 엣지 플랫폼은 컴퓨트 근처에 위치한 데이터 서비스(키-값 저장소, 객체 스토리지, 비동기 작업용 큐, 경우에 따라 데이터베이스)를 추가합니다.
팀들은 보통 간단하고 읽기 중심의 데이터를 먼저 저장합니다:
패턴은: 읽기는 엣지에서, 쓰기는 복제 시스템 쪽으로 흐르는 구조입니다.
"최종적 일관성(eventual consistency)"은 보통: 쓰기 직후 서로 다른 위치가 일시적으로 다른 값을 볼 수 있다는 뜻입니다. 제품팀 관점에서는 "한 사용자가 30초 동안 옛 플래그를 봤다"거나 "로그아웃이 즉시 전파되지 않았다"는 식으로 나타납니다.
실용적 완화책은:
속도 주장만 보지 마세요:
엣지 스토리지의 최적 활용은 무엇이 지금 당장 정확해야 하고 무엇이 나중에 정확해져도 되는지를 명확히 하는 데서 시작합니다.
엣지 네트워크가 캐싱을 넘어서 성장하면 예측 가능한 패턴이 나타납니다: 통합(consolidation). DNS, CDN, DDoS 보호, WAF, 봇 제어, 앱 접근을 따로 묶어 쓰던 대신 조직은 트래픽 진입과 흐름을 조정하는 단일 제어 플레인으로 모이게 됩니다.
실무적 동력은 운영 중력(operational gravity)입니다. 이미 대부분의 인바운드 트래픽이 한 엣지를 통과한다면 같은 경로에 더 많은 의사결정을 붙이는 것이 더 간단합니다—라우팅, 보안 정책, 정체성 검사, 애플리케이션 가속 등—추가 홉이나 더 많은 벤더를 관리할 필요 없이 말입니다.
통합은 팀을 더 빠르고 안정적으로 만듭니다:
중앙화는 실질적 트레이드오프를 가져옵니다:
엣지를 도구가 아닌 플랫폼으로 다루세요:
잘 하면 통합은 일상 운영 복잡성을 줄여주고—거버넌스는 그 편의가 숨은 위험으로 변하는 것을 막아줍니다.
엣지 플랫폼을 고르는 것은 단순히 "더 빠른 CDN"을 고르는 것이 아닙니다. 핵심 트래픽이 검사되고 가속되며 때로는 실행되는 장소를 선택하는 것입니다—종종 애플리케이션에 도달하기 전에 말입니다. 좋은 평가는 플랫폼 기능을 실제 제약(사용자 경험, 리스크, 개발자 생산성)에 연결합니다.
필요한 것을 세 가지 버킷으로 적어보세요:
"반드시 필요"를 측정 가능한 결과(예: 사고 수 감소, 지연 시간 감소, 오리진 부하 감소)에 연결할 수 없다면 옵션으로 취급하세요.
새 앱을 빌드하면서 퍼리미터를 현대화 중이라면 개발 워크플로가 이 엣지 자세와 어떻게 연결되는지도 평가하세요. 예를 들어 Koder.ai를 사용해 React 웹 앱(Go + PostgreSQL 백엔드 또는 Flutter 모바일 클라이언트)을 빠르게 배포하는 팀은 엣지 플랫폼을 통해 일관된 TLS 종료, WAF 정책, 레이트 리밋을 활용하면서도 소스 코드를 내보내 원하는 곳에 배포할 수 있는 선택권을 유지할 수 있습니다.
기능 이름이 아니라 구체적인 내용을 물어보세요:
유의미한 트래픽이 있는 한 개 앱(또는 한 API)을 선택하세요. p95 지연, 오류율, 캐시 적중률, 차단된 공격 수, 완화 소요 시간 같은 성공 지표를 정의하세요. 단계별 모드(모니터 → 집행)로 운영하고 롤백 계획(DNS 되돌리기, 우회 규칙, 문서화된 “비상 탈출” 경로)을 준비하세요.
결과가 나오면 /pricing에서 요금제를 비교하고 /blog에서 관련 설명과 배포 사례를 검토하세요.
엣지 네트워크는 여러 도시에 분산된 서버들(Points of Presence)로 구성되어 요청을 사용자에 더 가깝게 처리할 수 있게 해줍니다. 요청 상황에 따라 엣지는:
실제 효과는 지연 시간 감소와 오리진 인프라의 부하 및 노출을 줄이는 것입니다.
퍼리미터(perimeter)는 인터넷 트래픽이 처음으로 귀사 시스템에 닿는 경계입니다—웹사이트, 앱, API가 여기에 해당하며 보통 DNS와 엣지 리버스 프록시를 통해 접속합니다. 중요 포인트는:
퍼리미터에 제어를 집중하면 트래픽이 핵심 서비스에 도달하기 전에 일관된 성능·보안 규칙을 적용할 수 있습니다.
전통적 CDN은 엣지 위치에 정적 콘텐츠(이미지, CSS, JS, 다운로드 등)를 캐시하는 데 집중해 속도를 개선하고 오리진 부하를 줄입니다.
반면 현대적 엣지 플랫폼은 대부분의 트래픽에 대해 완전한 리버스 프록시로 동작하면서 라우팅, 보안 검사, 접근 제어, 경우에 따라서는 컴퓨트 기능까지 제공합니다—콘텐츠가 캐시 가능하든 아니든요.
DNS는 CDN/엣지 제공자를 앞단에 배치하는 가장 간단한 방법입니다: 도메인이 제공자를 가리키면 제공자는 방문자를 가까운 PoP로 라우팅합니다.
많은 구성에서 엣지는 리버스 프록시로 동작해 사용자가 먼저 엣지에 연결하고, 필요할 때만 엣지가 오리진에 연결합니다. 이 ‘중간에 위치한’ 점이 대규모 캐싱, 라우팅, 보안 적용을 가능하게 합니다.
엣지가 TLS를 종단(terminate)하면 HTTPS 연결이 엣지에서 수립됩니다. 이는 실무적으로 세 가지 능력을 제공합니다:
제어가 늘어나지만 엣지 구성은 운영상 매우 중요해집니다.
CDN 성능을 평가할 때 사용자 경험과 인프라 비용에 직접 연결되는 지표를 보세요:
이 지표들을 오리진 측 지표(CPU, 요청률, 이그레스)와 함께 보면 CDN이 실제로 의미 있는 부담 완화를 제공하는지 확인할 수 있습니다.
DDoS 공격은 많은 경우 볼류메트릭(대역폭을 채우는) 성격을 띠므로 엣지에서 방어하는 것이 유리합니다.
분산된 엣지는:
오리진에서만 방어하면 업스트림 링크 포화, 로드밸런서 과부하, 예기치 않은 비용 부담을 먼저 겪게 됩니다.
레이트 리밋은 특정 기간 내에 클라이언트(또는 토큰)가 만들 수 있는 요청 수를 제한해 한 소스가 자원을 독점하지 못하게 합니다.
일반적 엣지 활용 사례는:
모든 DDoS를 막지는 못하지만 남용성 급증을 완화하는 강력하고 이해하기 쉬운 수단입니다.
WAF는 HTTP 요청을 검사해 SQL 인젝션(SQLi)이나 XSS 같은 일반적인 웹 공격 패턴을 차단하는 규칙을 적용합니다. 봇 관리(Bot management)는 자동화된 트래픽을 식별하고 처리하는 데 초점을 맞춥니다—유용한 봇(검색 엔진 크롤러)과 해로운 봇(스크래핑, 가짜 가입, 크리덴셜 스터핑)을 구분합니다.
실무적 도입 방법은:
제로 트러스트는 네트워크 위치가 아니라 정체성(identity)과 컨텍스트에 따라 접근을 결정하는 접근 모델입니다. 엣지에서 보통 다음과 같이 적용됩니다:
피해야 할 실수는 단순히 VPN 대체만으로 끝내는 것입니다. 권한 범위 축소, 세션 시간 제한, 디바이스 검사 같은 보완 조치가 있어야 제로 트러스트의 이점이 유지됩니다.
엣지는 API 트래픽에 특히 중요합니다. API는 예측 가능하고 가치가 높으며 대규모로 호출되기 쉬워 공격 대상이 되기 쉽습니다. 엣지에서 API를 라우팅, 캐시, 필터링하면 지연을 줄이고 오리진 자원을 낭비하는 악성 요청을 막을 수 있습니다.
필수 엣지 제어 기능은:
우선 눈에 띄는 악성 요청을 조기에 차단하고 나머지는 관찰하기 쉽게 만드는 게 목표입니다.