Download the SQL Server Compliance Guide. Это старая 92-страничная документация 2008 года, но это скорее всего лучший (и самый вечный) технический документ, который когда-либо выпускал Microsoft.

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

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

Домашнее задание: поиск рисков

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

SELECT * FROM INFORMATION_SCHEMA.COLUMNS

WHERE COLUMN_NAME LIKE '%password%'

OR COLUMN_NAME LIKE '%social%'

OR COLUMN_NAME LIKE '%credit%'

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

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

Когда найдете такие данные, свяжитесь с разработчиками и бизнес-контактом для этой базы данных. Объясните, что данные не зашифрованы, и используйте примеры из Руководства по соответствию SQL Server, чтобы показать, какие последствия могут быть при утечке этих данных.

Правило: знайте, у кого и на что есть доступ

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

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

Наиболее серьезно защищенные компании выбирают совершенно другое решение, которое находится за пределами области DBA. Группа безопасности покупает аппаратные средства сторонних производителей, такие как IBM Guardium или Imperva, которые действуют как сетевой брандмауэр между всеми и SQL Server. Устройство регистрирует все, что происходит на SQL Server, а затем команда, отвечающая за безопасность может просмотреть эти журналы и вы даже не будете знать об этом.

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

No Comments