Як налаштувати правила доступу в Authelia крок за кроком

Якщо у вас вже запущено та захищено Authelia, яка захищає ваші програми, наступним кроком буде рішення хто може входити, звідки та з яким рівнем автентифікаціїНе всім користувачам потрібен доступ до однакових послуг, і не всі маршрути становлять однаковий ризик.

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

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

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

Правило може використовувати такі критерії:

• Домен: Визначте уражену програму або піддомени.
• Ресурс: Правило обмежує один маршрут або набір маршрутів.
• Тема: застосовує політику до певних користувачів або груп.
• Сітка: Перевірте IP-адресу, з якої надходить запит.
• Метод: різниця між GET, POST, PUT, DELETE або іншими запитами.
• Консультація: Це дозволяє оцінювати певні параметри, включені до URL-адреси.

Ці політики впливають лише на запити, які проходять через механізм авторизації проксі-сервера. Якщо програма підтримує порт з прямим доступомВідвідувач може обійти Authelia, увійшовши через IP-адресу та порт.

Як Authelia оцінює правила доступу

Аутелія вивчає правила послідовно, зверху внизЩойно знайдеться перший збіг, де виконуються всі критерії, застосовується його політика та припиняється перевірка наступних збігів. Якщо жодного збігу немає, використовується значення default_policy.

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

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 Він використовує регулярні вирази для застосування різних політик в межах одного домену. Це дозволяє вимагати двофакторну аутентифікацію (2FA) для адміністративної області, не обов'язково нав'язуючи її решті програми.

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

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

Вираз захищає /admin, його підмаршрути та варіанти, що містять параметри. Оскільки адміністративне правило є більш конкретним, його слід розміщувати перед загальним правилом.

Вирази потрібно записати завжди в лапкахСлеш, спеціальний символ або неправильний escape-символ можуть перешкодити запуску 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 Як політика за замовчуванням, упорядковуйте винятки від найбільш специфічних до найзагальніших та перевіряйте кожен сценарій, перш ніж надавати його реальним користувачам.