رمزگذاری کامل دیسک روی VPS

رمزگذاری کامل دیسک دقیقاً به یک سؤال پاسخ می‌دهد: وقتی دشمنی فضای ذخیره‌سازی شما را در دست دارد و دستگاه خاموش است، او چه چیزی به دست می‌آورد؟ هر سؤال دیگری که ممکن است داشته باشید — میزبان چه چیزی می‌تواند ببیند، اگر یک سرور در حال اجرا توقیف شود چه پیش می‌آید، آیا بکاپ‌های شما امن هستند — پاسخی متفاوت دارد، و رفتار با همه‌ی آن‌ها به‌عنوان یک سؤال واحد دقیقاً همان چیزی است که باعث می‌شود مردم به رمزگذاری‌ای برسند که هیچ‌چیز را محافظت نمی‌کند.

ارزش دارد در این تفکیک صریح باشیم، چون عبارت «رمزگذاری‌شده با LUKS» در تمام صفحات میزبانی حریم‌خصوصی این صنعت دیده می‌شود، از جمله صفحات خودمان. این یک کنترل واقعی است، اجرای آن تقریباً هیچ هزینه‌ای ندارد، و در عین حال پرادعاترین کنترل در حوزه‌ی میزبانی نیز هست. این راهنما موارد زیر را پوشش می‌دهد: رمزگذاری در حالت سکون واقعاً چه چیزی را روی یک سرور اجاره‌ای متوقف می‌کند، سه آرایش ارزشمند برای استقرار و دستورهای هر یک، دو تنظیم که واقعاً روی یک VPS کوچک اهمیت دارند، و مشتی اشتباه که کل این کار را به تزئین تبدیل می‌کند.

رمزگذاری در حالت سکون واقعاً از چه چیزی محافظت می‌کند

رمزگذاری در حالت سکون یعنی بایت‌های روی رسانه‌ی ذخیره‌سازی، هر زمان که حجم بسته باشد، متن رمزشده هستند. این یک ادعای محدود است، و ارزش آن به یک متغیر واحد بستگی دارد: کلید در لحظه‌ی ورود دشمن کجاست.

این را به‌عنوان یک تعریف بخوانید، نه یک ناامیدی. حذف دسته‌ی مواجهه‌ی «دیسک بیرون‌کشیده‌شده» به‌خاطر یک ساعت کار ارزشش را دارد، دقیقاً چون این همان دسته‌ای است که هیچ دفاع دیگری در برابرش ندارید، و همان چیزی است که بدون هدف‌گیری هیچ‌کس رخ می‌دهد: سخت‌افزار خراب می‌شود و بازگردانده می‌شود، آرایه‌ها بازنشسته می‌شوند، حجم‌ها به مستأجر بعدی واگذار می‌شوند. رمزگذاری همه‌ی این‌ها را به یک رویداد بی‌اهمیت تبدیل می‌کند.

چرا یک VPS مثل لپ‌تاپ نیست

روی لپ‌تاپ، طراحی بدیهی است. شما هنگام بوت یک عبارت عبور تایپ می‌کنید، کلید فقط تا زمانی که دستگاه بیدار است در RAM وجود دارد، و خاموش‌کردنش به داستان پایان می‌دهد. سرور کسی پشت کنسول ندارد. چیزی باید در هر بوت کلید را تأمین کند، و هر گزینه برای این «چیز» دسترس‌پذیری را در برابر محافظت معامله می‌کند:

• یک انسان آن را تایپ می‌کند. قوی‌ترین آرایش، چون کلید هرگز روی دستگاه باقی نمی‌ماند — اما سرور بدون شما نمی‌تواند از یک ریبوت بازگردد، و پیش از وجود سیستم‌عامل به راهی برای ورود نیاز دارید.
• دستگاه آن را نگه می‌دارد. راحت است، و در بیشتر پیکربندی‌های خانگی، خودشکن: یک فایل کلید روی همان دیسک مجازی یعنی هرکه دیسک را در دست دارد، کلید را هم در دست دارد.
• دستگاه دیگری آن را تحویل می‌دهد. بازکردن قفل وابسته به شبکه، معمولاً Clevis همراه با یک سرور Tang. سرور فقط تا زمانی خودش را باز می‌کند که هنوز بتواند به میزبانی که کنترل می‌کنید دسترسی داشته باشد، که یک ویژگی واقعاً مفید است — و جابه‌جایی اعتماد است، نه حذف آن.

یک تفاوت دوم وجود دارد که بیشتر راهنماها از آن می‌گذرند. روی یک VPS، /boot و initramfs به‌صورت متن ساده هستند، روی رسانه‌ای زندگی می‌کنند که در نهایت ارائه‌دهنده کنترلش می‌کند، و هیچ زنجیره‌ی بوتی وجود ندارد که بتوانید تأیید کنید — نه TPM ای که متعلق به شما باشد، نه measured boot، هیچ‌چیزی برای گواهی‌دادن. میزبانی که عبارت عبور شما را می‌خواست می‌توانست initramfs را تغییر دهد و آن را در دفعه‌ی بعدی که قفل را باز می‌کنید جمع‌آوری کند. این توصیف کاری نیست که ما انجام می‌دهیم؛ توصیف چیزی است که معماری اجازه می‌دهد، که تنها راه صادقانه برای استدلال درباره‌ی کامپیوتری است که اجاره می‌کنید. مقایسه‌ی VPS در برابر اختصاصی ما همین مرز اعتماد را از سمت سخت‌افزار طی می‌کند، و پاسخ صادقانه‌ی ما درباره‌ی ناشناسی آفشور همان انضباط را در بازاریابی اطراف آن به‌کار می‌برد.

سه آرایشی که ارزش استقرار دارند

یک راه‌اندازی درست و واحد وجود ندارد — آن یکی وجود دارد که بتوانید با حالت شکستش زندگی کنید. این سه مورد اساساً هر حالت واقعی را پوشش می‌دهند.

مگر دلیل خاصی داشته باشید، از اولی شروع کنید. این گزینه بیشتر محافظت را با کسری از ریسک عملیاتی ارائه می‌دهد، و ویژگی‌ای دارد که آن دو مورد دیگر ندارند: هیچ‌چیز درباره‌ی آن نمی‌تواند مانع بازگشت سرور به آنلاین‌شدن شود. آرایش سوم تنها موردی است که در آن عبارت عبور واقعیتی است که میزبان نمی‌تواند به آن دسترسی پیدا کند، نه وعده‌ای که میزبان می‌دهد؛ به همین دلیل است که سرورهای اختصاصی ما LUKS را در زمان نصب با عبارت عبوری که هرگز نمی‌بینیم اعمال می‌کنند.

رمزگذاری یک حجم داده روی یک VPS در حال اجرا

این آرایشی است که باید اول سراغش بروید. هیچ‌چیز از نو نصب نمی‌شود، هیچ‌چیز در فرایند بوت تغییر نمی‌کند، و اگر اشتباهی مرتکب شوید بدترین نتیجه یک فایل کانتینر است که دورش می‌اندازید. پانزده دقیقه روی یک سرور زنده‌ی Debian یا Ubuntu.

• ابزار را نصب کنید. 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.
• داده‌ای که اهمیت دارد را جابه‌جا کنید، سپس سرویس‌ها را به آن اشاره دهید. یک bind mount، یا یک rsync با سرویس متوقف‌شده، معمولاً از symlink تمیزتر است — پایگاه‌های‌داده به‌ویژه دوست ندارند دنبال‌شان بگردند.
• از هدر LUKS بکاپ بگیرید. cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin، سپس آن فایل را از سرور خارج کنید. چند کیلوبایت خراب در ابتدای کانتینر، هر بایت پشت سرش را برای همیشه نابود می‌کند، و این تنها بیمه‌ای است که وجود دارد.
• آن را ببندید و ثابت کنید می‌توانید دوباره وارد شوید. umount /srv/vault && cryptsetup close vault، سپس آن را دوباره از روی یادداشت‌هایتان باز کنید، نه از حافظه. این کار را پیش از آن‌که چیز باارزشی داخلش باشد انجام دهید.

پس از یک ریبوت، گاوصندوق تا زمانی که وارد شوید و بازش کنید بسته می‌ماند. این محدودیتی نیست که باید دورش مهندسی کرد — کل هدف همین است. حجمی که خودش را باز می‌کند، حجمی است که کلیدش روی همان دستگاه است.

رمزگذاری کامل روت با بازکردن قفل از راه دور روی SSH

وقتی نیازمندی این است که هیچ‌چیز خواندنی از یک توقیف در حالت خاموش جان سالم به‌در نبرد — لاگ‌ها، تاریخچه‌ی شل، فهرست بسته‌ها، شکل چیزی که اجرا می‌کنید — فایل‌سیستم روت هم باید داخل کانتینر باشد. مسئله در این حالت به رساندن یک عبارت عبور به دستگاهی تبدیل می‌شود که هنوز بوت نشده، و پاسخ یک سرور SSH کوچک است که داخل initramfs زندگی می‌کند.

• از همان ابتدا رمزشده نصب کنید. نصب‌کننده‌ی توزیع را از طریق آپلود 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" را تنظیم کنید: بدون ورود با رمز عبور، بدون port forwarding، پورت مخصوص به خود، و یک idle timeout تا یک نشست گیرکرده نتواند بوت را باز نگه دارد.
• به 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 را اجرا کنید. کلاینت شما درباره‌ی یک host key ناشناخته هشدار می‌دهد: initramfs کلید خودش را دارد، که انتظار می‌رود و ارزش pin‌کردن در یک رکورد جداگانه‌ی known_hosts را دارد.
• پیش از تکیه‌کردن به آن، مسیر شکست را تست کنید. یک به‌روزرسانی کرنل نصب کنید، ریبوت کنید، دوباره باز کنید. ارتقای کرنل initramfs را از نو می‌سازد، و دقیقاً همان لحظه‌ای است که یک پیکربندی نادرست خودش را نشان می‌دهد.

دو تنظیمی که اهمیت دارند، و تله‌ی VPS کوچک

LUKS2 به‌طور پیش‌فرض از AES-XTS با کلید 512-بیتی و اشتقاق کلید Argon2id استفاده می‌کند. هر دو درست هستند. دستکاری دستی سایفر راهی است برای هم‌زمان کندتر و ضعیف‌تر شدن، و اینترنت پر است از خط‌فرمان‌های کپی‌شده که دقیقاً همین کار را می‌کنند. با این حال، دو چیز شایسته‌ی توجه شما هستند.

عملکرد یک غیرمسئله است، تا وقتی که نیست

شتاب‌دهی سخت‌افزاری را با grep -m1 -o aes /proc/cpuinfo بررسی کنید و با cryptsetup benchmark اندازه بگیرید. روی هر CPU با AES-NI — که همه‌ی نودهایی است که ما اجرا می‌کنیم — AES-XTS چندین گیگابایت در ثانیه به‌ازای هر هسته جابه‌جا می‌کند، به‌راحتی بالاتر از چیزی که یک دیسک مجازی واحد ارائه می‌دهد، پس هزینه‌ی محسوس چند درصد CPU زیر I/O سنگین و یک افزایش کوچک در تأخیر است. بدون AES-NI تصویر برعکس می‌شود و رمزگذاری به تنگنا تبدیل می‌شود؛ این تنها موردی است که یک سایفر جایگزین یک تصمیم واقعی است، نه تقلید کورکورانه.

حافظه‌ی Argon2id همان چیزی است که گاز می‌گیرد

Argon2id عمداً حافظه‌خوار است، و cryptsetup آن را در زمان فرمت در برابر RAM دستگاهی که رویش فرمت می‌کنید کالیبره می‌کند. یک حجم را روی یک ایستگاه‌کاری 32 گیگابایتی فرمت کنید، آن را به یک VPS 1 گیگابایتی منتقل کنید، و بازکردن قفل می‌تواند کاملاً شکست بخورد چون حافظه‌ای که اشتقاق کلید طلب می‌کند وجود ندارد — حتی بدتر داخل یک initramfs، جایی که بسیار کمتر از یک سیستم در حال اجرا در دسترس است. روی نمونه‌های کوچک، آن را ثابت کنید: cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb آن را در 256 مگابایت سقف می‌زند. پایین‌تر یک کاهش واقعی در مقاومت در برابر brute force آفلاین است، پس آن را با یک عبارت عبور بلندتر جبران کنید.

یک فلگ اختیاری شایسته‌ی یک تصمیم آگاهانه است، نه کپی-پیست: --allow-discards عبارت TRIM را به دستگاه زیرین عبور می‌دهد، که برای فرسایش SSD و عملکرد پایدار خوب است، و همچنین آشکار می‌کند چقدر از حجم در حال استفاده است و تقریباً کجا. این به‌صورت پیش‌فرض خاموش است. آن را با دانستن این‌که چه چیزی نشت می‌کند، روشن کنید.

Swap، لاگ‌ها، اسنپ‌شات‌ها — بخش‌هایی که مردم فراموش می‌کنند

یک گاوصندوق رمزشده که متن ساده دورش نشت می‌کند، رایج‌ترین شکست از همه است، و تا وقتی کسی نگاه نکند نامرئی می‌ماند.

• Swap. هرچیزی که در حافظه است می‌تواند به دیسک page شود، از جمله موادی که با دقت داخل گاوصندوق گذاشته‌اید. یا swap را غیرفعال کنید، یا در هر بوت یک کلید تصادفی به آن بدهید با یک خط /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ِ متن ساده بنشیند، اصلاً از هیچ‌چیز محافظت نمی‌کند — رایج‌ترین اشتباه در رمزگذاری خودمیزبانی‌شده.
• روی دستگاهی که کنترل می‌کنید، از طریق شبکه واکشی‌شده. Clevis متصل به یک سرور Tang: clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'. سرور بدون نظارت بوت می‌شود تا زمانی که بتواند به خانه دسترسی داشته باشد و در هرجای دیگری از بازکردن قفل امتناع می‌کند. برای ناوگان‌های headless عالی است، و میزبان Tang را چیزی می‌کند که باید از آن دفاع شود.
• در یک TPM. روی سخت‌افزاری که مالکش هستید، معنادار است. روی یک VPS، TPM مجازی توسط همان هایپروایزری ارائه می‌شود که سعی می‌کنید کنارش بگذارید، پس این راحتی را حل می‌کند نه اعتماد را.

یک آزمون بیشتر طراحی‌ها را حل می‌کند: اگر دستگاه بتواند بدون شما به یک پرامپت ورود برسد، کلید روی دستگاه است. این می‌تواند یک معامله‌ی کاملاً معقول باشد — بارکارهای زیادی ریبوت بدون نظارت را بیشتر از مقاومت در برابر یک دشمن مصمم می‌خواهند. این انتخاب را آگاهانه انجام دهید، و نتیجه را چیزی توصیف نکنید که نیست.

میزبان شما چه چیزی را می‌بیند، و کجا حوزه‌ی قضایی وارد عمل می‌شود

روی یک VPS، یک هایپروایزر زیر شما نشسته است. ما حافظه‌ی مهمان را نمی‌خوانیم، و هیچ لاگ ترافیک، اتصال یا DNS و هیچ ردی از کنسول نگه نمی‌داریم — اما این‌ها سیاست‌اند، و چارچوب صادقانه این است که VPS از شما می‌خواهد به آن‌ها تکیه کنید. روی بیر متال هیچ هایپروایزری بین شما و سیلیکون نیست: رمزگذاری کامل دیسک که در زمان نصب با عبارت عبوری که هرگز دریافت نمی‌کنیم برپا می‌شود، یک ویژگی فیزیکی دستگاه است، نه اطمینانی از سوی ما. آن تفاوت است — نه انتخاب سایفر — که واقعاً بین آن‌ها انتخاب می‌کنید.

به همین دلیل رمزگذاری و حوزه‌ی قضایی دو نیمه‌ی یک پاسخ هستند. رمزگذاری تعیین می‌کند یک کپی از دیسک شما چه ارزشی دارد؛ حوزه‌ی قضایی تعیین می‌کند چه کسی می‌تواند دستگاه را وادار به ارائه کند، از طریق چه فرایندی و چقدر سریع. ما در هفت حوزه فعالیت می‌کنیم — ایسلند، سوئیس، پاناما، رومانی، مولداوی، هلند و روسیه — و استدلال انتخاب بین آن‌ها در راهنمای حوزه‌ی قضایی ما آمده، یا به‌شکل کوتاه‌تر از طریق انتخاب‌گر حوزه‌ی قضایی و صفحه‌ی موقعیت‌ها.

بخشی که رمزگذاری نمی‌تواند به آن دست بزند، افشای اجباری است، چون هدفش شما هستید، نه سخت‌افزار. بریتانیا، فرانسه و استرالیا از جمله کشورهایی هستند که قانونشان می‌تواند از یک فرد بخواهد کلید رمزگشایی را ارائه کند یا با مجازات امتناع روبه‌رو شود. آن مواجهه از محل حضور شما پیروی می‌کند، نه از محل سرور، و هیچ پیکربندی‌ای روی دستگاه آن را تغییر نمی‌دهد. ثبت‌نام بدون مدارک هویتی از همان ابتدا محدود می‌کند چقدر رد کاغذی وجود دارد — دلیل عملی و بدون تجمل این‌که میزبانی بدون KYC و رمزگذاری در یک گفت‌وگو به هم می‌رسند — اما این دفاعی در برابر دادگاهی که از قبل نام شما را دارد نیست.

نه اشتباهی که رمزگذاری را به تزئین تبدیل می‌کنند

• بازکردن خودکار قفل از یک فایل کلید روی همان دیسک. اکثریت سرورهای «رمزشده»، و معادل جاگذاشتن کلید در قفل.
• رمزگذاری حجمی که داده‌ی حساس هرگز به آن نمی‌رسد. گاوصندوق خالی است و پایگاه‌داده داخلش نیست.
• هرگز از هدر LUKS بکاپ نگرفتن. یک سکتور آسیب‌دیده در جلوی کانتینر و هر بایت پشت سرش برای همیشه از دست رفته.
• هرگز مسیر بازکردن قفل را تست نکردن. سپس یک ارتقای کرنل initramfs را از نو می‌سازد و ریبوت بعدی به یک عملیات نجات تبدیل می‌شود.
• فرمت‌کردن روی یک دستگاه بزرگ و بازکردن قفل روی یک دستگاه کوچک. Argon2id حافظه‌ای می‌خواهد که VPS نمی‌تواند فراهم کند، و حجم باز نخواهد شد.
• انتخاب یک عبارت عبور مثل یک رمز عبور ورود. هیچ‌چیز جز تابع اشتقاق کلید سرعت یک حمله‌ی آفلاین را محدود نمی‌کند. طول همان چیزی است که زمان می‌خرد.
• مهاجرت متن ساده به رمزگذاری و فرض این‌که نسخه‌ی اصلی از بین رفته. روی رسانه‌ی مجازی‌سازی‌شده، رونویسی به‌طور قابل‌اعتماد پاک نمی‌کند.
• فرستادن عبارت عبور از همان کانالی که برای مدیریت دستگاه استفاده می‌کنید. OpSec سرور مسئله‌ی همبستگی‌ای که این ایجاد می‌کند را پوشش می‌دهد.
• اشتباه‌گرفتن رمزگذاری ارائه‌دهنده با رمزگذاری خودتان. «تمام زیرساخت در حالت سکون رمزشده است» — شامل زیرساخت ما هم می‌شود — از زیرساخت محافظت می‌کند. فقط کلیدی که خودتان نگه می‌دارید، شما را در برابر زیرساخت محافظت می‌کند.

پس آیا انجامش روی یک VPS ارزشش را دارد؟

بله، با انتظارات کالیبره‌شده. برای یک ساعت کار و بدون هزینه‌ی اجرایی قابل‌اندازه‌گیری، یک حجم داده‌ی رمزشده کل یک دسته از مواجهه را که به‌شکل دیگری نمی‌توانید حلش کنید، حذف می‌کند، و برای همیشه حذفش می‌کند: سخت‌افزار بازنشسته، رسانه‌ی ذخیره‌سازی واگذارشده، دستگاهی خاموش در حضانت شخص دیگر. این کار را روی هر سروری که چیزی اهمیت‌دار روی آن است انجام دهید، درست بعد از چک‌لیست سخت‌سازی ساعت اول.

کاری که این کار نمی‌کند این است که یک کامپیوتر اجاره‌ای را به کامپیوتر خودتان تبدیل کند. اگر مدل تهدید شما خودِ میزبان را به‌عنوان دشمن در نظر دارد، هیچ سایفری این را حل نمی‌کند — پاسخ سخت‌افزار اختصاصی است، جایی که کلید از طریق IPMI تایپ می‌شود و هرگز از یک هایپروایزر عبور نمی‌کند، حوزه‌ی قضایی‌ای که عمداً انتخاب شده، و انضباط این‌که روی هیچ سروری چیزی نگذارید که نیازی به بودنش آنجا نیست. تطبیق کنترل با تهدید واقعی، تفاوت بین حریم‌خصوصی و ظاهر آن است.