Estás viendo la documentación de Apigee Edge.
Ve a la
documentación de Apigee X. info
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 con el protocolo HTTPS encriptado, en lugar del protocolo HTTP sin encriptar.
Edge admite TLS unidireccional y bidireccional en implementaciones en la nube y locales (para las versiones compatibles de TLS, consulta Software y versiones compatibles). La TLS unidireccional permite que el cliente TLS verifique la identidad del servidor 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 segura de autenticación con TLS bidireccional o cliente. Por lo general, se implementa TLS bidireccional para mejorar la seguridad de extremo a extremo y proteger tus datos de los ataques de cliente, como la falsificación de identidad de cliente o los ataques de intermediario. En el TLS de dos vías, el cliente verifica la identidad del servidor y, luego, el servidor verifica la identidad del cliente.
Terminología de TLS
Antes de configurar TLS, debes familiarizarte con los siguientes términos y conceptos importantes:
|
Término |
Definición |
|---|---|
|
Canadá |
Autoridad certificadora. Es una entidad de confianza, como Symantec o VeriSign, que se usa para emitir certificados y validar su autenticidad. Un tipo de certificado, llamado 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, tienes tu certificado junto con uno o más certificados intermedios que forman una cadena. Por lo general, la clave privada raíz de la AC firma el último certificado intermedio de la cadena. |
|
CSR |
Solicitud de firma de certificado. Un 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 AC firma la CSR para crear un certificado TLS. Por lo general, se genera una CSR cuando tienes un certificado vencido y quieres renovarlo. |
| DER |
Reglas de codificación distinguidas El formato DER es una forma binaria de un certificado en lugar del formato PEM ASCII. A veces, tiene la extensión .der, pero a menudo tiene la extensión .cer. La única forma de distinguir entre un archivo .cer DER y un archivo .cer PEM es abrirlo en un editor de texto y buscar las instrucciones |
| Alias de clave |
Un alias de clave identifica de forma ú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 de Apigee Edge. En la conexión southbound, el Message Processor actúa como el cliente y el servidor de backend actúa como el servidor. El certificado del cliente y su clave privada se almacenan en el almacén de claves de Apigee Edge. |
| P7B |
El formato PKCS #7 o P7B suele almacenarse en formato ASCII de Base64 y tiene una extensión de archivo .p7b o .p7c. Los certificados P7B contienen sentencias |
|
PEM |
El formato de correo electrónico con privacidad mejorada (PEM) es un formato ASCII basado en texto que es una codificación Base64 del formato binario de reglas de codificación distinguidas (DER). Los certificados PEM se pueden abrir en cualquier editor de texto, y el contenido real del certificado se delimita entre las sentencias Cumple con el formato X.509 para almacenar un certificado, una cadena de certificados o una clave privada. Si tu certificado o clave privada no está definido por un archivo PEM, puedes convertirlo a 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, cualquier certificado intermedio y la clave privada en un archivo encriptable. Los archivos PFX suelen tener extensiones como .pfx y .p12. Por lo general, los archivos PFX se usan en máquinas con Windows para importar y exportar certificados y claves privadas. |
|
Clave privada |
Se usa en el servidor TLS para desencriptar datos. Solo el servidor TLS tiene la clave privada, que no se comparte con los clientes TLS. |
|
Clave pública |
Se usa para encriptar los datos que se envían de un cliente TLS a un servidor TLS. La clave pública se incluye en el certificado. Todos los clientes 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. Esto te permite autoabastecer estos cambios y reducir las dependencias con el equipo de asistencia de Apigee. |
|
Certificado autofirmado |
Un certificado que no está firmado por una AC de confianza El emisor y el sujeto son idénticos; se firman con la clave privada que coincide con la clave pública que contienen. |
|
SNI |
Indicación del nombre del servidor. Permite que se entreguen varios destinos HTTPS desde la misma dirección IP y puerto sin que esos destinos deban usar el mismo certificado. |
|
Certificado TLS |
Es un archivo digital que identifica a una entidad en una transacción TLS. Se puede usar un certificado, o cert, para identificar el servidor y el cliente TLS, según la configuración de TLS. |
|
Truststore |
Contiene certificados de confianza en un cliente TLS que se usa para validar el certificado de un servidor TLS que se presenta al cliente. Por lo general, estos certificados son autofirmados o no están firmados por una AC de confianza. En la conexión norte, los certificados de la aplicación cliente se almacenan en el almacén de confianza de Apigee Edge. Esto solo es necesario si configuraste un 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 de Apigee Edge. Esto es obligatorio si deseas verificar el certificado del backend en Apigee Edge en 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 almacén de confianza dondequiera que se usen (por ejemplo, en el host virtual, los extremos de destino, los 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 un manejo independiente de cada nombre) en un solo servidor (o grupo de servidores). Esto permite que un servidor comparta sus recursos, como la memoria y los ciclos del procesador, sin que todos los servicios proporcionados deban usar 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 envía una solicitud de sesión al servidor.
- El servidor responde con un certificado que contiene su clave pública. Este certificado 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 para 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 de TLS con el servidor.
En la siguiente imagen, se muestra el protocolo de enlace TLS/SSL con un almacén de confianza opcional en el cliente:
Si el servidor TLS usa un certificado autofirmado o un certificado que no está firmado por una AC de confianza, creas un almacén de confianza en el cliente. El cliente propaga su almacén de confianza con los certificados del servidor y las 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 el TLS unidireccional, Edge puede ser el servidor o el cliente de la siguiente manera:
-
Edge como servidor TLS
Edge es el servidor que aloja el extremo de TLS, donde el extremo de TLS corresponde a un proxy de API que se implementó en un host virtual. El cliente es una app que intenta acceder al proxy de API. En esta situación, 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 TLS. Por lo tanto, el servidor de backend tiene un almacén de claves que contiene su certificado y clave privada.
TLS de dos vías
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 el TLS de dos vías, 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 su certificado y clave privada, y el almacén de claves del servidor contiene su certificado y 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 enviarle su certificado.
- El cliente de TLS presenta su certificado al servidor de TLS para autenticarse en el servidor.
En la siguiente figura, se muestra el protocolo de enlace TLS con un almacén de confianza opcional:
En esta situación, el protocolo de enlace es el siguiente:
- Si el servidor TLS usa un certificado autofirmado o un certificado que no está firmado por una AC de confianza, creas 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 de su almacén de confianza con el certificado que envía el servidor para verificar la identidad del servidor.
- Si el cliente de TLS usa un certificado autofirmado o un certificado que no está firmado por una AC de confianza, creas 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 TLS, el servidor compara el certificado de su almacén de confianza con el certificado que envía el cliente para verificar la identidad del cliente.
El cliente, el servidor o ambos pueden usar un almacén de confianza.
En el 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 de TLS, en el que el extremo de TLS 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 TLS. Por lo tanto, el servidor de backend tiene un almacén de claves que contiene su certificado y 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, de manera opcional, un almacén de confianza que contenga el certificado del servidor de backend si este usa un certificado autofirmado o un certificado que no está firmado por una AC de confianza.
Lo importante que debes recordar es que Edge es lo suficientemente flexible como para admitir TLS bidireccional, independientemente de cómo decidas configurarlo.
Compatibilidad con SNI
Edge admite el uso de la indicación de nombre de servidor (SNI) desde los proxies de API a Edge, donde Edge actúa como el servidor TLS, y desde Edge a los extremos de destino, donde Edge actúa como el cliente TLS, en las instalaciones de Cloud y Private Cloud.
Con SNI, que es una extensión de TLS/SSL, se pueden entregar varios destinos HTTPS desde la misma dirección IP y puerto sin que esos destinos deban usar el mismo certificado.
Para obtener información sobre cómo habilitar SNI para una instalación local, consulta Cómo usar SNI con Edge.
Norte y sur
En Apigee, el tráfico orientado al norte hace referencia al extremo de la API que usan las aplicaciones cliente para invocar el proxy de 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 norte.
En Apigee, el tráfico descendente 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 descendente. El procesador de mensajes es un componente de Apigee Edge que usa proxies para las solicitudes a la API a los servidores de destino de backend.
En la siguiente figura, se ilustran las conexiones ascendentes y descendentes de Apigee Edge:
