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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

[ПРАВИТЬ] Мы не храним номера SSN и номера кредитных карт. Если вы это сделаете, вам нужно быть еще более осторожным. Большинство моих приложений имеют доступ к журналу, некоторые обязаны HIPPA, но я считаю, что это хорошая практика для всего значимого

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Вот руководство от Microsoft по рекомендациям по безопасности SQL Server 2005: 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

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

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