Как пошагово настроить правила доступа в Authelia

Если у вас уже установлена ​​и работает Authelia, защищающая ваши приложения, следующий шаг — принять решение. Кто может войти, откуда и с каким уровнем аутентификации?Не всем пользователям необходим доступ к одним и тем же услугам, и не все маршруты сопряжены с одинаковым риском.

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

Что контролируют правила доступа Authelia?

Правила определены в этом разделе. access_control из конфигурационного файла. Когда обратный прокси-сервер запрашивает данные Authelia, система анализирует данные запроса и определяет... Какую политику следует применять? прежде чем разрешить или запретить доступ.

Правило может использовать следующие критерии:

• Домен: Определите, какое приложение или поддомены затронуты.
• Ресурс: Данное правило ограничивает маршрут одним маршрутом или набором маршрутов.
• Предмет: Применяет данную политику к конкретным пользователям или группам.
• Сетка: Проверьте IP-адрес, с которого поступил запрос.
• Метод: Разница между запросами GET, POST, PUT, DELETE и другими.
• Консультация: Это позволяет оценивать определенные параметры, содержащиеся в URL-адресе.

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

Как Authelia оценивает правила доступа

Аутелия изучает правила последовательно, сверху внизКак только обнаруживается первое совпадение, удовлетворяющее всем критериям, система применяет свою политику и прекращает проверку последующих совпадений. Если совпадений нет, используется значение default_policy.

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

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'estado.example.com'
      resources:
        - '^/api/health([/?].*)?$'
      policy: 'bypass'

    - domain: 'estado.example.com'
      subject:
        - 'group:admins'
      policy: 'two_factor'

    - domain: 'estado.example.com'
      policy: 'one_factor'

Исключение для /api/health Оно должно располагаться первым. Если бы общее правило домена было размещено первым, Authelia применила бы его немедленно. Исключение никогда не будет достигнуто..

Какую политику доступа следует использовать?

В Authelia действуют четыре основных правила. Каждое из них определяет минимальный уровень, необходимый для выполнения запроса:

• отрицать: Это полностью блокирует доступ к ресурсу.
• обход: Это позволяет получить доступ без аутентификации на Authelia.
• один фактор: Для этого требуется как минимум имя пользователя и пароль.
• двухфакторный Для этого также необходимо заполнить второй совместимый фактор.

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

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'documentos.example.com'
      policy: 'one_factor'

    - domain: 'panel.example.com'
      policy: 'two_factor'

Рекомендуется использовать bypass Используйте с особой осторожностью, так как это отключает аутентификацию для любого соответствующего запроса. Кроме того, не может быть объединен с критерием subjectПотому что Authelia сначала должна аутентифицировать посетителя, чтобы узнать его имя пользователя и группы.

Как создавать правила для домена и поддомена

Критерий domain Это позволяет указать точный домен или список доменов. Также поддерживаются подстановочные знаки для применения одной и той же политики к нескольким поддоменам.

access_control:
  default_policy: 'deny'
  rules:
    - domain:
        - 'grafana.example.com'
        - 'portainer.example.com'
      policy: 'two_factor'

    - domain: '*.interno.example.com'
      policy: 'one_factor'

Неожиданный выбор *.interno.example.com Это повлияет на поддомены, находящиеся по этому адресу. Необходимо заключить его в кавычки, чтобы предотвратить неправильное толкование звездочки в YAML.

Области, используемые в правилах, должны соответствовать одной из областей, определенных в session.cookiesЕсли это не так, то Аутелия запрос будет автоматически отклонендаже если правило кажется правильным.

Как ограничить доступ пользователей и групп

Критерий subject Это позволяет применять политику только к определенным пользователям или группам. Значения должны начинаться с user: o group:.

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'panel.example.com'
      subject:
        - 'group:admins'
      policy: 'two_factor'

    - domain: 'documentos.example.com'
      subject:
        - 'user:ana'
        - 'group:editores'
      policy: 'one_factor'

Во втором примере пользователь сможет ввести ana или любого члена группы editoresЭлементы на основном уровне списка функционируют как альтернативы.

Также можно потребовать, чтобы человек принадлежал к нескольким группам одновременно:

subject:
  - 'user:ana'
  - ['group:admins', 'group:infraestructura']

Это условие соответствует пользователю. ana или с любым лицом, принадлежащим к группы admins e infraestructura в то же время.

Как защитить определенные маршруты с помощью Authelia

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

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'app.example.com'
      resources:
        - '^/admin([/?].*)?$'
      policy: 'two_factor'

    - domain: 'app.example.com'
      policy: 'one_factor'

Выражение защищает /adminа также его подмаршруты и варианты, включающие параметры. Поскольку административное правило является более конкретным, его следует размещать перед общим правилом.

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

Как применять правила на основе исходной сети

Сети можно объявлять, используя отдельные адреса, диапазоны CIDR или многократно используемые группы. Это полезно для обеспечения однофакторной аутентификации в локальной сети или VPN и двухфакторной аутентификации при подключении из интернета.

definitions:
  network:
    red_local:
      - '192.168.1.0/24'
    vpn:
      - '10.8.0.0/24'

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'panel.example.com'
      networks:
        - 'red_local'
        - 'vpn'
      policy: 'one_factor'

    - domain: 'panel.example.com'
      policy: 'two_factor'

Authelia должна корректно получать исходный IP-адрес посетителя. Поэтому прокси-сервер должен отправлять соответствующие заголовки, и только эти заголовки должны быть объявлены как доверенные. прокси-серверы, которые вы фактически контролируетеИспользование заголовков из любого источника позволило бы подделать IP-адрес и обойти сетевое правило.

Хотя технически вы можете подать заявку. bypass</code dentro de la LAN, mantener al menos one_factor suele ser una opción más prudente para paneles sensibles.

Когда использовать правила для HTTP-методов

Критерий methods Это позволяет различать запросы GET, POST, PUT, PATCH, DELETE, OPTIONS и другие распознаваемые методы. Типичный пример использования — разрешение запросов CORS с предварительной проверкой без аутентификации.

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'api.example.com'
      methods:
        - 'OPTIONS'
      policy: 'bypass'

    - domain: 'api.example.com'
      policy: 'two_factor'

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

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

Как проверить, какое правило будет применяться Authelia?

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

docker exec authelia authelia config validate \
  --config /config/configuration.yml

Команда access-control check-policy Это позволяет смоделировать запрос и проверить, какое правило ему подойдёт:

docker exec authelia authelia access-control check-policy \
  --config /config/configuration.yml \
  --url https://panel.example.com/admin \
  --username ana \
  --groups admins,infraestructura \
  --ip 192.168.1.50 \
  --method GET \
  --verbose

В выходных данных определяется первое полное совпадение и указывается, какие критерии были успешными, а какие — нет. Рекомендуется повторить тест с другими пользователями, группами, маршрутами, сетями и методами, прежде чем продолжить. применять правила в производстве.

Распространенные ошибки при настройке правил доступа

Общее правило предшествует исключению.

Аутелия останавливается на первом полностью совпавшем совпадении. Она сначала приводит наиболее специфические правила, а общие оставляет напоследок.

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

Правило bypass не может использовать subjectДля установления личности посетителя Authelia должна потребовать как минимум следующее: one_factor.

Данный домен не охватывается сессионным cookie-файлом.

Убедитесь, что домен приложения соответствует одному из доменов, настроенных в session.cookies то есть, допустимый поддомен.

Регулярное выражение соответствует слишком большому количеству путей.

Закрепите узоры с помощью ^ y $ при необходимости проверьте каждый URL-адрес, используя check-policy перед перезапуском.

Authelia получает неверный IP-адрес.

Проверьте заголовки, передаваемые прокси-сервером, и конфигурацию доверенного прокси. В противном случае правила, основанные на networks Они не будут работать должным образом.

Приложение по-прежнему доступно через свою исходную версию.

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

Один и тот же раздел встречается в нескольких файлах.

Не декларировать access_control В нескольких файлах ожидается автоматическое объединение правил Authelia. Централизуйте этот раздел в одном конфигурационном файле.

При запросе двухфакторной аутентификации (2FA) данные в форме теряются.

Перенаправление во время POST-запроса может привести к потере отправленного содержимого. Избегайте использования правил для каждого метода при реализации внутренних разрешений приложения.

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