Управление шифрованием ленты и лучшие практики

16

Я хочу включить шифрование на всех моих лентах резервных копий. Я более или менее знаю, как сделать это технически, но процедурные и человеческие элементы реализации этого сложны.

Я использую диски HP LTO4 с bacula, который не имеет каких-либо функций управления ключами. Фактически, его поддержка аппаратного шифрования заключается в вызове внешнего сценария, который устанавливает ключ на диске перед чтением и записью.

Мои вопросы:

  1. Как я должен отслеживать, какие ленты имеют шифрование? У меня уже есть несколько сотен лент без шифрования. Даже если я найду время, чтобы переписать их все с помощью шифрования, будут месяцы совпадения, когда у некоторых это будет, а у некоторых - нет. Как bacula узнает, нужно ли устанавливать ключ перед чтением данной ленты? Достаточно ли умен накопитель для чтения незашифрованных лент, даже если ключ установлен?
  2. Если ключ когда-либо будет взломан, нам придется его изменить, и у нас будет та же проблема, что и у # 1.
  3. Если ключ потерян, мы фактически потеряли все наши резервные копии. Как я могу смягчить это, не увеличивая риск его компрометации?
  4. Должен ли ключ регулярно меняться? Раз в год? Какова лучшая практика?
  5. Как большие системы резервного копирования ISV справляются с этими проблемами?
lukecyca
источник
Это отличные вопросы, на которые я тоже хотел бы знать ответ.
Мэтт Симмонс
2
Да ладно, завсегдатаи Serverfault ... Должны быть лучшие ответы? Это хороший вопрос ...
Jesper M

Ответы:

7

Очень хорошие вопросы Я тоже хотел бы получить хорошие ответы от людей, которые знают об этом больше, чем я. :-)

3 Если ключ потерян, мы фактически потеряли все наши резервные копии

Именно поэтому многие или большинство людей не используют зашифрованные резервные копии.

Один из возможных способов - это создать пару «спасательных шлюпок», то есть пакетов с установочными носителями, именами пользователей и паролями для таких важных систем, как резервные копии, Active Directory и других (то есть того, что нужно для загрузки резервной копии, если основной сайт был полностью уничтожены при пожаре, но не сами данные резервного копирования). Вы должны хранить эти спасательные шлюпки в безопасном месте, например, в банковском хранилище или в сейфе с высоким уровнем безопасности в удаленном офисе с системой сигнализации. И, наконец, задокументируйте это, чтобы другие могли выяснить, как использовать спасательные шлюпки после того, как вы покинули компанию, если это необходимо.

4 Должен ли ключ регулярно меняться? Раз в год? Какова лучшая практика?

С практической точки зрения я бы сказал, чтобы не менять ключи, так как это быстро становится неуправляемым, если вы делаете. Если вы беспокоитесь о недостаточной безопасности резервного копирования, то укрепите физическую безопасность ваших лент, воспользовавшись такой службой , как Iron Mountain , или самостоятельно создав систему хранения с хорошей физической безопасностью.

И наконец: я бы предпочел, чтобы все шифрование и обработка резервных копий выполнялись в одной системе, чтобы снизить риск неэффективного восстановления. Под этим я подразумеваю использование встроенного шифрования в программном обеспечении, таком как Retrospect или Backup Exec, а не шифрование на уровне диска.

Джеспер М
источник
2

Я использую dm-crypt FS, шифруя его длинным и сильным паролем.

Чтобы не потерять парольную фразу, я написал это на запечатанном воском письме, отдал его в собственность компании, а он хранил в сейфе безопасности.

Конечно, вы можете дать это нотариусу, или как вы думаете.

Я думаю, что парольная фраза лучше для этой работы, так как она может быть только в уме людей, уполномоченных на это знать, в то время как цифровое устройство может быть потеряно, украдено и так далее.

Вас могут замучить, конечно :)

drAlberT
источник
Вы можете использовать Secret Sharing и разделить ключ на несколько, по отдельности бесполезных частей, распределенных между одинаково (не) заслуживающими доверия хранителями ...
Тобиас Кинцлер
2

Я отвечаю на это, и я делаю это вики-сообществом, так как я копирую и вставляю из существующего документа.

Для справки, я использую Amanda Enterprise в качестве решения для резервного копирования и не использую шифрование на магнитной ленте, которое оно обеспечивает, по тем причинам, которые вы упомянули.

Я исследовал ленточное шифрование и натолкнулся на замечательный технический документ от HP, в котором говорилось о шифровании LTO-4 , и в нем было много возможностей для управления ключами. Вот краткое изложение доступных опций:

• Шифрование в собственном режиме (иногда его называют «установить и забыть»). Этот метод управляет шифрованием LTO4 из библиотеки ленточных накопителей. Существует один ключ, который задается с помощью интерфейса управления библиотекой (Web GUO или панель управления оператора). Этот метод шифрует все ленты одним и тем же ключом, что отрицательно сказывается на уровне безопасности.

• Программное шифрование шифрует данные перед тем, как они покидают сервер, а ключи сохраняются во внутренней базе данных или каталоге приложения. Этот метод шифрования создает высокую нагрузку на сервер, поскольку программное обеспечение выполняет множество математических операций с использованием вычислительной мощности хоста. Несколько приложений, включая HP Open View Storage Data Protector 6.0, предлагают шифрование как функцию. Хотя безопасность данных, зашифрованных таким образом, очень высока (поскольку данные шифруются при передаче), поскольку зашифрованные данные являются очень случайными, становится невозможным сжатие данных в нисходящем направлении на ленточном накопителе, и поэтому хранение неэффективно.

• Ключи, управляемые приложением ISV, также известные как внутриполосное управление ключами. Программное обеспечение ISV предоставляет ключи и управляет ими, а ленточный накопитель Ultrium LTO4 выполняет шифрование. На ключи будут ссылаться связанные с ключом данные, и они будут храниться во внутренней базе данных приложений. (Обратитесь к вашему поставщику приложений резервного копирования для поддержки этой функции).

• Устройство внутриполосного шифрования перехватывает каналы Fibre Channel и шифрует данные в полете. Эти продукты доступны от нескольких поставщиков, таких как Neoscale и Decru. Управление ключами осуществляется из усиленного устройства управления ключами. Этот метод не зависит от программного обеспечения ISV и поддерживает устаревшие ленточные накопители и библиотеки. Сжатие данных должно выполняться этими устройствами, так как сжатие на ленточном накопителе невозможно после шифрования.

• Коммутатор SAN Fabric с возможностью шифрования аналогичен встроенному устройству, но в него встроено аппаратное шифрование.

• Key Management Appliance работает с библиотеками классов предприятия, такими как библиотеки HP StorageWorks EML и ESL серии E. Он известен как внешнее управление ключами, так как ключ подается на накопитель на магнитной ленте устройством управления ключами. На рисунке 8 показаны основные компоненты устройства управления ключами. Приложения резервного копирования не знают о возможности шифрования ленточного накопителя. Ключи передаются в контроллер ленточной библиотеки через сетевое соединение с использованием протокола SSL, недавно переименованного в Transport Layer Security (TLS). Это зашифрованное соединение, необходимое для защиты ключей при передаче от устройства. Для настройки безопасности в аппарат управления библиотекой устанавливается цифровой сертификат. Это устанавливает необходимое безопасное соединение. Настройка SSL / TLS использует шифрование с открытым ключом, но затем, после того, как рукопожатие завершено, секретный ключ проходит для шифрования ссылки. Когда ленты восстанавливаются, данные, связанные с ключом (полученные с ленты), используются для ссылки на запрос правильного ключа для дешифрования ленты независимо от приложения резервного копирования.

Что мы действительно упускаем, так это то, что люди в реальном мире делают. Белые книги хороши, но это не обязательно отражает реальность.

Кроме того, я разместил этот вопрос в своем блоге , поэтому некоторые ответы или примеры также могут отображаться там.

Мэтт Симмонс
источник
+1. Из документа «Там, где на дисках включено шифрование, обмен зашифрованными данными возможен… независимо от производителя». Так что шифрование LTO4 - это открытый стандарт, это хорошо. (В документе также говорится, что не все диски LTO4 поддерживают шифрование, и что шифрование не было частью LTO3 и более ранних стандартов.)
Jesper M