사용자 역할 방화벽 보안 정책
사용자 역할 방화벽 정책을 통해 관리자는 할당된 역할에 따라 사용자에 대한 네트워크 액세스를 허용하거나 제한할 수 있습니다. 사용자 역할 방화벽을 사용하면 위협을 보다 효과적으로 완화하고, 더 많은 정보를 제공하는 포렌식 리소스를 제공하며, 규정 준수를 위해 기록 보관을 개선하고, 일상적인 액세스 프로비저닝을 강화할 수 있습니다.
사용자 역할 방화벽 이해
머지않아 IP 정보만을 기반으로 네트워크 보안을 적용하고 모니터링하고 보고하는 것만으로는 오늘날의 역동적인 모바일 인력을 감당하기에 충분하지 않을 것입니다. 관리자는 사용자 방화벽 정책을 통합하여 할당된 역할에 따라 직원, 계약자, 파트너 및 기타 사용자의 네트워크 액세스를 허용하거나 제한할 수 있습니다. 사용자 역할 방화벽을 사용하면 위협을 보다 효과적으로 완화하고, 더 많은 정보를 제공하는 포렌식 리소스를 제공하며, 규정 준수를 위해 기록 보관을 개선하고, 일상적인 액세스 프로비저닝을 강화할 수 있습니다.
사용자 역할 방화벽은 다음 두 가지 작업을 트리거합니다.
트래픽과 관련된 사용자 및 역할 정보 검색
영역 쌍의 컨텍스트 내에서 6개의 일치 기준에 따라 취할 조치를 결정합니다.
소스 ID 필드는 사용자 역할 방화벽을 다른 유형의 방화벽과 구별합니다. 소스 ID가 특정 영역 쌍에 대한 정책에 지정되어 있는 경우 이는 사용자 역할 방화벽입니다. 정책 조회가 발생하기 전에 사용자 및 역할 정보를 검색해야 합니다. 정책에서 소스 자격 증명이 지정되지 않은 경우 사용자 및 역할 조회가 필요하지 않습니다.
사용자 및 역할 정보를 검색하기 위해 인증 테이블에서 트래픽에 해당하는 IP 주소를 가진 항목을 검색합니다. 항목이 발견되면 사용자는 인증된 사용자로 분류됩니다. 찾을 수 없는 경우 사용자는 인증되지 않은 사용자로 분류됩니다.
정책 일치를 위해 인증된 사용자와 연결된 사용자 이름 및 역할이 검색됩니다. 인증 분류와 검색된 사용자 및 역할 정보는 모두 source-identity 필드를 일치시키는 데 사용됩니다.
트래픽의 특성은 정책 사양과 일치합니다. 영역 컨텍스트 내에서 사용자 또는 역할과 일치하는 첫 번째 정책과 5가지 표준 일치 기준에 따라 트래픽에 적용할 작업이 결정됩니다.
다음 섹션에서는 사용자 및 역할 검색의 상호 작용과 정책 조회 프로세스, 사용자 및 역할 할당을 획득하는 방법, 사용자 역할 방화벽 정책을 구성하는 기술 및 사용자 역할 방화벽 정책 구성 예제에 대해 설명합니다.
사용자 역할 검색 및 정책 조회 프로세스
정책 조회의 경우 방화벽 정책은 영역 쌍(영역에서 영역으로, 지역으로)별로 그룹화됩니다. 영역 쌍의 컨텍스트 내에서 IP 기반 방화벽 정책은 소스 IP, 소스 포트, 대상 IP, 대상 포트 및 프로토콜의 5가지 기준에 따라 트래픽과 일치합니다.
사용자 역할 방화벽 정책에는 여섯 번째 일치 기준인 소스 ID가 포함됩니다. 소스 ID 필드는 정책이 적용되는 사용자 및 역할을 지정합니다. 소스 ID 필드가 영역 쌍 내의 정책에 지정된 경우, 정책 조회를 진행하기 전에 사용자 및 역할 정보를 검색해야 합니다. (영역 쌍의 모든 정책이 소스 ID 필드에 항목으로 any 설정되거나 항목이 없는 경우, 사용자 및 역할 정보는 필요하지 않으며 정책 조회에 5가지 표준 일치 기준이 사용됩니다.)
사용자 식별 테이블(UIT)은 이미 인증된 활성 사용자에 대한 사용자 및 역할 정보를 제공합니다. 테이블의 각 항목은 IP 주소를 인증된 사용자 및 해당 사용자와 연결된 모든 역할에 매핑합니다.
트래픽에 사용자 및 역할 데이터가 필요한 경우 등록된 각 UIT에서 동일한 IP 주소를 가진 항목을 검색합니다. 사용자가 인증되지 않은 경우 테이블에 해당 IP 주소에 대한 항목이 없습니다. UIT 항목이 없으면 사용자는 인증되지 않은 사용자로 간주됩니다.
정책 조회는 사용자 및 역할 정보가 검색된 후 다시 시작됩니다. 트래픽의 특성은 정책의 일치 기준과 일치합니다. 정책의 source-identity 필드는 하나 이상의 사용자 또는 역할과 다음 키워드를 지정할 수 있습니다.
| authenticated-user | 인증된 사용자입니다. |
| unauthenticated-user | 인증되지 않은 사용자입니다. |
| any | 인증에 관계 없는 모든 사용자. 소스 ID 필드가 구성되지 않았거나 영역 쌍에 대한 모든 정책에서 any로 설정된 경우, 5개의 기준만 일치합니다. |
| unknown-user | 정전과 같은 인증 서버 연결 끊김으로 인해 사용자를 인증할 수 없습니다. |
예를 들어 mgmt 역할에 할당된 user-c가 있다고 가정해 보겠습니다. 트러스트 영역에서 언트러스트 영역으로 트래픽이 IP 주소 198.51.100.3의 user-c로부터 수신되면 정책 조회가 시작됩니다. 표 1 은 트러스트 투 트러스트 언트러스트 영역 쌍에 대한 사용자 역할 방화벽의 세 가지 정책을 나타냅니다.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
신뢰 |
불신(Untrust) |
192.0.2.0 |
203.0.113.0 |
임의 |
http (영문) |
거부 |
– |
P2 |
신뢰 |
불신(Untrust) |
임의 |
임의 |
Mgmt |
임의 |
허용 |
– |
P3 |
신뢰 |
불신(Untrust) |
198.51.100.3 |
임의 |
직원 |
http (영문) |
거부 |
– |
영역 쌍에 대한 모든 정책은 source-identity 옵션에 대해 먼저 확인됩니다. 정책에서 사용자, 역할 또는 키워드를 지정하는 경우 정책 조회를 계속하기 전에 사용자 및 역할 검색이 이루어져야 합니다. 표 1 은 정책 P2가 mgmt를 소스 ID로 지정하여 사용자 역할 방화벽으로 만드는 것을 보여줍니다. 정책 조회를 계속하려면 먼저 사용자 및 역할을 검색해야 합니다.
키워드가 없거나 영역 컨텍스트의 모든 정책에서 소스 ID가 지정되지 않은 경우 사용자 및 역할 검색이 수행되지 않습니다. 이러한 경우 나머지 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 |
MGMT, 직원 |
203.0.113.2 |
사용자-S |
계약자 |
정책 조회가 재개되고 표 1 의 각 정책에 있는 일치 기준을 수신 트래픽과 비교합니다. 다른 모든 기준이 일치한다고 가정할 때 source-identity 필드에서 user-c, mgmt, employee, authenticated-user 또는 any를 지정하는 첫 번째 정책이 이 트래픽과 일치할 수 있습니다. 정책 P1은 user-c에 대해 검색된 역할 중 하나와 일치하지만 소스 IP 주소는 일치하지 않습니다. 따라서 정책 조회가 계속됩니다. 정책 P2의 경우 모든 기준이 트래픽과 일치합니다. 따라서 정책 작업이 수행되고 트래픽이 허용됩니다. 트래픽도 정책 P3와 일치하지만 사용자 방화벽 정책은 터미널이므로 첫 번째 정책 일치가 발견되면 정책 조회가 종료됩니다. 정책 P2가 모든 기준과 일치하므로 정책 조회가 종료되고 정책 P3이 선택되지 않습니다.
정책은 사용자 및 역할 검색 결과에서 사용자에게 할당된 분류를 기반으로 할 수도 있습니다. 표 3으로 표시된 동일한 영역 쌍에 대해 다른 정책 세트를 고려하십시오. IP 198.51.100.5에서 user-q로부터 트래픽을 수신하는 경우, source-identity 필드가 정책 중 하나 이상에 지정되어 있으므로 사용자 및 역할 검색이 필요합니다.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
신뢰 |
불신(Untrust) |
임의 |
임의 |
인증되지 않은 사용자 |
http (영문) |
거부 |
– |
P2 |
신뢰 |
불신(Untrust) |
임의 |
임의 |
Mgmt |
임의 |
허용 |
– |
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 | Junos Pulse 액세스 제어 서비스에서 SRX 시리즈 방화벽으로 푸시되는 동적 UIT입니다. Junos Pulse 액세스 제어 서비스의 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 시리즈 방화벽 구성은 Enforcer의 구성과 유사합니다. 통신을 설정하려면 두 장치 모두 다른 장치를 인식하기 위한 구성 및 암호 설정이 필요합니다. 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 시리즈 방화벽을 New Enforcer로 정의합니다. SRX 시리즈 방화벽에 지정된 것과 동일한 암호를 사용합니다.
사용자 및 암호는 표준 인증 구성에서와 같이 Access Control Service에 정의됩니다. 하나 이상의 역할을 사용자와 연결할 수도 있습니다. 사용자가 인증되면 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 주소와 연결됩니다. 정책 조회가 재개되면 소스 자격 증명으로 알 수 없는 사용자가 있는 정책이 트래픽과 일치합니다. 알 수 없는 사용자에 대한 특정 정책을 구현하여 인증 소스 손실을 처리하는 방법을 만들 수 있습니다.
방화벽 인증 테이블
방화벽 인증을 사용하려면 사용자가 영역과 디바이스 간의 액세스를 허용하기 전에 SRX 방화벽에 인증해야 합니다. 트래픽이 수신되면 사용자에게 사용자 이름과 암호를 입력하라는 메시지가 표시되고 유효한 사용자의 지정된 프로필에 대해 확인됩니다. 디바이스 구성에 따라 방화벽 인증은 텔넷, 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 문은 사용자 역할 방화벽 적용을 위한 방화벽 인증을 구성합니다.
캡티브 포털(captive portal) 리디렉션을 위한 사용자 역할 방화벽 구성
인증되지 않은 사용자를 액세스 제어 서비스로 자동 리디렉션하려면 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 시리즈 방화벽이 집행자로 구성될 때 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%";
}
}
프로필이 정의된 후 정책은 특정 기준이 일치할 때 캡티브 포털을 애플리케이션 서비스로 적용할 수 있습니다. 사용자 역할이 인증되지 않을 때마다 인증 리디렉션 캡티브 포털은 트래픽을 트러스트 영역에서 언트러스트 영역으로 전환합니다. 다음 예에서는 트러스트에서 언트러스트로의 모든 HTTP 트래픽에 auth-redirect 캡티브 포털 프로필을 적용하는 정책 P1을 정의합니다.
[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 시리즈 방화벽에서 사용자 역할 방화벽을 구성합니다. 방화벽은 인증된 활성 사용자 또는 관련 역할에 따라 트러스트 영역에서 언트러스트 영역으로 접근을 제어합니다. 사용자 역할 방화벽 정책은 다음과 같은 제한 사항을 설정합니다.
인증된 사용자만 트러스트 영역에서 언트러스트 영역으로 이동할 수 있습니다.
인증되지 않은 사용자는 인증을 위해 액세스 제어 서비스로 리디렉션됩니다.
영역 컨텍스트 내에서 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 애플리케이션 트래픽으로 식별되는 허용된 트래픽은 거부됩니다.
다른 애플리케이션에 대해 허용된 트래픽은 허용됩니다.
트러스트 영역에서 언트러스트 영역으로 향하는 다른 모든 트래픽은 허용됩니다.
요구 사항
시작하기 전에 Junos OS 릴리스 12.1 이상을 사용하는 SRX 시리즈 방화벽이 구성 및 초기화되었는지 확인하십시오.
이 예에서 트래픽의 IP 주소와 연결된 사용자 및 역할 정보는 액세스 제어 서비스에 의해 제공됩니다. 액세스 제어 서버 구성에 대한 자세한 내용은 Active Directory 인증 서버에서 사용자 역할 정보 가져오기를 참조하십시오.
개요
표 4 에는 이 예의 요구 사항을 충족하는 방화벽이 요약되어 있습니다. 사용자 역할 방화벽은 네 가지 정책으로 구성됩니다.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
사용자 역할-fw1 |
신뢰 |
불신(Untrust) |
임의 |
임의 |
인증되지 않은 사용자 |
http (영문) |
허용 |
UAC 종속 포털 |
사용자 역할-fw2 |
신뢰 |
불신(Untrust) |
192.0.2.0 |
203.0.113.0 |
dev-abc http-juniper-액세스 가능한 ftp 액세스 가능 |
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 캡티브 포털 서비스를 unauthenticated-user 키워드와 일치하는 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%”
이 정책은 인증 후 사용자를 다시 전송하기 위해 액세스 제어 서비스에서 사용할 기본 대상 및 적용자 변수를 지정합니다. 이렇게 하면 시스템 사양 변경이 구성 결과에 영향을 미치지 않습니다.
참고:명령줄에 와 같은
?target=변수가 포함된 경우 URL과 변수를 따옴표로 묶어야 합니다.소스 ID가 인증되지 않은 사용자인 경우 HTTP 트래픽을 영역 신뢰에서 영역 신뢰할 수 없는 영역으로 리디렉션하는 사용자 역할 방화벽 정책을 구성합니다. 캡티브 포털 프로필 이름은 이 정책과 일치하는 트래픽에 대해 수행할 작업으로 지정됩니다.
[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 (영문) |
허용 |
Idp |
P3 |
구역1 |
구역2 |
임의 |
임의 |
임의 |
임의 |
허용 |
Uac |
zone1에서 zone2로의 트래픽에 대한 정책은 모든 정책의 source-identity 필드에 any가 지정되어 있기 때문에 사용자 및 역할 검색을 시작하지 않습니다. 이 예에서 IP 주소 192.0.2.1에 대한 트래픽은 허용되지만 지정된 응용 프로그램 서비스(이 경우 콘텐츠 보안)에 대한 처리 요구 사항을 충족해야 합니다. 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 및 콘텐츠 보안에 대해 구성된 모든 요구 사항을 적용합니다. uac-policy 옵션을 지정하면 SRX 시리즈 방화벽으로 푸시되는 리소스 정책이 대상에 액세스할 수 있는지 여부를 결정합니다.
사용자 역할 방화벽은 사용자 역할 정책과 액세스 제어 서비스에서 푸시된 리소스 정책을 모두 구현할 수 있습니다. 표 6 에는 3개의 영역 쌍에 대한 정책이 나와 있습니다.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
구역1 |
구역2 |
임의 |
임의 |
인증되지 않은 사용자 |
임의 |
허용 |
UAC 종속 포털 |
P2 |
구역1 |
구역2 |
임의 |
192.0.2.1 |
역할2 |
http (영문) |
허용 |
Idp |
P3 |
구역1 |
구역2 |
임의 |
넷2 |
인증된 사용자 |
http (영문) |
허용 |
컨텐트 보안 |
P4 |
구역1 |
구역2 |
임의 |
임의 |
임의 |
임의 |
허용 |
|
P5 |
구역1 |
구역3 |
임의 |
임의 |
임의 |
임의 |
허용 |
Uac |
P6 |
구역2 |
구역3 |
임의 |
임의 |
임의 |
임의 |
허용 |
Uac |
zone1에서 zone2로의 트래픽에는 네 가지 사용자 역할 정책 중 하나가 적용됩니다. 이러한 정책 중 첫 번째는 UAC 종속 포털을 사용하여 인증되지 않은 사용자를 인증을 위해 액세스 제어 서비스로 리디렉션합니다.
zone1에서 zone3으로, zone2에서 zone3으로 트래픽 액세스는 액세스 제어 서비스에서 푸시된 리소스 정책에 의해 제어됩니다.