Comment construire une architecture cloud AWS sécurisée et fiable sans perdre la tête ?

Intro

Si vous avez déjà essayé de concevoir une architecture en nuage dans AWS à partir de zéro, vous le savez probablement déjà : c'est un mélange de liberté et de chaos. Il y a mille façons de construire quelque chose, et autant de façons de tout gâcher.

Un bref coup d'œil à la documentation AWS peut vous amener à penser : "Cool, nous nous contenterons d'observer les pratiques de premier ordre". Mais dans les environnements internationaux réels, les pratiques de premier ordre ne sont pas souvent en prise directe avec les besoins réels de l'entreprise commerciale, les limites de la fourchette de prix ou l'erreur humaine. C'est pourquoi faire appel à des professionnels comme perfsys dès le départ peut éviter de jouer au whack-a-mole avec des failles de protection et des complications de mise à l'échelle par la suite.

L'objectif n'est pas seulement d'obtenir quelque chose qui fonctionne. Il s'agit de construire un système qui ne s'effondre pas lorsque le trafic augmente ou qu'une région s'éteint - et qui ne laisse pas la porte d'entrée grande ouverte à l'Internet.

Commençons par l'évidence : AWS est un monstre

Il est possible de construire pratiquement n'importe quoi avec AWS. Des startups de deux personnes aux plateformes d'entreprise tentaculaires, les blocs de construction sont tous là - EC2, Lambda, RDS, S3, IAM, VPC, la liste est longue. Le problème ? Plus vous avez d'options, plus il est facile de créer un désordre emmêlé.

Ce n'est pas qu'AWS soit mal conçu. C'est simplement qu'il faut le concevoir correctement. Sinon, on se retrouve avec ce que certaines équipes appellent des "spaghettis dans le nuage" : des services interdépendants, des secrets codés en dur, pas de marquage, pas de journalisation et absolument aucune idée de ce qui coûte combien.

La fiabilité et la sécurité ne sont pas des atouts en soi

Il est tentant de considérer la sécurité et la fiabilité comme des problèmes futurs. "Nous sécuriserons le système après l'avoir mis en service. "Nous ajouterons un système de surveillance lors du prochain sprint. Mais demandez à quiconque a été confronté à une violation de données ou à une panne de plusieurs heures - c'est en sautant ces étapes que vous finirez par passer des nuits blanches.

Ce que signifie réellement la fiabilité

Il ne s'agit pas de garanties de temps de fonctionnement sur un diaporama. Il s'agit de prévoir les défaillances. Les services tombent en panne. Les disques tombent en panne. Les API ne fonctionnent plus. Ce qui compte, c'est de savoir si votre système continue à fonctionner lorsque les choses se cassent.

Disposez-vous d'une redondance entre les zones de disponibilité ? Votre système peut-il tolérer la défaillance d'un nœud de base de données sans perdre de données ou générer d'erreurs ? Exécutez-vous des charges de travail critiques dans une seule région parce que "c'est ce qui était le plus facile à déployer" ? Telles sont les questions qui distinguent les systèmes fonctionnels des systèmes résilients.

Et la sécurité ? Il n'y a pas que l'IAM

Oui, la gestion des identités et des accès (IAM) est le premier mur. Mais la sécurité va bien au-delà. Les buckets S3 accessibles au public. Des rôles sur-autorisés. Secrets codés en dur dans les fonctions Lambda. La journalisation désactivée "pour réduire les coûts". Tous ces éléments sont des bombes à retardement.

L'utilisation du cadre aws well architected peut aider à identifier ces problèmes avant qu'ils n'explosent. Il divise l'architecture en cinq domaines clés - sécurité, fiabilité, excellence opérationnelle, efficacité des performances et optimisation des coûts - et oblige les équipes à évaluer chacun d'entre eux, honnêtement. Il ne s'agit pas d'une solution miracle, mais elle vous pousse à poser des questions difficiles.

Les éléments constitutifs qui comptent vraiment

Très bien, entrons dans le vif du sujet. Voici ce qui compte lorsque vous construisez une architecture sécurisée et fiable sur AWS, et ce en quoi les équipes se trompent le plus souvent.

Utiliser les rôles IAM de la bonne manière (oui, vraiment)

Les rôles IAM sont puissants. Trop puissants, parfois. Il est beaucoup trop facile d'utiliser "AdministratorAccess" parce que quelque chose ne fonctionne pas, de promettre d'y remédier plus tard... et de ne jamais le faire.

Il faut verrouiller cela très tôt. Le principe du moindre privilège n'est pas seulement une bonne pratique - c'est la seule façon saine d'opérer. En d'autres termes :

• Rôles délimités par service

• Éviter les caractères génériques dans les autorisations

• Des informations d'identification de courte durée

• MFA obligatoire pour les utilisateurs humains

Ça vous semble pénible ? C'est vrai. Mais expliquer à votre patron pourquoi quelqu'un a exfiltré des données clients à partir d'un Lambda mal configuré l'est tout autant.

Séparez votre réseau comme vous le voulez

C'est un autre domaine où les raccourcis se retournent contre vous. Vous n'avez pas besoin d'une configuration réseau super complexe, mais quelques principes de base suffisent amplement :

• Sous-réseaux publics uniquement pour les éléments qui doivent faire face à l'internet (par exemple, les ALB)

• Sous-réseaux privés pour tout le reste

• Passerelles NAT pour un accès sortant contrôlé

• Points d'extrémité VPC pour le trafic des services AWS sans passer par l'internet public

Un VPC plat avec tout sur le même sous-réseau peut sembler facile. Jusqu'à ce que quelque chose se brise et emporte tout avec lui.

Journalisation et surveillance : Vous ne pouvez pas réparer ce que vous ne pouvez pas voir

Ce point ne devrait même plus faire l'objet d'un débat. La journalisation n'est pas facultative. Si vous ne capturez pas CloudTrail, les métriques CloudWatch et les journaux de flux VPC, vous volez à l'aveuglette.

Mais le hic, c'est que la journalisation seule ne suffit pas. Vous devez réellement consulter les journaux. Créez des alertes pour les éléments importants. Filtrer le bruit. Et s'assurer que les journaux sont centralisés à travers les comptes et les régions. Une visibilité fragmentée n'est pas une visibilité.

Tout crypter (sans exception)

Utilisez KMS pour les données au repos. Utilisez TLS pour les données en transit. Assurez la rotation des clés. Surveillez l'accès. C'est l'un des domaines où la paresse actuelle peut coûter très cher plus tard.

N'oubliez pas non plus les éléments tels que le chiffrement RDS, les paramètres de volume EBS et l'application de la norme TLS de la passerelle API. Ces petits détails s'accumulent.

L'infrastructure en tant que code ou l'échec

Vous déployez toujours en cliquant sur la console AWS ? C'est bien pour le développement, mais c'est dangereux pour la production.

Utilisez Terraform, CloudFormation ou CDK. Quelle que soit la préférence de votre équipe, choisissez-en une et tenez-vous en à elle. Contrôlez la version de vos modèles. Utilisez CI/CD pour le déploiement. Automatisez les retours en arrière. Les déploiements manuels sont une invitation à commettre des erreurs.

Par ailleurs, il convient de tout étiqueter. Les ressources sans étiquettes sont comme des câbles sans étiquettes - personne ne sait à quoi elles servent et tout le monde a peur de les toucher.

Évoluer sans sombrer

Soyons clairs : AWS adore les surprovisionnements. Vous obtenez des "performances", ils obtiennent votre argent. La mise à l'échelle efficace consiste à connaître vos modèles et à les planifier.

Utilisez des groupes de mise à l'échelle automatique, des instances ponctuelles (avec précaution) et des couches de mise en cache. Mais surtout : testez sous charge. La dernière chose que vous souhaitez, c'est de découvrir que votre instance RDS fond sous l'effet du trafic réel deux jours après son lancement.

Réservez également de la capacité lorsque cela s'avère judicieux. Cela permet d'économiser de l'argent et d'éviter les échecs surprises du provisionnement.

Les plans de reprise après sinistre ne sont pas facultatifs

Que se passe-t-il si une région tombe en panne ? Que se passe-t-il si votre base de données principale est corrompue ? Si la réponse est "euh... nous serions dans le pétrin", il est temps de revoir votre stratégie de reprise après sinistre.

Il ne s'agit pas de construire une copie identique de votre infrastructure dans une autre région. Il s'agit de savoir :

• Ce que vous restaureriez

• Combien de temps cela prendrait-il ?

• Quelles données seraient perdues (le cas échéant) ?

• Qui est responsable de quoi pendant un basculement ?

Et oui, vous devez tester votre plan de reprise d'activité. Sinon, ce n'est que de la fiction.

Anti-modèles courants à éviter

Passons rapidement en revue quelques pratiques à éviter qui reviennent trop souvent :

• Un seul compte pour tout : utilisez AWS Organizations. Séparer prod, dev, staging, etc.

• Laisser les VPC par défaut et les groupes de sécurité intacts : les verrouiller.

• S'appuyer excessivement sur les instances t2.micro "pour les tests" - elles finiront par se retrouver dans la production.

• Ne pas budgétiser les coûts de CloudWatch : oui, la journalisation coûte de l'argent. Ne pas journaliser coûte plus cher.

• Donner l'accès à "juste réparer rapidement" : réparer votre processus à la place.

Le mot de la fin ? Rester flexible, rester sain d'esprit

L'architecture en nuage ne consiste pas à trouver la configuration parfaite. Il s'agit de construire quelque chose de flexible, de robuste et de compréhensible par d'autres que la personne qui l'a écrit.

Vous n'avez jamais vraiment terminé, et c'est très bien ainsi. Ce qui compte, c'est d'être intentionnel. Poser des questions difficiles dès le début. Effectuer des audits fréquents. Automatiser là où cela compte. Et savoir quand faire appel à de l'aide.

Car soyons honnêtes : AWS est puissant, mais il est aussi facile de s'y perdre. Travailler avec des ingénieurs chevronnés qui vivent et respirent l'architecture en nuage peut faire la différence entre "ça marche, en général" et "nous dormons la nuit".

Et cela vaut la peine de construire pour cela.