Google Workspace Policy API가 DLP(data loss prevention) 규칙과 탐지기를 읽는 수준을 넘어 생성·수정·삭제까지 다루기 시작했다. 이제 보안팀은 콘솔 수작업만으로 정책을 맞추는 대신 코드와 승인 절차로 DLP 정책 수명주기를 관리할 수 있지만, 그만큼 권한·롤백·감사 기준을 먼저 정해야 한다.

핵심 요약

  • Google은 Workspace Policy API에 DLP 규칙·탐지기용 mutate 엔드포인트를 추가했다. 기존 Get/List 중심의 읽기 기능에 Create, Update, Delete가 더해진 변화다.
  • 이번 출시는 API-only다. Google이 밝힌 범위는 현재 Admin console에서 지원되는 DLP 관련 기능이며, 사용 주체는 super admin이다.
  • DLP는 Drive, Gmail, Chat, Chrome 같은 Workspace 영역에서 민감정보 유출을 줄이기 위한 규칙을 정의하고, 위반 시 알림·차단 같은 조치를 실행하는 기능이다.
  • Rapid Release와 Scheduled Release 도메인 모두에서 “Available now”로 안내됐고, 모든 Google Workspace 고객과 Workspace Individual 구독자에게 제공된다고 공지됐다.

무엇이 바뀌었나

이전의 Policy API 활용은 여러 보안 설정을 중앙에서 조회하고 감사하는 용도에 가까웠다. 이번 업데이트는 DLP 규칙과 detector에 대해 생성(Create), 수정(Update/Patch), 삭제(Delete) 흐름을 API로 열었다는 점이 핵심이다. Google의 별도 문서도 “create, patch, delete endpoints are only supported for rules and detectors settings for now”라고 범위를 제한해 설명한다.

즉 모든 Workspace 보안 설정을 마음대로 쓰기 가능한 API로 바꾼 것은 아니다. 그러나 DLP처럼 조직의 파일 공유, 메일, 채팅, 브라우저 사용 정책과 맞물리는 기능에 쓰기 API가 생기면 영향은 작지 않다. 보안팀은 새 규칙 배포, 지역·부서별 예외 반영, 일시적 비활성화, 사고 대응 후 재활성화를 콘솔 클릭 대신 코드화할 수 있다.

왜 보안팀과 개발팀이 같이 봐야 하나

DLP 정책은 단순한 관리 화면 설정이 아니라 실제 업무 흐름을 막거나 허용하는 제어 장치다. 잘 설계하면 외부 공유 문서나 민감한 식별정보 전송을 줄이는 데 도움이 되지만, 잘못 배포하면 정상적인 협업 파일 업로드나 메일 발송이 멈출 수 있다. 읽기 전용 API와 달리 mutate 엔드포인트는 실수의 폭발 반경이 넓다.

따라서 이 업데이트는 “관리자가 편해졌다”보다 “보안 정책을 코드로 다룰 수 있게 됐다”에 가깝다. Terraform 같은 선언형 도구가 바로 공식 지원된다는 뜻은 아니지만, 내부 Git 저장소·리뷰 절차·승인 기록과 결합해 DLP 정책 변경을 추적할 여지가 커진다. Google은 GAM이 Policy API를 지원한다고도 안내했다. 이미 GAM으로 Workspace 관리를 자동화하는 조직이라면 DLP 정책 변경까지 같은 작업 흐름에 묶을 수 있는지 확인할 만하다.

API 적용 전 확인할 조건

확인 항목 왜 중요한가 권장 확인 방식
권한 범위 공지 기준 사용자는 super admin이다. 쓰기 권한이 넓으면 오작동 시 전체 도메인에 영향을 줄 수 있다. API 호출 계정, OAuth 범위, 서비스 계정 위임 여부를 문서화하고 긴급 비활성화 담당자를 지정한다.
지원 범위 현재 mutate 지원은 DLP rules와 detectors로 제한된다. 기존 Admin console 설정 중 API로 바꿀 수 있는 항목과 아직 수작업으로 남는 항목을 분리한다.
변경 추적 DLP 정책 변경은 사고 조사와 감사에서 근거가 된다. 변경 전후 JSON, 리뷰 승인자, 배포 시각, 적용 대상 조직 단위를 남긴다.
롤백 잘못된 차단 규칙은 정상 업무를 멈출 수 있다. Delete보다 비활성화·되돌리기 절차를 먼저 설계하고, 직전 정책 스냅샷을 보관한다.

작은 범위에서 검증하는 절차

  1. 현재 정책을 먼저 읽어 저장한다. Get/List로 현행 DLP rules와 detectors를 export해 기준 파일을 만든다. 이 단계가 없으면 API 쓰기 테스트 뒤 무엇이 바뀌었는지 비교하기 어렵다.
  2. 테스트용 조직 단위나 제한된 사용자 집합을 정한다. 실제 전사 공유 정책에 바로 적용하지 말고 영향이 작은 범위에서 알림·차단 동작을 확인한다.
  3. 새 규칙은 “탐지 → 알림 → 차단” 순서로 강도를 높인다. Google의 DLP 설명처럼 위반은 incidents와 보호 조치를 유발할 수 있으므로 처음부터 강한 차단으로 시작하면 업무 중단 리스크가 커진다.
  4. API 호출 결과와 Admin console 표시가 일치하는지 본다. 이번 출시는 Admin console에서 지원되는 기능의 API-only launch로 안내됐기 때문에, 코드로 만든 정책이 운영자가 이해할 수 있는 형태로 보이는지도 중요하다.
  5. GAM 또는 내부 스크립트의 실패 처리를 검증한다. 중간 실패, 중복 실행, 일부 정책만 반영된 상태를 가정하고 재시도와 롤백 동작을 확인한다.

이 업데이트가 특히 유용한 경우

첫째, 여러 도메인·조직 단위에서 비슷한 DLP 정책을 반복 적용하는 조직이다. 콘솔에서 정책을 복사·수정하는 방식은 사람이 기억해야 할 항목이 많고, 예외가 늘어날수록 감사가 어려워진다. API 기반 변경은 템플릿과 리뷰 로그를 남길 수 있어 반복 작업을 줄인다.

둘째, 규제나 고객 계약 때문에 특정 데이터 유형의 외부 공유를 빠르게 막아야 하는 팀이다. 탐지기와 규칙을 코드로 준비해두면 사건 발생 시 동일한 패턴을 여러 범위에 빠르게 반영할 수 있다. 다만 빠른 배포보다 중요한 것은 되돌릴 수 있는 배포다. 삭제 API를 자동화에 넣기 전에는 비활성화, 이전 버전 복원, 승인 없는 실행 차단을 먼저 구현해야 한다.

셋째, 보안 정책을 개발 워크플로와 연결하려는 조직이다. Pull request 리뷰, 변경 티켓, 감사 로그, 배포 기록을 DLP 정책 변경과 연결하면 “누가 왜 어떤 규칙을 바꿨는가”를 나중에 설명하기 쉬워진다. 반대로 단발성 스크립트로만 운영하면 콘솔 수작업보다 더 위험할 수 있다.

주의할 한계

  • 공지와 문서 기준으로 쓰기 지원은 rules와 detectors에 먼저 열렸다. 모든 Policy API 리소스가 같은 수준으로 쓰기 가능하다고 해석하면 안 된다.
  • End users에게 새 기능이 생긴 것은 아니다. 이번 변화는 admin-only capability다.
  • Google 공지는 “API-only launch”라고 설명한다. UI에서 새 마법사가 생긴 것으로 기대하기보다, 기존 콘솔 기능을 자동화할 수 있는 API 범위가 늘었다고 보는 편이 정확하다.
  • DLP는 민감정보 보호 기능이지만, 정책 품질은 조직의 데이터 분류와 예외 관리에 달려 있다. API가 생겼다고 오탐·과차단 문제가 자동으로 해결되지는 않는다.

결론

Google Workspace의 이번 변화는 좁은 릴리즈 노트처럼 보이지만, 보안 자동화 관점에서는 의미가 있다. DLP 정책을 생성·수정·삭제할 수 있으면 관리자는 반복 설정을 줄이고, 개발팀은 정책 변경을 코드 리뷰와 배포 파이프라인에 넣을 수 있다. 대신 super admin 권한을 쓰는 API인 만큼 최소 권한, 변경 전 백업, 단계적 적용, 롤백 시나리오를 갖춘 뒤 적용해야 한다.

ActualStack 관점에서 이 업데이트의 가치는 “DLP를 더 쉽게 켠다”가 아니라 “민감정보 보호 정책을 검증 가능한 변경 관리 대상으로 옮길 수 있다”는 데 있다. Workspace를 쓰는 조직이라면 바로 전사 자동화부터 시작하기보다, 읽기 export와 작은 테스트 정책부터 만들어 운영자가 이해할 수 있는 변경 로그를 남기는 방식이 안전하다.

출처와 검증