2025년 6월부터 환경 구성원이 아닌 사용자와 공유되는 모든 흐름은 해당 사용자가 액세스할 수 없게 됩니다. Power Automate에 대한 이 중요한 변경 사항으로 인해 사용자는 해당 환경의 흐름에 액세스하려면 해당 환경의 구성원이어야 합니다. 이 변경은 환경 경계를 적용하여 보안을 강화합니다. 그러나 서로 다른 환경에서 흐름을 공유하는 조직(예: 흐름 소유자가 환경 외부의 사용자를 공동 소유자 또는 실행 전용 사용자로 추가하는 경우)에 영향을 줍니다.
새로운 정책을 준수하려면 Power Platform 관리자가 환경 외부의 사용자와 공유되는 흐름을 식별하고 해당 흐름의 공유 설정을 조정해야 합니다. 이 문서에서는 이를 위한 구조화된 접근 방식을 제공합니다.
이 문서는 다음을 수행하는 데 도움이 됩니다.
- 외부 사용자(흐름의 환경에 있지 않은 사용자)와 공유되는 흐름을 식별합니다.
- 연속성을 보장하기 위해 해당 흐름에 대한 공유 및 액세스를 조정합니다(예: 환경에 적절한 사용자 추가 및 실행 전용 액세스 사용).
이 문서를 통해 Power Platform 관리자는 2025년 6월 적용 전에 공유 문제를 선제적으로 해결할 수 있습니다. 또한 앞으로 흐름 공유를 안전하게 관리하기 위한 거버넌스를 설정하는 데 도움이 될 수 있습니다. 요점을 설명하기 위해 이 문서에는 실제 예제와 단계별 지침이 포함되어 있습니다.
클라우드 흐름 공유에서 공유 흐름을 관리하기 위한 모범 사례를 알아보세요.
환경 외부의 사용자와 공유되는 흐름 식별
첫 번째 단계는 각 환경의 모든 클라우드 흐름 및 해당 공유 사용자의 인벤토리를 작성한 다음, 외부인(해당 환경의 구성원이 아닌 사용자)과 공유하는 흐름을 찾아내는 것입니다. Power Automate 흐름은 일반(솔루션이 아닌) 흐름 또는 솔루션 인지 흐름(Dataverse 솔루션의 일부)의 두 가지 방법으로 만들 수 있습니다. 둘 다 환경에 상주하며 둘 다 검토가 필요합니다. 다음 섹션에서는 외부와 공유되는 흐름을 식별하는 방법을 설명합니다.
Power Platform 관리 센터—GUI 메서드
환경 관리자는 Power Platform 관리 센터를 사용하여 시각적 감사를 수행할 수 있습니다.
Power Platform 관리 센터에서 관리>환경 > (사용자 환경) >리소스>흐름을 선택합니다.
A는 소유자 열과 함께 환경의 모든 흐름을 나열합니다.
각 흐름에 대해 소유자를 검사합니다. 흐름에 소유자가 여러 명(작성자 및 공동 소유자)인 경우 흐름이 공유됩니다. 이러한 소유자를 환경의 알려진 구성원과 비교합니다. 예를 들어 해당 환경의 보안 그룹 또는 사용자 목록을 비교합니다.
소유자 또는 공동 소유자가 예상 환경 구성원이 아닌 경우 해당 흐름에 플래그를 지정합니다. 예를 들어 부서 A의 환경에는 부서 A의 사용자만 포함되어야 하지만 부서 B의 공동 소유자가 표시되는 경우 해당 흐름은 외부인과 공유됩니다. 세부 정보를 보거나 환경의 사용자 디렉터리와 상호 참조하려면 소유자의 이름을 선택해야 할 수 있습니다.
Power Platform 관리 센터의 장점—GUI 메서드
Power Platform 관리 센터는 사용자에게 친숙한 인터페이스를 제공하며 이름 또는 소유자별로 흐름을 필터링하고 정렬할 수 있습니다. 환경에 속한 팀과 사용자를 알면 명백한 불일치를 빠르게 발견할 수 있습니다.
Power Platform 관리 센터의 단점—GUI 메서드
이 방법은 수동이며 많은 흐름에 대해 잘 확장되지 않습니다. 소유자를 개별적으로 확인해야 하므로 대규모 환경에서는 시간이 많이 걸릴 수 있습니다. 사용자 인터페이스에서 직접 환경 멤버 자격을 교차 확인하는 것은 어려울 수 있습니다.
PowerShell 스크립트 - 자동화된 방법
체계적이고 반복 가능한 감사를 위해 Power Automate는 흐름과 해당 소유자를 나열하는 관리 PowerShell cmdlet을 제공합니다. 이 접근 방식은 대규모 환경 또는 전체 테넌트에 대한 대량 분석에 강력합니다. 모든 흐름을 출력하고 외부 공유를 강조 표시하도록 프로세스를 스크립팅할 수 있습니다.
예를 들어, 이 스크립트는 Get-AdminFlow
를 사용하여 모든 흐름을 검색한 다음, 각 흐름에 대해 Get-AdminFlowOwnerRole
을 사용하여 소유자와 역할을 나열합니다. 출력에는 각 흐름 이름과 Owner: [User]
, Role: [Owner/Co-owner]
라는 항목이 나열됩니다. 이 출력을 파일로 리디렉션하거나 추가로 처리할 수 있습니다.
다음으로, 외부 공유 결정: 각 소유자의 UPN(사용자 계정 이름)을 환경의 구성원인 사용자 집합과 비교합니다. 외부 공유는 UPN이 환경의 사용자 목록 또는 보안 그룹에 없는 모든 소유자에 의해 표시됩니다. 실제로 다음과 같은 작업을 수행할 수 있습니다.
- 이전 스크립트 및 환경 사용자 목록에서 흐름 소유자 목록을 내보낸 다음 Excel 또는 스크립트를 사용하여 차이점을 찾거나
-
Get-AdminEnvironmentUser
를 통해 환경 사용자에 대한 교차 검사를 수행하도록 PowerShell 스크립트를 향상시킵니다.
PowerShell 스크립트의 장점 - 자동화된 방법
이 방법은 자동화되고 포괄적입니다. 수백 또는 수천 개의 흐름을 빠르게 열거할 수 있으며 보고를 위해 스크립팅할 수 있습니다. 매월과 같은 일정에 따라 실행하여 새로운 외부 공유를 찾을 수 있습니다.
PowerShell 스크립트의 단점 - 자동화된 방법
PowerShell 및 관리자 권한에 대해 잘 알고 있어야 합니다. 또한 원시 출력에는 UPN 및 개체 ID가 표시됩니다. 환경 외부에 있는 항목을 판단해야 하며 몇 가지 분석이 필요합니다. 그러나 환경의 사용자 도메인을 알고 있거나 환경 구성원 목록이 있는 경우에는 간단합니다.
CoE(Center of Excellence) 툴킷—대시보드 메서드
조직에서 Power Platform Center of Excellence 시작 키트를 사용하는 경우 공유 메트릭이 포함된 Power BI 대시보드 및 보고서가 제공됩니다. CoE의 흐름 인벤토리는 게스트 소유자 또는 환경의 일반 보안 그룹 외부에 있는 소유자가 있는 흐름을 강조 표시할 수 있습니다. 예를 들어, CoE 대시보드에는 여러 소유자가 있는 흐름 또는 게스트 사용자와 공유된 흐름에 대한 보고서가 있을 수 있습니다. 이러한 인사이트를 활용하여 비정상적인 공유가 있는 흐름을 찾을 수 있습니다.
CoE(Center of Excellence) Toolkit의 장점 - 대시보드 방법
이미 환경 데이터를 집계하고 있을 수 있는 중앙 집중식 시각적 보고. CoE가 있는 경우 추가 스크립팅이 없습니다. 비준수 패턴에 자동으로 플래그를 지정할 수 있습니다.
CoE(Center of Excellence) 도구 키트의 단점 - 대시보드 방법
CoE 시작 키트를 배포하고 최신 상태로 유지해야 합니다. 데이터는 실시간이 아닐 수 있습니다(일반적으로 일정에 따라 새로 고쳐집니다). 또한 외부 도메인 사용자 식별과 같은 사용자 지정 필터를 설정하려면 CoE 구성 요소를 조정해야 할 수 있습니다.
식별 방법 비교
방법 | 도구/접근 방식 | 장점 | 단점 |
---|---|---|---|
관리 센터(GUI) | Power Platform 관리 센터 웹 인터페이스: 흐름 및 소유자를 시각적으로 확인합니다. | 쉽고 사용자 친화적인 인터페이스. 적은 수의 흐름에 대한 즉각적인 통찰력. | 수동 확인, 대규모 환경에서는 효과적으로 확장할 수 없습니다. 소유자와 환경 멤버 자격에 대한 기본 제공 상호 참조가 없습니다. |
PowerShell 스크립트 | 관리자 PowerShell cmdlets(Get-AdminFlow , Get-AdminFlowOwnerRole ). |
흐름 및 소유자의 자동화된 대량 출력. 예약하고 결과를 CSV 또는 다른 형식으로 내보낼 수 있습니다. 환경 사용자 목록을 알고 있는 경우 정확도가 높습니다. | PowerShell 지식이 필요합니다. 외부 소유자를 별도로 식별해야 합니다. 스크립트 또는 사후 처리가 필요합니다. |
CoE 도구 키트(대시보드) | Power BI 대시보드 및 CoE 흐름. | CoE가 설치된 경우 이미 사용할 수 있습니다. 중앙 집중식 보고서에서 외부 또는 게스트 소유자와 같은 비정상적인 공유를 강조 표시할 수 있습니다. | CoE 배포 및 유지 관리가 필요합니다. 데이터 새로 고침 지연(실시간이 아님)이 있습니다. 특정 외부 사용자를 정확히 찾아내기 위해 사용자 지정이 필요할 수 있습니다. |
이전 표에 있는 방법 중 하나 또는 조합을 사용하여 외부 공유 사용자가 있는 흐름 목록을 컴파일합니다. 정책 변경 전에 주의가 필요한 영향을 받는 흐름입니다. 많은 조직에서 이는 관리 가능한 흐름의 하위 집합일 수 있습니다(예: 몇 개의 부서 간 흐름 또는 파트너의 게스트 계정과 공유되는 흐름). 다른 경우, 특히 개방형 공유 관행을 사용하는 테넌트의 경우 처리해야 할 흐름이 상당히 많을 수 있으므로 이를 일찍 파악하는 것이 좋습니다.
영향을 받는 흐름에 대한 공유 및 액세스 조정
환경 외부의 사용자와 공유되는 흐름을 식별한 후 다음 단계는 각 흐름의 공유 구성을 수정하는 것입니다. 목표는 흐름에 액세스해야 하는 모든 사용자가 환경에 제대로 추가되도록(또는 흐름의 액세스가 수정되도록) 하는 것입니다. 이렇게 하면 새 적용이 시작될 때 아무도 기능을 잃지 않습니다. 다음 섹션에서는 조정에 접근하는 방법에 대해 설명합니다.
각 외부 공유의 필요성 평가
플래그가 지정된 각 흐름에 대해 흐름의 소유자 또는 관련 비즈니스 팀과 외부와 공유된 이유에 대해 논의합니다. 이 컨텍스트는 수정 사항을 결정하는 데 중요합니다. 다음 목록에서는 일반적인 시나리오 및 작업에 대해 설명합니다.
- 시나리오 1: 흐름을 실행하거나 출력을 보기 위해 사용자가 공동 소유자로 추가된 경우: 대부분의 경우 외부 사용자가 흐름을 트리거하거나 사용하기만 하면 되는 경우(편집이 아님) 소유자가 외부 사용자를 소유자로 추가했습니다. 예를 들어 소유자는 헬프데스크 에이전트를 흐름의 공동 소유자로 추가하여 에이전트가 수동으로 트리거할 수 있도록 할 수 있습니다. 이러한 경우 사용자에게 전체 소유자 권한이 필요하지 않을 수 있습니다.
- 작업: 소유자 목록에서 제거하고 대신 환경 액세스 권한이 있는지 확인한 후 실행 전용 사용자(해당하는 경우)로 흐름을 공유합니다. 이렇게 하면 소유자로 만들지 않고 흐름을 실행하는 데 필요한 기능이 제공됩니다. 이 문서의 환경에 필요한 사용자 추가 섹션에서 자세히 알아보세요.
- 시나리오 2: 사용자가 흐름을 작성하거나 유지 관리하는 데 진정으로 협력하는 경우: 예를 들어, 두 부서가 공동으로 흐름을 개발하여 부서 B의 사용자가 부서 A의 환경에서 공동 소유자가 되었습니다.
- 작업: 해당 사용자를 적절한 역할을 가진 소유자로 환경에 온보딩하거나, 여러 조직 단위가 흐름을 공동 소유해야 하는 경우 흐름을 중립 환경으로 이동하는 것이 좋습니다. 단기적으로는 사용자를 환경의 허용된 사용자 목록에 추가하고 적절한 역할(편집 권한이 필요한 경우 환경 제작자)을 부여하면 액세스 문제가 해결됩니다.
- 시나리오 3: 공유가 더 이상 필요하지 않음: 사용자가 임시로 추가되거나 프로젝트를 떠나는 경우가 있습니다.
- 작업: 흐름의 공유에서 외부 사용자를 제거합니다. 해당하는 경우 가장 간단한 수정 사항입니다. 환경 외부에 흐름이 필요한 사람이 없는 경우 공유를 취소합니다. 그러면 흐름이 규정을 준수하고 내부 소유자만 남게 됩니다.
- 시나리오 4: 테넌트 간 또는 게스트 사용자 공유: 예를 들어 흐름이 게스트(외부 테넌트) 계정과 공유되었습니다. 이는 적용 후 차단됩니다.
- 작업: 해당 게스트가 반드시 액세스해야 하는지 확인합니다. 그렇다면 한 가지 옵션은 해당 게스트를 테넌트 및 환경의 보안 그룹에 Azure AD 게스트로 공식적으로 추가하는 것입니다. 이렇게 하면 환경 구성원이 됩니다. 이는 드문 경우입니다. 또는 게스트를 대신하여 작업할 수 있는 내부 사용자에게 소유권을 이전하거나 직접 공유가 아닌 보안 HTTP 트리거를 통해 흐름을 노출하는 것과 같은 다른 메커니즘을 사용합니다. 환경 구성원으로 추가되더라도 테넌트 간 문제가 발생할 수 있으므로 직접 게스트 공유를 제거하는 것이 좋습니다.
환경에 필요한 사용자 추가
흐름에 계속 액세스할 수 있어야 하는 각 사용자에 대해 앞으로 환경의 구성원인지 확인합니다. 이는 일반적으로 다음을 의미합니다.
환경에서 보안 그룹을 사용하는 경우: 해당 Azure AD 보안 그룹에 사용자의 계정을 추가합니다. 이렇게 하면 달리 구성되지 않는 한 환경에서 기본 사용자 역할이 부여됩니다. 기본 사용자 역할은 일반적으로 흐름을 만들고 편집하지 않고 실행만 하면 되는 사용자에게 충분합니다. 추가한 후 이제 사용자가 Power Platform 관리 센터의 환경 사용자 목록에 표시되는지 확인합니다.
모든 사용자에게 열려 있는 테넌트 기본 환경인 경우: 라이선스가 있는 대부분의 사용자가 이미 이 환경에 있습니다. 사용자에게 Power Automate 라이선스가 있는지 확인하세요. 적용은 주로 구성원 자격이 제한된 기본이 아닌 환경에 영향을 줍니다.
환경 제작자와 기본 사용자: 사용자가 실제로 해당 환경에서 흐름을 빌드하고 편집해야 하는 경우가 아니면 환경 제작자를 부여하지 마세요. 수정 사항에서는 기본 사용자만 제공하거나 공유 흐름을 실행할 수 있는 사용자 지정 최소 역할을 제공하는 것이 좋습니다. 실행 전용 액세스의 경우 기본 사용자로 충분하며 사용자가 제작자일 필요는 없습니다. 제작자 역할을 제한하는 것은 거버넌스 모범 사례이며 다음 섹션에서 자세히 설명합니다.
흐름의 공유 설정 조정
이제 사용자가 환경 구성원이 되면 흐름이 공유되는 방식을 조정합니다.
사용자가 흐름을 실행하기만 하면 되는 경우: 실행 전용 공유를 사용합니다. Power Automate에서 흐름의 공유 설정을 엽니다. 소유자 목록에서 사용자를 제거하고 실행 전용 사용자 섹션에서 해당 이름을 추가합니다. 버튼 흐름 및 인스턴트 흐름과 같이 수동으로 트리거된 흐름 또는 공유 가능한 링크로 트리거된 흐름의 경우 이렇게 하면 사용자가 소유자가 아니어도 흐름을 트리거할 수 있습니다. 흐름의 내부를 편집하거나 표시할 수 없으며 실행만 할 수 있습니다. 그 결과 사용자는 소유자 목록 외부에 남아 있으므로 환경 충돌이 없지만 흐름의 기능을 의도한 대로 사용할 수 있습니다.
예: 마케팅 부서의 Bob은 영업의 잠재 고객 프로세서 흐름의 공동 소유자였으며 주기적으로 이를 시작했습니다. Bob을 공동 소유자 smf에서 제거하고 Bob을 실행 전용 사용자로 추가합니다. 또한 Bob은 Sales 환경에 기본 사용자로 추가됩니다. 이제 Bob은 흐름의 버튼을 선택하거나 흐름을 실행하기 위한 링크를 받을 수 있지만 더 이상 외부 소유자가 아니라 해당 환경의 승인된 기본 사용자입니다.
사용자에게 전체 소유자 권한(공동 작성)이 필요한 경우: 환경에 추가한 후 흐름에서 소유자로 나열되어 있는지 확인합니다. 기술적으로 권한을 새로 고치기 위해 제거했다가 다시 추가할 수 있습니다. 그러나 일단 환경에 있으면 공유는 합법적입니다. 서로 다른 지역의 두 소유자가 장기적으로 유지 관리하는 경우 흐름을 솔루션으로 이동하는 것도 고려할 수 있습니다. 솔루션 흐름은 필요한 경우 전용 환경으로 더 쉽게 전송할 수 있습니다. 어떤 경우든 소유자 아래에 표시되고 흐름의 세부 정보에서 해당 역할이 편집 가능(소유자)인지 다시 확인합니다.
중복되거나 승인되지 않은 공유 제거: 이 프로세스 중에 정리할 기회를 이용하십시오. 누군가 경우에 따라 추가되었지만 흐름을 사용하지 않는 경우 제거합니다. 최소 권한의 원칙은 감독을 줄이는 데 도움이 됩니다. 각 흐름의 소유자 목록은 디자인 및 편집 액세스 권한이 정말로 필요한 사용자로 제한되어야 합니다.
영향을 받는 사용자에게 변경 내용 전달
다른 사용자의 액세스 권한을 제거하거나 흐름을 호출하는 방법을 변경하는 경우 해당 사용자에게 알려주세요. 사용자 관점에서 실행 전용 액세스를 통해 흐름을 실행하는 것은 약간 다를 수 있습니다. 공유 링크를 받거나 내 흐름 대신 팀 흐름에서 흐름을 볼 수 있습니다. "새로운 Power Automate 정책을 준수하기 위해 Flow X의 공유 방법을 업데이트했습니다. 메서드 Y를 사용하여 계속 실행할 수 있지만 더 이상 직접 소유권으로 표시되지 않습니다."라고 설명합니다. 이렇게 하면 혼란을 방지할 수 있습니다.
사후 조정 상태 확인
변경한 후 PowerShell 또는 Power Platform 관리 센터를 사용하여 외부 소유자에게 남아 있는 흐름이 없는지 다시 확인합니다. 예를 들어 식별 스크립트를 다시 실행하고 더 이상 해당 흐름에 플래그를 지정하지 않는지 확인합니다. 플래그가 지정된 각 인스턴스를 제거 또는 적절한 환경 멤버 자격으로 해결합니다.
이러한 조정을 수행하면 Microsoft가 스위치를 전환할 때 해당 흐름이 의도한 사용자에 대해 계속 실행되도록 할 수 있습니다. 오류 you do not have access to this flow
대신 사용자는 이제 적절한 역할로 환경 구성원이므로 권한이 유지됩니다. 기본적으로, 공유 관행을 플랫폼의 거버넌스 모델에 맞추는 것입니다.