네트워크 보안
오가는 데이터를 지키는 TLS와 인증서, 경계를 지키는 장치들이다.
목차 (9)
TLS: 오가는 데이터를 지키는 세 가지 약속
인터넷의 패킷은 집 공유기, 통신사, 여러 중계 장비를 거쳐 간다. 그 길 위의 누구든 내용을 읽거나 바꿀 수 있다고 가정하는 것이 네트워크 보안의 출발점이다. TLS(Transport Layer Security)는 그 길 위에 세 가지를 약속한다. 남이 못 읽게 하는 기밀성, 바뀌면 알아채는 무결성, 그리고 지금 말하는 상대가 진짜 그 서버라는 인증이다. 암호 쪽 기초(대칭 암호, 키 교환, 서명)는 암호 노트에 있다.
현재 판은 RFC 8446(2018)의 TLS 1.3이다. 핸드셰이크(handshake)는 본 대화 전에 쓸 암호와 키를 정하는 짧은 인사다. TLS 1.3은 첫 메시지부터 키 교환 공개값을 실어 보내므로, 서버의 첫 답장 뒤로는 인증서까지 모두 암호화되고 왕복 한 번(1-RTT)이면 데이터를 보낼 수 있다.
클라이언트가 ClientHello를 보낸다. 지원하는 암호 묶음과 함께 키 교환용 공개값(key_share)을 미리 담는다.
핵심은 키 교환과 인증이 따로 움직인다는 점이다. 대칭 키는 양쪽이 즉석에서 만든 일회용 공개값(ECDHE)으로 정하고, 서버의 장기 개인키는 "이 대화에 내가 참여했다"는 서명에만 쓴다. 그래서 나중에 서버 개인키가 새어도 지난 대화를 풀 수 없다. 이 성질을 순방향 비밀성(forward secrecy)이라 한다.
| 바뀐 점 | TLS 1.2까지 | TLS 1.3 |
|---|---|---|
| 왕복 수 | 전체 핸드셰이크에 두 번 | 한 번. 재접속은 0-RTT도 가능하지만 재전송(replay)에 약해 안전한 요청에만 쓴다 |
| 키 교환 | RSA로 키를 그대로 실어 보내는 방식도 허용 | 일회용 (EC)DHE만 남아 순방향 비밀성이 기본이다 |
| 암호 묶음 | CBC 모드, RC4 등 문제가 알려진 조합도 고를 수 있음 | AES-GCM, ChaCha20-Poly1305 같은 인증 암호(AEAD)만 |
| 인증서 | 평문으로 보임 | 암호화되어 엿보는 사람이 볼 수 없다 |
TLS 1.0과 1.1은 RFC 8996으로 공식 폐기되었다. 서버 설정의 기준은 미국 표준기술연구소의 NIST SP 800-52 Rev. 2가 좋은 출발점이다. TLS는 웹만의 것이 아니다. 메일, DNS(아래 DoT·DoH), 그리고 P2P 화상 통화가 쓰는 WebRTC도 UDP용 변형인 DTLS로 키를 정한다.
인증서와 PKI: 공개키가 진짜 그 사이트의 것인가
키 교환은 상대가 누구든 비밀 키를 만들어 준다. 중간에 끼어든 사람과 만들어도 마찬가지다. 그래서 "이 공개키가 정말 example.com의 것"이라는 보증이 필요하고, 이것이 인증서(certificate)다. 인증서는 도메인 이름, 공개키, 유효기간을 적고 인증 기관(CA, Certificate Authority)이 서명한 문서이며, 형식은 RFC 5280의 X.509다.
이 구조 전체를 공개키 기반 구조(PKI, Public Key Infrastructure)라 한다. 약점도 구조에서 나온다. 신뢰 저장소에 있는 CA 중 하나라도 잘못 발급하면 어떤 도메인의 가짜 인증서든 만들어질 수 있다. 이를 막는 장치가 인증서 투명성(Certificate Transparency)이다. CA가 발급한 인증서를 누구나 볼 수 있는 추가 전용 로그에 남기게 하고, 브라우저는 로그에 없는 인증서를 거부한다. 도메인 주인은 로그를 지켜보다 모르는 발급을 찾아낼 수 있다.
| 과정 | 하는 일 |
|---|---|
| 발급 | CA는 신청자가 그 도메인을 실제로 다루는지 확인한다. Let's Encrypt는 ACME 프로토콜로 정해진 파일이나 DNS 레코드를 올리게 해 자동으로 확인한다 |
| 검증 | 브라우저는 서명 사슬, 이름 일치, 유효기간, 폐기 여부, 투명성 로그 기록을 확인한다 |
| 폐기 | 개인키가 새면 만료 전에 인증서를 무효로 한다. 폐기 확인이 늘 믿을 만하지 않아, 유효기간을 짧게(90일 등) 두고 자주 갱신하는 쪽으로 가고 있다 |
지금 쓰는 루트와 중간 인증서의 실제 사슬은 Let's Encrypt의 인증서 목록에서 볼 수 있다. 공개키 암호의 원리는 데이터 노트의 암호와 해시 절에 그림으로 있다.
HTTPS와 HSTS: 처음 한 번의 틈까지 막기
HTTPS는 HTTP를 TLS 안에 넣어 보내는 것뿐이다. 문제는 사람이 주소창에 example.com만 치면 브라우저가 예전 습관대로 http://로 먼저 갈 수 있다는 점이다. 서버가 https로 넘겨 주기 전의 그 첫 요청은 평문이라, 공용 Wi-Fi 같은 곳에서는 중간에서 응답을 바꿔 사용자를 계속 http에 붙잡아 둘 수 있다.
HSTS(HTTP Strict Transport Security, RFC 6797)는 서버가 HTTPS 응답에 다음 헤더를 실어 "앞으로 이 기간에는 https로만 오라"고 기억시키는 장치다. 브라우저는 그 기간 동안 http 링크도 보내기 전에 https로 바꾸고, 인증서 오류가 나면 사용자가 무시하고 넘어갈 수 없게 막는다.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload남는 틈은 정말 처음 방문하는 순간이다. 이것은 브라우저에 미리 넣어 두는 목록인 HSTS 프리로드로 막는다. 목록에 오르면 하위 도메인까지 모두 https여야 하고 빠지기도 오래 걸리므로, 모든 하위 도메인이 준비된 뒤 신청한다. 헤더 각 항목의 뜻은 MDN의 Strict-Transport-Security 문서에 있다. 쿠키를 https로만 보내게 하는 Secure 속성은 웹 보안 노트에서 다룬다.
HTTPS로 보내는 비밀번호를 브라우저에서 한 번 더 해시·암호화할 필요가 없는 이유는 보안 › 인증과 인가에 있다.
방화벽과 NAT: 경계에서 거르기
방화벽(firewall)은 정한 규칙에 따라 패킷을 통과시키거나 버리는 장치나 프로그램이다. 규칙의 기본값은 "명시적으로 허용한 것만 통과"(기본 거부)가 원칙이다. 미국 표준기술연구소의 NIST SP 800-41 Rev. 1은 방화벽 종류와 정책 짜는 법을 정리한 지침이다.
| 종류 | 보는 것 | 예 |
|---|---|---|
| 패킷 필터 | 패킷 하나의 주소, 포트, 프로토콜 | "밖에서 22번 포트로 오는 것은 버린다" |
| 상태 기반(stateful) | 연결 단위. 안에서 연 연결의 답장인지 기억한다 | 집 공유기, 운영체제 기본 방화벽 |
| 애플리케이션 계층 | HTTP 요청 내용 같은 응용 데이터 | 웹 애플리케이션 방화벽(WAF), 프록시 |
| 호스트 방화벽 | 그 컴퓨터 한 대로 드나드는 것 | 노트북을 공용 Wi-Fi에 붙일 때 마지막 방어선 |
NAT(Network Address Translation)는 공인 IP 하나를 집 안 여러 기기가 나눠 쓰게 하는 주소 변환이다. 원리는 네트워크 노트의 주소 절에 있다. 기록에 없는 연결을 받을 수 없으니 부수 효과로 방화벽처럼 동작하지만, 목적이 보안은 아니다. 포트 포워딩이나 UPnP로 연 구멍은 그대로 바깥에 드러나고, IPv6에서는 기기마다 공인 주소를 받으므로 NAT 없이 방화벽 규칙이 그 역할을 맡아야 한다.
경계 방화벽만 믿는 설계는 한 번 안으로 들어오면 모든 것에 닿을 수 있다는 약점이 있다. 그래서 요즘은 내부 망도 믿지 않고 요청마다 사용자와 기기를 확인하는 제로 트러스트(zero trust) 방식과, 망을 잘게 나누는 분할(segmentation)을 함께 쓴다. 한 겹이 뚫려도 버티는 설계는 보안의 기초의 심층 방어와 같은 생각이다.
방화벽이 규칙에 맞는지 보고 통과시킨다면, 침입 탐지 시스템(IDS, intrusion detection system)은 통과한 흐름 속에서 공격의 흔적을 찾아 경보를 낸다. 알려진 공격 모양(시그니처)과 맞춰 보거나 평소와 다른 흐름(이상 행위)을 잡는다. 탐지에 그치지 않고 그 자리에서 연결을 끊거나 패킷을 버리면 침입 방지 시스템(IPS)이다. IPS는 흐름 한가운데에 서야 해서 오탐이 정상 업무를 막을 수 있고, IDS는 옆에서 사본을 보므로 안전하지만 막지는 못한다. 네트워크에 두는 것, 서버마다 두는 것(호스트 기반), 무선용이 있고, 미국 NIST의 SP 800-94가 종류와 배치를 정리한다. 요즘은 방화벽에 IPS 기능을 합친 장비가 흔하고, 이들이 낸 경보는 보안 관제로 모인다.
VPN: 믿지 못하는 구간 위에 터널 만들기
VPN(Virtual Private Network)은 원래 패킷을 통째로 암호화해 다른 패킷 안에 싸서 보내는 터널이다. 중간 구간에서는 바깥 포장만 보이고, 반대편 VPN 서버가 포장을 풀어 원래 목적지로 보낸다.
| 쓰임 | 모습 | 주로 쓰는 프로토콜 |
|---|---|---|
| 원격 접속 | 집이나 출장지 노트북을 회사 내부망에 붙인다 | IPsec, TLS 기반 VPN, WireGuard |
| 사이트 간(site-to-site) | 지사와 본사 망을 인터넷 위에서 하나로 잇는다 | IPsec |
| 개인용 VPN 서비스 | 카페 Wi-Fi나 통신사로부터 접속 기록을 가린다 | WireGuard, OpenVPN 등 |
VPN은 엿보는 사람을 없애지 않고 자리를 옮긴다. 통신사 대신 VPN 운영자가 목적지를 보게 되므로, 개인용 VPN은 그 운영자를 통신사보다 더 믿을 때만 의미가 있다. 또 이미 HTTPS로 지켜지는 내용을 한 번 더 감쌀 뿐이라, 피싱이나 악성 프로그램을 막아 주지는 않는다. IPsec VPN을 설계할 때의 기준은 NIST SP 800-77 Rev. 1에 정리되어 있다.
망분리: 업무망과 인터넷망을 떼어 놓는다
망분리(network separation)는 내부 업무 시스템이 있는 업무망과 메일·웹 검색에 쓰는 인터넷망을 나눠, 업무용 PC가 인터넷에 직접 닿지 않게 하는 설계다. 인터넷에서 들어오는 악성코드와 피싱이 업무 서버까지 오는 길을 끊고, 업무 자료가 인터넷으로 곧장 새는 길도 끊는다. 한국에서는 공공기관과 금융회사에 규제로 의무화되면서 널리 퍼져, 보안 일을 하면 가장 먼저 마주치는 말 가운데 하나다.
두 망을 아예 끊어 사람이 손으로만 자료를 옮기게 한 상태는 에어 갭(air gap)이라 한다. 한국의 망분리는 대개 그보다 한 걸음 느슨해서, 두 망 사이에 검사하는 통로(망연계)를 하나 둔다.
| 방식 | 모습 | 좋은 점 | 약한 점 |
|---|---|---|---|
| 물리적 망분리 | 사람마다 인터넷 PC와 업무 PC 두 대, 망 장비와 회선도 따로 둔다 | 두 망 사이에 연결이 아예 없어 가장 확실하다 | 장비가 두 벌이라 비용과 자리가 들고, 두 PC를 오가는 일이 번거롭다 |
| 논리적 망분리(서버 기반) | PC 한 대. 한쪽 환경은 서버에서 도는 가상 데스크톱(VDI)이나 서버에서 브라우저·앱만 띄워 보내는 방식(SBC)의 화면으로 쓴다 | PC가 한 대로 줄고, 인터넷에서 받은 파일이 서버에 남아 PC로 내려오지 않는다 | 가상화 서버와 화면 전송 경로가 새 공격면이 되고, 서버가 멈추면 그쪽 업무가 함께 멈춘다 |
| 논리적 망분리(PC 안 가상화) | PC 한 대 안에서 소프트웨어로 격리한 두 환경을 나눠 쓴다 | 서버를 따로 두지 않아도 된다 | 같은 하드웨어와 운영체제 위라, 격리가 뚫리면 두 환경이 함께 위험해진다 |
서버 기반 방식이 화면만 보내고 입력만 받는 원리는 가상화 노트의 원격 데스크톱 절에 있다.
망을 나눠도 업무에는 자료가 오가야 한다. 인터넷 메일로 받은 첨부를 업무망으로 들이고(반입), 업무망에서 만든 자료를 밖으로 보낸다(반출). 이 일을 맡는 것이 망연계(자료 전송) 시스템이다. 두 망에 한 발씩 걸친 서버가 파일을 받아 검사하고 건너편에 내려놓을 뿐, 두 PC 사이에 연결을 열어 주지는 않는다. 더 엄격한 곳은 데이터가 물리적으로 한 방향으로만 흐르는 데이터 다이오드(일방향 게이트웨이)를 쓴다. 보안 등급이 다른 영역 사이에서 정보를 통제하며 옮기는 장치를 통틀어 교차 도메인 솔루션(CDS, cross domain solution)이라 부르기도 한다.
인터넷 PC에서 받은 회의자료.pdf을 업무 PC로 옮기려 한다. 두 PC 사이에는 연결이 없어, 파일을 망연계 시스템에 올린다.
망연계는 두 망을 잇는 유일한 다리라서 그 자체가 가장 노려지는 곳이다. 검사를 빠져나가는 파일 형식, 망연계 서버의 취약점, 관리자 계정 탈취가 모두 두 망을 다시 잇는 길이 된다. 그래서 망연계 서버는 패치, 접근 통제, 로그 감시를 가장 엄격하게 둔다.
한국에서 망분리가 자리 잡고 다시 바뀌어 온 흐름은 이렇다.
- 공공기관: 2006년 일부 기관의 시범을 거쳐 2007년 지침, 2008년 국가정보원 가이드라인으로 국가·공공기관에 넓혀졌다(바이라인네트워크의 망분리 해설).
- 금융권: 2011년 4월 농협 전산망 마비 사태와 2013년 3월 20일 방송사·은행 전산망이 한꺼번에 멈춘 3·20 전산 대란을 거치며 규제가 강해졌다. 금융위원회의 2013년 7월 금융전산 보안 강화 종합대책은 전산센터의 물리적 망분리를 2014년 말까지 의무화하고, 본점과 영업점은 단계적으로 망분리하게 했다.
- 기업: 2012년부터는 이용자 수나 매출이 일정 규모를 넘는 정보통신 서비스 기업도 개인정보를 다루는 PC를 망분리하도록 요구받았다(같은 해설).
- 금융권 완화: 금융위원회는 2024년 8월 금융분야 망분리 개선 로드맵을 내고, 도입 뒤 약 10년 동안 쌓인 업무 비효율과 신기술 제약을 이유로 규제 샌드박스를 통해 생성형 AI 활용을 허용하고 SaaS 이용 범위를 넓히고 연구·개발 환경을 고치기로 했다. 중장기로는 금융회사가 위험을 스스로 평가해 통제를 정하고 사고에는 책임을 더 지는 '자율보안-결과책임' 원칙의 체계와, 가칭 디지털 금융보안법을 제시했다.
- 공공 개편(N2SF): 국가정보원은 2025년 1월 국가 망 보안체계(N2SF) 가이드라인 초안을, 9월에 1.0 정식판을 냈다. 업무 정보와 시스템을 기밀(C)·민감(S)·공개(O) 세 등급으로 나누고 등급마다 보안 통제를 골라 거는 방식으로, 모든 업무를 같은 벽으로 끊던 망분리를 데이터 중요도에 따른 차등 통제로 바꾼다. 초안은 통제 항목을 권한, 인증, 분리 및 격리, 통제, 데이터, 정보자산의 여섯 영역으로 묶었고, 정식판은 항목을 280여 개로 늘리며 제로 트러스트의 "항상 검증, 최소 권한" 원칙을 보안 대책 수립의 기준으로 넣었다.
| 견줄 점 | 망분리가 해 주는 것 | 남는 문제 |
|---|---|---|
| 바깥 공격 | 인터넷 PC가 감염돼도 업무망까지 이어진 연결이 없다 | 망연계, 프로그램 배포·관리 서버, 외주 장비처럼 두 망을 잇는 예외가 생기면 그 길로 들어온다 |
| 자료 유출 | 업무 자료가 인터넷으로 곧장 나가지 않는다 | USB 같은 이동식 매체, 화면 촬영, 권한 있는 내부자의 반출은 막지 못해 매체 통제와 반출 기록이 따로 필요하다 |
| 일하는 방식 | 정해진 통로 밖의 자료 이동을 줄인다 | 두 PC를 오가야 하고, 클라우드·SaaS·생성형 AI·오픈 소스 저장소를 업무망에서 바로 쓰기 어렵다. 개발자를 뽑기 어렵다는 호소도 나온다 |
| 안쪽의 신뢰 | 경계를 한 겹 더 두껍게 세운다 | 업무망 안은 여전히 평평하게 믿는 경우가 많아, 한 번 들어온 공격자는 옆으로 이동하기 쉽다 |
실제 사고도 이런 예외에서 났다. 농협 사태에서는 서버 관리에 쓰던 외주 직원의 노트북이 감염돼 공격의 발판이 됐고, 3·20 때는 사내 PC에 프로그램을 배포하는 관리 서버가 악성코드를 퍼뜨린 통로로 지목됐다. 망을 나눴어도 두 망을 오가는 사람, 장비, 업데이트 경로가 곧 경계다.
망분리는 경계 보안을 버린 것이 아니라 성벽을 한 겹 더 두껍게 쌓은 것이다. 안쪽이면 믿는다는 경계 보안의 약점(제로 트러스트 노트의 첫 절)은 그대로 남는다. 제로 트러스트는 위치 대신 요청마다 신원, 기기 상태, 데이터 민감도로 판단하고, 마이크로세그멘테이션으로 안쪽도 잘게 나눈다. 둘은 양자택일이 아니어서, N2SF처럼 중요한 데이터일수록 분리와 격리를 강하게 걸고 나머지는 신원과 기기를 확인하는 통제로 여는 혼합이 지금 한국 규제가 가는 방향이다.
DNS 보안: 주소록이 거짓말하지 않게
DNS는 이름을 IP 주소로 바꾸는 인터넷의 주소록이다. 전통적인 DNS 질의와 응답은 평문 UDP라 두 가지 문제가 있다. 길 위에서 어떤 사이트를 찾는지 엿볼 수 있고, 가짜 응답을 끼워 넣어 사용자를 엉뚱한 서버로 보낼 수 있다(DNS 스푸핑, 캐시 오염). 두 문제는 해결책이 다르다.
| 방법 | 막는 것 | 방식 |
|---|---|---|
| DNSSEC (RFC 4033 등) | 위조. 응답이 진짜 그 도메인 주인이 낸 것인지 | 레코드에 서명하고 상위 영역이 하위 영역 키를 보증한다. 내용을 숨기지는 않는다 |
| DoT (DNS over TLS, RFC 7858) | 엿보기와 길 위의 변조 | 전용 포트 853에서 TLS로 질의한다. 망 관리자가 DNS 흐름을 구별하기 쉽다 |
| DoH (DNS over HTTPS, RFC 8484) | 엿보기와 길 위의 변조 | 보통의 HTTPS(443) 요청으로 질의해 웹 통신과 섞인다. 브라우저가 직접 쓰기도 한다 |
DoT·DoH는 리졸버까지만 지키므로 그 리졸버 운영자는 여전히 질의를 본다. 반대로 DNSSEC은 서명을 확인할 뿐 질의 내용을 숨기지 않는다. 둘은 경쟁이 아니라 서로 다른 구멍을 메운다. 그리고 DNS가 속더라도 HTTPS 사이트라면 가짜 서버는 올바른 인증서를 내밀 수 없어 브라우저가 경고한다. 여러 겹이 함께 지키는 셈이다.
DDoS: 막을 수 없으면 흡수한다
서비스 거부(DoS, Denial of Service) 공격은 데이터를 훔치는 대신 서비스를 못 쓰게 만든다. 수많은 기기(감염된 PC, 공유기, IoT 기기로 이루어진 봇넷)를 동원하면 분산 서비스 거부(DDoS)가 된다. 정상 요청과 공격 요청이 겉보기에 같을 때가 많아, 한곳에서 다 막으려 하기보다 넓게 받아 나눠 거르는 쪽으로 방어한다.
| 종류 | 노리는 것 | 대표적인 방어 |
|---|---|---|
| 볼륨형 | 회선 대역폭. 양으로 관을 막는다 | 큰 용량의 Anycast 망·CDN이 흡수, 통신사 단의 필터링 |
| 프로토콜형 | 연결 상태를 기억하는 장비의 표(예: 반쯤 열린 TCP 연결) | SYN 쿠키처럼 상태를 미루는 기법, 상태표 크기와 시간 제한 조정 |
| 애플리케이션 계층 | 무거운 페이지나 검색처럼 서버가 많이 일하는 요청 | 캐시, 속도 제한(rate limiting), 봇 판별, WAF 규칙 |
볼륨형 공격 중에는 출발지 주소를 피해자 주소로 속여, 작은 질문에 큰 답을 돌려주는 공개 서버들이 피해자에게 답을 쏟게 만드는 반사·증폭 방식이 있다. 근본 대책은 망 운영자들이 자기 망에서 나가는 패킷의 출발지 주소를 검사해 위조된 것을 버리는 것으로, BCP 38(RFC 2827)로 정리되어 있다. 서비스 운영자가 할 일은 공격 전에 정해 둔다. 원본 서버 주소를 감추고, 보호 서비스와 연락 경로를 마련하고, 평소 트래픽 기준선을 알아 둔다. 이 준비는 CISA의 DDoS 대응 안내에 단계별로 정리되어 있다.
Wi-Fi 보안: WPA2에서 WPA3로
무선은 전파가 벽 밖까지 나가므로 근처의 누구든 신호를 받을 수 있다. 그래서 Wi-Fi 보안은 누가 접속할 수 있는지(인증)와 오가는 프레임을 암호화하는 일을 함께 맡는다. 규격의 인증 프로그램은 Wi-Fi Alliance가 운영한다.
| 방식 | 상태 | 요점 |
|---|---|---|
| WEP | 쓰면 안 된다 | 암호 설계 결함으로 짧은 시간에 키가 드러난다 |
| WPA (TKIP) | 쓰면 안 된다 | WEP 장비에서 돌리려고 만든 임시방편이다 |
| WPA2 (AES-CCMP) | 아직 널리 쓰인다 | 암호화는 튼튼하지만, Personal 모드는 비밀번호가 약하면 오프라인 대입에 뚫린다 |
| WPA3 | 권장 | Personal은 SAE로 오프라인 대입을 막고, Enterprise는 더 강한 암호 묶음을 고를 수 있다 |
SAE(Simultaneous Authentication of Equals)는 비밀번호를 바탕으로 한 키 교환으로, 양쪽이 같은 비밀번호를 안다는 것을 비밀번호 자체를 흘리지 않고 서로 증명한다. 집과 사무실에서 할 일은 단순하다. 공유기와 기기가 지원하면 WPA3(아니면 WPA2-AES)를 고르고, 긴 비밀번호를 쓰고, 공유기 펌웨어를 갱신하고, 쓰지 않는 WPS는 끈다.
카페의 비밀번호 없는 공개 Wi-Fi는 원래 전혀 암호화되지 않았다. Wi-Fi Enhanced Open은 RFC 8110의 OWE로 비밀번호 없이도 기기마다 따로 암호화한다. 다만 상대 AP가 진짜인지는 증명하지 않으므로, 공용 망에서는 여전히 HTTPS와 위의 HSTS가 실제 내용을 지킨다.
- Transport Layer Security — Wikipedia
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 — IETF
- RFC 8996: Deprecating TLS 1.0 and TLS 1.1 — IETF
- SP 800-52 Rev. 2: Guidelines for TLS Implementations — NIST
- RFC 5280: Internet X.509 PKI Certificate and CRL Profile — IETF
- Certificate Transparency
- How It Works — Let's Encrypt
- Chains of Trust — Let's Encrypt
- RFC 6797: HTTP Strict Transport Security (HSTS) — IETF
- HSTS Preload List Submission
- Strict-Transport-Security — MDN
- SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy — NIST
- SP 800-77 Rev. 1: Guide to IPsec VPNs — NIST
- RFC 4033: DNS Security Introduction and Requirements — IETF
- RFC 7858: DNS over TLS — IETF
- RFC 8484: DNS Queries over HTTPS (DoH) — IETF
- RFC 2827 (BCP 38): Network Ingress Filtering — IETF
- Understanding and Responding to DDoS Attacks — CISA
- Wi-Fi Security — Wi-Fi Alliance
- RFC 8110: Opportunistic Wireless Encryption — IETF
- SP 800-94: Guide to Intrusion Detection and Prevention Systems — NIST
- Air gap — NIST Glossary
- Data diode — NIST Glossary
- Cross domain solution — NIST Glossary
- 금융전산 보안 강화 종합대책(2013) — 금융위원회
- 금융분야 망분리 개선 로드맵(2024) — 금융위원회
- 망분리 해설(2024) — 바이라인네트워크
- 국가 망 보안체계(N2SF) 가이드라인 초안 — 바이라인네트워크
- 국가 망 보안체계(N2SF) 가이드라인 1.0 — 바이라인네트워크
- 농협 전산망 마비 사태 — 위키백과
- 3·20 전산 대란 — 위키백과