Введение
Защита 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, кодируют его в своих приложениях, так как эта учетная запись имеет максимальные разрешения, после чего им не нужно беспокоиться о правах своего приложения.
Как только Вы изменили пароль sa, постарайтесь наладить систему его периодического изменения (например, поставьте себе в Outlook периодическую задачу), это позволит избежать распространения этого пароля по организации. Имейте в виду, что если человек, который знает пароль sa покинет организацию, Вам можете понадобиться несколько часов что бы сменить его на каждом SQL Server. DBA - параноик (подобный автору этой статьи) постоянно задаётся вопросом, сколько SQL серверов находится в сети, о которой он не знает. Для этих целей можно использовать бесплатные утилиты, типа "Электронный Глаз", с помощью которых можно находить функционирующие в вашей сети SQL серверы, у которых 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.
Убедитесь также, что для этой учетной записи опция Logon Locally запрещена. Это гарантирует, что никто не сможет войти в вашу систему под этой учетной записью и прочитать данные с вашего сервера или администрировать его. И последнее, убедитесь что имя учетной записи, под которой теперь запускается SQL сервер, не является информативным для злоумышленника. Не называйте ее, например, SQLAdmin или SQLStartupAccount. Убедитесь, что эта учетная запись выглядит, как обычный пользователь и не бросается в глаза злоумышленнику.
Проверка Failed Logins и Denied Access
Наилучший способ выявления попыток несанкционированного доступа в систему - это правильная установка оповещения и предупреждения. Установкой опции Failed Login (Server Properties | Security tab), вы предоставите себе возможность видеть, когда незваный гость пытался получить доступ к вашей системе. Это особенно полезно, если у вас есть стандартная прикладная программа, которая использует только несколько учетных записей. Как только вы обнаруживаете любой failed login, вы знаете, что он вызван не вашей прикладной программой и, следовательно, это должен быть пользователь. Следующим шагом является запуск Profiler и выявление Failed Logins и Hostname. Это даст вам имя компьютера, с которого производилась попытка несанкционированного доступа.
Использование только таких простых методов аудита дает вам не очень много, до тех пор, пока вы не начнёте по настоящему отслеживать все попытки входа в систему и не установите надлежащую систему сигнализации для немедленного оповещения, когда попытка несанкционированного доступа в систему будет действительно иметь место. Одним из лучших способов для этого является настройка SQL Alerts для генерации оповещений о возникших ошибках и других событиях, в который, например, можно использовать используя команду NET SEND или отправлять письма через e-mail. Автор считает нужным отслеживать любые ошибки типа permission denied, например, такие как #229. Если вы определите для себя все, что вы хотите подвергнуть аудиту, вы можете написать скрипт для изменения таблицы sysmessages (в которой хранятся все ошибки SQL сервера) для включения регистрации, как показано ниже:
-- Error Message #229: %ls permission denied on object '%.*ls', database '%.*ls', owner '%.*ls'.
UPDATE sysmessages SET dlevel = (dlevel | 0x80) WHERE error = 229
Если вы являетесь злоумышленником и хотите скрыть ваши действия на 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
go
select name, password from syslogins where password is null and name is not null and isntname = 0
Следите за появлением новых Cumulative Update
Своевременная установка последних накопительнык пакетов обновлений является лучшим путем для защиты от наиболее опытных злоумышленников. Большинством из известных мне уязвимых мест, которые были исправлены с помощью Cumulative Update, очень тяжело воспользоваться, но если ими воспользовались, то это очень опасно. Всегда планируйте установку на вашем SQL сервере, по крайней мере один раз в квартал, всех последних Cumulative Update. Оперативно получать уведомления о выходе сервисных пакетов и заплаток можно по ссылке: https://mssqlforever.blogspot.com/search/label/Cumulative%20Update
Защищайте расширенные хранимые процедуры
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 сервера.
Комментариев нет:
Отправить комментарий