Bonnes pratiques de sécurité

La gestion correcte de l'authentification, des contrôles d'accès et de la sécurité est essentielle pour une utilisation sécurisée du fournisseur Terraform AWS . Cette section décrit les meilleures pratiques en matière de :

• Rôles et autorisations IAM pour l'accès avec le moindre privilège

• Sécurisation des informations d'identification pour empêcher tout accès non autorisé aux AWS comptes et aux ressources

• Chiffrement à distance pour protéger les données sensibles

• Analyse de l'infrastructure et du code source pour identifier les erreurs de configuration

• Contrôles d'accès pour le stockage à distance

• Application de la politique Sentinel pour mettre en place des garde-fous en matière de gouvernance

Le respect de ces meilleures pratiques permet de renforcer votre posture de sécurité lorsque vous utilisez Terraform pour gérer AWS l'infrastructure.

Respectez le principe du moindre privilège

Le moindre privilège est un principe de sécurité fondamental qui consiste à n'accorder que les autorisations minimales requises pour qu'un utilisateur, un processus ou un système exécute les fonctions prévues. Il s'agit d'un concept fondamental du contrôle d'accès et d'une mesure préventive contre les accès non autorisés et les violations de données potentielles.

Le principe du moindre privilège est souligné à plusieurs reprises dans cette section car il est directement lié à la manière dont Terraform authentifie et exécute des actions contre des fournisseurs de cloud tels que. AWS

Lorsque vous utilisez Terraform pour provisionner et gérer AWS des ressources, il agit pour le compte d'une entité (utilisateur ou rôle) qui a besoin des autorisations appropriées pour effectuer des appels d'API. Ne pas respecter le moindre privilège présente des risques de sécurité majeurs :

• Si Terraform dispose d'autorisations excessives au-delà de ce qui est nécessaire, une mauvaise configuration involontaire peut entraîner des modifications ou des suppressions indésirables.

• Les autorisations d'accès trop permissives augmentent l'impact si les fichiers d'état ou les informations d'identification de Terraform sont compromis.

• Le fait de ne pas respecter le moindre privilège va à l'encontre des meilleures pratiques de sécurité et des exigences de conformité réglementaires relatives à l'octroi d'un accès minimal requis.

Utilisation des rôles IAM

Utilisez des rôles IAM plutôt que des utilisateurs IAM dans la mesure du possible pour améliorer la sécurité avec le fournisseur AWS Terraform. Les rôles IAM fournissent des informations d'identification de sécurité temporaires qui changent automatiquement, ce qui élimine le besoin de gérer des clés d'accès à long terme. Les rôles offrent également des contrôles d'accès précis par le biais de politiques IAM.

Accordez l'accès avec le moindre privilège en utilisant les politiques IAM

Élaborez soigneusement des politiques IAM pour garantir que les rôles et les utilisateurs ne disposent que du minimum d'autorisations requis pour leur charge de travail. Commencez par une politique vide et ajoutez de manière itérative les services et actions autorisés. Pour ce faire, procédez comme suit :

• Activez IAM Access Analyzer pour évaluer les politiques et mettre en évidence les autorisations non utilisées qui peuvent être supprimées.

• Passez en revue manuellement les politiques afin de supprimer toutes les fonctionnalités qui ne sont pas essentielles au regard de la responsabilité prévue du rôle.

• Utilisez les variables de politique IAM et les balises pour simplifier la gestion des autorisations.

Des politiques bien conçues accordent un accès juste suffisant pour accomplir les responsabilités liées à la charge de travail, rien de plus. Définissez des actions au niveau de l'opération et autorisez les appels uniquement aux API requises sur des ressources spécifiques.

Le respect de cette bonne pratique réduit l'ampleur de l'impact et respecte les principes de sécurité fondamentaux que sont la séparation des tâches et le moindre privilège d'accès. Commencez l'accès strict et ouvert progressivement selon les besoins, au lieu de commencer par ouvrir et d'essayer de restreindre l'accès ultérieurement.

Assumer des rôles IAM pour l'authentification locale

Lorsque vous exécutez Terraform localement, évitez de configurer des clés d'accès statiques. Utilisez plutôt les rôles IAM pour accorder temporairement un accès privilégié sans exposer les informations d'identification à long terme.

Tout d'abord, créez un rôle IAM avec les autorisations minimales nécessaires et ajoutez une relation de confiance qui permet à votre compte utilisateur ou à votre identité fédérée d'assumer le rôle IAM. Cela autorise l'utilisation temporaire du rôle.

Exemple de politique de relation de confiance :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/terraform-execution"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Exécutez ensuite la AWS CLI commande aws sts assume-role pour récupérer les informations d'identification de courte durée pour le rôle. Ces informations d'identification sont généralement valides pendant une heure.

AWS CLI exemple de commande :

aws sts assume-role --role-arn arn:aws:iam::111122223333:role/terraform-execution --role-session-name terraform-session-example

La sortie de la commande contient une clé d'accès, une clé secrète et un jeton de session que vous pouvez utiliser pour vous authentifier auprès de AWS :

{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA3XFRBF535PLBIFPI4:terraform-session-example",
        "Arn": "arn:aws:sts::111122223333:assumed-role/terraform-execution/terraform-session-example"
    },
    "Credentials": {
        "SecretAccessKey": " wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "SessionToken": " AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/LTo6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3zrkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtpZ3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE",
        "Expiration": "2024-03-15T00:05:07Z",
        "AccessKeyId": "ASIAIOSFODNN7EXAMPLE"
    }
}

Le AWS fournisseur peut également gérer automatiquement l'acceptation du rôle.

Exemple de configuration du fournisseur pour assumer un rôle IAM :

provider "aws" {
  assume_role {
    role_arn     = "arn:aws:iam::111122223333:role/terraform-execution"
    session_name = "terraform-session-example"
  }
}

Cela accorde des privilèges élevés strictement pendant la durée de la session Terraform. Les clés temporaires ne peuvent pas être divulguées car elles expirent automatiquement après la durée maximale de la session.

Les principaux avantages de cette bonne pratique incluent une sécurité améliorée par rapport aux clés d'accès à longue durée de vie, des contrôles d'accès précis sur le rôle pour le moins de privilèges et la possibilité de révoquer facilement l'accès en modifiant les autorisations du rôle. En utilisant les rôles IAM, vous évitez également d'avoir à stocker directement les secrets localement dans des scripts ou sur le disque, ce qui vous permet de partager la configuration Terraform en toute sécurité au sein d'une équipe.

Utiliser les rôles IAM pour l'authentification Amazon EC2

Lorsque vous exécutez Terraform à partir d'instances Amazon Elastic Compute Cloud (Amazon EC2), évitez de stocker des informations d'identification à long terme localement. Utilisez plutôt les rôles IAM et les profils d'instance pour accorder automatiquement les autorisations du moindre privilège.

Créez d'abord un rôle IAM avec les autorisations minimales et attribuez-le au profil d'instance. Le profil d'instance permet aux instances EC2 d'hériter des autorisations définies dans le rôle. Lancez ensuite les instances en spécifiant ce profil d'instance. L'instance s'authentifiera via le rôle attaché.

Avant d'exécuter des opérations Terraform, vérifiez que le rôle est présent dans les métadonnées de l'instance pour confirmer que les informations d'identification ont été héritées avec succès.

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

curl -H "X-aws-ec2-metadata-token: $TOKEN" -s http://169.254.169.254/latest/meta-data/iam/security-credentials/

Cette approche évite de coder en dur des AWS clés permanentes dans des scripts ou dans la configuration Terraform au sein de l'instance. Les informations d'identification temporaires sont mises à la disposition de Terraform de manière transparente via le rôle et le profil de l'instance.

Les principaux avantages de cette bonne pratique incluent l'amélioration de la sécurité par rapport aux informations d'identification à long terme, la réduction des frais de gestion des informations d'identification et la cohérence entre les environnements de développement, de test et de production. L'authentification des rôles IAM simplifie les exécutions de Terraform à partir d'instances EC2 tout en appliquant l'accès au moindre privilège.

Utiliser des informations d'identification dynamiques pour les espaces de travail HCP Terraform

HCP Terraform est un service géré fourni par HashiCorp qui aide les équipes à utiliser Terraform pour fournir et gérer l'infrastructure de plusieurs projets et environnements. Lorsque vous exécutez Terraform dans HCP Terraform, utilisez des informations d'identification dynamiques pour simplifier et sécuriser l'authentification. AWS Terraform échange automatiquement des informations d'identification temporaires à chaque exécution sans avoir à assumer le rôle IAM.

Les avantages incluent une rotation plus facile des secrets, une gestion centralisée des informations d'identification dans les espaces de travail, des autorisations de moindre privilège et l'élimination des clés codées en dur. L'utilisation de clés éphémères hachées améliore la sécurité par rapport aux clés d'accès à longue durée de vie.

Utiliser les rôles IAM dans AWS CodeBuild

Dans AWS CodeBuild, exécutez vos builds à l'aide d'un rôle IAM attribué au CodeBuild projet. Cela permet à chaque build d'hériter automatiquement des informations d'identification temporaires du rôle au lieu d'utiliser des clés à long terme.

Exécutez GitHub des actions à distance sur HCP Terraform

Configurez GitHub les flux de travail Actions pour exécuter Terraform à distance sur les espaces de travail HCP Terraform. Misez sur des informations d'identification dynamiques et sur le verrouillage d'état à distance plutôt que sur la gestion des GitHub secrets.

Utiliser GitHub les actions avec OIDC et configurer l'action AWS Credentials

Utilisez la norme OpenID Connect (OIDC) pour fédérer l'identité GitHub Actions via IAM. Utilisez l'action Configurer les AWS informations d'identification pour échanger le GitHub jeton contre des AWS informations d'identification temporaires sans avoir besoin de clés d'accès à long terme.

À utiliser GitLab avec OIDC et le AWS CLI

Utilisez la norme OIDC pour fédérer les GitLab identités via IAM pour un accès temporaire. En vous appuyant sur OIDC, vous évitez d'avoir à gérer directement les clés d' AWS accès à long terme qu'il contient. GitLab Les informations d'identification sont échangées just-in-time, ce qui améliore la sécurité. Les utilisateurs obtiennent également le moindre privilège d'accès en fonction des autorisations associées au rôle IAM.

Utilisez des utilisateurs IAM uniques grâce aux outils d'automatisation existants

Si vous disposez d'outils et de scripts d'automatisation qui ne prennent pas en charge nativement l'utilisation des rôles IAM, vous pouvez créer des utilisateurs IAM individuels pour accorder un accès programmatique. Le principe du moindre privilège s'applique toujours. Minimisez les autorisations liées aux politiques et utilisez des rôles distincts pour chaque pipeline ou script. Au fur et à mesure que vous migrez vers des outils ou des outils plus modernes, commencez à prendre en charge les rôles de manière native et passez progressivement à eux.

Avertissement

Les utilisateurs IAM disposent d'informations d'identification à long terme, ce qui présente un risque de sécurité. Pour atténuer ce risque, nous vous recommandons de n'octroyer à ces utilisateurs que les autorisations dont ils ont besoin pour effectuer la tâche et de supprimer ces utilisateurs lorsqu'ils ne sont plus nécessaires.

Utilisez le plugin Jenkins AWS Credentials

Utilisez le plugin AWS Credentials de Jenkins pour configurer et injecter des AWS informations d'identification de manière centralisée dans les builds de manière dynamique. Cela évite de vérifier les secrets dans le contrôle de source.

Surveillez, validez et optimisez en permanence le moindre privilège

Au fil du temps, des autorisations supplémentaires peuvent être accordées, qui peuvent dépasser les politiques minimales requises. Analysez en permanence les accès pour identifier et supprimer les droits inutiles.

Surveillez en permanence l'utilisation des clés d'accès

Si vous ne pouvez pas éviter d'utiliser des clés d'accès, utilisez les rapports d'identification IAM pour trouver les clés d'accès non utilisées datant de plus de 90 jours, et révoquez les clés inactives à la fois sur les comptes utilisateurs et sur les rôles de machine. Demandez aux administrateurs de confirmer manuellement la suppression des clés pour les employés actifs et les systèmes.

La surveillance de l'utilisation des clés vous permet d'optimiser les autorisations, car vous pouvez identifier et supprimer les autorisations non utilisées. Lorsque vous suivez cette bonne pratique en matière de rotation des clés d'accès, cela limite la durée de vie des informations d'identification et impose l'accès avec le moindre privilège.

AWS fournit plusieurs services et fonctionnalités que vous pouvez utiliser pour configurer des alertes et des notifications pour les administrateurs. Voici quelques options :

• AWS Config: vous pouvez utiliser des AWS Config règles pour évaluer les paramètres de configuration de vos AWS ressources, notamment les clés d'accès IAM. Vous pouvez créer des règles personnalisées pour vérifier des conditions spécifiques, telles que des clés d'accès non utilisées datant de plus d'un certain nombre de jours. En cas de violation d'une règle, AWS Config vous pouvez lancer une évaluation à des fins de correction ou envoyer des notifications à une rubrique Amazon Simple Notification Service (Amazon SNS).

• AWS Security Hub: Security Hub fournit une vue complète du niveau de sécurité de votre AWS compte et peut vous aider à détecter et à vous signaler les problèmes de sécurité potentiels, notamment les clés d'accès IAM inutilisées ou inactives. Security Hub peut s'intégrer à Amazon EventBridge et Amazon SNS ou envoyer des notifications AWS Chatbot aux administrateurs.

• AWS Lambda: Les fonctions Lambda peuvent être appelées par divers événements, notamment Amazon CloudWatch Events ou AWS Config des règles. Vous pouvez écrire des fonctions Lambda personnalisées pour évaluer l'utilisation des clés d'accès IAM, effectuer des vérifications supplémentaires et envoyer des notifications à l'aide de services tels qu'Amazon SNS ou. AWS Chatbot

Validez en permanence les politiques IAM

Utilisez IAM Access Analyzer pour évaluer les politiques associées aux rôles et identifier les services non utilisés ou les actions excédentaires accordées. Mettez en œuvre des examens d'accès périodiques pour vérifier manuellement que les politiques correspondent aux exigences actuelles.

Comparez la politique existante avec la politique générée par IAM Access Analyzer et supprimez toutes les autorisations inutiles. Vous devez également fournir des rapports aux utilisateurs et révoquer automatiquement les autorisations non utilisées après un délai de grâce. Cela permet de garantir que les politiques minimales restent en vigueur.

La révocation proactive et fréquente des accès obsolètes minimise les informations d'identification susceptibles d'être menacées en cas de violation. L'automatisation assure une hygiène des accréditations et une optimisation des autorisations durables et à long terme. Le respect de cette bonne pratique limite la portée de l'impact en appliquant de manière proactive le moindre privilège aux AWS identités et aux ressources.

Stockage d'état à distance sécurisé

Le stockage d'état à distance fait référence au stockage du fichier d'état Terraform à distance plutôt que localement sur la machine sur laquelle Terraform s'exécute. Le fichier d'état est crucial car il permet de suivre les ressources fournies par Terraform et leurs métadonnées.

L'incapacité à sécuriser l'état distant peut entraîner de graves problèmes tels que la perte de données d'état, l'incapacité de gérer l'infrastructure, la suppression involontaire de ressources et la divulgation d'informations sensibles susceptibles de se trouver dans le fichier d'état. Pour cette raison, la sécurisation du stockage à distance est cruciale pour une utilisation de Terraform en production.

Activez le chiffrement et les contrôles d'accès

Utilisez le chiffrement côté serveur (SSE) Amazon Simple Storage Service (Amazon S3) pour chiffrer l'état distant au repos.

Limitez l'accès direct aux flux de travail collaboratifs

• Structurez les flux de travail de collaboration dans HCP Terraform ou dans un pipeline CI/CD au sein de votre référentiel Git afin de limiter l'accès direct à l'état.

• Appuyez-vous sur les pull requests, exécutez les approbations, les vérifications des politiques et les notifications pour coordonner les changements.

Le respect de ces directives permet de sécuriser les attributs sensibles des ressources et d'éviter les conflits avec les modifications apportées par les membres de l'équipe. Le chiffrement et les protections d'accès strictes aident à réduire la surface d'attaque, et les flux de travail collaboratifs favorisent la productivité.

Utiliser AWS Secrets Manager

Terraform possède de nombreuses ressources et sources de données qui stockent des valeurs secrètes en texte clair dans le fichier d'état. Évitez de stocker des secrets dans l'état, utilisez-les plutôt AWS Secrets Manager.

Au lieu d'essayer de chiffrer manuellement des valeurs sensibles, comptez sur le support intégré de Terraform pour la gestion des états sensibles. Lorsque vous exportez des valeurs sensibles vers la sortie, assurez-vous qu'elles sont marquées comme sensibles.

Analysez en continu l'infrastructure et le code source

Analysez de manière proactive l'infrastructure et le code source en permanence pour détecter les risques tels que des informations d'identification exposées ou des erreurs de configuration afin de renforcer votre posture de sécurité. Répondez rapidement aux résultats en reconfigurant ou en appliquant des correctifs aux ressources.

Utiliser AWS les services pour le scan dynamique

Utilisez des outils AWS natifs tels qu'Amazon Inspector AWS Security Hub, Amazon Detective et Amazon GuardDuty pour surveiller l'infrastructure provisionnée sur l'ensemble des comptes et des régions. Planifiez des scans récurrents dans Security Hub pour suivre le déploiement et l'évolution de la configuration. Scannez les instances EC2, les fonctions Lambda, les conteneurs, les compartiments S3 et d'autres ressources.

Réaliser une analyse statique

Intégrez des analyseurs statiques tels que Checkov directement dans les pipelines CI/CD pour scanner le code de configuration Terraform (HCL) et identifier les risques de manière préventive avant le déploiement. Cela permet de déplacer les contrôles de sécurité à un stade antérieur du processus de développement (c'est ce que l'on appelle le déplacement vers la gauche) et d'éviter toute mauvaise configuration de l'infrastructure.

Garantir une correction rapide

Pour tous les résultats de l'analyse, veillez à une correction rapide en mettant à jour la configuration de Terraform, en appliquant des correctifs ou en reconfigurant les ressources manuellement, le cas échéant. Réduisez les niveaux de risque en vous attaquant aux causes profondes.

L'utilisation à la fois de l'analyse de l'infrastructure et de l'analyse du code fournit des informations en couches sur les configurations Terraform, les ressources allouées et le code des applications. Cela maximise la couverture des risques et la conformité grâce à des contrôles préventifs, détectifs et réactifs, tout en intégrant la sécurité plus tôt dans le cycle de vie du développement logiciel (SDLC).

Appliquer les contrôles des politiques

Utilisez des cadres de code tels que les politiques HashiCorp Sentinel pour fournir des garanties de gouvernance et des modèles standardisés pour le provisionnement de l'infrastructure avec Terraform.

Les politiques Sentinel peuvent définir des exigences ou des restrictions relatives à la configuration de Terraform afin de s'aligner sur les normes organisationnelles et les meilleures pratiques. Par exemple, vous pouvez utiliser les politiques Sentinel pour :

• Exiger l'apposition de balises sur toutes les ressources.

• Limitez les types d'instances à une liste approuvée.

• Appliquez les variables obligatoires.

• Empêcher la destruction des ressources de production.

L'intégration de contrôles de politique dans les cycles de vie des configurations de Terraform permet une application proactive des normes et des directives d'architecture. Sentinel fournit une logique de politique partagée qui permet d'accélérer le développement tout en empêchant les pratiques non approuvées.