26/11/2013

Architecture réseau et le PCI DSS 3.0

A l'occasion de la sortie de la version 3.0 du PCI DSS, voici une synthèse des règles d'architecture réseau imposées par le standard.

J'espère par cet article tordre le coup à certaines légendes urbaines sur les règles PCI DSS concernant l'architecture réseau.


1.2.1 Restrict inbound and outbound traffic to that which is necessary for the CDE

C'est l'exigence générale : il faut que les systèmes PCI soient protégés par un firewall qui bloque par défaut toutes les connexions entrantes et sortantes. C'est la règle deny-all.


1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.
1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ. 


Les services (et leurs serveurs sous-jacents) ayant pour vocation d'être accessibles depuis Internet doivent être positionnés dans un VLAN "DMZ". Les autres systèmes PCI seront alors dans un ou plusieurs VLANs constituant l'INZ (Internal Network Zone).

L'accès aux services exposés (typiquement les ports TCP/80 et TCP/443) doit impérativement être filtrés par un firewall.


1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.
1.3.5 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
Typiquement, on est d'accord pour mettre les serveurs HTTP en DMZ, mais on constate parfois un service d'un serveur interne mappé sur une IP publique (ex: un serveur SSH, un serveur FTP...). C'est interdit. Tout service accessible librement par Internet doit être en DMZ. On peut cependant extrapoler qu'il est possible de mapper un service hébergé en INZ à condition d'avoir un filtrage par adresses sources. 

Aucun service de la zone INZ ne doit être accessible en "source=any" depuis Internet. 

Les serveurs PCI (DMZ et INZ compris) ne doivent pas pouvoir établir des connexions sortantes vers Internet sans restriction. 

Aucun service de la zone INZ ne doit être accessible en "source=any" depuis Internet. 

Typiquement, les serveurs ne doivent pas avoir "accès à Internet", sauf vers des destinations connues : PSP, serveurs d'update...


1.3.4 Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network.

C'est la règle d'anti-spoofing. Je me demande toujours pourquoi elle est encore là, car les attaques par spoofing n'ont plus de réalité avec l'Internet aujourd'hui. Certainement une exigence poussée par les vendeurs de firewall avec l'option "anti-spoofing"...


1.3.7 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.

Les systèmes qui stockent des numéros de cartes (PANs) sur leurs systèmes de fichiers attachés, qu'il s'agit d'une base de données ou de fichiers de transactions, doivent être positionnés en INZ.

Cette exigence est souvent mal interprétée, beaucoup pensent que toutes les bases de données devaient être "obligatoirement" en INZ. Or, cette exigence 1.3.7 ne s'applique par définition pas aux bases de données techniques qui ne stockent pas de cartes, comme par exemple les bases utilisées par les CMS. 



2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. 
Je rajoute l'exigence 2.2.1 ici pour mettre en évidence une autre idée reçue du PCI DSS : les bases de données doivent forcément être installées sur des serveurs différents des serveurs HTTP/Web. C'est faux. L'exigence est : une seule fonction primaire par serveur. Or, la base de données techniques d'un CMS, n'est pas une fonction primaire. Elle le serait si elle stockait des cartes, mais si elle ne sert qu'à stocker du contenu, il est tout à fait possible de considérer de l'installer sur le serveur. 


Aucun commentaire:

Enregistrer un commentaire