Azure Logic Apps のワークフローのアクセスとデータをセキュリティで保護する

Azure Logic Appsは、Azure Storageを使って静止データを保存し、自動的に暗号化します。 この暗号化はMicrosoft管理キーを用いてデータを保護し、組織のセキュリティおよびコンプライアンスの約束を達成するのに役立ちます。 詳細については、「Azure Storage保存データの暗号化を参照してください。

このガイドでは、Azure Logic Appsの以下の主要な分野で、機密データをさらに安全・保護する方法を紹介しています:

Task 移動
ワークフローの管理や編集を誰ができるかをコントロールします セキュアロジックアプリの操作
入力、出力、パスワード、秘密をラン履歴に隠す 安全なラン履歴データ
環境間でパラメータ値を保護する セキュアパラメータ入力
認証の種類を理解する ワークフロー操作の認証タイプをレビューしてください
ワークフローを開始する通話を認証する 安全な着信通話
ワークフローから送る呼び出しを認証します セキュアなアウトバウンド通話
特定のコネクタをブロック ブロック接続
隔離要件を満たす アイソレーション誘導
セキュリティベースラインのレビュー Azure Logic Apps に対する Azure セキュリティ ベースライン

Azure全体のセキュリティに関する情報は、以下をご覧ください:

Azure RBAC を使用してロジック アプリの操作へのアクセスをセキュリティで保護する

Azureでは、ロールベースアクセス制御(RBAC)が誰がリソースを操作する権限やアクセス権を持つかを制御します。 他の人がロジックアプリやワークフロー、接続を作成・管理する前に、必要な権限を与える役割を割り当てる必要があります。 特定のユーザーやグループだけが管理、編集、ロジックアプリの閲覧などのタスクを実行できるように権限を設定することもできます。 権限を管理するために、Azureサブスクリプションにアクセスできるメンバーに組み込みまたはカスタマイズされた役割を割り当ててください。

Important

攻撃対象を減らすために、常に 最小権限の原則に基づいて役割を割り当ててください。

役割を割り当てる前に、以下のベストプラクティス、考慮点、影響をご確認ください。

  • ユーザー、アプリ、 管理されたアイデンティティ が、仕事を遂行するために必要なデータと操作 のみ にアクセスできるようにしましょう。

  • 貢献者レベルの役割やワークフロー編集権限は 、最小権限に基づいて信頼できるプリンシパル にのみ割り当てます。

  • 管理されたアイデンティティに対して、Logic Appのワークフローで作業を行えるよう最低限必要な権限だけを割り当ててください。

  • 貢献者やワークフローの編集権限は、そのワークフローに割り当てられたすべての 管理されたアイデンティティ の権限を保持することに相当します。

  • 貢献者やワークフロー編集権限を持つ誰でも、管理されたアイデンティティを使って任意のオーディエンスに対してアイデンティティベアラートークンを要求するHTTP組み込み操作を設定できます。 これらのトークンを使って任意のエンドポイントや宛先にリクエストを送信できます。 プラットフォームは目的地を制限しません。 ベアラートークンは1時間有効で、IDが届くAzure APIならいつでもアクセスできます。

Azure Logic Appsには、消費型か標準型のワークフローかに応じて、以下の具体的な役割があります。

消費ワークフロー
役割 説明
ロジック アプリ共同作成者 ロジック アプリのワークフローは管理できますが、それらに対するアクセスを変更することはできません。
ロジック アプリ オペレーター ロジック アプリのワークフローの読み取り、有効化、無効化ができますが、編集または更新はできません。
投稿者 すべてのリソースを管理するためのフル アクセス権がありますが、Azure RBAC でロールを割り当てたり、Azure Blueprints で割り当てを管理したり、イメージ ギャラリーを共有したりすることはできません。

例えば、自分で作成していないLogicアプリのワークフローを扱い、そのワークフローで使われている接続を認証する必要があるとします。 Azure サブスクリプションでは、そのロジック アプリ リソースが存在するリソース グループに対する共同作成者権限が必要です。 Logicアプリのリソースを作成すると、自動的に Contributor アクセス権が与えられます。

他の人があなたのLogic Appのワークフローを変更したり削除したりするのを防ぐには、Azureリソースロックを使いましょう。 この機能を使用すると、他のユーザーは運用リソースを変更または削除できなくなります。 接続のセキュリティの詳細は、Azure Logic Apps の接続の構成に関する記事と、接続のセキュリティと暗号化に関する記事をご確認ください。

標準的な作業工程
役割 説明
Logic Apps Standard Reader Standard ロジック アプリとワークフロー内のすべてのリソース (ワークフローの実行とその履歴を含む) への読み取り専用アクセス権があります。
Logic Apps Standard Operator ワークフローを有効、再送信、無効化したり、Standard ロジック アプリのサービス、システム、ネットワークへの接続を作成したりできます。 オペレーター ロールは、Azure Logic Apps プラットフォームで管理タスクとサポート タスクを実行できますが、ワークフローや設定を編集するためのアクセス許可がありません。
Logic Apps Standard Developer Standard ロジック アプリのワークフロー、接続、設定を作成および編集するアクセス権があります。 開発者ロールには、仮想ネットワーク統合の構成のようなアプリケーション全体の変更など、ワークフローの範囲外で変更を行うアクセス許可がありません。 App Service プランはサポートされていません。
Logic Apps Standard Contributor Standard ロジック アプリのすべての側面を管理するアクセス権はありますが、アクセスや所有権を変更することはできません。

ワークフロー実行履歴へのアクセス

ワークフロー実行中、すべてのデータはトランスポート層セキュリティ(TLS)を用いて転送中および静止時に暗号化されます。 ロジック アプリの実行が完了したら、実行されたステップを含め、その実行の履歴を、各アクションの状態、期間、入力、出力と共に確認できます。 この豊富な詳細情報から、ロジック アプリがどのように実行されたか、発生した問題のトラブルシューティングをどこから始めるかに関する分析情報が得られます。

ロジック アプリの実行履歴を表示するときは、Azure Logic Apps によってアクセスの認証が行われた後、各実行の要求と応答に対する入力および出力へのリンクが提供されます。 ただし、パスワード、シークレット、キーなどの秘匿性の高い情報を処理するアクションについては、他のユーザーがそのデータを表示したり利用したりできないようにします。 たとえば、ロジック アプリが HTTP アクションの認証時に使用する Azure Key Vault のシークレットを取得する場合、そのシークレットが見えないようにする必要があります。

ワークフローの実行履歴における入力と出力へのアクセスを制御するには、以下のオプションを使用します。

IP アドレス範囲でアクセスを制限する

ロジック アプリ ワークフローの実行履歴に含まれる入力と出力へのアクセスは、特定の IP アドレス範囲からの要求のみでそのデータを表示できるように制限できます。

たとえば、すべてのユーザーが入力および出力にアクセスできないようにするには、IP アドレス範囲を「0.0.0.0-0.0.0.0」のように指定します。 この制限を削除できるのは管理者アクセス許可を持つユーザーのみであるため、自分のロジック アプリ ワークフローのデータに対する "ジャストインタイム" アクセスが可能になります。 有効なIP範囲では以下のフォーマットが使われます:x.x.x.x/x または x.x.x.x-x.x.x.x.x。

許可された IP 範囲を指定するには、Azure portal 内の従量課金または Standard のロジック アプリ用の手順、または Azure Resource Manager テンプレート用の手順に従ってください。

消費ワークフロー

  1. Azure portal で、従量課金ロジック アプリのワークフローをデザイナーで開きます。

  2. Logicアプリのサイドバーで、 設定の下から ワークフロー設定を選択してください。

  3. [アクセス制御の構成] セクションで、[許可された着信 IP アドレス] の下にある [トリガー アクセス オプション] リストから [特定の IP 範囲] を選択します。

  4. [コンテンツの IP 範囲] ボックスで、入力と出力からの内容にアクセスできる IP アドレス範囲を指定します。

標準的な作業工程

  1. Azure portal で、Standard ロジック アプリ リソースを開きます。

  2. Logicアプリのサイドバーで設定の「Networking」を選択してください。

  3. [着信トラフィックの構成] セクションで、[パブリック ネットワーク アクセス] の横にある [アクセス制限なしで有効] を選択します。

  4. [アクセス制限] ページの [アプリ アクセス] で、[選択した仮想ネットワークと IP アドレスから有効] を選択します。

  5. [サイトのアクセスとルール] の下にある [メイン サイト] タブで、特定の IP 範囲からの [許可] または [拒否] リクエストに対して 1 つまたは複数のルールを追加します。 HTTP ヘッダーのフィルター設定と転送設定を使用することもできます。 有効なIP範囲では以下のフォーマットが使われます:x.x.x.x/x または x.x.x.x-x.x.x.x.x。

    詳細については、Azure Logic Apps (Standard) での受信 IP アドレスのブロックに関するページを参照してください。

難読化を使用して実行履歴のデータをセキュリティで保護する

多くのトリガーおよびアクションには、ロジック アプリの実行履歴から、入力と出力のどちらかまたは両方をセキュリティで保護するための設定があります。 "マネージド コネクタ" と "カスタム コネクタ" はすべて、これらのオプションに対応しています。 ただし、以下の組み込み操作は、これらのオプションに対応していません。

セキュリティで保護された入力 - サポートされていません セキュリティで保護された出力 - サポートされていません
配列変数に追加する
文字列変数に追加する
変数の値を減らす
各
状況
変数の値を増やす
変数を初期化する
繰り返し
スコープ
変数を設定する
Switch
Terminate
Until		 配列変数に追加する
文字列変数に追加する
作成
変数の値を減らす
各
状況
変数の値を増やす
変数を初期化する
JSON の解析
繰り返し
応答
スコープ
変数を設定する
Switch
Terminate
Until
Wait

入力と出力のセキュリティ保護に関する考慮事項

これらの設定を使用してこのデータをセキュリティで保護する前に、これらの考慮事項を確認してください。

  • トリガーまたはアクションの入力または出力を隠すと、Azure Logic Apps から Azure Log Analytics にそのセキュリティで保護されたデータが送信されません。 また、そのトリガーまたはアクションに追跡対象プロパティを追加して監視することもできません。

  • セキュリティで保護された出力は、ワークフロー履歴を処理するための Azure Logic Apps API から返されません。

  • 入力を隠すか出力を明示的に隠すアクションからの出力をセキュリティで保護するには、そのアクションで [セキュリティで保護された出力] を手動で有効にします。

  • ダウンストリームのアクションで、実行履歴にそのデータを隠すよう求める場合は、[セキュリティで保護された入力] または [セキュリティで保護された出力] を確実にオンにしてください。

    [セキュリティで保護された出力] の設定

    トリガーまたはアクションで [セキュリティで保護された出力] を手動でオンにすると、Azure Logic Apps により、実行履歴でその出力が非表示になります。 それらのセキュリティで保護された出力がダウンストリームのアクションで明示的に入力として使用されている場合、Azure Logic Apps はそのアクションの入力を実行履歴では非表示としますが、アクションの [セキュリティで保護された入力] の設定は有効にしません。

    ワークフローの実行履歴における隠れた入力として、安全な出力が可視性にどのように影響するかを示す図です。

    Compose、Parse JSON、Response アクションには、セキュリティで保護された入力設定のみが含まれます。 この設定をオンにした場合、それらのアクションの出力も非表示になります。 セキュリティで保護されたアップストリームの出力がそれらのアクションの入力として明示的に使用された場合、Azure Logic Apps によってそれらのアクションの入力と出力は非表示となりますが、それらのアクションの [セキュリティで保護された入力] の設定は有効になりません。 ダウンストリーム アクションが Compose、Parse JSON、または Response アクションの非表示の出力を入力として明示的に使用している場合、Azure Logic Appsは、このダウンストリーム アクションの入力または出力を非表示にしません。

    Compose、Parse JSON、Responseアクションの入力として、セキュアな出力が可視性にどのように影響するかを示す図です。

    [セキュリティで保護された入力] の設定

    トリガーまたはアクションで [セキュリティで保護された入力] を手動でオンにすると、Azure Logic Apps により、実行履歴でその入力が非表示になります。 そのトリガーまたはアクションからの表示可能な出力がダウンストリームのアクションの入力として明示的に使用されている場合、Azure Logic Apps は、そのダウンストリームのアクションの入力を実行履歴で非表示にしますが、このアクションの [セキュリティで保護された入力] は有効にならず、そのアクションの出力が非表示になることもありません。

    安全なトリガー入力やアクション入力が、下流のワークフローアクションの入力として可視性にどのように影響するかを示す図。

    Compose、Parse JSON、Responseアクションがトリガーやアクションの見える出力を明示的に使用し、そのトリガーやアクションの安全な入力を使っている場合、Azure Logic Appsはこれらのアクションの入力と出力を隠しますが、これらのアクションのSecure Inputs設定は有効にしません。 ダウンストリーム アクションが Compose、Parse JSON、または Response アクションの非表示の出力を入力として明示的に使用している場合、Azure Logic Appsは、このダウンストリーム アクションの入力または出力を非表示にしません。

    これは、Compose、Parse JSON、Responseワークフローのアクションがセキュア入力にどのように影響するかを示す図です。

デザイナーで入力と出力のセキュリティを保護する

  1. Azure portal で、ロジック アプリ ワークフローをデザイナーで開きます。

  2. デザイナーで、機密データをセキュリティで保護するトリガーまたはアクションを選択します。

  3. 表示された情報ウィンドウで、[設定] を選択し、[セキュリティ] を展開します。

    Azure ポータル、ワークフロー デザイナー、および設定が開かれた状態のトリガーまたはアクションを示すスクリーンショット。

  4. [セキュリティで保護された入力] と [セキュリティで保護された出力] のいずれかまたは両方をオンにします。

    アクションのSecure InputsまたはSecure Outputs設定が有効になっているワークフローを示すスクリーンショットです。

    トリガーまたはアクションのタイトル バーにロック アイコンが表示されます。 前のアクションからのセキュリティで保護された出力を表すトークンにも、ロック アイコンが表示されます。 たとえば、後続のアクションでは、動的コンテンツ リストからセキュリティで保護された出力のトークンを選択すると、そのトークンにロック アイコンが表示されます。

    次のアクションの動的コンテンツリストが開いているワークフローと、前のアクションのロックアイコン付きセキュア出力トークンを示すスクリーンショットです。

  5. ワークフローの実行後、その実行の履歴を表示できます。

    1. ロジック アプリのサイドバーで、[概要] を選択します。

    2. [実行履歴] で、表示したい実行を選択します。

    3. ワークフローの [実行履歴] ウィンドウで、確認したいアクションを選択します。

      入力と出力の両方を非表示にした場合は、それらの値が非表示になります。

      スタンダードワークフローの実行履歴表示で、入力と出力が隠されているスクリーンショットです。

コード ビューで入力と出力のセキュリティを保護する

基になるトリガーまたはアクションの定義で、次の値のいずれかまたは両方を含んだ runtimeConfiguration.secureData.properties 配列を追加または更新します。

  • "inputs":実行履歴における入力のセキュリティを保護します。
  • "outputs":実行履歴における出力のセキュリティを保護します。
"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

環境間でのパラメータ入力への安全なアクセス

デプロイ先が複数の異なる環境にまたがる場合、環境に応じて変わる値は、ワークフロー定義内でパラメーター化することを検討してください。 Azure Resource Managerのテンプレートを使ってロジックアプリをデプロイすることで、ハードコーディングされたデータを避け、セキュアなパラメータを定義して機密データを保護し、パラメータファイルを使ってテンプレートのパラメータに別々の入力としてデータを渡すことができます。

たとえば、Microsoft Entra ID を使用した OAuth で HTTP アクションの認証を行う場合、認証に使用されるクライアント ID とクライアント シークレットを受け入れるパラメーターを定義し、隠すことができます。 ロジック アプリ ワークフローでこれらのパラメーターを定義するには、ロジック アプリのワークフロー定義内の parameters セクションと、デプロイ用の Resource Manager テンプレートを使用します。 ロジック アプリの編集時や実行履歴の確認時に表示させたくないパラメーター値をセキュリティで保護するには、securestring または secureobject 型を使用してパラメーターを定義し、必要に応じてエンコードを使用します。 この型のパラメーターはリソース定義と一緒に返されず、デプロイ後にリソースを表示するときにもアクセスできません。 それらのパラメーターの値に実行時にアクセスするには、ワークフロー定義内で @parameters('<parameter-name>') 式を使用します。 この式は実行時にのみ評価され、ワークフロー定義言語で記述されます。

Note

リクエストヘッダーや本文にパラメータを使うと、ワークフローの実行履歴や送信HTTPリクエストを見るときにそのパラメータが見えることがあります。 コンテンツ アクセス ポリシーも適切に設定するようにしてください。 難読化を使用して、実行履歴の入力と出力を表示されないようにすることもできます。

既定では、Authorization ヘッダーは入力または出力で表示されません。 そこで秘密を使うと、その秘密は取り戻せません。

詳細については、この記事の次のセクションを参照してください。

Resource Manager テンプレートを使用してロジック アプリのデプロイを自動化する場合は、デプロイ時に評価される、セキュリティで保護されたテンプレート パラメーターを、securestring 型と secureobject 型を使用して定義できます。 テンプレート パラメーターを定義するには、テンプレートの最上位の parameters セクションを使用します。このセクションは独立しており、ワークフロー定義の parameters セクションとは異なります。 テンプレートのパラメーターに値を指定するには、別途パラメーター ファイルを使用します。

たとえばシークレットを使用する場合、それらのシークレットをデプロイ時に Azure Key Vault から取得する、セキュリティで保護されたテンプレート パラメーターを定義して使用することができます。 その後、パラメーター ファイルの中で、キー コンテナーとシークレットを参照することができます。 詳細については、以下を参照してください:

ワークフロー定義内のパラメーターをセキュリティで保護する (従量課金ワークフロー)

ロジック アプリのワークフロー定義内の秘匿性の高い情報を保護するには、その情報がロジック アプリ ワークフローの保存後に表示されないよう、セキュリティで保護されたパラメーターを使用します。 例えば、基本的な認証を必要とするHTTPアクションがあり、ユーザー名とパスワードを使ったとします。 ワークフロー定義の parameters セクションでは、basicAuthPasswordParam 型を使用して basicAuthUsernameParam パラメーターと securestring パラメーターを定義します。 そのうえで、これらのパラメーターをアクション定義の authentication セクションで参照します。

Important

最適なセキュリティを確保するため、可能であれば、認証には Microsoft Entra ID と マネージド ID を使用してください。 このオプションは認証情報を必要としない優れたセキュリティを提供します。 この ID は Azure で管理され、認証情報が安全に保たれます。この機密情報をユーザー側で管理する必要がないからです。

Azure Logic Apps のマネージド ID を設定するには、「Azure Logic Apps で マネージド ID を使用して Azure リソースへのアクセスと接続を認証する」を参照してください。

"definition": {
   "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
   "actions": {
      "HTTP": {
         "type": "Http",
         "inputs": {
            "method": "GET",
            "uri": "https://www.microsoft.com",
            "authentication": {
               "type": "Basic",
               "username": "@parameters('basicAuthUsernameParam')",
               "password": "@parameters('basicAuthPasswordParam')"
            }
         },
         "runAfter": {}
      }
   },
   "parameters": {
      "basicAuthPasswordParam": {
         "type": "securestring"
      },
      "basicAuthUsernameParam": {
         "type": "securestring"
      }
   },
   "triggers": {
      "manual": {
         "type": "Request",
         "kind": "Http",
         "inputs": {
            "schema": {}
         }
      }
   },
   "contentVersion": "1.0.0.0",
   "outputs": {}
}

Azure Resource Manager テンプレート内のパラメーターをセキュリティで保護する (従量課金ワークフロー)

ロジック アプリのリソースおよびワークフロー用の Resource Manager テンプレートには、複数の parameters セクションが存在します。 パスワード、キー、シークレットなどの秘匿性の高い情報を保護するには、テンプレート レベルおよびワークフロー定義レベルで、securestring または secureobject 型を使用して、セキュリティで保護されたパラメーターを定義します。 その後、これらの値を Azure Key Vault に格納すれば、パラメーター ファイルを使用して Key Vault とシークレットを参照することができます。 その後、デプロイ時にご利用のテンプレートからその情報を取得します。 詳しくは、デプロイ時に Azure Key Vault を使用して機密性の値を渡す方法に関する記事を参照してください。

Important

最適なセキュリティを確保するには、可能な場合は、認証にMicrosoft Entra IDとマネージド IDを使用してください。 このオプションは認証情報を必要としない優れたセキュリティを提供します。 この ID は Azure で管理され、認証情報が安全に保たれます。この機密情報をユーザー側で管理する必要がないからです。

Azure Logic Apps のマネージド ID を設定するには、「Azure Logic Apps で マネージド ID を使用して Azure リソースへのアクセスと接続を認証する」を参照してください。

このリストには、これらの parameters セクションの詳細が含まれています。

  • テンプレートの最上位の parameters セクションには、そのテンプレートが "デプロイ" 時に使用する値のパラメーターを定義します。 たとえば、特定のデプロイ環境の接続文字列がそのような値として考えられます。 これらの値は、独立したパラメーター ファイルに格納できるので、値の変更も容易に行うことができます。

  • ロジック アプリのリソース定義内、かつワークフロー定義の外側にある parameters セクションでは、ワークフロー定義のパラメーターの値を指定します。 このセクションでは、テンプレートのパラメーターを参照するテンプレート式を使用して、それらの値を割り当てることができます。 これらの式は、デプロイ時に評価されます。

  • ワークフロー定義内の parameters セクションでは、ロジック アプリ ワークフローによって実行時に使用されるパラメーターを定義します。 これらのパラメーターは、ロジック アプリのワークフロー内から、実行時に評価されるワークフロー定義式を使用して参照できます。

この例のテンプレートには、securestring 型を使用する、セキュリティで保護されたパラメーターの定義が複数存在します。

パラメーター名 説明
TemplatePasswordParam パスワードを受け取るテンプレート パラメーター。パスワードはその後、ワークフロー定義の basicAuthPasswordParam パラメーターに渡されます。
TemplateUsernameParam ユーザー名を受け取るテンプレート パラメーター。ユーザー名はその後、ワークフロー定義の basicAuthUserNameParam パラメーターに渡されます。
basicAuthPasswordParam HTTP アクションで基本認証用のパスワードを受け取るワークフロー定義パラメーター
basicAuthUserNameParam HTTP アクションで基本認証用のユーザー名を受け取るワークフロー定義パラメーター 
{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {
      "LogicAppName": {
         "type": "string",
         "minLength": 1,
         "maxLength": 80,
         "metadata": {
            "description": "Name of the Logic App."
         }
      },
      "TemplatePasswordParam": {
         "type": "securestring"
      },
      "TemplateUsernameParam": {
         "type": "securestring"
      },
      "LogicAppLocation": {
         "type": "string",
         "defaultValue": "[resourceGroup().location]",
         "allowedValues": [
            "[resourceGroup().location]",
            "eastasia",
            "southeastasia",
            "centralus",
            "eastus",
            "eastus2",
            "westus",
            "northcentralus",
            "southcentralus",
            "northeurope",
            "westeurope",
            "japanwest",
            "japaneast",
            "brazilsouth",
            "australiaeast",
            "australiasoutheast",
            "southindia",
            "centralindia",
            "westindia",
            "canadacentral",
            "canadaeast",
            "uksouth",
            "ukwest",
            "westcentralus",
            "westus2"
         ],
         "metadata": {
            "description": "Location of the Logic App."
         }
      }
   },
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
               "actions": {
                  "HTTP": {
                     "type": "Http",
                     "inputs": {
                        "method": "GET",
                        "uri": "https://www.microsoft.com",
                        "authentication": {
                           "type": "Basic",
                           "username": "@parameters('basicAuthUsernameParam')",
                           "password": "@parameters('basicAuthPasswordParam')"
                        }
                     },
                  "runAfter": {}
                  }
               },
               "parameters": {
                  "basicAuthPasswordParam": {
                     "type": "securestring"
                  },
                  "basicAuthUsernameParam": {
                     "type": "securestring"
                  }
               },
               "triggers": {
                  "manual": {
                     "type": "Request",
                     "kind": "Http",
                     "inputs": {
                        "schema": {}
                     }
                  }
               },
               "contentVersion": "1.0.0.0",
               "outputs": {}
            },
            "parameters": {
               "basicAuthPasswordParam": {
                  "value": "[parameters('TemplatePasswordParam')]"
               },
               "basicAuthUsernameParam": {
                  "value": "[parameters('TemplateUsernameParam')]"
               }
            }
         }
      }
   ],
   "outputs": {}
}

認証をサポートするコネクタの認証の種類

次の表では、認証の種類を選択できるコネクタの操作で使用できる認証の種類を示します。

認証の種類 Logicアプリと対応コネクタ
Basic Azure API Management、Azure App Service、HTTP、HTTP + Swagger、HTTP Webhook
クライアント証明書 Azure API Management、Azure App Service、HTTP、HTTP + Swagger、HTTP Webhook
Active Directory OAuth (Microsoft Entra ID を使用した OAuth 2.0) - 従量課金: Azure API Management、Azure App Service、Azure Functions、HTTP、HTTP + Swagger、HTTP Webhook

- Standard: Azure Automation、Azure Blob Storage、Azure Event Hubs、Azure キュー、Azure Service Bus、Azure テーブル、HTTP、HTTP Webhook、SQL Server
生 Azure API Management、Azure App Service、Azure Functions、HTTP、HTTP + Swagger、HTTP Webhook
マネージド ID 内蔵コネクタ:

- 従量課金: Azure API Management、Azure App Service、Azure Functions、HTTP、HTTP Webhook

- Standard: Azure Automation、Azure Blob Storage、Azure Event Hubs、Azure キュー、Azure Service Bus、Azure テーブル、HTTP、HTTP Webhook、SQL Server

注: 現在、ほとんどのサービス プロバイダー ベースの組み込みコネクタで、認証用ユーザー割り当てマネージド ID の選択がサポートされていません。

マネージド コネクタ: Azure App Service、Azure Automation、Azure Blob Storage、Azure Container Instance、Azure Cosmos DB、Azure Data Explorer、Azure Data Factory、Azure Data Lake、Azure Event Grid、Azure Event Hubs、Azure IoT Central V2、Azure IoT Central V3、Azure Key Vault、Azure Log Analytics、Azure キュー、Azure Resource Manager、Azure Service Bus、Azure Sentinel、Azure Table Storage、Azure VM、HTTP with Azure AD、SQL Server

Important

最適なセキュリティを確保するには、可能な場合は認証に Microsoft Entra ID と マネージド ID を使用してください。 このオプションは認証情報を必要としない優れたセキュリティを提供します。 この ID は Azure で管理され、認証情報が安全に保たれます。この機密情報をユーザー側で管理する必要がないからです。

Azure Logic Apps のマネージド ID を設定するには、「Azure Logic Apps で マネージド ID を使用して Azure リソースへのアクセスと接続を認証する」を参照してください。

要求ベースのトリガーへの受信呼び出しへのアクセス

ロジック アプリが要求ベースのトリガー (Request トリガーや HTTP Webhook トリガーなど) を介して受信する受信呼び出しによって、暗号化がサポートされており、少なくともトランスポート層セキュリティ (TLS) 1.2 (旧名は Secure Sockets Layer (SSL)) でセキュリティ保護されます。 Azure Logic Apps で、Request トリガーへの受信呼び出し、または HTTP Webhook トリガーもしくはアクションへのコールバックが受信されるときに、このバージョンが適用されます。

Note

TLS ハンドシェイク エラーが発生する場合は、TLS 1.2 を使用していることを確認してください。 詳細については、TLS 1.0 の問題の解決 を参照してください。

受信呼び出しの場合は、次の暗号スイートを使用します。

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384。
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256。
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384。
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384。
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256。
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384。
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256。

Important

Azure Logic Apps は現在、下位互換性のために以前の暗号スイートをサポートしています。 ただし、以前の暗号スイートは今後サポートされ "なくなる可能性がある" ため、新しいアプリを開発するときは "使用しないでください"。

たとえば、Azure Logic Apps で、またはご自身のロジック アプリの URL 上でセキュリティ ツールを使用することで、TLS ハンドシェイク メッセージを検査すると、次の暗号スイートが見つかることがあります。 繰り返しになりますが、これらの以前のスイートは "使用しないでください"。

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA。
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA。
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA。
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA。
  • TLS_RSA_WITH_AES_256_GCM_SHA384。
  • TLS_RSA_WITH_AES_128_GCM_SHA256。
  • TLS_RSA_WITH_AES_256_CBC_SHA256。
  • TLS_RSA_WITH_AES_128_CBC_SHA256。
  • TLS_RSA_WITH_AES_256_CBC_SHA。
  • TLS_RSA_WITH_AES_128_CBC_SHA。
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA。

ご利用のロジック アプリ ワークフローへの受信呼び出しを受信するトリガーへのアクセスを制限して、承認されたクライアントのみがそのワークフローを呼び出せるようにする方法を、次に一覧に示します。

Microsoft Entra ID を使用した OAuth 2.0 を有効にする

要求ベースのトリガーで始まる従量課金ワークフローでは、Microsoft Entra ID を使用した OAuth 2.0 を有効にすることで、そのトリガーによって作成されたエンドポイントに送信された受信呼び出しを認証して承認できます。 この認証を設定するには、ロジック アプリ リソース レベルで承認ポリシーを定義または追加します。 このように、受信呼び出しでは、承認のために OAuth アクセス トークン を使用します。

ロジック アプリ ワークフローで、OAuth アクセス トークンを含む外部からの要求を受け取る場合、Azure Logic Apps では、トークンのクレームを、各認証ポリシーで指定するクレームと照合します。 トークンのクレームと、少なくとも 1 つのポリシーに含まれるすべてのクレームが一致した場合、受信要求に対して承認が成功します。 トークンは、承認ポリシーで指定された数よりも多くのクレームを持つことができます。

Request トリガー (Webhook トリガーではなく) で始まる Standard ワークフローでは、マネージド ID を使用して、Request トリガーによって作成されたエンドポイントに送信される受信呼び出しを認証するために、Azure Functions プロビジョニングを使用できます。 このプロビジョニングは「Easy Auth」 とも呼ばれます。 詳細については、「Easy Auth を使用した Standard ロジック アプリでワークフローをトリガーする」を参照してください。

Microsoft Entra ID を使用した OAuth 2.0 を有効にする前の考慮事項

  • 最適なセキュリティを確保するために、可能な場合は、マネージド ID で Microsoft Entra ID を認証に使用することをお勧めします。 このオプションは認証情報を必要としない優れたセキュリティを提供します。 この ID は Azure で管理され、認証情報が安全に保たれます。この機密情報をユーザー側で管理する必要がないからです。 Azure Logic Apps のマネージド ID を設定するには、「Azure Logic Apps で マネージド ID を使用して Azure リソースへのアクセスと接続を認証する」を参照してください。

  • 従量課金ワークフローでは、要求ベースのトリガーのエンドポイント URL への受信呼び出しで使用できる認可スキームは、Microsoft Entra ID を使用した OAuth 2.0 または Shared Access Signature (SAS) のいずれか 1 つのみです。 一方のスキームを使用してももう一方のスキームは無効になりませんが、両方のスキームを同時に使用すると、サービスではどちらのスキームを選択するかわからないため、Azure Logic Apps でエラーが発生します。 従量課金ワークフローが Request トリガーで始まる場合は、SAS 認証を無効にし、Microsoft Entra ID を使用した OAuth 2.0 のみを使用するように認証を制限することができます。 Standard ワークフローの場合、SAS を無効にすることなく、他の認証の種類を使用できます。

  • Azure Logic Apps では、Microsoft Entra ID OAuth アクセス トークンに対してベアラー型または所有証明型 (従量課金ロジック アプリのみ) の認可スキームのどちらかがサポートされています。 ただし、アクセス トークンの Authorization ヘッダーでは、Bearer 型または PoP 型のどちらかを指定する必要があります。 PoP トークンを取得して使用する方法について詳しくは、「所有証明 (PoP) トークンを取得する」をご覧ください。

  • 従量課金ロジック アプリ リソースは、承認ポリシーの最大数に制限されている必要があります。 各承認ポリシーには、クレームの最大数もあります。 詳細については、Azure Logic Apps の制限と構成に関するページを参照してください。

  • 認可ポリシーには少なくとも 発行者 および オーディエン スクレームが含まれなければなりません。 発行者の請求額は、Microsoft Entra IDの発行者としてhttps://sts.windows.net/またはhttps://login.microsoftonline.com/(OAuth V2)で始まるものです。 Audienceクレームは、あなたのLogicアプリリソースの期待されるオーディエンス値を持っています。

    たとえば、ロジック アプリ リソースに、対象ユーザーと発行者という 2 つのクレームの種類が必要な承認ポリシーがあるとします。 デコードされたアクセス トークンの、このサンプルのペイロード セクションには、両方のクレームの種類が含まれています。aud は対象ユーザーの値で、iss は発行者の値です。

    {
    "aud": "https://management.core.windows.net/",
    "iss": "https://sts.windows.net/<Azure-AD-issuer-ID>/",
    "iat": 1582056988,
    "nbf": 1582056988,
    "exp": 1582060888,
    "_claim_names": {
       "groups": "src1"
    },
    "_claim_sources": {
       "src1": {
          "endpoint": "https://graph.windows.net/7200000-86f1-41af-91ab-2d7cd011db47/users/00000-f433-403e-b3aa-7d8406464625d7/getMemberObjects"
       }
    },
    "acr": "1",
    "aio": "AVQAq/8OAAAA7k1O1C2fRfeG604U9e6EzYcy52wb65Cx2OkaHIqDOkuyyr0IBa/YuaImaydaf/twVaeW/etbzzlKFNI4Q=",
    "amr": [
       "rsa",
       "mfa"
    ],
    "appid": "c44b4083-3bb0-00001-b47d-97400853cbdf3c",
    "appidacr": "2",
    "deviceid": "bfk817a1-3d981-4dddf82-8ade-2bddd2f5f8172ab",
    "family_name": "Sophia Owen",
    "given_name": "Sophia Owen (Fabrikam)",
    "ipaddr": "167.220.2.46",
    "name": "sophiaowen",
    "oid": "3d5053d9-f433-00000e-b3aa-7d84041625d7",
    "onprem_sid": "S-1-5-21-2497521184-1604012920-1887927527-21913475",
    "puid": "1003000000098FE48CE",
    "scp": "user_impersonation",
    "sub": "KGlhIodTx3XCVIWjJarRfJbsLX9JcdYYWDPkufGVij7_7k",
    "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
    "unique_name": "SophiaOwen@fabrikam.com",
    "upn": "SophiaOwen@fabrikam.com",
    "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
    "ver": "1.0"
}

要求エンドポイントを呼び出す唯一のオプションとして Microsoft Entra ID を使用して OAuth 2.0 を有効にする

要求ベースのエンドポイントの場合は、Microsoft Entra ID を使用した OAuth 2.0 のみを使用するように認可を制限できます。 このオプションは、Shared Access Signature (SAS) 認証を無効にしても機能します。

  1. ワークフローの場合は、 要求 トリガーまたは HTTP Webhook トリガーの 出力に "Authorization" ヘッダーを含める手順に従って OAuth アクセス トークンを確認する機能を使用して、要求トリガーまたは HTTP Webhook トリガーを設定します。

    Note

    この手順により、Authorization ヘッダーがワークフローの実行履歴とトリガーの出力に表示されます。

  2. Azure ポータルで、デザイナーでワークフローを開きます。

  3. デザイナーで、トリガーを選択します。 表示された情報ウィンドウで、[ 設定] を選択します。

  4. [全般]>[トリガー条件] で、[追加] を選択します。 トリガー条件ボックスに、使用したいトークンの種類に基づいて次のいずれかの式を入力します。

    @startsWith(triggerOutputs()?['headers']?['Authorization'], 'Bearer')

    -又は-

    @startsWith(triggerOutputs()?['headers']?['Authorization'], 'PoP')

正しい権限なしでトリガーエンドポイントを呼び出すと、実行履歴にはトリガーが Skipped として表示され、トリガー条件が失敗したというメッセージはありません。

所有証明 (PoP) トークンを取得する

Microsoft Authentication Library (MSAL) ライブラリには、使用できる PoP トークンが用意されています。 もし呼び出したいConsumption logicアプリのワークフローでPoPトークンが必要なら、MSALライブラリを使ってこのトークンを取得できます。 次のサンプルは、PoP トークンを取得する方法を示しています。

従量課金ロジック アプリ ワークフローで PoP トークンを使用するには、次の手順に従って Microsoft Entra ID を使用した OAuth を設定します。

従量課金ロジック アプリ リソースに Microsoft Entra ID を使用した OAuth を有効にする

従量課金ロジック アプリに承認ポリシーを追加するには、Azure portal または Azure Resource Manager テンプレートで次の手順に従います。

  1. Azure portal で、従量課金ロジック アプリとワークフローをデザイナーで開きます。

  2. Logicアプリのサイドバーで設定の「認証」を選択してください。

  3. [認可] ページで、[ポリシーの追加] を選択します。

    Azureポータル、認証ページ、ポリシー追加ボタンを選択しているスクリーンショットです。

  4. 承認ポリシーに関する情報は、ロジック アプリが、Request トリガーへの各受信呼び出しによって示されるアクセス トークンで必要とするクレームの種類と値を指定することで提供します。

    Azureポータル、認証ページ、認証ポリシーの詳細を示すスクリーンショットです。

    財産 必須 タイプ 説明
    ポリシー名 Yes String 承認ポリシーに使用する名前
    ポリシーの種類 Yes String ベアラー型トークン用の AAD、または所有証明型トークン用の AADPOP のいずれか。
    Claims Yes String ワークフローの要求トリガーが、トリガーへのそれぞれの受信呼び出しによって提示されるアクセス トークン内で予期する要求の種類と値を指定するキーと値のペア。 [標準要求の追加] を選んで、任意の必要な標準要求を追加できます。 PoP トークンに固有の要求を追加するには、[カスタム要求の追加] を選びます。

    使用可能な標準クレームの種類:

    - 発行者
    - 観客
    - 件名
    - JWT ID (JSON Web Token ID)

    必要条件：

    - 少なくとも、 要求 一覧には次の要求の種類が含まれている必要があります。

    -- 発行者: https://sts.windows.net/またはhttps://login.microsoftonline.com/で始まる値をMicrosoft Entra発行者 ID として設定します。
    -- 対象ユーザー: 値は、ロジック アプリ リソースに対して予想される対象ユーザーに設定されます。

    - 各クレームは、値の配列ではなく、単一の文字列値である必要があります。 たとえば、種類として Role を持ち、値として Developer を持つクレームを作成できます。 種類として Role を持ち、値が Developer および Program Manager に設定されているクレームを作成することはできません。

    クレームの値は最大文字数に制限されます。

    独自のクレームの種類と値を指定することもできます。 これらのクレームの種類の詳細については、Microsoft Entra のセキュリティ トークンのクレームを参照してください。

    次の例は、PoP トークンの情報を示しています。

    Azureポータル、認可ページ、所有証明ポリシー情報を示すスクリーンショットです。

  5. 別のクレームを追加するには、次のオプションから選択します。

    • 別のクレームの種類を追加するには、[Add standard claim]\(標準クレームの追加\) を選択し、クレームの種類を選択して、クレームの値を指定します。

    • 独自の要求を追加するには、[カスタム要求の追加] を選択します。 詳細については、アプリに省略可能な要求を提供する方法に関するページを参照してください。 カスタム要求は、その後、JWT ID の一部として格納されます (例: "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee")。

  6. 別の承認ポリシーを追加するには [ポリシーの追加] を選択します。 ポリシーを設定するには、前の手順を繰り返します。

  7. 完了したら、[保存] を選択します。

  8. 要求ベースのトリガー出力にアクセス トークンの Authorization ヘッダーを含めるには、「要求および HTTP Webhook トリガーの出力に "Authorization" ヘッダーを含める」を参照してください。

ポリシーなどのワークフロー プロパティは、Azure portal のワークフローのコード ビューに表示されません。 プログラムによってポリシーにアクセスするには、Azure Resource Manager を使用して次の API を呼び出します: https://management.azure.com/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group-name}/providers/Microsoft.Logic/workflows/{your-workflow-name}?api-version=2016-10-01&_=1612212851820。 必ず、Azure サブスクリプション ID、リソース グループ名、およびワークフロー名のプレースホルダー値を置き換えてください。

要求または HTTP Webhook トリガーの出力に "Authorization" ヘッダーを含める

要求ベースのトリガーにアクセスする受信呼び出しを認可するために Microsoft Entra ID を使用した OAuth を有効にするロジック アプリの場合、Request トリガーまたは HTTP Webhook トリガーの出力を有効にして、OAuth アクセス トークンの Authorization ヘッダーを含めることができます。 トリガーの基になる JSON 定義で、operationOptions プロパティを追加して IncludeAuthorizationHeadersInOutputs に設定します。 Request トリガーの例を次に示します。

"triggers": {
   "manual": {
      "inputs": {
         "schema": {}
      },
      "kind": "Http",
      "type": "Request",
      "operationOptions": "IncludeAuthorizationHeadersInOutputs"
   }
}

詳細については、以下を参照してください:

Shared Access Signature (SAS) のキーまたはトークンを生成する

ワークフローが要求ベースのトリガーで始まり、そのワークフローを初めて保存すると、Azure Logic Apps はそのトリガーに呼び出し可能なエンドポイントを作成します。 このエンドポイントには、ワークフローを開始するための受信呼び出しまたは要求を受信できる URL があります。 URL には、Shared Access Signature (SAS) が含まれています。これは、ストレージ サービスなどにアクセス許可を付与するキーまたはトークンです。 このエンドポイント URL は、次の形式を使用します。

https://<request-endpoint-URI>sp=<permissions>sv=<SAS-version>sig=<signature>

たとえば、Request トリガーでこの URL を表示するには、トリガーの HTTP URL プロパティを見つけます。

Azureポータル、消費ワークフロー、リクエストトリガーエンドポイントプロパティ(HTTP URL)を示すスクリーンショットです。

完全な URL は次の例のようになります。

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

URL の SAS にはクエリ パラメーターがあり、次の表で説明します。

Query parameter (クエリ パラメーター) 説明
sp 使用が許可された HTTP メソッドのアクセス許可を指定します。
sv 署名の生成に使用する SAS バージョンを指定します。
sig トリガーへのアクセスの認証に使用する署名を指定します。 この署名は、SHA256 アルゴリズムとシークレット アクセス キーを使用してすべての URL パスとプロパティで生成されます。 このキーは秘密に保たれ暗号化され、ロジック アプリと共に格納され、決して公開されることはありません。 お客様のロジック アプリでは、秘密鍵を使用して作成された有効な署名を含むそれらのトリガーのみが承認されます。

Important

アカウントキーを不正使用から守るように、SASキーも守りましょう。 侵害されたアクセス キーを取り消す計画を設定するか、その計画を立てておくようにしてください。 アクセス キーを使用する URI を配布する際には細心の注意を払い、そのような URI は HTTPS などの安全な接続でのみ配布するようにしてください。 アクセス キーを使用する操作は、HTTPS 接続上でのみ実行するようにしてください。 有効なキーを持つ URI があれば、誰でもその関連リソースにアクセスできます。

セキュリティを維持し、ワークフローへのアクセスを保護するために、アクセス キーはセキュリティ ポリシーに準拠する必要が生じたり侵害されたりする可能性があるため、アクセス キーを定期的に再生成してください。 これにより、承認されたリクエストのみがワークフローを起動できるようになり、データとプロセスを不正アクセスから保護することができます。

ストレージサービスにアクセスするためにSASキーを使う場合は、アカウントキーではなくMicrosoft Entra IDで保護されたユーザー委任SASを作成しましょう。

最適なセキュリティを確保するために、可能な限り管理されたIDと共にMicrosoft Entra IDを認証に使用してください。 このオプションは認証情報を必要としない優れたセキュリティを提供します。 この ID は Azure で管理され、認証情報が安全に保たれます。この機密情報をユーザー側で管理する必要がないからです。 Azure Logic Apps のマネージド ID を設定するには、「Azure Logic Apps で マネージド ID を使用して Azure リソースへのアクセスと接続を認証する」を参照してください。

要求ベースのトリガーでのエンドポイントへの受信呼び出しでは、1 つの認可スキーム (SAS または Microsoft Entra ID を使用した OAuth 2.0) のみを使用できます。 一方のスキームを使用してももう一方のスキームは無効になりませんが、両方のスキームを同時に使用すると、サービスではどちらのスキームを選択するかわからないため、Azure Logic Apps でエラーが発生します。

従量課金ワークフローが Request トリガーで始まる場合は、SAS 認証を無効にできます。 このオプションは、Microsoft Entra ID を使用した OAuth 2.0 のみを使用するように認可を制限している場合でも機能します。 Standard ワークフローの場合、SAS を無効にすることなく、他の認証の種類を使用できます。

SAS キーを使用する場合のセキュリティの詳細については、このガイドの以下のセクションを参照してください。

Shared Access Signature (SAS) 認証を無効にする

既定では、要求ベースのトリガーでは SAS 認証が有効になっています。 トリガーのエンドポイント URL には、次に例を示すクエリ パラメーター sp-<permissions>sv-<SAS-version>sig=<signature> で始まる SAS が含まれます。

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

ワークフローが要求トリガーで始まり、Microsoft Entra IDで OAuth を使用する場合は、SAS 認証を無効にして、ワークフローの実行に関するエラーや問題を回避できます。 また、シークレットへの依存関係を削除してセキュリティ レイヤーを追加します。これにより、シークレットがログに記録されたり漏洩したりするリスクが軽減されます。

このオプションは、要求ベースのエンドポイントを呼び出す唯一のオプションとして Microsoft Entra ID を使用した OAuth 2.0 を有効にする場合にも機能します。 Standard ワークフローの場合、SAS を無効にすることなく、他の認証の種類を使用できます。

Note

このアクションにより、受信要求の SAS 認証が無効になり、既存の SAS キーまたは署名が機能するのをブロックします。 ただし、SAS キーまたは署名は引き続き有効であり、SAS 認証を再度有効にした場合でも機能します。

新しいバージョンを作成して SAS キーと署名を無効にするには、「アクセス キー を再生成する」を参照してください。

SAS 認証を無効にすると、Request トリガーのエンドポイント URL に SAS キーが含まれなくなります。次に例を示します。

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01

SAS認証を無効化するための前提条件

リクエストベースのトリガーでSAS認証を無効にするには、REST API呼び出しを送信するツールが必要です。例えば:

Caution

資格情報、シークレット、アクセス トークン、API キーなどの機密データがあるシナリオでは、必要なセキュリティ機能でデータを保護するツールを必ず使用してください。 このツールはオフラインまたはローカルで動作する必要があり、オンライン アカウントへのサインインやクラウドへのデータの同期は必要ありません。 これらの特性を持つツールを使用すると、機密データを一般に公開するリスクが軽減されます。

SAS が有効または無効になっているトリガーを確認する

SAS 認証が無効になっている場合、トリガーのエンドポイント URL には SAS キーが含まれません。 また、従量課金ワークフロー定義には、sasAuthenticationPolicy JSON オブジェクトが含まれています。 このオブジェクトでは、state プロパティが Disabled に設定されています。次に例を示します。

"properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}

SAS が有効または無効になっている従量課金ワークフローを見つけるには、state プロパティが Disabled に設定されている sasAuthenticationPolicy オブジェクトがワークフロー定義に含まれているかどうかを確認します。

  1. REST API 呼び出しを送信するツールで、次の GET 要求を使用して、ワークフロー - Get 操作を実行してワークフローに関する情報を取得します。

    GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

  2. ワークフロー - Get 操作から出力を取得し、state プロパティが Disabled に設定されている sasAuthenticationPolicy オブジェクトが存在するかどうかを確認します。

sasAuthenticationPolicy プロパティをワークフロー定義に追加する

SAS 認証を無効にする従量課金ワークフローの場合は、次の手順に従います。

  1. まだ行っていない場合は、次の GET 要求を使用してワークフロー - Get 操作を実行して、ワークフローに関する情報を取得します。

    GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

  2. ワークフロー - Get 操作から出力を取得し、次の要素を手動で追加します。

    1. properties オブジェクトに、accessControl オブジェクトを含む triggers オブジェクトを追加します (存在しない場合)。

    2. triggers オブジェクトで、sasAuthenticationPolicy に設定された state プロパティを含む Disabled オブジェクトを追加します。

    完了すると、編集されたパーツは次の例のようになります。

    "properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}

  3. 次のような PUT 要求を使用して、ワークフロー - Update 操作を実行して、要求本文の入力として使用する編集済み出力でワークフローを更新する別の要求を送信します。

    PUT https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

  4. Azure portal で、デザイナーの従量課金ワークフローに移動し、Request トリガーの URL に SAS が含まれていないことを確認します。

  5. Microsoft Entra ID で OAuth 2.0 を有効にするには、ロジック アプリのリソース レベルで、Microsoft Entra ID を使用した OAuth 用に承認ポリシーを追加します。

    詳細については、「Microsoft Entra ID を使用した OAuth 2.0 を有効にする」を参照してください。

アクセス キーを再生成する

セキュリティを維持し、ロジック アプリ ワークフローへのアクセスを保護するには、セキュリティ ポリシーに準拠する必要がある場合や、セキュリティが侵害された可能性がある場合に備えて、定期的にアクセス キーを再生成するようにしてください。 これにより、承認されたリクエストのみがワークフローを起動できるようになり、データとプロセスを不正アクセスから保護することができます。

新しいアクセス キーを随時生成するには、Azure REST API または Azure portal を使用します。 過去に生成された URL や古いキーを使用する URI はすべて無効になり、それを使用したロジック アプリ ワークフローのトリガーは承認されなくなります。 再生成後に取得する URI は、新しいアクセス キーで署名されます。

  1. Azure portal で、再生成したいキーを使用するロジック アプリ リソースを開きます。

  2. ロジック アプリ リソース メニューの [設定] で、[アクセス キー] を選択します。

  3. 再生成したいキーを選択して、プロセスを完了します。

Important

アクセスキーを無断使用から守るのと同じように、アクセスキーを守りましょう。 侵害されたアクセス キーを取り消す計画を設定するか、その計画を立てておくようにしてください。 アクセス キーを使用する URI を配布する際には細心の注意を払い、そのような URI は HTTPS などの安全な接続でのみ配布するようにしてください。 アクセス キーを使用する操作は、HTTPS 接続上でのみ実行するようにしてください。 有効な鍵を持つURIを持つ誰でも関連するリソースにアクセスできます。

ストレージサービスにアクセスするためにSASキーを使う場合は、アカウントキーではなくMicrosoft Entra IDで保護されたユーザー委任SASを作成しましょう。

セキュリティを最適化するには、可能な場合は、認証に Microsoft Entra ID と マネージド ID を使用してください。 このオプションは認証情報を必要としない優れたセキュリティを提供します。 この ID は Azure で管理され、認証情報が安全に保たれます。この機密情報をユーザー側で管理する必要がないからです。

Azure Logic Apps のマネージド ID を設定するには、「Azure Logic Apps で マネージド ID を使用して Azure リソースへのアクセスと接続を認証する」を参照してください。

有効期限付きのコールバック URL を作成する

要求ベースのトリガーのエンドポイント URL を他のパーティと共有する場合は、特定のキーを使用する有効期限付きのコールバック URL を生成できます。 この方法を使うことで、キーをシームレスにロールしたり、特定の時間間に基づいてロジックアプリのトリガーを制限したりできます。 URL の有効期限を指定するには、Azure Logic Apps REST API を使用します。その例を次に示します。

POST /subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01

本文には、JSON 日付文字列を使用して NotAfter プロパティを含めます。 このプロパティは、NotAfter の日付と時刻までに限って有効なコールバック URL を返します。

プライマリまたはセカンダリの秘密鍵を使用して URL を作成する

要求ベースのトリガーに対するコールバック URL を生成または一覧表示する場合、URL の署名に使用するキーを指定することができます。 特定のキーで署名された URL を生成するには、Azure Logic Apps REST API を使用します。その例を次に示します。

POST /subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01

本文では、KeyType プロパティに Primary または Secondary を指定します。 このプロパティは、指定されたセキュリティ キーによって署名された URL を返します。

Azure API Management でロジック アプリ ワークフローを公開する

より多くの認証プロトコルとオプションを利用するには、Azure API Management を使用してロジック アプリ ワークフローを API として公開することを検討します。 このサービスは、任意のエンドポイントに対して、豊富な監視、セキュリティ、ポリシー、ドキュメント機能を提供します。 API Management では、ロジック アプリ用にパブリック エンドポイントまたはプライベート エンドポイントを公開できます。 このエンドポイントへのアクセスを認可するには、Microsoft Entra ID を使用した OAuth、クライアント証明書、またはその他のセキュリティ標準を使用できます。 API Management が要求を受け取ると、サービスによって要求がお客様のロジック アプリに送信され、その過程で、必要な変換または制限が行われます。 API Management のみにロジック アプリ ワークフローの呼び出しを許可するには、ロジック アプリの受信 IP アドレスを制限します。

詳細については、以下を参照してください:

受信 IP アドレスの制限

Shared Access Signature (SAS) と共に、ロジック アプリ ワークフローを呼び出すことができるクライアントを明確に制限したい場合があります。 たとえば、Azure API Management を使用して要求エンドポイントを管理する場合は、作成した API Management サービス インスタンスの IP アドレスからの要求のみを受け入れるようお使いのロジック アプリ ワークフローを制限できます。

指定する IP アドレスに関わらず、ワークフロー トリガー - Run 操作要求または API Management を使用することで、要求ベースのトリガーがあるロジック アプリ ワークフローを引き続き実行できます。 ただし、このシナリオでも Azure REST API に対する認証が必要です。 すべてのイベントが Azure の監査ログに表示されます。 アクセス制御ポリシーを適切に設定するようにしてください。

ロジック アプリ ワークフローの受信 IP アドレスを制限するには、Azure portal または Azure Resource Manager テンプレートに対応する手順を実行します。 有効なIP範囲では以下のフォーマットが使われます:x.x.x.x/x または x.x.x.x-x.x.x.x.x。

Azure portal では、ポータルの [許可された着信 IP アドレス] の説明とは対称的に、IP アドレスの制限は、トリガー "と" アクションの両方に影響します。 トリガー用とアクション用に分けてこのフィルターを設定するには、ロジック アプリ リソースの Azure Resource Manager テンプレートで accessControl オブジェクトを使用するか、Azure Logic Apps REST API でワークフロー - Create または Update 操作を使用します。

消費ワークフロー

  1. Azure portal で、従量課金ロジック アプリとワークフローをデザイナーで開きます。

  2. Logicアプリのサイドバーで、 設定の下から ワークフロー設定を選択してください。

  3. [アクセス制御の構成] セクションの [許可された着信 IP アドレス] で、シナリオのパスを選択します。

    • Azure Logic Apps の組み込みアクションを使用してワークフローを呼び出し可能にするには、ただし入れ子になったワークフローとしてのみ使用する場合は、Only other Logic Apps を選択します。 このオプションは、Azure Logic Apps アクションを使用して入れ子になったワークフローを呼び出す場合に "のみ" 機能します。

      このオプションを使用すると、ロジック アプリのリソースに空の配列が書き込まれ、組み込みの Azure Logic Apps アクションが使用されている親ワークフローからの呼び出しでのみ、入れ子になったワークフローをトリガーできるように要求できます。

    • HTTP アクションを使用してワークフローをネストされたワークフローとしてのみ呼び出せるようにするには、Specific IP ranges を選択してください。 [トリガーの IP 範囲] ボックスが表示されたら、親ワークフローの送信 IP アドレスを入力します。 有効なIP範囲では以下のフォーマットが使われます:x.x.x.x/x または x.x.x.x-x.x.x.x.x。

      Note

      [他のロジック アプリのみ] オプションと HTTP アクションを使用して入れ子になったワークフローを呼び出すと、呼び出しはブロックされ、"401 未承認" エラーが発生します。

    • 他の IP からの着信呼び出しを制限するシナリオでは、[トリガーの IP 範囲] ボックスが表示されたら、トリガーで使用できる IP アドレス範囲を指定します。 有効なIP範囲では以下のフォーマットが使われます:x.x.x.x/x または x.x.x.x-x.x.x.x.x。

  4. オプションとして、「 実行履歴から入力・出力メッセージを指定されたIPアドレスに割り当てるための通話を制限する」で、実行履歴の入力・出力メッセージにアクセスできる受信通話のIPアドレス範囲を指定します。

標準的な作業工程

  1. Azure portal で、Standard ロジック アプリ リソースを開きます。

  2. Logicアプリのサイドバーで設定の「Networking」を選択してください。

  3. [着信トラフィックの構成] セクションで、[パブリック ネットワーク アクセス] の横にある [アクセス制限なしで有効] を選択します。

  4. [アクセス制限] ページの [アプリ アクセス] で、[選択した仮想ネットワークと IP アドレスから有効] を選択します。

  5. [サイトのアクセスとルール] の下にある [メイン サイト] タブで、特定の IP 範囲からの [許可] または [拒否] リクエストに対して 1 つまたは複数のルールを追加します。 有効なIP範囲では以下のフォーマットが使われます:x.x.x.x/x または x.x.x.x-x.x.x.x.x。

    詳細については、Azure Logic Apps (Standard) での受信 IP アドレスのブロックに関するページを参照してください。

他のサービスやシステムへの送信呼び出しへのアクセス

ターゲットエンドポイントの能力に基づき、 HTTPトリガーまたはHTTPアクション によって送信されるアウトバウンドコールは暗号化をサポートし、トランス ポート層セキュリティ(TLS)1.0、1.1、1.2、または1.3(以前はセキュアソケット層(SSL)として知られていた)で保護されています。 Azure Logic Apps は、サポートされている可能な限り最高のバージョンを使用して、ターゲット エンドポイントとネゴシエートします。 たとえば、ターゲット エンドポイントが 1.3 をサポートしている場合、HTTP トリガーまたはアクションでは最初に 1.3 が使用されます。 それ以外の場合、コネクタは、2 番目に高いサポート バージョンを使用します。

このリストには、TLS/SSL 自己署名証明書に関する情報が含まれます。

  • マルチテナント Azure Logic Apps 環境内の従量課金ロジック アプリ ワークフローの場合、HTTP 操作で自己署名の TLS/SSL 証明書は許可されません。 ロジック アプリがサーバーに対して HTTP 呼び出しを行い、TLS/SSL 自己署名証明書を提示すると、TrustFailure エラーが発生して HTTP 呼び出しは失敗します。

  • シングルテナント Azure Logic Apps 環境内の Standard ロジック アプリ ワークフローの場合、HTTP 操作は自己署名の TLS/SSL 証明書をサポートします。 ただし、この認証の種類に対して追加の手順をいくつか完了する必要があります。 それ以外の場合、呼び出しは失敗します。 詳しくは、シングルテナント Azure Logic Apps 用の TLS/SSL 証明書の認証に関するページをご覧ください。

    代わりに、クライアント証明書、または資格情報の種類が Certificate である Microsoft Entra ID を使用した OAuth を使う場合でも、この認証の種類に対して追加の手順をいくつか完了する必要があります。 それ以外の場合、呼び出しは失敗します。 詳細については、シングルテナント Azure Logic Apps 用のクライアント証明書または資格情報の種類が "Certificate" である Microsoft Entra ID を使用した OAuth に関するページを参照してください。

ロジック アプリ ワークフローから送信された呼び出しを処理するエンドポイントに対するセキュリティ保護を容易にするには、他に次の方法があります。

  • 送信要求に認証を追加します。

    HTTP トリガーまたはアクションを使用して送信呼び出しを送信する場合は、ロジック アプリによって送信される要求への認証を追加できます。 たとえば、次の認証の種類を選択できます。

  • ロジック アプリ ワークフローの IP アドレスからのアクセスを制限する。

    ロジック アプリ ワークフローからエンドポイントへの呼び出しはすべて、ロジック アプリのリージョンに基づいて指定される特定の IP アドレスが起点となります。 これらの IP アドレスからのみ要求を受け入れるフィルターを追加できます。 これらの IP アドレスを取得するには、Azure Logic Apps の制限と構成に関するページを参照してください。

  • オンプレミス システムへの接続のセキュリティを強化する。

    Azure Logic Apps では、以下のサービスとの統合を行って、より安全で信頼性の高いオンプレミス通信を実現できます。

    • オンプレミス データ ゲートウェイ。

      Azure Logic Apps の多くのマネージド コネクタでは、オンプレミス システム (ファイル システム、SQL、SharePoint、DB2 など) への安全な接続が促進されます。 ゲートウェイは、オンプレミスのソースから、Azure Service Bus 経由の暗号化されたチャネルでデータを送信します。 すべてのトラフィックは、ゲートウェイ エージェントからのセキュリティで保護された送信トラフィックとして生成されます。 オンプレミス データ ゲートウェイのしくみを確認してください。

    • Azure API Managementを通じて接続してください。

      Azure API Management には、オンプレミス システムへのプロキシと通信のセキュリティ保護を実現するためのサイト間仮想プライベート ネットワークと ExpressRoute の統合など、オンプレミス接続オプションが用意されています。 オンプレミスのシステムへのアクセスを提供する API があり、API Management サービス インスタンスを作成することでその API を公開した場合は、ワークフロー デザイナーで対応する API Management 操作を選択することにより、ロジック アプリのワークフロー内からその API を呼び出すことができます。

      Note

      コネクタには、ユーザーが表示と接続のアクセス許可を持っている API Management サービスのみが表示され、消費量ベースの API Management サービスは表示されません。

      ロジック アプリのリソースの種類に基づいて、対応する手順を実施します。

      従量課金ワークフロー

      1. API Management のトリガーまたはアクションを追加するかどうかに基づいて、次の手順に従います。

        • トリガー:一般的な手順に従って「Choose an Azure API Management Trigger」という名前のトリガーを追加します。

        • アクション:一般的な手順に従って「Choose an Azure API Management action」というアクションを追加してください。

      2. API Management サービス インスタンスの一覧から、以前に作成した API Management サービス インスタンスを選択します。

      3. API 操作の一覧から、呼び出す API 操作を選択し、[アクションの追加] を選択します。

      Standard ワークフロー

      Standard ワークフローでは、トリガーではなく、API Management アクションのみを追加できます。

      1. ワークフローデザイナーで、一般的な手順に従って「Call an Azure API Management API」というアクションを追加します。

      2. API Management サービス インスタンスの一覧から、以前に作成した API Management サービス インスタンスを選択します。

      3. API 操作の一覧から、呼び出す API 操作を選択し、[新規作成] を選択します。

        Azureポータル、標準ワークフローデザイナー、そして呼び出すAPIを選択しているスクリーンショットです。

送信呼び出しに認証を追加する

HTTP および HTTPS エンドポイントでは、さまざまな種類の認証がサポートされています。 これらのエンドポイントへの送信呼び出しまたは要求の送信に使用するトリガーとアクションによっては、認証の種類を指定できます。 ワークフロー デザイナーでは、認証の種類の選択がサポートされているトリガーとアクションには、[認証] プロパティがあります。 ただし、このプロパティが既定で常に表示されるとは限りません。 このような場合は、トリガーまたはアクションで [高度なパラメーター] の一覧を開き、[認証] を選択します。

Important

ロジック アプリ ワークフローで処理される機密情報を保護するには、セキュリティで保護されたパラメーターを使用し、必要に応じてデータをエンコードします。 パラメーターの使用とセキュリティ保護の詳細については、「パラメーターの入力へのアクセス」を参照してください。

セキュリティを最適化するには、可能な場合は、認証に Microsoft Entra ID と マネージド ID を使用してください。 このオプションは認証情報を必要としない優れたセキュリティを提供します。 この ID は Azure で管理され、認証情報が安全に保たれます。この機密情報をユーザー側で管理する必要がないからです。

Azure Logic Apps のマネージド ID を設定するには、「Azure Logic Apps で マネージド ID を使用して Azure リソースへのアクセスと接続を認証する」を参照してください。

基本認証

HTTP 呼び出しの場合、基本認証では、要求を行うためにユーザー名とパスワードを含む base64 でエンコードされた文字列が使用されます。 この方法では、暗号化なしで資格情報が送信され、HTTPS/SSL プロトコルでこのオプションを使用していない限り、セキュリティ リスクが高まります。

Important

セキュリティを最適化するには、可能な場合は、認証に Microsoft Entra ID と マネージド ID を使用してください。 このオプションは認証情報を必要としない優れたセキュリティを提供します。 この ID は Azure で管理され、認証情報が安全に保たれます。この機密情報をユーザー側で管理する必要がないからです。

Azure Logic Apps のマネージド ID を設定するには、「Azure Logic Apps で マネージド ID を使用して Azure リソースへのアクセスと接続を認証する」を参照してください。

[基本] オプションを使用できる場合は選択し、次のプロパティ値を指定します。

プロパティ (デザイナー) プロパティ (JSON) 必須 価値 説明
Authentication type Yes Basic 使用する認証の種類
ユーザー名 username Yes < ユーザー名> ターゲット サービス エンドポイントへのアクセスを認証するためのユーザー名
パスワード password Yes < パスワード> ターゲット サービス エンドポイントへのアクセスを認証するためのパスワード

たとえば、デプロイを自動化するための Azure Resource Manager テンプレートで、セキュリティ保護されたパラメーターを使用して機密情報を処理および保護する場合は、式を使用して実行時にこれらのパラメーター値にアクセスできます。 次の例の HTTP アクション定義では、認証の type として Basic が指定され、パラメーター値を取得するために parameters() 関数が使用されています。

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "Basic",
         "username": "@parameters('userNameParam')",
         "password": "@parameters('passwordParam')"
      }
  },
  "runAfter": {}
}

クライアント証明書の認証

クライアント証明書認証では、アプリケーションとブラウザー サインイン用に Microsoft Entra ID に対して X.509 証明書を使用して直接認証することがユーザーに許可または要求されます。 この機能により、フィッシングに強い認証を採用し、公開鍵基盤(PKI)に対してX.509証明書で認証できます。

Important

セキュリティを最適化するには、可能な場合は、認証に Microsoft Entra ID と マネージド ID を使用してください。 このオプションは認証情報を必要としない優れたセキュリティを提供します。 この ID は Azure で管理され、認証情報が安全に保たれます。この機密情報をユーザー側で管理する必要がないからです。

Azure Logic Apps のマネージド ID を設定するには、「Azure Logic Apps で マネージド ID を使用して Azure リソースへのアクセスと接続を認証する」を参照してください。

[クライアント証明書] オプションを使用できる場合は選択し、次のプロパティ値を指定します。

プロパティ (デザイナー) プロパティ (JSON) 必須 価値 説明
Authentication type Yes クライアント証明書
または
ClientCertificate		 使用する認証タイプ。 Azure API Management で証明書を管理できます。

注: カスタム コネクタでは、受信と送信のどちらの呼び出しについても、証明書ベースの認証はサポートされていません。
Pfx pfx Yes < エンコードされたPFXファイルの内容> Base64 でエンコードされた Personal Information Exchange (PFX) ファイルのコンテンツ

PFX ファイルを Base64 でエンコードされた形式に変換するには、次の手順に従って PowerShell 7 を使用します。

1. 証明書の内容を変数に保存します。

$pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx')

2.ToBase64String() 関数を使用して証明書の内容を変換し、その内容をテキスト ファイルに保存します。

[System.Convert]::ToBase64String($pfx_cert) | Out-File 'pfx-encoded-bytes.txt'

トラブルシューティング: cert mmc/PowerShell コマンドを使用すると、次のエラーが表示される場合があります。

Could not load the certificate private key. Please check the authentication certificate password is correct and try again.

このエラーを解決するには、openssl コマンドを使用して PFX ファイルを PEM ファイルに変換し、それからもう一度元に戻します。

openssl pkcs12 -in certificate.pfx -out certificate.pem
openssl pkcs12 -in certificate.pem -export -out certificate2.pfx

その後は、証明書の新しく変換された PFX ファイルに対して base64 でエンコードされた文字列を取得すると、文字列は Azure Logic Apps で機能するようになります。
パスワード password No < パスワード・フォー・PFX-ファイル> PFX ファイルにアクセスするためのパスワード

Note

OpenSSLを使ってクライアント証明書で認証しようとすると、以下のエラーが出ることがあります:

BadRequest: Could not load private key

このエラーを解決するには、次の手順のようにします。

  1. すべての OpenSSL インスタンスをアンインストールします。
  2. OpenSSL バージョン 1.1.1t をインストールします。
  3. 新しいアップデートを使って証明書を辞約してください。
  4. クライアント証明書認証を使用する場合は、新しい証明書を HTTP 操作に追加します。

たとえば、デプロイを自動化するための Azure Resource Manager テンプレートで、セキュリティ保護されたパラメーターを使用して機密情報を処理および保護する場合は、式を使用して実行時にこれらのパラメーター値にアクセスできます。 次の例の HTTP アクション定義では、認証の type として ClientCertificate が指定され、パラメーター値を取得するために parameters() 関数が使用されています。

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ClientCertificate",
         "pfx": "@parameters('pfxParam')",
         "password": "@parameters('passwordParam')"
      }
   },
   "runAfter": {}
}

Important

シングルテナントAzure Logic Appsの標準論理アプリリソースがあり、TLS/SSL証明書、クライアント証明書、またはCertificate認証タイプのMicrosoft Entra ID OAuthでHTTP操作を使いたい場合は、この認証タイプの追加設定を必ず完了してください。 それ以外の場合、呼び出しは失敗します。 詳細については、「シングルテナント環境での認証」をご覧ください。

クライアント証明書認証によるサービスの安全性についての詳細は、以下をご覧ください:

Active Directory OAuth (OAuth 2.0 with Microsoft Entra ID) 認証

Request トリガーでは、ロジック アプリに Microsoft Entra 承認ポリシーを設定した後に、Microsoft Entra プラットフォームを使用して受信呼び出しを認証できます。

Important

セキュリティを最適化するには、可能な場合は、認証に Microsoft Entra ID と マネージド ID を使用してください。 このオプションは認証情報を必要としない優れたセキュリティを提供します。 この ID は Azure で管理され、認証情報が安全に保たれます。この機密情報をユーザー側で管理する必要がないからです。

Azure Logic Apps のマネージド ID を設定するには、「Azure Logic Apps で マネージド ID を使用して Azure リソースへのアクセスと接続を認証する」を参照してください。

Active Directory OAuth (Microsoft Entra ID を使用した OAuth 2.0) 認証の種類をサポートする他のすべてのトリガーとアクションで、次のプロパティ値を指定します。

プロパティ (デザイナー) プロパティ (JSON) 必須 価値 説明
Authentication type Yes Active Directory OAuth (Microsoft Entra ID を使用した OAuth 2.0)
または
ActiveDirectoryOAuth		 使用する認証タイプ。 現在、Azure Logic Apps では OAuth 2.0 プロトコルが使用されています。
機関 authority No < 認証トークン発行者のURL> アクセス キーを提供する機関の URL (例: Azure グローバル サービス リージョンの https://login.microsoftonline.com/)。 その他の各国クラウドについては、Microsoft Entra 認証エンドポイント - ID 機関の選択に関するページを確認してください。
テナント tenant Yes < テナントID (tenant-ID)> Microsoft Entra テナントのテナント ID
オーディエンス audience Yes < 認証するリソース> 承認で使用するリソース (https://management.core.windows.net/ など)
クライアント ID clientId Yes < クライアント ID> 承認を要求しているアプリのクライアント ID
資格情報の種類 credentialType Yes Certificate
または
Secret		 承認を要求するためにクライアントで使用される資格情報の種類。 このプロパティと値はロジック アプリの基になっている定義には出現しませんが、選択した資格情報の種類に対して表示されるプロパティがそれによって決まります。
シークレット secret はい (ただし資格情報の種類が "Secret" の場合のみ) < クライアントシークレット> 承認を要求しているクライアント シークレット
Pfx pfx はい (ただし資格情報の種類が "Certificate" の場合のみ) < エンコードされたPFXファイルの内容> Base64 でエンコードされた Personal Information Exchange (PFX) ファイルのコンテンツ
パスワード password はい (ただし資格情報の種類が "Certificate" の場合のみ) < パスワード・フォー・PFX-ファイル> PFX ファイルにアクセスするためのパスワード

たとえば、デプロイを自動化するための Azure Resource Manager テンプレートで、セキュリティ保護されたパラメーターを使用して機密情報を処理および保護する場合は、式を使用して実行時にこれらのパラメーター値にアクセスできます。 次の例の HTTP アクション定義では、認証の type として ActiveDirectoryOAuth、資格情報の種類として Secret が指定されており、パラメーター値を取得するために parameters() 関数が使用されています。

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ActiveDirectoryOAuth",
         "tenant": "@parameters('tenantIdParam')",
         "audience": "https://management.core.windows.net/",
         "clientId": "@parameters('clientIdParam')",
         "credentialType": "Secret",
         "secret": "@parameters('secretParam')"
     }
   },
   "runAfter": {}
}

Important

シングルテナントAzure Logic Appsの標準論理アプリリソースがあり、TLS/SSL証明書、クライアント証明書、またはCertificate認証タイプのMicrosoft Entra ID OAuthでHTTP操作を使いたい場合は、この認証タイプの追加設定を必ず完了してください。 それ以外の場合、呼び出しは失敗します。 詳細については、「シングルテナント環境での認証」をご覧ください。

Raw 認証

RAWオプションがあるなら、OAuth 2.0プロトコルに準拠しない認証方式を使う必要がある場合はこの認証タイプを使いましょう。 この種類では、送信要求で送信する Authorization ヘッダーの値を手動で作成し、トリガーまたはアクションでそのヘッダー値を指定します。

Important

セキュリティを最適化するには、可能な場合は、認証に Microsoft Entra ID と マネージド ID を使用してください。 このオプションは認証情報を必要としない優れたセキュリティを提供します。 この ID は Azure で管理され、認証情報が安全に保たれます。この機密情報をユーザー側で管理する必要がないからです。

Azure Logic Apps のマネージド ID を設定するには、「Azure Logic Apps で マネージド ID を使用して Azure リソースへのアクセスと接続を認証する」を参照してください。

次の例は、OAuth 1.0 プロトコルに従う HTTPS 要求のサンプル ヘッダーを示しています。

Authorization: OAuth realm="Photos",
   oauth_consumer_key="dpf43f3p2l4k3l03",
   oauth_signature_method="HMAC-SHA1",
   oauth_timestamp="137131200",
   oauth_nonce="wIjqoS",
   oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
   oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"

Raw 認証をサポートするトリガーまたはアクションでは、次のプロパティ値を指定します。

プロパティ (デザイナー) プロパティ (JSON) 必須 価値 説明
Authentication type Yes 未加工 使用する認証の種類
Value value Yes < 認可ヘッダー値> 認証に使用する Authorization ヘッダーの値

Azure Resource Managerのテンプレートのように、デプロイの自動化に使われたセキュアパラメータを扱い、機密情報を管理・保護する場合、実行時に式を使ってこれらのパラメータ値にアクセスできます。 次の例の HTTP アクション定義では、認証の type として Raw が指定され、パラメーター値を取得するために parameters() 関数が使用されています。

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "Raw",
         "value": "@parameters('authHeaderParam')"
      }
   },
   "runAfter": {}
}

マネージド ID 認証

マネージドID認証をサポートするトリガーやアクションでマネージドIDオプションが利用可能であれば、ロジックアプリはこのIDを使って、Microsoft Entra IDで保護されているAzureリソースへのアクセスを認証できます。認証情報やシークレット、Microsoft Entraトークンを使う必要はありません。 この ID は、ユーザーに代わって Azure が管理します。ユーザーがシークレットを管理したり、Microsoft Entra トークンを直接使用したりする必要がないため、資格情報の保護に役立ちます。 Microsoft Entra 認証用のマネージド ID がサポートされている Azure サービスの詳細を参照してください。

  • 従量課金ロジック アプリ リソースでは、システム割り当て ID または、手動で作成した "単一の" ユーザー割り当て ID を使用できます。

  • Standard ロジック アプリ リソースでは、システム割り当てマネージド ID "および" 複数のユーザー割り当てマネージド ID を同時に有効にすることができますが、いつでも使用できる ID は 1 つしか選択できません。

    Note

    既定では、実行時に接続を認証するために、システム割り当て ID は既に有効になっています。 この ID は、接続の作成時に使用する認証資格情報または接続文字列とは異なります。 このアイデンティティを無効にすると、実行時に接続が機能しません。 この設定を見るには、Logicアプリのサイドバーの 設定で 「Identity」を選択してください。

  1. ロジック アプリでマネージド ID を使用するには、その前に「Azure Logic Apps でマネージド ID を使用して認証し、リソースにアクセスする」の手順に従います。 これらの手順により、ロジック アプリでマネージド ID が有効になり、ターゲットの Azure リソースに対するその ID のアクセスが設定されます。

  2. Azure 関数でマネージド ID を使用できるようにするには、先に Azure Functions の認証を有効にします。

  3. マネージド ID の使用がサポートされているトリガーまたはアクションで、次の情報を指定します。

    組み込みのトリガーとアクション

    プロパティ (デザイナー) プロパティ (JSON) 必須 価値 説明
    Authentication type Yes マネージド ID
    または
    ManagedServiceIdentity    		 使用する認証の種類
    マネージド ID identity No < ユーザー割り当て識別ID> ユーザー割り当てマネージド ID。 注: システム割り当てマネージド ID を使用する場合は、このプロパティを含めないでください。
    オーディエンス audience Yes < target-resource-ID> アクセスするターゲット リソースのリソース ID。

    たとえば、https://storage.azure.com/ では、認証用のアクセス トークンがすべてのストレージ アカウントに対して有効になります。 ただし、特定のストレージ アカウントに対する https://fabrikamstorageaccount.blob.core.windows.net など、ルート サービスの URL を指定することもできます。

    注: 一部のトリガーまたはアクションでは、[対象ユーザー] プロパティが表示されない場合があります。 このプロパティが表示されるようにするには、トリガーまたはアクションで [高度なパラメーター] の一覧を開き、[対象ユーザー] を選択します。

    重要:このターゲットリソースIDがMicrosoft Entra IDが期待する値と正確に一致し、必要なトレーリングスラッシュも含めて確認してください。 そのため、すべての Azure Blob Storage アカウントの https://storage.azure.com/ リソース ID には、末尾のスラッシュが必要です。 ただし、特定のストレージ アカウントのリソース ID については、末尾のスラッシュは必要ありません。 これらのリソース ID を見つける方法については、Microsoft Entra ID をサポートしている Azure サービスに関するページを参照してください。

    Azure Resource Managerのテンプレートのように、デプロイの自動化に使われたセキュアパラメータを扱い、機密情報を管理・保護する場合、実行時に式を使ってこれらのパラメータ値にアクセスできます。 たとえば、この HTTP アクション定義では、認証の type が ManagedServiceIdentity と指定され、パラメーター値を取得するために parameters() 関数が使用されています。

    "HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ManagedServiceIdentity",
         "audience": "https://management.azure.com/"
      },
   },
   "runAfter": {}
}

    マネージド コネクタのトリガーおよびアクション

    プロパティ (デザイナー) 必須 価値 説明
    接続名 Yes < 接続名>
    マネージド ID Yes システムによって割り当てられた管理されたID
    または
    < ユーザー指定管理 ID 名>    		 使用する認証の種類

特定のコネクタによって作成されたブロック接続

Azure Logic Apps でコネクタを使用して特定のリソースに接続することが組織で許可されていない場合は、Azure Policy を使用して、ロジック アプリのワークフロー内の特定のコネクタについて、接続を作成する機能をブロックすることができます。 詳細については、Azure Logic Apps での特定のコネクタによって作成される接続のブロックに関するページを参照してください。

ロジック アプリの分離に関するガイダンス

隔離に関する詳細は以下の通りをご覧ください:

関連するコンテンツ

  • 最終更新: