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는 다양한 호스트, 네트워킹 및 방화벽 요구 사항에 맞게 작업할 수 있습니다.
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 인스턴스에 미치는 영향과 해당 구성이 완전히 파악된 경우에만 수행해야 합니다.
절차
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레거시 보안 영역을 사용할 때 자동 인증을 제거하려면 다음을 수행합니다.
/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를 다음 두 가지 방법으로 활성화할 수 있습니다.
- 보안 명령 사용.
-
elytron하위 시스템 명령 사용.
관리 콘솔에서는 다음과 같이 에서 단방향 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를 활성화할 수 있습니다.
절차
키 저장소구성./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()key-manager및server-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는PKIX및SunX509알고리즘을 제공합니다.이전 명령에서
SunX509를 키 관리자 알고리즘 특성으로 지정할 수 있습니다.또한 지원할 HTTPS 프로토콜을 결정해야 합니다. 위의 예제 명령은
TLSv1.2를 사용합니다.cipher-suite-filter를 사용하여 암호화 제품군과use-cipher-suites-order인수를 사용하여 서버 암호화 제품군 순서를 준수할 수 있습니다.use-cipher-suites-order속성은 기본적으로true로 설정됩니다. 이는 기본적으로 클라이언트 암호화 모음 순서를 준수하는 레거시보안하위 시스템 동작과 다릅니다.관리 인터페이스에서 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)JBoss EAP 인스턴스를 다시 로드합니다.
reload
관리 인터페이스에 대해 일방향 SSL/TLS가 활성화됩니다.
보안 영역과 ssl-context가 모두 정의된 경우 JBoss EAP는 ssl -context 에서 제공하는 SSL/TLS 구성을 사용합니다 .
1.2.5.3. 관리 콘솔을 사용하여 단방향 SSL/TLS 활성화 링크 복사링크가 클립보드에 복사되었습니다!
관리 콘솔에서 SSL 마법사를 사용하여 관리 콘솔에서 사용하는 관리 인터페이스에 대해 SSL을 활성화할 수 있습니다.
절차
- 관리 콘솔에 액세스합니다. 자세한 내용은 JBoss EAP 구성 가이드의 관리 콘솔 섹션을 참조하십시오.
- Runtime (런타임)으로 이동하여 적절한 서버 이름을 클릭합니다.
- 서버 이름 옆에 있는 View(보기 )를 클릭합니다.
- HTTP Manageme…를 클릭합니다. HTTP 관리 인터페이스 구성 페이지를 엽니다.
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 명령을 사용하여 클라이언트 인증서를 생성할 수 있습니다.
절차
클라이언트 인증서를 생성합니다.
$ keytool -genkeypair -alias client -keyalg RSA -keysize 1024 -validity 365 -keystore client.keystore.jks -dname "CN=client" -keypass secret -storepass secret클라이언트 인증서를 내보냅니다.
$ 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를 활성화할 수 있습니다.
사전 요구 사항
서버 신뢰 저장소에 대한 인증서를 내보냈습니다.
자세한 내용은 클라이언트 인증서 생성 을 참조하십시오.
절차
키 저장소를 가져오거나 생성합니다.
JBoss EAP에서 일방향 SSL/TLS를 활성화하기 전에 사용하려는 키 저장소, 신뢰 저장소 및 인증서를 가져오거나 생성해야 합니다. 키 저장소, 신뢰 저장소 및 인증서의 예제 집합을 생성하려면 다음 명령을 사용합니다.
키 저장소구성./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를생략할 수도 있습니다.서버 인증서를 내보냅니다.
/subsystem=elytron/key-store=twoWayKS:export-certificate(alias=localhost,path=/path/to/server.cer,pem=true)서버 신뢰
저장소의 키저장소를 생성하고 클라이언트 인증서를 서버 신뢰 저장소로 가져옵니다.참고다음 예제에서는 신뢰 체인이 없으므로 인증서를 확인하지 않습니다. 신뢰할 수 있는 인증서를 사용하는 경우 문제 없이 클라이언트 인증서를 검증할 수 있습니다.
/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()
서버 키 저장소 및 신뢰 저장소에 대해
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() 및를 사용하여 기본적으로 알고리즘을 결정하므로 이전 명령에서 algorithm을 지정하지 않았습니다. 그러나 알고리즘 특성을 지정할 수 있습니다. 알고리즘 특성을 지정하려면 JDK에서 제공하는 키 관리자 알고리즘이 무엇인지 알아야 합니다. 예를 들어 SunJSSE를 사용하는 JDK는TrustManagerfactory.getDefaultAlgorithm()PKIX및SunX509알고리즘을 제공합니다.이전 명령에서
SunX509를 키 관리자 알고리즘 특성으로 지정하고PKIX를 신뢰 관리자 알고리즘 속성으로 지정할 수 있습니다.또한 지원할 HTTPS 프로토콜을 결정해야 합니다. 위의 예제 명령은
TLSv1.2를 사용합니다.cipher-suite-filter를 사용하여 암호화 제품군과use-cipher-suites-order인수를 사용하여 서버 암호화 제품군 순서를 준수할 수 있습니다.use-cipher-suites-order속성은 기본적으로true로 설정됩니다. 이는 기본적으로 클라이언트 암호화 모음 순서를 준수하는 레거시보안하위 시스템 동작과 다릅니다.관리 인터페이스에서 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)JBoss EAP 인스턴스를 다시 로드합니다.
reload참고양방향 SSL/TLS 인증을 완료하려면 서버 인증서를 클라이언트 신뢰 저장소로 가져오고 클라이언트 인증서를 클라이언트 인증서를 제공하도록 구성해야 합니다.
클라이언트에서 클라이언트 인증서를 사용하도록 구성합니다.
양방향 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를 활성화하는 단계를 수행하는 동안 명시적으로 지시하지 않는 한 구성을 다시 로드하지 마십시오. 이렇게 하면 관리 인터페이스가 잠길 수 있습니다.
관리 인터페이스를 보호하기 위해 키 저장소를 생성합니다.
자세한 내용은 관리 인터페이스 보안을 위해 키 저장소 생성을 참조하십시오.
관리 인터페이스가 HTTPS에 바인딩되는지 확인합니다.
자세한 내용은 관리 인터페이스 구성이 HTTPS에 바인딩 되어 있는지 확인합니다.
선택 사항: 사용자 지정
socket-binding-group을 구현합니다.자세한 내용은 Custom socket-binding-group 을 참조하십시오.
새 보안 영역을 생성합니다.
자세한 내용은 새 보안 영역 생성을 참조하십시오.
새 보안 영역을 사용하도록 관리 인터페이스를 구성합니다.
자세한 내용은 보안 영역을 사용하도록 관리 인터페이스 구성을 참조하십시오.
키 저장소를 사용하도록 관리 인터페이스를 구성합니다.
자세한 내용은 키 저장소를 사용하도록 관리 인터페이스 구성을 참조하십시오.
jboss-cli.xml을 업데이트합니다.자세한 내용은 jboss-cli.xml 파일 업데이트를 참조하십시오.
1.2.9.1. 관리 인터페이스를 보호하기 위한 키 저장소 생성 링크 복사링크가 클립보드에 복사되었습니다!
관리 인터페이스를 보호하기 위해 키 저장소를 생성합니다.
관리 인터페이스는 JCEKS 형식의 키 저장소와 호환되지 않으므로 이 키 저장소는 JKS 형식이어야 합니다.
절차
다음 CLI 명령을 사용하여 키 저장소를 생성합니다.
매개 변수의 예제 값(예:
alias,keypass,storepass및dname)을 환경의 올바른 값으로 바꿉니다.$ 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- https9993 에 바인딩됩니다. 서버 구성 파일의 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 라는 속성 파일을 사용합니다.
절차
사용자 이름 및 암호를 저장할 속성 파일을 만듭니다.
나중에 사용자 이름 및 암호를 파일에 추가할 수 있지만, 현재는
https-mgmt-users.properties라는 빈 파일을 생성하여 해당 위치에 저장해야 합니다. 아래 예제에서는touch명령을 사용하는 방법을 보여주지만 텍스트 편집기와 같은 다른 메커니즘을 사용할 수도 있습니다.예제: touch 명령을 사용하여 빈 파일 생성
$ touch EAP_HOME/standalone/configuration/https-mgmt-users.properties다음 관리 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)속성 파일에 사용자를 추가합니다.
이때 새 보안 영역을 생성하고 인증에 속성 파일을 사용하도록 구성했습니다. 이제
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 명령을 사용하여 키 저장소를 사용하도록 관리 인터페이스를 구성합니다.
절차
다음 관리 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)서버의 설정을 다시 로드합니다.
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을 명시적으로 비활성화하는 것이 좋습니다.
절차
키 저장소를 생성합니다.
$ 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인증서를 내보냅니다.
$ 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인증서를 다른 신뢰 저장소로 가져옵니다.
$ 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.cerCertificateRealm 정의.
서버에 대한 구성(host
.xml 또는)에서 CertificateRealm을 정의하고 인터페이스를 가리킵니다. 다음 명령을 사용하여 수행할 수 있습니다.standalone.xml/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)http을 새 CertificateRealm으로 변경합니다.-interface의 security-realm/core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=CertificateRealm)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를 활성화합니다.
절차
OpenSSL TLS 공급자를 사용하도록 JBoss EAP 7.4 인스턴스를 구성하는 다음 방법 중 하나를 선택합니다.
기본적으로 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)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
선택 사항: TLS 1.3 프로토콜 이외의 프로토콜을 사용하도록
ssl-context를 구성한 경우 TLS 1.3프로토콜을포함하도록ssl-context에 protocol 속성을 구성해야 합니다./subsystem=elytron/server-ssl-context=serverSSC:write-attribute(name=protocols,value=[TLSv1.3])ssl-context구성에서cipher-suite-names속성을 구성하여 OpenSSL 프로바이더로 TLS 1.3 프로토콜 지원을 활성화합니다. 다음 예제에서는TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256을cipher-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)JBoss EAP 인스턴스를 다시 로드합니다.
reload선택 사항: 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.
추가 리소스
- 애플리케이션에 대한 단방향 SSL/TLS 또는 양방향 SSL/TLS 활성화에 대한 자세한 내용은 Elytron 하위 시스템을 사용하여 애플리케이션에 대한 일방향 SSL/TLS 사용을 참조하십시오.
-
client-ssl-context에 대한 자세한 내용은클라이언트-ssl-context사용을 참조하십시오. -
server-ssl-context에 대한 정보는server-ssl-context사용을 참조하십시오.
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를 구성하려면 다음을 수행해야 합니다.
- NSS 데이터베이스를 구성합니다.
- SSL/TLS용 FIPS 140-2 호환 암호화용 관리 CLI를 구성합니다.
-
Elytron 또는 레거시 코어 관리 인증을 사용하도록
undertow하위 시스템을 구성합니다.
OpenSSL 프로바이더에는 개인 키가 필요하지만 PKCS11 저장소에서 개인 키를 검색할 수는 없습니다. FIPS는 FIPS 호환 암호화 모듈에서 암호화되지 않은 키를 내보낼 수 없습니다. 따라서 Ely tron 하위 시스템과 레거시 보안 모두 FIPS 모드에서 TLS에 OpenSSL 공급자를 사용할 수 없습니다.
NSS 데이터베이스 구성
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를 실행하려면 이를 운영 체제에서 활성 사용자로 교체합니다.
NSS 구성 파일
/usr/share/jboss-as/nss_pkcsll_fips.cfg를 만듭니다.다음을 지정해야 합니다.
- 이름
- NSS 라이브러리가 있는 디렉토리
NSS 데이터베이스가 이전 단계에서 생성된 디렉토리
예:
nss_pkcsll_fips.cfgname = nss-fips nssLibraryDirectory=/usr/lib64 nssSecmodDirectory=/usr/share/jboss-as/nssdb nssDbMode = readOnly nssModule = fips참고64비트 버전의 Red Hat Enterprise Linux 6을 실행하지 않는 경우
nssLibraryDirectory를/usr/lib64 대신 /usr/lib로 설정합니다.
Java 보안 구성 파일을 편집합니다. 이 구성 파일은 전체 JVM에 영향을 미치며 다음 방법 중 하나를 사용하여 정의할 수 있습니다.
-
기본 구성 파일
java.security가 JDK에 제공됩니다. 이 파일은 다른 보안 구성 파일이 지정되지 않은 경우 사용됩니다. 이 파일의 위치는 JDK 벤더의 설명서를 참조하십시오. 사용자 지정 Java 보안 구성 파일을 정의하고
-Djava.security.properties=/path/to/java.security.properties를 사용하여 이를 참조합니다. 이러한 방식으로 참조할 경우 기본 보안 파일의 설정을 덮어씁니다. 이 옵션은 서로 다른 보안 설정이 필요한 동일한 호스트에서 여러 JVM을 실행하는 경우 유용합니다.Java 보안 구성 파일에 다음 행을 추가합니다.
예:
java.securitysecurity.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 값을 하나씩 늘려야 합니다.
-
기본 구성 파일
이전 단계에서 만든 NSS 데이터베이스 디렉터리에서
modutil명령을 실행하여 FIPS 모드를 활성화합니다.modutil -fips true -dbdir /usr/share/jboss-as/nssdb참고현재 보안 라이브러리 오류가 발생하면 NSS 공유 객체에 대한 라이브러리 서명을 다시 생성해야 합니다.
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"에서 암호를 변경할 수 없습니다.
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다음 명령을 실행하여 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 파일에서trustStorejavax.net.ssl.trustStore및 javax.net.ssl.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하위 시스템을 사용하는 경우:다음 콘텐츠를 사용하여 관리 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 구성 예를 참조하십시오.
관리 CLI를 시작할 때
-Dwildfly.config.url속성을 사용하여 구성 파일을 관리 CLI 스크립트에 전달합니다. 예를 들면 다음과 같습니다.$ jboss-cli.sh -Dwildfly.config.url=cli-wildfly-config.xml
Elytron 및 Undertow 하위 시스템 구성
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"])새
ssl-context를 사용하도록undertow하위 시스템을 업데이트합니다.참고HTTPS-listener에는 항상security-realm 또는가 구성되어 있어야 합니다. 두 구성을 변경하는 경우 아래 표시된 대로 명령을 단일 배치로 실행해야 합니다.ssl-contextbatch /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 호환 암호화 설정을 완료할 수 있습니다.
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-batchUndertow를 SSL/TLS로 구성하기 위한 기본 세부 정보는 애플리케이션용 SSL/TLS 설정에서 다룹니다.
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_SHAhttps 리스너에 대한 암호화 제품군 활성화의 기본 사항은 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")보안 영역에서 암호화 제품군을 활성화합니다.
보안 영역에서 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를 구성해야 합니다.
다음 콘텐츠를 사용하여 관리 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>관리 CLI를 시작할 때
-Dwildfly.config.url속성을 사용하여 구성 파일을 관리 CLI 스크립트에 전달합니다. 예를 들면 다음과 같습니다.$ jboss-cli.sh -Dwildfly.config.url=cli-wildfly-config.xml
Elytron 및 Undertow 하위 시스템 구성
FIPS 140-2 호환 암호화
키 저장소,를 추가합니다. 키 저장소를 정의할 때 유형은키-manager 및ssl-contextBCFKS여야 합니다./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")새
ssl-context를 사용하도록undertow하위 시스템을 업데이트합니다.참고HTTPS-listener에는 항상security-realm 또는가 구성되어 있어야 합니다. 두 구성을 변경하는 경우 아래 표시된 대로 명령을 단일 배치로 실행해야 합니다.ssl-contextbatch /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 또는 FIPS 공급자에 대한 정보는 domain.conf 파일에 -Djavax.net.debug=true 를 추가하여 디버그 수준 로깅을 활성화합니다.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을 명시적으로 비활성화하는 것이 좋습니다.
마스터 도메인 컨트롤러에서 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>각 호스트 컨트롤러에서 인증을 위한 SSL/TLS 신뢰 저장소로 보안 영역을 생성합니다.
예제: 각 호스트 컨트롤러의 보안 영역
<security-realm name="HTTPSRealm"> <authentication> <truststore provider="PKCS11" keystore-password="strongP@ssword1"/> </authentication> </security-realm>참고각 호스트에서 이 프로세스를 반복합니다.
방금 만든 보안 영역을 사용하여 마스터 도메인 컨트롤러에서 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>각 호스트 컨트롤러에서 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>각 서버가 호스트 컨트롤러에 다시 연결하는 방법을 업데이트합니다.
예제: 서버 설정
<server name="my-server" group="my-server-group"> <ssl ssl-protocol="TLS" trust-manager-algorithm="PKIX" truststore-type="PKCS11" truststore-password="strongP@ssword1"/> </server>관리형 도메인에서 양방향 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 서버 구성
- Red Hat SSO(Single Sign-On) 서버 다운로드 및 설치. 기본 지침은 Red Hat Single Sign-On Getting Started Guide 를 참조하십시오.
Red Hat Single Sign-On 서버 시작.
이 절차에서는
100의 포트 오프셋으로 서버를 시작했다고 가정했습니다.$ RHSSO_HOME/bin/standalone.sh -Djboss.socket.binding.port-offset=100http://localhost:8180/auth/ 에서 Red Hat SSO(Single Sign-On) 관리 콘솔에 로그인합니다.
Red Hat Single Sign-On 관리 콘솔에 처음 액세스한 경우 초기 관리 사용자를 생성하라는 메시지가 표시됩니다.
wildfly-infra라는 새 영역을 생성합니다.-
영역 이름 옆에 있는 드롭다운에서 Add realm (영역 추가)을 클릭하고 Name (이름) 필드에
wildfly-infra를 입력한 다음 Create(만들기 )를 클릭합니다.
-
영역 이름 옆에 있는 드롭다운에서 Add realm (영역 추가)을 클릭하고 Name (이름) 필드에
wildfly-console이라는 클라이언트 애플리케이션을 생성합니다.중요이 클라이언트 애플리케이션의 이름은 be
wildfly-console이어야 합니다.- Clients (클라이언트)를 선택하고 Create(생성)를 클릭합니다.
-
클라이언트 ID 필드에 있는
wildfly-console을 입력하고 Save(저장 )를 클릭합니다. -
표시되는 설정 화면에서 액세스 유형을
공용으로 설정하고유효한 리디렉션 URI를 http://localhost:9990/console/*, Web Origins 를http://localhost:9990로, Save(저장)를 클릭합니다.
wildfly-management라는 클라이언트 애플리케이션을 생성합니다.- Clients (클라이언트)를 선택하고 Create(생성)를 클릭합니다.
-
클라이언트 ID 필드에
wildfly-management를 입력하고 Save(저장 )를 클릭합니다. -
표시되는 Settings (설정) 화면에서 Access Type (액세스 유형)을
전달자 전용으로설정하고 Save(저장 )를 클릭합니다.
JBoss EAP 관리 콘솔에 대한 액세스 권한을 부여하는 역할을 만듭니다.
- Roles(역할 )를 선택하고 Add Role (역할 추가)을 클릭합니다.
Role Name (역할 이름) 필드의 대문자로 Enter
ADMINISTRATOR를 입력하고 Save(저장 )를 클릭합니다.이 절차에서는
ADMINISTRATOR역할을 사용하지만 다른 역할은 지원됩니다. 자세한 내용은 JBoss EAP 보안 아키텍처 의 역할 기반 액세스 제어 섹션을 참조하십시오.
사용자를 생성하고
ADMINISTRATOR역할을 할당합니다.- Users(사용자 )를 선택하고 Add user(사용자 추가 )를 클릭합니다.
-
Username (사용자 이름) 필드에
jboss를 입력하고 Save(저장 )를 클릭합니다. - Credentials(자격 증명 ) 탭을 선택하고 이 사용자의 암호를 설정합니다.
- Role Mappings (역할 맵핑) 탭을 선택하고 ADMINISTRATOR(ADMINISTRATOR )를 선택한 다음 Add selected (선택한 추가)를 클릭하여 역할을 이 사용자에게 추가합니다.
JBoss EAP에 Red Hat Single Sign-On 클라이언트 어댑터 설치
- 소프트웨어 다운로드 페이지에서 JBoss EAP 7용 Red Hat Single Sign-On 클라이언트 어댑터를 다운로드합니다.
- 이 파일의 압축을 JBoss EAP 설치의 루트 디렉터리에 풉니다.
adapter-elytron-install-offline.cli스크립트를 실행하여 JBoss EAP 설치를 구성합니다.$ EAP_HOME/bin/jboss-cli.sh --file=adapter-elytron-install-offline.cli중요이 스크립트는
elytron및undertow하위 시스템에서keycloak하위 시스템과 기타 필수 리소스를standalone.xml에 추가합니다. 다른 구성 파일을 사용해야 하는 경우 필요에 따라 스크립트를 수정합니다.
Red Hat Single Sign-On을 사용하도록 JBoss EAP 구성
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-
이 파일에서
REALM_PUBLIC_KEY를 공개 키 값으로 바꿉니다. 이 값을 얻으려면 Red Hat Single Sign-On 관리 콘솔에 로그인하고wildfly-infra영역을 선택하고 Realm SettingsKeys(재설정 키 )로 이동하여 공개 키를 클릭합니다. JBoss EAP 시작.
$ EAP_HOME/bin/standalone.sh중요standalone
.스크립트를 수정한 경우 해당 구성을 사용하여 JBoss EAP를 시작해야 합니다.xml 이외의 구성 파일을 사용하기 위해 Red Hat Single Sign-On 클라이언트 어댑터를 설치할 때 adapter- elytron-install-offline.cliprotect-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 관리 콘솔로 다시 리디렉션됩니다.