Authelia에서 액세스 규칙을 단계별로 설정하는 방법

이미 Authelia를 설치하고 애플리케이션을 보호하고 있다면 다음 단계는 결정을 내리는 것입니다. 누가 어디에서 어떤 수준의 인증을 통해 입장할 수 있는가모든 사용자가 동일한 서비스에 접근할 필요가 있는 것은 아니며, 모든 경로가 동일한 위험을 내포하는 것도 아닙니다.

Authelia의 액세스 규칙을 사용하면 도메인, 요청 경로, 사용자, 사용자 그룹, 소스 IP 주소 또는 HTTP 메서드에 따라 다양한 정책을 적용할 수 있습니다. 이를 통해 관리자 패널에 2단계 인증을 요구하거나, VPN을 통한 간편한 액세스를 허용하거나, 명시적으로 승인하지 않은 모든 요청을 차단할 수 있습니다.

Authelia의 접근 규칙은 무엇을 제어하나요?

규칙은 해당 섹션 내에 정의되어 있습니다. access_control 설정 파일에서 가져옵니다. 리버스 프록시가 Authelia에 쿼리를 보내면 시스템은 요청 데이터를 분석하고 결정합니다. 어떤 정책을 적용해야 할까요? 접근을 허용하거나 거부하기 전에.

규칙은 다음과 같은 기준을 사용할 수 있습니다.

• 도메인: 영향을 받는 애플리케이션 또는 하위 도메인을 식별하십시오.
• 의지: 이 규칙은 경로 하나 또는 경로 집합으로 제한합니다.
• 주제: 이 정책은 특정 사용자 또는 그룹에 적용됩니다.
• 그리드: 요청이 시작된 IP 주소를 확인하십시오.
• 방법: GET, POST, PUT, DELETE 또는 기타 요청 간의 차이점.
• 상의: 이를 통해 URL에 포함된 특정 매개변수를 평가할 수 있습니다.

이러한 정책은 프록시의 인증 메커니즘을 통과하는 요청에만 영향을 미칩니다. 애플리케이션이 유지 관리하는 경우 직접 접근 가능한 포트방문자는 IP 주소와 포트를 통해 접속함으로써 Authelia를 우회할 수 있습니다.

Authelia는 접근 규칙을 어떻게 평가할까요?

오텔리아는 규칙을 살펴봅니다. 위에서 아래로 순차적으로모든 조건을 충족하는 첫 번째 일치 항목을 발견하는 즉시 해당 정책을 적용하고 이후 일치 항목 확인을 중단합니다. 일치하는 항목이 없으면 해당 값을 사용합니다. default_policy.

즉, 가장 구체적인 규칙이 일반적인 규칙보다 먼저 나와야 합니다. 예를 들어, 인증 엔드포인트를 공개하고, 대시보드를 2단계 인증으로 보호하고, 나머지에는 비밀번호를 적용하려면 다음과 같은 순서를 사용할 수 있습니다.

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오텔리아는 방문자의 사용자 이름과 그룹을 확인하기 위해 먼저 방문자를 인증해야 하기 때문입니다.

도메인 및 서브도메인별 규칙 생성 방법

기준 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 이 기능은 정규 표현식을 사용하여 동일한 도메인 내에서 서로 다른 정책을 적용합니다. 이를 통해 관리자 영역에만 2단계 인증을 요구하고 애플리케이션의 나머지 부분에는 적용하지 않을 수 있습니다.

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 요청이 전송될 수 있습니다. 전송된 데이터가 손실됩니다.

애플리케이션이 정보를 읽고 수정하는 데 서로 다른 권한이 필요한 경우, 일반적으로 애플리케이션 자체 내에서 또는 역할(role)을 통해 권한을 관리하는 것이 가장 좋습니다.

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오텔리아는 방문객의 신원을 확인하기 위해 최소한 다음 사항을 요구해야 합니다. one_factor.

해당 도메인은 세션 쿠키의 적용 대상이 아닙니다.

애플리케이션 도메인이 구성된 도메인 중 하나와 일치하는지 확인하십시오. session.cookies 즉, 유효한 서브도메인입니다.

정규 표현식이 너무 많은 경로와 일치합니다.

패턴을 고정하세요 ^ y $ 적절한 경우 각 URL을 확인하세요. check-policy 재시작하기 전에.

Authelia는 잘못된 IP 주소를 수신했습니다.

프록시가 전달하는 헤더와 프록시의 신뢰 프록시 구성을 확인하십시오. 그렇지 않으면 규칙이 적용됩니다. networks 제대로 작동하지 않을 것입니다.

해당 애플리케이션은 포트를 통해 계속 접속할 수 있습니다.

규칙으로는 프록시를 우회하는 연결을 보호할 수 없습니다. 직접 포트 포워딩을 비활성화하고 다른 방법을 사용하십시오. 컨테이너 간 내부 네트워크.

동일한 부분이 여러 파일에 나타납니다.

신고하지 마십시오 access_control Authelia가 규칙을 자동으로 결합할 때까지 여러 파일에 나누어져 있는 경우, 해당 섹션을 단일 구성 파일로 통합하십시오.

2단계 인증을 요구할 경우 양식의 데이터가 손실됩니다.

POST 요청 중 리디렉션이 발생하면 제출된 콘텐츠가 손실될 수 있습니다. 내부 애플리케이션 권한 구현에 메서드별 규칙을 사용하는 것은 피하십시오.

Authelia의 접근 규칙을 올바르게 구성하면 각 서비스마다 별도의 인증 시스템을 관리할 필요 없이 최소 권한 원칙을 적용할 수 있습니다. 핵심은 다음과 같습니다. deny 기본 정책으로 예외 사항은 가장 구체적인 것부터 가장 일반적인 순서로 정렬하고, 실제 사용자에게 노출하기 전에 각 시나리오를 검증하십시오.