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

Защита информации — вопрос комплексный, предусматривающий решение следующих задач:

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

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

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

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

Первый набор относится к семейству GXA (Global XML Web Services Architecture). Набор включает в себя спецификации серии WS-*: WS-Security, WS-Trust, WS-SecureConversation, WS-Federation и WS-Policy, решающих в целом вопросы обеспечения конфиденциальности, целостности и аутентичности сообщений транспортного протокола SOAP, а также описывающие процессы установления доверительных отношений между субъектами обмена на основе различных политик.

Второй набор состоит из группы открытых разработок OASIS, поддерживаемых компаниями Sun Microsystems и Oracle: SAML (Security Assertion Markup Language) и XACML (eXtensible Access Control Markup Language). SAML — стандарт, основанный на XML, описывающий процесс обмена параметрами аутентификации и авторизации в рамках домена безопасности между поставщиком идентификации (генератор утверждений) и провайдером сервиса (потребитель утверждений). Основная задача, которую решает стандарт, создание нормативной базы для средств однократной регистрации пользователей (Single Sign-On, SSO). XACML — стандарт, определяющий XML-формат описания политики безопасности, включающей набор правил разграничения доступа к объектам, которые могут быть описаны средствами этого же протокола.

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

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

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

Рис. 1. Прямой и косвенный доступ пользователей к информационным ресурсам

 

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

ESB в системах со строго доказуемой безопасностью

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

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

Для реализации первого требования предназначен широкий класс систем управления идентификацией (Identity Management), представляющих собой единую консоль управления, которая позволяет объединять различные системы хранения данных, например СУБД и сервисы каталогов.

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

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

Интеграция ресурсов на основе «ИВК Юпитер. IM»

Интеграционная платформа «ИВК Юпитер» представляет собой защищенную реализацию промежуточного программного обеспечения, ориентированного на передачу сообщений (Message-oriented Middleware, MOM), являющегося основой для построения SOA. Основные функции МОМ «ИВК Юпитер»: гарантированное доведение информации между участниками обмена в информационных системах, наличие синхронного и асинхронного режимов обмена данными, прозрачная система адресации. Система является сертифицированным средством защиты информации и работает в ИС, обрабатывающих информацию до уровня 1Б включительно (по РД ФСТЭК РФ). Важным шагом на пути решения задачи интеграции систем защиты, встроенных в различные прикладные программные средства и установки корреляции между их контекстами безопасности, является разработка в 2007 году программного продукта «ИВК Юпитер. Identity Manager».

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

«ИВК Юпитер. IM» поддерживает следующие варианты интеграции с различным общесистемным и специальным программным обеспечением:

  • для Web-приложений (тонкий клиент) обеспечена возможность передачи идентификационных параметров через URL (Basic Authentication) и через формы (Form Authentication);
  • для исполняемых приложений («толстый» клиент) предоставляется прикладной программный интерфейс, позволяющий запрашивать значения требуемых для авторизации пользователя параметров;
  • для случаев, когда передача параметров перечисленными способами невозможна (например, для «унаследованных» программных систем, в которые невозможно внести изменения для реализации функциональных вызовов API «ИВК Юпитер. IM»), предусмотрена возможность эмуляции действий пользователя.

«ИВК Юпитер. IM» является высокоуровневым дополнением к базовой составляющей решения ИВК для управления идентификацией и аутентификацией должностных лиц информационной системы, встроенной в МОМ «ИВК Юпитер» (рис. 2). Система предоставляет администраторам средство управления доступом должностных лиц к прикладной части информационной системы. Продукт позволяет уменьшить затраты времени на выполнение администраторами таких задач, как создание, изменение и удаление учетных записей, и обеспечивает единообразное применение политик безопасности по всей информационной системе на основе шаблонного (рангового, группового) подхода. «ИВК Юпитер. IM» позволяет установить процессы добавления и удаления прикладных задач, по сути дела, в единое окно должностных лиц информационной системы с учетом необходимых настроек по доступу. Единое окно должностных лиц — набор сервисов для подключения к прикладному ресурсу, уже содержащий все настройки, необходимые для защищенного доступа. Создав должностное лицо со всеми необходимыми его учетными записями, «ИВК Юпитер. IM» осуществляет контроль и управление профилем каждого должностного лица в части доступа к приложениям информационной системы, реализуя принцип однократной регистрации (Single Sign-On, SSO), что позволяет снизить число паролей, которые необходимо не только помнить должностным лицам, но и поддерживать их (то есть периодически обновлять). При этом в качестве средства аутентификации используется МОМ «ИВК Юпитер». Сегодня «ИВК Юпитер» предоставляет различные варианты систем авторизации, в том числе с использованием персональных физических идентификаторов, таких как Aladdin e-Token.

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

В связи с тем что передача идентификационных параметров в подсистемы происходит прозрачно для пользователей, «ИВК Юпитер. IM» можно рассматривать как сервер безопасности прикладного уровня, обеспечивающий разграничение доступа пользователей к приложениям и реализованный на седьмом уровне транспортной модели OSI/ISO. При этом запрещение доступа обеспечивается за счет того, что должностные лица не обладают информацией о своих идентификационных параметрах в конкретных подсистемах. Очевидно, к контролируемым приложениям предъявляются только два требования: наличие механизма авторизации и возможность интеграции с «ИВК Юпитер. IM».

В качестве средства хранения идентификационных параметров используется стандартная СУБД, в том числе Oracle, а также защищенное хранилище данных, встроенное в «ИВК Юпитер», что полностью отвечает требованиям для хранения ключевой информации. В качестве среды функционирования «ИВК Юпитер. IM» может быть произвольная операционная среда, на которой функционирует сам комплекс «ИВК Юпитер» и приложения, зарегистрированные в нем.

«ИВК Юпитер. IM» представляет собой клиент-серверное приложение. Сервер обеспечивает хранение идентификационных параметров и выдачу их по запросу клиентов и совмещается с сервером безопасности «ИВК Юпитер». Клиент «ИВК Юпитер. IM» — приложение, которое запускается автоматически после успешной авторизации должностного лица в магистрали «ИВК Юпитер». Взаимодействие между клиентом и сервером происходит посредством защищенной среды передачи данных «ИВК Юпитер», осуществляющей гарантированное доведение произвольной, в том числе учетной и ключевой, информации и взаимодействия с разнородными удостоверяющими центрами, сертификатами которых должны быть подписаны отправления конкретных приложений. Автоматизированное подписание необходимым сертификатом, хранящимся в хранилище «ИВК Юпитер», всего трафика для каждого выделенного приложения — новая особенность функционирования разнородных информационных систем, включающих в себя разнородные приложения, связанные с различными удостоверяющими центрами.

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

Валерий Андреев, Олег Лекшин  ({andreev,lekshin}@ivk.ru)  — сотрудники компании ИВК (Москва).

«ИВК Юпитер»: реализация корпоративной политики безопасности