Hozzáférési szabályok konfigurálása az Autheliában lépésről lépésre

Ha már fut az Authelia, és védi az alkalmazásait, a következő lépés a következő döntés meghozatala ki, honnan és milyen szintű hitelesítéssel tud belépniNem minden felhasználónak kell hozzáférnie ugyanazokhoz a szolgáltatásokhoz, és nem minden útvonal jelent ugyanolyan kockázatot.

Az Authelia hozzáférési szabályai lehetővé teszik különböző szabályzatok alkalmazását a domain, a kért elérési út, a felhasználó, a csoportjai, a forrás IP-cím vagy akár a HTTP-metódus alapján. Ez lehetővé teszi kétfaktoros hitelesítés megkövetelését az adminisztrációs panelen, a VPN-en keresztüli egyszerűbb hozzáférést, és a nem kifejezetten engedélyezett kérések blokkolását.

Mit szabályoznak az Authelia hozzáférési szabályai?

A szabályok a szakaszon belül vannak meghatározva access_control a konfigurációs fájlból. Amikor a fordított proxy lekérdezi az Autheliát, a rendszer elemzi a kérés adatait, és meghatározza milyen irányelvet kell alkalmazni mielőtt engedélyezné vagy megtagadná a hozzáférést.

Egy szabály a következő kritériumokat használhatja:

• Domain: Azonosítsa az érintett alkalmazást vagy aldoméneket.
• Forrás: A szabály egy útvonalra vagy útvonalcsoportra korlátozódik.
• Téma: a szabályzatot adott felhasználókra vagy csoportokra alkalmazza.
• Rács: Ellenőrizd az IP-címet, ahonnan a kérés származik.
• Módszer: különbség a GET, POST, PUT, DELETE vagy más kérések között.
• Konzultáció: Lehetővé teszi az URL-ben található bizonyos paraméterek kiértékelését.

Ezek a szabályzatok csak azokat a kéréseket érintik, amelyek áthaladnak a proxy engedélyezési mechanizmusán. Ha az alkalmazás fenntartja a közvetlenül elérhető kikötőEgy látogató megkerülheti az Autheliát IP-címen és porton keresztüli belépéssel.

Hogyan értékeli az Authelia a hozzáférési szabályokat

Authelia megvizsgálja a szabályokat egymás után, fentről lefeléAmint megtalálja az első olyan egyezést, ahol minden feltétel teljesül, alkalmazza a szabályzatát, és leállítja a további egyezések ellenőrzését. Ha egyik sem egyezik, akkor a következő értéket használja: default_policy.

Ez azt jelenti, hogy a legspecifikusabb szabályoknak az általánosak előtt kell megjelenniük. Például, ha egy ellenőrzési végpontot nyilvánossá szeretne tenni, a műszerfalat 2FA-val szeretné védeni, és a többit jelszóval szeretné ellátni, akkor a következő sorrendet használhatja:

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'

Kivételt képez /api/health Elsőként kell szerepelnie. Ha a domain általános szabálya elsőként szerepelne, Authelia azonnal alkalmazná azt. A kivétel soha nem valósulna meg..

Melyik hozzáférési szabályzatot érdemes használni

Az Autheliának négy fő szabályzata van. Mindegyik meghatározza a kérés teljesítéséhez szükséges minimális szintet:

• tagadni: Teljesen blokkolja az erőforráshoz való hozzáférést.
• kitérő: Hitelesítés nélkül teszi lehetővé a hozzáférést az Authelián.
• egy_tényező: Legalább felhasználónév és jelszó szükséges hozzá.
• két_tényező: egy második kompatibilis tényező kitöltését is megköveteli.

A legbiztonságosabb konfiguráció a következő: deny alapértelmezett szabályzatként, és csak a legszükségesebbeket engedélyezi explicit szabályokon keresztül. Így egy új alkalmazás nem kerül véletlenül nyilvánosságra, mert a szabálya még nem jött létre.

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

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

Célszerű használni bypass Használja rendkívül óvatosan, mivel eltávolítja a hitelesítést minden egyező kérésnél. Továbbá nem kombinálható a kritériummal subjectmivel az Autheliának először hitelesítenie kell a látogatót, hogy megtudja a felhasználónevét és a csoportjait.

Szabályok létrehozása domain és aldomain szerint

A kritérium domain Lehetővé teszi egy pontos domain vagy domainek listájának megadását. Támogatja a helyettesítő karaktereket is, hogy ugyanazt a szabályzatot több aldomainre is alkalmazhassa.

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

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

A vadkártya *.interno.example.com Ez az adott cím alatti aldomaineket is érinti. Idézőjelek közé kell tenni, hogy a YAML ne értelmezze félre a csillagot.

A szabályokban használt tartományoknak a … részben meghatározott tartományok egyikének kell lefedniük. session.cookiesHa nem azok, akkor Authelia automatikusan elutasítja a kéréstmég akkor is, ha a szabály helyesnek tűnik.

Hogyan korlátozható a hozzáférés felhasználók és csoportok szerint

A kritérium subject Ez lehetővé teszi, hogy egy szabályzatot csak adott felhasználókra vagy csoportokra alkalmazzon. Az értékeknek a következővel kell kezdődniük: 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'

A második példában a felhasználó megadhatja ana vagy a csoport bármely tagja editoresA lista fő szintjén lévő elemek alternatívákként funkcionálnak.

Azt is megkövetelheted, hogy egy személy egyszerre több csoporthoz is tartozzon:

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

Ez a feltétel megfelel a felhasználónak ana vagy bármely hozzá tartozó személlyel a csoportok admins e infraestructura egy időben.

Hogyan védhetők meg bizonyos útvonalak az Autheliával

A kritérium resources Reguláris kifejezéseket használ különböző szabályzatok alkalmazására ugyanazon a domainen belül. Ez lehetővé teszi, hogy egy adminisztratív területhez 2FA-t írjunk elő anélkül, hogy azt az alkalmazás többi részére is kötelezővé tennénk.

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

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

A kifejezés védi /admin, annak alútvonalai és paramétereket tartalmazó változatai. Mivel az adminisztratív szabály konkrétabb, az általános szabály elé kell helyezni.

A kifejezéseket le kell írni mindig idézőjelbenEgy perjel, speciális karakter vagy helytelen escape megakadályozhatja az Authelia indítását, vagy azt okozhatja, hogy a szabály a tervezettnél több útvonalat fed le.

Hogyan alkalmazzunk szabályokat a forráshálózat alapján?

A hálózatok deklarálhatók egyedi címek, CIDR-tartományok vagy újrafelhasználható csoportok használatával. Ez akkor hasznos, ha egyfaktoros hitelesítést kell igényelni a helyi hálózatról vagy VPN-ről, illetve kétfaktoros hitelesítést, ha a kapcsolat az internetről indul.

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'

Az Autheliának helyesen kell fogadnia a látogató eredeti IP-címét. Ezért a proxynak el kell küldenie a megfelelő fejléceket, és csak ezeket a fejléceket kell megbízhatóként deklarálni. a proxyk, amelyeket valójában irányítaszBármely forrásból származó fejlécekre való támaszkodás lehetővé tenné az IP-cím hamisítását és a hálózatalapú szabályok megkerülését.

Bár technikailag jelentkezhet bypass</code dentro de la LAN, mantener al menos one_factor suele ser una opción más prudente para paneles sensibles.

Mikor használjunk HTTP metódus szabályokat?

A kritérium methods Lehetővé teszi a GET, POST, PUT, PATCH, DELETE, OPTIONS kérések és más elismert metódusok megkülönböztetését. Gyakori használati eset a hitelesítés nélküli, ellenőrzés előtti CORS kérések engedélyezése.

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

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

Ezt a kritériumot nem szabad a hitelesítési szint emelésére használni az űrlap beküldése során. Az Authelia nem tudja megőrizni a kérés törzsét a felhasználó átirányításakor, így egy POST kérés... elveszíti az elküldött adatokat.

Amikor egy alkalmazásnak különböző engedélyekre van szüksége az információk olvasásához és módosításához, általában a legjobb, ha ezeket az engedélyeket magán az alkalmazáson belül vagy a szerepkörein keresztül kezeljük.

Hogyan ellenőrizhető, hogy melyik szabályt fogja alkalmazni az Authelia?

A szolgáltatás újraindítása előtt ellenőrizheti a fájl szintaxisát a tárolóból:

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

A parancs access-control check-policy Lehetővé teszi egy kérés szimulálását és annak ellenőrzését, hogy melyik szabály fog egyezni:

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

A kimenet azonosítja az első teljes egyezést, és megmutatja, hogy mely kritériumok voltak sikeresek vagy sikertelenek. A folytatás előtt ajánlott megismételni a tesztet különböző felhasználókkal, csoportokkal, útvonalakkal, hálózatokkal és metódusokkal. alkalmazza a szabályokat a termelésben.

Gyakori hibák a hozzáférési szabályok konfigurálásakor

Egy általános szabály jelenik meg a kivétel előtt.

Authelia az első teljes párosításnál megáll. A legspecifikusabb szabályokat helyezi el először, az általánosakat pedig a végére hagyja.

A megkerülést egy felhasználóval vagy csoporttal kombinálják

Egy szabály bypass nem használható subjectA látogató személyazonosságának megállapításához Autheliának legalább a következőket kell kérnie: one_factor.

A domain nem tartozik a munkamenet-süti hatálya alá.

Ellenőrizze, hogy az alkalmazás tartománya megegyezik-e a konfiguráltak egyikével. session.cookies azaz egy érvényes aldomain.

A reguláris kifejezés túl sok útvonalra illeszkedik

Rögzítse a mintákat ^ y $ ahol szükséges, és ellenőrizze az egyes URL-eket a check-policy újraindítás előtt.

Az Authelia helytelen IP-címet kap

Ellenőrizd a proxy által továbbított fejléceket és a megbízható proxy konfigurációját. Ellenkező esetben a következőn alapuló szabályok érvényesek: networks Nem fognak megfelelően működni.

Az alkalmazás továbbra is elérhető a portján keresztül.

A szabályok nem tudják védeni a proxyt megkerülő kapcsolatot. Tiltsa le a közvetlen porttovábbítást, és használjon egy konténerek közötti belső hálózat.

Ugyanaz a szakasz több fájlban is megjelenik

Ne nyilatkozzon access_control több fájlban, amelyek arra várnak, hogy az Authelia automatikusan egyesítse a szabályokat. Központosítsa a szakaszt egyetlen konfigurációs fájlba.

Egy űrlap adatvesztést okoz, ha 2FA-t igényel.

Egy POST kérés során végrehajtott átirányítás elveheti a beküldött tartalmat. Kerülje a metódusonkénti szabályok használatát a belső alkalmazásengedélyek megvalósításához.

Az Authelia hozzáférési szabályainak megfelelő konfigurálása lehetővé teszi a minimális jogosultság elvének alkalmazását anélkül, hogy minden egyes szolgáltatáshoz külön hitelesítési rendszert kellene kezelni. A kulcs a következő létrehozása: deny Alapértelmezett szabályzatként a kivételeket a legspecifikusabbaktól a legáltalánosabbak felé kell rendezni, és minden egyes forgatókönyvet ellenőrizni kell, mielőtt valódi felhasználóknak elérhetővé tennénk.