¿Desarrollas aplicaciones? Presta atención al riesgo de configuration drift

¿Desarrollas aplicaciones? Presta atención al riesgo de configuration drift

Lorena Fernández

Quien está a cargo de desarrollar una aplicación o bien, si participa dentro de ese proceso, sabe que existen múltiples procedimientos a realizar. Se supone que una aplicación, para el propósito que fuese, pasa por constantes cambios para que funcione cada vez mejor. Así también, para que sea cada vez más segura y que mantenga la privacidad de los datos de los usuarios. Sin embargo, ¿qué pasa si es que todos estos cambios desembocan en problemas? Hoy en RedesZone os hablaremos sobre el tema del configuration drift.

Siempre que se desarrolle una aplicación, la misma necesita pasar por cambios. Los cuales se ven reflejados en actualizaciones. Dichos cambios pueden reflejar mejoras en la interfaz de usuario o alguna mejora en su infraestructura que permita mejor rendimiento. Sin embargo, existe el riesgo de que los cambios puedan afectar de forma negativa a la aplicación. Algunos, incluso, pueden dejarla inservible. A esta situación, se la conoce como configuration drift (desvío de configuración). Esto hace que las aplicaciones empeoren su rendimiento en general, en vez de mejorar.

Pero esto no significa que puedan existir precisamente cierto tipo de actualizaciones que se aplican abiertamente para poder generar tal configuration drift. Una serie de malas prácticas pueden hacer que progresivamente la aplicación pueda bajar su calidad de rendimiento y así también, sus niveles de seguridad.

Configuration drift y escalada de privilegios

Un ejemplo práctico que podemos citar, es el típico desarrollador de aplicaciones que accede frecuentemente a un servidor. De hecho, el acceso debe ser permanente, incluso para los más pequeños cambios y revisiones en general. Si quiero hacer algún cambio en la aplicación en producción (es decir, el entorno que hace que la aplicación funcione como tal para los usuarios), es necesario contar con credenciales de administrador especiales. A este desarrollador no le agrada la idea de tener credenciales adicionales porque finalmente, esto implica tiempo extra que puede perjudicar los tiempos que tiene para entregar sus cambios en la aplicación.

De todas formas, este desarrollador ha conseguido las credenciales que necesita para los cambios en producción que necesita hacer. Incluso, puede alterar sus permisos y agregar los que necesita para que pueda contar con permisos de administrador mediante la interfaz de gestión de usuarios. Aparentemente, no hay problema, ya que esos permisos de administrador únicamente se aplican al servidor al cual necesita acceder el desarrollador.

Recordemos que cualquier procedimiento que se aplique en producción puede salir muy bien o muy mal. Y si sale muy mal, los usuarios son los principales afectados. Una situación que refleje un cambio en producción mal aplicado es cuando una persona actualiza la aplicación a su última versión. Pero por desgracia, esa última versión no permite que la persona inicie sesión a su cuenta, muestre permanentemente un mensaje de error etc. El desarrollador de este ejemplo no tiene intenciones que van más allá de realizar su trabajo en tiempo y forma, ya que el tiempo que tiene para su proyecto está muy ajustado.

Pero, ¿qué pasa si en vez de esta persona se encuentra involucrada es un cibercriminal o algún colaborador mal intencionado? La escalada de privilegios es uno de los ataques que más secuelas deja a una red, sistema, y a su infraestructura en general. La peor parte es que este tipo de ataque es que muchas veces, pasa desapercibido. Y esto es porque el usuario malintencionado realiza todas las actividades de forma enmascarada, lo que significa que las mismas pasan por los controles de seguridad y éstos los detectan como benignas.

Incluso si el usuario que aplica la escalada de privilegios no tiene intenciones de llevar a cabo un ataque, puede tener potenciales problemas en otros aspectos. Si se diese un proceso de auditoría y se refleja este tipo de actividad, será muy difícil justificarla. Y si esto resulta ser algo que va en contra de las políticas o regulaciones en cuanto a cumplimiento, tanto el colaborador como la organización puede tener inconvenientes.

Consejos básicos para evitar el «configuration drift»

Del ejemplo que hemos citado más arriba, podemos extraer un par de recomendaciones. La primera consiste en documentar todo lo que refiere al desarrollo de la aplicación o servicio. Sin embargo, esto no se cierra a los manuales de procedimiento o instrucciones en general. Esto también tiene que abarcar todas las mejoras y cambios que se deban hacer a la aplicación. Es como tener un log de todos los inicios de sesión a una determinada base datos o cualquier otra aplicación.

Esa documentación tiene que informar en detalle acerca de todos los cambios hechos, los impactos que tiene. También debería incluir qué requisitos se debe cumplir para contar con la actualización, entre otros datos. Por desgracia, la práctica de la documentación es una de las que menos focos de atención tiene. Sin embargo, comienza a cobrar algo de importancia ante eventos como las auditorías o incidentes de seguridad.

Haciendo foco a la seguridad, hay que monitorizar de cerca a las credenciales de administrador. Uno puede pensar que un usuario con permisos de administrador no debería valerse de sus permisos en cuestión para alguna actividad maliciosa. Sin embargo, más arriba comentamos cómo la escalada de privilegios es un aliado importante para el configuration drift.