(Возврат на основную страницу)

Содержание номера за Март 2004 год

Editorial

Защищаем SQL Server 2000

Джим Рапоза (Jim Rapoza)

Несмотря на то, что червь Blaster и вирус Sobig собрали львиную долю внимания и страхов в 2002 году, год 2003 начался с появления червя, доставившего много головной боли администраторам SQL Server корпорации Microsoft. Червь SQL Slammer, использующий известную и уже «залатанную» дыру в SQL Server 2000, выводил из строя серверы и ставил на колени целые сети.

В ряде испытаний, проведенных недавно лабораторией eWEEK Labs, система SQL Server, на которой не была установлена нужная заплата, заражалась червем менее чем за 10 минут. Однако (что удивительно), через год после того, как SQL Slammer впервые предпринял атаку, в Интернете продолжает существовать множество уязвимых и необновленных систем SQL Server.

Для защиты SQL Server необходимо:

·        постоянно получать новые пакеты обновления;

·        изолировать новые или необновленные системы SQL Server до тех пор, пока не будет обеспечена их безопасность;

·        проводить тестирование заплаток в режиме отключения от сети;

·        использовать строгий, регулярно изменяемый пароль sa и, если это позволяют приложения, аутентификацию Windows;

·        блокировать порты, на которых SQL Server прослушивает соединения;

·        использовать инструменты для оценки уязвимостей и управления обновлениями;

·        обеспечить безопасность приложений, подключенных к SQL Server;

·        проверять множество ресурсов для информации по SQL Server.

Ясно, что до многих еще не дошла мысль о необходимости установить заплату, обеспечивая тем самым безопасность SQL Server 2000.

Осложняет эту проблему и тот факт, что MSDE 2000 (Microsoft SQL Server 2000 Desktop Engine), также уязвимый для SQL Slammer, зачастую устанавливается как часть приложений сторонних производителей.

Нет причин для того, чтобы ситуация была так тяжела. И хотя требуется быть бдительным, находясь в курсе ваших потенциально уязвимых точек и знать, где находятся все ваши реализации MSDE и SQL Server, все же организация защиты SQL Server — это не стратегическая оборонная инициатива.

Первый и самый очевидный шаг в обеспечении безопасности SQL Server — постоянно получать пакеты обновлений для SQL Server 2000. Все последние пакеты обновлений исправляют уязвимые места, атакуемые SQL Slammer, также как и ряд других потенциально опасных проблем безопасности.

Кроме того, мы рекомендуем следующее: ИТ-менеджеры, имеющие дело с новой системой SQL Server или системой, на которой не установлены необходимые «заплаты» (patches), должны отключить ее от сети или поместить в изолированную сеть. Если этого не сделать, то, учитывая высокую скорость атак Slammer, любой ИТ-персонал обречен на заражение системы в ходе установки на нее требуемых обновлений.

Также это дает возможность протестировать «заплату» в изолированном режиме, чтобы убедиться, что ее установка не окажется пагубной для ваших приложений.

Помимо SQL Slammer, слабо защищенная реализация SQL Server также упрощает злоумышленникам взлом приложений и баз данных и доступ к секретной информации. Одна из распространенных ошибок заключается в плохо организованной или вовсе отсутствующей процедуре авторизованного доступа. Не раз мы были ошарашены, встречая систему SQL Server с пустым паролем для учетной записи sa (системного администратора). Мы рекомендуем использовать сложный, постоянно меняющийся пароль для sa и, если приложение позволяет, применять аутентификацию Windows.

Другим общепринятым шагом, необходимым для обеспечения безопасности SQL Server, является блокирование портов, на которых он слушает соединения, а именно порта 1433 протокола TCP и порта 1434 протокола UDP (User Datagram Protocol). Если системы, которым необходимо подключение к SQL Server, будут единственными способными сделать это, вы будете более защищены от возможных неизвестных проблем.

Конечно же, применение продуманной системы безопасности в целом способно значительно обезопасить SQL Server. Использование приложений, проверяющих уязвимость, и средств управления обновлениями также может помочь IT-менеджерам в выявлении уязвимых систем, особенно встроенных экземпляров MSDE.

К тому же все приложения, подключенные к базе данных SQL Server, должны быть защищены от обычных ошибок и программ, использующих уязвимости. Если в ваших приложениях полно дыр, то обеспечение безопасности SQL Server вас не спасет.

И наконец, важно улучшать свои познания по SQL Server. Есть отличные книги, описывающие мельчайшие детали в конфигурировании и обеспечении безопасности SQL Server и серверных систем Windows.

Хорошей идеей является постоянная проверка веб-форумов разработчиков Microsoft, работающих с SQL Server, где обычно можно найти информацию по недавно выявленным проблемам, а также по дополнительной отладке и настройкам, способным сделать SQL Server более защищенными.

Programming

Выходим за пределы простой передачи журналов: мощная утилита резервирования на T-SQL

Линчи Шиа (Linchi Shea)

Большинство предприятий, полагающихся на высокую доступность своих приложений, работающих на SQL Server, для поддержки резервного сервера используют передачу журналов (log shipping). К сожалению, эти решения (как правило, довольно слабые) выполняют восстановление не достаточно изящно и, кроме того, вторгаются на основной сервер. Намучившись с необходимостью «нянчить» операции передачи журналов в своей фирме, Линчи Шиа создал мощную утилиту для SQL Server — TSQLStandby, использующую системные таблицы SQL Server 2000 для резервного копирования и восстановления.

Поддержка резервного SQL Server в той или иной степени касается всех. Фактически после 11 сентября 2001 года многие компании больше не довольствуются одними только резервными копиями на магнитной ленте — они требуют наличия отдельного восстановительного узла, на который можно быстро переключиться в случае необходимости.

Передача журналов в различных ее воплощениях является наиболее распространенной техникой, используемой для реализации резервного сервера. К сожалению, все опубликованные реализации передачи журналов в SQL Server (включая встроенную в SQL Server 2000 функцию передачи журналов) в той или иной степени страдают следующими недостатками.

• Они передают только резервные копии журнала. Однако, в некоторых случаях, базы данных (далее БД) могут быть настроены на режим простого восстановления (simple recovery mode) и, следовательно, не иметь резервных копий журнала. Но в целях создания узла восстановления необходимо поддерживать эти БД на резервном сервере. Даже если БД настроена на режим полного восстановления (full recovery mode), ее можно использовать для передачи резервных копий БД до тех пор, пока эти резервные копии не станут слишком большими, чтобы их можно было передавать по сети.

• Обычно организация переноса журналов накладывает специальные требования относительно того, как должно выполняться резервное копирование на основном сервере. Эти требования делают основной сервер мерее гибким для управления. Например, вы не можете просто выполнить резервное копирование БД или журнала на другой дисковый накопитель, даже если ваш первоначально сконфигурированный резервный дисковый накопитель окажется переполненным, поскольку резервное копирование БД или журнала вне процесса настроенной передачи журналов в большинстве реализаций, если не во всех, приведет к сбою передачи журналов.

• Обычно они по расписанию выполняют резервное копирование журнала, копируют резервный файл журнала, а затем восстанавливают его в едином процессе, все последующие шаги которого зависят от предыдущих. Если шаг по копированию файла не будет выполнен, то не состоится и восстановление, поэтому вся последовательность попыток передачи журналов будет неудачной до тех пор, пока эта проблема не будет решена, что, как правило, требует вмешательства оператора.

• Эти реализации передачи журналов слишком слабы, чтобы противостоять любым внешним неисправностям, таким как сетевые сбои или незапланированные отключения питания сервера. Если подобное событие уничтожит задание, выполненное лишь наполовину, то приложение не будет знать, откуда начинать работу восстановления сети или питания.

• На резервном сервере требуется проявлять осторожность и не восстанавливать БД, не уделив должного внимания настройке передачи журналов. Вы не можете просто загрузить весь набор БД и предоставить возможность процессу передачи журналов синхронизовать все восстановленные журналы автоматически. Также нельзя вручную восстановить резервную копию журнала на резервном сервере — эти реализации не переходят автоматически к следующей резервной копии журнала.

Основная причина этих проблем в том, что в подобных реализациях средство передачи журналов либо не помнит, где находится нужный файл, либо не использует всех преимуществ информации о состоянии резервного копирования/восстановления, хранимой на SQL Server.

Помня об этих недостатках, я разработал и реализовал утилиту для резервирования TSQLStandby, исходя из следующих наблюдений и предпосылок.

• SQL Server хранит информацию о каждой операции резервного копирования или восстановления, включающую (среди прочего) имя БД, дату начала резервного копирования (или восстановления), дату окончания резервного копирования, тип резервного копирования и физический файл резервной копии. История резервного копирования или восстановления сохраняется в нескольких системных таблицах, включая такие, как backupset, restorehistory и backupmediafamily в БД msdb.

• Подобным образом можно записать и сохранить информацию о состоянии копирования каждой БД или файла резервной копии в пользовательскую таблицу, тем самым поддерживая историю копирования резервных файлов.

• Определяя разницу между историей резервного копирования и историей копирования резервных файлов, можно установить, какой резервный файл должен быть скопирован следующим для каждой БД.

• Определяя разницу между историей копирования и историей восстановления, можно точно установить, какой файл должен быть восстановлен следующим для каждой БД, независимо от того, какие действия по восстановлению уже могли быть выполнены на резервном сервере.

• Кроме того, можно поддерживать всю информацию о состоянии на резервном сервере, определяя, что нужно копировать, а что восстанавливать, а также осуществлять фактическое копирование и восстановление файла полностью с резервного сервера без обращения к основному серверу.

• И, в заключение, с помощью T-SQL всего этого без труда можно добиться на резервном сервере, так как резервная информация о состоянии полностью содержится в таблицах на резервном сервере и логика определения, что копировать или восстанавливать следующим, главным образом вовлекает сравнение именно этих таблиц.

Обработка ошибок в SQL Server: предпосылки. Часть 2*

Эрланд Соммарског (Erland Sommarskog)

*См. Эрланд Соммарског. Обработка ошибок в SQL Server: предпосылки. Часть1 // SQL Server для профессионалов. 2004. №2

Реализация обработки ошибок в хранимых процедурах. Часть 1

Эрланд Соммарског (Erland Sommarskog)

Это вторая из двух статей, посвященных обработке ошибок в SQL Server. В ней содержатся рекомендации, как реализовать обработку ошибок при написании хранимых процедур, включая случаи их вызова из ADO. Предыдущая статья «Обработка ошибок в SQL Server: предпосылки»[1] дает углубленное описание индивидуальных отличительных особенностей обработки ошибок в SQL Server и ADO.

Обработка ошибок в хранимых процедурах является очень утомительной задачей, поскольку T-SQL не предлагает механизм обработки исключительных ситуаций или какой-либо On Error Goto. Все, что у вас есть, — это глобальная переменная @@error, которую необходимо проверять после выполнения каждого оператора, чтобы убедиться в ее ненулевом значении. При вызове хранимой процедуры вам также потребуется проверить возвращаемое этой процедурой значение.Это в высшей степени утомительно, поскольку вы столкнетесь с тем, что нужно идти на компромиссы и в некоторых случаях притворяться, что все идет хорошо.

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

Я выделяю наиболее важные моменты материала предыдущей статьи, чтобы вы знали, исходя из каких предположений требуется работать. Далее, я приведу общий пример, содержащий наиболее важные части обработки ошибок, сопровождая их специальными рассуждениями, относящимися к вызову хранимых процедур. Затем перейду к разделу, в котором буду обсуждать некоторые философские вопросы реализации обработки ошибок; если вы ограничены по времени, то можете пропустить его. Тем не менее, я рекомендовал бы прочесть раздел «Когда вы должны проверять @@error». Я рассмотрю SET XACT_ABORT ON, позволяющий упростить обработку ошибок, но не настолько, как вы, возможно, надеялись. Затем перейду к обработке ошибок в четырех особых областях: курсорах, триггерах, пользовательских функциях и динамическом SQL. И в заключение, рассмотрю обработку ошибок в клиентских приложениях, а точнее в ADO.

Для экономии места я займусь хранимыми процедурами, выполняемыми как часть какого-либо приложения. Я не включил сюда несвязанные SQL-операторы, посылаемые клиентами, и пренебрег административными сценариями, вроде сценариев для резервного копирования или сценариев, создающих или изменяющих таблицы. Не рассматривал я ни распределенные транзакции, ни использование оператора SAVE TRANSACTION.

Я не обсуждаю различные версии SQL Server. Эти рекомендации основаны на работе в среде SQL Server 2000, но в равной степени они применимы и к SQL 7.0, и к SQL 6.5. (На самом деле, ситуация в SQL 6.5 несколько проще, но поскольку вы, скорее всего, планируете переход на SQL 7 или SQL 2000, то можете сразу же написать вашу обработку ошибок также и для этих версий.) Следующая версия SQL Server под кодовым названием Yukon вводит новую конструкцию TRY-CATCH, упрощающую реализацию обработки ошибок. Поскольку Yukon продолжает оставаться на стадии раннего бета-тестирования, еще не время детально обсуждать эту конструкцию. Впрочем, в предыдущей статье есть раздел, дающий краткий обзор TRY-CATCH.

(Возврат на основную страницу)