VPNとBastion、Identity-aware Accessは何が違うのか
管理者接続を一つの方式に統一する理由はありません。Webの管理画面とCloud Consoleには、資源単位で利用者を許可するIdentity-aware Accessがよく合います。サーバーのSSH・RDPのセッションを統制し作業記録まで残すならBastionが有利です。複数のLegacy Protocol、専用Client、UDP、ネットワーク診断ツールを使う必要があるなら、接続範囲を限ったVPNがいまも現実的な選択です。
実運用では三つのうち一つだけを残すより組み合わせる場合が多くあります。Identity-aware Accessで利用者を確認したうえでBastionを経てSSHへつなぐ、あるいはVPNで管理網に入ったのち許可されたBastionを経てTarget Serverへ到達する形です。平時はIdentity-aware Accessを使い、その接続システムやIdPに障害が起きたときだけ別のVPNまたはBastionの経路をBreak-glassとして保つこともあります。したがって問いは「VPNが古いか、Zero Trustが新しいか」ではありません。誰が、どの端末で、どのProtocolを使い、正確にどの資源まで到達し、その過程でどんな証拠が残り、接続システムが故障したときにどう復旧するかを先に決めます。
NISTのZero Trust Architectureも、ネットワークの内側にいるという理由だけで利用者を信頼しません。利用者と端末を確認し、接続を資源とセッションの単位で許し、Identity・端末の状態・環境情報に応じて動的に判断するのが原則です。同時にNISTは、従来の境界基盤の接続とZero Trustの方式が相当の期間にわたり共存すると説明します。[1] 本稿は、人が管理画面、Cloud Control Plane、DB管理ツール、SSH・RDPのような管理Planeへ接続する経路だけを扱います。API要求でWAF・Gateway・JWT・mTLSが担う役割、Originへ直接迂回する露出経路、TLS証明書の発行・更新・廃棄はそれぞれ別の問題です。
VPNはネットワークへ到達する通路を作ります。IPsec VPNを基準に見れば、中心となる機能はIP Network Layerで通信を守ることです。接続後に利用者がどのSubnet、IP、Portへ到達できるかは、Routing、Firewall、ACL、Network Segmentationの方針が決めます。VPNだからといって社内網の全体を開く必要はありません。利用者グループごとのRouteとACLを分け、管理Subnetだけを許し、端末証明書・MFA・Device Postureを組み合わせれば済みます。問題はそれを行わなかったときです。VPN接続の成功を内部全体への信頼と読み替えると、一度奪われたアカウントや端末が広いNetwork Reachabilityを得ます。VPN Gateway自体も保護の対象です。NSAとCISAは、VPN Serverが保護されたネットワークへの進入点であるため攻撃者に狙われると指摘し、強い認証、速やかなPatch、不要な機能の無効化を勧めます。
Bastionは管理Protocolを統制された中継地点へ集めます。管理者はTarget Serverへ直接SSH・RDPでつながず、まずBastionを通ります。TargetはPublic IPや外部公開Portなしに Private Networkへ置き、Bastionから許可された対象とProtocolだけへ接続を限ります。Microsoftの現在のBastion Architectureも同じ構造を使います。BastionがVirtual Networkの中でPrivate IPのVMへRDP・SSH接続を中継し、Target VMはPublic IPがなくても構いません。ただしBastionが存在するという事実と、セッションが監査されるという事実は別です。単純なLinux Jump HostはSSH接続の時刻だけを記録し、実際の命令は残しません。Session Recordingも特定の等級や接続方式でのみ提供されることがあります。Azure Bastionの画面記録も別の機能であり、AWS Session ManagerはSSH・Port Forwardingの方式では内部Session Dataが再び暗号化されるため命令のLoggingを提供しないと明記します。セッション記録、Credential Brokering、一時的な権限、承認Workflowまで必要なら、単純なBastionよりPAM（Privileged Access Management）の機能を併せて検討します。
Identity-aware Accessは資源の手前で利用者とContextを判断します。利用者をまず内部ネットワークへ入れて移動させるのではなく、Application・Resource・Portの手前のProxyまたはBrokerがIdentityと方針を確認したうえで、その資源へ向かう経路だけを開きます。Google IAPを例にとれば、HTTPS Applicationの手前に中央のAuthorization Layerを置き、利用者やGroupごとに接続を許します。Context-awareの方針を組み合わせれば、IP、端末の属性、Patchの状態、時間、URL Pathのような条件も使えます。SSH・RDPを含むTCPの管理サービスも、実装によってはHTTPS Tunnelで中継します。しかしIdentity-awareという名前だけですべての実装が同じではありません。HTTP・HTTPSは比較的自然ですが、SSH・RDP・その他のTCPの対応は製品と配置方式によって異なります。UDP、Broadcast、古いThick Clientやネットワークの探索を要する道具は対応が難しく、別のVPNが要ることもあります。Identity-aware AccessもTargetの最終的な権限を代替しません。Brokerが「この利用者はこのサーバーのSSH Portへつないでよい」と判断しても、サーバーの中でRoot権限を持ってよいか、DBの特定のSchemaを変更してよいかは、Target OS・Application・DatabaseのAuthorizationが改めて判断します。[2]
- VPN
- VPNは遠隔の端末と組織のネットワークの間に保護された通信経路を作る方式であり、接続後にどこまで到達できるかはRouting、Firewall、ACL、Segmentationが決めます。
- Bastion
- Bastionは管理者がTarget Serverへ直接つながず必ず経由する統制された中継地点であり、許可された対象とProtocolだけに接続を限ります。
- Identity-aware Access
- Identity-aware Accessは利用者を内部ネットワークへ入れる代わりに、資源の手前のProxyやBrokerがIdentityと方針を確認し、その資源へ向かう経路だけを開く方式です。
製品の比較より先に決める五つの問い
第一に、誰が接続するのか。内部の管理者、開発者、外注の保守業者、Vendor Support、自動化システムを区別します。
第二に、どの端末から接続するのか。会社が管理する端末だけを許すか、個人端末や外部業者の端末を許すかを決めます。
第三に、どのProtocolが必要か。HTTPSだけでよいのか、SSH・RDP・DB Client・File Transfer・UDP・Legacy Toolまで要るのかを確認します。
第四に、正確にどこまで到達する必要があるか。管理画面一つか、特定のサーバーか、管理Subnet全体か、複数拠点のNetworkかを区別します。
第五に、どんな証拠と復旧経路が必要か。接続時刻だけでよいのか、許可方針と端末の状態を残すのか、実際の命令・画面まで記録するのか、IdP障害時に誰がどう入るのかを決めます。
この五つを書き出さなければ、最新の製品を導入しても従来の広い接続権限と不明確な運用手順をそのまま持ち込むことになります。
サービスの前段でリクエストを分類・防御 — リクエストと遮断記録から防御ルールを調整し、証明書とアクセス制御も管理します。
Identityと到達範囲、Protocolを比較します
下の表の等級は、特定の標準やVendorが公式に付与した等級ではありません。NISTのZero Trust原則とVPN指針、[1] Cloud-native環境の接続統制モデル、[2] MicrosoftのBastion Architecture、GoogleのIdentity-aware Accessの文書を、本稿の意思決定の問いに合わせて統合した編集判断です。製品と構成によって実際の機能は変わります。
判断の軸 | VPN | Bastion | Identity-aware Access |
|---|---|---|---|
| User Identity | IdP・MFA・Client Certificateと連携できるが、認証は通常Tunnelへの進入を許すもので、各Targetの権限は別である | BastionのログインIdentityとTarget OS・DBのアカウントが分かれる。PAM連携時は一時権限とCredential Brokeringが可能になる | User・Group・Role・Resourceが方針の中心である。資源ごとの許可と回収が比較的自然である |
| Device Identity / Posture | Client Certificate、MDM、EDR・Posture検査と連携できるが、製品と設定への依存が大きい | 基本のJump Hostだけでは利用者Endpointの状態を確認できない。Bastionの手前で別の検査が要る | 端末の所有、暗号化、Patchの状態、位置のようなContextを方針へ入れやすい。実装ごとの対応範囲は確認が要る |
| Network Reachability | 許可RouteとACLの範囲だけNetworkに到達する。Segmentationが弱ければ範囲が広がる | 利用者はBastionまで到達し、Bastionだけが許可されたTargetへつなぐ | 一般のNetworkを開くのではなく、特定のApplication・Resource・Portへ向かう経路を許す |
| Protocol Support | IP基盤のProtocolとLegacy Toolの対応に最も柔軟である。UDPや専用Clientが要る環境に向く | SSH・RDPに最もよく合う。DB・File Transfer・Custom Portは製品とProxyの方式によって変わる | HTTPSが最も自然である。SSH・RDP・一部のTCPも可能だが、UDP・Broadcast・Legacyの互換性は限られる |
| Least Privilege | Route・Subnet・Port・User Groupを細かく分ける必要がある。VPN自体が最小権限を作るわけではない | Bastionが接続するTarget、Port、Accountを限る必要がある。Bastionが管理網全体に到達すれば空白が残る | 資源・利用者・セッション単位の方針に向く。ただしTarget内部の権限は引き続き別に制限する |
| Credential Exposure | VPNは伝送経路を守るだけで、TargetのPasswordやSSH Keyをなくすわけではない | CredentialをBastionへ集める設計も、一時鍵やBroker方式で露出を減らす設計もある。設計差が大きい | Federationと短命Tokenで静的な秘密を減らす。Legacy Targetは依然として別のPasswordや鍵を要求する |
| Third-party Access | 専用Profile・管理Subnet・接続時間・Routeを分けなければ、外部業者へ広い接続を与えることになる | 特定サーバーに対する限定的なSSH・RDP保守に適する。作業Sessionの記録も結び付けやすい | 特定のApplication・Resourceだけを外部Identityへ許すのに向く。Federationと対象Protocolの対応が前提である |
監査と可用性、復旧を比較します
IdentityとProtocolだけで決めると、障害の時点で管理Plane全体が閉じる設計になります。監査の範囲、可用性の依存、運用の複雑さ、非常時接続、Break-glass、回収の手順を同じ表で併せて見ます。
判断の軸 | VPN | Bastion | Identity-aware Access |
|---|---|---|---|
| Session Audit | 誰がいつTunnelへつないだかは残るが、Targetで何をしたかは別のログが要る | 接続対象と時間を中央で確認しやすい。命令・画面の記録はProxy・PAM・製品機能を別に構成する必要がある | 誰がどの資源に許可・拒否されたかのDecision Logを残しやすい。実際の命令やApplication内部の行動までは含まない |
| Availability | VPN Gateway、IdP、DNS、Routingが運用依存になる。HAとPatchの戦略が要る | Bastion InstanceまたはManaged Service、Route、Targetのアカウントがすべて可用でなければならない。単一のJump Hostは単一障害点になる | IdP、Policy Engine、Proxy・Connectorが接続のControl Planeになる。複製と別のEmergency Pathが要る |
| Operational Complexity | Clientの配布、Route、Split Tunnel、Firewall、Gateway Patch、Capacityを管理する | Host Hardening、Patch、Scaling、Target Allowlist、アカウント、Session Storageを運用する。Managed Bastionは一部の負担を減らす | IdP、Resource Inventory、Policy、Connector、Device Management、Log Integrationを併せて管理する。初期の方針設計の負担が大きい |
| Emergency Access | 独立したVPN Gatewayと管理網を復旧経路に使える。平時の権限と分ける必要がある | 限定的なEmergency Bastionを復旧の中継地点に使える。主Bastionと同じ障害領域なら意味がない | 平時の接続には強いが、同じIdP・Policy Engineの障害は迂回できない。独立したEmergency Identity・Routeが要る |
| Break-glass | 別のアカウント・認証・Route・承認・警報を事前に構成する。全Networkを自動で開くFail-openは避ける | Emergency BastionとTargetのアカウントを事前に構成し、使用後にCredentialを回転する | 同じFederation・Conditional Policyに縛られないEmergency IdentityまたはBackup IdPが要る |
| Revocation | VPN Sessionの終了とアカウント・Certificateの廃棄だけでなく、Targetの既存Session・Credentialも回収する必要がある | Bastion Sessionの終了、Bastion権限の回収、Target Account・鍵・持続Sessionの除去が要る | 中央の方針とTokenは速やかに回収できるが、Cached SessionとTarget内部の権限は別に終了させる必要がある |
状況別に何から選ぶか
Webの管理画面が中心ならIdentity-aware Accessから見ます。内部運用のBackoffice、Grafana、CI/CDの管理画面、Database Web ConsoleのようにHTTPSで接続する資源はIdentity-aware Accessとよく合います。利用者・Groupごとに資源を分け、会社管理の端末や特定の時間帯のようなContextの条件を付けやすくなります。とくに外部の開発会社や保守業者へApplicationを一つだけ開くなら、管理Network全体をつなぐVPNより資源単位の方針のほうが接続範囲を説明し回収しやすくなります。ただしAccess Proxyを有効にしたからといって、既存の直接接続経路まで自動で消えるわけではありません。Google IAPも、Administrative ResourceでIAPを有効にするだけではDirect Requestが自動的に遮断されるわけではないと明記します。接続Brokerを迂回するHostname・IP・Portが残っていないかは別に検証します。
Private ServerのSSH・RDPが中心ならBastionを見ます。運用サーバーへ直接SSH・RDPを開きたくなく、誰がどのサーバーへ接続したかを中央で統制する必要があるならBastionが自然です。ここに実際の作業の証拠が必要なら、六つを別に確認します。単なる接続履歴か、Shell Commandを記録するか、RDPの画面を記録するか、Native ClientとBrowser Clientの両方が記録されるか、File TransferとPort Forwardingも監査されるか、記録が変更不能な別の保管庫に保存されるかです。「Session Recording対応」という機能名だけを見ず、使うProtocolとClientの経路が実際のRecordingの範囲に入るかを見ます。
複数のLegacy Protocolと専用の道具が必要ならVPNを保っても構いません。管理作業にSSH・RDPだけでなく複数のTCP・UDP Port、Vendor専用Client、Network Discovery、機器管理Protocolが必要ならVPNのほうが単純です。このときVPNを社内網全体への進入権にしないことが重要です。別の管理網、利用者ごとのRoute、Target Allowlist、MFA、端末認証、接続時間の制限を適用します。VPN接続の後もTargetの認証とAuthorizationは改めて行います。VPNを保つことはZero Trustを諦めることではありません。ネットワーク上の位置に自動の信頼を与えず、利用者・端末・資源ごとに権限を減らし継続して回収できるなら、既存の接続経路にもZero Trustの原則が適用できます。[1]
三つの方式はどう組み合わせられるか
Identity-aware AccessとBastionの組み合わせが最も一般的です。管理者のUser IdentityとMFA、Device PostureをIdentity-aware Accessが確認し、Resource PolicyとAccess Decision Logを残します。そのうえでBastionまたはPAMがSSH・RDPのProtocolを中継し、Target AccountとCredentialを統制し、Session Recordingを残して管理対象のサーバーへつなぎます。Identity-aware Accessの層は誰がBastionを使えるかを判断し、Bastionはどのサーバーへどのアカウントで接続し実際のSessionで何をしたかを統制します。
VPNとBastionの組み合わせは、Legacy Toolのために VPNが必要でありながら管理網全体への直接接続は許したくないときに使います。管理者の端末から限定的なVPNへ入るとBastionのアドレスだけがReachableになり、BastionまたはPAMを経て承認されたTargetへ到達します。VPNの利用者がTarget Serverへ直接つながるなら、Bastionを置いた目的が弱まります。RouteとFirewall PolicyがBastionの経由を強制する必要があります。
Identity-aware Accessと限定的なVPNの組み合わせもあります。管理者向けWeb ApplicationはIdentity-aware Accessへ移し、一部のLegacy Network Toolだけを別のVPNへ残します。すべてのProtocolを一度に移行しにくい組織にとって現実的な移行の形です。NISTも、大規模な組織が一度の技術の入れ替えでZero Trustへ移ることは難しく、業務の流れごとに従来の方式と新しい方式が共存すると説明します。[3]
平時のIdentity-aware Accessに独立したEmergency Pathを加える組み合わせもあります。平時は資源単位のIdentity-aware Accessを使い、IdPや方針システムの障害に備えて別のEmergency Identityと限定的なVPNまたはBastionを保ちます。ただし見かけ上は経路が二つでも、実際には同じIdP、DNS、MFA Service、Network Connectorに依存しているなら独立した復旧経路ではありません。構成要素ごとの障害依存を描いてみます。
接続ログと方針判断ログ、セッション記録を区別します
管理者接続を監査するには、「ログがあるか」ではなくどの問いに答えられるかを確認します。Identity-aware AccessはAccess Decisionの説明に強い一方、実際のShell Commandを自動では記録しません。Bastionは接続の経路を集めますが、単純なJump Hostなら命令の記録がありません。VPNはTunnelの接続を記録してもTarget Applicationの内部の行動までは把握しません。
Google IAPのAudit Logは利用者、Source IP、要求資源、許可の可否といった情報を提供します。Azure Bastionは現在接続中の利用者、Target VM、Source IP、接続の時刻と時間を示し、別の機能として画面記録に対応します。こうした情報だけで最終的な変更の内容をすべて再構成できるかは、TargetのOS・Application・Database Auditと併せて判断します。
Evidence Level | 答えられる問い | 代表的なEvidence |
|---|---|---|
| Connection Log | 誰がいつどこからどのGatewayまたはTargetへつないだか | VPN Login、Bastion Connection、Source IP、Target、Session Duration |
| Access Decision Log | どのIdentity・端末状態・Group・方針によって許可または拒否されたか | Policy Version、Device Posture、Access Level、Authorization Result |
| Session / Action Audit | 接続後に実際にどの命令・画面・設定変更を行ったか | Shell Command、RDP Recording、Application Audit、DB Query Audit |
監視から復旧・改善までつながる運用 — サービス指標とアラートを基準に対応し、変更履歴と事後報告を次の改善につなげます。
接続システム自体をProduction Dependencyとして管理します
Zero TrustまたはIdentity-aware Accessを導入すると、保安のControl Planeが新しい運用依存になります。NISTは、Policy Engine、Policy Administrator、Policy Enforcement Pointが停止すると資源への接続そのものが塞がれ、組織の運用が影響を受けると指摘します。これはZero Trustだけの問題ではなく、Legacy Remote-access VPNにも同様の障害の危険があります。[1] したがって接続のアーキテクチャには、正常な流れだけでなく失敗の方針も要ります。
管理者接続で自動のFail-openは便利に見えますが、方針システムの障害がそのまま管理Plane全体の公開につながります。高リスクの環境では平時の経路を自動で広げるより、限定的なBreak-glassの経路を別に作るほうが賢明です。
失敗した構成要素 | 平時の既定方針 | 事前に設計する例外 |
|---|---|---|
| IdP・Federation | 管理者接続は原則としてFail-closed | 同じFederationに依存しないEmergency IdentityまたはBackup IdP |
| Policy Engine・Access Broker | 高リスク資源への接続を停止 | 別のEmergency Gateway・Bastionと限定されたTarget Role |
| Device Posture Service | 条件を黙って無視しない | 承認済みのSecure Workstationから限られた時間・資源のみ許可 |
| Session Recording | 高リスクの変更は停止するか別途承認 | 独立したLogと手書きのIncident Recordを併用する限定的なEmergency Session |
| 中央Log Sink | Local Bufferまたは制限モード | 独立した保管庫・手書きEvidence・事後のReconciliation |
| Primary Bastion | Targetの直接公開を禁止 | 別の障害領域のEmergency BastionまたはCloud ConsoleのRecovery Path |
Break-glassは事前に設計し監査します
Break-glassは正常な統制をひそかに迂回するBackdoorではありません。正常な接続システムが故障したときにも限られた人員が必要な復旧作業を行えるよう、事前に設計し監査する非常時の運用手順です。Microsoft、Google Cloud、AWSの公式指針は共通して、Emergency Identityの冗長性、平時のIdentity Chainと異なる依存、強い認証、すべての使用に対する警報、定期試験と使用後のCredential回収を強調します。
発動条件と責任では五つを見ます。Break-glassを使える障害・保安事故の条件が文書化されているか。発動を承認するOwnerと代替の承認者が決まっているか。夜間・休日にも承認手順が働くか。関連するIncidentや変更Ticketなしに便宜のために使えないようにしたか。破壊的な作業には可能な場合に二人承認またはDual Controlを求めるか。
Emergency IdentityとCredentialでは六つを見ます。一つのアカウントや一つのHardware Keyが単一障害点にならないよう、二つ以上のEmergency IdentityまたはCredential Setがあるか。少なくとも一つのEmergency Identityが平時のFederation・SSO・Conditional Accessの障害で一緒に塞がれないか。平時の管理者アカウントとは異なる方式のPhishing-resistant MFAやHardware Credentialを使うか。CredentialとRecovery Deviceが互いに異なる安全な場所に保管されているか。自動休眠削除・期限切れ・人事異動の処理でアカウントが消えないか。Emergency Identityが平時の業務や自動化に使われていないか。
Reachabilityと権限では六つを見ます。Emergency Access Pathが事故の前にあらかじめ構成されているか。Network全体ではなく復旧に必要なManagement PlaneとTargetだけが到達可能か。許可Roleと命令の範囲が事前に決まっているか。可能なら権限とSessionに最大使用時間が設定されているか。Break-glassのために管理者Portや画面をInternetへ常時公開していないか。Cloud AccessとOn-premises Accessが一つの障害依存に縛られていないか。
監査と検知では五つを見ます。Emergency Identityの成功・失敗のログインごとに直ちに警報が出るか。利用者、時間、Source、Target、発動の理由、承認者を記録するか。可能な範囲でShell Command・画面・設定変更を別に記録するか。主たる接続システムとは別のLog保管場所にもEvidenceが残るか。記録システムが停止したときに使う手書きのIncident Log Templateがあるか。
試験と正常化では六つを見ます。危険度に合った周期で実際のログインと限定的な管理作業を試験するか。試験にIdP障害、MFA障害、DNS障害、主Bastion障害の筋書きが含まれるか。担当者が文書だけを見て復旧経路を使えるか。使用が終わればすべてのSession・Token・Certificate・鍵を終了または回収するか。長期Credentialを使ったなら直ちに回転するか。行った命令と変更を点検し正常な接続経路へ戻ったかを確認するか。実際の使用または訓練の後にRunbookと権限の範囲を改めるか。
よく失敗する五つの設計
第一に、VPN接続を管理者権限と見なすことです。VPNはNetwork Reachabilityを提供します。VPNに入った利用者がすべての管理画面とServerへ接続してよいという意味ではありません。VPNの後ろでも利用者Identity、Target Authorization、Network Segmentationが要ります。
第二に、Bastionを置きながら迂回経路を残すことです。管理者はBastionを使うのに、TargetのSSH・RDP Portも別のRouteから直接到達できるなら、監査と統制は任意のものになります。Bastionの経由をArchitectureとNetwork Policyが強制する必要があります。
第三に、Bastionの接続記録を作業の証拠と判断することです。利用者AがサーバーBへ30分接続したという事実と、どの命令でどの設定を変えたという事実は別です。Session RecordingとTarget Auditを別に設計します。
第四に、Identity-aware Accessを有効にして直接接続の経路を確認しないことです。Access Proxyが動いていても、別のHostname、Direct IP、内部Route、管理Portが残っていればProxyの認証・方針を経ません。この問題の具体的な露出経路と遮断の方法はOrigin Securityの領域で別に扱います。
第五に、IdPのアカウントを無効にすればすべての接続が終わると考えることです。既に発行されたToken、VPN Tunnel、Bastion Session、Target OS Session、SSH Key、Local Accountが残っていることがあります。RevocationはIdentity、Access Path、Target Credential、Active Sessionをすべて確認して初めて終わります。
選択の結果を文で残します
接続の方式を選んだら、製品名より運用の文を残すほうが有用です。運用の管理画面は会社が管理する端末からのみIdentity-aware Accessを経て接続する。利用者とGroupは資源ごとに許可し、すべての許可・拒否の判断を中央のLogに記録する。Production ServerのSSHはBastionと一時アカウントを通じてのみ許す。Target Serverは管理者の端末から直接Reachableではなく、接続履歴とShell Auditを別に保存する。Legacy Network Toolは別の管理VPNでのみ使う。VPNの利用者はBastionと承認された機器のアドレスだけがReachableであり、一般業務のNetworkへは接続できない。IdPまたはAccess Brokerの障害時には事前登録したEmergency Identityと別のBastionを使う。すべての使用はIncidentとして宣言し、復旧後にSessionの終了・Credentialの回転・事後点検を行う。この文を書けないなら、製品は選んでいても接続のアーキテクチャはまだ決まっていません。
VPNは複数のProtocolとNetwork Toolをつなぐことに強みがあります。BastionはSSH・RDPのような管理Sessionを統制された中継地点へ集めることに強みがあります。Identity-aware Accessは利用者・端末・資源ごとの方針と許可の判断を中央化することに強みがあります。どれ一つとして単独で完全ではありません。VPNはTargetの権限と作業の監査を代替しません。Bastionは利用者端末の状態やApplication Authorizationを自動では解決しません。Identity-aware Accessはすべてのlegacy Protocolに対応するわけではなく、Target内部の権限と独立した復旧経路も別に要ります。
管理者接続の方式を決めるときは、Protocol、Resource Scope、User Identity、Device Trust、Credential、Audit、Availability、Break-glassの順序が適切です。「どちらがより新しいか」より、この順序で問いに答えるとき、平時は最小限に開き障害時には実際に復旧できる管理Planeができます。
