大企業向けセキュリティ証跡基盤の作り方
はじめに
大企業のセキュリティ統制は、中小企業の延長では設計できません。システム数が多いだけでなく、基幹系、情報系、クラウドネイティブ、オンプレミス、SaaS、子会社、海外拠点、委託先運用、買収で引き継いだ古い環境が混在します。
この状態で全システムに同じチェックリストを配ると、たいてい破綻します。回答粒度が揃わず、証跡の信頼性もばらつき、重要システムと低リスクシステムが同じ重さで扱われます。結果として、中央部門は集計に追われ、現場は回答に疲弊し、経営は判断に使える情報を得られません。
大企業で必要なのは、単一ツールや一律チェックではなく、統制目的を共通化し、証跡の取り方は環境ごとに許容し、証跡品質と例外だけを全社で巻き上げる仕組みです。NIST CSF 2.0がリスク管理を改善するための共通枠組みを提供し、NIST SP 800-137が継続的監視による資産・脅威・脆弱性・統制有効性の可視化を重視している点とも整合します。12
この記事では、数十から数百システムではなく、数千以上のシステム群を持つ企業を想定し、数年単位で証跡アプローチを構築する考え方を整理します。
全体像
大企業向けの証跡アプローチは、統制の全社標準化と、証跡取得の分散実装を両立させます。中央で全部を集めるのではなく、各環境が証跡を出せる形を定義し、その品質を共通指標で評価します。
大企業で一律統制が難しい理由
システムの重要度が揃っていない
全システムを同じ深さで評価すると、重要システムに必要な検証が浅くなり、低リスクシステムには過剰な負荷がかかります。大企業では、売上、決済、顧客データ、法規制、社会的影響、復旧許容時間などでシステムを層別し、証跡の深さを変える必要があります。
技術基盤が揃っていない
同じ「脆弱性管理」でも、クラウドネイティブ、メインフレーム、SaaS、パッケージ、子会社環境では、取得できる証跡が違います。統制目的は共通にできますが、証跡ソースまで完全に統一しようとすると、例外だらけになります。
責任境界が複雑である
大企業では、共通基盤、事業部門、子会社、外部委託先、SaaS提供者が責任を分け持ちます。NIST RMFは、システムレベルと組織レベルのリスク管理をつなぎ、共通統制や継承される統制の責任を明確にする考え方を示しています。3 大企業の証跡設計でも、どの統制を全社共通基盤から継承し、どの統制をシステム個別に証明するかを分ける必要があります。
経営報告が集計不能になりやすい
システムごとに回答形式が違うと、全社リスクへ巻き上げられません。NIST IR 8286 Rev.1は、システムや組織の下位レベルで扱うリスク情報を企業全体のリスク管理へ統合する価値を説明しています。4 大企業では、証跡を集めるだけでなく、リスク登録簿や投資判断に接続できる粒度へ正規化する必要があります。
基本方針
統制目的は共通化し、実装は分散させる
全社で揃えるべきものは、ツール名や画面ではありません。揃えるべきものは、統制目的、証跡要求、鮮度、責任者、例外承認、評価基準です。
たとえば「重要ログを取得しているか」という統制目的は共通化できます。一方で、ログソースはSIEM、クラウド監査ログ、SaaS監査ログ、EDR、アプリケーションログ、委託先報告などに分かれます。この差を無理に潰さず、証跡契約として許容パターンを定義します。
システム単位ではなく、層別単位で深さを変える
証跡の深さは、全システム一律ではなく、層別で変えます。
| 層 | 対象例 | 証跡方針 |
|---|---|---|
| Tier 0 | 認証基盤、ネットワーク中核、鍵管理、監視基盤 | 最も深い証跡、短い鮮度SLA、全社共通統制として扱う |
| Tier 1 | 基幹業務、決済、顧客データ、重要インフラ相当 | 一次証跡中心、継続監視、例外は経営レベルで承認 |
| Tier 2 | 通常業務システム、部門アプリ | 標準証跡パターンを適用し、重要統制を自動化 |
| Tier 3 | 低リスクツール、小規模補助システム | 軽量な証跡と年次確認。ただしID、所有者、利用データは必須 |
| 外部依存 | SaaS、委託先、子会社、共同利用基盤 | 契約、監査報告、API証跡、アクセス範囲、オフボード証跡を組み合わせる |
この層別がないまま証跡基盤を作ると、重要でないシステムに時間を取られ、重要システムの統制有効性を深く見られません。
証跡契約を作る
証跡契約とは、統制目的ごとに「どの証跡を、どの形式で、どの頻度で、誰が、どの品質で出すか」を定義するものです。契約という名前にするのは、中央部門の依頼ではなく、システムオーナーと共通基盤の運用責任にするためです。
| 項目 | 定義すること |
|---|---|
| 統制目的ID | どの全社統制に対応するか |
| 対象範囲 | どのシステム、資産、環境、データ種別が対象か |
| 証跡ソース | API、ログ、スキャン結果、チケット、監査報告など |
| 鮮度SLA | 日次、週次、月次、四半期、イベント時など |
| 品質基準 | 完全性、正確性、改ざん耐性、生成元、時刻、所有者の有無 |
| 責任者 | システムオーナー、統制オーナー、共通基盤オーナー |
| 例外処理 | 代替統制、期限、承認者、再評価日 |
| 保持期間 | 監査、法務、契約、調査に必要な期間 |
NIST SP 800-53Aが示す統制評価の考え方や、SP 800-55の測定値の考え方を大企業に引き直すと、証跡契約は「何を評価できる状態にするか」を事前に合意する設計になります。56
証跡基盤の構成要素
全社統制カタログ
統制カタログは、法規制、社内規程、NIST CSF、ISO/IEC 27001、業界要求、顧客要求をそのまま並べる場所ではありません。重複した要求を統制目的へ正規化し、システム層別ごとの適用要否を持たせます。ISO/IEC 27001はISMSの要求事項、ISO/IEC 27002は情報セキュリティ管理策の参照先として使えます。78
共通ID体系
大企業の証跡基盤で最初に詰まるのは、データ量ではなくID不一致です。最低限、次のIDを揃えます。
| ID | 用途 |
|---|---|
| System ID | システム台帳、リスク登録簿、監査対象を結ぶ |
| Asset ID | サーバ、クラウド資源、端末、コンテナ、DBを結ぶ |
| Owner ID | 責任者、部門、委託先、承認者を結ぶ |
| Control ID | 統制目的、証跡要求、評価結果を結ぶ |
| Exception ID | 例外、期限、代替統制、リスク受容を追跡する |
| Supplier ID | SaaS、委託先、製品、子会社との依存関係を追跡する |
このID体系がないままログやスキャン結果を集めると、証跡レイクではなく検索しにくい保管庫になります。
証跡レジストリ
証跡レジストリは、証跡ファイルそのものを全部置く場所ではありません。どの統制目的について、どのシステムの、どの資産から、いつ、どの証跡が取得され、どの品質で評価されたかを管理する台帳です。
| メタデータ | 意味 |
|---|---|
| 取得時刻 | 証跡がいつ生成・取得されたか |
| 対象 | System ID、Asset ID、環境、データ種別 |
| 生成元 | API、ツール、ログ、委託先、手動添付など |
| 完全性 | 欠損、重複、対象外、未収集の有無 |
| 改ざん耐性 | 署名、ハッシュ、WORM、原本リンク |
| 評価結果 | 合格、不合格、未評価、例外、対象外 |
| 評価者 | 自動評価、統制オーナー、監査人など |
OSCALは、統制、評価、実装情報を機械可読に扱う方向性として参考になります。9 ただし、最初から全社OSCAL化を目指すより、まずはID、証跡契約、メタデータを揃えるほうが現実的です。
例外管理
大企業の統制は、例外をゼロにできません。重要なのは、例外を埋もれさせないことです。
例外には、期限、代替統制、残余リスク、リスク受容者、再評価日、経営報告要否を持たせます。Tier 1以上の例外は、システムオーナーだけで閉じず、CISOまたはリスク委員会へ上げます。例外が多い統制は、現場の怠慢ではなく、統制設計が環境に合っていない可能性もあります。
数年単位のロードマップ
Phase 0：準備期
期間の目安は6か月から1年です。ここで焦ってツールを入れると、既存の混乱をそのまま自動化します。
| やること | 成果物 |
|---|---|
| システム台帳と資産台帳の棚卸し | System ID、Owner ID、重要度、環境種別 |
| 統制要求の棚卸し | 規程、監査、法規制、顧客要求、業界要求の一覧 |
| 統制目的への正規化 | 30〜80程度の全社統制目的 |
| 層別基準の定義 | Tier 0〜3、外部依存、AI/データ基盤など |
| パイロット選定 | 代表的な環境を含む10〜30システム |
| ガバナンス体制 | CISO、事業、IT、内部監査、法務、調達の会議体 |
Phase 0の成功条件は、証跡をたくさん集めることではありません。「何を全社で揃えるか」と「何は環境差として許容するか」を決めることです。
Phase 1：標準化期
期間の目安は1年目です。ここでは、証跡の取得よりも、証跡を出すための標準を作ります。
| やること | 成果物 |
|---|---|
| 証跡契約テンプレートを作る | 統制目的ID、証跡ソース、鮮度SLA、品質基準 |
| 共通IDを台帳へ組み込む | System ID、Asset ID、Control ID、Exception ID |
| 共通統制を分ける | IdP、EDR、ログ、クラウド標準、脆弱性管理など |
| 重要システムから適用する | Tier 0とTier 1を優先 |
| 証跡品質KPIを出す | 網羅率、鮮度、生成元、欠損、例外件数 |
この段階では、まだ手動証跡が残っていて構いません。重要なのは、手動か自動かではなく、証跡の所有者と品質が見えていることです。
Phase 2：基盤化期
期間の目安は2〜3年目です。ここで初めて、大規模な証跡収集基盤やGRC連携が本格的に効き始めます。
| やること | 成果物 |
|---|---|
| 主要ソースを連携する | CMDB、IdP、EDR、CSPM、SIEM、脆弱性管理、チケット |
| 証跡レジストリを作る | 証跡メタデータ、原本リンク、評価結果 |
| オンボーディングを型化する | 新規システム、SaaS、子会社、委託先の接続手順 |
| 共通統制の継承を実装する | 全社IdP利用、標準ログ基盤、標準クラウド環境など |
| 内部監査と接続する | 証跡品質監査、サンプリング、例外妥当性評価 |
この時期の失敗パターンは、全証跡を1つの巨大な湖に投げ込むことです。必要なのは、原本を全部中央に集めることではなく、原本へのリンク、評価結果、品質メタデータを追えることです。
Phase 3：継続評価期
期間の目安は3〜5年目です。ここから、監査対応のための証跡収集ではなく、経営とリスク管理に使う継続評価へ移します。
| やること | 成果物 |
|---|---|
| 統制評価を継続化する | 日次・週次・月次評価、例外自動起票 |
| リスク登録簿へ接続する | 重大例外、是正遅延、サプライヤリスクの巻き上げ |
| 投資判断へ接続する | 統制不備、技術負債、共通基盤整備の優先順位 |
| サプライチェーンへ広げる | 委託先、SaaS、製品、SBOM、契約証跡 |
| AI・データ基盤へ広げる | モデル台帳、データ利用、承認ログ、出力監視 |
サプライチェーンでは、NIST SP 800-161 Rev.1が、組織の複数レベルでサプライチェーンリスクを識別、評価、低減する考え方を示しています。10 大企業の証跡基盤では、委託先報告や契約書を単なるPDF保管にせず、Supplier ID、対象システム、アクセス範囲、期限、是正状況と結びます。
Phase 4：定着期
期間の目安は5年目以降です。この段階でも完成ではありません。組織再編、買収、クラウド移行、AI利用拡大に合わせて、証跡契約と統制カタログを更新し続けます。
| やること | 成果物 |
|---|---|
| 古い回答様式を廃止する | 重複チェックリスト、部門独自台帳、監査前集計の縮小 |
| 証跡品質を監査対象にする | 自動証跡の完全性、正確性、改ざん耐性の検証 |
| 統制を製品化する | 各事業が使える標準部品、標準ダッシュボード、標準例外フロー |
| M&Aや子会社展開に使う | 買収後100日計画、子会社統制、海外拠点統制 |
ここまで来ると、証跡基盤は監査対応ツールではなく、企業のリスク運営基盤になります。
大企業向けKPI
大企業では、準拠率だけでは不十分です。証跡そのものの品質を測ります。
| KPI | 見ること |
|---|---|
| System ID付与率 | 全社台帳に載っていないシステムを減らす |
| 重要システム証跡契約率 | Tier 0/1に証跡契約があるか |
| 一次証跡比率 | 自己申告やスクリーンショット依存を下げる |
| 証跡鮮度SLA遵守率 | 古い証跡で判断していないか |
| 共通統制継承率 | IdP、EDR、ログ、クラウド標準をどれだけ使えているか |
| 例外滞留日数 | 期限切れ例外と長期未解消を見える化する |
| リスク登録簿連携率 | 統制不備が企業リスクへ巻き上がっているか |
| 監査再指摘率 | 同じ統制不備が繰り返されていないか |
| 委託先証跡更新率 | 外部依存の証跡が期限内に更新されているか |
このKPIは、セキュリティ部門だけで見るものではありません。事業責任者、システムオーナー、共通基盤オーナー、内部監査、調達が同じ数字を見る必要があります。
役割分担
| 役割 | 主責任 |
|---|---|
| 経営層 | リスク許容度、例外基準、投資優先度を決める |
| CISO/リスク管理 | 統制カタログ、証跡契約、KPI、例外ガバナンスを持つ |
| 事業責任者 | システムの重要度、リスク受容、改善計画を承認する |
| システムオーナー | 証跡契約に基づく証跡提出と例外管理を行う |
| 共通基盤オーナー | IdP、EDR、ログ、クラウド標準などの共通証跡を提供する |
| データ/プラットフォーム部門 | 証跡レジストリ、ID連携、品質ダッシュボードを運用する |
| 調達/法務 | 委託先、SaaS、契約、監視目的、保持期間を確認する |
| 内部監査 | 全件収集ではなく、証跡品質と例外妥当性を独立評価する |
大企業では、中央セキュリティ部門が全システムの証跡を直接作る設計は続きません。第1線が証跡を所有し、第2線が標準と品質を管理し、第3線が独立に検証する構造にします。
よくある失敗
ツール導入を先にする
GRC、SIEM、CSPM、脆弱性管理、CMDBを入れても、System ID、Owner ID、Control IDが揃っていなければ、全社説明には使いにくいままです。ツールより先に、統制目的、証跡契約、ID体系を固めます。
全システム一斉展開を狙う
数千システムを一度に対象にすると、現場対応も中央集計も詰まります。Tier 0/1と代表的な環境から始め、標準パターンを作ってから横展開します。
例外を悪いものとして扱う
例外を隠す文化になると、証跡基盤は形骸化します。例外は統制の失敗ではなく、リスク判断の対象です。ただし、期限、代替統制、リスク受容者、再評価日がない例外は認めない設計にします。
証跡を集めるだけで評価しない
ログ、スキャン結果、チケット、監査報告を集めても、統制目的に結びつかなければ説明責任にはなりません。証跡レジストリには、評価結果と評価基準を必ず持たせます。
内部監査を最後に呼ぶ
数年計画では、内部監査は最後の確認者ではなく、証跡品質の検証者として早期から巻き込むべきです。自動証跡の完全性や改ざん耐性をどう見るかは、監査側と早めに合意します。
まとめ
大企業の証跡アプローチは、短期の監査対応ではありません。数年かけて、システム台帳、統制カタログ、証跡契約、共通ID、証跡レジストリ、例外管理、リスク登録簿をつなぐ取り組みです。
ポイントは、全システムに同じ実装を強制することではありません。統制目的と証跡品質を共通化し、証跡取得は環境ごとの現実に合わせることです。
最終的に目指す状態は、次のような姿です。
- すべての重要システムに、所有者、重要度、証跡契約がある
- 共通統制は、全社基盤から継承できる
- システム個別統制は、一次証跡と例外管理で説明できる
- 統制不備は、リスク登録簿と投資判断へ巻き上がる
- 内部監査は、証跡集めではなく証跡品質を検証できる
この状態に近づけると、大企業のセキュリティ統制は「回答を集める活動」から「リスクを運営する仕組み」へ変わります。