企業セキュリティの全体像
— なぜ守るのか、何を守るのか、どう守るのか

ポイント: NIST CSF の6機能「統治（Govern）→ 識別（Identify）→ 防御（Protect）→ 検知（Detect）→ 対応（Respond）→ 復旧（Recover）」は、対策の抜け漏れ確認に最も使いやすい整理軸です。

対策の有効性は測定しなければ改善できず、経営層への報告も「やっています」以上の説明ができません。リスクマネジメントサイクルを回す際は、測定可能な指標を定めて定点観測します。

• 指標は「対策の稼働状況（KPI）」と「リスクの予兆（KRI: 例＝未対応の重大脆弱性の滞留数）」の両面で持つ
• NIST CSF等による成熟度評価を定期実施し、経年変化と投資判断の根拠にする

生成AIによる攻撃の高度化（§1.3）は、従来の教育の前提を崩しつつあります。

• 「不自然な日本語を見抜く」型の教育は無効化されつつある — AIが生成するフィッシング文面は自然で、文面の違和感に頼る判別はもはや成立しない
• 声・映像も本人確認の根拠にならない — ディープフェイクにより、電話の声やビデオ会議の顔が本人である保証はない

したがって防御の重心を「人の注意力」から業務プロセス側の防御に移す必要があります:

• 送金・支払先変更・権限変更などの重要依頼は、依頼が来た経路とは別の経路で本人確認する（コールバック検証。依頼メール記載の連絡先ではなく、既知の連絡先へかけ直す）
• 金額・重要度に応じた複数人承認の徹底（緊急を装った承認スキップ要求こそ危険信号）
• 「上司からの急ぎの依頼を疑うことを許容する」文化（§11.1の報告文化と同根）

端末を守る仕組みには EPP・EDR に加え、データの持ち出しを見張る DLP があります。3者は目的が異なりますが、いずれもPC上のエージェントで動くため、実装は重なります。

merge実装は「1つのエージェント」に統合されつつある

概念は別でも、エンドポイント型DLPはEDRと同じくPC常駐エージェントで動くため、監視ポイント（USB・印刷・クリップボード・アップロード）が共通です。そのため主要ベンダーは統合を進めています。

• CrowdStrike: EDRと同一エージェントに Falcon Data Protection（DLP）を追加
• Microsoft: Defender for Endpoint（EDR）と Purview（DLP）が同じ端末エージェント・データ基盤で連携

• BYOD（私物端末の業務利用）: 許可する場合はMDM/MAMによる統制とルール整備が前提
• リモートワーク環境: 自宅ネットワーク・公共Wi-Fi利用時の保護（常時VPN/ZTNA、画面覗き見対策）
• IoT・OT機器: 複合機、監視カメラ、工場設備等。パッチ適用が難しいためネットワーク分離が基本
• 退職・廃棄時: データの完全消去、資産返却の徹底

上記は主に「人間のID」の統制ですが、実際の環境にはサービスアカウント、APIキー、システム連携用アカウントといった非人間IDが人間IDの数倍〜数十倍存在し、AIエージェントの普及（§9.3）でさらに増加しています。侵害事例では、棚卸しから漏れたサービスアカウントや長期間ローテーションされないAPIキーが突かれるケースが多い領域です。

人間IDと異なり「入社・退職」というライフサイクルの起点がないため、別の管理が必要です。

• インベントリとオーナー割当: すべての非人間IDに管理責任者（人間）を紐付ける。作った担当者の退職とともに「所有者不明」になるのが典型的な放置パターン
• クレデンシャルの短命化: 長期固定のAPIキーではなく、OIDC連携等による短命トークンへの移行。固定キーが避けられない場合は定期ローテーション
• 権限の最小化と利用監視: 用途単位でIDを分離し、通常と異なる使われ方を検知する

メールゲートウェイは「受信」の防御ですが、自社ドメインが詐称される側の対策も必要です。BEC（§1.3）は自社が踏み台・名義として使われる攻撃であり、顧客・取引先への被害は自社の信用問題になります。

• SPF / DKIM / DMARC: 送信ドメイン認証の整備。Google・Yahoo等の送信者要件により事実上の必須要件となっており、未対応だと自社の正規メールが届かなくなる段階に来ている。DMARCはまず監視モード（p=none）でレポートを収集し、段階的に隔離・拒否（p=quarantine / reject）へ移行する
• 類似ドメインの監視: 自社を装ったフィッシング用ドメイン（タイポスクワッティング）の検知、フィッシングサイトのテイクダウン依頼
• ドメイン・証明書の運用管理: TLS証明書の期限管理（自動更新化）、ドメインの更新漏れ防止（失効したドメインを第三者に取得されるドロップキャッチは、メール・サービスの乗っ取りに直結する）

• クラウドサービス採用時のセキュリティ評価基準（データ所在地、認証取得状況、契約条件）を定める
• 部門が勝手に契約するシャドーITを防ぐ申請・承認プロセス
• マルチクラウド利用時の統制の一貫性
• 生成AIサービスの採用時は、上記に加えてAI固有の評価項目（学習利用の有無、出力の権利帰属等）を確認する — チェックリストは §8.5 (3) を参照

アプリケーション本体だけでなく、コードを作る環境そのもの（リポジトリ、CI/CD、開発者の手元ツール）が攻撃対象になります。ビルド環境の侵害は成果物すべてを汚染するため（SolarWinds型の事案）、影響が特に大きい領域です。

folder_managedソースコード管理（Git / リポジトリ）

conveyor_beltCI/CDパイプライン

• ビルド環境・ランナーの保護（使い捨て化、パッチ適用）
• パイプラインに与える認証情報の最小権限化（本番デプロイ権限の分離、OIDC等による短命クレデンシャル）
• 依存取得元の統制（社内プロキシ・許可リポジトリ経由）、成果物の署名・検証

smart_toyAIコーディングエージェント利用時の統制（近年の重要論点）

開発者がAIにコードを書かせることが標準になりつつあり、§8.5（利用者としての生成AI統制）の開発者版として固有のリスクを扱う必要があります。

脆弱性への取り組みは性質の異なる2つの活動に分かれ、それぞれ適した実施体制が異なります。

外部委託が主流となる理由は、能力面だけでなく構造的なものです。

1. 第三者性が要件そのもの — 金融（FISC）、PCI DSS、官公庁案件、顧客へのセキュリティチェックシート回答等では「独立した第三者による診断」が求められる。自己診断は対外的な証明力を持たない
2. 稼働率の問題 — 手動診断の専門人材を常勤で抱えても、診断ニーズはスポットであり年間を通じて稼働が埋まらない。専門会社は多数の顧客で案件を回すことで成立している
3. 人材の希少性と陳腐化の速さ — 攻撃側の専門性は防御側スキルとは別物で市場に少なく、診断の実務から離れるとスキルが急速に陳腐化する
4. 成果物と品質保証 — 対外提出可能な報告書、標準化された診断方法論、責任分界までを含めて調達している

実務上の分業の目安:

• 内製: ツールによる継続的スキャンとパッチ適用（§12.2）。CI/CDへの組み込みで開発速度と両立させる
• 外部委託: 年次・リリース前の手動診断、第三者証明が必要な診断
• 中間形態: バグバウンティ（継続的な外部の眼）、大企業でのレッドチーム内製
• 今後の変化: AWS Security Agent（付録参照）のようなAIエージェント型のオンデマンド診断は、上記2（稼働率）・3（人材希少性）の制約を崩す位置づけであり、手動診断の一部が「AIによる内製実行」に移行していく可能性がある。ただし第三者証明が必要な領域（上記1）は引き続き外部委託が残る

生成AIに関する統制は、立場によって3つの視点に分かれます。

LLMを組み込んだアプリケーションには、従来のWebアプリ（OWASP Top 10、§9.2）とは異なる固有の攻撃面があり、OWASP Top 10 for LLM Applications として整理されています。代表的な論点は以下です。

• 個人情報保護法への対応（利用目的の特定、安全管理措置、漏えい時の報告義務）
• 保有個人データの棚卸しとマッピング
• 越境データ移転の管理（海外クラウド・海外拠点への移転）
• プライバシーポリシーの整備と本人対応（開示・削除請求）

「生成AIを導入したいが、先にセキュリティを整備したい」という要請に答えるための節です。導入前 → 導入時 → 運用 の時系列で整理します。

looks_one導入前①: 導入形態のスコーピング — まず「どのスコープか」を特定する

「生成AIの導入」はひとくくりにできず、形態によってリスクと自社の責任範囲が全く異なります。最初にやるべきは、検討中のユースケースが以下のどれに当たるかの特定です（クラウドの責任共有モデル §7.1 のAI版にあたる考え方）。

下に行くほど自由度が上がる代わりに責任範囲が広がります。スコープが決まれば、見るべきセキュリティ項目は自動的に絞れます。具体的には以下の通りで、下位スコープの項目は上位スコープにも累積して適用されます。

looks_two導入前②: 前提となる社内整備 — AI導入の「前」にやるべきこと

生成AI固有の対策以前に、既存の基礎統制が整っていないとAI導入がそれを増幅する点が最重要です。

• 情報分類の整備（§8.1）が最優先 — 「入力してよい情報」のルールは、情報が分類されていなければ運用できない。AI導入はデータ統制の前提整備を先に要求する

• アクセス権の棚卸し（§4） — 特に社内データに接続するAI（M365 Copilot型）では、「過剰共有の表面化」が頻出事故パターン: 全社リンク共有等で雑に共有されていたファイルは、従来「誰も探さないから見えなかった」だけであり、AIが横断検索して答えてしまう。導入前に共有設定・アクセス権の棚卸しを済ませることが先行条件
• ID基盤との統合（§4.2） — AIサービスもSSO・MFA配下に置き、退職時に確実に停止されるようにする
• ログ・監視への組み込み（§12.1） — 誰が何を入力したかの監査証跡を取得できる構成にしておく

looks_3導入前③: AIサービスの評価チェックリスト

クラウドサービス採用基準（§7.3）・委託先評価（§13.1）の共通項目に加え、AI固有の確認項目があります。

• 入力データがモデルの学習に使われないことの契約的保証（オプトアウトの明記。管理画面設定だけでなく契約条件として）
• データの保存場所（リージョン）・保持期間・削除可否、テナント分離の方式
• 出力の権利帰属、著作権侵害を巡る紛争時の補償（indemnification）の有無
• 監査ログをAPI・管理画面から取得できるか（§12.1のSIEMに取り込めるか）
• 認証取得状況 — SOC 2 / ISO 27001 に加え、ISO/IEC 42001（AIマネジメントシステム）というAI固有の認証も判断材料になりつつある
• サブプロセッサ（AI事業者がさらに利用する外部モデル・基盤）の開示

looks_4導入時: AIガバナンスの整備（§2との接続）

• AI利用ポリシーの策定 — §2.1のポリシー体系に組み込む（独立文書でも既存規程の改定でも可）
• リスクオーナーの明確化 — AI委員会またはセキュリティ委員会（§2.2）の所管に追加
• ユースケース単位の申請・承認プロセス — 全面禁止でも全面解禁でもなく、「用途 × 扱うデータの分類（§8.1）」の組み合わせで許可を出すのが実務的。禁止一辺倒はシャドーAIを生むだけで統制効果がない
• 参照フレームワーク — NIST AI RMF、ISO/IEC 42001。海外展開時はEU AI Act等の規制対応（§2.4）

looks_5運用: 利用時の継続的な統制

• 業務での生成AI利用ルールの周知（入力してよい情報の分類の明確化）と、AI利用リテラシー教育（§11.1）
• 機密情報・個人情報の入力禁止 or 学習に使われない法人向けサービスの利用（スコープ1 → 2への誘導）
• 出力の正確性（ハルシネーション前提の利用）・著作権リスクの確認プロセス
• 未許可AIサービス利用（シャドーAI）の可視化と統制 — CASB/SSPM（§7.2）によるSaaS可視化の一部として運用
• エージェント型ツールへの権限付与の統制 — 業務ユーザーがAIエージェントにメール送信・ファイル操作・社内データ接続の権限を与える場面が増えている。付与できる権限の範囲をあらかじめ定め、重要操作には人間の承認を挟む（開発者向けの同種の統制は§9.3、仕組み側の設計原則は§9.5）
• 定期的な利用状況・ログのレビュー（§12.1）

• BIA（ビジネス影響度分析）: 止められない業務の特定
• RTO（目標復旧時間）/ RPO（目標復旧時点）の設定
• ランサムウェアを想定した復旧演習（バックアップからの実際のリストア試験）
• 代替手段の準備（システム停止時の手作業運用等）

ポイント: バックアップは「取っている」だけでは不十分で、「実際に戻せるか」をリストア試験で確認して初めて対策になります。

経済産業省・国家サイバー統括室が2026年3月（令和8年3月）に「制度構築方針」を公表した、日本のサプライチェーンセキュリティ対策を標準化する新しい国主導の評価・認証制度です。運用主体（スキームオーナー）はIPA（情報処理推進機構）が担い、令和8年度以降に具体化・運用開始が進む見込みです。

stars制度の骨格 — ★の段階（★3・★4、★5は今後具体化）

対策水準を段階（★）で表し、上位は下位を包含する（★3を経ずに★4取得も可能）。

account_tree要求事項の構成（NIST CSFに準拠）

要求事項は NIST CSFの6機能（統治・識別・防御・検知・対応・復旧）に「取引先管理」を加えた7分類で整理されており、本資料§2〜§12の各領域とそのまま対応します。本資料の内容を実践していれば、★制度の要求事項の大半は自然に満たせる関係です。

• 特徴的なのは★4の「重要な取引先のセキュリティ対策状況の把握」で、これにより再委託先にも一定の対策が波及する設計（§13.1の「再委託の管理」を制度化したもの）
• ★4の技術検証では、インターネット公開機器（VPN装置・ルータ等）への脆弱性検査が課される（§12.2・§5.3のASM/公開資産管理と直結）

insights実務へのインパクト

• 発注側: 独自チェックシートの代わりに「取引先に★3/★4を求める」形に置き換えられ、評価コストが下がる
• 受注側（特に中小企業）: 取引先ごとに異なる要求から解放され、★を1回取得すれば複数の取引先に示せる。SECURITY ACTION（自己宣言）が★3・★4取得の準備段階に位置づけられている
• 既存制度（SECURITY ACTION、自工会・部工会ガイドライン、ISMS、英国Cyber Essentials）と相互補完・連携する方向で設計

自社で使用中の暗号方式のインベントリ整備と、ポスト量子暗号（PQC）への移行計画のことです。「今暗号化通信を収集しておき、量子計算機の実用化後に解読する（Harvest Now, Decrypt Later）」という攻撃を踏まえ、長期間秘匿が必要なデータを扱う場合（金融・防衛・医療等）は特に優先度が高い取り組みです。

どちらか一方に寄せるのではなく、以下の観点で領域ごとに判断するのが現実的です。

実務上の推奨アプローチ:

1. AWSネイティブをベースラインとして全アカウントで有効化（GuardDuty、Security Hub、CloudTrail、Config等）— クラウド基盤の可視性はネイティブでしか得られないものが多く、ここを省略してパートナー製品だけに頼るのはアンチパターン
2. AWSが守備範囲としない領域はパートナーで充足（端末、全社ID、メール、教育）
3. 重複領域（CSPM/CNAPP、SIEM等）は「運用する人」を基準に選ぶ — マルチクラウドの横断可視化や既存SOCとの統合が必要ならパートナー、AWS中心ならネイティブ集約でコストと運用をシンプルに
4. パートナー製品を選ぶ場合も、データソースはAWSネイティブ（CloudTrail、GuardDuty等）から取り込む構成が基本であり、両者は競合ではなく積み重ねの関係