Disclaimer: Het origineel van deze pagina geschreven in het Nederlands. Deze pagina is automatisch vertaald naar andere talen met behulp van DeepL. Dit kan leiden tot verschillen in nuance, toon en betekenis. Raadpleeg bij twijfel altijd eerst de Nederlandse versie. Door de hoge kosten van vertalingen kan het zijn dat deze pagina inhoudelijk achter loopt met de Nederlandse versie. Wij beschouwen de Nederlandse versie van deze pagina als leidend.Cette page contient une liste de situations d’exception pour les mesures de sécurité de base. Une mesure sans contexte sera jugée négativement. C’est pourquoi la sécurité de base ajoute des exceptions selon le processus dit « se conformer ou s’expliquer ».
Si une exception est manquante, veuillez nous contacter. Cette demande d’exception sera alors examinée et pourra ou non être ajoutée aux mesures. Incluez les exigences du manuel de bonnes explications.
Numéros de version
L’objectif est de ne pas trouver d’informations qu’un pirate pourrait utiliser pour mener une attaque. En général, nous ne nous attendons donc pas à trouver des numéros de version. Voici les exceptions à cette règle :
- Les chaînes SSH2.0 sans commentaires sont exclues car les informations sur la version font partie du protocole. Voir www.openssh.com/txt/rfc4253.txt 4.2. Cela signifie, par exemple, que « OpenSSH_9.2p1 » est approuvé mais que « OpenSSH_9.2p1 Debian-2+deb12u2 » ne l’est pas. Cela est dû au fait qu’il publie des informations supplémentaires (« Debian-2+deb12u2 ») sur le système. Cela signifie que le système n’est pas renforcé contre les attaquants et qu’un attaquant sait exactement de quel type de système il s’agit.
- Versions majeures de produits bien connus qui ne disent pas grand-chose sur le niveau du correctif. Par exemple : Microsoft IIS 8.5, Microsoft httpapi/2.0, rtc 7.0, awselb/2.0. Ces versions sont approuvées.
Certificats
Tous les certificats devraient être délivrés par un organisme accrédité. Ces certificats sont ensuite reconnus par les navigateurs et les appareils. Voici les exceptions à cette règle :
- Certificats gouvernementaux G1. Ces certificats ne sont pas reconnus par le navigateur mais sont reconnus par le gouvernement central. Cela est indiqué par une déclaration. Le terme « non fiable » est désormais utilisé à dessein. Le certificat accepté doit comporter, entre autres, le numéro de série 10004001.
Portes ouvertes
On s’attend à ce que la surface d’attaque soit minimale, c’est-à-dire qu’il y ait le moins de ports ouverts possible. Voici les exceptions à cette règle :
- 8080/8443 (Cloudflare) : Le pare-feu Cloudflare ouvre certains ports redondants par défaut, comme le 8080. Vous pouvez configurer vous-même ce qui y apparaît. Si nous voyons cloudflare listé ici, nous l’approuvons maintenant avec une explication. En fin de compte, ce n’est pas une bonne chose et nous encourageons les utilisateurs de cloudflare à indiquer que l’entreprise devrait commencer à fermer ces ports. Cette exception est basée sur le contenu de la page web. Une politique est appliquée à cet égard en tant que déclaration.
- 8443 (VPN) : les sous-domaines liés au travail à domicile peuvent ouvrir ce port. Nous reconnaissons cela aux sous-domaines (et aux nombreuses variantes) : télétravail, travail à domicile, lieu de travail, poste de travail, extranet, intranet, à distance, travail à distance, vpn, etc.
Transfert de données cryptées (HTTPS)
On s’attend à ce que les sites web et les services web soient cryptés afin que les informations restent confidentielles. Voici les exceptions à cette règle :
- Listes de révocation de certificats : aucune connexion cryptée n’est nécessaire pour les sous-domaines « pki », « crl », « ocsp » et certaines de leurs variantes. L’en-tête HSTS n’a pas besoin d’être défini sur le port 443 (nous n’attendons pas https).
- Aucun cryptage n’est requis sur les sous-domaines Microsoft Autodiscover, il s’agit d’une exception générale pour les services Microsoft, car sinon tout le monde est rouge… ? Ceci s’applique aux domaines « autodiscover » et « autodiscover.test ».
En-têtes HTTP
On s’attend à ce que tous les sites web soient sécurisés. Voici les exceptions à cette règle :
- En-têtes manquants pour les types de contenu SOAP/JSON/XML : Ces services ne sont pas destinés aux humains et n’ont donc pas besoin de fournir la protection du navigateur destinée à protéger les humains.
- En-têtes manquants pour les services techniques : Pour le sous-domaine ADFS, l’en-tête HSTS ne doit pas être défini.
Autre
Toutes les exigences en matière de sécurité devraient être respectées. Il existe des scénarios complexes dans lesquels cela ne s’est pas encore produit ou n’est pas possible. Ce sont les exceptions :
- Les services Microsoft sur les sous-domaines autour de lyncdiscover, sip, enterpriseenrollment, enterpriseregistration, webmail, msoid. Cette mesure a été prise parce que ces services ne sont pas destinés aux navigateurs mais à des services automatisés. En même temps, l’impact serait élevé partout et les fournisseurs de services TIC ne peuvent pas résoudre ces problèmes :
- Le certificat de ces sous-domaines est approuvé, bien qu’il ne soit pas approuvé par Qualys.
- Comme il s’agit de services destinés aux appareils et non aux navigateurs, les en-têtes http ne sont pas obligatoires.