MS_AzureBastion - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

Azure Bastion

概要

インターネットからの接続のためのシン・クライアントの DaaS。

補足（何を解決するのか）: RDPで述べたとおり、
インターネットに 3389 / 22 を開けてはならない。
Bastion はこの問題への Azure 純正の答えである。

従来の踏み台 VM Azure Bastion
パブリック IP 踏み台に必要 どの VM にも不要
開けるポート 3389 / 22 無し（HTTPS 443 のみ）
運用 OS の更新・監視は自分 マネージド
クライアント RDP / SSH クライアント ブラウザだけ（HTML5）

「踏み台サーバーそのものを自分で持たなくてよい」点が最大の価値になる。

詳細

  • 利用中の仮想ネットワークにプロビジョニングされる。
  • 対象の VM にはパブリック IP アドレスは不要。

価格

  • 21.28 / 時間（1.5万/月）に加え、通信費用が発生する。
  • オンデマンドで作成することも出来る（スクリプトで、5 分）。
  • 2025年2月の作業で、￥700/日位いったので、
    あげっぱなすと月 2 万以上かかる。
  • シャットダウン運用ならぬ「オンデマンド de 作成・削除 運用」が必要。

補足（この指摘は実務的に重要）: Bastion は
VM のように「停止して課金を止める」ことができない。
存在するだけで時間課金される。

対処 内容
オンデマンド作成・削除 作成 5 分。使う日だけ立てる（本ページの推奨）
Developer SKU 無償（2024年 GA）。ただし機能制限あり・共有インフラ
開発環境では使わない VPN / Just-In-Time VM アクセスで代替

Developer SKU は「VNet 内の VM に、
ポータルからブラウザで繋ぐだけ」という最小構成なら無償で使える。
検証環境ではまずこれを検討したい
（ネイティブ クライアント接続・スケーリング等は Basic 以上が要る）。

作成

ポータルで、VM →［接続］→［Bastion］から作成可能。

セキュリティ

通信

Azure ポータルから踏み台サーバーに RDP / SSH 接続できる。

[クライアント] ──HTTPS 443──> [Azure ポータル / Bastion] ──RDP/SSH 3389,22──> [VM]
  • RDP / SSH over SSL で、RDP / SSH は、HTTPS でカプセル化される。
  • ポータルからクライアントレス（HTML5 で） の RDP または SSH 接続が可能

OS

Windows (RDP) / Linux (SSH) の双方で利用可能。

認証

ポータル経由で接続するので、Entra ID 認証が必要だが、
現時点で仮想マシンの Entra ID 認証・ログインは使用できず、
現状、OS ログインに別途クレデンシャルが必要。

移行メモ（最新化）: 現在は Entra ID（旧 Azure AD）による
VM ログインがサポートされている（Windows / Linux とも）。
AADLoginForWindows / AADSSHLoginForLinux 拡張機能を導入し、
RBAC ロール（Virtual Machine Administrator Login 等）を割り当てる。

これにより、

  • OS のローカル アカウントを作らなくてよい
  • 条件付きアクセス・多要素認証が効く
  • 退職者の無効化が Entra ID 側だけで済む

という運用になる。本ページ執筆時の制約は解消している。

リダイレクトの抑止

クライアント リソースのリダイレクト
（リモートデスクトップサービスを参照）は
止められており、テキストだけ、クリップボード経由でコピペできるもよう。

補足（これが Bastion を選ぶ理由になる）: リモートデスクトップサービスで
述べたとおり、ドライブ リダイレクトは情報漏洩の主経路である。
Bastion は既定でこれを塞いでいるため、
「データを持ち出させない」という要件に対して
設定漏れが起きないという利点がある。

なお現在は、Basic/Standard SKU でファイル転送を有効化することもできる。
要件に応じて選ぶ。

アクセス制御

  • NSGを使用して、制限できる。
  • 加えて、IP アドレス制限を行う場合、Entra ID による条件付きアクセス機能を構成する。

IaC化

Bastion ホスト

ポイント

  • VNET と Azure Bastion ホストのリソース・グループは分割不可能。
  • VNET は、VM と Azure Bastion ホストで、分けても良いが大掛かりになる。
  • サブネッティングについては、Azureのサブネッティングを参照。

Azure CLI

# リソース・グループ
az group create --name AzureBastionRG --location "Japan East"

# ネットワーク
az network vnet create --resource-group AzureBastionRG --name AzureBastionVnet \
  --address-prefix 10.0.0.0/16 \
  --subnet-name AzureBastionSubnet --subnet-prefix 10.0.0.0/24 \
  --location "Japan East"

# パブリック IP アドレス
az network public-ip create --resource-group AzureBastionRG \
  --name AzureBastionPubIP --sku Standard --location "Japan East"

# Azure Bastion 本体（5 分かかる）
az network bastion create --name MyAzBastion \
  --public-ip-address AzureBastionPubIP \
  --resource-group AzureBastionRG --vnet-name AzureBastionVnet \
  --location "Japan East"

補足（サブネット名は固定）: AzureBastionSubnet という
サブネット名は変更できない（Azure 側が固定で要求する）。
また /26 以上（Standard 以上ではより大きく）が必要である。

既存の VNet に後から追加する場合、
アドレス空間に余裕が無くて詰まることが多いため、
設計時に確保しておきたい。同種の固定名サブネットには
GatewaySubnet（Azureの仮想ネットワーク）もある。

仮想マシン

事前に VNet や Subnet を作成しておく（同一アドレス空間内では
特別な設定をしなくてもサブネット間の通信が可能）。

az network vnet subnet create --resource-group AzureBastionRG \
  --name ManagementTerminalSubnet --address-prefixes 10.0.1.0/24 \
  --vnet-name AzureBastionVnet

参考

Microsoft Learn

Tags: 移行, インフラストラクチャ, クラウド, Azure, セキュリティ

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

⚠️ **GitHub.com Fallback** ⚠️