奮闘したデータベース監査ログの意義を法令をもとに整理する

こんにちは、atama plus SRE チームの小路です。

本記事は、2025年12月16日の「どろんこSRE話〜綺麗じゃないSREの苦労話〜」で登壇した際の内容と重複する部分があります。冒頭は登壇時と同じ内容の学びのまとめ（と問題なく公開されればスライドのリンク）で、10分では話せなかった細かい構成、知識についてをここからまとめています。

DB監査ログについて、奮闘して得た学び

会社のフェーズによるものの、DB監査ログは「早く」検討しておくべきということです。
以下の3点を踏まえて推しています。

1. 会社・事業のフェーズに見合った監査ログ取得範囲の検討
   DB監査ログ取得の検討と開始が早ければ早いほど、当然ですが監査ログがもつ意義を早くから果たせます。逆にそれが存在しないと、リスクは当然膨れ上がります。
   また早いフェーズであるほど、いい意味で運用・保管コストにシビアに目を向けられます。適切なログ対象を選定するモチベーションがあり、コストとリスクをバランスする意識を早期に定着させられるチャンスでもあります。
2. コスト許容範囲や、監査ログ保管構成変更の要否とタイミングを計画できる
   検討により以下を見定め、事業の中長期的な開発計画に組み込めるという点です。
   • DB監査ログにかかるインフラコスト
   • そのコスト増加をどこまでそのまま許容するか
   • 許容できなくなったらいつ対応をするか
3. DB高負荷時の対応手順（Runbook）策定
   データベースの高負荷時に、動いているDB監査ログを止めるべきか否か、その手前で他に準備できることがないかを考える機会になります。
   自社の状況とDB監査ログの扱い方を照らして、あるべき障害対応手順・Runbookを整えていく入り口にもなります。

atama plus での実践

最近 SRE チームで進めている Platform Engineering 活動で、開発チームが独立してインフラの構築・運用が実施できるように社内向けの CDK ライブラリを開発し提供しています。
社内で推奨するインフラ設定のベストプラクティス、徹底したいガードレールが様々あるなか、このデータベース監査ログの有効化の設定も組み込んでいます。

// 推奨するポリシーの定義
class WithRecommendedClusterParameters extends Policy<DatabaseCluster, DatabaseClusterProps> {
  public override applyToProps(props: DatabaseClusterProps): DatabaseClusterProps {
    return {
      ...props,
      parameters: {
        // 省略
        // Specifies which classes of statements will be logged by session audit logging.
        'pgaudit.log': 'ddl,read,write',
        // Specifies the master role to use for object audit logging.
        'pgaudit.role': 'rds_pgaudit',

        /* Libraries */
        // pg_stat_statements is required for Performance Insights.
        // auto_explain and pgaudit is required for the settings above.
        'shared_preload_libraries': 'pg_stat_statements,auto_explain,pgaudit',

        ...props.parameters,
      },
    };
  }
}

// 推奨するポリシーをデフォルト適用した Construct
export class DatabaseCluster extends rds.DatabaseCluster {
  public constructor(scope: Construct, id: string, props: DatabaseClusterProps) {
    const policy = new PolicyChain(
      new WithStorageEncryption(scope, id),
      // ...(省略)...
      new WithRecommendedClusterParameters(),
    );

    super(scope, id, policy.applyToProps(props));

    policy.applyToResource(this);
  }
}

このCDKライブラリを利用しているプロダクトでは、現段階ではクローズドなものもあります。見方によってはもしかしたら "不要なフェーズ" かもしれません。
しかし監査ログの意義に立ち返り、atama＋ など他のサービスを運営する会社として検討し、これを設定すべきものとしています。

---

ここまでが登壇時の内容のまとめです。
ここからは、登壇に際して改めて調査したり、LTの時間内では都合上話せなかった部分を詳しく記載していきます。

AWS DB監査ログ構成変更で気にしたこと

構成の詳細は、下記リンクの記事でほとんど網羅されていると思うので、atama plus で実施するときに何を気にしたかだけ記載しておきます。

• サーバーレスコンピューティング
  • AWS Lambda vs ECS Fargate: まずは AWS Lambda でやってみる。稼働させてみてリソース調整して、それでも実行時間が足りなければ ECS にするつもりでした。AWS Lambda で十分だった。
• コスト
  • ストレージの料金（どのストレージクラスを使い、ライフサイクルをどう設定するか）
  • とはいえログの保管の流れがもともと CloudWatch Logs → Data Firehose → S3 だったので保管場所は変わらず、実質変化しなかった
• 完全性
  • DBの監査ログが欠損せず、かつS3保存する監査ログの間に差分が生じないこと
  • 確認するテストの方法まで設計して実施。ただ、ここはCoding LLMの恩恵が大きく得られた
• 障害対応とワークアラウンド
  • 監査ログ欠損の恐れのある事象に迅速に気づき対応できるようにすること
  • アラートに対するアクションをあらかじめ定義しておき手順書を作成
• 再利用性
  • 外部監査の対応があるかないかでも変わってくる
  • ログフォーマットなども気にすべき。脅威検知の用途で使うならなおさら
  • 今回、選定したストレージクラスからの一定期間分のログ再取得にかかる費用の増分はリスクとリターンを検討し、許容するものとした
• 進め方
  • 負荷の低いクラスターの Reader → Writer → 負荷の高いクラスターの Reader → Writer、といった順序づけ
  • データベースパラメータの設定変更があれば、それが再起動を伴うかどうか

https://dev.classmethod.jp/articles/aurora-postgresql-logs-direct-to-s3/
https://tech.pepabo.com/2025/04/16/colorme-rds-audit-logs-s3/

DB監査ログと法令の関係

奮闘しながら「そもそも何でDB監査ログって必要なんだっけ...？」といまさら気になったので調べました。
ここからは、一個人のまとめメモ程度だという前提のもと、興味のある方はご覧ください。

筆者は、職種は（一応）ソフトウェアエンジニアであり、法律について専門的な知見を持ち合わせておらず、正確性を保証するものではありません。この文章をもとにした行為で生じた損害に対する一切の責任を負いません。

法令に基づく各種体制を検討する際には、本記事など決して参考にせず、絶対に弁護士など専門家にご相談ください。

記事執筆時に施行されている条文を参照しています。その後、改正されている可能性もあるので最終的には自身でご確認、ご判断ください。

前提：注意義務と内部統制

会社法

第330条（株式会社と役員等との関係）

株式会社と役員及び会計監査人との関係は、委任に関する規定に従う。

民法 第643条（委任）・第644条（受任者の注意義務）

委任は、当事者の一方が法律行為をすることを相手方に委託し、相手方がこれを承諾することによって、その効力を生ずる。

受任者は、委任の本旨に従い、善良な管理者の注意をもって、委任事務を処理する義務を負う。

これにより、取締役には善管注意義務というものが発生します。
善良な管理者として株式会社から委任された事務、ここでは会社経営をしなければならないということです。そして、取締役が参加する取締役会は、以下のように権限とセットでやるべきことも規定されています。

第362条（取締役会の権限等）

４　取締役会は、次に掲げる事項その他の重要な業務執行の決定を取締役に委任することができない。
　...

六　取締役の職務の執行が法令及び定款に適合することを確保するための体制その他株式会社の業務並びに当該株式会社及びその子会社から成る企業集団の業務の適正を確保するために必要なものとして法務省令で定める体制の整備
　...
５　大会社である取締役会設置会社においては、取締役会は、前項第六号に掲げる事項を決定しなければならない。

※ 大会社：会社法2条6号（定義）
資本金が5億円以上又は負債の額が200億円以上の会社

会社法上での大会社の取締役会は、ここで言う「業務の適正を確保するために必要なものとして法務省令で定める体制」とやらを決議し、構築しなければならないのです。
また、ここでは詳しく引用していないですが、一定条件を満たせば大会社でなくとも義務が発生します。

「大会社？スタートアップだからまだ大丈夫！」と思っていても、大会社のくだりは取締役会の話であって、会社に委任された役員の善管注意義務はそれに関係なく発生します。然るべき人は、その会社の規模なりに適した体制を構築しておかないと、何かあったときに注意義務を果たしていないと見なされる可能性があります。

この構築すべき体制については、さらに細かく施行規則に記載されていて、

会社法施行規則 第100条（業務の適正を確保するための体制）

※一部抜粋

二　当該株式会社の損失の危険の管理に関する規程その他の体制
三　当該株式会社の取締役の職務の執行が効率的に行われることを確保するための体制
四　当該株式会社の使用人の職務の執行が法令及び定款に適合することを確保するための体制

このうちの「損失の危険の管理に関する規程その他の体制」とは、
個別法で保護すべきとされた情報の漏洩で発生するような、会社の損失を防ぐために敷かれるセキュリティ対策であり、
また、法令とガイドラインに反しない正しい財務報告を行えるようにし、嘘の報告でのちのち会社の追加の損失リスクを発生させない仕組みであり、
そのような体制が会社法により求められるという構図になっています。
四の「職務の執行が法令及び定款に適合することを確保するための体制」も監査ログなどは関与すると思われます。

役員が上記のような果たすべき義務を実施せず会社に損害を与えたと解釈された場合、本来は会社がその役員（委任した人）の責任を問い、損害を請求することができます。（会社法第847条 責任追及等の訴え）
会社がこれを行わない場合などに、一定の条件を満たした株主は、会社に損害を与えた役員に対して会社を代表して代わりに訴訟を起こし、当役員の責任を追求することができます。代表的な株主代表訴訟の事例を見ると、注意義務違反の判断がどのように下されるのかや命じられた賠償金額がどのくらいか知ることができます。

事例

内部統制システムの整備

直接的に「データベース監査ログ」は関係しないですが、内部統制システムの不備として役員の責任を認めた代表的な事例があります。ある会社の国外拠点における不正な資金操作とその隠蔽が問題になった事例で、当時の該当拠点の支店長（取締役）は、不正が起きないようにする、ないしは不正に気づくための 内部統制システム整備義務（善管注意義務） を怠ったとして賠償が命じられています^[1]。

個人情報漏洩の際の安全管理

ある会社Xが業務委託した会社Yの社員による個人情報の漏洩に際して、その親会社Zの役員を被告に賠償を求める訴訟がおこされました。子会社である会社Xが事件の収束に用意した金額は親会社Zにとっての損害であり、その責任は子会社Xとその委託先Yに渡って個人データの安全管理を怠った親会社Zの役員にあるとしたものと予想されます。
地裁は「個人データの安全管理については、一次的には（子会社である）会社Xの取締役会で決定される事項」とし、親会社Zに対する訴訟としてはどのような義務違反があったか立証されていないとして請求を棄却しました^[2]。
いずれにせよ本件では少なくとも 個人データの安全管理について取締役会の決定事項として言及 しており、やはり各企業で適切な対応を責任もって行うべきと示唆が得られます。

具体的な法律

然るべき体制を整えよ、と企業活動すべての大前提となっているような会社法を見てきましたが、それとは別にデータベース監査ログの要請と捉えられるような個別の法令があるか見ていきます。

個人情報の保護に関する法律（個人情報保護法）

よく話題になる個人情報の保護と、データベース監査ログの関係についても調べてみました。一番関係していそうな条文はこちらです。

第23条（安全管理措置）

個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならない。

https://laws.e-gov.go.jp/law/415AC0000000057#Mp-Ch_4-Se_2-At_23

では、どのような安全管理措置を講ずればよいのか？
こちらはガイドラインが公開されているので、関係しそうな箇所を抜粋します。

ガイドライン | （別添）講ずべき安全管理措置の内容

• 組織的安全管理措置
  • （2）個人データの取扱いに係る規律に従った運用
    詳細

    個人情報データベース等を情報システムで取り扱う場合、担当者の情報システムの利用状況（ログイン実績、アクセスログ等）

  • （4）漏えい等事案に対応する体制の整備
    詳細

    漏えい等事案の発生時に例えば次のような対応を行うための、体制を整備することが考えられる。

    • 事実関係の調査及び原因の究明
    • 影響を受ける可能性のある本人への通知

  • （5）取扱状況の把握及び安全管理措置の見直し
    詳細

    • 個人データの取扱状況について、定期的に自ら行う点検又は他部署等による監査を実施する。
    • 外部の主体による監査活動と合わせて、監査を実施する。

• 技術的安全管理措置
  • （3）外部からの不正アクセス等の防止
    詳細

    • ログ等の定期的な分析により、不正アクセス等を検知する。

このように、主に組織的な体制（権限管理やその記録）と技術的な対応（ログ分析による検知）がDB監査ログと関係しそうと言えそうです。
文面だけを見ると「スタートアップにはガチガチすぎる体制では？」との印象を受ける方もいるかもしれません。当然ながら記載通りの実現が望ましいとされているものの、中小規模事業者については全てこの水準が必須なわけではなく、その点いくばくか配慮されています。

取り扱う個人データの数量及び個人データを取り扱う従業者数が一定程度にとどまること等を踏まえ、円滑にその義務を履行し得るような手法の例を示すこととする。もっとも、中小規模事業者が、その他の個人情報取扱事業者と同様に「手法の例示」に記述した手法も採用することは、より望ましい対応である

ただし重要な例外事項があります。ある程度のスピード・規模で成長している企業では、特にソフトウェアのプロダクトを扱っている場合は当てはまることになりそうです。

（※2）「中小規模事業者」とは...次に掲げるものを除く

（※2）「中小規模事業者」とは、従業員（※3）の数が100人以下の個人情報取扱事業者をいう。ただし、次に掲げる者を除く。

• その事業の用に供する個人情報データベース等を構成する個人情報によって識別される特定の個人の数の合計が過去6月以内のいずれかの日において5,000を超える者
• 委託を受けて個人データを取り扱う者
  （※3）中小企業基本法（昭和38年法律第154号）における従業員をいい、労働基準法（昭和22年法律第49号）第20条の適用を受ける労働者に相当する者をいう。ただし、同法第21条の規定により同法第20条の適用が除外されている者は除く

さて、現行法では規定された4類型に当てはまれば、本人へ通知する義務があります^[3]。

1. 要配慮個人情報が含まれる事態
2. 財産的被害が生じるおそれがある事態
3. 不正の目的をもって行われた漏えい等が発生した事態
4. 1,000人を超える漏えい等が発生した事態

第26条(漏えい等の報告等)

２　前項に規定する場合には、個人情報取扱事業者（同項ただし書の規定による通知をした者を除く。）は、本人に対し、個人情報保護委員会規則で定めるところにより、当該事態が生じた旨を通知しなければならない。ただし、本人への通知が困難な場合であって、本人の権利利益を保護するため必要なこれに代わるべき措置をとるときは、この限りでない。

時代の早い変化に即して改正が行われる個人情報保護法ですが、検討段階にある次の改正法では、本人への通知が行われなくても本人の権利利益の保護に欠けるおそれが少ない場合について、本人への通知義務を緩和することを議論^[4]しています。ただし、こちらは検討中の内容です。

その議論にもあるように、現行法では広範囲な情報を対象として、漏洩時の通知・報告義務があるとされています。データベースに関して言えば、データベースへの不正アクセスという時点でそこにある個人データ^[5]がたとえ1.と2.に該当せずとも、3.を満たしており、対応義務が発生します。
データベース監査ログは、このような対応義務が発生した際の漏洩対象の確認を行う際には必須です。存在しなければ、「漏洩の可能性のある対象は全データです」としか言えなくなる可能性が出てます。
また活用できれば、その手前の不正検知にも有効となる可能性があります。

なお不正検知の体制について、上述した大規模な個人情報漏洩事件の裁判にて言及されていました。
漏洩した（会社Xの委託先の）会社Yでは、DBと端末間の通信量による不正検知の仕組みは存在しなかったようです。しかし、存在したとしてもそれだけで本件不正を回避できたとは言えない（∵異常検知アラートであれば、しきい値次第で本件のように小規模に長期的に分散して実行すれば検知されない可能性があった）と裁判所に判断されています^[6]。
ただ、ここもケースによって複合的に判断されうる基準だと想定されるため、一概に「だからDB監査ログによる不正検知や定期的な確認などは不要だ」とは決して言えません。

実際は、他のストレージなども含めて個人データの場所が想定されるため、データベース監査ログに限った話ではありません。その他のログや証跡の運用も同様に、安全管理措置の射程にあると考えてよさそうです。

金融商品取引法

この法令との関係では、内部統制報告制度（J-SOX）があげられます。企業に対し財務報告についての内部統制を義務付けた制度です。
この法律による規定で、有価証券報告書を提出しなければならない企業があり、代表的なものが株式市場に上場している会社です。

ここで財務報告についての内部統制の一部として、会計監査が関係してきます。
財務報告に含まれる会計の数値が不正でないものと証明しなければなりません。
そのためにどのような体制を設けて、それが想定通りに機能しているかを評価して報告することになります。ITに関する内部統制の有効性の評価ももちろん実施されます。

財務報告に係る内部統制の評価及び監査に関する実施基準

• 「Ⅰ．内部統制の基本的枠組み」

  • 「２．内部統制の基本的要素」
    • 「（６） ＩＴへの対応」
      注意書き引用

      財務報告の信頼性に関しては、ＩＴを度外視しては考えることのできない今日の企業環境を前提に、財務報告プロセスに重要な影響を及ぼすＩＴ環境への対応及び財務報告プロセス自体に組み込まれたＩＴの利用及び統制を適切に考慮し、財務報告の信頼性を担保するために必要な内部統制の基本的要素を整備することが必要になる。例えば、統制活動について見ると、企業内全体にわたる情報処理システムが財務報告に係るデータを適切に収集し処理するプロセスとなっていることを確保すること、あるいは、各業務領域において利用されるコンピュータ等のデータが適切に収集、処理され、財務報告に反映されるプロセスとなっていることを確保すること等が挙げられる。

• 「Ⅱ．財務報告に係る内部統制の評価及び報告」

  • 「３．財務報告に係る内部統制の評価の方法」
    • 「⑤ＩＴを利用した内部統制の評価」
      • 「（３）業務プロセスに係る内部統制の評価 」
        • 「ニ.ＩＴを利用した内部統制の整備状況及び運用状況の有効性の評価」
          • 「ａ．ＩＴに係る全般統制の評価」
            詳細

            経営者は、ＩＴに係る全般統制が、例えば、次のような点において有効に整備及び運用されているか評価する。
            ・システムの開発、保守
            ・システムの運用・管理
            ・内外からのアクセス管理などのシステムの安全性の確保
            ・外部委託に関する契約の管理

この文脈で、データベース監査ログの運用についてもその適正性が評価されるでしょう。
事業の主要プロダクトで使われているデータベースのあるデータを、財務会計上の不備がないことの根拠にしようとする場合、そのデータが改ざんされていないことが絶対です。
当該データベースへのアクセス権の管理など運用体制の構築ももちろんその根拠の一つとなり得ますが、アクセス権のある人間が改ざんを実施すればそれまでです。
結局のところこれを証明するには、データベース上で ”誰が” "いつ" "何をしたか" を示す監査ログが必要ですし、またそのログの保管においても、権限を持つもの以外改ざんできないこと・改ざんされていないことを示すことになります。
実務上、厳密にそこまで遡って全てを確認するかはさておき、いつでも証明できる体制を整えることが対象企業の経営者に求められていると解釈できそうです。
こちらもデータベース監査ログに限った話ではなく、その他のログや証跡にも当てはまると考えられます。

法令とデータベースログまとめ

各種法令とDB監査ログ（を入口にした監査ログその他の体制）をいくつか見てきました。

最後にそれらの法律が何を守るためにあるのかも整理します。
このように捉えると、「なぜ」「いつ」データベース監査ログが必要なのかを考えやすくなると思いました。

法律	守るもの	誰への責任？	DB監査ログその他の役割
会社法	株主・会社の資産	取締役 → 株主・会社	経営陣が適切に職務執行のリスク管理（監視）を行っていると言える根拠。
個人情報保護法	ユーザーのプライバシー	企業→ユーザー（被害者）	漏洩の事実確認と、影響範囲の特定（全件漏洩ではない証明）。
金融商品取引法 (J-SOX)	投資家の判断に用いられる数字の正確性	企業→市場・投資家	公開した財務データが、正しく処理されたことの担保。

これで全ての法令を網羅していないと思いますが、かなり長くなったのでここまでとします。気がついたら条文の引用の影響もあってか1万文字超えている...
「こういう法令もあるよ！」と詳しい方いらっしゃいましたら教えてください。

---

脚注

1. 大和銀行株主代表訴訟 - 弁護士法人栄光 栄光綜合法律事務所

2. https://www.jstage.jst.go.jp/article/jabesssb/1/0/1_100/_pdf/-char/ja

3. 漏えい等報告・本人への通知の義務化について

4. イ 本人への通知が行われなくても個人の権利利益の保護に欠けるおそれが少ない場合における漏えい等発生時の対応の在り方

5. 個人データの該当性にもまた詳しい定義がありますがここでは割愛

6. https://www.jstage.jst.go.jp/article/jabesssb/1/0/1_100/_pdf/-char/ja