ブログに戻るAIセキュリティ

スクリーンショット PII流出: 内部ツール GDPR

Slack、Confluence、メールなど内部ツールで共有されたスクリーンショットからのPII流出防止。

March 6, 20266 分で読めます
screenshot PIIinternal toolsGDPR compliancedata leakageJira Slack security

まだ監査していないDLPの盲点

DLPツールはネットワークトラフィック、メールの添付ファイル、ファイル転送を監視します。SSN列を含む表計算を検出します。顧客リストを含むメールにフラグを立てます。医療記録を含むアップロードをブロックします。

スクリーンキャプチャは検出しません。

スクリーンキャプチャは画像ファイルです。その中の個人情報はピクセルとして描画されています。テキストとして保存されていません。個人情報のパターンをスキャンするDLPエンジンは何も検出できません。

毎日、従業員がSlack、Jira、Teams、メールチェーンにスクリーンキャプチャを貼り付けています。DLPアラートはまったく発生しません。

スクリーンキャプチャが職場で個人情報を広める仕組み

リモートワークとハイブリッドワークにより、キャプチャの共有が一般的になりました。社内ツールは毎日それらで埋まっています。

チームメンバーは素早いコンテキスト共有のためにキャプチャを使います:

  • サポート担当者が顧客アカウントの画面をチームリーダーと共有します。
  • 開発者がユーザー入力データを含むエラーログを共有します。
  • アカウントマネージャーがCRMレコードを財務チームにコンテキストとして送ります。
  • IT管理者がシステム画面をキャプチャして設定を業務委託先に記録します。
  • プロダクトチームがダッシュボード画面をステークホルダー更新で共有します。

各添付ファイルには個人情報が含まれている可能性があります。顧客アカウントのキャプチャには名前、メール、ステータス、請求先住所が含まれます。エラーログファイルにはユーザーが入力した名前、住所、電話番号が含まれることがあります。CRMレコードのキャプチャにはアカウントの全プロファイルが含まれます。ダッシュボードファイルにはグラフラベルにユーザーIDが表示される場合があります。

アクセス制御の問題

スクリーンキャプチャの共有はアクセス制御の問題も引き起こします。

ほとんどの組織は本番システムにロールベースのアクセス制御を適用しています。サポート担当者は自分のキューのレコードしか見ることができません。業務委託先は割り当てられたプロジェクトファイルしか見ることができません。

担当者が顧客レコードをキャプチャして業務委託先と共有するSlackチャンネルに貼り付けると、アクセス制御が回避されます。業務委託先は通常のルートでは到達できなかった個人情報を取得します。業務委託先の作業を規定するDPAがこの転送をカバーしていない可能性があります。顧客のGDPR権利がその業務委託先に適用されない可能性があります。

この回避はGDPR第5条(1)(f)の問題です。完全性と機密性に関するものです。業務委託先が適切なDPAなしに個人情報を受け取る場合、第28条の整合性の問題も生じる可能性があります。第28条の義務のチェックリストについてはGDPRコンプライアンスガイドを参照してください。

技術的保護措置としての画像PII検出

キャプチャベースの個人情報漏洩に対する技術的保護措置はOCRとNLP検出の組み合わせです。手順は簡単です。

  1. 従業員が顧客インターフェースの画面をキャプチャします。
  2. 共有前に:キャプチャを検出ツールにアップロードします。
  3. ツールがOCRで可視テキストを抽出します。
  4. NLPがテキスト内のPIIエンティティを特定します。
  5. 従業員がレポートを確認します:「このキャプチャには[顧客名]、[メールアドレス]、[アカウントID]が含まれています。」
  6. 従業員はPIIを編集するか、共有範囲を絞るか、書面による理由と共に続行します。

これはすべての共有をブロックしません。移動する前に個人情報を表示します。人々はその後に情報に基づいた選択ができます。これがあなたのセキュリティページの保護スタックにどう適合するかをご覧ください。

ユースケース:SaaSヘルプデスクのJiraキャプチャポリシー

あるSaaS企業のヘルプデスクはアカウントの問題を記録するためにJiraを使用していました。チケットに添付されたファイルにはユーザーの個人情報が含まれていました。具体的には:

  • アカウント管理画面からのユーザーメールアドレス。
  • サブスクリプションプランの詳細。
  • 請求金額と日付。
  • 一部のケースでは部分的な支払いデータ。

GDPRの監査で18ヶ月間に作成された847件のJiraチケットが見つかりました。すべてに個人情報の添付ファイルがありました。Jiraは200人全員のエンジニアがアクセス可能でした。一部は顧客請求記録のDPAを持たない業務委託先でした。

是正手順:

  1. 遡及監査:既存の全添付ファイルに対するPII検出。312件のチケットがDPOレビュー用にフラグ付け。
  2. チケット整理:89件のチケットの添付ファイルを再添付前に編集。
  3. プロセス変更:Jira添付前にPIIチェックを必須とする新しいワークフロー。
  4. トレーニング:ヘルプデスク全スタッフへの15分間のセッション。

90日後の結果:

  • JiraでのPIIインシデント:90パーセント減少。
  • 残りのインシデント:書面による診断的理由と共に続行したケース。
  • DPAの範囲:業務委託先への不要な個人情報露出を削減するよう更新。

歴史的な312件のチケットはコンプライアンス上の指摘事項でした。90パーセントの減少は監査応答における是正の証拠となりました。

チームワークフローへのキャプチャレビューの組み込み

業務を遅らせることなくPII制御を望む組織には、いくつかの選択肢があります。

軽量オプション: SlackやJiraに貼り付ける前に従業員が使うブラウザツール。キャプチャをドラッグし、5秒でPIIレポートを取得し、続行または編集します。

JiraまたはServiceNowフック: ファイルがチケットに届く前に実行される検出。ファイルアップロード前のウイルススキャンのように機能します。

Slackボット: 選択したチャンネルでキャプチャのアップロードを受け取るボット。PII検出を実行します。検出されたエンティティでスレッドの返信を投稿します。これにより、ワークフローをブロックせずに個人情報が可視化されます。

チーム規範とサンプリング: 週次の自動チェック。コラボレーションツール内のキャプチャの10パーセントをサンプリング。検出を実行。チームリーダーに結果を報告。これにより、ワークフローをブロックせずに説明責任が生まれます。

GDPRの記録として:キャプチャのPII制御は第32条の「組織的措置」として認められます。保護措置を文書化します — ポリシーと技術ツール。使用の証拠を追加します。これにより第5条(2)の説明責任規則を満たします。コンプライアンスページと第32条の用語集エントリを参照してください。

anonym.legalがあなたのチームのためにこれをどのように処理するか確認したいですか?プランページを訪問するか、脱識別化に関する創業者声明をお読みください。

出典

データを保護する準備はできましたか?

48言語で273のエンティティタイプを使用してPIIを匿名化し始めましょう。