Шифрование / Безопасность в WebApp

Question

У нас есть веб-приложение, написанное на Java, которое хранит данные в базе данных PostgreSQL.

Мы хотели бы зашифровать несколько полей в нашей базе данных, а также некоторые загруженные документы. Однако все это должно быть двухсторонним шифрованием (т. Е. Мы должны иметь возможность расшифровать их), а дешифрование должно быть достаточно быстрым.

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

Любые другие идеи о том, как сделать это хотя бы умеренно ... безопасным?

Answer 1

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

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

Answer 2

Вы можете сделать это немного более безопасным.

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

Важным принципом здесь является то, что закрытый ключ может использоваться приложением, но не читаемым приложением. Так что, глядя на исходный код приложения, вы ничего не получите.

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

В случае правильной реализации это надежно защитит вас от всех форм автономной атаки. Хакер не может физически взломать хороший аппаратный токен. Ключ не может быть извлечен без знания пароля. Пароль не может быть угадан, потому что токен имеет аппаратные ограничения для атак методом перебора. Таким образом, единственный способ восстановить данные - это украсть токен и пароль или перебор ключа шифрования данных (это может быть 2048-битный сертификат RSA).

Answer 3

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

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

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

Итак, пользовательский сеанс знает пароль шифрования, который затем используется для шифрования и дешифрования. Когда администратор создает новых пользователей, он имеет доступ к незашифрованному паролю во время этого - когда он вводит новый пароль для нового пользователя, есть еще одна копия зашифрованного пароля, созданная и сохраненная в БД, зашифрованная этим паролем пользователя и т. Д.

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

Answer 4

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

Теперь вы совершенно правы, что ключ необходимо хранить таким образом, чтобы ваше приложение могло получить к нему доступ. Однако вместо того, чтобы хранить ключ в своем коде или в файле, вы можете «разделить секрет» на разные физические места, чтобы инсайдеру было труднее справиться с шифрованием. Например:

1. Во время разработки создайте новый ключ и "жесткий код" его в ваш программа. Назовите этот ключ A.

2. Во время установки создайте второй ключ. Назовите этот ключ B. Теперь зашифровать ключ B ключом A и сохранить зашифрованная версия этого в файловая система. Сделайте файл читаемым только пользователю, под которым сервер работает.

3. Для каждого значения, которое вы шифруете (скажем, каждый номер кредитной карты), генерировать третий ключ. Назовите этот ключ C. Используйте ключ С, чтобы зашифровать значение. Затем зашифровать Ключ C с ключом B и сохранить зашифрованная версия этого внутри база данных. (Вы можете использовать отдельный поле в той же таблице.)

Для расшифровки вы должны прочитать зашифрованный ключ C из базы данных и зашифрованный ключ B из файловой системы. Используйте ключ A, чтобы расшифровать ключ B, и ключ B, чтобы расшифровать ключ C. Затем используйте ключ C, чтобы расшифровать значение.

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