Шифрование базы данных SQL Server [закрыто]

-1

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

В соответствии с этим SQL Server не использует соление при шифровании.

Что я ищу, так это то, что если пользователь введет правильное имя пользователя / пароль, он получит доступ к своей учетной записи, но если злоумышленник использует SQL-инъекцию, он получит зашифрованную базу данных, которую он должен атаковать, чтобы получить информацию ,

Примечание: программисты используют SQL Sever 2012

— Чарльз Уитфилд
источник

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

— ChrisInEdmonton

@ChrisInEdmonton - В SQL Server я ищу то, как вы будете хранить пользовательские данные, так что если злоумышленник получит базу данных с помощью SQL-инъекции, он получит случайные строки и получит расшифровать это. Это было бы невозможно, потому что у хакера нет ключа.

— Чарльз Уитфилд

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

— Владимир Осельский

@SaUce - я назвал SQL-инъекцию возможной атакой.

— Чарльз Уитфилд

То, что рекомендует @ techie007, не позволит злоумышленнику увидеть данные, принадлежащие другим пользователям, злоумышленнику будут видны только данные (взломанного) пользователя, но если он найдет способ взломать учетную запись 1 пользователя, он сможет использовать SQL-инъекцию для определения других пользователей. а затем войти в каждую учетную запись и получить свои данные. Нижний ответ - НЕТ. Есть целые книги, написанные по безопасному кодированию.

— Владимир Осельский

Ответы:

Шифрование SQL Server предназначено для защиты данных в состоянии покоя, защиты файлов резервных копий и предотвращения доступа кого-либо к файлам данных базы данных в необработанном формате.

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

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

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

Изменить: я отмечаю, что вы удалили все ссылки на кредитные карты из вашего OP, поэтому, если это не ваша цель, не обращайте внимания на мои комментарии по стандартам PCI. Мои комментарии по шифрованию SQLServer остаются в силе.

— Фрэнк Томас
источник

Это просто гипотетически. Я просто хотел понять, какой метод шифрования можно использовать для SQL Server, как я описал.

— Чарльз Уитфилд

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

— Фрэнк Томас

Как компания, например Microsoft, хранит имя пользователя / пароли для учетных записей электронной почты в зашифрованном виде? Таким образом, если бы злоумышленник попробовал SQL-инъекцию, все, что он получил бы, - это случайные строки, которые он расшифровал бы с помощью ключа, которого у него нет. Итак, предположим, что Microsoft использует SQL Server 2012 для базы данных. Извини, игнорируй это. Я печатал это, когда вы вносили изменения в свой пост.

— Чарльз Уитфилд

сайты не хранят пароли. они хранят (соленый) хэш пароля, поэтому, если он будет украден, злоумышленник не сможет использовать эту информацию для входа в систему. это одно место, где сильное одностороннее хеширование лучше, чем двустороннее шифрование. Что попало в проблему Adobe, так это то, что они зашифровали данные своей учетной записи пользователя вместо того, чтобы хэшировать пароли, и со временем алгоритм, который они использовали, стал уязвимым (3des, если вам интересно). используйте SHA512 или эквивалентный хеш-код (не используйте SHA1 или MD5)

— Frank Thomas

Спасибо за разъяснения. Так где именно хранятся пароли? «Затем на прикладном уровне (не на сервере sql) зашифруйте конфиденциальные данные для этого конкретного пользователя, прежде чем сохранять». Спасибо за это. Есть ли веб-сайт или учебник, показывающий, как это можно сделать?

— Чарльз Уитфилд

Пожалуйста, обратитесь к таблице dbo.aspnet_Membership провайдера ASP.Net. Он хранит соль пароля на уровне пользователя и шифрует пароли перед их сохранением. Очень похоже на ваше требование.

В SQL Server нет готовых функциональных возможностей, если только вы не используете опцию для шифрования столбца. Но тогда вы застряли с необходимостью использовать тип данных varbinary, а также столкнуться с возможным снижением производительности (на 20% медленнее, чем в некоторых статьях). См. Http://technet.microsoft.com/en-us/library/ms179331.aspx.

— Tushax
источник