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

Соответственно встаёт задача использования множества паролей, точнее даже множества учетных записей (что сложнее, так как речь идет не только о пароле, а о том, что каждое приложение оперирует своей собственной связкой “имя — пароль”: — пользователь должен держать в голове связку “имя — пароль — приложение”), которая в большинстве случаев решается универсальным методом: стикер на монитор. Так что там у нас с безопасностью?

Второй аспект проблемы — взгляд с другой стороны баррикад: “Я тут что-то сделал, и меня не пускает” (то есть оптимизация работы службы поддержки и администрирования).

Решаем задачу в несколько шагов.

1. Четко сформулировать задачу.

2. Определить границы проекта.

3. Проанализировать приложения.

4. Разобраться в существующих технологиях.

5. Покритиковать технологии.

6. “Зри в корень”.

7. Обеспечить безопасность решения.

8. Составить список кандидатов.

9. Сократить список.

1.   Формулировка задачи

Прежде всего нужно ответить на вопрос: что нас заставило задуматься над этим? Драйвером для постановки задачи могут быть: 

  • вопросы информационной безопасности (давайте уберем наконец с мониторов стикеры с паролями, “накатим” политику сложности пароля на те приложения, в которых нет такого понятия, и т. д.); ·
  • необходимость автоматизировать некоторые аспекты работы с приложением. Пользователи слишком много времени тратят на реакцию “служебных” активностей приложения (выдается много непонятных сообщений, понять которые можно далеко не сразу, а еще больше времени уходит на придумывание нового пароля по комплексной политике сложности); ·
  • необходимость соответствовать чему-либо (например, PCI DSS требует двухфакторной аутентификации для работы с каким-либо приложением, которое ничего, кроме паролей, “не знает”).

2.   Границы проекта

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

3.   Анализ приложений

Как обстоят дела с политикой сложности пароля (ПСП) в приложениях: реализована ли ПСП и какая, есть ли параметр “время жизни пароля” (если нет, то может ли пользователь сменить пароль самостоятельно)? Наложите полученные результаты на существующую в компании политику.

На этом этапе имеем:

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

4.    Существующие технологии

Мы рассмотрим две из них: Password Synchronization (PS) и Single Sign-On (SSO). В общем, обе технологии сводятся к одному и тому же — использованию единого пароля для доступа ко всем интегрированным ресурсам. PS решает задачу именно синхронизацией паролей во всех приложениях, то есть реализует концепцию общего пароля: пользователь самостоятельно вводит один и тот же пароль в окна аутентификации всех приложений.

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

5.   Критика технологий

Отмечу, что PS решает задачу автоматизации только на уровне управления паролями, так как концептуально сводится к тому, что сам пользователь в каждое приложение вводит общий пароль (а вот из SSO можно выжать и еще кое-что полезное, например, уведомление администратора об аномальном поведении пользователя). Кроме того, PS предполагает интеграцию с приложениями на более низком уровне, что возможно далеко не всегда.

SSO интегрируется с приложениями на уровне взаимодействия с окнами, что значительно проще и вообще не затрагивает приложения . “Хороший” SSO, обладая инструментарием описания поведения и реакции на события приложений, позволяет автоматизировать практически любые события.

Если в списке есть приложения, не позволяющие пользователю менять пароль (или не имеющие функционала смены пароля), а условно- постоянность прописана в корпоративных политиках, то нужно смотреть в сторону PS или исключить приложение из списка интегрируемых.

Далее анализируем ПСП, понимая, что в случае PS мы не можем реализовать разные требования для различных приложений, так как используем общий пароль. Если найдены неперенастраиваемые противоречивые ПСП, то забываем про PS и выбираем SSO.

6.    “Зри в корень”

Если компания большая, то вы наверняка задумывались над этой задачей в более глобальном смысле, посягая на identity management. Рассмотрите тот вариант, который впишется в существующее IDM-решение или предоставит вам возможность интегрироваться в дальнейшем, и чем проще такая интеграция будет, тем лучше. “Коробочная” поддержка различных систем разных вендоров — это хорошо, но если выбор падет на что-нибудь экзотическое, вам понадобятся гарантии интегрируемости (как там дела с SDK?). 7.

7.    Безопасность решения

Если остановились на PS, то начинаем анализировать список приложений с точки зрения хранения ими данных аутентификации, понимая, что будет использоваться общий пароль, а значит, надежность всей этой сложной парольной конструкции будет не более, чем самая слабая модель хранения паролей в одном из приложений. У вас есть приложения, которые хранят пароли в открытом виде? Поздравляю: возвращаемся к пункту 1 и исключаем его (приложение) из списка интегрируемых или пересматриваем свое мнение о выбранной технологии. Аналогичные поздравления примите, если у вас для аутентификации используются смарт-карты, так как в этом случае мы принципиально отходим от концепции единого пароля (вы же не собираетесь синхронизировать пароли и PIN-код?).

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

8.   Список кандидатов

Один из наиболее важных параметров оценки качества SSO — интегрируемость с приложениями. Установите их типы: win32, java, web… что еще у вас есть?

Определите перечень клиентских ОС, а также ряд инфраструктурных моментов — например, предоставляется ли у вас удаленный доступ к приложениям?

С этими исходными данными можно приступить к составлению списка кандидатов.

9.   Сокращение списка

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

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

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

И снова безопасность: единый пароль, конечно, лучше общего, но насколько хорошо реализован механизм его использования? Особое внимание обратите на возможность работы в режиме единого PIN-кода в случае строгой первичной аутентификации, или единого отпечатка пальца, или еще чего-то единого, то есть рассмотрите, как SSO интегрируется со сторонними системами аутентификации и как их можно использовать при аутентификации в приложениях (это к первому пункту, к вопросу о PCI DSS).

Автор статьи — руководитель отдела внедрения и техподдержки Rainbow Security.