Аутентификация в самохостинге: избавиться от Google

Как настроить самостоятельную аутентификацию в homelab: Keycloak, Authelia и другие решения для независимости от Google и Big Tech.

Не указано

Алексей Кузнецов

Системный администратор20 февраля 2026 г.

Основные проблемы внешней аутентификации:
1. Зависимость от доступности внешнего сервиса
2. Отсутствие контроля над пользовательскими данными
3. Ограничения на кастомизацию
4. Проблемы с соответствием требованиям
5. Риск блокировки аккаунта

Рассматриваемые решения:
- Keycloak: платформа управления доступом и идентификацией
- Authelia: решение для двухфакторной аутентификации и единого входа
- Dex: OpenID Connect провайдер

docker run -d --name keycloak -p 8080:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin quay.io/keycloak/keycloak:latest

server:
  host: 0.0.0.0
  port: 9091
  log_level: info

authelia:
  default_redirection_url: https://yourdomain.com
  session:
    secret: your_session_secret
    expiration: 3600
    inactivity: 1800

server {
    listen 443 ssl http2;
    server_name yourdomain.com;
    
    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    
    location / {
        authelia_forward http://authelia:9091;
        proxy_pass http://your-service;
    }
}

import "golang.org/x/crypto/argon2"

func hashPassword(password string, salt []byte) []byte {
    hash := argon2.IDKey([]byte(password), salt, 3, 64*1024, 4, 32)
    return hash
}

Пошаговый переход:
1. Оценка текущей инфраструктуры
2. Выбор решения
3. Пилотное развертывание
4. Миграция пользователей
5. Постепенная интеграция
6. Полный переход

Самостоятельное размещение инфраструктуры, но все еще зависимость от Google для аутентификации кажется неправильным

Введение: Проблема зависимости от Big Tech для аутентификации в самохостинге

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

Эта зависимость от Big Tech для аутентификации создает несколько проблем:

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

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

Понимание аутентификации в самохостинге: основы и проблемы внешних провайдеров

Основы аутентификации и авторизации

Аутентификация - это процесс подтверждения личности пользователя, в то время как авторизация - это процесс предоставления аутентифицированному пользователю доступа к определенным ресурсам. В современной инфраструктуре эти два процесса тесно связаны и часто реализуются вместе.

Проблемы использования внешних провайдеров аутентификации

Хотя использование внешних провайдеров OAuth/OIDC (таких как Google, GitHub и др.) может показаться простым решением, оно создает ряд проблем для самохостинга:

1. Зависимость от доступности внешнего сервиса: Если сервисы Google или GitHub недоступны, ваши пользователи не смогут войти в систему.
2. Отсутствие контроля над пользовательскими данными: Вы не можете получить полные данные о пользователях и их активности.
3. Ограничения на кастомизацию: Внешние провайдеры часто предоставляют ограниченный набор возможностей для кастомизации процесса аутентификации.
4. Проблемы с соответствием требованиям: Некоторые отрасли или регионы имеют строгие требования к хранению данных, которые могут быть несовместимы с политиками внешних провайдеров.
5. Риск блокировки аккаунта: В случае подозрительной активности или ошибок в настройках, аккаунт разработчика в Google или GitHub может быть заблокирован, что приведет к неработоспособности аутентификации для всех пользователей.

Требования к самостоятельной системе аутентификации

При создании собственной системы аутентификации следует учитывать следующие требования:

1. Безопасность: Система должна обеспечивать защиту от распространенных атак, таких как подмена, перехват сессий, CSRF и т.д.
2. Масштабируемость: Решение должно быть способным обрабатывать растущее количество пользователей и запросов.
3. Интеграция с существующими сервисами: Система должна легко интегрироваться с вашими приложениями и сервисами.
4. Удобство для пользователей: Процесс аутентификации должен быть простым и понятным для конечных пользователей.
5. Гибкость: Система должна поддерживать различные методы аутентификации (пароль, двухфакторная, биометрия и т.д.) и быть расширяемой.

Самостоятельные решения аутентификации: Keycloak, Authelia, Dex и другие

Keycloak: Открытая платформа управления доступом

Keycloak - это открытая платформа управления доступом и идентификацией, разработанная Red Hat. Это мощное решение, которое поддерживает протоколы SAML 2.0 и OpenID Connect (OIDC).

Особенности Keycloak:

• Поддержка различных источников данных (базы данных, LDAP, Active Directory)
• Возможность создания и управления пользователями, ролями и группами
• Поддержка двухфакторной аутентификации
• Адаптивная аутентификация (базовая двухфакторная, условный доступ)
• Веб-администрирование
• Расширяемость через плагины и SPI

Установка Keycloak

Для установки Keycloak можно использовать Docker-контейнер, что является самым простым способом:

docker run -d --name keycloak -p 8080:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin quay.io/keycloak/keycloak:latest

После установки Keycloak будет доступен по адресу http://localhost:8080. Для первого входа используйте пользователя admin с паролем admin (заданным через переменные окружения).

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

version: '3.7'
services:
  keycloak:
    image: quay.io/keycloak/keycloak:latest
    container_name: keycloak
    ports:
      - 8080:8080
    environment:
      KEYCLOAK_USER: admin
      KEYCLOAK_PASSWORD: admin
      KEYCLOAK_IMPORT: /tmp/realm-export.json
    volumes:
      - ./keycloak_data:/opt/keycloak/data
      - ./realm-export.json:/tmp/realm-export.json

Конфигурация Keycloak

1. После входа в админ-панель Keycloak создайте новый realm (область) для вашего проекта.
2. Настройте клиенты (клиенты - это ваши приложения, которые будут использовать аутентификацию Keycloak).
3. Настройте пользователями, ролями и группами.
4. При необходимости импортируйте или экспортируйте конфигурацию realm.

Authelia: Решение для многофакторной аутентификации и единого входа

Authelia - это решение для двухфакторной аутентификации и единого входа, которое фокусируется на безопасности и простоте интеграции.

Особенности Authelia:

• Поддержка двухфакторной аутентификации через TOTP, WebAuthn и U2F
• Интеграция с обратным прокси (Nginx, Traefik, Caddy)
• Многофакторная аутентификация на основе рисков
• Поддержка SSO
• Веб-интерфейс для администрирования

Установка Authelia

Установка Authelia также может быть выполнена с помощью Docker:

docker run -d --name authelia -p 9091:9091 -v /path/to/config:/config authelia/authelia:latest

Пример конфигурации Authelia (/config/configuration.yml):

server:
  host: 0.0.0.0
  port: 9091
  log_level: info

authelia:
  default_redirection_url: https://yourdomain.com
  session:
    secret: your_session_secret
    expiration: 3600 # 1 час
    inactivity: 1800 # 30 минут

  totp:
    issuer: Your Organization
    period: 30

  regulation:
    max_retries: 3
    find_time: 120
    ban_time: 300

  storage:
    encryption_key: your_encryption_key
    local:
      path: /config/db.sqlite3

  identity_validation:
    reset_password:
      jwt_signer_private_key: your_jwt_private_key
      jwt_signer_public_key: your_jwt_public_key

  authentication_backend:
    file:
      path: /config/users_database.yml

  access_control:
    default_policy: deny
    rules:
      - domain: yourdomain.com
        policy: bypass
        resources:
          - "^/api/.*$"
      - domain: yourdomain.com
        policy: two_factor
      - domain: internal.yourdomain.com
        policy: one_factor

  notifiers:
    smtp:
      username: your_smtp_username
      password: your_smtp_password
      host: smtp.yourdomain.com
      port: 587
      from: "authelia@yourdomain.com"
      tls:
        server_name: smtp.yourdomain.com
        skip_verify: false

Dex: OpenID Connect для вашего кластера

Dex - это открытый сервис, реализующий протокол OpenID Connect, который может выступать в роли провайдера идентификации.

Особенности Dex:

• Поддержка различных бэкендов для пользователей (LDAP, GitHub, Google и др.)
• Поддержка SAML
• Легкая интеграция с Kubernetes
• Поддержка WebAuthn и U2F

Установка Dex

Установка Dex может быть выполнена через Helm для Kubernetes:

helm repo add dexidp/dex
helm install my-dex dexidp/dex

Пример конфигурации Dex (config.yaml):

issuer: https://auth.yourdomain.com
storage:
  type: sqlite3
  config:
    file: dex.db
web:
  http: 0.0.0.0:5556
enablePasswordDB: true
staticClients:
  - id: your-app
    redirectURIs:
      - 'https://yourapp.yourdomain.com/callback'
    name: 'Your Application'
    secret: your_client_secret
connectorData:
  - type: mockCallback
    id: mock
    name: Mock

Другие решения

Помимо рассмотренных выше, существуют и другие решения для самостоятельной аутентификации:

• ForgeRock Identity Platform: Комплексное решение для управления идентификацией, но с закрытым исходным кодом.
• Casdoor: Открытая платформа с поддержкой SSO, многофакторной аутентификации и других функций.
• Gluu: Самохостинговая платформа управления идентификацией с открытым исходным кодом.
• Airlock: Решение для защиты веб-приложений с функциями аутентификации.

Интеграция с существующими сервисами: настройка прокси и управление доступом

Использование обратного прокси для защиты сервисов

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

Настройка Nginx с Authelia

Authelia хорошо интегрируется с Nginx, что позволяет легко защитить любые сервисы. Пример конфигурации Nginx:

server {
    listen 443 ssl http2;
    server_name yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    
    location / {
        authelia_forward http://authelia:9091;
        proxy_pass http://your-service;
    }
}

Настройка Traefik с Keycloak

Traefik также может быть настроен для работы с Keycloak. Пример middleware для Traefik:

http:
  middlewares:
    keycloak-auth:
      forwardAuth:
        address: http://keycloak:8080/auth/realms/your-realm/protocol/openid-connect/auth
        trustForwardHeader: true
        authResponseHeaders: X-Auth-User, X-Auth-Email, X-Auth-Roles

  routers:
    your-service:
      rule: "Host(`yourdomain.com`)"
      service: your-service
      middlewares:
        - keycloak-auth

Защита Docker-контейнеров

Для защиты Docker-контейнеров можно использовать решения, такие как authelia-docker-proxy или настроить Nginx в качестве прокси для контейнеров.

version: '3.7'
services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - ./certs:/etc/nginx/certs
    depends_on:
      - your-service
      - authelia

  your-service:
    image: your-service-image
    # Конфигурация вашего сервиса

  authelia:
    image: authelia/authelia:latest
    volumes:
      - ./authelia:/config

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

Для эффективного управления доступом к ресурсам рекомендуется:

1. Создать четкую структуру ролей и разрешений.
2. Использовать группирование пользователей для упрощения управления.
3. Реализовать механизм наследования прав.
4. Регулярно аудировать права доступа.

Безопасность самостоятельной аутентификации: лучшие практики

Безопасность хранения паролей

При самостоятельной реализации системы аутентификации важно правильно обрабатывать пароли:

1. Никогда не храните пароли в открытом виде. Используйте надежные алгоритмы хеширования, такие как Argon2, bcrypt или scrypt.
2. Используйте соль для каждого пароля, чтобы защититься от атак по словарю.
3. Регулярно обновляйте алгоритмы хеширования по мере появления более безопасных вариантов.

Пример использования Argon2 в Go:

import "golang.org/x/crypto/argon2"

func hashPassword(password string, salt []byte) []byte {
    hash := argon2.IDKey([]byte(password), salt, 3, 64*1024, 4, 32)
    return hash
}

Защита от CSRF и XSS атак

1. Используйте токены CSRF для защиты от межсайтовых подделки запросов.
2. Экранируйте все пользовательские данные при отображении на страницах.
3. Используйте безопасные заголовки HTTP (CSP, X-XSS-Protection, X-Content-Type-Options).
4. Регулярно обновляйте зависимости для исправления уязвимостей.

Двухфакторная аутентификация

Обязательная двухфакторная аутентификация значительно повышает безопасность системы:

1. Поддерживайте стандартные методы (TOTP, SMS, email).
2. Рассмотрите возможность использования более безопасных методов (WebAuthn, FIDO2).
3. Реализуйте резервные методы восстановления доступа.

Регулярный аудит и мониторинг

1. Ведите логи всех попыток аутентификации, включая успешные и неудачные.
2. Реализуйте систему оповещений о подозрительной активности.
3. Регулярно проводите аудит прав доступа и пользователей.
4. Проверяйте уязвимости в используемых компонентах.

Резервное копирование и восстановление

1. Регулярно создавайте резервные копии базы данных с пользователями.
2. Храните резервные копии в безопасном месте.
3. Тестируйте процесс восстановления регулярно.

Сравнение с облачной аутентификацией: плюсы, минусы и гибридные подходы

Плюсы самостоятельной аутентификации

1. Полный контроль над данными пользователей: Вы владеете всеми пользовательскими данными и можете контролировать их использование.
2. Отсутствие зависимости от внешних сервисов: Система аутентификации остается работоспособной даже в случае проблем с внешними провайдерами.
3. Гибкость настройки: Вы можете настроить систему в соответствии со своими потребностями.
4. Соответствие требованиям: Легче достичь соответствия отраслевым и региональным требованиям к хранению данных.
5. Снижение затрат в долгосрочной перспективе: После первоначальных затрат на установку и настройку, эксплуатация может быть дешевле подписки на облачные сервисы.

Минусы самостоятельной аутентификации

1. Сложность первоначальной настройки: Требуется времени и знаний для правильной настройки.
2. Обязанности по обслуживанию: Необходимо самостоятельно обновлять систему, исправлять уязвимости и создавать резервные копии.
3. Масштабирование: При большом количестве пользователей может потребоваться масштабирование инфраструктуры.
4. Отсутствие готовых интеграций: Не все приложения и сервисы изначально поддерживают кастомные системы аутентификации.
5. Ответственность за безопасность: Вы несете полную ответственность за безопасность системы аутентификации.

Гибридные подходы

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

1. Основной аутентификационный сервер на собственном оборудовании, с возможностью резервного копирования данных в облако.
2. Использование облачных сервисов для двухфакторной аутентификации (например, SMS или push-уведомления).
3. Локальное управление пользователями, с возможностью синхронизации с облачным каталогом (например, Azure AD или Google Workspace).
4. Использование SAML federation для интеграции с некоторыми облачными сервисами, сохраняя основной контроль в локальной системе.

Пример гибридной конфигурации с использованием Keycloak и Azure AD:

# Настройка Identity Provider в Keycloak для Azure AD
providers:
  - id: azure-ad
    type: oidc
    config:
      clientId: your_azure_ad_client_id
      clientSecret: your_azure_ad_client_secret
      issuerUrl: https://login.microsoftonline.com/your_tenant_id/v2.0
      scopes: openid email profile
      useJwksUrl: true
      claimMappings:
        preferredUsername: email
        email: email
        name: name

Выбор подхода

Выбор между самостоятельной аутентификацией, облачной или гибридной зависит от:

• Масштаба инфраструктуры: Для небольших проектов облачные решения могут быть проще.
• Требований к безопасности: Некоторые отрасли требуют полного контроля над данными.
• Наличие технической экспертизы: Самостоятельная настройка требует компетенций.
• Бюджета: Облачные решения обычно требуют ежемесячных платежей, но не требуют первоначальных инвестиций.
• Требований к соответствию: Некоторые регуляторные требования могут диктовать использование конкретных подходов.

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

Постепенный переход к самостоятельной аутентификации

Переход от облачной аутентификации к самостоятельной может быть осуществлен поэтапно:

1. Оценка текущей инфраструктуры: Определите, какие сервисы используют аутентификацию и как они интегрированы.
2. Выбор решения: Исследуйте и выберите систему аутентификации, которая лучше всего соответствует вашим потребностям.
3. Пилотное развертывание: Настройте систему аутентификации в тестовой среде и протестируйте ее работу с несколькими сервисами.
4. Миграция пользователей: Разработайте план миграции пользователей, включая процедуры сброса паролей и настройки двухфакторной аутентификации.
5. Постепенная интеграция: Последовательно интегрируйте сервисы с новой системой аутентификации.
6. Полный переход: После успешного тестирования и интеграции всех сервисов полностью переведите инфраструктуру на новую систему аутентификации.

Рекомендации по внедрению

1. Начните с малого: Начните с защиты нескольких ключевых сервисов, прежде чем масштабировать решение на всю инфраструктуру.
2. Документируйте процессы: Ведите подробную документацию по настройке и использованию системы.
3. Обучите пользователей и администраторов: Убедитесь, что все понимают, как использовать новую систему.
4. Подготовьте план отката: Имейте план действий в случае проблем с новой системой.
5. Регулярно обновляйте систему: Следите за обновлениями безопасности и вовремя применяйте их.

Будущее самостоятельной аутентификации

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

• Упрощения процесса настройки и управления системами аутентификации.
• Появления новых стандартов и протоколов, улучшающих безопасность и удобство.
• Улучшенной интеграции с различными сервисами и платформами.
• Развития декентрализованных систем идентификации, таких как DID (Decentralized Identifiers).

Заключение

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

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

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