2026-07-28

클라우드 스토리지의 "암호화"와 파일 직접 암호화, 세금 서류·급여명세서를 진짜로 지켜주는 건 어느 쪽일까?

스캔한 세금 신고서를 회계사에게 보내거나, 대출 심사를 돕는 부모님께 급여명세서를 보낼 때 대부분은 이미 열려 있는 클라우드 드라이브에서 공유 링크를 만들어 보냅니다. 10초면 끝나고, 앱의 설정 화면 어딘가에는 보통 파일이 "암호화되어 있다"는 문구가 있습니다. 그 단어가 실제로 감당하는 몫보다 더 많은 신뢰를 받고 있습니다. 클라우드 스토리지 자체의 암호화와, 파일이 클라우드에 닿기도 전에 직접 암호화하는 것은 서로 완전히 다른 종류의 실패를 막아줍니다 — 그리고 바로 그 차이가, 실제로 있었던 2023년의 한 클라우드 노출 사고를 별일 아닌 해프닝이 아니라 3년짜리 유출로 만든 지점입니다.

"암호화"는 세 가지 다른 것을 가리키고, 클라우드 스토리지는 보통 앞의 두 가지만 의미한다

스토리지 제공자의 설정 화면에 파일이 암호화되어 있다고 적혀 있을 때, 그건 거의 항상 두 가지 특정한 보호만을 가리킵니다. 첫 번째는 전송 중 암호화입니다. Google Cloud의 공식 문서는 이것을 기기와 제공자의 서버 사이 네트워크 구간을 TLS로 보호하는 것이라고 설명합니다 — 양쪽 끝에서 무슨 일이 일어나는지는 전혀 다루지 않습니다. 양쪽 끝에서는 정의상 평문입니다. 기기가 보낸 것도 평문이고, 서버가 저장하거나 처리하려면 평문이 필요하기 때문입니다. 두 번째는 저장 시 암호화로, 제공자의 디스크에 놓인 사본을 보호합니다. 여기서 Google Cloud의 공식 문서는 기본값에서 누가 키를 쥐고 있는지 직접적으로 밝힙니다: "기본 저장 시 암호화에 사용되는 키는 저희가 소유하고 관리합니다(We own and manage the keys used in default encryption at rest)." 이건 특정 업체를 겨냥한 비판이 아닙니다 — 업계 전반의 주류 클라우드 스토리지가 구조적으로 이렇게 동작합니다. 그리고 이 말은 문자 그대로의 의미입니다: 제공자는 자신의 시스템이 필요할 때면 언제든 파일을 복호화할 수 있습니다. 키를 쥔 쪽이 바로 제공자이기 때문입니다. 세 번째 종류인 클라이언트 측 암호화는 구조적으로 다릅니다 — 파일이 기기를 떠나기도 전에 이미 읽을 수 없는 암호문이 되고, 그 키는 제공자가 애초에 가져본 적이 없습니다. 대부분의 클라우드 스토리지 서비스가 이것을 기본값으로 쓰지 않는 이유는, 미리보기·검색·브라우저 내 편집 같은 기능이 제공자의 서버가 파일 내용을 읽을 수 있어야 동작하기 때문입니다.

"저장 시 암호화"가 막아주지 못하는 것

실제 사례 하나가 이 틈이 정확히 어디서 벌어지는지 보여줍니다. 2020년 7월, Microsoft의 한 AI 연구팀이 오픈소스 AI 모델 폴더 하나를 공유하려고 Azure SAS(Shared Access Signature) 토큰을 공개 GitHub 저장소에 올렸습니다. 이 토큰은 두 겹으로 잘못 설정되어 있었습니다: 그 폴더 하나에 대한 읽기 전용 권한이어야 했는데 스토리지 계정 전체에 대한 "완전 제어(full control)" 권한이 부여되어 있었고, 만료 시점은 2051년으로 설정되어 있었습니다 — 사실상 영구적이었던 셈입니다. Wiz Research가 이 노출된 토큰을 발견해 신고한 것은 2023년 6월 22일이었고, Microsoft는 이틀 뒤 토큰을 폐기했으며, 공개 disclosure는 2023년 9월 18일에 이루어졌습니다 — 토큰이 처음 살아 있게 된 지 약 3년 만이었습니다. 그동안 그 링크 뒤에 있었던 것은 직원 두 명의 워크스테이션 전체 디스크 백업과 3만 건이 넘는 Microsoft Teams 내부 메시지였습니다. 그 스토리지 계정 자체의 저장 시 암호화는 Azure의 기본값대로 거의 확실히 켜져 있었을 것입니다 — 그리고 그건 아무 차이도 만들지 못했습니다. SAS 토큰 자체가 이미 복호화된 접근 권한을 열어주는 자격증명이었기 때문입니다. 범위를 정확히 짚어둘 필요가 있습니다: 이건 개인용 Dropbox나 Google Drive 공유가 아니라 기업용 Azure Blob Storage 계정에서 벌어진 사고입니다. 하지만 이 사고가 드러낸 메커니즘 자체는, 주류 개인용 클라우드 드라이브라면 어디에나 있는 공유 메뉴의 "이 링크를 가진 사람은 누구나 볼 수 있음" 옵션 뒤에 있는 것과 같습니다 — 일단 만들어진 링크는, 전달되거나, 오래된 이메일 스레드에 남아 있거나, 검색 크롤러에 수집되는 순간, 정당한 열람자가 받는 것과 똑같이 이미 복호화된 접근 권한을 그대로 넘겨줍니다. "저장 시 암호화되어 있다"는 그 스토리지 계정에 대해 그 3년 내내 사실이었지만, 실제로 벌어진 일과는 무관했습니다.

파일 자체가 어디로도 가기 전에 이미 암호문이라면 달라지는 것

클라이언트 측 암호화는 클라우드 제공자를 더 믿을 만하게 만들거나 공유 링크를 잘못 설정하기 어렵게 만들지 않습니다 — 대신 그 파일 하나에 한해서는 그 두 가지 질문 자체가 더 이상 중요하지 않게 만듭니다. 암호문이 있어서는 안 될 곳에 놓이더라도 — 과도하게 공유된 링크, 잘못 설정된 버킷, 저장 계층까지 닿은 제공자 측 침해든 — 새어 나가는 건 여전히 암호문이고, 애초에 어디에도 업로드된 적 없는 패스프레이즈 없이는 읽을 수 없습니다. 이건 "제공자가 암호화되어 있다고 말한다"보다 의미 있게 다른 보장입니다. 업로드 이후 이어지는 모든 접근 제어가, 다른 누군가에 의해, 계속해서, 빠짐없이 올바르게 설정되어 있어야 한다는 전제에 의존하지 않기 때문입니다. 위의 SAS 토큰은 누군가 잘못 설정을 알아채기까지 약 3년 동안 살아 있었습니다 — 이건 드문 종류의 실수가 아니라, 접근 제어가 결국 겪게 되는 흔한 실패 방식입니다.

세금 서류나 급여명세서를 실제로 보내는 방법

이 모든 이야기를 실무로 옮기면 철학이 아니라 짧은 체크리스트가 됩니다. 첫째, 클라우드 드라이브든 이메일 첨부든 공유 링크든 근처에도 가기 전에 내 기기에서 파일 자체를 먼저 암호화하십시오 — 제공자가 붙여둔 "암호화됨" 문구가 그 일을 대신해줄 거라고 기대하지 마십시오. 둘째, 파일 자체가 암호문이 되고 나면, 그걸 보내는 통로가 더 이상 데이터의 안전 여부를 결정하지 않습니다 — 이메일 첨부든, 클라우드 링크든, USB든, 어느 쪽이 새어 나가든 상관없어집니다. 셋째, 패스프레이즈는 파일과 같은 경로로 보내지 마십시오 — 전화 통화, 다른 앱으로 보내는 문자, 직접 만나서 전달 — 받은편지함 하나가 뚫리거나 과도한 공유 실수 하나가 자물쇠와 열쇠를 동시에 넘겨주지 않도록 하는 것입니다. 넷째, 다 끝났다고 가정하기 전에 상대방이 실제로 열 수 있는지 확인하십시오 — 패스프레이즈로 보호된 파일을 처음 받아보는 회계사라면 어떻게 열어야 하는지 한 줄 설명이 필요할 수 있습니다.

NearSeal이 여기서 하는 일

NearSeal은 정확히 이 체크리스트의 첫 번째 단계를 위해 만들어졌으며, 그 경계를 정확히 밝혀둘 가치가 있습니다. NearSeal은 전적으로 브라우저 안에서 동작합니다 — 파일도 패스프레이즈도 기기를 벗어나지 않고, 둘 중 어느 쪽도 업로드 단계가 없습니다. 기본적으로는 패스프레이즈로부터 PBKDF2-SHA256을 2²⁰회 반복해 AES-256-GCM 키를 유도합니다(NSEAL1 형식). 이 사이트뿐 아니라 공식 age나 rage CLI에서도 열리길 원한다면, 대신 옵트인 방식으로 age-encryption.org 형식(키 유도에는 scrypt, 암호화에는 ChaCha20-Poly1305)을 선택할 수 있습니다. 어느 쪽이든, 그 이후 내 기기를 떠나는 것 — 어떤 이메일로, 어떤 클라우드 링크로, 어떤 방식으로 보내든 — 은 이미 암호문입니다. NearSeal이 할 수 없는 일은 지나치게 넓게 설정된 공유 링크나 잘못된 수신자로 향하는 받은편지함을 고쳐주는 것입니다 — 어떤 클라이언트 측 도구도 다른 사람의 계정 설정이나 내가 직접 입력하는 주소창까지는 손이 닿지 않습니다. NearSeal이 할 수 있는 일은, 결국 파일을 실어 나르는 통로가 무엇이 되었든, 그 안에 든 내용이 그 통로가 다른 모든 걸 제대로 해냈는지에 더 이상 의존하지 않도록 만드는 것입니다.