Azure Bastion のセッション録画を使っている管理者にとって、今回のマネージド ID 対応の価値は「録画ファイルを Azure Storage に保存するための資格情報管理を減らせること」です。これまで SAS URL の発行・保管・期限管理が運用上の注意点になりやすかった環境では、Azure RBAC とマネージド ID を使うことで、より安全で扱いやすいセッション記録パイプラインを組みやすくなります。
2026年4月14日時点で確認された Azure Updates では、Azure Bastion のグラフィカル セッション記録に対するマネージド ID サポートが Public Preview として追加されています。Microsoft Learn でも、Bastion のセッション録画はストレージ アカウントへの認証にマネージド ID を利用でき、SAS トークン管理を不要にできると説明されています。(マイクロソフトAzure)
Azure Bastion のセッション録画で何が変わったのか
Azure Bastion のセッション録画は、Bastion 経由で仮想マシンに接続した RDP / SSH のグラフィカル セッションを記録し、セッション終了後または切断後に Azure Storage の BLOB コンテナーへ保存する機能です。録画は Azure ポータル上の Session recordings から確認できます。なお、この機能には Bastion Premium SKU が必要です。(Microsoft Learn)
今回のポイントは、録画データの保存先であるストレージ アカウントへの書き込み認証に、マネージド ID を使えるようになったことです。Bastion のマネージド ID に対して Storage Blob Data Contributor など必要な権限を付与し、Bastion 側ではセッション記録設定でマネージド ID と BLOB コンテナー URI を指定します。Microsoft のドキュメントでは、システム割り当てマネージド ID の手順が示されており、ユーザー割り当て ID も同様の流れで扱えるとされています。(Microsoft Learn)
管理者目線では、単なる認証方式の追加ではありません。録画ファイルという監査・証跡データを扱うパイプラインから、コピーされやすい SAS URL や有効期限付きトークンの運用負荷を減らせる点が重要です。
なぜマネージド ID 対応がセキュリティ運用を楽にするのか
マネージド ID は、Azure リソースに Microsoft Entra ID 上の ID を持たせ、対応する Azure サービスへ資格情報なしで認証させる仕組みです。Microsoft の説明では、マネージド ID によりアクセスキーやパスワードなどのシークレット管理を置き換えられ、認証情報は利用者から直接アクセスできません。(Microsoft Learn)
Azure Bastion のセッション録画では、これが次のような改善につながります。
| 観点 | 従来の SAS URL 中心の運用 | マネージド ID 利用時の運用 |
|---|---|---|
| 認証情報の扱い | SAS URL を生成・コピー・登録する | Bastion の ID に Azure RBAC で権限を付与する |
| 期限管理 | SAS の有効期限切れや更新漏れに注意が必要 | ID とロール割り当てを管理する |
| 権限設計 | SAS の権限・期間・IP 制限を慎重に設定する | BLOB コンテナーまたはストレージ アカウント単位でロールを絞る |
| 監査しやすさ | URL の保管場所や再利用状況を追いにくい場合がある | Entra ID、Azure RBAC、アクティビティ ログと組み合わせて確認しやすい |
| 運用ミス | URL の貼り間違い、期限切れ、過剰権限が起きやすい | ロール不足・スコープ誤りに注意すれば標準化しやすい |
特にクラウドセキュリティチームやリモートアクセス管理者にとっては、「誰が録画データを書き込めるのか」を RBAC で説明できるようになる点が大きなメリットです。Azure Storage では Microsoft Entra ID と Azure RBAC による BLOB データアクセス制御が利用でき、Storage Blob Data Contributor は BLOB への読み取り・書き込み・削除権限を付与する組み込みロールとして説明されています。(Microsoft Learn)
セッション録画パイプラインはどうシンプルになるか
Azure Bastion のセッション録画パイプラインは、実務では次のような流れになります。
| ステップ | 実施内容 | 管理上のポイント |
|---|---|---|
| Bastion を用意する | Premium SKU の Azure Bastion をデプロイ、または既存 Bastion を Premium に変更する | セッション録画は Premium SKU が前提 |
| 録画用コンテナーを作る | Azure Storage に専用の BLOB コンテナーを作成する | 他用途と混在させず、録画専用にすると権限・保持期間を管理しやすい |
| CORS を設定する | Bastion の DNS 名を許可元として CORS を設定する | Allowed origins は https://bst-... 形式の Bastion DNS 名を使う |
| Bastion に ID を持たせる | システム割り当て、またはユーザー割り当てマネージド ID を構成する | 単一 Bastion ならシステム割り当て、複数環境で権限を再利用したい場合はユーザー割り当てを検討 |
| Storage 権限を付与する | Bastion のマネージド ID に Storage Blob Data Contributor を付与する | 可能ならストレージ アカウント全体ではなく、必要最小スコープを検討 |
| Bastion 側で録画設定を行う | Session Recording Configuration でマネージド ID と BLOB コンテナー URI を指定する | SAS URL ではなくコンテナー URI を指定する構成になる |
| 録画を確認する | セッション終了後、Azure ポータルの Session recordings から録画を開く | 閲覧ユーザーには Storage Blob Data Reader などの読み取り権限が必要 |
この構成にすると、運用手順書から「SAS URL を生成して安全な場所に貼り付ける」「期限切れ前に再発行する」「古い SAS URL をどこで使っているか確認する」といった作業を減らせます。トラブル対応時も、まず確認すべき対象が「マネージド ID が有効か」「RBAC ロールが正しいスコープに付いているか」「BLOB コンテナー URI が正しいか」に整理されます。
システム割り当て ID とユーザー割り当て ID の使い分け
Azure Bastion のセッション録画では、システム割り当てマネージド ID とユーザー割り当てマネージド IDのどちらを使うかを設計段階で決めておくと、後の運用が楽になります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| システム割り当てマネージド ID | Bastion が1つ、構成がシンプル、リソース単位で権限を閉じたい | Bastion リソースのライフサイクルと ID が連動する |
| ユーザー割り当てマネージド ID | 複数 Bastion、複数環境、権限を事前承認して使い回したい | ID 自体の棚卸し、不要時の削除、割り当て先管理が必要 |
Microsoft のマネージド ID ドキュメントでは、システム割り当て ID はリソースのライフサイクルに紐づき、ユーザー割り当て ID は独立した Azure リソースとして作成され、複数リソースに関連付けられると説明されています。(Microsoft Learn)
実務では、まず単一環境ならシステム割り当て ID から始めるのが分かりやすいでしょう。一方で、本番・検証・災害対策環境などで同じ権限設計を展開したい場合や、Bastion の再作成後も同じ ID とロール割り当てを維持したい場合は、ユーザー割り当て ID が候補になります。
導入前に確認すべき前提条件
Azure Bastion のセッション録画をマネージド ID で運用する前に、以下を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| Bastion の SKU | Premium SKU であること。Basic / Standard の場合はアップグレードが必要 |
| 接続方式 | ブラウザー経由のグラフィカル セッション記録が対象。ネイティブ クライアント経由の録画には対応していない |
| Entra ID RDP との併用 | ポータルでの Entra ID RDP サポートは、現時点ではグラフィカル セッション録画と同時利用できない |
| ストレージ構成 | 録画用の専用 BLOB コンテナーを用意する |
| ストレージ機能 | 録画対象に BLOB バージョン管理や不変ストレージ ポリシーがあると要件に合わない可能性がある |
| 権限 | Bastion のマネージド ID に書き込み権限、閲覧者に読み取り権限を付与する |
| 録画範囲 | セッション録画を有効にした Bastion を通るすべてのセッションが録画対象になる |
Microsoft Learn では、セッション録画利用時の考慮点として、Premium SKU が必要であること、ネイティブ クライアントでは利用できないこと、録画有効化済み Bastion を通るすべてのセッションが記録されることなどが挙げられています。(Microsoft Learn)
特に最後の「すべてのセッションが録画される」という点は、セキュリティ上は強力ですが、運用設計を間違えると不要な録画データが増えます。特権管理者用 Bastion、日常運用用 Bastion、検証環境用 Bastion を分けるかどうかも、録画ポリシーと合わせて検討しましょう。
権限設計で失敗しやすいポイント
マネージド ID を使えば安全になる、という理解だけでは不十分です。実際には Azure RBAC のスコープ設計を誤ると、過剰権限や録画失敗の原因になります。
Storage Blob Data Contributor を広く付けすぎない
Bastion のマネージド ID には、録画データを書き込むための権限が必要です。Microsoft の手順では Storage Blob Data Contributor をストレージ アカウントに割り当てる例が示されていますが、組織のポリシーによってはコンテナー単位など、より狭いスコープを検討した方がよい場合があります。Azure Storage のロール割り当てでは、必要最小権限の原則に沿ってスコープを絞ることが推奨されています。(Microsoft Learn)
例えば、同じストレージ アカウントにアプリケーションログ、バックアップ、監査データが混在している場合、Bastion にストレージ アカウント全体の広い権限を与えるのは避けたい構成です。録画専用のストレージ アカウントまたは録画専用コンテナーを作り、そこだけに権限を付ける方が監査しやすくなります。
閲覧者の権限を忘れない
録画を書き込めることと、管理者が録画を閲覧できることは別です。Microsoft Learn では、セッション録画を表示または一覧表示するユーザーに Storage Blob Data Reader ロールが必要とされています。(Microsoft Learn)
「録画は保存されているはずなのにポータルで見えない」という問い合わせが起きた場合、Bastion 側だけでなく、閲覧ユーザーの BLOB データ読み取り権限も確認してください。
ロール割り当て直後にすぐ検証して失敗扱いしない
Azure Storage の Microsoft Entra ID 認可では、ロール割り当てが反映されるまで時間がかかる場合があります。Microsoft Learn では、Azure ロール割り当ての反映に最大30分かかる可能性があると記載されています。(Microsoft Learn)
構成直後のテストで録画保存に失敗した場合は、設定ミスだけでなく、ロール反映待ちの可能性も考慮しましょう。本番導入時は、変更直後に重要作業を開始せず、事前にテストセッションで保存・閲覧まで確認するのが安全です。
管理者ワークフローはこう変わる
今回の更新は、日々の管理者作業にも影響します。特に変わるのは、録画設定に関わる承認と変更管理です。
従来は、SAS URL を誰が生成し、どこに貼り付け、いつまで有効にするかを運用ルールで縛る必要がありました。期限を長くしすぎると漏えい時の影響が大きく、短くしすぎると更新漏れで録画が止まるリスクがあります。
マネージド ID 利用時は、承認の中心が「Bastion リソースにどの ID を割り当てるか」「その ID にどのスコープでどのロールを付与するか」に移ります。これは、セキュリティチームが普段管理している Azure RBAC のレビューに乗せやすい形です。
具体的には、次のようなワークフローにできます。
| 場面 | 推奨ワークフロー |
|---|---|
| 新しい Bastion を作る | Bastion 作成、Premium SKU 確認、録画専用コンテナー作成、マネージド ID 有効化、RBAC 付与を標準手順にする |
| 録画保存先を変更する | 変更前にアクティブ セッションがない時間帯を選び、新しいコンテナー URI と RBAC を確認してから切り替える |
| 監査対応を行う | Bastion の録画有効化状態、マネージド ID、RBAC ロール、閲覧者権限、保存期間をセットで提示する |
| 権限棚卸しをする | SAS URL の所在確認ではなく、マネージド ID とロール割り当てを中心に確認する |
| インシデント対応を行う | 影響範囲を、対象 Bastion、対象 ID、対象ストレージ コンテナーに絞って確認する |
独自のポイントとして、録画パイプラインを「Bastion の機能」ではなく「監査データの生成・保存・閲覧フロー」として扱うことをおすすめします。録画できるかだけでなく、誰が消せるのか、どの期間保持するのか、どの監査チームが閲覧できるのかまで設計すると、導入後の混乱を減らせます。
既存環境での移行チェックリスト
すでに SAS URL で Azure Bastion のセッション録画を運用している場合は、いきなり本番切り替えせず、次の順で確認すると安全です。
| 項目 | 確認内容 |
|---|---|
| 現在の録画保存先 | 既存のストレージ アカウント、コンテナー、保存期間、ライフサイクル管理を確認 |
| SAS URL の利用状況 | 現在 Bastion に登録されている SAS URL、期限、権限、IP 制限を確認 |
| マネージド ID の種類 | システム割り当てか、ユーザー割り当てかを決定 |
| RBAC スコープ | ストレージ アカウント全体か、コンテナー単位かを検討 |
| 閲覧者権限 | セキュリティチーム、監査担当、運用担当に必要な読み取り権限を整理 |
| テスト手順 | 短い RDP / SSH セッションを実施し、録画保存と再生を確認 |
| 切り戻し方針 | Public Preview 機能であることを踏まえ、SAS URL 方式への切り戻し要否を決めておく |
Public Preview の機能は、正式提供済み機能と同じ前提で全社標準に組み込む前に、自社のサポート要件や変更管理プロセスに合うかを確認する必要があります。特に規制業種や内部監査が厳しい組織では、プレビュー機能の利用範囲を限定し、検証環境から段階的に適用するのが現実的です。
よくある疑問
マネージド ID にすれば SAS URL は不要になるのか
Azure Bastion のセッション録画でマネージド ID 認証を選ぶ場合、SAS トークン管理を不要にできます。ただし、既存の SAS URL 方式もドキュメント上は選択肢として残っています。新規構成では、特別な理由がない限りマネージド ID を優先して検討するとよいでしょう。(Microsoft Learn)
録画は一部の管理者だけに限定できるのか
セッション録画を有効にした Bastion を通るセッションはすべて録画対象になります。特定ユーザーだけを録画する機能として設計するのではなく、「この Bastion を使う接続は録画される」という単位で考える必要があります。録画対象を分けたい場合は、Bastion の分離や接続経路の設計で対応します。
ネイティブ クライアント接続も録画できるのか
現時点の Microsoft Learn では、セッション録画はネイティブ クライアントでは利用できないとされています。Azure CLI などを使ったネイティブ クライアント接続を管理している組織は、録画対象の接続経路を明確に分けてください。(Microsoft Learn)
Entra ID 認証の RDP と一緒に使えるのか
ポータルでの Microsoft Entra ID サポートによる RDP セッションは、現時点ではグラフィカル セッション録画と同時に使えないとされています。Entra ID 認証と録画のどちらを優先するかは、対象サーバーのリスク、監査要件、運用ルールを踏まえて判断しましょう。(Microsoft Learn)
まず取るべきアクション
Azure Bastion のマネージド ID 対応は、セッション録画の安全性と運用性を同時に改善できる更新です。特に、特権作業の証跡を残したいクラウドセキュリティチームや、RDP / SSH の管理経路を標準化したいリモートアクセス管理者にとって、SAS URL 依存を減らせる意味は大きいでしょう。
まずは、既存の Bastion が Premium SKU か、セッション録画を有効にしているか、録画保存先のストレージ権限がどのように管理されているかを棚卸ししてください。そのうえで、検証環境の Bastion からマネージド ID 方式に切り替え、録画の保存・再生・権限レビューまで一連の流れを確認するのが最短です。
本番導入では、録画専用コンテナー、最小権限の RBAC、閲覧者ロール、保存期間、変更手順をセットで設計しましょう。Azure Bastion のセッション録画は「有効にするだけ」の機能ではなく、管理者作業の証跡を安全に残すための監査パイプラインとして扱うことで、実務に耐えるセキュアな運用に近づきます。
コメント