연결만 되는 인터넷은 아직 믿을 수 없다
지금까지 우리는 작은 인터넷을 만들었다. 케이블과 와이파이로 비트가 지나가고, IP 주소로 목적지를 찾고, 라우터가 길을 고르고, DNS가 이름을 주소로 바꾸고, 웹 서버가 응답한다.
하지만 여기까지는 "연결되는 인터넷"이다. "믿고 사용할 수 있는 인터넷"은 한 단계가 더 필요하다. 누가 중간에서 내용을 훔쳐보지 못하게 해야 하고, 엉뚱한 서버를 진짜 서버로 착각하지 않아야 하며, 필요 없는 문은 닫아 두어야 한다.
보안은 특별한 장식이 아니다. 도로를 만든 뒤 신호등, 차선, 출입문, 잠금장치를 더하는 일에 가깝다. 길이 있어야 이동할 수 있지만, 아무 차나 아무 건물에 들어오게 두면 위험하다. 인터넷 보안도 같다. 모든 통신을 막는 것이 아니라, 필요한 통신은 지나가게 하고 위험한 통신은 줄이는 과정이다.
이 장에서는 네 가지를 다룬다.
HTTP와 HTTPS의 차이
TLS 인증서가 서버 신원을 확인하는 방식
방화벽이 통신을 허용하거나 막는 방식
비밀번호, 업데이트, 최소 권한, 로그 확인 같은 운영 습관
AI 생성 이미지
HTTP와 HTTPS: 엽서와 봉투의 차이
HTTP는 웹 브라우저와 웹 서버가 대화하는 규칙이다. 이전 장에서 본 것처럼 브라우저는 서버에 요청을 보내고, 서버는 HTML이나 이미지 같은 응답을 돌려준다.
문제는 HTTP만 사용할 때다. HTTP 요청과 응답은 기본적으로 읽을 수 있는 형태로 오간다. 편지를 봉투에 넣지 않고 엽서로 보내는 것과 비슷하다. 엽서는 목적지까지 잘 갈 수 있지만, 중간에 지나가는 사람이 내용을 볼 수 있다.
인터넷에서 "중간에 지나가는 사람"은 꼭 사람이 아닐 수 있다. 같은 와이파이에 붙은 공격자, 잘못 설정된 공유기, 감염된 장비, 신뢰하기 어려운 네트워크 구간이 될 수 있다. HTTP로 로그인 비밀번호를 보내면, 길목에서 그 내용을 읽을 가능성이 생긴다.
HTTPS는 HTTP를 암호화된 통로 안에 넣어 보내는 방식이다. 암호화는 내용을 알아볼 수 없는 형태로 바꾸는 기술이다. 쉬운 비유로 말하면, 글을 잠긴 봉투에 넣어 보내는 것이다. 봉투가 중간에 보이더라도 안의 문장은 읽기 어렵다.
정확한 이름으로는 HTTPS의 보호막 역할을 하는 기술을 TLS라고 한다. TLS는 Transport Layer Security의 줄임말이다. HTTPS는 "HTTP + TLS"라고 생각하면 쉽다. 웹의 대화 내용은 HTTP이고, 그 대화를 감싸는 안전한 통로가 TLS다.
비유는 여기까지다. 실제 인터넷에서는 종이 봉투가 오가지 않는다. 컴퓨터는 수학적인 열쇠를 이용해 데이터를 다른 사람이 읽기 어려운 비트 배열로 바꾼다. 그리고 받는 쪽만 그 내용을 다시 원래 형태로 풀 수 있게 한다.
HTTPS가 해 주는 일은 크게 세 가지다.
첫째, 중간에서 내용을 읽기 어렵게 한다. 이를 비밀성이라고 한다. 로그인 정보, 쿠키, 검색어, 문서 내용처럼 민감한 데이터가 그대로 노출되는 일을 줄인다.
둘째, 중간에서 내용을 몰래 바꾸기 어렵게 한다. 이를 무결성이라고 한다. 무결성은 택배 상자에 붙은 봉인 스티커와 비슷하다. 누군가 중간에서 내용을 바꾸면 받는 쪽이 이상을 알아차릴 수 있다.
셋째, 내가 접속한 서버가 정말 그 이름의 서버인지 확인하게 돕는다. 이를 인증이라고 한다. 인증은 "상대가 누구인지 확인하는 절차"다. 여기서 TLS 인증서가 등장한다.
TLS 인증서: 서버의 디지털 신분증
암호화만 있으면 충분할 것 같지만, 한 가지 문제가 남는다. 내가 비밀 대화를 하고 있는 상대가 진짜 서버인지 어떻게 알 수 있을까?
예를 들어 브라우저가 bank.example에 접속한다고 생각해 보자. 통신이 암호화되어 있어도, 만약 공격자가 가짜 서버를 세워 놓고 사용자를 그쪽으로 유도했다면 사용자는 가짜 서버와 안전하게 대화하는 셈이 된다. 통로는 잠겨 있지만, 상대가 틀린 것이다.
TLS 인증서는 이 문제를 줄이기 위해 사용된다. TLS 인증서는 서버의 디지털 신분증이다. 신분증에 이름과 발급 기관이 적혀 있듯이, TLS 인증서에는 주로 다음 정보가 들어 있다.
이 인증서가 어떤 도메인 이름을 위한 것인지
서버가 사용하는 공개 키는 무엇인지
누가 이 인증서를 발급했는지
언제부터 언제까지 유효한지
여기서 공개 키는 누구에게나 보여 줄 수 있는 자물쇠라고 생각하면 된다. 개인 키는 그 자물쇠와 짝이 되는 열쇠다. 공개 키는 남에게 보여 줘도 되지만, 개인 키는 서버가 절대 밖으로 내보내면 안 된다.
브라우저가 HTTPS 사이트에 접속할 때는 대략 이런 일이 일어난다.
브라우저가 서버에 "안전한 통신을 시작하자"고 말한다.
서버가 자기 TLS 인증서를 보낸다.
브라우저가 인증서의 도메인 이름, 유효 기간, 발급자를 확인한다.
브라우저와 서버가 이번 연결에서만 쓸 임시 암호화 열쇠를 정한다.
그 뒤부터 HTTP 요청과 응답은 암호화되어 오간다.
인증서를 발급하는 기관을 인증 기관이라고 한다. 영어로는 CA, Certificate Authority라고 부른다. CA는 디지털 신분증을 발급하는 기관에 가깝다. 브라우저와 운영체제는 신뢰할 수 있는 CA 목록을 미리 가지고 있고, 서버 인증서가 그 신뢰 사슬 안에 있는지 확인한다.
작은 인터넷에서도 같은 원리를 실험할 수 있다. 예를 들어 web.example.local이라는 웹 서버를 만들고 HTTPS를 켜면, 브라우저는 이 서버의 인증서를 확인하려고 한다. 실험용으로 직접 만든 인증서는 브라우저가 처음에는 믿지 않는다. 이것을 자체 서명 인증서라고 한다. 말 그대로 "내가 나를 증명한 신분증"이다.
실험실 안에서는 자체 서명 인증서를 써도 된다. 다만 사용자는 그 인증서를 믿어도 되는 이유를 알고 있어야 한다. 실제 사람들에게 공개하는 웹사이트라면 브라우저가 기본적으로 신뢰하는 CA에서 발급받은 인증서를 사용해야 한다.
인증서 경고가 뜨면 습관적으로 무시하면 안 된다. 실험 중인 작은 인터넷에서 내가 직접 만든 인증서라는 사실을 알고 있다면 예외를 둘 수 있다. 하지만 실제 은행, 메일, 쇼핑몰에서 인증서 경고가 뜬다면 멈추는 것이 맞다. 경고는 "암호화가 없어서"만 뜨는 것이 아니라, "상대의 신분을 확인할 수 없어서" 뜨기도 한다.
방화벽: 모든 문을 열어 두지 않기
인터넷을 만들면 장치들은 서로 패킷을 보낼 수 있다. 그러나 모든 장치가 모든 장치의 모든 포트로 들어올 수 있게 두면 위험하다.
방화벽은 어떤 통신은 허용하고 어떤 통신은 막는 규칙 장치다. 건물 입구의 경비원에 비유할 수 있다. 경비원은 방문자의 목적지, 출입 시간, 방문 권한을 보고 들여보낼지 결정한다. 방화벽도 패킷의 출발지 IP, 목적지 IP, 포트 번호, TCP인지 UDP인지 같은 정보를 보고 통과 여부를 판단한다.
비유는 여기서 끝난다. 방화벽은 사람의 표정이나 의도를 읽지 않는다. 방화벽은 정해진 규칙과 패킷 정보를 비교해 기계적으로 판단한다.
작은 인터넷에 웹 서버가 있다고 하자. 웹 서버는 사용자가 웹페이지를 볼 수 있도록 TCP 443번 포트를 열어야 한다. HTTPS가 주로 쓰는 포트가 443번이기 때문이다. 하지만 웹 서버의 관리용 포트까지 모두에게 열 필요는 없다.
좋은 규칙은 보통 이런 방향을 따른다.
클라이언트 네트워크 → 웹 서버 TCP 443 허용
클라이언트 네트워크 → DNS 서버 UDP/TCP 53 허용
관리 네트워크 → 서버 관리 포트 허용
외부 또는 일반 클라이언트 → 서버 관리 포트 차단
서버 → 필요 없는 내부 장치 접근 차단
핵심은 "필요한 문만 열기"다. 처음부터 모든 문을 열어 놓고 나중에 하나씩 닫는 방식은 실수하기 쉽다. 반대로 기본은 막고, 필요한 통신만 하나씩 허용하면 위험한 노출을 줄일 수 있다. 이를 기본 차단 후 허용 방식이라고 부를 수 있다.
방화벽은 여러 위치에 있을 수 있다. 서버 운영체제 안에도 있고, 라우터에도 있고, 집 공유기에도 있고, 클라우드 서비스의 보안 규칙에도 있다. 그래서 통신이 안 될 때는 "방화벽을 확인했다"라는 말만으로는 부족하다. 어느 장비의 어느 방향 규칙을 확인했는지 봐야 한다.
또 하나 중요한 개념은 상태 기반 방화벽이다. 상태 기반 방화벽은 나가는 연결을 기억했다가, 그 연결에 대한 응답은 다시 들어오게 해 준다. 식당에서 손님에게 번호표를 주고, 같은 번호표를 가진 사람이 음식을 받아 가게 하는 것과 비슷하다. 이 기능 덕분에 내부 사용자가 웹사이트에 접속할 때마다 돌아오는 응답 규칙을 따로 만들지 않아도 된다.
비밀번호, 업데이트, 최소 권한, 로그
보안은 HTTPS와 방화벽만으로 끝나지 않는다. 작은 인터넷을 운영해도 기본 습관이 필요하다.
첫째, 비밀번호를 제대로 관리해야 한다. 비밀번호는 문을 여는 열쇠다. 짧고 흔한 비밀번호는 얇은 자물쇠와 같다. 관리자 계정에는 길고 예측하기 어려운 비밀번호를 사용해야 한다. 장비를 처음 설치할 때 들어 있는 기본 비밀번호는 반드시 바꿔야 한다. 가능하다면 비밀번호 외에 한 번 더 확인하는 다중 인증도 사용한다.
둘째, 업데이트를 해야 한다. 프로그램과 운영체제에는 시간이 지나며 약점이 발견된다. 업데이트는 그 약점을 고치는 수리 작업이다. 문고리에 결함이 발견되었는데도 그대로 두면, 공격자는 그 결함을 아는 순간 쉽게 들어올 수 있다. 서버, 라우터, 웹 애플리케이션, DNS 서버, 운영체제는 가능한 한 지원되는 버전으로 유지해야 한다.
셋째, 최소 권한을 지켜야 한다. 최소 권한은 각 사용자와 프로그램에게 필요한 권한만 주는 원칙이다. 청소 담당자에게 건물 전체 금고 열쇠까지 줄 필요는 없다. 웹 서버 프로그램도 마찬가지다. 웹 파일을 읽고 응답하는 데 필요한 권한만 있으면 된다. 모든 서비스를 관리자 권한으로 실행하면, 하나가 뚫렸을 때 피해가 커진다.
넷째, 로그를 봐야 한다. 로그는 장비와 프로그램이 남기는 기록이다. 건물 출입 기록이나 CCTV 목록과 비슷하다. 로그는 공격을 자동으로 막아 주지는 않지만, 무슨 일이 있었는지 알려 준다. 로그인 실패가 반복되는지, 방화벽이 어떤 패킷을 막고 있는지, 웹 서버에 이상한 요청이 들어오는지, 라우터 설정이 언제 바뀌었는지 확인할 수 있다.
작은 인터넷에서는 다음 기록부터 보면 충분하다.
서버 로그인 성공과 실패 기록
웹 서버 요청과 오류 기록
방화벽이 차단한 통신 기록
DNS 질의 기록
라우터나 서버 설정 변경 기록
로그를 남기기만 하고 보지 않으면 의미가 줄어든다. 처음에는 하루에 한 번 짧게 보는 것만으로도 충분하다. 중요한 것은 "정상일 때의 모습"을 익히는 것이다. 정상적인 요청과 이상한 요청을 구분하려면 평소의 기록을 알아야 한다.
안전한 작은 인터넷의 기본 모양
이제 우리가 만든 작은 인터넷을 안전하게 다듬어 보자.
웹 서버 web.example.local은 HTTPS로 서비스한다. 사용자는 TCP 443번 포트로 접속한다. HTTP 80번 포트는 처음 테스트할 때만 열고, 운영할 때는 HTTPS로 안내하거나 닫는다. DNS 서버는 필요한 클라이언트에게만 53번 포트를 허용한다. 서버 관리는 일반 클라이언트 네트워크가 아니라 관리 네트워크에서만 가능하게 한다.
각 장비의 기본 비밀번호는 바꾼다. 서버와 라우터는 업데이트한다. 웹 서버 프로그램은 필요한 권한만 가진 계정으로 실행한다. 방화벽은 기본적으로 막고 필요한 규칙만 연다. 그리고 로그를 남겨 이상한 시도를 확인한다.
이렇게 하면 완벽한 인터넷이 되는 것은 아니다. 보안에는 끝이 없다. 하지만 연결만 되던 인터넷이 "조금 더 믿을 수 있는 인터넷"으로 바뀐다. 중요한 변화는 기술보다 태도에 있다. 문을 열 때마다 왜 열어야 하는지 묻고, 신분을 확인하고, 기록을 남기는 습관이다.
고장 나면 어디를 볼 것인가
보안 설정을 추가하면 통신이 안 되는 일이 생길 수 있다. 이때는 무작정 설정을 지우지 말고 순서대로 확인한다.
HTTPS가 안 되면 먼저 이름을 본다. 브라우저에 입력한 이름과 인증서의 도메인 이름이 같은지 확인한다. web.example.local로 접속했는데 인증서가 다른 이름으로 발급되어 있으면 경고가 뜬다.
다음은 시간이다. 인증서에는 유효 기간이 있다. 클라이언트나 서버의 시간이 크게 틀어져 있으면 아직 유효하지 않거나 이미 만료된 인증서처럼 보일 수 있다.
그다음은 포트와 방화벽이다. 웹 서버가 TCP 443번에서 기다리고 있는지, 서버 운영체제 방화벽이 막고 있지 않은지, 라우터 방화벽이 중간에서 차단하지 않는지 확인한다. HTTP는 되는데 HTTPS만 안 되면 443번 포트, 인증서, TLS 설정을 우선 본다.
방화벽 때문에 통신이 안 될 때는 규칙의 방향을 확인한다. 들어오는 규칙인지, 나가는 규칙인지, 출발지와 목적지 IP 대역이 맞는지, TCP와 UDP를 혼동하지 않았는지 본다. DNS는 주로 UDP 53번을 쓰지만 경우에 따라 TCP 53번도 필요할 수 있다. 웹은 HTTPS라면 TCP 443번이다.
로그인 문제가 생기면 기본 비밀번호를 그대로 두지 않았는지, 관리자 접속이 너무 넓게 열려 있지 않은지, 실패한 로그인 시도가 반복되는지 로그를 확인한다.
보안 문제 해결의 핵심은 "닫힌 문을 찾는 것"과 "열려 있으면 안 되는 문을 찾는 것"이다. 인터넷은 길을 만드는 일에서 시작하지만, 안전한 인터넷은 그 길에 올바른 문과 잠금장치를 놓는 일로 완성된다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.