Creando Buckets de almacenamiento

/ CLOUD, DatawareHouse / Por

HOLIS!!!! tudu bom? hoy trabajaremos un poco con la importacion de archivos en Cloud, vamos a trabajar con Google Cloud Platform, por que? no hay porque… es lo que aprendi jaajaja…

Vamos de a poco, en cloud trabajamos con Buckets, basicamente es un contenedor, donde se almacenan archivos que luego pueden ser utilizados para alimentar a un datawarehouse. Se puede imaginar como una carpeta principal en internet, aunque técnicamente es mas que eso: es un espacio de almacenamiento con configuración de permisos, ubicación geográfica, politicas de acceso y versionado.

Supongamos que tenemos un dominio dentro de la organizacion que se llama Logistica, podemos crear un bucket llamado Logistica, al ser en internet, debemos considerar que puede que ya exista ese nombre, por ende lo haremos con un nombre único.

Como dijimos con anterioridad, debemos tomar en cuenta donde vamos a almacenar el bucket:

Que elegir y como hacerlo?

1. Región

Los datos se almacenan en una única región geográfica.

Ejemplos:

  • southamerica-east1 (São Paulo, Brasil)
  • us-central1 (Iowa, EE. UU.)
  • europe-west1 (Bélgica)

Ventajas

  • Menor costo.
  • Baja latencia para aplicaciones que también están en esa región.
  • Ideal cuando todo el sistema está concentrado en un solo lugar.

Desventajas

  • Si esa región tiene una interrupción importante, el bucket puede quedar temporalmente inaccesible.

Cuándo usarlo

  • Aplicaciones empresariales.
  • ETL.
  • BigQuery.
  • Backups locales.
  • Sistemas internos.

2. Dual Region

Los datos se almacenan automáticamente en dos regiones específicas.

Ejemplo:

São Paulo
      │
      └──────────────► Iowa

Si una región falla, la otra continúa disponible.

Ventajas

  • Alta disponibilidad.
  • Mejor recuperación ante desastres.
  • Menor riesgo de pérdida de servicio.

Desventajas

  • Mayor costo.

Cuándo usarlo

  • Bases de datos críticas.
  • Sistemas bancarios.
  • Facturación electrónica.
  • Información que no puede quedar inaccesible.

3. Multi-Region

Los datos se distribuyen dentro de una gran área geográfica administrada por Google.

Ejemplos:

  • US
  • EU
  • ASIA

Google decide en qué centros de datos almacenar las copias.

Ventajas

  • Muy alta disponibilidad.
  • Excelente para contenido consumido desde muchos lugares.

Desventajas

  • Generalmente es la opción más costosa.
  • No puedes elegir el país exacto donde se almacenan los datos dentro de esa zona.

Cuándo usarlo

  • Sitios web internacionales.
  • Distribución de imágenes y videos.
  • Aplicaciones con usuarios en muchos países.

Ya elegimos donde almacenar, ahora vamos a elegir COMO hacerlo:

En este punto no hay mucho que explicar mas alla de lo que ya nos explica GCP.

Ya tenemos, donde y el como…. que falta? EXACTO!! quien!!! quien puede tocar nuestras cosas. podemos hacerlo de dominio publico o bien conceder permisos:

Controlar el acceso a los objetos de un bucket es uno de los aspectos más importantes de la seguridad en GCP. La idea es aplicar el principio de menor privilegio: cada usuario o servicio debe tener únicamente los permisos necesarios para realizar su trabajo.

Estos son los principales aspectos a considerar:

1. ¿Quién necesita acceder?

Lo primero es identificar los tipos de usuarios:

  • Personas (administradores, desarrolladores, analistas).
  • Aplicaciones.
  • Procesos ETL.
  • Servicios automáticos.
  • Clientes externos.

Por ejemplo:

UsuarioPermisos
Data EngineerLeer y escribir
AnalistaSolo lectura
AplicaciónEscribir archivos
PúblicoNingún acceso (salvo que sea contenido público)
2. Evitar acceso público

Un error frecuente es permitir que cualquier persona en Internet pueda acceder al bucket.

Si el bucket contiene:

  • Información de clientes
  • Facturas
  • Datos bancarios
  • Backups
  • Archivos internos

no debería ser público.

Solo conviene permitir acceso público cuando el contenido está pensado para distribuirse libremente, como imágenes de un sitio web o archivos descargables.

3. Utilizar IAM en lugar de permisos individuales

En la actualidad, Google recomienda administrar permisos mediante IAM (Identity and Access Management) en lugar de configurar permisos objeto por objeto.

Esto permite:

  • administrar permisos de forma centralizada;
  • asignar roles a usuarios, grupos o cuentas de servicio;
  • auditar quién tiene acceso.

Ejemplos de roles:

  • Storage Object Viewer → solo lectura.
  • Storage Object Creator → solo puede subir archivos.
  • Storage Object Admin → administra objetos.
  • Storage Admin → administra buckets y objetos.
4. Usar cuentas de servicio

Las aplicaciones no deberían autenticarse con usuarios personales.

En su lugar se utilizan Service Accounts.

Ejemplo:

ETL
 │
 ▼
Service Account
 │
 ▼
Bucket

Así:

  • no depende de una contraseña humana;
  • las credenciales pueden rotarse;
  • es posible saber qué aplicación realizó cada acción.
5. Separar ambientes

Es recomendable utilizar buckets diferentes para:

Desarrollo
Producción
Testing
Backups

En lugar de:

mi-bucket/
    dev/
    test/
    prod/

La separación facilita la administración de permisos y reduce el riesgo de errores.

6. Proteger información sensible

Si el bucket almacena:

  • datos personales;
  • información financiera;
  • historias clínicas;
  • documentos legales;

es recomendable:

  • utilizar cifrado (Google cifra los datos en reposo por defecto, y puedes usar claves administradas por el cliente si lo necesitas);
  • limitar estrictamente los permisos;
  • habilitar registros de auditoría para conocer quién accedió a los datos.
7. Versionado

Activar el versionado permite recuperar archivos cuando alguien:

  • los elimina accidentalmente;
  • los sobrescribe;
  • carga una versión incorrecta.

Ejemplo:

factura.pdf
     │
     ├── versión 1
     ├── versión 2
     └── versión 3
8. Auditoría

Conviene revisar periódicamente:

  • quién accedió;
  • qué archivo descargó;
  • quién eliminó objetos;
  • desde qué cuenta se realizaron las operaciones.

Esto ayuda tanto en seguridad como en el diagnóstico de incidentes.

9. Compartir mediante URLs firmadas

Si necesitas compartir un archivo temporalmente con alguien que no tiene acceso al bucket, es preferible usar una URL firmada (Signed URL).

Por ejemplo:

  • un cliente puede descargar un PDF durante 30 minutos;
  • después de ese tiempo, el enlace deja de funcionar automáticamente.

Es más seguro que hacer público todo el bucket.

10. Aplicar el principio de menor privilegio

Es una buena práctica otorgar únicamente los permisos necesarios.

Por ejemplo:

Incorrecto:

  • Todos los desarrolladores tienen permisos de administrador.

Correcto:

  • ETL → escribir.
  • Analistas → leer.
  • Administradores → administrar.
  • Usuarios finales → sin acceso directo.

Por último vamos a proteger los datos…

Esto va a depender de la politica del negocio que estemos trabajando, pero basicamente es así…

Se eliminan de manera automatica segun un tiempo determinado, lo establecemos nosotros o bien por defecto a los 7 días

Depende el negocio, podemos pedir que se mantengan… si tenemos siempre el mismo documento y necesitamos que se mantenga una version actualizada tenemos el control de versiones…

UN TIPO ACÁ…. SI SOMOS POBRES OBTEMOS POR LA ELIMINACION YA QUE DE SEGURO METEMOS LOS DATOS EN UN TABLA Y NO MUCHAS VECES NO ES NECESARIO MANTENER TANTO ESPACIO DE ALMACENAMIENTO QUE NOS SUBE EL PRESUPUESTO….

Al finalizar le dimos al botón Crear y UALÁ!!! tenemos el bucket creado!!