Безопасность SOA 1-2-3, Часть 1

В данной серии статей читателю предлагается план реализации системы безопасности для сервис-ориентированной архитектуры (Service-Oriented Architecture, SOA). В этой статье, первой из трех статей серии, описывается процедура из 10 шагов, которая будет полезной на любом этапе - от формирования рабочей группы по безопасности SOA-приложения до создания эффективной процедуры сбора требований. В части 2 вы узнаете, как создать высокоуровневый проект, а в части 3 описываются контрольные примеры.

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

В итоге я создал свой план. Я разработал простую процедуру из 10 шагов, которая и предлагается в данной статье.

Шаг 1. Сформируйте оптимальную рабочую группу

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

Руководителем рабочей группы по безопасности должен быть человек, разбирающийся как в вопросах безопасности, так и в архитектуре программного обеспечения, предпочтительно, в SOA. Разработчик архитектуры обеспечения корпоративной безопасности (security enterprise architect, SEA), как и разработчик корпоративной архитектуры, отвечает за создание общей модели безопасности SOA-приложения, предназначенной для интеграции различных требований к обеспечению безопасности на любом уровне детализации. SEA входит в состав совета управления SOA, совместно с разработчиком корпоративной архитектуры (enterprise architect, EA) работает над обеспечением соответствия всех SOA-реализаций требованиям безопасности и возглавляет группу бизнес-аналитиков в сфере безопасности (security business analysts, SBAs) и инженеров систем обеспечения безопасности (security systems engineers, SSEs), отвечающих за создание артефактов, необходимых на протяжении всего процесса. Специалист SEA, кроме того, отвечает за работу с программистами, обеспечивающими написание кода сервисов безопасности и тестировщиками систем, обеспечивающими проведение тестирования систем до их развертывания.

Шаг 2. Составьте детализированный план проекта

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

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

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

Шаг 3. Ведите таблицу решений по безопасности для процесса внедрения SOA

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

• Приложения, которые будут входить в архитектуру SOA;
• Приложения, которым необходимо взаимодействовать с SOA-приложениями;
• Приложения, которые не будут входить в SOA или взаимодействовать с SOA-приложениями.

Каждой отдельной категории для наглядности хорошо присвоить определенный цвет. Например, я обозначил объекты в первой категории красным, во второй - оранжевым, а в третьей категории - желтым цветом.

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

В таблице 1 показан пример таблицы решений по безопасности для процесса внедрения SOA.

Таблица 1. Таблица решений по безопасности для процесса внедрения SOA

Из этой таблицы видно, что 12 приложений не будут входить в архитектуру SOA ("желтые" приложения); следовательно, в данном случае необходимы разные модели обеспечения безопасности, а именно: одна модель для обеспечения безопасности части системы, построенной на SOA, и еще одна модель, которая будет обеспечивать безопасность не входящих в SOA частей системы. Как правило, модели, построенные не на-SOA, основываются на так называемой защите периметра, при которой информационные ресурсы защищают посредством уровня межсетевых экранов.

Для системы безопасности, построенной на SOA, начните с создания инфраструктуры управления рисками, как описано в шаге 4.

Шаг 4. Создайте проект с использованием принципа инфраструктуры управления рисками

На этом этапе используется принцип "безопасности изнутри". "Безопасность изнутри " означает, что оценка безопасности должна быть одинаковой для всех деятельностей в реализации SOA. Необходимо разобраться в том, как будет работать реализация SOA (путем просмотра проектной документации), отметить, в каких моментах необходимо решение по безопасности, и идентифицировать контрольные точки безопасности, в которых эти решения будут реализованы.

Мы используем механизмы для принятия этих политик безопасности и применим их, возложив их выполнение на приложения, сервисы безопасности SOA-приложения и, по мере необходимости, на SOA-компоненты. Необходимо решить вопрос об инкапсуляции или декомпозиции требований по безопасности в набор сервисов безопасности, которые будут действовать в любой точке SOA-реализации. Так, например, можно возложить задачу аутентификации пользователей на сервис безопасности Authentication Security Service, обращаться к которому и взаимодействовать с которым придется всем приложениям. И наоборот, можно сконфигурировать сервисную шину предприятия (enterprise service bus, ESB) на ограничение доступа к отдельным сообщениям по типу "приложение за приложением". (Подробнее об этом читайте в части 2.)

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

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

В очень полезной книге Гэри Мак-Гроу (Gary McGraw) (см. раздел Ресурсы) подробно описывается процедура из пяти частей, которая может помочь в создании инфраструктуры управления рисками (risk-management framework, RMF). Если коротко, вы должны:

• Добиться понимания бизнес-контекста;
• Идентифицировать бизнес-риски и технические риски;
• Смоделировать и классифицировать риски;
• Определить стратегию снижения рисков;
• Внести исправления и проверить.

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

Шаг 5. Определите заинтересованных лиц внутри организации ("своих") и за ее пределами (сторонних)

Разобравшись в этих принципах, можно перейти к шагу 5. На этом этапе группа по безопасности SOA-приложения идентифицирует и выделяет заинтересованных в безопасности SOA-приложения лиц. Эти заинтересованные лица делятся на две категории: сторонние и "свои" заинтересованные лица. Сторонние руководящие органы, принимающие решения, например, Северо-Американская корпорация по вопросам надежности энергоснабжения (North American Electric Reliability Corporation, NERC) могут иметь определенные стандарты безопасности электронного пространства, такие как требования защиты критически важных инфраструктур ( Critical Infrastructure Protection, CIP), имеющие явные последствия для реализаций систем безопасности.

CIP охватывает такие разные области, как Security Management Controls (Элементы управления безопасностью) (CIP-003-1), Electronic Security Perimeter(s) (Электронный периметр безопасности) (CIP-005-1), Physical Security of Critical Cyber Assets (Физическая безопасность критически важных электронных ресурсов) (CIP-006-1), Systems Security Management (Управление безопасностью систем) (CIP-007-1), Incident Reporting and Response Planning (Создание отчетов об инцидентах и планирование реагирования) (CIP-008-1) и Recovery Plans for Critical Cyber Assets (Планы аварийного восстановления для критически важных электронных ресурсов) (CIP-009-1). Все эти стандарты формируют свои наборы специфических требований, которые влияют на общую реализацию безопасности SOA-приложения.

Кроме того, внутренние требования к безопасности, которые часто называют стандартами безопасности последовательности операций (Security Standard Operating Procedures, SOP), отвечают на все вопросы кто, что, где, когда и как в отношении безопасности. Кому и к чему разрешен доступ, когда и где, каким образом и как долго? Во многих организациях эта информация по своей сути изменяется с течением времени и становится неорганизованной и несогласованной; SOA-реализация часто требует значительной работы по созданию систематического документа, который точно отражал бы политики безопасности данной организации.

Шаг 6. Правильно выберите и используйте инструменты для сбора требований

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

Хорошо продуманные требования к безопасности и аналитические методы существенно понизят риски для безопасности системы. Инструменты определения и анализа требований IBM® Rational® хорошо подходят для понимания и представления потребностей заинтересованных лиц, ведения и координации коллекции и верификации потребностей потребителей и бизнеса, документирования и организации требований к системе, а также для ознакомления с требованиями каждого члена рабочей группы. Я использовал в работе и рекомендую вам такие инструменты, как IBM Rational RequisitePro®, WebSphere® Business Modeler и Rational Software Architect.

Шаг 7. При реализации безопасности SOA-приложения придерживайтесь схемы процесса SDLC

Учитывая огромный объем информации, который необходимо собрать, количество архитектурных артефактов, которые необходимо написать, и конкретные сервисы безопасности SOA-приложения, которые необходимо спроектировать, рабочей группе по безопасности SOA-приложения следует придерживаться стандартной схемы процедуры Жизненный цикл разработки программного обеспечения (Software Development Life Cycle, SDLC):

1. Идентификация требований к безопасности и ограничений;
2. Выявление и сбор требований к безопасности системы;
3. Создание безопасного архитектурного проекта;
4. Документация детализированного безопасного проекта SOA;
5. Реализация SOA (включая управление SOA);
6. Тестирование;
7. Размещение;
8. Обслуживание.

На первый взгляд эти шаги могут показаться очевидными, но рабочие группы по безопасности редко соблюдают схему SDLC. Они не привыкли сидеть в кабинетах и выписывать на классной доске детализированные требования; разрабатывать высокоуровневые проекты безопасности и создавать контрольные примеры, подтверждающие, что системы действительно безопасны. (Высокоуровневые проекты и контрольные примеры описываются в частях 2 и 3 данной серии статей.)

Прежде чем рабочая группа приступит к разработке решений, она должна собрать требования к системам. Существуют как явные, так и неявные требования к реализациям обеспечения безопасности. Что касается явных требований, хорошей стартовой точкой будет сбор требований от каждого из заинтересованных лиц, о которых говорилось в пункте 5. В отношении неявных требований к безопасности полезно использовать инфраструктуры обеспечения безопасности, например, триаду конфиденциальность, целостность и отслеживаемость (confidentiality, integrity, and accountability, CIA); с учетом которой составляется список конкретных требований ко всем системам безопасности. Триада CIA представляет собой широко используемую модель гарантирования информации (information assurance, IA), которая определяет конфиденциальность, целостность и доступность как основополагающие характеристики безопасности всех информационных систем.

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

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

Кроме того, одним из требований безопасности SOA-приложения является своевременный и надежный доступ к сервисам данных для авторизованных пользователей (доступность). SOA-реализации должны гарантировать, что эти ресурсы или информация будут доступны, когда в них возникнет необходимость; это означает, что доступ к ресурсам может быть осуществлен на скорости, достаточной для того, чтобы удаленная система могла выполнить свою задачу предписанным образом. Безусловно, возможны случаи, когда меры по защите конфиденциальности и целостности приняты, но атакующий тем не менее может сделать ресурсы менее доступными, чем требуется, или вообще недоступными. В частности, когда в качестве брокера сообщений используются компоненты SOA-системы, такие как ESB, то для обеспечения ее доступности и надежности необходимо указать в документации требований к безопасности SOA-приложения, что необходимо использовать протоколы высокой доступности, сетевые архитектуры с резервированием и аппаратное обеспечение системы, не имеющей ни одной одиночной точки отказа. Рабочая группа по безопасности SOA-приложения должна обеспечить всеобъемлющее выявление всех указанных областей и гарантировать, что соответствующие контрольные примеры будут задокументированы и смогут проиллюстрировать определенные требования.

Шаг 8. Найдите готовые модели и учитесь на их примере

После того как рабочая группа по безопасности SOA-приложения уделила некоторое время обсуждению всех описанных требований, члены группы должны выяснить, нельзя ли выполнить их при помощи инструментов сторонних производителей. Они должны написать программы сервисов безопасности SOA, которые будут удовлетворять конкретным требованиям. Чтобы не изобретать колесо, лучше и полезнее ознакомиться с уже имеющимися моделями и узнать, какие разработки уже были сделаны до того, как данная рабочая группа перешла к этапу высокоуровневого проектирования. Здесь, на 8 этапе процедуры, я рекомендую обратить внимание на следующие модели от компании Intelligrid (см. раздел Ресурсы). Ниже представлен список и описание обычно используемых служебных сервисов, которые могут пригодиться вам в SOA-реализации. Более подробно об этих сервисах мы поговорим в следующей статье, здесь я привожу список:

• Сервис аудита общего назначения;
• Сервис авторизации для управления доступом;
• Сервис обеспечения конфиденциальности;
• Сервис конверсии полномочий доступа;
• Сервис возобновления полномочий доступа;
• Сервис делегирования;
• Сервис слежения за периметром межсетевого экрана;
• Сервис установления личности;
• Сервис сопоставления личности;
• Сервис обеспечения информационной целостности;
• Междоменный сервис безопасности;
• Сервис обеспечения невозможности отказа от авторства;
• Сервис маршрутизации и QoS (гарантированного качества обслуживания);
• Сервис настройки политик безопасности;
• Сервис смены политик;
• Сервис обеспечения приватности;
• Сервис для работы с профилем (Сервис пользовательских профилей);
• Сервис обеспечения качества установления личности;
• Сервис защиты от атак отказа в обслуживании (Denial of Service, DoS);
• Сервис управления обеспечением безопасности;
• Сервис согласования протоколов;
• Сервис оценки доступности сервисов безопасности;
• Сервис единого входа в систему;
• Сервис установления доверия.

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

После того как вы выполните описанные действия и соберете достаточно информации, можно перейти к выполнению шага 9, в ходе которого необходимо просмотреть стандарты WS-Security и выяснить, какие из них применимы к вашей конкретной реализации безопасности SOA-приложения. На рисунке 1 представлена схема всех стандартов WS-Security, которые необходимо просмотреть.

Рисунок 1. Стандарты WS-Security

Как только модели станут детализированными, необходимо изучить подробные стандарты безопасности SOA-приложения, входящие в WS-Security, и понять, как они соотносятся друг с другом и с требованиями к модели безопасности SOA-приложения. Эти стандарты безопасности будут использоваться для формирования безопасных сообщений во всей SOA-реализации.

Шаг 10. Разработайте стандарты для сторонних разработчиков.

В заключение, при выполнении шага 10 рабочая группа по безопасности SOA-приложения создает набор стандартов и интерфейсов прикладного программирования (application program interface, API) для сторонних разработчиков. Один из главных коммерческих аргументов SOA заключается в том, что системы, построенные на этой архитектуре, могут использовать свою открытость путем доступа к сервисам, предоставляемым сторонними разработчиками. Каждый разработчик должен хорошо знать стандарты безопасности для SOA-реализаций и иметь ясное представление о том, как его сервисы будут взаимодействовать с сервисами безопасности SOA-реализаций.

На протяжении всего процесса разработки необходимо вести самый подробный глоссарий по терминам безопасности; это позволит обеспечить использование одних и тех же терминов и определений во всех создаваемых документах. Я советую в начале работы использовать глоссарий Oasis Security Services TC Glossary. Этот глоссарий следует использовать совместно со всеми другими разработчиками, чтобы гарантировать единство терминологии.

Заключение

Из данной статьи вы узнали, как за 10 шагов создать план реализации безопасности SOA-приложения:

• Сформировать оптимальную рабочую группу;
• Создать детализированный план проекта;
• Вести таблицу решений по безопасности для процесса внедрения SOA;
• Создать проект использования принципа "безопасность изнутри" и инфраструктуры управления рисками;
• Определить заинтересованных лиц внутри организации ("своих") и за ее пределами (сторонних);
• Правильно выбрать и использовать инструменты для сбора требований;
• При реализации безопасности SOA-приложения придерживаться схемы процесса SDLC;
• Ознакомиться с существующими моделями и учиться на их примере;
• Внимательно изучить стандарты WS-Security;
• Разработать стандарты для сторонних разработчиков.

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