클라우드 흐름 공유 및 권한 가이드

2025-06-17

이 가이드는 적절한 흐름 공유 시나리오를 식별하고 사용자 액세스를 관리하고 보안을 보장하기 위한 권한을 설정하는 데 도움이 될 수 있습니다.

Power Automate 환경에서 권한 및 역할 관리

안전하고 질서 있는 Power Automate 환경을 유지하려면 흐름을 생성, 편집 또는 실행할 수 있는 사용자를 관리하는 것이 중요합니다. Power Automate의 보안 모델은 여러 수준의 권한에서 작동합니다.

환경 수준 역할(예: 환경 관리자 및 환경 결정자): 주어진 환경에서 리소스를 관리하거나 만들 수 있는 사용자의 기능을 제어합니다.
Dataverse 보안 역할(환경에 Dataverse 데이터베이스가 있는 경우): 기본 사용자, 시스템 사용자 지정자 등 데이터 및 엔터티에 대한 액세스를 제어합니다. 예를 들어, 사용자는 일반적으로 Dataverse 데이터를 사용하는 앱이나 흐름을 실행하려면 최소한 기본 사용자 역할이 필요합니다.
흐름 수준 권한: 다른 사용자를 공동 소유자(편집 권한 포함) 또는 실행 전용 사용자로 만드는 개별 흐름에 대한 설정을 공유합니다.

환경 역할 및 보안

각 환경에서는 적절한 역할을 가진 사용자만 리소스를 만들거나 관리할 수 있습니다.

환경 관리자: 환경에 대한 전체 관리 제어 권한이 있습니다. 환경 관리자는 모든 흐름 보기, 사용자 추가 및 제거, 정책 설정을 포함한 모든 리소스를 관리할 수 있습니다. Dataverse가 없는 환경에서는 이 역할만으로 관리 작업을 수행할 수 있습니다. Dataverse 지원 환경에서 Dataverse의 시스템 관리자 역할은 데이터 작업에 대해 비슷한 목적을 수행합니다.
환경 제작자: 이 역할을 통해 사용자는 환경에서 흐름, 앱 및 연결과 같은 새 리소스를 만들 수 있습니다. 환경 제작자 역할은 Dataverse의 기존 데이터에 대한 액세스 권한을 부여하지 않으며 아티팩트를 빌드하고 공유할 수 있는 권한만 부여합니다. Microsoft는 미리 정의된 역할에 대해 최소 권한 모델을 따릅니다. 환경 제작자는 표시할 권한이 없는 데이터를 노출하지 않고 앱/흐름을 만드는 데 필요한 최소한의 액세스 권한을 갖습니다. 제작자는 필요에 따라 자신이 만든 앱/흐름을 조직 내의 다른 사람들과 공유할 수 있지만, 추가적인 Dataverse 역할이 부여되지 않는 한 데이터를 읽을 수 있는 권한을 스스로 높일 수는 없습니다.
환경 사용자(기본 사용자): Dataverse 기반 환경에서 일반 최종 사용자에게는 앱을 실행하거나 Dataverse 데이터와 상호 작용하는 흐름을 활용하기 위한 기본 사용자 보안 역할(때로는 Common Data Service 사용자라고 함)이 부여되어야 합니다. 기본적으로 환경에 사용자를 추가하려면, 특히 환경에 Dataverse 데이터베이스가 있는 경우, 해당 역할을 명시적으로 할당해야 할 수 있습니다. 이렇게 하면 사용자가 솔루션을 실행할 수 있지만 데이터에 대한 기본 권한만 갖게 됩니다. Dataverse이 없는 환경에서 사용자가 실행 전용으로 흐름이 공유될 경우, 수동으로 추가하지 않는 한 환경 사용자 목록에 표시되지 않을 수 있습니다. 해당 권한은 흐름 공유를 통해서만 이루어집니다.

개별 흐름 수준에서 소유자는 공동 소유자를 추가하거나 실행 전용 사용자를 할당하는 두 가지 주요 방법으로 클라우드 흐름을 공유할 수 있습니다. 차이점을 이해하는 것이 중요합니다.

소유자/공동 소유자: 공동 소유자는 기본적으로 흐름의 원래 작성자와 동일한 권한을 갖습니다. 공동 소유자는 실행 기록을 보고, 흐름의 디자인을 편집하고, 설정을 변경하고, 흐름을 시작 및 중지하고, 연결을 관리하고, 다른 소유자를 추가 또는 제거할 수 있습니다. 즉, 원래 작성자를 삭제할 수 없는 경우를 제외하고는 모든 공동 소유자에게 모든 권한이 부여됩니다. 공동 소유자는 팀 흐름 목록에 흐름을 표시하고, 자신이 만든 흐름처럼 관리할 수 있습니다. 이러한 사용 권한의 범위로 인해 신뢰할 수 있는 개인 또는 그룹만 공동 소유자로 추가해야 합니다.

예: Alice가 Bob 흐름의 공동 소유자인 경우 Alice는 해당 흐름을 수정하거나 삭제할 수 있으므로 Bob의 팀은 이러한 액세스를 의도한 경우에만 Alice를 추가해야 합니다.

실행 전용 사용자: 실행 전용 사용자는 일반적으로 버튼이나 SharePoint 항목 트리거와 같은 수동 트리거를 통해 흐름을 실행하는 데 제한됩니다. 편집 모드에서 흐름을 열거나, 내부 논리를 보거나, 과거 실행 기록을 볼 수 없습니다. 이는 동료가 자동화의 이점을 누릴 수 있도록 하려는 시나리오에 이상적입니다. 예를 들어 디자인 권한을 부여하지 않고 버튼 흐름 또는 인스턴트 데이터 처리 작업을 실행할 수 있습니다. 실행 전용 사용자는 흐름의 이름을 표시하고 실행할 수 있지만 세부 정보를 검사하려고 하면 가시성이 제한됩니다. 또한 어떤 식으로든 다른 사용자를 추가하거나 흐름을 변경할 수 없습니다.

예: 헬프데스크에는 티켓 만들기 및 승인 보내기에 대한 Power Automate 버튼 흐름이 있습니다. 모든 일선 직원은 실행 전용 사용자로 추가되므로 디바이스에서 흐름을 트리거할 수 있지만 흐름이 수행하는 작업을 변경할 수는 없습니다.

리소스별 보안과 환경 역할 비교

환경 역할과 흐름 공유 권한은 함께 작동합니다. 환경 관리자이거나 특정 Dataverse 권한이 있는 사용자는 광범위한 액세스 권한으로 인해 명시적 공유에 관계없이 흐름을 보거나 수정할 수 있습니다.

Power Platform 관리자 또는 환경 관리자는 개별적으로 공유하지 않더라도 환경의 모든 흐름을 표시하고 관리할 수 있습니다. 예를 들어 전역 관리자는 필요한 경우 자신을 흐름에 소유자로 추가할 수 있습니다.
반대로, 환경 역할이 없는 사용자는 공유를 통해 특정 흐름에 대한 액세스 권한을 부여받을 수 있습니다. 이 경우 해당 사용자는 해당 흐름의 특수 사례 참가자가 되지만 환경의 다른 리소스에 액세스하지 못할 수 있습니다.

권한을 효과적으로 관리하기 위해 조직은 어떤 사용자가 흐름 제작자(작성자)이고 어떤 사용자가 흐름 소비자*(실행기)인지 공식화한 다음 그에 따라 역할을 적용해야 합니다. 다음 섹션에서는 이러한 구분을 구현하고 위험을 최소화하기 위한 모범 사례에 대해 설명합니다.

Power Automate의 권한 수준—소유자 대 실행 전용 사용자

흐름 보안 관리의 핵심 측면은 다양한 공유 권한 수준의 기능을 이해하는 것입니다. 다음 표에는 클라우드 흐름에 대한 공동 소유자와 실행 전용 사용자 간의 차이점이 요약되어 있습니다. Power Automate에서 흐름 공동 소유자와 실행 전용 사용자 권한 및 기능을 비교합니다.

기능/액세스	공동 소유자(편집 가능)	실행 전용 사용자(실행 가능)
흐름 정의 보기 및 편집	있음. 흐름의 단계, 설정 및 연결을 보고 수정할 수 있는 전체 액세스 권한이 있습니다.	아니요 편집기에서 흐름을 열거나 구성을 가져올 수 없습니다. 실행 인터페이스만 가져옵니다.
흐름 실행/트리거	있음. 수동으로 흐름을 실행하고 트리거를 수정할 수 있습니다.	있음. 흐름 소유자가 허용한 대로 흐름을 트리거할 수 있습니다(예: 버튼 선택하거나 지정된 트리거 작업 사용).
실행 기록 보기(실행 로그)	있음. 과거 실행, 성공 및 실패 상태, 실행 기록의 출력을 볼 수 있습니다.	아니요 흐름의 실행 기록 또는 과거 실행에 대한 세부 정보를 표시할 수 없습니다.
흐름 관리(사용/사용 안 함, 이름 바꾸기, 삭제)	있음. 흐름 속성을 변경하고, 설정 또는 해제하고, 연결을 업데이트하고, 흐름을 완전히 삭제할 수 있습니다.	아니요 흐름의 상태나 설정을 변경할 수 없습니다. 호출할 수 있는 권한만 있습니다.
다른 사용자와 흐름 공유	있음. 원래 작성자를 삭제할 수 없다는 점을 제외하고 다른 공동 소유자를 추가하거나 제거할 수 있습니다. 실행 전용 사용자를 할당할 수도 있습니다.	아니요 다른 사람과 흐름을 공유할 수 없습니다. 그들은 액세스 권한을 부여하는 사람이 아니라 액세스 권한의 수혜자입니다.
자체 연결(호출자) 사용	해당 없음. 공동 소유자는 흐름에 정의된 연결을 사용합니다. 필요한 경우 연결을 업데이트할 수 있습니다.	종속성. 실행 전용 사용자는 커넥터에 대해 실행 전용 사용자에 의해 제공으로 흐름이 구성된 경우 실행할 때 자신의 연결을 사용해야 할 수도 있습니다. 그렇지 않으면 흐름에서 소유자의 연결을 사용합니다.
Power Automate 사용자 인터페이스의 가시성	모든 소유자의 팀 흐름 아래에 표시됩니다. 공동 소유자의 이름이 소유자 목록에 나열됩니다.	소유자를 위한 흐름의 실행 전용 사용자 목록(흐름 세부 정보 페이지)에 표시되지만, 실행 전용 사용자는 흐름을 실행할 수 있는 컨텍스트(예: 버튼 또는 앱 내, 소유한 흐름 또는 팀 흐름에 나열되지 않음)에서만 흐름을 가져옵니다.

실제로 이러한 구분은 공동 소유자가 흐름의 디자인 또는 유지 관리에 대해 진정으로 공동 작업해야 하는 사용자로 제한되어야 함을 의미하는 반면, 흐름 기능의 광범위한 배포에는 실행 전용 공유가 선호됩니다. Microsoft의 지침은 다음을 강화합니다: "필요한 경우에만 흐름 공동 작업을 위해 공동 소유자를 추가합니다." 대부분의 경우 흐름을 공유해야 하는 경우 실행 전용 권한으로 공유합니다." 이를 통해 사용자는 무단 수정이나 흐름 내부 노출의 위험 없이 자동화의 이점을 누릴 수 있습니다.

환경 구성원이 아닌 사용자가 흐름에 액세스할 수 있도록 허용하면 다음과 같은 몇 가지 위험이 발생할 수 있습니다.

거버넌스 사각지대: 관리자는 누가 액세스할 수 있는지 인식하지 못할 수 있습니다.
잠재적 데이터 노출: 흐름에서 중요한 데이터를 처리하는 경우.
실행 전용 액세스: 트리거가 매개 변수 입력 또는 출력 표시 유형을 허용하고 변경 제어가 손실되는 경우 문제가 될 수 있습니다. 팀 외부의 공동 소유자가 의도하지 않은 편집을 하는 경우입니다.

이러한 위험을 완화하기 위해 조직은 정책, 기술 제어 및 모니터링의 조합을 채택해야 합니다.

환경 액세스 제어 적용: 기본적인 모범 사례는 Microsoft Entra (Azure AD) 보안 그룹을 사용하여 환경 멤버 자격을 제한하는 것입니다. 보안 그룹을 환경과 연결하면 해당 그룹의 사용자만 환경의 역할에 추가할 수 있습니다. 즉, 제작자가 그룹 외부의 사용자와 흐름을 공유하려고 시도하더라도 해당 사용자는 환경에 자동으로 추가되지 않습니다. 연결된 보안 그룹이 있는 환경에서 그룹에 속하지 않은 모든 사용자는 기본적으로 외부인이며 관리자가 액세스 권한을 부여할 때까지 기능이 제한됩니다. 이 설정은 관리자가 정책에 따라 보안 그룹에 추가하여 명시적으로 추가하지 않는 한 외부인이 환경 리소스에 액세스하지 못하도록 차단합니다.

예를 들어, Contoso의 HR Apps 환경이 HR-Team 보안 그룹에 연결된 경우, 재무 부서의 사용자는 관리자가 HR-Team 그룹에 먼저 추가하지 않는 한 HR Apps 흐름의 공동 소유자로 지정될 수 없습니다. 이러한 방식으로 보안 그룹을 사용하면 조직에서 각 환경의 사용 권한을 명확하게 정의할 수 있습니다.
공동 소유권 검토 및 제한: 공동 소유자와의 흐름 공유는 드물게 수행해야 합니다. 각 공동 소유자는 사실상 흐름의 전체 소유자가 되므로 공동 소유자 수를 필요한 수로만 제한합니다. 문제 해결을 위해 외부 사람(예: 다른 팀의 개발자 또는 컨설턴트)과 흐름을 공유한 경우 문제가 해결된 후 공동 소유권을 제거해야 합니다. 지속적으로 필요한 경우가 아니면 이렇게 하십시오. 조직은 환경 외부에 공동 소유자를 추가하면 경고가 트리거되거나 승인이 필요한 거버넌스 프로세스를 구현할 수 있습니다. 이는 Power Automate 거버넌스 도구(예: Power Platform 관리 커넥터를 사용하여 흐름에 새 소유자가 추가될 때 감지하는 관리 흐름)를 사용하여 달성할 수 있습니다. 그런 다음 IT 또는 Power Platform Center of Excellence 팀에 알립니다.
외부 사용자에 대한 실행 전용 공유 선호: 환경 구성원이 아닌 사용자와의 공유가 불가피하거나 정당한 경우 가능한 경우 전체 편집 권한 대신 실행 전용 권한을 사용합니다. 실행 전용 액세스는 위험을 크게 줄여줍니다: 사용자는 흐름 논리를 보거나 변경할 수 없으며 중요한 페이로드를 포함할 수 있는 과거 실행 데이터를 가져옵니다.

예를 들어 흐름이 이메일을 통해 고객 데이터를 보내는 경우 실행 전용 사용자는 해당 이메일 보내기를 트리거할 수 있지만 어제 처리된 고객 세부 정보를 가져오기 위해 흐름을 열 수는 없습니다. 이 원칙은 최소 권한, 즉 사용자 역할에 필요한 최소 액세스 권한을 부여하는 것과 일치합니다. 실행 전용 공유는 제어권을 넘겨주지 않고 누군가가 흐름을 트리거하거나 활용할 수 있도록 하는 비즈니스 요구 사항을 달성할 수 있는 경우가 많습니다.
보안 역할을 사용하여 업무 분할: 흐름을 실행만 하고 흐름을 만들지 않는 사용자에게 환경 결정자 역할이 없는지 확인합니다. 이러한 사용자를 기본 환경 사용자로 유지하거나 실행 전용 흐름 액세스만 있는 환경 외부로 완전히 유지하면 불량 흐름을 만들거나 가져올 수 있는 가능성을 줄일 수 있습니다. 지정된 제작자만 제작자 권한을 가져야 하는 반면, 다른 사람들은 흐름의 출력만 사용할 수 있습니다.

보안 역할 및 그룹 사용: 제작자와 실행 전용 사용자 관리에서 자세히 알아보세요.
DLP(데이터 손실 방지) 정책 구현: DLP 정책은 커넥터 사용을 제어하는 것에 더 가깝지만 공유 흐름에서 금지된 커넥터를 사용하지 못하도록 하여 간접적으로 위험을 완화하는 데 도움이 됩니다. 예를 들어 외부인에게 흐름에 대한 실행 전용 액세스 권한이 부여된 경우 엄격한 DLP 정책은 흐름이 갑자기 승인되지 않은 서비스로 데이터를 푸시하기 시작할 수 없도록 합니다. DLP는 공유 자체를 중지하지는 않지만 흐름이 실수로 또는 의도적으로 오용되는 경우 잠재적인 손상을 제한합니다. 커넥터를 비즈니스 및 비-비즈니스 범주로 분류하고 위험한 조합을 차단하는 것이 가장 좋습니다. 이렇게 하면 흐름이 광범위하게 공유되더라도 승인되지 않은 엔드포인트로 데이터가 유출되지 않습니다.
정기 감사 및 모니터링: 흐름 권한을 감사하는 루틴(예: 월별 또는 분기별)을 설정합니다. 이 검토의 일환으로 비정상적인 공유가 있는 흐름, 특히 외부 소유자 또는 대규모 실행 전용 사용자 목록이 있는 흐름을 식별합니다. 여전히 필요한 경우 검토하십시오. Microsoft 설명서는 사용 권한을 정기적으로 검토하여 현재 비즈니스 요구 사항에 맞는지 확인하고 더 이상 필요하지 않은 사용자의 액세스 권한을 제거하도록 권장합니다.

모니터링을 자동화할 수 있습니다. 예를 들어, 관리자는 관리자 커넥터를 사용하여 모든 흐름에 대한 보고서와 소유자, 마지막 수정 날짜를 전송하는 Power Automate 흐름을 설정할 수 있습니다. 흐름은 지정된 승인된 개인 목록 외부에 소유자가 있는 흐름을 강조 표시합니다. 또한 Power Platform 관리자 분석 대시보드를 활용하는 것이 좋습니다. 전체 사용량을 표시할 수 있으며 잠재적으로 필터링하여 각 흐름을 실행 중인 사용자 수를 파악할 수 있습니다.
제작자 교육 및 정책 시행: 때때로 위험은 인식 부족으로 인해 발생합니다. 공유에 대한 명확한 정책을 문서화하고 전달합니다(예: 승인 없이 환경 X 외부의 사용자를 공동 소유자로 추가하지 않음). 팀 외부 사용자에게 필요한 경우 실행 전용 액세스를 사용합니다. Power Automate 제작자를 이러한 지침에 따라 교육하면 우발적인 노출을 줄일 수 있습니다. 조직에 내부 Power Platform 커뮤니티 또는 챔피언 네트워크가 있는 경우 흐름을 광범위하게 공유하는 것의 의미에 대한 알림을 공유하세요. 궁극적으로 사용자는 Power Automate가 공유를 쉽게 만들지만 환경 간 공동 작업을 위해 따라야 하는 규정 준수 및 보안 단계가 있음을 이해해야 합니다.
광범위한 공유를 위해 별도의 환경 사용: 경우에 따라 광범위한 대상 그룹이 사용해야 하는 흐름을 위한 전용 환경을 사용하는 것이 현명할 수 있습니다. 예를 들어 조직에서는 적절한 보안 그룹을 사용하여 많은 사용자에게 열려 있는 공유 서비스 환경을 만들 수 있습니다. 광범위한 소비를 위한 흐름은 더 제한된 환경에서 공유하지 않고 그곳에서 개발 및 호스팅할 수 있습니다. 이렇게 하면 환경 경계가 유지됩니다. 고도로 통제된 환경은 엄격하게 유지되며, 개방형 환경은 적절한 감독을 통해 부서 간 공유를 위해 지정됩니다. 이 전략을 채택하는 경우 개방형 환경에는 설계상 더 큰 사용자 기반이 있으므로 여전히 강력한 DLP 정책 및 모니터링이 있는지 확인합니다.
직접 공유 대신 흐름 복사 고려: 다른 환경의 사용자에게 흐름의 기능이 필요한 경우 또 다른 방법은 흐름을 패키지로 내보내고 라이브 흐름을 공유하는 대신 패키지를 공유하는 것입니다. Microsoft는 사용자가 Power Automate 환경의 구성원이 아닌 시나리오에서 이 방법을 권장하며, 사용자가 자신의 환경으로 가져온 흐름의 복사본을 보낼 수 있습니다. 그런 다음 수신자는 자신의 연결을 설정하고 흐름을 독립적으로 실행합니다. 이렇게 하면 원래 환경의 흐름에 대한 직접 액세스를 방지하여 위험을 완화할 수 있습니다. 이는 본질적으로 환경에 접근 권한을 제공하지 않고 솔루션을 제공합니다. 단점은 흐름에 대한 업데이트가 별도의 복사본이기 때문에 자동으로 동기화되지 않는다는 것입니다. 그러나 일회성 요구 사항이나 외부 팀과의 공유의 경우 이 방법을 사용하면 깔끔하게 분리할 수 있습니다.

요약하자면, 흐름 공유와 관련된 위험을 완화하는 것은 환경 액세스에 대한 엄격한 제어, 공유 옵션의 신중한 사용, 세심한 감독으로 귀결됩니다. 기술적 보호 장치(보안 그룹 제어 환경 및 DLP 정책 등)와 프로세스 보호 장치(소유자 추가 승인 및 정기 감사 등)를 결합함으로써 조직은 Power Automate의 협업 이점을 누리면서 보안 및 규정 준수 문제를 최소화할 수 있습니다.

다음 섹션에서는 거버넌스의 특정 측면에 초점을 맞춥니다: 역할과 그룹을 사용하여 누가 제작자인지, 누가 단순히 흐름의 주자인지를 정의합니다.

보안 역할 및 그룹 사용: 제작자와 실행 전용 사용자 관리

중요한 거버넌스 결정은 어떤 사용자가 제작자가 되어 흐름을 만들고 소유할 수 있는지, 그리고 어떤 사용자가 흐름 실행만 할 수 있는지, 결과를 사용할 수 있는지를 결정하는 것입니다. Power Automate및 Power Platform은 주로 보안 역할과 보안 그룹을 통해 이러한 구분을 강화하는 여러 가지 메커니즘을 제공합니다.

제작자와 비제작자 구분

엔터프라이즈 시나리오에서 Power Automate 라이선스가 있는 모든 사용자가 모든 환경에서 흐름을 빌드해야 하는 것은 아닙니다. 설계상 환경 제작자는 해당 환경에서 흐름과 기타 리소스를 생성할 수 있습니다. 전용 환경의 경우 의도적으로 환경 제작자 역할을 솔루션 빌드를 담당하는 사용자 또는 그룹에만 할당해야 합니다. 예를 들어, 재무 자동화 환경에서 재무 IT 팀과 소수의 고급 사용자에게만 제작자 권한이 있다고 결정할 수 있습니다.

다음을 수행하여 이를 시행하세요.

환경 제작자의 특정 사용자에게 직접 환경 제작자 보안 역할을 할당합니다.
Azure Active Directory(AD) 보안 그룹을 사용합니다. 의도한 모든 제작자를 그룹(예: 재무 제작자 그룹)에 추가하고 해당 환경에 Dataverse가 없는 경우 해당 그룹 전체에 환경 제작자 역할을 할당합니다. Dataverse 지원 환경에서는 그룹 구성원을 개별적으로 추가하거나 보안 역할이 있는 그룹 팀을 사용해야 할 수 있습니다.
광범위한 제어를 위해 환경을 보안 그룹과 연결하여 구성원만 환경에 들어갈 수 있도록 합니다. 그런 다음 그 내에서 적절한 하위 집합에 제작자 역할을 부여합니다. 이 2단계 접근 방식은 외부인을 제작자로 감지하지 않고 데려올 수 없으며 내부자 중 일부만 제작자 역할을 한다는 것을 의미합니다. 신뢰할 수 있는 지침에서는 원치 않는 사용자의 존재를 방지하기 위해 모든 프로덕션 및 중요한 환경에 환경 보안 그룹 기능을 적용하는 것이 좋습니다.

실행 전용 액세스에 보안 그룹 사용

환경 실행 전용 역할은 없지만 그룹을 사용하여 대규모로 실행 전용 권한을 관리할 수 있습니다. 흐름을 공유할 때 소유자는 공동 소유자 또는 실행 전용 액세스를 위해 개별 사용자 대신 그룹 이름을 입력할 수 있습니다. 즉, 영업 보고서 흐름 사용자와 같은 보안 그룹을 만들고 해당 그룹을 관련 흐름에서 실행 전용 사용자로 할당할 수 있습니다. 그러면 그룹의 모든 구성원이 해당 흐름에 대한 실행 권한을 상속합니다. 관리가 더 쉬워집니다. 특정 사용자에 대한 액세스 권한을 취소하려면 그룹에서 해당 사용자를 제거합니다. 그룹이 할당된 모든 흐름에 대한 실행 액세스 권한을 잃게 됩니다. 마찬가지로 새 사용자에게 여러 흐름에 대한 실행 액세스 권한을 부여하려면 해당 사용자를 그룹에 추가합니다. 따라서 보안 그룹은 권한 관리를 외부화하여 권한 관리를 단순화하는 데 도움이 됩니다.

Power Automate 흐름은 실행 전용 사용자 50명을 나열할 필요가 없습니다. 하나의 그룹을 나열하고 Azure AD 또는 Microsoft 365 관리자가 멤버십을 처리합니다.

참고

환경 자체가 보안 그룹으로 잠긴 경우 흐름 공유에 사용되는 그룹은 동일하거나 하위 집합이어야 합니다. 환경에서 허용된 사용자 외부의 사용자가 포함된 그룹과 흐름을 공유하는 경우 환경 설정에 따라 실제로 흐름을 실행하지 못할 수도 있습니다. 환경 액세스 정책에 따라 그룹 사용을 조정해야 합니다.

제작자와 실행자에 대한 역할 할당

Dataverse 환경에서는 보안 역할을 계층화하여 제작자와 실행 전용 사용자가 수행할 수 있는 작업을 세부 조정할 수 있습니다.

제작자: 흐름을 만들려면 최소한 환경 제작자 역할이 필요합니다. 해당 흐름이 Dataverse 테이블과 상호 작용하는 경우, 적절하게 설계하고 테스트하기 위해 시스템 사용자 지정자와 같은 추가적인 Dataverse 역할이나 특정 테이블에 대한 권한이 필요할 수도 있습니다. 환경 제작자와 데이터 액세스 권한을 부여하는 역할(필요한 경우)을 조합하면 전체 솔루션을 빌드할 수 있습니다. 제작자에게 필요한 권한만 부여하는 것이 가장 좋습니다. 예를 들어, 제작자가 SharePoint와 이메일만 자동화하는 경우 해당 환경에 존재하는 것 외에는 Dataverse 역할이 전혀 필요하지 않을 수 있습니다. 하지만 제작자가 Dataverse 레코드를 업데이트하는 흐름을 빌드하는 경우 해당 테이블에 대한 권한이 필요합니다. 필요한 경우 제작자가 지나치게 광범위한 역할을 맡는 대신, 별도의 제작자 데이터 역할을 맡을 수 있도록 보안 역할을 계획합니다.
실행 전용 사용자: 이러한 사용자는 환경 제작자가 필요하지 않습니다. 환경에 Dataverse 데이터베이스가 있고 흐름이 Dataverse 데이터와 관련이 있는 경우 흐름이 해당 컨텍스트에서 실행될 때 기본 데이터에 대한 읽기/쓰기 액세스 권한을 얻으려면 기본 사용자 역할(또는 다른 역할)이 필요할 수 있습니다. 예를 들어, 수동 트리거 흐름은 실행자를 대신하여 Dataverse 레코드를 만들 수 있습니다. 그렇다면 실행기는 해당 레코드를 만들 수 있는 권한이 필요합니다. 실행 전용 사용자가 연결 제공 옵션을 사용하는 경우, 흐름은 실행 전용 사용자의 자격 증명으로 실행됩니다. 이러한 경우, Dataverse 역할이나 관련 시스템 권한을 통해 해당 사용자가 흐름에서 실행하는 작업을 수행하는 데 필요한 최소한의 권한을 가지고 있는지 확인해야 합니다. 흐름이 항상 소유자의 연결을 사용하는 경우, 실행 전용 사용자는 버튼을 누르고 흐름이 소유자의 권한을 사용하므로 Dataverse에서 특별한 역할이 필요하지 않을 수 있습니다. 이 뉘앙스를 신중하게 고려해야 합니다. 안전한 방법은 실행 전용 사용자에게 표시할 수 있는 데이터에 대한 읽기 액세스 권한을 부여하는 것입니다. 많은 회사에서는 사용자 지정 Dataverse 역할을 만들거나 최소한의 읽기 권한이 있는 기본 사용자를 사용하여 모든 최종 사용자에게 할당하여 앱 및 흐름 실행에 대한 이러한 요구 사항을 충족합니다.

거버넌스를 염두에 둔 역할 관리

누가 어떤 역할을 맡고 있는지 추적합니다. Power Platform 관리자는 관리 센터 또는 PowerShell을 통해 환경의 모든 사용자와 할당된 보안 역할을 나열할 수 있습니다. 이는 예상되는 제작자 목록과 상호 참조될 수 있습니다. 인벤토리를 유지 관리하는 거버넌스 모범 사례입니다(예: 환경 X 제작자: Alice, Bob, Carol; 환경 X 실행 전용/소비자: 마케팅 부서의 모든 사용자). 이를 명확히 하면 새로운 제작자를 추가하라는 요청이 왔을 때 해당 제작자가 그룹 승인을 받았는지 또는 서클을 확장하는 데 필요한 승인을 받았는지 확인할 수 있습니다.

시나리오 및 예

다음 목록에서는 몇 가지 시나리오와 해결 방법의 예를 설명합니다.

시나리오: 소수의 팀만 흐름을 작성해야 하지만 부서의 많은 팀이 흐름을 실행하는 부서 환경입니다.
해결 방법: 부서의 IT 책임자에게 환경 관리자가 부여됩니다. 부서 제작자 Azure AD 그룹에는 앱 및 흐름을 만드는 5명이 포함됩니다. 이 그룹은 환경 제작자 역할에 추가됩니다. 이 작업은 직접 수행되거나 그룹 할당을 사용할 수 없는 경우 개인이 할당됩니다. 부서의 모든 사용자는 환경과 연결된 부서 사용자 그룹에 속하므로 모두 사용자가 될 수 있는 액세스 권한을 갖습니다. 전체 부서에서 실행해야 하는 환경에서 생성된 흐름은 부서 사용자 그룹과 실행 전용으로 공유됩니다. 이러한 방식으로 제작자들은 구축하고 공유할 수 있습니다. 부서 구성원은 실행할 수 있지만 부서가 아닌 사용자는 환경 그룹에 속하지 않으므로 액세스할 수 없습니다.
시나리오: 두 명의 솔루션 소유자를 제외한 누구도 편집해서는 안 되는 중요한 흐름이 있는 프로덕션 환경입니다.
해결 방법: 이 두 사람만이 환경 작성자입니다. 다른 누구도 메이커 역할을 할 수 없습니다. 다른 사용자가 흐름을 트리거해야 하는 경우 실행 전용 액세스 권한이 부여됩니다. 전용 서비스 계정 또는 서비스 주체는 실제로 안정성을 위한 흐름의 소유자이며 두 소유자는 유지 관리를 위한 공동 소유자일 수 있습니다. 서비스 주체를 기본 소유자로 사용하면 중요한 흐름에 대한 거버넌스가 향상됩니다. 모든 일반 직원은 해당 환경에 있지 않거나 사용자 역할만 있습니다. 환경은 배타성을 더욱 보장하기 위해 필요한 계정만 포함하는 보안 그룹에 연결될 수 있습니다.
시나리오: 거버넌스 팀이 모든 환경에서 모니터링 흐름을 빌드하는 CoE(Center of Excellence) 환경입니다.
해결 방법: Center of Excellence 팀만 액세스할 수 있습니다. 이는 역할별 환경 제작자입니다. 이러한 흐름은 더 내부적이므로 실행 전용 공유가 필요하지 않습니다. 여기서 중요한 Center of Excellence 담당자는 테넌트 수준에서 Power Platform 관리자 역할을 맡고 있을 수 있으며, 이는 암묵적으로 모든 환경에 대한 권한을 부여합니다.

역할 분리의 이점

제작자와 주자를 명확하게 구분하면 다음과 같은 결과를 얻을 수 있습니다.

최소 권한: 사용자는 필요한 권한만 얻습니다. 실행 전용 사용자는 해당 역할이 없기 때문에 IT 감독을 우회하는 흐름을 갑자기 만들 수 없습니다. 제작자는 창작의 자유를 얻지만, 인구가 적고 알려져 있기 때문에 더 쉽게 훈련하고 감독할 수 있습니다.
간소화된 수명 주기 관리: 직원이 퇴사하거나 역할을 변경할 때 액세스 권한을 더 쉽게 업데이트할 수 있습니다. 예를 들어 Joe가 제작자였고 팀에서 이동하는 경우 제작자 보안 그룹에서 제거합니다. 그는 해당 환경에서 만들고 편집할 수 있는 기능을 즉시 잃게 되며, 사용자 그룹에 남아 있는 경우 실행 액세스 권한을 유지합니다. 그런 다음 그의 후임을 Makers 그룹에 추가할 수 있습니다. 이 그룹 기반 유지 관리는 수십 개의 흐름 권한을 수동으로 추가 및 제거하는 것보다 깔끔합니다.
규정 준수 맞춤: 많은 규정에서 액세스 제어를 요구합니다. 이러한 특정 개인만 이 환경에서 자동화를 수정할 수 있고 다른 모든 개인은 승인된 흐름을 트리거할 수 있다는 것을 감사자에게 보여줄 수 있으면 강력한 내부 통제를 입증하는 데 도움이 될 수 있습니다. 감사자는 적용의 증거로 환경 역할 할당의 내보내기를 받을 수도 있습니다.
혼동 방지: 모든 사람이 제작자 권한을 가지고 있다면 기술 사용자가 실수로 흐름을 만들거나 변경하거나 Power Automate 인터페이스로 인해 혼동을 겪는 일이 줄어들 것입니다. 제작자의 역할을 제한하면 교육을 받은 직원만 흐름을 설계할 수 있으므로 실수를 줄일 수 있습니다.

이러한 조치는 주기적으로 재검토되어야 합니다. 비즈니스 요구 사항이 변화함에 따라 소비자인 누군가가 제작자가 되어야 하거나(예: 고급 사용자가 새 팀에 등장) 제작자가 소비자가 되어야 할 수 있습니다. 거버넌스 모델은 적절한 승인을 통해 이를 수용할 수 있을 만큼 유연해야 합니다. 환경 제작자 권한을 부여받기 위한 기준과 이를 요청하는 프로세스를 문서화하여 투명성과 일관성을 유지합니다. 마찬가지로, 제작자 액세스 취소를 트리거할 수 있는 조건(예: 다른 부서로 이동)을 정의합니다.

보안 역할과 그룹을 함께 사용함으로써 조직은 자동화를 만드는 사람과 자동화를 사용하는 사람을 명확하고 유지 관리 가능한 구분을 달성할 수 있습니다. 이를 통해 Power Automate 환경의 보안과 생산성이 모두 향상됩니다.