직접 소유하지 않은 머신의 디스크 암호화

프라이버시를 내세우는 모든 제공업체는 디스크가 암호화되어 있다고 말합니다. 대개 사실이지만, 대개 아무도 묻지 않은 질문에 답하는 셈입니다. 암호화가 신경 써야 할 상태는 세 가지이며, 서버는 그중 전체 디스크 암호화가 다루지 못하는 상태에서 가동 기간 전체를 보냅니다. 이 글은 그 경계선이 실제로 어디에 있는지, 그 양쪽에 무엇이 있는지, 그리고 같은 네 단어로 팔리는 두 가지 방식 중 어느 쪽이 여러분이 키를 쥐는 방식인지를 다룹니다.

세 가지 상태, 그리고 아무도 암호화하지 않는 상태

데이터는 세 가지 상태 중 하나로 설명되며, 업계는 그중 두 가지를 확실히 해결했습니다. 저장 상태는 현재 아무것도 읽고 있지 않은 디스크에 놓인 데이터로, 전체 디스크 암호화와 그 위에 겹쳐지는 데이터베이스 또는 오브젝트 스토리지 암호화로 해결됩니다. 전송 상태는 네트워크를 오가는 데이터로, TLS로 해결되며 그 완성도는 잘못 발급된 인증서 하나가 뉴스가 될 정도입니다. 사용 상태는 실행 중인 프로세스의 메모리에 올라온 데이터입니다 — 서버가 내보내는 모든 바이트는, 아무리 짧은 순간이라도, 전달되기 위해 반드시 이 상태를 거쳐야 합니다.

저장 데이터 암호화라는 표현은 정확하며, 너무 정확한 나머지 그냥 지나치기 쉽습니다. 이 표현이 가리키는 것은 머신이 꺼져 있는 동안 데이터가 놓인 상태입니다. 그런데 서버라는 머신의 존재 이유는 바로 꺼지지 않는 것입니다. 가동되는 몇 달 동안 볼륨은 열려 있고, 데이터베이스 파일은 알맞은 사용자 권한으로 실행되는 어떤 프로세스에서든 읽을 수 있으며, 암호화는 정전을 기다리는 것 말고는 아무 일도 하지 않습니다.

그 네 단어가 숨기는 두 번째 사실은 키를 누가 쥐고 있는가입니다. 같은 이름 아래 완전히 다른 두 방식이 팔립니다. 제공업체가 자신이 관리하는 키로 스토리지 계층을 암호화할 수도 있습니다 — 이는 제공업체의 폐기 절차를 보호하고 자사의 유출 노출을 줄이며, 드라이브가 건물 밖으로 나가는 상황도 실제로 막아 줍니다. 다만 키를 쥔 쪽은 다름 아닌 여러분이 궁금해했던 바로 그 당사자입니다. 아니면 볼륨을 여러분 자신의 머신 내부에서, 여러분의 머릿속과 가동 중인 커널의 메모리 말고는 어디에도 존재하지 않는 키로 암호화할 수도 있습니다. 제3자가 무엇을 손에 넣을 수 있는지를 바꾸는 것은 오직 두 번째 방식뿐이며, 이 가이드의 나머지 부분이 뜻하는 암호화도 바로 그것입니다.

이는 디스크 암호화를 반대하는 이야기가 결코 아닙니다. 아래 여덟 가지 시나리오 중 어느 것을 막고 있고 어느 것을 막지 못하는지 알아야 한다는 이야기입니다. 실제로 한 가지를 막는 암호화는 갖출 가치가 있습니다. 여덟 가지를 막는다고 믿는 암호화는 아예 없는 것보다 나쁩니다. 그 믿음이 거기서 대화를 끝내 버리기 때문입니다.

머신이 가동되는 동안 키가 있는 곳

LUKS 볼륨을 잠금 해제할 때 입력하는 암호 문구 자체는 키가 아닙니다. 그 문구는 볼륨 헤더에 저장된 마스터 키를 풀어낼 뿐이며, 그렇게 풀린 마스터 키는 볼륨이 닫히거나 머신의 전원이 끊어질 때까지 커널 메모리에 머뭅니다. 모든 읽기와 쓰기가 그 키를 거쳐 갑니다. 디스크가 사용되는 동안 키가 다른 어딘가에 있는 암호화된 디스크의 구성은 존재하지 않습니다 — 이는 누군가 고칠 수 있는 구현상의 세부 사항이 아니라, 암호화된 디스크를 사용한다는 것 자체의 의미입니다.

직접 소유한 하드웨어라면 그 메모리는 여러분이 통제하는 방 안의 본체 안에 있으며, 이를 노리는 공격은 이례적입니다 — 물리적으로 그 자리에 있어야 하고, 전원이 끊긴 뒤 메모리 칩에 몇 초간 남는 잔류 데이터를 노려야 합니다. 가상 서버에서는 상황이 정도가 아니라 종류부터 다릅니다. 여러분의 커널 메모리는 호스트 메모리의 한 영역입니다. 하이퍼바이저는 정의상 그 영역을 주소로 지정할 수 있습니다. 애초에 하이퍼바이저가 그 영역을 여러분에게 내준 방식 자체가 주소 지정이기 때문입니다. 지극히 평범한 세 가지 작업이 그 메모리를 읽어 낼 수 있습니다.

• 라이브 마이그레이션. 가동 중인 가상 머신을 물리 호스트 사이에서 옮기는 작업은 실행된 상태 그대로 메모리를 복사해 옮깁니다. 이는 결함이 아니라 기능입니다 — 재부팅 없이 호스트를 유지 보수하는 방법이 바로 이것이며, 복사되는 페이지 안에 여러분의 마스터 키도 들어 있습니다.
• 메모리를 포함하는 스냅샷. 직접 암호화한 볼륨의 디스크만 담은 스냅샷에는 암호문 외에는 아무것도 들어 있지 않습니다. 반면 머신이 멈췄던 지점에서 정확히 그대로 재개할 수 있게 해 주는 스냅샷에는 키도 들어 있습니다. "정확히 그대로"를 이루는 요소 안에 키가 포함되기 때문입니다.
• 메모리 덤프. 여러분의 게스트 메모리는 호스트 위에서 도는 한 프로세스의 주소 공간 안에 존재합니다. 그 프로세스의 메모리를 읽는 것은 흔히 쓰이는 디버깅 작업이며, 그 도구는 몰래 들여올 필요도 없이 가상화 스택에 이미 포함되어 있습니다.

이는 제공업체가 실제로 그렇게 한다는 주장이 아닙니다. 이러한 작업들이 여러분의 협조 없이도 이루어지고, 눈에 보이는 어떤 흔적도 남기지 않으며, 일상적인 플랫폼 유지 보수와 구별되지 않는다는 주장입니다. 위협 모델에 적어 둘 가치가 있는 유일한 속성이 바로 이것입니다 — 누군가 무엇을 하고 있는가가 아니라, 여러분이 알아채지 못한 채 무엇을 할 수 있는가입니다. 한 단계 바깥에서도 같은 논리가 적용되기에, 앞단의 레지스트리와 프록시도 호스트와 같은 목록에 올라야 합니다.

재부팅 문제, 그리고 그것을 무력화하는 지름길

암호화된 루트 볼륨은 시스템이 SSH 접속을 받을 수 있을 만큼 부팅되기 전에 잠금 해제되어야 합니다. 노트북이라면 키보드로 암호 문구를 입력하면 됩니다. 하지만 한 번도 들어가 본 적 없는 건물에, 이천 킬로미터 떨어진 머신이라면 그 순간 손 닿는 곳에 키보드가 없습니다. 이에 대한 현실적인 답은 모두 트레이드오프이며 — 아래 네 가지 중 하나만은 트레이드오프가 아니라, 트레이드오프를 한 것처럼 보이게 하는 수법일 뿐입니다.

원격 머신에서 암호화된 루트 볼륨을 잠금 해제하는 네 가지 방법

방법	무인 재부팅	도난된 디스크 방어	대가
부팅 이미지로 SSH 접속	아니요	예	initramfs 안의 최소한의 SSH 서버로 접속해 암호 문구를 입력할 수 있습니다. 사람이 깨어서 연락 가능해질 때까지 머신은 멈춰 있습니다. 이는 정직한 선택이며, 그 대가도 실재합니다 — 새벽 네 시의 재부팅은 누군가 알아차릴 때까지 그대로 장애가 됩니다.
네트워크 종속 키	예	부분적	머신은 부팅 시 다른 곳에서 운영하는 서버로부터 잠금 해제 키를 가져오며, 위치가 바뀌었거나 여러분이 재부팅하지 않은 머신에는 키 제공을 거부할 수 있습니다. 키 서버는 계속 가동되어야 하고, 같은 명령이 닿지 않는 곳에 있어야 합니다 — 그렇지 않으면 자물쇠 하나에 문 두 개로 키를 나눈 것에 지나지 않습니다.
부팅 이미지 안의 키 파일	예	아니요	키는 initramfs 안에 있고, initramfs는 암호화되지 않은 부팅 파티션 위에 있으며, 그 부팅 파티션은 다름 아닌 보호하려던 디스크 위에 있습니다. 디스크를 가져가는 사람은 키도 함께 가져갑니다. 이 구성은 흔하고 부팅도 매끄럽지만, 무엇으로부터도 전혀 지켜 주지 못합니다.
TPM에 봉인	예	부분적	직접 소유한 하드웨어라면 실제 보안 칩이 변조되지 않은 부팅 체인에만 키를 내줍니다. 가상 서버에서는 그 칩 자체가 호스트에 의해 에뮬레이션되므로, 그 칩에 키를 봉인하는 것은 애초에 키를 감추려 했던 바로 그 당사자에게 키를 넘기는 셈입니다.

세 번째 행은 오래 들여다볼 가치가 있습니다. 요구 사항이 디스크는 암호화되어야 한다라고만 적혀 있고 아무도 그 목적을 묻지 않았을 때 이르게 되는 결과가 바로 이것입니다. 감사는 통과합니다. 블록 디바이스는 실제로 암호화되어 있습니다. 하지만 키는 같은 물리 디스크 위, 복구 셸이 4초면 읽어 낼 파일 안에 함께 실려 있습니다.

이 지점이 바로 임대한 가상 머신과 직접 소유한 머신의 가장 뚜렷한 실질적 차이입니다. 전용 서버에서는 대역 외 관리 인터페이스가 재부팅에도 살아남는 콘솔을 제공하므로, 첫 번째 행은 더 이상 장애가 아니라 2분짜리 중단으로 바뀝니다 — 그리고 네 번째 행의 에뮬레이션 칩 문제도 사라집니다. 칩이 방어 대상으로 삼는 바로 그 당사자가 소프트웨어로 구현한 것이 아니라 보드에 납땜되어 있기 때문입니다.

전체 디스크 암호화가 실제로 사 주는 것

같은 질문을 여덟 가지 방식으로 던져 봅니다. 중요한 것은 마지막 열입니다. 암호화가 도움이 되지 않는 모든 행에서 대신 다른 무언가가 그 역할을 하고 있으며, 그 무언가의 이름을 밝히는 것이 이 작업의 전체 가치이기 때문입니다.

여덟 가지 시나리오와 전체 디스크 암호화가 결과를 바꾸는지 여부

시나리오	암호화가 도움이 되는가	실제로 결정하는 요소
드라이브가 폐기, 재판매되거나 보증 반품되는 경우	예	이를 대신 막아 주는 것은 아무것도 없습니다. 드라이브는 끊임없이 데이터 센터를 떠나며, 데이터 삭제는 하나의 절차이고, 절차는 조용히 실패하곤 합니다. 전체 디스크 암호화가 애초에 만들어진 시나리오가 바로 이것이며, 이 상황에서는 광고 그대로 작동합니다.
머신 전원이 꺼진 상태에서 디스크가 분리되는 경우	예	같은 보호가 같은 경계선을 따라 적용되며, 그 경계선은 바로 꺼짐이라는 단어입니다. 가동 중에 탈취된 머신은 잠금이 풀린 채, 볼륨이 열리고 키가 상주한 상태로 탈취된 머신입니다.
백업 사본이 다른 곳에 있는 경우	부분적	원본 볼륨의 암호화는 데이터 사본에는 아무 영향도 주지 못합니다. 결정하는 것은 그 백업이 나가기 전에 암호화되었는지, 그리고 그 키가 백업 대상 머신에는 저장되어 있지 않은지입니다.
플랫폼이 스냅샷을 찍는 경우	부분적	직접 암호화한 볼륨의 디스크만 담은 스냅샷은 암호문일 뿐이며, 암호 문구가 없는 사람에게는 쓸모가 없습니다. 반면 메모리 상태까지 담는 스냅샷은 키도 함께 담습니다. 이 둘 모두 똑같이 "스냅샷"이라고 불립니다.
누군가 가동 중인 머신에서 셸을 확보하는 경우	아니요	볼륨은 이미 열려 있으며, 침입자는 블록이 아니라 파일을 읽습니다. 이 행을 결정하는 것은 패치 적용, 최소 권한 원칙, 그리고 서비스마다 재사용하지 않는 자격 증명이며, 암호화는 여기에 아무런 기여도 하지 못합니다.
호스트 운영자, 또는 호스트 운영자의 접근 권한을 쥔 사람인 경우	아니요	이를 막는 것은 키가 머신 안으로 아예 들어가지 않는 암호화뿐입니다. 하드웨어 메모리 암호화가 유일한 예외이며, 이는 어디서나 기본적으로 꺼져 있습니다. 다음 절에서 다룹니다.
제공업체에 명령이 송달되는 경우	부분적	누가 무엇을 소명하며 요청할 수 있는지는 사법 관할이 결정하고, 그 답변에 무엇이 담길 수 있는지는 암호화가 결정합니다. 저희가 공개한 입장은 두 개의 개별 문장으로 되어 있으며, 둘 다 중요합니다 — 저희는 고객의 키를 보유하지 않으며 제출할 수도 없다는 것, 그리고 가상 서버의 암호화되지 않은 볼륨이라도 해당 서비스를 특정하는 명령은 여전히 필요하다는 것입니다.
유출 사실을 알려야 하는 경우	부분적	이용자가 EU에 있다면 GDPR 제32조는 요구되는 조치 중 하나로 암호화를 명시하며, 제34조는 데이터가 판독 불가능한 형태로 처리되었을 경우 개인에게 통지할 의무를 면제합니다 — 규제 당국에 대한 통지 의무는 결코 면제되지 않습니다. 이것이 적용되는지는 전적으로 데이터가 나갈 때 키가 어디에 있었는지에 달려 있습니다.

디스크 위의 계층: 적대적인 호스트에서도 살아남는 것

지금까지 다룬 모든 내용은 블록 디바이스에서 끝나는 계층에 관한 것이었습니다. 그 위에는 세 가지가 있으며, 이 셋을 합쳐야 앞선 표의 다섯 번째, 여섯 번째, 일곱 번째 행에 대한 유일한 답이 됩니다.

애플리케이션 아래가 아니라 위에서 암호화하기

필드 단위 암호화란 애플리케이션이 값을 데이터베이스에 넣기 전에 암호화하고, 다시 읽어 올 때 복호화하는 방식을 말합니다. 데이터베이스를 덤프하면 누가 어떤 경로로 가져가든 암호문만 남습니다. 다만 암호화된 열은 검색이나 색인이 불가능해지는 대가를 치르므로, 모든 필드가 아니라 메시지 본문, 업로드된 문서, 제3자 토큰처럼 그럴 가치가 있는 소수의 필드에만 적용해야 합니다. 이 길의 끝은 종단 간 암호화입니다 — 키는 사용자의 것이고, 서버는 평문을 결코 갖지 않으며, 적대적인 호스트도 얻을 것이 없으므로 아무것도 얻지 못합니다. 이 글에서 다루는 방식 중 누가 하드웨어를 운영하든 진정으로 상관없는 유일한 구조이며, 이는 인프라의 결정이기 이전에 제품의 결정입니다.

백업은 결과가 아니라 별도의 결정입니다

암호화된 머신에서 데이터가 빠져나가는 가장 흔한 경로는 백업입니다. 오브젝트 스토리지로 밀어 넣은 스냅샷, 두 번째 제공업체로 동기화한 데이터베이스 덤프, 워크스테이션으로 내려받은 아카이브 — 이들 중 어느 것도 원본 볼륨으로부터 아무것도 물려받지 않습니다. 데이터를 백업에 쓰는 바로 그 순간에, 머신 자체가 닿을 수 없는 곳에 보관된 키로 암호화하십시오. 그래야 침해된 서버가 자신의 이력조차 복호화하지 못합니다. 그런 다음, 필요해지기 전에 다른 머신에서 한 번 복원해 보십시오 — 열 수 없는 암호화된 백업은 한꺼번에 모든 것을 잃는 유독 깔끔한 방법입니다. 다른 나라에 둔 사본은 곧 다른 규칙 아래 놓인 사본이기도 하며, 이는 자신도 모르는 사이에 두 번째 사법 관할을 선택한 셈입니다.

메모리 암호화, 그리고 여러분에게는 아마 없을 이유

아무도 암호화하지 않는 그 상태에도 하드웨어 차원의 답은 존재합니다. AMD의 SEV-SNP, 인텔의 TDX 같은 기밀 컴퓨팅 확장 기능은 게스트의 메모리와 레지스터 상태를, 하이퍼바이저가 아니라 별도의 보안 프로세서가 쥔 키로 암호화합니다. 그래서 메모리를 덤프한 호스트가 얻는 것은 암호문뿐입니다. 이는 실재하며 이미 출시되어 있습니다. 다만 적용 범위는 좁습니다 — SEV-SNP는 3세대 EPYC 이상의 실리콘을 요구하고, 호스트는 이를 위해 일부러 설정되어야 하며, 게스트는 그것을 갖췄음을 증명해야 합니다. 범용 가상 서버 중 이를 제공하는 곳은 거의 없으며, 조용히 제공하는 곳은 하나도 없습니다. 제공업체가 서면으로 제공한다고 밝히고 그 증명을 직접 검증하는 방법까지 알려주지 않는 한, 없다고 가정하십시오.

한계를 솔직하게 인정하는 구성

이 모든 이야기의 결론이 신경 쓰지 마라는 아닙니다. 결론은 그 한계를 움츠러들지 않고 소리 내어 말할 수 있는 구성입니다.

1. 맞서고 있는 단 하나의 시나리오를 적어 봅니다 (5분). 폐기된 드라이브, 가동 중에 압수된 머신, 적대적인 호스트, 법원 명령, 반드시 알려야 하는 유출. 이들은 저마다 답이 다르며, 다섯 가지 모두를 겨냥한 구성은 결국 그중 어느 것도 확실히 달성하지 못합니다.
2. 키가 있는 곳에 암호화를 둡니다 (결정). 제공업체가 키를 쥐고 있다면, 여러분이 산 것은 드라이브가 건물 밖으로 나가는 상황에 대한 보호뿐이며 그 이상은 없습니다. 그 이상을 원한다면, 볼륨은 게스트 내부에서, 여러분 자신이, 플랫폼이 결코 보지 못하는 무언가로 잠금 해제해야 합니다.
3. 루트가 아니라 데이터 볼륨을 암호화합니다 (설정). 루트를 암호화하면 재부팅마다 여러분을 기다리게 됩니다. 데이터베이스 디렉터리, 업로드 파일, 비밀 값을 담는 별도의 암호화 볼륨을 두면, 민감한 부분은 여러분이 열 때까지 잠긴 채로 머신 스스로 다시 살아날 수 있습니다. 이것이 대다수 소규모 플랫폼이 택해야 할 절충안이지만, 이를 명시적으로 적어 두는 곳은 거의 없습니다.
4. 키 파일을 암호화되지 않은 부팅 파티션에 절대 남기지 않습니다 (규칙). 머신이 키 서버도 콘솔도 없이 무인으로 부팅된다면, 키는 디스크 위에 있을 수밖에 없습니다 — 세 번째 가능성은 없습니다. 도난된 드라이브가 정말로 위협 모델의 전부라면 이는 나쁘지 않은 절충이지만, 그 밖의 모든 경우에는 스스로를 속이는 일입니다.
5. 백업은 기록되는 시점에, 다른 곳에 보관된 키로 암호화합니다 (설정). 그런 다음, 아무 일도 터지지 않은 날에 다른 머신으로 하나를 복원해 보십시오.
6. 무엇을 막았는지 한 문장으로 말합니다 (5분). 대략 이런 문장입니다 — 이 디스크를 랙에서 뽑아 간 공격자는 아무것도 얻지 못하지만, 가동 중인 머신이나 그 호스트에서 root 권한을 가진 사람은 모든 것을 얻습니다. 그 문장을 적기가 불편하다면, 그것이 사실이기 때문입니다.

여섯 가지 중 둘은 결정이고 넷은 설정입니다. 결정에는 오후 반나절이 걸리고 설정에는 한 시간이 걸리지만, 그 오후 반나절 없이는 한 시간도 아무 가치가 없습니다. 순서를 거꾸로 하면 첫 번째 표의 세 번째 행에 이르게 됩니다 — 감사는 통과하지만 아무도 지켜 주지 못하는 머신입니다.

어떤 시나리오에 맞서고 있는지는 암호화의 질문이기 이전에 위협 모델링의 질문이며, 한 시간짜리 버전의 그 작업을 해 보면 여섯 번째 단계의 그 문장이 부산물처럼 거의 저절로 나옵니다. 만약 답이 드라이브가 아니라 법원 명령으로 드러난다면, 결과를 결정하는 계층은 디스크 위가 아니라 어느 나라의 법이 제공업체에 미치는가이며, 이를 신뢰하기 전에 확인하는 방법이 있습니다.

이 플랫폼을 운영하는 엔지니어들이 작성했으며, 오늘에 다시 검토했습니다. 여기 내용 중 잘못되었거나 오래된 부분이 있다면 고객 패널을 통해 알려주십시오 — 실제로 이 중 절반가량이 그렇게 접수된 내용입니다.