Аутентификация и авторизация: разница, протоколы (OAuth 2.0, LDAP, JWT) и модели (RBAC, ABAC) | Практическое руководство для DevOps

Основа безопасности: четкое разделение аутентификации и авторизации

Проектирование надежной IT-инфраструктуры начинается с понимания фундаментальных концепций контроля доступа. Аутентификация (Authentication, AuthN) отвечает на вопрос «кто вы?» - это процесс проверки личности пользователя или системы. Авторизация (Authorization, AuthZ) определяет «что вам можно?» - проверка прав на выполнение конкретного действия или доступ к ресурсу после успешной аутентификации. Смешение этих понятий приводит к архитектурным ошибкам, которые снижают безопасность всей среды.

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

Примеры из жизни системного администратора: где что применяется

В повседневной работе администратора эти концепции встречаются постоянно:

Linux: модули PAM (Pluggable Authentication Modules) отвечают за проверку учетных данных при входе в систему или через SSH - это аутентификация. Права на файлы, заданные командой chmod, или правила в файле /etc/sudoers определяют, может пользователь читать, изменять или выполнять файл - это авторизация.
Базы данных: команда CREATE USER в PostgreSQL или MySQL создает учетную запись с паролем - это аутентификация. Команда GRANT SELECT ON table_name TO user_name предоставляет право чтения конкретной таблицы - это авторизация.
Веб-сервер Nginx: модуль auth_basic требует логин и пароль для доступа к директории - это аутентификация. Блок location /admin { allow 192.168.1.10; deny all; } разрешает доступ только с определенного IP - это авторизация на основе атрибута (адреса).
Kubernetes: файл kubeconfig содержит сертификаты или токены для подключения к API кластера - это аутентификация. Объекты Role и RoleBinding определяют, может пользователь создавать Pods или читать Secrets в namespace - это авторизация.

Для быстрого сравнения используйте эту таблицу:

Компонент инфраструктуры	Аутентификация (Кто вы?)	Авторизация (Что вам можно?)
Операционная система (Linux)	Вход по паролю/SSH-ключу через PAM	Права на файлы (chmod), правила sudo
База данных (PostgreSQL)	Соединение с логином и паролем	SQL-права: SELECT, INSERT, UPDATE
Веб-приложение	Ввод логина/пароля на форме	Возможность удалить запись или просмотреть отчет
Kubernetes кластер	Подача токена или сертификата в API	RBAC: Role и RoleBinding

Почему смешение понятий - критическая ошибка в архитектуре

Нечеткое разделение приводит к двум основным рискам. Система может успешно подтвердить личность пользователя, но предоставить ему избыточные права, создавая уязвимость. Например, настроена интеграция с Active Directory для входа в веб-приложение (аутентификация), но внутри приложения все пользователи автоматически получают роль администратора (отсутствие авторизации). Или наоборот - легитимному пользователю отказывают в доступе к необходимым ресурсам из-за неправильно настроенных политик после успешного входа.

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

Как система узнает, кто вы: механизмы и протоколы аутентификации

После определения фундамента переходим к практической реализации проверки личности. Механизмы аутентификации классифицируются по количеству факторов: однофакторная (пароль или ключ), двухфакторная (2FA) и многофакторная (MFA). Для административного доступа к критичным системам двухфакторная аутентификация стала обязательным минимумом.

В корпоративной инфраструктуре управление тысячами учетных записей требует централизации. Основные решения для этого - LDAP и его расширение Active Directory от Microsoft.

LDAP/Active Directory: основа корпоративной инфраструктуры

LDAP (Lightweight Directory Access Protocol) служит протоколом для работы с директориями - централизованными хранилищами информации о пользователях, группах и устройствах. Active Directory (AD) - реализация LDAP от Microsoft с дополнительными службами, включая Kerberos для аутентификации.

Интеграция Linux-сервера с Active Directory стандартизирует управление доступом. Для Ubuntu или CentOS используйте SSSD (System Security Services Daemon).

Основные шаги:

Установить пакеты: sudo apt install sssd-ad sssd-tools realmd (для Ubuntu/Debian).
Настроить корректное время через NTP - это критично для работы Kerberos.
Присоединить сервер к домену командой: sudo realm join --user=admin_user domain.example.com.
Проверить и настроить файл /etc/sssd/sssd.conf, указав домен и параметры поиска.
Обновить /etc/nsswitch.conf для использования SSSD как источника информации о пользователях: passwd: files sss.
Настроить PAM для использования SSSD через файлы в /etc/pam.d/.

После конфигурации проверьте интеграцию командой getent passwd domain_user или id domain_user. Эти команды должны показать информацию о пользователе из AD.

Подробнее о работе с Linux и интеграции различных служб можно узнать в практическом руководстве по администрированию Linux для DevOps и сисадминов.

PAM (Pluggable Authentication Modules): гибкая аутентификация в Linux

PAM предоставляет модульную архитектуру для аутентификации в Linux. Он позволяет подключать разные источники проверки через набор динамических библиотек. Конфигурация PAM состоит из стеков модулей, управляемых файлами в директории /etc/pam.d/.

Основные типы модулей:

auth - проверка учетных данных (пароль, ключ).
account - проверка состояния учетной записи (доступ по времени, ограничения).
password - управление паролями (смена).
session - действия перед и после предоставления доступа (логирование, установка среды).

Пример конфигурации для службы SSH (/etc/pam.d/sshd), требующей сначала пароль, затем одноразовый код из Google Authenticator:

auth required pam_unix.so try_first_pass
auth required pam_google_authenticator.so

Модуль pam_ldap.so позволяет подключить аутентификацию через LDAP. Порядок модулей в стеке критически важен - система выполняет их последовательно.

Двухфакторная аутентификация (2FA): обязательный минимум для админ-доступа

Двухфакторная аутентификация добавляет второй, независимый фактор проверки после первого (обычно пароля). Основные методы: TOTP (Time-based One-Time Password) через приложения типа Google Authenticator или Authy, аппаратные токены (YubiKey), SMS (не рекомендуется из-за уязвимости протокола).

Пошаговая настройка 2FA для SSH на Linux-сервере с использованием PAM и Google Authenticator:

Установить модуль: sudo apt install libpam-google-authenticator.
Для каждого пользователя запустить google-authenticator и следовать инструкциям, сохранив QR-код.
Настроить PAM для SSH как показано выше.
В файле /etc/ssh/sshd_config убедиться, что PasswordAuthentication установлено в yes (или required).
Перезапустить службу SSH: sudo systemctl restart sshd.

Для веб-интерфейсов (TrueNAS, Proxmox) 2FA часто настраивается внутри их админ-панели. Альтернативный подход - использование reverse proxy (например, Nginx) с модулем аутентификации перед основным приложением.

Как система решает, что вам можно: модели контроля доступа (авторизация)

После успешного входа система применяет модель контроля доступа для определения прав. Эволюция моделей идет от простых списков ACL к ролевым и атрибутным системам.

RBAC (Role-Based Access Control): стандарт для Kubernetes и внутренних систем

RBAC управляет доступом через роли. Пользователь или сервисный аккаунт получает роль, которая содержит набор разрешений. Роль затем связывается с субъектом через привязку (Binding).

Три основных компонента:

Пользователь/Сервисный аккаунт (Subject) - субъект, которому нужны права.
Роль (Role/ClusterRole) - набор правил (например, «читать Pods в namespace default»).
Привязка (RoleBinding/ClusterRoleBinding) - связывает роль с субъектом.

Пример YAML-манифеста для создания Role в Kubernetes, разрешающего только чтение Pods в конкретном namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: monitoring
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Пример RoleBinding, присваивающего эту роль пользователю:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: monitoring
  name: read-pods-to-john
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader
subjects:
- kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io

В базах данных модель аналогична. В PostgreSQL создается роль readonly, затем выдаются права: GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly;.

Преимущество RBAC - простота управления для больших групп. Недостаток - «взрыв ролей» (role explosion), когда для уникальных комбинаций прав приходится создавать множество мелких ролей.

ABAC (Attribute-Based Access Control) и политики на основе правил

ABAC оценивает доступ на основе атрибутов субъекта, ресурса, действия и условий среды. Политика описывается правилами типа: «Пользователь из отдела разработки может запускать контейнеры в кластере staging только в рабочее время».

Пример политики AWS IAM в JSON, разрешающей доступ к корзине S3 только с корпоративного IP-адреса:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::project-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "192.168.1.0/24"
        }
      }
    }
  ]
}

В Nginx Plus можно использовать модуль auth_jwt для проверки JWT токена и переменные для динамического контроля доступа на основе claims токена.

Универсальным движком для политик ABAC служит Open Policy Agent (OPA). Он позволяет декларативно описывать политики в отдельном языке (Rego) и применять их к различным системам (Kubernetes, Docker, API).

SELinux и AppArmor: авторизация на уровне ядра (MAC)

SELinux и AppArmor реализуют модель обязательного контроля доступа (Mandatory Access Control, MAC) на уровне ядра Linux. В отличие от дискреционного контроля (DAC), где владелец файла сам назначает права (например, chmod 777), MAC управляется централизованной политикой, которая ограничивает возможности даже владельца.

SELinux присваивает каждому процессу и файлу контекст безопасности (security context). Команда ls -Z показывает контекст файлов, ps -Z - контекст процессов.

Основные режимы работы SELinux:

Enforcing - политика активно применяется и блокирует нарушения.
Permissive - политика проверяется, но нарушения только логируются, не блокируются.
Disabled - SELinux отключен.

Для отладки проблем используйте audit2why или sealert для анализа логов аудита и получения рекомендаций. Базовые рекомендации по настройке: начинайте с режима permissive для составления политики, затем переключайте на enforcing после тестирования.

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

Протоколы для веба и распределенных систем: OAuth 2.0, OpenID Connect, JWT

В современных веб-приложениях и микросервисных архитектурах аутентификация и авторизация реализуются через стандартные протоколы. OAuth 2.0 стал основным протоколом делегирования авторизации для API. OpenID Connect (OIDC) расширяет его для задач аутентификации. JWT служит форматом токенов для передачи утверждений.

OAuth 2.0: делегирование доступа без передачи паролей

OAuth 2.0 позволяет приложению получить ограниченный доступ к ресурсам пользователя на другом сервисе без передачи логина и пароля. Типичный сценарий: веб-приложение хочет получить доступ к календарю пользователя в Google.

Роли в OAuth 2.0:

Resource Owner - пользователь, владеющий данными.
Client - приложение, которое запрашивает доступ.
Authorization Server - сервер, который проверяет пользователя и выдаёт токены (например, сервер Google).
Resource Server - сервер, хранящий данные пользователя (API Google Calendar).

Стандартный и наиболее безопасный поток - Authorization Code Flow:

Приложение направляет пользователя на Authorization Server с параметрами client_id, redirect_uri и запрашиваемыми scope.
Пользователь аутентифицируется на Authorization Server и соглашается предоставить доступ.
Authorization Server перенаправляет пользователя обратно на приложение через redirect_uri, добавляя в URL временный код авторизации (code).
Приложение отправляет этот код вместе со своим client_secret напрямую на Authorization Server (back-channel) и получает access_token.
Приложение использует access_token для запросов к Resource Server.

Implicit Flow, где токен возвращается непосредственно в redirect URI, считается устаревшим и опасным из-за риска утечки токена через браузер.

JWT (JSON Web Tokens): что внутри и как безопасно использовать

JWT - компактный формат для безопасной передачи утверждений между двумя сторонами. Токен состоит из трех частей, разделенных точками: Header, Payload и Signature.

Header определяет тип токена и алгоритм подписи (например, {"alg": "RS256", "typ": "JWT"}). Payload содержит утверждения (claims) о субъекте и дополнительных данных. Стандартные claims включают iss (издатель), exp (время expiration), sub (subject). Signature создается путем подписи объединенного header и payload с использованием секретного ключа или приватного ключа RSA.

Проверить и декодировать JWT можно на сайте jwt.io или с помощью библиотек типа PyJWT для Python.

Критически важные моменты безопасности при использовании JWT:

Всегда проверяйте подписи. Алгоритм RS256 (подпись приватным ключом, проверка публичным) предпочтительнее HS256 (симметричная подпись секретным ключом), так как секрет не должен храниться на клиенте.
Обязательно проверяйте claim exp (время жизни токена) и iss (издатель).
Избегайте использования алгоритма «none» в заголовке, который указывает на отсутствие подписи.

Пример создания и проверки JWT с RS256 в Python:

import jwt
import datetime

# Создание токена (на стороне Authorization Server)
private_key = open('private.pem').read()
token = jwt.encode({
    "sub": "user123",
    "exp": datetime.datetime.utcnow() + datetime.timedelta(hours=1)
}, private_key, algorithm="RS256")

# Проверка токена (на стороне Resource Server)
public_key = open('public.pem').read()
decoded = jwt.decode(token, public_key, algorithms=["RS256"])

Практика: настройка единого входа (SSO) с Keycloak

Keycloak - open-source решение для Identity and Access Management, которое выступает как Identity Provider (IdP) для единого входа (Single Sign-On, SSO). Он поддерживает протоколы OAuth 2.0 и OpenID Connect.

Базовая схема настройки SSO для двух приложений (например, Grafana и Jenkins):

Развернуть Keycloak и создать Realm (домен безопасности).
В Realm создать Clients для Grafana и Jenkins. Для каждого Client указать корректный Redirect URI.
Настроить маппинг атрибутов: какие данные из токена (например, группа, email) передавать приложению.
В Grafana и Jenkins настроить аутентификацию через OIDC, указав URL Keycloak, Client ID и Client Secret.
Пользователь логинится в Keycloak один раз и получает доступ к обоим приложениям без повторного ввода учетных данных.

Важно правильно настроить механизм единого выхода (single logout), чтобы при выходе из одного приложения токены в других также аннулировались.

Для комплексного управления инфраструктурой и автоматизации таких настроек полезно использовать инструменты конфигурационного менеджмента. Их сравнение и практическое применение описаны в практическом гайде по выбору инструмента автоматизации в 2026 году.

Типичные ошибки, риски и рекомендации по построению отказоустойчивой системы

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

Список распространенных уязвимостей и как их избежать

Пароли и секреты в конфигурационных файлах или коде. Используйте специализированные системы управления секретами: HashiCorp Vault, Kubernetes Secrets (с осторожностью, они не шифруются по умолчанию), или секреты в облачных провайдерах (AWS Secrets Manager). Никогда не коммитите секреты в Git.
SSH доступ по паролю. Отключите PasswordAuthentication в /etc/ssh/sshd_config, используйте только ключи. Для критичных систем добавьте двухфакторную аутентификацию через PAM.
Слабые права на файлы токенов или ключей. Приватный ключ для подписи JWT или SSH ключ с правами 644 (readable для других пользователей) - уязвимость. Используйте chmod 600 для файлов секретов и запускайте процессы, использующие их, под отдельными, минимально привилегированными пользователями.
Отсутствие времени жизни (expire) для access_token. Всегда устанавливайте короткое время жизни access_token (например, 15 минут) и используйте механизм refresh_token для его обновления. Это ограничивает риск использования утекшего токена.
Открытый LDAP порт 389 без TLS. Принудительно используйте LDAPS (порт 636) для шифрования трафика. Настройте сервер LDAP/AD на обязательное использование TLS.

Для обеспечения безопасного взаимодействия с веб-сервисами критически важна правильная установка SSL/TLS. Пошаговые инструкции по этому процессу доступны в руководстве по ручной установке SSL-сертификатов на Nginx и Apache в 2026 году.

Checklist для проектирования и аудита системы

Проверьте свою систему с помощью этого списка вопросов:

Есть ли четкое архитектурное разделение между службами аутентификации и авторизации?
Применяется ли принцип наименьших привилегий для пользователей, сервисных аккаунтов и процессов?
Управление учетными записями централизовано (LDAP/AD) или разрознено?
Включена ли двухфакторная аутентификация для всех административных интерфейсов (SSH, веб-админка, базы данных)?
Ведутся ли и регулярно анализируются логи аудита событий входа и изменений прав?
Проверены ли алгоритмы шифрования и подписи (например, в JWT используется RS256, а не HS256 с слабым секретом)?
Актуальны ли версии ПО и протоколов (используется OAuth 2.0, а не устаревший OAuth 1.0; TLS 1.2/1.3, а не SSLv3)?
Существует ли резервная копия или реплика сервера аутентификации (LDAP/IdP) для отказоустойчивости?

Регулярный аудит и автоматизация рутинных проверок значительно повышают устойчивость инфраструктуры. Методы такой автоматизации описаны в практическом гайде по автоматизации инфраструктуры для DevOps и сисадминов.