HTTPS и зашифрованная база данных действительно защищены на виртуальном хостинге? - PullRequest
2 голосов
/ 31 августа 2009

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

Затем для базового безопасного веб-приложения мне нужно:

a) Веб-сайт с SSL-сертификатом, подтвержденным доменом (DV) (у меня нет фиксированного IP-адреса. Я использую базовый общий или «виртуальный» хостинг).

b) Разработайте простое приложение PHP & MySQL, которое собирает разумные данные о клиентах, помещая все файлы PHP приложения в защищенную папку SSL.

в) Все собранные данные будут сохранены в базе данных MySQL сервера.

Это часть вопросов моего сообщения:

1) Если я войду позже, используя phpmyadmin, чтобы просмотреть базу данных через обычные службы хостинга (HTTP), разве это небезопасно?

2) А как насчет администраторов хостинга? Они также могут прочитать все разумные данные, если я использую простой текст в базе данных. Но способов шифрования данных на сервере (не только при передаче по SSL) может быть достаточно? Не правда ли, что метод шифрования / декодирования может быть перехвачен администраторами хостинга? (учтите: метод находится внутри приложения на том же сервере). Я не могу платить за удобство и безопасность собственного сервера.

3) Учитывая эти вещи и предполагая, что они истинны ... действительно ли важно, если я пойду за шифрование базы данных?

Может быть, я что-то пропустил или неправильно истолковал какую-то проблему.

Большое спасибо за вашу помощь и терпение.

Ответы [ 6 ]

5 голосов
/ 31 августа 2009

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

См. Некоторые правила по этому вопросу: PCI

3 голосов
/ 31 августа 2009
  1. Да. HTTP небезопасен.
  2. Да, простой текст в базе данных небезопасен. Зашифрованный немного более «безопасен» - он будет удерживать кого-то, кто случайно просматривает, - но любой, у кого есть доступ к серверу, также имеет доступ к сценарию, выполняющему шифрование / дешифрование.
  3. Я бы сказал, да. Шифрование в вашем случае ничего не сделает против выделенного злоумышленника, но оно предотвратит немедленное получение данных сисадмином, бездействующим при просмотре данных, без необходимости осознанного шага взлома.

Я надеюсь, что вы не храните кредитную карту или другие конфиденциальные данные, особенно если это предусмотрено законодательством о конфиденциальности в вашей юрисдикции. Хранение такого рода вещей на общем сервере, вероятно, привлечет вас к ответственности. Если ничто иное, хранение данных кредитной карты таким образом не будет нарушать вашу торговую учетную запись - если они узнают об этом, Visa и MasterCard станут для вас недоступными.

1 голос
/ 31 августа 2009

Я думаю, что Бобинс абсолютно прав. Крипто с открытым ключом может помочь вам, но имейте в виду, что вы теряете удобство использования PHPMyAdmin для просмотра данных - вы увидите мусор, который нужно будет расшифровать где-то на стороне. См. http://www.php.net/openssl, чтобы узнать больше о PHP и шифровании с открытым ключом.

1 голос
/ 31 августа 2009

1) Конечно, просмотр данных с помощью phpmyadmin через HTTP небезопасен.

Что касается 2), если у вас нет физической защиты, то вы не можете иметь никакой защиты (возможно, за исключением хранения зашифрованных данных, которые вы шифруете и дешифруете вне хост-сайта).

Поскольку ваша хостинговая компания имеет доступ к компьютеру, они могут читать все ваши данные.

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

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

1 голос
/ 31 августа 2009
  1. Это.

  2. Они могут.

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

Вы правы. Единственный способ убедиться в этом - запустить собственный сервер. Также вам следует знать о стандарте безопасности данных в отрасли платежных карт .

0 голосов
/ 31 августа 2009

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

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

Не правда ли, что метод шифрования / декодирования может быть перехвачен администраторами хостинга?

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

...