CompTIA SY0-701: Управление идентификацией и доступом — Руководство по подготовке

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Часть CompTIA Security+ SY0-701 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов CompTIA, или пройдите тесты на время на ExamRoll.io.

Управление идентификацией и доступом (IAM) — это дисциплина, обеспечивающая предоставление нужным субъектам (пользователям, сервисам и устройствам) правильного доступа к нужным ресурсам в нужное время и только на необходимый срок. Она основывается на двух концептуально различных, но часто и опасно смешиваемых понятиях: аутентификация, которая доказывает, кем является субъект, и авторизация, которая определяет, что этот аутентифицированный субъект может делать. Пользователь, входящий в систему на рабочей станции с помощью отпечатка пальца, прошел аутентификацию; сможет ли этот пользователь открыть базу данных по заработной плате — это вопрос авторизации. Любая схема контроля, размывающая эти два понятия, создает уязвимости.

Факторы аутентификации и многофакторная аутентификация

Факторы аутентификации традиционно делятся на пять категорий: что-то, что вы знаете (пароли, PIN-коды), что-то, что у вас есть (смарт-карты, аппаратные токены, телефоны с TOTP-приложениями), что-то, чем вы являетесь (отпечаток пальца, сетчатка глаза, геометрия лица), где вы находитесь (геолокация или контекст на основе сети) и что-то, что вы делаете (поведенческая биометрия, например, ритм набора текста). Многофакторная аутентификация (MFA) требует подтверждения как минимум из двух разных категорий. Пароль в сочетании с секретным вопросом не является MFA — оба относятся к категории «что-то, что вы знаете». Пароль в сочетании с TOTP-кодом из Google Authenticator — это MFA.

Аппаратные токены бывают нескольких видов. Ключи безопасности FIDO2/WebAuthn, такие как YubiKey, используют асимметричную криптографию: закрытый ключ никогда не покидает устройство, а сервер хранит только открытый ключ, что защищает от фишинга и атак повторного воспроизведения (replay attacks). Токены HOTP генерируют одноразовые пароли на основе счетчика; токены TOTP генерируют их на основе текущего времени с использованием конструкции HMAC-SHA1:

TOTP = HMAC-SHA1(shared_secret, floor(current_unix_time / 30))

Смарт-карты, обычно карты PIV или CAC в правительственных средах, хранят сертификат X.509 и закрытый ключ на защищенном от несанкционированного доступа чипе. Предъявление карты в сочетании с PIN-кодом удовлетворяет двум факторам и позволяет выполнять аутентификацию на основе сертификата в таких системах, как Active Directory, через Kerberos PKINIT.

MFA — это самый эффективный метод защиты от кражи учетных данных. Когда пользователи сообщают о входах в систему с IP-адресов, с которых они не работали, сброс паролей устраняет симптом; внедрение MFA устраняет первопричину, поскольку одного украденного пароля становится недостаточно.

Система единого входа и федерация

Система единого входа (SSO) позволяет пользователю аутентифицироваться один раз и получать доступ к нескольким приложениям без повторного ввода учетных данных. Федерация расширяет эту возможность за пределы организационных границ или границ доверия — поставщик удостоверений (IdP) в одном домене ручается за пользователя перед поставщиком услуг (SP) в другом. Самое распространенное заблуждение здесь — считать SAML и OAuth взаимозаменяемыми; они решают разные задачи.

SAML 2.0 — это протокол на основе XML, предназначенный для корпоративного SSO и передачи утверждений аутентификации. Когда пользователь запрашивает SaaS-приложение, SP перенаправляет браузер к IdP, который аутентифицирует пользователя и возвращает подписанное утверждение SAML (SAML assertion), содержащее атрибуты идентификации. Это стандартный механизм, позволяющий сотрудникам получать доступ к облачным приложениям, таким как Salesforce или Workday, используя корпоративные учетные данные Active Directory.

OAuth 2.0 — это фреймворк авторизации, а не протокол аутентификации. Он предоставляет стороннему приложению делегированный доступ к ресурсу от имени пользователя с помощью токенов доступа. Разрешение приложению публиковать записи в вашей ленте Twitter — это пример потока OAuth. OpenID Connect (OIDC) — это слой идентификации, построенный поверх OAuth 2.0, который добавляет id_token (JWT), предоставляющий утверждения аутентификации. Именно это делает возможной функцию «Войти через Google».

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

Модели управления доступом

После установления личности модель управления доступом регулирует решения об авторизации. Дискреционное (избирательное) управление доступом (DAC) позволяет владельцам ресурсов устанавливать разрешения, обычно через списки контроля доступа (ACL). Мандатное управление доступом (MAC) централизованно применяет политику на основе меток и уровней допуска, что распространено в военных системах и реализуется с помощью таких фреймворков, как SELinux. Ролевое управление доступом (RBAC) назначает разрешения ролям, а пользователей — ролям. Роль «Аналитик по биллингу» несет определенный набор разрешений, и пользователи наследуют их через членство в роли. Управление доступом на основе атрибутов (ABAC) оценивает политики на основе атрибутов субъекта, ресурса, действия и окружения, что позволяет создавать правила вроде «разрешить доступ на чтение к файлам отдела кадров только в рабочее время с корпоративных устройств».

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

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

icacls C:\Finance /grant "Domain\Finance-RO:(OI)(CI)R"

Управление привилегированным доступом

Привилегированные учётные записи — администраторы домена, root, системные администраторы баз данных, корневые учётные записи облака, сервисные учётные записи — это главная ценность любой среды. Системы управления привилегированным доступом (Privileged Access Management, PAM), такие как CyberArk, BeyondTrust или HashiCorp Vault, обеспечивают контроль над этими учётными записями: учётные данные помещаются в хранилище и ротируются автоматически, сессии записываются, для получения доступа требуется обоснование и часто — одобрение, а пароли нередко бывают одноразовыми или эфемерными.

Доступ «Точно в срок» (Just-in-time, JIT) повышает привилегии только на время выполнения конкретной задачи, устраняя постоянные права администратора. Разработчик, которому нужно выполнить миграцию базы данных, получает ограниченные по времени учётные данные, которые автоматически истекают через 30 минут — таким образом, нет постоянной привилегированной учётной записи, которую можно было бы украсть. Privileged Identity Management (PIM) в Azure AD реализует этот подход нативно, требуя рабочих процессов утверждения и повторной аутентификации через MFA перед повышением привилегий.

Сервисные учётные записи представляют собой отдельную проблему. Они часто имеют избыточные привилегии, их пароли редко меняются, а их использование редко подвергается аудиту. Управляемые сервисные учётные записи (Managed Service Accounts, MSA) и групповые управляемые сервисные учётные записи (group Managed Service Accounts, gMSA) в Active Directory автоматизируют ротацию паролей и полностью устраняют необходимость для людей знать учётные данные сервисных аккаунтов.

Службы каталогов и предоставление доступа (провижининг)

Active Directory (AD) остаётся доминирующим локальным хранилищем удостоверений. Пользователи, компьютеры и группы организуются в организационные единицы (Organizational Units, OU), а объекты групповой политики (Group Policy Objects, GPO) иерархически применяют настройки конфигурации и безопасности. Отношения доверия AD распространяют аутентификацию между доменами и лесами. Azure Active Directory (Entra ID) расширяет эти концепции на облако, добавляя политики условного доступа, оценку рисков для защиты удостоверений и бесшовную интеграцию с тысячами SaaS-приложений.

LDAP (Lightweight Directory Access Protocol) — это базовый протокол для запросов к службам каталогов. RADIUS централизует аутентификацию для доступа к сети — VPN, Wi-Fi и проводная аутентификация 802.1X обычно выполняются через RADIUS-сервер, работающий на базе AD. TACACS+ выполняет аналогичную роль для администрирования сетевых устройств, с дополнительным преимуществом разделения аутентификации, авторизации и учёта на отдельные фазы.

Предоставление и отзыв доступа для пользователей должны быть тесно связаны с процессами отдела кадров. Самый частый сбой в IAM — это бесхозная учётная запись: аккаунт бывшего сотрудника в Active Directory, который остаётся активным недели или месяцы после увольнения. Автоматическое предоставление доступа через SCIM (System for Cross-domain Identity Management) или коннекторы от HR к AD, в сочетании с обязательными чек-листами по отзыву доступа, устраняет этот пробел.

Практический сценарий: Компрометация учётных данных через бесхозную учётную запись

ИТ-команда производственной компании обнаружила необычный доступ в нерабочее время к своей ERP-системе с сервисной учётной записи, которая была создана для ныне прекращённого проекта интеграции. Учётная запись имела права пользователя домена и никогда не проверялась в ходе ежеквартальных ревизий доступа, поскольку не была связана с конкретным сотрудником. Злоумышленник, купивший учётные данные из дампа в даркнете, использовал эту учётную запись для перечисления файловых ресурсов, кражи данных о ценах и обеспечения постоянного присутствия в системе через запланированную задачу. Утечка была обнаружена только тогда, когда поставщик ERP-системы заметил аномальные шаблоны вызовов API. Первопричиной был неудачный процесс отзыва доступа — интеграция была выведена из эксплуатации, но учётная запись так и не была отключена. Внедрение системы PAM с автоматическим обнаружением бесхозных учётных записей и обязательными циклами проверки выявило бы эту учётную запись задолго до того, как она была использована.

← Управление · Все домены · Угрозы →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →