Страница 4 из 4 Архитектурные особенности Предложенное решение базируется на использовании цифровых сертификатов стандарта X.509 и протокола Secure Sockets Layer (SSL), поддерживающего строгую двухфакторную аутентификацию пользователей СУБД Oracle, а также шифрование информации, передаваемой по сети между сервером БД и клиентской рабочей станцией (рис. 2). При этом задействованы лишь штатные настройки СУБД и клиента Oracle, описанные в документации по Oracle Advanced Security [6]. Установка на рабочей станции сервисов eToken дает возможность применять имеющиеся на ключе сертификаты для аутентификации в СУБД Oracle (cм. врезку "Процедура аутентификации в СУБД Oracle с использованием eToken"). Рис. 2. Архитектура предоставления доступа. Процедура аутентификации в СУБД Oracle с использованием eToken | Этап 1. Установление соединения клиент-сервер - Клиент посылает запрос на установление SSL-соединения.
- Сервер отвечает на запрос посылкой своего сертификата и делает запрос сертификата клиента.
- Клиент проверяет целостность, дату и срок действия сертификата, а также то, что сертификат подписан доверенным издателем.
- В случае подтверждения подлинности сертификата сервера клиент посылает ему собственный сертификат, который пользователь может выбрать из предлагаемого списка.
- Сервер проверяет целостность, дату и срок действия сертификата, а также то, что сертификат клиента подписан доверенным издателем, и при подтверждении подлинности "дает согласие" на обмен данными (в обратном случае - отказ в доступе).
- Клиент и сервер обмениваются ключевой информацией, используя криптографические алгоритмы с открытым ключом. На данной стадии запрашивается авторизация пользователя в eToken (ввод PIN-кода).
- На основании ключевой информации формируется сессионный ключ для шифрования трафика в течение сессии с использованием наилучшего симметричного алгоритма, доступного и для клиента, и для сервера.
- Соединение клиента с сервером установлено.
| Этап 2. Авторизация пользователя сетевыми службами Oracle в БД - В LDAP-каталоге (Oracle Internet Directory) проводится поиск отличительного имени пользователя, соответствующего полю Subject сертификата клиента.
- Если найдено соответствие, то по строке связи соединения определяется нужная БД, а по полю Subject сертификата клиента - схема доступа пользователя к указанной БД.
- Определяются роли масштаба предприятия (enterprise roles) и их соответствие ролям в выбранной схеме пользователя.
- Устанавливается соединение с БД.
| Сертификаты и связанные с ними закрытые ключи хранятся в защищенной памяти eToken (она доступна только встроенному в него криптопроцессору). Чтобы выполнить криптографические операции с закрытым ключом, пользователь должен ввести PIN-код. Такой подход позволяет на практике реализовать модель организации защищенного доступа пользователя к данным (СУБД) с использованием цифровых сертификатов Х.509, установленных в eToken, в двух уровнях. Легальные пользователи корпоративной сети (например, под управлением контроллера домена Windows 2000/2003) могут авторизоваться в сети (рис. 3) только после успешного завершения процесса аутентификации по смарт-карте, включающего предъявление соответствующего сертификата (первый уровень). На втором уровне защиты доступ авторизованных пользователей корпоративной сети к защищенным данным СУБД возможен только при предъявлении соответствующего сертификата Oracle. Рис. 3. Двухуровневая модель доступа к защищенным данным с помощью цифровых сертификатов Х.509. Подведем итоги. Предложенный метод защиты данных существенно ограничивает возможности кражи информации. А в случае совершения преступления он предоставляет обоснованные свидетельства для применения наказания, поскольку владелец электронного ключа и хранимых в нем сертификатов всегда известен. 1 - Обычно промышленные СУБД класса DB2 и Oracle сертифицированы как минимум по классу защищенности С2. 2 - По данным ряда источников, в том числе IDC. - Прим. ред. |