Chapter 1

보안 기초와 위협 모델링

  • 1.1 보안에 대한 이해
  • 1.2 신뢰
  • 1.3 고전적인 원칙
  • 1.4 적대적인 관점
  • 1.5 4가지 질문
  • 1.6 위협 모델링
  • 1.7 개인정보보호 고려사항
  • 1.8 어디에나 존재하는 위협 모델링

보안의 본질은 50년 전이나 지금이나 똑같아. "뭘 보호할지" 원칙을 세우고, "어떻게 깨질지" 위협을 찾는 것 — 이 두 축이 보안 설계의 출발점이야.

우리가 보안이라고 하면 해킹 방어, 암호화 같은 걸 떠올리잖아. 근데 Kohnfelder가 말하는 보안의 출발점은 훨씬 근본적이야 — "뭘 보호하고, 누구를 믿을 수 있느냐". 보안 목표를 **CIA(기밀성, 무결성, 가용성)**로 정리하는 건 기본 중의 기본이고, 여기에 인증, 인가, 부인 방지가 더해져. 이게 보안이 커버하는 범위야. 단순히 "해킹 막기"가 아니라, 데이터가 새지 않고(기밀성), 변조되지 않고(무결성), 필요할 때 쓸 수 있고(가용성), 누가 했는지 추적 가능한(부인 방지) 시스템을 만드는 거지.

그다음 질문은 신뢰야. 신뢰 경계(Trust Boundary) 안쪽과 바깥쪽은 완전히 다른 세계거든. 내부 서비스 간 통신이랑 외부 API 요청이 같은 수준의 신뢰를 가지면 안 되잖아. 근데 요즘은 제로 트러스트 모델이 뜨고 있어 — 내부든 외부든 아무것도 기본으로 신뢰하지 않고 매번 검증하는 방식이지. npm 패키지 하나 깔면 뒤에 수백 개 의존성이 딸려오는 세상에서, "신뢰한다"는 게 얼마나 위험한 가정인지 Log4Shell이 증명해줬잖아.

그리고 이 모든 걸 관통하는 게 1975년 Saltzer와 Schroeder가 정리한 원칙들이야. 최소 권한, 기본 거부, 심층 방어, 심리적 수용성 — 이름은 옛날 냄새가 나는데 내용은 지금 당장 K8s RBAC 설정하면서 적용하는 거랑 똑같아. root로 다 돌리지 말고(최소 권한), 허용 목록에 없으면 차단하고(기본 거부), 방어선을 여러 겹 두고(심층 방어), 보안이 너무 불편하면 사람이 우회한다(심리적 수용성). 50년 된 원칙이 여전히 유효한 이유는 간단해 — 기술이 바뀌어도 공격자가 노리는 건 같으니까.

이 원칙을 알았으면 이제 **적대적 사고(Adversarial Thinking)**로 넘어가야 해. 개발할 때 우리는 "이 기능이 어떻게 동작하지?"를 생각하잖아. 보안에서는 그 질문을 뒤집어야 해 — "이 기능이 어떻게 악용될 수 있지?". 파일 업로드를 만들었으면 확장자 위조는? 무한 크기 파일은? 파일명에 ../ 넣으면? 이렇게 끊임없이 "만약에?"를 던지는 거야. 공격자는 스크립트 키디부터 국가 수준까지 다양하고, 동기도 금전부터 서비스 마비까지 제각각이니까, "누가 왜 공격할까"를 먼저 정의해야 방어 수준이 결정돼.

이걸 체계적으로 하는 프레임워크가 STRIDE야. 위장(Spoofing), 변조(Tampering), 부인(Repudiation), 정보 유출(Information Disclosure), 서비스 거부(Denial of Service), 권한 상승(Elevation of Privilege) — 이 6가지를 시스템의 모든 컴포넌트와 데이터 흐름에 하나씩 대입해보는 거지. 빠뜨리지 않으려면 체계가 필요하고, STRIDE가 그 체계를 제공해. 시스템 다이어그램을 그리고, 데이터가 어디서 어디로 흐르는지 시각화하고, 각 지점에서 STRIDE를 적용하면 — 위협 목록이 나와.

근데 핵심은 이게 한 번 하고 끝나는 산출물이 아니라는 거야. API 엔드포인트 하나 추가할 때도 "인증 없이 접근하면?", "대량 요청 보내면?" 정도는 생각해봐야 하고, 코드 리뷰할 때도 "이 입력을 쿼리에 직접 넣고 있네?" 같은 보안 관점이 들어가야 해. 시스템이 바뀌면 위협도 바뀌니까, Agile 환경에서는 스프린트마다 변경분에 대한 증분적 위협 모델링이 현실적이야. 개인정보보호도 마찬가지 — 데이터 최소화 원칙을 위협 모델링 단계에서 반영하지 않으면 나중에 GDPR 대응하느라 리팩토링 지옥에 빠지거든.

결국 위협 모델링의 본질은 4가지 질문이야. 뭘 만들고 있어? 뭐가 잘못될 수 있어? 어떻게 막을 건데? 잘 했는지 어떻게 확인해? 간단해 보이지만, 이걸 개발 문화 속에 녹이는 게 진짜 어려운 거야.

정리

1장 읽고 기억할 거 세 가지:

  1. 보안은 CIA + 인증/인가/부인 방지를 아우르는 시스템 속성이야. 50년 된 원칙(최소 권한, 기본 거부, 심층 방어)이 지금도 그대로 먹혀.
  2. 신뢰는 명시적으로 정의하고, 적대적 사고로 "어떻게 깨질까"를 먼저 생각해야 해. 신뢰 경계 바깥은 기본적으로 의심하고, 서드파티 의존성까지 신뢰 체인으로 인식해야 해.
  3. 위협 모델링은 문서가 아니라 습관이야. STRIDE로 체계적으로 찾되, API 하나 추가할 때도, 코드 리뷰할 때도 적용하는 지속적 사고여야 해.