설계 단계의 개인정보 보호와 데이터 보존 정책

Privacy by Design (PbD)은 1990년대 Ann Cavoukian이 개발한 프레임워크로, Privacy를 사후에 고려하는 요소가 아니라 아키텍처의 기본 요구 사항으로 다룹니다. 시스템을 구축한 후 Privacy controls를 덧붙이는 대신, PbD는 첫 번째 design 결정부터 이를 통합합니다. GDPR Article 25는 PbD를 EU 대상 시스템의 법적 요구 사항으로 공식화했으며, design 단계와 기본 설정에 의한 data 보호를 요구합니다. 이는 기본 설정이 항상 이용 가능한 가장 강력한 Privacy 보호 옵션이어야 한다는 의미입니다.

Cavoukian의 7가지 원칙은 다음과 같습니다. 사후 대응이 아닌 사전 예방 — Privacy 사건이 발생하기 전에 예측하고 방지합니다. 기본값으로서의 Privacy — Privacy 보호를 위해 User가 별도로 행동할 필요가 없습니다. design에 내장된 Privacy — 별도의 계층으로 추가하지 않습니다. 완전한 기능성 — Privacy를 위해 Security나 기능성을 포기할 필요가 없습니다. 종단 간 Security — 수집부터 폐기까지 lifetime 전체를 보호합니다. 가시성과 투명성 — 독립적인 검증이 가능하도록 운영합니다. User Privacy 존중 — User 중심의 controls와 강력한 기본값을 사용합니다.

기본 설정에 의한 Privacy란 가장 강력한 Privacy 보호 설정이 처음부터 활성화되어 있다는 의미입니다. User가 data 수집을 거부하거나 공유를 제한하도록 요구하는 대신, 공유하려면 적극적으로 동의하도록 해야 합니다. 실제 예로는 소셜 미디어 프로필의 기본 설정을 공개가 아닌 비공개로 하는 것, 분석 도구의 기본 설정을 최소한의 data 수집으로 하는 것, 앱의 기본 설정을 위치 권한을 요청하지 않는 상태로 하는 것이 있습니다. PbD 원칙은 User의 인식에 의존하기보다 Privacy를 보호하는 선택을 자동으로 적용하도록 엔지니어에게 요구합니다.

Data 최소화는 PbD 원칙이자 GDPR의 법적 요구 사항으로, 명시된 목적에 반드시 필요한 개인 data만 수집하는 것을 의미합니다. 기능을 구축하기 전에 엔지니어는 다음을 질문해야 합니다. '정말 이 필드가 필요한가?' 일반적인 최소화 기법에는 원시 data 대신 파생 값 수집(생년월일 대신 연령대), pseudonymization 사용(직접 식별자를 토큰으로 대체), 개인 단위 분석이 필요하지 않은 경우 익명화 구현이 있습니다. 애초에 수집하지 않은 data는 침해될 수 없습니다.

Pseudonymization은 직접 식별 가능한 data를 인공 식별자(토큰)로 대체하면서 매핑 table을 유지하므로 키가 있으면 재식별이 가능합니다. GDPR은 pseudonymization을 Risk 감소 기법으로 인정하지만 pseudonymous data를 GDPR에서 면제하지는 NOT 않습니다. pseudonymous data도 여전히 개인 data입니다. 익명화는 개인을 식별할 수 있는 가능성을 되돌릴 수 없게 제거합니다. 진정한 익명 data는 GDPR 적용 범위에 포함되지 않지만, 실제 익명화는 기술적으로 어렵습니다. 익명이라고 주장된 많은 데이터 세트가 보조 data나 추론 공격을 통해 재식별될 수 있기 때문입니다.

Privacy Impact Assessment (PIA)는 GDPR에서 Data Protection Impact Assessment (DPIA)라고 하며, 새로운 시스템이나 프로세스를 시작하기 전에 Privacy Risk를 평가합니다. GDPR은 처리로 인해 높은 Risk가 발생할 가능성이 있는 경우 DPIA를 의무화합니다. 예를 들어 민감한 data의 대규모 처리, 체계적인 프로파일링, 새로운 기술의 사용 등이 해당합니다. DPIA에는 처리 목적, 필요성 평가, Risk 식별, Risk 완화 조치를 문서화합니다. DPIA를 조기에 완료하면 시스템 구축 후 비용이 많이 드는 재설계를 방지할 수 있습니다.

data 보존 정책은 각 범주의 data를 안전하게 폐기하기 전까지 얼마나 오래 보관할지 지정합니다. 보존 결정에서는 두 가지 상충하는 압력의 균형을 맞춰야 합니다. 법적, 운영상, 감사 요구 사항을 충족할 만큼 오래 보관하는 동시에 불필요한 Risk가 될 정도로 오래 보관하지 않는 것입니다. GDPR의 저장 기간 제한 원칙은 data가 원래 목적에 더 이상 필요하지 않을 때 삭제하도록 요구합니다. 보존 일정은 문서화해야 하며 자동 삭제 작업과 archive 만료 설정을 통해 Technical 방식으로 시행해야 합니다.

보존 일정에는 법적 보존을 위한 예외 메커니즘이 있어야 합니다. 소송이 예상되거나 시작되면 조직은 일반적인 보존 일정과 관계없이 잠재적으로 관련된 모든 data를 보존할 의무가 있습니다. 법적 보존 중인 data를 삭제하면 증거 훼손에 해당할 수 있으며 법원의 불리한 판결이나 제재로 이어질 수 있습니다. 법적 보존 소프트웨어는 영향을 받는 data에 Technical 보존 플래그를 설정하여 법무 팀이 보존을 해제할 때까지 자동 삭제를 방지합니다. 법적 보존은 유지되는 동안 Track하고 문서화해야 합니다.

data가 보존 기간의 끝에 도달하면 복구가 불가능한 방식으로 폐기해야 합니다. 디지털 data에는 암호학적 삭제(Encryption 키를 폐기하여 암호문을 사용할 수 없게 함), 자기 소거(자기 매체에 사용), 안전한 덮어쓰기(NIST SP 800-88 Clear 또는 Purge), Physical 파괴(파쇄, 소각)가 있습니다. 조직은 특히 제3자 매체 폐기의 경우 준수 감사의 증거로 폐기 증명서를 발급해야 합니다. 클라우드 저장소에서는 일반적으로 암호학적 삭제가 유일하게 실행 가능한 방법입니다.

법적 근거로 동의에 의존하는 조직은 누가, 언제, 어떤 구체적인 처리에, 어떤 방식을 통해 동의했는지를 입증하는 동의 기록을 유지해야 합니다. 이러한 기록은 처리가 계속되는 동안과 분쟁 해결을 위해 그 이후에도 합리적인 기간 동안 보관해야 합니다. 동의 관리 플랫폼(CMP)은 쿠키 동의, 기본 설정 수집 및 동의 철회를 자동화합니다. 동의 변경에 대한 감사 추적은 필수적입니다. 사용자가 동의를 철회했는데도 해당 사용자의 데이터가 계속 처리된다면 조직은 GDPR에 따른 상당한 법적 책임을 질 수 있습니다.

실무에서 설계 단계의 개인정보 보호란 아키텍트가 설계 시점에 개인정보 보호와 관련된 질문을 제기하는 것을 의미합니다. 클라이언트 측 분석 비콘보다 서버 측 렌더링을 우선 사용하십시오. 카드 번호 원문을 저장하는 대신 토큰화를 사용하십시오. 민감한 필드에는 데이터베이스에서 열 수준 암호화를 적용하십시오. 각 조회에 필요한 최소한의 데이터만 사용하도록 강제하는 데이터 접근 계층을 설계하십시오. PII는 별도의 더욱 엄격하게 제한된 데이터베이스 스키마에 저장하십시오. 분석 출력에는 차분 프라이버시를 적용하십시오. 이러한 선택이 쌓이면 내부자조차 악용하기 어려운 진정한 의미의 안전한 시스템이 구축됩니다.

이번 lesson에서 다룬 CompTIA Security+ (SY0-701) 개념에 대한 이해도를 확인해 보십시오.

이번 lesson에서는 다음을 배웠습니다. 설계 단계의 개인정보 보호는 기본 설정으로서의 개인정보 보호를 포함한 일곱 가지 기본 원칙을 바탕으로 처음부터 시스템에 개인정보 보호를 적용합니다. 데이터 최소화 및 가명화는 분석을 가능하게 유지하면서 공격자에게 데이터가 갖는 가치를 낮춥니다. 또한 데이터 보존 정책은 보존 기간이 끝났을 때 안전하게 폐기하여 불필요한 데이터 저장 위험과 법적 의무 사이의 균형을 맞춥니다. 다음에서는 안티바이러스, EDR 및 XDR 플랫폼을 포함한 엔드포인트 보안을 살펴보겠습니다.