Security/Compliance

• Objets identifiant les utilisateurs (personne ou compte pour l'accès d'une application)
• Un utilisateur peut être associé à 10 groupes maximum

• Objets identifiant plusieurs utilisateurs.
• Sont associés à des policy permissions.
• Par défaut 100 groupes maximum par compte.

• Objets associés à différentes identités pour leur donner des permissions
• 4 types de roles : AWS Service Role, AWS Service-Linked Role, Role for Cross-Account Access, Role for Identity Provider Access

• JSON policies qui définissent quelles ressources peuvent être accédées ou pas.
• Fournis par AWS ou définis par le client.

• Mécanismes qui indiquent comment une ressource peut être accédée

5 bonnes pratiques vérifiés par AWS sur le compte :

• Activation MFA sur le compte root
• créer des utilisateurs individuels
• utiliser des groupes pour assigner les permissions
• appliquer une IAM password policy
• changer les clés d'accès régulièrement

• Peuvent être attachées à plusieurs utilisateurs, groupes ou rôles
• AWS Managed Policies : police préconfigurée proposée par AWS pour les besoins classiques
• Customer Managed Policies : peuvent être créés en modifiant une fournie par AWS, à partir du Policy Genrerator ou manuellement

• Attachée à un seul utilisateur, groupe ou rôle
• Création par le Policy Generator ou manuellement

• Double authentification

• Permet l'accès sans compte AWS avec une identification tierce d'un Identity Provider (IdP)
• Fonctionne avec 2 type IdP : OpenID Connect (Facebook, Amazon, Google, …) et SAML (MS Active Directory)

• Permet l'accès aux services d'un autre compte AWS à l'aides des roles
• Trusted account : compte auquel on fait confiance (celui à qui on donne l'accès)
• Trusting account : compte qui fait confiance (celui qui donne l'accès)
• On prend le role en basculant au niveau du compte “switch role”

Haut de page

• une seule clef est utilisée pour crypter et décrypter les données
• Exemples : AES, DES (Digital Encryption Standard), Triple-DES, Blowfish, …

• on génère une clef publique et une clef privée
• on donne la clef publique pour crypter les données
• les 2 clefs sont nécessaires pour décrypter, nous seront donc les seuls à pouvoir le faire
• Exemples : RSA (Rivest-Shamir-Adleman), Diffie-Hellman, Digital Signature Algorithm

• Utiliser typiquement pour encrypter les DEK qui sont ensuite utilisées par d'autres services AWS
• 2 types : Customer managed CMKs et AWS managed CMKs

• Créés par par les CMKs et utilisées pour encrypter les données
• Envelope encryption : la clef de cryptage est elle-même cryptée

• Définir les accès aux clefs KMS

• Délégation d'accès aux clefs KMS à un service AWS

• Possibilité d'activer une rotation automatique tous les 365 jours (impossible sur une clef importée). Les clefs précédentes sont toujours utilisables sur les données cryptées avant.

• Importation d'une clef publique

• KMS programme l'effacement dans un délai de 7 à 30 jours. La clef est mise dans un état “Pending deletion” où elle ne peut plus servir
• Possibilité d'utiliser CloudTrail pour détecter une utilisation ou bien de programmer une alarme avec CloudWatch
• En cas de doute sur l'absence d'utilisation de la clef il est également possible de la désactiver plutôt que de la supprimer

Haut de page

• HSM : Hardware Security Module, composant physique non partagé

• Permet le stockage de secrets (mot de passe, clefs d'accès, …)
• Cryptage systématique
• Possibilité d'activer une rotation automatique pour mettre à jour automatiquement à partir d'une lambda fonction
• Possibilité de partager avec un autre compte AWS
• Jusqu'à 10 Ko, payement pour chaque secret storage plus le nombre d'appels via l'API chaque mois
• Accès défini par des IAM identity-based policies et IAM resource-based policies

• Permet le stockage de paramètres (qui peuvent être aussi des mots de passe)
• Cryptage optionnel
• Pas de gestion de rotation automatique
• Standard jusqu'à 4Ko (gratuit) ou advanced jusqu'à 8 Ko (payant)

Haut de page

• Root :container en haut de l'organisation, tous les éléments se trouvent sous ce root
• Organizational Units : pour catégoriser les account. Rattaché sous root ou une autre OU (jusqu'à 5 niveaux)
• Accounts : ce sont les comptes AWS dans lesquels on peut gérer les ressources
• Service Control Policies : contrôle quels services et fonctionnalités sont accessibles par un compte. Ces SCPs peuvent être associées au niveau root, OU ou account (elles s'appliquent ensuite à tous les objets enfants)

Haut de page

• Cross-site scripting
• Geo match
• IP addresses
• Size constraints
• SQL injection attacks
• String and regex matching

• Regular Rule : association de conditions (ET logique)
• Rate-based Rule : limite les accès depuis une adresse IP au delà d'un certains nombre de requête par période de 5 mn

Association d'une action à chaque règle

• Allow
• Block
• Count

• Par défaut relevé toutes les minutes et conservés pour 2 semaines
• Les métriques sont : AllowedRequests, BlockedRequests, CountedRequests, PassedRequests (requêtes qui ne correspondent à aucune règle WAF)

• Une fois l'association faite entre une WEB ACL et une distribution CloudFront, cela peut prendre 15mn à se propager à tous les Edge Locations
• Possibilité de customiser l'erreur 403 retourné à l'utilisateur

Permet de gérer WAF dans un environnement de plusieurs compte au travers des Organizations.

• Le compte doit faire partie d'une organization
• Un compte doit être défini comme Firewall Manager Admin
• AWS Config doit être activé

• WAF Rules
• Rules Groups : regroupe des règles qui ont la même action (Block ou Count mais pas Allow). A créer soi-même ou à acheter sur AWS Marketplace
• Firewall Manager Policies : contient les Rules Groups à assigner aux ressources. 2 Rules groups max par Policy (1 customer et 1 Marketplace)

Prévention contre les attaques DDoS (Distributed Denial of Service) qui peuvent être de différents types :

• SYN flood : envoi de SYN et suite au SYN ACK laisse la connexion ouverte
• DNS query flood : attaque du DNS par de multiples requêtes
• HTTP flood/Cache-busting : attaque par requêtes HTTP éventuellement en passant outre du cache pour attaquer le serveur source

• Gratuit
• Contre les attaques DDoS au niveau 3 (réseau) et niveau 4 (transport)
• Intégré dans CloudFront et Route 53

• Protection des applications sur EC2, CloudFront, ELB et Route 53
• Protection plus importante des attaques DDoS niveau 3 (réseau), niveau 4 (transport) et niveau 7 (application)
• Assistance 24/24 d'une équipe spécialisée
• 3 000 $ / mois avec WAF intégré + frais de transfert

Permet un accès à plusieurs account AWS avec un un accès SSO.

Haut de page

Authentication and user management service

• Pour créer et maintenir l'annuaire des utilisateurs
• Gère les inscription et les connexions

• Permet un accès temporaire à des utilisateurs ou bien des invités
• 2 type d'identités : authentifié et non authentifié
• Chaque identité a un rôle et chaque rôle à une policy attachée qui décrit les permissions

Haut de page