Azure Logic Apps におけるアクセスとデータのセキュリティ保護

Azure Logic Apps では、Azure Storage を利用して、データが格納され、自動的に保存データが暗号化されます。 この暗号化によってデータが保護され、組織のセキュリティとコンプライアンスの要件を満たすことができます。 既定では、Azure Storage は Microsoft マネージド キーを使用してデータを暗号化します。 詳細については、「保存データ向け Azure Storage の暗号化」を参照してください。

Azure Logic Apps 内の機密データへのアクセスをさらに制御し保護するために、次の領域のセキュリティを高めて設定できます。

Azure でのセキュリティの詳細については、次のトピックを参照してください。

ロジック アプリの操作へのアクセス

従量課金ロジック アプリの場合のみ、ロジック アプリとその接続を作成または管理する前に、Azure ロールベースのアクセス制御 (Azure RBAC) を使用してロールを通じて提供される特定のアクセス許可が必要です。 また、特定のユーザーまたはグループだけがロジック アプリの管理、編集、表示などの特定のタスクを実行できるよう、アクセス許可の設定もできます。 アクセス許可を制御するため、Azure サブスクリプションへのアクセス権を持つメンバーに、組み込みまたはカスタムのロールを割り当てることができます。 Azure Logic Apps には、従量課金ロジック アプリ ワークフローまたは Standard ロジック アプリ ワークフローのどちらを使用しているかに応じて、次の特定のロールがあります:

従量課金ワークフロー
ロール 説明
Logic App Contributor ロジック アプリのワークフローは管理できますが、それらに対するアクセスを変更することはできません。
Logic App Operator ロジック アプリのワークフローの読み取り、有効化、無効化ができますが、編集または更新はできません。
Contributor すべてのリソースを管理するためのフル アクセス権がありますが、Azure RBAC でロールを割り当てたり、Azure Blueprints で割り当てを管理したり、イメージ ギャラリーを共有したりすることはできません。

たとえば、自分で作成していないロジック アプリのワークフローを使用し、そのロジック アプリのワークフローで使用する接続を認証する必要がある場合を考えてください。 Azure サブスクリプションでは、そのロジック アプリ リソースが存在するリソース グループに対する共同作成者権限が必要です。 ロジック アプリを自分で作成した場合は、自動的に共同作成者権限が得られます。

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

Standard ワークフロー

Note

この機能はプレビュー段階にあり、「Microsoft Azure プレビューの追加使用条件」が適用されます。

ロール 説明
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 の形式が使用されます。

許可される IP 範囲を指定するには、Azure portal または Azure Resource Manager テンプレートに対して、次の手順を実行します。

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

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

  3. [アクセス制御の構成]>[許可された着信 IP アドレス] で、[特定の IP 範囲] を選択します。

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

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

  2. ロジック アプリのメニューの [設定] で、[ネットワーク] を選択します。

  3. [受信トラフィック] セクションで [アクセス制限] を選択します。

  4. 特定の IP 範囲からの 許可 または 拒否 要求に対して 1 つ以上のルールを作成します。 HTTP ヘッダーのフィルター設定と転送設定を使用することもできます。

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

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

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

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

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

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

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

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

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

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

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

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

    Secured outputs as inputs and downstream impact on most actions

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

    Secured outputs as inputs with downstream impact on specific actions

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

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

    Secured inputs and downstream impact on most actions

    セキュリティで保護された入力を持つトリガーまたはアクションからの表示可能な出力が、[作成]、[JSON の解析]、[応答] の各アクションで明示的に使用された場合、Azure Logic Apps はこれらのアクションの入力と出力を非表示にしますが、そのアクションの [セキュリティで保護された入力] の設定は 有効にしません。 [作成]、[JSON の解析]、[応答] のいずれかのアクションからの非表示の出力がダウンストリームのアクションで明示的に入力として使用された場合、Azure Logic Apps は、このダウンストリームのアクションの入力と出力を非表示にしません

    Secured inputs and downstream impact on specific actions

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

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

  2. ロジック アプリのリソースの種類に基づいて、機密データをセキュリティで保護するトリガーまたはアクションに関する次の手順に従います。

    従量課金ワークフロー

    トリガーまたはアクションの右上隅の省略記号ボタン (...) を選択し、[設定] を選択します。

    Screenshot shows Azure portal, Consumption workflow designer, and trigger or action with opened settings.

    Standard ワークフロー

    デザイナーで、トリガーまたはアクションを選択して情報ペインを開きます。 [設定] タブで [セキュリティ] を展開します。

    Screenshot shows Azure portal, Standard workflow designer, and trigger or action with opened settings.

  3. [セキュリティで保護された入力][セキュリティで保護された出力] のいずれかまたは両方をオンにします。 従量課金ワークフローでは、必ず [完了] を選択します。

    従量課金ワークフロー

    Screenshot shows Consumption workflow with an action's Secure Inputs or Secure Outputs settings enabled.

    トリガーまたはアクションのタイトル バーにロック アイコンが表示されます。

    Screenshot shows Consumption workflow and an action's title bar with lock icon.

    Standard ワークフロー

    Screenshot shows Standard workflow with an action's Secure Inputs or Secure Outputs settings enabled.

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

    従量課金ワークフロー

    Screenshot shows Consumption workflow with a subsequent action's dynamic content list open, and the previous action's token for secured output with lock icon.

    Standard ワークフロー

    Screenshot shows Standard workflow with a subsequent action's dynamic content list open, and the previous action's token for secured output with lock icon.

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

    従量課金ワークフロー

    1. ロジック アプリのメニューで、 [概要] を選択します。 [実行履歴] で、表示したい実行を選択します。

    2. [ロジック アプリの実行] ウィンドウで、確認したいアクションを展開して選択します。

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

      Screenshot shows Consumption workflow run history view with hidden inputs and outputs.

    Standard ワークフロー

    1. ワークフロー メニューで、 [概要] を選択します。 [実行履歴] で、表示したい実行を選択します。

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

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

      Screenshot shows Standard workflow run history view with hidden inputs and outputs.

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

基になるトリガーまたはアクションの定義で、次の値のいずれかまたは両方を含んだ 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>') 式を使用します。 この式は実行時にのみ評価され、ワークフロー定義言語で記述されます。

注意

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

詳細については、このトピックの以下のセクションをご覧ください。

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

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

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

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

"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 を使用して機密性の値を渡す方法に関する記事を参照してください。

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

  • テンプレートの最上位の 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": {}
}

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

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

認証の種類 ロジック アプリとサポートされているコネクタ
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 - 従量課金: 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
Raw 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

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

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

注意

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

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

Shared Access Signature (SAS) の生成

ロジック アプリの各要求エンドポイントでは、エンドポイントの URL に次の形式で Shared Access Signature (SAS) を含みます。

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

次の表で説明するように、各 URL にはクエリ パラメーター spsvsig が含まれています。

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

要求エンドポイントへの受信呼び出しでは、SAS または Microsoft Entra ID を使用した OAuth のいずれか 1 つの認可スキームのみを使用できます。 1 つのスキームを使用しても他方のスキームは無効にされませんが、両方のスキームを同時に使用すると、どちらのスキームを選択するかサービスでは不明なため、エラーが発生します。

SAS によるアクセスのセキュリティ保護の詳細については、このトピック内の次の各セクションを参照してください。

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

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

  1. Azure portal で、再生成したいキーを備えたロジック アプリを開きます。

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

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

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

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

POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-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 を生成するには、Logic Apps REST API を使用します。その例を次に示します。

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

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

Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) の有効化

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

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

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

Microsoft Entra ID OAuth を有効にする前の考慮事項

  • 要求エンドポイントへの受信呼び出しでは、Microsoft Entra ID を使用した OAuth または Shared Access Signature (SAS) のいずれか 1 つの認可スキームのみを使用できます。 1 つのスキームを使用しても他方のスキームは無効にされませんが、両方のスキームを同時に使用すると、どちらのスキームを選択するか Azure Logic Apps では不明なため、エラーが発生します。

  • 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) のいずれかで始まります。

    たとえば、ロジック アプリ リソースに、対象ユーザー発行者という 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": "72f988bf-86f1-41af-91ab-2d7cd011db47",
        "unique_name": "SophiaOwen@fabrikam.com",
        "upn": "SophiaOwen@fabrikam.com",
        "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
        "ver": "1.0"
    }
    

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

  1. 要求または HTTP Webhook のトリガー出力に 'Authorization' ヘッダーを含める手順に従うことで、OAuth アクセス トークンをチェックする機能を使用して、要求または HTTP Webhook のトリガーを設定します。

    Note

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

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

  3. トリガーの右上隅の省略記号ボタン (...) を選択し、[設定] を選択します。

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

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

    または

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

適切な承認を行わずにトリガー エンドポイントを呼び出すと、トリガーの条件に失敗したというメッセージが表示されずに、実行履歴にトリガーが Skipped として表示されます。

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

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

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

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

Azure portal または Azure Resource Manager テンプレートについて、次の手順を実行します。

Azure portal で、ロジック アプリに 1 つ以上の承認ポリシーを追加します。

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

  2. ロジック アプリのメニューの [設定] で、 [認証] を選択します。 承認ウィンドウが開いたら、 [ポリシーの追加] を選択します。

    Screenshot that shows Azure portal, Consumption logic app menu, Authorization page, and selected button to add policy.

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

    Screenshot that shows Azure portal, Consumption logic app Authorization page, and information for authorization policy.

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

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

    - 発行者
    - 対象者
    - 情報カテゴリ
    - JWT ID (JSON Web Token ID)

    要件:

    - クレームの一覧には、少なくとも発行者のクレームが含まれている必要があります。その Microsoft Entra 発行者 ID の値は、https://sts.windows.net/ または https://login.microsoftonline.com/ で始まります。

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

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

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

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

    Screenshot that shows Azure portal, Consumption logic app Authorization page, and information for a proof-of-possession policy.

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

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

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

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

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

  7. 要求ベースのトリガー出力にアクセス トークンの 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"
   }
}

詳細については、次のトピックをご覧ください。

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 アドレスに関わらず、Logic Apps REST API: Workflow Triggers - 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 の形式が使用されます。

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

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

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

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

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

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

    • 入れ子になったワークフローとしてのみ、HTTP アクションを使用してワークフローを呼び出し可能にするには、[特定の IP 範囲] を選択します。 [トリガーの IP 範囲] ボックスが表示されたら、親ワークフローの送信 IP アドレスを入力します。 有効な IP 範囲では、x.x.x.x/x または x.x.x.x-x.x.x.x の形式が使用されます。

      注意

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

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

  4. 必要に応じて、 [Restrict calls to get input and output messages from run history to the provided IP addresses](実行履歴からの入力と出力メッセージを取得するための呼び出しを指定した IP アドレスに制限する) で、実行履歴の入力メッセージと出力メッセージにアクセスできる着信呼び出しの IP アドレス範囲を指定できます。

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

  2. ロジック アプリのメニューの [設定] で、[ネットワーク] を選択します。

  3. [受信トラフィック] セクションで [アクセス制限] を選択します。

  4. 特定の IP 範囲からの 許可 または 拒否 要求に対して 1 つ以上のルールを作成します。 HTTP ヘッダーのフィルター設定と転送設定を使用することもできます。 有効な IP 範囲では、x.x.x.x/x または x.x.x.x-x.x.x.x の形式が使用されます。

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

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

ターゲット エンドポイントの機能に基づき、HTTP トリガーまたは HTTP アクションによって送信される送信呼び出しにより、暗号化がサポートされ、以前は Secure Sockets Layer (SSL) と呼ばれていた トランスポート層セキュリティ (TLS) 1.0、1.1、または 1.2 によってセキュリティ保護されます。 Azure Logic Apps は、サポートされている可能な限り最高のバージョンを使用して、ターゲット エンドポイントとネゴシエートします。 たとえば、ターゲット エンドポイントで 1.2 がサポートされている場合、HTTP トリガーまたはアクションで最初に使用されるのは 1.2 となります。 それ以外の場合、コネクタは、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 を呼び出すことができます。

      注意

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

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

      従量課金ワークフロー

      1. ワークフロー デザイナーの検索ボックスの下で、[組み込み] を選択します。 検索ボックスで、「API Management」という名前の組み込みコネクタを探します。

      2. トリガーとアクションのどちらを追加するかに基づいて、次の操作を選択します。

        • トリガー: [Choose an Azure API Management trigger](Azure API Management トリガーを選択する) を選択します。

        • アクション: Choose an Azure API Management action(Azure API Management アクションを選択する を選択します。

        次の例では、トリガーを追加します。

        Screenshot shows Azure portal, Consumption workflow designer, and Azure API Management trigger.

      3. 前に作成した API Management サービス インスタンスを選択します。

      4. 呼び出す対象の API 操作を選択する

        Screenshot shows Azure portal, Consumption workflow designer, and selected API to call.

      Standard ワークフロー

      Standard ワークフローでは、API Management 組み込みコネクタはトリガーではなくアクションのみを提供します。

      1. ワークフロー デザイナーで、ワークフローの最後または手順の途中で、[アクションの追加] を選択します。

      2. [アクションの追加] ウィンドウが開いたら、検索ボックスの [ランタイム] の一覧から [アプリ内] を選択して、組み込みコネクタのみを表示します。 [Call an Azure API Management API](Azure API Management の呼び出し API) という名前の組み込みアクションを選択します。

        Screenshot shows Azure portal, Standard workflow designer, and Azure API Management action.

      3. 前に作成した API Management サービス インスタンスを選択します。

      4. 呼び出す API を選択する 新しく接続する場合は、[新規作成] を選択します。

        Screenshot shows Azure portal, Standard workflow designer, and selected API to call.

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

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

重要

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

[基本認証]

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

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

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

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

クライアント証明書認証

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

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

:カスタム コネクタでは、受信と送信両方の呼び出しに対して証明書ベースの認証はサポートされていません。
Pfx pfx はい <encoded-pfx-file-content> 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 いいえ <password-for-pfx-file> 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 が指定され、パラメーター値を取得するために typeが使用されています。

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

重要

シングルテナント Azure Logic Apps 内に Standard ロジック アプリ リソースがあり、TSL/SSL 証明書、クライアント証明書、または資格情報の種類が Certificate である Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) で HTTP 操作を使用する場合は、この認証の種類に対して追加のセットアップ手順を完了してください。 そうしない場合、呼び出しは失敗します。 詳細については、シングルテナント環境での認証に関するページをご覧ください。

クライアント証明書認証を使用してサービスをセキュリティ保護する方法の詳細については、次のトピックを参照してください。

Microsoft ID プラットフォーム

Request トリガーでは、Microsoft ID プラットフォームを使用 して、ロジック アプリの Microsoft Entra 認可ポリシーを設定した後に受信呼び出しを認証できます。 Active Directory OAuth の認証の種類を提供するその他のすべてのトリガーとアクションについては、次のプロパティ値を指定します。

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

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

"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": {}
}

重要

シングルテナント Azure Logic Apps 内に Standard ロジック アプリ リソースがあり、TSL/SSL 証明書、クライアント証明書、または資格情報の種類が Certificate である Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) で HTTP 操作を使用する場合は、この認証の種類に対して追加のセットアップ手順を完了してください。 そうしない場合、呼び出しは失敗します。 詳細については、シングルテナント環境での認証に関するページをご覧ください。

Raw 認証

[未加工] オプションが使用可能な場合は、OAuth 2.0 プロトコルに従っていない認証スキームを使用する必要があるときに、この認証の種類を使用できます。 この種類では、送信要求で送信する Authorization ヘッダーの値を手動で作成し、トリガーまたはアクションでそのヘッダー値を指定します。

次の例は、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) 必須 説明
認証 type はい Raw 使用する認証の種類
Value value はい <authorization-header-value> 認証に使用する Authorization ヘッダーの値

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

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

マネージド ID の認証

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

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

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

    Note

    既定では、実行時に接続を認証するために、システム割り当て ID は既に有効になっています。 この ID は、接続の作成時に使用する認証資格情報または接続文字列とは異なります。 この ID を無効にした場合、接続は実行時に機能しません。 この設定を表示するには、ロジック アプリのメニューの [設定] で、 [ID] を選択します。

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

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

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

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

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

    たとえば、https://storage.azure.com/ では、認証用の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 アクション定義では、認証の typeManagedServiceIdentity と指定され、パラメーター値を取得するために typeが使用されています。

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

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

    プロパティ (デザイナー) 必須 説明
    接続名 はい <connection-name>
    管理対象 ID はい システム割り当てマネージド ID
    または
    <user-assigned-managed-identity-name>
    使用する認証の種類

接続の作成をブロックする

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

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

Azure Government 影響レベル 5 分離ガイダンスに関するページで説明されているリージョン内でのすべての影響レベルをサポートする Azure Logic Apps を、Azure Government で使用できます。 これらの要件を満たすため、ロジック アプリで他の Azure テナントによるパフォーマンスへの影響が軽減され、コンピューティング リソースが他のテナントと共有されないよう、Azure Logic Apps では、専用リソースを持つ環境でワークフローを作成および実行する機能がサポートされています。

分離の詳細については、次のドキュメントをご確認ください。

次のステップ