Об интеграции средств аутентификации

Connect! №9 и №10, 2010

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

Для аутентификации пользователей и сервисов используются цифровые сертификаты X.509, своего рода "электронные паспорта". Одним из самых надёжных способов при этом является строгая двухфакторная аутентификация. Первый фактор – смарт-карта, второй – знание личного PIN-кода. Для аутентификации пользователь и система должны предоставить друг другу действительные сертификаты и обменяться несколькими последовательными сообщениями, заверенными электронной подписью. Степень доверия к данному методу повышается, если связанный с сертификатом пользователя закрытый ключ хранится в защищённой памяти смарт-карты.

К сожалению, в штате разработчиков приложений весьма редко встречаются специалисты по защите информации, и уж тем более накладно держать в штате софтверной компании специалиста по криптографии, даже если для приложения необходим процесс встраивания электронной подписи или других сервисов PKI. В итоге за редким исключением мы имеем ситуацию, когда все вопросы, связанные с безопасностью, разработчики приложений с той или иной степенью надёжности перекладывают на встроенные механизмы безопасности СУБД, операционной системы и (реже – или) средств удалённого или терминального доступа. Аналогично разработчики поступают и с аутентификацией. Как правило, даже в недавно выпущенных программных приложениях в качестве единственного фактора аутентификации используется пароль. И это даже в том случае, когда в приложении может предусматриваться применение электронной подписи. В качестве итога в крупной организации обычно имеется следующий набор для решения задач аутентификации:

• одна или несколько сетей (сегментов) под управлением серверов Windows, Novell, Linux/Unix и разными, но чаще всего с PKI-совместимыми механизмами аутентификации пользователей корпоративной сети, например, на основе цифровых сертификатов;
• десятки приложений с разными механизмами и средствами аутентификации пользователей приложений, чаще всего с использованием пары логин/пароль.

Примером такой постановки задачи в упрощённом виде может послужить схема. В сегментах корпоративной сети под управлением серверов производства Microsoft и Novell есть возможность организовать аутентификацию с применением цифровых сертификатов, однако в этих же сегментах сети имеется ряд так называемых унаследованных приложений, доступ к которым может быть организован только по паролям. Кроме того, можно использовать встроенные механизмы PKI к приложениям Microsoft, SAP и Oracle для организации современных и более безопасных способов аутентификации.

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