암호화하지 않은 파일을 클라우드 드라이브에 올리면, 사업자·동기화 클라이언트·콘텐츠 해시가 아직 볼 수 있는 것

클라우드에 끌어다 놓는 것은 금고가 아니라, 다음 시스템에 평문을 넘기는 일입니다

소비형 클라우드 드라이브를 집 안의 금고처럼 여기는 일이 많습니다. 내 계정 안에 있으니 남이 못 연다는 식입니다. 끌어다 놓은 뒤, 그 바이트는 지금 디스크의 그 폴더를 떠납니다. 사업자가 저장하고, 동기화하고, 중복을 줄이고, 자주 미리보기까지 만드는 객체가 됩니다. 세금 신고서, 주민등록증 스캔, SSH 개인키, 데이터베이스 덤프, 마스킹하지 않은 고객 표는 제삼자 저장·검색 시스템에 평문으로 들어가면 안 되는 내용입니다.

HTTPS가 막는 것은 전송 구간의 도청입니다. 상대 시스템이 파일을 어떤 형태로 두는지, 키를 누가 쥐는지, 동기화 앱이 이 기기에 무엇을 캐시하는지, 공유 링크를 열면 암호문이 오는지 풀린 원문이 오는지는 정하지 않습니다. 앞 글에서 이미 썼습니다. 키를 모델 대화에 붙이면 기록과 보관으로 갑니다. 암호화하지 않은 파일을 드라이브에 넣는 것은 같은 종류의 노출입니다. 받는 쪽만 「모델 사업자」에서 「저장 사업자와 그 동기화·미리보기·중복 제거 경로」로 바뀝니다. 올리기 전에 물을 것은 「이 드라이브가 똑똑한가」가 아닙니다. 「이 복사본에, 이 기기를 평문으로 떠나면 안 되는 내용이 있는가」입니다.

이 글은 AWS S3, Google Drive / Google Cloud, iCloud의 공개 설명을 기준으로 합니다. 층이 문장으로 적혀 있어 대조하기 쉽기 때문입니다. 네이버 MYBOX나 카카오 드라이브 같은 소비형 제품은 「키를 누가 쥐는가」를 같은 문장으로 잘 쓰지 않습니다. 그래도 공학 모델은 대체로 같습니다. 전송은 TLS, 디스크에는 사업자가 키를 보관하는 저장 시 암호화, 그 위에 썸네일, 전문 검색, 해시 대조 즉시 업로드. 제품을 바꾸면 그 회사 보안 페이지를 다시 걷습니다. 아래의 SSE-S3나 「표준 데이터 보호」를 다른 브랜드에 그대로 붙이지 마세요.

HTTPS, 저장 시 암호화, 제로지식: 세 자물쇠는 같은 자물쇠가 아닙니다

「클라우드가 암호화되어 있나」를 예/아니오로 들으면 적어도 세 층이 빠집니다. 첫 번째는 전송 암호화입니다. 브라우저나 동기화 앱이 TLS로 바이트를 보냅니다. 중간 네트워크는 평문을 보지 못합니다. 이 층은 거의 기본이고, 주소창 자물쇠가 실제로 약속하는 범위이기도 합니다.

두 번째는 저장 시 암호화, 곧 서버 측 암호화입니다. AWS의 S3 서버 측 암호화 정의는 단정합니다. 데이터는 목적지에서, 받은 서비스가 암호화합니다. 데이터센터 디스크에 쓸 때 암호화하고, 여러분이 접근하면 다시 풉니다. 2023년 1월 5일부터 새로 올리는 객체는 기본이 SSE-S3(Amazon S3가 관리하는 키)입니다. 알고리즘은 AES-256이고, 객체마다 키가 다르며, 루트 키는 AWS가 순환합니다. 인증되고 권한이 있는 요청이라면 「암호화된 객체와 암호화되지 않은 객체를 접근하는 방식에 차이가 없습니다」. 미리 서명된 URL도 둘 다 같습니다. 객체 목록도 암호화 여부를 가리지 않습니다. 한 줄로 말하면, 이 층이 막는 것은 디스크가 도난당한 뒤의 물리 매체이지 「AWS가 여러분의 파일을 못 연다」가 아닙니다.

Google의 Drive 공개 표현도 비슷합니다. 업로드하거나 Docs / Sheets / Slides에서 만든 파일은 「전송 중과 저장 시에 AES-256으로 암호화」됩니다. 추가 기밀은 Workspace 클라이언트 측 암호화에 있고, 직장 또는 학교 계정에 관리자가 켜야 합니다. 켠 뒤에야 Google은 「여러분의 파일을 복호화할 수 없다」고 씁니다. 기본 층에는 그 문장이 없습니다. Google Cloud 기본 저장 시 암호화는 더 직접적입니다. 기본 암호화에 쓰는 키는 Google이 소유하고 관리합니다. 기본만 쓰면 그 키에 닿지 못하고, 순환도 통제하지 못합니다.

Apple은 기본과 선택을 나눠 씁니다. iCloud 데이터 보안 개요(2026년 1월 5일)는 표준 데이터 보호가 계정 기본이라고 적습니다. 데이터는 암호화되고, 키는 Apple 데이터센터에 있어 Apple이 복구를 도울 수 있습니다. 기본으로 종단간 암호화되는 범주는 일부뿐입니다. 수는 구체적입니다. 건강, iCloud 키체인 등을 포함해 항상 종단간인 범주가 15개입니다. 선택인 고급 데이터 보호를 켜면 25개로 늘고, iCloud 백업, 사진, 메모, iCloud Drive가 들어갑니다. 고급 데이터 보호를 끄면 기기는 필요한 키를 Apple 서버에 다시 올립니다. 기본은 「Apple도 iCloud Drive의 파일을 못 연다」가 아닙니다.

사업자가 키를 쥐고 있으면, 무엇을 할 수 있고 누구에게 보이나

사업자가 복호화할 수 있다는 말은 협박이 아닙니다. 기본 제품 기능이 성립하는 전제입니다. PDF 온라인 미리보기, 사진 썸네일, 문서 OCR이나 전문 검색, 파일 종류별 분류는 어떤 서버에서 내용을 보거나, 적어도 내용에서 나온 평문 색인을 봐야 합니다. Google은 클라이언트 측 암호화의 대가를 도움말에 스스로 적습니다. 암호화된 Docs / Sheets / Slides는 모바일 앱에서 편집할 수 없고, Drive 파일에 댓글을 달 수 없으며, 음성 입력과 몇몇 부가 기능이 없습니다. 암호화 문서 상한은 100 MB, 버전 기록은 최대 100개입니다. 제한이 생기는 이유는 구체적입니다. 서버가 원문을 풀 키를 더 이상 갖지 못하기 때문입니다.

AWS는 다른 면을 같은 정도로 분명히 씁니다. 미리 서명된 URL로 객체를 공유하면, 상대가 받는 접근 방식은 암호화되지 않은 객체와 같습니다. SSE-S3는 「링크를 연 사람」을 평문 밖으로 내보내지 않습니다. 막는 것은 「하드디스크를 가져간 사람」입니다. 계정 탈취, 공유 링크 유출, 회사 관리자 열람, 수사 기관 요청은 모두 「권한이 있는 접근」입니다. 저장 시 암호화는 기본으로 그 길을 막지 않습니다.

소비형 드라이브에는 층이 하나 더 있습니다. 동기화 클라이언트입니다. 파일은 먼저 이 기기의 동기화 폴더에 나타난 뒤 올라갑니다. 클라우드가 나중에 저장 시 암호화를 쓰더라도, 이 컴퓨터, 집에 로그인해 둔 다른 컴퓨터, 휴대폰의 오프라인 캐시에는 평문이 남을 수 있습니다. 브라우저 탭을 닫아도, 이미 동기화 폴더에 쓰인 사본은 지워지지 않습니다.

동기화, 미리보기, 즉시 업로드, 공유 링크는 또 다른 사본입니다

「업로드 성공」을 「클라우드에 한 부만 있다」로 들으면, 이 기기와 클라우드 양쪽의 사본이 빠집니다. 첫 번째는 동기화 앱의 작업 사본입니다. 대기열, 실패 재시도 캐시, 버전 충돌이 남긴 복사본. 두 번째는 서버가 미리보기를 위해 만든 파생 파일입니다. 썸네일, 다시 인코딩한 동영상, OCR 텍스트. 원본과 따로 두는 일이 많고, 원본을 지워도 파생 파일이 바로 따라 없어지지 않을 수 있습니다.

세 번째는 콘텐츠 해시입니다. 여러 드라이브가 파일 전체 또는 조각 해시로 즉시 업로드와 중복 제거를 합니다. 이 기기에서 먼저 해시를 계산하고, 서버에 같은 해시가 있으면 바이트를 다시 보내지 않습니다. 암호화하지 않은 파일에는 편합니다. 동시에 「같은 평문은 시스템에 한 부만 둔다」를 공개로 인정하는 것이기도 합니다. 흔한 설치 파일이나 공개 PDF를 암호화하지 않고 올리면, 서버는 해시만으로 여러분이 그걸 갖고 있음을 확인할 수 있습니다. 회사 안 같은 계약서를 여러 사람이 올리면, 중복을 줄인 뒤에도 같은 평문입니다. 이 기기에서 먼저 암호화하면, 매번 다른 salt와 IV 때문에 암호문이 달라지고 해시가 맞지 않아 즉시 업로드는 실패합니다. 고장이 아닙니다. 「사업자가 내용을 못 본다」의 직접적인 결과입니다.

네 번째는 공유 링크와 팀 공간입니다. 링크를 보낸 뒤의 권한 모델은 대개 「링크를 가진 사람이 파일을 가져갈 수 있다」입니다. 위 절과 맞물리면, 기본 저장 시 암호화는 내려받을 때 「암호문만 준다」로 바뀌지 않습니다. 상대 브라우저에 열리는 것은 풀린 원문입니다. 카카오톡 방에 넣은 「드라이브 링크」와 파일 본체를 붙이는 일은 노출면이 다릅니다. 평문이 여러분의 계정을 떠났는가에 대한 답은 자주 같습니다.

압축 파일에 암호를 거는 것만으로는 부족한 이유

「ZIP에 암호를 걸고 올린다」는 말은 이미 클라이언트 측 암호화를 한 것처럼 들립니다. 먼저 어떤 ZIP 암호화를 썼는지 묻습니다. 전통적인 PKWARE 암호화(ZipCrypto)는 스트림 암호입니다. 1994년 Eli Biham과 Paul Kocher는 A Known Plaintext Attack on the PKZIP Stream Cipher에서 이 암호가 약하며 가치 있는 데이터를 지키는 데 쓰면 안 된다고 썼습니다. 압축된 알려진 평문 약 13–40바이트, 또는 압축하지 않은 파일 앞부분 약 30–200바이트면, 당시 개인용 컴퓨터에서 몇 시간 안에 내부 키 표현을 되돌릴 수 있었습니다. 지금의 구현은 문턱을 더 낮춥니다. bkcrack은 알려진 평문 최소 12바이트(그중 연속 8바이트)면 내부 상태를 복구하고, 나머지 묶음과 같은 암호로 잠근 다른 항목까지 연다고 적습니다. 이 공격에서 암호 길이는 도움이 되지 않습니다. 목표가 키스트림 상태이지, 여러분의 암호를 추측하는 것이 아니기 때문입니다.

압축 도구가 AES로 바뀌어도, ZIP은 파일 이름, 디렉터리 구조, 암호화하지 않은 항목 설명을 헤더에 남길 수 있습니다. 드라이브의 파일 목록, 검색, 「종류」 필터가 읽는 것이 그 메타데이터입니다. 「압축 파일에 암호가 있다」를 「클라우드는 깨진 글자만 본다」로 바꾸면, 헤더와 약한 알고리즘 두 층이 빠집니다.

더 흔한 운영 실수는 이렇습니다. 암호화한 묶음과 암호를 적은 readme.txt를 같은 폴더에 넣고 함께 동기화합니다. 자물쇠와 열쇠를 같은 보관자에게 맡기면, 저장 시 암호화와 ZIP 암호 모두 구하지 못합니다.

이 기기에서 먼저 암호화하면 바뀌는 층

클라이언트 측 암호화의 조건은 좁습니다. 평문이 기기를 떠나기 전에 암호문이 됩니다. 키를 만드는 암호를 저장 사업자에게 보내지 않습니다. 사업자는 정상 운영에서 풀지 못합니다. Google은 Workspace 클라이언트 측 암호화를 「종단간, 클라이언트 사이」로 쓰고, 「Google은 복호화할 수 없다」고 이름을 붙입니다. 관리자가 켜는 추가 층이지, 개인 무료 Drive의 기본값이 아닙니다. 직접 암호화한 뒤 올리는 일은 같은 경계를 걷습니다. 키는 여러분의 암호와 기기에만 남고, 어느 드라이브에 클라이언트 측 암호화 스위치가 있는지를 기다리지 않습니다.

브라우저에서 대조할 수 있는 방법은 Web Crypto의 AES-GCM이지, 직접 짠 XOR이 아닙니다. MDN의 AesGcmParams 설명은 NIST SP 800-38D와 같습니다. 같은 키에서는 IV가 매번 달라야 하고, 규격은 96비트(12바이트) IV를 권합니다. IV는 비밀일 필요가 없고, 암호문 옆에 평문으로 둘 수 있습니다. NIST는 유일성을 무겁게 씁니다. 같은 키에서 IV를 재사용하면 위조 공격이 가능해지고, 그 중요성은 키를 비밀로 지키는 일과 거의 같습니다. 인증 태그의 기본은 128비트(16바이트)입니다. 암호가 틀리거나 암호문이 바뀌면 복호화는 바로 실패해야 하고, 깨진 평문을 뱉으면 안 됩니다.

MakePwd 파일 암호화는 이 경계를 따릅니다. 현재 탭에서 AES-256-GCM으로 조각 암호화하고, 암호는 PBKDF2-HMAC-SHA256, 10만 회 반복으로 키를 만듭니다. 파일마다 16바이트 salt, 조각마다 12바이트 IV, 출력은 IV + 암호문 + 16바이트 태그입니다. 단일 파일은 최대 5 GB, 기본 조각은 1 MB라서 파일 전체를 한 번에 메모리에 읽지 않습니다. 출력은 .lock 또는 .enc이고, 바이너리 형식은 같습니다. 파일과 암호는 기본으로 올리지 않습니다. 모든 도구는 열자마자 쓰며, 계정이 없고, 암호를 대신 맡아 두는 비밀번호 보관함도 없습니다. 이 페이지가 답하는 것은 「브라우저를 떠나기 전에 암호문이 될 수 있는가」이지, 「어느 드라이브로 대신 올려 주는가」가 아닙니다.

바로 확인하기: 카나리아 평문이 업로드 대기열에 없고, Network에는 암호문만

「올리지 않는다」는 문구는 스스로 증명하지 못합니다. 확인을 둘로 나눕니다. 먼저 암호화 과정 자체가 평문을 업무 데이터로 보내지 않았는지 보고, 그다음 드라이브에 넘긴 객체가 암호문인지 봅니다.

1. 텍스트를 만들고, 실제 업무에 나오지 않을 한 줄을 씁니다. 예: canary-cloud-20260902-only-once. 파일 이름에도 카나리아를 넣을 수 있습니다. 암호는 일회용 긴 문장을 쓰고, 평소 비밀번호는 쓰지 마세요.
2. 브라우저에서 파일 암호화 페이지를 엽니다. 개발자 도구를 열고 Network로 간 뒤 Preserve log를 켭니다. 그 파일을 고르고 암호를 넣은 뒤 .lock을 받습니다. 필터에 카나리아를 붙입니다. 요청 줄, 요청 본문, 분석 전송에 원문이 있으면 안 됩니다. 암호도 보이면 안 됩니다.
3. 받은 .lock을 16진 뷰어나 편집기로 엽니다. 머리에는 고정 매직이 보여야 하고, 방금 그 카나리아 문장은 보이면 안 됩니다. 틀린 암호로 복호화하면 실패해야 하고, 깨진 평문 파일을 만들면 안 됩니다.
4. 암호문을 자신의 드라이브에 백업하려면 올리는 것은 .lock이지 원본이 아닙니다. 올린 뒤 드라이브 미리보기에서 검색합니다. 읽을 수 있는 본문이 나오면 안 됩니다. 암호를 같은 동기화 폴더에 두지 마세요.

앞의 세 단계—요청 줄, 요청 본문, 분석 전송—는 브라우저에서 암호화할 때, 평문이 나가지 않았는지 직접 확인하는 법과 같습니다. 이 글이 더하는 것은 네 번째입니다. 객체가 브라우저를 떠난 뒤, 층은 「이 기기의 Web Crypto」에서 「드라이브가 평문으로 다루나」로 바뀝니다. 카나리아는 여러분이 보관한 원본에만 있어야 합니다. 드라이브 미리보기나 즉시 업로드 적중 안내에 나타나면, 올린 것은 아직 암호화하지 않은 사본입니다.

열자마자 쓰는 파일 암호화에서 경계를 익히기

「먼저 암호문이 되고, 어디에 올릴지는 내가 정한다」가 목표면 가입할 필요가 없고, 파일을 MakePwd에 맡길 필요도 없습니다. 파일 암호화를 열고, 버려도 되는 작은 파일을 고르고, 무작위 긴 암호로 암호화한 뒤 .lock을 받아 위 절처럼 Network를 검색하세요. 사람이 암호를 기억하거나 동료에게 줘야 하면 비밀번호 생성기에서 6–128자 무작위 문자열을 뽑습니다. 기본은 16자이고, 8자 미만은 약하다고 표시됩니다. 그다음 일회용 링크로 한 번 보내는 편이 낫고, 암호문과 같은 드라이브 폴더로 보내지 마세요. 일회용 링크의 키는 URL # 프래그먼트에 있고, 읽기 페이지는 수신자에게 공개입니다.

파일 암호화는 드라이브의 클라이언트 측 암호화 스위치를 대신하지 않습니다. 암호문을 올린 뒤 상대 제품이 악성코드 검사나 파일 이름 심사를 어떻게 할지도 약속하지 않습니다. .lock 머리에는 원래 파일 이름이 들어 있어, 드라이브 쪽은 이름을 볼 수 있습니다. 이름 자체가 보이면 안 되면, 암호화하기 전에 의미 없는 이름으로 바꿉니다. 암호를 잊으면 암호문에서 되돌릴 수 없습니다. 여러분이 통제하는 곳에 따로 적어두세요.

자주 묻는 질문

클라우드가 「암호화됨」이라고 쓰면, 사업자가 내 파일을 열 수 있습니까?

기본 저장 시 암호화에서는 보통 열 수 있습니다. AWS는 서버 측 암호화가 디스크에 쓸 때 암호화하고 접근할 때 다시 푼다고 적습니다. 권한이 있는 요청은 암호화된 객체와 암호화되지 않은 객체를 같게 다룹니다. Google은 기본 암호화의 키를 스스로 보관합니다. Apple 표준 데이터 보호는 복구를 돕기 위해 대부분의 키를 자사 데이터센터에 둡니다. 「사업자가 풀 수 없다」와는 다른 층입니다.

암호 걸린 ZIP을 만든 뒤 올리면 충분합니까?

전통적인 ZipCrypto는 부족합니다. 1994년 Biham과 Kocher는 알려진 평문 십여 바이트면 내부 키 상태를 복구할 수 있다고 보였고, 암호 길이는 이 공격에 도움이 되지 않습니다. AES 압축 파일이라도 파일 이름 같은 메타데이터는 평문으로 남을 수 있습니다. 클라우드 쪽이 암호문만 보게 하려면, 이 기기에서 인증 암호화를 끝낸 뒤 올리세요.

먼저 암호화하면 즉시 업로드와 온라인 미리보기가 됩니까?

원문 기준으로는 보통 되지 않습니다. 즉시 업로드는 콘텐츠 해시를 비교합니다. 같은 평문이라도 salt와 IV를 매번 새로 쓰면 해시가 바뀝니다. 미리보기, 썸네일, OCR은 원문을 풀어야 합니다. 예상된 대가입니다. 사업자가 내용을 못 보면, 미리보기도 대신 만들어 주지 못합니다.

암호를 .lock과 같은 클라우드 폴더에 둘 수 있습니까?

두지 마세요. 암호문과 암호가 같은 계정, 같은 동기화 폴더에 있으면 자물쇠와 열쇠를 같은 보관자에게 맡기는 것과 같습니다. 암호는 비밀번호 관리자에 두거나, 일회용 링크로 한 번 보내세요. 암호를 잊으면 .lock에서 평문을 되돌릴 수 없습니다. 제로지식 백업의 경계이지, 결함이 아닙니다.

다음에 올리기 전에 기억할 세 가지

첫째, 주소창 자물쇠와 「암호화됨」은 전송과 디스크 도난만 덮습니다. 사업자, 관리자, 공유 링크를 가진 사람은 덮지 않습니다. 둘째, 동기화 캐시, 미리보기 파생 파일, 콘텐츠 해시, 공유 링크가 각각 사본을 남길 수 있습니다. 암호화하지 않고 올리면 평문이 그 경로에 들어갑니다. 셋째, 클라우드 쪽이 불투명한 바이트만 보게 하려면, 이 기기에서 AES-256-GCM으로 .lock / .enc를 만들고, 암호는 다른 경로로 보낸 뒤, Network와 드라이브 미리보기에서 카나리아를 검색하세요.

「암호화 과정이 평문을 업무 데이터로 보냈는가」를 이어서 묻고 싶다면 브라우저에서 암호화할 때, 평문이 나가지 않았는지 직접 확인하는 법을 읽으세요. 암호문을 여는 암호를 사람에게 줘야 하면 URL의 # 뒤에 키를 두기 좋은 이유, 그리고 이 보호가 깨지는 순간과 일회용 링크를 한 번 읽은 뒤, 서버에 남는 것은 무엇인가를 보세요. 이 글은 「암호화하지 않은 파일이 클라우드에 들어간 뒤 아직 남을 수 있는 것」만 결론에 적을 수 있는 범위로 줄입니다.