‘네트워크 경계’ 묶음의 첫 글 · 1 / 9 — 묶음의 글 모두 보기 ↓
방화벽이 있는데 왜 또 막아야 하나요: 방화벽이 막는 것과 못 막는 것
네트워크 보안의 첫 문이라 불리는 방화벽이 실제로 판단하는 것과, 그 판단으로는 걸러지지 않는 위협을 구분해 봅니다.
짧은 답
방화벽은 오가는 통신을 미리 정한 규칙과 대조해 통과시키거나 버리는 검문소예요. 주소·포트·프로토콜을 보고 판단하므로, 열어 둔 통로로 정상적인 모습을 하고 들어오는 위협은 막지 못해 여러 겹 중 첫 겹으로 둬요.
이 글의 차례 8
경계를 만들어 주는 장비
네트워크 구성도를 앞에 두고 '방화벽이 있는데 왜 또 막아야 하지?' 하고 갸웃해 보신 적 있으시죠. 막상 이 장비가 무엇을 막아 주고 무엇은 못 막는지 선이 안 그어져서, 점검 때마다 같은 자리에서 멈추게 돼요. 이 글에서는 방화벽이 실제로 보는 것과 못 보는 것, 그래서 어디를 다른 겹에 맡기면 되는지를 순서대로 정리해 드릴게요.
회사 네트워크 구성도를 펼쳐 보면 대개 가운데쯤에 네모 하나가 있고 그 위에 방화벽이라고 적혀 있어요. 내부망과 바깥 인터넷 사이에 세워둔 검문소라는 뜻이에요. 하는 일 자체는 아주 단순해요. 오가는 통신을 하나씩 들여다보고, 미리 정해둔 규칙에 맞으면 통과시키고 맞지 않으면 조용히 버려요.
솔직히 말하면, 보안 장비 이야기에서 방화벽이 가장 먼저 등장하는 이유는 성능이 뛰어나서가 아니에요. 이 장비가 '경계'를 만들어 주기 때문이에요. 경계가 없으면 안과 밖의 구분이 없고, 구분이 없으면 무엇을 어디까지 지켜야 하는지도 정할 수 없어요. 방화벽은 위협을 없애 주는 장비라기보다 지켜야 할 선을 눈에 보이게 만들어 주는 장비에 가까워요. 이 한 줄만 잡아 두셔도 뒤 내용이 훨씬 편하게 읽혀요.
방화벽은 무엇을 보고 판단하는가
네트워크를 오가는 데이터는 패킷이라는 작은 조각 단위로 움직여요. 각 패킷의 머리 부분에는 어디에서 출발해 어디로 가는지(주소), 어떤 서비스에 해당하는지(포트), 어떤 통신 방식인지(프로토콜)가 적혀 있어요. 전통적인 패킷 필터 방식의 방화벽은 이 정보만 보고 규칙표와 대조해요. 편지 봉투의 겉면만 보고 배달 여부를 정하는 셈이에요.
여기서 한 걸음 나아간 것이 연결의 상태를 함께 기억하는 방식이에요. 내부에서 먼저 요청해서 시작된 대화의 응답인지, 바깥에서 불쑥 들어온 첫 접촉인지를 구분해요. 이 구분 하나만으로도 '우리가 부르지 않았는데 찾아온 통신'이 대부분 정리돼요. 그래서 오늘날 방화벽의 기본 동작으로 자리를 잡았어요.
최근 장비들은 여기에 더해 애플리케이션 수준까지 들여다보거나 다른 보안 기능을 함께 묶어 주기도 해요. 여기서 많이들 헷갈리시는데, 기능이 늘어나도 방화벽의 뼈대는 그대로예요. 규칙을 정하고, 대조하고, 통과 또는 차단을 결정하는 것이 전부예요.
허용·차단 정책을 세우는 사고방식
방법은 간단해요. 정책을 만드는 방향은 크게 두 가지예요. 위험해 보이는 것을 하나씩 막아 나가는 방향, 그리고 기본적으로 전부 막아 두고 업무에 꼭 필요한 것만 하나씩 여는 방향이에요. 보안에서 권장되는 쪽은 후자예요. 세상의 위험을 전부 나열하는 일은 끝이 없지만, 우리 업무에 필요한 통로를 적어 보는 일은 유한하니까요.
규칙표에는 순서가 있어요. 대개 위에서부터 차례로 대조하다가 처음 일치하는 규칙에서 판단이 끝나요. 그래서 넓게 허용하는 규칙이 위쪽에 있으면, 아래에 아무리 촘촘한 차단 규칙을 써 두어도 소용이 없어요. 현장 점검에서 자주 지적되는 항목이 바로 이 순서 문제, 그리고 '누가 왜 열었는지 아무도 모르는' 오래된 허용 규칙이에요. 찔리시는 분 계시죠?
그래서 실무에서는 규칙을 추가하는 절차보다 정리하는 절차를 더 중요하게 봐요. 규칙마다 요청자와 사유, 기한을 남겨 두면 몇 년 뒤에도 그 줄을 지워도 되는지 판단할 수 있어요. 기록이 없는 규칙은 무서워서 아무도 손대지 못한 채 남고, 그렇게 남은 구멍이 쌓여요. 반대로 한 줄짜리 기록만 붙여 둬도 정리가 놀랄 만큼 수월해져요.
정상 통로로 들어오는 것은 막지 못한다
근데 여기서 반전은, 방화벽의 한계가 그 강점에서 곧바로 따라 나온다는 점이에요. 방화벽은 '이 통로를 지나가도 되는가'를 판단할 뿐이에요. '이 통로로 지나가는 내용이 안전한가'까지 판단하도록 만들어진 장비가 아니에요. 회사 홈페이지를 운영하려면 웹 통로를 열어야 하고, 메일을 주고받으려면 메일 통로를 열어야 해요. 그리고 오늘날 문제가 되는 위협 상당수는 바로 그 열어둔 정상 통로를 타고 들어와요.
직원이 받은 메일의 첨부파일을 여는 순간, 내부에서 바깥으로 나가는 통신이 시작돼요. 방화벽 입장에서는 안에서 먼저 요청한 정상적인 대화예요. 웹 서비스 자체에 취약점이 있다면 그 취약점을 건드리는 요청도 방화벽에게는 평범한 웹 요청으로 보여요. 통신이 암호화되어 있으면 내용은 더더욱 보이지 않고요.
내부에서 벌어지는 일도 마찬가지예요. 경계에 서 있는 장비는 이미 안쪽에 들어와 있는 단말끼리의 통신이나, 권한을 가진 사람이 권한 범위 안에서 하는 행동을 대상으로 삼지 않아요. '방화벽이 있는데 어떻게 뚫렸나' 하는 질문이 반복되는 이유가 대부분 여기 있어요. 뚫린 게 아니라, 애초에 그 장비가 볼 수 없는 영역에서 일어난 일인 경우가 많아요. 이걸 알고 나면 원인을 엉뚱한 데서 찾느라 시간을 쓰는 일이 확 줄어요.
경계는 바깥에만 있지 않다
앞에서 말한 한계 가운데 '안쪽에서 벌어지는 일'은 경계를 하나 더 그어서 꽤 좁힐 수 있어요. 내부망을 한 덩어리로 두지 않고 성격이 다른 구역으로 나누는 거예요. 외부에 공개되는 서버 구역, 직원 업무용 단말 구역, 데이터베이스나 관리 시스템처럼 민감한 것이 모여 있는 구역을 분리하고, 구역 사이에도 '지나가도 되는 통로'를 정해 둬요. 이렇게 하면 단말 한 대가 문제를 일으켜도 그 영향이 구역 경계에서 한 번 더 걸러져요. 네트워크 분리 또는 세그먼테이션이라고 부르는 사고방식이고, 방화벽이 하는 일을 내부에도 적용하는 셈이에요.
아, 그리고 하나 더. 놓치기 쉬운 것이 기록이에요. 방화벽은 통과와 차단을 결정하면서 그 판단을 로그로 남길 수 있어요. 차단 기록은 '누가 어디를 두드리고 있는가'를 보여 주는 신호예요. 허용 기록은 사고가 난 뒤 '그때 무엇이 어디로 오갔는가'를 되짚는 실마리가 되고요. 규칙은 잘 세웠는데 로그를 아무도 보지 않거나 보관 기간이 짧아서 정작 필요할 때 비어 있는 경우가 현장에서 적지 않게 보여요. 장비를 두는 일과 그 장비가 남긴 기록을 읽는 체계를 갖추는 일은 별개예요.
정리하면 방화벽의 가치는 장비 한 대가 아니라 '경계를 어디에 몇 겹으로 긋고, 그 경계가 남긴 기록을 누가 읽는가'라는 설계 전체에서 나와요. 이 관점이 서면 다음에 이야기할 다층 방어가 구호가 아니라 구체적인 그림으로 바뀌어요.
그래서 여러 겹으로 쌓는다
이 한계는 방화벽의 결함이 아니라 역할의 범위예요. 한 장비가 모든 위협을 담당하게 만들 수는 없어요. 그래서 보안은 성격이 다른 방어 수단을 여러 겹으로 겹쳐 놓는 방식으로 설계해요. 경계에서 통로를 통제하고, 통로를 지나온 내용은 다른 수단으로 검사하고, 단말에서 실행되는 행위는 또 다른 수단으로 관찰하고, 그럼에도 지나간 흔적은 기록으로 남겨 나중에 추적하는 식이에요. 이것을 다층 방어(심층 방어)라고 부릅니다.
여러 겹을 쌓는 목적은 완벽한 차단이 아니에요. 확률과 시간을 버는 데 있어요. 각 겹은 저마다 빈틈이 있지만 빈틈의 위치가 서로 달라서, 겹쳐 놓으면 한 번에 전부 통과할 가능성이 낮아져요. 어느 한 겹이 뚫려도 다음 겹에서 신호가 남아 대응을 시작할 수 있고요.
이제 이렇게 해보시면 돼요. 종이 한 장을 반으로 접고 왼쪽에는 '방화벽이 막아 주는 것', 오른쪽에는 '다른 곳에 맡겨야 하는 것'을 적어 보세요. 두 목록이 채워지는 순간 우리 조직에서 비어 있는 겹이 어디인지 자연스럽게 보여요. 거기서 오래된 허용 규칙 몇 줄만 정리해도 체감이 확 달라져요. 방화벽을 처음부터 다시 설계할 필요는 없어요. 역할을 제자리에 놓아 주는 것만으로도 충분히 든든해집니다.
‘네트워크 경계’ 묶음의 글 9편
방화벽이 막는 것과 못 막는 것에서 출발해 망 분리·제로 트러스트·VPN·계정 권한·클라우드 책임·패치·취약점 공지 읽기까지, 경계와 그 안쪽을 지키는 구조를 읽는 묶음. 이 글에서 시작해 아래 순서로 읽으면 자연스럽게 이어집니다.
- 방화벽이 있는데 왜 또 막아야 하나요: 방화벽이 막는 것과 못 막는 것 — 지금 읽는 글
- 업무망과 인터넷망을 나누면 해킹 걱정이 끝날까요: 망 분리가 막아 주는 것과 틈이 생기는 자리
- 제로 트러스트는 '아무도 믿지 않는다'는 뜻일까요: 경계형 보안과 무엇이 다른지 구조로 정리
- VPN을 켜면 안전해지나요: VPN이 지키는 구간과 못 지키는 구간
- 서버 보안, 어디서부터 손대야 할까요: 공용 관리자 계정부터 나누는 이유
- 클라우드 보안, 어디까지가 내 책임인가
- 업데이트는 왜 미뤄지고, 왜 그래도 해야 하나: 패치 관리의 구조
- 보안 뉴스의 'CVE 번호'와 '심각도 점수', 점수가 높다고 우리에게 가장 급한 건 아닌 이유
- 공유기 접속 목록에 모르는 기기가 보여요: 내 기기인지 가르는 법과 막는 순서
자주 묻는 질문
방화벽만 잘 설정하면 웬만한 공격은 막을 수 있나요?
그렇지는 않아요. 방화벽은 통로 단위의 통제를 담당할 뿐이라, 열어둔 통로를 타고 오는 메일 첨부·웹 요청·내부 단말의 행위는 판단 범위 밖이에요. 성격이 다른 방어 수단을 함께 두는 것이 전제라고 보시면 돼요. 사용 중인 소프트웨어의 최신 취약점과 보안 공지, 패치 정보는 한국인터넷진흥원이 운영하는 보호나라에서 확인할 수 있어요.
방화벽 규칙을 정리하는 데 시간이 얼마나 걸리나요?
조직마다 규칙 수가 달라서 기간을 딱 잘라 말하기는 어려워요. 다만 한 번에 전부 손보기보다 '가장 넓게 허용하는 규칙'부터 몇 줄씩 확인해 나가는 방식이 부담이 적어요. 정리한 줄마다 요청자·사유·기한을 함께 남겨 두면 다음 점검부터는 훨씬 빨라져서, 시간이 지날수록 편해지는 쪽으로 굴러가요.
개인 PC의 방화벽도 같은 원리인가요?
원리는 같습니다. 규칙에 따라 통신을 허용하거나 차단합니다. 다만 보호 대상이 네트워크 전체가 아니라 그 PC 한 대라는 점, 그리고 사용자가 실행한 프로그램의 통신을 기준으로 판단하는 경우가 많다는 점이 다릅니다.
방화벽 규칙이 너무 많아졌는데 어디부터 손대야 하나요?
일반적으로는 가장 넓게 허용하는 규칙, 사용 흔적이 없는 규칙, 사유가 기록되지 않은 오래된 규칙 순으로 살펴봅니다. 삭제 전에 영향 범위를 확인하고 되돌릴 수 있는 절차를 준비해 두는 것이 안전합니다.
클라우드를 쓰면 방화벽은 신경 쓰지 않아도 되나요?
아닙니다. 클라우드 제공자는 기반 시설의 경계를 책임지지만, 내가 만든 서버와 서비스에 어떤 통로를 열어 둘지는 이용자의 설정 영역입니다. 이름은 보안 그룹이나 네트워크 접근 제어 같은 식으로 다르지만 '규칙을 정하고 대조해 통과·차단한다'는 원리는 같고, 기본 차단 후 필요한 것만 여는 사고방식도 그대로 적용됩니다.
방화벽 로그는 무엇을 위해 남기고, 무엇을 보면 되나요?
크게 두 용도입니다. 차단 기록은 평소에 어떤 접근 시도가 반복되는지 파악하는 신호로, 허용 기록은 사고 이후 통신 흐름을 되짚는 근거로 쓰입니다. 처음에는 전부 읽으려 하기보다 '평소와 다른 목적지·시간대·양'처럼 기준을 하나 정해 살펴보고, 보관 기간을 조직 정책에 맞게 정해 두는 것이 현실적입니다.
직접 확인해 보실 곳
확인할 곳
이 글에서 다루는 주제를 맡는 공식 기관입니다. 신고·상담 창구도 여기에 있으니, 실제 상황에서는 아래로 바로 이어 가시면 됩니다.
- 보호나라 보안 공지와 취약점 정보, 사고 신고 창구
참고한 자료
- 방화벽과 방화벽 정책 지침 (SP 800-41 Rev. 1) NIST 확인일
이 글은 입문자 기준으로 이해하기 쉽게 정리한 일반 정보이며, 내용은 운영 과정에서 순차적으로 점검·보완될 수 있습니다. 구체적인 절차나 수치는 해당 기관의 공식 안내를 기준으로 확인해주세요.
이 글의 용어
보안 용어 사전에서 한 줄 정의와 쉬운 비유로 다시 볼 수 있어요.