Каковы ваши предложения по хранению данных аутентификации AWS? - PullRequest
4 голосов
/ 07 декабря 2008

Сценарий: веб-приложение, написанное на PHP, использует Amazon Web Service и должно иметь под рукой идентификатор ключа доступа и секретный ключ доступа для работы. Существуют ли текущие рекомендации и / или API для безопасного хранения этих данных?

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

Это похоже на обычную ситуацию , и я никогда не находил удобного решения. Очевидно, что я не могу использовать односторонний хэш, потому что мне нужны исходные данные для создания HMAC для отправки в AWS. Ссылки на родственные S.O. вопросы очень приветствуются.

Ответы [ 3 ]

1 голос
/ 07 декабря 2008

Ах. Вопрос безопасности.

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

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

Если честно, если это не ваш собственный хост, ЛЮБЫЕ конфиденциальные данные могут быть скомпрометированы.

Если это ваш собственный хост, я бы предложил использовать соответствующие разрешения в Linux и PHPSuExec , чтобы убедиться, что только сценарии, которые ВЫ пишете, могут получить доступ к файлам.

В любом случае, чтобы ответить на ваш первоначальный вопрос, ваши AWS Access / Secret Keys точно такие же, как и пароль MySQL. Хорошо, у него есть возможность разрешить кому-то доступ к вашему сервису, но он не дает им доступа к вашему подробности. Даже при симметричном шифровании, если в вашем скрипте есть дыра в безопасности, к этой информации можно получить доступ.

Проще говоря, вы рискуете, когда кладете эти ключи в любое место, доступное для всех, кроме вас. Насколько вы доверяете серверам Amazon, не подвергаясь риску?

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

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

Надеюсь, это поможет

0 голосов
/ 24 декабря 2008

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

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

Таким образом, безопасность сервера по-прежнему является ключевой проблемой, вопрос лишь в том, насколько безопасности достаточно. Я бы посоветовал взглянуть на Bastille Linux или что-то подобное, чтобы укрепить свой сервер, но это совсем другая тема.

0 голосов
/ 17 декабря 2008

Моя мысль состоит в том, чтобы симметрично зашифровать его в файл на основе ключа, созданного из переменных локального сервера. Таким образом, это [надеюсь] бред, если кто-то получает копию файла через FTP, потерял ноутбук с скопированными файлами и т. Д. У меня есть проблема, что опытный злоумышленник может просто загрузить свой собственный сценарий, чтобы расшифровать его .

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

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

Если вы беспокоитесь о том, чтобы кто-то получил физический доступ к коробке, сконцентрируйтесь на физической безопасности, чтобы остановить это.

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