3.2.1. Идентификация и аутентификация субъектов доступа

3.2.1.1. Идентификация и аутентификации субъекта доступа «пользователь»

3.2.1.1.1. Идентификация и аутентификации пользователя при входе в систему

Формализованные требования к механизму идентификации и аутентификации пользователей задаются действующим сегодня нормативным документом [1].

Для СЗИ от НСД, используемых для защиты конфиденциальной информации (5 класс СВТ), требования к механизму идентификации и аутентификации состоят в следующем:

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

Проанализировав данные требования, приходим к выводу, что по своей сути они состоят из двух взаимосвязанных частей:

1. КСЗ должен располагать необходимыми данными для идентификации и аутентификации и препятствовать входу в СВТ неидентифицированного пользователя или пользователя, чья подлинность при аутентификации не подтвердилась.

2. КСЗ должен обеспечивать идентификацию пользователей при запросах на доступ, должен проверять подлинность идентификатора субъекта - осуществлять аутентификацию.

Первая часть требования предполагает реализацию механизма идентификации и аутентификации (проверку подлинности идентификатора субъекта) при входе пользователя в систему (либо при загрузке системы).

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

Резонно, что возникает вопрос, достаточно ли для эффективного решения задачи идентификации и аутентификации реализации только одного из регламентируемых нормативными документами требования. К чему может привести и по какой причине невыполнение СЗИ от НСД данных требований в полном объеме.

Чтобы ответить на эти вопросы, прежде всего, на примере семейства ОС Windows, рассмотрим всю последовательность идентификации и аутентификации пользователя, реализуемую современными системными средствами.

Этапы идентификации и аутентификации пользователя, реализуемые в системе (на примере ОС Windows), представлены на рис.2.1.

Первый шаг идентификации, поддерживаемый режимом аутентификации, реализуется при входе пользователя в систему. Здесь следует выделить возможность входа в штатном и в безопасном режиме (Safe Mode). В порядке замечания отметим, что принципиальным отличием безопасного режима является то, что при запуске системы в безопасном режиме можно отключить загрузку драйверов и приложений. Поэтому, если в системе используется СЗИ от НСД, можно попытаться загрузить систему в безопасном режиме без компонент СЗИ от НСД, т.е. без средства защиты. С учетом же того, что загрузить систему в безопасном режиме может любой пользователь (в Unix системах – только Root), то СЗИ от НСД должна обеспечивать возможность входа в систему в безопасном режиме (после идентификации и аутентификации) только под учетной записью администратора.

Второй шаг состоит в запуске пользователем процессов, которые уже, в свою очередь, порождают потоки (именно потоки в общем случае и осуществляют обращение к ресурсам). Все работающие в системе процессы и потоки выполняются в контексте защиты того пользователя, от имени которого они так или иначе были запущены. Для идентификации контекста защиты процесса или потока используется объект, называемый маркером доступа (access token). В контекст защиты входит информация, описывающая привилегии, учетные записи и группы, сопоставленные с процессом и потоком. При регистрации пользователя (первый шаг, см. рис.3.1) в системе создается начальный маркер, представляющий пользователя, который входит в систему, и сопоставляет его с процессом оболочки, применяемой для регистрации пользователя. Все программы, запускаемые пользователем, наследуют копию этого маркера. Механизмы защиты в Windows используют маркер, определяя набор действий, разрешенных потоку или процессу.

Рис.3.1. Этапы идентификации и аутентификации пользователя

В общем случае пользователь имеет возможность запуска процесса, как с собственными правами, так и под учетной записью другого пользователя. Запуск пользователем процесса под другой учетной записью возможно только после выполнения процедуры аутентификации – пользователь должен ввести идентификатор и пароль, соответствующие той учетной записи, под которой им будет запущен процесс (например, подобную возможность в ОС Windows предоставляет утилита: runas.exe, но, начиная с ОС Windows XP, эта функция уже вынесена в проводник - ее можно реализовать, нажав правой кнопкой мыши на выбранном в проводнике исполняемом файле).

В порядке замечания отметим следующее. С одной стороны, это очень полезная опция, которая может быть использована в корпоративных приложениях, когда на одном компьютере требуется обрабатывать конфиденциальные и открытые данные. При этом предполагается, что для обработки данных различных категорий создаются различные учетные записи. Данная опция предполагает, что одновременно (без перезагрузки) можно обрабатывать данные различных категорий, например, под одной учетной записью обрабатывать необходимым приложением конфиденциальные данные, под другой учетной записью запустить Internet приложение (у вас на мониторе может быть открыто одновременно два окна). Естественно, что реализация данной возможности выставляет и дополнительные требования к СЗИ от НСД (например, при подобном запуске приложения ОС Windows между пользователями не изолируется буфер обмена, который в ОС является «принадлежностью» рабочего стола). Это уже вопросы противодействия внутренним ИТ-угрозам (угрозам хищения информации инсайдерами – санкционированными пользователями), что является вопросом самостоятельного исследования (подробнее рассмотрим ниже). С другой стороны, рассматриваемая опция делает во многом неразрешимыми некоторые задачи защиты информации. В порядке иллюстрации рассмотрим вопрос реализации контроля доступа пользователей к устройствам. Проблема здесь состоит в том, что в большинстве случаев доступ к устройствам осуществляется драйвером, т.е. при фильтрации запроса на доступ на уровне драйвера мы увидим учетную запись System (естественно, что решать вопросы контроля доступа к ресурсам на прикладном уровне просто бессмысленно – будет найдено множество способов обхода такого механизма), вне зависимости от того, какой собственно пользователь запрашивает доступ к ресурсу.

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

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

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

Рис.3.2. Упрощенная схема запуска процесса с правами другого пользователя, реализуемая ОС Windows

Для того чтобы запустить процесс (программу) с правами другого пользователя, пользователь со своей учетной записью запускает программу-проводник, позволяющую запускать соответствующую утилиту, например, runas. В качестве параметров при запуске этой утилиты задается, какой процесс, с правами какого пользователя должен быть запущен, и пароль этого пользователя. Утилита запускается с правами текущего пользователя и взаимодействует с системной службой svchost, запущенной с правами System, которая, в свою очередь, взаимодействует с процессом winlogon, осуществляющим регистрацию входа нового пользователя в систему. При регистрации нового пользователя, потоки, запускаемые процессом winlogon, олицетворяют себя с правами регистрируемого пользователя.

Далее системная служба svchost запускает процесс, запуск которого запросил пользователь, с правами System, после чего, осуществляет смену первичного маркера доступа для запущенного процесса – смену маркера доступа System - на маркер доступа нового пользователя. В результате этого процесс начинает функционировать под учетной записью нового пользователя.

Таким образом, из рис.3.2 следует, что смена первичного маркера доступа осуществляется уже после запуска процесса, который изначально запускается с правами System. Видим, что если идентифицировать субъект доступа парой: идентификатор и эффективный идентификатор, то рассматриваемый процесс будет характеризоваться парой: System, Новый пользователь.

Теперь поговорим о парольном входе пользователя в систему.

Обобщенная классификация основных угроз парольной защите представлена на рис.3.3. Рассмотрим их.

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

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

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

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

Автоматиpованный

Угрозы преодоления парольной защиты

Явные

Скрытые

Физические

Технические

Хищение носителя

Визуальный съем пароля при вводе

Подбор пароля

Автоматический

Съем пароля на защищаемом объекте

Технический съем пароля при вводе

Снифер клавиатуры

Снифер канала

Отключение механизма защиты идентификации и аутентификации

Модификация учетных данных на защищаемом объекте

Замена учетных данных

Сброс пароля

Рис.3.3. Обобщенная классификация угроз преодоления парольной защиты

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

Второй подход предполагает возможность отключить механизм парольной защиты злоумышленником, например, загрузить систему с внешнего носителя (дисковода или CD-ROM); если механизм парольной защиты представляет собой некий процесс (в добавочной системе защиты), то выполнение данного процесса можно остановить средствами системного монитора, либо монитора приложений, например, встроенными средствами в оболочку Far..

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

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

Классификация способов усиления парольной защиты представлены соответственно на рис.3.4 и рис.3.5. На рис.3.4 представлена классификация усиления защиты, по средством изменения способа ввода пароля.

Способы ввода пароля

Консольный (ввод с клавиатуры)

С внешнего носителя

С использованием биометрических характеристик пользователя

Комбинированный

Рис.3.4. Способы ввода пароля

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

В части противодействия угрозе визуального съема пароля могут использоваться внешние носители информации, как от стандартных средств хранения информации, например, flash-устройство, так и предполагающие подключение специальных средств ввода парольной информации – всевозможные электронные ключи, смарт-карты и т.д. На этих носителях записывается пароль, который считывается системой при аутентификации пользователя. Здесь может задаваться достаточно большая длина пароля без угрозы его визуального съема. Применение для ввода пароля стандартного или специального носителя, с точки зрения обеспечиваемого уровня безопасности, практически равноценно, вопрос выбора носителя определяется его ценой, долговечностью, удобством хранения. Недостатком применения внешних носителей информации для ввода пароля является потенциальная угроза его хищения злоумышленником.

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

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

• Комбинирование способа ввода пароля с клавиатуры и способа ввода пароля с внешнего носителя (механизм ввода пароля с клавиатуры может рассматриваться как дополнение к механизму ввода пароля с внешнего носителя), так называемая двух-факторная аутентификация.

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

Посредством задания дополнительных требований к параметрам пароля

Способы усиления пароля

Увеличение длины пароля (числа символов в пароле)

Увеличение алфавита набором символов одного типа для задания пароля

Ограничение на число неверно введенных значений пароля

Ограничение на повторяемость пароля (история паролей)

Ограничение на возможность задания простых паролей

Увеличение алфавита набором типов символов для задания пароля

Посредством включения ограничений на процедуру аутентификации

Ограничение на периодичность смены пароля пользователем

Ограничение на число типов символов в пароле

Рис.3.5. Способы усиления пароля

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

Пусть A – исходный алфавит для задания пароля (некоторое число символов, включая их типы, для назначения пароля), а L – длина пароля. В этих предположениях число возможных парольных комбинаций:

R = f (А,L).

Обозначим вероятность подбора злоумышленником пароля с одной попытки P1 (в предположении, что все парольные комбинации равновероятны: P1 = 1/R). Если для подбора пароля злоумышленником совершается n попыток в единицу времени t, то за интервал времени T (число единиц времени), вероятность подбора пароля злоумышленником:

P = F (A,L,P1,n(t),T).

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

Применение способов усиления пароля, по средством задания дополнительных требований к параметрам пароля в соответствии с зависимостью R = f (А,L), призваны увеличить число возможных парольных комбинаций.

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

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

P = F (A,L,P1,N).

Данное ограничение можно рассматривать как альтернативу применению способов усиления пароля, по средством задания дополнительных требований к параметрам пароля в соответствии с зависимостью R = f (А,L), т.е. уменьшая параметр N, тем самым, можно снижать требования к параметру L, что, как отмечали ранее, крайне важно при использовании механизма парольной защиты, предполагающего ввод пароля с клавиатуры. Очевидно, что без использования данного ограничения, с учетом больших темпов роста производительности компьютеров, приводящего к заметному увеличению параметра n(t), без применения данного ограничения соответственно возрастают требования к параметрам А,L.

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

В системах парольной защиты, может использоваться ограничение на периодичность смены пароля пользователем, которое призвано ограничить возможность использования одного и того же значения пароля в течение сколько-нибудь продолжительного времени (например, более месяца). Как отмечалось, в случае, если не используется ограничение на число неверно введенных значений пароля, вероятность подбора пароля зависит не только от параметра n(t), но и от параметра T. Данное ограничение устанавливается на параметр T, позволяя снизить суммарное число попыток подбора для одного установленного значения пароля.

Вывод. Задача идентификации субъекта доступа «пользователь» при входе в систему решается отдельным механизмом парольной защиты доступа в систему.

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