Plateforme /Mauvaises configurations
MAUVAISES CONFIGURATIONS

Regardez au-delà
d’un port ouvert.

Secrets exposés, élévation de privilèges, sauvegardes de bases publiques : examinez les choix de configuration qui exposent vos ressources AWS, avec les éléments collectés et le contexte réunis dans Byrsa.

Mauvaises configurations / Dans Byrsa
byrsa / Plateforme de sécurité Rechercher dans votre espaceD
TOUS LES COMPTES CONNECTÉS

Mauvaises configurations

Espace de démonstration
ÉlevéeÉchec

Secret potentiel dans la configuration Lambda

Contrôle de configuration · AWS Lambda

Éléments du contrôle

Un identifiant potentiel a été détecté dans la configuration de la fonction. Examinez la variable et son utilisation.

API_TOKEN[REDACTED]
Règle
awslambda_function_no_secrets_in_variables
Ressource affectée
billing-handlerAWS Lambda
Compte
Production
Région
eu-west-1
Environnement
Production
Historique enregistré
Premier enregistrement
1 oct. 2026
Dernière mise à jour
4 oct. 2026
Clôture observée
Non observée
Données de démonstration Explorez la fonctionnalité dans votre espace Byrsa
Aperçu généré · Données illustratives
Mauvaises configurations · Données de démonstration
LES CONTRÔLES DE CONFIGURATION EN PRATIQUE

De petits paramètres.
Des conséquences à examiner.

Allez au-delà de l’accès public et du chiffrement. Ces exemples montrent comment identifiants, permissions, sauvegardes et contrôles d’audit peuvent exposer un environnement.

AWS LambdaSECRETS

Des identifiants cachés dans la configuration d’une fonction.

Ce que le contrôle signale
Des variables d’environnement contenant des motifs ressemblant à des mots de passe, clés API ou jetons d’accès.
Pourquoi c’est important
Une personne pouvant lire la configuration pourrait obtenir des identifiants pour un autre système. Examinez le secret potentiel et les services auxquels il pourrait donner accès.

Fonction · Constat sur une variable d’environnement · Compte et région

AWS IAMÉLÉVATION DE PRIVILÈGES

Des permissions qui ouvrent d’autres permissions.

Ce que le contrôle signale
Des politiques gérées par le client contenant des permissions ou combinaisons permettant une élévation de privilèges, comme la modification de politiques ou la transmission de rôles.
Pourquoi c’est important
Une identité pourrait obtenir un accès plus large. Examinez la politique avec les identités et ressources concernées avant d’évaluer l’impact.

Politique IAM · Règle en échec · Contexte de la ressource

Amazon EC2PROTECTION DES IDENTIFIANTS

Des métadonnées d’instance sans jeton de session obligatoire.

Ce que le contrôle signale
Des instances dont le point d’accès aux métadonnées est actif sans exiger de jeton IMDSv2.
Pourquoi c’est important
Certaines attaques SSRF pourraient exposer les identifiants du rôle d’instance. Examinez les métadonnées avec le rôle et l’exposition du workload.

Instance · Configuration des métadonnées · Constats associés

Amazon RDSEXPOSITION DES DONNÉES

Une base privée. Une sauvegarde partagée publiquement.

Ce que le contrôle signale
Des instantanés de bases ou de clusters dont les permissions de restauration autorisent tous les comptes AWS.
Pourquoi c’est important
Un instantané peut exposer une copie des données même si la base elle-même est privée. Examinez le partage des sauvegardes en plus de la base en cours d’exécution.

Instantané · Contrôle du partage · Compte et région

Amazon S3SÉCURITÉ DU TRANSPORT

Un stockage chiffré avec une politique d’accès non sécurisée.

Ce que le contrôle signale
Des buckets sans politique explicite refusant les requêtes via un transport non sécurisé.
Pourquoi c’est important
Le chiffrement au repos n’impose pas HTTPS pour les requêtes. Examinez séparément les contrôles de transport et le stockage des objets.

Bucket · Contrôle de la politique de transport · Détails de la ressource

AWS CloudTrailINTÉGRITÉ DES JOURNAUX

Des journaux d’audit sans validation d’intégrité.

Ce que le contrôle signale
Des pistes dont la validation des fichiers journaux est désactivée : aucun fichier de synthèse signé n’est généré pour ces journaux.
Pourquoi c’est important
Les analystes perdent un moyen de vérifier si les fichiers journaux livrés ont été modifiés ou supprimés. Examinez l’intégrité en complément de la couverture de journalisation.

Piste · Paramètre de validation · Recommandations du contrôle

Exemples de contrôles. Les résultats de votre espace dépendent des contrôles activés, des permissions de scan et des ressources des comptes connectés.

DU PARAMÈTRE À LA RESSOURCE

Comprendre l’échec.
Définir le périmètre.

Gardez la cause du constat en vue, que vous examiniez une ressource ou un problème de configuration répété dans l’environnement.

01
CONSTAT INDIVIDUEL

Lire les éléments collectés

Ouvrez le contrôle en échec pour consulter sa description, sa criticité, la ressource concernée et les dates enregistrées. Les recommandations disponibles précisent la configuration attendue.

02
VUE PAR RÈGLE

Repérer les échecs répétés

Passez à la vue par règle pour examiner le même contrôle sur plusieurs ressources. Filtrez par compte, région et criticité pour définir le périmètre du travail.

03
VUES CIBLÉES

Cibler le type de risque

Utilisez les vues Exposition Internet, Protection des données et IAM pour organiser votre revue. Suivez les liens des ressources pour examiner la configuration à l’origine du constat.

GARDEZ LE TRAVAIL LIÉ AU CONSTAT

Un parcours clair du
constat au suivi.

Attribuez le travail depuis le constat, conservez le contexte de la ressource et examinez le prochain résultat collecté. Une tâche terminée consigne le travail ; un contrôle réussi confirme la configuration observée.

  1. Contrôle en échecComprendre les éléments collectés
  2. Ressource affectéeExaminer la configuration
  3. Tâche liéeAttribuer un responsable
  4. Prochain scanExaminer le résultat collecté
L’avancement des tâches et l’état des contrôles restent distincts : le suivi repose sur les éléments collectés.
POUR ALLER PLUS LOIN

Questions sur
les mauvaises configurations.

Lire le guide utilisateur
Ces constats proviennent-ils de mon compte ?

Les contrôles présentés ici sont des exemples. Votre espace Byrsa affiche les résultats collectés pour vos comptes connectés. La couverture dépend des contrôles activés, des ressources, des permissions de scan et des données collectées.

Un contrôle en échec signifie-t-il qu’une attaque a eu lieu ?

Un échec identifie une configuration à examiner. Il ne prouve pas une exploitation. Utilisez la ressource concernée, les éléments enregistrés et les relations disponibles pour évaluer l’impact potentiel.

Puis-je analyser le même problème sur plusieurs ressources ?

Oui. La vue par règle permet d’examiner les échecs répétés. Ouvrez ensuite chaque constat pour consulter sa ressource, son compte, sa région et les recommandations disponibles.

Comment gérer un risque accepté ?

Lorsque cette option est disponible, enregistrez une exception approuvée avec une justification et une échéance. Distinguez l’exception d’un contrôle réussi et réexaminez-la lorsque l’environnement évolue.

En quoi ces constats diffèrent-ils des CVE ?

Les mauvaises configurations concernent les ressources cloud, politiques d’accès et contrôles de sécurité. Les CVE concernent les vulnérabilités logicielles connues. Utilisez la protection des workloads pour analyser les paquets et versions affectés.

Comprenez ce que vos paramètres cloud exposent.

Examinez une configuration avec l’équipe Byrsa.

Réserver une présentation