【クラウド法務・セキュリティガバナンス週次ブリーフ】

結論から言うと、今週の重点は「AI・認証・委託先・クラウド設定変更」を、法務とセキュリティの両面で見直すことです。

対象は、Azure、Entra ID、Microsoft 365、Intune、Defender、Purview、Sentinel、Copilot／AIエージェントを利用する日本企業・自治体・委託事業者です。

理由は明確です。

クラウドのリスクは、もはや「サーバーが落ちる」「IDが漏れる」だけではありません。

・AIエージェントが社内データへアクセスする・OAuth連携アプリが正規APIで情報を取得する・Teams通話でIT担当者になりすまされる・IntuneやDefenderの仕様変更で運用スクリプトが止まる・改正個人情報保護法により委託先管理やデータ利用の説明責任が重くなる

このように、技術設定・契約・運用ルール・証跡管理が一体で問われる段階に入っています。

数字で見ると、今週確認すべき実務項目は大きく10件です。

1つ目は、改正個人情報保護法です。

確認できた事実として、改正個人情報保護法は2026年7月17日に公布されています。ただし、具体的な施行日、政令、個人情報保護委員会規則、改訂ガイドラインの最終内容は、現時点では確認できません。

したがって、今すぐ「改正法対応済み」と断定するのは危険です。

今やるべきことは、推測で規程を直すことではありません。

・個人データの所在・利用目的・委託先・再委託先・漏えい時の連絡経路・削除手順・CopilotやAI分析で使うデータ範囲

これらを棚卸しすることです。

クラウドに保存しているから安全、Microsoft 365を使っているから問題ない、という話ではありません。委託元として、どのデータを、誰に、何の目的で、どこまで処理させているのかを説明できる必要があります。

2つ目は、IPAの「情報セキュリティ10大脅威2026」です。

IPAが2026年7月23日に公開した組織編資料では、組織向け脅威として、ランサム攻撃、サプライチェーン・委託先攻撃、AI利用をめぐるサイバーリスクが重視されています。

特にクラウド利用については、契約前調査、インシデント時の責任範囲、停止時の代替策、仕様変更時の設定見直しが重要です。

これは非常に実務的です。

クラウドサービスは、導入した瞬間に終わるものではありません。

仕様変更があります。価格変更があります。API変更があります。認証方式の変更があります。委託先や再委託先の変更があります。障害時にログをどこまで出してもらえるかという問題もあります。

つまり、クラウド契約は「導入契約」ではなく「継続統制契約」として見る必要があります。

3つ目は、Defender for Cloudの推奨事項モデル変更です。

確認できた事実として、SQL Vulnerability Assessmentでは、各評価ルールがデータベースごとの独立した推奨事項として表示される方向に変わっています。旧来のグループ化された推奨事項は、2026年7月31日に非推奨となるとされています。

ここで注意すべきなのは、件数が増えたからといって、直ちにリスクが急増したとは限らないことです。

表示単位が変わると、ダッシュボード上の推奨事項数やCloud Scoreの見え方が変わります。経営報告で「脆弱性が急増しました」と誤って説明すると、実態と違う判断につながります。

Azure Resource Graph、継続的エクスポート、例外管理、ガバナンスルールで旧推奨事項IDを使っている場合は、7月31日までに確認が必要です。

4つ目は、Microsoft Sentinelの検知ルールのコード管理です。

Microsoft Sentinelのカスタム検知ルールを、GitHubやAzure DevOpsでコード管理し、Bicepなどで展開できる流れが進んでいます。

これは良い変化です。検知ルールにも、レビュー、承認、変更履歴、ロールバックを適用できるからです。

一方で、リスクもあります。

誤った検知ルールを自動展開すれば、検知漏れや大量誤検知が起きます。SOCのルール変更は、アプリケーションのコード変更と同じく、レビューとテストが必要です。

「検知ルールはセキュリティ担当者が画面で直すもの」から、「検知ルールもコードとして管理するもの」へ移っています。

5つ目は、Entra IDのパスキー移行です。

確認できた事実として、2026年9月1日から、SMSまたは音声認証が有効なユーザーに対し、パスキー登録が促される予定です。また、2027年2月1日には、Microsoft提供のSMS・音声配信が終了する予定とされています。

これは単なるMFA設定変更ではありません。

端末紛失時にどう復旧するのか。機種変更時に誰が本人確認するのか。外部委託者にパスキーを使わせるのか。役員や管理者の緊急アクセスをどう守るのか。break-glassアカウントをどう扱うのか。

ここまで含めて認証設計です。

SMS MFAは便利でしたが、今後はフィッシング耐性のある認証方式へ移る必要があります。

6つ目は、IntuneとOutlookの複数管理対象アカウント対応です。

確認できた事実として、Intuneのモバイルアプリケーション管理では、iOS／iPadOS版Outlookで、同一アプリ内に複数の管理対象アカウントを追加・管理できる機能が段階展開されています。

これは、MSP、コンサルタント、兼務者、グループ会社対応では便利です。

しかし、法務・セキュリティ上は慎重に見るべきです。

同じ端末、同じOutlookアプリの中で、複数テナントの業務データを扱うことになるからです。

確認すべきは、以下です。

・テナント間コピー・添付ファイルの扱い・共有先制御・通知表示・選択的ワイプ・個人アカウントとの境界・退職時や契約終了時の削除

便利な機能ほど、データ境界の確認が必要です。

7つ目は、Defenderの権限モデル変更とAIエージェント評価です。

確認できた事実として、新規のDefender for Office 365 Plan 2組織では、Defender Unified RBACが既定の権限モデルになります。ただし、Exchange Online PowerShellやSecurity & Compliance PowerShellは、引き続き別のロール体系を使用します。

ここは誤解しやすい点です。

管理画面が統合されても、権限が完全に一本化されたわけではありません。

Defender、Exchange、Purview、Entra ID、Intuneは、それぞれ権限体系が異なります。管理者に何を任せ、何を任せないのかを、サービス別に整理する必要があります。

また、AIエージェントの評価機能も進んでいます。

AIエージェントは、人間ではありません。しかし、データにアクセスし、処理を実行し、外部サービスへ接続する場合があります。

だからこそ、AIエージェントには次の台帳が必要です。

・所有者・作成者・利用目的・接続先・アクセス権・実行可能な操作・停止条件・削除手順・ログ確認者

AIガバナンスは、利用規程だけでは足りません。非人間IDの管理が必要です。

8つ目は、Teamsを使った音声フィッシングです。

Microsoft Threat Intelligenceは、2026年第2四半期に約76億件のメール型フィッシングを検知したとしています。また、Teamsを使った悪意ある音声通話は、2025年半ばの基準値の約10倍に達したと報告されています。

これはMicrosoftの観測値であり、日本全体の発生率ではありません。ただし、傾向としては重く見るべきです。

これまでの教育は「怪しいメールを開かない」が中心でした。

しかし今後は、それだけでは足りません。

「IT部門です」「アカウント復旧のためMFAを承認してください」「Teamsで画面共有してください」「このコマンドを実行してください」

こうしたチャットや音声通話も、攻撃経路になります。

社内ルールとして、IT部門がTeams通話だけでMFA承認や遠隔操作を求めないこと、本人確認は別経路で行うことを明文化すべきです。

9つ目は、CI/CDとnpmパッケージ侵害です。

Microsoft Securityは、AsyncAPI関連のnpmパッケージ侵害について報告しています。悪性コードはインストール時ではなく、モジュール読み込み時に実行されるため、npm install --ignore-scriptsだけでは防げないとされています。

さらに重要なのは、侵害された成果物に正規のプロベナンス署名が付いていた点です。

つまり、署名があるから安全とは限りません。正規リポジトリ由来だから安全とも限りません。CI/CD自体やリリースワークフローが侵害されれば、正規に見える悪性成果物が作られます。

確認すべきは、依存関係だけではありません。

・ロックファイル・SBOM・ビルドイメージ・共有キャッシュ・GitHub Actionsの権限・npmトークン・Azureクライアントシークレット・Kubernetes資格情報・CI/CDのOIDC連携

ソフトウェアサプライチェーンの法務・セキュリティ確認は、今後さらに重要になります。

10個目は、正規OAuth連携を悪用したSaaS侵害です。

Microsoftは、音声フィッシングによるOAuth同意取得や、信頼されたSaaS連携経路の侵害を報告しています。

攻撃者が正規APIと正規トークンを使う場合、通常の不正ログイン検知だけでは見逃す可能性があります。

これは非常に重要です。

「ログイン成功がないから安全」「MFAを突破されていないから安全」「SaaS連携は以前承認したから問題ない」

この考え方は危険です。

OAuthアプリは、承認後も継続的に監査する必要があります。

・誰が同意したのか・どの権限を与えたのか・最後に使われたのはいつか・所有者は誰か・不要になったら誰が失効するのか・委託先SaaSが侵害された場合に通知されるのか

これを管理しないと、正規の連携経路がそのまま情報流出経路になります。

まとめます。

今週の実務対応は、次のとおりです。

まず7月31日までに、Defender for Cloudの旧推奨事項IDを使うクエリ、例外、エクスポート、ダッシュボードを確認すること。

次に30日以内に、SMS・音声認証利用者を抽出し、パスキー移行計画を作成すること。

さらに、TeamsでのITサポート本人確認ルールを整備すること。

加えて、OAuthアプリ、AIエージェント、CI/CD発行権限、Intune管理対象アカウント、クラウド委託契約を台帳化すること。

最後に、改正個人情報保護法については、未確定の政令・規則を推測せず、個人データと委託関係の棚卸しを先行することです。

クラウド法務は、契約書だけでは完結しません。クラウドセキュリティは、設定画面だけでは完結しません。

Azure、Entra ID、Microsoft 365、Intune、Defender、Purview、Sentinel、Copilot。これらを安全に使うには、ID、端末、データ、委託先、AI、ログ、契約を一体で見る必要があります。

クラウド導入の本当のリスクは、使うことではありません。変化に気づかず、古い前提のまま運用し続けることです。

#クラウド法務#Azure#EntraID#Microsoft365#Intune#サイバーセキュリティ#個人情報保護法#AIガバナンス#ゼロトラスト#山崎行政書士事務所