Проверка безопасности SQL Server

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

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

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

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

Я работал с тем же в своей компании. На самом деле я обнаружил, что большинство людей были более восприимчивы к этому, чем я думал, но несколько моментов были ключевыми:

• Напомните им, что основная цель этого - предотвратить несчастные случаи. Несчастные случаи - это то, что касается каждого. Почти никто не думает, что они когда-либо будут взломаны, и разговоры о внутренних хакерах немедленно заставляют их защищаться («вы мне не доверяете?»).
• Быстро отвечайте на запросы, когда они все же наталкиваются на блокировку.
• Будьте готовы работать с ними. Мы обнаружили, что некоторые из вещей, которые я изначально заблокировал, были необходимы им для выполнения своей работы и не вызовут проблем, если их немного откроют.
• Быть последовательным. Вы должны применять эти политики повсеместно. По возможности примените их и к себе.

Я также пытался делать это меньшими шагами, чтобы сделать это менее разрушительным. Например:

• Все новые базы данных теперь имеют ограниченные разрешения с самого начала. Вы не упустите то, чего никогда не пробовали.
• Начните с удаления системного администратора и других прав на уровне сервера, если они у них в настоящее время есть. Большинство людей согласятся, что им не нужно перенастраивать сервер, и это устраняет множество дыр в безопасности. Как только они увидят, что могут жить с этим, это подготовит почву для дальнейшего ужесточения.
• Сжимайте базы данных одного приложения за раз. Это делает его более управляемым, а также позволяет вам со временем узнать, какие права им нужны, чтобы в будущем ужесточение правил прошло более гладко.

Удачи!

Это серьезное мероприятие. Эти люди, вероятно, очень настроены по-своему, и для того, чтобы это изменить, потребуется большая поддержка со стороны их начальства. У них уже есть тестовая среда? Я предполагаю, что они это делают, но если они этого не делают, это должен быть первый шаг. Также убедитесь, что он готов к табаку. Если он старый и медленный, они будут съеживаться от того, что им придется его использовать. Вы должны быть готовы бросить им кость в других областях, например, в тестах, чтобы дипломатически облегчить им путь.

Познакомьтесь с ведущими разработчиками и узнайте, почему у них есть доступ к производственной среде. Вы, наверное, уже знаете большинство из них. Затем удалите / рассмотрите их причины. Я один из группы разработчиков, у которой есть полный производственный доступ к серверам, и я знаю, что мне этого не должно быть. До сих пор я видел, как трое моих коллег вызвали серьезные сбои из-за поспешного выполнения SQL или самоуспокоенности. «нам нужно внести изменения немедленно» - «напишите сценарий, я его проверю и запустю, если все в порядке». «Нам нужны живые данные» - «Серьезно? Или подойдет прошлогодняя резервная копия?» «Мне нужно проверить это, посмотреть, работает ли» - «Поприветствуйте свой новый виртуальный тестовый сервер».

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

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

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

Я настоятельно рекомендую вам проверить, применимо ли одно из этих условий к вашей организации:

SOX (Закон Сарбейнса-Оксли, применимый к публично торгуемым компаниям в США)
Счет 198 (провинция Онтарио и косвенно остальная часть Канады по правилам CSA)
CLERP-9 (Австралия)
J-SOX (Япония)

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

Во всех случаях руководство очень быстро придет на вашу сторону - под SOX это управление которые будут привлечены к ответственности (тюремное заключение!), если не будет установлен соответствующий «контроль».

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

Очень трудно отучить разработчиков от доступа к производственному SQL, поэтому сделайте доступ как можно более внезапным и четким. Если у вас есть поддержка руководства, дипломатия - не главное, о чем нужно беспокоиться. Безопасность и надежность важнее всего.

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

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

Я разработчик, у которого был производственный доступ к базе данных. Запустить статус обновления и забыть о предложении where ооочень легко.

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

Я как разработчик должен выкинуть это там.

Ненавижу тебя.

Тот факт, что администраторы баз данных хотят ограничить нас в выполнении работы, - идиотизм. У нас есть полная свобода действий в системе. Так вы заблокировали мою учетную запись? Все, что мне нужно сделать, это отбросить строку производственного подключения в моем отладочном коде Visual Studio, и я уйду и могу контролировать все, что может делать приложение.

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

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

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

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