실무 보안 기초: PEM 키 관리부터 데이터 암호화까지

보안은 선택 사양이 아닙니다. 클라이언트가 요청 한 번 보낼 때 그 데이터가 어떤 경로를 타고 서버까지 도달하는지, 그 흐름의 각 지점에서 무엇을 지켜야 하는지를 짚어봅니다.

PEM 키 — 집 주소와 열쇠를 동시에 공개하는 것

서브 도메인 형태는 다소 보안이 강화되어 있지만, 그럼에도 불구하고 도메인은 기본적으로 공개됩니다. 도메인 스캔 툴을 쓰면 패턴 분석이 가능하고, PEM 키 이름 패턴도 유추할 수 있습니다.

여기서 흔한 실수가 발생합니다. GitHub에 프로젝트 코드를 올릴 때 PEM 파일을 함께 커밋하는 경우입니다.

공개된 도메인 = 집 주소 공개 GitHub에 올린 PEM 파일 = 열쇠 공개

주소도 알고 열쇠도 있으면 문을 열 수 있습니다. 생각보다 이런 사고 사례가 간간히 등장합니다. .gitignore에 PEM 파일을 반드시 등록하고, 이미 올라갔다면 즉시 키를 재발급해야 합니다.

certbot

UFW — 경비병과 경비대장

UFW(Ubuntu Firewall)는 네트워크의 소통과 방어를 결정하는 경비병 역할을 합니다. 그리고 리눅스의 IPTables는 그 경비병들을 통제하는 경비대장입니다. UFW는 IPTables를 더 쉽게 다루기 위한 인터페이스입니다.

# UFW 상태 확인
sudo ufw status numbered

# SSH 포트 허용 (필수)
sudo ufw allow 22

# 특정 포트 차단
sudo ufw deny 9980

# 규칙 삭제
sudo ufw delete [번호]

이 정도만 잘 관리해도 꽤 괜찮은 보안을 구성할 수 있습니다.

Docker는 UFW를 우회한다

주의해야 할 함정이 있습니다. Docker는 IPTables의 룰을 직접 따릅니다. UFW에서 아무리 차단 설정을 해도, Docker가 IPTables에 직접 규칙을 추가하기 때문에 UFW 설정이 무력화될 수 있습니다.

Docker가 UFW의 보안 정책을 수용하도록 별도 설정이 필요합니다.

1) docker 제어파일 열기
#> sudo nano/etc/docker/daemon.json

2) /etc/docker/daemon.json 파일에서
  { "iptables": true를 false로 변경 }

3) docker restart
#> sudo systemctl restart docker

특히 DB 관련 포트의 외부 접속은 반드시 차단해야 합니다.

포트	서비스
3306	MySQL
5432	PostgreSQL
27017	MongoDB
6379	Redis
9200	Elasticsearch
1521	Oracle
1433	SQL Server

이 포트들이 외부에 열려 있으면 DB가 그대로 노출됩니다. 서버 초기화로 이어질 수 있는 심각한 사고입니다.

구간 암호화 — HTTPS, TLS, SSL, 모두 같은 말입니다

Certbot을 통해 HTTPS를 적용하면 데이터가 암호화되어 전송됩니다. HTTPS, TLS, SSL, 구간 암호화는 모두 같은 개념을 다르게 부르는 것입니다.

평문 전송이 얼마나 위험한지는 수치로 나타납니다. 과거 전체 보안 사고 사례의 97%가 평문 전송에서 비롯됐습니다. 실제로 약 10여 년 전 KT에서 수천만 명의 데이터가 유출된 사고도 이 범주에 속합니다. 당시 공격자는 사람을 건드린 게 아니라 네트워크를 모니터링하다가 평문으로 오가는 파라미터를 캐치하는 방식으로 패턴을 분석했습니다.

HTTPS가 적용되면 데이터가 암호화된 상태로 전송되고 서버에서 복호화됩니다. 공격자 입장에서 네트워크를 감청해도 암호화된 값만 보입니다.

그 결과 보안 공격의 타깃이 바뀌었습니다. 네트워크와 시스템을 직접 공략하는 대신, 사람(보이스피싱, 해킹 앱)이나 데이터가 시스템으로 넘어가기 직전 원천 데이터를 노리는 방식으로 바뀌었습니다.

완벽한 보안은 없다 — 그래서 보안을 하는 이유

보안의 전제 조건이 있습니다. 완벽한 보안은 불가능하다. 대기업 보안팀도 항상 하는 말입니다.

그렇다면 왜 보안을 하는가? 정답은 시간을 버는 것입니다. 공격자가 뚫는 데 걸리는 시간을 최대한 늘려서 보안팀이 탐지하고 대처할 수 있는 여유를 만드는 것이 목적입니다. 보안은 “절대 못 뚫게 막는 것”이 아니라 “최대한 오래 버티는 것”입니다.

이 관점에서 보면 HTTPS만으로는 부족합니다. 암호화된 파이프가 어떤 이유로든 손상됐을 때, 파이프 안에 있는 데이터 자체도 보호되어 있어야 합니다.

데이터 암호화 — HTTPS 이후의 한 겹

HTTPS는 전송 구간을 암호화합니다. 하지만 서버에 도달한 데이터, DB에 저장된 데이터는 별도로 암호화해야 합니다. 이것이 데이터 암호화입니다.

단방향 암호화 — 한 번 암호화하면 끝

한 번 암호화하면 원래 값으로 되돌릴 수 없습니다. 암호화된 값 그 자체로 사용합니다.

대표 알고리즘:

알고리즘	특징
SHA2 (SHA-256/512)	오랫동안 쓰인 표준, GPU 브루트포스에 취약해지는 중
Bcrypt	여전히 널리 사용
SHA3	SHA2의 후속, 더 강화된 구조
ARGON2	2015년 암호 해싱 대회 우승. 메모리 사용량 조절 가능 → GPU 기반 공격에 강함
Scrypt	메모리 하드 함수, Argon2와 함께 최근 인기 급상승
PBKDF2	Django 기본 암호화 방식

최근에는 Argon2, Scrypt, SHA3, Bcrypt 4가지의 사용이 특히 늘고 있습니다. Argon2가 강력한 이유는 메모리 사용량을 공격자에게 불리하게 설정할 수 있어 GPU 기반 병렬 공격에 매우 강하기 때문입니다.

적용 대상: 패스워드처럼 원래 값으로 쓸 필요 없는 데이터.

양방향 암호화 — 필요할 때 다시 꺼낼 수 있는 암호화

암호화했다가 필요시 원래 값으로 복호화할 수 있습니다.

대칭키 암호화 — 암호화/복호화에 같은 키 사용:

알고리즘	특징
AES-256	현재 가장 많이 쓰이는 대칭키 표준
ChaCha20	최근 급부상, GPU/메모리 환경에서 유리

비대칭키 암호화 — 공개키로 암호화, 개인키로 복호화:

알고리즘	특징
RSA	PEM 키 암호화에 사용되는 방식, 오랫동안 쓰인 표준
ECC	최근 인기 급상승, 더 짧은 키로 RSA와 동등한 보안

적용 대상: 계좌번호, 주민등록번호, 위치정보처럼 나중에 원래 값이 필요한 데이터.

암호화 적용 기준

적용 방식	대상
단방향	원래 모습으로 사용할 일 없는 데이터 (패스워드 등)
양방향	원래 모습으로 사용해야 하는 데이터 (계좌번호, 주민번호, 위치정보 등)
미적용	중요도가 낮은 데이터

주민등록번호, 계좌번호처럼 법적으로 민감한 데이터는 저장 자체를 매우 신중하게 판단해야 합니다.

로그 관리 — 5W1H로 기록하기

보안 사고가 났을 때 추적할 수 있으려면 로그가 있어야 합니다. 로그 기록의 기준은 5W1H(육하원칙)입니다.

어떤 디바이스에서, 어떤 요청이, 어떤 데이터를, 어떻게 처리했는지를 남깁니다. 금융권에서는 DB에도 별도의 암호화 프로시저를 두는 경우가 많습니다.

부하 분산 — 하나의 서버 안에서도 적용됩니다

부하 분산(Load Balancing)은 트래픽을 여러 서버에 효율적으로 분배해 성능과 가용성을 높이는 기법입니다. EC2 한 대를 쓰더라도 그 안에서 Nginx가 여러 애플리케이션으로 트래픽을 분산한다면, 이것도 부하 분산입니다.

핵심 질문은 “어디로, 무엇을, 얼마나, 어떻게 보낼 것인가”입니다.

서비스	특징
L4LB	하드웨어 로드밸런서
NGINX	소프트웨어 방식, 로드밸런싱 기능 내장 (활성화 필요)
HAProxy	오픈소스, 네이버 내부에서 활발히 사용 중

정답이 정해진 것은 아닙니다. 요구사항과 목적에 따라 적절한 방식을 선택하면 됩니다.

JWT와 추가 보안 기법들

JWT(JSON Web Token)는 Stateless하고 확장성이 높은 사용자 인증/권한 부여 방식입니다. HTTP 프로토콜의 특성에 잘 맞아 많이 쓰입니다.

JWT 외에도 활용할 수 있는 보안 기법들이 있습니다.

• Blacklist / Whitelist: 허용/차단 IP나 토큰 목록 관리
• Rate Limiting: 단위 시간당 요청 횟수 제한
• Throttling: 요청 속도를 조절해 과부하 방지
• 보안 코드 필터: 입력값의 악성 패턴 필터링
• 서비스 디스커버리: 마이크로서비스 환경에서 서비스 위치를 동적으로 관리