«Аутентификация и авторизация — это не просто два слова в требованиях ФСТЭК. Это фундаментальные процессы, которые, будучи спроектированными раздельно, но работая в тандеме, определяют реальную безопасность периметра. Многие уязвимости возникают не из-за отсутствия криптографии, а из-за путаницы в этих концепциях на архитектурном уровне.»
Фундамент контроля доступа: аутентификация против авторизации
В основе любой системы информационной безопасности лежит чёткое разграничение двух процессов. Аутентификация — это процедура проверки и подтверждения заявленной идентичности субъекта (пользователя, устройства, сервиса). Она отвечает на вопрос «Кто вы?». Авторизация — это процесс проверки прав доступа уже аутентифицированного субъекта к конкретным ресурсам или действиям. Она отвечает на вопрос «Что вам разрешено?».
Успешная аутентификация не гарантирует доступ. Пользователь может корректно ввести логин и пароль (доказать, кто он), но получить отказ при попытке открыть финансовый отчёт (ему это не разрешено). Понимание этой последовательности критично для построения защищённых систем, соответствующих требованиям регуляторов.
Методы подтверждения личности: от каталогов до аттестации
Выбор метода аутентификации зависит от требуемого уровня доверия, масштаба инфраструктуры и типа субъекта.
Службы каталогов (Directory Services)
Централизованные хранилища учётных записей и их атрибутов, выступающие единым источником истины для корпоративной инфраструктуры. Позволяют управлять доступом к множеству систем из одной точки. Типичные реализации: Microsoft Active Directory, OpenLDAP, FreeIPA. В облачных сценариях их роль берут на себя сервисы вроде Azure AD (часть Entra ID).
Федеративная аутентификация (Federation)
Модель, при которой проверку идентичности делегируют доверенному стороннему провайдеру (Identity Provider, IdP). После успешной аутентификации IdP выдаёт стандартизированный токен (SAML-assertion или JWT в OIDC), который принимается доверяющими ему приложениями (Service Providers). Это основа технологии единого входа (SSO) между разными доменами и организациями. Ключевые протоколы: SAML 2.0, OpenID Connect (OIDC). OAuth 2.0, вопреки частому заблуждению, — это протокол делегирования авторизации, а не аутентификации, хотя и используется в связке с OIDC.
Аттестация (Attestation)
Метод, при котором личность или состояние системы подтверждается криптографически проверяемым свидетельством от доверенного источника. Например, аппаратный модуль TPM (Trusted Platform Module) генерирует аттестационный отчёт, подтверждающий целостность ПО устройства. Или центр сертификации выдаёт клиентский сертификат X.509. Это краеугольный камень для Zero Trust-архитектур и безопасного подключения IoT-устройств, где важно доверять не только учётным данным, но и состоянию самого клиента.
Смарт-карты и аппаратные ключи
Аутентификация с использованием физического носителя с криптографическим чипом (например, смарт-карта, токен USB/NFC). Главное преимущество — закрытый ключ никогда не покидает защищённую среду токена, что исключает его кражу с диска или из памяти. Для использования требуется наличие самого носителя и знание PIN-кода (двухфакторность). Широко применяется в государственных структурах, финансовом секторе и на объектах КИИ.
Многофакторная аутентификация: что скрывается за кодами
MFA — обязательное требование современных стандартов. Факторы делятся на три категории: знание (пароль), обладание (токен), свойство (биометрия). На практике чаще комбинируют первые два.
| Технология | Принцип работы | Плюсы и риски | Типичное применение |
|---|---|---|---|
| TOTP (Time-based OTP) | Код генерируется на основе общего секрета и текущего времени (обычно с интервалом 30 сек). | Не требует связи с сервером для генерации. Риск: рассинхронизация часов. | Мобильные приложения-аутентификаторы (Google/Microsoft Authenticator). |
| HOTP (HMAC-based OTP) | Код генерируется на основе секрета и счётчика, инкрементируемого при каждой генерации. | Устойчив к рассинхронизации времени. Риск: рассинхронизация счётчика между клиентом и сервером. | Аппаратные токены без точных часов, офлайн-сценарии. |
| Push-уведомления | Запрос на подтверждение входа приходит в виде push-уведомления в доверенное приложение. | Удобство для пользователя. Риск: уязвимость к фишингу «бомбардировкой» уведомлений. | Корпоративные мобильные приложения, современные системы SSO. |
| SMS-коды | Одноразовый код доставляется через сеть мобильного оператора. | Всеобщая доступность. Риск: перехват через SS7, SIM-своппинг, задержки доставки. | Постепенно устаревает из-за рисков, не рекомендуется для привилегированных учётных записей. |
Модели авторизации: от простых ролей к сложным контекстам
После того как система поняла, кто пользователь, нужно решить, что ему можно. Для этого используются разные модели управления доступом.
RBAC (Role-Based Access Control)
Классическая модель, где права назначаются не пользователям напрямую, а ролям. Пользователь получает права через присвоение одной или нескольких ролей. Управление простое и наглядное, хорошо подходит для организаций с чёткой иерархией. Однако в сложных системах может привести к «вздутию» ролей (role explosion), когда для учёта всех комбинаций прав приходится создавать сотни специализированных ролей.
ABAC (Attribute-Based Access Control)
Более гибкая модель, где решение о доступе принимается на основе оценки атрибутов субъекта, объекта, действия и контекста окружения. Политика описывается правилами вроде: «Разрешить доступ к документу, если (отдел_пользователя == отдел_документа) И (уровень_секретности_пользователя >= уровень_секретности_документа) И (время_доступа в рабочее_время)». Позволяет реализовать сложные сценарии, но требует зрелой инфраструктуры для управления и оценки атрибутов.
ReBAC (Relationship-Based Access Control)
Модель, где права определяются отношениями между объектами в графе. Например, в файловом хранилище доступ к папке может быть у её «владельца», «участников» и «гостей», определённых через связи. Или в CRM-системе менеджер может видеть только сделки своих «подчинённых». Особенно актуальна для социальных платформ и систем с пользовательским контентом.
Принципы проектирования и типичные ошибки
Эффективная система контроля доступа строится на нескольких незыблемых принципах, нарушение которых ведёт к уязвимостям.
Обязательные практики
- Принцип наименьших привилегий (PoLP): любой субъект должен получать минимальный набор прав, необходимый для выполнения его задач.
- Разделение обязанностей (SoD): критические операции (например, выпуск платёжного поручения) требуют санкции двух независимых субъектов для предотвращения мошенничества.
- Явный запрет по умолчанию: если для запрашиваемого действия нет явного разрешающего правила, доступ должен блокироваться.
- Непрерывный аудит и логирование: фиксация всех событий аутентификации и авторизации (успешных и неуспешных) в защищённом централизованном хранилище (SIEM) для последующего анализа и расследования инцидентов.
- Регулярный пересмотр прав (Recertification): периодическая (ежеквартальная или ежегодная) проверка актуальности выданных прав руководителями подразделений для борьбы с «раздуванием привилегий».
Распространённые архитектурные ошибки
- Слабое хранение секретов: пароли в открытом виде, использование устаревших хеш-функций (MD5, SHA-1) без «соли».
- Отсутствие MFA для административных интерфейсов и учётных записей с повышенными привилегиями.
- Наследование избыточных прав: присвоение новым пользователям ролей по умолчанию с широкими полномочиями.
- «Мёртвые» сессии: отсутствие механизма принудительного завершения сеансов пользователя при изменении его ролей или отзыве доступа.
- Игнорирование контекста: предоставление доступа без учёта времени суток, географического местоположения, типа устройства или состояния его защиты.
Чек-лист для внедрения
| Задача | Приоритет | Статус | Комментарий |
|---|---|---|---|
| Внедрить MFA для всех внешних и административных сервисов | Высокий | ✅ | Основа для соответствия базовым требованиям. |
| Настроить федеративный SSO для корпоративных приложений | Высокий | 🔄 | Снижает риски, связанные с паролями, улучшает UX. |
| Реализовать RBAC с регулярным пересмотром ролей | Средний | 🔄 | Базовый уровень контроля, требует процессного подхода. |
| Настроить отправку логов доступа в SIEM-систему | Высокий | ✅ | Без этого расследование инцидентов невозможно. |
| Проанализировать сценарии для внедрения ABAC | Низкий | ❌ | Следующий шаг для зрелых систем. |
✅ Выполнено | 🔄 В процессе | ❌ Не начато
Итог: что важно помнить
- Аутентификация и авторизация — разные, но строго последовательные процессы. Их логику нельзя смешивать.
- MFA из рекомендации превратилась в обязательный минимум, особенно для доступа извне.
- Федерация и SSO решают проблему управления множеством паролей, но переносят точку атаки на провайдера идентификации, чью безопасность нужно оценивать так же строго.
- RBAC — хорошая отправная точка, но в динамичных средах рано или поздно потребуются более гибкие модели (ABAC, ReBAC).
- Логирование — не overhead, а единственный способ восстановить картину происшествия. Политики без аудита не работают.
- Без регулярного пересмотра выданных прав любая, даже идеально спроектированная система, со временем накопит «мусорные» привилегии, которые станут вектором для атаки.