서브도메인 고급 인증
서브도메인 고급 인증은 로그인 필요가 활성화된 HTTP / HTTPS 서비스 Host에 조건부 허용 규칙을 추가합니다. 요청이 처음 규칙과 일치하면 현재 요청을 먼저 규칙에 따라 한 번 허용하고, Cookie를 지원하는 클라이언트에는 단기 기능 확인 값을 반환합니다. 클라이언트가 후속 요청에서 그 값을 다시 보내야 현재 Host에만 유효한 지속형 임시 자격 증명이 만들어집니다. 규칙과 일치하지 않으면 일반 로그인, 세션 및 서비스 범위에 따라 처리됩니다.
임시 자격 증명은 시스템 로그인이 아닙니다. 로그인 세션이나 IP 접근 권한을 생성하지 않고 포털에도 표시되지 않으며, 다른 Host에 접근할 수도 없습니다. 고급 인증은 독립된 허용 경로이며 기존 로그인 규칙에 검증 단계를 하나 더 추가하는 기능이 아닙니다.
적용 조건
- 매핑 대상이 인증 서비스가 아닌 일반 서비스 Host입니다.
- 대상(타깃)이 HTTP 또는 HTTPS를 사용합니다.
- 매핑에서
로그인 필요를 활성화했습니다. - 출발지 IP 또는 지역 규칙을 사용할 경우 게이트웨이가 실제 클라이언트 IP를 식별할 수 있습니다.
서브도메인 매핑 목록에서 서비스 Host 오른쪽의 메뉴를 열고 고급 인증을 선택합니다. 인증 Host, 공개 매핑 및 TCP / UDP 매핑에는 이 메뉴가 표시되지 않습니다.
임시 자격 증명의 범위
Cookie를 지원하는 클라이언트가 기능 확인을 완료하고 지속형 임시 자격 증명을 얻은 뒤에는 유효 기간 동안 현재 Host의 다른 경로나 요청 메서드에 접근해도 매번 기존 조건을 다시 충족할 필요가 없습니다. 따라서 경로, 헤더 또는 쿼리 조건을 요청마다 계속 적용되는 접근 제어로 사용할 수 없습니다.
Cookie를 반환하지 않는 앱, 스크립트 및 기타 클라이언트는 지속 상태를 만들지 않습니다. 각 요청이 규칙과 다시 일치해야 하며 해당 요청만 허용됩니다. WebSocket 업그레이드도 101 Switching Protocols 응답에서 Cookie를 안정적으로 내려보낼 수 없으므로 현재 핸드셰이크만 허용합니다. 연결이 끊어져 다시 연결할 때는 규칙을 다시 평가합니다. 요청 로그의 요청별 허용 상태로 이 동작을 확인할 수 있습니다.
예를 들어 규칙이 /health에만 일치한다고 해서 지속형 자격 증명도 /health만 공개하는 것은 아닙니다. 브라우저가 기능 확인을 완료하면 임시 자격 증명이 유효한 동안 현재 Host 전체에 접근할 수 있습니다. 일부 고정 경로만 공개하려면 경로 응답을 사용하거나 Host를 분리하거나 업스트림 서비스에서 권한 검사를 계속 수행합니다.
일반 차단 목록, WAF 및 기존의 엄격한 허용 목록과 같은 보호 목적의 거부 규칙은 여전히 우선 적용됩니다. 고급 인증으로 이러한 보안 경계를 우회할 수 없습니다.
유효 시간 설정
| 설정 | 기본값 | 설정 범위 | 동작 |
|---|---|---|---|
접근이 없을 때 만료되는 시간 | 24시간 | 5분~30일 | 유효한 접근이 있을 때마다 유휴 시간을 다시 계산 |
접근 권한의 최대 유효 시간 | 30일 | 5분~365일 | 처음 발급된 시점부터 계산하며 계속 접근해도 연장되지 않음 |
두 시간 설정은 Cookie 기능 확인을 거쳐 만들어진 지속형 임시 자격 증명에만 적용됩니다. 요청별 허용은 다음 요청까지 이어지지 않습니다. 최대 유효 시간은 유휴 만료 시간보다 짧을 수 없습니다. 규칙, 유효 시간 또는 활성화 상태를 변경해 저장하면 시스템이 정책 버전을 교체하므로 기존 임시 자격 증명은 즉시 만료됩니다. 고급 인증을 비활성화해도 규칙 초안은 보존되어 나중에 다시 활성화할 수 있습니다.
규칙 그룹 구성
규칙은 “그룹 사이 OR, 그룹 안 AND” 방식으로 평가됩니다.
규칙 그룹 1: 조건 A AND 조건 B
OR
규칙 그룹 2: 조건 C AND 조건 D완전한 규칙 그룹 중 하나라도 일치하면 자격 증명을 발급합니다. Host 하나에 규칙 그룹을 최대 16개까지 설정할 수 있고, 그룹마다 조건을 최대 16개까지 추가할 수 있습니다. 활성화하려면 조건이 하나 이상 있는 규칙 그룹이 최소 하나 필요합니다.
다음과 같이 적용 범위가 넓은 규칙은 저장할 때 한 번 더 확인합니다.
- 그룹 전체가 ‘같지 않음’, ‘속하지 않음’과 같은 부정 조건으로만 구성된 경우
- HTTP 메서드만으로 허용하는 경우
- 경로 규칙이 루트 경로
/를 포함하는 경우 - 출발지 네트워크에
0.0.0.0/0또는::/0이 포함된 경우
추가 확인은 규칙의 적용 범위가 넓다는 경고일 뿐, 설정의 안전성을 보장하지 않습니다. 저장한 뒤에는 조건에 맞는 외부 네트워크와 맞지 않는 외부 네트워크에서 각각 즉시 검증합니다.
규모 및 발급 속도 제한
Host 하나의 규칙에는 다음과 같은 고정 제한도 적용됩니다.
| 항목 | 상한 |
|---|---|
| 조건 하나의 일치 값 또는 지역 선택 | 256개 |
| 모든 조건의 일치 값 합계 | 4096개 |
| 정규식 합계 | 256개 |
| 정규식 하나 | 512바이트 |
| 지역 및 네트워크 조건을 해석한 뒤의 CIDR 합계 | 100000개 |
| 고급 인증 설정 요청 | 8 MiB |
지속형 임시 자격 증명은 클라이언트가 유효한 기능 확인 값을 다시 보내고 재사용할 수 있는 기존 자격 증명이 없을 때만 만들어집니다. 같은 Host와 같은 클라이언트 IP에는 60초당 최대 10개, Host 하나의 전체 생성량에는 60초당 최대 1000개가 적용됩니다. Host 하나가 보관할 수 있는 활성 자격 증명은 최대 100000개입니다. 생성 속도나 용량 한도에 도달했거나 지속 저장소를 일시적으로 사용할 수 없더라도, 규칙과 이미 일치한 현재 요청은 요청별 허용으로 전환되며 지속화 실패 때문에 거부되지는 않습니다. 다음 요청은 규칙과 다시 일치해야 합니다. 공유 프록시의 출구 IP를 사용하면 여러 클라이언트가 같은 출발지로 집계되므로 앞단 프록시를 사용하는 환경에서는 먼저 실제 클라이언트 IP가 올바르게 식별되는지 확인합니다.
일치 대상
| 대상 | 사용 가능한 일치 방식 | 설정 요점 |
|---|---|---|
| 출발지 IP | 같음, 같지 않음, CIDR에 포함, CIDR에 포함되지 않음 | IPv4와 IPv6 지원, 한 줄에 주소 또는 네트워크 하나 |
| 출발지 지역 | 속함, 속하지 않음 | 도, 시, 도 전체 또는 통신사 범위를 선택하며 저장할 때 고정 CIDR로 해석 |
| URL 경로 | 같음, 같지 않음, 경로 접두사, 접두사가 아님, 포함, 포함하지 않음, RE2 정규식, RE2 정규식이 아님 | 도메인을 제외한 요청 경로와 일치 |
| 요청 헤더 | 존재함, 존재하지 않음, 같음, 같지 않음, 포함, 시작함, 끝남 및 각 부정 조건, RE2 정규식 | 자주 쓰는 이름에서 선택하거나 사용자 지정 헤더를 직접 입력. 값은 기본적으로 대소문자를 구분 |
| 쿼리 매개변수 | 존재함, 존재하지 않음, 같음, 같지 않음, 포함, 시작함, 끝남 및 각 부정 조건, RE2 정규식 | 매개변수와 값이 설정 백업에 포함됨 |
| HTTP 메서드 | 메서드에 포함, 메서드에 포함되지 않음 | 한 줄에 메서드 하나, 예: GET, HEAD |
조건에 일치 값을 여러 개 입력할 수 있는 경우 긍정 조건은 값 중 하나와 일치하면 통과하지만, 부정 조건은 요청 값이 설정된 모든 값과 다른 경우에만 통과합니다. 예를 들어 같지 않음 값이 두 개라면 “둘 중 하나와만 다르면 허용”되는 것이 아니라 두 값 모두와 다른 경우에만 통과합니다.
지역 범위는 저장할 때 CIDR로 펼쳐져 고정됩니다. 이후 CIDR 데이터 원본이 변경되어도 이미 저장된 규칙의 범위는 자동으로 넓어지거나 좁아지지 않습니다. 설정을 다시 열고 저장해야 현재 지역 데이터로 다시 컴파일됩니다.
헤더 이름에는 Host, Cookie, Authorization, X-Forwarded-*, X-Real-IP, X-Reauth-*처럼 자격 증명, 전달 정보 또는 클라이언트 IP와 관련된 헤더를 사용할 수 없습니다. 앞단 프록시를 사용할 때는 외부 클라이언트가 위조할 수 있는 헤더를 프록시에서 삭제하거나 다시 작성합니다.
헤더, 쿼리 및 경로 일치 값은 설정과 백업에 평문으로 저장됩니다. 다만 시스템은 이러한 설정 값을 고급 인증 진단 정보로 로그, 메트릭 또는 오류 세부 정보에 기록하지 않습니다. 요청 로그에는 일치한 규칙 그룹 ID와 임시 자격 증명 상태만 기록되고 설정 값은 표시되지 않습니다. 장기간 사용할 수 있는 중요 키를 쿼리에 직접 넣지 않습니다. 내보낸 백업도 민감한 파일로 취급합니다.
규칙 예시
신뢰할 수 있는 사무실 네트워크의 관리형 기기가 nas.example.com에 바로 접속하도록 하려면 같은 규칙 그룹에 다음 조건을 설정할 수 있습니다.
출발지 IP → CIDR에 포함 → 203.0.113.0/24요청 헤더 → 같음 → X-Device-ID → 기기 식별자
두 조건을 모두 충족해야 현재 요청이 허용되고, 브라우저가 기능 확인을 완료한 뒤 현재 Host의 지속형 임시 자격 증명이 발급됩니다. 헤더는 클라이언트가 직접 구성할 수 있으므로 신뢰할 수 있는 출발지 네트워크와 분리해 단독으로 강력한 인증 수단처럼 사용해서는 안 됩니다. 업스트림 서비스에서도 자체 권한 제어를 유지합니다.
검증 및 문제 해결
- 실제 외부 네트워크에서 규칙과 일치하는 요청을 보냅니다.
요청 로그에서 인증 결과가서브도메인 규칙으로 허용인지 확인합니다.서브도메인 규칙 그룹 ID가 예상한 규칙 그룹인지,임시 자격 증명 상태가요청별 허용,발급됨,갱신됨또는재사용됨인지 확인합니다. 브라우저의 첫 요청은 일반적으로 요청별 허용이며 기능 확인 Cookie를 다시 보낸 뒤에 발급됨으로 표시됩니다.- 조건과 일치하지 않는 출발지에서도 테스트하여 요청이 일반 로그인 절차로 돌아가는지 확인합니다.
- Cookie를 저장하지 않는 클라이언트로 두 번 연속 요청하여 매번 규칙을 다시 평가하고 요청별 허용으로 표시되는지 확인합니다. 그런 다음 브라우저에서 기능 확인 값이 지속형 자격 증명으로 교환되는지 확인합니다.
- 규칙을 수정하고 저장한 뒤 이전 브라우저의 임시 자격 증명이 즉시 만료되는지 확인합니다.
출발지 IP 또는 지역 규칙이 예상대로 동작하지 않으면 로그의 클라이언트 IP와 연결 출발지 IP를 먼저 확인합니다. 규칙을 저장할 수 없다면 조건 값, CIDR 주소 체계, RE2 정규식, 지역 데이터 원본 및 게이트웨이 버전이 서로 맞는지 확인합니다.