통합 수익 시스템에서의 거버넌스와 접근 제어

수익 데이터를 통합하는 것은 실질적인 성과이며, 동시에 여러분이 지금까지 내린 모든 접근 결정의 위험 부담을 조용히 끌어올립니다. 고객 데이터가 십여 개의 사일로에 흩어져 있을 때는, 한 도구에서의 권한 실수가 한 조각만 노출시켰습니다. 계정, 연락처, 활동, 수익, 제품 사용, 파트너 데이터가 모두 하나의 표준 계층에 자리 잡으면, 실수의 파급 범위는 수익 전체 그림이 됩니다. 통합 시스템을 유용하게 만드는 바로 그것, 즉 모든 것이 한곳에 있다는 사실이 거버넌스를 필수로 만드는 바로 그것이기도 합니다.

거버넌스는 보통 보안 검토 직전에 덧붙이는 컴플라이언스 잡무로 취급됩니다. 그것은 거꾸로입니다. 통합 수익 시스템에서는 접근 제어를 모든 계층에 설계로 반영해야 합니다. 이미 모든 것을 통합해버린 시스템에 나중에 이를 소급 적용하는 것은 고통스럽고, 놓치는 부분이 생길 것이기 때문입니다. 아래는 통합 수익 플랫폼에 필요한 거버넌스 모델과 그것이 현대적 수익 플랫폼을 위한 참조 아키텍처를 관통하는 방식입니다.

거버넌스는 스택 옆이 아니라 전체를 가로질러 작동한다

거버넌스를 수집과 모델링 옆에 있는 하나의 박스로 그리고 싶은 유혹이 있습니다. 잘못된 그림입니다. 거버넌스는 수집, 통합 데이터 계층, 모델링, 라이트백을 가로질러 작동합니다. 이들 각각이 자체적인 접근 질문을 제기하기 때문입니다.

• 수집: 어떤 출처가 표준 계층에 쓰기를 허용받으며, 그것을 얼마나 신뢰하는가?
• 통합 데이터 계층: 누가 어떤 엔티티, 필드, 행을 볼 수 있는가?
• 모델링: 누가 점수와 어트리뷰션을 계산하는 로직을 보거나 바꿀 수 있는가?
• 라이트백: 누가 시스템 오브 레코드로 변경 사항을 다시 밀어넣을 수 있으며, 누가 그것을 승인하는가?

이 각각에 대해 설계하십시오. 로그인 후 제한 없는 접근이라는 경계선만 있는 모델은 정확히 통합 시스템을 자산에서 부채로 뒤바꾸는 실패입니다.

핵심 축

아래 내용 중 새로운 것은 없습니다. 새로운 것은 수익 데이터를 통합한다는 것이 이 모든 것을 동시에 제대로 해내야 한다는 뜻이라는 점입니다. 이전에는 각 사일로가 다른 사일로를 무너뜨리지 않고 개별적으로 실패할 수 있었습니다.

역할 기반 접근 제어. 접근은 개인이 아니라 역할을 따릅니다. 담당자, RevOps 관리자, 마케팅 분석가, 재무 관리자는 각기 다른 뷰가 필요합니다. 수천 개의 개별 권한을 관리하며 누군가 팀을 옮길 때마다 어긋나게 두는 대신, 이를 한 번 정의하고 배정하십시오.

행 및 필드 수준 보안. 수익 데이터에는 테이블 수준의 접근만으로는 충분하지 않습니다. 담당자는 모든 사람의 계정이 아니라 자신의 계정만 보아야 합니다. 일부 필드(계약 금액, 마진, 보상과 관련된 모든 것)는 해당 레코드를 볼 수 있도록 허용된 사람에게조차 민감합니다. 세밀한 제어는 여기서는 프리미엄 등급이 아니라 기본 사양입니다.

최소 권한. 역할이 기능하는 데 필요한 최소한만 부여하십시오. 모든 것에 접근 가능한 시스템에서는, 이것이 사고와 침해 양쪽에 대한 주된 방어선입니다.

감사와 계보. 모든 접근과 모든 변경을 기록하십시오. 누가 무엇을 보았고, 누가 무엇을 바꿨으며, 계산된 값의 경우 어떤 데이터가 그것을 만들어냈는지. 그 계보가 CFO가 숫자의 출처를 물었을 때 시스템을 설명하고 방어할 수 있게 해줍니다.

통합의 역설

여기에는 실질적인 긴장이 있습니다. 통합은 "함께 모아서 전체를 아우르며 사고할 수 있게 하자"고 말합니다. 거버넌스는 "누가 무엇을 보는지 제한하자"고 말합니다. 이 둘은 반대 방향으로 당기며, 이를 잘 해결하는 것이 이 작업의 대부분입니다.

해결책은 이렇습니다. 데이터는 통합하고, 접근은 거버넌스로 다스리십시오. 표준 계층은 해석되고 완전한 모든 것을 담고 있습니다. 특정 사용자나 시스템이 실제로 보는 것은 그들의 역할, 행 범위, 필드 권한으로 필터링된 그 계층의 투영입니다. 저장은 통합되어 있습니다. 접근은 분할되어 있습니다. 이 둘이 서로 다른 수준에서 작동하기 때문에 여러분은 하나의 일관된 모델과 최소 권한 뷰를 동시에 얻게 됩니다.

이것이 웨어하우스 네이티브 아키텍처를 지지하는 더 강력한 논거 중 하나입니다. 플랫폼은 두 번째의, 서로 어긋나는 권한 모델을 구축하는 대신 웨어하우스의 기존 행 수준 보안을 물려받을 수 있습니다. 서로 동기화 상태를 유지해야 하는 두 개의 거버넌스 경계선은 잘못될 두 번의 기회이며, 저희 경험상 이들은 한 분기 안에 어긋나기 시작합니다.

움직이는 부분들을 통제하기

시스템의 두 가지 동적인 부분은 그들만의 특별한 주의를 받을 자격이 있습니다. 접근 실패가 실제로 피해를 입히는 지점이기 때문입니다.

먼저 라이트백. 데이터를 읽는 것은 기밀성의 문제입니다. 데이터를 쓰는 것은 무결성의 문제입니다. 라이트백 계층은 시스템 오브 레코드를 수정할 수 있으므로, 누가 라이트백 규칙을 만들 수 있는지, 그 규칙이 어떤 필드를 건드릴 수 있는지, 어떤 승인이 필요한지에 대한 자체 통제가 필요합니다. 라이트백 규칙은 CRM을 대규모로 편집하는 프로그램입니다. 그렇게 취급하십시오.

그다음은 프로그래매틱 접근입니다. API 우선 플랫폼에서는 API가 UI와 동일한 거버넌스를 강제해야 합니다. UI가 권한을 신중하게 범위 지정하는 동안 API 키가 광범위한 접근을 부여한다면, API는 여러분의 전체 모델을 우회하는 뒷문이 됩니다. 범위가 지정된 토큰, 최소 권한 서비스 계정, API 수준의 감사 로깅이 그 간극을 메웁니다.

이 모든 것의 기저에서, 거버넌스는 데이터가 정확한지에 의존합니다. 접근 결정은 올바른 역할 및 소유권 필드에 의존하므로, 그 필드를 정확하게 유지하는 RevOps 데이터 위생은 별개의 프로젝트가 아니라 거버넌스의 전제조건입니다. 오래된 "계정 소유자" 필드는 서류상으로는 멀쩡해 보이는 망가진 접근 규칙입니다.

핵심 요약

• 모든 수익 데이터를 위한 하나의 장소는 하나의 큰 파급 범위를 의미합니다. 데이터가 흩어져 있을 때보다 모든 접근 결정이 더 중요해집니다.
• 거버넌스는 수집, 데이터 계층, 모델링, 라이트백을 관통합니다. 로그인 화면이 아니라 각 계층에 이를 설계하십시오.
• RBAC, 행 및 필드 수준 보안, 최소 권한, 감사 계보 모두가 필요하며, 동시에 모두 필요합니다.
• 데이터는 통합하고, 접근은 거버넌스로 다스리십시오. 저장은 하나의 모델이고, 각자가 보는 것은 그것을 필터링한 투영입니다.
• 라이트백과 API 접근은 실패가 가장 큰 피해를 주는 곳입니다. 이들에게 자체 통제를 부여하고 API가 UI와 동일한 권한을 지키게 하십시오.

거버넌스는 통합 수익 시스템이 강력하면서도 신뢰할 수 있게 만드는 것이며, Revnewo와 같은 플랫폼이 접근 제어를 컴플라이언스 후속 작업이 아니라 아키텍처의 일부로 취급하는 이유입니다. 수익 데이터를 통합하고 있다면, 통합하기 전에 각 계층에 대한 접근 모델을 매핑하십시오. 나중이 아니라요.