Seguridad en la nube y SaaS

Es el reparto de obligaciones de seguridad entre el proveedor de nube y usted, y la mayoría de los incidentes en la nube ocurren en su lado de la línea. El proveedor protege lo que opera: centros de datos, hardware, la red entre ellos y, según el servicio, el sistema operativo y la propia aplicación. Usted sigue siendo responsable de cómo lo usa: quién tiene cuentas y con qué permisos, la autenticación multifactor (MFA), cómo se configuran el almacenamiento y los servicios, qué datos coloca allí, sus propias aplicaciones y sus parches, y sus copias de seguridad. La línea se mueve según el tipo de servicio. Con servidores virtuales alquilados gestiona casi todo por encima del hardware; con un producto SaaS como un paquete ofimático gestiona sobre todo identidades, ajustes de compartición y datos. Lea la matriz de responsabilidades de su proveedor, asigne cada elemento a un responsable con nombre en su empresa y revísela con cada servicio nuevo. Los certificados de un proveedor cubren su parte, no su configuración.

Describen cuánta parte de la pila gestiona el proveedor por usted y, por tanto, cuánto trabajo de seguridad le queda. Con la infraestructura como servicio (IaaS) alquila servidores virtuales, almacenamiento y redes; usted instala y parchea el sistema operativo, configura cortafuegos y ejecuta sus aplicaciones, así que el trabajo de seguridad se parece al de tener servidores propios. Con la plataforma como servicio (PaaS) el proveedor gestiona el sistema operativo y el entorno de ejecución, como una base de datos gestionada o una plataforma de aplicaciones; usted sigue siendo responsable de su código, la configuración, las identidades y los datos. Con el software como servicio (SaaS) usa una aplicación terminada, como correo, CRM o contabilidad; su parte es sobre todo quién tiene acceso, con qué permisos y autenticación multifactor, cómo se comparten los datos, y guardar su propia copia de los datos importantes. Muchas empresas usan los tres a la vez. Asigne cada servicio a su tipo, porque las preguntas de un auditor o una aseguradora son distintas para cada uno, igual que los registros que puede obtener.

Puede, en lo que asume el proveedor, pero traslada el riesgo más que eliminarlo. Un gran proveedor parchea su infraestructura, tiene centros de datos redundantes y emplea equipos de seguridad que pocas medianas empresas podrían pagar, así que la seguridad física, los fallos de hardware y la disponibilidad básica suelen mejorar. Lo que no se traslada es la responsabilidad sobre identidades, configuración y datos, que quedan más expuestos: una cuenta de administración en la nube es accesible desde cualquier punto de internet, un ajuste de almacenamiento puede publicar ficheros al mundo con un clic y una contraseña robada sin autenticación multifactor lo abre todo a la vez. Los atacantes han seguido a las empresas a la nube, y muchos de los incidentes que provocan allí empiezan con una cuenta robada por phishing o una clave de acceso filtrada. Migrar con seguridad significa MFA en todas las cuentas, mínimo privilegio para los administradores, registros activados y revisados, copias de seguridad que usted controla y alguien responsable de la configuración de la nube. La red de la oficina también sigue importando: portátiles, impresoras y servidores que quedan allí suelen ser el primer punto de apoyo de un atacante.

Las conexiones entre sus equipos y la nube, no lo que ocurre dentro de la nube. Un sensor en la red de la oficina o un agente en un servidor ve qué equipos se conectan a qué servicios en la nube y SaaS, cuándo, con qué frecuencia y cuántos datos se mueven en cada sentido, además del nombre del servidor en el handshake TLS donde se capturan paquetes. Eso basta para notar un portátil que sube gigabytes a un servicio de almacenamiento que nunca usó, un servidor que contacta cada pocos minutos con una máquina alquilada en la nube o un equipo que habla con una región inesperada. No ve lo que hacen los usuarios dentro de una aplicación SaaS, como compartir una carpeta públicamente, crear una regla de reenvío o dar a una aplicación acceso a un buzón; no ve el tráfico entre servicios en la nube; y no ve al personal que teletrabaja con equipos no gestionados. Eso sale de los registros de auditoría y las consolas de administración del propio proveedor. NetSenX cubre la parte de red: beaconing, escaneos, movimiento lateral y volumen saliente inusual en todos los planes. No sustituye los registros de su proveedor de nube.

En parte: ve el comportamiento de red de los servidores Linux que llevan su agente, estén donde estén, pero no lee el plano de control de su proveedor de nube. El agente de NetSenX funciona en Linux y macOS, así que un servidor virtual Linux que usted gestiona en un proveedor de nube puede llevarlo como cualquier otra máquina Linux; el agente ve entonces las conexiones de ese servidor, y las detecciones básicas se aplican en todos los planes: beaconing hacia un servidor de mando y control, escaneos, movimiento lateral hacia otros servidores y volumen de datos saliente inusual. Cada servidor así cuenta como un dispositivo de su plan. Quedan fuera: los servicios gestionados que usted no opera, como bases de datos, funciones sin servidor y almacenamiento; el tráfico entre servicios en la nube que nunca pasa por un servidor con agente; y todo lo de la capa de gestión del proveedor, como los inicios de sesión en cuentas, los cambios de permisos y la configuración. Para eso, active los registros de auditoría y de flujo del propio proveedor y envíelos adonde alguien los revise. Combinar ambas vistas le da el comportamiento de red de sus servidores y la actividad de cuentas a su alrededor.

Mirando quién es el destino, cómo se comporta la conexión y si algo en su negocio la explica. A los atacantes les gustan los servidores alquilados en la nube porque cualquiera puede crear uno en minutos y la dirección pertenece a un proveedor de prestigio, así que el nombre del proveedor por sí solo no demuestra nada. Mejores preguntas: ¿coincide el destino con un servicio que usa, por su nombre en el handshake TLS o en el DNS, y está ese servicio en su lista de proveedores? ¿Es la conexión regular, pequeña y a todas horas, como un programa que se reporta, en lugar de estar impulsada por personas en horario laboral? ¿Empezó justo después de algo inusual en ese equipo, como un programa nuevo o un inicio de sesión desde el extranjero? ¿Un servidor que normalmente solo recibe conexiones empieza de pronto a abrirlas hacia fuera? Un servicio legítimo de copias o de monitorización suele tener un destino documentado y un contrato; una máquina virtual desconocida a la que un puesto de trabajo contacta cada cinco minutos, no. NetSenX señala en todos los planes ese patrón de contacto regular, llamado beaconing, y el volumen saliente inusual, con el destino, para que pueda preguntar al responsable adecuado.

Averígüelo primero por las conexiones y pregunte después al responsable de cada servidor, porque la mayoría de esas conexiones tienen una explicación aburrida y unas pocas no. Razones legítimas son servicios de monitorización y copias, réplicas de actualizaciones, la API de un proveedor, la máquina de pruebas de un desarrollador o un proveedor SaaS alojado en un operador barato. Las señales preocupantes son lo contrario: un servidor sin ninguna razón de negocio para hablar con internet, conexiones que se repiten a intervalos fijos día y noche, tráfico que empezó tras un incidente o una instalación nueva y destinos que nadie en la empresa reconoce. Los servidores virtuales alquilados en proveedores baratos son un lugar habitual para los servidores de mando de los atacantes y para acumular datos robados, precisamente porque son baratos, rápidos y anónimos de alquilar. Mantenga la lista de destinos esperados por servidor, revísela con los responsables y bloquee el tráfico saliente de los servidores que no lo necesiten. En todos los planes, NetSenX muestra las conexiones de sus equipos con sus destinos y alerta de beaconing y volumen saliente inusual, que son los patrones que más importan aquí.

Sí, y lo hacen, porque el tráfico hacia un servicio en la nube conocido rara vez se bloquea o se cuestiona. El malware puede recoger instrucciones de un fichero en una cuenta pública de almacenamiento en la nube, un documento compartido, un sitio de alojamiento de código, la interfaz de bots de una app de mensajería o una red de distribución de contenidos, y devolver los datos robados por el mismo camino. Para un cortafuegos que juzga los destinos por su reputación, parece un empleado normal usando un servicio popular. Lo que aún lo delata es el comportamiento. Un programa que consulta un fichero en la nube a intervalos regulares, día y noche, desde un equipo cuyo usuario no está trabajando, tiene un ritmo que las personas no tienen; las subidas pueden ser inusualmente grandes para ese equipo; y la huella del cliente en el handshake TLS puede no coincidir con un navegador ni con la app oficial del servicio. Pasos prácticos: permita solo los servicios en la nube que usa el negocio, por inquilino (tenant) cuando sus herramientas lo permitan, e investigue los equipos que hablan con cuentas personales de servicios populares. NetSenX detecta beaconing y volumen saliente inusual en todos los planes, sea cual sea el destino, y huellas TLS desde el plan Starter allí donde el agente captura paquetes.

Compare la transferencia con lo que ese equipo hace normalmente y con las herramientas que su empresa usa de verdad. Un cliente de sincronización que envía ficheros al servicio de almacenamiento aprobado sigue un patrón: funciona en los puestos de quienes lo usan, su volumen sube y baja con el horario laboral y el destino es el servicio que usted paga. El robo de datos suele diferir al menos en algo: es un servidor, y no un puesto, el que sube mucho; el destino es una cuenta de almacenamiento personal o desconocida, un sitio para compartir ficheros o un servidor alquilado; el volumen supera con creces el nivel habitual de ese equipo; ocurre de noche o en fin de semana; o sigue a otras señales de alerta, como escaneos o nuevos inicios de sesión de administradores. Las herramientas que usan los atacantes para ello, como utilidades de sincronización por línea de comandos, a menudo parecen una copia de seguridad legítima. Pregunte primero al responsable del equipo y revise después los registros del proveedor de almacenamiento sobre la cuenta usada. En todos los planes, NetSenX alerta del volumen de datos saliente inusual por equipo y muestra el destino; no ve qué ficheros se enviaron.

Puede ver si un equipo de la empresa envía cantidades inusuales de datos a servicios en la nube, que suele ser la señal temprana más útil, pero no quién lo hizo ni qué ficheros eran. En las semanas antes de que alguien se vaya, un aumento fuerte de subidas desde su portátil a un almacenamiento personal, a un sitio de transferencia de ficheros o a una herramienta de IA merece una conversación, sobre todo a horas extrañas. Un buen proceso de salida importa más que la detección: acordar por escrito qué se queda en la empresa, retirar el último día el acceso a cuentas SaaS y en la nube, revocar tokens y contraseñas de aplicación, revisar enlaces compartidos y reglas de reenvío en correo y almacenamiento, y recoger los equipos. La prevención de pérdida de datos y los registros de auditoría de sus servicios de almacenamiento y correo pueden mostrar nombres de ficheros; un sensor de red no. Mantenga cualquier revisión proporcionada, centrada en equipos y datos de la empresa, y acordada con RR. HH. y, cuando proceda, con la representación de los trabajadores, porque la vigilancia del personal está regulada en todos los países de la UE. En todos los planes, NetSenX alerta del volumen de datos saliente inusual de un equipo y muestra el destino.

Sí, sobre todo a través de los equipos y las cuentas que los sincronizan o administran. Cuando un ransomware cifra ficheros en un portátil cuyas carpetas se sincronizan con un almacenamiento en la nube, el cliente de sincronización sube fielmente las versiones cifradas, así que las copias en la nube también cambian. Un atacante con una cuenta de administración robada puede borrar o cifrar datos directamente en el servicio, eliminar copias y versiones, o sacarlo todo primero y amenazar con publicarlo. Lo que ayuda: mantenga activado el control de versiones de ficheros con historial suficiente y sepa cómo revertir una carpeta entera de una vez; proteja las cuentas de administración con autenticación multifactor resistente al phishing y sepárelas de las cuentas del día a día; active la protección contra borrado o los bloqueos de retención donde el servicio los ofrezca; tenga una copia de seguridad independiente que los mismos administradores no puedan eliminar; y limite la sincronización a las carpetas que la gente necesita. Vigile los pasos previos al cifrado, porque ahí aún puede intervenir: en todos los planes, NetSenX detecta beaconing, escaneos, movimiento lateral y volumen saliente inusual, incluidas las subidas grandes a almacenamiento en la nube. No ve las acciones en la consola de administración del servicio en la nube.

Normalmente no de la forma que usted necesita. Los proveedores SaaS protegen su servicio frente a sus propios fallos, con almacenamiento redundante y recuperación ante desastres, pero en general no prometen restaurar sus datos tras algo que usted o un atacante hayan hecho dentro de su cuenta. Los elementos borrados permanecen en papeleras e historiales de versiones durante un tiempo limitado y luego desaparecen; un ataque de ransomware que cifra ficheros sincronizados, un administrador malintencionado que borra buzones o un error de sincronización que sobrescribe una carpeta pueden superar esos plazos; y cuando termina una suscripción o una licencia de usuario, los datos pueden eliminarse. Lea las condiciones de su proveedor: la mayoría describe este reparto como parte de la responsabilidad compartida. Si los datos importan, tenga su propia copia: un servicio de copias o una exportación que copie correo, ficheros y datos clave de aplicaciones a un almacenamiento que los administradores del SaaS no puedan borrar, conservada el tiempo que exijan sus necesidades de negocio y legales. Pruebe al menos una vez a restaurar un buzón y una carpeta, porque ahí aparecen los huecos. Un sensor de red no ayuda aquí; es planificación de copias y conservación.

Empiece por las identidades, porque la mayoría de las tomas de cuentas comienzan con una contraseña robada por phishing o reutilizada. Lo esencial, por orden: autenticación multifactor para todos los usuarios, con métodos resistentes al phishing como llaves de seguridad o passkeys para los administradores; cuentas de administración separadas, usadas solo para administrar, y el menor número posible de administradores globales; protocolos de autenticación heredados que eluden la MFA desactivados; políticas de inicio de sesión que bloqueen ubicaciones de riesgo o equipos no gestionados si su licencia lo permite; registros de auditoría activados y conservados el tiempo suficiente para investigar; alertas sobre nuevas reglas de reenvío de correo, nuevos roles de administración y nuevos consentimientos a aplicaciones OAuth; límites al uso compartido externo y a las aplicaciones de terceros que los usuarios pueden conectar; y una copia del correo y los ficheros fuera del proveedor, porque sus papeleras no son una copia de seguridad. Revise roles de administración y cuentas de invitados cada trimestre. Casi todo es configuración que ya paga. Un sensor de red no ve lo que pasa dentro de estos servicios; lo que aporta es la vista de los equipos que se conectan a ellos, como un portátil que empieza a hacer beaconing después de que alguien abriera un adjunto de phishing.

Es un ataque en el que se engaña a la víctima para que conceda a una aplicación maliciosa acceso a su cuenta, en lugar de entregar la contraseña. El usuario recibe un enlace a lo que parece una aplicación útil o una solicitud de documento, inicia sesión en la página real de Microsoft o Google y hace clic para aprobar permisos como leer el correo, los ficheros o los contactos. A partir de ahí, la aplicación del atacante tiene un token que funciona sin contraseña y que a menudo sobrevive a un cambio de contraseña y a la autenticación multifactor, porque el usuario dio su consentimiento. Es eficaz precisamente porque todas las páginas que ve la víctima son auténticas. Defensas: restrinja el consentimiento de los usuarios para que solo editores verificados o aplicaciones aprobadas por un administrador puedan recibir acceso, exija revisión de un administrador para los permisos de alto riesgo, active alertas sobre nuevos consentimientos y revise con regularidad la lista de aplicaciones conectadas, eliminando lo que nadie reconozca. Si encuentra una autorización maliciosa, revoque la aplicación y sus tokens y revise después en los registros de auditoría a qué accedió. Un sensor de red no ve los consentimientos, que ocurren en el proveedor de identidad; ahí es donde van los controles.

Los que necesitará para responder qué pasó tras un incidente: quién inició sesión, qué cambió y a qué datos se accedió. En cada servicio en la nube o SaaS, compruebe que estén activados: los registros de inicio de sesión con ubicación y dispositivo; los cambios de administración y configuración, como nuevos roles, políticas, reglas de reenvío y consentimientos a aplicaciones; el acceso a ficheros y buzones cuando el servicio lo ofrezca; la actividad de API en cuentas de nube; y los registros de flujo de red de sus redes en la nube si tiene servidores allí. Después compruebe cuánto tiempo se conserva cada uno por defecto, porque algunos servicios solo guardan una ventana corta salvo que pague más o los exporte. Guarde copias donde los administradores de ese servicio no puedan borrarlas, para que un atacante con permisos de administración no pueda borrar el rastro. Decida quién los revisa y qué eventos generan una alerta. La notificación de incidentes según NIS2 y el RGPD, y su aseguradora, esperarán que reconstruya una cronología. Un sensor de red aporta el lado de los equipos: NetSenX conserva las alertas durante el periodo que incluye su plan, con equipos, destinos y horas.

Normalmente nada bueno, y rápido, porque los atacantes rastrean sin parar los repositorios públicos de código en busca de claves. Una clave de acceso a la nube o un token de API funciona como una contraseña que nunca pide autenticación multifactor; quien la tenga puede usar la cuenta con los permisos de esa clave desde cualquier lugar. El abuso típico va desde arrancar capacidad de cómputo cara para minar criptomonedas hasta copiar buckets de almacenamiento y bases de datos, o crear usuarios nuevos para que el atacante conserve el acceso tras revocar la clave. Las filtraciones se producen por código subido a repositorios públicos o compartidos, ficheros de configuración en copias de seguridad, capturas de pantalla, registros de CI y mensajes de chat. Si ocurre: revoque o rote la clave de inmediato, no después de investigar; revise los registros de actividad de la cuenta en busca de todo lo hecho con ella desde la filtración, incluidos usuarios, claves y recursos nuevos en regiones inusuales; elimine lo que haya creado el atacante; y revise la facturación. Para evitarlo, use el escaneo de secretos en sus repositorios, credenciales de corta duración en lugar de claves permanentes, permisos estrechos por clave y alertas de presupuesto. Un sensor de red no puede ver una clave publicada en internet; sí puede ver las consecuencias en los servidores que vigila.

Es almacenamiento en la nube que puede leer, o incluso escribir, más gente de la prevista, a menudo cualquiera en internet. Los servicios de almacenamiento de objetos permiten compartir públicamente un bucket o contenedor con un solo ajuste o un enlace, algo útil para las imágenes de una web y peligroso para copias de seguridad, exportaciones, facturas o ficheros de clientes. Muchas exposiciones de datos que salieron en prensa no fueron ataques, sino ficheros encontrados por alguien que buscaba buckets abiertos. Se evita con algunos hábitos: active en el proveedor el bloqueo del acceso público para toda la cuenta, salvo que un bucket deba ser realmente público, y guarde el contenido público en buckets separados con nombres claros; prefiera enlaces firmados con caducidad al uso compartido público; cifre los datos y limite quién puede cambiar los ajustes de compartición; use las comprobaciones de configuración del proveedor o una herramienta de postura que señale el almacenamiento público; y revise los enlaces compartidos del almacenamiento SaaS, como los que funcionan para cualquiera que los tenga. Compruébelo tras cada proyecto nuevo, porque los buckets de pruebas son un culpable habitual. Un sensor de red no ve los ajustes de los buckets; eso corresponde a la gestión de la configuración de la nube.

Es una dirección interna especial en cada máquina virtual en la nube desde la que la máquina puede leer información sobre sí misma, incluidas credenciales temporales para los permisos que tiene asignados. El software que funciona en el servidor usa esas credenciales para llegar al almacenamiento, a bases de datos y a otros servicios en la nube sin guardar una contraseña en su configuración, lo cual es una buena práctica. El riesgo es que cualquier cosa capaz de hacer que el servidor envíe una petición web a esa dirección puede leer también las credenciales. Una vía habitual es la falsificación de peticiones del lado del servidor (SSRF): un fallo en una aplicación web que permite a un atacante hacer que el servidor descargue una URL que él elige. Con las credenciales, el atacante actúa en su cuenta de nube con los permisos del servidor. Defensas: exija la versión más reciente, basada en sesión, del servicio de metadatos donde su proveedor la ofrezca, porque bloquea peticiones falsificadas simples; dé a cada rol de servidor solo los permisos que necesita; corrija los fallos SSRF y valide las URL que descargan las aplicaciones; y configure alertas cuando se usen credenciales del rol de un servidor desde fuera de su entorno, algo que pueden mostrar los registros de actividad del proveedor.

Normalmente primero en la factura, por eso las alertas de presupuesto son la detección más barata que puede configurar. Los atacantes que obtienen credenciales de nube suelen arrancar muchas máquinas virtuales o contenedores potentes, a menudo en regiones que nunca usa, para minar criptomonedas a su costa. Señales: un aumento repentino del gasto en cómputo o del número de instancias, máquinas con tipos de GPU que nadie pidió, recursos nuevos en regiones desconocidas, claves de acceso o usuarios nuevos creados por las mismas fechas y servidores funcionando a plena CPU día y noche. En un servidor que gestiona usted, un proceso de minería se ve también en la red: conexiones constantes y duraderas con pools de minería, a menudo en puertos inusuales, desde una máquina que normalmente solo atiende peticiones web. Responda revocando las credenciales usadas, eliminando lo que haya creado el atacante en todas las regiones, buscando mecanismos de persistencia como usuarios, roles y funciones programadas nuevos, y preguntando al proveedor por los cargos. NetSenX ve el comportamiento de red de los servidores que llevan su agente, como conexiones regulares con un destino desconocido; no vigila su factura de nube ni los recursos sin agente.

Combine varias fuentes baratas, porque ninguna lo ve todo. El proveedor de identidad muestra en qué aplicaciones inicia sesión la gente con su cuenta de empresa, incluidas las aplicaciones OAuth conectadas al correo o a los ficheros. Las notas de gastos y los extractos de tarjetas revelan suscripciones compradas por los equipos. La gestión de navegadores y equipos puede listar las extensiones y aplicaciones de escritorio instaladas. Los registros DNS y los del cortafuegos o el proxy muestran a qué servicios llegan los equipos de la empresa. Después ordene la lista: herramientas que duplican una aprobada, herramientas que guardan datos de la empresa o de clientes y las inofensivas. Para cada herramienta que trata datos, decida aprobarla como es debido, con contrato y control de administración, sustituirla o retirarla, y explique el porqué a los usuarios. Hacerlo una vez por trimestre mantiene la lista corta. Una vista de red ayuda en la parte de conexiones: NetSenX muestra qué equipos se conectan a qué destinos, con una vista específica de servicios de IA desde el plan Pro; no identifica cada aplicación SaaS por su nombre y no ve los inicios de sesión ni los consentimientos de aplicaciones, que están en el proveedor de identidad.

Son tres tipos de herramientas de seguridad en la nube que miran cosas distintas. La gestión de la postura de seguridad en la nube (CSPM) revisa la configuración de sus cuentas de nube, como almacenamiento público, reglas de cortafuegos abiertas, falta de cifrado o permisos demasiado amplios, frente a las buenas prácticas, y avisa de las desviaciones. La gestión de la postura de seguridad SaaS (SSPM) hace lo mismo con las aplicaciones SaaS, comprobando ajustes como la MFA obligatoria, el uso compartido externo y los roles de administración. Un agente de seguridad de acceso a la nube (CASB) se sitúa entre los usuarios y los servicios en la nube, mediante un proxy o las API de los proveedores, para descubrir qué servicios se usan y aplicar políticas, como bloquear la subida de datos sensibles. Necesitarlos depende de la escala. Una empresa con una cuenta de nube y un paquete ofimático suele llegar lejos con las recomendaciones integradas y los paneles de puntuación de seguridad de los proveedores, sin coste adicional. Varias cuentas de nube, muchas herramientas SaaS o datos regulados hacen más rentables las herramientas dedicadas. Ninguna observa el comportamiento de los equipos de su red; esa es otra capa, que cubre la detección de red.

Haga preguntas cuyas respuestas pueda comprobar y que importen si algo sale mal. Evidencias: qué informes o certificados independientes cubren el servicio que compra, como un informe SOC 2 Tipo II o un certificado ISO/IEC 27001, con alcance y fecha, y si puede leerlos. Datos: dónde se almacenan y tratan, qué subencargados intervienen, si se usan para entrenar modelos, cuánto tiempo se conservan y cómo los recupera en un formato útil cuando se vaya. Acceso: inicio de sesión único, MFA obligatoria, permisos por roles y registros de auditoría exportables. Incidentes: con qué rapidez le avisan, por qué canal y qué apoyo le dan para sus propias obligaciones de notificación según el RGPD o NIS2. Resiliencia: copias de seguridad, objetivos de recuperación y cómo se protegen frente al mal uso de una cuenta de administración. Vulnerabilidades: cómo gestionan los avisos y con qué rapidez parchean. Lleve las respuestas clave al contrato o al contrato de encargo del tratamiento, no solo a un cuestionario. Un proveedor más pequeño con respuestas claras y honestas puede ser más seguro que uno grande con respuestas vagas.

Normalmente los dos, por cosas distintas. El proveedor es responsable de proteger su servicio y, según el RGPD, un proveedor que actúa como su encargado del tratamiento debe notificárselo sin dilación indebida tras tener conocimiento de una violación de la seguridad de los datos personales. Usted, como responsable de los datos de sus clientes o empleados, sigue encargándose de evaluar el riesgo para los afectados y, cuando proceda, de notificarlo a la autoridad de control en un plazo de 72 horas desde que tenga conocimiento, y de informar a los interesados si el riesgo es alto. Si su empresa está sujeta a NIS2, un incidente significativo causado por un proveedor puede activar sus propias obligaciones de notificación, y NIS2 espera que gestione la seguridad de la cadena de suministro como parte de sus medidas de gestión de riesgos. Los contratos deciden gran parte de la práctica: plazos de aviso, cooperación, información que recibirá y responsabilidad. Prepárese antes: sepa qué proveedores tienen qué datos, guarde sus contactos de seguridad e incluya una brecha en un proveedor en su plan de respuesta a incidentes. Su ley nacional de transposición de NIS2 puede añadir detalles; consúltela.

No de gestionarla, pero sí de gestionar el riesgo que le genera, si su empresa está sujeta a NIS2. La Directiva (UE) 2022/2555 incluye la seguridad de la cadena de suministro, incluidos los aspectos de seguridad de las relaciones con proveedores directos y prestadores de servicios, entre las medidas de gestión de riesgos de ciberseguridad del artículo 21. En la práctica significa saber de qué proveedores de nube y SaaS dependen sus servicios importantes, evaluar su seguridad, incluir requisitos en los contratos y planificar su caída o su compromiso. Los proveedores de servicios de computación en nube figuran ellos mismos en NIS2 como entidades del sector de infraestructura digital, así que muchos tienen sus propias obligaciones, lo que ayuda pero no sustituye su evaluación. Pruebas útiles de los proveedores son informes de auditoría independientes, certificaciones con un alcance claro, compromisos de notificación de incidentes y condiciones de salida. Lleve un registro de proveedores que indique los datos y servicios que respalda cada uno y revíselo cada año y tras los incidentes. Las transposiciones nacionales pueden añadir requisitos o guías; consulte la ley de su país y las publicaciones de su autoridad.

Primero contener, después averiguar qué pasó, y dejar constancia de todo sobre la marcha. Contención: restablezca la contraseña y revoque todas las sesiones y tokens activos de la cuenta; elimine los métodos MFA que no registró usted y vuelva a registrarlos; busque y borre nuevas reglas de reenvío, consentimientos a aplicaciones, claves de API, usuarios o roles de administración creados por el atacante; y si era una cuenta de administración, revise todo el inquilino o la cuenta de nube, porque los atacantes crean puertas traseras. Investigación: use los registros de inicio de sesión y de auditoría del proveedor para establecer cuándo empezó el acceso, desde dónde y qué se leyó, cambió, compartió o descargó; compruebe si la misma contraseña se usaba en otros sitios. Después decida las obligaciones: el acceso a datos personales puede suponer una notificación según el RGPD en un plazo de 72 horas desde que tenga conocimiento, y un incidente significativo puede tener que notificarse según NIS2 en su país. Mire también los equipos: la contraseña robada a menudo procedía de un portátil infectado o de una página de phishing. En todos los planes, NetSenX puede mostrar si algún equipo de su red empezó por esas fechas a hacer beaconing, escaneos o envíos inusuales. No ve los inicios de sesión de la cuenta en la nube.