TLS 구성 옵션

이 페이지는 Apigee 및 Apigee Hybrid에 적용됩니다.

Apigee Edge 문서 보기

이 섹션에서는 프록시에서 대상으로 전송되는 트래픽에 대해 TLS를 구성하는 방법을 보여줍니다.

대상 엔드포인트 또는 대상 서버의 TLS 옵션 설정 정보

타겟은 아래와 같은 XML 객체로 나타낼 수 있습니다.

<HTTPTargetConnection>
    <Properties/>
    <URL>https:myTargetAddress</URL>
    <SSLInfo>
        <Enabled>true</Enabled>
        <Enforce>true</Enforce>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTruststoreRef</TrustStore>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
    </SSLInfo>
</HTTPTargetConnection>

TLS를 구성하기 위해 수정하는 대상 엔드포인트 구성의 영역은 <SSLInfo> 태그로 정의됩니다. 동일한 <SSLInfo> 태그를 사용하여 대상 엔드포인트 또는 대상 서버를 구성합니다.

<SSLInfo>의 하위 요소에 대한 자세한 내용은 TLS/SSL TargetEndpoint 구성을 참조하세요.

다음 표에서는 <SSLInfo> 태그에서 사용되는 TLS 구성 요소를 설명합니다.

요소	설명
<Enabled>	Apigee와 API 클라이언트 간 또는 Apigee와 대상 백엔드 간의 단방향 TLS를 사용 설정합니다.
<Enforce>	Apigee와 대상 백엔드 간에 엄격한 SSL을 적용합니다. true로 설정하면 잘못된 인증서, 만료된 인증서, 자체 서명된 인증서, 호스트 이름이 일치하지 않는 인증서, 신뢰할 수 없는 루트가 있는 인증서에 대한 연결이 실패합니다. 4xx 또는 5xx의 실패 코드가 반환됩니다. 설정하지 않거나 false로 설정하면 문제가 있는 인증서가 있는 대상 백엔드에 대한 연결 결과는 <IgnoreValidationErrors> 설정에 따라 달라집니다(아래 참조). <IgnoreValidationErrors>가 true로 설정된 경우 특정 조건에서 성공 응답(2xx)이 발생할 수 있습니다.
<ClientAuthEnabled>	Apigee와 API 클라이언트 간 또는 Apigee와 대상 백엔드 간의 양방향 TLS(상호 TLS 또는 mTLS라고도 함)를 사용 설정합니다. 양방향 TLS를 사용 설정하려면 일반적으로 Apigee와 트러스트 저장소에 트러스트 저장소를 설정해야 합니다.
<KeyStore>	키 저장소입니다.
<KeyAlias>	키 저장소에 인증서와 비공개 키를 업로드할 때 지정된 별칭입니다.
<TrustStore>	트러스트 저장소입니다.
<IgnoreValidationErrors>	true인 경우 Apigee는 TLS 인증서 오류를 무시합니다. 기본값은 false입니다. 백엔드 시스템이 SNI를 사용하고 호스트 이름과 일치하지 않는 주체 고유 이름(DN)이 있는 인증서를 반환하면 오류를 무시할 수 없으며 연결이 실패합니다. 참고: <Enforce>가 true로 설정된 경우 <IgnoreValidationErrors> 값이 무시됩니다.

<KeyStore> 및 <TrustStore> 요소 설정 정보

위 예시에서 키 저장소 및 트러스트 저장소는 참조를 사용하여 다음 형식으로 지정됩니다.

<KeyStore>ref://myKeystoreRef</KeyStore>
<TrustStore>ref://myTruststoreRef</TrustStore>

Apigee에서는 항상 키 저장소와 트러스트 저장소에 대한 참조를 사용할 것을 적극 권장합니다. 참조는 키 저장소 이름을 직접 지정하는 대신 키 저장소 또는 트러스트 저장소의 이름이 포함되는 변수입니다. 예를 들면 다음과 같습니다.

• myKeystoreRef는 키 저장소 이름이 포함된 참조입니다. 이 예시에서 키 저장소 이름은 myKeystore입니다.
• myTruststoreRef는 트러스트 저장소 이름이 포함된 참조입니다. 이 예시에서 트러스트 저장소의 이름은 myTruststore입니다.

인증서가 만료되면 대상 엔드포인트/대상 서버를 업데이트하여 새 인증서가 포함된 키 저장소 또는 트러스트 저장소를 지정해야 합니다. 참조의 장점은 대상 엔드포인트/대상 서버 자체를 수정할 필요 없이 참조 값을 수정하여 키 저장소 또는 트러스트 저장소를 변경할 수 있다는 것입니다.

참조의 값을 변경할 때는 Apigee 지원팀에 문의할 필요가 없습니다.

키 저장소 이름과 트러스트 저장소 이름을 직접 지정할 수도 있습니다.

<KeyStore>myKeystore</KeyStore>
<TrustStore>myTruststore</TrustStore>

키 저장소 또는 트러스트 저장소의 이름을 직접 지정할 경우 Apigee 지원팀에 문의해야 합니다.

세 번째 옵션은 흐름 변수를 사용하는 것입니다.

<KeyStore>{ssl.keystore}</KeyStore>
<TrustStore>{ssl.truststore}</TrustStore>

흐름 변수를 사용하면 참조와 같이 키 저장소 또는 트러스트 저장소를 업데이트할 수 있습니다. 자세한 내용은 흐름 변수를 사용하여 TLS/SSL 값을 동적으로 설정을 참조하세요.

TLS 구성 정보

유료 및 평가 계정 둘 다의 모든 Apigee 고객은 대상 엔드포인트/대상 서버 구성을 완전히 제어할 수 있습니다. 또한 유료 Apigee 고객은 TLS 속성을 완전히 제어할 수 있습니다.

만료된 인증서 처리

TLS 인증서가 만료되거나 인증서가 더 이상 유효하지 않도록 시스템 구성이 변경되면 인증서를 업데이트해야 합니다. 대상 엔드포인트/대상 서버의 TLS를 구성하는 경우 구성을 수행하기 전에 해당 업데이트를 수행할 방법을 결정해야 합니다.

참고: 새 인증서를 추가하기 위해 기존 키 저장소 또는 트러스트 저장소를 업데이트할 수 없습니다. 인증서를 업데이트할 때 새 키 저장소/트러스트 저장소를 만들어야 합니다. 일반적으로 이전 키 저장소/트러스트 저장소의 인증서가 만료되기 전에 새 키 저장소/트러스트 저장소를 만들고 새 인증서를 업로드합니다. 이렇게 하면 새로운 키 저장소/트러스트 저장소를 테스트하고 문제가 발생하면 이전 키 저장소/트러스트 저장소로 롤백할 수 있습니다.

인증서 만료 시기

Apigee에서는 인증서를 다음 두 위치 중 하나에 저장합니다.

• 키 저장소 - TLS 핸드셰이크 중에 항목을 식별하는 데 사용되는 TLS 인증서와 비공개 키를 포함합니다.
• 트러스트 저장소 - 클라이언트에 제공된 TLS 서버 인증서의 유효성을 검사하는 데 사용되는 TLS 클라이언트의 신뢰할 수 있는 인증서를 포함합니다. 이러한 인증서는 일반적으로 자체 서명 인증서, 신뢰할 수 있는 CA에서 서명한 인증서 또는 양방향 TLS(상호 TLS 또는 mTLS라고도 함)의 일부로 사용되는 인증서입니다.

키 저장소의 인증서가 만료되고 키 저장소 참조를 사용하는 경우 새 인증서를 키 저장소에 업로드할 수 없습니다. 대신 다음을 수행합니다.

1. 새 키 저장소를 생성합니다.
2. 이전 키 저장소와 동일한 별칭 이름을 사용하여 새 키 저장소에 새 인증서를 업로드합니다.
3. 새 키 저장소를 사용하도록 대상 서버/대상 엔드포인트의 참조를 업데이트합니다.

트러스트 저장소의 인증서가 만료되고 트러스트 저장소에 대한 참조를 사용하는 경우 다음을 수행합니다.

1. 새 트러스트 저장소를 만듭니다.
2. 새 인증서를 새 트러스트 저장소에 업로드합니다. 별칭 이름은 트러스트 저장소에서 중요하지 않습니다. 참고 인증서가 체인의 일부인 경우 모든 인증서가 포함된 단일 파일을 만들어 해당 파일을 단일 별칭으로 업로드하거나, 각 인증서에 서로 다른 별칭을 사용하여 체인의 모든 인증서를 트러스트 저장소에 업로드 합니다.
3. 새 트러스트 저장소를 사용하려면 대상 서버/대상 엔드포인트의 참조를 업데이트합니다.

만료된 인증서 업데이트 방법 요약

대상 엔드포인트/대상 서버에서 키 저장소 및 트러스트 저장소의 이름을 지정하는 데 사용하는 방법은 인증서 업데이트 수행 방법을 결정합니다. 이 옵션은 다음과 같습니다.

• 참조
• 직접 이름
• 흐름 변수

다음 표에 설명된 것처럼 이러한 각 방법이 업데이트 프로세스에 미치는 영향은 서로 다릅니다.

구성 유형	인증서 업데이트/교체 방법	사용량
참조(권장)	키 저장소의 경우 새 이름과 이전 별칭과 동일한 이름으로 새 키 저장소를 만듭니다. 트러스트 저장소의 경우 새 이름으로 트러스트 저장소를 만듭니다.	키 저장소 또는 트러스트 저장소에 대한 참조를 업데이트합니다. Apigee 지원팀에 문의할 필요가 없습니다.
흐름 변수	키 저장소의 경우 새 이름 및 동일한 이름 또는 새 이름의 별칭으로 새 키 저장소를 만듭니다. 트러스트 저장소의 경우 새 이름으로 트러스트 저장소를 만듭니다.	각 요청에서 업데이트된 흐름 변수를 새 키 저장소, 별칭 또는 트러스트 저장소의 이름으로 전달합니다. Apigee 지원팀에 문의할 필요가 없습니다.
직접성	새 키 저장소, 별칭, 트러스트 저장소를 만듭니다.	프록시를 다시 배포합니다.
직접성	키 저장소 또는 트러스트 저장소를 삭제하고 동일한 이름으로 다시 생성합니다.	새 키 저장소와 별칭이 설정될 때까지 API 요청이 실패합니다. 키 저장소가 Apigee와 백엔드 서비스 간의 양방향 TLS(상호 TLS 또는 mTLS라고도 함)에 사용되는 경우 Apigee 지원팀에 문의하여 메시지 프로세서를 다시 시작합니다.
직접	트러스트 저장소의 경우에만 트러스트 저장소에 새 인증서를 업로드합니다.	메시지 프로세서를 다시 시작하려면 Apigee 지원팀에 문의하세요.