Источник: pcweek/re #21, 11 июня 2002Тимоти Дик
Предпринимателя должна беспокоить любая система, которая в ответ на полученный извне запрос автоматически извлекает и передает критичные для бизнеса данные. Когда же речь идет о Web-сервисах, это справедливо вдвойне: к ним нужно относиться так же осторожно, как к дикому зверю.
В целом eWeek Labs рекомендует первопроходцам развертывать Web-сервисы постепенно. Это особенно важно, если нужно обеспечить внешний доступ к таким услугам, так как инфраструктура безопасности для них все еще отсутствует.
Одна из основных проблем в этой области связана с тем, что при разработке стандарта SOAP I.I (Simple Object Access Protocol - простой протокол доступа к объектам) практически не уделялось никакого внимания вопросам безопасности.
В разделе 8 заметок консорциума Всемирной паутины под названием "Вопросы безопасности" (с ними можно ознакомиться по адресу:www.w3.org/TR/SOAP)отмечено: "Настоящий документ не описывает методов защиты целостности и конфиденциальности информации. Эти вопросы будут рассматриваться в последующих его версиях".
Очередная версия этого протокола, SOAP 1.2, уже разрабатывается, однако белые пятна остаются и в ней.
Именно такие упущения привели к разнобою в защите уже развернутых библиотек Web-сервисов. Более того, некоторые из них на сегодняшний день вообще не предлагают никаких средств обеспечения безопасности, так как это не требуется спецификацией SOAP.
Проблемы безопасности нельзя откладывать на перспективу. Когда появляется бизнес-необходимость, подразделение ИТ должно создать или найти технологию, которая сможет удовлетворить новую потребность, в том числе в защите своей организации и ее партнеров. Сейчас многие фирмы остро нуждаются в Web-сервисах, предлагающих уникальное сочетание функциональной совместимости, доступности и простоты. Именно они должны лечь в основу будущих сетей связи между компаниями.
| 1. Принимайте только те входящие запросы, которые поступают по VPN, - это обеспечит безопасность на транспортном уровне. | Защита Web-сервисов | 2. Проверяйте, от кого поступил запрос на Web-сервис, используя для этого аутентификацию силами Web-сервера. |
| 3. Конфигурируйте Web-сервер и разрешения на доступ к файлам ОС так, чтобы доступ к Web-сервису могли получить только те, кому это позволено. | 4. Ограничьте доступ Web-сервиса к базам данных так, чтобы он мог обращаться лишь к отдельным (действительно необходимым ему) колонкам и столбцам таблицы. |
Обеспечить их безопасность можно даже сейчас, несмотря на незрелость нынешних стандартов, но для этого придется приложить большие усилия. Надо сказать, что по крайней мере в текущем году организациям придется заниматься заказным кодированием намного больше, чем им хотелось бы.
На сегодняшний день имеется единственный более-менее простой способ безопасного развертывания Web-сервисов: упаковать их в защищенный транспортный протокол.
В обозримом будущем самое широкое распространение, видимо, должна получить HTTPS, шифрованная версия протокола HTTP, дополненная встроенной технологией аутентификации (это может быть, например, справочная аутентификация Digest Authentication).
Впрочем, простой протокол HTTP обладает "врожденной" несовместимостью с изощренными потребностями бизнеса и поэтому даже в версии HTTPS едва ли сможет удовлетворять всем требованиям.
Обеспечить их безопасность можно даже сейчас, несмотря на незрелость нынешних стандартов, но для этого придется приложить большие усилия. Надо сказать, что по крайней мере в текущем году организациям придется заниматься заказным кодированием намного больше, чем им хотелось бы по защищенности Web-сервисов. Его активно применяют лишь благодаря той универсальной поддержке, которую эта технология уже получила в продуктах и услугах.
HTTPS хорош для "внутреннего употребления". Что же касается его использования за пределами компании, особенно при развертывании наиболее критичных услуг, то в этом случае лучше применять системы управления очередями сообщений наподобие MQSeries корпорации IBM или Windows Message Queuing (функцию Windows 2000 Server) компании Microsoft. Обе системы гарантируют доставку даже через общедоступный Интернет; кроме того, они дополнены функциями аутентификации пользователей, шифрования, подтверждения получения сообщений и аудита. Короче говоря, две эти системы обладают функциями безопасности, которых так не хватает SOAP.
В качестве другого варианта организации внешней связи рекомендуем оказание конфиденциальных Web-услуг только сетям VPN (виртуальные частные сети) на основе протокола IPSec, проложенным между головной организацией и ее деловыми партнерами. В сочетании с аутентификацией пользователей на Web-сервере такой подход обеспечивает полную изоляцию сетевого трафика при надежной аутентификации и шифровании (данные SOAP пересылаются в виде легко перехватываемых текстовых последовательностей, поэтому шифрование транспортного протокола приобретает здесь особое значение).
Для реализации Web-сервисов на Web-серверах используются скрипты или компилированные программы, запускаемые в ответ на соответствующие запросы HTTP. Благодаря этому защитить их можно сравнительно просто с помощью стандартных средств управления доступом к файлам, которые имеются во всех основных ПО построения Web-серверов. Применение подобных систем безопасности обеспечивает аутентификацию пользователей еще до того, как их запрос дойдет до исполняемого кода самого Web-сервиса.
Правда, зависимость SOAP от HTTP привела к унаследованию таких слабых мест этого протокола, как невозможность регистрации состояния соединения и отсутствие гарантий доставки.
Не предоставляет HTTP никакой информации и о ведущихся переговорах между клиентом и сервером, что значительно затрудняет развертывание Web-сервисов, которые требуют не одного, а двух отдельных сообщений от деловых партнеров.
Если, например, данные аутентификации пользователя на Web-сервере не используются, вызывающий абонент вынужден включать их в каждый запрос SOAP, дополняя его, скажем, именем пользователя и паролем.
В настоящее время уже ведется разработка важных стандартов, содержащих полное описание инфраструктуры безопасности Web-сервисов на основе XML. Однако все эти проекты находятся пока на ранней стадии, поэтому в ближайшие месяцы их практической реализации ожидать не приходится.
К числу основных можно отнести три таких проекта, за развитием которых мы рекомендуем внимательно следить. Стандарт XML-Signature Syntax and Processing ("Синтаксис и обработка подписей XML") консорциума Всемирной паутины (12 февраля нынешнего года он обрел статус рекомендации W3C) определяет порядок подписи, проверки целостности и верификации отправителя XML-сообщений. Стандарт этого же консорциума XML Encryption Syntax and Processing ("Синтаксис и обработка шифрования XML"), имеющий статус рабочего проекта W3C, обеспечит шифрование XML-данных, а его же спецификация XML Key Management ("Управление ключами XML"), также находящаяся на стадии рабочего проекта, предложит XML-интерфейс подключения к инфраструктуре открытых ключей.
И все же какой бы стойкостью ни обладала инфраструктура, ее безопасность со временем может быть скомпрометирована, а размеры ущерба при этом зависят от того, насколько защищена конфигурация всей системы.
Как и в случае с любыми исходными текстами, доступными внешним пользователям, при разработке программ Web-сервисов необходимо применять методы защищенного кодирования. Обязательно проверяйте существование, диапазон и логику всех пересылаемых параметров еще до их использования. Запускайте Web-сервер или механизм сценариев, с помощью которых исполняется код, только с ограниченной учетной записью операционной системы. Опираясь на средства контроля доступа к базе данных, открывайте доступ только к тому ее подмножеству, что необходимо для оказания конкретной Web-услуги.
С техническим директором филиала eWeek на Западном побережье США Тимоти Диком можно связаться по адресу timothy_dyck@ziffdavis. corn