{"id":2148,"date":"2019-11-04T14:56:31","date_gmt":"2019-11-04T14:56:31","guid":{"rendered":"https:\/\/keepler.io\/2019\/11\/04\/10-errores-de-seguridad-habituales-al-trabajar-en-la-nube\/"},"modified":"2023-09-12T13:15:15","modified_gmt":"2023-09-12T13:15:15","slug":"10-errores-de-seguridad-habituales-al-trabajar-en-la-nube","status":"publish","type":"post","link":"https:\/\/keepler.io\/es\/2019\/11\/04\/10-errores-de-seguridad-habituales-al-trabajar-en-la-nube\/","title":{"rendered":"10 errores de seguridad habituales al trabajar en la nube"},"content":{"rendered":"

Cada vez son m\u00e1s las empresas que est\u00e1n migrando sus sistemas de almacenamiento y procesamiento de datos on-premise a la cloud p\u00fablica<\/strong>. Esto supone que gran parte de los datos que manejan tanto grandes como peque\u00f1as organizaciones pase de estar almacenada en data centers corporativos y privados a la nube.<\/p>\n

Una de las principales preocupaciones de estas empresas es garantizar la privacidad y seguridad de la informaci\u00f3n<\/strong> cumpliendo con el Reglamento General de Protecci\u00f3n de Datos (GDPR) que entr\u00f3 en vigor en el a\u00f1o 2018. Para ello, los proveedores cloud como AWS, Google Cloud o Microsoft Azure ofrecen gran cantidad de servicios y herramientas que ayudan a monitorizar y securizar nuestros sistemas<\/strong> de almacenamiento, an\u00e1lisis y procesamiento de grandes cantidades de datos.<\/p>\n

Sin embargo, los temas relacionados con la seguridad, privacidad y conformidad de estos sistemas son una responsabilidad compartida entre el proveedor y el cliente<\/strong>, como queda reflejado, por ejemplo, en el Modelo de Responsabilidad Compartida de AWS<\/a>.<\/p>\n

En Keepler<\/strong> somos expertos en ayudar a grandes clientes corporativos de sectores regulados o con fuertes requisitos de seguridad como banca, seguros, energ\u00eda, telecomunicaciones, retail, farma o industria, a dise\u00f1ar, implementar y refactorizar sistemas de procesamiento de datos en la nube p\u00fablica, siguiendo las mejores pr\u00e1cticas en securizaci\u00f3n y privacidad<\/strong> de la informaci\u00f3n.<\/p>\n

Bas\u00e1ndonos en nuestra experiencia<\/strong> en m\u00faltiples proyectos, a continuaci\u00f3n vamos a explicar las 10 vulnerabilidades m\u00e1s comunes que nos encontramos al auditar entornos de trabajo cloud, concretamente en AWS, y c\u00f3mo podemos evitarlas.<\/p>\nBuenas pr\u00e1cticas en securizaci\u00f3n y privacidad de informaci\u00f3n #seguridad #ciberseguridad #cloud <\/a><\/span>Compartir en X<\/a><\/span>\n

1. Multi-Factor Authentication (MFA) deshabilitado en las cuentas de los usuarios de AWS y pol\u00edtica de contrase\u00f1as no configurada<\/h5>\n

Con MFA deshabilitado<\/strong> facilitas que cualquier atacante que consiga tu contrase\u00f1a pueda acceder a tu cuenta. Esto, unido a una contrase\u00f1a no robusta y a la inexistencia de una pol\u00edtica de rotado<\/strong> de passwords adecuada, facilita el acceso al atacante. Para evitarlo, se debe activar Multi-Factor Authentication<\/strong> en tus cuentas de AWS de modo que, adem\u00e1s de la contrase\u00f1a, se necesite un token de autenticaci\u00f3n generado autom\u00e1ticamente en un dispositivo para acceder a ellas.<\/p>\n

2. Visibilidad de la actividad de nuestras cuentas de AWS insuficiente y descentralizada<\/h5>\n

Uno de los principales errores que cometemos los usuarios de AWS es crear recursos sin activar la monitorizaci\u00f3n y el registro de logs sobre \u00e9stos y sobre nuestra cuenta de AWS en general. No es posible securizar lo que no puedes ver<\/strong> y en esta situaci\u00f3n resulta dif\u00edcil detectar riesgos.<\/p>\n

Para tener un entorno lo m\u00e1s seguro y controlado posible existen algunos servicios de AWS<\/strong> como AWS CloudTrail, AWS CloudWatch, VPC Flow Logs y AWS Guarduty que podemos utilizar.<\/p>\n

Se debe activar AWS CloudTrail<\/strong> para capturar los eventos o llamadas al API de AWS de modo que la informaci\u00f3n sobre las distintas actividades o cambios que realizan los usuarios en todos los servicios de tus cuentas de AWS se registren en ficheros de logs almacenados en buckets de S3 correctamente cifrados y protegidos. Por otro lado, es posible configurar alarmas de CloudWatch<\/strong> para detectar cualquier cambio que se produzca en tu infraestructura, o el uso inadecuado de cualquier recurso. Tambi\u00e9n se debe activar VPC Flow Logs<\/strong>, para monitorizar el tr\u00e1fico de red que circula por nuestra VPC, permitiendo as\u00ed detectar cualquier anomal\u00eda. Adem\u00e1s de esto, podemos a\u00f1adir AWS Guarduty<\/strong> para detectar actividades maliciosas y comportamientos no autorizados mediante el an\u00e1lisis constante de los registros de eventos.<\/p>\n

En definitiva, AWS proporciona potentes herramientas de auditor\u00eda y debemos habilitarlas y utilizarlas para tener un entorno lo m\u00e1s seguro y controlado posible.<\/p>\n

3. Mantener antiguos empleados de tu compa\u00f1\u00eda y AWS Access Keys no utilizadas habilitados en AWS<\/h5>\n

Tanto las Access Key no utilizadas como los usuarios inactivos incrementan el riesgo de que tus datos se vean comprometidos o tus aplicaciones sobre AWS sufran cualquier ataque. Por ello, resulta muy importante establecer regularmente procesos para deshabilitar usuarios inactivos y eliminar las Access Keys<\/strong> que ya no se usen.<\/p>\n

4. Incumplimiento del principio de conceder los menores privilegios posibles<\/h5>\n

Desafortunadamente, los administradores a menudo asignan permisos demasiado permisivos para acceder a los recursos de AWS, lo que permite que los usuarios quiz\u00e1s puedan realizar cambios de configuraci\u00f3n que no deber\u00edan y que si un atacante consigue acceder a la cuenta y obtener dichos permisos haga mayor da\u00f1o en la aplicaci\u00f3n. Por ello, cualquier usuario, grupo o rol de IAM s\u00f3lo debe tener permisos para realizar su trabajo y nada m\u00e1s.<\/p>\n

Para reducir este riesgo, se recomienda asignar pol\u00edticas a grupos o roles de IAM en lugar de usuarios, ya que esto facilita la gesti\u00f3n de permisos en AWS, y cuanto m\u00e1s simple sea esa gesti\u00f3n, m\u00e1s dif\u00edcil ser\u00e1 conceder permisos excesivos a cada entidad de AWS IAM y ser estrictos de cara a asignar \u00fanicamente aquellos permisos necesarios.<\/p>\n

5. Permitir el acceso a puertos de gesti\u00f3n como SSH y RDP desde cualquier punto de Internet<\/h5>\n

Con una configuraci\u00f3n de red demasiado permisiva cualquiera puede acceder al puerto 22 (SSH) o al puerto 3389 (RDP) de tus instancias EC2 en AWS. Esto supone que cualquier atacante, utilizando t\u00e9cnicas como acceso por fuerza bruta, puede conseguir el control de tus servidores, acceder a los datos que en ellos residen o incluso destruir esos datos. Adem\u00e1s, podr\u00edan realizar ataques distribuidos de denegaci\u00f3n de servicio (DDoS) que afecten al funcionamiento de tu sistema y que pueden suponer grandes p\u00e9rdidas de dinero para la empresa.<\/p>\n

Para mitigar estos riesgos<\/strong> se debe realizar las siguientes acciones:<\/p>\n