Conception de confiance

Tags:
Categories:

Architecture de sécurité et principes de conception

Les trois éléments de sécurité et principes de conception de sécurité

  • Intégrité (Integrity)
  • Disponibilité (Availability)
  • Confidentialité (Confidentiality)

Principe de conception ouverte

Open Design

  • La conception ne devrait pas être secrète, une conception ouverte est plus sûre.
  • La sécurité ne dépend pas du secret.

Principe de sécurité par défaut en cas d’échec

Fail-safe defaults

  • La décision d’accès est basée sur “autoriser”, et non sur “refuser”.
  • Par défaut, l’accès n’est pas autorisé, les mécanismes de protection ne servent qu’à identifier les cas d’accès autorisés.
  • Sécurité en cas de défaillance : tout système complexe devrait avoir un mécanisme de sécurité d’urgence en cas de défaillance fonctionnelle. En outre, il faut être prudent avec les messages d’erreur et les journaux pour éviter les fuites d’informations.
  • Sécurité par défaut : dans son état initial, le système a une configuration par défaut qui est sécurisée, en utilisant le moins de services et de systèmes possibles pour offrir un maximum de sécurité.

Principe de séparation des privilèges

Separation of Privilege

  • Un mécanisme de protection nécessitant deux clés pour être déverrouillé est plus robuste et plus souple qu’un mécanisme n’en nécessitant qu’une.
  • Objectifs de la séparation des privilèges
  • Prévenir les conflits d’intérêts et les abus de pouvoir individuels
  • Décomposer un privilège important en plusieurs privilèges, rendant plus difficile l’accès illégal aux objets à protéger, et donc plus sécurisé.
  • Séparer les responsabilités et les pouvoirs de différents processus

Le système peut configurer par défaut 3 rôles, les permissions des comptes système entre les rôles sont mutuellement indépendantes, séparant les responsabilités et les pouvoirs :

  • Administrateur système : chargé de la gestion quotidienne des utilisateurs et de la configuration du système.
  • Administrateur de sécurité : chargé de l’activation et de la désactivation de l’état des utilisateurs et de la configuration de sécurité.
  • Auditeur de sécurité : chargé de l’audit des opérations des deux premiers rôles, possédant les permissions d’exportation des journaux, garantissant la traçabilité de toutes les opérations des utilisateurs du système.

Principe du moindre privilège

Least Privilege

  • Chaque utilisateur et chaque programme du système devraient utiliser le plus petit ensemble de privilèges nécessaires pour accomplir leur tâche.
  • S’assurer que les applications fonctionnent avec les permissions minimales.
  • Pour les divers programmes exécutés par les utilisateurs du système, tels que les bases de données, les serveurs WEB, etc., il faut faire attention à utiliser le compte avec les permissions les plus faibles pour exécuter ou se connecter, et ne pas utiliser le compte avec les permissions les plus élevées du système.
  • Lors de la création d’un nouveau compte, attribuer par défaut le rôle avec les permissions minimales.

Principe d’économie de mécanisme

Economy of Mechanism

  • Garder la conception du système et le code aussi simples et compacts que possible.
  • Plus la conception logicielle est complexe, plus la probabilité de bugs dans le code est élevée. Si la conception est aussi soignée que possible, la probabilité de problèmes de sécurité est plus faible.
  • Supprimer le code redondant et les modules de fonctionnalités inutiles, conserver ce code ne ferait qu’augmenter la surface d’attaque du système.
  • Concevoir des composants réutilisables pour réduire le code redondant.
  • Économie et praticité : simple, soigné, modularisé.
  • Ne pas sur-concevoir

Principe du moindre mécanisme commun

Least Common Mechanism

  • Éviter autant que possible les scénarios où plusieurs objets partagent la même ressource, et minimiser autant que possible le nombre et l’utilisation des ressources partagées.
  • Les objets partagés présentent un danger potentiel de flux d’informations et d’interactions involontaires, il faut éviter autant que possible les scénarios où plusieurs objets partagent la même ressource.
  • Si un ou plusieurs objets ne sont pas satisfaits du service fourni par le mécanisme partagé, ils peuvent choisir de ne pas utiliser le mécanisme partagé, afin d’éviter d’être indirectement attaqués par les bugs d’autres objets.
  • Minimiser la mémoire partagée
  • Minimiser la liaison des ports
  • Réduire les connexions, se défendre contre les attaques Dos

Principe de médiation complète

Complete Mediation

  • Le principe de médiation complète exige que chaque accès à chaque objet soit soumis à une vérification de sécurité.
  • Chaque fois qu’un sujet tente d’accéder à un objet, le système vérifie à chaque fois si le sujet possède cette permission.
  • Autant que possible, laisser le propriétaire de la ressource prendre la décision de contrôle d’accès, par exemple, si c’est une URL, laisser le serveur backend effectuer la vérification, ne pas effectuer de jugement frontend.
  • Faire particulièrement attention à l’utilisation et à la vérification du cache, on ne peut pas garantir que chaque accès aux informations du cache n’a pas été falsifié par un pirate informatique. Ex. : empoisonnement du cache DNS.

Principe de convivialité psychologique

Psychological Acceptability

  • Les mécanismes de sécurité peuvent ajouter un fardeau supplémentaire aux utilisateurs, mais ce fardeau doit être minimal et raisonnable.
  • Les mécanismes de sécurité devraient être les plus conviviaux possible pour les utilisateurs du système, facilitant leur utilisation et leur compréhension du système.
  • Si la méthode de configuration est trop complexe et fastidieuse, l’administrateur système risque involontairement de configurer une option incorrecte, rendant ainsi le système moins sécurisé.
  • Ce principe est généralement lié à l’interaction homme-machine et à l’interface UCD (User Centered Design).

Principe de défense en profondeur

Defense in Depth La défense en profondeur est un principe de défense global avec des exigences très élevées. En général, il demande aux architectes système d’appliquer de manière globale les divers principes de conception de sécurité, en utilisant des mécanismes de vérification de sécurité multiples et en se concentrant sur les mécanismes de défense de sécurité au niveau de l’architecture système, plutôt que de ne compter que sur un seul mécanisme de sécurité.