Ya podemos decir que estamos hablando de una serie de artículos, donde primero vimos cómo crear las claves SSH pública y privada, después cómo acceder a la máquina virtual Linux por SSH y ahora vamos a ver cómo acceder a la máquina Linux por escritorio remoto (RDP). Estos artículos no sólo está relacionados, sino que para una correcta implementación requiere seguir un orden correlativo.
Si la semana pasada estuvimos viendo cómo generar claves SSH sin complicaciones desde Windows, hoy vamos a ver cómo conectarnos a las máquinas virtuales Linux que tenemos en Azure utilizando las claves SSH. Por lo tanto, para poder seguir este artículo es imprescindible que anteriormente hayamos creado el archivo PPK de clave privada, como por ejemplo con PuTTYgen, algo que hemos explicado detalladamente en el artículo anterior.
Recientemente, montando una infraestructura en Azure con múltiples máquinas virtuales Linux, alguien me comentó que se estaban encontrando con muchos problemas siguiendo los pasos indicados por Microsoft para crear claves SSH. Eso me ha llevado a escribir este artículo, ya que efectivamente para estos casos necesitamos generar y utilizar claves SSH (Secure SHell) para poder conectarnos con estas máquinas Linux hospedadas en Azure.
Microsoft Flow es uno de los servicios disponibles en Office 365 por el que Microsoft está apostando como herramienta de integración transversal con casi prácticamente cualquier servicio en la nube. Hace un tiempo, nuestro compañero Sergio Hernández ya presentó este servicio en este mismo blog. En esta ocasión vamos a ver un caso de uso real en el que en ENCAMINA hemos utilizado Flow para integrar correo de Office 365 con SAP CRM.
Azure Security Center utiliza el Control de acceso basado en roles (RBAC), que proporciona roles integrados que pueden asignarse a usuarios, grupos y servicios en Azure. Cuando se planea utilizar el Security Center, es importante leer previamente el artículo sobre Permisos en Azure Security Center para tener una visión más precisa sobre los roles clave y las acciones que estos roles pueden realizar.
Como ya leímos en el post de introducción a Azure Databricks, nuestros desarrollos estarán basados en Notebooks que podemos ejecutar bajo demanda o programados en un Job. Este modelo de trabajo implica una buena gestión de las cadenas de conexión, claves o Secrets que vamos a compartir con los desarrolladores o usuarios que acceden a los Notebooks. No queremos tener ningún problema de seguridad, si ocurriera que se perdiese una cadena de conexión a alguna de nuestras bases de datos.
Antes de contaros qué es Azure Databricks, hablemos de Apache Spark y de Notebooks para que podamos entender perfectamente qué es.
En el mundo de la tecnología no hay nada más vulnerable que el usuario y sus malas prácticas, impulsadas principalmente por el exceso de confianza, despreocupación y desconocimiento. La mala práctica más extendida es el uso de contraseñas débiles y predecibles, y es que habitualmente los usuarios utilizan contraseñas que les resulte fácil de recordar y/o reutilizan las mismas contraseñas una y otra vez.
Son muchas las organizaciones, grandes o pequeñas, las que de una u otra forma, analizan sus datos: financieros, de ingresos, de gastos, de operaciones, de proyectos, etc. Y es que, gracias a ese análisis y esos indicadores que representan cómo va el negocio, es posible tomar decisiones ¡Benditos indicadores de negocio 🙏!
Imagina un servicio que monitorice cualquier cambio en tus ficheros y registros del sistema operativo, así como en tus aplicaciones u otro tipo de archivo para detectar cualquier indicio de ataque o infección… Esto existe y ya está disponible como preview en Azure Security Center.
¡Suscríbete a nuestras RRSS!
