Hace tan solo unos meses, AWS anunció el soporte dirigido a TLS mutuo (mTLS o muthual authentication) para su servicio Application Load Balancer (ALB).

A medida que nuestras bases de datos y nuestro volumen de negocio va creciendo, es muy habitual empezar a apreciar un deterioro en el rendimiento de las mismas. Esto es lógico, ya que no se están soportando las mismas cargas de trabajo ni se está trabajando con el mismo volumen de datos que antes.

Ante esta situación, uno puede pensar que simplemente toca ampliar los recursos de los servidores y olvidarse de ello, pero lo cierto es que esta solución no siempre es ni necesaria ni idónea. 

En artículos anteriores tratamos el tema de cómo auditar eventos en diferentes sistemas, y en el caso de Windows explicamos cómo hacer que estos quedasen reflejados en el Visor de Eventos. Ahora bien, como también hemos comentado en otras ocasiones, lo ideal es que todo log se envíe a un sistema centralizado para el visionado de los mismos en un único lugar, y para ello hay que hacer uso de un software específico para este fin.

En entornos Windows tenemos multitud de posibilidades, una de ellas es el uso del software NXLog, que es el que vamos a tratar en el artículo de hoy y cuyo funcionamiento veremos con un pequeño ejemplo.

Hace unos meses realizamos un interesante artículo titulado Auditar eventos y acciones en sistemas Linux y Windows, donde mostrábamos cómo dejar reflejadas en logs las diferentes llamadas al sistema en máquinas Linux y Windows. Al final de dicho artículo recalcábamos que esta solución sólo contemplaba el tener los logs en local, y que en entornos con varios servidores, lo más conveniente era poder enviar estos logs a un sistema centralizado. Este es el tema que vamos a tratar en el artículo de hoy, centrándonos concretamente en entornos Linux.

Puesto que este artículo es una continuación del mencionado anteriormente, explicaremos cómo centralizar logs del servicio audit, pero debemos destacar que esta solución también es válida para centralizar cualquier tipo de log, ya sea de Apache, Nginx, Tomcat, MySQL o lo que necesitéis.

La seguridad informática es un pilar fundamental para los administradores de sistemas y para las empresas que quieren mantener a salvo sus datos. Tener bien securizados nuestros servidores y sistemas es esencial para garantizar esta seguridad ante posibles intrusiones, pero igual de importante es tener controlado qué hacen los usuarios dentro de estos servidores, sin importar que sean usuarios autorizados.

El pasado 10 de junio se publicó Debian 12, que viene bajo el nombre de “Bookworm”. Esta versión del popular sistema operativo tendrá soporte hasta 2028, y tras su salida, Debian 11 “Bullseye” ha pasado a ser oldstable aunque su soporte se mantiene hasta 2026. Mientras, Debian 10 “Stretch” pasa a ser oldoldstable y ya no recibe actualizaciones de seguridad, aunque aún tiene soporte LTS hasta el año que viene.

En este artículo vamos a comentar algunos de los cambios que más nos han llamado la atención y que creemos que se deben tener en cuenta para aquellos que vayan a actualizar a esta nueva versión. Os incluimos una guía de cómo realizar dicha actualización

¡Comenzamos!

En este artículo nos alejaremos del apartado más técnico y hablaremos de arquitectura, pero no de aquella de estilo barroco o renacentista, ni de las grandes construcciones como el Burj Khalifa, sino de arquitectura en la nube.
 
Concretamente nos vamos a centrar en el servicio VPC de AWS y vamos a plantear la situación de tener los entornos de producción y preproducción (u otros entornos no productivos):

• En diferentes VPCs
• En diferentes subredes dentro de la misma VPC

Además, todo ello puede tener impacto en el tema de costes, que suele ser uno de los puntos que más nos preocupan.

Antes de nada convendría repasar el concepto de VPC.

Cuando nuestras bases de datos van creciendo, ya sea en número de tablas, en número de registros, o ambas cosas, es muy común que empecemos a apreciar una degradación en el tiempo de ejecución de las queries de lectura, especialmente si éstas son complejas y tienen que coger datos de diferentes tablas.

Por suerte, MySQL ofrece opciones para acelerar (optimizar) estas consultas.

Pero antes de pasar a explicar este proceso, vamos a empezar por comprender un concepto básico: ¿cómo elige InnoDB (el motor de almacenamiento que utiliza MySQL) el mejor camino a seguir a la hora de recoger datos? La respuesta es: sirviéndose del contenido almacenado en la tabla statistics.

Esta tabla, que se encuentra en la base de datos information_schema, almacena información sobre los índices de todas las tablas del conjunto entero de las bases de datos.