Lecciones Aprendidas: Errores en el Despliegue de un Sistema en Producción
Bienvenidos a «Lecciones Aprendidas», una serie en la que compartimos nuestros mayores errores para que tú no cometas los mismos. En el episodio de hoy, me remonto a una época en la que era desarrollador web y estaba implementando una solución en un sistema en producción. Trabajaba en la solución en mi portátil y la subí a un sistema de pruebas. Verifiqué que todo funcionaba como se esperaba y, siguiendo un manual de operaciones, la subí al sistema en producción. Nuevamente, verifiqué que todo funcionaba correctamente.
En ese momento, estaba listo para pasar a mi siguiente tarea y quería hacer limpieza. En ese momento, ejecuté un comando que pensé era razonable: «rm -f» para borrar los archivos de prueba que había estado utilizando. Inexplicablemente, recibí una advertencia que decía «no tienes permiso para hacer eso». Hmm. Bueno, aquí es donde cometí un gran error. Cambié al usuario root y eliminé los archivos de todas formas con el mismo comando. Pocos momentos después, el sistema en producción se cayó. Lo que había hecho era hacer clic en la ventana de producción cuando realmente pensé que estaba en el sistema de pruebas. Y pensé que estaba en un directorio remoto cuando, en realidad, estaba en el directorio raíz del sistema en producción. Por supuesto, al borrar ese directorio, el sistema colapsó.
La buena noticia es que teníamos más de un servidor en producción. Teníamos el production 2 y el production 3. Así que saqué este servidor de rotación y el sistema en producción volvió a funcionar. ¿Qué lecciones aprendí de eso? Bueno, la primera, por supuesto, es que los duplicados pueden salvarte de mucha vergüenza. Hoy en día, nos referimos a eso como una implementación blue/green, donde primero implementas en un subconjunto de servidores y luego lo extiendes a más servidores a medida que te sientes más seguro de que el cambio que hiciste es legítimo. Y si hay un problema, puedes revertirlo rápidamente sin afectar a muchos servidores.
Pero probablemente la lección más importante aquí es tener una separación de roles. Tal vez fue una cuestión de conveniencia, quizás un poco de pereza, pero en ese momento tendíamos a compartir contraseñas de algunas de estas cuentas de administrador. Y parte de la razón por la que hicimos eso es que los administradores realmente no querían que se les moleste con, ya sabes, «aplica este pequeño cambio por mí». «Aquí, dame solo esa contraseña y me encargaré y me apartaré de tu camino». Pero sería mucho más inteligente usar algún otro mecanismo y, como mínimo, por ejemplo, utilizar grupos. De esa manera, no tendrías un usuario root, sino un grupo específico de usuarios que pueden realizar funcionalidades específicas dentro de determinadas secciones de tu entorno de producción. Pero aún mejor es tener un sistema de gestión de acceso privilegiado. Tenemos un vídeo al respecto por si quieres aprender más, pero la idea aquí es eliminar la necesidad de tener acceso root para un desarrollador. En su lugar, proporciona una forma conveniente de compartir algunas de estas funciones de alto nivel con diferentes usuarios, pero manteniendo la trazabilidad. Con el sistema de gestión de acceso privilegiado, puedes tener un inicio de sesión que, en lugar de ser un inicio de sesión directo, pasa por un sistema separado que gestiona las contraseñas entre múltiples usuarios para una identificación de usuario compartida. Por supuesto, esto también elimina el acceso root. También argumentaría que realmente deberías limitar el acceso sudo, ya que podrías sentirte tentado a hacerlo también, que es una idea en la que puedes cambiar a un usuario root solo para un comando. Eso sería un poco mejor. Pero aún así, un desarrollador no debería tener ese nivel de autoridad.
Realmente, la lección más importante que podemos extraer de esto es automatizar tu implementación. En mi caso, estaba siguiendo un manual de operaciones, pero en retrospectiva, habría sido mucho más inteligente tener un script que implementara automáticamente en producción. Dicho script tendría todos los inicios de sesión necesarios para poder hacerlo. Podría probar para asegurarse de que los cambios se hayan aplicado correctamente y revertirlos si detecta que algunos sistemas están fallando. Si haces esto, esperemos que puedas evitar la vergüenza que yo sufrí.
Resumen de Artículo
| Lecciones Aprendidas | Recomendaciones |
|---|---|
| Duplicados pueden salvarte de la vergüenza. | Implementa una estrategia de implementación Blue/Green. |
| Tener roles separados para usuarios privilegiados. | Utiliza grupos y sistemas de gestión de acceso privilegiado. |
| Automatiza tu despliegue. | Crea scripts automatizados y verifica que los cambios se hayan aplicado correctamente. |
Preguntas Frecuentes (FAQs)
1. ¿Qué es una implementación Blue/Green?
Una implementación Blue/Green es una estrategia en la que primero se implementa un cambio o actualización en un entorno de prueba o un subconjunto limitado de servidores en producción (es decir, el entorno «Blue»). Una vez que se verifica que el cambio es exitoso y no presenta problemas, se procede a implementarlo en el resto de los servidores (es decir, el entorno «Green»). Esto permite minimizar el impacto en caso de que surjan problemas durante o después de la implementación.
2. ¿Por qué es importante tener roles separados para usuarios privilegiados?
Tener roles separados para usuarios privilegiados ayuda a garantizar una gestión más segura y controlada de los recursos y permisos del sistema. Al asignar roles específicos a grupos de usuarios, se pueden limitar y controlar las acciones que cada usuario puede realizar dentro de ciertas secciones del entorno de producción. Esto reduce el riesgo de errores humanos o acciones maliciosas, así como también facilita la trazabilidad y responsabilidad en caso de incidentes.
3. ¿Qué es el acceso privilegiado y cómo se gestiona?
El acceso privilegiado se refiere a los permisos y capacidades especiales que se otorgan a ciertos usuarios para realizar tareas críticas de administración en un sistema. Para gestionar el acceso privilegiado de manera segura, se utilizan sistemas de gestión de acceso privilegiado que permiten compartir funciones de alto nivel con diferentes usuarios sin la necesidad de otorgar una identidad de usuario con acceso root. Estos sistemas facilitan la gestión de contraseñas, control de acceso y trazabilidad de las acciones realizadas por cada usuario.
4. ¿Cuál es la importancia de automatizar el despliegue?
Automatizar el despliegue proporciona una forma más eficiente y segura de implementar cambios en un sistema en producción. Al utilizar scripts o herramientas automatizadas, se reducen las posibilidades de errores humanos, se agiliza el proceso de implementación y se facilita la capacidad de revertir cambios si algo no funciona como se esperaba. Esto también brinda una mayor consistencia y estandarización en el proceso de despliegue, lo que a su vez aumenta la confiabilidad del sistema en general.
Espero que estas lecciones aprendidas te sean útiles y te ayuden a evitar cometer los mismos errores. Recuerda que en Todoforti.net tenemos más artículos relacionados con la ciberseguridad y las mejores prácticas para mantener seguros tus sistemas. ¡No dudes en echarles un vistazo!
Hasta la próxima y ¡sigue protegiendo tus sistemas!
¿Te ha resultado útil??
0 / 0
Hola, somos Mila Jiménez y César Sánchez. Dos apasionados de la ciberseguridad con muchos años de experiencia. Hemos trabajado en muchas empresas del mundo TI y ahora nos apetece compartir nuestro conocimiento con cualquiera que lo necesite.
¡Si te gusta nuestro contenido puedes invitarnos a un café AQUÍ!