암호화 이메일 대 암호화 파일 전송 비교

암호화 이메일(PGP, S/MIME, 또는 ProtonMail 같은 서비스)은 대부분의 수신 서버가 여전히 적용하는 Gmail 첨부 한도인 약 25MB 이하의 짧은 민감한 메시지와 문서에 잘 작동합니다. 암호화 파일 전송(HexaTransfer, SwissTransfer, Tresorit Send)은 10GB 이상의 페이로드를 처리하고, 일회용 다운로드 링크를 생성하며, 파일을 수신함의 보존 정책으로부터 분리합니다. 대화 스레드와 소용량 첨부가 필요할 때는 이메일을 선택합니다. 대용량이거나, 시간에 민감하거나, 메일 아카이브에 무기한 남아있어서는 안 되는 파일에는 파일 전송을 선택합니다. 종종 둘 다 필요할 것입니다.

이메일의 용량 장벽

SMTP는 1982년 7비트 ASCII 전보용으로 설계되었습니다. 첨부 파일은 MIME base64 인코딩을 통해 추가되며, 이진 데이터가 약 33% 늘어납니다. 20MB 동영상이 27MB 이메일이 됩니다. Gmail은 25MB를 초과하는 메시지를 거부하고, Outlook.com은 20MB로 제한하며, 대부분의 기업 Exchange 서버는 10~35MB 사이에서 제한을 설정합니다.

한도에 부딪히면 선택지가 불편해집니다. 7-Zip 볼륨으로 .zip을 분할하거나, 클라우드 서비스에 업로드하고 링크를 붙여 넣거나(암호화를 무력화), 도구를 바꾸는 것입니다. 파일 전송 서비스는 이를 완전히 건너뜁니다. HexaTransfer는 10GB .psd를 직접 전송하고, WeTransfer는 무료 티어에서 2GB를 처리하며, Signiant 같은 전용 엔터프라이즈 도구는 테라바이트를 전송할 수 있습니다.

실제로 다른 암호화 방식

PGP(RFC 4880)는 랜덤 AES-256 세션 키로 메시지 본문을 암호화한 다음, 그 키를 수신자의 RSA-4096 또는 Curve25519 공개 키로 래핑합니다. S/MIME(RFC 8551)은 CA가 발급한 X.509 인증서를 사용하여 동일한 작업을 수행합니다. 둘 다 종단간입니다. 메일 제공업체는 암호문을 저장합니다.

암호화 파일 전송은 일반적으로 다른 모델을 사용합니다. 파일은 클라이언트 측에서 AES-256-GCM으로 암호화되고, 서버는 암호문만 저장하며, 복호화 키는 URL 프래그먼트(#key=...)에 담겨 서버에 도달하지 않습니다. PKI도 없고, 신뢰 웹도 없으며, 키 서버도 없습니다. 절충점은 이메일 암호화가 발신자를 암호학적으로 인증하는 반면, 파일 링크는 URL을 보유한 사람만 인증한다는 점입니다.

한눈에 비교

| 기능 | 암호화 이메일(PGP/S-MIME) | 암호화 파일 전송 | |---|---|---| | 일반 크기 한도 | 25MB | 2GB~10GB+ | | 발신자 인증 | 강력(서명됨) | 약함(링크 기반) | | 수신자 키 설정 | 사전에 필요 | 불필요 | | 보존 기간 | 수신함에 영구 | 일반적으로 7일 | | 노출되는 메타데이터 | 제목, 헤더 | 파일명 선택사항 | | 비기술 수신자와 호환 | 드묾 | 항상 | | 규제 적합성 | HIPAA 이메일(BAA 포함) | GDPR 제32조, HIPAA |

보존 기간: 메일 아카이브 대 만료되는 링크

암호화된 이메일은 수신함에 수년간 저장됩니다. 수신자의 기기가 나중에 침해되거나 PGP 개인 키가 유출되면, 모든 이전 메시지가 복호화됩니다. 장기 보존은 감사 추적에는 좋지만 침해 범위에는 나쁩니다.

파일 전송 링크는 일반적으로 만료됩니다. HexaTransfer는 7일 후 전송을 삭제합니다. SwissTransfer는 30일로 제한합니다. 타이머가 만료되면 암호문이 삭제되고 복호화 키는 쓸모없게 됩니다. URL이 수년 후에 유출되더라도 잠금 해제할 것이 없습니다. 이는 GDPR 제5조 제1항 제e호와 개인정보보호법의 데이터 최소화 원칙에 잘 부합하며, 법률 및 의료 워크플로우가 일회성 공개에 전송 서비스를 점점 더 선호하는 이유입니다.

수신자의 불편함

PGP의 사용성 문제는 널리 알려져 있습니다. 2015년 카네기 멜런 연구에서 10명 중 10명이 첫 시도에서 암호화된 이메일 전송에 실패했습니다. PGP 출시 20년이 지난 후에도 수신자는 여전히 키 쌍을 생성하고, 어딘가에 게시하며, 지문을 확인하고, Thunderbird 또는 GPG Suite를 구성해야 합니다. S/MIME은 Active Directory를 통해 인증서를 자동 배포하는 기업 환경에서는 약간 더 낫습니다.

파일 전송은 이를 단순화합니다. 링크를 클릭하고, 선택적으로 비밀번호를 입력하면 됩니다. 수신자는 사전 설정이 전혀 필요 없습니다. 이것이 클라이언트 대면 시나리오에서 암호화 파일 전송 도구가 선호되는 이유입니다. 고객에게 1099를 보내는 회계사, 전문의에게 DICOM 검사를 전송하는 방사선 전문의, 소송 발견 .pdf 묶음을 전달하는 변호사 등에서 활용됩니다.

겹치는 영역: 민감한 소용량 문서

서명된 계약서, 스캔된 여권, 2MB 의료 검사 결과는 모호한 영역에 있습니다. 두 방법 모두 작동합니다. 대화 스레드와 연결된 지속적인 기록이 필요하다면 이메일이 낫습니다. 배달 후 문서가 사라져야 하거나, 수신자가 PGP 그룹 외부에 있거나, 파일이 실제로 검색되었다는 다운로드 영수증이 필요하다면 파일 전송이 낫습니다.

일부 팀은 분할 워크플로우를 실행합니다. ProtonMail이나 Tutanota는 25MB 이하의 스레드 기반 교환에, 전용 전송 서비스는 더 크거나 만료되어야 하는 모든 것에 사용합니다. 둘 다 제공업체에는 암호문만 남으므로 HIPAA 45 CFR 164.312(e)(1)와 PCI DSS 4.0 요구사항 4.2.1의 전송 중 데이터 요구사항을 충족합니다.

준수 및 보존 기준

규정은 특정 도구를 거의 지정하지 않습니다. 결과를 지정할 뿐입니다. GDPR 제32조는 개인 데이터에 대한 "적절한 기술적 조치"를 요구합니다. HIPAA 보안 규칙은 정지 시와 이동 시 ePHI 암호화를 요구합니다. PCI DSS 4.0은 메시징 채널에서 암호화되지 않은 PAN을 차단합니다. 이메일이든 파일 전송이든 모든 E2EE 솔루션은 올바르게 구성되고 서명된 Business Associate Agreement(HIPAA) 또는 Data Processing Addendum(GDPR, 개인정보보호법 포함)이 뒷받침되면 이를 충족할 수 있습니다.

실질적 차이는 보존 자세에 있습니다. 메일 시스템은 기본적으로 무기한 저장하고, 파일 전송 시스템은 기본적으로 삭제합니다. GDPR 제17조 및 개인정보보호법 제36조의 삭제 요청에 있어 파일 전송 모델이 훨씬 쉽습니다. 요청이 도착할 때쯤 데이터는 이미 사라져 있습니다.

적합한 도구 선택

지속적인 대화, 소용량 첨부 파일, 서명된 감사 추적이 중요한 법적 의미가 있는 커뮤니케이션에는 암호화 이메일을 사용합니다. 일회성 대용량 전송, 비기술 수신자에게 보내는 민감한 문서, 자체 파괴가 필요한 파일, 25MB 첨부 한도에 걸리는 모든 것에는 암호화 파일 전송을 사용합니다. 둘은 경쟁 관계가 아니라 보완 관계입니다.

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