クラウド法務・セキュリティガバナンス週次ブリーフ
- 山崎行政書士事務所
- 7 日前
- 読了時間: 13分
2026年9月1日版
Azure・Entra ID・Microsoft 365・Intuneを利用する日本企業が確認したい10の重要動向
2026年9月、日本企業のクラウド運用は、単なる製品アップデートへの対応では済まない局面に入っています。
Microsoft Entra IDではパスキーへの移行が始まり、Azure Monitorでは旧ログ取り込み方式のサポート終了が迫り、Entra Connect Syncにも明確な更新期限が設定されています。
一方、日本側でも、SCS評価制度、改正個人情報保護法、重要インフラ統一基準の具体化が進んでいます。
これらを個別のニュースとして追うだけでは、実務上の意味を見失います。
クラウド法務とセキュリティガバナンスの観点で重要なのは、
ID端末データログAI委託先契約BCP復旧監査
を一つの管理体系として捉えることです。
今週の結論は明確です。
クラウドガバナンスの評価軸は、
「設定しているか」
から、
「実際に強制できるか」「証跡を残せるか」「事故時に説明できるか」
へ移っています。
今回は、2026年9月1日時点で確認できる日本政府・公的機関、Microsoft公式、主要セキュリティベンダーの情報を中心に、特に実務への影響が大きい10項目を整理します。
1．SCS評価制度が実運用準備の段階へ
2026年8月28日、IPAは「サプライチェーン強化に向けたセキュリティ対策評価制度」、いわゆるSCS評価制度について、基本規程などを公開しました。
SCS評価制度は、取引先企業のセキュリティ対策状況を共通基準で評価し、その結果を可視化することで、サプライチェーン全体のセキュリティ水準を高めることを目的としています。
制度そのものは任意です。
現時点で、一般企業にSCS評価取得を一律に義務付ける法律ではありません。
一方で、IPAや経済産業省は、委託元が委託先へ求めるセキュリティ対策水準を示し、その実施状況を確認する場面での活用を想定しています。
AzureやMicrosoft 365の運用、MSP、SOC、システム開発、SaaSなどを提供する企業にとって、今後重要になるのは「安全です」と説明することではありません。
例えば次のような項目について、証跡を提示できることが求められる可能性があります。
MFA特権ID管理アクセスレビュー端末管理脆弱性管理ログ監視インシデント対応バックアップBCP・DR委託先管理変更管理教育訓練
重要なのは、対策の存在だけではありません。
規程、実際の設定、監査ログ、アクセスレビュー結果、訓練記録、復旧試験記録などを第三者が確認できる状態にしておくことです。
SCS評価制度への準備とは、新たな製品を購入することよりも、現在の対策を証拠付きで説明できるよう整理することだと考えた方が実務的です。
出典IPA「サプライチェーン強化に向けたセキュリティ対策評価制度」https://www.ipa.go.jp/security/scs/index.html
経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度」https://www.meti.go.jp/policy/netsecurity/scs.html
確認できない点として、特定企業や特定業界が将来★3・★4を必須の取引条件とするかどうかは、現時点では確認できません。
2．改正個人情報保護法の具体化が次の段階へ
2026年8月26日、個人情報保護委員会は、改正個人情報保護法について、政令・規則等で定める事項の全体像案を公表しました。
資料では、今後具体化される論点として、AI開発、16歳未満の子どもの個人情報、顔特徴データ、委託先の義務、漏えい報告・本人通知、オプトアウト提供、課徴金制度などが整理されています。
AIについては、統計作成等の特例に関連して、「統計作成等であると整理できるAI開発等」を含む方向が示されています。
ただし、どのAI開発が具体的に対象となるかは、今後の委員会規則やガイドラインで具体化される予定です。
Microsoft 365、Azure、Copilot、生成AI、外部SaaSなどを利用する企業にとって、ここで重要なのは、最終規則を待ってから対応を始めることではありません。
今から準備できるのは、データフローの可視化です。
最低限、次を整理しておくとよいでしょう。
どの個人情報を取得するのか取得目的は何かどこへ保存するのかAIが参照するのか外部SaaSへ送信されるのかMSPやBPOがアクセスするのか再委託されるのか海外からアクセスされるのか保存期間は何年か削除方法は何か漏えい時に誰が誰へ報告するのか
法令対応を「契約書の確認」だけで終わらせるのではなく、実際にデータがどのように流れるかを把握することが重要です。
出典個人情報保護委員会 第366回委員会https://www.ppc.go.jp/aboutus/minutes/2026/20260826/
現時点では、政令、委員会規則、ガイドラインの最終内容は確認できません。
したがって、「改正法対応済み」と断定できる段階ではありません。
3．重要インフラ統一基準は10月1日施行予定
2026年7月31日、内閣官房 国家サイバー統括室において「重要インフラのサイバーセキュリティ対策のための統一基準」が決定されました。
施行予定日は2026年10月1日です。
また、安全基準等策定ガイドライン案についての意見募集は8月に終了しています。
9月1日時点では、最終ガイドラインとパブリックコメント結果の公表は確認できません。
ここで重要なのは、重要インフラ事業者だけの話として片付けないことです。
重要インフラ事業者へ、
Azure運用Microsoft 365運用MSPSOC開発保守バックアップデータセンターサービス
などを提供している企業には、契約や調達条件を通じて要求が及ぶ可能性があります。
特に確認したいのは次の項目です。
事故報告ログ提供監査権再委託アクセス管理BCP復旧支援
契約書に「事故時にログを提供する」と書かれていても、実際には必要なログを取得していなければ対応できません。
復旧支援義務があっても、復元試験を行ったことがなければ、実際の事故で機能するかは分かりません。
重要なのは、契約と実運用を一致させることです。
出典内閣官房 国家サイバー統括室https://www.cyber.go.jp/policy/group/infra/policy.html
一般企業すべてに統一基準が直接適用されるとは確認できません。
4．Entra IDは9月1日からパスキー移行開始
2026年9月1日から、Microsoft Entra IDでSMSまたは音声認証が有効になっているユーザーについて、パスキーも自動的に有効化されます。
対象ユーザーはMFAサインイン後にパスキー登録を促されるようになります。
さらに2027年2月1日には、Microsoftが提供するSMS・音声認証そのものが終了します。
その時点でSMS・音声しか認証方法を持たないユーザーは、サインイン継続のためパスキー登録が必要になります。
2027年2月1日の強制動作についてはオプトアウトできません。
この変更を単なる認証機能のアップデートとして扱うのは危険です。
情シスが最初に確認したいのは、対象人数です。
SMS利用者音声認証利用者役員外部委託者BYOD利用者共有端末利用者特殊端末利用者
を把握します。
その上で、
WindowsiPhoneAndroid
それぞれの登録方法を用意します。
さらに、端末紛失、故障、機種変更時の復旧手順まで設計する必要があります。
フィッシング耐性を高めることは重要ですが、復旧方法が不明確であれば、認証強化が業務停止につながる可能性があります。
出典Microsoft Learnhttps://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement
個別テナントで何人が対象になるかは、実際のAuthentication Methods Policyと利用実績を確認しなければ判断できません。
5．Entra Connectは9月30日までに更新が必要
Microsoftは、Microsoft Entra Connect Syncについて、2026年9月30日時点で最低2.5.79.0以上でなければ、すべての同期サービスが失敗すると明記しています。
期限を過ぎても対応バージョンへ更新すれば機能は回復しますが、それまで同期が停止します。
これは単なるサーバー保守ではありません。
Entra Connectは、ハイブリッドID環境におけるIDライフサイクル管理の一部です。
例えば、退職者をオンプレミスActive Directoryで無効化した場合、その変更がEntra IDへ同期されることでクラウドアクセスも停止する設計になっている企業があります。
同期が止まれば、予定どおりアクセス停止が反映されない可能性があります。
そのため、確認対象は本番サーバーだけではありません。
本番ステージングDR旧サーバーカスタム同期ルール構成ファイル変更
まで含めます。
更新後は、サービスが起動しただけで完了としないことも重要です。
ユーザー作成属性変更グループ変更アカウント無効化
まで実際に同期試験を行います。
出典Microsoft Learnhttps://learn.microsoft.com/en-us/entra/identity/hybrid/connect/reference-connect-version-history
独自同期ルールやカスタム構成を持つ個別環境で更新がそのまま成功するかは確認できません。
6．Azure MonitorはManaged Identityと旧ログAPIを同時に確認
Azure Monitorでは、二つの大きな変更があります。
一つ目はlinked storageです。
Log Analytics Workspaceでsaved queriesまたはsaved log alert queries用のlinked storage accountを追加・更新する場合、WorkspaceへのManaged Identity割り当てが必要になります。
Storage Account側には、そのManaged Identityに対する必要なRBACも設定します。
Portalから手動設定している環境だけでなく、
TerraformBicepARMCI/CD
を利用している環境も確認が必要です。
必要なIdentityやRole AssignmentがIaCに含まれていなければ、これまで成功していたデプロイが失敗する可能性があります。
二つ目はHTTP Data Collector APIです。
legacy HTTP Data Collector APIは2026年9月14日にサポート終了となります。
ただしMicrosoftは、TLS 1.2以上を使用している既存クライアントについて、9月14日以降もingestion自体は継続すると説明しています。
つまり、ログが突然止まるとは限りません。
ここが注意点です。
「9月15日にもログが来ているから対応不要」
とは判断できません。
技術的に動くことと、サポート対象であることは別です。
MicrosoftはLogs Ingestion APIへの移行を推奨しています。
移行時には、
DCRMicrosoft Entra認証RBACデータ変換
などを利用できます。
7．Linux版Azure VPN Clientはサポート終了
Azure VPN Client for Linux Previewは2026年8月31日に終了しました。
終了後、Microsoftはバグ修正、セキュリティパッチ、製品サポートを提供しません。
注意したいのは代替クライアントの認証です。
MicrosoftはOpenVPNやstrongSwanを代替として案内していますが、これらのLinuxクライアントではAzure VPN GatewayのMicrosoft Entra ID認証を利用できません。
つまり、Entra ID認証でLinux版Azure VPN Clientを使っていた場合、単なるアプリの入替では済まない可能性があります。
証明書認証などへ変更する場合は、
証明書発行秘密鍵管理更新失効退職者処理紛失端末対応
まで新たに設計します。
これはVPNクライアントの変更ではなく、認証基盤の変更として扱うべきです。
出典Microsoft Learnhttps://learn.microsoft.com/en-us/azure/virtual-wan/azure-vpn-client-linux-retirement
既存クライアントが実際にいつまで接続できるかは確認できません。
8．Intune 2608でWindows端末への無人Remote Help
Microsoft Intune Service Release 2608では、物理的な企業所有Windows端末を対象としたUnattended Remote Helpが追加されています。
認可された担当者は、利用者本人がその場にいなくても、自分自身の資格情報で対象端末へ接続できます。
便利な機能ですが、これは通常のヘルプデスク機能よりも「特権リモートアクセス」として捉える方が適切です。
利用者不在でも操作できるため、
誰が使えるのかどの端末に接続できるのか利用理由を記録するのか監査ログを誰が確認するのか
を明確にします。
特にMicrosoftの現行資料では、通常の利用者参加型Remote HelpではConditional Accessを利用できますが、無人アクセスには同じConditional Accessが適用されないとされています。
そのため、RBACと対象スコープを必要最小限にすることが重要です。
出典Microsoft Intune Remote Helphttps://learn.microsoft.com/en-us/intune/remote-help/
個別テナントで利用可能かは、契約ライセンスと展開状況を確認する必要があります。
9．Purview、自動ラベルを本番適用前にSimulation
Microsoft Purviewでは、Sensitivity Labelのauto-labeling policyについて、本番適用前にSimulation Modeを利用できる機能が追加されています。
実際のファイルやメールへ変更を加えず、
どのアイテムが対象になるのか対象件数はどの程度か誤検知があるか業務影響があるか
を確認できます。
DLPや自動ラベルは強力ですが、誤った設定を本番適用すれば、必要な外部共有や業務システム連携まで止める可能性があります。
そのため、
Simulation結果確認法務・情シス・業務レビュー本番適用
という流れを作ることが有効です。
Simulation結果自体を、設定変更前に影響評価を行った証跡として残すこともできます。
出典Microsoft Purview What's newhttps://learn.microsoft.com/en-us/purview/whats-new
個別テナントでのライセンス条件や提供状況は確認が必要です。
10．ChainDropが示したCI/CD資格情報の新しいリスク
Palo Alto Networks Unit 42は2026年8月6日、自己増殖型npmワーム「ChainDrop」の分析を公表しました。
Unit 42によると、400を超えるnpmパッケージが感染し、クラウド資格情報、GitHubトークン、npmトークン、SSHキーなどが標的となりました。
特に注目したいのが、GitHub Actions Runnerのメモリから一時的な資格情報を探索する機能です。
近年、AzureとGitHub Actionsの連携では、長期的なClient Secretを使わずOIDC Federationを使う設計が推奨されています。
これは重要な改善です。
しかし、
「OIDCだから盗まれる資格情報はない」
という意味ではありません。
ジョブ実行中には短命な認証情報が存在します。
Runnerそのものや依存パッケージが侵害されれば、その一時資格情報が攻撃対象になる可能性があります。
GitHub ActionsからAzureへ接続している場合は、
Federated CredentialのsubjectRepositoryBranchEnvironmentAzure RBACRunnerからの外向き通信依存パッケージSBOM
まで確認する価値があります。
出典Palo Alto Networks Unit 42https://unit42.paloaltonetworks.com/
日本企業や特定組織がChainDropによる侵害を受けた事実は、今回確認した情報からは確認できません。
9月の重要日程
2026年9月1日Entra IDのSMS・音声ユーザーへのパスキー移行開始
2026年9月14日HTTP Data Collector APIサポート終了
2026年9月30日Entra Connect Syncの最低バージョン要件を満たさない環境で同期停止
2026年10月1日重要インフラ統一基準施行予定
そして2027年に向けて、SCS評価制度や改正個人情報保護法への具体的対応が進みます。
今週、48時間以内に確認したいこと
まず、期限が迫っている技術項目を優先します。
Entra IDのSMS・音声認証利用者を抽出する
Entra Connectの全サーバーバージョンを取得する
HTTP Data Collector API利用箇所を検索する
Linux版Azure VPN Client利用者を確認する
Azure Monitor linked storageのManaged IdentityとRBACを確認する
この5点は、比較的短時間で棚卸しできます。
30日以内に進めたいこと
技術期限への対応後は、制度とガバナンスを整備します。
SCS評価制度については、自社対策を要求事項へ対応付け、証跡を整理する。
改正個人情報保護法については、Azure、Microsoft 365、Copilot、SaaS、BPOを含めたデータフローを作成する。
重要インフラ関連顧客がいる場合は、事故報告、ログ、監査、再委託、BCP、復旧について契約と実運用を比較する。
Intune Remote Helpは専用RBACと監査レビューを設計する。
PurviewではSimulation Modeを利用してDLP・自動ラベルの業務影響を事前検証する。
このように、個々の製品対応を組織全体の統制へつなげることが重要です。
まとめ
2026年9月は、クラウドの認証、ログ、ID基盤が大きく動く月です。
Entra IDではパスキー移行が始まり、Azure Monitorでは旧ログAPIのサポート終了が迫り、Entra Connectには明確な更新期限があります。
一方、日本側ではSCS評価制度、改正個人情報保護法、重要インフラ統一基準の具体化が進んでいます。
これらを別々に管理していると、本質を見失います。
例えば、
MFAを設定しているから安全。
ログを保存しているから大丈夫。
委託契約があるから責任分界は明確。
DLPを導入したから情報漏えい対策は完了。
という判断では、今後のクラウドガバナンスとして十分ではありません。
必要なのは、
MFAが実際にフィッシング耐性のある方式へ移行しているか。
ログが事故後の説明に使える状態か。
委託契約で約束した対応を実際に実行できるか。
DLPが業務へ与える影響を本番前に確認したか。
特権Remote Helpを必要最小限の担当者だけが利用できるか。
Entra Connectが止まってもアクセス停止を確実に実行できるか。
まで見ることです。
クラウドガバナンスの評価軸は、
「設定しているか」
から、
「実際に強制できるか」「証跡を残せるか」「事故時に説明できるか」
へ変化しています。
Azure、Entra ID、Microsoft 365、Intune、Purview、CI/CDを製品単位で管理するだけでは足りません。
ID、端末、データ、ログ、AI、CI/CD、委託先、契約、BCP、復旧、監査を一つの体系として管理する必要があります。
クラウドの本当のリスクは、クラウドを利用することそのものではありません。
制度やサービスが変化しているにもかかわらず、昨日まで正しかった前提を、今日も正しいと思ったまま運用し続けることです。
2026年9月は、認証・ログ・ID同期の重要期限が集中します。
今の時点で「何を使っているのか」「期限に対応できているのか」「事故時に説明できるのか」を可視化しておくことが、今月最も重要なクラウド法務・セキュリティガバナンス対応です。
コメント