Regla de seguridad uno: Probablemente lo estés violando ahora mismo.
A estas alturas ya has oído la Regla de Seguridad Cero lo suficiente como para saberla de memoria . Te lo sabes de memoria ¿verdad?
Por si acaso, déjame refrescarte la memoria:
NO DEBERÁS CONFIAR EN LA APORTACIÓN DEL USUARIO. ALGUNA VEZ.
Excelente. Ahora que hemos establecido y dejado de lado esa regla fundamental, hablemos de la Regla de Seguridad Uno. Porque como habrás adivinado, hay más de una regla de seguridad. Bien, pasemos a la regla número uno, ¿de acuerdo?
REGLA DE SEGURIDAD UNO: NO DEBERÁS CODIFICAR LAS CREDENCIALES. ALGUNA VEZ.
En una era de control de acceso a través de tokenización (popular para las API) e identidad federada, esta regla rara vez se rompe en las aplicaciones públicas. Donde a menudo esta regla se rompe y se ignora es dentro de la organización. Y esto se está convirtiendo rápidamente en un problema a medida que NetOps prepara el uso de scripts y automatización para hacer su parte para optimizar la TI en apoyo de las iniciativas de transformación digital de su organización.
Permítanme ilustrarlo con uno de los ejemplos muy reales que encontré en Internet. Digo uno porque no tengo ni el tiempo ni el ancho de banda para proporcionar una lista completa. La práctica es así de generalizada.
A su derecha verá un error de seguridad extremadamente común: texto simple y credenciales codificadas. Ni siquiera hay un comentario que reconozca que es inaceptable en un entorno de trabajo ni una señal que indique la necesidad de utilizar un método de autenticación más seguro.
Esto me preocupa profundamente en el contexto del lado de NetOps porque el radio de explosión es significativamente mayor cuando se interviene en la red corporativa compartida.
Una de las razones por las que vemos este tipo de problemas de seguridad es porque, si bien es cierto que NetOps está adoptando la automatización, no necesariamente la está adoptando de manera estratégica. Lo que estamos viendo es un porcentaje significativo de profesionales de NetOps que adoptan Python y lo combinan con un método tradicional de configuración y gestión basado en CLI.
De la misma manera que escriben credenciales en la línea de comandos, introducen esas mismas credenciales en un script y listo.
Al final esto será un problema. Veremos a alguien aprovecharse de esta práctica y estará en nuestras noticias durante días. Porque ese tipo de cosas ya han sucedido antes. ¿Recuerdas OneLogin ? Si bien no almacenaban scripts con credenciales, sí almacenaban archivos con credenciales. Podéis imaginaros el lío que se armó.
El problema es que NetOps puede sentirse bastante seguro de poner credenciales de línea de comandos en un script, pero ¿dónde termina ese script? ¿Se gestiona como debería ser? ¿Te gusta la infraestructura como código? ¿Está versionado y guardado en un repositorio?
Quizás recuerdes una encuesta de la comunidad Network to Code que mostró una alta tasa de adopción entre NetOps para (espera...) Github.
Preguntémonos entonces: ¿dónde está nuestro repositorio? ¿Esta fuera del sitio? ¿En el sitio? ¿Cómo está protegido y cuál es el radio de explosión si alguien lo logra?
Necesitamos, para poder mantener y servir al negocio, escalar las operaciones a través de scripts y automatización. NetOps tiene que avanzar en esa dirección, pero no debería hacerlo sin considerar seriamente las ramificaciones de las credenciales de texto simple almacenadas, bueno, en cualquier lugar.
Como mínimo, los scripts deben requerir el ingreso de credenciales al momento de la invocación. Las credenciales nunca deben almacenarse en un archivo o en un script , y ciertamente nunca en texto sin formato. Lo mejor sería utilizar una solución de gestión de credenciales más avanzada para forzar la autenticación y utilizar la tokenización en scripts internos. Pero sé que en este momento estamos en los momentos iniciales de la adopción masiva de la automatización en NetOps, y tenemos que avanzar paso a paso.
Con esto en mente, al menos se deben exigir credenciales al momento de la invocación. Si esto es demasiado difícil con su implementación actual, entonces tal vez sea momento de dar un paso atrás y echar un vistazo a su estrategia general de automatización para TI. La primera pregunta es: ¿tienes uno? ¿O lo que estás haciendo es una respuesta táctica (y primaria) a las demandas del negocio?
Porque la solución a largo plazo no debería –no puede– ser credenciales en texto simple en cada script. Además del obvio riesgo de seguridad, considere la deuda técnica en la que está incurriendo. Si tienes que cambiar las credenciales, tendrás que cambiarlas en todas partes . Se necesita tiempo y esfuerzo para localizarlos. Probablemente no tengas tiempo ni esfuerzo; de lo contrario, no estarías tan ansioso por dedicar tiempo a adoptar la automatización en primer lugar.
Así que por favor, no viole la Regla de Seguridad Uno. Sea más seguro y más inteligente que eso. La automatización no debería ser una respuesta táctica a los requisitos de escala y velocidad. Debe ser –y es– estratégico, y eso significa estar más atento a las ramificaciones a largo plazo de cómo se implementa.