Estás viendo la documentación de Apigee Edge.
Ve a la
documentación de Apigee X. Información
La seguridad de la capa de transporte (TLS), cuyo predecesor es la capa de conexión segura (SSL), es la tecnología de seguridad estándar para establecer un vínculo encriptado entre un servidor web y un cliente web, como un navegador o una app. Un vínculo encriptado garantiza que todos los datos que pasan entre el servidor y el cliente permanezcan privados. Para usar TLS, un cliente realiza una solicitud segura al servidor mediante el protocolo encriptado HTTPS, en lugar del protocolo HTTP sin encriptar.
Edge admite TLS unidireccional y bidireccional tanto en la nube como en una implementación local (para conocer las versiones compatibles de TLS, consulta Software y versiones compatibles). La TLS unidireccional permite que el cliente de TLS verifique la identidad del servidor de TLS. Por ejemplo, una app que se ejecuta en un teléfono Android (cliente) puede verificar la identidad de las APIs de Edge (servidor).
Apigee también admite una forma más sólida de autenticación a través de TLS bidireccional (o de cliente). Por lo general, implementas TLS bidireccional para mejorar la seguridad de extremo a extremo y proteger tus datos de los ataques de clientes, como la falsificación de identidad de clientes o los ataques de intermediarios. En la TLS bidireccional, el cliente verifica la identidad del servidor y, luego, el servidor verifica la identidad del cliente.
Terminología de TLS
Debes estar familiarizado con los siguientes términos y conceptos importantes antes de configurar TLS:
|
Período |
Definición |
|---|---|
|
Canadá |
Autoridad certificadora. Una entidad de confianza, como Symantec o VeriSign, que se usa para emitir certificados y validar su autenticidad. Un tipo de certificado, llamado certificado autofirmado, no requiere una AC. |
|
Cadena de certificado |
A menudo, no tendrás un certificado firmado por la clave privada raíz de tu AC. En su lugar, tendrás tu certificado junto con uno o más certificados intermedios que forman una cadena. Por lo general, el último certificado intermedio de la cadena está firmado por la clave privada raíz de la CA. |
|
CSR |
Solicitud de firma de certificado. Una CSR es un archivo que se genera en el servidor TLS según la clave privada. La CSR contiene la clave pública y otra información, como el nombre, la ubicación y el nombre de dominio de la organización. La CA firma la CSR para crear un certificado TLS. Por lo general, generas una CSR cuando tienes un certificado vencido y quieres renovarlo. |
| DER |
Reglas de codificación distinguidas. El formato DER es un formato binario de un certificado, en lugar del formato ASCII PEM. A veces tiene la extensión de archivo .der, pero suele tener la extensión .cer. La única forma de diferenciar entre un archivo DER .cer y un archivo PEM .cer es abrir el archivo en un editor de texto y buscar las sentencias |
| Alias de la clave |
Un alias de clave identifica de manera única una entrada del almacén de claves (certificado TLS y clave privada correspondiente) en el almacén de claves.
En Apigee Edge, |
|
Almacén de claves |
Un almacén de claves es un repositorio que contiene uno o más certificados TLS y una clave privada correspondiente que se usa para identificar la entidad durante un protocolo de enlace TLS entre un cliente y un servidor. En la conexión northbound, el router actúa como el servidor y su certificado se almacena en el almacén de claves en Apigee Edge. En la conexión hacia el sur, el procesador de mensajes actúa como el cliente, y el servidor de backend actúa como el servidor. El certificado de cliente y su clave privada se almacenan en el almacén de claves en Apigee Edge. |
| P7B |
El formato PKCS #7 o P7B se suele almacenar en formato ASCII Base64 y tiene la extensión de archivo .p7b o .p7c. Los certificados P7B contienen declaraciones |
|
PEM |
El formato de correo con privacidad mejorada (PEM) es un formato ASCII basado en texto que es una codificación Base64 del formato de Reglas de codificación distinguidas (DER) binarias. Los certificados PEM se pueden abrir en cualquier editor de texto y el contenido real del certificado está delimitado entre las declaraciones Cumple con el formato X.509 para almacenar certificados, cadenas de certificados o claves privadas. Si tu certificado o clave privada no están definidos por un archivo PEM, puedes convertirlos en un archivo PEM con utilidades como OpenSSL. |
| PKCS #12/PFX | El formato PKCS #12 o PFX es un formato binario para almacenar el certificado del servidor, los certificados intermedios y la clave privada en un archivo que se puede encriptar. Los archivos PFX suelen tener extensiones como .pfx y .p12. Los archivos PFX se suelen usar en máquinas con Windows para importar y exportar certificados y claves privadas. |
|
Clave privada |
Se usa en el servidor de TLS para desencriptar datos. Solo el servidor de TLS tiene la clave privada; no se comparte con los clientes de TLS. |
|
Clave pública |
Se usa para encriptar datos enviados desde un cliente de TLS a un servidor de TLS. La clave pública se incluye en el certificado. Todos los clientes de TLS tienen una copia de la clave pública del servidor. |
| References | Las referencias proporcionan un nivel de indirección para los almacenes de claves. Por lo tanto, los cambios en el almacén de claves no requieren una actualización del host virtual, siempre y cuando se mantengan la misma referencia y el mismo alias de clave. De esta forma, puedes autoadministrar estos cambios y reducir las dependencias con el equipo de asistencia al cliente de Apigee. |
|
Certificado autofirmado |
Un certificado que no está firmado por una AC de confianza. La entidad emisora y el sujeto son idénticos; están firmados con la clave privada que coincide con la clave pública que contienen. |
|
SNI |
Indicación de nombre del servidor. Permite que varios destinos HTTPS se entreguen desde la misma dirección IP y puerto sin que esos destinos usen el mismo certificado. |
|
Certificado TLS |
Es un archivo digital que identifica una entidad en una transacción TLS. Se puede usar un certificado, o cert, para identificar el servidor y el cliente de TLS, según la configuración de TLS. |
|
Almacén de confianza |
Contiene certificados de confianza en un cliente de TLS que se usan para validar un certificado del servidor de TLS que se presenta al cliente. Por lo general, estos certificados son certificados autofirmados o que no están firmados por una AC de confianza. En la conexión northbound, los certificados de la aplicación cliente se almacenan en el almacén de confianza de Apigee Edge. Esto es necesario solo si configuraste una TLS bidireccional entre el cliente y Apigee. En la conexión southbound, los certificados del servidor de backend se almacenan en el almacén de confianza en Apigee Edge. Esto es necesario si deseas verificar el certificado del backend en Apigee Edge mediante una comunicación TLS unidireccional o bidireccional entre Apigee Edge y el servidor de backend. Apigee Edge no tiene un objeto de almacén de confianza independiente. Por lo tanto, los almacenes de confianza se crean como un objeto de almacén de claves, pero se hace referencia a ellos como almacenes de confianza siempre que se usen (por ejemplo, en host virtual, extremos de destino, servidores de destino, etcétera). |
| Host virtual |
El host virtual representa el extremo de la API de Apigee para las aplicaciones cliente. Es una entidad que ayuda a alojar varios nombres de dominio (con control independiente de cada nombre) en un solo servidor (o grupo de servidores). Esto permite que un servidor comparta sus recursos, como los ciclos de memoria y procesador, sin necesidad de que todos los servicios proporcionados usen el mismo nombre de host. Un host virtual puede entregar tráfico HTTP o HTTPS (habilitado para SSL). Un host virtual habilitado para SSL se puede configurar en modo TLS unidireccional o bidireccional. Se configura con lo siguiente:
|
TLS/SSL unidireccional
En la siguiente imagen, se muestra el protocolo de enlace TLS/SSL para la autenticación unidireccional entre un cliente y un servidor TLS:
En una configuración de TLS unidireccional, el protocolo de enlace es el siguiente:
- El cliente emite una solicitud de sesión al servidor.
- El servidor responde con un certificado, que contiene su clave pública. que proviene del almacén de claves del servidor, que también contiene la clave privada del servidor. La clave privada nunca se envía al cliente.
- Para un certificado firmado, el cliente usa un almacén de confianza que contiene certificados de servidor y claves públicas a fin de validar que la cadena de certificados esté firmada por una autoridad certificadora (AC) de confianza.
- El cliente y el servidor intercambian varios mensajes más para validar las claves.
- El cliente inicia la transferencia de datos TLS con el servidor.
En la siguiente figura, se muestra el protocolo de enlace TLS/SSL mediante un almacén de confianza opcional en el cliente:
Si el servidor TLS usa un certificado autofirmado o uno que no está firmado por una AC de confianza, debes crear un almacén de confianza en el cliente. El cliente propaga su almacén de confianza con certificados de servidor y claves públicas en las que confía. Cuando el cliente recibe un certificado, el certificado entrante se valida con los certificados de su almacén de confianza.
En la TLS unidireccional, Edge puede ser el servidor o el cliente de la siguiente manera:
-
Edge como servidor de TLS
Edge es el servidor que aloja el extremo TLS, en el que este corresponde a un proxy de API implementado en un host virtual. El cliente es una app que intenta acceder al proxy de API. En este caso, Edge tiene el almacén de claves que contiene el certificado y la clave privada.
-
Edge como cliente de TLS
Edge actúa como el cliente que accede a un servicio de backend. En este caso, el servicio de backend corresponde al servidor que aloja un extremo de TLS. Por lo tanto, el servidor de backend tiene un almacén de claves que contiene el certificado y la clave privada.
TLS bidireccional
En la siguiente imagen, se muestra el protocolo de enlace TLS/SSL para la autenticación TLS bidireccional entre un cliente y un servidor:
En la TLS bidireccional, el protocolo de enlace es el siguiente:
- El cliente y el servidor tienen sus propios almacenes de claves. El almacén de claves del cliente contiene el certificado y la clave privada, y el almacén de claves del servidor contiene el certificado y la clave privada.
- El servidor de TLS presenta su certificado al cliente de TLS para que se autentique. Luego, el cliente verifica la identidad del servidor antes de enviar su certificado al servidor.
- El cliente TLS presenta su certificado al servidor TLS para autenticarse en el servidor.
En la siguiente figura, se muestra el protocolo de enlace de TLS con un almacén de confianza opcional:
En este caso, el protocolo de enlace es el siguiente:
- Si el servidor de TLS usa un certificado autofirmado o uno que no está firmado por una AC de confianza, debes crear un almacén de confianza en el cliente. El cliente tiene una copia del certificado del servidor en su almacén de confianza. Durante el protocolo de enlace TLS, el cliente compara el certificado almacenado en su almacén de confianza con el certificado enviado desde el servidor para verificar la identidad del servidor.
- Si el cliente de TLS usa un certificado autofirmado o uno que no está firmado por una AC de confianza, debes crear un almacén de confianza en el servidor.El servidor tiene una copia del certificado del cliente en su almacén de confianza. Durante el protocolo de enlace de TLS, el servidor compara el certificado de su almacén de confianza con el que envió el cliente para verificar la identidad del cliente.
El cliente, el servidor o ambos pueden usar un almacén de confianza.
En la TLS bidireccional, Edge puede ser el servidor o el cliente de la siguiente manera:
-
Edge como servidor
Edge es el servidor que aloja el extremo TLS, en el que este corresponde a un proxy de API. El cliente es una app que intenta acceder al proxy de API. En esta situación, Edge tiene un almacén de claves que contiene el certificado y la clave privada, y requiere un almacén de confianza que contenga el certificado y la cadena de AC del cliente.
-
Edge como cliente
Edge actúa como un cliente que accede a un servicio de backend. En este caso, el servicio de backend corresponde al servidor que aloja el extremo de TLS. Por lo tanto, el servidor de backend tiene un almacén de claves que contiene el certificado y la clave privada.
Edge también debe definir un almacén de claves que contenga el certificado necesario para validarse en el servicio de backend y, opcionalmente, un almacén de confianza que contenga el certificado del servidor de backend si el servidor usa un certificado autofirmado o uno que no esté firmado por una AC de confianza.
Es importante recordar que Edge es lo suficientemente flexible como para admitir TLS bidireccional, sin importar cómo decidas configurarla.
Asistencia de SNI
Edge admite el uso de la indicación de nombre del servidor (SNI) desde los proxies de API hasta Edge, en el que Edge actúa como el servidor TLS, y desde Edge hasta los extremos de destino, en los que Edge actúa como el cliente de TLS, en instalaciones de Cloud y de nube privada.
Con la SNI, que es una extensión de TLS/SSL, se pueden entregar varios objetivos HTTPS desde la misma dirección IP y puerto sin necesidad de que esos destinos usen el mismo certificado.
Si deseas obtener información sobre cómo habilitar la SNI en una instalación local, consulta Usa SNI con Edge.
Hacia el norte y hacia el sur
En Apigee, el norte hace referencia al extremo de la API que usan las aplicaciones cliente para invocar el proxy de la API. Por lo general, el router es el punto de entrada en Apigee Edge y controla las solicitudes entrantes a Apigee Edge. Por lo tanto, en Apigee, el extremo que se usa para la comunicación entre la aplicación cliente y Apigee Edge (router) se conoce como northbound.
En Apigee, el límite sur hace referencia al extremo de destino que Apigee usa para comunicarse con el servidor de backend. Por lo tanto, en Apigee, el extremo que se usa para la comunicación entre Apigee Edge (Message Processor) y el servidor de backend se conoce como southbound. Message Processor es un componente de Apigee Edge que procesa las solicitudes a la API en los servidores de destino de backend.
En la siguiente figura, se ilustran las conexiones hacia el norte y el sur para Apigee Edge:
