개인정보보호와 보안관리

1. 개인정보와 처리 원칙

개인정보는 살아 있는 개인을 식별하거나 다른 정보와 쉽게 결합해 식별할 수 있는 정보이다. 민감정보·고유식별정보 등은 더 높은 보호가 필요할 수 있다.

일반적인 보호 원칙:

• 목적을 명확히 하고 필요한 범위에서 수집
• 적법한 처리 근거 확보
• 정확성·최신성 유지
• 보유기간이 끝나거나 목적 달성 시 파기
• 안전성 확보조치
• 정보주체의 권리 보장
• 처리 과정과 책임을 설명할 수 있음

목적 설정 → 최소 수집 → 이용·제공 통제
    → 정확성·보안 유지 → 보유기간 관리 → 안전한 파기

2. 개인정보 생명주기

수집
 ↓
저장
 ↓
이용·분석
 ↓
제공·위탁·이전
 ↓
보관
 ↓
파기

단계별 통제 예시:

개발·시험 환경에 운영 개인정보를 복사하면 노출 위험이 커지므로 비식별 데이터나 생성 데이터를 우선 사용한다.

3. 최소수집과 목적 제한

“나중에 사용할 수 있으므로”라는 이유만으로 과도하게 수집하면 위험과 관리비용이 증가한다.

업무 목적
   ↓
꼭 필요한 데이터 항목 도출
   ↓
선택 항목과 필수 항목 분리
   ↓
보유기간·접근자·제공처 설정

목적이 바뀌면 기존 처리 근거와 고지·동의 범위를 다시 검토해야 한다.

4. 가명처리와 익명처리

원본 식별자
    │
    ├─ 치환키·추가정보를 별도 보관
    ▼
가명 데이터
    │  결합·재식별 위험 평가
    ▼
분석·통계 활용

가명정보도 재식별 위험과 접근통제가 필요하다. 단순히 이름을 지웠다고 자동으로 익명정보가 되는 것은 아니다.

5. 개인정보 접근통제

• 업무 역할에 따른 최소권한
• 조회·다운로드·변경 권한 분리
• 대량조회·대량다운로드 탐지
• 관리자·DBA 특권 통제
• 화면 마스킹과 출력 제한
• 접속기록·처리기록 보관과 검토
• 휴면·퇴직 계정 회수
• 중요 작업 MFA·재인증

사용자 → 업무 역할 → 조회 범위 → 화면 마스킹
                       │
                       └─ 다운로드·반출은 별도 승인

6. 암호화와 키 분리

전송 구간은 TLS 같은 안전한 채널을 사용하고, 저장 데이터는 중요도와 위협에 따라 암호화·토큰화·분리보관을 적용한다.

데이터 저장소 ─ 암호문
키 관리시스템 ─ 암호키
접근권한·감사 ─ 서로 분리

키를 같은 소스코드·설정파일·DB에 함께 보관하면 암호화 효과가 약해진다.

7. 위탁·제3자·외부 서비스 관리

개인정보 처리를 외부 업체나 클라우드 서비스에 맡겨도 책임과 통제가 사라지는 것은 아니다.

검토 항목:

• 처리 목적과 범위
• 재위탁 여부
• 접근권한과 관리자 통제
• 암호화·로그·백업·파기
• 사고 통지와 대응 책임
• 계약 종료 후 반환·파기
• 정기 점검과 증적

8. 보안관리 체계

보안관리 체계는 일회성 제품 도입이 아니라 위험 기반의 지속적 개선 과정이다.

범위·정책·책임 설정
      ↓
자산·위험 분석
      ↓
통제 선정·구현
      ↓
교육·운영·모니터링
      ↓
점검·감사
      ↓
경영 검토·개선
      └────────► 반복

제공 자료의 ISMS 생명주기와 같은 관리과정은 정책·조직, 위험관리, 대책 구현, 사후관리의 연결로 이해한다. 인증제도 세부 기준은 최신 공식 기준을 별도로 확인한다.

9. 위험 대응

위험을 전가해도 법적·관리 책임이 모두 사라지는 것은 아니다. 잔여위험의 승인 주체와 근거를 기록해야 한다.

10. 개인정보·보안사고 대응

탐지·신고
   ↓
초동 분류·영향 평가
   ↓
확산 차단·증거 보존
   ↓
원인 제거·안전한 복구
   ↓
관련 조직·이해관계자 통지 판단
   ↓
사후 분석·재발 방지

대응 시 주의:

• 증거를 훼손하지 않도록 시간·로그·이미지 보존
• 공격자 계정·토큰·키 폐기
• 취약점만 수정하고 침해 범위를 놓치지 않음
• 복구 전 안전성 검증
• 법적 신고·통지 요건은 최신 기준 확인
• 개인에게 미치는 영향 완화

11. 개인정보 흐름을 먼저 그리기

수집 → 전송 → 저장 → 이용·결합 → 제공·위탁 → 보관 → 파기
  │       │       │         │          │        │
최소화  TLS   암호화·키   목적 제한   계약·점검  보존기준

데이터 항목, 처리 목적, 법적 근거, 보관기간, 저장 위치, 수신자, 책임자를 데이터 맵에 연결해야 누락된 복제본과 shadow data를 찾을 수 있다.

12. 가명처리·익명화의 위험 판정

가명정보는 추가 정보와 결합해 재식별될 가능성이 있으므로 개인정보 보호조치와 분리 보관이 필요하다. 익명화는 합리적으로 개인을 알아볼 수 없는 상태를 목표로 하지만, 외부 데이터와의 결합 위험을 평가해야 한다.

• k-anonymity: 준식별자 조합이 최소 k명과 구별되지 않음
• l-diversity: 각 그룹의 민감값 다양성을 보완
• 차등 개인정보보호: 질의 결과에 통제된 무작위성을 넣어 개인 포함 여부 추론을 제한

k=5만 충족해도 그룹의 질병값이 모두 같으면 속성 노출 위험이 남을 수 있다.

13. Privacy by Design과 영향평가

설계 시작
 → 목적·필요성 확인
 → 최소 수집·기본 비공개 설정
 → 위협·재식별·오남용 시나리오
 → 기술·관리·물리 통제
 → 잔여위험 승인·추적

고위험 처리에는 개인정보 영향평가 또는 이에 준하는 사전 검토를 적용한다. 운영 단계에서는 접근기록, 다운로드 사유, 대량조회 경보, 파기 증적, 위탁사 재평가를 측정한다.

14. 사고 대응과 법적 기준

탐지 → 사실확인·범위분석 → 추가 유출 차단 → 증거 보존
 → 내부 보고·법률 검토 → 필요한 통지·신고 → 복구 → 재발방지

구체적인 신고 대상·기한은 법령과 감독기관 지침이 바뀔 수 있으므로 최신 공식 기준을 확인한다. 모든 사고를 동일 기한에 같은 기관에 신고한다고 단정해서는 안 된다.

15. 지표 예시

• 보존기간이 지난 데이터 파기율
• 과도권한 개선율과 휴면 계정 회수율
• 개인정보 조회·다운로드 이상행위 탐지율
• 가명정보 추가정보 분리 준수율
• 위탁사 점검·개선조치 완료율

확인 문제

1. 가명정보는 개인정보 보호조치 대상에서 벗어나는가?
2. k=5인데 각 그룹의 민감값이 모두 같으면 어떤 위험이 남는가?
3. 개인정보 데이터 맵이 포함해야 할 핵심은?
4. 사고 대응에서 로그 원본을 즉시 삭제하면 안 되는 이유는?
5. 신고 기한을 이론에 영구 고정하면 위험한 이유는?