Dataverse 보안 재편, 교훈을 너무 늦게 적용.

출처: Dev.to

Dataverse는 세 가지 접근 제어 원시 요소를 제공하며, 이를 조합해 권한 모델을 구성합니다: 비즈니스 유닛(BU), 보안 역할, 팀. 이론적으로는 단순합니다. 실제로는 1년 이상 운영되는 모든 프로젝트가 동일한 실패 패턴을 겪습니다. 보안 모델이 점점 커지는 것이죠—부서마다 새로운 역할, 프로젝트마다 새로운 팀, “지역별 데이터 분리 필요”라는 요구가 있을 때마다 새로운 비즈니스 유닛을 추가합니다. 3년 차가 되면 목적을 기억하지 못하는 20개의 역할이 생기고, 접근 권한 감사를 하는 데 일주일이 걸립니다.

우리는 세 프로젝트에 대해 보안 구조 개편을 진행했습니다. 첫 번째는 너무 늦게 시작했기 때문에 5주가 걸렸고, 마지막은 3개월 차에 바로 잡아냈기 때문에 1주만에 끝났습니다. 패턴은 다음과 같습니다.

비즈니스 유닛: 사용자와 레코드를 담는 계층형 컨테이너. Dataverse의 레코드 한 행은 사용자 또는 팀이 소유하며, 이들은 특정 BU에 속합니다. BU는 루트에서부터 아래로 트리를 이루어갑니다.

보안 역할: 테이블별 권한 집합(생성 / 읽기 / 쓰기 / 삭제 / 추가 / 추가 대상 / 할당 / 공유)과 범위별 권한(사용자 / 비즈니스 유닛 / 상위:하위 / 조직)으로 구성됩니다. 사용자는 하나 이상의 역할을 가집니다.

팀: 레코드를 공동 소유할 수 있는 사용자 그룹이며, 팀에 역할을 할당하면 모든 구성원이 그 역할을 상속받습니다.

흔히 저지르는 오해는 역할을 직책(예: “영업 사원”)으로, BU를 부서(예: “영업부”)로 생각하는 것입니다. 실제 매핑은 다음과 같습니다.

• BU: 데이터 격리(지역, 국가, 데이터가 섞이면 안 되는 인수 기업)
• 역할: 기능(계정 읽기, 기회 편집, 엑셀 내보내기)
• 팀: BU 간 협업 및 레코드 공동 소유

역할을 데이터 격리(“유럽 영업 사원 역할 vs 미국 영업 사원 역할”)에 사용하면 N개의 지역마다 같은 역할을 복제하게 됩니다. BU를 기능(“읽기 전용 BU”)에 사용하면 의미 없는 트리가 생깁니다.

프로젝트의 보안 모델이 드리프트된 경우는 다음과 같습니다.

• “Sales Rep v2”, “Sales Rep Special Cases”, “Sales Rep US Mountain Region” 등 이름이 붙은 10개 이상의 사용자 정의 역할
• 올바른 접근 권한을 얻기 위해 한 계정에 4~5개의 역할을 겹쳐서 할당
• 실제 레코드 소유를 공유하지 않는 사용자를 묶기 위해 만든 팀(그룹 할당의 대용품)
• 3단계를 초과하는 깊은 BU 트리
• 비즈니스 담당자가 “이 레코드를 누가 볼 수 있나요?” 라는 질문에 엔지니어가 쿼리를 실행하지 않으면 답을 못 하는 상황

지난해 한 고객사에서 위 다섯 가지 증상을 모두 발견했으며, 아래와 같이 해결했습니다.

1. 현황 파악
   보안 역할 매트릭스를 스프레드시트로 내보냅니다. 역할, 테이블, 권한을 모두 기록합니다. 이 문서가 모든 대화의 출발점이 됩니다.

2. 역할을 의도별로 그룹화
   역할별 권한 컬럼을 보고 클러스터를 찾습니다. 대부분의 “사용자 정의 역할”은 실제로 3~5개의 의도(읽기 전용, 표준 사용자, 파워 사용자, 관리자, 시스템 관리자)로 매핑됩니다. 더 세분화된 역할은 거의 항상 약간의 변형에 불과합니다.

3. 기능 역할 정의
   2단계에서 만든 클러스터를 3~5개의 정규화된 역할로 교체합니다.

   acme_read_only        - 모든 비즈니스 테이블에 대해 읽기만 가능, 쓰기 불가
   acme_standard_user    - 할당된 레코드에 대해 읽기 + 쓰기 (사용자 범위)
   acme_power_user       - BU 범위에서 읽기 + 쓰기 + 추가 + 할당
   acme_admin            - 모든 권한, 조직 범위
   acme_integration      - (선택) 서비스 주체 통합용

4. 실제 데이터 격리 요구사항 파악
   대부분의 프로젝트는 루트 외에 BU가 필요 없습니다. 구체적으로 물어보세요: “사용자가 보 shouldn’t not see a record, does the business have an audit or compliance problem?” 대부분 내부 CRM에서는 답이 ‘아니오’입니다. 다국적 기업처럼 데이터 거주 규정이 있다면 국가당 하나의 BU가 필요합니다.

5. BU 트리 축소
   컴플라이언스 이유가 전혀 없는 7개의 BU가 있다면 모든 사용자를 루트 BU로 이동하고 나머지는 삭제합니다. 이것이 가장 큰 잠금 해제 포인트이며, “BU‑범위 접근” 문제 대부분이 트리 평탄화로 사라집니다.

6. 팀은 소유권에만 사용
   팀은 여러 사용자가 공동 책임을 지는 레코드(예: 딜 데스크 큐, 지원 트리아지 풀)를 소유하도록 합니다. 역할을 공유하는 사용자를 묶기 위해 팀을 만들지 마세요—그 목적이 바로 역할입니다.

7. 사용자를 새 역할 세트로 마이그레이션
   새 정규화된 역할을 할당하고, 기존 사용자 정의 역할을 하나씩 제거하면서 문제가 없는지 검증합니다. 먼저 UAT 환경에서 진행하고, 프로덕션에서는 바로 적용하지 마세요.

8. 추가 역할 생성을 잠금
   새로운 보안 역할을 만들려면 반드시 티켓과 정당한 사유가 필요합니다. “X를 위해 새로운 역할이 필요합니다”는 대부분 “기존 역할에 기능을 추가해야 함”으로 귀결됩니다. 기본 답을 “아니오”로 하면 장기적으로 모델이 깔끔해집니다.

---

우리가 진행하는 분기별 접근 권한 검토

깨끗한 모델도 시간이 지나면 드리프트합니다. 매 분기마다 다음을 수행합니다.

• 역할‑대‑사용자 할당 매트릭스를 내보냅니다.
• 역할이 3개 이상인 사용자를 표시(통합 기회 탐색).
• 사용자 1명만 할당된 역할을 표시(삭제 가능성).
• 무작위로 10명의 사용자를 점검: “그들이 볼 수 있는 것이 정확히 맞고, 그 외는 보지 못하는가?” UI에서 접근 권한을 확인합니다.
• 팀 구성을 검토: 모든 팀이 원래 목적을 여전히 수행하고 있는가?

분당 45분, 엔지니어 1명 투입. 결과는 “변경 사항 없음” 또는 “역할 통합 티켓”이 됩니다. 두 경우 모두 건강한 상태입니다.

보안 역할을 변경해도 즉시 전파되지 않을 수 있습니다. 역할 변경은 다음 사용자 행동 시점이나 캐시 갱신 후에 적용되며, 최대 15분 정도 걸릴 수 있습니다.

• 권한을 제거했을 때, 사용자가 캐시가 갱신되기 전까지는 여전히 이전 권한을 사용할 수 있습니다.
• 긴급하지 않은 변경은 무시해도 됩니다(캐시가 곧 정리됩니다).
• 보안에 중요한 권한 회수(계정 탈취, 퇴사 직원 등)는 역할을 바꾸기보다 사용자 계정을 비활성화하세요. 계정 비활성화는 즉시 적용되지만, 역할 변경은 결국 일관성을 갖게 됩니다.

프로젝트가 6개월 차이고 이미 4개의 중복된 사용자 정의 역할이 보이면, 추가 역할을 만들지 말고 아직 구조 개편을 하지 마세요. 범위가 안정될 때까지 한 달 정도 기다린 뒤, 3개월 차에 8단계 개편을 실행합니다. 일주일 집중 작업이 나중에 4주 작업을 절감합니다.

프로젝트가 2년 차이고 관리가 어려워졌다면, 2주간 전용 기간을 확보해 전체 개편을 수행하고, 이를 일회성 부채 상환으로 간주한 뒤 분기별 검토를 도입합니다. 고통이 스스로 사라지지는 않습니다.