-
Salesforce Shield, 실제로 어떤 기능인가: 보안 강화가 필요한 조직을 위한 안내Setup 2026. 7. 3. 17:21반응형
Salesforce를 어느 정도 사용하다 보면 한 번쯈 들어보게 되는 이름이 있습니다. Salesforce Shield. "보안 강화 옵션"이라는 설명은 들었지만, 정확히 어떤 기능이 포함되어 있고, 우리 조직에 필요한지 판단하기가 쉽지 않습니다.
이번 글에서는 Salesforce Shield를 구성하는 네 가지 핵심 기능을 실무 관점에서 정리합니다. 도입을 검토 중이거나, 고객사의 보안 요구사항에 대응해야 하는 분들께 도움이 되길 바랍니다.
Salesforce Shield란
Shield는 Salesforce의 기본 라이선스에 포함된 보안 기능 위에 추가하는 보안 강화 패키지입니다. 별도 라이선스로 제공되며, 금융·의료·공공 등 규제 산업에서의 컴플라이언스 요구를 충족하거나, 민감한 데이터를 다루는 조직의 감사 추적과 접근 통제를 강화하는 목적으로 사용됩니다.
Shield는 크게 네 가지 기능으로 구성됩니다.
1. Event Monitoring: 누가 무엇을 했는가
Event Monitoring은 Salesforce 내에서 발생하는 다양한 사용자 활동을 이벤트 로그 파일 형태로 기록하는 기능입니다. 로그인 기록, 레코드 조회, 보고서 실행, API 호출, 파일 다운로드 등 수십 가지 이벤트 유형이 포함됩니다.
기본 기능과의 차이는 깊이입니다. Salesforce 기본 기능으로도 로그인 기록 정도는 확인할 수 있지만, Event Monitoring은 "어떤 사용자가 언제, 어떤 IP에서, 어떤 레코드를 조회했는가"까지 추적이 가능합니다. 대량 데이터 다운로드나 비정상적인 API 호출 패턴을 감지하는 데 활용할 수 있습니다.
한 가지 알아두면 좋은 점은, Event Monitoring 로그는 기본적으로 24시간 단위로 생성됩니다. 실시간 모니터링이 필요하다면 Real-Time Event Monitoring을 별도로 검토해야 하며, 로그 데이터를 분석하려면 외부 SIEM 도구나 Salesforce의 Einstein Analytics와 연동하는 작업이 추가로 필요합니다.
2. Field Audit Trail: 필드 변경 이력을 얼마나 오래 보관할까
Salesforce 기본 기능에도 필드 히스토리 추적(Field History Tracking)이 있습니다. 그러나 기본 기능은 최대 18개월까지만 이력을 보관하고, 추적 가능한 필드 수도 제한됩니다.
Field Audit Trail은 이 한계를 넘어서기 위한 기능입니다. 최대 10년까지 필드 변경 이력을 보관할 수 있고, 데이터가 Big Object(FieldHistoryArchive)에 저장되어 장기 보관에 최적화된 구조를 갖춥니다.
금융, 의료, 법률처럼 "언제, 누가, 무엇을 어떻게 바꿨는가"를 수년 치 소급해서 입증해야 하는 규제 환경에서 실질적인 필요성이 생깁니다.
다만 실무적으로 주의할 점이 있습니다. Field Audit Trail 데이터는 Big Object에 저장되는데, Big Object는 표준 SOQL의 일부 기능(예: LIKE 연산자, 관계 쿼리)이 제한됩니다. 또한 Field History Tracking 자체를 Field Audit Trail로 대체하는 것이 아니라, 기존 트래킹 위에 장기 보관 레이어가 추가되는 개념이라는 점도 알아두면 좋습니다.
3. Transaction Security Policy: 조건에 따라 접근을 차단한다
Transaction Security는 특정 이벤트가 발생했을 때 실시간으로 정책을 실행하는 기능입니다. 단순한 로그 기록을 넘어, 조건에 따라 사용자 세션을 차단하거나 관리자에게 알림을 보내는 등의 액션을 취할 수 있습니다.
예를 들어 이런 시나리오를 정책으로 구성할 수 있습니다.
- 한 사용자가 짧은 시간 안에 대량의 레코드를 다운로드하려 하면 → 세션 차단 + 관리자 알림
- 특정 국가 IP 대역에서 로그인 시도 감지 시 → 접근 차단
- 특정 프로파일 사용자가 특정 오브젝트 보고서를 실행할 때 → MFA 재인증 요구
정책은 Apex 코드 또는 조건 빌더(Condition Builder)로 구성할 수 있습니다. 과거에는 Apex 작성이 필수였지만, 최근에는 노코드로도 기본적인 정책 구성이 가능합니다.
내부자 위협(Insider Threat) 대응이나 비정상 행동 탐지를 자동화하고 싶은 조직에 특히 유용한 기능입니다.
4. Platform Encryption: 데이터 자체를 암호화한다
Platform Encryption은 Salesforce 데이터베이스에 저장된 데이터를 필드 단위로 암호화하는 기능입니다. Salesforce의 기본 인프라 암호화(전송 암호화, 스토리지 암호화)와는 다른 개념으로, 애플리케이션 레이어에서 데이터를 암호화해 Salesforce 직원조차 내용을 볼 수 없도록 하는 수준을 지원합니다.
암호화 키는 Salesforce가 관리하거나, 조직이 직접 관리(Bring Your Own Key, BYOK)하는 방식 중 선택할 수 있습니다. 키를 직접 관리하면 데이터 주권(Data Sovereignty) 요구를 더 강하게 충족할 수 있습니다.
단, Platform Encryption을 적용하면 해당 필드에서는 SOQL 와일드카드 검색(LIKE '%값%')이나 일부 수식 필드 참조가 제한됩니다. 운영 중인 시스템에 뒤늦게 적용하면 기존 기능이 깨질 수 있기 때문에, 도입 초기부터 암호화 대상 필드를 설계에 반영하는 것이 중요합니다.
기본 기능으로 대체 가능한 것과 그렇지 않은 것
Shield 도입을 검토할 때 자주 나오는 질문이 "표준 기능으로 어디까지 가능한가"입니다.
요구사항표준 기능Shield 필요 여부로그인 이력 확인 Setup Audit Trail, 로그인 기록 불필요 사용자 활성/비활성 이력 Setup Audit Trail 불필요 필드 변경 이력 (18개월 이내) Field History Tracking 불필요 필드 변경 이력 (수년 보관) — Field Audit Trail 필요 레코드 조회 이력 추적 — Event Monitoring 필요 비정상 행동 실시간 차단 — Transaction Security 필요 필드 단위 데이터 암호화 — Platform Encryption 필요 표준 기능만으로 충분한 경우도 많습니다. 특히 사용자 활성/비활성 이력처럼 "언제 계정이 켜지고 꺼졌는가"는 Setup Audit Trail에서 확인할 수 있어서, 이 목적만으로 Shield를 검토할 필요는 없습니다.
도입 전 반드시 생각해볼 것
Shield는 강력하지만, 도입 자체가 목적이 되어서는 안 됩니다. 몇 가지 현실적인 포인트를 먼저 정리하는 것이 좋습니다.
어떤 규제나 내부 정책을 충족해야 하는가. Shield의 각 기능은 특정 컴플라이언스 요건에 대응하기 위해 설계되어 있습니다. 막연히 "보안을 강화하고 싶다"는 수준이라면, 표준 기능과의 갭 분석(Gap Analysis)을 먼저 해보는 것이 순서입니다.
데이터 모델 설계에 미치는 영향을 사전에 검토해야 한다. Platform Encryption은 적용 후에 기존 기능이 제한될 수 있고, Field Audit Trail은 Big Object 구조의 한계를 이해하고 활용해야 합니다. 운영 중에 사후 적용하면 예상치 못한 이슈가 생길 수 있습니다.
라이선스 비용 대비 실제 활용도. Shield는 추가 라이선스 비용이 발생합니다. 도입 후 실제로 로그를 분석하고 정책을 운영하는 담당자와 프로세스가 갖춰져 있지 않으면 비용만 나가고 실효를 거두기 어렵습니다.
마무리
Salesforce Shield는 기본 플랫폼이 제공하지 못하는 감사 추적, 장기 이력 보관, 실시간 정책 제어, 데이터 암호화를 가능하게 하는 기능 묶음입니다.
규제 산업이나 민감한 데이터를 다루는 조직에서는 강력한 선택지가 되지만, 도입 전에 실제 요구사항과 기존 기능 간의 갭을 먼저 명확히 하는 것이 불필요한 투자를 막는 길입니다.
반응형