Escala en la era de la seguridad total
En la WWDC (Conferencia Mundial de Desarrolladores) de Apple en junio, el magnate de la telefonía móvil anunció que a partir del 1 de enero de 2017, todas las aplicaciones en la tienda de aplicaciones DEBEN (ese es el estilo RFC MUST para los expertos en redes que siguen) usar App Transport Security (ATS).
Básicamente, obliga a las aplicaciones a utilizar HTTPS en lugar de HTTP.
Ahora bien, lo que eso significa para las personas es que sólo tienen unos pocos meses para:
- Actualizar sus aplicaciones móviles
Esto parece obvio. Después de todo, el requisito es que las aplicaciones móviles en iOS utilicen HTTPS. Así que sí, ahí está. - Admite HTTPS en el backend
Puede que esto no sea tan obvio, pero el objetivo de HTTPS es proteger las comunicaciones, lo que implica al menos dos partes involucradas. En el caso de las aplicaciones móviles, se trata de algún tipo de punto final (aplicación, servicio, puerta de enlace API), ya sea local o en la nube. Esto también debe ser compatible con HTTPS.
Ese segundo requisito es el que es más complejo, técnica y operativamente, que el primero, porque no es simplemente cuestión de pulsar un interruptor. Hay gestión de certificados y claves, distribución, actualizaciones, cambios en las configuraciones de servidores web y puertas de enlace API que antes no admitían HTTPS. Es posible que se requieran cambios importantes en la infraestructura (y arquitectura) para brindar soporte. Y luego hay cambios operativos que deben realizarse, incluyendo vigilar las caducidad de los certificados y reemplazarlos.
Escalar en una era en la que todo está seguro no es sólo una cuestión de capacidad, sino de capacidad operativa. El impacto operativo del soporte de una infraestructura de aplicaciones segura no es trivial. No se trata solo de casillas de verificación o de un nuevo archivo de configuración.
1.Cambios de proceso
Si está “haciendo DevOps” (o incluso si no lo está haciendo), debe examinar su proceso de implementación y asegurarse de que incluya los componentes necesarios para soportar 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 expiran. Y cuando lo hacen, es algo malo™. El equipo de operaciones debe saber cuándo expirarán los certificados y asegurarse de que exista un proceso establecido para renovarlos y luego implementarlos (que es básicamente GOTO #1: Cambio de proceso).
3.Cambios de capacidad
El cifrado y el descifrado no son baratos en términos de procesamiento. Incluso si no son tan codiciosas como solían ser, las conexiones seguras aún consumen más recursos que las inseguras. Es posible que no notes ninguna diferencia perceptible en aplicaciones que tengan muy pocos usuarios. Pero, para aquellos que se utilizan mucho (simultáneamente), será necesario examinar qué capacidad está disponible para escalar horizontalmente. Y no sólo servidores (virtuales o físicos) sino también la infraestructura. Esto incluye puertas de enlace de API (o dispositivos/sistemas que actúan como puertas de enlace de API) y, potencialmente, registros de servicios (si ya está utilizando contenedores y microservicios).
4.Cambios arquitectónicos
Una conexión segura de extremo a extremo puede paralizar todos los servicios de seguridad entre el usuario y la aplicación, haciéndolos prácticamente inútiles para evitar que el malware o el código malicioso lleguen a las aplicaciones y servicios que tienen acceso a datos confidenciales. La capacidad de interceptar conexiones seguras e inspeccionarlas, tanto en la entrada (solicitud) como en la salida (respuesta), es un componente importante de una estrategia de seguridad exitosa. Es posible que se requieran cambios arquitectónicos para garantizar que la infraestructura de seguridad crítica continúe teniendo la visibilidad necesaria para desempeñar su función de prevención de violaciones e infecciones.
Una arquitectura de dos niveles en la que las conexiones seguras son administradas por la red principal puede aliviar gran parte de los problemas operativos asociados con tener certificados y claves dispersos por toda la infraestructura de la aplicación. Esto se debe a que la conexión segura puede finalizarse en la red principal mediante un proxy seguro. La comunicación con las aplicaciones back-end puede seguir siendo en texto simple, si así se desea, o puede volver a cifrarse para mantener una comunicación segura de extremo a extremo. Los datos no cifrados se pueden reflejar en soluciones de seguridad (como IDS/IPS) para una mayor inspección, manteniendo así la inversión en la infraestructura existente. Esto significa una ubicación central en la que se deben implementar, administrar y monitorear los certificados y las claves. También proporciona un punto estratégico en la ruta de datos NS donde se puede realizar intercepción e inspección sin interferir en las comunicaciones entre dispositivos móviles y aplicaciones .
De todos modos, el impacto en la escala de un enfoque de Todo Seguro para las aplicaciones (móviles y otras) no es sólo un problema de recursos informáticos, sino también operativo. Y aunque Apple es sin duda un impulsor de estos cambios, no es el único. Recuerde que a pesar de la eliminación del requisito SSL/TLS para HTTP/2 del estándar oficial, la comunidad de navegadores web solo admitirá HTTP/2 sobre SSL/TLS. Esto significa que, a medida que más de la web pasa de HTTP/1x a HTTP/2, Secure Everything simplemente seguirá ampliando su alcance.
Esta marcha continua hacia la eliminación de cualquier tipo de comunicación no cifrada entre aplicaciones y usuarios (por decreto o por función) requerirá para algunas organizaciones cambios significativos tanto en los procesos como en los productos.