こんにちは。Azure Security サポートチームです。
今回は AIPスキャナーが対象ファイルを破損させてしまう事例とその回避方法についてご案内いたします。
AIP スキャナーによるスキャンによって対象ファイルが破損するシナリオ
1.スキャナー ノードの記憶域の空き領域が逼迫している状態でラベル付け処理を行うとファイルが故障します。
AIP スキャナーはスキャン対象のファイルを検査・ラベル付け処理を行う際に、スキャナー コンピューターの一時領域に対象ファイル データを転送し、秘密度ラベルの適用処理後に
スキャン対象のリポジトリ パスにある原本と差し替えます。
現状の仕様ではスキャナー ノードの記憶域が十分に確保されていない場合にもコンテンツ スキャン ジョブは実行されてしまいます。この場合、スキャナー本体の記憶域の範囲内で
不完全なデータの状態で対象のコンテンツをラベル付けし、元のリポジトリ パスにあるファイルを差し替えるため、結果としてラベル付けされたファイルが故障してしまう場合があります。
<回避策>
スキャナー ノードの記憶域は十分な空き領域を確保いただくようにお願いいたします。
公開されている AIP スキャナーの前提条件では一時ファイルとして 10 GB は確保いただくことをお勧めしております。
<参考>
Azure Information Protection (AIP) 統合ラベルスキャナーの前提条件
2.異なるスキャナー クラスターに参加する複数の AIP スキャナーで同一のリポジトリをラベル付け処理するよう構成するとファイルが故障する場合があります。
同一のリポジトリを対象にしたコンテンツ スキャン ジョブを設定した別々のクラスターに参加するノードでスキャンを実行すると、コンテンツ スキャンのタイミングがノード間でバッティングしてしまう場合があります。同一のコンテンツに対して複数のノードによるコンテンツ スキャンのタイミングがバッティングしてしまうと、最初のスキャン ジョブによるラベリング処理途中のコンテンツを後続のスキャン ジョブによってキャプチャしてしまう場合があり、この場合にも AIP スキャナーが 1. のシナリオと同様に不完全なデータをキャプチャして元のリポジトリに返すことでラベル付け処理されたコンテンツが故障する場合があります。
<回避策>
AIP スキャナーをスケールアウトする場合、単一のスキャナー クラスターに複数のノードを参加させて構成します。複数のノードで構成されているスキャナー クラスターは共有するデータベースによって、スキャン対象のリポジトリのスキャンに関するデータが共有され、各ノードが効率的にスキャンを行うよう動作します。
※以下の図は代表的なスキャナーのアーキテクチャの概要図になります。
図 1: Security,Compliance,and Identity に公開された “Best practices for deploying and using the AIP UL scanner“ より抜粋
上記を踏まえ、スキャナーのパフォーマンス向上の観点でスキャナーのノードの増設を検討する場合には、別々のリポジトリをスキャンするよう複数のクラスターを構成するか、同一のクラスターに
複数のノードを参加させるよう構成いただくことを検討ください。
<参考>
Azure Information Protection (AIP) 統合ラベル スキャナーをインストールして構成する
3.対象のリポジトリ内のコンテンツが DFS レプリケーション等で複数のファイル サーバーと同期途中の状態でラベル付け処理を行うとファイルが故障する可能性があります。
スキャン対象のコンテンツが DFS レプリケーションなど複数のファイル サーバー間でデータの同期を行うよう構成されている場合、レプリケーション途中のファイルを AIP スキャナーがキャプチャしてしまう場合があります。
この場合にも 1. のシナリオと同様のメカニズムにより AIP スキャナーが不完全な状態のデータをキャプチャしラベル付けした上で元のリポジトリにあるファイルと差し替えをしてしまいファイルが故障してしまう場合があります。
<回避策>
DFS レプリケーションを構成している環境では、レプリケーションのスケジュール調整ならびにコンテンツ スキャン ジョブのスケジュールを “手動” に設定いただき、レプリケーションを実施する時間とコンテンツ スキャン ジョブが実行される時間帯が重複しないように調整いただくことを検討ください。
4. AIP スキャナーがスキャン対象としているリポジトリに対して、AIP クライアント側から一括ラベル付け処理を実施するとファイルが破損する可能性があります。
上記の 1 ～ 3 のシナリオにて解説いたしました AIP スキャナー と同様に AIP クライアントも対象ファイルをラベル付け処理を行う際に、対象のファイルをローカルのプロファイル内にある一時フォルダにコピーした後に処理を実施します。
スキャナーによるファイル処理と AIP クライアントによるファイル処理がバッティングしてしまうと、不完全なファイルをキャプチャする事象が発生し、ラベル付け処理が行われたファイルが破損する可能性があります。
<回避策>
実際の環境でスキャン ジョブによる処理と AIP クライアントによるラベル付け処理がバッティングしてしまう可能性は現実的には低いと考えられますが、理論上はファイルが破損するリスクがあります。
AIP クライアントの GUI や PowerShell コマンド (Set-AIPFileLable) コマンドによって一括ラベル付け処理を計画される場合には、対象のフォルダ パスが AIP スキャナーのコンテンツ スキャン ジョブと重複していないか事前に確認いただくなど、運用によってリスクを低減することを検討ください。
5. スキャン対象のリポジトリのファイル容量が逼迫している場合、スキャン対象のファイルが破損する可能性があります。
AIP スキャナーのローカルにある一時記憶域にてラベル付け処理が完了したファイルは、最終的にスキャン対象の元のリポジトリのファイル パスにあるデータと差し替えられます。
スキャナーがリポジトリ先の記憶域の逼迫を検出できた場合には、スキャン処理が失敗しますが、リポジトリ側の記憶域の逼迫の検出タイミング等の何らかの要因により、スキャナーがラベル付けを行ったファイルの差し替え処理の継続を試みる可能性があります。
対象リポジトリの記憶域が逼迫していることでデータの差し替えに失敗し、スキャン対象のファイルが破損する可能性があります。
<回避策>
スキャナー コンピューター自体の記憶域だけでなく、スキャン対象のリポジトリの記憶の空き容量にも十分注意いただくようお願いいたします。
AIP スキャナーにはラベル付け処理によって壊れてしまったファイルを復元する機能はありません。
今回の記事でご案内させていただいた各シナリオの情報が、AIP スキャナーを適切に展開/運用いただくことに寄与しましたら幸いです。
※本ブログ記事化にあたり、弊社サポートによる調査にご協力いただきましたお客様に深く感謝いたします。
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。