이 텍스트는 Salesforce의 자동 번역 시스템을 사용하여 번역되었습니다. 이 콘텐츠에 대한 피드백을 제공하고 다음에 원하는 내용을 알려주려면 저희의 설문 조사을 참조하십시오.
여기에 업데이트 일정에 대해 알아보십시오.
보안 시스템은 조직의 이해당사자 및 데이터를 보호합니다. 보안 아키텍처는 사용자 ID를 확인하고, 필수 정보로만 데이터 액세스를 제한하며, 데이터 손상을 방지합니다.
Salesforce는 고객 Trust 및 데이터 보안에 우선 순위를 두고 있습니다. Salesforce Platform은 개인 정보 보호 및 보안을 보장합니다. 실시간 시스템 성능 및 보안 정보는 Salesforce Trust에서 확인할 수 있습니다.
조직 및 고객 데이터를 보호하는 것이 보안 Salesforce 솔루션 구축의 기초입니다. Salesforce 아키텍처는 Salesforce의 내장형 보안 기능을 활용하여 조직 및 고객 데이터를 보호할 책임이 있습니다. 이러한 결정을 내릴 때 지리적 분포, 산업, 회사 운영 절차, 고객 데이터 유형을 고려하십시오.
조직 보안, 세션 보안, 데이터 보안과 같은 세 가지 영역에 집중하여 솔루션을 보다 안전하게 만들 수 있습니다.
조직 보안은 유효한 권한이 있는 사용자만 시스템에 액세스하고 필수 기능 및 데이터만 액세스할 수 있도록 하여 시스템을 무단 액세스로부터 보호합니다.
조직 보안 문제가 있다는 신호는 다음과 같습니다.
- 사용자를 활성화 또는 비활성화하는 특별 프로세스
- 사용자 또는 시스템 역할 변경에 대한 인가를 업데이트하기 위한 명확하지 않은 단계
- 올바른 사용자 보안 할당을 위해 개인의 기관 Knowledge 의존
- 구축된 보안 프레임워크 또는 업계 모범 사례를 준수하지 못함
- 구조화된 데이터 거버넌스 프레임워크 및 지원 정책이 없음
인증 및 권한 부여에 집중하여 Salesforce 조직에 대한 더 나은 조직 보안 제어를 구축할 수 있습니다.
인증은 시스템에 액세스하려는 사용자의 ID를 확인하는 보안 및 액세스 관리에 매우 중요합니다. 이는 인간 사용자(직원, 고객) 및 자동화된 사용자(외부 시스템, 통합) 모두에게 적용되며, 각 사용자 유형에 특정 인증 스키마가 필요합니다. 조직의 모든 Salesforce 입력 지점에서 안전하게 액세스하려면 다양한 인증 방법을 설정해야 합니다.
Salesforce에서 보안 인증 플로 만들기:
- 페르소나가 아닌 개인을 기반으로 Salesforce 사용자를 만듭니다. Salesforce의 내장 감사 기능은 각 사용자 계정이 플랫폼에 액세스하는 단일 개인에 해당하는 경우 가장 효과적입니다. 공유 사용자 계정을 사용하면 감사의 효율성이 저하되고 추가 보안 취약점이 발생하거나 계정 위반이 미치는 잠재적인 영향을 에스컬레이션하거나 효과적인 인가 스키마를 만들 수 있는 기능이 복잡해집니다. 여기에는 통합 사용자의 사용자 계정이 포함됩니다.
- 보안 UI 기반 액세스 시나리오 대부분의 사용자는 Salesforce 조직에 대해 일종의 UI 기반 액세스(일반적으로 로그인 액세스)가 필요합니다. Salesforce는 다음을 포함하여 이러한 로그인 시나리오에 대한 몇 가지 보호 계층을 제공합니다.
- 암호 정책. 사이버 범죄자는 사용자 이름 및 암호를 타겟팅하여 응용 프로그램에 대한 무단 액세스를 얻을 수 있습니다. 암호 정책을 구성하는 것은 로그인 액세스를 보호하는 데 중요한 단계이지만, Salesforce에서 사용자별로 이러한 정책을 재정의할 수 있기 때문에 이것만으로는 충분하지 않습니다.
- 다단계 인증(MFA) Salesforce는 모든 UI 기반 사용자 로그인에 MFA를 필요합니다. MFA는 사용자가 사용자 이름과 암호를 입력한 후 추가 식별 형식 또는 요소를 제공하도록 요구하여 자격 증명 누출 및 대량 공격에 대한 필수 방어 기능을 제공합니다. 이 추가 요소는 일반적으로 모바일 장치, 보안 키 또는 생체 인식 마커와 같은 물리적 형태를 취합니다.
- Single-sign on (SSO). SSO 시나리오에서 사용자는 조직의 응용 프로그램에서 하나의 자격 증명 집합만 사용합니다. 시스템에 대한 액세스는 중앙 위치에서 프로비저닝 및 관리되므로 보안이 향상됩니다. Salesforce는 SSO 시나리오에서 서비스 공급자 또는 ID 공급자 역할을 수행할 수 있습니다. SSO 구현 중단이나 문제를 해결할 수 있도록 일부 또는 모든 관리자가 Salesforce에 직접 로그인하도록 허용해야 합니다.
- 로그인 후 단계. 일부 사용 사례에서는 시스템에 액세스하기 전에 사용자에게 추가 단계를 완료해야 할 수 있습니다. 사용자 정의 로그인 플로를 구현하여 사용자에게 이러한 추가 프로세스 단계를 안내할 수 있습니다. 예:
- 사용 약관 수락
- 로그인 검색 및 무암호 로그인 시나리오를 통해 작업
- 세션 기반 공격 가능성을 줄이기 위해 사용자당 동시 Salesforce 세션 수 제한(세션 보안 참조).
- 지오펜싱 서비스에 연결
- 보안 API 기반 액세스 시나리오 모든 사용자가 Salesforce 조직에 대한 API 기반 액세스를 요청할 수 있습니다. Salesforce는 다음을 포함하여 API 기반 시나리오에 대한 몇 가지 보호 계층을 제공합니다.
- API 액세스 제어. API 액세스 제어 없이 유효한 자격 증명 집합을 보유한 모든 사용자는 연결된 앱이 조직에 배포되지 않은 경우에도 모든 앱을 활용하여 조직과 연결할 수 있습니다. 데이터 액세스 제어는 계속 적용되지만 사용자는 제어되지 않은 방식으로 정보에 액세스할 수 있습니다. 예를 들어, 시스템 관리자의 승인 없이 대용량 데이터를 다운로드하거나 손상된 정보를 업로드하는 데 앱을 사용할 수 있습니다.
- API 전용 권한. Salesforce에서 API 전용 사용자 권한을 구성할 수 있습니다. 이 권한 집합의 일부로 자동화 또는 통합 사용자 페르소나에 할당하여 UI 기반 액세스를 완전히 차단합니다.
- 인증서 및 키 인증서 및 키를 사용하면 Salesforce에서 요청이 승인된 비즈니스 또는 회사에서 시작되었는지 확인할 수 있습니다. SSO를 Salesforce와 함께 사용하려면 인증서와 키를 구성해야 합니다.
- 연결된 앱 Salesforce에서 연결된 앱을 구성하면 필요한 인증 프로토콜, 권한 부여 범위 및 세션 동작을 포함하여 Salesforce에 대한 외부 시스템 액세스를 단일 정의로 제어할 수 있습니다.
- 명명된 자격 증명 명명된 자격 증명을 사용하면 Salesforce 내에서 외부 액세스 지점 및 인증 프로토콜을 단일 정의로 제어할 수 있습니다. 이를 사용하여 Apex, 외부 서비스 및 Salesforce Connect 데이터 소스의 콜아웃에 대한 인증을 안전하게 정의하고 관리할 수 있습니다.
- Agentforce Agent 사용자 인증. Salesforce에 구축된 Agentforce 에이전트는 실제 사용자와 마찬가지로 관리 가능한 권한이 있는 에이전트-사용자 개체를 사용합니다. 에이전트를 설정할 때 액세스를 에이전트가 수행하는 역할에 주의 깊게 조율하여 최종 사용자를 제공하는 데 필요한 항목으로만 데이터 액세스를 제한합니다. 또한 공개 및 비공개 작업을 모두 사용하여 에이전트를 구성할 수 있습니다. 비공개 작업의 경우 최종 사용자를 확인 및 인증하여 에이전트 컨텍스트에 매핑합니다. 이렇게 하면 에이전트가 최종 사용자의 액세스 제어 내에서 동작하고 보안과 Trust 유지할 수 있습니다.
아래의 패턴 및 안티패턴 목록은 Salesforce 조직에서 올바르고 나쁜 인증 아키텍처를 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 향후 개선할 기회를 식별합니다.
Salesforce에서 사용할 수 있는 인증 도구에 대한 자세한 내용은 보안과 관련된 도구를 참조하십시오.
권한 부여는 사용자가 액세스할 수 있는 기능, 기능 및 데이터와 해당 자원으로 수행할 수 있는 작업(인증됨)을 정의합니다. 인가 제어는 인증되지 않은 최종 사용자에게 서비스를 제공하는 Agentforce 에이전트 사용자에 맞게 조정되어야 합니다.
조직에 인증할 수 있는 사람을 제한하는 것이 중요한 첫 번째 단계이지만 강력한 인증과 강력한 인증을 연결하는 것이 중요합니다. 적절한 권한 부여 제어가 없으면 사용자가 잠재적으로 비즈니스 및 이해당사자에게 해로운 방식으로 레코드를 생성, 편집, 삭제하거나 시스템 기능에 액세스할 수 있습니다. 권한 부여 제어가 부적절하면 시스템 사용이 더 어려울 수도 있습니다. 사용자가 시스템 내에서 수행할 수 있는 작업을 제어하여 시스템과 사용자를 안전하게 보호하는 Trust 수준을 높일 수 있습니다.
Salesforce에 대한 보안 권한 부여 스키마 구축:
- 최소 권한의 원칙을 따르십시오. 사용자에게 과업에 필요한 권한만 할당하여 최소 권한(PoLP) 원칙을 적용합니다. 이 원칙을 따르려면 세분화된 모듈식 권한 집합을 설계합니다. 이렇게 하면 권한 집합 그룹을 통해 정교한 액세스 제어 기능을 사용할 수 있으며, 무시 기능, 만료 일자 설정 등을 비롯한 권한을 정확하게 관리할 수 있습니다. 시스템의 기능 단위를 비즈니스 기능에 맞춰 세분화된 권한 및 효과적인 권한 집합 그룹을 정의합니다. 권한은 Salesforce의 메타데이터 액세스에 적용됩니다. Salesforce 데이터 액세스를 위한 PoLP 구성에 대한 자세한 내용은 공유 및 가시성을 참조하십시오.
- 개인이 아닌 개인의 관점에서 사용자 액세스를** 생각해보십시오**. 개별 사용자에 대한 인가(또는 일반적인 보안)를 고려해도 시스템의 규모를 조정하고 발전하지 않습니다. 대신 사용자 그룹을 나타내는 페르소나를 설계하고 관리합니다. 보안 Salesforce 솔루션은 인증에 개인을, 권한 부여에 페르소나를 사용합니다. 고유한 개인 정보에 대한 보안 구성을 정의하면 보안 모델의 액세스 및 권한을 세부적으로 제어할 수 있으므로 장기적으로 재단계화 필요가 최소화됩니다. 설계 표준 및 문서에 정의한 보안 개인 정보를 포함합니다.
- 권한 집합 및 권한 집합 그룹을 사용하여 메타데이터에 대한 사용자 액세스를 제어합니다. 권한 집합 및 권한 집합 그룹은 사용자가 액세스할 수 있는 메타데이터 및 해당 메타데이터로 수행할 수 있는 작업을 관리합니다. Salesforce 메타데이터에 대한 자세한 내용은 메타데이터 대 데이터를 참조하십시오. 권한 집합 및 권한 집합 그룹을 통해 앱 할당, 기능 라이센스 활성화, 관리 패키지 액세스, 시스템 권한, CRUD 액세스, 필드 수준 액세스를 구성합니다. 이 액세스를 설계 표준 및 문서에 포함하십시오.
- 조직 전체 기본값(OWD) 및 공유를 사용하여 사용자의 데이터 액세스를 제어합니다. Salesforce의 데이터와 메타데이터는 별도의 엔티티이므로 각각에 대해 별도의 액세스 제어가 필요합니다. OWD 및 내장된 공유 도구를 사용하여 Salesforce 데이터(개별 레코드, 파일 및 문서도구)에 대한 액세스를 구성합니다. 자세한 내용은 데이터 보안을 참조하십시오.
- OAuth 범위를 사용하여 연결된 앱의 액세스를 제어합니다. 연결된 앱을 구성할 때 앱 사용자가 Salesforce 리소스에 대해 보유할 범위 또는 액세스 권한을 정의합니다. OAuth 토큰 관리에 대한 자세한 내용은 세션 관리를 참조하십시오.
- 모든 통합에 대해 1개의 Salesforce 사용자를 만듭니다. 최소 권한 원칙을 준수하려면 각 통합에 대해 고유한 Salesforce 통합 사용자를 만듭니다. 이를 통해 특정 데이터 액세스를 할당하고 작업을 효과적으로 제어하고 트랜잭션 추적 가능성을 보장하며 잠재적인 보안 위반이 미치는 영향을 최소화할 수 있습니다.
- 모든 Agent 사용자에 대해 PoLP를 사용하여 고유한 계정을 구현합니다. 각 Agentforce 에이전트 사용자는 고유해야 하며 여러 에이전트 간에 재사용되지 않아야 합니다. 해당 계정에 대한 권한은 최소 권한 원칙을 엄격하게 준수해야 합니다. 에이전트 사용자가 실행한 작업은 Salesforce 내에서 또는 Salesforce 액세스 제어를 준수하지 않는 외부 시스템에 대해 강화된 보안 컨텍스트에서 작동할 수 있다는 점에 유의하십시오. 그러면 작업이 사용자에게 민감한 정보에 액세스하거나 사용자에게 정보를 공개할 수 있습니다.
- 프로필 사용을 최소화하고 프로필에서 액세스 컨트롤을 마이그레이션합니다. 프로필은 기존 Salesforce Classic 사용자 인터페이스(특히 기본 레코드 유형 및 페이지 레이아웃 할당)에 특정한 로그인 IP 범위, 로그인 시간 및 기능에 대한 액세스를 제한할 수 있는 기능을 제공합니다. 현재 프로필에 있는 다른 기능은 권한 집합 및 권한 집합 그룹의 동등한 기능으로 마이그레이션해야 합니다. Salesforce Classic UI 기능과 관련된 프로필의 기능은 수정 대상으로 지정해야 합니다.
아래의 패턴 및 비패턴 목록은 Salesforce 조직에서 올바르고 나쁜 권한 부여 관행을 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 향후 개선할 기회를 식별합니다.
Salesforce에서 사용할 수 있는 권한 부여 도구에 대한 자세한 내용은 보안과 관련된 도구를 참조하십시오.
이 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다.
✨ Pattern & Anti-Pattern Explorer에서 조직 보안에 대한 더 많은 패턴을 알아보십시오.
| 패턴 | 안티 패턴 | |
|---|---|---|
| 인증 | 설계 표준 및 문서:
- 승인된 보안 개인 정보가 명확하게 정의되고 나열됩니다. - 보안 매트릭스에 보안 개인 정보 및 허용된 인증 스키마(UI, API) 간 매핑이 있습니다. |
설계 표준 및 문서가 있는 경우:
- 보안 개인 정보 포함 안 함 - 보안 개인 정보 및 허용된 인증 스키마에 대한 명확한 매핑이 포함된 보안 매트릭스를 포함하지 마십시오. |
| 조직에서:
- 로그인 구성은 Salesforce MFA 점검에 부합합니다. - Salesforce에 로그인하는 사용자와 엔티티 간의 관계는 1:1(공유 사용자 없음) - API 액세스 제어는 사용자가 무단 연결된 앱을 통해 인증하지 못하도록 방지합니다. - SSO가 활성화된 경우 승인된 관리자 사용자에게 직접 로그인 액세스 권한이 부여됩니다. |
조직에서:
- 로그인 구성이 Salesforce MFA 점검에 일치하지 않습니다. - Salesforce에 로그인하는 사용자와 엔티티 간의 관계는 1:1가 아닙니다(공유 사용자 계정 있음) - 사용자가 방화벽 뒤에서 Salesforce에 액세스하는 경우 방화벽에서 하드 코딩된 IP 주소를 사용하여 Salesforce로부터의 통신을 안전하게 보호합니다. - API 액세스 제어가 활성화되지 않음 - SSO가 활성화된 경우 승인된 관리자 사용자에게 직접 로그인 액세스 권한이 없습니다. |
|
| In LWC, Apex, Aura:
- 인증을 실행하는 메서드는 명명된 자격 증명을 사용하여 사용자 이름/암호 플로를 처리합니다. - 읽을 수 있는 형식의 코드에 사용자 이름 또는 암호가 표시되지 않습니다(하드 코딩된 값 또는 문자열 없음). - 사용자 정의 로그인 플로가 있는 경우 모든 관련 사용자 정의 코드가 적절한 SessionManagement 메서드를 사용합니다. |
In LWC, Apex, Aura:
- 인증이 임시로 처리됩니다. - 코드에 사용자 이름 및 암호가 표시됩니다. |
|
| 승인 | 설계 표준 및 문서:
- Salesforce에 대한 액세스 권한이 있는 모든 사용자 및 시스템이 보안 매트릭스에서 하나 이상의 페르소나에 매핑됩니다. - 보안 매트릭스에 메타데이터 권한 및 할당된 사용자 페르소나가 명확하게 나열됩니다. - 향상된 권한을 부여하기 위한 사용 사례가 명확하게 나열되어 있습니다. -- 모든 데이터 수정 권한 -- 모든 데이터 보기 권한 |
설계 표준 및 문서가 있는 경우:
- 보안 매트릭스를 포함하지 마십시오. - 명확하게 권한을 나열하지 않음 - 고급 권한을 부여하기 위한 사용 사례를 명확하게 나열하지 않음 |
| 조직에서:
- 권한 집합 및 권한 집합 그룹은 메타데이터에 대한 액세스를 제어하는 데 사용됩니다. - 비즈니스 기능에 맞춰 권한 집합 및 권한 집합 그룹 - 사용자에게 할당된 권한은 보안 매트릭스 정의를 따릅니다. - 프로필은 최소한으로 사용되며 로그인 IP 범위 및 로그인 시간 제어에만 사용됩니다. - 모든 통합에 대해 고유한 API 전용 통합 사용자가 구성됩니다. |
조직에서:
- 권한 집합 그룹이 비즈니스 기능을 기반으로 액세스를 허용하도록 구성되지 않았습니다. - 권한 집합이 임시로 구성됩니다. - 권한 집합이 중복되거나 중복되는 경우, 명확한 기능 논리와 집합 간의 차이점을 이해하기 어려움 - 사용자에게 할당된 권한은 보안 매트릭스 정의를 따르지 않습니다. - 프로필에 메타데이터에 대한 액세스 제어가 포함되어 있습니다. - API 전용 사용자가 구성되지 않거나 둘 이상의 통합에서 공유됩니다. |
|
| Apex:
- 데이터베이스 작업은 다음을 포함하여 필드 및 개체 수준 액세스 검사를 적절하게 수행합니다. -- DML 및 데이터베이스 DML 문은 데이터 작업 및/OR의 사용자 또는 시스템 모드를 선언합니다. -- DML 및 Database DML 문은 데이터 작업 전에 스트립 액세스 가능 메서드를 사용합니다.
-- SOQL 및 SOSL 문은 USER_MODE 및 SYSTEM_MODE 키워드 AND/OR와 함께 사용됩니다.
-- stripInaccessible 메서드를 사용하여 쿼리 및 하위 쿼리 결과를 필터링합니다.
-- sObject describe 결과 메서드(즉, isAccessible, isCreateable, isUpdateable, 및/또는 isDeletable)가 거의 사용되지 않습니다. |
Apex:
- DML, 데이터베이스 클래스 메서드, SOQL 및 SOSL이 기본 시스템 모드로 실행됩니다. - 데이터베이스 작업에서 다음을 포함한 액세스 검사를 적절하게 수행하지 않습니다. -- DML 또는 데이터베이스 클래스 메서드에서는 sObject 및 필드 수준 액세스에 대해 독점적으로 isAccessible, isCreateable, isUpdateable 및/또는 isDeletable 확인을 사용합니다.
-- SOQL 쿼리는 액세스 제한에 SECURITY_ENFORCED 키워드만 사용합니다. |
|
| In Flows (플로 설계에 대한 보안 고려 사항):
- 플로는 가능한 한 제한적인 실행 컨텍스트를 사용합니다. 이상적으로 사용자 모드 - 실행 컨텍스트를 최소화하기 위해 보안에 민감하거나 특권 데이터 액세스가 하위 플로에서 수행됩니다. - 레코드 트리거 플로에서 수행되는 논리 제한 - 허용된 페이로드만 입력으로 전달되도록 플로 입력의 유효성을 검사합니다. |
플로:
- 플로가 수행하는 작업에 관계없이 플로가 공유 없이 시스템 모드 또는 시스템 모드로 실행됩니다. - 모든 플로 논리가 단일 대규모 플로 내에서 수행됩니다. - 플로 입력은 확인되지 않고 소비자에게 전달됩니다. |
세션은 기간 동안 사용자와 연결된 일련의 요청 및 응답입니다. 사용자가 Salesforce에 성공적으로 인증하면 세션이 시작됩니다. 세션 보안은 세션 간섭 또는 하이재킹을 방지하여 무단 액세스 및 데이터 침해를 방지하기 위해 시스템을 구성하는 방법입니다.
시스템의 모든 사용자 활동은 세션의 컨텍스트 내에서 발생하므로 세션이 시작되는 방식, 세션 중 발생할 수 있는 상황, 사용자가 사용해야 하는 장치, 의심스러운 또는 비정상적인 세션 동작을 감지하고 대응하는 방법을 고려하는 것이 중요합니다.
세션 관리, 장치 액세스, 위협 감지 및 응답과 같은 세 가지 키에 집중하여 Salesforce에서 세션 보안을 구축할 수 있습니다.
세션은 사용자가 성공적으로 인증하고 Salesforce에 대한 액세스 권한을 얻으면 시작됩니다. 이러한 세션을 통해 플랫폼이 특정 요청 및 응답을 해당 특정 사용자와 연결할 수 있습니다.
HTTPS 프로토콜을 사용하면 프런트 엔드 클라이언트와 Salesforce Platform 간의 통신을 쉽게 수행할 수 있습니다. 클라이언트에는 브라우저, 모바일 응용 프로그램, 로컬 응용 프로그램 등이 포함될 수 있습니다. HTTPS는 모든 커뮤니케이션이 개별적이며 이전 또는 향후 커뮤니케이션과 관련이 없습니다.
이 무시 접근 방식은 네트워크 통신을 가속화하고 패키지 간 링크가 끊어질 경우 발생하는 오류를 제거합니다. 그러나 웹 앱은 여러 요청 및 응답 상호 작용 전반에서 각 사용자의 ID 및 기타 관련 정보를 추적할 수 있는 방법이 필요합니다. 대부분의 웹 응용 프로그램과 마찬가지로 Salesforce는 세션 및 토큰을 사용하여 이를 수행합니다.
- 세션을 통해 Salesforce에서 요청 및 응답을 사용자와 연결할 수 있습니다. 사용자가 인증되면 플랫폼이 클라이언트 앱에 세션 ID를 다시 보냅니다. 이 ID는 사용자 요청(탐색, 검색, 데이터 제출 등)과 함께 포함됩니다.
- 토큰을 사용하면 사용자와 연결된 애플리케이션이 ID를 한 번 확인하고 그 이후에 고유한 액세스 토큰을 사용할 수 있습니다. 토큰의 수명은 제한되며 특정 리소스에만 액세스할 수 있습니다(액세스 수준 구성에 대한 자세한 내용은 승인을 참조하십시오). 토큰을 사용하면 사용자가 로그인할 필요 없이 권한이 있는 리소스에 액세스할 수 있습니다.
세션 및 토큰이 올바르게 보호되지 않을 경우 악의적인 작업자가 세션과 토큰을 방해하고 사용자를 가리키거나 시스템에서 악성 코드를 실행할 수 있습니다.
Salesforce의 보안 세션 관리 구축:
- Salesforce에서 세션 유형을 분류하는 방법 이해 승인된 세션 유형을 보안 사용자 페르소나에 식별하고 매핑하고 문서에 기록합니다.
- 세션이 시작되는 방법 및 세션 트래픽이 이동할 수 있는 위치 제어 다양한 사용자 페르소나가 시작할 수 있는 세션 유형을 식별한 후 승인되지 않은 소스 또는 컨텍스트에서 생성된 세션을 차단하도록 제어를 구성합니다. Salesforce는 다음을 포함하여 세션 출처 및 트래픽을 제어하는 몇 가지 방법을 제공합니다.
- 내장 세션 보호. Salesforce는 크로스 사이트 스크립팅, 크로스 사이트 요청 위조, 콘텐츠 스니핑, 클릭재킹 등의 세션 기반 악성 활동에 대한 조직 전체 보호 기능을 자동으로 활성화합니다. 이러한 보호 기능은 비활성화해서는 안 됩니다. 일부는 비활성화할 수 없습니다.
- 도메인 및 IP 범위. 모든 Salesforce 조직에 기본적으로 내 도메인이 활성화되어 있어 Salesforce 액세스를 위한 회사별 하위 도메인이 생성됩니다. 내 도메인을 통해 조직과 연결된 이름을 사용자 정의하거나 변경할 수 있습니다. 또한 Salesforce는 Experience Cloud 사이트 및 기타 응용 프로그램 페이지에 대한 추가 도메인 구성을 지원합니다. 참고: 사용자가 회사 방화벽 뒤에서 Salesforce에 액세스해야 하는 경우 방화벽 허용 목록에 필수 도메인을 추가합니다. 로그인 IP 범위 및 신뢰할 수 있는 IP 범위를 설정하여 Salesforce에 대한 인바운드 로그인 및 세션 요청을 제어할 수 있습니다.
- 로그인 시간 특정 사용자 개인 정보가 작업 시간을 설정한 경우 정의된 로그인 시간 이외에 Salesforce에 액세스할 수 있는 권한을 제한할 수 있습니다.
- 추가 세션 수준 보안이 필요한 작업 제어 기본적으로 세션에는 표준 및 높은 보증과 같은 두 가지 종류의 보안 수준이 있을 수 있습니다. 이러한 보안 수준을 사용하여 사용자가 보고서 및 대시보드 액세스 또는 Salesforce 조직의 보안 구성 관리와 같은 활동을 수행하거나 수행할 수 없는 방법을 제어합니다. 세션 수준 보안 정책은 사용자가 작업을 수행하기 위해 고안정 세션을 설정하거나 사용자가 민감한 작업을 수행하지 못하도록 차단할 수 있습니다.
- 세션 기반 권한을 추가해야 하는 작업 제어 Salesforce는 사용자에게 특정 세션 동안 권한 부여 또는 액세스 권한을 일시적으로 허용하기 위해 세션 기반 권한 활성화를 지원합니다. 플로 또는 Salesforce API를 통해 세션 기반 권한을 활성화 및 비활성화할 수 있습니다.
- 시간 초과를 통해 비활성 사용자 세션 관리 비활성 세션 종료는 세션 보안 관리의 핵심 부분입니다. 이렇게 하면 예를 들어 사용자가 브라우저 탭에서 Salesforce 세션을 열어두지만 다른 응용 프로그램에서 활성 상태로 작업하는 경우 또는 사용자의 모바일 장치가 Salesforce에 로그인되어 있지만 비관중인 경우 시스템을 보호할 수 있습니다. Salesforce의 기본 세션 비활성 시간 제한은 2시간입니다. 세션 비활성 시간 초과 수준을 늘리거나 줄일 수 있지만, 시간 초과를 늘리려면 강력하고 잘 문서화된 근거가 있어야 합니다.
- 토큰 구성을 통해 연결된 앱 세션 관리. 연결된 앱을 구성할 때 연결된 앱을 통해 Salesforce에 액세스하는 사용자에게 부여되는 권한 부여 범위 또는 수준도 정의합니다. 이 범위는 연결된 앱의 사용자가 성공적으로 인증한 후 발행되는 OAuth 토큰을 통해 세션 수준에서 적용됩니다. 토큰 새로 고침 정책을 통해 토큰의 지속 기간을 제어할 수 있습니다. 조직 관리자는 필요한 경우 사용자별 및 조직별로 토큰을 수동으로 취소할 수 있습니다.
아래의 패턴 및 안티패턴 목록은 Salesforce 조직에서 올바르고 나쁜 세션 관리를 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 향후 개선할 기회를 식별합니다.
Salesforce에서 사용할 수 있는 세션 관리 도구에 대한 자세한 내용은 보안과 관련된 도구를 참조하십시오.
현재 컨텍스트에서, 장치는 개인이 데스크탑 워크스테이션, 노트북, 태블릿 또는 휴대폰과 같이 Salesforce에 액세스하는 데 사용할 모든 전자 장치입니다.
휴대용 장치는 사용자에게 모든 위치에서 Salesforce에 액세스할 수 있는 유연성을 제공합니다. 그러나 이 편의성은 잠재적으로 악의적인 작업자에 대한 추가 공격 벡터를 도입합니다. 이러한 위협 벡터는 공개 장소에서 자격 증명을 훔치기 위해 어깨 서핑하는 것과 같은 간단한 전술에서 장치에 악성웨어 설치 또는 데이터 전송을 가짜 공개 Wi-Fi 네트워크 만들기와 같은 더 정교한 방법까지 다양합니다. 따라서 장치(특히 휴대용 장치)를 보호하는 것은 전반적인 시스템 보안에 필수적입니다.
Salesforce의 장치 액세스 보호:
- Salesforce에서 제공하는 모바일 앱 솔루션 사용 Salesforce에 액세스해야 하는 모바일 장치의 사용자가 iOS 및 Android용으로 제공되는 공식 Salesforce 앱을 사용하도록 합니다. 비즈니스 요구에 맞춤형 모바일 솔루션이 필요한 경우 안전한 인증 및 권한 부여 방법을 제공하는 Salesforce Mobile SDK를 사용해야 합니다.
- 세션 관리에 모바일 장치 사용을 설계합니다. 세션 보안 수준, 세션 시간 제한, 기타 세션 컨텍스트 제어는 모바일 장치에서 사용자가 예상하는 액세스를 고려해야 합니다. Salesforce에 액세스할 수 있는 장치 및 액세스할 수 없는 장치 및 모바일 세션에 액세스해야 하는 사용자 유형을 고려합니다. 보안 개인 정보 문서에 모바일 액세스 표준을 포함합니다. 이 주제에 대한 자세한 내용은 세션 관리를 참조하십시오.
- MDM(Mobile Device Management) 기술로 장치 수준 보안을 보완합니다. iOS 및 Android용 Salesforce 앱은 많은 인기 MDM 제품군과 호환됩니다. 선호하는 MDM 솔루션을 통해 사용자 장치에서 Salesforce 앱에 대한 추가 액세스 제어를 구성할 수 있습니다.
- MAM(Mobile Application Management) 기술을 사용하여 앱 수준의 보안을 보완합니다. MAM 기술은 모바일 장치에서 앱 수준 컨트롤을 지원합니다. Salesforce는 Salesforce 모바일 앱용 유료 MAM 추가 기능을 제공합니다.
아래의 패턴 및 안티패턴 목록은 Salesforce 조직에서 장치 관리가 제대로 진행되었는지 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 향후 개선할 기회를 식별합니다.
Salesforce에서 사용할 수 있는 장치 관리 도구에 대한 자세한 내용은 보안과 관련된 도구를 참조하십시오.
위협 감지는 악의적인 활동을 나타낼 수 있는 시스템의 동작 패턴을 식별하는 프로세스입니다. 평균보다 큰 데이터를 다운로드하거나 사용자가 평균보다 짧은 기간 내에 여러 레코드에서 중요한 데이터를 포함하는 필드를 수정하는 경우가 있습니다. 위협에 대한 대응에는 자동 세션 만료, 경고 및 기타 알림이 포함될 수 있습니다.
위협 감지는 잠재적인 문제를 가능한 한 빨리 식별하고 대응하는 것입니다. 실시간 위협 감지를 기반으로 조치를 취하면 추적 중인 악성 동작을 중지할 수 있습니다. Salesforce는 추가 기능 또는 Salesforce Shield의 일부로 실시간 이벤트 모니터링을 제공합니다. 민감도가 높은 응용 프로그램이 있거나 강력한 실시간 위협 감지 및 대응 기능이 필요한 경우 다음 솔루션 중 하나를 사용하십시오.
Salesforce 솔루션에 대한 효과적인 위협 감지 및 대응 전략 구축:
- 내장된 감사 기능 사용 Salesforce는 조직의 변경 사항을 추적하고 감사할 수 있는 다양한 내장 도구를 제공합니다. 예를 들어, 설정 감사 내역을 통해 관리 작업의 감사 내역을 볼 수 있습니다. Salesforce는 기본적으로 제한된 기간 동안 필드 수준 변경 사항을 추적하지만, UI에서 최대 18개월, API를 통해 최대 24개월 동안 필드 변경 사항을 표시하도록 필드 내역 추적을 활성화할 수 있습니다. 또한 Field Audit Trail을 활성화하여 데이터를 수동으로 삭제할 때까지 필드 수준 변경 사항에 대한 감사 내역을 무기한으로 유지할 수 있습니다.
- 정기적인 감사 검토 수립 감사는 실시간 위협 감지가 놓칠 수 있는 비정상적인 변경 사항을 식별하는 데 매우 중요합니다. 합법적인 액세스 권한이 있는 사용자가 연장 기간 동안 매일 소수의 레코드를 지속적으로 삭제하는 시나리오를 고려하십시오. 이 사용자에게 유효한 로그인 자격 증명, 레코드를 삭제할 수 있는 적절한 권한 부여가 있고 한 번에 대량의 레코드를 삭제하지 않으므로 활동이 실시간 위협으로 감지될 가능성이 거의 없습니다. 그러나 사용자 활동 보고서를 검토하는 감사 팀은 시간 경과에 따라 단일 사용자가 과도하게 레코드를 삭제하는 추세를 명확하게 식별하여 쉽게 해결할 수 있습니다. 거버넌스 정책의 일환으로 로그인 내역, 사용자 세션 활동 및 연결된 앱 사용을 감사하기 위한 정기적인 간격을 설정합니다.
- 위협 대응 전략을 개발하고 보안 정책에 포함합니다. 다음을 포함하는 위협 대응 전략을 만듭니다.
이벤트 모니터링은 실시간 위협 감지 및 대응을 활성화하여 이 원칙을 적용하는 데 필요한 데이터를 제공합니다. 트랜잭션 보안은 회사의 정책 중심 작업을 적용하며, 이벤트 유형은 시간에 따른 사용자 및 응용 프로그램 액세스 모니터링을 지원합니다.
Salesforce의 기본 위협 감지 서비스는 통계 및 기계 학습 모델을 사용하여 의심스러운 동작을 식별합니다. 이 서비스는 사이버 공격 및 의심스러운 데이터 액세스를 방지하는 특정 이벤트를 생성합니다.
트랜잭션 보안은 조직에서 발생하는 주요 이벤트를 가로채고 회사의 정책 중심 작업을 적용하는 프레임워크를 제공하므로 보안을 한 단계 더 발전시킵니다. 이렇게 하면 이벤트 모니터링이 로깅 도구에서 자동화된 보안 방어의 중요한 구성 요소로 전환됩니다.
아래의 패턴 및 안티패턴 목록은 Salesforce 조직에서 위협 감지 및 대응이 제대로 진행되었는지 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 향후 개선할 기회를 식별합니다.
Salesforce에서 제공하는 위협 감지, 경고 및 응답 자동화 도구에 대한 자세한 내용은 보안과 관련된 도구를 참조하십시오.
이 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다.
✨ Pattern & Anti-Pattern Explorer에서 세션 보안에 대한 더 많은 패턴을 알아보십시오.
| 패턴 | 안티 패턴 | |
|---|---|---|
| 세션 관리 | 설계 표준 및 문서:
- 보안 개인 정보가 각 개인 정보에 대해 승인된 세션 유형 및 시간 초과/기간 설정을 명확하게 나열합니다. - 로그인 시간이 지정되었거나 필요하지 않은 것으로 식별됨 - 세션 수준 보안 또는 권한이 강화되어야 하는 작업을 명확하고 검색 가능 - 연결된 앱 범위 및 토큰 관리 정책이 명확하고 검색 가능 |
설계 표준 및 문서:
- 세션 유형 및 시간 제한/기간 설정에 대한 보안 개인 정보가 없거나 정보가 누락된 경우 - 보안 정책에 연결된 앱 범위 또는 토큰 관리에 대한 정보가 포함되어 있지 않습니다. |
| 조직에서:
- 세션 감사 시 사용자가 예상 세션 유형을 통해 Salesforce에만 액세스하는 것이 표시됩니다. - "API 전용 사용자" 액세스에 대한 명확하고 활성 권한 집합이 있으며("API 전용" 권한 집합이 TRUE로 설정됨) 모든 통합 및 자동화된 사용자가 할당됩니다. - 사용자가 방화벽 뒤에서 Salesforce에 액세스하는 경우 방화벽은 IP 주소 대신 필수 도메인의 허용 목록을 사용하여 Salesforce로의 통신을 안전하게 보호합니다. - 비활성 세션 시간 초과 간격이 기본값을 초과하지 않습니다(2시간). - 다음 설정이 모두 활성화됩니다. -- 설정 페이지의 클릭잭 방어 -- 비설정 Salesforce 페이지의 클릭잭 방어 -- 교차 사이트 요청 위조(CSRF) 보호 -- 교차 사이트 스크립팅(XSS) 보호 -- 콘텐츠 스니핑 방어 활성화 -- 참조 페이지 URL 보호 -- Salesforce 외부로 리디렉션되기 전에 사용자에게 경고 |
조직에서:
- 정기적인 세션 감사가 없습니다. - 사용자가 보유해야 하는 세션 유형에 대한 정의가 없습니다. - "API 전용" 권한이 명확하지 않거나 통합 및 자동화된 사용자에서 누락됨 - 사용자가 방화벽 뒤에서 Salesforce에 액세스하는 경우 방화벽에서 하드 코딩된 IP 주소를 사용하여 Salesforce로부터의 통신을 안전하게 보호합니다. - 비활성 세션 시간 초과 간격이 기본값을 초과합니다(2시간). - 다음 설정이 비활성화됩니다. -- 설정 페이지의 클릭잭 방어 -- 비설정 Salesforce 페이지의 클릭잭 방어 -- 교차 사이트 요청 위조(CSRF) 보호 -- 교차 사이트 스크립팅(XSS) 보호 -- 콘텐츠 스니핑 방어 활성화 -- 참조 페이지 URL 보호 -- Salesforce 외부로 리디렉션되기 전에 사용자에게 경고 |
|
| In LWC, Apex, Aura:
- 사용자 정의 로그인 플로가 있는 경우 모든 관련 사용자 정의 코드에서 적절한 SessionManagement 메서드를 사용하여 세션 수준 보안을 할당합니다. |
In LWC, Apex, Aura:
- 사용자 정의 로그인 플로가 있는 경우 세션 수준 보안을 할당하는 논리가 없습니다. |
|
| 장치 액세스 | 설계 표준 및 문서:
- 명확하고 검색 가능한 장치 정책 - 보안 개인 정보가 적절한 장치 사용 및 정책에 명확하게 매핑됩니다. |
설계 표준 및 문서:
- 보안 정책이 없거나 장치 액세스에 대한 정보가 포함되어 있지 않습니다. |
| 조직에서:
- 비활성 상태에서 PIN/암호 코드 잠금 해제가 필요한 Salesforce 모바일 연결된 앱 구성 - 비즈니스 요구에 따라 Salesforce 모바일에 액세스할 수 있는 사용자를 엄격하게 제어해야 하는 경우 API 액세스 제어가 활성화되고 Salesforce 모바일 앱의 모든 사용자에게 권한 집합이 할당됩니다. |
조직에서:
- 비활성 상태에서 PIN/암호 잠금 해제를 요구하도록 Salesforce 모바일 연결된 앱이 구성되지 않았습니다. – 비즈니스 요구에 따라 Salesforce 모바일에 액세스할 수 있는 사용자를 엄격하게 제어해야 하지만 API 액세스 제어가 활성화되어 있지 않거나 권한 집합이 Salesforce 모바일 앱에 대한 액세스를 제어하는 데 사용되지 않습니다. |
|
| 위협 감지 및 대응 | 설계 표준 및 문서:
- 보안 정책에 적절한 응답 유형과 함께 응답을 트리거해야 하는 이벤트 목록이 포함되어 있습니다. - 데이터 모델의 모든 개체에 대해 감사 수준이 지정되었습니다. - Salesforce에서 사용 가능한 로그를 검토하는 단계가 문서화되어 있습니다. - 모든 자동 응답이 명확하게 문서화됩니다. |
설계 표준 및 문서:
- 보안 정책이 없거나 위협 감지 및 경고에 대한 정보가 포함되어 있지 않습니다. - 자동 응답 문서가 없거나 명확하지 않음 |
| 회사 내부:
- 감사 데이터는 비즈니스 이해당사자가 이해하고 액세스할 수 있는 보고서에서 사용할 수 있습니다. - 감사 내역 및 보고서가 정기적으로 검토됩니다. |
회사 내부:
- 감사 데이터는 액세스 및 해석에 대한 주제 전문 지식이 필요한 로그 파일을 통해서만 사용할 수 있습니다. - 감사 정보를 검토하는 프로세스가 없는 경우 |
|
| 조직에서:
- 비정상적인 사용이 감지된 경우 사용자 계정을 비활성화하거나 리소스에 대한 액세스를 실시간으로 차단하여 위협에 대응하는 자동화가 있습니다. - 비정상적인 활동에 대해 적절한 사용자에게 알리도록 알림 및 경고가 구성됩니다. - 비공개 또는 중요한 데이터가 포함된 모든 필드에 대해 필드 내역 추적이 활성화됩니다. |
조직에서:
- 위협에 대처하기 위한 자동화 기능이 없습니다. - 알림 및 경고가 적절한 사용자에게 비정상 활동에 대해 알리도록 구성되어 있지 않거나 비정상 활동과 관련된 일부 알림 및 경고가 있지만 임시로 제공됩니다. - 비공개 또는 중요한 데이터가 포함된 필드에 대해 필드 내역 추적이 일관되게 활성화되지 않습니다. |
데이터 보안은 무단 액세스, 손상 또는 의도하지 않은 삭제로부터 데이터를 보호하는 방법입니다. 데이터 보안은 전송 중 및 유지 중에 모두 데이터를 보호하는 작업에 포함됩니다.
강력한 데이터 보안은 시스템에 대한 무단 액세스로 인한 위험 및 잠재적인 손상을 최소화합니다. 데이터 보안이 부적절하면 고객 및 회사에 심각한 영향을 미칠 수 있는 데이터 침해에 시스템이 취약해집니다. 따라서 데이터를 보호하는 것은 보안 아키텍처를 구축하는 데 매우 중요합니다.
데이터 보안을 향상하려면 Salesforce 내에서 분류와 함께 데이터로 간주되는 내용을 명확하게 이해해야 합니다. Salesforce 조직 내에 저장된 개별 레코드, 파일 및 문서는 해당 데이터입니다. 메타데이터와 데이터의 구분에 대한 자세한 내용은 Salesforce 아키텍처 기본 사항을 참조하십시오.
공유 및 가시성 및 암호화 사용에 중점을 두어 Salesforce 솔루션에서 더욱 강력한 데이터 보안을 구축할 수 있습니다.
참고: 데이터 보안을 위해 설계할 때 두 개의 개념이 솔루션의 전체적인 데이터 보안에 영향을 미치므로 데이터 보안뿐 아니라 아카이빙 및 정리도 고려하십시오.
민감도(예: 공개, 내부, 기밀, 제한)를 기반으로 Salesforce Platform에 저장된 모든 데이터를 식별하고 분류합니다. 각 데이터 유형을 처리하고 보호하는 방법을 간략하게 설명하는 명확한 데이터 분류 정책을 정의합니다. 필드 수준 보안, 암호화, 데이터 마스킹과 같은 적절한 보안 제어를 구현하여 정책을 적용하고 무단 액세스 또는 노출으로부터 중요한 데이터를 보호합니다. 해당 분류 및 제어를 정기적으로 검토하고 감사하여 비즈니스 및 규정 준수 요구 사항에 부합하는지 확인합니다.
공유 및 가시성은 사용자가 Salesforce 내에서 데이터에 액세스하는 방법을 제어할 수 있도록 시스템을 구성합니다. 공유 및 가시성은 사용자가 액세스할 수 있는 개별 레코드를 제어하지만 이러한 설정만으로는 특정 레코드로 사용자가 수행할 수 있는 작업이나 해당 레코드 내의 표시되는 특정 필드를 제어하지 않는다는 점에 유의해야 합니다. 데이터 작업 수행 권한(예: CRUD)은 개별 개체 및 필드 수준에서 사용자에 대해 구성할 수 있는 메타데이터 액세스 제어를 통해 사용자에게 할당됩니다. 이에 대한 자세한 내용은 승인을 참조하십시오.
Agentforce 작업은 일반적으로 직접 액세스 권한이 없는 인증된 사용자와 익명 사용자 모두에게 데이터를 노출할 수 있습니다. Agentforce 에이전트를 구축할 때 에이전트에 할당된 모든 작업을 주의 깊게 고려하고 문서화하십시오. 각 작업에 대해 다음을 이해해야 합니다.
- 작업이 액세스할 수 있는 데이터입니다.
- 작업이 실행되는 보안 컨텍스트입니다.
- 작업에 에이전트 세션에 민감하거나 제한된 데이터를 통합할 수 있는 Knowledge 검색 또는 기타 기능이 있는지 여부
Salesforce에서 효과적인 공유 및 가시성 구성:
- 의미 있는 작업 기능을 둘러싼 액세스 설계 사용자 페르소나를 수행할 비즈니스 기능에 매핑하는 보안 매트릭스를 만듭니다. 이 템플릿을 기본으로 사용하여 공유 및 가시성을 설계합니다. 의미 있는 비즈니스 기능을 식별하는 방법에 대한 자세한 내용은 기능 단위를 참조하십시오.
- 최소 권한 원칙을 적용하는 가장 간단한 경로를 선택하십시오. 공유 및 가시성 계획을 설계할 때 최소 권한의 원칙을 적용할 때 가장 간단한 방법으로 하십시오. 시스템 유지 관리, 확장성, 적응성에 다운스트림 문제가 발생할 수 있는 과도하게 설계된 데이터 제한 및 공유 스키마를 방지합니다. 대신 Salesforce의 유연하고 계층화된 데이터 공유를 활용하여 데이터 수준에서 사용자 액세스를 위한 세분화된 규칙을 구성합니다.
- 비즈니스에서 중요한 데이터를 처리하지 않는 한 내부 조직 전체 기본값(OWD)을 공용 읽기 전용으로 설정한 후 비공개를 사용합니다. OWD는 데이터 수준에서 사용자가 보유할 "최소" 권한 수준을 제어합니다. OWD 수준에서 액세스를 제한할 수 없습니다. 비공개 OWD는 모든 사용 사례에 이상적인 것처럼 보일 수 있지만 비즈니스 전반의 사용자는 종종 복잡한 공유 스키마를 통해 더 권한이 많은 OWD를 실수로 복제하는 경우가 있습니다. 또한 비공개 OWD로 인해 사용자가 중복 데이터를 만들 수 있습니다. 데이터 용량 및 상위-하위 또는 소유권 왜곡에 따라 공유 계산(및 재계산)을 완료하는 데 상당한 시간이 소요될 수 있습니다. 비공개 OWD는 이 상황을 악화합니다. OWD는 CRUD 권한 및 필드 수준 가시성을 제어하지 않는다는 점에 유의해야 합니다. 비즈니스 요구 사항에 따라 정당화되는 경우에만 OWD를 선택하십시오. 일반적으로 이러한 정당화는 규정 준수와 관련이 있습니다.
- ** 외부 조직 전체 기본값(OWD)을 강력한 비즈니스 이유가 있는 경우를 제외하고 비공개로 설정합니다**. Experience Cloud 사이트, 포털 등에서 Salesforce 데이터에 액세스하는 사용자에게는 외부 OWD가 적용됩니다. 이렇게 하면 내부 및 외부 사용자에 대해 별도의 OWD 기준선을 구성하여 다양한 유형의 "최소" 권한을 허용할 수 있습니다. 항상 외부 사용자의 OWD를 비공개로 설정합니다. 더 개방적인 수준의 예외는 비즈니스 요구에 따라 명확하게 근거가 있어야 합니다.
아래의 패턴 및 안티패턴 목록은 Salesforce 조직에서 올바른 공유 및 가시성을 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 향후 개선할 기회를 식별합니다.
Salesforce의 공유 및 가시성 도구에 대한 자세한 내용은 보안과 관련된 도구를 참조하십시오.
암호화는 읽을 수 있는 데이터를 암호화되지 않는 인코딩 형식으로 변환합니다. 암호화된 데이터는 키를 통해 해독하거나 원래 형태로 다시 번역할 수 있습니다. 따라서 암호화는 데이터를 보존하고 전송하는 동안 모두 보호하는 가장 효과적인 방법 중 하나이며, 무단 당사자가 데이터에 액세스하는 경우에도 데이터를 읽을 수 없습니다.
Salesforce 솔루션에서 암호화를 적절하게 사용하도록 설계:
- 항상 전송 중인 데이터를 적절하게 암호화하십시오. Salesforce는 Salesforce에서 지원하는 브라우저에서 발생하는 모든 세션에 TLS(Transport Layer Security)를 적용하며, HTTPS를 사용하는 아웃바운드 호출이 특정 보안 표준을 충족하도록 요구합니다. 플랫폼 API는 기본적으로 HTTPS도 사용합니다. 또한 Salesforce Experience Cloud 사이트 또는 포털과 관련 Salesforce 조직 간에 전송되는 데이터는 기본적으로 암호화됩니다. Salesforce의 내장형 이메일 서비스를 사용하는 경우 Salesforce에서 이메일을 전송하고 수신 시도하기 위해 사용하는 TLS(Transport Layer Security)의 기본 수준이 있습니다. 명확한 비즈니스 근거가 없으면 최소한 조직 설정이 기본 설정보다 낮지 않아야 합니다. 데이터 분류 및 민감도를 기반으로 AWS Direct Connect 또는 Salesforce Private Connect를 통해 Salesforce에 대한 비공개 네트워크 연결을 활용하는 것이 좋습니다. 이렇게 하면 데이터가 공개 인터넷을 이동하지 않고 사용자 액세스 및 통합을 위해 비공개 네트워크 연결을 통해 안전하게 흐릅니다.
- 비즈니스에서 요구하는 경우 데이터를 암호화 상태로 유지합니다. Salesforce는 데이터를 암호화하는 다양한 방법을 제공합니다.
- Hyperforce. 데이터는 Hyperforce를 사용하는 조직에서 암호화된 상태로 유지됩니다. 암호화는 Salesforce에서 조직에 대해 관리합니다. 자체 암호화 키를 만들거나 폐기할 수 없습니다.
- Salesforce Shield. Salesforce Shield를 사용하면 응용 프로그램 및 데이터베이스 계층을 비롯한 추가 계층에서 Salesforce 조직의 데이터를 암호화할 수 있습니다. Shield를 사용하면 강력한 BYOK(Bring Your Own Key) 옵션 등 테넌트의 암호화 키에 대한 전체 관리 기능을 사용할 수 있습니다. 또한 비정형 데이터(파일, 첨부 파일, 검색 색인, 이벤트 포함)를 암호화할 수 있습니다. Hyperforce 기반 인스턴스는 외부 키 관리자를 사용하여 자체 AWS KMS를 가져올 수 있는 옵션을 제공합니다. 이 기능을 사용하면 Salesforce에 저장된 데이터를 암호화 및 해독하는 데 사용되는 KMS 내의 암호화 키를 완벽하게 제어하여 보안을 강화하고 조직의 규정 준수 요구 사항에 부합할 수 있습니다.
아래의 패턴 및 안티패턴 목록은 Salesforce 조직에서 암호화의 올바르고 나쁜 사용을 보여줍니다. 구축하기 전에 설계의 유효성을 검사하거나 향후 개선할 기회를 식별합니다.
Salesforce에서 사용할 수 있는 암호화 도구에 대한 자세한 내용은 보안과 관련된 도구를 참조하십시오.
이 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다.
✨ Pattern & Anti-Pattern Explorer에서 데이터 보안에 대한 더 많은 패턴을 알아보십시오.
| 패턴 | 안티 패턴 | |
|---|---|---|
| 공유 및 가시성 | 설계 표준 및 문서:
- 보안 매트릭스는 각 사용자 페르소나가 액세스 권한을 부여받은 데이터를 간략하게 보여줍니다. - 해당되는 경우 외부 사용자 및 내부 사용자에 서로 다른 데이터 액세스 표준이 사용됩니다. |
설계 표준 및 문서:
- 설계 표준 및 문서가 없거나 보안 매트릭스를 포함하지 않습니다. - 보안 매트릭스가 있는 경우 사용자 페르소나에 대한 데이터 액세스를 간략하게 표시하지 않습니다. |
| 조직에서:
- 내부 사용자의 조직 전체 기본값(OWD)은 공용 읽기 또는 내부 사용자의 OWD는 규정 준수 요구 사항으로 인해 비공개입니다. - 외부 사용자의 OWD는 비공개입니다. - 생성형 AI는 사용자 모드에서만 작동하거나 명확한 비즈니스 근거가 있는 시스템 액세스에 대한 일부 사용 |
조직에서:
- 내부 사용자의 OWD는 비즈니스 근거 없이 비공개로 설정되거나 내부 사용자의 OWD는 공용 읽기/쓰기로 설정됩니다. - 비즈니스 근거 없이 외부 사용자의 OWD는 비공개 이외의 모든 항목으로 설정됩니다. - 생성형 AI는 비즈니스 근거 없이 시스템 모드에서 작동 |
|
| Apex:
- 모든 코드가 데이터 액세스(SOQL/SOSL) 또는 데이터 작업 수행(DML/데이터베이스 클래스 메서드) 공유 키워드 사용 |
Apex:
- 키워드가 일관되지 않게 사용되는 공유 |
|
| 암호화 사용 | 설계 표준 및 문서:
- 전송 중(필요한 경우) 데이터 암호화를 위한 사용 사례가 명확하고 검색 가능 - 승인된 암호화 프로토콜이 명확하게 나열됩니다. - 코드 문서에 암호화가 사용되는 위치 및 사용되는 프로토콜이 명확하게 표시됩니다. |
설계 표준 및 문서:
- 승인된 암호화 프로토콜이 명확하지 않거나 나열되지 않음 - 코드가 문서화되지 않았거나 코드에서 암호화가 사용되는 위치와 방법에 대한 문서가 명확하지 않습니다. |
| 조직에서:
- 보안 위험이 파악되었으므로 데이터를 보호해야 하는 경우 Hyperforce 또는 Salesforce Shield 암호화를 제공합니다. |
조직에서:
- 비즈니스 요구에 따라 데이터 보호 수준이 높아지지만 Hyperforce 및 Salesforce Shield 사용되지 않습니다. |
|
| Apex:
- 비즈니스 요구 사항이 전송 시 더 높은 데이터 보호를 요구하는 경우 통합과 관련된 모든 코드는 Crypto Class 방법을 사용하여 전송 전에 데이터를 암호화하거나 수신 시 데이터를 암호 해독합니다. |
Apex:
- 비즈니스 요구에 따라 전송 시 더 높은 수준의 데이터 보호가 필요하지만 통합과 관련된 코드는 전송 전이나 수신 시 데이터를 암호화하지 않고 논리를 수행하거나 Crypto Class 메서드가 임시로 사용됩니다. |
| 도구 | 설명 | 조직 보안 | 세션 보안 | 데이터 보안 |
|---|---|---|---|---|
| Apex Crypto 클래스 | Apex 데이터 암호화 및 해독 | X | ||
| API 액세스 제어 | Salesforce API 및 연결된 앱에 대한 액세스 관리 | X | X | X |
| API 변칙 이벤트 | 사용자가 API를 호출하는 방식의 변칙 추적 | X | ||
| 브라우저 보안 설정 | 중요한 데이터 보호 및 SSL 인증서 모니터링 | X | ||
| 인증서 기반 인증 | 고유한 디지털 인증서를 사용하여 개인 인증 | X | X | |
| 인증서 및 키 | Salesforce에서 외부 웹 사이트에 대한 요청 확인 | X | X | |
| 코드 스캐너 | 보안 취약점에 대한 Apex 코드 스캔 | X | X | |
| 연결된 앱 | API 및 표준 프로토콜을 통한 통합 | X | X | |
| 자격 증명 채우기 이벤트 | 도난된 사용자 자격 증명을 사용하는 시도된 로그인 추적 | X | ||
| CSP Trusted Site | 코드 삽입 공격 방지(예: 교차 사이트 스크립팅) | X | ||
| 사용자 정의 로그인 플로 | 사용자의 로그인 비즈니스 프로세스 제어 | X | ||
| 고객 ID | 웹 사이트 및 앱 로그인 및 확인 제어 | X | ||
| Data Mask | Sandbox에서 중요한 데이터 자동 마스킹 | X | ||
| 디버그 로그 | 조직에서 발생하는 이벤트 추적 | X | ||
| 위임 관리 | 관리자가 아닌 사용자에게 제한된 관리자 권한 할당 | X | X | |
| 장치 활성화 | 신뢰할 수 없는 브라우저, 장치 또는 IP 범위에서 로그인 확인 | X | ||
| 고급 트랜잭션 보안 | 이벤트 가로채기, 사용자 활동 모니터링 및 제어 | X | ||
| 필드 액세스 | 필드 수준에서 데이터 액세스 제어 | X | ||
| 현장 감사 내역 | 보관된 필드 내역 데이터를 보존하는 정책 정의 | X | ||
| 필드 내역 추적 | 필드 내역 추적 및 표시 | X | ||
| Frontdoor.jsp | 기존 세션 ID 및 서버 URL을 사용하여 액세스 허용 | X | ||
| Heroku Connect | Heroku와 Salesforce 간의 양방향 동기화 | X | ||
| Herooku Shield | HIPAA 또는 PCI 호환 앱 구축 | X | ||
| 높은 보증 세션 보안 | 민감한 작업에 추가 보안 필요 | X | ||
| Identity Connect | 사용자 레코드를 Active Directory 계정에 매핑 | X | ||
| ID 확인 내역 | 사용자 ID 확인 시도 감사 | X | ||
| 통합 사용자 라이센스 | API를 통해서만 데이터 및 기능에 대한 액세스 권한을 부여합니다. | X | X | |
| Lightning Login | 약하거나 잊혀진 암호 및 잠긴 계정 방지 | X | ||
| 로그인 액세스 | 지원 사용자가 다른 사용자로 로그인하도록 허용 | X | ||
| 로그인 포렌식 | ID 사기를 나타낼 수 있는 동작 식별 | X | ||
| 로그인 내역 | 조직 및 Experience Cloud 사이트 로그인 시도 모니터링 | X | ||
| 모바일 장치 추적 | 조직에 대한 모바일 장치 액세스 추적 및 모니터링 | X | ||
| Mobile SDK | 독립형 모바일 앱 내에서 Salesforce Platform에 연결 | X | X | X |
| 사용자 권한 모니터링(Shield) | 권한 집합 및 권한 집합 그룹 변경 사항 | X | X | |
| 다단계 인증 | 로그인을 위해 2개 이상의 확인 메서드 필요 | X | X | |
| 상호 인증 | SSL 또는 TLS 상호 인증 적용 | |||
| 내 도메인 | 로그인 페이지 및 정책, SSO, 소셜 로그인 구성 | X | ||
| 명명된 자격 증명 | 끝점 URL 및 인증 매개 변수 지정 | X | ||
| OAuth 인증 | 토큰 교환을 통한 클라이언트 응용 프로그램 액세스 권한 부여 | X | ||
| 암호 정책 | 암호 내역, 길이, 복잡성 설정 | X | ||
| 권한 집합 할당 만료 | 권한 집합 및 권한 집합 그룹 할당에 대한 만료 설정 | X | X | |
| 권한 집합 이벤트 | 권한 집합 및 권한 집합 그룹에 대한 변경 사항 모니터링 | X | X | |
| 권한 집합 그룹 | 복잡한 액세스 요구 사항을 지원하는 번들 권한 집합 | X | ||
| 권한 집합 | 사용자가 메타데이터, 기능 및 앱에 액세스하는 방법 제어 | X | ||
| 개인 연결 | Salesforce와 Amazon 웹 서비스 간의 안전한 통합 | X | ||
| 프로필 | 로그인 IP 범위 및 로그인 시간 제어 | X | ||
| 실시간 이벤트 모니터링 | Salesforce에서 표준 이벤트 모니터링 및 감지 | X | ||
| 원격 사이트 설정 | Apex 또는 JavaScript 호출에 대한 외부 사이트 등록 | X | ||
| 보고 변칙 이벤트 | 사용자가 보고서를 실행하거나 내보내는 방식의 변칙 추적 | X | ||
| 제한 규칙 | 사용자가 불필요한 레코드에 액세스하지 못하도록 방지 | X | ||
| Salesforce 코드 분석기 | IDE, CLI 또는 CI/CD를 통해 코드를 스캔하여 모범 사례를 준수하는지 확인합니다. | X | X | |
| 스코핑 규칙 | 사용자가 볼 수 있는 기본 레코드 제어 | X | ||
| 보안 센터 | 모든 조직 전반의 보안 설정 보기 및 자세 변경에 대한 경고 구성 | X | X | |
| 보안 상태 점검 | 보안 설정에서 취약점 식별 | X | ||
| 세션 하이재킹 이벤트 | 도난 세션 식별자를 통한 무단 액세스 식별 | X | ||
| 세션 관리 클래스 | 활성 세션에 대한 보안 설정 사용자 정의 | X | ||
| 세션 보안 설정 | 세션을 구성하여 악성 공격으로부터 보호 | X | ||
| 설정 감사 내역 | 관리자가 적용한 최근 설정 변경 사항 추적 | X | ||
| 공유 설정 | 레코드 수준에서 데이터 액세스 제어 | X | ||
| Shield Platform Encryption | 유지 및 전송 중 중요한 데이터 암호화 | X | ||
| 단일 등록 | 단일 로그인을 통해 여러 응용 프로그램에 대한 액세스 제공 | X | X | |
| Cross-Domain Identity Management(SCIM) 시스템 | REST API를 통해 시스템 전반의 ID 관리 | X | ||
| 위협 감지 | 통계 및 기계 학습을 사용하여 위협 감지 | X | ||
| 신뢰할 수 있는 IP 범위 | 추가 확인이 필요하지 않은 IP 주소 정의 | X | ||
| 사용자 액세스 보고서 | 사용자의 개체, 레코드, 권한 액세스에 대한 통합 보기 가져오기 | X | X |
| 자원 | 설명 | 조직 보안 | 세션 보안 | 데이터 보안 |
|---|---|---|---|---|
| 공유 아키텍처 가이드 | 액세스 도구, 공유 모델, 사용 사례에 대해 자세히 알아보기 | X | ||
| 설계 표준 템플릿 | 조직에 대한 설계 표준 만들기 | X | X | X |
| 사용자 보안 모델 구축 방법 | 사용자 보안 모델을 더 잘 이해 | X | X | |
| Salesforce에서 최소 권한 원칙 구현 방법 | Salesforce에서 PoLP 데이터 액세스 제어 적용에 대해 알아보기 | X | X | |
| 사용자 세션 모니터링 | 활성 세션 검토 및 의심스러운 세션 종료 | X | ||
| 다단계 인증 | Salesforce에서 공식 MFA 리소스에 액세스 | X | ||
| 권한 집합 그룹(Trailhead) | 권한 집합 그룹 활용 | X | X | |
| REST API 아키텍처 | REST API 용어 및 개념 이해 | X | X | X |
| 보안 및 SOAP API | SOAP API 용어 및 개념 이해 | X | X | X |
| API 및 내부 시스템 사용자를 위한 보안 모범 사례 | API 사용자 및 보안 내부 시스템 사용자가 Salesforce에 안전하게 액세스 | X | ||
| 보안 구현 가이드 | Salesforce 보안을 포괄적으로 살펴봅니다. | X | X | X |
| 보안 정책 템플릿 | 조직에 대한 보안 정책 설정 | X | X | X |
| 세션 유형 | 조직에 액세스하는 데 사용되는 세션 유형 식별 | X | ||
| 위협 모델링 기본 사항(Trailhead) | 보안 위협 및 방지 방법에 대해 알아봅니다. | X |
Salesforce Well-Architected의 관련성을 유지할 수 있도록 도와주십시오. 이 콘텐츠에 대한 사용자 의견을 제공하려면 설문 조사을 작성하고 다음에 원하는 내용을 알려주십시오.