監査ログは、誰がいつ何をしたかを1件ずつ追う画面です。レポートが今の状態を数えるのに対して、こちらは起きたことを時系列で並べます。事故の調査と定期の点検に使いますが、2つの前提を知らないまま数えると結論を誤ります。1つは、開いた人のパーミッションによって表示される範囲が変わることです。もう1つは、記録が新旧2つの画面に期間で分かれていることです。このページでは、開ける人の条件、列の意味、記録される範囲と残る期間、絞り込みとCSVへの書き出し、新しい監査ログとの使い分け、調査の進め方を説明します。画面を開かずに監視を続ける方法はEvents Reportingの設定で扱います。
誰が何を見られるか
サイドバーの監査ログから開きます。開けるのは所有者と管理者、および管理サイドバーを表示のパーミッションを持つグループのメンバーです。委譲の設計は管理権限の一覧と割り当て方で扱います。
見落としやすいのは、一覧の上に出ている一文です。
【注意】 画面には
1Passwordのアクセス権を持つエリアのイベントのみを見ることができます。と表示されます。監査ログが返すのは、開いた人がアクセスできる範囲のイベントだけです。同じ時刻の同じ操作でも、2人の管理者が見る一覧は一致しません。件数を数えて社内の報告に使うと、集計した人によって値が変わります。組織全体の欠けのない記録が必要な場合は、画面ではなくEvents APIから取得してください。
この性質は、保管庫を絞って管理を任せている組織ほど強く出ます。特定の部門の保管庫だけを任された管理者の画面には、他部門の保管庫で起きたことが最初から現れません。調査を依頼するときは、依頼先が対象の保管庫にアクセスできるかを先に確認してください。
画面の読み方
一覧は5つの列で構成されます。
| 列 | 内容 |
|---|---|
日付と時刻 | 操作が行われた日時。既定では新しい順に並ぶ |
イベント | 操作の種類。レポートを表示、グループを作成する、デバイスを認証するなど |
実行ユーザー | 操作した人の名前とメールアドレス |
説明 | 何に対する操作だったか |
IP アドレス | 操作した端末のIPアドレス |
説明の中の対象名はリンクになっていて、選ぶとそのレポートや保管庫に移動します。調査の途中で対象を確かめたいときに使えます。一覧の件数は右上の1ページあたりのアイテム数で変えられます。既定のままだと調査のたびにページ送りが増えるので、最初に大きくしておくと楽です。
IP アドレスにはIPv6のアドレスも入ります。社内の記録と突き合わせるときは、IPv4だけを想定した検索では引っかかりません。
記録されるイベントと残る期間
記録されるのは管理操作が中心で、大きく6つの領域に分かれます。
| 領域 | 記録される操作の例 |
|---|---|
| アカウントと課金 | アカウント名、ロゴ、サインインアドレスの変更、支払い方法と契約の変更 |
| 人とグループ | 招待、参加、グループの作成と削除、メンバーシップの変更 |
| 保管庫とアイテム | 保管庫の作成と削除、アイテムの作成、編集、アーカイブ、削除、共有リンクの発行と削除 |
| 端末と認証 | 端末の認証と解除、2要素認証の変更、サインイン試行の上限超過、SSOのサインイントークン |
| 統合と自動化 | サービスアカウントの追加、トークンの発行と失効、SSO設定の変更、Slackの統合 |
| MSP | 管理対象企業の追加、起動、解除 |
レポートを開いた操作と書き出した操作も残ります。監査の証跡として使える一方で、担当者の閲覧履歴も残るということです。
【注意】 保管庫のエクスポートのイベントは、1Password 8.4.0以降のアプリで行われた操作しか記録されません。古いアプリが残っている環境では、持ち出しがあっても監査ログに現れない可能性があります。アプリのバージョンの分布はサインイン試行と端末のレポートの
デバイスレポートで確認できます。
保存期間は365日です。それより前のイベントは画面からも書き出しからも取れません。1年を超えて保管する必要がある場合は、CSVを定期的に書き出すか、SIEMへ送って自社側で保管します。設計はログの保管とアラートの設計で扱います。
一覧を絞り込む
一覧の右上に年月日、実行ユーザー、イベントの3つの絞り込みがあります。それぞれ選んで適用すると一覧が絞られます。複数を同時に使うときはすべてのフィルターから選び、まとめて適用します。解除は各フィルターの中から、全ての解除はまとめて行えます。
イベントの一覧は数十件あります。調査でよく使う組み合わせは決まってくるので、選んだ状態のURLをブックマークするより、手順書に「どのイベントを選ぶか」を書いておく方が確実です。
CSVに書き出す
右上のDownloadから書き出します。CSVには画面に出ていない列が入ります。実行した人の一意の識別子、操作の種類、対象の種類と識別子、補足情報とその識別子です。
識別子が入っているのは、名前やメールアドレスが変わっても同じ対象を追えるようにするためです。退職者の操作を後から調べるときは、この識別子を手掛かりにします。逆に言えば、識別子と実際の人や保管庫を結びつける表を自社で持っていないと、書き出したCSVだけでは読めません。
新しい監査ログに切り替える
一覧の上のバナーからTry new audit logを選ぶと、新しい監査ログに切り替わります。バナーには、2025年12月1日以降に記録されたイベントをより詳しく確認できると表示されます。Return to old audit logでいつでも戻れます。
新しい画面では列の構成が変わります。年月日、アクション、カテゴリ、実行ユーザーの4列になり、各行の詳細をすべて表示から、変更の前後の値、使ったアプリ、端末、OS、場所、セッションの情報まで開けます。誰が何をしたかだけでなく、どこからどうやって行ったかまで追えるようになります。書き出しもダウンロード（CSV）から行えます。
アクションの値はreport.viewやgroup.access.grantのように、対象と属性と動作をピリオドでつないだ英語の表記です。旧来のレポートを表示のような日本語の表記とは体系が違うため、手順書に書くイベント名は両方を併記しておかないと後任が探せません。
【注意】 2つの画面は期間で分かれています。2025年12月1日より前のイベントは新しい画面に出ず、旧来の画面に戻って探すことになります。調査の対象期間がこの日をまたぐ場合、同じ事象を2つの画面で別々に集めて、手作業でつなぐ必要があります。四半期や年度の区切りで調べる運用にしていると、毎回この作業が発生します。
調査と点検での使い方
事故を調べるとき
先に期間を絞り、次に実行ユーザーで絞ります。イベントの種類で絞るのは最後です。何が起きたか分からない段階でイベントを絞ると、想定していない操作を落とします。関係する保管庫が特定できている場合は、保管庫とアクセス権の棚卸しの手順で現在のアクセス権を先に確認しておくと、監査ログの読み方が早くなります。
月次で点検するとき
見るのは件数ではなく、想定していない操作が混ざっていないかです。グループへのメンバーの追加、保管庫のアクセス権の変更、サービスアカウントのトークンの発行の3つを毎月確認すると、不要なアクセス権の広がりに早く気付けます。
記録として残すとき
CSVを書き出し、書き出した日付と絞り込みの条件を一緒に保管します。条件を残さないと、後から見たときに「この期間に本当にこれだけしかなかったのか」が判断できません。書き出したファイルにはメールアドレスとIPアドレスが入るため、保管場所は元の画面と同じ機密度で扱ってください。
【運用のポイント】 監査ログは事後に追うための画面です。危険な操作にその場で気付く仕組みにはなりません。アラートが必要な操作を洗い出したら、Events APIでSIEMへ送り、SIEM側でルールを組みます。監査ログは調査、SIEMは検知、という切り分けにすると、どちらも中途半端になりません。