Trust

Salesforce에서는 Trust 가장 중요한 가치입니다. 이는 플랫폼에서 모든 아키텍처 결정의 기반입니다. 설계자의 경우 Trust 고유한 파트너 관계를 통해 이루어집니다. Salesforce는 해당 기반에 의존하는 보안 솔루션을 설계하면서 자체 설계할 수 있는 안전하고 규정 준수 플랫폼인 인프라, 메타데이터, 도구를 제공합니다.

이 파트너십은 보안 책임을 명확하게 분할하는 프레임워크인 공유 책임 모델을 통해 운영됩니다.

• Salesforce는 인프라스트럭처, 패치 및 규정 준수 인증을 비롯한 플랫폼의 보안을 담당합니다*.*
• 구성, 액세스 제어, 사용자 정의 코드, 데이터 거버넌스를 포함하여 플랫폼의 보안에 대한 책임이 있습니다.******

이 디비전은 아키텍처 책임을 정의하므로 필수적입니다. Salesforce는 수천 개의 조직이 인프라를 공유하는 다중 테넌트 아키텍처를 운영합니다. 플랫폼은 인프라 수준에서 강력한 보안 보호를 제공합니다. 아키텍처 결정에 따라 특정 솔루션이 이해당사자의 신뢰를 얻는지 여부가 결정됩니다.

공유 책임 모델은 물리적 보안, 네트워크 보호, 플랫폼 패치, 인프라 암호화를 대신하여 보안 솔루션 설계를 담당합니다. 이를 통해 해당 기반에 기반한 보안 솔루션 설계(예: ID 및 액세스 관리, 데이터 보호, 통합 보안, 보안 개발 관행, 규정 준수 및 사고 대응 기능)에 집중할 수 있습니다.

설계 시 기술 부채를 복합하는 Trust 무시합니다. 규정이 변경되면 누락된 암호화 전략은 비용이 많이 드는 보완 방법이 됩니다. 자격 증명이 손상되면 관리되지 않은 통합이 취약점이 됩니다. 처음부터 Trust 구축하는 비용은 나중에 수리하는 것보다 항상 저렴합니다.

Trust 네 가지 아키텍처 차원에 걸쳐 통합적으로 작동합니다.

• 보안 컨트롤은 시스템 및 데이터를 보호합니다.
• ID 관리에서 액세스 관리
• 개인정보 보호정책은 사용자 에이전시를 존중합니다.
• 규제 의무를 충족하는 규정 준수 프레임워크

네 가지 측면 모두에 맞춰 설계하는 설계자는 투명성, 제어, 복원력을 통해 Trust 얻고 유지하는 솔루션을 만듭니다.

에이전트의 Trust 에이전트가 작업하는 신뢰할 수 있는 컨텍스트로 확장됩니다. 신뢰할 수 있는 컨텍스트는 에이전트가 명확한 ID 및 권한 경계를 가진 관리되고 확인된 데이터에 액세스할 수 있음을 의미하며, 이는 AI 시스템이 보안, 감사 가능성, 규정 준수를 유지하면서 사용자를 대신하여 사유하고 조치를 취할 수 있도록 합니다. 신뢰할 수 있는 컨텍스트를 설계하는 것은 에이전트 엔터프라이즈 아키텍처의 기본 사항입니다.

이 기둥은 모든 Salesforce 솔루션이 종속되는 플랫폼 보안 기준선을 설정합니다. Agentic Trust 기둥은 자율 에이전트에게 고유한 위험을 해결하기 위해 이 기준을 바탕으로 즉각적인 주입, 행동 관리, 에이전트가 추론 시간 동안 액세스할 수 있는 데이터를 포함합니다. 먼저 기준선을 설계한 다음, Agenttic Trust 지침을 사용하여 에이전트별 컨트롤을 계층화하는 것이 중요합니다.

이 기둥은 다른 프레임워크 우려 사항과 긴밀하게 연결됩니다.

• 신뢰성은 공격에 저항하고 침입 시 복구할 수 있는 인프라에 달려 있습니다.
• 운영적 우수성은 안전한 배포 파이프라인과 사고 대응 기능을 필요로 합니다.
• 공정성은 데이터 및 알고리즘적 결정을 투명하고 윤리적으로 처리해야 합니다.

이러한 기둥은 함께 조직에서 가장 민감한 작업을 Trust 수 있는 솔루션 중심의 통합 접근 방식을 형성합니다.

공유 책임 모델에서 Salesforce 및 아키텍처는 Trust를 유지하기 위해 각각의 책임을 이행해야 합니다. 각 측에서 보안해야 하는 항목을 자세히 살펴보겠습니다.

Salesforce는 다음을 포함하여 플랫폼 및 글로벌 인프라를 보호할 책임이 있습니다.

• 데이터 센터 액세스 제어, 감시, 환경 보호
• Hyperforce 경우 기본 클라우드 공급자(예: 인스턴스에 따라 AWS, Azure 또는 Google Cloud)는 위임받은 책임을 통해 물리적 데이터 센터 보안을 처리합니다. Salesforce Infrastructure 및 Sub-Processors 문서는 각 서비스에 대한 공급자 및 하위 프로세서를 식별합니다.

• DDoS 보호 및 위협 감지를 비롯한 네트워크 계층 보안 제어
• 운송 중(TLS 1.2+) 및 유휴 중(일반적으로 AES-256)의 교통량 암호화

• Salesforce를 통해 취약성 대응 및 플랫폼 패치 배포(보안 고지 사항에 대한 자세한 내용은 security.salesforce.com을 참조하십시오)
• 운영 체제 및 인프라 보안 관리

• 인증 및 증명: Salesforce는 SOC 1/2/3, ISO 27001/27017/27018, FedRAMP 인증(거래 멀티테넌트 플랫폼이 아닌 Government Cloud Plus 및 MuleSoft Government Cloud) 및 PCI DSS 레벨 1 검증을 유지합니다.
• 규제 지원: 이는 비즈니스 협력사 협약(BAA) 또는 GDPR 준수 프로그램이 있는 HIPAA 지원 서비스에 적용됩니다.
• 자세한 내용은 Trust.salesforce.com 및 compliance.salesforce.com을 참조하십시오.

• 테넌트 격리 아키텍처: 공유 메타데이터 중심의 커널은 모든 조직의 데이터와 메타데이터를 조직 ID별로 분할하므로 하나의 조직이 공유 인프라에서 모두 실행되어도 다른 조직의 레코드에 액세스할 수 없습니다. 커널은 유지 관리해야 하는 구성을 통해서가 아닌 모든 쿼리에 구분을 적용합니다.
• 유휴 상태인 인프라 수준 암호화 및 백업 인프라: 기본 플랫폼 라이센스에는 Classic Encryption(AES-128는 사용자 정의 텍스트 필드만 제공)이 포함되어 있습니다. Shield Platform Encryption 별도의 라이센스가 필요합니다(AES-256를 사용하면 자체 키를 가져오고 표준 및 사용자 정의 필드, 파일, 첨부 파일을 제공할 수 있습니다).

이러한 제어를 통해 플랫폼이 안전하고 신뢰할 수 있으며 규정을 준수할 수 있습니다.

데이터, 구성, 운영 프로세스를 안전하게 보호할 책임이 있습니다.

• 정체성과 연합: 싱글사인온(SSO) 및 다단계 인증(MFA)의 경우 사용자의 ID를 확인해야 합니다.
• 액세스 제한: 기술적으로 ID 연결 방법 및 시기는 IP 범위 및 로그인 시간으로 제한됩니다.
• 최소 권한 원칙(PoLP): PoLP를 사용하여 개별 업무를 수행하는 데 필요한 역할, 프로필 및 권한 집합에 대한 액세스 권한만 부여합니다.
• 수명 주기 관리: 사용자 수명 주기 관리 및 액세스 재인증 지침을 연습합니다.

• 데이터 분류, 마스킹, 개체/필드/레코드 수준 보안 사용
• CRUD 권한 및 공유 규칙 적용
• 검증된 전략을 소유하고 테스트하고 배포하여 조직의 데이터를 복원하여 데이터 손실 또는 손상 복구를 제어할 수 있도록 합니다.

• API 인증(예: OAuth 2.0 또는 JWT) 및 명명된 자격 증명을 사용합니다.
• 각 통합의 액세스 범위가 지정되고 사용자와 별도로 감사할 수 있도록 PoLP 권한 집합을 사용하여 전용 통합 사용자를 활성화합니다.
• 보안 끝점 및 외부 시스템 유효성 검사.

• 이벤트 모니터링, 감사 추적, 보안 정보 및 SIEM(이벤트 관리) 통합을 사용합니다.
• 사고 대응 절차 및 보안 검토를 따르십시오.

• 안전한 사용자 정의 코드(예: Apex 또는 Lightning) 및 입력 검증을 사용합니다.
• 코드에 개체, 필드, 공유 권한이 적용되도록 사용자 모드에서 Apex 실행합니다.
• 주입 방지 및 보안 개발 관행을 따르십시오.

• 솔루션 준수 조치를 유지합니다.
• 개인정보보호/동의 관리 및 데이터 보존 정책을 따릅니다.

일부 책임에는 공동 작업이 필요합니다.

• 보안 사고 대응: 두 당사자는 모두 감지 및 응답 활동에 참여합니다.
• 빈약성 관리: Salesforce가 플랫폼을 패치하고, 설계자는 사용자 정의 코드를 패치합니다.
• 보안 모니터링: 플랫폼 생성 보안 신호와 아키텍처 분석을 결합합니다.
• 규정 준수 인증: Salesforce는 플랫폼(예: Government Cloud용 SOC, ISO, FedRAMP)을 인증합니다. 설계자는 인증된 조치 내에서 사용자 정의 개체, 코드, 통합, 구성과 같은 구축된 내용을 소유하여 감사 준수 증거를 제공합니다.
• IDF: Salesforce는 설계자 ID 공급자가 제공하는 어설션을 신뢰합니다. 설계자는 공급자를 보호하고 공급자와 Salesforce 간의 Trust 관계를 유지합니다.
• 키 관리: Salesforce는 자체 키 가져오기 암호화를 사용하여 데이터를 보호하는 키 자료를 생성, 순환, 취소하는 동안 암호화 서비스를 운영합니다.

이 문서의 모든 설계 원칙, 주제 섹션 및 체크리스트 항목은 설계자로서의 책임을 나타냅니다. 공유 책임 모델은 Salesforce Platform에 대한 Trust 얻기 위해 설계하고 구성해야 하는 내용을 구성합니다.

경계는 규제 의무로 확장됩니다. Salesforce는 플랫폼의 인증 및 증명을 유지하고 위반으로부터 인프라를 보호합니다. 아키텍처는 데이터 및 관할에 첨부되는 의무(예: 적용되는 법률, 데이터 분류 방법, 데이터 보존 및 동의 규칙이 적용되는 방법, 관리 중인 데이터 위반을 감지하고 보고하는 방법)에 대한 책임이 있습니다. 아키텍처는 배포에 대한 규정에 따라 배포에 대한 규정에 따라 해당 의무 뒤에 있는 특정 수치(예: 유지 기간 및 알림 기한)를 배포에 대한 규정과 비교하여 결정해야 하며, 이는 관할 지역에 따라 다르며 시간에 따라 변경될 수 있습니다.

다음 원칙을 사용하여 플랫폼의 보안에 대한 아키텍처 결정을 안내합니다.

• 모든 레이어에 제로 Trust 적용. 네트워크 위치, 사용자 친숙도 또는 시스템 원본을 기반으로 Trust 가정하지 마십시오. 데이터, 응용 프로그램, 통합, 인프라 계층에서 인증, 권한 부여, 암호화를 통해 모든 액세스 요청을 명시적으로 확인합니다. 다중 테넌트 아키텍처는 수천 개의 조직과 인프라를 공유하므로 솔루션이 실행되는 네트워크는 신뢰할 수 있는 경계가 아닙니다. 각 요청이 생성된 위치에 대해 신뢰하지 않고 ID, 권한 부여, 컨텍스트 등 각 요청의 본질을 확인합니다.
• 기본적으로 최소 권한 부여. 각 사용자, 통합, 자동 프로세스가 목적을 달성하기 위해 필요한 최소 액세스 수준을 부여합니다. 가장 제한적인 설정(비공개 조직 전체 기본값(OWD) 및 최소 권한)부터 시작하고 문서화된 비즈니스 요구 사항을 기반으로 의도적으로 확장합니다. 4개의 레이어 액세스 모델(조직 → 개체 → 필드 → 레코드)을 사용하여 각 레이어가 위의 레이어를 추가로 제한합니다.
• 방어를 심층적으로 구현하십시오. 하나의 컨트롤이 실패하면 전체 시스템이 손상되지 않도록 여러 보안 컨트롤을 계층화합니다. 예방 제어(예: 작업을 차단하는 CRUD/FLS 적용 및 트랜잭션 보안 정책), 탐정 제어(예: 이벤트 모니터링), 반응형 제어(예: 트랜잭션 보안 단계별 인증 및 알림)를 결합합니다. 인접 레이어가 실패할 수 있는 것처럼 각 레이어를 설계합니다. 필드 수준 보안은 공유 규칙이 너무 허용되는 경우에도 데이터를 보호합니다.
• 설계로 보안 통합. 위협 모델링, 보안 요구 사항, 확인 제어를 초기 개념에서 진행 중인 진화까지 모든 아키텍처 단계에 통합합니다. 구축을 시작하기 전에 스푸핑, 조작, 거부, 정보 공개, 서비스 거부, 권한 상승(STRIDE) 위협 모델링을 수행합니다. 보안은 기술 선택 및 설계 결정을 구성합니다.
• 자동화에 내장된 보안. 자동화된 파이프라인, 구성 템플릿 및 플랫폼 기본값에 보안 제어를 구축합니다. CI/CD의 Salesforce 코드 분석기는 배포 전에 취약점을 포착합니다. Configuration-as-code는 보안 기준선을 적용합니다. 내장형 보안은 일관성을 보장하고 솔루션 복잡성에 따라 보안을 확장할 수 있습니다.
• 개인 정보를 위한 디자인. 초기 아키텍처 단계의 개인정보 보호 원칙을 통합합니다. 데이터 최소화(필수 데이터만 수집), 목적 제한(작업 기능별 액세스 제한), 동의 관리(세분화된 목적별 동의 적용), 데이터 주체 권한(규제 시간 내에 액세스, 수정, 삭제, 이동성 워크플로를 완료하도록 활성화)을 위해 설계합니다.
• 추적성을 위한 설계. 변칙을 감지하는 데 의존하기 전에 모든 결과적 작업을 특성화하고 재구성할 수 있도록 합니다. 데이터, 권한, 구성에 대한 변경 사항이 감사 내역, 필드 내역, 이벤트 로그에 수집되고 해당 레코드를 변경 방지 저장소에 유지해야 합니다. 추적 가능성은 감지, 포렌식, 책임을 위한 전제 조건입니다. 기록되지 않은 내용은 조사할 수 없습니다.
• 사고 대응을 위한 설계. 이벤트 모니터링을 통해 감지 가능성을 위해 설계하고 트랜잭션 보안 정책을 통해 실시간으로 중재합니다. 문서화된 절차 및 격리 경계를 통해 신속한 응답을 활성화합니다. 백업 기능 및 포렌식 보존을 통해 복구를 지원합니다. 테이블판 연습 및 위반 시뮬레이션을 통해 응답을 테스트합니다.

설계자는 Salesforce가 제공하는 플랫폼에서 솔루션을 보호할 책임이 있습니다.

Salesforce와 상호 작용하는 워크로드가 점점 더 많이 핵심 플랫폼 외부에서 실행됩니다. 통합 서비스, 사용자 정의 응용 프로그램, 헤드리스 클라이언트는 사용자를 대신하여 Salesforce API를 자주 호출합니다. 이 패턴을 가속화하기 위해 Salesforce는 플랫폼의 기능을 API, 도구, 명령(예: Salesforce Headless 360)으로 노출합니다. 이러한 애플리케이션을 운영하는 사용자와 상관없이 설계자는 Salesforce를 만나는 Trust 경계를 소유하며, 이를 통해 인증 방법, 사용자가 보유한 ID 및 권한, 보유한 암호, 경계를 넘는 데이터를 결정합니다.

아래의 원칙은 모든 컨테이너화된 통합 플랫폼에 적용됩니다(예: MuleSoft CloudHub).

외부 클라이언트가 명명된 사용자로 인증되면 Salesforce의 플랫폼 보안 모델이 자동으로 적용됩니다. 개체 권한, 필드 수준 보안 및 공유 규칙은 브라우저에서와 동일하게 적용됩니다. 사용자별 인증은 해당 개인의 권한에 대한 모든 호출 범위를 지정하고 감사 내역을 유지합니다. 즉시 사용자의 토큰을 취소하면 클라이언트의 대신 작업 능력이 제거됩니다. 특정 사용자에 대한 작업이 수행될 때마다 공유 서비스 계정보다 이 작업을 선호합니다.

많은 사용자에 대한 토큰을 보유한 클라이언트가 Trust 집중하고 공격자의 가치가 높은 프록시가 되므로 방어적으로 경계를 설계합니다. 도난된 OAuth 토큰 한 개만 클라이언트가 제공하는 모든 사용자의 데이터에 도달할 수 있습니다. 가정적인 것은 아닙니다. 2025년 Salesloft 드리프트 사고로 공격자가 OAuth 토큰을 훔쳐 수백 개의 조직에서 Salesforce 데이터에 액세스하는 데 사용했습니다.

• 사용자 아이덴티티를 전파하지 말고 풀해요. 사용자별 인증 또는 OAuth 2.0 토큰 교환을 사용하여 서비스 홉 전반에 걸쳐 사용자의 ID를 전달합니다(에이전트 ID 및 인증 참조), 따라서 모든 사용자가 아닌 한 명의 사용자의 컨텍스트에 대한 범위가 적용됩니다.
• OAuth 클라이언트 자격 증명 및 새로 고침 토큰을 기본 대상으로 처리합니다. 관리 암호 저장소에 저장하고 자주 순환하고 즉시 취소할 수 있도록 설계를 유지합니다. 프록시 공격자를 신호하는 비정상적인 패턴에 대한 API 사용량을 모니터링합니다.
• 두 측면의 범위를 최소화합니다. 손상된 클라이언트가 관련되지 않은 데이터로 피벗되지 않도록 외부 클라이언트 앱(ECA) OAuth 범위 및 통합 사용자의 Salesforce 권한을 기능에 필요한 최소값으로 제한합니다.
• 외부 클라이언트 앱을 통해 경계를 관리합니다. ECA는 외부 응용 프로그램이 인증하는 방법, 허용되는 플로, 적용되는 범위를 정의하여 해당 응용 프로그램에 대한 새로운 통합을 설계합니다(인증 아키텍처 참조).

클라이언트가 에이전트 사용자 또는 통합 사용자로 실행되는 경우에는 주의해야 합니다. 이러한 ID는 상위 컨텍스트에서 작동할 수 있으며, 경우에 따라 Salesforce의 액세스 제어를 준수하지 않는 외부 시스템에 대해 작동할 수 있으므로 위에 설명된 권한 및 모니터링 규칙을 사용하여 해당 권한을 유지할 수 있습니다.

컨테이너화된 플랫폼에서 통합이 실행되면 컨테이너 수준 격리 자체가 보안 제어로 간주됩니다. 각 응용 프로그램은 응용 프로그램 간에 공유된 런타임 또는 메모리가 없는 전용 컨테이너에서 실행됩니다.

이 격리는 다음을 제공합니다.

• 테넌트 경계 집행: 압축된 응용 프로그램은 동일한 환경을 공유하는 인접 응용 프로그램의 데이터 또는 리소스에 액세스할 수 없습니다. 각 컨테이너에는 분리된 파일 시스템 및 프로세스 공간이 있습니다. 방화벽 및 TLS 구성을 통해 네트워크 격리를 적용하고 권한 기본값에 의존하지 않고 아웃바운드 트래픽을 명시적으로 제한합니다.
• 부호 깊이: 컨테이너 격리를 통해 응용 프로그램 수준 제어 이상의 보안 계층이 추가됩니다. 응용 프로그램 코드에 취약성이 있는 경우에도 컨테이너 경계가 폭발 반경을 제한합니다.
• 규정 준수 세분화: 규제된 워크로드(예: PCI 및 HIPAA)는 전용 컨테이너에서 분리하여 비준수 워크로드와의 혼합을 방지할 수 있습니다.

다중 응용 프로그램 환경을 설계하는 아키텍처는 컨테이너 격리를 사용하여 과업 및 보안 도메인 분리를 적용해야 합니다. 카드 소지자 데이터를 처리하는 금융 서비스 통합은 마케팅 통합과 동일한 환경 내에서도 별도의 컨테이너에서 실행해야 합니다.

컨테이너 간 트래픽은 암호화되어야 하며, 규제 프레임워크에 따라 양측 인증이 필요한 경우 상호 TLS(mTLS)를 적용해야 합니다.

작동 방식:

• 필요한 경우 인바운드 연결에 대해 옵션 상호 TLS(mTLS)를 활성화하도록 TLS 컨텍스트를 구성합니다.
• 클라이언트 인증서 인증과 함께 플랫폼 수준 SSL을 사용하여 플랫폼 서비스와 복제본 간의 통신을 안전하게 보호합니다.
• 규제 프레임워크에 따라 필요한 경우 mTLS를 활성화하도록 TLS 컨텍스트를 구성합니다.
• 수명 주기 및 취소가 중앙 집중화된 상태로 유지되도록 플랫폼의 인증서 저장소를 통해 인증서를 관리합니다.
• 컨테이너 간의 무단 트래픽을 방지하는 네트워크 격리 경계를 적용합니다.

플랫폼 계층의 트래픽을 암호화하면 전송 중인 데이터를 면밀하게 보호할 수 있습니다. 응용 프로그램 계층 HTTPS가 잘못 구성된 경우에도 컨테이너 트래픽은 암호화된 상태로 유지됩니다.

VPN을 통해 온 프레미스 시스템에 연결하는 컨테이너는 전송 중인 데이터를 보호하기 위해 구조화해야 합니다.

• 터널 암호화: 암호화된 VPN 터널을 통해 컨테이너와 온 프레미스 시스템 간의 모든 트래픽을 라우팅합니다. 이는 응용 프로그램 계층 TLS에 관계없이 적용됩니다. 심층 방어를 사용하면 중요한 데이터를 이중 암호화할 수 있습니다.
• 네트워크 세분화 적용: VPN 터널 정책은 컨테이너가 액세스할 수 있는 온 프레미스 네트워크를 제한합니다. 축소된 컨테이너는 VPN이 허용하는 네트워크 이상의 무단 내부 시스템으로 피벗할 수 없습니다.
• 준수 증거: VPN 암호화는 클라우드 환경에서 전송되는 데이터를 보호하기 위해 허용되는 메커니즘 중 하나입니다. HIPAA, PCI-DSS 또는 SOX 제어를 검토하는 감사자는 하이브리드 통합을 위해 전송 시 문서화된 암호화를 기대합니다.

설계자는 최소 권한의 네트워크 액세스를 적용하는 VPN 정책을 설계해야 합니다. 마케팅 통합 컨테이너는 VPN을 통해 모두 액세스할 수 있는 경우에도 내부 금융 시스템으로 라우팅되지 않아야 합니다.

Vanity 도메인(예: 통합 API의 사용자 정의 URL)은 설계자가 TLS 인증서를 Trust 앵커로 관리해야 합니다.

Vanity 도메인(예: 통합 API의 사용자 정의 URL)은 설계자가 TLS 인증서를 Trust 앵커로 관리해야 합니다.

• 인증서 수명 주기 자동화: 자동 인증서 갱신 및 배포를 구현합니다. 만료된 인증서가 통합 Trust 끊고 클라이언트가 인증서 확인 오류와 함께 연결을 거부합니다.
• 인증서 취소 계획: 보안 사고에 대한 인증서 순환 절차를 설계합니다. 비공개 키가 손상된 경우 모든 지역에서 신속한 인증서 재발급 및 배포가 필요합니다.
• 카이퍼 제품군 구성: 이전 TLS 구성(TLS 1.0/1.1 및 약한 암호화)은 규정 준수 감사에 실패했습니다. TLS 1.2+(최소 요구 사항)를 적용하고 인증서 및 클라이언트 구성을 조직 보안 정책에 맞춥니다.
• 인증서 투명 로깅: 최신 TLS 인증서는 인증 기관(CA)에서 공용 인증서 투명도(CT) 로그에 제출됩니다. 각 CT 로그는 X.509v3 확장을 통해 CA가 인증서에 포함하는 로깅의 암호화 증거인 서명 인증서 타임스탬프(SCT)를 반환합니다. 설계자는 crt.sh 또는 자동 경고와 같은 서비스를 사용하여 도메인에 대한 무단 인증서 발급을 위해 CT 로그를 모니터링해야 합니다.

인증서의 잘못된 관리가 Trust 자세에 직접적인 영향을 미칩니다.

• 만료된 인증서: 중단으로 표시되는 인증 실패를 야기합니다. 갱신 워크플로를 시작하려면 만료 30일 이내에 경고 보내기를 모니터링해야 합니다.
• 자명 인증서: 외부 클라이언트를 위한 Trust 체인을 중단합니다. 프로덕션 통합에는 신뢰할 수 있는 인증 기관(CA)이 서명한 인증서가 필요합니다.
• Wildcard 인증서 확장: 과도하게 넓은 와일드카드 인증서(예: *.company.com)를 나타내며, 인증서가 손상된 경우 폭발 반경이 커집니다. 범위가 좁은 인증서는 통합 도메인에 따라 선호됩니다.

컨테이너 배포 지역은 데이터 보존 및 규정 준수 요구 사항에 부합해야 합니다.

• GDPR 데이터 보존: GDPR는 유럽 연합(EU)에서 나가는 개인 데이터에 대한 적절한 보호를 요구하지만, EU 배포 자체는 요구하지 않습니다. EU 지역에 통합을 배포하면 컨테이너 계산 및 데이터 처리가 규제 범위 내에 유지되며, 이는 이 요구 사항을 충족하는 가장 직접적인 방법입니다. EU 외부에서 발생하는 전송은 적절성 결정, 표준 계약 조항(SCC) 또는 바인딩 기업 규칙(BCR)에 따라 계속 허용됩니다.
• 데이터 현지화 법률: 데이터 현지화 요구 사항이 포함된 국가: 러시아(연방법 152-FZ 및 필수 저장) 및 중국(CIIO의 경우 PIPL/CSL), 국가 내 컨테이너 배포가 필요할 수 있습니다. 인도의 DPDP Act of 2023에서는 일반적인 국가 내 보관 의무를 부과하지 않는 블랙리스트 접근 방식을 사용합니다. 정부 알림에 의해 특별히 제한되지 않는 한 모든 국가로 데이터 전송이 허용됩니다. 설계자는 관할 분야별 규정을 이해해야 합니다.
• 국경 간 데이터 전송 메커니즘: 다국적 배포가 필요하지만 데이터가 국경을 넘어야 하는 경우 설계자는 SCC, BCR 또는 기타 법적 전송 메커니즘을 구현해야 합니다.
• 규정 준수 인증 조정: 컨테이너 배포 지역은 Salesforce 규정 준수 인증서와 일치해야 합니다. FedRAMP 승인 워크로드는 미국 지역 배포가 필요합니다. HITRUST 인증 통합의 경우 배포 영역이 활성 HITRUST 인증 범위에 속하는지 확인해야 합니다.

지역 배포 결정은 규정 준수에 직접적인 영향을 미치는 아키텍처의 책임입니다. 재무 팀은 SOX 제어 통합에 대해 미국 전용 배포를 요구할 수 있습니다. 의료 팀은 개인 건강 정보(PHI)를 처리하기 위해 HITRUST 인증 지역이 필요할 수 있습니다.

컨테이너에는 자격 증명, API 키, 암호화 키에 대한 액세스 권한이 필요합니다. 설계자는 노출을 방지하는 암호 관리 프로세스를 설계해야 합니다.

• 하드코딩된 비밀 없음: 컨테이너에 배포된 응용 프로그램 코드 또는 구성 파일에 자격 증명을 포함하지 마십시오. 플랫폼 관리 암호 저장소를 사용합니다.
• 플랫폼 관리 암호 삽입: 플랫폼의 관리 저장소에서 런타임 시 암호를 해결하고(파일 시스템에 유지하는 대신) 로그 또는 콘솔에 노출되지 않도록 자격 증명을 포함하는 구성 값을 보호 상태로 표시합니다.
• 비밀 회전: 순환된 암호를 정상적으로 처리하도록 통합을 설계합니다. OAuth 토큰 새로 고침 패턴, API 키 순환 워크플로, 데이터베이스 암호 변경은 컨테이너를 재배포하지 않아도 됩니다.
• 최소 권한 암호 액세스: 컨테이너에게 기능에 필요한 암호에 대한 액세스 권한만 부여합니다. 마케팅 통합은 동일한 환경을 공유하는 경우에도 금융 시스템 자격 증명에 액세스하지 않아야 합니다.

노출된 암호는 일반적인 통합 보안 사고입니다. 설계자는 자격 증명을 누출하지 않고도 코드 검토, 로그, 오류 메시지, 모니터링 대시보드를 유지할 수 있는 암호 처리 프로세스를 설계해야 합니다.

Salesforce 경계의 응용 프로그램은 규정 준수 로깅 요구 사항을 충족하는 감사 이벤트를 생성합니다.

• 요청/응답 로깅: API 요청, 응답, 라우팅 결정을 기록합니다. 규정 준수 팀은 액세스 감사에 이러한 로그를 사용하여 언제 어떤 데이터에 액세스한 사람을 결정합니다.
• 오류 및 예외 로깅: 컨테이너 로그에서 보안 이벤트(예: 인증 실패, 인가 거부, 유효하지 않은 인증서)를 캡처합니다. SIEM 통합은 실시간 보안 모니터링을 지원합니다.
• 로그 보존 정책: 설계자는 규제 요구 사항을 충족하는 유지 기간을 구성해야 합니다. 해당 최소값은 규정에 따라 설정되며, 프레임워크에 따라 다르며, 시간에 따라 변경되므로 하드 코딩 값이 아닌 규정에 대해 각 숫자를 확인하는 잘 유지되는 규정 준수 소스에서 파생해야 합니다.
• 로그 암호화 및 액세스 제어: 감사 로그에 민감한 메타데이터가 포함될 수 있습니다. 로그는 계속 암호화되고 권한이 있는 보안/규정 준수 담당자만 액세스할 수 있어야 합니다. 로깅이 부족하면 사고 조사가 방지되고 규정 준수 감사가 실패합니다. 설계자는 로깅 용량(예: 성능 영향 및 저장소 비용)과 규정 준수 및 보안 조사 요구 사항의 균형을 맞춰야 합니다.

위협 모델링은 이전 또는 이후에 발생하는 별도의 단계가 아닌 솔루션 설계의 일부여야 합니다. 잠재적인 위협을 모델링하고 디자인이 발전함에 따라 모델을 다시 살펴보아야 하므로 보안이 아키텍처를 세분화하는 대신 아키텍처를 구성할 수 있습니다. Salesforce가 인프라 보안(예: 네트워크 보호, OS 경화, 취약성 관리)을 관리하는 동안 구성, 통합, 사용자 정의 코드에서 응용 프로그램 계층 위험을 식별해야 합니다. 아래에 나열된 Salesforce별 위협 벡터에 STRIDE 프레임워크(스푸핑, 변형, 거부, 정보 공개, 서비스 거부, 권한 상승)를 적용합니다. 데이터가 시스템, 네트워크 또는 권한 수준을 넘는 Trust 경계 식별

다음 Salesforce별 위협 모델링 고려 사항에 STRIDE 프레임워크를 적용합니다.

• 다중 조직 데이터 흐름은 각 교차 시 명시적 인증 및 인가를 요구하는 추가 Trust 경계를 생성합니다.
• 외부 통합은 API 및 미들웨어를 사용하므로 플랫폼 보안 제어를 우회하는 공격 벡터를 도입할 수 있습니다.
• 사용자 지정 Apex 및 Lightning 구성 요소는 주입, XSS, 액세스 제어 적용을 위한 보안 코딩 분석을 필요로 합니다.
• Experience Cloud 사이트는 인증되지 않은 사용자 또는 경량 인증된 사용자에게 공격 영역을 확장합니다.
• 제3자 및 ISV 코드(예: 관리 패키지, AgentExchange 목록, 연결된 앱, 타사 커넥터, 클라이언트측 JavaScript 라이브러리 및 에이전트가 호출하는 외부 AI 서비스)는 공급망 벡터로서 설치 시 또는 런타임 시 Trust 경계를 넘어갑니다.

제3자 및 ISV 코드는 Trust 경계의 일부입니다.

관리 패키지 또는 AgentExchange 목록은 조직 내에서 부여한 권한으로 실행되므로 보안 조치가 설치할 때 보안 조치가 됩니다. Salesforce 보안 검토는 AppExchange 또는 AgentExchange에 도달하기 전에 나열된 각 패키지를 점검합니다. 해당 포트 이후에는 모든 것을 소유합니다.

• 자체 데이터 분류 및 위험 조치에 대해 패키지 평가
• 문서화된 기능에 필요한 최소 권한 부여
• 게시자의 릴리스를 사용하여 최신 상태로 유지
• 자체 코드에 적용하는 것과 동일한 이벤트 모니터링 및 감사 제어를 통해 활동을 모니터링합니다.

솔루션 스택의 모든 계층에 보안 제어를 적용합니다. 한 레이어의 제약으로 인해 전체 시스템이 노출되지 않아야 한다는 점에 유의하십시오.

위 및 아래 레이어가 실패할 수 있는 것처럼 각 레이어를 설계합니다. 여러 개의 독립 제어 기능이 복원 능력을 제공한다는 점에 유의하십시오.

제로 Trust 네트워크 위치 또는 이전 인증 상태를 기반으로 암시적 Trust 제거합니다. 모든 요청은 독립적으로 인증 및 승인되어야 합니다.

Zero Trust 적용:

• MFA, 세션 정책 및 컨텍스트(예: IP, 장치, 시간 및 동작)를 기반으로 조건부 액세스를 통해 지속적인 확인을 통해 사용자 액세스
• 모든 호출에서 OAuth 토큰 검증, 인증서 기반 상호 TLS, IP 허용 목록을 통한 통합 연결
• 명시적 인증을 통해 시스템 간 통신, 신뢰할 수 있는 내부 시스템에도 적용
• 모든 쿼리 및 작업에 대한 CRUD 및 FLS 적용을 통해 데이터 액세스

보안 자산 재고는 보안 설계 입력입니다. 위협 모델만 적용하고 최소 권한을 적용하고 먼저 열거한 공격 영역을 모니터링할 수 있으므로 보안 관련 자산 추적은 보안에 종속되는 설계 결정에 속합니다. 이는 Operational Excellence가 적용하는 운영 구성 관리와는 다릅니다(예: 운영 안정성을 위해 조직 설정 버전 지정 및 구성 드리프트 감지). 다시 말해, 보안 위험이 있는 자산은 무엇이며 그 이유는 무엇입니까?

민감한 데이터를 저장하는 사용자 정의 개체, 외부 시스템 통합, 공개 API, 특권 계정, 프로덕션 액세스 보조금, 고급 권한이 있는 설치된 패키지를 포함하여 모든 보안 관련 자산의 최신 재고를 유지 관리합니다.

보안 자산 재고에는 다음이 포함되어야 합니다.

• 기밀 또는 제한된 데이터가 포함된 사용자 정의 개체 및 필드
• 통합 끝점 및 인증 메커니즘
• 권한이 높아진 사용자(예: 모든 데이터 수정, 모든 데이터 보기, 사용자 관리)
• API 전용 통합 사용자 및 권한 범위
• 외부 클라이언트 앱(ECA) 및 OAuth 범위와 함께 조직에 계속 존재하는 레거시 연결된 앱
• 설치된 AgentExchange 패키지 및 권한 부여
• Experience Cloud 사이트 및 인증 및 외부 공유 모델
• 상향 공유 모드가 있는 사용자 정의 Apex 클래스
• 레거시 클래스에 특히 주의하십시오. 공유 선언을 생략하는 API 버전 66.0 이전에 컴파일된 코드는 기본적으로 "공유하지 않음"으로 지정됩니다(예: 시스템 모드, 실제 사용자의 레코드 액세스를 우회). API 버전 67.0(Summer '26)에서 생략된 선언은 대신 기본적으로 "공유됨"으로 지정되고 데이터베이스 작업은 사용자 모드로 실행됩니다. 그러나 기존 클래스는 v67.0 이상에서 다시 컴파일될 때까지 기존 동작을 유지하므로 이전 버전에서 전달된 선언되지 않은 클래스는 자동으로 상향으로 유지됩니다.

최소 권한을 적용하는 ID 컨트롤을 설계 및 구성할 책임이 있습니다.

PoLP를 사용하여 컨트롤을 제대로 설계하고 구성하는 방법을 자세히 살펴보겠습니다.

Salesforce는 조직, 개체, 필드, 레코드와 같은 네 가지 고유한 계층을 통해 액세스 제어를 적용합니다. 네 가지 계층을 모두 의도적으로 활용하는 솔루션을 설계해야 합니다. 핵심 액세스 제어는 권한을 기반으로 하며, 즉, 액세스는 추가적이며 레코드에 도달하기 위해 사용자에게 모든 계층에서 권한을 부여해야 합니다. 핵심 플랫폼에는 일반화된 "거부 재정의 허용" 규칙이 없으므로 대상 거부를 통해 이미 부여된 광범위한 보조금에 대한 액세스를 실행 취소할 수 없습니다.

권한이 높은 계층은 제한할 수 있는 비용을 지불하지 않지만, 조직 전체 기본값 또는 개체 권한을 조기에 확장하면 필드 수준 보안 및 공유 구성에 의존하여 부여되지 않았어야 했던 액세스 권한을 막을 수 있습니다.

제한 규칙 및 무시 권한은 액세스를 빼는 두 가지 내장 예외이지만 각각 범위가 좁습니다(레코드 수준 필터링에 대한 제한 규칙 및 권한 집합 그룹 내에서 부여된 권한에 대한 무시) 일반화된 거부 계층이 아닌.

중요한 데이터가 포함된 개체에 대해 OWD를 비공개로 설정합니다. OWD를 공용 읽기 전용(공용 읽기/쓰기 제외)으로 열면 레코드가 광범위하게 노출되고 잠재적으로 중요한 재구축 없이 나중에 액세스를 제한할 수 있는 기능이 손상됩니다. 성숙한 조직에서 가장 일반적인 Trust 부채는 초기 구현 중에 설정된 허용된 OWD로 인해 발생합니다.

레코드 레이어는 다음과 같이 공유 피라미드로 묘사되는 부여 및 제한 모델을 따릅니다. OWD는 제한적인 기준선을 설정하고 역할 계층 구조, 공유 규칙, 수동 공유를 오픈 액세스를 상향으로 설정합니다. 두 가지 컨트롤은 액세스 권한을 부여하는 대신 액세스 권한을 제거하도록 해당 플로를 반전시키며 두 가지 모두를 의도적으로 설계할 가치가 있습니다.

• 제한 규칙은 사용자가 이미 액세스 권한이 있는 레코드 내에서 볼 수 있는 내용을 필터링하므로 광범위한 개체 액세스 권한이 있는 사용자에게는 계속해서 규칙이 허용하는 하위 집합만 표시됩니다.
• 무시 권한은 권한 집합 그룹 내의 특정 권한을 제거하므로 재사용 가능한 그룹에서 액세스를 어셈블링한 다음, 지정된 모집단이 보유하지 않아야 하는 항목을 제거할 수 있습니다.
• 기부금 기반 레이어만으로도 과도한 프로비저닝 또는 여러 좁은 권한 집합에 대한 세부 액세스 권한을 강제 적용할 경우 이러한 규칙에 도달하십시오.

Salesforce에서 플랫폼 요구 사항으로 요구하는 사용자 인터페이스를 통해 프로덕션 환경에 로그인하는 모든 사용자에게 MFA(다단계 인증)를 적용합니다. 이 요구 사항은 API 전용 액세스에 적용되지 않습니다. JWT 전달자 또는 클라이언트-자격 증명 플로를 사용하는 통합은 면제되어 있으므로 대신 인증서 관리 및 IP 제한으로 통합을 보호해야 합니다. MFA 요구 사항을 특권 작업으로 확장합니다.

SSO(단일 등록)의 경우 SAML 2.0 또는 OpenID Connect 프로토콜이 선호됩니다. 세션 정책을 구성하여 보안과 유용성의 균형을 맞춥니다.

• 세션 시간 초과: 사용자 권한 수준에 적합한 세션 시간 제한을 구성합니다(권한이 높은 계정의 경우 시간 제한이 짧아도 비관련 세션으로 인한 위험은 줄어듭니다).
• IP 제한: 관리 프로필 및 통합 사용자에 대한 제한을 적용합니다.
• 로그인 시간: 서비스 계정을 예상되는 운영 기간으로 제한합니다.
• 장치 활성화: Salesforce의 기본 장치 활성화(인식되지 않는 장치의 로그인에 대한 ID 확인)에 의존하고 특권이 높은 계정에 대한 MFA 및 IP 제한을 추가합니다. 기본 장치 Trust 태도가 외부 ID 공급자를 통해 적용됩니다.
• 세션 IP 잠금: 세션이 시작된 IP 주소로 세션을 잠그면 다른 네트워크 위치에서 도난된 세션 ID를 재생할 수 없습니다. 이렇게 하면 보안이 강화되지만 모바일 사용자에게 마찰이 추가되고 자동 통합이 중단될 수 있습니다. 잠금이 실행되지 않는 경우 보상 제어로 "모든 요청에 로그인 IP 범위 적용"을 사용하여 프로필 수준에서 엄격한 로그인 IP 범위를 적용합니다.
• 높은 보증 세션: 정기 로그인 자체가 중요한 작업에 도달할 수 없도록 세션 보안 수준 정책 및 액세스 정책을 통해 중요한 작업(예: 보고서 액세스 또는 IP 범위 관리)에 대해 높은 보증 세션 보안 수준을 요구합니다. Lightning Experience MFA를 다시 프롬프트하여 표준 세션을 높은 보증으로 전환하는 것은 지원되지 않으므로 표준 세션 사용자가 상승하라는 메시지가 표시되지 않고 게이트된 작업에서 차단되는 것을 알고 이 정책 범위를 지정합니다.
• 세션 쿠키 보호: 스크립트가 세션 ID 쿠키를 읽을 수 없도록 HttpOnly 특성을 요구하고 세션이 처음 사용된 도메인에 세션을 잠그면 세션 하이재킹이 끊어집니다.
• 통합 사용자를 위한 API 전용 액세스: 사용자 인터페이스를 통해 로그인할 수 없도록 통합 및 서비스 계정을 API 전용 인증으로 제한합니다. 새 빌드의 경우 Salesforce 통합 사용자 라이센스로 최소 액세스 - API 전용 통합 프로필을 할당합니다. 이전 Salesforce API 전용 시스템 통합 프로필은 Spring '24부터 프로비저닝된 조직에서 사용할 수 없으므로 사용되지 않는 프로필이 아닌 현재 프로필에 대한 새로운 통합을 설계하십시오.

API 인증의 경우 통합 패턴에 적합한 OAuth 2.0 플로를 선택합니다.

• JWT 전달자 흐름: 이는 통합 사용자로 실행되는 서버 간 통합에 사용됩니다(인증서 기반, 신뢰할 수 있는 환경에서 기본 설정).
• 웹 서버 플로(권한 부여 코드, PKCE 포함): 이를 사용자 인가가 필요한 웹 응용 프로그램 및 특정 사용자 컨텍스트를 유지 관리해야 하는 서버 간 통합에 사용합니다(번복되는 브라우저 프롬프트를 방지하기 위해 서버측에 새로 고침 토큰 저장).
• 권한 부여-코드 플로 재생 안전: 가로채기된 인가 코드를 요청한 클라이언트를 제외한 모든 사람이 사용할 수 없도록 PKCE를 적용하고 새로 고침 토큰을 순환(사용할 때마다 새로 고침 토큰을 발행하고 이전 새로 고침 토큰을 무효화)하여 도난된 새로 고침 토큰의 유효 기간이 좁습니다. 사용 중지된 토큰을 재사용하면 신호가 손상됩니다.
• 헤드리스 ID 인가 코드 및 자격 증명 플로(PKCE 사용): 리디렉션 기반 웹 서버 플로에서 클라이언트가 없는 브라우저를 가정하여 특정 사용자 컨텍스트에서 실행해야 하는 실제로 헤드리스 비브라우저 클라이언트에 사용합니다.
• 장치 흐름(헤드리스 장치용): 2025년 8월 28일부터 Salesforce는 기본 Salesforce CLI 연결된 앱의 OAuth 2.0 장치 플로를 영구적으로 차단했습니다. CLI 및 CI/CD 도구에 대신 웹 서버 플로(sf 조직 로그인 웹) 또는 JWT 전달자 플로(sf 조직 로그인 jwt)를 사용합니다.

사용자 이름-암호 플로를 사용하지 마십시오. Salesforce는 Summer '23 이후에 생성된 조직에 대해 기본적으로 이를 차단하고 이 플로에 대한 사용 중지 계획을 게시했습니다. 계속해서 사용자 이름-암호 플로에 의존하는 기존 통합은 마이그레이션을 지연된 기술 부채로 처리하는 대신 JWT 전달자 플로 또는 클라이언트 자격 증명 플로로 마이그레이션해야 합니다.

해당 플로는 통합을 나타내는 앱 등록에 구성됩니다. Spring '26부터 Salesforce는 해당 등록을 연결된 앱에서 외부 클라이언트 앱(ECA)으로 전환합니다. 새 연결된 앱 만들기는 기본적으로 비활성화되고 ECA는 새로운 통합을 설계할 수 있는 구조입니다. 기존 연결된 앱은 설치된 상태로 유지되지만 조직이 마이그레이션되면 더 이상 인증을 처리하지 않으므로 연결된 앱을 영구 모델로 처리하는 대신 통합 인증 방법을 감사할 때 마이그레이션을 고려하십시오.

인증 플로를 선택하는 것 외에도 앱이 연결할 수 있는 고유한 거버넌스를 만듭니다.

• 통합당 하나의 등록: 각각의 새 통합에 대해 전용 외부 클라이언트 앱을 등록하고 각 기존에 대해 고유한 연결된 앱을 등록합니다. 여러 개에 걸쳐 하나의 광범위한 등록을 공유하는 대신 각 통합에 필요한 OAuth 범위로만 범위를 지정하는 전용 등록은 각 통합의 액세스를 독립적으로 감사하고 취소할 수 있도록 유지합니다.
• 액세스를 명시적으로 사전 승인합니다(권장): 관리자가 사용자가 자체 승인하는 대신 프로필 및 권한 집합을 통해 액세스 권한을 부여하도록 외부 클라이언트 앱의 허용된 사용자 정책을 "관리자 승인 사용자가 미리 승인됨"으로 설정합니다. 관리자가 설정에서 직접 구성하며, 연결할 수 있는 사람을 결정하기 위해 Salesforce에서 권장하는 제어입니다.
• API 액세스 제어(더 엄격하고 허용 목록 기반): 더욱 엄격한 제어를 위해 API 액세스 제어는 관리자 승인 사용자를 허용 목록으로 지정된 연결된 앱으로만 제한합니다. 활성화하려면 Salesforce 고객 지원에 요청해야 하므로 셀프 서비스 설정으로 처리하지 않고 설계할 때 해당 단계를 계획합니다.

코드, 구성 파일 또는 버전 관리에 자격 증명을 포함하지 마십시오. 명명된 자격 증명 및 외부 자격 증명을 사용하여 순환 기능을 사용하여 인증을 중앙에서 관리합니다.

일반적인 사용자 인증과 달리 에이전트는 고유한 ID 모델을 필요로 하며, 올바른 모델은 에이전트가 직원 또는 외부 사용자를 제공하는지 여부에 따라 다릅니다. 올바르게 ID를 설계하면 에이전트 보안의 기반이 됩니다. 이는 에이전트가 액세스할 수 있는 데이터와 에이전트가 액세스할 수 있는 작업을 결정합니다.

내부 및 외부 에이전트. nts를 자세히 살펴보겠습니다.

• 직원 대리인(내부): 로그인한 사용자의 컨텍스트 내에서 과업을 실행합니다. 이러한 과업은 사용자의 라이센스, 권한 집합, 필드 수준 보안, 공유 규칙을 상속하므로 별도의 에이전트 ID가 프로비저닝되지 않으며 기존 보안 프레임워크는 에이전트가 수행할 수 있는 작업을 관리합니다.
• 고객 대리인(외부): 공개 채널을 통해 상호 작용하고 공개 사이트 게스트 사용자가 아닌 전용 에이전트 사용자, 전문 통합 사용자로 실행합니다. 전용 통합 사용자로 실행하면 에이전트가 백엔드 작업을 수행하고 데이터에 액세스할 수 있습니다(인증되지 않은 게스트 프로필이 액세스할 수 없는 경우). 그러나 명시적 최소 권한 권한이 적용됩니다. 고객 에이전트를 만들 때 액세스 권한이 최소한인 새 에이전트 사용자를 프로비저닝하고 작업에 필요한 특정 권한만 부여합니다.

에이전트의 작업이 여러 서비스에 걸쳐 있는 경우 공유 또는 게스트 ID로 속하지 않고 각 서비스 홉 전반에 걸쳐 사용자의 ID를 전파합니다. Salesforce OAuth 2.0 토큰 교환 플로는 다음을 지원합니다.

클라이언트가 사용자의 기존 ID 공급자 토큰을 표시하고 Apex 토큰 교환 처리기가 Salesforce 사용자에게 매핑하고 Salesforce 액세스 토큰을 발행하므로 원래 사용자의 컨텍스트가 서비스 계정으로 축소하는 대신 요청을 따릅니다. 에이전트의 사용자 ID를 사용하여 비정상적인 동작을 감지하여 이벤트 모니터링을 통해 에이전트 활동을 모니터링합니다.

연결을 시작한 사람 및 작업이 실행되어야 하는 컨텍스트에 따라 올바른 모델을 선택할 수 있습니다.

일반적인 연결 시나리오는 다음과 같이 권장 접근 방식을 매핑합니다.

관리 보고 차트가 아닌 데이터 액세스 요구(사용자에게 다른 사용자가 소유한 레코드에 대한 액세스 권한이 필요한 사용자)에 대한 역할 계층을 설계합니다. 각 수준은 공유-계산 오버헤드를 추가하므로 역할 계층 깊이가 비공개 OWD 설정 및 대용량 데이터가 있는 조직에서 더 많은 가중치를 가져오는 고려 사항인 비공개 OWD 설정이 부여되지 않는 수준을 추가하는 대신 실제 데이터 액세스 관계를 따르도록 합니다.

권한 집합 및 권한 집합 그룹은 유연하고 추가적인 액세스를 제공하여 프로필 확산의 필요성을 줄입니다. 프로필이 아닌 권한 집합 및 권한 집합 그룹을 통해 기능 액세스 권한을 부여합니다. 그러면 액세스가 추가 가능하고 감사 가능해집니다. 프로필은 계속해서 필요합니다. 로그인 시간 및 IP 제한과 함께 페이지 레이아웃 할당, 레코드 유형 기본값, 앱 가시성을 제어합니다. 제거할 구조가 아닌 지속적인 액세스 모델의 일부로 프로필을 처리합니다.

트랜잭션 보안 정책은 기준선의 일부가 아니며 핵심 권한 부여 모델을 보완하는 추가 기능입니다. 위의 ID, 역할, 프로필, 권한 집합, 공유 컨트롤은 이미 자체적으로 안전한 권한 부여 조치를 설정하고 트랜잭션 보안은 상단에 실시간 컨텍스트 평가를 추가합니다. 일반 패턴을 초과하는 대량 데이터 다운로드, 예기치 않은 지역에서의 로그인, 변경 기간 외부의 권한 변경 등 비정상적인 동작을 감지하고 차단하는 정책을 구성합니다.

보안 제어는 아키텍처의 책임인 가용성 제약을 가집니다. IP 제한이 지나치게 넓으면 네트워크 변경 시 합법적인 사용자가 잠길 수 있으며, 트랜잭션 보안 정책이 너무 적극적으로 조정되면 유효한 비즈니스 활동을 차단할 수 있습니다. 따라서 이러한 제어를 실제 위험 범위로 지정하고, 적용하기 전에 모니터 전용 모드로 전환하고, 제어 실패 시점에 대한 유리 경로를 설계할 수 있습니다.

당사 책임: 역할 계층을 설계하고, 권한 집합을 만들고, 트랜잭션 보안 정책을 구성합니다.

기존 역할 기반 액세스 제어)는 사용자의 역할을 기반으로 권한을 부여합니다. ABAC(특성 기반 액세스 제어)는 데이터, 사용자, 컨텍스트의 특성을 기반으로 인가 결정을 내립니다.

대부분의 요구 사항에서 핵심 공유 모델은 액세스를 완전히 표현합니다. 레코드별 공유에서 표현할 수 없는 데이터 분류를 따라 액세스해야 하는 경우 전용 ABAC에 대한 범위: Data 360 ABAC는 태그 및 주석을 통해 이를 제공합니다.

Data 360 ABAC는 다음을 통해 작동합니다.

• 데이터 개체에 적용된 태그(예: 개인 식별 정보(PII), 금융, 의료, 기밀 태그)를 기반으로 액세스 규칙을 정의하는 태그 기반 정책입니다.
• 정책 기반 권한 부여 결정을 지원하기 위해 데이터 개체에 주석이 적용됩니다.
• 새 조직과 기존 조직의 기본 "모두 허용" 정책은 세분화된 관리 정책을 사용하려면 명시적으로 삭제해야 합니다.

주된 아키텍처 용도는 데이터 분류 적용입니다. 분류 계층이 ABAC 적용을 촉진하는 방법은 데이터 보호 및 개인정보보호 아래의 데이터 분류를 참조하십시오.

이 수준의 세분화는 운영 비용을 부과합니다. 핵심 공유는 검사 가능한 작은 규칙 집합(OWD, 역할 계층, 공유 규칙)에서 "누가 이 레코드를 볼 수 있으며 왜?"라는 질문에 답변하지만, ABAC는 평가 시간에 데이터 태그, 사용자 특성, 컨텍스트 조합에서 답변을 도출하므로 정책 및 태그가 누적될 때 효과적인 액세스가 근거하고 감사하기가 더 어려워집니다.

설계 요구 사항으로 감사 가능성을 적용합니다. 태그를 일관적으로 적용하고, 정책 집합을 적용하는 분류에 맞게 소규모로 유지하고, 사용자가 지정된 레코드에 도달한 이유를 재구성할 수 있는 기능을 유지합니다. 소유권 기반 모델을 일반 대체하는 대신 레코드별 공유가 실제로 표현할 수 없는 분류 중심 사례에 ABAC를 예약합니다.

시스템 관리자, 통합 사용자, 자동화된 프로세스 계정을 포함하여 고급 권한이 있는 계정을 식별하고 보호합니다. 해당 계정은 공격자의 중요한 대상입니다.

중요 영향 계정에 고급 제어를 적용합니다.

• 피싱 방지 MFA 필요
• 로그인 IP 범위를 알려진 관리 위치로 제한
• 로그인 경고 및 권한 변경 알림 활성화
• 조직의 위험 허용 및 규정 준수 요구 사항에 따라 빈도가 결정되는 고권위 계정에 대해 문서화된 증거를 사용하여 정기적인 액세스 검토 수행
• 비상 액세스 및 사용 후 감사를 위한 고장난 절차 유지

통합 및 서비스 계정의 경우:

• OAuth 플로 적용, 사용자 이름-암호 플로 사용 안 함
• IP 제한 적용
• 자격 증명 순환 일정 구현
• 이벤트 모니터링을 통해 비정상적인 API 사용 패턴 모니터링

당사 책임: 중요 계정을 식별하고 고급 제어를 적용하거나 분기별 검토를 수행합니다.

적절한 초기 액세스 권한이 있는 사용자를 프로비저닝하고 역할이 발전함에 따라 권한을 조정하거나 더 이상 액세스가 필요하지 않은 경우 프로비저닝을 즉시 해제하도록 자동화된 프로세스를 설계합니다.

ID 공급자의 자동 프로비저닝을 위해 교차 도메인 ID 관리(SCIM) 시스템을 구현합니다. SAML 또는 OpenID Connect 적시 프로비저닝은 처음 로그인할 때 사용자를 만들지만 사용자 프로비저닝이 해제되지 않는 대안입니다. 다시 말해, SCIM은 수명 주기의 핵심이지만 선택 항목이 아닙니다.

ID 수명 주기에는 다음이 포함됩니다.

• 프로비저닝: HR 시스템 이벤트로 트리거되는 작업 기능과 일치하는 기준 액세스 권한이 있는 계정을 만듭니다.
• 액세스 조정: 역할이 확장될 때 추가 권한을 부여하고 역할이 변경되면 권한을 취소합니다.
• 정기적인 재인증: 분기별로 액세스를 검토하고 확인합니다.
• 제공 중단: 고용이 종료되거나 역할에 더 이상 Salesforce 액세스 권한이 필요하지 않으면 즉시 액세스를 취소합니다.

관리자가 정기적으로 팀의 권한을 검토하고 유효성을 검사할 때 액세스 재인증 프로세스를 구현합니다. 검토 주기는 위험 및 규정 준수 요구 사항을 기반으로 합니다.

당사 책임: SCIM을 구현하고 프로비저닝 워크플로를 설계하거나 분기별 재인증을 수행합니다.

데이터를 여러 조직으로 분리하는 것은 단순히 비용 또는 보존 결정으로 간주되는 경우가 있습니다. 아키텍처적으로는 보안 제약이며, 관리 결과는 액세스 설계에 속합니다.

절연은 주요 이점입니다. 별도의 조직은 데이터 집합 간에 가능한 한 강력한 경계를 제공합니다. 집합 공유 모델 및 교차 테넌트 권한 출혈은 없지만, 이를 요구하는 관할 지역에 대한 명확한 규제선이 있습니다. 같은 경계가 거버넌스를 조각화합니다. 단일 조직 내에서 한 번만 유지해야 하는 모든 액세스 제어(예: 권한 집합 설계, 역할 계층, 중요 영향 계정 강화, 상태 확인 기준선, 이벤트 모니터링, SIEM 상관 관계)는 이제 조직당 곱해지므로 모든 조직에서 일관성을 유지해야 합니다. 한 조직에서 권한을 줄이고 다른 조직에서 누락된 권한은 공격자가 찾고 활용할 수 있는 불일치가 생성되므로 조직 간의 드리프트가 자체 공격 영역을 만듭니다. Cross-org 통합은 이전에 존재하지 않은 인증된 Trust 경계를 추가합니다. 각 교차 조직 통합은 보안 및 모니터링이 필요한 연결입니다.

따라서 조직을 분할하기 전에 거버넌스 승수와 비교하여 격리 혜택을 가중해야 합니다. 단일 조직 내에서 하드 현지화 요구 사항 또는 고객의 계약상 격리 요구 사항을 충족할 수 없는 사례에 대해 다중 조직을 예약합니다. 도입 시 처음부터 모든 조직에 대해 동일하게 적용되도록 액세스 모델, 모니터링, 구성 기준선을 설계해야 합니다.

당사 책임: 다중 조직 결정은 비용뿐만 아니라 보안 제약으로 취급하십시오. 다중 조직이 필요한 경우 모든 조직에 액세스 제어, 모니터링 및 상태 확인 기준을 일관되게 적용하고 각 교차 조직 통합을 Trust 경계로 보호합니다.

데이터 분류, 암호화 구성, 개인 정보 보호 제어 설계에 대한 책임이 있습니다.

데이터 및 개인 정보를 적절하게 보호하는 방법을 자세히 살펴보겠습니다.

데이터를 올바르게 분류하려면 데이터를 알아야 합니다. 전반적인 아키텍처 과업은 비즈니스 도메인을 이해하고 보유한 데이터, 데이터의 의미 및 중요한 데이터가 있는 위치를 카탈로그화하는 데이터 사전을 유지하는 것입니다. 먼저 식별한 데이터만 분류하거나 보호할 수 있습니다.

적절한 보호 제어를 구동하는 데이터 분류 스키마를 설정합니다. 분류 레이블은 자체적으로 아무것도 보호하지 않습니다. 이는 적용하는 컨트롤에 대한 입력이므로 할당하는 모든 분류는 구체적인 암호화, 액세스, 보존 또는 모니터링 결정에 매핑해야 합니다. 데이터 모델링 중에 결정된 분류는 암호화 요구 사항, 액세스 제어, 보존 정책, 규정 준수 의무에 직접적으로 영향을 미칩니다.

Salesforce에서는 조직의 규제 요구 사항 및 비즈니스 요구 사항에 맞게 조정할 수 있는 프레임워크를 제공하는 4계층 스키마를 사용합니다. 많은 기업이 업계 표준에 부합하는 유사한 모델을 사용합니다(예: ISO 27001 및 NIST). 구현은 규정 준수 의무(예: HIPAA, PCI DSS, GDPR, 산업 규정) 및 비즈니스 컨텍스트를 반영해야 합니다.

필드 수준에서 분류를 적용합니다. 단일 계정 레코드에 공개 필드(예: 회사 이름), 기밀 필드(예: 회사 매출액), 제한 필드(예: 사회 보장 번호)가 포함될 수 있습니다. 필드 수준 보안은 다음의 차이점을 반영해야 합니다.

할당한 태그를 읽고 액세스 규칙을 적용하는 특성 기반 액세스 제어를 통해 분류를 적용할 수 있습니다. 이는 OWD 및 공유 규칙을 보완하는 메타데이터 중심 레이어입니다.

분류 스키마에 ABAC를 맞추면 플랫폼이 다음을 수행할 수 있습니다.

• 개체별로 유지되는 공유 규칙이 아닌 분류 자체에서 제한됨 또는 비밀로 태그가 지정된 데이터에 대한 액세스를 제한합니다.
• 시간에 따른 레코드 분류 변화에 따라 액세스를 조정합니다. 새롭게 규제됨으로 태그된 레코드는 수동 규칙 변경 없이 더 엄격한 액세스를 승계합니다.
• 데이터 특성(예: 분류 및 민감도)과 사용자 특성(예: 부서 및 공백) 및 컨텍스트(예: 시간 및 위치)를 단일 인가 결정에 결합합니다.

이 체계에 맞게 ABAC 정책을 설계하여 필드를 제한됨으로 분류하는 작업이 액세스 제어를 촉진하고 구현을 분리된 공유 규칙을 유지하는 대신 분리된 분류에 연결합니다.

당사 책임: 분류 스키마를 정의하고, 데이터 모델러를 교육하고, 설계 시 필드를 분류하고, 제어를 구성하고, ABAC 정책을 분류 계층에 맞게 조율하여 태그를 구동합니다.

플랫폼이 이미 모든 조직에 제공하는 정보를 사용하여 시작합니다. 나머지 데이터는 기본적으로 암호화됩니다. Hyperforce Salesforce에서 소유하고 관리하는 단일 키 아래 전체 저장소 볼륨을 보호하는 볼륨 수준 암호화를 적용합니다. 이 기준선은 항상 솔루션에 적용되며 투명하지만, 필드별로 작동하지 않으므로 키 수명 주기 내에서 암호화 및 제어할 항목을 선택하는 것은 사용자가 아닌 플랫폼에 따라 결정됩니다.

기준선에서 규정 준수, 계약 또는 데이터 분류 의무를 충족할 수 없는 경우 Shield Platform Encryption 사용하십시오. 특히 볼륨 수준 암호화가 제공하지 않는 세 가지 항목 중 하나가 필요한 경우

• 키 자재를 직접 생성, 순환, 취소할 수 있도록 키 수명 주기 제어
• 표준 필드, 사용자 정의 필드, 파일 및 첨부 파일이 암호화된 상태로 유지되는 선택성
• Salesforce에서 데이터에 액세스할 수 없도록 렌더링하는 기능입니다.

HIPAA, PCI DSS, GDPR 등 명시적 규제 키 제어 의무에 해당하는 데이터 및 제한된 데이터는 일반적으로 트리거됩니다. 기준선은 이미 모든 기타 항목에 대한 인프라 수준 방어를 포함합니다.

Shield Platform Encryption 필드 수준에서 암호화되며, 쿼리 가능성을 위해 보안을 교환하는 두 가지 스키마를 제공합니다.

확률적 암호화는 강력한 기본 구성표이지만 암호화된 필드는 필터 기준, 정렬 또는 집계 함수(예: MAX(), MIN() 및 COUNT_DISTINCT() 함수)에서 사용할 수 없습니다.

결정적 암호화는 동일한 일반 텍스트가 항상 동일한 암호 텍스트를 생성하므로 대/소문자를 구분하거나 대/소문자를 구분하지 않는 SOQL WHERE 절에서 정확히 일치하는 필터링을 지원합니다.

기본적으로 확률적 스키마를 사용하여 암호화하고 필터링 또는 정렬해야 하는 특정 필드에 결정적 암호화를 예약하는 것이 좋습니다. 수식 필드 참조, 보고서 집계, SOQL 작업에 미치는 영향 등 데이터 모델링 설계 시 이러한 제약 사항을 평가합니다.

고객 제어 키는 다음과 같은 두 가지 고유한 형태로 제공됩니다.

• BYOK(Bring Your Own Key)를 사용하면 자체 암호화 라이브러리, 엔터프라이즈 키 관리 시스템 또는 하드웨어 보안 모듈을 사용하여 Salesforce 외부에서 키 자료를 생성하고 플랫폼에 제공할 수 있습니다.
• 캐시 전용 키 서비스는 사용자가 제어하는 키 서비스에 데이터 암호화 키를 보관합니다. Salesforce는 저장하지 않고 필요에 따라 가져옵니다.

두 양식 모두 자체 일정에 따라 키 자료를 순환하고 폐기할 수 있습니다. 키 자료를 폐기하면 보호한 데이터가 복구할 수 없도록 렌더링되며, 이는 일상이 아닌 강력하고 의도한 제어입니다. 또한 키 순환 및 취소 절차를 문서화하는 것이 중요합니다.

모든 통합은 TLS 1.2 이상을 사용해야 합니다(Salesforce Platform에서 적용), 그러나 자체 구성을 사용하여 제한된 데이터를 처리하는 통합에 대해 인증서 기반 상호 인증을 구현해야 합니다.

당사 책임: 플랫폼의 볼륨 수준 기준선이 충분한 위치와 규정 준수, 계약 또는 분류 의무가 Shield Platform Encryption 보장하는 위치를 결정한 다음, 암호화 스키마를 선택하고, 고객 제어 키 전략을 선택하고 운영하고, 민감한 통합을 위해 인증서 기반 인증을 구현합니다.

제한된 데이터가 Sandbox에 들어오지 않도록 방지하는 전략을 사용하여 비프로덕션 환경에서 중요한 데이터를 보호합니다.

• 일부 Sandbox 복제는 Sandbox 새로 고침에서 제한된 데이터를 제외합니다.
• 데이터 마스킹 규칙은 데이터 특성을 유지하는 패턴을 사용하여 Sandbox에서 민감한 필드 값을 혼동시킵니다.
• 합성 데이터 생성은 생산 데이터가 필요하지 않은 개발 환경에 적용됩니다.
• Sandbox 템플릿은 각 sandbox 유형에 포함할 개체 및 필드를 정의합니다.

규정 준수 테스트를 설계하는 것은 아키텍처의 책임입니다. 팀이 규제된 데이터가 프로덕션 경계 내에 유지되는 동안 프로덕션과 유사한 조건에 대한 유효성을 검사할 수 있도록 실질적인 특성을 가진 합성 데이터에 대한 개발 및 테스트 주기를 구축합니다.

당사 책임: Sandbox 전략 설계, Data Mask 규칙 구성, 합성 테스트 데이터 생성

아키텍처 결정을 통해 사용자 프라이버시를 존중하는 솔루션을 설계합니다.

• 데이터 최소화: 명시된 비즈니스 목적에 필요한 데이터만 수집합니다. "이 데이터가 필요한 아키텍처 결정은 무엇입니까?"를 물어 모든 필드 추가에 도전합니다. 가장 안전한 데이터는 수집하지 않은 데이터입니다.
• 사용 제한: 기술적으로 목적 제한을 적용하는 데이터 액세스 패턴을 설계합니다. 권한 집합 및 공유 규칙을 사용하여 직무의 목적에 따라 데이터에 대한 액세스를 제한합니다. 예를 들어, 마케팅 사용자는 작업에 필요한 경우를 제외하고 지원 사례 세부 사항에 액세스하지 않아야 합니다.
• 동의 관리: 마케팅, 분석, 옵션 데이터 처리를 위해 개별 수준에서 동의 추적을 구현합니다. 통합 시스템에서 전파되는 동의 철회 워크플로를 설계합니다. 다시 말해, 동의는 세분화되고 목적이 구체적입니다.
• 데이터 주체의 권리: 액세스 요청(예: 데이터 사본 제공), 수정(예: 부정확성 수정), 삭제(예: 법적으로 허용되는 경우 데이터 삭제), 이동성(예: 기계에서 읽을 수 있는 형식으로 내보내기)에 대한 워크플로를 구축합니다. 각 규제 프레임워크가 적용하는 응답 기한 내에 완료하도록 이러한 워크플로를 설계합니다. 이러한 기한은 관할에 따라 다르며 주기적으로 수정되므로 유지되는 규정 준수 소스에서 워크플로의 SLA를 매개변수화하고 단일 값을 하드 코딩하는 대신 각 기간을 규정에 맞게 확인하는 것이 중요합니다.

당사 책임: 최소화를 사용하여 데이터 모델을 설계하고, 목적에 따라 액세스를 구성하고, 동의 워크플로를 구현하고, 데이터 주체 권한 자동화를 구축합니다.

데이터 보존은 프로비저닝하기 전에 선택한 아키텍처 결정이며 나중에 토글하는 설정이 아닙니다. Hyperforce 지역 배포를 제공하지만 Salesforce가 운영하는 지역만 존재하며, 조직의 상주 상태는 프로비저닝 시 고정됩니다. 각 데이터 범주가 있는 위치를 결정하고 적절한 지역을 사용할 수 있는지 확인하고 국경을 합법적으로 교차하는 데이터 전송 메커니즘을 설계할 책임이 있습니다.

국가 내 저장소로 기본 설정하는 대신 시작하기 전에 주거 의무를 분류하는 것이 중요합니다.

• 필수 현지화. 소규모 관할 지역의 경우 국가 범위 내에 있는 특정 데이터가 필요합니다(일반적으로 규제된 섹터에만 적용되는 경우). Salesforce가 국가 내 지역에서 운영되지 않는 경우 네이티브 스토리지가 자체적으로 요구 사항을 충족할 수 없으므로 데이터 보존 오버레이 또는 별도의 조직이 필요합니다. 이 목록이 변경될 수 있으므로 규정에 대한 특정 의무를 확인하는 것이 중요합니다.
• 책임 기반 프레임워크. 대부분의 시스템에서는 현지화 요구 사항을 적용하지 않습니다. 적절한 교차 국경 전송 메커니즘이 있는 지역 허브에 만족합니다. 이러한 경우 결정은 대기 시간을 최소화하고 규정을 간소화하는 영역을 기반으로 합니다.

데이터가 테두리를 넘으면 구성하기 전에 인식해야 합니다. 다시 말해 발생하는 전송과 법적 근거를 파악한 다음, 데이터가 종단 간에 관리되도록 액세스를 설계해야 합니다. 적절성 결정이 있는 곳에서는 마찰이 가장 적습니다. 바인딩 기업 규칙(BCR) 및 표준 계약 조항(SCC)은 대부분의 나머지 전송에 적용됩니다. 명시적 동의는 마지막 수단으로만 사용하십시오.

허용되는 전송이 지나치게 넓지 않도록 전송 메커니즘과 제한적인 레코드 액세스(예: 비공개 OWD 및 목적 범위 공유)를 연결합니다. 각 데이터 범주가 시작, 전송, 상주하는 위치를 표시하는 문서 데이터 플로 맵 규정 또는 지역 가용성이 변경되면 다시 살펴봅니다.

당사 책임: 데이터 범주별로 보존 의무를 분류하고, 프로비저닝하기 전에 지역 가용성을 확인하고, 교차 플로에 대한 전송 메커니즘(적합성, BCR/SCC)을 선택하고, 데이터 플로 맵을 문서화합니다.

플랫폼에서 제공하는 규정 준수 조치를 유지하는 솔루션을 설계할 책임이 있습니다.

이 지침은 지향적입니다. 규제 요구 사항은 관할 지역 및 시간에 따라 다릅니다. 배포 시 적용되는 규정, 감독 기관 또는 Salesforce 규정 준수 문서 등 규정에 대한 특정 의무를 항상 확인해야 합니다.

Salesforce는 광범위한 규정 준수 인증을 유지합니다(Trust.salesforce.com 및 compliance.salesforce.com에서 사용 가능): SOC 2 유형 II, ISO 27001, FedRAMP(Government Cloud 오퍼링용), HIPAA, PCI DSS, 지역 인증. 해당 인증서에는 플랫폼 인프라 및 공유 서비스에 대한 Salesforce의 책임이 포함됩니다.

플랫폼 인증은 규정 준수 부담을 줄이지만 아키텍처 책임은 제거하지 않습니다. 사용자 정의 개체, Apex 코드, 통합 및 구성은 플랫폼에서 제공하는 규정 준수 상태를 유지해야 합니다.

당사 책임: 규정 준수 조치를 유지하고 아키텍처가 규제 요구 사항을 충족하는 방식을 문서화하는 솔루션을 설계합니다.

• 보호된 건강 정보(PHI)가 포함된 모든 필드에 대해 Shield Platform Encryption을 활성화합니다.
• HIPAA 규정 준수를 위해 보존 정책이 포함된 Field Audit Trail을 활성화하여 HIPAA의 레코드 보관 요구 사항을 충족합니다. 규정에 따라 현재 기간을 확인합니다.
• 이벤트 모니터링을 구성하여 무단 PHI 액세스 패턴을 감지합니다.
• 액세스 제어, 감사 로깅, 전송 보안 등 HIPAA 보안 규칙에 필요한 모든 기술 보안을 구현합니다.

• 단일 사용자가 금융 거래를 만들고 승인하지 못하도록 권한 집합 설계를 통해 업무 분리(SoD)를 구현합니다.
• PCI 환경의 경우 PCI DSS 준수 범위를 최소화하기 위해 Salesforce에 전체 기본 계정 번호(PAN)를 저장하지 마십시오.
• 가능한 경우 결제 게이트웨이 토큰화를 사용하십시오.

• GDPR 및 LGPD의 경우 세분화된 목적별 수신 동의를 수집하는 동의 관리를 설계합니다.
• CCPA/CPRA 는 옵트아웃 모델을 따릅니다. 세분화된 목적 기반 동의 대신 개인 정보의 판매 또는 공유를 거부하는 명확한 메커니즘을 제공합니다.
• 각 프레임워크의 응답 기한 내에 완료되고 규정에 따라 확인된 데이터 주체 권한 워크플로를 구축합니다.
• 동의가 만료되면 데이터를 제거하는 데이터 보존 자동화를 구현합니다.

• 규제된 정부 작업 부하에 Salesforce Government Cloud를 사용합니다.
• Salesforce 구성에 매핑되는 NIST 800-53 컨트롤을 구현합니다.
• 정부 SIEM 인프라에 라우팅되는 이벤트 모니터링을 통해 연속 모니터링을 활성화합니다.

당사 책임: 규제 요구 사항에 따라 Shield, 필드 감사 내역, 업무 분리, 동의 관리, 데이터 보존을 구성합니다.

데이터 보호 및 개인정보보호 규정은 관할 구역에 따라 크게 다르며 특정 의무는 빠르게 변경되므로 이 수준에서는 국가별 테이블이 아닌 의사 결정이 필요합니다.

두 가지 아키텍처 레버는 데이터 보호 및 개인정보보호에 포함된 주거 및 국경 간 전송입니다.

이러한 규정을 준수하려면 다음을 수행해야 합니다.

• 각 데이터 범주가 있어야 하는 위치 분류
• 프로비저닝하기 전에 적절한 영역이 있는지 확인
• 경계를 넘는 데이터에 대한 법적 전송 메커니즘을 설계합니다.

자세한 내용은 결정 프레임워크에 대한 자세한 내용은 데이터 보존 및 주권을 확인하십시오.

이 외의 모든 사항은 시점 수치로 간주됩니다(예: 관할 지역에서 사용하는 동의 모델, 데이터 주체 요청의 기한, 위반 후 규제 기관 또는 영향을 받는 개인에게 알리는 기간, 감사 레코드의 최소 보존 기간). 이러한 숫자는 규정에 따라 설정되며 프레임워크에 따라 다르며, 규제 기관의 일정에 따라 수정됩니다.

여기에서 하드 코딩하지 마십시오. 배포에 대한 규정(또는 해당 규정을 따르는 유지 규정 준수 소스)을 기반으로 다음 단계를 결정하고 설계 크기를 운영 공간에서 가장 좁은 기간으로 지정해야 합니다.

다음은 설계에 속하는 지속적인 아키텍처적 결과입니다.

• 단일 자릿수 일 단위로 측정된 데이터 주체-요청 마감일은 특별 수동 프로세스로 충족할 수 없으므로 단기 조건이 있는 모든 관할 지역에서 작업할 때 DSR 처리를 자동화해야 합니다. 인테이크용 Experience Cloud, 사례 추적용 Service Cloud, 검색용 개인정보 보호센터, 처리에 대한 플로를 사용합니다.
• 위반 알림 창이 너무 좁아 간소화하기 때문에 위반 응답 워크플로를 미리 구축해야 합니다. 이벤트 모니터링 변칙 규칙, 미리 할당된 역할, 미리 작성된 규제자 및 데이터 주체 알림, 이력 범위 내에서 가장 좁은 기한을 가정하는 에스컬레이션 경로를 결정합니다. 개별 알림은 일반적으로 고위험 결정에 의해 트리거되므로 워크플로에 위험 평가를 포함해야 합니다.
• 일부 관할 영역에서는 감사 로그의 국가 내 보존을 요구하거나 권장합니다(최소값은 수년) 따라서 이력 내에서 SIEM 보존의 크기를 최소값으로 조정하고 로그가 관할 영역에서 나갈 수 있는지 확인해야 합니다.

당사 책임: 데이터 보호 및 개인정보보호별로 보존 및 전송을 설계하고, 가장 좁은 기한에 맞춰 DSR 및 위반 대응 워크플로를 자동화하고, 이 가이드에 작성된 값이 아닌 규제에 대한 모든 관할 지역별 값을 확인합니다.

시점 감사 준비가 아닌 지속적인 규정 준수 검증을 위해 설계합니다.

• 보안 상태 확인은 Salesforce 보안 기준선에 따라 구성을 평가하고 위험 점수를 제공합니다. Salesforce 보안 기준선 권장 사항의 준수를 모니터링하기 위해 정기적으로 확인합니다. 점수가 80% 이상(매우 우수 또는 우수 밴드)로 유지됩니다.
• 이벤트 모니터링은 사용자 활동, API 호출, 인증 이벤트, 데이터 액세스 패턴에 대한 자세한 로그를 수집합니다. 외부 SIEM으로 이벤트 로그 파일을 라우팅하여 기본 보존 제한을 초과하는 장기 보존을 수행합니다.
• 트랜잭션 보안은 정책에 대한 이벤트를 실시간으로 평가하며 이벤트를 차단하거나 MFA를 늘리거나 정책 위반을 알릴 수 있습니다.

배포 파이프라인에서 규정 준수 검사를 자동화하여 배포가 권한 모델을 약화시키지 않거나 감사 설정을 비활성화하거나 비호환 구성을 도입하지 않는지 확인하는 것이 중요합니다.

당사 책임: 분기별 상태 확인을 실행하고, 이벤트 모니터링을 SIEM에 라우팅하거나, 트랜잭션 보안 정책을 구성하고, CI/CD에서 규정 준수 검증을 자동화합니다.

규정 준수 요구 사항, 조사 요구 사항, 보존 의무를 기반으로 감사 내역 전략을 설계합니다.

규제된 환경의 경우 장기간 로그 보존 및 시스템 간 상관 관계를 위해 외부 SIEM 통합을 사용하여 이벤트 모니터링을 구현합니다. 규정 레코드 유지 요구 사항이 적용되는 모든 제한된 및 비밀 필드를 다루는 필드 감사 내역 정책 설계

당사 책임: 민감한 필드에 대한 필드 감사 내역을 활성화하고, SIEM에 이벤트 모니터링을 라우팅하거나, 트랜잭션 보안 정책을 구성합니다.

사후 고려하지 않고 개발 전반에 걸쳐 보안을 통합할 책임이 있습니다.

가능한 한 빠른 개발 단계에서 보안 관행을 통합합니다. 아키텍처 단계에서 위협 모델링을 사용하면 설계 수준의 취약성을 방지할 수 있습니다. 기능 요구 사항과 함께 수집된 보안 요구 사항은 보안을 후반기에 고려하지 않도록 방지합니다.

보안 결함은 설계 또는 개발 단계가 아닌 프로덕션에서 발견될 때 수정되는 비용이 상당히 높습니다. 아키텍처를 검토하는 동안 발견된 설계 수준 보안 결함은 한 대화만 해결해야 할 수 있습니다. 그러나 프로덕션에서 동일한 결함이 발견되면 재구축, 데이터 마이그레이션, 규정 준수 조치, 잠재적인 위반 알림이 필요합니다.

따라서 다음에 중점을 둔 교대 근무 왼쪽 보안을 실행합니다.

• 설계 마무리 전 위협 모델링
• 사용자 스토리의 보안 요구 사항
• 개발자를 위한 보안 코딩 교육
• ID에 통합된 정적 분석
• 보안 중심 코드 검토
• CI/CD의 자동화된 보안 테스트
• 프로덕션 배포 전 보안 검증

당사 책임: 위협 모델링을 수행하고 개발자를 교육하고 CI/CD에 코드 분석기를 통합하며 보안 인식 코드 검토를 요구합니다.

Salesforce 컨텍스트에서 일반적인 취약성에 대한 방어를 설계하는 것이 중요합니다. Salesforce에서 2025 OWASP Top 10에 대한 매핑 방법을 자세히 살펴보겠습니다.

• A01:2025 - 접근 제어 장애: 모든 Apex 데이터 액세스에 CRUD 및 필드 수준 보안(FLS)을 프로그래밍 방식으로 적용합니다.
  • API 버전 67.0 이상에서는 Apex 기본적으로 사용자 컨텍스트에서 실행됩니다. 즉, 코드를 실행하는 동안 현재 사용자의 권한과 FLS가 적용됩니다.
    • WITH SECURITYENFORCED가 제거되어 컴파일 오류가 발생했습니다. 기존 사용을 WITH USER_MODE로 교체합니다. 플랫폼은 표준 UI에서 액세스를 적용합니다.
  • API 버전 66.0 이전에서는 시스템 모드가 기본값입니다. SOQL 쿼리 또는 DML 작업용 Security.stripInaccessible()에서 USERMODE와 함께 사용합니다.
• A01:2025 - 클라이언트측 데이터 API: Lightning 데이터 서비스 및 UI API는 실행 중인 사용자의 FLS, CRUD 및 공유를 자동으로 적용하므로 해당 구성 요소를 기반으로 구축된 구성 요소는 기본적으로 최소 권한을 상속합니다.
  • 구성 요소가 사용자 정의 Apex 호출하면 이 보호 기능이 손실됩니다. 명령형 Apex 사용자 모드에서 실행되는 경우에만 액세스를 적용하므로 공유 없이 선언된 클래스는 모델을 자동으로 우회하는 이스케이프 해치 역할을 합니다.
  • 데이터 액세스에 Lightning 데이터 서비스 및 UI API를 사용합니다.
  • 구성 요소의 모든 필수 Apex 호출에 대해 CRUD, FLS 및 공유를 다시 주장해야 합니다.
• A02:2025 - 보안 구성 오류: 상태 확인을 사용하여 보안 기준선에서 구성 드리프트를 모니터링합니다.
  • 문서화된 비즈니스 근거에 명시적으로 요구되는 경우를 제외하고 Experience Cloud 사이트에서 게스트 사용자 액세스를 비활성화합니다.
• A05:2025 - 주입: 2025 주입 범주는 SOQL/SOSL 주입 및 교차 사이트 스크립팅(XSS)을 포함합니다.
  • 쿼리 삽입의 경우 모든 동적 쿼리에 바인딩 변수를 사용합니다. 사용자 입력을 쿼리 문자열에 직접 연결하지 마십시오. 플랫폼의 매개변수화된 쿼리 메커니즘은 올바르게 사용할 경우 주입 위험을 제거합니다.
  • SOQL 또는 SOSL injection은 쿼리 조건을 확대하여 발신자가 액세스할 수 없어야 하는 레코드 또는 필드를 공개하는 판독값에 적용됩니다. 이러한 언어는 쓰기가 별도의 DML 작업을 통해 실행되는 동안 데이터를 읽기 때문에 쿼리에 개체 및 필드 권한이 적용되지 않을 경우 복합되므로 액세스 제어 및 기밀성 위험이 발생합니다.
  • XSS의 경우 Lightning 웹 구성 요소는 LWC 렌더링 엔진을 통해 자동으로 보호합니다.
  • Aura 구성 요소 및 Visualforce 경우 동적 콘텐츠를 렌더링할 때 플랫폼 인코딩 기능(예: HTMLENCODE, JSENCODE, URLENCODE)을 적용해야 합니다.

당사 책임: 사용자 정의 코드에 CRUD/FLS를 적용하고 인코딩 함수를 적용하거나 바인딩 변수를 사용하거나 구성 드리프트를 모니터링합니다.

모든 스테이지에서 보안 게이트를 사용하여 CI/CD 파이프라인을 설계합니다. 보안을 자동화해야만 개발 속도에 따라 확장할 수 있습니다.

파이프라인 보안 단계를 자세히 살펴보겠습니다.

• 소스 제어는 필수 코드 검토와 함께 지점 보호 규칙을 사용합니다. 주요 지점에 대한 직접 커밋 또는 서명된 커밋은 없습니다.
• 정적 분석은 PMD, ESLint, RetireJS를 통합하여 주입, XSS, 안전하지 않은 패턴을 감지하는 Salesforce 코드 분석기를 사용합니다.
• 보안 스캔은 SAST 도구 및 암호 감지를 사용하여 자격 증명 커밋 및 종속성 취약성 스캔을 방지합니다.
• 권한 검증은 자동 비교 기술을 사용하여 보안 기준선에 대한 권한 변경 사항을 검토하고 권한 확장에 대한 경고를 보냅니다.
• 권한 확장 변경을 위해 보안 팀의 승인이 필요한 중요 보안 결과에 대한 배포를 중단하는 배포 게이트
• 배포 후 모니터링은 배포 후 변칙적인 동작에 대해 이벤트 모니터링 경고를 사용합니다.

당사 책임: CI/CD에 코드 분석기를 통합하고 지점 보호를 구성하거나 배포 게이트를 구현하고 자동으로 권한을 확인합니다.

포괄적인 보안 테스트에는 다양한 취약성 클래스를 해결하는 여러 기술이 포함되어 있습니다. 각 전략을 자세히 살펴보겠습니다.

• 정적 분석은 개발자 IDE에서 Salesforce Code Analyzer를 실행하여 즉시 피드백을 얻고 CI/CD 파이프라인에서 자동화된 게이트로 실행합니다. 정적 분석은 응용 프로그램을 실행하지 않고 소스 코드의 취약점을 식별합니다.
• 투명 테스트는 신뢰할 수 없는 사용자, 특히 Experience Cloud 사이트 및 공개 API에 노출되는 사용자 정의 애플리케이션에 대한 투명 테스트를 수행합니다.
  • AppExchange 및 AgentExchange 보안 검토의 경우 항상 정적 분석 보고서가 필요합니다.
  • 솔루션이 타사 웹 응용 프로그램 또는 서비스를 통합하는 경우 동적 스캔 보고서(투명 테스트)가 필요합니다.
  • 침투 테스트는 실시간 응용 프로그램에 대한 공격자 기법을 시뮬레이션합니다.
• 보안 중심 단위 테스트는 다른 권한 프로파일을 가진 사용자로 실행하여 액세스 제어 적용을 검증하는 Apex 테스트를 작성합니다. CRUD/FLS 적용이 무단 액세스를 차단하는지 확인하는 것이 중요합니다.
• AgentExchange 패키지 및 JavaScript 라이브러리를 모니터링하는 종속성 스캔을 통해 알려진 취약성을 확인할 수 있습니다. 설치된 패키지에 대한 보안 고지 사항을 구독하는 것이 중요합니다.

당사 책임: 코드 분석기를 실행하고, 침투 테스트를 수행하고, 보안 단위 테스트를 작성하고, 종속성을 스캔합니다.

Salesforce에서 보안 및 데이터 사고 대응은 위반, 무단 액세스, 악성 데이터 파괴 감지, 차단, 복구에 중점을 둡니다. 사고 대응 팀은 인접한 책임을 소유하는 두 가지 인접 기둥과 함께 작업합니다.

• 운영적 우수성은 사고 관리의 운영 기계(예: 심각도 계층, 통화 회전, 에스컬레이션 및 사고 후 검토)를 다룹니다.
• 신뢰성은 백업 및 재해 복구 전략을 비롯한 RTO 및 RPO 목표에 따른 가용성 복구를 다룹니다.

설계자는 보안 사고 감지, 대응 및 복구를 설계할 책임이 있습니다.

감지성은 명시적으로 설계해야 하는 아키텍처 품질입니다. 포괄적인 모니터링이 없으면 보안 사고가 장기간 감지되지 않을 수 있습니다.

여러 채널을 통해 감지를 구현하는 것이 중요합니다.

• 이벤트 모니터링은 로그인, 보고서 및 데이터 내보내기, 권한 변경, API 호출을 다루는 원시 이벤트 로그를 캡처합니다. 감지 논리를 결정하기 위해 구성하는 로그 상단에 트랜잭션 보안 정책 또는 SIEM 상관 관계가 필요한 비정상적인 이벤트를 식별해야 합니다.
• 트랜잭션 보안 정책은 이벤트를 실시간으로 평가하고 의심스러운 작업을 차단합니다. 이러한 정책을 구성해야 합니다.
• 설정 감사 내역은 플랫폼에서 제공하는 관리 변경 사항을 추적하지만 이를 모니터링해야 합니다.
• 사용자 정의 응용 프로그램 로깅은 Apex에서 구현해야 하는 보안 관련 이벤트를 캡처합니다.

엔터프라이즈 보안 Telemetry와의 상관 관계를 위해 이벤트 모니터링 로그를 SIEM 플랫폼에 라우팅합니다. 동작 기준선을 통해 거짓 양성을 최소화하면서 의심스러운 패턴을 감지하는 경고 규칙을 설계합니다.

당사 책임: 이벤트 모니터링을 SIEM으로 라우팅하고, 트랜잭션 보안 정책을 구성하고, 사용자 정의 로깅을 구현하고, 동작 기준선을 설정합니다.

사고가 발생하기 전에 사고 대응을 지원하는 아키텍처 결정을 문서화하는 것이 중요합니다.

• 중요한 비즈니스 기능을 방해하지 않고 손상된 구성 요소를 분리하는 솔루션을 설계하는 격리 경계. 권한 집합 해지, IP 제한 변경, 세션 종료를 구성해야 빠른 격리 기능을 제공합니다.
• 포렌식 보존은 이벤트 모니터링을 사용하여 자세한 활동 로그(플랫폼 기능)를 제공합니다. 필드 감사 내역은 구성에 따라 데이터 변경 내역을 유지합니다. 공격자가 아키텍처를 수정할 수 없도록 설계 로그가 변경할 수 없는 저장소로 라우팅됩니다.
• 일반적인 사고 유형에 대해 테스트된 복구 프로세스를 문서화하는 복구 절차입니다. 백업 무결성을 정기적으로 확인하는 것이 중요합니다. 보안 사고 시나리오의 경우 복구 시간 목표(RTO) 및 복구 지점 목표(RPO)를 알아야 합니다.
• 사고 시 작동하는 알림 메커니즘을 설계하는 통신 워크플로(예: 대역 외 통신 채널, 사전 설계된 템플릿 및 잠재적으로 손상된 시스템에 의존하지 않는 에스컬레이션 절차)
• ** 취약성 공개 채널**은 공개 Experience Cloud 사이트용입니다. 외부 연구자는 RFC 9116 security.txt 표준에 게시된 공개 정책을 통해 보안 문제를 보고할 수 있는 문서화된 모니터링된 방법을 제공합니다. 외부 보고서는 사고의 첫 번째 신호이므로 책임이 있는 아키텍처의 일부로 이 인테이크 경로를 설정하는 것이 중요합니다.

당사 책임: 분리 절차를 문서화하고, 변경할 수 없는 외부 저장소로 로그를 라우팅하고, 분기별로 복구 절차를 테스트하고, 대역 외 커뮤니케이션을 설정하고, 공개 사이트에 대한 취약성 공개 채널을 게시합니다.

Salesforce에서는 플랫폼별 시나리오에 대한 응답 기능을 준비하는 것이 중요합니다.

• 이벤트 모니터링 로그인 변칙(예: 예기치 않은 지리, 비정상적인 시간 및 새로운 장치)을 통해 손상된 사용자 계정이 감지됩니다. 계정이 손상되면 사용자를 동결하고 자격 증명을 강제 재설정하거나 설정 감사 내역 및 데이터 액세스 로그를 검토하여 제약 기간을 결정합니다.
• 이벤트 모니터링 보고서 내보내기 및 API 데이터 액세스 볼륨 변칙을 통해 대량 데이터 추출이 감지됩니다. 데이터 추출이 발생하면 세션을 즉시 취소하고 권한을 제한하거나 영향을 받는 레코드 및 분류 수준을 식별합니다.
• 배포 모니터링 및 설정 감사 내역 구성 변경을 통해 권한이 없는 코드 배포가 감지됩니다. 인가되지 않은 코드가 배포되면 배포를 즉시 롤백하고 손상된 배포 자격 증명에서 모든 변경 사항을 감사합니다.
• 설정 감사 내역 모니터링을 통해 승인된 변경 기간 외부의 권한 변경 사항에 대한 권한 에스컬레이션이 감지됩니다. 권한 에스컬레이션이 발생하면 에스컬레이션된 권한을 즉시 취소하고 액세스 권한이 높아진 활동을 감사합니다.

당사 책임: 플랫폼별 시나리오에 대한 응답 절차를 문서화하고, 모니터링을 구성하여 각 시나리오를 감지하고, 테이블 모드 연습을 통해 절차를 테스트합니다.

사고 후에는 아키텍처 개선에 초점을 맞춘 사고 후 판단 없이 검토를 수행하는 것이 중요합니다. 발생한 상황, 사고를 방지하거나 감지하는 기존 컨트롤이 실패한 이유, 향후 위험을 줄이기 위해 필요한 아키텍처 변경 사항을 문서화해야 합니다.

사고 후 검토 목표:

• 사고 타임라인 및 공격자 기술을 결정합니다.
• 사고를 활성화한 제어 실패를 식별합니다.
• 사고로 드러난 모든 아키텍처 약점을 문서화합니다.
• 위험 감소를 기반으로 한 해결 방법의 우선 순위를 지정합니다.
• 팀 전체에서 학습된 내용을 공유합니다.
• 감지 규칙 및 응답 절차를 업데이트합니다.

시간 경과에 따른 사고 메트릭을 추적하여 평균 감지 시간(MTTD), 평균 응답 시간(MTTR), 영향 범위를 결정하는 것이 중요합니다.

당사 책임: 적시에 사고 후 검토를 수행하고, ADR의 개선 사항을 문서화하고, MTTD 및 MTTR 추세를 추적하고, 학습된 교훈을 공유합니다.

아키텍처를 검토하는 동안, 프로덕션 배포 전, 지속적인 평가에 주기적으로 이 체크리스트를 사용합니다. 모든 항목은 Salesforce 아키텍처의 책임을 나타냅니다.

공유 책임

• Salesforce가 보호하는 모든 항목(예: 인프라, 플랫폼, 규정 준수 인증)을 문서화합니다.
• 보호해야 하는 모든 사항(예: 구성, 액세스, 사용자 정의 코드, 데이터 거버넌스)을 문서화합니다.
• 공유 책임 영역을 식별합니다(예: 사고 대응, 취약성 관리, 모니터링).
• 이해당사자 및 구현 팀에 최대한 명확하고 간결하게 책임을 전달합니다.

보안 아키텍처

• 구축을 시작하기 전에 STRIDE 메서드를 사용하여 위협 모델링을 완료합니다.
• 데이터, 응용 프로그램, ID, 통합 계층에 방어 세부 제어를 적용합니다.
• 모든 액세스 요청에 대해 명시적 확인을 요구하는 Zero Trust 원칙을 구현합니다.
• 중요한 데이터, 통합, API, 특권 계정을 다루는 최신 보안 자산 재고를 유지합니다.
• 위협 분석 및 제어 근거를 포함하여 ADR에서 보안 아키텍처 결정을 문서화합니다.
• 풀 토큰 대신 사용자별 ID를 전파하여 Salesforce Trust 경계에서 헤드리스 및 대리 클라이언트를 보호합니다.
• 외부 클라이언트 앱을 통해 OAuth 자격 증명을 저장, 순환 및 최소 권한 범위로 지정합니다.
• 컨테이너화된 통합의 경우 컨테이너 격리를 보안 경계로 적용하고, 프레임워크에 필요할 경우 mTLS를 사용하여 컨테이너 간 및 하이브리드 VPN 트래픽을 암호화하고, 배포 지역을 데이터 보존 및 규정 준수 인증에 맞춥니다.

ID 및 액세스 관리

• 중요한 데이터가 포함된 개체에 대해 OWD를 비공개로 설정합니다.
• 폭넓은 읽기 액세스 권한이 문서화된 요구 사항인 개체의 경우 공용 읽기 전용을 예약합니다.
• 모든 프로덕션 UI 액세스에 MFA를 적용하고 특권 계정에 대한 하드웨어 보안 키를 적용합니다. JWT 전달자 또는 클라이언트 자격 증명을 사용하는 API 전용 통합은 면제됩니다.
• 강력한 IdP 인증을 사용하여 SAML 2.0 또는 OpenID Connect를 사용하여 SSO를 구현합니다.
• 모든 API 인증에 OAuth 2.0(JWT 전달자 기본 설정)을 사용합니다. 내장 자격 증명에 OAuth 2.0을 사용 하지 마십시오.
• 문서화된 최소 권한 요구 사항을 기반으로 하는 권한 집합을 통해 액세스 권한을 부여합니다.
• 중요 영향 계정에 고급 제어를 적용합니다(예: IP 제한, 로그인 경고, 정기적인 액세스 검토).
• 조직의 위험 허용 및 규정 준수 요구 사항에 따라 빈도가 결정되는 고권위 계정에 대해 문서화된 증거를 사용하여 정기적인 액세스 검토를 수행합니다.
• SCIM 프로비저닝 및 90일 동안 유휴 중인 계정 감지를 통해 ID 수명 주기를 자동화합니다.
• 로그인한 사용자의 컨텍스트에서 직원 에이전트를 실행하고 고객 에이전트에 대해 최소 권한이 있는 전용 에이전트 사용자를 프로비저닝합니다. 공개 사이트 게스트 사용자에 대해 이 작업을 수행하지 마십시오.**
• 에이전트 인스턴스 및 Bot 정의 식별자를 사용하여 에이전트 인증에 대한 JWT를 구현합니다.
• 데이터 분류 및 일관된 메타데이터 태그 지정 표준에 부합하는 ABAC 정책을 정의합니다.

데이터 보호 및 개인정보보호

• 모든 데이터를 분류하고 각 분류 수준에 적합한 보호 제어를 적용합니다.
• 문서화된 키 관리를 사용하여 제한된 데이터에 대해 Shield Platform Encryption을 활성화합니다.
• 제한된 데이터의 인증서 기반 인증을 사용하는 모든 통합에 **TLS 1.2+**가 필요합니다.
• 마스킹 또는 제외를 통해 제한된 데이터가 비프로덕션 환경에 들어오지 않도록 방지합니다.
• 세분화된 목적별 추적 및 철회 워크플로를 사용하여 동의를 구현합니다.
• 각 규제 프레임워크의 응답 기한 내에 완료되는 데이터 주체 권한 워크플로를 구축합니다. 이는 운영 공간에서 가장 좁은 기간까지 크기를 지정하고 각 숫자가 규정에 대해 확인되는 유지된 규정 준수 소스에서 관할 지역별로 매개변수화되어야 합니다.
• 데이터 보존 요구 사항을 문서화하고 Hyperforce 지역 정렬을 확인합니다.

규정 준수 및 규정 준수

• 업계의 규제 요구 사항을 충족하는 플랫폼 인증을 확인합니다.
• 기본 보존 제한을 초과하는 보존을 위해 SIEM 라우팅으로 이벤트 모니터링을 활성화합니다.
• 필드 감사 내역을 구성하여 보존이 규정 최소값을 충족하도록 제한된 필드를 포함합니다.
• 보안 상태 확인 점수를 80% 이상 유지(매우 우수 또는 우수 밴드)하고 예외를 문서화합니다.
• 중요한 위반 중에 중단되는 CI/CD 파이프라인에 대한 규정 준수 검사를 자동화합니다.
• 실시간 변칙 감지 및 대응을 위한 트랜잭션 보안 정책을 구현합니다.

보안 개발 수명 주기

• 설계 단계에서 위협 모델링을 수행합니다(대규모 빌드 투자 전).
• 모든 Apex 환경에서 CRUD/FLS 적용
• API 버전 67.0 이상에 대한 자동 사용자 모드 적용을 사용하거나 API 버전 66.0 이전에 WITH USERMODE 또는 stripInaccessible()을 사용합니다.
• API 버전 67.0에서 제거된 SECURITYENFORCED와 함께 사용하지 마십시오.
• 중요한 결과가 배포를 차단할 경우 CI/CD에서 Salesforce 코드 분석기를 실행합니다.
• 모든 프로덕션 변경 사항에 대해 보안 인식 검토자가 코드를 검토해야 합니다.
• 모든 공개 응용 프로그램 및 Experience Cloud 사이트에 대한 진입 테스트를 수행합니다.
• SOQL, SOSL, HTML 컨텍스트에서 주입을 방지하는 모든 사용자 입력을 확인하고 비활성화합니다.

보안 사고 대응

• 이벤트 모니터링 경고 규칙을 설계하여 행동 기준선을 통해 의심스러운 패턴을 감지합니다.
• 조건부 보존을 위해 변경할 수 없는 외부 저장소로 로그를 라우팅합니다.
• 플랫폼별 시나리오에 대한 사고 대응 절차를 문서화하고 테스트합니다.
• ADR을 사용하여 사고 후 검토를 실행하여 아키텍처 개선 사항을 수집합니다.
• MTTD 및 MTTR 메트릭을 추적하여 감지 및 응답 공백을 식별합니다.

좋게 설계된 프레임워크에 대한 사용자 의견을 공유하십시오.