Падение черного ястреба

Фленов Михаил aka Horrific

Спецвыпуск: Хакер, номер #052, стр. 052-070-3

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

Аутентификация MS SQL

В MS SQL Server все настройки происходят в SQL Enterprise Manager. Запусти эту программу, и перед тобой откроется окно с разделенной на две части рабочей областью: слева дерево объектов, справа - то, что содержит выделенный в дереве объект.

Откроем ветку Microsoft SQL Servers, в которой содержатся группы серверов. По умолчанию создается группа с именем SQL Server Group. После выделения группы в ней становятся видны все серверы. Если есть локальный сервер, то он останется единственным до тех пор, пока не будут зарегистрированы другие серверы баз данных (удаленные или локальные). Щелкнем по имени сервера и в появившемся меню выберем пункт Properties. Перед тобой откроется окно свойств сервера. Идем на закладку Security – здесь к твоим услугам переключатель между режимами.

Здесь же можно выбрать уровень аудита (Audit Level). По умолчанию выбран None, а значит, сервер не будет сохранять в логах информацию об удачных или неудачных входах в систему. Все знают, что в продуктах MS настройки по умолчанию далеки от идеала, но то, что в логах не будет информации о входах пользователей, - просто катастрофа. Срочно переключай аудит на All, чтобы можно было контролировать, кто и когда входил (или пытался войти).

Внешние ключи

Как ключи могут повлиять на безопасность? Казалось бы, это всего лишь связь между двумя таблицами. Здесь все довольно просто. Чаще всего связь построена по принципу главный-подчиненный (один ко многим). В одной таблице находится главная строка, а в другой - множество подчиненных строк. Допустим, у нас есть две таблицы: одна для хранения списка сотрудников (People), а другая с информацией об их зарплатах по каждому месяцу (Salary). Если попытаться удалить запись из таблицы Peoples, для которой есть подчиненные записи в Salary, то произойдет ошибка (сначала нужно удалить все подчиненные записи).

Ты еще не видишь преимущество вторичных ключей? А я вижу. Таблицы сотрудников можно сильно не защищать, потому что с ними работает множество народа и текущий список может быть доступен через web. Другое дело- зарплата. Даже если хакер получит доступ к Peoples, то не сможет удалить все записи. Внешние ключи не дадут врагу сделать свое черное дело, пока не будут удалены соответствующие записи из Salary, что намного сложнее.

Из всего сказанного можно сделать такой вывод: если есть публичная таблица, из которой запрещено удалять (Public), создай для нее подчиненную таблицу (Slave), защищенную по полной программе, и свяжи обе таблицы внешним ключом. При создании новой записи в главной таблице в подчиненную должна добавляться связанная строка. Эта связь сделает удаление из Public невозможным до тех пор, пока хакер не найдет закрытую для бдительной общественности таблицу Slave.

Триггеры

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