クラウド法務・セキュリティガバナンス週次ブリーフ
2026年8月31日版
Azure・Entra ID・Microsoft 365・Intune・Purviewを取り巻く制度・技術変更を実務目線で整理
結論
2026年8月末、日本企業のクラウドガバナンスは、制度対応とMicrosoft製品の技術変更が同時に進む重要な局面に入っています。
今週、特に優先して確認したいのは、SCS評価制度の具体化、改正個人情報保護法に関する政令・規則等の検討、Microsoft Entra IDのパスキー移行、Azure Monitorのログ基盤変更、Entra Connect Syncの更新期限、そしてIntuneやPurviewを利用したアクセス・情報統制です。
理由は、これらが単なる新機能や製品アップデートではなく、事故発生時の説明責任、委託先管理、ID停止、ログ保全、情報漏えい防止、BCP・DRと直接結びついているためです。
直近の日程では、8月31日にLinux版Azure VPN Clientが終了し、Azure Monitorのlinked storageに関するManaged Identity要件も8月31日以降に強制される可能性があります。9月1日からはEntra IDのパスキー移行が始まり、9月14日にHTTP Data Collector APIがサポート終了、9月30日には古いEntra Connect Sync環境で同期サービスが停止します。そして10月1日には重要インフラ統一基準の施行が予定されています。
今週のテーマを一言で表すなら、クラウドガバナンスの評価軸が「設定が存在するか」から「その設定を実際に強制できるか、証拠を残せるか、事故時に説明できるか」へ移っている、ということです。
1．SCS評価制度が「構想」から「実運用準備」の段階へ
2026年8月28日、IPAは「サプライチェーン強化に向けたセキュリティ対策評価制度」、いわゆるSCS評価制度について、基本規程等を公開しました。
SCS評価制度は、企業のセキュリティ対策状況を一定の共通基準で評価し、その結果を可視化することで、サプライチェーン全体のセキュリティ水準を高めることを目的としています。
制度そのものは任意です。現時点で、一般企業に対してSCS評価取得を一律に義務付ける法律ではありません。
一方で、IPAは、委託元が委託先へ求めるセキュリティ対策水準を示し、その実施状況を確認する場面で利用されることを想定しています。
これは、クラウド運用会社、MSP、SOC、システム開発会社、SaaS事業者にとって重要な動きです。
これまで企業間取引では、顧客ごとに異なるセキュリティチェックシートへ回答するケースが少なくありませんでした。しかしSCS評価制度が普及すれば、委託先がどの程度の対策を実施しているのかを、より共通化された基準で説明する場面が増える可能性があります。
AzureやMicrosoft 365を利用する企業であれば、Entra IDのMFAや特権ID管理、Intuneによる端末統制、Defenderによる脅威検知、SentinelやAzure Monitorによるログ管理、バックアップ、脆弱性管理、事故対応、再委託管理などを、どの要求事項に対応する対策なのか整理しておくことが実務上有効です。
重要なのは、「実施しています」と答えられることではありません。
規程、設定画面、監査ログ、インシデント訓練記録、バックアップ復元試験、アクセスレビュー結果など、客観的に確認できる証跡が必要になります。
つまりSCS評価制度への備えとは、新しいセキュリティ製品を追加することだけではありません。すでに実施している対策を、第三者へ説明できる形で整理することでもあります。
出典IPA「サプライチェーン強化に向けたセキュリティ対策評価制度」https://www.ipa.go.jp/security/scs/
確認できない点として、特定業界や個別企業が将来★3または★4を取引必須条件とするかどうかは、現時点では確認できません。
2．改正個人情報保護法、政令・規則等の具体化が進む
2026年8月26日、個人情報保護委員会は、改正個人情報保護法について、政令・規則等で定める事項の全体像を整理しました。
今後、この整理を基礎として、政令、個人情報保護委員会規則、ガイドライン、Q&Aなどの具体化が進められます。
今回示された論点には、AI開発、16歳未満の子どもの個人情報、顔特徴データ、個人データ処理を受託する委託先の義務、漏えい等の報告・本人通知、オプトアウト提供、重大違反に対する課徴金制度などが含まれています。
特にクラウド・AI利用企業にとって重要なのは、法務対応を「クラウドサービスの契約書を確認すること」だけで終わらせないことです。
企業がMicrosoft 365を利用し、Copilotで文書を参照し、Azure上のAIアプリからデータを分析し、その一部を外部SaaSやBPOへ連携している場合、一つの個人データに複数の主体が関与します。
そのため今後必要になるのは、データの保存場所だけではなく、データの流れ全体を把握することです。
誰が取得するのか。何の目的で利用するのか。どのクラウドサービスへ保存するのか。AIが参照するのか。外部事業者へ渡るのか。海外からアクセスされるのか。再委託があるのか。いつ削除するのか。
こうした情報を図として整理しておけば、今後政令・規則やガイドラインが公表された際に、自社環境とのギャップを比較しやすくなります。
現段階では、個別の最終要件がすべて確定しているわけではありません。そのため「改正法対応済み」と断定する段階ではありません。
今やるべきことは、将来の規制内容を推測して規程を書き換えることではなく、まず現在のデータフローを正確に把握することです。
出典個人情報保護委員会https://www.ppc.go.jp/
3．Intune 2608でWindows端末への無人Remote Helpが追加
Microsoft Intune Service Release 2608では、企業所有のWindows端末を対象とするUnattended Remote Helpが追加されました。
認可されたヘルプデスク担当者は、利用者本人がその場にいなくても、対象端末へ接続してトラブルシューティングを行うことができます。
ここで重要なのは、利用者のWindowsセッションをそのまま遠隔操作する仕組みではなく、担当者が自身の資格情報を用いて別のWindowsセッションを作成するという点です。
また、このアクセスはIntune RBACと監査ログの対象になります。
一見するとサポート効率を高める便利な機能ですが、セキュリティガバナンス上は「特権リモートアクセス」として扱う必要があります。
利用者が不在でも端末へ接続できるため、権限を持つ人を広げすぎれば、不正操作や誤操作のリスクが高まります。
そのため、Remote Helpを利用する場合は、誰が利用できるのか、どの端末へ接続できるのか、どの部署を対象とするのか、接続理由を記録するのか、監査ログを誰がレビューするのかまで定める必要があります。
Microsoftも、最小権限原則に基づく専用カスタムロールの利用を推奨しています。
特に注意すべきなのは、Microsoftの現行資料では、通常のユーザー参加型Remote HelpでConditional Accessを利用できる一方、無人Remote Helpについては同じConditional Accessが適用されないと説明されている点です。
したがって、Remote Help自体のRBAC、対象スコープ、管理者認証を厳しく設計する必要があります。
出典Microsoft Intune What's newhttps://learn.microsoft.com/en-us/intune/intune-service/fundamentals/whats-new
個別テナントで利用可能かどうかは、ライセンスと機能展開状況を確認する必要があります。
4．Entra ID、9月1日からパスキー移行が本格化
2026年9月1日から、Microsoft Entra IDでSMSまたは音声認証が有効になっているユーザーについて、パスキーが自動的に有効化されます。
対象ユーザーは、MFAを完了した後にパスキー登録を促されるようになります。
さらに2027年2月1日には、Microsoftが提供するSMS・音声認証の配信自体が終了します。
つまり2026年9月1日は、長期的なパスワードレス・フィッシング耐性認証への移行開始日と見ることができます。
企業が今確認すべきなのは、「パスキー機能が有効になっているか」だけではありません。
まずSMS・音声認証を利用している人数を把握し、その利用者がどの端末を使っているのかを確認する必要があります。
Windows、iPhone、Android、BYOD、役員端末、外部委託者端末、共有端末などでは、運用方法が異なる可能性があります。
さらに重要なのが、登録後のライフサイクルです。
端末を紛失した場合、誰が本人確認をするのか。スマートフォンを買い替えた場合はどうするのか。故障時にどの認証方法で復旧するのか。
こうした例外手順を用意しておかなければ、認証強化がそのまま業務停止につながる可能性があります。
出典Microsoft Learnhttps://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement
5．Linux版Azure VPN Clientが8月31日で終了
Azure VPN Client for Linux Previewは2026年8月31日に終了します。
終了後は、Microsoftからバグ修正、セキュリティパッチ、製品サポートが提供されなくなり、Linux向けリポジトリからパッケージも削除されます。
今回対象となるのはLinux版です。
Windows版、macOS版Azure VPN Client、Azure VPN Gatewayそのもの、Site-to-Site VPNには今回の終了は影響しません。
注意すべきなのは、代替クライアントにおける認証方式です。
MicrosoftはOpenVPNやstrongSwanを代替として案内していますが、これらのLinuxクライアントではAzure VPN GatewayのMicrosoft Entra ID認証を利用できません。
そのため、Linux版Azure VPN ClientをEntra ID認証で利用していた企業では、VPNソフトを交換するだけでは済まない場合があります。
証明書認証やRADIUSなど別方式へ変更する場合、証明書発行、秘密鍵管理、有効期限管理、失効、退職者処理、端末紛失時対応など、新しい運用設計が必要になります。
これはVPNアプリの更新ではなく、認証ライフサイクルの変更です。
出典Microsoft Learnhttps://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-client-linux-retire
既存クライアントが8月31日以降いつまで実際に接続できるかは確認できません。したがって、接続できる状態が続いていても、サポートされた本番構成として扱うべきではありません。
6．Azure Monitor linked storage、Managed Identity必須化へ
Azure Monitorでは、Log Analytics Workspaceのsaved queriesやsaved log alert queries用linked storage accountに関する認証方式も変わります。
Microsoftは、2026年8月31日以降、linked storage accountを新規作成または更新する場合に、Log Analytics WorkspaceへManaged Identityを割り当てることを必須化する方針を示しています。
Storage Account側では、そのManaged Identityへ必要なRBACを割り当てる必要があります。
この変更で注意したいのは、Portalから手動操作するケースだけではありません。
Terraform、Bicep、ARMテンプレート、CI/CDパイプラインでlinked storageを変更している環境では、Managed Identityや必要なRole Assignmentが定義されていない場合、これまで成功していたデプロイが強制開始後に失敗する可能性があります。
つまり、Azure Portalの設定だけを見るのではなく、IaCコード、デプロイパイプライン、権限設計まで確認する必要があります。
なお、Microsoftの現行記述は「no earlier than August 31, 2026」とされているため、8月31日の特定時刻から全テナントで一斉に強制されると断定することはできません。
7．HTTP Data Collector API、9月14日にサポート終了
Azure Monitorのlegacy HTTP Data Collector APIは、2026年9月14日にサポート終了となります。
ただし、MicrosoftはTLS 1.2以上へ対応している既存クライアントについて、9月14日以降もingestion自体は継続すると説明しています。
この点は非常に重要です。
9月15日にログが届いている可能性があるからです。
しかし、「ログが届いている」ことと「サポートされた構成である」ことは同じではありません。
サポート終了後は、基本的に重要なセキュリティ修正のみとなり、MicrosoftはLogs Ingestion APIへの移行を推奨しています。
Logs Ingestion APIではData Collection Ruleを使用し、Microsoft Entra認証、DCR単位のRBAC、データ変換などを利用できます。
移行時に特に注意したいのがMicrosoft Sentinelです。
送信先テーブルやスキーマが変われば、Analytics Rule、Hunting Query、Workbook、Parser、Playbook、Logic Apps、Power BIなどが旧スキーマを参照している可能性があります。
そのため「新しいAPIからログが入った」だけで移行完了と判断するべきではありません。
ログ受信、検知、自動化、可視化、監査まで回帰試験する必要があります。
HTTP Data Collector APIによるingestionが将来完全停止する日付は、今回確認したMicrosoft公式情報では確認できません。
8．Entra Connect、9月30日までの更新が必須
Microsoft Entra Connect Syncについて、2026年9月30日までに最低2.5.79.0以上へ更新する必要があります。
期限時点で必要なバージョンを満たしていない場合、すべての同期サービスが失敗します。
更新後に機能を回復することはできますが、それまで同期が停止することになります。
これは単なるサーバーメンテナンスの問題ではありません。
Entra Connectを利用するハイブリッドID環境では、オンプレミスActive Directoryで行ったユーザー作成、属性変更、グループ変更、アカウント無効化などをEntra IDへ同期しています。
もし同期が停止すれば、例えば退職者をオンプレミスADで無効化しても、その変更がクラウド側へ予定どおり反映されない可能性があります。
つまり、Entra ConnectはIDライフサイクル管理と内部統制の一部です。
更新対象も本番サーバーだけではありません。
ステージング、DR、旧サーバー、カスタム同期ルール、構成ファイル変更などを含めて確認する必要があります。
更新後は、単にSync Serviceが起動することを確認するだけでなく、ユーザー作成、変更、グループ変更、アカウント無効化まで実際にテストする必要があります。
出典Microsoft Learnhttps://learn.microsoft.com/en-us/entra/identity/hybrid/connect/reference-connect-version-history
個別環境で更新がそのまま成功するかは、OS、.NET、TLS、FIPS、カスタム構成などによって異なるため、確認できません。
9．重要インフラ安全基準ガイドライン案、意見募集が終了
重要インフラの「安全基準等策定ガイドライン（案）」に関する意見募集は、2026年8月26日に終了しました。
2026年8月31日時点では、国家サイバー統括室の公式ページ上で意見募集終了は確認できますが、パブリックコメントの結果と最終版ガイドラインの公表は確認できません。
一方、「重要インフラのサイバーセキュリティ対策のための統一基準」は2026年7月31日に決定され、10月1日施行予定です。
重要インフラ事業者へAzure、Microsoft 365、SOC、MSP、開発、保守などを提供している企業にとっては、最終版が公表されるまで何もしないという対応より、現状の契約と運用の差分を先に整理する方が現実的です。
特に確認したいのは、事故報告、ログ提供、監査権、再委託、アクセス管理、BCP、復旧支援です。
契約書上は「事故時にログを提供する」と書かれていても、実際には必要なログを保持していない。
BCPには復旧目標が書かれていても、復元試験を実施したことがない。
再委託について承認条項はあるものの、実際の再委託先を把握していない。
こうした状態があれば、契約上の義務と実運用の間にギャップが存在します。
出典内閣官房 国家サイバー統括室https://www.cyber.go.jp/
最終ガイドラインとパブリックコメント結果は、2026年8月31日時点では確認できません。
10．Purview、自動ラベルを本番適用前にSimulation
Microsoft Purviewでは、Sensitivity Labelのauto-labeling policyについて、本番適用前にSimulation Modeで実行し、実際のデータを変更せず対象アイテムを確認できる機能が追加されています。
DLPや自動ラベルは非常に強力です。
一方で、誤ったルールを本番適用すると、業務上必要な情報共有まで止めてしまう可能性があります。
例えば、顧客へ送る必要のあるファイルが外部共有禁止になる。
大量の既存文書へ不適切な機密ラベルが付与される。
業務システムとの連携に影響する。
こうした問題が考えられます。
Simulation Modeを利用すれば、実際に変更を加える前に、どのデータが対象になるのかを確認できます。
その結果を法務、情報システム、セキュリティ、業務部門が共同でレビューすることで、「規程上は機密だが実務上は共有が必要」といった例外も事前に発見できます。
これは単なるテスト機能ではなく、情報分類・DLPにおける変更管理と証跡作成の仕組みとして利用できます。
出典Microsoft Purview What's newhttps://learn.microsoft.com/en-us/purview/whats-new
個別テナントのライセンス条件や機能展開状況については、各環境で確認する必要があります。
直近の日程を整理する
今後の対応を時系列で見ると、重要な節目は次のとおりです。
2026年8月31日
Linux版Azure VPN Client終了。Azure Monitor linked storageのManaged Identity要件は8月31日以降の強制開始に注意。
2026年9月1日
Entra IDでSMS・音声認証利用者へのパスキー自動移行開始。
2026年9月14日
HTTP Data Collector APIサポート終了。
2026年9月30日
Entra Connect Syncの最低バージョン要件を満たさない環境で同期停止。
2026年10月1日
重要インフラ統一基準施行予定。
この日程だけを見ても、9月はMicrosoftクラウドの認証・ログ・ID基盤を重点的に確認する月になることが分かります。
今週、48時間以内に確認したいこと
まず優先したいのは、期限の迫った技術項目です。
Linux版Azure VPN Clientの利用者がいるか。
Entra IDでSMS・音声認証を使っている利用者は何人いるか。
Azure Monitor linked storageにManaged Identityと必要なRBACが設定されているか。
HTTP Data Collector APIを使っているスクリプトや外部製品が残っていないか。
Entra Connectの全サーバーがどのバージョンなのか。
ここを確認するだけでも、9月に突然起きる可能性がある認証・同期・ログ送信障害をかなり減らせます。
30日以内に進めたいこと
期限物への対応が終わったら、制度側のガバナンス整備へ進みます。
SCS評価制度については、自社の対策と要求事項の対応関係を整理し、将来の顧客監査へ備えます。
個人情報保護法については、Azure、Microsoft 365、Copilot、SaaS、MSP、BPOを含むデータフローを整理します。
重要インフラ関連顧客がいる企業では、事故報告、ログ、監査、再委託、復旧について契約書と実運用を比較します。
Remote Helpについては、専用RBACと監査ログレビューを設計します。
PurviewについてはSimulation Modeを使い、情報分類やDLPを本番適用する前に業務影響を確認する運用を構築します。
まとめ
今週の10項目を一つの視点から見ると、クラウドガバナンスの考え方そのものが変わってきていることが分かります。
これまでは、
「MFAを設定している」
「ログを保存している」
「委託契約を締結している」
「DLPを導入している」
「バックアップを取得している」
という、対策の存在自体が評価されがちでした。
しかし現在は、その一歩先が問われています。
MFAは実際にフィッシング耐性のある方式へ移行しているか。
ログは事故後の説明に使える状態か。
委託契約に書かれていることを、現場で本当に実行できるか。
DLPは業務を止めずに適用できることを事前検証したか。
Remote Helpの権限は本当に必要最小限か。
Entra Connectが止まった場合でも、退職者のアクセス停止を確実に行えるか。
つまり、クラウドガバナンスの評価軸は、
「設定しているか」
から、
「実際に強制できるか、証跡を残せるか、事故時に説明できるか」
へ移っています。
Azure、Entra ID、Microsoft 365、Intune、Purviewなどを製品単位で管理するだけでは、今後のガバナンスには不十分です。
必要なのは、ID、端末、データ、ログ、AI、委託先、契約、BCP、復旧、監査を一つの体系として管理することです。
クラウドの本当のリスクは、クラウドを使うことそのものではありません。
制度やサービスが変化しているにもかかわらず、昨日まで正しかった前提を今日もそのまま使い続けることです。
2026年9月は、認証、ログ、ID同期の大きな期限が集中します。
9月に入ってから慌てて対応するのではなく、8月31日の時点で「どこまで対応できているか」を可視化することが、今週最も重要なクラウドガバナンス対応です。
コメント