Power Pages 포털 보안 강화: 테이블 권한과 범위 심층 분석

By Mirko Peters · 2026-08-11

팟캐스트 블로그에 다시 오신 것을 환영합니다! Microsoft Power Platform에서 고객 대상 웹 애플리케이션을 구축할 때 보안은 나중에 고려할 사항이 될 수 없습니다. Power Pages는 Dataverse와 직접 연결된 견고한 외부 포털을 빠르게 배포할 수 있는 훌륭한 도구입니다. 하지만 큰 힘에는 큰 책임이 따릅니다. 특히 조직의 민감한 데이터가 실수로 외부에 노출되거나 조직 경계를 넘어 유출되지 않도록 해야 하는 책임입니다.

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

Titelbild: Securing Your Power Pages Portal: A Deep Dive into Table Permissions and Scopes

이번 글에서는 최근 에피소드에서 다룬 핵심 아키텍처 보안 개념을 자세히 살펴보겠습니다. 아직 청취하지 않으셨다면 Build Customer Portals with Power Pages and Dataverse 에피소드를 꼭 확인해 보세요. 환경 설정, 외부 ID 처리, 첫 번째 포털 솔루션 배포까지 전 과정을 단계별로 다룹니다.

Power Pages 보안의 작동 원리를 자세히 살펴보겠습니다. 먼저 데이터 경계를 계획하는 방법과 테이블 권한을 제대로 다루는 방법부터 알아보겠습니다.

Power Pages 보안 소개

Power Pages 사이트를 처음 만들면 플랫폼은 유연하고 높은 수준으로 사용자 지정할 수 있는 작업 공간을 제공합니다. 하지만 그 아래에는 Microsoft Dataverse 환경으로 직접 연결되는 통로가 있습니다. 보안 구성이 제대로 관리되지 않으면 데이터베이스의 모든 레코드가 보호되지 않은 엔드포인트나 범위가 잘못 지정된 목록 보기를 통해 노출될 수 있습니다.

Power Pages의 보안은 다층 방어 전략에 기반합니다. 바깥쪽 계층에는 Azure AD B2C, 로컬 계정, 외부 ID 공급자와 같은 인증 메커니즘이 있어 사용자가 자신이 누구인지 증명하도록 합니다. 안쪽 계층에는 웹 역할과 Dataverse 테이블 권한이 있습니다. 이러한 권한은 인증된 ID가 무엇을 보고, 만들고, 업데이트하고, 삭제할 수 있는지를 정확히 결정합니다. 이를 올바르게 설정하는 것이 안전한 엔터프라이즈 포털과 언제든 대형 데이터 유출로 이어질 수 있는 상황을 가르는 차이입니다.

데이터 경계와 테이블 권한 계획

Power Pages Studio에서 버튼 하나라도 누르기 전에, 화이트보드를 꺼내 데이터 경계를 꼼꼼히 정리해야 합니다. 이는 포털 프로젝트 전체 수명 주기에서 아마 가장 중요한 15분일 것입니다.

먼저 외부 사용자에게 노출할 모든 Dataverse 테이블의 목록을 체계적으로 작성합니다. 각 테이블에 대해 필요한 최소한의 CRUD 작업을 정의합니다. 고객이 정말 송장을 삭제할 수 있어야 할까요, 아니면 읽기와 추가 권한만 있으면 충분할까요? 작업을 정의했다면 각 테이블의 행 범위를 결정해야 합니다.

연락처 범위: 사용자는 자신의 연락처 레코드에 직접 연결된 레코드와만 상호 작용할 수 있습니다.
계정 범위: 사용자는 소속 회사 또는 계정 전체와 연결된 레코드와 상호 작용할 수 있습니다.
전역 범위: 사용자는 테이블 전체의 모든 레코드를 볼 수 있습니다(일반적으로 공개 지식 자료 문서나 메타데이터에 사용됩니다).

이러한 경계를 초기에 정의하면 개발 환경에서 어떤 구성을 만들기 전에 최소 권한 원칙의 기준선을 확립할 수 있습니다.

연락처 범위와 계정 범위 이해하기

Power Pages를 처음 접하는 메이커들이 가장 많이 혼동하는 부분 중 하나는 연락처 범위와 계정 범위의 미묘한 차이입니다. 범위를 잘못 선택하면 관련 회사 데이터가 숨겨져 사용자 경험이 완전히 망가지거나, 기밀 데이터가 권한 없는 사람에게 의도치 않게 노출될 수 있습니다.

연락처 범위는 개인 소비자형 포털을 위해 설계되었습니다. 사용자가 로그인하여 지원 티켓을 제출하면, 연락처 범위 권한은 사용자가 기본 연락처 또는 생성자로 명시적으로 지정된 케이스만 볼 수 있도록 합니다. 같은 회사의 다른 사용자가 로그인하더라도 동료의 개인 지원 티켓은 보이지 않습니다.

반면 Account Scope(계정 범위)는 B2B 포털 아키텍처를 위해 설계되었습니다. B2B 시나리오에서는 계정 관리자나 주요 구매 담당자가 소속 상위 계정과 연결된 모든 케이스, 주문, 송장을 볼 수 있어야 합니다. 테이블 권한에 Account 범위를 할당하면, 포털은 로그인한 사용자의 Contact 레코드에 연결된 상위 Account를 평가한 다음, 해당 조직에 속한 모든 관련 하위 레코드를 표시합니다. B2B를 성공적으로 운영하려면 Dataverse에서 이 관계를 올바르게 매핑하는 것이 무엇보다 중요합니다.

웹 역할 정의와 Authenticated Users 함정 피하기

웹 역할은 인증된 사용자와 Dataverse 테이블 권한을 연결하는 다리 역할을 합니다. 기본 상태에서 Power Pages에는 "Authenticated Users"라는 기본 역할이 포함되어 있습니다. 많은 관리자가 바로 이 지점에서 위험한 보안 함정에 빠집니다.

기본적으로 포털에 성공적으로 로그인한 모든 사용자는 자동으로 Authenticated Users 역할에 속하게 됩니다. 이 기본 역할에 광범위한 테이블 권한, 또는 더 나쁘게는 Global 범위 권한을 부여하면, 사이트에 가입하는 모든 사람이 즉시 그 과도한 권한을 물려받게 됩니다. 이는 심각한 보안 안티패턴입니다.

대신 특정 사용자 페르소나에 맞춘 세분화된 사용자 지정 웹 역할을 만들어야 합니다. 예를 들면 다음과 같습니다.

CustomerUser: 케이스와 주문 같은 운영 테이블에 대해 Contact 범위를 적용하여, 사용자가 자신의 상호 작용 내역을 추적할 수 있도록 합니다.
AccountManager: Account 범위를 적용하여, 지정된 조직 리더가 회사 전체 자산을 볼 수 있도록 합니다.
KnowledgeBaseViewer: 전역으로 매핑하되, 공개 지원 문서에 대한 읽기 전용 작업으로만 엄격히 제한합니다.

불필요한 기본 액세스는 항상 제거하고, 사용자가 조직 내 관계에 따라 목적에 맞게 만든 역할에 명시적으로 할당되도록 하십시오.

필드 수준 표시 강화 및 PII 보호

테이블 범위를 통해 행 수준 액세스를 제어하는 것은 절반에 불과합니다. 개별 행과 목록에서 어떤 데이터가 보이는지도 꼼꼼히 살펴봐야 합니다. 전화번호, 자택 주소, 금융 정보, 내부 직원 메모 같은 개인 식별 정보(PII)가 노출되면 GDPR이나 CCPA 위반 같은 심각한 규정 준수 문제로 이어질 수 있습니다.

Power Pages에서 목록과 기본 양식을 만들 때는 보기에서 민감한 열을 반드시 제거하십시오. 전면 양식 레이아웃에서 필드를 숨겼다고 해서, 권한이 지나치게 넓다면 그 필드를 검사하거나 기본 웹 API로 가져올 수 없는 것은 아닙니다. 안전하고 정제된 열만 포함하는 별도의 강화된 보기(예: 지정된 "PublicView")를 활용하십시오. 특정 열을 반드시 데이터베이스 테이블에 남겨 두어야 한다면, Dataverse의 열 수준 보안을 구현하여 데이터베이스 엔진 수준에서 액세스를 완전히 제한하는 방안을 고려하십시오.

포털 권한 침투 테스트

보안 모델이 제대로 작동한다고 단순히 가정할 수는 없습니다. 입증해야 합니다. 포털 솔루션을 테스트 또는 운영 환경에 배포하기 전에, 테이블 권한과 라우팅 로직에 대해 철저한 침투 테스트를 수행해야 합니다.

정의한 각 웹 역할에 대해 테스트 사용자 계정을 설정하십시오. 일반 CustomerUser로 로그인하여 다른 Contact 또는 Account에 속한 데이터를 조회해 보십시오. 브라우저 주소 표시줄에서 레코드 ID를 바꿔 보며 직접 URL 조작과 GUID 변조를 시도하고, 서버가 승인되지 않은 요청을 올바르게 차단하는지 확인하십시오. 또한 포털의 진단 및 감사 로그를 검토하여, 권한 상승 시도가 적절한 403 Forbidden 응답을 발생시키는지 확인하십시오.

결론 및 모범 사례

Power Pages 포털을 보호하려면 신중한 계획, 최소 권한 원칙의 엄격한 준수, 그리고 Dataverse 테이블 권한과 범위에 대한 깊은 이해가 필요합니다. Authenticated Users 역할 같은 위험한 기본값에서 벗어나고, 테이블 액세스를 Contact 또는 Account 수준으로 신중하게 범위 지정하며, 필드 수준 표시를 강화하면, 기능성과 보안성을 모두 갖춘 고객 포털을 구축할 수 있습니다.

이 주제를 더 깊이 살펴보고 외부 ID 설정, 솔루션 아키텍처 설계, 실제 운영 전환 준비까지 포함한 엔드 투 엔드 구현 가이드를 확인하려면 함께 제공되는 팟캐스트 에피소드 Build Customer Portals with Power Pages and Dataverse를 꼭 들어 보시기 바랍니다. 읽어 주셔서 감사합니다. Microsoft Power Platform을 더 깊이 익힐 수 있는 전문가 팁을 계속 기대해 주십시오!