алгоритмы пароля / коммерческой тайны: они безопасны в файлах php?

Question

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

Считается ли это безопасной настройкой; Кто-нибудь может загрузить исходный текст php с моего веб-сервера и, следовательно, иметь доступ к моему корневому паролю mysql?

Я использую Apache 2.0 и PHP 5, на Ubuntu 8.04 и MySQL 5.

спасибо.

Answer 1

Если вы храните медицинские данные в Соединенных Штатах, к вам применяются особые, строгие требования безопасности . Другие страны могут иметь аналогичные положения.

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

Это серьезный вопрос, который может подвергнуть вашу компанию серьезной ответственности.

Answer 2

Ваш сервер защищен как самое слабое место вашего сервера.

Если кто-то скомпрометировал слабый пароль для учетной записи, которая может прочитать этот файл - тогда да, теперь у него есть ваш пароль root. Если вы допустили ошибку в своем коде (или использовали чей-либо код / ​​программу с такой ошибкой / «функцией»), это также может поставить ее под угрозу - и да, обе ситуации БЫЛИ И ДЕЛАЮТ.

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

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

Answer 3

В отношении

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

Хорошая предосторожность против этого - поместить все файлы PHP (кроме файла начальной загрузки / индекса) вне каталога public_html / htdocs / www или любого другого каталога.
Вы можете использовать что-то вроде ZendGuard.
Вы можете просто решить скомпилировать конфиденциальные данные как расширение PHP (в основном, только константы).

Помните, что 100% защиты не существует.

Answer 4

Да, ваш источник php может быть «просочился» (доставлен как текст, а не исполнен), если ваш веб-сервер каким-то образом неправильно настроен.

Утечка кода из-за сбоя в работе веб-сервера, приводящего к доставке php-страниц вместо выполнения , произошедшего с Facebook в 2007 .

Answer 5

Создайте пользователя mysql для каждого приложения и предоставьте этому пользователю наименьшее количество привилегий, необходимых для правильной работы. Большинство приложений нужно только выбрать, обновить и удалить. http://en.wikipedia.org/wiki/Principle_of_least_privilege

Ваш пользователь root mysql имеет особые привилегии как суперпользователь. Допустим, вы достигли максимального ограничения соединения. MySQL всегда резервирует последнее соединение для суперпользователя, чтобы вы могли войти туда и администрировать окно, уничтожать соединения и т. Д.

Если вы используете root в своем веб-приложении, вы можете заблокировать свою собственную базу данных.

Answer 6

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

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

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

Это гарантирует, что если у вас нет правильного личного ключа, вы не сможете получить симметричный ключ.

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

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

Закрытый ключ будет удален сразу после использования, чтобы ограничить вероятность его записи на жесткий диск.

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

Answer 7

Просто из любопытства, вы знакомы с Google Health ?