Извините, я некромант... Но у меня есть несколько дополнительных вопросов именно по этой теме. При обеспечении безопасности системы сначала оцениваются модели угроз. Для школы, где я это настраиваю, физический доступ, пока система работает, не является проблемой. Проблемой является кража физических серверов не техническими людьми (взлом, кража всего, ссуда). Таким образом, риск возникает только от холодной загрузки со стороны третьей стороны. Я бы классифицировал наш риск как "от холодной загрузки". Как можно смягчить эту атаку, предотвращая извлечение ключа шифрования из базы данных OSD Monitors? Например, если они просто подключат всё и загрузят систему. Хватит ли зашифровать только загрузочные диски ОС? А что, если переместить разделы Ceph OSD WAL/DB на выделенные корпоративные SSD? Это то, для чего используется RocksDB? Похоже, что это легкое восстановление из блока .db SSD в формат RocksDB и чтение в открытом виде? --- С другой стороны... Моя компания требует запрос на проверку безопасности для наших команд по информационной безопасности. Им абсолютно необходимо владеть этими ключами шифрования, скорее всего, производными от корневого ключа (если LUKS такое поддерживает, то AWS KMS да). В случае, если они не владеют корневым сертификатом или корневым ключом, требуется документальное подтверждение того, где точно хранятся ключи, что потребует, как вы уже догадались, хранить их на зашифрованном (данные в покое) объёме. Кроме того, они потребуют ротировать ключи по циклу 30 дней/1 год. Это то, что многие организации называют инфраструктурой безопасной уровня Бронза, что является минимальными требованиями. Аудиты безопасности также требуют точно такой же информации. Правительство США требует уровень Золото для наших партнерств. Суть, которую я пытаюсь донести, в том, что нам нужно гораздо больше четко прописать, где и в каком формате это хранится, как извлекать и/или заменять ключи и т.д. Я попытался покопаться в коде, но не смог быстро найти ссылку. Поскольку это LUKS, ротация будет простой задачей — сгенерировать новый ключ и удалить старый. Однако потребуется схема RocksDB и то, как она хранится. В конечном итоге всё сводится к следующему: RocksDB, хранящаяся на незашифрованном разделе, будет бессмысленной, если в ней содержатся частные ключи LUKS для разблокировки объемов/пулов Ceph. RocksDB также нужно хранить в зашифрованном формате с данными в покое.
