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

Azure・Entra ID・Microsoft 365・Intune・AIを取り巻く重要動向10選

基準日：2026年8月23日

結論

今週、日本企業が優先して確認すべきテーマは5つあります。

第一に、個人情報保護委員会が8月19日に公表した行政上の対応から、クラウドや外部サービスへ処理を委ねても、安全管理措置を「委託先任せ」にしてよいわけではないことを改めて確認すること。

第二に、2026年9月1日に始まるMicrosoft Entra IDのパスキー自動有効化へ備えること。

第三に、8月26日に意見募集が締め切られる重要インフラの「安全基準等策定ガイドライン（案）」を確認し、クラウド委託契約や事故報告、ログ、再委託、復旧体制との差分を把握すること。

第四に、9月14日のAzure Monitor HTTP Data Collector APIサポート終了、9月30日のEntra Connect同期停止期限へ向け、移行状況を具体的に点検すること。

第五に、Copilot、MCP、AIエージェントについて、利用規程や台帳管理だけで終わらせず、Intune、Microsoft Defender、Microsoft Sentinelなどを使った技術的な実行制御まで進めることです。

今週取り上げる重要項目は10件です。内訳は、日本政府・公的機関3件、Microsoft公式6件、主要セキュリティベンダー1件です。

いずれにも共通しているのは、クラウドガバナンスの重心が「設定しているか」から、実際に強制できるか、証跡を残せるか、事故時に説明できるかへ移っていることです。

1．個人情報保護委員会がKDDI等へ指導――安全管理措置を「委託先任せ」にしない

2026年8月19日、個人情報保護委員会は、KDDI株式会社および一部のインターネットサービスプロバイダに対し、個人情報保護法に基づく行政上の対応を行いました。

事案の発端は、KDDIが複数のプロバイダ向けに提供していたメールシステムです。

2026年6月17日、このシステムを構成するソフトウェアの脆弱性を悪用した不正アクセスにより、メールサービス利用者のID、すなわちメールアドレスとパスワードの漏えいが発覚しました。

個人情報保護委員会の公表資料によれば、漏えいが確認された認証情報に関係する本人は1,223万1,954人。そのうち761万6,173人分のパスワードが平文のまま保存されていました。

個人情報保護委員会は、大量の個人データを扱い、多数のパスワードを平文で保存していたというリスクを踏まえれば、攻撃者の侵入後の横展開を防ぎ、被害を最小限にするための多層的な対策が必要だったとしています。

しかし実際には、そうした事情に応じたアクセス制御等が十分ではなく、技術的安全管理措置に不備が認められたとして、KDDIへ個人情報保護法第147条に基づく改善指導を行いました。再発防止策等については、2026年10月19日までの報告も求めています。

クラウド利用企業にとって何が重要か

この事案はAzureやMicrosoft 365そのものの事故ではありません。

そのため、「Microsoftクラウドにも同じ問題がある」と読み替えることはできません。

一方、企業のクラウドガバナンスを考える上では非常に重要な示唆があります。

実務上の推論として、外部サービスへシステム運用やデータ処理を委託したとしても、委託元が安全管理措置の実効性を考えなくてよいわけではありません。

契約書に「適切なセキュリティ対策を実施する」と記載するだけではなく、認証情報をどのように保存しているのか、特権アクセスはどのように管理されているのか、侵害後の横展開をどう防止するのか、再委託先は誰なのか、重大事故発生時に何時間以内に連絡されるのかまで確認する必要があります。

また、個人情報保護委員会は、漏えいした認証情報と同一または類似するパスワードを他サービスでも使い回している場合、リスト型攻撃による二次被害のおそれがあるとして注意を呼び掛けています。

Entra IDやMicrosoft 365を利用する企業に置き換えれば、パスワード依存を下げ、フィッシング耐性のある認証へ移行することの意味が一段と大きくなります。

出典：個人情報保護委員会、2026年8月19日個人情報保護委員会の公表資料

2．Entra IDは9月1日からパスキーを自動有効化

Microsoft Entra IDでは、認証方式の大きな変更が目前に迫っています。

Microsoftの現行公式資料によれば、2026年9月1日から、SMSまたは音声認証が有効なユーザーについて、パスキーが自動的に有効化されます。

対象にはAuthentication Methods PolicyでSMS・音声を有効にしているユーザーだけでなく、従来のMFA設定で有効化されているユーザーも含まれます。

対象ユーザーはパスキーを利用できるポリシーへ自動的に含まれ、Registration CampaignもMicrosoft Managedの状態となります。

その後、ユーザーがサインインしてMFAを完了すると、パスキー登録を促す画面が表示されます。既定では、この登録案内は何度でも先送りできます。

さらに重要なのが2027年2月1日です。

この日以降、Microsoft自身が提供するSMS・音声認証の通信配信は終了します。

SMSまたは音声しかMFA方法を持っていない利用者は、継続してアカウントへアクセスするため、サインイン中にパスキーを登録する必要があります。

この2027年2月1日の動作についてはオプトアウトできません。

9月1日は「設定変更」ではなく変更管理の日

実務上、最も注意したいのは、これを単なるセキュリティ機能の追加として扱うことです。

9月1日以降、利用者の画面にこれまで表示されなかったパスキー登録案内が出る可能性があります。

情シスにとって必要なのは、対象人数を事前に把握し、Windows、iPhone、Androidなど端末別の登録方法を説明し、端末紛失、機種変更、故障、退職時の復旧方法まで整理することです。

また、役員、外部委託者、共有端末利用者、特殊な業務端末など、通常のパスキー運用が難しい利用者も洗い出す必要があります。

Microsoftは、9月1日から2027年2月1日までの自動移行について一時的なオプトアウトを用意していますが、これは恒久的な回避策ではありません。

つまり、今後半年でSMS・音声依存からフィッシング耐性のある認証へ移行することが、Entra ID運用の大きなテーマになります。

出典：Microsoft Learn、2026年8月10日更新Passkeys by default and retirement of Microsoft-provided SMS and voice authentication

3．重要インフラ「安全基準等策定ガイドライン（案）」は8月26日締切

2026年8月5日、内閣官房国家サイバー統括室は、「安全基準等策定ガイドライン（案）」について意見募集を開始しました。

受付期限は2026年8月26日23時59分です。

背景には、2026年7月31日に決定された「重要インフラのサイバーセキュリティ対策のための統一基準」があります。

国家サイバー統括室によれば、これまでは分野や事業者によってサイバーセキュリティ対策の水準にばらつきがあったことから、重要インフラ事業者等が分野横断的に実施すべき対策について統一的な基準が設けられました。

今回のガイドライン案は、所管省庁や各重要インフラ分野の業界団体等が、それぞれの安全基準等を策定する際に参照するための詳細事項を示すものです。

Azure運用会社やMSPも無関係とは限らない

現時点で、すべての一般企業へこのガイドラインが直接適用されるとは確認できません。

また、ガイドラインはまだ「案」であり、最終内容も確定していません。

ただし、実務上の推論として、重要インフラ事業者を顧客に持つMSP、SOC、クラウド運用会社、システム開発会社、保守会社には、契約や調達要件を通じて要求が波及する可能性があります。

特に確認したいのは、事故報告、ログ提供、監査権、再委託、アクセス管理、BCP、復旧支援です。

契約書には報告義務があるのに、SOCから必要なログを取得できない。

復旧支援義務があるのに、RTOや復元試験が決まっていない。

再委託条項はあるものの、実際の再委託先を把握していない。

こうした「契約と実運用のずれ」を、最終版公表前から洗い出しておくことに意味があります。

出典：内閣官房 国家サイバー統括室、2026年8月5日安全基準等策定ガイドライン（案）の意見募集

4．8月Microsoft月例更新――悪用確認済みCVEにIPAが「至急更新」

2026年8月12日、Microsoftの月例セキュリティ更新が公開されました。

IPAは同日、「Microsoft製品の脆弱性対策について（2026年8月）」を緊急情報として掲載しています。

その中でも特に注意が必要なのが、CVE-2026-68820です。

IPAによれば、Microsoftはこの脆弱性について既に悪用の事実を確認しており、「今後被害が拡大するおそれがある」として、至急セキュリティ更新プログラムを適用するよう求めています。

CVE-2026-68820は、WinSock用Windows Ancillary Function Driverの特権昇格脆弱性です。

Intuneでは「配信したか」ではなく「適用されたか」を見る

IntuneやWindows Autopatchを利用している組織では、「自動更新を設定しているから対応済み」と判断しないことが重要です。

更新リングで延期している端末、長期間オフラインになっている端末、再起動待ちの端末、例外ポリシーへ入っている端末などは、更新されていない可能性があります。

管理者端末や開発端末など高い権限を持つ端末については、一般端末より優先的に実適用状況を確認することも検討すべきです。

これは実務上の推論であり、個別端末が侵害されていることを意味するものではありません。

個別環境の影響有無は、OSバージョン、適用済み更新、EDRログなどを確認する必要があります。

出典：IPA、2026年8月12日Microsoft製品の脆弱性対策について（2026年8月）

5．Entra Connectは9月30日までに更新――「最低版へ上げれば終わり」ではない

Microsoftは、Microsoft Entra Connect Syncについて、2026年9月30日までに少なくともバージョン2.5.79.0へ更新しなければ、すべての同期サービスが停止すると明記しています。

期限までに更新できなかった場合、更新するまで同期サービスは失敗し続けるとされています。

Entra Connectは単なるディレクトリ同期ソフトではありません。

多くのハイブリッド環境では、オンプレミスActive Directoryでユーザーを作成・変更・無効化し、その結果をEntra IDへ同期しています。

そのため同期停止は、退職者の無効化、グループ変更、属性変更、パスワード関連処理など、IDライフサイクルそのものへ影響します。

2.5.79.0は「ゴール」ではない

さらに注意したいのは、2.5.79.0そのものも、Microsoftのリリース履歴では2026年10月23日にサポート終了予定とされていることです。

したがって、9月30日の最低条件だけを満たすために2.5.79.0へ上げるのではなく、現時点でサポートされているより新しいバージョンへ更新することを検討した方が合理的です。

確認対象は本番サーバーだけではありません。

ステージング、DR、過去に残した旧サーバー、カスタム同期ルール、構成ファイル変更なども含める必要があります。

Microsoftは、古い環境からの更新では.NET Framework 4.7.2やTLS 1.2などの最低要件にも注意するよう案内しています。

更新後は「サービスが起動した」で終わらせず、ユーザー作成、属性変更、グループ変更、ユーザー無効化まで実際に同期試験を行うことが重要です。

出典：Microsoft Learn、2026年8月23日確認Microsoft Entra Connect Upgrade guidance

6．Azure Monitor――8月31日と9月14日の二つの期限を混同しない

Azure Monitorでは、二つの異なる変更期限があります。

まず、Log Analytics Workspaceとcustomer-managed storage accountの連携です。

Microsoftは、2026年8月31日以降のある時点から、saved queriesおよびsaved log alert queries用のlinked storage accountを新規追加または更新する場合、Log Analytics WorkspaceへManaged Identityを割り当てることを必須とする予定です。

公式文書では「no earlier than August 31, 2026」とされているため、8月31日ちょうどに必ず強制されると断定するのではなく、8月31日以降に強制が開始される可能性へ備えるという読み方が正確です。

Managed Identityには、対象Storage AccountでStorage Table Data Contributorの権限が必要とされています。

もう一つは、legacy HTTP Data Collector APIです。

こちらは2026年9月14日にサポート終了します。

ただしMicrosoftの現行移行ガイドでは、TLS 1.2以上に対応した既存クライアントについては、9月14日以降もingestion自体は継続すると明記されています。

一方、APIへ提供されるのは重要なセキュリティ修正のみとなり、MicrosoftはLogs Ingestion APIへの移行を推奨しています。

「ログが届いているから大丈夫」が危険

ここで注意すべきなのは、9月14日を過ぎてもログが届く可能性があることです。

技術的に動作していることと、サポートされた設計であることは同じではありません。

Logs Ingestion APIではData Collection Ruleを利用し、Microsoft Entraによる認証やDCR単位のRBACを利用できます。

Sentinelを含め、旧Data Collector APIへ依存したカスタム連携を持つ企業では、送信スクリプトだけでなく、テーブル、クエリ、Analytics Rule、Workbook、Parser、Playbookなどへの影響も確認すべきです。

出典：Microsoft Learn、2026年8月時点現行資料Azure Monitor customer-managed storageHTTP Data Collector API migration guide

7．Intune 2607――CopilotとMCPを「ルール」ではなく端末側で制御する

Microsoft Intune Service Release 2607では、AI利用を端末側から統制するための重要な設定が追加されています。

Microsoft Edgeでは、Browsing with Copilot Allowed URLsとBrowsing with Copilot Blocked URLsが利用可能になりました。

許可リストではCopilotによる閲覧を許可するURLを指定でき、ブロックリストでは利用させないURLを定義できます。

ブロックリストが許可リストより優先されます。対象はHTTP／HTTPSで、サイトのorigin単位で判定されます。

また、Visual Studioの管理テンプレートには**Disable Model Context Protocol（MCP）**が追加されています。

Defender Antivirusについては、Controlled ConfigurationがPreview提供されています。

有効化すると、IntuneまたはMicrosoft Defender for Endpointから提供されたDefender Antivirus設定を権威ある設定として扱い、GPO、Configuration Manager、スクリプト、ローカル管理者による変更より優先できます。

AI利用規程を技術設定へ翻訳する

これまでのAIガバナンスでは、「機密情報をCopilotへ入力しない」「未承認AIを利用しない」というルールが中心でした。

しかし利用規程は、技術的に利用を止めるものではありません。

実務では、人事、給与、会計、顧客管理、内部通報、管理ポータルなどについて、Copilotの利用を許可するか禁止するかを整理し、実際のEdgeポリシーへ反映することが可能になっています。

MCPについても、開発者が自由に接続先を追加するのではなく、利用可能なMCPサーバー、接続先データ、実行ツールを企業として管理する必要があります。

なお、Controlled ConfigurationはPreviewであり、全組織で利用できるとは限りません。また、対象は現時点でDefender Antivirus等に限定され、EDRやFirewall全体をカバーするものではありません。

8．Microsoft Defender――AIエージェントが実行する操作を事前に評価する

AIエージェントの統制は、台帳管理から実行時防御へ進み始めています。

Microsoft DefenderのReal-time Protectionでは、AIエージェントのagentic loop内で行われる活動を検査し、危険な操作を実行前にブロックすることができます。

Agent 365では、Work IQ MCPと統合してツール呼び出しを実行前に評価し、Agent 365へオンボードされた顧客MCPツールも対象とします。

Microsoftは、未対応ツールを利用するエージェントやWork IQ MCPと統合しないエージェントについては保護対象外であることも明記しています。

カスタムルールでは、条件に一致した操作をブロックできます。

Defenderが監査またはブロックした動作はBehaviorInfoへ記録され、どのエージェント、利用者、ツールが関係したかを調査できます。

AIエージェント台帳に足りない項目

AIエージェント台帳に「名称」「所有者」「利用目的」しか記載していない場合、今後は十分ではありません。

どのMCPへ接続できるのか、どのツールを実行できるのか、どのデータを読み取れるのか、どの操作をブロックするのか、誰が監視するのかまで管理する必要があります。

つまりAIガバナンスは、

利用規程 → 台帳 → 権限制御 → 実行時制御

という段階へ進んでいます。

ただし、DefenderのAI保護はエージェントの種類によって対応状況が異なり、一部機能はPreviewです。

個別のAIエージェントが対象となるか、必要ライセンスを保有しているかについては、各テナントで確認する必要があります。

出典：Microsoft Learn、2026年7月～8月現行資料Microsoft Defender AI agent real-time protection

9．Microsoft Sentinel UEBA――ネットワークログを「人と端末の行動」に変える

2026年8月、Microsoft SentinelのUEBAに新しいデータソースと異常検知がPreviewとして追加されました。

Fortinet FortiGateについては、CommonSecurityLogのファイアウォールイベントを利用し、40を超える新しいbehaviorが追加されています。

対象には、短時間でのシステム設定変更、設定バックアップ、証明書変更、セキュリティサービス停止などが含まれます。

さらにCheck Point、FortiGate、ZscalerのFirewall、VPN、Web Proxyについて10個の新しい異常検知ルールが追加されました。

異常なVPNサインイン、VPNサインイン失敗、高リスクWebカテゴリーへの通常とは異なるアクセス、セキュリティ検知の急増、不審な管理変更などを、個々の利用者や端末の過去行動、組織全体の行動と比較して分析します。

SOCの価値は「何GBログを送ったか」では測れない

SIEM導入でよくあるのが、「FirewallログをSentinelへ送ったので監視できている」という状態です。

しかしUEBAを有効に使うためには、ユーザー、端末、IPアドレス、時刻、イベント内容が適切に関連付けられている必要があります。

ユーザー名の表記がシステムごとに異なる、端末IDが紐付かない、時刻がずれている、といった状態では、行動分析の精度も下がります。

実務上は、SOC契約の評価軸を「ログ取得の有無」だけでなく、正規化、エンティティマッピング、検知チューニングまで広げる必要があります。

なお、今回の追加機能はPreviewです。正式GAの日付は確認できません。

出典：Microsoft Sentinel What's new、2026年8月

10．ChainDrop――CI/CDは「開発ツール」ではなくクラウドID基盤

最後は、ソフトウェアサプライチェーンです。

Palo Alto Networks Unit 42は2026年8月6日、自己増殖型npmワームChainDropの分析を公開しました。

Unit 42によれば、ChainDropは400を超えるnpmパッケージへ感染し、開発端末、CIパイプライン、クラウド環境、下流ソフトウェア利用者へ影響する可能性があります。

窃取対象には、クラウド資格情報、npmトークン、GitHubトークン、SSHキーなどが含まれます。

特に重要なのは、GitHub Actions Runnerのメモリから一時資格情報を取得する機能が確認されている点です。

「OIDCだからSecretがない」は十分ではない

AzureとGitHub Actionsを接続する場合、長期的なClient Secretを廃止し、OIDC Federationを利用する設計は重要な改善です。

しかし、OIDCを利用していても、ジョブの実行中には一時的な認証情報が存在します。

Runnerそのものや依存パッケージが侵害されれば、その一時資格情報が攻撃対象になる可能性があります。

そのためGitHub ActionsからAzureへデプロイしている企業では、Federated Credentialのsubject条件、対象Repository、Branch、Environment、Azure RBAC、Runnerの外向き通信、npm依存関係を確認することが重要です。

侵害が疑われる場合には、悪性パッケージを削除するだけでは十分とは限りません。

Runnerがアクセス可能だったクラウド資格情報やトークンについて、失効・ローテーションの必要性まで確認すべきです。

これはUnit 42の調査から導く実務上の推論です。

なお、日本企業や特定の顧客がChainDropによる侵害を受けた事実は、今回確認した情報からは判断できません。

出典：Palo Alto Networks Unit 42、2026年8月6日Unit 42 ChainDrop analysis

今週、実際に何をするべきか

今週の対応を優先順位で並べると、次のようになります。

•  8月26日までに重要インフラ「安全基準等策定ガイドライン（案）」を確認し、重要インフラ関連顧客がいる場合は現行契約との差分を整理する

•  8月中にEntra IDでSMS・音声認証が有効な利用者を抽出し、9月1日のパスキー自動有効化について利用者へ案内する

•  Intune等で8月Microsoft月例更新の実適用率、再起動待ち、例外端末を確認する

•  9月14日までにHTTP Data Collector APIを利用しているカスタムログ連携を棚卸しし、Logs Ingestion API／DCRへの移行計画を確定する

•  9月30日までにすべてのEntra Connectサーバーをサポート対象版へ更新し、ユーザー作成・変更・無効化の同期試験を行う

•  Copilotの許可・禁止URL、利用可能なMCPサーバー、AIエージェントのツール権限を台帳化する

•  GitHub Actions等のCI/CDについて、OIDC Federation、Azure RBAC、依存パッケージ、Runnerからの外向き通信を確認する

まとめ――クラウドガバナンスは「委託」「AI」「ID」「ログ」を一つに見る

今週の10件は、一見すると別々のニュースです。

個人情報保護委員会による行政対応。

Entra IDのパスキー。

重要インフラ基準。

Windowsの脆弱性。

Entra Connect。

Azure Monitor。

Intune。

AIエージェント。

Sentinel。

npmサプライチェーン。

しかし、これらを一つの線で結ぶと、現在のクラウドガバナンスがどこへ向かっているかが見えてきます。

システムを委託しても、責任は消えません。

MFAを導入しても、弱い認証方式を残せば攻撃面は残ります。

AI利用規程を作っても、実行権限を制御できなければ統制は完成しません。

ログを集めても、誰のどの行動なのか説明できなければ監視の価値は下がります。

長期シークレットをOIDCへ変えても、実行環境そのものが侵害されれば一時資格情報が狙われます。

だからこそ、これからのクラウド法務・セキュリティでは、Azure、Entra ID、Microsoft 365、Intune、Defender、Sentinel、Copilotを個別製品として見るだけでは足りません。

ID、端末、データ、AI、ログ、CI/CD、委託先、契約、BCP、復旧を一つのガバナンスとして管理する必要があります。

クラウドの本当のリスクは、クラウドを利用することそのものではありません。

制度や技術が変わったにもかかわらず、昨日までの前提を今日もそのまま使い続けることです。

2026年後半のクラウドガバナンスで企業に求められるのは、製品を導入した事実ではなく、変化を継続的に把握し、契約・設定・運用へ反映し、その結果を証跡として説明できる組織であることです。