Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지에서
 

사용자 액세스 권한

시스템 관리자는 사용자에게 명령 및 구성 계층 수준과 문에 대한 액세스 또는 권한을 부여합니다. 사용자는 해당 명령만 실행할 수 있으며, 액세스 권한이 있는 명령문만 보고 구성할 수 있습니다. 또한 확장된 정규식을 사용해 사용자에게 허용되거나 거부되는 운영 모드 명령, 구성 문 및 계층을 지정할 수 있습니다. 이는 권한이 없는 사용자가 중요한 명령을 실행하거나 네트워크에 손상을 줄 수 있는 문을 구성하는 것을 방지합니다.

액세스 권한 수준 개요

각 최상위 CLI 명령 및 구성 문은 관련 액세스 권한 레벨을 갖습니다. 사용자는 이러한 명령만 실행하고 액세스 권한이 있는 경우에만 문만 구성하고 볼 수 있습니다. 하나 이상의 권한 플래그는 각 로그인 클래스에 대한 액세스 권한을 정의합니다.

각 로그인 클래스의 경우, 운영 모드 명령 및 구성 모드 명령과 문 계층 사용 여부를 명백히 허용하거나 거부할 수 있으며 그렇지 않은 경우 이는 permissions 문에 지정된 권한 수준에 따라 허용되거나 거부될 수 있습니다.

로그인 클래스 권한 플래그

권한 플래그를 사용하여 사용자에게 운영 모드 명령 및 구성 계층 수준과 문에 대한 액세스 권한을 부여할 수 있습니다. [edit system login class] 계층 수준에서 사용자의 로그인 클래스에 대한 권한 플래그를 구성합니다. 특정 권한 플래그 지정 시, 사용자는 명령 및 플래그에 해당하는 구성 계층 수준과 문에 대한 액세스 권한을 갖습니다. 모든 명령 및 구성 문에 대한 액세스를 부여하려면 all 권한 플래그를 사용해야 합니다.

주:

나열된 각 명령은 명령과 모든 하위 명령에 접두어로 명령이 있음을 나타냅니다. 나열된 각 구성 문은 해당 플래그가 액세스를 부여하는 구성 계층의 상단을 나타냅니다.

permissions 문은 표 1에 나열된 하나 이상의 권한 플래그를 지정합니다. 권한 플래그는 누적되지 않습니다. 각 클래스의 경우 정보를 표시하는 view와(과) 구성 모드를 입력하는 configure을(를) 포함하여 필요한 모든 권한 플래그를 나열해야 합니다. 두 가지 형태의 권한이 구성의 개별 부분에 대한 사용자의 액세스를 제어합니다.

  • "일반" 형태 - 권한 유형에 대한 읽기 전용 기능을 제공합니다. interface을(를) 예로 들 수 있습니다.

  • -control 형태 - 해당 권한 유형에 대한 읽기 및 쓰기 기능을 제공합니다. interface-control을(를) 예로 들 수 있습니다.

구성 계층 수준과 문에 대한 액세스를 부여하는 권한 플래그의 경우, 일반 형태 플래그가 해당 구성에 대한 읽기 전용 권한을 부여합니다. 예를 들어, interface 권한 플래그는 [edit interfaces] 계층 수준에 대한 읽기 전용 액세스 권한을 부여합니다. -control 플래그 형태는 해당 구성에 대한 읽기 쓰기 액세스 권한을 부여합니다. 예를 들어, interface-control 플래그는 [edit interfaces] 계층 수준에 대한 읽기 쓰기 액세스 권한을 부여합니다.

표 1에는 [edit system login class class-name]계층 수준에서 permissions문을 포함하여 구성 가능한 로그인 클래스 권한 플래그가 나열되어 있습니다.

권한 플래그는 특정한 세트의 액세스 권한을 부여합니다. 각 권한 플래그는 운영 모드 또는 구성 모드 명령 그리고 플래그가 액세스 권한을 부여하는 구성 계층 수준과 문과 함께 나열됩니다.

표 1: 로그인 클래스 권한 플래그

권한 플래그

설명

access

운영 모드 또는 구성 모드에서 액세스 구성을 볼 수 있습니다.

access-control

[edit access] 계층 수준에서 액세스 정보를 보고 구성할 수 있습니다.

admin

운영 모드 또는 구성 모드에서 사용자 계정 정보를 볼 수 있습니다.

admin-control

사용자 계정 정보를 보고 [edit system] 계층 수준에서 이를 구성할 수 있습니다.

all

모든 운영 모드 명령 및 구성 모드 명령에 액세스할 수 있습니다. 모든 구성 계층 수준에서 구성을 수정할 수 있습니다.

clear

디바이스가 네트워크에서 학습하고 다양한 네트워크 데이터베이스에 저장하는 정보를 제거(삭제)할 수 있습니다(clear 명령 사용).

configure

구성 모드를 입력(configure 명령 사용) 및 구성을 커밋(commit 명령 사용)할 수 있습니다.

control

모든 제어 수준 동작 즉, -control 권한 플래그와 함께 구성된 모든 동작을 수행할 수 있습니다.

field

필드 디버그 명령을 볼 수 있습니다. 디버깅 지원을 위해 예약되었습니다.

firewall

운영 모드 또는 구성 모드에서 방화벽 필터 구성을 볼 수 있습니다.

firewall-control

[edit firewall] 계층 수준에서 방화벽 필터 정보를 보고 구성할 수 있습니다.

floppy

이동식 미디어 측에서 읽고 쓸 수 있습니다.

flow-tap

운영 모드 또는 구성 모드에서 플로우 탭 구성을 볼 수 있습니다.

flow-tap-control

[edit services flow-tap] 계층 수준에서 플로우 탭 정보를 보고 구성할 수 있습니다.

flow-tap-operation

라우터 또는 스위치에 대한 플로우 탭을 요청할 수 있습니다. 예를 들어, DTCP(Dynamic Tasking Control Protocol) 클라이언트는 관리 사용자로 Junos OS자신을 인증할 수 있는 flow-tap-operation권한이 있어야 합니다.

주:

flow-tap-operation 옵션은 all-control 권한 플래그에 포함되어 있지 않습니다.

idp-profiler-operation

프로파일러 데이터를 볼 수 있습니다.

interface

운영 모드 또는 구성 모드에서 인터페이스 구성을 볼 수 있습니다.

interface-control

섀시, CoS(Class of Service), 그룹, 포워딩 옵션 및 인터페이스 구성 정보를 볼 수 있습니다. 다음 계층 수준에서 구성을 수정할 수 있습니다.

  • [edit chassis]

  • [edit class-of-service]

  • [edit groups]

  • [edit forwarding-options]

  • [edit interfaces]

maintenance

디바이스의 로컬 쉘을 시작하고 쉘에서 슈퍼유저가 되고(su root 명령 사용) 디바이스를 중지 및 재부팅(request system 명령 사용)하는 등 시스템 유지 관리 작업을 수행할 수 있습니다.

network

ping, ssh, telnet 및 traceroute 명령을 사용해 네트워크에 액세스할 수 있습니다.

pgcp-session-mirroring

pgcp 세션 미러링 구성을 볼 수 있습니다.

pgcp-session-mirroring-control

pgcp 세션 미러링 구성을 수정할 수 있습니다.

reset

restart 명령을 사용하여 소프트웨어 프로세스를 다시 시작할 수 있습니다.

rollback

rollback 명령을 사용하여 이전에 커밋한 구성으로 되돌아갈 수 있습니다.

routing

구성 모드 및 운영 모드에서 일반적인 라우팅, 라우팅 프로토콜 및 라우팅 정책 구성 정보를 볼 수 있습니다.

routing-control

[edit routing-options] 계층 수준에서 일반 라우팅, [edit protocols] 계층 수준에서 라우팅 프로토콜 및 [edit policy-options] 계층 수준에서 라우팅 정책 정보를 보고 구성할 수 있습니다.

secret

구성에서 비밀번호 및 기타 인증 키를 볼 수 있습니다.

secret-control

구성의 비밀번호 및 기타 인증 키를 보고 수정할 수 있습니다.

security

운영 모드 및 구성 모드에서 보안 구성 정보를 볼 수 있습니다.

security-control

[edit security] 계층 수준에서 보안 정보를 보고 구성할 수 있습니다.

shell

start shell 명령을 사용하여 라우터 또는 스위치에서 로컬 쉘을 시작할 수 있습니다.

snmp

운영 모드 또는 구성 모드에서 SNMP(Simple Network Management Protocol) 구성 정보를 볼 수 있습니다.

snmp-control

[edit snmp] 계층 수준에서 SNMP 구성 정보를 보고 수정할 수 있습니다.

[edit fc-fabrics] 계층 수준에서 Fibre Channel 스토리지 구성 정보를 볼 수 있습니다.

[edit fc-fabrics] 계층 수준에서 Fibre Channel 스토리지 구성 정보를 수정할 수 있습니다.

system

운영 모드 또는 구성 모드에서 시스템 수준의 정보를 볼 수 있습니다.

system-control

[edit system] 계층 수준에서 시스템 수준의 구성 정보를 보고 수정할 수 있습니다.

trace

추적 파일 설정을 보고 추적 파일 속성을 구성할 수 있습니다.

trace-control

추적 파일 설정을 수정하고 추적 파일 속성을 구성할 수 있습니다.

[edit unified-edge] 계층에서 통합 에지 구성을 볼 수 있습니다.

[edit unified-edge] 계층에서 통합 에지 관련 구성을 수정할 수 있습니다.

view

다양한 명령을 사용해 현재 시스템 전체, 라우팅 테이블 및 프로토콜 특정 값 및 통계를 표시할 수 있습니다. 비밀 구성을 볼 수 없습니다.

view-configuration

비밀, 시스템 스크립트 및 이벤트 옵션을 제외한 모든 구성을 볼 수 있습니다.

주:

maintenance 권한이 있는 사용자만 스크립트, 운영 스크립트 또는 심지어 이벤트 스크립트 구성을 볼 수 있습니다.

로그인 클래스에 대한 개별 명령과 문 계층 허용 및 거부

기본적으로, 모든 상위 수준의 CLI 명령 및 구성 계층 수준은 관련 액세스 권한 수준을 갖습니다. 사용자는 해당 명령만 실행할 수 있으며, 액세스 권한이 있는 명령문만 보고 구성할 수 있습니다. 각 로그인 클래스의 경우, 운영 모드 및 구성 모드 명령과 permissions 문에 지정된 권한 수준에 의해 별도로 허용 또는 거부될 수 있는 문 계층 사용 여부를 명시적으로 허용하고 거부할 수 있습니다.

권한 플래그는 운영 모드 및 구성 모드 명령과 구성 계층 수준 및 문에 대한 사용자 액세스 권한을 부여합니다. [edit system login class] 계층 수준에서 사용자의 로그인 클래스에 대한 특정 권한 플래그를 지정함으로써, 해당 명령 그리고 구성 계층 수준 및 문에 대한 사용자 액세스 권한을 부여할 수 있습니다. 모든 명령 및 구성 문에 대한 액세스를 부여하려면 all 권한 플래그를 사용해야 합니다.

로그인 클래스에 대한 allow-commands, deny-commands, allow-configuration 및 deny-configuration 문을 구성하여 명령과 문의 사용 여부를 명시적으로 허용하거나 거부할 수 있습니다. 문에서 확장 정규 표현을 사용하여 클래스에 할당된 사용자를 위해 어떤 명령과 문을 허용하거나 거부할지 여부를 지정할 수 있습니다.

예: 액세스 권한 수준으로 사용자 권한 구성

이 예제에서는 로그인 클래스의 사용자 권한을 구성합니다. 로그인 클래스의 사용자 권한을 구성하여 사용자가 무단 네트워크 동작을 하지 못하도록 합니다. 사용자는 이러한 명령만 실행하고 액세스 권한이 있는 이러한 문만 보고 수정할 수 있습니다. 이러한 제약으로 인해 무단 사용자가 네트워크에 피해를 줄 수 있는 민감한 명령을 실행하거나 메시지를 구성하지 못하도록 방지합니다.

요구 사항

이 예를 구성하기 전에 디바이스 초기화를 제외한 특별한 구성은 필요하지 않습니다.

개요

각 최상위 수준의 CLI 명령과 각 구성 문은 이와 관련된 액세스 권한 수준을 갖습니다. 로그인 클래스를 구성할 때 운영 모드 및 구성 모드 명령과 구성 문 사용 여부를 명시적으로 허용하거나 거부할 수 있습니다. 사용자는 해당 명령만 실행할 수 있으며, 액세스 권한이 있는 명령문만 보고 구성할 수 있습니다.

permissions 문에서 하나 이상의 권한 플래그를 지정함으로써 각 로그인 클래스에 대한 액세스 권한을 정의합니다. 권한 플래그는 명령, 문 및 계층에 대한 사용자 액세스 권한을 부여합니다. 권한 플래그는 누적되지 않습니다. 각 로그인 클래스의 경우 정보를 표시하는 view와(과) 구성 모드를 입력하는 configure을(를) 포함하여 필요한 모든 권한 플래그를 나열해야 합니다. 사용자의 로그인 클래스에 특정 권한 플래그를 지정함으로써 해당 명령, 문 및 계층에 대한 사용자 액세스 권한을 부여할 수 있습니다. 모든 명령 및 구성 문에 대한 액세스를 부여하려면 all 권한 플래그를 사용해야 합니다. 권한 플래그는 권한 유형에 대해 읽기 전용("일반" 형식) 및 읽고 쓰기(-control로 끝나는 형식)를 제공합니다.

주:

사용자가 rollback 권한 플래그가 활성화되어 있는 rollback 명령을 사용할 때 all 로그인 클래스 권한 비트는 확장 정규 표현보다 우선시됩니다.

로그인 클래스에 대한 사용자 액세스 권한 수준을 구성하려면 [edit system login class class-name] 계층 수준에서 permissions 문을 포함시켜야 합니다. 그 다음에 권한 플래그가 표시됩니다. 공백으로 분리된 목록(대괄호로 표시)으로 여러 권한을 구성합니다.

팁:

사용 가능한 권한을 보려면 CLI의 컨텍스트에 민감한 도움말을 사용하고 permissions 문 다음에 물음표(?)를 입력해야 합니다.

구성

이 예제에서는 snmp-admin 로그인 클래스를 구성합니다. 이 로그인 클래스 사용자는 SNMP 매개 변수만 구성하고 볼 수 있습니다.

액세스 권한 수준으로 사용자 권한 구성

단계별 절차

로그인 클래스에 대한 액세스 권한 구성 방법:

  1. configure, snmp 및 snmp-control 권한 플래그를 사용하여 snmp-admin 로그인 클래스를 구성합니다.

    구성된 권한 플래그는 SNMP에 대한 읽기(snmp)와 읽고 쓰기(snmp-control) 기능을 모두 제공하며 이는 이 로그인 클래스에 대해 허용된 유일한 액세스 권한입니다. 다른 모든 액세스 권한이 거부됩니다.

  2. snmp-admin 로그인 클래스에 할당된 사용자 계정을 생성합니다.

결과

구성 모드에서 show system login 명령을 입력하여 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.

디바이스를 구성한 후 구성 모드에서 commit을(를) 입력하십시오.

검증

새 로그인 클래스에 할당된 사용자 이름을 사용하여 로그인하고 구성이 제대로 작동하는지 확인합니다.

SNMP 구성 확인

목적

snmp-admin 로그인 클래스의 사용자가 SNMP를 구성할 수 있는지 확인합니다.

작업

구성 모드에서, [edit snmp] 계층 수준에 SNMP 문을 구성합니다.

의미

snmp-admin 로그인 클래스의 사용자는 SNMP 매개 변수를 구성할 수 있습니다. 사용자는 이러한 매개 변수를 구성할 수 있습니다. 이 클래스에 지정된 권한 플래그가 snmp(읽기 기능) 및 snmp-control(읽고 쓰기 기능) 권한 비트를 모두 포함하기 때문입니다.

비-SNMP 구성 확인

목적

snmp-admin 로그인 클래스의 사용자가 비-SNMP 구성 문을 수정할 수 없는지 확인합니다.

작업

구성 모드에서, interfaces 계층에 문과 같은 비-SNMP 문을 구성하려고 시도합니다.

의미

snmp-admin 로그인 클래스의 사용자는 [edit interfaces] 계층을 구성할 수 없습니다. 이 클래스에 대해 지정된 권한 플래그가 이를 허용하지 않기 때문입니다. 이 경우, CLI은 오류 메시지를 발행합니다.

작동 모드 명령, 구성 명령문 및 계층을 허용하거나 거부하는 정규 표현식

이러한 주제에는 다음 섹션이 포함됩니다.

허용 및 거부 명령문에 대한 이해

각 최상위 수준 CLI 명령과 각 구성 명령문 계층 구조는 이와 관련된 액세스 권한 수준을 갖습니다. 각 로그인 클래스는 운영 모드 및 구성 모드 명령과 구성 계층 및 명령문의 사용을 명시적으로 허용하거나 거부할 수 있습니다. 사용자는 해당 명령만 실행할 수 있으며, 액세스 권한이 있는 명령문만 보고 구성할 수 있습니다.

각 로그인 클래스에 대한 액세스 권한은 [edit system login class class-name]계층 수준에서 permissions명령문에 지정된 하나 이상의 권한 플래그로 정의됩니다. 또한 확장된 정규 표현식을 정의하여 특정 명령 및 구성 계층 구조의 사용을 허용하거나 거부할 수 있습니다. 로그인 클래스에 대해 다음 명령문을 구성하여 정규 표현식을 지정할 수 있습니다.

  • allow-commands 및 deny-commands - 작동 모드 및 구성 모드 명령에 대한 액세스를 허용하거나 거부합니다.

  • allow-configuration 및 deny-configuration - 특정 구성 계층에 대한 액세스를 허용하거나 거부합니다.

    주:

    이러한 명령문은 특히 와일드카드 매치에서 보다 유연하고 보다 느린 매치를 수행합니다. 그러나 다수의 전체 경로 정규 표현식이나 와일드카드 표현식이 구성된 경우, 가능한 모든 명령문을 평가하는 데 매우 오랜 시간이 소요되어 성능에 부정적인 영향을 미칠 수 있습니다.

  • allow-commands-regexps 및 deny-commands-regexps - 정규 표현식 문자열을 사용하여 특정 명령에 대한 액세스를 허용하거나 거부합니다.

  • allow-configuration-regexps 및 deny-configuration-regexps - 정규 표현식 문자열을 사용하여 특정 구성 계층에 대한 액세스를 허용하거나 거부합니다.

주:

기존 구성에서 allow/deny-commands 또는 allow/deny-configuration 명령문을 사용하는 경우, allow/deny-commands-regexps 또는 allow/deny-configuration-regexps 명령문과 함께 동일한 구성 옵션을 사용하면 동일한 결과가 생성되지 않을 수 있습니다. 검색 및 매치 방법은 이러한 명령문의 두 가지 형식에서 다릅니다.

allow/deny-* 명령문을 사용하여 명령 및 구성 문 계층 구조를 명시적으로 허용하면, permissions 명령문이 이미 정의한 권한에 추가됩니다. 마찬가지로, allow/deny-* 명령문을 사용하여 명령 및 구성 명령문 계층 구조를 명시적으로 거부하면 permissions 명령문이 이미 정의한 권한이 제거됩니다.

예를 들어, 다음 구성에서 configure 권한이 있으면 로그인 클래스의 사용자가 구성 모드로 들어갈 수 있습니다. 또한, allow-configuration 식을 사용하면 [edit system services] 계층 수준에서 구성을 수정하고 커밋할 수 있습니다.

마찬가지로, 다음 구성에서 로그인 클래스 사용자는 all 권한 플래그가 허용하는 모든 작업을 수행할 수 있습니다. 단, 사용자가 [edit system services] 계층 수준에서 구성을 보거나 수정할 수 없다는 점은 예외입니다.

혀용 및 거부 명령문 구문에 대한 이해

각 로그인 클래스에서 한 번만 allow/deny-* 명령문을 구성할 수 있습니다. 명령문을 구성할 때:

  • 필요한 만큼 정규 표현식을 구성할 수 있습니다.

  • 정규 표현식은 대소문자를 구분하지 않음

allow/deny-commands 명령문은 allow/deny-commands-regexps 명령문과 상호 배타적이며, allow/deny-configuration 명령문은 allow/deny-configuration-regexps 명령문과 상호 배타적입니다. 예를 들어, 동일한 로그인 클래스에서 allow-configuration 및 allow-configuration-regexps를 모두 구성할 수 없습니다.

명령에 대한 액세스 권한을 정의하려면, allow-commands 및 deny-commands 명령문을 사용하여 확장된 정규 표현식을 지정합니다. 각각의 완전한 독립형 식을 괄호( )로 묶고 파이프( | ) 기호를 사용하여 식을 구분합니다. 파이프 기호로 연결된 정규 표현식 사이에는 공백을 사용하지 않습니다. 완전한 표현식은 큰따옴표로 묶입니다.

예:

allow-commands 명령문으로 복잡한 정규 표현식을 지정할 때는 앵커를 사용해야 합니다. 예:

구성 계층의 일부에 대한 액세스 권한을 정의하려면, allow-configuration 및 deny-configuration 명령문에 확장 정규 표현식을 지정합니다. 전체 경로를 괄호( )로 묶고 파이프( | ) 기호를 사용하여 식을 구분합니다. 파이프 기호로 연결된 정규 표현식 사이에는 공백을 사용하지 않습니다. 완전한 표현식은 큰따옴표로 묶입니다.

예:

allow/deny-commands-regexps 또는 allow/deny-configuration-regexps 명령문을 사용하여 확장 정규 표현식을 지정하는 경우, 각 식을 따옴표(" ")로 묶고 공백을 사용하여 식을 구분합니다. 여러 식은 대괄호 [ ]로 묶습니다. 예:

set, log, count 등의 수정자는 매치시킬 정규 표현식 문자열 내에서 지원되지 않습니다. 수정자를 사용하면 아무 것도 매치되지 않습니다.

올바른 구성:

잘못된 구성:

허용 및 거부 명령문 우선 순위 및 매치에 대한 이해

기본적으로, allow-commands 및 allow-configuration 정규 표현식은 deny-commands 및 deny-configuration 식보다 우선합니다. 따라서, allow-commands 및 deny-commands 명령문 모두에 대해 동일한 명령을 구성하면 허용 작업이 거부 작업보다 우선합니다. 마찬가지로 allow-configuration와(과) deny-configuration 명령문 모두에 대해 동일한 명령문을 구성하는 경우, 허용 작업이 거부 작업보다 우선합니다.

예를 들어, 다음 구성을 사용하면 명령문에 동일한 명령이 포함되어 deny-commands있어도 test로그인 클래스의 사용자가 request system software add명령을 사용하여 소프트웨어를 설치할 수 있습니다.

마찬가지로 다음 구성을 사용하면, test로그인 클래스 테스트의 사용자가 deny-configuration명령문에 동일한 계층이 포함되어 있어도 [edit system services]구성 계층을 보고 수정할 수 있습니다.

allow-commands 및 deny-commands 명령문에 명령의 두 가지 변형이 있는 경우, 가장 긴 매치 항목이 항상 실행됩니다. 다음 구성에서는 test 로그인 클래스의 사용자가 commit synchronize 명령을 실행할 수 있지만, commit 명령은 실행할 수 없습니다. 이는 commit synchronize가 commit와 commit synchronize 간의 가장 긴 매치 항목이고 allow-commands에 대해 지정되기 때문입니다.

다음 구성에서는 test 로그인 클래스의 사용자가 commit 명령을 실행할 수 있지만, commit synchronize 명령은 실행할 수 없습니다. 이는 commit synchronize가 commit와 commit synchronize 간의 가장 긴 매치 항목이고 deny-commands에 대해 지정되기 때문입니다.

다른 명령문과 달리, *-regexps 명령문의 기본 동작은 deny-commands-regexps 및 deny-configuration-regexps 정규 표현식이 allow-commands-regexps 및 allow-configuration-regexps 표현식보다 우선한다는 것입니다. 정규 표현식이 deny-configuration-regexps명령문보다 우선하도록 allow-configuration-regexps계층 [edit system]구조 수준에서 regex-additive-logic명령문을 구성할 수 있습니다. 명령문을 구성하면 더 높은 수준의 구성 계층을 거부한 다음 특정 하위 계층에 대한 사용자 액세스만 허용할 수 있습니다.

허용 및 거부 명령문의 규칙에 대한 이해

allow/deny-commands, allow/deny-configuration, allow/deny-commands-regexps 및 allow/deny-configuration-regexps 명령문은 로그인 클래스 권한보다 우선합니다. 이러한 명령문을 구성할 때 다음 규칙이 적용됩니다.

  • allow-commands 및 deny-commands 명령문의 정규 표현식에는 commit, load, rollback, save, status 및 update 명령도 포함될 수 있습니다.

  • rollback사용자가 rollback권한 플래그가 활성화되어 있는 명령을 사용할 때, all로그인 클래스 권한 비트는 확장 정규 표현보다 우선시됩니다.

  • 사용자는 확장 정규 표현식을 지정할 때 load override 명령을 실행할 수 없습니다. 사용자는 merge, replace 및 patch 구성 명령만 실행할 수 있습니다.

  • 정규 표현식을 나타낼 때 * 와일드카드 문자를 사용할 수 있습니다. 그러나 이는 정규 표현식의 일부로 사용해야 합니다. [ * ] 또는 [ .* ]을(를) 유일한 표현으로 사용할 수 없습니다. 또한 와(과) 같은 (interfaces (description (|.*))식으로 allow-configuration명령문을 구성할 수는 없습니다. 이는 (으)로 평가되기 allow-configuration .*때문입니다.

*-regexps 명령문의 차이점에 대한 이해

본 섹션에서는 allow/deny-configuration 명령문과 allow/deny-configuration-regexps 명령문 사이의 차이점을 설명합니다.

allow/deny-configuration-regexps 명령문은 정규 표현식을 토큰으로 분할하고 각 조각을 지정된 구성의 전체 경로의 각 부분과 매치시키는 반면, allow/deny-configuration 명령문은 전체 문자열과 매치시킵니다. allow/deny-configuration-regexps 명령문의 경우, 각 문자열이 문자열 용어 사이에 공백이 있는 정규 표현식인 일련의 문자열을 구성합니다. 이러한 구문은 매우 빠른 매치를 제공하지만, 유연성이 떨어집니다. 와일드카드 표현식을 지정하려면 매치시키려는 공백으로 구분된 문자열의 각 토큰에 대해 와일드카드를 설정해야 합니다. 그러면 이러한 명령문에 와일드카드 표현식을 사용하기가 더 어려워집니다.

예:

  • allow-configuration-regexps를 사용하여 하나의 토큰과 매치되는 정규 표현식

    해당 예는 options이(가) 명령문의 첫 번째 토큰과 매치되는 유일한 표현식임을 보여줍니다.

    앞의 구성은 다음 명령문과 매치됩니다.

    • set policy-options condition condition dynamic-db

    • set routing-options static route static-route next-hop next-hop

    • set event-options generate-event event time-interval seconds

    앞의 구성은 다음 명령문과 매치되지 않습니다.

    • system host-name host-options

    • interfaces interface-name description options

  • allow-configuration-regexps를 사용하여 3개의 토큰과 매치되는 정규 표현식

    이 예는 ssh이(가) 명령문의 세 번째 토큰과 매치되는 유일한 표현식임을 보여줍니다.

    앞선 예에서, 세 개의 토큰에는 각각 .*, .* 및 .*ssh이(가) 포함됩니다.

    앞의 구성은 다음 명령문과 매치됩니다.

    • system host-name hostname-ssh

    • system services ssh

    • system services outbound-ssh

    앞의 구성은 다음 명령문과 매치되지 않습니다.

    • interfaces interface-name description ssh

명령문을 deny-configuration-regexps사용하는 것보다 deny-configuration명령문을 사용하여 구성 액세스를 제한하는 것이 더 쉽습니다. 은(는) 특정 구성에 대한 액세스를 제한하는 동일한 결과를 얻기 위해 서로 다른 구성에서 및 deny-configuration-regexps명령문을 deny-configuration모두 사용하는 것을 표 2보여줍니다.

표 2: deny-configuration 및 deny-configuration-regexps 명령문을 사용하여 구성 액세스 제한

구성 거부됨

사용: deny-configuration

사용: deny-configuration-regexps

결과

xnm-ssl

 
[edit system]
login {
    class test {
        permissions configure;
         allow-configuration .*;
        deny-configuration .*xnm-ssl;
    }
}

[edit system]
login {
    class test {
        permissions configure;
         allow-configuration .*;
        deny-configuration-regexps ".* .* .*-ssl"";
    }
}

다음 구성 명령문은 거부됩니다.

  • system services xnm-ssl

ssh

 
[edit system]
login {
    class test {
        permissions configure;
        allow-configuration .*;
        deny-configuration ".*ssh";
    }
}

[edit system]
login {
    class test {
        permissions configure;
        allow-configuration .*;
        deny-configuration-regexps ".*ssh";
        deny-configuration-regexps ".* .*ssh";
        deny-configuration-regexps ".* .* .*ssh";
    }
}

다음 구성 명령문들은 거부됩니다.

  • system host-name hostname-ssh

  • system services ssh

  • system services outbound-ssh

  • security ssh-known-host

간단한 구성을 원할 때 allow/deny-configuration 명령문도 유용하지만, allow/deny-configuration-regexps 명령문은 더 나은 성능을 제공하고 allow/deny-configuration 명령문에서 식을 결합할 때 존재하는 모호성을 극복하게 합니다.

원격 인증 서버에서 정규 표현식 사용

확장 정규 표현식을 사용하여, 특정 사용자에 대해 허용되거나 거부되는 작동 모드 및 구성 모드 명령과 구성 명령문 및 계층을 지정할 수 있습니다. 계층 [edit system login class class-name]구조 수준에서 , , allow/deny-commands-regexps및 allow/deny-configuration-regexps명령문에 allow/deny-commandsallow/deny-configuration이러한 정규 표현식을 로컬로 지정합니다. 인증 서버 구성에서 주니퍼 네트웍스 벤더별 TACACS+ 또는 RADIUS 속성을 지정하여 이러한 정규 표현식을 원격으로 지정합니다. 로컬 및 원격으로 권한 부여 매개 변수를 구성하면 TACACS+ 또는 RADIUS 권한 부여 중에 수신된 정규식이 로컬 디바이스에 정의된 정규식과 병합됩니다.

주:

Junos OS 릴리스 18.1부터 TACACS+ 인증에 대해 allow-commands-regexps 및 deny-commands-regexps 명령문이 지원됩니다.

allow-commands, deny-commands, allow-configuration 또는 deny-configuration을(를) 사용하여 로컬 구성에서 여러 정규 표현식을 지정하는 경우 7개 문장의 경우 괄호 안에 정규 표현식을 구성하고 파이프 기호를 사용하여 구분합니다. 완전한 식은 큰따옴표로 묶습니다. 예를 들어, 다음 구문을 사용하여 여러 allow-commands 매개 변수를 지정할 수 있습니다.

RADIUS 인증 서버는 다음 속성과 구문을 사용합니다.

TACACS+ 인증 서버는 다음 속성과 구문을 사용합니다.

allow-commands-regexps, deny-commands-regexps, allow-configuration-regexps 또는 deny-configuration-regexps을(를) 사용하여 로컬 구성에서 여러 정규 표현식을 지정하는 경우, 큰따옴표 안에 정규 표현식을 구성하고 공백 연산자를 사용하여 구분합니다. 완전한 표현식을 대괄호로 묶습니다. 예를 들어, 다음 구문을 사용하여 여러 allow-commands 매개 변수를 지정할 수 있습니다.

RADIUS 인증 서버는 다음 속성과 구문을 사용합니다.

TACACS+ 인증 서버는 다음 속성과 구문을 사용합니다.

RADIUS 및 TACACS+ 서버는 별도의 줄에 각 개별 표현식을 지정하는 Simplified 구문도 지원합니다. 예를 들어, RADIUS 서버의 Simplified 구문은 다음과 같습니다.

마찬가지로 TACACS+ 서버 Simplified 구문은 다음과 같습니다.

표 3 정규 표현식을 사용하여 로컬 인증 구성과 TACACS+ 서버 인증 구성을 구분합니다.

표 3: 정규 표현식을 사용한 로컬 및 원격 권한 부여 구성의 예

로컬 구성

원격 TACACS+ 구성

 
login {
    class local {
        permissions configure;
        allow-commands "(ping .*)|(traceroute .*)|(show .*)|(configure .*)|(edit)|(exit)|(commit)|(rollback .*)";
        deny-commands .*;
        allow-configuration "(interfaces .* unit 0 family ethernet-switching vlan mem.* .*)|(interfaces .* native.* .*)|(interfaces .* unit 0 family ethernet-switching interface-mo.* .*)|(interfaces .* unit .*)|(interfaces .* disable)|(interfaces .* description .*)|(vlans .* vlan-.* .*)"
        deny-configuration .*;
    }
}

user = remote {
    login = username
    service = junos-exec {
        allow-commands1 = "ping .*"
        allow-commands2 = "traceroute .*"
        allow-commands3 = "show .*"
        allow-commands4 = "configure"
        allow-commands5 = "edit"
        allow-commands6 = "exit"
        allow-commands7 = "commit"
        allow-commands8 = ".*xml-mode"
        allow-commands9 = ".*netconf.*"
        allow-commands10 = ".*need-trailer"
        allow-commands11 = "rollback.*"
        allow-commands12 = "junoscript"
        deny-commands1 = ".*"
        allow-configuration1 = "interfaces .* unit 0 family ethernet-switching vlan mem.* .*"
        allow-configuration2 = "interfaces .* native.* .*"
        allow-configuration3 = "interfaces .* unit 0 family ethernet-switching interface-mo.* .*"
        allow-configuration4 = "interfaces .* unit .*"
        allow-configuration5 = "interfaces .* disable"
        allow-configuration6 = "interfaces .* description .*"
        allow-configuration7 = "interfaces .*"
        allow-configuration8 = "vlans .* vlan-.* .*"
        deny-configuration1 = ".*"
        local-user-name = local-username
        user-permissions = "configure"
    }
}
주:

  • 다음 세 가지 명령을 실행하여 로컬 또는 원격에서 NETCONF 모드에 대한 액세스를 명시적으로 허용해야 합니다. xml-mode, netconf, need-trailer 목적으로 사용할 수 있습니다.

  • deny-configuration = ".*" 명령문을 사용할 때는 allow-configuration 명령문을 사용하여 원하는 구성을 모두 허용해야 합니다. 그러나 이 구성은 allow-configuration 명령문에 대해 허용되는 정규 표현식 버퍼 제한에 영향을 줄 수 있습니다. 이 제한을 초과하면 허용된 구성이 작동하지 않을 수 있습니다.

정규 표현식 지정

경고:

명령 및 구성 명령문에 대한 정규 표현식을 지정할 때 다음 예와 같이 주의를 기울이십시오. 구문이 잘못된 정규 표현식은 구성이 오류 없이 커밋되더라도 원하는 결과를 생성하지 못할 수 있습니다.

전체 명령 또는 명령문을 실행하는 것과 동일한 방식으로 명령 및 구성 명령문에 대한 정규 표현식을 지정해야 합니다. 표 4은(는) [edit interfaces] 및 [edit vlans] 명령문 계층 에 대한 액세스 권한을 구성하기 위한 정규 표현식을 나열합니다.

표 4: 정규 표현식 지정

명령문

정규 표현식

구성 참고 사항

[edit interfaces]

set 인터페이스에 대한 명령은 다음과 같이 실행됩니다.

[edit]
user@host# set interfaces interface-name unit interface-unit-number

set interfaces 명령문은 그 자체로는 불완전하며, 이를 실행하려면 unit 옵션이 필요합니다.

결과적으로, set interfaces 구성을 거부하는 데 필요한 정규 표현식은 명령문 변수 대신 .* 연산자를 사용하여 전체 실행 문자열을 지정해야 합니다.

[edit system login class class-name]
user@host# set permissions configure
user@host# set deny-configuration "interfaces .* unit .*"

  • .* 연산자는 특정 명령이나 명령문에 대해 지정된 지점부터 모든 것을 나타냅니다. 이 예에서는 단위 값이 있는 인터페이스 이름을 나타냅니다.

  • deny-configuration "interfaces .*" 명령문만 지정하는 것은 올바르지 않으며, 지정된 로그인 클래스에 대한 인터페이스 구성에 대한 액세스를 거부하지 않습니다.

  • 다른 유효한 옵션이 정규 표현식에 포함될 수 있습니다. 예:

    [edit system login class class-name]
user@host# set permissions configure
user@host# set deny-configuration "interfaces .* description .*"

    [edit system login class class-name]
user@host# set permissions configure
user@host# set allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ]

    [edit system login class class-name]
user@host# set permissions configure
user@host# set allow-configuration "interfaces .* unit 0 family ethernet-switching vlan mem.* .*"

    참고: 이 예의 mem.* 정규 표현식은 mem 키워드로 시작하는 여러 문자열이 지정된 정규 표현식에 포함될 것으로 예상되는 경우에 사용됩니다. member 문자열이 하나만 포함될 것으로 예상되는 경우, member .* 정규 표현식을 사용합니다.

[edit vlans]

VLANs에 대한 set 명령은 다음과 같이 실행됩니다.

[edit]
user@host# set vlans vlan-name vlan-id vlan-id

여기서 set vlans 명령문은 그 자체로는 불완전하며, 명령문을 실행하기 위해서는 vlan-id 옵션이 필요합니다.

결과적으로, set vlans 구성을 허용하는 데 필요한 정규 표현식은 명령문 변수 대신 .* 연산자를 사용하여 전체 실행 문자열을 지정해야 합니다.

[edit system login class class-name]
user@host# set permissions configure
user@host# set allow-configuration "vlans .* vlan-id .*"

  • .* 연산자는 특정 명령이나 명령문에 대해 지정된 지점부터 모든 것을 나타냅니다. 본 예에서는 VLAN ID가 있는 모든 VLAN 이름을 나타냅니다.

  • [edit vlans] 명령문 계층 아래의 다른 유효한 옵션은 정규 표현식에 포함될 수 있습니다. 예:

    [edit system login class class-name]
user@host# set permissions configure
user@host# set allow-configuration-regexps [ "vlans .* vlan-id .*" "vlans .* vlan-id .* description .*" "vlans .* vlan-id .* filter .*" ]

정규 표현식 연산자

표 5 작동 및 구성 모드를 허용하거나 거부하는 데 사용하는 일반적인 정규 표현식 연산자를 나열합니다.

명령 정규 표현식은 POSIX 1003.2에 정의된 대로 확장된(최신) 정규 표현식을 구현합니다.

표 5: 일반 정규 표현식 연산자

연산자

매치

예

|

파이프로 구분된 둘 이상의 용어 중 하나입니다. 각 용어는 괄호( )로 묶인 완전한 독립형 표현식이어야 하며, 파이프와 인접한 괄호 사이에 공백이 없어야 합니다.

 
[edit system login class test]
user@host# set permissions configure
user@host# set allow-commands "(ping)|(traceroute)|(show system alarms)|(show system software)"
user@host# set deny-configuration "(access)|(access-profile)|(accounting-options)|(applications)|(apply-groups)|(bridge-domains)|(chassis)|(class-of-service)"

이전 구성에서 테스트 로그인 클래스에 할당된 사용자는 allow-commands 명령문에 지정된 명령으로만 작동 모드 액세스가 제한됩니다. 또한 deny-configuration 명령문에 지정된 계층 수준을 제외하고 구성 모드에 액세스할 수 있습니다.

^

식의 시작 부분에서 명령이 시작되는 위치를 나타내는 데 사용되며 모호성이 있을 수 있습니다.

 
[edit system login class test]
user@host# set permissions interface
user@host# set permissions interface-control
user@host# set allow-commands "(^show) (log|interfaces|policer))|(^monitor)"

이전 구성에서 테스트 로그인 클래스에 할당된 사용자는 인터페이스 구성을 보고 구성할 수 있습니다. allow-commands 명령문은 show 및 monitor 키워드로 시작하는 명령에 대한 액세스 권한을 부여합니다.

첫 번째 필터의 경우, 지정된 명령에는 show log, show interfaces 및 show policer 명령이 포함됩니다. 두 번째 필터는 또는 monitor traffic명령과 monitor interfaces같이 monitor키워드로 시작하는 모든 명령을 지정합니다.

$

명령 끝에 있는 문자. 해당 지점까지 정확히 매치해야 하는 명령을 나타내는 데 사용됩니다.

 
[edit system login class test]
user@host# set permissions interface
user@host# set allow-commands "(show interfaces$)"

이전 구성에서 테스트 로그인 클래스에 할당된 사용자는 구성 모드에서 인터페이스 구성을 볼 수 있습니다. 사용자는 show configuration 작동 모드 명령으로 인터페이스 구성을 볼 수도 있습니다. 그러나 allow-commands 명령문에 지정된 정규 표현식은 사용자가 show interfaces 명령만 실행하도록 제한하고, show interfaces detail 또는 show interfaces extensive와(과) 같은 명령 확장에 대한 액세스는 거부합니다.

[ ]

문자 또는 숫자의 범위. 범위의 시작과 끝을 구분하려면 하이픈( - )을 사용합니다.

 
[edit system login class test]
user@host# set permissions clear
user@host# set permissions configure
user@host# set permissions network
user@host# set permissions trace
user@host# set permissions view
user@host# set allow-configuration-regexps [ "interfaces [gx]e-.* unit [0-9]* description .*" ]

이전 구성에서 테스트 로그인 클래스에 할당된 사용자는 운영자 수준의 사용자 권한을 가집니다. 또한 이러한 사용자는 인터페이스 이름 및 장치 번호(0~9)의 지정된 범위 내에서 인터페이스를 구성하는 액세스 권한을 가집니다.

( )

평가할 완전한 독립 실행형 표현식을 나타내는 명령 그룹입니다. 그런 다음 결과는 전체 표현식의 일부로 평가됩니다. 설명된 대로 괄호는 파이프 연산자와 함께 사용해야 합니다.

 
[edit system login class test]
user@host# set permissions all
user@host# set allow-commands "(clear)|(configure)"
user@host# deny-commands "(mtrace)|(start)|(delete)"

위의 구성에서 테스트 로그인 클래스에 할당된 사용자는 수퍼유저 수준의 권한을 가지며, allow-commands 명령문에 지정된 명령에 액세스할 수 있습니다.

*

0개 이상의 용어.

 
[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m*)"

위 구성에서 로그인 사용자 이름이 m으(로) 시작하는 테스트 로그인 클래스에 할당된 사용자는 구성 액세스가 거부됩니다.

+

1개 이상의 용어.

 
[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m+)"

위 구성에서 로그인 사용자 이름이 m으(로) 시작하는 테스트 로그인 클래스에 할당된 사용자는 구성 액세스가 거부됩니다.

.

공백 " "을 제외한 모든 문자.

 
[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m.)"

위 구성에서 로그인 사용자 이름이 m으(로) 시작하는 테스트 로그인 클래스에 할당된 사용자는 구성 액세스가 거부됩니다.

. *

지정된 지점 이후의 모든 것.

 
[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m .*)"

위 구성에서 로그인 사용자 이름이 m으(로) 시작하는 테스트 로그인 클래스에 할당된 사용자는 구성 액세스가 거부됩니다.

마찬가지로 deny-configuration "protocols .*" 명령문은 [edit protocols] 계층 수준 아래의 모든 구성 액세스를 거부합니다.

주:

  • *, +, . 연산은 .*을(를) 사용하여 수행할 수 있습니다.

  • deny-commands .* 및 deny-configuration .* 명령문은 각각 모든 작동 모드 명령 및 구성 계층에 대한 액세스를 거부합니다.
주:

! 정규 표현식 연산자는 지원되지 않습니다.

정규 표현식 예

표 6은(는) 정규 표현식을 지정하기 위한 예로, [edit system ntp server]와 [edit protocols rip]의 두 구성 계층에서 구성 옵션을 허용하는 데 사용되는 정규 표현식을 나열합니다.

주:

표 6은(는) 모든 구성 명령문 및 계층에 대한 모든 정규 표현식 및 키워드의 포괄적인 목록을 제공하지 않습니다. 표에 나열된 정규 표현식은 [edit system ntp server] 및 [edit protocols rip] 명령문 계층에 대해서만 유효성이 검사됩니다.
표 6: 정규 표현식의 예

명령문 계층

정규 표현식

허용되는 구성

거부된 구성

[edit system ntp server]

      

키 key-number

 
[edit system login class test]
set permissions configure
set allow-configuration-regexps [ "system ntp server .*" "system ntp server .* key .*" ]
set deny-configuration-regexps [ "system ntp server .* version .*" "system ntp server .* prefer" ]

  • 서버 IP

  • 서버 IP 및 키

  • 버전

  • 선호

버전 version-number

 
[edit system login class test]
set permissions configure
set allow-configuration-regexps [ "system ntp server .*" "system ntp server .* version .*" ]
set deny-configuration-regexps [ "system ntp server .* key .*" "system ntp server .* prefer" ]

  • 서버 IP

  • 서버 IP 및 버전

  • key

  • 선호

선호

 
[edit system login class test]
set permissions configure
set allow-configuration-regexps [ "system ntp server .*" "system ntp server .* prefer" ];
set deny-configuration-regexps [ "system ntp server .* key .*" "system ntp server .* version .*" ]

  • 서버 IP

  • 서버 IP 및 선호

  • key

  • 버전

[edit protocols rip]

      

메시지 크기 message-size

 
[edit system login class test]
set permissions configure
set allow-configuration-regexps "protocols rip message-size .*"
set deny-configuration-regexps [ "protocols rip metric-in .*" "protocols rip route-timeout .*" "protocols rip update-interval .*" ]

  • 메시지 크기

  • 메트릭 인

  • 루트 타임아웃

  • 업데이트 간격

메트릭 인 metric-in 

[edit system login class test]
set permissions configure
set  allow-configuration-regexps "protocols rip metric-in .*"
set  deny-configuration-regexps [ "protocols rip message-size .*" "protocols rip route-timeout .*" "protocols rip update-interval .*" ]

  • 메트릭 인

  • 메시지 크기

  • 루트 타임아웃

  • 업데이트 간격

루트 타임아웃 route-timeout 

[edit system login class test]
set permissions configure
set allow-configuration-regexps "protocols rip route-timeout .*"
set deny-configuration-regexps [ "protocols rip metric-in .*" "protocols rip message-size .*" "protocols rip update-interval .*" ]

  • 루트 타임아웃

  • 메시지 크기

  • 메트릭 인

  • 업데이트 간격

업데이트 간격 update-interval

 
[edit system login class test]
set permissions configure
set allow-configuration-regexps "protocols rip update-interval .*"
set deny-configuration-regexps [ "protocols rip metric-in .*" "protocols rip route-timeout .*" "protocols rip message-size .*" ]

  • 업데이트 간격

  • 메시지 크기

  • 메트릭 인

  • 루트 타임아웃

allow-configuration 및 deny-configuration 문을 사용하여 액세스 권한을 정의하는 방법

다음 유형의 문을 조합하여 구성 문 계층에 대한 액세스 권한을 정의할 수 있습니다.

  • 권한 플래그

  • allow-configuration 및 deny-configuration 문

권한 플래그는 사용자나 로그인 클래스가 액세스하고 제어할 수 있는 항목의 더 큰 경계를 정의합니다. allow-configuration 및 deny-configuration 문에는 하나 이상의 정규식이 포함되어 있어 특정 구성 계층 및 문을 허용하거나 거부합니다. allow-configuration 및 deny-configuration 문은 권한 플래그보다 우선하며, 관리자로 하여금 사용자가 보고 구성할 수 있는 계층과 문을 정확하게 제어할 수 있도록 합니다.

이 주제에서는 이러한 문을 사용하는 로그인 클래스 구성의 예시를 보여주면서 allow-configuration 및 deny-configuration 문을 사용하여 액세스 권한을 정의하는 방법에 대해 설명합니다. 예시 1~3은 deny-configuration 문에 정의된 항목을 제외한 모든 명령과 문에 대해 사용자 액세스를 허용하는 로그인 클래스를 생성합니다.

권한 비트 및 권한 플래그는 같은 의미로 사용됩니다.

예시 1

사용자가 모든 명령을 실행하고 텔넷 매개 변수를 제외한 모든 항목을 구성할 수 있는 로그인 클래스를 생성하려면 다음 단계를 따르십시오.

  1. 사용자의 로그인 클래스 권한을 all로 설정합니다.
  2. 다음 deny-configuration 문을 포함합니다.

예시 2

사용자가 모든 명령을 실행하고 이름이 'm'으로 시작하는 로그인 클래스 내의 문을 제외한 모든 항목을 구성할 수 있는 로그인 클래스를 생성하려면 다음 단계를 따르십시오.

  1. 사용자의 로그인 클래스 권한을 all로 설정합니다.

  2. 다음 deny-configuration 문을 포함합니다.

예시 3

사용자가 모든 명령을 실행하고 [edit system login class] 또는 계층 [edit system services] 수준을 제외한 모든 항목을 구성할 수 있는 로그인 클래스를 생성하려면 다음 단계를 따르십시오.

  1. 사용자의 로그인 클래스 권한을 all로 설정합니다.

  2. 다음 deny-configuration 문을 포함합니다.

다음 예시는 allow-configuration 및 deny-configuration 문을 사용하여 [edit system services] 계층 수준에 대해 서로 반대되는 권한을 결정하는 방법을 보여줍니다.

예시 4

사용자가 [edit system services] 계층 수준에서만 전체 구성 권한을 갖도록 허용하는 로그인 클래스를 생성하려면 다음 단계를 따르십시오.

  1. 사용자의 로그인 클래스 권한을 configure로 설정합니다.

  2. 다음 allow-configuration 문을 포함합니다.

예시 5

사용자가 [edit system services] 계층 수준을 제외한 모든 명령과 모든 구성 계층에 대해 전체 권한을 갖도록 허용하는 로그인 클래스를 생성하려면 다음 단계를 따르십시오.

  1. 사용자의 로그인 클래스 권한을 all로 설정합니다.

  2. 다음 deny-configuration 문을 포함합니다.

예: 정규식과 함께 추가 논리를 사용하여 액세스 권한 지정

이 예에서는 정규식을 사용하여 구성 액세스 권한을 설정할 때 추가 논리를 사용하는 방법을 보여 줍니다.

요구 사항

이 예에서는 Junos OS 릴리스 16.1 이상을 실행하는 장치를 사용합니다.

개요

구성을 변경할 수 있는 사용자와 변경할 수 있는 항목을 제어하기 위해 정규식을 정의할 수 있습니다. 이러한 정규식은 로그인 클래스의 사용자가 액세스할 수 있는 특정 구성 계층을 나타냅니다. 예를 들어 사용자가 라우팅 인스턴스 그룹을 수정할 수 있는 정규식을 정의하고 사용자가 다른 라우팅 인스턴스 또는 다른 구성 수준을 변경하지 못하도록 하는 정규식을 정의할 수 있습니다. 로그인 클래스에 대해 allow-configuration-regexps 및 deny-configuration-regexps문을 구성하여 정규식을 정의합니다.

기본적으로 deny-configuration-regexps문이 allow-configuration-regexps문보다 우선합니다. 로그인 클래스에 대한 deny-configuration-regexps문에 구성 계층이 나타나면 allow-configuration-regexps문의 내용에 관계없이 해당 클래스의 사용자에게 보이지 않습니다. deny-configuration-regexps문에 구성 계층이 나타나지 않는 경우, allow-configuration-regexps문에 구성 계층이 나타나면 해당 클래스의 사용자가 볼 수 있습니다.

*-configuration-regexps문에 대한 가산 논리를 활성화하여 이 기본 동작을 변경할 수 있습니다. 덧셈 논리를 사용하도록 설정하면 allow-configuration-regexps문이 deny-configuration-regexps문보다 우선합니다.

따라서 deny-configuration-regexps문이 주어진 수준(protocols.*)에서 모든 구성 계층에 대한 액세스를 거부하지만, allow-configuration-regexps문이 하나의 하위 계층(protocols bgp.*)에 대한 액세스를 허용한다면, 장치는 기본적으로 deny-configuration-regexps문이 우선하므로 해당 로그인 클래스의 사용자에 대한 계층에 대한 액세스를 거부합니다. 그러나 추가 논리를 사용하도록 설정하면 allow-configuration-regexps이(가) 이 경우 우선하므로 장치는 해당 로그인 클래스의 사용자에 대해 지정된 하위 계층에 대한 액세스를 허용합니다.

구성

단계별 절차

지정된 로그인 클래스의 사용자가 하나 이상의 개별 구성 계층에 대한 액세스를 명시적으로 허용하는 추가 논리를 사용하려면,

  1. deny-configuration-regexps문을 포함하고, 구성 계층에 대한 액세스를 명시적으로 거부합니다.

    예:

  2. allow-configuration-regexps문을 포함하고, 특정 계층에 허용할 정규식을 정의합니다.

    예:

  3. allow-configuration-regexps과 deny-configuration-regexps 정규 표현식에 대한 덧셈 논리를 사용합니다.

  4. 로그인 클래스를 한 명 이상의 사용자에게 할당합니다.

  5. 변경 내용을 커밋합니다.

    이 로그인 클래스에 할당된 사용자는 allow-configuration-regexps문에 포함된 구성 계층에 액세스할 수 있지만 deny-configuration-regexps문에 지정된 다른 계층에는 액세스할 수 없습니다.

주:

regex-additive-logic문을 구성하면 모든 로그인 클래스에 있는 allow-configuration-regexps과 deny-configuration-regexps문 모두에 동작 변경이 적용됩니다. 추가 논리를 사용하는 경우 기존 문에 미치는 영향을 평가하고 해당 문의 정규식을 적절하게 업데이트해야 합니다.

예

추가 논리와 함께 정규식 사용

목적

이 절에서는 시스템에 적합한 구성을 만들기 위한 아이디어를 제공하기 위해 추가 논리를 사용하는 정규식의 예를 제공합니다.

특정 라우팅 인스턴스 허용

다음 로그인 클래스 예제에는 이름이 CUST-VRF-(으)로 시작하는 라우팅 인스턴스의 구성을 허용하는 정규 표현식이 포함되어 있습니다. 예를 들어 CUST-VRF-1, CUST-VRF-25, CUST-VRF-100등입니다. 이 예에는 라우팅 인스턴스의 구성을 금지하는 정규식도 포함되어 있습니다.

기본적으로 deny-configuration-regexps문이 우선하며, 이전 구성에서는 이름에 관계없이 로그인 클래스의 사용자가 라우팅 인스턴스를 구성할 수 없습니다.

그러나 다음 문을 구성하면 allow-configuration-regexps문이 우선합니다. 따라서 사용자는 이름이 CUST-VRF-(으)로 시작하는 라우팅 인스턴스를 구성할 수 있지만 다른 라우팅 인스턴스는 구성할 수 없습니다.

BGP 피어 구성만 허용

다음 로그인 클래스 예제에는 [edit protocols] 계층 수준에서는 구성을 금지하지만 BGP 피어는 구성할 수 있는 정규식이 포함되어 있습니다.

[edit protocols]에서 기본적으로 이전 구성은 로그인 클래스의 사용자가 아래의 계층을 변경하는 것을 방지합니다.

그러나 다음 문을 구성하는 경우 로그인 클래스의 사용자는 BGP 피어를 변경할 수 있지만 허용된 계층 수준을 벗어난 다른 프로토콜 또는 기타 BGP 문을 구성할 수 없습니다.

검증

액세스 권한을 올바르게 설정했는지 확인하려면,

  1. 로그인 클래스를 구성하고 변경 내용을 커밋합니다.

  2. 로그인 클래스를 username에 할당합니다.

  3. 새로운 로그인 클래스와 함께 할당된 username(으)로 로그인합니다.

  4. 허용되는 계층 수준을 구성하려고 합니다.

    • 허용된 계층 수준에서 문을 구성할 수 있어야 합니다.

    • 거부된 계층 수준은 표시되지 않아야 합니다.

    • 허용되거나 거부된 표현식은 permissions문에 부여된 모든 권한보다 우선해야 합니다.

예: 운영 모드 명령에 대한 액세스 권한으로 사용자 권한 구성

이 예는 사용자 정의 로그인 클래스 구성 및 운영 모드 명령에 대한 액세스 권한 할당 방법을 보여줍니다. 로그인 클래스의 사용자는 액세스 권한이 있는 명령만 실행할 수 있습니다. 이를 통해 권한이 없는 사용자가 네트워크에 손상을 줄 수 있는 중요한 명령을 실행하는 것을 방지합니다.

요구 사항

이 예에서 사용되는 하드웨어 및 소프트웨어 구성 요소는 다음과 같습니다.

  • 주니퍼 네트웍스 디바이스 1개

  • TACACS+(또는 RADIUS) 서버 1개

시작하기 전에 디바이스 및 TACACS+ 서버 간에 TCP 연결을 설정하십시오. RADIUS 서버의 경우 디바이스 및 RADIUS 서버 간에 UDP 연결을 설정합니다.

개요 및 토폴로지

그림 1은(는) 라우터 R1이 주니퍼 네트웍스 디바이스이며 TACACS+ 서버와 TCP 연결이 설정된 간단한 토폴로지를 보여줍니다.

그림 1: 토폴로지토폴로지

이 예는 사용자 정의된 로그인 클래스 3개로 R1을 구성합니다. 클래스 1, 클래스 2, 클래스 3. 각 클래스는 permissions문을 구성하고 allow-commands 및 deny-commands문을 사용해 확장된 정규 표현을 정의함으로써 사용자에 대한 액세스 권한을 정의합니다.

각 로그인 클래스의 목적은 다음과 같습니다.

  • Class1 - allow-commands문으로만 사용자에 대한 액세스 권한을 정의합니다. 이 로그인 클래스는 디바이스 재부팅하기 위한 운영자 수준의 사용자 승인 및 권한을 제공합니다.

  • Class2 - deny-commands문으로만 사용자에 대한 액세스 권한을 정의합니다. 이 로그인 클래스는 운영자 수준의 사용자 허가를 제공하고 set명령에 대한 액세스를 거부합니다.

  • Class3 - allow-commands 및 deny-commands문을 모두 사용해 사용자에 대한 액세스 권한을 정의합니다. 이 로그인 클래스는 인터페이스에 액세스하고 디바이스 정보를 볼 수 있는 슈퍼유저 수준의 승인 및 권한을 제공합니다. 또한 edit 및 configure명령에 대한 액세스를 거부합니다.

라우터 R1에는 Class1, Class2, Class3 로그인 클래스에 할당된 User1, User2, User3의 3개의 다른 사용자가 있습니다.

구성

CLI 빠른 구성

이 예를 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일로 붙여 넣은 다음 모든 라인브레이크를 제거하고, 네트워크 구성을 일치하는 데 필요한 세부 사항을 바꾸고 [edit]계층 수준에서 명령을 CLI로 복사해 붙여 넣은 다음, 구성 모드에서 commit을(를) 입력합니다.

R1

라우터 R1에 대한 인증 매개 변수 구성

단계별 절차

라우터 R1 인증 구성을 위해 다음을 수행합니다.

  1. R1 사용자 인증을 시도하는 순서를 구성합니다. 이 예에서는 먼저 TACACS+ 서버 인증을 사용한 다음 RADIUS 서버 인증을, 그리고 그다음으로 로컬 암호를 사용합니다.

  2. TACACS+ 서버를 구성합니다.

  3. RADIUS 서버를 구성합니다.

  4. R1 계정 매개 변수를 구성합니다.

allow-commands 문(Class1)을 사용하여 액세스 권한 구성

단계별 절차

allow-commands 문을 사용하여 정규식을 지정하기 위해 다음을 수행합니다.

  1. Class1 로그인 클래스를 구성하고 운영자 수준의 사용자 승인을 할당합니다.

  2. 클래스의 사용자가 디바이스를 재부팅할 수 있도록 allow-commands 정규식을 구성합니다.

  3. Class1 로그인 클래스에 대한 사용자 계정을 구성합니다.

dene-commands 문(Class2)을 사용하여 액세스 권한 구성

단계별 절차

deny-commands 문을 사용하여 정규식을 지정하기 위해 다음을 수행합니다.

  1. Class2 로그인 클래스를 구성하고 운영자 수준의 사용자 승인을 할당합니다.

  2. 클래스 사용자가 set 명령을 실행하는 것을 방지하기 위해 deny-commands 정규식을 구성합니다.

  3. Class2 로그인 클래스에 대한 사용자 계정을 구성합니다.

allow-commands 및 dene-commands 문(Class3)을 모두 사용하여 액세스 권한 구성

단계별 절차

allow-commands 및 deny-commands 문을 모두 사용하여 정규식을 지정하기 위해 다음을 수행합니다.

  1. Class3 로그인 클래스를 구성하고 슈퍼유저 수준의 승인을 할당합니다.

  2. 클래스 사용자가 모든 명령을 실행하는 것을 방지하기 위해 deny-commands 정규식을 구성합니다.

  3. allow-commands 정규식을 구성해 사용자가 구성 모드를 입력할 수 있도록 합니다.

  4. Class3 로그인 클래스에 대한 사용자 계정을 구성합니다.

결과

구성 모드에서 show system 명령을 입력하여 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.

검증

새로운 로그인 클래스에 할당된 사용자 이름으로 로그인하고 구성이 제대로 작동하는지 확인합니다.

Class1 구성 확인

목적

Class1 로그인 클래스에서 허용된 사용 승인 및 명령이 작동하는지 확인합니다.

작업

운영 모드에서 show system users 명령을 실행합니다.

운영 모드에서 request system reboot 명령을 실행합니다.

의미

User1이 할당된 Class1 로그인 클래스는 운영자 수준의 사용자 승인을 보유하고 있으며 클래스 사용자가 request system reboot 명령을 실행할 수 있습니다.

사전 정의된 운영자 로그인 클래스는 다음과 같은 승인 플래그가 지정되어 있습니다.

  • clear - clear 명령을 사용해 디바이스가 네트워크로부터 학습한 정보를 지우고 다양한 네트워크 데이터베이스에 저장할 수 있습니다.

  • network - ping, ssh, telnet, 및 traceroute 명령을 사용해 네트워크에 액세스할 수 있습니다.

  • reset - restart 명령을 사용하여 소프트웨어 프로세스를 다시 시작할 수 있습니다.

  • trace - 추적 파일 설정을 보고 추적 파일 속성을 구성할 수 있습니다.

  • view - 다양한 명령을 사용해 현재 시스템 전체, 라우팅 테이블 및 프로토콜 특정 값 및 통계를 표시할 수 있습니다. 비밀 구성을 볼 수 없습니다.

Class1 로그인 클래스의 경우 위에서 언급한 사용자 승인 외에도 User1은 request system reboot 명령을 실행할 수 있습니다. 첫 번째 출력은 운영자로서의 뷰 승인을 표시하고 두 번째 출력은 User1이 운영자로 실행할 수 있는 유일한 request system 명령어가 request system reboot 명령어임을 보여줍니다.

Class2 구성 확인

목적

Class2 로그인 클래스에서 허용된 사용 승인 및 명령이 작동하는지 확인합니다.

작업

운영 모드에서 ping 명령을 실행합니다.

CLI 프롬프트에서 사용 가능한 명령을 확인합니다.

CLI 프롬프트에서 모든 집합 명령을 실행합니다.

의미

User2가 할당된 Class2 로그인 클래스는 운영자 수준의 사용자 승인을 보유하고 있으며 모든 set 명령에 대한 액세스를 거부합니다.

사전 정의된 운영자 로그인 클래스에 지정된 승인 플래그는 Class1에 대한 지정된 것과 동일합니다.

Class3 구성 확인

목적

Class3 로그인 클래스에서 허용된 사용 승인 및 명령이 작동하는지 확인합니다.

작업

운영 모드에서 사용 가능한 명령을 확인합니다.

구성 모드로 진입합니다.

의미

User3이 할당된 Class3 로그인 클래스는 슈퍼유저(모든) 승인을 가지고 있지만 이 클래스는 사용자가 configure 명령만 실행할 수 있도록 합니다. 클래스는 모든 다른 운영 모드 명령에 대한 액세스를 거부합니다. allow/deny-commands 문에 지정된 정규식이 사용자 승인보다 우선시되므로 R1의 User3은 구성 모드에만 액세스할 수 있으며 다른 모든 운영 모드 명령에 대한 액세스가 거부됩니다.

예: 구성 문 및 계층에 대한 액세스 권한으로 사용자 권한 구성

이 예에서는 사용자 정의 로그인 클래스를 구성하고 특정 구성 계층에 액세스 권한을 할당하는 방법을 보여 줍니다. 로그인 클래스의 사용자는 액세스 권한이 있는 구성 문 및 계층만 보고 수정할 수 있습니다. 이렇게 하면 권한 없는 사용자가 네트워크에 손상을 줄 수 있는 디바이스 구성을 수정할 수 없습니다.

요구 사항

이 예에서 사용되는 하드웨어 및 소프트웨어 구성 요소는 다음과 같습니다.

  • 주니퍼 네트웍스 디바이스 1개

  • TACACS+(또는 RADIUS) 서버 1개

시작하기 전에 디바이스 및 TACACS+ 서버 간에 TCP 연결을 설정하십시오. RADIUS 서버의 경우 디바이스 및 RADIUS 서버 간에 UDP 연결을 설정합니다.

개요 및 토폴로지

그림 2은(는) 라우터 R1이 주니퍼 네트웍스 디바이스이며 TACACS+ 서버와 TCP 연결이 설정된 간단한 토폴로지를 보여줍니다.

그림 2: 토폴로지토폴로지

이 예에서는 사용자 정의된 두 개의 로그인 클래스로 R1을 구성합니다. 클래스 1 및 클래스 2. 각 클래스는 permissions문을 구성하고 allow-configuration, deny-configuration, allow-configuration-regexps 및 deny-configuration-regexps문을 사용해 확장된 정규 표현을 정의함으로써 사용자에 대한 액세스 권한을 정의합니다.

각 로그인 클래스의 목적은 다음과 같습니다.

  • Class1— allow-configuration 및 deny-configuration문으로 사용자에 대한 접근 권한을 정의합니다. 이 로그인 클래스는 [edit interfaces] 계층만 구성할 수 있는 액세스 권한을 제공하며 디바이스의 다른 모든 액세스는 거부합니다. 이를 위해 사용자 권한에는 구성 액세스를 제공하는 configure이(가) 포함됩니다. 또한 allow-configuration문은 인터페이스 구성에 대한 액세스를 허용하고, deny-configuration문은 다른 모든 구성 계층에 대한 액세스를 거부합니다. 허용문은 거부문보다 우선하므로 Class1 로그인 클래스에 할당된 사용자는 [edit interfaces] 계층 수준에만 액세스할 수 있습니다.

  • Class2— allow-configuration-regexps 및 deny-configuration-regexps문으로 사용자에 대한 접근 권한을 정의합니다. 이 로그인 클래스는 슈퍼 사용자 수준의 사용자 권한을 제공하며 인터페이스에 대해 여러 계층 수준에서 구성을 명시적으로 허용합니다. 또한 [edit system] 및 [edit protocols] 계층 수준에 대한 액세스를 거부합니다.

라우터 R1에는 Class1과 Class2 로그인 클래스에 각각 할당된 User1과 User2라는 두 명의 사용자가 있습니다.

구성

CLI 빠른 구성

이 예를 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일로 붙여 넣은 다음 모든 라인브레이크를 제거하고, 네트워크 구성을 일치하는 데 필요한 세부 사항을 바꾸고 [edit]계층 수준에서 명령을 CLI로 복사해 붙여 넣은 다음, 구성 모드에서 commit을(를) 입력합니다.

R1

라우터 R1에 대한 인증 매개 변수 구성

단계별 절차

라우터 R1 인증 구성을 위해 다음을 수행합니다.

  1. R1 사용자 인증을 시도하는 순서를 구성합니다. 이 예에서는 먼저 TACACS+ 서버 인증을 사용한 다음 RADIUS 서버 인증을, 그리고 그다음으로 로컬 암호를 사용합니다.

  2. TACACS+ 서버를 구성합니다.

  3. RADIUS 서버를 구성합니다.

  4. R1 계정 매개 변수를 구성합니다.

allow-configuration 및 deny-configuration문(Class1)을 사용하여 액세스 권한 구성

단계별 절차

allow-configuration 및 deny-configuration문을 사용하여 정규 표현식을 지정하려면,

  1. Class1 로그인 클래스를 configure 권한으로 구성합니다.

  2. 클래스의 사용자가 [edit interfaces] 계층 수준의 일부를 보고 수정할 수 있도록 allow-configuration 정규식을 구성합니다.

  3. 모든 구성 계층에 대한 액세스를 거부하도록 deny-configuration 정규식을 구성합니다.

  4. Class1 로그인 클래스에 대한 사용자 계정을 구성합니다.

allow-configuration-regexps 및 deny-configuration-regexps문(클래스 2)을 사용하여 액세스 권한 구성

단계별 절차

allow-configuration-regexps 및 deny-configuration-regexps문을 사용하여 정규 표현식을 지정하려면,

  1. Class2 로그인 클래스를 구성하고 슈퍼 사용자(모든) 권한을 할당합니다.

  2. 클래스의 사용자가 [edit interfaces] 계층 수준에서 여러 계층에 액세스할 수 있도록 allow-configuration-regexps 정규식을 구성합니다.

  3. deny-configuration-regexps 정규 표현식을 구성하여 클래스의 사용자가 [edit system] 및 [edit protocols] 계층 수준에서 구성을 보거나 수정할 수 없도록 합니다.

  4. Class2 로그인 클래스에 대한 사용자 계정을 구성합니다.

결과

구성 모드에서 show system 명령을 입력하여 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.

검증

새로운 로그인 클래스에 할당된 사용자 이름으로 로그인하고 구성이 제대로 작동하는지 확인합니다.

Class1 구성 확인

목적

Class1 로그인 클래스에 허용된 사용 권한이 작동하는지 확인합니다.

작업

운영 모드에서 사용 가능한 명령을 확인합니다.

구성 모드에서 사용 가능한 구성 사용 권한을 확인합니다.

의미

User1은 첫 번째 출력에서 보듯이 configure 사용자 권한을 가지고 있습니다. 또한 구성 모드에서 User1은 interfaces 계층 수준에 액세스할 수 있지만, 두 번째 출력에서 볼 수 있듯이 해당 계층 수준에만 액세스할 수 있습니다.

Class2 구성 확인

목적

Class2 구성이 예상대로 작동하는지 확인합니다.

작업

구성 모드에서 interfaces 구성에 접근합니다.

구성 모드에서 system 및 protocols 구성 계층 구조에 접근합니다.

의미

사용자2는 R1에서 인터페이스를 구성할 수 있는 권한이 있지만 [edit system] 또는 [edit protocols] 계층 수준을 보거나 수정할 수 있는 권한이 없습니다.

변경 내역 표

기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. Feature Explorer 를 사용하여 플랫폼에서 기능이 지원되는지 확인하세요.

릴리스
설명
18.1
Junos OS 릴리스 18.1부터 TACACS+ 인증에 대해 allow-commands-regexps 및 deny-commands-regexps 명령문이 지원됩니다.