내부 지식 베이스의 스크린샷 PII
내부 지식 베이스 — Confluence, Notion, SharePoint, GitBook — 에는 표준 컴플라이언스 도구가 놓치는 특정 유형의 PII 문제가 있습니다. 바로 프로세스 문서에 사용된 스크린샷에 삽입된 고객 개인정보입니다.
이 패턴은 수천 개의 지원 및 운영팀에서 반복됩니다.
지원 담당자가 특이한 계정 설정을 발견합니다. 문제를 문서화하기 위해 고객 계정 페이지의 스크린샷을 찍습니다. 스크린샷에는 UI 헤더의 고객 이름, 계정 설정의 이메일, 플랜 세부 정보가 표시됩니다.
해당 문서가 내부 지식 베이스에 게시됩니다. 150명의 지원 담당자가 이를 볼 수 있습니다. 외부 헬프데스크의 계약업체 12명도 볼 수 있습니다. 문서는 유용합니다. 해당 엣지 케이스를 처리하는 방법을 보여줍니다. 앞으로 그 설정을 접하는 모든 담당자가 이를 읽을 것입니다.
3년 후, 지식 베이스에는 그런 문서가 847개 있습니다. 각각 고객 계정 스크린샷을 포함합니다. 표시된 고객들은 개인정보의 이차적 이용에 동의하지 않았습니다. 대부분은 자신의 데이터가 거기에 저장되어 있다는 것을 모릅니다.
이것은 작은 문제가 아닙니다. 새 문서가 추가될 때마다 커집니다.
GDPR 노출: 왜 중요한가
지식 베이스 스크린샷에 대한 GDPR 분석은 명확합니다.
데이터 최소화 (제5조 제1항 c호): 개인정보는 "적절하고 관련성 있으며 필요한 것에 한정"되어야 합니다. 계정 설정에 관한 지식 베이스 문서에는 실제 고객 이름과 이메일이 필요하지 않습니다. 흐릿한 스크린샷으로도 목적을 충분히 달성합니다. 실제 고객 데이터를 포함하는 것은 필요하지 않습니다.
목적 제한 (제5조 제1항 b호): 하나의 목적 — 고객 서비스 — 을 위해 수집된 데이터는 합법적인 근거 없이 다른 목적 — 내부 프로세스 문서 — 에 재사용될 수 없습니다. 계정 기록은 서비스 제공을 위해 수집된 것이지 내부 문서화를 위한 것이 아닙니다. 이것은 두 가지 별개의 처리 목적입니다. 동일한 기록을 두 가지 모두에 사용하려면 대부분의 팀이 설정하지 않은 유효한 법적 근거가 필요합니다.
접근 제어 (제5조 제1항 f호 및 제32조): 적절한 기술적 조치로 개인정보를 보호해야 합니다. 150명의 모든 담당자와 계약업체 — 기본 계정 시스템에 접근 권한이 없는 사람들 포함 — 에게 공개된 도구의 고객 계정 스크린샷은 지나치게 광범위한 접근을 만듭니다.
삭제권 (제17조): 삭제를 요청하는 정보주체는 "지체 없이" 기록을 삭제받을 권리가 있습니다. 삽입된 스크린샷으로 23개의 지식 베이스 문서에 데이터가 나타나는 경우, 요청 처리에는 23개 문서 모두를 찾아 업데이트해야 합니다. 시스템 없이는 어렵습니다. GDPR 삭제권에 관한 단계별 안내는 GDPR 삭제권 가이드를 참조하십시오.
이것들은 엣지 케이스적 해석이 아닙니다. 일반적인 관행에 대한 규정 문구의 직접적인 적용입니다.
접근 제어 우회
Confluence 스크린샷에서 가장 심각한 컴플라이언스 문제는 생성되는 접근 제어 우회입니다.
지원팀은 역할 기반 접근 제어(RBAC)를 사용하여 고객 계정 시스템을 볼 수 있는 사람을 제한합니다. 1등급 담당자는 기본 계정 세부 정보를 봅니다. 2등급 담당자는 청구 및 기술 기록을 봅니다. 관리자는 전체 계정 프로필을 봅니다.
2등급 담당자가 전체 고객 계정 스크린샷으로 지식 베이스 문서를 만들면, 해당 스크린샷은 도구의 모든 사용자에게 표시됩니다. 청구 기록을 볼 수 없어야 할 1등급 담당자가 이를 볼 수 있습니다. 시스템 접근 권한이 없는 계약업체가 볼 수 있습니다. 온보딩 중인 신입 직원이 볼 수 있습니다.
스크린샷은 고객 계정 시스템의 RBAC 제어를 우회합니다. RBAC가 보호하도록 구축된 개인정보가 이제 지식 베이스에 접근 권한이 있는 모든 사람에게 공개됩니다.
이것은 이론적인 위험이 아닙니다. 문서 워크플로의 일반적인 결과입니다. 스크린샷은 만료 날짜, 접근 로그, 감사 추적 없이 그대로 남아 있습니다.
실용적인 시정 조치
GDPR 감사에서 이 문제를 발견한 팀을 위해:
소급 시정:
- 이미지 첨부 파일이 있는 모든 지식 베이스 페이지 식별
- 모든 첨부 파일에 이미지 PII 탐지 실행
- 플래그 된 이미지 검토: 높은 신뢰도 적중은 검토 대기열로 이동
- 각 플래그 된 이미지에 대해: 정리된 버전으로 교체하거나 페이지 접근 제한
- GDPR 기록을 위해 시정 조치 기록
소급 작업 규모는 지식 베이스 크기에 따라 다릅니다. 50명의 지원팀에서 3년된 지식 베이스의 경우 이미지 수가 수천 개에 달할 수 있습니다. 배치 이미지 처리가 이를 실행 가능하게 합니다. 플래그 된 이미지의 인적 검토가 핵심 병목입니다.
사전 예방적 제어:
- 모든 지원 직원을 교육하여 지식 베이스에 게시하기 전에 스크린샷을 정리하도록 함
- 도구 제공: 붙여넣기 전에 고객 이름을 흐리게 하는 스크린샷 주석 도구
- 검토 단계 추가: 게시 전에 이미지의 고객 PII를 특별히 확인하는 지정 검토자
- Confluence 첨부 파일 전체에 분기별 배치 이미지 스캔 실행
최소 실행 가능 제어: 게시 체크리스트: "게시 전에 스크린샷에서 모든 고객 이름, 이메일, 계정 ID를 제거하거나 흐리게 하십시오." 저기술, 비자동화이지만 문서화된 제어를 만듭니다. 소규모 팀의 경우 이것이 출발점입니다.
광범위한 법적 프레임워크는 GDPR 컴플라이언스 개요를 참조하고, 체크리스트만으로는 왜 한계가 있는지는 기술적 제어 없는 정책이 실패하는 이유를 참조하십시오.
왜 문제가 시간이 지나면서 커지는가
체계적인 제어 없이는 지식 베이스 PII 노출이 복잡해집니다.
규모: 고객 스크린샷이 포함된 각 새 문서는 전체 노출에 더해집니다. 지원팀이 성장하고 지식 베이스가 확장됨에 따라 누적된 PII도 증가합니다. 이러한 도구를 유용하게 만드는 속성 — 게시 용이성, 영속성, 광범위한 접근 — 이 PII 문제를 악화시키는 요소입니다.
잊혀진 문서: 더 이상 발생하지 않는 오래된 엣지 케이스에 관한 문서가 접근 가능한 상태로 남습니다. 이후에 삭제 요청을 한 고객의 PII를 담고 있습니다. 아무도 2022년에 마지막으로 업데이트된 문서를 확인하지 않습니다.
팀 간 확산: 지식 베이스는 종종 교차 기능적으로 됩니다. 고객 스크린샷이 있는 지원 문서가 기능 요청이나 버그 보고의 맥락을 위해 제품팀, 엔지니어링팀 또는 외부 계약업체와 공유될 수 있습니다. 각 공유는 개인정보의 접근 대상을 넓힙니다.
삭제 백로그: 지식 베이스에 더 많은 고객 기록이 쌓일수록 삭제 요청에 응답하는 것이 더 복잡해집니다. 시스템 없이는 정보주체의 기록의 모든 인스턴스가 찾아지고 제거되었음을 신뢰할 수 있게 확인할 방법이 없습니다. 팀은 믿을 수 있는 삭제 확인을 할 수 없습니다.
지식 베이스 PII는 수정하는 것보다 예방하는 것이 더 쉽습니다. 지금 설정된 제어는 복잡해지는 시정 문제를 방지합니다. 스크린샷 흐리게 하기 없이 게시된 모든 문서는 미래로 미뤄진 시정 작업입니다.