Важное сообщение для партнеров Oracle в области информационной безопасности
Проверена работоспособность лицензионно чистого решения!
Описание проблемы
Российское законодательство (например, Федеральный Закон о Персональных Данных N 152-ФЗ) требует в некоторых случаях обязательного использования Российской криптографии («для ИСПДн 1 класса при многопользовательском режиме обработки ПДн ... должны использоваться сертифицированные средства криптографической защиты»).[1]
При доступе к ИСПДн через Web-интерфейс логично было бы использовать ее для аутентификации пользователей и установки безопасного соединения на HTTP-сервере; но, к сожалению, не для всех систем существует готовая интеграция...
Дело в том, что западные производители программного обеспечения ориентируются на использование криптографии стандарта RSA, в то время как отечественные сертифицированные СКЗИ используют собственные алгоритмы преобразований, такие, как:
- ГОСТ Р 34.10-94 и ГОСТ Р 34.11-94 (генерация ключевой пары, операции создания и проверки X.509 сертификата и для аутентификации клиента),
- ГОСТ 28147-89 (операции шифрования данных и имитозащита для обеспечения конфиденциальности и контроля целостности передаваемой информации),
- ГОСТ Р 34.10-2001 (операции электронной подписи).
В итоге, часто администраторам крупных российских IT-систем приходится дублировать системы обеспечения безопасных подключений и аутентификации. Разумно было бы оптимизировать эти системы, совместив в рамках одного решения защиту гетерогенной Web-среды бизнес-приложений и возможность работы с российской криптографией.
В качестве такого решения мог бы подойти сертифицированный в составе Oracle Identity & Access Management Suite [2] продукт Oracle Access Manager, обеспечивающий аутентификацию (с организацией Web-SSO), авторизацию и аудит обращений пользователей и администраторов к десяткам различных HTTP, Web-серверов и бизнес-приложений.[3]
Российские пользователи классических Web-приложений Oracle (Portal, Collaboration Suite, e-Business Suite и др.) пытались с ними «подружить» ГОСТовую криптографию самостоятельно и с помощью системных интеграторов.
К сожалению, лучшее, чего удалось добиться до сих пор, – это организация защищенного канала связи между клиентом и сервером Oracle AS 10g на уровне TCP/IP соединения с использованием библиотек сертифицированных российских криптопровайдеров (CSP). Аутентификация внутри приложений оставалась прежняя – парольная (или с помощью сертификатов формата RSA при добавлении Oracle SSO сервера).
Попытки решить эту проблему сводились к модификации модуля аутентификации, идущего в составе Oracle HTTP-сервера, что не гарантировало нормальную работу приложения, т.к. при этом нарушалась его целостность (и лицензионная чистота). Кроме того, существовали дополнительные интеграционные ограничения.
Их снял только новый продукт, – Oracle Access Manager (OAM), поддерживающий широкий спектр различных HTTP-серверов на основе свободно распространяемого программного обеспечения. OAM умел передавать идентификатор пользователя как приложениям Oracle, так и Web-приложениям других вендоров; осталось только научить его получать этот идентификатор от системы, понимающей аутентификацию по ГОСТ...
В качестве такой системы мог подойти любой HTTP-сервер Apache со шлюзом (webgate) OAM, дополненый росийскими библиотеками для обеспечения безопасных подключений и аутентификаций по ГОСТ. С лицензионной точки зрения нет никаких проблем для разработчиков и пользователей этих дополнительных библиотек.
В итоге появляется возможность построить универсальную систему, обеспчивающую
- создание защищенных соединений между клиентами и пограничными HTTP-серверами Apache (ГОСТ и не-ГОСТ)
- проверку X.509 сертификатов и аутентификацию клиентов (ГОСТ и не-ГОСТ)
- безопасную передачу идентификатора пользователя, аутентентифицированного по ГОСТ и не-ГОСТ сертификату на Web-сервера бизнес-приложений с организацией Web Single Sign-On, авторизация на защищаемых web-ресурсах по дополнительным факторам, аудит обращений
Описание решения
Выяснилось, что решение компания Digt (ООО «Цифровые технологии»)[4] Trusted TLS[5] прекрасно интегрируется с OAM и справляется с этой задачей, работая в паре с сертифицированным СКЗИ «КриптоПро CSP».[6]
Trusted TLS работает через протоколы TLS/SSL (SSL v.2/v.3 или TLS v.1.0) с помощью средств, предоставляемых библиотекой OpenSSL. Он поставляется в виде специальной сборки сервера Apache.
Модуль mod_digt_tls.so обеспечивает работу по протоколу TLS на ГОСТ-алгоритмах, используя низкоуровневые вызовы функции криптопровайдера КриптоПро. Это означает, что многие российские организации могут получить лицензионно чистое решение по использованию российской криптографии для аутентификации и организации Web-SSO в гетерогенной среде.
Краткий список защищаемых с помощью накладных сертифицированных ФСТЭК решений включает:
- множество Web-приложений, доступ к которым организован через сервера Apache и их модификации от Oracle и IBM, сервера IBM Domino, Microsoft IIS и ISA, Sun JS
- множество Web-приложений, работающих на серверах приложений и порталах Oracle (OC4J через Oracle SSO и WebLogic), IBM WebSphere, Microsoft (Portal и SharePoint), SAP и Plumtree
- приложения Oracle – eBusiness Suite, Siebel, PeopleSoft, iFlex
При своем недавнем обновлении продуктов интеграционного слоя Oracle Fusion Middleware 11g компания подтвердила, что Oracle Access Manager будет являться основным решением для организации SSO для продуктов OFM 11g и всех будущих приложений.[7] Такому выбору способствовала гибкая архитектура решения, в частности, – поддержка разнообразных хранилищ идентификационных данных через Oracle Virtual Directory.
Поэтому мы призываем партнеров Oracle в области информационной безопасности ориентироваться именно на этот продукт, предлагая заказчикам решение для WebSSO.
Рекомендации и поддержка
По информации разработчика, - компаниии Digt, для обеспечения кроссплатформенности конечного решения разработка модуля Trusted TLS ведется на платформах Linux RedHat 7.3/9.0, Solaris 9 Sparc 32, Windows 2000+
Мы все же рекомендуем вам ориентироваться на Windows-платформу, в частности, - на актуальные версии, встречающиеся в вышеупомянутом реестре сертифицированных средств защиты информации ФСТЭК.
КриптоПро CSP поддерживается на Windows 2000/XP/2003/Vista/2008; так что с этим тоже не будет проблем.
Существуют версии Trusted TLS для HTTP-серверов Apache 1.3, Apache 2.0 и Apache 2.2. По вышеуказанной таблице «Oracle Access Manager Certification Information» находим, что поддерживаются следующие шлюзы (Webgates)
- Apache 1.3.x – на платформе Windows 2000 AS SP4 or later SPs & Windows 2003 EE SP1 or later SPs
- Apache 2.0.x – на платформе Windows 2000 AS SP4 or later SPs, Windows 2003 EE SP1 or later SPs, Windows 2008 EE all SPs
- Apache 2.2.x – на платформе Windows 2003 EE SP1 or later SPs & Windows 2008 EE all SPs
Список OID атрибутов сертификата X.509, поддерживаемых OAM, приведен в главе «Настройка аутентификации пользователей» руководства по администрированию Oracle Access Manager:
Пример установки и настройки OVD и OAM можно найти по ссылке:
http://www.oracle.com/technology/obe/fusion_middleware/im1014/ovd-oam/index.htm
По вопросам деталей настройки интеграции между OAM и Trusted TLS просьба обращаться письменно по адресу igor.mineev@oracle.com
[1] http://www.fstec.ru/_spravs/meropriaytiay.doc
[2] См. сертификат ФСТЭК №1664 от 18 августа 2008 г. в реестре сертифицированных средств защиты информации по адресу http://www.fstec.ru/_razd/_serto.htm
[3] См. закладки «Webgates» и «3rdParty Oracle Integrations» в таблице http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle_access_manager_certification_10.1.4_r3_matrix.xls
[4] http://www.digt.ru/company/ или http://www.trusted.ru/company/about/
[5] http://www.trusted.ru/products/trusted-tls/about/
[6] http://www.cryptopro.ru/cryptopro/products/csp/
[7] http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle-access-manager-101430-faq-ext.pdf
Комментариев нет:
Отправить комментарий