|
|
Пример решения: Система сквозной однократной аутентификации SecureLogin от ActivIdentity
Какие проблемы возникают при использовании паролей с точки зрения пользователей:
Желая оптимизировать процесс пользователь пытается:
В результате уровень информационной защищенности компании значительно понижается. К сожалению, административные меры далеко не всегда приносят желаемые результаты: максимум на что можно надеяться в результате предпринимаемых усилий — это перемещение записанного пароля с монитора в ящик стола. Значит, административные меры необходимо заменить техническими. Сквозная однократная аутентификация (Single Sing-On) SecureLogin В рамках этой концепции предполагается использовать специальное программное решение, которое будет хранить пароли пользователя от всех приложений, требующих аутентификации и автоматически вводить их, когда приложение того требует. То есть подобное решение замещает собой пользователя в процессе аутентификации приложением. Доступ пользователя к хранимым паролям и настройкам происходит после аутентификации в подобной системе, которая, как правило, совмещается с аутентификацией в операционной среде. Таким образом, введя свои персональные данные аутентификации (ПДА) один раз, например, логин и пароль, пользователь автоматически получает доступ ко всем системам, требующим аутентификации. Именно отсюда такие системы получили название Single Sing-On (SSO) — сквозная однократная аутентификация. Ярким и наиболее функциональным решением в этой области является система SecureLogin компании ActivIdentity. Именно ее мы и рассмотрим как решение проблемы «желтого стикера». Основной задачей SecureLogin является:
Аутентификация пользователя в приложениях Как говорилось выше, аутентификация выполняется вводом соответствующих данных, как правило, это связанная пара — логин и пароль. Каждый параметр впечатывается с клавиатуры в соответствующее поле ввода или выбирается из представленного списка, после чего нажимается кнопка ввода (ОК, Ввод, Вход и т.д.) SecureLogin автоматически определяет начало процесса аутентификации, то есть появление окна ввода ПДА, подставляет в поля ввода соответствующие данные и нажимает кнопку завершения ввода данных. Самым сложным для подобных систем является умение взаимодействовать с окнами аутентификации различных приложений и работать с разными вариантами ввода данных (ввод текста, выпадающие списки, установка флагов и т.д.). Одним из параметров оценки качества подобных систем является как раз умение работать с различными приложениями. То есть, при попытке оценить качество такой системы, необходимо ответить на вопрос: как много существует приложений или их групп, сформированных по какому-либо признаку, как то: написанных на определенном языке, например, Java, с которыми система однократной аутентификации не может работать. Чем меньше таких приложений, тем лучше система. Для достижения необходимого качества по этому параметру используется 3 метода интеграции SecureLogin с приложениями. Первый способ (заранее описанные приложения). Наиболее популярные и широко используемые приложения, такие как Cisco VPN, Oracle и т.д. интегрированы разработчиками SecureLogin в эту систему. В процессе описания приложения были определены параметры, однозначно характеризующие само приложение, окно аутентификации и типы требуемых данных таким образом, что при его появлении SecureLogin «узнает» его и вводит соответствующие данные.
Такой Мастер может запускаться пользователем и системным администратором, например, для того, чтобы заранее настроить SecureLogin для работы с определенным приложением.
Существуют и другие трудности на пути автоматической аутентификации: использование всплывающих окон (splash screen), перемещающиеся кнопки, неактивность окна и т.д.
Язык создания макросов содержит более 70 команд, которые позволяют описать работу SecureLogin с любым приложением (его окном), а также использовать при автоматической аутентификации любые типы данных и разнообразные способы ввода. Для упрощения написания макросов может использоваться утилита, которая определяет все параметры окна аутентификации (исполняемого файла) и выдает в виде «черновика» в синтаксисе SecureLogin. Макросы могут использоваться не только в том случае, когда автоматические методы не могут быть реализованы, но и когда требуется создать «сложную» модель аутентификации, построенную на множестве зависимостей.
Итак, SecureLogin обнаруживает окна аутентификации и автоматически вводит требуемые значения. Бывают ситуации, когда в одном и том же приложении у одного и того же пользователя существует несколько учетных записей. Классический пример — бесплатные почтовые серверы. Эта ситуация так же предусмотрена: SecureLogin может содержать для одного и того же пользователя несколько наборов ПДА для входя в одно и тоже приложение. В этом случае возможно два варианта поведения системы:
Структура SecureLogin Современные даже небольшие компании стремятся создать IT-структуру таким образом, чтобы любые системы, входящие в ее состав, имели возможность централизованного унифицированного управления. Одна из важных особенностей SecureLogin — это как раз возможность централизованного управления.
Управление SecureLogin в этом случае выполняется с помощью стандартных MMC-консолей. В этом случае каждый пользователь при работе с SecureLogin будет использовать те настройки, которые были сделаны системным администратором, что исключает, во-первых: необходимость рядового пользователя вникать в принципы работы этой системы, а во-вторых: исключает возможность выполнять несанкционированные действия. Итак, за счет возможности централизованного управления системный администратор один раз выполняет настройку SecureLogin для работы с каждым используемым в компании приложением. Далее администратор может перенести эти и другие настройки на прочие объекты AD следующими способами:
Как обеспечить безопасность Многие сталкивались с вопросами «сохранить пароль» или «помнить меня», которые задают некоторые приложения во время аутентификации. Активация этой опции сохраняет ваши логин-пароль или в реестре или в пользовательских файлах, что позволяет приложению не требовать ввода этих данных от пользователя в следующий раз. Использование этой опции небезопасно, так как при входе в систему под Вашим профилем открывается доступ к Вашим учетным записям приложений. В чем здесь угроза? Если кто-то, обладая соответствующими полномочиями, сбросит Windows-пароль и войдет под вашим именем, то он получит доступ к тем приложениям, которые «вас помнят». В случае использования SecureLogin такой «фокус» не получится, так как ПДА хранятся в зашифрованном виде, с использованием логина и «оригинального» пароля пользователя; новый пароль не может быть использован для получения доступа к ПДА. Пропадут ли ПДА в этом случае? В SecureLogin для решения этой задачи используется система контрольных вопросов. Доступ к ПДА с использованием нового пароля не может быть выполнен. SecureLogin контролирует такую ситуацию и предлагает пользователю дать ответ на контрольный вопрос, который является вторым «ключом» для доступа к ПДА. То есть, ключ шифрования ПДА сохраняется в зашифрованном виде дважды:
Ответ на контрольный вопрос будет использоваться один раз при первом входе в систему после изменения пароля. После правильного ответа на контрольный вопрос SecureLogin пересохраняет ключ шифрования ПДА, зашифровав его с использованием нового пароля (а вернее — его хэша). Таким образом, при последующем использовании этого нового пароля сквозная однократная аутентификация восстановится. Администратор может определить требуемую сложность ответа на контрольный вопрос (минимальную длину, необходимость использования цифр и т.д.). За счет описанных выше мер можно с уверенностью гарантировать надежное хранение ПДА пользователей. Автоматическая генерация пароля Приложения могут требовать периодической смены пароля или смены пароля при первом запуске. Последнее значительно упрощает централизованное создание новых учетных записей: пользователь получает свой логин и пароль, который должен быть обязательно изменен при первом входе в систему. Также SecureLogin автоматизирует и процессы смены паролей. При появлении окна смены паролей система автоматически подставит текущий пароль (что обычно требуется), сгенерирует случайным образом новый пароль, который подставит в окна ввода и подтверждения и сохранит его для последующего использования. При этом может использоваться политика сложности паролей, которая описывается 15 правилами, такими как:
За счет этого можно заставить приложение «подчиняться» корпоративной политике сложности паролей даже в том случае, если само приложение не оперирует такими понятиями. Кроме того, возможность использовать отдельную политику сложности пароля для каждого приложения позволяет учитывать специфику приложения. Например, может потребоваться ограничить длину пароля или исключить какие-либо символы, которые не могут быть использованы в данном приложении. Возможность автоматической перегенерации паролей позволяет не только автоматизировать процесс смены пароля, но и добиться ситуации, когда пользователь вообще не знает своего пароля. Если пользователь не знает своего пароля, то не может передать его или записать «на всякий случай». Страшные слова: фишинг и фарминг Продолжая рассматривать вопросы безопасности необходимо затронуть тему фишинговых и фарминговых атак (от английского слова fishing — ловля рыбы, pharming). Суть первой атаки заключается в том, что хакер тем или иным способ «подставляет» пользователю собственное окно ввода ПДА или страницу аутентификации, которое внешне полностью идентично оригинальному, с помощью которого происходит аутентификация в приложении или web-ресурсе. В результате пользователь вводит свои данные, а они, в свою очередь, становятся доступны атакующему и далее используются в целях мошенничества. Второй тип атак сводится к тому, что пользователь автоматически перенаправляется на хакерский, внешне абсолютно идентичный атакуемому сайт, где вводимые данные сохраняются и используются таким же образом, как и в предыдущем случае. С помощью этих атак может быть организована утечка важной коммерческой информации, а так же кража личных данных пользователя, например, использующихся для управления банковскими счетами через интернет, номера кредитных карт при бронировании билетов, совершении покупок и т.д. Для предотвращения таких атак на уровне приложений выполняется проверка контрольной суммы перед началом подстановки ПДА. Если контрольная сумма не совпала, то подстановка ПДА не происходит. В случае работы с web-приложениями предусмотрена защита от подобных атак. Для этого выполняется во-первых: проверка URL активного окна, а во-вторых: перенаправление на указанный (известный нам) URL. Кроме того, может выполняться и проверка защищенности соединения, то есть, ведется ли работа по SSL-протоколу. Состоит отметить, что SecureLogin не только предотвращает ввод данных в «неправильное» окно, но и может выполнить SNMP- и/или SMTP-уведомление, например, администратору, что позволит принять оперативные методы для анализа ситуации и устранения возникшей опасности. Механизм уведомлений может быть использован и в любой другой произвольной ситуации, например, при аутентификации для доступа к особо важным корпоративным данным. Также, с помощью log-файла или журнала событий операционной системы, при необходимости, можно проанализировать активность пользователя. Использование смарт-карт и USB-ключей SecureLogin работает с любыми персональными идентификаторами — смарт-картами и USB-ключами, которые поддерживают работу по стандарту PKCS#11. Это позволяет использовать SecureLogin как с картами и ключами ActivIdentity, так и с любыми другими персональными идентификаторами, которые уже задействованы в компании. То есть, SecureLogin не рассматривается как некоторое дополнение к инфраструктуре ключей или смарт-карт определенного производителя, наоборот — персональный идентификатор всего лишь дополняет функционал SecureLogin в качестве хранилища ПДА.
В случае использования PKI ПДА могут храниться в AD, но при этом шифроваться с помощью цифрового сертификата пользователя: открытый ключ используется для шифрования ПДА, секретный (хранимый в защищенной памяти карты) — для расшифровки. При желании SecureLogin может быть настроен так, что доступ к ПДА будет осуществляться без персонального идентификатора (например, при его потере). В этом случае будет задействован описанный выше механизм вопросов-ответов. Кроме того, SecureLogin позволяет успешно бороться с «забывчивостью пользователей», которые покидают свои рабочие места, не заблокировав компьютер и оставив, например карту в считывателе. Практика показывает, что, как правило, никакие административные меры не могут это предотвратить. Для закрытия этой бреши в безопасности администратором включается режим повторной аутентификации: перед постановкой ПДА SecureLogin запрашивает PIN карты. Аналогичная ситуация возможна и без использования карт, в этом случае пользователь должен будет ввести свой системный пароль. То есть, для запуска любого приложения, требующего авторизации, он должен пройти аутентификацию (не путайте с системами синхронизации паролей). В заключение хотелось бы сказать, что SecureLogin позволяет работать с Windows-, Web-, Java-приложениями, а так же поддерживает работу через различные терминальные серверы. Например, не так давно продукты компании ActivIdentity, в том числе и SecureLogin, прошли сертификацию на предмет совместимости с Citrix Presentation Server (полноэкранный режим, опубликованные приложения, смешанный режим) и получили статус Citrix Ready. Кроме того, по версии журнала SC Magazine, SecureLogin компании ActivIdentity признан лучшим SSO-решением. Также, немаловажным фактом для российских пользователей является то, что в настоящее время силами дистрибьютора ActivIdentity на территории России и стран СНГ — компании Rainbow Technologies ведется работа по локализации SecureLogin и других решений производителя. Андрей Тархов |
Сегодня количество программных продуктов, используемых в любой компании, довольно велико. И можно с уверенностью сказать, что существует тенденция увеличения их количества, причем независимо от профиля компании. Многие из используемых приложений требуют прохождения аутентификации, то есть указания логина и пароля пользователя.
Второй способ (использование Мастера). Так как невозможно заранее описать все приложения, а в идеале система должна быть универсальной, то есть работать со всеми приложениями, реализована высококачественная система автоматического распознавания новых приложений (их окон). Когда пользователь запускает приложение появляется окно аутентификации, SecureLogin распознает приложение как «своего клиента» и предлагает сохранить параметры приложения и введенные ПДА для последующей автоматической аутентификации. В этом случае запускается Мастер, который позволяет «натренировать» SecureLogin на работу с приложением. То есть, показать (в буквальном смысле этого слова), какое окно используется для ввода логина, какое — для пароля, какая кнопка нажимается для завершения ввода данных и т.д. На этом этапе SecureLogin фиксирует идентификаторы указанных полей, а также их классы и формирует описание приложения таким образом, что при последующем запуске приложения оно узнается и отрабатывается SecureLogin.
Третий способ (написание макроса). Существует масса причин, которые не позволяют использовать второй способ. Одна из них — непостоянство идентификаторов полей: при каждом новом запуске приложения идентификаторы полей изменяются. В этом случаем SecureLogin будет пытаться подставить, например, имя пользователя в окно ввода с идентификатором 10001, которое было определено во время настройки, но при текущем сеансе работы это же окно имеет идентификатор, например, 95262.
Для решения нетривиальных задач аутентификации используются макросы — небольшая подпрограмма на внутреннем языке SecureLogin, которая описывает параметры окна и способы взаимодействия с ним. Стоит отметить, что методы, описанные выше, так же основаны на макросах: в первом случае макросы сохранены как описание предопределенных приложений, во втором — SecureLogin автоматически генерирует макрос.
Например, существует определенная программа, которая выполняет подключение к удаленному серверу. В этом случае пользователю необходимо указать свой логин, пароль и выбрать из выпадающего меню сервер, к которому он подключается. Если для каждого сервера используется своя ученая запись (логин-пароль), то необходимо использовать подпрограмму, которая будет подставлять пару логин-пароль соответствующую выбранному серверу. Или, например, существует некоторая периодичность доступности серверов, в этом случае возможно реализовать автоматическое подключение к доступному серверу в зависимости от времени суток.
Если компания использует доменую структуру сети (а это наиболее часто встречающаяся ситуация), то SecureLogin может быть интегрирован в Active Directory (AD), как частный случай службы каталогов, совместимых с протоколом LDAP (Light Data Access Protocol). С этой целью выполняется расширение схемы AD, внесение дополнительных атрибутов объектам «User». Стоит отметить, что такие изменения одобрены Microsoft и могут быть применены к таким структурным элементам как «User», так и к «Organization Unit» любого уровня вложенности. Так же поддерживается работа на уровне Групповых Политик. Эти особенности позволяют выполнять однотипные настройки SecureLogin для целых подразделений и отделов, а, при необходимости, детализировать их для отдельных пользователей.
На этапе настройки SecureLogin администратор может задать перечень контрольных вопросов или разрешить пользователю сформировать для себя такой вопрос самому. В любом случае, системный администратор не может задать ответы (то есть обзавестись вторым ключом), это делает пользователь при первой загрузке операционной системы после установки SecureLogin. Стоит отметить, что среди настроек есть опция принудительной регистрации контрольного вопроса, при активации которой пользователь не может отказаться от него, так как это окно не может быть закрыто до выбора вопроса и ввода ответа на него.
Пользователь проходит двухфакторную аутентификацию (сама карта или ключ плюс PIN-код) при входе в Windows, а ПДА извлекаются из идентификатора для подстановки в соответствующие окна. Интересен тот факт, что первичная аутентификация в систему возможна как на базе цифрового сертификата, хранимого на карте, а так и с использованием имени пользователя/пароля, которые вместе с ПДА также хранятся на карте (в том случае, если компания не используется PKI).
