管理コンソールのサイドバーにあるレポートには、セキュリティーの問題、アカウントの使われ方、組織への定着度を確かめる画面が10本並びます。厄介なのは、この10本が2つの異なる条件で守られていることです。監査とレポートを情報システム部門に任せたつもりが、担当者の画面には一部しか出ていない、ということが起こります。更新のタイミングと対象範囲もレポートごとに違うため、数字をそのまま社内報告に転記すると実態とずれます。このページでは10本の内訳と閲覧できる人、数字を読むときの前提、監査ログやインサイトとの使い分けを説明します。個々のレポートの手順は次のページ以降で扱います。
レポート画面に並ぶもの
レポートを開くと、セキュリティリポート、アカウントのアクティビティ、チームインサイトの3つのまとまりにカードが並びます。各カードには表示またはレポートの生成の操作があり、まだ開いていないカードには未表示、開いたことのあるカードには最終閲覧日が出ます。
| まとまり | レポート | 分かること | 扱うページ |
|---|---|---|---|
セキュリティリポート | 違反報告 | 自社ドメインのメールアドレスが外部の情報漏洩に含まれていないか | ドメイン侵害レポート |
セキュリティリポート | ビジネスWatchtowerレポート | 保管庫のアイテムに弱いパスワードなどの問題がいくつあるか | ビジネスWatchtowerレポート |
セキュリティリポート | 開発者シークレットの検出レポート | 端末に平文で置かれたキーやトークンがどれだけあるか | 開発者のシークレットを見つけて是正する |
アカウントのアクティビティ | 使用状況レポート | 人、サービスアカウント、保管庫ごとのアイテムの使われ方 | 利用状況と定着のレポート |
アカウントのアクティビティ | サインイン試行 | 失敗またはブロックされたサインイン | サインイン試行と端末のレポート |
アカウントのアクティビティ | アダプションレポート | 最終サインインとブラウザー拡張機能の状態 | 利用状況と定着のレポート |
チームインサイト | チームレポート | 人数、グループ数、保管庫数と、人ごとの状態 | 利用状況と定着のレポート |
チームインサイト | デバイスレポート | 稼働中の端末数と古いバージョンのアプリ | サインイン試行と端末のレポート |
チームインサイト | 概要レポート | アカウント全体の数の要約 | 利用状況と定着のレポート |
チームインサイト | メール変更レポート | 保留中のメールアドレスの変更 | メールアドレスの変更 |
メール変更レポートは自動プロビジョニングを設定しているアカウントにだけ現れます。SCIM Bridgeを使う構成では出ません。統合を削除すると、以後は開けなくなります。

ビジネスWatchtowerレポートを開いたところ。保管庫ごとに問題の件数が並ぶ(画像は英語表示)インサイトは10本のカードとは別に、同じレポートの画面からタブとして開きます。こちらは数えるための画面ではなく、見つかった問題を是正するための画面です。インサイトの使い方とインサイト通知の設計で扱います。
誰がどのレポートを見られるか
セキュリティリポートの3本を開けるのは所有者とセキュリティグループのメンバーだけです。管理者グループに入れても出てきません。この3本だけを渡す方法もありません。インサイトとセキュリティレポートを表示というパーミッションは組み込みグループにしか付いておらず、カスタムグループに割り当てられる10件の一覧に存在しないためです。
残りの7本は所有者と管理者、または管理サイドバーを表示のパーミッションを持つグループのメンバーが開けます。こちらはカスタムグループに割り当てられるので、レポートの閲覧だけを渡す設計ができます。

違反報告。所有者とセキュリティグループのメンバーだけが開ける【注意】 委譲したつもりで開けていない、という事故が起きがちです。グループを作ったら、対象者のアカウントで実際に
レポートを開き、必要なカードが全て出ることを確認してください。出ないカードがあっても設定の管理を足すのは避けてください。ポリシーとサインインアドレスまで変更できるパーミッションで、閲覧を渡す目的には広すぎます。
監査とレポートをまとめて情報システム部門に任せる場合、セキュリティグループに入れるのが唯一の方法になります。ただしこのグループには管理サイドバーを表示も付いてくるため、渡す範囲は結果として広くなります。誰に何を見せるかの設計は組み込みグループの役割と管理権限の一覧と割り当て方で扱います。
数字を読むときの前提
レポートごとに見えている範囲が違います。
| レポート | 見えている範囲 |
|---|---|
ビジネスWatchtowerレポート | 直近のサイクルで集計できた保管庫だけ |
使用状況レポート | 作成した人が保管庫の管理を持つ保管庫だけ。アイテムの利用履歴は過去12カ月 |
サインイン試行 | 過去60日。アプリ内のロック解除の失敗は含まない |
アダプションレポート・チームレポート・概要レポート | 開いた時点の状態 |
違反報告 | 外部の漏洩データベースに登録済みの侵害 |
ここから3つの落とし穴が出ます。1つ目は母集団です。ビジネスWatchtowerレポートが数えているのは全保管庫ではありません。2つ目は作成者による違いです。使用状況レポートは作成した人のパーミッションの範囲しか出ないため、管理者が違えば結果も違います。3つ目は期間の区切りです。60日と12カ月が混在しているので、四半期の報告を作るとサインイン試行だけ穴が空きます。

チームレポート。人数、グループ数、保管庫数と、人ごとの最終サインインが並ぶレポート、監査ログ、インサイトの使い分け
3つを混同すると、必要な画面にたどり着けません。
レポートは、ある時点の状態を数える画面です。棚卸しや定期の報告に使います。監査ログは、誰がいつ何をしたかを1件ずつ追う画面です。事故の調査に使います。インサイトは、見つかった問題を是正する画面です。対象者へのリマインダーとWatchtowerへの導線を持ちます。
画面を開かずに継続して監視したい場合は、イベントレポートでSIEMへ流します。Events Reportingの設定とSIEMごとの接続で扱います。
【運用のポイント】 レポートを開いた操作そのものも記録されます。カードには
最終閲覧日が表示され、監査ログにはレポートを表示というイベントが残ります。定期的に確認していることの証跡として監査で使える一方、担当者にも見られていることは事前に伝えておいてください。
運用に組み込むときの決めごと
レポートは開くだけでは何も変わりません。着手の前に3つを決めておくと、毎月の作業が定型になります。
見る人と頻度を先に決める
10本を毎月全部見る必要はありません。週次はサインイン試行、月次はアダプションレポートとデバイスレポート、四半期はビジネスWatchtowerレポートと違反報告、という程度の粗さで十分です。誰が開くかを決めたら、その人が属するグループで実際に開けるかを必ず確認してください。
書き出したCSVの置き場所を決める
多くのレポートはCSVに書き出せます。書き出したファイルにはメールアドレスと利用の履歴が入るため、扱いは元のレポートと同じ機密度になります。保存先と保管期間を先に決めておかないと、監査の証跡として使えないうえに、それ自体が持ち出しの経路になります。
数字の定義を固定する
同じ「利用者数」でも、稼働中のチームメンバーの数、サインインした人の数、ブラウザー拡張機能を設定した人の数では値が違います。報告に使う数字がどのレポートのどの欄の値なのかを一度決め、以後は変えないでください。前月比が動いた理由を後から追えなくなります。