brain

사회공학과 피싱: phishing · spear phishing · smishing · vishing · BEC · 딥페이크

상황

• “계정이 정지될 예정입니다. 본인 확인하세요”라는 택배사·은행 사칭 문자의 링크를 눌렀더니 진짜와 똑같은 로그인 화면이 나왔다(진단 Q1).
• 대표 이름으로 “급하게 거래처에 송금해야 하니 이 계좌로 300만 원 보내 주세요. 회의 중이라 전화는 어려워요“라는 메일·메신저가 왔다.
• 회사 대표의 목소리로 전화가 와서 “지금 바로 처리해”라고 했는데, 나중에 보니 AI로 만든 가짜 목소리였다.
• npm 관리자가 “2FA(Two-Factor Authentication) 갱신이 필요하다”는 npm 사칭 메일에 속아 계정을 빼앗겼다(웹·앱 보안 7번 레슨 2025년 npm 사건).

용어

• social engineering(사회공학) — 기술의 빈틈이 아니라 사람의 심리(신뢰, 다급함, 두려움, 권위에 대한 복종, 호기심)를 이용해 정보를 빼내거나 행동을 시키는 공격. 아무리 시스템이 튼튼해도 사람이 문을 열어 주면 끝이다. 실제 사고의 출발점으로 가장 흔한 경로 중 하나.
• phishing(피싱) — 믿을 만한 곳을 사칭해서 비밀번호·카드번호·인증 코드를 입력하게 하거나 악성 파일을 열게 하는 것(진단 Q1). “fishing(낚시)”을 비튼 말.
  • spear phishing(스피어 피싱, 표적 피싱) — 아무에게나 뿌리지 않고 특정 사람·회사를 조사해서 맞춤으로 만든 피싱. 실제 거래처 이름·진행 중인 프로젝트를 언급해 훨씬 그럴듯하다. 작살(spear)로 한 마리를 노린다는 뜻.
  • smishing(스미싱) — 문자(SMS(Short Message Service))로 오는 피싱. 택배·은행·과태료 사칭이 단골.
  • vishing(비싱) — 음성 전화(voice)로 하는 피싱. 한국의 “보이스피싱”이 이것.
  • 비유: 낚시꾼이 미끼를 던지는 것. 그물처럼 넓게 던지면 일반 피싱, 특정 물고기의 습성을 연구해 그 물고기만 노리면 스피어 피싱.
• pretexting(프리텍스팅, 구실 만들기) — “IT팀인데 점검 중이라 비밀번호 확인 필요해요”처럼 그럴듯한 상황·역할을 꾸며 접근하는 수법. 많은 사회공학 공격의 뼈대.
• BEC(Business Email Compromise, 비즈니스 이메일 사기) — 대표·임원·거래처를 사칭(또는 실제 계정 탈취)해 송금·계좌 변경을 요구하는 사기(상황 2). “CEO 사기”라고도 한다. 피해 금액이 큰 사이버 범죄 유형 중 하나.
• deepfake(딥페이크) — AI로 만든 가짜 목소리·얼굴·영상(상황 3). 몇 초 분량의 목소리 샘플로도 흉내 낼 수 있어, “목소리가 맞으니 본인”이라는 확인 방식이 더는 안전하지 않다. 영상 회의에 등장한 가짜 임원들에게 속아 큰돈을 송금한 해외 기업 사례도 보도됐다.
• 흔한 심리 장치 — 다급함(“오늘 안 하면 정지”), 권위(“대표 지시”), 비밀 유지(“아무에게도 말하지 마”), 두려움(“법적 조치”), 이득(“당첨”). 이 신호가 보이면 멈춘다.
• 방어
  • 다른 경로로 확인(out-of-band verification) — 메일로 온 송금 요청은 이미 알고 있는 번호로 직접 전화해 확인. 문자의 링크 대신 직접 앱·주소를 입력해 접속. 상황 2·3을 막는 가장 효과적인 습관.
  • 확인 절차를 규칙으로 — “계좌 변경·송금은 두 사람 확인”, “가족·팀 간 암호 질문”. 사람의 판단이 아니라 절차가 막게 한다.
  • 피싱에 강한 로그인 — 가짜 사이트에 비밀번호를 넣어도 소용없게 만드는 passkey(패스키)·보안 키(다음 레슨). 상황 4 같은 계정 탈취를 크게 줄인다.
  • 링크 주소 확인 — 표시된 글자가 아니라 실제 도메인을 본다(npmjs.help ≠ npmjs.com, 인프라 용어 2번).

지시 예문

• “우리 팀 송금·계좌 변경 절차를 만들어줘: 메일·메신저 요청만으로는 처리 금지, 등록된 번호로 전화 확인, 금액 기준 이상은 두 사람 승인.”
• “고객에게 보낼 피싱 주의 안내문을 써줘: 우리는 문자로 로그인 링크를 보내지 않는다는 사실, 공식 도메인 목록, 의심될 때 신고 방법.”
• “우리 서비스를 사칭하는 비슷한 도메인(오타·하이픈·다른 최상위 도메인)이 등록돼 있는지 찾아줘.”

---

계정 지키기: password manager · MFA 종류 · MFA fatigue · SIM swap · passkey

상황

• 여러 사이트에 같은 비밀번호를 쓰다가 한 곳이 유출되자, GitHub·클라우드 계정까지 줄줄이 털렸다(웹·앱 보안 3번 레슨 credential stuffing).
• 문자 인증으로 2단계 인증을 켜 뒀는데, 공격자가 통신사에 내 번호로 유심을 재발급받아 인증 문자를 가로챘다.
• 새벽에 “로그인 승인하시겠습니까?” 푸시 알림이 수십 번 와서, 귀찮아서 승인을 눌러 버렸다.
• 비밀번호와 인증 앱 코드를 모두 입력했는데도, 그게 가짜 로그인 페이지였어서 계정을 뺏겼다(1번 레슨 피싱).

용어

• password manager(비밀번호 관리자) — 사이트마다 길고 무작위인 다른 비밀번호를 만들어 저장·자동 입력해 주는 도구. 사람이 외울 필요가 없으니 재사용(상황 1)을 끊는다. 또 등록된 진짜 도메인에서만 자동 입력되어, 가짜 사이트에선 입력이 안 되는 것이 피싱 경보 역할도 한다.
• MFA(Multi-Factor Authentication, 다단계 인증) / 2FA(Two-Factor Authentication, 2단계 인증) — 비밀번호(아는 것)에 더해 가진 것(휴대폰·보안 키)이나 나 자신(지문·얼굴)을 함께 확인(인프라 용어 11번). 방식마다 강도가 다르다(약한 것 → 강한 것):
  • SMS(Short Message Service) 인증 문자 — 가장 약하다. SIM swap(유심 탈취)(상황 2)·문자 가로채기에 취약. 없는 것보단 낫지만 중요한 계정엔 피한다.
  • TOTP(Time-based One-Time Password, 시간 기반 일회용 비밀번호) — 인증 앱(Google Authenticator 등)이 30초마다 바꾸는 6자리 코드. 문자보다 안전. 그러나 가짜 사이트에 코드까지 입력하면 공격자가 즉시 써 버릴 수 있다(상황 4).
  • push 승인 — 앱에 “로그인하시겠습니까?” 알림. 편하지만 아래 MFA fatigue에 약하다. 화면에 뜬 숫자를 맞춰 입력하는 방식(number matching)이 이를 보완한다.
  • hardware security key(하드웨어 보안 키) · passkey(패스키) — 가장 강하다. FIDO2(Fast IDentity Online 2)·WebAuthn(Web Authentication) 표준 기반으로, 인증이 진짜 도메인에 묶여 있어서 가짜 사이트에선 작동 자체를 안 한다. 그래서 “피싱 저항(phishing-resistant)” 인증이라 부른다(상황 4 해결).
• MFA fatigue / push bombing(인증 피로 공격) — 비밀번호를 알아낸 공격자가 승인 요청을 수십 번 반복해 사용자가 지쳐서(또는 실수로) 승인하게 만드는 것(상황 3). 2022년 우버(Uber) 침해 사고의 출발점으로 널리 알려졌다. 내가 시도하지 않은 승인 요청은 절대 승인하지 않고, 오히려 비밀번호가 샜다는 신호로 보고 즉시 바꾼다.
• SIM swap(심 스와핑, 유심 탈취) — 공격자가 피해자를 사칭해 통신사에서 유심을 재발급받아 전화번호를 가로채는 것(상황 2). 문자 인증·전화 인증을 모두 무력화한다. 통신사의 유심 보호·번호 이동 잠금 서비스를 켜 두고, 중요한 계정은 문자 인증에 의존하지 않는다.
• passkey(패스키) — 비밀번호 대신 기기(폰·노트북)에 저장된 암호 열쇠 + 지문·얼굴·PIN(Personal Identification Number)으로 로그인하는 방식. 외울 것도, 유출될 비밀번호도 없고, 피싱 사이트에선 작동하지 않는다. 지원하는 서비스(GitHub, Google, Apple 등)부터 켜 둔다.
  • 비유: 비밀번호·인증 코드는 말로 전하는 암호라 엿듣거나 속여서 받아 낼 수 있다. 패스키는 진짜 문에만 맞는 열쇠 — 가짜 문(피싱 사이트)엔 아예 꽂히지 않는다.
• account recovery(계정 복구)가 약한 고리 — 아무리 강한 인증을 걸어도 “비밀번호 찾기”가 문자 하나로 뚫리면 소용없다. recovery code(복구 코드)는 비밀번호 관리자나 오프라인에 안전하게 보관하고, 복구 수단(이메일·전화)도 함께 강화한다.
• 우선순위 — 모든 계정을 똑같이 지킬 수 없다면 이메일(다른 계정 복구의 열쇠), GitHub·클라우드·도메인 등록 업체(서비스 전체의 열쇠), 결제·은행부터. 바이브코더에겐 GitHub과 클라우드 콘솔이 곧 회사 전체다.

지시 예문

• “내가 쓰는 핵심 계정(이메일, GitHub, Vercel, Supabase, AWS, 도메인 등록 업체, npm)의 2단계 인증 설정 방법을 정리해줘. 각각 passkey·보안 키 지원 여부와 문자 인증을 끄는 방법까지.”
• “우리 서비스 로그인에 passkey(WebAuthn) 옵션을 추가하는 구현 계획을 세워줘. 기존 비밀번호 로그인과 함께 쓰는 방식으로.”
• “우리 서비스의 비밀번호 재설정·계정 복구 흐름이 문자 하나로 뚫리지 않는지 점검해줘. 복구 코드 발급과 보관 안내도 추가하고.”

---

위협 모델링: asset · threat actor · data flow · STRIDE · 네 가지 질문

데이터가 신뢰 경계를 넘는 지점에서 검증과 권한 검사가 필요합니다.

상황

• 결제 기능을 다 만든 뒤에야 “환불 API에 권한 검사가 없다“는 걸 알았다. 고치려니 구조를 크게 바꿔야 한다.
• 보안 점검을 하려는데 OWASP(Open Worldwide Application Security Project) Top 10을 위에서부터 다 보자니 끝이 없다. 우리 서비스에서 진짜 위험한 게 뭔지 우선순위가 없다.
• AI에게 “보안 점검해 줘”라고 하면 매번 일반론만 나온다.

용어

• threat modeling(위협 모델링) — 만들기 전에(또는 크게 바꾸기 전에) “누가, 무엇을 노리고, 어떤 경로로 공격할 수 있나, 그래서 무엇을 대비할까“를 체계적으로 따져 보는 활동(진단 Q2의 답). 다 만든 뒤 고치는 것보다 설계 단계에서 고치는 게 훨씬 싸다(웹·앱 보안 10번 레슨 shift left, OWASP의 insecure design 범주).
  • 비유: 이사 가기 전 집 방범 계획. “귀중품은 무엇이고(자산), 누가 노릴 수 있고(위협 주체), 어디로 들어올 수 있나(창문·현관·베란다), 그래서 무엇을 달까(잠금장치·CCTV)”. 이사한 뒤 도둑맞고 나서 창문을 바꾸는 것보다 싸다.
• 네 가지 질문 — 위협 모델링의 가장 단순한 틀(보안 전문가 애덤 쇼스택이 정리).
  1. 무엇을 만들고 있나? — 구조를 그린다(아래 data flow).
  2. 무엇이 잘못될 수 있나? — 위협을 찾는다(아래 STRIDE).
  3. 그래서 무엇을 할까? — 대응책과 우선순위.
  4. 잘했나? — 대응책이 실제로 들어갔는지 확인(테스트, 기획 용어 3번 acceptance criteria).
• asset(자산) — 지켜야 할 것. 고객 개인정보, 결제 정보, 계정, 돈(환불·포인트), 서비스 가용성, 평판, 비밀 키.
• threat actor(위협 주체) — 공격할 수 있는 누군가. 익명의 외부인·봇, 로그인한 일반 사용자(웹·앱 보안 2번 레슨 IDOR(Insecure Direct Object Reference)), 악의적인 내부자·퇴사자, 탈취된 계정, 속은 AI 에이전트(AI 보안 2번 레슨). “로그인한 사용자도 공격자일 수 있다”는 게 자주 빠진다.
• attack vector(공격 경로) — 공격이 들어오는 길. 입력 폼, API, 파일 업로드, 외부 연동, 웹훅, 관리자 화면, 의존성, AI가 읽는 외부 문서(웹·앱 보안 1번 레슨 attack surface).
• DFD(Data Flow Diagram, 데이터 흐름도) — 사용자·브라우저·서버·DB·외부 서비스(결제사·AI API)를 상자로, 데이터가 오가는 길을 화살표로 그린 그림. 화살표가 trust boundary(신뢰 경계)(AI 보안 1번 레슨)를 넘는 지점마다 위협이 생긴다 — 거기가 점검 1순위. 기획 용어 5번 user flow의 보안 버전.
• STRIDE(스트라이드) — “무엇이 잘못될 수 있나”를 빠짐없이 묻기 위한 6가지 위협 분류 체크리스트(마이크로소프트가 만든 틀). 각 화살표·상자에 대해 하나씩 묻는다.
  • S — Spoofing(위장): 남인 척할 수 있나? → 인증(웹·앱 보안 3번 레슨, 2번 레슨 MFA(Multi-Factor Authentication))
  • T — Tampering(변조): 데이터를 몰래 바꿀 수 있나? → 무결성, 서버 검증, 결제 금액은 서버가 계산
  • R — Repudiation(부인): “나 안 했어”라고 발뺌할 수 있나? → audit log(웹·앱 보안 10번 레슨)
  • I — Information disclosure(정보 노출): 보면 안 되는 걸 볼 수 있나? → 접근 제어, 응답 필드 최소화(웹·앱 보안 8번 레슨)
  • D — Denial of service(서비스 거부): 멈추게 하거나 요금을 터뜨릴 수 있나? → rate limit, 상한(AI 보안 8번 레슨)
  • E — Elevation of privilege(권한 상승): 더 높은 권한을 얻을 수 있나? → 서버 측 권한 검사, 최소 권한(웹·앱 보안 2번 레슨)
  • 웹·앱 보안 1번 레슨 CIA(Confidentiality·Integrity·Availability)와 짝을 이룬다: T↔무결성, I↔기밀성, D↔가용성.
• 우선순위 — 찾은 위협마다 가능성 × 피해 크기(웹·앱 보안 1번 레슨 risk)로 점수를 매겨 높은 것부터(상황 2). 모든 위협을 막을 순 없으니 받아들일 위험(accept)도 의식적으로 정한다.
• AI와 함께 하기 — “보안 점검해 줘” 대신 DFD와 자산 목록을 주고 STRIDE로 묻게 하면 일반론이 아닌 우리 서비스 맞춤 위협이 나온다(상황 3).

지시 예문

• “결제·환불 기능의 데이터 흐름도(DFD)를 Mermaid로 그려줘. 사용자, 브라우저, API 서버, DB, 결제사, 웹훅을 넣고 trust boundary를 표시해서.”
• “그 DFD의 화살표마다 STRIDE 6가지를 적용해서 위협 목록을 만들어줘. 각 위협의 가능성·피해 크기·대응책·관련 코드 위치를 표로, 점수 높은 순으로.”
• “이 기능의 자산과 threat actor 목록을 정리해줘. 로그인한 일반 사용자, 퇴사자, 탈취된 관리자 계정, 속은 AI 에이전트를 포함해서.”
• “PRD(Product Requirements Document)에 ‘보안 고려사항’ 섹션을 추가해서, 위협 모델링 결과 상위 5개와 대응책을 acceptance criteria로 적어줘.”

---

보안 설계 원칙: zero trust · defense in depth · separation of duties · secure by default · fail closed

상황

• 사내 관리 도구를 “회사 와이파이에서만 접속되니까 안전하다”며 로그인 없이 열어 뒀다. 누군가 카페에서 VPN(Virtual Private Network) 계정 하나를 탈취하자 내부 전체가 열렸다.
• 개발자 한 명이 코드 작성·리뷰 승인·실서비스 배포·DB 접근을 혼자 다 할 수 있었다. 실수 하나가 그대로 사고가 됐다.
• 결제 검증 서버가 잠깐 응답하지 않자, 코드가 “에러면 일단 통과“로 처리해 검증 없이 결제가 승인됐다.
• 새 기능을 배포할 때마다 기본 설정이 “모두 공개”라서, 일일이 닫아야 했고 몇 개는 놓쳤다.

용어

• perimeter security(경계 보안, 성곽 모델) — “안쪽은 믿고, 바깥만 막는다“는 옛 방식. 회사 네트워크 안에 들어오면 대부분 허용. 상황 1처럼 한 번 뚫리면 안쪽 전체가 열린다.
  • 비유: 성벽과 해자만 튼튼한 성. 성문을 한 번 통과하면 성 안 어디든 다닐 수 있다.
• zero trust(제로 트러스트) — “아무것도 기본으로 믿지 않고, 매번 확인한다(never trust, always verify)”. 회사 네트워크 안이든 밖이든, 요청마다 누구인지·어떤 기기인지·권한이 있는지를 확인한다. 클라우드·재택·외부 SaaS(Software as a Service)가 섞인 요즘 환경의 기본 사고방식.
  • 핵심: 위치(사내망)로 신뢰하지 않음, 요청 단위 인증·인가(웹·앱 보안 2번 레슨 서버 측 검사), 최소 권한(인프라 용어 11번, AI 보안 3번 레슨), 이상 행동 감시.
  • 비유: 성 대신 호텔. 호텔 건물에 들어와도 방마다 카드키가 필요하고, 카드키는 내 방·내 층만 연다.
  • 바이브코더에게: DB를 “내부망이니 괜찮다”며 열어 두지 않기(인프라 용어 11번), 관리 화면도 로그인·MFA(Multi-Factor Authentication) 필수, 서버끼리의 호출도 인증.
• defense in depth(다층 방어) — 방어를 여러 겹으로 쌓아, 한 겹이 뚫려도 다음 겹이 막게 하는 것(웹·앱 보안 5번 레슨 보안 헤더, AI 보안 8번 레슨 가드레일). 입력 검증 + 서버 권한 검사 + RLS(Row Level Security) + 최소 권한 키 + 모니터링.
  • 비유: 은행. 경비원 + CCTV + 금고 + 금고 안 개별 보관함 + 출입 기록.
• separation of duties(직무 분리) — 중요한 일을 한 사람이 처음부터 끝까지 하지 못하게 나누는 것(상황 2). 코드 작성자 ≠ 리뷰 승인자, 송금 요청자 ≠ 승인자(1번 레슨 BEC(Business Email Compromise) 대책), 실서비스 DB 접근은 별도 권한. 혼자 개발하는 사람은 사람 대신 절차·도구로 나눈다: 브랜치 보호(PR(Pull Request) 없이 main 직접 push 금지), CI(Continuous Integration) 통과 필수, AI가 만든 변경은 내가 승인(AI 보안 9번 레슨).
• secure by default(기본값을 안전하게) — 설정의 출발점을 가장 안전한 쪽에 두고, 필요한 것만 연다(상황 4). 새 버킷은 private, 새 API는 인증 필수, 새 테이블은 RLS 켜짐(웹·앱 보안 2번 레슨 deny by default, 8번 레슨 hardening). 사람은 “닫기”를 잊기 쉬우니 잊어도 안전하게.
• fail closed vs fail open(실패 시 닫기 vs 열기) — 검사 장치가 고장·에러났을 때 어느 쪽으로 넘어지게 할지(상황 3).
  • fail closed(fail secure) — 에러면 거부. 인증·권한·결제 검증은 이쪽이 원칙.
  • fail open — 에러면 허용. 가용성이 더 중요한 곳(예: 추천 기능이 실패하면 추천 없이 보여주기)에만.
  • 비유: 정전 때 금고 문은 잠긴 채로(fail closed), 비상구 문은 열린 채로(fail open) 있어야 한다. 무엇을 지키는 문이냐에 따라 다르다.
  • AI가 만든 try { verify() } catch { /* 무시하고 진행 */ } 같은 코드가 대표적인 fail open 실수.
• keep it simple(단순하게) — 복잡할수록 빈틈이 숨는다. 쓰지 않는 기능·계정·도구·의존성은 지워서 공격 표면을 줄인다(웹·앱 보안 1번 레슨, 7번 레슨 의존성 최소화).

지시 예문

• “인증·권한·결제 검증 코드에서 에러가 나면 통과시키는(fail open) catch 블록을 찾아서, 거부(fail closed)하도록 바꿔줘. 예외적으로 fail open이 맞는 곳은 이유를 주석으로.”
• “관리 화면과 내부 API가 ‘내부망이라서’ 인증 없이 열려 있는 곳이 있는지 점검하고, 전부 로그인·역할 검사를 거치게 바꿔줘.”
• “GitHub 저장소에 main 브랜치 보호를 걸어줘: PR 필수, CI 통과 필수, 직접 push 금지.”
• “새 테이블·버킷·API를 만들 때 쓰는 템플릿을 secure by default로 만들어줘: RLS 켜짐, private, 인증 필수가 기본값.”

---

보안 사고 대응: IR 단계 · containment · 증거 보존 · IOC · 유출 신고 72시간

상황

• 새벽에 관리자 계정으로 회원 데이터가 대량 조회된 기록을 발견했다. 당황해서 서버를 통째로 지우고 새로 설치했더니, 무엇이 언제 어떻게 빠져나갔는지 알 수 없게 됐다.
• 해킹이 의심되는데 “확실해지면 알리자”며 내부 조사만 2주를 했다. 그 사이 신고 기한을 넘겼다.
• 유출된 API 키를 새로 발급했지만, 공격자가 그 키로 미리 만들어 둔 다른 관리자 계정은 그대로 남아 있었다.

용어

• IR(Incident Response, 보안 사고 대응) — 보안 사고가 났을 때 피해를 줄이고, 원인을 없애고, 복구하고, 배우는 정해진 절차. 인프라 용어 13번 incident·runbook·postmortem의 보안판. 미국 표준 기관 NIST(National Institute of Standards and Technology)가 정리한 단계가 널리 쓰인다:
  1. preparation(준비) — 사고 전에: 연락망, runbook, 로그·audit log(웹·앱 보안 10번 레슨), 백업, 키 폐기 방법을 미리 마련.
  2. detection & analysis(탐지·분석) — 이상 징후 발견, 진짜 사고인지·범위가 어디까지인지 판단.
  3. containment, eradication & recovery(차단·제거·복구) — 아래 설명.
  4. post-incident activity(사후 활동) — postmortem(인프라 용어 13번), 재발 방지 작업, 위협 모델(3번 레슨) 갱신.
     • 비유: 화재 대응. 준비(소화기·대피로), 발견(연기 감지), 차단(방화문 닫기), 진화(불 끄기), 복구(수리), 원인 조사·재발 방지. 불을 끄기 전에 원인 조사부터 하지 않고, 원인 조사 없이 그냥 페인트칠만 다시 하지도 않는다.
• containment(차단·봉쇄) — 피해가 더 번지지 않게 막는 단계. 가장 먼저 한다.
  • 유출 의심 키·토큰 폐기(인프라 용어 11번), 탈취 의심 계정 잠금·세션 전부 무효화(웹·앱 보안 3번 레슨), 문제 서버를 네트워크에서 격리(지우지 말고), 취약한 기능 임시 차단(feature flag, 기획 용어 6번).
• evidence preservation(증거 보존) — 차단하면서도 로그·디스크·DB 상태를 지우지 않고 남겨 두는 것. 서버를 바로 밀어 버리면 무엇이 빠져나갔는지, 공격자가 아직 남아 있는지 알 수 없다(상황 1). 스냅샷·로그 백업을 먼저 뜨고, 그다음 복구한다.
• eradication(제거) — 공격자의 발판을 모두 없애는 것: 심어 둔 백도어, 몰래 만든 계정·키(상황 3), 악성 의존성(웹·앱 보안 7번 레슨), 그리고 처음 뚫린 취약점 자체. 키만 바꾸고 끝내면 공격자가 다른 문으로 돌아온다.
• recovery(복구) — 깨끗한 상태로 서비스를 되돌림. 오염되지 않은 백업(DB 용어 14번), 재배포, 강화된 감시 속에서 단계적으로.
• IOC(Indicator of Compromise, 침해 지표) — “뚫렸다“는 흔적: 처음 보는 관리자 계정, 알 수 없는 IP의 로그인, 갑자기 생긴 API 키, 낯선 외부 주소로 나가는 대량 트래픽, 변경된 파일. 이걸 기준으로 피해 범위를 찾고, 다른 곳도 당했는지 확인한다.
• breach notification(유출 통지·신고) — 개인정보가 유출되면 법이 정한 기한 안에 알려야 한다(상황 2). 한국 개인정보 보호법에선 1천 명 이상 유출, 민감정보·고유식별정보 유출, 외부 해킹에 의한 유출(규모 무관) 등은 알게 된 때부터 72시간 이내 개인정보보호위원회 또는 KISA(Korea Internet & Security Agency, 한국인터넷진흥원)에 신고해야 하고, 정보주체(피해 이용자)에게도 통지해야 한다. “내부 조사가 끝난 뒤”가 아니라 “알게 된 때”부터 센다. 2026년 개정으로 유출이 최종 확인되기 전 “유출 가능성” 단계의 통지, 과징금 상향 등이 강화됐다고 보도됐으니, 실제 적용 조문은 최신 법령으로 확인한다.
  • 숨기거나 늦추면 법적 제재와 신뢰 손실이 사고 자체보다 커지는 경우가 많다(인프라 용어 13번 status page·투명한 공지).
• 소규모 팀의 현실적 준비 — 거창한 보안 팀 없이도: 연락할 사람·순서, 키 폐기 방법 목록(서비스별), 로그가 어디에 며칠 남는지, 백업 복구 리허설(DB 용어 14번), 신고처와 기한 메모를 한 장의 runbook으로.

지시 예문

• “보안 사고 runbook 초안을 만들어줘: 탐지 시 확인할 IOC 목록, containment 순서(키 폐기·세션 무효화·격리), 증거 보존(로그·DB 스냅샷) 방법, 연락망, 개인정보 유출 시 72시간 신고·통지 체크리스트.”
• “우리가 쓰는 모든 서비스(Supabase, Vercel, AWS, GitHub, 결제사, AI API)의 키를 긴급 폐기·재발급하는 방법을 한 문서에 정리해줘.”
• “지난 7일 audit log에서 IOC를 찾아줘: 새로 생긴 관리자 계정, 처음 보는 국가·IP 로그인, 새로 발급된 API 키, 평소 대비 대량 조회.”

---

랜섬웨어와 백업: ransomware · 이중 협박 · 3-2-1 백업 · immutable backup

상황

• 어느 날 아침 서버의 파일과 DB가 전부 암호화되어 열리지 않고, “비트코인을 보내면 풀어 주겠다”는 메시지만 남았다.
• 백업은 매일 하고 있었는데, 공격자가 같은 관리자 계정으로 백업 저장소에도 들어가 백업까지 지워 버렸다.
• 복구는 했지만, 공격자가 “돈을 안 내면 훔쳐 간 고객 데이터를 공개하겠다”고 다시 협박한다.

용어

• ransomware(랜섬웨어) — 데이터를 암호화해 못 쓰게 만들고, 풀어 주는 대가로 몸값(ransom)을 요구하는 악성코드·공격. 웹·앱 보안 1번 레슨 CIA(Confidentiality·Integrity·Availability) 중 가용성을 인질로 잡는다. 웹·앱 보안 4번 레슨 MOVEit 사건의 Cl0p 같은 조직이 대표적.
  • 초기 침투 경로 — 대부분 지금까지 배운 것들: 피싱(1번 레슨), 탈취된 계정·약한 MFA(Multi-Factor Authentication)(2번 레슨), 패치 안 된 VPN(Virtual Private Network)·서버(웹·앱 보안 4번 레슨 Fortinet 사례), 인터넷에 열린 원격 접속.
• double extortion(이중 협박) — 암호화만 하는 게 아니라 데이터를 먼저 빼낸 뒤, “복구 대가” + “공개하지 않는 대가“를 이중으로 요구(상황 3). 백업으로 복구해도 유출 문제는 남는다 — 5번 레슨 유출 신고 의무가 함께 발생한다.
• 3-2-1 backup rule(3-2-1 백업 규칙) — 백업의 기본 원칙.
  • 3 — 데이터 사본을 3개(원본 1 + 백업 2)
  • 2 — 2가지 다른 저장 방식(예: DB 자체 백업 + 다른 클라우드 저장소)
  • 1 — 1개는 다른 장소(다른 리전·다른 클라우드 계정, 인프라 용어 9번)
  • 비유: 중요한 계약서를 원본 + 복사본 두 장으로 만들고, 그중 하나는 다른 건물 금고에 두는 것. 사무실에 불이 나도 하나는 남는다.
• immutable backup(불변 백업) · offline backup(오프라인 백업) — 상황 2처럼 공격자가 관리자 권한을 얻으면 온라인 백업도 지운다. 그래서:
  • immutable(불변) — 정해진 기간 동안 누구도(관리자도) 수정·삭제할 수 없게 잠근 백업(클라우드 스토리지의 보존 잠금 기능 등).
  • offline / air-gapped(분리된) — 평소 네트워크에서 끊어 둔 백업.
  • 백업 접근 권한 분리 — 백업을 지울 수 있는 계정을 일상 관리자 계정과 다르게(4번 레슨 직무 분리, 인프라 용어 11번 최소 권한).
  • 3-2-1에 “불변·오프라인 1개”와 “복구 검증 오류 0”을 더해 3-2-1-1-0이라 부르기도 한다.
• restore test(복구 테스트) — 한 번도 복구해 본 적 없는 백업은 믿을 수 없다(DB 용어 14번). 정기적으로 실제 복구해 보고, 걸리는 시간이 RTO(Recovery Time Objective)·RPO(Recovery Point Objective)(인프라 용어 13번) 안에 드는지 확인한다.
• 몸값을 낼까 — 내도 복구된다는 보장이 없고, 데이터 공개 협박은 계속될 수 있으며, 범죄 자금이 된다. 그래서 내지 않아도 되도록 준비(위 백업)하는 것이 핵심이다. 실제 결정은 법률·수사기관(경찰·KISA(Korea Internet & Security Agency))과 상의한다.

지시 예문

• “우리 데이터(DB, 업로드 파일, 설정)의 백업 현황을 3-2-1 기준으로 점검해줘: 사본 수, 저장 방식, 다른 리전·계정 보관 여부. 부족한 부분 개선안도.”
• “백업 버킷에 보존 잠금(immutable)을 걸어서 30일간 삭제·수정이 안 되게 하고, 백업을 지울 수 있는 권한을 일상 관리자 계정과 분리해줘.”
• “매달 첫째 주에 최신 백업을 스테이징에 실제 복구해 보고, 걸린 시간과 데이터 시점을 기록하는 복구 테스트 절차를 만들어줘.”

---

취약점 관리와 공개: patch · zero-day · KEV · coordinated disclosure · bug bounty · security.txt

상황

• 쓰던 VPN(Virtual Private Network) 장비의 취약점 패치가 나왔는데 “바빠서” 몇 달 미뤘더니 그사이 뚫렸다(웹·앱 보안 4번 레슨 Fortinet 사례).
• 모르는 사람이 “당신 서비스에 다른 사람 주문을 볼 수 있는 구멍이 있다“는 메일을 보냈다. 스팸인지 진짜인지, 어떻게 답해야 할지 모르겠다.
• 반대로, 내가 다른 회사 서비스를 쓰다 취약점을 발견했다. 어디에 어떻게 알려야 할지 모르겠다.

용어

• patch management(패치 관리) — 소프트웨어·의존성·서버·장비의 보안 업데이트를 꾸준히 적용하는 일. 웹·앱 보안 7번 레슨 의존성 관리의 운영판. 공개된 취약점은 공격자도 같은 날 안다 — 패치가 나온 뒤 미루는 기간이 가장 위험하다(상황 1).
• zero-day(제로데이) vs n-day —
  • zero-day — 개발사가 아직 모르거나 패치가 없는 상태에서 악용되는 취약점. “고칠 시간이 0일”. MOVEit 사건이 제로데이(웹·앱 보안 4번 레슨). 개인·소규모 팀이 직접 막기는 어렵고, 다층 방어(4번 레슨)로 피해를 줄인다.
  • n-day — 이미 공개되고 패치도 나온 취약점. 대부분의 실제 침해는 이쪽 — 패치만 했으면 막혔을 사고가 훨씬 많다.
• KEV(Known Exploited Vulnerabilities, 실제 악용 취약점 목록) — 미국 사이버보안 기관 CISA(Cybersecurity and Infrastructure Security Agency)가 관리하는, 실제로 공격에 쓰이고 있는 취약점 목록. CVSS(Common Vulnerability Scoring System) 점수(웹·앱 보안 7번 레슨)가 “얼마나 심각할 수 있나”라면, KEV는 “지금 실제로 당하고 있나”. 우선순위를 정할 때 함께 본다.
• vulnerability disclosure(취약점 공개) — 취약점을 발견한 사람이 그 사실을 알리는 방식.
  • coordinated disclosure(조정된 공개, 책임 있는 공개) — 먼저 개발사에 비공개로 알리고, 고칠 시간(흔히 90일 안팎)을 준 뒤에 공개. 업계의 표준 관행.
  • full disclosure(전면 공개) — 바로 대중에 공개. 개발사가 무시할 때 압박 수단으로 쓰이기도 하지만, 패치 전 공개라 위험하다.
  • 상황 3이라면: 해당 회사의 보안 신고 창구로 비공개로 알리고, 확인에 필요한 최소한만 시험하며, 남의 데이터를 열람·저장·공유하지 않는다. 허락받지 않은 공격·스캔은 법적 문제가 될 수 있다 — 아래 VDP·버그 바운티의 허용 범위 안에서만.
• VDP(Vulnerability Disclosure Policy, 취약점 공개 정책) — “취약점을 발견하면 여기로, 이렇게 알려 주세요. 이 범위 안의 선의의 점검에는 법적 조치를 하지 않겠습니다(safe harbor, 면책 보장)”를 공개한 문서. 보상은 없을 수도 있다.
• bug bounty(버그 바운티) — VDP에 더해 유효한 취약점 신고에 보상금을 주는 제도(진단 Q3의 답). 대기업·플랫폼은 HackerOne·Bugcrowd 같은 중개 플랫폼에서 운영한다. 신고 범위(scope), 금지 행위(서비스 마비 공격, 개인정보 열람 등), 심각도별 보상이 정해져 있다.
  • 비유: 동네 가게가 “우리 가게 자물쇠 허점을 찾아 알려 주시면 사례하겠습니다. 단, 진짜로 물건을 가져가면 안 됩니다“라고 공고를 붙인 것. 해커톤(진단 Q3 오답)은 정해진 시간 동안 무언가를 만드는 대회라 다르다.
• security.txt — 웹사이트에 /.well-known/security.txt 파일을 두어 보안 연락처와 VDP 위치를 알려 주는 표준(RFC(Request for Comments) 9116). 연구자가 “어디로 알려야 하나”를 바로 찾게 한다.
• 신고를 받았을 때(상황 2) — 작은 팀도 할 일은 단순하다.
  1. 빨리 받았다고 답장(무시·위협하지 않기 — 선의의 신고자를 협박하면 평판만 잃는다).
  2. 재현·심각도 판단(기획 용어 8번 bug report, 웹·앱 보안 1번 레슨 risk).
  3. 고치고, 신고자에게 결과 공유, 원하면 감사 표시(명예의 전당 등).
  4. 필요하면 5번 레슨 사고 대응으로 전환(이미 악용됐는지 IOC(Indicator of Compromise) 확인).

지시 예문

• “우리 서비스에 /.well-known/security.txt를 추가하고, 간단한 VDP 페이지를 만들어줘: 신고 이메일, 범위, 금지 행위, 선의의 점검 면책, 응답 기한.”
• “우리가 쓰는 의존성·서버 구성 요소 중 CISA KEV 목록에 오른 취약점이 있는지 확인하고, 있으면 최우선으로 패치 계획을 세워줘.”
• “외부에서 받은 취약점 신고 메일에 보낼 첫 답장 템플릿과, 재현·심각도 판단·수정·결과 공유까지의 처리 절차를 만들어줘.”

---

공격해 보는 점검과 지키는 조직: pentest · red/blue/purple team · SOC · SIEM · EDR

상황

• 자동 보안 스캔(웹·앱 보안 10번 레슨)은 다 통과했는데, 외부 전문가가 와서 반나절 만에 다른 사용자 주문을 보는 방법을 찾아냈다.
• 투자사가 “모의 해킹 보고서“를 요구한다. 무엇을 의뢰해야 하는지 모르겠다.
• 회사가 커지면서 “보안 관제”, “SIEM”, “EDR” 같은 말이 들리는데 각각이 무엇을 하는 건지 모르겠다.

용어

• vulnerability assessment(취약점 진단) vs pentest(penetration test, 모의 해킹)
  • 취약점 진단 — 도구와 체크리스트로 알려진 약점을 넓게 찾아 목록화(웹·앱 보안 10번 레슨 SAST(Static Application Security Testing)·DAST(Dynamic Application Security Testing)·SCA(Software Composition Analysis)).
  • 모의 해킹 — 허락받은 전문가가 실제 공격자처럼 약점을 엮어 어디까지 뚫리는지 직접 시도. 도구가 못 찾는 업무 논리의 구멍(웹·앱 보안 2번 레슨 접근 제어, 환불·쿠폰 악용 같은 business logic flaw)을 잘 찾는다(상황 1).
  • 비유: 취약점 진단은 건물 안전 점검표로 소화기·비상구를 하나씩 체크하는 것, 모의 해킹은 훈련받은 사람이 실제로 침입을 시도해 보는 것.
• scope · rules of engagement(범위·교전 규칙) — 모의 해킹 전에 서면으로 정하는 것: 대상(도메인·앱·API), 기간, 허용·금지 행위(실서비스 데이터 변경 금지, 서비스 마비 공격 금지), 연락 체계. 허락받지 않은 해킹은 범죄(7번 레슨)라서, 의뢰하는 쪽도 받는 쪽도 이 문서가 필수다(상황 2). 실서비스 대신 스테이징(웹 용어 33번)에서 하는 경우가 많다.
• red team · blue team · purple team
  • red team(레드팀) — 공격하는 쪽. 모의 해킹보다 넓게, 피싱(1번 레슨)·물리 침입까지 포함해 목표(예: 고객 DB 탈취)를 달성해 보는 실전형 훈련.
  • blue team(블루팀) — 방어·탐지·대응하는 쪽. 로그 감시, 경보, 사고 대응(5번 레슨).
  • purple team(퍼플팀) — 레드와 블루가 함께 앉아 “이 공격을 왜 못 잡았나”를 바로 고쳐 가는 협업 방식. 빨강 + 파랑 = 보라.
  • 비유: 축구 연습 경기. 레드팀은 상대 공격수 역할, 블루팀은 우리 수비, 퍼플팀은 경기 중간중간 멈추고 “방금 왜 뚫렸지?”를 같이 복기하는 코치진.
• CTF(Capture The Flag, 깃발 뺏기) — 문제 속 숨겨진 “깃발(정답 문자열)”을 해킹 기법으로 찾아내는 보안 경진 대회·연습 문제. 보안 실력을 기르는 대표적 방법이자, 허락된 환경에서 공격 기법을 배우는 곳.
• 조직이 커지면 등장하는 이름들 — 지금 당장 필요하진 않지만 알아 둘 것(상황 3).
  • SOC(Security Operations Center, 보안 관제 센터) — 보안 이벤트를 24시간 감시·대응하는 팀(또는 외부 관제 서비스). 블루팀의 상시 조직.
  • SIEM(Security Information and Event Management, 보안 정보·이벤트 관리) — 서버·앱·클라우드·로그인 기록 등 흩어진 로그를 한곳에 모아 상관관계를 분석하고 경보를 울리는 시스템. 인프라 용어 8번 관측 + 웹·앱 보안 10번 레슨 audit log의 보안 전용 통합판.
  • EDR(Endpoint Detection and Response, 단말 탐지·대응) — 직원 노트북·서버(엔드포인트)에서 악성 행위를 탐지하고 격리하는 도구. 백신의 진화형. 랜섬웨어(6번 레슨) 초기 단계를 잡는 데 쓰인다.
  • 1인·소규모라면: 클라우드·SaaS(Software as a Service)의 기본 보안 알림을 켜고, audit log와 경보(웹·앱 보안 10번 레슨)부터 갖추는 것이 현실적인 첫걸음.

지시 예문

• “외부 모의 해킹을 의뢰하려고 해. 범위(도메인·API·앱), 기간, 허용·금지 행위, 테스트 계정, 연락 체계를 담은 scope 문서 초안을 써줘. 대상은 스테이징 환경.”
• “우리 서비스의 business logic flaw 후보를 찾아줘: 쿠폰 중복 사용, 음수 수량 주문, 환불 후 포인트 유지, 결제 금액 조작 같은 것들을 시나리오로.”
• “1인 개발자 기준으로 지금 켤 수 있는 보안 알림을 정리해줘: GitHub·Vercel·Supabase·클라우드 콘솔의 새 로그인·키 생성·권한 변경 알림.”

---

규정과 인증: 개인정보처리방침 · 최소 수집 · 파기 · 위탁·국외 이전 · ISMS-P · SOC 2 · GDPR

상황

• 서비스를 출시하려는데 “개인정보처리방침이 없다“는 지적을 받았다. 무엇을 써야 하는지 모르겠다.
• 회원가입에서 이름·생년월일·주소·직업까지 전부 필수로 받고 있다. 실제로 쓰는 건 이메일뿐이다.
• 탈퇴한 회원 정보가 몇 년째 DB에 그대로 남아 있다(DB 용어 10번 soft delete).
• 해외 기업 고객이 계약 전에 “SOC 2 보고서가 있느냐”고 묻는다.

용어

• compliance(컴플라이언스, 규정 준수) — 법·규정·계약이 요구하는 보안·개인정보 기준을 지키고, 지킨다는 걸 증명하는 일. 보안을 “잘하는 것”과 별개로 “지켰다는 근거를 남기는 것“까지 포함한다. 아래는 방향을 잡기 위한 용어 정리이고, 실제 적용은 최신 법령 확인·전문가 자문이 필요하다.
• 개인정보처리방침(privacy policy) — 어떤 개인정보를 무엇을 위해, 얼마나 오래 수집·보관하고, 누구에게 맡기거나 넘기는지, 이용자가 어떻게 열람·삭제를 요청하는지 공개하는 문서. 한국에선 개인정보를 처리하면 공개해야 하는 법적 의무(상황 1). 실제 데이터 흐름(3번 레슨 DFD(Data Flow Diagram))과 일치해야 의미가 있다.
• 개인정보 보호책임자(CPO, Chief Privacy Officer) — 개인정보 처리를 책임지는 사람으로 지정해 방침에 공개한다. 작은 회사는 대표가 겸하는 경우가 많다.
• 최소 수집 원칙(data minimization) — 서비스에 꼭 필요한 정보만 받는다(상황 2). 안 받은 정보는 샐 일도 없다 — 가장 싸고 강력한 보안. 필수와 선택 항목을 나눠서 따로 동의받고, 선택을 거부해도 서비스는 쓸 수 있어야 한다. 마케팅 수신 동의도 별도(디지털 마케팅 10번 레슨).
• 보유 기간과 파기(retention & destruction) — 목적을 다하거나 정해진 보유 기간이 지나면 지체 없이 파기(상황 3). soft delete로 숨기기만 하면 파기가 아니다 — 개인정보 컬럼은 실제 삭제·익명화(DB 용어 10번). 백업 속 데이터도 보존 기간이 지나면 함께 사라지게 설계한다(6번 레슨).
• 위탁과 국외 이전 — 클라우드(AWS·Vercel·Supabase), 이메일 발송, 결제, AI API에 개인정보를 맡기는 것은 처리 위탁이고, 그 서버가 해외에 있으면 국외 이전이다(인프라 용어 9번 data residency). 방침에 어느 회사에, 무엇을, 어느 나라로 넘기는지 적어야 한다. AI 서비스에 고객 데이터를 보내는 기능을 추가했다면 방침도 갱신(AI 보안 4번 레슨).
• ISMS-P(정보보호 및 개인정보보호 관리체계 인증) — 한국 KISA(Korea Internet & Security Agency) 등이 심사하는 보안·개인정보 관리 체계 인증. 일정 규모(매출·이용자 수 등 기준) 이상 사업자에겐 의무이고, 그 외엔 신뢰 확보용으로 받는다. 기준은 시행령 개정으로 바뀔 수 있어 최신 기준을 확인한다.
• ISO 27001 — 국제 표준 정보보호 관리체계 인증. 해외 거래에서 자주 요구된다.
• SOC 2(System and Organization Controls 2) — 미국 회계사 기준에 따른 보안·가용성 등 통제에 대한 감사 보고서. 미국 기업과 B2B(Business to Business) 거래할 때 흔히 요구된다(상황 4). 인증서라기보다 “일정 기간 통제를 잘 운영했다“는 감사 결과다.
• GDPR(General Data Protection Regulation, EU 일반 개인정보 보호법) — 유럽연합 개인정보 보호법. 우리 회사가 한국에 있어도 EU 이용자를 대상으로 서비스하면 적용될 수 있다. 동의, 열람·삭제 요청권, 유출 시 72시간 내 감독기관 신고 등 한국법과 비슷한 축이 많다.
• 증거 남기기 — 규정 준수는 “했다”보다 “했다는 기록“이 중요하다: 동의 기록(누가·언제·무엇에), 접근 권한 부여·회수 기록(웹·앱 보안 10번 레슨 audit log), 파기 기록, 교육·점검 기록.
  • 비유: 식당 위생 점검. 실제로 깨끗한 것도 중요하지만, 점검원은 온도 기록표·소독 일지를 본다. 기록이 없으면 했다는 걸 증명할 수 없다.

지시 예문

• “우리 서비스의 실제 데이터 흐름(수집 항목, 저장 위치, 위탁 업체, 국외 이전 여부, 보유 기간)을 코드와 설정에서 추출해서 표로 만들어줘. 개인정보처리방침 초안의 근거로 쓸 거야.”
• “회원가입 필드 중 실제로 쓰지 않는 개인정보를 찾아서 제거하거나 선택 항목으로 바꾸고, 필수·선택 동의를 분리해줘.”
• “탈퇴 후 보유 기간이 지난 회원의 개인정보 컬럼을 실제로 삭제·익명화하는 정기 작업을 만들고, 파기 기록을 남기게 해줘.”
• “AI API에 고객 데이터를 보내는 기능들을 찾아서, 위탁·국외 이전으로 방침에 적어야 할 항목을 정리해줘.”