Simulacro de release: Bases de datos

[erikasv]

Descripción y resultado

Teniendo en cuenta los inconvenientes que tuvimos con las bases de datos para el lanzamiento, vamos a iniciar sacando el backup y restaurando dichos backups en un local para asegurarnos de que se puede hacer así tome mucho tiempo.

1. Sacar backup de todas las tabas y bases de datos de pruebas la base de datos de portafolios en pruebas
2. Sacar backup de todas las tablas relacionadas con compensaciones de la base de datos del servicio principal de producción (strategies, companies, etc)
3. Los backups de las demás bases de datos se pueden encontrar aquí. Pero si lo considera más fácil, puede realizar los pasos originales (los tachados)
4. Crear instancia de postgres en máquina local (misma versión e imagen que la que se está usando en producción)
5. Restaurar backups de bases de datos de pruebas en el local.
6. Restaurar las tablas de compensaciones en ambiente local
7. Conectar ambiente de desarrollo con estas bases de datos y probar que todo esté bien.

[erikasv]

Hey team! Please add your planning poker estimate with Zenhub @cazapatamar @hacheG @ManuelStardust

[erikasv]

@hacheG @ManuelStardust @cazapatamar cambié la descripción, revisar y si es el caso reevaluar su votación

[cazapatamar]

Se hace el proceso en el ambiente local y es exitoso. Se dejan los pasos en este documento

[cazapatamar]

Como un alcance adicional a esta tarea se va a revisar el archivo de politicas de seguridad de postgres pg_hba.conf para establecer que optimizaciones en seguridad se pueden aplicar la bd de biotablero de producción.

[cazapatamar]

Resumen de lo que es el archivo pg_hba.conf:

Es un archivo de texto que se utiliza para definir las políticas de autenticación y acceso a la base de datos. En cada linea se encuentra una regla distinta. Tiene esta estructura:

Private Zenhub Image

• TYPE: El tipo de conexión al que se aplica la regla (puede ser local para conexiones Unix domain socket o host para conexiones a través de la red). Las mas usadas son:
  • local: Esta opción se utiliza para conexiones locales a través de sockets de dominio Unix en el mismo servidor donde se ejecuta PostgreSQL.
  • host: Se utiliza para conexiones desde hosts remotos a través de la red. Puedes especificar direcciones IP y rangos de direcciones IP para controlar el acceso.
  • hostssl: Similar a host, pero para conexiones a través de SSL/TLS. Esta opción se usa cuando deseas habilitar la autenticación SSL/TLS para conexiones seguras desde hosts remotos.
  • hostnossl: Similar a host, pero para conexiones que no utilizan SSL/TLS. Puede ser útil si deseas permitir conexiones no seguras desde hosts específicos.
• DATABASE: El nombre de la base de datos a la que se aplica la regla. El valor "all" especifica que coincide con todas las bases de datos. El valor "sameuser" especifica que el registro coincide si la base de datos solicitada tiene el mismo nombre que el usuario solicitado. El valor "samerole" especifica que el usuario solicitado debe ser miembro del rol con el mismo nombre que la base de datos solicitada
• USER: El nombre de usuario al que se aplica la regla
• ADDRESS: La dirección IP o el rango de direcciones IP a los que se aplica la regla.
  • 127.0.0.1/32: Conexiones desde la dirección IP local (localhost).
  • 192.168.1.0/24: Conexiones desde cualquier dirección IP en la subred 192.168.1.0/24.
  • 0.0.0.0/0: Acepta conexiones desde cualquier dirección IP (peligroso si no se limita de forma adecuada).
• METHOD: El método de autenticación que se utiliza para verificar las conexiones entrantes. Las mas usadas son:
  • trust: No se requiere autenticación; cualquiera puede conectarse sin contraseña.
  • md5: Autenticación basada en contraseña; se requiere una contraseña encriptada MD5.
  • peer: Autenticación basada en sistema operativo; utiliza la identidad del sistema operativo del usuario.
  • cert: Autenticación basada en certificado SSL/TLS.
  • reject: Rechaza la conexión sin intentos de autenticación.

Las siguientes líneas son algunos ejemplos de las reglas de autenticación y acceso:

• local all all trust: Esta línea permite todas las conexiones locales (a través de sockets Unix) sin requerir autenticación. En otras palabras, cualquier usuario puede conectarse localmente sin proporcionar una contraseña.

• host all all 127.0.0.1/32 trust: Esta línea permite conexiones IPv4 locales desde la dirección IP 127.0.0.1 (localhost) sin requerir autenticación. Al igual que la anterior, cualquier usuario puede conectarse localmente sin una contraseña.

• host all all ::1/128 trust: Similar a la anterior, pero para conexiones IPv6 desde la dirección ::1 (localhost).

• host all all all md5: Esta línea permite conexiones desde cualquier dirección IP (IPv4 o IPv6) y requiere autenticación mediante contraseña (autenticación MD5).

[cazapatamar]

Recomendaciones para nuestra base de datos:

• Evaluar si es necesario tenere reglas de acceso desde el local ya que la bd está en un servidor independiente
• Establecer reglas especificas para hacer la conexion desde la ip el backend para cada base de datos o una unica regla usando el parametro sameuser o samerole para la columna DATABASE.
• Establecer regla para el acceso desde los equipos locales de los desarrolladores. Revisar si la VPN tiene un rango de ips o mascara de subred especifica.
• En ambientes de producción evitar el uso de metodo trust y en general cualquier regla abierta al publico en general y que se pueda acceder desde cualquier origen.

[cazapatamar]

Se revisó brevemente configuracion sugerida en la documentacion de dataverse y lo que hacen es definir una regla de acceso md5 en local. Este caso no nos sirve por que esa aplicacion tiene todos los camponentes en el mismo servidor.