Graph Explorer を使いこなす:ユーザーのフットプリントをエンドツーエンドで追跡する
By Mirko Peters ·
ポッドキャストのコンパニオン・ブログへ、ようこそお帰りなさい!今回の投稿では、私たちが皆よく知っていて、ときには苦労させられる、分断された管理用ユーザーインターフェイスの枠をはるかに超えていきます…
Automatically translated with AI from the original post. Read the English original
ポッドキャスト連動ブログへようこそ!今回の投稿では、私たちが普段使っている断片的な管理用ユーザーインターフェイスの枠を大きく超えていきます。Microsoft 365 全体で特定のユーザーが何にアクセスし、何を共有し、何を操作したのかを包括的な監査証跡としてまとめようとしたことがあるなら、ネイティブの管理センターがいかにばらばらに感じられるかご存じでしょう。だからこそ、Microsoft Graph を深く掘り下げます。Graph API を使えば、個々のユーザーからグループ、SharePoint サイト、ファイル、外部リンク、さらにはアクティブな閲覧者へもスムーズに移動できます。このガイドと直接対応している音声の議論にも一緒に取り組みたい場合は、関連エピソード Map Microsoft 365 Users, Groups, Files, and Shares with Graph もぜひご覧ください。
なぜ M365 は孤立していないのか
管理者やセキュリティチームの間でよくある誤解の一つは、個々の Microsoft 365 サービスがそれぞれ安全で独立したサイロとして動作しているというものです。実際には、Teams のチャット、SharePoint のドキュメントライブラリ、OneDrive のフォルダーは、基盤となるグループメンバーシップやアクセス許可の継承を通じて、絶えず相互に影響し合っています。
- Teams のチャット、SharePoint のライブラリ、OneDrive のフォルダーは、グループメンバーシップを通じて相互に連携しています。
- 「1人を1つのグループに追加する」という単純な操作だけで、標準のビューには明確な監査の連続性を残さないまま、多数の基盤サイト、チャネル、外部共有へのアクセスが静かに開放されてしまうことがあります。
- コンプライアンス上のリスクは、プライベートチャットに投稿されたゲストリンク、複数のライブラリに複製されたファイル、プロジェクト終了後も放置された孤立した共有など、こうした見えにくい経路から生じます。
Graph Explorer によるフットプリントの把握(ユーザーからファイルへの接点)
テナント全体でアクセスがどのように広がっているかを真に理解するには、繰り返し使える クエリのパターンが必要です。Graph Explorer で一連の API 呼び出しを計画的に実行すれば、ユーザーの接点の全体像を次のようにマッピングできます。
- 対象ユーザーを特定します:
GET /v1.0/users/{userPrincipalName}?$select=id,displayName,userPrincipalName - 直接および間接のメンバーシップを列挙します:
GET /v1.0/users/{id}/memberOf?$select=id,displayName - それらのグループが紐づくリソースに移動します。Microsoft 365 グループと Teams の場合は、基盤となる SharePoint サイトを対象にします:
GET /v1.0/groups/{groupId}/drive/root/children?$select=id,name,lastModifiedDateTime,webUrl
または、サイトのドライブとライブラリを直接列挙します:
GET /v1.0/sites/{siteId}/drives - アイテムのアクセス許可と共有リンクを取得します:
GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$select=id,grantedToV2,link,roles,shareId - 利用可能な場合は、監査ログとサインインログを使って、誰がいつ何にアクセスしたかを追跡します:
GET /v1.0/auditLogs/signIns または /security/alerts を、ファイル、サイト、または共有のコンテキストと組み合わせます。 - Teams の投稿とチャネルのメッセージに戻って検証を完了します:
GET /v1.0/teams/{teamId}/channels/{channelId}/messages?$search="filename"(beta エンドポイントと適切なアクセス許可が必要です)。
実際に使えるノイズ削減フィルター
Microsoft Graph から生データを取得していると、すぐに消火ホースから水を飲もうとしているような気分になるかもしれません。膨大なデータセットを実用的な情報に変えるには、的確なクエリパラメーターを活用する必要があります。
- スコープフィルターを適用して、過去 7 日以内に作成された外部共有を絞り込みます:
GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$filter=link/scope eq 'anonymous' or link/scope eq 'organization'&$select=… - ファイル名の拡張子を追加して、リスクの高いファイルの種類を絞り込みます。追加する内容:
$filter=endsWith(resourceReference/name,'.xlsm') or endsWith(resourceReference/name,'.pst') を追記します - Teams のチャネルで、機密用語が通常の業務時間外に言及されたものを追跡します:
GET /v1.0/teams/{teamId}/channels/{channelId}/messages?$search="confidential"。その後、結果を createdDateTime で通常の業務時間外のものに絞り込みます。 - 常に $select を追加して、ID、名前、Web URL、最終更新日時、最小限のアクセス許可フィールドだけを返すようにし、ペイロードを軽量かつ効率的に保ちます。
- 迅速なトリアージのために、簡単なスポットチェックでは $top=50 を使って結果数を制限します。ただし、データを恒久的なストレージバックエンドにエクスポートする際には、この制限を外すことを忘れないでください。
エンタープライズ規模で必須の対策(ページングとスロットリング)
単一のテストユーザーからの検証を、数十万件のオブジェクトを抱えるエンタープライズ テナントへ拡張するとき、パフォーマンスと信頼性が最も重要になります。
- すべてのページの結果について @odata.nextLink プロパティを明示的にたどらない限り、データの取得は完了していません。
- HTTP 429 のレート制限応答には、指数バックオフの処理を実装して対応してください。また、スクリプトが中断箇所から安全に再開できるようにしておきます。
- クエリはまとめて効率よく実行してください。細かい呼び出しを大量に送るより、少数で構造の整ったリクエストを優先し、グループとサイトの対応関係は積極的にキャッシュしてください。
- 大規模なテナント全体のクロールは、SharePoint サイト ID や日付範囲で分割して、タイムアウトを回避してください。負荷の高い処理は業務時間外にスケジュールしましょう。
よくある落とし穴と迅速な対処
自動化された Graph クエリのパイプラインを構築する際は、経験豊富な管理者でも問題に直面します。次の代表的な落とし穴と、すぐに取れる対処法を押さえておきましょう。
- 落とし穴: 基になるスキーマが時間の経過とともに変わると、CSV エクスポートにずれが生じて動作しなくなります。
対処: バージョン管理された変換処理を用い、"unknown" フィールドを適切に扱える堅牢な仕組みを備えて、Graph API を直接利用してください。 - 落とし穴: GUID とユーザー プリンシパル名 (UPN) のように識別子が混在すると、データベースの結合が機能しなくなります。
対処: データを、ユーザー、グループ、サイト、ドライブ、アイテム、アクセス許可を含む一貫したセマンティック モデルに正規化してください。 - 落とし穴: "1ページ目への偏り" により監視が機能せず、深いページに埋もれた重大なセキュリティ インシデントを見逃してしまいます。
対処: 処理した総ページ数を必ずログに記録し、想定されるレコード数が予期せず減少した場合にはアラートを発生させてください。 - 落とし穴: 無関係なファイルが大量に届き、管理しきれなくなります。
対処: リンクの範囲、作成日時や更新日時の期間、対象を絞った機密用語リストで、明示的にフィルターをかけてください。 - 落とし穴: Teams の共有が、基になるファイルとひも付かなくなります。
対処: チャネル メッセージの Web URL をドライブ アイテムに直接関連付け、両方の一意の識別子を保存してください。
これにより可能になるエグゼクティブ向けの KPI
Graph API の生の出力を構造化された指標に変換すると、経営層が強く必要としている可視性が得られます。把握できる主な重要業績評価指標 (KPI) は次のとおりです。
- 外部への公開スピード: サイトまたはチームごとに分類した、週ごとの新しいゲスト リンクの生成数を測定します。
- 機密ファイルへのアクセス率: 秘密度ラベルが付いたコンテンツについて、一意の閲覧者を追跡し、社内ユーザーと外部ゲストを区別します。
- グループ変更による波及リスク: グループのメンバーシップが変更されてから 24 時間以内に、突然アクセス可能になったファイルを特定します。
- 非公式な拡散: 1 スプリント内に複数のチームやサイトへ広がった機密ファイルを追跡します。
- クリーンアップの効果: 取り消された共有リンクの数を数え、修復までの全体的な所要時間を測定します。
すぐに使えるクエリのレシピ(コピーして貼り付けるだけ)
Graph Explorer で最初のエンドツーエンドの検証をすぐに始めたい場合は、次のコピーして貼り付けるだけの手順に従ってください。
- ユーザーの基本情報とグループを取得:
/users/{upn}?$select=id,displayName
/users/{id}/memberOf?$select=id,displayName - 見つかった Microsoft 365 グループごとに、ドライブの子項目を取得:
/groups/{groupId}/drive/root/children?$select=id,name,webUrl,lastModifiedDateTime&$top=200
必ず @odata.nextLink をたどってください - ファイル アイテムごとに、アクセス許可を確認:
/drives/{driveId}/items/{itemId}/permissions?$select=id,roles,grantedToV2,link
link/scope が ('anonymous','organization') に含まれるように絞り込んでください - 整理したデータを、テナント時刻、サイト ID、ドライブ ID、アイテム ID、Web URL、所有者、スコープ、有効期限のデータを含めて、データ ウェアハウスにエクスポートします。
- 集計したデータを Power BI で可視化し、組織内での継続的な監視に活用します。
継続的に運用されるダッシュボードにする
Graph Explorer での単発のクエリは調査には非常に有効ですが、継続的なガバナンスには自動化が必要です。堅牢なデータフローを構築し、ユーザー、グループ、サイト、ドライブ、アイテム、アクセス許可、メッセージのテーブルを正規化したうえで、ファイル アイテムを中心としたスター スキーマを作成して、クエリを継続的に運用されるダッシュボードへ発展させてください。更新日時に基づく増分データ更新を設定し、機密ラベルが付いた重要なコンテンツに新しい外部リンクが追加されるたびに通知が発生するリアルタイム アラートも構成しましょう。
30 日間の展開計画
この取り組みを組織全体で実践する準備はできていますか。次の 4 週間の展開フレームワークに従ってください。
- 第 1 週: アプリの登録を完了し、最小限の特権の Graph API アクセス許可を割り当てて、正確な $select と $filter パラメーターを使った基準クエリを確立します。
- 2週目:ページネーション用スクリプトを作成し、IDからUPNへの識別子の正規化を実装して、最初のデータエクスポートを正常に実行します。
- 3週目:Power BI のデータモデルと基本的なKPIを構築します。外部公開の追跡やリップル リスク分析も含めます。
- 4週目:データの更新を自動化し、異常アラートを設定して、セキュリティチームとコンプライアンスチーム向けの標準運用手順を文書化します。
対象となる読者
この手法は、組織内の以下の役割の方に特に役立つように設計されています。
- 標準の管理ダッシュボードでは重大な死角が見過ごされているのではないかと考えている Microsoft 365 管理者および SecOps リーダー。
- 高価なサードパーティ製ソフトウェアを増やすことなく、共有のエンドツーエンドの可視性を必要とするコンプライアンスチーム。
- 安全で管理された外部共有の実践に最終的な責任を負うコラボレーションのオーナー。
現場で役立つヒント
Graph の自動化に取り組む際には、以下の実践的なヒントを手元に置いておいてください。
- 死角をなくすため、調査は必ずユーザーまたはファイルのいずれかを起点とし、そこから両方向に展開してください。
- 「グループに追加」の操作はリスクの高い変更イベントとして扱い、24 時間以内に下流のアクセス許可への影響を確認してください。
- Teams のメッセージやファイル名を検索するための機密用語のリストを常に用意し、定期的に見直してください。
- 処理したページ数とレコード数のボリュームは注意深く記録してください。ログが完全に沈黙している場合、それはパイプラインのジョブが壊れていることを示す重要なサインであることがあります。
まとめ
Microsoft Graph を使ってユーザーの足跡をエンドツーエンドで追跡できるようになると、分断された管理者向けビューと真のエンタープライズ全体の可視性との間のギャップが埋まります。孤立したサイロから関係性に基づくアクセスマッピングへと発想を転換することで、機密データを先回りして保護し、非公式な共有の流通を排除し、経営層が必要とする実用的な KPI を提供できるようになります。このようなシナリオに関する専門家による詳しい解説、実例、深掘りの内容をさらに知りたい方は、Map Microsoft 365 Users, Groups, Files, and Shares with Graph でエピソード全編をお聴きください。
購読
Graph の実践的なレシピをさらに詳しく知りたい方は、m365.show/subscribe で新しいエピソードをご覧ください。