2026年4月20日のMicrosoft Security Blogで示された要点はシンプルです。Microsoft Entra、Azure private endpoints、Zero Trust network access（ZTNA）を使う組織は、パスワードやシークレットを「安全に保管する」だけでなく、盗まれる資格情報そのものを減らし、インターネットから到達できる公開エンドポイントを減らす設計へ移行すべきです。Microsoftは、機会攻撃を難しくするための実務策として、credential elimination、endpoint reduction / endpoint elimination、identity controls、platform engineeringを挙げています。(マイクロソフト)
特に最初に確認すべきなのは、公開されたPaaS、RDP/SSHなどの管理ポート、長期利用されているクライアントシークレット、広すぎるVPN・ZTNAアクセス範囲です。Azure Private Linkのプライベート エンドポイント、Microsoft Entra Private Access、マネージドIDを組み合わせることで、「外から見えない」「盗まれる秘密が少ない」「アクセス単位がアプリごとに絞られる」構成に近づけられます。
Microsoftの更新で押さえるべき結論
今回の更新は、単なる「新機能紹介」ではありません。実務的には、クラウドセキュリティ設計の優先順位を次のように見直すべきだ、というメッセージです。
| 観点 | 従来ありがちな対応 | 今回の更新から読み取れる実務方針 |
|---|---|---|
| 資格情報 | シークレットをKey Vaultで保管し、期限管理する | 可能な限りシークレットを使わず、マネージドIDやフェデレーションIDへ移行する |
| ネットワーク公開 | IP制限やWAFで公開エンドポイントを守る | そもそも公開エンドポイントを減らし、Private LinkやZTNAで到達経路を限定する |
| 管理アクセス | RDP/SSHを許可し、接続元IPで絞る | Bastion、JIT、シリアルコンソール、Entraベースの認証に寄せる |
| 社内アプリ接続 | VPNでネットワーク全体へ入れる | Microsoft Entra Private Accessなどでアプリ単位にアクセスを許可する |
| 組織運用 | チームごとに例外設定を許す | セキュアな標準構成を「選びやすい既定値」として提供する |
ポイントは、攻撃者にとって使いやすい入口を残さないことです。Microsoftは、攻撃者はネットワークを「突破する」というより、盗まれた資格情報でログインするケースが多いと説明しています。そのため、認証情報を減らすことと、公開面を減らすことは別々の対策ではなく、同時に進めるべき設計課題です。(マイクロソフト)
「endpoint elimination」と「private connectivity」は何を意味するのか
ここでいうendpoint eliminationは、すべてのエンドポイントをなくすという意味ではありません。インターネットから直接到達できる受信口を、業務上必要な最小限まで減らすという意味です。
Azure環境では、次のような対象が見直し候補になります。
| 見直し対象 | よくあるリスク | 推奨される方向性 |
|---|---|---|
| Azure Storage、Azure SQL Database、Cosmos DBなどのPaaS | public network accessが有効なまま残る | Private Endpointを作成し、検証後に公開アクセスを無効化する |
| VMのRDP/SSH | 緊急対応用に開けたポートが恒久化する | Bastion、JIT、Entra認証、管理用踏み台の再設計を行う |
| App ServiceやAPI | 全世界公開のまま認証だけに依存する | Private Endpoint、Application Gateway、WAF、ID制御を用途別に組み合わせる |
| 社内アプリ向けVPN | 接続後に広いネットワークへ到達できる | ZTNAでアプリ、ポート、ユーザー、条件を絞る |
| CI/CDやアプリのシークレット | 長期シークレットが漏えい・失効・放置される | マネージドID、Workload Identity Federation、短命トークンへ移行する |
Azure Private Linkでは、仮想ネットワーク内のプライベート エンドポイント経由でAzure PaaSサービスなどへ接続できます。Microsoftの説明では、仮想ネットワークとサービス間のトラフィックはMicrosoftのバックボーンネットワークを通り、サービスをパブリックインターネットへ公開する必要がありません。(Microsoft Learn)
つまり、Azure private endpointsは「公開されたサービスを少し安全にする機能」ではなく、サービスをプライベートネットワーク側へ引き込むための設計部品として考えるべきです。
Microsoft Entra利用者が最初に確認すべき変更点
Microsoft Entraを使っている組織では、ユーザーIDだけでなく、ワークロードID、サービスプリンシパル、AIエージェント、管理者アクセスまで含めて棚卸しする必要があります。
長期シークレットを使っているアプリ登録を洗い出す
最初に確認すべきなのは、アプリ登録やサービスプリンシパルで長期のクライアントシークレットを使っている箇所です。
よくある危険な状態は次のとおりです。
| 状態 | なぜ危険か | 初動 |
|---|---|---|
| 有効期限が1年以上のクライアントシークレットがある | 漏えいしても長期間悪用される | 期限短縮ではなく、マネージドID化できるかを先に確認する |
| CI/CDの環境変数にシークレットを保存している | ログ、設定ミス、権限過多で漏えいしやすい | Workload Identity Federationを検討する |
| 退職者や古いチームが作成したアプリ登録が残る | 所有者不明で棚卸しされない | 所有者、用途、権限、最終利用日時を確認する |
| ContributorやOwner権限を広く付与している | 侵害時の影響範囲が大きい | リソースグループ単位、読み取り専用、データプレーン権限へ分解する |
MicrosoftのマネージドIDは、資格情報を管理する必要がなく、資格情報自体が利用者からアクセスできない仕組みです。AzureリソースはMicrosoft Entra認証をサポートするリソースに対して、マネージドIDで認証できます。(Microsoft Learn)
実務では、「シークレットを安全な場所に置いたから完了」では不十分です。シークレットが必要な理由を一つずつ確認し、マネージドIDまたはフェデレーションIDに置き換えられるものから移行します。
Microsoft Entra Private Accessの範囲を広げすぎていないか確認する
Microsoft Entra Private Accessは、FQDNやIPアドレスを指定してプライベートまたは内部リソースへのアクセスを管理する機能です。Global Secure Access Clientを使うことで、リモートワーカーがVPNなしで必要なリソースへ接続でき、Quick AccessやGlobal Secure Access appによって対象リソースを構成できます。(Microsoft Learn)
ただし、ZTNAを導入していても、設定が広すぎると従来のVPNと同じ問題を持ち込みます。
避けるべき設定例は次のとおりです。
| 避けたい設定 | 問題 | 改善例 |
|---|---|---|
| 広いIPレンジをまとめてQuick Accessに入れる | アプリ単位の最小権限にならない | 業務アプリごとにGlobal Secure Access appを分ける |
| すべての社内DNS名を一括許可する | 不要な管理系ホストにも到達できる | FQDN、ポート、ユーザーグループを用途別に分ける |
| Conditional Accessを未設定にする | 侵害アカウントでも到達できる可能性がある | MFA、準拠デバイス、リスク条件を組み合わせる |
| 管理者と一般利用者を同じポリシーにする | 特権アクセスのリスクが高い | PIM、強い認証、専用デバイス条件を追加する |
MicrosoftのZero Trust関連ドキュメントでも、Private Accessのアプリケーションセグメントが広すぎると、従来型VPNの過剰なアクセスモデルを再現してしまうと説明されています。(Microsoft Learn)
Azure private endpointsで最初に見るべきポイント
Azure private endpointsを導入する際は、単にプライベート エンドポイントを作るだけでは不十分です。実務では、公開アクセス、DNS、依存システム、監視、ロールバック手順までセットで確認します。
public network accessが有効なPaaSを棚卸しする
最初の作業は、公開されているAzureリソースの棚卸しです。Azure Resource Graphを使える環境であれば、次のようなクエリを出発点にできます。
Resources
| where properties.publicNetworkAccess =~ 'Enabled'
| project subscriptionId, resourceGroup, type, name, location, publicNetworkAccess = properties.publicNetworkAccess
| order by type asc, name ascすべてのリソース種別を完全に拾えるとは限らないため、この結果だけで判断しないでください。Storage、SQL、Key Vault、Cosmos DB、App Service、Container Apps、AKS API Serverなど、組織で使っている主要サービスごとに確認観点を補います。
公開IPを持つリソースの洗い出しには、次のようなクエリも役立ちます。
Resources
| where type =~ 'microsoft.network/publicipaddresses'
| project subscriptionId, resourceGroup, name, location, ipAddress = properties.ipAddress, sku = properties.sku.name
| order by resourceGroup asc, name ascRDPやSSHのような管理ポートは、緊急対応で一時的に開けた設定が残りやすい領域です。
Resources
| where type =~ 'microsoft.network/networksecuritygroups'
| mv-expand rule = properties.securityRules
| where tostring(rule.properties.access) == 'Allow'
| where tostring(rule.properties.direction) == 'Inbound'
| where tostring(rule.properties.destinationPortRange) in ('22', '3389')
or tostring(rule.properties.destinationPortRanges) contains '22'
or tostring(rule.properties.destinationPortRanges) contains '3389'
| project subscriptionId, resourceGroup, nsg = name, rule = rule.name,
source = tostring(rule.properties.sourceAddressPrefix),
destinationPort = tostring(rule.properties.destinationPortRange)ここで重要なのは、「公開されているか」だけでなく、「公開されている理由が現在も正当か」を確認することです。古い検証環境、使われていない踏み台、移行前に開けた一時許可は、機会攻撃の入口になりやすい箇所です。
DNS設計を後回しにしない
Azure private endpointsで失敗しやすいのはDNSです。プライベート エンドポイントを作成しても、クライアントが引き続きパブリック側の名前解決をしていれば、期待した経路になりません。
確認すべきポイントは次のとおりです。
| 確認項目 | 実務上の注意点 |
|---|---|
| Private DNS Zone | 対象サービスに対応するゾーンが作成・リンクされているか |
| オンプレミスDNS | 条件付きフォワーダーやDNS転送が正しく設定されているか |
| 複数VNet | ハブ・スポーク構成で名前解決が一貫しているか |
| CI/CDエージェント | ビルドやデプロイ元がプライベート名を解決できるか |
| 監視・バックアップ | 監視基盤やバックアップサービスが新しい経路で到達できるか |
プライベート化の移行では、DNS変更が最も利用者影響を生みやすい部分です。いきなり公開アクセスを無効化するのではなく、テスト端末、開発環境、本番の一部ユーザー、全体展開の順に検証します。
public access無効化は「接続確認後」に行う
Private Endpointを作っただけでは、攻撃対象領域を十分に減らしたとは言えません。多くのPaaSでは、プライベート接続を作った後もpublic network accessが有効なまま残る可能性があります。
安全に進める順序は次のとおりです。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | 対象リソースを選ぶ | 機密データ、認証情報、基幹システムから優先する |
| 2 | Private Endpointを作成する | サブネット、IPアドレス、承認状態を確認する |
| 3 | DNSを設定する | クライアントからプライベートIPへ解決されるか確認する |
| 4 | アプリ接続をテストする | 通常処理、バッチ、監視、障害時処理を確認する |
| 5 | public network accessを無効化する | 例外接続がないかログで確認する |
| 6 | 監視を設定する | 失敗した接続、名前解決、認証失敗を検知する |
この順序を守らないと、「セキュリティ強化のための変更」が業務停止につながります。特にグローバル組織では、地域ごとのネットワーク、プロキシ、DNS、運用時間帯が異なるため、段階的な切り替えが必須です。
ZTNA利用者が見直すべきアクセス設計
Global Secure Accessは、Microsoft Entra Internet AccessとMicrosoft Entra Private Accessをまとめる概念で、Microsoft Entra管理センター上の統合された場所として提供されています。Microsoftは、Global Secure Accessが「最小特権」「明示的な検証」「侵害を前提とする」というZero Trustの原則に基づくと説明しています。(Microsoft Learn)
ZTNAを導入済みの組織が確認すべきポイントは、製品の有無ではなく、アクセス設計の粒度です。
| 確認項目 | 危険な状態 | 望ましい状態 |
|---|---|---|
| アプリ単位の制御 | ユーザーが接続後に広いネットワークへ到達できる | アプリ、ポート、FQDN単位で到達先を限定する |
| 条件付きアクセス | MFAだけで許可している | デバイス準拠、リスク、場所、特権条件を組み合わせる |
| 管理アクセス | 管理者も一般ユーザーと同じ経路を使う | 管理者専用ポリシー、PIM、強い認証を使う |
| コネクタ | 1台構成、古いバージョン、監視なし | 複数台構成、正常性監視、更新管理を行う |
| 例外管理 | 「一時的な広い許可」が残る | 期限、所有者、理由、レビュー日を必須にする |
Microsoft Entra Private Accessでは、プライベートネットワークコネクタの正常性が重要です。Microsoftは、コネクタが非アクティブまたは異常な場合、より安全性の低いアクセス方法に戻ってしまう可能性があると説明しており、コネクタグループごとに少なくとも2つのアクティブで正常なコネクタを持つことも推奨しています。(Microsoft Learn)
実務チーム別の初動チェックリスト
今回の更新は、セキュリティ部門だけで完結しません。Cloud security architects、network security teams、platform engineersが同じ優先順位で動けるように、役割ごとに初動を分けると進めやすくなります。
| 役割 | 最初にやること | 成果物 |
|---|---|---|
| Cloud security architects | 公開エンドポイント、シークレット、ZTNA範囲の基準を定義する | 標準アーキテクチャ、例外基準、移行優先度 |
| Network security teams | Public IP、NSG、Private Endpoint、DNS、ルーティングを棚卸しする | 公開面一覧、閉塞計画、DNS設計 |
| Platform engineers | マネージドID、Private Link、Policy as Codeを標準モジュール化する | Terraform/Bicepモジュール、CI/CDテンプレート、ガードレール |
| SOC / SecOps | 侵害時に使われやすい入口を監視する | アラート、ログ相関、例外レビュー |
| アプリ担当 | 接続先、シークレット、依存ジョブを確認する | 影響調査、テスト計画、切り戻し手順 |
重要なのは、各チームが別々に最適化しないことです。たとえば、ネットワークチームがPrivate Endpointを作っても、アプリ側が長期シークレットを使い続けていれば、資格情報の悪用リスクは残ります。逆に、マネージドIDへ移行しても、PaaSが全世界に公開されたままなら、探索・認証試行の対象になり続けます。
優先順位は「公開」「資格情報」「権限の広さ」で決める
すべてを一度に直そうとすると、移行が止まります。最初は次の条件に当てはまるものから対応してください。
| 優先度 | 条件 | 例 |
|---|---|---|
| 最優先 | インターネット公開かつ機密データを扱う | Storage、SQL、Key Vault、Cosmos DB |
| 高 | 長期シークレットと広い権限を持つ | Owner / Contributor権限を持つサービスプリンシパル |
| 高 | 管理ポートが公開されている | 22番、3389番、管理用Web UI |
| 中 | VPNやZTNAで広いネットワーク範囲を許可している | サブネット全体、複数ポート一括許可 |
| 中 | DNSや監視が未整備のPrivate Endpoint | 作成済みだが経路確認・ログ確認が不十分 |
| 低 | 検証環境だが外部公開されている | 開発用Webアプリ、古いPoC環境 |
判断基準は、「攻撃者が見つけやすいか」「認証情報を悪用しやすいか」「侵害時の横展開がしやすいか」の3つです。この3条件が重なるリソースは、費用対効果が高い改善対象です。
失敗しやすいポイント
Private Endpointを作っただけで満足する
Private Endpointを作成しても、public network accessが残っていれば、外部公開面は残ります。DNSが正しくない場合も、クライアントは想定外の経路で接続します。
作成後は、次の3点を必ず確認してください。
| 確認 | コマンド・方法の例 |
|---|---|
| 名前解決 | クライアントから対象FQDNを解決し、プライベートIPになるか確認する |
| 接続経路 | アプリ、バッチ、監視基盤から接続できるか確認する |
| 公開停止 | public network access無効化後も業務処理が成立するか確認する |
マネージドIDに広すぎる権限を与える
シークレットをなくしても、マネージドIDにOwnerやContributorを広く付与してしまうと、侵害時の影響範囲が大きくなります。
改善の基本は、次の順序です。
| 観点 | 推奨 |
|---|---|
| スコープ | サブスクリプション全体ではなく、必要なリソースまたはリソースグループに限定する |
| ロール | 汎用的なContributorではなく、必要な組み込みロールやカスタムロールを使う |
| ライフサイクル | 使われていないユーザー割り当てマネージドIDを定期的に削除する |
| 監査 | サインインログ、Activity Log、RBAC変更を監視する |
ZTNAを「新しいVPN」として使ってしまう
ZTNAの価値は、ネットワーク全体へ入れることではなく、必要なアプリへ必要な条件で入れることです。広いIPレンジや複数プロトコルをまとめて許可すると、従来VPNの弱点が残ります。
移行時は、次のように分解します。
| 悪い分け方 | 良い分け方 |
|---|---|
| 「社内システム一式」 | 人事システム、経理システム、管理画面などアプリ単位 |
| 「本社ネットワーク全体」 | 必要なFQDN、IP、ポート単位 |
| 「社員全員」 | 部門、職務、端末状態、リスク条件単位 |
| 「管理者全部」 | 特権ロール、PIM有効化、専用管理端末単位 |
最初の30日で進める現実的なアクション
最初から全社移行を狙うより、30日で「危険な入口を見える化し、1つ閉じる」ところまで進めるのが現実的です。
| 期間 | アクション | ゴール |
|---|---|---|
| 1週目 | Public IP、public network access、RDP/SSH、長期シークレットを棚卸しする | 攻撃対象領域の一覧を作る |
| 2週目 | 機密度と公開状態で優先順位を付ける | 最初に閉じる3〜5件を決める |
| 3週目 | 1つのPaaSでPrivate Endpoint、DNS、接続テストを実施する | 安全な移行手順を確立する |
| 4週目 | public access無効化、ログ監視、例外管理を開始する | 再利用できる標準手順にする |
この30日で作るべき成果物は、完璧な全社ロードマップではありません。再利用できる「安全な閉じ方」です。1つのStorage AccountやSQL Databaseで、Private Endpoint化、DNS確認、public access無効化、監視、切り戻しまで通せれば、次の移行対象へ横展開できます。
これからの設計基準
Microsoft Entra、Azure private endpoints、Zero Trust network accessを使う環境では、次の基準を標準にしていくべきです。
| 設計基準 | 実務での意味 |
|---|---|
| Secretless first | 新規ワークロードは、クライアントシークレットではなくマネージドIDやフェデレーションIDを優先する |
| Private by default | 機密データを扱うPaaSは、原則としてPrivate Endpoint経由にする |
| No standing admin exposure | RDP/SSHや管理画面を恒久的に公開しない |
| App-level access | VPN的な広いネットワーク許可ではなく、アプリ単位でZTNAを設計する |
| Policy as Code | Azure Policy、IaC、CI/CDで公開設定やシークレット利用を検出・抑止する |
| Exception with expiry | 例外は所有者、理由、期限、レビュー日を必須にする |
今回のMicrosoftの更新を実務に落とすなら、最初の一歩は明確です。AzureとMicrosoft Entraの環境から、公開エンドポイント、長期シークレット、広すぎるアクセス範囲を棚卸ししてください。そのうえで、重要度の高いPaaSからAzure Private Linkのプライベート エンドポイントへ移行し、ワークロード認証はマネージドIDへ、ユーザーの社内アプリアクセスはMicrosoft Entra Private AccessなどのZTNAへ寄せていきます。
「守る入口を増やす」のではなく、「攻撃者が使える入口を減らす」。これが、Microsoft Entra、Azure private endpoints、Zero Trust network accessを運用する組織が、2026年時点で最初に確認すべき設計変更です。
コメント