nube
4 artículos con esta etiqueta
¿Qué es la shadow AI (IA en la sombra)? Los riesgos del uso de IA que tu empresa no ve, y qué deben hacer organizaciones y personas
La shadow AI (IA en la sombra) es que los empleados usen para el trabajo herramientas de IA que la empresa no ha aprobado o no gestiona (chatbots, extensiones de navegador con IA, asistentes de programación, IA para actas de reuniones, agentes de IA conectados a cuentas de trabajo). Es la forma IA de la shadow IT. Los riesgos principales: los datos confidenciales o personales introducidos pueden quedar almacenados en el proveedor y, según el plan y los ajustes, usarse para entrenamiento (las condiciones de consumo y de empresa difieren); las autorizaciones OAuth y las claves de API dan a herramientas de terceros acceso al correo y a las unidades; los errores de la salida y los problemas de licencias; y las obligaciones de privacidad y auditoría. Prohibirla sin más empuja el uso fuera de la vista, así que ofrece una herramienta aprobada con condiciones de empresa que no entrenen con las entradas, una regla breve sobre qué datos pueden introducirse, SSO y controles de administración, revisión periódica de autorizaciones OAuth y extensiones, y un canal para preguntar antes.
Toma de control de subdominios (DNS colgante): cómo un registro DNS olvidado permite a un atacante usar tu dominio
Si borras un recurso en la nube sin borrar el registro DNS, te queda una entrada colgante: cualquiera puede apropiarse de ese subdominio creando un recurso con el mismo FQDN. Tus servidores no se tocan, mientras un subdominio legítimo sirve contenido del atacante. El daño no es solo de apariencia: las aplicaciones suelen exponer las cookies de sesión a todos los subdominios mediante un comodín, así que el subdominio secuestrado puede leerlas. Y la documentación rechaza de forma explícita la creencia de que un certificado te protege. La solución es integrar el orden de borrado en tus procedimientos y herramientas en lugar de fiarlo a la memoria.
Qué es la SSRF (Server-Side Request Forgery, falsificación de solicitudes del lado del servidor)
La SSRF abusa de URLs de entrada externa para hacer que un servidor acceda a recursos internos (IPs internas, metadatos de la nube). Si recuperas URLs, necesitas una lista de destinos permitidos, bloqueo de objetivos internos y protección frente a las elusiones por redirección/reenlace de DNS. Fue la causa de la brecha de Capital One.
Filtración de Capital One (2019) — cómo un SSRF expuso más de 100M de registros, y cómo defenderse
Un solo SSRF alcanzó el endpoint de metadatos → credenciales IAM temporales con privilegios excesivos → copia masiva de S3, filtrando ~106M de registros. Cada paso pudo haberlo detenido. En tu entorno: IMDSv2, IAM de mínimo privilegio y una lista de permitidos para las peticiones salientes.