6 errores de seguridad sin servidor que nunca debe cometer
Asegurar su aplicación sin servidor puede ser abrumador, especialmente cuando hay tantos microservicios ejecutándose simultáneamente. ¿Alguna vez has tenido esa sensación de hundimiento en la boca del estómago, preocupado por haber olvidado algo? ¿El miedo agonizante de que has dejado la estufa encendida y quemarás tu hogar?
Si está implementando aplicaciones sin servidor, puede estar experimentando esa aprensión apremiante con respecto a asegurar esta tecnología relativamente nueva. Si bien nos encantaría asegurarle que todo está bien, es muy probable que haya cometido algunos errores. Siga leyendo para conocer los principales errores que debe evitar al proteger las aplicaciones sin servidor.
Error n. ° 1: asumir que WAF se encarga de todas las necesidades de seguridad de su aplicación
Tradicionalmente, los firewalls de aplicaciones web (WAF) se ubican en el perímetro de su red, al ingreso de Internet, protegiendo los servicios web o de aplicaciones que están alojados en la nube. Dado que un WAF solo es capaz de inspeccionar el tráfico HTTP (s), y solo protegerá las funciones, que son funciones activadas por API Gateway, que deja muchos eventos desencadenados por funciones no protegidas que son internos de la red en la nube.
Como ejemplo, un WAF no ayudará si sus funciones se activan desde diferentes fuentes de eventos, como:
· Eventos de almacenamiento en la nube (por ejemplo, AWS S3, Google Cloud Storage, Azure Blob Storage)
· Procesamiento de datos de flujo (por ejemplo, AWS Kinesis)
· Cambios en las bases de datos (por ejemplo, AWS DynamoDB, Azure CosmosDB)
· Modificaciones de código (por ejemplo, AWS CodeCommit)
· Notificaciones (por ejemplo, SMS, correos electrónicos, IoT)
Eso no quiere decir que no deba tener un WAF como primera línea de defensa, pero es un error crítico asumir que el WAF se encarga de todo. Confiar únicamente en un WAF deja muchos agujeros de seguridad que debe resolver con una solución diferente.
Error # 2: no personalizar los permisos de funciones
Establecer políticas con un alcance más amplio y más permisivo de lo que necesita la función es un error de seguridad común sin servidor.
Si no se minimizan los roles y permisos de funciones individuales, su superficie de ataque es más grande de lo necesario. Debe sentarse con los desarrolladores que escribieron las funciones y revisar lo que hace cada función. Solo después de determinar qué funciones deben hacer realmente, puede crear correctamente un rol único para cada función y crear una política de permisos adecuada.
Error # 3: Pensar que su código es todo su código
OK, ahora que cada función está autorizada correctamente, con un enfoque estricto en el mínimo privilegio, debería estar todo listo, ¿verdad?
Aguanta, todavía no. Nuestro siguiente error es pensar que cada código de su aplicación es su código .
En lo que llamamos ‘Envenenamiento del pozo’, los atacantes apuntan a obtener una mayor persistencia a largo plazo en su aplicación mediante un ataque aguas arriba. Las aplicaciones nativas de la nube tienden a comprender muchos módulos y bibliotecas. Los módulos a menudo incluyen muchos otros módulos, por lo que no es raro que una sola función sin servidor incluye decenas de miles de líneas de código de varias fuentes externas, incluso con menos de 100 líneas de código que escribieron sus desarrolladores. Hoy, más del 70% del código de la aplicación utiliza código abierto. Los atacantes buscan incluir su código malicioso en proyectos comunes, por ejemplo, GitHub. Después de envenenar el pozo, esperan pacientemente a que la nueva versión llegue a sus aplicaciones en la nube. No es de extrañar que la mayoría de los controles de seguridad de las aplicaciones integren herramientas como el Análisis de Código Fuente (SCA) al inicio del desarrollo.
En 2017, Black Duck Software, una compañía que comercializa y vende soluciones SCA, publicó un informe, donde los investigadores encontraron que de 1,000 aplicaciones de uso común en la empresa, el 96 por ciento utilizaba software de código abierto y más del 60 por ciento contenía vulnerabilidades de seguridad debido a estos componentes: algunos de los errores encontrados también tenían más de cuatro años.
Error # 4: Pensar que tienes control sobre todas tus funciones
Las vulnerabilidades del código pueden mitigarse mediante la integración cuidadosa de la seguridad de la aplicación en la canalización de CI / CD … pero ¿puede estar seguro de que todas las funciones que ha implementado pasaron por su CI / CD?
Las funciones malintencionadas pueden entrar por diversos medios, lo que puede dificultar la protección de aplicaciones sin servidor. Medios como ser desplegado por un empleado deshonesto. Además, las estaciones de trabajo de sus desarrolladores podrían ser un objetivo para los atacantes, en lugar de las propias aplicaciones implementadas. Para ser justos, los desarrolladores tienden a ser menos susceptibles a las estafas de phishing que algunos. Pero acceder a una estación de trabajo permitiría a los atacantes desplegar funciones maliciosas a través de canales legítimos. Tales funciones podrían colarse y causar estragos, sin ser detectadas.
Error # 5: mirar los indicadores de ataque incorrectos
Como se describe en nuestro blog de análisis de seguridad sin servidor , la visibilidad se vuelve más difícil con sin servidor. El cambio a sin servidor aumenta significativamente la cantidad total de información y la cantidad de recursos, lo que resulta en su incapacidad para dar sentido a todos los datos.
Obtener información de esta montaña de datos es un desafío y, como resultado, también lo es proteger las aplicaciones sin servidor. A medida que la cantidad de funciones continúa aumentando de cientos a incluso miles, es más difícil determinar si todo se comporta de la manera en que se supone que debe hacerlo. Solo unos pocos cientos de funciones pueden generar miles de millones de eventos en su registro todos los días. Con todos esos datos de registro, es difícil filtrar las señales verdaderas importantes y relevantes del ruido irrelevante.
Incluso si está familiarizado con los patrones de ataque que son exclusivos de las aplicaciones sin servidor, el escaneo visual y la correlación de estos datos en un patrón de ataque no es escalable: el aumento del gasto de capital humano para resolver el problema no es práctico. Aquí es donde ayuda la inteligencia artificial y el aprendizaje automático. Hemos demostrado los beneficios de la IA a través de una serie de casos de uso, por ejemplo, autos autónomos, y la IA ahora también está haciendo una gran diferencia, encontrando formas de aumentar la seguridad en la nube.
Error # 6: otorgar funciones todo el tiempo en el mundo
Las funciones deben tener un perfil de tiempo de ejecución ajustado. Es cierto que la creación de tiempos de espera de función sin servidor adecuados a menudo no es intuitiva. La duración máxima de una función puede ser bastante específica para esa función. Debe considerar el tiempo de espera configurado frente al tiempo de espera real. Muchos desarrolladores establecen el tiempo de espera al máximo permitido. ¿Y por qué no? ¯ \ _ (ツ) _ / ¯ No pagamos por ese tiempo, por lo que también podríamos hacerlo.
Porque seguridad.
Si un atacante puede tener éxito con una inyección de código, tiene más tiempo disponible para hacer más daño. Los tiempos de espera más cortos requieren que ataquen con más frecuencia, lo que llamamos un ataque del ” Día de la Marmota “. Eso hace que el ataque sea más visible.
Por lo tanto, reduzca no solo lo que puede hacer una función, sino cuánto tiempo puede ejecutarse.
Recursos adicionales de seguridad sin servidor
Asegurar aplicaciones sin servidor requiere una variedad de herramientas y tácticas, incluida la colaboración entre las personas involucradas en la aplicación y la seguridad. Para obtener más información sobre la seguridad sin servidor, visite la página Comprobar qué es la seguridad sin servidor . También puede leer nuestro último libro electrónico, Principales riesgos de seguridad sin servidor y Estrategias de mitigación .
