2.2. 관리 인터페이스 보안 방법
다음 섹션에서는 JBoss EAP 관리 인터페이스 및 관련 하위 시스템 보안과 관련된 다양한 작업을 수행하는 방법을 보여줍니다.
표시된 관리 CLI 명령은 JBoss EAP 독립 실행형 서버를 실행한다고 가정합니다. JBoss EAP 관리형 도메인에 대한 관리 CLI 사용에 대한 자세한 내용은 JBoss EAP 관리 CLI 가이드를 참조하십시오.
2.2.1. JBoss EAP에서 사용하는 네트워킹 및 포트 구성
호스트 구성에 따라 JBoss EAP는 다양한 네트워크 인터페이스와 포트를 사용하도록 구성할 수 있습니다. 이를 통해 JBoss EAP는 다양한 호스트, 네트워킹 및 방화벽 요구 사항을 사용할 수 있습니다.
JBoss EAP에서 사용하는 네트워킹 및 포트와 해당 설정을 구성하는 방법에 대한 자세한 내용은 구성 가이드의 네트워크 및 포트 구성 섹션을 참조하십시오.
2.2.2. HTTPS에 대한 관리 인터페이스 구성
HTTPS를 통해서만 통신을 위해 JBoss EAP 관리 인터페이스를 구성하면 보안이 향상됩니다. 클라이언트와 관리 인터페이스 간의 모든 네트워크 트래픽은 암호화되므로 중간자 공격과 같은 보안 공격의 위험이 줄어듭니다.
이 절차에서는 JBoss EAP 인스턴스와 암호화되지 않은 통신이 비활성화됩니다. 이 절차는 독립 실행형 서버 및 관리형 도메인 구성에 모두 적용됩니다. 관리형 도메인의 경우 관리 CLI 명령 접두사를 호스트 이름으로 추가합니다(예: /host=master
).
관리 인터페이스에서 HTTPS를 활성화하는 단계를 수행하는 동안 명시적으로 지시하지 않는 한 구성을 다시 로드하지 마십시오. 이렇게 하면 관리 인터페이스에서 잠길 수 있습니다.
키 저장소를 생성하여 관리 인터페이스를 보호합니다.
참고관리 인터페이스가 JCEKS 형식의 키 저장소와 호환되지 않으므로 이 키 저장소는 JKS 형식이어야 합니다.
다음을 사용하여 매개 변수의 예제 값(예:
별칭
,keypass
,keystore
,storepass
및dname
)을 해당 환경에 대한 올바른 값으로 교체하여 키 저장소를 생성합니다.참고매개변수
validity
는 키가 유효한 일 수를 지정합니다.730
의 값은 2년입니다.keytool
명령을 사용하여 터미널에서 키 저장소를 생성$ 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
관리 인터페이스가 HTTPS에 바인딩되는지 확인합니다.
독립 실행형 서버 실행.
관리 인터페이스가 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
섹션 내에서 socket 요소를 변경합니다.다음 명령을 사용하여 관리 인터페이스를 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)
선택 사항: 사용자 지정 socket-binding-group을 사용합니다. 사용자 지정
socket-binding-group
을 사용하려면 기본적으로 포트9993
에 바인딩되는management-https
바인딩이 정의되어 있는지 확인해야 합니다. 서버 구성 파일의socket-binding-group
섹션을 검토하거나 관리 CLI를 사용하여 이를 확인할 수 있습니다.관리 CLI를 사용하여 socket-binding-group 구성의 예
/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}" } }
새 보안 영역을 만듭니다. 이 예에서 HTTPS를 사용하는 새 보안 영역인 ManagementRealmHTTPS는 사용자 이름과 암호를 저장하기 위해
EAP_HOME/standalone/configuration/
디렉터리에 있는https-mgmt-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
옵션을 사용하여 properties 파일과 보안 영역을 모두 지정해야 합니다. 여기에서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
중요속성 파일을 사용하여 사용자 이름과 암호를 저장하는 보안 영역을 구성할 때 각 영역에서 다른 영역과 공유되지 않는 고유한 속성 파일을 사용하는 것이 좋습니다.
새 보안 영역을 사용하도록 관리 인터페이스를 구성합니다.
/core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=ManagementRealmHTTPS)
키 저장소를 사용하도록 관리 인터페이스를 구성합니다.
다음 CLI 명령을 사용하여 키 저장소를 사용하도록 관리 인터페이스를 구성합니다. 매개 변수 파일의 경우 암호 및 별칭 값을 첫 번째 단계에서 복사해야 합니다.
보안 저장소에 키 저장소를 추가하는 CLI 명령
/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
을 업데이트하려면 다음 단계로 이동합니다.jboss-cli.xml
을 업데이트합니다.관리 CLI를 사용하여 관리 작업을 수행하는 경우
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 /]
-
<
2.2.3. 관리 콘솔만 비활성화
JBoss Operations Network와 같은 기타 클라이언트는 JBoss EAP 관리를 위해 HTTP 인터페이스를 사용하여 작동합니다. 이러한 서비스를 계속 사용하려면 웹 기반 관리 콘솔 자체만 비활성화할 수 있습니다. 이는 console-enabled 속성을 false 로 설정하여 수행됩니다.
웹 기반 관리 콘솔 비활성화를 위한 CLI 명령
/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)
2.2.4. 관리 인터페이스에 대한 2 단계 SSL/TLS 설정
양방향 SSL/TLS 인증( 클라이언트 인증 이라고도 함)은 SSL/TLS 인증서를 사용하여 클라이언트와 서버 모두를 인증합니다. 이는 클라이언트와 서버 모두에 각각 인증서가 있다는 점에서 HTTPS에 대한 관리 인터페이스 구성 섹션과 다릅니다. 이를 통해 서버는 서버일 뿐만 아니라 클라이언트가 이를 말하는 사람이기도 합니다.
이 섹션에서는 다음 규칙이 사용됩니다.
- 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.cer
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)
http-interface
의security-realm
을 새 CertificateRealm으로 변경합니다./core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=CertificateRealm)
CLI에 대한 SSL/TLS 구성을 추가합니다.
중요양방향 SSL/TLS를 추가하는 것 외에도 관리 인터페이스도 HTTPS에 바인딩하도록 구성해야 합니다.
EAP_HOME/bin/jboss-cli.xml
을 설정 파일로 사용하는 CLI의 SSL/TLS 구성을 추가합니다.키 저장소 및 신뢰 저장소 암호를 일반 텍스트에 저장하려면
EAP_HOME/bin/jboss-cli.xml
을 편집하고 변수에 적절한 값을 사용하여 SSL/TLS 구성을 추가합니다.jboss-cli.xml 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>
암호 자격 증명 모음에 저장된 키 저장소 및 신뢰 저장소 암호를 사용하려면 자격 증명 모음 구성과 적절한 vault 값을
EAP_HOME/bin/jboss-cli.xml
에 추가해야 합니다.jboss-cli.xml XML 예
<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>
2.2.5. 애플리케이션용 SSL/TLS 설정
JBoss EAP는 관리 인터페이스에 HTTPS 및 양방향 SSL/TLS를 지원하는 것 외에도 보안 도메인에서 사용할 SSL/TLS(HTTPS 리스너를 통해)를 설정할 수 있습니다.
사전 요구 사항으로 SSL/TLS 암호화 키 및 인증서를 생성하여 액세스 가능한 디렉터리에 배치해야 합니다. 또한 관련 정보(예: 키 저장소 별칭 및 암호, 원하는 암호화 제품군 등)에 액세스할 수도 있어야 합니다. SSL/TLS 키 및 인증서를 생성하는 예를 보려면 관리 인터페이스에 대한 2일 SSL/TLS 설정 섹션의 처음 두 단계를 참조하십시오. HTTPS 리스너(암호 모음 포함)에 대한 자세한 내용은 HTTPS 리스너 참조 섹션을 참조하십시오.
One-Way SSL/TLS 설정
이 예에서는 keystore인 identity.jks
가 서버 구성 디렉터리에 복사되고 지정된 속성으로 구성되어 있다고 가정합니다. 관리자는 예제 값에 대해 고유한 값을 대체해야 합니다.
표시된 관리 CLI 명령은 JBoss EAP 독립 실행형 서버를 실행한다고 가정합니다. JBoss EAP 관리형 도메인에 대한 관리 CLI 사용에 대한 자세한 내용은 JBoss EAP 관리 CLI 가이드를 참조하십시오.
먼저 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:add( \ socket-binding=https, security-realm=HTTPSRealm) run-batch
주의Red Hat은 영향을 받는 모든 패키지에서 TLSv1.1 또는 TLSv1.2를 사용하도록 SSLv2, SSLv3 및 TLSv1.0을 명시적으로 비활성화할 것을 권장합니다.
변경 사항을 적용하려면 서버를 다시 로드합니다.
reload
2.2.6. 2단계 SSL/TLS for Applications 설정
애플리케이션에 대한 양방향 SSL/TLS 설정은 관리 인터페이스에 대해 Two-Way SSL/TLS 설정에 설명된 동일한 여러 절차를 따릅니다. 애플리케이션에 대해 Two-Way SSL/TLS를 설정하려면 다음을 수행해야 합니다.
- 클라이언트와 서버 둘 다에 대한 저장소를 생성
- 클라이언트와 서버 모두에 대한 인증서 내보내기
- 인증서를 반대 신뢰 저장소로 가져옵니다.
-
서버의 키 저장소 및 신뢰 저장소를 사용하는 서버에서 보안 영역(예:
CertificateRealm
)을 정의합니다. -
보안 영역을 사용하도록
undertow
하위 시스템을 업데이트하면 클라이언트 확인이 필요합니다.
처음 네 단계는 관리 인터페이스에 대한 Two-Way SSL/TLS 설정에서 다룹니다.
새 보안 영역을 추가한 후 서버를 다시 로드하지 않은 경우 다음 단계를 수행하기 전에 서버를 다시 로드해야 합니다.
Cryostat를 업데이트합니다.
키 저장소, 인증서, 신뢰 저장소 및 보안 영역을 생성 및 구성한 후에는 undertow
하위 시스템에 HTTPS 리스너를 추가하고 생성한 보안 영역을 사용하며 클라이언트 확인이 필요합니다.
/subsystem=undertow/server=default-server/https-listener=https:add( \ socket-binding=https, security-realm=CertificateRealm, verify-client=REQUIRED)
애플리케이션에 대해 양방향 SSL/TLS가 활성화된 JBoss EAP 인스턴스에 연결하는 모든 클라이언트는 클라이언트 인증서 또는 키 저장소에 액세스할 수 있어야 합니다. 즉, 인증서가 서버의 신뢰 저장소에 포함된 클라이언트 키 저장소입니다. 클라이언트가 브라우저를 사용하여 JBoss EAP 인스턴스에 연결하는 경우 해당 인증서 또는 키 저장소를 브라우저의 인증서 관리자로 가져와야 합니다.
애플리케이션과 함께 양방향 SSL/TLS 외에도 애플리케이션에서 인증서 기반 인증을 사용하는 방법에 대한 자세한 내용은 JBoss EAP에 대한 ID 관리 구성 방법에서 인증서 기반 인증을 사용하도록 보안 도메인 구성에서 확인할 수 있습니다.
2.2.7. HTTPS 리스너 참조
HTTPS 리스너에 사용할 수 있는 전체 속성 목록은 JBoss EAP 구성 가이드의 Cryostat Cryostat 특성을 참조하십시오.
2.2.7.1. Cipher Suites 정보
허용되는 암호화 암호 목록을 구성할 수 있습니다. JSSE 구문의 경우 쉼표로 구분된 목록이어야 합니다. OpenSSL 구문의 경우 콜론으로 구분된 목록이어야 합니다. 하나의 구문만 사용해야 합니다. 기본값은 JVM 기본값입니다.
약한 암호를 사용하는 것은 심각한 보안 위험입니다. 암호화 제품군에 대한 NIST 권장 사항은 http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295 를 참조하십시오.
사용 가능한 OpenSSL 암호 목록은 https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-STRINGS 을 참조하십시오. 다음은 지원되지 않습니다.
- @SECLEVEL
- SUITEB128
- SUITEB128ONLY
- SUITEB192
표준 JSSE 암호 목록은 http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#Cipher 를 참조하십시오.
활성화된 암호화 제품군 목록을 업데이트하려면 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")
이 예제에서는 두 가지 가능한 암호만 나열하지만 실제 예제를 사용하면 더 많이 사용할 수 있습니다.
2.2.8. Red Hat Enterprise Linux 6에서 SSL/TLS용 FIPS 140-2 암호화 활성화
SSL/TLS에 FIPS 140-2 호환 암호화를 사용하도록 Cryostat를 구성할 수 있습니다. 이 구성 예제의 범위는 FIPS 모드에서 Mozilla NSS 라이브러리를 사용하는 Red Hat Enterprise Linux 6로 제한됩니다.
Red Hat Enterprise Linux 6는 FIPS 140-2 준수로 이미 구성되어 있어야 합니다. 자세한 내용은 https://access.redhat.com/knowledge/solutions/137833 을 참조하십시오.
TLS 1.2 프로토콜은 FIPS 모드에서 실행할 때 Oracle/OpenJDK 및 JBoss EAP에서 지원되지 않으며 NoSuchAlgorithmException 이 발생할 수 있습니다. 이 문제에 대한 자세한 내용은 여기에서 확인할 수 있습니다.
SSL/TLS에 대한 FIPS 140-2 암호화가 활성화된 환경에서 jboss-cli.sh
를 실행하는 경우 FIPS 모드: SunJSSE TrustManagers만 사용할 수 있습니다
. jboss-cli.sh
파일에서 javax.net.ssl.keyStore
및 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=imapassword"
SSL/TLS에 FIPS 140-2 호환 암호화를 사용하도록 Cryostat를 구성하려면 다음을 수행해야 합니다.
- NSS 데이터베이스 구성
- Cryostat 구성
2.2.8.1. 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
참고jboss 사용자는 예제일 뿐입니다. JBoss EAP 실행을 위해 사용하려는 운영 체제의 사용자로 교체해야 합니다.
NSS 구성 파일
/usr/share/jboss-as/nss_pkcsll_fips.cfg
를 만듭니다.다음을 지정해야 합니다.
- 이름
- NSS 라이브러리가 있는 디렉터리
이전 단계에서 NSS 데이터베이스가 생성된 디렉터리
Example
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을 실행하지 않는 경우
/usr/lib
64 대신nssLibraryDirectory
를/usr/lib64
로 설정합니다.
$JAVA_HOME/jre/lib/security/java.security
구성 파일을 편집합니다.$JAVA_HOME/jre/lib/security/java.security
에 다음 행을 추가합니다.예제
java.security
security.provider.1=sun.security.pkcs11.SunPKCS11 /usr/share/jboss-as/nss_pkcsll_fips.cfg
참고위 행에 지정된
nss_pkcsll_fips.cfg
구성 파일은 이전 단계에서 생성한 파일입니다.또한 다음에서
$JAVA_HOME/jre/lib/security/java.security
에서 다음 링크를 업데이트해야 합니다.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의 값이 1로 증가해야 합니다.이전 단계에서 생성한 NSS 데이터베이스 디렉터리에서
modutil
명령을 실행하여 FIPS 모드를 활성화합니다.modutil -fips true -dbdir /usr/share/jboss-as/nssdb
참고이 시점에서 일부 NSS 공유 오브젝트에 대한 라이브러리 서명을 다시 생성해야 하는 경우 보안 라이브러리 오류가 발생할 수 있습니다.
FIPS 토큰에 암호를 설정합니다.
토큰 이름은 NSS FIPS 140-2 Certificate DB 여야 합니다.
modutil -changepw "NSS FIPS 140-2 Certificate DB" -dbdir /usr/share/jboss-as/nssdb
중요FIPS 토큰에 사용되는 암호는 FIPS 호환 암호여야 합니다. 암호가 충분하지 않은 경우 토큰 "NSS FIPS 140-2 Certificate DB"의 암호를 변경할 수 없음 오류: ERROR: Unable to change password on token "NSS FIPS 140-2 Certificate 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
2.2.8.2. Cryostat 구성
SSL/TLS에 대한 FIPS 140-2 호환 암호화 설정을 완료하려면 다음을 수행합니다.
SSL/TLS를 사용하도록 Cryostat를 구성합니다.
참고아래 명령은 배치 모드로 실행하거나 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
Cryostat를 SSL/TLS로 구성하는 기본 세부 정보는 애플리케이션에 대한 SSL/TLS 설정에서 참조하십시오.
Cryostat에서 사용하는 암호화 제품군을 구성합니다.
SSL/TLS를 구성한 후에는 특정 암호화 제품군 세트를 활성화하도록 https 리스너 및 보안 영역을 구성해야 합니다.
필수 Cipher 제품군
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 Suites 에서 다룹니다. https 리스너에서 암호화 제품군을 활성화하려면 다음을 수행합니다.
Cipher Suites를 Enabling 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])
다음 명령을 실행하여 JVM에서 PKCS11 키 저장소에서 개인 키를 읽을 수 있는지 확인합니다.
keytool -list -storetype pkcs11
2.2.9. IBM JDK에서 FIPS 140-2 Compliant Cryptography
IBM JDK에서 IBM JCE(Java Cryptographic Extension) IBMJCEFIPS 공급자 및 IBM JSSE(Java Secure Sockets Extension) FIPS 140-2 Cryptographic Module (IBMJSSE2) for Multi-platforms는 FIPS 140-2 호환 암호화를 제공합니다.
IBMJCEFIPS 공급자에 대한 자세한 내용은 IBM Documentation for IBM JCEFIPS 및 NIST IBMJCEFIPS - 보안 정책을 참조하십시오. IBMJSSE2에 대한 자세한 내용은 여기에서 확인할 수 있습니다.
2.2.9.1. 키 스토리지
IBM JCE는 키 저장소를 제공하지 않습니다. 키는 컴퓨터에 저장되고 물리적 경계를 남기지 않습니다. 키가 컴퓨터 간에 이동되는 경우 암호화해야 합니다.
FIPS 호환 모드에서 keytool 을 실행하려면 다음과 같이 각 명령에서 -providerClass 옵션을 사용합니다.
keytool -list -storetype JCEKS -keystore mystore.jck -storepass mystorepass -providerClass com.ibm.crypto.fips.provider.IBMJCEFIPS
2.2.9.2. 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
2.2.10. JVM이 FIPS 모드에서 실행 중일 때 관리형 도메인 시작
관리형 도메인인 FIPS가 구성되어 있고 필요한 모든 인증서가 구성되어 있다고 가정합니다. 여기에는 도메인 컨트롤러의 인증서를 각 컨트롤러의 신뢰 저장소로 가져오는 작업이 포함됩니다. 관리형 도메인 구성에 대한 자세한 내용은 JBoss EAP 구성 가이드의 도메인 관리를 참조하십시오. FIPS 구성에 대한 자세한 내용은 Red Hat Enterprise Linux 6에서 SSL/TLS에 FIPS 140-2 암호화 활성화를 참조하십시오.
통신에 SSL/TLS를 사용하도록 각 호스트 컨트롤러 및 마스터 도메인 컨트롤러를 업데이트해야 합니다.
Red Hat은 영향을 받는 모든 패키지에서 TLSv1.1을 사용하도록 SSLv2, SSLv3 및 TLSv1.0을 명시적으로 비활성화할 것을 권장합니다.
마스터 도메인 컨트롤러에서 SSL/TLS 보안 영역을 생성합니다.
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 보안 영역을 생성합니다.
인증을 위해 SSL/TLS 신뢰 저장소를 사용하여 보안 영역을 생성해야 합니다.
보안의 예
<security-realm name="HTTPSRealm"> <authentication> <truststore provider="PKCS11" keystore-password="strongP@ssword1"/> </authentication> </security-realm>
참고각 호스트에서 이 프로세스를 반복해야 합니다.
마스터 도메인 컨트롤러에서 네이티브 인터페이스를 보호합니다.
방금 생성한 보안 영역으로 마스터 도메인 컨트롤러의 기본 인터페이스가 보호되도록 해야 합니다.
네이티브 인터페이스의 예
<management-interfaces> ... <native-interface security-realm="HTTPSRealm"> <socket interface="management" port="${jboss.management.native.port:9999}"/> </native-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:9999}"/> </discovery-options> </remote> </domain-controller>
각 서버가 호스트 컨트롤러에 다시 연결하는 방법을 업데이트합니다.
또한 각 서버가 호스트 컨트롤러에 다시 연결하는 방법을 업데이트해야 합니다.
서버 설정 예
<server name="my-server" group="my-server-group"> <ssl ssl-protocol="TLS" trust-manager-algorithm="SunX509" 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
중요또한 각 호스트의 인증서를 도메인 컨트롤러의 신뢰 저장소로 가져와야 합니다.
2.2.11. Cryostat에 대한 원격 액세스 비활성화
jmx
하위 시스템에 대한 원격 액세스를 통해 JDK 및 애플리케이션 관리 작업을 원격으로 트리거할 수 있습니다. JBoss EAP에서 Cryostat에 대한 원격 액세스를 비활성화하려면 jmx
하위 시스템에서 원격 커넥터를 제거합니다.
Remoting Connector 제거
/subsystem=jmx/remoting-connector=jmx/:remove
Cryostat에 대한 자세한 내용은 Red Hat JBoss Enterprise Application Platform 보안 아키텍처 가이드의 Cryostat 섹션을참조하십시오.
2.2.12. JAAS를 사용하여 관리 인터페이스 보안
JAAS는 JBoss EAP에서 보안을 관리하기 위해 사용하는 선언적 보안 API입니다. JAAS 및 선언적 보안에 대한 자세한 내용 및 배경 내용은 Red Hat JBoss Enterprise Application Platform 보안 아키텍처 가이드의 선언적 보안 및 JAAS 섹션을 참조하십시오.
ADMIN_ONLY 모드에서 JBoss EAP 인스턴스를 실행하도록 구성된 경우 JAAS를 사용하여 관리 인터페이스를 보호하는 것은 지원되지 않습니다. ADMIN_ONLY 모드에 대한 자세한 내용은 JBoss EAP 구성 가이드의 ADMIN_ONLY 모드에서 JBoss EAP 실행 섹션을 참조하십시오.
JAAS를 사용하여 관리 인터페이스를 인증하려면 다음 단계를 수행해야 합니다.
보안 도메인을 생성합니다.
이 예에서는 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")])
JAAS 인증을 사용하여 보안 영역을 만듭니다.
/core-service=management/security-realm=SecurityDomainAuthnRealm:add /core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:add(name=UsersLMDomain)
새 보안 영역을 사용하도록
http-interface
관리 인터페이스를 업데이트합니다./core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=SecurityDomainAuthnRealm)
선택 사항: 그룹 멤버십을 할당합니다.
특성
assign-groups
는 보안 영역의 그룹 할당에 보안 도메인의 로드된 사용자 멤버십 정보가 사용되는지 여부를 결정합니다.true
로 설정하면 이 그룹 할당이 RBAC(역할 기반 액세스 제어)에 사용됩니다./core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:write-attribute(name=assign-groups,value=true)
2.2.13. 자동 인증
JBoss EAP의 기본 설치에는 로컬 관리 CLI 사용자에 대한 자동으로 인증 방법이 포함되어 있습니다. 이를 통해 로컬 사용자는 사용자 이름 또는 암호 인증 없이 관리 CLI에 액세스할 수 있습니다. 이 기능은 편의를 위해 활성화되며 인증 없이도 관리 CLI 스크립트를 실행하는 로컬 사용자를 지원합니다. 로컬 구성에 대한 액세스는 일반적으로 사용자에게 고유한 사용자 세부 정보를 추가하거나 보안 검사를 비활성화할 수 있는 유용한 기능으로 간주됩니다.
보안 제어가 필요한 경우 로컬 사용자에 대한 자동 인증의 편의성을 비활성화할 수 있습니다. 이 작업은 구성 파일의 security-realm 섹션에서 로컬 요소를 제거하여 수행할 수 있습니다. 이는 독립 실행형 인스턴스 및 도메인에 모두 적용됩니다.
로컬 요소 제거는 JBoss EAP 인스턴스에 미치는 영향과 해당 구성이 완전히 이해되는 경우에만 수행해야 합니다.
영역에서 자동으로 인증을 제거하려면 다음을 수행합니다.
/core-service=management/security-realm=REALM_NAME/authentication=local:remove
2.2.14. Cryostat 응답 헤더 제거
기본 JBoss EAP undertow
하위 시스템에는 default-host
의 각 HTTP 응답에 추가된 두 개의 응답 헤더가 포함되어 있습니다.
-
JBoss-EAP/7
로 설정된서버
-
x-Powered-By
, is set to Cryostat/1
개발 및 디버깅 목적에 유용할 수 있지만 사용 중인 서버에 대한 정보를 공개하지 않으려면 이러한 헤더를 제거할 수 있습니다.
다음 관리 CLI 명령을 사용하여 default-host
에서 이러한 응답 헤더를 제거합니다.
/subsystem=undertow/server=default-server/host=default-host/filter-ref=server-header:remove /subsystem=undertow/server=default-server/host=default-host/filter-ref=x-powered-by-header:remove reload