Por qué debería dejar de usar MSSQL Server como origen de datos compartido de RDM

Microsoft SQL Server (MSSQL) ha sido durante mucho tiempo una opción habitual como origen de datos compartido para Devolutions Remote Desktop Manager (RDM). Es un sistema conocido, rinde bien y resulta fácil de implementar.

El problema hoy no es MSSQL Server en sí, sino la arquitectura con la que acaba la mayoría de los equipos: ordenadores de usuario con acceso directo por red a la base de datos que almacena datos operativos confidenciales. Esto aumenta la exposición, crea más puntos de fallo y añade una carga administrativa constante.

Devolutions Server frente a Devolutions Cloud: una guía rápida para decidir

La mejor opción es abandonar los orígenes de datos compartidos de MSSQL de acceso directo y pasar a un origen de datos autoalojado o alojado en la nube. En lugar de que cada cliente de RDM se conecte a la base de datos, los usuarios se conectan a una capa de servicio que centraliza el acceso y reduce el número de puntos en los que pueden fallar los permisos, la conectividad o la configuración.

Ese es el cambio que hay detrás de Devolutions Server y Devolutions Cloud. Devolutions Server le ofrece un origen de datos autoalojado, mientras que Devolutions Cloud le ofrece uno alojado en la nube. Ambos sustituyen el acceso directo de RDM a la base de datos por un modelo de acceso seguro respaldado por DVLS o Cloud.

Elija Devolutions Server si la mayoría de estos puntos se aplican a su caso:

• Necesita autoalojamiento por motivos de cumplimiento, requisitos de clientes o política interna.
• Quiere control total sobre la infraestructura, las actualizaciones y la ubicación de los datos.
• Se siente cómodo operando una aplicación de servidor dentro de su entorno.

Elija Devolutions Cloud si la mayoría de estos puntos se aplican a su caso:

• Quiere reducir la propiedad de infraestructura y el mantenimiento continuo.
• Quiere una implementación más rápida con menos dependencias del alojamiento y la conectividad de bases de datos.
• Prefiere un enfoque orientado a la nube para el acceso compartido a bóvedas y la colaboración.

Si tiene dudas, use este criterio de desempate: si mantener servidores es precisamente lo que quiere reducir, Devolutions Cloud suele ser la mejor opción.

Una migración más sencilla

La forma más fluida de abandonar el acceso directo a MSSQL suele ser una implementación por fases: configurar el nuevo origen de datos, migrar los datos, validarlos con un grupo reducido y, después, trasladar al resto del equipo al nuevo origen de datos compartido en RDM.

Pasar de MSSQL con acceso directo a Devolutions Server

Si desea un destino autoalojado, utilice el asistente de migración de la consola de Devolutions Server para pasar de MSSQL Server, incluido Azure SQL, a Devolutions Server.

Siga la guía paso a paso aquí: Migrar bóvedas de MSSQL Server a Devolutions Server

Nuestra ruta de transición recomendada es la siguiente:

• Implemente Devolutions Server junto a su origen de datos actual.
• Haga una copia de seguridad de la base de datos.
• Ejecute el asistente de migración y valide los datos migrados con un grupo reducido de usuarios.
• Impleméntelo para el resto del equipo.
• Una vez que todos hayan hecho el cambio, restrinja el acceso directo a SQL y retire el antiguo origen de datos compartido.

Pasar de MSSQL con acceso directo a Devolutions Cloud

Si desea un destino alojado en la nube, traslade sus bóvedas de MSSQL a Devolutions Cloud exportándolas desde el origen de datos e importándolas en Devolutions Cloud.

Siga la guía paso a paso aquí: Migrar bóvedas de MSSQL Server a Devolutions Cloud

Un plan de implementación práctico sería el siguiente:

• Cree su Devolutions Cloud y añádalo como origen de datos en RDM.
• Haga una copia de seguridad de la base de datos existente.
• Exporte las bóvedas desde el origen de datos e impórtelas en Devolutions Cloud.
• Vuelva a crear y verifique los permisos durante la migración.
• Valide con un grupo de usuarios, amplíe la implementación gradualmente y, después, retire el origen de datos de MSSQL.

Por qué esto mejora tanto el control como el trabajo diario

Ya se centre en reducir el riesgo, mantener la fiabilidad de los sistemas o simplemente ahorrar tiempo, las ventajas son las mismas.

Seguridad y control

• Menos puntos finales pueden intentar acceder al backend sensible.
• El acceso se aplica a través de una capa de servicio en lugar de un acceso directo a la base de datos.
• Se reducen los patrones de acceso indirecto creados por la conectividad directa a MSSQL.

Eficiencia operativa

• Menos tiempo dedicado a solucionar problemas de conectividad con MSSQL ordenador por ordenador.
• Incorporación y baja de usuarios más limpias, ya que el acceso se gestiona a través de la plataforma.
• Menos casos particulares en la gestión de la red y de los permisos.

Mucho más que un simple sustituto de la compartición de MSSQL

Pasar a Devolutions Server o Devolutions Cloud no consiste solo en reducir la exposición y simplificar la administración. También le da acceso a funciones de la plataforma que no forman parte de una configuración directa de MSSQL, como las aprobaciones de acceso, el inicio de sesión único (SSO), los mensajes seguros y los flujos de trabajo de acceso privilegiado. Para los equipos que elijan Devolutions Server, esto también puede incluir la sincronización del lado del servidor, las notificaciones por correo electrónico, las restricciones de GeoIP, la integración con Syslog y la compatibilidad con Azure Log Analytics.

Si necesita ayuda para migrar a un nuevo origen de datos, nuestro equipo de soporte está listo para ayudarle.