1Password 監査ログ運用ガイド 2026 - Events API・SIEM 連携・SOC 2 / ISO 27001 証跡まで

1Password Business の監査ログは「契約したけれど見ていない」状態になりがちですが、サインイン試行・Vault アクセス・権限変更の記録を Events API で SIEM に流し、定例レビューと SOC 2 / ISO 27001 の証跡に結びつければ、情シス・セキュリティ運用の中核になります。

本記事は、1Password Business の監査ログに「何が記録されるか」から、Admin Console での閲覧、Events API による構造化 JSON のストリーミング、Splunk / Datadog / Elastic への連携、検知ルール設計、コンプライアンス証跡化までを、情シス・セキュリティ担当者の実運用目線で整理します。導入プラン選定の前提は 1Password Business プラン徹底比較 2026 も併せて参照してください。

1Password の監査ログに何が記録されるのか

監査ログ (Activity Log) は、組織内で「誰が・いつ・どの認証情報に・何をしたか」を追跡するための記録です。1Password Business / Enterprise プランで提供され、情シスやセキュリティ部門が利用状況を可視化する起点になります¹。

まず押さえるべきは、記録される情報の粒度です。Admin Console の監査ログ (Activity Log) では、各イベントに次の項目が紐づきます。

• actor (操作者): 操作したユーザーのメールアドレス・ID
• action (操作内容): 閲覧・編集・共有・削除、サインイン、ポリシー変更など
• target (対象): 操作対象のアイテム・Vault・グループ
• timestamp / IP: 発生時刻、接続元 IP アドレス

ユーザーエージェントなどのクライアント情報や、サインインの成否 (success / failure) まで踏み込みたい場合は、後述の Events API を使います。とくに sign-in attempts のイベントでは、IP・クライアント情報・成否を構造化 JSON で取得できます。

3 つの主要なイベント種別

監査対象は多岐にわたりますが、運用上とくに重要なのは次の 3 系統です。

1. サインインと認証イベント: 成功・失敗のサインイン、新しいデバイスや場所からのログイン。SSO (SAML / OIDC) や MFA ポリシーと連動して記録される
2. Vault / アイテムアクセス: どの Vault のどのアイテムが閲覧・編集・共有・削除されたか。機密度の高い Vault へのアクセス追跡に直結する
3. 権限・ポリシー変更: グループ管理、Vault 権限の付与・剥奪、管理者操作。アクセス権の変更履歴は内部統制で最重視される

Business プラン以上が前提

これらの監査ログは 1Password の Business / Enterprise プランの機能です。Individual / Families といった個人向けプランには、組織全体のアクセスを管理者が俯瞰する監査ログはありません。プラン別の機能差と社員規模ごとのコストは 1Password Business プラン徹底比較 2026 で整理しているため、導入規模の判断はそちらを参照してください。

Admin Console で監査ログを閲覧・エクスポートする

日々の確認は、まず Admin Console の監査ログ/レポート画面から始めます。コードを書かずに、ブラウザ上のフィルタと CSV エクスポートだけで多くの調査が完結します。

監査ログ画面からの閲覧

管理者は Admin Console の 監査ログ画面 (Reports → Activity 相当) から、組織全体のアクティビティを時系列で確認できます。actor・action・対象 Vault・期間でフィルタでき、たとえば「特定ユーザーの直近 30 日のアイテムアクセス」「失敗したサインインのみ」といった絞り込みが可能です。

ここで得られる一覧は、インシデント発生時の一次調査に向いています。「退職予定者が直近にどの Vault を開いたか」「深夜帯のアクセスがどのアカウントから発生したか」を、ログ基盤を組む前でも即座に追えるのが利点です。

エクスポートと保管

監査ログの内容は CSV を主としてエクスポートできます (構造化 JSON が必要な場合は後述の Events API 経由が基本です)。リアルタイム連携の前段として、まずは定期エクスポートをバックアップ的に運用し、四半期レビューの素材にするチームも多くあります¹。保管期間はプランや契約条件によって異なるため、長期保管が必要な場合は Events API で外部基盤に流す設計が現実解になります。

Events API と SIEM 連携 (Splunk / Datadog / Elastic)

手動エクスポートはスポット調査には十分ですが、継続的なモニタリングには Events API で SIEM に流すのが本筋です。Events API は、コンソール UI を超えて監査イベントへ準リアルタイム / バッチでアクセスする仕組みで、構造化 JSON でイベントを返します²。

Events API の基本

Events API は Admin Console の Integrations → Events Reporting からトークン (bearer token / Authorization: Bearer ヘッダで送信) を発行し、sign in attempts・item usage・audit events といったカテゴリ単位で取得します²。トークンは取得専用のスコープで発行し、Vault の中身そのものにはアクセスしない設計です。

返却される JSON には、actor・action・target・timestamp・IP・user agent・outcome が含まれるため、外部基盤側で正規化すれば他のログ (IdP・エンドポイント・クラウド) と突合できます。

2025〜2026 年の 1Password は、人間ユーザーだけでなくマシンアイデンティティや AI エージェントの「agent-level audit logs (誰がどの権限でどのシークレットを使ったか)」を Unified Access の枠組みで打ち出しており、監査ログの射程はシークレット管理・AI ガバナンスへ広がっています。

[訳] 1Password が Unified Access を正式発表。人間・マシン・AI エージェントの 3 軸で認証情報とアクセスを可視化・統制し、エージェント単位の監査ログまでカバーする新カテゴリ製品 (1Password 公式)。

AI エージェントへのシークレット配布とその監査をどう設計するかは、シャドー AI 対策を 1Password Business で組む 2026 で SSO/SCIM と Unified Access の観点から掘り下げています。本記事は、そこで記録されたログを「読んで・運用する」側にフォーカスします。

主要 SIEM への連携パターン

1Password は Splunk / Datadog / Elastic 向けに公式の連携手順を用意しています²。専用コネクタが無い場合も、構造化 JSON のおかげで実装は素直です。

実装は次の 3 段階で PoC を組むのが定石です。

1. 取得専用トークンを発行: Events Reporting から sign in attempts 等のカテゴリ別にトークンを作成
2. 中継基盤で取得・正規化: サーバーレス関数 (AWS Lambda / Azure Functions) で定期ポーリングし、timestamp / actor_email / action_type / target_type / ip_address / user_agent / success を共通スキーマに整える
3. SIEM 側で可視化・検知: 「Overview」「Sign-in Activity」「Admin Actions」「High-Risk Events」のダッシュボードと検知ルールを構築

サインイン監視と検知ルールの設計

ログを集めるだけでは意味がありません。SIEM に取り込んだイベントから、リスクの高いパターンを自動で検知する設計を最初に組み込みます。

まず作るべき検知ルール

サインイン監視で効果が高い検知ルールは、おおむね次の 4 つに集約されます。

• 同一 IP からの失敗サインイン多発: ブルートフォースの兆候。閾値 (例: 5 分間に 10 回失敗) でアラート
• 異常な地理からのログイン (impossible travel): 短時間に物理的に到達不可能な 2 地点からのサインイン
• 不審な管理者サインイン: 普段と異なる時間帯・場所・デバイスからの管理者アカウント利用
• 権限昇格・大量アクセス: 短時間での Vault 権限付与の連続、退職予定者のアクセス急増

これらは Events API が返す outcome (success / failure)・ip・actor・timestamp から組み立てられます。Elastic Security や Datadog のモニター、Splunk の相関サーチで実装するのが一般的です。

アラート疲れを避ける運用

検知ルールは多ければよいわけではなく、誤検知が多いと「アラート疲れ」で本当の異常を見逃します。導入初期は閾値をやや緩めに設定し、正常パターン (出張・在宅勤務・夜間バッチ運用者) をベースラインとして学習させてから、段階的に締めていくのが現実的です。

定例レビューとコンプライアンス証跡 (SOC 2 / ISO 27001 / J-SOX)

リアルタイム検知と並行して、人手による定例レビューを回すことで、監査ログはコンプライアンスの証跡として最大の価値を発揮します。

四半期レビューの運用サイクル

定例レビューは四半期に 1 度を基本に、以下を棚卸しします。

1. サインイン試行の確認: 直近 90 日の失敗サインイン傾向、新規デバイス・新規地域の発生状況
2. Vault アクセスの確認: 機密度の高い Vault へのアクセス者と頻度、想定外のアクセスの有無
3. 権限変更の確認: アクセス権の付与・変更・剥奪の履歴が、人事異動・退職の実態と整合しているか

重要なのは、レビュー実施日・確認者・対応結果を記録として残すことです。SOC 2 Type 2 や ISO 27001 のアクセスレビュー統制では、「定期的にレビューした記録」そのものが監査証跡になります。

コンプライアンス証跡としての活用

1Password 自身が SOC 2 Type 2 と ISO 27001 の認証を維持しており³、利用企業はその上で自社の統制証跡として監査ログを使えます。具体的な対応例は次のとおりです。

• 論理アクセス制御 (SOC 2 / ISO 27001): サインイン試行と Vault アクセスの記録が、アクセス制御の有効性を示す証跡になる
• 変更管理 (SOC 2 / ISO 27001): 権限・ポリシー変更の履歴が、承認された変更のみが行われたことの裏付けになる
• IT 全般統制 (J-SOX): アクセス権の付与・変更・剥奪が追跡でき、内部統制報告制度の評価ポイントを満たす

1Password Business の Events API でログを長期保管基盤 (BigQuery / S3 / Elastic 等) に流しておけば、「直近 12 ヶ月の管理者操作を提出してほしい」といった監査人の要求にもクエリ一発で応えられます。手作業のスクリーンショット収集に追われる監査対応から脱却できる点が、運用上の最大のメリットです。

[訳] 1Password の監査ログと Events API があると、SOC 2 のレポーティングと監査対応が大幅に簡素化される。多数の SaaS を抱える複雑な環境でも、アクセスの証跡を一元的に取り出せるのが大きい (利用企業の声)。

弊社でも、AI 受託開発やデータ基盤構築の案件で扱う LLM プロバイダの API キーや SaaS 認証情報を 1Password 系の仕組みで管理し、アクセス履歴を運用に組み込んでいます。Events API から SIEM への取り込み設計、検知ルールの初期設定、四半期レビューの運用フロー策定まで、監査ログを「契約しただけ」で終わらせない実装を支援することも可能です。

まとめ: 監査ログは「集める」より「運用する」

1Password Business の監査ログは、記録・閲覧・ストリーミング・レビューの 4 ステップで運用に落とし込むと、情シス・セキュリティの中核資産になります。

• 記録: サインイン・Vault アクセス・権限変更を Activity Log で actor / action / target / timestamp / IP の粒度で取得 (成否やクライアント情報は Events API で補完)
• 閲覧: Admin Console の監査ログ画面 (Reports → Activity 相当) でフィルタ・CSV エクスポート
• ストリーミング: Events API の構造化 JSON を Splunk (HEC) / Datadog (Logs API) / Elastic (ECS) に連携
• 検知: 失敗サインイン多発・impossible travel・不審な管理者操作をルール化
• レビューと証跡: 四半期レビューを記録に残し、SOC 2 Type 2 / ISO 27001 / J-SOX の統制証跡に

監査ログの価値は「集めること」ではなく「読んで運用すること」にあります。Events API で SIEM に流し、検知と定例レビューの両輪を回す設計を最初から組めば、インシデント調査もコンプライアンス監査も、その場しのぎから恒常運用へと変わります。

※情報は 2026-05-31 時点の内容です。最新情報は公式サイトをご確認ください。

※本記事には PR を含みます。