【ITニュース解説】🔐 Enabling Easy Auth for Azure Logic Apps (Standard)

クラウド上でさまざまなシステム連携や自動化ワークフローを構築できるAzure Logic Appsは、現代のITシステムにおいて非常に重要な役割を果たしている。特にHTTPトリガーを使って外部からLogic Appのワークフローを呼び出す場合、そのセキュリティは極めて重要である。

通常、Logic AppのHTTPトリガーはShared Access Signature（SAS）キーと呼ばれる特別なパラメータをURLに付与することで認証を行う。これは「sig=...」のような形式でURLに含まれ、このキーを持つことでワークフローを実行できる仕組みだ。しかし、この方法ではURL自体が漏洩した場合、誰でもワークフローを呼び出せるため、セキュリティの観点からは十分とは言えない。より堅牢なセキュリティを確保するには、別の認証方法を導入する必要がある。

そこで推奨されるのが、App Service Authentication/Authorization、通称「Easy Auth」の利用である。Easy AuthをLogic Appの前面に配置することで、Microsoft Entra ID（旧称Azure AD）というマイクロソフトが提供するクラウドベースのID管理サービスによって発行された有効なトークンを持つ呼び出し元だけがワークフローを実行できるようになる。これにより、より厳格なアクセス制御が可能となる。この解説では、Logic Apps Standard（シングルテナント環境）でEasy Authを有効にする手順とその仕組みを説明する。

Easy Authを導入するにあたり、いくつかの前提条件がある。まず、Azure上にLogic App Standardがデプロイされていること。次に、Microsoft Entra IDにApp Registration（アプリケーション登録）が行われていることだ。App Registrationとは、Entra IDにアプリケーションを登録し、そのアプリケーションがEntra IDと連携して認証や認可を行えるようにするための設定である。また、Logic Appリソースに対してOwner（所有者）またはContributor（共同作成者）の権限を持っている必要がある。ここで注意が必要なのは、Easy AuthはLogic Apps Standardでのみ利用可能であり、Logic Apps Consumptionプランではサポートされていない点だ。Consumptionプランの場合は、API ManagementやIP制限といった代替手段を検討する必要がある。

では、具体的な設定手順を見ていこう。

まず、認証を有効にし、設定、適用する。Azureポータルで対象のLogic Appに移動し、設定メニューから「認証」を選択する。次に「IDプロバイダーの追加」をクリックし、IDプロバイダーとして「Microsoft」を選ぶ。ここで、事前に作成しておいたApp Registrationを選択するか、新しく作成する。選択が完了したら設定を保存する。

App Registrationを紐付けた後、Microsoftプロバイダーの「編集」をクリックして詳細な設定を行う。 一つ目は「Issuer URL」の設定である。これはトークンを発行する認証局のURLを指し、通常は「https://login.microsoftonline.com/<テナントID>/v2.0」のような形式で、自身のEntra IDテナントのv2.0エンドポイントを指定する。 二つ目は「Allowed token audiences」の設定で、このトークンがどのアプリケーションのために発行されたものかを示す識別子である。ここでは、通常「api://<クライアントID>」と、App RegistrationのクライアントID（生のGUID形式）の二つを追加する。クライアントIDはApp Registrationでアプリケーションを一意に識別するためのIDである。

さらに、「追加チェック」の項目では、より詳細なアクセス制御を設定できる。 「クライアントアプリケーションの要件」では、特定の信頼されたクライアントアプリケーションからのリクエストのみを許可するか、テスト目的で任意のアプリケーションからのリクエストを許可するかを選択できる。セキュリティを考慮すると、特定のクライアントアプリケーションからのアクセスに限定することが推奨される。 「IDの要件」では、特定のユーザーやグループからのリクエストのみを許可するか、任意のIDからのリクエストを許可するかを選択する。 「テナントの要件」では、自身のテナントからのリクエストのみを許可するか（シングルテナント構成の場合に推奨）、または任意のMicrosoft Entraテナントからのリクエストを許可するか（マルチテナント構成の場合）を選択する。シングルテナント環境では、自身のテナントのみに制限するのが一般的である。

これらの設定後、再度「認証」設定画面の「設定」タブを開き、App Service authenticationが「有効」になっていること、そしてアクセス制限が「認証を要求」になっていることを確認し、変更を保存する。これにより、認証されていないリクエストはLogic Appに到達できなくなる。

次に、Logic Appにアクセスするためのトークンを取得し、内容を確認する。トークンはPostmanやAzure CLIなどのツールを使って取得できる。例えばPostmanを使用する場合、「grant_type=client_credentials」という認証フローで、自身のApp RegistrationのクライアントIDとクライアントシークレット、そしてスコープを指定してリクエストを送信する。成功すると、応答に「access_token」という項目が含まれる。このaccess_tokenは、認証が成功したことを証明するデジタル署名付きのデータで、ユーザーやアプリケーションのID情報と権限情報が含まれる。

取得したaccess_tokenは、jwt.msのようなツールでデコード（内容を解析）できる。デコードすると、トークンに含まれる情報がJSON形式で表示される。この中で特に注目すべきは「oid」というクレーム（情報）である。これはObject ID（OID）と呼ばれ、Microsoft Entra ID内でユーザーやサービスプリンシパル（アプリケーションやサービスを識別するID）を一意に識別するIDである。

このOIDを利用して、Logic Appへのアクセスを特定のIDに制限できる。Logic Appの「認証」設定に戻り、Microsoftプロバイダーの「IDの要件」設定を選択する。ここで「特定のIDからの要求を許可する」を選び、先ほど取得したOIDを許可リストに追加する。これにより、そのOIDを持つ特定のユーザーやサービスプリンシパルだけがLogic Appを呼び出せるようになる。

最後に、異なる認証方法でのLogic Appの動作を検証する。 まず、SASキーのみを使用してLogic Appを呼び出すと、認証は成功する。しかし、これは認証済みのEntra IDトークンなしでアクセスできるため、セキュリティレベルは低い。 次に、Easy Authを有効にした状態で、有効なBearer Token（access_tokenの先頭に「Bearer 」を付与したもの）をヘッダーに含めて呼び出すと、認証が成功し、ワークフローが実行される。これがEasy Authの本来の動作であり、セキュアなアクセス方法である。 もし、Bearerプレフィックスなしでトークンを送信したり、無効なトークンを使用したりした場合は、401 Unauthorizedエラーが返され、アクセスが拒否される。これは、Easy Authが正しく機能している証拠である。

Easy Authを有効にし、さらにIdentity requirementで特定のOIDにアクセスを制限することで、Logic AppのエンドポイントはMicrosoft Entra IDによって厳重に保護される。これにより、特定のクライアントアプリケーション、特定のテナント、そして特定のIDを持つ呼び出し元のみがLogic Appにアクセスできるようになる。これは、Logic AppがエンタープライズグレードのAPIセキュリティ要件を満たす上で非常に重要なステップとなる。