Azure App Serviceの認証・ID|マネージドID・Key Vault参照・EasyAuthでパスワードレス

Azure

「データベースのパスワードやAPIキーを、アプリ設定にベタ書きしていませんか?」——動くには動きますが、シークレットが漏れれば一大事です。Azureには、パスワードをコードにも設定にも書かずに、安全に接続するための仕組みが揃っています。

マネージドID、Key Vault、EasyAuth…名前は聞くけど、それぞれ何を解決してくれるのか整理できてない…

この記事では、App Serviceの「認証・ID」を、「シークレットを書かない」「パスワードレスで繋ぐ」という一貫したテーマで整理します。読み終えたときに、次の4つを説明・実践できるようになることをゴールにします。

  • マネージドID(システム割り当て)を有効化できる
  • マネージドID(ユーザー割り当て)を有効化できる
  • Key Vault参照(@Microsoft.KeyVault)でシークレットを注入できる
  • EasyAuth(App Service認証/Entra ID)を構成できる

各セクションの最後に「これが説明できればOK」の自己チェックを置いています。App Serviceの設定(アプリ設定・接続文字列)は第3回で解説しています。

全体像:3つの機能で「パスワードレス」を実現する

個別の説明に入る前に、3つの機能がどう連携するかを掴んでおきましょう。

【マネージドID + Key Vault で「接続文字列にパスワードを書かない」】

  ① App Serviceに「マネージドID」を持たせる
        (=アプリ自身のAzure上の"身分証")
              │
      ┌───────┴────────┐
      ▼                ▼
  ② Key Vaultに        ③ SQL DBなどに
   「このIDは読取OK」     「このIDはログインOK」
    と権限(RBAC)を付与     と権限を付与
      │
      ▼
  ④ アプリ設定に @Microsoft.KeyVault(...) 参照を書く
     → 起動時にKey Vaultからシークレットが自動注入

  =コードにも設定にもパスワードが一切残らない

【EasyAuth】は別軸:アプリに"入ってくる人"のログイン
  (Entra IDでサインインを要求、コード改修なし)

ポイントは、マネージドIDが「アプリ自身の身分証」になり、それを使って各サービスへパスワードレスで接続する、という点です。まずはこの主役から見ていきます。

マネージドID(システム割り当て)を有効化する

マネージドID(Managed Identity)とは、App ServiceにAzure上の”身分証(Entra IDのID)”を持たせる仕組みです。これにより、パスワードやキーを管理せずに、他のAzureリソースへ認証できます。

システム割り当て(System-assigned)マネージドIDは、そのApp Serviceと一心同体のIDです。有効化するとIDが払い出され、App Serviceを削除するとIDも一緒に消えます。「このアプリ専用の身分証」という、最もシンプルな形です。

# システム割り当てマネージドIDを有効化
az webapp identity assign \
  --resource-group rg-appservice \
  --name my-webapp-001

# → 出力される principalId(Object ID)が"身分証番号"

有効化すると principalId(Object ID) が払い出されます。この後は、このObject IDに対して「Key Vaultの読み取り権限」「SQL DBのログイン権限」などを付与していく流れになります。

【ここが説明できればOK①】
システム割り当てマネージドIDを有効化し、Object IDが払い出されることを確認できれば、このチェックはクリアです。

マネージドID(ユーザー割り当て)を有効化する

もう一つがユーザー割り当て(User-assigned)マネージドIDです。こちらはアプリとは独立した”共用の身分証”で、先に単体のリソースとして作成し、複数のApp Serviceやリソースに紐付けて使い回せます。

「アプリと運命共同体=システム割り当て」「独立して使い回せる=ユーザー割り当て」で覚えよう!

# ① ユーザー割り当てマネージドIDを単体で作成
az identity create \
  --resource-group rg-appservice \
  --name id-shared-app

# ② そのIDをApp Serviceに紐付け
az webapp identity assign \
  --resource-group rg-appservice \
  --name my-webapp-001 \
  --identities "<ユーザー割り当てIDのリソースID>"

使い分けの目安はこうです。1つのアプリ専用でシンプルにいくならシステム割り当て複数のアプリで同じ権限セットを共有したい・アプリを作り直しても権限設定を残したいならユーザー割り当て。多くの学習・小規模用途ではシステム割り当てで十分です。

【ここが説明できればOK②】
ユーザー割り当てマネージドIDを作成しアプリに紐付けて利用できることを確認できれば、このチェックはクリアです。

Key Vault参照(@Microsoft.KeyVault)でシークレットを注入する

マネージドIDという身分証が用意できたら、いよいよ本題の「シークレットをアプリ設定に書かない」仕組みです。App Serviceには、アプリ設定の値としてKey Vaultのシークレットを”参照”できる機能があります。

やり方は、アプリ設定の値に特別な参照構文を書くだけです。

# アプリ設定の「値」にKey Vault参照を書く
DB_PASSWORD = @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/db-password/)

# または identifier 形式
DB_PASSWORD = @Microsoft.KeyVault(VaultName=myvault;SecretName=db-password)

こう書いておくと、App Serviceは起動時にマネージドIDを使ってKey Vaultにアクセスし、実際のシークレット値を取ってきて環境変数に注入します。アプリのコードから見れば、いつもどおり環境変数 DB_PASSWORD を読むだけ。アプリ設定の画面にも実際のパスワードは表示されず、参照式だけが残るのがポイントです。

前提として、App ServiceのマネージドIDに、Key Vaultのシークレット読み取り権限(RBACの「Key Vault Secrets User」ロール、またはアクセスポリシー)を付与しておく必要があります。この「マネージドID+Key Vault参照+読み取り権限」の3点セットで、パスワードがどこにも残らない構成が完成します。

【ここが説明できればOK③】
アプリ設定に @Microsoft.KeyVault(...) 参照を記述し、Key Vaultのシークレットが解決されることを確認できれば、このチェックはクリアです。

EasyAuth(App Service認証/Entra ID)を構成する

ここまではアプリから他サービスへの接続(=出ていく側の認証)でした。最後は視点が変わり、アプリアクセスしてくるユーザーのログイン(=入ってくる側の認証)です。これを担うのがEasyAuth(App Service認証)です。

EasyAuth(App Service認証/認可)とは、アプリのコードを一切改修せずに、App Serviceのプラットフォーム側でサインインを要求できる機能です。Entra IDなどのプロバイダーで認証を強制できます。

最大のメリットは「認証ロジックを自前で書かなくていい」こと。ポータルの「認証(Authentication)」からプロバイダー(Microsoft Entra ID、Google、GitHubなど)を追加し、「認証されていないアクセスを拒否」に設定するだけで、アプリの前段でサインインが要求されるようになります。

【EasyAuthの動き】

  未認証ユーザー
     │ アプリにアクセス
     ▼
 ┌────────────────────────┐
 │ App Service認証(EasyAuth)│ ← プラットフォーム層で判定
 │ 「サインインしてる?」       │
 └────────────────────────┘
     │ NO → Entra IDのサインイン画面へリダイレクト
     │ YES → そのままアプリ本体へ
     ▼
   アプリのコード(認証処理は書かなくていい)

社内向けの管理画面を「Entra IDでログインした社員だけに見せたい」といったケースに最適です。認証済みユーザーの情報は、アプリ側でヘッダーやエンドポイント経由で受け取れます。「まずアクセスできる人を絞る」という意味では、第4回のアクセス制限(ネットワークで絞る)と補完し合う関係です(EasyAuthは”誰か(ID)”で、アクセス制限は”どこから(IP)”で絞る)。

【ここが説明できればOK④】
App Service認証(EasyAuth)でEntra IDプロバイダーを構成し、サインインが要求されることを確認できれば、このチェックはクリアです。

まとめ

今回はApp Serviceの「認証・ID」を、パスワードレスの視点で整理しました。

  • マネージドID =アプリの”身分証”。システム割り当て(アプリ専用)とユーザー割り当て(共用・使い回し)
  • Key Vault参照@Microsoft.KeyVault(...) でシークレットを自動注入。設定にパスワードを残さない
  • 「マネージドID+Key Vault参照+読み取り権限」の3点セットでパスワードレス接続が完成
  • EasyAuth =アプリに入ってくる人のログインを、コード改修なしでEntra ID等に強制

認証・IDまで押さえたら、いよいよ最終回。スケール・運用・監視——本番で”動かし続ける”ための技術——に進みましょう。次回(第6回)で解説します。

あわせて読みたい

タイトルとURLをコピーしました