Cassandra 네이티브 mTLS 구성

소개

메시지 프로세서, 관리 서버, 라우터와 같은 프라이빗 클라우드용 Edge의 다양한 구성요소는 기본적으로 일반 텍스트 채널을 통해 Cassandra 노드에 연결됩니다. 이러한 채널에서 Cassandra와 주고받는 데이터는 일반 텍스트로 전달됩니다. Apigee mTLS는 Consul 서비스 메시 기반 기능으로, 프라이빗 클라우드용 Edge 클러스터의 구성요소 간 통신에 보안을 추가합니다. Apigee의 이 제품은 클라이언트 구성요소와 Cassandra 간의 통신 채널에 TLS 보안도 추가합니다.

이 도움말에서는 외부 서비스 메시를 사용하지 않고 Cassandra에서 기본적으로 제공되는 기능을 사용하여 상호 TLS (양방향 TLS라고도 함)를 통해 프라이빗 클라우드용 Edge의 클라이언트 구성요소와 Cassandra 간의 통신을 보호하는 Apigee의 새로운 대안 제품을 다룹니다.

기본 mTLS 기능

이 도움말에 설명된 Cassandra와 클라이언트 구성요소 간의 mTLS 사용 설정은 Apache Cassandra에서 기본적으로 제공하는 TLS 기능을 기반으로 합니다. 사용 설정되면 Cassandra에 대한 클라이언트 연결 (CQL 기본 전송 포트 9042)은 연결을 설정하기 전에 클라이언트와 양방향 TLS 핸드셰이크를 실행합니다. 이 양방향 TLS 연결을 위해 Cassandra는 서버 역할을 하고 Cassandra에 연결하는 다양한 클라이언트 (예: edge-message-processor, cqlsh 도구 등)는 클라이언트 역할을 합니다.

양방향 TLS (상호 TLS 또는 mTLS)의 경우 Cassandra와 클라이언트 모두 자체 키 저장소로 설정해야 합니다. 각 Cassandra 노드의 키 저장소에는 자체 키와 인증서가 포함되어야 합니다. 각 클라이언트 애플리케이션의 키 저장소에는 해당 특정 클라이언트의 키와 인증서가 포함되어야 합니다. 상대방의 인증서와 연결된 체인이 포함된 트러스트 저장소를 Cassandra와 클라이언트 모두에 추가해야 합니다. 각 Cassandra 노드의 트러스트 저장소에는 클라이언트의 인증서가 포함되어야 하고 각 클라이언트의 트러스트 저장소에는 모든 Cassandra 노드의 인증서가 포함되어야 합니다. 양방향 TLS 핸드셰이크가 일반적으로 작동하는 방식에 대한 자세한 내용은 Apigee의 양방향 TLS/SSL 도움말을 참고하세요.

인증서 체인

일반적으로 양방향 TLS에서는 서버 인증서, 클라이언트 인증서, 인증서 체인, 키 저장소, 트러스트 저장소를 다양한 방법으로 만들 수 있습니다. Cassandra 및 클라이언트 기본 mTLS에도 동일하게 적용됩니다. 조직에서 일반적으로 프라이빗 클라우드용 Edge 클러스터를 운영하는 방식과 설정할 수 있는 고유한 클라이언트-Cassandra 연결 쌍의 수를 고려하여 Apigee는 이 기능의 키와 인증서를 구성할 때 다음 일반적인 접근 방식을 취할 것을 권장합니다. 실행 가능한 다른 방법도 있지만 아래 방법은 보안과 유지보수 오버헤드의 균형을 잘 제공할 수 있습니다.

  1. 루트에서 서명한 루트 인증서와 중간 키/인증서 쌍을 가져옵니다. 이러한 키와 인증서를 이미 보유하고 있을 수도 있습니다. 그렇지 않은 경우 부록 1의 단계에 따라 자체 서명된 루트 및 중간 인증서와 키를 만들 수 있습니다.

  2. 위의 공통 중간 키/인증서를 사용하여 모든 애플리케이션별 (리프) 키와 인증서에 서명합니다.

클러스터 1개에 공통 중간 키/인증서를 사용하면 모든 Cassandra 및 클라이언트 노드에 공통 트러스트 저장소 (동일한 루트 및 중간 인증서 체인 포함)가 구성됩니다. 모든 Cassandra 노드와 클라이언트 애플리케이션은 공통 중간 키/인증서로 서명된 고유한 리프 키와 인증서를 가져옵니다.

  1. Cassandra 노드 또는 클라이언트 애플리케이션의 리프 인증서를 순환하는 것은 간단합니다.
  2. 중간 또는 루트 인증서를 순환하는 것은 여전히 다소 복잡한 작업이지만 이러한 순환의 빈도는 리프 인증서의 빈도보다 훨씬 낮습니다.

조직의 보안 관행에 따라 여러 프라이빗 클라우드 클러스터에서 공통 루트 및 중간 인증서를 사용할지 결정합니다. 대체 인증서 설정은 부록 2를 참고하세요.

이 도움말의 나머지 단계에서는 위의 키 및 인증서 설계 방법론에 대한 세부정보를 제공합니다.

제한사항 및 주의사항

이 기능에는 다음과 같은 제한사항이 적용됩니다.

  • 클라이언트 구성요소와 Cassandra 간의 기본 mTLS 제품은 apigee-mtls와 호환되지 않습니다. 이 기능을 사용하는 경우 apigee-mtls를 사용할 수 없으며 그 반대의 경우도 마찬가지입니다.
  • 클라이언트 구성요소와 Cassandra 간에 mTLS를 사용 설정하면 클라이언트와 Cassandra 간에 설정되는 연결에 약간의 성능 영향이 있습니다. Cassandra와 클라이언트가 통신을 시작하기 전에 먼저 TLS를 협상해야 하므로 클라이언트 부팅 또는 Cassandra 연결 확장과 같은 작업이 느려질 수 있습니다. 영향은 미미하며 일반적으로 눈에 띄지 않습니다.
  • Cassandra에서 인바운드 클라이언트 연결에 mTLS를 선택적으로 적용할 수 있습니다. 적용을 사용 설정할 수 있지만 Apigee 소프트웨어 업그레이드, TLS 기능 사용 설정/중지, 특정 유형의 인증서 순환과 같은 운영 작업 중에는 사용 중지해야 합니다. 자세한 내용은 작업 및 구성 섹션을 참고하세요.
  • 인증서 관리 및 유지보수는 고객의 책임입니다.
  • 인증서 순환에는 다양한 미묘한 차이가 있습니다. 자세한 내용은 인증서 순환 섹션을 참고하세요.

기본 mTLS 사용 설정

기본 mTLS를 사용 설정하는 것은 아래 설명된 대로 3단계 절차입니다.

  1. 루트 인증서와 중간 키/인증서 쌍을 가져옵니다.
  2. Cassandra 노드 1개의 리프 키/인증서 쌍을 만들고 서명한 후 키 저장소에 저장하고 선택적 mTLS 를 위해 Cassandra를 구성합니다. 각 Cassandra 노드에 대해 한 번에 하나씩 단계를 반복합니다.
  3. 클라이언트 애플리케이션 1개의 리프 키/인증서 쌍을 만들고 서명한 후 키 저장소에 저장하고 mTLS를 위해 클라이언트 애플리케이션을 구성합니다. 각 클라이언트 애플리케이션에 대해 한 번에 하나씩 단계를 반복합니다. 클라이언트 애플리케이션:
    1. edge-management-server
    2. edge-message-processor
    3. edge-router

이러한 단계는 아래에 자세히 설명되어 있습니다.

루트 및 중간 인증서 가져오기

루트에서 서명한 루트 인증서와 중간 키/인증서 쌍을 가져옵니다. 조직의 CA 서명 루트 및 중간 인증서를 사용하거나 자체 서명된 인증서를 만듭니다. 트러스트 저장소에 루트 및 중간 인증서 체인을 저장합니다. 유용한 명령어는 부록 1을 참고하세요. 후속 명령어는 다음 파일에 액세스할 수 있다고 가정합니다.

  • intermediate.key - 리프 인증서 서명을 위한 중간 인증서의 키 파일
  • intermediate-cert.pem- 중간 인증서

Cassandra 노드 구성

  1. Cassandra 노드 하나를 선택합니다.
  2. 리프 키와 인증서 쌍을 생성하고 중간 인증서로 서명합니다. 키와 서명된 인증서를 키 저장소에 저장합니다. 예를 들어 다음과 같습니다. 
    
# Generate Leaf key and csr
openssl req -newkey rsa:2048 -keyout cass-node1.key -out cass-node1-req.pem -sha256 -days 365 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=yourip/emailAddress=cassnode1@yourorg.com"

# leaf cert signed by intermediate
openssl x509 -req -in cass-node1-req.pem -CAkey intermediate.key -CA intermediate-cert.pem -days 365 -CAcreateserial -out cass-node1-cert.pem

# keystore packaging leaf key and cert
openssl pkcs12 -export -clcerts -in cass-node1-cert.pem -inkey cass-node1.key -out cass-node1-keystore.pfx -name nativemtls -password pass:keystorepass

    키 저장소 및 트러스트 저장소 파일을 노드의 특정 위치에 배치하고 apigee 사용자가 액세스할 수 있는지 확인합니다. 

    cp cass-node1-keystore.pfx /opt/apigee/customer/application/
cp truststore.pfx /opt/apigee/customer/application/

chown apigee:apigee /opt/apigee/customer/application/cass-node1-keystore.pfx
chown apigee:apigee /opt/apigee/customer/application/truststore.pfx

  3. /opt/apigee/customer/application/cassandra.properties 파일을 만들거나 수정합니다. 이 파일에 다음 콘텐츠를 추가합니다. 
    ### Enable Cassandra TLS on CQL connections
conf_cassandra_client_encryption_enabled=true

### Optional TLS - true or false
conf_cassandra_client_encryption_optional=true

### Keystore details
conf_cassandra_client_encryption_keystore=/opt/apigee/customer/application/cass-node1-keystore.pfx
conf_cassandra_client_encryption_keystore_password=keystorepass
conf_cassandra_server_encryption_store_type=PKCS12

### Whether to enable 2-way TLS (or mTLS) - true or false
conf_cassandra_client_encryption_require_client_auth=true

### When 2-way TLS is enabled, client certificate details need to be provided via a truststore
conf_cassandra_client_encryption_truststore=/opt/apigee/customer/application/truststore.pfx
conf_cassandra_client_encryption_truststore_password=trustpass
conf_cassandra_client_encryption_store_type=PKCS12

    파일이 apigee 사용자가 소유하고 읽을 수 있는지 확인합니다.

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  4. Cassandra 노드를 구성하고 다시 시작합니다. 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  5. 각 Cassandra 노드에서 한 번에 하나씩 위의 단계를 반복합니다.

클라이언트 애플리케이션 구성

이 섹션은 Cassandra에 연결하는 다음 클라이언트 구성요소에 적용됩니다.

  • edge-management-server
  • edge-message-processor
  • edge-router

  1. 클라이언트 구성요소 하나를 선택합니다.
  2. 리프 키와 인증서 쌍을 생성하고 중간 인증서로 서명합니다. 키와 서명된 인증서를 키 저장소에 저장합니다. 예를 들어 다음과 같습니다. 
    
# Generate Leaf key and csr
openssl req -newkey rsa:2048 -keyout mgmt-node1.key -out mgmt-node1-req.pem -sha256 -days 365 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=yourip/emailAddress=mgmtnode1@yourorg.com"

# leaf cert signed by intermediate
openssl x509 -req -in mgmt-node1-req.pem -CAkey intermediate.key -CA intermediate-cert.pem -days 365 -CAcreateserial -out mgmt-node1-cert.pem

# keystore packaging leaf key and cert
openssl pkcs12 -export -clcerts -in mgmt-node1-cert.pem -inkey mgmt-node1.key -out mgmt-node1-keystore.pfx -name nativemtls -password pass:keystorepass

    키 저장소 및 트러스트 저장소 파일을 노드의 특정 위치에 배치하고 apigee 사용자가 액세스할 수 있는지 확인합니다.

    cp mgmt-node1-keystore.pfx /opt/apigee/customer/application/
cp truststore.pfx /opt/apigee/customer/application/

chown apigee:apigee /opt/apigee/customer/application/mgmt-node1-keystore.pfx
chown apigee:apigee /opt/apigee/customer/application/truststore.pfx

  3. 구성 중인 애플리케이션을 기반으로 구성 파일을 만들고 수정합니다.
    애플리케이션 구성 파일
    관리 서버 /opt/apigee/customer/application/management-server.properties
    관리 프로세서 /opt/apigee/customer/application/message-processor.properties
    라우터 /opt/apigee/customer/application/router.properties

    파일에 다음 구성을 추가합니다. 

    ### Enable TLS on CQL connections
conf_cassandra_sslconfig.enable.tls=true
conf_cassandra_sslconfig.enable.mtls=true

### Keystore Details
conf_cassandra_sslconfig.keystore.path=/opt/apigee/customer/application/mgmt-node1-keystore.pfx
conf_cassandra_sslconfig.keystore.password=keystorepass
conf_cassandra_sslconfig.keystore.type=PKCS12

### Truststore Details
conf_cassandra_sslconfig.truststore.path=/opt/apigee/customer/application/truststore.pfx
conf_cassandra_sslconfig.truststore.password=trustpass
conf_cassandra_sslconfig.truststore.type=PKCS12

    구성 파일이 apigee 사용자가 소유하고 읽을 수 있는지 확인합니다. 

    chown apigee:apigee configuration file

### Example:
chown apigee:apigee /opt/apigee/customer/application/management-server.properties

  4. 클라이언트 애플리케이션을 다시 시작합니다. 
    # Configure and restart service:
apigee-service component configure
apigee-service component restart
# Example, to configure and restart message processor application
apigee-service edge-message-processor configure
apigee-service edge-message-processor restart
  5. 적절한 애플리케이션의 시스템 로그에서 아래 줄을 따라 로그를 찾아 클라이언트 애플리케이션에서 SSL이 올바르게 구성되었는지 확인할 수 있습니다.

    SSL 옵션이 Cassandra 연결에 추가됨

  6. 각 클라이언트 애플리케이션에 대해 한 번에 하나씩 위의 단계를 반복합니다.

작업 및 구성

mTLS 적용

Cassandra에서 mTLS가 적용되지 않으면 Cassandra는 클라이언트의 일반 텍스트 연결 또는 양방향 TLS 핸드셰이크를 성공적으로 실행할 수 있는 클라이언트를 허용합니다. mTLS 적용이 작동하려면 먼저 Cassandra에서 mTLS를 구성해야 합니다. 아래 단계에 따라 Cassandra에서 mTLS 적용을 설정할 수 있습니다.

  1. Cassandra 노드 하나를 선택합니다.
  2. /opt/apigee/customer/application/cassandra.properties 파일을 만들거나 수정합니다. 이 파일에 다음 속성을 추가하거나 수정합니다. 
    ### Optional TLS - true or false
conf_cassandra_client_encryption_optional=false

    파일이 apigee 사용자가 소유하고 읽을 수 있는지 확인합니다.

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  3. Cassandra 노드를 구성하고 다시 시작합니다. 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  4. 각 Cassandra 노드에서 한 번에 하나씩 위의 단계를 반복합니다.

Cassandra에서 mTLS가 적용되면 표준 Cassandra 쿼리 도구 cqlsh가 Cassandra에 직접 연결할 수 없습니다. SSL용 cqlsh를 구성하려면 새 리프 키와 인증서 (클라이언트 애플리케이션의 리프 키 및 인증서와 유사)를 생성하고 다음을 실행합니다.

  1. $HOME/.cassandra/cqlshrc 파일을 만들거나 수정합니다.
  2. 파일에 다음 콘텐츠를 추가합니다. 
    [ssl]
certfile = /home/admin-user/certs/inter-root.pem
validate = false
userkey = /home/admin-user/certs/cqlsh1.key
usercert = /home/admin-user/certs/cqlsh1-cert.pem
    • certfile - 루트 및 중간 인증서 체인이 포함된 인증서 파일
    • userkey - cqlsh에서 사용할 클라이언트 키. 중간 인증서로 생성하고 서명할 수 있는 리프 키/인증서 쌍이어야 합니다.
    • usercert - cqlsh에서 사용할 클라이언트 인증서. 중간 인증서로 생성하고 서명할 수 있는 리프 키/인증서여야 합니다.
  3. --ssl 인수를 제공하면서 평소와 같이 cqlsh 명령어를 실행합니다. 예를 들어 다음과 같습니다. 
    $  /opt/apigee/apigee-cassandra/bin/cqlsh --ssl X.X.X.X
Connected to Apigee at X.X.X.X:9042
[cqlsh 6.0.0 | Cassandra 4.0.13 | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cqlsh>

Cassandra에서 mTLS 적용 중지

Cassandra에서 mTLS 적용을 중지하려면 아래 단계를 따르세요.

  1. Cassandra 노드 하나를 선택합니다.
  2. /opt/apigee/customer/application/cassandra.properties 파일을 만들거나 수정합니다. 이 파일에 다음 속성을 추가하거나 수정합니다. 
    ### Optional TLS - true or false
conf_cassandra_client_encryption_optional=true

    파일이 apigee 사용자가 소유하고 읽을 수 있는지 확인합니다.

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  3. Cassandra 노드를 구성하고 다시 시작합니다. 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  4. 각 Cassandra 노드에서 한 번에 하나씩 위의 단계를 반복합니다.

기본 mTLS 중지

기본 mTLS를 중지하는 것은 기본 mTLS를 사용 설정하는 것과 마찬가지로 여러 단계로 이루어진 프로세스입니다. 대략적인 단계는 다음과 같습니다.

  1. Cassandra에서 mTLS 적용 중지 (적용된 경우)
  2. 다음 클라이언트 애플리케이션의 모든 노드에서 mTLS를 하나씩 중지합니다.
    • edge-management-server
    • edge-message-processor
    • edge-router
    1. 구성 중인 애플리케이션을 기반으로 구성 파일을 만들고 수정합니다.
      애플리케이션 구성 파일
      관리 서버 /opt/apigee/customer/application/management-server.properties
      관리 프로세서 /opt/apigee/customer/application/message-processor.properties
      라우터 /opt/apigee/customer/application/router.properties
    2. 구성 파일에 다음 속성을 추가하거나 수정합니다. 
      ### TLS on CQL connections
conf_cassandra_sslconfig.enable.tls=false
conf_cassandra_sslconfig.enable.mtls=false
    3. 구성 파일이 apigee 사용자가 소유하고 읽을 수 있는지 확인합니다. 
      chown apigee:apigee configuration file

### Example:
chown apigee:apigee /opt/apigee/customer/application/management-server.properties
    4. 클라이언트 애플리케이션을 다시 시작합니다. 
      
# Configure and restart service:
apigee-service component configure
apigee-service component restart

# Example, to configure and restart message processor application
apigee-service edge-message-processor configure
apigee-service edge-message-processor restart
    5. 각 클라이언트 애플리케이션에 대해 한 번에 하나씩 a~d단계를 반복합니다.
  3. 모든 Cassandra 노드에서 mTLS를 하나씩 중지합니다.
    1. Cassandra 노드 하나를 선택합니다.
    2. /opt/apigee/customer/application/cassandra.properties 파일을 만들거나 수정합니다. 이 파일에 다음 속성을 추가하거나 수정합니다. 
      ### Cassandra TLS on CQL connections
conf_cassandra_client_encryption_enabled=false

      파일이 apigee 사용자가 소유하고 읽을 수 있는지 확인합니다.

      chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    3. Cassandra 노드를 구성하고 다시 시작합니다.
      4. apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
    4. 각 Cassandra 노드에 대해 한 번에 하나씩 a~c단계를 반복합니다.

인증서 순환

리프 인증서만 순환 (동일한 중간 및 루트 인증서 유지)

클라이언트 애플리케이션 구성과 유사한 단계를 따를 수 있습니다.

  1. 동일한 중간 키/인증서를 사용하여 애플리케이션의 새 리프 키/인증서를 생성합니다.
  2. 비밀번호 및 키 저장소 유형과 함께 애플리케이션에서 새 리프 키/인증서의 경로를 구성합니다.
  3. 애플리케이션을 다시 시작합니다.
루트 또는 중간 인증서 순환

중간 또는 루트 인증서를 순환하려는 경우 여러 단계로 이루어진 프로세스로 실행하는 것이 좋습니다.

  1. 클러스터에서 Cassandra 기본 mTLS를 중지합니다.
  2. 새 루트 및 중간 인증서를 사용하여 새 리프 또는 애플리케이션 인증서를 생성합니다.
  3. 새 키 및 인증서 세트를 사용하여 Cassandra 기본 mTLS를 사용 설정하는 단계를 따릅니다.

일반 Apigee 작업

Apigee 소프트웨어 업그레이드, Cassandra 노드 추가 또는 삭제, 데이터 센터 추가 또는 삭제, Cassandra 인증 사용 설정 또는 중지와 같은 일반적인 Apigee 작업을 실행하려면 Cassandra에서 mTLS가 적용되지 않아야 합니다. mTLS를 적용한 경우 적용을 중지하기 전에 이러한 작업을 진행합니다.

부록 1

이 부록의 단계에 따라 자체 서명된 루트 및 중간 키/인증서 쌍을 생성하고 이 인증서 체인을 트러스트 저장소에 추가할 수 있습니다.

자체 서명된 루트 및 중간 인증서 생성

# Create self-signed root key and cert
openssl req -x509 -newkey rsa:2048 -keyout root.key -out root-cert.pem -sha256 -days 3650 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=root.yourorg.com/emailAddress=apigeeroot@yourorg.com"

# Create intermediate key and cert (signed by root)
openssl req -newkey rsa:2048 -keyout intermediate.key -out intermediate-req.pem -sha256 -days 3650 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=inter.yourorg.com/emailAddress=apigeeinter@yourorg.com"

openssl x509 -req -in intermediate-req.pem -CAkey root.key -CA root-cert.pem -days 3650 -CAcreateserial -out intermediate-cert.pem

트러스트 저장소 생성

# Merge root and intermediate cert into 1 file
cat intermediate-cert.pem > inter-root.pem
cat root-cert.pem >> inter-root.pem

# Create truststore to be used everywhere
keytool -keystore truststore.pfx -storetype PKCS12 -importcert -file inter-root.pem -keypass trustpass -storepass trustpass -alias nativemtls -noprompt

부록 2: 대체 인증서 체인 설정

이 도움말에서는 보안과 작업 편의성의 균형을 맞추는 특정 인증서 체인 설정을 권장하지만 대체 설정도 있으며 아래에 설명되어 있습니다. 대부분의 일반적인 원칙은 다음과 같은 다른 방법론에도 적용됩니다.

  1. 모든 Cassandra 노드 또는 클라이언트 애플리케이션에 직접 리프 키와 인증서가 있음 (서명 루트 또는 중간 인증서 없음). 이렇게 하면 인증서 순환이 복잡해질 수 있습니다.
  2. 다양한 사용 사례에 여러 루트 및 중간 세트가 있음. 예를 들어 Cassandra 노드에는 Cassandra의 모든 리프 인증서가 서명되는 루트/중간 인증서 세트가 1개 있습니다. 마찬가지로 모든 클라이언트 애플리케이션에는 애플리케이션 리프 인증서 서명을 위한 별도의 루트/중간 세트가 하나 있을 수 있습니다. 이러한 설정은 실행 가능하지만 루트/중간 인증서 체인을 적절한 트러스트 저장소에 추가해야 합니다. 이 예에서 Cassandra의 트러스트 저장소에는 클라이언트의 루트/중간 인증서가 포함되어야 하고 클라이언트 애플리케이션에는 트러스트 저장소에 Cassandra 노드의 루트/중간 체인이 있어야 합니다.
  3. 위와 마찬가지로 리전별로 여러 루트 및 중간 인증서 세트 를 사용할 수 있지만 모든 리전의 모든 클라이언트와 모든 리전의 모든 서버는 구성된 트러스트 저장소에 모두 추가하여 모든 루트 및 중간 체인을 인식해야 합니다.