Seguridad Multi-Cloud: Integrando AWS y GCP

La adopcion de estrategias Multi-Cloud ya no es una excepcion, es la norma. Sin embargo, gestionar la seguridad a traves de AWS y Google Cloud Platform (GCP) presenta desafios unicos debido a las diferencias fundamentales en sus modelos de identidad, red y auditoria.

En este articulo, exploraremos como construir una postura de seguridad unificada que aproveche lo mejor de ambos mundos sin sacrificar visibilidad ni control.

Puntos Clave

1. Identidad: Use federación (OIDC) para evitar claves de larga duración.
2. Red: Entienda las diferencias entre Security Groups (ENI-level) y Firewall Rules (Instance-level/Global).
3. Auditoría: Centralice CloudTrail y Cloud Audit Logs en un solo "pane of glass".
4. Infraestructura: Defina políticas de seguridad agnósticas a la nube usando Terraform.

1. Identidad Centralizada: La "Receta" de Federación

El mayor riesgo en entornos multi-cloud es la gestión de secretos de larga duración (Access Keys). La solución moderna en 2025 es OIDC Federation, permitiendo que servicios en AWS accedan a GCP (y viceversa) sin tocar una sola clave estática.

Implementación Práctica con Terraform

A continuación, mostramos cómo permitir que una carga de trabajo en AWS asuma una identidad en GCP mediante Workload Identity Federation.

Paso A: Configurar el Pool en GCP

Primero, creamos el "apretón de manos" en el lado de Google Cloud para confiar en el proveedor de identidades de AWS.

1resource "google_iam_workload_identity_pool" "aws_pool" {
2workload_identity_pool_id = "aws-integration-pool"
3display_name              = "AWS Integration Pool"
4description               = "Confianza federada para cuentas AWS"
5}
6
7resource "google_iam_workload_identity_pool_provider" "aws_provider" {
8workload_identity_pool_id          = google_iam_workload_identity_pool.aws_pool.workload_identity_pool_id
9workload_identity_pool_provider_id = "aws-provider"
10
11# Confiamos en la cuenta AWS especifica
12aws {
13  account_id = "123456789012"
14}
15}

Paso B: Mapeo de Identidades

El secreto está en no confiar en toda la cuenta, sino en roles específicos. Usamos "Attribute Mapping" para restringir el acceso.

1attribute_mapping = {
2"google.subject" = "assertion.arn"
3}
4
5# Solo permitimos que el rol específico "prod-app-role" asuma identidad
6attribute_condition = "assertion.arn == 'arn:aws:iam::123456789012:role/prod-app-role'"

Esta configuración asegura que solo tu aplicación de producción en AWS pueda acceder a recursos en GCP, eliminando la necesidad de rotar claves JSON de Service Accounts. Es más seguro, más limpio y cumple con estándares CIS/ISO27001 por defecto.

2. Visibilidad Unificada y Auditoria

¿Como detectas un ataque que salta de un bucket de S3 a una instancia de Compute Engine? Necesitas centralizar tus logs.

Estrategia de Agregacion

No intentes mirar dos consolas diferentes. Centraliza la ingesta de logs en un SIEM o una plataforma de observabilidad de seguridad.

3. Diferencias en el Modelo de Seguridad de Red

Entender las diferencias sutiles entre AWS y GCP es vital para evitar errores de configuracion.

Security Groups vs. Firewall Rules

Aunque ambos cumplen funciones similares, operan de manera diferente:

• AWS Security Groups: Son stateful y se aplican a nivel de interfaz de red (ENI). Las reglas de entrada permiten implicitamente la respuesta de salida.
• GCP Firewall Rules: Son globales a la VPC pero se aplican a las instancias. Son stateful, pero la gestion de tags es mas flexible y jerarquica.

1# AWS (Security Group)
2Type: Ingress
3Protocol: TCP
4Port: 22
5Source: 0.0.0.0/0
6Action: DENY (No existe explicitamente en SGs, se maneja por omision en allow-lists o NACLs)
7
8# GCP (Firewall Rule)
9direction: INGRESS
10action: DENY
11rules:
12- IPProtocol: tcp
13  ports: ["22"]
14sourceRanges: ["0.0.0.0/0"]
15targetTags: ["public-server"]

Nota clave: En AWS, los Security Groups son "Deny All" por defecto y solo permiten lo que listas (Allow Lists). Los NACLs son stateless y permiten reglas DENY explicitas. En GCP, las reglas de Firewall permiten reglas DENY y acciones de logging mas granulares directamente.

4. Automatizacion y "Shift Left" en Multi-Cloud

Gestionar dos nubes manualmente es imposible. La unica via es Infrastructure as Code (IaC).

Herramientas como Terraform o Pulumi te permiten definir politicas de seguridad que se aplican a ambos proveedores usando un lenguaje comun.

Ejemplo: Bucket Privado Estandarizado

Puedes crear un modulo de Terraform que genere un Bucket S3 (AWS) o un Storage Bucket (GCP) con las mismas politicas de seguridad base:

1. Encriptacion activada por defecto.
2. Acceso publico bloqueado.
3. Versionado activado para recuperacion de ransomware.

Conclusión

La integracion de seguridad entre AWS y GCP no se trata de duplicar esfuerzos, sino de abstraer los principios (Identidad, Red, Datos) y aplicarlos consistentemente utilizando las herramientas nativas de cada nube orquestadas por una capa de gestion centralizada.

En 2025, la seguridad efectiva es aquella que es invisible para el desarrollador pero implacable con el atacante.