Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Comprendre la hiérarchie et le cycle de vie des ressources
AWS Security Agent organise les ressources de test de sécurité dans une structure hiérarchique qui détermine ce qui est partagé au sein de votre organisation et ce qui est délimité par application. La compréhension de cette structure vous permet de configurer AWS Security Agent de manière efficace et de savoir où trouver et gérer les différentes ressources.
Ce qui est partagé au sein de votre organisation
Certaines ressources d'AWS Security Agent sont configurées une seule fois au niveau de l'organisation et s'appliquent à toutes vos applications et à tous vos espaces d'agent. Ces ressources au niveau du locataire assurent la cohérence et réduisent les tâches de configuration dupliquées.
| Ressource | Description | Pourquoi c'est partagé |
|---|---|---|
|
Exigences en matière de sécurité |
Normes de sécurité organisationnelles qui définissent ce que l'agent de sécurité AWS valide lors de la conception et de la révision du code |
Vos politiques de sécurité s'appliquent à toutes les applications. Définissez-les une seule fois et AWS Security Agent les applique partout. |
|
GitHub intégrations |
GitHub Organisations enregistrées ou comptes d'utilisateurs autorisés à se connecter à AWS Security Agent |
Enregistrez votre GitHub organisation une seule fois, puis connectez des référentiels spécifiques à n'importe quel espace agent selon vos besoins. |
|
Configurations du centre d'identité IAM |
Paramètres SSO qui contrôlent la manière dont les utilisateurs accèdent à AWS Security Agent |
La gestion centralisée des identités s'applique à tous les agents Spaces de votre organisation. |
Important
Les modifications apportées aux exigences de sécurité concernent toutes les futures révisions de conception et de code dans tous les Agent Spaces. Les avis existants ne sont pas affectés.
Ce qui est défini par agent Space
Chaque espace agent représente une application ou un projet distinct que vous souhaitez sécuriser. Les ressources au niveau de l'espace agent sont limitées à cette application spécifique, ce qui permet aux différentes équipes de travailler indépendamment avec leurs propres configurations et évaluations.
| Ressource | Description | Pourquoi le champ d'application est-il limité par application |
|---|---|---|
|
Configurations des tests de pénétration |
Testez les configurations pour des fonctionnalités, des points de terminaison d'API ou des fonctionnalités spécifiques au sein de votre application |
Chaque application possède des cibles, des méthodes d'authentification et des limites de portée uniques qui lui sont propres. |
|
Revues de design |
Évaluations individuelles de la sécurité architecturale des documents de conception |
Chaque application possède sa propre architecture et ses propres documents de conception qui sont évalués indépendamment. |
|
Modèles de menaces |
Évaluations de modélisation des menaces qui fournissent une vue d'ensemble du système et identifient les menaces à partir du code source, des documents de conception, ou des deux |
Chaque application possède son propre code et son propre design, et les menaces sont modélisées indépendamment. Les modèles de menace sont des configurations réutilisables que vous pouvez réexécuter au fur et à mesure de l'évolution de votre code et de votre conception. |
|
Intégrations |
Fournisseurs de sources et de documentation (GitHub GitLab,, Bitbucket, GitHub Enterprise Server et Confluence) connectés à cet agent Space |
Les différentes applications s'appuient sur des sources et des documentations différentes. En les connectant au niveau de l'espace agent, les limites des applications restent claires. |
|
Paramètres de révision du code |
Configuration des fonctionnalités de révision du code, y compris les sources connectées, les paramètres de numérisation et l'activation des commentaires PR |
Chaque application possède ses propres référentiels et ses besoins en matière de révision de sécurité sont configurés indépendamment. |
|
Paramètres de correction des tests d'intrusion |
Configuration des référentiels connectés pouvant recevoir des demandes de correction automatisées pour les résultats des tests d'intrusion |
Les équipes contrôlent les endroits où AWS Security Agent peut soumettre des modifications de code en fonction du flux de travail de leur application. |
|
Attributions d'utilisateurs |
Utilisateurs ayant accès à cet espace d'agent spécifique |
Les équipes ne voient que les évaluations de sécurité pour les applications dont elles sont responsables, ce qui permet d'organiser et de cibler le travail. |
Astuce
Nous vous recommandons de créer un espace agent par application ou projet afin de maintenir des limites claires entre les équipes et d'organiser efficacement les évaluations de sécurité.
Comment les GitHub référentiels s'insèrent dans la hiérarchie
GitHub les référentiels sont intégrés par le biais d'un processus en plusieurs étapes qui connecte les ressources de l'organisation à des applications spécifiques :
-
Inscrivez-vous au niveau du locataire : autorisez une seule fois GitHub l'application AWS Security Agent pour votre GitHub organisation ou votre compte utilisateur
-
Connexion au niveau de l'espace agent : sélectionnez des référentiels spécifiques pour vous connecter à chaque espace agent
-
Configurer l'utilisation par référentiel - Activez des fonctionnalités spécifiques pour chaque référentiel connecté :
-
Révision du code : analyse complète du code source et analyse automatique des pull requests
-
Contexte des tests d'intrusion - Compréhension de l'application à partir du code source lors des tests d'intrusion
-
Correction automatique du code : requêtes d'extraction automatisées avec correctifs de vulnérabilité pour la révision du code et les résultats des tests d'intrusion
-
Un référentiel unique peut être connecté à plusieurs espaces d'agent avec différentes fonctionnalités activées dans chacun d'eux.
Principales différences entre les capacités de sécurité
Chaque fonctionnalité de sécurité d'AWS Security Agent suit un modèle de flux de travail différent en fonction de la façon dont les équipes de sécurité l'utilisent.
Tests de pénétration : configurations réutilisables avec exécutions indépendantes
Les tests d'intrusion utilisent un modèle de configuration et d'exécution qui prend en charge les tests de sécurité itératifs :
-
Créez une fois, exécutez plusieurs fois : définissez une configuration pour une cible spécifique (point de terminaison d'API, zone de fonctionnalités) avec les limites du champ d'application, l'authentification et les paramètres de test
-
Exécutions indépendantes : exécutez plusieurs fois la même configuration pour améliorer la sécurité. Chaque exécution est indépendante et génère de nouvelles découvertes
Ce modèle prend en charge la validation continue de la sécurité au fur et à mesure que vous développez et déployez des améliorations.
Revues de conception : One-off évaluations avec clonage
Les révisions de conception sont des évaluations indépendantes qui ne suivent pas un modèle de configuration réutilisable :
-
Évaluation unique : chaque revue de conception analyse les documents téléchargés une seule fois par rapport aux exigences de sécurité de votre organisation
-
Impossible de réexécuter : les révisions de conception ne sont pas réutilisables. Vous ne pouvez pas réexécuter le même avis
-
Cloner pour les mises à jour : clonez une révision de conception existante pour créer une nouvelle révision avec les documents originaux préchargés, ce qui vous permet de mettre à jour les documents et d'exécuter une nouvelle analyse
Ce modèle prend en charge les évaluations ponctuelles de la sécurité architecturale.
Révisions du code : configurations réutilisables avec analyses à la demande et analyse automatique des relations publiques
Les révisions de code proposent deux modes de fonctionnement pour sécuriser votre code source :
-
Révisions complètes du code (application Web) : créez des configurations de révision de code qui sélectionnent GitHub des référentiels ou des sources S3, puis exécutez des analyses complètes à la demande. Chaque exécution effectue une analyse statique de l'ensemble de votre code source et génère des résultats accompagnés de conseils de correction. Vous pouvez réexécuter la même configuration de révision de code au fur et à mesure que votre code évolue.
-
Pull request comments (GitHub) - Activez l'analyse automatique pour les GitHub référentiels connectés. AWS Security Agent examine automatiquement les pull requests lorsqu'elles sont marquées comme étant prêtes à être examinées et publie les résultats de sécurité sous forme de commentaires directement dans les commentaires GitHub.
Les deux modes utilisent les paramètres de révision du code que vous avez configurés (vulnérabilités de sécurité, exigences personnalisées, ou les deux) et prennent en charge la correction automatique du code par le biais de pull requests.
Modèles de menace : configurations réutilisables avec exécutions à la demande
Les modèles de menace utilisent un modèle de configuration et d'exécution qui prend en charge l'évaluation itérative de votre architecture :
-
Créez une fois, exécutez plusieurs fois : définissez un modèle de menace en sélectionnant le code source comme source, en téléchargeant des documents de conception sous forme de documents de portée, ou les deux. Exécutez-le à la demande et réexécutez-le au fur et à mesure de l'évolution de votre code et de votre conception.
-
Entrées flexibles : exécutez un modèle de menace uniquement sur le code source, sur les documents de conception uniquement, ou sur les deux. Les documents Scope définissent sur quoi l'agent concentre son analyse ; le code source fournit le contexte de votre système existant.
-
Vue d'ensemble du système et menaces : chaque exécution produit une vue d'ensemble du système décrivant l'architecture, les limites de confiance, les flux de données et le niveau de sécurité de votre application, ainsi qu'un ensemble de menaces classées par catégorie STRIDE avec leur gravité, des preuves et des recommandations exploitables.
Comprendre les relations entre les ressources
La hiérarchie détermine l'endroit où vous configurez et accédez aux différentes ressources :
Dans la console de gestion AWS :
-
Configuration des ressources au niveau du locataire (exigences de sécurité, GitHub intégrations, IAM Identity Center)
-
Création et gestion d'espaces d'agents
-
Configuration des paramètres de l'espace agent (référentiels connectés, activation de la révision du code, correction des tests d'intrusion)
Dans l'application Web Security Agent :
-
Créez et gérez des configurations de tests d'intrusion et des exécutions de tests
-
Création et gestion de révisions de conception
-
Créez, gérez et exécutez des révisions de code par rapport à des référentiels connectés et à des sources S3
-
Créez, gérez et exécutez des modèles de menaces par rapport au code source, aux documents de portée, ou aux deux
-
Consultez les résultats des tests d'intrusion, des révisions de code, des révisions de conception et des modèles de menace
Dans GitHub :
-
Afficher les résultats de l'examen du code de pull request sous forme de commentaires
-
Recevez des pull requests de correction automatisés pour la révision du code et les résultats des tests d'intrusion (lorsque cette option est activée dans l'espace des agents)
Note
Les résultats de la révision du code Pull Request apparaissent dans GitHub. Les résultats complets de l'examen du code, des tests d'intrusion et de la révision de la conception apparaissent dans l'application Web Security Agent.
