Amazon Quick のデータ損失防止 (DLP) 機能を使ってみた
いわさです。
先月のアップデートになるのですが、Amazon Quick のデータ損失防止（DLP : Data Loss Prevention）の機能が追加されました。
この機能は DLP プロバイダーを接続することで Amazon Quick にデータ損失防止のポリシーを適用することができます。
本日時点では Microsoft Purview がサポートされており、Purview で定義した秘密度ラベルを Quick 側で読み取り、ラベルごとにファイルの扱い（ブロック・警告・許可）を出し分けることができるようになります。
適用先はチャット・スペース・ナレッジベースの3つで、特定のラベルが設定されたファイル以外は取り扱えないようにするとか、あるいは特定ラベルのファイルは扱えないようにするとか色々とカスタマイズも可能です。
これまで Microsoft 365 の中で使っていた Purview のラベルをそのまま Qmazon Quick の DLP ルールで扱えるイメージです。
環境としては前回の記事で Visual Studio サブスクリプションの中の Microsoft 365 E5 サンドボックスを使って Microsoft Purview の秘密度ラベルを作成して適用するところまで動作確認しています。
今日はその環境をそのまま使って Amazon Quick と連携させてみます。
設定してみる
AWS 公式ドキュメント上に設定の流れは記載されていますので設定にあたってはそちらを正として確認してください。
大まかな流れですが、まず事前に Microsoft Entra 管理センターでアプリを作成します。
そしてそのアプリのクライアント ID やシークレットなどを AWS Secrets Manager に登録します。
最後に Amazon Quick 上で DLP プロバイダーをセットアップし、デフォルトアクションや秘密度ラベルごとのアクションを設定して完了です！
Microsoft Entra 管理センターでアプリ作成
前提として前回の記事で Micosoft Purview 自体は導入済みなのでそのあたりは割愛しています。
有効化されてテナントの管理者で Microsoft Entra 管理センターにアクセスします。
Entra ID 側では、アプリを1つ登録して次の API アクセス許可を付与し、管理者の同意を行う必要があります。
アプリをシングルテナントのみで登録したあと、API を許可する必要があるのですが、どこにどの API があるのか見つけるのにちょっと苦労しました。
UnifiedPolicy.Tenant.Readは「所属する組織で仕様している API」の「Microsoft Information Protection Sync Service」から選択できます。
SensitivityLabels.Read.All は、「Microsoft Graph」から選択できます。
管理者の同意まですませておきました。
AWS Secrets Manager に登録
Entra アプリ登録後、アプリケーション（クライアント）ID と、ディレクトリ（テナント）ID を取得することができるのでこれを控えておきましょう。AWS 側で使います。
また、「証明書とシークレット」からクライアントシークレットも作成しましょう。で、シークレット値も控えておいてください。これも AWS 側で使います。
上記３つの Entra 側の値をですね、AWS 側では Secrets Manager にシークレットとして格納します。
次のように JSON 形式で。
{
"clientId": "（アプリケーションID）",
"clientSecret": "（クライアントシークレットの値）",
"tenantId": "（ディレクトリ(テナント)ID）"
}
コンソール上だとこんな感じ。
そして、Amazon Quick からこのシークレットを参照するので、シークレット ARN を控えておいてください。
Amazon Quick 上で DLP プロバイダーをセットアップ
いよいよ Amazon Quick 側での設定です。
Amazon Quick の管理コンソールのメニューに「ガバナンス」 -> 「データ損失防止」が追加されています。
ここからデータ損失防止機能で使う DLP プロバイダーの設定を追加することができます。
追加ウィザードではまずは DLP プロバイダーを選択するのですが、本日時点では Microsoft Purview のみが選択可能です。ただ、この作り方すると今後色々な DLP プロバイダーが追加されそうな雰囲気を感じますね。
続いて Microsoft Purview テナントを選択するので、ここで AWS Secrets Manager に先ほど作成したシークレットの ARN を指定しましょう。指定後に検証ボタンを押すと接続検証ができます。
Amazon Quick 側でのシークレットへのアクセス権限、Entra 側の API 権限や各種 ID が正しければいけるはず。
つづいてファイルをどのように Amazon Quick が処理するかカスタマイズする画面です。
Purview 連携の場合だと Purview 側で定義した秘密度ラベルに応じて Amazon Quick 側でどう処理させるかのアクションを定義できます。
また、どのラベルにも該当していないファイルの場合はデフォルトアクションを設定することもできます。
ラベルマッピングをしたらあとは最終確認して DLP プロバイダーの設定が完了です。
デフォルトでは作成した DLP 設定は無効化状態になっています。トグルボタンがオフになっているのが見えますかね。
これを有効化することで Amazon Quick 環境に適用されます。
なお、適用できる DLP 設定はアカウント上一つまでです。
DLP が有効になった環境でチャット機能を使ってみる
さて、DLP 設定ができたのでこれで Amazon Quick 上の挙動がどう変わるのか試してみましょうか。
事前に秘密度ラベルを設定したファイルと設定していないファイルを用意しておきました。
hoge-new-book.xlsx は Purview 秘密度ラベルが何も適用されていない、ローカルで新規作成された Excel ブックです。
customer-list-xxx.xlsx たちは組織の One Drive 上で秘密度ラベルを設定したブックたちですが、適用したラベルが異なります。
そして Quick 側のラベルアクションはこんな感じでマッピングしました。
デフォルトはブロックで、そして各ラベルごとのアクションを Allow、Warn、Block で選択しています。
ブロックの挙動
ではまずは、ブロックアクションがマッピングされているであろう、customer-list-hoge-secret.xlsx を Amazon Quick のチャット上にアップロードしてエージェントに処理させてみました。
ブロックされましたね！エージェントが処理することが出来ませんでした。
なお、エラーの詳細をコピーボタンを押すと、次のようなエラー情報を取得することが出来ます。DLP ポリシーで弾かれていることがわかりますね。良いじゃないか。
警告の挙動
つづいて警告アクションがマッピングされているであろう customer-list-opnfidential.xlsx を処理します。
今回はブロックされずに、処理前にまず警告ダイアログみたいなのが表示されました。
キャンセルか許可かボタンを押すことが出来ます。
許可を押してみると次のように処理が続行されました！そしてファイルが機密分類されているので気をつけろと警告が出ていますね。これも良いな。
許可の挙動
つづいて、許可アクションがマッピンされているであろう customer-list-public.xlsx を処理してみます。
こちらはそのまま処理されました。期待どおりです。
デフォルトの挙動
そして、最後に上記いずれのラベル分類がされていない新規ブックをアップロードしてみます。
エラーになりました。なるほど！！
DLP ポリシーのデフォルト設定がブロックになっているので、処理していいと分類されたファイル以外は全部ブロックされる感じですね。許可したファイルのみしかアップロードさせない環境が完成した。めちゃ良いですねこれは。
なお、DLP ポリシーのデフォルトアクションを変えると、このあたりの挙動ももちろん変更できます。
次のようにデフォルトアクションを許可にしてみましょう。
この場合は普通に処理ができましたね。
ラベリングされていないファイルをどう処理させたいかの組織ルールに従って調整が出来そうです。
さいごに
本日は Amazon Quick に追加された Microsoft Purview 連携の DLP を設定して、ブロック・警告・許可の違いを確認してみました。
Microsoft Purview 導入という敷居はありますが、ガバナンスとしてこのあたりをやりたかった組織は多そうです。
すでに Microsoft 365 で Purview の秘密度ラベルを運用している組織なら、そのラベルをそのまま Quick に持ち込めるので、これはぜひ使ってみたいですね。
他の DLP プロバイダーもそのうち追加されるだろうか？気になりますね。
