¡Tener el control no es lo mismo que estar seguro!
En primer lugar, una vieja idea de Bruce Schneier: la seguridad es un proceso, no un producto (El proceso de seguridad). Los procesos de seguridad maduros y efectivos requieren constantes recursos / mejoras que cuestan tiempo, dinero, personas (inteligentes), etc.
Supongamos que su aplicación consta de algunos servidores web, bases de datos, un equilibrador de carga y algo de código Ruby on Rails.
- ¿Qué es una descripción simplificada de la nube?
- ¿Qué se puede hacer para asegurarme de que no cruce el límite de uso de la capa gratuita de AWS?
- ¿Para qué utiliza la etiqueta de instancia AWS EC2?
- ¿Cuáles son las experiencias de las personas con Amazon Virtual Private Cloud?
- ¿Cuáles son los límites de Firebase Cloud Functions en comparación con Google App Engine en el contexto de las aplicaciones móviles?
Simplifiquemos su modelo de amenaza y dividamos el riesgo en dos categorías: seguridad de infraestructura / plataforma y seguridad de aplicaciones.
Dado que la seguridad requiere inversiones, digamos que mantener su infraestructura (servidores, red, instalación, etc.) segura requiere X recursos por año, mientras que mantener la aplicación Rails segura requiere Y recursos por año.
En el modelo local, su empresa es responsable de financiar tanto X como Y.
Si está alojado en Elastic beanstalk, X está financiado en su totalidad por AWS, mientras que Y está financiado por su empresa.
Entonces, la pregunta no es si las instalaciones locales son más seguras que AWS.
La pregunta debería ser: ¿cree que su empresa puede invertir suficientes recursos para crear un marco de seguridad maduro? y crees que puedes hacerlo mejor que AWS?