主なセキュリティガイドライン

山崎行政書士事務所
9月11日
読了時間: 13分

— NIST を中核とした国際標準の全体俯瞰と実務適用 —

著者：山崎行政書士事務所クラウド法務・アーキテクチャ支援チーム

発行日：2025-09-11

要旨（Abstract）

本稿は、**NIST（米国国立標準技術研究所）が公表する主要フレームワーク／SP 文書群を中核に、ISO/IEC 27001・COBIT・ITILなどの国際標準および日本国内ガイドライン（IPA／ISMAP／FISC／総務省）**を横断整理する。NIST CSF 2.0（2024）、SP 800‑171 Rev.3（2024）、SP 800‑63 Rev.4（2025）などの近年改訂点を反映し、Azure を含むクラウド環境に適用する際の実務勘所（暗号化・鍵主権・監査可能性・責任分界・証憑化）を、パラメータシートと導入フェーズの観点で提示する。

キーワード：NIST CSF 2.0、SP 800‑53/37/171/63/82、FIPS 140‑3、FedRAMP、ISO/IEC 27001、ISMAP、FISC、Azure、Evidence Pack

0. まず押さえる「近年の要アップデート」

・NIST CSF 2.0 …… 2024年正式版。新Function「Govern（統治）」が追加（計6機能）。
・SP 800‑171 Rev.3 …… 2024年最終版。CUI保護要求を改訂、評価書（800‑171A）も更新。
・SP 800‑63 Rev.4 …… 2025年最終版。デジタルIDの最新潮流を反映（MFA/属性/連携）。
・SP 800‑82 Rev.3 …… OT/ICS向けの最終版（制御系の安全・可用性と両立する防御）。
・FIPS 140‑3 …… 暗号モジュールの現行適合枠。140‑2は2026年までの経過取扱い。
・FedRAMP Rev.5 …… NIST SP 800‑53 Rev.5 ベースのクラウド評価基準へ完全移行。

1. NIST Cybersecurity Framework（CSF）

1.1 概要

2014年初版。CSF 2.0（2024）では機能が6つ（Govern / Identify / Protect / Detect / Respond / Recover）へ拡張。
組織の成熟度に応じて**目標状態（Target Profile）と現状（Current Profile）**を定義し、ギャップ是正を継続する。

1.2 Azure 実装の当てどころ（例）

Govern：クラウド規程、データ移転方針、責任分界、Azure Policyによる強制。
Protect：Key Vault（CMK/BYOK）、TLS 1.2/1.3、WAF/Firewall/Private Link。
Detect：Azure Monitor / Log Analytics / Microsoft Sentinelで相関検知。
Respond/Recover：SOAR（Playbook）とASR/Backup、DR 演習の定期化。

2. NIST Special Publication（SP）シリーズ（主流）

┌─────────────┬──────────────────────────────────────────────┬────────────────────────────────────┐
│ 文書           │ 目的/範囲                                     │ Azure 適用の主ポイント               │
├─────────────┼──────────────────────────────────────────────┼────────────────────────────────────┤
│ SP 800‑53 r5   │ 組織/システムのセキュリティ・プライバシー統制集  │ Policy/Templateにマッピング、監査証跡   │
│ SP 800‑37 r2   │ RMF：リスク管理の運用プロセス（選定→評価→監視） │ 変更管理/評価/再認定を運用に組込み       │
│ SP 800‑171 r3  │ CUI保護（非連邦組織向け要求）                   │ RBAC/PIM、鍵主権、ログ保持、接続分離     │
│ SP 800‑63 r4   │ デジタルID（MFA/ID保証/連携/セッション）         │ 条件付アクセス、IdP連携、MFA要件設計     │
│ SP 800‑82 r3   │ OT/ICS セキュリティ（安全性と防御の両立）         │ 制御系はゼロ停を優先、段階導入/監視設計   │
│ SP 800‑161 r1  │ サプライチェーン・リスク管理                     │ CSP/サードパーティの評価・追跡            │
│ SP 800‑52 r2   │ TLS 実装ガイド                                   │ TLS1.2/1.3、弱スイート排除、HSTS         │
│ SP 800‑53A r5  │ 53統制のアセスメント手法                         │ Evidence Packの試験手順/所見テンプレ      │
└─────────────┴──────────────────────────────────────────────┴────────────────────────────────────┘

3. その他 NIST ドキュメント・プログラム

FIPS 140‑3（CMVP）：暗号モジュール認証の現行枠。140‑2 は 2026 年に完全履歴化。
NICE Framework（SP 800‑181r1）：セキュリティ人材の職務・技能フレーム。
FedRAMP：米連邦向けクラウド評価。**Low/Moderate/High（SP 800‑53 r5）**の基準に準拠。

4. 日本の主なセキュリティ基準・ガイドライン

サイバーセキュリティ経営ガイドライン（経産省・IPA）：経営者の「重要10項目」。CSF と整合。
安全なクラウド利用のための手引き（IPA）：クラウド導入・運用の留意点を体系化。
ISMAP（政府情報システム向けクラウド評価制度）：日本版 FedRAMP。公共調達の前提一覧。
FISC 安全対策基準：金融機関の実装要件。クラウド利用時もログ・暗号・運用統制が重点。
総務省/経産省の IoT 関連ガイド：設計段階からのSecurity by Designとアップデート体制を要求。

5. マッピングと導入ステップ（実務）

5.1 規格→クラウド実装のマトリクス（要約）

NIST CSF「Govern/Identify」→ 管理規程・データ移転台帳・Azure Policy（リージョン/公開禁止）
NIST SP 800‑53（AC/SC/AU等）→ Entra ID（MFA/CA/PIM）、Key Vault(CMK/BYOK)、Log/Audit/WORM
NIST SP 800‑171 r3         → CUI境界分離、Private Link、最小権限、監査証跡、改ざん耐性保持
FIPS 140‑3                  → HSM/暗号モジュールの適合性確認、140‑2の経過措置を把握
ISMAP                        → 公共向けクラウド選定（登録サービス優先）、監査パッケージ整備
FISC                          → ログ長期保管、鍵管理、変更管理、外部委託統制（SOC報告/監査）

5.2 導入フェーズ（成熟度別）

Baseline：TLS1.2/1.3、TDE/既定暗号、MFA、Activity/Diagnosticsの集約と保持設計
Advanced：Key Vault CMK/BYOK、Private Link、Sentinel相関検知、Blob WORM/アーカイブ
Mission‑Critical：HSM + 二重暗号化、mTLS/ゼロトラスト分離、DR演習、RMF運用（再評価/再認定）

6. 実装チェックリスト（監査に効く最小セット）

鍵主権：Key Vault（CMK/BYOK）、ローテ ≤ 12M、Wrap/Unwrap/Sign の最小権限。
ID 強化：Entra ID の MFA＋条件付きアクセス／特権は PIM（JIT/承認/記録）。
通信・境界：TLS1.2/1.3、WAF Prevention、Private Link／必要に応じ mTLS。
ログ：Activity／Sign‑in／診断ログを集中保管、WORM＋アーカイブ、検索クエリを定義。
規格マッピング：CSF/800‑53/171/ISMAP/FISC を Evidence マトリクスに反映。
DR/通知：72h ルールを想定した初動 Runbook と DR 演習（RTO/RPO 実測）。

7. 山崎行政書士事務所のご支援（PR）

法務（APPI/GDPR/SCC/ISMAP/契約）× 技術（Policy/IaC/Key Vault/Sentinel/ASR）を同一の設計書と Evidence Packで束ね、監査にそのまま出せる品質で納品します。

要件整理→設計→実装→証憑化をワンストップ。
NIST/ISO × 国内（ISMAP/FISC）の対照マトリクス・問答集を付与。
90日ロードマップで Baseline を立ち上げ、Advanced/Mission‑Critical へ段階拡張。
金融・医療・製造など高規制業種の実績を、テンプレとチェックリストで再現可能に。

ご相談の流れ

初回ヒアリング → 2) 現状診断（規格×運用×法務） → 3) 実装・運用化 → 4) 定期レビュー（法改正/新機能反映）

参照リンク集（べた貼り・本文にはリンクを置かない運用）

※公式原典・制度サイトを中心に掲載しています。

Wix 貼り付けメモ

本文にリンクを置かず、上記「参照リンク集」のみに URL を集約。
表は貼り付け後に等幅（コード）スタイルへ切替えると崩れにくくなります。
長文は見出し（H2/H3）と箇条書きで区切り、モバイル閲覧の可読性を確保。

（根拠メモ：ブラウズ確認済みポイント — ブログ本文に含めなくて構いません）

CSF 2.0 は 2024/02/26 公開、6 Functions（Govern 含む）。 NIST CSRC
SP 800‑171 Rev.3（最終版）は 2024/05 公開、評価ガイドも更新。 NIST CSRC+1
SP 800‑63 Rev.4 は 2025/07 公開。 NIST Pages+1
SP 800‑82 Rev.3 は最終版（2023）。 NIST CSRC
FIPS 140‑3 / CMVP：140‑2 新規受付終了、140‑2 は 2026/09/21 まで有効扱い。 NIST CSRC+1
FedRAMP：Rev.5（SP 800‑53 r5）への移行ガイド。 fedramp.gov
ISMAP：制度概要と英語版イントロ資料。 ismap.go.jp +1
サイバーセキュリティ経営ガイドライン v3.0 と IPA プラクティス。 Ministry of Economy, Trade and Industry+1
FISC：最新版 PDF 案内／各版の提供ページ。 FISC 金融情報システムセンター+1
IPA/中小向けクラウド手引き、IoT 製品向け対策ガイド。 Japan Patent Office+1

必要に応じ、貴社の業界規制（金融・医療・公共等）とNIST/ISO/国内制度の対照マトリクス、Evidence Pack（設計書・台帳・KQL/Runbook）まで即時カスタマイズし、監査可能性と実装容易性を両立させます。

あなた:

上記をもっと詳細に文章で上級者向けに書いて下さい

ChatGPT:

GPT-5 pro に対するリクエスト

Reasoned for 6m 10s

以下は Wix のブログにそのまま貼り付けやすい体裁（見出し／段落中心・箇条書き最小・ASCII 表あり）で整えた、上級 SE 向け・長文／論文調の原稿です。本文中にはリンクを一切置かず、末尾に**「参照リンク集（べた貼り URL）」**のみを掲載しています。

主なセキュリティガイドライン

— NIST を核に、ISO・国内制度と連動させるエンタープライズ実装論 —

著者：山崎行政書士事務所クラウド法務・アーキテクチャ支援チーム発行日：2025-09-11注記：本稿は一般情報の提供であり、個別案件に対する法的助言ではありません。

0. 序論：フレームワークは“設計言語”、規格は“検収仕様”

企業の情報セキュリティを中長期で運用するには、フレームワーク（設計言語）と規格・制度（検収仕様）を同一の設計書に落とし込む必要がある。

設計言語：NIST CSF 2.0（組織の姿勢・ガバナンス／運用の方向性を定める）
検収仕様：NIST SP 800‑53（統制カタログ）、SP 800‑171（CUI 要求）、FedRAMP（クラウド評価）、FIPS 140‑3（暗号モジュール）
相互運用：ISO/IEC 27001:2022（マネジメント体系）、国内ガイドライン（ISMAP／FISC／IPA）（公共調達・金融監督・実務ガイダンス）

本稿は、これらをリスクベースかつ監査可能性を担保するかたちで束ね、Azure 等のクラウド実装に落ちるレベルまで踏み込んで解説する。

1. NIST CSF 2.0：6 機能体制の「運用オペレーティング・システム」

CSF 2.0は、従来の 5 機能（Identify/Protect/Detect/Respond/Recover）に**Govern（統治）**を追加し、経営・法務・IT を接合する骨格となった。ポイントは 3 つ。

Govern の中核：リスク受容基準、役割責任、サプライチェーン、法的義務（越境移転・72 時間報告等）を方針→手順→証跡の階層で明文化する。
Profile/Tier：現状 Profile と目標 Profile を差分管理し、Tier（組織成熟度）を監査 KPIと連動させる。
情報資産→データ流→統制配置：クラウドではデータの所在（Residency）と鍵主権を最初に決め、そこからネットワーク・ID・ログ・DR を逆算する。

Azure 実装の勘所：Azure Policyでリージョン制限・Public アクセス拒否・タグ（データ分類/Residency/Owner）を強制。**Key Vault（CMK/BYOK）**で鍵主権を確立し、Monitor/Sentinelで検知と証跡運用を回す。ASR/Backupで Recover を演習まで組み込む。

2. NIST SP 800‑53 Rev.5：統制カタログの「部品表（BOM）」

SP 800‑53 r5は統制（Controls）を AC/SC/AU/CM/CP/IR/MA/PE/PL/PM/RA/SA/SI 等のファミリで定義し、組織横断の一貫運用を前提にしている。実装は次の 4 層で考えると破綻しにくい。

方針層（PL/PM）：情報セキュリティ方針、データ移転方針、契約（DPA/SCC）を設計書にリンク。
構成層（SC/AC/CM）：TLS1.2/1.3、Private Link、ネットワーク分離、RBAC/PIM、IaC による再現性。
運用層（AU/IR/CP）：ログ一元化（LA/Sentinel）、SOAR 初動、DR 手順の演習・記録。
供給網層（SA/RA/SR）：サプライヤの統制適合性・脆弱性修正 SLA・監査証憑の取得。

Azure マッピング例（抜粋）AC：Entra ID（MFA/条件付きアクセス）、PIM（JIT）／SC：AppGW(WAF)/TLS/Private Link／AU：Activity＋診断ログ→Log Analytics、Blob WORM で改ざん耐性／CM：Azure Policy＋Bicep/Terraform／CP：ASR/GRS、RTO/RPO の実測記録／IR：Sentinel＋Logic Apps

3. RMF（SP 800‑37 r2）：Prepare→Categorize→Select→Implement→Assess→Authorize→Monitor

RMFは「コントロールを“選んで終わり”」を禁止する。

Prepare：組織体制・役割・データ分類・依存関係（クラウド/サードパーティ）を整備。
Categorize：FIPS 199による影響度（機密性/完全性/可用性）区分。
Select：SP 800‑53からベースラインを選定し、テーラリング（追加・削除・強化）。
Assess/Authorize：SP 800‑53Aの試験手順で検証→是正計画（POA&M）→稼働認可。
Monitor：設定・脆弱性・アラート・インシデントの継続監視と再認可。

FedRAMP は RMF の具体化（クラウド評価制度）。Rev.5 への完全移行により、SP 800‑53 r5 ベースで Low/Moderate/High を要求。既存クラウドの運用も、テンプレ／証憑一式（SSP/POA&M/コンティニュアスモニタリング）に沿って維持する発想が重要。

4. SP 800‑171 r3：CUI（Controlled Unclassified Information）の保護

CUIを非連邦組織が扱う際の必須要求。r3 では要求の再編が行われ、**53 系に基づく評価手順（800‑171A）**で適合性を立証する。

焦点：アクセス制御・暗号化・境界分離・監査・構成管理・媒体保護。
実務：Private Linkで東西分離、CMK/BYOKで鍵主権、PIMで特権最小化、WORM＋アーカイブで長期保持と改ざん耐性。
サプライチェーン：再委託先（SaaS・運用委託）の統制証憑をチェーンで取得する。

5. SP 800‑63（Digital Identity）第 4 版の要点

IAL/AAL/FAL（本人確認・認証・フェデレーションの保証レベル）を、リスク・利用者体験・プライバシーの三点で再整理。

AAL：MFA 義務化の適用範囲、フィッシング耐性（FIDO2/CTAP/WebAuthn）へ比重。
設計指針：条件付きアクセスでリスクに応じた追加要件を出し分け、セッション管理の厳格化（再認証・トークン無効化）を盛り込む。

6. SP 800‑82 r3（OT/ICS）：可用性と防御のトレードオフ設計

OT（制御系）はゼロ停止の要請が強く、IT のプリンシプルを直接適用できない場合がある。r3 は監視・分離・変更管理の厳格化を前提に、

産業プロトコルの特性（ベンダ固有・平文多い）を踏まえた境界制御
監視の遅延/ノイズと誤遮断のバランス
安全計装（SIS）との責任分界を体系化する。クラウド連携はデータダイオード／ミラー／遅延収集など、安全側に倒す実装指針が基本となる。

7. SP 800‑161（SCRM）と第三者リスク

サプライチェーンの可視化・証憑・残留リスクを、契約・監査・技術統制で一貫管理する。

契約：監査協力・脆弱性開示・ログ保全・越境移転・下請け届出。
技術：SBOM／署名検証／コード由来の証跡、脅威インテリジェンスとの連動。
運用：年次再評価＋重大変更時の臨時レビュー。

8. SP 800‑52 r2（TLS）と暗号スイートの実務

TLS 1.2/1.3 のみ許可、レガシー暗号・圧縮・再交渉は無効化。HSTS、OCSP Stapling、鍵のローテーション周期と証明書失効テストまでを Runbook に含める。

9. FIPS 140‑3（CMVP）：暗号モジュールの検収ライン

140‑3は暗号モジュールの現行適合枠。140‑2は新規受理終了済で、2026/09/21以降は履歴リスト扱い（既存用途に限定）。

実務：HSM/Key Vault の FIPS 適合を調達要件に含め、暗号境界・鍵ライフサイクル（生成・配布・廃棄）を設計書に明記する。

10. ISO/IEC・COBIT・ITIL とのアラインメント

ISO 27001:2022（Annex A 93 コントロール）と SP 800‑53は高い重複がある。

ISOはマネジメントと監査適合の骨格、NISTは技術統制の粒度。
COBITはガバナンス（価値・リスク・資源）、ITILは運用（変更・インシデント）を補う。
実務ではマトリクスで目的→統制→証跡を一行で紐付け、監査・再設計・教育に再利用する。

11. 日本の枠組み：ISMAP／FISC／IPA

ISMAP：公共調達の前提。登録クラウドを優先採用し、SSP・脆弱性運用・監視連携を制度様式に合わせると効率的。
FISC 安全対策基準：金融の長期ログ保全・鍵主権・外部委託統制が焦点。クラウド利用時も改ざん耐性（WORM）とDR 証跡が重視される。
IPA：サイバーセキュリティ経営ガイドライン v3.0は経営への要請整理、クラウド手引きは導入・運用の実務観点。OT/ICSのクラウド活用ガイドも参照価値が高い。

12. 実務マッピング：規格→クラウド統制→証跡（抜粋）

┌─────────────┬─────────────────────────┬────────────────────────────────┬────────────────────────┐
│ 目的/規格         │ 統制（例）                 │ クラウド実装（例：Azure）           │ 証跡（Evidence）         │
├─────────────┼─────────────────────────┼────────────────────────────────┼────────────────────────┤
│ CSF Govern        │ 組織・役割・移転方針        │ Policy/テンプレ/契約（DPA/SCC）     │ 規程/台帳/契約/承認ログ   │
│ SP 800‑53 AC/SC   │ 最小権限/通信防御           │ Entra(MFA/CA/PIM) / TLS / PL        │ 役割台帳/SSLポリシー      │
│ SP 800‑53 AU      │ 監査ログ/保持/改ざん耐性     │ Activity＋診断 → LA、Blob WORM      │ 保持設定/KQL/改ざん証跡    │
│ SP 800‑53 CP/IR   │ DR/インシデント対応          │ ASR/Backup、Sentinel＋SOAR           │ 演習記録/RTO・RPO 実測     │
│ SP 800‑171        │ CUI 境界/鍵主権/分離         │ Private Link、Key Vault（CMK/BYOK）  │ 171A 評価票/設定エビデンス │
│ FIPS 140‑3        │ 暗号モジュール適合           │ HSM/Key Vault 証明                  │ CMVP 証憑/設定書           │
│ ISMAP/FISC/IPA    │ 制度準拠/金融統制/実務       │ ISMAP 登録 CSP／WORM／DR演習         │ 制度様式／ログ保全報告     │
└─────────────┴─────────────────────────┴────────────────────────────────┴────────────────────────┘

13. 導入フェーズと KPI（監査対応まで一気通貫）

Baseline（0–90 日）：TLS1.2/1.3、TDE/既定暗号、MFA、診断ログ集約、タグ強制、Evidence Pack 雛形Advanced（90–180 日）：Key Vault CMK/BYOK、Private Link、Sentinel 相関検知、Blob WORM、POA&M 運用Mission‑Critical（180 日〜）：HSM＋二重暗号化、mTLS、ゼロトラスト分離、DR 四半期演習、RMF 再認可

KPI 例