서버 보안 설정 방법

Red Hat JBoss Enterprise Application Platform 7.4

Red Hat JBoss Enterprise Application Platform 및 해당 관리 인터페이스의 보안을 위한 지침.

Red Hat Customer Content Services

초록

이 문서의 목적은 Red Hat JBoss EAP(JBoss Enterprise Application Platform) 보안을 위한 실용적인 가이드를 제공하는 것입니다. 구체적으로는 이 가이드에서 JBoss EAP의 모든 관리 인터페이스를 보호하는 방법을 자세히 설명합니다. 이 가이드를 읽기 전에 사용자는 Red Hat JBoss Enterprise Application Platform의 보안 아키텍처 문서를 읽고 JBoss EAP가 보안을 처리하는 방법을 잘 알고 있어야 합니다. 이 문서에서는 구성 변경을 수행하기 위해 JBoss EAP CLI 인터페이스를 사용합니다. 이 문서를 작성할 때 독자는 JBoss EAP 보안 방법에 대한 확실한 이해가 있어야 합니다.

JBoss EAP 문서에 대한 피드백 제공

오류를 보고하거나 문서를 개선하기 위해 Red Hat Jira 계정에 로그인하여 문제를 제출하십시오. Red Hat Jira 계정이 없는 경우 계정을 생성하라는 메시지가 표시됩니다.

절차

  1. 티켓을 생성하려면 다음 링크를 클릭하십시오.
  2. 문서 URL, 섹션 번호 를 포함하고 문제를 설명하십시오.
  3. 요약 에 문제에 대한 간략한 설명을 입력합니다.
  4. 설명에서 문제 또는 개선 사항에 대한 자세한 설명을 제공합니다. 문서에서 문제가 발생한 위치에 URL을 포함합니다.
  5. Submit 을 클릭하고 문제를 적절한 문서 팀으로 라우팅합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

1장. 서버 및 인터페이스 보안

1.1. 블록 구축

1.1.1. 인터페이스 및 소켓 바인딩

JBoss EAP는 호스트의 인터페이스(예: inet-addressnic )는 물론 웹 애플리케이션 및 관리 인터페이스 모두에 대한 통신용 포트를 활용합니다. 이러한 인터페이스 및 포트는 JBoss EAP의 인터페이스와 socket-binding-groups 설정을 통해 정의 및 구성됩니다.

인터페이스socket-binding-groups 를 정의하고 구성하는 방법에 대한 자세한 내용은 JBoss EAP 구성 가이드의 소켓 바인딩 섹션을 참조하십시오.

예제: 인터페이스

<interfaces>
  <interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
  </interface>
  <interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
  </interface>
</interfaces>

예제: 소켓 바인딩 그룹

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
    <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <outbound-socket-binding name="mail-smtp">
        <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
</socket-binding-group>

1.1.2. Elytron 하위 시스템

1.1.2.1. 서버 전체에 Elytron 보안 활성화

서버 전반에서 Elytron을 활성화하는 간단한 방법이 있습니다. JBoss EAP 7.1은 보안 프로바이더로 Elytron을 활성화하는 구성 스크립트 예제를 도입했습니다. 이 스크립트는 서버 설치의 EAP_HOME/docs/examples 디렉터리에 상주합니다.

다음 명령을 실행하여 서버에서 Elytron 보안을 활성화합니다.

$ EAP_HOME/bin/jboss-cli.sh --file=EAP_HOME/docs/examples/enable-elytron.cli

1.1.2.2. Elytron 보안 도메인 만들기

elytron 하위 시스템의 보안 도메인은(보안 영역과 함께 사용할 경우) 핵심 관리 인증은 물론 애플리케이션과의 인증에 모두 사용됩니다.

중요

배포는 배포당 하나의 Elytron 보안 도메인 사용으로 제한됩니다. 여러 레거시 보안 도메인이 필요한 시나리오는 이제 하나의 Elytron 보안 도메인을 사용하여 수행할 수 있습니다.

관리 CLI를 사용하여 보안 도메인 추가
/subsystem=elytron/security-domain=domainName:add(realms=[{realm=realmName,role-decoder=roleDecoderName}],default-realm=realmName,permission-mapper=permissionMapperName,role-mapper=roleMapperName,...)
관리 콘솔을 사용하여 보안 도메인 추가
  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
  2. ConfigurationSubsystemsSecurity (Elytron)기타 설정으로 이동하여 보기를 클릭합니다.
  3. SSL보안 도메인을 선택하고 추가 버튼을 사용하여 새 보안 도메인을 구성합니다.

1.1.2.3. Elytron Security Realm 만들기

elytron 하위 시스템의 보안 영역은(보안 도메인과 함께 사용할 경우) 핵심 관리 인증은 물론 애플리케이션과의 인증에 모두 사용됩니다. 또한 보안 영역은 해당 ID 저장소, example jdbc-realm,filesystem-realm,properties-realm 등에 따라 구체적으로 입력됩니다.

관리 CLI를 사용하여 보안 영역 추가
/subsystem=elytron/type-of-realm=realmName:add(....)

jdbc-realm,filesystem-realmproperties-realm 과 같은 특정 영역을 추가하는 예제는 이전 섹션에서 확인할 수 있습니다.

관리 콘솔을 사용하여 보안 영역 추가
  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
  2. 구성하위 시스템보안(Elytron)보안 영역으로 이동하여 보기를 클릭합니다.
  3. Security Realm (보안 영역) 탭에서 적절한 보안 영역 유형을 선택하고 Add(추가 )를 클릭하여 새 보안 영역을 구성합니다.

1.1.2.4. Elytron 역할 표시기 만들기

역할 디코더는 보안 영역에서 제공하는 ID에서 역할로 속성을 변환합니다. 역할 디코더는 기능에 따라 구체적으로 입력됩니다(예: empty-role-decoder,simple-role-decoder, custom-role-decoder ).

관리 CLI를 사용하여 역할 전달자 추가
/subsystem=elytron/ROLE-DECODER-TYPE=roleDeoderName:add(....)
관리 콘솔을 사용하여 역할 검색기 추가
  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
  2. ConfigurationSubsystemsSecurity (Elytron)Mappers / redhatders로 이동하여 보기를 클릭합니다.
  3. Role satellite(역할)를 클릭하고 적절한 역할 디코더 유형을 선택하고 Add(추가 )를 클릭하여 새 역할 디코더를 구성합니다.

1.1.2.5. elytron 하위 시스템에 source-address-role-decoder 추가

관리 CLI 또는 관리 콘솔을 사용하여 source-address-role-decoder 역할 디코더를 elytron 하위 시스템에 추가할 수 있습니다. 매퍼 요소에서 이 역할 디코더를 구성하면 권한 결정을 내릴 때 클라이언트의 IP 주소를 사용합니다.

source-address-role-decoder 는 클라이언트의 IP 주소를 추출하고 pattern 특성 또는 source-address 특성에 지정된 IP 주소와 일치하는지 확인합니다. 클라이언트의 IP 주소가 특성에 지정된 IP 주소와 일치하는 경우 elytronroles 속성을 사용하여 사용자에게 역할을 할당합니다.

참고

이 절차에서는 관리 CLI를 사용하여 elytron 하위 시스템의 mappers 요소에 source-address-role-decoder 를 추가합니다. 관리 콘솔을 사용하여 이 작업을 완료하려면 추가 리소스 섹션에 제공된 링크를 참조하십시오.

사전 요구 사항

  • 서버의 클라이언트의 IP 주소를 확인합니다.

절차

  1. elytron 하위 시스템에서 관리 CLI를 사용하여 source-address-role-decoder 를 추가합니다. source-address-role-decoder 의 경우 사용자의 IP 주소와 하나 이상의 역할을 지정해야 합니다.

    mappers 요소에 source-address-role-decoder추가하는 예:

    /subsystem=elytron/source-address-role-decoder=decoder1:add(source-address="10.10.10.10", roles=["Administrator"])

    이 예제에서는 decoder1 이라는 구성된 source-address-role-decoder 를 보여줍니다. 클라이언트가 서버에 연결을 시도하면 elytron 하위 시스템은 source-address-role-decoder 를 사용하여 클라이언트의 IP 주소가 패턴 특성 또는 source-address 특성에 지정된 IP 주소와 일치하는지 확인합니다. 이전 예에서 source-address-role-decoder 는 클라이언트의 IP 주소가 10.10.10.10인지 확인합니다. 클라이언트의 IP 주소가 10.10.10.10 이면 elytronroles 속성을 사용하여 사용자에게 Administrator 역할을 할당합니다.

    참고

    다른 네트워크에서 연결을 설정해야 하는 사용자에게 특정 역할을 할당하도록 source-address-role-decoder 를 구성할 수 있습니다.

  2. security-domain 에서 role- decoder 특성에서 구성된 source-address-role -decoder 를 참조합니다. 이렇게 하면 Elytron 보안 도메인에서 권한 결정을 내릴 때 source-address-role-decoder 를 사용할 수 있습니다.

    role-decoder 특성 에서 구성된 source-address-role-decoder,decoder1 을 참조하는 예제입니다.

    /subsystem=elytron/security-domain=domainName:add(role-decoder=decoder1,default-realm=realmName,realms=[{realm=realmName}])

추가 리소스

  • 관리 콘솔을 사용하여 역할 디코더를 추가하는 방법에 대한 자세한 내용은 Elytron Subsystem 을 참조하십시오.
  • elytron 하위 시스템에 대한 자세한 내용은 보안 아키텍처 가이드의 Elytron Subsystem 을 참조하십시오.

1.1.3. elytron 하위 시스템에 aggregate-role-decoder 구성

aggregate-role-decoder 는 두 개 이상의 역할 디코더로 구성됩니다. aggregate-role-decoder 를 사용하여 각 역할 디코더에서 반환된 역할을 집계할 수 있습니다.

사전 요구 사항

  • elytron 하위 시스템에서 2개 이상의 역할 디코더를 구성합니다.

절차

  • aggregate-role-decoder 역할 디코더에 2개 이상의 역할 디코더를 추가합니다.

    aggregate-role-decoder 역할 디코더에 decoder 1 및 decoder2 를 추가하는 예:

    /subsystem=elytron/aggregate-role-decoder=aggregateDecoder:add(role-decoders=[decoder1, decoder2])

추가 리소스

1.1.3.1. Elytron 역할 매퍼 만들기

역할 매퍼는 다른 역할로 디코딩된 후 역할을 매핑합니다. 예를 들어 역할 이름을 정규화하거나 주체가 디코딩된 후 주체에서 특정 역할을 추가 및 제거하는 작업이 있습니다. 역할 매퍼는 기능에 따라 구체적으로 입력됩니다(예: add-prefix-role-mapper,add-suffix-role-mapper, constant-role-mapper ).

역할 매퍼를 추가하면 일반 양식이 사용됩니다.
/subsystem=elytron/ROLE-MAPPER-TYPE=roleMapperName:add(...)
관리 콘솔을 사용하여 역할 매퍼 추가
  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
  2. ConfigurationSubsystemsSecurity (Elytron)Mappers / redhatders로 이동하여 보기를 클릭합니다.
  3. Role Mapper (역할 매퍼)를 클릭하고 적절한 역할 매퍼 유형을 선택하고 Add(추가 )를 클릭하여 새 역할 매퍼를 구성합니다.

1.1.3.2. Elytron 권한 세트 만들기

권한 세트를 사용하여 ID에 권한을 할당할 수 있습니다.

관리 CLI를 사용하여 권한 세트 추가
/subsystem=elytron/permission-set=PermissionSetName:add(permissions=[{class-name="...", module="...", target-name="...", action="..."}...])

permissions 매개변수는 각 권한에 다음 속성이 있는 권한 집합으로 구성됩니다.

  • class-name 은 권한의 정규화된 클래스 이름입니다. 이는 필요한 유일한 권한 속성입니다.
  • 모듈은 권한을 로드하는 데 사용되는 선택적 모듈입니다.
  • target-name 은 구성 시 권한에 전달되는 선택적 대상 이름입니다.
  • action 은 구성 시 권한에 전달되는 선택적 작업입니다.

1.1.3.3. Elytron 권한 맵퍼 만들기

ID에 할당되는 역할 외에도 권한을 할당할 수도 있습니다. 권한 매퍼는 ID에 권한을 할당합니다. 권한 매퍼도 특히 해당 기능에 따라 입력됩니다(예: logical-permission-mapper,simple-permission-mapper, custom-permission-mapper ).

관리 CLI를 사용하여 권한 매퍼 추가
/subsystem=elytron/simple-permission-mapper=PermissionMapperName:add(...)
관리 콘솔을 사용하여 권한 매퍼 추가
  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
  2. ConfigurationSubsystemsSecurity (Elytron)Mappers / redhatders로 이동하여 보기를 클릭합니다.
  3. Principalkonder를 클릭하고 적절한 주체 디코더 유형을 선택하고 Add(추가 )를 클릭하여 새 주체 디코더를 구성합니다.

1.1.3.4. 인증 구성 생성

인증 구성에는 연결을 만들 때 사용할 자격 증명이 포함되어 있습니다. 인증 구성에 대한 자세한 내용은 JBoss EAP용 ID 관리 구성 방법에서 Elytron 클라이언트를 사용하여 클라이언트 인증 구성을 참조하십시오.

참고

자격 증명 저장소 대신 액세스 사용자의 자격 증명을 사용하도록 Elytron 보안 도메인을 구성할 수 있습니다. 예를 들어 보안 도메인을 Kerberos와 함께 사용하여 들어오는 사용자를 인증할 수 있습니다. JBoss EAP용 Kerberos로 SSO를 설정하는 방법에서 Elytron 하위 시스템 구성의 지침을 따르고 Kerberos 보안 팩토리에서 obtain-kerberos-ticket=true 를 설정합니다.

관리 CLI를 사용하여 인증 구성 추가
/subsystem=elytron/authentication-configuration=AUTHENTICATION_CONFIGURATION_NAME:add(authentication-name=AUTHENTICATION_NAME, credential-reference={clear-text=PASSWORD})
관리 콘솔을 사용하여 인증 구성 추가
  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
  2. ConfigurationSubsystemsSecurity (Elytron)기타 설정으로 이동하여 보기를 클릭합니다.
  3. 인증 → 인증 구성을 클릭하고 Add (추가 )를 클릭하여 새 인증 구성을 구성합니다.

인증-구성 속성의 전체 목록은 Elytron 하위 시스템 구성 요소 참조를 참조하십시오.

1.1.3.5. 인증 컨텍스트 생성

인증 컨텍스트에는 연결 설정에 사용할 일련의 규칙과 인증 구성 또는 SSL 컨텍스트 가 포함되어 있습니다. 인증 컨텍스트에 대한 자세한 내용은 JBoss EAP용 ID 관리 구성 방법에서 Elytron 클라이언트를 사용하여 클라이언트 인증 구성을 참조하십시오.

관리 CLI를 사용하여 인증 컨텍스트 추가

인증 컨텍스트는 다음 관리 CLI 명령을 사용하여 생성할 수 있습니다.

/subsystem=elytron/authentication-context=AUTHENTICATION_CONTEXT_NAME:add()

일반적으로 인증 컨텍스트에는 규칙 집합과 인증 구성 또는 SSL 컨텍스트가 포함됩니다. 다음 CLI 명령은 호스트 이름이 localhost 인 경우에만 작동하는 인증 컨텍스트 정의 방법을 제공합니다.

/subsystem=elytron/authentication-context=AUTHENTICATION_CONTEXT_NAME:add(match-rules=[{authentication-configuration=AUTHENTICATION_CONFIGURATION_NAME, match-host=localhost}])
관리 콘솔을 사용하여 인증 컨텍스트 추가
  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
  2. ConfigurationSubsystemsSecurity (Elytron)기타 설정으로 이동하여 보기를 클릭합니다.
  3. Authentication → Authentication Context 를 클릭하고 Add 를 클릭하여 새 인증 컨텍스트를 구성합니다.

authentication-context 속성의 전체 목록은 Elytron 하위 시스템 구성 요소 참조를 참조하십시오.

1.1.3.6. Elytron 인증 팩토리 만들기

인증 팩토리는 특정 인증 메커니즘에 사용되는 인증 정책입니다. 인증 팩토리는 특히 http-authentication-factory,sasl-authentication-factorykerberos-security-factory 와 같은 인증 메커니즘을 기반으로 합니다.

관리 CLI를 사용하여 인증 팩토리 추가
/subsystem=elytron/AUTH-FACTORY-TYPE=authFactoryName:add(....)
관리 콘솔을 사용하여 인증 팩토리 추가
  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
  2. ConfigurationSubsystemsSecurity (Elytron)Factories / Transformers 로 이동하여 보기를 클릭합니다.
  3. HTTP 팩토리,SASL 팩토리 또는 기타 팩토리를 클릭하고 적절한 팩토리 유형을 선택하고 Add(추가 )를 클릭하여 새 팩토리를 구성합니다.

1.1.3.7. Elytron 키 저장소 만들기

키 저장소 는 키 저장소 유형, 해당 위치 및 액세스하기 위한 자격 증명을 비롯한 키 저장소 또는 신뢰 저장소의 정의입니다.

elytron 하위 시스템에서 사용할 예제 키 저장소를 생성하려면 다음 명령을 사용합니다.

$ keytool -genkeypair -alias localhost -keyalg RSA -keysize 1024 -validity 365 -keystore keystore.jks -dname "CN=localhost" -keypass secret -storepass secret
관리 CLI를 사용하여 키 저장소 추가

새로 만든 키 저장소를 참조하는 Elytron의 키 저장소를 정의하려면 다음 관리 CLI 명령을 실행합니다. 이 명령은 제공된 파일 시스템 경로, 키 저장소 액세스에 사용되는 자격 증명 참조 및 키 저장소 유형을 기준으로 키 저장소에 대한 경로를 차단합니다.

/subsystem=elytron/key-store=newKeyStore:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
참고

위의 명령은 키 저장소 파일의 위치를 참조하기 위해 상대-to 를 사용합니다. 또는 경로에서 키 저장소의 전체 경로를 지정하고 relative-to 생략할 수도 있습니다.

관리 콘솔을 사용하여 키 저장소 추가
  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
  2. ConfigurationSubsystemsSecurity (Elytron)기타 설정으로 이동하여 보기를 클릭합니다.
  3. 저장소키 저장소 를 클릭하고 추가를 클릭하여 새 키 저장소를 구성합니다.

1.1.3.8. Elytron 키 관리자 만들기

key-manager키 저장소를 참조하며 SSL 컨텍스트와 함께 사용됩니다.

관리 CLI를 사용하여 키 관리자 추가

다음 명령은 참조할 기본 키 저장소, 키 관리자를 초기화할 때 사용할 알고리즘 및 기본 키 저장소의 항목에 액세스하기 위한 자격 증명 참조를 지정합니다.

/subsystem=elytron/key-manager=newKeyManager:add(key-store=KEY_STORE,credential-reference={clear-text=secret})
중요

Elytron 하위 시스템에서 KeyManagerfactory.getDefaultAlgorithm() 를 사용하여 기본적으로 알고리즘을 결정하므로 이전 명령에서 algorithm을 지정하지 않았습니다. 그러나 알고리즘 특성을 지정할 수 있습니다. 알고리즘 특성을 지정하려면 JDK에서 제공하는 키 관리자 알고리즘이 무엇인지 알아야 합니다. 예를 들어 SunJSSE를 사용하는 JDK는 PKIXSunX509 알고리즘을 제공합니다.

이전 명령에서 SunX509 를 키 관리자 알고리즘 특성으로 지정할 수 있습니다.

관리 콘솔을 사용하여 키 관리자 추가
  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
  2. ConfigurationSubsystemsSecurity (Elytron)기타 설정으로 이동하여 보기를 클릭합니다.
  3. SSLKey Manager 를 클릭하고 Add(추가 )를 클릭하여 새 키 관리자를 구성합니다.

1.1.3.9. Elytron Truststore 생성

Elytron에서 신뢰 저장소를 생성하려면 다음 CLI 명령을 실행합니다.

/subsystem=elytron/key-store=default-trust-store:add(type=JKS, relative-to=jboss.server.config.dir, path=application.truststore, credential-reference={clear-text=password})

위의 명령을 성공적으로 실행하려면 EAP_HOME/standalone/configuration 디렉터리에 application.truststore 파일이 있어야 합니다. 엔드 포인트의 인증서에 CA가 서명한 경우 트러스트 저장소에는 끝점 또는 인증서 체인과 연결된 인증서가 포함되어야 합니다.

자체 서명된 인증서를 사용하지 않도록 권장합니다. 인증서는 CA에서 서명하고 신뢰 저장소에는 ROOT 및 중간 CA를 나타내는 인증서 체인이 포함되어야 합니다.

1.1.3.10. Elytron Trust Manager 만들기

Elytron에서 신뢰 관리자를 정의하려면 다음 CLI 명령을 실행합니다.

/subsystem=elytron/trust-manager=default-trust-manager:add(key-store=TRUST-STORE-NAME)

이렇게 하면 정의된 신뢰 저장소를 애플리케이션 서버에서 신뢰하는 인증서의 소스로 설정합니다.

1.1.3.11. Box Elytron 구성 요소 외부 사용

JBoss EAP는 elytron 하위 시스템에서 구성된 기본 Elytron 구성 요소 집합을 제공합니다. 사전 구성된 구성 요소에 대한 자세한 내용은 보안 아키텍처 가이드 의 박스 아웃 섹션에서 확인할 수 있습니다.

1.1.3.11.1. 관리 인터페이스 보안

JBoss EAP가 Elytron으로 사용자 인증 섹션의 관리 인터페이스를 보호하기 위해 기본적으로 Elytron 구성 요소를 사용하도록 활성화하는 방법에 대한 자세한 내용을 확인할 수 있습니다.

1.1.3.11.2. 애플리케이션 보안

elytron 하위 시스템은 기본적으로 http -authentication-factory에 대한 application-http -authentication을 제공하며, 이는 애플리케이션을 보호하는 데 사용할 수 있습니다. application-http-authentication 구성 방법에 대한 자세한 내용은 보안 아키텍처 가이드 의 박스 아웃 섹션을 참조하십시오.

application-http-authentication 을 사용하도록 애플리케이션을 구성하려면 How to Configure Identity Management Guide 에서 Elytron 또는 Legacy Security for Authentication을 사용하도록 웹 애플리케이션 구성을 참조하십시오. ID 관리 가이드의 애플리케이션 인증 구성 섹션 재정의 섹션에 있는 단계를 사용하여 모든 애플리케이션의 기본 동작을 재정의할 수도 있습니다.

1.1.3.11.3. SSL/TLS 사용

JBoss EAP는 레거시 코어 관리 인증을 사용하여 기본 단방향 SSL/TLS 구성을 제공하지만, elytron 하위 시스템에서는 제공하지 않습니다. 다음 섹션의 애플리케이션뿐만 아니라 관리 인터페이스 모두에서 elytron 하위 시스템을 사용하여 SSL/TLS를 구성하는 방법에 대한 자세한 내용을 확인할 수 있습니다.

1.1.3.11.4. 다른 하위 시스템과 함께 Elytron 사용

애플리케이션 및 관리 인터페이스 보안 외에도 Elytron은 JBoss EAP의 다른 하위 시스템과도 통합됩니다.

batch-jberet
Elytron 보안 도메인을 사용하여 배치 작업을 실행하도록 batch-jberet 하위 시스템을 구성할 수 있습니다. 자세한 내용은 Configuration Guide의 Configure Security for Batch Jobs 를 참조하십시오.
datasources
자격 증명 저장소 또는 Elytron 보안 도메인을 사용하여 데이터 소스 정의에 인증 정보를 제공할 수 있습니다. 자세한 내용은 구성 가이드 의 데이터 소스 보안을 참조하십시오.
ejb3
배포에서 참조할 ejb3 하위 시스템에서 Elytron 보안 도메인에 대한 매핑을 생성할 수 있습니다. 자세한 내용은 자카르타 엔터프라이즈 빈 애플리케이션 개발에서 Elytron Integration with the EJB Subsystem 을 참조하십시오.
iiop-openjdk
elytron 하위 시스템을 사용하여 iiop-openjdk 하위 시스템을 사용하여 클라이언트와 서버 간에 SSL/TLS를 구성할 수 있습니다. 자세한 내용은 구성 가이드의 SSL/TLS와 함께 SSL/TLS를 사용하도록 구성 IIOP 를 참조하십시오.
jca
elytron-enabled 특성을 사용하여 작업 관리자의 Elytron 보안을 활성화할 수 있습니다. 자세한 내용은 구성 가이드에서 JCA 하위 시스템 구성을 참조하십시오.
jgroups
elytron 하위 시스템에 정의된 키 저장소 또는 자격 증명 참조를 참조하도록 SY M_ENCRYPT 및 ASYM_ENCRYPT 프로토콜을 구성할 수 있습니다. 자세한 내용은 구성 가이드의 클러스터 보안을 참조하십시오.
메일
자격 증명 저장소를 사용하여 메일 하위 시스템의 서버 정의에 인증 정보를 제공할 수 있습니다. 자세한 내용은 구성 가이드에서 암호에 대한 자격 증명 저장소 사용을 참조하십시오.
messaging-activemq
messaging-activemq 하위 시스템에서 사용하는 원격 연결에 대한 원격 연결을 보호할 수 있습니다. 자세한 내용은 메시징 구성의 Elytron 하위 시스템 사용 섹션 을 참조하십시오.
modcluster
Elytron 클라이언트 ssl-context 를 사용하여 SSL/TLS를 사용하여 로드 밸런서 장치와 통신할 수 있습니다. 자세한 내용은 Elytron Integration with the ModCluster Subsystem 을 참조하십시오.
Remoting
원격 하위 시스템에서 인증 컨텍스트, SASL 인증 팩토리 및 elytron 하위 시스템에 정의된 SSL 컨텍스트를 참조하도록 인바운드 및 아웃바운드 연결을 구성할 수 있습니다. 각 연결 유형 구성에 대한 자세한 내용은 제거 하위 시스템과의 통합을 참조하십시오.
resource-adapters
Elytron을 사용하여 리소스 어댑터에 대한 연결을 보호할 수 있습니다. 보안 inflow를 활성화하여 작업 관리자가 실행할 작업을 제출할 때 보안 자격 증명을 설정할 수 있습니다. 자세한 내용은 구성 가이드에서 Elytron 하위 시스템을 사용하도록 리소스 어댑터 구성에서 참조하십시오.
Undertow
elytron 하위 시스템을 사용하여 SSL/TLS 및 애플리케이션 인증을 모두 구성할 수 있습니다. 애플리케이션 인증 구성에 대한 자세한 내용은 Using SSL/TLSConfigure Web Applications to Use Elytron or Legacy Security for Authentication in How to Configure SSL/TLS를 참조하십시오.

1.1.3.12. Elytron 하위 시스템 활성화 및 비활성화

elytron 하위 시스템은 기존 보안 하위 시스템과 함께 기본 JBoss EAP 프로필로 미리 구성됩니다.

elytron 하위 시스템이 구성되지 않은 프로필을 사용하는 경우 elytron 확장을 추가하고 elytron 하위 시스템을 활성화하여 추가할 수 있습니다.

elytron 하위 시스템에 필요한 elytron 확장을 추가하려면 다음을 수행합니다.

/extension=org.wildfly.extension.elytron:add()

JBoss EAP에서 elytron 하위 시스템을 활성화하려면 다음을 수행합니다.

/subsystem=elytron:add

reload

JBoss EAP에서 elytron 하위 시스템을 비활성화하려면 다음을 수행합니다.

/subsystem=elytron:remove

reload
중요

JBoss EAP 내의 다른 하위 시스템은 elytron 하위 시스템에 종속될 수 있습니다. 이러한 종속성을 비활성화하기 전에 해결되지 않으면 JBoss EAP를 시작할 때 오류가 표시됩니다.

1.1.4. 레거시 보안 하위 시스템

1.1.4.1. 보안 하위 시스템 비활성화

하위 시스템의 제거 작업을 실행하여 JBoss EAP에서 보안 하위 시스템을 비활성화할 수 있습니다.

절차

  • JBoss EAP에서 보안 하위 시스템을 비활성화합니다.

    /subsystem=security:remove
중요

JBoss EAP 내의 다른 하위 시스템은 보안 하위 시스템에 대한 종속성을 가질 수 있습니다. 이러한 종속성을 비활성화하기 전에 해결되지 않으면 JBoss EAP를 시작할 때 오류가 표시됩니다.

1.1.4.2. 보안 하위 시스템 활성화

하위 시스템의 추가 작업을 실행하여 JBoss EAP에서 보안 하위 시스템을 활성화할 수 있습니다.

절차

  • JBoss EAP에서 보안 하위 시스템을 활성화합니다.

    /subsystem=security:add

1.1.5. 기존 보안 영역

JBoss EAP는 보안 영역을 사용하여 관리 인터페이스에서 사용할 수 있는 로컬 LDAP 속성과 같은 인증 및 권한 부여 메커니즘을 정의합니다.

예제: 보안 영역

<security-realms>
  <security-realm name="ManagementRealm">
    <authentication>
      <local default-user="$local" skip-group-loading="true"/>
      <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
    </authentication>
    <authorization map-groups-to-roles="false">
      <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
    </authorization>
  </security-realm>
  <security-realm name="ApplicationRealm">
    <authentication>
      <local default-user="$local" allowed-users="*" skip-group-loading="true"/>
      <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
    </authentication>
    <authorization>
      <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
    </authorization>
  </security-realm>
</security-realms>

참고

JBoss EAP를 사용하면 기존 보안 영역을 업데이트하는 것 외에도 새 보안 영역을 생성할 수 있습니다. 관리 콘솔을 통해 새 보안 영역을 생성하고 관리 CLI에서 다음 명령을 호출할 수 있습니다.

/core-service=management/security-realm=<new_realm_name>:add()

새 보안 영역을 생성하고 인증 또는 권한 부여에 속성 파일을 사용하려면 특별히 새 보안 도메인에 대한 새 속성 파일을 생성해야 합니다. JBoss EAP는 다른 보안 도메인에서 사용하는 기존 파일을 재사용하지 않으며, 존재하지 않는 경우 구성에 지정된 새 파일을 자동으로 생성하지 않습니다.

추가 리소스

  • 보안 영역에 대한 자세한 내용은 Security realms를 참조하십시오.

1.1.6. 관리 인터페이스 보안을 위해 인증 및 소켓 바인딩 사용

socket-binding,http-authentication-factory, http-upgrade 를 조합하여 elytron 하위 시스템을 사용하여 관리 인터페이스를 보호할 수 있습니다. 또는 security- realm과 함께 socket- binding 을 사용하여 레거시 코어 관리 인증으로 관리 인터페이스를 보호할 수 있습니다. 관리 인터페이스를 비활성화하고 다양한 역할 및 액세스 권한을 갖도록 인터페이스의 사용자를 구성할 수도 있습니다.

기본적으로 JBoss EAP는 관리 인터페이스에 연결할 http-interface 를 정의합니다.

절차

  • 서버 관리 인터페이스 설정을 표시합니다.

    [standalone@localhost:9990 /] /core-service=management:read-resource(recursive=true)
    {
        "outcome" => "success",
        "result" => {
            "access" => {...},
            "ldap-connection" => undefined,
            "management-interface" => {"http-interface" => {
                "allowed-origins" => undefined,
                "console-enabled" => true,
                "http-authentication-factory" => "management-http-authentication",
                "http-upgrade" => {
                    "enabled" => true,
                    "sasl-authentication-factory" => "management-sasl-authentication"
                },
                "http-upgrade-enabled" => true,
                "sasl-protocol" => "remote",
                "secure-socket-binding" => undefined,
                "security-realm" => undefined,
                "server-name" => undefined,
                "socket-binding" => "management-http",
                "ssl-context" => undefined
            }},
            "security-realm" => {...},
            "service" => undefined
        }
    }

1.2. 관리 인터페이스 보안 방법

다음 섹션에서는 JBoss EAP 관리 인터페이스 및 관련 하위 시스템 보안과 관련된 다양한 작업을 수행하는 방법을 보여줍니다.

참고

표시된 관리 CLI 명령은 JBoss EAP 독립 실행형 서버를 실행 중이라고 가정합니다. JBoss EAP 관리형 도메인의 관리 CLI 사용에 대한 자세한 내용은 JBoss EAP 관리 CLI 가이드를 참조하십시오.

관리 CLI와 Elytron 통합

관리 인터페이스는 레거시 보안 영역에서 수행하는 것과 동일한 방식으로 elytron 하위 시스템의 리소스를 사용하여 보호할 수 있습니다.

연결에 대한 SSL 구성은 다음 위치 중 하나에서 제공됩니다.

  • CLI별 구성 내의 모든 SSL 구성입니다.
  • 사용자에게 서버의 인증서를 수락하도록 자동으로 프롬프트를 표시하는 기본 SSL 구성입니다.
  • java 시스템 속성.

클라이언트 구성은 the wildfly-config.xml 파일을 사용하여 수정할 수 있습니다.

참고

D wildfly.config.url 속성을 설정하면 클라이언트가 구성에 사용할 수 있습니다.

1.2.1. 네트워킹 및 포트 구성

호스트의 구성에 따라 다양한 네트워크 인터페이스 및 포트를 사용하도록 JBoss EAP를 구성할 수 있습니다. 이를 통해 JBoss EAP는 다양한 호스트, 네트워킹 및 방화벽 요구 사항에 맞게 작업할 수 있습니다.

추가 리소스

  • JBoss EAP에서 사용하는 네트워킹 및 포트 및 이러한 설정 구성 방법에 대한 자세한 내용은 JBoss EAP 구성 가이드의 네트워크 및 포트 구성 섹션을 참조하십시오.

1.2.2. 관리 콘솔 비활성화

JBoss Operations Network와 같은 기타 클라이언트는 HTTP 인터페이스를 사용하여 JBoss EAP를 관리합니다. 이러한 서비스를 계속 사용하려면 웹 기반 관리 콘솔 자체만 비활성화될 수 있습니다. 이는 console-enabled 특성을 false 로 설정하여 수행됩니다.

절차

  • JBoss EAP에서 웹 기반 관리 콘솔을 비활성화하려면 다음을 수행합니다.

    /core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)

1.2.3. RuntimeClass에 대한 원격 액세스 비활성화

jmx 하위 시스템에 대한 원격 액세스를 사용하면 JDK 및 애플리케이션 관리 작업을 원격으로 트리거할 수 있습니다.

절차

  • JBoss EAP에서 RuntimeClass에 대한 원격 액세스를 비활성화하려면 jmx 하위 시스템에서 remoting 커넥터를 제거하십시오.

    /subsystem=jmx/remoting-connector=jmx/:remove

1.2.4. 자동 인증

JBoss EAP의 기본 설치에는 로컬 관리 CLI 사용자에 대한 자동 인증 방법이 포함되어 있습니다. 이를 통해 로컬 사용자는 사용자 이름 또는 암호 인증 없이 관리 CLI에 액세스할 수 있습니다. 이 기능을 사용하여 로컬 사용자가 인증 없이 관리 CLI 스크립트를 실행할 수 있습니다. 로컬 구성에 대한 액세스 권한은 일반적으로 사용자에게 고유한 사용자 세부 정보를 추가하거나 보안 검사를 비활성화하는 기능을 제공한다는 점에서 유용한 기능으로 간주됩니다.

더 큰 보안 제어가 필요한 경우 자동 인증을 비활성화할 수 있습니다. 이 작업은 구성 파일의 security-realm 특성 내에서 로컬 요소를 제거하여 수행할 수 있습니다. 이는 관리형 도메인뿐만 아니라 두 독립 실행형 인스턴스 모두에 적용할 수 있습니다.

중요

로컬 요소를 제거하려면 JBoss EAP 인스턴스에 미치는 영향과 해당 구성이 완전히 파악된 경우에만 수행해야 합니다.

절차

  1. elytron 하위 시스템을 사용할 때 자동 인증을 제거하려면 다음을 수행합니다.

    [standalone@localhost:9990 /] /subsystem=elytron/sasl-authentication-factory=managenet-sasl-authentication:read-resource
    {
        "outcome" => "success",
        "result" => {
            "mechanism-configurations" => [
                {
                    "mechanism-name" => "JBOSS-LOCAL-USER",
                    "realm-mapper" => "local"
                },
                {
                    "mechanism-name" => "DIGEST-MD5",
                    "mechanism-realm-configurations" => [{"realm-name" => "ManagementRealm"}]
                }
            ],
            "sasl-server-factory" => "configured",
            "security-domain" => "ManagementDomain"
        }
    }
    
    [standalone@localhost:9990 /] /subsystem=elytron/sasl-authentication-factory=managenet-sasl-authentication:list-remove(name=mechanism-configurations, index=0)
    
    [standalone@localhost:9990 /] reload
  2. 레거시 보안 영역을 사용할 때 자동 인증을 제거하려면 다음을 수행합니다.

    /core-service=management/security-realm=<realm_name>/authentication=local:remove

1.2.5. Elytron 하위 시스템을 사용하여 관리 인터페이스에 대한 단방향 SSL/TLS

JBoss EAP에서는 JBoss EAP 관리 CLI 또는 관리 콘솔을 사용하여 관리 인터페이스에 대해 일방향 SSL/TLS를 활성화할 수 있습니다.

관리 CLI에서는 일방향 SSL/TLS를 다음 두 가지 방법으로 활성화할 수 있습니다.

관리 콘솔에서는 다음과 같이 에서 단방향 SSL/TLS를 활성화할 수 있습니다.

1.2.5.1. 보안 명령을 사용하여 단방향 SSL/TLS 활성화

security enable-ssl-management 명령을 사용하여 관리 인터페이스에 대해 일방향 SSL/TLS를 활성화할 수 있습니다.

절차

  • CLI에 보안 enable-ssl-management --interactive 명령을 입력합니다.

    예제

    security enable-ssl-management --interactive
    
    Please provide required pieces of information to enable SSL:
    Key-store file name (default management.keystore): keystore.jks
    Password (blank generated): secret
    What is your first and last name? [Unknown]: localhost
    What is the name of your organizational unit? [Unknown]:
    What is the name of your organization? [Unknown]:
    What is the name of your City or Locality? [Unknown]:
    What is the name of your State or Province? [Unknown]:
    What is the two-letter country code for this unit? [Unknown]:
    Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct y/n [y]?
    Validity (in days, blank default): 365
    Alias (blank generated): localhost
    Enable SSL Mutual Authentication y/n (blank n): n
    
    SSL options:
    key store file: keystore.jks
    distinguished name: CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
    password: secret
    validity: 365
    alias: localhost
    Server keystore file keystore.jks, certificate file keystore.pem and keystore.csr file
    will be generated in server configuration directory.
    Do you confirm y/n :y

참고
  • 명령이 실행되면 관리 CLI가 서버를 다시 로드하고 다시 연결합니다.
  • disable- ssl-management 명령을 사용하여 관리 인터페이스에 대해 일방향 SSL/TLS를 비활성화할 수 있습니다.

    security disable-ssl-management

    이 명령은 Elytron 리소스를 삭제하지 않습니다. SSL 구성에 ApplicationRealm 레거시 보안 영역을 사용하도록 시스템을 구성합니다.

1.2.5.2. Elytron 하위 시스템 명령을 사용하여 단방향 SSL/TLS 활성화

elytron 하위 시스템 명령을 사용하여 관리 인터페이스에 대해 단방향 SSL/TLS를 활성화할 수 있습니다.

절차

  1. 키 저장소 구성.

    /subsystem=elytron/key-store=httpsKS:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
    참고

    위의 명령은 키 저장소 파일의 위치를 참조하기 위해 상대-to 를 사용합니다. 또는 경로에서 키 저장소의 전체 경로를 지정하고 relative-to 생략할 수도 있습니다.

    키 저장소 파일이 아직 없는 경우 다음 명령을 사용하여 예제 키 쌍을 생성할 수 있습니다.

    /subsystem=elytron/key-store=httpsKS:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
    
    /subsystem=elytron/key-store=httpsKS:store()
  2. key-managerserver-ssl-context 를 만듭니다.

    /subsystem=elytron/key-manager=httpsKM:add(key-store=httpsKS,credential-reference={clear-text=secret})
    
    /subsystem=elytron/server-ssl-context=httpsSSC:add(key-manager=httpsKM,protocols=["TLSv1.2"])
    중요

    Elytron 하위 시스템에서 KeyManagerfactory.getDefaultAlgorithm() 를 사용하여 기본적으로 알고리즘을 결정하므로 이전 명령에서 algorithm을 지정하지 않았습니다. 그러나 알고리즘 특성을 지정할 수 있습니다. 알고리즘 특성을 지정하려면 JDK에서 제공하는 키 관리자 알고리즘이 무엇인지 알아야 합니다. 예를 들어 SunJSSE를 사용하는 JDK는 PKIXSunX509 알고리즘을 제공합니다.

    이전 명령에서 SunX509 를 키 관리자 알고리즘 특성으로 지정할 수 있습니다.

    또한 지원할 HTTPS 프로토콜을 결정해야 합니다. 위의 예제 명령은 TLSv1.2 를 사용합니다.

    cipher-suite-filter 를 사용하여 암호화 제품군과 use-cipher-suites-order 인수를 사용하여 서버 암호화 제품군 순서를 준수할 수 있습니다. use-cipher-suites-order 속성은 기본적으로 true 로 설정됩니다. 이는 기본적으로 클라이언트 암호화 모음 순서를 준수하는 레거시 보안 하위 시스템 동작과 다릅니다.

  3. 관리 인터페이스에서 HTTPS를 활성화합니다.

    /core-service=management/management-interface=http-interface:write-attribute(name=ssl-context, value=httpsSSC)
    
    /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
  4. JBoss EAP 인스턴스를 다시 로드합니다.

    reload

관리 인터페이스에 대해 일방향 SSL/TLS가 활성화됩니다.

중요

보안 영역과 ssl-context가 모두 정의된 경우 JBoss EAP는 ssl -context 에서 제공하는 SSL/TLS 구성을 사용합니다 .

1.2.5.3. 관리 콘솔을 사용하여 단방향 SSL/TLS 활성화

관리 콘솔에서 SSL 마법사를 사용하여 관리 콘솔에서 사용하는 관리 인터페이스에 대해 SSL을 활성화할 수 있습니다.

절차

  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
  2. Runtime (런타임)으로 이동하여 적절한 서버 이름을 클릭합니다.
  3. 서버 이름 옆에 있는 View(보기 )를 클릭합니다.
  4. HTTP Manageme…​를 클릭합니다. HTTP 관리 인터페이스 구성 페이지를 엽니다.
  5. Enable SSL (SSL 활성화)을 클릭하여 마법사를 시작합니다.

    마법사는 SSL을 활성화하기 위한 다음 시나리오를 안내합니다.

    • 인증서 저장소를 생성하고 자체 서명된 인증서를 생성하려고 합니다.
    • Let's Encrypt 인증 기관에서 인증서를 가져오고자 합니다.
    • 파일 시스템에 인증서 저장소가 이미 있지만 키 저장소 구성이 없습니다.
    • 유효한 인증서 저장소를 사용하는 키 저장소 구성이 이미 있습니다.

마법사를 사용하여 상호 인증을 위한 신뢰 저장소를 선택적으로 생성할 수 있습니다.

1.2.6. Elytron subsystem을 사용하여 관리 인터페이스에 대한 양방향 SSL/TLS

JBoss EAP에서 관리 인터페이스에 대한 양방향 SSL/TLS는 보안 명령을 사용하거나 elytron 하위 시스템 명령을 사용하여 활성화할 수 있습니다.

양방향 SSL/TLS를 활성화하려면 먼저 클라이언트 인증서를 가져오거나 생성해야 합니다. 다음 절차를 사용하여 클라이언트 인증서를 생성할 수 있습니다.

그런 다음 다음 방법 중 하나를 사용하여 관리 인터페이스에 대해 양방향 SSL/TLS를 활성화할 수 있습니다.

1.2.6.1. 클라이언트 인증서 생성

CLI에서 keytool 명령을 사용하여 클라이언트 인증서를 생성할 수 있습니다.

절차

  1. 클라이언트 인증서를 생성합니다.

    $ keytool -genkeypair -alias client -keyalg RSA -keysize 1024 -validity 365 -keystore client.keystore.jks -dname "CN=client" -keypass secret -storepass secret
  2. 클라이언트 인증서를 내보냅니다.

    $ keytool -exportcert  -keystore client.keystore.jks -alias client -keypass secret -storepass secret -file /path/to/client.cer

1.2.6.2. 보안 명령을 사용하여 양방향 SSL/TLS 활성화

security enable-ssl-management 명령을 사용하여 관리 인터페이스에 대해 양방향 SSL/TLS를 활성화할 수 있습니다.

참고

다음 예제에서는 신뢰 체인이 없으므로 인증서를 확인하지 않습니다. 신뢰할 수 있는 인증서를 사용하는 경우 문제 없이 클라이언트 인증서를 검증할 수 있습니다.

사전 요구 사항

  • 클라이언트 키 저장소를 구성했습니다.
  • 서버 신뢰 저장소에 대한 인증서를 내보냈습니다.

    자세한 내용은 클라이언트 인증서 생성 을 참조하십시오.

절차

  • CLI에 보안 enable-ssl-management --interactive 명령을 입력합니다.

    예제

    security enable-ssl-management --interactive
    
    Please provide required pieces of information to enable SSL:
    Key-store file name (default management.keystore): server.keystore.jks
    Password (blank generated): secret
    What is your first and last name? [Unknown]: localhost
    What is the name of your organizational unit? [Unknown]:
    What is the name of your organization? [Unknown]:
    What is the name of your City or Locality? [Unknown]:
    What is the name of your State or Province? [Unknown]:
    What is the two-letter country code for this unit? [Unknown]:
    Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct y/n [y]?
    Validity (in days, blank default): 365
    Alias (blank generated): localhost
    Enable SSL Mutual Authentication y/n (blank n): y
    Client certificate (path to pem file): /path/to/client.cer
    Validate certificate y/n (blank y): n
    Trust-store file name (management.truststore): server.truststore.jks
    Password (blank generated): secret
    
    SSL options:
    key store file: server.keystore.jks
    distinguished name: CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
    password: secret
    validity: 365
    alias: localhost
    client certificate: /path/to/client.cer
    trust store file: server.trustore.jks
    trust store password: secret
    Server keystore file server.keystore.jks, certificate file server.pem and server.csr file will be generated in server configuration directory.
    Server truststore file server.trustore.jks will be generated in server configuration directory.
    Do you confirm y/n: y

    참고
    • 명령이 실행되면 관리 CLI가 서버를 다시 로드하고 다시 연결을 시도합니다.

      양방향 SSL/TLS 인증을 완료하려면 서버 인증서를 클라이언트 신뢰 저장소로 가져오고 클라이언트 인증서를 클라이언트 인증서를 제공하도록 구성해야 합니다.

    • disable- ssl-management 명령을 사용하여 관리 인터페이스에 대해 양방향 SSL/TLS를 비활성화할 수 있습니다.

      security disable-ssl-management

      이 명령은 Elytron 리소스를 삭제하지 않습니다. SSL 구성에 ApplicationRealm 레거시 보안 영역을 사용하도록 시스템을 구성합니다.

1.2.6.3. Elytron 하위 시스템 명령을 사용하여 양방향 SSL/TLS 활성화

elytron 하위 시스템 명령을 사용하여 관리 인터페이스에 대해 양방향 SSL/TLS를 활성화할 수 있습니다.

사전 요구 사항

절차

  1. 키 저장소를 가져오거나 생성합니다.

    JBoss EAP에서 일방향 SSL/TLS를 활성화하기 전에 사용하려는 키 저장소, 신뢰 저장소 및 인증서를 가져오거나 생성해야 합니다. 키 저장소, 신뢰 저장소 및 인증서의 예제 집합을 생성하려면 다음 명령을 사용합니다.

    1. 키 저장소 구성.

      /subsystem=elytron/key-store=twoWayKS:add(path=server.keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
      
      /subsystem=elytron/key-store=twoWayKS:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
      
      /subsystem=elytron/key-store=twoWayKS:store()
      참고

      위의 명령은 키 저장소 파일의 위치를 참조하기 위해 상대-to 를 사용합니다. 또는 경로에서 키 저장소의 전체 경로를 지정하고 relative-to 생략할 수도 있습니다.

    2. 서버 인증서를 내보냅니다.

      /subsystem=elytron/key-store=twoWayKS:export-certificate(alias=localhost,path=/path/to/server.cer,pem=true)
    3. 서버 신뢰 저장소의 키 저장소를 생성하고 클라이언트 인증서를 서버 신뢰 저장소로 가져옵니다.

      참고

      다음 예제에서는 신뢰 체인이 없으므로 인증서를 확인하지 않습니다. 신뢰할 수 있는 인증서를 사용하는 경우 문제 없이 클라이언트 인증서를 검증할 수 있습니다.

      /subsystem=elytron/key-store=twoWayTS:add(path=server.truststore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
      
      /subsystem=elytron/key-store=twoWayTS:import-certificate(alias=client,path=/path/to/client.cer,credential-reference={clear-text=secret},trust-cacerts=true,validate=false)
      
      /subsystem=elytron/key-store=twoWayTS:store()
  2. 서버 키 저장소 및 신뢰 저장소에 대해 key-manager, trust -manager 및 server-ssl-context 를 구성합니다.

    /subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS,credential-reference={clear-text=secret})
    
    /subsystem=elytron/trust-manager=twoWayTM:add(key-store=twoWayTS)
    
    /subsystem=elytron/server-ssl-context=twoWaySSC:add(key-manager=twoWayKM,protocols=["TLSv1.2"],trust-manager=twoWayTM,want-client-auth=true,need-client-auth=true)
    중요

    Elytron 하위 시스템에서 KeyManagerfactory.getDefaultAlgorithm() 및 TrustManager factory.getDefaultAlgorithm() 를 사용하여 기본적으로 알고리즘을 결정하므로 이전 명령에서 algorithm을 지정하지 않았습니다. 그러나 알고리즘 특성을 지정할 수 있습니다. 알고리즘 특성을 지정하려면 JDK에서 제공하는 키 관리자 알고리즘이 무엇인지 알아야 합니다. 예를 들어 SunJSSE를 사용하는 JDK는 PKIXSunX509 알고리즘을 제공합니다.

    이전 명령에서 SunX509 를 키 관리자 알고리즘 특성으로 지정하고 PKIX 를 신뢰 관리자 알고리즘 속성으로 지정할 수 있습니다.

    또한 지원할 HTTPS 프로토콜을 결정해야 합니다. 위의 예제 명령은 TLSv1.2 를 사용합니다.

    cipher-suite-filter 를 사용하여 암호화 제품군과 use-cipher-suites-order 인수를 사용하여 서버 암호화 제품군 순서를 준수할 수 있습니다. use-cipher-suites-order 속성은 기본적으로 true 로 설정됩니다. 이는 기본적으로 클라이언트 암호화 모음 순서를 준수하는 레거시 보안 하위 시스템 동작과 다릅니다.

  3. 관리 인터페이스에서 HTTPS를 활성화합니다.

    /core-service=management/management-interface=http-interface:write-attribute(name=ssl-context, value=twoWaySSC)
    
    /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
  4. JBoss EAP 인스턴스를 다시 로드합니다.

    reload
    참고

    양방향 SSL/TLS 인증을 완료하려면 서버 인증서를 클라이언트 신뢰 저장소로 가져오고 클라이언트 인증서를 클라이언트 인증서를 제공하도록 구성해야 합니다.

  5. 클라이언트에서 클라이언트 인증서를 사용하도록 구성합니다.

    양방향 SSL/TLS 인증을 완료하려면 서버에 신뢰할 수 있는 클라이언트 인증서를 제공하도록 클라이언트를 구성해야 합니다. 예를 들어 브라우저를 사용하는 경우 신뢰할 수 있는 인증서를 브라우저의 신뢰 저장소로 가져와야 합니다.

    따라서 원래 인증을 서버 관리로 변경하지 않고 강제 양방향 SSL/TLS 인증을 받게 됩니다.

    원래 인증 방법을 변경하려면 JBoss EAP에 대한 ID 관리 구성 방법인증서 구성을 참조하십시오.

양방향 SSL/TLS가 관리 인터페이스에 대해 이제 활성화됩니다.

중요

보안 영역과 ssl-context가 모두 정의된 경우 JBoss EAP는 ssl -context 에서 제공하는 SSL/TLS 구성을 사용합니다 .

1.2.7. CLI 보안 명령을 사용하여 관리 인터페이스에 대한 SASL 인증

CLI 보안 명령을 사용하여 관리 인터페이스에 대한 SASL 인증을 활성화 및 비활성화할 수 있습니다. 명령을 사용하여 SASL 메커니즘을 다시 정렬할 수도 있습니다.

SASL 인증 활성화

JBoss EAP에서 elytron SASL 인증 팩토리를 사용하는 SASL 인증 팩토리는 보안 enable-sasl-management 명령을 사용하여 관리 인터페이스에 대해 활성화할 수 있습니다. 이 명령은 인증을 구성하는 데 필요한 기존의 모든 리소스를 생성합니다. 기본적으로 이 명령은 포함된 SASL 팩토리를 http-interface 와 연결합니다.

예제: SASL 인증 활성화

security enable-sasl-management

Server reloaded.
Command success.
Authentication configured for management http-interface
sasl authentication-factory=management-sasl-authentication
security-domain=ManagementDomain

참고

명령이 실행되면 관리 CLI가 서버를 다시 로드하고 다시 연결합니다.

SASL 팩토리가 이미 있는 경우 --mechanism 인수에서 정의한 메커니즘을 사용하도록 팩토리가 업데이트됩니다.

인수 목록은 Authorization Security Arguments 를 참조하십시오.

SASL 인증 비활성화

활성 SASL 인증 팩토리를 제거하려면 다음 명령을 사용합니다.

security disable-sasl-management

또는 활성 SASL 인증 팩토리에서 특정 메커니즘을 제거하려면 다음 명령을 사용합니다.

security disable-sasl-management --mechanism=MECHANISM
SASL 메커니즘 다시 정렬

정의된 SASL 메커니즘의 순서는 서버가 클라이언트로 전송되는 첫 번째 일치 메커니즘을 사용하여 요청을 인증하는 방법을 지정합니다.

다음과 같이 쉼표로 구분된 을 보안 순서-sasl-management 명령에 전달하여 이 순서를 변경할 수 있습니다.

security reorder-sasl-management --mechanisms-order=MECHANISM1,MECHANISM2,...

추가 리소스

1.2.8. CLI 보안 명령을 사용하여 관리 인터페이스에 대한 HTTP 인증

CLI security 명령을 사용하여 관리 인터페이스에 대한 HTTP 인증을 활성화 및 비활성화할 수 있습니다.

HTTP 인증 활성화

JBoss EAP에서는 보안 enable-http-auth-management 명령을 사용한 관리 인터페이스에 대해 elytron HTTP 인증 팩토리를 사용하는 HTTP 인증을 활성화할 수 있습니다. 이 명령은 http-interface 만 대상으로 할 수 있으며 포함된 HTTP 인증 팩토리가 이 인터페이스와 연결된 추가 인수가 없습니다.

예제: HTTP 인증 활성화

security enable-http-auth-management

Server reloaded.
Command success.
Authentication configured for management http-interface
http authentication-factory=management-http-authentication
security-domain=ManagementDomain

참고

명령이 실행되면 관리 CLI가 서버를 다시 로드하고 다시 연결합니다.

HTTP 팩토리가 이미 있는 경우 --mechanism 인수에서 정의한 메커니즘을 사용하도록 팩토리가 업데이트됩니다.

인수 목록은 Authorization Security Arguments 를 참조하십시오.

HTTP 인증 비활성화

활성 HTTP 인증 팩토리를 제거하려면 다음 명령을 사용합니다.

security disable-http-auth-management

또는 다음 명령을 사용하여 활성 HTTP 인증 팩토리에서 특정 메커니즘을 제거할 수 있습니다.

security disable-http-auth-management --mechanism=MECHANISM

추가 리소스

1.2.9. 레거시 코어 관리 인증을 사용하여 단방향 SSL/TLS에 대한 관리 인터페이스 구성

일방향 SSL/TLS를 사용하는 통신용 JBoss EAP 관리 인터페이스를 구성하면 향상된 보안이 제공됩니다. 클라이언트와 관리 인터페이스 간의 모든 네트워크 트래픽이 암호화되므로 중간자 공격과 같은 보안 공격 위험이 줄어듭니다.

이 프로세스에서는 JBoss EAP 인스턴스와의 암호화되지 않은 통신이 비활성화됩니다. 이 절차는 독립 실행형 서버 및 관리형 도메인 구성에 모두 적용됩니다. 관리형 도메인의 경우 관리 CLI 명령 앞에 호스트 이름(예: /host=master )을 추가합니다.

중요

관리 인터페이스에서 일방향 SSL/TLS를 활성화하는 단계를 수행하는 동안 명시적으로 지시하지 않는 한 구성을 다시 로드하지 마십시오. 이렇게 하면 관리 인터페이스가 잠길 수 있습니다.

  1. 관리 인터페이스를 보호하기 위해 키 저장소를 생성합니다.

    자세한 내용은 관리 인터페이스 보안을 위해 키 저장소 생성을 참조하십시오.

  2. 관리 인터페이스가 HTTPS에 바인딩되는지 확인합니다.

    자세한 내용은 관리 인터페이스 구성이 HTTPS에 바인딩 되어 있는지 확인합니다.

  3. 선택 사항: 사용자 지정 socket-binding-group 을 구현합니다.

    자세한 내용은 Custom socket-binding-group 을 참조하십시오.

  4. 새 보안 영역을 생성합니다.

    자세한 내용은 새 보안 영역 생성을 참조하십시오.

  5. 새 보안 영역을 사용하도록 관리 인터페이스를 구성합니다.

    자세한 내용은 보안 영역을 사용하도록 관리 인터페이스 구성을 참조하십시오.

  6. 키 저장소를 사용하도록 관리 인터페이스를 구성합니다.

    자세한 내용은 키 저장소를 사용하도록 관리 인터페이스 구성을 참조하십시오.

  7. jboss-cli.xml 을 업데이트합니다.

    자세한 내용은 jboss-cli.xml 파일 업데이트를 참조하십시오.

1.2.9.1. 관리 인터페이스를 보호하기 위한 키 저장소 생성

관리 인터페이스를 보호하기 위해 키 저장소를 생성합니다.

관리 인터페이스는 JCEKS 형식의 키 저장소와 호환되지 않으므로 이 키 저장소는 JKS 형식이어야 합니다.

절차

  • 다음 CLI 명령을 사용하여 키 저장소를 생성합니다.

    매개 변수의 예제 값(예: alias,keypass,storepassdname )을 환경의 올바른 값으로 바꿉니다.

    $ keytool -genkeypair -alias appserver -storetype jks -keyalg RSA -keysize 2048 -keypass password1 -keystore EAP_HOME/standalone/configuration/identity.jks -storepass password1 -dname "CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US" -validity 730 -v
참고

매개변수 유효성 은 키가 유효한 일 수를 지정합니다. 730 의 값은 2년입니다.

1.2.9.2. 관리 인터페이스가 HTTPS에 바인딩되는지 확인

관리 인터페이스가 HTTPS에 바인딩되도록 JBoss EAP를 구성합니다.

절차

  • 독립 실행형 서버를 실행할 때 구성

    관리 인터페이스가 HTTPS에 바인딩되도록 하려면 management -https 구성을 추가하고 management-http 구성을 제거해야 합니다.

    다음 CLI 명령을 사용하여 관리 인터페이스를 HTTPS에 바인딩합니다.

    /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
    
    /core-service=management/management-interface=http-interface:undefine-attribute(name=socket-binding)
  • 관리형 도메인을 실행할 때 구성

    secure-port를 추가하고 포트 구성을 제거하여 management- interface 특성 내에서 소켓 요소를 변경합니다.

    다음 명령을 사용하여 관리 인터페이스를 HTTPS에 바인딩합니다.

    /host=master/core-service=management/management-interface=http-interface:write-attribute(name=secure-port,value=9993)
    
    /host=master/core-service=management/management-interface=http-interface:undefine-attribute(name=port)

1.2.9.3. 사용자 정의 socket-binding-group

사용자 지정 socket-binding-group을 사용하려면 management- https 바인딩이 정의되었는지 확인해야 합니다. 기본적으로 포트 9993 에 바인딩됩니다. 서버 구성 파일의 socket-binding-group 특성 또는 관리 CLI를 사용하여 확인할 수 있습니다.

/socket-binding-group=standard-sockets/socket-binding=management-https:read-resource(recursive=true)

{
    "outcome" => "success",
    "result" => {
        "client-mappings" => undefined,
        "fixed-port" => false,
        "interface" => "management",
        "multicast-address" => undefined,
        "multicast-port" => undefined,
        "name" => "management-https",
        "port" => expression "${jboss.management.https.port:9993}"
    }
}

1.2.9.4. 새 보안 영역 생성

새 보안 영역을 생성합니다.

이 절차에서는 HTTPS를 사용하는 새 보안 영역 ManagementRealmHTTPS, 사용자 이름 및 암호를 저장하기 위해 EAP_HOME/standalone/configuration/ 디렉터리에 있는 https-tekton-users.properties 라는 속성 파일을 사용합니다.

절차

  1. 사용자 이름 및 암호를 저장할 속성 파일을 만듭니다.

    나중에 사용자 이름 및 암호를 파일에 추가할 수 있지만, 현재는 https-mgmt-users.properties 라는 빈 파일을 생성하여 해당 위치에 저장해야 합니다. 아래 예제에서는 touch 명령을 사용하는 방법을 보여주지만 텍스트 편집기와 같은 다른 메커니즘을 사용할 수도 있습니다.

    예제: touch 명령을 사용하여 빈 파일 생성

    $ touch EAP_HOME/standalone/configuration/https-mgmt-users.properties

  2. 다음 관리 CLI 명령을 사용하여 ManagementRealmHTTPS 라는 새 보안 영역을 생성합니다.

    /core-service=management/security-realm=ManagementRealmHTTPS:add
    
    /core-service=management/security-realm=ManagementRealmHTTPS/authentication=properties:add(path=https-mgmt-users.properties,relative-to=jboss.server.config.dir)
  3. 속성 파일에 사용자를 추가합니다.

    이때 새 보안 영역을 생성하고 인증에 속성 파일을 사용하도록 구성했습니다. 이제 EAP_HOME/bin/ 디렉터리에서 사용할 수 있는 add-user 스크립트를 사용하여 해당 속성 파일에 사용자를 추가해야 합니다. add-user 스크립트를 실행하는 경우 각각 -up 및 - r 옵션을 사용하여 속성 파일과 보안 영역을 모두 지정해야 합니다. 여기에서 add-user 스크립트는 https-mgmt-users.properties 파일에 저장할 사용자 이름 및 암호 정보를 입력하라는 메시지를 대화식으로 표시합니다.

    $ EAP_HOME/bin/add-user.sh -up EAP_HOME/standalone/configuration/https-mgmt-users.properties -r ManagementRealmHTTPS
    ...
    Enter the details of the new user to add.
    Using realm 'ManagementRealmHTTPS' as specified on the command line.
    ...
    Username : httpUser
    Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file.
     - The password must not be one of the following restricted values {root, admin, administrator}
     - The password must contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
     - The password must be different from the username
    ...
    Password :
    Re-enter Password :
    About to add user 'httpUser' for realm 'ManagementRealmHTTPS'
    ...
    Is this correct yes/no? yes
    ..
    Added user 'httpUser' to file 'EAP_HOME/configuration/https-mgmt-users.properties'
    ...
    Is this new user going to be used for one AS process to connect to another AS process?
    e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
    yes/no? no
    중요

    속성 파일을 사용하여 사용자 이름과 암호를 저장하는 보안 영역을 구성하는 경우 각 영역에서 다른 영역과 공유하지 않는 고유한 속성 파일을 사용하는 것이 좋습니다.

1.2.9.5. 보안 영역을 사용하도록 관리 인터페이스 구성

관리 CLI 명령을 사용하여 보안 영역을 사용하도록 관리 인터페이스를 구성할 수 있습니다.

절차

  • 다음 관리 CLI 명령을 사용합니다.

    /core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=ManagementRealmHTTPS)

1.2.9.6. 키 저장소를 사용하도록 관리 인터페이스 구성

관리 CLI 명령을 사용하여 키 저장소를 사용하도록 관리 인터페이스를 구성합니다.

절차

  1. 다음 관리 CLI 명령을 사용하여 키 저장소를 사용하도록 관리 인터페이스를 구성합니다.

    매개 변수 파일의 경우 암호와 별칭의 값은 Create a Keystore(키 저장소 만들기)에서 Secure the Management Interfaces (관리 인터페이스 보안) 단계로 복사해야 합니다.

    /core-service=management/security-realm=ManagementRealmHTTPS/server-identity=ssl:add(keystore-path=identity.jks,keystore-relative-to=jboss.server.config.dir,keystore-password=password1, alias=appserver)
    참고

    키 저장소 암호를 업데이트하려면 다음 CLI 명령을 사용합니다.

    /core-service=management/security-realm=ManagementRealmHTTPS/server-identity=ssl:write-attribute(name=keystore-password,value=newpassword)
  2. 서버의 설정을 다시 로드합니다.

    reload

    서버 구성을 다시 로드한 후 시작하는 서비스 수를 나타내는 텍스트 바로 앞에 로그에 다음이 포함되어야 합니다.

    13:50:54,160 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0061: Http management interface listening on https://127.0.0.1:9993/management
    13:50:54,162 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0052: Admin console listening on https://127.0.0.1:9993

이제 관리 인터페이스가 포트 9993 에서 수신 대기하여 절차가 완료되었음을 확인합니다.

중요

이때 CLI의 연결을 끊고 포트 바인딩이 변경되었으므로 다시 연결할 수 없습니다.

관리 CLI가 다시 연결할 수 있도록 jboss-cli.xml 파일을 업데이트하려면 다음 단계를 진행합니다.

1.2.9.7. jboss-cli.xml 파일 업데이트

관리 작업을 수행하기 위해 관리 CLI를 사용하는 경우 EAP_HOME/bin/jboss-cli.xml 파일을 업데이트해야 합니다.

절차

  • 다음과 같이 EAP_HOME/bin/jboss-cli.xml 파일을 업데이트합니다.

    • <default-protocol> 값을 https-remoting으로 업데이트합니다.
    • <default-controller> 에서 <protocol> 값을 https-remoting 으로 업데이트합니다.
    • <default-controller> 에서 <port> 값을 9993 으로 업데이트합니다.

    예: jboss-cli.xml

    <jboss-cli xmlns="urn:jboss:cli:2.0">
        <default-protocol use-legacy-override="true">https-remoting</default-protocol>
        <!-- The default controller to connect to when 'connect' command is executed w/o arguments -->
        <default-controller>
            <protocol>https-remoting</protocol>
            <host>localhost</host>
            <port>9993</port>
        </default-controller>
    ...

다음에 관리 CLI를 사용하여 관리 인터페이스에 연결하면 서버 인증서를 수락하고 ManagementRealmHTTPS 보안 영역에 대해 인증해야 합니다.

예제: 서버 인증서 및 인증 수락

$ ./jboss-cli.sh -c
Unable to connect due to unrecognised server certificate
Subject    - CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US
Issuer     - CN=appserver, OU=Sales, O=Systems Inc, L=Raleigh, ST=NC, C=US
Valid From - Tue Jun 28 13:38:48 CDT 2016
Valid To   - Thu Jun 28 13:38:48 CDT 2018
MD5 : 76:f4:81:8b:7e:c3:be:6d:ee:63:c1:7a:b7:b8:f0:fb
SHA1 : ea:e3:f1:eb:53:90:69:d0:c9:69:4a:5a:a3:20:8f:76:c1:e6:66:b6

Accept certificate? [N]o, [T]emporarily, [P]ermenantly : p
Authenticating against security realm: ManagementRealmHTTPS
Username: httpUser
Password:
[standalone@localhost:9993 /]

중요

보안 영역과 ssl-context가 모두 정의된 경우 JBoss EAP는 ssl -context 에서 제공하는 SSL/TLS 구성을 사용합니다 .

1.2.10. 레거시 코어 관리 인증을 사용하여 관리 인터페이스에 대해 양방향 SSL/TLS 설정

클라이언트 인증이라고도 하는 양방향 SSL/TLS 인증은 SSL/TLS 인증서를 사용하여 클라이언트와 서버를 모두 인증합니다. 클라이언트와 서버 모두 인증서가 있다는 점에서 일방향 SSL/TLS에 대한 관리 인터페이스 구성 섹션과 다릅니다. 이렇게 하면 서버가 말하는 것은 물론 클라이언트가 말하는 사람이기도 한다는 것을 보장할 수 있습니다.

이 섹션에서 다음 규칙이 사용됩니다.

HOST1
JBoss 서버 호스트 이름. 예: jboss.redhat.com.
HOST2
클라이언트에 적합한 이름입니다. 예를 들면 myclient 입니다. 반드시 실제 호스트 이름은 아닙니다.
CA_HOST1
HOST1 인증서에 사용할 DN(고유 이름)입니다. 예: cn=jboss,dc=redhat,dc=com.
CA_HOST2
HOST2 인증서에 사용할 DN(고유 이름)입니다. 예를 들면 cn=myclient,dc=redhat,dc=com 입니다.
참고

암호 자격 증명 모음을 사용하여 키 저장소와 신뢰 저장소 암호를 저장하는 데 권장되는 경우 암호 자격 증명 모음이 이미 생성되어야 합니다. 암호 자격 증명 모음에 대한 자세한 내용은 Red Hat JBoss Enterprise Application Platform 7 보안 아키텍처 가이드 Password Vault 섹션과 Password Vault System 섹션을 참조하십시오.

주의

Red Hat은 영향을 받는 모든 패키지에서 TLSv1.1 또는 TLSv1.2를 기반으로 SSLv2, SSLv3 및 TLSv1.0을 명시적으로 비활성화하는 것이 좋습니다.

절차

  1. 키 저장소를 생성합니다.

    $ keytool -genkeypair -alias HOST1_alias -keyalg RSA -keysize 1024 -validity 365 -keystore HOST1.keystore.jks -dname "CA_HOST1" -keypass secret -storepass secret
    
    $ keytool -genkeypair -alias HOST2_alias -keyalg RSA -keysize 1024 -validity 365 -keystore HOST2.keystore.jks -dname "CA_HOST2" -keypass secret -storepass secret
  2. 인증서를 내보냅니다.

    $ keytool -exportcert  -keystore HOST1.keystore.jks -alias HOST1_alias -keypass secret -storepass secret -file HOST1.cer
    
    $ keytool -exportcert  -keystore HOST2.keystore.jks -alias HOST2_alias -keypass secret -storepass secret -file HOST2.cer
  3. 인증서를 다른 신뢰 저장소로 가져옵니다.

    $ keytool -importcert -keystore HOST1.truststore.jks -storepass secret -alias HOST2_alias -trustcacerts -file HOST2.cer
    
    $ keytool -importcert -keystore HOST2.truststore.jks -storepass secret -alias HOST1_alias -trustcacerts -file HOST1.cer
  4. CertificateRealm 정의.

    서버에 대한 구성(host.xml 또는 standalone.xml )에서 CertificateRealm을 정의하고 인터페이스를 가리킵니다. 다음 명령을 사용하여 수행할 수 있습니다.

    /core-service=management/security-realm=CertificateRealm:add()
    
    /core-service=management/security-realm=CertificateRealm/server-identity=ssl:add(keystore-path=/path/to/HOST1.keystore.jks, keystore-password=secret,alias=HOST1_alias)
    
    /core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-path=/path/to/HOST1.truststore.jks,keystore-password=secret)
  5. http -interface의 security- realm 을 새 CertificateRealm으로 변경합니다.

    /core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=CertificateRealm)
  6. CLI에 대한 SSL/TLS 구성을 추가합니다.

    중요

    양방향 SSL/TLS를 추가하는 것 외에도 관리 인터페이스도 HTTPS에 바인딩하도록 구성해야 합니다. 자세한 내용은 Legacy Core Management Authentication을 사용하여 일방향 SSL/TLS에 대한 관리 인터페이스 구성 섹션에서 HTTPS로 관리 인터페이스 바인딩 을 참조하십시오.

    EAP_HOME/bin/jboss-cli.xml을 설정 파일로 사용하는 CLI에 대한 SSL/ TLS 구성을 추가합니다.

    키 저장소 및 신뢰 저장소 암호를 일반 텍스트로 저장하려면 EAP_HOME/bin/jboss-cli.xml 을 편집하고 변수에 적절한 값을 사용하여 SSL/TLS 구성을 추가합니다.

    예: jboss-cli.xml 기본 텍스트로 키 저장소 및 신뢰 저장소 암호 저장

    <ssl>
      <alias>HOST2_alias</alias>
      <key-store>/path/to/HOST2.keystore.jks</key-store>
      <key-store-password>secret</key-store-password>
      <trust-store>/path/to/HOST2.truststore.jks</trust-store>
      <trust-store-password>secret</trust-store-password>
      <modify-trust-store>true</modify-trust-store>
    </ssl>

    암호 자격 증명 모음에 저장된 키 저장소 및 신뢰 저장소 암호를 사용하려면 자격 증명 모음 구성과 적절한 자격 증명 모음 값을 EAP_HOME/bin/jboss-cli.xml에 추가해야 합니다.

    예: jboss-cli.xml 암호 Vault에서 키 저장소 및 신뢰 저장소 암호 저장

    <ssl>
      <vault>
        <vault-option name="KEYSTORE_URL" value="path-to/vault/vault.keystore"/>
        <vault-option name="KEYSTORE_PASSWORD" value="MASK-5WNXs8oEbrs"/>
        <vault-option name="KEYSTORE_ALIAS" value="vault"/>
        <vault-option name="SALT" value="12345678"/>
        <vault-option name="ITERATION_COUNT" value="50"/>
        <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/>
      </vault>
      <alias>HOST2_alias</alias>
      <key-store>/path/to/HOST2.keystore.jks</key-store>
      <key-store-password>VAULT::VB::cli_pass::1</key-store-password>
      <key-password>VAULT::VB::cli_pass::1</key-password>
      <trust-store>/path/to/HOST2.truststore.jks</trust-store>
      <trust-store-password>VAULT::VB::cli_pass::1</trust-store-password>
      <modify-trust-store>true</modify-trust-store>
    </ssl>

중요

보안 영역과 ssl-context가 모두 정의된 경우 JBoss EAP는 ssl -context 에서 제공하는 SSL/TLS 구성을 사용합니다 .

1.2.11. HTTPS 리스너 참조

HTTPS 리스너에 사용할 수 있는 전체 속성 목록은 JBoss EAP 구성 가이드의 Undertow 하위 시스템 속성 섹션을 참조하십시오.

1.2.11.1. 암호 슈트 정보

허용되는 암호화 암호 목록을 구성할 수 있습니다. JSSE 구문의 경우 쉼표로 구분된 목록이어야 합니다. OpenSSL 구문의 경우 콜론으로 구분된 목록이어야 합니다. 구문 한 개만 사용되는지 확인합니다. 기본값은 JVM 기본값입니다.

중요

취약한 암호를 사용하는 것은 보안 위험이 높습니다. 암호화 제품군에 대한 NIST 권장 사항은 NIST 지침을 참조하십시오.

사용 가능한 OpenSSL 암호화 목록은 OpenSSL 설명서를 참조하십시오. 다음은 지원되지 않습니다.

  • @SECLEVEL
  • SUITEB128
  • 제품군
  • SUITEB192

표준 JSSE 암호화 목록은 Java 문서를 참조하십시오.

활성화된 암호화 제품군 목록을 업데이트하려면 undertow 하위 시스템에서 HTTPS 리스너의 enabled-cipher-suites 속성을 사용합니다.

예제: 활성화된 암호 슈트 목록을 업데이트하기 위한 관리 CLI 명령

/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enabled-cipher-suites,value="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA")

참고

이 예제에서는 두 개의 가능한 암호만 나열하지만, 실제 예제는 더 많이 사용할 수 있습니다.

1.2.12. OpenSSL 공급자로 TLS 1.3 프로토콜 지원 활성화

ssl-context 구성에서 cipher-suite-names 속성을 구성하여 OpenSSL 공급자로 TLS 1.3 프로토콜 지원을 활성화할 수 있습니다. OpenSSL TLS 공급자를 사용하도록 JBoss EAP를 구성하기 위한 다음 방법 중 하나를 선택합니다.

  • 기본적으로 OpenSSL TLS 프로바이더를 사용하도록 Elytron 하위 시스템을 구성합니다.
  • OpenSSL TLS 공급자를 사용하도록 server-ssl-context 구성 요소 또는 client-ssl-context 구성 요소의 provider 속성을 구성합니다.
중요

TLS 1.2와 비교하여 JDK 11을 사용하여 TLS 1.3을 실행할 때 성능이 저하될 수 있습니다. 이 문제는 클라이언트가 서버에 매우 많은 TLS 1.3 요청을 만들 때 발생할 수 있습니다. 최신 JDK 버전으로 시스템을 업그레이드하면 성능을 향상시킬 수 있습니다. 프로덕션 환경에서 활성화하기 전에 TLS 1.3으로 성능 저하를 테스트하십시오.

사전 요구 사항

  • 애플리케이션에 대해 일방향 SSL/TLS 또는 양방향 SSL/TLS를 활성화합니다.

절차

  1. OpenSSL TLS 공급자를 사용하도록 JBoss EAP 7.4 인스턴스를 구성하는 다음 방법 중 하나를 선택합니다.

    1. 기본적으로 OpenSSL TLS 프로바이더를 사용하도록 elytron 하위 시스템을 구성합니다. 이렇게 하려면 전 세계에 등록된 모든 공급자 후에 OpenSSL TLS 공급자를 등록하는 기본 최종 제공자 구성을 제거합니다.

      /subsystem=elytron:undefine-attribute(name=final-providers)
      reload

      다음으로 전 세계에 등록된 모든 공급자보다 먼저 OpenSSL TLS 공급자를 등록합니다.

      /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers)
    2. OpenSSL TLS 프로바이더 를 사용하도록 server-ssl-context 또는 client-ssl-context 의 provider 속성을 구성합니다.

      server SSC 라는 기존 server-ssl-context 에 대한 provider 속성을 설정하는 예제입니다.

      /subsystem=elytron/server-ssl-context=serverSSC:write-attribute(name=providers,value=openssl)
      reload

  2. 선택 사항: TLS 1.3 프로토콜 이외의 프로토콜을 사용하도록 ssl-context 를 구성한 경우 TLS 1.3 프로토콜을 포함하도록 ssl-context 에 protocol 속성을 구성해야 합니다.

    /subsystem=elytron/server-ssl-context=serverSSC:write-attribute(name=protocols,value=[TLSv1.3])
  3. ssl-context 구성에서 cipher-suite-names 속성을 구성하여 OpenSSL 프로바이더로 TLS 1.3 프로토콜 지원을 활성화합니다. 다음 예제에서는 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256cipher-suite-names 특성 값으로 설정합니다.

    /subsystem=elytron/server-ssl-context=serverSSC:write-attribute(name=cipher-suite-names,value=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256)
  4. JBoss EAP 인스턴스를 다시 로드합니다.

    reload
  5. 선택 사항: TLS 1.3 프로토콜 및 TLS 1.3 암호화 제품군을 사용하여 서버와 SSL 암호화 연결을 설정할 수 있는지 테스트합니다. curl 과 같은 도구를 사용하여 구성 출력을 확인합니다.

    curl -v https://<ip_address>:<ssl_port>

    SSL 연결을 보호하기 위해 TLS 1.3 프로토콜과 함께 TLS_AES_256_GCM_SHA384 를 보여주는 출력 예.

    SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
    * ALPN, server accepted to use h2
    * Server certificate:
    *  subject: C=Unknown; ST=Unknown; L=Unknown; O=Unknown; OU=Unknown; CN=localhost
    *  start date: Oct  6 14:58:16 2020 GMT
    *  expire date: Nov  5 15:58:16 2020 GMT
    *  issuer: C=Unknown; ST=Unknown; L=Unknown; O=Unknown; OU=Unknown; CN=localhost
    *  SSL certificate verify result: self signed certificate (18), continuing anyway.

추가 리소스

1.2.13. FIPS 140-2 호환 암호화

다음 방법 중 하나를 사용하여 Red Hat Enterprise Linux에서 FIPS 140-2 호환 암호화를 구성할 수 있습니다.

1.2.13.1. Red Hat Enterprise Linux 7 및 이후에서 SSL/TLS에 대한 FIPS 140-2 암호화 활성화

SSL/TLS에 FIPS 140-2 호환 암호화를 사용하도록 Undertow를 구성할 수 있습니다. 이 구성 예제의 범위는 FIPS 모드에서 Mozilla NSS 라이브러리를 사용하여 Red Hat Enterprise Linux 7 이상으로 제한됩니다.

중요

설치된 Red Hat Enterprise Linux는 FIPS 140-2 규격으로 이미 구성되어 있어야 합니다. 자세한 내용은 Red Hat 고객 포털에 있는 RHEL 6 또는 RHEL 7 FIPS288 호환 가능 여부에 해당하는 솔루션을 참조하십시오.

주의

FIPS 모드에서 JBoss EAP를 실행할 때 TLS 1.2 프로토콜을 사용하면 NoSuchAlgorithmException 이 발생할 수 있습니다. 이 문제에 대한 자세한 내용은 NoSuchAlgorithmException: no such algorithm에서 확인할 수 있습니다. Red Hat 고객 포털에 있는 SunTls12MasterSecret.

따라서 HTTP/2에 TLS 1.2 프로토콜이 필요하므로 FIPS 모드에서 HTTP/2를 구성할 수 없습니다. FIPS 모드(PKCS11)는 TLS 1 및 TLS 1.1 프로토콜을 지원하므로 다음을 사용할 수 있습니다.

  • Oracle/OpenJDK의 경우 TLS 1.1
  • IBM java의 경우 TLS 1

SSL/TLS에 FIPS 140-2 호환 암호화를 사용하도록 Undertow를 구성하려면 다음을 수행해야 합니다.

참고

OpenSSL 프로바이더에는 개인 키가 필요하지만 PKCS11 저장소에서 개인 키를 검색할 수는 없습니다. FIPS는 FIPS 호환 암호화 모듈에서 암호화되지 않은 키를 내보낼 수 없습니다. 따라서 Ely tron 하위 시스템과 레거시 보안 모두 FIPS 모드에서 TLS에 OpenSSL 공급자를 사용할 수 없습니다.

NSS 데이터베이스 구성
  1. NSS 데이터베이스를 보관할 적절한 사용자가 소유한 디렉터리를 만듭니다.

    NSS 데이터베이스 디렉터리 생성을 위한 명령 예

    $ mkdir -p /usr/share/jboss-as/nssdb
    $ chown jboss /usr/share/jboss-as/nssdb
    $ modutil -create -dbdir /usr/share/jboss-as/nssdb

    참고
    • RHEL 7 이전의 기본 데이터베이스 형식인 DBM 파일 형식은 더 이상 사용되지 않습니다. NSS는 기본적으로 SQL을 사용합니다.
    • jboss 사용자는 예시일 뿐입니다. JBoss EAP를 실행하려면 이를 운영 체제에서 활성 사용자로 교체합니다.
  2. NSS 구성 파일 /usr/share/jboss-as/nss_pkcsll_fips.cfg 를 만듭니다.

    다음을 지정해야 합니다.

    • 이름
    • NSS 라이브러리가 있는 디렉토리
    • NSS 데이터베이스가 이전 단계에서 생성된 디렉토리

      예: nss_pkcsll_fips.cfg

      name = nss-fips
      nssLibraryDirectory=/usr/lib64
      nssSecmodDirectory=/usr/share/jboss-as/nssdb
      nssDbMode = readOnly
      nssModule = fips

      참고

      64비트 버전의 Red Hat Enterprise Linux 6을 실행하지 않는 경우 nssLibraryDirectory/usr/lib 64 대신 /usr/lib 로 설정합니다.

  3. Java 보안 구성 파일을 편집합니다. 이 구성 파일은 전체 JVM에 영향을 미치며 다음 방법 중 하나를 사용하여 정의할 수 있습니다.

    • 기본 구성 파일 java.security 가 JDK에 제공됩니다. 이 파일은 다른 보안 구성 파일이 지정되지 않은 경우 사용됩니다. 이 파일의 위치는 JDK 벤더의 설명서를 참조하십시오.
    • 사용자 지정 Java 보안 구성 파일을 정의하고 -Djava.security.properties=/path/to/java.security.properties 를 사용하여 이를 참조합니다. 이러한 방식으로 참조할 경우 기본 보안 파일의 설정을 덮어씁니다. 이 옵션은 서로 다른 보안 설정이 필요한 동일한 호스트에서 여러 JVM을 실행하는 경우 유용합니다.

      Java 보안 구성 파일에 다음 행을 추가합니다.

      예: java.security

      security.provider.1=sun.security.pkcs11.SunPKCS11 /usr/share/jboss-as/nss_pkcsll_fips.cfg

      참고

      위 행에 지정된 nss_pkcsll_fips.cfg 구성 파일은 이전 단계에서 만든 파일입니다.

      구성 파일에서 다음 링크도 업데이트해야 합니다.

      security.provider.5=com.sun.net.ssl.internal.ssl.Provider

      다음으로 변경

      security.provider.5=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-nss-fips
      중요

      이 파일에 있는 다른 security.provider.X 행(예: security.provider.2)은 이 공급자에 우선 순위를 지정하기 위해 X 값을 하나씩 늘려야 합니다.

  4. 이전 단계에서 만든 NSS 데이터베이스 디렉터리에서 modutil 명령을 실행하여 FIPS 모드를 활성화합니다.

    modutil -fips true -dbdir /usr/share/jboss-as/nssdb
    참고

    현재 보안 라이브러리 오류가 발생하면 NSS 공유 객체에 대한 라이브러리 서명을 다시 생성해야 합니다.

  5. FIPS 토큰에 암호를 설정합니다.

    토큰 이름은 NSS FIPS 140-2 인증서 DB 여야 합니다.

    modutil -changepw "NSS FIPS 140-2 Certificate DB" -dbdir /usr/share/jboss-as/nssdb
    중요

    FIPS 토큰에 사용되는 암호는 FIPS 호환 암호여야 합니다. 암호가 충분하지 않으면 오류가 발생할 수 있습니다. 오류: 토큰 "NSS FIPS 140-2 인증서 DB"에서 암호를 변경할 수 없습니다.

  6. NSS 도구를 사용하여 인증서를 생성합니다.

    명령 예

    $ certutil -S -k rsa -n undertow -t "u,u,u" -x -s "CN=localhost, OU=MYOU, O=MYORG, L=MYCITY, ST=MYSTATE, C=MY" -d /usr/share/jboss-as/nssdb

  7. 다음 명령을 실행하여 JVM이 PKCS11 키 저장소에서 개인 키를 읽을 수 있는지 확인합니다.

    $ keytool -list -storetype pkcs11
중요

FIPS가 활성화되면 JBoss EAP를 시작할 때 다음 오류가 표시될 수 있습니다.

10:16:13,993 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.server.controller.management.security_realm.ApplicationRealm.key-manager: org.jboss.msc.service.StartException in service jboss.server.controller.management.security_realm.ApplicationRealm.key-manager: WFLYDM0018: Unable to start service
	at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:85)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.security.KeyStoreException: FIPS mode: KeyStore must be from provider SunPKCS11-nss-fips
	at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:67)
	at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
	at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:130)
	at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:83)
	... 5 more

이 메시지는 FIPS 140-2 규격 암호화를 사용하지 않는 레거시 코어 관리 인증의 기본 키 관리자와 같은 기존 키 관리자가 구성된 경우 나타납니다.

SSL/TLS용 FIPS 140-2 호환 암호화에 대한 관리 CLI 구성

SSL/TLS가 활성화된 FIPS 140-2 호환 암호화 환경에서 작동하도록 JBoss EAP 관리 CLI를 구성해야 합니다. 기본적으로 이러한 환경에서 관리 CLI를 사용하려고 하면 org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException이 발생합니다. FIPS 모드: SunJSSE TrustManager만 사용할 수 있습니다.

  • 레거시 보안 하위 시스템을 사용하는 경우:

    다음과 같이 jboss-cli .sh 파일에서 javax.net.ssl.trustStore 및 javax.net.ssl. trustStore 시스템 속성을 업데이트합니다.

    JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11"
    JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=P@ssword123"
  • elytron 하위 시스템을 사용하는 경우:

    1. 다음 콘텐츠를 사용하여 관리 CLI의 XML 구성 파일을 생성합니다.

      예: cli-wildfly-config.xml

      <configuration>
        <authentication-client xmlns="urn:elytron:client:1.2">
          <key-stores>
            <key-store name="truststore" type="PKCS11">
              <key-store-clear-password password="P@ssword123"/>
            </key-store>
          </key-stores>
          <ssl-contexts>
            <ssl-context name="client-cli-context">
              <trust-store key-store-name="truststore"/>
              <cipher-suite selector="${cipher.suite.filter}"/>
              <protocol names="TLSv1.1"/>
            </ssl-context>
          </ssl-contexts>
          <ssl-context-rules>
            <rule use-ssl-context="client-cli-context"/>
          </ssl-context-rules>
        </authentication-client>
      </configuration>

      참고

      IBM JDK를 사용하는 경우 필요한 특정 구성의 IBM 관리 CLI 구성 예를 참조하십시오.

    2. 관리 CLI를 시작할 때 -Dwildfly.config.url 속성을 사용하여 구성 파일을 관리 CLI 스크립트에 전달합니다. 예를 들면 다음과 같습니다.

      $ jboss-cli.sh -Dwildfly.config.url=cli-wildfly-config.xml
Elytron 및 Undertow 하위 시스템 구성
  1. FIPS 140-2 호환 암호화 키 저장소,키- manager 및 ssl- context 를 추가합니다.

    /subsystem=elytron/key-store=fipsKS:add(type=PKCS11,provider-name="SunPKCS11-nss-fips",credential-reference={clear-text="P@ssword123"})
    
    /subsystem=elytron/key-manager=fipsKM:add(key-store=fipsKS,algorithm="SunX509",provider-name=SunPKCS11-nss-fips,credential-reference={clear-text="P@ssword123"})
    
    /subsystem=elytron/server-ssl-context=fipsSSC:add(key-manager=fipsKM,protocols=["TLSv1.1"])
  2. ssl-context 를 사용하도록 undertow 하위 시스템을 업데이트합니다.

    참고

    HTTPS-listener 에는 항상 security-realm 또는 ssl- context 가 구성되어 있어야 합니다. 두 구성을 변경하는 경우 아래 표시된 대로 명령을 단일 배치로 실행해야 합니다.

    batch
    /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=fipsSSC)
    run-batch
    
    reload

elytron 하위 시스템에서 FIPS 모드의 OpenJDK 및 Oracle JDK는 사용자 지정 KeyManager 또는 TrustManager 구현을 기반으로 하는 고급 기능의 사용을 제한합니다. 다음 구성 속성은 서버에서 작동하지 않습니다.

  • server-ssl-context.security-domain
  • trust-manager.certificate-revocation-list
Legacy Core Management Authentication을 사용하여 Undertow 구성

필요한 경우 elytron 하위 시스템 대신 레거시 코어 관리 인증을 계속 사용하여 SSL/TLS에 대한 FIPS 140-2 호환 암호화 설정을 완료할 수 있습니다.

  1. SSL/TLS를 사용하도록 Undertow를 구성합니다.

    참고

    아래의 다음 명령은 배치 모드에서 실행해야 합니다. 또는 ssl 서버 ID를 추가한 후 서버를 다시 로드해야 합니다. 아래 예는 배치 모드를 사용하여 확인할 수 있습니다.

    batch
    
    /core-service=management/security-realm=HTTPSRealm:add
    
    /core-service=management/security-realm=HTTPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="strongP@ssword1")
    
    /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=HTTPSRealm, enabled-protocols="TLSv1.1")
    
    run-batch

    Undertow를 SSL/TLS로 구성하기 위한 기본 세부 정보는 애플리케이션용 SSL/TLS 설정에서 다룹니다.

  2. Undertow에서 사용하는 암호화 제품군을 구성합니다.

    SSL/TLS가 구성되면 특정 암호화 제품군 세트가 활성화되도록 https 리스너 및 보안 영역을 구성해야 합니다.

    필요한 암호 슈트

    SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_AES_256_CBC_SHA

    https 리스너에 대한 암호화 제품군 활성화의 기본 사항은 Cipher suite 정보 에서 다룹니다. https 리스너에서 암호화 제품군을 활성화하려면 다음을 수행합니다.

    Https 리스너에서 Cipher Suites 활성화 명령 예

    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enabled-cipher-suites,value="SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA,TLS_ECDH_anon_WITH_AES_256_CBC_SHA")

  3. 보안 영역에서 암호화 제품군을 활성화합니다.

    보안 영역에서 Cipher Suites 활성화 명령 예

    /core-service=management/security-realm=HTTPSRealm/server-identity=ssl:write-attribute(name=enabled-cipher-suites, value=[SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_AES_256_CBC_SHA])

1.2.13.2. Bouncy를 사용하여 SSL/TLS에 대한 FIPS 140-2 암호화 활성화

SSL/TLS에 FIPS 140-2 호환 암호화를 사용하도록 Undertow를 구성할 수 있습니다. 이 구성 예제의 범위는 Red Hat Enterprise Linux 7 이상으로 제한됩니다. Bou skills JAR은 Red Hat에서 제공하지 않으며 Bouncy 에서 직접 받아야 합니다.

사전 요구 사항
  • 환경이 Bouncy-le 공급업체 를 사용하도록 구성되었는지 확인합니다.
  • Bouncy(취소) 키 저장소는 서버에 있어야 합니다. 존재하지 않는 경우 다음 명령을 사용하여 만들 수 있습니다.

    $ keytool -genkeypair -alias ALIAS -keyalg RSA -keysize 2048 -keypass PASSWORD -keystore KEYSTORE -storetype BCFKS -storepass STORE_PASSWORD
Elytron을 사용하여 FIPS 140-2 Compliant Cryptography for SSL/TLS에 대한 관리 CLI 구성

SSL/TLS가 활성화된 FIPS 140-2 호환 암호화 환경에서 작동하도록 JBoss EAP 관리 CLI를 구성해야 합니다.

  1. 다음 콘텐츠를 사용하여 관리 CLI의 XML 구성 파일을 생성합니다.

    예: cli-wildfly-config.xml

    <configuration>
      <authentication-client xmlns="urn:elytron:client:1.2">
        <key-stores>
          <key-store name="truststore" type="BCFKS">
            <file name="${truststore.location}" />
            <key-store-clear-password password="${password}" />
          </key-store>
          <key-store name="keystore" type="BCFKS">
            <file name="${keystore.location}" />
            <key-store-clear-password password="${password}" />
          </key-store>
        </key-stores>
        <ssl-contexts>
          <ssl-context name="client-cli-context">
            <key-store-ssl-certificate algorithm="PKIX" key-store-name="keystore">
              <key-store-clear-password password="${password"} />
            </key-store-ssl-certificate>
            <trust-store key-store-name="truststore"/>
            <trust-manager algorithm="PKIX">
            </trust-manager>
            <cipher-suite selector="TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CCM,TLS_RSA_WITH_AES_128_CCM"/>
            <protocol names="TLSv1.2"/>
          </ssl-context>
        </ssl-contexts>
        <ssl-context-rules>
          <rule use-ssl-context="client-cli-context"/>
        </ssl-context-rules>
      </authentication-client>
    </configuration>

  2. 관리 CLI를 시작할 때 -Dwildfly.config.url 속성을 사용하여 구성 파일을 관리 CLI 스크립트에 전달합니다. 예를 들면 다음과 같습니다.

    $ jboss-cli.sh -Dwildfly.config.url=cli-wildfly-config.xml
Elytron 및 Undertow 하위 시스템 구성
  1. FIPS 140-2 호환 암호화 키 저장소,키- manager 및 ssl- context 를 추가합니다. 키 저장소를 정의할 때 유형은 BCFKS 여야 합니다.

    /subsystem=elytron/key-store=fipsKS:add(path=KEYSTORE,relative-to=jboss.server.config.dir,credential-reference={clear-text=STORE_PASSWORD},type="BCFKS")
    
    /subsystem=elytron/key-manager=fipsKM:add(key-store=fipsKS,algorithm="PKIX",credential-reference={clear-text=PASSWORD})
    
    /subsystem=elytron/server-ssl-context=fipsSSC:add(key-manager=fipsKM,protocols=["TLSv1.2"],cipher-suite-filter="TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CCM,TLS_RSA_WITH_AES_128_CCM")
  2. ssl-context 를 사용하도록 undertow 하위 시스템을 업데이트합니다.

    참고

    HTTPS-listener 에는 항상 security-realm 또는 ssl- context 가 구성되어 있어야 합니다. 두 구성을 변경하는 경우 아래 표시된 대로 명령을 단일 배치로 실행해야 합니다.

    batch
    /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=fipsSSC)
    run-batch
    
    reload

1.2.14. FIPS 140-2 IBM JDK의 암호화 호환

IBM JDK에서 JCE(Java Cryptographic Extension) IBMJCEFIPS 공급자 및 JSSE(Java Secure Sockets Extension) FIPS 140-2 암호화 모듈(IBMJSSE2)은 FIPS 140-2 호환 암호화를 제공합니다.

IBMJCEFIPS 공급자에 대한 자세한 내용은 IBM JCEFIPS 및 NIST IBM JCEFIPS - 보안 정책을 참조하십시오. IBMJSSE2에 대한 자세한 내용은 FIPS 모드에서 IBMJSSE2 실행을 참조하십시오.

1.2.14.1. 키 스토리지

IBM JCE는 키 저장소를 제공하지 않습니다. 키는 컴퓨터에 저장되며 실제 경계를 남겨 두지 않습니다. 키가 컴퓨터 간에 이동하는 경우 암호화되어야 합니다.

FIPS 호환 모드에서 keytool 을 실행하려면 다음과 같이 각 명령에 -providerClass 옵션을 사용하십시오.

keytool -list -storetype JCEKS -keystore mystore.jck -storepass mystorepass -providerClass com.ibm.crypto.fips.provider.IBMJCEFIPS

1.2.14.2. 관리 CLI 구성

IBM JDK 에서 FIPS 140-2 호환 암호화용 관리 CLI를 구성하려면 다음과 같은 IBM JDK 전용 관리 CLI 구성 파일을 사용해야 합니다.

예: cli-wildfly-config-ibm.xml

<configuration>
  <authentication-client xmlns="urn:elytron:client:1.2">
    <key-stores>
      <key-store name="truststore" type="JKS">
        <file name="/path/to/truststore"/>
        <key-store-clear-password password="P@ssword123"/>
      </key-store>
    </key-stores>
    <ssl-contexts>
      <ssl-context name="client-cli-context">
        <trust-store key-store-name="truststore"/>
        <cipher-suite selector="${cipher.suite.filter}"/>
        <protocol names="TLSv1"/>
      </ssl-context>
    </ssl-contexts>
    <ssl-context-rules>
      <rule use-ssl-context="client-cli-context"/>
    </ssl-context-rules>
  </authentication-client>
</configuration>

1.2.14.3. FIPS 공급자 정보 검사

서버에서 사용하는 IBMJCEFIPS에 대한 정보를 검사하려면 standalone.conf 또는 domain.conf 파일에 -Djavax.net.debug=true 를 추가하여 디버그 수준 로깅을 활성화합니다. FIPS 공급자에 대한 정보는 server.log 파일에 기록됩니다. 예를 들면 다음과 같습니다.

04:22:45,685 INFO  [stdout] (http-/127.0.0.1:8443-1) JsseJCE:  Using MessageDigest SHA from provider IBMJCEFIPS version 1.7
04:22:45,689 INFO  [stdout] (http-/127.0.0.1:8443-1) DHCrypt:  DH KeyPairGenerator  from provider from init IBMJCEFIPS version 1.7
04:22:45,754 INFO  [stdout] (http-/127.0.0.1:8443-1) JsseJCE:  Using KeyFactory DiffieHellman from provider IBMJCEFIPS version 1.7
04:22:45,754 INFO  [stdout] (http-/127.0.0.1:8443-1) JsseJCE:  Using KeyAgreement DiffieHellman from provider IBMJCEFIPS version 1.7
04:22:45,754 INFO  [stdout] (http-/127.0.0.1:8443-1) DHCrypt:  DH KeyAgreement  from provider IBMJCEFIPS version 1.7
04:22:45,754 INFO  [stdout] (http-/127.0.0.1:8443-1) DHCrypt:  DH KeyAgreement  from provider from initIBMJCEFIPS version 1.7

1.2.15. JVM이 FIPS 모드에서 실행되는 경우 관리형 도메인 시작

통신에 SSL/TLS를 사용하도록 각 호스트 컨트롤러 및 마스터 도메인 컨트롤러를 업데이트합니다.

사전 요구 사항

시작하기 전에 다음 사전 요구 사항을 완료해야 합니다.

  • 관리형 도메인을 구현했습니다.

    관리형 도메인 구성에 대한 자세한 내용은 JBoss EAP 구성 가이드의 도메인 관리 섹션을 참조하십시오.

  • FIPS가 설정되어 있습니다.

    FIPS 구성에 대한 자세한 내용은 Red Hat Enterprise Linux 7 이상에서 FIPS 140-2 암호화 활성화를 참조하십시오.

  • 필요한 모든 인증서를 생성하고 도메인 컨트롤러 인증서를 각 컨트롤러의 신뢰 저장소로 가져왔습니다.
주의

Red Hat은 영향을 받는 모든 패키지에서 TLSv1.1 대신 SSLv2, SSLv3 및 TLSv1.0을 명시적으로 비활성화하는 것이 좋습니다.

  1. 마스터 도메인 컨트롤러에서 NSS 데이터베이스를 PKCS11 프로바이더로 사용하도록 구성된 SSL/TLS 보안 영역을 생성합니다.

    예제: 마스터 도메인 컨트롤러의 보안 영역

    <security-realm name="HTTPSRealm">
        <server-identities>
            <ssl>
                <engine enabled-protocols="TLSv1.1"/>
                <keystore provider="PKCS11" keystore-password="strongP@ssword1"/>
            </ssl>
        </server-identities>
        <authentication>
            <local default-user="\$local"/>
            <properties path="https-users.properties" relative-to="jboss.domain.config.dir"/>
        </authentication>
    </security-realm>

  2. 각 호스트 컨트롤러에서 인증을 위한 SSL/TLS 신뢰 저장소로 보안 영역을 생성합니다.

    예제: 각 호스트 컨트롤러의 보안 영역

    <security-realm name="HTTPSRealm">
      <authentication>
        <truststore provider="PKCS11" keystore-password="strongP@ssword1"/>
      </authentication>
    </security-realm>

    참고

    각 호스트에서 이 프로세스를 반복합니다.

  3. 방금 만든 보안 영역을 사용하여 마스터 도메인 컨트롤러에서 HTTP 인터페이스를 보호합니다.

    예제: HTTP 인터페이스

    <management-interfaces>
        <http-interface security-realm="HTTPSRealm">
            <http-upgrade enabled="true"/>
            <socket interface="management" port="${jboss.management.http.port:9990}"/>
        </http-interface>
    </management-interfaces>

  4. 각 호스트 컨트롤러에서 SSL/TLS 영역을 사용하여 마스터 도메인 컨트롤러에 연결합니다.

    마스터 도메인 컨트롤러 연결에 사용되는 보안 영역을 업데이트합니다. 서버가 실행되지 않는 동안 host .xml 또는 host-slave.xml 과 같이 호스트 컨트롤러의 구성 파일을 수정합니다.

    예제: 호스트 컨트롤러 구성 파일

    <domain-controller>
      <remote security-realm="HTTPSRealm">
        <discovery-options>
          <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9990}"/>
        </discovery-options>
      </remote>
    </domain-controller>

  5. 각 서버가 호스트 컨트롤러에 다시 연결하는 방법을 업데이트합니다.

    예제: 서버 설정

    <server name="my-server" group="my-server-group">
      <ssl ssl-protocol="TLS" trust-manager-algorithm="PKIX" truststore-type="PKCS11" truststore-password="strongP@ssword1"/>
    </server>

  6. 관리형 도메인에서 양방향 SSL/TLS를 구성합니다.

    양방향 SSL/TLS를 활성화하려면 마스터 도메인 컨트롤러의 SSL/TLS 보안 영역에 신뢰 저장소 인증 방법을 추가하려면 다음 관리 CLI 명령을 실행합니다.

    /host=master/core-service=management/security-realm=HTTPSRealm/authentication=truststore:add(keystore-provider="PKCS11",keystore-password="strongP@ssword1")
    
    reload --host=master

    또한 SSL 서버 ID가 있도록 각 호스트 컨트롤러의 보안 영역을 업데이트하고 다음 관리 CLI 명령을 실행해야 합니다.

    /host=host1/core-service=management/security-realm=HTTPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="strongP@ssword1",enabled-protocols=["TLSv1.1"])
    
    reload --host=host1
    중요

    또한 각 호스트의 인증서를 도메인 컨트롤러의 신뢰 저장소로 가져와야 합니다.

1.2.16. Red Hat Single Sign-On으로 관리 콘솔 보안

elytron 하위 시스템을 사용하여 Red Hat Single Sign-On으로 JBoss EAP 관리 콘솔을 보호할 수 있습니다.

참고

이 기능은 독립 실행형 서버를 실행할 때만 사용할 수 있으며 관리형 도메인을 실행할 때 지원되지 않습니다. Red Hat Single Sign-On을 사용하여 관리 CLI를 보호하는 것은 지원되지 않습니다.

다음 단계를 사용하여 JBoss EAP 관리 콘솔에 대한 사용자를 인증하도록 Red Hat Single Sign-On을 설정합니다.

JBoss EAP 관리를 위한 Red Hat Single Sign-On 서버 구성
  1. Red Hat SSO(Single Sign-On) 서버 다운로드 및 설치. 기본 지침은 Red Hat Single Sign-On Getting Started Guide 를 참조하십시오.
  2. Red Hat Single Sign-On 서버 시작.

    이 절차에서는 100 의 포트 오프셋으로 서버를 시작했다고 가정했습니다.

    $ RHSSO_HOME/bin/standalone.sh -Djboss.socket.binding.port-offset=100
  3. http://localhost:8180/auth/ 에서 Red Hat SSO(Single Sign-On) 관리 콘솔에 로그인합니다.

    Red Hat Single Sign-On 관리 콘솔에 처음 액세스한 경우 초기 관리 사용자를 생성하라는 메시지가 표시됩니다.

  4. wildfly-infra 라는 새 영역을 생성합니다.

    1. 영역 이름 옆에 있는 드롭다운에서 Add realm (영역 추가)을 클릭하고 Name (이름) 필드에 wildfly-infra 를 입력한 다음 Create(만들기 )를 클릭합니다.
  5. wildfly-console 이라는 클라이언트 애플리케이션을 생성합니다.

    중요

    이 클라이언트 애플리케이션의 이름은 be wildfly-console 이어야 합니다.

    1. Clients (클라이언트)를 선택하고 Create(생성)를 클릭합니다.
    2. 클라이언트 ID 필드에 있는 wildfly-console 을 입력하고 Save(저장 )를 클릭합니다.
    3. 표시되는 설정 화면에서 액세스 유형을 공용 으로 설정하고유효한 리디렉션 URI를 http://localhost:9990/console/*, Web Originshttp://localhost:9990, Save( 저장 )를 클릭합니다.
  6. wildfly-management 라는 클라이언트 애플리케이션을 생성합니다.

    1. Clients (클라이언트)를 선택하고 Create(생성)를 클릭합니다.
    2. 클라이언트 ID 필드에 wildfly-management 를 입력하고 Save(저장 )를 클릭합니다.
    3. 표시되는 Settings (설정) 화면에서 Access Type (액세스 유형)을 전달자 전용으로 설정하고 Save(저장 )를 클릭합니다.
  7. JBoss EAP 관리 콘솔에 대한 액세스 권한을 부여하는 역할을 만듭니다.

    1. Roles(역할 )를 선택하고 Add Role (역할 추가)을 클릭합니다.
    2. Role Name (역할 이름) 필드의 대문자로 Enter ADMINISTRATOR 를 입력하고 Save(저장 )를 클릭합니다.

      이 절차에서는 ADMINISTRATOR 역할을 사용하지만 다른 역할은 지원됩니다. 자세한 내용은 JBoss EAP 보안 아키텍처역할 기반 액세스 제어 섹션을 참조하십시오.

  8. 사용자를 생성하고 ADMINISTRATOR 역할을 할당합니다.

    1. Users(사용자 )를 선택하고 Add user(사용자 추가 )를 클릭합니다.
    2. Username (사용자 이름) 필드에 jboss 를 입력하고 Save(저장 )를 클릭합니다.
    3. Credentials(자격 증명 ) 탭을 선택하고 이 사용자의 암호를 설정합니다.
    4. Role Mappings (역할 맵핑) 탭을 선택하고 ADMINISTRATOR(ADMINISTRATOR )를 선택한 다음 Add selected (선택한 추가)를 클릭하여 역할을 이 사용자에게 추가합니다.
JBoss EAP에 Red Hat Single Sign-On 클라이언트 어댑터 설치
  1. 소프트웨어 다운로드 페이지에서 JBoss EAP 7용 Red Hat Single Sign-On 클라이언트 어댑터를 다운로드합니다.
  2. 이 파일의 압축을 JBoss EAP 설치의 루트 디렉터리에 풉니다.
  3. adapter-elytron-install-offline.cli 스크립트를 실행하여 JBoss EAP 설치를 구성합니다.

    $ EAP_HOME/bin/jboss-cli.sh --file=adapter-elytron-install-offline.cli
    중요

    이 스크립트는 elytronundertow 하위 시스템에서 keycloak 하위 시스템과 기타 필수 리소스를 standalone.xml 에 추가합니다. 다른 구성 파일을 사용해야 하는 경우 필요에 따라 스크립트를 수정합니다.

Red Hat Single Sign-On을 사용하도록 JBoss EAP 구성
  1. EAP_HOME/bin/ 디렉터리에서 다음 콘텐츠를 사용하여 protect-eap-mgmt-services.cli 라는 파일을 생성합니다.

    # Create a realm for both JBoss EAP console and mgmt interface
    /subsystem=keycloak/realm=wildfly-infra:add(auth-server-url=http://localhost:8180/auth,realm-public-key=REALM_PUBLIC_KEY)
    
    # Create a secure-deployment in order to protect mgmt interface
    /subsystem=keycloak/secure-deployment=wildfly-management:add(realm=wildfly-infra,resource=wildfly-management,principal-attribute=preferred_username,bearer-only=true,ssl-required=EXTERNAL)
    
    # Protect HTTP mgmt interface with Keycloak adapter
    /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm)
    /subsystem=elytron/http-authentication-factory=keycloak-mgmt-http-authentication:add(security-domain=KeycloakDomain,http-server-mechanism-factory=wildfly-management,mechanism-configurations=[{mechanism-name=KEYCLOAK,mechanism-realm-configurations=[{realm-name=KeycloakOIDCRealm,realm-mapper=keycloak-oidc-realm-mapper}]}])
    /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory,value=keycloak-mgmt-http-authentication)
    /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade, value={enabled=true, sasl-authentication-factory=management-sasl-authentication})
    
    # Enable RBAC where roles are obtained from the identity
    /core-service=management/access=authorization:write-attribute(name=provider,value=rbac)
    /core-service=management/access=authorization:write-attribute(name=use-identity-roles,value=true)
    
    # Create a secure-server in order to publish the JBoss EAP console configuration via mgmt interface
    /subsystem=keycloak/secure-server=wildfly-console:add(realm=wildfly-infra,resource=wildfly-console,public-client=true)
    
    # reload
    reload
  2. 이 파일에서 REALM_PUBLIC_KEY 를 공개 키 값으로 바꿉니다. 이 값을 얻으려면 Red Hat Single Sign-On 관리 콘솔에 로그인하고 wildfly-infra 영역을 선택하고 Realm SettingsKeys(재설정 → 키 )로 이동하여 공개 키를 클릭합니다.
  3. JBoss EAP 시작.

    $ EAP_HOME/bin/standalone.sh
    중요

    standalone . xml 이외의 구성 파일을 사용하기 위해 Red Hat Single Sign-On 클라이언트 어댑터를 설치할 때 adapter- elytron-install-offline. cli 스크립트를 수정한 경우 해당 구성을 사용하여 JBoss EAP를 시작해야 합니다.

  4. protect-eap-mgmt-services.cli 스크립트를 실행합니다.

    $ EAP_HOME/bin/jboss-cli.sh --connect --file=protect-eap-mgmt-services.cli

이제 http://localhost:9990/console/ 에서 JBoss EAP 관리 콘솔에 액세스하면 Red Hat Single Sign-On으로 리디렉션되어 로그인한 다음 인증에 성공하면 JBoss EAP 관리 콘솔로 다시 리디렉션됩니다.

1.3. 레거시 보안 도메인에 대한 보안 감사 구성

audit 모듈을 사용하여 보안 하위 시스템에서 이벤트를 모니터링할 수 있습니다. 감사에서는 공급자 모듈, 사용자 정의 구현 또는 둘 다를 사용하여 이벤트를 모니터링합니다.

감사 모듈은 이벤트 모니터링 후 로그 파일을 쓰거나, 이메일 알림을 읽거나, 다른 감사 메커니즘을 사용합니다.

관리 콘솔을 사용하여 보안 도메인의 보안 감사 설정을 구성합니다.

절차

  1. Configuration(구성 ) 탭을 클릭합니다.
  2. 하위 시스템보안(Legacy) 으로 이동합니다.
  3. 편집 가능한 보안 도메인을 선택하고 보기를 클릭합니다.
  4. Audit (감사) 탭을 선택하고 Add (추가)를 눌러 새 감사 모듈을 추가합니다.
  5. 모듈의 이름을 설정하고 Code 필드에 provider 모듈의 클래스 이름으로 입력합니다.
  6. 선택 사항: 모듈을 편집하고 모듈 옵션 필드에서 키/값 쌍을 추가하여 모듈 옵션을 추가합니다. Enter를 눌러 새 값을 추가하고 Backspace를 눌러 기존 값을 제거합니다.

1.4. Elytron를 통한 보안 감사

Elytron를 사용하여 트리거 이벤트에 대한 보안 감사를 완료할 수 있습니다. 보안 감사는 권한 부여 또는 인증 시도에 대한 응답으로 로그에 쓰는 등 이벤트를 트리거하는 것을 나타냅니다.

이벤트에서 수행되는 보안 감사 유형은 보안 영역 구성에 따라 다릅니다.

1.4.1. Elytron 감사 로깅

elytron 하위 시스템으로 감사 로깅을 활성화한 후에는 애플리케이션 서버 내에서 Elytron 인증 및 권한 부여 이벤트를 기록할 수 있습니다. Elytron는 사람이 읽을 수 있는 텍스트 형식의 개별 이벤트를 저장하기 위해 JSON 에 감사 로그 항목을 저장합니다.

Elytron 감사 로깅은 JBoss EAP 관리 인터페이스의 감사 로깅과 같은 다른 유형의 감사 로깅과 다릅니다.

Elytron는 기본적으로 감사 로깅을 비활성화합니다. Elytron에 대해 다음 로그 처리기를 구성하여 감사 로깅을 활성화할 수 있습니다. 보안 도메인에 로그 처리기를 추가할 수 있습니다.

  • 파일 감사 로깅
  • 정기적으로 파일 감사 로깅
  • 크기 회전 파일 감사 로깅
  • syslog 감사 로깅
  • 사용자 정의 감사 로깅

aggregate-security-event-listener 리소스 를 사용하여 로거와 같은 추가 대상에 보안 이벤트를 보낼 수 있습니다. aggregate-security-event-listener 리소스 는 집계 리스너 정의에 지정된 모든 리스너에 모든 이벤트를 제공합니다.

audit 모듈을 사용하여 레거시 보안 도메인의 이벤트를 모니터링할 수 있습니다. 관리 콘솔을 사용하여 레거시 보안 도메인의 보안 감사 설정을 구성할 수 있습니다.

추가 리소스

1.4.2. 파일 감사 로깅 활성화

elytron 하위 시스템을 사용하여 독립 실행형 서버 또는 관리형 도메인에서 서버에 대한 파일 감사 로깅을 활성화할 수 있습니다.

파일 감사 로깅은 감사 로그 메시지를 파일 시스템 내의 단일 파일에 저장합니다. 기본적으로 Elytron는 local-audit 를 파일 감사 로거로 지정합니다. 관리형 도메인의 EAP_HOME/standalone/log/audit.log 에 Elytron 감사 로그를 작성할 수 있도록 local- audit 를 활성화해야 합니다.

절차

  1. 파일 감사 로그를 생성합니다.

    elytron 하위 시스템을 사용하여 파일 감사 로그를 생성하는 예:

    /subsystem=elytron/file-audit-log=<audit_log_name>:add(path="<path_to_log_file>", relative-to="<base_for_path_to_log_file>", format=<format_type>, synchronized=<whether_to_log_immediately>)

  2. 파일 감사 로그를 보안 도메인에 추가합니다.

    보안 도메인에 파일 감사 로그를 추가하는 명령의 예

    /subsystem=elytron/security-domain=<security_domain_name>:write-attribute(name=security-event-listener , value=<audit_log_name>)

추가 리소스

1.4.3. 정기적인 순환 파일 감사 로깅 활성화

elytron 하위 시스템을 사용하여 독립 실행형 서버 또는 도메인 도메인의 서버에 대한 주기적 회전 파일 감사 로깅을 활성화할 수 있습니다.

파일 감사 로깅을 정기적으로 순환하면 구성된 일정에 따라 감사 로그 파일이 자동으로 순환됩니다. 주기적인 회전 파일 감사 로깅은 기본 파일 감사 로거와 유사하지만 주기적인 회전 파일 감사 로깅에는 접미사 가 추가로 포함됩니다.

suffix 속성의 값은 java.time.format.DateTimeFormatter 형식(예: .yyy -MM-dd )을 사용하여 지정된 날짜입니다. Elytron는 접미사와 함께 제공되는 값에서 회전 기간을 자동으로 계산합니다. elytron 하위 시스템은 로그 파일 이름 끝에 접미사를 추가합니다.

절차

  1. 주기적인 회전 파일 감사 로그를 생성합니다.

    elytron 하위 시스템에서 주기적인 회전 파일 감사 로그를 생성하는 예

    /subsystem=elytron/periodic-rotating-file-audit-log=<periodic_audit_log_name>:add(path="<periodic_audit_log_filename>", relative-to="<path_to_audit_log_directory>", format=<record_format>, synchronized=<whether_to_log_immediately>,suffix="<suffix_in_DateTimeFormatter_format>")

  2. 주기적인 회전 파일 감사 로거를 보안 도메인에 추가합니다.

    보안 도메인에 정기적인 회전 파일 감사 로거 추가 예

    /subsystem=elytron/security-domain=<security_domain_name>:write-attribute(name=security-event-listener, value=<periodic_audit_log_name>)

추가 리소스

1.4.4. 크기 회전 파일 감사 로깅 활성화

elytron 하위 시스템을 사용하여 독립 실행형 서버 또는 관리형 도메인에서 서버에 대한 크기 회전 파일 감사 로깅을 활성화할 수 있습니다.

크기 회전 파일 감사 로깅은 로그 파일이 구성된 파일 크기에 도달하면 감사 로그 파일을 자동으로 순환합니다. 크기 회전 파일 감사 로깅은 기본 파일 감사 로거와 유사하지만 크기 회전 파일 감사 로깅에는 추가 속성이 포함되어 있습니다.

로그 파일 크기가 rotate-size 특성에 정의된 제한을 초과하면 Elytron는 현재 파일의 끝에 .1 접미사를 추가하고 Elytron은 새 로그 파일을 생성합니다. Elytron는 기존 로그 파일에 대해 접미사를 하나씩 늘립니다. 예를 들어 Elytron renames audit_log.1 의 이름을 audit_log.2 로 변경합니다. Elytron는 로그 파일 양이 max-backup-index 로 정의된 최대 로그 파일 수에 도달할 때까지 증분을 계속합니다. 로그 파일이 max-backup-index 값을 초과하면 Elytron에서 해당 파일을 제거합니다(예: audit_log.99 ).

절차

  1. 크기 회전 파일 감사 로그를 만듭니다.

    elytron 하위 시스템을 사용하여 크기 회전 파일 감사 로그를 생성하는 예:

    /subsystem=elytron/size-rotating-file-audit-log=<audit_log_name>:add(path="<path_to_log_file>",relative-to="<base_for_path_to_log_file>",format=<record_format>,synchronized=<whether_to_log_immediately>,rotate-size="<max_file_size_before_rotation>",max-backup-index=<max_number_of_backup_files>)

  2. 크기 회전 감사 로거를 보안 도메인에 추가합니다.

    elytron 하위 시스템을 사용하여 크기 회전 파일 감사 로그를 활성화하는 예:

    /subsystem=elytron/security-domain=<domain_size_logger>:write-attribute(name=security-event-listener, value=<audit_log_name>)

추가 리소스

1.4.5. syslog 감사 로깅 활성화

elytron 하위 시스템을 사용하여 독립 실행형 서버 또는 관리형 도메인에서 서버에 대한 syslog 감사 로깅을 활성화할 수 있습니다. syslog 감사 로깅을 사용하면 로깅 결과를 syslog 서버로 전송하여 로컬 파일에 로깅하는 것보다 더 많은 보안 옵션을 제공합니다.

syslog 핸들러는 syslog 서버의 호스트 이름 및 syslog 서버가 수신 대기하는 포트와 같이 syslog 서버에 연결하는 데 사용되는 매개변수를 지정합니다. 여러 syslog 핸들러를 정의하고 동시에 활성화할 수 있습니다.

지원되는 로그 형식에는 RFC5424RFC3164 가 포함됩니다. 지원되는 전송 프로토콜에는 UDP, TCP, SSL이 포함된 TCP가 포함됩니다.

첫 번째 인스턴스에 대한 syslog 를 정의할 때 로거는 다음 예에 표시된 대로 메시지를 포함하는 INFORMATIONAL 우선 순위 이벤트를 syslog 서버로 보냅니다.

"Elytron audit logging enabled with RFC format: <format>"

<format> 은 감사 로깅 핸들러에 대해 구성된 RFC 포맷을 참조하며, 기본값은 RFC5424 입니다.

절차

  1. syslog 처리기를 추가합니다.

    elytron 하위 시스템을 사용하여 syslog 핸들러 추가의 예:

    /subsystem=elytron/syslog-audit-log=<syslog_audit_log_name>:add(host-name=<record_host_name>, port=<syslog_server_port_number>, server-address=<syslog_server_address>, format=<record_format>, transport=<transport_layer_protocol>)

    TLS를 통해 syslog 서버에 로그를 보낼 수도 있습니다.

    TLS를 통해 로그를 전송하는 syslog 구성의 예

    /subsystem=elytron/syslog-audit-log=<syslog_audit_log_name>:add(transport=SSL_TCP,server-address=<syslog_server_address>,port=<syslog_server_port_number>,host-name=<record_host_name>,ssl-context=<client_ssl_context>)

  2. syslog 감사 로거를 보안 도메인에 추가합니다.

    보안 도메인에 syslog 감사 로거 추가 예

    /subsystem=elytron/security-domain=<security_domain_name>:write-attribute(name=security-event-listener, value=<syslog_audit_log_name>)

추가 리소스

1.4.6. Elytron에서 사용자 정의 보안 이벤트 리스너 사용

Elytron를 사용하여 사용자 지정 이벤트 리스너를 정의할 수 있습니다. 사용자 지정 이벤트 리스너는 들어오는 보안 이벤트 처리를 관리합니다. 이벤트 리스너를 사용자 정의 감사 로깅 목적으로 사용하거나 이벤트 리스너를 사용하여 내부 ID 스토리지에 대해 사용자를 인증할 수 있습니다.

중요

모듈 관리 CLI 명령을 사용하여 모듈을 추가하고 제거하는 작업은 기술 프리뷰 기능으로만 제공됩니다. 모듈 명령은 관리형 도메인에서 사용하거나 원격 관리 CLI로 연결할 때 적합하지 않습니다. 프로덕션 환경에서 모듈을 수동으로 추가하거나 제거해야 합니다.

기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있으며 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.

절차

  1. java.util.function.Consumer<org.wildfly.security.auth.server.event.SecurityEvent> 인터페이스를 구현하는 클래스를 생성합니다. 예를 들어 다음은 사용자가 인증에 성공하거나 실패할 때마다 메시지를 출력합니다.

    지정된 인터페이스를 사용하는 Java 클래스를 생성하는 예:

    public class MySecurityEventListener implements Consumer<SecurityEvent> {
        public void accept(SecurityEvent securityEvent) {
            if (securityEvent instanceof SecurityAuthenticationSuccessfulEvent) {
                System.err.printf("Authenticated user \"%s\"\n", securityEvent.getSecurityIdentity().getPrincipal());
            } else if (securityEvent instanceof SecurityAuthenticationFailedEvent) {
                System.err.printf("Failed authentication as user \"%s\"\n", ((SecurityAuthenticationFailedEvent)securityEvent).getPrincipal());
            }
        }
    }

    예제의 Java 클래스는 사용자가 인증을 성공하거나 실패할 때마다 메시지를 출력합니다.

  2. 사용자 지정 이벤트 리스너를 JBoss EAP에 모듈로 제공하는 JAR 추가

    다음은 Elytron에 모듈로 사용자 지정 이벤트 리스너를 추가하는 관리 CLI 명령의 예입니다.

    모듈 명령을 사용하여 사용자 지정 이벤트 리스너를 Elytron에 모듈로 추가하는 예:

    /subsystem=elytron/custom-security-event-listener=<listener_name>:add(module=<module_name>, class-name=<class_name>)

  3. 보안 도메인의 사용자 지정 이벤트 리스너를 참조합니다.

    ApplicationDomain 에서 사용자 지정 이벤트 리스너를 참조하는 예:

    /subsystem=elytron/security-domain=<domain_name>:write-attribute(name=security-event-listener, value=<listener_name>)

  4. 서버를 다시 시작합니다.

    $ reload

    이벤트 리스너는 지정된 보안 도메인에서 보안 이벤트를 수신합니다.

추가 리소스

1.5. 애플리케이션을 위한 단방향 및 양방향 SSL/TLS 구성

1.5.1. 애플리케이션을 위한 자체 서명 인증서 자동 생성

레거시 보안 영역을 사용하는 경우 JBoss EAP는 개발을 위해 자체 서명된 인증서를 자동으로 생성합니다.

예제: 자체 서명된 인증서 생성 표시 서버 로그

15:26:09,031 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-7) WFLYDM0111: Keystore /path/to/jboss/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
...
15:26:10,076 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0113: Generated self signed certificate at /path/to/jboss/configuration/application.keystore. Please note that self signed certificates are not secure, and should only be used for testing purposes. Do not use this self signed certificate in production.
SHA-1 fingerprint of the generated key is 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00:11:22:33
SHA-256 fingerprint of the generated key is 00:11:22:33:44:55:66:77:88:99:00:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee
...

이 인증서는 테스트를 위해 생성되며 애플리케이션에서 사용하는 HTTPS 인터페이스에 할당됩니다. HTTPS 인터페이스에 처음 액세스할 때 파일이 없는 경우 인증서가 포함된 키 저장소가 생성됩니다.

예제: 자체 서명 인증서를 사용하는 기본 ApplicationRealm

<security-realm name="ApplicationRealm">
  <server-identities>
    <ssl>
      <keystore path="application.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/>
    </ssl>
  </server-identities>
  ...
</security-realm>

예제: 기본 HTTPS 인터페이스 구성

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
    ...
    <server name="default-server">
        ...
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
        ...

참고

자체 서명된 인증서 생성을 비활성화하려면 서버 키 저장소 구성에서 generate-self-signed-certificate-host="localhost" 를 제거해야 합니다. generate-self-signed-certificate-host 속성에는 자체 서명 인증서가 생성되어야 하는 호스트 이름이 있습니다.

주의

이 자체 서명된 인증서는 테스트 목적으로만 사용할 수 있으며 프로덕션 환경에서 사용하기 위한 것이 아닙니다. Elytron을 사용하는 애플리케이션의 SSL/TLS 구성에 대한 자세한 내용은 Elytron 하위 시스템을 사용하여 애플리케이션에 대한 일방향 SSL/TLS 활성화 및 Elytron Subsystem 섹션을 사용하여 애플리케이션에 대해 양방향 SSL/TLS 활성화를 참조하십시오. 기존 보안을 사용하여 애플리케이션의 SSL/TLS 구성에 대한 자세한 내용은 레거시 보안 Realms를 사용하여 애플리케이션에 대한 일방향 SSL/TLS 활성화 및 레거시 보안 Realms 섹션을 사용하여 애플리케이션의 양방향 SSL/TLS 활성화를 참조하십시오.

1.5.2. Elytron 사용

1.5.2.1. Elytron 하위 시스템을 사용하여 애플리케이션에 대한 일방향 SSL/TLS 활성화

JBoss EAP에서는 JBoss EAP 관리 CLI 또는 관리 콘솔을 사용하여 배포된 애플리케이션에 대해 일방향 SSL/TLS를 활성화할 수 있습니다.

관리 CLI에서는 일방향 SSL/TLS를 다음 두 가지 방법으로 활성화할 수 있습니다.

보안 명령 사용

보안 enable-ssl-http-server 명령을 사용하여 배포된 애플리케이션에 대해 일방향 SSL/TLS를 활성화할 수 있습니다.

예제: 마법사 사용

security enable-ssl-http-server --interactive

Please provide required pieces of information to enable SSL:
Key-store file name (default default-server.keystore): keystore.jks
Password (blank generated): secret
What is your first and last name? [Unknown]: localhost
What is the name of your organizational unit? [Unknown]:
What is the name of your organization? [Unknown]:
What is the name of your City or Locality? [Unknown]:
What is the name of your State or Province? [Unknown]:
What is the two-letter country code for this unit? [Unknown]:
Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct y/n [y]?
Validity (in days, blank default): 365
Alias (blank generated): localhost
Enable SSL Mutual Authentication y/n (blank n): n

SSL options:
key store file: keystore.jks
distinguished name: CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
password: secret
validity: 365
alias: localhost
Server keystore file keystore.jks, certificate file keystore.pem and keystore.csr file
will be generated in server configuration directory.
Do you confirm y/n: y

참고

명령이 실행되면 관리 CLI가 서버를 다시 로드합니다.

애플리케이션에 대해 일방향 SSL/TLS가 활성화됩니다.

Elytron 하위 시스템 명령 사용

JBoss EAP에서 undertow 하위 시스템과 함께 elytron 하위 시스템을 사용하여 배포된 애플리케이션에 대해 일방향 SSL/TLS를 활성화할 수 있습니다.

  1. JBoss EAP 에서 키 저장소 구성.

    /subsystem=elytron/key-store=httpsKS:add(path=/path/to/keystore.jks, credential-reference={clear-text=secret}, type=JKS)

    키 저장소 파일이 아직 없는 경우 다음 명령을 사용하여 예제 키 쌍을 생성할 수 있습니다.

    /subsystem=elytron/key-store=httpsKS:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
    
    /subsystem=elytron/key-store=httpsKS:store()
  2. 저장소를 참조하는 key- manager 를 구성합니다.

    /subsystem=elytron/key-manager=httpsKM:add(key-store=httpsKS,credential-reference={clear-text=secret})
    중요

    Elytron 하위 시스템에서 KeyManagerfactory.getDefaultAlgorithm() 를 사용하여 기본적으로 알고리즘을 결정하므로 이전 명령에서 algorithm을 지정하지 않았습니다. 그러나 알고리즘 특성을 지정할 수 있습니다. 알고리즘 특성을 지정하려면 JDK에서 제공하는 키 관리자 알고리즘이 무엇인지 알아야 합니다. 예를 들어 SunJSSE를 사용하는 JDK는 PKIXSunX509 알고리즘을 제공합니다.

    이전 명령에서 SunX509 를 키 관리자 알고리즘 특성으로 지정할 수 있습니다.

  3. -manager를 참조하는 server-ssl- context 를 구성합니다.

    /subsystem=elytron/server-ssl-context=httpsSSC:add(key-manager=httpsKM, protocols=["TLSv1.2"])
    중요

    지원할 SSL/TLS 프로토콜을 결정해야 합니다. 위의 예제 명령은 TLSv1.2 를 사용합니다. cipher-suite-filter 인수를 사용하여 허용되는 암호화 제품군과 use-cipher-suites-order 인수를 지정하여 서버 암호 제품군 순서를 적용할 수 있습니다. 기본적으로 use-cipher-suites-order 특성은 true 로 설정됩니다. 이는 기본적으로 클라이언트 암호화 제품군 순서를 준수하는 레거시 보안 하위 시스템 동작과 다릅니다.

    주의

    Red Hat은 영향을 받는 모든 패키지에서 TLSv1.1 또는 TLSv1.2를 기반으로 SSLv2, SSLv3 및 TLSv1.0을 명시적으로 비활성화하는 것이 좋습니다.

  4. https-listener 가 SSL 구성에 레거시 보안 영역을 사용하도록 구성되어 있는지 확인합니다.

    /subsystem=undertow/server=default-server/https-listener=https:read-attribute(name=security-realm)
    {
        "outcome" => "success",
        "result" => "ApplicationRealm"
    }

    위의 명령은 https-listener 가 SSL 구성에 ApplicationRealm 레거시 보안 영역을 사용하도록 구성되어 있음을 보여줍니다. Undertow는 Elytron의 레거시 보안 영역과 ssl-context 를 동시에 참조할 수 없으므로 레거시 보안 영역에 대한 참조를 제거해야 합니다.

    참고

    결과가 정의되지 않은 경우 다음 단계에서 보안 영역에 대한 참조를 제거할 필요가 없습니다.

  5. 레거시 보안 영역에 대한 참조를 제거하고 Elytron에서 ssl -context를 사용하도록 https- listener 를 업데이트합니다.

    참고

    HTTPS-listener 에는 항상 security-realm 또는 ssl- context 가 구성되어 있어야 합니다. 두 구성을 변경하는 경우 아래 표시된 대로 명령을 단일 배치로 실행해야 합니다.

    batch
    /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=httpsSSC)
    run-batch
  6. 서버를 다시 로드합니다.

    reload

    애플리케이션에 대해 일방향 SSL/TLS가 활성화됩니다.

참고

disable- ssl-http-server 명령을 사용하여 배포된 애플리케이션의 단방향 SSL/TLS를 비활성화할 수 있습니다.

security disable-ssl-http-server

이 명령은 Elytron 리소스를 삭제하지 않습니다. SSL 구성에 ApplicationRealm 레거시 보안 영역을 사용하도록 시스템을 구성합니다.

관리 콘솔 사용

관리 콘솔에서 SSL 마법사를 사용하여 undertow 하위 시스템을 구성하여 애플리케이션에 대해 SSL을 활성화할 수 있습니다.

마법사에 액세스하려면 다음을 수행합니다.

  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
  2. 구성하위 시스템웹(Undertow) → 서버로 이동합니다.
  3. 구성할 서버의 이름을 클릭합니다.
  4. View(보기 )를 클릭합니다.
  5. 리스너 → HTTPS 리스너 로 이동합니다.
  6. SSL을 활성화할 리스너를 선택하고 Enable SSL (SSL 활성화)을 클릭하여 마법사를 시작합니다.

    마법사는 SSL을 활성화하기 위한 다음 시나리오를 안내합니다.

    • 인증서 저장소를 생성하고 자체 서명된 인증서를 생성하려고 합니다.
    • Let's Encrypt 인증 기관에서 인증서를 가져오고자 합니다.
    • 파일 시스템에 인증서 저장소가 이미 있지만 키 저장소 구성이 없습니다.
    • 유효한 인증서 저장소를 사용하는 키 저장소 구성이 이미 있습니다.

마법사를 사용하여 상호 인증을 위한 신뢰 저장소를 선택적으로 생성할 수 있습니다.

1.5.2.2. Elytron 하위 시스템을 사용하여 애플리케이션에 대한 양방향 SSL/TLS 활성화

  1. 클라이언트 키 저장소를 가져오거나 생성합니다.

    $ keytool -genkeypair -alias client -keyalg RSA -keysize 1024 -validity 365 -keystore client.keystore.jks -dname "CN=client" -keypass secret -storepass secret
  2. 클라이언트 인증서를 내보냅니다.

    keytool -exportcert  -keystore client.keystore.jks -alias client -keypass secret -storepass secret -file /path/to/client.cer
  3. 배포된 애플리케이션에 대해 양방향 SSL/TLS를 활성화합니다.

    JBoss EAP에서 배포된 애플리케이션에 대한 양방향 SSL/TLS는 보안 명령을 사용하거나 elytron 하위 시스템 명령을 사용하여 활성화할 수 있습니다.

    1. 보안 명령 사용.

      보안 enable-ssl-http-server 명령을 사용하여 배포된 애플리케이션에 대해 양방향 SSL/TLS를 활성화할 수 있습니다.

      참고

      다음 예제에서는 신뢰 체인이 없으므로 인증서를 확인하지 않습니다. 신뢰할 수 있는 인증서를 사용하는 경우 문제 없이 클라이언트 인증서를 검증할 수 있습니다.

      예제: 마법사 사용

      security enable-ssl-http-server --interactive
      
      Please provide required pieces of information to enable SSL:
      Key-store file name (default default-server.keystore): server.keystore.jks
      Password (blank generated): secret
      What is your first and last name? [Unknown]: localhost
      What is the name of your organizational unit? [Unknown]:
      What is the name of your organization? [Unknown]:
      What is the name of your City or Locality? [Unknown]:
      What is the name of your State or Province? [Unknown]:
      What is the two-letter country code for this unit? [Unknown]:
      Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct y/n [y]?
      Validity (in days, blank default): 365
      Alias (blank generated): localhost
      Enable SSL Mutual Authentication y/n (blank n): y
      Client certificate (path to pem file): /path/to/client.cer
      Validate certificate y/n (blank y): n
      Trust-store file name (management.truststore): server.truststore.jks
      Password (blank generated): secret
      
      SSL options:
      key store file: server.keystore.jks
      distinguished name: CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
      password: secret
      validity: 365
      alias: localhost
      client certificate: /path/to/client.cer
      trust store file: server.trustore.jks
      trust store password: secret
      Server keystore file server.keystore.jks, certificate file server.pem and server.csr file will be generated in server configuration directory.
      Server truststore file server.trustore.jks will be generated in server configuration directory.
      Do you confirm y/n: y

      참고

      명령이 실행되면 관리 CLI가 서버를 다시 로드합니다.

      양방향 SSL/TLS 인증을 완료하려면 서버 인증서를 클라이언트 신뢰 저장소로 가져오고 클라이언트 인증서를 클라이언트 인증서를 제공하도록 구성해야 합니다.

    2. elytron 하위 시스템 명령 사용.

      JBoss EAP에서 undertow 하위 시스템과 함께 elytron 하위 시스템을 사용하여 배포된 애플리케이션에 대해 양방향 SSL/TLS를 활성화할 수도 있습니다.

      1. 키 저장소를 가져오거나 생성합니다.

        JBoss EAP에서 양방향 SSL/TLS를 활성화하기 전에 사용하려는 키 저장소, 신뢰 저장소 및 인증서를 가져오거나 생성해야 합니다.

        1. 서버 키 저장소를 생성합니다.

          /subsystem=elytron/key-store=twoWayKS:add(path=/PATH/TO/server.keystore.jks,credential-reference={clear-text=secret},type=JKS)
          
          /subsystem=elytron/key-store=twoWayKS:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
          
          /subsystem=elytron/key-store=twoWayKS:store()
          참고

          위의 명령은 키 저장소에 대한 절대 경로를 사용합니다. 또는 relative-to 특성을 사용하여 기본 디렉터리 변수를 지정하고 경로에서 상대 경로를 지정할 수 있습니다.

          /subsystem=elytron/key-store=twoWayKS:add(path=server.keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
        2. 서버 인증서를 내보냅니다.

          /subsystem=elytron/key-store=twoWayKS:export-certificate(alias=localhost,path=/path/to/server.cer,pem=true)
      2. 서버 신뢰 저장소의 키 저장소를 생성하고 클라이언트 인증서를 서버 신뢰 저장소로 가져옵니다.

        참고

        다음 예제에서는 신뢰 체인이 없으므로 인증서를 확인하지 않습니다. 신뢰할 수 있는 인증서를 사용하는 경우 문제 없이 클라이언트 인증서를 검증할 수 있습니다.

        /subsystem=elytron/key-store=twoWayTS:add(path=/path/to/server.truststore.jks,credential-reference={clear-text=secret},type=JKS)
        
        /subsystem=elytron/key-store=twoWayTS:import-certificate(alias=client,path=/path/to/client.cer,credential-reference={clear-text=secret},trust-cacerts=true,validate=false)
        
        /subsystem=elytron/key-store=twoWayTS:store()
      3. 키 저장소 키 저장소를 참조하는 key-manager 구성합니다.

        /subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS, credential-reference={clear-text=secret})
        중요

        Elytron 하위 시스템에서 KeyManagerfactory.getDefaultAlgorithm() 를 사용하여 기본적으로 알고리즘을 결정하므로 이전 명령에서 algorithm을 지정하지 않았습니다. 그러나 알고리즘 특성을 지정할 수 있습니다. 알고리즘 특성을 지정하려면 JDK에서 제공하는 키 관리자 알고리즘이 무엇인지 알아야 합니다.

        예를 들어 SunJSSE 를 사용하는 JDK는 PKIX 및 SunX 509 알고리즘을 제공합니다.

        이전 명령에서 SunX509 를 키 관리자 알고리즘 특성으로 지정할 수 있습니다.

      4. truststore 키 저장소를 참조하는 trust-manager 구성합니다.

        /subsystem=elytron/trust-manager=twoWayTM:add(key-store=twoWayTS)
        중요

        Elytron 하위 시스템에서 TrustManagerfactory.getDefaultAlgorithm() 를 사용하여 기본적으로 알고리즘을 결정하므로 이전 명령에서 algorithm을 지정하지 않았습니다. 그러나 알고리즘 특성을 지정할 수 있습니다. 알고리즘 특성을 지정하려면 JDK에서 제공하는 신뢰 관리자 알고리즘이 무엇인지 알아야 합니다. 예를 들어 SunJSSE 를 사용하는 JDK는 PKIXSunX509 알고리즘을 제공합니다.

        이전 명령에서 PKIX 를 신뢰 관리자 알고리즘 특성으로 지정할 수 있습니다.

      5. -manager,trust-manager 를 참조하고 클라이언트 인증을 활성화하는 server- ssl-context 를 구성합니다.

        /subsystem=elytron/server-ssl-context=twoWaySSC:add(key-manager=twoWayKM, protocols=["TLSv1.2"], trust-manager=twoWayTM, need-client-auth=true)
        중요

        지원할 SSL/TLS 프로토콜을 결정해야 합니다. 위의 예제 명령은 TLSv1.2 를 사용합니다. cipher-suite-filter 인수를 사용하여 허용되는 암호화 제품군과 use-cipher-suites-order 인수를 지정하여 서버 암호 제품군 순서를 적용할 수 있습니다. 기본적으로 use-cipher-suites-order 특성은 true 로 설정됩니다. 이는 기본적으로 클라이언트 암호화 제품군 순서를 준수하는 레거시 보안 하위 시스템 동작과 다릅니다.

        주의

        Red Hat은 영향을 받는 모든 패키지에서 TLSv1.1 또는 TLSv1.2를 기반으로 SSLv2, SSLv3 및 TLSv1.0을 명시적으로 비활성화하는 것이 좋습니다.

      6. https-listener 가 SSL 구성에 레거시 보안 영역을 사용하도록 구성되어 있는지 확인합니다.

        /subsystem=undertow/server=default-server/https-listener=https:read-attribute(name=security-realm)
        {
            "outcome" => "success",
            "result" => "ApplicationRealm"
        }

        위의 명령은 https-listener 가 SSL 구성에 ApplicationRealm 레거시 보안 영역을 사용하도록 구성되어 있음을 보여줍니다. Undertow는 elytron 하위 시스템에서 동시에 레거시 보안 영역과 ssl-context 를 모두 참조할 수 없습니다. 따라서 레거시 보안 영역에 대한 참조를 제거해야 합니다.

        참고

        결과가 정의되지 않은 경우 다음 단계에서 보안 영역에 대한 참조를 제거할 필요가 없습니다.

      7. 레거시 보안 영역에 대한 참조를 제거하고 Elytron에서 ssl -context를 사용하도록 https- listener 를 업데이트합니다.

        참고

        HTTPS-listener 에는 항상 security-realm 또는 ssl- context 가 구성되어 있어야 합니다. 두 구성을 변경하는 경우 아래 표시된 대로 명령을 단일 배치로 실행해야 합니다.

        batch
        /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
        /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=twoWaySSC)
        run-batch
      8. 서버를 다시 로드합니다.

        reload
        참고

        양방향 SSL/TLS 인증을 완료하려면 서버 인증서를 클라이언트 신뢰 저장소로 가져오고 클라이언트 인증서를 클라이언트 인증서를 제공하도록 구성해야 합니다.

        $ keytool -importcert -keystore client.truststore.jks -storepass secret -alias localhost -trustcacerts -file /path/to/server.cer
      9. 클라이언트에서 클라이언트 인증서를 사용하도록 구성합니다.

        양방향 SSL/TLS 인증을 완료하려면 서버에 신뢰할 수 있는 클라이언트 인증서를 제공하도록 클라이언트를 구성해야 합니다. 예를 들어 브라우저를 사용하는 경우 신뢰할 수 있는 인증서를 브라우저의 신뢰 저장소로 가져와야 합니다.

        이 절차에서는 양방향 SSL/TLS를 강제 적용하지만 애플리케이션의 원래 인증 방법을 변경하지 않습니다.

        원래 인증 방법을 변경하려면 JBoss EAP에 대한 ID 관리 구성 방법인증서 구성을 참조하십시오.

양방향 SSL/TLS가 애플리케이션에 대해 활성화됩니다.

참고

disable- ssl-http-server 명령을 사용하여 배포된 애플리케이션에 대해 양방향 SSL/TLS를 비활성화할 수 있습니다.

security disable-ssl-http-server

이 명령은 Elytron 리소스를 삭제하지 않습니다. SSL 구성에 ApplicationRealm 레거시 보안 영역을 사용하도록 시스템을 구성합니다.

1.5.3. Elytron에서 CRL을 사용하여 인증서 폐기 구성

Elytron에서 인증서 해지에 CRL(Certificate Revocation List)을 사용하도록 양방향 SSL/TLS를 활성화하는 데 사용되는 신뢰 관리자를 구성합니다.

사전 요구 사항

  • 신뢰 관리자는 양방향 SSL/TLS를 사용하도록 구성되어 있습니다.
  • 신뢰 관리자에는 해지할 인증서 체인이 포함되어 있습니다.

절차

  1. 인증서에서 참조된 배포 지점에서 얻은 CRL을 사용하도록 신뢰 관리자를 구성합니다.

    /subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=certificate-revocation-list,value={})
  2. 인증서에서 참조된 배포 지점에서 얻은 CRL을 재정의합니다.

    /subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=certificate-revocation-list.path, value=intermediate.crl.pem)
  3. 인증서 취소에 CRL을 사용하도록 trust-manager 를 구성합니다.

    • OCSP 응답자가 인증서 폐기를 위해 구성된 경우 신뢰 관리자에 값 true인 ocsp.prefer-crls 를 추가하여 인증서 취소에 CRL을 사용합니다.

      /subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=ocsp.prefer-crls,value="true")
    • 인증서 취소를 위해 OCSP 응답자가 구성되지 않은 경우 구성이 완료됩니다.

추가 정보

1.5.4. Elytron에서 OCSP를 사용하여 인증 해지 구성

인증서 해지에 OCI(Online Certificate Status Protocol) 응답자를 사용하도록 양방향 SSL/TLS를 활성화하는 데 사용되는 신뢰 관리자를 구성합니다. OCSP는 RFC6960 에서 정의됩니다.

OCSP 응답자와 CRL이 모두 인증서 취소를 위해 구성되면 기본적으로 OCSP 응답자가 호출됩니다.

사전 요구 사항

  • 신뢰 관리자는 양방향 SSL/TLS를 사용하도록 구성되어 있습니다.

절차

  1. 인증서 취소를 위해 인증서 취소를 위해 인증서에 정의된 OCSP 응답자를 사용하도록 신뢰 관리자를 구성합니다.

    /subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=ocsp,value={})
  2. 인증서에 정의된 OCSP 응답자를 재정의합니다.

    /subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=ocsp.responder,value="http://example.com/ocsp-responder")

추가 정보

1.5.5. 레거시 보안 영역 사용

중요

전제 조건으로 SSL/TLS 암호화 키와 인증서를 만들어 액세스 가능한 디렉터리에 배치해야 합니다. 또한 원하는 암호화 제품군과 키 저장소 별칭과 같은 관련 정보에 액세스할 수 있어야 합니다. SSL/TLS 키 및 인증서 생성에 대한 예는 관리 인터페이스 설정 섹션의 처음 두 단계를 참조하십시오. 암호화 제품군을 비롯한 HTTPS 리스너에 대한 자세한 내용은 HTTPS 리스너 참조 섹션을 참조하십시오.

1.5.5.1. 레거시 보안 Realms를 사용하여 애플리케이션에 대한 단방향 SSL/TLS 활성화

이 예제에서는 키 저장소 identity.jks 가 서버 구성 디렉터리에 복사되고 지정된 속성으로 구성되었다고 가정합니다. 관리자는 예제에 대해 자체 값을 대체해야 합니다.

참고

표시된 관리 CLI 명령은 JBoss EAP 독립 실행형 서버를 실행 중이라고 가정합니다. JBoss EAP 관리형 도메인의 관리 CLI 사용에 대한 자세한 내용은 JBoss EAP 관리 CLI 가이드를 참조하십시오.

  1. 먼저 HTTPS 보안 영역을 추가하고 구성합니다. HTTPS 보안 영역을 구성하고 나면 보안 영역을 참조하는 undertow 하위 시스템에서 https-listener 를 구성합니다.

    batch
    
    /core-service=management/security-realm=HTTPSRealm:add
    
    /core-service=management/security-realm=HTTPSRealm/server-identity=ssl:add(keystore-path=identity.jks, keystore-relative-to=jboss.server.config.dir, keystore-password=password1, alias=appserver)
    
    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=security-realm, value=HTTPSRealm)
    
    run-batch
    주의

    Red Hat은 영향을 받는 모든 패키지에서 TLSv1.1 또는 TLSv1.2를 기반으로 SSLv2, SSLv3 및 TLSv1.0을 명시적으로 비활성화하는 것이 좋습니다.

  2. 변경 사항을 적용하려면 JBoss EAP 인스턴스를 다시 시작하십시오.

1.5.5.2. 레거시 보안 Realms를 사용하여 애플리케이션의 양방향 SSL/TLS 활성화

애플리케이션의 양방향 SSL/TLS 설정은 관리 인터페이스의 양방향 SSL/TLS 설정에 설명된 것과 동일한 많은 절차를 따릅니다. 애플리케이션을 위한 양방향 SSL/TLS를 설정하려면 다음을 수행해야 합니다.

  1. 클라이언트 및 서버 모두에 대한 저장소 생성
  2. 클라이언트 및 서버 둘 다에 대한 인증서를 내보냅니다.
  3. 인증서를 opposing truststores로 가져옵니다.
  4. 서버의 키 저장소 및 신뢰 저장소를 사용하는 서버에서 CertificateRealm 과 같은 보안 영역을 정의합니다.
  5. 보안 영역을 사용하고 클라이언트 확인이 필요하도록 undertow 하위 시스템을 업데이트합니다.

처음 4단계는 관리 인터페이스의 양방향 SSL/TLS 설정에서 다룹니다.

중요

새 보안 영역을 추가한 이후 서버가 다시 로드되지 않은 경우 다음 단계를 수행하기 전에 서버를 다시 로드해야 합니다.

Undertow 하위 시스템 업데이트

키 저장소, 인증서, 신뢰 저장소 및 보안 영역을 생성하고 구성한 후 undertow 하위 시스템에 HTTPS 리스너를 추가하고 생성한 보안 영역을 사용하며 클라이언트 확인이 필요합니다.

/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=security-realm, value=CertificateRealm)

/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=verify-client, value=REQUIRED)
중요

이러한 변경 사항을 적용하려면 서버를 다시 로드해야 합니다.

중요

애플리케이션에 대해 양방향 SSL/TLS를 사용하여 JBoss EAP 인스턴스에 연결하는 클라이언트는 클라이언트 인증서 또는 키 저장소에 액세스할 수 있어야 합니다. 즉, 인증서가 서버의 신뢰 저장소에 포함된 클라이언트 키 저장소입니다. 클라이언트가 브라우저를 사용하여 JBoss EAP 인스턴스에 연결하는 경우 해당 인증서 또는 키 저장소를 브라우저의 인증서 관리자로 가져와야 합니다.

참고

애플리케이션과의 양방향 SSL/TLS 외에도 애플리케이션에서 인증서 기반 인증을 사용하는 방법에 대한 자세한 내용은 JBoss EAP How to Configure Identity Management Guide 의 인증서 기반 인증 구성 섹션에서 확인할 수 있습니다.

1.6. CLI 보안 명령을 사용하여 애플리케이션에 대해 HTTP 인증 활성화

JBoss EAP에서 elytron HTTP 인증 팩토리를 사용하는 HTTP 인증은 보안 enable-http-auth-http-server 명령을 사용하여 undertow 보안 도메인에 대해 활성화할 수 있습니다. 기본적으로 이 명령은 애플리케이션 HTTP 팩토리를 지정된 보안 도메인에 연결합니다.

예제: Undertow 보안 도메인에서 HTTP 인증 활성화

security enable-http-auth-http-server --security-domain=SECURITY_DOMAIN

Server reloaded.
Command success.
Authentication configured for security domain SECURITY_DOMAIN
http authentication-factory=application-http-authentication
security-domain=SECURITY_DOMAIN

참고

명령이 실행되면 관리 CLI가 서버를 다시 로드하고 다시 연결합니다.

HTTP 팩토리가 이미 있는 경우 --mechanism 인수에서 정의한 메커니즘을 사용하도록 팩토리가 업데이트됩니다.

1.6.1. 관리 인터페이스에 대한 HTTP 인증 비활성화

다음 절차에서는 관리 인터페이스에 대해 HTTP 인증을 비활성화하는 방법을 설명합니다.

절차

  • 활성 HTTP 인증 팩토리를 제거하려면 다음 명령을 사용합니다.

    security disable-http-auth-http-server --security-domain=SECURITY_DOMAIN
  • 또는 다음 명령을 사용하여 활성 SASL 인증 팩토리에서 특정 메커니즘을 제거할 수 있습니다.

    security disable-http-auth-http-server --mechanism=MECHANISM --security-domain=SECURITY_DOMAIN

1.7. SASL 인증 메커니즘

SASL(Simple Authentication and Security Layer) 인증 메커니즘은 elytron 하위 시스템을 사용하여 JBoss EAP 서버에 대한 연결을 인증하고 서버에 연결하는 클라이언트의 메커니즘을 정의하는 데 사용됩니다. 클라이언트는 다른 JBoss EAP 인스턴스 또는 Elytron 클라이언트일 수 있습니다. JBoss EAP의 SASL 인증 메커니즘은 제거 하위 시스템과의 Elytron 통합 에서도 널리 사용됩니다.

1.7.1. SASL 인증 메커니즘 선택

참고

JBoss EAP와 Elytron Client는 다양한 SASL 인증 메커니즘을 사용하여 작업하지만 사용하는 메커니즘이 지원되는지 확인해야 합니다. SASL 인증 메커니즘에 대한 지원 수준 목록은 이 목록을 참조하십시오.

사용하는 인증 메커니즘은 사용자 환경과 원하는 인증 방법에 따라 다릅니다. 다음 목록은 지원되는 SASL 인증 메커니즘 의 사용을 요약합니다.

익명
인증되지 않은 게스트 액세스.
DIGEST-MD5
SASL 메커니즘으로 HTTP 다이제스트 인증을 사용합니다.
EXTERNAL
요청 컨텍스트에 암시되는 인증 자격 증명을 사용합니다. 예를 들면 IPsec 또는 TLS 인증입니다.
제1의 메커니즘으로 시작하는 메커니즘
Kerberos를 사용한 인증.
JBOSS-LOCAL-USER
클라이언트에 JBoss EAP 서버를 실행 중인 로컬 사용자와 동일한 파일 액세스 권한이 있음을 테스트하여 인증을 제공합니다. 이는 동일한 시스템에서 실행되는 다른 JBoss EAP 인스턴스에 유용합니다.
OAUTHBEARER
OAuth에서 SASL 메커니즘으로 제공하는 인증을 사용합니다.
PLAIN
일반 텍스트 사용자 이름 및 암호 인증.
SCRAM시작 메커니즘
지정된 해시 기능을 사용하는 SCRAM(Salted Challenge Response Authentication Mechanism).
으로 끝나는 메커니즘
특정 인증 메커니즘의 채널 바인딩 변형을 나타냅니다. 기본 연결에서 SSL/TLS를 사용하는 경우 이러한 변형을 사용해야 합니다.

개별 SASL 인증 메커니즘에 대한 자세한 내용은 IANA SASL 메커니즘 목록 및 개별 메커니즘 메모를 참조하십시오.

1.7.2. 서버측에서 SASL 인증 메커니즘 구성

서버측에 SASL 인증 메커니즘을 구성하는 작업은 SASL 인증 팩토리를 사용하여 수행됩니다.

다음과 같은 두 가지 구성이 필요합니다.

  • 인증 메커니즘을 지정하는 A sasl-authentication-factory.
  • 하나 이상의 of sasl- authentication-factory를 집계하고 메커니즘 속성을 구성하는 구성 가능한-sasl-server -factory 는 특정 인증 메커니즘을 활성화 또는 비활성화하기 위해 선택적으로 필터를 적용하는 것입니다.

다음 예제에서는 애플리케이션 클라이언트의 SASL 인증 메커니즘으로 DIGEST -MD5를 사용하는 구성 가능 -sasl-server-factory 및 asasl-authentication -factory를 생성하는 방법을 보여줍니다.

/subsystem=elytron/configurable-sasl-server-factory=mySASLServerFactory:add(sasl-server-factory=elytron)

/subsystem=elytron/sasl-authentication-factory=mySASLAuthFactory:add(sasl-server-factory=mySASLServerFactory,security-domain=ApplicationDomain,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=ApplicationRealm}]}])

1.7.3. 클라이언트측에서 SASL 인증 메커니즘 지정

클라이언트에서 사용하는 SASL 인증 메커니즘은 a sasl-mechanism-selector 를 사용하여 지정합니다. 클라이언트가 연결하는 서버가 노출하는 지원되는 SASL 인증 메커니즘을 지정할 수 있습니다.

A sasl-mechanism-selector 는 인증이 구성된 Elytron 구성에서 정의됩니다.

  • elytron 하위 시스템에서는 인증 구성의 속성입니다. 예를 들면 다음과 같습니다.

    /subsystem=elytron/authentication-configuration=myAuthConfig:write-attribute(name=sasl-mechanism-selector,value="DIGEST-MD5")

    sasl-mechanism-selector 와 함께 authentication-configuration 을 사용하는 예는 Configuring SSL 또는 TLS with elytron 에서 확인할 수 있습니다.

  • Elytron Client의 경우 클라이언트 구성 파일의 authentication -configurations 구성 요소(일반적으로 named wildfly-config.xml )에 지정됩니다. 예를 들면 다음과 같습니다.

    <configuration>
      <authentication-client xmlns="urn:elytron:client:1.2">
        <authentication-rules>
          <rule use-configuration="default" />
        </authentication-rules>
        <authentication-configurations>
          <configuration name="default">
            <sasl-mechanism-selector selector="#ALL" />
          ...
          </configuration>
        </authentication-configurations>
      </authentication-client>
    </configuration>

Elytron Client 를 사용한 클라이언트 인증 구성에 대한 자세한 내용은 ID 관리 구성 방법을 참조하십시오.

SASL-mechanism-selector Grammar

selector 문자열 for sasl-mechanism-selector 에는 특정 항목이 있습니다.

간단한 형식의 개별 메커니즘은 이름을 공백으로 구분하여 순서대로 나열하여 지정합니다. 예를 들어 DIGEST-MD5, SCRAM-SHA-1 및 SCRAM-SHA-256을 허용된 인증 메커니즘으로 지정하려면 다음 문자열을 사용합니다. DIGEST-MD5 SCRAM-SHA-1 SCRAM-SHA-256.

보다 고급 사용으로 다음과 같은 특수 토큰을 사용할 수 있습니다.

  • #ALL: 모든 메커니즘.
  • #FAMILY(이름): 지정된 메커니즘 제품군에 속하는 메커니즘. 예를 들어, 이 제품군은 DIGEST, EAP,œ2, SCRAM, or-ISO-9798일 수 있습니다.
  • #PLUS: 채널 바인딩을 사용하는 메커니즘입니다. 예를 들어, SCRAM-SHA-XXX- 또는œ2-XXX- 이며.
  • #MUTUAL: 서버를 인증하는 메커니즘(예: 서버가 암호를 알고 있음을 입증하는 경우). #MUTUAL에는 # FAMILY (SCRAM) 및 #FAMILY( GS2) 와 같은 제품군이 포함됩니다.
  • #HASH(ALGORITHM): 지정된 해시 알고리즘을 사용하는 메커니즘입니다. 예를 들어 알고리즘은 MD5, SHA-1, SHA-256, SHA-384 또는 SHA-512일 수 있습니다.

위의 토큰과 이름을 다음 작업 및 서술자와 함께 사용할 수도 있습니다.

  • -: forbids
  • !: Inverts
  • &&: 및
  • ||: 또는
  • ==: 같음
  • ?: if
  • #TLS: TLS가 활성 상태일 때 참입니다. 그렇지 않으면 false입니다.

다음은 몇 가지 예제입니다 . 메커니즘 선택자 문자열 및 의미는 다음과 같습니다.

  • #TLS && !#MUTUAL: TLS가 활성화되면 상호 인증이 없는 모든 메커니즘입니다.
  • #ALL -익명: ANONYMOUS를 제외한 모든 메커니즘.
  • SCRAM-SHA-1 SCRAM-SHA-256: 이러한 두 메커니즘을 순서대로 추가합니다.
  • (SCRAM-SHA-1 || SCRAM-SHA-256): 두 메커니즘을 프로바이더 또는 서버에서 표시하는 순서대로 추가합니다.
  • !#HASH(MD5): MD5 해싱 알고리즘을 사용하지 않는 메커니즘입니다.
  • #FAMILY(DIGEST): 모든 다이제스트 메커니즘.

1.7.4. SASL 인증 메커니즘 속성 구성

서버 측과 클라이언트 측 모두에서 인증 메커니즘 속성을 구성할 수 있습니다.

  • 서버 측에서는 구성 가능-sasl-server-factory 에서 인증 메커니즘 속성을 정의합니다. 다음 예제에서는 값이 falsecom.sun.security.sasl.digest.utf8 속성을 정의합니다.

    /subsystem=elytron/configurable-sasl-server-factory=mySASLServerFactory:map-put(name=properties,key=com.sun.security.sasl.digest.utf8,value=false)
  • 클라이언트 측에서는 클라이언트의 인증 구성에서 인증 메커니즘 속성을 정의합니다.

    • elytron 하위 시스템에서 인증 구성에서 인증 메커니즘 속성을 정의합니다. 다음 예제에서는 값이 truewildfly.sasl.local-user.quiet-auth 속성을 정의합니다.

      /subsystem=elytron/authentication-configuration=myAuthConfig:map-put(name=mechanism-properties,key=wildfly.sasl.local-user.quiet-auth,value=true)
    • Elytron Client의 경우 인증 메커니즘 속성은 클라이언트 구성 파일의 authentication-configurations 구성 요소(일반적으로 named wildfly-config.xml )에 지정됩니다. 예를 들면 다음과 같습니다.

      ...
      <authentication-configurations>
        <configuration name="default">
          <sasl-mechanism-selector selector="#ALL" />
          <set-mechanism-properties>
            <property key="wildfly.sasl.local-user.quiet-auth" value="true" />
          </set-mechanism-properties>
          ...
        </configuration>
      </authentication-configurations>
      ...

Java 설명서에서 표준 Java SASL 인증 메커니즘 속성 목록을 확인할 수 있습니다. 다른 JBoss EAP 특정 SASL 인증 메커니즘 속성은 인증 메커니즘 참조 에 나열되어 있습니다.

1.8. ModCluster 하위 시스템과 Elytron 통합

elytron 하위 시스템에서 노출하는 보안 기능 중 하나는 SSL/TLS를 사용하여 로드 밸런서 장치와 통신하도록 modcluster 하위 시스템을 구성하는 데 사용할 수 있는 클라이언트 ssl-context 입니다.

애플리케이션 서버와 로드 밸런서 간의 통신을 보호할 때 다음과 같이 클라이언트 ssl-context 를 정의해야 합니다.

  • 로드 밸런서의 인증서를 검증하는 데 사용할 인증서 체인을 포함하는 신뢰 저장소를 정의합니다.
  • 로드 밸런서 인증서에 대한 검증을 수행하도록 신뢰 관리자를 정의합니다.

1.8.1. 클라이언트 SSL 컨텍스트 정의 및 ModCluster 하위 시스템 구성

다음 절차에 따라 truststore 및 trust manager를 구성해야 합니다. 이러한 생성에 대한 자세한 내용은 Create an Elytron Truststore and Create an Elytron Trust Manager 에서 참조하십시오.

  1. 클라이언트 SSL 컨텍스트를 만듭니다.

    이 SSL 컨텍스트는 SSL/TLS를 사용하여 로드 밸런서에 연결할 때 modcluster 하위 시스템에서 사용합니다.

    /subsystem=elytron/client-ssl-context=modcluster-client-ssl-context:add(trust-manager=default-trust-manager)
  2. 다음 옵션 중 하나를 사용하여 새로 생성된 클라이언트 SSL 컨텍스트를 참조합니다.

    • ssl-context 를 설정하여 modcluster 하위 시스템을 구성합니다.

      /subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=ssl-context, value=modcluster-client-ssl-context)
    • mod-cluster 필터의 ssl-context 특성을 정의하여 undertow 하위 시스템을 구성합니다.

      /subsystem=undertow/configuration=filter/mod-cluster=modcluster:write-attribute(name=ssl-context,value=modcluster-client-ssl-context)
  3. 서버를 다시 로드합니다.

    reload

modcluster 하위 시스템을 구성하고 신뢰 관리자와 함께 양방향 인증을 사용하려면 키 관리자도 구성해야 합니다.

  1. 키 저장소를 생성합니다.

    /subsystem=elytron/key-store=twoWayKS:add(path=/path/to/client.keystore.jks, credential-reference={clear-text=secret},type=JKS)
  2. 키 관리자를 구성합니다.

    /subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS, algorithm="SunX509", credential-reference={clear-text=secret})
  3. 클라이언트 SSL 컨텍스트를 만듭니다.

    /subsystem=elytron/client-ssl-context=modcluster-client-ssl-context:add(trust-manager=default-trust-manager, key-manager=twoWayKM)
    참고

    기존 클라이언트 SSL 컨텍스트가 이미 있는 경우 다음과 같이 key-manager 를 추가할 수 있습니다.

    /subsystem=elytron/client-ssl-context=modcluster-client-ssl-context:write-attribute(name=key-manager, value=twoWayKM)
  4. 서버를 다시 로드합니다.

    reload

1.9. JGroups 하위 시스템과 Elytron 통합

jgroups 하위 시스템에서 권한 또는 암호화 프로토콜을 정의할 때 elytron 하위 시스템의 구성 요소를 참조할 수 있습니다. 이러한 프로토콜 구성에 대한 전체 지침은 구성 가이드클러스터 보안 섹션에서 확인할 수 있습니다.

1.10. Remoting Subsystem과의 Elytron 통합

1.10.1. 원격 커넥터와의 Elytron 통합

원격 커넥터는 SASL 인증 팩토리, 소켓 바인딩 및 선택적 SSL 컨텍스트에서 지정합니다. 특히 커넥터의 특성은 다음과 같습니다.

sasl-authentication-factory
이 커넥터에 대한 요청을 인증하는 데 사용할 SASL 인증 팩토리에 대한 참조입니다. 이 팩토리 생성에 대한 자세한 내용은 Create an Elytron Authentication 팩토리 를 참조하십시오.
socket-binding
소켓 바인딩에 대한 참조로, 커넥터가 들어오는 요청을 수신 대기해야 하는 인터페이스 및 포트를 자세히 설명합니다.
ssl-context
이 커넥터에 사용할 서버 측 SSL 컨텍스트에 대한 선택적 참조입니다. SSL 컨텍스트에는 사용할 서버 키 관리자와 신뢰 관리자가 포함되어 있으며, SSL이 필요한 인스턴스에 정의해야 합니다.

예를 들어 커넥터는 다음과 같이 추가할 수 있습니다. 여기서 SASL_FACTORY_NAME 은 이미 정의된 인증 팩토리이고 SOCKET_BINDING_NAME 은 기존 소켓 바인딩입니다.

/subsystem=remoting/connector=CONNECTOR_NAME:add(sasl-authentication-factory=SASL_FACTORY_NAME,socket-binding=SOCKET_BINDING_NAME)

SSL이 필요한 경우 아래 표시된 대로 ssl -context 특성을 사용하여 사전 구성된 server-ssl -context 를 참조할 수 있습니다.

/subsystem=remoting/connector=CONNECTOR_NAME:add(sasl-authentication-factory=SASL_FACTORY_NAME,socket-binding=SOCKET_BINDING_NAME,ssl-context=SSL_CONTEXT_NAME)

1.10.1.1. elytron 하위 시스템을 사용하여 커넥터 원격에 단방향 SSL/TLS 활성화

다음 SASL 메커니즘은 SSL/TLS와 같은 외부 보안 채널에 대한 채널 바인딩을 지원합니다.

  • GS2-KRB5-PLUS
  • SCRAM-SHA-1-PLUS
  • SCRAM-SHA-256-PLUS
  • SCRAM-SHA-384-PLUS
  • SCRAM-SHA-512-PLUS

이러한 메커니즘 중 하나를 사용하려면 사용자 지정 SASL 팩토리를 구성하거나 미리 정의된 SASL 인증 팩토리 중 하나를 수정할 수 있습니다. 클라이언트에서 SASL 메커니즘 선택기 를 사용하여 적절한 SASL 메커니즘을 지정할 수 있습니다.

사전 요구 사항

  • 키 저장소가 구성됩니다.
  • key-manager 가 구성되어 있습니다.
  • 정의된 key -manager를 참조하도록 server-ssl- context가 구성되어 있습니다.

절차

  1. 커넥터에 대한 소켓 바인딩 을 만듭니다. 다음 명령은 포트 11199 에서 수신 대기하는 oneWayBinding 바인딩을 정의합니다.

    /socket-binding-group=standard-sockets/socket-binding=oneWayBinding:add(port=11199)
  2. SASL 인증 팩토리, 이전에 생성한 소켓 바인딩 및 SSL 컨텍스트를 참조하는 커넥터를 만듭니다.

    /subsystem=remoting/connector=oneWayConnector:add(sasl-authentication-factory=SASL_FACTORY,socket-binding=oneWayBinding,ssl-context=SSL_CONTEXT)
    중요

    보안 영역과 ssl-context가 모두 정의된 경우 JBoss EAP는 ssl -context 에서 제공하는 SSL/TLS 구성을 사용합니다 .

  3. 서버 인증서를 신뢰하도록 클라이언트를 구성합니다. 일반 예제 클라이언트는 Elytron 클라이언트 사이드 1 방식 예제에서 찾을 수 있습니다. 이 예제에서는 클라이언트 trust -store를 사용하여 ssl- context 를 구성합니다.

1.10.1.2. elytron 하위 시스템을 사용하여 커넥터 원격에 양방향 SSL/TLS 활성화

다음 SASL 메커니즘은 SSL/TLS와 같은 외부 보안 채널에 대한 채널 바인딩을 지원합니다.

  • GS2-KRB5-PLUS
  • SCRAM-SHA-1-PLUS
  • SCRAM-SHA-256-PLUS
  • SCRAM-SHA-384-PLUS
  • SCRAM-SHA-512-PLUS

이러한 메커니즘을 사용하려면 사용자 지정 SASL 팩토리를 구성하거나 미리 정의된 SASL 인증 팩토리 중 하나를 수정하여 이러한 메커니즘을 제공할 수 있습니다. 클라이언트에서 SASL 메커니즘 선택기를 사용하여 적절한 SASL 메커니즘을 지정할 수 있습니다.

사전 요구 사항

  • 클라이언트 및 서버 인증서에 대한 별도의 키 저장소 구성 요소가 구성됩니다.
  • 서버 저장소의 key- manager 가 구성됩니다.
  • 서버 신뢰 저장소의 trust- manager 가 구성됩니다.
  • 정의된 key -manager 및 trust-manager를 참조하는 server- ssl-context 가 구성되어 있습니다.

절차

  1. 커넥터에 대한 소켓 바인딩 을 만듭니다. 다음 명령은 포트 11199 에서 수신 대기하는 twoWayBinding 바인딩을 정의합니다.

    /socket-binding-group=standard-sockets/socket-binding=twoWayBinding:add(port=11199)
  2. SASL 인증 팩토리, 이전에 생성한 소켓 바인딩 및 SSL 컨텍스트를 참조하는 커넥터를 만듭니다.

    /subsystem=remoting/connector=twoWayConnector:add(sasl-authentication-factory=SASL_FACTORY,socket-binding=twoWayBinding,ssl-context=SSL_CONTEXT)
    중요

    보안 영역과 ssl-context가 모두 정의된 경우 JBoss EAP는 ssl -context 에서 제공하는 SSL/TLS 구성을 사용합니다 .

  3. 서버 인증서를 신뢰하고 서버에 인증서를 제공하도록 클라이언트를 구성합니다.

    양방향 SSL/TLS 인증을 완료하려면 서버에 신뢰할 수 있는 클라이언트 인증서를 제공하도록 클라이언트를 구성해야 합니다. 예를 들어 브라우저를 사용하는 경우 신뢰할 수 있는 인증서를 브라우저의 트러스트 저장소로 가져와야 합니다. 일반 예제 클라이언트는 Elytron 클라이언트 사이드 방식 예에서 확인할 수 있습니다. 이 예제에서는 클라이언트 trust -store키 저장소를 사용하여 ssl-context 구성합니다.

리모팅 커넥터에서 양방향 SSL/TLS가 활성화됩니다.

1.10.2. HTTP 커넥터 원격와의 Elytron 통합

원격 HTTP 연결은 elytron 하위 시스템에서 커넥터와 elytron 하위 시스템에 정의된 SASL 인증 팩토리를 참조하여 지정합니다. HTTP 커넥터는 HTTP 업그레이드 기반 원격 커넥터에 대한 구성을 제공하고 connector-ref 특성에서 지정하는 HTTP 리스너에 연결합니다.

http-connector 의 속성은 다음과 같습니다.

connector-ref
사전 정의된 undertow 리스너에 대한 참조입니다.
sasl-authentication-factory
이 커넥터에 대한 요청을 인증하는 데 사용할 SASL 인증 팩토리에 대한 참조입니다. 이 팩토리 생성에 대한 자세한 내용은 Create an Elytron Authentication 팩토리 를 참조하십시오.

예를 들어, http-connector 를 다음과 같이 추가할 수 있습니다. 여기서 CONNECTOR_NAMEundertow 리스너를 참조하고 SASL_FACTORY_NAMEelytron 하위 시스템에서 이미 정의된 인증 팩토리입니다.

/subsystem=remoting/http-connector=HTTP_CONNECTOR_NAME:add(connector-ref=CONNECTOR_NAME,sasl-authentication-factory=SASL_FACTORY_NAME)

1.10.2.1. 원격 HTTP 커넥터에서 일방향 SSL 활성화

다음 SASL 메커니즘은 SSL/TLS와 같은 외부 보안 채널에 대한 채널 바인딩을 지원합니다.

  • GS2-KRB5-PLUS
  • SCRAM-SHA-1-PLUS
  • SCRAM-SHA-256-PLUS
  • SCRAM-SHA-384-PLUS
  • SCRAM-SHA-512-PLUS

위의 메커니즘 중 하나를 사용하기 위해 사용자 지정 SASL 팩토리를 구성하거나 사전 정의된 SASL 인증 팩토리 중 하나를 수정하여 이러한 메커니즘을 제공할 수 있습니다. 클라이언트에서 SASL 메커니즘 선택기 를 사용하여 적절한 SASL 메커니즘을 지정할 수 있습니다.

사전 요구 사항

절차

  1. https-listener 가 SSL 구성에 레거시 보안 영역을 사용하도록 구성되어 있는지 확인합니다.

    /subsystem=undertow/server=default-server/https-listener=https:read-attribute(name=security-realm)
    {
        "outcome" => "success",
        "result" => "ApplicationRealm"
    }

    위의 명령은 https-listener 가 SSL 구성에 ApplicationRealm 레거시 보안 영역을 사용하도록 구성되어 있음을 보여줍니다. Undertow는 Elytron의 레거시 보안 영역과 ssl-context 를 동시에 참조할 수 없으므로 레거시 보안 영역에 대한 참조를 제거해야 합니다.

    참고

    결과가 정의되지 않은 경우 다음 단계에서 보안 영역에 대한 참조를 제거할 필요가 없습니다.

  2. 레거시 보안 영역에 대한 참조를 제거하고 Elytron에서 ssl -context를 사용하도록 https- listener 를 업데이트합니다.

    참고

    HTTPS-listener 에는 항상 security-realm 또는 ssl- context 가 구성되어 있어야 합니다. 두 구성을 변경하는 경우 아래 표시된 대로 명령을 단일 배치로 실행해야 합니다.

    batch
    /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=SERVER_SSL_CONTEXT)
    run-batch
  3. HTTPS 리스너 및 SASL 인증 팩토리를 참조하는 HTTP 커넥터를 만듭니다.

    /subsystem=remoting/http-connector=ssl-http-connector:add(connector-ref=https,sasl-authentication-factory=SASL_FACTORY)
  4. 서버를 다시 로드합니다.

    reload
  5. 서버 인증서를 신뢰하도록 클라이언트를 구성합니다. 예를 들어 브라우저를 사용하는 경우 신뢰할 수 있는 인증서를 브라우저의 트러스트 저장소로 가져와야 합니다.

1.10.2.2. 원격 HTTP 커넥터에서 양방향 SSL/TLS 활성화

다음 SASL 메커니즘은 SSL/TLS와 같은 외부 보안 채널에 대한 채널 바인딩을 지원합니다.

  • GS2-KRB5-PLUS
  • SCRAM-SHA-1-PLUS
  • SCRAM-SHA-256-PLUS
  • SCRAM-SHA-384-PLUS
  • SCRAM-SHA-512-PLUS

위의 메커니즘 중 하나를 사용하기 위해 사용자 지정 SASL 팩토리를 구성하거나 사전 정의된 SASL 인증 팩토리 중 하나를 수정하여 이러한 메커니즘을 제공할 수 있습니다. 클라이언트에서 SASL 메커니즘 선택기 를 사용하여 적절한 SASL 메커니즘을 지정할 수 있습니다.

사전 요구 사항

절차

  1. https-listener 가 SSL 구성에 레거시 보안 영역을 사용하도록 구성되어 있는지 확인합니다.

    /subsystem=undertow/server=default-server/https-listener=https:read-attribute(name=security-realm)
    {
        "outcome" => "success",
        "result" => "ApplicationRealm"
    }

    위의 명령은 https-listener 가 SSL 구성에 ApplicationRealm 레거시 보안 영역을 사용하도록 구성되어 있음을 보여줍니다. Undertow는 Elytron의 레거시 보안 영역과 ssl-context 를 동시에 참조할 수 없으므로 레거시 보안 영역에 대한 참조를 제거해야 합니다.

    참고

    결과가 정의되지 않은 경우 다음 단계에서 보안 영역에 대한 참조를 제거할 필요가 없습니다.

  2. 레거시 보안 영역에 대한 참조를 제거하고 Elytron에서 ssl -context를 사용하도록 https- listener 를 업데이트합니다.

    참고

    HTTPS-listener 에는 항상 security-realm 또는 ssl- context 가 구성되어 있어야 합니다. 두 구성을 변경하는 경우 아래 표시된 대로 명령을 단일 배치로 실행해야 합니다.

    batch
    /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=SERVER_SSL_CONTEXT)
    run-batch
  3. HTTPS 리스너 및 SASL 인증 팩토리를 참조하는 HTTP 커넥터를 만듭니다.

    /subsystem=remoting/http-connector=ssl-http-connector:add(connector-ref=https,sasl-authentication-factory=SASL_FACTORY)
  4. 서버를 다시 로드합니다.

    reload
  5. 서버 인증서를 신뢰하고 서버에 인증서를 제공하도록 클라이언트를 구성합니다.

    신뢰할 수 있는 클라이언트 인증서를 서버에 제공하도록 클라이언트를 구성하여 양방향 SSL/TLS 인증을 완료합니다. 예를 들어 브라우저를 사용하는 경우 신뢰할 수 있는 인증서를 브라우저의 트러스트 저장소로 가져와야 합니다.

이제 remoting HTTP 커넥터에서 양방향 SSL/TLS가 활성화됩니다.

중요

보안 영역과 ssl-context가 모두 정의된 경우 JBoss EAP는 ssl -context 에서 제공하는 SSL/TLS 구성을 사용합니다 .

1.10.3. 아웃바운드 커넥터 원격와의 Elytron 통합

원격 아웃바운드 연결은 아웃바운드 소켓 바인딩 및 인증 컨텍스트에서 지정합니다. 인증 컨텍스트는 연결에 필요한 모든 보안 정보를 제공합니다. 특히 remote-outbound-connection 의 특성은 다음과 같습니다.

  • outbound-socket-binding-ref - 연결의 대상 주소와 포트를 결정하는 데 사용되는 아웃바운드 소켓 바인딩의 이름입니다.
  • authentication-context - 인증 구성과 정의된 SSL 컨텍스트(있는 경우 연결에 필요한)를 포함하는 인증 컨텍스트에 대한 참조입니다. 인증 컨텍스트 정의에 대한 자세한 내용은 인증 컨텍스트 생성을 참조하십시오.

예를 들어 remote-outbound-connection 은 다음과 같이 추가할 수 있습니다. 여기서 OUTBOUND_SOCKET_BINDING_NAME 은 이미 정의된 아웃바운드 소켓-바인 딩이고 AUTHENTICATION_CONTEXT_NAME 은 이미 elytron 하위 시스템 구성에 정의된 인증 컨텍스트 입니다.

/subsystem=remoting/remote-outbound-connection=OUTBOUND_CONNECTION_NAME:add(authentication-context=AUTHENTICATION_CONTEXT_NAME, outbound-socket-binding-ref=OUTBOUND_SOCKET_BINDING_NAME)

추가 리소스

1.11. SSL/TLS에 대한 추가 Elytron 구성 요소

일방향 SSL/TLS 및 양방향 SSL/TLS를 구성하는 기본 개념은 다음에서 설명합니다.

또한 Elytron은 SSL/TLS 구성을 위한 몇 가지 추가 구성 요소를 제공합니다.

1.11.1. ldap-key-store 사용

ldap-key-store 를 사용하면 LDAP 서버에 저장된 키 저장소를 사용할 수 있습니다. 저장소를 사용하는 것과 동일한 방식으로 ldap-key -store 를 사용할 수 있습니다.

참고

Jakarta Management ObjectName을 사용하여 LDAP 자격 증명을 해독할 수 없습니다. 대신 자격 증명 저장소를 사용하여 자격 증명을 보호할 수 있습니다. 자격 증명 저장소에 대한 자세한 내용은 Elytron의 자격 증명 저장소를 참조하십시오.

ldap-key-store 를 생성하고 사용하려면 다음을 수행합니다.

  1. dir-context 구성.

    JBoss EAP에서 LDAP 서버에 연결하려면 URL과 서버 연결에 사용되는 주체를 제공하는 dir-context 를 구성해야 합니다.

    예: dir-context

    /subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389", principal="uid=admin,ou=system", credential-reference={clear-text="secret"})

  2. ldap-key-store 를 구성합니다.

    ldap-key-store 를 구성할 때 LDAP 서버에 연결하는 데 사용되는 dir-context 와 LDAP 서버에 저장된 키 저장소를 찾는 방법을 모두 지정해야 합니다. 최소한 검색 경로를 지정해야 합니다.

    예: ldap-key-store

    /subsystem=elytron/ldap-key-store=ldapKS:add(dir-context=exampleDC, search-path="ou=Keystores,dc=wildfly,dc=org")

  3. ldap-key-store 를 사용합니다.

    ldap-key-store 를 정의한 후에는 키 저장소를 사용할 수 있는 동일한 위치에서 사용할 수 있습니다. 예를 들어 애플리케이션에 대해 일 방향 SSL/TLS 및 양방향 SSL/TLS 를 구성할 때 ldap-key-store 를 사용할 수 있습니다.

ldap-key-store 및 기타 Elytron 구성 요소에 대한 전체 속성 목록은 Elytron Subsystem Components Reference 를 참조하십시오.

1.11.2. filtering-key-store 사용

filtering-key-store 를 사용하면 기존 키 저장소에서 별칭의 하위 집합을 노출하고 키 저장소 를 사용할 수 있는 동일한 위치에 사용할 수 있습니다 . 예를 들어 키 저장소에 alias1, alias 2alias3 이 포함되어 있지만 alias 1과 alias 3 만 노출하려고 하면 filter -key-store 가 여러 가지 방법으로 사용할 수 있습니다.

filter -key-store 를 생성하려면 다음을 수행합니다.

  1. 키 저장소 구성.

    /subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
  2. filtering-key-store 를 구성합니다.

    filtering-key-store 를 구성할 때 필터링할 키 저장소와 키 저장소에서 별칭을 필터링하기 위한 alias-filter 를 지정합니다. 필터는 다음 형식 중 하나로 지정할 수 있습니다.

    • 콤마로 구분된 별칭 목록인 alias1,alias3.
    • ALL:-alias2 - 나열된 별칭을 제외하고 키 저장소의 모든 별칭을 노출합니다.
    • NONE:+alias1:+alias3 은 나열된 키 저장소를 제외한 별칭을 노출하지 않습니다.

      이 예에서는 쉼표로 구분된 목록을 사용하여 alias1 및 alias 3을 노출합니다.

      /subsystem=elytron/filtering-key-store=filterKS:add(key-store=myKS, alias-filter="alias1,alias3")
      참고

      alias-filter 특성은 대소문자를 구분합니다. elytronAppServer 와 같은 대소문자 별칭 또는 대문자 별칭을 일부 키 저장소 프로바이더에서 인식하지 못하기 때문에 elytronappserver 와 같은 소문자 별칭을 사용하는 것이 좋습니다.

  3. filtering-key-store 를 사용합니다.

    filtering-key-store 를 정의한 후에는 키 저장소를 사용할 수 있는 동일한 위치에서 사용할 수 있습니다. 예를 들어 애플리케이션에 대해 일 방향 SSL/TLS 및 양방향 SSL/TLS 를 구성할 때 필터링 키 저장소 를 사용할 수 있습니다.

filter -key-store 및 기타 Elytron 구성 요소에 대한 전체 속성 목록은 Elytron Subsystem Components Reference 를 참조하십시오.

1.11.3. 키 저장소 다시 로드

관리 CLI에서 JBoss EAP에 구성된 키 저장소를 다시 로드할 수 있습니다. 이 기능은 키 저장소에서 참조하는 인증서를 변경한 경우 유용합니다.

키 저장소를 다시 로드하려면 다음을 수행합니다.

/subsystem=elytron/key-store=httpsKS:load

1.11.4. 키 관리자 다시 초기화

관리 CLI에서 JBoss EAP에 구성된 키-manager 를 다시 초기화할 수 있습니다. 이 기능은 키 저장소 리소스에서 제공하는 인증서를 변경한 후 서버를 다시 시작하지 않고 새 SSL 연결에 적용하려는 경우에 유용합니다.

참고

키 저장소가 파일을 기반으로 하는 경우 먼저 로드해야 합니다.

/subsystem=elytron/key-store=httpsKS:load()

key-manager 를 다시 초기화하려면 다음을 수행합니다.

/subsystem=elytron/key-manager=httpsKM:init()

1.11.5. Trust Manager 다시 초기화

관리 CLI 또는 관리 콘솔에서 JBoss EAP에 구성된 trust-manager 를 다시 초기화할 수 있습니다. 이 기능은 키 저장소 리소스에서 제공하는 인증서를 변경하고 서버를 다시 시작하지 않고 새 SSL 연결에 변경 사항을 적용하려는 경우에 유용합니다.

관리 CLI에서 신뢰 관리자 다시 초기화
참고

키 저장소가 파일을 기반으로 하는 경우 먼저 로드해야 합니다.

/subsystem=elytron/key-store=httpsKS:load()

trust-manager 를 다시 초기화하려면 다음을 수행합니다.

/subsystem=elytron/trust-manager=httpsTM:init()
관리 콘솔에서 Trust Manager 다시 초기화
  1. 관리 콘솔로 이동하여 Runtime (런타임) 탭을 클릭합니다.
  2. Monitor (모니터링) 열에서 Security(보안) (Elytron) 를 클릭합니다.
  3. 보안 열에서 SSL → 보기를 클릭합니다.
  4. 네비게이션 창에서 Trust Manager (신뢰 관리자)를 클릭합니다.
  5. 화면 오른쪽 상단에 있는 Initialize (최초화)를 클릭하여 trust-manager 를 다시 초기화합니다.

1.11.6. 키 저장소 별칭

별칭 은 저장소에 저장된 비밀 또는 자격 증명을 나타냅니다. 키 저장소 구성 요소를 사용하여 elytron 하위 시스템에 키 저장소 를 추가하는 경우 별칭 관련 키 저장소 작업을 사용하여 키 저장소의 내용을 확인할 수 있습니다.

별칭 조작을 위한 다른 작업은 다음과 같습니다.

  • read-alias - 키 저장소에서 별칭을 읽습니다.
  • read-aliases - 키 저장소에서 별칭을 읽습니다.
  • remove-alias - 키 저장소에서 별칭을 제거합니다.

예를 들어 별칭을 읽으려면 다음을 수행합니다.

/subsystem=elytron/key-store=httpsKS/:read-alias(alias=localhost)

1.11.7. client-ssl-context 사용

원격에서 SSL 사용 등 JBoss EAP 인스턴스가 클라이언트로 SSL 연결을 만들 때 client-ssl-context 가 SSL 컨텍스트를 제공하는 데 사용됩니다.

client-ssl-context 를 생성하려면 다음을 수행합니다.

  1. 필요에 따라 키 저장소, key-managertrust-manager 구성 요소를 생성합니다.

    양방향 SSL/TLS 연결을 설정하는 경우 클라이언트 및 서버 인증서에 사용할 별도의 키 저장소 구성 요소, 클라이언트 저장소의 키-관리자, 서버 키 저장소에 대한 trust-manager 를 생성해야 합니다. 또는 일방향 SSL/TLS 연결을 수행하는 경우 서버 인증서에 대한 키 저장소와 이를 참조하는 trust-manager 를 생성해야 합니다. 키 저장소 및 신뢰 저장소 생성의 예는 Elytron Subsystem(Elytron 하위 시스템) 섹션을 사용하여 애플리케이션의 Enable Two-way SSL/TLS 를 참조하십시오.

  2. client-ssl-context 를 만듭니다.

    키 저장소, 신뢰 저장소 및 기타 필수 구성 옵션을 참조하는 클라이언트-ssl-context 를 만듭니다.

    예: client-ssl-context

    /subsystem=elytron/client-ssl-context=exampleCSC:add(key-manager=clientKM, trust-manager=clientTM, protocols=["TLSv1.2"])

  3. client-ssl-context를 참조합니다.

client-ssl-context 및 기타 Elytron 구성 요소에 대한 전체 속성 목록은 Elytron 하위 시스템 구성 요소 참조를 참조하십시오.

1.11.8. server-ssl-context 사용

server-ssl-context 는 서버 측 SSL 컨텍스트를 제공하는 데 사용됩니다. SSL 컨텍스트의 일반적인 구성 외에도 암호화 제품군 및 프로토콜과 같은 추가 항목을 구성할 수 있습니다. SSL 컨텍스트는 구성된 추가 항목을 래핑합니다.

  1. 필요에 따라 키 저장소, key-managertrust-manager 구성 요소를 생성합니다.

    양방향 SSL/TLS 연결을 설정하는 경우 클라이언트 및 서버 인증서에 사용할 별도의 키 저장소 구성 요소, 서버 저장소 의 키-관리자, 서버 신뢰 저장소에 대한 trust-manager 를 생성해야 합니다 . 또는 일방향 SSL/TLS 연결을 수행하는 경우 서버 인증서에 대한 키 저장소와 이를 참조하는 키-manager 를 생성해야 합니다. 키 저장소 및 신뢰 저장소 생성의 예는 Elytron 하위 시스템을 사용하여 애플리케이션에 대한 양방향 SSL/TLS 활성화 섹션에서 확인할 수 있습니다.

  2. server-ssl-context 를 만듭니다.

    아래 설명된 옵션 중 하나를 사용하여 키 관리자, 신뢰 관리자 또는 기타 원하는 구성 옵션을 참조하는 server-ssl-context 를 만듭니다.

관리 CLI를 사용하여 서버 SSL 컨텍스트 추가
/subsystem=elytron/server-ssl-context=newServerSSLContext:add(key-manager=KEY_MANAGER,protocols=["TLSv1.2"])
중요

지원할 HTTPS 프로토콜을 결정해야 합니다. 위의 예제 명령은 TLSv1.2 를 사용합니다. cipher-suite-filter 인수를 사용하여 허용되는 암호화 제품군과 use-cipher-suites-order 인수를 지정하여 서버 암호 제품군 순서를 적용할 수 있습니다. 기본적으로 use-cipher-suites-order 특성은 true 로 설정됩니다. 이는 기본적으로 클라이언트 암호화 제품군 순서를 준수하는 레거시 보안 하위 시스템 동작과 다릅니다.

관리 콘솔을 사용하여 서버 SSL 컨텍스트 추가
  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
  2. ConfigurationSubsystemsSecurity (Elytron)기타 설정으로 이동하여 보기를 클릭합니다.
  3. SSL → 서버 SSL 컨텍스트를 클릭하고 Add (추가 )를 클릭하여 새 서버 SSL 컨텍스트를 구성합니다.

server-ssl-context 및 기타 Elytron 구성 요소에 대한 속성 전체 목록은 Elytron Subsystem Components Reference 를 참조하십시오.

1.11.9. server-ssl-sni-context 사용

server-ssl-sni-context 는 서버 측 SNI 일치를 제공하는 데 사용됩니다. 제공된 호스트 이름이 일치하지 않는 경우 기본값과 함께 호스트 이름과 SSL 컨텍스트를 연결하는 일치하는 규칙을 제공합니다. undertow 하위 시스템에서 컨텍스트를 정의할 때와 같이 표준 서버 SSL 컨텍스트 대신 SSL SNI 컨텍스트를 사용할 수 있습니다.

  1. 필요에 따라 키 저장소, key-manager, trust-managerserver-ssl-context 구성 요소를 만듭니다. server -ssl-sni-context를 생성하려면 서버 SSL 컨텍스트가 정의되어 있어야 합니다.
  2. server-ssl-context 요소에 일치하는 정보를 제공하는 server-ssl-sni -context 를 만듭니다. 일치하는 호스트 이름을 찾을 수 없는 경우 사용되는 default-ssl-context 특성을 사용하여 기본 SSL 컨텍스트를 지정해야 합니다. host-context-map 은 다양한 SSL 컨텍스트와 일치하도록 쉼표로 구분된 호스트 이름 목록을 허용합니다.

    /subsystem=elytron/server-ssl-sni-context=SERVER_SSL_SNI_CONTEXT:add(default-ssl-context=DEFAULT_SERVER_SSL_CONTEXT,host-context-map={HOSTNAME=SERVER_SSL_CONTEXT,...})

    다음은 server SSL SSL 컨텍스트를 기본값으로 하는 server-ssl-sni-context 를 정의하는 데 사용되며 www.example.com 의 들어오는 요청과 exampleSSL 컨텍스트와 일치시킵니다.

    /subsystem=elytron/server-ssl-sni-context=exampleSNIContext:add(default-ssl-context=serverSSL,host-context-map={www\\.example\\.com=exampleSSL})
참고

호스트 일치의 특성 값은 정규식으로 작동하므로 도메인 이름을 구분하는 데 사용되는 마침표(.)를 이스케이프해야 합니다.

관리 콘솔을 사용하여 server-ssl-sni-context 구성
  1. 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
  2. ConfigurationSubsystemsSecurity (Elytron)기타 설정으로 이동하여 보기를 클릭합니다.
  3. SSL → 서버 SSL SNI 컨텍스트를 클릭하여 필요한 ssl-sni-context 를 구성합니다.

Elytron 구성 요소에 대한 전체 속성 목록은 Elytron 하위 시스템 구성 요소 참조를 참조하십시오.

1.11.10. 사용자 정의 SSL 구성 요소

elytron 하위 시스템에서 SSL/TLS를 구성할 때 다음 구성 요소의 사용자 지정 구현을 제공하고 사용할 수 있습니다.

  • key-store
  • key-manager
  • trust-manager
  • client-ssl-context
  • server-ssl-context
주의

JSSE(Java Secure Socket Extension)에 대한 지식 없이 trust-manager 외부에 있는 구성 요소의 사용자 지정 구현을 제공하지 않는 것이 좋습니다.

중요

FIPS를 사용하는 경우 보안상의 이유로 FIPS를 사용하려면 이러한 관리자를 JDK에 포함해야 하므로 사용자 정의 신뢰 관리자 또는 키 관리자를 활용할 수 없습니다. X509 증거를 검증하는 SecurityRealm 을 구현하여 유사한 동작을 수행할 수 있습니다.

Elytron 구성 요소의 사용자 지정 구현을 생성할 때 적절한 기능과 요구 사항을 제시해야 합니다. 기능 및 요구 사항에 대한 자세한 내용은 JBoss EAP 보안 아키텍처 가이드의 기능 및 요구 사항 섹션을 참조하십시오. 각 구성 요소에 대한 구현 세부 정보는 JDK 벤더에서 제공합니다.

1.11.10.1. Elytron에 사용자 지정 구성 요소 추가

다음 단계에서는 Elytron 내에서 사용자 지정 구성 요소를 추가하는 방법을 설명합니다.

  1. 사용자 지정 구성 요소에 대한 공급자가 포함된 JAR을 모듈로 JBoss EAP에 추가하여 javax.api와 같은 필수 종속성을 선언합니다.

    module add --name=MODULE_NAME --resources=FACTORY_JAR --dependencies=javax.api,DEPENDENCY_LIST
    중요

    모듈 관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다. 자세한 내용은 Create a Custom Module Manually and Remove a Custom Module Manually 섹션을 참조하십시오.

    기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

    기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.

  2. elytron 하위 시스템에 구성 요소를 추가하면 공급업체를 검색하는 데 java.util.ServiceLoader 를 사용합니다. 또는 provider -loader를 정의하여 공급업체에 대한 참조를 제공할 수 있습니다. 로더를 생성하는 방법에는 두 가지가 있으며 각 구성 요소에 대해 하나만 구현해야 합니다.

    • provider -loader를 정의할 때 직접 공급자를 참조합니다.

      /subsystem=elytron/provider-loader=LOADER_NAME:add(class-names=[CLASS_NAME],module=MODULE_NAME)
    • META-INF/services/java.security.Provider 에 프로바이더에 대한 참조를 포함합니다. 이 참조는 org.kohsuke.metainf-services 에서 @MetaInfServices 주석을 사용할 때 자동으로 생성됩니다. 이 방법을 사용하는 경우 다음과 같이 provider-loader 에서 모듈만 참조해야 합니다.

      /subsystem=elytron/provider-loader=LOADER_NAME:add(module=MODULE_NAME)
  3. Elytron의 구성에 사용자 지정 구성 요소를 추가하고 정의된 공급자를 참조할 유형에 적절한 요소를 추가합니다.

    /subsystem=elytron/COMPONENT_NAME=NEW_COMPONENT:add(providers=LOADER_NAME,...)

    예를 들어 신뢰 관리자를 정의하기 위해 다음 명령에 표시된 대로 trust-manager 요소가 사용됩니다.

    예제: 사용자 정의 신뢰 관리자 추가

    /subsystem=elytron/trust-manager=newTrustManager:add(algorithm=MyX509,providers=customProvider,key-store=sampleKeystore)

  4. 정의되고 나면 구성 요소를 다른 요소에서 참조할 수 있습니다.

추가 리소스

1.11.10.2. 사용자 지정 Elytron 구성 요소에 인수 포함

다음과 같이 클래스에서 초기화 메서드를 구현하는 경우 사용자 지정 구성 요소 내에 인수를 포함할 수 있습니다.

void initialize(final Map<String, String> configuration);

이 메서드를 사용하면 사용자 정의 클래스에서 정의된 경우 구성 문자열 세트를 수신할 수 있습니다. 구성 요소를 정의할 때 구성 속성을 사용하여 전달됩니다. 예를 들어 다음 예제에서는 값이 my ValuemyAttribute 라는 속성을 정의합니다.

/subsystem=elytron/COMPONENT_NAME=NEW_COMPONENT:add(class-name=CLASS_NAME,module=MODULE_NAME,configuration={myAttribute="myValue"}

1.11.10.3. Elytron으로 사용자 지정 신뢰 관리자 사용

사용자 지정 신뢰 관리자를 구현하면 Undertow에서 HTTPS, 디렉터리 컨텍스트 에서 LDAPS 또는 Elytron이 SSL 연결에 사용되는 모든 위치를 사용할 때 인증서 유효성 검사를 확장할 수 있습니다. 이 구성 요소는 서버에 대한 신뢰 결정을 내려야 하며 사용자 지정 신뢰 관리자를 사용하는 경우 이러한 요소를 구현하는 것이 좋습니다.

중요

FIPS를 사용하는 경우 보안상의 이유로 이 관리자를 JDK에 포함해야 하므로 사용자 정의 신뢰 관리자를 활용할 수 없습니다. X509 증거를 검증하는 SecurityRealm 을 구현하여 유사한 동작을 수행할 수 있습니다.

Custom Trust Manager 구현 요구사항

사용자 정의 신뢰 관리자를 사용하는 경우 다음을 구현해야 합니다.

  • X509ExtendedTrustManager 인터페이스를 구현하는 신뢰 관리자입니다.
  • TrustManagerFactorySpi 를 확장하는 신뢰 관리자 팩토리입니다.
  • 신뢰 관리자 팩토리의 공급자.

프로바이더는 JBoss EAP에 추가할 JAR 파일에 포함되어야 합니다. 구현된 모든 클래스는 JBoss EAP에 모듈로 포함되어야 합니다. 클래스는 한 모듈에 필요하지 않으며 모듈 종속성에서 로드할 수 있습니다.

구현 예

다음 예제에서는 사용자 지정 신뢰 관리자 팩토리를 서비스로 등록하는 공급자를 보여줍니다.

예제: 공급자

import org.kohsuke.MetaInfServices;
import javax.net.ssl.TrustManagerFactory;
import java.security.Provider;
import java.util.Collections;
import java.util.List;
import java.util.Map;

@MetaInfServices(Provider.class)
public class CustomProvider extends Provider {

    public CustomProvider() {
        super("CustomProvider", 1.0, "Demo provider");

        System.out.println("CustomProvider initialization.");

        final List<String> emptyList = Collections.emptyList();
        final Map<String, String> emptyMap = Collections.emptyMap();

        putService(new Service(this, TrustManagerFactory.class.getSimpleName(),"CustomAlgorithm", CustomTrustManagerFactorySpi.class.getName(), emptyList, emptyMap));
    }

}

다음 예제에서는 사용자 지정 신뢰 관리자를 보여줍니다. 이 신뢰 관리자에는 클라이언트 또는 서버가 신뢰할 수 있는지 확인하는 과부하 방법이 포함되어 있습니다.

예제: TrustManager

import javax.net.ssl.SSLEngine;
import javax.net.ssl.X509ExtendedTrustManager;
import java.net.Socket;
import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;

public class CustomTrustManager extends X509ExtendedTrustManager {

    public void checkClientTrusted(X509Certificate[] x509Certificates, String s, Socket socket) throws CertificateException {
        // Insert your code here
    }

    public void checkServerTrusted(X509Certificate[] x509Certificates, String s, Socket socket) throws CertificateException {
        // Insert your code here
    }

    public void checkClientTrusted(X509Certificate[] x509Certificates, String s, SSLEngine sslEngine) throws CertificateException {
        // Insert your code here
    }

    public void checkServerTrusted(X509Certificate[] x509Certificates, String s, SSLEngine sslEngine) throws CertificateException {
        // Insert your code here
    }

    public void checkClientTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException {
        // Insert your code here
    }

    public void checkServerTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException {
        // Insert your code here
    }

    public X509Certificate[] getAcceptedIssuers() {
        // Insert your code here
    }

}

다음 예는 신뢰 관리자의 인스턴스를 반환하는 데 사용되는 팩토리입니다.

예제: TrustManagerFactorySpi

import javax.net.ssl.ManagerFactoryParameters;
import javax.net.ssl.TrustManager;
import javax.net.ssl.TrustManagerFactorySpi;
import java.security.InvalidAlgorithmParameterException;
import java.security.KeyStore;
import java.security.KeyStoreException;

public class CustomTrustManagerFactorySpi extends TrustManagerFactorySpi {

    protected void engineInit(KeyStore keyStore) throws KeyStoreException {
        // Insert your code here
    }

    protected void engineInit(ManagerFactoryParameters managerFactoryParameters) throws InvalidAlgorithmParameterException {
        // Insert your code here
    }

    protected CustomTrustManager[] engineGetTrustManagers() {
        // Insert your code here
    }

}

Custom Trust Manager 추가

공급자와 신뢰 관리자가 생성되면 Ely tron에 사용자 지정 구성 요소 추가에 설명된 단계를 사용하여 ely tron 하위 시스템에 추가합니다.

1.11.11. 기본 SSLContext

배포 내에서 사용되는 대부분의 라이브러리에는 설정한 연결에 대한 SSL 구성이 필요할 수 있습니다. 이러한 라이브러리는 호출자가 구성할 수 있는 경향이 있습니다. 구성이 제공되지 않으면 프로세스에 기본 SSLContext 를 사용합니다.

기본 SSLContext 는 다음 메서드 호출을 사용하여 사용할 수 있습니다.

javax.net.ssl.SSLContext.getDefault();

기본적으로 이 SSLContext 는 시스템 속성을 사용하여 구성됩니다. 그러나 elytron 하위 시스템 내에서 구성된 컨텍스트 중 어떤 컨텍스트를 연결하고 기본값으로 사용해야 하는지 지정할 수 있습니다.

이 기능을 사용하려면 SSLContext 를 정상적으로 구성합니다. 다음 명령을 사용하여 기본값으로 사용해야 하는 SSLContext 를 지정할 수 있습니다.

/subsystem=elytron:write-attribute(name=default-ssl-context, value=client-context)

기존 서비스 및 배포가 설정하기 전에 기본 SSLContext 를 캐시할 수 있으므로 배포를 활성화하기 전에 기본값을 설정하려면 다시 로드해야 합니다.

:reload

이후에 default-ssl-context 특성이 정의되지 않은 경우 표준 API는 기본값을 되돌리는 메커니즘을 제공하지 않습니다. 이 경우 Java 프로세스를 다시 시작해야 합니다.

/subsystem=elytron:undefine-attribute(name=default-ssl-context)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-restart" => true,
        "process-state" => "restart-required"
    }
}

1.11.12. 인증서 폐기 목록 사용

CRL(인증서 해지 목록)에 대해 인증서의 유효성을 검사하려면 elytron 하위 시스템에서 신뢰 관리자에 대한 certificate-revocation-list 특성을 사용하여 인증서를 구성할 수 있습니다. 예를 들면 다음과 같습니다.

/subsystem=elytron/trust-manager=TRUST_MANAGER:write-attribute(name=certificate-revocation-list,value={path=/path/to/CRL_FILE.crl.pem}

신뢰 관리자에 사용 가능한 속성에 대한 자세한 내용은 trust-manager attributes table 테이블을 참조하십시오.

참고

신뢰할 수 있는 저장소에는 인증 취소 목록과 인증서의 유효성을 확인하기 위해 인증서 체인이 포함되어야 합니다. 신뢰 저장소에는 엔드티티 인증서, 인증 기관 및 중간 인증서만 포함되어서는 안 됩니다.

reload-certificate-revocation-list 작업을 사용하여 신뢰 관리자에게 인증서 취소 목록을 다시 로드하도록 지시할 수 있습니다.

/subsystem=elytron/trust-manager=TRUST_MANAGER:reload-certificate-revocation-list

1.11.13. 인증 기관을 사용하여 서명된 인증서 관리

JBoss EAP 관리 CLI 및 관리 콘솔을 사용하여 서명된 인증서를 가져오고 관리할 수 있습니다. 이를 통해 CLI 또는 콘솔에서 직접 서명한 인증서를 생성한 다음 필요한 키 저장소로 가져올 수 있습니다.

참고

이 섹션의 대부분의 명령에는 인증 기관의 스테이징 URL을 사용해야 하는지 여부를 나타내는 선택적 스테이징 매개 변수가 있습니다. 이 값은 기본값은 false 이며 테스트 목적으로 설계되었습니다. 이 매개 변수는 프로덕션 환경에서는 활성화되지 않아야 합니다.

암호 암호화 계정 설정

JBoss EAP 7.4부터 Let's Encrypt는 유일하게 지원되는 인증 기관입니다. 서명된 인증서를 관리하려면 인증 기관과 다음 정보를 사용하여 계정을 생성해야 합니다.

  • 인증 기관 계정 키의 별칭을 포함하는 키 저장소입니다.
  • 인증 기관의 별칭입니다. 제공된 별칭이 지정된 키 저장소에 없는 경우 개인 키 항목으로 생성되어 저장됩니다.
  • 문제 발생 시 인증 기관이 연락할 수 있는 이메일 주소와 같은 선택적 URL 목록입니다.
/subsystem=elytron/certificate-authority-account=CERTIFICATE_ACCOUNT:add(key-store=KEYSTORE,alias=ALIAS,contact-urls=[mailto:EMAIL_ADDRESS])
인증 기관으로 계정 생성

계정이 구성되면 서비스 약관에 따라 인증 기관을 사용하여 만들 수 있습니다.

/subsystem=elytron/certificate-authority-account=CERTIFICATE_ACCOUNT:create-account(agree-to-terms-of-service=true)
인증 기관으로 계정 업데이트

인증 기관 계정 옵션은 update-account 명령을 사용하여 업데이트할 수 있습니다.

/subsystem=elytron/certificate-authority-account=CERTIFICATE_ACCOUNT:update-account(agree-to-terms-of-service=true)
인증 기관과 연결된 계정 키 변경

인증 기관 계정과 연결된 키는 change-account-key 명령을 사용하여 변경할 수 있습니다.

/subsystem=elytron/certificate-authority-account=CERTIFICATE_ACCOUNT:change-account-key()
인증 기관을 사용하여 계정 비활성화

계정이 더 이상 필요하지 않은 경우 deactivate -account 명령을 사용하여 비활성화할 수 있습니다.

/subsystem=elytron/certificate-authority-account=CERTIFICATE_ACCOUNT:deactivate-account()
인증 기관과 메타 데이터 연결

get-metadata 명령을 사용하여 계정의 메타데이터를 쿼리할 수 있습니다. 이는 다음과 같은 정보를 제공합니다.

  • 서비스 약관에 대한 URL입니다.
  • 인증 기관 웹 사이트의 URL입니다.
  • 인증 기관 계정 목록입니다.
  • 외부 계정이 필요한지 여부.
/subsystem=elytron/certificate-authority-account=CERTIFICATE_ACCOUNT:get-metadata()
관리 콘솔을 사용하여 암호 암호화 계정 구성

관리 콘솔을 사용하여 let's Encrypt 계정을 구성하려면 다음을 수행합니다.

  1. 관리 콘솔에 액세스합니다.

    자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.

  2. 런타임 → 호스트보안(Elytron)SSL 로 이동하여 보기를 클릭합니다.
  3. Certificate Auth… (인증 기관 인증...)를 클릭하여 인증 기관 계정 페이지를 엽니다.
  4. 라벨이 있는 버튼을 클릭하면 선택한 별칭에 대해 다음 구성을 수행할 수 있습니다.

    • create

      인증 기관으로 계정을 생성합니다.

    • 비활성화

      선택한 인증 기관 계정을 비활성화합니다.

    • update

      선택한 계정을 인증 기관으로 업데이트합니다.

    • 메타데이터 가져오기

      인증 기관 계정에 대한 다음 정보를 확인합니다.

      • 관련 별칭
      • 인증 기관 이름
      • 연락처
      • 키 저장소 이름
      • 인증 기관 세부 정보
    • 계정 키 변경

      • 인증 기관에서 연결된 키를 변경합니다.

1.11.14. 키 저장소 조작 작업

관리 CLI와 관리 콘솔을 사용하여 Elytron 키 저장소 리소스에서 다양한 키 저장소 조작 작업을 수행할 수 있습니다.

관리 CLI를 사용하여 키 저장소 조작 작업

관리 CLI를 사용하여 다음 키 저장소 조작 작업을 수행할 수 있습니다.

  • 키 쌍을 생성합니다.

    generate-key-pair 명령은 키 쌍을 생성하고 결과 공개 키를 자체 서명 X.509 인증서로 래핑합니다. 생성된 개인 키와 자체 서명된 인증서가 키 저장소에 추가됩니다.

    /subsystem=elytron/key-store=httpsKS:add(path=/path/to/server.keystore.jks,credential-reference={clear-text=secret},type=JKS)
    
    /subsystem=elytron/key-store=httpsKS:generate-key-pair(alias=example,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=www.example.com")
  • 인증서 서명 요청을 생성합니다.

    generate-certificate-signing-request 명령은 키 저장소의 PrivateKeyEntry 를 사용하여 PKCS #10 인증서 서명 요청을 생성합니다. 생성된 인증서 서명 요청이 파일에 작성됩니다.

    /subsystem=elytron/key-store=httpsKS:generate-certificate-signing-request(alias=example,path=server.csr,relative-to=jboss.server.config.dir,distinguished-name="CN=www.example.com",extensions=[{critical=false,name=KeyUsage,value=digitalSignature}],credential-reference={clear-text=secret})
  • 인증서 또는 인증서 체인 가져오기.

    import-certificate 명령은 파일에서 키 저장소의 항목으로 인증서 또는 인증서 체인을 가져옵니다.

    /subsystem=elytron/key-store=httpsKS:import-certificate(alias=example,path=/path/to/certificate_or_chain/file,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},trust-cacerts=true)
  • 인증서를 내보냅니다.

    export-certificate 명령은 키 저장소의 항목에서 파일로 인증서를 내보냅니다.

    /subsystem=elytron/key-store=httpsKS:export-certificate(alias=example,path=serverCert.cer,relative-to=jboss.server.config.dir,pem=true)
  • 별칭 변경.

    change-alias 명령은 기존 키 저장소 항목을 새 별칭으로 이동합니다.

    /subsystem=elytron/key-store=httpsKS:change-alias(alias=example,new-alias=newExample,credential-reference={clear-text=secret})
  • 키 저장소에 대한 변경 사항을 저장합니다.

    store 명령은 키 저장소를 지원하는 파일의 변경 사항을 유지합니다.

    /subsystem=elytron/key-store=httpsKS:store()
관리 콘솔을 사용하여 키 저장소 조작 작업

관리 콘솔을 사용하여 작업을 수행하려면 다음을 수행합니다.

  1. 관리 콘솔에 액세스합니다.

    자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.

  2. 런타임보안(Elytron)저장소로 이동하여 보기를 클릭합니다.
  3. Key Store (키 저장소)를 클릭하여 키 저장소 정의 페이지를 엽니다.
  4. 필요한 키 저장소 이름을 클릭합니다.

    라벨이 있는 버튼을 클릭하여 선택한 키 저장소에 대해 다음 작업을 수행할 수 있습니다.

    • 로드

      키 저장소를 로드하거나 다시 로드합니다.

    • 저장

      키 저장소를 지원하는 파일의 변경 사항을 유지합니다.

    • 키 쌍 생성

      키 쌍을 생성하고 자체 서명된 X.509 인증서에 공개 키를 래핑한 다음 개인 키와 인증서를 키 저장소에 추가합니다.

    • 인증서 가져 오기

      파일에서 키 저장소로 인증서 체인을 가져옵니다.

    • 가져오기

      인증 기관에서 서명된 인증서를 가져와 키 저장소에 저장합니다.

1.11.14.1. 키 저장소 인증 기관 작업

Let's Encrypt Account를 구성한 후 키 저장소에서 다음 작업을 수행할 수 있습니다.

참고

이 섹션의 대부분의 명령에는 인증 기관의 스테이징 URL을 사용해야 하는지 여부를 나타내는 선택적 스테이징 매개 변수가 있습니다. 이 값은 기본값은 false 이며 테스트 목적으로 설계되었습니다. 이 매개 변수는 프로덕션 환경에서는 활성화되지 않아야 합니다.

관리 CLI를 사용한 키 저장소 인증 기관 작업

관리 CLI를 사용하여 다음 키 저장소 인증 기관 작업을 수행할 수 있습니다.

  • 서명된 인증서 받기.

    키 저장소에 인증 기관 계정이 정의되면 obtain-certificate 명령을 사용하여 서명된 인증서를 가져와 키 저장소에 저장할 수 있습니다. 인증 기관이 있는 계정이 없으면 자동으로 생성됩니다.

    /subsystem=elytron/key-store=KEYSTORE:obtain-certificate(alias=ALIAS,domain-names=[DOMAIN_NAME],certificate-authority-account=CERTIFICATE_ACCOUNT,agree-to-terms-of-service=true,algorithm=RSA,credential-reference={clear-text=secret})
  • 서명된 인증서를 취소합니다.

    revoke-certificate 명령은 인증 기관에서 발급한 인증서를 취소합니다.

    /subsystem=elytron/key-store=KEYSTORE:revoke-certificate(alias=ALIAS,certificate-authority-account=CERTIFICATE_ACCOUNT)
  • 서명된 인증서가 갱신 예정인지 확인합니다.

    should-renew-certificate 명령은 인증서 갱신이 필요한지 여부를 결정합니다. 인증서가 지정된 일 수보다 적은 경우 명령은 true 를 반환하고 그렇지 않으면 false 를 반환합니다.

    다음 명령은 향후 7일 동안 인증서가 만료되는지 여부를 확인합니다.

    /subsystem=elytron/key-store=KEYSTORE:should-renew-certificate(alias=ALIAS,expiration=7)
관리 콘솔을 사용한 키 저장소 인증 기관 작업

관리 콘솔을 사용하여 작업을 수행하려면 다음을 수행합니다.

  1. 관리 콘솔에 액세스합니다.

    자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.

  2. 런타임보안(Elytron)저장소로 이동하여 보기를 클릭합니다.
  3. Key Store (키 저장소)를 클릭하여 키 저장소 정의 페이지를 엽니다.
  4. 필수 키 저장소 이름 옆에 있는 Aliases (별칭)를 클릭합니다.
  5. 필요한 별칭 이름을 클릭합니다.

    라벨이 있는 버튼을 클릭하면 선택한 별칭에 대해 다음 작업을 수행할 수 있습니다.

    • Alias 변경

      항목의 별칭을 변경합니다.

    • 인증서 내보내기

      키 저장소 항목에서 파일로 인증서를 내보냅니다.

    • CSR 생성

      인증서 서명 요청을 생성합니다.

    • Alias 제거

      키 저장소에서 선택한 별칭을 제거합니다.

    • 세부 정보

      별칭과 연결된 인증서의 세부 정보를 확인합니다.

    • 취소

      별칭과 연결된 인증서를 취소합니다.

    • 갱신 확인

      관련 인증서가 갱신 예정인지 확인합니다.

1.11.15. 주체 대체 이름 확장을 사용하여 X.509 인증서에 대한 Evidence providerder 구성

기본적으로 Elytron의 X.509 인증서와 연결된 주체는 인증서의 주체 이름이며 X.509 인증서 체인과 연결된 주체는 인증서 체인의 첫 번째 인증서의 주체 이름입니다. X.509 인증서에서 주체로 주제 대체 이름 확장을 사용하도록 X509-subject-alt-name-evidence-decoder 를 구성할 수 있습니다.

X.509 인증서 및 X.509 인증서 체인에 대한 주체 대체 이름 확장 사양은 RFC 5280 에 정의되어 있습니다.

사전 요구 사항

  • 예상 클라이언트 인증서 형식을 알고 있거나 로컬에 클라이언트 인증서를 사용할 수 있습니다.

절차

  1. 사용할 대체 이름 확장을 식별합니다.

    클라이언트 인증서가 로컬에 있는 경우 keytool 명령을 사용하여 주체 대체 이름 확장을 볼 수 있습니다.

    keytool -printcert -file /path/to/certificate/certificate.cert

    주체 대체 이름 확장은 다음과 같이 나열됩니다.

    SubjectAlternativeName [
       DNS:one.example.org
       IP Address:127.0.0.1
    ]
  2. 식별된 제목 대체 이름을 사용하려면 x509-subject-alt-name-evidence-decoder 를 만듭니다.

    /subsystem=elytron/x509-subject-alt-name-evidence-decoder=exampleDnsDecoder:add(alt-name-type=__EXTENSION_TO_USE__)
    • evidence 디코더를 사용하려면 security-domain에서 이를 참조합니다.

      /subsystem=elytron/security-domain=__Security_Domain_Name__:write-attribute(name="evidence-decoder",value="exampleDnsDecoder")

1.11.16. 집계 송신자 구성

두 개 이상의 증거 디코더를 결합하도록 집계 증거 디코더를 구성할 수 있습니다. 증거 디코더는 더 이상 증거 디코더가 남아 있지 않은 증거 디코더를 반환할 때까지 구성된 순서로 적용됩니다.

사전 요구 사항

절차

  1. 기존 증거 디코더에서 집계 증거 디코더를 생성합니다.

    /subsystem=elytron/aggregate-evidence-decoder=aggregateDecoder:add(evidence-decoders=[__DECODER_1__,__DECODER_2__,...,__DECODER_N__])
    • evidence 디코더를 사용하려면 보안 도메인에서 이를 참조합니다.

      /subsystem=elytron/security-domain=__SECURITY_DOMAIN__:write-attribute(name="evidence-decoder",value="aggregateDecoder")

1.11.17. X.500 주체 에라타 구성

인증서 체인의 첫 번째 인증서에서 주체를 추출하도록 x500-subject-evidence-decoder 를 구성합니다.

절차

  • x.500 제목 증거 디코더 생성:

    /subsystem=elytron/x500-subject-evidence-decoder=exampleSubjectDecoder:add()

1.11.18. 사용자 지정 에라타 구현 사용

JBoss EAP에 모듈로 추가하여 Elytron에서 사용자 지정 org.wildfly.security.auth.server.EvidenceDecoder 구현을 사용할 수 있습니다.

절차

  1. 사용자 지정 구현 클래스를 JAR(Java Archive)로 패키징합니다.
  2. JAR을 포함하는 JBoss EAP에 모듈을 추가합니다.

    JBoss EAP에 모듈 추가에 대한 자세한 내용은 구성 가이드 의 사용자 지정 모듈 만들기 섹션을 참조하십시오.

  3. Elytron에 사용자 정의 증거 디코더를 추가합니다.

    /subsystem=elytron/custom-evidence-decoder=myCustomEvidenceDecoder:add(module=__MODULE_NAME__, class-name=__FULLY_QUALIFIED_CLASS_NAME__)

2장. 관리형 도메인 보안

관리형 도메인 컨트롤러와 해당 호스트 컨트롤러 간의 통신을 보호할 수 있습니다.

2.1. elytron를 사용하여 도메인 컨트롤러에 대한 암호 인증 구성

슬레이브 컨트롤러가 사용자로 인증할 수 있도록 사용자를 마스터 도메인 컨트롤러에 추가해야 합니다. 슬레이브 컨트롤러는 마스터 도메인 컨트롤러의 HTTP 인터페이스에서 인증을 시도합니다.

절차

  1. 마스터 도메인 컨트롤러에 사용자를 추가합니다. add-user 유틸리티를 사용하여 사용자 이름, 암호 및 기타 구성을 추가합니다. HTTP 인터페이스가 ManagementRealm Elytron 보안 영역으로 보호되는 경우 ManagementRealm 에 사용자를 추가해야 합니다.

    참고

    기본 파일 기반 사용자 및 그룹 인증 메커니즘을 사용하는 경우 EAP_HOME/bin/add-user.sh 스크립트를 실행합니다.

    참고

    add-user 유틸리티를 사용하여 사용자 정보를 추가한 후 서버는 메모리에 있는 속성 파일의 내용을 캐시합니다. 그러나 서버는 각 인증 요청에 있는 속성 파일의 수정된 시간을 확인하고 시간이 업데이트되면 다시 로드합니다. 즉, add-user 유틸리티에 의한 모든 변경 사항은 실행 중인 모든 서버에 즉시 적용됩니다.

    참고

    관리 사용자의 기본 영역 이름은 ManagementRealm 입니다. add-user 유틸리티에서 영역 이름을 묻는 메시지가 표시되면 기본 영역 이름(즉, 다른 영역으로 전환하지 않은 경우)을 수락해야 합니다.

  2. 슬레이브 컨트롤러에 인증 구성을 추가합니다. 다음 예제에서는 사용자 슬레이브 및 password1 을 사용하여 슬레이브 라는 새 인증 구성을 추가하는 방법을 보여줍니다.

    /host=slave/subsystem=elytron/authentication-configuration=slave:add(authentication-name=slave, credential-reference={clear-text=password1!})
  3. 다음 예와 같이 슬레이브 컨트롤러에 authentication-context 를 추가합니다.

    /host=slave/subsystem=elytron/authentication-context=slave-context:add(match-rules=[{authentication-configuration=slave}])
  4. 다음 예와 같이 슬레이브 컨트롤러에서 도메인 컨트롤러 위치 및 authentication-context 를 지정합니다.

    <domain-controller>
      <remote protocol="remote" host="localhost" port="9990" authentication-context="slave-context"/>
    </domain-controller>

추가 리소스

  • 관리형 도메인 운영 모드의 개념 및 일반 구성에 대한 자세한 내용은 JBoss EAP 구성 가이드도메인 관리 섹션을 참조하십시오.
  • 사용자 관리에 대한 자세한 내용은 JBoss EAP 구성 가이드관리 사용자 섹션을 참조하십시오.

2.2. 레거시 코어 관리 인증을 사용하여 도메인 컨트롤러에 대한 암호 인증 구성

기본적으로 Red Hat JBoss Enterprise Application Platform은 마스터 도메인 컨트롤러에 연결된 각 슬레이브 컨트롤러의 인증이 필요하므로 마스터 도메인 컨트롤러를 구성합니다.

프로시저를 사용하여 적절한 자격 증명을 사용하여 슬레이브 컨트롤러를 구성합니다.

절차

  1. add-user 스크립트를 사용하여 사용자를 마스터 도메인 컨트롤러에 추가합니다.

    1. 마스터가 관리 인터페이스를 보호하기 위해 사용하는 것과 동일한 영역에 사용자가 추가되었는지 확인합니다(기본적으로 ManagementRealm ).
    2. 다음 예와 같이 슬레이브 사용자를 추가합니다. Is this new user going to be used for one AS process to connect to another AS process? (이 새로운 사용자가 다른 AS 프로세스에 연결하는 데 사용할 이 사용자 )를 선택합니다.

      $ EAP_HOME/bin/add-user.sh
      
      What type of user do you wish to add?
       a) Management User (mgmt-users.properties)
       b) Application User (application-users.properties)
      (a): a
      
      Enter the details of the new user to add.
      Using realm 'ManagementRealm' as discovered from the existing property files.
      Username : slave-user
      Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
       - The password should be different from the username
       - The password should not be one of the following restricted values {root, admin, administrator}
       - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
      Password :
      Re-enter Password :
      What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[  ]:
      About to add user 'slave-user' for realm 'ManagementRealm'
      Is this correct yes/no? yes
      Added user 'slave-user' to file '/home/user/EAP-7.4.0/standalone/configuration/mgmt-users.properties'
      Added user 'slave-user' to file '/home/user/EAP-7.4.0/domain/configuration/mgmt-users.properties'
      Added user 'slave-user' with groups  to file '/home/user/EAP-7.4.0/standalone/configuration/mgmt-groups.properties'
      Added user 'slave-user' with groups  to file '/home/user/EAP-7.4.0/domain/configuration/mgmt-groups.properties'
      Is this new user going to be used for one AS process to connect to another AS process?
      e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
      yes/no? yes
      To represent the user add the following to the server-identities definition <secret value="ABCzc3dv11Qx" />
      중요

      사용자를 추가한 후 스크립트는 <secret> 요소를 출력합니다. 다음 단계에서 이 요소를 사용해야 합니다.

  2. 자격 증명을 사용하도록 슬레이브 컨트롤러를 구성합니다. 마스터 도메인 컨트롤러에서 사용자를 생성한 후 호스트 구성 파일에서 해당 자격 증명을 사용하도록 각 슬레이브 컨트롤러를 업데이트해야 합니다. 예: host.xml 또는 host-slave.xml.

    다음 예제에서는 사용자 이름을 도메인 컨트롤러 구성의 <remote> 요소에 추가하는 방법을 보여줍니다. 또한 예제에서는 <secret>을 <secret><remote> 요소를 보호하는 데 사용되는 영역의 server-identities 에 추가하는 방법을 보여줍니다.

    참고

    이전 단계의 마스터 도메인 컨트롤러에 사용자를 추가하여 사용자 이름과 <secret> 을 모두 가져올 수 있었습니다.

    ...
    <security-realm name="ManagementRealm">
        <server-identities>
            <!-- Replace this with either a base64 password of your own, or use a vault with a vault expression -->
            <secret value="ABCzc3dv11Qx"/>
        </server-identities>
    ...
    <domain-controller>
      <remote security-realm="ManagementRealm" username="slave-user">
          <discovery-options>
              <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9990}"/>
          </discovery-options>
      </remote>
    </domain-controller>

추가 리소스

  • 관리형 도메인 운영 모드의 개념 및 일반 구성에 대한 자세한 내용은 JBoss EAP 구성 가이드도메인 관리 섹션을 참조하십시오.
  • 사용자 관리에 대한 자세한 내용은 JBoss EAP 구성 가이드관리 사용자 섹션 .

2.3. Elytron를 사용하여 도메인 컨트롤러에 대한 SSL 또는 TLS 구성

관리형 도메인에서 마스터 도메인 컨트롤러와 호스트 컨트롤러 간에 서로 통신할 때 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security)를 사용하도록 JBoss EAP 인스턴스를 구성할 수 있습니다.

중요

관리형 도메인의 JBoss EAP 인스턴스 간에 SSL 또는 TLS를 사용하도록 구성하면 각 인스턴스에 상호 작용에 따라 클라이언트 또는 서버 역할이 있을 수 있습니다. 여기에는 모든 호스트 컨트롤러 및 도메인 컨트롤러가 포함됩니다. 최상의 결과를 얻으려면 끝점 간에 양방향 SSL 또는 TLS를 설정합니다.

사전 요구 사항

  • 필요한 모든 인증서 및 키 저장소를 생성하고 구성합니다. 관리 인터페이스에 대해 양방향 SSL/TLS를 활성화하려면 보안 명령을 사용하여 양방향 SSL/TLS 활성화 또는 Elytron 하위 시스템 명령을 사용하여 양방향 SSL/TLS 활성화를 참조하십시오.

    참고

    끝점 간에 양방향 SSL 또는 TLS를 설정하려면 마스터 도메인 컨트롤러와 각 호스트 컨트롤러에 대한 인증서 및 키 저장소를 생성하고 구성해야 합니다.

    또한 마스터 도메인 컨트롤러의 인증서를 각 호스트 컨트롤러 키 저장소로 가져와야 합니다. 또한 각 호스트 컨트롤러 인증서를 마스터 도메인 컨트롤러 키 저장소로 가져옵니다.

절차

  1. 마스터 도메인 컨트롤러에 사용자를 추가합니다. 기본 파일 기반 사용자 및 그룹 인증 메커니즘을 다시 사용하는 경우 EAP_HOME/bin/add-user.sh 스크립트를 실행합니다. 메시지가 표시되면 사용자 이름, 암호 및 기타 구성을 추가합니다.

    참고

    관리 사용자의 기본 영역 이름은 ManagementRealm 입니다. add-user 유틸리티에서 영역 이름을 묻는 메시지가 표시되면 기본 영역 이름(즉, 다른 영역으로 전환하지 않은 경우)을 수락해야 합니다.

    참고

    슬레이브 컨트롤러의 마스터 도메인 컨트롤러에 사용자를 인증해야 합니다.

    참고

    서버는 속성 파일의 내용을 메모리에 캐시합니다. 그러나 서버는 각 인증 요청에 있는 속성 파일의 수정된 시간을 확인하고 시간이 업데이트되면 다시 로드합니다. 따라서 add-user 유틸리티의 모든 변경 사항은 실행 중인 모든 서버에 즉시 적용됩니다.

  2. SSL 또는 TLS를 사용하도록 마스터 도메인 컨트롤러를 구성합니다. 다음 예제에서는 서버 키 저장소 및 truststore 에 대한 도메인 컨트롤러 키 저장소 ,key-manager,trust-manager, server-ssl-context 를 구성하는 명령을 보여줍니다.

    /host=master/subsystem=elytron/key-store=twoWayKS:add(path=/path/to/server.keystore.jks,credential-reference={clear-text=secret},type=JKS)
    
    /host=master/subsystem=elytron/key-store=twoWayTS:add(path=/path/to/server.truststore.jks,credential-reference={clear-text=secret},type=JKS)
    
    /host=master/subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS,credential-reference={clear-text=secret})
    
    /host=master/subsystem=elytron/trust-manager=twoWayTM:add(key-store=twoWayTS)
    
    /host=master/subsystem=elytron/server-ssl-context=twoWaySSC:add(key-manager=twoWayKM,protocols=["TLSv1.2"],trust-manager=twoWayTM,want-client-auth=true,need-client-auth=true)
    
    /host=master/core-service=management/management-interface=http-interface:write-attribute(name=ssl-context, value=twoWaySSC)
    중요

    Elytron 하위 시스템에서 KeyManagerfactory.getDefaultAlgorithm() 및 TrustManager factory.getDefaultAlgorithm() 를 사용하여 기본적으로 알고리즘을 결정하므로 이전 명령에서 algorithm을 지정하지 않았습니다. 그러나 알고리즘 특성을 지정할 수 있습니다. 알고리즘 특성을 지정하려면 JDK에서 제공하는 키 관리자 알고리즘이 무엇인지 알아야 합니다. 예를 들어 SunJSSE를 사용하는 JDK는 PKIXSunX509 알고리즘을 제공합니다.

    이전 명령에서 SunX509 를 키 관리자 알고리즘 특성으로 지정하고 PKIX 를 신뢰 관리자 알고리즘 속성으로 지정할 수 있습니다.

    또한 지원하려는 HTTPS 프로토콜을 확인해야 합니다. 이 절차의 예제에서는 TLSv1.2 를 사용합니다.

    cipher-suite-filter 를 사용하여 암호화 제품군과 use-cipher-suites-order 인수를 사용하여 서버 암호화 제품군 순서를 준수할 수 있습니다. use-cipher-suites-order 속성은 기본적으로 true 로 설정됩니다. 이는 기본적으로 클라이언트 암호화 모음 순서를 준수하는 레거시 보안 하위 시스템 동작과 다릅니다.

  3. 각 슬레이브 호스트 컨트롤러에서 인증 컨텍스트 및 도메인 컨트롤러 위치를 구성합니다. 다음 예제 구성은 localhost 에 존재하는 도메인 컨트롤러를 보여줍니다.

    참고

    해당 환경의 올바른 관리 사용자, 암호 및 도메인 컨트롤러 위치를 지정해야 합니다.

    /host=slave1/subsystem=elytron/authentication-context=slaveHostSSLContext:add()
    
    /host=slave1/subsystem=elytron/authentication-configuration=slaveHostSSLConfiguration:add()
    
    /host=slave1/subsystem=elytron/authentication-configuration=slaveHostSSLConfiguration:write-attribute(name=sasl-mechanism-selector,value=DIGEST-MD5)
    
    /host=slave1/subsystem=elytron/authentication-configuration=slaveHostSSLConfiguration:write-attribute(name=authentication-name,value=slave)
    
    /host=slave1/subsystem=elytron/authentication-configuration=slaveHostSSLConfiguration:write-attribute(name=realm,value=ManagementRealm)
    
    /host=slave1/subsystem=elytron/authentication-configuration=slaveHostSSLConfiguration:write-attribute(name=credential-reference,value={clear-text=password1!})
    
    /host=slave1/subsystem=elytron/authentication-context=slaveHostSSLContext:write-attribute(name=match-rules,value=[{match-host=localhost,authentication-configuration=slaveHostSSLConfiguration}]
    
    /host=slave1:write-remote-domain-controller(host=localhost,port=9990,protocol=remote,authentication-context=slaveHostSSLContext)
  4. SSL 또는 TLS를 사용하도록 각 슬레이브 호스트 컨트롤러를 구성합니다. 다음 명령은 서버 키 저장소 및 truststore 에 대한 슬레이브 호스트 컨트롤러 키- 저장소 ,key-manager,trust-manager,client-ssl-context, authentication-context 를 구성합니다. 또한 이 예제에서는 localhost 에 존재하는 도메인 컨트롤러를 보여줍니다.

    참고

    환경에 맞는 올바른 도메인 컨트롤러 위치를 지정해야 합니다.

    /host=slave1/subsystem=elytron/key-store=twoWayKS:add(path=/path/to/client.keystore.jks,credential-reference={clear-text=secret},type=JKS)
    
    /host=slave1/subsystem=elytron/key-store=twoWayTS:add(path=/path/to/client.truststore.jks,credential-reference={clear-text=secret},type=JKS)
    
    /host=slave1/subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS,credential-reference={clear-text=secret})
    
    /host=slave1/subsystem=elytron/trust-manager=twoWayTM:add(key-store=twoWayTS)
    
    /host=slave1/subsystem=elytron/client-ssl-context=twoWayCSC:add(key-manager=twoWayKM,protocols=["TLSv1.2"],trust-manager=twoWayTM)
    
    /host=slave1/subsystem=elytron/authentication-context=slaveHostSSLContext:write-attribute(name=match-rules,value=[{match-host=localhost,authentication-configuration=slaveHostSSLConfiguration,ssl-context=twoWayCSC}])
    중요

    Elytron 하위 시스템에서 KeyManagerfactory.getDefaultAlgorithm() 및 TrustManager factory.getDefaultAlgorithm() 를 사용하여 기본적으로 알고리즘을 결정하므로 이전 명령에서 algorithm을 지정하지 않았습니다. 그러나 알고리즘 특성을 지정할 수 있습니다. 알고리즘 특성을 지정하려면 JDK에서 제공하는 키 관리자 알고리즘이 무엇인지 알아야 합니다. 예를 들어 SunJSSE를 사용하는 JDK는 PKIXSunX509 알고리즘을 제공합니다.

    이전 명령에서 SunX509 를 키 관리자 알고리즘 특성으로 지정하고 PKIX 를 신뢰 관리자 알고리즘 속성으로 지정할 수 있습니다.

    또한 지원하려는 HTTPS 프로토콜을 확인해야 합니다. 이 절차의 예제에서는 TLSv1.2 를 사용합니다.

    cipher-suite-filter 를 사용하여 암호화 제품군과 use-cipher-suites-order 인수를 사용하여 서버 암호화 제품군 순서를 준수할 수 있습니다. use-cipher-suites-order 속성은 기본적으로 true 로 설정됩니다. 이는 기본적으로 클라이언트 암호화 모음 순서를 준수하는 레거시 보안 하위 시스템 동작과 다릅니다.

  5. 관리형 도메인에서 모든 JBoss EAP 호스트를 다시 로드합니다.

추가 리소스

  • 관리형 도메인 운영 모드의 개념 및 일반 구성에 대한 자세한 내용은 JBoss EAP 구성 가이드도메인 관리 섹션을 참조하십시오.
  • 사용자 관리에 대한 자세한 내용은 JBoss EAP 구성 가이드관리 사용자 섹션 .

2.4. Elytron를 사용하여 도메인 모드에서 SSL 구성

JBoss EAP 7.1 이상 버전에서는 Elytron를 사용하여 도메인 모드에서 SSL을 구성할 수 있습니다.

사전 요구 사항

  • JBoss EAP 7.1 이상.
  • Elytron

절차

  1. 자체 서명된 인증서를 생성하여 SSL을 활성화합니다.

    keytool -genkey -alias jboss -keysize 2048 -validity 365 -keyalg RSA -sigalg SHA256withRSA -keystore jboss.jks -storepass jboss@123 -keypass jboss@123 -dname "CN=example.com, OU=JavaEE, O=Red Hat, C=IN"
  2. 관리 CLI를 사용하여 키 저장소, key-manager, ssl-context를 생성합니다.

    #Configure a keystore
    /profile=<profile-name>/subsystem=elytron/key-store=httpsKS:add(path="${jboss.home.dir}/ssl/jboss.jks", credential-reference={clear-text=jboss@123}, type=JKS)
    
    #Create a new key-manager
    /profile=<profile-name>/subsystem=elytron/key-manager=httpsKM:add(key-store=httpsKS,algorithm="SunX509",credential-reference={clear-text=jboss@123})
    
    #Configure new server-ssl-context reference with protocol and ciphers
    /profile=<profile-name>/subsystem=elytron/server-ssl-context=httpsSSC:add(key-manager=httpsKM,protocols=["TLSv1.2"])
  3. Elytron ssl-context 를 매핑하도록 VDDK 하위 시스템을 구성합니다.

    batch
    /profile=<profile-name>/subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
    /profile=<profile-name>/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=httpsSSC)
    run-batch
  4. 선택 사항: 동일한 ssl-context 를 사용하도록 management-interface 를 보호합니다.

    host-*.xml 파일은 관리 인터페이스가 포함된 도메인 컨트롤러 및 호스트 컨트롤러에 대한 구성을 정의합니다. SSL이 성공적으로 구성되었는지 확인하려면 호스트에서 ssl-context 를 다시 정의해야 합니다.

    #Configure a keystore on the master DC host
    /host=<host-name>/subsystem=elytron/key-store=httpsKS:add(path="${jboss.home.dir}/ssl/jboss.jks", credential-reference={clear-text=jboss@123}, type=JKS)
    
    #Create a new key-manager on the master DC host
    /host=<host-name>/subsystem=elytron/key-manager=httpsKM:add(key-store=httpsKS,algorithm="SunX509",credential-reference={clear-text=jboss@123})
    
    #Configure new server-ssl-context reference with protocol and ciphers on the master DC host
    /host=<host-name>/subsystem=elytron/server-ssl-context=httpsSSC:add(key-manager=httpsKM,protocols=["TLSv1.2"])
    
    #Configure the secure-port and ssl-context for management-http interface  on the master DC host
    /host=<host-name>/core-service=management/management-interface=http-interface:write-attribute(name=ssl-context,value=httpsSSC)
    
    /host=<host-name>/core-service=management/management-interface=http-interface:write-attribute(name=secure-port,value=9993)
  5. 원격 호스트 컨트롤러가 SSL을 통해 도메인 컨트롤러에 연결할 수 있도록 truststore가 올바르게 구성되었는지 확인합니다. 자세한 내용은 Elytron을 사용하여 도메인 및 호스트 컨트롤러 간 SSL/TLS 구성을 참조하십시오.
  6. 서버를 다시 로드하여 변경 사항이 적용되었는지 확인합니다.

    reload --host=<host-name>

검증

  • Red Hat Enterprise Linux 명령줄에서 브라우저 또는 openSSL을 사용하여 TLS 연결을 확인합니다.

    openssl s_client -connect host:8443

    출력에는 인증서 및 사용된 TLS 버전에 대한 정보가 표시됩니다.

    SSL-Session:
    Protocol: TLSv1.2

2.5. 레거시 코어 관리 인증 메커니즘을 위한 SSL 또는 TLS 구성

관리형 도메인에서 마스터 도메인 컨트롤러와 호스트 컨트롤러 간에 서로 통신할 때 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security)를 사용하도록 JBoss EAP 인스턴스를 구성할 수 있습니다.

중요

관리형 도메인의 JBoss EAP 인스턴스 간에 SSL 또는 TLS를 사용하도록 구성하면 각 인스턴스에 상호 작용에 따라 클라이언트 또는 서버 역할이 있을 수 있습니다. 여기에는 모든 호스트 컨트롤러 및 도메인 컨트롤러가 포함됩니다. 최상의 결과를 얻으려면 끝점 간에 양방향 SSL 또는 TLS를 설정합니다.

사전 요구 사항

  • 필요한 모든 인증서 및 키 저장소를 생성하고 구성합니다. 관리 인터페이스에 대해 양방향 SSL/TLS를 활성화하려면 레거시 코어 관리 인증을 사용하여 관리 인터페이스에 대한 양방향 SSL/TLS 설정을 참조하십시오.

    참고

    끝점 간에 양방향 SSL 또는 TLS를 설정하려면 마스터 도메인 컨트롤러와 각 호스트 컨트롤러에 대한 인증서 및 키 저장소를 생성하고 구성해야 합니다.

    또한 마스터 도메인 컨트롤러의 인증서를 각 호스트 컨트롤러 키 저장소로 가져와야 합니다. 또한 각 호스트 컨트롤러 인증서를 마스터 도메인 컨트롤러 키 저장소로 가져옵니다.

절차

  1. 다음 예에 설명된 대로 SSL 또는 TLS를 사용하도록 마스터 도메인 컨트롤러를 구성합니다. 모든 인증서와 키 저장소를 구성한 경우 양방향 SSL/TLS를 사용하도록 보안 영역을 구성해야 합니다. SSL/TLS를 사용하도록 보안 영역을 구성하여 이를 수행할 수 있습니다. 구성된 보안 영역은 호스트 컨트롤러와 마스터 도메인 컨트롤러 간의 연결에 사용되는 관리 인터페이스를 보호합니다.

    참고

    배치 모드 또는 서버에서 다음 명령을 실행합니다. ssl 서버 ID를 추가한 후 서버를 다시 로드해야 합니다. 이 절차의 예는 배치 모드에서 실행됩니다.

    batch
    
    /host=master/core-service=management/security-realm=CertificateRealm:add()
    
    /host=master/core-service=management/security-realm=CertificateRealm/server-identity=ssl:add(alias=domaincontroller,keystore-relative-to=jboss.domain.config.dir,keystore-path=domaincontroller.jks,keystore-password=secret)
    
    /host=master/core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-relative-to=jboss.domain.config.dir,keystore-path=domaincontroller.jks,keystore-password=secret)
    
    /host=master/core-service=management/security-realm=CertificateRealm/authentication=local:add(default-user=\$local)
    
    /host=master/core-service=management/security-realm=CertificateRealm/authentication=properties:add(relative-to=jboss.domain.config.dir,path=mgmt-users.properties)
    
    /host=master/core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=CertificateRealm)
    
    run-batch
  2. 다음 예와 같이 SSL 또는 TLS를 사용하도록 모든 호스트 컨트롤러를 구성합니다.

    batch
    
    /host=instance1/core-service=management/security-realm=CertificateRealm:add()
    
    /host=instance1/core-service=management/security-realm=CertificateRealm/server-identity=ssl:add(alias=instance1,keystore-relative-to=jboss.domain.config.dir,keystore-path=instance1.jks,keystore-password=secret)
    
    /host=instance1/core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-relative-to=jboss.domain.config.dir,keystore-path=instance1.jks,keystore-password=secret)
    
    /host=instance1/core-service=management/security-realm=CertificateRealm/authentication=local:add(default-user="\$local")
    
    /host=instance1/core-service=management/security-realm=CertificateRealm/authentication=properties:add(relative-to=jboss.domain.config.dir,path=mgmt-users.properties)
    
    /host=instance1/core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=CertificateRealm)
    
    run-batch
  3. 마스터 도메인 컨트롤러를 연결할 때 사용되는 보안 영역을 업데이트합니다. 서버가 실행되고 있지 않은 경우 호스트 컨트롤러 구성 파일에 이 업데이트를 수행해야 합니다. 예: host.xml 또는 host-slave.xml.

    <domain-controller>
      <remote security-realm="CertificateRealm" username="slave-user">
        <discovery-options>
          <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9990}"/>
        </discovery-options>
      </remote>
    </domain-controller>

추가 리소스

3장. 서버 및 관리 인터페이스의 사용자 보안

3.1. Elytron을 사용한 사용자 인증

3.1.1. 기본 설정

기본적으로 JBoss EAP 관리 인터페이스는 레거시 코어 관리 인증으로 보호됩니다.

예제: 기본 설정

/core-service=management/management-interface=http-interface:read-resource()
{
    "outcome" => "success",
    "result" => {
        "allowed-origins" => undefined,
        "console-enabled" => true,
        "http-authentication-factory" => undefined,
        "http-upgrade" => {"enabled" => true},
        "http-upgrade-enabled" => true,
        "sasl-protocol" => "remote",
        "secure-socket-binding" => undefined,
        "security-realm" => "ManagementRealm",
        "server-name" => undefined,
        "socket-binding" => "management-http",
        "ssl-context" => undefined
    }

JBoss EAP는 관리 인터페이스 보안을 위해 elytron 하위 시스템에서 management-http-authentication 및 management-sasl-authentication 을 제공합니다.

기본 Elytron 구성 요소를 사용하도록 JBoss EAP를 업데이트하려면 다음을 수행합니다.

  1. management-http -authentication을 사용하도록 http-authentication- factory 를 설정합니다.

    /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=management-http-authentication)
  2. management -sasl-authentication을 사용하는 Setsasl-authentication- factory:

    /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=management-sasl-authentication)
  3. security-realm 을 undefine :

    /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm)
  4. 변경 사항을 적용하기 위해 JBoss EAP를 다시 로드합니다.
reload

이제 관리 인터페이스는 elytron 하위 시스템에서 제공하는 기본 구성 요소를 사용하여 보안을 설정합니다.

3.1.1.1. 기본 Elytron HTTP 인증 구성

예를 들어 웹 기반 관리 콘솔을 사용할 때 http를 통해 관리 인터페이스에 액세스하는 경우 JBoss EAP는 management-http-authentication http-authentication -factory를 사용합니다.

/subsystem=elytron/http-authentication-factory=management-http-authentication:read-resource()
{
    "outcome" => "success",
    "result" => {
        "http-server-mechanism-factory" => "global",
        "mechanism-configurations" => [{
            "mechanism-name" => "DIGEST",
            "mechanism-realm-configurations" => [{"realm-name" => "ManagementRealm"}]
        }],
        "security-domain" => "ManagementDomain"
    }
}

management-http-authentication http-authentication-factory는 ManagementDomain 보안 도메인을 사용하도록 구성됩니다.

/subsystem=elytron/security-domain=ManagementDomain:read-resource()
{
    "outcome" => "success",
    "result" => {
        "default-realm" => "ManagementRealm",
        "permission-mapper" => "default-permission-mapper",
        "post-realm-principal-transformer" => undefined,
        "pre-realm-principal-transformer" => undefined,
        "principal-decoder" => undefined,
        "realm-mapper" => undefined,
        "realms" => [
            {
                "realm" => "ManagementRealm",
                "role-decoder" => "groups-to-roles"
            },
            {
                "realm" => "local",
                "role-mapper" => "super-user-mapper"
            }
        ],
        "role-mapper" => undefined,
        "trusted-security-domains" => undefined
    }
}

ManagementDomain 보안 도메인은 속성 기반 영역인 ManagementRealm Elytron 보안 영역에서 지원합니다.

중요

속성 기반 영역은 서버가 시작될 때만 읽습니다. 수동으로 또는 add-user 스크립트를 사용하여 서버를 시작한 후에 추가된 사용자는 서버를 다시 로드해야 합니다. 이 다시 로드는 관리 CLI에서 reload 명령을 실행하여 수행합니다.

reload
/subsystem=elytron/properties-realm=ManagementRealm:read-resource()
{
    "outcome" => "success",
    "result" => {
        "groups-attribute" => "groups",
        "groups-properties" => {
            "path" => "mgmt-groups.properties",
            "relative-to" => "jboss.server.config.dir"
        },
        "plain-text" => false,
        "users-properties" => {
            "path" => "mgmt-users.properties",
            "relative-to" => "jboss.server.config.dir"
        }
    }
}

3.1.1.2. 기본 Elytron 관리 CLI 인증

기본적으로 관리 CLI(jboss-cli.sh)는 remote+http 를 통해 연결하도록 구성됩니다.

예제: 기본 jboss-cli.xml

<jboss-cli xmlns="urn:jboss:cli:3.1">

    <default-protocol use-legacy-override="true">remote+http</default-protocol>

    <!-- The default controller to connect to when 'connect' command is executed w/o arguments -->
    <default-controller>
        <protocol>remote+http</protocol>
        <host>localhost</host>
        <port>9990</port>
    </default-controller>

그러면 HTTP를 통한 연결이 설정되고 HTTP 업그레이드를 사용하여 통신 프로토콜을 Remoting 으로 변경합니다. HTTP 업그레이드 연결은 a sasl-authentication -factory를 사용하여 http-interface 의 http- upgrade 섹션에서 보호됩니다.

예제: 기본 구성 요소로 구성

/core-service=management/management-interface=http-interface:read-resource()
{
    "outcome" => "success",
    "result" => {
        "allowed-origins" => undefined,
        "console-enabled" => true,
        "http-authentication-factory" => "management-http-authentication",
        "http-upgrade" => {
            "enabled" => true,
            "sasl-authentication-factory" => "management-sasl-authentication"
        },
        "http-upgrade-enabled" => true,
        "sasl-protocol" => "remote",
        "secure-socket-binding" => undefined,
        "security-realm" => undefined,
        "server-name" => undefined,
        "socket-binding" => "management-http",
        "ssl-context" => undefined
    }
}

기본 sasl-authentication-factory는 management-sasl-authentication 입니다.

/subsystem=elytron/sasl-authentication-factory=management-sasl-authentication:read-resource()
{
    "outcome" => "success",
    "result" => {
        "mechanism-configurations" => [
            {
                "mechanism-name" => "JBOSS-LOCAL-USER",
                "realm-mapper" => "local"
            },
            {
                "mechanism-name" => "DIGEST-MD5",
                "mechanism-realm-configurations" => [{"realm-name" => "ManagementRealm"}]
            }
        ],
        "sasl-server-factory" => "configured",
        "security-domain" => "ManagementDomain"
    }
}

management-sasl-authentication sasl-authentication-factory는 JBOSS-LOCAL-USERDIGEST-MD5 메커니즘을 지정합니다.

DIGEST-MD5에 사용되는 ManagementRealm Elytron 보안 영역은 management- http-authentication http-authentication- factory에서 사용되는 영역과 같습니다.

예제: JBOSS-LOCAL-USER Realm

/subsystem=elytron/identity-realm=local:read-resource()
{
    "outcome" => "success",
    "result" => {
        "attribute-name" => undefined,
        "attribute-values" => undefined,
        "identity" => "$local"
    }
}

로컬 Elytron 보안 영역은 로컬 사용자에 대한 자동 인증을 처리하는 것입니다.

3.1.2. 새 ID 저장소로 관리 인터페이스 보안

  1. 보안 도메인 및 ID 저장소에 대해 지원하는 보안 영역, 디코더 또는 매퍼를 만듭니다.

    이 프로세스는 JBoss EAP의 Elytron subsystem 섹션에서 ID 관리 가이드를 구성하는 방법에 대해 설명합니다. 예를 들어 파일 시스템 기반 ID 저장소를 사용하여 관리 인터페이스를 보호하려면 파일 시스템 기반 ID 저장소로 인증 구성 단계를 따릅니다.

  2. http-authentication-factory or sasl-authentication-factory 를 만듭니다.

    예: http-authentication-factory

    /subsystem=elytron/http-authentication-factory=example-http-auth:add(http-server-mechanism-factory=global, security-domain=exampleSD, mechanism-configurations=[{mechanism-name=DIGEST, mechanism-realm-configurations=[{realm-name=exampleManagementRealm}]}])

    예: sasl-authentication-factory

    /subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured, security-domain=exampleSD, mechanism-configurations=[{mechanism-name=DIGEST-MD5, mechanism-realm-configurations=[{realm-name=exampleManagementRealm}]}])

  3. 구성된 구성 가능-sasl-server-factory에 pattern- filter를 추가합니다.

    예제: 구성된 구성 가능-sasl-server-factory에 GSSAPI 추가

    /subsystem=elytron/configurable-sasl-server-factory=configured:list-add(name=filters, value={pattern-filter=GSSAPI})

    선택적 단계입니다. 클라이언트가 HTTP 관리 인터페이스에 연결하려고 하면 JBoss EAP는 401 Unauthorized 상태 코드와 지원되는 인증 메커니즘을 나열하는 일련의 헤더(예: Digest, GSSAPI 등)를 사용하여 HTTP 응답을 다시 보냅니다. 자세한 내용은 JBoss EAP 보안 아키텍처 가이드 의 HTTP 인터페이스로 로컬 및 원격 클라이언트 인증 섹션을 참조하십시오.

  4. http-authentication-factory or sasl-authentication-factory 를 사용하도록 관리 인터페이스를 업데이트합니다.

    예제: http-authentication-factory 업데이트

    /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=example-http-auth)
    
    reload

    예제: sasl-authentication-factory 업데이트

    /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth)
    
    reload

    참고

    레거시 코어 관리 인증을 사용하는 경우 단일 레거시 보안 영역으로 http 관리 인터페이스만 보안할 수 있습니다. 이렇게 하면 HTTP 및 SASL 구성이 하나의 레거시 보안 영역에 강제로 표시됩니다. elytron 하위 시스템을 사용하는 경우 http-authentication-factory 및 sasl- authentication-factory 를 별도로 구성하여 http 관리 인터페이스의 HTTP 및 SASL 메커니즘을 보호하기 위해 개별 보안 도메인을 사용할 수 있습니다.

참고

레거시 보안과 Elytron에서 유사한 두 가지 특성이 관리 인터페이스에서 각각 구성된 경우 Elytron 관련 구성만 사용됩니다. 예를 들어 레거시 보안을 위한 security-realm 과 Elytron용 http-authentication-factory 가 구성된 경우 인증은 http-authentication-factory 구성으로 처리됩니다.

참고

관리 인터페이스에 HTTP 인터페이스의 http-authentication-factory, 또는 sasl-authentication-factorysecurity-realm 이 포함되고 ssl-context 특성이 사용되지 않는 경우 인증은 Elytron에서 처리하고 SSL은 레거시 보안 영역에 의해 처리됩니다.

관리 인터페이스에 security-realm 및 ssl- context 가 모두 포함되고 HTTP 인터페이스의 http- authentication-factory 또는sasl-authentication-factory 가 사용되지 않으면 기존 보안 영역에서 인증을 처리하고 SSL을 Elytron에서 처리합니다.

3.1.3. 음소거 인증 추가

기본적으로 JBoss EAP는 로컬 보안 영역을 통해 자동 인증이라고도 하는 로컬 사용자에 대한 인증 메커니즘을 제공합니다. 자세한 내용은 Silent 인증 섹션을 참조하십시오.

a sasl-authentication-factory 에 자동 인증을 추가해야 합니다.

existing sasl-authentication-factory 에 자동 인증을 추가하려면 다음을 수행합니다.

/subsystem=elytron/sasl-authentication-factory=example-sasl-auth:list-add(name=mechanism-configurations, value={mechanism-name=JBOSS-LOCAL-USER, realm-mapper=local})

reload

자동 인증을 사용하여 new sasl-server-factory 를 생성하려면 다음을 수행합니다.

/subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured,security-domain=ManagementDomain,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=exampleManagementRealm}]},{mechanism-name=JBOSS-LOCAL-USER, realm-mapper=local}])

reload
참고

위의 예제에서는 기존 ManagementDomain 보안 도메인을 사용하지만 다른 보안 도메인을 생성하고 사용할 수도 있습니다. JBoss EAP How to Configure Identity Management GuideElytron subsystem 섹션에서 보안 도메인을 생성하는 더 많은 예를 확인할 수 있습니다.

중요

Elytron 보안이 사용되고 인증 시도가 실제 ID에 일치하지 않는 인증 이름과 JBOSS-LOCAL-USER SASL 메커니즘을 사용하면 인증에 실패합니다.

기존 보안 하위 시스템에서 JBOSS-LOCAL-USER 에 대한 사용자 지정 사용자 이름을 선택할 수 있습니다. 여기에서 사용자 이름을 특수 ID에 매핑하여 인증이 진행됩니다.

3.1.4. 인증된 관리 사용자의 ID 매핑

elytron 하위 시스템을 사용하여 관리 인터페이스를 보호하는 경우 인증된 사용자의 ID 매핑을 위한 관리 인터페이스에 보안 도메인을 제공할 수 있습니다. 이렇게 하면 인증된 사용자가 관리 인터페이스에 로그인할 때 적절한 ID로 표시할 수 있습니다.

애플리케이션 서버에서 두 가지 이상의 유형의 관리 인터페이스를 노출합니다. 각 유형의 인터페이스를 독립 인증 팩토리와 연결하여 해당 인터페이스의 인증 요구 사항을 처리할 수 있습니다.

권한 부여 결정을 내리기 위해 보안 도메인에서 현재 보안 ID를 가져옵니다. 반환된 보안 ID에는 해당 보안 도메인 내에 정의된 규칙에 따라 역할 매핑 및 권한 할당이 있습니다.

참고

대부분의 경우 공통 보안 도메인은 모든 관리에 사용됩니다. 관리 인터페이스 인증은 물론 권한 결정에 사용되는 보안 ID를 획득하는 데 사용됩니다. 이 경우 보안 도메인은 관리 인터페이스의 인증 팩토리와 연결되며 특별한 access=identity 를 정의할 필요가 없습니다.

권한 결정에 대한 ID를 가져오는 데 다른 보안 도메인을 사용하는 경우도 있습니다. 여기에서 access=identity 리소스가 정의됩니다. 권한 부여를 위해 ID를 가져오기 위한 보안 도메인에 대한 참조가 포함되어 있습니다.

아래 예제에서는 example SD Elytron 보안 도메인을 사용하여 관리 인터페이스를 보안했으며 example ManagementRealm 으로 노출한다고 가정합니다.

ID 매핑을 정의하려면 ID 리소스를 관리 인터페이스에 추가합니다.

예제: ID 리소스 추가

/core-service=management/access=identity:add(security-domain=exampleSD)

identity 리소스를 추가했으면 관리 인터페이스에 액세스할 때 인증된 사용자의 ID가 표시됩니다. identity 리소스를 추가하지 않으면 인증에 사용되는 보안 도메인의 ID가 사용됩니다.

예를 들어, 관리 CLI에 user1 로 로그인한 경우 ID가 올바르게 표시됩니다.

예제: 관리 CLI에서 인증된 사용자의 ID 표시

:whoami
{
    "outcome" => "success",
    "result" => {"identity" => {"username" => "user1"}}
}

중요

ID 리소스가 추가되고 레거시 보안 영역이 관리 인터페이스를 보호하는 데 사용되는 경우 인증된 사용자에게 항상 익명 ID가 있습니다. Identity 리소스를 제거하면 레거시 보안 영역에서 인증된 사용자가 적절한 ID와 함께 표시됩니다.

관리 작업에 대한 권한 부여는 항상 access=identity 에 지정된 도메인인 보안 도메인을 사용합니다. 지정하지 않으면 인증에 사용되는 도메인입니다. 모든 역할 매핑은 항상 보안 도메인의 컨텍스트에 있습니다.

현재 요청에 대한 ID 리소스는 Elytron 구성을 사용하여 매핑된 역할 집합을 반환합니다. RBAC 기반 역할 매핑 정의가 사용 중인 경우 identity 리소스의 역할을 그룹으로 가져와 현재 요청에 대한 관리 역할을 가져옵니다.

표 3.1. 다양한 시나리오에 사용할 ID

시나리오access=identity 정의 없음access=Elytron 보안 도메인을 참조하는 ID

레거시 security-realm을 사용하는 HTTP 관리 인터페이스

연결에서 ID.

지원되지 않거나 익명 ID.

security-domain에서 지원하는 elytron HTTP 인증 팩토리를 사용하는 HTTP 관리 인터페이스

연결에서 ID.

성공적으로 유입된 경우 참조된 security-domain 의 ID입니다.

HTTP 업그레이드를 포함한 네이티브 관리, 레거시 보안 영역사용 인터페이스

연결에서 ID.

지원되지 않거나 익명 ID.

HTTP 업그레이드를 포함한 네이티브 관리, 보안 도메인에서 지원하는 elytron SASL 인증 팩토리를 사용한 인터페이스

연결에서 ID.

성공적으로 유입된 경우 참조된 security-domain 의 ID입니다.

참고

ID 리소스에 사용된 보안 도메인이 인증에서 보안 도메인을 신뢰하지 않으면 익명 ID가 사용됩니다.

둘 다 동일한 보안 영역을 사용하는 경우 ID 리소스에 사용되는 보안 도메인은 인증에서 보안 도메인을 신뢰할 필요가 없습니다.

신뢰할 수 있는 보안 도메인이 전이식이 아닙니다.

access=identity 리소스를 정의하지 않은 경우 관리 인터페이스에 대해 인증 중에 설정한 ID가 사용됩니다. 연결을 사용하여 설정된 ID는 원격 하위 시스템을 통해 또는 애플리케이션을 사용하는 경우 사용할 수 없습니다.

access=identity 리소스가 정의되지만 관리 인터페이스에서 사용하는 보안 도메인은 다르며, 수신할 도메인 목록에 나열되지 않은 경우 ID가 설정되지 않습니다. 인증 중에 설정한 ID를 사용하여 inflow가 시도됩니다. 원격 하위 시스템을 통해 또는 애플리케이션을 사용하는 연결을 사용하여 설정된 ID는 이러한 방식으로 유입되지 않습니다.

중요

레거시 보안 영역을 사용하여 관리 인터페이스를 보호하는 경우 다양한 보안 도메인에서 ID를 분리할 수 없습니다. 이 경우 access=identity 리소스를 정의하지 않아야 합니다. 따라서 인증 중에 설정한 ID를 직접 사용할 수 있습니다. 따라서 PicketBox를 사용하여 보안된 애플리케이션은 ID 리소스에 대해 지원되지 않습니다.

3.1.5. 관리 CLI로 Elytron 클라이언트 사용

JBoss EAP에 연결할 때 보안 정보를 제공하기 위해 Elytron Client를 사용하도록 관리 CLI를 구성할 수 있습니다.

  1. Elytron을 사용하여 관리 인터페이스 보안.

    관리 CLI와 함께 Elytron 클라이언트를 사용하려면 Elytron을 사용하여 관리 인터페이스를 보안해야 합니다. Elytron을 사용하여 사용자 인증에서 Elytron을 사용하여 관리 인터페이스 보안에 대한 자세한 내용을 확인할 수 있습니다.

  2. Elytron 클라이언트 구성 파일을 만듭니다.

    인증 구성이 있는 Elytron 클라이언트 구성 파일과 해당 구성을 사용하는 규칙을 만들어야 합니다. 인증 구성 생성에 대한 자세한 내용은 JBoss EAP How to Configure Identity Management GuideThe Configuration File Approach 섹션에서 확인할 수 있습니다.

    예: custom-config.xml

    <configuration>
        <authentication-client xmlns="urn:elytron:client:1.2">
            <authentication-rules>
                <rule use-configuration="configuration1">
                    <match-host name="localhost" />
                </rule>
            </authentication-rules>
            <authentication-configurations>
                <configuration name="configuration1">
                    <sasl-mechanism-selector selector="DIGEST-MD5" />
                    <providers>
                      <use-service-loader />
                    </providers>
                    <set-user-name name="user1" />
                    <credentials>
                        <clear-password password="password123" />
                    </credentials>
                    <set-mechanism-realm name="exampleManagementRealm" />
                 </configuration>
            </authentication-configurations>
        </authentication-client>
    </configuration>

  3. 관리 CLI 스크립트와 함께 Elytron 클라이언트 구성 파일을 사용합니다.

    $ ./jboss-cli.sh -c  -Dwildfly.config.url=/path/to/custom-config.xml

3.2. ID 전파 및 Elytron을 통한 전달

3.2.1. 원격 호출을 위한 보안 ID 전파

JBoss EAP 7.1에서는 클라이언트에서 호출 원격화를 위한 서버로 보안 ID를 전파하도록 서버와 애플리케이션을 쉽게 구성할 수 있는 기능을 도입했습니다. 지정된 사용자의 보안 ID 내에서 실행되도록 서버 구성 요소를 구성할 수도 있습니다.

이 섹션의 예제에서는 보안 ID 자격 증명을 전달하는 방법을 보여줍니다. 또한 클라이언트와 자카르타 Enterprise Bean의 보안 ID를 원격 Jakarta Enterprise Beans에 전파합니다. 원격 Jakarta Enterprise Beans라는 이름의 주체 이름이 포함된 문자열과 사용자의 권한 있는 역할 정보를 반환합니다. 예제는 다음 구성 요소로 구성됩니다.

  • 호출자에 대한 권한 부여 정보를 반환하는 모든 사용자가 액세스할 수 있는 단일 메서드가 포함된 보안 Jakarta Enterprise Beans.
  • 단일 방법을 포함하는 중간 자카르타 엔터프라이즈 빈. 원격 연결을 사용하고 보안 Jakarta Enterprise Beans에서 메서드를 호출합니다.
  • 중간 자카르타 Enterprise Bean을 호출하는 원격 독립 실행형 클라이언트 애플리케이션.
  • 인증에 사용되는 ID 정보가 포함된 META-INF/wildfly-config.xml 파일입니다.

먼저 서버를 구성하여 보안 ID 전파를 활성화해야 합니다. 다음으로 WildFlyInitialContextFactory 를 사용하여 원격 Jakarta Enterprise Bean을 조회하고 호출하는 예제 애플리케이션 코드를 검토합니다.

보안 전파를 위해 서버 설정
  1. Elytron ApplicationDomain 을 사용하도록 ejb3 하위 시스템을 구성합니다.

    /subsystem=ejb3/application-security-domain=quickstart-domain:add(security-domain=ApplicationDomain)

    그러면 다음 application-security-domain 구성이 ejb3 하위 시스템에 추가됩니다.

    <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
        ....
        <application-security-domains>
            <application-security-domain name="quickstart-domain" security-domain="ApplicationDomain"/>
        </application-security-domains>
    </subsystem>
  2. PLAIN 인증 구성을 추가하여 일반 텍스트 사용자 이름과 암호를 전송하고 아웃바운드 연결에 사용할 인증 컨텍스트를 추가합니다. ID 전파를 지원하는 메커니즘 목록은 보안 ID 전파를 지원하는 메커니즘을 참조하십시오.

    /subsystem=elytron/authentication-configuration=ejb-outbound-configuration:add(security-domain=ApplicationDomain,sasl-mechanism-selector="PLAIN")
    /subsystem=elytron/authentication-context=ejb-outbound-context:add(match-rules=[{authentication-configuration=ejb-outbound-configuration}])

    이렇게 하면 다음과 같은 authentication-client 구성이 elytron 하위 시스템에 추가됩니다.

    <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
        <authentication-client>
            <authentication-configuration name="ejb-outbound-configuration" security-domain="ApplicationDomain" sasl-mechanism-selector="PLAIN"/>
            <authentication-context name="ejb-outbound-context">
                <match-rule authentication-configuration="ejb-outbound-configuration"/>
            </authentication-context>
        </authentication-client>
        ....
    </subsystem>
  3. 원격 대상 아웃바운드 소켓 바인딩을 standard-sockets 소켓 바인딩 그룹에 추가합니다.

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=ejb-outbound:add(host=localhost,port=8080)

    그러면 다음과 같은 ejb-outbound 아웃바운드 소켓 바인딩이 standard-sockets 소켓 바인딩 그룹에 추가됩니다.

    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        ....
        <outbound-socket-binding name="ejb-outbound">
            <remote-destination host="localhost" port="8080"/>
        </outbound-socket-binding>
    </socket-binding-group>
  4. 원격 아웃바운드 연결을 추가하고 HTTP 커넥터에서 SASL 인증 팩토리를 설정합니다.

    /subsystem=remoting/remote-outbound-connection=ejb-outbound-connection:add(outbound-socket-binding-ref=ejb-outbound, authentication-context=ejb-outbound-context)
    /subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=sasl-authentication-factory,value=application-sasl-authentication)

    그러면 원격 하위 시스템에 다음의 http-remoting -connector 및 ejb-outbound-connection 구성이 추가됩니다.

    <subsystem xmlns="urn:jboss:domain:remoting:4.0">
        ....
        <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm" sasl-authentication-factory="application-sasl-authentication"/>
        <outbound-connections>
            <remote-outbound-connection name="ejb-outbound-connection" outbound-socket-binding-ref="ejb-outbound" authentication-context="ejb-outbound-context"/>
        </outbound-connections>
    </subsystem>
  5. PLAIN 메커니즘을 사용하도록 Elytron SASL 인증을 구성합니다.

    /subsystem=elytron/sasl-authentication-factory=application-sasl-authentication:write-attribute(name=mechanism-configurations,value=[{mechanism-name=PLAIN},{mechanism-name=JBOSS-LOCAL-USER,realm-mapper=local},{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=ApplicationRealm}]}])

    그러면 다음 application-sasl-authentication 구성이 elytron 하위 시스템에 추가됩니다.

    <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
        ....
        <sasl>
          ....
          <sasl-authentication-factory name="application-sasl-authentication" sasl-server-factory="configured" security-domain="ApplicationDomain">
              <mechanism-configuration>
                  <mechanism mechanism-name="PLAIN"/>
                  <mechanism mechanism-name="JBOSS-LOCAL-USER" realm-mapper="local"/>
                  <mechanism mechanism-name="DIGEST-MD5">
                      <mechanism-realm realm-name="ApplicationRealm"/>
                  </mechanism>
              </mechanism-configuration>
          </sasl-authentication-factory>
      </sasl>
      ....
    </subsystem>

다음 예제 애플리케이션에 대해 보안 전파를 활성화하도록 서버가 구성되었습니다.

보안 ID를 배포하는 예제 애플리케이션 코드 검토

서버 구성에서 보안 ID 전파가 활성화되면 Jakarta Enterprise Beans 클라이언트 애플리케이션에서 WildFlyInitialContextFactory 를 사용하여 Jakarta Enterprise Beans 프록시를 조회하고 호출할 수 있습니다. Jakarta Enterprise Beans는 아래에 표시된 클라이언트 예제에서 인증된 사용자로 호출됩니다. 다음은 JBoss EAP 7.4와 함께 제공되는 ejb-security-context-propagation 빠른 시작에서 축약된 코드 예제입니다. 보안 ID 전파의 전체 작업 예는 빠른 시작을 참조하십시오.

Jakarta Enterprise Bean을 다른 사용자로 호출하려면 컨텍스트 속성에서 Context.SECURITY_PRINCIPALContext.SECURITY_CREDENTIALS 를 설정할 수 있습니다.

예제: 원격 클라이언트

public class RemoteClient {

    public static void main(String[] args) throws Exception {
        // invoke the intermediate bean using the identity configured in wildfly-config.xml
        invokeIntermediateBean();

        // now lets programmatically setup an authentication context to switch users before invoking the intermediate bean
        AuthenticationConfiguration superUser = AuthenticationConfiguration.empty().setSaslMechanismSelector(SaslMechanismSelector.NONE.addMechanism("PLAIN")).
                useName("superUser").usePassword("superPwd1!");
        final AuthenticationContext authCtx = AuthenticationContext.empty().
                with(MatchRule.ALL, superUser);

        AuthenticationContext.getContextManager().setThreadDefault(authCtx);
        invokeIntermediateBean();
    }

    private static void invokeIntermediateBean() throws Exception {
        final Hashtable<String, String> jndiProperties = new Hashtable<>();
        jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
        jndiProperties.put(Context.PROVIDER_URL, "remote+http://localhost:8080");
        final Context context = new InitialContext(jndiProperties);
        IntermediateEJBRemote intermediate = (IntermediateEJBRemote) context.lookup("ejb:/ejb-security-context-propagation/IntermediateEJB!"
                + IntermediateEJBRemote.class.getName());
        // Call the intermediate EJB
        System.out.println(intermediate.makeRemoteCalls());
    }
}

예제: 중간 자카르타 엔터프라이즈 빈

@Stateless
@Remote(IntermediateEJBRemote.class)
@SecurityDomain("quickstart-domain")
@PermitAll
public class IntermediateEJB implements IntermediateEJBRemote {

    @EJB(lookup="ejb:/ejb-security-context-propagation/SecuredEJB!org.jboss.as.quickstarts.ejb_security_context_propagation.SecuredEJBRemote")
    private SecuredEJBRemote remote;

    @Resource
    private EJBContext context;

    public String makeRemoteCalls() {
        try {
            StringBuilder sb = new StringBuilder("** ").
                    append(context.getCallerPrincipal()).
                    append(" * * \n\n");
            sb.append("Remote Security Information: ").
                    append(remote.getSecurityInformation()).
                    append("\n");

            return sb.toString();
        } catch (Exception e) {
            if (e instanceof RuntimeException) {
                throw (RuntimeException) e;
            }
            throw new RuntimeException("Teasting failed.", e);
        }
    }
}

예제: Secure Jakarta Enterprise Bean

@Stateless
@Remote(SecuredEJBRemote.class)
@SecurityDomain("quickstart-domain")
public class SecuredEJB implements SecuredEJBRemote {

    @Resource
    private SessionContext context;

    @PermitAll
    public String getSecurityInformation() {
        StringBuilder sb = new StringBuilder("[");
        sb.append("Principal=[").
                append(context.getCallerPrincipal().getName()).
                append("], ");
        userInRole("guest", sb).append(", ");
        userInRole("user", sb).append(", ");
        userInRole("admin", sb).append("]");
        return sb.toString();
    }
}

예: wildfly-config.xml 파일

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <authentication-client xmlns="urn:elytron:client:1.2">
        <authentication-rules>
            <rule use-configuration="default"/>
        </authentication-rules>
        <authentication-configurations>
            <configuration name="default">
                <set-user-name name="quickstartUser"/>
                <credentials>
                    <clear-password password="quickstartPwd1!"/>
                </credentials>
                <sasl-mechanism-selector selector="PLAIN"/>
                <providers>
                    <use-service-loader />
                </providers>
            </configuration>
        </authentication-configurations>
    </authentication-client>
</configuration>

3.2.2. 권한 부여 전달 모드 사용

자격 증명 전달 외에도 Elytron은 피어 간 ID의 신뢰할 수 있는 사용을 지원합니다. 이 기능은 다음 사례에서 유용할 수 있습니다.

  • 요구 사항은 유선 암호를 보낼 수 없기 때문입니다.
  • 인증 유형은 자격 증명 전달을 지원하지 않는 유형입니다.
  • 환경에서는 전파 요청을 받기 위해 허용되는 시스템을 제한해야 합니다.

권한 부여 전달을 활용하려면 먼저 전달 서버에서 인증 클라이언트를 구성한 다음 수신 서버가 인증을 수락하고 처리하도록 구성합니다.

전달 서버에서 인증 클라이언트 구성

권한 부여 전달을 활성화하려면 서버 구성에서 인증 클라이언트 구성을 구성해야 합니다.

다음 관리 CLI 명령은 기본 인증 클라이언트 구성을 생성하여 인증 전달을 활성화합니다. 필요한 경우 고급 규칙 기반 선택을 구성할 수 있습니다.

예제: 인증 클라이언트 구성을 생성하기 위한 관리 CLI 명령

/subsystem=elytron/authentication-configuration=forwardit:add(authentication-name=theserver1,security-domain=ApplicationDomain,realm=ApplicationRealm,forwarding-mode=authorization,credential-reference={clear-text=thereallysecretpassword})
/subsystem=elytron/authentication-context=forwardctx:add(match-rules=[{authentication-configuration=forwardit,match-no-user=true}])

이러한 명령은 다음과 같은 인증 구성인증-컨텍스트 구성을 elytron 하위 시스템에 추가합니다.

예제: 인증 클라이언트 설정

<authentication-client>
    <authentication-configuration name="forwardit" authentication-name="theserver1" security-domain="ApplicationDomain" forwarding-mode="authorization" realm="ApplicationRealm">
        <credential-reference clear-text="thereallysecretpassword"/>
    </authentication-configuration>
    <authentication-context name="forwardctx">
        <match-rule match-no-user="true" authentication-configuration="forwardit"/>
    </authentication-context>
</authentication-client>

전달 서버가 기본 인증 기반 사용자 이름 및 자격 증명을 사용하는 대신 수신 서버에 연결하는 경우 사전 정의된 서버 로그인 이름 theserver1 을 사용하여 신뢰 관계를 설정합니다.

수신자 서버에서 권한 부여 전달 구성

전달이 성공적으로 완료되려면 전달 서버에서 전달한 서버와 일치하는 ID를 사용하여 수신 서버 구성을 구성해야 합니다. 이 경우 수신 서버에서 올바른 자격 증명을 사용하여 server 1 이라는 사용자를 구성해야 합니다.

또한 전달 서버에서 전달되는 server 1 ID에 대한 ID 스위치를 허용하도록 elytron 하위 시스템에서 "RunAs" 권한 매핑을 구성해야 합니다. 권한 매핑에 대한 자세한 내용은 Create an Elytron Permission Mapper in How to Configure Server Security for JBoss EAP를 참조하십시오.

아래 명령은 다음 구성이 포함된 auth -forwarding-per라는 simple-permission-mapper 를 추가합니다.

  • 사용자 anonymous 에 대한 권한 매핑. 이 사용자는 익명 사용자가 로그인할 수 없도록 하는 권한이 없습니다.
  • 사용자 theserver1 에 대한 권한 매핑. 이 사용자에게는 *RunAsPrincipalPermission 권한이 할당되어 이 사용자에게 모든 ID로 실행할 수 있는 글로벌 권한이 부여됩니다. 원하는 경우 권한을 특정 ID로 제한할 수 있습니다.
  • 다른 모든 사용자에 대한 권한 매핑.

예제: 간단한 권한 맵퍼 만들기에 대한 관리 CLI 명령

/subsystem=elytron/permission-set=run-as-principal-permission:add(permissions=[{class-name="org.wildfly.security.auth.permission.RunAsPrincipalPermission",target-name="*"}])

/subsystem=elytron/simple-permission-mapper=auth-forwarding-permission-mapper:add(permission-mappings=[{principals=["anonymous"]},{principals=["theserver1"],permission-sets=[{permission-set=login-permission},{permission-set=default-permissions},{permission-set=run-as-principal-permission}]},{match-all=true,permission-sets=[{permission-set=login-permission},{permission-set=default-permissions}]}]

이 명령은 다음의 simple-permission-mapper 구성을 elytron 하위 시스템에 추가합니다.

예제: 간단한 권한 매퍼 설정

<mappers>
    <simple-permission-mapper name="auth-forwarding-permission-mapper">
        <permission-mapping>
            <principal name="anonymous"/>
            <!-- No permissions: Deny any permission to anonymous! -->
        </permission-mapping>
        <permission-mapping>
            <principal name="theserver1"/>
            <permission-set name="login-permission"/>
            <permission-set name="default-permissions"/>
            <permission-set name="run-as-principal-permission"/>
        </permission-mapping>
        <permission-mapping match-all="true">
            <permission-set name="login-permission"/>
            <permission-set name="default-permissions"/>
        </permission-mapping>
    </simple-permission-mapper>
</mappers>
<permission-sets>
    <permission-set name="login-permission">
        <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/>
    </permission-set>
    <permission-set name="default-permissions">
        <permission class-name="org.wildfly.extension.batch.jberet.deployment.BatchPermission" module="org.wildfly.extension.batch.jberet" target-name="*"/>
        <permission class-name="org.wildfly.transaction.client.RemoteTransactionPermission" module="org.wildfly.transaction.client"/>
        <permission class-name="org.jboss.ejb.client.RemoteEJBPermission" module="org.jboss.ejb-client"/>
    </permission-set>
    <permission-set name="run-as-principal-permission">
        <permission class-name="org.wildfly.security.auth.permission.RunAsPrincipalPermission" target-name="*"/>
    </permission-set>
</permission-sets>

참고

login-permissiondefault-permissions 권한 세트는 이미 기본 구성에 있습니다.

권한 전달 후 주요 변환기를 사용하는 경우 해당 변환기는 인증 및 권한 부여 주체 모두에 적용됩니다.

3.2.3. case-principal-transformer 를 생성하여 주체 사용자 이름의 케이스 문자를 변경합니다.

elytron 하위 시스템에는 case-principal-transformer 주체 변환기 가 포함됩니다. 이 주체 변환기를 사용하여 주체의 사용자 이름을 대문자 또는 소문자로 변경할 수 있습니다.

case-principal-transformer 주체 변환기에는 기본적으로 true 로 설정된 대문자 특성이 포함되어 있습니다.

case-principal-transformer 의 사용 사례를 시연하려면 인증 메커니즘을 사용하여 주체를 보안 영역에 매핑한다고 고려하십시오. 영역 매퍼는 매핑된 주체를 조작하여 보안 영역을 식별하고 ID 중 하나를 로드합니다. 인증 메커니즘은 ID를 post-realm 매핑 단계 및 최종 주체 변환 단계에 전달합니다. 그런 다음 인증 메커니즘은 인증을 위해 ID를 확인합니다. case-principal-transformer 주체 변환기를 사용하여 매핑된 주체의 문자 케이스 형식을 변환할 수 있습니다.

절차의 예제에서는 보안 도메인 컨텍스트에서 case-principal-transformer 를 사용합니다. 다음 인증 정책에 따라 주요 변환기를 인라인으로 사용할 수도 있습니다.

  • http-authentication-factory
  • sasl-authentication-factory
  • ssl-context
  • aggregate-realm

절차

  1. case-principal-transformerelytron 하위 시스템에 추가하고 사용자 이름에 대한 문자를 선택합니다.

    1. 변환기의 사용자 이름을 대문자로 변경하려면 기본 대문자 특성 값을 변경하지 마십시오.

      기본 대문자 특성 설정이 정의된 elytron 하위 시스템에 <transformer_name> 표시 예:

      /subsystem=elytron/case-principal-transformer=<transformer_name>:add(upper-case="true")

      또는 기본 대문자 특성 값을 사용하도록 명령 구문을 줄일 수 있습니다.

      /subsystem=elytron/case-principal-transformer=<transformer_name>:add()
    2. 변환기의 사용자 이름을 소문자로 변경하려면 대문자 특성을 false로 설정합니다.

      대문자 특성이 false 로 설정된 elytron 하위 시스템에 <transformer_name> 표시 예:

      /subsystem=elytron/case-principal-transformer=<transformer_name>:add(upper-case="false")

  2. 선택 사항: elytron 하위 시스템을 사용하여 주요 변환기를 구성합니다. 다음 예제에서는 elytron 하위 시스템에서 제공한 기본 ApplicationDomain 구성에 주체 변환기를 구성했습니다. Elytron은 기본 ApplicationDomain 구성을 pre-realm-principal-transformer 에 적용합니다 :

    /subsystem=elytron/security-domain=ApplicationDomain:write-attribute(name=pre-realm-principal-transformer,value=<transformer_name>)
    참고

    영역 매퍼로 보안 영역을 식별한 후 ApplicationDomain 구성을 사용하도록 post-realm-principal-transformer 를 구성할 수 있습니다.

추가 리소스

3.2.4. 보안 ID 자격 증명 검색

HTTP 클라이언트에서 나가는 호출에 사용할 ID 자격 증명을 검색해야 하는 경우가 있을 수 있습니다. 다음 예제에서는 프로그래밍 방식으로 보안 자격 증명을 검색하는 방법을 보여줍니다.

import org.wildfly.security.auth.server.IdentityCredentials;
import org.wildfly.security.auth.server.SecurityDomain;
import org.wildfly.security.auth.server.SecurityIdentity;
import org.wildfly.security.credential.PasswordCredential;
import org.wildfly.security.password.interfaces.ClearPassword;

SecurityIdentity securityIdentity = null;
ClearPassword password = null;

// Obtain the SecurityDomain for the current deployment.
// The calling code requires the
//     org.wildfly.security.permission.ElytronPermission("getSecurityDomain") permission
//     if running with a security manager.
SecurityDomain securityDomain = SecurityDomain.getCurrent();
if (securityDomain != null) {
    // Obtain the current security identity from the security domain.
    // This always returns an identity, but it could be the representation
    //     of the anonymous identity if no authenticated identity is available.
    securityIdentity = securityDomain.getCurrentSecurityIdentity();
    // The private credentials can be accessed to obtain any credentials delegated to the identity.
    // The calling code requires the
    //     org.wildfly.security.permission.ElytronPermission("getPrivateCredentials")
    //     permission if running with a security manager.
    IdentityCredentials credentials = securityIdentity.getPrivateCredentials();
    if (credentials.contains(PasswordCredential.class)) {
        password = credentials.getCredential(PasswordCredential.class).getPassword(ClearPassword.class);
    }
}

3.2.5. 보안 ID 전파를 지원하는 메커니즘

다음 SASL 메커니즘은 보안 ID 전파를 지원합니다.

  • PLAIN
  • OAUTHBEARER
  • GSSAPI
  • GS2-KRB5

다음 HTTP 메커니즘은 보안 ID 전파를 지원합니다.

  • FORM 1
  • BASIC
  • BEARER_TOKEN
  • SPNEGO

1 웹 브라우저에서는 FORM 인증을 자동으로 처리하지 않습니다. 따라서 HA 클러스터에서 실행할 때 FORM 인증을 사용하는 웹 애플리케이션에서 ID 전파를 사용할 수 없습니다. BASICSPNEGO 와 같은 기타 메커니즘은 HA 클러스터 환경에서 ID 전파를 지원합니다.

3.3. Elytron을 사용한 ID 전환

3.3.1. 서버 대 서버 자카르타 엔터프라이즈 빈 호출의 ID 전환

기본적으로 애플리케이션 서버에 배포된 Jakarta Enterprise Beans에 대한 원격 호출을 만들 때 원격 서버에서 인증에 사용된 ID는 소스 서버에서 사용된 것과 같습니다. 경우에 따라 다른 ID의 보안 컨텍스트 내에서 원격 보안 자카르타 Enterprise Bean을 실행할 수 있습니다.

Elytron API를 사용하여 server-to-server Jakarta Enterprise Beans 호출에서 ID를 전환할 수 있습니다. 이렇게 하면 연결을 통해 수신된 요청이 API 호출에서 프로그래밍 방식으로 지정된 ID를 사용하여 새 요청으로 실행됩니다.

다음 코드 예제에서는 원격 Jakarta Enterprise Beans에서 인증에 사용되는 ID를 전환하는 방법을 보여줍니다. securityDomain.authenticate() 메서드에 전달된 remoteUsername 및 remote Password 인수는 대상 서버에서 인증하는 데 사용할 ID 자격 증명입니다.

예제: 서버 대 서버 자카르타 엔터프라이즈 빈 호출의 ID 전환

SecurityDomain securityDomain = SecurityDomain.getCurrent();
Callable<T> forwardIdentityCallable = () -> {
    return AuthenticationContext.empty()
            .with(MatchRule.ALL,
                    AuthenticationConfiguration.empty()
                    .setSaslMechanismSelector(SaslMechanismSelector.ALL)
                    .useForwardedIdentity(securityDomain))
            .runCallable(callable);
};

securityDomain.authenticate(remoteUsername, new PasswordGuessEvidence(remotePassword.toCharArray())).runAs(forwardIdentityCallable);

3.4. 레거시 코어 관리 인증을 통한 사용자 인증

3.4.1. 기본 사용자 설정

JBoss EAP의 모든 관리 인터페이스는 기본적으로 보호되며 사용자는 로컬 인터페이스와 원격 인터페이스의 두 가지 방법으로 액세스할 수 있습니다. 이러한 인증 메커니즘의 기본 사항은 JBoss EAP 보안 아키텍처 가이드의 박스 섹션에서 기본 보안 및 JBoss EAP 아웃 에서 다룹니다. 기본적으로 이러한 인터페이스에 대한 액세스는 Management Realm 보안 영역에서 구성됩니다. 처음에는 로컬 인터페이스가 활성화되며 JBoss EAP 인스턴스를 실행하는 호스트 시스템에 액세스해야 합니다. 원격 액세스도 활성화되며 파일 기반 ID 저장소를 사용하도록 구성됩니다. 기본적으로 mgmt-users.properties 파일을 사용하여 사용자 이름 및 암호와 mgmt-groups.properties 를 사용하여 사용자 그룹 정보를 저장합니다.

EAP_HOME/bin/ 디렉터리에 포함된 adduser 스크립트를 사용하여 사용자 정보가 해당 파일에 추가됩니다.

add user 스크립트를 통해 사용자를 추가하려면 다음을 수행합니다.

  1. add-user.sh 또는 add-user.bat 명령을 실행합니다.
  2. 관리 사용자 또는 애플리케이션 사용자를 추가할지 여부를 선택합니다.
  3. 사용자가 추가할 영역을 선택합니다. 기본적으로 사용 가능한 영역은 ManagementRealmApplicationRealm 입니다. 사용자 지정 영역을 추가한 경우 대신 이름을 수동으로 입력할 수 있습니다.
  4. 메시지가 표시되면 원하는 사용자 이름, 암호 및 선택적 역할을 입력합니다. 변경 사항은 보안 영역의 각 속성 파일에 작성됩니다.

3.4.2. LDAP를 통한 인증 추가

JBoss EAP는 관리 인터페이스 보안을 위해 LDAP 인증 사용을 지원합니다. LDAP의 기초와 JBoss EAP의 작동 방식에 대해서는 LDAP 에서 다루는 내용,관리 인터페이스와 함께 LDAP 사용, Red Hat JBoss Enterprise Application Platform 7 보안 아키텍처 가이드의 ManagementRealm 섹션에 LDAP 사용 등이 포함됩니다. LDAP 인증을 사용하여 관리 인터페이스를 보호하는 방법에 대한 자세한 내용은 JBoss EAP How to Configure Identity Management Guide 에서 LDAP로 관리 인터페이스 보안 섹션을 참조하십시오.

3.4.3. 관리 인터페이스 보안에 JAAS 사용

JAAS는 JBoss EAP에서 보안을 관리하는 데 사용하는 선언적 보안 API입니다. JAAS 및 선언적 보안에 대한 자세한 내용 및 배경 정보는 Red Hat JBoss Enterprise Application Platform 보안 아키텍처 가이드의 선언적 보안 및 JAAS 섹션을 참조하십시오.

참고

JBoss EAP 인스턴스가 ADMIN_ONLY 모드에서 실행되도록 구성된 경우 JAAS를 사용하여 관리 인터페이스를 보호하는 것은 지원되지 않습니다. ADMIN_ONLY 모드에 대한 자세한 내용은 JBoss EAP 구성 가이드의 ADMIN_ONLY 모드 실행 섹션을 참조하십시오.

JAAS를 사용하여 관리 인터페이스에 인증하려면 다음 단계를 수행해야 합니다.

  1. 보안 도메인을 생성합니다.

    이 예제에서는 UserRoles 로그인 모듈로 보안 도메인을 생성하지만 다른 로그인 모듈도 사용할 수 있습니다.

    /subsystem=security/security-domain=UsersLMDomain:add(cache-type=default)
    
    /subsystem=security/security-domain=UsersLMDomain/authentication=classic:add
    
    /subsystem=security/security-domain=UsersLMDomain/authentication=classic/login-module=UsersRoles:add(code=UsersRoles, flag=required,module-options=[("usersProperties"=>"users.properties"),("rolesProperties"=>"roles.properties")])
  2. JAAS 인증을 사용하여 보안 영역을 만듭니다.

    /core-service=management/security-realm=SecurityDomainAuthnRealm:add
    
    /core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:add(name=UsersLMDomain)
  3. 새 보안 영역을 사용하도록 http-interface 관리 인터페이스를 업데이트합니다.

    /core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=SecurityDomainAuthnRealm)
  4. 선택 사항: 그룹 멤버십 할당.

    특성 assign-groups 는 보안 영역의 그룹 할당에 보안 도메인에서 로드된 사용자 멤버십 정보가 사용되는지 여부를 결정합니다. true 로 설정하면 이 그룹 할당이 역할 기반 액세스 제어(RBAC)에 사용됩니다.

    /core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:write-attribute(name=assign-groups,value=true)

3.5. 역할 기반 액세스 제어

역할 기반 액세스 제어의 기본 사항은 역할 기반 액세스 제어 및 JBoss EAP 보안 아키텍처 가이드 의 관리 인터페이스에 RBAC 추가 섹션에서 설명합니다.

3.5.1. 역할 기반 액세스 제어 활성화

기본적으로 RBAC(역할 기반 액세스 제어) 시스템은 비활성화되어 있습니다. provider 특성을 simple 에서 rbac. provider 로 변경하면 활성화됩니다.provider관리 요소의 access-control 요소의 속성입니다. 이 작업은 관리 CLI를 사용하거나 서버가 오프라인인 경우 서버 구성 XML 파일을 편집하여 수행할 수 있습니다. 실행 중인 서버에서 RBAC를 비활성화하거나 활성화하면 적용되기 전에 서버 구성을 다시 로드해야 합니다.

주의

프로바이더를 rbac 으로 변경하기 전에 Administrator 또는 SuperUser 역할에서 하나 이상 RBAC 역할 중 하나로 매핑되는 사용자가 구성에 있는지 확인합니다. 그렇지 않으면 설치를 종료하고 XML 구성을 편집하는 것을 제외하고는 설치할 수 없습니다. JBoss EAP와 함께 제공되는 표준 XML 구성 중 하나를 시작한 경우 $local 사용자는 SuperUser 역할에 매핑되고 로컬 인증 체계가 활성화됩니다. 이렇게 하면 JBoss EAP 프로세스와 동일한 시스템에서 CLI를 실행하는 사용자가 전체 관리 권한을 가질 수 있습니다. 원격 CLI 사용자와 웹 기반 관리 콘솔 사용자는 권한이 없습니다.

공급자를 전환하기 전에 $local 외에 하나 이상의 사용자를 매핑하는 것이 좋습니다. 공급업체가 simple 로 설정된 경우에도 the rbac 프로바이더와 연결된 모든 구성을 수행할 수 있습니다.

활성화된 후에는 Administrator 또는 SuperUser 역할 사용자만 비활성화할 수 있습니다. 기본적으로 관리 CLI는 서버와 동일한 시스템에서 실행되는 경우 SuperUser 역할로 실행됩니다.

RBAC를 활성화하는 CLI

관리 CLI를 사용하여 RBAC를 활성화하려면 액세스 권한 부여 리소스의 쓰기 작업을 사용하여 프로바이더 특성을 로 설정합니다.

/core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

reload

관리형 도메인에서 액세스 제어 구성은 도메인 전체 구성의 일부이므로 리소스 주소는 위와 동일하지만 관리 CLI는 마스터 도메인 컨트롤러에 연결됩니다.

/core-service=management/access=authorization:write-attribute(name=provider,value=rbac)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    },
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {
            "outcome" => "success",
            "response-headers" => {
                "operation-requires-reload" => true,
                "process-state" => "reload-required"
            }
        }},
        "server-two" => {"response" => {
            "outcome" => "success",
            "response-headers" => {
                "operation-requires-reload" => true,
                "process-state" => "reload-required"
            }
        }}
    }}}}
}

reload --host=master
참고

독립 실행형 서버와 마찬가지로 변경 사항을 적용하려면 다시 로드하거나 다시 시작해야 합니다. 관리형 도메인에서는 마스터 도메인 컨트롤러부터 시작하여 도메인의 모든 호스트와 서버를 다시 로드하거나 다시 시작해야 합니다.

RBAC 비활성화를 위한 관리 CLI 명령

관리 CLI를 사용하여 RBAC를 비활성화하려면 액세스 권한 부여 리소스의 쓰기 작업을 사용하여 프로바이더 특성을 simple 로 설정합니다.

/core-service=management/access=authorization:write-attribute(name=provider, value=simple)
RBAC를 활성화 또는 비활성화하는 XML 구성

서버가 오프라인인 경우 XML 구성을 편집하여 RBAC를 활성화하거나 비활성화할 수 있습니다. 이렇게 하려면 관리 요소의 access-control 요소의 provider 속성을 편집합니다. 활성화되도록 값을 설정하고 simple to disable를 설정합니다.

예제: RBAC를 활성화 또는 비활성화하는 XML 구성

<management>
  <access-control provider="rbac">
    <role-mapping>
      <role name="SuperUser">
        <include>
          <user name="$local"/>
        </include>
      </role>
    </role-mapping>
  </access-control>
</management>

3.5.2. 권한 조합 정책 변경

권한 조합 정책은 사용자에게 둘 이상의 역할이 할당되는 경우 권한을 결정하는 방법을 결정합니다. 허용 또는 거부 로 설정할 수 있습니다. 기본값은 허용 입니다.

허용 으로 설정되면 작업을 허용하는 사용자에게 역할이 할당되면 작업이 허용됩니다.

rejecting( 거부 )으로 설정하면 여러 역할이 사용자에게 할당되면 작업이 허용되지 않습니다. 즉, 정책이 각 사용자를 거부하도록 설정된 경우 하나의 역할만 할당해야 합니다. 여러 역할이 있는 사용자는 정책이 거부로 설정된 경우 관리 콘솔 또는 관리 CLI를 사용할 수 없습니다.

권한 조합 정책은 permission-combination-policy 특성을 허용 또는 거부 로 설정하여 구성됩니다. 이 작업은 관리 CLI를 사용하거나 서버가 오프라인인 경우 서버 구성 XML 파일을 편집하여 수행할 수 있습니다. permission-combination-policy 특성은 access-control 요소의 일부이며 access-control 요소는 관리 요소에서 찾을 수 있습니다.

권한 조합 정책 설정

액세스 권한 부여 리소스의 write-attribute 작업을 사용하여 permission-combination-policy 특성을 필수 정책 이름으로 설정합니다.

/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=POLICYNAME)

유효한 정책 이름이 거부 되고 허용됩니다.

예제: 권한 조합 취소를 위한 관리 CLI 명령

/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=rejecting)

서버가 오프라인인 경우 XML 구성을 편집하여 권한 조합 정책 값을 변경할 수 있습니다. 이렇게 하려면 access -control 요소의 permission-combination- policy 특성을 편집합니다.

예제: 권한 조합 취소를 위한 XML 구성

<access-control provider="rbac" permission-combination-policy="rejecting">
  <role-mapping>
    <role name="SuperUser">
      <include>
        <user name="$local"/>
      </include>
    </role>
  </role-mapping>
</access-control>

3.5.3. 역할 관리

RBAC(역할 기반 액세스 제어)가 활성화되면 관리 사용자가 수행할 수 있는 작업은 사용자가 할당되는 역할에 따라 결정됩니다. JBoss EAP 7은 사용자 및 그룹 멤버십 둘 다에 따라 포함 시스템을 사용하며 사용자가 속한 역할을 결정합니다.

사용자가 다음과 같은 경우 사용자에게 역할이 할당되는 것으로 간주됩니다.

  • 역할에 포함할 사용자로 나열되거나,
  • 역할에 포함할 그룹의 구성원입니다.

사용자가 없는 경우 사용자에게도 역할이 할당되는 것으로 간주됩니다.

  • 역할에서 제외할 사용자로 나열되거나
  • 역할에서 제외할 그룹 구성원입니다.

제외는 포함보다 우선합니다.

역할은 관리 콘솔과 관리 CLI를 사용하여 사용자 및 그룹의 설정을 포함하고 제외할 수 있습니다.

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

3.5.3.1. 관리 CLI를 사용하여 사용자 역할 할당 구성

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

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

역할 할당 구성 보기

구성된 역할의 전체 목록을 가져오려면 :read-children-names 작업을 사용합니다.

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

지정된 role -mapping의 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"
            }
        }
    }
}
새 역할 추가

다음 절차에서는 역할에 대한 role-mapping 항목을 추가하는 방법을 설명합니다. 역할을 구성하기 전에 이 작업을 수행해야 합니다.

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

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

ROLENAME 은 새 매핑이 있는 역할의 이름입니다(예: Auditor ).

예제: 새 역할 구성을 위한 관리 CLI 명령

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

역할에 포함된 사용자 추가

다음 절차에서는 사용자를 포함된 역할 목록에 추가하는 방법을 설명합니다.

역할 구성이 수행되지 않은 경우 먼저 role-mapping 항목을 수행해야 합니다.

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

/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)
  • ROLENAME 은 구성되는 역할의 이름입니다(예: Auditor ).
  • ALIAS 는 이 매핑의 고유한 이름입니다. Red Hat은 user-USERNAME(예: user-max )과 같은 별칭에 대한 명명 규칙을 사용할 것을 권장합니다.
  • USERNAME 은 max와 같이 포함 목록에 추가되는 사용자의 이름입니다 .

예제: 역할에 포함된 사용자의 관리 CLI 명령

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

역할에서 제외된 사용자로 사용자 추가

다음 절차에서는 제외된 역할 목록에 사용자를 추가하는 방법을 설명합니다.

역할 구성이 수행되지 않은 경우 먼저 role-mapping 항목을 수행해야 합니다.

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

/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)
  • ROLENAME 은 구성되는 역할의 이름입니다(예: Auditor ).
  • USERNAME 은 제외 목록에 추가되는 사용자의 이름입니다(예: max ).
  • ALIAS 는 이 매핑의 고유한 이름입니다. Red Hat은 user-USERNAME(예: user-max )과 같은 별칭에 대한 명명 규칙을 사용할 것을 권장합니다.

예제: 역할에서 제외된 관리 CLI 명령 사용자

/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
  • ROLENAME 은 구성되는 역할의 이름입니다(예: Auditor ).
  • ALIAS 는 이 매핑의 고유한 이름입니다. Red Hat은 user-USERNAME(예: user-max )과 같은 별칭에 대한 명명 규칙을 사용할 것을 권장합니다.

예제: 사용자 역할 제거를 위한 관리 CLI 명령 구성 포함

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

참고

includes 목록에서 사용자를 제거해도 시스템에서 사용자가 제거되지 않으며, 역할이 사용자에게 할당되지 않습니다. 이 역할은 그룹 멤버십에 따라 계속 할당될 수 있습니다.

사용자 역할 제거 설정 제외

다음 절차에서는 역할 매핑에서 사용자 제외 항목을 제거하는 방법을 설명합니다.

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

/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
  • ROLENAME 은 구성되는 역할의 이름입니다(예: Auditor ).
  • ALIAS 는 이 매핑의 고유한 이름입니다. Red Hat은 user-USERNAME(예: user-max )과 같은 별칭에 대한 명명 규칙을 사용할 것을 권장합니다.
/core-service=management/access=authorization/role-mapping=Auditor/exclude=user-max:remove
참고

excludes 목록에서 사용자를 제거해도 시스템에서 사용자가 제거되지 않으며, 역할이 사용자에게 할당된다는 보장도 없습니다. 그룹 멤버십에 따라 역할을 제외할 수 있습니다.

3.5.4. Elytron Subsystem을 사용하여 사용자 역할 할당 구성

역할 관리 섹션에서 다룬 대로 사용자에 대한 역할 매핑을 직접 추가하는 것 외에도 elytron 하위 시스템에서 제공하는 ID에서 직접 가져온 RBAC 역할을 구성할 수도 있습니다.

elytron 하위 시스템에서 제공하는 역할을 사용하도록 RBAC 시스템을 구성하려면 다음을 수행합니다.

/core-service=management/access=authorization:write-attribute(name=use-identity-roles,value=true)
중요

이 기능을 사용하려면 RBAC를 활성화해야 하며 주체에는 RBAC 역할이 있어야 합니다.

3.5.5. 역할 및 사용자 그룹

사용자 그룹은 하나 이상의 사용자에게 할당할 수 있는 임의의 레이블입니다. 관리 인터페이스를 사용하여 인증할 때 관리 인터페이스의 보안 방식에 따라 사용자에게 elytron 하위 시스템 또는 코어 관리 인증이 할당됩니다. RBAC 시스템은 멤버가 속한 사용자 그룹에 따라 사용자에게 역할을 자동으로 할당하도록 구성할 수 있습니다. 그룹 멤버십에 따라 역할에서 사용자를 제외할 수도 있습니다.

3.5.6. 관리 CLI를 사용하여 그룹 역할 할당 구성

역할에서 포함하거나 제외할 그룹은 관리 콘솔 및 관리 CLI에서 구성할 수 있습니다. 이 주제는 관리 CLI 사용만 보여줍니다.

사용자 및 그룹을 역할에 매핑하는 구성은 관리 API의 구성: /core-service=management/access=authorization as role-mapping 요소.

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

그룹 역할 할당 구성 보기

read-children-names 작업을 사용하여 구성된 역할의 전체 목록을 가져옵니다.

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

지정된 role -mapping의 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"
            }
        }
    }
}
새 역할 추가

다음 절차에서는 역할에 대한 role-mapping 항목을 추가하는 방법을 설명합니다. 역할을 구성하기 전에 이 작업을 수행해야 합니다.

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

/core-service=management/access=authorization/role-mapping=ROLENAME:add
역할에 포함된 그룹 추가

다음 절차에서는 포함된 역할 목록에 그룹을 추가하는 방법을 설명합니다.

역할 구성이 수행되지 않은 경우 먼저 role-mapping 항목을 수행해야 합니다.

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

/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=GROUPNAME, type=GROUP)
  • ROLENAME 은 구성되는 역할의 이름입니다(예: Auditor ).
  • GROUPNAME조사 자와 같이 include 목록에 추가되는 그룹의 이름입니다.
  • ALIAS 는 이 매핑의 고유한 이름입니다. Red Hat은 group-GROUPNAME(예: group-investigator)과 같은 별칭에 대한 명명 규칙을 사용할 것을 권장합니다.

예제: 역할에 포함된 그룹 추가를 위한 관리 CLI 명령

/core-service=management/access=authorization/role-mapping=Auditor/include=group-investigators:add(name=investigators, type=GROUP)

역할에서 제외로 그룹 추가

다음 절차에서는 제외된 역할 목록에 그룹을 추가하는 방법을 설명합니다.

역할 구성이 수행되지 않은 경우 역할 매핑 항목을 먼저 생성해야 합니다.

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

/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=GROUPNAME, type=GROUP)
  • ROLENAME 은 구성되는 역할의 이름입니다(예: Auditor ).
  • GROUPNAME 은 supervisors와 같이 include 목록에 추가할 그룹의 이름입니다.
  • ALIAS 는 이 매핑의 고유한 이름입니다. Red Hat은 group-GROUPNAME(예: group-supervisors )과 같은 별칭에 대한 명명 규칙을 사용할 것을 권장합니다.

예제: 역할에서 제외된 그룹 추가를 위한 관리 CLI 명령

/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-supervisors:add(name=supervisors, type=GROUP)

그룹 역할 포함 구성 제거

다음 절차에서는 역할 매핑에서 그룹 포함 항목을 제거하는 방법을 설명합니다.

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

/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
  • ROLENAME 은 구성되는 역할의 이름입니다(예: Auditor ).
  • ALIAS 는 이 매핑의 고유한 이름입니다. Red Hat은 group-GROUPNAME(예: group-investigator)과 같은 별칭에 대한 명명 규칙을 사용할 것을 권장합니다.

예제: 그룹 역할 제거를 위한 관리 CLI 명령 구성 포함

/core-service=management/access=authorization/role-mapping=Auditor/include=group-investigators:remove

참고

includes 목록에서 그룹을 제거해도 시스템에서 그룹이 제거되지 않으며, 역할이 이 그룹의 사용자에게 할당되지 않습니다. 이 역할은 계속 그룹의 사용자에게 개별적으로 할당될 수 있습니다.

사용자 그룹 제외 항목 제거

다음 절차에서는 역할 매핑에서 그룹 제외 항목을 제거하는 방법을 설명합니다.

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

/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
  • ROLENAME 은 구성되는 역할의 이름입니다(예: Auditor ).
  • ALIAS 는 이 매핑의 고유한 이름입니다. Red Hat은 group-GROUPNAME(예: group-supervisors )과 같은 별칭에 대한 명명 규칙을 사용할 것을 권장합니다.
/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-supervisors:remove
참고

제외 목록에서 그룹을 제거해도 시스템에서 그룹이 제거되지 않습니다. 또한 역할이 그룹의 멤버에게 할당된다는 보장은 없습니다. 그룹 멤버십에 따라 역할을 제외할 수 있습니다.

3.5.7. LDAP에서 RBAC 사용

LDAP와 함께 RBAC를 사용하는 방법과 LDAP에서 RBAC를 사용하도록 JBoss EAP를 구성하는 방법에 대한 기본 사항은 JBoss EAP의 LDAP 및 RBAC 섹션에서 ID 관리 가이드 구성 방법에서 다룹니다.

3.5.8. 범위가 지정된 역할

범위가 지정된 역할은 표준 역할 중 하나의 권한을 부여하지만 JBoss EAP 관리형 도메인에서 하나 이상의 지정된 서버 그룹 또는 호스트에 대해서만 권한을 부여하는 사용자 정의 역할입니다. 범위가 지정된 역할을 통해 관리 사용자에게 필요한 서버 그룹 또는 호스트로만 제한되는 권한이 부여될 수 있습니다.

중요

범위가 지정된 역할은 Administrator 또는 SuperUser 역할이 할당된 사용자가 생성할 수 있습니다.

다음 5가지 특성으로 정의됩니다.

  • 고유한 이름입니다.
  • 기반이 되는 표준 역할.
  • 서버 그룹 또는 호스트에 적용되는 경우.
  • 제한된 서버 그룹 또는 호스트 목록입니다.
  • 모든 사용자가 자동으로 포함되는 경우. 기본값은 false 입니다.

범위가 지정된 역할은 표준 역할과 동일한 방식으로 사용자와 그룹에 할당할 수 있습니다.

범위가 지정된 역할을 만들면 새 권한을 정의할 수 없습니다. 범위가 지정된 역할은 제한된 범위에서 기존 역할의 권한을 적용하는 데만 사용할 수 있습니다. 예를 들어 단일 서버 그룹으로 제한되는 Deployer 역할을 기반으로 범위가 지정된 역할을 생성할 수 있습니다.

역할은 다음을 제한할 수 있는 두 가지 범위만 있습니다.

호스트 범위 역할
호스트 범위에 해당하는 역할은 해당 역할의 권한을 하나 이상의 호스트로 제한합니다. 즉, 관련 /host=*/ 리소스 트리에 액세스가 제공되지만 다른 호스트와 관련된 리소스는 숨겨집니다.
server-group-scoped 역할
server-group-scoped 역할은 해당 역할의 권한을 하나 이상의 서버 그룹으로 제한합니다. 또한 역할 권한은 지정된 server -groups와 연결된 프로필, 소켓 바인딩 그룹, 서버 구성 및 서버 리소스에도 적용됩니다. server-group과 논리적으로 관련이 없는 하위 리소스는 사용자에게 표시되지 않습니다.
중요

일부 리소스는 사용성을 향상시키기 위해 관리 모델을 간단하게 볼 수 있도록 server-grouphost scoped 역할에 주소가 지정되지 않습니다. 중요한 데이터를 보호하기 위해 주소 지정이 불가능한 리소스와는 다릅니다.

호스트 범위가 지정된 역할의 경우, 역할에 지정된 서버 그룹과 관련이 없는 경우 관리 모델의 /host=* 부분에 있는 리소스가 표시되지 않습니다.

server-group 범위가 지정된 역할의 경우 프로필,socket-binding-group,deployment , deployment-overlay,server-group, server-config 및 server 부분의 리소스가 역할에 지정된 서버 그룹과 관련이 없는 경우 표시되지 않습니다.

3.5.8.1. 관리 CLI에서 범위 역할 구성

중요

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

새 범위 역할 추가

새 범위가 지정된 역할을 추가하려면 다음 작업을 수행해야 합니다.

/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-ROLESERVER-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 을 적절한 정보로 바꿉니다.

중요

사용자 또는 그룹이 할당되면 범위가 지정된 역할을 삭제할 수 없습니다. 먼저 역할 할당을 제거한 다음 삭제합니다.

사용자 추가 및 제거

범위가 지정된 역할 간에 사용자를 추가 및 제거하는 작업은 표준 역할 추가 및 제거와 동일한 프로세스를 따릅니다.

3.5.8.2. 관리 콘솔에서 범위 역할 구성

중요

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

관리 콘솔에서 범위가 지정된 역할 구성은 다음 단계를 수행하여 찾을 수 있습니다.

  1. 관리 콘솔에 로그인합니다.
  2. Access Control(액세스 제어 ) 탭을 클릭합니다.
  3. Roles (역할)를 클릭하여 범위가 지정된 역할을 포함한 모든 역할을 확인합니다.

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

새 범위 역할 추가
  1. 관리 콘솔에 로그인합니다.
  2. Access Control(액세스 제어 ) 탭을 클릭합니다.
  3. Roles(역할 )를 선택하고 Add (+)(추가(+)) 버튼을 클릭합니다.
  4. 호스트 범위 역할 또는 서버 그룹 범위 역할을 선택합니다.
  5. 다음 세부 사항을 지정합니다.

    • 이름: 새 범위가 지정된 역할의 고유 이름입니다.
    • 기본 역할: 이 역할이 권한을 기준으로 할 역할입니다.
    • 호스트 또는 서버 그룹: 추가되는 역할의 유형에 따라 역할이 제한되는 호스트 또는 서버 그룹 목록입니다. 여러 항목을 선택할 수 있습니다.
    • 모두 포함: 이 역할에 모든 사용자를 자동으로 포함해야 하는지 여부. 기본값은 OFF 입니다.
  6. Add(추가) 를 클릭하여 새 역할을 만듭니다.
범위 역할 편집
  1. 관리 콘솔에 로그인합니다.
  2. Access Control(액세스 제어 ) 탭을 클릭합니다.
  3. 왼쪽에서 Roles(역할 ) 메뉴를 클릭합니다.
  4. 편집할 범위 역할을 클릭하고 Edit(편집 )를 클릭합니다.
  5. 원하는 세부 정보를 업데이트하여 변경한 후 Save (저장) 버튼을 클릭합니다.
지정된 역할 멤버 보기
  1. 관리 콘솔에 로그인합니다.
  2. Access Control(액세스 제어 ) 탭을 클릭합니다.
  3. 왼쪽에서 Roles(역할 ) 메뉴를 클릭합니다.
  4. 원하는 범위가 지정된 역할을 클릭하여 포함 및 제외된 멤버를 확인합니다.
범위 역할 삭제
  1. 관리 콘솔에 로그인합니다.
  2. Access Control(액세스 제어 ) 탭을 클릭합니다.
  3. 왼쪽에서 Roles(역할 ) 메뉴를 클릭합니다.
  4. 원하는 범위가 지정된 역할을 클릭하고 드롭다운에서 제거를 클릭합니다.
  5. Yes (예)를 클릭하여 역할 및 모든 할당을 제거합니다.
사용자 추가 및 제거

범위가 지정된 역할 간에 사용자를 추가 및 제거하는 작업은 표준 역할 추가 및 제거와 동일한 프로세스를 따릅니다. 사용자의 범위가 지정된 역할을 업데이트하려면 다음을 수행합니다.

  1. 관리 콘솔에 로그인합니다.
  2. Access Control(액세스 제어 ) 탭을 클릭합니다.
  3. 왼쪽에서 Roles(역할 ) 메뉴를 클릭하고 원하는 범위가 지정된 역할을 클릭합니다.
  4. 멤버를 제외하려면 Plus (+)단추를선택하여 멤버 또는 Minus(-) 버튼을선택합니다.

3.5.9. 제한 조건 구성

3.5.9.1. 중요 제한 조건 구성

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

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

관리 모델 내에서 각 민감도 제한 사항은 분류로 식별됩니다. 그런 다음 분류는 유형으로 그룹화됩니다. 각 분류에는 분류 구성이 적용되는 경로 패턴 목록인 apply-to 요소가 있습니다.

민감도 제한 조건을 구성하려면 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
        }
    }
}

역할 및 수행할 수 있는 각 작업은 특성의 구성에 따라 달라집니다. 다음 표에 요약되어 있습니다.

표 3.2. 민감도 제한 설정 아웃

현재의requires-readrequires-writerequires-addressable

true

읽기는 민감합니다. Auditor,Administrator,SuperUser 만.

쓰기는 민감합니다. 관리자와 SuperUser 만 쓸 수 있습니다.

주소 지정은 민감합니다. Auditor,Administrator,SuperUser 만 주소를 지정할 수 있습니다.

false

읽기는 민감하지 않습니다. 모든 관리 사용자는 다음과 같이 읽을 수 있습니다.

쓰기는 민감하지 않습니다. 유지 관리 프로그램,AdministratorSuperUser 만 쓸 수 있습니다. 배포자 는 리소스도 애플리케이션 리소스로 작성할 수 있습니다.

주소 지정은 민감하지 않습니다. 모든 관리 사용자가 처리할 수 있습니다.

3.5.9.2. 중요 제한 조건 나열

다음 관리 CLI 명령을 사용하여 JBoss EAP 관리 모델에서 직접 사용 가능한 민감도 제한 조건 목록을 확인할 수 있습니다.

/core-service=management/access=authorization/constraint=sensitivity-classification:read-resource(include-runtime=true,recursive=true)

3.5.9.3. 애플리케이션 리소스 제한 조건 구성

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

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

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

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

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

예제: logger-profile 애플리케이션 리소스 분류 활성화

/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}
    }
}
중요

애플리케이션 리소스 제한 조건은 해당 구성과 일치하는 모든 리소스에 적용됩니다. 예를 들어 한 데이터 소스 리소스에 대한 배포자 사용자 액세스 권한을 부여할 수는 없지만 다른 데이터 소스 리소스에 대한 액세스 권한은 부여할 수 없습니다. 이 수준의 분리가 필요한 경우 다른 서버 그룹에 리소스를 구성하고 각 그룹에 대해 서로 다른 범위가 지정된 배포자 역할을 생성하는 것이 좋습니다.

3.5.9.4. 애플리케이션 리소스 제한 조건 나열

다음 관리 CLI 명령을 사용하여 JBoss EAP 관리 모델에서 직접 사용 가능한 애플리케이션 리소스 제약 조건 목록을 확인할 수 있습니다.

/core-service=management/access=authorization/constraint=application-classification:read-resource(include-runtime=true,recursive=true)

3.5.9.5. Vault Expression Constraint 구성

기본적으로 자격 증명 모음 표현식을 읽고 쓰는 것은 중요한 작업입니다. vault 표현식 제약 조건을 구성하면 또는 둘 다 민감하지 않게 설정할 수 있습니다. 이 제약 조건을 변경하면 많은 역할이 자격 증명 모음 표현식을 읽고 쓸 수 있습니다.

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

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

예제: Vault 표현식에 대한 작성을 중요하지 않은 작업

/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
    }
}

각 자격 증명 모음 식과 각 자격 증명 모음 식은 특성 구성에 따라 다릅니다. 다음 표에 요약되어 있습니다.

표 3.3. Vault Expression Constraint Configuration Outcomes

현재의requires-readrequires-write

true

읽기 작업은 민감합니다. 감사자,관리자SuperUser 만.

쓰기 작업은 민감합니다. 관리자와 SuperUser 만 쓸 수 있습니다.

false

읽기 작업은 민감하지 않습니다. 모든 관리 사용자는.

쓰기 작업은 민감하지 않습니다. monitor,AdministratorSuperUser 에서 쓰기를 수행할 수 있습니다. 배포자 는 자격 증명 모음 표현식이 애플리케이션 리소스에 있는 경우에도 작성할 수 있습니다.

4장. 자격 증명을 위한 보안 스토리지

JBoss EAP를 사용하면 구성 파일 외부에서 중요한 문자열을 암호화할 수 있습니다. 이러한 문자열은 키 저장소에 저장한 다음 애플리케이션 및 확인 시스템에 대해 암호 해독할 수 있습니다. 중요한 문자열은 다음 중 하나에 저장할 수 있습니다.

  • 인증 정보 저장소 - JBoss EAP 7.1에 소개된 인증 정보 저장소에서는 스토리지 파일에서 암호화하여 인증 정보 저장소에서 중요한 텍스트 문자열을 안전하게 보호할 수 있습니다. 각 JBoss EAP 서버에는 여러 자격 증명 저장소가 포함될 수 있습니다.
  • Password Vault - 기존 구성에서 주로 사용되는 암호 자격 증명 모음은 Java 키 저장소를 사용하여 구성 파일 외부에 중요한 문자열을 저장합니다. 각 JBoss EAP 서버는 단일 암호 자격 증명 모음만 포함할 수 있습니다.

기본적으로 EAP_HOME/standalone/configuration/ 및 EAP_HOME/domain/configuration/ 의 모든 구성 파일을 읽을 수 있습니다. 일반 텍스트 암호를 구성 파일에 저장하지 않고 자격 증명 저장소 또는 암호 자격 증명 모음 에 이러한 자격 증명 을 배치하는 것이 좋습니다.

구성 파일에 일반 텍스트 암호를 배치하기로 결정한 경우 제한된 사용자만 해당 파일에 액세스할 수 있어야 합니다. 최소한 JBoss EAP 7이 실행 중인 사용자 계정에는 읽기-쓰기 액세스 권한이 필요합니다.

4.1. 인증 정보 저장 Elytron에 저장

4.1.1. Elytron에서 제공하는 인증 정보 저장소

Elytron는 자격 증명을 저장하는 데 사용할 수 있는 두 가지 기본 인증 정보 저장소 유형을 제공합니다. KeyStoreCredentialStore 및 PropertiesCredentialStore JBoss EAP 관리 CLI를 사용하여 인증 정보 저장소를 관리하거나 WildFly Elytron 툴을 사용하여 오프라인에서 관리할 수 있습니다. 두 가지 기본 저장소 유형 외에도 고유한 사용자 지정 자격 증명 저장소를 생성, 사용 및 관리할 수 있습니다.

4.1.1.1. KeyStoreCredentialStore/credential-store

모든 Elytron 자격 증명 유형을 KeyStoreCredentialStore에 저장할 수 있습니다. elytron 하위 시스템에서 KeyStoreCredentialStore의 리소스 이름은 credential-store 입니다. KeyStoreCredentialStore는 JDK(Java Development Kit)의 KeyStore 구현에서 제공하는 메커니즘을 사용하여 인증 정보를 보호합니다.

다음과 같이 관리 CLI에서 KeyStoreCredentialStore에 액세스합니다.

/subsystem=elytron/credential-store

4.1.1.2. PropertiesCredentialStore/secret-key-credential-store

제대로 시작하려면 JBoss EAP에서 특정 보안 리소스를 잠금 해제하려면 초기 키가 필요합니다. 필요한 서버 리소스의 잠금을 해제하려면 secret-key-credential-store 를 사용하여 이 마스터 시크릿 키를 제공합니다. PropertiesCredentialStore를 사용하여 SDS(Advanced Encryption Standard) 시크릿 키 저장을 지원하는 SecretKeyCredential을 저장할 수도 있습니다. 파일 시스템 권한을 사용하여 자격 증명 저장소에 대한 액세스를 제한합니다. 이 자격 증명 저장소에 대한 액세스를 제한하려면 애플리케이션 서버에만 액세스 권한을 부여하는 것이 좋습니다. PropertiesCredentialStore의 elytron 하위 시스템에 있는 리소스 이름은 secret-key-credential-store 이며 다음과 같이 관리 CLI에서 액세스할 수 있습니다.

/subsystem=elytron/secret-key-credential-store

초기 키 생성 및 제공에 대한 자세한 내용은 JBoss EAP에 초기 키 제공에서 보안 리소스의 잠금을 해제하는 것을 참조하십시오. 또는 외부 소스에서 마스터 키 또는 암호를 가져올 수 있습니다. 외부 소스에서 암호를 가져오는 방법에 대한 자세한 내용은 외부 소스에서 인증 정보 저장소의 암호 가져오기를 참조하십시오.

4.1.2. Elytron의 인증 정보 유형

Elytron는 다양한 보안 요구에 맞게 다음과 같은 세 가지 자격 증명 유형을 제공하며 이러한 자격 증명을 Elytron의 자격 증명 저장소 중 하나에 저장할 수 있습니다.

PasswordCredential

이 자격 증명 유형을 사용하면 일반 텍스트 또는 암호화되지 않은 암호를 안전하게 저장할 수 있습니다. 암호가 필요한 JBoss EAP 리소스의 경우 일반 텍스트 암호 대신 PasswordCredential에 대한 참조를 사용하여 암호의 기밀성을 유지합니다.

데이터베이스에 연결하는 예

data-source add ... --user-name=db_user --password=StrongPassword

이 예제 데이터베이스 연결 명령에서는 암호를 볼 수 있습니다. StrongPassword. 즉, 다른 사용자가 서버 구성 파일에서도 볼 수 있습니다.

PasswordCredential을 사용하여 데이터베이스에 연결하는 예

data-source add ... --user-name=db_user --credential-reference={store=exampleKeyStoreCredentialStore, alias=passwordCredentialAlias}

암호 대신 인증 정보 참조를 사용하여 데이터베이스에 연결할 때 다른 사용자는 암호가 아닌 구성 파일의 자격 증명 참조만 볼 수 있습니다.

KeyPairCredential

SSH(Secure Shell) 및 PKI(Public-Key Cryptography Standards) 키 쌍을 KeyPairCredential로 모두 사용할 수 있습니다. 키 쌍에는 지정된 사용자만 알고 있는 공유 공개 키와 개인 키가 모두 포함됩니다.

WildFly Elytron 툴만 사용하여 KeyPairCredential를 관리할 수 있습니다.

SecretKeyCredential
SecretKeyCredential은 Elytron에서 암호화된 표현식을 만드는 데 사용할 수 있는 고급 암호화 표준(AES) 키입니다. 암호화된 식에 대한 자세한 내용은 Elytron의 Encrypted 표현식을 참조하십시오.

4.1.3. Elytron 인증 정보 저장소에서 지원하는 인증 정보 유형

다음 표에서는 어떤 인증 정보 저장소에서 지원하는 인증 정보 유형을 보여줍니다.

인증 정보 유형KeyStoreCredentialStore/credential-storePropertiesCredentialStore/secret-key-credential-store

PasswordCredential

있음

없음

KeyPairCredential

있음

없음

SecretKeyCredential

있음

있음

4.1.4. JBoss EAP 관리 CLI를 사용한 인증 정보 저장소 작업

실행 중인 JBoss EAP 서버에서 JBoss EAP 자격 증명을 관리하려면 제공된 관리 CLI 작업을 사용합니다. JBoss EAP 관리 CLI를 사용하여 PasswordCredentialSecretKeyCredential 을 관리할 수 있습니다.

참고

이러한 작업은 수정 가능한 인증 정보 저장소에서만 수행할 수 있습니다. 모든 인증 정보 저장소 유형은 기본적으로 수정할 수 있습니다.

4.1.4.1. 독립 실행형 서버의 키StoreCredentialStore/credential-store 생성

파일 시스템의 모든 디렉터리에서 독립 실행형 서버로 실행되는 JBoss EAP에 대한 KeyStoreCredentialStore를 생성합니다. 보안의 경우 저장소를 포함하는 디렉터리에 제한된 사용자만 액세스할 수 있어야 합니다.

사전 요구 사항

  • JBoss EAP가 실행 중인 사용자 계정에 대해 KeyStoreCredentialStore가 포함된 디렉터리에 대한 읽기/쓰기 액세스 권한이 있어야 합니다.
참고

동일한 Elytron 기능을 구현하므로 credential-storesecret-key-credential-store 의 동일한 이름을 사용할 수 없습니다. org.wildfly.security.credential-store.

절차

  • 다음 관리 CLI 명령을 사용하여 KeyStoreCredentialStore를 생성합니다.

    구문

    /subsystem=elytron/credential-store=<name_of_credential_store>:add(path="<path_to_store_file>", relative-to=<base_path_to_store_file>, credential-reference={clear-text=<store_password>}, create=true)

    예제

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:add(path="exampleKeyStoreCredentialStore.jceks", relative-to=jboss.server.data.dir, credential-reference={clear-text=password}, create=true)
    {"outcome" => "success"}

4.1.4.2. 관리형 도메인의 KeyStoreCredentialStore/credential-store 생성

관리형 도메인에서 KeyStoreCredentialStore를 생성할 수 있지만 먼저 WildFly Elytron 도구를 사용하여 KeyStoreCredentialStore를 준비해야 합니다. 단일 관리형 도메인에 여러 호스트 컨트롤러가 있는 경우 다음 옵션 중 하나를 선택합니다.

  • 각 호스트 컨트롤러에서 KeyStoreCredentialStore를 생성하고 각 KeyStoreCredentialStore에 자격 증명을 추가합니다.
  • 하나의 호스트 컨트롤러에서 다른 모든 호스트 컨트롤러에 저장된 KeyStoreCredentialStore를 복사합니다.
  • NFS(Network File System)에 KeyStoreCredentialStore 파일을 저장한 다음, 생성한 모든 KeyStoreCredentialStore 리소스에 해당 파일을 사용합니다.

또는 WildFly Elytron 툴을 사용하지 않고 호스트 컨트롤러에 자격 증명을 사용하여 KeyStoreCredentialStore 파일을 만들 수도 있습니다.

참고

동일한 프로필의 모든 서버에 KeyStoreCredentialStore 파일이 포함되어 있기 때문에 모든 서버에서 KeyStoreCredentialStore 리소스를 정의할 필요는 없습니다. 키StoreCredentialStore 파일은 서버 데이터 디렉터리 relative-to=jboss.server.data.dir 에서 찾을 수 있습니다.

중요

동일한 Elytron 기능을 구현하므로 credential-storesecret-key-credential-store 의 동일한 이름을 사용할 수 없습니다. org.wildfly.security.credential-store.

다음 절차에서는 NFS를 사용하여 모든 호스트 컨트롤러에 KeyStoreCredentialStore 파일을 제공하는 방법을 설명합니다.

절차

  1. WildFly Elytron 툴을 사용하여 KeyStoreCredentialStore 스토리지 파일을 생성합니다. 이에 대한 자세한 내용은 WildFly Elytron 툴을 사용한 Credential store 작업을 참조하십시오.
  2. 스토리지 파일을 배포합니다. 예를 들어 scp 명령을 사용하여 각 호스트 컨트롤러에 할당하거나 NFS에 저장하고 모든 KeyStoreCredentialStore 리소스에 사용합니다.

    참고

    일관성을 유지하려면 여러 리소스 및 호스트 컨트롤러에서 사용하고 NFS에 저장한 KeyStoreCredentialStore 파일의 경우 읽기 전용 모드에서 KeyStoreCredentialStore를 사용해야 합니다. 또한 KeyStoreCredentialStore 파일에 절대 경로를 제공하십시오.

    구문

    /profile=<profile_name>/subsystem=elytron/credential-store=<name_of_credential_store>:add(path=<absolute_path_to_store_keystore>,credential-reference={clear-text="<store_password>"},create=false,modifiable=false)

    예제

    /profile=full-ha/subsystem=elytron/credential-store=exampleCredentialStoreDomain:add(path=/usr/local/etc/example-cred-store.cs,credential-reference={clear-text="password"},create=false,modifiable=false)

  3. 선택 사항: 프로필에 credential-store 리소스를 정의해야 하는 경우 스토리지 파일을 사용하여 리소스를 생성합니다.

    구문

    /profile=<profile_name>/subsystem=elytron/credential-store=<name_of_credential_store>:add(path=<path_to_store_file>,credential-reference={clear-text="<store_password>"})

    예제

    /profile=full-ha/subsystem=elytron/credential-store=exampleCredentialStoreHA:add(path=/usr/local/etc/example-cred-store-ha.cs, credential-reference={clear-text="password"})

  4. 선택 사항: 호스트 컨트롤러에 대한 KeyStoreCredentialStore 리소스를 생성합니다.

    구문

    /host=<host_controller_name>/subsystem=elytron/credential-store=<name_of_credential_store>:add(path=<path_to_store_file>,credential-reference={clear-text="<store_password>"})

    예제

    /host=master/subsystem=elytron/credential-store=exampleCredentialStoreHost:add(path=/usr/local/etc/example-cred-store-host.cs, credential-reference={clear-text="password"})

4.1.4.3. 독립 실행형 서버의 PropertiesCredentialStore/secret-key-credential-store 생성

관리 CLI를 사용하여 PropertiesCredentialStore를 생성합니다. PropertiesCredentialStore를 생성할 때 JBoss EAP는 기본적으로 시크릿 키를 생성합니다. 생성된 키의 이름은 key 이며 크기는 256비트입니다.

사전 요구 사항

  • JBoss EAP가 실행 중인 사용자 계정에 대한 PropertiesCredentialStore가 포함된 디렉터리에 대한 읽기/쓰기 액세스 권한이 있어야 합니다.

절차

  • 다음 명령을 사용하여 관리 CLI를 사용하여 PropertiesCredentialStore를 생성합니다.

    구문

    /subsystem=elytron/secret-key-credential-store=<name_of_credential_store>:add(path="<path_to_the_credential_store>", relative-to=<path_to_store_file>)

    예제

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:add(path=examplePropertiesCredentialStore.cs, relative-to=jboss.server.config.dir)
    {"outcome" => "success"}

4.1.4.4. 키StoreCredentialStore/credential-store에 PasswordCredential 추가

구성 파일에서 해당 암호를 숨기려면 PasswordCredential로 사용해야 하는 해당 리소스에 대한 일반 텍스트 암호를 추가합니다. 그런 다음 이 저장된 자격 증명을 참조하여 암호를 노출하지 않고도 해당 리소스에 액세스할 수 있습니다.

사전 요구 사항

절차

  • KeyStoreCredentialStore에 새 PasswordCredential을 추가합니다.

    구문

    /subsystem=elytron/credential-store=<name_of_credential_store>:add-alias(alias=<alias>, secret-value=<secret-value>)

    예제

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:add-alias(alias=passwordCredentialAlias, secret-value=StrongPassword)
    {"outcome" => "success"}

검증

  • 다음 명령을 실행하여 PasswordCredential이 KeyStoreCredentialStore에 추가되었는지 확인합니다.

    구문

    /subsystem=elytron/credential-store=<name_of_credential_store>:read-aliases()

    예제

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:read-aliases()
    {
        "outcome" => "success",
        "result" => ["passwordcredentialalias"]
    }

4.1.4.5. KeyStoreCredentialStore/credential-store에서 SecretKeyCredential 생성

KeyStoreCredentialStore에서 SecretKeyCredential을 생성합니다. 기본적으로 Elytron는 256비트 키를 만듭니다. 다른 크기를 원하는 경우 키 크기 특성에 128비트 또는 192-비트 키를 지정할 수 있습니다.

사전 요구 사항

절차

  1. 다음 관리 CLI 명령을 사용하여 KeyStoreCredentialStore에서 SecretKeyCredential을 생성합니다.

    구문

    /subsystem=elytron/credential-store=<name_of_credential_store>:generate-secret-key(alias=<alias>, key-size=<128_or_192>)

    예제

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:generate-secret-key(alias=secretKeyCredentialAlias)

검증

  • 다음 명령을 실행하여 Elytron이 KeyStoreCredentialStore에 SecretKeyCredential을 저장했는지 확인합니다.

    구문

    /subsystem=elytron/credential-store=<credential_store>:read-aliases()

    예제

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:read-aliases()
    {
        "outcome" => "success",
        "result" => [
            "secretkeycredentialalias"
        ]
    }

4.1.4.6. PropertiesCredentialStore/secret-key-credential-store에서 SecretKeyCredential 생성

PropertiesCredentialStore에서 SecretKeyCredential을 생성합니다. 기본적으로 Elytron는 256비트 키를 만듭니다. 다른 크기를 원하는 경우 키 크기 특성에 128비트 또는 192-비트 키를 지정할 수 있습니다.

SecretKeyCredential을 생성할 때 Elytron은 새로운 임의의 비밀 키를 생성하여 SecretKeyCredential로 저장합니다. PropertiesCredentialStore에서 내보내기 작업을 사용하여 자격 증명의 내용을 볼 수 있습니다.

중요

JBoss EAP에서 손실된 Elytron 자격 증명을 암호 해독하거나 검색할 수 없으므로 PropertiesCredentialStore, SecretKeyCredential 또는 둘 다의 백업을 생성해야 합니다.

PropertiesCredentialStore에서 내보내기 작업을 사용하여 SecretKeyCredential의 값을 가져올 수 있습니다. 그런 다음 이 값을 백업으로 저장할 수 있습니다. 자세한 내용은 PropertiesCredentialStore/secret-key-credential-store에서 SecretKeyCredential 내보내기 를 참조하십시오.

사전 요구 사항

절차

  • 다음 관리 CLI 명령을 사용하여 PropertiesCredentialStore에서 SecretKeyCredential를 생성합니다.

    구문

    /subsystem=elytron/secret-key-credential-store=<name_of_the_properties_credential_store>:generate-secret-key(alias=<alias>, key-size=<128_or_192>)

    예제

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:generate-secret-key(alias=secretKeyCredentialAlias)
    {"outcome" => "success"}

검증

  • 다음 명령을 실행하여 Elytron가 SecretKeyCredential을 생성했는지 확인합니다.

    구문

    /subsystem=elytron/secret-key-credential-store=<name_of_the_properties_credential_store>:read-aliases()

    예제

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:read-aliases()
    {
        "outcome" => "success",
        "result" => [
            "secretkeycredentialalias",
            "key"
        ]
    }

4.1.4.7. PropertiesCredential으로 SecretKeyCredentials/secret-key-credential-store 가져오기

PropertiesCredentialStore 외부에서 만든 SecretKeyCredentialCredential을 Elytron PropertiesCredentialStore로 가져올 수 있습니다. 다른 인증 정보 저장소에서 SecretKeyCredentialCredentialStore를 내보냈다고 가정하겠습니다. (예:tekton-hierayou can import it to the PropertiesCredentialStore).

사전 요구 사항

절차

  1. 다음 명령을 사용하여 관리 CLI에서 명령 캐싱을 비활성화합니다.

    중요

    캐싱을 비활성화하지 않으면 관리 CLI 기록 파일에 액세스할 수 있는 모든 사용자에게 시크릿 키가 표시됩니다.

    history --disable
  2. 다음 관리 CLI 명령을 사용하여 시크릿 키를 가져옵니다.

    구문

    /subsystem=elytron/secret-key-credential-store=<name_of_credential_store>:import-secret-key(alias=<alias>, key="<secret_key>")

    예제

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:import-secret-key(alias=imported, key="RUxZAUs+Y1CzEPw0g2AHHOZ+oTKhT9osSabWQtoxR+O+42o11g==")

  3. 다음 관리 CLI 명령을 사용하여 명령 캐싱을 다시 활성화합니다.

    history --enable

4.1.4.8. KeyStoreCredentialStore/credential-store에 자격 증명 나열

KeyStoreCredentialStore에 저장된 모든 인증 정보를 보려면 관리 CLI를 사용하여 나열할 수 있습니다.

절차

  • 다음 관리 CLI 명령을 사용하여 KeyStoreCredentialStore에 저장된 인증 정보를 나열합니다.

    구문

    /subsystem=elytron/credential-store=<name_of_credential_store>:read-aliases()

    예제

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:read-aliases()
    {
        "outcome" => "success",
        "result" => [
            "passwordcredentialalias",
            "secretkeycredentialalias"
        ]
    }

4.1.4.9. PropertiesCredentialStore/secret-key-credential-store에 자격 증명 나열

PropertiesCredentialStore에 저장된 모든 자격 증명을 보려면 관리 CLI를 사용하여 나열할 수 있습니다.

절차

  • 다음 관리 CLI 명령을 사용하여 PropertiesCredentialStore에 저장된 자격 증명을 나열합니다.

    구문

    /subsystem=elytron/secret-key-credential-store=<name_of_credential_store>:read-aliases()

    예제

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:read-aliases()
    {
        "outcome" => "success",
        "result" => [
            "secretkeycredentialalias",
            "key"
        ]
    }

4.1.4.10. KeyStoreCredentialStore/credential-store에서 SecretKeyCredential 자격 증명 내보내기

KeyStoreCredentialStore에서 기존 SecretKeyCredential을 내보내 SecretKeyCredential을 사용하거나 SecretKeyCredential의 백업을 생성할 수 있습니다.

사전 요구 사항

절차

  • 다음 관리 CLI 명령을 사용하여 KeyStoreCredentialStore에서 SecretKeyCredential을 내보냅니다.

    구문

    /subsystem=elytron/credential-store=<name_of_credential_store>:export-secret-key(alias=<alias>)

    예제

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:export-secret-key(alias=secretKeyCredentialAlias)
    {
        "outcome" => "success",
        "result" => {"key" => "RUxZAUui+8JkoDCE6mFyA3cCIbSAZaXq5wgYejj1scYgdDqWiw=="}
    }

4.1.4.11. PropertiesCredentialStore/secret-key-credential-store에서 SecretKeyCredential 내보내기

PropertiesCredentialStore에서 기존 SecretKeyCredential을 내보내 SecretKeyCredential 또는 SecretKeyCredential의 백업을 생성할 수 있습니다.

사전 요구 사항

절차

  • 다음 관리 CLI 명령을 사용하여 PropertiesCredentialStore에서 SecretKeyCredentials를 내보냅니다.

    구문

    /subsystem=elytron/secret-key-credential-store=<name_of_credential_store>:export-secret-key(alias=<alias>)

    예제

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:export-secret-key(alias=secretkeycredentialalias)
    {
        "outcome" => "success",
        "result" => {"key" => "RUxZAUtxXcYvz0aukZu+odOynIr0ByLhC72iwzlJsi+ZPmONgA=="}
    }

4.1.4.12. KeyStoreCredentialStore/credential-store에서 인증 정보 제거

모든 자격 증명 유형을 KeyStoreCredentialStore에 저장할 수 있지만, 자격 증명을 제거할 때 기본적으로 Elytron은 PasswordCredential이 있다고 가정합니다. 다른 인증 정보 유형을 제거하려면 entry-type 특성에 지정합니다.

절차

  • 다음 관리 CLI 명령을 사용하여 KeyStoreCredentialStore에서 인증 정보를 제거합니다.

    구문

    /subsystem=elytron/credential-store=<name_of_credential_store>:remove-alias(alias=<alias>, entry-type=<credential_type>)

    PasswordCredential 제거 예

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:remove-alias(alias=passwordCredentialAlias)
    {
        "outcome" => "success",
        "response-headers" => {"warnings" => [{
            "warning" => "Update dependent resources as alias 'passwordCredentialAlias' does not exist anymore",
            "level" => "WARNING",
            "operation" => {
                "address" => [
                    ("subsystem" => "elytron"),
                    ("credential-store" => "exampleKeyStoreCredentialStore")
                ],
                "operation" => "remove-alias"
            }
        }]}
    }

    SecretKeyCredential 제거 예

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:remove-alias(alias=secretKeyCredentialAlias, entry-type=SecretKeyCredential)
    {
        "outcome" => "success",
        "response-headers" => {"warnings" => [{
            "warning" => "Update dependent resources as alias 'secretKeyCredentialAl
    ias' does not exist anymore",
            "level" => "WARNING",
            "operation" => {
                "address" => [
                    ("subsystem" => "elytron"),
                    ("credential-store" => "exampleKeyStoreCredentialStore")
                ],
                "operation" => "remove-alias"
            }
        }]}
    }

검증

  • 다음 명령을 실행하여 Elytron가 인증 정보를 제거했는지 확인합니다.

    구문

    /subsystem=elytron/credential-store=<name_of_credential_store>:read-aliases()

    예제

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:read-aliases()
    {
        "outcome" => "success",
        "result" => []
    }

    제거한 인증 정보가 나열되지 않습니다.

4.1.4.13. PropertiesCredentialStore/secret-key-credential-store에서 인증 정보 제거

SecretKeyCredential 유형만 PropertiesCredentialStore에 저장할 수 있습니다. 즉, PropertiesCredentialStore에서 자격 증명을 제거할 때 항목 유형을 지정할 필요가 없습니다.

절차

  • 다음 명령을 사용하여 PropertiesCredentialStore에서 SecretKeyCredentials를 제거합니다.

    구문

    /subsystem=elytron/secret-key-credential-store=<name_of_credential_store>:remove-alias(alias=<alias>)

    예제

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:remove-alias(alias=secretKeyCredentialAlias)
    {
        "outcome" => "success",
        "response-headers" => {"warnings" => [{
            "warning" => "Update dependent resources as alias 'secretKeyCredentialAlias' does not exist anymore",
            "level" => "WARNING",
            "operation" => {
                "address" => [
                    ("subsystem" => "elytron"),
                    ("secret-key-credential-store" => "examplePropertiesCredentialSt
    ore")
                ],
                "operation" => "remove-alias"
            }
        }]}
    }

검증

  • 다음 명령을 실행하여 Elytron가 인증 정보를 제거했는지 확인합니다.

    구문

    /subsystem=elytron/secret-key-credential-store=<name_of_credential_store>:read-aliases()

    예제

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:read-aliases()
    {
        "outcome" => "success",
        "result" => []
    }

    제거한 인증 정보가 나열되지 않습니다.

4.1.5. WildFly Elytron 툴을 사용한 인증 정보 저장소 작업

4.1.5.1. WildFly Elytron 툴을 사용하여 KeyStoreCredentialStore/credential-store 생성

Elytron에서는 모든 자격 증명 유형을 저장할 수 있는 KeyStoreCredentialStore를 오프라인으로 만들 수 있습니다.

절차

  • 다음 명령과 함께 WildFly Elytron 툴을 사용하여 KeyStoreCredentialStore를 생성합니다.

    구문

    $ EAP_HOME/bin/elytron-tool.sh credential-store --create --location "<path_to_store_file>" --password <store_password>

    예제

    $ EAP_HOME/bin/elytron-tool.sh credential-store --create --location "../cred_stores/example-credential-store.jceks" --password storePassword
    Credential Store has been successfully created

    명령에 저장소 암호를 포함하지 않으려면 해당 인수를 생략한 다음 프롬프트에서 수동으로 암호를 입력합니다. WildFly Elytron 툴에서 생성된 마스크된 암호를 사용할 수도 있습니다. 마스킹된 암호 생성에 대한 자세한 내용은 WildFly Elytron 툴을 사용하여 마스크된 암호화된 문자열 생성을 참조하십시오.

4.1.5.2. Bouncy callle 공급자를 사용하여 KeyStoreCredentialStore/credential-store 생성

Bouncy castle 공급자를 사용하여 KeyStoreCredentialStore를 만듭니다.

사전 요구 사항

참고

동일한 Elytron 기능을 구현하므로 credential-storesecret-key-credential-store 의 동일한 이름을 사용할 수 없습니다. org.wildfly.security.credential-store.

절차

  1. BCFKS(BCFKS) 키 저장소(BCFKS) 키 저장소를 정의합니다. FIPS는 연방 정보 처리 표준을 나타냅니다. 이미 계정이 있는 경우 다음 단계로 이동합니다.

    $ keytool -genkeypair -alias <key_pair_alias> -keyalg <key_algorithm> -keysize <key_size> -storepass <key_pair_and_keystore_password> -keystore <path_to_keystore> -storetype BCFKS -keypass <key_pair_and_keystore_password>
    중요

    키 저장소 키pass 및 storepass 속성이 동일한지 확인합니다. 해당 시스템이 아닌 경우 elytron 하위 시스템의 BCFKS 키 저장소에서 이를 정의할 수 없습니다.

  2. KeyStoreCredentialStore에 대한 시크릿 키를 생성합니다.

    $ keytool -genseckey -alias <key_alias> -keyalg <key_algorithm> -keysize <key_size> -keystore <path_to_keystore> -storetype BCFKS -storepass <key_and_keystore_password> -keypass <key_and_keystore_password>
  3. WildFly Elytron 툴을 다음 명령과 함께 사용하여 KeyStoreCredentialStore를 정의합니다.

    $ EAP_HOME/bin/elytron-tool.sh credential-store -c -a <alias> -x <alias_password> -p <key_and_keystore_password> -l <path_to_keystore> -u "keyStoreType=BCFKS;external=true;keyAlias=<key_alias>;externalPath=<path_to_credential_store>"

4.1.5.3. WildFly Elytron 툴을 사용하여 PropertiesCredentialStore/secret-key-credential-store 생성

Elytron에서는 SecretKeyCredentialCredential 인스턴스를 저장할 수 있는 속성CredentialStore를 오프라인에서 만들 수 있습니다.

절차

  • 다음 명령과 함께 WildFly Elytron 툴을 사용하여 PropertiesCredentialStore를 생성합니다.

    구문

    $ EAP_HOME/bin/elytron-tool.sh credential-store --create --location "<path_to_store_file>" --type PropertiesCredentialStore

    예제

    $ bin/elytron-tool.sh credential-store --create --location=standalone/configuration/properties-credential-store.cs --type PropertiesCredentialStore
    Credential Store has been successfully created

4.1.5.4. WildFly Elytron 툴 KeyStoreCredentialStore/credential-store 작업

WildFly Elytron 툴을 사용하여 다음과 같은 다양한 KeyStoreCredentialStore 작업을 수행할 수 있습니다.

PasswordCredential 추가

다음 WildFly Elytron 툴 명령을 사용하여 KeyStoreCredentialStore에 PasswordCredential을 추가할 수 있습니다.

구문

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "<path_to_store_file>" --password <store_password> --add <alias> --secret <sensitive_string>

예제

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "../cred_stores/example-credential-store.jceks" --password storePassword --add examplePasswordCredential --secret speci@l_db_pa$$_01
Alias "examplePasswordCredential" has been successfully stored

명령에 보안을 배치하지 않으려면 해당 인수를 생략한 다음 메시지가 표시되면 수동으로 시크릿을 입력합니다.

SecretKeyCredential 생성

다음 WildFly Elytron 툴 명령을 사용하여 KeyStoreCredentialStore에 SecretKeyCredential을 추가할 수 있습니다.

구문

$ EAP_HOME/bin/elytron-tool.sh credential-store --generate-secret-key=example --location=<path_to_the_credential_store> --password <store_password>

예제

$ EAP_HOME/bin/elytron-tool.sh credential-store --generate-secret-key=example --location "../cred_stores/example-credential-store.jceks" --password storePassword
Alias "example" has been successfully stored

명령에 보안을 배치하지 않으려면 해당 인수를 생략한 다음 메시지가 표시되면 수동으로 시크릿을 입력합니다.

기본적으로 JBoss EAP에서 SecretKeyCredential을 생성할 때 256비트 시크릿 키를 생성합니다. 크기를 변경하려면 각각 128비트 또는 192비트 키를 생성하도록 --size=128 또는 --size=192 를 지정할 수 있습니다.

SecretKeyCredential 가져오기

다음 WildFLy Elytron 툴 명령을 사용하여 SecretKeyCredential을 가져올 수 있습니다.

구문

$ EAP_HOME/bin/elytron-tool.sh credential-store --import-secret-key=imported --location=<path_to_credential_store> --password=<store_password>

예제

$ EAP_HOME/bin/elytron-tool.sh credential-store --import-secret-key=imported --location=../cred_stores/example-credential-store.jceks --password=storePassword

가져올 시크릿 키를 입력합니다.

모든 인증 정보를 나열

다음 WildFly Elytron 툴 명령을 사용하여 KeyStoreCredentialStore에서 자격 증명을 나열할 수 있습니다.

구문

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "<path_to_store_file>" --password <store_password> --aliases

예제:

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "../cred_stores/example-credential-store.jceks" --password storePassword --aliases
Credential store contains following aliases: examplepasswordcredential example

별칭이 있는지 확인합니다.

다음 명령을 사용하여 인증 정보 저장소에 별칭이 있는지 확인합니다.

구문

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "<path_to_store_file>" --password <store_password> --exists <alias>

예제

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "../cred_stores/example-credential-store.jceks" --password storePassword --exists examplepasswordcredential
Alias "examplepasswordcredential" exists

SecretKeyCredential 내보내기

다음 명령을 사용하여 KeyStoreCredentialStore에서 SecretKeyCredentialStore를 내보낼 수 있습니다.

구문

$ EAP_HOME/bin/elytron-tool.sh credential-store --export-secret-key=<alias> --location=<path_to_credential_store> --password=storePassword

예제

$ EAP_HOME/bin/elytron-tool.sh credential-store --export-secret-key=example --location=../cred_stores/example-credential-store.jceks --password=storePassword
Exported SecretKey for alias example=RUxZAUtBiAnoLP1CA+i6DtcbkZHfybBJxPeS9mlVOmEYwjjmEA==

인증 정보 제거

다음 명령을 사용하여 인증 정보 저장소에서 자격 증명을 제거할 수 있습니다.

구문

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "<path_to_store_file>" --password <store_password> --remove <alias>

예제

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "../cred_stores/example-credential-store.jceks" --password storePassword --remove examplepasswordcredential
Alias "examplepasswordcredential" has been successfully removed

4.1.5.5. WildFly Elytron 툴 PropertiesCredentialStore/secret-key-credential-store 작업

WildFly Elytron 도구를 사용하여 SecretKeyCredentialStore 작업을 수행할 수 있습니다.

SecretKeyCredential 생성

다음 WildFly Elytron 툴 명령을 사용하여 PropertiesCredentialStore에서 SecteKeyCredential 을 생성할 수 있습니다.

구문

$ EAP_HOME/bin/elytron-tool.sh credential-store --generate-secret-key=example --location "<path_to_the_credential_store>" --type PropertiesCredentialStore

예제

$ EAP_HOME/bin/elytron-tool.sh credential-store --generate-secret-key=example --location "standalone/configuration/properties-credential-store.cs" --type PropertiesCredentialStore
Alias "example" has been successfully stored

SecretKeyCredential 가져오기

다음 WildFLy Elytron 툴 명령을 사용하여 SecretKeyCredential을 가져올 수 있습니다.

구문

$ EAP_HOME/bin/elytron-tool.sh credential-store --import-secret-key=imported --location=<path_to_credential_store> --type PropertiesCredentialStore

예제

$ EAP_HOME/bin/elytron-tool.sh credential-store --import-secret-key=imported --location "standalone/configuration/properties-credential-store.cs" --type PropertiesCredentialStore

모든 인증 정보를 나열

다음 WildFly Elytron 툴 명령을 사용하여 PropertiesCredentialStore의 자격 증명을 나열할 수 있습니다.

구문

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "<path_to_store_file>"  --aliases --type PropertiesCredentialStore

예제

$ EAP_HOME/bin/elytron-tool.sh credential-store  --location "standalone/configuration/properties-credential-store.cs" --aliases --type PropertiesCredentialStore
Credential store contains following aliases: example

SecretKeyCredential 내보내기

다음 명령을 사용하여 PropertiesCredentialStore에서 SecretKeyCredentialStore를 내보낼 수 있습니다.

구문

$ EAP_HOME/bin/elytron-tool.sh credential-store --export-secret-key=<alias> --location "<path_to_credential_store>"  --type PropertiesCredentialStore

예제

$ EAP_HOME/bin/elytron-tool.sh credential-store --export-secret-key=example --location "standalone/configuration/properties-credential-store.cs" --type PropertiesCredentialStore
Exported SecretKey for alias example=RUxZAUt1EZM7PsYRgMGypkGirSel+5Eix4aSgwop6jfxGYUQaQ==

인증 정보 제거

다음 명령을 사용하여 인증 정보 저장소에서 자격 증명을 제거할 수 있습니다.

구문

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "<path_to_store_file>" --remove <alias> --type PropertiesCredentialStore

예제

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "standalone/configuration/properties-credential-store.cs"  --remove example --type PropertiesCredentialStore
Alias "example" has been successfully removed

4.1.5.6. WildFly Elytron 툴을 사용하여 생성된 자격 증명 저장소 추가 JBoss EAP Server

WildFly Elytron 툴을 사용하여 인증 정보 저장소를 생성한 후 실행 중인 JBoss EAP 서버에 추가할 수 있습니다.

사전 요구 사항

절차

  • 다음 관리 CLI 명령을 사용하여 실행 중인 JBoss EAP 서버에 자격 증명 저장소를 추가합니다.

    /subsystem=elytron/credential-store=<store_name>:add(location="<path_to_store_file>",credential-reference={clear-text=<store_password>})

    예를 들면 다음과 같습니다.

    /subsystem=elytron/credential-store=my_store:add(location="../cred_stores/example-credential-store.jceks",credential-reference={clear-text=storePassword})

자격 증명 저장소를 JBoss EAP 구성에 추가한 후 credential-reference 특성을 사용하여 인증 정보 저장소에 저장된 암호 또는 중요한 문자열을 참조할 수 있습니다.

자세한 내용은 사용 가능한 옵션의 자세한 목록을 보려면 EAP_HOME/bin/elytron-tool.sh credentials-store --help 명령을 사용합니다.

4.1.5.7. WildFly Elytron 툴 키 쌍 관리 작업

다음 인수를 사용하여 elytron-tool.sh 를 사용하여 자격 증명 저장소의 별칭에 저장할 수 있는 새 키 쌍 생성과 같은 자격 증명 저장소를 조작할 수 있습니다.

키 쌍 생성

generate-key-pair 명령을 사용하여 키 쌍을 생성합니다. 그런 다음 키 쌍을 자격 증명 저장소의 별칭 아래에 저장할 수 있습니다. 다음 예제에서는 인증 정보 저장소에 지정된 위치에 저장된 3072 비트의 할당된 크기를 가진 RSA 키 쌍의 생성을 보여줍니다. 키 쌍에 제공되는 별칭의 예는 다음과 같습니다.

$ EAP_HOME/bin/elytron-tool.sh credential-store --location=<path_to_store_file> --generate-key-pair example --algorithm RSA --size 3072
키 쌍 가져오기

import-key-pair 명령을 사용하여 기존 SSH 키 쌍을 지정된 별칭이 있는 자격 증명 저장소로 가져옵니다. 다음 예제에서는 OpenSSH 형식의 개인 키가 포함된 /home/user/.ssh/id_rsa 파일에서 예제 별칭을 사용하여 키 쌍을 가져옵니다.

$ EAP_HOME/bin/elytron-tool.sh credential-store --import-key-pair example --private-key-location /home/user/.ssh/id_rsa --location=<path_to_store_file>
키 쌍 내보내기

키 쌍의 공개 키를 표시하려면 export-key-pair-public-key 명령을 사용합니다. 공개 키에는 OpenSSH 형식으로 지정된 별칭이 있습니다. 다음 예제에서는 alias 예의 공개 키를 표시합니다.

$ EAP_HOME/bin/elytron-tool.sh credential-store --location=<path_to_store_file> --export-key-pair-public-key example

Credential store password:
Confirm credential store password:
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMfncZuHmR7uglb0M96ieArRFtp42xPn9+ugukbY8dyjOXoi
cZrYRyy9+X68fylEWBMzyg+nhjWkxJlJ2M2LAGY=
참고

export-key-pair-public-key 명령을 실행한 후 인증 정보 저장소 암호를 입력하라는 메시지가 표시됩니다. 암호가 없는 경우 프롬프트를 비워 둡니다.

4.1.5.8. Elytron 구성 파일에서 저장된 키 쌍의 사용 예

키 쌍은 공개 키와 개인 키의 두 가지이지만 일치하는 암호화 키로 구성됩니다. elytron 구성 파일에서 키 쌍을 참조하려면 인증 정보 저장소에 키 쌍을 저장해야 합니다. 그런 다음 Git에 액세스 권한을 제공하여 독립 실행형 서버 구성 데이터를 관리할 수 있습니다.

다음 예제에서는 elytron 구성 파일의 <credential-stores> 요소에서 자격 증명 저장소와 해당 속성을 참조합니다. <credential> 요소는 키 쌍을 저장하는 자격 증명 저장소 및 별칭을 참조합니다.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <authentication-client xmlns="urn:elytron:client:1.6">

     <credential-stores>
        <credential-store name="${credential_store_name}">
           <protection-parameter-credentials>
              <clear-password password="${credential_store_password}"/>
           </protection-parameter-credentials>
           <attributes>
              <attribute name="path" value="${path_to_credential_store}"/>
           </attributes>
        </credential-store>
     </credential-stores>

     <authentication-rules>
        <rule use-configuration="${configuration_file_name}"/>
     </authentication-rules>

     <authentication-configurations>
        <configuration name="${configuration_file_name}">
           <credentials>
              <credential-store-reference store="${credential_store_name}" alias="${alias_of_key_pair}"/>
           </credentials>
        </configuration>
     </authentication-configurations>

  </authentication-client>
</configuration>

elytron 구성 파일을 구성한 후 SSH 인증에 키 쌍을 사용할 수 있습니다.

4.1.5.9. WildFly Elytron 툴을 사용하여 마스킹된 암호화된 문자열 생성

WildFly Elytron 도구를 사용하여 자격 증명 저장소의 일반 텍스트 암호 대신 사용할 PicketBox 호환 MASK 암호화 문자열을 생성할 수 있습니다.

절차

  • 마스킹된 문자열을 생성하려면 다음 명령을 사용하고 salt 및 반복 개수에 대한 값을 제공합니다.

    $ EAP_HOME/bin/elytron-tool.sh mask --salt <salt> --iteration <iteration_count> --secret <password>

    예를 들면 다음과 같습니다.

    $ EAP_HOME/bin/elytron-tool.sh mask --salt 12345678 --iteration 123 --secret supersecretstorepassword
    
    MASK-8VzWsSNwBaR676g8ujiIDdFKwSjOBHCHgnKf17nun3v;12345678;123

    명령에 시크릿을 제공하지 않으려면 해당 인수를 생략하면 표준 입력을 사용하여 수동으로 시크릿을 입력하라는 메시지가 표시됩니다.

자세한 내용은 사용 가능한 옵션 목록을 보려면 EAP_HOME/bin/elytron-tool.sh mask --help 명령을 사용하십시오.

4.1.6. Elytron의 암호화된 표현식

중요한 문자열의 보안을 유지하려면 서버 구성 파일에서 중요한 문자열 대신 암호화된 식을 사용할 수 있습니다.

암호화된 표현식은 문자열을 SecretKeyCredential로 암호화한 다음 인코딩 접두사와 확인자 이름과 결합하는 결과입니다. 인코딩 접두사는 Elytron가 표현식이 암호화된 표현식임을 나타냅니다. 확인자는 암호화된 표현식을 자격 증명 저장소의 해당 SecretKeyCredential에 매핑합니다.

Elytron의 expression=encryption 리소스는 암호화된 표현식을 사용하여 런타임에 암호화된 문자열을 디코딩합니다. 구성 파일에서 중요한 문자열 자체 대신 암호화된 표현식을 사용하면 문자열의 기밀성을 보호합니다. 암호화된 표현식은 다음 형식을 사용합니다.

특정 리졸버를 사용할 때의 구문

${ENC::RESOLVER_NAME:ENCRYPTED_STRING}

ENC 는 암호화된 표현식을 나타내는 접두사입니다.

RESOLVER_NAME 은 암호화된 문자열을 해독하는 데 Elytron를 사용하는 해결자입니다.

예제

${ENC::initialresolver:RUxZAUMQE+L5zx9LmCRLyh5fjdfl1WM7lhfthKjeoEU+x+RMi6s=}

기본 해결 방법을 사용하여 암호화된 표현식을 생성하는 경우 다음과 같습니다.

기본 확인자 사용 시 구문

${ENC::ENCRYPTED_STRING}

예제

${ENC::RUxZAUMQE+L5zx9LmCRLyh5fjdfl1WM7lhfthKjeoEU+x+RMi6s=}

이 경우 Elytron는 expression=encryption 리소스에 정의된 기본 확인자를 사용하여 표현식의 암호를 해독합니다. 이를 지원하는 모든 리소스 속성에 대해 암호화된 표현식을 사용할 수 있습니다. 속성이 암호화된 표현식을 지원하는지 확인하려면 read-resource-description 작업을 사용합니다. 예를 들면 다음과 같습니다.

mail/mail-session의 read-resource-description 예

/subsystem=mail/mail-session=*/:read-resource-description(recursive=true,access-control=none)
{
  "outcome"=>"success",
  "result"=>[{
  ...
    "from"=>{
      ...
      "expression-allowed"=>true,
      ...
   }]
}

이 예에서 의 속성은 암호화된 식을 지원합니다. 즉, 이메일 주소를 암호화한 다음 암호화된 표현식을 사용하여 에서 필드에 이메일 주소를 숨길 수 있습니다.

4.1.7. Elytron에서 암호화된 표현식 생성

중요한 문자열 및 SecretKeyCredential에서 암호화된 표현식을 만듭니다. 관리 모델의 중요한 문자열 대신 암호화된 표현식을 사용하여 중요한 문자열의 기밀성을 유지 관리합니다.

사전 요구 사항

절차

  1. 다음 관리 CLI 명령을 사용하여 인증 정보 저장소에서 기존 SecretKeyCredential의 별칭을 참조하는 확인자를 만듭니다.

    구문

    /subsystem=elytron/expression=encryption:add(resolvers=[{name=<name_of_the_resolver>, credential-store=<name_of_credential_store>, secret-key=<secret_key_alias>}])

    예제

    /subsystem=elytron/expression=encryption:add(resolvers=[{name=exampleResolver, credential-store=examplePropertiesCredentialStore, secret-key=key}])

    중복 리소스에 대한 오류 메시지가 표시되면 다음과 같이 add 대신 list-add 작업을 사용합니다.

    구문

    /subsystem=elytron/expression=encryption:list-add(name=resolvers, value={name=<name_of_the_resolver>, credential-store=<name_of_credential_store>, secret-key=<secret_key_alias>})

    예제

    /subsystem=elytron/expression=encryption:list-add(name=resolvers,value={name=exampleResolver, credential-store=examplePropertiesCredentialStore, secret-key=key})
    {
        "outcome" => "success",
        "response-headers" => {
            "operation-requires-reload" => true,
            "process-state" => "reload-required"
        }
    }

  2. 다음 관리 CLI 명령을 사용하여 서버를 다시 로드합니다.

    reload
  3. 관리 CLI에서 명령 캐싱을 비활성화합니다.

    중요

    캐싱을 비활성화하지 않으면 관리 CLI 기록 파일에 액세스할 수 있는 모든 사용자에게 시크릿 키가 표시됩니다.

    history --disable
  4. 다음 관리 CLI 명령을 사용하여 암호화된 표현식을 생성합니다.

    구문

    /subsystem=elytron/expression=encryption:create-expression(resolver=<existing_resolver>, clear-text=<sensitive_string_to_protect>)

    예제

    /subsystem=elytron/expression=encryption:create-expression(resolver=exampleResolver, clear-text=TestPassword)
    {
        "outcome" => "success",
        "result" => {"expression" => "${ENC::exampleResolver:RUxZAUMQgtpG7oFlHR2j1Gkn3GKIHff+HR8GcMX1QXHvx2uGurI=}"}
    }

    ${ENC::exampleResolver:RUxZAU OSPpG7oFlHR2j1Gkn3GKIHIff+HR8GcMX1QX1QX2uGurI=} 은 관리 모델의 TestPassword 대신 사용하는 암호화된 표현식입니다.

    다른 위치에서 동일한 일반 텍스트를 사용하는 경우 해당 위치의 일반 텍스트 대신 암호화된 표현식을 사용하기 전에 매번 이 명령을 반복합니다. 동일한 일반 텍스트에 대해 동일한 명령을 반복하면 Elytron가 각 호출에 대해 고유한 초기화 벡터를 사용하므로 동일한 키에 대해 다른 결과가 나타납니다.

    다른 암호화된 식을 사용하면 문자열에 하나의 암호화된 표현식이 손상되면 다른 암호화된 식에도 동일한 문자열이 포함되어 있는지 확인할 수 없습니다.

  5. 다음 관리 CLI 명령을 사용하여 명령 캐싱을 다시 활성화합니다.

    history --enable

4.1.8. JBoss EAP 구성에서 PasswordCredential 사용

자격 증명 저장소에 저장된 암호 또는 중요한 문자열을 참조하려면 JBoss EAP 구성에서 credentials-reference 특성을 사용합니다. JBoss EAP 구성 전반에서 대부분의 위치에 암호 또는 기타 중요한 문자열을 제공하는 대신 자격 증명 참조를 사용할 수 있습니다.

사전 요구 사항

절차

  • credential-reference 속성의 기존 KeyStoreCredentialStore 및 alias to the PasswordCredential을 참조합니다.

    구문

    credential-reference={store=<store_name>, alias=<alias>}

    예제

    data-source add --name=example_data_source --jndi-name=java:/example_data_source --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE --user-name=db_user --credential-reference={store=exampleKeyStoreCredentialStore, alias=passwordCredentialAlias}
    16:17:23,024 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:/example_data_source]

    이 예제에서는 KeyStoreCredentialStore exampleKeyStore CredentialStore 데이터베이스의 일반 텍스트 암호 대신 암호CredentialAlias 가 사용되므로 데이터베이스 암호를 보호합니다.

4.1.9. 암호화된 표현식을 사용하여 KeyStoreCredentialStore/credential-store 보안

암호화된 표현식을 사용하여 KeyStoreCredentialStore를 보호할 수 있습니다.

사전 요구 사항

절차

  • 일반 텍스트로 암호화된 표현식을 사용하는 KeyStoreCredential Store를 생성합니다.

    구문

    /subsystem=elytron/credential-store=<name_of_credential_store>:add(path=<path_to_the_credential_store>, create=true, modifiable=true, credential-reference={clear-text=<encrypted_expression>})

    예제

    /subsystem=elytron/credential-store=secureKeyStoreCredentialStore:add(path="secureKeyStoreCredentialStore.jceks", relative-to=jboss.server.data.dir, create=true, modifiable=true, credential-reference={clear-text=${ENC::exampleResolver:RUxZAUMQgtpG7oFlHR2j1Gkn3GKIHff+HR8GcMX1QXHvx2uGurI=}})
    {"outcome" => "success"}

4.1.10. 인증 정보 저장소의 인증 정보 자동 업데이트

인증 정보 저장소가 있는 경우 인증 정보 참조에서 자격 증명을 참조하기 전에 자격 증명을 추가하거나 기존 인증 정보를 업데이트할 필요가 없습니다. Elytron은 이 프로세스를 자동화합니다. 자격 증명 참조를 구성할 때 저장소와 일반 텍스트 특성을 둘 다 지정합니다. Elytron은 store 특성으로 지정된 자격 증명 저장소에서 자격 증명을 자동으로 추가하거나 업데이트합니다. 선택적으로 alias 속성을 지정할 수 있습니다.

Elytron은 다음과 같이 인증 정보 저장소를 업데이트합니다.

  • 별칭을 지정하는 경우 다음을 수행합니다.

    • 별칭에 대한 항목이 있으면 기존 자격 증명이 지정된 일반 텍스트 암호로 교체됩니다.
    • 별칭에 대한 항목이 없으면 지정된 별칭과 일반 텍스트 암호를 사용하여 새 항목이 자격 증명 저장소에 추가됩니다.
  • 별칭을 지정하지 않으면 Elytron은 별칭을 생성하고 지정된 alias 및 지정된 일반 텍스트 암호를 사용하여 자격 증명 저장소에 새 항목을 추가합니다.

자격 증명 저장소가 업데이트되면 관리 모델에서 일반 텍스트 특성이 제거됩니다.

다음 예제에서는 저장소,일반 텍스트별칭 속성을 지정하는 자격 증명 참조를 생성하는 방법을 보여줍니다.

/subsystem=elytron/key-store=exampleKS:add(relative-to=jboss.server.config.dir, path=example.keystore, type=JCEKS, credential-reference={store=exampleKeyStoreCredentialStore, alias=myNewAlias, clear-text=myNewPassword})
{
    "outcome" => "success",
    "result" => {"credential-store-update" => {
        "status" => "new-entry-added",
        "new-alias" => "myNewAlias"
    }}
}

다음 명령을 사용하여 이전에 정의된 자격 증명 저장소에 추가된 myNewAlias 항목에 대한 자격 증명을 업데이트할 수 있습니다.

/subsystem=elytron/key-store=exampleKS:write-attribute(name=credential-reference.clear-text,value=myUpdatedPassword)
{
    "outcome" => "success",
    "result" => {"credential-store-update" => {"status" => "existing-entry-updated"}},
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
참고

Credential -reference 매개변수가 포함된 작업이 실패하면 자동 인증 정보 저장소 업데이트가 발생하지 않습니다.

credentials -reference 특성에서 지정한 자격 증명 저장소는 변경되지 않습니다.

4.1.11. FIPShiera 호환 인증 정보 저장소 정의

NNSS(Network Security Services) 데이터베이스를 사용하거나 Bouncy NetNamespacele 공급자를 사용하여 연방 정보 처리 표준(FIPS) 호환 자격 증명 저장소를 정의할 수 있습니다.

4.1.11.1. NSS 데이터베이스를 사용하여 FIPShiera 호환 자격 증명 저장소 정의

연방 정보 처리 표준 (FIPS) 준수 키 저장소를 얻으려면 Sun PKCS#11 (PKCS는 공개 키 Cryptography Standards) 공급자를 사용하십시오. 데이터베이스 정의에 대한 지침은 NSS 데이터베이스 구성을 참조하십시오.

절차

  1. 자격 증명 저장소에서 사용할 비밀 키를 생성합니다.

    참고

    keytool 명령이 작동하려면 nss_pkcsll_fips.cfg 파일에서 nsssDbMode 특성을 readWrite 로 할당해야 합니다.

    $ keytool -keystore NONE -storetype PKCS11 -storepass <keystore_password> -genseckey -alias <key_alias> -keyalg <key_algorithm> -keysize <key_size>
  2. 외부 자격 증명 저장소를 생성합니다. 외부 자격 증명 저장소에는 PKCS#11 키 저장소의 시크릿 키가 있으며 이전 단계에서 정의한 별칭을 사용하여 이 키 저장소에 액세스합니다. 그런 다음 이 키 저장소를 사용하여 JCEKS(Java Cryptography Extension Keystore) 키 저장소에서 자격 증명을 해독합니다. 자격 증명 저장소 속성 외에도 Elytron은 credential-store KeyStoreCredentialStore 구현 속성을 사용하여 외부 인증 정보 저장소를 구성합니다.

    /subsystem=elytron/credential-store=<store_name>:add(modifiable=true, implementation-properties={"keyStoreType"=>"PKCS11", "external"=>"true", "keyAlias"=>"<key_alias>", externalPath="<path_to_JCEKS_file>"}, credential-reference={clear-text="<keystore_password>"}, create=true)
  3. 생성되고 나면 자격 증명 저장소를 사용하여 별칭을 정상적으로 저장할 수 있습니다.

    /subsystem=elytron/credential-store=<store_name>:add-alias(alias="<alias>", secret-value="<sensitive_string>")
  4. 자격 증명 저장소에서 를 읽고 별칭이 추가되었는지 확인합니다.

    /subsystem=elytron/credential-store=<store_name>:read-aliases()

4.1.11.2. Bouncy SCALEle 공급자를 사용하여 FIPShiera 호환 자격 증명 저장소 정의

Bouncy 2.1le 공급자를 사용하여 FIPS (Federal Information Processing Standards)hiera 호환 자격 증명 저장소를 정의합니다.

사전 요구 사항

절차

  1. 자격 증명 저장소에서 사용할 비밀 키를 생성합니다.

    $ keytool -genseckey -alias<key_alias> -keyalg <key_algorithm> -keysize <key_size> -keystore <path_to_keystore> -storetype BCFKS -storepass <key_and_keystore_password> -keypass <key_and_keystore_password>
    중요

    저장소의 키 패스 및 저장소는 elytron 하위 시스템에 정의된 FIPS 인증 정보 저장소와 동일해야 합니다.

  2. 외부 자격 증명 저장소를 생성합니다. 외부 자격 증명 저장소에는 BCFKS 키 저장소의 비밀 키가 있으며 이전 단계에서 정의한 별칭을 사용하여 이 키 저장소에 액세스합니다. 그런 다음 이 키 저장소는 JCEKS 키 저장소의 자격 증명을 해독하는 데 사용됩니다. credentials -store KeyStoreCredentialStore 구현 속성은 외부 자격 증명 저장소를 구성하는 데 사용됩니다.

    /subsystem=elytron/credential-store=<BCFKS_credential_store>:add(relative-to=jboss.server.config.dir,credential-reference={clear-text=<key_and_keystore_password>},implementation-properties={keyAlias=<key_alias>,external=true,externalPath=<path_to_credential_store>,keyStoreType=BCFKS},create=true,location=<path_to_keystore>,modifiable=true)
  3. 생성되고 나면 자격 증명 저장소를 사용하여 별칭을 정상적으로 저장할 수 있습니다.

    /subsystem=elytron/credential-store=<BCFKS_credential_store>:add-alias(alias="<alias>", secret-value="<sensitive_string>")
  4. 자격 증명 저장소에서 를 읽고 별칭이 추가되었는지 확인합니다.

    /subsystem=elytron/credential-store=<BCFKS_credential_store>:read-aliases()

4.1.12. 자격 증명 저장소 사용자 지정 구현 사용

자격 증명 저장소의 사용자 지정 구현을 사용합니다.

절차

  1. SPI(Service Provider Interface) CredentialStoreSpi 추상 클래스를 확장하는 클래스를 생성합니다.
  2. Java 보안 프로바이더 를 구현하는 클래스를 만듭니다. 프로바이더는 서비스로 사용자 지정 자격 증명 저장소 클래스를 추가해야 합니다.
  3. 자격 증명 저장소 및 프로바이더 클래스를 포함하는 모듈을 생성하고 org.wildfly.security.elytron 에 종속성을 사용하여 JBoss EAP에 추가합니다. 예를 들면 다음과 같습니다.

    module add --name=org.jboss.customcredstore --resources=/path/to/customcredstoreprovider.jar --dependencies=org.wildfly.security.elytron --slot=main
  4. 공급자의 공급자 로더를 생성합니다. 예를 들면 다음과 같습니다.

    /subsystem=elytron/provider-loader=myCustomLoader:add(class-names=[org.wildfly.security.mycustomcredstore.CustomElytronProvider],module=org.jboss.customcredstore)
  5. 사용자 지정 구현을 사용하여 자격 증명 저장소를 만듭니다.

    참고

    올바른 공급업체유형 값을 지정해야 합니다. type 값은 사용자 지정 자격 증명 저장소 클래스를 서비스로 추가하는 공급자 클래스에서 사용되는 값입니다.

    예를 들면 다음과 같습니다.

    /subsystem=elytron/credential-store=my_store:add(providers=myCustomLoader,type=CustomKeyStorePasswordStore,location="cred_stores/my_store.jceks",relative-to=jboss.server.data.dir,credential-reference={clear-text=supersecretstorepassword},create=true)

    또는 여러 공급자를 생성한 경우 다른 공급자 로더와 함께 다른 공급자 로더를 사용하여 추가 공급자를 지정할 수 있습니다. 이를 통해 새로운 유형의 자격 증명에 대한 기타 추가 구현을 보유할 수 있습니다. 이러한 지정된 다른 공급자는 사용자 지정 자격 증명 저장소의 초기화 메서드에서 Provider[] 인수로 자동으로 액세스할 수 있습니다. 예를 들면 다음과 같습니다.

    /subsystem=elytron/credential-store=my_store:add(providers=myCustomLoader,other-providers=myCustomLoader2,type=CustomKeyStorePasswordStore,location="cred_stores/my_store.jceks",relative-to=jboss.server.data.dir,credential-reference={clear-text=supersecretstorepassword},create=true)

4.1.13. 외부 소스에서 인증 정보 저장소의 암호를 가져옵니다.

자격 증명 저장소의 암호를 일반 텍스트 형식으로 제공하는 대신 의사 자격 증명 저장소를 사용하여 암호를 제공하도록 선택할 수 있습니다.

암호를 제공하기 위한 다음과 같은 옵션이 있습니다.

EXT

java.lang.Runtime#exec(java.lang.String) 를 사용하는 외부 명령. 공백으로 구분된 문자열 목록을 사용하여 명령에 매개변수를 제공할 수 있습니다. 외부 명령은 운영 체제에서 실행 가능한 파일(예: 쉘 스크립트 또는 실행 가능한 바이너리 파일)을 나타냅니다. Elytron는 실행하는 명령의 표준 출력에서 암호를 읽습니다.

예제

credential-reference={clear-text="{EXT}/usr/bin/getThePasswordScript.sh par1 par2", type="COMMAND"}

CMD

java.lang.ProcessBuilder 를 사용하는 외부 명령. 쉼표로 구분된 문자열 목록을 사용하여 명령에 매개변수를 제공할 수 있습니다. 외부 명령은 운영 체제에서 실행 가능한 파일(예: 쉘 스크립트 또는 실행 가능한 바이너리 파일)을 나타냅니다. Elytron는 실행하는 명령의 표준 출력에서 암호를 읽습니다.

예제

credential-reference={clear-text="{CMD}/usr/bin/getThePasswordScript.sh par1,par2", type="COMMAND"}

MASK

PBE 또는 암호 기반 암호화를 사용하여 마스킹된 암호입니다. SALTITERATION 값을 포함하는 다음 형식이어야 합니다.

credential-reference={clear-text="MASK-MASKED_VALUE;SALT;ITERATION"}

예제

credential-reference={clear-text="MASK-NqMznhSbL3lwRpDmyuqLBW==;12345678;123"}

중요

EXT,CMDMASK 는 외부 암호를 제공하는 레거시 보안 자격 증명 모음 스타일과 이전 버전과의 호환성을 제공합니다. MASK 의 경우 SALTITERATION 값이 포함된 위의 형식을 사용해야 합니다.

다른 자격 증명 저장소에 있는 암호를 새 자격 증명 저장소의 암호로 사용할 수도 있습니다.

다른 자격 증명 저장소에서 암호를 사용하여 생성된 인증 정보 저장소의 예

/subsystem=elytron/credential-store=exampleCS:add(location="cred_stores/exampleCS.jceks", relative-to=jboss.server.data.dir, create=true, credential-reference={store=cred-store, alias=pwd})

4.1.14. 보안 리소스 잠금을 해제하기 위해 JBoss EAP에 초기 키 제공

보안을 위해 일부 JBoss EAP 구성 요소는 KeyStoreCredentialStore의 PasswordCredential에 의해 보호됩니다. 이 KeyStoreCredentialStore는 JBoss EAP 외부에 저장된 시크릿 키로 보호됩니다. 이를 마스터 키라고 합니다. JBoss EAP는 시작 중에 이 마스터 키를 사용하여 KeyStoreCredentialStore를 잠금 해제하여 KeyStoreCredentialStore에 저장된 암호 자격 증명을 가져옵니다.

Elytron에서 PropertiesCredentialStore를 사용하여 마스터 키를 제공할 수 있습니다. 또는 외부 소스에서 마스터 키 또는 암호를 가져올 수 있습니다. 외부 소스에서 암호를 가져오는 방법에 대한 자세한 내용은 외부 소스에서 인증 정보 저장소의 암호 가져오기를 참조하십시오.

4.1.14.1. 독립 실행형 서버의 PropertiesCredentialStore/secret-key-credential-store 생성

관리 CLI를 사용하여 PropertiesCredentialStore를 생성합니다. PropertiesCredentialStore를 생성할 때 JBoss EAP는 기본적으로 시크릿 키를 생성합니다. 생성된 키의 이름은 key 이며 크기는 256비트입니다.

사전 요구 사항

  • JBoss EAP가 실행 중인 사용자 계정에 대한 PropertiesCredentialStore가 포함된 디렉터리에 대한 읽기/쓰기 액세스 권한이 있어야 합니다.

절차

  • 다음 명령을 사용하여 관리 CLI를 사용하여 PropertiesCredentialStore를 생성합니다.

    구문

    /subsystem=elytron/secret-key-credential-store=<name_of_credential_store>:add(path="<path_to_the_credential_store>", relative-to=<path_to_store_file>)

    예제

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:add(path=examplePropertiesCredentialStore.cs, relative-to=jboss.server.config.dir)
    {"outcome" => "success"}

4.1.14.2. Elytron에서 암호화된 표현식 생성

중요한 문자열 및 SecretKeyCredential에서 암호화된 표현식을 만듭니다. 관리 모델의 중요한 문자열 대신 암호화된 표현식을 사용하여 중요한 문자열의 기밀성을 유지 관리합니다.

사전 요구 사항

절차

  1. 다음 관리 CLI 명령을 사용하여 인증 정보 저장소에서 기존 SecretKeyCredential의 별칭을 참조하는 확인자를 만듭니다.

    구문

    /subsystem=elytron/expression=encryption:add(resolvers=[{name=<name_of_the_resolver>, credential-store=<name_of_credential_store>, secret-key=<secret_key_alias>}])

    예제

    /subsystem=elytron/expression=encryption:add(resolvers=[{name=exampleResolver, credential-store=examplePropertiesCredentialStore, secret-key=key}])

    중복 리소스에 대한 오류 메시지가 표시되면 다음과 같이 add 대신 list-add 작업을 사용합니다.

    구문

    /subsystem=elytron/expression=encryption:list-add(name=resolvers, value={name=<name_of_the_resolver>, credential-store=<name_of_credential_store>, secret-key=<secret_key_alias>})

    예제

    /subsystem=elytron/expression=encryption:list-add(name=resolvers,value={name=exampleResolver, credential-store=examplePropertiesCredentialStore, secret-key=key})
    {
        "outcome" => "success",
        "response-headers" => {
            "operation-requires-reload" => true,
            "process-state" => "reload-required"
        }
    }

  2. 다음 관리 CLI 명령을 사용하여 서버를 다시 로드합니다.

    reload
  3. 관리 CLI에서 명령 캐싱을 비활성화합니다.

    중요

    캐싱을 비활성화하지 않으면 관리 CLI 기록 파일에 액세스할 수 있는 모든 사용자에게 시크릿 키가 표시됩니다.

    history --disable
  4. 다음 관리 CLI 명령을 사용하여 암호화된 표현식을 생성합니다.

    구문

    /subsystem=elytron/expression=encryption:create-expression(resolver=<existing_resolver>, clear-text=<sensitive_string_to_protect>)

    예제

    /subsystem=elytron/expression=encryption:create-expression(resolver=exampleResolver, clear-text=TestPassword)
    {
        "outcome" => "success",
        "result" => {"expression" => "${ENC::exampleResolver:RUxZAUMQgtpG7oFlHR2j1Gkn3GKIHff+HR8GcMX1QXHvx2uGurI=}"}
    }

    ${ENC::exampleResolver:RUxZAU OSPpG7oFlHR2j1Gkn3GKIHIff+HR8GcMX1QX1QX2uGurI=} 은 관리 모델의 TestPassword 대신 사용하는 암호화된 표현식입니다.

    다른 위치에서 동일한 일반 텍스트를 사용하는 경우 해당 위치의 일반 텍스트 대신 암호화된 표현식을 사용하기 전에 매번 이 명령을 반복합니다. 동일한 일반 텍스트에 대해 동일한 명령을 반복하면 Elytron가 각 호출에 대해 고유한 초기화 벡터를 사용하므로 동일한 키에 대해 다른 결과가 나타납니다.

    다른 암호화된 식을 사용하면 문자열에 하나의 암호화된 표현식이 손상되면 다른 암호화된 식에도 동일한 문자열이 포함되어 있는지 확인할 수 없습니다.

  5. 다음 관리 CLI 명령을 사용하여 명령 캐싱을 다시 활성화합니다.

    history --enable

4.1.14.3. 암호화된 표현식을 사용하여 KeyStoreCredentialStore/credential-store 보안

암호화된 표현식을 사용하여 KeyStoreCredentialStore를 보호할 수 있습니다.

사전 요구 사항

절차

  • 일반 텍스트로 암호화된 표현식을 사용하는 KeyStoreCredential Store를 생성합니다.

    구문

    /subsystem=elytron/credential-store=<name_of_credential_store>:add(path=<path_to_the_credential_store>, create=true, modifiable=true, credential-reference={clear-text=<encrypted_expression>})

    예제

    /subsystem=elytron/credential-store=secureKeyStoreCredentialStore:add(path="secureKeyStoreCredentialStore.jceks", relative-to=jboss.server.data.dir, create=true, modifiable=true, credential-reference={clear-text=${ENC::exampleResolver:RUxZAUMQgtpG7oFlHR2j1Gkn3GKIHff+HR8GcMX1QXHvx2uGurI=}})
    {"outcome" => "success"}

암호화된 표현식을 사용하여 KeyStoreCredentialStore를 보안한 후 KeyStoreCredentialStore에 SecretKeyCredential 을 생성하고 시크릿 키를 사용하여 다른 암호화된 표현식을 생성할 수 있습니다. 그런 다음 관리 모델의 중요한 문자열 대신 이 새로운 암호화된 표현식을 서버 구성 파일인 사용할 수 있습니다. 보안을 위해 전체 인증 정보 저장소 체인을 생성할 수 있습니다. 이러한 체인은 문자열이 다음과 같이 보호되므로 민감한 문자열을 추측하기가 더 어렵습니다.

  • 첫 번째 암호화된 표현식은 KeyStoreCredentialStore를 보호합니다.
  • 또 다른 암호화된 표현식은 민감한 문자열을 보호합니다.
  • 민감한 문자열을 디코딩하려면 암호화된 두 식을 모두 해독해야 합니다.

암호화된 표현식의 체인이 길어짐에 따라 민감한 문자열을 해독하기가 더 어려워집니다.

4.1.15. 암호 자격 증명 모음을 자격 증명 저장소로 변환

WildFly Elytron 툴을 사용하여 암호 자격 증명 저장소로 암호 자격 증명 모음을 변환할 수 있습니다. 암호 자격 증명 모음을 자격 증명 저장소로 변환하려면 자격 증명 모음을 초기화할 때 사용되는 자격 증명 모음의 값이 필요합니다.

참고

암호 자격 증명 모음을 변환할 때 새 자격 증명 저장소의 별칭은 동일한 암호 자격 증명 블록 및 속성 이름에 따라 다음과 같은 형식으로 지정됩니다. VAULT_BLOCK::ATTRIBUTE_NAME.

4.1.15.1. WildFly Elytron 툴을 사용하여 단일 암호 자격 증명 모음을 자격 증명 저장소로 변환

WildFly Elytron 툴을 사용하여 단일 암호 자격 증명 모음을 자격 증명 저장소로 변환합니다.

절차

  • 다음 명령을 사용하여 암호 자격 증명 모음을 자격 증명 저장소로 변환합니다.

    $ EAP_HOME/bin/elytron-tool.sh vault --keystore "<path_to_vault_file>" --keystore-password <vault_password> --enc-dir "<path_to_vault_directory>" --salt <salt> --iteration <iteration_count> --alias <vault_alias>

    예를 들어 --location 인수를 사용하여 새 인증 정보 저장소의 파일 이름 및 위치를 지정할 수도 있습니다.

    $ EAP_HOME/bin/elytron-tool.sh vault --keystore ../vaults/vault.keystore --keystore-password vault22 --enc-dir ../vaults/ --salt 1234abcd --iteration 120 --alias my_vault --location ../cred_stores/my_vault_converted.cred_store
참고

summary 인수를 사용하여 변환에 사용되는 관리 CLI 명령의 요약을 출력할 수도 있습니다. 일반 텍스트 암호를 사용하는 경우에도 요약 출력에 마스킹됩니다. 기본 Salt반복 값은 명령에 지정되지 않는 한 사용됩니다.

4.1.15.2. WildFly Elytron 툴을 사용하여 암호 자격 증명 저장소로 대규모 변환

여러 암호 자격 증명 모음을 자격 증명 저장소로 대량 변환

절차

  1. 변환하려는 자격 증명 모음의 세부 정보를 다음 형식으로 설명 파일에 넣습니다.

    keystore:<path_to_vault_file>
    keystore-password:<vault_password>
    enc-dir:<path_to_vault_directory>
    salt:<salt> 1
    iteration:<iteration_count>
    location:<path_to_converted_cred_store> 2
    alias:<vault_alias>
    properties:<parameter1>=<value1>;<parameter2>=<value2>; 3
    1
    자격 증명 모음에 일반 텍스트 암호를 제공하는 경우 salt 및 반복을 생략할 수 있습니다.
    2
    변환된 자격 증명 저장소의 위치 및 파일 이름을 지정합니다.
    3
    선택 사항: 세미콜론(;)으로 구분된 선택적 매개 변수 목록을 지정합니다. 사용 가능한 매개 변수 목록은 EAP_HOME/bin/elytron-tool.sh vault --help 를 참조하십시오.

    예를 들면 다음과 같습니다.

    keystore:/vaults/vault1/vault1.keystore
    keystore-password:vault11
    enc-dir:/vaults/vault1/
    salt:1234abcd
    iteration:120
    location:/cred_stores/vault1_converted.cred_store
    alias:my_vault
    
    keystore:/vaults/vault2/vault2.keystore
    keystore-password:vault22
    enc-dir:/vaults/vault2/
    salt:abcd1234
    iteration:130
    location:/cred_stores/vault2_converted.cred_store
    alias:my_vault2
  2. 이전 단계의 설명 파일과 함께 대규모 변환 명령을 실행합니다.

    $ EAP_HOME/bin/elytron-tool.sh vault --bulk-convert vaultdescriptions.txt

자세한 내용은 사용 가능한 옵션의 자세한 목록을 보려면 EAP_HOME/bin/elytron-tool.sh vault --help 명령을 사용하십시오.

4.1.16. Elytron 클라이언트와 자격 증명 저장소를 사용하는 예

Jakarta Enterprise Beans 등의 JBoss EAP에 연결하는 클라이언트는 Elytron Client를 사용하여 인증할 수 있습니다. 실행 중인 JBoss EAP 서버에 액세스할 수 없는 사용자는 WildFly Elytron 툴을 사용하여 자격 증명 저장소를 생성 및 수정할 수 있으며 클라이언트는 Elytron Client를 사용하여 인증 정보 저장소 내에서 중요한 문자열에 액세스할 수 있습니다.

다음 예제에서는 Elytron 클라이언트 구성 파일에서 자격 증명 저장소를 사용하는 방법을 보여줍니다.

자격 증명 저장소가 있는 custom-config.xml

<configuration>
  <authentication-client xmlns="urn:elytron:client:1.2">
    ...
    <credential-stores>
      <credential-store name="my_store"> 1
        <protection-parameter-credentials>
          <credential-store-reference clear-text="pass123"/> 2
        </protection-parameter-credentials>
        <attributes>
          <attribute name="location" value="/path/to/my_store.jceks"/> 3
        </attributes>
      </credential-store>
    </credential-stores>
    ...
    <authentication-configurations>
      <configuration name="my_user">
        <set-host name="localhost"/>
        <set-user-name name="my_user"/>
        <set-mechanism-realm name="ManagementRealm"/>
        <use-provider-sasl-factory/>
        <credentials>
          <credential-store-reference store="my_store" alias="my_user"/> 4
        </credentials>
      </configuration>
    </authentication-configurations>
    ...
  </authentication-client>
</configuration>

1
Elytron 클라이언트 구성 파일 내에서 사용할 자격 증명 저장소의 이름입니다.
2
자격 증명 저장소의 암호입니다.
3
자격 증명 저장소 파일의 경로입니다.
4
자격 증명 저장소에 저장된 중요한 문자열에 대한 자격 증명 참조입니다.

4.2. 암호 자격 증명 모음

JBoss EAP 및 관련 애플리케이션을 구성하려면 사용자 이름 및 암호와 같이 잠재적으로 중요한 정보가 필요합니다. 구성 파일에 암호를 일반 텍스트로 저장하는 대신 암호 자격 증명 모음 기능을 사용하여 암호 정보를 마스킹하고 암호화된 키 저장소에 저장할 수 있습니다. 암호가 저장되면 관리 CLI 명령이나 JBoss EAP에 배포된 애플리케이션에 참조를 포함할 수 있습니다.

암호 자격 증명 모음은 Java 키 저장소를 스토리지 메커니즘으로 사용합니다. 암호 자격 증명 모음은 스토리지와 키 스토리지의 두 부분으로 구성됩니다. Java 키 저장소는 중요한 문자열을 Vault 스토리지에서 암호화하거나 해독하는 데 사용되는 키를 저장하는 데 사용됩니다.

중요

이 단계에서는 JRE(Java Runtime Environment)에서 제공하는 keytool 유틸리티를 사용합니다. Red Hat Enterprise Linux에서 /usr/bin/keytool 인 파일의 경로를 찾습니다.

JCEKS 키 저장소 구현은 Java 벤더마다 다르므로 JDK와 동일한 벤더의 keytool 유틸리티를 사용하여 키 저장소를 생성해야 합니다. 다른 벤더의 JDK에서 실행되는 JBoss EAP 7 인스턴스에서 한 벤더의 JDK에서 키 도구로 생성한 키 저장소를 사용하면 예외가 발생합니다 . java.io.IOException: com.sun.crypto.provider.SealedObjectForKeyProtector

4.2.1. 암호 자격 증명 모음 설정

다음 단계에 따라 Password Vault를 설정하고 사용합니다.

  1. 키 저장소 및 기타 암호화된 정보를 저장할 디렉터리를 만듭니다.

    이 절차의 나머지 부분에서는 디렉터리가 EAP_HOME/vault/ 라고 가정합니다. 이 디렉터리에는 중요한 정보가 포함되어 있으므로 제한된 사용자만 액세스할 수 있어야 합니다. 최소한 JBoss EAP가 실행 중인 사용자 계정에는 읽기-쓰기 액세스 권한이 필요합니다.

  2. keytool 유틸리티와 함께 사용할 매개 변수를 결정합니다.

    다음 매개변수의 값을 결정합니다.

    alias
    별칭은 키 저장소에 저장된 자격 증명 모음 또는 기타 데이터의 고유 식별자입니다. 별칭은 대소문자를 구분하지 않습니다.
    storetype
    storetype은 키 저장소 유형을 지정합니다. 값 jceks가 권장됩니다.
    keyalg
    암호화에 사용할 알고리즘입니다. JRE 및 운영 체제에 대한 설명서를 사용하여 사용할 수 있는 다른 선택 사항을 확인합니다.
    키 크기
    암호화 키의 크기는 무차별 강제를 통해 암호 해독하기 얼마나 어려운지에 영향을 미칩니다. 적절한 값에 대한 자세한 내용은 keytool 유틸리티와 함께 배포된 문서를 참조하십시오.
    저장소
    storepass 값은 키를 읽을 수 있도록 키 저장소에 인증하는 데 사용되는 암호입니다. 암호는 최소 6자 이상이어야 하며 키 저장소에 액세스할 때 제공해야 합니다. 이 매개변수를 생략하면 keytool 유틸리티에서 명령을 실행한 후 입력하라는 메시지를 표시합니다.
    키 경로
    keypass 값은 특정 키에 액세스하는 데 사용되는 암호이며 storepass 매개 변수의 값과 일치해야 합니다.
    유효 기간
    유효 기간은 키가 유효한 기간(일)입니다.
    키 저장소

    키 저장소의 값은 키 저장소의 값을 저장할 파일 경로 및 파일 이름입니다. 키 저장소 파일은 데이터를 처음 추가할 때 생성됩니다. Red Hat Enterprise Linux 및 유사한 운영 체제에 대해 /(전달 슬래시) 및 Windows Server의 \(backslash)가 올바른 파일 경로 구분 기호가 사용되었는지 확인합니다.

    keytool 유틸리티에는 다른 많은 옵션이 있습니다. 자세한 내용은 JRE 또는 운영 체제 설명서를 참조하십시오.

  3. keytool 명령을 실행하여 keypass 및 storepass 에 동일한 값이 포함되어 있는지 확인합니다.

    $ keytool -genseckey -alias vault -storetype jceks -keyalg AES -keysize 128 -storepass vault22 -keypass vault22 -keystore EAP_HOME/vault/vault.keystore

    그러면 EAP_HOME/vault/vault.keystore 파일에 생성된 키 저장소가 생성됩니다. JBoss EAP의 암호와 같은 암호화된 문자열을 저장하는 데 사용할 별칭 자격 증명 모음과 함께 단일 키를 저장합니다.

4.2.2. 암호 자격 증명 모음 초기화

암호 자격 증명 모음은 대화형으로 초기화할 수 있습니다. 여기서 각 매개 변수의 값을 입력하라는 메시지가 표시되거나 모든 매개 변수 값이 명령줄에 제공되는 비대화식으로 초기화할 수 있습니다. 각 메서드는 동일한 결과를 제공하므로 둘 중 하나를 사용할 수 있습니다.

다음 매개변수가 필요합니다.

키 저장소 URL (KEYSTORE_URL)
키 저장소 파일의 파일 시스템 경로 또는 URI입니다. 이 예제에서는 EAP_HOME/vault/vault.keystore 를 사용합니다.
키 저장소 암호 (KEYSTORE_PASSWORD)
키 저장소에 액세스하는 데 사용되는 암호입니다.
솔트 (SALT)
salt 값은 키 저장소의 내용을 암호화하기 위해 반복 개수와 함께 사용되는 8자 임의 문자열입니다.
키 저장소 별칭 (KEYSTORE_ALIAS)
키 저장소가 알려진 별칭입니다.
반복 개수(ITERATION_COUNT)
암호화 알고리즘이 실행되는 횟수입니다.
암호화된 파일을 저장할 디렉토리 (ENC_FILE_DIR)
암호화된 파일을 저장할 경로입니다. 일반적으로 암호 자격 증명 모음을 포함하는 디렉터리입니다. 암호화된 모든 정보를 키 저장소와 같은 위치에 저장하는 것이 편리하지만 필수 사항은 아닙니다. 이 디렉터리는 제한된 사용자만 액세스할 수 있어야 합니다. 최소한 JBoss EAP 7이 실행 중인 사용자 계정에는 읽기-쓰기 액세스 권한이 필요합니다. 키 저장소는 암호 자격 증명 모음을 설정할 때 생성한 디렉터리에 있어야 합니다. 디렉터리 이름에 후행 역슬래시 또는 슬래시가 필요합니다. Red Hat Enterprise Linux 및 유사한 운영 체제에 대해 /(전달 슬래시) 및 Windows Server의 \(backslash)가 올바른 파일 경로 구분 기호가 사용되었는지 확인합니다.
Vault 블록(VAULT_BLOCK)
암호 자격 증명 모음에서 이 블록에 제공되는 이름입니다.
특성(ATTRIBUTE)
저장할 속성에 제공되는 이름입니다.
보안 속성(SEC-ATTR)
암호 자격 증명 모음에 저장되는 암호입니다.

password vault 명령을 비대화식으로 실행하려면 관련 정보에 대한 매개 변수를 사용하여 EAP_HOME/bin/ 에 있는 자격 증명 모음 스크립트를 호출할 수 있습니다.

$ vault.sh --keystore KEYSTORE_URL --keystore-password KEYSTORE_PASSWORD --alias KEYSTORE_ALIAS --vault-block VAULT_BLOCK --attribute ATTRIBUTE --sec-attr SEC-ATTR --enc-dir ENC_FILE_DIR --iteration ITERATION_COUNT --salt SALT

예제: 암호 Vault 초기화

$ vault.sh --keystore EAP_HOME/vault/vault.keystore --keystore-password vault22 --alias vault --vault-block vb --attribute password --sec-attr 0penS3sam3 --enc-dir EAP_HOME/vault/ --iteration 120 --salt 1234abcd

예제: 출력 결과

=========================================================================

  JBoss Vault

  JBOSS_HOME: EAP_HOME

  JAVA: java

=========================================================================

Nov 09, 2015 9:02:47 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX00361: Default Security Vault Implementation Initialized and Ready
WFLYSEC0047: Secured attribute value has been stored in Vault.
Please make note of the following:
********************************************
Vault Block:vb
Attribute Name:password
Configuration should be done as follows:
VAULT::vb::password::1
********************************************
WFLYSEC0048: Vault Configuration in WildFly configuration file:
********************************************

</extensions>
<vault>
  <vault-option name="KEYSTORE_URL" value="EAP_HOME/vault/vault.keystore"/>
  <vault-option name="KEYSTORE_PASSWORD" value="MASK-5dOaAVafCSd"/>
  <vault-option name="KEYSTORE_ALIAS" value="vault"/>
  <vault-option name="SALT" value="1234abcd"/>
  <vault-option name="ITERATION_COUNT" value="120"/>
  <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/>
</vault><management> ...
********************************************

password vault 명령을 대화식으로 실행하려면 다음 단계가 필요합니다.

  1. password vault 명령을 대화식으로 시작합니다.

    Red Hat Enterprise Linux에서 EAP_HOME/bin/vault.sh 를 실행하고 유사한 운영 체제 또는 Windows Server의 EAP_HOME\bin\vault.bat 를 실행합니다. 0 (영)을 입력하여 새 대화형 세션을 시작합니다.

  2. 프롬프트 매개 변수를 완료합니다.

    프롬프트에 따라 필수 매개 변수를 입력합니다.

  3. 마스킹된 암호 정보를 기록합니다.

    마스킹된 암호, salt 및 반복 수는 표준 출력에 출력됩니다. 안전한 위치에서 해당 항목을 메모해둡니다. Password Vault에 항목을 추가해야 합니다. 키 저장소 파일에 대한 액세스 및 이러한 값을 사용하면 공격자가 암호 Vault의 중요한 정보에 대한 액세스 권한을 얻을 수 있습니다.

  4. 대화식 콘솔 종료

    2 (two)를 입력하여 대화형 콘솔을 종료합니다.

예제: 입력 및 출력

Please enter a Digit::   0: Start Interactive Session  1: Remove Interactive Session  2: Exit
0
Starting an interactive session
Enter directory to store encrypted files:EAP_HOME/vault/
Enter Keystore URL:EAP_HOME/vault/vault.keystore
Enter Keystore password: vault22
Enter Keystore password again: vault22
Values match
Enter 8 character salt:1234abcd
Enter iteration count as a number (Eg: 44):120
Enter Keystore Alias:vault
Initializing Vault
Nov 09, 2015 9:24:36 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX000361: Default Security Vault Implementation Initialized and Ready
Vault Configuration in AS7 config file:
********************************************
...
</extensions>
<vault>
  <vault-option name="KEYSTORE_URL" value="EAP_HOME/vault/vault.keystore"/>
  <vault-option name="KEYSTORE_PASSWORD" value="MASK-5dOaAVafCSd"/>
  <vault-option name="KEYSTORE_ALIAS" value="vault"/>
  <vault-option name="SALT" value="1234abcd"/>
  <vault-option name="ITERATION_COUNT" value="120"/>
  <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/>
</vault><management> ...
********************************************
Vault is initialized and ready for use
Handshake with Vault complete

+ 구성 파일과 배포에 사용하기 위해 키 저장소 암호가 마스킹되었습니다. 또한 자격 증명 모음이 초기화되어 사용할 준비가 되었습니다.

4.2.3. 암호 자격 증명 모음 사용

암호와 기타 중요한 특성을 구성 파일에서 마스킹하고 사용하기 전에 JBoss EAP 7은 암호를 저장하고 암호 해독하는 암호 자격 증명 모음을 인식해야 합니다.

다음 명령은 암호 자격 증명 모음을 사용하도록 JBoss EAP 7을 구성하는 데 사용할 수 있습니다.

/core-service=vault:add(vault-options=[("KEYSTORE_URL" => PATH_TO_KEYSTORE),("KEYSTORE_PASSWORD" => MASKED_PASSWORD),("KEYSTORE_ALIAS" => ALIAS),("SALT" => SALT),("ITERATION_COUNT" => ITERATION_COUNT),("ENC_FILE_DIR" => ENC_FILE_DIR)])

/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "EAP_HOME/vault/vault.keystore"),("KEYSTORE_PASSWORD" => "MASK-5dOaAVafCSd"),("KEYSTORE_ALIAS" => "vault"),("SALT" => "1234abcd"),("ITERATION_COUNT" => "120"),("ENC_FILE_DIR" => "EAP_HOME/vault/")])
참고

Microsoft Windows Server를 사용 중인 경우 파일 경로에서 두 개의 백슬래시(\\)를 대신 사용합니다. 예를 들면 C:\\data\\vault\\vault.keystore 입니다. 이는 단일 백슬래시 문자(\)가 문자 이스케이프에 사용되기 때문입니다.

4.2.4. 암호 자격 증명 모음에 중요한 문자열 저장

일반 텍스트 구성 파일에 암호 및 기타 중요한 문자열을 포함하는 것은 보안 위험이 있습니다. 보안 강화를 위해 이러한 문자열을 Password Vault에 저장하여 구성 파일, 관리 CLI 명령 및 애플리케이션에서 마스킹된 양식으로 참조할 수 있습니다.

중요한 문자열은 Password Vault에 대화식으로 저장할 수 있습니다. 여기서 도구는 각 매개 변수의 값을 입력하라는 메시지를 표시하거나 명령줄에 모든 매개 변수의 값이 제공되는 비대화형으로 저장할 수 있습니다. 각 메서드는 동일한 결과를 제공하므로 둘 중 하나를 사용할 수 있습니다. 두 메서드는 모두 vault 스크립트를 사용하여 호출됩니다.

password vault 명령을 비대화식으로 실행하려면 자격 증명 모음 스크립트( EAP_HOME/bin/에 있음)를 관련 정보에 대한 매개 변수를 사용하여 호출할 수 있습니다.

$ vault.sh --keystore KEYSTORE_URL --keystore-password KEYSTORE_PASSWORD --alias KEYSTORE_ALIAS --vault-block VAULT_BLOCK --attribute ATTRIBUTE --sec-attr SEC-ATTR --enc-dir ENC_FILE_DIR --iteration ITERATION_COUNT --salt SALT
참고

키 저장소 암호는 마스킹된 형식이 아닌 일반 텍스트 형식으로 지정해야 합니다.

$ vault.sh --keystore EAP_HOME/vault/vault.keystore --keystore-password vault22 --alias vault --vault-block vb --attribute password --sec-attr 0penS3sam3 --enc-dir EAP_HOME/vault/ --iteration 120 --salt 1234abcd

예제: 출력 결과

=========================================================================

  JBoss Vault

  JBOSS_HOME: EAP_HOME

  JAVA: java

=========================================================================

Nov 09, 2015 9:24:36 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX00361: Default Security Vault Implementation Initialized and Ready
WFLYSEC0047: Secured attribute value has been stored in Vault.
Please make note of the following:
********************************************
Vault Block:vb
Attribute Name:password
Configuration should be done as follows:
VAULT::vb::password::1
********************************************
WFLYSEC0048: Vault Configuration in WildFly configuration file:
********************************************
...
</extensions>
<vault>
  <vault-option name="KEYSTORE_URL" value="../vault/vault.keystore"/>
  <vault-option name="KEYSTORE_PASSWORD" value="MASK-5dOaAVafCSd"/>
  <vault-option name="KEYSTORE_ALIAS" value="vault"/>
  <vault-option name="SALT" value="1234abcd"/>
  <vault-option name="ITERATION_COUNT" value="120"/>
  <vault-option name="ENC_FILE_DIR" value="../vault/"/>
</vault><management> ...
********************************************

자격 증명 모음 스크립트를 호출한 후 메시지가 표준 출력에 출력되어 vault 블록, 속성 이름, 마스킹된 문자열 및 구성에서 문자열 사용에 대한 조언을 표시합니다. 이 정보를 안전한 위치에서 기록해 둡니다. 샘플 출력의 추출은 다음과 같습니다.

Vault Block:vb
Attribute Name:password
Configuration should be done as follows:
VAULT::vb::password::1

password vault 명령을 대화식으로 실행하려면 다음 단계가 필요합니다.

  1. 대화식으로 Password Vault 명령을 시작합니다.

    운영 체제의 명령줄 인터페이스를 시작하고 EAP_HOME/bin/vault.sh (Red Hat Enterprise Linux 및 유사한 운영 체제) 또는 EAP_HOME\bin\vault.bat (Microsoft Windows Server)를 실행합니다. 0 (영)을 입력하여 새 대화형 세션을 시작합니다.

  2. 프롬프트 매개 변수를 완료합니다.

    프롬프트에 따라 필수 매개 변수를 입력합니다. 이러한 값은 Password Vault가 생성될 때 제공되는 값과 일치해야 합니다.

    참고

    키 저장소 암호는 마스킹된 형식이 아닌 일반 텍스트 형식으로 지정해야 합니다.

  3. 중요한 문자열에 대한 프롬프트 매개 변수를 완료합니다.

    0 (zero)을 입력하여 중요한 문자열을 저장합니다. 프롬프트에 따라 필수 매개 변수를 입력합니다.

  4. 마스킹된 문자열에 대한 정보를 기록해 둡니다.

    메시지는 자격 증명 모음 블록, 특성 이름, 마스킹된 문자열 및 구성에서 문자열을 사용하는 방법에 대한 지침을 표시하는 표준 출력에 출력됩니다. 이 정보를 안전한 위치에서 기록해 둡니다. 샘플 출력의 추출은 다음과 같습니다.

    Vault Block:ds_Example1
    Attribute Name:password
    Configuration should be done as follows:
    VAULT::ds_Example1::password::1
  5. 대화형 콘솔을 종료합니다.

    2 (two)를 입력하여 대화형 콘솔을 종료합니다.

예제: 입력 및 출력

 =========================================================================
  JBoss Vault
  JBOSS_HOME: EAP_HOME
  JAVA: java
 =========================================================================
 **********************************
 ****  JBoss Vault  ***************
 **********************************
Please enter a Digit::   0: Start Interactive Session  1: Remove Interactive Session  2: Exit
0
Starting an interactive session
Enter directory to store encrypted files:EAP_HOME/vault/
Enter Keystore URL:EAP_HOME/vault/vault.keystore
Enter Keystore password:
Enter Keystore password again:
Values match
Enter 8 character salt:1234abcd
Enter iteration count as a number (Eg: 44):120
Enter Keystore Alias:vault
Initializing Vault
Nov 09, 2015 9:24:36 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX000361: Default Security Vault Implementation Initialized and Ready
Vault Configuration in AS7 config file:
 ********************************************
...
</extensions>
<vault>
  <vault-option name="KEYSTORE_URL" value="EAP_HOME/vault/vault.keystore"/>
  <vault-option name="KEYSTORE_PASSWORD" value="MASK-5dOaAVafCSd"/>
  <vault-option name="KEYSTORE_ALIAS" value="vault"/>
  <vault-option name="SALT" value="1234abcd"/>
  <vault-option name="ITERATION_COUNT" value="120"/>
  <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/>
</vault><management> ...
 ********************************************
Vault is initialized and ready for use
Handshake with Vault complete
Please enter a Digit::  0: Store a secured attribute  1: Check whether a secured attribute exists  2: Remove secured attribute  3: Exit
0
Task: Store a secured attribute
Please enter secured attribute value (such as password):
Please enter secured attribute value (such as password) again:
Values match
Enter Vault Block:ds_Example1
Enter Attribute Name:password
Secured attribute value has been stored in vault.
Please make note of the following:
 ********************************************
Vault Block:ds_Example1
Attribute Name:password
Configuration should be done as follows:
VAULT::ds_Example1::password::1
 ********************************************
Please enter a Digit::  0: Store a secured attribute  1: Check whether a secured attribute exists  2: Remove secured attribute  3: Exit

4.2.5. 설정에서 암호화된 중요한 문자열 사용

암호화된 모든 중요한 문자열은 마스킹된 형식으로 구성 파일 또는 관리 CLI 명령에서 사용할 수 있으며 표현식을 제공할 수 있습니다.

특정 하위 시스템 내에서 식이 허용되는지 확인하려면 해당 하위 시스템에 대해 다음 관리 CLI 명령을 실행합니다.

/subsystem=SUBSYSTEM:read-resource-description(recursive=true)

이 명령 실행 출력에서 expression -allowed 매개 변수의 값을 찾습니다. 이 값이 참 이면 이 하위 시스템의 구성 내에서 표현식을 사용할 수 있습니다.

다음 구문을 사용하여 일반 텍스트 문자열을 마스크된 형식으로 바꿉니다.

${VAULT::VAULT_BLOCK::ATTRIBUTE_NAME::MASKED_STRING}

예제: 마스크된 양식에서 암호를 사용한 데이터 소스 정의

...
  <subsystem xmlns="urn:jboss:domain:datasources:5.0">
    <datasources>
      <datasource jndi-name="java:jboss/datasources/ExampleDS" enabled="true" use-java-context="true" pool-name="H2DS">
        <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
        <driver>h2</driver>
        <pool></pool>
        <security>
          <user-name>sa</user-name>
          <password>${VAULT::ds_ExampleDS::password::1}</password>
        </security>
      </datasource>
      <drivers>
         <driver name="h2" module="com.h2database.h2">
            <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
         </driver>
      </drivers>
    </datasources>
  </subsystem>
...

4.2.6. 애플리케이션에서 암호화된 중요한 문자열 사용

암호 자격 증명 모음에 저장된 암호화된 문자열은 애플리케이션의 소스 코드에서 사용할 수 있습니다. 아래 예제는 서블릿의 소스 코드 추출을 통해 일반 텍스트 암호 대신 데이터 소스 정의에서 마스킹된 암호 사용을 설명합니다. 차이점을 확인할 수 있도록 일반 텍스트 버전은 주석으로 처리됩니다.

예제: Vault된 암호를 사용하는 서블릿

@DataSourceDefinition(
        name = "java:jboss/datasources/LoginDS",
        user = "sa",
        password = "VAULT::DS::thePass::1",
        className = "org.h2.jdbcx.JdbcDataSource",
        url = "jdbc:h2:tcp://localhost/mem:test"
)
/*old (plaintext) definition
@DataSourceDefinition(
        name = "java:jboss/datasources/LoginDS",
        user = "sa",
        password = "sa",
        className = "org.h2.jdbcx.JdbcDataSource",
        url = "jdbc:h2:tcp://localhost/mem:test"
)*/

4.2.7. 중요한 문자열이 암호 Vault에 있는지 확인합니다.

Password Vault에 중요한 문자열을 저장하거나 사용하기 전에 먼저 해당 문자열이 이미 저장되었는지 확인하는 것이 유용할 수 있습니다.

이 점검은 사용자가 각 매개 변수의 값을 입력하라는 메시지나 모든 매개 변수의 값이 명령줄에 제공되는 비대화형으로 대화형으로 수행할 수 있습니다. 각 메서드는 동일한 결과를 제공하므로 둘 중 하나를 사용할 수 있습니다. 두 메서드는 모두 vault 스크립트를 사용하여 호출됩니다.

비대화형 방법을 사용하여 모든 매개 변수의 값을 한 번에 제공합니다. 모든 매개 변수에 대한 설명은 Initialize the Password Vault 를 참조하십시오. password vault 명령을 비대화식으로 실행하려면 관련 정보에 대한 매개 변수를 사용하여 EAP_HOME/bin/ 에 있는 자격 증명 모음 스크립트를 호출할 수 있습니다.

$ vault.sh --keystore KEYSTORE_URL --keystore-password KEYSTORE_PASSWORD --alias KEYSTORE_ALIAS --check-sec-attr --vault-block VAULT_BLOCK --attribute ATTRIBUTE --enc-dir ENC_FILE_DIR --iteration ITERATION_COUNT --salt SALT

자리 표시자 값을 실제 값으로 대체합니다. KEYSTORE_URL, KEYSTORE_ PASSWORD 및 KEYSTORE_ ALIAS 매개 변수의 값은 암호 자격 증명 모음이 생성될 때 제공되는 값과 일치해야 합니다.

참고

키 저장소 암호는 마스킹된 형식이 아닌 일반 텍스트 형식으로 지정해야 합니다.

중요한 문자열이 지정된 자격 증명 모음 블록에 저장된 경우 다음 메시지가 표시됩니다.

Password already exists.

값이 지정된 블록에 저장되지 않으면 다음 메시지가 표시됩니다.

Password doesn't exist.

password vault 명령을 대화식으로 실행하려면 다음 단계가 필요합니다.

  1. password vault 명령을 대화식으로 시작합니다.

    EAP_HOME/bin/vault.sh (Red Hat Enterprise Linux 및 유사한 운영 체제) 또는 EAP_HOME\bin\vault.bat(Windows Server)를 실행합니다. 0 (영)을 입력하여 새 대화형 세션을 시작합니다.

  2. 프롬프트 매개 변수를 완료합니다. 프롬프트에 따라 필수 인증 매개 변수를 입력합니다. 이러한 값은 암호 자격 증명 모음이 생성될 때 제공되는 값과 일치해야 합니다.

    참고

    인증 메시지가 표시되면 키 저장소 암호를 일반 텍스트 형식으로 지정해야 하며, 형식은 마스킹되지 않습니다.

    • 1 (한)을 입력하여 보안 특성이 있는지 여부를 선택합니다.
    • 중요한 문자열이 저장되는 vault 블록의 이름을 입력합니다.
    • 확인할 중요한 문자열의 이름을 입력합니다.

중요한 문자열이 지정된 자격 증명 모음 블록에 저장된 경우 다음과 같은 확인 메시지가 출력됩니다.

A value exists for (VAULT_BLOCK, ATTRIBUTE)

중요한 문자열이 지정된 블록에 저장되지 않으면 다음과 같은 메시지가 출력됩니다.

No value has been store for (VAULT_BLOCK, ATTRIBUTE)

예제: 중요한 문자열 확인

 =========================================================================
  JBoss Vault
  JBOSS_HOME: EAP_HOME
  JAVA: java
 =========================================================================
 **********************************
 ****  JBoss Vault  ***************
 **********************************
Please enter a Digit::   0: Start Interactive Session  1: Remove Interactive Session  2: Exit
0
Starting an interactive session
Enter directory to store encrypted files:EAP_HOME/vault
Enter Keystore URL:EAP_HOME/vault/vault.keystore
Enter Keystore password:
Enter Keystore password again:
Values match
Enter 8 character salt:1234abcd
Enter iteration count as a number (Eg: 44):120
Enter Keystore Alias:vault
Initializing Vault
Nov 09, 2015 9:24:36 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX000361: Default Security Vault Implementation Initialized and Ready
Vault Configuration in AS7 config file:
 ********************************************
...
</extensions>
<vault>
  <vault-option name="KEYSTORE_URL" value="EAP_HOME/vault/vault.keystore"/>
  <vault-option name="KEYSTORE_PASSWORD" value="MASK-5dOaAVafCSd"/>
  <vault-option name="KEYSTORE_ALIAS" value="vault"/>
  <vault-option name="SALT" value="1234abcd"/>
  <vault-option name="ITERATION_COUNT" value="120"/>
  <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/>
</vault><management> ...
 ********************************************
Vault is initialized and ready for use
Handshake with Vault complete
Please enter a Digit::  0: Store a secured attribute  1: Check whether a secured attribute exists  2: Remove secured attribute  3: Exit
1
Task: Verify whether a secured attribute exists
Enter Vault Block:vb
Enter Attribute Name:password
A value exists for (vb, password)
Please enter a Digit::  0: Store a secured attribute  1: Check whether a secured attribute exists  2: Remove secured attribute  3: Exit

4.2.8. 암호 자격 증명 모음에서 중요한 문자열 제거

보안상의 이유로 더 이상 필요하지 않은 경우 암호 자격 증명 모음에서 중요한 문자열을 제거하는 것이 좋습니다. 예를 들어 애플리케이션이 해제되는 경우 데이터 소스 정의에 사용되는 중요한 문자열이 동시에 제거되어야 합니다.

중요

전제 조건으로 Password Vault에서 중요한 문자열을 제거하기 전에 JBoss EAP 구성에 사용되는지 확인합니다.

이 작업은 사용자가 각 매개 변수의 값을 입력하라는 메시지가 표시되는 대화식 또는 명령줄에서 모든 매개 변수의 값이 제공되는 비대화형으로 수행할 수 있습니다. 각 메서드는 동일한 결과를 제공하므로 둘 중 하나를 사용할 수 있습니다. 두 메서드는 모두 vault 스크립트를 사용하여 호출됩니다.

비대화형 방법을 사용하여 모든 매개 변수의 값을 한 번에 제공합니다. 모든 매개 변수에 대한 설명은 Initialize the Password Vault 를 참조하십시오. password vault 명령을 비대화식으로 실행하려면 자격 증명 모음 스크립트( EAP_HOME/bin/에 있음)를 관련 정보에 대한 매개 변수를 사용하여 호출할 수 있습니다.

$ vault.sh --keystore KEYSTORE_URL --keystore-password KEYSTORE_PASSWORD --alias KEYSTORE_ALIAS --remove-sec-attr --vault-block VAULT_BLOCK --attribute ATTRIBUTE --enc-dir ENC_FILE_DIR --iteration ITERATION_COUNT --salt SALT

자리 표시자 값을 실제 값으로 대체합니다. KEYSTORE_URL, KEYSTORE_ PASSWORD 및 KEYSTORE_ ALIAS 매개 변수의 값은 암호 Vault가 생성될 때 제공되는 값과 일치해야 합니다.

참고

키 저장소 암호는 마스킹된 형식이 아닌 일반 텍스트 형식으로 지정해야 합니다.

중요한 문자열이 성공적으로 제거되면 다음과 같은 확인 메시지가 표시됩니다.

Secured attribute [VAULT_BLOCK::ATTRIBUTE] has been successfully removed from vault

중요한 문자열이 제거되지 않으면 다음과 같은 메시지가 표시됩니다.

Secured attribute [VAULT_BLOCK::ATTRIBUTE] was not removed from vault, check whether it exist

예제: 출력 결과

$ ./vault.sh --keystore EAP_HOME/vault/vault.keystore --keystore-password vault22 --alias vault --remove-sec-attr --vault-block vb --attribute password --enc-dir EAP_HOME/vault/ --iteration 120 --salt 1234abcd
 =========================================================================
  JBoss Vault
  JBOSS_HOME: EAP_HOME
  JAVA: java
 =========================================================================
Dec 23, 2015 1:54:24 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX000361: Default Security Vault Implementation Initialized and Ready
Secured attribute [vb::password] has been successfully removed from vault

중요한 문자열 제거

password vault 명령을 대화식으로 실행하려면 다음 단계가 필요합니다.

  1. password vault 명령을 대화식으로 시작합니다.

    EAP_HOME/bin/vault.sh (Red Hat Enterprise Linux 및 유사한 운영 체제) 또는 EAP_HOME\bin\vault.bat(Microsoft Windows Server)를 실행합니다. 0 (영)을 입력하여 새 대화형 세션을 시작합니다.

  2. 프롬프트 매개 변수를 완료합니다.

    프롬프트에 따라 필수 인증 매개 변수를 입력합니다. 이러한 값은 암호 자격 증명 모음이 생성될 때 제공되는 값과 일치해야 합니다.

    참고

    인증 메시지가 표시되면 키 저장소 암호를 일반 텍스트 형식으로 지정해야 하며, 형식은 마스킹되지 않습니다.

    • 2 (two)를 입력하여 옵션 Remove secured attributes(보안 속성 제거)를 선택합니다.
    • 중요한 문자열이 저장되는 vault 블록의 이름을 입력합니다.
    • 제거할 중요한 문자열의 이름을 입력합니다.

중요한 문자열이 성공적으로 제거되면 다음과 같은 확인 메시지가 표시됩니다.

Secured attribute [VAULT_BLOCK::ATTRIBUTE] has been successfully removed from vault

중요한 문자열이 제거되지 않으면 다음과 같은 메시지가 표시됩니다.

Secured attribute [VAULT_BLOCK::ATTRIBUTE] was not removed from vault, check whether it exist

예제: 출력 결과

 **********************************
 ****  JBoss Vault  ***************
 **********************************
Please enter a Digit::   0: Start Interactive Session  1: Remove Interactive Session  2: Exit
0
Starting an interactive session
Enter directory to store encrypted files:EAP_HOME/vault/
Enter Keystore URL:EAP_HOME/vault/vault.keystore
Enter Keystore password:
Enter Keystore password again:
Values match
Enter 8 character salt:1234abcd
Enter iteration count as a number (Eg: 44):120
Enter Keystore Alias:vault
Initializing Vault
Dec 23, 2014 1:40:56 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX000361: Default Security Vault Implementation Initialized and Ready
Vault Configuration in configuration file:
 ********************************************
...
</extensions>
<vault>
  <vault-option name="KEYSTORE_URL" value="EAP_HOME/vault/vault.keystore"/>
  <vault-option name="KEYSTORE_PASSWORD" value="MASK-5dOaAVafCSd"/>
  <vault-option name="KEYSTORE_ALIAS" value="vault"/>
  <vault-option name="SALT" value="1234abcd"/>
  <vault-option name="ITERATION_COUNT" value="120"/>
  <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/>
</vault><management> ...
 ********************************************
Vault is initialized and ready for use
Handshake with Vault complete
Please enter a Digit::  0: Store a secured attribute  1: Check whether a secured attribute exists  2: Remove secured attribute  3: Exit
2
Task: Remove secured attribute
Enter Vault Block:vb
Enter Attribute Name:password
Secured attribute [vb::password] has been successfully removed from vault

4.2.9. 암호 Vault 사용자 지정 구현을 사용하도록 Red Hat JBoss Enterprise Application Platform 구성

제공된 암호 자격 증명 모음 구현을 사용하는 것 외에도 사용자 지정 SecurityVault 구현을 사용할 수도 있습니다.

중요

전제 조건으로 암호 자격 증명 모음이 초기화되었는지 확인합니다. 자세한 내용은 Initialize the Password Vault 를 참조하십시오.

암호 자격 증명 모음에 사용자 지정 구현을 사용하려면 다음을 수행합니다.

  1. 인터페이스 SecurityVault 를 구현하는 클래스를 생성합니다.
  2. 이전 단계의 클래스를 포함하는 모듈을 생성하고 인터페이스가 SecurityVaultorg.picketbox 에 대한 종속성을 지정합니다.
  3. 다음 속성으로 vault 요소를 추가하여 JBoss EAP 구성에서 사용자 지정 암호 자격 증명 모음을 활성화합니다.

    • code - SecurityVault 를 구현하는 정규화된 클래스 이름입니다.
    • module - 사용자 지정 클래스가 포함된 모듈의 이름입니다.

선택적으로 vault-options 매개 변수를 사용하여 암호 자격 증명 모음에 대한 사용자 지정 클래스를 초기화할 수 있습니다.

예제: vault-options 매개 변수를 사용하여 사용자 정의 클래스를 초기화합니다.

/core-service=vault:add(code="custom.vault.implementation.CustomSecurityVault", module="custom.vault.module", vault-options=[("KEYSTORE_URL" => PATH_TO_KEYSTORE),("KEYSTORE_PASSWORD" => MASKED_PASSWORD), ("KEYSTORE_ALIAS" => ALIAS),("SALT" => SALT),("ITERATION_COUNT" => ITERATION_COUNT),("ENC_FILE_DIR" => ENC_FILE_DIR)])

4.2.10. 외부 소스에서 키 저장소 암호 얻기

EXT,EXTC,CMD,CMDC 또는 CLASS 메서드는 Java 키 저장소 암호를 가져오기 위해 vault 구성에서 사용할 수 있습니다.

<vault-option name="KEYSTORE_PASSWORD" value="METHOD_TO_OBTAIN_PASSWORD"/>

메서드 설명은 다음과 같이 나열됩니다.

{EXT}…​
정확한 명령을 나타냅니다. 여기서 …​ 는 정확한 명령입니다. 예를 들어 {EXT}/usr/bin/getmypassword --section 1 --query company 는 표준 출력에 암호를 표시하는 /usr/bin/getmypassword 명령을 실행하여 Security Vault의 키 저장소에 대해 password로 사용합니다. 이 예에서 명령은 --section 1 및 -- query company 의 두 가지 옵션을 사용합니다.
{EXTC[:expiration_in_millis]}…​
정확한 명령을 나타냅니다. 여기서 …​ platform 명령을 실행하기 위해 Runtime.exec(String) 메서드에 전달되는 정확한 명령줄입니다. 명령 출력의 첫 번째 줄은 암호로 사용됩니다. EXTC 변형은 expiration_in_millis 밀리초의 암호를 캐시합니다. 기본 캐시 만료는 0 = infinity입니다. 예를 들어 {EXTC:120000}/usr/bin/getmypassword --section 1 --query 회사는 캐시에 /usr/bin/getmypassword 출력이 포함되어 있는지 여부를 확인하고 출력이 포함된 경우 사용합니다. 출력이 포함되어 있지 않으면 명령을 실행하여 캐시하고 사용합니다. 이 예에서 캐시는 2분 후에 만료되며 이는 120000밀리초입니다.
{CMD}…​ or {CMDC[:expiration_in_millis]}…​
일반 명령은 첫 번째 부분이 실제 명령이고 추가 부분이 매개 변수를 나타내는 ( 콤마)로 구분된 문자열입니다. 쉼표는 백슬래시되어 매개 변수의 일부로 유지할 수 있습니다. 예를 들면 {CMD}/usr/bin/getmypassword,--section,1,--query, Company입니다.
{CLASS[@jboss_module_spec]}classname[:ctorargs]
여기서 [:ctorargs] 는 클래스 이름의 : (colon)으로 구분된 선택적 문자열입니다 . The ctorargs 는 쉼표로 구분된 문자열 목록입니다. 예를 들면 {CLASS@org.test.passwd}org.test.passwd.ExternamPassworProvider 입니다. 이 예에서는 org.test.passwd.ExternamPassworProvider 클래스가 org.test.passwd 모듈에서 로드되고 toCharArray() 메서드를 사용하여 암호를 가져옵니다. toCharArray() 를 사용할 수 없는 경우 toString() 메서드가 사용됩니다. org.test.passwd.ExternamPassworProvider 클래스에는 기본 생성자가 있어야 합니다.

5장. Java 보안 관리자

Java 보안 정책을 정의하면 JVM(Java Virtual Machine)의 외부 경계를 관리하도록 Java Security Manager를 구성할 수 있습니다.

5.1. Java 보안 관리자 정보

Java Security Manager는 JVM(Java Virtual Machine) 샌드박스의 외부 경계를 관리하는 클래스로 JVM 내에서 코드를 실행하는 방법을 제어합니다. Java Security Manager를 활성화하면 Java API에서 잠재적으로 안전하지 않은 다양한 작업을 실행하기 전에 보안 관리자에게 승인을 확인합니다. Java Security Manager는 보안 정책을 사용하여 지정된 작업을 허용할지 또는 거부할지 여부를 결정합니다.

5.2. Java 보안 정책 정보

Java 보안 정책은 다양한 코드 클래스에 대해 정의된 권한 집합입니다. Java Security Manager는 애플리케이션에서 요청한 작업을 보안 정책과 비교합니다. 정책에서 조치를 허용하는 경우 Security Manager(보안 관리자는 해당 작업을 수행할 수 있도록 허용합니다. 정책에서 작업을 허용하지 않으면 보안 관리자가 해당 작업을 거부합니다.

중요

이전 버전의 JBoss EAP는 외부 파일(예: EAP_HOME/bin/server.policy )을 사용하여 정책을 정의했습니다. JBoss EAP 7은 security-manager 하위 시스템과 개별 배포에서 XML 파일을 통해 Java 보안 정책을 정의합니다. security-manager 하위 시스템은 모든 배포에 대한 최소 및 최대 권한을 정의하는 반면 XML 파일은 개별 배포에서 요청한 권한을 지정합니다.

5.2.1. 보안 관리자 하위 시스템에서 정책 정의 정보

security-manager 하위 시스템을 사용하면 모든 배포에 대해 공유 또는 공통 권한을 정의할 수 있습니다. 이 작업은 최소 및 최대 권한 세트를 정의하여 수행됩니다. 모든 배포는 최소 권한에 정의된 최소 모든 권한으로 부여됩니다. 배포 프로세스는 최대 권한 집합에 정의된 권한을 초과하는 권한을 요청하면 배포에 실패합니다.

예제: 최소 권한 세트를 업데이트하기 위한 관리 CLI 명령

/subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions, value=[{class="java.util.PropertyPermission", actions="read", name="*"}])

예제: 최대 권한 세트를 업데이트하는 관리 CLI 명령

/subsystem=security-manager/deployment-permissions=default:write-attribute(name=maximum-permissions, value=[{class="java.util.PropertyPermission", actions="read,write", name="*"}, {class="java.io.FilePermission", actions="read,write", name="/-"}])

참고

최대 권한 집합이 정의되지 않은 경우 기본값은 java.security.AllPermission 입니다.

추가 리소스

  • JBoss EAP 구성 가이드에서 security-manager 하위 시스템에 대한 전체 참조를 찾을 수 있습니다.

5.2.2. 배포에서 정책 정의 정보

JBoss EAP 7에서는 배포에 META-INF/permissions.xml 을 추가할 수 있습니다. 이 파일을 사용하면 배포에 필요한 권한을 지정할 수 있습니다.

최소 권한 세트가 security-manager 하위 시스템에 정의되고 META-INF/permissions.xml 이 배포에 추가되면 해당 권한의 통합이 부여됩니다. permissions.xml 에서 요청한 권한이 security-manager 하위 시스템에 정의된 최대 정책을 초과하면 배포에 실패합니다. META-INF/permissions.xmlMETA-INF/jboss-permissions.xml 이 배포에 모두 있는 경우 META-INF/jboss-permissions.xml 에 요청된 권한만 부여됩니다.

사양은 permissions.xml 이 전체 애플리케이션 또는 최상위 배포 모듈을 다루도록 지시합니다. 하위 배포에 대한 특정 권한을 정의하려는 경우 JBoss EAP별 META-INF/jboss-permissions.xml 을 사용할 수 있습니다. 이는 permissions.xml 과 동일한 형식을 따르며 선언된 배포 모듈에만 적용됩니다.

예제: 샘플 permissions.xml

<permissions version="7">
  <permission>
    <class-name>java.util.PropertyPermission</class-name>
    <name>*</name>
    <actions>read</actions>
  </permission>
</permissions>

5.2.3. 모듈에서 정책 정의 정보

module. xml 파일에 <permissions> 요소를 추가하여 모듈 의 권한을 제한할 수 있습니다. <permissions> 요소에는 모듈에 부여할 권한을 정의하는 0개 이상의 <grant> 요소가 포함되어 있습니다. 각 <grant> 요소에는 다음 속성이 포함됩니다.

권한
부여할 권한의 정규화된 클래스 이름입니다.
name
권한 클래스 생성자에 제공할 권한 이름입니다.
동작
일부 권한 유형에 필요한 (선택 사항) 작업 목록입니다.

예: 정의된 정책이 포함된 module.xml

<module xmlns="urn:jboss:module:1.5" name="org.jboss.test.example">
  <permissions>
    <grant permission="java.util.PropertyPermission" name="*" actions="read,write" />
    <grant permission="java.io.FilePermission" name="/etc/-" actions="read" />
  </permissions>
  ...
</module>

<permissions> 요소가 있는 경우 모듈은 나열한 권한으로만 제한됩니다. <permissions> 요소가 없으면 모듈에 대한 제한 사항이 없습니다.

5.3. Java 보안 관리자를 사용하여 JBoss EAP 실행

Java Security Manager를 사용하여 다음 두 가지 방법으로 JBoss EAP를 실행할 수 있습니다. Java 보안 관리자를 실행하는 방법은 다음 두 가지가 있습니다.

  • 시작 구성 스크립트에서 -secmgr 플래그를 사용합니다.
  • 시작 구성 파일 사용.
중요

이전 버전의 JBoss EAP는 -Djava.security.manager Java 시스템 속성과 사용자 지정 보안 관리자를 사용할 수 있습니다. 이 중 어느 것도 JBoss EAP 7에서 지원되지 않습니다. 또한 Java Security Manager 정책은 이제 security-manager 하위 시스템에 정의되어 있으므로 외부 정책 파일과 -Djava.security.policy Java 시스템 속성은 JBoss EAP 7이 지원되지 않습니다.

중요

Java Security Manager를 활성화한 상태에서 JBoss EAP를 시작하기 전에 모든 보안 정책이 security-manager 하위 시스템에 정의되어 있는지 확인해야 합니다.

5.3.1. 시작 구성 스크립트에서 -secmgr 플래그를 사용합니다.

Java Security Manager를 사용하여 JBoss EAP를 실행할 수 있습니다. 이 작업을 수행하려면 시작 중에SECmgr 옵션을 사용합니다.

절차

  • JBoss EAP 인스턴스를 시작할 때 -secmgr 플래그를 포함합니다.

    -secmgr 플래그를 포함하는 방법의 예

    ./standalone.sh -secmgr

5.3.2. 시작 구성 파일 사용

Java Security Manager를 사용하여 JBoss EAP를 실행할 수 있습니다. 이렇게 하려면 시작 구성 파일을 수정해야 합니다.

중요

도메인 또는 독립 실행형 서버는 구성 파일을 편집하기 전에 완전히 중지해야 합니다.

참고

관리형 도메인에서 JBoss EAP를 사용하는 경우 도메인의 각 물리적 호스트 또는 인스턴스에서 다음 절차를 수행해야 합니다.

절차

  • 시작 구성 파일을 사용하여 Java Security Manager를 활성화합니다 . 독립 실행형 인스턴스 또는 관리형 도메인을 실행 중인지에 따라 standalone.conf 또는 domain.conf 파일을 편집해야 합니다. Windows에서 실행하는 경우 standalone.conf.bat 또는 domain.conf.bat 파일이 대신 사용됩니다.

    구성 파일에서 SECMGR="true" 행의 주석을 제거합니다.

    standalone.conf 또는 domain.conf의 예

    # Uncomment this to run with a security manager enabled
    SECMGR="true"

    standalone.conf.BAT 또는 domain.conf.bat의 예

    rem # Uncomment this to run with a security manager enabled
    set "SECMGR=true"

5.4. 이전 버전에서 이동하기 전에 고려해야 할 사항

Java Security Manager가 활성화된 상태로 실행되는 이전 버전의 JBoss EAP 7에서 JBoss EAP 7로 애플리케이션을 이동하는 경우, 정책을 정의하는 방법과 JBoss EAP 구성과 배포에 필요한 구성의 변경 사항을 알고 있어야 합니다. 다음은 알고 있어야 하는 변경 사항은 다음과 같습니다.

  • 이전 버전의 JBoss EAP에서는 정책이 외부 구성 파일에 정의되었습니다. JBoss EAP 7에서 정책은 security-manager 하위 시스템을 사용하고 배포에 포함된 permissions.xml 또는 jboss-permissions.xml 과 함께 정의됩니다.
  • 이전 버전의 JBoss EAP를 시작하는 동안 -Djava.security.manager-Djava.security.policy Java 시스템 속성을 사용할 수 있습니다. 이러한 기능은 더 이상 지원되지 않으며, 대신 JBoss EAP가 Java Security Manager와 함께 실행되도록 secmgr 플래그를 사용해야 합니다.
  • JBoss EAP 7에서는 사용자 지정 보안 관리자가 지원되지 않습니다.

부록 A. 참고 자료

A.1. Elytron 하위 시스템 구성 요소 참조

표 A.1. add-prefix-role-mapper 속성

속성설명

접두사

각 역할에 추가할 접두사입니다.

표 A.2. add-suffix-role-mapper 속성

속성설명

접미사

각 역할에 추가할 접미사입니다.

표 A.3. aggregate-http-server-mechanism-factory Attributes

속성설명

http-server-mechanism-factories

집계할 HTTP 서버 팩토리 목록입니다.

표 A.4. aggregate-principal-decoder 속성

속성설명

주체 디코더

집계할 주요 디코더 목록입니다.

표 A.5. aggregate-principal-transformer 속성

속성설명

Principal-transformers

집계할 주요 변환기 목록입니다.

표 A.6. aggregate-providers 속성

속성설명

공급자

집계할 참조된 Provider[] 리소스 목록입니다.

표 A.7. aggregate-realm 속성

속성설명

authentication-realm

인증 단계에 사용할 보안 영역에 참조합니다. 이는 자격 증명을 가져오거나 확인하는 데 사용됩니다.

authorization-realm

권한 부여 단계에 대한 ID를 로드하는 데 사용할 보안 영역에 대한 참조입니다.

authorization-realms

인증 단계를 위해 ID를 로드하기 위해 집계할 보안 영역에 대한 참조입니다.

여러 권한 부여 영역을 사용하는 방법에 대한 자세한 내용은 ID 관리 구성 가이드의 여러 ID 저장소를 사용하여 인증 및 권한 부여 구성을 참조하십시오.

참고

authorization-realmauthorization-realms 특성은 함께 사용할 수 없습니다. 한 영역에서 두 속성 중 하나만 정의합니다.

표 A.8. aggregate-role-mapper 속성

속성설명

role-mappers

집계할 역할 매퍼 목록입니다.

표 A.9. aggregate-sasl-server-factory 속성

속성설명

sasl-server-factories

집계할 SASL 서버 팩토리 목록입니다.

표 A.10. 인증 구성 속성

속성설명

익명

진정한 익명 인증을 허용하는 경우. 기본값은 false입니다.

authentication-name

사용할 인증 이름입니다.

authorization-name

사용할 권한 부여 이름입니다.

인증 정보 참조

인증에 사용할 자격 증명입니다. 이는 일반 텍스트 또는 자격 증명 저장소에 저장된 자격 증명에 대한 참조일 수 있습니다.

extends

확장할 기존 인증 구성입니다.

호스트

사용할 호스트입니다.

kerberos-security-factory

GSS kerberos 자격 증명을 가져오는 데 사용되는 kerberos 보안 팩토리에 대한 참조입니다.

mechanism-properties

SASL 인증 메커니즘의 구성 속성입니다.

port

사용할 포트입니다.

프로토콜

사용할 프로토콜입니다.

영역

사용할 영역입니다.

sasl-mechanism-selector

SASL 메커니즘 선택기 문자열입니다. sasl-mechanism-selector 에 필요한 grammar에 대한 자세한 내용은 JBoss EAP용 서버 보안 구성 방법sasl-mechanism-selector Grammar 를 참조하십시오.

security-domain

보안 도메인에 대한 참조로 전달된 ID를 가져옵니다.

표 A.11. authentication-context 속성

속성설명

extends

확장할 기존 인증 컨텍스트입니다.

match-rules

이 인증 컨텍스트와 일치하는 규칙입니다.

표 A.12. authentication-context match-rules Attributes

속성설명

authentication-configuration

일치 시 사용할 인증 구성에 대한 참조입니다.

match-abstract-type

일치하는 추상 유형입니다.

match-abstract-type-authority

와 일치하는 추상 유형 권한입니다.

match-host

일치하는 호스트입니다.

match-local-security-domain

일치하는 로컬 보안 도메인입니다.

match-no-user

true인 경우 규칙이 사용자 없음과 일치합니다.

match-path

패치와 일치해야 합니다.

match-port

와 일치하는 포트입니다.

match-protocol

일치시킬 프로토콜입니다.