Esta guía presenta un modelo mental para que los desarrolladores den sentido al panorama de la seguridad de la información y construyan aplicaciones más seguras. Debería desglosar los complejos requisitos de seguridad de una forma que resulte manejable. Pero antes hay que definir algunos términos.
Política: Conjunto de directivas, normas y prácticas que prescriben cómo una organización gestiona, protege y distribuye la información. Ejemplo: La empresa debe cumplir el GDPR.
Principio: Ideas compartidas por todas las aplicaciones seguras y aplicables a cualquier tipo de sistema informático. Cuanto más se apliquen, más sólida será la seguridad del sistema. Ejemplo: Principio del menor privilegio.
Norma: Técnicas específicas concebidas para proteger un sistema informático de una o varias maneras. Ejemplo. Especificación OAUTH2 para la autorización.
Directriz: Herramienta o tecnología proporcionada para ayudar a los programas a ajustarse a ciertas normas. Suele ser una tecnología específica. Ejemplo: Consultas parametrizadas en JDBC para evitar la inyección SQL.
Estas son definiciones de trabajo para esta guía. Estos términos tienen significados diferentes y superpuestos en otros contextos, pero serán suficientes para entender este modelo.
El modelo
La empresa u organización tiene una Política. El equipo elige una estándar que sigue los buenos diseño y se adhiera a la política de la empresa. Existen Directrices que describen cómo debemos aplicar esa Norma en nuestra pila tecnológica específica. Usamos la culminación de éstas para escribir buenos Requisitos y Historias de Usuarios que podemos probar fácilmente con un Caso de Prueba.
Veamos esto con un ejemplo.
La Política de la compañía establece que los datos de los usuarios no pueden ser accesibles públicamente. Estamos construyendo un sistema en tiempo real altamente distribuido. Necesitamos encontrar un Estándar industrial apropiado que satisfaga esta Política. Los datos de los usuarios van a viajar fuera de la intranet de la empresa. Los Principios de seguridad CLASP nos dicen que asumamos que la red está comprometida. Decidimos adoptar el estándar TLS para poder proteger nuestros datos en una red comprometida. ¿Pero cómo? Tenemos que encontrar directrices específicas para nuestra pila tecnológica. Digamos que Kafka es nuestro principal mecanismo de comunicación. Resulta que Confluent Cloud es compatible con TLS desde el principio. Por último, podemos crear una Historia de Usuario con el resumen:
Habilitar TLS para la comunicación cliente-roker y broker-broker en Confluent Cloud
¿Qué hemos hecho aquí? Tomamos una política vaga de alto nivel que podría aplicarse a cualquier número de conceptos de seguridad y la redujimos a un estándar específico del sector basado en la aplicación de principios de seguridad a nuestra arquitectura. Eso nos permitió encontrar fácilmente una directriz tecnológica específica adecuada. Por último, pudimos escribir una historia viable.
Ahora invirtámosla.
Consideremos el siguiente requisito:
"Implementar la autorización en la aplicación".
Increíblemente poco útil, pero también increíblemente común. Además, no hace referencia a ninguna política. Pero dado lo que sabemos sobre Principios de seguridad, podemos hacer algunas suposiciones. Suponemos que es una buena idea minimizar la superficie de ataque permitiendo sólo a ciertos usuarios utilizar el sistema. Además, es prudente dar a esos usuarios tan pocos permisos como sea posible. En otras palabras, queremos autenticar a los usuarios y dar a los usuarios autenticados autorizaciones mínimas. Necesitamos encontrar estándares de autenticación y autorización adecuados a nuestra organización y arquitectura. Proponemos SASL para la autenticación y ACL para la autorización. Nuestra pila tecnológica ya tiene soporte para ambos. Ahora satisfacemos el requisito con las historias:
- Configurar SASL/PLAIN para clientes Kafka - Dar a los usuarios permisos de lectura para los Temas A, B, y C en Zookeeper ACLs
Estas historias son fáciles de entender e implementar. Tal vez el director del proyecto se oponga y diga que debemos utilizar el sistema RBAC interno de la empresa. En el contexto del modelo, sabemos que el director del proyecto está proponiendo un estándar diferente. El ingeniero sólo tiene que encontrar y aplicar la directriz de Kafka para satisfacer esa norma. El modelo nos ayudó a tomar un requisito desalentador y descomponerlo de una manera que es mucho más fácil de entender, discutir e implementar.
Inspirado por Brian Glas, Great Expectations: A Secure Software Story, Open Source North 2018.
