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

용어	정의
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) 형식은 텍스트 기반 ASCII 형식으로, 바이너리 DER (Distinguished Encoding Rules) 형식의 Base64 인코딩입니다. 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 클라이언트를 식별하는 데 사용할 수 있습니다.
Truststore	클라이언트에 제공된 TLS 서버 인증서의 유효성을 검사하는 데 사용되는 TLS 클라이언트의 신뢰할 수 있는 인증서를 포함합니다. 이러한 인증서는 일반적으로 자체 서명 인증서 또는 신뢰할 수 있는 CA에서 서명하지 않은 인증서입니다. 노스바운드 연결에서 클라이언트 애플리케이션의 인증서는 Apigee Edge의 트러스트 저장소에 저장됩니다. 이는 클라이언트와 Apigee 간에 양방향 TLS를 구성한 경우에만 필요합니다. 남향 연결에서 백엔드 서버의 인증서는 Apigee Edge의 트러스트 저장소에 저장됩니다. Apigee Edge와 백엔드 서버 간의 단방향 또는 양방향 TLS 통신에서 Apigee Edge의 백엔드 인증서를 확인하려면 이 작업이 필요합니다. Apigee Edge에는 별도의 트러스트스토어 객체가 없습니다. 따라서 트러스트 저장소는 키 저장소 객체로 생성되지만 사용되는 위치(예: 가상 호스트, 대상 엔드포인트, 대상 서버 등)에서는 트러스트 저장소로 참조됩니다.
가상 호스트	가상 호스트는 클라이언트 애플리케이션의 Apigee API 엔드포인트를 나타냅니다. 단일 서버(또는 서버 풀)에서 여러 도메인 이름을 호스팅하는 데 도움이 되는 항목입니다(각 이름을 별도로 처리함). 이렇게 하면 제공되는 모든 서비스가 동일한 호스트 이름을 사용할 필요 없이 한 서버에서 메모리 및 프로세서 사이클과 같은 리소스를 공유할 수 있습니다. 가상 호스트는 HTTP 또는 HTTPS (SSL 사용) 트래픽을 제공할 수 있습니다. SSL 지원 가상 호스트는 단방향 또는 양방향 TLS 모드로 구성할 수 있습니다. 다음과 같이 구성됩니다. 호스트 별칭 (API 엔드포인트 DNS 이름) 1개 이상 포트 키 저장소 키 저장소에서 서버 인증서 중 하나를 고유하게 식별하는 키 별칭입니다. 원하는 경우 트러스트 저장소 (클라이언트 인증이 사용 설정된 양방향 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는 Cloud 및 Private Cloud 설치 모두에서 API 프록시에서 Edge(Edge가 TLS 서버로 작동)로, 그리고 Edge에서 Edge가 TLS 클라이언트로 작동하는 대상 엔드포인트로의 서버 이름 표시(SNI) 사용을 지원합니다.

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

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

북행 및 남행

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

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

다음 그림은 Apigee Edge의 북방향 및 남방향 연결을 보여줍니다.