---
schema_version: "1"
id: d3e0833e528513c94765b9bbe50e673a246e13f3c2cb1ba9f2f25cae8ebaa3ef
title: ID 및 액세스 관리 - 패턴
collection: architect
version: current
locale: ko-kr
portal_url: https://docs.salesforce.com/architect/current/ko-kr/well-architected/guides/trust-identity-access-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/ko-kr/well-architected/guide/trust-identity-access-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: d68e5fd9475e057aadab9cd8397d1600e64a654e8e04aa3b71287dd65a5fa8d7
products:
  - 잘 설계된 프레임워크
  - Architect Site Content Repo
---
# ID 및 액세스 관리 - 패턴

<br>

Well-Architected [Trust](/docs/architect/ko-kr/well-architected/guide/trust.html)에 대해 자세히 알아보기 → [ID 및 액세스 관리](/docs/architect/ko-kr/well-architected/guide/trust.html#identity-and-access-management)

## 기본 경계인 ID

**패턴**

| 찾을 위치 | 유사성 |
| --- | --- |
| 플랫폼 \| 아키텍처                   | ✅ 액세스 제어는 네트워크 위치 또는 장치에 관계없이 모든 요청에서 명시적으로 ID를 확인합니다.                                              |
| 플랫폼 \| 아키텍처                   | ✅ ID 기반 보안 컨트롤은 네트워크 기반 Trust 가정을 대체합니다.                                                                            |
| 플랫폼 \| 조직                            | ✅ 액세스 결정은 액세스를 요청하는 사람(인증), 액세스 권한이 부여된 작업(인증), 컨텍스트(장치, 위치)를 고려합니다. |
| 플랫폼 \| 문서                  | ✅ 보안 아키텍처는 ID를 네트워크 주변이 아닌 기본 Trust 경계로 문서화합니다.                                                       |

**안티 패턴**

| 찾을 위치 | 불만 사항 |
| --- | --- |
| 플랫폼 \| 아키텍처                   | ⚡️ 기업 네트워크 또는 VPN 사용자는 신뢰할 수 있는 것으로 간주되며 네트워크 위치만을 기반으로 광범위한 액세스 권한이 부여됩니다. |
| 플랫폼 \| 아키텍처                   | ⚡️ 액세스 제어는 ID 확인이 아닌 네트워크 주변에 의존합니다.                                          |
| 플랫폼 \| 조직                            | ⚡️ 액세스 결정은 컨텍스트 신호(장치, 위치, 시간, 동작 패턴)를 고려하지 않습니다.                         |
| 플랫폼 \| 문서                  | ⚡️ 보안 아키텍처는 네트워크 위치를 기본 Trust 경계로 처리합니다.                                              |

## Salesforce 4계층 액세스 모델

**패턴**

| 찾을 위치 | 유사성 |
| --- | --- |
| 플랫폼 \| 조직                            | ✅ 솔루션은 네 가지 Salesforce 액세스 계층 모두를 활용합니다. 조직(라이센스, 기능), 개체(CRUD), 필드(FLS), 레코드(공유)                |
| 플랫폼 \| 조직                            | ✅ 액세스 모델은 하향식(org → 개체 → 필드 → 레코드)으로 설계되고 하향식으로 확인됨                                                            |
| 플랫폼 \| 조직                            | ✅ 중요한 데이터가 포함된 개체의 경우 조직 전체 기본값(OWD)이 비공개로 설정됩니다.                                                            |
| 플랫폼 \| 조직                            | ✅ 공용 읽기 전용으로 설정된 OWD는 광범위한 가시성이 위험을 노출하지 않고 비즈니스를 지원하는 참조 개체(제품, 가격 목록)로 제한됩니다. |
| 플랫폼 \| 조직                            | ✅ 조직 수준 제약(라이센스, IP 범위, 로그인 시간, 기능 권한)이 사용자 모집단의 기준 기능을 정의합니다.             |
| 플랫폼 \| 조직                            | ✅ 개체 권한(프로필 및 권한 집합을 통해)은 사용자 세그먼트의 각 개체에 대한 만들기, 읽기, 편집, 삭제 액세스를 제어합니다.                                                                  |
| 플랫폼 \| 조직                            | ✅ 필드 수준 보안은 개체 액세스 권한이 부여된 경우에도 민감한 필드를 보호합니다.                                                                    |
| 플랫폼 \| 조직                            | ✅ 레코드 수준 공유는 문서화된 비즈니스 요구 사항을 기반으로 역할 계층 및 공유 규칙을 사용합니다.                                                 |
| 플랫폼 \| 조직                            | ✅ 권한 기본값 이후에 제한되지 않고 제한 기준선에서 의도적으로 확장된 액세스                                                  |

**안티 패턴**

| 찾을 위치 | 불만 사항 |
| --- | --- |
| 플랫폼 \| 조직                            | ⚡️ 액세스 모델은 네 가지 계층(조직, 개체, 필드, 레코드)을 모두 활용하지 않습니다.                                             |
| 플랫폼 \| 조직                            | ⚡️ OWD는 제한 없이 개발하는 동안 편리하게 공용 읽기/쓰기로 설정됩니다.                                   |
| 플랫폼 \| 조직                            | ⚡️ 초과 권한 부여 OWD가 조기에 설정되면 데이터 용량이 증가하고 비즈니스 프로세스가 결정화되기 때문에 제한이 기하급수적으로 어려워집니다. |
| 플랫폼 \| 조직                            | ⚡️ 개체 또는 레코드 수준 액세스 제어에만 의존하는 필드 수준 보안이 구성되지 않음                                 |

## 인증 아키텍처

**패턴**

| 찾을 위치 | 유사성 |
| --- | --- |
| 플랫폼 \| 조직                            | ✅ 프로덕션 환경에 액세스하는 모든 사용자에게 다단계 인증(MFA)이 적용됩니다(UI 액세스 필수)                                                                      |
| 플랫폼 \| 조직                            | ✅ MFA는 대량 데이터 내보내기, 권한 변경, 관리 구성 등 특권 작업으로 확장됩니다.                                                                   |
| 플랫폼 \| 조직                            | ✅ 싱글사인온(SSO)은 SAML 2.0 또는 OpenID Connect 프로토콜을 사용합니다.                                                                                                                               |
| 플랫폼 \| 조직                            | ✅ 세션 시간 제한이 적절하게 구성되어 있습니다. 표준 사용자의 경우 2시간, 관리자 및 제한된 데이터에 액세스하는 사용자의 경우 15~30분                                                |
| 플랫폼 \| 조직                            | ✅ 관리 프로필 및 통합 사용자에게 IP 제한이 적용됨                                                                                                               |
| 플랫폼 \| 조직                            | ✅ 로그인 시간은 서비스 계정을 예상되는 운영 기간으로 제한합니다.                                                                                                                        |
| 플랫폼 \| 조직                            | ✅ 인식되지 않는 장치의 로그인을 확인하는 기본 장치 활성화, MFA 및 IP 제한으로 높은 권한이 있는 계정에 대한 보호 기능 추가                                                                                                                        |
| 플랫폼 \| 조직                            | ✅ SSO가 활성화된 경우 승인된 관리자 사용자에게 직접 로그인 액세스 권한이 부여됩니다(중단 처리 절차).                                                                                                    |
| 플랫폼 \| 조직                            | ✅ Salesforce에 로그인하는 사용자와 엔티티 간의 관계는 1:1(공유 사용자 계정 없음)                                                                                         |
| 플랫폼 \| 조직                            | ✅ API 액세스 제어 - 사용자가 무단 연결된 앱을 통해 인증할 수 없음                                                                                                        |
| 플랫폼 \| 명명된 자격 증명              | ✅ 명명된 자격 증명 및 외부 자격 증명은 순환 기능을 사용하여 인증을 중앙에서 관리합니다.                                                                                        |
| 플랫폼 \| 명명된 자격 증명              | ✅ 명명된 자격 증명 코드에서 인증 세부 사항 추상화, 코드 변경 없이 자격 증명 업데이트 활성화                                                                                |
| 플랫폼 \| 명명된 자격 증명              | ✅ 자격 증명은 코드, 구성 파일 또는 버전 관리에 포함되지 않습니다.                                                                                                              |
| 플랫폼 \| Apex                           | ✅ 인증을 실행하는 메서드는 명명된 자격 증명을 사용하여 사용자 이름/암호 플로를 처리합니다.                                                                                                  |
| 플랫폼 \| Apex                           | ✅ 읽을 수 있는 형식(하드 코딩된 값 또는 문자열 없음)의 코드에 사용자 이름 또는 암호가 표시되지 않음                                                                                               |
| 플랫폼 \| Aura                           | ✅ 인증을 실행하는 메서드는 명명된 자격 증명을 사용하여 사용자 이름/암호 플로를 처리합니다.                                                                                                  |
| 플랫폼 \| Aura                           | ✅ 읽을 수 있는 형식의 코드에 사용자 이름 또는 암호가 표시되지 않음                                                                                                                                 |
| 플랫폼 \| Lightning 웹 구성 요소(LWC) | ✅ 인증을 실행하는 메서드는 명명된 자격 증명을 사용합니다.                                                                                                                                    |
| 플랫폼 \| Lightning 웹 구성 요소(LWC) | ✅ 코드에 사용자 이름 또는 암호가 표시되지 않음                                                                                                                                                     |
| 통합 \| API                         | ✅ OAuth 2.0 JWT 전달자 플로는 신뢰할 수 있는 환경에서 서버 간 통합에 사용됩니다(프로덕션 통합의 경우 기본).                                                          |
| 통합 \| API                         | ✅ OAuth 2.0 웹 서버 플로는 사용자 컨텍스트가 필요한 서버 간 통합에 사용됩니다.                                                                                                   |
| 통합 \| API                         | ✅ OAuth 2.0 장치 플로는 헤드리스 장치에 사용됩니다. CLI 및 CI/CD 툴링은 웹 서버 플로(`sf org login web`) 또는 JWT 전달자 플로(`sf org login jwt`)를 사용합니다. 2025년 8월 28일부터 기본 Salesforce CLI 연결된 앱의 장치 플로가 차단되었습니다. |
| 통합 \| API                         | ✅ 사용자 이름-암호 OAuth 플로는 사용되지 않으며, 사용하는 기존 통합은 JWT 전달자 또는 클라이언트 자격 증명 플로로 마이그레이션됩니다. |

**안티 패턴**

| 찾을 위치 | 불만 사항 |
| --- | --- |
| 플랫폼 \| 조직                            | ⚡️ MFA는 프로덕션 환경 액세스에 적용되지 않음                                                           |
| 플랫폼 \| 조직                            | ⚡️ 로그인 구성이 Salesforce MFA 요구 사항에 부합하지 않음                                                |
| 플랫폼 \| 조직                            | ⚡️ MFA는 특권 작업(대량 내보내기, 권한 변경, 관리 구성)으로 확장되지 않음   |
| 플랫폼 \| 조직                            | ⚡️ 세션 시간 제한이 구성되지 않았거나 과도하게 허용됨(24시간 이상)                                      |
| 플랫폼 \| 조직                            | ⚡️ 세션 정책은 표준 사용자와 제한된 데이터에 액세스하는 관리자/사용자를 구분하지 않습니다. |
| 플랫폼 \| 조직                            | ⚡️ 관리 프로필 및 통합 사용자에게 IP 제한이 적용되지 않음                              |
| 플랫폼 \| 조직                            | ⚡️ 서비스 계정의 로그인 시간이 예상 운영 기간으로 제한되지 않음                             |
| 플랫폼 \| 조직                            | ⚡️ 높은 권한이 있는 계정은 MFA 또는 IP 제한이 추가되지 않은 장치 활성화 외에는 아무것도 사용하지 않습니다.                                                      |
| 플랫폼 \| 조직                            | ⚡️ SSO가 활성화된 경우 승인된 관리자 사용자가 직접 로그인 액세스 권한을 보유하지 않습니다(단계별 절차 없음)                 |
| 플랫폼 \| 조직                            | ⚡️ 사용자와 엔티티 간의 관계는 1:1가 아닙니다(공유 사용자 계정 있음)                             |
| 플랫폼 \| 조직                            | ⚡️ API 액세스 제어가 활성화되지 않음                                                                               |
| 플랫폼 \| 명명된 자격 증명              | ⚡️ 자격 증명은 코드, 구성 파일 또는 버전 관리에 직접 포함됩니다.                              |
| 플랫폼 \| Apex                           | ⚡️ 사용자 이름 및 암호가 읽을 수 있는 형식으로 코드로 표시됩니다.                                                      |
| 플랫폼 \| Apex                           | ⚡️ 일관적인 구현 없이 인증이 임시로 처리됩니다.                                              |
| 플랫폼 \| Aura                           | ⚡️ 인증은 명명된 자격 증명 없이 임시로 처리됩니다.                                                      |
| 플랫폼 \| Aura                           | ⚡️ 코드에 사용자 이름 및 암호 표시                                                                          |
| 플랫폼 \| Lightning 웹 구성 요소(LWC) | ⚡️ 인증은 명명된 자격 증명 없이 임시로 처리됩니다.                                                      |
| 플랫폼 \| Lightning 웹 구성 요소(LWC) | ⚡️ 코드에 사용자 이름 및 암호 표시                                                                          |
| 플랫폼 \| 비즈니스                       | ⚡️ 사용자 프로비저닝 및 프로비저닝 해제 SLA 및 요구 사항이 없음                                         |
| 통합 \| API                         | ⚡️ 더 많은 보안 OAuth 플로를 사용할 수 있는 경우 사용자 이름-암호 OAuth 플로가 사용됩니다.                                 |
| 통합 \| API                         | ⚡️ OAuth 범위가 과도하게 허용되는 경우(범위 제한이 충분한 경우 전체 액세스)                               |
| 통합 \| API                         | ⚡️ 클라이언트 자격 증명(클라이언트 ID, 클라이언트 암호)이 코드 또는 구성 파일에 안전하지 않게 저장됩니다.                     |

## 인가 및 액세스 제어

**패턴**

| 찾을 위치 | 유사성 |
| --- | --- |
| 플랫폼 \| 조직                            | ✅ 역할 계층 깊이는 최대 5~7개 수준(성능 오버헤드 및 복잡한 문제 해결 방지)                                                                                |
| 플랫폼 \| 조직                            | ✅ 권한 집합 및 권한 집합 그룹은 프로필 확산 없이 유연하고 추가적인 액세스를 제공합니다.                                                                                |
| 플랫폼 \| 조직                            | ✅ 권한 집합은 특정 직무, 신청 또는 임시 승진된 권한에 대한 액세스 권한을 부여합니다.                                                                                  |
| 플랫폼 \| 조직                            | ✅ 권한 집합 그룹 - 예외에 대한 무시 기능과 관련 권한 집합 결합                                                                                            |
| 플랫폼 \| 조직                            | ✅ 권한 집합 및 권한 집합 그룹(프로필 아님)을 통해 모든 기능 액세스 권한이 부여되어 작업 역할이 발전함에 따라 유연성을 제공합니다.                                             |
| 플랫폼 \| 조직                            | ✅ 트랜잭션 보안 정책은 실시간 컨텍스트 평가를 통해 인증 연장                                                                                                  |
| 플랫폼 \| 조직                            | ✅ 트랜잭션 보안 정책은 비정상적인 동작을 감지하고 차단합니다(모형을 초과하는 대량 데이터 다운로드, 예기치 않은 지역에서 로그인, 변경 기간 외부의 권한 변경) |
| 플랫폼 \| 조직                            | ✅ 중요한 작업 또는 데이터 액세스에 대해 IP 제한이 구성됩니다.                                                                                                            |
| 플랫폼 \| 조직                            | ✅ 모든 통합에 대해 고유한 API 전용 통합 사용자가 구성됨                                                                                                                   |
| 플랫폼 \| Apex                           | ✅ 모든 코드 액세스 데이터는 USER_MODE, SYSTEM_MODE 키워드 또는 Security.stripInaccessible() 메서드를 사용하여 CRUD 및 FLS를 적용합니다.                                                    |
| 플랫폼 \| Apex                           | ✅ SOQL 쿼리는 비즈니스 요구 사항을 기반으로 명시적으로 WITH USER_MODE 또는 WITH SYSTEM_MODE 키워드를 사용합니다.                                                                                   |
| 플랫폼 \| Apex                           | ✅ DML 작업은 삽입/업데이트/업데이트 작업 전에 Security.stripInaccessible()를 사용하여 액세스 적용                                                                            |
| 플랫폼 \| Apex                           | ✅ 데이터 운영에 대한 사용자 또는 시스템 모드를 명시적으로 선언하는 데이터베이스 DML 문                                                                                                       |
| 플랫폼 \| Apex                           | ✅ 데이터베이스 작업에서 stripInaccessible() 메서드를 사용하여 쿼리 및 하위 쿼리 결과를 필터링합니다.                                                                                                 |
| 플랫폼 \| Apex                           | ✅ 공유 키워드(공유 포함, 공유 없음, 상속된 공유)가 비즈니스 보안 요구 사항에 따라 적절하게 사용됩니다.                                                       |
| 플랫폼 \| 설계 표준               | ✅ 고급 권한(모든 데이터 수정, 모든 데이터 보기)을 부여하기 위한 사용 사례는 비즈니스 근거와 함께 명확하게 문서화되어 있습니다.                                                           |

**안티 패턴**

| 찾을 위치 | 불만 사항 |
| --- | --- |
| 플랫폼 \| 조직                            | ⚡️ 역할 계층은 5~7개 수준보다 깊으므로 공유 계산의 성능 오버헤드 및 복잡성 문제 해결                                       |
| 플랫폼 \| 조직                            | ⚡️ 역할 계층은 비즈니스 근거 없이 광범위한 액세스 권한을 부여합니다.                                                                                                    |
| 플랫폼 \| 조직                            | ⚡️ 프로필이 가벼운 권한 변형에 대해 반복적으로 복제되어 명확하지 않은 구분을 가진 수십 개의 프로필이 생성됩니다.                                                |
| 플랫폼 \| 조직                            | ⚡️ 프로필에 메타데이터에 대한 액세스 제어가 포함되어 있습니다(권한 집합 사용)                                                                                           |
| 플랫폼 \| 조직                            | ⚡️ 비정상 동작을 감지하기 위해 트랜잭션 보안 정책이 구현되지 않음                                                                                       |
| 플랫폼 \| 조직                            | ⚡️ 중요한 작업 또는 데이터 액세스에 대해 IP 제한이 구성되지 않음                                                                                    |
| 플랫폼 \| 조직                            | ⚡️ API 전용 사용자가 구성되지 않거나 여러 통합에서 공유됩니다.                                                                                         |
| 플랫폼 \| 조직                            | ⚡️ 모든 데이터 보기 또는 모든 데이터 수정 권한은 문서화된 근거 없이 부여됩니다.                                                                            |
| 플랫폼 \| Apex                           | ⚡️ SOQL/SOSL 쿼리 및 DML 작업은 명시적 액세스 확인 없이 기본 시스템 모드에서 실행됩니다.                                                                       |
| 플랫폼 \| Apex                           | ⚡️ CRUD 및 FLS 적용이 일관되지 않거나 누락됨                                                                                                                  |
| 플랫폼 \| Apex                           | ⚡️ SOQL은 제거되어 이제 컴파일 오류를 야기한 WITH SECURITY_ENFORCED에 의존합니다(WITH USER_MODE로 대체). |
| 플랫폼 \| Apex                           | ⚡️ 공유 키워드가 일관되지 않거나 사용되지 않습니다.                                                                                                               |
| 플랫폼 \| 설계 표준               | ⚡️ 향상된 권한을 부여하기 위한 사용 사례는 명확하게 문서화되지 않음                                                                                               |

## 특성 기반 액세스 제어(ABAC) 및 Data 360

**패턴**

| 찾을 위치 | 유사성 |
| --- | --- |
| 플랫폼 \| Data 360                       | ✅ RBAC(역할, 프로필, 권한 집합)는 플랫폼 액세스를 제어합니다(Data 360을 사용할 수 있는 사용자), ABAC는 데이터 액세스를 제어합니다(특성을 기반으로 표시되는 데이터)                              |
| 플랫폼 \| Data 360                       | ✅ AI 에이전트는 요청 사용자의 컨텍스트에서 실행되므로 에이전트가 생성한 쿼리는 시스템 수준 액세스 권한으로 실행되지 않고 해당 사용자의 액세스 권한에 의해 제한됩니다.         |
| 플랫폼 \| 문서                  | ✅ 데이터 분류 분류는 특성 정의, 적용 규칙 및 비즈니스 근거와 함께 문서화됩니다.                                                                     |

**안티 패턴**

| 찾을 위치 | 불만 사항 |
| --- | --- |
| 플랫폼 \| Data 360                       | ⚡️ 데이터 분류를 따라야 하는 액세스는 특성 기반 액세스 제어 대신 표현할 수 없는 역할 계층 및 공유를 통해 강제 적용됩니다. |
| 플랫폼 \| Data 360                       | ⚡️ FLS 우회: 필드 수준 액세스 권한이 없는 사용자가 FLS를 적용하지 않는 API 또는 SOQL 쿼리를 통해 데이터를 검색합니다.                                                    |
| 플랫폼 \| Data 360                       | ⚡️ AI 에이전트가 요청 사용자의 컨텍스트에서 실행하지 않고 데이터를 쿼리하며, 에이전트 생성 쿼리는 개체, 필드, 레코드 수준 액세스 제어를 우회합니다.    |
| 플랫폼 \| Data 360                       | ⚡️ 에이전트 실행 컨텍스트에는 사용자 대리 특성이 포함되지 않으며, 에이전트가 시스템 수준 액세스로 작업합니다.                                               |
| 플랫폼 \| 문서                  | ⚡️ 데이터 분류 분류 분류는 문서화되지 않으며, 특성 정의는 일관되지 않은 적용을 만드는 팀에 따라 다릅니다.                                           |

## 중요 영향 계정

**패턴**

| 찾을 위치 | 유사성 |
| --- | --- |
| 플랫폼 \| 조직                            | ✅ 중요 영향 계정(시스템 관리자, 통합 사용자, 자동 프로세스 계정)이 자산 재고에서 식별 및 추적됨 |
| 플랫폼 \| 조직                            | ✅ 중요 영향 계정은 광범위한 플랫폼 액세스를 제공하는 높은 권한으로 인해 가치가 높은 대상을 나타냅니다.                              |
| 플랫폼 \| 조직                            | ✅ 하드웨어 보안 키 또는 인증 앱은 MFA(SMS가 아닌 SIM 교체에 취약)에 필요합니다.                              |
| 플랫폼 \| 조직                            | ✅ 로그인 IP 범위는 알려진 관리 위치로 제한됩니다.                                                                              |
| 플랫폼 \| 조직                            | ✅ 로그인 경고 및 권한 변경 알림 활성화                                                                                  |
| 플랫폼 \| 조직                            | ✅ 문서화된 증거를 통해 분기별 액세스 검토 수행                                                                            |
| 플랫폼 \| 조직                            | ✅ 사용 후 감사를 통한 긴급 액세스에 대한 고장 절차가 있습니다.                                                                         |
| 통합 \| 서비스 계정            | ✅ OAuth 플로는 통합 및 서비스 계정에 사용됩니다(사용자 이름-암호 없음).                                                           |
| 통합 \| 서비스 계정            | ✅ 통합 사용자에게 IP 제한이 적용됨                                                                                            |
| 통합 \| 서비스 계정            | ✅ 자격 증명 순환 일정이 구현됨(분기별 또는 정책별)                                                                       |
| 통합 \| 서비스 계정            | ✅ 이벤트 모니터링을 통해 비정상적인 API 사용 패턴 모니터링                                                                           |
| 통합 \| 서비스 계정            | ✅ 각 통합에는 최소 필수 권한이 있는 전용 서비스 계정이 있습니다(넓은 액세스 권한이 있는 공유 "통합 사용자"가 아님).          |
| 통합 \| 서비스 계정            | ✅ 서비스 계정은 비동기 작업이므로 최소 권한을 엄격하게 적용합니다.                                                               |

**안티 패턴**

| 찾을 위치 | 불만 사항 |
| --- | --- |
| 플랫폼 \| 조직                            | ⚡️ 중요 영향 계정(관리자, 통합, 자동화)이 식별, 추적 또는 목록화되지 않음 |
| 플랫폼 \| 조직                            | ⚡️ 시스템 관리자는 하드웨어 보안 키 또는 인증 앱 대신 SMS 기반 MFA를 사용합니다.       |
| 플랫폼 \| 조직                            | ⚡️ 중요 영향 계정에는 로그인 시간 또는 IP 제한이 없습니다.                                        |
| 플랫폼 \| 조직                            | ⚡️ 특권 계정의 로그인 또는 권한 변경에 대한 경고가 구성되지 않음                       |
| 플랫폼 \| 조직                            | ⚡️ 중요 영향 계정 액세스는 정기적으로 검토되거나 비정기적으로 검토되지 않습니다(분기별이 아님).              |
| 플랫폼 \| 조직                            | ⚡️ 비상 액세스에 대한 중단 절차가 없습니다.                                                  |
| 통합 \| 서비스 계정            | ⚡️ 단일 "API 사용자" 계정은 모든 데이터 수정 권한이 있는 여러 통합에서 공유됩니다.    |
| 통합 \| 서비스 계정            | ⚡️ OAuth를 사용할 수 있는 경우 서비스 계정에서 사용자 이름-암호 인증을 사용합니다.                         |
| 통합 \| 서비스 계정            | ⚡️ 서비스 계정 자격 증명은 수년 동안 변경되지 않은 정적 암호를 사용합니다(순환 없음)                    |
| 통합 \| 서비스 계정            | ⚡️ 서비스 계정에 통합에 필요한 것보다 과도한 권한이 있습니다.                           |
| 통합 \| 서비스 계정            | ⚡️ 서비스 계정의 비정상적인 API 사용 패턴은 모니터링되지 않습니다.                                   |

## ID 수명 주기 관리

**패턴**

| 찾을 위치 | 유사성 |
| --- | --- |
| 플랫폼 \| 프로세스                        | ✅ ID 수명 주기에는 다음이 포함됩니다. 프로비저닝(기본 액세스 권한으로 만들기), 액세스 조정(역할 변경 시 부여/취소), 정기 재인증(분기별 유효성 검사), 프로비저닝 취소(즉시 해지) |
| 플랫폼 \| 조직                            | ✅ ID 공급자의 자동 프로비저닝을 위해 SCIM(Cross-domain Identity Management System)이 구현됨                                                                                              |
| 플랫폼 \| 프로세스                        | ✅ 프로비저닝 - HR 시스템 이벤트로 트리거된 기본 액세스 일치 작업 기능이 있는 계정 생성                                                                                                           |
| 플랫폼 \| 프로세스                        | ✅ 액세스 조정은 역할이 확장되면 추가 권한을 부여하고 역할이 변경되면 권한을 취소합니다.                                                                                                         |
| 플랫폼 \| 프로세스                        | ✅ 관리자가 팀에 대한 액세스를 검토하고 유효성을 검사하는 분기별 정기 재인증                                                                                                               |
| 플랫폼 \| 프로세스                        | ✅ 프로비저닝을 해제하면 고용이 종료되거나 역할에 더 이상 Salesforce가 필요하지 않으면 액세스가 즉시 취소됩니다.                                                                                                              |
| 플랫폼 \| 조직                            | ✅ 자동 감지가 90일 이내에 로그인하지 않은 사용자를 식별하고 액세스 검토 워크플로를 트리거합니다.                                                                                                   |
| 플랫폼 \| 조직                            | ✅ 적시에(JIT) 프로비저닝 - 적절한 경우 SSO에서 사용자를 자동으로 만듭니다.                                                                                                                             |

**안티 패턴**

| 찾을 위치 | 불만 사항 |
| --- | --- |
| 플랫폼 \| 조직                            | ID 공급자 통합이 있어도 SCIM 프로비저닝이 구현되지 않음                    |
| 플랫폼 \| 프로세스                        | ⚡️ 표준 온보딩 절차 없이 새 사용자가 수동으로 생성됩니다.                                |
| 플랫폼 \| 프로세스                        | ⚡️ 초기 사용자 액세스가 일관되지 않거나 기존 사용자 복사를 기반으로 합니다.                               |
| 플랫폼 \| 프로세스                        | ⚡️ 역할 변경 또는 전송에 대한 액세스 변경 사항이 지연되거나 완료되지 않음                               |
| 플랫폼 \| 프로세스                        | ⚡️ 오프보딩이 지연되었으며, 이전 직원은 종료 후 액세스 권한을 유지합니다(동일 비활성화 아님). |
| 플랫폼 \| 조직                            | ⚡️ 사용자 프로비저닝에 대한 자동화가 없음(수동 사용자 만들기 전용)                               |
| 플랫폼 \| 프로세스                        | ⚡️ 액세스 재인증 캠페인이 없음(분기별 또는 연간 검토 없음)                            |
| 플랫폼 \| 프로세스                        | ⚡️ 재인증 중 식별된 불필요한 액세스는 제거되지 않습니다.                                  |
| 플랫폼 \| 프로세스                        | ⚡️ 특권 계정, cross-org 액세스, 외부 사용자의 경우 액세스 재인증이 엄격하지 않음     |
| 플랫폼 \| 조직                            | ⚡️ 부재 중인 계정(90일 이상 로그인하지 않음)이 검토 또는 비활성화 없이 누적됨                    |
