보안 가이드
비밀번호, MFA, 기기, 공용 Wi-Fi, 서버, 의존성, Git, 노출된 환경 — 오늘 바로 적용할 수 있는 방어책을 목표별로 정리한 실용 가이드입니다.
비밀번호를 안전하게 저장하는 법 — 올바른 해싱과 솔트
서버에 비밀번호를 안전하게 저장하는 실전 가이드. 평문·암호화·생 해시가 모두 실패하는 이유를 이해한 뒤 하나의 답으로 수렴합니다: 사용자별 솔트 + 의도적으로 느린 해시(Argon2id 권장, bcrypt/scrypt는 대안). 직접 만들지 말고 표준 함수를 쓰며, 시간이 지날수록 비용을 올리고, 약한 해시는 로그인 시 재해싱으로 이전하세요.
AI 시대의 보안: 지금 다잡아야 할 기본기 (우선순위 체크리스트)
AI는 새로운 약점을 만들기보다 기존 약점(패치 안 된 CVE, 재사용된 비밀번호, 노출된 시크릿)에 대한 공격을 주로 증폭한다 — 자동으로, 빠르게, 대규모로 찾아내며. 따라서 가장 좋은 대비는 기본기를 올바른 순서로 다잡는 것이다: CVE 패치 + 의존성 모니터링, 재사용 차단 + MFA, 노출 시크릿 제거, 최소 권한, 공개 표면 축소, 로그/IOC, 백업.
AI 시대 보안에서 통하는 것(과 통하지 않는 것) — 작은 사이트도 노려지는 이유
AI 시대의 네 가지 통념을 바로잡는다: (1) 너무 작아서 표적이 안 된다 → 자동화가 '사람이 고르는' 단계를 없앤다; (2) 특별한 새 통제가 필요하다 → 여전히 기본기가 이긴다; (3) 제품이 안전하게 해준다 → 탐지보다 예방 설계가 먼저; (4) AI 코드는 빠르니 안전하다 → 취약점과 함께 출시되니 공개 전 검토. 통하는 것은 올바른 순서의 지루한 기본기다.
피싱 메일이 자기 도메인을 위조했다? 스푸핑 vs 침해, 그리고 막는 법
자기 도메인에서 온 것처럼 보이는 수상한 메일은 보통 침해가 아니라 From 위조다 — SMTP가 누구나 From 줄을 쓰게 허용하기 때문. 헤더(Authentication-Results, Received, Reply-To)를 읽으면 침해와 위조를 구분할 수 있다. 받은편지함에 도달하는 주된 이유는 DMARC 정책 부재. SPF → DKIM → DMARC(p=none → reject) 순서로 고친다.
백업의 핵심: 3-2-1 규칙과 랜섬웨어를 견디는 복구 계획
'백업이 있다'로는 부족하다 — 복원할 수 있음을 검증한 백업만이 진짜다. 기본: 3-2-1 규칙(사본 3개, 매체 2종, 한 부는 외부). 랜섬웨어에는 '오프라인 또는 불변' 사본이 최소 하나 더 필요하다 — 늘 연결된 백업은 원본과 함께 암호화된다. 클라우드 동기화는 백업이 아니다(삭제와 암호화까지 복제한다). 버전 관리와 주기적 복원 테스트가 실천을 완성한다.
gitleaks로 커밋 전에 시크릿을 막아라: push 전에 API 키 유출 잡기
시크릿은 '유출된 뒤 삭제'할 수 없다. 한 번 커밋되면 Git 히스토리에 남고, push되면 유출된 것으로 다뤄야 한다 — 키를 폐기/교체해야 한다. gitleaks는 정규식/엔트로피로 저장소 전체와 커밋 히스토리를 스캔해 API 키, 개인 키, 토큰을 찾는 무료 도구다. 방어의 핵심은 두 관문: push 전에 로컬에서 막는 pre-commit 훅과, 빠져나간 것을 잡는 CI/cron. .gitignore는 새 추적만 막을 뿐 탐지하지 못하므로, 스캐너가 여전히 필요하다.
MFA를 제대로 고르기: '피싱 저항'이 무엇이고, SMS가 왜 약한가
MFA는 유출된 비밀번호만으로는 못 들어오게 하는 두 번째 잠금이다 — 하지만 무엇을 켜느냐에 따라 강도가 세 등급으로 갈린다. SMS/이메일 코드는 릴레이 피싱과 SIM 스왑에 무너지고, 인증 앱(TOTP)은 중간, 패스키/보안 키(FIDO2)는 가짜 사이트에 아예 제시될 수 없다 — 그것이 피싱 저항이다. 최우선: 왕국의 열쇠(이메일, 도메인, 결제)에 피싱 저항 MFA를. 복구 코드 저장과 백업 요소가 설정을 완성한다.
아직 Windows 10? 지원 종료 후 계속 쓸 때의 보안 위험
Windows 10은 2025년 10월 14일에 지원이 종료되었습니다. 계속 쓸 때의 핵심 위험은 새로 발견된 구멍이 영영 패치되지 않고(영구 데이) 쌓여 기기가 선호 표적이 되는 것입니다. 소비자 ESU는 2026년 10월 13일까지의 1년, 보안 전용 임시방편입니다(무료 등록 경로가 있지만, EEA의 무료 첫해는 대부분 지역에 적용 안 됨). 진짜 해법은 Windows 11로 옮기거나 하드웨어를 교체하는 것 — ESU는 이전이 끝날 때까지의 다리로만 쓰세요.
BitLocker vs '장치 암호화' — 같은 기술, 완전판 vs 자동 라이트판
BitLocker와 장치 암호화는 같은 암호화 엔진을 공유한다. 장치 암호화 = Home에서도 동작하는 자동·라이트판(Microsoft 계정으로 자동 켜짐, 복구 키 자동 위탁, 최소 옵션). BitLocker = Pro 이상의 완전판(시작 PIN, To Go로 외장 드라이브 암호화, 세밀한 제어). 개인에게는 자동으로 암호화되어 있고 복구 키 위치를 아는 것만으로 보통 충분하다. 이름보다 상태가 중요하다.
의존성 CVE를 제대로 고치기: 스캔, 수정, 격리, 그리고 계속 감시
취약점 작업은 '고쳤다'고 끝나는 게 아니다. 완료 = 1) 스캔, 2) 수정, 3) 격리/인계, 4) 모니터링. 모니터링(매일 변화 탐지)이 갖춰지기 전까지는 미완이다 — 의존성은 내일 다시 취약해진다. 다음 배포가 덮어쓰는 완벽한 수정은 가치가 0이다. 소규모 팀은 두 규율로 안전을 지킨다: 자동 변화 탐지와 '로컬→push→배포'.
들고 다니는 노트북 지키기 — 도난, 분실, 어깨너머 훔쳐보기 방어
노트북을 들고 다니면 언젠가 잃거나 도난당한다고 전제하라. 진짜 방어는 분실해도 내용이 새지 않게 설계하는 것이다: 디스크 암호화(BitLocker/FileVault), 짧은 자동 잠금이 있는 강한 로그인, 원격 삭제/위치 추적. HTTPS가 보편화돼 공용 Wi-Fi 도청은 우선순위가 낮고, 진짜 위협은 악성 AP, 어깨너머 훔쳐보기, 자리를 비우는 것이다. VPN을 과신하지 말고 — 먼저 기기를 단단히 하라.
osv-scanner 설치와 사용법: 의존성에서 CVE 찾아내기
osv-scanner는 락파일과 컨테이너를 스캔해 의존성의 CVE를 무료로 드러냅니다. 설치·실행·CI 연동을 짚고, npm/pnpm audit·Dependabot과 언제 쓸지도 비교합니다. 본 사이트의 견해: 올바른 도구는 당신의 환경이 결정합니다 — 다중 생태계나 GitHub 비사용 프로젝트엔 osv-scanner를, 단일 npm 트리엔 번들된 pnpm audit을.
비밀번호 관리자는 안전한가? 작동 원리, 클라우드 vs 로컬, 선택법
비밀번호 관리자는 재사용이나 평문 보관보다 안전합니다. 핵심은 제로 지식 암호화: 마스터 비밀번호가 당신의 기기에서만 금고를 복호화하고, 제공자는 암호문만 보관하므로 제공자 침해로도 비밀번호가 노출되지 않습니다. 진짜 단일 지점은 마스터 비밀번호 + 금고 MFA입니다. 용도에 따라 클라우드(Bitwarden/1Password)나 로컬(KeePass)을 고르세요.
공용 Wi-Fi의 위험 — 진짜 위험은 '도청'이 아니라 이블 트윈과 무시된 인증서 경고
공용 Wi-Fi '도청'은 HTTPS로 대부분 완화되어 이제 우선순위가 낮습니다. 진짜 위험은 (1) 이블 트윈 가짜 AP에 스스로 접속, (2) 인증서 경고 무시, (3) 공유 네트워크에 기기 노출입니다. 가장 강한 해법은 의외로 단순합니다 — 폰 테더링을 쓰고, HTTPS와 인증서 경고를 신뢰하고, 모르는 SSID에 자동 접속하지 마세요. VPN은 그다음 계층입니다.
공개 디렉터리에 시크릿 파일을 남겨두지 않았나요? 웹루트를 점검하라
웹루트의 모든 것은 누구나 URL로 가져갈 수 있습니다. 남겨진 토큰/자격증명 JSON, .env, 백업은 즉각 노출을 뜻하며 — 공유 템플릿에서 왔다면 모든 사이트가 같은 구멍을 갖습니다. 해법: 공개 디렉터리엔 공개해도 되는 것만, 시크릿은 웹루트 밖에 권한 600으로, 하나 찾으면 모든 사이트와 호스트를 점검하기.
1인 개발자와 소규모 운영자를 위한 보안 베이스라인: 표준 세트 전부
베이스라인은 '모두 똑같이 중요'가 아닙니다. 본 사이트의 우선순위: 1) 왕국의 열쇠(MFA, 도메인, 이메일), 2) 시크릿과 코드, 3) 앱 자체, 4) 패치·탐지·복구. 시간이 유한할 때 위에서부터 채우세요. 심각한 침해는 대부분 새로운 공격이 아니라 이 토대의 틈에서 옵니다.
중대규모 조직을 위한 보안 베이스라인: 팀을 위한 표준 토대
규모가 커지면 베이스라인은 '체크리스트'에서 '담당자가 있는 프로그램'으로 옮겨갑니다. 우선순위는 1인 버전과 같습니다: 1) 신원, 2) 시크릿과 공급망, 3) 앱과 인프라, 4) 탐지와 대응, 그리고 가로지르는 사람·거버넌스 계층. 큰 변화: 침해의 주원인이 실수에서 사람·프로세스·퇴직자 접근·제3자로 이동합니다.
보안 인벤토리 — 서버 여러 대를 운영하는 사람이 놓치는 7가지 점검
1인/소규모 운영자에게 사고는 통제의 부재보다 추적되지 않은 상태에서 옵니다. 경계는 키를 쥔 PC입니다. 신뢰의 뿌리로 2FA를 계층화하고, SSH 키를 매트릭스로 만들어 중복/미사용/고아를 죽이고, 클라우드의 평문 비밀번호를 제거하고, 한 번에 하나씩 되돌릴 수 있게 조치하고, 시크릿을 대장에 두지 마세요. 도구 추가 전에 인벤토리부터.
자체 호스팅 Git vs GitHub: 실제로 어느 쪽이 더 안전한가?
Git을 자체 호스팅한다고 '더 안전'해지지 않습니다 — 위험을 옮길 뿐입니다. 실수로 인한 공개 노출 부류는 사라지지만, 서버 패치·백업·커밋 전 시크릿 탐지가 당신에게 넘어옵니다. 그 대가를 치르면 옳은 선택이고, 방치하면 GitHub보다 나쁩니다. 본 사이트의 견해: 자체 호스팅은 보상 통제와 묶일 때만 작동합니다.
스마트폰 보안 기초 — 키, 금고, 신분증을 하나로 담은 기기를 지키기
폰은 2FA, 이메일, 뱅킹, 신분증을 하나의 단일 실패 지점에 집약합니다. 진짜 방어는 보안 앱이 아닙니다: (1) 강한 잠금 + 짧은 자동 잠금(암호가 암호화 키); (2) 자동 OS/앱 업데이트; (3) 공식 스토어 + 권한 검토; (4) 원격 잠금/초기화 사전 설정; (5) 2FA 백업 보관. iOS/Android는 이미 기본으로 암호화·샌드박스합니다.
침해될 수 있는 환경에 루트 키를 주지 마라: SSH 키 최소 권한
임시·침해 가능한 환경(GPU 파드, CI 러너, 일회용 VM)에서 프로덕션에 루트 키를 등록한다는 것은, 그 환경이 침해되는 순간 프로덕션이 루트로 통째로 넘어간다는 뜻입니다. 해법: 임시 환경에 루트 키 금지; 미사용 시 키 제거; 다시 필요하면 비루트 사용자 + 키를 한 작업으로 제한하는 명령 제한 키. 재사용 키는 가장 중요한 자산이니 — '한 번 누출, 전부' 구조를 절대 만들지 마세요.
비밀번호를 Google Drive에 저장하면 안전한가? 제대로 보관하는 법
비밀번호를 평문 Google 문서/시트에 두는 것은 위험합니다: Google 계정 하나가 모든 비밀번호의 단일 실패 지점이 됩니다 — 계정 탈취, 악성 연결 앱, 피싱이 한꺼번에 누출시킵니다. 해법은 전용 비밀번호 관리자입니다(동기화해도 내용은 암호화). Drive를 꼭 써야 한다면 암호화된 금고 파일만 저장하고 계정에 피싱 저항 MFA를 거세요.
OpenAI 계정이 정지되는 이유: 탈취된 API 키와 디스틸레이션 정책
탈취된 API 키가 '디스틸레이션'에 악용되면 피해자의 계정조차 자동 정지될 수 있습니다. 그 메커니즘과 예방, 이의 제기를 비식별화·방어적으로 정리한 가이드.
X-Forwarded-For(XFF) 스푸핑이란 — 신뢰 프록시 설정의 함정
XFF는 클라이언트가 위조 가능한 헤더입니다. 무차별 스캐너가 인젝션 탐침을 위조된 XFF에 숨기고, '모든 프록시 신뢰(와일드카드)'가 통과시킵니다. 패치 = 경계에서 IP 헤더 정제; 근본 수정 = 올바른 프록시(또는 없음)만 신뢰. 영향 0이라도 고칠 설정이 남았습니다.
AI가 작성한 코드에서 API 키가 유출돼 부정 과금이 발생했다 — 진짜 원인은 방치된 CVSS 10.0
요금 급증은 증상이었다. 진짜 원인은 패치되지 않은 공개 CVSS 10.0 RCE였다. 익명화한 사례를 방어 교훈으로 정리한다.
보안 기본: .env와 API 키의 진짜 위험은 무엇인가
여기서 시작하라. .env와 API 키가 유출되면 무슨 일이 일어나는지(여분 키 → 사칭 → 부정 과금) 이해한 뒤, 오늘 네 가지 습관을 들이라: 노출하지 말 것, 커밋하지 말 것, 유출되면 전부 교체할 것, 스스로 점검할 것.
Laravel 앱의 .env가 온 세상에 읽혔다 — 가장 흔한 공유 호스팅 실수
원인: 앱 전체가 웹 루트 아래 있었다 — public/만 보여야 한다. 세 단계로 고친다 — .htaccess 응급 처치, 키 교체, 구조 재배치 — 그리고 프로세스로 재발을 막는다.
Next.js를 안전하게 운영하기: 공개된 CVE에 뒤처지지 않기
프레임워크 최대 위험은 방치된 공개 CVE다. 네 기둥으로 방어한다: 가동 중인 버전으로 판단, Dependabot/osv-scanner로 모니터링, 빠른 업데이트, 최소 권한 운영. 본 사이트의 견해: 인디 개발자는 지식이 아니라 운영의 연속성에서 진다 — 속도가 아니라 놓치지 않는 시스템으로 이긴다.
공유 호스팅에서 .env를 공개 웹에 노출하지 않기
진짜 해법: 앱 본체를 docroot 밖에, public/만 노출. .htaccess로 출혈을 멈추고, 재구성으로 영구화한 뒤, 자가 점검. 본 사이트의 견해: 이건 한 사람의 실수가 아니라 업계 표준이 된 나쁜 패턴 — 경계심이 아니라 프로세스로 고치세요. bootstrap-redirect가 심링크를 이깁니다.