위치:
아카이브 Apex - 잊혀질 권리 (RTBF)
데이터 프라이버시 규정은 개인에게 잊혀질 권리(RTBF)를 부여하며, 조직은 요청 시 개인 데이터를 안전하게 지우도록 요구합니다. 아카이브 Apex 아카이브 앱에서 특정 데이터를 식별 및 삭제하여 규정을 준수하므로 다른 보관된 데이터의 무결성을 유지하면서 철저한 제거를 보장합니다.
RTBF 필터 기준
RTBF 요청을 처리하려면 적절한 필터 기준을 지정합니다. 예:
| 기준 | 예 |
|---|---|
| 필드 이름 | 직원 ID |
| 개체 | 연락처 |
| 값 | ID 123456789011121314 |
중요 고려 사항
- 제출은 하루에 10,000개의 요청으로 제한되며 루트 레코드 검색은 10,000개로 제한됩니다.
- RTBF 삭제 프로세스는 계층 내에서 직접 및 간접적으로 관련된 하위 레코드로 확장됩니다.
- 검색 결과가 중복되면 일부 레코드가 감사 파일에서 이미 삭제됨으로 표시될 수 있습니다.
- 검색 결과 제한에 도달하면 Apex 활동 상태에 이 오류와 함께
200상태 코드가 표시됩니다.Request processed. Maximum search results reached. Refine your search or submit a new request. - 대부분의 표준 RTBF 요청은 30분 이내에 완료됩니다.
- 최적의 결과를 얻으려면 루트 개체를 대상으로 합니다.
- 개체 및 필드 이름 필터는 대/소문자를 구분하지 않습니다.
- 보관은 부분 삭제를 지원하지 않습니다.
보관된 계층에서 하위 레코드의 RTBF 동작
하위 레코드에서 RTBF 요청을 실행하면 해당 요청으로 인해 보관된 전체 계층이 제거됩니다.
예를 들어, 특정 사례 레코드를 검색하고 RTBF 보관 요청을 제출하는 경우 요청이 사례, 관련 과업 및 관련 계정 루트 레코드를 제거합니다. 이러한 레코드가 함께 보관되었으므로 RTBF는 전체 보관된 계층을 삭제합니다.
그러나 계정이 별도로 보관된 경우 사례 레코드에서 RTBF를 실행하면 계정 레코드가 아닌 사례 및 과업만 제거됩니다.
RTBF 작동 방식
RTBF 프로세스는 비동기 프로세스로 실행되며 다음 순차 API 호출을 따릅니다.
- 데이터 식별 - Apex 쿼리 아카이브를 통해 지정된 필터 기준과 일치하는 모든 레코드를 찾습니다.
- 데이터 삭제 - Apex 아카이브에 삭제 요청을 보내 일치하는 모든 레코드를 제거합니다.
프로세스가 완료되면 RTBF 활동 아이콘이 아카이브 콘솔의 활동 탭 아래에 나타납니다.
RTBF 요청 예제
Maria Johnson의 이전 직원이 시스템에서 모든 개인 데이터를 삭제하기 위한 RTBF 요청을 제출합니다. 회사에서 이메일 서신, 고객 상호 작용, 프로젝트 할당과 함께 직원 레코드를 보관합니다. RTBF 요청을 팔로우하려면 이 필터 기준을 사용합니다.
| 개체 | 필드 이름 | 값 |
|---|---|---|
| Contact | 이메일 | Maria@own.com |
| 사례 | 직원 ID | 987654321 |
| 과업 | Assigned To | 마리아 존슨 |
| 이메일 | 발신자 | Maria@own.com |
| 문서 | 소유자 | 마리아 존슨 |
이 요청을 통해 Maria의 연락처 정보, 그녀가 참여한 사례, 그녀에게 할당된 과업, 그녀에게 연결된 모든 이메일 및 문서 레코드를 포함하여 Maria의 데이터가 완전히 제거됩니다. 이 프로세스를 통해 데이터 프라이버시 규정을 준수하면서 중요한 정보를 철저하고 정확하게 삭제할 수 있습니다.
API 메서드 및 응답 처리
RTBF 요청을 제출하기 전에 Apex 데이터 쿼리에서 쿼리를 실행하여 기준을 검증하는 것이 좋습니다.
| 입력 | 출력 | 정의 |
|---|---|---|
ArchiverAccessorResponse |
|
잊기 API 호출의 응답입니다. getRTBFStatus 메서드를 사용하여 요청 상태를 추적하는 requestId을 반환합니다. |
Criteria(문자열 sObjectName, 문자열 fieldName, 문자열 value) |
||
forgetArchivedRecords(list<Criteria>
inputFilters) |
ArchiverAccessorResponse |
보관 잊기 요청 및 삭제할 기준 목록을 만드는 공개 방법입니다. |
getRTBFStatus(string requestId) |
삭제된 정보의 모든 세부 사항이 포함된 CSV 보고서입니다. | RTBF 요청에 대한 팔로우업 기능을 제공하는 공개 방법입니다. |
- Apex 보관—RTBF 요청 실행
아카이브 Apex 수동으로 테스트하고 아카이브 앱에서 RTBF 요청을 실행합니다. - 아카이빙 Apex—RTBF 사용 사례 시나리오
Archive 앱에서 RTBF에 대한 사례 시나리오를 사용합니다. - 아카이빙 Apex - 아카이빙 앱에서 PII 익명화
레코드를 삭제하지 않고 보관된 레코드에서 개인 식별 정보(PII)를 익명화합니다. 익명화는 중요한 값을 되돌릴 수 없는 자리 표시자로 대체하여 아카이브 앱의 레코드 구조를 유지하면서 개인 정보 보호 규정을 준수할 수 있습니다.
Apex 보관—RTBF 요청 실행
아카이브 Apex 수동으로 테스트하고 아카이브 앱에서 RTBF 요청을 실행합니다.
- 설정 아이콘을 클릭합니다.
- Developer Console을 선택합니다.
-
콘솔을 열려면 Windows에서
F12또는Ctrl+Shift+I키를 누르거나 Mac에서Cmd+E키를 누릅니다. -
콘솔에서 이 코드를 실행하여 기준 목록을 만들고, RTBF 요청을 보내고, 아카이브에서
requestId을 가져옵니다.SF_Archive.Criteria criteria1 = new SF_Archive.Criteria('Account', 'Name', 'example name'); list<SF_Archive.Criteria> lst = new list<SF_Archive.Criteria>(); lst.add(criteria1); SF_Archive.ArchiverAccessorResponse response = SF_Archive.ArchiverAccessor.forgetArchivedRecords(lst); Map<String, String> values = (Map<String, String>)JSON.deserialize(response.getBody(), Map<String, String>.class); String requestId = values.get('request_id'); system.debug(requestId); -
실행을 클릭합니다.
요청이 시작됩니다. 완료되면
requestId이 실행 로그에 저장됩니다.
RTBF 요청 상태 보기
RTBF 요청을 보내면 요청 상태를 볼 수 있습니다.
- 페이지의 오른쪽 상단에서 설정 아이콘을 클릭합니다.
- Developer Console을 선택합니다.
-
Command + E누르십시오. -
RTBF 요청의
requestId을 사용하여 이 코드를 실행합니다.SF_Archive.ArchiverAccessorResponse reportResponse = SF_Archive.ArchiverAccessor.getRTBFStatus(requestId); system.debug(reportResponse.getBody()); -
실행을 클릭합니다.
상태 요청이 시작됩니다. 완료되면 다음 상태 중 하나가 실행 로그에 표시됩니다.
Request failed, please contact support.요청에 실패했으며,
Request handled, no matching results were found.:지정된 기준과 일치하는 레코드가 없습니다.
Request is open. Scan is still in progress.요청이 계속 진행 중입니다.
요청이 성공적으로 완료되면 삭제된 정보의 모든 세부 사항이 포함된 CSV 보고서를 받게 됩니다.
CSV 보고서에 다음 정보가 포함됩니다.
| 필드 | 상세 설명 |
|---|---|
| 기준 레코드 | 요청의 삭제 기준과 일치하는 레코드 필드입니다. |
| 기준 레코드 유형 | 요청의 기준입니다. |
| 삭제를 유발한 관련 Salesforce ID | 표에서 기준과 일치하는 다른 레코드에서 참조하는 행입니다. |
| Salesforce ID | 보고서 행에 포함된 레코드의 ID입니다. |
| 상태 | 레코드가 삭제되었는지 여부를 나타냅니다. |
RTBF 일반 오류
유효하지 않은 기준
- 필드는 개체와 일치해야 합니다.
- 개체가 동일한 기준은 둘 이상 허용되지 않습니다.
- 요청당 최대 10개의 기준을 보낼 수 있습니다.
결과 없음
- 값은 부분일 수 없습니다.
- 기준은 보관된 레코드 유형이어야 합니다.
예를 들어, ID가 X인 계정이 있고 해당 ID에 속하는 사례를 보관한 경우 해당 계정에 속하는 사례를 제외해야 합니다. 이를 위해 다음 필터 기준을 만듭니다.
Object type: Case, field: AccountId, value: XObject type: Account, field: Id, value: XArchive에 관련 계정이 없으므로 이 기준은 삭제되지 않습니다.아카이빙 Apex—RTBF 사용 사례 시나리오
Archive 앱에서 RTBF에 대한 사례 시나리오를 사용합니다.
시나리오 1: 다중 개체가 있는 RTBF
Jane Doe는 지난 2년 동안 계정을 보유한 XYZ 은행의 고객입니다. 최근에는 GDPR(일반 데이터 보호 규정)에 따라 RTBF를 사용하고 싶다고 결정했습니다. Jane은 은행에서 그녀에 대한 불필요한 개인 데이터를 보유하고 있으며 레코드에서 삭제하려고 합니다.
Jane은 XYZ 은행에 RTBF 요청을 제출하고 계정 정보, 트랜잭션 내역, 은행에서 보유한 기타 모든 개인 데이터를 포함할 수 있는 지우려는 개인 데이터를 지정합니다. 은행에서 Jane의 개인 데이터를 식별하고 찾습니다.
| 기준 | 필터 | 필터 | 필터 | 필터 |
|---|---|---|---|---|
| 개체 | 계정 | Transaction_c | 사례 | 이메일 |
| 필드 이름 | 이름 | 트랜잭션 사용자 | 고객 이름 | 보낸 사람 |
| 값 | Jane Doe | Jane Doe | Jane Doe | Jane Doe |
RTBF 요청에 최대 10개의 개별 개체를 포함할 수 있습니다.
결과:
보관에서 계정 1개, 트랜잭션 2,000개, 사례 15개를 루트로, 이메일 30개를 찾습니다.
시나리오 2: RTBF 단일 개체
제약 회사에서 관절염을 치료하기 위해 실험 의약품인 Eddy's Elixirs를 출시했습니다. 그러나 환자 간에 심각한 부작용이 발생했습니다. 의약품을 회수한 후 회사는 모든 공개 레코드 및 Eddy's Elixirs와 관련된 디지털 콘텐츠를 제거하기 위한 RTBF 요청을 제출했습니다.
| 기준 | 필터 |
|---|---|
| 개체 | 사례 |
| 필드 이름 | 의약품 이름 |
| 값 | 에디의 배율 |
결과:
보관에서 루트로 1,000개의 사례와 루트 아래에 하위 레코드로 보관된 1,000개의 환자 레코드를 찾습니다. 모두 제거됩니다.
RTBF 아이콘이 표시된 하나의 활동이 콘솔 활동 보관 탭에 생성됩니다.
시나리오 3: 검색된 루트 레코드 10,000개 초과 RTBF
ConnectWorld라는 인기 소셜 미디어 플랫폼의 정기 사용자인 Emily Jones가 계정을 비활성화하고 데이터 보호 규정에 따라 RTBF를 수행하도록 요청합니다.
| 개체 | 필터 | 필터 | 필터 |
|---|---|---|---|
| 개체 | 사용자 계정 | 연락처 | 사례 |
| 필드 이름 | 이름 | 전화 | 관련 ID |
| 값 | 에밀리 존스의 계정 ID | Emily의 전화 번호 | Emily Jones의 계정 ID |
결과:
보관은 루트 사례 레코드 20,000개, 연락처 300,000개, 사례 10,000개를 루트로 찾고 하위 레코드가 제거되면 루트 아래에 보관된 연락처 150,000개를 찾습니다.
RTBF 아이콘이 표시된 하나의 활동이 콘솔 활동 보관 탭에 생성됩니다.
"getRTBFStatus 요청 처리됨" 오류 메시지가 포함된 상태 코드 200을 반환합니다. 최대 검색 결과에 도달했습니다. 검색 범위를 좁히거나 새 요청을 제출하여 더 많은 레코드를 확인하십시오."
아카이브는 RTBF Apex 요청당 최대 10,000개의 루트 레코드를 처리할 수 있습니다. 이 오류를 해결하려면 쿼리를 다시 실행하여 나머지 레코드를 검색합니다.
아카이빙 Apex - 아카이빙 앱에서 PII 익명화
레코드를 삭제하지 않고 보관된 레코드에서 개인 식별 정보(PII)를 익명화합니다. 익명화는 중요한 값을 되돌릴 수 없는 자리 표시자로 대체하여 아카이브 앱의 레코드 구조를 유지하면서 개인 정보 보호 규정을 준수할 수 있습니다.
마스킹이라고도 하는 익명화를 사용하면 잊혀질 권리(RTBF)와 같은 개인정보보호 요청을 준수할 수 있습니다. 이 프로세스는 보관된 레코드에 대한 현장 업데이트를 수행합니다. 데이터를 영구적으로 삭제하는 제거 작업과 달리 익명화는 특정 민감한 값을 redacted@example.com과 같은 일반 텍스트로 대체합니다.
익명화 작동 방식
시스템은 개체 메타데이터를 사용하여 이름, 이메일, 전화, 주소와 같은 PII 필드를 감지합니다. 요청을 제출하면 원래 PII 값이 되돌릴 수 없는 자리 표시자로 마스킹됩니다. 레코드 ID 및 타임스탬프와 같은 비PII 데이터는 변경되지 않고 검색할 수 있습니다.
익명화는 포괄적입니다. 루트 레코드를 익명화하면 익명화 프로세스가 동일한 보관된 계층 내의 모든 관련 하위 레코드에 자동으로 계단식으로 적용됩니다. 예를 들어 연락처 레코드를 익명화하면 해당 레코드의 관련 과업 및 이벤트에서도 PII가 익명화됩니다.
중요 고려 사항
- 익명화 프로세스는 영구적입니다. 익명화 후에는 원래 PII 값을 복구하거나 볼 수 없습니다.
- 레코드는 한 번만 익명화할 수 있습니다. 익명화된 레코드에 대한 중복 요청을 제출하는 경우 시스템에서 무시합니다.
- 익명화는 일일 조직당 10,000개의 요청의 표준 보관 RTBF 속도 제한을 공유합니다.
- 익명화할 필드는 수동으로 선택할 수 없습니다. 시스템에서 Recover 알고리즘을 기반으로 PII 필드를 자동으로 식별합니다.
- 법적으로 보유한 레코드는 익명화할 수 없습니다. 현재 보류 또는 보존 잠금이 있는 레코드가 자동으로 제외됩니다.
다음 사항도 참조:
익명화 요청 제출
대상 기준을 정의하고 SF_Archive.ArchiverAccessor Apex 클래스를 사용하여 익명화 작업을 제출합니다.
다음의 요구 사항을 충족하는지 확인하십시오.
- Apex 코드를 실행하는 사용자에게는
SF_Archive네임스페이스에 액세스할 수 있는 권한이 있습니다. - Developer Console 또는 IDE에 액세스하여 익명 Apex 실행을 실행합니다.
- Developer Console 또는 원하는 Apex 실행 도구를 엽니다.
- 익명 실행 창을 엽니다.
-
기준을 정의하고 요청을 제출하려면 이 코드를 실행합니다. 이 코드 블록은 연락처 레코드의 이메일 주소 필드를 익명화합니다.
// 1. Define the criteria for the records to anonymize. // Syntax: new Criteria('ObjectAPIName', 'FieldAPIName', 'ValueToMatch'); List<SF_Archive.Criteria> criteriaList = new List<SF_Archive.Criteria>(); // Example: Anonymize a specific Contact by Email criteriaList.add(new SF_Archive.Criteria( 'Contact', 'Email', 'mickey.mouse@example.com' )); // 2. Submit the anonymization request. SF_Archive.ArchiverAccessorResponse response = SF_Archive.ArchiverAccessor.maskArchivedRecords(criteriaList); // 3. Process the response to get the request ID. Map<String, String> values = (Map<String, String>)JSON.deserialize(response.getBody(), Map<String, String>.class); String requestId = values.get('request_id'); // Output the request ID for tracking. System.debug('Anonymization Job Submitted. Request ID: ' + requestId);
익명화 상태 확인
제출하는 동안 생성된 요청 ID를 사용하여 익명화 작업의 상태를 확인하고 감사 보고서를 생성합니다.
익명화는 비동기 프로세스입니다. 요청을 제출한 후 반환된 요청 ID를 사용하여 진행 상황을 추적하고 결과를 확인합니다.
-
익명화 작업 상태를 확인하려면 익명 실행 창에서 이 코드를 실행합니다.
// Paste the Request ID found in the Debug Log from the anonymization request. // Example: String requestId = '0Qn5e000000abcD'; String requestId = 'YOUR_REQUEST_ID_HERE'; // Check the status. String statusResponse = SF_Archive.ArchiverAccessor.getMaskingStatus(requestId); System.debug('Anonymization Job Status: ' + statusResponse); -
익명화 작업이 완료된 후 감사 보고서를 생성하려면 익명 실행 창에서 이 코드를 실행합니다.
String requestId = 'YOUR_REQUEST_ID_HERE'; String report = SF_Archive.ArchiverAccessor.getMaskingReport(requestId); System.debug('Anonymization Audit Report: ' + report);
익명화 결과
익명화 프로세스가 완료된 후 PII 필드가 표시되는 방식을 검토합니다. 작업 상태가 HANDLED이면 시스템이 보관된 데이터를 즉시 업데이트합니다.
- 이메일 주소와 같은 원래 PII를 사용하는 검색은 결과를 반환하지 않습니다.
- 레코드 ID와 같은 민감하지 않은 식별자를 사용하는 검색은 익명화된 레코드를 반환합니다.
- 검색, 내보내기 또는 보관 취소를 통해 레코드를 볼 경우 PII 필드에 자리 표시자 값이 표시됩니다.
| 필드 | 원래 값 | 익명화된 값 |
|---|---|---|
| 이름 | 미키 마우스 | redacted_first_name |
| 이메일 | mickey.mouse@example.com | redacted@example.com |
| 전화 | +1-415-555-1234 | 000-000-0000 |
| ContactId | 003XX0000123AbC | 003XX0000123AbC |

