Как бороться с паролями, ключами API и т. Д. В стеке разработки? (git, webservers и т. д.)

Question

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

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

Очевидно, что мне нужны они где-то в моих PHP-источниках. Я обычно помещаю все секретные или конфиденциальные данные в отдельный файл include (например, «passwords.php»), который я размещаю вне корня документа HTTP. Таким образом, посетители не могут напрямую обращаться к самому файлу.

Но есть больше:

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

2. Репозитории Git: особенно если мы хотим удаленно размещать объекты git удаленно, должен ли я полностью хранить файл passwords.php из репозитория git, чтобы убедиться, что данные нигде не протекают? (но тогда как мне перейти на контроль версий или передать его членам команды?)

3. Строгие политики коммуникации: Я буду работать с несколькими людьми, и я хочу, чтобы кто-либо никогда не отправлял по электронной почте или просто трафик по FTP чувствительные детали. Некоторым людям нужен только доступ к тестовой среде, а не к фактическому серверу. Как ограничить доступ к passwords.php (содержащий фактические серверные логины и т. Д.) Только тем, кто действительно нуждается?

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

Answer 1

Это звучит как обязательство. Много риска. Но реквизит для вашей цели.

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

Я предлагаю разместить ваше приложение с помощью Amazon Web Services. Они обеспечивают удобство управления, надежные и надежные веб-службы. После того, как вы начнете сегментировать свое приложение (серверы db, кластеры кешей, медиа-серверы и т. Д.), Он станет меньше: «Надеюсь, что меня не взломают» и больше «Я надеюсь, что смогу справиться со всем этим дерьмом». ,

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