Масштабируемая автоматизация 2FA в инфраструктуре: интеграция FreeRADIUS, Vault и аудит | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Масштабируемая автоматизация 2FA в инфраструктуре: интеграция FreeRADIUS, Vault и аудит

12 мая 2026 9 мин. чтения
Содержание статьи

Ручное управление двухфакторной аутентификацией для десятков или сотен серверов становится узким местом в растущей инфраструктуре. Это руководство предлагает готовое решение для централизации 2FA через FreeRADIUS, интеграции с существующими каталогами LDAP/Active Directory и полной автоматизации жизненного цикла TOTP-секретов с помощью HashiCorp Vault. Вы получите проверенные конфигурационные файлы, скрипты для массовой выдачи ключей и инструкции по настройке детального аудита, критически важного для соответствия регуляторным требованиям, таким как GDPR. Архитектура масштабируется для корпоративных сред и элиминирует рутинные операции.

Проблема масштаба: почему ручная настройка 2FA для серверов больше не работает

Инвестиции в развитие ИИ-инфраструктуры, подобные планируемым SoftBank во Франции, подчеркивают общий тренд на рост и усложнение дата-центров. В такой среде парк серверов, включая стандартные единицы вроде Lenovo ThinkSystem SR250 V2, быстро расширяется. Добавление каждого нового сотрудника или хоста при ручном управлении 2FA требует отдельных действий: генерация секрета, настройка PAM на сервере, передача ключа пользователю. Среднее время настройки одного аккаунта достигает 15-20 минут, а риск конфигурационной ошибки или утери актуального списка доступа растет экспоненциально.

Отзыв доступа при увольнении сотрудника превращается в многоэтапную операцию по всем серверам. Отсутствие единого журнала событий аутентификации затрудняет расследование инцидентов и создает проблемы для соответствия регуляторным нормам, например, GDPR, который требует прозрачного контроля за доступом к персональным данным. Решение лежит в создании централизованной системы, которая, подобно интеграции SMB/CIFS между Linux и Windows для общего доступа к файлам, унифицирует управление учетными данными поверх разнородной инфраструктуры.

Архитектура решения: FreeRADIUS как единая точка входа, интегрированная с вашим каталогом

Ядром системы выступает FreeRADIUS 3.x – сервер, реализующий протокол RADIUS для аутентификации, авторизации и учета (AAA). Поток работы выглядит так: пользователь пытается подключиться по SSH к любому серверу инфраструктуры. SSH-сервер через PAM-модуль перенаправляет запрос на FreeRADIUS. Тот проверяет логин и пароль, обращаясь к центральному каталогу – Active Directory или OpenLDAP. После успешной проверки первого фактора FreeRADIUS запрашивает валидацию одноразового кода TOTP через API HashiCorp Vault. Итоговый ответ (Accept/Reject) возвращается клиенту.

Главное преимущество – использование существующих учетных записей из корпоративного каталога. Блокировка пользователя в AD автоматически лишает его доступа ко всем системам. Это создает единую и непротиворечивую политику безопасности. Для более глубокого понимания различий между аутентификацией и авторизацией и других моделей управления доступом, обратитесь к практическому руководству по аутентификации, авторизации и интеграции LDAP/AD.

Выбор и базовая установка FreeRADIUS

Для большинства дистрибутивов рекомендуется версия из стабильных репозиториев. Установите базовые пакеты:

# Для RHEL/CentOS/Rocky Linux 8/9:
sudo dnf install freeradius freeradius-utils freeradius-ldap
# Для Ubuntu/Debian:
sudo apt install freeradius freeradius-utils freeradius-mod-ldap

После установки основная конфигурация находится в /etc/raddb/. Проверьте работу сервиса: sudo systemctl start radiusd и sudo systemctl enable radiusd.

Настройка модуля ldap для подключения к Active Directory или OpenLDAP

Ключевой шаг – интеграция с каталогом. Отредактируйте файл /etc/raddb/mods-enabled/ldap. Приведем пример для Active Directory:

ldap {
    server = "dc01.yourdomain.local"
    port = 389
    identity = "CN=Radius Service,OU=Service Accounts,DC=yourdomain,DC=local"
    password = "YourSecurePassword"
    base_dn = "DC=yourdomain,DC=local"
    user {
        base_dn = "${..base_dn}"
        filter = "(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})"
    }
    group {
        base_dn = "${..base_dn}"
        filter = "(objectClass=group)"
    }
    tls {
        start_tls = no
    }
    keepalive {
        idle = 60
        probes = 3
        interval = 3
    }
}

Пароль учетной записи службы рекомендуется хранить не в plain text, а в отдельном защищенном файле с ограниченными правами доступа. После настройки проверьте связь с помощью утилиты radtest, предварительно настроив тестового клиента в /etc/raddb/clients.conf.

Автоматизация жизни TOTP-секретов: централизованное управление через HashiCorp Vault

Генерация, распределение и отзыв TOTP-ключей для сотен пользователей вручную нереалистичны. HashiCorp Vault с движком TOTP решает эту проблему, предоставляя центральное API для управления секретами, встроенный аудит и интеграцию с ролевой моделью доступа. Альтернатива – хранение секретов локально в базе FreeRADIUS – не обеспечивает необходимой масштабируемости и удобства автоматизации.

Настройка движка TOTP и политик доступа в Vault

Предполагается, что Vault уже развернут и инициализирован. Включите движок TOTP и создайте политику:

# Включение движка
vault secrets enable totp

# Создание политики доступа (файл policy-totp.hcl)
path "totp/creds/*" {
  capabilities = ["read"]
}
path "totp/keys/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

# Запись политики в Vault
vault policy write totp-manager policy-totp.hcl

Затем настройте метод аутентификации (например, AppRole) для FreeRADIUS-сервера и привяжите созданную политику.

Интеграция FreeRADIUS с Vault: модуль rest

FreeRADIUS будет проверять TOTP-код, отправляя запрос к Vault через модуль rest. Настройте его в /etc/raddb/mods-enabled/rest:

rest {
    vault_verify {
        uri = "https://vault.yourdomain.local:8200/v1/totp/code/${tolower(%{User-Name})}"
        method = 'post'
        body = '{"code": "%{User-Password}"}'
        headers {
            "Content-Type" = "application/json"
            "X-Vault-Token" = "s.your-vault-token-here"
        }
        tls = yes
        timeout = 5
    }
}

Токен Vault следует хранить в секретном файле и подгружать через ${raddb:file_path}. В секции авторизации (/etc/raddb/sites-enabled/default) добавьте вызов этого модуля после успешной LDAP-аутентификации.

Скрипты для массовой выдачи и отзыва ключей

Следующий Python-скрипт (пример) автоматизирует выдачу ключей, извлекая пользователей из LDAP/AD:

#!/usr/bin/env python3
import ldap3, hvac, smtplib
from email.mime.text import MIMEText

# 1. Подключение к LDAP и получение списка пользователей
server = ldap3.Server('ldap://dc01.yourdomain.local')
conn = ldap3.Connection(server, 'CN=Service,OU=...', 'pass', auto_bind=True)
conn.search('OU=Users,DC=...', '(objectClass=user)', attributes=['sAMAccountName', 'mail'])

# 2. Подключение к Vault
vault_client = hvac.Client(url='https://vault...', token='s.vault-token')

# 3. Генерация ключа и отправка email для каждого пользователя
for entry in conn.entries:
    username = entry.sAMAccountName.value
    email = entry.mail.value
    
    # Генерация ключа в Vault
    resp = vault_client.secrets.totp.create_key(
        name=username,
        generate=True,
        issuer="YourCompany",
        account_name=username
    )
    barcode_url = resp['data']['barcode']
    
    # Отправка email с инструкцией и QR-кодом
    msg = MIMEText(f'Ваш ключ 2FA: {barcode_url}')
    msg['Subject'] = 'Настройка двухфакторной аутентификации'
    msg['From'] = 'noreply@yourdomain.local'
    msg['To'] = email
    # ... отправка через SMTP

Для немедленного отзыва ключа достаточно выполнить в Vault: vault delete totp/keys/username. В случае критической ситуации, например, потери администратором ключа, потребуется четкий план аварийного восстановления. Алгоритм действий в такой ситуации детально описан в руководстве по восстановлению доступа при потере ключа 2FA.

Подключение серверов к центральному FreeRADIUS: отказ от локальных паролей

Клиентская настройка сводится к установке PAM-модуля pam_radius на каждом Linux-сервере, который должен использовать централизованную 2FA. Это превращает разовую ручную операцию в автоматизируемый процесс, легко встраиваемый в образы или системы управления конфигурацией.

Настройка PAM-модуля pam_radius на клиентских хостах

Установите пакет и настройте основные файлы:

# Установка (пример для CentOS/RHEL):
sudo yum install pam_radius

# Конфигурация /etc/pam_radius_auth.conf:
# Формат: IP_сервера секрет [timeout]
10.0.1.10 YourSharedSecret 3

# Конфигурация /etc/pam.d/sshd (добавить строку):
auth sufficient pam_radius_auth.so

Общий секрет (shared secret) между клиентом и сервером FreeRADIUS должен быть сложным и уникальным. Его можно генерировать автоматически для каждого нового хоста и хранить в том же Vault. Также убедитесь, что в /etc/ssh/sshd_config разрешена аутентификация по паролю: PasswordAuthentication yes и ChallengeResponseAuthentication yes.

Сценарий автоматического подключения нового хоста (Ansible/Puppet)

Интеграция в инфраструктуру как код (IaC) – следующий уровень автоматизации. Пример таска в Ansible playbook:

- name: Configure client for central 2FA
  hosts: new_linux_servers
  vars:
    radius_server: "10.0.1.10"
    radius_secret: "{{ vault_radius_secret }}" # Секрет из HashiCorp Vault
  tasks:
    - name: Install pam_radius package
      package:
        name: pam_radius
        state: present
    - name: Configure pam_radius_auth.conf
      template:
        src: pam_radius_auth.conf.j2
        dest: /etc/pam_radius_auth.conf
        owner: root
        group: root
        mode: 0600
    - name: Update PAM configuration for SSH
      lineinfile:
        path: /etc/pam.d/sshd
        line: 'auth sufficient pam_radius_auth.so'
        insertbefore: '^auth.*substack.*password-auth'
    - name: Restart sshd service
      service:
        name: sshd
        state: restarted

Этот подход гарантирует идентичную настройку всех серверов и позволяет быстро подключить к системе централизованной аутентификации новые ресурсы, будь то серверы приложений или системы хранения, такие как TrueNAS. Для комплексной защиты самих серверов используйте готовые рекомендации из практического руководства по харденингу и аудиту Linux-серверов.

Аудит и мониторинг: кто, когда и откуда заходил

Настройка детального аудита обязательна не только для безопасности, но и для соответствия стандартам, таким как GDPR, который требует доказательств контроля доступа к данным. Централизованная архитектура с FreeRADIUS и Vault упрощает сбор необходимых логов.

Настройка детального логирования в FreeRADIUS

Активируйте модуль detail для записи полной информации о каждом запросе аутентификации. В файле /etc/raddb/sites-enabled/default в секции post-auth убедитесь, что есть вызов detail.log:

post-auth {
    ...
    detail.log
    ...
}

Настройте сам модуль в /etc/raddb/mods-enabled/detail. Логи будут содержать ключевые поля: User-Name, Calling-Station-Id (IP-адрес клиента), NAS-Identifier (имя сервера, откуда пришел запрос), Reply-Message (результат аутентификации). Пример строки лога: Mon May 12 10:15:30 2026 : Auth: Login OK: [jsmith] (from client ssh-server-01 port 1812).

Анализ логов и создание алертов на подозрительную активность

Собранные логи необходимо анализировать. Простые правила на основе grep или fail2ban можно дополнить интеграцией с SIEM-системой, например, ELK Stack. Примеры сценариев для выявления аномалий:

  • Множество неудачных попыток: grep "Reply-Message = Access-Reject" /var/log/radius/radius.log | awk '{print $8}' | sort | uniq -c | sort -nr – покажет IP-адреса с наибольшим числом отказов.
  • Попытки входа в нерабочее время: Анализ временных меток запросов с 22:00 до 06:00 для учетных записей, не относящихся к службам.
  • Входы с необычных географических локаций: При наличии GeoIP-базы можно сопоставлять IP-адрес Calling-Station-Id с местоположением.

Для автоматического алертинга настройте отправку логов FreeRADIUS в Prometheus через экспортер или напрямую в Alertmanager по заданным правилам. Полный цикл аудита, от сбора логов до генерации отчетов, рассмотрен в полном руководстве по аудиту и защите серверов, где также приведены готовые скрипты для автоматизации.

Типичные проблемы, ограничения и дальнейшее развитие

Представленное решение создает зависимость от доступности сервисов FreeRADIUS и Vault. Для продакшен-сред критически важна настройка отказоустойчивого кластера для каждого из них. Проблемы с синхронизацией времени (NTP) на серверах приведут к сбоям TOTP, так как код зависит от точного времени. Ошибка в общем секрете между клиентом и сервером RADIUS или блокировка портов 1812/1813 файрволом – наиболее частые причины сбоев аутентификации.

Дальнейшее развитие системы включает:

  1. Высокая доступность: Развертывание нескольких экземпляров FreeRADIUS за балансировщиком и настройка репликации Vault.
  2. Расширение поддержки: Интеграция 2FA для других сервисов, таких как веб-панели TrueNAS Scale/Core, Grafana, Jenkins, используя тот же центральный FreeRADIUS.
  3. Углубление аудита: Настройка отправки аудиторских логов Vault о всех операциях с TOTP-ключами в центральную SIEM.

Это решение – надежная база для масштабируемого управления доступом, проверенная на практике. Оно заменяет хаотичные ручные процедуры на предсказуемый, автоматизированный процесс, значительно повышая безопасность и снижая операционную нагрузку на команду DevOps. Для отработки общих навыков администрирования Linux, которые лежат в основе всей инфраструктуры, полезно обратиться к практическому руководству по системному администрированию Linux.

Автоматизация не ограничивается безопасностью. Для ускорения рабочих процессов, связанных с ИИ, вы можете использовать агрегатор API AiTunnel, который предоставляет единый доступ к более чем 200 моделям нейросетей, включая GPT и Claude, с оплатой в рублях и без необходимости VPN.

Поделиться:
Сохранить гайд? В закладки браузера