cloudflare2026년 8월 14일

Cloudflare는 MCP 트래픽을 어떻게 탐지하고 보안을 강화하는가 (새 탭에서 열림)

AI 에이전트는 기존 사용자보다 훨씬 빠르고 반복적으로 도구를 호출할 수 있어, 한 번의 잘못된 판단이 대규모 권한 오용으로 확산될 수 있다. MCP는 에이전트가 SaaS, 내부 애플리케이션, API의 도구를 호출하게 해주지만, 승인되지 않은 서버로 직접 연결하는 ‘Shadow MCP’가 일반 HTTPS 트래픽처럼 보일 수 있다는 문제가 있다. 따라서 클라이언트·네트워크·MCP 서버의 각 지점에서 호출을 식별하고, 검사하며, 실행 전 차단하는 다층 통제가 필요하다. ## AI 에이전트가 기존 권한 모델을 바꾸는 이유 - 기존 권한 체계는 사용자가 판단하고, 사람의 속도로만 작업한다는 가정에 기반했다. - AI 에이전트는 판단이 비결정적이며, 같은 도구를 피로 없이 반복 호출할 수 있다. - 잘못된 판단 하나가 사람이 알아차리기 전에 수천 건의 잘못된 작업으로 확대될 수 있다. - 에이전트 연결은 한 줄의 설정만으로 가능해, 직원이 승인 여부를 확인하지 않고 MCP 서버를 사용할 위험이 있다. ## MCP 도구 호출의 구조와 보안 신호 MCP 호출은 시스템의 위치에 따라 세 가지 형태로 나타난다. - 클라이언트 내부에서는 특정 도구와 인자를 호출하기로 한 에이전트의 결정이다. - 네트워크에서는 JSON-RPC 메시지를 담은 HTTP 요청이다. - 서버에서는 실제 도구 핸들러를 실행하는 작업으로 변환된다. - 요청에는 다음과 같은 식별 정보가 포함된다. - `Host`, 경로: 대상 서버 식별 - `Authorization`: 호출자 인증 정보 - `MCP-Protocol-Version`: MCP 프로토콜 버전 - `Mcp-Method`: 수행할 작업 - `Mcp-Name`: 호출할 도구 이름 - `id`: 요청과 응답을 연결하는 식별자 - `params`: 도구 인자 - 특히 `params`에는 검색어, 소스 코드, 고객 데이터, 티켓 생성이나 인프라 변경 지시가 포함될 수 있어 가장 민감하다. - 응답에도 도구가 반환한 민감한 데이터가 포함될 수 있으므로 요청뿐 아니라 응답 검사와 로깅도 중요하다. - MCP는 특정 호스트명이나 `/mcp` 경로를 반드시 요구하지 않기 때문에, 승인되지 않은 직접 연결이 일반 HTTPS API 호출처럼 보일 수 있다. ## 클라이언트 내부 통제 - 모델이 도구를 선택한 뒤 실제 요청으로 직렬화하기 전에 서버, 도구 이름, 인자를 검사할 수 있다. - 승인 목록에 없는 서버를 차단할 수 있다. - 민감한 작업에 사용자 확인을 요구할 수 있다. - 요청이 기기를 떠나기 전에 인자에서 민감한 데이터를 제거할 수 있다. - 네트워크를 사용하지 않는 로컬 `stdio` MCP 서버도 통제할 수 있다. - 단점은 사용하는 모든 MCP 클라이언트마다 통제를 별도로 구현해야 한다는 점이다. - 조직이 클라이언트와 기기를 모두 관리할 때 효과적이지만, 단일 클라이언트의 telemetry만으로는 전체 MCP 사용 현황을 파악할 수 없다. ## 네트워크 경계에서의 탐지와 차단 - 보안 웹 게이트웨이는 요청이 클라이언트를 떠난 뒤 HTTP 트래픽을 관찰한다. - TLS 복호화를 적용하면 사용자와 기기, 대상 서버, MCP 관련 헤더를 함께 식별할 수 있다. - 특정 MCP 클라이언트에 의존하지 않고 관리되는 네트워크 경로의 원격 MCP 트래픽을 폭넓게 탐지할 수 있다. - 승인된 MCP Portal을 거치지 않는 직접 연결을 목적지에 도달하기 전에 차단할 수 있다. - DLP 기능을 사용하면 JSON-RPC 메서드와 인자를 검사해 민감한 데이터 전송을 차단하거나 기록할 수 있다. - 다만 로컬 `stdio` 호출이나 조직 네트워크 밖에서 발생한 트래픽은 볼 수 없다. ## MCP 서버에서의 실행 전 통제 - MCP 서버는 호출자를 인증하고, 메시지를 해석하며, 도구와 인자를 검증한 뒤 실행하는 가장 풍부한 실행 컨텍스트를 가진다. - 도구 핸들러가 실행되기 전에 다음 정책을 적용할 수 있다. - 호출자별 도구 권한 확인 - 호출 횟수 제한 - 인자 검사 - 실행 결과와 승인 여부 기록 - 읽기 작업은 허용하되, 쓰기 작업에는 에이전트 식별 정보와 감사 이벤트를 추가할 수 있다. - 중요 작업은 핸들러 실행 전에 차단해야 하며, 실행 후 로그만 남기는 방식으로는 피해를 예방할 수 없다. - Cloudflare의 WriteGuard는 도구별 위험 등급과 활성화 상태를 사용해 읽기·쓰기·중요 작업을 차등 처리한다. - 서버 측 통제는 사용자가 클라이언트를 바꾸거나 로컬 훅을 비활성화해도 우회하기 어렵다. - 단, 해당 통제를 구현한 MCP 서버만 보호할 수 있다는 한계가 있다. ## Cloudflare One과 MCP Portal의 역할 - Cloudflare One은 검사된 MCP 트래픽을 식별하고, 어떤 사용자와 서버가 생성했는지 보여주는 기능을 제공한다. - 관리 네트워크 경로에서 직접 연결을 통제해 승인된 MCP Portal 경로만 사용하도록 강제할 수 있다. - 이를 통해 관리자는 에이전트가 승인된 경로를 이용하는지, 아니면 MCP Portal을 우회해 서버에 직접 연결하는지 확인할 수 있다. - 네트워크 계층은 가장 넓은 범위의 원격 MCP 연결을 감시하고, 클라이언트와 서버 계층은 요청 내용과 실행 맥락을 더 깊이 통제한다. ## 실용적인 권장 방식 MCP 보안은 한 지점에 의존하기보다 다층으로 구성하는 것이 적절하다. 클라이언트에서는 민감한 요청을 사전 확인하고, 네트워크에서는 Shadow MCP와 Portal 우회 연결을 탐지·차단하며, 서버에서는 도구별 권한·위험 등급·속도 제한을 적용해야 한다. 특히 데이터 변경이나 외부 시스템 조작을 수행하는 도구는 반드시 서버에서 실행 전에 검증하고 감사 로그를 남겨야 한다.

access-controlai-agentmodel-context-protocoldata-loss-prevention+4

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)을 적용해, 자격 증명만 탈취한 공격자가 하네스의 증명 키 없이 재사용하지 못하도록 한다. ## 실용적인 적용 방향 - 에이전트마다 장기 서비스 계정과 광범위한 정적 키를 제공하지 말고, 작업별 단기 자격 증명을 발급하는 것이 우선이다. - 프롬프트의 금지 문구에 의존하지 말고 하네스와 네트워크 계층에서 도구·데이터·외부 전송을 직접 제한해야 한다. - 모든 행동에 인간 승인을 넣기보다 고위험 작업에만 승인 절차를 적용해야 한다. - 활동 로그를 통해 권한 범위를 지속적으로 줄이되, 실행 중인 작업의 권한을 사후에 넓히지 않는 원칙을 유지해야 한다.

access-controlzero-trustaudit-loggingleast-privilege+2

cloudflare2026년 8월 5일

Cloudflare OS: 에이전트, 앱 및 업무를 위한 개방형 플랫폼 (새 탭에서 열림)

Cloudflare OS는 회사의 지식·절차·용어·시스템을 에이전트가 활용하도록 만들어, 엔지니어뿐 아니라 모든 직원이 업무를 자동화하고 앱과 문서를 만들 수 있게 하는 플랫폼이다. 초기 버전의 한계였던 정적 앱, 반복적인 에이전트 실행, 데이터 권한 관리 문제를 해결하기 위해 보안과 거버넌스를 플랫폼의 핵심으로 재설계했다. 새 버전은 오픈 소스로 제공되며, 조직이 내부 시스템과 업무 방식을 연결해 직접 구축하고 확장할 수 있다. ## 조직의 맥락을 에이전트에게 전달하기 - 조직은 미션과 함께 고유한 용어, 절차, 시스템, 표준, 업무 방식을 구성원에게 전달한다. - 업무 결과는 코드뿐 아니라 문서, 발표 자료, 인간관계, 물리적 성과 등 다양한 형태로 나타난다. - 코드는 실행 여부라는 명확한 피드백이 있지만, 비정형 업무에는 조직의 맥락과 시스템 접근 권한이 필요하다. - Cloudflare OS는 회사가 축적한 지식과 반복 업무의 모범 사례를 에이전트가 따를 수 있는 컨텍스트와 스킬로 저장한다. - 한 사람이 더 나은 업무 방식을 만들면 조직 전체가 이를 재사용할 수 있다. ## 초기 버전에서 얻은 한계와 교훈 - 초기 Cloudflare OS는 개인별 비공개 워크스페이스 중심이었다. - 앱은 내부 시스템과 실시간으로 연결된 소프트웨어가 아니라 정적인 결과물에 가까웠다. - 결정적인 반복 작업도 스킬을 다시 실행해야 했고, 그만큼 추가 모델 토큰을 소비했다. - MCP 서버가 제공하는 도구 목록만으로는 에이전트가 실제로 어떤 데이터와 리소스를 관찰했는지 알 수 없었다. - 워크스페이스와 앱을 공유하면서, 사용자가 권한 없는 정보를 간접적으로 볼 가능성이 커졌다. - 이에 따라 보안을 앱 제작자나 개별 사용자에게 맡기지 않고 플랫폼 수준에서 처리하도록 새 기반을 설계했다. ## Cloudflare OS의 세 가지 구성 요소 - **조직 컨텍스트 기반 에이전트 워크스페이스** - 회사가 선별한 지식과 스킬을 바탕으로 대화하고 작업한다. - 에이전트가 코드를 작성·실행할 수 있는 격리된 런타임을 제공한다. - **보안·거버넌스 프레임워크** - 내부 데이터와 서비스에 대한 접근을 정책에 따라 통제한다. - 에이전트와 앱이 접근할 수 있는 리소스와 데이터의 이동 경로를 관리한다. - **수정 가능한 개인·협업 앱 플랫폼** - 대화에서 시작한 작업을 문서, 앱, 지속 실행 워크플로로 발전시킬 수 있다. - 사용자가 만든 앱을 공유하고 계속 수정할 수 있다. ## 브라우저 기반 에이전트 워크스페이스 - 개발자나 터미널 사용법을 몰라도 브라우저에서 사용할 수 있도록 설계됐다. - 워크스페이스는 다음 요소를 결합한다. - 에이전트 세션 - 지속 상태 - 파일과 산출물 - 외부 리소스 접근 - 코드를 작성하고 실행하는 격리 런타임 - 팀이나 회사가 수집한 컨텍스트와 스킬이 기본으로 포함되어 동일한 업무 절차를 매번 다시 설명할 필요가 없다. ### 조사와 질의 - 회사 컨텍스트와 허용된 리소스를 기반으로 주제를 조사할 수 있다. - 전체 데이터를 모델 컨텍스트에 넣는 대신, 에이전트가 코드를 작성해 검색·필터링·조인·분석을 수행한다. ### 문서·슬라이드·스프레드시트 생성 - 조사 결과를 문서, 프레젠테이션, 스프레드시트로 변환할 수 있다. - 결과물은 단순한 정적 파일이 아니라 원본 데이터와 연결된 상태로 유지될 수 있다. - 데이터가 변경되면 결과물을 갱신할 수 있으며, Google Drive 같은 기존 서비스나 익숙한 형식으로 내보낼 수도 있다. ### 협업 앱 구축 - 문서나 스프레드시트로 부족한 경우, 에이전트가 자체 인터페이스·로직·상태를 가진 앱을 만든다. - 앱은 회사 리소스와 연결될 수 있고 여러 사람이 함께 사용할 수 있다. ### 결정적 워크플로 실행 - 반복적인 업무의 예측 가능한 단계는 코드로 처리하고, 판단이 필요한 부분에만 모델을 사용한다. - 워크플로는 수동 실행, 예약 실행, 연결된 시스템의 이벤트 발생 시 실행이 가능하다. - 기존 MCP 서버는 MCP Server Portals를 통해 계속 사용할 수 있다. ## API 키 대신 세분화된 권한 모델 - 회사 시스템에 연결하기 위해 API 키를 에이전트나 사용자에게 직접 제공하는 방식은 위험하다. - API 키는 대개 권한 범위가 넓고 수명이 길며, 공유와 감사가 어렵다. - MCP 서버는 자격 증명을 내부에 보관하고 제한된 도구만 노출하므로 개선된 접근 방식이다. - 그러나 MCP만으로는 에이전트가 어떤 원본 리소스를 관찰했는지, 이후 데이터가 어디로 이동할 수 있는지까지 통제하기 어렵다. - 따라서 권한 부여는 단순히 “어떤 도구를 호출할 수 있는가”를 넘어 데이터의 후속 사용과 노출 가능성까지 고려해야 한다. ## 무권한 시작과 Gatekeeper 기반 접근 - Cloudflare Access가 Cloudflare OS에 들어올 수 있는 사용자를 통제한다. - OS 내부에서는 모든 에이전트와 앱이 처음에 아무 권한도 갖지 않는다. - 에이전트가 특정 리소스에 대한 접근을 요청하면 관리자가 승인하거나 거부한다. - 승인된 리소스는 생성 코드에 타입이 지정된 바인딩으로 전달된다. ```ts const issues = await env.PROJECT.listIssues({ teamId: "ENG", state: "open", }); ``` - `env.PROJECT`는 특정 리소스와 정책에 대한 권한을 나타내는 capability다. - 실제 인증 정보는 에이전트와 생성된 코드에서 완전히 격리된다. - 이러한 Gatekeeper를 통해 에이전트와 앱이 시스템 오브 레코드에 접근할 때 조직의 정책에 따른 통제가 가능해진다. ## 실용적인 결론 Cloudflare OS의 핵심은 단순히 AI 챗봇을 제공하는 것이 아니라, 조직의 지식과 시스템 접근 권한을 안전하게 결합해 업무 자체를 자동화하는 데 있다. 조직에 도입하려면 먼저 반복 업무를 컨텍스트·스킬·결정적 워크플로로 정리하고, API 키 직접 공유 대신 리소스별 최소 권한과 감사 가능한 접근 정책을 설계하는 것이 중요하다.

access-controlai-agentcloudflaremodel-context-protocol+3

cloudflare2026년 8월 5일

WriteGuard: MCP 서버를 위한 세밀한 제어 (새 탭에서 열림)

AI 에이전트가 외부 시스템에 쓰기 권한을 가지면, 잘못된 프롬프트 하나만으로 사람의 작업 속도를 훨씬 뛰어넘는 대규모 변경을 일으킬 수 있다. Cloudflare는 에이전트별 설정이나 사용자의 감시에 의존하지 않고, MCP 도구 호출을 중앙에서 정책 적용·식별·감사하기 위해 WriteGuard를 구축했다. WriteGuard는 인간 사용자의 권한은 유지하면서 에이전트 세션을 별도로 추적하고, 위험도에 따라 작업을 허용·기록·차단한다. ## MCP의 구조와 에이전트 동작 방식 - MCP(Model Context Protocol)는 AI 애플리케이션이 외부 도구와 데이터에 연결되도록 하는 표준이다. - MCP 서버는 다음 요소를 가진 도구를 제공한다. - 도구 이름 - 설명 - 입력 스키마 - 실제 작업을 수행하는 핸들러 - 에이전트가 도구를 선택하면 MCP 클라이언트가 서버에 호출을 보내고, 서버가 Jira·GitLab·데이터베이스 등 downstream 시스템과 상호작용한다. - 따라서 도구에 쓰기 권한이 부여되면 에이전트가 외부 시스템의 상태를 직접 변경할 수 있다. ## 무제한 쓰기 권한의 위험 - 잘못 작성된 정리 작업 프롬프트가 수천 개의 티켓을 자동으로 닫을 수 있다. - 사람이 직접 수행한 작업과 에이전트가 수행한 작업이 동일한 사용자 계정으로 기록되면 원인 분석과 복구가 어려워진다. - 여러 에이전트 세션이 동시에 실행되면 네트워크 로그만으로 특정 세션을 식별하기 어렵다. - 위험한 사례는 다음과 같다. - 계약 소프트웨어의 계약 내용 변경 - 고객지원 큐에 대량 답변 전송 - 데이터베이스 테이블 전체 삭제 - Cloudflare는 모든 사용자가 에이전트를 완벽하게 설정하거나 모든 도구 호출을 감시할 수 없다고 판단했다. ## Cloudflare의 MCP 확장 - Cloudflare의 내부 에이전트는 OpenCode, Cloudflare OS, 장기 실행 에이전트 서비스 등을 통해 MCP를 사용한다. - 내부 MCP 포털이 여러 서버를 통합하며, 연결된 서버 수는 13개에서 27개로 증가했다. - 초기에는 Jira, GitLab, 위키, 운영 시스템 등을 조회하는 읽기 전용 서버로 시작했다. - 이후 엔지니어링·제품·디자인·영업·고객 성공팀에서 실제 변경 작업을 수행하는 도구를 요구했다. - 클라이언트의 skill이나 elicitation prompt만으로는 통제가 어렵기 때문에 중앙 정책 계층인 WriteGuard를 도입했다. ## WriteGuard의 역할 - WriteGuard는 MCP 서버와 도구 호출 사이에 위치하는 공통 계층이다. - 도구 설정과 요청 컨텍스트를 바탕으로 호출을 다음과 같이 처리한다. - 호출을 그대로 통과 - 에이전트 식별 정보를 추가한 뒤 통과 - 감사 이벤트를 생성 - 핸들러 실행 전에 호출 차단 - WriteGuard는 다음 기능을 하나의 장소에서 제공한다. - 도구별 정책 관리 - 사용자 및 에이전트 신원 연결 - downstream 시스템에 에이전트 정보 표시 - 중앙 감사 로그 수집 ## 도구 위험도 기반 정책 각 도구에는 위험도, 활성화 여부, 라벨링 설정을 지정한다. - **Read Only** - 이슈 검색 - Merge Request 조회 - 파이프라인 상태 확인 - **Minimal Impact** - 리액션 추가 - 알림을 읽음으로 표시 - 이슈 구독 - **Contained Write** - 댓글 작성 - Merge Request 생성 - 이슈 필드 수정 - **Critical** - Merge Request 병합 - 운영 환경 배포 실행 - 레코드 일괄 삭제 위험도는 감사 로그 기록 여부와 호출 허용 여부를 결정하며, 위험도별로 로그를 검색할 수 있다. 또한 서버 코드를 수정하지 않고도 특정 입력 필드에 일반 텍스트나 HTML 형식의 에이전트 라벨을 삽입할 수 있다. ## 사람의 권한을 유지하고 에이전트만 식별 - 내부 MCP 서버는 Cloudflare Access와 OAuth로 사용자를 인증한다. - 에이전트는 별도 계정이 아니라 사용자의 권한을 그대로 사용한다. - 따라서 Joe가 특정 이슈를 닫을 수 없다면 Joe의 에이전트도 닫을 수 없다. - 별도 에이전트 계정을 만들지 않은 이유는 다음과 같다. - 관리해야 할 권한 체계가 추가됨 - 에이전트와 책임자인 사람의 연결이 약해짐 - 대신 WriteGuard는 사용자 신원에 MCP 클라이언트와 세션 정보를 추가한다. - downstream 애플리케이션에는 사람의 권한으로 수행된 작업이라는 정보와 함께, 어떤 에이전트 세션이 작업했는지 표시할 수 있다. ## 중앙 감사 로그와 대규모 활동 분석 - WriteGuard는 각 도구 호출을 성공, 실패, 차단으로 분류한다. - 이후 감사 이벤트를 비동기적으로 내부 audit Worker에 전송한다. - 감사 이벤트에는 다음 정보가 포함된다. - MCP 서버 - 도구 이름 - 위험도 - 호출 결과 - 사용자 - 클라이언트 - 실행 시간 - 비밀번호나 민감한 값으로 분류된 입력 키의 값은 제거한다. - 비동기 로깅을 사용하므로 에이전트가 응답을 기다리는 시간에는 추가 지연이 없다. - MCP 포털 로그가 개별 호출을 보여준다면, WriteGuard 로그는 도구의 의미적 분류·에이전트 컨텍스트·백엔드 처리 결과를 함께 제공한다. - 이를 통해 특정 시스템 하나가 아니라 전체 MCP 환경에서 에이전트의 대량 활동을 검색하고 조사할 수 있다. ## GitLab 적용 방식 - 글에서는 GitLab MCP 서버의 세 도구를 예로 든다. - `get_merge_request`: Merge Request 읽기 - `create_mr_note`: 댓글 또는 노트 작성 - `merge_mr`: Merge Request 병합 - 이 도구들은 각각 읽기, 제한적 쓰기, 중요 쓰기 등 서로 다른 위험도 정책을 적용할 수 있다. - 이를 통해 동일한 GitLab 서버 안에서도 조회는 허용하되 댓글 작성이나 병합은 별도로 기록하거나 차단하는 식의 세밀한 통제가 가능하다. ## 실용적인 결론 MCP 서버에 쓰기 권한을 추가할 때는 단순한 사용자 인증만으로는 부족하다. 도구별 위험도 정책, 에이전트 세션 식별, 민감정보 제거 감사 로그, 사전 차단 기능을 중앙 계층에서 제공해야 하며, 특히 대량 변경이 가능한 작업은 높은 위험도로 분류해 별도 통제하는 것이 안전하다.

access-controlai-agentgitlabmodel-context-protocol+4

netflix2026년 6월 19일

데이터 프로젝트: 넷플릭스 규모로 데이터 자산 관리 (새 탭에서 열림)

Netflix는 수백만 개의 테이블과 수만 개의 워크로드를 개별 자산·사용자 단위로 관리하면서 권한 변경과 워크플로 장애가 반복되는 문제를 겪었다. Data Projects는 관련 자산을 프로젝트로 묶고, 사람과 무관하게 유지되는 프로젝트 전용 신원(identity)을 부여해 권한과 실행 주체의 관리 단위를 상향한다. 이를 통해 조직 개편이나 담당자 변경에도 권한과 데이터 워크플로가 안정적으로 유지되도록 한다. ## 개별 자산 중심 권한 관리의 한계 - 기존에는 모든 테이블에 개별 ACL을 설정해야 했다. - 조직 개편이나 팀 통합 때 수백 개 테이블의 권한을 하나씩 수정해야 했다. - 대규모 권한 변경 요청이 지원팀에 집중됐다. - 관리 부담을 피하기 위해 테이블을 전사 공개하는 사례가 생겨 ACL의 의미가 약화됐다. - Data Projects는 여러 테이블과 워크로드를 하나의 프로젝트로 묶어 프로젝트 단위로 권한을 관리한다. ## 사람에게 종속된 워크로드 신원의 문제 - Maestro 워크플로, Spark 파이프라인, 데이터 이동 작업은 실행 시 신원이 필요했다. - 기존에는 워크플로 작성자의 사용자 계정으로 실행하는 경우가 많았다. - 담당자가 팀을 옮기거나 퇴사하면 계정 권한이 바뀌어 워크플로가 실패했다. - 다른 사람의 계정으로 교체해도 권한이 완전히 같지 않아 새로운 권한 오류가 연쇄적으로 발생했다. - 수만 개의 예약 워크로드를 운영하는 Netflix에서는 이러한 방식이 지속 가능하지 않았다. ## Data Projects의 기본 구조 - Data Project는 관련 데이터 자산을 묶어 관리·조회하는 논리적 컨테이너다. - 포함할 수 있는 자산에는 테이블, 워크플로, 시크릿 등이 있다. - 동시에 사람과 독립적으로 유지되는 합성(synthetic)·지속적(durable) 신원 역할을 한다. - 500개 테이블의 ACL을 각각 관리하는 대신, 하나의 프로젝트에 대한 권한을 관리한다. - 초기 목적은 접근 제어와 실행 신원 통합이지만, 향후 다른 데이터 플랫폼 관리 기능으로 확장될 수 있다. ## 프로젝트 기반 역할과 권한 - 프로젝트 소유 팀이 프로젝트의 grant를 관리한다. - 사용자, 그룹, 애플리케이션, CI 작업 등 다양한 주체를 grant로 추가할 수 있다. - 각 grant에는 프로젝트 내 작업 범위를 결정하는 역할이 부여된다. - 예를 들어: - `Contributor`: 프로젝트 자산에 대한 읽기·쓰기 권한 - `Viewer`: 읽기 전용 권한 - 팀원이 합류하거나 떠날 때 개별 자산 ACL 수백 개를 수정하지 않고 프로젝트 grant 하나만 변경하면 된다. ## Netflix 애플리케이션 ID와 AWS IAM 역할 - 모든 Data Project에는 Netflix 애플리케이션 신원이 provision된다. - 필요하면 AWS IAM 역할도 함께 제공된다. - Netflix 신원은 Maestro 같은 비동기 워크로드의 실행 주체가 된다. - AWS IAM 역할은 Amazon EMR의 Spark 작업 등 AWS 특화 작업에 사용된다. - IAM 역할은 암호학적으로 안전한 방식으로 프로젝트의 Netflix 신원으로 교환될 수 있다. - 권한이 충분한 프로젝트 구성원은 로컬 노트북이나 노트북 환경에서 프로젝트 신원을 가정해 실제 예약 작업과 동일한 권한으로 테스트·디버깅할 수 있다. ## ‘Gravity’를 통한 자산 자동 귀속 - 프로젝트 신원으로 실행된 워크로드가 새 자산을 만들면 해당 자산이 자동으로 프로젝트에 포함된다. - 예를 들어 Maestro 워크플로가 테이블 세 개를 생성하면 이 테이블들이 자동으로 프로젝트의 자산이 된다. - 생성 자산을 나중에 찾아 프로젝트에 수동 등록할 필요가 없다. - 프로젝트가 해당 워크로드가 만든 자산의 중심이 되어 관리 범위와 권한 적용이 자연스럽게 확장된다. ## Maestro와 신뢰된 워크로드 실행 - Maestro는 ETL, 데이터 이동, 머신러닝 학습 등 배치 분석 작업을 담당하는 Netflix의 핵심 오케스트레이터다. - 예약 작업은 원래 사용자가 실행 시점에 উপস্থিত하지 않아도 되므로, Maestro는 Trusted Workload Manager(TWM)로 지정됐다. - TWM은 관리하는 워크로드를 대신해 새로운 신원 토큰을 발급할 권한을 가진다. - 하나의 워크플로 실행은 데이터 웨어하우스 테이블 ACL, Netflix 리소스 정책, AWS IAM 정책을 모두 통과해야 할 수 있다. - 따라서 실행 신원이 불안정하면 전체 데이터 파이프라인이 실패한다. ## 프로젝트 기반 지속 가능한 신원 - 기존의 `maestro OBO alice@netflix.com` 방식은 Maestro와 개인 사용자의 권한을 결합했지만, 사용자 생명주기에 종속됐다. - Data Projects는 이를 팀이 소유하는 Netflix 애플리케이션 신원으로 대체한다. - 프로젝트 신원은 담당자의 휴가, 부서 이동, 퇴사와 무관하게 유지된다. - Maestro는 워크플로 실행 전 호출자가 해당 프로젝트를 사용할 권한이 있는지 검증한다. - 실행 중 생성된 테이블은 gravity를 통해 프로젝트에 자동 귀속되고 프로젝트 권한을 물려받는다. - 시크릿도 프로젝트 정책 범위에서 관리되므로 담당자 변경으로 자격 증명이 고립되지 않는다. - 결과적으로 권한 관리가 중앙화되고, 워크플로 실행이 안정적이며, 감사 가능성도 높아진다. 대규모 데이터 플랫폼에서는 개별 테이블과 사용자에 권한을 계속 부여하기보다, 팀·서비스·워크로드를 대표하는 프로젝트 단위의 소유권과 지속 가능한 실행 신원을 도입하는 것이 효과적이다. 특히 예약 작업과 조직 변화가 많은 환경에서는 프로젝트 단위 권한, 자동 자산 귀속, 사람과 분리된 서비스 신원을 함께 설계하는 것이 권장된다.

access-controlapache-sparkidentity-managementaws-iam+4

gitlab2026년 6월 11일

GitLab 패치 릴리스: 19.0.2, 18.11.5, 18.10.8 | GitLab 문서 (새 탭에서 열림)

2026년 6월 10일 GitLab은 CE/EE용 패치 버전 19.0.2, 18.11.5, 18.10.8을 출시했다. 이번 릴리스에는 계정 탈취, XSS, 서비스 거부, SSRF, 권한 우회 등 다수의 보안 취약점이 포함되어 있어 모든 자체 관리형 설치 환경에 즉시 업그레이드가 권고된다. GitLab.com은 이미 패치가 적용됐으며, GitLab Dedicated 고객은 별도 조치가 필요 없다. ## 패치 릴리스와 업그레이드 권고 - 패치 릴리스는 보안 및 주요 버그를 수정하기 위한 버전이다. - 정기 패치는 매월 둘째·넷째 수요일에 배포되며, 심각도가 높은 취약점에는 비정기 긴급 패치가 제공될 수 있다. - 영향을 받는 버전을 사용하는 모든 설치 유형(Omnibus, 소스 코드, Helm Chart 등)은 가능한 한 빨리 최신 패치 버전으로 업그레이드해야 한다. - 보안 취약점의 상세 이슈는 수정 릴리스 후 30일이 지나면 공개된다. ## 계정 탈취와 권한 검증 문제 - **CVE-2026-6552 — Group SAML Identity API** - GitLab EE 대상 취약점이다. - 그룹 Owner 권한의 인증 사용자가 잘못된 권한 검증을 악용해 다른 그룹 구성원의 GitLab 계정을 탈취할 수 있었다. - CVSS **8.7**로 이번 릴리스에서 가장 심각한 취약점 중 하나다. - **CVE-2026-6269 — Merge Requests API** - CE/EE 모두 영향을 받는다. - Developer 권한 사용자가 숨겨진 머지 리퀘스트를 수정할 수 있었다. - CVSS **5.4**다. - **CVE-2026-6277 — Security Inventory** - GitLab EE 대상이다. - Security Manager가 관련 기능이 비활성화된 상태에서도 프로젝트 보안 설정을 변경할 수 있었다. - CVSS **4.3**이다. - **CVE-2026-6976 — Merge Request diff** - 파일명 처리와 권한 검증 문제로 Developer가 머지 리퀘스트 diff에서 변경 사항을 숨길 수 있었다. - CVSS는 **3.7**로 평가됐다. ## XSS 및 HTML 입력값 검증 문제 - **CVE-2026-10087 — Analytics Dashboard** - GitLab EE 대상이다. - Developer 권한 사용자가 입력값 검증 미흡을 이용해 대상 사용자의 권한으로 임의의 클라이언트 측 코드를 실행할 수 있었다. - CVSS **8.7**이며, 사용자의 상호작용이 필요하다. - **CVE-2026-8589 — 그룹 설정 필드** - GitLab EE 대상이다. - 악의적인 입력을 통해 대상 사용자 계정에 승인되지 않은 이메일 주소를 추가할 수 있었다. - CVSS **7.3**이다. - **CVE-2026-10733 — CI/CD Catalog** - CE/EE 모두 영향을 받는다. - 부적절한 입력값 정제로 인해 인증 사용자가 CI/CD Catalog 페이지에서 서비스 거부를 유발할 수 있었다. - CVSS **4.3**이다. ## 서비스 거부 및 리소스 고갈 - **CVE-2026-7250 — Grape API JSON 파싱 미들웨어** - CE/EE의 API 요청 파싱 과정에서 입력값 검증이 부족했다. - 인증하지 않은 공격자가 조작된 요청을 보내 서비스 거부를 일으킬 수 있었다. - CVSS **7.5**로, 외부에 노출된 API 서버에 특히 중요하다. - **CVE-2026-1500 — Group Placeholder Reassignments API** - 특수하게 제작된 파일 업로드를 처리하는 과정에서 리소스가 과도하게 소비될 수 있었다. - 인증된 사용자가 서비스 거부를 유발할 수 있으며, CVSS는 **6.5**다. ## SSRF와 내부 데이터 접근 - **CVE-2026-9204 — Gitaly 저장소 가져오기** - 저장소 가져오기 과정에서 보조 URL 검증이 충분하지 않았다. - 인증된 사용자가 Gitaly 서버의 임의 파일을 읽거나 내부 네트워크 리소스에 접근할 가능성이 있었다. - CVSS **5.3**이며, 서버 측 요청 위조(SSRF) 유형의 취약점이다. ## 적용 대상 버전 - **19.0.2**: GitLab 19.0 계열의 이전 버전 - **18.11.5**: GitLab 18.11 계열의 이전 버전 - **18.10.8**: GitLab 18.10 계열의 이전 버전 - 취약점별로 GitLab 12.10, 13.1.4, 15.x, 17.x 등 다양한 이전 버전이 영향을 받는다. - 취약점에 따라 GitLab EE만 영향을 받거나 CE/EE 모두 영향을 받는다. 자체 관리형 GitLab 운영자는 현재 버전의 지원 브랜치에 맞춰 19.0.2, 18.11.5, 18.10.8 중 해당되는 버전으로 즉시 업그레이드하고, 외부 공개 API와 Gitaly 접근 로그도 함께 점검하는 것이 좋다.

access-controlgitlabci-cdapi-security+3

gitlab2026년 5월 21일

GitLab Secrets Manager로 CI/CD 자격 증명 관리 (새 탭에서 열림)

GitLab Secrets Manager는 CI/CD 자격 증명을 GitLab 내부에서 안전하게 관리하도록 지원하는 기능으로, GitLab 19.0에서 공개 베타로 제공됩니다. 비밀 값을 프로젝트·그룹 구조와 파이프라인의 브랜치·환경 조건에 따라 최소 범위로 제공해 유출 시 피해를 줄이고, 생성·변경·사용 이력을 감사 로그로 추적할 수 있다는 것이 핵심입니다. 기존 외부 보안 저장소와 달리 별도의 권한 체계와 운영 시스템을 추가로 관리하지 않아도 됩니다. ## CI/CD 변수와 외부 보안 저장소의 한계 - 개발자는 자격 증명을 `.env`, 설정 파일 또는 CI/CD 변수에 임시로 저장하기 쉽습니다. - 프로젝트나 그룹 수준의 CI/CD 변수는 값을 마스킹할 수 있지만, 기본적으로 여러 작업에 주입되어 최소 권한 원칙을 위반할 수 있습니다. - 파이프라인 접근 권한이 있는 사용자가 변수 값을 읽을 가능성도 있습니다. - 별도 Vault를 사용하면 비밀을 CI/CD 설정에서 분리할 수 있지만 다음과 같은 운영 부담이 생깁니다. - 별도 인증 방식 관리 - GitLab과 다른 권한 모델 유지 - 여러 시스템의 감사 로그 상관관계 분석 - 조직·역할 변경 시 권한 동기화 ## GitLab Secrets Manager의 사용 방식 - Secrets Manager는 OpenBao를 기반으로 GitLab에 통합된 네이티브 기능입니다. - `.gitlab-ci.yml`의 `secrets:` 키워드로 작업에 필요한 비밀을 선언합니다. ```yaml deploy: secrets: DATABASE_PASSWORD: gitlab_secrets_manager: name: db-password script: - deploy --password $DATABASE_PASSWORD ``` - 기본적으로 비밀 값은 임시 파일에 기록되고, 해당 파일 경로가 작업 범위의 환경 변수로 전달됩니다. - 값 자체보다 파일 경로를 전달하면 하위 프로세스, 크래시 덤프, 텔레메트리 등에 비밀이 노출될 가능성을 줄일 수 있습니다. ## 기존 GitLab 권한 모델 활용 - 그룹과 프로젝트 구조가 비밀의 격리 경계로 사용됩니다. - 사용자·그룹·역할별로 읽기, 생성, 수정, 삭제 권한을 설정할 수 있습니다. - 그룹 수준에서 만든 비밀은 하위 프로젝트들이 상속받아 공통 자격 증명을 한 번만 정의할 수 있습니다. - 사용자가 프로젝트에서 제거되면 해당 프로젝트의 비밀 접근 권한도 즉시 사라집니다. - 별도 보안 시스템에서 GitLab의 조직 구조와 권한을 다시 구성하고 동기화할 필요가 없습니다. ## 브랜치와 환경별 최소 권한 범위 - 각 비밀은 해당 비밀이 필요한 작업에만 제공됩니다. - 접근 여부는 다음 작업 속성으로 결정됩니다. - 대상 환경 - 실행 브랜치 - 브랜치 보호 여부 - 환경과 브랜치에는 와일드카드를 사용할 수 있습니다. 예를 들어 `production/*`과 같은 규칙을 지정할 수 있습니다. - 보호된 브랜치에서 `production/*` 환경으로 실행되는 작업에만 비밀을 제공하도록 조건을 조합할 수 있습니다. - 작업 실행 시 백엔드가 작업의 신원, 브랜치, 환경을 검증한 뒤 비밀을 반환합니다. - 작업 종료 후 비밀은 러너에 남지 않으며, 로그에서는 값이 마스킹됩니다. - 자격 증명이 유출되어도 접근 가능한 시스템 범위가 좁아져 회전, 조사, 복구에 필요한 작업이 줄어듭니다. ## 파이프라인과 연결된 감사 추적 - 프로젝트·그룹 비밀의 생성, 수정, 삭제 이벤트가 GitLab의 기존 감사 로그에 기록됩니다. - CI/CD 파이프라인에서 비밀을 읽은 이벤트에는 원본 파이프라인 ID와 작업 ID가 포함됩니다. - 따라서 별도 CI 시스템, 보안 저장소, ID 제공자의 로그를 수동으로 조합하지 않고도 비밀 사용 경로를 추적할 수 있습니다. - 감사 로깅은 현재 self-managed 배포에서 제공되며, GitLab.com 지원은 공개 베타 기간 중 추가될 예정입니다. ## 공개 베타와 기존 도구와의 연계 - GitLab.com 및 self-managed 환경의 Premium·Ultimate 사용자가 공개 베타에 참여할 수 있습니다. - GitLab Dedicated 지원은 추후 제공될 예정입니다. - 베타 기간에는 무료이며, 정식 출시 후에는 GitLab Credits를 통해 유료 제공됩니다. - HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager 통합도 계속 사용할 수 있어 기존 시스템에서 단계적으로 전환할 수 있습니다. 실무적으로는 광범위한 CI/CD 변수를 먼저 점검하고, 배포 환경·브랜치별로 필요한 비밀을 Secrets Manager로 이전하는 것이 좋습니다. 특히 운영 자격 증명은 보호된 브랜치와 특정 `production/*` 환경에만 연결해 유출 시 피해 범위를 제한하는 방식을 권장합니다.

access-controlci-cdsecrets-managementaudit-logging+3

figma2025년 10월 22일

대규모 가시성: Figma가 (새 탭에서 열림)

피그마(Figma)는 서비스 규모가 확장됨에 따라 복잡해진 권한 관리 로직을 효율적으로 처리하기 위해 자체적인 권한 정의 언어(DSL)인 'Permit'을 구축했습니다. 기존의 파편화된 명령형 코드 방식에서 벗어나 선언적인 DSL을 도입함으로써 권한 정책의 일관성을 확보하고 보안 취약점 발생 가능성을 획기적으로 낮췄습니다. 이를 통해 복잡한 사용자-리소스 간의 관계를 명확하게 모델링하고 성능 저하 없이 대규모 시스템에 적용할 수 있는 권한 검증 인프라를 완성했습니다. ### 기존 시스템의 한계와 권한 관리의 복잡성 * 권한 체크 로직이 Go 애플리케이션 코드 곳곳에 흩어져 있어, 특정 리소스에 대한 접근 규칙을 한눈에 파악하거나 일관되게 수정하기 매우 어려웠습니다. * 팀, 프로젝트, 파일로 이어지는 계층 구조뿐만 아니라 엔터프라이즈 설정, 공유 링크 등 수많은 변수가 결합되면서 권한 로직 수정 시 예기치 않은 부작용(side effects)이 발생할 위험이 컸습니다. * 성능 최적화를 위해 데이터베이스 쿼리에 권한 로직을 직접 포함시켜야 하는 경우가 많았는데, 이는 비즈니스 로직과 권한 정책이 뒤섞여 코드 유지보수성을 떨어뜨리는 결과로 이어졌습니다. ### 관계 기반 접근 제어(ReBAC)와 Permit DSL 설계 * 구글의 Zanzibar 시스템에서 영감을 얻어, 객체 간의 관계를 중심으로 권한을 정의하는 ReBAC(Relationship-Based Access Control) 모델을 피그마의 환경에 맞게 커스텀화했습니다. * Permit DSL은 'Actor(사용자)', 'Resource(파일, 팀 등)', 'Action(편집, 보기 등)' 간의 관계를 선언적인 문법으로 정의합니다. * 예를 들어 "사용자가 파일이 속한 프로젝트의 편집자라면 해당 파일에 대한 편집 권한을 가진다"와 같은 전이적인(transitive) 관계를 직관적인 문법으로 표현할 수 있게 되었습니다. ### 컴파일러 및 성능 최적화 기술 * DSL로 작성된 정책을 런타임에 해석하는 대신, 효율적인 Go 코드로 변환하는 자체 컴파일러를 개발하여 실행 성능을 극대화하고 런타임 오버헤드를 최소화했습니다. * 컴파일 단계에서 정적 분석을 수행하여 순환 참조나 정의되지 않은 권한 사용 등 논리적 오류를 사전에 차단합니다. * 특히 '부분 평가(Partial Evaluation)' 기법을 도입하여, 권한 로직을 SQL 쿼리의 WHERE 절로 변환함으로써 수백만 개의 리소스 중 사용자가 접근 가능한 항목만 효율적으로 필터링할 수 있도록 구현했습니다. ### 안전한 전환을 위한 검증 및 배포 프로세스 * DSL 내부에 유닛 테스트를 직접 작성할 수 있는 기능을 포함시켜, 정책 변경이 기존의 기대 결과와 일치하는지 배포 전 즉시 검증할 수 있는 환경을 마련했습니다. * '섀도 모드(Shadow mode)'를 활용하여 실제 트래픽에서 기존의 레거시 권한 로직 결과와 새로운 Permit 시스템의 결과를 실시간으로 비교하며 데이터 정합성을 확인했습니다. * 성능 모니터링을 통해 권한 확인 작업이 전체 API 응답 시간에 미치는 영향을 정밀하게 추적하며 안정성을 확보했습니다. 권한 관리는 단순한 기능을 넘어 대규모 SaaS의 보안과 확장성을 결정짓는 핵심 인프라입니다. 피그마의 사례처럼 권한 로직을 비즈니스 코드에서 분리하여 '정책(Policy)'으로서 중앙 집중화하고 코드화하는 전략은, 제품의 복잡도가 높아질수록 개발 생산성과 시스템 안정성을 동시에 잡을 수 있는 가장 강력한 방법 중 하나입니다.

access-controlauthorizationinfrastructuredsl+2

discord2025년 4월 16일

게임 개발자 플레이북 제 (새 탭에서 열림)

Discord는 게임 개발 초기부터 소규모 플레이테스트 커뮤니티를 운영하면 플레이어의 피드백과 지지를 효과적으로 확보할 수 있다고 설명한다. 핵심은 서버를 테스트와 피드백이라는 목적에 맞게 단순하게 구성하고, 정보 전달·토론·운영진 관리·음성 테스트 공간을 명확히 분리하는 것이다. 초기에는 최소한의 구조로 시작하되 커뮤니티 규모와 게임의 복잡성에 따라 기능을 점진적으로 확장하는 것이 권장된다. ## 초기 플레이테스트 커뮤니티의 목적 - 게임 개발 초기에 소수의 플레이어를 커뮤니티에 모으면 핵심 지지자, 홍보자, 내부 테스터로 발전할 수 있다. - Discord는 소규모 친구 간 대화를 위해 만들어진 플랫폼이므로 개발자와 플레이어 간 지속적인 관계 형성에 적합하다. - 서버에서는 다음 활동을 수행할 수 있다. - 플레이테스트 일정 조율 - 음성·영상·화면 공유를 통한 테스트 관찰 - 버그와 사용성에 대한 피드백 수집 - 게임 업데이트와 개발 방향에 대한 대화 - 커뮤니티는 개발 후반보다 가능한 한 이른 시점에 시작하는 편이 좋다. ## 플레이테스트 서버의 기본 구조 - 서버의 최우선 목표는 “플레이어가 쉽게 게임을 테스트하고 피드백을 남기도록 하는 것”이다. - 부가적인 목표가 있더라도 서버의 범위와 채널 수는 가능한 한 집중적으로 유지해야 한다. - 기본 카테고리는 다음과 같이 나누는 것이 좋다. - 읽기 전용 정보 채널 - 플레이어와 운영진이 함께 대화하는 토론 채널 - 운영진 전용 커뮤니케이션 - 음성 채팅, 영상 통화, 화면 공유용 개별 채널 - 규칙, 공지, 업데이트처럼 중요한 정보가 먼저 보이고 그 아래에서 관련 토론이 이어지도록 카테고리와 채널 순서를 일관되게 구성한다. - 게임에 직업·키트·영웅이 많다면 각각을 위한 포럼 채널을 만들 수 있다. - 던전, 레이드, 제작처럼 복잡한 시스템이 많다면 기능별로 채널을 분리하는 방식도 유용하다. ## 역할과 권한 관리 - 기본 역할은 스튜디오 운영진 역할과 플레이테스터 역할 두 가지로 단순하게 시작한다. - `@admin`: 스튜디오 이름으로 변경하고 모든 채널에 접근 - `@playtest`: 관리자 전용 카테고리를 제외한 테스트 관련 채널에 접근 - 역할이 없는 `@everyone`에게 모든 권한을 제거하면 초대받지 않은 사용자는 서버에 들어와도 콘텐츠를 볼 수 없다. - 권한이 없는 사용자는 역할을 부여받기 전까지 사실상 빈 서버만 보게 된다. - Discord의 **View Server As** 기능을 사용해 각 역할이 실제로 어떤 채널과 기능을 볼 수 있는지 점검하는 것이 좋다. - 운영진은 모든 활동을 확인할 수 있어야 하지만, 테스터에게 관리자용 내부 논의가 노출되지 않도록 카테고리 단위로 권한을 분리해야 한다. ## Community 기능 활용 서버가 커지면 Discord의 Community 기능을 활성화해 관리와 분석 기능을 추가할 수 있다. - **Announcement Channels** - 서버 공지를 다른 서버가 팔로우할 수 있다. - 모든 메시지가 아니라 선택한 공지만 외부에 게시할 수 있다. - **Server Insights** - 서버 회원이 500명에 도달하면 참여도와 유지율에 대한 분석 정보를 확인할 수 있다. - **Community Onboarding** - 신규 회원이 직접 역할을 선택하도록 할 수 있다. - 서버 규칙에 동의한 사용자만 참여하도록 설정할 수 있다. - 모든 기능을 처음부터 활성화할 필요는 없으며, 커뮤니티 성장 단계에 맞춰 필요한 기능만 도입하면 된다. ## 읽기 전용 채널과 정보 전달 - 각 채널은 하나의 명확한 기능을 가져야 한다. - 채널 이름만 보아도 어떤 정보가 있는지 알 수 있도록 구체적으로 지정해야 한다. - 읽기 전용 채널은 일반 역할에 `Send Message` 권한을 주지 않는 방식으로 구현한다. - 이모지와 Markdown을 일관되게 사용하면 중요한 정보와 사용자가 취해야 할 행동을 빠르게 파악할 수 있다. - 예시 채널은 다음과 같이 구성된다. - `#rules-and-info`: 서버 규칙과 이용 지침 - `#announcements`: 게임 및 플레이테스트 관련 주요 공지 - `#patch-notes`: 버전 업데이트와 변경 사항 - `#game-discussion`: 게임에 대한 양방향 토론 공간 ## 실용적인 운영 추천 처음에는 Discord 템플릿을 기반으로 규칙·공지·패치 노트·게임 토론·관리자 전용 공간만 구성하고, 역할별 권한을 먼저 검증하는 것이 좋다. 이후 테스트 참여자가 늘거나 게임 시스템이 복잡해질 때 포럼 채널, Community Onboarding, Server Insights 등을 단계적으로 추가하면 서버가 불필요하게 복잡해지는 것을 막을 수 있다.

access-controldiscordmarkdowngame-development+2

figma2024년 6월 2일

초안 작동 방식 업데이트 | Figma (새 탭에서 열림)

Figma는 Starter·Professional 플랜의 Drafts를 팀과 분리된 개인 공간에서 팀 내부의 전용 Drafts 공간으로 이전한다. 이를 통해 파일 소유권과 권한을 명확히 하고, 팀 플랜 기능과 향후 결제·라이선스 관리 개선의 기반을 마련하려는 것이다. Drafts는 계속 비공개로 유지되며 무료로 생성·편집할 수 있지만, 팀으로 이동할 때 일부 협업자의 편집 권한이 변경될 수 있다. ## Drafts 이전의 배경 - 기존 Drafts는 팀에 속하지 않아 파일 소유권과 팀 연계가 불명확했다. - Starter·Professional과 Organization·Enterprise의 Drafts 구조가 달라 제품 개선이 복잡했다. - 팀과 연결되지 않은 Drafts에서는 고급 프로토타이핑, 비밀번호 보호, Dev Mode 같은 유료 기능을 사용할 수 없었다. - 개인 작업과 업무용 작업이 분리되지 않아 파일 권한, 보안, 지식재산권 관리에 문제가 생길 가능성이 있었다. ## Drafts의 새로운 구조 - 모든 Drafts는 이제 하나의 팀에 연결되어야 한다. - 사용자는 자신이 속한 각 팀 안에 개인 전용 Drafts 공간을 갖는다. - Professional 팀의 Drafts에서는 편집자에게 Professional 기능이 제공된다. - Starter 팀이 하나뿐인 사용자는 Drafts가 해당 팀의 새 Drafts 공간으로 자동 이전될 수 있다. - 팀 목록은 새 드롭다운 메뉴를 통해 확인하고 선택할 수 있다. ## 협업 권한과 요금 변화 - 팀으로 Draft를 옮겨도 파일은 기본적으로 계속 비공개다. - Draft의 기존 편집자가 해당 팀의 정식 멤버가 아니면, 예상치 못한 유료 좌석 발생을 막기 위해 자동으로 뷰어로 변경된다. - 필요한 경우 사용자 또는 관리자가 다시 편집 권한을 부여해야 한다. - Starter 팀에서는 무제한 뷰어를 초대할 수 있고, 최대 3개의 협업 파일에는 무제한 편집자를 둘 수 있다. - 개인 Drafts를 팀에 소속시키더라도 자신의 Draft를 계속 무료로 생성·편집할 수 있다. ## Drafts를 팀으로 이동하는 방법 - “Drafts to move” 공간으로 이동하면 원하는 팀의 Drafts 공간을 선택해 파일을 옮길 수 있다. - 특정 팀과 관련 없는 개인 작업은 무료 Starter 팀을 만든 뒤 그 팀으로 이동할 수 있다. - 이전 작업이 진행 중인 동안에도 기존 협업자와 Draft를 계속 편집할 수 있다. - 다만 새로운 협업자를 초대하려면 먼저 파일을 팀으로 이동해야 한다. - 현재 고정된 마감일은 없으며, 향후 이동하지 않은 Drafts는 무료 Starter 플랜으로 이전될 예정이다. 이전 전에는 별도 안내가 제공된다. ## 앞으로의 개선 방향 - 사용자가 유료 편집자 좌석으로 전환되는 시점을 더 명확히 안내할 예정이다. - 프리랜서의 프로젝트 인계와 여러 팀에 속한 사용자의 업무를 지원할 계획이다. - 관리자 대시보드와 게스트 관리 등 라이선스 관리 기능을 개선할 예정이다. - Figma의 결제 관련 사용자 경험도 전반적으로 재설계하고 있다. ## 실용적인 대응 현재 Drafts를 검토해 업무용·개인용 파일을 적절한 팀으로 분류하고, 이동 후 편집 권한이 필요한 협업자가 해당 팀의 정식 멤버인지 확인하는 것이 좋다. 어느 팀에도 속하지 않는 개인 작업은 별도의 무료 Starter 팀으로 분리하면 관리와 권한 설정이 수월하다.

access-controlfigmaprototypingdev-mode+2

figma2024년 3월 12일

Figma에서 커스텀 권한 (새 탭에서 열림)

Figma는 기존 Ruby 모놀리스의 `has_access?` 메서드에 모든 권한 로직을 집중시킨 결과, 복잡성·디버깅 난이도·계층형 권한의 한계·데이터베이스 부하 문제에 직면했다. 이를 해결하기 위해 자체 권한 도메인 특화 언어(DSL), 크로스플랫폼 권한 로직 엔진을 구축하고 핵심 권한 규칙을 새 시스템으로 이전했다. 목표는 권한 정확성과 성능을 높이는 동시에 개발자가 안전하게 권한 규칙을 변경할 수 있도록 만드는 것이었다. ## Figma의 권한 모델 - Figma의 협업 기능은 파일과 폴더, 팀, 조직 단위의 복잡한 권한 구조를 필요로 한다. - 파일 접근 방식은 크게 두 가지다. - **역할 기반 접근**: 상위 폴더·팀·조직에서 상속된 역할에 따라 접근한다. - **링크 기반 접근**: 링크를 가진 사용자의 접근 수준, 만료 기간, 비밀번호, 조직 정책 등을 조합해 결정한다. - 파일 삭제 여부, 계층 구조, 조직 제한, 결제 상태 등도 접근 가능 여부에 영향을 준다. - 기존에는 각 ActiveRecord 모델의 `has_access?` 메서드가 사용자와 리소스를 받아 접근 가능 여부를 boolean으로 반환했다. ## 기존 `has_access?` 방식의 한계 - 권한 판단에 필요한 모든 비즈니스 로직이 하나의 긴 메서드에 들어갔다. - 제품 엔지니어가 컨트롤러에서 이 메서드를 적절한 시점에 직접 호출해야 했다. - 작은 변경도 전체 권한 체계에 영향을 줄 수 있어 개발자들이 메서드 수정 자체를 꺼리게 됐다. - 권한 버그는 Figma의 모든 파일에 대한 접근 허용으로 이어질 수 있어 위험성이 컸다. - 디버깅 시 특정 규칙만 분리해 확인하기 어려웠고, 수십 개의 로그를 코드 곳곳에 추가해야 했다. ## 계층형 권한과 boolean 플래그의 문제 - 권한 수준을 정수로 표현했지만, 실제 동작은 여러 boolean 플래그에 의해 달라졌다. - 예시 메서드는 다음과 같은 선택적 인자를 포함했다. - `ignore_link_access` - `org_candidate` - `ignore_archived_branch` - 같은 권한 수준이라도 플래그 조합에 따라 결과가 달라져 개발자가 이해해야 할 경우의 수가 많았다. - 리소스마다 플래그의 의미와 동작이 달라 일관된 권한 모델을 만들기 어려웠다. - 예를 들어 `300` 수준의 편집 권한은 있어도, 특정 조건을 무시한 `100` 수준의 보기 권한 검사는 통과하지 못할 수 있었다. - 따라서 기존 계층 구조만으로는 표현하기 어려운, 서로 독립적인 세밀한 권한이 필요했다. - 새로운 시스템은 기존 계층형 권한을 지원하면서도 비계층적이고 독립적인 권한 체계를 추가할 수 있어야 했다. ## 권한 검사로 인한 데이터베이스 부하 - Figma의 사용자와 리소스 규모가 빠르게 증가하면서 권한 검사가 데이터베이스에 큰 부담을 줬다. - 전체 데이터베이스 부하 중 약 **20%**가 권한 검사에서 발생했다. - 데이터베이스를 수직·수평 확장하는 것만으로는 물리적 한계가 있었기 때문에, 권한 로직 자체가 데이터 계층에 가하는 부하를 줄여야 했다. - 새로운 권한 시스템에는 권한 데이터를 어떻게 조회하고 처리할지에 대한 더 세밀한 제어가 필요했다. ## 자체 권한 DSL과 로직 엔진 - Figma는 외부 솔루션을 우선 검토하는 일반적인 방침과 달리, 권한 문제에는 자체 시스템을 선택했다. - 구축한 구성 요소는 다음과 같다. - 권한 규칙을 명확하게 표현하는 **도메인 특화 언어(DSL)** - 여러 환경에서 동작하는 **크로스플랫폼 권한 로직 엔진** - 기존의 핵심 권한 규칙을 새 시스템으로 이전하는 마이그레이션 체계 - 이를 통해 권한 규칙을 하나의 거대한 조건문으로 관리하지 않고, 독립적이고 조합 가능한 규칙으로 다룰 수 있게 하는 것이 목표였다. - 결과적으로 권한 로직을 제품 기능과 분리하고, 규칙 추가·수정·삭제 시 기존 권한 체계를 모두 다시 이해해야 하는 부담을 줄이려 했다. ## 실용적인 결론 복잡한 권한 시스템에서는 단순한 `if/else` 함수와 호출 규약만으로 규모 확장을 감당하기 어렵다. 권한을 독립적인 규칙으로 모델링하고, 선언적인 DSL과 공통 실행 엔진을 사용하면 정확성·성능·개발자 경험을 함께 개선할 수 있다.

access-controlrubydatabase-shardingauthorization+3

figma2017년 11월 28일

디자인 시스템을 위한 고급 (새 탭에서 열림)

디자인 시스템을 운영하려면 구성 요소를 쉽게 공유하는 것뿐 아니라, 누가 프로젝트를 보고 수정할 수 있는지도 세밀하게 관리해야 한다. Figma는 이를 위해 유료 팀에 **보기 전용(View-only)**과 **초대 전용(Invite-only)** 프로젝트 권한을 도입했다. 이 기능은 유지 관리자가 디자인 시스템을 보호하면서도 팀 전체의 활용을 지원하도록 해, 실수로 인한 변경을 줄이는 것이 핵심 목적이다. ## 디자인 시스템 운영에서 권한 관리가 필요한 이유 - 디자인 시스템 제작자는 새 구성 요소를 팀 전체에 공개하기 전에 비공개로 테스트할 필요가 있다. - 시스템이 배포된 뒤에는 많은 디자이너가 실수로 핵심 구성 요소를 수정하지 않도록 보호해야 한다. - 기존에는 Figma 팀의 편집자가 모든 프로젝트를 보고 수정할 수 있어, 유지 관리자와 사용자를 구분하기 어려웠다. - Team Library가 파일과 팀 간 구성 요소 공유를 해결했다면, Advanced Project Permissions는 프로젝트의 접근 범위와 수정 권한을 해결한다. ## 새로 추가된 프로젝트 권한 유료 Professional Team의 편집자는 프로젝트 생성 시 다음 세 가지 접근 수준을 선택할 수 있다. - **팀 전체 편집 가능** - 팀의 모든 구성원이 프로젝트를 보고 수정할 수 있다. - **팀 전체 보기 가능** - 팀 구성원은 프로젝트를 열람할 수 있지만 내용을 수정할 수 없다. - 배포된 디자인 시스템을 보호하는 데 적합하다. - **초대 전용** - 지정된 사용자만 프로젝트에 접근할 수 있다. - 개발 중인 디자인 시스템이나 제한된 협업에 활용할 수 있다. 기존 프로젝트도 Share 버튼을 통해 기본 접근 권한을 변경할 수 있다. ## 유지 관리자와 사용자를 분리하는 보호 장치 - 디자인 시스템 유지 관리자는 컴포넌트와 스타일을 만들고 안정성을 관리한다. - 일반 사용자는 시스템의 구성 요소를 참고하거나 활용하되, 원본을 직접 변경하지 않는 것이 바람직하다. - 보기 전용 권한은 사용자의 접근성을 유지하면서도 우발적인 편집을 방지하는 완충 역할을 한다. - 특히 규모가 큰 팀에서 의도하지 않은 수정으로 디자인 시스템이 훼손되는 문제를 줄일 수 있다. ## 권한 강화의 한계와 향후 방향 - 유지 관리자와 사용자의 비율에 따라 일부 구성원은 시스템을 직접 개선할 기회가 줄어들 수 있다. - 보기 전용 권한은 안정성을 높이지만, 개선 제안과 실제 반영 사이에 별도의 의사소통 과정이 필요하다. - Figma는 코드 저장소의 풀 리퀘스트와 유사하게, 디자이너가 변경을 제안하고 유지 관리자가 검토하는 방식을 검토하고 있었다. - 이를 통해 권한 보호와 개방적인 개선 문화를 함께 구현하려는 방향을 제시했다. 디자인 시스템을 운영할 때는 개발 중인 프로젝트에는 **초대 전용**, 공식 배포본에는 **보기 전용**, 공동 편집이 필요한 작업에는 **팀 전체 편집 가능** 권한을 적용하는 방식이 실용적이다. 다만 변경 제안 절차와 검토 책임자까지 함께 정해 두어야 권한 제한이 협업 저하로 이어지지 않는다.

access-controlfigmadesign-systemscollaboration+2