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 を設定し、顧客による変更・削除を制限する。顧客管理型では拒否割り当てを使わない方式も選べる
• 権限シナリオは、発行者管理、発行者と顧客の共同管理、発行者アクセスを渡さず顧客操作を拒否するロックモード、拒否も発行者アクセスも使わない顧客管理の 4 方式。保守責任に合わせて選ぶ
• 発行者に管理を委ねる場合は、アクセス権を 承認（authorizations）として定義し、原則 Entra ID グループ + 必要なロールの組で最小権限に絞る
• パッケージは mainTemplate.json と createUiDefinition.json を含む .zip として登録する。テンプレートの記法・サイズ制限は通常の ARM デプロイに準じる
• マネージドアプリ自体に追加課金はなく、展開されたリソースの利用料は顧客サブスクリプションで発生する（Marketplace 商用オファーでは別途ライセンス課金を設定可能）

内部の仕組み

横にスクロール

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

発行者管理型では、このリソースグループに 拒否割り当て（deny assignment）を設定して顧客の直接操作を制限し、定義時に指定した 承認（プリンシパルとロールの組）を発行者へ射影します。一方、現在は発行者の恒久アクセスや拒否割り当てを使わず、顧客が管理する権限シナリオも選択できます。

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

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

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

運用・監視

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

コスト

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

セキュリティ

• 発行者管理型では、顧客の直接操作を deny assignment で構造的に止め、構成改変による事故やサポート不能化を防げる
• 発行者へ管理を委ねる場合は、権限を 承認（authorizations）として宣言し、Entra ID グループ + 最小ロールで渡す。Owner 相当の恒久付与は避ける
• 接続情報は Key Vault などで管理し、テンプレート、展開履歴、outputs に機微情報を出さない。管理対象リソースグループ内に置くだけでは秘密化できない
• 発行者の保守操作は監査ログに発行者 ID で記録されるため、責任分界点が明確になる
• 一時保守には Managed Applications の Just-In-Time アクセスを使い、顧客承認、期間、ロールを限定する。この機能の利用には Microsoft Entra ID P2 ライセンスが必要

関連サービス・比較

比較対象として分かりやすいのが Template Specs です。Template Specs は ARM テンプレートをテナント内で共有・バージョン管理しますが、展開後を 1 つのアプリとして管理する仕組みや、発行者へ運用権限を委ねる仕組みは持ちません。標準構成の再利用だけなら Template Specs、管理対象リソースグループを含むアプリ単位の配布や発行者保守が必要なら Managed Applications、という使い分けになります。

ハンズオン / 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