Ce guide présente un modèle mental permettant aux développeurs de comprendre le paysage de la sécurité de l'information et de créer des applications plus sûres. Il devrait permettre de décomposer les exigences complexes en matière de sécurité d'une manière qui soit gérable. Toutefois, il convient tout d'abord de définir certains termes.
Politique: Ensemble de directives, de règles et de pratiques qui prescrivent la manière dont une organisation gère, protège et distribue l'information. Exemple : L'entreprise doit se conformer au GDPR.
Principe: Idées partagées par toutes les applications sécurisées et s'appliquant à tout type de système logiciel. Plus elles sont appliquées, plus la sécurité du système est robuste. Exemple : Principe du moindre privilège.
Norme: Techniques spécifiques conçues pour protéger un système logiciel d'une ou plusieurs façons. Exemple. Spécification OAUTH2 pour l'autorisation.
Directive: Outil ou technologie fourni pour aider les programmes à se conformer à certaines normes. Généralement spécifique à une technologie. Exemple : Requêtes paramétrées dans JDBC pour éviter les injections SQL.
Il s'agit de définitions de travail pour ce guide. Ces termes ont des significations différentes et se recoupent dans d'autres contextes, mais ils suffiront à la compréhension de ce modèle.
Le modèle
L'entreprise ou l'organisation dispose d'une politique. L'équipe choisit une de l'industrie qui respecte les bons principes de conception de conception et qui respecte la politique de l'entreprise. Il existe des lignes directrices décrivant la manière dont nous devons mettre en œuvre cette norme dans notre pile technologique spécifique. Nous utilisons le point culminant de ces lignes directrices pour rédiger de bonnes exigences et des histoires d'utilisateurs que nous pouvons tester facilement à l'aide d'un cas de test.
Voyons cela à l'aide d'un exemple.
La politique de l'entreprise stipule que les données des utilisateurs ne peuvent pas être accessibles au public. Nous construisons un système en temps réel hautement distribué. Nous devons trouver une norme industrielle appropriée qui satisfasse cette politique. Les données des utilisateurs vont circuler en dehors de l'intranet de l'entreprise. Les principes de sécurité de CLASP nous indiquent qu'il faut supposer que le réseau est compromis. Nous décidons d'adopter la norme TLS afin de sécuriser nos données sur un réseau compromis. Mais comment ? Nous devons trouver des lignes directrices spécifiques à notre pile technologique. Disons que Kafka est notre principal mécanisme de communication. Il se trouve que Confluent Cloud prend en charge TLS dès le départ. Enfin, nous pouvons créer une histoire d'utilisateur avec le résumé :
Activer TLS pour les communications client-courtier et courtier-courtier dans Confluent Cloud
Qu'avons-nous fait ici ? Nous avons pris une politique vague de haut niveau qui pourrait être appliquée à n'importe quel concept de sécurité et nous l'avons réduite à une norme industrielle spécifique basée sur l'application des principes de sécurité à notre architecture. Cela nous a permis de trouver facilement une ligne directrice appropriée et spécifique à la technologie. Enfin, nous avons pu rédiger une histoire réalisable.
Maintenant, inversons les choses.
Considérons l'exigence suivante : "Implémenter l'autorisation dans l'application" :
"Mettre en œuvre l'autorisation dans l'application".
Cette exigence est incroyablement inutile, mais aussi incroyablement courante. De plus, elle ne fait pas référence à une politique. Mais étant donné ce que nous savons des principes de sécurité, nous pouvons faire quelques suppositions. Nous pensons que c'est une bonne idée de minimiser la surface d'attaque en n'autorisant que certains utilisateurs à utiliser le système. De plus, il est judicieux d'accorder à ces utilisateurs le moins de permissions possible. En d'autres termes, nous voulons authentifier les utilisateurs et donner aux utilisateurs authentifiés des autorisations minimales. Nous devons trouver des normes d'authentification et d'autorisation adaptées à notre organisation et à notre architecture. Nous proposons SASL pour l'authentification et ACL pour l'autorisation. Notre pile technologique prend déjà en charge ces deux types de normes. Nous allons maintenant répondre à cette exigence avec les histoires :
- Configurer SASL/PLAIN pour les clients Kafka - Donner aux utilisateurs des permissions de lecture pour les sujets A, B et C dans les ACL de Zookeeper.
Ces histoires sont faciles à comprendre et à mettre en œuvre. Peut-être que le chef de projet revient à la charge et dit que nous devons utiliser le système RBAC interne de l'entreprise. Dans le contexte du modèle, nous savons que le chef de projet propose une norme différente. L'ingénieur doit simplement trouver et mettre en œuvre la directive Kafka pour satisfaire cette norme. Le modèle nous a aidés à prendre une exigence intimidante et à la décomposer d'une manière qui est beaucoup plus facile à comprendre, à discuter et à mettre en œuvre.
Inspiré par Brian Glas, Great Expectations : A Secure Software Story, Open Source North 2018.
