059. 사후 보안 (Bolt-on Security)

⚠️ 이 문서는 시스템이나 소프트웨어 개발 시 보안을 고려하지 않다가, 개발 완료 후 또는 운영 중에 취약점이 발견되면 방화벽, 백신, 패치 등을 덧대어 막으려는 과거의 수동적인 보안 접근 방식인 '사후 보안(Bolt-on Security)'의 위험성과 한계를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 사후 보안(Bolt-on Security)은 나사(Bolt)를 덧대어 조이듯, 애플리케이션의 본질적 구조(Architecture)는 수정하지 않은 채 외곽에 WAF, IPS, 솔루션 등을 덧붙여서 외부 위협을 튕겨내려는 땜질식 보안 접근법이다.
  2. 가치/한계: 당장의 출시일(Time-to-Market)을 맞추기 위해 초기엔 빨라 보이지만, 근본적인 논리 결함(예: 설계상 권한 우회)은 외곽 장비로 막을 수 없으며, 결국 운영 중에 해킹을 당하고 아키텍처를 뒤집어엎어야 하는 **막대한 기술 부채(Technical Debt)**를 유발한다.
  3. 융합: 현대 IT 공학은 이 치명적 단점을 뼈저리게 경험하고 이를 철저히 금기시(Anti-pattern)하며, 정반대의 개념인 내재적 보안(Security by Design)과 DevSecOps로 패러다임을 180도 전환하였다.

Ⅰ. 개요 및 탄생 배경 (Context & Background)

1990년~2000년대 초기 인터넷 붐 시절, 소프트웨어 개발의 유일한 목표는 "기능이 돌아가게 만들어서 빨리 돈을 버는 것"이었다. 개발자들은 보안에 무지했고, 코드를 다 짠 뒤에 네트워크 엔지니어나 보안팀에게 "우리 서버 앞에 방화벽이랑 침입탐지시스템(IDS) 좀 달아주세요"라고 부탁하는 것이 당연한 관행이었다.

이것이 바로 **사후 보안 (Bolt-on Security)**이다. 기능 개발(Dev)과 보안(Sec)이 물리적, 시간적, 조직적으로 완전히 분리되어 있는 사일로(Silo) 환경에서 탄생한 기형적인 땜질 방식이다. "보안은 보안팀이나 네트워크 장비가 알아서 해줄 거야"라는 개발자의 안일한 믿음이 이 방식을 유지시켰다.

📢 섹션 요약 비유: 배를 만들 때 나무판자에 구멍이 숭숭 나게 대충 만들어 띄워놓고, 물이 새어 들어오기 시작하니까 배 바깥쪽에서 급하게 방수포(솔루션)를 덧대고 펌프(백신)로 물을 빼내는 아주 위험천만한 선박 제조법입니다.

Ⅱ. 사후 보안의 치명적인 문제점 (Why it fails)

사후 보안은 왜 현대전에서 패배할 수밖에 없는가?

  1. 외곽 통제의 한계 (우회 가능성)
    • WAF(웹 방화벽)를 앞에 달아도, 해커가 WAF의 룰셋을 우회하는 신종 인젝션(Injection) 코드를 짜서 던지면 뚫린다. 애플리케이션 자체가 입력값을 맹신하게 짜여 있다면 외곽 방어막이 뚫리는 순간 서버는 즉시 무너진다.
  2. 비즈니스 로직 취약점은 방어 불가
    • 방화벽이나 솔루션은 트래픽이 정상적인지(HTTP 형식에 맞는지)만 판단할 뿐, 로직의 결함은 알지 못한다.
    • 예: 장바구니에 아이템 개수를 -1(마이너스)로 넣었을 때 돈이 환불되는 로직 에러나, 남의 게시글 번호로 URL을 고쳤더니 권한 없이 읽히는 문제(IDOR)는 장비로 절대 막을 수 없다. 오직 '소스코드'를 뜯어고쳐야만 막힌다.
  3. 천문학적인 수정 비용 (Cost of Change)
    • 개발 완료 후 모의해킹에서 설계 결함이 발견되면, DB 스키마부터 API 로직까지 연쇄적으로 뜯어고쳐야 한다. 설계 단계에서 10만 원이면 고칠 것을, 오픈 후에는 1,000만 원 이상의 기회비용과 서비스 중단(Downtime)을 감수해야 한다.
  4. 시스템 복잡도와 성능 저하
    • 코드를 고치기 싫으니 자꾸 앞에 솔루션을 덧붙인다 (방화벽 $\rightarrow$ WAF $\rightarrow$ 프록시 $\rightarrow$ 암호화 장비). 트래픽이 거쳐야 할 장비가 무거워져 네트워크 지연(Latency)이 폭발하고 관리 포인트가 미친 듯이 늘어난다.
┌─────────────────────────────────────────────────────────────────────────────────┐
│           사후 보안(Bolt-on) 아키텍처의 한계와 방어 붕괴 시각화                 │
├─────────────────────────────────────────────────────────────────────────────────┤
│                                                                                 │
│  [ 해커의 교묘한 공격 ]                                                         │
│   "URL 파라미터 조작: /view?user_id=9999 (남의 ID)"                             │
│            │                                                                    │
│            ▼                                                                    │
│   ┌─────────────────┐                                                           │
│   │ 🛡️ WAF (웹 방화벽) │ ─▶ "SQL 주입은 아니네. 정상적인 HTTP 요청이군. 통과!"  │
│   └─────────────────┘                                                           │
│            │ (WAF 우회 성공)                                                    │
│            ▼                                                                    │
│   ┌─────────────────┐                                                           │
│   │ ⚙️ 취약한 애플리케이션│ ─▶ "사용자 인증 체크 로직이 없네? DB에서 9999번     │
│   │   (Bolt-on 타겟)   │     고객 정보 꺼내서 그대로 보여줘야지~"               │
│   └─────────────────┘                                                           │
│            │                                                                    │
│            ▼                                                                    │
│  [ 🚨 개인정보 대량 유출 사고 발생! ]                                           │
│                                                                                 │
│  * 교훈: 아무리 두꺼운 철갑(방화벽)을 겉에 둘러도, 그 안의 뇌(애플리케이션)가   │
│         바보라면 겉모습만 멀쩡한 고철 덩어리에 불과하다.                        │
└─────────────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 다이어그램은 사후 보안의 민낯을 여실히 보여준다. 인프라 보안팀은 WAF를 샀으니 안전하다고 믿지만, 해커는 시스템 자체의 로직 구멍(IDOR)을 찔러 무혈입성한다. 아키텍처나 코드 레벨(Security by Design)에서 "이 유저가 이 데이터를 볼 권한이 있는지 검증하라"는 코드가 내재되어 있지 않으면 솔루션 덧대기(Bolt-on)는 완벽한 돈 낭비다.

  • 📢 섹션 요약 비유: 몸이 비만이고 혈관이 망가진 사람(결함 있는 코드)이 운동과 식단 조절(내재적 설계)은 안 하고, 값비싼 비타민과 영양제(외곽 솔루션)만 덕지덕지 먹으면서 자기는 건강해질 거라고 믿는 최악의 안티패턴입니다.

Ⅲ. 실무 시나리오에서의 대립 (Dev vs Sec)

현업에서 Bolt-on 보안의 징후는 주로 개발 부서와 보안 부서의 싸움에서 나타난다.

  • 상황: 오픈 D-7일. 취약점 점검 결과, 비밀번호가 평문으로 저장되고 세션 관리 로직이 엉망임.
  • 보안팀: "코드 설계가 틀렸습니다. 처음부터 다시 짜서 암호화하고, 세션 타이머 넣으세요."
  • 개발팀장: "지금 아키텍처 건드리면 3달 밀립니다. 안 됩니다. 걍 서버 앞에 비싼 보안 솔루션 하나 얹어서(Bolt-on) 일단 외부 접근만 대충 막고 오픈하시죠."
  • 결과: 경영진은 돈과 시간에 쫓겨 결국 솔루션을 덧대는 것을 승인한다. 6개월 뒤 내부 직원의 실수나 외곽 솔루션을 우회한 공격에 의해 평문 DB가 통째로 털리며 회사가 폐업 위기에 몰린다.

Ⅳ. 결론 및 전환 (Paradigm Shift)

'사후 보안(Bolt-on)'은 클라우드 네이티브와 마이크로서비스(MSA)가 지배하는 현대 환경에서는 며칠도 버틸 수 없는 구시대의 유물이다. 인프라가 코드로 짠 대로 수백 대씩 생성되었다가 사라지는 환경에서, 사람이 일일이 장비를 덧붙일 시간은 없다.

소프트웨어 산업은 이 치명적 실패를 교훈 삼아, 보안을 제일 앞단으로 끌어와(Shift-Left) 코드 자체를 견고하게 굽는 **내재적 보안(Security by Design)**이라는 혁명을 이루어냈다. 진정한 보안은 나사를 덧대는 것이 아니라, 쇠를 녹일 때 탄소를 섞어 강철을 만드는 과정이어야 한다.

📌 관련 개념 맵

  • 대비되는 정답 철학: 내재적 보안 (Security by Design), Shift-Left, DevSecOps
  • 발생 원인: 사일로(Silo) 문화, 빠른 출시(Time to market)의 압박
  • 치명적 취약점 형태: 비즈니스 로직 취약점, 인가 결함(IDOR) (솔루션으로 막기 힘든 결함들)

👶 어린이를 위한 3줄 비유 설명

  1. 장난감 자동차를 대충 조립했는데 바퀴가 자꾸 빠지고 흔들려요.
  2. 바퀴의 축을 튼튼하게 다시 고치려면 다 분해해야 하니까 귀찮아서 겉에다가 강력 접착테이프만 둘둘 감아버리는 게 바로 '사후 보안'이에요.
  3. 처음에는 굴러가는 것 같지만, 조금만 거친 길을 달리면 테이프가 다 뜯어지고 자동차는 완전히 박살 나버리는 아주 위험한 방법이랍니다.