Как безопасно хранить ключи API моих клиентов? - PullRequest
0 голосов
/ 25 августа 2018

Я занимаюсь разработкой службы SAAS, которая позволяет моим клиентам подключать сторонние инструменты электронной почты (например, MailChimp). Поэтому я прошу ввести их ключ API, связанный с желаемой службой, чтобы разрешить автоматическое выполнение определенных действий с их учетной записью.

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

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

Я думал о нескольких решениях:

  • Шифрование ключей API в базе данных, но я не вижу, как их тестировать (расшифровывать), поскольку это не похоже на пароль?

  • Хранить ключи API в другой базе данных, размещенной в другом месте, но проблема шифрования остается той же ... нет?

  • Используйте поток OAuth: это казалось удобным, но все сервисы, которые я хочу подключить через API, не предлагают этого, и я даже не уверен, что это действительно подходит для меня.

  • Я намереваюсь разместить свой SAAS на веб-сервисах Amazon, я увидел, что он предлагает услугу, называемую «Управление ключами» KMS, но я не знаю, действительно ли она еще раз адаптирована к моим проблемным ...

Если кто-то уже должен был ответить на эту проблему или знает, как ее решить, я хочу быть в курсе этого!

Примечание: извините за мой плохой английский, я француз.

1 Ответ

0 голосов
/ 25 августа 2018

Все решения, которые вы упомянули, в какой-то степени действительны, и комбинация, скорее всего, является лучшим ответом. Вашему приложению необходим доступ к этим API-ключам, поэтому хакер не может получить полный контроль вашего приложения и не получить контроль над API-ключами. Полный контроль является ключевой частью - вам может быть намного сложнее добраться до них.

Шифрование

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

Разделение

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

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


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

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