저장 시 암호화 vs 전송 중 암호화: 보안에 둘 다 중요

전송 중 암호화는 두 지점 사이를 이동하는 데이터를 보호합니다 — 예를 들어 브라우저와 서버 사이를 TLS 1.3의 AES-256-GCM 또는 ChaCha20-Poly1305로 보호합니다. 저장 시 암호화는 디스크에 있는 데이터를 보호합니다. 보통 전체 디스크 암호화에는 AES-256-XTS, 파일별 암호화에는 AES-256-GCM을 사용합니다. 하나만으로는 충분하지 않습니다. TLS는 네트워크 도청을 막지만 서버에서 복호화됩니다. 저장 시 암호화는 보관 데이터를 보호하지만 키가 암호문 옆에 있으면 의미가 없습니다. 진정한 보안은 두 가지를 함께 적용하는 데서 나오며, 이상적으로는 클라이언트 측(엔드투엔드) 암호화를 추가하여 서버가 평문을 전혀 보지 못하게 합니다.

두 가지 다른 위협, 두 가지 다른 통제

위협의 양상은 데이터의 위치에 따라 다릅니다.

전송 중(네트워크 경로): 커피숍에서 패킷 스니퍼를 실행하는 공격자, 침해된 ISP 라우터, 해저 케이블을 도청하는 국가 수준 행위자. 2013년 스노든 문서는 NSA의 MUSCULAR 프로그램이 구글 내부 광섬유 링크를 도청했음을 폭로했습니다. 방어 수단: TLS 1.3, 앱에는 인증서 피닝 권장.

저장 시(스토리지): 도난된 노트북, 유출된 백업 테이프, 잘못 구성된 S3 버킷, 디스크 접근 권한이 있는 불량 데이터센터 직원. 2017년 Equifax 침해는 데이터가 암호화되지 않은 채로 저장되어 1억 4,700만 건의 기록이 노출되었습니다. 방어 수단: 디스크에는 LUKS, BitLocker, FileVault; 파일별 또는 블록별로는 AES-256-GCM 또는 AES-256-XTS.

하나를 다른 것의 대체물로 취급하는 것이 실수입니다. TLS는 데이터베이스 덤프를 보호하지 않습니다. 디스크 암호화는 중간자 공격을 막지 않습니다.

TLS 1.3이 전송 중 데이터를 보호하는 방법

RFC 8446(2018)으로 표준화된 TLS 1.3은 현대의 기본값입니다. 다음을 사용합니다.

기본 순방향 비밀성: 임시 ECDHE 키 교환. 서버의 장기 키가 유출되어도 과거 세션은 보호됩니다.
AEAD 암호만 사용: AES-128-GCM, AES-256-GCM, 또는 ChaCha20-Poly1305. 구식 CBC 모드와 RC4는 제거됩니다.
단일 라운드트립 핸드셰이크(1-RTT) 또는 재개를 위한 제로 라운드트립(0-RTT).
암호화된 핸드셰이크: 수동 관찰자가 인증서 체인을 볼 수 없습니다.

WeTransfer, SwissTransfer, Tresorit, Proton Drive, HexaTransfer 모두 최소 12개월의 HSTS 헤더로 HTTPS를 강제하는 TLS 1.3을 운영합니다. SSL Labs의 testssl 도구로 검증할 수 있습니다.

서버의 저장 시 암호화 작동 방식

파일이 도착하고 TLS가 종료되면 저장 시 암호화가 시작됩니다. 여러 계층이 있습니다.

블록 수준(전체 디스크): LUKS(Linux), BitLocker(Windows), FileVault(macOS) 또는 AWS EBS 암호화 같은 클라우드 제공자 동등물의 AES-256-XTS. 도난된 디스크를 보호합니다.
파일 시스템 수준: eCryptfs, ext4/F2FS의 Fscrypt. 사용자별 파일을 별도 키로 암호화합니다.
객체 스토리지 수준: AWS S3 SSE-KMS, Azure Blob 스토리지 서비스 암호화, Google Cloud Storage의 고객 관리 키. 각 객체를 AES-256-GCM으로 암호화합니다.
애플리케이션 수준: 서비스가 스토리지에 쓰기 전 자체 코드에서 각 파일을 암호화하고, 키는 KMS나 HSM에 보관합니다.

애플리케이션 수준이 가장 강력합니다. 어떤 스토리지 시스템도 데이터를 보기 전에 암호화가 이루어지기 때문입니다.

"암호문 옆의 키" 함정

저장 시 암호화가 흔히 실패하는 지점입니다. 키가 암호문과 같은 서버에 저장되면, 서버를 침해한 공격자가 둘 다 얻습니다. 제공자는 기술적으로 "저장 시 암호화" 컴플라이언스 항목을 체크하면서도 서버 침해에 대한 실질적 보호를 전혀 제공하지 않을 수 있습니다.

좋은 아키텍처는 관심사를 분리합니다.

암호문: S3 또는 유사 객체 스토리지.
암호화 키: AWS KMS, Google Cloud KMS, Azure Key Vault, 또는 전용 HSM.
키에 대한 접근: 단기 IAM 자격 증명과 감사 로그로 제어.

훌륭한 아키텍처는 한 발 더 나아갑니다. 클라이언트 측 암호화(E2EE)를 사용하면 키가 서버에 전혀 존재하지 않습니다. 사용자의 브라우저가 키를 생성하고, 파일을 암호화하고, 키를 보관합니다. 서버는 암호문을 저장하고 유출할 것이 없습니다.

암호화 공백이 생기는 곳

두 가지 통제가 모두 있어도 데이터가 잠시 평문 상태가 되는 곳이 있습니다.

업로드 처리, 바이러스 검사, 썸네일 생성 중 서버 메모리 내에서.
액세스 로그에 파일명이나 내용 스니펫이 디버깅용으로 기록되는 경우.
백업이 같은 암호화를 상속받지 않는 경우 백업 테이프에서.
서비스가 파일 내용을 처리하는 압축 또는 트랜스코딩 중에.
사용자가 캐시를 지우지 않으면 다운로드 후 브라우저 캐시에서.

이런 공백들이 영지식(클라이언트 측) 암호화가 중요한 이유입니다. 업로드 전 브라우저에서 파일이 암호화되면, 서버 측 공백은 무관합니다 — 서버는 항상 암호문만 봅니다.

주요 서비스의 실제 구현

공개 문서를 기반으로 한 대략적인 분류:

Google Drive, Dropbox, OneDrive: 전송 중 TLS 1.3, 저장 시 제공자 키의 AES-256. 영지식 아님.
WeTransfer(무료 티어): 전송 중 TLS 1.3, AWS S3에 AES-256 저장 시 암호화. 제공자가 키 보유.
Box Enterprise: 전송 중 TLS 1.3, 저장 시 AES-256-GCM, 선택적 고객 관리 키(Box KeySafe).
Tresorit, Proton Drive, SwissTransfer E2EE 티어, HexaTransfer: 전송 중 TLS 1.3, 저장 시 AES-256-GCM이지만 파일별 키는 클라이언트 생성이며 서버에 도달하지 않습니다. 사실상 영지식.

민감한 데이터에는 마지막 범주만이 내부자 위협과 유효한 법적 요구에 대해 의미 있는 보호를 제공합니다.

컴플라이언스와 심층 방어 의무

규제 기관은 명시적으로 둘 다 요구합니다.

GDPR 제32조: 데이터가 어느 상태에 있든 개인 데이터의 "가명 처리 및 암호화"를 의무화합니다.
HIPAA 보안 규칙 45 CFR § 164.312: 전송 중 및 저장 시 ePHI 암호화를 모두 요구합니다.
PCI DSS 4.0 요구사항 3 및 4: "저장된 카드 소지자 데이터 보호"(저장 시)와 "전송 중 강력한 암호화로 카드 소지자 데이터 보호"(전송 중)를 분리합니다.
한국 개인정보보호법(PIPA): 개인정보의 안전한 처리를 위해 저장 및 전송 모두에서 암호화를 요구합니다.

하나만 제공하는 것은 보안 실패이기 전에 컴플라이언스 실패입니다.

둘 다 활성화되었는지 확인하는 방법

파일 전송 서비스에 대한 다섯 가지 빠른 점검:

testssl.sh https://provider.com으로 강력한 암호만 사용하는 TLS 1.3을 확인합니다.
max-age가 최소 31,536,000(1년)인 HSTS 헤더를 확인합니다.
저장 시 AES-256-GCM 또는 AES-256-XTS를 명시적으로 언급하는 보안 백서를 읽습니다.
키가 애플리케이션 데이터베이스가 아닌 KMS 또는 HSM에 있음을 확인합니다.
SOC 2 Type II 또는 ISO 27001 인증 확인 — 둘 다 저장 시 및 전송 중 통제를 문서화하도록 요구합니다.

보너스: 클라이언트 측 암호화가 옵션으로 제공되는지 확인하십시오. 있다면 민감한 파일에 활성화하십시오.

hexatransfer.com에서 사용해 보세요 — 무료, 계정 불필요, 최대 10GB.