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

БиблиотекаБиблиотека

Октябрь, 2010

Алексей Сабанов, к.т.н., заместитель генерального директора Аладдин

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

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

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

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

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

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

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

Читать полную версию

Первоисточник: Connect!, №9 и №10, 2010

Эксперт: Редакционный эксперт

Репринт