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

Но проблема состоит в том, что почти все потенциальные взломщики защиты сервера SQL Server также знают об использовании порта 1433 для приема запросов на установление соединения в подавляющем большинстве серверов SQL Seiver. Если применяемый сервер SQL Server имеет непосредственное соединение с Интернетом, то автор настоятельно рекомендует перейти к использованию нестандартного номера порта. Для этого обратитесь к сетевому администратору, чтобы он порекомендовал вам один из свободных портов. Не следует лишь забывать, что после смены порта, через который сервер принимает запросы на установление соединения, необходимо также изменить соответствующие настройки на всех клиентских компьютерах, получающих доступ к серверу с помощью протокола IP. Например, если решено перейти к использованию порта 1402, то необходимо открыть программу Client Network Utility и ввести запись, относяшуюся к конкретному серверу, в которой в качестве номера порта IP указано значение 1402.

С версии SQL Server 2000 предусмотрена также возможность сообщить клиентской программе о том, что порт необходимо определять динамически; для этого достаточно установить флажок Dynamically determine port.

Отказ от использования учетной записи sa

Любой начинающий разработчик узнает о существовании учетной записи системного администратора SQL Server в течение первых десяти минут с начала своего обучения. Но в последних версиях SQL Server предусмотрена фиксированная роль сервера sysadmin, поэтому автор настоятельно рекомендует ввести в состав членов этой роли реальные учетные записи, а затем заменить пароль sa каким-то настолько длинным и абсолютно непостижимым текстом, чтобы ни один взломщик не стал тратить время на бесплодные попытки угадать такой пароль. Если требуется применение исключительно средств обеспечения безопасности Windows, то после этого можно отключить соответствующие средства SQL Server и тем самым покончить с проблемой учетной записи sa раз и навсегда.

Обеспечение доступа к системной хранимой процедуре xpcmdshell с помощью дополнительного интерфейса

Не забывайте о том, что нужно соблюдать исключительную осторожность, предоставляя возможность использовать системную хранимую процедуру xp cmdshell. Эта процедура позволяет вызывать любую команду DOS или Windows с интерфейсом командной строки. Набор прав, предоставляемых пользователям, зависит от того, от имени какой учетной записи эксплуатируется СУБД SQL Server. Если это - системная учетная запись (как в большинстве инсталляций), то пользователи процедуры xp cmdshell приобретают значительные права доступа к серверу (такие пользователи могут, например, копировать файлы на серверный компьютер из любого места в сети, а затем вызывать их на выполнение). Но мы обязаны полностью открыть карты и сказать о том, что значительное количество серверов эксплуатируется в контексте

учетной записи администратора домена Windows; это означает, что любой пользователь, имеющий возможность вызывать хранимую процедуру xp cmdshell на выполнение, имеет практически полный доступ ко всей сети.

Из этого следует вывод, что не предоставляя никому доступ к хранимой процедуре xp cmdshell, вы тем самым предотвратите возможность получения административных прав на конкретном сервере или, возможно, даже во всем домене.

Применение представлений, хранимых процедур и пользовательских функций как инструментальных средств обеспечения безопасности

Напомним, что представления, хранимые процедуры и пользовательские функции предоставляют исключительно широкие возможности сокрытия данных. В частности, представления обычно служат для внедрения средств обеспечения безопасности, реализуемых на уровне столбца. У пользователя, работающего с представлением, создается впечатление, будто он получает доступ ко всей таблице, тогда как в действительности доступ предоставляется только к подмножеству всех данных (напомним, что в данной книге приведен пример, в котором с помощью представления была исключена возможность доступа к конфиденциальной информации о служащем, такой как данные о зарплате). Хранимые процедуры и пользовательские функции позволяют вьшолнять в основном аналогичные действия; например, пользователю может быть предоставлено право на выполнение хранимой процедуры или пользовательской функции, но это не приведет к получению пользователем всех данных таблицы (он получит лишь то, что возвратит хранимая процедура или пользовательская функция). При этом конечный пользователь может даже не догадываться, в какой базовой таблице содержатся полученные данные. Кроме того, с самими представлениями, хранимыми процедурами и пользовательскими функциями связаны собственные средства защиты прав доступа. В частности, из того, что в представлениях и хранимых процедурах применяется некоторая таблица, не следует, что при их вызове пользователь получает права дост)Т1а к этой таблице.

Сертификаты и асимметричные ключи

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

В СУБД SQL Server предоставляется возможность применять шифрование с помощью ключей на нескольких разных уровнях с учетом того, что может потребоваться организовать несколько отдельных сфер управления, защищаемых с применением различных ключей шифрования. Кроме того, в СУБД SQL Server поддерживается так называемый главный ключ службы (Senice Master Key), который входит в состав каждой

инсталляции сервера. Главный ьслюч службы SQL Server зашифрован операционной системой Windows на уровне главного ключа службы Windows. Аналогичным образом, каждая база данных содержит главный ключ базы данных (Database Master Key), который в случае необходимости может быть сам зашифрован с помощью главного ключа службы SQL Server. После этого в каждой базе данных можно определять сертификаты и (или) асимметричные ключи (и те и другие представляют собой разновидности ключей шифрования). Общая иерархия ключей шифрования показана на рис. 22.3.

Сертификаты

- Симметричные ключи

Асимметричные ключи

- Симметричные ключи

- Симметричные ключи

- Данные

Данные

- Данные

Рис. 22.3. Общая иерархия ключей шифрования

Сертификаты

Начиная с версии SQL Server 2000 в СУБД SQL Server предусмотрено применение собственного центра сертификации (Certificate Authority- СА). Кроме того, обеспечивается возможность применения центров сертификации независимых разработчиков. Центр сертификации выпускает сертификат, который включает ключ шифрования, наряду с некоторой базовой информацией, прилагаемой к сертификату, касающейся того, на какой период времени распространяется действие сертификата (дата ввода в действие и дата его истечения), содержащей имя держателя и сведения о том, каким центром был выпущен этот сертификат. Сертификат назначается для использования на сервере с помощью команды CREATE CERTIFICATE.