Шифрование данных в кластере приложений - PullRequest
3 голосов
/ 01 августа 2011

У меня есть веб-приложение, доступ к которому осуществляется через SSL. Чтобы повысить безопасность на стороне сервера, мы рассмотрим добавление симметричного шифрования для базы данных.

Приложение распространяется на 6 серверов в кластере websphere.

Мы рассматривали простую модель генерации общего ключа, распространяя ключ по всем клонам в изолированном хранилище ключей JCEKS.

Устанавливается на AES (256) для шифра и длины ключа.

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

Это просто вопрос резервного копирования ключа и хранилища ключей, чтобы мы всегда имели где-нибудь копию в случае аварии?

AES все еще является надежным шифром? и симметричное шифрование обычно быстрее, чем асимметричное. Есть ли какие-либо существенные последствия для производительности при использовании 256-битного ключа или это больше влияет на размер зашифрованных данных?

1 Ответ

3 голосов
/ 01 августа 2011

AES

AES по-прежнему является официальным стандартом Avanced Encryption Standard, так что это все еще очень хороший выбор для симметричного шифра. Нарушение скорости для ключей более длинного размера незначительно по сравнению с улучшенной защитой.

Общий подход

Прежде всего, сам подход кажется обоснованным. Но вы должны иметь в виду недостатки, которые вносит зашифрованные данные в базу данных: нет более эффективной индексации, нет оптимизации запросов, вообще нет выборочных запросов ... Если вы собираетесь шифровать большие части базы данных или даже всю базу данных, вам следует лучше изучить функциональность шифрования, предлагаемую самой базой данных. Если вы используете этот подход, вам следует дополнительно защитить соединения с вашей базой данных с помощью SSL / TLS, что легко упустить из виду. Это сохраняет все преимущества «нормальной» базы данных и обеспечивает дополнительную безопасность, которую вы ищете.

Вы правы насчет потери ключей: у вас большие проблемы :) Но не все потеряно, вы все равно можете взломать пароль файла хранилища ключей JCEKS ...

Что приводит нас к этому ресурсу. Это действительно проблема курицы и яйца с хранилищами ключей и паролями. Единственное действительно чистое решение - вводить пароли вручную при каждом запуске приложения / базы данных. Но это, как правило, реальная проблема (подумайте о сбое посреди ночи), поэтому люди склонны хранить пароли в текстовом файле в файловой системе. Это приемлемо, если вы следуете некоторым рекомендациям:

  • в идеале этот файл должен быть на другом компьютере с ограниченным доступом
  • если он должен быть на том же компьютере, ограничьте права доступа к этой папке - но не забудьте разрешить приложению доступ к нему
  • Повторное шифрование этого файла, как правило, бесполезно, снова проблема курицы и яйца. Несмотря на то, что BASE64-кодирование содержимого может быть полезно иметь первую защиту от технически менее опытных
  • Мало кто должен знать пароль (его нельзя сказать достаточно часто)
  • Вы должны хранить резервную копию пароля в сейфе.
  • Избегайте распространения файла хранилища ключей любой ценой

Если вы действительно хотите быть строгим (скажем, один или два человека должны знать пароль), то вы можете дополнительно установить схему Secret Sharing , но это может быть излишним в зависимости от ваших требований. Такая схема позволила бы лицам с (само по себе бесполезной) частью секрета объединять части, чтобы восстановить действительный секрет. Таким образом, вы можете уменьшить риск потери, распространив детали на большую группу.

...