Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Lorsque vous concevez des architectures de charge de travail, vous devez utiliser des modèles de secteur qui répondent aux défis courants. Les modèles peuvent vous aider à faire des compromis intentionnels au sein des charges de travail et à optimiser les résultats souhaités. Ils peuvent également aider à atténuer les risques qui proviennent de problèmes spécifiques, ce qui peut affecter la fiabilité, les performances, le coût et les opérations. Ces risques peuvent indiquer l’absence de garanties de sécurité, s’ils sont laissés sans assistance, peuvent présenter des risques importants pour l’entreprise. Ces modèles sont soutenus par l’expérience réelle, sont conçus pour la mise à l’échelle du cloud et les modèles d’exploitation, et sont intrinsèquement indépendants du fournisseur. L’utilisation de modèles connus comme moyen de normaliser la conception de votre charge de travail est un composant de l’excellence opérationnelle.
De nombreux modèles de conception prennent directement en charge un ou plusieurs piliers d’architecture. Les modèles de conception qui prennent en charge le pilier sécurité hiérarchisent les concepts tels que la segmentation et l’isolation, l’autorisation forte, la sécurité uniforme des applications et les protocoles modernes.
Le tableau suivant récapitule les modèles de conception d’architecture qui prennent en charge les objectifs de sécurité.
| Motif | Résumé |
|---|---|
| Ambassadeur | Encapsule et gère les communications réseau en déchargeant les tâches croisées liées à la communication réseau. Les services d’assistance résultants lancent la communication pour le compte du client. Ce point de médiation offre la possibilité d’accroître la sécurité sur les communications réseau. |
| Back-ends pour les serveurs frontaux | Individualise la couche de service d’une charge de travail en créant des services distincts exclusifs à une interface frontale spécifique. En raison de cette séparation, la sécurité et l’autorisation dans la couche de service qui prennent en charge un client peuvent être adaptées aux fonctionnalités fournies par ce client, ce qui peut réduire la surface d’exposition d’une API et un mouvement latéral entre différents back-ends susceptibles d’exposer différentes fonctionnalités. |
| Cloison | Introduit une segmentation intentionnelle et complète entre les composants pour isoler le rayon d’explosion des dysfonctionnements. Vous pouvez également utiliser cette stratégie pour contenir des incidents de sécurité à la cloison compromise. |
| Vérification des revendications | Sépare les données du flux de messagerie, ce qui permet de récupérer séparément les données associées à un message. Ce modèle prend en charge la conservation des données sensibles hors des corps de messages, au lieu de les gérer dans un magasin de données sécurisé. Cette configuration vous permet d’établir une autorisation plus stricte pour prendre en charge l’accès aux données sensibles des services qui sont censés utiliser les données, mais supprimer la visibilité des services auxiliaires comme les solutions de surveillance de file d’attente. |
| Identité fédérée | Délègue l’approbation à un fournisseur d’identité externe à la charge de travail pour la gestion des utilisateurs et la fourniture de l’authentification pour votre application. En externalisant la gestion et l’authentification des utilisateurs, vous pouvez obtenir des fonctionnalités évoluées pour la détection et la prévention basées sur les identités sans avoir à implémenter ces fonctionnalités dans votre charge de travail. Les fournisseurs d’identité externes utilisent des protocoles d’authentification interopérables modernes. |
| Gardien | Décharge le traitement des demandes spécifiquement pour l’application du contrôle d’accès et de sécurité avant et après le transfert de la requête vers un nœud principal. L’ajout d’une passerelle dans le flux de requête vous permet de centraliser les fonctionnalités de sécurité telles que les pare-feu d’applications web, la protection DDoS, la détection de bot, la manipulation des demandes, l’initiation d’authentification et les vérifications d’autorisation. |
| Agrégation de passerelle | Simplifie les interactions client avec votre charge de travail en agrégeant des appels à plusieurs services principaux dans une seule requête. Cette topologie réduit souvent le nombre de points tactiles qu’un client a avec un système, ce qui réduit la surface d’exposition publique et les points d’authentification. Les back-ends agrégés peuvent rester entièrement isolés du réseau des clients. |
| Déchargement de passerelle | Décharge le traitement des demandes sur un appareil de passerelle avant et après le transfert de la requête vers un nœud principal. L’ajout d’une passerelle dans le flux de requête vous permet de centraliser les fonctionnalités de sécurité telles que les pare-feu d’applications web et les connexions TLS avec les clients. Toutes les fonctionnalités déchargées fournies par la plateforme offrent déjà une sécurité renforcée. |
| Éditeur/Abonné | Dissocie les composants d’une architecture en remplaçant la communication directe client-service par communication via un répartiteur de messages intermédiaire ou un bus d’événements. Ce remplacement introduit une limite de segmentation de sécurité importante qui permet aux abonnés de file d’attente d’être isolés du réseau de l’éditeur. |
| Quarantaine | Garantit que les ressources externes répondent à un niveau de qualité convenu par l’équipe avant d’être autorisées à les consommer dans la charge de travail. Cette vérification sert de première validation de sécurité des artefacts externes. La validation sur un artefact est effectuée dans un environnement segmenté avant d’être utilisé dans le cycle de vie de développement sécurisé (SDL). |
| Side-car | Étend les fonctionnalités d’une application encapsulant des tâches non primaires ou croisées dans un processus complémentaire qui existe en même temps que l’application principale. Encapsulant ces tâches et en les déployant hors processus, vous pouvez réduire la surface des processus sensibles uniquement au code nécessaire pour accomplir la tâche. Vous pouvez également utiliser des sidecars pour ajouter des contrôles de sécurité croisés à un composant d’application qui n’est pas conçu en mode natif avec cette fonctionnalité. |
| Limitation | Impose des limites au taux ou au débit des requêtes entrantes à une ressource ou un composant. Vous pouvez concevoir les limites pour empêcher l’épuisement des ressources pouvant résulter d’un abus automatisé du système. |
| Valet Key | Octroie un accès restreint à la sécurité à une ressource sans utiliser de ressource intermédiaire pour proxyer l’accès. Ce modèle permet à un client d’accéder directement à une ressource sans avoir besoin d’informations d’identification durables ou permanentes. Toutes les demandes d’accès commencent par une transaction auditable. L’accès accordé est alors limité à la fois dans l’étendue et la durée. Ce modèle facilite également la révocation de l’accès accordé. |
Étapes suivantes
Passez en revue les modèles de conception d’architecture qui prennent en charge les autres piliers d’Azure Well-Architected Framework :
- Modèles de conception d’architecture qui prennent en charge la fiabilité
- Modèles de conception d’architecture qui prennent en charge l’optimisation des coûts
- Modèles de conception d’architecture qui prennent en charge l’excellence opérationnelle
- Modèles de conception d’architecture qui prennent en charge l’efficacité des performances