4.3. 역할 기반 액세스 제어

사용자와 그룹을 역할에 매핑하는 구성은 role-mapping 요소로 /core-service=management/access=authorization 에 있습니다.

SuperUser 또는 관리자 역할의 사용자만 이 구성을 수행할 수 있습니다.

/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
{
    "outcome" => "success",
    "result" => [
        "Administrator",
        "Deployer",
        "Maintainer",
        "Monitor",
        "Operator",
        "SuperUser"
    ]
}

지정된 역할 매핑의 read-resource 작업을 사용하여 특정 역할의 전체 세부 정보를 가져옵니다.

/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "include-all" => false,
        "exclude" => undefined,
        "include" => {
            "user-theboss" => {
                "name" => "theboss",
                "realm" => undefined,
                "type" => "USER"
            },
            "user-harold" => {
                "name" => "harold",
                "realm" => undefined,
                "type" => "USER"
            },
            "group-SysOps" => {
                "name" => "SysOps",
                "realm" => undefined,
                "type" => "GROUP"
            }
        }
    }
}

add 작업을 사용하여 새 역할 구성을 추가합니다.

/core-service=management/access=authorization/role-mapping=ROLENAME:add

/core-service=management/access=authorization/role-mapping=Auditor:add

역할에 대한 구성이 없는 경우 먼저 역할 매핑 항목을 수행해야 합니다.

추가 작업을 사용하여 역할 포함 목록에 사용자 항목을 추가합니다.

/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)

/core-service=management/access=authorization/role-mapping=Auditor/include=user-max:add(name=max, type=USER)

역할에 대한 구성이 없는 경우 먼저 역할 매핑 항목을 수행해야 합니다.

add 작업을 사용하여 역할의 excludes 목록에 사용자 항목을 추가합니다.

/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)

/core-service=management/access=authorization/role-mapping=Auditor/exclude=user-max:add(name=max, type=USER)

remove 작업을 사용하여 항목을 제거합니다.

/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove

/core-service=management/access=authorization/role-mapping=Auditor/include=user-max:remove

remove 작업을 사용하여 항목을 제거합니다.

/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove

/core-service=management/access=authorization/role-mapping=Auditor/exclude=user-max:remove

/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:add

/core-service=management/access=authorization/server-group-scoped-role=NEW-SCOPED-ROLE:add(base-role=BASE-ROLE, server-groups=[SERVER-GROUP-NAME])

NEW-SCOPED-ROLE, BASE-ROLE, SERVER-GROUP-NAME 을 적절한 정보로 교체합니다.

/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:read-resource(recursive=true)

NEW-SCOPED-ROLE을 적절한 정보로 교체합니다.

범위가 지정된 역할의 세부 정보를 편집하려면 write-attribute 명령을 사용할 수 있습니다. 예를 들면 다음과 같습니다.

/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:write-attribute(name=include-all, value=true)

NEW-SCOPED-ROLE을 적절한 정보로 교체합니다.

/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:remove

/core-service=management/access=authorization/server-group-scoped-role=NEW-SCOPED-ROLE:remove

NEW-SCOPED-ROLE을 적절한 정보로 교체합니다.

관리 콘솔의 범위가 지정된 역할 구성은 다음 단계를 통해 확인할 수 있습니다.

다음 절차에서는 범위가 지정된 역할에 대한 구성 작업을 수행하는 방법을 보여줍니다.

각 민감한 리소스 제약 조건은 중요한 리소스 집합을 정의합니다. 중요한 리소스는 일반적으로 암호와 같이 시크릿이어야 하거나 네트워킹, JVM 구성 또는 시스템 속성과 같이 서버에 심각한 영향을 미치는 리소스입니다. 액세스 제어 시스템 자체도 민감한 것으로 간주됩니다. 리소스 민감도는 특정 리소스를 읽고, 쓰거나, 처리할 수 있는 역할을 제한합니다.

민감도 제약 조건 구성은 at /core-service=management/access=authorization/constraint=sensitivity-classification 에 있습니다.

관리 모델 내에서 각 민감성 제약 조건은 분류로 식별됩니다. 그런 다음 분류는 유형으로 그룹화됩니다. 13 가지 유형으로 정렬되는 39 개의 분류가 있습니다.

민감도 제약 조건을 구성하려면 write-attribute 작업을 사용하여 configured-requires-read,configured-requires-write 또는 configured-requires-addressable 특성을 설정합니다. 이러한 유형의 작업을 민감하게 설정하려면 특성 값을 true 로 설정합니다. 그렇지 않으면 민감하지 않게 설정하려면 false 로 설정합니다. 기본적으로 이러한 속성은 설정되지 않으며 default-requires-read,default-requires-write, default-requires-addressable 의 값이 사용됩니다. 구성된 속성이 설정되면 기본값 대신 사용되는 값이 됩니다. 기본값은 변경할 수 없습니다.

/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property:write-attribute(name=configured-requires-read,value=true)

/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property:read-resource

{
    "outcome" => "success",
    "result" => {
        "configured-requires-addressable" => undefined,
        "configured-requires-read" => true,
        "configured-requires-write" => undefined,
        "default-requires-addressable" => false,
        "default-requires-read" => false,
        "default-requires-write" => true,
        "applies-to" => {
            "/core-service=platform-mbean/type=runtime" => undefined,
            "/system-property=*" => undefined,
            "/" => undefined
        }
    }
}

이러한 속성의 구성에 따라 다음 표에 요약된 작업을 수행할 수 있는 역할은 다음과 같습니다.

각 애플리케이션 리소스 제약 조건은 일반적으로 애플리케이션 및 서비스 배포와 관련된 리소스, 속성 및 작업 집합을 정의합니다. 애플리케이션 리소스 제약 조건이 활성화된 경우 배포자 역할의 관리 사용자에게 적용되는 리소스에 대한 액세스 권한이 부여됩니다.

애플리케이션 제약 조건 구성은 /core-service=management/access=authorization/constraint=application-classification/ 에 있습니다.

각 애플리케이션 리소스 제약 조건은 분류로 식별됩니다. 그런 다음 분류는 유형으로 그룹화됩니다. 8 가지 유형으로 정렬되는 14 개의 분류가 있습니다. 각 분류에는 분류 구성이 적용되는 리소스 경로 패턴 목록인 applies-to 요소가 있습니다.

기본적으로 활성화된 유일한 애플리케이션 리소스 분류는 core입니다. 코어에는 배포, 배포 오버레이 및 배포 작업이 포함됩니다.

애플리케이션 리소스를 활성화하려면 write-attribute 작업을 사용하여 분류의 configured-application 특성을 true 로 설정합니다. 애플리케이션 리소스를 비활성화하려면 이 속성을 false 로 설정합니다. 기본적으로 이러한 속성은 설정되지 않으며 default-application 속성 값이 사용됩니다. 기본값은 변경할 수 없습니다.

/core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile:write-attribute(name=configured-application,value=true)

/core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile:read-resource

{
    "outcome" => "success",
    "result" => {
        "configured-application" => true,
        "default-application" => false,
        "applies-to" => {"/subsystem=logging/logging-profile=*" => undefined}
    }
}

기본적으로 vault 표현식을 읽고 쓰는 것은 민감한 작업입니다. Vault 표현식 제약 조건을 구성하면 해당 작업 중 하나 또는 둘 다 중요하지 않은 것으로 설정할 수 있습니다. 이 제약 조건을 변경하면 역할 수가 많을수록 vault 표현식을 읽고 쓸 수 있습니다.

vault 표현식 제약 조건은 at /core-service=management/access=authorization/constraint=vault-expression 에 있습니다.

vault 표현식 제약 조건을 구성하려면 write-attribute 작업을 사용하여 configured-requires-write 및 configured-requires-read 의 속성을 true 또는 false 로 설정합니다. 기본적으로 이 값은 설정되지 않으며 default-requires-read 및 default-requires-write 값이 사용됩니다. 기본값은 변경할 수 없습니다.

/core-service=management/access=authorization/constraint=vault-expression:write-attribute(name=configured-requires-write,value=false)

/core-service=management/access=authorization/constraint=vault-expression:read-resource

{
    "outcome" => "success",
    "result" => {
        "configured-requires-read" => undefined,
        "configured-requires-write" => false,
        "default-requires-read" => true,
        "default-requires-write" => true
    }
}

이 구성에 따라 vault 표현식을 읽고 쓸 수 있는 역할은 다음 표에 요약되어 있습니다.