【クラウド法務】NIS2 × Azureログ構成でトラブルになりやすい3つのポイント― Azure環境のログ・証跡を「技術」と「法務」の両面から見直す ―

導入：技術的には動いている。でも「NIS2的に大丈夫か」が誰も答えられない

クラウド環境の構築・運用は、ドキュメントも豊富で、技術的な情報は探せば見つかります。Azure についても、ログの種類や収集方法、Sentinel 連携など、技術ブログやMSドキュメントを読めば一通りは把握できるはずです。

しかし、全国の情シス・IT部門の方から相談を受けていると、次のような声を非常によく耳にします。

「NIS2 を意識して Azure のログ構成は組んだつもりだが、契約・法務リスクが整理できていない」「ベンダー任せで設計してしまい、障害時・インシデント時の責任分界が曖昧なまま稼働している」「欧州拠点から “このログ構成で NIS2 的に本当に大丈夫か” と聞かれても、社内で説明しきれない」

本記事では、「NIS2 × Azureログ構成 × クラウド法務」 という視点から、全国の製造業・IT企業の案件で実際に見えてきた「よくある落とし穴」と、実務で使える整理方法をご紹介します。

1. NIS2対応で、Azureログ構成は実際どう組まれているか（技術の“事実整理”）

まずは「技術構成の事実」を、ざっくり言語化しておきます。多くの企業での Azure ログ構成（NIS2を意識し始めた段階） は、次のようなイメージです。

• テナント構成

  • 親テナント：日本本社（Azure / M365 / Entra ID を集約）

  • 子テナント：欧州拠点・グループ会社用テナント もしくは サブスクリプション分割

• ID・認証まわり

  • Entra ID（旧 Azure AD）＋オンプレAD / 他IdP 連携

  • 条件付きアクセス・多要素認証・Privileged Identity Management（PIM）など

• ログ収集基盤

  • Azure Activity log / Resource log / Entra ID サインインログ / Audit log など

  • Azure Monitor → Log Analytics Workspace に集約

  • 一部は Microsoft Sentinel や外部 SIEM へ転送

• 保存場所・保持期間

  • Log Analytics：90日〜180日程度で設定

  • 長期保存用に Azure Storage / 外部アーカイブ製品 を一部併用

  • 欧州向けワークスペースを EU リージョンに分けているケースもあり

このあたりまでは、多くの企業で「技術構成図」として整理されていることがほとんどです。

しかし一方で、次のような “法務・契約の図” が存在しないケースが非常に多いのが実情です。

• NIS2 を意識したときに、「どのログを・どの期間・誰の責任で 保存・監視しているのか」

• ログの消失・不足・設定ミスがあったときの「クラウド事業者・ベンダー・自社それぞれの責任範囲」

• 日本本社と欧州拠点との間で「どのような合意（規程・契約）でログ・証跡を扱うのか」

ここまでは“技術構成”として整理された図がある一方で、「契約上・規制上、どこからどこまで誰の責任か」 という図が存在しないケースがほとんどです。

ここから先が「クラウド法務」の話になります。

2. 全国の案件で見えてきた「クラウド法務上の落とし穴」3選

代表的なものを3つだけ挙げると、次のようなパターンです。

① NIS2対応を「ログの有無の話」に矮小化してしまう

• 技術的にはOK

  • Activity log や Sign-in log を一通り有効化

  • Log Analytics で 90日〜180日の保持期間を設定

  • Sentinel でアラートルールも用意している

• 法務・規制的にはNGになりうる点

  • NIS2 で求められるのは「ログがあるかどうか」だけでなく、

    • インシデント検知・報告体制

    • 経営レベルでの説明責任

    • サプライチェーン・委託先も含めたリスク管理などを含む**“全体としての体制”**

  • 「Azure 上のログはあります」で説明を止めてしまい、経営層・欧州拠点・監督当局に対してストーリーとして説明できない。

② ログ保持期間・保存場所と契約・規程がバラバラ

• 技術的にはOK

  • 「コストもあるので、とりあえず Log Analytics は 90日だけ」

  • 長期保存は必要になったらバックアップの仕組みを検討

• 法務・規制的にはNGになりうる点

  • グループ内規程・取引先との契約・業界ガイドラインでは、1〜5年程度のログ・証跡保持を前提にしているケースが多い

  • 欧州拠点で採用しているセキュリティポリシーともズレており、「本社の Azure ログが 90日しか遡れない」ことがNIS2対応の監査で問題になる可能性がある。

③ 日本本社と欧州拠点で「誰がどこまで見る・持つか」が決まっていない

• 技術的にはOK

  • 日本本社テナントの Azure ログを、欧州拠点のセキュリティチームにも閲覧権限付与

  • もしくは、欧州側ワークスペースにミラーリングして監視

• 法務・規制的にはNGになりうる点

  • 個人データを含むログ（ユーザーID・IP・操作履歴など）について、

    • どこまでマスキング／最小化するか

    • どの国の拠点がどの粒度で参照できるのかが明文化されていない

  • 日本本社・欧州拠点・クラウド事業者の関係を前提にしたDPA（データ処理契約）・グループ内規程・委託契約が整理されておらず、監査やトラブル時に説明がつかない。

「技術的にはなんとか動いているが、NIS2 や GDPR を踏まえた契約・責任分界・社内規程の整理が追いついていない」——多くの企業で、このギャップが生じています。

3. NIS2 × Azureログ構成で、まず押さえるべき3つの整理軸

技術構成を大きく変える前に、最低限、次の3つを紙に落としておくと、その後のベンダー調整・社内説明が格段に楽になります。

① 誰がどのレイヤーを担保するか（責任分界表）

• クラウド事業者（Microsoft）

  • データセンターの物理的安全

  • プラットフォームとしての Azure / Entra ID / M365 の稼働

  • 提供されるログの仕様・SLA

• 構築ベンダー / 運用ベンダー

  • ログ設定・Sentinelルールなどの初期設計

  • 運用監視・一次対応・レポーティングの範囲

  • 重大インシデント発生時のエスカレーションフロー

• 自社（情シス / セキュリティ・基盤チーム）

  • ベンダー選定・仕様の最終決定

  • NIS2 / GDPR / 自社規程を踏まえた要件定義

  • 経営層・海外拠点への説明責任

• 事業部門 / 欧州拠点・子会社側

  • 現地規制との整合確認

  • ローカル手順（インシデント報告フローなど）の運用

  • 実務でのログ活用（調査・再発防止など）

Excel でも PowerPoint でも構いませんので、「誰が・どこまで・何を担保するか」 を一枚で見えるようにすることが重要です。

② どのログを、どこに、どの期間、誰の責任で保存するか

• 対象ログの整理

  • Azure Activity log

  • Resource log（各サービスの診断ログ）

  • Entra ID Sign-in log / Audit log

  • Sentinel / SIEM 側のイベントログ など

• 保存場所

  • Log Analytics Workspace（本番）

  • 長期保管用の Storage / 外部アーカイブ

  • EU リージョン／日本リージョンの使い分け

• 保持期間

  • NIS2 / 業界ガイドライン / 取引先契約 に基づいた年数（例：ログは最低 1〜5年、重要システムはそれ以上 等）

• 責任の割り振り

  • 「設定をミスったら誰の責任か」

  • 「保持期間満了後に削除する判断は誰が行うのか」

ここまでを “ログポリシー” として文書化 しておくことで、監査・取引先・経営層に対する説明が一気に楽になります。

③ 海外・グループ会社をまたぐときの「契約・規程」の整合性

• DPA（データ処理契約）の確認

  • Microsoft との DPA

  • 日本本社と欧州拠点の間のデータ処理に関する合意

• グループ内規程

  • セキュリティポリシー・ログ・証跡管理のルール

  • 個人データを含むログのマスキング・匿名化方針

• 委託契約・ベンダー契約

  • NIS2 / GDPR を踏まえた委託先管理条項

  • インシデント時の報告期限・報告内容・責任範囲

技術構成の検討と並行して、「契約書」「社内規程」「運用手順」 をAzure の実態に合わせてアップデートすることが、NIS2 対応としての“抜け漏れ防止”につながります。

4. ケーススタディ：製造業A社（売上1,000億円台、拠点12カ国）の場合

実際に当事務所でご相談を受けた事例の一つをご紹介します（業種等は匿名化しています）。

• 業種：製造業（BtoB）

• 売上規模：1,000億円台

• 拠点：日本本社＋欧州4カ国＋アジア7カ国

• テーマ：NIS2 を見据えた Azure / M365 / Entra ID 統合とログ構成の見直し

課題の整理

• ベンダーからは 技術構成図（テナント・サブスクリプション・ネットワーク）は出てくるが、契約・責任分界図 が存在しない

• 欧州拠点から NIS2 対応の一環として「ログをどこまで・どの期間・どのリージョンに保存しているか」の説明を求められるが、日本側で体系的に整理できていない

• ログ保持期間を「コストの観点だけ」で 90日にしており、監査部門から「これでは足りないのでは」と指摘を受けていた

当事務所の支援内容（抜粋）

• クラウド構成図と契約書のクロスチェック

  • Azure / M365 / Entra ID の構成図と、Microsoft との契約・既存のベンダー契約・DPA を突き合わせ

• 責任分界マトリクスの作成

  • クラウド事業者 / ベンダー（国内・海外） / 日本本社 / 欧州拠点 それぞれの役割を「平常時」「インシデント時」「監査対応時」に分けて整理

• ログ・証跡要件の整理と Azure 側設定案のレビュー

  • NIS2 を含む関連規制・業界ガイドライン・取引先要求をまとめ、「どのログを」「どの期間」「どこに保存するか」を方針化

  • それを前提に、ベンダーが提案した Azure ログ設定案をレビュー

• 海外子会社とのデータ取扱いルール（ドラフト）作成支援

  • 個人データを含むログの扱い

  • 日本本社・欧州拠点間のアクセス権限

  • インシデント報告・再発防止のフローなどを含むグループ内規程（ドラフト）を作成

結果として

• 監査部門・親会社・欧州拠点からの質問に、「技術構成」と「契約・規程」をセットにした一貫したストーリーで回答できるようになった

• ログ保持期間・保存場所・責任分界が明文化され、「技術はベンダー任せ、法務は総務任せ」という状態から脱却

• NIS2 対応をきっかけに、グループ全体のクラウド方針を見直す土台を整えることができた……といった声をいただいています。

5. NIS2 を意識して Azure を運用している企業が、今すぐ確認しておきたいチェックポイント

自社で検討を進める際のチェックリストとして、次の項目を挙げておきます。

• □ クラウド事業者・ベンダー・自社・海外拠点の責任分界図が1枚で説明できる

• □ Azureログ（Activity / Resource / Entra ID など）の保持期間が、　 NIS2・GDPR・契約・業界ガイドラインと整合している

• □ 日本本社・欧州拠点・グループ会社との　 ログ・証跡データの流れと契約（DPA・委託契約・グループ内規程）が対応している

• □ 障害・インシデントが起きたときの　 「誰が・どこまで・いつまでに・何をするか」 が文章化されている

• □ ベンダー任せの構成から脱却し、　 「自社としての NIS2 / クラウドセキュリティ方針」 を説明できる

すべて自信を持って「YES」と言える企業は、全国的に見てもまだ多くありません。

6. 全国からのご相談について

山崎行政書士事務所では、Microsoft Azure / Entra ID / M365 等の技術構成と、契約・規程・監査対応をセットで整理する「クラウド法務支援」 を行っています。

• ベンダーとの 責任分界 を、NIS2 / GDPR を踏まえて整理したい

• Azure ログ構成 が NIS2 の観点から十分かどうか、外部の目でチェックしてほしい

• 監査・親会社・欧州拠点・取引先からの質問に、一貫したストーリーで答えられるようにしたい

といったお悩みがあれば、オンライン（全国対応） にて初回のご相談を承っております。

👉 ご相談フォームはこちら

👉 お問い合わせの際に、「NIS2 Azureログの記事を見た」 と書いていただけるとスムーズです。