次の方法で共有

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 内の従量課金または Standard のロジック アプリ用の手順、または Azure Resource Manager テンプレート用の手順に従ってください。

従量課金ワークフロー

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

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

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

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

Standard ワークフロー

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

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

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

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

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

    詳細については、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 はそのアクションの入力を実行履歴では非表示としますが、アクションの [セキュリティで保護された入力] の設定は有効にしません。

    入力としてのセキュリティで保護された出力とダウンストリームによるほとんどのアクションへの影響

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

    入力としてのセキュリティで保護された出力とダウンストリームによる特定のアクションへの影響

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

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

    セキュリティで保護された入力とダウンストリームのほとんどのアクションへの影響

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

    セキュリティで保護された入力とダウンストリームの特定のアクションへの影響

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

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

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

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

    Azure portal、ワークフロー デザイナー、[設定] が開かれたトリガーまたはアクションを示すスクリーンショット。

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

    アクションの [セキュリティで保護された入力] または [セキュリティで保護された出力] の設定が有効になっているワークフローを示すスクリーンショット。

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

    後続のアクションの動的コンテンツ リストが開いているワークフローと、ロック アイコンが表示されたセキュリティで保護された出力の前のアクションのトークンを示すスクリーンショット。

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

    1. 従量課金プランのロジック アプリ メニューまたは標準ワークフロー メニューのいずれかで [概要] を選択します。

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

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

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

      入出力が非表示になっている Standard ワークフローの [実行履歴] ビューを示すスクリーンショット。

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

基になるトリガーまたはアクションの定義で、次の値のいずれかまたは両方を含んだ 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 セクションで参照します。

重要

最適なセキュリティを確保するために、可能な場合はマネージド ID を使用した Microsoft Entra 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 を使用して機密性の値を渡す方法に関する記事を参照してください。

重要

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

このリストには、これらの 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": {}
}

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

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

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

重要

最適なセキュリティを確保するために、可能な場合はマネージド ID を使用した Microsoft Entra 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

重要

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

    たとえば、ロジック アプリ リソースに、対象ユーザーと発行者という 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. 従量課金ワークフローの場合、Request トリガーまたは HTTP Webhook トリガー出力に 'Authorization' ヘッダーを含める手順に従うことで、OAuth アクセス トークンをチェックする機能を使用して、Request トリガーまたは 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 テンプレートで次の手順に従います。

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

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

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

    Azure portal、[認可] ページ、選択された [ポリシーの追加] ボタンを示すスクリーンショット。

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

    Azure portal、[認可] ページ、承認ポリシーの詳細を示すスクリーンショット。

    プロパティ 必須 タイプ 説明
    ポリシー名 はい 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 トークンの情報を示しています。

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

  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 portal、従量課金ワークフロー デザイナー、Request トリガー エンドポイント 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 パスとプロパティで生成されます。 このキーは秘密に保たれ暗号化され、ロジック アプリと共に格納され、決して公開されることはありません。 お客様のロジック アプリでは、秘密鍵を使用して作成された有効な署名を含むそれらのトリガーのみが承認されます。

重要

SAS キーは、アカウント キーを不正使用から保護するのと同様に、必ず保護するようにしてください。 侵害されたアクセス キーを取り消す計画を設定するか、その計画を立てておくようにしてください。 アクセス キーを使用する URI を配布する際には細心の注意を払い、そのような URI は HTTPS などの安全な接続でのみ配布するようにしてください。 アクセス キーを使用する操作は、HTTPS 接続上でのみ実行するようにしてください。 有効なキーを持つ URI があれば、誰でもその関連リソースにアクセスできます。 セキュリティを維持し、ロジック アプリ ワークフローへのアクセスを保護するには、セキュリティ ポリシーに準拠する必要がある場合や、セキュリティが侵害された可能性がある場合に備えて、定期的にアクセス キーを再生成するようにしてください。 これにより、承認されたリクエストのみがワークフローを起動できるようになり、データとプロセスを不正アクセスから保護することができます。

SAS キーを使用してストレージ サービスにアクセスする場合、Microsoft では、アカウント キーではなく 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

従量課金ワークフローが Request トリガーで始まり、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

前提条件

このタスクには、REST API 呼び出しを送信するツールが必要です。次に例を示します。

注意事項

資格情報、シークレット、アクセス トークン、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 オブジェクトに、triggers オブジェクトを含む accessControl オブジェクトを追加します (存在しない場合)。

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

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

    "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. 再生成したいキーを選択して、プロセスを完了します。

重要

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

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

最適なセキュリティを確保するために、可能な場合はマネージド ID を使用した Microsoft Entra 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 の形式が使用されます。

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

従量課金ワークフロー

  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 で、Standard ロジック アプリ リソースを開きます。

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

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

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

  5. [サイトのアクセスとルール] の下にある [メイン サイト] タブで、特定の IP 範囲からの [許可] または [拒否] リクエストに対して 1 つまたは複数のルールを追加します。 有効な 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 を呼び出すことができます。

      Note

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

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

      従量課金ワークフロー

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

        • トリガー:

          1. ワークフロー デザイナーで、[トリガーの追加] を選択します。

          2. [トリガーの追加] ペインが開いたら、検索ボックスに「API Management」と入力します。

          3. トリガーの結果の一覧から、[Choose an Azure API Management Trigger]\(Azure API Management トリガーを選択する\) を選択します。

        • アクション:

          1. ワークフロー デザイナーで、アクションを追加する場所のプラス記号 (+) を選択します。

          2. [アクションの追加] ウィンドウが開いたら、検索ボックスに「API Management」と入力します。

          3. アクションの結果の一覧から、[Choose an Azure API Management action]\(Azure API Management アクションを選択する\) を選択します。

        次の例は、Azure API Management トリガーの検索を示しています。

        Azure portal、従量課金ワークフロー デザイナー、API Management トリガーの検索を示すスクリーンショット。

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

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

      Standard ワークフロー

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

      1. ワークフロー デザイナーで、アクションを追加する場所のプラス記号 (+) を選択します。

      2. [アクションの追加] ウィンドウが開いたら、検索ボックスに「API Management」と入力します。

      3. アクションの結果の一覧から、[Call an Azure API Management API]\(Azure API Management API の呼び出し\) を選択します。

        Azure portal、Standard ワークフロー デザイナー、Azure API Management アクションを示すスクリーンショット。

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

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

        Azure portal、Standard ワークフロー デザイナー、呼び出す選択された API を示すスクリーンショット。

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

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

重要

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

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

基本認証

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

重要

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

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

プロパティ (デザイナー) プロパティ (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": {}
}

クライアント証明書認証

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

重要

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

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

プロパティ (デザイナー) プロパティ (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 Entra プラットフォーム

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

重要

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

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

プロパティ (デザイナー) プロパティ (JSON) 必須 値 説明
認証 type はい Active Directory OAuth (Microsoft Entra ID を使用した OAuth 2.0)
または
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 OAuth で HTTP 操作を使用する場合は、この認証の種類に対して追加のセットアップ手順を完了してください。 そうしない場合、呼び出しは失敗します。 詳細については、「シングルテナント環境での認証」をご覧ください。

Raw 認証

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

重要

最適なセキュリティを確保するために、可能な場合はマネージド ID を使用した Microsoft Entra 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) 必須 値 説明
認証 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 アクション定義では、認証の type が ManagedServiceIdentity と指定され、パラメーター値を取得するために 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 での特定のコネクタによって作成される接続のブロックに関するページを参照してください。

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

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

関連するコンテンツ