audit-logging

3 개의 포스트

cloudflare

에이전트 액세스 모델 (새 탭에서 열림)

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

cloudflare

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 서버에 쓰기 권한을 추가할 때는 단순한 사용자 인증만으로는 부족하다. 도구별 위험도 정책, 에이전트 세션 식별, 민감정보 제거 감사 로그, 사전 차단 기능을 중앙 계층에서 제공해야 하며, 특히 대량 변경이 가능한 작업은 높은 위험도로 분류해 별도 통제하는 것이 안전하다.

gitlab

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/*` 환경에만 연결해 유출 시 피해 범위를 제한하는 방식을 권장합니다.