Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / Microsoft 365 Copilotはデータを漏らしている？Graph権限・DLP・Purviewで守る方法（AI吹き替え）

Transcript

Microsoft 365 Copilotはデータを漏らしている？Graph権限・DLP・Purviewで守る方法（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
マイクロソフト365、コパイロット、AI、Azure、そして働き方の未来を切り開く人々に捧げる10日間、準備はいいですか?
0:07
この1月、M365コンがさらに規模を拡大して帰ってきます。
0:12
世界中のMVPや業界エキスパートによるライブセッション、実践的なデモ、専門知識の共有にご期待ください。
0:18
ありきたりなスライドや空虚な流行語は一切ありません。
0:22
コパイロットスタジオ、AIエージェント、ファブリック、セキュリティ、ガバナンス、自動化といった現実の課題に切り込みます。
0:29
ITプロフェッショナル、開発者、ビジネスリーダー、どなたにも最適なセッションをご用意しています。
0:35
10日間という期間で複数の技術を探求し、グローバルなコミュニティとつながることができます。
0:40
ライブで視聴し、実践的な知見を組織に持ち帰りましょう。
0:45
2027年1月、10日間、一つのマイクロソフトコミュニティ、登録受付を開始しました。
0:51
m365コン.NETにアクセスして、今すぐ参加枠を確保してください。
0:55
繰り返しになりますが、m365コン.NETです。
0:59
m365コン.NETから今すぐ登録を、1月のライブでお会いしましょう。
1:04
コパイロットが自分の権限内にある情報しか表示しないと思っているなら、考え直すべきです。
1:09
グラフ権限を一つ間違えるだけで、コンプライアンスチームが承認していないデータが突然AIに露出してしまいます。
1:14
怖いのは、それが起きていることに一生気づかないかもしれないという点です。
1:17
この動画では、管理されていないコパイロットアクセスの真のリスクを解説し、機密ファイルや財務データ、顧客情報がどのように漏えいし得るのかを見ていきます。
1:25
その後、必要なアクセス権を維持しつつ、生産性を損なうことなく、グラフ権限、DLPポリシー、パービューで保護する方法を解説します。
1:34
コパイロットが過剰な情報を持つと、若手スタッフが先市販機のプロジェクトレビューのメモを求めた際に、自分たちの会議のまとめではなく、非公開の取締役会の議事録や戦略的決定、予算削減の詳細、本来見るべきではなかった人物名までが表示されてしまうのです。
1:51
侵害アラートもDLP警告もならず、AIが本来触れるべきではないドキュメントを静かに提供してしまうのです。
1:57
なぜなら、コパイロットはユーザーのメールボックスやワンドライブの境界で自動的に停止するわけではないからです。
2:03
その到達範囲は、マイクロソフトグラフを通じて付与された権限によって決定されます。
2:07
グラフは単なるデータベースではなく、マイクロソフト365のほぼ全てのコンテンツ、シェアポイント、チームズメッセージ予定表、ワンノート、テナントに紐付くCRMデータなどへのアクセス拠点です。
2:19
適切なドアさえ開いていれば、全てはグラフを経由して流れ出します。
2:23
これこそ、多くの管理者が軽視しているポイントです。
2:25
自分自身でサインインしているのだから、コパイロットも自分が見えるものしか見ないはずだという一般的な思い込みがあります。
2:29
一見もっともらしく聞こえます。
2:31
問題は、コパイロット自体が独自のアプリケーション権限セットで動作することが多いという点です。
2:36
もしその権限がサインインしているユーザーの権利よりも広範囲であれば、キーボードの前に座る人間が到達できる範囲を遥かに超えるアクセス権を持つAIアシスタントが誕生することになります。
2:45
そして一部の導入環境では、それらの昇格された権限が理由を問われることもなく付与されています。
2:50
市販機予測に取り組んでいる財務アナリストを想像してみてください。
2:54
彼らはコパイロットに、上位20社のアカウントの現在のパイプラインデータを尋ねます。
2:58
通常の役割において彼らが見るべきなのは一部のクライアントの数字だけのはずです。
3:02
しかし、コパイロットのアプリ登録でグラフがどのようにスコープ設定されているかによっては、
3:07
AIがそのアナリストが直接アクセスしたことのない共有チームサイトから、営業パイプラインの全レポートを引き出してしまいます。
3:13
エンドユーザーの視点からは、何も疑わしい点はありません。
3:16
しかし、セキュリティとコンプライアンスの観点から見れば、それは機密情報の露呈です。
3:20
グラフAPIの権限は、実質的に組織のデータへの正面玄関となります。
3:24
マイクロソフトはこれらを、サインインしたユーザーに代わって動作する、
3:28
移任された権限と、アプリが独立して動作することを許可する、アプリケーション権限に分けています。
3:33
コパイロットのシナリオではコンテンツ取得のために移任された権限が必要なことが多いですが、
3:38
ユーザーが参加していなかったチーム会議の要約など、
3:40
特定の機能では管理者がアプリケーションレベルの権限を承認するよう求められる場合があります。
3:45
そして、そこに危険が忍び寄ります。
3:47
アプリケーション権限は、意図的にスコープを制限しない限り、個々のユーザーの制限を無視します。
3:52
これらの承認は導入の初期段階で行われることが多く、開発テナントでコパイロットをテストしているIT管理者がセットアップを完了させるためだけに権限プロンプトで、
4:01
同意をクリックし、その構成を影響を検討せずに本番環境で複製してしまう可能性があります。
4:06
一度設定されると、それらの広範な権限は誰かが積極的に監査しない限り残存します。
4:11
時間の経過とともに新しいデータソースがM365に接続されると、意識的な決定なしにコパイロットの到達範囲は拡大していきます。
4:18
これが静かな権限の肥大化です。騒ぎもユーザーからの苦情もなく、ただAIの範囲が徐々に広がっていくだけなのです。
4:26
課題は、ほとんどのセキュリティチームが、どのコパイロットの機能がどのレベルのグラフアクセスを必要とするかを熟知していないことです。
4:32
彼らはシェアポイントの全てのファイルの読み取りを見て、ユーザーコンテキストによって制限されていると思い込むかもしれませんが、
4:38
その権限がアプリケーションレベルでテナント全体に及ぶものであるとは認識していません。
4:41
特定のAIシナリオを最小限必要な権限にマッピングしなければ、結局は初期設定で承認された権限がデフォルトとなってしまいます。
4:49
そして、それらの権利が広ければ広いほど、期待される動作と実際の動作との間のギャップは大きくなります。
4:56
また、コパイロットの出力にはユーザーが確認できる組み込みの権限追跡機能がないことも覚えておくべきです。
5:03
もしAIが通常ならユーザーが閲覧をブロックされる場所からコンテンツを取得した場合でも、これはあなたの権限外です、という警告バナーは表示されません。
5:12
その透明性の欠如により、リスクを伴う露呈が日常のワークフローに紛れ込みやすくなります。
5:17
ここでの重要な教訓は、AI導入におけるグラフ権限は、オンボーディングプロセスにおける単なるチェックボックスの一つではないということです。
5:24
それらは、コパイロットがネットワーク上で行う全ての対話を形作る設計上の選択なのです。
5:28
ファイアウォール規則やVPNのアクセス範囲と同様に、意図的かつ定期的に見直し、再検証を行う必要があります。
5:35
デフォルト設定はすぐに利用を開始できますが、人間よりも遥かに広い範囲をAIが扱うことを容認していることになります。
5:42
範囲が容易に拡大してしまうことが分かった今、本格的なインシデントに発展する前にその隙間をどう見つけるかが次の課題です。
5:50
流出する前に漏洩を見つける。
5:51
もしコパイロットが本来表示すべきでないデータを表示していたら、あなたはそれに気づけるでしょうか?
5:55
ほとんどの組織にとって正直な答えは、いいえ、です。
5:58
情報が公開サイトに投稿されたり、メーリングリストに一斉送信されたりするわけではありません。
6:04
漏洩は、ドキュメントの草案や要約、AIが生成した回答の中にひっそりと現れるかもしれません。
6:10
そして、誰かが異変に気づかない限り、警告を発することなく見過ごされてしまいます。
6:14
可視性の問題は、多くの監視システムの構築方法に起因しています。
6:18
それらは従来の活動やファイルのダウンロード、異常なログイン場所、大量のメール送信向けに調整されており、AIによる情報収集やコンパイルの仕組みには対応していません。
6:28
コパイロットは、一般的な意味でファイルを開くわけではありません。
6:32
マイクロソフトグラフを通じてデータソースをクエリし、結果をまとめて自然言語テキストとして提示します。
6:37
つまり、AIがバックグラウンドで機密性の高い場所からデータを取得していても、標準のファイルアクセスレポートには問題がないように見える可能性があるのです。
6:45
ある企業では、従業員が自分の部門の管轄外であるクライアント名を何気なく口にしたことで、初めて問題に気づいたケースもありました。
6:53
マネージャーがどうしてそれを知っているのかと尋ねると、その答えは、コパイロットが草案に含めていたから、でした。
6:58
インシデントチケットも自動警告もありませんでした。
7:01
ただの何気ない発言がきっかけで、IT部門が調査に乗り出したのです。
7:04
全容を把握した頃には、AIが生成した同じ回答がすでに複数のチーム間で共有されてしまっていました。
7:10
マイクロソフト365にはこうしたシナリオを調査するためのツールがありますが、どこを見るべきかを知っておく必要があります。
7:16
パービューの監査機能を使えば、コパイロットによるデータアクセスを詳細に記録できます。
7:20
ただ、そこにAIという大きな警告バッジが表示されるわけではありません。
7:24
監査ログ検索に入ったら、検索クエリの実行やファイルアクセスなど、コパイロットが使用する特定の操作でフィルタリングし、コパイロットのデプロイに関連付けられたアプリケーションIDで絞り込むことができます。
7:35
これには事前の準備が少し必要です。
7:37
エントラIDでアプリ登録の詳細を確認し、通信を識別できるようにしておく必要があります。
7:42
そこから先は、パターンを見つけることが重要です。
7:44
通常はデータ利用が少ないアカウントから大量のクエリが発生している場合、
7:48
例えばインターンのアカウントが1時間に10回もの複雑な検索を行っているなら、確認する価値があります。
7:53
機密とラベル付けされたコンテンツが、通常は触れるはずのない部門で急増している場合も同様です。
7:58
パービューはラベル付けされたアクティビティをフラグ立てできるため、
8:01
コパイロットのクエリがラベル付きドキュメントを参照した場合、
8:05
AIが全文を出力しなくてもログで確認できます。
8:07
役割ベースのアクセス権レビューも、点と点をつなぐ有効な手段です。
8:11
誰が実際にコパイロットを使用しているかをマッピングし、やり取りするデータの種類と照らし合わせることで、不整合の可能性を早期に発見できます。
8:19
財務部門がレポート作成にコパイロットを多用するのは自然ですが、
8:22
なぜマーケティング部門の複数のアカウントが、AIクエリを通じて給与計算スプレッドシートにアクセスしているのでしょうか。
8:27
こうしたレビューを行えば、監査小石の単一イベントを超えた全体像を把握できます。
8:32
ただし、一般的な監視ダッシュボードではあまり役に立たないという難点があります。
8:36
これらはあらゆるM365アクティビティを広範なカテゴリに集約するため、AI特有の挙動が通常の操作に紛れてしまう可能性があるからです。
8:45
コパイロットのアプリIDや使用パターンに焦点を当てたカスタムフィルターやレポートを作成しなければ、砂浜から特定の砂粒を探すような作業になってしまいます。
8:54
必要なのは単なる可視化ではなく、ターゲットを絞った可視化です。
8:58
これは監視文化を築くためではなく、AIが実際に何を取り込んでいるかを確実に把握するためのものです。
9:03
適切なログ記録手法は3つの重要な疑問に答えてくれます。
9:06
コパイロットは何を取得したのか?誰がそれを実行したのか?そして、そのアクションは既存のセキュリティ及びコンプライアンスポリシーに準拠しているか?
9:13
これらの答えがあれば、権限の調整、DLPルールの整地化、役割の割り当ての厳格化など、課題に対して的確に対処できます。
9:21
明確な答えがなければ推測するしかなく、推測はセキュリティ戦略とは言えません。
9:26
そのため、誰かの何気ない一言を待つよりも、時間を投資して監視体制を構築し、コパイロットの足跡を可視化、追跡できるようにする価値があります。
9:36
そうすれば、データ過剰露出の兆候は不意の出来事ではなく管理可能なイベントとなります。
9:41
どこで情報漏洩が起きているかを知ることは、ほんの第一歩に過ぎません。
9:45
真のゴールは再発防止であり、そこで適切なガードレールが重要になります。
9:50
実際に機能するガードレールです。
9:52
DLPは、クレジットカード番号が含まれるメールを検知するためだけのツールではありません。
9:56
コパイロットの文脈においてDLPは、AIが生成した回答に機密データが含まれ、それがチームチャットに貼り付けられたり、テナント外へエクスポートされたりするのを防ぐトリップワイヤーとなります。
10:08
Microsoft 365の基盤ツールとしては同じですが、AIシナリオに合わせて設定するには、これまでとは異なる考え方が必要です。
10:17
多くの組織のDLPポリシーが、電子メールの添付ファイル、USBドライブへのファイルダウンロード、非承認アプリへのデータコピーといった旧来のトリガーを前提としていることが問題です。
10:28
コパイロットはファイルを送信するわけではないため、デフォルトではこれらのルールはトリガーされません。
10:33
コパイロットはその場でコンテンツを生成しているからです。
10:36
コパイロットに制限付きとマークされた顧客リストをすべて尋ね、それがラベル付けされたドキュメントから抽出された場合、従来のDLP条件を一度もトリガーすることなく出力が流出する可能性があります。
10:47
そのため、AIのプロンプトと応答をDLPのスコープに明示的に組み込む必要があります。
10:53
実践的な例として、特定の契約書をセキュアな環境外へ持ち出すことをポリシーで禁止しているとします。
10:59
ユーザーがコパイロットに重要な情報を抽出してパワーポイントに貼り付けるよう指示するかもしれません。
11:04
DLPルールでAIが生成したコンテンツを監視していなければ、その機密情報は保護されていないファイルの中に存在することになります。
11:12
DLP検査の対象をコパイロットの出力まで拡張することで、そのパワーポイントが管理外の場所に保存されたり、チームで外部ゲストと共有されたりするのをブロックできます。
11:22
Microsoft 365での設定は複雑ではありませんが、慎重なプロセスが必要です。
11:27
まず、Microsoft Purviewコンプライアンスポータルでデータ損失防止のセクションに移動し、新しいポリシーを作成します。
11:33
適用する場所を選択する際、Exchange、SharePoint、OneDrive、そして何よりもチームを含めてください。
11:39
コパイロットはこれらのいずれにもデータを表示できるからです。
11:42
次に、条件を定義します。
11:45
金融口座番号のような組み込みの機密情報の種類や、社内のプロジェクトコードを検出するカスタムの種類を対象にできます。
11:53
また、秘密ドラベルを一貫して使用している場合は、保存または共有されるファイルの最終出力にラベル付けされたコンテンツが含まれたときにトリガーされるよう条件を設定することも可能です。
12:03
最後に、アクションを構成します。
12:05
共有のブロック、ユーザーへのポリシーヒントの表示、あるいは続行するための正当な理由の入力を要求します。
12:10
秘密ドラベルそのものが、この仕組みを実現するための鍵となります。
12:14
AIのコンテキストにおいて、ラベルは他のM365サービスと同様にコパイロットが読み取れるメタデータです。
12:21
機密性の高いドキュメントにアクセスや使用を制限するラベルが付いている場合、ラベルの保護設定が関連アプリ全体で一貫して適用されていれば、コパイロットは回答生成時にその制限を尊重します。
12:33
AIが許可された範囲外のラベルが付いたコンテンツを使用しようとすると、そのラベルにリンクされたDLPポリシーによってアクションを阻止するか、レビュー対象としてフラグを立てることができます。
12:43
その連携がなければ、コンプライアンスの観点からラベルは単なる飾りになってしまいます。
12:48
私がよく目にする設定ミスの一つは、DLPポリシーがAIシナリオを全く認識していない状態のままにすることです。
12:54
ルールは存在しても、管理者がコパイロットの出力を別個のチャンネルとみなしていないために、リンクが設定されていないのです。
13:00
これにより、メール内であればブロックされるはずの機密情報が、生成された回答の中では検査されず、視覚が生じてしまいます。
13:08
これを修正するには、AIを活用したワークフローもDLPの監視場所の一つと考え、他のすべてと同様に監視しなければなりません。
13:16
DLPと秘密ドラベルが適切に構成され連携していれば、コパイロットはコンプライアンスの悩みの種になることなく、有用なツールであり続けられます。
13:25
レポートのドラフト作成やドキュメントの要約、データセットの精査を任せつつ、メールやチームメッセージと同様の境界線を静かに矯正できます。
13:34
ユーザーはAI支援の恩恵を受けられ、ガードレールによって機密情報の流出が防がれます。
13:39
この利点は、単に意図しない情報共有を防ぐことだけではありません。
13:43
明確なルールの下でテクノロジーを運用できるようにすることが重要です。
13:47
そうすれば、チームの不満を招き、導入を阻害するような一律の制限に頼る必要もなくなります。
13:52
コントロールを調整することで、マーケティングはコパイロットでブレインストーミングを行い、財務は分析を実行し、人事はオンボーディングガイドを生成するなど、各部門が許可された範囲内で活動できます。
14:03
しかし、出力の制御はパズルの断片に過ぎません。
14:06
リスクを完全に低減するには、そもそも誰にどのAI機能へのアクセス権を与えるかを決定する必要があります。
14:12
一律のアクセス権で全てに対応することはできません。
14:15
マーケティングのインターンとCFOが、本当に同じコパイロットの権限を持つべきでしょうか。
14:20
口に出すと馬鹿げた話に聞こえますが、多くのテナントではまさにそのように設定されています。
14:26
役割ごとの構成を設定するよりも手軽で迅速なため、全員に同じ権限でコパイロットが有効化されているのです。
14:32
その欠点は、AIのアクセス権が各役割のニーズではなく、最もオープンな環境に合わせられてしまうことです。
14:38
そこで登場するのが、役割ベースのコパイロットアクセスグループです。
14:42
全てのユーザーを同等に扱うのではなく、特定の役割が実際に必要とする情報やワークフローにAI機能を合わせます。
14:49
マーケティングはキャンペーン資産やブランドガイドラインへのアクセスが必要でも、生の財務モデルは必要ないかもしれません。
14:56
財務はそれらのモデルを必要としますが、初期段階の製品ロードマップは不要です。
15:01
目的は、コパイロットの利便性を下げることではありません。
15:03
その範囲を、各人の業務に関連するものに限定することです。
15:07
全社一律で有効化するリスクは、多くのチームが予想しているよりもはるかに大きいものです。
15:11
コパイロットは、マイクロソフト365関係台に既に存在するデータを利用して動作します。
15:16
全てのスタッフが平等なAIアクセス権を持つと、テクノロジーは意図的に維持してきた情報のサイロを壊してしまいます。
15:22
その結果、人事アシスタントが収益の内訳に触れてしまったり、運用責任者がコパイロットに翌年の製品リリース計画を尋ねて、まだ確定していない設計の詳細を得てしまったりする事態になりかねません。
15:34
その時点では情報漏洩とは感じられませんが、リスクは確実に存在します。
15:38
適切なアクセスモデルを構築するには、業務内容とデータニーズのマッピングから始める必要があります。
15:43
使用するアプリケーションだけでなく、日常的に触れるデータの深度や機密性も考慮すべきです。
15:48
例えば、営業チームのコパイロットへのリクエストの70%は顧客のアカウント履歴に関連しており、機密性の高い契約ファイルへのアクセスは5%未満であるといったことが判明するかもしれません。
15:57
つまり、AIの利用範囲の大部分を特定のシェアポイントライブラリ内に限定し、残りをロックダウンすれば安全だということです。
16:03
各部門で同じ作業を行えばパターンが見えてきます。
16:06
各グループに必要な権限を把握できれば、マイクロソフトエントラーID、旧Azure ADが強力な管理ツールとなります。
16:14
役割に応じたセキュリティグループを作成し、グループ単位でコパイロットの権限を割り当てます。
16:20
例えば、財務グループには特定のグラフAPIスコープのみを有効にし、マーケティンググループには別のセットを割り当てることが可能です。
16:29
機密サイトやチームチャンネル、特定のワンドライブフォルダーへのアクセス権も同じモデルで管理できます。
16:34
このアプローチの強みは、これまで説明した制御機能と組み合わせることで発揮されます。
16:39
グラフの権限は、コパイロットが技術的にアクセスできる範囲を決定します。
16:44
DLPポリシーは、AIの出力に機密情報が含まれていないかを監視します。
16:50
役割ベースのグループは、権限の過度な拡大を防ぎ、入力ソースを制限することで、不要なDLP検知を回避する役割も果たします。
17:00
しかし、どんなシステムもやりすぎは禁物です。
17:04
あらゆるシナリオに細分化されたグループを作りたくなるものです。
17:08
レポート権限付きの財務アナリスト用コパイロットや、チームアクセスなしのマーケティングインターン用など、数十ものバリエーションができてしまいます。
17:15
紙の上では細かく見えても、実際の運用環境ではメンテナンスが非常に困難になります。
17:20
ユーザーの役割は変わり、プロジェクトは変化し、契約社員も出入りします。
17:25
グループモデルが複雑すぎると、IT部門はセキュリティ向上よりもアクセス権の修正に時間を取られることになります。
17:31
真の目的はバランスです。
17:33
明確で整理された少数の役割グループであれば、管理を停滞させることなく、ほとんどのユースケースに対応できます。
17:39
CFOグループには広範な分析能力が必要ですが、出力共有には厳格な制御が求められます。
17:44
インターングループにはデータ範囲を限定しつつも、実務に貢献できるだけの能力を与えます。
17:50
部門リーダーには中間的な権限を与え、特別なプロジェクトで例外が必要な場合はIT部門が調整できるようにします。
17:57
すべてをロックダウンしてユーザーを不便にさせる必要はありません。
18:00
各AI利用環境を適切かつ安全に保ち、ポリシーに従わせることが重要です。
18:05
正しく設定できれば、そのメリットはすぐに現れます。
18:08
ユーザーはコパイロットが提示するデータに驚かなくなります。
18:11
それは常に彼らの責任範囲内のものだからです。
18:14
誤って情報が公開されることがなくなるため、コンプライアンスチームが調査すべきインシデントも減ります。
18:19
IT部門は、全社展開によって築き上げたデータ境界が侵害される心配をすることなく、
18:26
コパイロットの新機能を安心して導入できます。
18:29
アクセス制御とガードレールを連携させることで、リスクプロファイルを大幅に低減できるのです。
18:34
しかし、どれほど優れたモデルであっても、それが機能していることを自分自身、
18:38
そして監査を求めてくる相手に対して証明できなければ意味がありません。
18:41
速度を落とさずにコンプライアンスを証明すること。
18:44
コンプライアンスは単なる見せかけのセキュリティではなく、監査人を納得させるための証拠です。
18:48
ポリシーやガードレールは重要ですが、AIが支援したデータに何が起きたのかを正確に示せなければ、
18:54
証明ではなく主張に終始してしまいます。
18:56
監査に対応できるコパイロット環境とは、
18:58
ユーザーのクエリからAIによるデータ取得までの全てのやり取りが説明可能であり、
19:03
検証可能な証跡に裏打ちされている状態を指します。
19:06
難しいのは、多くの企業が社内レビューを通過したことで万全だと考えてしまう点です。
19:11
そうしたレビューでは管理策の存在やいくつかのサンプルシナリオを確認するだけに留まり、
19:17
外部監査人が求める流度を常に満たしているとは限りません。
19:21
外部の審査員が、全市販機にコパイロットがアクセスした全ての機密コンテンツのログと、
19:27
誰がなぜそれを要求したかの提示を求めたとき、驚くほど頻繁に不備が見つかります。
19:32
ログが不完全であるか、あるいはAI関連のイベントが最初からそのようにタグ付けされておらず、
19:37
完全に欠落しているかのいずれかです。
19:39
ここでマイクロソフトパービューが大きな違いを生み出します。
19:42
そのコンプライアンス機能は、単にラベルやDLPポリシーを適用するだけではありません。
19:47
必要なホレンジック証拠を収集することもできます。
19:50
コパイロットのコンテキストにおいて、パービューは関連する全てのデータアクセス要求、
19:54
その背後にあるID、およびソースの場所を記録可能です。
19:56
また、AIの自己報告に頼ることなく、機密ファイルがドラフト、
20:01
ようやくエクスポートで参照されたといったデータ移動のパターンと、
20:04
それらのイベントを関連づけることもできます。
20:06
パービューのコンプライアンススコアは、単なる見栄えの良い指標ではありません。
20:10
これは、マイクロソフトが推奨する管理策に対し、
20:12
AI関連のリスクを直接制限するものを含め、
20:15
お客様の環境がどの程度適合しているかを示すスナップショットです。
20:17
グラフ権限の整理、より厳格なDLP設定、
20:21
適切に管理されたロールベースのグループなどが、
20:23
すべてそのスコアに反映されます。
20:25
スコアは変更を加えるたびに更新されるため、
20:28
AIガバナンスの改善によってコンプライアンスの状況が
20:30
どのように向上しているかをほぼリアルタイムで確認できます。
20:33
特定の顧客データがコパイロットによって生成されたレポートになぜ含まれていたのかを、
20:38
規制当局の調査で説明しなければならない場面を想像してください。
20:41
構造化されたログがなければ、その説明は推測の域を出ません。
20:45
パービューを適切に構成すれば、アクセス要求を監査ログで示し、
20:49
それを許可したロールと権限を特定し、
20:51
出力が承認されたチャンネル内に留まっていたことを証明できます。
20:54
記録のないイベントを慌てて説明するよりも、
20:56
はるかに楽な話し合いになります。
20:58
重要なのは、コンプライアンス報告を監査前の特別なプロジェクトとしてではなく、
21:02
通常のITガバナンスサイクルの一部に組み込むことです。
21:05
自動化されたレポーティングは、この点で大きく役立ちます。
21:08
パービューは、情報保護ポリシーの合致、DLPインシデント、
21:11
および秘密ドラベルの使用状況に関する定期的なレポートを生成できます。
21:15
これらのレポートが毎月ガバナンスチームのワークスペースに届けられるようスケジュール設定すれば、
21:19
レビューが容易なAIアクティビティの基準線が構築されます。
21:23
どんな異常も、履歴パターンと照らし合わせればすぐに浮き彫りになります。
21:26
こうした時間短縮機能の積み重ねが重要です。
21:28
例えば、パービューには、ラベル付けされたコンテンツに関わる全インシデントを場所やアクティビティの種類でグループ化したレポートが標準で備わっています。
21:36
コパイロットのセッションで機密ドキュメントが出力に取り込まれ、DLPが機能した場合、
21:41
そのインシデントはカスタムクエリをゼロから作成しなくてもレポートに表示されます。
21:45
そこから詳細をドリルダウンして確認できますが、収集や分類といった面倒な作業はすでに完了しています。
21:52
もう一つの効率化として、パービューの監査とマイクロソフト365の役割ベースのアクセスデータとの統合があります。
21:59
パービューはエントラーIDグループを認識できるため、役割の種類ごとにアクセスログを抽出できます。
22:05
つまり、過去90日間にマーケティング担当者がコパイロット経由で財務ラベル付きデータにアクセスしたすべての事例を表示する、
22:11
といった具体的な問いにも迅速に答えられます。
22:14
役割とデータ分類の両方で絞り込めるこの機能こそ、外部監査人が求めているものです。
22:21
考えてみれば、このレベルのコンプライアンスは負担ではありません。
22:24
それは、ガバナンス設計が実際に機能していることを確認するためのガードレールなのです。
22:28
また、手作業でデータをかき集める必要がないため、監査に伴うストレスも解消されます。
22:31
ご視聴ありがとうございました。