모든 내부 바이브 코딩 애플리케이션을 한 번의 클릭으로 안전하게 보호하세요 (새 탭에서 열림)
AI로 애플리케이션 개발·배포가 쉬워진 만큼, 직원이 실수로 내부 애플리케이션이나 데이터를 인터넷에 노출할 위험도 커졌다. Cloudflare는 이를 막기 위해 Workers에 Cloudflare Access를 직접 연결해, 애플리케이션 코드나 개발자의 설정에 의존하지 않고 기본적으로 인증을 강제할 수 있도록 했다. 계정 전체, 개별 Worker, 프리뷰 환경에 정책을 적용하고, 코드에서는 별도의 JWT 검증 없이 인증 사용자 정보를 사용할 수 있다. ## Worker 단위로 적용하는 Cloudflare Access - Access를 Worker에 활성화하면 요청이 애플리케이션 코드에 도달하기 전에 인증이 수행된다. - 다음과 같은 접근 경로를 모두 보호할 수 있다. - 커스텀 도메인 - 라우트 - `workers.dev` 서브도메인 - 프리뷰 URL - 기존에는 호스트 이름별로 Access 정책을 설정해야 했기 때문에 새 도메인을 추가할 때마다 정책도 갱신해야 했다. - 이제 정책이 호스트 이름이 아닌 Worker에 연결되므로, 해당 Worker에 연결된 새 도메인과 URL도 자동으로 보호된다. - 보호 범위는 다음 중에서 선택할 수 있다. - 프리뷰 URL만 보호 - 모든 호스트 이름 보호 - 기존 IdP를 연결하거나 특정 이메일 주소, 도메인, 그룹만 허용할 수 있으며, 에이전트에는 서비스 토큰을 사용할 수 있다. ## 계정 전체의 Worker를 기본적으로 비공개 처리 - 계정 수준에서 Access 정책을 설정하면 현재 및 향후 생성되는 모든 Worker가 기본적으로 비공개가 된다. - 정책 적용 범위는 다음과 같이 선택할 수 있다. - 프리뷰 트래픽만 - 프로덕션 트래픽만 - 프리뷰와 프로덕션 모두 - 프로덕션은 공개해야 하지만 개발 중인 배포는 노출되면 안 되는 경우, 프리뷰 전용 정책이 유용하다. - 특정 Worker를 공개해야 한다면 계정 전체 정책을 해당 Worker에서 우회할 수 있다. ## 개별 Worker 정책과 우선순위 - 계정 전체를 잠그지 않고 특정 애플리케이션만 보호하는 것도 가능하다. - Worker 화면의 새로운 Access 탭에서 해당 애플리케이션에 적용되는 정책을 확인할 수 있다. - 여러 정책이 겹칠 경우 우선순위는 다음과 같다. 1. 호스트 이름 정책 2. Worker 정책 3. 계정 정책 ## 코드에서 인증 사용자 정보 확인 - Access가 Worker를 보호하면 요청의 `ctx` 객체에 인증 사용자 정보가 포함된다. - `ctx.access.getIdentity()`를 호출해 다음 정보를 얻을 수 있다. - 이메일 - 이름 - 그룹 - 기존에는 JWT를 직접 파싱하고 서명을 검증한 뒤 클레임을 추출해야 했지만, 이제는 Worker에서 바로 identity 객체를 사용할 수 있다. ```js export default { async fetch(request, env, ctx) { if (!ctx.access) { return new Response("Access required", { status: 403 }); } const identity = await ctx.access.getIdentity(); const email = identity?.email ?? "unknown"; return new Response(`Hello, ${email}`); } }; ``` - 사용자별 화면 구성, 권한 검사, 사용자 단위 감사 로그 등에 활용할 수 있다. ## 로컬 개발 환경에서 인증 사용자 시뮬레이션 - 배포 전에 `wrangler dev`에서 Access 사용자 정보를 테스트할 수 있다. - `wrangler.jsonc`에 개발용 Access identity를 설정한다. ```json { "access": { "dev": { "aud": "my-app", "identity": { "email": "admin@company.com" } } } } ``` - 로컬 요청에서도 `ctx.access.getIdentity()`가 프로덕션과 유사한 identity 객체를 반환한다. - 이메일 주소를 바꿔가며 사용자별 콘텐츠와 권한 동작을 배포 없이 검증할 수 있다. ## 내부 애플리케이션 플랫폼 보호 - Workers for Platforms를 이용하면 여러 애플리케이션을 대규모로 배포할 수 있다. - 각 Worker가 네임스페이스에 배포되고, 모든 요청은 하나의 dispatch Worker를 거친다. - dispatch Worker에 Access 정책을 한 번만 설정하면 이를 통해 배포되는 모든 Worker가 기본적으로 비공개가 된다. - 내부 드래그 앤 드롭 배포 플랫폼처럼 직원용 애플리케이션 플랫폼을 구축할 때 유용하다. ## FL2 기반 요청 처리 구조 - Worker 단위 Access 적용은 Cloudflare의 Rust 기반 모듈형 프록시인 FL2를 기반으로 한다. - Access가 실행되기 전에 요청이 어느 Worker로 라우팅될지 알아야 하므로, Workers 라우팅과 실행 로직을 분리해야 했다. - 라우팅을 Access보다 앞 단계로 이동함으로써 호스트 이름이 아니라 개별 Worker를 기준으로 인증 정책을 적용할 수 있게 되었다. - 기존 NGINX·Lua 기반 FL1 구조에서는 요청 파이프라인의 로직을 앞 단계로 옮기는 작업이 복잡하고 위험할 수 있었지만, FL2가 이를 가능하게 했다. 개발 조직에서는 계정 수준에서 프리뷰 배포를 우선 보호하고, 공개가 필요한 Worker만 명시적으로 예외 처리하는 방식이 실용적이다. 내부 플랫폼을 운영한다면 dispatch Worker에 Access를 적용해 새로 배포되는 모든 애플리케이션을 비공개 상태로 시작하는 것이 안전하다.
