-[Marco de trabajo](sections/team-framework.md) 🤝 - ¡Conoce cómo organizamos nuestro trabajo en equipo! 🗓️ Este documento te explicará cómo colaboramos y nos coordinamos para lograr nuestros objetivos.
-[Marco de trabajo](sections/team-framework.md) 🤝 - ¡Conoce cómo organizamos nuestro trabajo en equipo! 🗓️ Este documento te explicará cómo colaboramos y nos coordinamos para lograr nuestros objetivos.
-[Tareas (tickets)](sections/tickets.md) 🎫 - ¡Aprende cómo gestionamos nuestras tareas! 📝 Este documento te mostrará cómo utilizamos los tickets para organizar y priorizar nuestro trabajo.
-[Tareas (tickets)](sections/tickets.md) 🎫 - ¡Aprende cómo gestionamos nuestras tareas! 📝 Este documento te mostrará cómo utilizamos los tickets para organizar y priorizar nuestro trabajo.
-[Versionamiento de código fuente](sections/code-versioning.md) 💾 - ¡Domina el control de versiones! 💪 Este documento te enseñará cómo versionamos nuestro código fuente para mantener un historial de cambios y colaborar de manera segura.
-[Versionamiento de código fuente](sections/code-versioning.md) 💾 - ¡Domina el control de versiones! 💪 Este documento te enseñará cómo versionamos nuestro código fuente para mantener un historial de cambios y colaborar de manera segura.
## Secciones pendientes
-[Registro de eventos (logs)](sections/logs.md)
-[Seguridad](sections/security.md)
-[Bases de datos relacionales](sections/relational-dbs.md)
Para sistemas web, se recomienda implementar un sistema de registro de eventos (logs) con textos en Inglés. Es recomendable que se almacenen en una base de datos no relacional (por ejemplo, MongoDB).
Los datos que debería tener un log son:
| Variable | Consola | Base de datos | Notas |
| ----- | :---: | :---: | :---: |
| Identificador | ❌ | ✔️ | |
| Hora y fecha | ✔️ | ✔️ | |
| Registro manual | ❌ | ✔️ | Variable booleana que indica si el log ha sido registrado manualmente o por un *logger*. |
| Tipo de evento | ✔️ | ✔️ | Valores: \[*Verbose*, *Debug*, *Information*, *Warning*, *Error*, *Fatal*\] |
| Descripción | ✔️ | ✔️ | Breve descripción del evento |
| Sistema o Microservicio | ❌ | ✔️ | Ejemplo: *BioTablero-Search*, *BioTablero-Utils*, *BioTablero-Forest* |
* Todas las bases de datos deberán permitir almacenar datos en Español correctamente.
* Todos los nombres de los elementos de las bases de datos (tablas, columnas, vistas, triggers, etcétera) deberán estar en Inglés.
* Por temas de versionamiento y actualización de las bases de datos, se recomienda no crear vistas, triggers, funciones ni procedimientos almacenados.
* Se recomienda el uso de diferentes esquemas (*schemas*) para dividir la base de datos por módulos.
## Desarrollo y versionamiento
Será obligatorio el uso de herramientas *ORM* (*Object Relational Mapping*) para manejar las bases de datos relacionales en proyectos de software.
En caso de no usar otros sistemas de versionamiento, se podrán agregar los cambios de las bases de datos siguiendo las siguientes normas:
* Los scripts SQL se almacenarán en la ruta “*./scripts/sql/*”.
* Los scripts se guardarán en una carpeta con un formato de nombres que indique la fecha de creación (formato *año-mes-día* seguido de un guión) seguido de una descripción breve en Inglés. Algunos ejemplos son:
**2022-12-31 \- Logs module*
**2023-02-24 \- User module changes*
* En la carpeta se guardarán los scripts SQL con un formato de nombres que indique el orden (Un entero y un punto) seguido de una breve descripción del script en Inglés. Algunos ejemplos son:
**1\. Update tables.sql*
**2\. Add tables.sql*
**3\. Sedding data.sql*
* Todos los scripts deberán indicar al inicio, a qué base de datos afectarán (Con el comando *USE*).
* Todos los scripts deberán estar documentados, describiendo los cambios que realizarán.
* En los comandos de los scripts deberán especificarse los esquemas (*schemas*) involucrados, sin importar que se esté manejando el esquema por defecto.
* Se recomienda dividir los scripts por tipo (por ejemplo, scripts para creación de tablas, de poblado de datos, de modificación, etcétera)
## Tablas
Para las bases de datos relacionales, es necesario cumplir con las siguientes condiciones:
* Se debe evitar el uso de tablas temporales.
* Todas las tablas deberán tener una columna con una llave primaria (*PK*). Se recomienda que sea un identificador numérico.
* Los nombres de tablas y columnas se tendrán que nombrar en singular.
## Prefijos
Para las bases de datos relacionales, es necesario utilizar los siguientes prefijos:
| Elemento | Prefijo |
| ----- | ----- |
| Procedimiento almacenado | “*sp\_*” |
| Función | “*fn\_*” |
| Trigger | “*tg\_*” |
| Vista | “*vw\_*” |
## Seguridad
Tareas del administrador de bases de datos (*DBA*):
* Es obligatorio el uso de un usuario de base de datos que tenga permisos restringidos únicamente relacionados con el sistema de información.
* Es obligatorio limitar el privilegio al mínimo necesario.
* Es obligatorio llevar un control de versiones de la base de datos.
* En caso de existir un usuario súper administrador en un ambiente de producción, es recomendable eliminarlo.
* Es recomendable asignar contraseñas robustas a los usuarios de la base de datos.
* Es recomendable utilizar cifrado en las conexiones con SSL, o usar un túnel SSH.
* Es obligatoria una revisión periódica del espacio en disco y los logs del sistema.
* Es obligatorio realizar copias de seguridad periódicamente y probar su correcto funcionamiento.
## Rendimiento
* Evitar el uso de vistas y procedimientos almacenados.
* Evitar la creación y el uso de columnas con datos binarios.
* En caso de tener columnas con datos binarios deben estar en tablas separadas referenciadas con la PK, con el fin de mejorar el tiempo en las búsquedas y las copias de seguridad.
* Evitar usar el asterisco (\*) en las sentencias *SELECT*.
* Si se van a realizar muchas inserciones o actualizaciones en una tabla, se deben utilizar [tareas por lotes](https://learn.microsoft.com/en-us/sql/odbc/reference/develop-app/batches-of-sql-statements?view=sql-server-ver16).
* En caso de necesitar una consulta que involucre muchas columnas y/o conversiones de las mismas, se recomienda crear un [campo computado](https://learn.microsoft.com/en-us/sql/relational-databases/tables/specify-computed-columns-in-a-table?view=sql-server-ver16).
* Para los desarrollos, es recomendable guardar tokens, credenciales u otra información sensible por medio de variables de entorno.
* Nunca se deberán almacenar contraseñas, tokens, claves privadas o cualquier tipo de información sensible en el código fuente.
* Es obligatorio el uso de gestores de contraseñas para almacenar y compartir datos sensibles entre desarrolladores u otros integrantes del equipo.
* En el caso de tener que almacenar contraseñas, es obligatorio el cifrado u ocultamiento de la información. Se recomienda el uso de un algoritmo de [hash](https://en.wikipedia.org/wiki/Hash_function) junto con una [sal](https://en.wikipedia.org/wiki/Salt_\(cryptography\)).
* En el caso de tener que almacenar datos sensibles (Por ejemplo, números de tarjetas de cŕedito), se deberá utilizar un algoritmo de cifrado robusto (por ejemplo, [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard)) con una clave de al menos 128 bits.
## Recomendaciones (Web)
* Todos los sistemas de información deberán implementar un sistema de [registro de eventos (logs)](logs.md).
* Todas las conexiones y manejo de credenciales y datos sensibles deben ser responsabilidad del back end. Bajo ninguna circunstancia el front end debe manejar directamente este tipo de datos.
* Los sistemas de autenticación deberán implementar protecciones ante ataques de [fuerza bruta](https://en.wikipedia.org/wiki/Brute-force_attack).
* Es recomendable que los sistemas de autenticación implementen un sistema de detección de robots del lado del servidor.
* Es recomendable habilitar sistemas de doble verificación (por ejemplo, [TOTP](https://en.wikipedia.org/wiki/Time-based_one-time_password)) en los sistemas de autenticación.
* Las restricciones y permisos de los roles de usuario en el sistema deberán funcionar en el front end y en el back end por igual.
* Los desarrollos web tendrán que estar preparados para ataques [XSS](https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting), [CSRF](https://developer.mozilla.org/en-US/docs/Glossary/CSRF) y [SQL Injection](https://developer.mozilla.org/en-US/docs/Glossary/SQL_Injection).
* Todas las plataformas web del ambiente de producción tendrán que implementar protocolos de comunicación cifrados (Por ejemplo, HTTPS).
## Recomendaciones (Redes y conexiones)
* Las conexiones a servidores Linux en producción deberán realizarse con claves privadas.
* Se recomienda que la conexión a sistemas privados y servicios de pruebas se realicen con una conexión por VPN.
* Se recomienda que las conexiones a los servidores sean restringidas por IP pública, en caso de que los servidores pertenezcan a un servicio en la nube privado.