사용자 역할 방화벽 보안 정책
사용자 역할 방화벽 정책 덕분에 관리자는 사용자에게 할당된 역할에 따라 사용자에 대한 네트워크 액세스를 허용하거나 제한할 수 있습니다. 사용자 역할 방화벽은 위협을 보다 효과적으로 완화하고, 더 많은 정보를 제공하는 포렌식 리소스를 제공하며, 규정 준수를 위한 기록 보관을 개선하고, 일상적인 액세스 프로비저닝을 향상시킵니다.
사용자 역할 방화벽 이해
IP 정보에만 기반한 네트워크 보안 적용, 모니터링 및 보고만으로는 오늘날의 역동적이고 이동이 잦은 인력에게 충분하지 않을 것입니다. 관리자는 사용자 방화벽 정책을 통합하여 할당된 역할에 따라 직원, 계약자, 파트너 및 기타 사용자의 네트워크 액세스를 허용하거나 제한할 수 있습니다. 사용자 역할 방화벽은 위협을 보다 효과적으로 완화하고, 더 많은 정보를 제공하는 포렌식 리소스를 제공하며, 규정 준수를 위한 기록 보관을 개선하고, 일상적인 액세스 프로비저닝을 향상시킵니다.
사용자 역할 방화벽은 다음 두 가지 작업을 트리거합니다.
트래픽과 관련된 사용자 및 역할 정보 검색
영역 쌍의 컨텍스트 내에서 6개의 일치 기준에 따라 수행할 작업을 결정합니다
source-identity 필드는 사용자 역할 방화벽을 다른 유형의 방화벽과 구분합니다. 소스 자격 증명이 특정 영역 쌍에 대한 정책에 지정된 경우 사용자 역할 방화벽입니다. 정책 조회가 발생하기 전에 사용자 및 역할 정보를 검색해야 합니다. 정책에 소스 자격 증명이 지정되지 않은 경우 사용자 및 역할 조회가 필요하지 않습니다.
사용자 및 역할 정보를 검색하기 위해 인증 테이블에서 트래픽에 해당하는 IP 주소가 있는 항목을 검색합니다. 항목이 발견되면 사용자는 인증된 사용자로 분류됩니다. 찾을 수 없는 경우 사용자는 인증되지 않은 사용자로 분류됩니다.
정책 일치를 위해 인증된 사용자와 연관된 사용자 이름 및 역할이 검색됩니다. 인증 분류와 검색된 사용자 및 역할 정보 모두 source-identity 필드를 일치시키는 데 사용됩니다.
트래픽의 특성은 정책 사양과 일치합니다. 영역 컨텍스트 내에서 사용자 또는 역할과 일치하는 첫 번째 정책과 5개의 표준 일치 기준이 트래픽에 적용할 작업을 결정합니다.
다음 섹션에서는 사용자 및 역할 검색과 정책 조회 프로세스의 상호 작용, 사용자 및 역할 할당을 획득하는 방법, 사용자 역할 방화벽 정책을 구성하는 기술 및 사용자 역할 방화벽 정책 구성 예제에 대해 설명합니다.
사용자 역할 검색 및 정책 조회 프로세스
정책 조회의 경우 방화벽 정책은 영역 쌍(from zone 및 to zone)별로 그룹화됩니다. 영역 쌍의 컨텍스트 내에서 IP 기반 방화벽 정책은 소스 IP, 소스 포트, 대상 IP, 대상 포트 및 프로토콜의 다섯 가지 기준에 따라 트래픽과 일치됩니다.
사용자 역할 방화벽 정책에는 여섯 번째 일치 기준인 소스 ID가 포함됩니다. source-identity 필드는 정책이 적용되는 사용자 및 역할을 지정합니다. 소스 ID 필드가 영역 쌍 내의 정책에 지정되면 정책 조회를 진행하기 전에 사용자 및 역할 정보를 검색해야 합니다. (영역 쌍의 모든 정책이 로 설정 any 되거나 소스 ID 필드에 항목이 없는 경우 사용자 및 역할 정보가 필요하지 않으며 정책 조회에 5가지 표준 일치 기준이 사용됩니다.)
UIT(사용자 식별 테이블)는 이미 인증된 활성 사용자에 대한 사용자 및 역할 정보를 제공합니다. 테이블의 각 항목은 IP 주소를 인증된 사용자 및 해당 사용자와 연관된 모든 역할에 매핑합니다.
트래픽에 사용자 및 역할 데이터가 필요한 경우 등록된 각 UIT에서 동일한 IP 주소를 가진 항목을 검색합니다. 사용자가 인증되지 않은 경우 테이블에 해당 IP 주소에 대한 항목이 없습니다. UIT 항목이 없는 경우 사용자는 인증되지 않은 사용자로 간주됩니다.
정책 조회는 사용자 및 역할 정보가 검색된 후 다시 시작됩니다. 트래픽의 특성은 정책의 일치 기준과 일치합니다. 정책의 source-identity 필드는 하나 이상의 사용자 또는 역할과 다음 키워드를 지정할 수 있습니다.
| authenticated-user | 인증된 사용자입니다. |
| unauthenticated-user | 인증되지 않은 사용자. |
| any | 인증에 관계없이 모든 사용자. 소스 ID 필드가 구성되지 않았거나 영역 쌍에 대한 모든 정책에서 any로 설정된 경우 5개의 기준만 일치합니다. |
| unknown-user | 정전과 같은 인증 서버 연결 끊김으로 인해 사용자를 인증할 수 없습니다. |
예를 들어, 관리 역할에 할당된 user-c를 고려하십시오. IP 주소 198.51.100.3의 user-c로부터 트러스트 영역에서 언트러스트 영역으로의 트래픽이 수신되면 정책 조회가 시작됩니다. 표 1 은 신뢰할 수 없는 영역 쌍에 대한 사용자 역할 방화벽의 세 가지 정책을 나타냅니다.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
트러스트 |
불신(untrust) |
192.0.2.0 |
203.0.113.0 |
어떤 |
HTTP (영어) |
거절하다 |
– |
P2 |
트러스트 |
불신(untrust) |
어떤 |
어떤 |
관리 |
어떤 |
허락하다 |
– |
P3 |
트러스트 |
불신(untrust) |
198.51.100.3 |
어떤 |
종업원 |
HTTP (영어) |
거절하다 |
– |
영역 쌍에 대한 모든 정책은 먼저 source-identity 옵션을 확인합니다. 정책에서 사용자, 역할 또는 키워드를 지정하는 경우 정책 조회를 계속하기 전에 사용자 및 역할 검색이 발생해야 합니다. 표 1 은 정책 P2가 mgmt를 소스 ID로 지정하여 이를 사용자 역할 방화벽으로 만든다는 것을 보여줍니다. 정책 조회를 계속하려면 먼저 사용자 및 역할을 검색해야 합니다.
키워드가 any 또는 영역 컨텍스트의 모든 정책에 소스 자격 증명이 지정되지 않은 경우 사용자 및 역할 검색이 수행되지 않습니다. 이 경우 나머지 5개 값만 정책 기준과 일치합니다.
표 2에 표시된 UIT는 IP 주소를 확인합니다. 주소가 발견되므로 사용자 이름 user-c, user-c에 대해 나열된 모든 역할(이 경우 mgmt 및 employee) 및 키워드 authenticated-user는 트래픽을 정책 필드와 source-identity 일치시키는 데 사용되는 데이터가 됩니다.
소스 IP 주소 |
사용자 이름 |
역할 |
|---|---|---|
192.0.2.4 |
사용자-A |
종업원 |
198.51.100.3 |
사용자-C |
관리, 직원 |
203.0.113.2 |
사용자-S |
계약자 |
정책 조회가 재개되고 표 1 의 각 정책 일치 기준을 수신 트래픽과 비교합니다. 다른 모든 기준이 일치한다고 가정할 때, user-c, mgmt, employee, authenticated-user 또는 source-identity 필드의 any를 지정하는 첫 번째 정책이 이 트래픽과 일치할 수 있습니다. 정책 P1은 user-c에 대해 검색된 역할 중 하나와 일치하지만 소스 IP 주소는 일치하지 않습니다. 따라서 정책 조회가 계속됩니다. 정책 P2의 경우 모든 기준이 트래픽과 일치합니다. 따라서 정책 작업이 따르고 트래픽이 허용됩니다. 트래픽은 정책 P3과도 일치하지만 사용자 방화벽 정책은 터미널입니다. 첫 번째 정책 일치가 발견되면 정책 조회가 종료됩니다. 정책 P2가 모든 기준과 일치하므로 정책 조회가 종료되고 정책 P3은 확인되지 않습니다.
정책은 사용자 및 역할 검색 결과에서 사용자에게 할당된 분류를 기반으로 할 수도 있습니다. 표 3에 표시된 동일한 영역 쌍에 대해 다른 정책 세트를 고려하십시오. IP 198.51.100.5의 user-q로부터 트래픽이 수신되면, source-identity 필드가 정책 중 하나 이상에 지정되므로 사용자 및 역할 검색이 필요합니다.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
트러스트 |
불신(untrust) |
어떤 |
어떤 |
인증되지 않은 사용자 |
HTTP (영어) |
거절하다 |
– |
P2 |
트러스트 |
불신(untrust) |
어떤 |
어떤 |
관리 |
어떤 |
허락하다 |
– |
P3 |
트러스트 |
불신(untrust) |
198.51.100.3 |
어떤 |
종업원 |
HTTP (영어) |
거절하다 |
– |
표 2의 UIT 항목을 확인하면 IP 주소 198.51.100.5에 대한 항목을 찾을 수 없습니다. 따라서 사용자는 인증되지 않은 사용자로 간주됩니다. 정책 조회가 재개되면 트래픽이 정책 P1과 일치하고 트래픽이 거부됩니다.
사용자 식별 테이블 이해
SRX 시리즈 방화벽에서 UIT(사용자 식별 테이블)에는 인증된 각 사용자의 IP 주소, 사용자 이름 및 역할 정보가 포함됩니다. 항목은 IP 주소를 기준으로 정렬됩니다. 보안 정책에 사용자 이름 및 역할 정보가 필요한 경우 모든 UIT가 확인됩니다. UIT 중 하나의 항목에서 IP 주소를 찾으면 해당 주소의 사용자가 이미 성공적으로 인증되었음을 의미합니다.
각 인증 소스는 자체 UIT를 독립적으로 유지 관리하고 데이터 액세스를 위한 쿼리 함수를 제공합니다. 로컬 인증 테이블, UAC(Unified Access Control) 인증 테이블 및 방화벽 인증 테이블의 세 가지 유형의 UIT가 지원됩니다.
| Local authentication table | CLI 명령을 사용하여 수동 또는 프로그래밍 방식으로 SRX 시리즈 방화벽에서 생성된 정적 UIT입니다. 로컬 인증 테이블에 포함된 모든 사용자는 인증된 사용자로 간주됩니다. 일치하는 IP 주소가 발견되면 테이블 항목에서 사용자 및 역할 정보가 검색되고 트래픽과 연결됩니다. 사용자 및 역할 정보는 디바이스에서 수동으로 생성하거나 타사 인증 서버에서 이식할 수 있지만 로컬 인증 테이블의 데이터는 실시간으로 업데이트되지 않습니다. |
| UAC authentication table | 동적 UIT는 Junos Pulse 액세스 제어 서비스에서 SRX 시리즈 방화벽으로 푸시되었습니다. Junos Pulse Access Control Service의 UAC 인증 테이블에는 인증된 각 사용자에 대한 항목이 포함되어 있습니다. 이 테이블의 데이터는 인증 테이블이 업데이트될 때마다 업데이트되고 SRX 시리즈 방화벽으로 푸시됩니다. 디바이스 구성에 따라 Junos Pulse Access Control Service 자체 또는 타사 인증 서버에서 인증이 발생할 수 있습니다. 액세스 제어 서비스가 타사 서버의 데이터를 릴레이하는 경우, 액세스 제어 서비스는 인증 테이블의 파일 형식과 일치하도록 데이터를 재구성하고 SRX 시리즈 방화벽으로 푸시합니다. |
| Firewall authentication table | 이 보안 정책에서 방화벽 인증 유형으로 지정될 때
|
로컬 인증 테이블
로컬 인증 테이블은 항목을 삽입하거나 삭제하는 CLI 명령으로 관리됩니다. 로컬 인증 테이블은 동적 UIT를 사용할 수 없는 경우 백업 솔루션으로 사용하거나 프린터 또는 파일 서버와 같이 네트워크에 인증할 수 없는 디바이스에 사용자 및 역할 정보를 할당하는 데 사용할 수 있습니다. 로컬 인증 테이블은 방화벽 인증 또는 액세스 제어 서비스가 구성되지 않은 상태에서 사용자 역할 방화벽이 작동하는 방식을 테스트하거나 시연하는 데 사용할 수 있습니다.
타사 인증 소스의 IP 주소, 사용자 이름 및 역할은 CLI 명령을 사용하여 프로그래밍 방식으로 로컬 인증 테이블에 다운로드하고 추가할 수 있습니다. 인증 소스가 사용자와 그룹을 정의하는 경우, 그룹은 역할로 구성되고 평소와 같이 사용자와 연관될 수 있습니다.
UAC 인증 테이블을 준수하기 위해 사용자 이름은 65자로 제한되고 역할 이름은 64자로 제한됩니다. 로컬 인증 테이블에는 설치 시 Junos OS 릴리스에 따라 SRX1500 디바이스 이상에서 최대 10,240개, SRX650 이하 디바이스에서 5120개의 인증 항목이 있습니다. 로컬 인증 테이블에는 vSRX 가상 방화벽에 대한 5120개의 인증 항목이 있습니다. 각 인증 항목은 최대 200개의 역할과 연결할 수 있습니다. 최대 용량은 각 사용자에게 할당된 평균 10개의 역할을 기준으로 합니다. UAC 인증 테이블에 지정된 것과 동일한 용량입니다.
다음 명령을 사용하여 로컬 인증 테이블에 항목을 추가합니다. 각 항목은 IP 주소로 입력됩니다.
user@host> request security user-identification local-authentication-table add user user-name ip-address ip-address role [role-name role-name ]
단일 CLI 명령의 role 옵션은 최대 40개의 역할을 허용합니다. 단일 사용자와 40개 이상의 역할을 연결하려면 여러 명령을 입력해야 합니다. 인증, 사용자 및 역할 항목을 추가하거나 수정할 때 다음 특성을 염두에 둡니다.
역할 이름은 사용자 이름과 같을 수 없습니다.
add기존 IP 주소 및 사용자 이름과 함께 옵션을 사용하면 역할 항목이 집계됩니다. 테이블은 사용자당 최대 200개의 역할을 지원할 수 있습니다.add기존 IP 주소 및 새 사용자 이름과 함께 옵션을 사용하면 해당 IP 주소의 기존 사용자 이름을 덮어씁니다.역할 집계는 기존 세션에 영향을 주지 않습니다.
기존 항목의 역할 목록을 변경하려면 기존 항목을 삭제하고 새 역할 목록이 있는 항목을 추가해야 합니다.
기존 항목의 IP 주소를 변경하려면 기존 항목을 삭제하고 새 IP 주소로 항목을 추가해야 합니다.
항목은 IP 주소 또는 사용자 이름으로 삭제할 수 있습니다.
user@host> request security user-identification local-authentication-table delete (ip-address | user-name)
로컬 인증 테이블은 다음 명령으로 지울 수 있습니다.
user@host> clear security user-identification local-authentication-table
로컬 인증 테이블의 내용을 표시하려면 다음 show... 명령을 사용하십시오.
user@host> show security user-identification local-authentication-table all (brief | extensive)
옵션(기본값)은 brief IP 주소를 기준으로 정렬된 표 형식으로 정보를 표시합니다. 사용자 이름 및 역할 목록은 형식에 맞게 잘립니다.
user@host> show security user-identification local-authentication-table all
Total entries: 2 Source IP Username Roles 198.51.100.1 user1 role1 203.0.113.2 user2 role2, role3
이 extensive 옵션은 각 필드의 전체 내용을 표시합니다. 다른 옵션은 단일 사용자 이름, IP 주소 또는 역할로 표시를 제한합니다.
user@host> show security user-identification local-authentication-table all extensive
Total entries: 3 Ip-address: 198.51.100.2 Username: user1 Roles: role1 Ip-address: 203.0.113.2 Username: user1 Roles: role2 Ip-address: 192.0.2.3 Username: user3 Roles: role1, role2
UAC 인증 테이블
SRX 시리즈 방화벽은 Junos Pulse 액세스 제어 서비스의 집행자 역할을 할 수 있습니다. 이 구현에서 SRX 시리즈 방화벽은 레이어 3 적용 지점 역할을 하며 액세스 제어 서비스에서 푸시다운된 IP 기반 리소스 정책을 통해 리소스에 대한 액세스를 제어합니다.
사용자 역할 방화벽으로 구현될 경우 SRX 시리즈 방화벽은 사용자 역할 검색과 유사한 방식으로 UAC 네트워크에 액세스할 수 있습니다. 이 경우 인증된 모든 사용자에 대한 사용자 및 역할 정보가 액세스 제어 서비스에서 푸시됩니다.
SRX 시리즈 방화벽 구성은 실행자의 구성과 유사합니다. 통신을 설정하려면 두 디바이스 모두 서로를 인식하기 위한 구성 및 암호 설정이 필요합니다. SRX 시리즈 방화벽에서 액세스 제어 서비스를 인프라 컨트롤러로 연결합니다.
[edit] user@host# set services unified-access-control infranet-controller ic-name address ip-address user@host# set services unified-access-control infranet-controller ic-name interface interface-name user@host# set services unified-access-control infranet-controller ic-name password password
액세스 제어 서비스에서 SRX 시리즈 방화벽을 새 실행자로 정의합니다. SRX 시리즈 방화벽에 명시된 것과 동일한 암호를 사용하십시오.
사용자와 암호는 표준 인증 구성에서와 같이 액세스 제어 서비스에서 정의됩니다. 하나 이상의 역할을 사용자와 연결할 수도 있습니다. 사용자가 인증되면 IP 주소, 사용자 이름 및 관련 역할이 포함된 항목이 액세스 제어 서비스의 UAC 인증 테이블에 추가됩니다.
두 디바이스 간의 연결이 초기화되면 UAC 인증 테이블이 액세스 제어 서비스에서 SRX 시리즈 방화벽으로 푸시됩니다. 액세스 제어 서비스에서 항목이 추가, 제거 또는 업데이트될 때마다 업데이트된 UAC 인증 테이블이 SRX 시리즈 방화벽으로 푸시됩니다.
리소스 액세스 정책은 사용자 역할 방화벽 구현을 위한 Access Control Service에 필요하지 않습니다. 액세스 동작은 SRX 시리즈 방화벽의 정책 구성에서 제공됩니다. 액세스 제어 서비스에 리소스 액세스 정책이 정의된 경우 SRX 시리즈 방화벽으로 푸시되지만 특정 방화벽 정책이 정책의 작업 필드에 UAC 정책을 구현하지 않는 한 사용되지 않습니다.
다음 show services 명령은 SRX 시리즈 방화벽에 UAC 인증 테이블의 내용을 표시하여 테이블이 액세스 제어 서비스에서 성공적으로 푸시되었음을 확인합니다.
user@host> show services unified-access-control authentication-table extended
Id Source IP Username Age Role name 3 192.0.2.1 april 60 Users 6 192.0.2.2 june 60 Employeees Total: 2
SRX 시리즈 방화벽은 연결을 모니터링하고 액세스 제어 서비스와의 통신이 끊어졌는지 감지합니다. UAC 구성에 따라 SRX 시리즈 방화벽은 다른 요청을 하기 전에 구성된 간격 동안 응답을 기다립니다. 응답이 수신되면 액세스 제어 서비스가 작동하는 것으로 간주됩니다. 지정된 제한 시간 후에도 응답이 수신되지 않으면 통신이 끊어진 것으로 간주되고 시간 제한 작업이 적용됩니다. 다음 UAC 명령 구문은 간격, 시간 제한 및 시간 제한 작업을 구성합니다.
user@host# set services unified-access-control interval seconds user@host# set services unified-access-control timeout seconds user@host# set services unified-access-control timeout-action (close | no-change | open)
연결이 끊긴 동안 연결이 끊긴 디바이스에 대해 사용자 및 역할 조회를 시도하면 시간 제한 작업에 관계없이 오류 코드를 반환합니다. 모든 인증 소스에 대한 액세스가 손실되면 키워드 unknown-user가 IP 주소와 연결됩니다. 정책 조회가 재개되면 소스 자격 증명으로 unknown-user가 있는 정책이 트래픽과 일치합니다. 알 수 없는 사용자에 대한 특정 정책을 구현하여 인증 원본의 손실을 처리하는 방법을 만들 수 있습니다.
방화벽 인증 테이블
방화벽 인증은 사용자가 영역과 디바이스 간의 액세스를 허용하기 전에 SRX 시리즈 방화벽에 대한 인증을 요구합니다. 트래픽이 수신되면 사용자에게 사용자 이름과 비밀번호를 입력하라는 메시지가 표시되고 지정된 유효한 사용자 프로필에 대해 확인됩니다. 디바이스 구성에 따라 방화벽 인증은 Telnet, HTTP, HTTPS(SRX5800, SRX5600 및 SRX5400 디바이스용) 및 FTP 트래픽이 로컬 또는 RADIUS, LDAP 또는 SecureID 인증 서버에 의해 인증되었는지 확인합니다.
디바이스에서 방화벽 인증이 사용 중인 경우 인증 프로세스에서 사용자 역할 방화벽 일치 기준에 필요한 사용자 이름 및 역할 정보를 제공할 수도 있습니다. 이 경우 정보는 방화벽 인증 테이블이라는 UIT에서 수집되고 유지 관리됩니다. 계층에 edit access 있는 하나 이상의 액세스 정책은 방화벽 인증에 사용할 인증 방법을 정의합니다.
방화벽 인증 테이블은 사용자 역할 정보 검색을 위한 인증 소스로 활성화되어야 합니다. 이 priority 옵션은 모든 UIT를 검사할 순서를 지정합니다.
user@host# set security user-identification authentication-source firewall-authentication priority priority
지정된 영역 쌍 firewall-authentication 에 대한 방화벽 정책에서 해당 작업에 대해 permit 지정된 서비스가 일치하는 트래픽의 인증을 시작합니다. user-firewall 인증 유형은 인증된 사용자에 대한 UIT 항목을 생성합니다. 옵션에 access-profile 지정된 이름은 유효한 사용자를 인증하는 데 사용할 프로필을 식별합니다.
[edit security policies from-zone zone to-zone zone policy policy-name] user@host# set match source-identity unauthenticated-user user@host# set then permit firewall-authentication user-firewall access-profile profile-name
UIT 테이블 항목에는 인증된 사용자 및 사용자와 연결된 그룹에 매핑된 트래픽의 IP 주소가 포함됩니다. 사용자가 더 이상 활성화되지 않으면 항목이 테이블에서 제거됩니다. 트래픽 및 인증된 사용자가 변경됨에 따라 항목이 지속적으로 추가 및 제거되기 때문에 방화벽 인증 테이블은 동적인 것으로 간주됩니다.
동일한 영역 쌍 내의 정책이 일치 기준의 일부로 필드를 지정 source-identity 하면 활성화된 모든 UIT에서 트래픽의 IP 주소에 해당하는 항목이 검색됩니다. 발견된 경우, 소스 ID 일치를 위해 연결된 사용자 이름 및 그룹이 검색됩니다. (사용자 인증 그룹 이름은 소스 ID 일치를 위한 역할 이름으로 간주됩니다.)
사용자 및 역할로 정책 프로비저닝
SRX 시리즈 방화벽에 정의된 모든 사용자와 역할, 액세스 제어 서비스에 정의된 모든 사용자와 역할은 SRX 시리즈 방화벽의 사용자 역할 파일에 보관됩니다. 프로비저닝에 사용할 수 있는 모든 사용자 및 역할을 표시하려면 다음 show security... 명령을 사용합니다.
방화벽 인증 테이블의 사용자 이름 및 역할은 다음 표시에 포함되지 않습니다.
프로비저닝에 사용할 수 있는 모든 역할을 표시하려면 명령을 사용합니다
show security user-identification role-provision all. 모든 UIT의 역할이 함께 나열됩니다.프로비저닝에 사용할 수 있는 모든 사용자를 표시하려면 명령을 사용합니다
show security user-identification user-provision all.프로비저닝에 사용할 수 있는 모든 사용자 및 역할을 표시하려면 명령을 사용합니다
show security user-identification source-identity-provision all.
정책 구성이 커밋되면 사용자 역할 파일을 검사하여 정책에 지정된 모든 사용자 및 역할을 프로비저닝에 사용할 수 있는지 확인합니다. 사용자 또는 역할을 찾을 수 없는 경우 나중에 정의할 수 있도록 누락된 사용자 또는 역할을 식별하는 경고가 표시됩니다.
사용자 또는 역할이 아직 정의되지 않은 경우에도 정책이 커밋됩니다.
방화벽 인증을 통해 사용자 이름 및 역할 정보 얻기
사용자 역할 방화벽 정책 방화벽 인증과 통합하여 사용자를 인증하고 사용자 이름 및 역할 정보를 검색할 수 있습니다. 이 정보는 트래픽의 IP 주소에 매핑되고 방화벽 인증 테이블에 저장되며 사용자 역할 방화벽 정책 시행에 사용됩니다.
다음 CLI 문은 사용자 역할 방화벽 적용을 위한 방화벽 인증을 구성합니다.
캡티브 포털 리디렉션을 위한 사용자 역할 방화벽 구성
인증되지 않은 사용자를 액세스 제어 서비스로 자동으로 리디렉션하려면 UAC 캡티브 포털 기능을 사용합니다. 다음 구문은 캡티브 포털의 프로필을 정의합니다.
set services unified-access-control captive-portal profile-name redirect-traffic [unauthenticated | all] set services unified-access-control captive-portal profile-name redirect-url host-url
인증 암호화에 사용되는 Kerberos 프로토콜은 SPN(서비스 사용자 이름)으로만 액세스 제어 서비스를 식별합니다. 프로토콜은 IP 주소를 허용하지 않습니다. 따라서 리디렉션 URL의 형식은 다음과 같아야 합니다
service://hostname/options
이 구현에서 서비스는 HTTP이고 호스트 이름은 액세스 제어 서비스의 FQDN입니다. 호스트 이름 뒤에 지정된 옵션은 추가 정보를 액세스 제어 서비스에 전달하여 사용자를 원래 대상, SRX 시리즈 방화벽 또는 리디렉션을 시작한 정책으로 다시 안내합니다. 다음 키워드 및 변수 쌍을 사용하여 옵션을 구성할 수 있습니다.
| ?target=%dest-url% | 사용자가 액세스하려는 보호된 리소스를 지정합니다. |
| &enforcer=%enforcer-id% | SRX 시리즈 방화벽이 액세스 제어 서비스에 의해 집행자로 구성될 때 할당되는 ID를 지정합니다. |
| &policy=%policy-id% | 트래픽을 리디렉션한 보안 정책에 대한 암호화된 정책 ID를 지정합니다. |
다음 문은 auth-redirect라는 캡티브 포털의 프로필을 정의합니다. 캡티브 포털은 인증을 위해 인증되지 않은 사용자를 액세스 제어 서비스의 URL로 리디렉션합니다. 인증에 성공하면 트래픽은 SRX 시리즈 방화벽으로 다시 전달됩니다.
[edit] user@host# set services unified-access-control captive-portal auth-redirect redirect-traffic unauthenticated user@host# set services unified-access-control captive-portal auth-redirect redirect-url "http://ic6000.example.com/?target=%dest-url%&enforcer=%enforcer-id%&policy=%policy-id%"
정의된 종속 포털 프로필은 UAC 컨피그레이션의 일부로 표시됩니다.
[edit] user@host#show services
unified-access-control {
captive-portal auth-redirect {
redirect-traffic unauthenticated;
redirect-url "http://ic6000.example.com/?target=%dest-url%&enforcer=%enforcer-id%&policy=%policy-id%";
}
}
프로필이 정의된 후 정책은 특정 기준이 일치할 때 캡티브 포털을 애플리케이션 서비스로 적용할 수 있습니다. 사용자 역할이 인증되지 않을 때마다 인증 리디렉션 캡티브 포털은 트래픽을 신뢰 영역에서 신뢰할 수 없는 영역으로 전환합니다. 다음 예제에서는 정책 P1을 정의하여 trust에서 untrust로 전환되는 모든 HTTP 트래픽에 auth-redirect 캡티브 포털 프로필을 적용합니다.
[edit] user@host# set security policies from-zone trust to-zone untrust policy P1 match application http user@host# set security policies from-zone trust to-zone untrust policy P1 match source-identity unauthenticated-user user@host# set security policies from-zone trust to-zone untrust policy P1 then permit application-services uac-policy captive-portal auth-redirect
예: SRX 시리즈 디바이스에서 사용자 역할 방화벽 구성
다음 예제에서는 SRX 시리즈 방화벽에서 사용자 역할 방화벽을 구성합니다. 방화벽은 인증된 활성 사용자 또는 관련 역할에 기반하여 트러스트 영역에서 언트러스트(untrust) 영역으로의 액세스를 제어합니다. 사용자 역할 방화벽 정책에는 다음과 같은 제한 사항이 적용됩니다.
인증된 사용자만 트러스트 영역에서 언트러스트 영역으로 이동할 수 있습니다.
인증되지 않은 사용자는 인증을 위해 액세스 제어 서비스로 리디렉션됩니다.
영역 컨텍스트 내에서 IP 192.0.2.0에서 IP 203.0.113.0으로의 트래픽이 제한됩니다. dev-abc, http-juniper-accessible 또는 ftp-accessible 역할의 사용자로부터의 트래픽만 허용됩니다. 허용된 트래픽은 AppFW 규칙에 의해 추가로 평가됩니다.
junos:FACEBOOK-ACCESS, junos:GOOGLE-TALK 또는 junos:MEEBO 애플리케이션 트래픽으로 식별되는 허용된 트래픽은 거부됩니다.
다른 애플리케이션에 대해 허용된 트래픽은 허용됩니다.
트러스트 영역에서 언트러스트(untrust) 영역으로의 다른 모든 트래픽은 허용됩니다.
요구 사항
시작하기 전에 Junos OS 릴리스 12.1 이상이 포함된 SRX 시리즈 방화벽이 구성 및 초기화되었는지 확인하십시오.
이 예에서는 액세스 제어 서비스에서 트래픽의 IP 주소와 관련된 사용자 및 역할 정보를 제공합니다. 액세스 제어 서버 구성에 대한 자세한 내용은 Active Directory를 ID 소스로 구성을 참조하십시오.
개요
표 4 에는 이 예제의 요구 사항을 충족하는 방화벽이 요약되어 있습니다. 사용자 역할 방화벽은 네 가지 정책으로 구성됩니다.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
사용자 역할-fw1 |
트러스트 |
불신(untrust) |
어떤 |
어떤 |
인증되지 않은 사용자 |
HTTP (영어) |
허락하다 |
UAC 캡티브 포털 |
사용자 역할-FW2 |
트러스트 |
불신(untrust) |
192.0.2.0 |
203.0.113.0 |
dev-abc http-juniper-accessible ftp-accessible |
HTTP (영어) |
허락하다 |
AppFW 규칙 집합 RS1 |
사용자 역할-fw3 |
트러스트 |
불신(untrust) |
192.0.2.0 |
203.0.113.0 |
어떤 |
HTTP (영어) |
거절하다 |
|
사용자 역할-FW4 |
트러스트 |
불신(untrust) |
어떤 |
어떤 |
어떤 |
HTTP (영어) |
허락하다 |
|
source-identity 이 필드는 이 방화벽의 정책 중 하나 이상에 대해 지정되므로 정책 조회를 수행하기 전에 사용자 및 역할 정보를 검색해야 합니다. 트래픽의 소스 IP는 UIT의 항목과 비교됩니다. 소스 IP 주소가 발견되면 키워드authenticated, 사용자 이름 및 이 사용자와 연관된 모든 역할이 나중에 정책 조회에서 사용할 수 있도록 저장됩니다. UIT에서 IP 주소와 일치하는 항목을 찾을 수 없는 경우 키워드 unauthenticated-user 는 정책 조회를 위해 저장됩니다.
사용자 이름, 역할 및 키워드를 검색한 후 정책 조회가 시작됩니다. 수신 트래픽의 특성은 각 정책의 일치 기준과 비교됩니다. 일치하는 항목이 발견되면 해당 정책에 지정된 작업이 수행됩니다.
정책 일치는 종료 이벤트이며, 일치 이후의 정책은 확인되지 않습니다. 정책 시퀀스는 일치하는 트래픽을 위해 수행할 작업에 영향을 미칩니다. 이 예에서 정책은 다음 순서로 적용됩니다.
| user-role-fw1 | UAC 캡티브 포털 서비스를 적용하여 HTTP 트래픽을 인증되지 않은 사용자 키워드와 일치시키고 인증을 위해 액세스 제어 서비스로 리디렉션합니다. 캡티브 포털 사양을 식별하도록 UAC 프로필도 구성해야 합니다. |
| user-role-fw2 | 일치하는 사용자 이름 또는 역할이 있는 주소 192.0.2.0에서 주소 203.0.113.0까지의 모든 HTTP 트래픽에 AppFW 규칙 집합을 적용합니다. 규칙 집합을 정의하도록 응용 프로그램 방화벽도 구성해야 합니다. |
| user-role-fw3 | 이 영역 쌍에 대해 주소 192.0.2.0에서 주소 203.0.113.0까지 나머지 모든 HTTP 트래픽을 거부합니다. |
| user-role-fw4 | 이 영역 쌍에 대해 나머지 HTTP 트래픽을 모두 허용합니다. |
구성
다음 예제에서는 구성 계층에서 다양한 수준의 탐색이 필요합니다. 이를 수행하는 방법에 대한 지침은 CLI 사용자 가이드의 구성 모드에서 CLI 편집기 사용을 참조하십시오.
인증되지 않은 사용자에 대한 리디렉션 구성
단계별 절차
IP 주소가 UIT에 나열되지 않은 경우 unauthenticated-user 키워드가 정책 조회에 사용됩니다. 정책은 이 트래픽에 대한 액세스를 거부하는 대신 인증을 위해 트래픽을 UAC 캡티브 포털로 리디렉션할 수 있습니다.
UAC 인증이 인증된 사용자를 위한 정책에 의해 가려지지 않도록 인증되지 않은 사용자에 대한 리디렉션 정책을 "모든" 사용자에 대한 정책 앞에 배치하는 것이 중요합니다.
SRX 시리즈 방화벽에서 액세스 제어 서비스로의 리디렉션 구성:
구성 모드에서 캡티브 포털 acs-device에 대한 UAC 프로필을 구성합니다.
[edit] user@host# set services unified-access-control captive-portal acs-device redirect-traffic unauthenticated-user
액세스 제어 서비스에 대한 리디렉션 URL 또는 캡티브 포털에 대한 기본 URL을 구성합니다.
[edit] user@host# set services unified-access-control captive-portal acs-device redirect-url “https://%ic-url%/?target=%dest-url%&enforcer=%enforcer-id%”
이 정책은 인증 후 사용자를 다시 안내하기 위해 Access Control Service에서 사용할 기본 대상 및 enforcer 변수를 지정합니다. 이렇게 하면 시스템 사양의 변경이 구성 결과에 영향을 미치지 않습니다.
메모:명령행에 ,와
?target=같은 변수가 포함된 경우 URL과 변수를 따옴표로 묶어야 합니다.source-identity가 unauthenticated-user인 경우 HTTP 트래픽을 zone trust에서 zone untrust로 리디렉션하는 사용자 역할 방화벽 정책을 구성합니다. 캡티브 포털 프로필 이름은 이 정책과 일치하는 트래픽에 대해 수행할 작업으로 지정됩니다.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match source-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match source-identity unauthenticated-user user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 then permit application-services uac-policy captive-portal acs-device
정책 구성을 완료하면 변경 사항을 커밋합니다.
[edit] user@host# commit
결과
구성 모드에서 및 show security policies 명령을 입력하여 show services 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.
[edit]user@host#show services unified-access-control { captive-portal acs-device { redirect-traffic unauthenticated; redirect-url “https://%ic-ip%/?target=%dest-url%&enforcer=%enforcer-id%”
user@host# show security policies
from-zone trust to-zone untrust {
policy user-role-fw1 {
match {
source-address any;
destination-address any;
application http;
source-identity unauthenticated-user
}
then {
permit {
application-services {
uac-policy {
captive-portal acs-device;
}
}
}
}
}
}
응용 프로그램 방화벽을 사용하여 사용자 역할 정책 만들기
단계별 절차
이 정책은 사용자 및 역할과 애플리케이션을 기반으로 IP192.0.2.0에서 IP 203.0.113.0으로 트래픽을 제한합니다. 구성은 응용 프로그램 규칙 집합을 정의하고 일치하는 사용자 역할 트래픽에 적용합니다.
AppFW 규칙 집합 rs1을 구성합니다. 다음 규칙 집합은 junos:FACEBOOK-ACCESS, junos:GOOGLE-TALK 또는 junos:MEEBO 애플리케이션 트래픽을 거부합니다. 나머지 트래픽에 기본 설정인 permit을 적용합니다.
[edit security application-firewall rule-sets rs1] user@host# set rule r1 match dynamic-application [junos:FACEBOOK-ACCESS junos:GOOGLE-TALK junos:MEEBO] user@host# set rule r1 then deny user@host# set default-rule permit
dev-abc, http-mgmt-accessible 또는 ftp-accessible 사용자 역할을 사용하여 IP 192.0.2.0에서 IP 203.0.113.0으로의 트래픽에 rs1 애플리케이션 방화벽 규칙 세트를 적용하도록 정책을 구성합니다.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match source-address 192.0.2.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match destination-address 203.0.113.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match source-identity [dev-abc http-mgmt-accessible ftp-accessible] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 then permit application-services application-firewall rule-set rs1
정책 구성을 완료하면 변경 사항을 커밋합니다.
[edit] user@host# commit
결과
AppFW 규칙 집합이 올바르게 구성되었는지 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.
[edit]user@host#show security application-firewall rule-sets rs1 { rule r1 { match { dynamic-application [junos:FACEBOOK-ACCESS junos:GOOGLE-TALK junos:MEEBO] } then { deny; } } default-rule { permit; } }
사용자 및 역할에 따라 나머지 보안 정책 생성
단계별 절차
다음 절차에서는 나머지 트래픽에 대한 정책을 구성합니다.
소스 및 대상 주소는 동일하지만 user-role-fw2 정책에 지정된 것과 다른 사용자 및 역할 기준을 가진 트래픽을 거부하도록 정책을 구성합니다.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match source-address 192.0.2.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match destination-address 203.0.113.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match source-identity any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 then deny
영역 트러스트에서 영역 언트러스트로의 다른 모든 HTTP 트래픽을 허용하도록 보안 정책을 구성합니다.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match source-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match source-identity any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 then permit
결과
사용자 역할 방화벽 정책의 내용과 시퀀스를 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.
[edit]user@host#show security policies ... from-zone trust to-zone untrust { policy user-role-fw1 { match { source-address any; destination-address any; application http; source-identity unauthenticated-user } then { permit { application-services { uac-policy { captive-portal acs-device; } } } } } } from-zone trust to-zone untrust { policy user-role-fw2 { match { source-address 192.0.2.0; destination-address 203.0.113.0; application http; source-identity [dev-abc http-juniper-accessible ftp-accessible] } then { permit { application-services { application-firewall { rule-set rs1 } } } } } } from-zone trust to-zone untrust { policy user-role-fw3 { match { source-address 192.0.2.0; destination-address 203.0.113.0; application http; source-identity any } then { deny } } } from-zone trust to-zone untrust { policy user-role-fw4 { match { source-address any; destination-address any; application http; source-identity any } then { permit } } }
UAC를 사용하여 리소스 정책 구성
사용자 역할 방화벽 기능을 사용하는 경우 Access Control Service에서 리소스 정책이 필요하지 않습니다. 그러나 리소스 정책이 존재할 경우에는 연결 시 SRX 시리즈 방화벽으로 푸시됩니다. 정책 구성에 UAC 응용 프로그램 서비스를 적용하여 이러한 리소스 정책을 사용하는 정책을 만들 수 있습니다. 표 5 에는 UAC 리소스 정책을 단독으로 사용하는 세 가지 방화벽 정책이 나와 있습니다.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
존1 |
영역2 |
어떤 |
192.0.2.1 |
어떤 |
HTTP (영어) |
허락하다 |
컨텐트 보안 |
P2 |
존1 |
영역2 |
어떤 |
넷2 |
어떤 |
HTTP (영어) |
허락하다 |
침입 탐지 및 방지(ID |
P3 |
존1 |
영역2 |
어떤 |
어떤 |
어떤 |
어떤 |
허락하다 |
UAC (영어) |
zone1에서 zone2로의 트래픽에 대한 정책은 모든 정책의 source-identity 필드에 any가 지정되어 있기 때문에 사용자 및 역할 검색을 시작하지 않습니다. 이 예에서는 IP 주소 192.0.2.1에 대한 트래픽이 허용되지만 지정된 애플리케이션 서비스(이 경우 Content Security)에 대한 처리 요구 사항을 충족해야 합니다. net2에 대한 트래픽은 침입 탐지 및 방지(IDP) 처리 요구 사항에 의해 허용되고 처리됩니다. 나머지 트래픽은 UAC 처리 요구 사항에 따라 허용되고 처리됩니다.
이 방화벽 정책의 구성은 다음과 같습니다.
[edit]user@host#show security policies from-zone zone1 to-zone zone2 { policy P1 { match { source-address any; destination-address 192.0.2.1; source-identity any; application http; } then { permit { application-services { idp; } } } } } from-zone zone1 to-zone zone2 { policy P2 { match { source-address any; destination-address net2; source-identity any; application http; } then { permit { application-services { utm; } } } } } from-zone zone1 to-zone zone2 { policy P3 { match { source-address any; destination-address any; source-identity any; application any; } then { permit { application-services { uac-policy; } } } } }
이 샘플 구성에서 P1 및 P2의 작업 필드는 각각 IDP 및 Content Security에 대해 구성된 모든 요구 사항을 적용합니다. uac-policy 옵션을 지정하면 SRX 시리즈 방화벽에 푸시된 리소스 정책에 따라 대상에 액세스할 수 있는지 여부가 결정됩니다.
사용자 역할 방화벽은 사용자 역할 정책과 액세스 제어 서비스에서 푸시된 리소스 정책을 모두 구현할 수 있습니다. 표 6 에는 세 개의 영역 쌍에 대한 정책이 표시되어 있습니다.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
존1 |
영역2 |
어떤 |
어떤 |
인증되지 않은 사용자 |
어떤 |
허락하다 |
UAC 캡티브 포털 |
P2 |
존1 |
영역2 |
어떤 |
192.0.2.1 |
역할2 |
HTTP (영어) |
허락하다 |
침입 탐지 및 방지(ID |
P3 |
존1 |
영역2 |
어떤 |
넷2 |
인증된 사용자 |
HTTP (영어) |
허락하다 |
컨텐트 보안 |
P4 |
존1 |
영역2 |
어떤 |
어떤 |
어떤 |
어떤 |
허락하다 |
|
P5 |
존1 |
존3 |
어떤 |
어떤 |
어떤 |
어떤 |
허락하다 |
UAC (영어) |
피6 |
영역2 |
존3 |
어떤 |
어떤 |
어떤 |
어떤 |
허락하다 |
UAC (영어) |
영역 1에서 영역 2로의 트래픽에는 네 가지 사용자 역할 정책 중 하나가 적용됩니다. 이러한 정책 중 첫 번째는 UAC 캡티브 포털을 사용하여 인증되지 않은 사용자를 인증을 위해 액세스 제어 서비스로 리디렉션합니다.
영역 1에서 영역 3으로, 영역 2에서 영역 3으로의 트래픽 액세스는 액세스 제어 서비스에서 푸시된 리소스 정책에 의해 제어됩니다.
플랫폼별 사용자 역할 방화벽 보안 정책 동작
기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인할 수 있습니다.
다음 표를 사용하여 플랫폼에 대한 플랫폼별 동작을 검토할 수 있습니다.
플랫폼별 로컬 인증 동작
| 플랫폼 |
다름 |
|---|---|
| SRX 시리즈 |
|
플랫폼별 방화벽 인증 동작
| 플랫폼 |
다름 |
|---|---|
| SRX 시리즈 |
|