Como bien menciono, hay hace un tiempo una buena forma de fortalecer la programación, y en base a eso la internet, plataformas, servicios, proveedores y cualquier cosa que hoy esté conectada de alguna forma a la red, en base al escaneo proactivo de «secretos».
Así como hay antivirus hace décadas, y podemos implementar rutinas de test en el proceso DevOps, hay recientemente muchas «filtraciones» de datos que podrían haberse dado al quedar descubiertas credenciales.
Las APIs son lo que conecta al mundo, son las interfaces de sistema y programación que vinieron a dar la oportunidad de integrar sistemas de forma fácil, pero a la vez, más allá de la seguridad y los permisos que puedan tener, terminan siendo débiles frente a una mala práctica de dejar en el código o mal protegida las credenciales.
¿Cómo funciona la autenticación en una API o Webservice?
Tendremos otro debate sobre API REST y Webservices SOAP, entre otras interfaces que podemos disponer o desarrollar para conectar o comunicar diferentes sistemas o partes de un sistema.
Pero básicamente, así como tu correo electrónico tiene usuario y clave, las APIs o Webservices tienen también «usuario y clave» o «api key y api token». Si alguien conoce, accede, descifra, encuentra o consigue esas credenciales, puede actuar de muchas maneras y ocasionar cambios, extracción de información y hasta daños deliverados.
A estas credenciales se las denomina en algunas plataformas «secretos«. En otras podemos leer que en vez de api token se le denomina api secret, es indistinto.
¿Por qué se filtran las credenciales, api keys, tokens y otras informaciones?
Bueno, una de las principales pésimas prácticas es colocar credenciales en el código. Se sube sin ofuscar o eliminar la credencial, a un repositorio público, y quedan expuestas.
También pasa al configurar de forma deficiente programas como Postman, por ejemplo, y donde compartes una colección de cierta plataforma donde estás probando sus APIs, y otra persona tendrá acceso a tus credenciales y/o incluso configuras que esa colección quede pública, disponible a todo el mundo.
Algunas tecnologías ya permiten marcar las credenciales y ofuscarlas o eliminarlas directamente al subir o compartir un desarrollo o batería de pruebas. También hay otras formas de protegerlas:
- Credenciales como variables de entorno.
- Cifrar las credenciales en base de datos.
- Separarlas en archivos de configuración y estos no se compartan.
- etc…
Escaneo masivo de «secretos» en las nubes de código (Github)
Las grandes empresas y millones de programadores utilizan las grandes «nubes de código» como GitHub, GitLab, Bitbucket, entre otras, para dejar almacenado sus sistemas, desarrollos, notas y más.
¿Por qué entonces no escanear estos secretos y notificar que están expuestos? ¿Y si se encuentra algún fragmento que de indicios de que no debiera publicarse, por qué no ofuscarlo de forma proactiva?
Bien, ese camino ha tomado por ejemplo GitHub y su Escaneo de Secretos, con un programa que permite no sólo a empresas y desarrolladores programadores de sistemas cuidar sus credenciales y accesos, sino además permitiendo que personas, empresas y programadores que usan otras plataformas también puedan aprovechar este servicio.
¿Cómo suscribir tu empresa o plataforma al programa de participación en Secrets Scanning de Github?
Si trabajas con alguna de estas plataformas ya suscriptas, los tokens de las mismas que publiques están cubiertos. Si eres parte de alguna otra empresa o plataforma y quieres ser parte, nada más deberás iniciar contacto y empezar a trabajar en conjunto con el equipo de GitHub para dentro de poco tiempo estar participando.
¿Cómo funciona GitHub Secrets scanning?
Las plataformas comparten cierta información que permite armar patrones regulares de credenciales, tales como fragmentos de tokens que se generan y los headers más habituales (ej: «plataform-api-key», «some-api-secret», y un patrón/regExp, por ejemplo, etc).
Además GitHub trabaja de forma proactiva con esas plataformas mediante el escaneo y notificación que se encontró una posible credencial, y en qué repositorio. Se sugiere validar falsos positivos y luego, dependiendo las políticas que cada empresa elabore, notificar al usuario y anular las credenciales usadas por otras nuevas.
Este es el esquema de como funciona y se integra GitHub Secrets:
Algunas preguntas y respuestas que encuentro relevantes para cerrar:
- ¿Debo compartir, como empresa, todos mis key/tokens con GitHub? No, sólo es necesario el key, como referencia, y generar patrones o expresiones regulares para que puedan coincidir con el escaneo.
- ¿Aplica en todo lo que se sube o publica en GitHub? Sólo en repositorios públicos. Para empresas que usan la nube de GitHub Enterprise, es posible aplicar otras reglas avanzadas.
- ¿Se le notifica al usuario o sólo a la empresa? Por lo que veo en la documentación el programa envía una notificación casi inmediata a la empresa parte del programa, se sugiere revocar el token y contactar al usuario. En apariencia GitHub no genera un aviso al programador/usuario individual.
- ¿Es posible hacer un filtro o validación manual de las alertas? Claro, y hasta en los documentos lo sugiere para no revocar unas credenciales y generar desconexión o daño. También pueden darse falsos positivos o quizás hasta que algunas credenciales sí sea deseo que sean públicas.
