← 메인으로

🔒 전자금융 보안 모의해킹 · 통신구간 암호화 적용

Target: 모바일/웹 거래 통신 채널
평가기준: 위험도 5 WEB-SER 통신구간 암호화
💡 쉽게 말하면
평문 통신은 내용이 보이는 우편엽서를 보내는 것과 같아, 배달부가 다 읽고 고칠 수 있습니다. HTTPS는 밀봉된 봉투를 쓰고 보내는 사람이 진짜인지 도장까지 확인하는 것입니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
거래 통신 전송🔒 Secured Channel
거래 통신이 평문(HTTP)이거나 약한 TLS·인증서 미검증으로 연결되면, 동일 네트워크의 공격자가 중간자(MITM)로 끼어들어 거래정보·자격증명을 탈취·변조할 수 있습니다.
⚡ 중간자(MITM) 평문 가로채기
mitmproxy로 HTTP 트래픽 열람·변조
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 평가기준 [전자금융] 통신구간 암호화 적용(위험도 5)
  • 전자금융감독규정 제32조: 정보처리시스템 전송구간 암호화 미흡
  • 중요정보 평문 전송 / 서버 인증서 검증 부재
🛡️ 대응 코드/설정 실습

모든 거래 통신은 HTTPS(TLS 1.2 이상)로 강제하고, 클라이언트는 서버 인증서·호스트명을 검증(필요 시 인증서 고정)해야 합니다. 아래 통신 설정을 안전하게 보완하세요.

📚 금융보안원 평가기준 / 조치 가이드

1. 점검 항목

통신 보안 > 통신구간 암호화 적용

2. 위험 분석

  • 평문 통신으로 거래정보·자격증명 탈취
  • 인증서 미검증 시 중간자 변조 공격

3. 조치 방법

  • 모든 거래 통신 HTTPS(TLS 1.2 이상) 적용
  • 서버 인증서·호스트명 검증 및 인증서 고정
  • 약한 암호스위트·구버전 프로토콜 차단
🏗️ 현대 금융 IT 환경에서의 변형
ALB 종단서비스 메시HSTS

어디가 달라졌나

클라우드에서는 TLS 가 대개 ALB·CloudFront 에서 종단됩니다. 겉보기에는 HTTPS 이지만 로드밸런서 뒤 구간이 평문인 구성이 매우 흔합니다. 평가항목은 “통신구간 암호화”인데, 점검 대상이 외부 구간만인 것으로 오해하기 쉽습니다.

현대 스택에서의 조치

  • ALB → 타깃 구간도 HTTPS 로 설정합니다. 사설 인증서라도 평문보다 낫습니다.
  • MSA 내부는 서비스 메시 mTLS(Istio PeerAuthentication: STRICT)로 자동 암호화합니다.
  • 외부에는 HSTS + preload, 리다이렉트는 301 로 HTTPS 강제. 평문 요청 자체를 없앱니다.
# Istio — 네임스페이스 전체 mTLS 강제
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata: { name: default, namespace: fin-core }
spec:
  mtls: { mode: STRICT }        # PERMISSIVE 는 평문도 받는다
놓치기 쉬운 곳 — Istio 의 기본값은 PERMISSIVE 입니다. "메시를 깔았으니 mTLS 가 된다"고 생각하지만 평문 트래픽이 그대로 통과합니다. STRICT 로 바꿨는지 확인하세요.