TLS/SSL 정보

현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동 정보

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를 구성하기 전에 다음과 같은 중요한 용어와 개념을 잘 알고 있어야 합니다.

용어	정의
캐나다	인증 기관으로 이동합니다. 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의 키 저장소에 저장됩니다. southbound 연결에서는 메시지 프로세서가 클라이언트 역할을 하고 백엔드 서버가 서버 역할을 합니다. 클라이언트 인증서와 비공개 키는 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 트랜잭션에서 항목을 식별하는 디지털 파일입니다. TLS 구성에 따라 인증서 또는 cert를 사용하여 TLS 서버와 TLS 클라이언트를 식별할 수 있습니다.
트러스트 저장소	클라이언트에 제공되는 TLS 서버의 인증서를 검증하는 데 사용되는 TLS 클라이언트의 신뢰할 수 있는 인증서가 포함됩니다. 이러한 인증서는 일반적으로 자체 서명된 인증서 또는 신뢰할 수 있는 CA가 서명하지 않은 인증서입니다. 북쪽 바운드 연결에서 클라이언트 애플리케이션의 인증서는 Apigee Edge의 트러스트 저장소에 저장됩니다. 클라이언트와 Apigee 사이에 양방향 TLS를 구성한 경우에만 필요합니다. southbound 연결에서 백엔드 서버의 인증서는 Apigee Edge의 트러스트 저장소에 저장됩니다. Apigee Edge는 Apigee Edge의 백엔드 인증서를 Apigee Edge와 백엔드 서버 간의 단방향 또는 양방향 TLS 통신으로 확인하려는 경우에 필요합니다. Apigee Edge에는 별도의 트러스트 저장소 객체가 없습니다. 따라서 트러스트 저장소는 키 저장소 객체로 생성되지만 사용되는 곳(예: 가상 호스트, 대상 엔드포인트, 대상 서버 등)마다 truststore로 참조됩니다.
가상 호스트	가상 호스트는 클라이언트 애플리케이션의 Apigee API 엔드포인트를 나타냅니다. 단일 서버(또는 서버 풀)에서 여러 도메인 이름(각 이름을 별도로 처리)을 호스팅하는 데 도움이 되는 항목입니다. 이렇게 하면 제공된 모든 서비스에서 동일한 호스트 이름을 사용할 필요 없이 한 서버가 메모리 및 프로세서 사이클과 같은 리소스를 공유할 수 있습니다. 가상 호스트는 HTTP 또는 HTTPS (SSL 사용) 트래픽을 처리할 수 있습니다. SSL 지원 가상 호스트는 단방향 또는 양방향 TLS 모드로 구성할 수 있습니다. 다음과 같이 구성됩니다. 하나 이상의 hostalias (API 엔드포인트 DNS 이름)입니다. 포트 키 저장소 키 저장소의 서버 인증서 중 하나를 고유하게 식별하는 키 별칭입니다. 필요한 경우 트러스트 저장소 (클라이언트 인증이 사용 설정된 양방향 TLS)

단방향 TLS/SSL

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

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

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

다음 그림은 클라이언트에서 선택적 truststore를 사용하는 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

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

• 클라이언트로서의 Edge

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

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

Edge는 유연하여 구성 방식과 상관없이 양방향 TLS를 지원할 수 있다는 점을 기억해야 합니다.

SNI 지원

Edge는 클라우드 및 프라이빗 클라우드 설치에서 API 프록시에서 Edge로 서버 이름 표시 (SNI)를 사용할 수 있도록 지원합니다. 여기에서 Edge는 TLS 서버로, Edge에서 대상 엔드포인트로, 이때 Edge는 TLS 클라이언트 역할을 합니다.

TLS/SSL의 확장인 SNI를 사용하면 해당 대상에 동일한 인증서를 사용할 필요 없이 동일한 IP 주소 및 포트에서 여러 HTTPS 대상을 제공할 수 있습니다.

온프레미스 설치를 위해 SNI를 사용 설정하는 방법에 대한 자세한 내용은 Edge에서 SNI 사용을 참조하세요.

북쪽 방면 및 남쪽 방면

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

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

다음 그림은 Apigee Edge의 북쪽 경계 및 남쪽 경계 연결을 보여줍니다.