Comment mettre en place des mesures de sécurité robustes pour protéger vos serveurs

Introduction

Lorsque vous travaillez sur une infrastructure cloud, votre principale préoccupation est de vous assurer que vos applications sont pleinement opérationnelles. Un aspect important de votre processus de configuration et de déploiement consiste à intégrer des mesures de sécurité efficaces, approfondies et robustes dans vos applications ou systèmes avant qu'ils ne soient proposés au public. Plutôt que de mettre en œuvre des mesures de sécurité de manière rétroactive après le déploiement, il est important de veiller à ce qu'une configuration de base sécurisée soit intégrée à votre infrastructure.

Ce tutoriel vous aidera à cet égard. Il mettra en évidence certaines mesures de sécurité pratiques qui peuvent être mises en œuvre pendant la configuration et le paramétrage de l'infrastructure de votre serveur. Bien qu'il ne s'agisse pas d'une liste exhaustive de protocoles de sécurité pour serveurs, c'est un point de départ utile. À mesure que vous travaillerez avec votre environnement et vos applications et que vous en comprendrez mieux les besoins spécifiques, vous pourrez développer des mesures de sécurité supplémentaires pour renforcer votre base.

Clés SSH (Secure Shell)

Lorsque vous travaillez avec votre serveur, la majeure partie de votre temps sera consacrée à travailler dans une SSH connexion avec votre serveur lors d'une session de terminal. Les clés SSH (Security Shell) offrent une méthode de connexion au serveur plus sûre que les connexions basées sur des mots de passe. Aux fins d'authentification, avec l'utilisation de clés SSH, deux clés d'accès sont préparées. La première est une clé secrète (privée) tandis que l'autre est une clé publique, partageable.

L'authentification par clé SSH doit d'abord être configurée. Pour ce faire, il faut placer la clé publique SSH dans le répertoire approprié sur le serveur. Lors de la connexion initiale de votre client au serveur, il vous sera demandé de prouver que vous possédez la clé privée. Cela se fait par la génération d'une valeur aléatoire qui sera ensuite envoyée à votre client SSH. Le client SSH, à son tour, utilisera la clé privée pour chiffrer une réponse. Cette réponse sera envoyée au serveur. Ensuite, le serveur déchiffrera le message du client à l'aide de votre clé publique. Si la valeur aléatoire est déchiffrée par le serveur, cela indique que le client possède la clé privée. Dans ce cas, l'authentification est confirmée et une connexion au serveur sans mot de passe peut être établie.

Améliorer la sécurité avec les clés SSH

Bien que l'autorisation par mot de passe ou toute authentification avec SSH soit entièrement chiffrée, des utilisateurs malveillants peuvent tenter d'accéder au serveur. Surtout s'ils ont réussi à obtenir l'adresse IP publique du serveur. En essayant toutes les combinaisons de touches possibles, l'informatique moderne permet les connexions basées sur un mot de passe, et cela est souvent tenté par des utilisateurs malveillants. Si l'on devait automatiser ces tentatives d'accès, il serait possible, en essayant systématiquement différentes combinaisons, de finir par trouver le bon mot de passe.

En tirant parti de l'authentification chiffrée SSH, il n'est pas nécessaire d'activer les mots de passe pour se connecter. Les clés SSH contiennent généralement un nombre considérable de combinaisons potentielles qu'un attaquant devrait tester. Le nombre accru de bits multiplie le potentiel de combinaisons différentes nécessaires pour casser le chiffrement. Par conséquent, tester toutes les combinaisons possibles de l'algorithme de clé SSH prendrait énormément de temps. Ainsi, cette entreprise ne vaut pas le temps d'un attaquant malveillant. C'est pourquoi le chiffrement SSH est généralement considéré comme « inviolable ».

Mise en œuvre des clés SSH

La connexion à n'importe quel serveur Linux distant devrait utiliser des clés SSH. Une clé peut être générée sur la machine locale, et la clé publique transférée vers le serveur en quelques minutes. Avec ce tutoriel, vous aurez une idée de base sur la façon d'utiliser SSH to connect to a remote server in Ubuntu. Vous pouvez également suivre notre tutoriel détaillé sur la configuration de votre serveur Linux pour utiliser l'authentification par clé SSH.

Dans l'ensemble, ne pas autoriser l'utilisateur root à se connecter directement via SSH est une bonne pratique couramment utilisée, tandis que se connecter en tant qu'utilisateur non privilégié et utiliser un outil comme sudo pour élever les privilèges au besoin est recommandé. C'est ce qu'on appelle le principe du moindre privilège : une méthode de limitation des autorisations d'accès. Une fois que la connexion en tant que compte non privilégié a été vérifiée avec SSH, les connexions root peuvent être désactivées en définissant la directive PermitRootLogin no dans /etc/ssh/sshd_config sur votre serveur. Ensuite, le serveur peut être redémarré avec une commande de processus SSH sudo systemctl restart sshd.

Pare-feux

Un logiciel (ou un périphérique matériel) qui régule l'exposition des services au réseau est appelé un pare-feu. Un pare-feu, configuré de manière optimale, garantit que seuls les services autorisés sont disponibles publiquement et autorisés à entrer et sortir du serveur concerné.

Plusieurs services peuvent s'exécuter par défaut sur un serveur et ceux-ci peuvent être classés dans les groupes suivants :

• Services internes : Ceux-ci ne doivent être accessibles qu'en interne depuis le serveur utilise lui-même. Cela empêche l'exposition des services à l'accessibilité publique sur Internet (ex : une base de données accessible uniquement via des connexions locales).
• Services publics : Services qui peuvent être consultés par n'importe qui, souvent de manière anonyme, sur Internet. Ceux-ci incluent les serveurs web qui permettent aux visiteurs d'accéder à votre site.
• Services privés : Seuls les comptes autorisés provenant d'un ensemble exclusif d'emplacements peuvent accéder à ces services (ex : panneau de contrôle de base de données phpMyAdmin).

Alors que les services publics peuvent rester accessibles depuis Internet, les services privés peuvent être restreints en fonction de paramètres d'accès (tels que les types de connexion), et les services internes sont totalement coupés de tout accès basé sur Internet. L'accès à ces services, ainsi que la granularité avec laquelle il est autorisé, sont entièrement contrôlés par le pare-feu. Les ports inutilisés sont généralement configurés pour bloquer complètement leur accès.

Amélioration de la sécurité grâce à l'utilisation d'un pare-feu

Un pare-feu est une base pour la protection des serveurs. Il sert à limiter les connexions vers et depuis les services avant que l'application ne gère le trafic. Bien entendu, vous pouvez implémenter des fonctionnalités de sécurité supplémentaires pour vos services et les restreindre aux interfaces souhaitées.

Seuls les services que vous choisissez de laisser ouverts ne seront pas restreints par un pare-feu correctement configuré. Cela limite les éléments vulnérables à l'exploitation car les logiciels disponibles sont beaucoup plus limités et donc moins susceptibles de subir une attaque.

Mise en œuvre des pare-feux

De nombreux pare-feux sont disponibles pour les systèmes Linux. Certains d'entre eux sont assez complexes. Cependant, la configuration typique d'un pare-feu ne devrait être effectuée qu'au moment de la configuration initiale du serveur, lorsque des modifications des services du serveur sont implémentées. Cela ne devrait vous prendre que quelques minutes. Voici quelques options à envisager pour configurer et activer le pare-feu :

• Pour CentOS, vous pouvez suivre notre guide de configuration d'un pare-feu avec FirewallD sur CentOS 7.
• Notre guide Iptables peut vous guider à travers le listage et la suppression des règles de pare-feu Iptables.

Le plus important, quel que soit le tutoriel, est de vous assurer que le pare-feu choisi bloque le trafic inconnu provenant de vos serveurs afin d'éviter que de nouveaux services disponibles ne soient exposés par inadvertance sur Internet. En devant autoriser explicitement l'accès, vous serez invité à évaluer pleinement comment un service est accédé, exécuté et par qui il est autorisé à être accédé.

Réseaux de cloud privé virtuel (VPC)

Les ressources de votre infrastructure doivent fonctionner à l’intérieur d’un réseau privé connu sous le nom de VPC. Ces réseaux sont plus sécurisés car ils empêchent l’accès à partir d’autres réseaux VPC basés sur le cloud. Ainsi, ils rendent les interfaces du réseau inaccessibles depuis l’Internet public.

Améliorer la sécurité avec les réseaux VPC

Les réseaux privés sont préférables à leurs homologues de réseau public pour la communication interne. VPC permet d’isoler des groupes de ressources dans des réseaux privés particuliers. Comme les réseaux VPC s’interfacent uniquement via des connexions privées, le trafic du réseau est protégé contre l’exposition à l’internet public, où ces informations pourraient être vulnérables à l’interception ou à l’exposition. Les réseaux VPC peuvent également être utilisés pour isoler des environnements d’exécution, ainsi que des locataires. Des passerelles internet peuvent également être configurées comme point d’accès unique entre l’internet public et les ressources de votre réseau VPC.

De plus, une grande partie de la sécurité consiste à analyser nos systèmes et à sécuriser tous les composants au mieux de nos capacités. L’audit des services nous permet de connaître les protocoles acceptables des systèmes, les services en cours d’exécution et les ports utilisés pour la communication. Connaître ces informations peut aider à prendre les meilleures décisions concernant la configuration. Ces décisions peuvent concerner les paramètres du pare-feu, la surveillance et les alertes du système, ainsi que les services qui doivent être accessibles publiquement.

Tirer parti de l’audit pour renforcer la sécurité

Chaque service peut être utilisé pour gérer des clients externes ou à des fins internes. Quel que soit l’objectif, ces services sont tous des points de vulnérabilité pour les utilisateurs malveillants. À mesure que le nombre de services en cours d’exécution augmente, le potentiel d’exploitation des vulnérabilités augmente également.

Vous pouvez commencer à analyser les services une fois que vous avez une idée précise des services exécutés par une machine. Lors de la réalisation d’un audit de services, il est utile de se poser les questions suivantes :

• Ce service particulier doit-il être activement en cours d’exécution ?
• S’exécute-t-il sur les interfaces réseau optimales ?
• Le service est-il plus adapté à une interface réseau publique ou privée ?
• Les règles du pare-feu sont-elles correctement configurées pour autoriser le trafic légitime vers ce service ?
• Le trafic illégitime est-il bloqué par mes règles de pare-feu ?
• Un système d’alerte sur les vulnérabilités de sécurité est-il activé ?

Lors de l’ajout d’un nouveau serveur à l’infrastructure, ce qui précède devrait constituer des pratiques standard dans son processus de configuration. Un avantage supplémentaire des audits de services est qu’ils permettront d’identifier toutes les configurations qui ont été modifiées involontairement.

Réaliser des audits de services

Afin d’auditer les services en cours d’exécution, utilisez la commande ss pour lister tous les ports UDP et TCP activement utilisés sur un serveur. Voici un exemple d’utilisation de la commande ss avec un nom de programme PID, pour vérifier les ports TCP et UDP en écoute :

Un résultat similaire au suivant sera renvoyé :

Votre attention principale doit se porter sur les colonnes Netid, Local Address:Port et Process :

• Si la valeur de Local Address:Port est 0.0.0.0, cela signifie que le service accepte activement toutes les connexions sur toutes les interfaces réseau IPv4. Si l’adresse est [::], alors toutes les connexions IPv6 acceptent le trafic.
• Dans l’exemple ci-dessus, Nginx et SSH écoutent tous deux sur toutes les interfaces publiques sur les deux piles réseau (IPv4 et IPv6).

Avec l’exemple ci-dessus, vous pourriez choisir si vous devez autoriser SSH et Nginx à écouter sur les deux interfaces, ou sur une seule. En général, vous souhaiterez désactiver tous les services inutilisés pour les empêcher de s’exécuter. Par exemple, si votre site ne doit être accessible que via IPv4, il serait utile de désactiver les interfaces IPv6 pour limiter l’exposition.

Rester à jour grâce aux mises à jour sans surveillance

Les mises à jour sans surveillance réduisent le niveau d’effort requis pour sécuriser vos serveurs et aident à raccourcir la durée pendant laquelle ils restent exposés à des bogues connus. Plus vous tardez à exécuter les mises à jour sur votre serveur, plus il reste exposé à des vulnérabilités connues. Les mises à jour sans surveillance garantissent que dès que des paquets de correction sont disponibles, ils peuvent être installés automatiquement sur le serveur afin de limiter la période de vulnérabilité.

En plus de l’audit des serveurs, les mises à jour sans surveillance peuvent considérablement réduire l’exposition aux attaques. Elles réduiront également de manière significative le temps consacré à la maintenance des serveurs.

Comment les mises à jour automatiques sont activées

Les mises à jour automatiques sont désormais une fonctionnalité facultative sur la plupart des distributions de serveurs. Sur Ubuntu, par exemple, l'administrateur peut exécuter la commande suivante :

Pour plus d'informations sur la mise en œuvre des mises à jour automatiques, consultez la section sur les mises à jour automatiques ici. Pour Fedora, les instructions se trouvent ici. Veuillez noter que les mises à jour automatiques n'installeront que les logiciels initialement installés via le système de gestion de paquets de votre système. Toutes les applications supplémentaires, telles que celles basées sur le Web, devront faire l'objet d'une vérification manuelle distincte pour les mises à jour ou être configurées individuellement pour les mises à jour automatiques.

Indexation des répertoires

Lorsqu'un répertoire ne contient pas de fichier d'index, la plupart des serveurs sont configurés pour afficher l'index du répertoire par défaut. En d'autres termes, si un répertoire nommé « downloads » a été créé sur votre serveur web, toute personne naviguant dans ce répertoire pourra voir tous les fichiers qu'il contient. Bien que cela ne constitue pas toujours un risque de sécurité, cela rend des informations confidentielles visibles à des personnes non autorisées. À titre d'exemple, imaginez que votre serveur web contienne un fichier renfermant les identifiants d'accès à la page d'accueil de votre site web et un fichier contenant toutes les configurations de la base de données back-end du site. Si l'indexation des répertoires n'est pas désactivée, ces fichiers seront visibles par quiconque navigue dans ce répertoire.

Améliorer la sécurité en désactivant l'indexation des répertoires

Même si l'indexation des répertoires est utile, elle peut exposer involontairement des fichiers. Pour atténuer cette exposition involontaire et les risques associés, l'indexation des répertoires sur le serveur devrait être désactivée par défaut. Bien que les fichiers restent accessibles aux visiteurs, l'exposition à une consultation involontaire des données est considérablement limitée.

Désactiver l'indexation des répertoires

Dans la plupart des cas, l'ajout d'une seule ligne supplémentaire à la configuration de votre serveur web suffit pour désactiver l'indexation des répertoires.

• Suivez ces étapes pour désactiver ces listages de répertoires sur le wiki d'Apache. Assurez-vous que Options -Indexes est répertorié dans les blocs de configuration Apache Directory.
• Les index sont désactivés par défaut sur Nginx, ce qui ne nécessite aucune action supplémentaire à cet égard.

Sauvegardes fréquentes

Bien que les sauvegardes ne soient pas une mesure de sécurité en soi, elles sont impératives pour protéger les données et l'ensemble des systèmes en cas de compromission du système. Elles permettent également d'analyser comment le système a pu être attaqué. Prenons le scénario malheureux où votre système est attaqué par un rançongiciel (un virus ou un logiciel malveillant qui chiffre les fichiers de votre système et ne les déchiffre que si vous payez une rançon au pirate). S'il n'existe aucune sauvegarde des données, votre seule option est de payer pour récupérer l'accès à vos données. Si les données sont sauvegardées de manière sécurisée, vous y aurez toujours accès et pourrez les récupérer sans avoir besoin d'accéder au système compromis.

Amélioration de la sécurité grâce à des sauvegardes fréquentes

Des sauvegardes fréquentes permettent de récupérer des informations en cas d'attaque, de corruption ou même de perte involontaire (suppression). Quel que soit le type d'événement négatif entraînant une perte de données, le risque est atténué par la conservation de copies des données du serveur.

Outre les attaques par rançongiciel, des sauvegardes fréquentes peuvent faciliter l'investigation mesurable d'attaques système à long terme. Si vous ne stockez pas vos données en toute sécurité sous forme de sauvegarde, déterminer la source de l'attaque et les données compromises peut s'avérer difficile, voire impossible.

Mettre en œuvre des sauvegardes fréquentes

Il est primordial de considérer la récupération vérifiable de données corrompues, compromises ou supprimées comme l'objectif de vos efforts de restauration lors de la sauvegarde de vos systèmes. Pour mieux situer les choses, réfléchissez aux actions qui nécessiteraient le moins de travail pour vous remettre sur pied si votre serveur venait à disparaître demain.

Voici d'autres points à prendre en compte lors de l'élaboration d'un plan de reprise d'activité :

• Si vous travaillez avec des données qui changent de manière dynamique, vos sauvegardes devront probablement être plus fréquentes. En cas de perte de données, si votre dernière sauvegarde est trop ancienne, vous risquez d'être contraint de revenir à des données obsolètes.
• Pensez au processus réel de restauration des sauvegardes. Faudra-t-il ajouter un nouveau serveur pour cela ou le serveur existant peut-il être restauré ?
• Quelle est la plus longue période pendant laquelle votre serveur peut rester inopérationnel ?
• La sauvegarde hors site est-elle une solution nécessaire ?

Pour en savoir plus sur les solutions de reprise après sinistre de CloudSigma, consultez notre article de blog détaillant pourquoi notre Disaster-Recovery-as-a-Service est le compagnon idéal du cloud. Et ici, vous pouvez en savoir plus sur les fonctionnalités de sécurité & de continuité d'activité de CloudSigma. Nous disposons également d'un guide détaillé sur comment configurer facilement la fonctionnalité de sauvegarde de CloudSigma.

Réseaux privés et VPN

Un réseau privé est un réseau dont l'accès et l'utilisation sont réservés à des utilisateurs ou des serveurs particuliers. Une connexion sécurisée entre des appareils distants qui permet à la connexion de fonctionner comme si elle se trouvait dans un réseau privé est un VPN (un réseau privé virtuel). Il vous offre la possibilité de sécuriser les connexions dans un réseau privé et de connecter des serveurs distants.

Comment les réseaux privés améliorent-ils la sécurité ?

Lorsqu'il s'agit de choisir entre un réseau public et un réseau privé pour les communications internes, ce dernier est toujours l'option préférable. Gardez toutefois à l'esprit que d'autres utilisateurs du centre de données peuvent toujours accéder au même réseau. Cela signifie que des mesures de sécurité supplémentaires doivent tout de même être appliquées pour garantir la sécurité des communications entre les serveurs.

Essentiellement, l'utilisation d'un VPN est une approche permettant de délimiter ce que les employés de votre organisation peuvent voir. La correspondance sera totalement sécurisée et privée. Les configurations d'applications permettraient de faire passer le trafic de l'interface virtuelle par le VPN. De cette manière, seuls les services destinés à l'interaction avec les clients via Internet pourront être exposés à un réseau public.

Est-il difficile de mettre en œuvre un VPN ?

L'exploitation de réseaux privés est aussi simple pour votre centre de données que la configuration de vos applications et de votre pare-feu pour utiliser un réseau privé, ainsi que l'activation du VPN lors de la création de votre serveur. Il est important de rappeler que d'autres serveurs partagent le même espace réseau que les réseaux privés à l'échelle du centre.

La configuration initiale d'un VPN est légèrement plus complexe. Cependant, la sécurité supplémentaire que cela apporte en vaut la peine pour la majorité des cas d'utilisation. Les données de configuration et la sécurité partagée doivent être installées et configurées sur chaque serveur du réseau. Pour des informations plus détaillées sur le fonctionnement d'un VPN et un aperçu de la configuration d'OpenVPN sur Ubuntu, suivez ce guide. Vous pouvez également suivre ce tutoriel qui vous guide à travers les étapes pour connecter un réseau VPN à l'infrastructure de CloudSigma.

Chiffrement SSL/TLS et infrastructure à clés publiques

La génération, la gestion et la validation de certificats pour identifier les individus et le chiffrement des communications sont appelées infrastructure à clés publiques (PKI). Différentes entités peuvent s'authentifier mutuellement à l'aide de certificats SSL ou TLS de confiance. Après cela, ils peuvent également être utilisés pour établir une communication chiffrée.

Comment les certificats améliorent la sécurité

Afin de chiffrer le trafic et de valider l'identité des membres sur un serveur, il est essentiel d'établir une autorité de certification (CA) et de pouvoir visualiser tous les certificats de votre réseau. Cela peut aider à prévenir les attaques de type « homme du milieu » (man-in-the-middle), dans lesquelles le serveur est imité par un pirate informatique et le trafic est détourné.

La configuration de chaque serveur peut être établie pour faire confiance à une autorité de certification (CA) centralisée. Toutes les signatures de certificats ultérieures peuvent alors être implicitement approuvées. Si le chiffrement SSL/TLS est pris en charge par les protocoles et les applications utilisés par votre serveur, vous pouvez sécuriser votre système sans la surcharge d'un tunnel VPN. Pour plus d'informations, suivez notre tutoriel sur la façon d'automatiser les renouvellements de certificats SSL LetsEncrypt pour Nginx.

Difficulté de mise en œuvre

La configuration d'une autorité de certification, puis la mise en place du reste de la PKI, peuvent nécessiter un effort initial important. De plus, lorsque de nouveaux certificats doivent être créés, révoqués ou signés, un effort d'administration supplémentaire sera requis.

Comme la plupart des infrastructures doivent évoluer, la mise en œuvre d'une PKO complète est l'approche la plus sensée. Jusqu'à ce que vous atteigniez un point où la PKI vaut les coûts d'administration supplémentaires, l'utilisation d'un VPN pour sécuriser les composants du système peut servir de mesure d'attente adéquate.

Détection des intrusions système et utilisation de l'audit de fichiers

L'audit de fichiers est un processus utilisé pour comparer les fichiers et leurs attributs de votre système dans un état sain et entièrement sécurisé avec ceux de votre système actuel. C'est une bonne méthode pour trouver et isoler les modifications non autorisées du système.

Un IDS, système de détection d'intrusion, fait référence à un logiciel de surveillance qui garde un œil sur toute activité non autorisée sur le système. En général, il utilise des méthodes d'audit de fichiers pour rechercher tout changement inattendu du système.

Amélioration de la sécurité grâce à l'IDS et à l'audit de fichiers

Au-delà du simple audit au niveau des services, la réalisation d'audits au niveau des fichiers est essentielle pour garantir la sécurité de votre système. Cela peut être fait soit par un processus IDS automatisé, soit périodiquement par l'administrateur système.

Les audits de fichiers et les IDS sont les seuls véritables processus permettant de s'assurer que le système n'a subi aucune modification imprévue. La plupart des intrus veulent exploiter les serveurs qu'ils envahissent pendant de longues périodes, et pour ce faire, ils doivent conserver la capacité de dissimuler leurs actions. Ils pourraient remplacer des binaires par des versions vulnérables ou compromises. Tout fichier ayant été modifié dans le système sera détecté par un audit du système de fichiers. Cela vous permet d'avoir la tranquillité d'esprit de savoir très rapidement si l'intégrité du système a été compromise.

Niveau de difficulté de mise en œuvre

La mise en œuvre de l'IDS et de l'audit de fichiers peut être un processus très intense. Au départ, le système doit être configuré pour définir les chemins à exclure et établir les modifications non standard qui ont été apportées au système afin de créer une mesure de référence du système.

Les opérations quotidiennes deviennent également plus fastidieuses car les procédures devront revérifier le système avant l'exécution de toute mise à jour. La base de référence des mesures du système devra également être recréée ou rétablie pour intégrer les changements de version des logiciels dans la nouvelle base de référence du système. Les rapports d'audit devront également être transposés vers un autre emplacement. C’est parce que vous devez empêcher un intrus du système de modifier l'audit pour rester caché en couvrant ses traces.

Bien que cela augmente certainement la charge administrative de votre système, c'est l'un des seuls moyens infaillibles de s'assurer qu'aucun des fichiers n'a été modifié à votre insu. Certains des systèmes de détection d'intrusion et d'audit de fichiers les plus populaires sont Aide et Tripwire.

Environnements isolés

Toute méthode dans laquelle des composants individuels sont exécutés dans leur propre espace dédié est appelée environnement d'exécution isolé.

Cela peut signifier que certains composants d'application particuliers seront hébergés sur leurs propres serveurs dédiés, ou que vos services peuvent être configurés pour fonctionner dans des environnements chroot (ou des conteneurs). Le degré d'isolation de l'environnement dépend principalement des réalités de votre infrastructure et des exigences de votre application.

Améliorer la sécurité avec des environnements isolés

En isolant vos processus dans des environnements individuels, vous isolez également les processus qui pourraient être affectés par des failles de sécurité. Tout comme les compartiments et les cloisons étanches aident à contenir les voies d'eau sur les navires, lorsque vous séparez les différentes parties et composants de votre système, si un intrus accède à l'un d'eux, il ne pourra pas accéder à l'ensemble du système réseau interconnecté.

Difficulté de mise en œuvre

La complexité de l'isolation de vos applications varie en fonction des types de confinement que vous avez décidé d'utiliser. Docker ne considère pas l'isolation comme une fonctionnalité de sécurité. Cependant, lorsque vos composants sont répartis entre différents conteneurs, l'isolation est obtenue beaucoup plus facilement. Vous pouvez suivre ce tutoriel pour installer Docker sur notre infrastructure.

Lorsque des environnements chroot sont mis en place, un certain degré d'isolation est également assuré. Cependant, ce n'est pas une méthode complètement impénétrable car il existe des méthodes pour s'échapper d'un tel environnement. Des machines dédiées pour les différents composants sont généralement le moyen le plus simple et le plus efficace d'obtenir une isolation. Cependant, cela est plus coûteux en raison de la nécessité de machines supplémentaires.

Dernières réflexions

Les stratégies fournies ne sont que quelques-unes des étapes que vous pouvez suivre afin d'augmenter la sécurité de votre système. Il convient d’ajouter que plus vous attendez pour implémenter les fonctionnalités de sécurité, plus leur efficacité diminue. Dans cette optique, il est important de s'assurer que la sécurité ne soit pas mise de côté. Au contraire, elle devrait être mise en œuvre comme l'une des premières dispositions de la construction de l'infrastructure. Une fois que votre système est suffisamment sécurisé avec des protections de base, vous pouvez commencer à activer des services et à ajouter des applications, tout en sachant qu'elles s'exécutent par défaut dans un environnement sécurisé.

La sécurité n'est pas un processus stagnant, cependant, mais un processus fluide. Elle doit être maintenue et itérée. Elle doit être abordée avec une mentalité de conscience constante et de vigilance persistante. Posez-vous toujours la question de savoir quelles sont les implications en matière de sécurité de tout changement de système.  Assurez-vous que les environnements d'exploitation et les configurations par défaut optimisent toujours la sécurité et fonctionnent avec des logiciels suffisamment défensifs.

Bonne informatique !