VPS 전체 디스크 암호화

전체 디스크 암호화는 정확히 한 가지 질문에만 답합니다: 공격자가 여러분의 스토리지를 손에 넣었고 기기 전원이 꺼져 있을 때, 그가 얻는 것은 무엇인가? 여러분이 가질 법한 다른 모든 질문 — 호스트가 무엇을 볼 수 있는지, 실행 중인 서버가 압수되면 어떻게 되는지, 백업은 안전한지 — 은 저마다 답이 다르며, 이를 모두 하나로 취급하는 것이야말로 아무것도 보호하지 못하는 암호화로 끝나는 지름길입니다.

이 구분은 솔직하게 짚고 넘어갈 가치가 있습니다. "LUKS로 암호화됨"이라는 문구는 이 업계의 거의 모든 프라이버시 호스팅 페이지에 등장하며, 저희 페이지도 예외는 아닙니다. 이는 실질적인 통제 수단이고 운영 비용도 거의 들지 않지만, 동시에 호스팅 업계에서 가장 과장되게 홍보되는 통제 수단이기도 합니다. 이 가이드에서는 임대 서버에서 저장 데이터 암호화가 실제로 무엇을 막아주는지, 배포할 가치가 있는 세 가지 방식과 각각의 명령어, 소형 VPS에서 실제로 중요한 두 가지 설정, 그리고 이 모든 노력을 겉치레로 전락시키는 몇 가지 실수를 다룹니다.

저장 데이터 암호화가 실제로 보호하는 것

저장 데이터 암호화란 볼륨이 닫혀 있는 동안에는 저장 매체상의 바이트가 암호문이라는 뜻입니다. 이는 좁은 범위의 주장이며, 그 가치는 단 하나의 변수에 달려 있습니다: 공격자가 들이닥치는 그 순간 키가 어디에 있는가입니다.

이를 실망이 아니라 정의로 받아들이십시오. 드라이브 탈취라는 노출 유형을 제거하는 것이 한 시간의 작업만큼의 가치가 있는 이유는, 바로 그것이 다른 어떤 방어 수단도 없는 유형이며, 누구도 여러분을 표적으로 삼지 않아도 일어나는 유형이기 때문입니다: 하드웨어가 고장 나 반납되고, 어레이가 퇴역하고, 볼륨이 다음 임차인에게 재발급됩니다. 암호화는 이 모든 것을 아무 일도 아닌 것으로 만들어 줍니다.

VPS가 노트북과 다른 이유

노트북에서는 설계가 자명합니다. 부팅 시 패스프레이즈를 입력하면 키는 기기가 켜져 있는 동안에만 RAM에 존재하고, 전원을 끄면 이야기는 끝납니다. 서버는 콘솔 앞에 아무도 없습니다. 부팅할 때마다 무언가가 키를 공급해야 하며, 그 "무언가"의 후보마다 가용성과 보호 사이의 트레이드오프가 있습니다:

• 사람이 직접 입력합니다. 키가 기기에 절대 머무르지 않으므로 가장 강력한 방식입니다 — 다만 여러분 없이는 서버가 재부팅 후 돌아올 수 없고, 운영체제가 존재하기도 전에 접속할 방법이 필요합니다.
• 기기 자체가 보관합니다. 편리하지만, 대부분의 자가 구성 환경에서는 자기모순적입니다: 같은 가상 디스크에 있는 키 파일은 그 디스크를 손에 넣는 사람이 곧 키도 손에 넣는다는 뜻입니다.
• 다른 기기가 넘겨줍니다. 네트워크에 종속된 잠금 해제 방식으로, 보통 Clevis와 Tang 서버 조합을 씁니다. 서버는 여러분이 통제하는 호스트에 여전히 접속할 수 있는 동안에만 스스로 잠금을 해제하며, 이는 실제로 유용한 속성입니다 — 다만 신뢰를 없애는 것이 아니라 옮기는 것일 뿐입니다.

대부분의 가이드가 건너뛰는 두 번째 차이점이 있습니다. VPS에서는 /boot와 initramfs가 평문이며, 이들은 결국 공급자가 통제하는 스토리지 위에 있고, 여러분이 검증할 수 있는 부팅 체인이 존재하지 않습니다 — 여러분 소유의 TPM도, 측정된 부팅도, 증명할 수단도 없습니다. 여러분의 패스프레이즈를 원하는 호스트라면 initramfs를 변조해 다음번 잠금 해제 때 그것을 가로챌 수 있습니다. 이는 저희가 실제로 하는 어떤 일을 묘사하는 것이 아니라, 이 아키텍처가 허용하는 바를 묘사하는 것이며, 임대한 컴퓨터를 두고 추론할 수 있는 유일하게 정직한 방식입니다. 저희의 VPS 대 전용 서버 비교에서는 하드웨어 관점에서 같은 신뢰 경계를 다루며, 오프쇼어 익명성에 대한 저희의 솔직한 답변에서는 그 주변 마케팅에도 같은 원칙을 적용합니다.

배포할 가치가 있는 세 가지 방식

단 하나의 정답인 설정은 없습니다 — 여러분이 감수할 수 있는 실패 양상을 가진 설정이 있을 뿐입니다. 이 세 가지가 실질적으로 모든 실제 사례를 아우릅니다.

특별히 그러지 말아야 할 이유가 없다면 첫 번째 방식부터 시작하십시오. 운영 위험은 아주 작은 반면 대부분의 보호 효과를 제공하며, 다른 두 방식에는 없는 한 가지 속성도 갖추고 있습니다: 그 무엇도 서버가 다시 온라인 상태로 돌아오는 것을 막지 못한다는 점입니다. 세 번째 방식은 패스프레이즈가 호스트가 하는 약속이 아니라 호스트가 결코 닿을 수 없는 사실이 되는 유일한 방식이며, 이것이 바로 저희 전용 서버가 저희조차 알지 못하는 패스프레이즈로 설치 시점에 LUKS를 적용하는 이유입니다.

실행 중인 VPS에서 데이터 볼륨 암호화하기

가장 먼저 시도해야 할 방식입니다. 아무것도 재설치하지 않고, 부팅 과정도 전혀 바뀌지 않으며, 실수하더라도 최악의 결과는 그냥 버리면 되는 컨테이너 파일 하나뿐입니다. 실행 중인 Debian 또는 Ubuntu 서버에서 15분이면 끝납니다.

• 도구를 설치하십시오. apt install cryptsetup. 사용 중인 플랜에 두 번째 블록 장치가 딸려 있다면 그것을 직접 사용하고 다음 단계는 건너뛰십시오.
• 컨테이너를 만드십시오. 디스크가 하나뿐인 VPS에서는 파일을 만드는 것이 현실적입니다: fallocate -l 40G /var/lib/vault.img. 이는 디스크처럼 동작하며 나중에 용량을 늘릴 수도 있습니다.
• LUKS2로 포맷하십시오. cryptsetup luksFormat --type luks2 /var/lib/vault.img. 암호 방식은 기본값을 그대로 사용하십시오. 소형 서버에서 손댈 가치가 있는 단 하나의 매개변수는 아래 절에서 다룹니다.
• 열어서 파일 시스템을 만드십시오. cryptsetup open /var/lib/vault.img vault를 실행하면 /dev/mapper/vault가 생성됩니다. 이어서 mkfs.ext4 /dev/mapper/vault와 mount /dev/mapper/vault /srv/vault를 실행하십시오.
• 중요한 데이터를 옮긴 뒤 서비스가 그곳을 바라보게 하십시오. 바인드 마운트나, 서비스를 멈춘 상태에서의 rsync가 대개 심볼릭 링크보다 깔끔합니다 — 특히 데이터베이스는 여기저기 옮겨 다니는 것을 싫어합니다.
• LUKS 헤더를 백업하십시오. cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin을 실행한 뒤, 그 파일을 서버 밖으로 옮기십시오. 컨테이너 앞부분의 몇 킬로바이트만 손상되어도 그 뒤의 모든 바이트가 영구히 사라지며, 이것이 존재하는 유일한 보험입니다.
• 닫은 뒤 다시 들어갈 수 있는지 확인하십시오. umount /srv/vault && cryptsetup close vault를 실행한 다음, 기억이 아니라 메모를 보고 다시 여십시오. 안에 값진 것이 들어가기 전에 이 작업을 해 두십시오.

재부팅 후에도 볼트는 여러분이 로그인해서 열기 전까지 닫힌 채로 있습니다. 이는 우회해야 할 제약이 아니라, 바로 그것이 핵심입니다. 스스로 열리는 볼륨은 키가 기기 위에 있는 볼륨입니다.

SSH 원격 잠금 해제를 사용한 전체 루트 암호화

전원이 꺼진 채로 압수당해도 읽을 수 있는 것이 아무것도 남지 않아야 한다는 요건 — 로그, 셸 기록, 패키지 목록, 실행 중인 것의 윤곽까지 — 이 있다면 루트 파일 시스템도 컨테이너 안에 있어야 합니다. 그러면 문제는 아직 부팅되지 않은 기기에 패스프레이즈를 어떻게 전달하느냐가 되며, 그 답은 initramfs 안에 들어 있는 아주 작은 SSH 서버입니다.

• 처음부터 암호화된 상태로 설치하십시오. 커스텀 ISO 업로드를 통해 배포판 설치 프로그램을 부팅하고, 암호화된 LVM으로 안내형 파티셔닝을 선택하십시오. 실행 중인 루트 파일 시스템을 그 자리에서 변환하는 것도 가능은 하지만 그만한 위험을 감수할 가치가 없습니다.
• 부팅 전 SSH 서버를 추가하십시오. apt install dropbear-initramfs를 실행한 뒤, /etc/dropbear/initramfs/authorized_keys에 공개키를 넣으십시오. 이는 평소 사용하는 SSH와는 별개의 키 세트입니다 — 전용 키를 사용하십시오.
• 단단히 잠그십시오. /etc/dropbear/initramfs/dropbear.conf에서 DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s"로 설정하십시오: 비밀번호 로그인 금지, 포트 포워딩 금지, 전용 포트, 그리고 멈춘 세션이 부팅을 계속 붙잡아 두지 못하도록 하는 유휴 시간 제한입니다.
• initramfs에 네트워크를 부여하십시오. 정적 ip= 매개변수를 GRUB_CMDLINE_LINUX(/etc/default/grub 안에 있습니다)에 추가하십시오 — 형식은 ip=address::gateway:netmask::interface:off입니다. 이 단계에서 DHCP에 의존하는 것이 사람들이 잠겨 나가떨어지는 원인입니다.
• 다시 빌드하고 재부팅하십시오. update-initramfs -u && update-grub을 실행한 뒤 재부팅하고, ssh -p 2222 root@your-server로 접속해 cryptroot-unlock을 실행하십시오. 클라이언트가 알 수 없는 호스트 키라고 경고할 것입니다: initramfs는 자신만의 호스트 키를 가지고 있으며, 이는 예상된 일이므로 별도의 known_hosts 항목으로 고정해 둘 가치가 있습니다.
• 의존하기 전에 실패 경로를 테스트하십시오. 커널 업데이트를 설치하고, 재부팅하고, 다시 잠금을 해제해 보십시오. 커널 업그레이드는 initramfs를 다시 생성하며, 바로 그 순간 잘못된 설정이 드러납니다.

중요한 두 가지 설정과 소형 VPS의 함정

LUKS2는 기본값으로 512비트 키의 AES-XTS와 Argon2id 키 유도 방식을 사용합니다. 둘 다 올바른 선택입니다. 암호 방식을 직접 손보는 것은 더 느리면서 동시에 더 약해지는 지름길이며, 인터넷에는 정확히 그렇게 만드는 복사-붙여넣기 명령줄이 넘쳐납니다. 다만 주의를 기울일 가치가 있는 것이 두 가지 있습니다.

성능은 문제가 되지 않습니다 — 문제가 되기 전까지는

grep -m1 -o aes /proc/cpuinfo로 하드웨어 가속 여부를 확인하고, cryptsetup benchmark로 직접 측정해 보십시오. AES-NI를 갖춘 CPU라면 — 저희가 운영하는 모든 노드가 그렇습니다 — AES-XTS는 코어당 초당 몇 기가바이트를 처리하며, 이는 단일 가상 디스크가 낼 수 있는 속도를 여유 있게 웃돌기 때문에, 체감되는 비용은 대량 I/O 상황에서 CPU 몇 퍼센트와 약간의 지연 시간 증가뿐입니다. AES-NI가 없으면 상황은 역전되어 암호화가 병목이 되며, 이때가 바로 대체 암호 방식이 맹목적인 관행이 아니라 실질적인 결정이 되는 유일한 경우입니다.

발목을 잡는 것은 Argon2id의 메모리 요구량입니다

Argon2id는 의도적으로 메모리를 많이 소모하도록 설계되었으며, cryptsetup은 포맷 시점에 포맷을 실행하는 기기의 RAM을 기준으로 이를 보정합니다. 32GB 워크스테이션에서 볼륨을 포맷한 뒤 1GB VPS로 옮기면, 키 유도가 요구하는 메모리가 없어 잠금 해제가 아예 실패할 수 있습니다 — 실행 중인 시스템보다 사용 가능한 메모리가 훨씬 적은 initramfs 안에서는 상황이 더 나쁩니다. 소형 인스턴스에서는 값을 고정해 두십시오: cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb는 이를 256MB로 제한합니다. 값을 낮추면 오프라인 무차별 대입 공격에 대한 저항력이 실제로 줄어들므로, 더 긴 패스프레이즈로 보완하십시오.

복사-붙여넣기가 아니라 의식적인 판단이 필요한 선택형 플래그가 하나 있습니다: --allow-discards는 TRIM을 하부 장치로 그대로 전달하며, 이는 SSD 수명과 안정 상태 성능에는 좋지만 동시에 볼륨의 얼마만큼이 사용 중이고 대략 어디에 있는지도 드러냅니다. 기본값은 꺼짐입니다. 무엇이 유출되는지 알고 나서 켜십시오.

스왑, 로그, 스냅샷 — 사람들이 잊어버리는 부분

주변에서 평문이 새고 있는 암호화된 볼트야말로 가장 흔한 실패이며, 누군가 들여다보기 전까지는 눈에 띄지 않습니다.

• 스왑. 여러분이 신경 써서 볼트에 넣은 자료를 포함해, 메모리에 있는 무엇이든 디스크로 페이징될 수 있습니다. 스왑을 아예 비활성화하거나, /etc/crypttab에 swap /dev/vdb1 /dev/urandom swap,cipher=aes-xts-plain64,size=256와 같은 줄을 추가해 부팅할 때마다 무작위 키를 부여하십시오.
• 여러분이 살펴보지 않은 곳에 기록되는 모든 것. /var/log, /tmp, 데이터베이스 데이터 디렉터리, /var/lib/docker, 셸 기록, systemd 저널까지입니다. /srv/vault를 암호화해도 PostgreSQL이 여전히 /var/lib/postgresql에 기록한다면 정확히 아무 의미가 없습니다. 암호화하기 전에 먼저 목록을 만드십시오.
• 스냅샷. 암호화된 볼륨의 블록 수준 스냅샷은 암호문이므로 문제가 없습니다. 메모리 상태까지 담는 스냅샷은 전혀 다른 대상이며 키를 포함할 수 있습니다. 사용하기 전에 공급자의 패널이 어떤 종류를 찍는지 먼저 파악하십시오.
• 백업. 목적지는 이 문제를 해결할 자리가 아닙니다. restic이나 BorgBackup 같은 도구는 발신지에서 대상이 절대 보지 못하는 키로 암호화하며, 그래서 백업 서버는 신뢰해야 하는 기기가 아니라 다른 관할권에 있는 평범한 기기여도 됩니다.
• 이미 어딘가로 보낸 평문. 저장 데이터 암호화는 소급 적용되지 않습니다. 이미 복사되었거나, 메일로 전송되었거나, 다른 곳과 동기화된 것은 지금 여러분이 그리는 경계 바깥에 있습니다.

키가 어디에 있는가가 설계의 전부입니다

위의 모든 방식은 사실 키 보관에 관한 이야기입니다. 네 가지 선택지가 있으며, 이들은 동등하지 않습니다:

• 머릿속에만 두고 부팅마다 입력. 최대의 보호, 최대의 운영 마찰. 여러분 없이는 기기를 정말로 읽어낼 수 없습니다.
• 암호화된 기기 위의 파일 안에 저장. 순진한 디스크 재판매에는 대응이 되지만 그 외에는 아무것도 막지 못합니다. 그 파일이 평문 상태인 /boot 위에 있다면 아무것도 막지 못합니다 — 셀프 호스팅 암호화에서 가장 흔한 단 하나의 실수입니다.
• 여러분이 통제하는 기기에, 네트워크로 가져옴. Tang 서버에 묶인 Clevis: clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'. 서버는 홈에 연결할 수 있는 동안에는 무인으로 부팅되며, 그 외의 어떤 곳에서도 잠금 해제를 거부합니다. 무인 서버 집단에 매우 적합하며, 대신 Tang 호스트가 반드시 방어해야 할 대상이 됩니다.
• TPM 안에. 여러분이 소유한 하드웨어에서는 의미가 있습니다. VPS에서는 가상 TPM을 바로 여러분이 배제하려는 그 하이퍼바이저가 제공하므로, 이는 신뢰가 아니라 편의를 해결할 뿐입니다.

대부분의 설계는 한 가지 시험으로 판가름 납니다: 여러분 없이도 기기가 로그인 프롬프트에 도달할 수 있다면, 키는 그 기기 위에 있는 것입니다. 이는 얼마든지 합리적인 타협일 수 있습니다 — 많은 워크로드는 집요한 공격자에 대한 저항력보다 무인 재부팅을 더 원합니다. 다만 그 선택을 의식적으로 내리고, 결과를 실제와 다른 것으로 포장하지는 마십시오.

호스트가 볼 수 있는 것과 관할권이 넘겨받는 지점

VPS에서는 하이퍼바이저가 여러분 아래에 자리 잡고 있습니다. 저희는 게스트 메모리를 읽지 않고, 트래픽·접속·DNS 로그도 콘솔 기록도 남기지 않습니다 — 다만 이는 정책이며, 솔직히 말하면 VPS는 여러분이 그 정책을 신뢰하기를 요구합니다. 베어메탈에서는 여러분과 실리콘 사이에 하이퍼바이저가 없습니다: 설치 시점에 설정되고 저희조차 받아 본 적 없는 패스프레이즈로 보호되는 전체 디스크 암호화는 저희가 드리는 보장이 아니라 그 기기의 물리적 속성입니다. 여러분이 정말로 선택하고 있는 것은 암호 방식이 아니라 바로 이 차이입니다.

그래서 암호화와 관할권은 하나의 답을 이루는 두 반쪽입니다. 암호화는 여러분의 디스크 사본이 무슨 가치가 있는지를 결정하고, 관할권은 누가, 어떤 절차로, 얼마나 빨리 그 기기를 내놓으라고 강제할 수 있는지를 결정합니다. 저희는 아이슬란드, 스위스, 파나마, 루마니아, 몰도바, 네덜란드, 러시아까지 일곱 곳에서 운영하고 있으며, 그중에서 고르는 논리는 저희 관할권 가이드에서, 더 짧게는 관할권 선택 도구와 위치 페이지에서 확인하실 수 있습니다.

암호화가 손댈 수 없는 부분은 키 제출 강제인데, 이는 하드웨어가 아니라 여러분을 겨냥하기 때문입니다. 영국, 프랑스, 호주는 복호화 키를 제출하도록 요구하고 거부하면 처벌할 수 있는 법을 가진 나라에 속합니다. 그 노출 위험은 서버가 어디에 있는지가 아니라 여러분이 어디에 있는지를 따라다니며, 기기의 어떤 설정으로도 바뀌지 않습니다. 신분증 없이 가입하는 것은 애초에 남는 서류 흔적의 양을 제한해 줍니다 — KYC 없는 호스팅과 암호화가 결국 같은 맥락에서 논의되는, 실용적이고 화려할 것 없는 이유입니다 — 하지만 이미 여러분의 이름을 확보한 법원에 맞서는 방어 수단은 아닙니다.

암호화를 겉치레로 만드는 아홉 가지 실수

• 같은 디스크에 있는 키 파일로 자동 잠금 해제하기. "암호화된" 서버 대다수가 이 경우이며, 자물쇠에 열쇠를 꽂아 둔 것과 다를 바 없습니다.
• 민감한 데이터가 결코 도달하지 않는 볼륨을 암호화하기. 볼트는 비어 있고 데이터베이스는 그 안에 없습니다.
• LUKS 헤더를 절대 백업하지 않기. 컨테이너 앞부분의 섹터 하나만 손상되어도 그 뒤의 모든 바이트가 영원히 사라집니다.
• 잠금 해제 경로를 절대 테스트하지 않기. 그러다 커널 업그레이드가 initramfs를 다시 생성하면 다음 재부팅이 구조 작전이 되어 버립니다.
• 큰 기기에서 포맷하고 작은 기기에서 잠금 해제하기. Argon2id가 요구하는 메모리를 VPS가 제공하지 못해 볼륨이 열리지 않습니다.
• 로그인 비밀번호처럼 패스프레이즈를 고르기. 키 유도 함수 외에는 오프라인 공격의 속도를 제한하는 것이 아무것도 없습니다. 시간을 벌어주는 것은 길이입니다.
• 평문을 암호화로 옮기고 원본이 사라졌다고 가정하기. 가상화된 스토리지에서는 덮어쓰기가 확실하게 지워주지 않습니다.
• 기기를 관리하는 것과 같은 채널로 패스프레이즈를 전송하기. 이렇게 생기는 상관관계 문제는 서버 OpSec에서 다룹니다.
• 공급자의 암호화와 여러분 자신의 암호화를 혼동하기. "모든 인프라는 저장 데이터가 암호화되어 있습니다" — 저희도 마찬가지입니다 — 라는 말은 인프라를 보호할 뿐입니다. 인프라로부터 여러분을 보호하는 것은 오직 여러분이 직접 쥐고 있는 키뿐입니다.

그렇다면 VPS에서 이 작업을 할 가치가 있는가?

예, 기대치를 적절히 조정한다면 그렇습니다. 한 시간의 작업과 측정할 만한 운영 비용 없이, 암호화된 데이터 볼륨은 달리 대응할 방법이 없는 노출 유형 전체를 제거해 주며, 그것도 영구히 제거합니다: 퇴역한 하드웨어, 재발급된 스토리지, 남의 손에 넘어간 채 전원이 꺼진 기기까지 말입니다. 중요한 것을 담고 있는 모든 서버에서, 첫 한 시간 강화 체크리스트 직후에 이 정도는 해 두십시오.

다만 이것이 임대한 컴퓨터를 여러분의 컴퓨터로 바꿔주지는 않습니다. 여러분의 위협 모델에 호스트 자체가 공격자로 들어 있다면, 어떤 암호 방식으로도 그것은 해결되지 않습니다 — 답은 키를 IPMI로 입력하고 결코 하이퍼바이저를 거치지 않는 전용 하드웨어, 의도적으로 선택한 관할권, 그리고 굳이 있을 필요가 없는 것은 어떤 서버에도 두지 않는 규율입니다. 통제 수단을 실제 위협에 맞추는 것, 그것이 프라이버시와 프라이버시처럼 보이는 것의 차이입니다.