はじめに
たとえば、Power Apps アプリで Azure SQL Database のデータを参照するために、コネクションを作って組織内のユーザーと共有してしまうと、良からぬ者によって良からぬことをやられてしまうかもしれません。1
そんな不安は未然に払拭しておいたほうが良いでしょうから、Power Apps アプリや Power Automate フローから Azure SQL Database に対して直接 SQL クエリを実行せずに、目的に応じて実行する SQL クエリを Logic Apps ロジックアプリに隠ぺいして HTTP リクエストで必要な情報を取り込もうと思いました。
が、この**「HTTP リクエスト」もよりセキュアに通信できないか**と検討してみます。
ゴールは、**「Azure Logic Apps ロジックアプリが特定のクライアント (ここでは Power Automate フロー) からのみ HTTP リクエストを受け付けるようなアクセス制限を設ける」**です。
Azure Logic Apps 要求エンドポイント
要求エンドポイントでは、以下のいずれかの承認スキームが用意されています。
- Shared Access Signature (SAS)
- Azure Active Directory Open Authentication (Azure AD OAuth)
機能的に片方の承認スキームを有効にしてもう片方の承認スキームを無効にすることはできません。また、リクエストする時に両方のスキームを同時に使用するとエラーが発生してしまいます。
承認スキーム：SAS
When a HTTP request is received (HTTP 要求の受信時) トリガーを実装したフローを保存すると要求エンドポイント URL が生成されますが、この URL には SAS クエリパラメーターが含まれています。
ただこの URL を知っていればどのクライアントからでもアクセスできてしまうので、今回のゴールにはちょっと適していないですね。
承認スキーム：Azure AD OAuth
Logic Apps ロジックアプリで承認ポリシーを定義することで、要求エンドポイントへアクセスする際に Azure AD OAuth で承認させることができます。
※承認ポリシーは複数個定義することもできる。
クライアントからロジックアプリで承認するためのアクセストークンを含めて HTTP リクエストを要求エンドポイントに対して発行すると定義されたいずれかの承認ポリシーに含まれるすべてのクレームが一致した場合、承認が成功します。
今回のゴールにはこちらのほうが適しているようです。
各種設定と実装
ここでは、Logic Apps ロジックアプリの要求エンドポイント呼び出し時に、Azure AD OAuth 承認させるための各種設定と実装を順に説明していきます。
Azure AD での作業
Azure AD テナントにアプリを登録してサービスプリンシパルを作成します。
※下図のオレンジ色の線で囲った部分
ここでは、この操作を Power Automate フローが格納される環境の Microsoft 365 サブスクリプションに紐づく Azure AD テナントで行います。
なお、これ以降では各フローを以下のように呼ぶことにします。
- Logic Apps ロジックアプリ → 受け側
- Power Automate フロー → 送り側
アプリの登録：受け側 (Logic Apps ロジックアプリ)
まずは「受け側」。
Azure ポータルから Azure AD テナントを開くか、Microsoft 365 管理センターから Azure AD テナントを開きます。そして [管理] セクションから [アプリの登録] を開いて [新規登録] を行います。
「表示名」に適当な名前を入力し、「サポートされているアカウントの種類」から「この組織ディレクトリに含まれるアカウント」を選択します。「リダイレクト URI」は不要なので省略します。
登録が完了したら、[概要] を開きます。「アプリケーション (クライアント) ID」と「ディレクトリ (テナント) ID」をメモっておきます。後で使います。
次に、「送り側」から「受け側」へアクセスできるようにするために、スコープを介して「受け側」の要求エンドポイントを公開します。
[管理] セクションの [API の公開] を開きます。
「アプリケーション ID の URI」を設定します。
「スコープ」を追加します。
Azure AD テナントでの「受け側」の作業は以上となります。
アプリの登録：送り側 (Power Automate フロー)
続いて「送り側」。
Azure ポータルから Azure AD テナントを開くか、Microsoft 365 管理センターから Azure AD テナントを開きます。そして [管理] セクションから [アプリの登録] を開いて [新規登録] を行います。
「表示名」に適当な名前を入力し、「サポートされているアカウントの種類」から「この組織ディレクトリに含まれるアカウント」を選択します。「リダイレクト URI」は不要なので省略します。
登録が完了したら、[概要] を開きます。「アプリケーション (クライアント) ID」と「ディレクトリ (テナント) ID」をメモっておきます。後で使います。
※「ディレクトリ (テナント) ID」は先ほどの「受け側」でメモった値と同じです。
次に、アクセストークンを取得する時に「送り側」自身を認証するために必要な「クライアント シークレット」を追加します。
[管理] セクションの [証明書とシークレット] を開きます。
新しい「クライアント シークレット」を作成します。
作った「クライアント シークレット」の値をメモっておきます。後で使います。
次に「送り側」から「受け側」にアクセスするためのアクセス許可を追加します。
[管理] セクションの [API のアクセス許可] を開きます。
先ほどの「受け側」で追加した「スコープ」を追加します。
Azure AD テナントでの「送り側」の作業は以上となります。
受け側 (Logic Apps ロジックアプリ) での作業
「送り側」からの HTTP リクエストに含まれるアクセストークン内のクレームをチェックするための「Azure AD 承認ポリシー」を定義します。
※下図のオレンジ色の線で囲った部分
フローを作成
まず、外部から HTTP リクエストを受け取るために「When a HTTP request is received (HTTP 要求の受信時)」トリガーを含むフローを作成します。保存すると要求エンドポイントの URL が発行されるので、これをメモっておきます。後で使います。
Azure AD 承認ポリシーを追加
HTTP リクエストに含まれるアクセストークンを検証するためのポリシーを定義します。
[設定] セクションの [承認] を開き、以下のように「ポリシー」を追加します。
ここでは、追加するポリシーの内容を以下のように設定しました。
| 追加するクレーム | 名前 | 値 | 説明 |
|---|---|---|---|
| 標準 | Issuer |
https://sts.windows.net/<ディレクトリ (テナント) ID>/※末尾の "/"を忘れずに |
発行者 (Azure AD テナント) を識別する識別子 |
| 標準 | Audience | 「受け側」のアプリケーション (クライアント) ID | トークンの対象となる受信者のアプリケーション ID |
| カスタム | appid | 「送り側」のアプリケーション (クライアント) ID | トークンを使用するクライアントのアプリケーション ID |
これで、受け取ったアクセストークンのクレームをポリシーで指定するクレームを照合するようになります。
アクセストークンのその他のクレームについては、以下のドキュメントをご参照ください。
送り側 (Power Automate フロー) での作業
HTTP アクションでアクセストークンを含むリクエストを発行するようにフローを実装します。
※下図のオレンジ色の線で囲った部分
HTTP アクション
HTTP アクションでアクセストークンを含むリクエストを発行するように実装します。
ここでは、HTTP アクションのオプションを以下のように設定しました。
| オプション | 入力値 |
|---|---|
| Method | 「受け側」の「When a HTTP request is received (HTTP 要求の受信時)」トリガーで指定したメソッドを選択 |
| URI | 「受け側」の要求エンドポイント URL ※URL から SAS クエリパラメーター (sp, sv, sig) を取り除くこと ※→ https://<request-endpoint-URI>?api-version=2016-10-01
|
| Authentication | 「Active Directory OAuth」を選択 |
| Authority | 空白 (＝デフォルト) ※デフォルト＝ https://login.windows.net/
|
| Tenant | ディレクトリ (テナント) ID |
| Audience | 「受け側」のアプリケーション (クライアント) ID |
| Client ID | 「送り側」のアプリケーション (クライアント) ID |
| Credential Type | 「Secret」を選択 |
| Secret | 「送り側」のクライアント シークレット値 |
動作確認
それでは実行してみて、「送り側」、「受け側」がともに正常に動作しているか確認します。
送り側 (Power Automate フロー) を確認
下図のように HTTP アクションが正常に動作していることを確認できました。
受け側 (Logic Apps ロジックアプリ) を確認
下図のように When a HTTP request is received (HTTP 要求の受信時) トリガーが正常に動作していることを確認できました。
サインイン ログを確認
Azure AD テナントで、サービスプリンシパルのサインインログでも認証が成功していることが確認できました。
まとめ
これまでの各種設定・実装・動作確認を踏まえると、一連の承認の流れは下図のようになっていることがわかります。
「受け側」の Azure Logic Apps ロジックアプリの「Azure AD 承認ポリシー」を定義することによって、特定のクライアント (「送り側」の Power Automate フロー) からしか HTTP リクエストを受け付けないようにアクセス制限することができました。
Azure Logic Apps のセキュリティ保護については、以下のドキュメントあたりをご覧いただければと思います。