Как защитить базу данных SQL Server 2005?

Question

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

Что делать, чтобы обеспечить надежную защиту данных?

Шифрование данных имеет смысл, конечно ... но как насчет того, чтобы остановить кого-то от того, чтобы начать работу с машиной?

Что мне делать с разработчиками, которым необходим доступ к данным, исправления и т. Д.?

Есть ли документ или сайт передового опыта, который я могу использовать в качестве руководства?

Answer 1

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

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

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

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

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

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

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

Ох. И никаких «реальных» данных о разработке или серверах QA.

[EDIT] Мы не храним номера SSN или номера кредитных карт. Если вы это сделаете, вам нужно быть еще более осторожным.Большинство моих приложений имеют доступ к регистрации, некоторые из них требуются из-за HIPPA, но я считаю, что это хорошая практика практически для чего-то значимого.

Answer 2

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

Answer 3

Вам необходимо оценить стандартную безопасность для сервера Windows. Хорошим местом для начала является использование интегрированных логинов, а не логинов SQL.

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

Answer 4

Я бы использовал Active Directory для управления доступом к SQL Server или любому сетевому ресурсу. Сгруппировав пользователей и применяя безопасность к группе, это сделает намного проще вносить изменения в будущем.

Вот руководство от Microsoft по SQL Server 2005 Security Best Practices: http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SQL2005SecBestPract.doc * Примечание: скачивает документ Word, так что вы будете нуждаться в MS Word или зрителя MS Word

Этот документ имеет много подробно, чтобы вы могли сначала взять кофе.

Однако я согласен с другими, активное развитие не должно происходить против производственных данных. В настоящее время мы используем процесс очистки производственных данных до того, как он попадает в среду QA или Dev.

Еще один вариант, который мы рассмотрели, - это разработка решения для генерации данных для Dev и QA.

Answer 5

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

Если вы находитесь в США, я предположил бы, что ваша корпорация может иметь кучу высокооплачиваемых адвокатов, которые будут иметь возможность так же дать окончательный ответ :)

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