静鉄の駅でこの広告を見かけた方へ。「契約書」と「Azure監査対応」は、もう別々に整える時代ではありません
静岡鉄道の駅で、山崎行政書士事務所の広告を見かけた方へ。
今回、全駅パネルを小沼みのりさん起用のデザインに変更しました。
けれど、この広告で本当にお伝えしたいのは、見た目の刷新だけではありません。
「契約書、どうする？」
この言葉に、私たちはもう一つの意味を込めています。
それは、
「その契約、規程、運用ルールは、AzureやMicrosoft 365の実際の構成と一致していますか？」
という問いです。
いま、監査で本当に見られるのは、書面の有無だけではありません。
権限管理が実装されているか。秘密情報が適切に守られているか。ログが残り、説明できるか。
つまり、法務・規程・クラウド構成・証跡が一つにつながっているかが問われます。
結論
NISTやISMSの監査対応で強い企業は、規程を先に作るだけでなく、Entra ID・Key Vault・監査ログまで“説明できる構成”に落としている企業です。
NIST CSF 2.0では、サイバーリスク管理を6機能で捉えます。ISMS側では、2022年版の管理策群が93 controlsとして整理され、Microsoft側でも Defender for Cloud の規制コンプライアンスで ISO/IEC 27001:2022 と ISO/IEC 27002:2022 が扱われています。
理由
監査で弱い環境には、共通点があります。
契約書には「権限は適切に管理する」と書いてある。
規程には「機密情報は厳格に管理する」と書いてある。
監査説明では「ログを取得している」と言っている。
ところが現場では、
グローバル管理者が常時付与のまま
Key Vault が旧来のアクセス ポリシー前提で運用されている
サインインログや監査ログの見方が定まっていない
いざというとき、誰が何を変更したか出せない
というズレが起きています。
Microsoft Entra の監査ログは、ユーザー、グループ、アプリ、ライセンス変更などの追跡可能なアクティビティを収集し、コンプライアンスに必要となることが多いシステムアクティビティレコードへのアクセスを提供するとされています。サインインログも、対話型だけでなく、非対話型、サービス プリンシパル、マネージド ID まで含めて確認対象になっています。
また、Key Vault では Microsoft はアクセス ポリシーより RBAC を推奨しており、旧来のアクセス ポリシー運用では、Contributor や Key Vault Contributor などが access policy を設定して自らにデータプレーンアクセスを与えられるリスクがあると明記しています。
つまり、監査対応で本当に重要なのは、
書いてあることではなく、
構成として証明できることです。
数字
監査観点で押さえるべき数字は、まずここです。
NIST CSF 2.0 は 6機能（Govern, Identify, Protect, Detect, Respond, Recover）です。
ISO/IEC 27002:2022 は 93 controls の構成です。
Microsoft Defender for Cloud の規制コンプライアンスでは、ISO/IEC 27001:2022 と ISO/IEC 27002:2022 が利用可能な標準として列挙されています。
NIST / ISMS Annex A マッピングで見る
Entra ID・Key Vault・監査ログの監査論点
以下は、情シス・監査対応担当者がそのまま会議に持ち込みやすい実務整理です。
なお、ISO規格本文の詳細な再掲は避け、監査実務での結び付け方に絞ります。
1. Entra ID は「権限統制」の中心である
監査で問われること
管理者権限は最小化されているか
承認なしの高権限常時付与が残っていないか
人だけでなく、アプリやサービス プリンシパルの権限も把握できているか
権限変更の履歴を追えるか
NIST CSF 2.0 との対応
Govern: 権限管理ルール、承認フロー、例外管理
Identify: どのIDにどのロールがあるかの棚卸し
Protect: MFA、条件付きアクセス、PIM、最小権限
Detect: 不審なサインインや権限変更の検知
Respond / Recover: 権限剥奪、緊急遮断、復旧手順
NISTの2.0では Govern が独立機能として追加され、ガバナンスを先頭で扱う構成になりました。これは、権限管理を単なる設定論ではなく、経営・統制の問題として扱うべきことを強く示しています。
ISMS Annex A での見せ方
Annex A 全文の逐語的な記載はここでは避けますが、実務上は以下の束で見せると通りやすいです。
アクセス制御
識別・認証情報の管理
特権アクセスの統制
ログ取得とモニタリング
役割分担と職務分離
実装で監査に強くなる項目
PIMで高権限を Eligible 化
Activate 時に MFA と理由入力を要求
条件付きアクセスで接続元・端末条件を制御
アクセスレビューで定期棚卸し
サインインログと監査ログを Log Analytics 側へ送る
Microsoft Entra の監査ログはアプリケーション、グループ、ユーザー、ライセンス変更などを記録し、サインインログは対話型・非対話型・サービス プリンシパル・マネージド ID を含むため、監査時に「誰が」「どの資格で」「何にアクセスしたか」を説明する中核になります。
2. Key Vault は「秘密情報管理」の中心である
監査で問われること
秘密情報へのアクセス権が限定されているか
アプリ運用担当と鍵管理担当が分離されているか
秘密情報の取得・削除・変更が追跡できるか
緊急時の誤削除対策があるか
NIST CSF 2.0 との対応
Govern: 鍵・秘密情報管理方針、担当分離
Identify: どのアプリがどのシークレットを使うかの把握
Protect: RBAC、マネージド ID、Purge Protection
Detect: 不審なシークレット取得・権限変更の監視
Respond / Recover: 鍵のローテーション、失効、復旧
ISMS Annex A での見せ方
機密情報保護
特権操作の統制
変更管理
ログ取得
バックアップ・復旧
実装で監査に強くなる項目
アクセス ポリシー前提から RBAC 前提へ移行
Contributor の範囲を厳格に絞る
シークレット参照にマネージド ID を優先
削除保護と復旧性を設定
取得・削除・権限変更の監査観点を決める
Microsoft Learn では、Key Vault 管理時はアクセス ポリシーではなく RBAC を使うことがセキュリティ強化につながると明示しています。また、Contributor 権限を持つユーザーが access policy を設定して自分にデータプレーンアクセスを与えるリスクを挙げ、厳格な管理を求めています。
3. 監査ログは「言った・言わない」を終わらせる証拠である
監査で問われること
ログは何をどこまで取得しているか
保持期間は十分か
監視だけでなく、後から追跡できるか
人の操作だけでなく、ワークロードIDやサービス プリンシパルも見えているか
NIST CSF 2.0 との対応
Identify: 何を監視対象にするか定義
Detect: ログから異常を見つける
Respond: 調査、封じ込め、報告
Recover: 再発防止、是正策の反映
Govern: 保持方針、責任者、エスカレーション
ISMS Annex A での見せ方
ログ記録
監視活動
インシデント対応
証跡保全
継続的改善
Entra 側では、監査ログが変更履歴の追跡に、サインインログが認証イベントの把握に使えます。NIST SP 800-61r3 でも、Govern・Identify・Protect が予防と準備、Detect・Respond・Recover が発見と対処に機能する、と整理されています。
実装で監査に強くなる項目
Entra 監査ログ／サインインログの取得対象を明確化
Log Analytics ワークスペースへ集約
Sentinel で重要イベントの分析・相関
保持期間とエクスポート方針を決定
監査対応時の抽出手順を運用化
監査で刺さる説明の仕方
情シスが監査で強くなるのは、ツール名を並べたときではありません。
「統制目的 → 実装 → 証跡」 の順で話せるときです。
例えば、こうです。
Entra ID
統制目的: 高権限の濫用防止
実装: PIM、MFA、条件付きアクセス、アクセスレビュー
証跡: 監査ログ、サインインログ、レビュー結果
Key Vault
統制目的: シークレットの不正取得防止
実装: RBAC、マネージド ID、権限分離、削除保護
証跡: 権限設定、操作ログ、変更履歴
監査ログ
統制目的: 変更・アクセス・異常の追跡
実装: ログ集約、保持、分析、報告フロー
証跡: ログ検索結果、アラート履歴、対応記録
この形に落とせると、NISTにもISMSにも説明が通しやすくなります。
逆に、
「MFA入れてます」
「Key Vault使ってます」
「ログもあります」
だけでは、監査では弱いのです。
山崎行政書士事務所が入る意味
ここで、法務と技術の橋渡しが効いてきます。
行政書士としては、
規程
台帳
役割分担
委託先管理
監査説明用の文書化
を整える。
Azureエンジニアとしては、
Entra ID
Key Vault
監査ログ
Sentinel
権限設計
運用証跡
を整える。
この両方が揃って初めて、
「監査に通る書類」ではなく、
「監査で説明できる実体」
になります。
最後に
静鉄の駅で見かける
「契約書、どうする？」
という一言は、いまや紙の契約だけを意味しません。
本当に問われているのは、
その契約、規程、運用ルールが、Entra ID・Key Vault・監査ログまで一致しているか
です。
NISTでも、ISMSでも、結局見られるのはそこです。
書類があることではない。
説明できる構成になっていること。
そこまで整えて、はじめて監査対応は強くなります。
まとめ
結論
NIST / ISMS監査対応で強いのは、規程とAzure構成を別々にせず、Entra ID・Key Vault・監査ログまでつないで説明できる企業である。
理由
NIST CSF 2.0 は6機能でリスク管理を整理し、ISMS 2022系は93 controlsで統制を詳細化している。Microsoft Learn でも、Entra ログは監査・コンプライアンス説明に有用であり、Key Vault は RBAC 推奨であることが示されている。
数字
NIST CSF 2.0 は6機能、ISO/IEC 27002:2022 は93 controls、Defender for Cloud の規制コンプライアンスには ISO/IEC 27001:2022 と ISO/IEC 27002:2022 が含まれる。
