「Microsoft recommends endpoint elimination plus private connectivity to reduce opportunistic attack surface」という更新を、単なるMicrosoftのベストプラクティス紹介として読むだけでは不十分です。2026年4月20日に公開されたMicrosoft Security Blogの要点は、日和見型攻撃に対して「侵入された後に検知する」だけでなく、そもそも攻撃者が見つけられる入口と、悪用できる資格情報を設計段階で減らすことにあります。(Microsoft)
Microsoft Entra / Azure private endpoints / Zero Trust network access を使う組織が最初にやるべきことは明確です。まず、インターネットから到達できる管理ポート、公開されたPaaSデータプレーン、長期利用されているシークレットを棚卸しし、重要データや特権に近いものから順に閉じます。そのうえで、Azure Private Link、マネージドID、Microsoft Entra Private Access、条件付きアクセスを組み合わせ、公開ネットワーク前提の構成を「IDで許可された通信だけが、プライベート経路で届く」構成へ移行します。
「endpoint elimination plus private connectivity」は何を意味するのか
ここでいうendpoint eliminationは、PCやスマートフォンなどの「端末をなくす」という意味ではありません。攻撃者がスキャンできる公開エンドポイント、直接ログインできる管理口、使い回せる資格情報を減らす、という設計思想です。
Microsoftのブログでは、日和見型攻撃を防ぐための実践として、資格情報の排除、エンドポイントの削減、ID制御を取り上げています。特に、ワークロードがシークレットなしで認証できるならそうすべきであり、AzureではマネージドIDやフェデレーションIDのパターンを使って、パスワード、クライアントシークレット、APIキーのような漏えいしやすい要素を減らす考え方が示されています。(Microsoft)
重要なのは、ネットワーク対策とID対策を分けて考えないことです。公開エンドポイントを減らしても、強すぎる権限を持つシークレットが残っていれば、侵害時の被害範囲は広がります。逆に、マネージドIDを使っていても、データベースやストレージがインターネットから到達可能なままなら、設定ミスや盗まれたトークンを起点に攻撃余地が残ります。
優先して確認すべき攻撃面
まずは「どの通信を閉じるか」ではなく、「どの入口が攻撃者にとって一番使いやすいか」で整理します。Security teams、compliance leads、platform architects が同じ優先順位で会話できるよう、次の表で棚卸ししてください。
| 攻撃面 | よくある例 | 優先度が高い条件 | 推奨される低減策 |
|---|---|---|---|
| 公開された管理経路 | RDP、SSH、踏み台サーバー、VPN入口 | 0.0.0.0/0許可、特権管理者が利用、ログが不十分 | 直接公開を停止し、JIT、Bastion、Microsoft Entra Private Access、PIMへ移行 |
| 公開されたPaaSデータプレーン | Azure Storage、Azure SQL Database、Key Vault、Cosmos DB | 個人情報、機密データ、業務停止につながるデータを保持 | Azure private endpoints / Private Linkを使い、検証後にパブリックアクセスを無効化 |
| 長期利用の資格情報 | クライアントシークレット、接続文字列、APIキー、証明書 | 有効期限が長い、複数環境で共有、コードやCI/CD変数に保存 | Microsoft EntraのマネージドID、ワークロードID、最小権限RBACへ移行 |
| 広すぎるネットワークアクセス | VPNでサブネット全体に到達、広いIPレンジの許可 | 役割ごとの到達範囲が分かれていない | ZTNAでアプリ単位・ポート単位に分割 |
| 例外運用 | 一時的な公開、手動許可、期限なしの例外 | 所有者不明、期限なし、監査証跡なし | 例外に期限・承認者・リスク理由を付け、Policy-as-Codeで再発を防止 |
最初に潰すべきなのは、公開された管理ポートと高価値データの公開データプレーンです。攻撃者から見れば、これらは探索しやすく、認証情報が1つ漏れただけで侵害につながりやすい入口です。
Microsoft Entraで「盗まれて困る資格情報」を減らす
Microsoft Entraを使う組織では、最初の実務テーマを「認証強化」ではなく「資格情報の削減」に置くと効果が出やすくなります。MFAや条件付きアクセスは重要ですが、アプリケーションや自動化基盤に長期シークレットが残っていると、フィッシング対策とは別の経路で侵害される可能性があります。
Microsoft Learnでは、マネージドIDにより開発者がシークレットや資格情報を管理する必要がなくなり、アプリケーションが資格情報を保持せずにMicrosoft Entraトークンを取得できると説明されています。マネージドIDは、Azureリソースに割り当てられ、Storage、SQL Database、Cosmos DBなどの依存リソースへのアクセスに使えます。(Microsoft Learn)
実務での進め方
まず、次の場所にあるシークレットを棚卸しします。
- Microsoft Entraのアプリ登録にあるクライアントシークレット
- Azure Key Vault内の長期シークレット
- GitHub Actions、Azure DevOps、GitLab CIなどのCI/CD変数
- App Service、Functions、VM、コンテナ環境のアプリ設定
- ソースコード、構成ファイル、Terraform変数、Bicepパラメーター
次に、Azure上のワークロードからAzureリソースへアクセスする処理を優先して、マネージドIDへ移行します。たとえば、Azure FunctionsがAzure Storageに接続している場合、接続文字列をアプリ設定に保存する構成から、FunctionsのマネージドIDに必要最小限のRBACロールを付与する構成へ変えます。
注意点は、マネージドIDにしただけで安全になるわけではないことです。スコープをサブスクリプション全体に広げたり、Contributorのような強い権限を安易に付けたりすると、シークレットを減らしても侵害時の影響範囲は大きいままです。権限は、対象リソース、操作内容、環境単位で絞り込みます。
Azure private endpointsでPaaSの公開データプレーンを閉じる
Azure private endpointsは、Azure PaaSを使う組織にとって、攻撃対象領域を減らす中心的な対策です。Private Endpointは仮想ネットワーク内のプライベートIPアドレスを使うネットワークインターフェイスで、Azure Private Linkを通じてサービスへプライベートに接続します。対象にはAzure Storage、Azure Cosmos DB、Azure SQL Databaseなどがあります。(Microsoft Learn)
Azure Private Linkを使うと、Azure PaaSやAzure上の顧客・パートナーサービスへ、仮想ネットワーク内のprivate endpoint経由でアクセスできます。Microsoftの説明では、仮想ネットワークとサービス間のトラフィックはMicrosoftのバックボーンネットワークを通り、サービスをパブリックインターネットへ公開する必要がなくなります。(Microsoft Learn)
移行手順の基本
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 対象選定 | 機密データを持つStorage、SQL、Key Vaultなどを優先 | 重要度の低い開発環境から始め、本番の高リスク資産が後回しになる |
| Private Endpoint作成 | ワークロードが存在するVNet、または接続性のあるHub/Spokeに配置 | サブリソースの指定を誤る。Storageならblob、file、dfsなど用途別に確認が必要 |
| DNS設定 | Private DNS Zoneや社内DNS連携でFQDNをプライベートIPへ解決 | private endpointは作ったが、名前解決が公開IPのままになる |
| 通信確認 | アプリ、管理端末、監視、バックアップ経路から疎通確認 | アプリ本体だけ確認し、運用ツールやバッチ処理が失敗する |
| パブリックアクセス制限 | 検証後に対象サービスのパブリックネットワークアクセスを無効化または厳格化 | private endpointを作っただけで満足し、公開経路が残る |
| 監視 | Azure Monitor、ログ、アラートで通信量や失敗を監視 | ネットワークを閉じた後の障害検知が遅れる |
Private Endpointで特に多い失敗は、DNSです。Microsoft Learnでも、Private Endpoint経由で同じサービスへ接続するには別のDNS設定が必要になる場合があり、FQDNがPrivate EndpointのプライベートIPアドレスへ解決されることを確認する必要があると説明されています。(Microsoft Learn)
Zero Trust network accessでVPN型の広い到達性をやめる
Microsoft Entra Private Accessは、内部アプリやプライベートリソースへのアクセスを、ID中心のZero Trust network accessとして扱うための選択肢です。Microsoft Learnでは、FQDNやIPアドレスをプライベートまたは内部リソースとして指定でき、Global Secure Access Clientを導入したリモートワーカーはVPNを使わずに必要なリソースへアクセスできると説明されています。(Microsoft Learn)
従来型VPNの問題は、認証後に「ネットワークへ入れる」ことです。業務アプリAだけを使うユーザーが、同じネットワーク上のサーバーBや管理ポートへ到達できる構成になっていると、資格情報の侵害後に横展開されやすくなります。ZTNAでは、ユーザー、デバイス、アプリ、条件付きアクセスの評価結果に基づき、必要なアプリやポートだけへ到達させます。
Microsoft Entra Private Accessで優先すべき設定
| 対策 | 目的 | 実装の目安 |
|---|---|---|
| アプリ単位のセグメント化 | VPNのような広い到達性を避ける | FQDN、IP、ポートを業務アプリ単位で定義 |
| 条件付きアクセスの適用 | 盗まれた資格情報だけで内部資産へ入らせない | MFA、準拠済みデバイス、認証強度、リスク条件を組み合わせる |
| ユーザー・グループ割り当て | 最小権限を実現する | 「全社員」ではなく、業務ロールや部門単位で割り当て |
| コネクタの冗長化 | 代替の弱い経路へ戻さない | コネクタグループごとに複数台を配置し、正常性を監視 |
| DNS設計 | 内部FQDNを安全に解決する | Private Access経由で内部DNSへ到達できるようにする |
Microsoft Learnでは、Private Accessアプリに条件付きアクセスポリシーを適用でき、グローバルセキュアアクセスからQuick AccessアプリやPrivate Accessアプリ向けに条件付きアクセスを構成できると説明されています。(Microsoft Learn)
ただし、Quick Accessに広いIPレンジや多数のポートを入れすぎると、従来型VPNの過剰許可を再現してしまいます。MicrosoftのZero Trustネットワーク保護ガイダンスでも、広いアプリケーションセグメントは従来型VPNの過剰なアクセスモデルを複製し、偵察や横展開を容易にすると説明されています。(Microsoft Learn)
影響評価は「露出度・権限・代替経路」で判断する
セキュリティ変更は、正しさだけで進めると業務影響で止まります。優先順位は、次の3軸で決めると実務に落とし込みやすくなります。
| 評価軸 | 高リスクの例 | 判断基準 |
|---|---|---|
| 露出度 | インターネットから到達できる、広いIPレンジに開いている | 外部スキャンで見えるか、認証前に到達できるか |
| 権限 | 管理者、データ所有者、本番DBへの書き込み権限 | 侵害時に横展開やデータ流出へ直結するか |
| 代替経路 | Private Link、ZTNA、Bastion、JITへ移行可能 | 業務を止めずに閉じる現実的な手段があるか |
優先順位は、次の順で考えると失敗しにくくなります。
最優先は、公開されたRDP/SSHや管理用ポートです。これは攻撃者にとって探索しやすく、認証情報の総当たり、脆弱性悪用、設定ミスの影響を受けやすい領域です。
次に、機密データを保持するPaaSの公開アクセスです。Storage、SQL、Key Vaultのようなサービスは、private endpointへの移行とパブリックアクセス制限をセットで進めます。
その後、長期シークレットの排除を進めます。シークレットは「漏えいしたかどうか分からない」ことが多く、期限切れによる障害も起こしやすいため、マネージドIDやフェデレーション認証へ段階的に移します。
最後に、VPN型の広いネットワークアクセスをZTNAへ置き換えます。ユーザー体験への影響が出やすいため、パイロットグループ、業務アプリ単位、部門単位の順で進めるのが現実的です。
30日・60日・90日の実行計画
30日以内にやること
最初の30日は、閉じる前の可視化と即効性のある対策に集中します。
- インターネット公開IP、NSG、Azure Firewall、Application Gateway、公開PaaSを棚卸しする
- RDP/SSH/管理UIが外部公開されていないか確認する
- Microsoft Entraのアプリ登録から、有効期限が長いクライアントシークレットを抽出する
- Key Vault、CI/CD、アプリ設定に保存された接続文字列を確認する
- 機密データを扱うPaaSを「Private Endpoint移行候補」として分類する
- Microsoft Entra Private Accessの対象にする内部アプリを5〜10個選ぶ
この段階では、いきなり全社適用しないことが重要です。まずは高リスク資産を特定し、例外の所有者と期限を明確にします。
60日以内にやること
60日以内には、実際に公開面を減らします。
- 管理ポートの直接公開を停止し、Bastion、JIT、Private Accessなどへ移行する
- 重要なStorage、SQL、Key Vaultにprivate endpointを設定する
- DNS解決がPrivate EndpointのプライベートIPへ向くことを確認する
- 検証済みのPaaSからパブリックネットワークアクセスを制限する
- アプリの接続文字列をマネージドID認証へ切り替える
- Private Accessアプリに条件付きアクセスを適用する
この時点での成果指標は、「private endpointを何個作ったか」ではありません。公開アクセスが実際に減ったか、シークレットが減ったか、条件付きアクセスの対象になった内部アプリが増えたかで判断します。
90日以内にやること
90日以内には、再発防止の仕組みに移ります。
- Bicep、Terraform、Azure Policyなどで安全な標準テンプレートを作る
- 本番PaaSは原則private endpoint必須にする
- パブリックアクセスを許可する例外には期限、承認者、リスク理由を必須にする
- マネージドIDを標準化し、強すぎるRBACロールを検出する
- Private Accessのアプリセグメントを見直し、広すぎるIPレンジを縮小する
- コンプライアンス証跡として、例外一覧、アクセスログ、変更履歴を保存する
Microsoftのブログでも、長期的な対策としてプラットフォームエンジニアリングが強調されています。安全な標準ランタイム、ライブラリ、パイプライン、Policy-as-Codeを用意し、非推奨パターンをブロックすることで、チームごとの個別設定や例外によるリスクを減らすという考え方です。(Microsoft)
コンプライアンス担当者が見るべき証跡
compliance leadsにとって重要なのは、「安全にした」という説明ではなく、監査で確認できる証跡です。
確認すべき証跡は次の通りです。
| 証跡 | 確認内容 |
|---|---|
| 公開エンドポイント一覧 | インターネット到達可能な管理経路とPaaSの数が減っているか |
| Private Endpoint適用状況 | 機密データを持つ対象サービスに適用されているか |
| パブリックアクセス例外 | 期限、承認者、業務理由、代替計画があるか |
| シークレット一覧 | 長期シークレットが減り、マネージドIDへ移行しているか |
| 条件付きアクセス適用状況 | Private AccessアプリにMFA、デバイス準拠、認証強度が適用されているか |
| ログと監視 | サインインログ、Private Linkの監視、Global Secure Accessのログが確認できるか |
監査対応では、「全て閉じた」と言い切るよりも、「高リスク資産から順に閉じ、残る例外は期限付きで管理している」と説明できる状態を作るほうが現実的です。
platform architectsが標準化すべき設計パターン
platform architectsは、各チームに「private endpointを使ってください」「シークレットをなくしてください」と依頼するだけでは不十分です。チームごとに解釈が分かれると、設定ミスや例外が増えます。
標準化すべきパターンは次の通りです。
| 標準パターン | 含めるべき内容 |
|---|---|
| セキュアなPaaSテンプレート | private endpoint、Private DNS、診断ログ、タグ、パブリックアクセス制限 |
| マネージドID標準 | system-assigned / user-assignedの使い分け、RBACスコープ、ログ確認方法 |
| 内部アプリ公開標準 | Microsoft Entra Private Access、アプリセグメント、条件付きアクセス、ユーザー割り当て |
| 例外標準 | 期限、承認者、再評価日、リスク受容者、代替策 |
| 監視標準 | Azure Monitor、Microsoft Entraサインインログ、アラート、定期レビュー |
セキュリティチームが毎回レビューするのではなく、安全なテンプレートを使えば最初から基準を満たす状態にすることが大切です。これが、Microsoftのブログでいう「secure choiceをeasy choiceにする」発想です。
やってはいけない対策
最後に、よくある失敗を整理します。
1つ目は、private endpointを作っただけで満足することです。パブリックアクセスが残り、DNSも公開IPへ向いているなら、攻撃面は十分に減っていません。
2つ目は、ZTNAを導入しながら広いIPレンジを許可することです。Quick Accessに大きなネットワーク範囲を入れすぎると、VPNの過剰アクセスを別の名前で再現するだけになります。
3つ目は、マネージドIDに強すぎる権限を与えることです。シークレットは減っても、侵害時の影響範囲が大きければリスク低減としては不十分です。
4つ目は、全社一括でネットワーク制御を変えることです。Global Secure AccessやPrivate Accessのトラフィック転送プロファイルは、対象ユーザーやグループを絞って段階展開するほうが安全です。Microsoftのガイダンスでも、広すぎる割り当ては全社的な接続障害のリスクになり、狭すぎる割り当ては保護されないユーザーを生むと説明されています。(Microsoft Learn)
まず実行すべき次の一手
Microsoft recommends endpoint elimination plus private connectivity to reduce opportunistic attack surface の実務的な読み解きは、「公開面を減らす」「資格情報を減らす」「アクセスをアプリ単位に絞る」の3点です。
最初の一手として、次の3つを同時に始めてください。
- インターネット到達可能な管理ポートと公開PaaSを一覧化する
- 重要システムで使われている長期シークレットを抽出する
- 高リスクな内部アプリをMicrosoft Entra Private Accessの候補にする
その後、Azure private endpointsでデータプレーンを閉じ、Microsoft EntraのマネージドIDでシークレットを減らし、Zero Trust network accessで内部アプリへの到達範囲を最小化します。対策のゴールは、単に「外から見えない」状態ではありません。攻撃者が資格情報を得ても、到達できる場所が少なく、使える権限も小さく、異常なアクセスがログとして残る状態を作ることです。
コメント