|
|
По материалам статьи Brian Knight "10
Steps to Securing your SQL Server"
Введение Защита SQL Server довольно трудная задача, но весьма необходимая. Эта статья призвана заострить внимание на сравнительно простых способах защиты SQL Server. Хотя предлагаемые рекомендации позволят Вам избежать ряда наиболее распространённых проблем защиты SQL Server - Вы не должны полностью полагаться на эти рекомендации и ни в коем случае не отказываться от постоянного аудита и корректировок вашего плана безопасности. Ниже представлены рекомендации по защите десяти основных точек безопасности SQL Server: Если возможно, всегда используйте Windows Authentication Почти в каждой уязвимости Microsoft SQL Server автор видел предупреждение в нижнем колонтитуле, которое обычно предостерегает, что "…хорошо было бы Вам использовать режим Windows Authentication, чтобы избежать этой проблемы…" (перефразировано, конечно). Использование режима Windows Only исключает приблизительно 95% проблем безопасности SQL Server, которые автор встречал, включая известные вирусы. Для хакера, чтобы проникнуть через вашу систему безопасности использующую режим Windows Only, необходимо сначала пройти подтверждение подлинности в домене, что является гораздо более трудной задачей, чем прохождение идентификации SQL. Что является наиболее важным, так это то, что пароли не передаются по сети, так как SQL Server будет использовать маркер пользователя. Продумайте использование учетной записи sa Старайтесь никогда не использовать учётную запись sa, даже
если Вы являетесь администратором баз данных (DBA). Если Вы
DBA и не можете использовать Windows Authentication, создайте
новую учётную запись системного администратора и используёте в
последствии только её. Многим это может не понравиться,
поскольку Вы измените пароль sa для всех рабочих серверов. Но,
тем не менее, этот пароль необходимо изменить и он не должен
быть известен разработчикам. Многие разработчики, зная пароль
sa, кодируют его в своих приложениях, так как эта учетная
запись имеет максимальные разрешения, после чего им не нужно
беспокоиться о правах своего приложения. Удалите BUILTIN/Administrators Автор статьи считает на сегодняшний день это самой большой уязвимостью SQL Server. Он не может понять, для каких целей Microsoft по умолчанию предоставляет администраторам NT права равные sa. Первое, что автор делает после новой инсталляции - удаление этого логина. Будьте осторожны! Перед удалением этого логина, Вы должны убедиться, что учетная запись, от имени которой запускается SQL Server, имеет свой собственный логин. Если у SQL Server нет логина для учетной записи NT, от имени которой стартует SQL Server, наверняка Вы будете иметь проблемы с запуском SQL Server или SQL Server AGENT. Измените учетную запись, от имени которой стартует MSSQLServer По тем же причинам, автор считает целесообразным заменять
учетную запись Localsystem, от имени которой по умолчанию
стартует SQL Server. Если Вы собираетесь сделать это через
Enterprise Manager (щёлкните правой кнопкой мыши по имени
сервера и выберете пункт Properties | вкладка Security), Вы
будете избавлены от необходимость выполнить несколько
дополнительных шагов по предоставлению необходимых разрешений
альтернативной учетной записи, которые ЕМ сделает за Вас.
Когда вы измените учетную запись, под которой запускается SQL
сервер, убедитесь, что она имеет минимальные права на вашем
компьютере (ни в коем случае не обладает правами
администратора!). Основная причина, по которой эти права
должны быть минималными - не позволить злоумышленнику получить
полный контроль над операционной системой, если он сможет
получить права SysAdmin. Проверка Failed Logins и Denied Access Наилучший способ выявления попыток несанкционированного
доступа в систему - это правильная установка оповещения и
предупреждения. Установкой опции Failed Login (Server
Properties | Security tab), вы предоставите себе возможность
видеть, когда незваный гость пытался получить доступ к вашей
системе. Это особенно полезно, если у вас есть стандартная
прикладная программа, которая использует только несколько
учетных записей. Как только вы обнаруживаете любой failed
login, вы знаете, что он вызван не вашей прикладной программой
и, следовательно, это должен быть пользователь. Следующим
шагом является запуск Profiler и выявление Failed Logins и
Hostname. Это даст вам имя компьютера, с которого
производилась попытка несанкционированного
доступа. -- Error Message #229: %ls permission denied on object
'%.*ls', database '%.*ls', owner '%.*ls'. Если вы являетесь злоумышленником и хотите скрыть ваши действия на SQL сервере, то наилучшим способом для этого является перезапись всех журналов ошибок на SQL сервере с помощью утилиты DBCC ERRORLOG пять раз, таким образом заметая все следы вашего там пребывания. Для защиты против этого я рекомендую добавить registry key (если он еще не существует), который увеличит число хранящихся на SQL сервере журналов ошибок с 5 до по крайней мере 10. Для этого внесите следующую строку в Registry: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer] "NumErrorLogs"=dword:00000010 И в заключение, подумайте над тем, чтобы регулярно проверять логины, у которых отсутствует пароль. Вы можете делать это с помощью простого запроса (имейте ввиду, что учетная запись Windows никогда не хранит пароль, следовательно вы можете отфильтровать эти записи используя параметр isntname = 0). use master Следите за появлением новых Service Packs и Hot Fixes Своевременная установка последних Service Packs и Hot Fixes
является лучшим путем для защиты от наиболее опытных
злоумышленников. Большинством из известных мне уязвимых мест,
которые были исправлены с помощью Service Packs и Hot Fixes,
очень тяжело воспользоваться, но если ними воспользовались, то
это очень опасно. Всегда планируйте установку на вашем SQL
сервере, по крайней мере один раз в квартал, всех последних
Service Packs и Hot Fixes. Оперативно получать уведомления о
выходе сервисных пакетов и заплаток можно подписавшись на
Microsoft Security Alerts по адресу: Защищайте расширенные хранимые процедуры SQL сервер предоставляет ряд дополнительных удобств и поддерживает расширенные хранимые процедуры. Единственной проблемой является то, что эти хранимые процедуры обладают теми же правами, что и учетная запись, под которой стартует SQL сервер. Если вы не используете репликацию или SQL Mail, то запускайте SQL сервер под системной учетной записью. Далее вы можете заблокировать все хранимые процедуры, которыми вы практически не пользуетесь. В особенности такие расширенные хранимые процедуры, как xp_cmdshell. Эта расширенная хранимая процедура позволяет выполнить любую команду операционной системы и может косвенно использоваться для доступа в вашу сеть. Несмотря на это, автор не хотел бы удалять ни одну из этих хранимых процедур. Enterprise Manager обычно использует их для доступа к функциям системного уровня и удаление этих хранимых процедур может привести к возникновению новых ошибок. Автор статьи предпочитает запретить доступ к ним от имени любой учетной записи, для которой они без надобности и, если только если вы чувствуете, что всё достаточно хорошо проверили, то можете их удалить. Измените порт, через который работает SQL сервер, и заблокируйте его Если вы измените порт SQL сервера, то злоумышленнику потребуется несколько больше времени для сканирования портов и обнаружения вашего SQL сервера. Большинство неквалифицированных злоумышленников прекратят попытки сканирования вашей сети после проверки общеизвестных портов. Однако для защиты от более опытных взломщиков, вы должны быть уверенны в том, что ваш firewall защищает ваш SQL сервер от любого не установленного траффика. Вы можете изменить порт вашего SQL сервера, воспользовавшись утилитой Server Network Configuration, выбрав протокол TCP/IP и затем Properties для него. Заранее согласуйте новый адрес порта с вашим системным администратором, чтобы он был доступен через ваш firewall. Предоставляйте доступ к БД посредством хранимых процедур Всегда старайтесь не предоставлять прямой доступ к вашим данным. Вместо этого используйте доступ к данным только через хранимые процедуры и предоставляйте права доступа процедурам вместо того, чтобы огульно раздавать права db_datareader и db_datawriter. Если вы используете хранимые процедуры, убедитесь что вы правильно запрограммировали ADO для работы с ними. Это поможет вам защититься от SQL Injection атак. SQL Injection атаки позволяют злоумышленнику выполнить любую SQL команду, которую он пожелает, используя формы (для ввода информации) вашего приложения. Еще одним преимуществом использования хранимых процедур является то, что их легче использовать. Например, если вы не используете хранимые процедуры, то вам придется перекомпилировать ваше приложение или обновлять ASP страницы каждый раз, когда вы изменяете текст запроса. Защищайте вашу операционную систему Если ваша ОС не защищена, то ваш SQL сервер открыт настежь. Это как запереть дверь и оставить рядом с ней открытыми окна. Не забудьте протестировать вашу систему после выполнения всех рекомендаций и делайте это как можно чаще! Документируйте все, что вы сделали, и когда вы будете устанавливать новый сервер, вы ничего не забудете. Автор надеется, что эта статья дает некоторые базовые знания для того, чтобы начать устанавливать систему защиты вашего SQL сервера. |
Редакция: Александра Гладченко 2002г. |