【ITニュース解説】🔐 Fine-Grained Role Control for Logic App Standard Workflows with APIM + Easy Auth

システムエンジニアを目指す初心者の皆さん、こんにちは。今回のニュース記事は、クラウド上で業務プロセスを自動化するサービス「Azure Logic Apps Standard」をもっと安全に、そして細かく利用するための仕組みについて解説しています。特に、どのユーザーが、どの処理を実行できるのかを厳密に管理する方法に焦点を当てています。

まず、Logic Apps Standardについて簡単に説明する。これは、様々なサービスを連携させ、複雑なワークフローをコードを書かずに視覚的に作成できる便利なツールだ。例えば、「商品が購入されたら、在庫システムを更新し、購入者へメールを送信する」といった一連の処理を自動化できる。

Logic Apps Standardは通常、インターネット経由でアクセスできるHTTPエンドポイントを持っている。しかし、このエンドポイントが誰でも利用できる状態だと、セキュリティ上の問題が生じる。そこで、記事の前提として、Logic Apps Standardのエンドポイントを「Easy Auth」という機能で保護しているとある。Easy Authは、Azure Entra ID（旧称 Azure Active Directory）と連携して、ユーザーが有効なアカウントを持っているかどうかを確認する認証の仕組みだ。これにより、Logic Appへの不正アクセスをある程度防ぐことができる。

しかし、Easy Authだけでは、認証されたユーザーなら誰でもLogic Appの全てのワークフローを実行できてしまう。例えば、特定のユーザーには「商品の追加」ワークフローだけを許可し、「商品の削除」ワークフローは許可しない、といったきめ細やかな制御はできない。そこで登場するのが「Azure API Management（APIM）」というサービスだ。

APIMは、APIの「門番」のような役割を果たす。APIへのすべてのリクエストはまずAPIMを通過し、APIMがリクエストの認証、認可、ルーティング、トラフィック管理などを行う。今回の記事では、APIMを使ってLogic Appへのアクセスをさらに厳しく、そして細かく管理する方法を説明している。具体的には、ユーザーが持っている「ロール」（役割）に基づいて、特定のLogic Appワークフローへのアクセスを許可したり拒否したりする「ロールベースアクセス制御」をAPIMで実現する。

この仕組みを構築するためのステップは主に4つある。

最初のステップは「App Rolesの登録」だ。これは、Azure Entra ID上で、APIMが管理するAPIに対して利用可能な「役割」を定義することだ。例えば、「wf_arithmetic_add」というロールは足し算ワークフローを実行できる役割、「wf_arithmetic_sub」は引き算ワークフローを実行できる役割、といった具合だ。これらのロールは、特定のユーザーやサービスプリンシパル（アプリケーションやサービス自身を表すID）に割り当てられる。これにより、そのユーザーやサービスがどの操作を許可されているかを明確に定義できる。

次のステップは「Logic App StandardをAPIMに組み込む」ことだ。通常、Logic Appはそれぞれ固有のURLを持ち、そのURLには「SASトークン」という一時的なアクセスキーが含まれている。このSASトークンは便利なのだが、ロールベースの認証・認可には向いていない。そこで、APIMを介してLogic Appにアクセスするように設定する。APIMでは、Logic AppのワークフローごとにAPI操作を手動で作成し、各操作のバックエンドURLを対応するLogic AppのHTTPエンドポイントに設定する。このとき、Logic App側のURLからSASトークンを取り除き、認証はAPIMとEasy Auth、そしてJWT（後述）に任せるようにする。また、APIMの「URL書き換えポリシー」を使って、外部に公開するURL（例: /api/wf_arithmetic_add）を、Logic App内部の複雑なURL（例: /api/wf_arithmetic_add/triggers/RcvReq/invoke?api-version=...）に変換することで、APIM側の設定を簡素化し、外部からの見た目もきれいに保つ。

3つ目のステップが最も重要で、「APIMでのJWT検証」だ。ユーザーやサービスがAPIを呼び出す際、そのリクエストには「JWT（JSON Web Token）」という形式の認証情報が含まれている。このJWTは、ユーザーが誰であるか、どのようなロールを持っているかといった情報を暗号化して格納した電子的な証明書のようなものだ。APIMは、リクエストを受け取ると、まずこのJWTが有効なものであるかを検証する。具体的には、APIMの「インバウンドポリシー」と呼ばれる設定で、validate-jwtというポリシーを使用する。これにより、トークンの署名が正しいか、発行元が信頼できるかなどをチェックし、無効なトークンの場合は401 Unauthorizedエラーを返す。

さらに、APIMポリシー内では、有効なJWTからユーザーのロール情報を抽出する。JWTには「roles」というクレーム（情報項目）があり、ここにはユーザーに割り当てられているロール（例: "wf_arithmetic_add", "wf_arithmetic_sub"）が列挙されている。APIMは、リクエストされたAPI操作（例えば/api/wf_arithmetic_add）がどのワークフローに対応するかをURLから判断し、そのワークフロー名がユーザーの持つロールリストに含まれているかをチェックする。もし、ユーザーが「wf_arithmetic_add」ロールを持っていて、「wf_arithmetic_add」ワークフローを呼び出そうとしている場合はアクセスを許可する。しかし、「wf_arithmetic_mul」ワークフローを呼び出そうとしているのに、「wf_arithmetic_mul」ロールを持っていなければ、APIMはリクエストをブロックし、403 Forbidden（アクセス拒否）エラーを返す。このチェックは、Logic Appにリクエストが到達する前に行われるため、Logic App側では余計な処理を行う必要がなく、セキュリティが向上する。

最後のステップは「検証」だ。実際に異なるロールを持つJWTを使ってAPIを呼び出し、想定通りにアクセスが許可されたり拒否されたりすることを確認する。例えば、「wf_arithmetic_add」ロールを持つトークンで足し算ワークフローを呼び出すと200 OKで成功し、同じトークンで掛け算ワークフロー（対応するロールがない）を呼び出すと403 Forbiddenで拒否されることが確認できる。

この一連の仕組みを導入することで、APIMはLogic Appの手前で、認証とロールに基づくきめ細やかな認可を強力に実施する。これにより、Logic Appのセキュリティが大幅に強化され、どのユーザーがどの業務プロセスを実行できるかを厳密に管理できるようになる。システム開発において、セキュリティは非常に重要な要素であり、このような多層的な防御とアクセス制御の考え方は、システムエンジニアとして身につけておくべき重要な知識である。