[SFDC] Data Security & Access

최승언·2023년 3월 30일

sfdc

SFDC

목록 보기

2/2

❓Object Access

사용자가 각 개체에 대한 레코드를 만들고, 읽고, 편집하고, 삭제(CRED, Create Read Edit Delete)할 수 있는 기본 수준 액세스 권한을 지정한다.

특정 사용자로부터 전체 탭과 개체를 숨길 수 있으므로 해당 유형의 데이터가 존재하는지조차 알 수 없다.

Permission Sets와 Profiles에서 Object Access를 관리할 수 있다.

❓Field Level Security

사용자가 개체의 특정 필드에 대한 값을 보고, 편집하고, 삭제할 수 있는지 여부를 제어한다. 민감한 필드를 보호할 수 있는 설정이다.

필드는 Profile에 따라 보이지 않거나 읽기전용으로 설정할 수 있다.

필드의 값에 대한 검색을 막지 않는다. 검색어가 필드 수준 보안으로 보호되는 필드 값과 일치하면 연결된 레코드가 보호된 필드 및 해당 값 없이 검색 결과에 반환된다.

❓Profiles

Org 내 Object를 사용하는데 사용자가 할 수 있는 작업을 결정하는 액세스 제어 기능

Profile은 모든 사용자에게 필수적으로 요구된다. Profile이 없으면 사용자를 가질 수 없다.

⚙️유형

Standard Profiles

Salesforce에서는 기본적으로 여러 가지 Standard Profile가 제공되며, 삭제할 수 없다.
(Read Only / Standard User / Marketing User / Contract Manager / Solution Manager / System Administrator)

Custom Profiles
API를 사용하여 custom profile을 만들 수 있고, 기존의 profile을 복제하여 기업의 요구에 맞게 커스터마이징 할 수 있다. 해당 Profile에 할당된 사용자가 없으면 삭제할 수 있다.

❓Permission Sets

사용자에게 다양한 도구 및 기능에 대한 엑세스 권한을 부여하는 설정 및 권한 모음이다.

Permission Set은 Profile과 매우 유사하다. Profile에서 관리할 수 있는 것들을 Permission Set에서도 관리할 수 있다. 하지만 주요 차이점은 사용자가 Profile 하나만 가질 수 있지만, Permission Set은 여러 개 가질 수 있다는 것이다.

따라서 Profile을 정의하여 각 유형의 사용자가 필요한 최소한의 권한과 설정을 부여한 다음, Permission Set을 사용하여 추가적인 액세스 권한을 부여할 수 있다.

모든 유형의 사용자에게 필요한 최소한의 권한과 설정을 부여하도록 Profile을 정의한 다음, Permission Set을 사용하여 사용자의 기능적 액세스를 확장한다.

예시

어느 Org에 기본적인 직무 기능을 수행하는 많은 사용자가 있을 때, 그들이 일을 수행할 수 있도록 모든 액세스 권한을 부여하는 하나의 Profile을 지정할 수 있다. 하지만 일부 사용자는 특별한 앱이나 기능에서 작업하고 있다. 이러한 일부 사용자를 위해서 Permission Set를 생성하고 할당할 수 있다.
일부 사용자는 일시적으로 특정 필드와 개체에 액세스해야할 필요가 있을 때, Permission Set를 생성하고 할당할 수 있다.

Permission Set Groups

Permission Set 여러개를 Permission Set Group에 포함시킬 수 있다. Permission Set Group에는 해당 그룹에 속한 모든 Permission Set의 권한을 가진다.

Muted Permission Sets

Muted Permission Set는 Permission Set Group에 포함된 Permission Set를 비활성화하는 데 사용된다.

Permission Set Groups 설정으로 이동
특정 Permission Set Group을 선택해서 Muting Permission Set in Group을 클릭
참고 : 그룹에서 하나의 muting permission set만 허용된다.
New 버튼을 클릭하고 New Muting Permission Set의 라벨과 API 이름을 입력한 다음 Save 버튼을 클릭한다.
만들어진 Muting Permission Set을 열고, 주어진 목록에서 수정할 Access/Permissions을 선택한다.

장점

Permission set의 권한을 제거하고 새로 만들 필요가 없이 Permission set group을 재사용하여 시간을 절약할 수 있다.
Permission Set Group에서 권한을 뮤트하면 해당 그룹과 관련된 사용자의 권한만 뮤트되고 Permission Set에 할당된 그룹 밖의 사용자들에게는 영향을 미치지 않는다.

❓Roles

사용자가 Salesforce에서 볼 수 있는 데이터를 정의하는 레코드 수준의 액세스 제어

⚙️Public Groups

Public Group이란

여러 사용자를 함께 묶어 그룹화하고 해당 그룹에 대한 액세스 권한을 제어할 수 있는 기능
그룹에는 특정 프로필, 역할 또는 다른 사용자가 포함될 수 있다.

Public Group의 장점

한 번에 여러 사용자에게 레코드, 필드 또는 기타 Salesforce 리소스에 대한 액세스 권한을 부여하는 프로세스를 단순화할 수 있다.

Public Group에 Role을 할당한다면

해당 Role에 속한 사용자가 해당 그룹에서 지정된 권한을 가질 수 있다.
또한, Public Group의 권한을 수정하면 해당 Role에 속한 모든 사용자들에게 권한이 적용된다.

액세스 제어 간소화
Role은 조직의 계층 구조를 나타내므로, Public Group에 Role을 할당함으로써 해당 Role에 속한 모든 사용자에 대한 액세스 권한을 한 번에 관리할 수 있다.
사용자 관리 용이성
Public Group에 Role을 할당하면 새로운 사용자를 추가할 때 각 사용자에게 권한을 부여하는 것보다 훨씬 쉽다.
보안 강화
Public Group에 Role을 할당하면 해당 Role을 기반으로 권한을 관리할 수 있으므로 보안을 강화할 수 있다. Role-Based Access Control(RBAC)는 조직 전체에서 일관성 있는 보안 수준을 유지할 수 있도록 도와준다.
유연성 증가
Public Group은 다른 사용자와 함께 그룹화될 수 있기 때문에 해당 Role을 가진 사용자에게 필요한 액세스 권한을 다른 부서나 프로젝트에서도 제공할 수 있다.

❓Record Level Access

사용자가 자신의 Profile에서 액세스 권한이 있는 각 객체에서 보고 편집할 수 있는 개별 레코드를 결정한다.

레코드에 대한 권한은 항상 개체 수준, 필드 수준 및 레코드 수준 권한의 조합에 따라 평가된다.

서로 다른 사용자 Group 간에 레코드 수준 공유를 제어하는 4가지 매커니즘이 있다.

⚙️Organizational-Wide Default(OWD)

각 사용자가 특정 개체의 레코드에 대해 갖는 액세스 수준을 정의한다.

OWD를 사용하여 데이터를 잠근 다음, Role Hierarchy / Sharing Rules / Manual Sharing을 사용하여 요구 사항에 맞게 권한을 제어한다.

OWD는 개체의 모든 레코드에 대한 기본 액세스 수준을 결정한다.

⭐ OWD는 Profile에서 부여된 것보다 더 많은 액세스 권한을 사용자에게 부여할 수 없다.

- Access Levels

Public Read/Write
모든 사용자가 모든 레코드를 보고, 편집할 수 있다.
가장 낮은 보안 수준을 제공하지만, Org 내에서 레코드를 공유하기 가장 쉬운 방법이다.
Public Read Only
모든 사용자가 레코드를 읽을 수 있지만, 편집할 수는 없다.
팀 간 공유가 필요한 경우에 사용된다.
Private
레코드에 대한 가장 제한적인 액세스 권한을 부여한다. 해당 레코드를 만든 소유자와 상위 계층에 해당하는 사용자만 레코드를 보고, 편집할 수 있다.
Controlled by Parent
상위 레코드가 하위 레코드의 보안 설정을 결정하는 방식이다.
Public Read/Write/Transfer
모든 사용자들이 볼 수 있고, 수정할 수 있다. Case와 Lead에서만 사용할 수 있다.

Campaign에서만 가능한 level

Public Full Access
모든 사용자들이 모든 레코드를 보고, 수정하고, 삭제할 수 있다.

PriceBook에서만 가능한 level

Use
PriceBook의 기본 액세스 수준이며, 사용자가 PriceBook 정보에 액세스하고 해당 PriceBook 정보를 Product와 함께 Opportunity에 사용할 수 있다.
View only
사용자가 PriceBook 정보에 액세스할 수 있지만 Product와 관련된 Opportunity에서 해당 PriceBook 정보를 사용할 수는 없다.
No Access
PriceBook 정보 및 가격에 액세스하는 것을 제한한다.

OWD는 Org의 데이터 보안 수준을 결정하는 중요한 설정 중 하나이며, Org의 비즈니스 규칙 및 보안 요구 사항에 따라 적절한 수준으로 구성되어야 한다. 또한, OWD는 Org 내에서 레코드에 대한 액세스 권한을 제어하는 중요한 요소이므로, 신중하게 고려하여 구성해야 한다.

⭐Custom Object가 Standard Object와 Master-Detail 관계일 경우, OWD 설정은 'Controlled by Parent'가 되며, 변경할 수 없다.

⚙️Role hierarchy

Org 내에서 계층 구조를 형성하는 기능

사용자가 조직 내에서 어디에 위치하고 있는지를 나타내는데, 이를 통해 사용자의 데이터 액세스 권한을 관리할 수 있다.

예를 들어, 조직 내에서 상위 직원은 모든 하위 직원들이 볼 수 있는 데이터를 볼 수 있지만, 하위 직원들은 상위 직원이 볼 수 있는 데이터를 볼 수 없다. 이렇게 Role 계층 구조를 사용하여 데이터 보안을 강화할 수 있다.

사용자들은 반드시 Role을 가져야 하는 것은 아니다.

Top-level Role
Org의 최상위 레벨에 위치한 Role
Mid-level Role
Top-level Role 밑에 위치한 Role로, Top-level Role은 Mid-level Role에 대한 액세스 권한을 가진다.
Low-level Role
Mid-level Role에 속한 Role로, Mid-level Role과 Top-level Role은 Low-level Role에 대한 액세스 권한을 가진다.

Role hierarchy는 각 Role별로 다른 권한을 할당할 수 있으므로 Org의 비즈니스 규칙을 따르고, 보안을 유지하면서 데이터에 대한 액세스 권한을 효과적으로 관리할 수 있다.

⚙️Role-Based Access Control(RBAC)

RBAC는 왜 필요한가

RBAC는 대규모, 복잡하고 분산된 환경에서 사용자의 액세스 권한을 명확하고 간단하게 제어할 수 있도록 도와준다.
직원, 제3자 계약자 또는 기타 많은 근로자들이 일상 업무 수행을 위해 동일하거나 유사한 액세스 권한을 필요로 하기 때문에 조직 내에서 Role에 따라 사람들을 그룹화 하여 액세스 권한을 부여하는 것이 매우 간단하다.

권한을 제어하고 자동으로 부여하지 못한다면 Org에게 다양한 방식으로 비용이 발생할 수 있다.

새로운 직원 및 계약자가 필요한 권한을 빠르게 확보하지 못하면 업무 진행이 늦어짐
권한이 없어야 할 시스템에 접근할 수 있게 될 수 있음
직무 변경이나 조직 이탈 후에도 권한이 유지될 가능성이 있음

이러한 문제점은 회사의 보안을 위협한다.

RBAC란 무엇인가

조직 내에서 정의된 사용자의 Role에 따라 비즈니스 네트워크의 일부에 대한 액세스 제한을 설정하는 것
⭐핵심은 사용자가 자신의 Role에 필요한 자원만 사용할 수 있도록 하는 것

Example

마케팅 : Facebook Ads, Google Analytics, Google Ads
재무 : Xero, 수입/지출 스프레드시트
인사 : 인사 관리 도구 (Workday 같은..)

장점

비용 절감
사용자 액세스 권한 부여의 복잡성과 연관된 비용을 줄일 수 있다. 액세스 권한을 검토하여 다양한 규정을 준수하도록 보장하고, 새로운 직원이 조직의 역할에 따라 미리 지정된 시스템에 액세스할 수 있도록 최적화하여 효율성을 높일 수 있다.
보안 강화
높은 효율성
절차 간소화
규정 준수

⚙️Sharing Rules

데이터 공유 규칙을 정의하는 도구

특정 레코드를 다른 사용자나 그룹과 공유하도록 허용하며, 기존의 OWD나 Role hierarchy 규칙으로는 제어할 수 없는 데이터에 대한 액세스 권한을 제어할 수 있다.

Criteria-Based Sharing Rule
특정 기준을 충족하는 레코드를 다른 사용자나 그룹과 공유한다. 예를 들어, 지역이나 특정 조건에 따라 레코드를 공유할 수 있다.
Owner-Based Sharing Rule
레코드의 소유자를 기반으로 한다. 레코드의 소유자가 다른 사용자나 그룹과 레코드를 공유할 수 있도록 허용한다.

Sharing Rule은 기존의 OWD나 Role hierarchy와 함께 사용되어 높은 수준의 데이터 보안을 제공한다. 이를 통해 Org는 데이터에 대한 액세스 권한을 세밀하게 제어할 수 있으며, 기업에서 필요한 보안 규정을 따를 수 있다.

수동으로 다른 사용자와 레코드를 공유할 수 있다.

특정 다른 사용자에게 특정 유형의 레코드에 대한 액세스 권한을 부여할 수 있다.

- 사용 가능한 경우

사용자가 계층 구조에서 소유자의 상위 계층이거나 전체 액세스 권한이 있는 사용자이거나 관리자여야 한다.
개체에 대한 OWD 설정이 private 또는 Public read only이어야 한다.

❓Roles vs. Profiles

Roles는 사용자가 볼 수 있는 것을 결정하고,
Profiles는 사용자가 할 수 있는 것을 결정한다.

Roles	Profiles
사용자의 레코드 가시성 액세스	사용자의 레코드 CRED(create, read, edit, delete)에 대한 액세스
레코드 수준의 엑세스	Object 또는 필드 수준의 액세스
계층 구조를 따르며, 계층 구조에 따라 데이터 가시성 권한이 부여된다	계층 구조를 따르지 않으며, 프로필을 기반으로 권한이 부여된다
항상 Profile에 의존적이다	Role에 독립적일 수 있다
사용자에게 필수적으로 요구되지 않는다	사용자에게 필수적으로 요구된다
레코드와 필드에 대한 액세스만을 제어	Object, 필드 수준의 보안, 페이지 레이아웃, 레코드 유형, 앱에 대한 엑세스를 제어
부하직원을 포함한 데이터에 대한 가시성 액세스 권한	Profile을 기반으로 데이터 변경에 대한 액세스 권한

참고

최승언

공부기록

이전 포스트