PIA Workflow 플랫폼 아키텍처 설계 및 연계 전략(ITSM/CI-CD/SIEM)

“개인정보 영향평가(PIA) 체계적 관리 시스템”을 전사 운영 관점(거버넌스 + 프로세스 + 시스템 + 보안통제 + 예시)까지 한 번에 돌아가도록 종합적인 설계를 위해 정리해본 내용입니다.
법적 근거: 개인정보보호법 제33조 등 (법률정보센터) / KISA 영향평가 수행안내서 공개 페이지 (KISA)

왜 “PIA 관리 시스템”이 필요하나

PIA의 본질(현업에서 놓치기 쉬운 포인트)

• PIA는 “문서 작성”이 아니라 서비스/시스템 변경이 개인정보 위험을 어떻게 바꾸는지를 증적으로 남기고, 보완조치가 실제 반영되었는지까지 추적하는 체계입니다.
• 개인정보보호법 제33조는 영향평가의 취지(위험요인 분석/개선사항 도출)와 고려요소(처리 규모, 제3자 제공, 권리침해 가능성 등)를 명시합니다.

문서/엑셀로 운영 시 흔한 실패 패턴

• “누가/언제/무엇을 승인”했는지 이력 부정확 → 감사·분쟁에 취약
• 개발/기획 변경이 잦은데 PIA 재평가 트리거가 없음 → “배포 후 뒤늦게 이슈”
• 위탁/국외이전/AI 활용 등 복잡도 증가 → 표준 체크리스트만으론 누락 발생

300x250

➡️ 결론: SDLC(기획→개발→배포)와 붙어있는 워크플로우 시스템이 필요합니다.

목표 아키텍처

권장 구조(업무 관점)

1. 대상 식별(Trigger): 신규/변경/연동/위탁/국외이전/AI 도입 이벤트 감지
2. 평가 수행(Workflow): 템플릿 기반 작성 + 자동 검증 + 위험도 산정
3. 보완조치(Controls): 조치항목 생성 → 담당 배정 → 완료 증적 첨부
4. 승인/배포 게이트: 미충족 시 배포 차단(또는 예외승인)
5. 사후 모니터링: 운영 중 변화/사고/점검 결과를 PIA에 연결

권장 구조(시스템 관점, 논리 컴포넌트)

• PIA 포털(Frontend): 신청/작성/검토/승인/리포트
• Workflow 엔진: 상태 전이, 결재 라우팅, SLA, 알림
• Risk/Control 엔진: 위험도 점수화 + 통제 매핑(암호화/접근통제/파기 등)
• 증적 저장소: 산출물(PDF), 설계서, 데이터흐름도(DFD), 로그, 스캔 결과
• 연계 허브(Integration): Jira/Confluence/Git, CMDB, IAM, DLP, SIEM, CI/CD

핵심 데이터 모델(“PIA를 시스템화”하는 최소 단위)

아래 개체(테이블/엔티티)를 잡으면 운영이 안정됩니다.

1. System(시스템/서비스)

• 서비스명, 소유부서, 운영환경(온프레/클라우드), 배포방식, 외부연동 목록

2. ProcessingActivity(처리활동)

• “회원가입”, “결제”, “배송”, “CS”, “추천/분석” 같은 업무 단위 처리

3. DataAsset(개인정보 항목)

• 항목명, 민감정보/고유식별정보 여부, 수집근거, 보유기간, 암호화 여부

4. DataFlow(데이터 흐름)

• 수집 → 저장 → 이용/제공 → 파기, 전송구간/저장소/처리자(내부/위탁)

5. Risk(위험 시나리오)

• 위험원인(과다수집, 접근통제 미흡, 위탁관리 부재, API 노출 등)
• 영향(금전피해, 계정탈취, 프라이버시 침해, 대규모 유출 등)

6. Control(보완조치/통제항목)

• 암호화, 마스킹, 접근제어, 로깅, 보관기간 자동파기, 위탁점검, 국외이전 보호조치…

7. Approval(결재/승인) & Evidence(증적)

• 승인자, 일시, 코멘트, 전자서명, 첨부파일 해시(SHA-256)

프로세스 설계(상태 머신) — “재평가/변경관리”가 핵심

권장 상태(예시)

• Draft(작성중)
• Submitted(제출)
• Reviewing(검토중: 개인정보/보안/법무)
• Remediation(보완조치 수행중)
• Approved(승인완료)
• Exception Approved(예외승인: 리스크 수용)
• Closed(종료/배포완료)
• Reassessment Required(재평가 필요)

재평가 트리거(중요)

아래 이벤트 발생 시 자동으로 Reassessment Required를 띄우는 걸 권장합니다.

• 개인정보 항목 추가/변경(예: 휴대폰번호 → 주민번호 추가)
• 보유기간 변경(예: 1년 → 5년)
• 제3자 제공/위탁 신규 발생
• 국외 이전 경로/사업자 변경
• 신규 로그 수집/분석(AI/프로파일링/자동결정 포함)
• 신규 외부 API 오픈/권한 정책 변경

법령 취지상 “권리침해 가능성/위험정도 변화”가 핵심이므로, 변경관리와 붙어야 합니다.

위험도 산정(점수화) 설계 + 예시

기본 점수 모델(현업 적용 쉬움)

• 위험도 = 영향도(15) × 발생가능성(15)
• 등급 예시
  • 1~5: 허용(기본통제 확인)
  • 6~12: 조건부 승인(보완 후 승인)
  • 13~25: 고위험(재설계/차단/예외승인만 허용)

실제 입력 예시(“배송 주소 + 전화번호 + 외부택배사 위탁”)

• 영향도: 4 (개인식별 + 3자 제공/위탁)
• 가능성: 3 (API 연동/권한오류 가능)
• 위험도: 12 → “조건부 승인”

자동 생성 보완조치 예

• 위탁 계약/보안조항 첨부
• 제공 API의 최소필드(주소/전화만) 강제
• 전송구간 TLS + IP allowlist
• 위탁사 접근로그 수신/점검 주기 등록

시스템 기능 설계(모듈별 상세)

1. 대상 식별(PIA Intake) — “자동화할수록 누락이 줄어듦”

• 신규 서비스 등록 폼
  • 개인정보 처리 여부(예/아니오)
  • 처리 항목 선택(사전 정의된 데이터 사전)
  • 처리규모(일/월 처리량)
  • 제공/위탁/국외이전/AI활용 체크
• 변경요청 연동(Jira/ITSM)
  • “개인정보 관련 변경 라벨”이 붙으면 PIA 티켓 자동 생성

2. 템플릿/체크리스트 엔진(표준화)

• KISA 수행안내서 구조를 내부 템플릿에 반영(필수 항목 누락 방지)
• 템플릿 버전 관리(중요): 법/내부정책 개정 시 “새 버전으로 재평가 추천” 자동화

3. 데이터흐름(DFD) 관리(현업 체감 큰 기능)

• UI에서 “수집→저장→처리→제공→파기”를 노드/엣지 형태로 입력
• 각 엣지(전송)에
  • 암호화(TLS), 인증(mTLS/OAuth), 네트워크 경계(WAF/VPN) 체크
• 각 저장소에
  • 암호화 at-rest(KMS), 접근통제(IAM), 보관기간, 파기 방식 설정

4. 보완조치(Controls) 생성/추적(“실행력”의 핵심)

• 위험항목을 등록하면 자동으로 조치 티켓 생성
• 티켓에
  • 담당(개발/인프라/보안/개인정보)
  • 기한(SLA)
  • 증적(설정 스크린샷, 정책 링크, 로그 샘플, 테스트 결과) 업로드
• 완료 시 검증 체크(보안팀/개인정보팀) 단계 통과해야 상태가 다음으로 이동

5. 승인/예외승인(리스크 수용) 체계

• 기본 승인 흐름: 서비스 오너 → 개인정보 담당 → 보안팀 → (필요 시) DPO/CISO
• 예외승인 흐름
  • “조치 불가 사유” + “대체통제” + “잔여리스크” + “만료일(재검토 날짜)” 필수

내부 사용자 점검포인트

1. 접근통제(RBAC/ABAC)

• RBAC 기본
  • 작성자(서비스팀) / 검토자(보안·개인정보·법무) / 승인자 / 감사자(읽기전용)
• ABAC 권장
  • “소유부서/프로젝트” 기반으로 열람 범위 제한
• PIA 결과물 자체가 민감정보가 될 수 있음(설계도/내부구조/취약지점 포함) → 열람 제한 필수

2. 무결성/증적성(감사 대비)

• 모든 변경에 감사로그(누가/언제/무엇을/어떤 값으로)
• 첨부파일은 업로드 시 SHA-256 해시 저장
• 가능하면 WORM(Object Lock) 등 불변 저장소 적용

3. 데이터 보호(암호화)

• DB 암호화(at-rest) + 백업 암호화
• 파일 저장소 암호화 + 링크 공유 금지/만료
• 민감 첨부파일은 별도 보안등급(예: “보안팀만 열람”) 옵션

4. 연계 보안(운영과 연결)

• SIEM/Wazuh에 PIA 주요 이벤트를 보냄(예: 고위험 승인, 예외승인 발생, 기한 초과)
• 배포 파이프라인(CI/CD)에서 “PIA 승인 ID 없으면 Production 배포 실패” 같은 게이트 적용

예시(간단 게이트 로직, 의사코드)

# CI 단계에서 PIA 승인상태 확인(예시)
PIA_ID="$1"
STATUS=$(curl -s "https://pia.example/api/v1/pia/${PIA_ID}/status" | jq -r .status)

if [[ "$STATUS" != "APPROVED" && "$STATUS" != "EXCEPTION_APPROVED" ]]; then
  echo "PIA not approved. Block deployment."
  exit 1
fi

구체 예시 3개(작성/평가/조치가 어떻게 굴러가는지)

예시 A) 신규 “회원가입 + 마케팅 동의” 개편

• 변경: 수집항목에 “생년월일” 추가, 마케팅 동의 UI 변경
• 자동 트리거: “개인정보 항목 추가” → 재평가 필요
• 주요 리스크
  • 과다수집(생년월일 필요성 부족)
  • 동의 분리/명확성 미흡
• 보완조치
  • 목적/근거 정리(필수/선택 분리)
  • 동의 UI 스크린샷 증적
  • 보유기간/파기 자동화 설정 증적

예시 B) “외부 결제대행(PG) + 위탁” 도입

• 변경: 제3자 제공/위탁 신규 발생
• 주요 리스크
  • 위탁사 관리 부재(계약/점검/재위탁)
  • 전송구간 노출(API 키 유출)
• 보완조치
  • 위탁계약서 보안조항 첨부 + 점검주기 등록
  • API 인증 OAuth/mTLS, IP 제한
  • 제공 최소화(필요 필드만)

예시 C) “AI 추천(프로파일링)” 도입

• 변경: 행태정보 기반 분석/추천
• 주요 리스크
  • 목적 외 이용(추천 외 2차 활용)
  • 과도한 추적/장기보관
  • 모델 학습데이터 관리(반출/재식별)
• 보완조치
  • 데이터 최소화/보관기간 단축
  • 학습데이터 접근통제 + 반출 승인 절차
  • 설명가능성/거부권 등 관련 고지(조직 정책에 따라)

운영체계(사람/규정/지표)까지 포함해야 “돌아갑니다”

역할(R&R) 권장

• 서비스 오너: 사실관계/데이터흐름 입력 책임
• 개인정보 담당: 법적 근거/고지/동의/보유기간 검증
• 보안팀: 접근통제/암호화/로그/취약점/연동 보안 검증
• 법무/컴플: 계약(위탁/국외이전) 조항 검증
• DPO/CISO: 고위험 승인/예외승인 최종 책임

KPI/대시보드(관리자는 이걸 봅니다)

• PIA 평균 리드타임(제출→승인)
• 고위험(13~25) 건수 추이
• 예외승인 건수 + 만료일 도래 건수
• 보완조치 SLA 준수율
• 시스템/서비스 커버리지(PIA 연결률)

구축 로드맵

1. 1단계(빠르게 효과)
   • 템플릿/이력/증적 저장 + 승인 워크플로우
2. 2단계(누락 방지)
   • 변경요청/SDLC 연동(트리거 자동화) + 보완조치 티켓 자동 생성
3. 3단계(운영 내재화)
   • CI/CD 배포 게이트 + SIEM 연계 + 예외승인 만료 관리
4. 4단계(고도화)
   • 데이터 카탈로그/자동 분류(DLP)와 연동해 “항목 인식 자동화”, 위험 추천

내부 사용자 점검 체크리스트

1. 수집 최소화: 목적 대비 필수/선택이 명확한가
2. 처리 목적: 추천/분석 등 2차 활용이 섞이지 않았나
3. 보유·파기: 보유기간이 자동화되어 있고 증적이 있는가
4. 제공/위탁: 계약/재위탁/점검주기가 시스템에 등록됐나
5. 국외이전: 이전 경로/사업자/보호조치/대응절차가 있는가
6. 접근통제: DB/오브젝트스토리지/로그 접근이 최소권한인가
7. 전송보안: 외부 연동 API에 강한 인증·키관리·제한이 있는가
8. 로깅/감사: “누가 무엇을 봤는지” 추적 가능한가
9. 사고대응: 유출 시 통지/보고/차단 절차가 PIA에 연결됐나
10. 재평가 트리거: 변경 시 자동으로 PIA가 열리도록 되어 있나

다음 단계

• PIA 관리 시스템 요구사항 정의(기능/비기능/RBAC/감사로그/연계)
• DB/엔티티 설계(ERD) + 상태전이 표(State Machine)
• PIA 템플릿(작성 예시 포함) + 위험/통제 라이브러리(표)
• SDLC 연동 설계(Jira/Git/CI/CD 게이트)