«Контроль доступа — это не только про пароли и роли. Это архитектура недоверия по умолчанию, где каждая операция — это суд, а система — строгий судья, проверяющий не только кто ты, но и что тебе позволено. Речь идёт о фундаментальном разграничении между теми, кому система может делегировать полномочия, и всеми остальными.»
Аутентификация и авторизация: два слоя цифрового пропуска
Путаница между этими терминами — распространённая ошибка, которая приводит к уязвимостям в проектировании систем. Их нельзя рассматривать отдельно, но и смешивать — опасно.
Аутентификация отвечает на вопрос «Ты кто?». Это процедура верификации заявленной идентичности субъекта. Она подтверждает факт, что пользователь, система или процесс являются теми, за кого себя выдают. Механизмы: не только пароли или токены, но и биометрические данные, аппаратные ключи, сертификаты.
Авторизация задаёт следующий вопрос: «Что тебе разрешено?». Это процесс проверки прав уже аутентифицированного субъекта на выполнение конкретного действия (чтение, запись, выполнение, удаление) с определённым объектом (файл, запись в БД, API-эндпоинт, физическая дверь).
Последовательность всегда жёсткая: сначала «кто», потом «что». Нельзя определить права для анонима. Попытка авторизации без предварительной аутентификации — сигнал об ошибке или атаке.
Механика контроля: как система принимает решение
В основе любого решения о доступе лежит политика безопасности — формализованный набор правил. На практике она реализуется через механизмы вроде списков контроля доступа (ACL), матриц доступа или систем управления ролями (RBAC).
Когда происходит запрос, система запускает последовательную проверку:
- Идентификация и аутентификация: Субъект предъявляет идентификатор (логин, токен). Система проверяет его подлинность.
- Проверка контекста: Оцениваются дополнительные параметры: время суток, IP-адрес, состояние устройства (установлены ли обновления). В современных системах это этап контекстной авторизации.
- Проверка полномочий: Система сверяет идентификатор субъекта и запрашиваемое действие с политикой безопасности. Здесь решается, соответствует ли запрос правилам.
- Вынесение вердикта и аудит: Решение (разрешить/запретить) исполняется, а само событие — попытка доступа с деталями — записывается в журнал для последующего аудита.
Сравнение в контексте: от физической безопасности до API
Физический периметр: доступ в защищённое помещение
| Этап | Что происходит | Ключевой принцип |
|---|---|---|
| 1. Идентификация | Сотрудник прикладывает пропуск к считывателю. Система видит номер карты. | Заявка идентификатора |
| 2. Аутентификация | Проверка, не аннулирована ли карта, не является ли дубликатом. Может включать пин-код или биометрию. | Подтверждение легитимности идентификатора |
| 3. Авторизация | Сверка с расписанием доступа: разрешено ли этому сотруднику входить в эту дверь в данный день и час. | Проверка прав на действие в данном контексте |
| 4. Результат и аудит | Дверь открывается/остаётся закрытой. В журнал вносится запись: время, ID карты, дверь, результат. | Исполнение решения и фиксация события |
Важный нюанс: сотрудник может быть аутентифицирован (его пропуск настоящий и действующий), но не авторизован для входа в конкретную серверную в ночную смену. Отказ в доступе в этом случае — результат работы политики авторизации.
Программный уровень: вызов метода в микросервисной архитектуре
| Этап | Что происходит | Ключевой принцип |
|---|---|---|
| 1. Идентификация | Микросервис A отправляет запрос к микросервису B, передавая JWT-токен или API-ключ в заголовках. | Предъявление цифрового удостоверения |
| 2. Аутентификация | Сервис B проверяет криптографическую подпись токена, его срок действия и издателя. | Верификация целостности и актуальности учётных данных |
| 3. Авторизация | Из расшифрованного токена извлекаются claims (утверждения) о ролях или scope. Проверяется, есть ли у субъекта право на вызов этого конкретного эндпоинта (например, POST /api/v1/orders). | Сопоставление утверждений о правах с политикой доступа к ресурсу |
| 4. Результат и аудит | Запрос выполняется или возвращается HTTP 403 Forbidden. Метрики и логи записываются в централизованную систему мониторинга. | Обеспечение подотчётности и observability |
Сравнительный анализ авторизованного и неавторизованного субъекта
| Аспект | Авторизованный субъект (персонал, система, сервис) | Неавторизованный субъект |
|---|---|---|
| Статус в системе | Доверенная сущность, прошедшая проверку подлинности и имеющая определённые, ограниченные политикой, права. | Любая иная сущность: не прошедшая аутентификацию, аутентифицированная, но не имеющая нужных прав, или аноним. |
| Взаимодействие с ресурсами | Действует в рамках явно предоставленных полномочий. Запросы оцениваются по политике «что явно разрешено, то разрешено» (whitelist). | Любое взаимодействие блокируется политикой «что явно не запрещено, то запрещено» или, что хуже, получает доступ по умолчанию, если политика не настроена. |
| Последствия действий | Действия могут приводить к изменениям состояния системы, что возлагает ответственность. Каждое действие может быть атрибутировано конкретной сущности. | Попытка действия обычно блокируется и логируется как событие безопасности. В идеале — не может привести к изменению состояния. |
| Обработка системой | Запросы обрабатываются штатным образом. Может применяться повышенный уровень логирования для критических операций. | Запросы должны получать минималистичные, не раскрывающие деталей системы, ответы (например, «404 Not Found» вместо «403 Forbidden» на несуществующий для пользователя ресурс). |
Принципы, которые превращают механизм в стратегию
Правильная настройка разграничения — это не техническая задача, а управленческая. Она основывается на нескольких принципах, закреплённых и в лучших практиках, и в требованиях регуляторов вроде 152-ФЗ и приказов ФСТЭК.
Принцип минимальных привилегий (Least Privilege)
Субъекту предоставляется ровно тот набор прав, который необходим для выполнения его текущих задач, и не более. Это не «на всякий случай». Следствие: права должны оперативно отзываться при смене обязанностей или проекта. Автоматизированный пересмотр прав (рекомендованный, например, в документах ФСТЭК) — не роскошь, а необходимость.
Разделение обязанностей (SoD)
Критичные бизнес-процессы разбиваются на этапы, которые должны выполняться разными людьми или системами. Это не позволяет одному авторизованному субъекту совершить неправомерное действие от начала до конца. Пример: один сотрудник создаёт платёжное поручение, а второй — его утверждает.
Неотвратимость аудита (Accountability)
Любое действие авторизованного субъекта, особенно в отношении критичных активов, должно быть залогировано таким образом, чтобы его невозможно было отрицать (non-repudiation). Журналы должны защищаться от модификации, а их анализ — проводиться регулярно. Именно журналы аудита становятся главным доказательством при расследовании инцидента, показывая цепочку действий от аутентифицированного пользователя.
Защита в глубину (Defense in Depth)
Контроль доступа не должен быть однослойным. После прохождения авторизации на уровне приложения может требоваться дополнительная проверка для доступа к конкретному набору данных внутри него (например, на основе мандатного управления доступом). Отказ на любом из уровней останавливает операцию.
Итог: почему это больше, чем классификация
Различие между авторизованным и неавторизованным персоналом — это не просто ярлыки в системе. Это основа архитектурной философии безопасности, где доверие не предоставляется по умолчанию, а заслуживается и постоянно проверяется. Авторизованный доступ — это всегда временное, ограниченное и контролируемое делегирование полномочий от системы к субъекту.
Ошибки в реализации этой модели — будь то избыточные права, смешение этапов аутентификации и авторизации или отсутствие детального аудита — создают риски, которые сложно обнаружить до момента реализации угрозы. В контексте российских требований корректное разграничение доступа является не пунктом для галочки, а обязательным условием для построения защищённого информационного контура, способного противостоять как внешним, так и внутренним угрозам.