|
|
|
|
|
Строим автоматизированную систему безопасностиОдно время обеспечение безопасности баз данных подразумевало лишь проверку доступа. Разбил пользователей на группы по типам задач, назначил каждой группе разрешения, необходимые ее членам, и все. Но времена меняются! Сегодня ни один специалист по SQL Server даже не подумает запускать базу данных, не проверив ее систему безопасности на наличие таких уязвимых мест, как слабые пароли или ошибки брандмауэра. Но как узнать, что проверены все существенные настройки безопасности? Простого решения, вроде блокировки папок с файлами установки или отключения гостевой учетной записи на серверах, увы, не существует. Необходимо разработать упорядоченный план тестирования безопасности с проверкой различных параметров настройки, характерных для компании, и постоянно вести журнал результатов проверок. В предлагаемой статье я объясню, из каких элементов состоит схема тестирования безопасности, и приведу примеры кода T-SQL, которые можно использовать для автоматизации различных процессов при тестировании конфигурации и работе с отчетами о тестах. Автоматическое тестирование Проверки конфигурации — это основной и давно испытанный прием тестирования безопасности базы данных, а также существенный этап защиты базы данных от вторжений извне и изнутри организации. По существу, проверка конфигурации сводится к проверке того, что конкретная настройка, относящаяся к системе безопасности, такая как включение брандмауэра, настройка того или иного порта или удаление ненужных сетевых библиотек, выполнена правильно. Проверка конфигурации также затрагивает политики резервного копирования и защиты файлов, режимы аутентификации, гостевые учетные записи и полномочия роли Public. Большинство администраторов баз данных выполняют проверки вручную, но, создав сценарий, объединяющий отдельные действия, можно легко автоматизировать многие рутинные операции. Например, выполнив код T-SQL, показанный в листинге 1 (вставив собственный номер версии), можно выяснить, установлен ли на сервере базы данных последний пакет обновлений. А чтобы определить, была ли отключена ненужная служба, можно выполнить код из листинга 2, который проверяет, работает или нет служба координатора распределенных транзакций (MSDTC). Хотя сценарии, которые автоматизируют тесты безопасности, редко бывают сложнее, чем приведенные примеры кода, эти примеры не являются полностью автоматизированными тестами. Полностью автоматизированный тест безопасности включает в себя следующие элементы. Четко определенный план каждой проверки, включающий ожидаемый результат (например, все версии SQL Server равны или превышают номер 8.00.2039), чтобы можно было определить, правильно ли установлен параметр, и условия проведения теста (сервер работает, база данных поддерживает все тестируемые настройки, тест имеет необходимые разрешения и для сценария, и в местах проверки). Составление отчетов о результатах каждой проверки. Отдельный отчет о недостатках, который создается, когда значение параметра нарушает политику безопасности. Не стоит тратить время на тестирование параметра, если для него в компании не установлены требования или политики безопасности. Более того, если очевидно, что конкретная настройка безопасности должна тестироваться, даже если она не документирована, сначала следует как можно скорее зафиксировать в журнале наличие нарушения плана безопасности или бизнес-правил компании по этой настройке. Если данная настройка является уязвимой с точки зрения безопасности, следует сообщить ответственному лицу о том, что необходимо пересмотреть политику безопасности. Ведение журнала отчетов о проверках Запись отчета о тесте должна быть частью процедуры тестирования; она производится при каждой проверке той или иной настройки безопасности. Каждый отчет должен содержать как минимум уникальный идентификационный номер (ID), дату проверки, имя выполнявшего проверку сотрудника, ожидаемое и актуальное значение проверяемого параметра и, наконец, резюме теста — успешный или неуспешный. Далее я поясню, как определить ожидаемое значение теста. Можно создать таблицу и хранить в ней результаты отчетов, генерируемые в процессе тестов конфигурации, как показано в коде T-SQL листинга 3. Два отчета, приведенные в табл. 1, содержат примеры результатов тестов, подобные результатам, которые можно увидеть, выполняя предыдущие сценарии тестов. Позже я расскажу об особой технике написания сценариев для перемещения результатов тестов в таблицу, а также для автоматизации других частей процесса тестирования. Вести журналы необходимо — это экономит время, обеспечивает целостность данных и сокращает дублирование тестов. Разработчики могут использовать эти результаты для воспроизведения очевидных ошибок. Тестировщики могут применять их для проверки сделанных корректировок. Ведение журнала проверок избавит администратора от проведения незапланированных и недокументированных тестов. Тем более что автоматизировать ведение журнала отчетов о проверках так же просто, как сами проверки безопасности. Следует также вести журнал ошибок с записями обо всех обнаруженных нарушениях и потенциальных уязвимых местах системы безопасности. Отчет об ошибках должен содержать ту же информацию, что и отчет о проверке, плюс уникальный номер ошибки, дата составления отчета, описание проблемы и состояние работы над ошибкой (например, «тестируется», «отладка», «уточнение», «устранена»). Некоторые компании, возможно, сочтут необходимым добавить к этому перечню еще один пункт — указание на соответствующее требование политики безопасности. Чтобы вести журнал ошибок, сначала нужно создать другую таблицу, соответствующую данным отчета об ошибках, но на этот раз используя код, подобный коду листинга 4. Чтобы представить, как выглядит отчет об ошибках, рассмотрим такой пример: проверка безопасности показала, что сервер работает под учетной записью LocalSystem (что категорически запрещается почти на любом производстве, см. код листинга 5). Отчет об ошибке по этой проверке может выглядеть примерно так, как показано в табл. 2. Обратите внимание на столбец Current Status, где состояние «отладка» (Debugging) означает, что тестирование приостановлено до окончательного решения проблемы. Как только проблема будет устранена, администратор или разработчик переустанавливает состояние в значение «тестируется» (дефектная настройка — LocalSystem в данном случае — обнаружена и приведена в порядок) или в состояние «закрыто» (проблема решена по-другому). Дата публикации: 2007-03-18 20:08:43 Просмотров: 1702 Текущая оценка 0.00 голосов - 0
|
|
4.98 голосов: 576
