セキュリティ

Microsoft PurviewエンドポイントDLPでマイナンバーを検出する仕様と動作を確認してみた

こんにちは、臼田です。

みなさん、DLPしてますか？(挨拶

今回はタイトルの通り、Microsoft PurviewのエンドポイントDLPを利用して、日本のマイナンバーを検出する動作を見ていきます。

仕様や動作の原理を細かく確認し、実際に利用できる状態にしていきます。

概要

Microsoft PurviewのエンドポイントDLPでは様々な機密情報の移動を制御することが可能です。Information Protectionにある「機密情報の種類」をDLPの「ポリシー」に組み込むことで制御できます。簡単に書くと以下の図のイメージです。

「機密情報の種類」は事前にMicrosoftが用意したマネージドな機密情報の種類と、ユーザーが作成するカスタマイズした機密情報の種類があります。それぞれ以下に詳細情報があります。

日本のマイナンバーをエンドポイントDLPで検出したい場合、マネージドな機密情報の種類に「日本の個人用マイ ナンバー(Japanese My Number Personal)」があるため、これを利用できます。

ちなみに、日本に関係するマネージドな機密情報の種類は2025/04/18現在下記9種類があります。

ただし、種類によりDLPポリシーに組み込めないものがあるため注意が必要です。Purviewの「情報保護 -> 分類子 -> 機密情報の種類」にて「サポート対象プラットフォーム」を確認できますので詳細はこちらを確認してください。現段階では「日本の物理アドレス(Japan Physical Addresses, つまり住所)」はエンドポイントDLPでは利用できません。

マイナンバー検出の詳細仕様

「機密情報の種類」の仕様を確認するには少しコツが要ります。

まずドキュメントの確認から行います。

マネージドな機密情報の種類の一覧から日本の個人用マイ ナンバーのページを開きます。

以下のようにフォーマットやパターンが書かれています。

そしてその下に定義があるのですが、これが厄介なところです。ここには利用する組み込み関数やキーワードのリストが書かれています。

そして、これらの詳細の説明はありません。組み込み関数の一覧はこちらにありますが、本当に一部の関数だけ説明されているだけで、上記のマイナンバーを検出する関数については説明がありませんでした。

というわけで、実際の「機密情報の種類」の設定を見ていきましょう。

「情報保護 -> 分類子 -> 機密情報の種類」にて「Japanese My Number Personal」を選択して詳細を表示すると以下のように右カラムに詳細情報として、どのような内容になっているか見えます。

下の方もスクロールして確認すると、「Japanese My Number Personal」では2つのパターンがあることが確認できます。

しかし、これでもまだ詳細がわかりません。

マネージドな機密情報の種類は設定内容の詳細を「編集画面で確認する」という力技ができないのですが、設定をコピーして利用することができるため、そちらから編集画面で確認をやってみます。

詳細画面から「コピー」をクリックします。

出来上がったカスタマイズした機密情報の種類を編集して内容を確認していきましょう。

次のページに進むと詳細な定義を確認できます。2つのパターンがありましたが、それぞれ信頼度がHighとLowだったんですね。そしてパターンごと編集でさらに詳細を確認してみます。

パターン1では関数とリストがありましたが、この内関数の方は編集でも関数名しかわからず、関数自体はおそらくユーザーが実装できないもののため、これ以上詳細はわかりません。「おそらく12桁の数字を検出するもの」と考えておくのが良さそうです。

一方でキーワードのリストは以下のように確認できました。「個人 番号」「マイ ナンバー」などマイナンバーと関連する語句が並んでいます。これらが「単語の一致」で検出するようになっています。

もう1つのキーワードグループでは、「文字列の一致」で同じようなワードが並んでいます。

つまり、関数による単純な12桁の検出だけではなく、これらのマイナンバー関連用語が番号の前後に含まれる場合はHighとして検出される、真偽は不明だが12桁の検出だけした場合はLowとして検出される、と解釈すれば良さそうです。

検出をテストする

「機密情報の種類」はPurviewの画面上でテストを実行できます。先程確認した仕様に対して、実際にどのようなファイルがどう判定されるかテストしていきましょう。

「機密情報の種類」の詳細画面で「テスト」を押します。

準備したファイルは「個人番号」という文字列と、ダミーのマイナンバー12桁が書かれたものです。マイナンバーのテスト用番号の扱いがいまいちはっきりしなかったので、ここでは伏せておきます。

このファイルをアップロードして「テスト」を実行します。

照合結果として、High, Medium, Lowがそれぞれ検出されました。なぜMediumもあるのかは謎ですが、少なくとも結果的にはHighとして扱われそうです。マイナンバーだけでなく、補助要素の「個人番号」と合わせて検出していることからHighの判定になっていることがわかります。

では続いて、マイナンバー12桁だけで他の文字列がないファイルで試してみましょう。

こちらは予想通り、Lowのみの検出となりました。補助要素は空欄となり、関数による12桁の番号の検出だけが反応していることがわかります。

これで「機密情報の種類」がどのように反応するのか確認できました。

エンドポイントDLPでの検出

間違いなく動作する対象のファイルを用意できたので、実際のエンドポイントで試していきましょう。

DLPポリシーのルールを編集し、条件に「機密情報の種類」を設定します。

制限する操作として「デバイスでアクティビティを監査または制限する」にて各種アクションを選択します。

今回は「すべてのアプリ向けファイルアクティビティ -> RDPを使用してコピーまたは移動する」で検出を試しますのでこれを設定します。

エンドポイントのWindowsにRDP接続し、コピーをすると以下のように検出されました。

管理側でも検出した結果を確認します。アクティビティエクスプローラーでイベントが検出されています。

「DLP rule matched」と「File copied to remote desktop session」が検出されました。

確認するとファイル名や対象のユーザー、どの機密情報の種類なのかが確認できたり、

下の方ではファイルパスや操作したアプリケーションも確認できます。

まとめ

Microsoft PurviewのエンドポイントDLPでマイナンバーに関するアクティビティを検出するのを試してみました。

他の「機密情報の種類」もそうですが、適切に扱うためには中身の設定をなるべく把握しておく必要があります。

今回の手順で環境に適用する前に詳細を理解することできますので、ぜひ試してみてください。

臼田 佳祐

AWSとセキュリティやってます。普段はクラスメソッドで働いてます。クラウドネイティブでは副業としてセキュリティサービスの検証とかやってます。

記事一覧