침해를 가정하라: 로깅·탐지·사고대응부터 랜섬웨어 막는 3-2-1 백업까지 웹 보안 실전 가이드

보안에서 가장 위험한 착각은 "우리는 안 뚫린다"입니다. 충분한 시간과 동기를 가진 공격자 앞에서 완벽한 방벽은 존재하지 않습니다. 그래서 성숙한 운영은 질문을 바꿉니다. "뚫릴 것인가"가 아니라 "뚫렸을 때 얼마나 빨리 알아채고, 얼마나 멀쩡히 되살아날 것인가" 입니다.

예방은 침해의 확률을 낮춥니다. 포트를 닫고, 인증을 강화하고, 통신을 암호화하고, 애플리케이션 취약점을 막는 일은 전부 필수입니다. 하지만 예방을 아무리 잘해도 0이 되지는 않습니다. 매주 새 취약점이 공개되고, 공격은 자동화·대량화되며, 사소한 설정 실수 하나가 연쇄의 시작점이 됩니다. 침해를 가정하라(assume breach) 는 예방을 포기하라는 말이 아니라, 예방을 다 한 뒤에도 "그럼에도 뚫렸다면"을 미리 준비해 두라는 뜻입니다.

이 글은 침해를 가정한 운영 방어를 다섯 갈래로 정리합니다. 무엇을 기록할 것인가(로깅), 어떻게 알아챌 것인가(모니터링·탐지), 알아챈 뒤 무엇을 할 것인가(사고 대응), 그리고 최악의 경우에도 어떻게 되살아날 것인가(백업·복구)입니다. 마지막 백업 파트는 랜섬웨어 시대의 가장 강력한 생존 전략이라 비중 있게 다룹니다. 1인 운영자도 오늘 당장 따라 할 수 있도록, 복사해 쓸 수 있는 명령과 체크리스트를 함께 실었습니다.

체류 시간: 피해 규모를 결정하는 단 하나의 숫자

침해 대응에서 가장 중요한 지표를 하나만 꼽으라면 체류 시간(dwell time) 입니다. 공격자가 시스템에 침입한 순간부터 발각되기까지, 즉 "들키지 않고 머문" 기간을 말합니다.

이 숫자가 왜 결정적일까요. 침해의 피해 규모는 체류 시간에 거의 정비례하기 때문입니다. 같은 침입이라도 하루 만에 잡으면 가벼운 사고로 끝나지만, 200일을 방치하면 데이터가 전부 빠져나간 뒤일 수 있습니다. 표적형 공격(APT)이 노골적으로 "오래 조용히 머무는 것"을 목표로 삼는 이유가 여기에 있습니다. 머무는 시간이 길수록 더 깊이 침투하고, 더 많이 빼내고, 더 큰 피해를 줄 수 있으니까요.

현실의 침해 사고를 따라가 보면 뼈아픈 패턴이 반복됩니다. 침입은 수개월, 때로는 수년간 탐지되지 않은 채 진행되고, 정작 본인은 외부(고객·결제사·수사기관)가 알려 줘서야 사고를 인지합니다. 해마다 침해 통계를 정리하는 Verizon 데이터 침해 조사 보고서(DBIR)가 반복해서 확인해 주는 사실이 바로 이것 — 스스로 탐지하지 못하고 외부 통보로 알게 되는 경우가 여전히 많다는 점입니다. 이것은 예방의 실패가 아니라 탐지의 실패 입니다.

입구는 대개 거창하지 않습니다. 패치가 이미 나와 있는 알려진 취약점(n-day)으로 조용히 들어오는 경우가 많습니다. 대표적으로 파일 전송 솔루션의 MOVEit Transfer 취약점(CVE-2023-34362)은 패치 공개 이후에도 미적용 시스템을 통해 조용히 침투해, 한참 뒤 대량의 데이터가 외부에 풀리고 나서야 발각된 사례가 적지 않았습니다. 모든 입구를 다 막지 못하더라도, 들어온 흔적을 빨리 보는 것 — 그것이 침해 대응의 전부라고 해도 과언이 아닙니다.

그리고 탐지에는 절대 조건이 있습니다. 기록되지 않은 것은 탐지할 수 없다. 시스템에서 무슨 일이 벌어지는지 볼 수 없으면, 이상한 일이 벌어져도 알 길이 없습니다. 그래서 탐지의 첫걸음은 언제나 로깅입니다.

무엇을 기록할 것인가: 보안에 의미 있는 사건

로깅은 단순한 디버깅 도구가 아닙니다. 탐지의 토대이고, 침해 후 "무슨 일이 있었는지"를 재구성하는 단서이며, 책임을 추적하는 근거입니다. 모든 것을 기록할 필요는 없습니다. 핵심은 보안상 의미 있는 사건 을 빠짐없이 남기는 것입니다.

가장 먼저 손이 가야 할 곳은 인증 로그 입니다. 리눅스라면 보통 다음 두 군데에 남습니다.

# 데비안/우분투 계열
sudo tail -n 200 /var/log/auth.log

# systemd 환경(배포판 무관) — SSH 인증 이력만 모아 보기
sudo journalctl -u ssh --since "yesterday" | grep -Ei "failed|invalid|accepted"

성공한 로그인만 보면 안 됩니다. 정작 중요한 건 실패한 시도, 특히 비정상적인 패턴의 실패 입니다. "어제 새벽 낯선 나라 IP에서 root 계정으로 수백 번 시도가 있었다" 같은 신호는 실패 로그에만 남습니다. 반복 실패 IP를 자동 차단하는 fail2ban도 결국 이 인증 로그를 읽어 동작하므로, 같은 로그를 사람이 가끔 들여다보는 것만으로도 공격의 전조를 잡을 수 있습니다.

# fail2ban이 실제로 무엇을 차단하고 있는지 한눈에 보기
sudo fail2ban-client status sshd

좋은 로그의 네 가지 조건

기록한다고 다 쓸모 있는 로그가 되는 건 아닙니다. 다음 네 가지를 갖춰야 나중에 실제로 단서가 됩니다.

1. 충분한 맥락. 각 항목은 "언제, 누가/무엇이, 무엇을, 어디서" 했는지를 담아야 합니다. 맥락이 빠진 로그는 사고 당일 아무 의미가 없습니다.

2. 민감 정보 배제. 역설적이지만 로그 자체가 위험이 될 수 있습니다. 비밀번호·토큰·키·개인정보가 평문으로 로그에 찍히면, 로그가 유출될 때 그것들도 함께 샙니다. 요청 본문이나 쿼리 파라미터를 통째로 로깅하는 습관은 특히 위험합니다.

3. 로그의 무결성. 공격자는 침입하면 흔적부터 지웁니다. 이건 즉흥적 행동이 아니라, 공격자 행동을 체계적으로 정리한 MITRE ATT&CK에 흔적 제거(Indicator Removal, T1070) 라는 이름으로 분류돼 있을 만큼 정형화된 단계입니다. 그래서 로그는 공격자가 쉽게 손댈 수 없는 곳, 즉 로그를 생성하는 시스템과 분리된 곳 에 한 벌 더 보관해야 합니다.

4. 충분한 보존 기간. 침해는 뒤늦게 발견되는 일이 흔하므로, 발견 시점에서 침입 시작점까지 거슬러 올라갈 수 있을 만큼 로그를 오래 보존해야 합니다.

지금 당장 할 일 한 가지. 1인 운영이라도 딱 하나만 먼저 하십시오 — 웹 서버·인증 로그를 운영 서버 바깥으로 한 벌 복사해 두는 것. 다른 호스팅의 저장소든, 권한이 분리된 객체 스토리지든, 운영 시스템을 장악한 공격자의 손이 그 사본에 닿지 않으면 됩니다. 침해를 알아챈 순간, 변조되지 않은 그 사본 한 벌이 "무슨 일이 있었는지"를 재구성하는 거의 유일한 단서가 됩니다.

리눅스의 auditd를 켜 두면 권한·접근·파일 변경 같은 시스템 수준 사건을 커널에서 직접 기록할 수 있습니다. 응용 로그보다 변조가 어렵다는 장점이 있습니다.

# auditd 설치·활성화 (데비안/우분투)
sudo apt-get install -y auditd
sudo systemctl enable --now auditd

# 예: /etc/passwd 변경과 권한 상승 추적 규칙
sudo auditctl -w /etc/passwd -p wa -k identity
sudo auditctl -a always,exit -F arch=b64 -S execve -F euid=0 -k root_cmd

로그를 살아 있게 만들기: 모니터링과 탐지

로그를 남기는 건 시작일 뿐입니다. 사람이 매일 수만, 수십만 줄을 일일이 읽을 수는 없으니, 그중에서 주의가 필요한 것만 골라내는 모니터링이 필요합니다. 무엇을 골라내야 할까요.

• 알려진 공격 패턴 — 이미 알려진 공격의 서명이나 시도가 나타나는지.
• 이상 징후(anomaly) — 평소와 다른 패턴. 비정상 시간대 접근, 낯선 위치에서의 로그인, 갑작스러운 대량 데이터 조회, 평소 없던 권한 사용. "정상"을 알아야 "비정상"이 보이므로, 평소의 정상 패턴을 미리 파악해 두는 것이 핵심입니다.
• 무결성 변화 — 변하지 않아야 할 것이 변했는지. 중요한 시스템 파일, 설정 파일, 웹 콘텐츠가 예상치 못하게 바뀌면 그 자체가 침해 신호입니다.
• 예상치 못한 변화 — 새 포트가 열리거나, 낯선 프로세스가 뜨거나, 모르는 사용자가 추가되면 무조건 점검 대상입니다.

파일 무결성 모니터링(FIM)

무결성 변화 감시는 침입자가 심어 둔 웹셸·백도어·변조된 바이너리를 잡아내는 강력한 방법입니다. 정상 상태의 "지문"을 떠 두고, 주기적으로 현재 상태와 비교하는 방식입니다. 오픈소스 AIDE가 대표적입니다.

# AIDE 설치 후, 깨끗한 상태에서 기준 DB 생성
sudo apt-get install -y aide
sudo aideinit
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# 이후 정기적으로(예: 매일 cron) 변경 여부 점검
sudo aide --check

손쉽게 시작하려면 핵심 디렉터리의 체크섬을 떠 두고 비교하는 것만으로도 1차 방어가 됩니다.

# 웹 루트의 현재 지문 생성
find /var/www -type f -exec sha256sum {} \; | sort > /root/webroot.sha256.base

# 나중에 변조 여부 확인 — 출력이 있으면 무언가 바뀐 것
find /var/www -type f -exec sha256sum {} \; | sort | diff - /root/webroot.sha256.base

예상치 못한 포트·프로세스·사용자 변화도 한 줄로 빠르게 점검할 수 있습니다.

ss -tulnp                              # 열린 포트와 바인딩 프로세스
ps aux --sort=-%cpu | head             # 비정상적으로 자원을 먹는 프로세스
awk -F: '$3>=1000 {print $1}' /etc/passwd   # 일반 사용자 계정 목록 점검

알림의 균형: 경보 피로를 피하라

모니터링의 진짜 어려움은 기술이 아니라 균형 입니다. 너무 많이 알리면 알림이 홍수가 되어 둔감해지고(경보 피로, alert fatigue), 정작 중요한 신호를 흘려보냅니다. 너무 적게 알리면 놓칩니다. 그래서 심각도에 따라 차등 을 두는 것이 정석입니다.

자동화와 AI는 1차 분류까지

대량의 로그에서 이상 패턴을 1차로 추려 내는 일은 자동화와 AI가 잘 돕는 영역입니다. 사람이 모든 로그를 읽는 불가능한 일을 "사람이 검토할 것만 추려 주는" 가능한 일로 바꿔 줍니다. 다만 두 가지 한계를 기억해야 합니다. 첫째, 로그에는 민감 정보가 섞일 수 있으므로 외부 서비스로 보낼 때 신중 해야 합니다. 둘째, AI의 1차 분류는 사람의 판단을 보조할 뿐 대체하지 않습니다. 최종 판단은 언제나 사람의 몫입니다.

사고 대응(IR): 알아챈 다음에 무엇을 하는가

탐지가 "알아채는 것"이라면, 사고 대응(incident response, IR)은 "알아챈 다음에 하는 일"입니다. 침해의 순간은 혼란스럽고 압박이 큽니다. 그 순간 무엇을 할지 미리 정해 두지 않으면, 당황 속에서 증거를 지우거나, 성급히 전원을 내려 공격자를 자극하는 식의 잘못된 결정을 내리기 쉽습니다.

IR 자료, 어디서 보나. "전담 보안팀이 없으면 IR은 불가능한 것 아닌가" 싶겠지만, 작은 조직이 그대로 따라 할 수 있는 무료 기본 절차가 공개돼 있습니다. 미국 CISA는 사고 대응의 단계별 가이드와 점검표를 무료로 제공합니다. 지금 사고가 난 게 아니어도, 한 번 훑어보고 우리 상황에 맞게 한 페이지짜리 "첫 대응 메모"로 줄여 두는 것만으로 충분합니다.

핵심 원칙: 불나기 전에 소화기 위치를 알아 둬라

사고 대응의 제1원칙은 사고가 나기 전에 준비하는 것 입니다. 불이 난 뒤에 소화기를 찾으면 늦습니다. 미리 정해 둘 것은 다음과 같습니다.

• 침해 의심 시 누가 무엇을 하는지에 대한 기본 계획
• 중요한 연락처와 의사결정 경로(누구에게 보고하고 누가 결정하는가)
• 대응에 필요한 자원과 접근 권한
• 무엇보다 검증된 백업(아래에서 자세히)

대응의 기본 흐름

구체적 절차라기보다 사고를 바라보는 틀로 이해하십시오.

특히 제거·복구 단계에서 흔한 함정이 하나 있습니다. 백업으로 깨끗이 되돌리고 안심하는 것입니다. 그러나 애초에 침입을 허용한 취약점을 그대로 두면, 복구한 시스템은 같은 수법으로 곧장 다시 뚫립니다. 복구는 "되돌리기"가 아니라 "되돌린 뒤 구멍 막기"까지가 한 세트입니다.

신고와 법적 의무

개인정보가 관련된 침해라면 법적 신고 의무 가 있을 수 있습니다. 한국을 비롯한 많은 국가가 일정 규모 이상의 개인정보 유출에 대해 당국과 정보 주체에게 신고하도록 규정합니다. 국내에서는 KISA 보호나라가 침해사고 신고 창구와 대응 안내를 운영하므로, 신고처와 절차를 평상시에 미리 확인해 두십시오. 구체적 의무는 상황과 관할에 따라 다르므로, 필요하면 전문가의 조언을 받는 것이 안전합니다.

백업과 복구: 랜섬웨어 시대의 최강 방어

이제 가장 실용적이고, 어쩌면 가장 중요한 부분입니다. 랜섬웨어에 대한 가장 강력한 방어는 역설적으로 침입을 막는 것이 아니라 백업 입니다.

왜 백업이 협박을 무력화하는가

랜섬웨어는 데이터를 암호화해 못 쓰게 만든 뒤 몸값을 요구합니다. 협박이 통하는 이유는 단 하나, 피해자가 그 데이터를 잃을 수 없기 때문 입니다. 그런데 깨끗한 백업이 있어서 암호화된 데이터를 버리고 복구할 수 있다면? 몸값을 낼 이유가 사라집니다. 협박의 힘 자체가 무너집니다.

이것이 "침해를 가정하라"의 가장 구체적인 실천입니다 — "뚫릴 수 있다. 하지만 뚫려도 데이터는 잃지 않는다." 게다가 백업은 랜섬웨어뿐 아니라 하드웨어 고장, 실수로 인한 삭제, 자연재해, 파괴적 공격까지 모든 데이터 손실에 대한 보험입니다. 적은 노력으로 이만한 회복력을 주는 방어는 드뭅니다.

3-2-1 규칙

백업의 고전이자 검증된 원칙은 3-2-1 규칙 입니다.

이 규칙의 정신은 단 하나, 단일 실패점을 없애는 것 입니다. 어떤 하나의 사고로도 모든 사본을 동시에 잃지 않도록 분산하는 것입니다.

현대적 핵심: 백업도 노려진다

여기서 2026년 현재 가장 중요한 점을 강조합니다. 정교한 랜섬웨어는 데이터를 암호화하기 전에 먼저 백업을 찾아 파괴 하려 합니다. 백업이 있으면 피해자가 돈을 내지 않을 것을 알기 때문입니다. Verizon DBIR가 해마다 확인해 주듯 랜섬웨어는 지금도 침해의 주된 동기로 남아 있고, 앞서 본 MOVEit(CVE-2023-34362) 사건의 Cl0p처럼 조직화된 집단이 같은 수법을 대량으로 돌립니다.

그래서 단순히 백업을 "가지는 것"을 넘어 백업 자체를 공격으로부터 보호 해야 합니다. 핵심 원칙은 이것입니다 — 침해된 시스템에서 백업을 쉽게 접근하거나 삭제할 수 없어야 한다. 백업이 운영 시스템과 같은 네트워크에, 같은 권한으로 닿는 곳에 있으면, 운영 시스템을 장악한 공격자가 백업까지 함께 지웁니다.

따라서 백업은 다음 중 하나 이상의 형태여야 강력합니다.

• 불변(immutable) 백업 — 한 번 기록되면 보존 기간 동안 변경·삭제 불가. 객체 스토리지의 오브젝트 잠금(Object Lock)이 대표적.
• 오프라인(air-gapped) 백업 — 운영 시스템에서 물리적·논리적으로 끊겨 있어 원격에서 손댈 수 없는 형태.
• 권한 분리 — 운영 서버의 자격 증명만으로는 백업 저장소를 삭제할 수 없도록 별도 권한 체계 적용.

이것이 3-2-1의 "off-site"가 단순한 물리적 거리를 넘어 "공격자의 손이 닿지 않는 분리" 를 의미하는 현대적 이유입니다.

오픈소스 백업 도구로 이 원칙을 구현하는 예시입니다. restic은 객체 스토리지에 직접 백업하고, 저장소 쪽에 잠금/보존 정책을 걸어 불변성을 확보할 수 있습니다.

# restic: 객체 스토리지 저장소 초기화 (한 번만)
export RESTIC_REPOSITORY="s3:https://s3.example.com/my-immutable-bucket"
export RESTIC_PASSWORD="<강력한-저장소-암호>"
restic init

# DB 덤프 + 업로드 디렉터리를 함께 백업
mysqldump --single-transaction --routines mydb > /tmp/db.sql
restic backup /tmp/db.sql /var/www/uploads

# 오래된 스냅샷 정리 정책(보존 정책)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

저장소를 담는 버킷 자체에 오브젝트 잠금(WORM) 과 버전 관리를 켜 두면, 운영 서버가 장악돼도 보존 기간 안의 백업은 누구도 삭제할 수 없습니다. 운영 서버에는 "쓰기"만 가능하고 "삭제"는 불가능한 별도 키를 발급하는 것이 핵심입니다.

검증되지 않은 백업은 백업이 아니다

마지막으로 가장 흔하고 뼈아픈 실수를 강조합니다 — 백업을 만들기만 하고, 실제로 복구되는지 확인하지 않는 것 입니다.

백업이 존재한다는 사실과, 그 백업으로 실제 복구가 된다는 사실은 전혀 다릅니다. 백업이 손상됐을 수도, 불완전할 수도, 복구 절차에 문제가 있을 수도 있습니다. 그리고 이걸 발견하는 최악의 순간은 정확히 백업이 진짜로 필요한 재난의 순간 입니다. 그때 작동하지 않으면, 백업이 없는 것과 똑같습니다.

현장에서 가장 자주 보는 실패가 바로 이것입니다. 백업은 매일 도는데, 막상 복구해 보면 데이터베이스 덤프가 절반에서 잘려 있거나, 사용자 업로드 파일은 백업 대상에서 통째로 빠져 있는 경우입니다. 새 서버를 인수하면 가장 먼저 "복구가 되는지"부터 한 번 돌려 보는 이유가 여기 있습니다. 백업 화면의 초록색 체크가 아니라, 빈 환경에 실제로 되살려 서비스가 떠야 비로소 "백업이 있다"고 말할 수 있습니다.

# 복구 리허설: 빈 환경에 restic 스냅샷을 실제로 풀어 본다
restic snapshots                       # 어떤 시점이 있는지 확인
restic restore latest --target /tmp/restore-test

# 복원한 DB 덤프가 온전한지(잘리지 않았는지) 실제로 불러 본다
mysql -e "CREATE DATABASE restore_check"
mysql restore_check < /tmp/restore-test/tmp/db.sql && echo "DB 복원 OK"

이번 분기에 딱 한 번 할 일. 백업에서 빈 환경으로 실제 복원을 해 보십시오. 데이터베이스가 다 들어오는지, 사용자 업로드 파일과 설정까지 함께 살아나는지, 서비스가 정상으로 뜨는지를 눈으로 확인하면 됩니다. 이 한 번의 리허설이 진짜 재난의 순간에 "백업이 있었는데 안 됐다"는 최악의 상황을 막아 줍니다.

침해를 가정한 운영 체크리스트

지금까지의 내용을 그대로 복사해 쓸 수 있는 점검 목록으로 압축했습니다.

• 의미 있는 사건 로깅 — 인증·권한·접근·애플리케이션·시스템 사건을 충분한 맥락과 함께 기록
• 로그에서 민감 정보 배제 — 비밀번호·토큰·키·개인정보가 평문으로 찍히지 않는지 확인
• 로그 분리 보관 — 운영 서버 바깥에 무결한 사본 한 벌, 충분한 보존 기간 확보
• 인증 실패 모니터링 — 무차별 대입·비정상 로그인 패턴 감시, fail2ban 등 자동 차단
• 파일 무결성 모니터링 — AIDE 등으로 웹 루트·설정·바이너리 변조 감지
• 예상치 못한 변화 점검 — 새 포트·낯선 프로세스·모르는 사용자 추가 여부
• 알림 차등화 — 즉시 대응/검토 필요/단순 기록으로 나눠 경보 피로 방지
• 사고 대응 메모 준비 — 첫 단계로 무엇을 할지, 보고·결정 경로, 신고처를 1페이지로
• 3-2-1 백업 — 사본 셋, 매체 둘, 한 벌은 분리된 곳에
• 백업의 공격 분리 — 불변/오프라인/권한 분리로 침해 시스템에서 삭제 불가하게
• 복구 정기 검증 — 분기마다 빈 환경에 실제 복원해 서비스가 뜨는지 확인

자주 묻는 질문 (FAQ)

Q. 전담 보안팀도 SIEM도 없는 1인 운영입니다. 무엇부터 해야 하나요? 우선순위는 명확합니다. 첫째, 웹 서버·인증 로그를 운영 서버 바깥에 한 벌 복사해 두십시오(분리 보관). 둘째, fail2ban으로 인증 실패를 자동 차단하고 그 로그를 가끔 직접 들여다보십시오. 셋째, 3-2-1 규칙으로 백업하고 이번 분기에 한 번 실제 복구를 해 보십시오. 이 세 가지만 갖춰도 "탐지 못 함 + 복구 못 함"이라는 최악의 조합은 피할 수 있습니다. 거창한 도구보다 이 기본기가 먼저입니다.

Q. 체류 시간(dwell time)을 실제로 어떻게 줄이나요? 줄이는 것은 결국 "더 빨리 알아채는 것"입니다. 핵심은 두 가지입니다. 우선 평소의 정상 패턴을 알아 두는 것 — 정상을 알아야 비정상이 눈에 띕니다. 그리고 정말 중요한 사건(관리자 계정 다중 실패 후 성공, 웹 루트 변조, 신규 사용자 추가 등)만 즉시 알림으로 빼내, 경보 피로 없이 이상 신호가 사람에게 곧장 닿게 하는 것입니다. 모든 것을 알리면 아무것도 못 보고, 아무것도 안 알리면 외부 통보로만 알게 됩니다.

Q. 침해를 발견했습니다. 곧바로 서버 전원을 내려야 하나요? 성급한 차단은 오히려 위험할 수 있습니다. 전원을 내리면 메모리 상의 증거가 사라지고, 공격자가 눈치채고 더 파괴적으로 행동하거나 백도어를 추가로 심을 수 있습니다. 순서는 확인·분류 → 격리·차단 → 증거 보전입니다. 네트워크에서 격리해 확산을 막되, 흔적은 성급히 지우지 말고 무결한 로그를 확보한 다음, 백도어 제거와 함께 반드시 침입을 허용한 취약점까지 고친 뒤 복구하십시오. 취약점을 안 고치고 복구하면 같은 길로 다시 뚫립니다.

Q. 매일 백업을 돌리고 있는데, 그래도 안심하면 안 되나요? 안심하기 이릅니다. 가장 흔한 실패가 "백업은 도는데 복구가 안 되는" 경우입니다 — DB 덤프가 중간에 잘려 있거나, 업로드 파일이 대상에서 빠져 있는 식입니다. 백업 화면의 초록색 체크는 "파일을 만들었다"는 뜻이지 "복구된다"는 보장이 아닙니다. 분기마다 한 번, 빈 환경에 실제로 복원해 데이터베이스·업로드·설정이 함께 살아나고 서비스가 정상으로 뜨는지를 눈으로 확인하십시오. 검증되지 않은 백업은 백업이 아니라 희망일 뿐입니다.

Q. 랜섬웨어가 백업까지 지운다는데, 백업을 어떻게 지켜야 하나요? 백업이 운영 시스템과 같은 네트워크에 같은 권한으로 닿는 곳에 있으면, 운영 서버를 장악한 공격자가 백업도 함께 파괴합니다. 그래서 백업은 침해된 시스템에서 삭제할 수 없는 형태여야 합니다. 객체 스토리지의 오브젝트 잠금(WORM)으로 불변 백업을 만들거나, 오프라인(air-gapped)으로 보관하거나, 운영 서버에는 "쓰기만 되고 삭제는 안 되는" 별도 키를 주는 식의 권한 분리가 핵심입니다. 3-2-1 규칙의 "off-site"를 단순한 거리가 아니라 "공격자 손이 닿지 않는 분리"로 해석해야 합니다.

원문 출처 및 더 알아보기

이 글은 (주)뎁팀 웹 보안팀이 운영하는 보안 가이드 사이트 SGAEPS(시그앱스)의 가이드를 바탕으로 재구성했습니다. 더 깊은 원문은 SGAEPS 가이드 원문에서 확인하실 수 있습니다.

웹 보안 점검·긴급 대응이 필요하시면 DevTeam의 웹 긴급지원 또는 개발/보안 문의를 이용해 주세요.