Un audit d’infrastructure utile répond à quatre questions : que faisons-nous tourner, qui peut y accéder ou le modifier, quelles preuves démontrent l’efficacité des contrôles et que faut-il corriger en priorité ? Traitez PaaS, IaaS, réseaux, pare-feu et systèmes d’exploitation comme un seul système connecté. Commencez par une autorisation écrite, un périmètre convenu, des responsables nommés, un créneau et un contact d’urgence. Privilégiez les accès en lecture seule et ne testez aucun système sans autorisation.
Cartographiez l’environnement avant les tests : comptes et abonnements cloud, régions, projets, environnements de production et de test, points de terminaison publics, charges de travail, stockages, identités et fournisseurs externes. Représentez les flux de données et les frontières de confiance. Pour chaque actif, notez son propriétaire, sa fonction métier, la sensibilité des données, son exposition, ses dépendances et son importance pour la reprise. Comparez l’inventaire à la facturation, au DNS, aux exports de la console cloud, à la gestion des terminaux et à l’Infrastructure as Code pour repérer les ressources oubliées et changements manuels.
Définissez d’abord la responsabilité partagée. En IaaS, le fournisseur gère généralement les installations physiques et le service sous-jacent, tandis que votre équipe gère les systèmes invités, les charges de travail, les identités, les règles réseau et les données. En PaaS, le fournisseur gère davantage l’environnement d’exécution, mais votre équipe reste responsable du code applicatif, des accès, des données, des secrets et des réglages propres au service. Vérifiez les conditions de chaque service : l’étiquette « géré » ne signifie pas que le fournisseur assure tous les contrôles de sécurité.
Pour l’IaaS, examinez les frontières entre comptes et projets, rôles d’administration, MFA, identités des charges, comptes de service, stockage des clés et secrets, IP publiques, exposition du stockage, sauvegardes, chiffrement, correctifs et dérive de configuration. Préférez des identifiants temporaires et limités ainsi que des voies d’administration privées. Pour le PaaS, vérifiez l’isolation des tenants, l’authentification et l’autorisation, la connectivité privée, les origines autorisées, les droits de déploiement, variables d’environnement, références aux secrets, rétention et journaux d’audit. Assurez-vous que les journaux de diagnostic sont activés, conservés, protégés et utiles en cas d’incident.
Pour le réseau informatique, vérifiez les chemins réels entre utilisateurs, entrée Internet, répartiteurs, couches applicatives, bases de données, interfaces d’administration et destinations sortantes. Examinez sous-réseaux, routes, segmentation, DNS, VPN ou accès privé, administration distante, restrictions de sortie et résilience. Comparez le schéma réseau aux journaux de flux et aux exports de configuration. Analysez les chemins inattendus, réseaux trop plats, bases directement exposées, interfaces inutilisées et trafic contournant les contrôles. Un scanner autorisé peut révéler des services accessibles ; convenez de l’horaire et du débit, puis validez ses résultats : un scan ne constitue pas un audit réseau complet.
Examinez ensemble les règles des groupes de sécurité cloud, ACL réseau, pare-feu hôtes et équipements dédiés. Pour chaque règle, identifiez propriétaire, motif, source, destination, protocole, port, direction, environnement et date d’expiration ou de revue. Recherchez sources Internet sans restriction, plages de ports larges, règles générales, doublons, accès temporaires oubliés et ports d’administration publics. Vérifiez le refus par défaut et la journalisation. Testez les modifications sans risque ; supprimez une règle seulement après confirmation de ses dépendances et préparation d’un retour arrière.
Pour chaque système d’exploitation administré, vérifiez version prise en charge et correctifs, base de sécurité, comptes locaux et d’annuaire, groupes privilégiés, MFA pour l’administration, exposition SSH ou bureau à distance, authentification, pare-feu hôte, protection des terminaux, chiffrement du disque, Secure Boot si disponible, synchronisation horaire, services et tâches au démarrage. Contrôlez la centralisation des journaux, les alertes, les sauvegardes et restaurations et la gestion de configuration. Comparez aux recommandations actuelles du fournisseur ou au CIS Benchmark correspondant et documentez les exceptions justifiées. En PaaS, contrôlez uniquement les mécanismes hôtes visibles et concentrez-vous sur l’application et le service.
Conservez des preuves reproductibles : actif et compte, date, outil ou écran de console, instantané de configuration, état attendu et observé, évaluateur et limites. Protégez les exports et captures, qui peuvent révéler identifiants, topologie ou secrets ; masquez les valeurs sensibles et restreignez l’accès. Classez les constats selon impact, probabilité, actifs touchés, exposition, exploitabilité et contrôles compensatoires. Séparez faiblesses confirmées et observations à approfondir, et désignez un responsable métier et un responsable technique.
Transformez les constats en plan de correction suivi : priorité, responsable, échéance, demande de changement, retour arrière et validation. Corrigez d’abord l’administration exposée et les privilèges excessifs, puis les lacunes de segmentation, systèmes vulnérables ou non pris en charge, angles morts des journaux et sauvegardes insuffisantes. Revalidez le contrôle après modification et gardez les preuves avant/après. Présentez les risques résiduels à la personne habilitée à les accepter. L’audit est terminé lorsque les responsables comprennent le risque et que des actions vérifiées l’ont réduit.
Utilisez les référentiels comme point de départ, pas comme substitut au contexte : NIST SP 800-115 décrit la planification et la conduite d’évaluations techniques ; les CIS Benchmarks proposent des recommandations de configuration par technologie pour le cloud, les équipements réseau et les systèmes d’exploitation. Choisissez le benchmark correspondant au fournisseur et à la version exacte, adaptez-le par des décisions de risque documentées et respectez les techniques autorisées dans les règles d’engagement. Sources : https://csrc.nist.gov/pubs/sp/800/115/final et https://www.cisecurity.org/cis-benchmarks-overview
Donnez à votre prochain produit quelqu’un qui reste.
Prêt à commencer ? Écrivez-moi — je peux démarrer immédiatement et rester dans la durée. Des collaborations à long terme, pas une passation après deux semaines. Discutons de votre projet, de vos exigences et de la meilleure façon d’avancer.