Контроль доступа

Описание организация контроля доступа в Authelia
Tags:
Categories:

Файл конфигурации configuration.yml

access_control:
  default_policy: 'deny'
  rules:
  - domain: 'private.rabrain.ru'
    domain_regex: '^(\d+\-)?priv-img\.rabrain\.ru$'
    policy: 'one_factor'
    networks:
    - 'internal'
    - '1.1.1.1'
    subject:
    - ['user:adam']
    - ['user:fred']
    - ['group:admins']
    methods:
    - 'GET'
    - 'HEAD'
    resources:
    - '^/api.*'
    query:
    - - operator: 'present'
        key: 'secure'
      - operator: 'absent'
        key: 'insecure'
    - - operator: 'pattern'
        key: 'token'
        value: '^(abc123|zyx789)$'
      - operator: 'not pattern'
        key: 'random'
        value: '^(1|2)$'

Опции

default_policy

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

rules

Правила имеют множество параметров настройки. Правило совпадает, если все критерии правила соответствуют запросу, за исключением политики, которая применяется к запросу.

Правило определяет две основные вещи:
  • политика, применяемая при совпадении всех критериев
  • критерии соответствия запроса, представленного обратному прокси
Критерии разбиты на несколько частей:
  • domain: домен или список доменов, на которые направлен запрос.
  • domain_regex: regex-форма домена.
  • resources: шаблон или список шаблонов, которым должен соответствовать путь.
  • subject: пользователь или группа пользователей, для которых нужно определить политику.
  • networks: сетевые адреса, диапазоны (нотация CIDR) или группы, из которых исходит запрос.
  • methods: http-методы, используемые в запросе.

Правило выполняется, если все критерии правила совпадают. Правила оцениваются в последовательном порядке в соответствии с концепцией 1 сопоставления правил.

domain

Требуется: Этот критерий и/или критерий domain_regex являются обязательными.

Этот критерий соответствует имени домена и имеет два способа настройки: в виде одной строки или в виде списка строк. Если это список строк, правило будет соответствовать любому из доменов в списке, совпадающему с доменом запроса. При использовании в сочетании с domain_regex правило будет соответствовать критериям domain или domain_regex.

access_control:
  rules:
  - domain: '*.rabrain.ru'
    policy: 'bypass'
  - domain:
    - '*.rabrain.ru'
    policy: 'bypass'

access_control:
  rules:
  - domain: ['apple.rabrain.ru', 'banana.rabrain.ru']
    policy: 'bypass'
  - domain:
    - 'apple.rabrain.ru'
    - 'banana.rabrain.ru'
    policy: 'bypass'

access_control:
  rules:
  - domain: 'apple.rabrain.ru'
    domain_regex: '^(pub|img)-data\.rabrain\.ru$'
    policy: bypass

domain_regex

Требуется: Этот критерий и/или критерий домена являются обязательными.

Этот критерий соответствует имени домена и имеет два способа настройки: в виде одной строки или в виде списка строк. Если это список строк, правило будет соответствовать, когда любой из доменов в списке совпадает с доменом запроса. При использовании в сочетании с domain правило будет соответствовать либо критерию domain, либо критерию domain_regex.

access_control:
  rules:
  - domain_regex:
    - '^user-(?P<User>\w+)\.rabrain\.ru$'
    - '^group-(?P<Group>\w+)\.rabrain\.ru$'
    policy: 'one_factor'

access_control:
  rules:
  - domain: 'protected.rabrain.ru'
  - domain_regex: '^(img|data)-private\.rabrain\.ru'
    policy: 'one_factor'

policy

Конкретная политика, которую следует применить к выбранному правилу. Это не критерии для совпадения, это действие, которое нужно предпринять при совпадении.

subject

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

Тип subject Префикс Описание
User user: Сопоставляет имя пользователя.
Group group: Определяет, есть ли у пользователя группа с таким именем.
OAuth 2.0 Client oauth2:client: Определяет, был ли запрос авторизован с помощью токена, выданного клиентом с указанным идентификатором, использующим тип гранта client_credentials. 
access_control:
  rules:
  - domain: 'rabrain.ru'
    policy: 'two_factor'
    subject:
    - 'user:john'
    - ['group:admin', 'group:app-name']
    - 'group:super-admin'
  - domain: 'rabrain.ru'
    policy: 'two_factor'
    subject:
    - ['user:john']
    - ['group:admin', 'group:app-name']
    - ['group:super-admin']

access_control:
  rules:
  - domain: 'rabrain.ru'
    policy: 'one_factor'
    subject: 'group:super-admin'
  - domain: 'rabrain.ru'
    policy: 'one_factor'
    subject:
    - 'group:super-admin'
  - domain: 'rabrain.ru'
    policy: 'one_factor'
    subject:
    - ['group:super-admin']

methods

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

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

RFC Methods Additional Documentation
RFC7231 GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE MDN
RFC5789 PATCH MDN
RFC4918 PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK 
access_control:
  rules:
  - domain: 'rabrain.ru'
    policy: 'bypass'
    methods:
    - 'OPTIONS'

Обход OPTIONS-запросов к домену rabrain.ru.

networks

Эти критерии состоят из списка значений, которые могут быть IP-адресом, диапазоном сетевых адресов в нотации CIDR или именованным определением сети. Он сопоставляет первый адрес в заголовке X-Forwarded-For, или, если их нет, он возвращается к IP-адресу TCP-источника пакета. По этой причине важно правильно настроить прокси-сервер для точного соответствия запросов этим критериям. Примечание: вы можете комбинировать CIDR-сети с правилами псевдонимов по своему усмотрению.

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

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

definitions:
  network:
    internal:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/18'
access_control:
  default_policy: 'two_factor'
  rules:
  - domain: 'secure.rabrain.ru'
    policy: 'one_factor'
    networks:
    - '10.0.0.0/8'
    - '172.16.0.0/12'
    - '192.168.0.0/18'
    - '112.134.145.167/32'
  - domain: 'secure.rabrain.ru'
    policy: 'one_factor'
    networks:
    - 'internal'
    - '112.134.145.167/32'
  - domain: 'secure.rabrain.ru'
    policy: 'two_factor'

resources

Этот критерий соответствует пути и запросу запроса с помощью регулярных выражений. Правило выражается в виде списка строк. Если любое из регулярных выражений в списке соответствует запросу, оно считается совпавшим. Полезный инструмент для отладки этих регулярных выражений называется Regex 101 (убедитесь, что вы выбрали опцию Golang).

access_control:
  rules:
  - domain: 'app.rabrain.ru'
    policy: 'bypass'
    resources:
    - '^/api([/?].*)?$'

query

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

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

key

Ключ аргумента запроса для проверки.

value

Значение, по которому будет выполняться проверка. Оно необходимо, если оператор отсутствует или присутствует. Рекомендуется, чтобы это значение всегда заключалось в кавычки, как показано в примерах.

operator

Оператор правила для этого правила.

access_control:
  rules:
    - domain: 'app.rabrain.ru'
      policy: 'bypass'
      query:
      - - operator: 'present'
          key: 'secure'
        - operator: 'absent'
          key: 'insecure'
      - - operator: 'pattern'
          key: 'token'
          value: '^(abc123|zyx789)$'
        - operator: 'not pattern'
          key: 'random'
          value: '^(1|2)$'

Policies

Политика первого подходящего правила в списке определяет политику, применяемую к запросу, если ни одно правило не соответствует запросу, применяется политика по умолчанию (default_policy).

deny

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

bypass

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

one_factor

Эта политика требует, чтобы пользователь как минимум успешно выполнил 1FA (имя пользователя и пароль). Это означает, что если пользователь выполнил 2FA, ему будет разрешен доступ к ресурсу.

two_factor

Эта политика требует от пользователя успешного выполнения 2FA. В настоящее время это самый высокий уровень политики аутентификации.

Сопоставление правил

Есть две важные концепции, которые необходимо понимать, когда речь идет о сопоставлении правил.

С помощью команды authelia access-control check-policy можно легко определить, соответствует ли раздел правил управления доступом заданному запросу и почему он не соответствует.

Концепция сопоставления правил 1: последовательный порядок

Правила сопоставляются в последовательном порядке. Первая запись в списке, в которой совпадают все критерии, является правилом, которое применяется. Некоторые критерии правил дополнительно допускают список критериев, когда один из этих критериев в списке соответствует запросу, этот критерий считается подходящим для данного конкретного правила.

Например, следующее правило будет считать запросы на rabrain.ru или любой поддомен rabrain.ru соответствующими, если они имеют путь /api или если они начинаются с /api/. Это означает, что второе правило для app.rabrain.ru не будет рассматриваться, если запрос будет направлен на https://app.rabrain.ru/api, потому что первое правило совпадает с этим запросом.

- domain:
    - 'rabrain.ru'
    - '*.rabrain.ru'
  policy: 'bypass'
  resources:
    - '^/api$'
    - '^/api/'
- domain:
    - 'app.rabrain.ru'
  policy: 'two_factor'

Концепция соответствия правил 2: Критерии субъекта требуют аутентификации

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

  • Сам критерий субъекта
  • Критерий domain_regex, когда он содержит именованные группы Regex.

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

Именованные группы регексов

Некоторые критерии допускают совпадение с именованными группами regex. Эти группы мы принимаем: User и Group

Именованные группы regex представлены синтаксисом (?P\w+), где User - имя группы, а \w+ - шаблон для области шаблона, которая должна быть сравнена со значением совпадения.

definitions:
  network:
    internal:
      - '10.10.0.0/16'
      - '192.168.2.0/24'
    vpn: '10.9.0.0/16'

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'public.rabrain.ru'
      policy: 'bypass'

    - domain: '*.rabrain.ru'
      policy: 'bypass'
      methods:
        - 'OPTIONS'

    - domain: 'secure.rabrain.ru'
      policy: 'one_factor'
      networks:
        - 'internal'
        - 'vpn'
        - '192.168.1.0/24'
        - '10.0.0.1'

    - domain:
      - 'secure.rabrain.ru'
      - 'private.rabrain.ru'
      policy: 'two_factor'

    - domain: 'singlefactor.rabrain.ru'
      policy: 'one_factor'

    - domain: 'mx2.mail.rabrain.ru'
      subject: 'group:admins'
      policy: 'deny'

    - domain: '*.rabrain.ru'
      subject:
        - 'group:admins'
        - 'group:moderators'
      policy: 'two_factor'

    - domain: 'dev.rabrain.ru'
      resources:
      - '^/groups/dev/.*$'
      subject: 'group:dev'
      policy: 'two_factor'

    - domain: 'dev.rabrain.ru'
      resources:
      - '^/users/john/.*$'
      subject:
      - ['group:dev', 'user:john']
      - 'group:admins'
      policy: 'two_factor'