Допустим, у меня есть база данных MySQL, в которую пользователи могут вводить некоторые личные данные, такие как почтовые адреса, через веб-сайт php.Пользователи НЕ могут войти на этот сайт, чтобы позже проверить, что они ввели.Предприятие, для которого они ввели свои данные (добровольно, конечно), затем может использовать эти данные, чтобы, возможно, отправлять пользователям реальную почту (вы знаете, почтовые услуги и тому подобное) или электронные письма (конечно, пользователи заранее договорились, что они хотят получать электронные письма),База данных служит просто хранилищем данных, и я хочу, чтобы она была немного безопасной.Если кто-то проникнет в базу данных, получение адреса электронной почты и фактического имени и фамилии (многие адреса электронной почты в любом случае содержат оба адреса) может не принести большого вреда, но знание того, где живут люди, может быть слишком большой раздачей.
Предприятие получает доступ к базе данных через интерфейс C #, который предназначен для хранимых процедур в базе данных для выполнения каких-либо задач, включая поиск пользователей на основе их адреса электронной почты.
Из того, что я собрал в процессе поиска, я мог бы подуматьследующей процедуры для обработки личных данных более безопасным способом (чем сохранение их в виде простого текста в базе данных)
- перед отправкой конфиденциальной информации в хранимые процедуры простой текст шифруется с помощьюключ, пока еще в php, поэтому все журналы сервера MySQL видят зашифрованные данные
- интерфейс использует тот же ключ, чтобы сделать данные читаемыми снова, когда они отображаются для пользователей предприятия (им нужно получить доступэта личная информацияd пользователь чувствует себя комфортно на предприятии, и в этом вся суть этой схемы)
Моя точка зрения такова: это не пароли, которые хранятся, поэтому мне не нужны все паролихитрость хеширования (насколько я понимаю, при безопасном сохранении пароля в базе данных вы используете односторонний алгоритм, поэтому вы никогда не сможете взломать пароль прямо из базы данных, а должны хешировать каждый пароль, который хотите попробовать, и проверить его на соответствиежелаемую запись в базе данных, чтобы увидеть, если вы выбрали правильный пароль), но вместо этого можно пойти на простое шифрование / дешифрование, потому что я не хочу грубо форсировать каждый адрес из базы данных.
Есть несколько грубых моментов, которые вызывают у меня беспокойство:
- Мне нужно каким-то образом предоставить ключ, который я хочу зашифровать, php.Обычно это делается с помощью библиотеки или внешнего php-документа, например, вы предоставляете информацию о подключении к базе данных в отдельном php-файле, который находится в папке на сервере, недоступной из Интернета (сервер скажет, что доступ запрещен, если вы попытаетесьполучить доступ к нему) Это хорошая практика, и могу ли я быть уверенным, что этот файл ключа действительно безопасен?
- Мне также необходимо предоставить ключ для интерфейса.Это должно быть сделано отдельно в (возможно зашифрованном) файле конфигурации для внешнего интерфейса. Разумно ли иметь ключ в двух местах, хотя и для двух разных систем? Ключ никогда не должен изменяться, иначе часть данных будет потеряна!
- Почему-то у меня такое чувство, чтоесли кто-то знает, как получить доступ к базе данных, он / она, вероятно, выяснит, где находятся данные о соединении и как к ним следует обращаться.О, смотри, вот ключ шифрования, интересно, что это делает. Какова вероятность того, что если доступ к базе данных будет нарушен, ключ шифрования будет открыт, а также приложит все усилия для того, чтобы предоставить пользователям немного больше конфиденциальности?
- Если бы я хотелчтобы добавить еще один «дополнительный уровень безопасности» и зашифровать адрес электронной почты, я должен был бы зашифровать каждый адрес электронной почты, который я хочу найти, из php или внешнего интерфейса, верно?
- Наличие процедур поиска с использованием«RIKE» будет взламывать зашифрованные поля, не так ли?Таким образом, чтобы продолжить поиск частей адреса электронной почты, я не могу зашифровать запись электронной почты, верно?
- Мне придется изменить поля моей базы данных на двоичные, чтобы вместить зашифрованные данные или сделать их больше и кодировать их с помощью base64, не так ли?
- Существует ли алгоритм шифрования / дешифрования, готовый к использованию в PHP 7.0.7 и C #?(Я не слишком беспокоюсь о C #) Тот, который достаточно безопасен, не раздувая мои крошечные тексты на огромные куски двоичного кода?Я не знаю, имеет ли это какое-либо значение, но , если я использую, например, 256-битный ключ, это 32 байта.Если уличная часть адреса будет короче 32 символов, будет ли работать шифрование?Будут ли задействованы громоздкие отступы?
В целом, я чувствую, что выигрыш в безопасности незначителен по сравнению с мерами, которые я должен предпринять в своих файлах php, а также в коде длявнешний интерфейс.Воспринимаемый выигрыш в безопасности может быть больше («Woha! Они сохраняют наши данные в зашифрованном виде! Они точно знают, что делают!»).Наличие строгих и ограничительных привилегий для определенных типов пользователей (например, отозвать команды «SELECT») должно быть более полезным, не так ли?
Правка для @Luke Joshua Park:
Спасибо за ваш подробный ответ.Я полагаю, под сервером API вы имеете в виду веб-сервер, на котором находится мой php?Это действительно должно быть отдельно от сервера базы данных.Оба сервера размещены в сети университета, но доступ к ним можно получить через Интернет.
Я могу пройти путь аутентификации до точки, где каждый пользователь внутри предприятия (небольшой проект в указанном университете, может быть, плохойвыбор формулировки) имеет базу данных пользователя с разумно установленными грантами.Но пользователи извне, использующие php, только отправляют данные для хранения в базу данных (в идеале с обычным, но отдельным пользователем базы данных с соответствующими грантами) и никогда не получают (свои) данные.Использование аутентификации означало бы, что они сначала должны были создать учетную запись (которая не нужна), и как они аутентифицируют себя для создания нежелательной учетной записи?