Workspace Studio DLP 설정: 민감정보 외부 공유를 차단하고 내부 flow를 지키는 법
TL;DR
DLP for Studio는 Workspace Studio flow의 각 step이 실행되기 전에 Referenced sources, Step inputs, 결과를 볼 사람의 범위를 검사합니다. 조건이 맞으면
Block Studio flows
,
Require user approval
,
Audit only
가운데 설정한 action을 적용합니다.
이 글에서는 별도 변경 절차에서 만들어 동료 검토까지 끝낸 inactive 규칙으로 시작합니다. 비민감 확인 문구와 통제 가능한 테스트 계정만 씁니다. 확인 문구가 있는 외부 flow는 멈추는지, 같은 문구를 쓰는 내부 flow는 계속되는지 확인합니다. 차단 결과뿐 아니라 Rule log events까지 대조해야 완료입니다.
핵심 3줄 요약
핵심 1
Google Admin console의 Rules에서 동료 검토를 마친 inactive 파일럿 DLP 규칙을 엽니다.
핵심 2
content condition과 외부 audience condition을 함께 두고 action은 Block Studio flows로 정합니다.
핵심 3
비민감 marker를 사용해 외부 run 차단, 내부 run 유지, 로그 기록을 한 묶음으로 검증합니다.
이 글에서 다룰 내용
- DLP for Studio가 검사하는 데이터와 실행 시점
- 지원 에디션과 필요한 관리자 권한
- 승인된 inactive rule의 scope와 condition을 검토하고 활성화하는 순서
- 외부 차단과 내부 협업 유지를 확인하는 비민감 테스트
- 그대로 복사해 쓰는 두 flow 설계 프롬프트
- 10 MB 분석 한도와 링크·외부 소유 파일 등 알려진 사각지대
- Rule log events로 결과를 재확인하는 방법
해결할 문제: 외부 차단을 켜다가 내부 자동화까지 멈춥니다
Workspace Studio flow는 Drive, Gmail, Chat, Calendar와 서드파티 앱의 데이터를 단계별로 사용할 수 있습니다. 데이터 조건을 넓게 잡거나 scope를 곧바로 전사로 지정하면 필요한 내부 flow도 멈출 수 있습니다. 반대로 외부 audience만 보고 데이터 조건을 빼면 공개 가능한 결과까지 차단할 수 있습니다.
따라서 첫 완료 지점은 전사 정책도 새 규칙 작성도 아닙니다. 동료가 이미 검토한 inactive 규칙과 파일럿 사용자 한 명이 소유한 비민감 테스트 파일로 양쪽 결과를 확인합니다. 외부로 나갈 때만 현재 run이 차단되어야 합니다. 내부 flow는 유지되어야 하며 로그에서는 같은 rule을 찾을 수 있어야 합니다.
기능 정의: DLP for Studio란 무엇인가
DLP for Studio는 flow가 실행될 때 각 step의 민감정보와 데이터 경계를 검사하는 Google Workspace 데이터 보호 기능입니다. 공식 도움말은 검사 대상을 세 범위로 나눕니다. step에서 사용한 변수의 출처인 Referenced sources, prompt와 변수 등 step 설정에 들어간 Step inputs, 결과를 누가 볼 수 있는지 나타내는 audience입니다.
조건을 만족하면 action은 step 실행 전에 적용됩니다.
Block Studio flows
는 현재 run을 멈춥니다. Activity 페이지에서 사용자에게 알리고 event도 기록합니다. 이 action은 같은 flow의 다른 run까지 모두 꺼 버리지는 않습니다.
Require user approval
은 Approvals 페이지에서 사람 검토를 기다립니다.
Audit only
는 실행을 막지 않은 채 event만 남깁니다. 비슷한 rule끼리 action이 충돌하면 더 엄격한 action이 우선합니다.
지원 조건과 테스트 경계를 먼저 확인합니다
공식 전용 도움말이 명시한 지원 에디션은 Frontline Standard·Plus, Enterprise Standard·Plus, Education Fundamentals·Standard·Plus, Enterprise Essentials Plus입니다. 다른 에디션이나 인접한 Gemini DLP의 조건을 가져다 쓰지 말고 현재 계약과 Admin console에서 메뉴를 확인합니다.
규칙을 검토하고 활성화하려면 View and Manage DLP rule privileges가 필요합니다. 파일럿에는 실제 고객 자료나 개인정보를 넣지 않습니다. 테스트 사용자가 소유한 Drive 문서에는
파일럿 확인 문구 01
만 넣습니다. 조직이 통제하는 외부 테스트 계정과 내부 테스트 계정도 각각 준비합니다.
파일럿 확인 문구는 탐지 흐름을 확인하기 위한 내부 fixture입니다. 제품이 제공하는 정보 유형이나 보안 등급이 아닙니다. 실제 민감정보 detector로 확대하는 결정, scope 확대, 예외 추가는 이번 첫 검증 뒤의 별도 승인으로 남깁니다.
실행 순서: 외부 차단과 내부 유지를 양쪽 검증합니다
1단계. 현재 정책과 파일럿 소유자를 기록합니다
Admin console에서 현재 data protection rule 목록과 Workspace Studio 사용 가능 여부를 확인합니다. 작업자, 검토자, 파일럿 조직 단위 또는 그룹, 이전 rule 상태, 되돌릴 값을 기록합니다. rule scope가 제한될 때 파일 기준 적용은 접근자가 아니라 파일 소유자를 따르므로 테스트 Drive 문서는 파일럿 사용자가 직접 소유하게 합니다.
중단 기준도 정합니다. 외부 flow가 marker를 포함한 채 실행되거나, 내부 flow가 같은 rule 때문에 막히거나, 적용 rule과 event를 로그에서 확인하지 못하면 scope를 넓히지 않습니다.
2단계. Rules에서 승인된 inactive 파일럿 rule을 엽니다
Google Admin console의
Rules
에서 별도 변경 절차로 저장된 inactive rule을 엽니다. rule 이름과 설명에 파일럿 목적, owner, 검토일이 있는지 확인합니다. 공식 create-rule 도움말은 Inactive를 고르면 rule을 저장하되 아직 적용하지 않고 동료와 내용을 검토할 수 있다고 설명합니다. 이 글에서는 그 검토가 끝난 rule만 이어받습니다.
Scope는 전사가 아니라 승인된 파일럿 조직 단위 또는 그룹으로 제한합니다. 조직 단위와 그룹 설정이 충돌하면 그룹이 우선합니다. 우선순위를 확인하지 않은 채 사용자를 여러 scope에 겹치게 넣지 않습니다.
3단계. content와 audience를 AND로 묶습니다
전용 도움말의 condition 이름을 기준으로 저장된 값을 검토합니다. content 쪽은 Referenced sources에서 Drive source data의
파일럿 확인 문구 01
을 찾도록 되어 있어야 합니다. audience 쪽은 Block sharing with external users and agents여야 합니다. 값이 다르면 이 글에서 즉석 수정하지 말고 원래 변경 절차로 돌려보냅니다.
두 조건은 AND로 묶습니다. 이 구성은 marker가 있고 결과가 조직 밖으로 나갈 때만 테스트 rule이 맞도록 범위를 좁힙니다. source 전체를
Any data
로 검사하면 실제 step이 그 데이터를 사용하지 않아도 overly restrictive할 수 있다는 공식 경고가 있으므로 첫 파일럿에서는 피합니다.
4단계. action을 Block Studio flows로 정하고 활성화합니다
Action은
Block Studio flows
로 정합니다. 기존 외부 승인 글의
Require user approval
과 달리 이 action은 사람이 승인해서 계속하는 흐름이 아니라 조건에 맞는 현재 run을 취소하는 흐름입니다. 사용자 안내 문구를 넣을 수 있는 화면이 보이면 파일럿 rule 이름과 내부 문의 경로만 적고 민감한 detector 상세는 노출하지 않습니다.
검토자가 scope, AND 조건, action, 되돌릴 값을 승인하면 rule을 Active로 바꿉니다. 공식 도움말은 변경이 최대 24시간 걸릴 수 있지만 일반적으로 더 빠르다고 안내합니다. 즉시 보이지 않는다고 rule을 중복 생성하지 말고 적용 시간을 기록한 뒤 기다립니다.
5단계. 외부·내부 flow를 별도로 Test run합니다
Workspace Studio에서 확인 문구 문서를 읽어 한 줄 알림을 만드는 flow 두 개를 준비합니다. 하나는 조직이 통제하는 외부 테스트 계정을 대상으로 합니다. 다른 하나는 내부 테스트 계정을 대상으로 합니다. 대상 주소만 바꾼 같은 flow를 반복하지 말고 이름과 목적을 분리합니다.
외부 flow는 확인 문구가 있는 source와 외부 audience를 동시에 만족하므로 현재 run이 차단되어야 합니다. 내부 flow는 같은 확인 문구를 쓰더라도 외부 audience 조건이 맞지 않으므로 이 rule 때문에 차단되면 안 됩니다.
Run Completed
나
Blocked
표시만 보지 말고 실제 지정 대상, source, rule 이름을 대조합니다.
6단계. Activity와 로그를 대조한 뒤 확대 여부를 정합니다
차단된 외부 run은 Workspace Studio Activity 페이지에서 확인합니다. 관리자는 Rule log events와 Workspace Studio log events에서 같은 테스트 시각, 파일럿 사용자, rule, flow 식별자를 찾아 기록합니다. DLP 전용 도움말은 위반이 실제 incident인지 false positive인지 조사하라고 안내합니다.
검증표에는
외부 marker run 차단
,
내부 marker run 유지
,
rule event 확인
,
실제 민감정보 미사용
,
사람 검토 완료
를 각각 남깁니다. 모두 확인된 뒤에도 전사 확대는 자동으로 하지 않습니다. 실제 detector와 업무 범위를 정한 별도 변경 승인을 받아야 합니다.
그대로 복사해 쓰는 파일럿 flow 설계 프롬프트
아래 프롬프트는 두 flow의 초안을 만드는 용도입니다. 생성된 단계를 검토하고 DLP rule 적용 시간을 확인한 사람만 Test run을 누릅니다.
목표: 비민감 확인 문구 문서를 읽어 한 줄 알림을 만드는 내부용 flow와 외부 차단 검증용 flow를 각각 설계한다.
허용 입력: 파일럿 사용자가 소유한 Drive 테스트 문서, 파일럿 확인 문구 01, 승인된 내부 테스트 계정, 조직이 통제하는 외부 테스트 계정, 테스트 번호만 사용한다.
제외 입력: 고객·임직원 자료, 계약·인사·재무 자료, 운영 자료, 외부 소유 파일, URL로 연결한 자료, 운영 중 flow, 대량 수신자는 사용하지 않는다.
출력 형식: flow 이름, source owner, marker, audience 역할, step 목록, 예상 DLP 결과, 사람이 확인할 값, 중단 조건을 두 flow별 목록으로 제시한다.
완료 기준: 외부 flow의 현재 run은 Block Studio flows로 멈춰야 한다. 내부 flow는 같은 rule 때문에 멈추지 않아야 하며 Activity와 rule log에서 결과를 대조할 수 있어야 한다.
추측 금지: 주소·조직 경계·rule 상태·적용 시간·권한·로그 결과를 추정하지 말고 화면이나 입력에 없는 값은 확인 필요로 표시한다.
승인 지점: 사람이 생성된 step, source owner, audience, rule 상태를 검토한 뒤 각각 한 번만 Test run한다. detector 변경·scope 확대·예외 추가는 별도 승인 전 실행하지 않는다.
실무 인사이트: 차단 한 건이 정책 전체를 증명하지 않습니다
Block Studio flows
는 조건에 맞은 현재 run을 멈춥니다. 같은 flow의 이후 run이나 다른 flow를 자동으로 모두 끄는 master switch가 아닙니다. 그래서 차단 화면 한 장보다 어떤 source, input, audience condition이 맞았는지 로그에서 확인하는 일이 중요합니다.
내부 flow가 통과했다고 해서 민감정보 detector의 정확도가 증명된 것도 아닙니다. 이번 marker 테스트가 확인하는 것은 rule 조합과 외부 경계입니다. 실제 detector의 false positive와 false negative, 데이터 분류 체계, 법적 기준은 승인된 별도 표본과 담당자 검토가 필요합니다.
주의할 점
- 각 step에서 추출된 텍스트는 처음 10 MB만 분석됩니다. 파일 전체를 검사했다고 표현하지 않습니다.
- AI-powered step에 URL로 연결한 resource, Gemini가 찾은 source, 조직 밖 사용자가 소유한 파일은 문서가 설명한 미검사 범위에 포함됩니다.
- Drive 파일을 외부 구성원이 든 Google Group과 공유한 경우 DLP for Studio가 외부로 인식하지 못할 수 있습니다.
- AI-generated text는 source의 classification label을 상속하지 않으며 Workspace Studio에서 label이 붙은 것으로 간주되지 않습니다.
-
Referenced sources는 실제 step에서 쓰지 않은 source data까지 맞힐 수 있어 overly restrictive할 수 있습니다. pilot에서 condition을 좁혀 검증합니다. - DLP for Studio의 외부 판정은 같은 Workspace Studio customer ID 기준이며 Gmail DLP의 trusted domain이나 domain alias 기준과 다를 수 있습니다.
- rule 변경은 최대 24시간 걸릴 수 있습니다. zero-hit 또는 즉시 미적용을 실패로 단정해 같은 rule을 다시 만들지 않습니다.
- block은 승인, 권한 회수, 보존 정책, 법적 판단을 대신하지 않습니다. 정상 업무 유지와 실제 incident 판단은 사람이 맡습니다.
자주 묻는 질문
Q1. Block Studio flows를 고르면 flow 자체가 영구히 꺼지나요?
아닙니다. 공식 도움말은 조건을 위반한 현재 run을 멈춘다고 설명합니다. 같은 flow의 다른 run은 조건이 다르면 계속될 수 있으므로 매 event의 source와 audience를 확인합니다.
Q2. 내부 flow도 같은 확인 문구를 쓰면 막히나요?
이 글의 rule은 확인 문구 content condition과 외부 audience condition을 AND로 묶습니다. 내부 audience라면 외부 조건이 맞지 않아 이 rule 때문에 차단되면 안 됩니다. 실제 결과가 다르면 scope, condition operator, 다른 DLP rule을 확인합니다.
Q3. Drive 링크를 prompt에 넣으면 링크 대상 파일도 검사되나요?
공식 도움말은 AI-powered step의 prompt에 링크한 resource와 Workspace Studio source에서 Gemini가 찾은 자료를 검사하지 않는다고 명시합니다. 중요한 source는 링크가 있으니 안전하다고 추정하지 말고 별도 접근 권한과 데이터 취급 절차를 적용합니다.
Q4. 외부 flow가 차단되면 테스트가 끝난 것인가요?
아닙니다. 내부 flow가 유지되는지, Rule log events와 Workspace Studio log events에 같은 rule과 flow 맥락이 남는지, 실제 민감정보를 쓰지 않았는지까지 확인해야 합니다. 그 뒤에도 detector와 scope 확대는 별도 승인입니다.
출처
마무리
Workspace Studio DLP 설정의 첫 성공 기준은 차단 횟수가 많아지는 것이 아닙니다. 좁은 파일럿에서 확인 문구가 있는 외부 run만 멈춰야 합니다. 같은 문구를 쓰는 내부 run은 유지되어야 하며 같은 결과를 로그로 설명할 수 있어야 합니다.
규칙을 inactive로 검토합니다. content와 audience를 AND로 묶은 다음 Block Studio flows를 활성화해 양쪽을 검증합니다. 실제 detector와 전사 scope는 이 증거를 사람이 승인한 다음 단계로 남겨야 자동화와 데이터 보호를 함께 지킬 수 있습니다.
