[21/01/2022] Cuando se construyen aplicaciones modernas, la gestión de los permisos de acceso durante eventos operativos es complicada.
Las mejores prácticas de seguridad especifican que los ingenieros -desarrolladores e ingenieros de operaciones- deben tener el menor acceso posible a la aplicación de producción y su infraestructura. A veces, los requisitos empresariales o las normativas del sector exigen que el acceso a la producción esté muy restringido. Pero incluso sin requisitos industriales o empresariales, las mejores prácticas de seguridad, como el principio de mínimo privilegio, dictan que los ingenieros deben tener el menor acceso posible a la producción, incluidos los ingenieros responsables de gestionar los problemas operativos de guardia.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Sin embargo, esto puede convertirse en un problema cuando un ingeniero de guardia tiene que ocuparse de un problema en una aplicación de producción. Cuando los permisos están muy controlados, los ingenieros de guardia ocasionalmente necesitan permisos adicionales para resolver problemas de producción. A veces, actos simples, como reiniciar un servidor de producción, están más allá de los permisos normales de un ingeniero de guardia, pero pueden ser necesarios en caso de emergencia.
¿Cómo realizan los ingenieros de guardia estas actividades durante una emergencia? Realizando una escalada de permisos. Se trata de una acción que otorga temporalmente a un ingeniero permisos adicionales para realizar procedimientos de emergencia que normalmente estarían fuera de sus permisos.
Pero ¿cómo puede un ingeniero escalar sus permisos sin que la capacidad de escalar sus permisos se conviertan en una vulnerabilidad de seguridad?
Hay cuatro maneras de lograr la escalada de permisos que pueden conceder a sus ingenieros de guardia los permisos que necesitan, limitando al mismo tiempo las vulnerabilidades de seguridad inherentes a la concesión de los permisos adicionales. Cada una tiene ventajas y desventajas.
BTG o Break the Glass
El modelo BTG o Break the Glass permite que un ingeniero de guardia solicite a un proceso del sistema una escalada de permisos, que se utilizará solo en una situación de emergencia. Cuando el ingeniero solicita estos permisos adicionales, un sistema automatizado le concede los permisos necesarios, pero registra inmediatamente la solicitud y envía una notificación a la dirección correspondiente para informarle de la solicitud. Dado que el ingeniero es consciente de esta notificación, sabe que solo puede "romper el cristal" durante una emergencia real, y que tendrá que explicar sus acciones más tarde, por ejemplo, durante una próxima revisión del incidente. Esto hace que sea poco probable que alguien solicite estos permisos adicionales excepto cuando sea absolutamente necesario.
Este modelo suele ser muy fácil de implementar en un entorno de producción, y permite a los ingenieros la flexibilidad que necesitan durante una emergencia. Sin embargo, el proceso de revisión es un proceso reactivo, no un proceso proactivo. Esto significa que la dirección solo puede revisar lo que ha sucedido para que el ingeniero escale sus permisos después del hecho. Si un ingeniero descontento solicita un BTG para obtener permisos para realizar una actividad nefasta, la dirección solo lo sabrá después de que ocurra, no antes. Debido a esto, el modelo de BTG es genial para entornos moderadamente seguros, pero no es aceptable cuando se requiere un alto nivel de seguridad o protección contra posibles malas acciones de los empleados.
Escalada registrada
En el modelo de escalada registrada, cuando un ingeniero necesita realizar ciertas actividades privilegiadas más allá de su nivel de permiso normal, utiliza comandos específicos que se registran y supervisan para detectar accesos inapropiados. Por ejemplo, si un ingeniero necesita acceder a una red privada protegida, puede iniciar sesión en un host bastión, un servidor que le da acceso a la red privada protegida. El host bastión registra todas las actividades que realiza el ingeniero, y las pone a disposición para su examen a posteriori. La intención es garantizar que ningún actor malo haya entrado y realizado acciones inapropiadas en la red protegida, pero que las actividades legítimas puedan seguir realizándose con normalidad.
Al igual que el modelo BTG, el modelo de escalada registrada permite a cualquier ingeniero con los permisos adecuados acceder a la red de producción para cualquier propósito apropiado, no solo para una emergencia. Sin embargo, estos usuarios solo tienen acceso desde un entorno de "casa de cristal", un entorno en el que cada acción realizada se hace visible para su análisis posterior. Esto proporciona muchas de las mismas ventajas del modelo BTG, pero con desventajas similares. En concreto, la dirección solo se enterará de la actividad nefasta después de que se haya producido y no tiene capacidad para prevenirla de antemano.
Escalada bipersonal
El escalado bipersonal es una mejora del modelo BTG, en el que el escalado BTG solo se permite si dos personas independientes están trabajando juntas en el problema, y ambas autorizan el escalado. Entonces, por política, todas las acciones que realicen en el marco de BTG deben ser revisadas por ambas partes, y ambas partes deben participar en todas las actividades de escalado realizadas.
Esto supone una gran mejora en la seguridad con respecto al modelo básico de BTG, porque elimina en su mayor parte que el empleado descontento pueda dañar la producción simplemente emitiendo una escalada de BTG. En su lugar, dos empleados deben trabajar juntos para realizar cualquier acción de forma proactiva. Ningún empleado puede dañar un sistema sin tener un segundo empleado como cómplice, lo que mejora significativamente la seguridad general.
El modelo de escalada de dos personas puede ser más difícil de aplicar, debido a los requisitos de la política que la gente debe seguir para que sea eficaz. Tiene que ser insostenible que un ingeniero trabaje con otro ingeniero para conceder el acceso BTG a dos personas, y luego permitir al ingeniero solitario el uso exclusivo y no supervisado del acceso. Este problema anula el propósito del modelo de escalada de dos personas.
Herramientas de alcance limitado
Para obtener la máxima seguridad, las herramientas de alcance limitado son el mejor modelo. Esto implica la creación de herramientas personalizadas que realicen actividades específicas necesarias para proporcionar mantenimiento operativo a una aplicación de producción. Si necesita realizar alguna acción más allá de sus capacidades normales, invoca la acción utilizando una herramienta diseñada a medida para realizar ese acceso.
Por ejemplo, si un ingeniero de guardia debe reiniciar un servidor de producción, normalmente se conectaría al servidor de producción como "root" y reiniciaría el servidor. Esto requiere un nivel de permisos que es inaceptable en la mayoría de los entornos de producción. Sin embargo, imagine una consola web que da a un ingeniero de operaciones la capacidad de pulsar un botón para iniciar un reinicio de los servidores de producción. Pueden, utilizando sus permisos normales, realizar una acción específica que normalmente requeriría permisos escalados.
La ventaja del modelo de herramientas de alcance limitado es que da al usuario las capacidades exactas que necesita, y solo esas capacidades. Esto preserva el principio de menor permiso, pero da al operador las capacidades específicas que requiere. La herramienta personalizada también suele ofrecer las ventajas del modelo de escalado registrado, ya que mantiene un registro de quién utiliza la herramienta y cuándo se utiliza, de modo que las actividades implicadas pueden rastrearse y examinarse posteriormente durante la revisión de un incidente.
La desventaja del modelo de herramientas de alcance limitado es que no proporciona un modelo de escalamiento genérico, sino que da acceso solo a capacidades específicas que fueron imaginadas de antemano, utilizando herramientas creadas para permitir esa acción. Si tiene que realizar alguna acción que requiera permisos escalados, y no hay ninguna herramienta disponible para realizar esa acción, usted, como ingeniero de operaciones, puede estar simplemente sin suerte.
Como tal, mientras que las herramientas de alcance limitado es el mejor y más seguro modelo en general, a menudo no se utiliza solo, sino en conjunto con uno de los otros modelos para los permisos imprevistos que puedan ser necesarios. Sin embargo, esto puede disminuir las ventajas de seguridad inherentes a este modelo.
¿Qué modelo es el mejor?
Estos cuatro métodos son las mejores prácticas, pero solo funcionan para algunas empresas y son inaceptables para otras. En la práctica, se suele emplear una combinación de varios métodos. Seleccionando los procesos, las complejidades y la supervisión operativa apropiados para su negocio y su industria, puede implementar la escalada de permisos sin comprometer indebidamente su aplicación y su seguridad.
Basado en el artículo de Lee Atchison (InfoWorld) y editado por CIO Perú
Lee Atchison es un reconocido líder de opinión en cloud computing y modernización de aplicaciones. Con más de tres décadas de experiencia en desarrollo, arquitectura, escalado y modernización de productos, Lee ha trabajado en Amazon, Amazon Web Services (AWS), New Relic y otras organizaciones de aplicaciones modernas. Es ampliamente citado en muchas publicaciones y ha sido un orador destacado en todo el mundo. El libro más reciente de Lee se llama Architecting for Scale (O'Reilly Media).
Puede ver también