Индивидуальное задание. 
Программно-аппаратная защита информации

Идентификация пользователей КС — субъектов доступа к данным

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

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

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

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