Escalar en la era de «Protegerlo todo»

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

En la WWDC (Conferencia Mundial de Desarrolladores) de Apple celebrada en junio, el gigante de la telefonía móvil anunció que, a partir del 1 de enero de 2017, todas las aplicaciones de la App Store DEBERÁN (en el sentido normativo de «MUST» de las RFC, para quienes estén familiarizados con las redes) utilizar App Transport Security (ATS).

Básicamente, obliga a las aplicaciones a usar HTTPS en lugar de HTTP.

Ahora bien, esto significa que la gente solo dispone de unos meses para:

1. Actualizar sus aplicaciones móviles
   Parece obvio. Al fin y al cabo, el requisito es que las aplicaciones móviles para iOS utilicen HTTPS. Así que sí, eso es lo primero.
2. Compatibilidad con HTTPS en el backend
   Puede que esto no resulte tan obvio, pero el objetivo de HTTPS es proteger las comunicaciones, lo que implica la participación de al menos dos partes. En el caso de las aplicaciones móviles, la otra parte es algún tipo de punto de conexión (aplicación, servicio o puerta de enlace de API), ya sea en las instalaciones o en la nube. Este también debe ser compatible con HTTPS.

Ese segundo requisito es más complejo que el primero, tanto desde el punto de vista técnico como operativo, porque no se trata simplemente de accionar un interruptor. Hay que gestionar y distribuir certificados y claves, realizar actualizaciones y modificar la configuración de servidores web y puertas de enlace de API que antes no admitían HTTPS. Es posible que sea necesario realizar cambios importantes en la infraestructura (y la arquitectura) para ofrecer compatibilidad. Además, deben introducirse cambios operativos, como supervisar las fechas de caducidad de los certificados y sustituirlos.

Escalar en la era de «Todo seguro» no es solo una cuestión de capacidad, sino también de capacidad operativa. El impacto operativo de mantener una infraestructura de aplicaciones segura no es trivial. No se trata simplemente de marcar casillas o de añadir un nuevo archivo de configuración.

1. Cambios en los procesos

Si estás «haciendo DevOps» (o incluso si no es así), debes revisar el proceso de tu canalización de despliegue y asegurarte de que incluya los componentes necesarios para admitir HTTPS. Esto significa que las claves, los certificados y la configuración deben incluirse en el proceso.

2. Cambios en la gestión

Los certificados caducan. Y cuando lo hacen, es Algo Malo™. El equipo de Operaciones debe saber cuándo caducarán y asegurarse de que exista un proceso para renovarlos y, después, desplegarlos (lo que básicamente equivale a GOTO n.º 1: Cambio de proceso).

3. Cambios de capacidad

El cifrado y el descifrado tienen un coste computacional considerable. Aunque ya no consumen tantos recursos como antes, las conexiones seguras siguen requiriendo más recursos que las no seguras. Es posible que no aprecies ninguna diferencia en aplicaciones con muy pocos usuarios. Sin embargo, en aquellas que se utilizan de forma intensiva (y simultánea), tendrás que evaluar la capacidad disponible para escalar horizontalmente. Y no solo en cuanto a servidores (virtuales o físicos), sino también a la infraestructura. Esto incluye las puertas de enlace de API (o los dispositivos/sistemas que actúan como tales) y, posiblemente, los registros de servicios (si ya utilizas contenedores y microservicios).

4. Cambios arquitectónicos

Una conexión segura de extremo a extremo puede obstaculizar todos los servicios de seguridad situados entre el usuario y la aplicación, lo que los hace prácticamente inútiles para impedir que el malware o el código malicioso lleguen a aplicaciones y servicios con acceso a datos confidenciales. La capacidad de interceptar las conexiones seguras e inspeccionarlas —tanto a la entrada (solicitud) como a la salida (respuesta)— es un componente importante de una estrategia de seguridad eficaz. Es posible que sea necesario realizar cambios en la arquitectura para garantizar que la infraestructura de seguridad crítica siga teniendo la visibilidad necesaria para desempeñar su función de prevención de brechas de seguridad e infecciones.

Una arquitectura de dos niveles en la que las conexiones seguras se gestionan desde la red central puede aliviar gran parte de los problemas operativos asociados a la proliferación de certificados y claves por toda la infraestructura de aplicaciones. Esto se debe a que un proxy seguro puede terminar la conexión segura en la red central. La comunicación con las aplicaciones de back-end puede seguir realizándose en texto sin cifrar, si así se desea, o volver a cifrarse para mantener una comunicación segura de extremo a extremo. Los datos sin cifrar pueden replicarse en soluciones de seguridad (como IDS/IPS) para someterlos a una inspección más exhaustiva, preservando así la inversión en la infraestructura existente. Esto permite disponer de una única ubicación centralizada en la que desplegar, gestionar y supervisar los certificados y las claves. También proporciona un punto estratégico en la ruta de datos N-S donde pueden llevarse a cabo la interceptación y la inspección sin interferir en las comunicaciones entre móvil <—> aplicación.

En cualquier caso, el impacto que tiene a gran escala un enfoque de «protegerlo todo» en las aplicaciones (móviles o de otro tipo) no es solo una cuestión de recursos informáticos, sino también operativa. Y aunque Apple es sin duda uno de los impulsores de estos cambios, no es el único. Cabe recordar que, pese a haberse eliminado del estándar oficial el requisito de SSL/TLS para HTTP/2, la comunidad de navegadores web solo admitirá HTTP/2 sobre SSL/TLS. Esto significa que, a medida que una mayor parte de la web migre de HTTP/1.x a HTTP/2, el enfoque de «protegerlo todo» seguirá ampliando su alcance.

Este avance continuo hacia la eliminación de cualquier tipo de comunicación sin cifrar entre las aplicaciones y los usuarios (ya sea por imposición o por funcionalidad) exigirá a algunas organizaciones cambios importantes tanto en sus procesos como en sus productos.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie