El acceso, registro y permanencia en la plataforma es totalmente gratuito. Además existen varios productos (DNS…) y herramientas que se ofrecen a coste 0€.
Te damos 7 días de prueba tras tu registro. Despliega en la plataforma tantos servicios como quieras, pruébalos y mantenlos tras el trial si te han convencido.
Te pedimos tu tarjeta de crédito para asegurarnos de que no eres un robot. Tres días antes de finalizar el periodo de prueba (7 días) te haremos llegar un mensaje para que determines si quieres mantener los servicios o darlos de baja.
Actualmente, casi cualquier aplicación o software necesita de una base de datos para funcionar.
Una base de datos es simplemente un conjunto de información estructurada que permite la consulta de los datos de forma ordenada y precisa. Su uso está muy extendido y generalmente se ha implementado como una solución instalada en un servidor, local o remoto.
La irrupción de la tecnología Cloud Computing ha cambiado las cosas. En 2009, AWS presentó su servicio RDS y con él surgió lo que actualmente se conoce como DBaaS, base de datos como servicio o base de datos administrada.
Este servicio (o modalidad) de base de datos permite a los usuarios almacenar, administrar y recuperar sus datos estructurados, no estructurados y semiestructurados mediante una plataforma en la nube, accesible desde internet.
¿Por qué utilizar una base de datos en la nube? Características clave
El paso a la nube implica aprovechar muchas de las características de esta tecnología en las bases de datos. De esta manera, la base de datos como servicio tienen unas particularidades frente al modelo de base de datos tradicional que es interesante resaltar:
Escalabilidad . Cualquier solución cloud, DBaaS incluida, está preparada para incrementar y reducir los recursos asignados en cualquier momento. Esta escalabilidad abarca desde crecimientos graduales de consumo hasta picos de consultas en momentos puntuales.
Replicación . Una arquitectura distribuida, típica de los servicios en la nube, beneficia y mucho a las bases de datos. Replicando instancias se consigue gestionar accesos concurrentes sin saturar el sistema y conservando la integridad de la información en todo momento.
No existe el concepto: almacenamiento físico. La ‘caída’ del servidor es una incidencia clásica en una base de datos tradicional, impidiendo el acceso a la misma y bloqueándose así el servicio. Sin embargo, las bases de datos en la nube (BDaaS) no están atadas al funcionamiento de un servidor en concreto y, por tanto, su fiabilidad y resiliencia son mayores.
Seguridad . Todo servicio cloud cuenta con medidas de seguridad y protección frente a ataques: Firewalls perimetrales, Anti DDOS, encriptación de datos… Además de un sistema de backups que respalda la información en todo momento y asegura su recuperación.
Tipos de bases de datos
Una situación bastante común en todas las empresas surge a la hora de elegir la base de datos. ¿Qué tipo de base de datos es mejor?, ¿cuál debería elegir? Esta duda existe porque hay dos tipos de bases de datos: las relacionales (SQL) y las no relacionales (NoSQL).
En este tipo de elecciones, la utilidad final y el tipo de proyecto son, sin ninguna duda, los principales condicionantes a valorar. No obstante, es importante definir y plasmar las características básicas de cada una para comprender mejor en qué consisten:
Bases de datos SQL (relacionales). Son un conjunto de datos organizados en tablas formalmente descritas, desde donde se puede acceder a los datos o volver a estructurarlos de muchas maneras diferentes sin tener que reorganizar las tablas de base. Trabajan con el Lenguaje de Consultas Estructuradas (SQL) .
Las bases de datos relacionales son, en líneas generales, más robustas y menos vulnerables, siendo sus principales características la atomicidad, la consistencia, el aislamiento y la durabilidad.
Bases de datos NoSQL (no relacionales). Están diseñadas concretamente para modelos de datos específicos y tienen esquemas flexibles para crear aplicaciones modernas. Pueden ejecutarse en la nube y están diseñadas para servir cargas pesadas de lectura y escritura, siendo capaces de escalar hacia arriba y hacia abajo con facilidad y más adecuadas para funcionar de forma nativa en la nube.
¿Cuándo es recomendable utilizar una BBDD NoSQL (no relacional)?
Cuando por detrás hay una aplicación que hace muchas consultas/lecturas de grandes cantidades de datos.
Cuando el volumen de datos crece muy rápidamente en momentos puntuales o las necesidades de proceso no se pueden prever.
Cuando no hay necesidad de que los datos sean consistentes.
Si los datos a almacenar no disponen de una estructura fija.
Eso sí, una misma aplicación o software puede usar una BBDD relacional y una BBDD no relacional y guardar información diferente en cada una de ellas.
Algunos ejemplos de BBDD no relacional son:
Amazon
Google
Microsoft
La alta disponibilidad es una cualidad de un sistema informático o dispositivo que garantiza un alto rendimiento operativo durante un periodo determinado.
La disponibilidad se mide en porcentajes: el 100% significaría que el sistema nunca falla; una garantía del 99% anual significa que el sistema podría tener un tiempo de inactividad del 1%, es decir, 3,65 días de inactividad al año.
Para intentar ofrecer una disponibilidad lo más cercana al 100% los arquitectos e ingenieros encargados de la infraestructura diseñan modelos geo-redundados que aseguren el servicio en caso de interrupción o caída del sistema principal.
Actualmente la demanda de infraestructuras en alta disponibilidad se ha disparado. Esto se debe a que las empresas, cada vez más, dependen de servicios en la nube para procesos críticos internos que deben estar siempre disponibles. La alta disponibilidad de estas infraestructuras disminuye el riesgo y esto es bueno para el negocio.
Ejemplo práctico de alta disponibilidad usando Amazon Web Services:
Esta es una muestra de un servidor LAMP (Linux, Apache, MySQL y PHP) en alta disponibilidad a través de Amazon Web Services (AWS).
En la ilustración se representan dos zonas de disponibilidad (A y B). Cada una de estas zonas dispone de una capa de servidor web (detallado en la ilustración como Web tier ) y un RDS.
En el caso de las capas web, se replica la aplicación PHP que contienen en las dos zonas. Además, como se puede observar, se encuentran en modo autoescabale, es decir, los recursos crecen a mayor cantidad de tráfico y peticiones del sistema.
Por otro lado, están los RDS. Uno asume el rol de RDS Master, base de datos primaria, y el otro el de RDS Slave o base de datos secundaria, encargada de mantener una réplica latente y en reposo de la base de datos principal. Frente a las dos zonas hay un balanceador de carga.
Las Availability Zones (AZ o zonas de disponibilidad) son zonas geográficas distintas y aisladas. En algunos casos resulta interesante ejecutar varias aplicaciones independientes en más de una zona de disponibilidad, de manera que si una de ellas falla, la aplicación puede continuar ejecutándose en las otras.
Route 53 es el sistema de nombres de dominio (DNS) escalable y altamente disponible. Forma parte de la plataforma de AWS y su nombre hace referencia al puerto TCP o UDP 53, donde se concentran las peticiones del servidor DNS.
ELB es un servicio de balanceo de carga elástico. Permite distribuir el tráfico entrante para que un único recurso no se sature con todo el tráfico. El balanceo de carga es un sistema bastante efectivo de incrementar la disponibilidad de un sistema, reemplazando las instancias que fallan mientras el balanceador redirige la carga a otras que continúan operativas.
Tipos de balanceador de carga a tener en cuenta:
S3 es un servicio de almacenamiento de grandes volúmenes de datos que permite recopilar, almacenar y analizar datos independientemente de su formato.
RDS es un servicio web que permite la configuración, operación y escalabilidad de una o varias bases de datos relacionales en la nube. Facilita una capacidad rentable y redimensionable para bases de datos relacionales y cuenta con imágenes de los gestores de bases de datos más usados.
Componentes necesarios para obtener alta disponibilidad.
Para conseguir un sistema en alta disponibilidad hay varios componentes a tener en cuenta. De esta manera, la alta disponibilidad depende fundamentalmente de factores como:
Ubicación/es. Disponer de servidores redundados en diferentes centros de datos y áreas geográficas aumenta la fiabilidad y disminuye el riesgo. Si todos los servidores estuvieran ubicados en el mismo sitio o área geográfica, un desastre natural como un terremoto o inundación podría hacer que todo el sistema caiga.
Hardware . Los servidores, discos duros e interfaces de red que estén en alta disponibilidad deben ser resistentes a posibles cortes energéticos o fallos en el hardware.
Software . Todo software, incluido el sistema operativo, debe estar preparado para gestionar posibles fallos inesperados que en un momento determinado pudieran requerir de, por ejemplo, un reinicio.
Datos . Un sistema en alta disponibilidad debe valorar todos los posibles factores que deriven en una pérdida de datos o inconsistencia de los mismos.
Red . Uno de los puntos de fallo habituales en cualquier sistema son las interrupciones imprevistas de la red. Es importante que exista una estrategia de red redundante ante posibles fallos.
Además de la redundancia y revisión de todos estos factores es necesario disponer de un buen arquitecto y equipo de IT que acompañen y trabajen en la identificación, diagnóstico y resolución de fallos potenciales con el fin de reducir el riesgo e incrementar el porcentaje de disponibilidad anual del servicio.
Actualmente están apareciendo una gran cantidad de herramientas en el mercado pensadas para ayudar a DevOps y administradores de sistemas a simplificar su trabajo y a automatizar procesos.
Algunas herramientas que destacar son:
Plataforma de software libre utilizada para administrar configuraciones, crear máquinas virtuales o integrar e implementar aplicaciones.
Ansible es un motor de automatización que usa un modelo sin agente, normalmente con claves SSH, que permiten autenticar y administrar las máquinas de destino. Se categoriza como una herramienta de orquestación donde las tareas de configuración se definen en cuadernos de estrategias, con una serie de módulos disponibles para llevar a cabo tareas específicas.
Plataforma de automatización pensada para conocer mediante código nuestra infraestructura y así poder recrearla, reconfigurarla o replicarla.
Chef no gestiona el aprovisionamiento de VM o sistemas operativos, lo que hace es configurar y desplegar aplicaciones y configuraciones orquestando la configuración de entornos compuestos por más de un nodo. Para hacer todo esto, Chef dispone de diferentes módulos específicos como:
Chef Habitat. Permite la automatización del ciclo de vida de la aplicación más que de la infraestructura.
Chef InSpec. Ayuda en la automatización del cumplimiento normativo con los requisitos de seguridad o de directiva.
Chef Desktop, Chef Automate, Chef Infra…
Plataforma de automatización pensada para empresas.
Permite controlar el proceso de entrega e implementación de las aplicaciones. El proceso incluye la instalación de agentes en las máquinas destino para permitir a Puppet Master ejecutar el código que define la configuración deseada en relación a las máquinas virtuales y la infraestructura.
Método de distribución múltiple estándar usado para personalizar una máquina virtual la primera vez que se arranca.
Cloud-init permite la creación de imágenes o plantillas que se reutilizan para instalar paquetes y escribir archivos, configurar usuarios o establecer parámetros de seguridad de forma automatizada. Cloud-init no necesita de pasos adicionales o agentes para aplicar la configuración durante el proceso de arranque inicial.
Herramienta de orquestación de código abierto que permite definir la infraestructura como código. Es decir, permite escribir en un fichero de texto las características/definición de la infraestructura con un lenguaje de programación bastante simple y claro.
Plan de Recuperación ante Desastres (DRP, Disaster Recovery Plan)
Las empresas deben estar listas ante cualquier incidente, y para ello deben protegerse de posibles percances o problemas de seguridad, ya que estos podrían acabar impactando sobre el negocio y el futuro de la compañía. Por este motivo, es necesario blindar los principales procesos de negocio a través de una serie de tareas que faciliten la recuperación, tras un incidente grave, en un plazo de tiempo corto.
Con un Plan de Recuperación ante Desastres (DRP) se garantiza el poder dar una respuesta rápida y planificada ante cualquier fallo de seguridad, repercutiendo positivamente sobre la imagen y reputación de la compañía. Además de mitigar el impacto financiero y de pérdida de información asociados a este tipo de incidentes.
El riesgo, la razón para establecer un DRP
Las empresas identifican diferentes riesgos potenciales que pueden impactar negativamente en las operaciones normales de una organización. La evaluación de riesgos debería ser realizada con el fin de ver qué eventos pueden dar lugar a un potencial desastre, incluyendo:
Catástrofe.
Pandemia.
Fuego.
Fallos en el suministro eléctrico.
Ataques terroristas.
Interrupciones organizadas o deliberadas.
Sistema y/o fallos del equipo.
Error humano.
Virus, amenazas y ataques informáticos.
Cuestiones legales.
Huelgas de empleados.
Conmoción social o disturbios.
La idea es tener en mente todos los riesgos potenciales para poder tomar medidas o formular un futuro plan de continuidad de negocio.
Parámetros de tiempo en un DRP
Existen dos conceptos que ayudan a medir los tiempos de respuesta en los procesos de Recuperación ante Desastres y que son muy utilizados en el mundo TI, aunque no son exclusivos del mismo:
Punto Objetivo de Recuperación (RPO). Es una medida que indica el máximo periodo de tiempo que una organización está dispuesta a sufrir una pérdida de datos. Para reducir el RPO es necesario aumentar el sincronismo de réplica de datos.
Tiempo Objetivo de Recuperación (RTO). Es el tiempo que pasará una infraestructura antes de estar disponible. Para reducir el RTO, se requiere que la infraestructura (tecnológica, logística, física…) esté disponible en el menor tiempo posible tras la interrupción.
Plan de Continuidad del Negocio (PCN)
Generalmente, un Plan de Recuperación ante Desastres (DRP) es parte de un plan mayor denominado Plan de Continuidad del Negocio (PCN).
La diferencia está en el alcance, mientras el PRD se enfoca en un ámbito más técnico, menos profundo y de forma más reactiva; el Plan de Continuidad del Negocio o PCN es una estrategia que establece la continuidad de una organización desde múltiples perspectivas : infraestructura IT, RRHH, mobiliario, logística, infraestructuras físicas…
Un buen Plan de Continuidad de Negocio nos ayuda a:
Para establecer un buen Plan de Continuidad de Negocio se deben considerar aquellos factores que permitan garantizar la continuidad de una empresa en circunstancias adversas.
El proceso para identificar factores e implementar un plan de este tipo consta de las siguientes fases:
Hay que establecer qué áreas y departamentos estarán implicados en el Plan de Continuidad. Lo recomendable es comenzar por aquellos departamentos o áreas con mayor importancia y progresivamente ir ampliando la continuidad a toda la organización.
Se recopila toda la información necesaria para determinar cuáles son los procesos de negocio críticos, los activos que les dan soporte y las necesidades temporales y de recursos.
Conocidos los activos que soportan los procesos críticos, se debe determinar si, en caso de desastre, será posible recuperar dichos activos en el tiempo necesario. En aquellos casos en los que no sea así, se deberán establecer estrategias de recuperación.
A partir de las estrategias de recuperación escogidas, se realiza la selección e implantación de las iniciativas necesarias, y se documenta el Plan de Crisis y los respectivos documentos para la recuperación de los entornos.
A partir de la infraestructura de la empresa, se desarrollarán los planes de prueba y mantenimiento.
Además del análisis y la implantación, es necesario que tanto el personal técnico como los responsables de nuestra empresa conozcan qué es y qué supone el Plan de Continuidad de Negocio, así como qué se espera de ellos.
Plan de Continuidad TIC (PCTIC)
Cuando el Plan de Continuidad de Negocio es restringido al ámbito más tecnológico , surge lo que se conoce como Plan de Continuidad TIC.
En base a lo que ya hemos visto antes, las tareas para realizar un Plan de Continuidad TIC pueden resumirse en los siguientes pasos :
Determinar el alcance de los servicios y procesos objeto de la mejora de su continuidad.
Realizar reuniones con los departamentos tecnológicos implicados y determinar sus necesidades y requerimientos.
Realizar reuniones con personal técnico y determinar con qué capacidades y recursos cuentan.
Identificar los servicios y procesos críticos junto con los activos tecnológicos que los sustentan y sus dependencias.
Obtener los riesgos a los que están expuestos los servicios y procesos.
Identificar qué medidas o iniciativas es necesario llevar a cabo para que las capacidades tecnológicas sean superiores a las demandas de negocio.
Elaborar el plan de crisis para identificar las primeras acciones a realizar cuando ocurre un desastre.
Elaborar los planes de recuperación para cada entorno implicado en el alcance.
Elaborar las instrucciones técnicas de trabajo para poder llevar a cabo el plan de recuperación ante desastres.
Elaborar el plan de mantenimiento e implantarlo.
Elaborar el plan de pruebas e implantarlo, realizando comprobaciones periódicas para verificar que son correctas.
Realizar la formación al personal implicado en el Plan de Continuidad de Negocio de la compañía.
Proteger la información personal y el acceso a las instalaciones es un punto cada vez más crítico.
La tecnología IAM ( Identity Access Management ) es un sistema integrado de políticas y procesos que tiene como objetivo facilitar y controlar el acceso a los sistemas de información.
Esta tecnología se puede utilizar para iniciar, capturar, registrar y gestionar identidades de usuarios y sus permisos de acceso de manera automatizada.
Dentro de una empresa, la gestión de identidades y accesos puede llevarse a cabo a través de un producto o a través de una combinación de procesos; y puede gestionarse a través de un software o por medio de servicios en la nube y hardware. El objetivo es que los administradores tengan visibilidad y control sobre los datos de la organización y determinen qué usuarios pueden tener acceso.
Algunos conceptos básicos del IAM:
Usuarios . Un usuario de IAM es el concepto que representa a la persona o a la aplicación que interactúa con la infraestructura. Generalmente un usuario consta de nombre y credenciales.
Grupos . Conjunto o agrupación de usuarios de IAM. Estos grupos permiten identificar permisos para varios usuarios al mismo tiempo, haciendo más fácil la administración.
Identidad . Concepto que representa a un usuario, a una agrupación o a una entidad que demanda acceso a un servicio.
Permiso . Concepto que determina el acceso a los recursos.
Rol . Es un conjunto de permisos. Los roles pueden ser generales, propietarios o específicos y determinan las operaciones que se pueden realizar (lectura, escritura o eliminación, por ejemplo).
RBAC . Control de acceso basado en rol es un sistema de autorización usado para gestionar el acceso a recursos. Para poder conceder acceso, se debe asignar roles a usuarios, grupos, entidades de servicio o identidades administradas.
¿Cómo funciona un sistema IAM?
Las dos funciones principales que caracterizan a los sistemas IAM son: verificar la identidad de los usuarios que quieren iniciar sesión y definir qué autorizaciones tienen.
Estas dos funciones pueden ser procesadas de diferentes maneras.
Verificar la identidad. El primer paso relacionado con la gestión de identidad y acceso es saber quién está iniciando sesión en el sistema. El proceso más sencillo y común para llevar a cabo esta verificación es mediante la combinación de dos inputs: usuario y contraseña. Un sistema más avanzado promovería la autenticación a través múltiples factores.
Comprobar el nivel de autorización. Una vez que el usuario ha sido identificado correctamente, el siguiente paso dentro del sistema IAM es gestionar su acceso. Este será un acceso personalizado basado en un conjunto de reglas de autorización almacenadas en el sistema.
Factores de autenticación
El proceso de evaluación de cualquier sistema informático analiza y valora a cada usuario en busca de características propias de él. Si coinciden, se confirma la identidad del usuario. Estás características son conocidas como factores de autenticación, ya que ayudan a verificar que el usuario es quien dice ser.
Los tres factores de verificación más utilizados son:
Algo que el usuario sabe. Este es un factor de verificación que solo el usuario debe conocer, como una combinación de nombre de usuario y contraseña.
Algo que tiene el usuario. Token físico o software de doble autenticación que se habilita a los usuarios autorizados. Se pueden plantear diferentes ejemplos, desde los más rudimentarios, como sería el de la llave que te permite abrir la puerta de casa, hasta otros más sofisticados como Google Authenticator.
Algo que caracteriza o pertenece al usuario. Una propiedad física del cuerpo. Un ejemplo común de este factor de autenticación sería el reconocimiento fácil o la huella dactilar de muchos dispositivos móviles.
SSO (Single Sign On) como parte de la Gestión de Identidades y Acceso (IAM)
Dentro de la Gestión de Identidades y Acceso (IAM), una de las soluciones de control de accesos más conocidas es el SSO o Single Sign On.
Este Inicio de Sesión Único es un proceso de autenticación que permite que un usuario determinado pueda acceder a varios sistemas con una sola instancia de identificación.
El SSO es una funcionalidad con gran utilidad cuando hay varios sistemas o aplicaciones a los que acceder y se quiere evitar el ingreso de las credenciales de forma repetitiva. Para los usuarios supone una gran comodidad ya que basta con identificarse una sola vez para mantener la sesión válida en todos los sistemas y aplicaciones que utilizan el SSO.
Los principales tipos de Single Sign On son:
Enterprise SSO (E-SSO). También conocido como legacy sso, funciona para una autenticación primaria, captando los requisitos de login presentados por las aplicaciones secundarias para completar los mismos con el usuario y contraseña. Estos sistemas permiten interactuar con sistemas que pueden deshabilitar la presentación de la pantalla de login.
Web SSO. También conocido como gestión de acceso web. Funciona únicamente con aplicaciones y recursos accedidos vía web. Los accesos son captados con la ayuda de un servidor proxy o de un componente instalado en el servidor/aplicación web. Para reconocer a aquellos usuarios que acceden y su estado de autenticación se usan cookies, parámetros por GET (menos seguro) o POST.
Kerberos. Proceso para externalizar la autenticación de los usuarios. Consiste en usuarios que se registran en el servidor Kerberos y reciben un identificador, que será presentado por las aplicaciones cliente para obtener acceso.
Identidad federada. Este sistema usa protocolos basados en estándares para habilitar que las aplicaciones puedan identificar los clientes sin necesidad de autenticación redundante.
OpenID. Proceso de SSO distribuido y descentralizado donde la identidad se compila en un Localizador Uniforme de Recursos (URL) que cualquier aplicación o servidor puede verificar.
¿Por qué IAM es tan importante en el Cloud?
En cualquier servicio en la nube, los datos se almacenan de forma remota y se consultan a través de Internet. Los usuarios, por su parte, pueden conectarse a internet desde cualquier sitio y dispositivo, lo que provoca que la mayoría de los servicios cloud no dependan de la ubicación y el tipo de dispositivo.
Debido a todo esto, la identidad se convierte en el punto más importante a la hora de controlar el acceso. Es la identidad del usuario, no su dispositivo o ubicación, lo que determina si tiene acceso y a qué datos puede acceder.
La Gestión de Identidades y Acceso (IAM) ayuda a evitar ataques en función de la identidad y las fugas de datos asociadas al escalamiento de privilegios.
De esta manera, se puede afirmar que los sistemas IAM son esenciales para los servicios cloud y la gestión de equipos remotos.
Algunos productos IAM
Azure Active Directory.
AWS Identity and Access Management.
IBM Security Identity and Access Assurance.
OneLogin.
Actualmente existen dos grandes aproximaciones en la arquitectura de software: los sistemas monolíticos y los microservicios distribuidos. El dilema entre una arquitectura u otra responde a las necesidades, cada vez más importantes, por parte de los usuarios profesionales de los sistemas digitales.
Arquitectura monolítica
Las aplicaciones monolíticas tienen como característica el uso de una base de código única para sus servicios o funcionalidades. Normalmente consta de un frontend y un conjunto de servicios o módulos. Todos estos módulos corren generalmente debajo de la misma máquina virtual.
Una arquitectura monolítica es autónoma, es decir, no depende de otros servicios fuera de esta y obedece solo a los componentes que están en su interior (frontend, backend y BBDD).
Arquitectura basada en microservicios
Los microservicios, sin embargo, son una arquitectura que busca desacoplar o independizar los componentes individuales de una aplicación, de manera que cada componente sea una aplicación en sí misma. Los microservicios se conectan entre si a través de APIs.
Este tipo de arquitectura apuesta por una programación distribuida, haciendo que los diferentes componentes del software puedan ser desarrollados y desplegados de forma independiente.
Una arquitectura de este tipo incrementa la eficiencia en la gestión de equipos y permite desplegar a producción de una forma más ágil. De esta manera, se pueden formar equipos multifuncionales con poco esfuerzo y deshacerlos igualmente, algo que se debe también a la autonomía de cada uno de los modelos de la solución.
Microservicios en la nube
Los servicios en la nube se caracterizan por ofrecer agilidad, flexibilidad, resiliencia y capacidad de adaptación . Migrar a la nube es un paso importante del proceso de modernización de cualquier software, pero estos beneficios no se dan de manera automática por el simple hecho de estar en la nube.
Cumplir con la promesa de un servicio más eficiente y adaptable requiere de un ajuste paralelo en la arquitectura de la aplicación. Las arquitecturas monolíticas muchas veces se acaban convirtiendo en un cuello de botella para sistemas complejos y a gran escala. Los microservicios, sin embargo, gracias a la naturaleza de su arquitectura, habilitan la posibilidad de escalar aplicaciones fácilmente evitando así posibles cuellos de botella y limitaciones.
Es fundamentalmente por esta razón por lo que se considera que los microservicios son un elemento esencial en toda estrategia cloud de ciertas dimensiones.
Existen numerosas amenazas de seguridad que afectan a los entornos en la nube. A continuación, listamos las 12 vulnerabilidades principales de los servicios cloud.
Violaciones de datos. El robo o pérdida de datos puede ser provocado por un ataque, un error humano o simplemente derivado de unas malas prácticas de seguridad. La configuración correcta de los accesos y una buena seguridad perimetral son fundamentales a la hora de bloquear este tipo de intrusiones.
Gestión de identidad y accesos deficientes. Una mala gestión de la identidad, contraseñas o credenciales pueden provocar que un intruso acceda a las infraestructuras y ahí lea, modifique, elimine o robe información sin control alguno.
APIs inseguras. En muchos casos, son las interfaces de programación (o APIs) el elemento clave de seguridad asociada a los servicios en la nube. Estás APIs deben diseñarse pensando en las políticas de seguridad y posibles ataques.
Vulnerabilidades de los sistemas. Son bugs en aplicaciones que pueden ser utilizados por intrusos para infiltrarse en el sistema y robar datos o interrumpir el servicio. Muchas veces, el hecho de que servicios y/o aplicaciones de distintos clientes compartan elementos como el procesador o la memoria física habilita potenciales brechas de seguridad que han de valorarse.
Robo de cuentas. El robo de cuentas no es algo nuevo, pero los servicios en la nube incrementan el riesgo. Si un intruso/atacante consigue los datos de acceso de un usuario, este podría acceder a áreas críticas del servicio en la nube y causar daños, manipular datos o devolver información falsa.
Ataques desde el interior. Un administrador, ex empleado o usuario malintencionado (que esté dentro de la organización) puede acceder a información confidencial y tener altos niveles de acceso a sistemas críticos. Algunos estudios estiman que el 90% de las organizaciones es consciente de esta vulnerabilidad. En muchos casos, para reducir el riesgo y evitar este tipo de ataques, las organizaciones adoptan sistemas de monitorización de usuarios, sistemas IDS, sistemas IAM y sistemas DLP ( Data Loss Prevention ).
Amenazas persistentes avanzadas (APT). Es un tipo de ataque que consiste en infiltrarse y comprometer un sistema con información valiosa, robando datos. Las APT persiguen sus objetivos de forma sigilosa durante largos periodos de tiempo y se van adaptando a las medidas de seguridad que se adoptan contra ellos.
Pérdida de datos. La pérdida de datos en servicios cloud pueden deberse a un ataque, un borrado accidental, una catástrofe, problemas con el proveedor de servicios… Por ello es importante que tanto el proveedor de servicios cloud como el usuario tomen medidas y cuenten siempre con un sistema de copias de seguridad.
Análisis de riesgos insuficiente . Evaluar la tecnología en la nube a utilizar es importante, valorar los riesgos y contar con una hoja de ruta adecuada es fundamental para que los servicios cloud contratados no supongan exponerse a ataques o robo de información.
Abuso y mal uso de los servicios cloud. Existen servicios en la nube con medidas de seguridad deficientes que pueden ser usados para crear bots, atacar usuarios y empresas o incluso a otros servicios en la nube. Entre este tipo de ataques pueden estar los ataques DDoS y las campañas de phishing.
Ataques de denegación de servicio (DoS). Estos ataques se han diseñado para detener servicios y evitar así que los usuarios puedan acceder a sus datos o aplicaciones. Existen diferentes estrategias para ejecutar este tipo de ataques: consumo de cantidades excesivas de recursos que bloqueen el servicio, ralentización de los sistemas de usuarios legítimos o incluso el bloqueo directo de accesos.
Tecnología compartida. Generalmente los proveedores de infraestructura en la nube ofrecen sus servicios de forma escalable compartiendo una infraestructura física. Esta tecnología compartida puede dar lugar a vulnerabilidades relacionadas con un bajo aislamiento entre clientes que comparten la misma infraestructura.
Warning: this action cannot be undone.
Please wait a few moments.
