네트워크 보안 실전 가이드: 공유기·카페 와이파이·중간자 공격(MITM)에서 내 데이터를 지키는 법

카페에 앉아 노트북을 열고, 익숙한 이름의 와이파이에 무심코 연결합니다. 그런데 그 와이파이, 정말 카페가 띄운 것이 맞을까요? 같은 사무실 네트워크에 앉아 있는 옆자리 동료의 노트북은, 정말 "내 편"일까요? 이 질문이 불편하다면, 당신은 이미 네트워크 보안의 핵심을 절반쯤 이해한 것입니다.

우리는 서버를 지키는 이야기는 많이 합니다. 방화벽, 패치, TLS, 접근 권한. 그런데 정작 매일 자신이 올라타는 네트워크 그 자체가 공격의 무대가 될 수 있다는 사실은 자주 잊습니다. 집 공유기, 회사 사내망, 카페 공용 와이파이 — 이 세 곳 모두가 누군가에게는 침투 경로입니다.

이 글은 "네트워크 안에 있으면 안전하다"는 오래된 믿음을 해체하는 데서 출발합니다. 결론부터 말하면 이렇습니다. 같은 네트워크를 공유한다는 것은, 신뢰를 공유한다는 뜻이 아닙니다. 아래에서 공유기 보안, 중간자 공격, 가짜 와이파이, 같은 네트워크 안의 위협, 그리고 개발자 컴퓨터라는 특별한 표적을 차례로 짚고, 각 항목마다 복붙해서 바로 쓸 수 있는 점검 항목을 정리합니다.

"네트워크 안쪽"은 안전지대가 아니다

전통적인 보안 모델은 네트워크를 성벽으로 그렸습니다. 바깥은 위험하고, 성벽 안(사내망, 내 와이파이)은 안전하다는 그림입니다. 이 그림에서 방어란 곧 "성문을 잘 지키는 것"이었습니다.

문제는 이 그림이 틀렸다는 데 있습니다. 성벽 안에 누가 들어와 있는지, 그리고 그 성벽이 정말 내가 생각하는 그 성벽인지를 우리는 확신할 수 없습니다. 그래서 현대 보안은 위치를 신뢰의 근거로 삼지 않습니다. "이 IP는 사내망이니까 통과"가 아니라 "로그인한 이 사람이 본인이 맞으니까 통과"로 판단합니다. 네트워크 위치가 아니라 신원으로 검증한다는 이 원칙을 흔히 Zero Trust라고 부릅니다.

네트워크 계층에서 이 원칙이 왜 필요한지는, 실제 위협을 하나씩 보면 분명해집니다. 정리하면 위협은 대략 이렇게 나뉩니다.

이제 위에서부터 하나씩 풀어 보겠습니다.

공유기: 가장 중요한데 가장 방치되는 장치

집이든 사무실이든, 당신이 보내고 받는 모든 인터넷 트래픽이 가장 먼저 지나는 관문이 공유기(라우터)입니다. 그런데 역설적이게도, 보안에서 가장 자주 잊히는 장치 역시 공유기입니다.

공유기 하나가 무너지면 전부가 무너진다

공유기는 당신의 네트워크와 바깥 인터넷 사이에 선 문지기입니다. 노트북, 휴대폰, 사무실이라면 모든 직원의 기기까지 — 전부 이 한 대를 통해 바깥과 연결됩니다. 그러니 논리는 단순합니다. 공유기가 장악당하면, 그 공유기를 지나는 모든 트래픽이 통째로 위험해집니다.

공유기를 손에 넣은 공격자가 할 수 있는 일을 늘어놓아 보면 섬뜩합니다. 트래픽을 엿보고, DNS를 조작해 가짜 사이트로 유도하고, 페이지에 악성 코드를 끼워 넣고, 네트워크 안의 모든 기기를 다음 공격의 발판으로 삼습니다. 바깥에서나 가능하다고 여겼던 위협들이, 공유기 장악 한 번으로 네트워크 안쪽에서 벌어지게 됩니다.

펌웨어 — 공유기에도 운영체제가 있다

공유기도 결국 소프트웨어로 돌아갑니다. 이 소프트웨어를 펌웨어(firmware)라고 부릅니다. 그리고 일반 소프트웨어에 적용되는 모든 보안 상식이 펌웨어에도 똑같이 적용됩니다. 펌웨어에도 취약점(CVE)이 발견되고, 그 취약점을 노린 자동화 공격이 인터넷을 끊임없이 훑습니다.

진짜 문제는 빈도입니다. 사람들은 서버는 패치해도 공유기는 한 번 설치하면 몇 년을 잊습니다. 그 사이 펌웨어에는 심각한 결함이 쌓여 가고, 패치가 나와도 적용되지 않은 채 방치됩니다. 이것이 바로 n-day 위험 — 고칠 방법(패치)이 이미 공개됐는데도 적용하지 않아서 생기는 위험 — 의 전형입니다.

서버 쪽 사례지만 Citrix Bleed(CVE-2023-4966)가 좋은 예시입니다. 패치가 이미 배포됐는데도 적용하지 않은 탓에 대규모 침해로 번졌습니다. 공유기는 바로 이 "패치는 있는데 아무도 누르지 않는" 상태에 가장 오래, 가장 흔하게 머무는 장치입니다. 실제로 어떤 장비가 알려진 취약점을 안은 채 인터넷에 노출돼 있는지는 CISA의 실제 악용 목록(KEV)에서 볼 수 있는데, 이 목록에는 가정·소호용 공유기와 IoT 장비가 단골로 오릅니다. 대규모 봇넷의 상당수가 패치되지 않은 공유기와 IoT 기기로 이루어진다는 점도 기억할 만합니다. 당신의 방치된 공유기가, 지금 이 순간 자기도 모르게 봇넷의 일부가 되어 어딘가를 공격하고 있을 수도 있습니다.

공유기 보안 체크리스트

원칙만 늘어놓으면 와닿지 않으니, 그대로 따라 할 수 있는 점검 목록으로 정리합니다.

• 펌웨어를 최신으로 유지한다. 제조사가 업데이트를 제공하는지 확인하고 정기적으로 적용한다. 더 이상 업데이트가 나오지 않는 오래된 공유기는 누적된 취약점 덩어리이므로 교체를 고려한다.
• 기본 관리자 비밀번호를 바꾼다. 공유기는 알려진 기본 비밀번호를 단 채 출고된다. 그대로 두면 공격자가 기본값만으로 관리 화면에 들어온다. 반드시 강한 것으로 교체한다.
• 관리 인터페이스를 인터넷에 노출하지 않는다. 원격 관리 기능이 켜져 있으면 관리 화면이 전 세계를 향한 표적이 된다. 꼭 필요하지 않다면 끈다.
• 강한 와이파이 암호화를 쓴다. 보안 방식을 WPA3(없으면 최소 WPA2)로 설정하고, 이미 깨진 WEP·WPA(1세대)는 끈다. 와이파이 비밀번호도 충분히 길고 강하게 잡는다.
• 불필요한 기능을 끈다. 안 쓰는 부가 기능은 그 자체가 공격면이다. 특히 내부 장치가 알아서 외부 포트를 여는 UPnP는, 의도치 않은 노출을 만들 수 있으니 쓰지 않는다면 비활성화한다.
• 게스트 네트워크를 분리한다. 방문자나 신뢰하지 않는 기기는 게스트망에 두어 주 네트워크와 떼어 놓는다.

내 공유기가 바깥에 무엇을 열어 두고 있는지 궁금하다면, Shodan에 자신의 공인 IP를 넣어 검색해 보십시오. Shodan은 인터넷에 연결된 장치를 훑어 목록으로 보여 주는 검색엔진인데, 공격자도 똑같은 도구로 표적을 고릅니다. 내 IP가 여기서 관리 화면째로 잡힌다면, 그건 이미 적신호입니다.

중간자 공격: 둘 사이에 끼어드는 그림자

네트워크 위협의 한복판에 중간자 공격(Man-in-the-Middle, MITM)이 있습니다. 이 구조를 이해하면, 왜 그토록 모두가 "암호화, 암호화" 하는지가 한 번에 납득됩니다.

어떻게 끼어드는가

이름 그대로입니다. 통신하는 두 당사자 — 이를테면 당신과 어떤 웹사이트 — 사이에 공격자가 몰래 자리를 잡습니다. 당신은 사이트와 직접 대화한다고 믿지만, 실제로는 당신의 모든 말이 공격자를 한 번 거쳐서 전달됩니다. 공격자는 양쪽 모두에게 "내가 상대방이야"라고 연기하면서, 가운데서 통신을 엿보고, 기록하고, 필요하면 내용까지 바꿔치기합니다.

이게 가능한 이유는 네트워크 통신이 여러 중간 지점을 거쳐 흐르기 때문입니다. 공격자가 그 경로의 어느 한 지점 — 특히 당신과 같은 네트워크 안 — 에 설 수만 있다면, 통신을 가로챌 위치를 확보하게 됩니다.

끼어들면 무엇이 가능해지나

중간 자리를 차지한 공격자가 할 수 있는 일은 두 갈래입니다.

• 엿보기(도청). 암호화되지 않은 통신이라면 내용이 그대로 보입니다. 당신이 입력하는 아이디·비밀번호, 주고받는 데이터, 방문하는 사이트가 전부 노출됩니다.
• 바꿔치기(변조). 한 발 더 나아가, 당신이 보는 페이지에 악성 내용을 끼워 넣거나 당신이 보내는 데이터를 조작합니다. 단순히 훔쳐보는 것을 넘어, 적극적으로 속일 수 있다는 뜻입니다.

특히 위험한 조합은 변조 능력이 거래 정보 조작과 만날 때입니다. 예를 들어 송금 계좌번호나 결제 금액이 통신 도중에 슬쩍 바뀐다면, 사용자는 자기가 정상 거래를 했다고 끝까지 믿게 됩니다.

방어는 결국 암호화다

MITM에 대한 근본 방어는 암호화입니다. 통신이 제대로 암호화돼 있으면, 공격자가 중간에서 가로채도 내용을 읽지 못하고, 함부로 변조하면 무결성 검증 단계에서 들통납니다. 게다가 TLS의 인증서 검증 기능은 "지금 내가 통신하는 상대가 진짜인지"를 확인해 주기 때문에, 공격자가 상대방 행세를 하는 것 자체를 막아 줍니다.

그래서 암호화는 옵션이 아니라 기본값이어야 합니다. 암호화되지 않은 평문 통신은 MITM 앞에 발가벗고 서 있는 것과 같으며, 신뢰할 수 없는 네트워크일수록 그 위험은 커집니다. 신뢰할 수 없는 곳에서는 모든 통신이 HTTPS인지 각별히 확인하고, 필요하면 VPN — 신뢰할 수 없는 네트워크 위에 자신만의 암호화된 통로를 까는 가상 사설망 — 같은 추가 암호화 계층을 한 겹 더 두르는 것이 좋습니다.

개발자·사업주를 위한 30초 점검. 내 사이트가 중간자에게 평문을 흘리지는 않는지 직접 확인할 수 있습니다. SSL Labs SSL Test에 도메인을 넣으면 TLS 설정과 인증서 상태를 등급으로 보여 주고, 서버를 어떻게 설정해야 하는지는 Mozilla SSL Configuration Generator가 그대로 만들어 줍니다. 새 도메인을 올릴 때마다 이 둘로 한 번 훑어 두면, "이 사이트는 중간자가 끼어들어도 못 읽는다"를 30초 만에 확인할 수 있습니다.

카페 와이파이의 함정: 그 와이파이는 진짜인가

이제 아주 구체적이고 일상적인 위협으로 내려옵니다. 카페나 공항 같은 곳의 공용 와이파이입니다.

악성 쌍둥이(evil twin) — 복제된 접속점

불편하지만 알아 둬야 할 사실이 있습니다. 카페에서 연결한 그 와이파이가, 카페가 띄운 것이 아닐 수 있습니다. 공격자가 만든 가짜일 수 있습니다.

작동 방식은 간단합니다. 공격자가 카페 안에서, 그 카페 와이파이와 똑같거나 매우 비슷한 이름의 가짜 접속점을 띄웁니다. 이것을 악성 쌍둥이(evil twin)라고 부릅니다. 손님들은 익숙한 이름을 보고 의심 없이 연결하고, 그 순간부터 모든 트래픽이 공격자를 거쳐 흐릅니다. 앞서 본 중간자 자리를, 공격자가 가짜 와이파이 하나로 손쉽게 확보하는 셈입니다.

현장에서 보면 이건 거창한 장비가 필요한 공격이 전혀 아닙니다. 손바닥만 한 장치 하나로 "Free Cafe WiFi" 같은 이름을 띄우는 건 너무 쉬워서, 같은 이름이 두 개 잡힌다고 해서 둘 다 진짜라는 보장이 전혀 없습니다. 결론적으로 "이름이 익숙하다"는 것은 신뢰의 근거가 못 됩니다.

강제 끊김과 재연결의 덫

더 교묘한 수법도 있습니다. 당신이 이미 진짜 와이파이에 잘 붙어 있더라도, 공격자가 그 연결을 강제로 끊어 버릴 수 있습니다. 무선 신호를 방해하거나 연결 해제 신호를 흘려서, 기기를 와이파이에서 튕겨 내는 것입니다.

연결이 끊긴 기기는 자동으로 재연결을 시도합니다. 바로 이때가 함정입니다. 공격자가 미리 띄워 둔 가짜 접속점이 진짜보다 강한 신호로 손짓하면, 기기가 그 가짜에 붙어 버릴 수 있습니다. 또는 재연결 과정에서 "비밀번호를 다시 입력하세요" 화면이 뜨고, 무심코 입력하는 순간 그 비밀번호가 공격자에게 넘어갑니다.

이 한 가지만 기억하세요. 이유 없이 와이파이가 끊겼다가, 다시 연결되면서 비밀번호를 또 입력하라고 하면 의심하십시오. 정상적인 상황에서 이미 붙어 있던 와이파이가 갑자기 끊기고 비밀번호를 재요구하는 일은 흔하지 않습니다. 그 비밀번호를 입력하는 순간이, 네트워크 접속 권한을 공격자에게 넘겨주는 순간일 수 있습니다.

방어: 공용 네트워크를 처음부터 믿지 않기

공용 와이파이 방어의 핵심은 단 하나, 신뢰하지 않는 것입니다. 위치를 신뢰하지 않는 Zero Trust 사고를 일상에 적용하는 것이라 보면 됩니다.

• 암호화를 확인한다. 통신이 암호화돼 있으면 가로채도 못 읽는다. 공용망에서는 모든 통신이 HTTPS인지 각별히 확인하고, 평문 통신은 피한다.
• VPN 등 추가 암호화 계층을 쓴다. 신뢰할 수 없는 네트워크 위에 자신만의 암호화 통로를 깔면, 그 네트워크를 지나는 트래픽을 보호할 수 있다.
• 의심스러운 재연결을 경계한다. 이유 없는 끊김과 비밀번호 재요구를 의심한다. 익숙한 이름이라도 비정상 동작이 따라붙으면 연결하지 않는다.
• 민감한 작업을 피한다. 중요한 로그인, 금융 거래, 업무 시스템 접근은 공용망에서 가급적 하지 않는다. 꼭 필요하면 개인 핫스팟이나 VPN을 거친다.
• 자동 연결을 끈다. 익숙한 이름에 자동으로 붙도록 두면, 그 이름을 흉내 낸 가짜에 자동 연결될 수 있다. 신뢰할 수 없는 곳에서는 자동 연결을 꺼 둔다.

같은 네트워크 안의 위협: 나를 제외한 누군가

여기서 이 글의 가장 중요한 통찰에 도착합니다. 가짜 와이파이만 위험한 게 아닙니다. 나를 제외한 누군가가 같은 네트워크 안에 있다는 사실 그 자체가 위험합니다.

같은 네트워크 = 신뢰의 공유, 가 아니다

같은 네트워크에 붙은 기기들은 서로 통신할 수 있는 위치에 있습니다. 편리하지만 동시에 위험합니다. 같은 네트워크 안의 다른 기기가 악의를 품었거나 이미 감염돼 있다면, 그게 곧바로 당신을 노릴 수 있기 때문입니다. 앞서 본 중간자 공격도, 같은 네트워크 안에서는 훨씬 쉽게 일어납니다.

핵심을 다시 못 박겠습니다. 같은 네트워크를 공유한다는 것은, 신뢰를 공유한다는 뜻이 아닙니다. 당신과 같은 와이파이에 붙은 모든 기기는, 당신이 통제할 수도 알 수도 없는 잠재적 위협입니다. 그 기기 주인에게 악의가 없더라도, 기기 자체가 이미 감염돼 봇넷의 일부가 돼 있다면, 그것이 당신을 향할 수 있습니다.

사무실이라고 안전하지 않다 — 오히려 클수록 위험하다

이 통찰은 공용 와이파이를 넘어 사무실 사내망에도 그대로 적용됩니다. 그리고 여기에 직관을 거스르는 진실이 하나 있습니다. 직원이 수십, 수백 명인 사무실은 그만큼 더 위험합니다.

이유는 확률입니다. 네트워크 안의 사람과 기기가 많을수록, 그중 하나가 위협이 될 가능성이 높아집니다. 수백 명이 있다면 그중 누군가의 기기가 감염됐을 가능성, 누군가가 부주의하거나 악의를 품었을 가능성이 그만큼 커집니다. 그리고 그 단 한 대의 감염된 기기가, 같은 네트워크 안의 나머지 전부에게 위협이 됩니다.

일반화하면 이렇습니다. 나를 제외한 누군가가 네트워크 안에 있으면, 그 자체로 위험이 존재하며, 그 위험은 인원수에 비례해 커집니다. 이것이 "네트워크 안쪽을 신뢰하지 말라"는 원칙의 가장 구체적인 근거입니다. 사내망 안에 있다는 사실은 결코 안전을 보장하지 않습니다.

방어: 분리와 격리

같은 네트워크 안의 위협에 대한 답은 분리와 격리입니다.

네트워크를 분리하라. 모든 기기를 하나의 평평한 네트워크에 몰아넣지 말고, 용도와 신뢰 수준에 따라 나눕니다. 게스트 네트워크 분리가 가장 기본적인 예입니다. 사무실이라면 부서·용도·신뢰 수준별로 네트워크를 쪼개서, 한 구역의 침해가 전체로 번지지 않게 합니다. 이것이 바로 측면 이동(lateral movement — 공격자가 처음 뚫은 한 대를 발판 삼아 같은 네트워크의 다른 장치로 옮겨 다니며 권한을 넓혀 가는 것)에 대한 방어입니다. 공격자가 실제로 어떻게 옆으로 번지는지는 MITRE ATT&CK의 Lateral Movement 전술에 단계별로 정리돼 있습니다.

중요한 것을 격리하라. 특히 민감한 시스템은 일반 네트워크와 떼어 둡니다. 모두가 접근하는 네트워크에 핵심 자산을 두면, 그 네트워크 안의 누구든(또는 감염된 무엇이든) 그것을 노릴 수 있습니다.

Zero Trust를 적용하라. 네트워크 위치를 신뢰의 근거로 삼지 마십시오. 사내망 안에 있다는 이유로 접근을 허용하지 말고, 모든 접근을 신원으로 검증하십시오. 그러면 네트워크가 뚫려도 신원 검증이라는 한 겹이 더 막아 줍니다. 작은 팀이라도 이걸 직접 만들 필요는 없습니다. 예컨대 Cloudflare Zero Trust 같은 서비스를 쓰면, 관리자 화면이나 내부 도구의 출입 기준을 "이 네트워크 안에 있으니 통과"에서 "로그인한 이 사람이 맞으니 통과"로 바꿀 수 있고, 그 과정에서 관리 포트를 인터넷에 직접 열지 않아도 됩니다.

개발자 컴퓨터: 가장 탐나는 표적

네트워크 격리가 특히 중요한 한 가지 경우를 따로 떼어 강조하겠습니다. 개발자의 컴퓨터입니다.

왜 개발자 PC는 더 쉽게, 더 치명적으로 털리나

개발자의 컴퓨터는 공격자에게 유독 탐나는 표적입니다. 이유가 둘입니다.

첫째, 더 쉽게 털립니다. 개발자는 업무 특성상 온갖 도구를 설치하고, 여러 출처에서 코드와 패키지를 끌어오며(공급망 위험), 높은 권한을 쥔 채로 작업하고, 다양한 시스템에 접근합니다. 이 모든 것이 일반 사용자보다 훨씬 넓은 공격면을 만듭니다. 개발자 컴퓨터는 본질적으로 더 많은 것에 노출돼 있습니다.

2024년 xz-utils 백도어(CVE-2024-3094) 사건이 그 단적인 예입니다. 널리 쓰이는 오픈소스 라이브러리에 백도어가 심어져, 그저 평소처럼 패키지를 당겨 빌드한 개발자의 기기가 표적이 될 뻔했습니다. "내가 가져오는 코드는 깨끗하다"는 가정 자체가 공격면이라는 것을 보여 준 사건입니다.

둘째, 털렸을 때 더 치명적입니다. 개발자 컴퓨터에는 회사에서 가장 민감한 것들이 모여 있습니다. 소스 코드, 서버 접근용 SSH 개인키, 클라우드 자격 증명, 데이터베이스 접속 정보, 그리고 회사 핵심 시스템에 대한 접근 권한까지. 개발자 컴퓨터 한 대가 뚫리면, 그걸 발판으로 회사 핵심 인프라 전체가 위험에 빠질 수 있습니다. 권한 상승과 측면 이동이 가장 빠르게 일어나는 출발점이 바로 여기입니다.

로컬 개발 환경은 격리된 네트워크여야 한다

그래서 이 원칙이 중요합니다. 로컬 개발 환경은 격리된 네트워크에 두어야 합니다.

개발 환경은 본질적으로 실험적이고 불안정합니다. 테스트 중인 코드, 검증되지 않은 패키지, 디버그 모드로 돌아가는 서비스가 잔뜩 있습니다. 만약 이런 개발 환경이 운영 시스템이나 민감한 자산과 같은 네트워크에 있다면, 개발 환경의 약점이 그대로 그것들로 가는 통로가 됩니다. 실험적이고 불안정한 것과, 반드시 지켜야 할 중요한 것이 같은 공간에 있어서는 안 됩니다.

개발 환경을 분리된 네트워크에 두면, 설령 개발 환경이 뚫려도 피해가 그 안에 갇힙니다. 이것은 네트워크 분리 원칙을 "개발"이라는 특히 위험한 활동에 적용한 것입니다. 동시에 개발자 본인도 자신의 컴퓨터가 매력적인 표적임을 인식하고, 기본기 — SSH 키 안전 관리, 최소 권한, 꾸준한 패치 — 를 각별히 지켜야 합니다.

한눈에 보는 실행 항목

이 글에서 짚은 것을 그대로 따라 할 수 있는 행동 목록으로 압축합니다.

1. 공유기 펌웨어를 최신으로 유지하고 기본 비밀번호를 바꾼다. 원격 관리를 끄고, WPA3(최소 WPA2) 암호화를 쓴다.
2. 모든 통신이 암호화돼 있는지 확인한다. 특히 신뢰할 수 없는 네트워크에서. 필요하면 VPN 같은 추가 암호화 계층을 둔다.
3. 공용 와이파이를 믿지 않는다. 자동 연결을 끄고, 민감한 작업을 피하며, 이유 없는 재연결과 비밀번호 재요구를 의심한다.
4. 네트워크를 분리한다. 게스트 네트워크를 떼어 놓고, 신뢰 수준에 따라 네트워크를 나눈다.
5. 중요한 시스템을 격리한다. 모두가 접근하는 네트워크에 핵심 자산을 두지 않는다.
6. 로컬 개발 환경을 격리된 네트워크에 둔다. 개발자 컴퓨터가 가장 탐나는 표적임을 잊지 않는다.
7. 네트워크에 Zero Trust를 적용한다. 위치가 아니라 신원으로 검증한다.

자주 묻는 질문 (FAQ)

Q. 공용 와이파이에서 HTTPS만 쓰면 VPN은 필요 없나요? HTTPS는 웹 통신의 내용을 암호화해 주므로 중간자가 본문을 읽지 못하게 막아 줍니다. 다만 어떤 도메인에 접속하는지, 어떤 앱이 평문으로 통신하는지까지 다 가려 주지는 못하고, 가짜 와이파이에 붙는 것 자체를 막아 주지도 않습니다. 신뢰할 수 없는 공용망에서 민감한 작업을 해야 한다면, HTTPS 위에 VPN이라는 암호화 통로를 한 겹 더 두르는 편이 안전합니다.

Q. 같은 이름의 와이파이가 두 개 잡히면 어떤 게 진짜인가요? 이름만으로는 구별할 수 없습니다. 악성 쌍둥이(evil twin) 공격은 진짜와 똑같은 이름을 띄우는 것이 핵심이라, "이름이 익숙하다"는 신뢰의 근거가 되지 못합니다. 가장 확실한 방법은 그 장소의 직원에게 정확한 와이파이 이름을 직접 확인하는 것이고, 이유 없이 끊겼다가 비밀번호를 다시 요구하는 정황이 있으면 연결하지 않는 것입니다. 불안하면 개인 핫스팟을 쓰는 편이 낫습니다.

Q. 집에서 가족만 쓰는 와이파이도 네트워크 분리가 필요한가요? 규모는 작아도 원칙은 같습니다. 스마트 TV, IoT 가전, 손님 휴대폰처럼 통제하기 어려운 기기가 늘어날수록, 그중 하나가 감염됐을 때 같은 네트워크의 다른 기기로 번질 위험이 생깁니다. 대부분의 가정용 공유기가 제공하는 게스트 네트워크 기능만 켜서, 손님과 신뢰도가 낮은 IoT 기기를 주 네트워크와 분리해 두는 것만으로도 기본적인 격리가 됩니다.

Q. 사내망 안에 있으면 안전하다고 봐도 되나요? 아닙니다. 그것이 바로 이 글이 해체하려는 가장 흔한 오해입니다. 네트워크 안에 있다는 위치는 안전을 보장하지 않습니다. 직원과 기기가 많을수록 그중 하나가 감염됐거나 위협이 될 확률이 높아지고, 그 한 대가 같은 네트워크의 모두에게 위험이 됩니다. 위치가 아니라 신원으로 검증하는 Zero Trust를 적용하고, 중요한 시스템은 별도로 격리해야 합니다.

Q. 개발자 컴퓨터를 격리하라는데, 1인 개발자도 그래야 하나요? 규모와 무관하게 원칙은 유효합니다. 개발자 PC에는 SSH 개인키, 클라우드 자격 증명, 데이터베이스 접속 정보처럼 한 번 털리면 인프라 전체로 번지는 것들이 모여 있기 때문입니다. 1인이라면 운영 자산과 같은 평평한 네트워크에 테스트 환경을 두지 않는 것, 키를 안전하게 관리하는 것, 검증되지 않은 패키지를 무심코 끌어와 빌드하지 않는 것만 지켜도 위험을 크게 줄일 수 있습니다.

원문 출처 및 더 알아보기

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

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