Product SiteDocumentation Site

Chapitre 14. Sécurité

14.1. Définir une politique de sécurité
14.2. Pare-feu ou filtre de paquets
14.2.1. nftables Behavior
14.2.2. Moving from iptables to nftables
14.2.3. Syntax of nft
14.2.4. Installer les règles à chaque démarrage
14.3. Supervision : prévention, détection, dissuasion
14.3.1. Surveillance des logs avec logcheck
14.3.2. Surveillance de l'activité
14.3.3. Avoiding Intrusion
14.3.4. Détection des changements
14.3.5. Détection d'intrusion (IDS/NIDS)
14.4. Introduction à AppArmor
14.4.1. Les principes
14.4.2. Activer AppArmor et gérer les profils
14.4.3. Créer un nouveau profil
14.5. Introduction à SELinux
14.5.1. Les principes
14.5.2. La mise en route
14.5.3. La gestion d'un système SELinux
14.5.4. L'adaptation des règles
14.6. Autres considérations sur la sécurité
14.6.1. Risques inhérents aux applications web
14.6.2. Savoir à quoi s'attendre
14.6.3. Bien choisir les logiciels
14.6.4. Gérer une machine dans son ensemble
14.6.5. Les utilisateurs sont des acteurs
14.6.6. Sécurité physique
14.6.7. Responsabilité juridique
14.7. En cas de piratage
14.7.1. Détecter et constater le piratage
14.7.2. Mettre le serveur hors ligne
14.7.3. Préserver tout ce qui peut constituer une preuve
14.7.4. Réinstaller
14.7.5. Analyser à froid
14.7.6. Reconstituer le scénario de l'attaque
Un système d'information a, selon les cas, une importance variable ; parfois, il est vital à la survie d'une entreprise. Il doit donc être protégé en conséquence contre divers risques, ce que l'on regroupe communément sous l'appellation de sécurité.

14.1. Définir une politique de sécurité

Le terme de « sécurité » recouvre une vaste étendue de concepts, d'outils et de procédures, qui ne s'appliquent pas à tous les cas. Il convient de s'interroger sur ce que l'on souhaite accomplir pour choisir lesquels mettre en œuvre. Pour sécuriser un système, il faut se poser quelques questions ; si l'on se lance tête baissée dans la mise en œuvre d'outils, on risque de se focaliser sur certains aspects au détriment des plus importants.
Il est donc crucial de se fixer un but. Pour cela, il s'agit d'apporter des réponses aux questions suivantes :
  • Que cherche-t-on à protéger ? La politique de sécurité à mener ne sera pas la même selon que l'on cherche à protéger les ordinateurs ou les données. Et s'il s'agit des données, il faudra également se demander lesquelles.
  • Contre quoi cherche-t-on à se protéger ? Est-ce d'un vol de données confidentielles ? De la perte accidentelle de ces données ? De la perte de revenu associée à une interruption de service ?
  • Également, de qui cherche-t-on à se protéger ? Les mesures de sécurité à mettre en place différeront largement selon que l'on cherche à se prémunir d'une faute de frappe d'un utilisateur habituel du système ou d'un groupe d'attaquants déterminés.
Il est d'usage d'appeler « risque » la conjonction des trois facteurs : ce qui doit être protégé, ce qu'on souhaite éviter et les éléments qui essaient de faire en sorte que cela arrive. La réunion des réponses à ces trois questions permet de modéliser ce risque. De cette modélisation découlera une politique de sécurité, qui se manifestera à son tour par des actions concrètes.
Il faudra enfin prendre en compte les contraintes qui peuvent limiter la liberté d'action. Jusqu'où est-on prêt à aller pour sécuriser le système ? Cette question a un impact majeur et la réponse apportée est trop souvent formulée en seuls termes de coût, alors qu'il faut également se demander jusqu'à quel point la politique de sécurité peut incommoder les utilisateurs du système, ou en dégrader les performances, par exemple.
Une fois que l'on a établi une modélisation du risque dont on cherche à se prémunir, on peut se pencher sur la définition d'une politique de sécurité.
Dans la plupart des cas, on s'apercevra que le système informatique peut être segmenté en sous-ensembles cohérents plus ou moins indépendants. Chacun de ces sous-systèmes pourra avoir ses besoins et ses contraintes propres ; il faudra donc en général les considérer séparément lors de la définition des politiques de sécurité correspondantes. Il conviendra alors de toujours garder à l'esprit le principe selon lequel un périmètre court et bien défini est plus facile à défendre qu'une frontière vague et longue. L'organisation du réseau devra donc être pensée en conséquence, afin que les services les plus sensibles soient concentrés sur un petit nombre de machines et que ces machines ne soient accessibles qu'à travers un nombre minimal de points de passage, plus faciles à sécuriser que s'il faut défendre chacune des machines contre l'intégralité du monde extérieur. On voit clairement apparaître ici l'utilité des solutions de filtrage du trafic réseau, notamment par des pare-feu. On pourra pour cela utiliser du matériel dédié, mais une solution peut-être plus simple et plus souple est d'utiliser un pare-feu logiciel, tel que celui intégré dans le noyau Linux.