Новости

Сравнение технологии Синхронизации паролей (Password Synchronization) и сквозной однократной аутентификации (Single Sign-On)

Целью этой статьи является описать сравнение технологии Синхронизации паролей и сквозной однократной аутентификации на примере ActivIdentity SecureLogin. Рассмотрены базовые принципы, основной упор сделан на уровне безопасности всей ИТ-структуры при внедрении той или иной технологии.

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

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

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

Целью этой статьи является сравнение технологии Синхронизации паролей и сквозной однократной аутентификации на примере ActivIdentity SecureLogin. Мы рассмотрим базовые принципы обеих технологий, сделав основной упор на уровне безопасности всей ИТ-структуры при внедрении той или иной технологии.

Что такое система синхронизации паролей

Синхронизация паролей — это процесс изменения паролей для всех приложений на одно и то же значение, для того чтобы пользователь всегда вводил один и тот же пароль. Единожды развернув систему синхронизации паролей, пользователи будут вводить один и тот же пароль во всех «синхронизируемых» системах: при входе в Windows, доступе к сетевым ресурсам, корпоративным бизнес-приложениям, почтовым службам и т.д..

Обычно, пароли синхронизируются следующим образом:

  1. Когда в каком-либо приложении, интегрированном с системой синхронизации паролей (далее будем называть такие приложения «синхронизируемые»), истекает срок действия пароля, пользователь указывает новый пароль.
  2. Это инициирует процесс синхронизации паролей, и этот новый пароль передается всем другим системам, которые интегрированы с системой синхронизации паролей.
  3. Пароли в «синхронизируемых» приложениях автоматически изменяется на новое значение — указное пользователем при смене пароля в приложении-инициаторе.
  4. Всякий раз, когда пользователь проходит аутентификацию в любой «синхронизируемой» системе/приложении, он использует пароль один и тот же пароль.

Таким образом, если в процесс синхронизации вовлечены 5 приложений, то пользователь в каждом из них будет использовать один и тот же пароль.

Рассмотри ситуации истечения срока действия пароля в бизнес-приложении. В этом случае пользователю предлагают указать новый пароль. Новое значение регистрируется в «этом» приложении, при этом система синхронизации паролей изменяет текущей пароль во всех «синхронизируемых» приложениях на новое значение. Далее, когда пользователь аутентифицируется, например, в почтовую систему, ему необходимо указать его пароль, значение которого было изменено. Пользователь обязан ввести точно такой же пароль в диалоговое окно почтовой системы, который он указал ранее в бизнес-системе. Это распространяется на все «синхронизируемые» приложения: при аутентификации пользователь использует единый пароль.

Какова польза синхронизации паролей?

На первый взгляд синхронизация паролей обладает следующими полезными свойствами:

  1. Пользователь должен помнить только один пароль, вместо множества. Это может значительно понизить количество обращений в службу поддержки по поводу забытых паролей и блокировки учетных записей. Так же это понижает вероятность того, что пользователь запишет свой пароль, так как запомнить один пароль, пусть даже и сложный, запомнить все-таки можно.
  2. Пользователь должен вводить свой пароль каждый раз при запуске приложения. Это предотвращает несанкционированный доступ к приложениям, когда пользователь покидает рабочее место, не заблокировав компьютер.

Недостатки системы синхронизации паролей

  1. Безопасность понижается до уровня «наименьшего общего знаменателя». При синхронизации все пароли становятся одинаковыми. Это означает, что они могут удовлетворять только политики наиболее «слабого» приложения. Например, если в процесс синхронизации включено приложение, пароль которого может быть не длиннее четырех символом, это означает, что все приложения будут использовать пароль длиной максимум четыре символа.
  2. Несовместимость политик паролей. Синхронизация не будет работать в том случае, если «синхронизируются» приложения с несовместимыми политиками сложности паролей. Например, вы не можете использовать приложение, которое требует использования определенного набора символов в группе приложений, которые требуют использование другого набора символов. Или пример, приведенный в предыдущем абзаце: как синхронизировать пароли двух приложений, первое из которых требует использование пароля не короче 6 символом, а второе — не длиннее 5 (этот пример несколько утрирован и был выбраны исключительно для хорошей наглядности).
  3. Риск скомпрометировать слабый пароль. При использовании системы синхронизации паролей, пользовать сам задает свой пароль, что подразумевает отсутствие защиты от использования слабого пароля. Пользователь может повторно использовать предыдущий пароль, задать простой пароль (который проще запомнить), использовать слова в качестве паролей или некоторые персональные данные (например, номер телефона), что делает пароль легким для подбора.
  4. Риск, обусловленный тем, что пользователь знает свой пароль. Проблема заключает в том, что пользователь знает свой пароль, так как система синхронизации предоставляет пользователю возможность самостоятельно задать его. В результате пароль может быть скомпрометирован, так как существует возможность записать его (и приклеить на монитор — очень распространенный случай) или поделиться им с сотрудником.
  5. Проблема единого пароля. В процессе синхронизации указанный пользователем пароль «рассылается» всем «синхронизируемым» приложениям, это приводит к тому, что использование одного «слабого» пароля (выше рассмотрена проблема политик сложности паролей в разных приложениях) приводит к созданию потенциальной уязвимости во всех приложениях, так как доступ к ним будет осуществляться именно по этому «слабому» паролю. Кроме того, если кто-то узнает пароль к одному из «синхронизируемых» приложений, то это автоматически означает получение доступа ко всем приложениям. Компрометации пароля может произойти и со стороны какого-либо приложения — вполне понятно, что разные приложения по-разному хранят пароли от учетных записей пользователей. В случае синхронизации возникает следующая ситуация: уровень защиты пароля определяется самым слабым по этому критерию их всех приложением (а некоторые очень распространенные приложения хранят пароли в открытом виде). В качестве примера можно рассмотреть ситуацию, когда один и тот же ключ используется для замка от ворот, сарая, где хранится садовый инвентарь, и сейфа семейными ценностями.
  6. Синхронизируются только пароли. Система синхронизации паролей синхронизирует только пароли, в то время как при аутентификации вводятся и другие данные: имя пользователя, IP-адрес, название базы данных и т.д. Все эти данные пользователь должен помнить и вводить их. Простейшим примером является RDP-аутентификация, при которой необходимо указать имя пользователя, пароль, IP-адрес, домен – все эти данные необходимо вводить вручную.
  7. Ограниченность сервисов и приложений. Система синхронизации паролей требует инсталляции специальных модулей, которые являются «надстройками» над теми ресурсами, которые «синхронизируются». Это кардинальным образом ограничивает перечень приложений, которые могут быть включены в процесс синхронизации паролей. Например, внешние web-ресурсы, или приложения не имеющие модули синхронизации (а таковых большинство) не могут быть включены в процесс синхронизации.
  8. Работа с несколькими учетными записями. Бывают случаи, когда у одного пользователя существует несколько учетных записей в одном и тот же приложении (соответственно с разными полномочиями и доступом к различным данным). В этом случае исходя из концепции синхронизации пароля во всех учетных записях будет использоваться один и тот же пароль, что полностью противоречит основным положениям информационной безопасности.
  9. Аутентификация с использованием смарт-карт (цифровых сертификатов). В этом случае вообще не понятно, что с чем синхронизировать, так как первичная аутентификация происходит на базе сертификата (от пользователя требуется ввести PIN-код карты), а приложение требует пароль. Что синхронизовать: PIN-код смарт-карты и пароли приложений? Ситуация выглядит абсурдной, так как к этим «данным» предъявляются разные требования по сложности (можно раскрыть эту тему довольно подробно). Кроме того, нельзя допустить, чтобы PIN-код от карты, сертификаты в которой используются в том числе и для ЭЦП, был где-либо записан, так как компрометация пароля позволит не только войти во все приложения, но и пользовать смарт-картой, а значит ставить цифровые подписи «от имени владельца карты). Конечно, PIN можно исключить из списка синхронизируемых паролей, в этом случае мы должны отказаться от концепции к которой стремимся, так как возникает как минимум второй элемент, требующий запоминания.

Что такое ActivIdentity

ActivIdentity SecureLogin Single Sign-On—это реализация технологии сквозной комплексной аутентификации, которая реализует комплексную политику безопасности паролей в масштабах всего предприятия, взаимодействуя с выбранными приложениями. При этом приложения могут располагаться где угодно, как в вашей корпоративной сети, так и быть вообще внешними приложениями, например — we-приложения.

Как работает SecureLogin

SecureLogin реализует модель сквозной однократной аутентификации, создавая ситуацию, когда пользователь помнит один единственный пароль (далее будет описано, как от паролей можно отказаться вообще). Так как пользователь должен помнить и использовать только один пароль, компания может ужесточить требования к политики паролей, а именно: увеличить минимальную длину пароля, ввести необходимость использование нескольких спец символов, цифр и т.д.

SecureLogin управляет и автоматически вводит пароли во всем приложения вместо пользователя. Это позволяет пользователю быстро и защищено получать доступ ко всем приложениям, web-ресурсам, терминальным сессиям и т.д. используя один идентификатор.

SecureLogin — гибкое решение и обладает богатыми возможностями настройки. В то же время, будучи крайне простой в установке системой, SecureLogin реализует следующий сценарий:

  • Пользователь включает свой компьютер и вводит имя пользователя и пароль (если быть более точным, то проходит первичную аутентификацию);
  • Пользователь аутентифицируется в доверенную среду, например, службу каталогов: Active Directory, Novell eDirectory (или что-то еще совместимое с LDAP v3).

Служба каталога хранит персональные данные аутентификации (ПДА) пользователя для всех приложений, аутентификация в которые выполняется автоматически с помощью SecureLogin (далее будем называть их SSO-разрешенные приложения — SSO-РП). ПДА хранятся в зашифрованном виде, что гарантирует их доступность только аутентифицировавшемуся пользователю.

  • Локальный агент SecureLogin запускается на компьютере и «следит» за SSO-РП;
  • Когда запускает SSO-РП, SecureLogin извлекает соответствующие данные из службы каталогов и автоматически подставляет их в соответствующие поля окна аутентификации и нажимает соответствующую кнопку;
  • SecureLogin автоматически определяет диалоги аутентификации и в том случае, когда они повторно возникают в течение работы приложения и повторно подставляет соответствующие ПДА.

Как происходит настройка приложения для работы с SecureLogin?

Никак.
Приложение не должно каким-либо образом настраиваться на работу с SecureLogin, дописываться, дополняться модулем интеграции и т.д. Вся работа по «интеграции» выполняется в SecureLogin. После установки SecureLogin будет автоматически определять все приложения, к которым пользователь имеет доступ. При появлении окна аутентификации SecureLogin предложит «зарегистрировать». Если пользователь отвечает Да, то:

  • запускается Мастер, который создает описание данного окна аутентификации на внутреннем языке SecureLogin. При необходимости макрос можно доработать, например, для расширения его функционала.
  • пользователь вводит свои ПДА, которые сохраняются в зашифрованном виде в службе каталога.

Впоследствии, при появлении ранее зарегистрированного приложения SecureLogin, как говорилось ранее, извлекает ПДА пользователя , подставляет их в нужные поля и нажимает нужную кнопку.

Автоматическое «определение» окончания действия пароля

Когда срок действия пароля истекает, SecureLogin контролируют эту ситуацию и в зависимости от ранее сделанных настроек:

  • случайным образом сгенерирует новый пароль, который удовлетворяет политикам сложности пароля;
  • предложит пользователю ввести свой собственный пароль (с возможностью проверить его соответствие политике сложности пароля).

После формирования нового пароля, сохраняется и используется до момента истечения срока его действия.

Основной вопрос: это то же самое что и синхронизация паролей?

Нет. Система синхронизации изменяет пароля во всех приложениях на единый. При этом пользователь продолжает вводить пароль (и прочие данные) при запуске каждого приложения, но использует при этом одно и то же значение пароля.
В противоположность этому, SecureLogin использует отдельные пароли для каждого приложения, защищено храня их и прочие ПДА в службе каталогов, извлекая их и подставляя в нужные окна, когда того требует зарегистрированное приложение.

Отсутствие проблемы единого пароля. В отличие от системы синхронизации паролей SecureLogin использует собственный пароль для каждого приложения. Даже если какое-либо приложение (а вернее пароль к нему) становится скомпрометированным, несанкционированный доступ не будет получен ко всем приложениям, так как приложения не используют один и тот же пароль, а наоборот, доступ к каждому из них осуществляется по «своему» уникальному паролю.

Отсутствие проблемы «слабого» пароля. SecureLogin позволяет избежать эту проблему, так как позволяет сконфигурировать и «навязать» использование политик сложности пароля для все SSO-РП. Так как пользователь должен помнить один пароль и, главное, вводить его единожды, требования к сложности такого пароля могут быть значительно более высокими, чем в случае использования, например, пяти паролей.

Кроме того, SecureLogin обладает возможностью случайной генерации паролей для приложений с учетом политики сложности пароля. При использовании этого функционала обеспечение секретности и общей защищенности значительно возрастает. Это объясняется довольно просто тем, что если пользователь не знает свой пароль, он не может каким-либо образом скомпрометировать его.

SecureLogin предотвращает запись паролей и передачу их третьим лицам. Так как пользователь не должен вводить, а значит и помнить пароли для всех приложений, то он не будет записывать их или передавать кому-либо. Этому способствуют два обстоятельства.
Как бы странно это не звучало, но если пользователь не использует свой пароль, он довольно быстро забудет его.

Можно не полагаться на забывчивость пользователя и активировать режим случайной генерации паролей. В этом случае пользовать попросту не будет знать свои пароли, а значит, не сможет скомпрометировать пароль специально или по неосторожности.


SecureLogin предотвращает возникновении ситуации несовместимости паролей. SecureLogin создает пароль для каждого приложения в соответствии с его персональной политикой сложности пароля, учитывая все возможные ограничения на состав пароля в конкретно взятом приложении. За счет чего можно с уверенностью говорить, что нет таких приложений, структуру пароля которых SecureLogin бы не поддерживал. Это так же гарантирует то, что SecureLogin будет работать с различными приложения, даже если их политики сложности пароля противоречат друг другу.

Можем ли мы избавиться от паролей вообще?

Возможно значительно расширить используемые типы аутентификации различными более надежными методами, такими как: смарт-карты, биометрия и т.д.

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

Таким образом, можно достичь наиболее привлекательной с точки зрения безопасности ситуации, в которой доступ осуществляется во все системы без использования вообще какого-либо пароля: аутентификация во все приложения выполняется автоматически с помощью SecureLogin, а первичная аутентификация выполняется на базе отпечатка пальца пользователя и смарт-карты (палец нельзя оставить на столе по забывчивости).

Пользователи оставляют свои рабочие места не заблокированными

В случае реализации сквозной однократной аутентификации возникает ситуация, когда, пройдя первичную аутентификацию в систему, доступ ко всем SSO-РП становится фактически открытым, так как SecureLogin будет извлекать данные из службы каталогов и подставлять по требованию приложения (никто не знает, пользователь за своим рабочим столом и обедает). Для предотвращения несанкционированного доступа к приложениям возможно активировать повторную аутентификацию пользователя (ре-аутентификацию).

Алгоритм работы приблизительно такой:

Пользователь проходит первичную аутентификацию в систему, использую любой из возможных методов: пароль, смарт-карту, отпечаток пальца их комбинацию и т.д.

Пари запуске SSO-РП, для которого в SecureLogin активирована опция ре-аутентификации, SecureLogin требует аутентифицироваться повторно, с использований того же метода, который использовался при первичной аутентификации (если речь идет о использовании пароля, то каждый раз будет использовать тот же самый системный пароль).

SecureLogin извлекает соответствующие данные аутентификации и подставляет их в приложение, реализуя автоматическую аутентификацию в приложение.

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

Другие полезности SecureLogin

Интеграция, не требующая изменения самих приложений. Так как интеграция с SecureLogin не требует внесения каких-либо изменений в приложения, применимость этой системы значительно возрастает, так как снимаются ограничения на нестандартные, малораспространенные, специализированные приложения (например, разработанные специально для вашей компании), а так же «внешние» приложения, которые в принципе не могут быть изменены или доработаны, например, web-приложения.

Решение проблемы «забытый пароль»

В отличие от пользователя SecureLogin не забывает пароли и не допускает ошибок при их вводе. За счет этого устраняется ситуация блокировки учетной записи пользователя из-за последовательного неправильного ввода паролей.

Расширение возможностей мониторинга и аудита

SecureLogin позволяет SNMP-уведомления при выполнении определенных администратором операций, а так же вносит записи в системный журнал событий. Это позволяет расширить функционал мониторинга и отчетности самих приложений, а так же реализовать уведомления в режиме реального времени, например, при работе критичными приложениями.

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


Автор: Тархов Андрей, менеджер продуктов ActivIdentity

Rainbow Technologies

Использование материалов этой статьи без согласования с автором запрещено.

Возврат к списку

 

Защита банкоматов

Имя* Компания* Email* Телефон

* - Поля, обязательные для заполнения

Компрометация приложений для смартфонов

Имя* Компания* Email* Телефон

* - Поля, обязательные для заполнения

Семинар ATAR

Фамилия* Имя* Должность* Компания* Email* Телефон* Защита от автоматического заполнения Введите символы с картинки*

* - Поля, обязательные для заполнения

Заполните поля

Защита от автоматических сообщений
CAPTCHA
Введите слово на картинке*

Заполните поля

Защита от автоматических сообщений
CAPTCHA
Введите слово на картинке*

Для получения БЕСПЛАТНОГО БИЛЕТА заполните, пожалуйста, Форму:

Количество билетов ограничено

Фамилия* Имя* Отчество* Название компании* Должность* Телефон рабочий* Телефон мобильный* E-mail*

* - Поля, обязательные для заполнения