Dataverse 보안 역할 vs. 행 수준 보안: 어떤 것이 필요할까?

By Mirko Peters · 2026-08-20

Dynamics 365와 Microsoft 365에서 Dataverse 보안 역할, 행 수준 보안, 열 수준 권한의 차이를 알아봅니다.

Automatically translated with AI from the original post. Read the English original

Microsoft Dynamics 365와 Power Platform에서 비즈니스 솔루션을 설계할 때는 민감한 데이터에 대한 액세스 제어가 매우 중요합니다. 테이블 수준 Dataverse 보안 역할과 세분화된 행 수준 보안 중에서 선택하면 권한 없는 데이터 노출을 방지하는 동시에, 팀원이 일상 업무를 효율적으로 수행하는 데 필요한 권한을 유지할 수 있습니다.

핵심 요약

• Dataverse 보안 역할은 건물의 안내 데스크와 같은 역할을 하며, 사용자가 어떤 테이블(예: 계정 또는 사례)을 읽고, 만들고, 업데이트하고, 삭제할 수 있는지를 결정합니다.
• 행 수준 보안은 테이블 내 개별 레코드에 대한 액세스를 제한하여, 영업 담당자가 본인이 소유한 고객 기회만 볼 수 있도록 보장합니다.
• Microsoft Entra ID는 로그인 시 사용자 신원을 확인하고, Dataverse는 기본 데이터 모델에 대해 세분화된 권한과 비즈니스 규칙을 적용합니다.
• 열 수준 보안은 접근 가능한 행 안에서도 재무 메모나 급여 정보와 같은 민감한 세부 정보를 보호하는 추가 보호 계층을 제공합니다.
• 테이블, 행, 열 권한을 함께 사용하면 흩어진 UI 설정에 의존하지 않고도 조직의 운영 요구에 맞춰 데이터 가시성을 정밀하게 조정할 수 있습니다.

Dataverse 보안 계층 이해하기

Microsoft Dataverse의 데이터 보안은 단순한 on/off 스위치가 아닙니다. 대신 운영 효율성과 엄격한 규정 준수의 균형을 맞추도록 설계된 다계층 아키텍처 모델로 동작합니다. 조직이 보안을 뒤늦게 고려하거나 개별 Power Apps나 Dynamics 365 모듈 내에서 사용자 인터페이스 요소를 숨기는 데만 의존하면, 필연적으로 데이터 유출과 사용자 불편에 노출됩니다. 견고한 보안 전략에는 신원, 테이블, 행, 열이 어떻게 맞물리는지 이해하는 것이 필요합니다.

데이터 환경을 안전한 기업 본사라고 생각해 보십시오. 직원이 모든 사무실, 서류 캐비닛, 서랍에 자유롭게 접근할 수는 없습니다. Dataverse의 보안도 이와 같은 원리로, 데이터 구조의 모든 수준에서 명확한 경계를 설정합니다. 사용자가 어떤 비즈니스 레코드와도 상호 작용하기 전에, 시스템은 신원을 확인하고 할당된 책임을 데이터베이스 아키텍처에 비추어 평가합니다.

테이블 수준 보안 역할 자세히 알아보기

보안 역할은 Dataverse 권한의 기반 계층을 이룹니다. 보안 역할은 본질적으로 영업 담당자, 고객 서비스 상담원, 부서 관리자 등 특정 직무나 부서와 연결된 권한의 묶음입니다.

테이블 수준에서 이러한 역할은 사용자가 데이터 범주 전체에 대해 표준 만들기(Create), 읽기(Read), 업데이트(Update), 삭제(Delete)(CRUD) 작업을 수행할 수 있는지를 제어합니다. 예를 들면 다음과 같습니다.

• 영업 담당자: 일반적으로 계정, 연락처, 리드, 기회를 읽고, 만들고, 업데이트할 수 있는 권한이 부여되지만, 중요한 과거 레코드를 삭제하는 권한은 대개 제한됩니다.
• 고객 서비스 상담원: 지원 사례와 고객 대기열을 관리하도록 구성되지만, 영업 파이프라인 단계나 상업적 기회를 변경하는 권한은 제외될 수 있습니다.
• 부서장: 여러 운영 테이블에 걸친 광범위한 감독 권한이 부여되어, 부서 간 보고서를 생성하고 팀 성과를 모니터링할 수 있습니다.

이러한 권한은 개별 앱 화면이 아니라 데이터 기반에 직접 연결되어 있으므로, 사용자가 사용자 지정 캔버스 앱, 모델 기반 앱, 또는 연결된 Power Automate 워크플로를 통해 직접 정보에 접근하더라도 동일한 보호 장치가 계속 적용됩니다.

행 수준 보안과 소유권

테이블 수준 보안은 사용자가 계정 테이블 자체를 열 수 있는지를 결정하지만, 행 수준 보안은 해당 테이블 안에서 사용자가 볼 수 있는 고객 레코드를 결정합니다. 행 수준 보안이 없다면 영업 사원 보안 역할이 할당된 모든 사용자가 데이터베이스의 모든 고객 레코드를 볼 수 있게 됩니다.

행 수준 보안은 레코드 소유권과 비즈니스 단위에 크게 의존합니다. 일반적인 영업 구성에서 영업 담당자는 자신이 명시적으로 소유자로 지정된 계정 및 연락처 행에만 액세스할 수 있습니다. 반면 영업 관리자는 더 높은 보안 범위에 속하므로, 지역 팀 전체가 소유한 모든 고객 행을 볼 수 있습니다.

이처럼 세분화된 방식은 직원이 자신과 관련된 업무에 집중하도록 하는 동시에, 신입 직원이 다른 부서가 관리하는 민감한 계정을 무분별하게 둘러보는 것을 막아 줍니다. 또한 실수로 데이터가 노출될 위험을 크게 줄이고, 작업 공간의 불필요한 정보를 최소화합니다.

민감한 데이터를 위한 열 수준 보안

사용자가 계정이나 연락처 행에 정당하게 액세스할 수 있더라도, 특정 열에는 제한된 보기가 필요한 민감한 정보가 포함될 수 있습니다. 열 수준 보안을 사용하면 관리자가 은행 정보, 임원 보상 금액, 기밀 협상 메모와 같은 특정 필드를 잠그는 한편, 나머지 고객 레코드는 일반 업무에 필요한 만큼 모두 액세스할 수 있도록 유지할 수 있습니다.

비즈니스 단위와 함께 사용하면 조직은 복잡한 기업 구조, 지역 자회사, 또는 별도의 운영 부서를 반영하는 견고한 계층적 경계를 구성할 수 있습니다. 이러한 통합 데이터 구조가 내부적으로 어떻게 작동하는지 더 자세히 알고 싶다면 M365 FM 팟캐스트의 전체 에피소드 듣기를 참고하시기 바랍니다.

결론

Microsoft Dataverse 환경을 구성하려면 사용자 권한을 실제 업무 흐름에 맞추는 체계적인 전략이 필요합니다. Entra ID 신원 확인, 테이블 수준 보안 역할, 행 단위 소유권 규칙, 열 수준 보호를 계층적으로 적용하면 Dynamics 365와 Power Platform을 위한 안전하고 성능이 뛰어난 데이터 기반을 구축할 수 있습니다. 조직의 액세스 요구 사항을 충분히 검토하고, 데이터 자체를 기준으로 보안 모델을 설계하시기 바랍니다. Microsoft 클라우드 환경을 최적화하기 위한 실질적인 전략과 전문가의 통찰을 더 얻으려면 전체 팟캐스트 에피소드를 들어 보시기 바랍니다.

자주 묻는 질문

Dataverse에서 테이블 수준 보안과 행 수준 보안의 차이는 무엇입니까?

테이블 수준 보안은 모든 계정이나 지원 사례처럼 데이터 범주 전체와 사용자가 상호 작용할 수 있는지를 제어합니다. 행 수준 보안은 한 단계 더 나아가 소유권, 팀 할당 또는 비즈니스 단위를 기준으로 해당 테이블 내 특정 레코드에 대한 액세스를 제한합니다.

Microsoft Entra ID는 Dataverse 보안과 어떻게 상호 작용합니까?

Microsoft Entra ID는 로그인 시 사용자의 신원을 확인하는 초기 인증 계층(건물의 안내 데스크와 같은 역할)입니다. 이후 Dataverse는 해당 신원을 받아 특정 보안 역할과 권한을 적용하여 사용자가 무엇을 보고 수정할 수 있는지 결정합니다.

고객 레코드 내 특정 필드에 대한 액세스를 제한할 수 있습니까?

예. Dataverse에는 열 수준 보안이 포함되어 있습니다. 이 기능을 사용하면 관리자가 액세스 가능한 행 안의 재무 데이터나 비공개 메모 같은 개별 필드를 보호하여, 사용자가 자신의 역할과 관련된 데이터만 보도록 할 수 있습니다.

보안 역할을 Power 앱마다 따로 구성해야 합니까?

아니요. Dataverse는 Dynamics 365 및 Power Platform 애플리케이션의 공통 데이터 기반 역할을 하므로, 보안 역할과 비즈니스 규칙이 데이터 계층에서 직접 적용됩니다. 따라서 연결된 모든 앱에 일관된 보호 장치가 자동으로 적용됩니다.