Seguridad en la nube: riesgos, arquitectura, disponibilidad e integración con infraestructura local

Entienda cómo la seguridad en la nube, la arquitectura, la disponibilidad, el backup, las redes y la integración con infraestructura local influyen en entornos corporativos híbridos.

¡Descúbrelo!

La seguridad en la nube no depende únicamente del proveedor contratado.

Incluso en entornos robustos, la empresa continúa siendo responsable de decisiones de arquitectura, gestión de accesos, protección de datos, configuración de servicios, integración con redes locales, continuidad operativa y monitoreo.

Por eso, tratar la nube como un lugar automáticamente seguro es un error. La seguridad depende de la forma en que el entorno se planifica, configura, opera e integra con la infraestructura existente.

Este artículo profundiza el clúster de cloud de A3A Engenharia, dando continuidad a los contenidos sobre computación en la nube en la práctica y migración a la nube, ahora con foco en seguridad, arquitectura, disponibilidad e integración con entornos locales.

La seguridad en la nube comienza en la arquitectura

La seguridad en la nube comienza antes de contratar herramientas.

Comienza en la arquitectura: cómo se organizarán los servicios, quién tendrá acceso, qué datos se tratarán, cómo se separarán los entornos, cómo se conectará la red y cómo se gestionarán las fallas.

Una arquitectura en la nube mal planificada puede crear riesgos incluso cuando utiliza servicios de proveedores reconocidos. Permisos excesivos, datos expuestos, falta de segmentación, ausencia de logs, backups insuficientes y configuraciones predeterminadas pueden comprometer el entorno.

Por eso, la arquitectura debe considerar la seguridad desde el inicio. Este principio evita que los controles se agreguen solamente al final, cuando el entorno ya está en operación.

En empresas, este análisis debe involucrar tecnología, operación, gestión de riesgos, LGPD, proveedores, contratos y continuidad del negocio.

Responsabilidad compartida: qué corresponde al proveedor y qué permanece con la empresa

En servicios de nube existe una división de responsabilidades entre proveedor y cliente.

El proveedor normalmente es responsable de partes de la infraestructura física, data centers, hardware, algunos servicios de plataforma y capas operativas del entorno contratado.

La empresa, por su parte, continúa siendo responsable de muchos puntos críticos: usuarios, contraseñas, autenticación, permisos, datos, configuraciones, políticas, integraciones, aplicaciones, backups, clasificación de la información y uso adecuado de los servicios.

Esta división se conoce como responsabilidad compartida.

En la práctica, esto significa que contratar un entorno en la nube no transfiere toda la responsabilidad de seguridad al proveedor.

Un entorno puede ser técnicamente avanzado y aun así vulnerable si la empresa deja cuentas sin autenticación multifactor, expone datos públicamente, concede permisos demasiado amplios o no revisa los accesos.

Para entender los fundamentos de protección de datos, confidencialidad, integridad y disponibilidad, vea también Seguridad de la información: qué es, pilares, riesgos y buenas prácticas.

Control de acceso, identidad y principio de mínimo privilegio

El control de acceso es uno de los puntos más importantes en seguridad en la nube.

Los entornos en la nube suelen permitir la creación rápida de usuarios, claves, integraciones, APIs, máquinas virtuales, buckets, bases de datos y aplicaciones. Esta flexibilidad es útil, pero también aumenta el riesgo de permisos excesivos.

El principio de mínimo privilegio es simple: cada usuario, sistema o servicio debe tener únicamente los accesos necesarios para cumplir su función.

En la práctica, esto exige:

• perfiles de acceso bien definidos;
• autenticación multifactor;
• revisión periódica de permisos;
• eliminación de accesos obsoletos;
• control de cuentas administrativas;
• registro de actividades críticas;
• separación entre entornos de prueba, homologación y producción;
• atención a proveedores y terceros.

Este cuidado es aún más importante en entornos híbridos, donde los usuarios pueden acceder a recursos locales y servicios en la nube desde diferentes redes, dispositivos y ubicaciones.

Disponibilidad, redundancia y continuidad del negocio

Uno de los motivos para adoptar servicios en la nube es mejorar la disponibilidad. Pero la disponibilidad no ocurre automáticamente.

Depende de arquitectura, redundancia, replicación, red, procedimientos, monitoreo y pruebas.

Alta disponibilidad significa reducir puntos únicos de falla. Esto puede involucrar múltiples zonas, redundancia de servicios, balanceo de carga, replicación de datos, enlaces alternativos y planes de contingencia.

La continuidad del negocio va más allá de la tecnología. Pregunta: ¿cómo continúa operando la empresa si un sistema queda indisponible?

Esta pregunta exige analizar procesos, personas, proveedores, contratos, comunicación, prioridades e impacto operativo.

Un entorno en la nube puede contribuir a la continuidad, pero debe diseñarse para ello. Si todos los accesos, datos y servicios dependen de un único punto mal configurado, la nube no resuelve el problema.

Backup en la nube y disaster recovery

Backup en la nube y disaster recovery son temas relacionados, pero no son lo mismo.

Backup es una copia de datos que permite la recuperación en caso de pérdida, falla, eliminación indebida o incidente.

Disaster recovery es la estrategia para restaurar sistemas, servicios y operación después de una falla relevante, indisponibilidad prolongada o desastre.

Un backup puede existir y aun así no ser suficiente para recuperar la operación en el tiempo necesario. Por eso, las empresas deben evaluar tiempo de recuperación, punto de recuperación, criticidad de los sistemas, dependencias y pruebas periódicas.

Algunas preguntas son esenciales:

• ¿qué datos deben recuperarse primero?
• ¿cuál es el tiempo máximo aceptable de indisponibilidad?
• ¿qué pérdida de datos es tolerable?
• ¿los backups se prueban?
• ¿existen copias protegidas contra eliminación o modificación indebida?
• ¿quién activa el plan de recuperación?
• ¿qué sistemas dependen de infraestructura local?

El backup en la nube puede ser una parte importante de la estrategia, pero debe estar conectado a un plan real de continuidad y recuperación.

Latencia, red y desempeño en entornos distribuidos

La arquitectura en la nube depende de la red.

Latencia, pérdida de paquetes, ancho de banda, disponibilidad de enlaces y calidad de la red local influyen directamente en la experiencia de los usuarios y el funcionamiento de los sistemas.

Cuando una aplicación depende de comunicación constante entre sistemas locales y servicios en la nube, el diseño de la red se vuelve crítico.

Esto se aplica a bases de datos, videovigilancia, sistemas de control de acceso, aplicaciones corporativas, integraciones con APIs, backups y plataformas de análisis.

Un proyecto debe considerar:

• redundancia de enlaces;
• segmentación de red;
• enrutamiento adecuado;
• control de tráfico;
• firewalls;
• monitoreo;
• calidad del cableado y de la infraestructura local;
• necesidad de baja latencia para sistemas críticos.

Los contenidos sobre Proyectos de Infraestructura de Red, Tipos de Redes de Computadoras y Desempeño en Redes de Computadoras ayudan a comprender esta base.

Cloud híbrida e infraestructura local: cuándo tiene sentido integrar

Cloud híbrida combina recursos locales y servicios en la nube.

Este modelo tiene sentido cuando no todos los sistemas deben migrarse por completo a la nube, pero la empresa aun así quiere aprovechar flexibilidad, almacenamiento, gestión centralizada, escalabilidad o recursos digitales modernos.

Los entornos híbridos son comunes cuando existen:

• sistemas críticos que necesitan operar localmente;
• equipos físicos integrados con aplicaciones digitales;
• gran volumen de datos generado en campo;
• necesidad de baja latencia;
• requisitos específicos de seguridad;
• entornos industriales u operativos;
• cámaras, control de acceso, sensores y dispositivos conectados;
• backup o replicación en la nube.

El desafío está en la integración. La empresa debe garantizar que identidad, red, seguridad, monitoreo, documentación y soporte funcionen entre ambos mundos.

Una arquitectura híbrida mal integrada puede crear puntos ciegos: sistemas locales sin monitoreo, servicios en la nube sin gobernanza o accesos que no son revisados.

Edge computing: cuándo es mejor procesar cerca del origen

Edge computing es un enfoque en el que parte del procesamiento ocurre cerca del origen de los datos.

Puede ser útil cuando existe necesidad de respuesta rápida, reducción de latencia, operación local o procesamiento de grandes volúmenes de información antes de enviarlos a la nube.

En seguridad electrónica, IoT, automatización, videovigilancia y sistemas distribuidos, no siempre tiene sentido enviar todo inmediatamente a servicios remotos.

Algunas decisiones deben ocurrir cerca del equipo, sensor, cámara, controlador o usuario.

Esto no elimina la nube. Crea una arquitectura distribuida, en la que parte de la inteligencia permanece local y parte se centraliza.

Para comprender el crecimiento de los dispositivos conectados, vea también Internet de las Cosas (IoT).

Gobernanza, costos y control de cambios

Los entornos en la nube pueden crecer rápidamente.

Esta es una ventaja, pero también puede convertirse en un problema cuando no existe gobernanza.

Sin control, los equipos pueden crear recursos innecesarios, mantener servicios sin uso, abrir permisos indebidos, duplicar entornos, elevar costos y dificultar la auditoría.

La gobernanza en la nube involucra reglas, roles, responsables, presupuesto, estándares de configuración, documentación, monitoreo y proceso de cambios.

Algunos puntos importantes son:

• definir responsables por entornos y servicios;
• controlar la creación de recursos;
• acompañar costos recurrentes;
• estandarizar configuraciones;
• registrar modificaciones relevantes;
• revisar accesos periódicamente;
• documentar integraciones;
• evaluar proveedores y contratos.

La gobernanza evita que la nube se transforme en un entorno difícil de controlar.

Riesgos comunes en una arquitectura en la nube mal planificada

Una arquitectura en la nube mal planificada suele generar problemas previsibles.

Algunos de los riesgos más comunes son:

• permisos excesivos;
• datos expuestos por configuración inadecuada;
• ausencia de autenticación multifactor;
• falta de segregación entre entornos;
• dependencia de un único enlace de internet;
• backups no probados;
• costos recurrentes sin control;
• ausencia de logs y monitoreo;
• integraciones sin documentación;
• proveedores sin evaluación adecuada;
• planes de recuperación inexistentes o no probados;
• seguridad tratada únicamente después de la implantación.

Estos riesgos muestran que la seguridad en la nube no es un recurso aislado. Es resultado de arquitectura, proceso y operación.

Cómo la ingeniería reduce riesgos en entornos cloud

La ingeniería reduce riesgos cuando transforma elecciones tecnológicas en proyectos verificables.

Esto significa levantar requisitos, evaluar la infraestructura existente, mapear dependencias, analizar riesgos, definir criterios de desempeño, diseñar la integración, documentar decisiones y validar la implantación.

En entornos cloud, la ingeniería ayuda a conectar decisiones de software con la realidad física y operativa de la empresa: redes, enlaces, energía, salas técnicas, dispositivos, data centers, sensores, cámaras, controladores, usuarios y procesos.

También ayuda a definir límites. No todo necesita ir a la nube. No todo debe permanecer local. La mejor arquitectura es aquella que cumple los requisitos técnicos, operativos, financieros y de seguridad.

Al final, la seguridad en la nube depende de la integración entre personas, procesos, tecnología e infraestructura.