Sécurité des systèmes informatiques/Sécurité informatique/Centralisation des traces
Au travers de la détection d'intrusion, on voit que la collecte d'information dans le système informatique est une opération importante pour traiter ses problèmes de sécurité. Dans certains cas, la centralisation de cette information est quasiment vue comme une fin en soi, et associée à une propriété de la sécurité qui a été baptisée l'auditabilité. De notre point de vue, cette propriété n'est pas réellement dissociée des autres propriétés de sécurité ; par contre, elle met en relief un certain nombre de besoins de sécurité qui impliquent généralement la collecte et le stockage (souvent de manière centralisée) des sources d'information disponibles dans le système informatique. Nous regroupons ces opérations sous le thème de la centralisation des traces dans le système informatique.
Le problème de la gestion des traces
[modifier | modifier le wikicode]Le besoin de collecte peut avoir une origine technique, comme dans les cas où ces traces sont nécessaires pour la mise en œuvre d'un système de détection d'intrusion ou la réalisation de contrôles liés à la sécurité. Mais il peut également avoir une origine plus politique, notamment quand la disponibilité de ces données est liée à l'obligation de pouvoir fournir des éléments d'enquête à des organismes habilités, internes (audit interne) ou externes (tutelles, cour des comptes pour les organismes publics, etc.), voire tout simplement une origine légale pour répondre aux besoins de l'autorité judiciaire. Dans l'ensemble de ces cas, la mise à disposition des traces fournies en standard par les systèmes d'exploitation, les progiciels, les équipements réseau et bien sûr les équipements de sécurité eux-mêmes devrait pouvoir être possible.
Toutefois, pour être réalisable, cette mise à disposition doit réellement avoir été prévue. Par ailleurs, pour être un tant soit peu probantes, les traces collectées doivent présenter un minimum de garanties d'intégrité - la deuxième action d'un attaquant averti étant d'effacer les traces qu'il génère.
Enfin, il ne faut pas oublier que, à partir du moment où ces traces contiennent des informations nominatives - il est quasiment inévitable qu'elles puissent en contenir si elles sont dignes d'intérêt - elles doivent être gérées en conformité avec les directives de la CNIL et de la loi « Informatique et libertés » (c'est à dire qu'elles ne doivent pas être conservées indéfiniment et qu'elles doivent être protégées pour qu'on ne les détourne pas de leur finalité originelle). On consultera notamment sur ces points le rapport de la CNIL sur « La cybersurveillance sur les lieux de travail », disponible à l'adresse : http://www.cnil.fr/fileadmin/documents/approfondir/rapports/Rcybersurveillance-2004-VD.pdf.
À l'heure actuelle, il nous semble que ces besoins peuvent difficilement être satisfaits autrement que par la mise en place pragmatique d'un système centralisé de consolidation et de stockage des traces, géré directement par les acteurs de la SSI. Il semble même que syslog soit un standard de fait incontournable pour prendre en compte une bonne majorité des types d'équipement existants (même si cela demande des adaptations pour les systèmes basés sur MS/Windows).
Mise en œuvre
[modifier | modifier le wikicode]La solution la plus directe : Syslog
[modifier | modifier le wikicode]Dans la pratique, nous recommanderions tout simplement l'utilisation d'un serveur Unix syslog-ng (pour faciliter le tri des traces en fonction de leur origine) détaché du reste du système informatique et décemment configuré du point de vue sécurité, équipé d'une zone de stockage relativement grande et assurant une rotation régulière des traces collectées, par exemple avec l'utilitaire logrotate (Un système Debian GNU/Linux standard assure ces fonctions sans difficultés dans la configuration par défaut).
Les systèmes incapables d'utiliser Syslog ne sont généralement pas capables de faire plus que de stocker leurs traces dans des fichiers à plat, lesquels dans ce cas doivent être déportés manuellement s'ils sont intéressants, par exemple via SSH.
Ce type de solution est loin d'être idéal du point de vue de sa propre sécurité, surtout si on le compare, par exemple, avec les modes de transmission d'alertes de certains IDS (via des connexions SSL authentifiées avec des certificats).
Syslog est un protocole fonctionnant sur UDP [RFC 3164] ou éventuellement sur TCP [RFC 3185], notoirement non-sûr.
Toutefois, dans la pratique, l'intérêt concret d'un tel système (s'il est utilisé par les autres éléments du système informatique pour stocker leurs traces) est très important, à la fois en terme de données disponibles pour la surveillance de la sécurité et pour pouvoir disposer d'informations en cas d'intrusion grave.
Et la protection d'une telle machine est relativement facile à réaliser.
Éléments de volumétrie
[modifier | modifier le wikicode]Nous mentionnons dans cette section quelques données quantitatives relatives à l'utilisation d'un serveur Syslog de centralisation. Les deux figures suivantes permettent de donner une idée (empiriquement) des capacités de stockages (et d'analyse) nécessaires pour des systèmes courants. Toutefois, ces données correspondent bien sûr à des cas particuliers. Suivant les applications concernées, les volumes peuvent être très différents. Ces éléments correspondent à un système informatique comptant environ un millier d'utilisateurs et autant de postes de travail sur lequel les données de sécurité courantes disponibles avec le système d'authentification basé sur Active Directory sont collectées, centralisées, conservées pendant une durée définie puis détruites automatiquement (afin de respecter à la fois les besoins de sécurité des données et des utilisateurs).
Au cours du processus de rotation, les traces sont compressées de manière à maitriser l'espace disque occupé. Les transferts se font au fil de l'eau via UDP, dans le mode de fonctionnement nominal de Syslog. La configuration des paramètres d'émission des traces (niveau d'audit, stratégie d'audit, debug ou logging level, etc.) peut avoir un effet très important sur les volumes impliqués (ainsi que sur la pertinence des traces générées).
La première figure ci-dessus montre l'évolution de l'occupation de la partition de stockage des différentes traces sur une longue période.
La seconde figure détaille plus particulièrement l'évolution de la taille du fichier plat dans lequel l'ensemble des traces sont enregistrées sur une période plus courte. Ce fichier là est non-compressé et subit une rotation hebdomadaire.