Приложение В (справочное). Управление и проблемы безопасности

Приложение В
(справочное)

Управление и проблемы безопасности

В.1 Общие положения

В настоящем приложении подробно рассмотрены вопросы сквозного управления и безопасности и предоставляется контекст и дополнительная информация относительно управления транзакциями, надежности службы, безопасности SOA и руководства безопасностью SOA.

Управление и безопасность поддерживают нефункциональные требования, являющиеся ключевой особенностью/задачей SOA, и указывают те точки, на которых должно фокусироваться каждое решение. Это дает гарантию того, что SOA будет соответствовать требованиям мониторинга, надежности, доступности, управляемости, транзакционности, пригодности для обслуживания, масштабируемости, информационной безопасности, эксплуатационной безопасности, жизненного цикла и т.д. Управление и безопасность относятся к той же области применения, что и традиционные аспекты (отказ, конфигурация, учет, производительность, безопасность) из справочника лучших практик ITIL или три базовых фактора "надежность, доступность, удобство обслуживания" (RAS - reliability, accessibility, serviceability). Необходимо поддерживать три важных аспекта управления и безопасности - управление транзакциями, доступность и надежность службы.

В.2 Управление транзакциями

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

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

Транзакции состоят из двух типов транзакций, созданных по стандартам Веб-служб, а именно стандарт WS-Coordination (см. [25]), который является основой для WS-AtomicTransaction (см. [26]), и WS-Business Activity (см. [27]):

- атомарные транзакции. Атомарные транзакции происходят при построении компонентов служб, требующих непротиворечивого соглашения о результатах недолгих распределенных действий с семантикой "действие либо выполняется полностью, либо не выполняется совсем". Атомарная транзакция требует таких свойств, как атомарность, непротиворечивость, изоляция и длительность (ACID - atomicity, consistency, isolation and durability), и таким образом поддерживает блокировку измененных ресурсов до сохранения или отмены этих изменений. Результатом службы будет либо успешное изменение всех ресурсов, координированных службой, либо восстановление состояния, которое существовало перед взаимодействием службы;

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

В.3 Доступность

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

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

Доступность службы часто является ключевой метрикой в соглашении об уровне обслуживания, политиках и контрактах.

В.4 Надежность службы

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

При разработке службы ключевым принципом является понятие идемпотентности. Если служба является идемпотентной, это означает, что одинаковые копии обращения к службе (например, путем повторений) приведут к одинаковому результату. Другими словами, достигается идентичный результат независимо от того, происходит запрос однократно либо повторяется несколько раз. Любые операции, не изменяющие состояние (чтение/получение), по определению являются идемпотентными. Чтобы произвести действие, изменяющее состояние, требуется тщательная разработка идемпотентной системы для обеспечения одинакового результата при одинаковых обращениях (запросах). При невозможности разработки идемпотентной службы к надежности задаются другие требования, например "доставка без дублирования сообщений с возможностью потери" и "гарантированная доставка".

Системы могут предоставлять четыре качества надежности:

- без потери с дублированием: запрос отправлен один раз, но есть вероятность доставки копий. К этой семантике подходят идемпотентные операции;

- с потерями без дублирования: запрос отправлен однократно, при этом не разрешается отправлять любые копии, поскольку эффект двойного запроса приводит к неправильному поведению, например повторному списанию денег с банковского счета. Если не удается отправить запрос, нет риска для корректного поведения службы;

- без потерь без дублирования: запрос отправлен однократно, и его не разрешается размножать или дублировать. Потеря запроса может представлять риск для корректного поведения службы. Другими словами, должны быть предприняты все разумные попытки, чтобы отправить запрос исключительно однократно;

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

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

В.5 Управление SOA

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

- мониторинг и управление ИТ-системами: обеспечивает мониторинг и управление инфраструктурой ИТ и системами, включая возможность отслеживать и собирать данные метрик и состояния ИТ-систем и инфраструктуры, что также подразумевает управление виртуализированными системами;

- мониторинг и управление приложениями и решениями SOA: обеспечивает мониторинг и управление программным обеспечением служб и приложением, что включает возможность собирать данные метрик, отслеживать и управлять состоянием решения и приложения;

- мониторинг и управление деловой активностью: обеспечивает мониторинг и управление деловой активностью и бизнес-процессами, что дает возможность анализировать информацию о событиях в режиме реального времени/почти реального времени, а также информацию о сохраненных событиях, рассматривать и проводить оценку деловой активности в форме информации о событии, а также определять ответы и предупреждения/уведомления о проблемах;

- управление безопасностью: управляет и отслеживает безопасность и защищенные решения, что дает возможность управлять ролями и идентификационными данными, правами доступа и наделением правами; защищать неструктурированные и структурированные данные от несанкционированного доступа и потери данных; рассматривать, как разрабатывается и сохраняется программное обеспечение системы и службы на протяжении всего жизненного цикла программного обеспечения; поддерживать состояние безопасности через превентивные изменения, реагирующие на идентифицированные уязвимости и новые угрозы, позволяя ИТ-организации управлять рисками, связанными с ИТ, соответствовать и обеспечивать основание для автоматизации управления безопасностью;

- управление событиями: обеспечивает возможность управления событиями; включает в себя обработку событий, ведение журнала и аудит;

- управление конфигурацией и управление изменениями: данная категория дает возможность изменять конфигурацию и описание решения и службы;

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

- управление жизненным циклом: обеспечивает механизм для развертывания, запуска/включения, остановки/отключения и удаления служб и решения SOA.

Кроме того, руководство SOA и службами используют управление для фактического выполнения и применения политики и процессов управления. Эти политики управления вместе с другими политиками в системе (безопасности, надежности, доступности и т.д.) являются теми правилами, которые формируют системы управления.

В.6 Службы управления

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

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

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

В.7 Управление метаданными службы

В окружениях SOA важно обеспечить возможность управления дополнительными метаданными службы и физическими документами, такими как описания служб и политик, связанных со службами. Реестры и репозитории включают эти возможности. Такая функциональность необходима как дополнение к обнаружению служб.

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

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

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

Существуют также другие описания, которые могут потребоваться наряду с пониманием доменов служб, интеграции (или шины предприятия) и федерации служб.

В.8 Безопасность SOA

Безопасность SOA рассматривает защиту от угроз в контексте уязвимостей сервис-ориентированной архитектуры; это - защита взаимодействий между потребителями службы и поставщиками службы, а также защита всех элементов, которые участвуют в архитектуре.

Подход, используемый для безопасности SOA, должен следовать лучшим образцам передового опыта в этой отрасли, таким как рекомендация Х.805, разработанная ITU-T, и аспекты, описанные в серии стандартов WS-Security (см. [28]).

Ниже приведены угрозы, которые должна рассматривать безопасность SOA:

- разрушение (атака на доступность): разрушение информации и/или ресурсов, и/или компонентов, к которым получен доступ через службы или которые связаны со службами или жизненным циклом служб;

- повреждение (атака на целостность): несанкционированное вмешательство в актив, доступ к которому получен через службы, или актив связан со службами или жизненным циклом служб;

- удаление (атака на доступность): кража, удаление или потеря информации и/или других ресурсов, влияющих на службы;

- раскрытие (атака на конфиденциальность): несанкционированный доступ к активу или службе;

- прерывание (атака на доступность): прерывание службы. Служба становится недоступной или непригодной для использования.

Для защиты от перечисленных угроз необходимы восемь аспектов безопасности:

a) управление доступом: ограничение и управление доступом к службам и элементам, с использованием маркеров, компонентов и элементов: пароль, списки управления доступом, брандмауэр;

b) аутентификация: предоставление идентификационных данных для использования служб или любых компонентов SOA. Например, общий секрет, инфраструктура открытых ключей или цифровые подписи. Нужно отметить, что, поскольку SOA определяет взаимодействие между потребителями служб и поставщиками служб, подтверждение идентификационных данных должно выполняться между исходным потребителем и окончательным поставщиком службы. В хореографии служб используются различные агенты, и, возможно, аутентификация потребуется для всех. При аспекте, которым должен управлять SOA, когда службы предоставляются двумя или несколькими организациями, существует риск, что из-за подключения и отключения агентов среда станет трудноуправляемой. Поэтому обычно в SOA используются интегрированные идентификационные данные, основанные на распространении маркеров, которые обеспечивают непротиворечивую аутентификацию начальной запрашивающей стороны посредством доверенного протокола между компонентами и реализуют доверенную модель аутентификации. В качестве примера может служить WS-Federation (см. [29]);

c) неотказуемость: предотвращение возможности отказаться от факта выполнения действия в компонентах или элементах сервис-ориентированной архитектуры. Примеры: системные журналы и цифровые подписи, защищающие сообщения посредством ХМL-Signature. В хореографии служб взаимодействуют множество агентов, и может потребоваться поддержка трассировки всех действий от всех агентов;

d) конфиденциальность данных: гарантия конфиденциальности обмена данными при взаимодействии служб или управлении компонентами архитектуры. Чтобы избежать нежелательных разглашений, вероятно, потребуется обеспечить сквозную конфиденциальность между начальным потребителем службы и окончательным поставщиком службы. Пример: защита сообщения с использованием шифрования XML-Encryption;

e) коммуникационная безопасность: гарантия того, что информация исходит только из ожидаемого источника к ожидаемому месту назначения. Примеры: использование HTTPS, VPN, MPLS, L2TP. В архитектуре SOA на границе компонентов могут потребоваться проверки уровня приложения или решения для контроля адресов источников и точек назначения входящих и исходящих сообщений;

f) целостность данных: гарантия того, что полученные данные тождественны отправленным после всех взаимодействий между компонентами службы, будь то данные для управления SOA или целей жизненного цикла либо для взаимодействий между потребителями службы и поставщиками. Примеры: цифровая подпись XML-Signature, антивирусное программное обеспечение. Обработка подписи XML должна происходить только на конце взаимодействия службы, чтобы избежать нарушения целостности на различных узлах, которые могут составлять архитектуру между потребителем и поставщиком службы;

g) доступность: гарантия того, что элементы, службы и компоненты доступны законным пользователям. Данный аспект должен быть скоординирован с SLA и другими метаданными контракта, которые определяют условия использования службы;

h) персональные данные: гарантия того, что идентификация, использование и управление службой не разглашаются.

В.9 Руководство безопасностью SOA

Руководство безопасностью SOA - это специализированный домен руководства, который связан с безопасностью SOA.

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

Инфраструктура политики безопасности: руководство безопасностью SOA определяет и реализует компоненты, которые администрируют политику безопасности, ее распространение и преобразование надлежащих компонентов SOA и элементов, решение политики безопасности и компонентов осуществления и наконец компонентов, которые отслеживают и сообщают об использовании политики безопасности и соответствии.

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

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