다음을 통해 공유

ID 및 액세스 관리 권장 사항

  • 아티클

이 Power Platform Well-Architected Security 체크리스트 권장 사항에 적용됩니다.

남동:05 모든 워크로드 사용자, 팀 구성원, 시스템 구성 요소 전반에 걸쳐 엄격하고 조건부이며 감사 가능한 ID 및 액세스 관리(IAM)를 구현합니다. 필요한 경우에만 액세스를 제한하세요. 모든 인증 및 권한 부여 구현에 최신 산업 표준을 사용합니다. 신원을 기반으로 하지 않는 액세스를 제한하고 엄격하게 감사합니다.

이 가이드에서는 워크로드 리소스에 액세스하려고 시도하는 ID를 인증하고 승인하기 위한 권장 사항을 설명합니다.

기술적인 통제 측면에서 볼 때, ID는 항상 기본 경계선입니다. 이 범위에는 워크로드의 에지만 포함되지 않습니다. 또한 워크로드 내부에 있는 개별 구성 요소도 포함됩니다.

일반적인 ID는 다음과 같습니다.

  • 인간. 애플리케이션 사용자, 관리자, 운영자, 감사자 및 악의적인 공격자.
  • 시스템. 워크로드 ID, 관리 ID, API 키, 서비스 주체 및 Azure 리소스.
  • 익명. 자신이 누구인지에 대한 어떠한 증거도 제공하지 않은 엔터티.

정의

용어 정의
인증(AuthN) ID가 누구인지 또는 무엇인지 확인하는 프로세스입니다.
인증(AuthZ) ID에 요청된 작업을 수행할 수 있는 권한이 있는지 확인하는 프로세스입니다.
조건부 액세스 지정된 기준에 따라 작업을 허용하는 규칙 집합입니다.
IdP ID 공급자(예: Microsoft Entra ID).
가상 사용자 일련의 책임과 활동이 있는 직무 기능 또는 직함입니다.
사전 공유 키 공급자와 소비자 간에 공유되고 합의된 보안 메커니즘을 통해 사용되는 비밀 유형입니다.
리소스 ID 플랫폼에서 관리하는 클라우드 리소스에 대해 정의된 ID입니다.
역할 사용자 또는 그룹이 수행할 수 있는 작업을 정의하는 권한 집합입니다.
Scope 역할 운영이 허용되는 다양한 수준의 조직 계층입니다. 또한 시스템의 기능 그룹입니다.
보안 주체 권한을 제공하는 ID입니다. 사용자, 그룹 또는 서비스 주체일 수 있습니다. 모든 그룹 구성원은 동일한 수준의 액세스 권한을 갖습니다.
사용자 ID 직원이나 외부 사용자와 같은 개인의 ID입니다.
워크로드 ID 다른 서비스 및 리소스에 대해 자신을 인증하는 데 사용되는 애플리케이션, 서비스, 스크립트, 컨테이너 또는 워크로드의 기타 구성 요소에 대한 시스템 ID입니다.

참고

ID는 보안 주체라는 상위 항목 아래 유사한 다른 ID와 그룹화될 수 있습니다. 보안 그룹은 보안 주체의 예입니다. 이 계층적 관계는 유지 관리를 단순화하고 일관성을 향상시킵니다. ID 특성은 개인 수준에서 처리되지 않으므로 오류 가능성도 줄어듭니다. 이 문서에서 ID라는 용어에는 보안 주체가 포함됩니다.

Power Platform의 ID 공급자인 Microsoft Entra ID

모든 Power Platform 제품은 ID 및 액세스 관리를 위해 Microsoft Entra ID(이전의 Azure Active Directory 또는 Azure AD)를 사용합니다. Entra ID를 사용하면 조직은 하이브리드 및 멀티클라우드 환경의 ID를 보호하고 관리할 수 있습니다. Entra ID는 Power Platform 리소스에 액세스해야 하는 비즈니스 게스트를 관리하는 데에도 필수적입니다. 또한 Power Platform은 Entra ID를 사용하여 서비스 주체 기능을 사용하여 Power Platform API와 통합해야 하는 다른 애플리케이션을 관리합니다. Entra ID를 사용하여 Power Platform은 조건부 액세스 및 지속적인 액세스 권한 평가와 같은 Entra ID 고급 보안 기능을 활용할 수 있습니다.

인증

인증은 ID를 확인하는 프로세스입니다. 요청하는 ID는 확인 가능한 신원 확인 양식을 제공해야 합니다. 예:

  • 사용자 이름 및 암호.
  • 액세스 권한을 부여하는 API 키와 같은 사전 공유 비밀입니다.
  • SAS(공유 액세스 서명) 토큰.
  • TLS(전송 계층 보안) 상호 인증에 사용되는 인증서입니다.

Power Platform 인증에는 사용자의 브라우저와Power Platform 또는 Azure 서비스 간 요청 시퀀스, 응답 및 리디렉션을 포함합니다. 시퀀스는 Microsoft Entra ID 인증 코드 부여 흐름을 따릅니다.

데이터 원본에 연결하고 인증하는 것은 Power Platform 서비스에 대한 인증과 별개로 수행됩니다. 자세한 정보는 데이터 원본에 연결 및 인증을 참고하세요.

권한 부여

Power Platform 모든 API 호출의 권한 부여를 위해 업계 표준인 Microsoft Entra 2.0 프로토콜을 사용하여 Microsoft ID Identity Platform OAuth 을 사용합니다.

주요 디자인 전략

워크로드에 대한 ID 요구 사항을 이해하려면 사용자 및 시스템 흐름, 워크로드 자산, 가상 사용자와 이들이 수행할 작업을 나열해야 합니다.

각 사용 사례에는 위반을 가정하는 사고방식으로 설계해야 하는 고유한 컨트롤 집합이 있을 수 있습니다. 사용 사례 또는 가상 사용자의 ID 요구 사항을 기반으로 조건부 선택을 식별합니다. 모든 사용 사례에 하나의 솔루션을 사용하지 마십시오. 반대로 컨트롤이 너무 세분화되어 불필요한 관리 오버헤드가 발생해서는 안 됩니다.

ID 액세스 추적을 기록해야 합니다. 이렇게 하면 컨트롤을 검증하는 데 도움이 되며 규정 준수 감사에 로그를 사용할 수 있습니다.

인증을 위한 모든 ID 확인

외부에서 내부로 접근 가능 Power Platform 인증에는 사용자의 브라우저와Power Platform 또는 Azure 서비스 간 요청 시퀀스, 응답 및 리디렉션을 포함합니다. 시퀀스는 Microsoft Entra ID 인증 코드 부여 흐름을 따릅니다. Power Platform은 다양한 목적으로 워크로드에 액세스하는 모든 사용자를 자동으로 인증합니다.

안에서 밖으로 접근 가능 워크로드는 다른 리소스에 액세스해야 합니다. 예를 들어 데이터 플랫폼에서 읽거나 쓰고, 비밀 저장소에서 비밀을 검색하고, 모니터링 서비스에 원격 분석을 기록합니다. 타사 서비스에 액세스해야 할 수도 있습니다. 이는 모두 워크로드 ID 요구 사항입니다. 그러나 리소스 ID 요구 사항도 고려해야 합니다. 예를 들어 배포 파이프라인이 실행되고 인증되는 방법입니다.

승인을 위한 작업 결정

다음으로, 해당 작업이 승인될 수 있도록 인증된 각 ID가 수행하려는 작업이 무엇인지 알아야 합니다. 작업은 필요한 액세스 유형에 따라 분류될 수 있습니다.

  • 데이터 플레인 액세스. 데이터 평면에서 발생하는 작업으로 인해 데이터 전송이 발생합니다. 예를 들어 애플리케이션이 Microsoft Dataverse에서 데이터를 읽거나 쓰거나 Application Insights에 로그를 씁니다.

  • 제어 평면 액세스. 컨트롤 플레인에서 수행되는 작업으로 인해 Power Platform 리소스가 생성, 수정 또는 삭제됩니다. 예를 들어 환경 속성을 수정하거나 데이터 정책을 생성합니다.

애플리케이션은 일반적으로 데이터 평면 작업을 대상으로 하지만 작업은 컨트롤 플레인과 데이터 평면 모두에 액세스하는 경우가 많습니다.

역할 기반 권한 제공

각 ID의 책임에 따라 허용되어야 하는 작업을 승인합니다. 하나의 정체성은 필요 이상의 기능을 하도록 허용되어서는 안 됩니다. 권한 부여 규칙을 설정하기 전에 누가 또는 무엇을 요청하는지, 해당 역할이 무엇을 할 수 있는지, 어느 정도까지 할 수 있는지를 명확하게 이해해야 합니다. 이러한 요소는 ID, 역할, 범위를 결합한 선택으로 이어집니다.

다음을 고려하십시오.

  • 워크로드에 읽기 및 쓰기 액세스 모두에 대해 Dataverse에 대한 데이터 평면 액세스 권한이 있어야 합니까?
  • 워크로드에도 환경 속성에 대한 액세스가 필요합니까?
  • 악의적인 공격자에 의해 ID가 손상되면 기밀성, 무결성 및 가용성 측면에서 시스템에 어떤 영향을 미치게 됩니까?
  • 워크로드에 영구 액세스가 필요합니까, 아니면 조건부 액세스를 고려할 수 있습니까?
  • 워크로드가 관리/상승된 권한이 필요한 작업을 수행합니까?
  • 워크로드는 타사 서비스와 어떻게 상호 작용합니까?
  • 부조종사의 경우 SSO(Single Sign-On) 요구 사항이 있습니까?
  • 조종사가 인증되지 않은 모드, 인증된 모드, 아니면 둘 다로 작동하고 있습니까?

역할 할당

역할은 ID에 할당된 권한 집합입니다. ID가 작업을 완료하도록 허용하는 역할만 할당하고 그 이상은 허용하지 않습니다. 사용자의 권한이 작업 요구 사항으로 제한되면 시스템에서 의심스럽거나 승인되지 않은 동작을 식별하는 것이 더 쉽습니다.

다음과 같이 질문합니다.

  • 읽기 전용 액세스만으로 충분합니까?
  • ID에 리소스를 삭제하려면 권한이 필요합니까?
  • 역할은 자신이 생성한 레코드에만 액세스하면 됩니까?
  • 사용자가 속한 사업부에 따른 계층적 액세스 권한이 필요합니까?
  • 역할에 관리 권한이나 상승된 권한이 필요합니까?
  • 역할에 이러한 권한에 대한 영구적인 액세스가 필요합니까?
  • 사용자가 직업을 바꾸면 어떻게 되나요?

사용자, 애플리케이션 또는 서비스의 액세스 수준을 제한하면 잠재적인 공격 표면이 줄어듭니다. 특정 작업을 수행하는 데 필요한 최소한의 권한만 부여하면 공격이 성공하거나 무단 액세스가 발생할 위험이 크게 줄어듭니다. 예를 들어 개발자는 개발 환경에 대한 제작자 액세스 권한만 필요하지만 프로덕션 환경에는 필요하지 않습니다. 리소스를 만들기 위한 액세스 권한만 필요하지만 환경 속성을 변경할 수는 없습니다. Dataverse에서 데이터를 읽고 쓸 때만 액세스하면 되지만 Dataverse 테이블의 데이터 모델 또는 특성은 변경할 수 없습니다.

개별 사용자를 대상으로 하는 권한을 피하세요. 세분화된 사용자 지정 권한은 복잡성과 혼란을 야기하며 사용자가 역할을 변경하고 비즈니스 전반에 걸쳐 이동하거나 유사한 인증 요구 사항을 가진 새로운 사용자가 팀에 합류함에 따라 유지 관리가 어려워질 수 있습니다. 이러한 상황은 유지 관리가 어렵고 보안과 안정성 모두에 부정적인 영향을 미치는 복잡한 레거시 구성을 만들 수 있습니다.

트레이드오프: 세부적인 액세스 제어 접근 방식을 통해 사용자 활동에 대한 감사 및 모니터링을 개선할 수 있습니다.

가장 낮은 권한부터 시작하여 운영 또는 데이터 액세스 요구 사항에 따라 더 많은 권한을 추가하는 역할을 부여하세요. 기술팀은 권한을 구현하기 위한 명확한 지침을 갖고 있어야 합니다.

조건부 액세스 선택

모든 ID에 동일한 수준의 액세스 권한을 부여하지 마십시오. 두 가지 주요 요소를 바탕으로 결정을 내립니다.

  • 시간. ID가 환경에 액세스할 수 있는 기간입니다.
  • 권한. 사용 권한 수준입니다.

이러한 요소는 상호 배타적이지 않습니다. 더 많은 권한과 무제한 액세스 기간을 가진 손상된 ID는 시스템과 데이터에 대한 더 많은 제어권을 얻거나 해당 액세스를 사용하여 환경을 계속 변경할 수 있습니다. 예방 조치와 폭발 반경 제어를 위해 이러한 접근 요소를 제한합니다.

JIT(Just in Time) 방식은 필요한 경우에만 필요한 권한을 제공합니다.

Just Enough Access(JEA) 는 필요한 권한만 제공합니다.

시간과 특권이 주요 요소이기는 하지만 적용되는 다른 조건도 있습니다. 예를 들어 액세스가 시작된 장치, 네트워크 및 위치를 사용하여 정책을 설정할 수도 있습니다.

사용자 신원 및 위치, 기기 상태, 워크로드 컨텍스트, 데이터 분류, 이상 현상과 같은 매개변수를 포함하여 승인되지 않은 액세스를 필터링, 감지, 차단하는 강력한 제어 기능을 사용합니다.

예를 들어 공급업체, 파트너, 고객과 같은 타사 ID가 워크로드에 액세스해야 할 수 있습니다. 상근 직원에게 제공하는 기본 권한이 아닌 적절한 수준의 액세스 권한이 필요합니다. 외부 계정을 명확하게 구분하면 이러한 벡터에서 발생하는 공격을 더 쉽게 예방하고 탐지할 수 있습니다.

심각한 영향 계정

관리 ID는 수행하는 작업을 위해 광범위한 시스템 및 애플리케이션에 대한 권한 있는 액세스가 필요하기 때문에 가장 큰 영향을 미치는 보안 위험 중 일부를 초래합니다. 손상이나 오용은 귀하의 비즈니스와 정보 시스템에 해로운 영향을 미칠 수 있습니다. 관리 보안은 가장 중요한 보안 영역 중 하나입니다.

단호한 공격자로부터 권한 있는 액세스를 보호하려면 이러한 시스템을 위험으로부터 격리하기 위한 완전하고 사려 깊은 접근 방식을 취해야 합니다. 다음 몇 가지 전략을 참조하십시오.

  • 중요한 영향을 미치는 계정의 수를 최소화합니다.

  • 기존 ID에 대한 권한을 승격하는 대신 별도의 역할을 사용하세요.

  • IdP의 JIT 기능을 사용하여 영구적 또는 지속적인 접근을 방지하세요. 방어 기능이 깨지는 상황의 경우 비상 액세스 절차를 따르세요.

  • 비밀번호 없는 인증이나 다중 요소 인증과 같은 최신 액세스 프로토콜을 사용하세요. 이러한 메커니즘을 IdP에 외부화합니다.

  • 조건부 액세스 정책을 사용하여 주요 보안 특성을 시행합니다.

  • 사용하지 않는 관리 계정 을 해제하세요.

ID 수명 주기를 관리하는 프로세스 확립

ID에 대한 액세스는 ID가 액세스하는 리소스보다 오래 지속되어서는 안 됩니다. 팀 구조나 소프트웨어 구성 요소가 변경된 경우 ID를 비활성화하거나 삭제하는 프로세스가 있는지 확인하십시오.

이 지침은 소스 제어, 데이터, 컨트롤 플레인, 워크로드 사용자, 인프라, 도구, 데이터 모니터링, 로그, 메트릭 및 기타 엔터티에 적용됩니다.

디지털 ID, 권한이 높은 사용자, 외부/게스트 사용자 및 워크로드 사용자의 수명 주기를 관리하기 위해 ID 거버넌스 프로세스를 수립합니다. ID가 조직이나 팀을 떠날 때 해당 워크로드 권한이 제거되도록 액세스 검토를 구현합니다.

비ID 기반 비밀 보호

사전 공유 키와 같은 애플리케이션 비밀은 시스템의 취약한 지점으로 간주되어야 합니다. 양방향 통신에서 공급자나 소비자가 손상되면 심각한 보안 위험이 발생할 수 있습니다. 이러한 키는 운영 프로세스를 도입하기 때문에 부담스러울 수도 있습니다.

이러한 비밀을 비밀 저장소에서 동적으로 가져올 수 있는 엔터티로 취급합니다. 앱, 흐름, 배포 파이프라인 또는 기타 아티팩트에 하드 코딩하면 안 됩니다.

비밀을 취소할 수 있는 기능이 있는지 확인하세요.

키 교체 및 만료와 같은 작업을 처리하는 운영 방식을 적용합니다.

교체 정책에 대한 자세한 내용은 두 개의 인증 자격 증명 집합이 있는 리소스에 대한 비밀 교체 자동화 및 자습서: Key Vault에서 인증서 자동 교체 빈도 업데이트를 참조하세요.

개발 환경을 안전하게 유지

개발자 환경에 대한 쓰기 액세스는 제한되어야 하며, 소스 코드에 대한 읽기 액세스는 알아야 할 역할에 따라 제한되어야 합니다. 정기적으로 리소스를 검사하고 최신 취약점을 식별하는 프로세스가 있어야 합니다.

감사 추적 유지

ID 관리의 한 가지 측면은 시스템을 감사할 수 있도록 보장하는 것입니다. 감사는 위반 가정 전략이 효과적인지 여부를 검증합니다. 감사 추적을 유지하면 다음과 같은 이점이 있습니다.

  • 강력한 인증을 통해 ID가 인증되었는지 확인하세요. 거부 공격을 방지하기 위해 모든 작업은 추적 가능해야 합니다.

  • 약하거나 누락된 인증 프로토콜을 감지하고 사용자 및 애플리케이션 로그인에 대한 가시성과 통찰력을 확보하세요.

  • 보안 및 규정 준수 요구 사항을 기반으로 ID에서 워크로드에 대한 액세스를 평가하고 사용자 계정 위험, 장치 상태, 기타 설정한 기준 및 정책을 고려합니다.

  • 규정 준수 요구 사항과의 진행 상황이나 편차를 추적합니다.

대부분의 리소스에는 데이터 평면 액세스 권한이 있습니다. 리소스에 액세스하는 ID와 리소스가 수행하는 작업을 알아야 합니다. 해당 정보를 보안 진단에 사용할 수 있습니다.

Power Platform 간편 사용

Power Platform 액세스 제어는 전체 보안 아키텍처의 중요한 부분입니다. 액세스 제어 지점은 올바른 사용자가 Power Platform 리소스에 대한 액세스 권한을 얻도록 할 수 있습니다. 이 섹션에서는 구성할 수 있는 다양한 액세스 포인트와 전반적인 보안 전략에서 해당 액세스 포인트의 역할을 살펴보겠습니다.

Microsoft Entra ID

모든 Power Platform 제품은 ID 및 액세스 관리를 위해 Microsoft Entra ID(이전의 Azure Active Directory 또는 Azure AD)를 사용합니다. Entra ID를 사용하면 조직은 하이브리드 및 멀티클라우드 환경의 ID를 보호하고 관리할 수 있습니다. Entra ID는 Power Platform 리소스에 액세스해야 하는 비즈니스 게스트를 관리하는 데에도 필수적입니다. 또한 Power Platform은 Entra ID를 사용하여 서비스 주체 기능을 사용하여 Power Platform API와 통합해야 하는 다른 애플리케이션을 관리합니다. Entra ID를 사용하여 Power Platform은 조건부 액세스 및 지속적인 액세스 권한 평가와 같은 Entra ID 고급 보안 기능을 활용할 수 있습니다.

클라우드 컴퓨팅 시스템의 다이어그램.

라이선스 할당

Power Apps 및 Power Automate에 대한 액세스는 라이선스를 갖는 것으로 시작됩니다. 사용자가 액세스할 수 있는 자산 및 데이터는 사용자가 보유한 라이선스 유형에 따라 결정됩니다. 다음 표에서는 계획 유형에 따라 사용자가 사용할 수 있는 리소스의 차이를 개략적으로 설명합니다. 세분화된 라이선스 세부 정보는 라이선싱 개요에서 찾을 수 있습니다.

조건부 액세스 정책

조건부 액세스는 액세스 결정에 대한 정책 을 설명합니다. 조건부 액세스를 사용하려면 사용 사례에 필요한 제한 사항을 이해해야 합니다. 운영 요구 사항에 따라 액세스 정책을 설정하여 Microsoft Entra 조건부 액세스를 구성하세요.

자세한 내용은 다음을 참조하세요.

지속적인 액세스

액세스를 취소해야 하는지 결정하기 위해 특정 이벤트를 평가할 때 지속적인 액세스가 가속화됩니다. 기존에는 OAuth 2.0 인증을 사용할 경우 토큰 갱신 중에 확인이 완료되면 액세스 토큰 만료가 발생합니다. 지속적인 액세스를 통해 사용자의 중요한 이벤트 및 네트워크 위치 변경을 지속적으로 평가하여 사용자가 계속 액세스를 유지해야 하는지 결정합니다. 이러한 평가로 인해 활성 세션이 조기 종료되거나 재인증이 필요할 수 있습니다. 예를 들어 사용자 계정이 비활성화되면 해당 사용자는 앱에 액세스할 수 없게 됩니다. 위치도 중요합니다. 예를 들어 토큰은 신뢰할 수 있는 위치에서 인증을 받았지만 사용자가 신뢰할 수 없는 네트워크로 연결을 변경했을 수 있습니다. 지속적인 액세스는 조건부 액세스 정책 평가를 호출하고 사용자는 더 이상 승인된 위치에서 연결되지 않기 때문에 액세스 권한을 잃게 됩니다.

현재 Power Platform에서는 Dataverse만 지속적인 액세스 권한 평가를 지원합니다. Microsoft 다른 Power Platform 서비스와 클라이언트에 대한 지원을 추가하기 위해 노력하고 있습니다. 자세한 내용은 지속적인 액세스 권한 평가를 참조하십시오.

하이브리드 작업 모델이 지속적으로 채택되고 클라우드 애플리케이션이 사용되면서 Entra ID는 사용자와 리소스를 보호하기 위한 중요한 기본 보안 경계가 되었습니다. 조건부 액세스는 해당 경계를 네트워크 경계 이상으로 확장하여 사용자 및 장치 ID를 포함합니다. 지속적인 액세스를 통해 이벤트나 사용자 위치가 변경되면 액세스가 재평가됩니다. Power Platform에서 Entra ID를 사용하면 애플리케이션 포트폴리오 전체에 일관되게 적용할 수 있는 조직 수준 보안 거버넌스를 구현할 수 있습니다. Power Platform에서 Entra ID를 사용하기 위한 자체 계획을 수립하는 데 대한 자세한 지침은 이러한 ID 관리 모범 사례를 검토하세요.

그룹 액세스 관리

특정 사용자에게 권한을 부여하는 대신 Microsoft Entra ID의 그룹에 액세스 권한을 할당합니다. 그룹이 존재하지 않는 경우 ID 팀과 협력하여 그룹을 만드세요. 그런 다음 Azure 외부에서 그룹 구성원을 추가 및 제거하고 권한이 최신인지 확인할 수 있습니다. 메일링 리스트와 같은 다른 목적으로 그룹을 사용할 수도 있습니다.

자세한 내용은 Microsoft Entra ID의 그룹을 사용하여 보안 액세스 제어를 참조하세요.

위협 탐지

Microsoft Entra ID 보호는 ID 기반 위험을 탐지, 조사 및 해결하는 데 도움이 될 수 있습니다. 자세한 내용은 ID 보호란?을 참조하세요.

위협 탐지는 의심스러운 활동에 대한 경고에 대응하거나 활동 로그에서 비정상적인 이벤트를 사전에 검색하는 형태를 취할 수 있습니다. Sentinel의 사용자 및 엔터티 동작 분석(UEBA)을 사용하면 의심스러운 활동을 쉽게 감지할 수 있습니다. Microsoft 자세한 내용은 Sentinel에서 UEBA를 사용하여 고급 위협 식별 Microsoft 을 참조하세요.

ID 로깅

Power Apps, Power Automate, Copilot Studio, 커넥터 및 데이터 손실 방지 활동 로깅은 Microsoft Purview 규정 준수 포털에서 추적하고 볼 수 있습니다. 자세한 내용은 Purview에 대해 Microsoft 알아보세요를 참조하세요.

Dataverse 데이터베이스가 있는 환경에서 고객 레코드에 대한 변경 사항을 기록합니다. Dataverse 감사는 환경의 앱이나 SDK를 통한 사용자 액세스도 기록합니다. 이 감사는 환경 수준에서 활성화되며 개별 테이블과 열에 대한 추가 구성이 필요합니다.

서비스 관리자 역할

Entra ID에는 관리자에게 관리 작업을 수행할 수 있는 권한을 부여하기 위해 할당할 수 있는 사전 설정된 역할 세트가 포함되어 있습니다. 각 역할의 권한을 세부적으로 분석하려면 권한 매트릭스를 검토할 수 있습니다.

Microsoft Entra PIM(Privileged Identity Management)을 사용하여 Power Platform 관리 센터에서 높은 권한의 관리자 역할을 관리합니다.

Dataverse 데이터 보안

Dataverse의 주요 기능 중 하나는 많은 비즈니스 사용 시나리오에 적응할 수 있는 풍부한 보안 모델입니다. 이 보안 모델은 Dataverse 데이터베이스가 환경에 있는 경우에만 사용할 수 있습니다. 보안 전문가로서 전체 보안 모델을 직접 구축하지는 않지만 보안 기능의 사용이 조직의 데이터 보안 요구 사항과 일치하는지 확인하는 데 참여할 수 있습니다. Dataverse는 역할 기반 보안을 사용하여 권한 모음을 그룹화합니다. 이러한 보안 역할은 사용자와 직접 연결하거나 Dataverse 팀 및 사업부와 연결할 수 있습니다. 자세한 내용은 Microsoft Dataverse의 보안 개념을 참조하십시오.

Copilot Studio에서 사용자 인증 구성

Copilot Studio는 여러 인증 옵션을 지원합니다. 필요에 가장 적합한 것을 선택하십시오. 인증을 통해 사용자는 로그인하여 조종사에게 제한된 리소스나 정보에 대한 접근 권한을 부여할 수 있습니다. 사용자는 Microsoft Entra ID나 Google이나 OAuth 2.0 ID 공급자를 사용하여 로그인할 수 있습니다. Facebook 자세한 내용은 사용자 인증 구성 Copilot Studio에서 확인하세요.

Direct Line기반 보안을 사용하면 비밀이나 토큰을 사용하여 보안 액세스를 활성화하여 제어하는 위치에 대한 액세스를 제한할 수 있습니다. Direct Line

Copilot Studio 단일 로그인(SSO)을 지원하므로 조종사가 사용자를 로그인시킬 수 있습니다. SSO는 웹 페이지와 모바일 애플리케이션에 구현되어야 합니다. Microsoft Teams"Teams에서만" 인증 옵션을 선택하면 SSO가 원활하게 진행됩니다. Azure AD v2를 사용하여 수동으로 구성할 수도 있습니다. 그러나 이 경우 Teams 앱을 1-클릭 Teams 배포가 아닌 zip 파일로 배포해야 합니다. Copilot Studio

자세히 보기:

고객 Lockbox를 사용하여 데이터에 안전하게 액세스

대부분의 작업, 지원 및 문제 해결은 직원(하위 처리자 포함)이 수행하며, 고객 데이터에 액세스할 필요가 없습니다. Microsoft Power Platform 고객 Lockbox를 통해 드물게 고객 데이터에 대한 데이터 액세스가 필요할 때 고객이 데이터 액세스 요청을 검토 및 승인(또는 거부)할 수 있는 인터페이스를 제공합니다. 예를 들어, 엔지니어가 고객 데이터에 액세스해야 할 때 사용되며, 이는 응답에서 고객이 시작한 지원 티켓이나 Microsoft 에서 식별된 문제에 이르기까지 다양합니다. Microsoft 자세한 내용은 Power Platform 및 Dynamics 365의 고객 Lockbox를 사용하여 고객 데이터에 안전하게 액세스를 참조하세요.

보안 체크리스트

전체 권장 사항 세트를 참조하세요.

보안 체크리스트