Azure Managed Applications

解決する課題

• ソフトウェアベンダーが、自社アプリを顧客の Azure サブスクリプションへ配布したいが、構成の中身や運用ノウハウは見せたくない
• 顧客に渡したあと設定を勝手に変更されて壊れるのを防ぎ、サポート可能な状態を保ちたい
• 社内の標準アプリ（共通基盤・分析環境など）を、承認された構成として部門にセルフサービスで払い出したい
• 単なる ARM テンプレート配布では、展開後の運用・更新・課金を発行者側で握れない
• 顧客環境に置いたリソースを、発行者が一定の権限で保守しつつ、顧客の請求は顧客側で発生させたい

主要概念と用語

• マネージドアプリケーション（Managed Application）: ARM テンプレートと UI 定義をパッケージ化し、発行者が運用責任を持ったまま顧客環境にデプロイされるアプリ。顧客から見ると中身が隠蔽された 1 つの管理単位になる
• 管理対象リソースグループ（managed resource group）: アプリの実体リソースが配置される、顧客サブスクリプション内の隔離されたリソースグループ。顧客の通常権限ではここを直接編集できない
• サービスカタログ定義（service catalog）: 自社の Entra ID テナント内で配布する形態。社内・特定顧客向けにカタログとして公開する
• Marketplace 形態: Azure Marketplace を通じて一般のテナントへ公開する形態。商用配布に使う
• createUiDefinition.json: デプロイ時に顧客が入力するパラメータのポータル UI を定義するファイル。入力フォームの体裁を制御する
• mainTemplate.json: 実際に展開されるリソースを記述した ARM テンプレート本体
• deny assignment（拒否割り当て）: 管理対象リソースグループに自動付与され、顧客側の直接操作を拒否する仕組み。発行者だけが定義した権限で触れる
• 発行者 / 消費者: アプリを提供する側（ベンダー・社内プラットフォーム）と、自サブスクリプションに展開して使う側

仕様・制限・クォータ

• 提供形態は **サービスカタログ（自テナント内配布）**と **Azure Marketplace（一般公開）**の 2 種類。前者は社内カタログ、後者は商用配布向け
• 各マネージドアプリには 管理対象リソースグループが 1 つ対応し、アプリ削除時にはその中のリソースもまとめて削除される
• 管理対象リソースグループには deny assignment が自動付与され、顧客は通常権限で中のリソースを変更・削除できない
• 発行者がアクセスする権限は **承認（authorizations）**として定義し、原則 Entra ID グループ + 必要なロールの組で最小権限に絞る
• パッケージは mainTemplate.json と createUiDefinition.json を含む .zip として登録する。テンプレートの記法・サイズ制限は通常の ARM デプロイに準じる
• マネージドアプリ自体に追加課金はなく、展開されたリソースの利用料は顧客サブスクリプションで発生する（Marketplace 商用オファーでは別途ライセンス課金を設定可能）

内部の仕組み

マネージドアプリは、**mainTemplate.json（リソース定義）**と **createUiDefinition.json（入力 UI）**を束ねたパッケージとして定義します。顧客がこれをデプロイすると、Azure は顧客サブスクリプション内に 管理対象リソースグループを作り、テンプレートの実体リソースをそこへ配置します。

このリソースグループには **拒否割り当て（deny assignment）**が自動的に掛かり、顧客の通常権限では中のリソースを直接編集・削除できなくなります。一方、発行者には定義時に指定した **承認（プリンシパルとロールの組）**が射影され、発行者だけが必要な範囲でリソースを保守できます。

• 顧客には「アプリ」という 1 つの論理単位だけが見え、内部リソースの細部は隠蔽される
• 削除はアプリ単位で行い、管理対象リソースグループごと破棄されるためリソースの取り残しが起きにくい
• 発行者は射影された権限で更新・監視・サポートを行えるが、Owner 相当の全権を恒久的に持たせない設計が推奨される

設計パターン / ベストプラクティス

• 承認はグループに最小権限で: 発行者アクセスは個人ではなく Entra ID グループに、必要なロールだけを渡す。担当変更をメンバーシップで吸収でき、棚卸しも容易
• UI 定義で入力を堅くする: createUiDefinition.json で入力検証・選択肢・既定値を作り込み、顧客の誤入力による破損を予防する
• 更新を前提に設計: アプリのバージョン更新フローを想定し、テンプレートを冪等かつ再適用可能に保つ。状態を持つリソースの扱いを明確にする
• 隠蔽したい資産を内部へ: 顧客に見せたくない構成・スクリプト・接続情報は管理対象リソースグループ側に閉じ込め、出力（outputs）は必要最小限にとどめる
• 社内配布はサービスカタログ: 一般公開が不要なら Marketplace ではなくサービスカタログ定義を使い、自テナント内のカタログとして統制する

運用・監視

• Azure Monitor / Log Analytics を管理対象リソースグループへ向け、発行者側からアプリの稼働メトリクスとログを収集する
• アクティビティログで、発行者プリンシパルが管理対象リソースに対して行った保守操作を監査する。誰がいつ何を変更したかを追える
• 更新の配布は、新バージョンのパッケージを定義に反映し、対象アプリへ適用する運用を整える。破壊的変更は事前検証を必須にする
• Azure Policy を併用し、配布されたアプリが組織のコンプライアンス基準に沿うかを横断的に確認する
• 顧客側では、アプリ単位の状態（プロビジョニング成否・通知）を確認し、問題時は発行者のサポート窓口へという分界を明確にする

コスト

マネージドアプリケーションという枠組み自体に追加料金は発生しません。費用は、展開されたリソースの利用料として顧客のサブスクリプションで従来どおり発生します。つまり「誰が請求を受けるか」は顧客側のままで、発行者は運用責任を負いながらインフラ費用は顧客に紐付くという分担になります。商用配布の場合は、Marketplace のオファー設定でライセンス課金（従量・月額など）を上乗せでき、これは発行者の収益になります。いずれも変動する単価は公式の料金ページやオファー条件で都度確認してください。

セキュリティ

• 顧客の直接操作は deny assignment で構造的に止まり、構成改変による事故やサポート不能化を防げる
• 発行者の権限は **承認（authorizations）**として宣言し、Entra ID グループ + 最小ロールで渡す。Owner 相当の恒久付与は避ける
• 顧客に見せたくない接続情報・スクリプトは管理対象リソースグループ内に隔離し、outputs に機微情報を出さない
• 発行者の保守操作は監査ログに発行者 ID で記録されるため、責任分界点が明確になる
• 高権限が必要な保守は、PIM による Just-In-Time 昇格と組み合わせ、常時強権限を持たない運用にする

関連サービス・比較

比較対象として分かりやすいのが Template Specs です。Template Specs は ARM テンプレートをテナント内で共有・バージョン管理する仕組みで、展開後の運用責任や中身の隠蔽までは行いません。マネージドアプリは「発行者が運用を握り、顧客から中身を隠す」点が決定的に異なります。単に標準構成を再利用したいだけなら Template Specs、運用責任ごとアプリとして配布したいならマネージドアプリ、という使い分けになります。

ハンズオン / CLI例

# サービスカタログ定義（マネージドアプリ定義）を作成
# package.zip は mainTemplate.json と createUiDefinition.json を含む
az managedapp definition create \
  --name "myAppDefinition" \
  --resource-group "publisher-rg" \
  --location "japaneast" \
  --display-name "社内標準アプリ" \
  --description "承認済みの共通基盤アプリ" \
  --lock-level "ReadOnly" \
  --authorizations "<group-object-id>:<role-definition-id>" \
  --package-file-uri "https://example.blob.core.windows.net/pkg/package.zip"

# 定義の一覧を確認
az managedapp definition list \
  --resource-group "publisher-rg" -o table

# 顧客サブスクリプションへマネージドアプリを展開
# managed-rg-id が管理対象リソースグループになる
az managedapp create \
  --name "myAppInstance" \
  --resource-group "consumer-rg" \
  --location "japaneast" \
  --kind "ServiceCatalog" \
  --managed-rg-id "/subscriptions/<sub-id>/resourceGroups/myApp-managed" \
  --managedapp-definition-id "/subscriptions/<sub-id>/resourceGroups/publisher-rg/providers/Microsoft.Solutions/applicationDefinitions/myAppDefinition"

# 展開済みマネージドアプリの一覧を確認
az managedapp list \
  --resource-group "consumer-rg" -o table