Microsoft Entra、Azure private endpoints、Zero Trust network accessを検討しているチームがまず押さえるべき結論は明確です。公開エンドポイントを残して後から守る設計ではなく、最初から到達できる場所を減らし、管理アクセスは仲介し、サービス間通信はトークンベースにすることが、2026年時点では標準設計になりつつあります。
背景にあるのは、攻撃者が高度な侵入経路だけでなく、公開された管理ポート、漏えいしたシークレット、例外だらけのネットワーク設定を狙う「機会型攻撃」です。Microsoftは2026年4月20日のSecurity Blogで、資格情報の削減、公開到達可能なエンドポイントの削減、Managed IdentityやPrivate Link、Bastionのような設計を組み合わせる重要性を示しています。(Microsoft)
この記事では、Cloud security architects、network security teams、platform engineersに向けて、private endpoints、brokered admin access、token-based service callsをどのように標準設計へ組み込むべきかを、判断基準と実装時の注意点まで具体的に整理します。
なぜ「追加のハードニング」ではなく「標準設計要件」になっているのか
従来のクラウド設計では、サービスを公開エンドポイントで作成し、あとからFirewall、IP制限、MFA、監査ログ、シークレットローテーションを追加する流れがよくありました。小規模な環境では一見うまく見えますが、サービス数、リージョン数、開発チーム数が増えると、例外設定が増え、どこに公開口が残っているか把握しづらくなります。
Microsoftのブログでは、攻撃者は必ずしも「ネットワークを破る」のではなく、盗まれた資格情報でログインすることが多いと説明されています。また、ワークロードがシークレットなしで認証できるならそうすべきであり、AzureではManaged IdentityやフェデレーションされたIDパターンによって、保存・ローテーション・期限切れ対応が必要なパスワード、クライアントシークレット、APIキーを減らせるとしています。(Microsoft)
重要なのは、これらを個別のセキュリティ施策として扱わないことです。private endpointだけを導入しても、RDP/SSHが公開されていれば管理面の攻撃対象は残ります。Managed Identityを導入しても、ネットワークが誰からでも到達可能なら探索や誤設定のリスクは下がりません。
2026年時点の実務的な設計方針は、次の3点をセットで考えることです。
| 設計要件 | 従来ありがちな設計 | これからの標準設計 | 主な狙い |
|---|---|---|---|
| Private endpoints / private connectivity | PaaSを公開エンドポイントで作成し、IP制限で守る | Azure Private Link / private endpointでVNet内のプライベートIP経由にする | インターネットから探索される面を減らす |
| Brokered admin access | VMにPublic IPを付け、RDP/SSHを制限付きで開ける | Azure Bastion、JIT、Serial Console、Microsoft Entra Private Accessなどで仲介する | 管理ポートの直接公開を避ける |
| Token-based service calls | 接続文字列、APIキー、クライアントシークレットをアプリに保存する | Managed Identity、Workload Identity、OAuthトークンで認可する | 漏えい・再利用・期限切れによる事故を減らす |
Azure private endpointsは「公開しない」ための基本部品
Azure private endpointは、Azure Private Linkを利用するサービスへ、仮想ネットワーク内のプライベートIPアドレスで接続するためのネットワークインターフェイスです。Azure Private Linkでは、Azure PaaSやPrivate Link対応サービスへの通信がMicrosoft backbone networkを通り、パブリックインターネットへの露出を減らせます。(Microsoft Learn)
つまりprivate endpointは、単なる「通信経路の暗号化」ではありません。設計上の価値は、攻撃者がインターネット側から見つけられる入口を減らすことにあります。
private endpointを優先すべきリソース
すべてのリソースを一気にprivate endpoint化する必要はありません。まずは、侵害時の影響が大きいデータプレーンから優先します。
| 優先度 | 対象例 | 判断基準 |
|---|---|---|
| 高 | データベース、Storage、Key Vault、メッセージング基盤 | 機密データ、鍵、接続文字列、業務データを扱う |
| 高 | CI/CDや自動化基盤が接続するサービス | ビルドエージェントや運用スクリプトから定常的にアクセスする |
| 中 | 内部API、業務アプリ、管理用ポータル | 社内・特定拠点・特定ワークロードだけが利用する |
| 中 | ログ、監視、診断データの送信先 | 障害時に止められないため、DNSと経路設計を慎重に行う |
| 低 | 一般公開が前提のWebフロント | WAF、DDoS対策、認証、Bot対策など別の保護を優先する |
判断の目安は「そのサービスは、世界中のインターネットから名前解決・接続試行される必要があるか」です。必要がないなら、private endpoint化を標準候補に入れるべきです。
DNS設計を後回しにしない
private endpoint導入で最も失敗しやすいのはDNSです。Microsoft Learnでは、private endpointのIPアドレスを接続先FQDNに解決するため、DNS設定を正しく構成することが重要だと説明しています。また、既存のAzureサービスには公開エンドポイント向けDNS構成があるため、private endpoint利用時には解決を上書きする必要があります。(Microsoft Learn)
よくある失敗は次の通りです。
| 失敗パターン | 起きる問題 | 対策 |
|---|---|---|
| private endpointだけ作成し、DNSを未整備 | アプリが引き続き公開エンドポイントへ接続する | Private DNS ZoneをVNetにリンクし、名前解決結果を確認する |
| 1つのPrivate DNS Zoneに複数サービスを雑に混在 | Aレコードの競合や名前解決不良が起きる | サービスごとの推奨ゾーン名に従う |
| オンプレミスDNSとの連携を考えない | VPN/ExpressRoute越しのクライアントだけ接続できない | 条件付きフォワーダーやAzure DNS Private Resolverを設計に入れる |
| パブリックアクセスを残したまま満足する | 攻撃面削減の効果が限定的になる | サービス側のPublic network accessやFirewall設定も確認する |
private endpointは「作成したら終わり」ではありません。名前解決、経路、サービス側の公開設定、監視ログまでセットで確認して初めて、安全なプライベート接続になります。
Brokered admin accessでRDP/SSHを直接公開しない
管理アクセスは、攻撃者にとって非常に分かりやすい入口です。RDPの3389番、SSHの22番をインターネットへ公開し、送信元IP制限だけで守る設計は、現在では例外扱いにすべきです。
Azure Bastionは、Azure portalまたはローカルのSSH/RDPクライアントから、TLS経由でVMへ接続するフルマネージドPaaSです。Azure BastionはVNetに直接デプロイされ、private IPを使ってVMへ接続できるため、VM側にPublic IP、エージェント、特別なクライアントソフトウェアを必要としません。(Microsoft Learn)
Bastionを使うべき場面
Azure Bastionは、次のようなケースで特に有効です。
| 場面 | 推奨アプローチ |
|---|---|
| Azure VMへ一時的にRDP/SSHしたい | Azure Bastion経由にし、VMのPublic IPを削除する |
| 運用者ごとにアクセス制御したい | Microsoft Entra ID、RBAC、PIM、条件付きアクセスと組み合わせる |
| 管理操作の証跡が必要 | Bastion Premiumのセッション記録などを検討する |
| より閉じた管理経路にしたい | Private-only Bastionを検討する |
Private-only Bastionでは、Bastionホスト自体へのPublic IP経由接続を許可せず、private IPアクセスのみを可能にする構成が用意されています。要件やSKUの制約はありますが、管理面の公開範囲をさらに小さくしたい環境では有力な選択肢です。(Microsoft Learn)
Microsoft Entra Private Accessとの使い分け
Azure Bastionが主にAzure VMへの管理接続を仲介するのに対し、Microsoft Entra Private Accessは、社内アプリやオンプレミスリソースなどのプライベートリソースへのアクセスを、ID中心のZero Trust Network Accessとして制御する位置づけです。
Microsoft Entra Private Accessでは、FQDNやIPアドレスでプライベートリソースを指定し、Global Secure Access Clientを通じてアクセスできます。Remote workersは、条件を満たせば従来型VPNなしで内部リソースへアクセスでき、Conditional Accessによる制御も組み込めます。(Microsoft Learn)
ざっくり整理すると、次のようになります。
| 用途 | 向いているサービス |
|---|---|
| Azure VMへのRDP/SSH管理 | Azure Bastion |
| オンプレミスや社内アプリへのユーザーアクセス | Microsoft Entra Private Access |
| 一時的な高権限運用 | PIM、JIT、Bastion、条件付きアクセスの組み合わせ |
| 緊急時の低レベル管理 | Serial Consoleなど、通常経路とは別の手段を設計 |
ポイントは、管理アクセスを「ネットワーク的に開ける」のではなく、誰が、どの条件で、どのリソースに、どの時間だけ接続できるかとして設計することです。
Token-based service callsでシークレットを持たないサービス間通信へ移行する
サービス間通信では、接続文字列、APIキー、クライアントシークレットをアプリケーション設定やCI/CD変数に保存する設計が長く使われてきました。しかし、これらは漏えい、期限切れ、ローテーション漏れ、リポジトリへの誤コミットの原因になります。
Managed Identityを使うと、Azureリソース上で動くアプリケーションは、資格情報をコードや設定に持たずにMicrosoft Entraトークンを取得し、対応するリソースへアクセスできます。Microsoft Learnでも、Managed Identityは開発者が資格情報を管理する必要をなくし、アプリケーションが資格情報なしでMicrosoft Entraトークンを取得できると説明されています。(Microsoft Learn)
実装時の基本パターン
典型的な構成は次の通りです。
| ステップ | 実施内容 |
|---|---|
| IDを割り当てる | App Service、VM、AKS、Functionsなどにsystem-assignedまたはuser-assigned managed identityを割り当てる |
| 権限を付与する | Storage、Key Vault、SQLなどの対象リソースに対し、必要最小限のRBACやデータプレーン権限を付与する |
| SDKを使う | Azure IdentityライブラリやMSALを使い、シークレットではなくトークンで認証する |
| ネットワークを閉じる | private endpointやFirewallで、認可されたネットワーク・ワークロードからのみ到達可能にする |
| 監査する | Microsoft Entraサインインログ、Azure Activity logs、リソースログで利用状況を確認する |
system-assignedとuser-assignedの選び方
Managed Identityにはsystem-assignedとuser-assignedがあります。どちらか一方が常に正解ではありません。
| 種類 | 向いているケース | 注意点 |
|---|---|---|
| system-assigned managed identity | 単一リソースに固有の権限を持たせたい。リソース削除時にIDも消したい | リソース再作成時にIDも変わるため、権限再付与が必要になる場合がある |
| user-assigned managed identity | 複数リソースで同じ権限を使いたい。事前に権限付与したIDを使いたい | 使い回しすぎると権限範囲が広がる。不要になったIDを手動で削除する必要がある |
Microsoft Learnでは、複数リソースが同じリソースへアクセスする場合はuser-assigned identityで管理負荷を下げられる一方、各リソースに固有の権限が必要な場合や、リソース削除時にIDも削除したい場合はsystem-assigned identityが適すると説明されています。(Microsoft Learn)
トークンベースでも「権限を広げすぎない」
トークンベースにすれば安全、というわけではありません。アクセストークンは認可のためのセキュリティトークンであり、扱いを誤るとリスクになります。Microsoft identity platformのドキュメントでも、アクセストークンはセンシティブな資格情報として扱うべきだと説明されています。(Microsoft Learn)
特に注意したいのは、Managed Identityに強すぎる権限を与えることです。たとえば、アプリの実行権限を持つユーザーがそのアプリ上でコードを実行できる場合、そのアプリに割り当てられたManaged Identityの権限も間接的に使える可能性があります。Microsoft Learnでも、コードを実行できるリソースに管理アクセスを与える場合、そのManaged Identityの権限を考慮する必要があると説明されています。(Microsoft Learn)
実務では、次のように設計します。
- 「Reader」「Contributor」などの広いロールを安易に付与しない
- データプレーン権限と管理プレーン権限を分ける
- 本番、検証、開発でManaged Identityを分ける
- 同じuser-assigned identityを多数の無関係なアプリで共有しない
- 権限変更の反映遅延を考慮し、緊急遮断手順を用意する
Managed Identityのグループやロールメンバーシップ変更は、トークン更新まで反映に時間がかかることがあります。Microsoft Learnでは、Managed Identityトークンは基盤側でキャッシュされ、変更が反映されるまで数時間かかる場合があると説明されています。(Microsoft Learn)
Zero Trust network accessでは「ネットワーク信頼」から「IDと条件」へ移す
Zero Trust network accessの本質は、社内ネットワークにいるから安全、VPNに入ったから信頼できる、という前提を捨てることです。Microsoft Entraは、ID、アクセス条件、権限、接続チャネル、侵害の監視を組み合わせてZero Trust戦略を実装するための製品群として位置づけられています。(Microsoft Learn)
この考え方をAzure設計へ落とすと、次のようになります。
| レイヤー | 設計の考え方 |
|---|---|
| ネットワーク | 公開エンドポイントを減らし、private endpointやPrivate Linkで閉じる |
| ID | ユーザー、ワークロード、AIエージェントを個別のIDとして扱う |
| アクセス制御 | 条件付きアクセス、PIM、RBAC、最小権限で制御する |
| 管理アクセス | RDP/SSHを直接開けず、BastionやPrivate Accessで仲介する |
| サービス間通信 | シークレットではなく、Managed IdentityやWorkload Identityでトークン認可する |
| 監査 | サインインログ、Activity logs、リソースログ、セッション記録を集約する |
Microsoft Entra Private Accessのラボドキュメントでも、ZTNAとしてオンプレミスリソースへ細かいアクセスを提供し、Conditional Access、Continuous Access Evaluation、Privileged Identity Managementなどでアクセスセキュリティを強化できると説明されています。(Microsoft Learn)
実装ロードマップ：どこから着手すべきか
private endpoints、Bastion、Managed Identityをいきなり全社導入しようとすると、DNS、権限、運用手順、コスト、例外処理が同時に発生して失敗しがちです。最初は「攻撃面をどこから減らすと効果が大きいか」で順序を決めます。
| フェーズ | やること | 成果物 |
|---|---|---|
| 現状把握 | Public IP、公開PaaS、RDP/SSH、保存済みシークレットを棚卸しする | 攻撃面インベントリ |
| 優先順位付け | データ、鍵、管理アクセス、CI/CD経路を高優先にする | 移行対象リスト |
| private connectivity化 | Private Link、private endpoint、Private DNS Zoneを設計する | プライベート接続テンプレート |
| 管理アクセスの仲介 | Bastion、JIT、Entra Private Access、PIMを導入する | 管理アクセス標準 |
| シークレット削減 | Managed Identity、Workload Identity、OAuthへ移行する | シークレット廃止計画 |
| 標準化 | IaC、Azure Policy、テンプレート、CI/CDチェックに組み込む | platform guardrails |
| 監査と改善 | ログ、例外、未対応リソースを継続監視する | セキュリティ運用ダッシュボード |
特に効果が大きい最初の一手は、本番環境の管理ポートとデータストアの公開経路をなくすことです。公開されたVMのRDP/SSH、StorageやSQLの広い公開設定、長期間使われているクライアントシークレットは、攻撃者にとって分かりやすい入口になります。
アーキテクチャ例：Azure上の業務アプリを閉じる
たとえば、グローバル企業がAzure上で業務アプリを運用している場合、次のような設計が現実的です。
| コンポーネント | 推奨設計 |
|---|---|
| フロントエンド | 公開が必要な場合のみWAFや認証を前段に配置する |
| アプリケーション | App Service、AKS、FunctionsなどにManaged Identityを割り当てる |
| データベース | Azure SQLやCosmos DBはprivate endpoint経由にする |
| シークレット管理 | Key Vaultはprivate endpoint化し、アプリはManaged Identityでアクセスする |
| 管理アクセス | VMや踏み台を直接公開せず、Azure BastionまたはEntra Private Accessを使う |
| 名前解決 | Private DNS ZoneをハブVNetまたは共通DNS設計に組み込む |
| 権限 | RBACとデータプレーン権限を分け、最小権限で付与する |
| 監査 | Entraサインインログ、Activity logs、診断ログをSIEMへ送る |
この構成では、アプリケーションはインターネットへ公開されたデータベース名や接続文字列に依存しません。管理者もVMへ直接RDP/SSHしません。サービス間通信はManaged Identityで発行されたトークンを使い、ネットワーク経路はprivate endpointで閉じます。
結果として、攻撃者が外部からスキャンして見つけられる入口、盗んで再利用できるシークレット、横展開に使える共有資格情報を同時に減らせます。
失敗しやすいポイントと回避策
private endpointを作っただけで安心する
private endpointを作成しても、サービス側のPublic network accessが残っていたり、DNSが公開エンドポイントを向いたままだったりすると、期待した攻撃面削減になりません。作成後は、クライアントからの名前解決結果、接続元IP、リソース側ログを必ず確認します。
Bastionを入れてもVMのPublic IPを残す
Azure Bastionを導入したのに、既存VMのPublic IPやNSGのRDP/SSH許可が残っているケースがあります。この状態では「別経路を追加しただけ」です。Bastion経由で運用できることを確認したら、不要なPublic IPとインバウンド許可を削除します。
user-assigned managed identityを共有しすぎる
user-assigned managed identityは便利ですが、複数アプリで使い回すと、1つのアプリ侵害で広い権限が使われる可能性があります。同じ業務機能、同じ権限範囲、同じライフサイクルのリソースに限定して共有するのが安全です。
条件付きアクセスだけに頼る
条件付きアクセスは重要ですが、公開エンドポイントや管理ポートが多い状態をすべて補えるわけではありません。Zero Trustでは「アクセスを評価する」だけでなく、「そもそも到達できる対象を減らす」ことも同じくらい重要です。
例外を恒久化する
「このシステムだけ一時的にPublic IPを許可」「このチームだけシークレット認証を継続」といった例外は、期限と所有者を決めないと恒久化します。例外はチケット化し、期限、理由、代替案、レビュー日を必ず設定します。
組織標準に落とし込むためのチェックリスト
実装を個別チーム任せにすると、private endpointやManaged Identityの導入状況にばらつきが出ます。platform engineeringの観点では、セキュアな選択肢を「使いやすい標準」として提供することが重要です。Microsoftのブログでも、標準化されたpaved pathsにより、セキュリティを後付けではなく設計に組み込む考え方が示されています。(Microsoft)
導入時は、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| 公開エンドポイント | 本当にインターネット公開が必要か。不要ならprivate endpoint化できるか |
| 管理ポート | RDP/SSH/WinRMなどがインターネットに開いていないか |
| DNS | Private DNS Zone、オンプレミスDNS、フォワーダー設計が整っているか |
| シークレット | APIキー、クライアントシークレット、接続文字列をManaged Identityへ置き換えられるか |
| 権限 | IDごとに最小権限になっているか。環境ごとに分離されているか |
| IaC | Terraform、Bicep、ARMテンプレートで標準構成を再利用できるか |
| Policy | Public IP作成、公開PaaS、広すぎるNSGを検出・禁止できるか |
| 監査 | 誰が、いつ、どのIDで、どのリソースへアクセスしたか追跡できるか |
| 例外管理 | 例外に期限、責任者、レビュー日があるか |
| 運用手順 | 障害時、権限剥奪時、DNS不具合時の手順があるか |
まず次に取るべき行動
Microsoft Entra、Azure private endpoints、Zero Trust network accessをこれから設計するなら、最初にやるべきことは新機能の比較ではありません。自社環境の「到達できる入口」と「盗まれる可能性のある資格情報」を棚卸しすることです。
優先順位は次の順で考えると実行しやすくなります。
- 本番VMのPublic IP、RDP、SSHを洗い出す
- 機密データを扱うPaaSの公開エンドポイントを洗い出す
- 長期間使っているクライアントシークレット、APIキー、接続文字列を洗い出す
- 高リスクなものからBastion、private endpoint、Managed Identityへ移行する
- Azure Policy、IaC、CI/CDチェックで「安全な構成」を標準化する
private endpoints、brokered admin access、token-based service callsは、もはや「余裕があれば追加する強化策」ではありません。公開面を減らし、管理アクセスを仲介し、サービス間通信からシークレットをなくすことが、AzureとMicrosoft Entraを使うクラウド基盤のデフォルト設計になりつつあります。
まずは1つの重要システムを選び、公開エンドポイント、管理ポート、保存済みシークレットを可視化してください。そこからprivate connectivity、BastionまたはEntra Private Access、Managed Identityへ順に置き換えることで、機会型攻撃に強いクラウド設計へ現実的に移行できます。
コメント