GRANT IMPERSONATE ON LOGIN::Login2 TO Login1
Нетрудно видеть, что учетная запись Login1 выступает здесь в качестве субъекта доступа, а Login2 – в качестве объекта.
При предоставлении права IMPERSONATE пользователю БД, вместо ключевого слова LOGIN перед знаком «::» ставится слово USER. Например:
GRANT IMPERSONATE ON USER::User2 TO User1
Разумеется, категория доступа IMPERSONATE может фигурировать также в вызовах команд DENY и REVOKE.
6.2. Использование криптографических методов защиты информации в системах баз данных
Криптографические методы получили широкое распространение в силу своей универсальности: благодаря их применению удается одновременно обеспечить и целостность, и конфиденциальность информации. В СБД криптографические средства присутствуют, скорее, как вспомогательные. Однако умалять их значения нельзя. Почему?
Во-первых, всегда существует риск перехвата информации, циркулирующей между клиентской и серверной частью СБД. Даже пароли учетных записей SQL Server, которые указываются в командах CREATE LOGIN и ALTER LOGIN, передаются на сервер в открытом виде. Если и сам канал передачи информации не защищен, то перехватить нужный пароль никому не составит труда. Для повышения защищенности информации при передаче по незащищенным каналам целесообразно использовать встроенные в SQL Server механизмы шифрования трафика.
Во-вторых, крайне желательно хранить конфиденциальную информацию в БД в зашифрованном виде. Тщательной разработки правил доступа может оказаться недостаточно, чтобы предотвратить несанкционированное раскрытие неких секретных сведений. Дело в том, что злоумышленник может найти способ, чтобы скопировать БД на свой сервер, где он обладает правами системного администратора. Системный администратор имеет доступ к любой БД с правами владельца, и запретить ему ничего нельзя: он по умолчанию имеет полные права на выполнение всех действий и на просмотр любой информации. И если конфиденциальные сведения хранятся в незашифрованном виде, системный администратор без труда доберется до них. Единственная (но во многих случаях преодолимая) трудность для злоумышленника – это получить копию файлов БД или носитель ее резервной копии.
В SQL Server 2005 имеются следующие механизмы криптографической защиты информации:
· средства шифрования трафика между SQL-сервером и SQL-клиентами;
· операторы Transact-SQL, поддерживающие работу с криптографическими ключами и цифровыми сертификатами;
· процедуры и функции поддержки шифрования информации в БД;
· языковые средства шифрования кодов подпрограмм БД.
6.2.1. Шифрование трафика в SQL Server 2005
Единственная возможность шифрования трафика в SQL Server 2005 – это установка SSL-соединения.
В SSL обязательно используются цифровые сертификаты. В SQL Server 2005 можно использовать два типа сертификатов.
1. Самоподписанный сертификат. Генерируется и подписывается самим сервером SQL Server 2005. Автоматически создается и применяется в ситуации, когда шифрование трафика включено, но нет явного указания, какой именно сертификат использовать. Существенный недостаток самоподписанных сертификатов: при их использовании легко провести атаку «человек посередине».
2. Сертификат от внешнего центра сертификации.
В составе операционной системы Windows 2003 Server поставляется компонент Certificate Services – центр сертификации от Microsoft. Ему автоматически доверяет и Windows, и SQL Server (серверные и клиентские компоненты), поэтому рекомендуется использовать сертификаты, выдаваемые именно данным центром. Для защиты SQL Server 2005 требуется установить изолированный корневой центр сертификации, создающий сертификаты для Web-серверов, аутентификации клиентов при подключении к Web-серверам и т. п. Другие типы центров сертификации не подойдут для SQL Server. Имя центра сертификации должно совпадать с DNS-именем компьютера, на котором он разворачивается.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.