TLS/SSL 정보

Apigee Edge 문서를 보고 있습니다.
Apigee X 문서로 이동하세요. info

전송 계층 보안(TLS)은 전신인 보안 소켓 레이어(SSL)가 웹 서버와 웹 클라이언트(예: 브라우저 또는 앱) 간에 암호화된 링크를 설정하는 표준 보안 기술입니다. 암호화된 링크는 서버와 클라이언트 간에 전달되는 모든 데이터가 비공개로 유지되도록 합니다. TLS를 사용하기 위해 클라이언트는 암호화되지 않은 HTTP 프로토콜 대신 암호화된 HTTPS 프로토콜을 사용하여 서버에 보안 요청을 합니다.

Edge는 클라우드 및 온프레미스 배포 모두에서 단방향 TLS와 양방향 TLS를 지원합니다 (지원되는 TLS 버전은 지원되는 소프트웨어 및 지원되는 버전 참고). 단방향 TLS를 사용하면 TLS 클라이언트가 TLS 서버의 ID를 확인할 수 있습니다. 예를 들어 Android 휴대전화 (클라이언트)에서 실행되는 앱은 Edge API (서버)의 ID를 확인할 수 있습니다.

Apigee는 양방향 또는 클라이언트 TLS를 사용하여 더 강력한 형태의 인증도 지원합니다. 일반적으로 양방향 TLS를 구현하여 엔드 투 엔드 보안을 강화하고 클라이언트 스푸핑이나 중간자 공격과 같은 클라이언트 공격으로부터 데이터를 보호합니다. 양방향 TLS에서는 클라이언트가 서버의 ID를 확인한 후 서버가 클라이언트의 ID를 확인합니다.

TLS 용어

TLS를 구성하기 전에 다음 중요한 용어와 개념을 숙지해야 합니다.

용어	정의
CA	인증 기관입니다. 인증서를 발급하고 인증서의 진위 여부를 검증하는 데 사용되는 신뢰할 수 있는 기관(예: Symantec 또는 VeriSign)입니다. 자체 서명 인증서라고 하는 한 유형의 인증서에는 CA가 필요하지 않습니다.
인증서 체인	CA의 루트 비공개 키로 서명된 인증서가 없는 경우가 많습니다. 대신 체인을 형성하는 하나 이상의 중간 인증서와 함께 인증서가 있습니다. 체인의 마지막 중간 인증서는 일반적으로 CA의 루트 비공개 키로 서명됩니다.
CSR	인증서 서명 요청입니다. CSR은 비공개 키를 기반으로 TLS 서버에서 생성된 파일입니다. CSR에는 공개 키와 조직 이름, 위치, 도메인 이름과 같은 기타 정보가 포함되어 있습니다. CA는 CSR에 서명하여 TLS 인증서를 만듭니다. 일반적으로 인증서가 만료되었고 갱신하려는 경우 CSR을 생성합니다.
DER	고유한 인코딩 규칙입니다. DER 형식은 ASCII PEM 형식 대신 인증서의 바이너리 형식입니다. 파일 확장자가 .der인 경우도 있지만 파일 확장자가 .cer인 경우가 많습니다. DER .cer 파일과 PEM .cer 파일의 차이점을 알 수 있는 유일한 방법은 텍스트 편집기에서 파일을 열고 BEGIN 및 END 문을 찾는 것입니다. 모든 유형의 인증서와 비공개 키는 DER 형식으로 인코딩할 수 있습니다. DER은 일반적으로 Java 플랫폼에서 사용됩니다.
키 별칭	키 별칭은 키 저장소에서 키 저장소 항목 (TLS 인증서 및 해당 비공개 키)을 고유하게 식별합니다. Apigee Edge에서는 UI 또는 API를 사용하여 인증서/키를 키 저장소에 업로드할 때 KeyAlias를 alias라고 합니다.
키 저장소	키 저장소는 클라이언트와 서버 간의 TLS 핸드셰이크 중에 항목을 식별하는 데 사용되는 하나 이상의 TLS 인증서와 해당 비공개 키를 포함하는 저장소입니다. 상위 연결에서 라우터는 서버 역할을 하며 인증서는 Apigee Edge의 키 저장소에 저장됩니다. 다운스트림 연결에서 메시지 프로세서는 클라이언트로 작동하고 백엔드 서버는 서버로 작동합니다. 클라이언트 인증서와 비공개 키는 Apigee Edge의 키 저장소에 저장됩니다.
P7B	PKCS #7 또는 P7B 형식은 일반적으로 Base64 ASCII 형식으로 저장되며 파일 확장자는 .p7b 또는 .p7c입니다. P7B 인증서에는 -----BEGIN PKCS7----- 및 -----END PKCS7----- 문이 포함됩니다. P7B 파일에는 인증서와 체인 인증서만 포함되며 비공개 키는 포함되지 않습니다.
PEM	개인 정보 보호 강화 메일 (PEM) 형식은 바이너리 고유한 인코딩 규칙 (DER) 형식의 Base64 인코딩인 텍스트 기반 ASCII 형식입니다. PEM 인증서는 텍스트 편집기에서 열 수 있으며 실제 인증서 콘텐츠는 -----BEGIN CERTIFICATE----- 및 -----END CERTIFICATE----- 문장 사이에 구분됩니다. 인증서, 인증서 체인 또는 비공개 키를 저장하기 위한 X.509 형식을 준수합니다. 인증서 또는 비공개 키가 PEM 파일로 정의되지 않은 경우 OpenSSL과 같은 유틸리티를 사용하여 PEM 파일로 변환할 수 있습니다.
PKCS #12/PFX	PKCS #12 또는 PFX 형식은 서버 인증서, 중간 인증서, 비공개 키를 하나의 암호화 가능한 파일에 저장하는 바이너리 형식입니다. PFX 파일에는 일반적으로 .pfx 및 .p12와 같은 확장자가 있습니다. PFX 파일은 일반적으로 Windows 머신에서 인증서와 비공개 키를 가져오고 내보내는 데 사용됩니다.
비공개 키	TLS 서버에서 데이터를 복호화하는 데 사용됩니다. TLS 서버만 비공개 키를 보유하며 TLS 클라이언트와 공유되지 않습니다.
공개 키	TLS 클라이언트에서 TLS 서버로 전송되는 데이터를 암호화하는 데 사용됩니다. 공개 키가 인증서에 포함됩니다. 모든 TLS 클라이언트에는 서버의 공개 키 사본이 있습니다.
참조	참조는 키 저장소에 간접 참조 수준을 제공하므로 동일한 참조와 키 별칭이 유지되는 한 키 저장소 변경 시 가상 호스트를 업데이트할 필요가 없습니다. 이를 통해 이러한 변경사항을 직접 처리하고 Apigee 지원팀과의 종속성을 줄일 수 있습니다.
자체 서명 인증서	신뢰할 수 있는 CA에서 서명하지 않은 인증서 발급자와 주체가 동일합니다. 포함된 공개 키와 일치하는 비공개 키로 서명됩니다.
SNI	서버 이름 표시입니다. 여러 HTTPS 타겟이 동일한 인증서를 사용하지 않아도 동일한 IP 주소와 포트에서 제공될 수 있습니다.
TLS 인증서	TLS 트랜잭션에서 엔티티를 식별하는 디지털 파일입니다. 인증서 또는 cert는 TLS 구성에 따라 TLS 서버와 TLS 클라이언트를 식별하는 데 사용할 수 있습니다.
신뢰 저장소	클라이언트에 제공된 TLS 서버 인증서의 유효성을 검사하는 데 사용되는 TLS 클라이언트의 신뢰할 수 있는 인증서를 포함합니다. 이러한 인증서는 일반적으로 자체 서명 인증서 또는 신뢰할 수 있는 CA에서 서명하지 않은 인증서입니다. 북바운드 연결에서 클라이언트 애플리케이션의 인증서는 Apigee Edge의 트러스트 저장소에 저장됩니다. 이는 클라이언트와 Apigee 간에 양방향 TLS를 구성한 경우에만 필요합니다. 다운스트림 연결에서 백엔드 서버의 인증서는 Apigee Edge의 트러스트 저장소에 저장됩니다. Apigee Edge와 백엔드 서버 간의 단방향 또는 양방향 TLS 통신에서 Apigee Edge의 백엔드 인증서를 확인하려면 이 옵션이 필요합니다. Apigee Edge에는 별도의 신뢰 저장소 객체가 없습니다. 따라서 트러스트 저장소는 키 저장소 객체로 생성되지만 사용되는 곳(예: 가상 호스트, 대상 엔드포인트, 대상 서버 등)에서는 트러스트 저장소로 참조됩니다.
가상 호스트	가상 호스트는 클라이언트 애플리케이션의 Apigee API 엔드포인트를 나타냅니다. 단일 서버(또는 서버 풀)에서 여러 도메인 이름(각 이름의 별도 처리 포함)을 호스팅하는 데 도움이 되는 엔티티입니다. 이렇게 하면 제공되는 모든 서비스가 동일한 호스트 이름을 사용하지 않아도 하나의 서버가 메모리 및 프로세서 주기와 같은 리소스를 공유할 수 있습니다. 가상 호스트는 HTTP 또는 HTTPS (SSL 지원) 트래픽을 제공할 수 있습니다. SSL 지원 가상 호스트는 단방향 또는 양방향 TLS 모드로 구성할 수 있습니다. 다음과 같이 구성됩니다. 하나 이상의 hostalias (API 엔드포인트 DNS 이름) 포트 키 저장소 키 저장소에서 서버 인증서 중 하나를 고유하게 식별하는 키 별칭입니다. 선택적으로 트러스트 저장소 (양방향 TLS, 클라이언트 인증이 사용 설정된 경우)

단방향 TLS/SSL

다음 그림은 TLS 클라이언트와 TLS 서버 간의 단방향 인증을 위한 TLS/SSL 핸드셰이크를 보여줍니다.

단방향 TLS 구성에서 핸드셰이크는 다음과 같습니다.

• 클라이언트는 서버에 세션 요청을 실행합니다.
• 서버는 공개 키가 포함된 인증서로 응답합니다. 이 인증서는 서버의 키 저장소에서 가져오며, 여기에는 서버의 비공개 키도 포함됩니다. 비공개 키는 클라이언트로 전송되지 않습니다.
• 서명된 인증서의 경우 클라이언트는 서버 인증서와 공개 키가 포함된 트러스트 저장소를 사용하여 인증서 체인이 신뢰할 수 있는 인증 기관 (CA)에 의해 서명되었는지 확인합니다.
• 클라이언트와 서버는 키를 검증하기 위해 여러 메시지를 추가로 교환합니다.
• 클라이언트가 서버와 TLS 데이터 전송을 시작합니다.

다음 그림은 클라이언트에서 선택적 트러스트 저장소를 사용하여 TLS/SSL 핸드셰이크를 보여줍니다.

TLS 서버가 자체 서명 인증서 또는 신뢰할 수 있는 CA에서 서명하지 않은 인증서를 사용하는 경우 클라이언트에서 트러스트 저장소를 만듭니다. 클라이언트는 신뢰하는 서버 인증서와 공개 키로 신뢰 저장소를 채웁니다. 클라이언트가 인증서를 수신하면 수신된 인증서가 트러스트 저장소의 인증서에 대해 검증됩니다.

단방향 TLS에서 Edge는 다음과 같이 서버 또는 클라이언트가 될 수 있습니다.

• TLS 서버로서의 Edge

  Edge는 TLS 엔드포인트를 호스팅하는 서버이며, 여기서 TLS 엔드포인트는 가상 호스트에 배포된 API 프록시에 해당합니다. 클라이언트는 API 프록시에 액세스하려고 하는 앱입니다. 이 시나리오에서 Edge에는 인증서와 비공개 키가 포함된 키 저장소가 있습니다.

• TLS 클라이언트로서의 Edge

  Edge는 백엔드 서비스에 액세스하는 클라이언트 역할을 합니다. 이 경우 백엔드 서비스는 TLS 엔드포인트를 호스팅하는 서버에 해당합니다. 따라서 백엔드 서버에는 인증서와 비공개 키가 포함된 키 저장소가 있습니다.

양방향 TLS

다음 그림은 클라이언트와 서버 간의 양방향 TLS 인증을 위한 TLS/SSL 핸드셰이크를 보여줍니다.

양방향 TLS에서 핸드셰이크는 다음과 같습니다.

• 클라이언트와 서버 모두 자체 키 저장소가 있습니다. 클라이언트의 키 저장소에는 인증서와 비공개 키가 포함되고 서버의 키 저장소에는 인증서와 비공개 키가 포함됩니다.
• TLS 서버는 TLS 클라이언트에 인증서를 제공하여 자신을 인증합니다. 그런 다음 클라이언트는 서버에 인증서를 전송하기 전에 서버의 ID를 확인합니다.
• TLS 클라이언트는 TLS 서버에 인증서를 제공하여 서버에 자신을 인증합니다.

다음 그림은 선택적 신뢰 저장소를 사용하는 TLS 핸드셰이크를 보여줍니다.

이 시나리오에서 핸드셰이크는 다음과 같습니다.

• TLS 서버가 자체 서명 인증서 또는 신뢰할 수 있는 CA에서 서명하지 않은 인증서를 사용하는 경우 클라이언트에서 트러스트 저장소를 만듭니다. 클라이언트의 트러스트 저장소에 서버 인증서의 사본이 있습니다. TLS 핸드셰이크 중에 클라이언트는 트러스트 저장소의 인증서를 서버에서 보낸 인증서와 비교하여 서버의 ID를 확인합니다.
• TLS 클라이언트가 자체 서명된 인증서 또는 신뢰할 수 있는 CA에서 서명하지 않은 인증서를 사용하는 경우 서버에 트러스트 저장소를 만듭니다.서버의 트러스트 저장소에는 클라이언트 인증서의 사본이 있습니다. TLS 핸드셰이크 중에 서버는 트러스트 저장소의 인증서를 클라이언트에서 보낸 인증서와 비교하여 클라이언트의 ID를 확인합니다.

클라이언트 또는 서버 또는 둘 다 신뢰 저장소를 사용할 수 있습니다.

양방향 TLS에서 Edge는 다음과 같이 서버 또는 클라이언트가 될 수 있습니다.

• 에지를 서버로 사용

  Edge는 TLS 엔드포인트를 호스팅하는 서버이며, 여기서 TLS 엔드포인트는 API 프록시에 해당합니다. 클라이언트는 API 프록시에 액세스하려고 하는 앱입니다. 이 시나리오에서 Edge에는 인증서와 비공개 키가 포함된 키 저장소가 있으며 클라이언트의 인증서와 CA 체인이 포함된 트러스트 저장소가 필요합니다.

• 클라이언트로 Edge 사용

  Edge는 백엔드 서비스에 액세스하는 클라이언트 역할을 합니다. 이 경우 백엔드 서비스는 TLS 엔드포인트를 호스팅하는 서버에 해당합니다. 따라서 백엔드 서버에는 인증서와 비공개 키가 포함된 키 저장소가 있습니다.

  또한 Edge는 백엔드 서비스에 자체적으로 유효성을 검사하는 데 필요한 인증서가 포함된 키 저장소를 정의해야 하며, 서버가 자체 서명된 인증서 또는 신뢰할 수 있는 CA에서 서명하지 않은 인증서를 사용하는 경우 백엔드 서버의 인증서가 포함된 트러스트 저장소를 선택적으로 정의해야 합니다.

중요한 점은 Edge가 어떻게 구성되든 양방향 TLS를 지원할 수 있을 만큼 유연하다는 것입니다.

SNI 지원

Edge는 클라우드 및 Private Cloud 설치 모두에서 API 프록시에서 Edge로(여기서 Edge는 TLS 서버 역할을 함) 그리고 Edge에서 타겟 엔드포인트로(여기서 Edge는 TLS 클라이언트 역할을 함) 서버 이름 표시(SNI) 사용을 지원합니다.

TLS/SSL의 확장 프로그램인 SNI를 사용하면 이러한 타겟이 동일한 인증서를 사용하지 않아도 동일한 IP 주소와 포트에서 여러 HTTPS 타겟을 제공할 수 있습니다.

온프레미스 설치에서 SNI를 사용 설정하는 방법은 Edge에서 SNI 사용을 참고하세요.

Northbound 및 Southbound

Apigee에서 북바운드는 클라이언트 애플리케이션이 API 프록시를 호출하는 데 사용하는 API 엔드포인트를 의미합니다. 일반적으로 라우터는 Apigee Edge의 진입점이며 Apigee Edge에 대한 수신 요청을 처리합니다. 따라서 Apigee에서 클라이언트 애플리케이션과 Apigee Edge (라우터) 간의 통신에 사용되는 엔드포인트를 northbound라고 합니다.

Apigee에서 southbound는 Apigee가 백엔드 서버와 통신하는 데 사용하는 대상 엔드포인트를 의미합니다. 따라서 Apigee에서 Apigee Edge(메시지 프로세서)와 백엔드 서버 간 통신에 사용되는 엔드포인트를 southbound라고 합니다. 메시지 프로세서는 API 요청을 백엔드 대상 서버에 프록시하는 Apigee Edge의 구성요소입니다.

다음 그림은 Apigee Edge의 Northbound 및 Southbound 연결을 보여줍니다.