다음을 통해 공유

Azure Logic Apps의 워크플로에 대한 보안 액세스 및 데이터

  • 아티클

Azure Logic Apps는 Azure Storage를 사용하여 자동으로 미사용 데이터를 암호화하고 저장합니다. 이 암호화는 데이터를 보호하고 조직의 보안 및 규정 준수 노력에 부합하는 데 도움이 됩니다. 기본적으로 Azure Storage는 Microsoft 관리형 키를 사용하여 데이터를 암호화합니다. 자세한 내용은 미사용 데이터에 대한 Azure Storage 암호화를 검토하세요.

Azure Logic Apps에서 액세스를 추가로 제어하고 중요한 데이터를 보호하기 위해 다음과 같은 영역에 추가적인 보안을 설정할 수 있습니다.

Azure의 보안에 대한 자세한 내용은 다음 항목을 검토하세요.

논리 앱 작업에 대한 액세스

소비 논리 앱의 경우에만 논리 앱 및 해당 연결을 만들거나 관리하려면 Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하는 역할을 통해 제공되는 특정 권한이 필요합니다. 특정 사용자 또는 그룹만 논리 앱 관리, 편집 및 보기와 같은 특정 작업을 실행할 수 있도록 권한을 설정할 수도 있습니다. 권한을 제어하려면 Azure 구독에 액세스할 수 있는 멤버에게 기본 제공 또는 사용자 지정 역할을 할당하면 됩니다. Azure Logic Apps에는 논리 앱 워크플로가 소비인지 표준인지에 따라 다음과 같은 특정 역할이 있습니다.

사용량 워크플로
역할 설명
논리 앱 기여자 논리 앱 워크플로를 관리할 수 있지만 해당 워크플로에 대한 액세스는 변경할 수 없습니다.
논리 앱 운영자 논리 앱 워크플로를 읽고 사용 및 사용하지 않도록 설정할 수는 있지만 편집하거나 업데이트할 수 없습니다.
기여자 모든 리소스를 관리할 수 있는 모든 권한이 있지만, Azure RBAC에서 역할을 할당하거나, Azure Blueprints에서 할당을 관리하거나, 이미지 갤러리를 공유할 수 없습니다.

예를 들어 해당 논리 앱의 워크플로에서 사용하는 연결을 만들고 인증하지 않은 논리 앱 워크플로로 작업해야 한다고 가정합니다. Azure 구독에는 해당 논리 앱 리소스가 포함된 리소스 그룹에 대한 기여자 권한이 필요합니다. 논리 앱 리소스를 만들면 기여자 액세스 권한이 자동으로 부여됩니다.

다른 사람이 논리 앱 워크플로를 변경하거나 삭제하지 못하게 하려면 Azure 리소스 잠금을 사용할 수 있습니다. 이 기능은 다른 사람이 프로덕션 리소스를 변경하거나 삭제하지 못하도록 합니다. 연결 보안에 대한 자세한 내용은 Azure Logic Apps의 연결 구성 및 연결 보안 및 암호화를 참조하세요.

표준 워크플로

참고 항목

이 기능은 미리 보기로 제공되고 Microsoft Azure 미리 보기의 추가 사용 약관이 적용됩니다.

역할 설명
Logic Apps 표준 읽기 권한자(미리 보기) 워크플로 실행 및 해당 기록을 포함하여 표준 논리 앱 및 워크플로의 모든 리소스에 대해 읽기 전용 액세스 권한이 있습니다.
Logic Apps 표준 운영자(미리 보기) 워크플로를 활성화, 다시 제출 및 사용하지 않도록 설정하고 표준 논리 앱에 대한 서비스, 시스템 및 네트워크에 대한 연결을 만들 수 있는 액세스 권한이 있습니다. 운영자 역할은 Azure Logic Apps 플랫폼에서 관리 및 지원 태스크를 수행할 수 있지만 워크플로 또는 설정을 편집할 수 있는 권한이 없습니다.
Logic Apps 표준 개발자(미리 보기) 표준 논리 앱에 대한 워크플로, 연결 및 설정을 만들고 편집할 수 있는 액세스 권한이 있습니다. 개발자 역할에는 워크플로 범위 외부에서 변경할 수 있는 권한이 없습니다(예: 가상 네트워크 통합 구성과 같은 애플리케이션 전체 변경 작업). App Service 요금제는 지원되지 않습니다.
Logic Apps 표준 기여자(미리 보기) 표준 논리 앱의 모든 측면을 관리할 수 있는 액세스 권한이 있지만 액세스 권한 또는 소유권을 변경할 수는 없습니다.

실행 기록 데이터에 대한 액세스

논리 앱을 실행하는 동안 모든 데이터는 TLS(전송 계층 보안)를 사용하여 미사용 상태에서 전송 중에 암호화됩니다. 논리 앱 실행이 끝나면 해당 실행 기록을 볼 수 있습니다. 여기에는 실행된 단계와 함께 각 작업의 상태, 지속 시간, 입력 및 출력이 포함됩니다. 이렇게 풍부한 정보는 논리 앱이 어떻게 실행되었는지, 문제가 발생하면 어디부터 문제 해결을 시작해야 하는지에 대한 인사이트를 제공합니다.

논리 앱의 실행 기록을 볼 때 Azure Logic Apps에서 액세스를 인증한 다음, 각 실행의 요청과 응답에 대한 입력 및 출력 링크를 제공합니다. 단, 암호, 비밀, 키 또는 기타 중요한 정보를 처리하는 작업의 경우 다른 사용자가 해당 데이터를 보거나 액세스하지 못하도록 하는 것이 좋습니다. 예를 들어, Azure Key Vault에서 논리 앱이 HTTP 작업을 인증할 때 사용할 비밀을 가져오는 경우, 이 비밀을 시야에서 숨기는 것이 좋습니다.

논리 앱의 실행 기록에서 입력과 출력에 대한 액세스를 제어하기 위해 다음 옵션을 사용할 수 있습니다.

IP 주소 범위를 통한 액세스 제한

논리 앱 워크플로의 실행 기록에 포함된 입력 및 출력으로 액세스 권한을 제한하여 특정 IP 주소 범위의 요청만 해당 데이터를 보도록 할 수 있습니다.

예를 들어, 입력 및 출력에 아무도 액세스하지 못하게 하려면 0.0.0.0-0.0.0.0와 같은 IP 주소 범위를 지정합니다. 이러한 제한은 관리자 권한이 있는 사용자만 제거할 수 있기 때문에 논리 앱 워크플로의 데이터에 대한 “Just-In-Time” 액세스 가능성을 제공합니다. 올바른 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 주소 범위를 지정합니다.

표준 워크플로

  1. Azure Portal에서 표준 논리 앱 리소스를 엽니다.

  2. 논리 앱 메뉴의 설정에서 네트워킹을 선택합니다.

  3. 인바운드 트래픽 구성 섹션에서 공용 네트워크 액세스 옆에 있는 액세스 제한 없이 사용을 선택합니다.

  4. 액세스 제한 페이지의 앱 액세스에서 선택한 가상 네트워크 및 IP 주소에서 사용 설정됨을 선택합니다.

  5. 사이트 액세스 및 규칙 아래의 기본 사이트 탭에서 특정 IP 범위의 허용 또는 거부 요청에 하나 이상의 규칙을 추가합니다. HTTP 헤더 필터 설정 및 전달 설정을 사용할 수도 있습니다. 올바른 IP 범위는 x.x.x.x/x 또는 x.x.x.x-x.x.x.x 형식을 사용합니다.

    자세한 내용은 Azure Logic Apps(표준)에서 인바운드 IP 주소 차단을 참조하세요.

난독 처리를 사용하여 실행 기록의 데이터 보호

많은 트리거와 작업에는 논리 앱의 실행 기록에서 입력, 출력 또는 둘 다를 보호하는 설정이 있습니다. 모든 관리형 커넥터 및 사용자 지정 커넥터는 이러한 옵션을 지원합니다. 하지만 다음 기본 제공 작업은 이러한 옵션을 지원하지 않습니다.

보안 입력 - 지원되지 않음 보안 출력 - 지원되지 않음
배열 변수에 추가
문자열 변수에 추가
변수 감소
For each
다음과 같은 경우
변수 증가
변수 초기화
되풀이
범위
변수 설정
스위치
종료
Until		 배열 변수에 추가
문자열 변수에 추가
Docker Compose
변수 감소
For each
다음과 같은 경우
변수 증가
변수 초기화
Parse JSON
되풀이
응답
범위
변수 설정
스위치
종료
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. 워크플로 실행 기록 창에서 검토할 작업을 선택합니다.

      입력과 출력을 모두 숨기도록 선택하면 해당 값이 숨김 상태로 표시됩니다.

      숨겨진 입력 및 출력이 있는 표준 워크플로 실행 기록 보기를 보여 주는 스크린샷.

코드 보기의 보안 입력 및 출력

기본 트리거 또는 작업 정의에서 다음 값 중 하나 또는 둘 다를 사용하여 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 섹션에서 이러한 매개 변수를 참조합니다.

Important

최적의 보안을 위해 가능한 경우 인증을 위해 관리 ID와 함께 Microsoft Entra ID를 사용하는 것이 좋습니다. 이 옵션은 자격 증명을 제공하지 않고도 뛰어난 보안을 제공합니다. Azure는 이 ID를 관리하고 이 중요한 정보를 관리할 필요가 없도록 인증 정보를 안전하게 유지하는 데 도움이 됩니다. 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에 해당 값을 저장하고 매개 변수 파일을 사용하여 키 자격 증명 모음과 비밀을 참조할 수 있습니다. 그러면 템플릿이 배포 시 해당 정보를 검색합니다. 자세한 내용은 Azure Key Vault를 사용하여 배포 중에 중요한 값 전달을 검토하세요.

Important

최적의 보안을 위해 가능한 경우 인증을 위해 관리 ID와 함께 Microsoft Entra ID를 사용하는 것이 좋습니다. 이 옵션은 자격 증명을 제공하지 않고도 뛰어난 보안을 제공합니다. Azure는 이 ID를 관리하고 이 중요한 정보를 관리할 필요가 없도록 인증 정보를 안전하게 유지하는 데 도움이 됩니다. Azure Logic Apps용 관리 ID를 설정하려면 Azure Logic Apps에서 관리 ID를 사용하여 Azure 리소스에 대한 액세스 및 연결 인증을 참조하세요.

이 목록에는 다음 parameters 섹션에 대한 자세한 정보가 포함되어 있습니다.

  • 템플릿의 최상위 수준에서 parameters 섹션은 템플릿이 배포 시 사용하는 값에 대한 매개 변수를 정의합니다. 예를 들어 이러한 값에는 특정 배포 환경에 대한 연결 문자열이 포함될 수 있습니다. 그런 다음, 값을 별도의 매개 변수 파일에 저장하면 해당 값을 더 쉽게 변경할 수 있습니다.

  • 논리 앱의 리소스 정의 내에 있지만 워크플로 정의 외부에 있는 parameters 섹션은 워크플로 정의의 매개 변수에 대한 값을 지정합니다. 이 섹션에서는 템플릿 매개 변수를 참조하는 템플릿 식을 사용하여 해당 값을 할당할 수 있습니다. 이러한 식은 배포 시 평가됩니다.

  • 워크플로 정의 내에서 parameters 섹션은 논리 앱 워크플로가 런타임 시 사용하는 매개 변수를 정의합니다. 그런 다음, 런타임 시 평가되는 워크플로 정의 식을 사용하여 논리 앱의 워크플로 내에서 해당 매개 변수를 참조할 수 있습니다.

다음 예제 템플릿에는 securestring 형식을 사용하는 여러 보안 매개 변수 정의가 포함됩니다.

매개 변수 이름 설명
TemplatePasswordParam 비밀을 수신한 후 워크플로 정의의 basicAuthPasswordParam 매개 변수로 전달되는 템플릿 매개 변수
TemplateUsernameParam 사용자 이름을 수신한 후 워크플로 정의의 basicAuthUserNameParam 매개 변수로 전달되는 템플릿 매개 변수
basicAuthPasswordParam HTTP 작업에서 기본 인증을 위한 암호를 수신하는 워크플로 정의 매개 변수
basicAuthUserNameParam HTTP 작업에서 기본 인증을 위한 사용자 이름을 수신하는 워크플로 정의 매개 변수 
{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {
      "LogicAppName": {
         "type": "string",
         "minLength": 1,
         "maxLength": 80,
         "metadata": {
            "description": "Name of the Logic App."
         }
      },
      "TemplatePasswordParam": {
         "type": "securestring"
      },
      "TemplateUsernameParam": {
         "type": "securestring"
      },
      "LogicAppLocation": {
         "type": "string",
         "defaultValue": "[resourceGroup().location]",
         "allowedValues": [
            "[resourceGroup().location]",
            "eastasia",
            "southeastasia",
            "centralus",
            "eastus",
            "eastus2",
            "westus",
            "northcentralus",
            "southcentralus",
            "northeurope",
            "westeurope",
            "japanwest",
            "japaneast",
            "brazilsouth",
            "australiaeast",
            "australiasoutheast",
            "southindia",
            "centralindia",
            "westindia",
            "canadacentral",
            "canadaeast",
            "uksouth",
            "ukwest",
            "westcentralus",
            "westus2"
         ],
         "metadata": {
            "description": "Location of the Logic App."
         }
      }
   },
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
               "actions": {
                  "HTTP": {
                     "type": "Http",
                     "inputs": {
                        "method": "GET",
                        "uri": "https://www.microsoft.com",
                        "authentication": {
                           "type": "Basic",
                           "username": "@parameters('basicAuthUsernameParam')",
                           "password": "@parameters('basicAuthPasswordParam')"
                        }
                     },
                  "runAfter": {}
                  }
               },
               "parameters": {
                  "basicAuthPasswordParam": {
                     "type": "securestring"
                  },
                  "basicAuthUsernameParam": {
                     "type": "securestring"
                  }
               },
               "triggers": {
                  "manual": {
                     "type": "Request",
                     "kind": "Http",
                     "inputs": {
                        "schema": {}
                     }
                  }
               },
               "contentVersion": "1.0.0.0",
               "outputs": {}
            },
            "parameters": {
               "basicAuthPasswordParam": {
                  "value": "[parameters('TemplatePasswordParam')]"
               },
               "basicAuthUsernameParam": {
                  "value": "[parameters('TemplateUsernameParam')]"
               }
            }
         }
      }
   ],
   "outputs": {}
}

인증을 지원하는 커넥터에 대한 인증 유형

다음 표에는 인증 유형을 선택할 수 있는 커넥터 작업에서 사용할 수 있는 인증 유형이 나와 있습니다.

Authentication type 논리 앱 및 지원 커넥터
기본 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

- 표준: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Service Bus, Azure Tables, HTTP, HTTP Webhook, SQL Server
원시 Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
관리 ID 기본 제공 커넥터:

- 사용량: Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP Webhook

- 표준: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Service Bus, Azure Tables, 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 Queues, Azure Resource Manager, Azure Service Bus, Azure Sentinel, Azure Table Storage, Azure VM, Microsoft Entra ID를 사용하는 HTTP, SQL Server

Important

최적의 보안을 위해 가능한 경우 인증을 위해 관리 ID와 함께 Microsoft Entra ID를 사용하는 것이 좋습니다. 이 옵션은 자격 증명을 제공하지 않고도 뛰어난 보안을 제공합니다. Azure는 이 ID를 관리하고 이 중요한 정보를 관리할 필요가 없도록 인증 정보를 안전하게 유지하는 데 도움이 됩니다. Azure Logic Apps용 관리 ID를 설정하려면 Azure Logic Apps에서 관리 ID를 사용하여 Azure 리소스에 대한 액세스 및 연결 인증을 참조하세요.

요청 기반 트리거에 대한 인바운드 호출에 대한 액세스

논리 앱이 요청 기반 트리거(예: Request 트리거 또는 HTTP Webhook 트리거)를 통해 받는 인바운드 호출은 암호화를 지원하며 TLS(Transport Layer Security) 1.2 이상(이전 이름: SSL(Secure Sockets Layer))을 사용하여 보호됩니다. 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

Important

이전 버전과의 호환성을 위해 Azure Logic Apps는 현재 일부 이전 암호 그룹을 지원합니다. 하지만 이전 암호 그룹은 향후에 지원되지 않을 수 있으므로 새 앱을 개발할 때 사용하지 마세요.

예를 들어 Azure Logic Apps에서 또는 논리 앱의 URL에서 보안 도구를 사용하여 TLS 핸드셰이크 메시지를 검사하는 경우 다음 암호 그룹을 찾을 수 있습니다. 이러한 이전 암호 그룹은 사용하지 마세요.

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

다음 목록에는 권한이 있는 클라이언트만 워크플로를 호출할 수 있도록 논리 앱 워크플로에 대한 인바운드 호출을 받는 트리거에 대한 액세스를 제한할 수 있는 방법이 포함되어 있습니다.

Microsoft Entra ID와 함께 OAuth 2.0 사용

요청 기반 트리거로 시작하는 사용량 워크플로에서 Microsoft Entra ID를 사용하는 OAuth 2.0을 사용하도록 설정하여 해당 트리거에서 만든 엔드포인트로 전송된 인바운드 호출을 인증하고 권한을 부여할 수 있습니다. 이 인증을 설정하려면 논리 앱 리소스 수준에서 권한 부여 정책을 정의하거나 추가합니다. 이러한 방식으로 인바운드 호출은 권한 부여에 OAuth 액세스 토큰을 사용합니다.

논리 앱 워크플로가 OAuth 액세스 토큰을 포함하는 인바운드 요청을 받으면 Azure Logic Apps는 토큰의 클레임을 각 권한 부여 정책에 지정된 클레임과 비교합니다. 토큰의 클레임과 하나 이상의 정책에 있는 모든 클레임 사이에 일치하는 항목이 있으면 인바운드 요청에 대한 권한 부여가 성공합니다. 토큰은 권한 부여 정책에 지정된 수보다 많은 클레임을 가질 수 있습니다.

Request 트리거(webhook 트리거 아님)로 시작하는 표준 워크플로에서는 관리 ID를 사용하여 해당 Request 트리거에서 만든 엔드포인트로 전송된 인바운드 호출을 인증하기 위해 Azure Functions 프로비전을 사용할 수 있습니다. 이 프로비전을 "Easy Auth"라고도 합니다. 자세한 내용은 간편한 인증을 사용하여 표준 논리 앱에서 트리거 워크플로를 참조하세요.

Microsoft Entra ID를 사용하여 OAuth 2.0을 사용하도록 설정하기 전 고려 사항

  • 최적의 보안을 위해 가능한 경우 인증을 위해 관리 ID와 함께 Microsoft Entra ID를 사용하는 것이 좋습니다. 이 옵션은 자격 증명을 제공하지 않고도 뛰어난 보안을 제공합니다. Azure는 이 ID를 관리하고 이 중요한 정보를 관리할 필요가 없도록 인증 정보를 안전하게 유지하는 데 도움이 됩니다. Azure Logic Apps용 관리 ID를 설정하려면 Azure Logic Apps에서 관리 ID를 사용하여 Azure 리소스에 대한 액세스 및 연결 인증을 참조하세요.

  • 사용량 워크플로에서 요청 기반 트리거의 엔드포인트 URL에 대한 인바운드 호출은 권한 부여 체계로 Microsoft Entra ID를 사용하는 OAuth 2.0 또는 SAS(공유 액세스 서명) 중 하나만 사용할 수 있습니다. 한 가지 체계를 사용해도 다른 체계가 비활성화되지는 아니지만 두 가지 체계를 동시에 사용하면 Azure Logic Apps는 해당 서비스가 어떤 체계를 선택할지 모르기 때문에 오류가 발생합니다. 사용량 워크플로가 Request 트리거로 시작하는 경우 SAS 인증을 사용하지 않도록 설정하고 Microsoft Entra ID에서 OAuth 2.0만 사용하도록 권한을 제한할 수 있습니다. 표준 워크플로의 경우 SAS를 사용하지 않도록 설정하지 않고 다른 인증 유형을 사용할 수 있습니다.

  • Azure Logic Apps는 Microsoft Entra ID OAuth 액세스 토큰에 대한 전달자 유형 또는 소유 증명 유형(소비 논리 앱에만 해당) 권한 부여 체계를 지원합니다. 그러나 액세스 토큰의 Authorization 헤더는 Bearer 형식 또는 PoP 형식을 지정해야 합니다. PoP 토큰을 가져와 사용하는 방법에 대한 자세한 내용은 PoP(소유 증명) 토큰 가져오기를 참조하세요.

  • 사용량 논리 앱 리소스는 최대 권한 부여 정책 수로 제한됩니다. 각 권한 부여 정책에도 최대 클레임 수가 있습니다. 자세한 내용은 Azure Logic Apps에 대한 제한 및 구성을 참조하세요.

  • 권한 부여 정책에는 최소한 발급자 클레임이 포함되어야 하며, 여기에는 https://sts.windows.net/ 또는 https://login.microsoftonline.com/(OAuth V2)로 시작하는 값이 Microsoft Entra ID의 발급자로 있습니다.

    예를 들어 논리 앱 리소스에 대상 및 발급자라는 두 가지 클레임 유형이 필요한 권한 부여 정책이 있다고 가정합니다. 디코딩된 액세스 토큰에 대한 샘플 페이로드 섹션에는 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만 사용하도록 권한 부여를 제한할 수 있습니다. 이 옵션은 SAS(공유 액세스 서명) 인증을 사용하지 않도록 설정하는 경우에도 작동합니다.

  1. 사용량 워크플로의 경우 Request 또는 HTTP webhook 트리거 출력에 'Authorization' 헤더를 포함하는 단계에 따라 OAuth 액세스 토큰을 검사하는 기능을 사용하여 Request 트리거 또는 HTTP Webhook 트리거를 설정합니다.

    참고 항목

    이 단계에서는 워크플로의 실행 기록 및 트리거의 출력에 Authorization 헤더를 표시합니다.

  2. Azure Portal에서 디자이너를 통해 사용량 워크플로를 엽니다.

  3. 디자이너에서 트리거를 선택합니다. 열리는 정보 창에서 설정을 선택합니다.

  4. 일반>트리거 조건에서 추가를 선택합니다. 트리거 조건 상자에 사용하려는 토큰 형식에 따라 다음 식 중 하나를 입력합니다.

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

    또는

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

올바른 권한 부여 없이 트리거 엔드포인트를 호출하면 실행 기록에 트리거 조건이 실패했다는 메시지 없이 트리거만 Skipped로 표시됩니다.

PoP(소유 증명) 토큰 가져오기

MSAL(Microsoft 인증 라이브러리) 라이브러리는 사용할 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, 권한 부여 페이지 및 권한 부여 정책 세부 정보를 보여 주는 스크린샷

    속성 필수 Type 설명
    정책 이름 예 문자열 권한 부여 정책에 사용하려는 이름입니다.
    정책 유형 예 문자열 전달자 형식 토큰의 경우 AAD, 소유 증명 형식 토큰의 경우 AADPOP입니다.
    클레임 예 문자열 트리거에 대한 각 인바운드 호출에서 제공하는 액세스 토큰에서 워크플로의 요청 트리거가 기대하는 클레임 유형 및 값을 지정하는 키-값 쌍입니다. 표준 클레임 추가를 선택하여 원하는 표준 클레임을 추가할 수 있습니다. PoP 토큰과 관련된 클레임을 추가하려면 사용자 지정 클레임 추가를 선택합니다.

    사용 가능한 표준 클레임 유형:

    - 발급자
    - 대상
    - 주제
    - JWT ID(JSON Web Token identifier)

    요구 사항:

    - 최소한 클레임 목록에는 발급자 클레임이 포함되어야 하며, 여기에는 Microsoft Entra 발급자 ID로 https://sts.windows.net/ 또는 https://login.microsoftonline.com/으로 시작하는 값이 있어야 합니다.

    - 각 클레임은 값 배열이 아니라 단일 문자열 값이어야 합니다. 예를 들어 유형이 역할이고 값이 개발자인 클레임이 있을 수 있습니다. 유형이 역할이고 값이 개발자 및 프로그램 관리자로 설정된 클레임은 있을 수 없습니다.

    - 클레임 값은 최대 문자 수로 제한됩니다.

    이러한 클레임 유형에 대한 자세한 내용은 Microsoft Entra 보안 토큰의 클레임을 검토하세요. 자체 클레임 유형 및 값을 지정할 수도 있습니다.

    다음 예제에서는 PoP 토큰에 대한 정보를 보여 줍니다.

    Azure Portal, 권한 부여 페이지 및 소유 증면 정책 정보를 보여 주는 스크린샷

  5. 또 다른 클레임을 추가하려면 다음 옵션 중에서 선택합니다.

    • 다른 클레임 유형을 추가하려면 표준 클레임 추가를 선택하고 클레임 유형을 선택한 후 클레임 값을 지정합니다.

    • 자체 클레임을 추가하려면 사용자 지정 클레임 추가를 선택합니다. 자세한 내용은 선택적 클레임을 앱에 제공하는 방법을 검토하세요. 사용자 지정 클레임은 JWT ID의 일부로 저장됩니다. 예: "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee".

  6. 권한 부여 정책을 더 추가하려면 정책 추가를 선택합니다. 이전 단계를 반복하여 정책을 설정합니다.

  7. 완료되면 저장을 선택합니다.

  8. 액세스 토큰의 Authorization 헤더를 요청 기반 트리거 출력에 포함하려면 요청 및 HTTP 웹후크 트리거 출력에 '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 웹후크 트리거 출력에 'Authorization' 헤더 포함

인바운드 호출이 요청 기반 트리거에 액세스하도록 권한을 부여하기 위해 Microsoft Entra ID OAuth를 사용하도록 설정하는 논리 앱의 경우, Request 트리거 또는 HTTP Webhook 트리거 출력이 OAuth 액세스 토큰의 Authorization 헤더를 포함하도록 설정할 수 있습니다. 트리거의 기본 JSON 정의에서 operationOptions 속성을 추가하고 IncludeAuthorizationHeadersInOutputs로 설정합니다. Request 트리거의 예는 다음과 같습니다.

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

자세한 내용은 다음 항목을 검토하세요:

SAS(공유 액세스 서명) 키 또는 토큰 생성

워크플로가 요청 기반 트리거로 시작하고 해당 워크플로를 처음으로 저장하면 Azure Logic Apps는 해당 트리거에 호출 가능한 엔드포인트를 만듭니다. 이 엔드포인트에는 워크플로를 시작하기 위한 인바운드 호출 또는 요청을 받을 수 있는 URL이 있습니다. 이 URL에는 스토리지 서비스에 대한 권한을 부여하는 키 또는 토큰인 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에는 다음 표에 설명된 쿼리 매개 변수가 있습니다.

쿼리 매개 변수 설명
sp 사용이 허용된 HTTP 메서드에 대한 권한을 지정합니다.
sv 서명을 생성하는 데 사용할 SAS 버전을 지정합니다.
sig 트리거에 대한 액세스를 인증하는 데 사용할 서명을 지정합니다. 서명은 모든 URL 경로 및 속성에 관한 비밀 액세스 키를 포함한 SHA256 알고리즘을 사용하여 생성됩니다. 이 키는 암호화된 상태로 안전하게 유지되고, 논리 앱에 저장되며, 공개되거나 게시되지 않습니다. 논리 앱은 암호 키로 만들어진 유효한 서명을 포함하는 트리거에 권한을 부여합니다.

Important

계정 키를 무단으로 사용하지 않도록 보호하는 것처럼 SAS 키를 보호해야 합니다. 손상된 액세스 키를 해지하기 위한 계획을 설정하거나 만듭니다. 액세스 키를 사용하는 URI를 배포하고 HTTPS와 같은 보안 연결을 통해서만 이러한 URI를 배포할 때 재량권을 사용합니다. HTTPS 연결을 통해 액세스 키를 사용하는 작업만 수행해야 합니다. 유효한 키가 있는 URI가 있는 모든 사용자는 연결된 리소스에 액세스할 수 있습니다. 보안을 유지하고 논리 앱 워크플로 에 대한 액세스를 보호하려면 보안 정책을 준수하거나 손상되어야 할 수 있으므로 정기적으로 액세스 키를 다시 생성합니다. 이렇게 하면 권한 있는 요청만 워크플로를 트리거하여 데이터 및 프로세스를 무단 액세스로부터 보호할 수 있습니다.

SAS 키를 사용하여 스토리지 서비스에 액세스하는 경우 계정 키가 아닌 Microsoft Entra ID로 보호되는 사용자 위임 SAS를 만드는 것이 좋습니다.

최적의 보안을 위해 가능한 한 인증을 위해 관리 ID와 함께 Microsoft Entra ID를 사용하는 것이 좋습니다. 이 옵션은 자격 증명을 제공하지 않고도 뛰어난 보안을 제공합니다. Azure는 이 ID를 관리하고 이 중요한 정보를 관리할 필요가 없도록 인증 정보를 안전하게 유지하는 데 도움이 됩니다. Azure Logic Apps용 관리 ID를 설정하려면 Azure Logic Apps에서 관리 ID를 사용하여 Azure 리소스에 대한 액세스 및 연결 인증을 참조하세요.

요청 기반 트리거의 엔드포인트에 대한 인바운드 호출은 권한 부여 체계로 SAS 또는 Microsoft Entra ID를 사용하는 OAuth 2.0 중 하나만 사용할 수 있습니다. 한 가지 체계를 사용해도 다른 체계가 비활성화되지는 아니지만 두 가지 체계를 동시에 사용하면 Azure Logic Apps는 해당 서비스가 어떤 체계를 선택할지 모르기 때문에 오류가 발생합니다.

요청 트리거로 시작하는 소비 워크플로가 있는 경우 SAS 인증을 사용하지 않도록 설정할 수 있습니다. 이 옵션은 Microsoft Entra ID에서 OAuth 2.0만 사용하도록 권한 부여를 제한하는 경우에도 작동합니다. 표준 워크플로의 경우 SAS를 사용하지 않도록 설정하지 않고 다른 인증 유형을 사용할 수 있습니다.

SAS 키를 사용하는 경우 보안에 대한 자세한 내용은 이 가이드의 다음 섹션을 참조하세요.

SAS(공유 액세스 서명) 인증 사용 안 함(사용량만 해당)

기본적으로 요청 기반 트리거는 SAS 인증이 사용하도록 설정됩니다. 트리거의 엔드포인트 URL에는 쿼리 매개 변수로 시작하는 SAS(예: sp-<permissions>sv-<SAS-version>sig=<signature>)가 포함됩니다.

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을 사용하도록 설정하는 경우에도 작동합니다. 표준 워크플로의 경우 SAS를 사용하지 않도록 설정하지 않고 다른 인증 유형을 사용할 수 있습니다.

참고 항목

이 작업은 들어오는 요청에 대해 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 개체가 포함됩니다. 이 개체에는 상태속성이 사용 안 함으로 설정되어 있습니다. 예를 들면 다음과 같습니다.

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

SAS를 사용하거나 사용하지 않도록 설정된 사용량 워크플로를 찾으려면 워크플로 정의에 상태 속성이 사용 안 함으로 설정된 sasAuthenticationPolicy 개체가 포함되어 있는지 확인합니다.

  1. REST API 호출을 보내는 도구를 사용하는 경우 다음 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. 워크플로 - 가져오기 작업에서 출력을 가져와서 state 속성이 Disabled로 설정되어 있는 sasAuthenticationPolicy 개체가 있는지 여부를 확인합니다.

워크플로 정의에 sasAuthenticationPolicy 속성 추가

SAS 인증을 사용하지 않도록 설정하려는 사용량 워크플로의 경우 다음 단계를 따릅니다.

  1. 아직 이 작업을 수행하지 않은 경우 다음 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. 워크플로 - 가져오기 작업에서 출력을 가져오고 다음 요소를 수동으로 추가합니다.

    1. 개체가 properties 없는 경우 개체를 포함하는 개체를 triggers 추가 accessControl 합니다.

    2. triggers 개체에서 Disabled로 설정된 state 속성을 포함하는 sasAuthenticationPolicy개체를 추가합니다.

    완료한 후 편집한 부분은 다음 예제와 같이 표시됩니다.

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

  3. 다음 PUT 요청을 사용하여 워크플로 - 업데이트 작업을 실행하여 요청 본문의 입력으로 사용하는 편집된 출력으로 워크플로를 업데이트하는 다른 요청을 보냅니다. 예를 들면 다음과 같습니다.

    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을 사용합니다. 이전 키를 사용하는 이전에 생성된 모든 URI 또는 URL은 무효화되고 더 이상 논리 앱 워크플로를 트리거할 권한이 없습니다. 다시 생성 후 검색하는 URI는 새 액세스 키로 서명됩니다.

  1. Azure Portal에서 다시 생성하려는 키를 사용하는 논리 앱 리소스를 엽니다.

  2. 논리 앱 리소스 메뉴의 설정에서 액세스 키를 선택합니다.

  3. 다시 생성하려는 키를 선택하고 프로세스를 마칩니다.

Important

계정 키를 무단으로 사용하지 않도록 보호하는 것처럼 액세스 키를 보호해야 합니다. 손상된 액세스 키를 해지하기 위한 계획을 설정하거나 만듭니다. 액세스 키를 사용하는 URI를 배포하고 HTTPS와 같은 보안 연결을 통해서만 이러한 URI를 배포할 때 재량권을 사용합니다. HTTPS 연결을 통해 액세스 키를 사용하는 작업만 수행해야 합니다. 유효한 키가 있는 URI가 있는 모든 사용자는 연결된 리소스에 액세스할 수 있습니다.

SAS 키를 사용하여 스토리지 서비스에 액세스하는 경우 계정 키가 아닌 Microsoft Entra ID로 보호되는 사용자 위임 SAS를 만드는 것이 좋습니다.

최적의 보안을 위해 가능한 경우 인증을 위해 관리 ID와 함께 Microsoft Entra ID를 사용하는 것이 좋습니다. 이 옵션은 자격 증명을 제공하지 않고도 뛰어난 보안을 제공합니다. Azure는 이 ID를 관리하고 이 중요한 정보를 관리할 필요가 없도록 인증 정보를 안전하게 유지하는 데 도움이 됩니다. 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 주소 제한

SAS(공유 액세스 서명)와 마찬가지로 논리 앱 워크플로를 호출할 수 있는 특정 클라이언트를 구체적으로 제한할 수 있습니다. 예를 들어 Azure API Management를 사용하여 요청 엔드포인트를 관리하는 경우 생성한 API Management 서비스 인스턴스에 대한 IP 주소의 요청만 수락하도록 논리 앱 워크플로를 제한할 수 있습니다.

지정하는 IP 주소에 관계없이 워크플로 트리거 - 실행 작업 요청을 사용하거나 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 기본 제공 작업을 사용하여 중첩된 워크플로로만 호출할 수 있도록 하려면 다른 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 형식을 사용합니다.

      참고 항목

      다른 Logic Apps 전용 옵션과 HTTP 동작을 사용하여 중첩 워크플로를 호출하는 경우에는 호출이 차단되고 "401 권한 없음"오류가 발생합니다.

    • 다른 IP의 인바운드 호출을 제한하려는 시나리오의 경우 트리거에 대한 IP 범위 상자가 나타나면 트리거가 허용하는 IP 주소 범위를 지정합니다. 올바른 IP 범위는 x.x.x.x/x 또는 x.x.x.x-x.x.x.x 형식을 사용합니다.

  4. 필요에 따라 실행 기록에서 입력한 IP 주소에 대한 입력 및 출력 메시지를 얻기 위한 호출 제한 아래에서 실행 기록의 입력 및 출력 메시지에 액세스할 수 있는 인바운드 호출의 IP 주소 범위를 지정할 수 있습니다.

표준 워크플로

  1. Azure Portal에서 표준 논리 앱 리소스를 엽니다.

  2. 논리 앱 메뉴의 설정에서 네트워킹을 선택합니다.

  3. 인바운드 트래픽 구성 섹션에서 공용 네트워크 액세스 옆에 있는 액세스 제한 없이 사용을 선택합니다.

  4. 액세스 제한 페이지의 앱 액세스에서 선택한 가상 네트워크 및 IP 주소에서 사용 설정됨을 선택합니다.

  5. 사이트 액세스 및 규칙 아래의 기본 사이트 탭에서 특정 IP 범위의 허용 또는 거부 요청에 하나 이상의 규칙을 추가합니다. 올바른 IP 범위는 x.x.x.x/x 또는 x.x.x.x-x.x.x.x 형식을 사용합니다.

    자세한 내용은 Azure Logic Apps(표준)에서 인바운드 IP 주소 차단을 참조하세요.

다른 서비스 및 시스템에 대한 아웃바운드 호출을 위한 액세스

대상 엔드포인트의 기능을 기반으로 HTTP 트리거 또는 HTTP 동작이 보낸 아웃바운드 호출은 암호화를 지원하며 TLS(Transport Layer Security) 1.0, 1.1 또는 1.2(이전 이름: SSL(Secure Sockets Layer))로 보호됩니다. Azure Logic Apps는 지원되는 가장 높은 가능한 버전을 사용하여 대상 엔드포인트와 협상합니다. 예를 들어 대상 엔드포인트가 1.2를 지원하는 경우 HTTP 트리거 또는 동작은 1.2를 먼저 사용합니다. 그렇지 않으면 커넥터는 다음으로 높은 지원되는 버전을 사용합니다.

이 목록에는 TLS/SSL 자체 서명 인증서에 대한 정보가 포함되어 있습니다.

  • 다중 테넌트 Azure Logic Apps 환경의 사용량 논리 앱 워크플로의 경우 HTTP 작업은 자체 서명된 TLS/SSL 인증서를 허용하지 않습니다. 논리 앱이 서버에 HTTP 호출을 수행하고 TLS/SSL 자체 서명된 인증서를 제공하면 HTTP 호출은 실패하고 TrustFailure 오류가 발생합니다.

  • 단일 테넌트 Azure Logic Apps 환경의 표준 논리 앱 워크플로의 경우 HTTP 작업은 자체 서명된 TLS/SSL 인증서를 지원합니다. 하지만 이 인증 유형에 대한 몇 가지 추가 단계를 완료해야 합니다. 그러지 않으면 호출이 실패합니다. 자세한 내용은 단일 테넌트 Azure Logic Apps에 대한 TLS/SSL 인증서 인증을 검토하세요.

    클라이언트 인증서를 사용하거나 인증서 자격 증명 유형을 포함한 Microsoft Entra ID OAuth를 사용하는 경우 이 인증 유형에 대한 몇 가지 추가 단계를 완료해야 합니다. 그러지 않으면 호출이 실패합니다. 자세한 내용은 단일 테넌트 Azure Logic Apps에 대한 클라이언트 인증서 또는 "인증서" 자격 증명 유형이 있는 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는 보안 프록시를 위한 사이트 간 VPN(가상 사설망) 및 ExpressRoute 통합과 온-프레미스 시스템에 대한 통신 등의 온-프레미스 연결 옵션을 제공합니다. 온-프레미스 시스템에 대한 액세스를 제공하는 API가 있고 API Management 서비스 인스턴스를 만들어 해당 API를 노출한 경우 워크플로 디자이너에서 해당 API Management 작업을 선택하여 논리 앱의 워크플로에서 해당 API를 호출할 수 있습니다.

      참고 항목

      커넥터는 보기 및 연결 권한이 있는 API Management 서비스만 표시하고 소비 기반 API Management 서비스는 표시하지 않습니다.

      논리 앱 리소스 종류에 따라 해당 단계를 수행합니다.

      소비 워크플로

      1. API Management 트리거 또는 작업을 추가하는지 여부에 따라 다음 단계를 따릅니다.

        • 트리거:

          1. 워크플로 디자이너에서 트리거 추가를 선택합니다.

          2. 트리거 추가 창이 열리면 검색 상자에 API Management를 입력합니다.

          3. 트리거 결과 목록에서 Azure API Management 트리거 선택을 선택합니다.

        • 작업:

          1. 워크플로 디자이너에서 작업을 추가하려는 위치에 더하기 기호(+)를 선택합니다.

          2. 작업 추가 창이 열리면 검색 상자에 API Management를 입력합니다.

          3. 작업 결과 목록에서 Azure API Management 작업 선택을 선택합니다.

        다음 예에서는 Azure API Management 트리거를 찾는 방법을 보여 줍니다.

        스크린샷에서 Azure Portal, 사용량 워크플로 디자이너 및 API Management 트리거 찾기를 보여 줍니다.

      2. API Management 서비스 인스턴스 목록에서 이전에 만든 API Management 서비스 인스턴스를 선택합니다.

      3. API 작업 목록에서 호출할 API 작업을 선택한 다음 작업 추가를 선택합니다.

      표준 워크플로

      표준 워크플로의 경우 트리거가 아닌 API Management 작업만 추가할 수 있습니다.

      1. 워크플로 디자이너에서 작업을 추가하려는 위치에 더하기 기호(+)를 선택합니다.

      2. 작업 추가 창이 열리면 검색 상자에 API Management를 입력합니다.

      3. 작업 결과 목록에서 Azure API 관리 API 호출을 선택합니다.

        스크린샷에서 Azure Portal, 표준 워크플로 디자이너 및 Azure API Management 작업을 보여 줍니다.

      4. API Management 서비스 인스턴스 목록에서 이전에 만든 API Management 서비스 인스턴스를 선택합니다.

      5. API 작업 목록에서 호출할 API 작업을 선택한 다음 새로 만들기를 선택합니다.

        스크린샷에서 Azure Portal, 표준 워크플로 디자이너 및 호출할 선택된 API를 보여 줍니다.

아웃바운드 호출에 대한 인증 추가

HTTP 및 HTTPS 엔드포인트는 다양한 종류의 인증을 지원합니다. 이러한 엔드포인트에 아웃바운드 호출 또는 요청을 보내는 데 사용하는 일부 트리거 및 동작에서 인증 유형을 지정할 수 있습니다. 워크플로 디자이너에서 인증 유형 선택을 지원하는 트리거 및 작업에는 인증 속성이 있습니다. 그러나 이 속성은 기본적으로 항상 표시되지 않을 수도 있습니다. 이런 경우 트리거 또는 동작에서 고급 매개 변수 목록을 열고 인증을 선택합니다.

Important

논리 앱 워크플로가 처리하는 중요한 정보를 보호하려면 보안 매개 변수를 사용하고 필요에 따라 데이터를 인코딩합니다. 매개 변수를 사용하고 보호하는 방법에 대한 자세한 내용은 매개 변수 입력에 대한 액세스를 검토하세요.

최적의 보안을 위해 가능한 경우 인증을 위해 관리 ID와 함께 Microsoft Entra ID를 사용하는 것이 좋습니다. 이 옵션은 자격 증명을 제공하지 않고도 뛰어난 보안을 제공합니다. Azure는 이 ID를 관리하고 이 중요한 정보를 관리할 필요가 없도록 인증 정보를 안전하게 유지하는 데 도움이 됩니다. Azure Logic Apps용 관리 ID를 설정하려면 Azure Logic Apps에서 관리 ID를 사용하여 Azure 리소스에 대한 액세스 및 연결 인증을 참조하세요.

인증 유형

HTTP 호출의 경우 기본 인증은 사용자 이름과 암호를 포함하는 base64로 인코딩된 문자열을 사용하여 요청을 만듭니다. 이 방법은 암호화 없이 자격 증명을 전송하고 HTTPS/SSL 프로토콜에서 이 옵션을 사용하지 않는 한, 보안 위험이 높아집니다.

Important

최적의 보안을 위해 가능한 경우 인증을 위해 관리 ID와 함께 Microsoft Entra ID를 사용하는 것이 좋습니다. 이 옵션은 자격 증명을 제공하지 않고도 뛰어난 보안을 제공합니다. Azure는 이 ID를 관리하고 이 중요한 정보를 관리할 필요가 없도록 인증 정보를 안전하게 유지하는 데 도움이 됩니다. Azure Logic Apps용 관리 ID를 설정하려면 Azure Logic Apps에서 관리 ID를 사용하여 Azure 리소스에 대한 액세스 및 연결 인증을 참조하세요.

기본 옵션이 사용 가능하고 선택된 경우 다음 속성 값을 지정합니다.

속성(디자이너) Property(JSON) Required 값 설명
인증 type 예 Basic 사용할 인증 유형
사용자 이름 username 예 <사용자-이름> 대상 서비스 엔드포인트에 대한 액세스를 인증하는 사용자 이름입니다.
암호 password 예 <password> 대상 서비스 엔드포인트에 대한 액세스를 인증하는 암호입니다.

보안 매개 변수를 사용하여 중요한 정보를 처리하고 보안을 유지하는 경우(예: 배포 자동화를 위한 Azure Resource Manager 템플릿에서), 식을 사용하여 런타임 시 해당 매개 변수 값에 액세스할 수 있습니다. 다음 예제 HTTP 작업 정의는 인증 type을 Basic로 지정하고 parameters() 함수를 사용하여 매개 변수 값을 가져옵니다.

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

클라이언트 인증서 인증

인증서 기반 인증을 사용하면 사용자가 애플리케이션 및 브라우저 로그인을 위해 Microsoft Entra ID가 아닌 X.509 인증서로 직접 인증을 진행하도록 허용하거나 요구할 수 있습니다. 이 기능을 통해 고객은 피싱 방지 인증을 채택하고 PKI(퍼블릭 키 인프라)에 대해 X.509 인증서로 인증할 수 있습니다.

Important

최적의 보안을 위해 가능한 경우 인증을 위해 관리 ID와 함께 Microsoft Entra ID를 사용하는 것이 좋습니다. 이 옵션은 자격 증명을 제공하지 않고도 뛰어난 보안을 제공합니다. Azure는 이 ID를 관리하고 이 중요한 정보를 관리할 필요가 없도록 인증 정보를 안전하게 유지하는 데 도움이 됩니다. Azure Logic Apps용 관리 ID를 설정하려면 Azure Logic Apps에서 관리 ID를 사용하여 Azure 리소스에 대한 액세스 및 연결 인증을 참조하세요.

클라이언트 인증서 옵션이 사용 가능하고 선택된 경우 다음 속성 값을 지정합니다.

속성(디자이너) Property(JSON) Required 값 설명
인증 type 예 클라이언트 인증서
또는
ClientCertificate		 사용할 인증 유형입니다. Azure API Management를 사용하여 인증서를 관리할 수 있습니다.

참고: 사용자 지정 커넥터는 인바운드 및 아웃바운드 호출 모두에 대해 인증서 기반 인증을 지원하지 않습니다.
Pfx pfx 예 <encoded-pfx-file-content> PFX(개인 정보 교환) 파일의 base64로 인코딩된 콘텐츠

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 파일에 액세스하기 위한 암호

참고 항목

OpenSSL을 사용하여 클라이언트 인증서로 인증하려고 하면 다음 오류가 발생할 수 있습니다.

BadRequest: Could not load private key

이 문제를 해결하려면 다음 단계를 따릅니다.

  1. 모든 OpenSSL 인스턴스를 제거합니다.
  2. OpenSSL 버전 1.1.1t를 설치합니다.
  3. 새 업데이트를 사용하여 인증서에 다시 서명합니다.
  4. 클라이언트 인증서 인증을 사용할 때 HTTP 작업에 새 인증서를 추가합니다.

보안 매개 변수를 사용하여 중요한 정보를 처리하고 보안을 유지하는 경우(예: 배포 자동화를 위한 Azure Resource Manager 템플릿에서), 식을 사용하여 런타임 시 해당 매개 변수 값에 액세스할 수 있습니다. 다음 예제 HTTP 작업 정의는 인증 type을 ClientCertificate로 지정하고 parameters() 함수를 사용하여 매개 변수 값을 가져옵니다.

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

Important

단일 테넌트 Azure Logic Apps에 표준 논리 앱 리소스가 있고, TSL/SSL 인증서, 클라이언트 인증서 또는 Certificate 자격 증명 유형을 사용하는 Microsoft Entra ID OAuth(Microsoft Entra ID 공개 인증)으로 HTTP 작업을 사용하려는 경우 이 인증 단계에 대한 추가 설정 단계를 완료해야 합니다. 그러지 않으면 호출이 실패합니다. 자세한 내용은 단일 테넌트 환경의 인증을 검토하세요.

클라이언트 인증서 인증을 사용하여 서비스를 보호하는 방법에 대한 자세한 내용은 다음 항목을 검토하세요.

Microsoft Entra 플랫폼

Request 트리거에서 논리 앱에 대한 Microsoft Entra 권한 부여 정책을 설정한 후에 Microsoft Entra 플랫폼을 사용하여 들어오는 호출을 인증할 수 있습니다.

Important

최적의 보안을 위해 가능한 경우 인증을 위해 관리 ID와 함께 Microsoft Entra ID를 사용하는 것이 좋습니다. 이 옵션은 자격 증명을 제공하지 않고도 뛰어난 보안을 제공합니다. Azure는 이 ID를 관리하고 이 중요한 정보를 관리할 필요가 없도록 인증 정보를 안전하게 유지하는 데 도움이 됩니다. Azure Logic Apps용 관리 ID를 설정하려면 Azure Logic Apps에서 관리 ID를 사용하여 Azure 리소스에 대한 액세스 및 연결 인증을 참조하세요.

Active Directory OAuth(Microsoft Entra ID를 사용하는 OAuth 2.0) 인증 유형을 지원하는 다른 모든 트리거 및 작업의 경우 다음 속성 값을 지정합니다.

속성(디자이너) Property(JSON) Required 값 설명
인증 type 예 Active Directory OAuth(Microsoft Entra ID를 사용하는 OAuth 2.0)
또는
ActiveDirectoryOAuth		 사용할 인증 유형입니다. Azure Logic Apps는 현재 OAuth 2.0 프로토콜을 따릅니다.
Authority authority 아니요 <URL-for-authority-token-issuer> Azure 전역 서비스 지역과 같이 https://login.microsoftonline.com/ 액세스 키를 제공하는 기관의 URL입니다. 다른 국가 클라우드의 경우 Microsoft Entra 인증 엔드포인트 - ID 기관 선택을 검토하세요.
테넌트 tenant 예 <tenant-ID> Microsoft Entra 테넌트의 테넌트 ID
대상 audience 예 <resource-to-authorize> 권한 부여에 사용할 리소스(예: https://management.core.windows.net/)
클라이언트 ID clientId 예 <client-ID> 권한 부여를 요청하는 앱에 대한 클라이언트 ID
자격 증명 유형 credentialType 예 인증서
또는
암호		 클라이언트가 권한 부여를 요청하는 데 사용하는 자격 증명 유형입니다. 이 속성과 값은 논리 앱의 기본 정의에는 나타나지 않지만 선택한 자격 증명 유형에 대해 나타나는 속성을 결정합니다.
비밀 secret 예, "Secret" 자격 증명 유형에만 해당 <client-secret> 권한 부여를 요청하는 클라이언트 비밀
Pfx pfx 예, "Certificate" 자격 증명 유형에만 해당 <encoded-pfx-file-content> PFX(개인 정보 교환) 파일의 base64로 인코딩된 콘텐츠
암호 password 예, "Certificate" 자격 증명 유형에만 해당 <password-for-pfx-file> PFX 파일에 액세스하기 위한 암호

보안 매개 변수를 사용하여 중요한 정보를 처리하고 보안을 유지하는 경우(예: 배포 자동화를 위한 Azure Resource Manager 템플릿에서), 식을 사용하여 런타임 시 해당 매개 변수 값에 액세스할 수 있습니다. 다음 예제 HTTP 작업 정의는 인증 type을 ActiveDirectoryOAuth로 지정하며 자격 증명 유형을 Secret으로 지정하고 parameters() 함수를 사용하여 매개 변수 값을 가져옵니다.

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

Important

단일 테넌트 Azure Logic Apps에 표준 논리 앱 리소스가 있고, TSL/SSL 인증서, 클라이언트 인증서 또는 Certificate 자격 증명 유형을 사용하는 Microsoft Entra ID OAuth으로 HTTP 작업을 사용하려는 경우 이 인증 단계에 대한 추가 설정 단계를 완료해야 합니다. 그러지 않으면 호출이 실패합니다. 자세한 내용은 단일 테넌트 환경의 인증을 참조하세요.

원시 인증

원시 옵션을 사용할 수 있으면 OAuth 2.0 프로토콜을 따르지 않는 인증 체계를 사용해야 하는 경우 이 인증 유형을 사용할 수 있습니다. 이 유형을 사용하면 나가는 요청과 함께 보내는 인증 헤더 값을 수동으로 만들고 트리거 또는 작업에서 이 헤더 값을 지정합니다.

Important

최적의 보안을 위해 가능한 경우 인증을 위해 관리 ID와 함께 Microsoft Entra ID를 사용하는 것이 좋습니다. 이 옵션은 자격 증명을 제공하지 않고도 뛰어난 보안을 제공합니다. Azure는 이 ID를 관리하고 이 중요한 정보를 관리할 필요가 없도록 인증 정보를 안전하게 유지하는 데 도움이 됩니다. 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"

원시 인증을 지원하는 트리거 또는 작업에서 다음 속성 값을 지정합니다.

속성(디자이너) Property(JSON) Required 값 설명
인증 type 예 원시 사용할 인증 유형
값 value 예 <authorization-header-value> 인증에 사용할 인증 헤더 값

보안 매개 변수를 사용하여 중요한 정보를 처리하고 보안을 유지하는 경우(예: 배포 자동화를 위한 Azure Resource Manager 템플릿에서), 식을 사용하여 런타임 시 해당 매개 변수 값에 액세스할 수 있습니다. 다음 예제 HTTP 작업 정의는 인증 type을 Raw로 지정하고 parameters() 함수를 사용하여 매개 변수 값을 가져옵니다.

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

관리 ID 인증

관리 ID 인증을 지원하는 트리거 또는 작업에서 관리 ID 옵션을 사용할 수 있는 경우 Microsoft Entra ID로 보호되는 Azure 리소스에 대한 액세스를 인증하기 위해 논리 앱에서 자격 증명, 비밀 또는 Microsoft Entra 토큰이 아니라 이 ID를 사용할 수 있습니다. Azure는 ID를 관리하며, 사용자가 비밀을 관리하거나 Microsoft Entra 토큰을 직접 사용하지 않기 때문에 자격 증명을 보호하는 데 유용합니다. Microsoft Entra 인증에 관리 ID를 지원하는 Azure 서비스에 대해 자세히 알아보세요.

  • 소비 논리 앱 리소스는 시스템이 할당한 ID 또는 수동으로 만든 ‘단일’ 사용자가 할당한 ID를 사용할 수 있습니다.

  • 표준 논리 앱 리소스는 시스템이 할당한 관리 ID 및 여러 개의 사용자가 할당한 관리 ID를 ‘동시’에 사용하도록 설정하는 기능을 지원하지만, 사용할 ID는 언제든지 하나만 선택할 수 있습니다.

    참고 항목

    기본적으로 시스템이 할당한 ID는 런타임에 연결을 인증하는 데 사용하도록 이미 설정되어 있습니다. 이 ID는 연결을 만들 때 사용하는 인증 자격 증명이나 연결 문자열과는 다릅니다. 이 ID를 사용하지 않도록 설정하면 실행 시 연결이 작동하지 않습니다. 이 설정을 보려면 논리 앱 메뉴의 설정에서 ID를 선택합니다.

  1. 논리 앱이 관리 ID를 사용할 수 있으려면 그 전에 Azure Logic Apps에서 관리 ID를 사용하여 Azure 리소스에 대한 액세스 인증의 단계를 따르세요. 이 단계는 논리 앱에서 관리 ID를 사용하도록 설정하고 대상 Azure 리소스에 대한 해당 ID의 액세스 권한을 설정합니다.

  2. Azure 함수가 관리 ID를 사용할 수 있으려면 먼저 Azure functions에 대한 인증이 가능하도록 설정합니다.

  3. 관리 ID 사용을 지원하는 트리거 또는 동작에서 다음 정보를 제공합니다.

    기본 제공 트리거 및 동작

    속성(디자이너) Property(JSON) Required 값 설명
    인증 type 예 관리 ID
    또는
    ManagedServiceIdentity    		 사용할 인증 유형
    관리 ID identity 아니요 <user-assigned-identity-ID> 사용할 사용자가 할당한 관리 ID입니다. 참고: 시스템이 할당한 관리 ID를 사용하는 경우 이 속성을 포함하지 마세요.
    대상 audience 예 <target-resource-ID> 액세스하려는 대상 리소스의 리소스 ID입니다.

    예를 들어 https://storage.azure.com/은 인증을 위한 액세스 토큰을 모든 스토리지 계정에 유효하게 만듭니다. 하지만 특정 스토리지 계정에 대해 https://fabrikamstorageaccount.blob.core.windows.net과 같은 루트 서비스 URL을 지정할 수도 있습니다.

    참고: Audience 속성은 일부 트리거나 작업에서 숨겨질 수 있습니다. 이 속성을 표시하려면 트리거 또는 작업에서 고급 매개 변수 목록을 열고 대상 그룹을 선택합니다.

    중요: 이 대상 리소스 ID는 필수 후행 슬래시를 포함하여 Azure AD에 필요한 값과 정확히 일치해야 합니다. 따라서 모든 Azure Blob Storage 계정에 대한 https://storage.azure.com/ 리소스 ID에는 후행 슬래시가 필요합니다. 그러나 특정 스토리지 계정에 대한 리소스 ID에는 후행 슬래시가 필요하지 않습니다. 이러한 리소스 ID를 찾으려면 Microsoft Entra ID를 지원하는 Azure 서비스를 검토합니다.

    보안 매개 변수를 사용하여 중요한 정보를 처리하고 보안을 유지하는 경우(예: 배포 자동화를 위한 Azure Resource Manager 템플릿에서), 식을 사용하여 런타임 시 해당 매개 변수 값에 액세스할 수 있습니다. 예를 들어 이 HTTP 동작 정의는 인증 type을 ManagedServiceIdentity로 지정하고 parameters() 함수를 사용하여 매개 변수 값을 가져옵니다.

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

    관리되는 커넥터 트리거 및 동작

    속성(디자이너) Required 값 Description
    연결 이름 예 <connection-name>
    관리 ID 예 시스템 할당 관리 ID
    또는
    <user-assigned-managed-identity-name>    		 사용할 인증 유형

연결 만들기 차단

Azure Logic Apps의 커넥터를 사용하여 특정 리소스에 연결하는 것이 조직에서 허용되지 않는 경우 Azure Policy를 사용하여 논리 앱 워크플로의 특정 커넥터에 대해 이러한 연결을 만드는 기능을 차단할 수 있습니다. 자세한 내용은 Azure Logic Apps의 특정 커넥터에서 만든 연결 차단을 검토하세요.

논리 앱에 대한 격리 지침

격리에 대한 자세한 내용은 다음 설명서를 참조하세요.

관련 콘텐츠