Пример анализа безопасности Веб-сервисов

Методические подходы к анализу безопасности

Обзор

Подобно политикам, которые могут быть высокоуровневыми или крайне детализированными, анализ риска может быть осуществлен с различными степенями детализации. В настоящем подпункте предоставлено обсуждение высоких уровней веб-сервисов, новой технологии, которая имеет значение для многих компаний, предоставляющих финансовые услуги, и других компаний, использующих Интернет для бизнеса. Данный пример анализа является иллюстративным и не должен рассматриваться в качестве конкретной рекомендации для обеспечения безопасности. Как отмечается на протяжении всего данного примера, каждая организация должна составить свое собственное определение риска и безопасности на основе своих конкретных политик и потребностей бизнеса.

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

Основными компонентами веб-сервисов являются:

- сервер приложений, где размещается сервис (т.е. где функционирует ПО сервера);

- интерфейс сервиса (часто описываемый на языке веб-сервисов, WSDL);

- хранилище данных или справочник с описанием интерфейса на WSDL, чтобы клиенты веб-сервисов могли найти (и использовать) интерфейс;

- клиент веб-сервиса, желающий использовать веб-сервис;

- протокол связи (простой протокол доступа к объектам, то есть SOAP), позволяющий клиенту веб-сервиса общаться с сервисом.

Существует большое число "определений" того, что составляет веб-сервис, но обычно общепринятым определением является информационная услуга, раскрывающая информацию через SOAP стандарта W3C [20]. Клиент интерфейса SOAP должен знать, как получить доступ к этим информационным услугам. Данный доступ может описываться в формате другого стандарта W3C, языка описания веб-сервисов (WSDL). Создатели сервисов на базе SOAP публикуют файлы WSDL.

 Безопасность веб-сервисов

При обеспечении безопасности веб-сервисов необходимо рассматривать сервер приложений, поддерживающий сервис, описание сервиса, хранилище сервиса, клиента, использующего сервис, и протокол связи. Различными поставщиками была разработана структура безопасности веб-сервисов и ряд спецификаций. Кроме того, можно использовать универсальное решение проблемы веб-безопасности SSL для обеспечения частичной безопасности веб-сервисов. В настоящем подпункте обсуждаются дополнительные подробности обеспечения безопасности веб-сервисов.

Стандарты безопасности

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

Язык разметки систем гарантированной безопасности (SAML) определяет основанную на языке XML структуру обмена информацией по обеспечению безопасности, выраженной в виде утверждений в отношении логической единицы, имеющей тождество в некотором домене безопасности. Эти утверждения передаются в сообщениях запроса и ответных сообщениях на SAML. Обмен информацией по обеспечению безопасности происходит в форме утверждений на SAML, в которых могут передаваться подробности о предыдущих событиях аутентификации, атрибутах человеческих или компьютерных субъектов и решениях о санкционировании, разрешающих или запрещающих субъекту доступ к компьютерным ресурсам. Развитие SAML тщательно контролируется промышленностью, так как в перспективе он может стать стандартным средством передачи регистрационной информации для веб-сервисов, основанных на SOAP. В настоящее время у SAML существует описание SOAP.

Безопасность веб-сервисов представляет собой предлагаемую совокупность расширений SOAP, благодаря которой для операций веб-сервисов обеспечивается целостность и конфиденциальность. Целью безопасности веб-сервисов является обеспечение целостности и конфиденциальности посредством распространения маркеров доступа, целостности и конфиденциальности сообщений. Предлагаемая компаниями Microsoft и IBM безопасность веб-сервисов и ответственность перешла к OASIS (организации по продвижению стандартов для структурированной информации).

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

Подпись на языке XML является проектом рекомендации объединенной группы IETF (проблемной группы проектирования Интернет) и W3C по представлению информации о цифровой подписи в документах на языке XML. Подписи на языке XML обеспечивают целостность, аутентификацию сообщения и/или услуги по аутентификации подписавшего лица для данных любого типа, расположенных в XML, включающем в себя подпись, или в другом месте. Подпись на языке XML является основным стандартом, на который дается ссылка в других стандартах безопасности, включая шифрование на языке XML, SAML и WS-Security.

Liberty Alliance Project является промышленным консорциумом, возглавляемым крупными фирмами, предназначенным для совместного открытого использования технологий интегрированной идентичности. Интегрированная идентичность позволяет потребителю использовать отдельную признанную идентичность во многих организациях. Этот потребитель может использовать ту же доверенную информацию об идентичности в группе различных организаций, и этому потребителю не надо представлять новую идентичность, мандаты идентификации собственности.

Распределение ключей на XML - это спецификация протокола W3C для описания и регистрации открытых ключей, которая может использоваться со спецификациями подписи и шифрования на XML. Распределение ключей на XML является версией спецификации 2. Инструментальные средства для распределения ключей имеются у различных поставщиков.

 Стандарты веб-сервисов

Обзор

Стандарты для веб-сервисов постоянно совершенствуются. Тремя главными процедурами, дополняющими основные стандарты операций SOAP, являются: обнаружение сервисов, обеспечение безопасности и бизнес-процесс. Основным стандартом поиска сервисов служит UDDI (универсальная система предметного описания и интеграции), описывающая, как центральное хранилище файлов WSDL в открытом или частном исполнении позволяет пользователям находить и активизировать сервисы. Существует большое число используемых стандартов безопасности для обеспечения услуг по определению подлинности, шифрованию, подписанию и утверждению на уровне пользователя и сообщения. Стандарты бизнес-процесса связаны с ответом на вопрос: "Как я объединяю сервисы для создания целостного полезного процесса вместо элементарных функций?"

 Внедрение

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

                                    │    ┌────────┐

                                    │    │Клиент/ │

                                    ├────┤сервис 3│

┌──────────────┐                    │    │  (S3)  │

│ ┌──────────┐ │          Внутренняя││   └────────┘   │

│ │Веб-сервис│ │             сеть   │.   ┌────────┐   .

│ │  (WS1)   │ │                    ││┌─┐│Клиент/ │┌─┐│          ┌────────┐

│ └─────────┬┘ │                    ├┼┤C├┤сервис 4├┤D├┼──────────┤Интернет│

│           │  │                    ││└─┘│  (S4)  │└─┘│          └────────┘

│           │  │                    │.   └────────┘   .             ┌─┐

│           │  │                    ││Демилитари-     │Демилитари-  │E│

│           │  │┌────────┐          │ зованная зона    зованная зона└┬┘

│           │  ││Клиент/ │          │                                │

│        ┌──┴─┐││сервис 2│         ┌┴┐                           ┌───┴────┐

│Машина 1│ IP │││  (S2)  │         │B│                           │Клиент/ │

└────────┴──┬─┴┘└───┬────┘         └┬┘                           │сервис 5│

            │ ┌─┐   │               │                            │  (S5)  │

            └─┤A├───┴───────────────┤                            └────────┘

              └─┘                   │

Рисунок B.1. Общая модель веб-сервисов

Возможно, что клиент S2 расположен на ближайшей сетевой шине, в том же информационном центре, что и WS1. Клиент S3 также находится во внутренней сети компании, но может быть гораздо дальше, например, в филиале в другом городе или в другой стране. Клиент S4 находится в демилитаризованной зоне, соединенной с Интернетом, и имеет определенный уровень связи с Интернетом и внутренней сетью компании. Наконец, клиентам Интернета, таким как S5, возможен доступ к внутреннему сервису типа WS1.

Обеспечение безопасности

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

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

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

Анализ угроз

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

Решения

Решения по требованиям обеспечения безопасности веб-сервиса WS1 могут различаться в зависимости от клиентов, запрашивающих обслуживание. Рассмотрим случай, когда WS1 поддерживает только клиентов, подобных S2, которые расположены физически близко к WS1. В этом случае клиент и сервис расположены близко друг к другу, и возможность несанкционированных запросов на обслуживание может быть сведена к минимуму посредством таблиц маршрутизации, виртуальных локальных сетей, внутренних межсетевых экранов между сегментами сети или других методов. Предполагая, что WS1 и S2 достаточно защищены от внешних связей, логично предположить, что конфиденциальность данных и аутентификация паролей основываются просто на их изоляции от остального мира.

По мере удаления клиента от веб-сервиса WS1 сложности возрастают. Между клиентом S3 и веб-сервисом WS1 запросы на обслуживание проходят по более широкой сети, открывая больше возможностей проверки запросов и больше точек, где может быть создан и введен несанкционированный запрос. Таким образом, между клиентом S3 и веб-сервисом WS1 требуется дополнительная защита. Как описывалось ранее, это может быть либо аутентификация на основе сертификатов, либо IPSEC между аппаратными средствами клиента S3 и аппаратными средствами веб-сервиса WS1.

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

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

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

Существуют также другие концепции обеспечения безопасности веб-сервисов. Функционирование между клиентом и сервером часто бывает критически важным. Устранение отказа, резервирование, восстановление и вопросы, возникающие при непредвиденных обстоятельствах, могут сделать некоторые контрмеры более привлекательными. Инструментальные средства разработки веб-сервисов, имеющиеся в различных компаниях, обеспечивают различные виды поддержки стандартов SSL и стандартов безопасности веб-сервисов; конкретное инструментальное средство может не поддержать повторное использование SSL-сеанса на основе сертификатов. Поскольку сервер приложений может обладать различными возможностями по отношению к стандартным инструментальным средствам, результаты могут различаться.