VPS 암호화는 cryptsetup luksFormat 한 줄이면 끝나는 일처럼 보이지만, 실제로는 사람들이 기대했던 것을 조용히 채워주지 못합니다. 임대한 머신에서는 커널 아래에 하이퍼바이저가 자리 잡고 있어, 위협 모델 자체가 전체 디스크 암호화가 원래 설계된 대상과 다릅니다. 이 가이드는 있는 그대로를 말합니다: VPS에서 LUKS가 막아주는 것과 막아주지 못하는 것, 실제로 작동하는 두 가지 배포 경로, 그리고 스스로 자신의 서버에서 잠기는 일이 없도록 SSH로 암호화된 루트를 잠금 해제하는 방법까지입니다.
임대 서버에서 암호화가 실제로 지켜주는 것
전체 디스크 암호화는 저장된 데이터(data at rest)를 보호합니다. 이 표현은 함축하는 바가 많은데, VPS에서는 어떤 순간이 저장된 상태이고 어떤 순간이 아닌지 명확히 짚어볼 필요가 있습니다 — 대부분의 기대가 무너지는 지점은 바로 이 둘 사이의 간극입니다.
폐기되는 하드웨어
드라이브는 고장 나고, 교체되고, 랙을 떠납니다. 수명을 다한 디스크에 남은 LUKS 볼륨은 다음에 그것을 다루는 사람에게 그저 잡음 덩어리일 뿐입니다. 이 경우에는 암호화가 문제를 완전히 해결합니다.
분리되거나 복사된 볼륨
머신 전원이 꺼진 상태에서 볼륨이 인스턴스에서 분리되거나 복제되거나 이미지로 뜨더라도, 그 결과물은 여러분의 파일이 아니라 암호문과 헤더일 뿐입니다.
구동 중인 머신
볼륨이 열려 있는 동안에는 마스터 키가 커널 메모리에 존재합니다. 원리상 하이퍼바이저 수준의 접근이라면 이 키에 닿을 수 있습니다. 암호화는 여기서 비용을 높일 뿐, 문을 완전히 닫아주지는 못합니다.
스스로 저지르는 실수
암호화되지 않은 스왑, 평문 백업, 마운트 전에 기록된 로그는 모두 이 보호막 바깥에 있습니다. 암호화된 서버에서 실제로 발생하는 유출은 대부분 암호 자체가 아니라 바로 여기서 일어납니다.
이 한계는 분명히 짚고 넘어가야 계획을 세울 수 있습니다: 볼륨이 잠금 해제된 동안에는 키가 여러분 소유가 아닌 하드웨어의 RAM에 올라가 있습니다. VPS에서의 LUKS는 오프라인 접근에는 강력한 해답이지만, 실시간 접근에는 부분적인 해답일 뿐입니다. 이를 관할권의 대체물로 여기지 말고, 실제로 신뢰할 수 있는 관할권과 함께 사용하세요 — /offshore-hosting 참고.
명령어를 입력하기 전에 구성부터 정하세요
실제 요구사항은 거의 대부분 네 가지 구성으로 정리됩니다. 잘못된 것을 고르면 재설치라는 대가를 치르게 되므로, 작업 도중이 아니라 지금 결정하세요.
경로 A — 이미 운영 중인 서버에서 데이터 볼륨 암호화하기
대부분의 사람들이 실제로 원하는 방식이 바로 이것입니다: 10분이면 끝나고, 재설치가 필요 없으며, 중요한 것은 모두 이 보호막 안에 들어갑니다. 먼저 두 번째 볼륨을 연결하세요 — /storage 요금제라면 대용량 디스크가 여기에 해당하고, 일반 /vps 라면 배포 시점에 볼륨을 추가할 수 있습니다.
- 1
대상 장치 확인하기
lsblk를 실행해 포맷하려는 장치가 비어 있는 것이 맞는지 확인하세요. luksFormat은 그 위에 있는 모든 것을 파괴하며 되돌릴 방법이 없습니다.
- 2
LUKS2 컨테이너 만들기
cryptsetup luksFormat --type luks2 /dev/vdb를 실행하면 대문자로 YES를 입력하라고 요구한 뒤 패스프레이즈를 설정하게 합니다. 히스토리도 없고 입력한 글자가 보이지도 않는 콘솔에서 정확히 다시 입력할 수 있는 패스프레이즈를 고르세요.
- 3
열고 파일시스템 만들기
cryptsetup open /dev/vdb cryptdata를 실행하면 /dev/mapper/cryptdata가 생성됩니다. 이어서 mkfs.ext4 /dev/mapper/cryptdata를 실행한 뒤, 데이터가 위치할 경로(예: /srv/data)에 마운트하세요.
- 4
부팅 시 잠금 해제 방식 정하기
재부팅할 때마다 패스프레이즈를 직접 입력하거나, cryptsetup luksAddKey로 키파일을 추가해 루트에 저장하는 방법이 있습니다. 키파일은 편리하지만 명백히 더 취약합니다 — 어떤 것을 맞바꾸고 있는지 분명히 인식하세요.
- 5
crypttab과 fstab 설정하기
장치 이름 대신 UUID=를 사용해 /etc/crypttab에 매핑을 추가한 다음, 잠금 해제가 실패하더라도 부팅이 멈추지 않도록 nofail 옵션과 함께 /etc/fstab에서 마운트하세요.
키파일이 암호화되지 않은 루트에 놓여 있다면, 지금 무엇을 얻은 것인지 정확히 알아야 합니다: 이 볼륨은 랙을 떠나는 디스크나 인스턴스에서 분리되는 디스크로부터는 보호되지만, VM 전체를 복제한 사본으로부터는 보호되지 않습니다 — 그 사본 안에 키도 함께 들어있기 때문입니다. 이보다 더 강한 보호가 필요하다면 패스프레이즈는 서버 바깥에서 와야 합니다.
경로 B — 커스텀 ISO로 암호화된 루트 구성하기
전원이 꺼진 상태에서 머신에 읽을 수 있는 것이 아무것도 남아 있지 않아야 한다는 요구사항이라면, 루트 자체가 LUKS 안에 있어야 합니다. 즉, 커스텀 ISO 부팅을 허용하는 제공업체에서 콘솔로 직접 새로 설치해야 한다는 뜻입니다.
- 1
콘솔에서 설치 프로그램 부팅하기
Debian이나 Ubuntu netinst ISO를 커스텀 ISO로 마운트하고 VNC나 시리얼 콘솔로 설치를 진행하세요. 이 단계는 SSH로는 전혀 할 수 없습니다 — 아직 접속할 시스템 자체가 존재하지 않기 때문입니다.
- 2
암호화된 LVM으로 안내에 따라 파티션 나누기
설치 프로그램은 작은 /boot를 평문으로 남겨둡니다. 볼륨이 열리기 전에 무언가는 먼저 실행되어야 하기 때문이며, root와 swap은 하나의 LUKS 컨테이너 안에 함께 배치됩니다.
- 3
보지 않고도 입력할 수 있는 패스프레이즈 고르기
재부팅할 때마다 SSH로 이 패스프레이즈를 다시 입력해야 하며, 입력한 글자도 보이지 않고 자동완성도 없습니다. 이런 상황에서는 기호를 뒤섞은 조합보다 단어 다섯 개짜리 패스프레이즈가 낫습니다.
- 4
로그아웃하기 전에 원격 잠금 해제 설정하기
막 암호화를 마친 루트는 다음 재부팅 후 패스프레이즈 입력 프롬프트에서 하염없이 멈춰 있게 됩니다. 콘솔이 아직 눈앞에 있는 바로 이 세션에서 원격 잠금 해제를 설정하세요.
RAM이 1~2GB인 요금제에서는 기본 Argon2id 키 유도 방식이 initramfs가 가진 것보다 더 많은 메모리를 요구할 수 있어, 패스프레이즈가 맞아도 부팅 시 잠금 해제가 실패할 수 있습니다. 포맷 시점에 cryptsetup luksFormat --pbkdf-memory 262144로 상한을 걸어두거나, 소형 인스턴스를 무인 재부팅에 맡기기 전에 cryptsetup luksDump로 기존 헤더를 점검하세요.
dropbear-initramfs로 SSH 원격 잠금 해제하기
암호화된 루트는 운영체제가 존재하기도 전에 패스프레이즈를 필요로 합니다. dropbear-initramfs는 initramfs 안에 작은 SSH 서버를 넣어 어디서든 패스프레이즈를 입력할 수 있게 해줍니다 — 이것이 암호화된 서버와 암호화된 벽돌을 가르는 차이입니다.
- 1
패키지 설치하기
apt install dropbear-initramfs를 실행하세요. initramfs 생성 과정에 후킹되어, 이후 만들어지는 모든 커널 이미지에 자동으로 다시 포함됩니다.
- 2
키 하나, 명령어 하나만 허용하기
공개 키를 /etc/dropbear/initramfs/authorized_keys에 넣으세요 — Debian 11 이하에서는 /etc/dropbear-initramfs/authorized_keys입니다. 줄 앞에 no-port-forwarding,no-agent-forwarding,no-x11-forwarding,command="cryptroot-unlock"를 붙여, 키를 도난당해도 프롬프트 하나 말고는 아무것도 얻지 못하게 하세요.
- 3
initramfs에 네트워크 연결해주기
제공업체가 DHCP를 지원한다면 그대로 작동합니다. 그렇지 않다면 GRUB_CMDLINE_LINUX에 정적 ip=ADDRESS::GATEWAY:NETMASK::eth0:off 파라미터를 추가하고 update-grub을 실행하세요. 마지막으로 update-initramfs -u -k all을 실행해 변경 사항을 이미지에 반영하세요.
- 4
의존하기 전에 전체 재부팅으로 테스트하기
제공업체 콘솔을 다른 창에 띄워둔 채 재부팅하고, 접속해서 패스프레이즈를 입력한 다음 부팅이 계속 진행되는지 지켜보세요. 검증하지 않은 잠금 해제 경로는 기능이 아니라 예정된 장애입니다.
initramfs는 부팅된 시스템이 제시하는 것과는 다른, 자신만의 SSH 호스트 키를 가지고 있으므로 재부팅할 때마다 클라이언트가 호스트 키가 바뀌었다고 경고합니다. /etc/dropbear/initramfs/dropbear.conf의 DROPBEAR_OPTIONS를 통해 dropbear를 별도 포트에서 실행하거나, ssh -o HostKeyAlias=box-initramfs로 접속하고, 두 지문(fingerprint)을 모두 기록해 두세요.
디스크 암호화가 대개 무너지는 지점은 키 관리입니다
암호 알고리즘 자체는 약점이었던 적이 없습니다. LUKS와 관련해 복구 가능했던 사고는 결국 키나 헤더 문제로 귀결되므로, 이 둘을 인프라로 취급하세요.
- 헤더는 즉시 백업하세요 — cryptsetup luksHeaderBackup /dev/vdb --header-backup-file luks-header.img — 그리고 서버 밖에 보관하세요. 부주의한 dd 명령 한 번으로 헤더가 손상되면, 패스프레이즈가 완벽해도 데이터는 영구히 사라집니다.
- 슬롯은 두 개를 사용하세요. LUKS2는 32개의 슬롯을 제공합니다: 하나에는 패스프레이즈를, 다른 하나에는 비밀번호 관리자에 보관한 길고 무작위한 복구 키를 넣으세요. 슬롯 하나만 쓰는 것은 스스로 만든 단일 장애점입니다.
- 원격 머신에서는 순서를 지켜 교체하세요 — luksAddKey로 새 키를 추가하고, 그 키로 볼륨이 열리는지 확인한 다음, luksKillSlot으로 이전 키를 제거하세요. 절대 순서를 뒤집지 마세요.
- 패스프레이즈와 서버 접속 정보는 서로 다른 곳에 보관하세요. 메모 하나가 유출되었다고 해서 주소와 키가 한꺼번에 넘어가서는 안 됩니다.
암호화가 성능에 미치는 대가
오버헤드는 실재하지만 대체로 체감되지 않습니다. 다른 시대의 벤치마크를 그대로 믿기보다, 실제로 사용하는 머신에서 직접 측정하세요.
사람들이 흔히 놓치는 부분
가장자리에서 평문이 새어 나오는 암호화 볼륨은 잘못된 안도감을 줄 뿐이며, 이는 아무 안도감도 없는 것보다 나쁩니다. 작업이 끝났다고 말하기 전에 다음 다섯 가지를 마무리하세요.
- 스왑. 암호화되지 않은 스왑 파티션에는 메모리를 거쳐 간 온갖 조각이 남을 수 있습니다. /etc/crypttab에 /dev/urandom 항목을 두어, 부팅할 때마다 새로운 무작위 키로 암호화하세요.
- 마운트 전에 기록되는 로그. 암호화된 볼륨이 아직 닫혀 있는 동안 기록되는 로그는 모두 평문 루트에 남습니다. 애플리케이션과 데이터베이스 로그는 이 보호막 안쪽 경로를 가리키도록 설정하세요.
- 백업. 암호화된 볼륨의 내용을 평문 상태로 오브젝트 스토리지에 복사하면 지금까지의 작업이 모두 무의미해집니다. restic, borg, age 등으로 백업을 별도로 암호화하고, 그 키는 다른 곳에 보관하세요.
- 스냅샷. 제공업체의 스냅샷은 RAM이 아니라 디스크를 캡처하므로 LUKS 볼륨은 그 안에서도 암호문 상태로 남습니다 — 하지만 암호화되지 않은 루트에 남아 있는 것은 그 상태 그대로 캡처됩니다.
- Discard. LUKS를 통해 discard 플래그를 전달하면 NVMe TRIM 기능은 계속 작동하지만, 어떤 블록이 사용되지 않는지가 밖으로 드러나 파일시스템이 얼마나 차 있고 대략 어떤 모양인지가 노출됩니다. 다른 설정을 그대로 베끼지 말고, 신중하게 판단해서 선택하세요.
그래도 호스트가 중요한 이유
암호화는 여러분이 통제하는 계층입니다: 머신 전원이 꺼지거나 디스크가 건물을 떠난 뒤, 데이터를 읽어내는 데 얼마만큼의 비용이 들지를 결정합니다. 그 주위를 둘러싼 계층 — 누가 하드웨어에 대한 접근을 강제할 수 있는지, 어떤 기록이 서버와 여러분을 연결 짓는지 — 은 제공업체와 그 관할권의 몫입니다. 저희 15개 리전 중 여섯 곳이 프라이버시 등급 관할권입니다. 목록은 /locations 에서, 그것이 실제로 무엇을 바꾸는지는 /offshore-hosting 에서 확인하세요.
위에서 다룬 경로가 애초에 가능한지는 제공업체의 세 가지 역량에 달려 있습니다: 커스텀 ISO 부팅 — 이것이 없으면 경로 B 자체가 불가능합니다 — 원격 잠금 해제가 돌아오지 않을 때를 위한 대역 외(out-of-band) 콘솔 접근, 그리고 애초에 머신을 법적 신원과 엮지 않는 가입 절차입니다. 저희의 모든 /offshore-vps 와 /storage 요금제는 커스텀 ISO로 부팅하고, 콘솔 접근을 제공하며, KYC 없이 선불 암호화폐 잔액으로 결제됩니다 — 그러니 암호화된 디스크가 이미 여러분의 이름이 적힌 서류 흔적 위에 놓이는 일은 없습니다. 호스트가 무엇을 볼 수 있고 볼 수 없는지에 대한 솔직한 설명은 /guides 에 있습니다.
배포 체크리스트
- 위협부터 명확히 하세요: 폐기되는 드라이브, 분리된 볼륨, 오프라인 이미지는 암호화가 답이 되는 대상입니다 — 구동 중인 하이퍼바이저는 아닙니다.
- 서버가 이미 구동 중이라면 데이터 볼륨을 암호화하세요(경로 A). 루트 자체를 암호화해야 할 때만 커스텀 ISO로 재설치하세요(경로 B).
- aes-xts-plain64를 사용하는 LUKS2를 쓰고, RAM 2GB 미만 요금제에서는 Argon2id 메모리 상한을 설정하세요.
- 패스프레이즈는 키 슬롯 하나에, 길고 무작위한 복구 키는 다른 슬롯에 넣고, 둘 다 서버 밖에 보관하세요.
- 실제 데이터를 단 1바이트라도 쓰기 전에 LUKS 헤더를 백업하세요.
- dropbear-initramfs는 기본값이 아닌 포트에서, 키 인증만으로, cryptroot-unlock 명령으로 제한해 운영하세요.
- 제공업체 콘솔을 옆에 열어둔 채로 재부팅과 잠금 해제 전 과정을 최소 한 번 테스트하세요.
- 오프사이트에 암호화된 백업을 두고, 복구 훈련도 한 번은 해보세요 — 검증하지 않은 백업은 백업이 아니라 희망 사항일 뿐입니다.
디스크 암호화를 하면 호스팅 제공업체가 제 데이터를 읽지 못하게 되나요?
저장된 상태에서는 그렇습니다: 머신 전원이 꺼지면 볼륨은 암호문이 되고, 패스프레이즈는 여러분의 머릿속을 벗어난 적이 없습니다. 하지만 볼륨이 열린 채로 서버가 구동 중일 때는, 마스터 키가 제공업체가 운영하는 하드웨어의 RAM에 올라가 있습니다. 암호화는 폐기된 드라이브, 분리된 볼륨, 콜드 이미지 같은 오프라인 경로는 모두 차단하고, 나머지 경우의 비용은 끌어올립니다. 이는 신뢰할 수 있는 관할권을 대체하는 것이 아니라 보완하는 역할을 합니다.
재설치 없이 기존 VPS를 암호화할 수 있나요?
별도의 데이터 볼륨이라면 가능합니다. 10분 정도면 되며, 위에서 다룬 경로 A가 바로 그것입니다. 루트 파일시스템은 현실적으로 어렵습니다. cryptsetup reencrypt로 파일시스템을 제자리에서 변환할 수는 있지만, 원격 머신에서 작업 도중 연결이 끊기거나 전원 이상이 발생하면 부팅 불가능한 서버와 긴 밤이 남게 됩니다. 커스텀 ISO로 재설치하는 편이 더 빠르고 훨씬 안전합니다.
LUKS는 성능을 얼마나 깎아먹나요?
대부분의 예상보다 적습니다. AES-NI 환경에서 일반적인 혼합 워크로드 기준으로 AES-XTS의 비용은 몇 퍼센트 수준이며, 최신 EPYC 코어에서 cryptsetup benchmark를 돌리면 여러 GB/s가 나옵니다. 체감되는 경우는 빠른 NVMe를 상대로 한 단일 스레드 순차 I/O로, 이때는 드라이브보다 코어 하나가 먼저 포화 상태에 이를 수 있습니다. 추측하지 말고 직접 사용하는 인스턴스에서 벤치마크하세요.
패스프레이즈를 잊어버리면 어떻게 되나요?
데이터는 사라집니다. 복구 메커니즘도, 제공업체 측 마스터 키도, 이를 되돌려줄 지원 티켓도 존재하지 않습니다 — 바로 그 성질이 이 설계의 핵심입니다. 무작위 복구 키를 담은 두 번째 키 슬롯과, 서버가 아닌 다른 곳에 보관한 LUKS 헤더 백업으로 스스로를 지키세요.
initramfs 안에서 SSH를 실행하는 것은 위험하지 않나요?
작고 잘 알려진 형태의 노출입니다. dropbear는 루트 파일시스템이 존재하기 전 단 몇 초 동안만 실행되고, 공개 키 인증만 허용하며, 패스프레이즈 입력 프롬프트만 띄우는 강제 명령 하나로 제한할 수 있습니다. 기본값이 아닌 포트를 사용하고 initramfs 호스트 키를 따로 기록해두면, 이것이 없을 때 확실하게 서버에서 잠겨버리는 상황에 비해 실질적인 위험은 미미합니다.
