Mostrando entradas con la etiqueta Amazon. Mostrar todas las entradas
Mostrando entradas con la etiqueta Amazon. Mostrar todas las entradas

jueves, junio 18, 2026

Hacking AI: Jailbreak, Prompt Injection, Hallucinations & Misalignment. How to Hack Digital Services Based on LLMs & AI Agents (English Edition)

Hoy, ya con los deberes del cumpleaños cumplido, os dejo una noticia que para mí es muy bonita. Es el inicio de un proyecto nuevo que lleva meses gestándose y que el día 1 de Julio de este año da su comienzo. Pero mientras llega ese día, os dejo uno de sus primeros pasos, que es esta versión en inglés del libro de Hacking IA que publicamos en Español, pero ahora en su versión en Inglés.
Si estás leyendo este blog, probablemente te interese más la versión en Español, pero si tienes algún compañero que no habla nuestra lengua, ya le puedes compartir el enlace del libro en Amazon. Y si te gusta leer en inglés en digital, pues también lo tienes.
En breve ya os iré contando más novedades de este nuevo proyecto en el que voy a comenzar a trabajar con viejos y buenos amigos y compañeros, pero por el momento aquí tenéis un adelanto, que para nosotros es muy especial. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


lunes, enero 19, 2026

Tu SmartTV de Sony, Samsung, LG, Hisense & TCL te vigila y les han demandado en USA

Hace unas semanas os contaba mi frustración con algunos procesos que hemos construido sobre la usabilidad de la tecnología en el artículo que titulé: "La "shittización" en contra de hacer las cosas simples", y cómo los requisitos para, por ejemplo, usar un servicio tan simple y tan común como la televisión,  habían subido exponencialmente en el nivel cognitivo que requieren a las personas.
El motivo por el que todo esto sucede, tiene mucho que ver con el "Growth" o el "Crecimiento del negocio", y de eso centré mi artículo de "El futuro está por hackear - Solo para gente Smart" donde explicaba que cada usuario que ve una SmartTV es una oportunidad para venderle algo - mediante anuncios - o de capturar más datos para poder vender a esa persona a los anunciantes, que es de lo que va este caso, justamente.


Y de eso mismo van las demandas que han puesto en Texas a los fabricantes de SmartTV Sony, Samsung, LG, y las compañías chinas Hisense y TL, por hacer capturas periódicas de lo que estás viendo en la pantalla, analizarlo, hacer un fingerprinting y enviarlo a sus servidores.
Como se puede ver en la demanda puesta a Samsung, el software ACR que están instalando en las SmartTVs los fabricantes demandados, se está capturando lo que hay en pantalla, y se está enviando un fingerprint para hacer una perfilado completo de ese usuario, independientemente de si son vídeos en Youtube, o cámaras de seguridad de la casa - con zonas privadas -. 

Hay que tener presente que cuando un usuario de una SmartTV está viendo contenido en una app, como Netflix, Amazon Prime, o Disney+, el sistema operativo sigue teniendo control de la pantalla, así que puede hacer capturas y acceder a datos que de otra manera le estarían lejos de su alcance. 
Así que aprovechar esa capacidad, les permite espiar qué está viendo cada usuario en la televisión, y sacar el máximo de insights posibles utilizando técnicas avanzadas de Machine Learning, que ya sabemos cómo se hace eso en detalle.

Figura 6: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen TorranoFran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Pero no solo eso, ya que también se están capturando los datos incluso si la televisión está desconectada de Internet, para enviarlos cuando esta se reconecta, y permite generar a qué horas se levanta, acuesta, ve la televisión o llega del trabajo. Algo que tienen instrumentalizado para su negocio de anuncios.


Pero claro, en la pantalla de la SmartTV también se pueden ver otras cosas, como la navegación de Internet - incluso por tu banco -, las fotos o vídeos personales, o los juegos a los que estás jugando en tu consola, algo que le da muchos datos de competencia a los fabricantes de SmartTVs
Todo ello genera un perfil personal que puede ser utilizado para campañas políticas, como puede verse en este artículo en el que Samsung DSP explica los beneficios de utilizar los datos extraídos, para poder poner anuncios dirigidos con intereses políticos. Lo que es un claro riesgo de ingerencia extranjera si, como dicen en las demandas, el Partido Comunista Chino tiene acceso a estos datos de las SmartTVs chinas HisSense y TCL.
Las demandas hacen especial hincapié en cómo la información que se da a los usuarios para conseguir el consentimiento no está correctamente explicada, ni al alcance de cualquiera, ni al mismo nivel la posibilidad de aceptar  y denegar el permiso, ya que las opciones están muy ocultas cuando se trata de revocar el permiso de acceso a los datos.
Estos permisos se buscan conseguir en el momento de la instalación, justo cuando los usuarios quieren tener cuanto antes funcionando su televisión, que es lo que os he contado en los artículos que he estado escribiendo estos días. Un momento en el que el usuario tiene urgencia, algo muy beneficioso y conocido por todos, para lograr un YES, ya sea a una venta o a un consentimiento fácil como "I Agree to all"

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


jueves, mayo 29, 2025

FrodoKEM: Un Key-Encapsulation Mechanism Quantum-Safe (PQC) que recibe su nombre por "El señor de los Anillos"

No hace mucho os hablaba de HQC "Hamming Quasi-Cyclic" el segundo KEM (Key-Encapsulation Mechanism) elegido por el NIST para completar al primero que se anuncio y que fue bautizado como  Module-Latice-Based KEM, o MLB-KEM o ML-KEM. Estos dos primeros KEM han sido elegidos como parte de la estandarización de los algoritmos de Criptografía Post-Cuántica (PQC: Post-Quantum Cryptography). 

Sin embargo, hubo otros que se quedaron en el camino, y que con la aceleración de los últimos anuncios de Google Willow Quantum ChipMicrosoft Majorana-1 y Amazon Ocelot Quantum Chip,  merece la pena conocerlos porque alguno se está convirtiendo en estándar ISO. Uno de ellos es FrodoKEM, en el que han colaborado el mundo de la universidad, investigadores de Google y de Microsoft, que incluso tienes publicado en su GitHub para que lo puedas probar.
Si queréis conocer más información de  Module-Latice-Based KEM, o MLB-KEM o ML-KEM, la podéis encontrar en la publicación completa del standard de ML-KEM la tenéis documentada en el siguiente paper del NIST, y yo escribí un artículo de HQC "Hamming Quasi-Cyclic", que también podéis leer.
Estos dos algoritmos se basan en una estructura de anillo algebraica central para esos algoritmos, y la apuesta de Frodo "es librarse del anillo". Sí, has entendido correctamente, este algoritmo recibe su nombre en homenaje al mítico personaje "Frodo" de "El señor de los anillos", que si no te has leído el libro, estás tardando ya - yo le dediqué un verano y lo disfruté como un "enano".

Tu lectura de este verano, sí o sí.

En este caso, FrodoKEM utiliza, para la generación de las claves de cifrado PQC (Post-Quantum Cryptography) que se usarán en una solución PKI se basan en la dificultad de resolver el problema de Learning With Errors. En este caso, el problema radica en dada una matriz A cuadrada de n x n generada uniformemente aleatoria, y dos matrices lineales siendo una muestra s de la clave, pero teniendo además la matriz e "errores", se realiza el cálculo de A x s + e y se obtiene una matriz b.
Para un atacante la dificultad del algoritmo es resolver la inversa, es decir, dado A y el resultado b, encontrar s, que sería la derivada sampleada de la clave, que no sería fácil de resolver para un algoritmo cuántico por la explosión de probabilidades en los que se ha podido inyectar el error, lo que le obliga a descubrir la matriz de errores, además de la clave. Como se puede ver en la imagen siguiente, la clave pública está compuesta de sA y b, por lo que se hace complejo resolver el problema.
Esta es la base fundamental de FrodoKEM, que como bien explican en la web de "FrodoKEM" y en el artículo "FrodoKEM: A conservative quantum-safe cryptographic algorithm" fue descartado del proceso de estandarización de NIST en la Ronda 3, pero va a ser estandarizado por la ISO/IEC 18033-2 para que sea un estándar que pueda ser utilizado por cualquiera que lo desee en la industria. 
El problema que tiene FrodoKEM, como bien explican, es que evitar las posibles vulnerabilidades criptográficas que puede tener en el futuro el "anillo algebraico" en el que se centran ML-KEM y HQC-KEM es un coste en tamaño y en ciclos de computación.

Por supuesto, si te interesa el mundo de la criptografía, y no estás al día, te recomiendo que te pongas las pilas con el libro de  Cifrado de las comunicaciones digitales: de la cifra clásica a RSA 2ª Edición de 0xWord que te va a aclarar muchos de los conceptos que que son importantes en los algoritmos PQC (Post Quantum Cryptography).

Así que, si no tenías lectura para estos días, ya sabes qué te puedes comenzar a leer, que esto es fundamental para entender el mundo de la seguridad informática en cualquiera de las áreas profesionales en la que te quieras especializar.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


martes, abril 15, 2025

Cómo servir modelos de ML e IA (LLMs) en Kubernetes con KServe: Autoscaling Inteligente y Eficiencia en GPU

La Inteligencia Artificial no se detiene, y su adopción en producción tampoco, pero hay una brecha silenciosa entre entrenar un modelo y servirlo de forma eficiente, escalable y mantenible. Aquí es donde Kubernetes se convierte en el aliado perfecto, y donde herramientas como KServe (el sucesor de KFServing) brillan.

Figura 1: Cómo servir modelos de ML e IA (LLMs) en Kubernetes con KServe.
Autoscaling Inteligente y Eficiencia en GPU

En este artículo te cuento cómo puedes montar una plataforma moderna para servir modelos de IA y LLMs sobre Kubernetes, aprovechar las novedades más recientes de KServe, y hacer que tu infraestructura escale según uso real y consumo de GPU

Spoiler: sí, se puede tener eficiencia, velocidad y buena arquitectura al mismo tiempo.

¿Por qué servir modelos sobre Kubernetes?

Entrenar un modelo es sólo la mitad del camino. Lo difícil viene después: ponerlo a funcionar en producción de forma fiable, segura y escalable.
  • Alta disponibilidad
  • Autoescalado según carga real
  • Seguridad, versionado, observabilidad
  • Integración con pipelines CI/CD y orquestadores como Argo Workflows o Kubeflow
Kubernetes permite todo esto. Pero no hay que reinventar la rueda, y ahí entra KServe.

Antes de continuar… ¿Qué es Kubeflow y qué ofrece?

Kubeflow es una plataforma Open Source pensada para desplegar, escalar y gestionar flujos de trabajo de Machine Learning (ML) sobre Kubernetes. Su objetivo principal es llevar el desarrollo de modelos de ML a producción de forma reproducible, escalable y portátil.


Kubeflow no es una herramienta única, sino un conjunto de componentes modulares que cubren distintas etapas del ciclo de vida del modelo de Machine Learning:
  • Kubeflow Pipelines: Orquestación de pipelines de ML (entrenamiento, preprocesado, validación, etcétera).
  • Katib: AutoML y búsqueda de hiperparámetros.
  • KServe (antes KFServing): Serving de modelos con escalado automático y despliegues sin downtime.
  • Notebook Servers: Entornos Jupyter en Kubernetes, listos para trabajar con datos y modelos.
  • Central Dashboard y Profiles: Gestión multiusuario, RBAC, y control de recursos por equipo o proyecto.
Kubeflow se posiciona como una plataforma completa para MLops sobre Kubernetes, especialmente útil cuando necesitas estandarizar y automatizar todo el flujo de trabajo desde el desarrollo hasta el despliegue.

Figura 4: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen TorranoFran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Aunque KServe puede funcionar por separado de Kubeflow, se integra perfectamente como pieza de serving dentro del stack Kubeflow.

KServe: servir modelos como si fueran microservicios

KServe es un componente de Kubeflow, pero puede usarse de forma independiente. Te permite desplegar modelos como recursos de Kubernetes (CRDs), exponiéndose vía REST o gRPC, con soporte para, entre otros, PyTorch, TensorFlow, XGBoost, SKLearn, ONNX etc... e incluso tus propios contenedores.
  • Lo bueno: cada modelo es un InferenceService, y tú defines lo que necesita: CPU, GPU, versiones, etcétera.
  • Lo brutal: KServe soporta escalado automático hasta cero réplicas, y las vuelve a levantar cuando hay tráfico. Nada de infra desperdiciada.
GPU autoscaling
  • Puedes escalar vertical y horizontalmente tus modelos en GPU.
  • Mediante Prometheus Adapter + HPA Custom Metrics, se puede escalar según uso de memoria GPU, uso de batch o incluso peticiones por segundo.
Raw Deployment mode
  • 1.- KServe por defecto usa Knative para autoescalar.
    • Escala basándose en tráfico HTTP (requests por segundo).
    • Esto no es suficiente cuando usas GPUs, ya que estas no se liberan con tráfico bajo.
    • Además, los workloads con GPU suelen tener procesamiento batch o tiempos largos de inferencia, donde Knative no escala de forma óptima.
  • 2.- Para modelos en GPU, muchas veces no se usa Knative, sino raw deployment mode en KServe, para tener más control.
    • Aquí ya no dependes de Knative, sino de un Deployment + HPA.
  • 3.- Prometheus Adapter + HPA con métricas personalizadas
    • Prometheus Adapter permite exponer métricas personalizadas (por ejemplo: uso de memoria GPU, utilización del device, número de peticiones, etc.) como Custom Metrics API.
    • Con eso puedes configurar un HPA (Horizontal Pod Autoscaler) para escalar los pods de inferencia según esas métricas.
    • Esto se usa en entornos donde se necesita un autoscaling más inteligente y específico, especialmente con GPU.
Scale down a cero

¿Qué significa “scale down a cero” en KServe?
  • Es la capacidad de escalar a cero réplicas un modelo cuando no está recibiendo peticiones, y volver a levantarlo automáticamente (auto-scale up) cuando llega una nueva petición.
¿Qué beneficios tiene esta solución?
  • Ahorro de costes brutal: Si tienes muchos modelos desplegados pero no todos se usan constantemente, con scale-to-zero no malgastas CPU ni RAM. Ideal en entornos cloud donde pagas por uso de recursos, como en clusters gestionados (EKS, GKE, AKS…).
  • Optimización de recursos en el cluster: En vez de mantener todos los pods activos, los que no reciben tráfico se eliminan temporalmente, dejando espacio a otros workloads que sí lo necesitan. Ayuda a evitar sobrecargas y reduce la necesidad de sobredimensionar el cluster.
  • Despliegue eficiente de muchos modelos: Puedes permitir que muchos equipos o usuarios publiquen sus propios modelos sin saturar el sistema. Esto habilita patrones como “multi-tenancy” eficiente para inferencias bajo demanda.
  • Escalado bajo demanda: Si un modelo recibe tráfico repentino, KServe lo activa rápidamente. Esto es perfecto para modelos que solo se usan de vez en cuando o que funcionan como microservicios ML reactivos.
Canary rollout

KServe soporta dividir tráfico entre versiones de modelo (v1, v2, etcétera). Por ejemplo puedes hacer un 90/10, observar métricas y logs, y luego promover o descartar la nueva versión. Pero… ¿qué es Canary rollout

Figura 6: Canary Rollout

El Canary rollout te permite probar una nueva versión de un modelo (por ejemplo v2) con una pequeña parte del tráfico real, mientras que la versión estable (v1) sigue sirviendo la mayoría del tráfico. Esto es clave para:
  • Validar rendimiento y exactitud del modelo en producción.
  • Detectar errores o regresiones antes de hacer el cambio completo.
  • Observar métricas y logs reales sin impactar a todos los usuarios.
Ejemplo de Canary rollout en KServe
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
 name: sklearn-iris
 namespace: kserve-test
spec:
 predictor:
   model:
     modelFormat:
       name: sklearn
     storageUri: "gs://kfserving-examples/models/sklearn/1.0/model-1"
   canaryTrafficPercent: 10
   canary:
     model:
       modelFormat:
         name: sklearn
       storageUri: "gs://kfserving-examples/models/sklearn/1.0/model-2"
  • storageUri: del bloque principal. Apunta a model-1, la versión actual y estable del modelo.
  • canary: Define model-2 como la nueva versión que se quiere probar.
  • canaryTrafficPercent: 10: indica que el 10% del tráfico entrante será dirigido a model-2, mientras que el 90% restante seguirá siendo servido por model-1.
Novedades destacadas

Desde la versión v0.15.0, KServe ha incorporado mejoras significativas para el despliegue de modelos de lenguaje (LLMs), incluyendo soporte distribuido con vLLM, mejoras en el runtime de Hugging Face y optimizaciones para almacenamiento y readiness. Esto abre la puerta a escenarios como:
  • Servir un modelo LLaMA o Falcon en múltiples nodos GPU.
  • Integrar modelos de Hugging Face con pipelines existentes y autoscaling por demanda.
  • Aprovechar técnicas avanzadas como RAG o agentes con herramientas directamente desde Kubernetes.
Si antes KServe era ideal para modelos tradicionales de Machine Learning, ahora también lo es para los modelos de última generación. 

Algunas otras funcionalidades adicionales:
  • Soporte para descarga de archivos individuales desde GCS Google Cloud Storage), lo que mejora los tiempos de inicio.
  • Readiness probes más precisas, especialmente para modelos en transformers, mejorando la confiabilidad de despliegues en producción.
  • Introducción de “KServe Guru” en Gurubase.io, un espacio para encontrar y compartir soluciones de la comunidad.
Arquitectura tipo: Cómo lo montamos

Una plataforma de inferencia moderna sobre Kubernetes podría verse así:
  • KServe + Istio: para gestión de modelos como microservicios.
  • Knative Serving: para escalado a 0, cold start optimizado.
  • Prometheus + Grafana: para métricas personalizadas de GPU o latencia.
  • Cert-Manager + Ingress Gateway: TLS automático para exposición segura.
  • ArgoCD o Flux: GitOps para definir modelos como código.
  • GPU Operator de NVIDIA: para gestionar drivers y nodos GPU
¿Y si no quieres montar todo esto desde cero?

Aunque herramientas como KServe y Kubeflow son muy potentes, su configuración desde cero puede requerir tiempo, conocimientos avanzados de Kubernetes y una buena integración con infraestructura cloud o on-prem. Aquí es donde entran plataformas como Axebow.io, que están diseñadas para facilitar el despliegue de aplicaciones, entornos de Machine Learning e IA y plataformas completas sobre Kubernetes. Esto permite que equipos de IA y Data Science se enfoquen en desarrollar y servir modelos sin preocuparse por los detalles de infraestructura.


Axebow.io proporciona configuraciones optimizadas para rendimiento, autoscaling con GPU y despliegues reproducibles, lo que reduce la complejidad operativa y acelera el time-to-production. Si estás interesado en saber más, contacta con nosotros.

Autores: Miguel Angel Chuecos Carlos García Blanco, CEO de Kumori

jueves, enero 02, 2025

Infra as Code vs. Platform Engineering: Una Mirada Técnica a la Tendencia Actual

En los últimos años, la gestión y automatización de infraestructuras tecnológicas ha experimentado un cambio significativo. Dos enfoques han surgido como protagonistas: el uso de herramientas de Infra as Code (IaC), y el movimiento hacia la ingeniería de plataformas (Platform Engineering) respaldado por soluciones como Axebow, de la que ya os habló nuestro compañero José Bernabéu-Auban en su artículo: "Platform Engineering as a Service: La encrucijada de la Nube y la ilusión del progreso."

Figura 1: Infra as Code vs. Platform Engineering.
Una Mirada Técnica a la Tendencia Actual

Este artículo explora ambas tendencias, haciendo especial énfasis en la complejidad y el nivel de conocimiento necesario para implementar IaC en entornos multicloud.

Infra as Code: Automatización Granular y Flexible

Infra as Code (IaC) ha sido una revolución para los equipos de DevOps y operaciones. Herramientas como Terraform, Ansible y Pulumi permiten definir y gestionar la infraestructura utilizando código, lo que garantiza consistencia, auditabilidad y capacidad de replicación. 
Sin embargo, trabajar con ib en entornos multicloud, como AWS, Google Cloud y Azure, agrega capas de complejidad que exigen un nivel avanzado de conocimiento técnico y organización.

Ventajas del Enfoque IaC

1. Granularidad y Control: Las herramientas IaC ofrecen control detallado sobre los recursos. Por ejemplo, con Terraform, se puede definir cada componente de una infraestructura cloud, desde redes hasta bases de datos.

2. Compatibilidad multicloud: Aunque IaC puede implementarse en entornos multicloud, utilizar distribuciones de Kubernetes nativas de los proveedores cloud tipo (EKS, GKE, AKS) puede limitar la portabilidad y la interoperabilidad entre plataformas, lo que puede generar dependencias que dificultan una verdadera estrategia multicloud. 
 
3. Madurez Tecnológica: Muchas herramientas IaC están bien documentadas y cuentan con una comunidad activa, lo que facilita su adopción.

Desafíos del Enfoque IaC

Complejidad en Entornos Multicloud: Gestionar IaC en una nube ya es complejo; al incorporar múltiples proveedores como AWS, Google Cloud y Azure, se deben manejar diferencias en APIs, servicios y configuraciones. Esto incrementa los riesgos de errores y la necesidad de conocimientos especializados para unificar estrategias.

• Curva de Aprendizaje Pronunciada: Configurar y mantener IaC en un entorno multicloud requiere habilidades avanzadas, lo que implica un costo significativo en términos de formación y tiempo. Los equipos deben dominar lenguajes de configuración, comprender arquitecturas de cada proveedor y desarrollar experiencia en integración. 
 
Esta curva de aprendizaje puede traducirse en retrasos en la implementación y mayores gastos operativos, ya que el tiempo necesario para alcanzar la plena competencia puede ser considerable. Además, los errores derivados de una capacitación insuficiente pueden aumentar los costos asociados al re-trabajo y a la resolución de problemas.

• Escalabilidad Limitada sin Buenas Prácticas: Sin una estrategia bien definida, las configuraciones de IaC pueden volverse inmanejables a medida que crecen las implementaciones.

• Fragmentación Operativa: La falta de estandarización entre nubes puede resultar en implementaciones inconsistentes y más difíciles de mantener.

Platform Engineering: Abstracción y Estandarización

La Ingeniería de Plataformas o Platform Engineering  se posiciona como un enfoque holístico para gestionar infraestructuras y herramientas de desarrollo. Soluciones conocidas como plataformas de ingeniería, entre las que se encuentra Axebow, buscan crear una capa unificada que abstraiga la complejidad técnica y proporcione a los equipos de desarrollo y operaciones una experiencia optimizada.


Beneficios del Enfoque de Platform Engineering


1. Abstracción de Complejidad: Estas plataformas permiten a los equipos trabajar en un entorno preconfigurado que automatiza las configuraciones comunes, reduciendo la necesidad de conocimientos especializados.


2. Control y Optimización de Costes: La ingeniería de plataformas facilita la supervisión y gestión eficiente de los recursos, permitiendo identificar y eliminar ineficiencias en el uso de la infraestructura. Esto es particularmente relevante en entornos multicloud, donde los costos pueden escalar rápidamente si no se controlan adecuadamente. Poder optimizar el coste es un factor fundamental.
3. Productividad Mejorada: Con una plataforma estandarizada, los desarrolladores pueden enfocarse en construir aplicaciones en lugar de preocuparse por los detalles de la infraestructura.
4. Escalabilidad Organizacional: La ingeniería de plataformas promueve la coherencia y facilita la escalabilidad al ofrecer una base uniforme para todas las aplicaciones.

5. Seguridad y Gobernanza: La centralización de la gestión reduce los riesgos de configuraciones inseguras o incoherentes.


Desafíos del Platform Engineering

• Costos Iniciales: Implementar este tipo de plataformas requiere una inversión significativa en tiempo y recursos.

• Menor Flexibilidad Inicial: Aunque la abstracción reduce la complejidad, también puede limitar la capacidad de personalización para casos excepcionales.

• Resistencia al Cambio: Los equipos acostumbrados a trabajar con IaC y scripting pueden ser reticentes a adoptar un enfoque centralizado.

Ambos enfoques tienen su lugar en las estrategias modernas de infraestructura. En muchas organizaciones, la convergencia entre ambas filosofías está generando híbridos donde IaC establece las bases de la infraestructura, mientras que la ingeniería de plataformas ofrece una experiencia optimizada para los desarrolladores.

Consideraciones Finales

La elección entre Infra as Code & Scripting vs. Platform Engineering no es excluyente. Las organizaciones deben evaluar sus necesidades específicas, madurez técnica y objetivos a largo plazo. Mientras que IaC es ideal para entornos donde se requiere un control fino y personalización, la ingeniería de plataformas sobresale en contextos donde la escalabilidad y la eficiencia del equipo son prioritarias.

Figura 8: Comparación y Convergencia

En última instancia, herramientas como Axebow representan una evolución hacia un enfoque más colaborativo y orientado a la experiencia del usuario, marcando el camino hacia el futuro de la automatización de infraestructuras. Si quieres probar un servicio líder como el de Axebow solo entra en nuestra web.

Un saludo,


miércoles, febrero 07, 2024

Amazon Web Services (AWS): Hardening de Infraestructuras Cloud Computing en @0xWord

Comienza el año, y comienza al mismo tiempo la publicación de los nuevos títulos de este año, donde antes de RootedCON esperamos lanzar cuatro (4) nuevos títulos para que podáis hacer más grande vuestra biblioteca. Para que tengáis la colección completa. Y el primero de este año es "Amazon Web Services (AWS): Hardening de Infraestructuras Cloud Computing", escrito por Abraham Romero.
Ya lo tenéis ya disponible en la web de 0xWord, desde donde lo podéis comprar para tener lo antes posible 24-48 horas dependiendo de lo lejos que sea, en vuestras manos, y sobre una temática fundamental hoy en día, la fortificación de las infraestructuras en el Cloud de AWS.


El libro tiene 220 páginas, y cuenta en seis capítulos desde los principios iniciales de la suscripción que afectan a la seguridad, hasta los ataques que pueden significar grandes costes solo por un problema de seguridad, pasando por los temas más técnicos de fortificación de redes, fortificación de servicios, y fortificación de plataformas. El índice del libro completo os lo he subido a mi cuenta de SlideShare.

Como podéis ver, toca temas claves como el cifrado de datos, la seguridad de las cuentas privilegiadas de administración el despliegue y configuración de los servicios de firewalling de red y de aplicaciones, los controles de acceso, y la monitorización y gestión del alarmado de toda la plataforma cloud, algo fundamental hoy en día.


Figura 3: Índice del libro "Amazon Web Services (AWS):
 Hardening de Infraestructuras Cloud Computing"

El libro lo que lo ha escrito Abraham Romero Cid, es una especialización en seguridad para AWS, que es una de las plataformas de computación en la nube más utilizadas en todo el mundo a día de hoy. Ha revolucionado el mercado con la gran cantidad de servicios disponibles que ofrece, haciendo posible que las empresas y usuarios de todo el mundo puedan construir sus propias infraestructuras, productos y aplicaciones de forma rápida, sencilla y abaratando costes.

Este libro se ha escrito desde la perspectiva de una certificación de AWS para introducirse en el entorno cloud: AWS Certified Cloud Practitioner. Es por esto que el libro es el punto de partida ideal para aquellas personas que quieran adentrarse en esta tecnología, o pretendan afrontar dicho examen.
De esta forma, se cubrirán los conceptos más básicos y ventajas de la nube frente al modelo tradicional, su sistema de precios, se revisarán los principales servicios de AWS en términos de computación, redes, almacenamiento y bases de datos, y finalmente la seguridad en la nube, donde se analizarán los diferentes mecanismos de protección frente ataques, control de acceso, monitorización, conformidad etcétera.

Usar tus Tempos de MyPublicInbox 0xWord para adquirir este libro

Para terminar, te recuerdo que tendrás también 100 Tempos de MyPublicInbox por la compra de este libro de "Amazon Web Services (AWS): Hardening de Infraestructuras Cloud Computing" y que además, puedes pagar completa o parcialmente este libro con Tempos de MyPublicInbox. Aquí te explico cómo se hace.

La idea es muy sencilla, hemos creado un Buzón Público de 0xWord en MyPublicInbox y tenemos disponible el módulo de transferencias de Tempos entre cuentas siempre que el destinatario sea un Perfil Público de la plataforma. Para que se puedan hacer estas transferencias, primero debe estar el Perfil Público destinatario de la transferencia en la Agenda.

Figura 5: Perfil de 0xWord en MyPublicInbox. Opción de "Añadir a  la Agenda".
https://MyPublicInbox.com/0xWord

Para dar de alta un Perfil Público en tu agenda, solo debes iniciar sesión en MyPublicInbox, y con la sesión iniciada ir a la web del perfil. En este caso, a la URL del perfil público de 0xWord en MyPublicInbox, - https://MyPublicInbox.com/0xWord - donde te aparecerá la opción de "Añadir a la agenda". Cuando acabe este proceso, podrás ir a la opción Agenda de tu buzón de correo en MyPublicInbox y deberías tener el Perfil Público de 0xWord allí.

Figura 6: Cuando lo agregues estará en tu agenda

Una vez que lo tengas en la agenda, ya será tan fácil como irte a tu perfil - se accede haciendo clic en la imagen redonda con tu foto en la parte superior - y entrar en la Zona de Transferencias. Desde allí seleccionas el Buzón Público de 0xWord, el número de Tempos que quieres transferir, y en el concepto debes poner que es para recibir un código descuento para usar en la tienda de 0xWord.


No te preocupes por el texto concreto, porque los procesamos manualmente como los pedidos de se hacen en la tienda. 

Canjear 500 Tempos por un código descuento de 5 €

La última opción es bastante sencilla. Solo debes irte a la sección de Canjear Tempos -> Vales para Tiendas, y "Comprar" por 500 Tempos y código de 5 €. Es lo mismo que enviar la transferencia pero en un paquete de 500 Tempos y de forma totalmente automatizada, así que solo con que le des a comprar recibirás el código descuento y lo podrás utilizar en la tienda de 0xWord.com

Así que, si quieres conseguir nuestros libros de Seguridad Informática & Hacking aprovechando los Tempos de MyPublicInbox podrás hacerlo de forma muy sencilla y mucho, mucho, mucho más barato. Y así apoyas este proyecto tan bonito que es 0xWord.com.

Ser escritor de libros de 0xWord

Además, todos lo que queráis convertiros en escritores y hacer un proyecto de libro con nosotros. Podéis también enviarnos vuestra propuesta a través del buzón de 0xWord en MyPublicInbox, y si sois Perfiles Públicos de la plataforma, podéis entrar en la sección de Mi Perfil -> Servicios para ti y solicitar más información sobre el proceso de escribir un libro en 0xWord.
Nuestro equipo se pondrá en contacto contigo y evaluará tu proyecto de publicación de libro. Ya sabes que principalmente de Seguridad Informática & Hacking, y puede ser técnico, súper-técnico, o divulgación, y si es una novela... podemos estudiarlo también.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Entrada destacada

Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment. Nuestro nuevo libro en 0xWord

Pocas veces me ha hecho tanta ilusión que saliera un nuevo libro en 0xWord como con este libro de " Hacking IA: Jailbreak, Prompt Inje...

Entradas populares