AWS Secrets Manager enables you to safely store secrets, such as passwords or access keys. This way, you don't have to store these secrets as plaintext in your applications. With the help of IAM AssumeRole, you can then access the secrets in Secrets Manager without exposing your AWS keys in cleartext.
The post Store secrets in AWS Secrets Manager first appeared on 4sysops.
Je travaille sur des environnements AWS depuis plus de 6 ans maintenant. Que ce soit en tant qu'Ops, architecte, ou architecte sécurité, il y toujours une constante que je constate autour de moi : l'IAM d'AWS est très souvent mal utilisé.
Dans ce billet, je vous propose de faire un petit tour d'horizon des raisons probables.
La documentation est censée être le pilier sur lequel s'appuyer. Toutefois, force est d'admettre que la documentation d'AWS est loin d'être un exemple en ce qui concerne l'IAM.
Bien que la firme prône le least privilege, beaucoup de ses documentations en sont très loin.
De mon point de vue, la documentation est censé montrer des exemples les plus sécurisés possible pour "pousser" les utilisateurs à adopter les bons réflexes. Force est d'admettre que ce n'est pas le cas.
Principal souci du modèle d'AWS, qui fait que chaque équipe produit est autonome : L'inconsistance des API.
Les même actions ne correspondent pas forcément au même verbes API...
Ainsi la simple action de créer un tag peut avoir plusieurs nom différents en fonction des services, comme par exemple :
Connexion
elasticloadbalancing:addTagsec2:createTagsecr:tagResourceMais comme ce serait trop simple, toutes les API n'ont pas forcément les mêmes type de cible.
Ainsi si je veux cibler des ressources en fonction de leurs tags, j'ai encore une fois des filtres différents :
Lorsqu'on met en place un modèle zero trust basé sur le least privilege, on va vouloir cloisonner au mieux les droits que l'on donne pour éviter toute action non désirée.
Maintenant on arrive au vrai problème.
En fonction des ressources, on pourra (ou non) filtrer correctement, mais pas forcément au même niveau.
Certaines ressources ont des ARN prévisibles, dans ce cas il est simple filtrer en amont (avant même que la moindre ressource soit créé).
D'autres fonctionne sur des identifiants internes créés par AWS, comme les security group par exemple.
Dans ce cas, il est parfois possible de filtrer sur la présence de certains tags, mais une fois de plus, pas tout le temps!
En effet, tous les services n'appliquent pas les tags de la même manière. Certains vont l'appliquer dès la création, d'autres après. Parfois tout se fait en un seul appel API, parfois en plusieurs...
J'aime à dire que l'IAM d'AWS est sans doute l'un des plus complet à ce jour. Toutefois, sa complétude vient aussi avec une complexité certaine : Le nombre de policies et les différentes couches qui s'appliquent à chaque évaluation.
Cinq type des policies qui peuvent toutes être utlisées en même temps lorsque vous accédez à un service, cinq!
Je ne peux que comprendre ceux qui se perdent dans ces multiples niveaux d'abstraction.
Comme tous les services d'AWS, l'IAM a ses propres limitations.
Par exemple, un role IAM ne peut pas avoir plus de 10 managed policies d'attachées, et chacune de ces policies ne peut pas dépasser 6144 bytes (sans les espaces/sauts de ligne).
Un role ou un utilisateur ne peut pas avoir plus d'une boundary attachées.
Ces limitations empêchent de pouvoir composer des roles ou utilisateurs de manière optimale car si l'on veut restreindre au maximum, on est obligé de recréer des policy pour chaque ressource!
De plus quand on veut pouvoir donner des accès console + CLI, on est parfois obligé de donner plus de droit que souhaité car sinon on empêche la console de fonctionner correctement.
Mon dernier point et non des moindre : le support lui même s'y perd!
j'ai déjà eu à contacter le support à de multiples reprises pour des soucis d'IAM, et force est d'admettre que très souvent le support tatône pour trouver une policy fonctionnelle ou comprendre d'où peuvent venir les blocages.
Entre l'inconsistance des API, des ressources, des filtres et la complexité de certaines policies lorsqu'on veut filtrer efficacement, c'est parfois compliqué de suivre le fil.
Malgré tout les points que j'ai cité, il est toujours possible de faire "proprement" des policies (du moins du mieux possible), toutefois, ca demande du temps et de l'outillage.
Pour ma part, voici ce que j'utilise très (très) souvent :
Il faut garder en tête que l'IAM d'AWS reste complexe de part sa puissance. Pour ma part, même après des années à en faire quotidiennement, je suis très loin d'en maîtriser 100% de ses aspects...
Dernièrement Facebook a eu un incident majeur et a disparu du net pendant plusieurs heures.
Les réactions que cela a suscitées, dans la sphère technique, m’ont quelque peu surpris, donc nous allons parler dans ce billet des pannes chez les big tech.
Par big tech, j’entends ces boites que l’on pense bien trop grandes pour avoir le moindre incident visible de l’extérieur.
Facebook a rencontré un incident réseau impressionnant et très simple en même temps. Une erreur de manipulation a conduit à la suppression des routes BGP vers Facebook.
Ce sont ces routes qui permettent d’indiquer à Internet comment arriver à Facebook.
L’incident peut sembler anodin, mais repropager des routes BGP peut prendre du temps, surtout pour une infrastructure de la taille de Facebook.
De manière visuelle, voici ce que ça a provoqué :
Visualization of Facebook withdrawing its ASN, made with https://t.co/REvbPepOHK and Yakety Sax. pic.twitter.com/aGVXOPtliu
— Steve Weis (@sweis) October 4, 2021
Point ayant empiré la situation : Facebook ayant perdu son réseau, il était nécessaire d’aller en datacenter pour accéder aux machines, datacenter qui était impossible d’accès vu qu’il nécessitait un accès réseau pour l’authentification.
C’est un point qui a été remonté par Facebook dans leur communiqué de presse :
We’ve done extensive work hardening our systems to prevent unauthorized access, and it was interesting to see how that hardening slowed us down as we tried to recover from an outage caused not by malicious activity, but an error of our own making.
J’en avais parlé sur ce blog à l’époque, AWS a rencontré en fin d’année dernière un incident majeur, suite à l’ajout de stockage sur leur moteur Kinesis, pour les usages internet (IAM notamment), un incident majeur a paralysé une énorme partie d’Internet pendant plusieurs heures.
TFerdinand.netTeddy FERDINANDUne fois de plus, le communiqué de presse de l’entreprise est transparent sur la cause de l’incident :
The new capacity had caused all of the servers in the fleet to exceed the maximum number of threads allowed by an operating system configuration. As this limit was being exceeded, cache construction was failing to complete and front-end servers were ending up with useless shard-maps that left them unable to route requests to back-end clusters
Vu de l’extérieur, l’incident semble assez bête en fait, un problème de dimensionnement des machines qui a conduit à une indisponibilité mondiale.
Quelques semaines après l’incident AWS, Google rencontre aussi un incident majeur : l’authentification de l’ensemble de ses applications ne répond plus.
Que ce soit YouTube, GCP, Google Workspace, plus aucun utilisateur ne parvient à se connecter.
De par l’intégration des services de Google un peu partout, l’impact a été visible par beaucoup de monde.
Une fois de plus, l’entreprise a été transparente sur la cause de cet incident dans son communiqué de presse :
Google uses an evolving suite of automation tools to manage the quota of various resources allocated for services. […] An existing grace period on enforcing quota restrictions delayed the impact, which eventually expired, triggering automated quota systems to decrease the quota allowed for the User ID service and triggering this incident.
En septembre/octobre 2020, Azure AD a rencontré un incident rendant le service d’authentification de Microsoft inaccessible (en grosse partie).
La root cause : une double anomalie, un package en test (slow ring) déployé en production, et un déploiement en parallèle sur l’ensemble des serveurs au lieu de le déployer en rolling update.
Azure AD is designed to be a geo-distributed service deployed in an active-active configuration with multiple partitions across multiple data centers around the world, built with isolation boundaries. Normally, changes initially target a validation ring that contains no customer data, followed by an inner ring that contains Microsoft only users, and lastly our production environment. These changes are deployed in phases across five rings over several days.
In this case, the SDP system failed to correctly target the validation test ring due to a latent defect that impacted the system’s ability to interpret deployment metadata. Consequently, all rings were targeted concurrently. The incorrect deployment caused service availability to degrade.
Dans un premier temps, j’ai constaté que la bienveillance de beaucoup de communautés techniques disparaît lorsque l’on parle des GAFAM. Sans en être un grand fan, je n’oublie pas que ce sont des femmes et des hommes comme mes collègues et moi qui sont derrière. Beaucoup sont passionnés par leur travail et le niveau requis pour rentrer dans ces entreprises est loin d’être anodin.
Pour autant, nombre de messages sur les réseaux sociaux considéraient que c’était "amateur" que d’avoir ce type d’incident.
Pour avoir connu nombre d’incidents majeurs dans ma carrière, parfois, il ne s’agit pas d’incompétence, mais d’un concours de circonstances imprévu et difficilement prévisible !
Point intéressant à retenir, même des colosses comme les GAFAM rencontre des incidents impactant. La différence majeure pour moi reste le facteur d’échelle : chez les GAFAM, l’incident est directement très visible.
Personnellement, je trouve cela rassurant de se dire que même ces boites aussi énormes rencontre des incidents somme toute assez classiques.
Pour chacun de ses incidents, on a pu constater un post mortem clair et transparent sur ces derniers. Permettant ainsi de mieux appréhender la portée de ces anomalies et pourquoi leur résolution à parfois pris du temps.
Mais on voit aussi que les entreprises communiquent de suite sur la manière dont elles vont éviter que cela se reproduise.
Le legacy, cette dette technique éternelle que l’on voit dans toutes les entreprises (ou presque). Il serait idiot de penser qu’il n’y a pas de legacy ou de manque de documentation chez les GAFAM.
Quand bien même ils ont des processus bien huilés (en tout cas en public), comme toutes les boites, ils ont un historique et des composants qui sont anciens et/ou mal documentés.
La différence majeure étant le facteur d’échelle, du legacy chez Microsoft n’a pas le même poids que chez une entreprise de taille plus modeste.
Ce billet a avant tout pour but de mettre un peu en avant ces incidents et la toxicité de certaines communautés Tech autour de ces derniers.
Les GAFAM ne sont pas invincibles et rencontre des incidents d’exploitation comme toutes les entreprises. D’un côté, je dirais même que c’est rassurant de se dire que cela leur arrive aussi !
Et vous, qu’en pensez-vous ?
Quand on parle du Cloud, on parle forcément de SLA !!
Le contrat de niveau de service, traduit en Service Level Agreement (SLA) , est un document important, qui régit les relations entre le fournisseur et le client.
Dans le SLA vous trouverez de nombreux indicateurs, dont les garanties de service exprimées en pourcentage, voici quelques ordres de grandeur :
| Niveau de SLA | Durée de panne maxi par mois |
| 99,99 % | 4 minutes 22 secondes |
| 99,9 % | 43 minutes 49 secondes |
| 99 % | 7 heures 18 mn et 17 s |
| 95 % | 1 jour 12 h 31 mn 27 s |
Le calcul étant le suivant :
(Durée totale – Durée de panne ) / durée totale x 100
Sachant qu’un pois de 30 jours représente 43200 minutes.
Certains contrat prévoient le remboursement de frais en cas de dépassement des garanties (pénalités), mais il est important de surveiller la qualité de service et de signaler le moindre défaut, car en général la panne commence lorsqu’elle est signalée.
Si une solution client dépends de deux services différents, alors les SLA doivent être multipliés :
Exemple :
Service A : 99.95%
Service B : 99.95%
Solution :
99.95% * 99.95% = 99.9%
Le SLA a diminué, ce qui est assez logique : un service en panne entraine la panne de la solution.
Exemple : Une application dépendant de SQL hébergée chez Microsoft Azure :
Bonne lecture de vos contrats !!!
Laurent Gébeau
Pour me suivre :
Sources :
Définition d’un SLA – Wikipedia : https://fr.wikipedia.org/wiki/Service-level_agreement
SLA Microsoft Azure : https://azure.microsoft.com/fr-fr/support/legal/sla/summary/
SLA Google une pâge par service : https://cloud.google.com/terms/sla
SLA Amazon : il semble qu’il y ait une page par Service https://aws.amazon.com/fr/search/?searchQuery=SLA+service+level+agreement
Calculatrice de SLA : https://uptime.is/
The post Qu’est qu’un Service Level Agreement (SLA) ? first appeared on Le Cloud pour Tous.
