자동화 도구에 권한을 줄 때 가장 위험한 표현은 ‘일단 관리자 권한으로 해보고 나중에 줄이자’입니다. CI 파이프라인이나 AI 에이전트가 계정 전체를 수정할 수 있으면 설정 오류나 토큰 유출 한 번이 여러 서비스의 장애로 이어질 수 있습니다.
Cloudflare는 2026년 9월 15일 Workers의 권한을 개별 애플리케이션 단위로 제한하고 수행 가능한 작업도 네 역할로 나누는 기능을 공개했습니다. 특정 플랫폼을 넘어 자동화 계정에 최소 권한을 설계할 때 참고할 만한 구조입니다.
3줄 핵심 요약
- Cloudflare Workers는 계정 전체가 아니라 특정 애플리케이션 하나에 사용자와 API 토큰 권한을 제한할 수 있게 됐습니다.
- 관측 정보, 소스 읽기, 배포, 삭제 권한을 네 역할로 나눠 업무에 필요한 수준만 부여합니다.
- CI와 AI 에이전트의 토큰이 노출되거나 오작동해도 다른 애플리케이션과 계정 자원으로 피해가 번지지 않게 해야 합니다.

역할과 범위를 따로 정하기
권한은 ‘무엇을 할 수 있는가’와 ‘어디에서 할 수 있는가’의 조합으로 봐야 합니다. Cloudflare는 메타데이터 읽기, 콘텐츠 읽기, 편집과 관리 역할을 제공하고 범위는 개발자 플랫폼 전체, 특정 제품 전체, 개별 Worker로 나눕니다.
같은 읽기 권한도 모든 애플리케이션에 적용할지 하나에만 적용할지에 따라 위험이 크게 달라집니다. 사람과 자동화 모두 업무에 필요한 가장 좁은 역할과 자원 범위를 선택해야 합니다.
디버깅에는 소스 코드가 필요하지 않을 수 있다
장애를 조사하는 엔지니어나 에이전트는 설정, 지표, 로그와 추적 정보만으로 원인을 찾을 수 있는 경우가 많습니다. Metadata Read-Only 역할은 관측 데이터에 접근하면서 Worker 소스와 변경 권한을 노출하지 않는 용도입니다.
조사 도구가 하나의 Worker에만 제한되면 같은 계정의 다른 서비스 로그와 설정도 볼 수 없습니다. 진단 편의를 이유로 읽기 범위를 무조건 넓히기보다 필요한 데이터 종류부터 구분하는 것이 좋습니다.
코드 리뷰와 배포 권한도 분리하기
리뷰 에이전트는 코드를 읽어야 하지만 배포하거나 설정을 바꿀 필요는 없습니다. Content Read-Only 역할은 소스 조회와 수정 권한을 분리합니다.
반대로 CI 파이프라인은 새 버전을 배포해야 하므로 Editor가 필요할 수 있지만 애플리케이션 삭제까지 허용할 이유는 적습니다. 워크플로마다 특정 Worker 하나에 제한된 별도 API 토큰을 사용하면 토큰이 노출돼도 다른 애플리케이션과 계정 전체로 피해가 확산되는 것을 줄일 수 있습니다.
삭제와 트래픽 경로 변경은 별도 통제하기
Admin은 애플리케이션 삭제가 가능한 가장 높은 역할이므로 일상적인 배포 계정에 부여하지 않는 편이 안전합니다. Worker에 연결된 경로나 사용자 도메인을 바꾸는 작업은 실제 운영 트래픽을 다른 곳으로 돌릴 수 있어 Worker 편집 권한 외에 별도의 Routes 권한도 요구됩니다.
이미 연결된 경로를 바꾸지 않는 배포는 도메인 권한 없이 수행할 수 있습니다. 배포, 삭제, 트래픽 전환을 서로 다른 승인 단계로 나누면 자동화 실수의 영향 범위를 제한할 수 있습니다.
권한 부족 오류를 권한 확대 요청서로 사용하기
권한을 좁게 주면 자동화가 403 오류를 만날 수 있습니다. 이때 문제를 빨리 해결하려고 관리자 권한을 추가하기보다 실패한 API, 대상 자원과 필요한 작업을 확인해야 합니다.
Cloudflare는 거부 응답에 관련 API 문서 링크를 포함해 필요한 권한을 찾도록 개선했다고 설명합니다. 조직에서는 권한 추가 요청에 목적, 대상, 만료일과 검토자를 기록하고 일정 기간 사용되지 않은 토큰과 역할을 정기적으로 회수하는 절차가 필요합니다.
사용자와 업계에 미치는 영향
리소스 단위 권한은 AI 에이전트와 자동화 파이프라인을 운영 환경에 연결할 때 피해 반경을 줄입니다. 팀은 디버깅, 리뷰, 배포와 삭제를 서로 다른 역할로 나누고 프로젝트마다 독립된 자격 증명을 발급할 수 있습니다.
토큰이 유출되거나 에이전트가 잘못된 명령을 선택해도 접근 가능한 자원과 행동이 제한됩니다. 이런 구조는 속도를 포기하는 보안 조치라기보다 자동화를 더 넓게 적용하기 위한 안전 경계에 가깝습니다.
확인할 점
세분화된 역할을 제공해도 실제 할당이 넓으면 최소 권한 효과는 사라집니다. Worker 배포가 데이터베이스, 저장소, 비밀값 또는 도메인 변경을 함께 요구한다면 각 연결 자원의 권한을 별도로 분석해야 합니다.
기존 레거시 역할은 계속 동작하므로 새 역할로 전환할 때 누락과 중복 권한을 점검해야 합니다. 기능이 다른 Cloudflare 제품으로 확대되는 일정과 지원 범위는 향후 달라질 수 있으므로 최신 공식 문서를 확인해야 합니다.
출처
'수수께끼연구소' 카테고리의 다른 글
| 쇼핑몰이 멀쩡해 보여도 위험할 수 있다: 악성 자바스크립트 점검법 (0) | 2026.09.17 |
|---|---|
| AWS 가입부터 비용 관리까지 쉬워진다? 새 시작 화면에서 꼭 확인할 5가지 (0) | 2026.09.17 |
| 검색 노출은 유지하고 AI 학습은 거부할 수 있을까? (0) | 2026.09.16 |
| AI 에이전트에 GitHub 권한을 줄 때: OAuth 동의 설계 5가지 (0) | 2026.09.15 |
| 이번 주 AWS 핵심 4가지: GPT-6 Astra부터 90분 Lambda까지 (0) | 2026.09.15 |