Рекомендации по шифрованию базы данных Firebase Realtime с использованием Google Cloud KMS - PullRequest
0 голосов
/ 01 ноября 2018

Мы используем правила базы данных Firebase для защиты нашей базы данных. Мы также хотели бы добавить дополнительную безопасность путем шифрования конфиденциальной информации пользователя. Прямо сейчас наш подход шифрования:

Шифрование клиентской части пользовательских данных с помощью открытого ключа перед тем, как пользователь записывает его в базу данных. Расшифровка с помощью закрытого ключа на сервере перед доставкой данных пользователю с помощью запроса GET

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

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

Однако мы не были уверены, что может быть лучший подход с использованием Cloud KMS. Можно ли использовать KMS для шифрования на стороне клиента и на стороне сервера? Или как лучше использовать KMS для улучшения шифрования базы данных?

Ответы [ 3 ]

0 голосов
/ 01 ноября 2018

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

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

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

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

Спасибо за ваш вопрос и за использование Cloud KMS; Пожалуйста, дайте нам знать, если у вас есть дополнительные вопросы, с которыми мы можем помочь!

0 голосов
/ 06 ноября 2018

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

0 голосов
/ 01 ноября 2018

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

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

Пример. Зачем шифровать данные на стороне пользователя, если вы собираетесь расшифровать их на сервере перед отправкой клиенту?

Жесткое кодирование закрытого ключа в коде сервера - ужасная практика. Это почти гарантирует, что ваша ключевая пара будет утечка.

Да, использование Cloud KMS станет для вас огромным улучшением. Это облегчит внедрение системы безопасности и устранит некоторые проблемы с управлением шифрованием. Тем не менее, вам необходимо понять KMS и лучшие методы шифрования. Плохо спроектированная безопасность очень легко взломать. Плохо спроектированная система безопасности очень легко потерять из-за невозможности передать данные.

Проще говоря, вам понадобится как минимум следующее:

  1. Управление ключами шифрования
  2. Поворот ключа
  3. Шифрование в покое
  4. Шифрование в пути
  5. Разделение обязанностей (администраторы не могут расшифровать данные)

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

Я мог бы продолжать и продолжать, и поэтому на эту тему написаны большие книги.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...