--- schema_version: "1" id: 9c1c3c3d9143f1b2e46a0c1f2f57a7f485a763e219a4c0eb93b782de2b625bf1 title: 데이터 보호 패턴 collection: architect version: current locale: ko-kr portal_url: https://docs.salesforce.com/architect/current/ko-kr/well-architected/guides/trust-data-protection-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/ko-kr/well-architected/guide/trust-data-protection-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: a37dc475cb281208dafa09958428468244f53da2fc24be29dc1c1d5c72b77221 products: - 잘 설계된 프레임워크 - Architect Site Content Repo --- # 데이터 보호 패턴
Well-Architected [Trust](/docs/architect/ko-kr/well-architected/guide/trust.html)에 대해 자세히 알아보기 → [데이터 보호 및 개인정보보호](/docs/architect/ko-kr/well-architected/guide/trust.html#data-protection-and-privacy) ## 데이터 분류 **패턴** | 찾을 위치 | 유사성 | | --- | --- | | 데이터 분류 스키마 | ✅ 수준(공개, 내부, 기밀, 제한)으로 문서화된 분류 스키마
✅ 각 분류 수준에 제공된 비즈니스 예
✅ 규제 의무에 부합하는 분류 스키마(HIPAA, PCI DSS, GDPR)
✅ 설계 도중 분류를 일관적으로 적용하도록 교육받은 데이터 모델러
✅ 소급이 아닌 데이터 모델링 프로세스의 일부로 분류된 새 필드 | | 필드 수준 분류 | ✅ 개체 수준이 아닌 필드 수준에서 적용되는 분류
✅ 단일 개체 내의 필드에 다른 분류가 있을 수 있습니다.
✅ 분류 차이를 반영하는 필드 수준 보안
✅ 분류되지 않은 데이터는 기본적으로 가장 높은 적절한 보호 수준으로 설정됩니다.
✅ 분류 드라이브 보호 제어(암호화, 액세스, 보존) | | 사용자 정의 개체 및 필드 | ✅ 모든 사용자 정의 개체에 문서화된 데이터 분류가 있습니다.
✅ 기밀 또는 제한으로 분류된 민감한 필드(임금, SSN, PHI, 결제 데이터)
✅ 공개 필드(회사 이름, 웹 사이트) 문서화
✅ 필드 설명에 수집된 분류 메타데이터
✅ 코드 검토 및 ARB 동안 검토된 분류 | | 표준 개체 | ✅ 분류 스키마에 대해 평가된 표준 개체 필드
✅ 제한된 표준 필드에 대해 Shield Platform Encryption 활성화
✅ 기밀 표준 필드에 적용되는 필드 수준 보안
✅ 민감한 표준 필드가 노출되지 않도록 필터링된 보고서 및 목록 보기 | | 통합 데이터 | ✅ 구현 전에 분류된 통합을 통한 데이터 플로
✅ 외부 시스템 데이터 민감도 평가 및 문서화
✅ 제한된 데이터 사용 인증서 기반 인증을 처리하는 통합 끝점
✅ 시스템 경계 전체에서 데이터 분류 유지 | | 규정 준수 매핑 | ✅ 식별 및 제한으로 표시된 HIPAA PHI 필드
✅ 가능한 경우 Salesforce에서 피할 수 있는 PCI 카드 소지자 데이터 - 범위를 줄이기 위해 결제 게이트웨이를 통해 토큰화되며, 저장해야 하는 경우 PCI DSS 제어 아래에 암호화된 사용자 정의 필드를 사용합니다.
✅ GDPR 개인 데이터 식별 및 개인 정보 보호 제어 적용
✅ SOX 금융 데이터 분류 및 직무 분리 적용 | **안티 패턴** | 찾을 위치 | 불만 사항 | | --- | --- | | 균일한 보호 | ⚡️ 민감도에 상관없이 모든 필드에 동일한 보호 기능 적용
⚡️ 값이 낮은 데이터가 과도하게 보호되고(자원 낭비) 중요한 데이터가 보호되지 않음
PHI 또는 결제 카드 데이터와 동일하게 처리되는 공용 회사 정보
⚡️ 분류 근거 없이 "보안을 위해" 암호화된 모든 필드 | | 소급 분류 | ⚡️ 프로덕션에 배포 후 분류된 데이터
⚡️ 설계 검토가 아닌 규정 준수 감사를 통해 검색된 중요한 데이터
⚡️ 보안 사고 후에만 분류되는 데이터
⚡️ 개발 중 기본값은 "나중에 분류를 확인하겠습니다"입니다. | | 개체 수준만 분류 | ⚡️ 필드에 민감도가 다른 경우 전체 개체가 일관되게 분류됩니다.
⚡️ 민감한 필드에 대한 필드 수준 보안 없이 개체 수준 액세스 권한 부여
⚡️ 동일한 분류로 간주되는 계정 또는 연락처 개체의 모든 필드
⚡️ 혼합 민감도 개체에 대한 유일한 액세스 제어로 사용되는 개체 권한 | | 부족 Knowledge | ⚡️ 분류 문서화되지 않음, 주요 사람의 Knowledge 존재
⚡️ 개발자가 민감한 필드를 "단순히 알아야 함"에 의존
⚡️ 모든 데이터 모델러가 액세스할 수 있는 작성된 분류 스키마가 없음
⚡️ 분류 교육 없이 새 팀 구성원이 온보딩됨 | ## 암호화 **패턴** | 찾을 위치 | 유사성 | | --- | --- | | 암호화 상태 유지 | ✅ Hyperforce 통해 인프라 수준에서 암호화된 모든 데이터
✅ 제한된 데이터에 대해 Shield Platform Encryption 활성화
✅ 쿼리 및 고유성 요구 사항을 기반으로 선택된 암호화 스키마(확률적, 결정적, 대/소문자를 구분하는 결정적)
✅ 데이터 모델 설계 시 평가된 암호화 제약 | | Shield Platform Encryption 전략 | ✅ 대부분의 제한된 필드에 사용되는 확률적 암호화(모든 쿼리 작업 지원)
✅ WHERE 절 또는 고유성이 정확히 일치해야 하는 필드에 사용되는 결정적 암호화
✅ 비즈니스 논리에 대해 사례 구분이 중요한 경우 사용되는 대/소문자를 구별하는 결정론
✅ 프로덕션 배포 전에 테스트된 암호화된 필드 동작
✅ 수식 필드는 적절하게 처리된 암호화된 필드를 참조합니다(필요한 경우 Apex 이동). | | 키 관리 | ✅ 문서화 및 자동화된 키 순환 절차
✅ 재해 복구 연습 중 테스트된 주요 폐기 시나리오
✅ 명시적 키 제어가 필요한 규정 준수에 대해 고객 관리 키(BYOK) 평가
✅ 문서화된 주요 취소 절차
✅ 규정 준수 요구 사항에 따라 관리되는 암호화 키 수명 주기 | | 운송 중 암호화 | ✅ 모든 통합에 TLS 1.2 이상 필요
✅ 제한된 데이터를 처리하는 통합을 위한 인증서 기반 상호 인증
✅ 프로토콜 다운그레이드를 방지하기 위해 Experience Cloud 사이트에 구성된 HSTS 머리글
✅ TLS 인증서 만료 모니터링 및 자동 갱신 구성
✅ 약한 암호 및 비활성화된 프로토콜 | | 코드 및 구성 | ✅ 코드, 구성 파일 또는 버전 관리에 포함되지 않은 자격 증명
✅ 인증을 중앙에서 관리하는 데 사용되는 명명된 자격 증명 및 외부 자격 증명
✅ 아키텍처에 내장된 자격 증명 순환 기능
✅ 코드 변경 없이 업데이트를 활성화하는 코드에서 명명된 자격 증명 추상 인증 | | AppExchange 패키지 | ✅ 설치 전에 평가된 패키지 보안 요구 사항
✅ 비즈니스가 정당한 경우에만 패키지에 액세스할 수 있는 암호화된 필드
✅ 이벤트 모니터링을 통해 모니터링되는 패키지 데이터 액세스 패턴
✅ 고급 검토를 받는 제한된 데이터에 액세스해야 하는 패키지 | **안티 패턴** | 찾을 위치 | 불만 사항 | | --- | --- | | 평가가 없는 암호화 | ⚡️ 테스트 없이 모든 필드에 확률적 암호화 활성화
⚡️ 암호화된 필드를 집계할 수 없으므로 프로덕션에서 실패한 중요 보고서
⚡️ 이해에 영향을 미치지 않는 수식 필드 소스에 암호화가 활성화됨
결정적 암호화로 전환하지 않고 암호화된 SOQL LIKE 쿼리에 사용되는 필드 | | 내장형 자격 증명 | ⚡️ 코드, 사용자 정의 설정 또는 버전 관리에 포함된 자격 증명
Apex 클래스에서 하드 코딩된 API 키, 암호 및 인증서
⚡️ 소스 제어 리포지토리에 커밋된 자격 증명
⚡️ 암호화 없이 사용자 정의 메타데이터 또는 사용자 정의 설정에 저장된 자격 증명 | | 약한 프로토콜 또는 레거시 프로토콜 | ⚡️ TLS 1.0 또는 1.1 지원(사용되지 않음 및 취약성)
JWT 전달자를 사용할 수 있는 경우 허용되는 사용자 이름-암호 OAuth 플로
⚡️ 자체 서명 인증서가 프로덕션 통합에 허용됨
⚡️ 인증서 유효성 검사가 비활성화되어 "통합 작동" | | 키 관리 없음 | ⚡️ 키 순환 절차 없이 Shield Platform Encryption 활성화
⚡️ 문서화된 키 폐기 시나리오 없음
⚡️ 규정 준수에 대해 고객 관리 키를 평가하지 않고 사용되는 기본 키
⚡️ 테스트되지 않은 키 순환 및 취소 절차 | | 과암호화 | ⚡️ 공개 또는 내부 분류 데이터 암호화 - 혜택 없이 비용 추가
⚡️ 모든 필드에 Shield Platform Encryption 활성화되어 불필요한 복잡성 발생
⚡️ 규정 준수에 필요하지 않은 경우 사용되는 BYOK(작업 오버헤드 추가)
⚡️ 데이터 분류로 인해 암호화가 필요하지 않음 | ## 데이터 마스킹 **패턴** | 찾을 위치 | 유사성 | | --- | --- | | Sandbox 전략 | ✅ 제한된 데이터는 개발 또는 테스트 환경에 들어가지 않습니다.
✅ 부분 Sandbox 복사에는 제한된 개체 및 필드가 제외됩니다.
✅ Sandbox 템플릿은 환경 유형별로 포함할 개체 및 필드를 정의합니다.
✅ 프로덕션과 유사한 데이터가 필요한 Sandbox에 맞게 구성된 Data Mask | | Data Mask 규칙 | ✅ Data Mask 규칙은 데이터 특성을 유지하면서 민감한 필드를 난독화합니다.
✅ 패턴은 참조 무결성을 유지합니다(동일한 입력은 동일한 마스킹된 출력을 생성함).
✅ 이메일 주소가 마스킹되었지만 테스트를 위해 유효한 형식으로 유지됨
✅ 전화번호가 마스킹되지만 유효한 형식 유지
✅ 날짜가 변경되어 상대 관계 유지
✅ 실질적인 범위 내에서 무작위화된 숫자 필드 | | 합성 데이터 | ✅ 개발 환경에서 합성 데이터 생성을 사용합니다.
✅ 합성 데이터에는 효과적인 테스트를 지원하는 현실적인 특성이 있습니다.
✅ 개발에 프로덕션 데이터가 필요하지 않음
✅ 개발 파이프라인에서 자동화된 데이터 생성 테스트 | | 비프로덕션 환경 | ✅ 프로덕션 데이터가 개인 개발자 조직에 복사되지 않음
✅ 화면 캡처 및 데모 - 마스킹 또는 합성 데이터 사용
✅ 교육 환경에서 합성 데이터 또는 밀도로 마스킹된 프로덕션 데이터를 사용합니다.
✅ 비프로덕션 데이터에 대한 계약자 및 공급업체 액세스가 비업무용 분류로 제한됨 | **안티 패턴** | 찾을 위치 | 불만 사항 | | --- | --- | | Sandbox의 프로덕션 데이터 | ⚡️ 개발을 위해 마스킹되지 않은 프로덕션 데이터로 전체 Sandbox 새로 고침
⚡️ 편의를 위해 개발자 Sandbox에 복사된 제한된 데이터
⚡️ 개발자에게 프로덕션 데이터 Sandbox에 광범위한 액세스 권한 부여
⚡️ Sandbox가 중요한 데이터로 새로 고쳐졌습니다. "실제 데이터로 테스트가 더 쉬워짐" | | 합성 데이터 없음 | ⚡️ 모든 테스트에 대해서만 사용되는 프로덕션 데이터
⚡️ 개발 환경에 대한 합성 데이터 생성 안 함
⚡️ 합성 대안을 평가하지 않고 "실제 데이터가 필요함"으로 간주됨
⚡️ 생성을 자동화할 수 있는 경우 생성되는 수동 테스트 데이터 | ## 설계를 통한 개인 정보 보호 **패턴** | 찾을 위치 | 유사성 | | --- | --- | | 데이터 최소화 | ✅ 명시된 비즈니스 목적에 필요한 데이터만 수집
✅ "이 데이터에 필요한 아키텍처 결정은 무엇입니까?"와 관련된 모든 필드 추가
✅ 더 이상 제공되지 않는 데이터 수집 목적이 제거됨
✅ 명확하게 표시되고 비즈니스 근거 없이 필요하지 않은 옵션 필드
✅ "모두 영구적으로 유지"가 아닌 법적 근거에 맞춰 내역 데이터 보존 | | 목적 제한 | ✅ 권한 집합은 직무 목적에 따라 데이터 액세스를 제한합니다.
✅ 마케팅 사용자는 문서화된 근거 없이 지원 사례 세부 사항에 액세스할 수 없음
✅ 세일즈 사용자는 작업이 필요하지 않으면 고객 서비스 내역에 액세스할 수 없습니다.
✅ 교차 기능 데이터 액세스에는 명시적 승인 및 모니터링이 필요합니다.
✅ 권한 집합 설명에 명시된 데이터 액세스 목적 | | 동의 관리 | ✅ 마케팅, 분석, 옵션 처리를 위해 개인 수준에서 수집된 동의
✅ 동의는 세분화(목표별), 이진 덮개 동의 아님
✅ 통합 시스템 전반에 동의 철회 워크플로 전파
✅ 타임스탬프, 버전 및 메커니즘으로 추적된 동의 결정
✅ 동의 UI는 사용자가 동의하는 내용을 명확하게 설명합니다. | | 데이터 주체 권리 | ✅ 액세스 요청 워크플로는 배포에 대한 규정 집합의 기한 내에 데이터 사본을 제공합니다.
✅ 감사 내역을 사용하여 오류를 수정하는 수정 워크플로
✅ 삭제 워크플로는 법적으로 허용되는 경우 데이터를 삭제합니다(보존 의무 고려).
✅ 이식성 워크플로는 기계에서 읽을 수 있는 형식으로 데이터를 내보냅니다.
✅ 일정 시간 확인을 위해 정기적으로 테스트되는 데이터 주체 권한 워크플로
✅ 워크플로 자동화를 통해 규제 타임라인이 일관되게 충족됨 | | 개인정보 보호 제어 | ✅ 정책을 통해서만 아닌 기술적으로 적용되는 개인 정보 보호 제어
✅ 공유 규칙이 목적 제한을 구현함
✅ 민감한 특성을 보호하는 필드 수준 보안
✅ 감사 내역 - 개인 정보 관련 이벤트 수집
✅ CI/CD 파이프라인에서 확인된 개인정보 보호 제어 | **안티 패턴** | 찾을 위치 | 불만 사항 | | --- | --- | | 모든 항목 수집 | ⚡️ "모든 가능한 데이터를 수집합니다. 언젠가는 필요할 수 있음" 접근 방식
문서화된 비즈니스 목적이 없는 추가된 필드
⚡️ 데이터 보존 사유 없이 무기한으로 보관
필수로 설정하여 수집되는 옵션 데이터 | | 블레킷 동의 | ⚡️ 모든 목적에 대한 단일 "조건에 동의" 동의
⚡️ 단일 확인란에서 서비스 전달과 결합된 마케팅 동의
목적을 구분할 수 있는 경우 모두 또는 없음 동의
20페이지의 사용 약관에 포함된 동의 | | 적용되지 않는 정책 | ⚡️ 개인정보 보호정책은 기술적으로 적용되지 않는 이상적인 관행을 설명합니다.
⚡️ 부적절한 데이터 액세스를 방지하기 위한 사용자 교육
기술적 제어를 구현하지 않고 문서화된 개인정보 보호정책
⚡️ 모니터링 및 확인 없이 정책 준수 가정 | | 수동 데이터 주체 요청 | ⚡️ 수개월 동안 수동 IT 티켓을 통해 처리된 GDPR/CCPA 요청
⚡️ 액세스, 정정, 삭제, 이동성에 대한 문서화된 절차 없음
⚡️ 배포에 대한 규정 집합의 요청 완성 창이 누락되었습니다.
⚡️ 감사 동안 발견된 워크플로가 존재하지 않도록 요청 | | 과도한 데이터 공유 | ⚡️ 목적 사유 없이 부서 전체에서 광범위한 데이터 액세스 권한 부여
⚡️ 마케팅에서 지원 사례 세부 사항에 대한 액세스 허용
⚡️ 세일즈가 문서화 없이 고객 서비스 내역에 액세스할 수 있음
⚡️ 개인 데이터가 포함된 개체에 사용되는 공용 읽기/쓰기 OWD | ## 데이터 보존 **패턴** | 찾을 위치 | 유사성 | | --- | --- | | Hyperforce 지역 배포 | ✅ Hyperforce 지역에서 데이터 보존 요구 사항을 충족하는 조직 프로비저닝
✅ 필수 지리적 경계 내에 데이터 저장 및 처리 발생
✅ 프로비저닝하기 전에 문서화 및 확인된 지역 요구 사항
✅ 필요한 경우 다중 조직 아키텍처를 통해 해결되는 다중 지역 요구 사항 | | 데이터 플로 매핑 | ✅ 데이터가 출처, 전송, 상주하는 문서의 데이터 플로 매핑
✅ 규정 대비 식별 및 평가된 국경 간 데이터 전송
✅ 국제 전송을 위한 표준 계약 조항 또는 바인딩 기업 규칙
✅ 저장소 위치뿐만 아니라 레지던스 준수에 대해 평가된 데이터 전송 경로 | | 데이터 보존 범위 | ✅ 데이터 저장 위치(Hyperforce 지역)
✅ 데이터 처리 위치(계산 영역)
✅ 백업 저장소 위치
✅ 로그 및 감사 추적 저장소 위치
✅ 교차 국가 간 데이터 이동에 대해 평가된 통합 이동 경로 | | 다중 조직 아키텍처 | ✅ 단일 조직 내에서 규제 요구 사항을 충족할 수 없는 경우 사용되는 다중 조직 아키텍처
✅ 각 조직이 해당 데이터 영역에서 프로비저닝됨
✅ 통합 패턴은 데이터 보존 제약을 준수합니다.
✅ ADR에 명시된 운영 복잡성 제약 | | 규정 준수 확인 | ✅ 관할에 따라 문서화된 데이터 보존 요구 사항
✅ 프로비저닝 전에 요구 사항에 따라 확인된 Hyperforce 지역 선택
✅ 정기 감사는 데이터가 필수 범위 내에 남아 있는지 확인합니다.
✅ 주거 규정 변경으로 아키텍처 검토 트리거 | **안티 패턴** | 찾을 위치 | 불만 사항 | | --- | --- | | 주거 관리 | ⚡️ 규정 준수 감사 동안 발견된 데이터 보존 위반
⚡️ 지역 요구 사항 평가 없이 프로비저닝된 조직
⚡️ 데이터 위치 규정을 고려하지 않고 "클라우드가 클라우드입니다"로 간주됨
⚡️ 주거 의무 검토 없이 추가된 관할 | | 거주지를 무시하는 교통 | ⚡️ 운송 경로를 무시하는 동안 저장소 위치만 고려
⚡️ 규정 준수 범위를 벗어난 지역을 통해 라우팅되는 데이터
비준수 지역에 사용되는 통합 미들웨어
⚡️ 기본 데이터가 아닌 다른 영역에 저장된 백업 | | 불필요한 다중 조직 | ⚡️ Hyperforce 영역이 있는 단일 조직이 충분한 경우 사용되는 멀티 조직 아키텍처
⚡️ 규제 없이 운영 복잡성, 라이센스 비용, 통합 오버헤드에 곱한 값
⚡️ 특정 규정 준수 요구 사항 없이 "안전하도록" 구현된 멀티 조직
⚡️ 데이터 분류 및 액세스 제어가 충분한 경우 기본적으로 사용되는 다중 조직 |