Come configurare le regole di accesso in Authelia passo dopo passo

Se Authelia è già attivo e funzionante e protegge le tue applicazioni, il passo successivo è decidere chi può accedere, da dove e con quale livello di autenticazioneNon tutti gli utenti necessitano di accedere agli stessi servizi, né tutti i percorsi presentano lo stesso rischio.

Le regole di accesso di Authelia consentono di applicare diverse policy in base al dominio, al percorso richiesto, all'utente, ai suoi gruppi, all'indirizzo IP di origine o persino al metodo HTTP. Questo permette di richiedere l'autenticazione a due fattori per un pannello di amministrazione, facilitare l'accesso tramite VPN e bloccare qualsiasi richiesta non esplicitamente autorizzata.

Che cosa controllano le regole di accesso di Authelia?

Le regole sono definite all'interno della sezione access_control dal file di configurazione. Quando il proxy inverso interroga Authelia, il sistema analizza i dati della richiesta e determina quale politica dovrebbe essere applicata prima di consentire o negare l'accesso.

Una regola può utilizzare i seguenti criteri:

• Dominio: Identificare l'applicazione o i sottodomini interessati.
• Risorsa: La regola limita a un solo percorso o a un insieme di percorsi.
• Soggetto: Applica la policy a utenti o gruppi specifici.
• Griglia: Verifica l'indirizzo IP da cui proviene la richiesta.
• Metodo: differenza tra GET, POST, PUT, DELETE o altre richieste.
• Consultazione: Consente di valutare determinati parametri inclusi nell'URL.

Queste politiche riguardano solo le richieste che passano attraverso il meccanismo di autorizzazione del proxy. Se l'applicazione mantiene un porto accessibile direttamenteUn visitatore potrebbe aggirare Authelia accedendo tramite IP e porta.

Come Authelia valuta le regole di accesso

Authelia esamina le regole in sequenza, dall'alto verso il bassoNon appena trova la prima corrispondenza in cui tutti i criteri sono soddisfatti, applica la sua politica e smette di controllare le corrispondenze successive. Se non c'è corrispondenza, utilizza il valore di default_policy.

Ciò significa che le regole più specifiche devono apparire prima di quelle generali. Ad esempio, se si desidera rendere pubblico un endpoint di verifica, proteggere la dashboard con l'autenticazione a due fattori (2FA) e applicare una password al resto, è possibile utilizzare questo ordine:

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'

L'eccezione per /api/health Deve comparire per prima. Se la regola generale del dominio fosse posizionata per prima, Authelia la applicherebbe immediatamente. L'eccezione non si verificherebbe mai..

Quale politica di accesso dovresti utilizzare?

Authelia ha quattro politiche principali. Ognuna di esse determina il livello minimo richiesto per completare la richiesta:

• negare: Blocca completamente l'accesso alla risorsa.
• bypass: Consente l'accesso senza autenticazione su Authelia.
• un fattore: Richiede almeno un nome utente e una password.
• due fattori: richiede anche il completamento di un secondo fattore compatibile.

La configurazione più sicura è utilizzare deny come politica predefinita e consentire solo ciò che è necessario tramite regole esplicite. In questo modo, una nuova applicazione non verrà esposta accidentalmente perché la sua regola non è ancora stata creata.

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

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

Si consiglia di utilizzare bypass Da usare con estrema cautela, poiché rimuove l'autenticazione per qualsiasi richiesta corrispondente. Inoltre, non può essere combinato con il criterio subjectperché Authelia ha bisogno di autenticare prima il visitatore per scoprire il suo nome utente e i gruppi a cui appartiene.

Come creare regole per dominio e sottodominio

Il criterio domain Consente di specificare un dominio esatto o un elenco di domini. Supporta inoltre i caratteri jolly per applicare la stessa policy a più sottodomini.

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

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

La carta jolly *.interno.example.com Ciò avrà effetto sui sottodomini di quell'indirizzo. Deve essere racchiuso tra virgolette per evitare che YAML interpreti erroneamente l'asterisco.

I domini utilizzati nelle regole devono essere coperti da uno dei domini definiti in session.cookiesSe non lo sono, Authelia la richiesta verrà automaticamente rifiutataanche se la regola sembra corretta.

Come limitare l'accesso per utenti e gruppi

Il criterio subject Ciò consente di applicare una policy solo a utenti o gruppi specifici. I valori devono iniziare con 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'

Nel secondo esempio, l'utente potrà inserire ana o qualsiasi membro del gruppo editoresGli elementi al livello principale dell'elenco fungono da alternative.

È inoltre possibile richiedere che una persona appartenga contemporaneamente a più gruppi:

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

Questa condizione corrisponde all'utente ana o con qualsiasi persona appartenente a i gruppi admins e infraestructura allo stesso tempo.

Come proteggere percorsi specifici con Authelia

Il criterio resources Utilizza espressioni regolari per applicare diverse policy all'interno dello stesso dominio. Ciò consente di richiedere l'autenticazione a due fattori (2FA) per un'area amministrativa senza necessariamente imporla al resto dell'applicazione.

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

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

L'espressione protegge /admin, i suoi sottopercorsi e le varianti che includono parametri. Poiché la regola amministrativa è più specifica, dovrebbe essere posizionata prima della regola generale.

Le espressioni devono essere scritte sempre tra virgoletteUna barra, un carattere speciale o una sequenza di escape errata possono impedire l'avvio di Authelia o far sì che la regola copra più percorsi del previsto.

Come applicare le regole in base alla rete di origine

Le reti possono essere dichiarate utilizzando indirizzi individuali, intervalli CIDR o gruppi riutilizzabili. Ciò è utile per richiedere l'autenticazione a singolo fattore dalla rete locale o da una VPN e l'autenticazione a due fattori quando la connessione proviene da Internet.

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 deve ricevere correttamente l'indirizzo IP originale del visitatore. Pertanto, il proxy deve inviare le intestazioni corrispondenti, e solo queste intestazioni devono essere dichiarate attendibili. i proxy che effettivamente controlliAffidarsi alle intestazioni provenienti da qualsiasi fonte consentirebbe di falsificare l'indirizzo IP e di eludere una regola di rete.

Sebbene tecnicamente sia possibile applicare bypass</code dentro de la LAN, mantener al menos one_factor suele ser una opción más prudente para paneles sensibles.

Quando utilizzare le regole del metodo HTTP

Il criterio methods Consente di distinguere tra richieste GET, POST, PUT, PATCH, DELETE, OPTIONS e altri metodi riconosciuti. Un caso d'uso comune è quello di consentire richieste CORS di pre-verifica senza autenticazione.

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

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

Questo criterio non dovrebbe essere utilizzato per aumentare il livello di autenticazione durante l'invio del modulo. Authelia non può conservare il corpo della richiesta quando reindirizza l'utente, quindi una richiesta POST potrebbe perdere i dati inviati.

Quando un'applicazione necessita di autorizzazioni diverse per leggere e modificare le informazioni, di solito è meglio gestire tali autorizzazioni all'interno dell'applicazione stessa o tramite i suoi ruoli.

Come verificare quale regola applicherà Authelia

Prima di riavviare il servizio, è possibile convalidare la sintassi del file dal container:

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

Il comando access-control check-policy Consente di simulare una richiesta e verificare quale regola corrisponderà:

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

L'output identifica la prima corrispondenza completa e mostra quali criteri sono stati soddisfatti e quali no. Si consiglia di ripetere il test con utenti, gruppi, percorsi, reti e metodi diversi prima di procedere. applicare le regole in produzione.

Errori comuni nella configurazione delle regole di accesso

La regola generale precede l'eccezione.

Authelia si ferma alla prima corrispondenza completa. Mette prima le regole più specifiche e lascia per ultime quelle generali.

Il bypass è combinato con un utente o un gruppo

Una regola bypass non posso usare subjectPer accertare l'identità del visitatore, Authelia deve richiedere almeno one_factor.

Il dominio non è coperto dal cookie di sessione

Verificare che il dominio dell'applicazione corrisponda a uno di quelli configurati in session.cookies vale a dire, un sottodominio valido.

L'espressione regolare corrisponde a troppi percorsi

Ancorare i modelli con ^ y $ dove appropriato e controlla ogni URL utilizzando check-policy prima di riavviare.

Authelia riceve un indirizzo IP errato

Controlla le intestazioni inoltrate dal proxy e la sua configurazione proxy attendibile. Altrimenti, le regole basate su networks Non funzioneranno correttamente.

L'applicazione rimane accessibile tramite la sua porta.

Le regole non possono proteggere una connessione che bypassa il proxy. Disabilita il port forwarding diretto e usa un rete interna tra i container.

La stessa sezione compare in diversi file

Non dichiarare access_control in diversi file in attesa che Authelia combini automaticamente le regole. Centralizzare la sezione in un unico file di configurazione.

Un modulo perde dati quando richiede l'autenticazione a due fattori (2FA).

Un reindirizzamento durante una richiesta POST può invalidare il contenuto inviato. Evita di utilizzare regole per metodo per implementare le autorizzazioni interne dell'applicazione.

Configurando correttamente le regole di accesso di Authelia è possibile applicare il principio del minimo privilegio senza dover gestire un sistema di autenticazione separato per ogni servizio. La chiave è stabilire deny Come prassi predefinita, ordina le eccezioni dalla più specifica alla più generale e convalida ogni scenario prima di renderlo disponibile agli utenti reali.