Зачем это надо?

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

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

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

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

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

То есть, человек, который знает логин и пароль с точки зрения приложения является тем, кто имеет:

1.     право выполнять операции и

2.     доступ к информации

которые определены для некоторого сотрудника с указанным логином и паролем.

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

В этом месте статьи мы столкнулись с первой проблемой: паролей становится слишком много. 

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

Для предотвращения подобных атак существует ряд стандартных требований к сложности пароля, которые обеспечивают его стойкость к подбору, вот некоторые из них: 

1.    использовать пароль, длина которого не менее заданного

2.    использовать символы верхнего и нижнего регистра

3.    использовать цифры

4.    использовать специальные символы (!»№;%:?*()_+=_)

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

Только что мы озвучили вторую существующую проблему: пароли становятся сложными.

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

1.    пароль должен меняться с определенной периодичностью

2.    новый пароль не может совпадать с предыдущим или некоторым количеством ранее используемых

3.    пароль не может меняться чаще, чем это определено

Два последних правила предотвращают использование «любимых» паролей: вторым правилом мы предотвращаем само использование «любимого пароля»,  а третьим запрещаем последовательное изменение пароля заданное количество раз таким образом,  чтобы «перемотать» весь список ранее используемых.

Итак, озвучена третья проблема: пароли меняются.

Если политика безопасности компании должным образом описывает правила использования паролей, то пользователь начинает сталкиваться с тремя вышеперечисленными проблемами:

1.    паролей много

2.    пароли сложные

3.    пароли меняются.

Так как любой пользователь пытается облегчить себе жизнь (а попробуйте запомнить, например, 5 паролей типа d7U%iP7)  возникает проблема «желтого стикера». Суть которой сводится к тому, что пароли начинают записывать и хранить в легкодоступном месте. Название «желтый стикер» возникло из личной практики: сотрудники некоторой компании записывали свои пароли на стикер и клеили его на монитор.

Второй «метод борьбы» с жесткими требованиями к паролям — использование везде  одного и того же пароля. К сожалению, не все (в том числе и системные администраторы, и сотрудники отдела безопасности) до конца понимают опасность этой ситуации. В этом случае компрометация (или раскрытие) одного пароля дает доступ ко всем ресурсам (например, при недостаточной или неправильной защите пароля самим приложением). Можно провести бытовую аналогию: представьте себе ситуацию, когда в несколько дверей врезаны замки, отпирающиеся одним ключом.

В результате все перечисленные выше усилия по сохранению «секретов» компании сводятся к нулю.

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

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

Ярким и наиболее функциональным решением в этой области является система SecureLogin  компании ActivIdentity. Именно ее мы и рассмотрим как решением проблемы «желтого стикера».

Основной задачей SecureLogin является:

1.                  аутентификация пользователя в приложения, посредством подстановки ПДА в соответствующие поля ввода данных.

2.                  хранение данных о приложениях

3.                  защищенное хранение всех ПДА пользователей (логина, пароля и любых дополнительных данных)

Рассмотри подробно работу SecureLogin.

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

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

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

Для достижения непревзайденного качества по этому параметру используется 3 метода интеграции SecureLogin с приложениями.

Первый способ (заранее описанные приложения). Наиболее популярные и широко используемые  приложения, такие как Cisco VPN, Oracle и т.д. интегрированы разработчиками SecureLogin в эту систему. В процессе описания приложения были определены параметры, однозначно характеризующие само приложение, окно аутентификации и типы требуемых данных таким образом, что при его появлении SecureLogin «узнает» его и вводит соответствующие данные.  

Второй способ (использование Мастера).  Так как невозможно заранее описать все приложения, а в идеале система должна быть универсальной, то есть работать со всеми приложениями, реализована мощная система автоматической распознавания  новых приложений (их окон). Когда пользователь запускает приложение, появляется окно аутентификации, SecureLogin распознает приложение как  «своего клиента» и предлагает сохранить параметры приложения и введенные ПДА для последующей автоматической аутентификации. В этом случае запускается Мастер, который позволяет «натренировать» SecureLogin на работу с приложением. То есть, показать (в буквальном смысле этого слова), какое окно используется для ввода логина, какое — для пароля, какая кнопка нажимается для завершения ввода данных и т.д. На этом этапе SecureLogin фиксирует идентификаторы указанных полей и их классы и формирует описание приложения, таким образом, что при последующем запуске приложения оно узнается и отрабатывается SecureLogin.

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

 Третий способ (написание макроса). Существует масса факторов, которые не позволяют использовать второй способ. Одни из них — переменчивость идентификаторов полей: при каждом новом запуске приложения идентификаторы полей изменяются. В этом случаем SecureLogin будет пытаться подставить, например, имя пользователя в окно ввода с идентификатором 10001, которое было определено во время «тренировки», но при текущем сеансе работы это же окно имеет идентификатор, например, 95262.

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

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

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

Использование макросов может использоваться не только в том случае, когда автоматические методы не могут быть использованы, но и тогда, когда требуется реализовать «сложную» модель аутентификации, построенную на некоторых зависимостях.

Например, существует некоторая программа, которая выполняет подключение к удаленному серверу. В этом случае пользователю необходимо указать свой логин, пароль и выбрать из выпадающего меню сервер, к которому он подключается. В том случае, если для каждого сервера используется своя ученая запись (логин-пароль), то необходимо использовать подпрограмму, которая будет подставлять пару логин-пароль соответствующую выбранному серверу. Или например, существует некоторая периодичность доступности серверов, в этом случае возможно реализовать автоматическое подключение к доступному серверу в зависимости от времени суток.