社内ナレッジベースのスクリーンショットに潜むPII問題
社内ナレッジベース — Confluence、Notion、SharePoint、GitBook — には、標準的なコンプライアンスツールでは見つけにくい特有のPII問題があります。それは、プロセスドキュメントに使用されるスクリーンショットに埋め込まれた顧客の個人データです。
このパターンは、数千ものサポートチームや運用チームで繰り返されています。
あるサポート担当者が、通常とは異なるアカウント設定を発見します。問題を記録するために、顧客のアカウントページのスクリーンショットを撮ります。そのスクリーンショットには、UIヘッダーに顧客名、アカウント設定にメールアドレス、プランの詳細が表示されています。
この記事が社内ナレッジベースに公開されます。150人のサポート担当者が閲覧できるようになります。外部ヘルプデスクの12人の業務委託者も同様です。記事は有用です。そのエッジケースへの対処方法を示しています。将来この設定に遭遇した担当者は誰でも読むことになります。
3年後、ナレッジベースには847本のこのような記事が蓄積されます。それぞれに顧客アカウントのスクリーンショットが含まれています。掲載されている顧客は、自分のデータがこのような二次利用に使われることに同意していません。ほとんどの顧客は、自分のデータがそこに保存されていることすら知りません。
これは小さな問題ではありません。新しい記事が公開されるたびに拡大します。
GDPRのリスク：なぜ重大なのか
社内ナレッジベースのスクリーンショットに関するGDPR分析は明確です。
データ最小化（第5条1項(c)）： 個人データは「適切で関連性があり、かつ処理の目的のために必要な範囲に限定されなければならない」とされています。アカウント設定に関する記事には、顧客の実名やメールアドレスは不要です。名前をぼかしたスクリーンショットで十分に目的を達成できます。実際の顧客データを含めることは必要ではありません。
目的の制限（第5条1項(b)）： ある目的 — 顧客サービス — のために収集したデータを、別の目的 — 社内プロセスドキュメント — に法的根拠なく再利用することはできません。アカウントデータはサービス提供のために収集されたものであり、社内記事のためではありません。これらは2つの異なる処理目的です。同じデータを両方に使用するには、ほとんどのチームが設定していない有効な法的根拠が必要です。
アクセス制御（第5条1項(f)および第32条）： 適切な技術的措置によって個人データを保護しなければなりません。アカウントシステムへのアクセス権を持たない担当者や業務委託者を含む150人全員がアクセスできるツールに顧客アカウントのスクリーンショットを置くことは、過度に広いアクセスを生み出します。
消去権（第17条）： 消去を請求するデータ主体は「遅滞なく」自分のデータを削除してもらう権利があります。そのデータが23本の記事に埋め込みスクリーンショットとして存在する場合、請求への対応には23本すべての記事を見つけて更新する必要があります。システムなしではこれは困難です。GDPRの消去権ガイドでは詳細な手順を説明しています。
これらは特殊な解釈ではありません。一般的な慣行に対する規制テキストの直接的な適用です。
アクセス制御の迂回
Confluenceスクリーンショットに関して最も深刻なコンプライアンス問題は、アクセス制御の迂回です。
サポートチームは、顧客アカウントシステムへのアクセスを制限するためにロールベースのアクセス制御（RBAC）を使用します。Tier 1の担当者は基本的なアカウント情報を見ます。Tier 2の担当者は請求情報と技術情報を見ます。管理者は完全なアカウントプロファイルを見ます。
Tier 2の担当者が顧客の完全なアカウントスクリーンショットを含む記事を作成すると、そのスクリーンショットはツールのすべてのユーザーに表示されます。請求情報を見るべきでないTier 1の担当者が閲覧できるようになります。システムアクセス権のない業務委託者も閲覧できます。オンボーディング中の新入社員も閲覧できます。
スクリーンショットは、顧客アカウントシステムのRBACコントロールを迂回します。RBACが保護するために設定された個人データが、ナレッジベースへのアクセス権を持つ全員に公開されます。
これは理論上のリスクではありません。ドキュメント作成ワークフローの通常の結果です。スクリーンショットは有効期限なし、アクセスログなし、監査証跡なしのまま残り続けます。
実践的な是正手順
GDPRの監査でこの問題を発見したチーム向けに：
遡及的な是正：
- 画像添付ファイルを持つすべてのナレッジベースページを特定する
- すべての添付ファイルにPII検出を実行する
- フラグが立てられた画像を確認：高信頼度の検出をレビューキューに送る
- フラグが立てられた各画像：サニタイズされたバージョンに置き換えるか、ページアクセスを制限する
- GDPR記録のための是正アクションを記録する
遡及的作業の規模はナレッジベースの大きさによります。50人のサポートチームで3年分のナレッジベースの場合、画像数は数千に達することがあります。バッチ画像処理によって実現可能になります。フラグが立てられた画像の人間によるレビューが主なボトルネックです。
予防的なコントロール：
- すべてのサポートスタッフに公開前のスクリーンショットサニタイズを教育する
- ツールを提供する：貼り付け前に顧客名をぼかすスクリーンショット注釈ツール
- レビューステップを追加する：指定されたレビュアーが公開前に記事を確認し、画像内の顧客PIIを特にチェックする
- Confluenceの全添付ファイルを四半期ごとにバッチスキャンする
最小限のコントロール： 公開チェックリスト：「公開前にスクリーンショット内の顧客名、メールアドレス、アカウントIDをすべて削除またはぼかしてください。」自動化されていませんが、文書化されたコントロールを作成します。小規模チームにはこれが出発点です。
より広い法的枠組みについてはGDPRコンプライアンス概要を参照してください。チェックリストのみのアプローチが大規模では機能しない理由については、技術的コントロールなしのポリシーが失敗する理由を参照してください。
なぜ問題は時間とともに悪化するのか
体系的なコントロールがなければ、ナレッジベース内のPIIへの露出は複合的に増加します。
量： 顧客スクリーンショットを含む新しい記事が追加されるたびに、総露出量が増加します。サポートチームが成長し、ナレッジベースが拡大するにつれて、蓄積されるPIIも増えます。これらのツールを有用にする特性 — 公開の容易さ、永続性、広いアクセス — こそがPII問題を悪化させます。
忘れられた記事： もう発生しない古いエッジケースに関する記事はアクセス可能なままです。それらには、その後消去請求を提出した顧客のPIIが含まれています。2022年に最後に更新された記事を誰もチェックしません。
チーム間への拡散： ナレッジベースはしばしば部門横断的になります。顧客スクリーンショットを含むサポート記事は、機能要求やバグレポートのコンテキストとして製品チーム、エンジニアリングチーム、または外部の業務委託者に共有されることがあります。共有のたびに個人データの閲覧者が増えます。
消去請求のバックログ： ナレッジベースに蓄積された顧客データが増えるほど、消去請求への対応が複雑になります。システムがなければ、データ主体のすべての情報を見つけて削除したことを確認する信頼できる手段がありません。
ナレッジベースのPIIは修正より防止の方が容易です。今実施するコントロールによって、複合的な是正問題を回避できます。サニタイズされていないスクリーンショットで公開されたすべての記事は、将来に先送りされた是正作業です。