프리야(Priya), 그녀의 회사, 그리고 그 목요일 오후는 꾸며낸 이야기입니다. 그녀는 Salesforce 관리자들이 자주 겪는 상황들을 조합한 인물입니다. 제품 세부 정보와 숫자는 아래 연결된 공식 Contour 페이지에서 가져왔습니다.
프리야는 차가운 차이(chai)를 마시다가 Slack 알림을 받았습니다.
고객 서비스 팀장이었습니다. "월요일에 지원팀에 새로운 Agentforce 에이전트를 도입합니다. 불필요한 것은 볼 수 없겠죠?"
프리야는 Salesforce 관리자로 9년 경력을 가지고 있습니다. 그녀는 빠르게 타이핑하고 더 빨리 대답합니다. 나머지 생각보다 먼저 손가락이 "괜찮을 거예요!"라고 입력했습니다.
괜찮을 거예요. 이 세 단어는 IT에서 어떤 문장보다도 많은 사고 보고서를 초래해 왔습니다.
그녀는 메시지를 삭제했습니다. 그리고 운영 환경(production)의 연락처 기록(Contact record)을 열고, 무작위 계정 하나를 선택한 뒤 스크롤했습니다. 사회 보장 번호(Social Security number), 평문 숫자 그대로. 전체 카드 번호. 생년월일. 개인 이메일. 전화번호.
다음으로 새로운 AI 에이전트가 실행될 권한 집합(permission set)을 열었고, 그녀의 배는 살짝 가라앉았습니다. 만약 권한 집합이 필드를 읽을 수 있다면, 에이전트도 그 필드를 읽을 수 있습니다. 데이터가 개인 정보라는 것을 알지 못합니다. 단지 문이 잠겨 있지 않다는 것만 압니다.
9년간 깔끔하게 조직을 구축해 왔지만, 그녀는 Salesforce 데이터 보안에서 가장 기본적인 질문에 대한 실질적인 답을 찾지 못했습니다: 누가 무엇을 볼 수 있으며, 모든 것이 어디에 숨어 있는가?
여기서 **필드 레벨 보안(field-level security)**의 함정이 있습니다. 이것은 훌륭하지만, 너무 직설적입니다. 모든 필드에 대해 프로필이나 권한 집합이 보거나 못 보게 합니다. 보이거나 숨겨지거나. 켜져 있거나 꺼지거나.
이것은 비즈니스가 "우리 서비스 에이전트들은 고객의 SSN 마지막 네 자리를 확인해야 하지만, 전체 번호는 절대 봐서는 안 됩니다."라고 말할 때까지 괜찮습니다.
이제 문제가 발생합니다. 필드를 숨기면 에이전트가 업무를 할 수 없고, 보여주면 접근 권한을 가진 모든 사람(그리고 모든 AI 에이전트)에게 모든 숫자가 노출됩니다. 중간에 '조금만 보여주는' 네이티브 설정은 없습니다.
그래서 관리자들은 임시방편을 찾습니다. 마지막 네 자리만 반환하는 수식 필드(formula field)를 작성합니다. 대부분의 프로필에서는 원래 값을 숨깁니다. 페이지 레이아웃(page layouts)을 수정하고, 그다음 라이트닝 페이지(Lightning pages), 그리고 권한 집합(permission sets)을 하나씩 처리합니다. 신중하고 지루하며, 깨지기 쉬운 작업입니다.
프리야는 이 방법을 완벽하게 알고 있었습니다:
"***-**-" & RIGHT(SSN__c, 4)
하나의 필드. 작성하는 데 5분밖에 걸리지 않습니다.
하지만 마스킹된 필드는 원래 값이 나타나는 모든 곳—모든 레이아웃, 모든 라이트닝 페이지, 모든 프로필, 모든 권한 집합—에서 잠겨 있을 때만 마스킹됩니다. 하나라도 놓치면 마스크는 장식품에 불과합니다.
그녀는 스프레드시트를 열고 지난 2년 동안 피했던 일을 했습니다. 그 작업의 규모를 추정했습니다.
그녀의 조직 같은 곳은 쉽게 400개 이상의 객체(objects)를 가질 수 있습니다. 민감한 정보는 눈에 띄는 장소에만 존재하지 않습니다. 2017년에 누군가가 만든 사용자 정의 객체(custom object) 안에 숨어 있기도 합니다. 자유 형식의 메모 필드(free-text Notes field) 안에 숨어 있기도 합니다. 담당자가 고객의 카드 번호를 '그냥 저장하기 위해' 붙여넣었던 설명(Description) 상자 안에 숨어 있습니다. 이 모든 **민감 데이터(sensitive data)**를 수동으로 찾는다는 것은 객체를 하나하나 열고 필드 레이블을 뚫어져라 보는 것을 의미합니다.
그리고 수정 작업이 뒤따릅니다. 단일 필드를 수동으로 마스킹하는 데는 메타데이터 수술(metadata surgery)로 약 한 시간이 걸립니다: 수식, 레이아웃, FLS(Field Level Security). 이를 수백 개의 필드에 곱하면 200시간에서 400시간에 달합니다. Concretio는 표준 관리자 청구 요율(standard admin billing rates) 기준으로 마스킹 프로젝트당 $15K에서 $60K가 될 것이라고 추정합니다.
그녀를 정말 겁먹게 한 부분은 이것이었습니다: 되돌릴 수 있는 것이 없다는 점입니다.
잘못된 FLS 변경 하나만으로도 통합(integration), 보고서(report), 또는 조직의 절반에 달하는 레이아웃을 망가뜨릴 수 있습니다. 아무도 금요일에 Salesforce 데이터 보안을 '수정'했다가 토요일에 청구 동기화(billing sync)가 작동하지 않는 이유를 설명하고 싶어 하지 않습니다.
이것이 많은 조직들이 이 작업을 수행하지 못하는 조용한 이유입니다. 아무도 신경 쓰지 않아서가 아닙니다. 모두가 만지는 것을 두려워하기 때문입니다.
프리야는 스프레드시트를 닫았습니다. 월요일은 사흘 뒤였습니다.
목요일 오후 6시, 프리야는 모든 관리자가 하는 일을 했습니다. 구글 검색을 한 것입니다.
그녀는 '데이터 마스킹(data masking)'이 누가 말하느냐에 따라 의미가 달라지며, 이들을 혼동하는 것이 바로 격차를 만드는 방식임을 알게 되었습니다. 이를 세 개의 계층으로 생각할 수 있습니다:
- 데이터베이스 계층(The database layer). 저장 시 암호화(Encryption at rest)가 이루어집니다. Salesforce Shield와 Event Monitoring이 여기에 속하며, 저장된 데이터를 보호합니다.
- 샌드박스 계층(The sandbox layer). 운영 환경(production)의 데이터가 샌드박스로 복사될 때, 개발자는 실제 고객 기록을 받아서는 안 됩니다. Salesforce 자체의 Data Mask & Seed 기능이 이를 다룹니다.
- 표시 계층(The display layer). 사람이든, 보고서든, AI 에이전트든 운영 환경에서 실제로 화면으로 보는 것입니다.
그녀의 조직은 이미 앞의 두 가지를 갖추고 있었습니다. Shield가 설치되었고 샌드박스는 정제되었습니다. 그럼에도 불구하고 그녀는 라이브 기록(live record)에서 전체 SSN을 보고 있는 상황이었습니다.
표시 계층에 구멍이 난 것입니다. 대부분의 마스킹 도구는 샌드박스 내, 데이터 복사 과정에서만 작동합니다. 실제로 그녀가 필요로 했던 질문에 답하는 경우는 매우 드뭅니다. 즉, 컴플라이언스 팀은 여전히 실제 번호를 볼 수 있는 동일한 기록에서 서비스 에이전트에게 어떻게 ***-**-4321을 보여줄 수 있을까요?
이는 암호화 문제가 아니었습니다. Salesforce 데이터 거버넌스(data governance) 문제였으며, 다른 종류의 도구가 필요했습니다.
그날 저녁, 그녀는 Concretio의 Salesforce 데이터 마스킹 솔루션인 Contour라는 제품을 발견했습니다. 이는 AppExchange에서 설치하는 2세대 관리형 패키지입니다. 외부 API나 데이터 내보내기 없이 조직 내부에서 실행됩니다.
그녀는 마케팅 홍수벽을 예상했지만, 발견한 것은 외우기 쉬울 정도로 간결한 워크플로우였습니다.
Contour는 필드 이름(field names), 레이블(labels), 그리고 실제 기록 데이터를 읽어와 개인 정보를 찾아냅니다. 이는 메타데이터와 기록을 확인하는 2단계 스캐너이며, 7가지 패턴 카테고리 전반에 걸쳐 일반 텍스트 필드에서도 **민감 데이터(sensitive data)**를 플래그 지정할 수 있습니다. 전체 조직(Full Org)을 스캔하거나, 사용자 정의 객체(Custom objects)를 선택하거나, 특정 역할이 접근할 수 있는 범위로 한정된 페르소나 기반 스캔(Persona-Based scan)을 실행할 수 있습니다. 프리야는 좁은 범위부터 시작했는데, 이것이 현명한 방식이었습니다.
플래그가 지정된 각 필드에 대해, 해당 필드를 참조하는 모든 페이지 레이아웃(page layout), Lightning 페이지, 프로필 및 권한 집합(permission set)을 보여줍니다. 이것은 Priya가 직접 구축할 시간이 없었던 지도이며, 나머지 프로세스를 안전하게 만드는 핵심입니다.
여섯 가지 템플릿 중에서 선택할 수 있습니다: 마지막 4자리(Last 4), 마지막 2자리(Last 2), 전체 마스크(Full Mask), 이메일(Email), 카드 번호(Card number), 그리고 국가 ID(National ID)입니다. 필드마다 다른 형태가 필요합니다. 카드 번호와 이메일 주소는 같은 방식으로 숨겨져서는 안 됩니다.
클릭 한 번으로 페이지 레이아웃, Lightning 페이지, 프로필의 필드 수준 보안(field-level security) 및 권한 집합 FLS를 업데이트하며, 전체 감사 추적(audit trail)이 남습니다. 이 단계는 예전에는 몇 주 전체를 소요하던 작업이었습니다.
모든 변경 사항은 기록되며, 클릭 한 번으로 정확히 이전 상태로 복원할 수 있습니다. Priya는 다섯 단계를 두 번 읽었습니다. 이것은 그녀가 계속 생각할 수밖에 없었던 부분이었습니다.
여기서 영리한 부분은 원본 데이터를 처리하는 방식입니다. 마스크된 수식 필드(Masked formula fields)는 원본과 함께 생성되며, 대신 대체되는 것이 아닙니다. 실제 값은 절대 수정되지 않으며, 원본을 참조하는 기존 수식들은 계속 작동합니다. 이후 FLS가 누가 원본을 보고 누가 마스크를 볼지 결정합니다. Salesforce 자체에서는 이 세 번째 옵션을 기본적으로 제공하지 않습니다.
모든 관리자(admin)는 대규모 권한 변경에 대한 두려움을 알고 있습니다. 무서운 것은 작업 자체가 아닙니다. 그 변화가 무엇을 건드릴지 모른다는 것입니다.
Contour는 이를 두 가지 방식으로 해결합니다. 어떤 것이 배포되기 전에, 참조 스캐너(reference scanner)는 정확히 어떤 레이아웃, Lightning 페이지, 프로필 및 권한 집합이 변경될지 보여줍니다. 미리 보기를 확인하기 전까지는 아무 일도 일어나지 않습니다. 그리고 만약 무언가 잘못되더라도, 롤백(rollback)은 레이아웃, FLS, Lightning 페이지를 정확히 이전 상태로 복원하고 생성했던 수식 필드들을 삭제합니다.
그리고 프로필 문제가 있습니다. 30개 프로필을 업데이트하는 것은 예전에는 모든 단일 필드를 위해 Setup에서 30번의 수동 작업을 해야 함을 의미했습니다. Contour는 프로필과 권한 집합을 동일 배포의 별도 배치 단계(batch steps)로 처리하며, 둘 다 롤백 시 복원됩니다.
프리야는 Salesforce 데이터 보안을 둘러싼 마비 상태가 부족한 기술 때문이 아니라 안전장치(safety nets)의 부재에서 비롯된다는 것을 깨달았다. 그녀는 필드를 마스킹하는 방법을 알고 있었다. 단지 틀릴 여유를 감당할 수 없을 뿐이었다. 롤백(rollback) 기능 덕분에 이제는 안전하게 실수할 수 있게 되었고, 그것이 사람들을 시작할 용기를 갖게 만든다.
이것이 그녀에게 판매한 데모이다. 두 사람이 보는 하나의 Contact 레코드를 상상해 보라.
같은 객체, 같은 레코드. 다른 권한 집합(permission sets), 다른 보기 방식이다. 아무도 자신의 업무를 수행하는 데 막히지 않으며, 누구도 직무에 필요한 것 이상을 보지 못한다. 처음으로 그녀의 org 내 **민감 데이터(sensitive data)**는 on/off 스위치가 아니라 여러 단계(levels)를 갖게 되었다.
이제 월요일의 문제로 돌아가 보자.
AI 에이전트가 일반 사용자와 다른 점은 무엇일까? 사람은 SSN을 흘깃 보고 계속 스크롤할 수 있다. 하지만 에이전트는 그 값을 요약, 제안된 답장, 또는 케이스 노트에 가져올 수 있으며, 이를 시간당 천 번까지 할 수 있다. Concretio가 말했듯이, **Salesforce 데이터 거버넌스(data governance)**는 Agentforce를 위한 필수 전제 조건이지, 있으면 좋은 기능이 아니다.
해결책은 거의 지루할 정도로 간단했는데, 이것이 바로 보안 수정에서 원하는 바이다:
- 에이전트는 권한 집합으로부터 필드 접근 권한을 상속받는다. 만약 권한 집합이 이메일(Email)을 읽을 수 있다면, 에이전트도 이메일을 읽는다. 대신 에이전트에게
Email_Mask__c에 대한 접근을 부여하면, j*****@g****.com만 보게 된다.
- AI 코드는 변경할 필요가 없다. 백엔드 통합은 별도의 권한 집합을 통해 전체 접근을 유지한다. Trust Layer를 우회하는 방법은 없다. 이것은 Salesforce가 이미 작동하는 방식인 순수한 **필드 수준 보안(field-level security)**이다.
- 같은 레코드, 다른 가시성. 컴플라이언스 사용자는 전체 값을 보고, AI 에이전트는 마스킹된 값을 본다.
프리야는 책상에서 크게 웃었다. 그녀가 두려워했던
이것은 그녀가 앞으로 Salesforce 데이터 보안을 생각하는 방식까지 바꾸어 놓았다. 질문은 더 이상 단순히 '사용자가 이것을 볼 수 있는가?'가 아니었다. 그것은 '사용자, 보고서, 또는 AI 에이전트가 이것을 볼 수 있는가?'로 바뀌었다. 세 가지 대상(audience), 하나의 제어(control) 세트.
그녀는 저녁 내내 AI 에이전트에 대해 걱정하며 시작했다. 자정이 되어서야 감사(audit)에 대해 생각하고 있었다.
그녀의 회사는 결제 및 건강 관련 데이터를 처리하기 때문에 Salesforce 규정 준수가 선택 사항이 아니다. 그것은 끊임없이 발생하는 골칫거리들의 달력과 같다. Concretio는 자신의 마스킹 기능을 여러 가지 요구사항에 맞춰 정리했다.
PCI-DSS v4.0, Requirement 3.4.1. 기본 계정 번호(primary account number)는 표시될 때 마스킹되어야 하며, 이는 2024년 4월부터 의무화되었다. Contour의 카드 마스킹 템플릿은 ****-****-****-1234를 렌더링하고 감사 증거를 생성한다. -
HIPAA의 최소 필요 원칙(minimum necessary standard). 서비스 에이전트는 마스킹된 환자 데이터를 보고 규정 준수 역할은 전체 기록을 본다. 각 역할은 필요한 것만 받는다. -
GDPR Article 25. 설계 단계부터 데이터 보호(Data protection by design). 역할 기반 마스킹에 필드 수준 거버넌스 메타데이터를 추가하면 지속적인 규정 준수를 입증하는 데 도움이 된다. -
SOX와 CCPA도 목록에 있다.
감사 시 가장 중요한 부분은 증거(evidence)이다. 모든 배포는 타임스탬프와 필드 개수와 함께 기록된다. 상세한 이벤트 기록은 Salesforce 파일(ContentVersion)로 저장되므로 다운로드하고 공유할 수 있으며, 로그 레코드가 삭제되어도 살아남는다. 감사관 방문 전에 밤 11시에 설정 메뉴를 통해 스크린샷을 찾아 헤맨 경험이 있는 사람이라면 그 가치를 안다.
좋은 Salesforce 데이터 거버넌스는 단순히 유출을 막는 것에 관한 것이 아니다. 그것은 당신이 유출을 막았다는 것을 침착하고, 요청 시에 증명하는 것에 관한 것이다.
단순한 **필드 수준 보안(field-level security)**으로는 필드를 숨길 수 있지만, 그 절반만 보여줄 수는 없다. 온/오프가 유일한 도구라면, 당신의 에이전트는 눈이 멀거나 과도하게 노출되는 상황에 놓일 것이다. 첫날부터 모든 중요한 필드의 마스킹된 버전을 계획하라.
SSN 필드는 눈에 잘 띄지만, 진짜 위험은 아무도 기억하지 못하는 노트 상자나 사용자 지정 텍스트 필드에 붙여넣어진 민감 데이터입니다. 단순히 레이블만 스캔할 것이 아니라 기록 전체를 스캔해야 합니다. 그렇지 않으면 잘못된 것을 보호하고 임무가 끝났다고 생각하게 될 것입니다.
감사관은 당신이 얼마나 조심했는지 신경 쓰지 않습니다. 그들이 신경 쓰는 것은 당신이 보여줄 수 있는 증거입니다. Salesforce 컴플라이언스는 증거에 존재하므로, 로그를 유지하고, 날짜를 기록하며, 변경 전후 상태를 보존해야 합니다. Salesforce 컴플라이언스를 일 년에 한 번의 급한 작업으로 취급하는 팀은 두 배로 비용을 지불하게 됩니다.
이 모든 것 아래에는 하나의 아이디어가 놓여 있습니다: Salesforce 데이터 거버넌스는 프로젝트가 아니라 습관입니다. 새로운 필드에 대한 **필드 레벨 보안(field-level security)**이든, 새로운 통합을 통해 도착하는 민감 데이터이든, 데이터가 나타난 후에 결정하지 말고, 데이터가 나타나기 전에 누가 무엇을 볼지 결정해야 합니다.
이 수치들은 Concretio의 자체 페이지에서 가져온 것이므로, 이를 공급업체 추정치로 간주하고 직접 계산해 보시기 바랍니다. 그들의 주장은 다음과 같습니다: