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를 활성화하는 단계를 수행하는 동안 명시적으로 지시하지 않는 한 구성을 다시 로드하지 마십시오. 이렇게 하면 관리 인터페이스에서 잠길 수 있습니다.

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

    참고

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

    다음을 사용하여 매개 변수의 예제 값(예: 별칭,keypass,keystore,storepassdname )을 해당 환경에 대한 올바른 값으로 교체하여 키 저장소를 생성합니다.

    참고

    매개변수 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

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

    1. 독립 실행형 서버 실행.

      관리 인터페이스가 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)
    2. 관리형 도메인 실행

      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)
  3. 선택 사항: 사용자 지정 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}"
        }
    }

  4. 새 보안 영역을 만듭니다. 이 예에서 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
    중요

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

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

    /core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=ManagementRealmHTTPS)
  6. 키 저장소를 사용하도록 관리 인터페이스를 구성합니다.

    다음 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 을 업데이트하려면 다음 단계로 이동합니다.

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

    관리 CLI를 사용하여 관리 작업을 수행하는 경우 EAP_HOME/bin/jboss-cli.xml 파일을 다음과 같이 변경해야 합니다.

    • < default-protocol >의 값을 https-remoting 으로 업데이트합니다.
    • &lt ;default-controller >에서 < protocol >의 값을 https-remoting 으로 업데이트합니다.
    • &lt ;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을 명시적으로 비활성화할 것을 권장합니다.

  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-interfacesecurity-realm 을 새 CertificateRealm으로 변경합니다.

    /core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=CertificateRealm)
  6. 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 가이드를 참조하십시오.

  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:add( \
    socket-binding=https, security-realm=HTTPSRealm)
    
    run-batch
    주의

    Red Hat은 영향을 받는 모든 패키지에서 TLSv1.1 또는 TLSv1.2를 사용하도록 SSLv2, SSLv3 및 TLSv1.0을 명시적으로 비활성화할 것을 권장합니다.

  2. 변경 사항을 적용하려면 서버를 다시 로드합니다.

    reload

2.2.6. 2단계 SSL/TLS for Applications 설정

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

  1. 클라이언트와 서버 둘 다에 대한 저장소를 생성
  2. 클라이언트와 서버 모두에 대한 인증서 내보내기
  3. 인증서를 반대 신뢰 저장소로 가져옵니다.
  4. 서버의 키 저장소 및 신뢰 저장소를 사용하는 서버에서 보안 영역(예: CertificateRealm )을 정의합니다.
  5. 보안 영역을 사용하도록 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.keyStorejavax.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 데이터베이스 구성

  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

    참고

    jboss 사용자는 예제일 뿐입니다. JBoss EAP 실행을 위해 사용하려는 운영 체제의 사용자로 교체해야 합니다.

  2. 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 로 설정합니다.

  3. $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로 증가해야 합니다.

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

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

    이 시점에서 일부 NSS 공유 오브젝트에 대한 라이브러리 서명을 다시 생성해야 하는 경우 보안 라이브러리 오류가 발생할 수 있습니다.

  5. 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" 오류가 표시될 수 있습니다.

  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

2.2.8.2. Cryostat 구성

SSL/TLS에 대한 FIPS 140-2 호환 암호화 설정을 완료하려면 다음을 수행합니다.

  1. 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 설정에서 참조하십시오.

  2. 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")

  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])

  4. 다음 명령을 실행하여 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 JCEFIPSNIST 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을 명시적으로 비활성화할 것을 권장합니다.

  1. 마스터 도메인 컨트롤러에서 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>

  2. 각 호스트 컨트롤러에 SSL/TLS 보안 영역을 생성합니다.

    인증을 위해 SSL/TLS 신뢰 저장소를 사용하여 보안 영역을 생성해야 합니다.

    보안의 예

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

    참고

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

  3. 마스터 도메인 컨트롤러에서 네이티브 인터페이스를 보호합니다.

    방금 생성한 보안 영역으로 마스터 도메인 컨트롤러의 기본 인터페이스가 보호되도록 해야 합니다.

    네이티브 인터페이스의 예

    <management-interfaces>
      ...
      <native-interface security-realm="HTTPSRealm">
        <socket interface="management" port="${jboss.management.native.port:9999}"/>
       </native-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:9999}"/>
        </discovery-options>
      </remote>
    </domain-controller>

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

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

    서버 설정 예

    <server name="my-server" group="my-server-group">
      <ssl ssl-protocol="TLS" trust-manager-algorithm="SunX509" 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
    중요

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

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를 사용하여 관리 인터페이스를 인증하려면 다음 단계를 수행해야 합니다.

  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)

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 Cryo stat/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
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat, Inc.