Интегрированное управление защитой информации в слабо связанных информационных системах.

Возможности и перспективы

Олег Лекшин,
Валерии Андреев

Защита информации - вопрос комплексный

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

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

• идентификация клиента (пользователя либо агента) в системе;
• проверка прав доступа к защищаемым данным в рамках общезначимого (системного) контекста безопасности;
• шифрование трафика между клиентами и сервисами И С;
• обеспечение целостности данных.

Группы стандартов Web-сервисов

На сегодняшний день многие вопросы защиты информации в слабо связанных ИС достаточно хорошо проработаны. Технология Web-сервисов, которая в настоящее время является, по сути, единственной общепризнанной реализацией SOA, почти полностью стандартизована, в том числе и по вопросам защиты информации. Существует несколько наборов спецификаций, описывающих, каким образом решать перечисленные выше задачи применительно к Web-сервисам. Первый набор относится к семейству GXA (Global XML Web Services Architecture) и включает в себя спецификации серии WS-*. Второй набор состоит из группы стандартов SAML (Security Assertion Markup Language) и XACML (extensible Access Control Markup Language), разработанных OASIS и поддерживаемых Sun Microsystems и Oracle.

Перечисленные стандарты решают две базовые задачи:

1. Создание доверенной среды обмена данными, обеспечивающей гарантию конфиденциальности, целостности и аутентичности передаваемой информации.
2. Распространение единого контекста безопасности в слабо связанной вычислительной среде при однократной аутентификации пользователя (Single Sign-On, SSO).

Проблема строгого доказательства безопасности в SOA

Упомянутые стандартизованные решения не закрывают всех вопросов управления правилами разграничения доступа (ПРД) в слабо связанных системах. Можно сказать, что в целом решена лишь задача управления доступом к приложениям (сервисам) и специфическим для этих приложений информационным объектам - вторичным информационным ресурсам. Однако в общем случае такие информационные объекты сами по себе являются результатом сложных преобразований данных, полученных от низкоуровневых первичных ресурсов, таких как файлы и базы данных и, возможно, какие-либо другие информационные источники. Подобные преобразования по своей сути являются описанием бизнес-логики приложения. Независимо от свойств принятой в ИС модели ПРД к вторичным ресурсам невозможно говорить о строгом доказательстве безопасности И С без формального доказательства того, что реализация соответствует заданной информационной модели.

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

Напомним, что в ИС со строго доказуемой безопасностью должны применяться такие системы управления ПРД, для которых математически доказано, что пользователь не может повысить свой уровень доступа, не имея на это прав. Иногда строгого доказательства безопасности И С не требуется. К таким системам можно отнести ИС с вероятностной моделью информационной безопасности (ИБ), в которых реализовано управление рисками И Б на основе успешных практик.

Однако существуют системы, в которых критичность обрабатываемой информации настолько высока, что на всех уровнях функционирования И С требуется максимальная эффективность соответствующих средств защиты. В первую очередь это относится к сведениям, составляющим государственную тайну РФ, а также некоторые виды информации ограниченного доступа, например персональные данные. При создании таких систем, даже при условии применения сертифицированных интеграционных технологий и архитектур, требуется проводить не только доказательство отсутствия в прикладных задачах недекларированных возможностей, но и доказательство строгого соответствия их заявленных свойств информационной модели системы. Тогда при обеспечении строгого доказательства безопасности системы вне зависимости от ее информационной модели и конкретного воплощения в сервисах можно существенно снизить требования по безопасности к прикладному уровню. Для решения задачи в такой постановке еще предстоит провести серьезную проработку модели ИБ в слабо связанных информационных системах.

Центральный элемент в SOA - корпоративная сервисная шина (Enterprise Service Bus, ESB) или магистраль

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

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

1. Реализация системы управления ПРД, охватывающей все базовые средства доступа к первичным и вторичным информационным ресурсам из единого центра управления, в рамках унифицированной расширяемой модели управления ПРД. Кроме того, необходимо обеспечить синхронизацию учетных данных пользователей ("наследование" уровня доступа) в ESB и подключенных к ней системах.
2. Обеспечение выполнения любого процесса доступа к данным в контексте безопасности, связанным с пользователем, инициировавшим этот процесс, независимо от того, является ли он локальным или удаленным по отношению к самому пользователю ("виртуализация" пользователя).

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

"ИВК Юпитер™"

В компании ИВК много лет проводятся исследования в области защиты информации в трехуровневой архитектуре, а также ведется разработка прикладных SOA-решений на базе продукта "ИВК Юпитер™".

"ИВК Юпитер™" (как базовая интеграционная платформа) - это защищенная реализация промежуточного программного обеспечения, ориентированного на передачу сообщений (Message-oriented Middleware, MOM), являющегося основой для построения ESB. Среди основных функций MOM "ИВК Юпитер™" отметим гарантированное доведение, наличие синхронного и асинхронного режимов обмена данными, прозрачную систему адресации. "ИВК Юпитер™" также является сертифицированным средством защиты информации (СЗИ). Наличие сертификации позволяет работать в ИС, обрабатывающих сведения, составляющие государственную тайну (до уровня "совершенно секретно").

"ИВК Юпитер™ Identity Manager"

Важным шагом на пути решения задачи интеграции систем защиты, встроенных в различные прикладные программные средства, и установления корреляции между их контекстами безопасности является начатая в 2007 г. разработка нового программного продукта - "ИВК Юпитер™ Identity Manager" ("ИВК Юпитер™ IM").

"ИВК Юпитер™ IM" является средством централизованного хранения и управления идентификационными параметрами (ИП), необходимыми для авторизации пользователей в различных прикладных подсистемах. В качестве ИП могут использоваться любые данные - логины, пароли, ключи, сертификаты и т.п. Передача ИП в подсистему, к которой пользователю необходимо получить доступ, производится автоматически. "ИВК Юпитер™ IM" поддерживает следующие варианты интеграции с различным общесистемным и специальным программным обеспечением (ОПО и СПО):

• для Web-приложений ("тонкий" клиент) обеспечена возможность передачи ИП через URL (Basic Authentication) и через формы (Form Authentication);
• для исполняемых приложений ("толстый" клиент) предоставляется программный интерфейс (API);
• для случаев, когда передача ИП указанными выше способами невозможна (например, для "унаследованного" ПО, в код которого невозможно внести изменения), предусмотрена возможность эмуляции действий пользователя.

"ИВК Юпитер™ IM" реализует SSO, при этом в качестве средства аутентификации используется MOM "ИВК Юпитер™". Отметим, что в настоящее время программный продукт "ИВК Юпитер™" предоставляет различные варианты систем аутентификации, в том числе с использованием персональных физических идентификаторов, таких как Aladdin e-Token.

В "ИВК Юпитер™ IM" также реализована важная возможность отслеживания состояния пользовательских сессий во взаимодействующих с ним приложениях и завершения этих сессий при выходе должностного лица из основной контролирующей системы - "ИВК Юпитер™".

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

В качестве средства хранения ИП "ИВК Юпитер™ IM" может использовать стандартные СУБД, в том числе Oracle, а также защищенное хранилище данных, встроенное в сам "ИВК Юпитер™".

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

В настоящее время завершаются работы по интеграции систем разграничения доступа "ИВК Юпитер™ IM" и ключевого общесистемного ПО -СУБД (Oracle и т.п.), Microsoft Active Directory и LDAP. Решение этих задач обеспечит возможность построения на базе продуктов "ИВК Юпитер™" и "ИВК Юпитер™ IM" полноценной системы интегрированного управления политикой безопасности во всей информационной системе и в ее прикладных компонентах.