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.

Bonnes pratiques de sécurité pour AWS Security Agent

AWS Security Agent fournit un certain nombre de fonctionnalités de sécurité à prendre en compte lors de l'élaboration et de la mise en œuvre de vos propres politiques de sécurité. Les bonnes pratiques suivantes doivent être considérées comme des instructions générales et ne représentent pas une solution de sécurité complète. Étant donné que ces bonnes pratiques peuvent ne pas être appropriées ou suffisantes pour votre environnement, considérez-les comme des remarques utiles plutôt que comme des recommandations.

Utiliser des environnements hors production pour les tests de pénétration

AWS Security Agent utilise une suite complète d'outils de test d'intrusion issus de la distribution Kali Linux. Ces outils sont conçus pour identifier les failles de sécurité et peuvent effectuer des actions qui modifient l'état des applications, les données ou les configurations du système.

Bonne pratique : effectuez des tests de pénétration dans des environnements hors production qui reflètent votre configuration de production. Ces environnements de test doivent :

Les tests dans des environnements de production peuvent entraîner :

Valider les résultats AI-generated de sécurité

AWS Security Agent effectue une analyse de sécurité à l'aide d'agents d'intelligence artificielle. En raison de la nature non déterministe des systèmes d'IA, les tests d'intrusion peuvent produire des résultats différents selon les exécutions.

Bonne pratique : validez les résultats de sécurité avant de prendre des mesures correctives :

Les problèmes identifiés ne représentent peut-être pas tous des vulnérabilités exploitables dans votre contexte de déploiement spécifique.

Vérifiez et testez le code de correction généré

AWS Security Agent peut générer des correctifs de code et des améliorations de sécurité pour les vulnérabilités identifiées. Ces AI-generated correctifs nécessitent une vérification avant le déploiement.

Bonne pratique : passez en revue toutes les modifications de code générées :

Accès au référentiel de code

AWS Security Agent peut fournir des conseils de sécurité sur les modifications de code par le biais de commentaires sur les pull requests et de l'intégration de la révision du code. Pour protéger les informations de sécurité sensibles, cette fonctionnalité fonctionne sous des contraintes spécifiques.

Limitation : les directives de sécurité du code sont limitées aux référentiels privés uniquement. Cela garantit que :

AWS Security Agent ne fournit pas de directives de sécurité du code pour les référentiels publics. Il ne commentera pas les référentiels publics ou les projets open source dans lesquels les résultats de sécurité seraient visibles publiquement.

Les tests de pénétration d'AWS Security Agent permettent d'examiner et de corriger les référentiels privés et publics que vous avez configurés pour le pentest. Si le référentiel est public, le code de correction sera fourni sous forme de fichier diff téléchargeable au lieu d'une pull request.

URL accessibles

Les URL accessibles spécifient des points de terminaison supplémentaires auxquels l'environnement de test d'intrusion peut accéder pendant les tests. Ils sont nécessaires lorsque votre application dépend de services externes tels que des fournisseurs d'authentification tiers ou des CDN. Toutes les dépendances réseau requises pour les tests doivent être spécifiées sous forme d'URL cibles ou d'URL accessibles. Le réseau bloque l'accès à tous les points de terminaison non spécifiés.

Implications en matière de sécurité : l'agent de sécurité AWS n'est pas chargé d'effectuer des tests de sécurité sur les URL accessibles. En spécifiant des URL accessibles, vous attestez de la confiance dans ces dépendances. Les données des tests d'intrusion, y compris les informations d'identification, peuvent être transmises à ces points de terminaison URL accessibles pendant les tests.

Inférence interrégionale

AWS Security Agent sélectionne automatiquement la région optimale pour traiter vos demandes d'inférence. Cela permet d'optimiser les ressources informatiques disponibles, la disponibilité des modèles et d'offrir la meilleure expérience client. Vos données restent stockées uniquement dans la région d'où provient la demande ; toutefois, les demandes de saisie et les résultats de sortie peuvent être traités en dehors de cette région. Nous transmettons toutes les données cryptées sur le réseau AWS.

AWS Security Agent utilise deux types d'inférence entre régions en fonction de la région :

Pour les régions utilisant l'inférence interrégionale globale, les invites de saisie et les résultats de sortie peuvent être traités dans n'importe quelle région AWS commerciale. Toutes les données transmises lors d'opérations interrégionales restent sur le réseau AWS et ne transitent pas par l'Internet public. Nous chiffrons les données en transit entre les régions AWS.

Le tableau suivant décrit l'endroit où vos demandes d'inférence sont traitées en fonction de la région d'origine de la demande et de la fonctionnalité utilisée.

Cross-Region l'inférence est toujours activée et ne peut pas être désactivée. Cross-Region l'inférence n'est pas affectée par les politiques clients contenues dans les politiques de contrôle des services (SCP) ou dans AWS Control Tower qui limitent le contenu client à des régions spécifiques. Pour plus d'informations sur la façon dont AWS Security Agent protège vos données lors du traitement interrégional, consultez la section Traitement Cross-Region des données.