監査人が、ある統制 — 管理者アカウントの利用は、必要に応じて事後調査ができるようログされている — についてのメモを返してきました。これは SOC 2 Trust Services Criteria の CC6.1 (論理アクセス)、CC6.3 (アクセス変更)、CC7.2 (システム監視) にマップされる — それらの統制のうち「管理者活動」の切り取りに相当します。
メモは短いものでした。
ログとアラートの設定の提示、ありがとうございます。テストを完了するために、管理者活動が実際にログされている (単にログが有効になっている、ではなく) ことの証拠が必要です。GCP Audit Logs から、4 つの必須フィールドを示すサンプルを提示してもらえますか。
監査人の 4 フィールド:
- 管理者/特権ユーザー
- 実行された操作
- タイムスタンプ
- 影響を受けたリソース
これを読んで、自分たちが当然と思っていたことに気づきました。私たちはどこでも監査ログを有効にしており、GCP のすべての設定ページも見せられました。すぐに出せなかったのは、管理者が管理者らしいことをした、捕捉され、クエリ可能で、帰属可能なきれいなサンプルでした。
このメモが、私の監査ログの捉え方を作り直しました。本記事は、自社監査の前にこれを読んでおきたかった、という内容です。
「ログ有効」は「監査証拠」ではない
多くのチームは監査ログを設定問題として捉えます。pgaudit を有効化、MySQL の general log を有効化、GCP Cloud Audit Logs を有効化、SaaS の管理画面でチェックボックスを入れる。
それは簡単な方の半分です。
難しい方の半分は、監査人が実際に求めるものです: いま、管理者が特権操作を実行した具体的なレコードを、ユーザー + 操作 + タイムスタンプ + 影響リソースとともに出せるか？
監査人は設定ページを採点しません。あなたが渡すログサンプルを採点します。ログが有効でも、ログ自体が空、不整形、もしくは 4 つのフィールドのいずれかを欠いているなら、その統制は不完全です。
ギャップはほぼ常に次の 3 つのどれかに住みます。
- ログは有効だがイベントが捕捉されていない — 管理者が行った操作カテゴリが、そのロガーの記録対象に入っていない。
- イベントは捕捉されているが ID が誤っている — 共有サービスアカウントが操作を実行し、「誰」が曖昧。
- イベントは捕捉されているがリソースが暗黙 — ログは「ポリシーが更新された」と言うが、どのポリシーかが分からない。
この統制はとくに管理者活動について問うており、これらのギャップが最も悪い場所です。管理者操作は稀で、特権的で、プロダクトエンジニアが最後に計測する層に当たります。
監査人が「管理者活動」で意味するもの
Bytebase のようなデータベースアクセスプラットフォームの文脈では、管理者は他のユーザーが運用するルールを変えられる人を指します。これは想像より広いです。
- Workspace 管理者 — インスタンスを払い出し、グローバル設定を管理
- DBA — 環境を構成し、承認フローを設定し、マスキングポリシーを管理
- プロジェクトオーナー — プロジェクト内で DB アクセスを付与し、ロールを割り当て、変更を承認
- SSO / ID 管理者 — 認証設定を変更し、SSO プロバイダーをローテーション
- 特権権限を含むカスタムロールを持つすべての人 — ロングテール
統制が「管理者アカウントの利用がログされている」と言うとき、上記のあらゆるロールがあらゆる特権操作を行うたびに、4 つの必須フィールドつきのログエントリを残す必要がある、という意味です。
監査人はクエリの放水を求めているのではありません。システムのセキュリティ姿勢を変える活動 — 付与、取り消し、ポリシー編集、ID 変更、稀なブレークグラスデプロイ — の特定の切り取りを求めています。
4 フィールド、6 カテゴリ
監査人のチェックリスト — ユーザー、操作、タイムスタンプ、影響リソース — は最低限です。データベースアクセスプラットフォームでこの統制を実際に通過するには、次のすべてのカテゴリが同じ 4 フィールドレコードを出す必要があります。
1. 認証イベント
すべてのログイン、すべての SSO ハンドオフ、すべての失敗試行、すべてのセッション終了。新 IP からの成功ログインは監査イベントです。2FA 失敗も監査イベントです。タイムアウトでのセッション終了も監査イベントです — インシデント調査時に「この管理者のセッションはいつ終わったか」が問われるからです。
2. ロールと権限の変更
ワークスペース、プロジェクト、データベースの各レベルでの付与と取り消し。レコードは、誰が、どの管理者により、どのリソースに対してどの権限を付与され、いつ を捕捉する必要があります。「Alice が Bob に DB prod-orders の読み取りを付与」が 1 行。「Alice が設定を変更」と保存するのは間違い。
3. ポリシー変更
SQL レビュールール、承認フロー定義、マスキングルール、データ分類設定、保存ポリシー、許可リスト。各編集は、プラットフォームの残りの挙動を変える管理者操作です。各編集には変更前後、または少なくとも変更レコードへのポインタが必要です。
4. アクセス申請の判断
誰が申請し、誰が承認・却下したか、どの根拠で、いつ失効するか。Just-In-Time アクセスの監査証跡 — 監査人が常設アクセス自体を指摘事項として扱うため、ますます期待されるパターン。
5. データ露出イベント
クエリのエクスポート、マスキング例外 (誰が、どの承認の下で何をアンマスクしたか)、外部ユーザーへのクエリシートの共有。これらは「データが安全境界の外に出た」イベントで、インシデント対応テストで監査人が真っ先に追跡します。
6. 変更の実行
デプロイ、ロールバック、Admin モードでの手動 SQL 実行、通常の承認フローのバイパス。すべての実行に行が必要です。Admin モードはとくに — ブレークグラスの経路 — 多くのチームが落とすところ。最も重要な瞬間にログの議論を飛ばしてしまうのです。
これら 6 カテゴリは SOC 2 の Trust Services Criterion に対応します。CC6.1 は論理アクセス、CC6.3 はアクセス変更、CC7.2 はシステム監視をカバーします。「管理者活動」統制は、これらの実装の中の「管理者」スライスに位置します。
DB ネイティブのログだけでは足りない
この統制を最初に見たとき、本能的に DB の監査ログを指したくなりました。Postgres には pgaudit、MySQL には general log、SQL Server には audit specification、Oracle には Unified Auditing があります。
どれも有用です。プラットフォームに対する統制には、どれも答えません。
DB ネイティブのログは実行された SQL を捕捉します。捕捉しないのは:
- その SQL の実行を誰が承認したか — 承認者は DB 層の外
- どのポリシーの下でその SQL が許されたか — 文が通った SQL レビュールール
- 本人としてアクセスしているのか、付与されたロール経由か — 申請チェーン
- このセッションに至るアクセス申請は何か — JIT の履歴
- マスキング例外が許可された理由 — アンマスク読み取りの背後の承認
DB の監査ログは何が実行されたかを語ります。プラットフォームの監査ログは誰が、どのポリシーの下で承認し、その承認がいまも有効かを語ります。「1 週間の管理者活動をユーザー + 操作 + タイムスタンプ + リソース付きで見せて」と問う SOC 2 監査人には、後者が必要です。
アーキテクチャがアプリ → DB で間に何も無いなら、DB のログがほぼすべてで、その周りに計測を組みます。ユーザーと DB の間にプラットフォーム — Bytebase、Okta Privileged Access、StrongDM、Teleport、自前の踏み台 — があるなら、そのプラットフォームには DB と少なくとも同じくらい厳格な独自監査ログが必要です。
我々が対応として作ったもの
監査人のメモを受けて、私たちは 2 つのことを行いました。
第 1 に、自分たちの監査ログを監査しました。上の 6 カテゴリを順に歩き、ログへのクエリですべてのイベント種別についてユーザー + 操作 + タイムスタンプ + リソースのタプルを再現できるかを確認しました。SSO 構成とワークスペース設定にあった一握りの管理者操作が、より古く構造化されていないフォーマットで捕捉されていたので、正規化しました。
第 2 に、ログを監査人に渡しやすくしました。Bytebase の監査ログ は GUI でユーザー、操作種別、リソース、期間でのフィルタをサポートし、JSON や CSV に SIEM 取り込み用エクスポートできます。次の監査サイクルでは、証拠は設定ページのスクリーンショットではなく、フィルタ済みのエクスポートになります。
具体的な変更は小さく、メンタルモデルの変更は大きいものでした。「ログ有効」はシステムのプロパティで、「監査証拠」はアーティファクトです — オンデマンドに生成しなければなりません。そこから導かれる設計判断は、システム内のすべての管理者クラスの操作は、副作用ではなく構造的にログレコードを生む、というものです。
これは Bytebase 自身の SOC 2 監査通過のコンプライアンス物語です。同じ学びが顧客にも当てはまります。Bytebase は開発者と DB の間に立つため、すべてのスキーマ変更、データクエリ、アクセス付与、ポリシー編集がプラットフォームを通ります。監査ログはチームに、すべての DB 操作について同じ 4 フィールドのレコード (ユーザー + 操作 + タイムスタンプ + リソース) を提供します。彼らの監査人が「3 月 14 日に本番スキーマを誰が変えて、誰が承認したか」と問うとき、答えは Slack と Jira をかき分けてではなく、フィルタ済みのエクスポートになります。
データベースアクセスプラットフォームを評価しているなら
データベースアクセスプラットフォームを購入予定で SOC 2 を気にするなら、ベンダーに次を尋ねてください。
- 監査ログのエクスポートサンプルを見せて。 設定ページではなく、スクリーンショットでもなく、少なくとも 1 週間分の実エクスポート。
- 管理者活動だけにフィルタできるか？ 答えに grep が含まれるなら、ログは監査に十分な構造化がされていない。
- すべての行にユーザー ID、操作名、タイムスタンプ、影響リソースが含まれるか？ どれか欠ける行があれば、その行で統制を落とす。
- 保存はどの程度で、改ざん検知性はあるか？ SOC 2 は具体的な保存期間を定めないが、12 ヶ月が一般的な基準で、一部統制カテゴリには 7 年を求める監査人もいる。
- SIEM へエクスポートできるか？ プラットフォームのログがベンダー UI 内にしかないと、他のセキュリティ telemetry と相関できない — 監査人はそれを求めるようになっている。
- ブレークグラス経路 (Admin モード、緊急アクセス、バイパスロール) は通常経路と同じ忠実度でログされるか？ 最もよくあるギャップ。
チェックリスト
いま SOC 2 を通そうとしているなら、管理者活動統制が要求するものの短縮版はこれです。
- システム内のすべての管理者ロールが列挙可能 (ワークスペース、プロジェクト、DB、カスタム)
- それぞれのロールが実行できる特権操作にログエントリ種別が対応
- すべてのログエントリにユーザー、操作、タイムスタンプ、影響リソース — 例外無し
- ログはユーザー、操作、リソース、期間でクエリ可能
- 1 週間分のサンプルが後処理無しでエクスポートして監査人に渡せる
- ブレークグラス経路も同じ 4 フィールドでログされる
- 保存は最低 12 ヶ月、改ざん検知性あり
- ログを SIEM に取り込める
「ログがある」と「監査を通せる」の差は、今日、慌てずに上の各行にチェックを入れられるかどうかにあります。
FAQ
GCP Audit Logs / AWS CloudTrail / Azure Monitor を監査ログにできるか？
インフラレベルの管理者活動には、はい。これらクラウド監査ログは IAM 変更、リソース作成、コンソールログインなどを捕捉します。アプリレベルの管理者活動 — SaaS 内のロール付与、SQL レビューポリシー編集、アクセス申請の承認 — は捕捉しません。データベースアクセスプラットフォームには、クラウドネイティブログに加えて、プラットフォーム独自の監査ログが必要です。
SOC 2 に DB 監査ログだけで足りるか？
DB 層活動には必要ですが、十分ではありません。DB のログは、SOC 2 の論理アクセスと監視の統制が求めるプラットフォームレベルの文脈 — 承認、アクセス申請、ポリシー変更、ID イベント — を捉えません。ユーザーと DB の間にプラットフォーム層があるなら、そのプラットフォーム層に独自の監査ログが必要です。
どのくらいの保存期間が必要か？
SOC 2 は具体的な保存期間を義務付けません — 監査人はあなたのポリシーが何を述べ、それを満たしているかを見ます。一般的な既定は 12 ヶ月。規制業界はより長期 (SOX、HIPAA、PCI DSS それぞれに厳しい要件) を求めることが多いです。ポリシーで宣言した期間を、ログ基盤が実際に届ける必要があります。
「改ざん検知性 (tamper-evident)」とは？
事後の改変を検出できる監査ログ。実装は追記専用ストレージ (不変 S3 バケット、WORM) から暗号チェーン (各エントリが直前のエントリのハッシュを含む) までさまざま。SOC 2 はメカニズムを規定しません。監査人は、削除や改変が検知可能であることを確認したいのです。
非管理者ユーザーの活動はどうか？
別の統制です。管理者活動統制はとくに特権アカウントについてです。一般ユーザー活動 (クエリ、データアクセス) は別の統制 — CC6.1 (論理アクセス、認証用)、CC6.7 (データ伝送、持ち出し経路用)、CC7.2 (監視、異常検知用) — に属します。原則は同じ: ログ有効化は必要だが十分ではなく、監査を通すのは証拠です。
関連記事:
- データベース監査ログ: 2 つのレイヤー、1 本の証跡 — ハブ。インフラ vs ワークフローの分割
- Bytebase の監査ログの扱い — 何が記録されるか、スキーマ、エクスポート方法
- Postgres 監査ログガイド — PostgreSQL のエンジンネイティブ選択肢
- SOC 2 データセキュリティと保存要件
- SOX 準拠のためのデータベース変更管理
- データベースアクセス制御のベストプラクティス
- データベース変更管理とは