개인정보와 보호할 자산
55분 안팎
학습 목표
수집 목적과 보관 범위를 정합니다.
개념
왜 자산부터 적습니까
보안 점검에서 첫 질문은 어떤 도구를 실행할지가 아니라 누구의 무엇을 지킬지입니다. 개인 자료 보관 앱에서는 제목과 본문, 계정 정보, 로그인 상태, 관찰 로그가 서로 다른 가치를 가집니다. 자료 본문이 밖으로 나가면 기밀성 손상이고, 소유자가 바뀌면 무결성 손상이며, 메모리 자료가 재시작 때 사라지면 가용성 문제입니다. 하나를 보호했다고 나머지가 보호되는 것은 아닙니다.
이번 모듈은 앞 미션 solution의 app.cjs·auth.cjs·server.cjs와 report.md를 출발점으로 삼습니다. 실습은 소유한 로컬 환경에서 합성 계정과 자료만 사용합니다. Python 3와 Node.js로 문서 검사와 함수 시험을 수행하고 Docker 전체 검사는 외부 실행으로 구분합니다. 미션 ZIP 루트에서 명령을 입력하며 상대 경로가 없다는 오류가 나오면 현재 디렉터리를 먼저 확인합니다. 실제 비밀번호·이름·자료를 예제에 넣지 않습니다.
자산은 파일 이름보다 넓습니다
자산은 보호할 가치가 있는 데이터와 기능입니다. documents는 메모리 Map에 저장된 id·title·content·owner의 묶음입니다. 계정에는 합성 사용자 ID와 역할 및 비밀번호 검증용 salt·key가 있습니다. 세션에는 무작위 식별자와 사용자·만료 시각이 있습니다. 요청 로그는 상태와 요청 식별자로 문제를 추적하는 기능을 제공합니다. 자산을 저장 파일만으로 정의하면 현재 앱의 메모리 자료가 목록에서 빠집니다.
목록에는 식별자, 수집 목적, 위치, 접근자, 보관 기준, 삭제 계기, 금지할 항목을 적습니다. A-documents의 목적은 소유자의 자료 보관이고 접근자는 소유자와 정책이 허용한 관리자입니다. 관리자 읽기는 현재 코드의 규칙이지 모든 서비스의 기본 권한이 아닙니다. 운영 정책에서 관리자 열람을 제한하려면 정책 변경과 테스트를 함께 바꿔야 합니다. 비밀성의 정도와 실제 권한표를 혼동하지 않습니다.
필요한 정보와 편한 정보를 구별합니다
로그인에는 합성 사용자명과 비밀번호 검증값이 필요하지만 생년월일·전화번호는 이 기능에 필요하지 않습니다. 자료 생성에는 제목과 본문이 필요하지만 작성자의 주소는 필요하지 않습니다. 요청 실패를 분석할 때 상태·서버 요청 ID가 있으면 도움이 되지만 원문 비밀번호·세션 쿠키·자료 본문을 로그에 넣을 이유는 없습니다. 나중에 쓸 수도 있다는 설명은 목적과 수집 필요성을 대신하지 못합니다.
사용자가 본문에 개인정보를 입력할 수도 있으므로 title과 content는 잠재적으로 민감한 자유 입력으로 표시합니다. 이번 fixture에는 합성 내용만 있어도 실제 서비스 설계에서는 이 가능성을 고려해야 합니다. 사용자 ID 역시 다른 정보와 연결될 수 있습니다. 로그에 본문이 없다는 관찰만으로 로그 전체가 개인정보와 무관하다고 단정하지 않습니다. 본문 미수집과 접근 제한을 서로 다른 통제로 기록합니다.
현재 관찰과 제안한 정책을 나눕니다
현재 자료와 계정은 프로세스 메모리에 있습니다. 자료는 DELETE 성공 또는 재시작으로 없어집니다. 이것은 사용자 삭제 요구를 완전하게 이행하는 운영 저장 설계가 아니라 현재 코드의 관찰입니다. 향후 디스크·백업·검색 색인을 추가하면 삭제 대상과 시점이 늘어납니다. 현재 없는 저장소를 이미 구현했다고 쓰지 말고 새 기능 도입 시 모델 갱신 조건으로 기록합니다.
세션 TTL은 실습 기본값 1000ms입니다. 만료된 세션은 resolve에서 확인할 때 제거되고 logout도 해당 토큰을 제거합니다. 시간이 지나면 저장소 전체에서 자동으로 정리된다고 말할 수 없습니다. 자산 표에서 접근 불가 시점과 물리 제거 계기를 따로 적으면 이 차이가 드러납니다. 재시작은 메모리를 비우지만 영속 저장의 삭제 증거로 사용할 수 없습니다.
보관·삭제 기준을 검증 가능한 문장으로 씁니다
교재 정책으로 로그 보관 목표를 7일로 제안할 수 있지만 현재 앱에 회전 작업이 구현되었다고 주장하지 않습니다. 이 숫자는 법정 기간이나 일반 서비스의 추천값이 아니라 이 미션에서 선택한 가상 운영 기준입니다. 정책에는 목적 종료 조건, 담당자, 실행 방법, 확인 방법을 함께 적습니다. 법적 의무가 필요한 실제 서비스 판단은 별도 검토 대상이며 이번 실습은 법 준수 인증을 제공하지 않습니다.
삭제 확인은 요청이 성공했는지와 후속 조회에서 자료가 없는지를 묶습니다. 소유자 삭제 뒤 GET은 404여야 하고 타인의 DELETE 뒤 소유자 조회는 여전히 200이어야 합니다. 계정 탈퇴 기능은 현재 없으므로 계정 삭제 완료라고 보고하지 않습니다. 부재 기능을 잔여 위험으로 남기고 후속 설계의 담당과 재검토 조건을 제안합니다.
제출 전 점검과 오류 읽기
이번 레슨 제출물은 네 자산의 표와 수집하지 않을 항목 목록입니다. 각 행을 현재 코드에서 한 번 찾아 근거 파일과 함수명을 덧붙입니다. 예상 기능은 제안이라고 표시하고 실행한 기능은 관찰이라고 표시합니다. 리뷰어가 보관 기준과 삭제 기준을 구분할 수 있고, 로그·세션 원문을 붙이지 않고도 표를 설명할 수 있으면 목적을 달성한 것입니다.
JSONDecodeError가 나오면 쉼표·따옴표와 오류의 줄 번호를 읽습니다. KeyError는 문서 계약에서 요구한 키가 빠졌다는 뜻일 수 있습니다. 검사를 피하려고 빈 칸을 임의 문장으로 채우기보다 목적·접근자·삭제 계기를 실제 앱에 맞게 씁니다. 필드가 있다고 정책이 타당한 것은 아니므로 자동 검사 뒤 사람이 내용과 실행 경로를 대조합니다.
실무 리뷰를 한 번 더 합니다
자산 목록을 읽을 때 같은 데이터를 여러 위치에 복제했는지 질문합니다. 자료 본문을 디버그 파일에 복사하면 새 저장 위치가 생기고 원래 자료의 삭제만으로 사본이 없어지지 않습니다. 현재 코드에서 실제 사본을 찾지 못했다면 가능성으로 표시합니다. 증거 JSON에는 관찰 결과와 합성 식별자만 남기고 자료 원문은 넣지 않는 방향으로 설계합니다. 이 결정은 삭제 부담과 증거 접근 범위를 줄이는 근거가 됩니다.
따라하기
자산 위치 확인
Python 3에서 다음 코드를 실행하고 판별에 사용한 조건을 확인합니다.
assets={'A-documents':'memory','A-accounts':'memory','A-sessions':'memory','A-log':'log'}
for key in sorted(assets): print(key, assets[key])실행 결과
A-accounts memory A-documents memory A-log log A-sessions memory
보관과 제거 시점 구분
Python 3에서 다음 코드를 실행하고 판별에 사용한 조건을 확인합니다.
now=1000; expires_at=1000
print('access:', now < expires_at)
print('cleanup:', 'on resolve/logout')실행 결과
access: False cleanup: on resolve/logout
목적 없는 수집 제외
Python 3에서 다음 코드를 실행하고 판별에 사용한 조건을 확인합니다.
needed={'username','password-verifier'}
requested={'username','password-verifier','phone'}
print('exclude:', ','.join(sorted(requested-needed)))실행 결과
exclude: phone
제출물과 실행 결과 대조
네 자산에 목적·위치·접근자·보관·삭제를 적고 코드의 관찰과 정책 제안을 구분합니다. 미션 ZIP의 threat-model.json에서 assets를 작성합니다.
확인 문제
실습
자료 내용·계정·세션·로그 네 행의 표를 제출합니다. 각 행에는 목적·접근자·위치·보관·삭제·근거 함수·금지 수집 항목이 필요합니다. 현재 동작과 제안한 운영 기준을 표시하고 실제 개인정보는 넣지 않습니다.
더 읽기
면접 질문
- 실습 앱에서 보호할 자산과 신뢰 경계를 설명합니다.