ACA con Azure DataBase + Azure Storage

1. Crear una Base de Datos.

1.1 Crear el servidor PostgreSQL.

Vamos al recurso de azure llamado "Azure Database for PostgreSQL flexible server"

Le damos a crear nueva.

Configuramos los "Dátos básicos":

Muy importante seleccionar la opción de "Tipo de carga de trabajo" --> "Desarrollo/Pruebas", ya qie es lo que estamos haciendo. Esto hará que sea mucho más barato.

Justo un poco más abajo de esto tenemos esta opción "Proceso y almacenamiento"

Continuamos con el resto de datos básicos

Configuramos las "Redes"

Habilitamos el acceso público para poder acceder pero solo le damos permisos a nustra IP para estar seguros de que nadie más puede acceder al recurso.

Configuramos la "Seguridad"

¿Qué hace cada opción?

• Clave administrada por el servicio (Elegida): Azure gestiona automáticamente las claves de cifrado y protege los datos sin necesidad de configuración adicional. Es la opción más sencilla y recomendada para prácticas y entornos estándar.
• Clave administrada por el cliente: El usuario controla sus propias claves de cifrado mediante servicios como Azure key Vault. Ofrece mayor control y seguridad avanzada, pero requiere una configuración más compleja.

En nuestro caso elegimos la opción administrada por el servcio porque nos dimplifica la administración y proporciona cifrado en reposo de forma automática.

Le damos a crear

1.2 Crear la base de datos.

Iremos al server de base de datos postgress que hemos creado y creamos una base de datos que será appdb-practica.

1.3 Opciones de seguridad.

Firewall

Azure PostgreSQL incorpora reglas de firewall para controlar qué firecciones IP pueden contectarse al servidor. Se puede permitir únicamente el acceso desde IPs concretas desde servicios de Azure o configurar acceso privado mediante redes virtuales.

Opciones:

Nosotros anteriormente lo que hicimos al crear el servidor de BD fue permitir solo el acceso a mi IP con esta configuración:

Autenticación

El servicio permite varios métodos de autenticación:

• PostgreSQL authentication: acceso mediante usuario y contraseña.
• Microsoft Entra ID: autenticación integrada co ncuentas de Azure para mayor seguridad.

En nuestro caso le pusimos solo contraseña con PostgreSQL porque queremos que sea sencillo para la práctica.

Usuarios y permisos

Es posible crear distintos usuarios dentro de la base de datos y asignar permisos específicos según las necesidades de cada aplicación o servicio.

De hecho esto debería de ser algo obligatorio.

Los usuario solo deberían de tener los mínimos privilegios posibles para realizar la tarea a la que se dediquen.

Cifrado y seguridad

Azure cifra automáticamente los datos en reposo y utiliza SSL/TLS para proteger als conexiones entre aplicaciones y la base de datos.

Mecanismos para permitir conexiones externas

Las aplicaciones externas pueden conectarse utilizando:

• Endpoint público del servidor
• Puerto 5432 de PostgreSQL
• Usuario y contraseña
• Reglas de firewall que permitan la IP del cliente
• Variables de entorno o secretos almacenados en Azure Container Apps

En entornos más seguros también pueden utilizarse:

• Redes virtuales privadas (VNet)
• Private Endpoints
• Managed Identity y Microsoft Entra ID

2. Analizar cómo una ACA accede a la BD

Información necesaria

Una ACA necesita:

Para recogerla lo que haremos es:

1. DB_HOST: Endpoint del servidor.

   Es la dirección del server, que la encontraremos en la información general del server de BD que hemos creado.

   

2. DB_PORT: Puerto.

   PostgreSQL utiliza por defecto el puerto 5432

3. DB_NAME: Nombre de la BD.

   Será el nombre que le pusimos al crearla, en nuestro caso appdb-practica

4. DB_USER: Usuario.

   El creado en la instalación del server. Irá con este formato: <usuario>@<nombre-db>

5. DB_PASSWORD: Contraseña.

   La contraseña asociada al usuario.

2.1 Configuración en ACA

Iremos a Containers dentro de ACA, elegimos la app y configuramos las variablse en

Escribimos todas las variables que van con "Entrada manual"

Para introducir el secreto primero debemos crearlo. Lo haremos dentro de la aplicación contenedora, podemos hacerlo en "Key Vault" de Azure pero para hacerlo más sencillo lo haremos directamente.

Ahora debemos añadirlo a las variables de la siguiente manera, igual que añadimos las "entradas manuales", le damos a "Hacer referencia a un secreto". Aquí nos debería de aparecer directamente para seleccionarlo.

Y así es como nos deben de quedar las variables de entorno:

Aunque la aplicación desplegada actualmente es una web estática y no utiliza conexión real con la base de datos, se configuraron las variables de entorno y secretos necesarios para simular cómo una ACA accedería a un servicio PostgreSQL gestionado en Azure.

Esta configuración permitiría a una aplicación backend conectarse de forma segura utilizando credenciales protegidas y parámetros de conexión almacenados en el entorno del contenedor.

3. Crear una cuanta de Azure Storage.

En nuestro caso crearemos un "Blob Storage"

3.1 Crear la Storage Account.

Lo primero que debemos hacer es crear una "Storage Account" porque es el recurso principal de almacenamiento en Azure. Dentro de esta cuenta se podrán crear servicios como Blob Storage, File Storage, Tables o Queues.

Le damos a crear y comenzamos a configurar los "Datos básicos"

Continuamos con la configuración "Avanzado"

• NO habilitamos el "espacio de nombres jerárquico" porque lo que hace eso es activar "Data Lake Gen2" (una estructura tipo carpetas avanzada).

  Eso se usa en:

  • Big data
  • Azure Data Lake
  • Análisis de datos

• NO habilitamos "SFTP" ni "sistema de archivos de red", porque no podemos al no haber habilitado lo anterior, igualmente tampoco deberíamos de habilitarlo.

• NO permitimos "replicación entre inquilinos" porque esto lo que hace es que nos permite compartir datos entre distintos tenants de Azure, y es solo para empresas grandes o escenarios complejos.

• NO habilitamos la "identidad administradad e SMB" porque Blob Storage no usa SMB, eso sería en "Azure File Storage"

Continuamos con la configuración de "Redes"

Para evitar problemas y al ser una práctica lo q haremos es habilitar desde todas las redes, pero sería muy buena práctica de seguridad especificar que IPs pueden acceder únicamente.

Para el 'enrutamiento de red' elegiremos la opción de "enrutamiento de internet", ya que es la más adecuada para entornos de desarrollo y prácticas. Esta opción permite que el tráfico acceda al servicio directamente mediante la red pública, sin necesidad de configuraciones avanzadasd de red privada o integración con la red global de Microsoft.

Continuamos con la configuración de "Protección de datos"

• NO habilitamos la "restauración a un momento dado para contenedores", lo que hace esto es volver TODO el contenedor a un estado anterior. Para nuestra práctica no es necesario porque además sumaría costes.
• NO habilitamos "el control de versiones para blob" lo que hace es que guarda copias de cada versión del archivo, no cuesta extra directamente pero, sí aumenta el almacenamiento usado, por lo que para la práctica no es necesario.
• NO activamos "la fuente de cambios del blob" porque registrará todo y no nos es necesario para esta práctica.

• NO habilitamos "la compatibilidad con la inmutabilidad de nivel de versión" porque lo que hace es que no se puedan borrar ni modificar los datos, se suele utilizar en bancos, tema legal y auditorías oficiales, por lo que para nuestra práctica no lo necesitamos.

• NO "Habilitar la eliminación temporal para blobs", protege imágenes, archivos, pdfs... En mi caso también lo quitaremos porque solo haremos pruebas

• NO "Habilitar la eliminación temporal para contenedores", protege el contenedor completo (la "carpeta"), en nuestro caso también lo quitaré
• NO "Habilitar la eliminación temporal de recursos compartidos de archivos clásicos", protege archivos tipo red (File Storage), también lo quitamos

Continuamos con la configuración de "Seguridad"

• "Requerir transferencia segura para las operaciones de API de REST": obliga a usar HTTPS
• "Permitir el acceso anónimo en contenedores individuales": permite acceso público sin autenticación a blobs.
• "Habilitar el acceso a la clave de la cuenta de almacenamiento": permite usar connection strings, access keys y SDKs tradicionales. Lo necesitamos para compatibilidad.
• "El valor predeterminado es la autorización de Microsoft Entra en Azure Portal": deberíamos de activarla porque serían buenas prácticas de seguridad ya que, azure lo que hace es usar la identidad de Microsoft Entra (Azure AD), lo que es más moderno y seguro. Si no la activamos, tendremos que usar access keys, connection strings o métodos clásicos de autenticación que son más antiguos.
• "Habilitar Defender para Storage": Su función es detectar accesos sospechosos, malware, ataques, actividades anómalas o posibles filtraciones de datos. Genera costes por lo que no lo activaremos en esta práctica.

Continuamos configurando el "Cifrado"

• El "tipo de cifrado":

  • Claves administradas por Microsoft (MMK): azure genera las clasves, cifra los datos automáticamente, administra la seguridad.
  • Claves administradas por el cliente (CMK): Elegiremos esta opción cuando queramos usar "Azure Key Vault" con claves propias de la empresa.

• "Habilitar cifrado de infraestructura": lo que hace es añadir una capa extra de cifrado a nivel de infraestructura física. Es más complejo y puede aumentar costes, por lo que no nos hace falta.

Cuando lo tengamos le damos a crear.

3.2 Entrar en el Storage Account y subir archivos.

Vamos al Blob Storage que acabamos de crear y seleccionamos "Data Storage" --> "containers" --> "Agregar contenedor"

Subimos una foto cualquiera para hacer la prueba.

Y entramos desde la URL para probarlo y ver que podemos ver lo que acabamos de subir.

Mas abajo aparecerán:

Pegamos la URL en el navegador y comprobamos

4. ¿Cómo usa Azure Storage una app ACA?

Tiene 3 formas principales de hacerlo:

1. Connection String / Access Keys 2. SAS Token (acceso temporal) 3. Microsoft Entra ID (Managed Identity)

Es el método más simple

La app usa:

DefaultEndpointsProtocol=https;
AccountName=xxx;
AccountKey=xxx;

Se guarda en:

• Variables de entorno
• Secretos en Container Apps

Ventajas:

• Fácil de usar
• Rápido de configurar

Desventajas:

• Menos seguro
• Si se filtra la clave, hay acceso total

Permite acceso limitado y temporal

Ventajas:

• Expira en el tiempo definido
• Permisos limitados (solo lectura, etc)
• Más seguro que keys

Desventajas:

• Hay que regenerarlo

Recomendado. La app usa su identidad dentro de Azure.

Ventajas:

• No hay contraseñas
• Más seguro
• Recomendado en producción

Desventajas:

• Más complejo de configurar

Connection String / Access Keys ¿Qué necesita la app de ACA para conectar?

A) Base de datos (PostgreSQL)

DB_HOST=tu.servidor.postgres.database.azure.com
DB_PORT=5432
DB_NAME=appdb
DB_USER=usuario
DB_PASSWORD=contraseña

B) Azure Storage (Blob)

STORAGE_ACCOUNT_NAME=tuaccount
STORAGE_CONTAINER=objetos-practica
STORAGE_CONNECTION_STRING=DefaultEndpointsProtocol=https;Account....

Cundo lo tengamos, lo añadiremos todo a las "variables de entorno" del contenedor de esta forma:

Y crearemos la revisión.

5. Esquema de Arquitectura de la infraestructura.