Mesures de sécurité recommandées pour protéger vos serveurs

Introduction

La mise en place et l'exécution de vos applications seront souvent votre principale préoccupation lorsque vous travaillez sur une infrastructure cloud. Dans le cadre de votre processus de configuration et de déploiement, il est important d'inclure des mesures de sécurité robustes et approfondies pour vos systèmes et applications avant qu'ils ne soient accessibles au public. La mise en œuvre des mesures de sécurité de ce didacticiel avant de déployer vos applications garantira que tout logiciel que vous exécutez sur votre infrastructure dispose d'une configuration de base sécurisée, par opposition aux mesures ad hoc qui peuvent être mises en œuvre après le déploiement.

Ce guide présente certaines mesures de sécurité pratiques que vous pouvez prendre lors de la configuration et de l'installation de votre infrastructure de serveur. Cette liste n'est pas une liste exhaustive de tout ce que vous pouvez faire pour sécuriser vos serveurs, mais cela vous offre un point de départ sur lequel vous pouvez vous appuyer. Au fil du temps, vous pouvez développer une approche de sécurité plus personnalisée qui répond aux besoins spécifiques de vos environnements et applications.

Clés SSH

SSH, ou shell sécurisé, est un protocole crypté utilisé pour administrer et communiquer avec les serveurs. Lorsque vous travaillez avec un serveur, vous passerez probablement la plupart de votre temps dans une session de terminal connectée à votre serveur via SSH. Une alternative plus sécurisée aux connexions basées sur un mot de passe, les clés SSH utilisent le cryptage pour fournir un moyen sécurisé de se connecter à votre serveur et sont recommandées pour tous les utilisateurs.

Avec les clés SSH, une paire de clés privée et publique est créée à des fins d'authentification. La clé privée est gardée secrète et sécurisée par l'utilisateur, tandis que la clé publique peut être partagée.

Pour configurer l'authentification par clé SSH, vous devez placer votre clé SSH publique sur le serveur dans son répertoire approprié. Lorsque votre client se connecte pour la première fois au serveur, le serveur vous demandera une preuve que vous disposez de la clé privée associée. Pour ce faire, il génère une valeur aléatoire et l'envoie à votre client SSH. Votre client SSH utilisera alors votre clé privée pour chiffrer la réponse, puis enverra la réponse chiffrée au serveur. Le serveur déchiffre ensuite la réponse de votre client à l'aide de votre clé publique. Si le serveur peut déchiffrer la valeur aléatoire, cela signifie que votre client possède la clé privée et le serveur vous permettra de vous connecter sans mot de passe.

Pour en savoir plus sur le fonctionnement de l'authentification basée sur la clé SSH, consultez notre article Comprendre le processus de cryptage et de connexion SSH.

Comment les clés SSH améliorent-elles la sécurité ?

Avec SSH, tout type d'authentification, y compris l'authentification par mot de passe, est entièrement chiffré. Cependant, lorsque les connexions basées sur un mot de passe sont autorisées, les utilisateurs malveillants peuvent tenter à plusieurs reprises d'accéder à un serveur, en particulier s'il possède une adresse IP publique. Avec la puissance informatique moderne, il est possible d'accéder à un serveur en automatisant ces tentatives et en essayant combinaison après combinaison jusqu'à ce que le bon mot de passe soit trouvé.

La configuration de l'authentification par clé SSH vous permet de désactiver l'authentification par mot de passe. Les clés SSH contiennent généralement beaucoup plus de bits de données qu'un mot de passe, ce qui signifie qu'il y a beaucoup plus de combinaisons possibles qu'un attaquant devrait parcourir. De nombreux algorithmes de clé SSH sont considérés comme indéchiffrables par le matériel informatique moderne car ils nécessiteraient trop de temps pour parcourir toutes les correspondances possibles.

Comment implémenter des clés SSH

Les clés SSH sont la méthode recommandée pour se connecter à distance à n'importe quel environnement de serveur Linux. Une paire de clés SSH peut être générée sur votre machine locale et vous pouvez transférer la clé publique sur vos serveurs en quelques minutes.

Pour configurer la clé SSH sur votre serveur, suivez nos guides spécifiques à la distribution Comment configurer les clés SSH pour Ubuntu, Debian ou CentOS.

Si vous souhaitez toujours une authentification par mot de passe, envisagez d'implémenter une solution telle que fail2ban sur vos serveurs pour limiter les tentatives de mot de passe.

Dans les deux cas, il est recommandé de ne pas autoriser l'utilisateur root à se connecter directement via SSH. Au lieu de cela, connectez-vous en tant qu'utilisateur non privilégié, puis augmentez les privilèges si nécessaire à l'aide d'un outil tel que sudo . Cette approche de la limitation des autorisations est connue sous le nom de principe du moindre privilège. Une fois que vous vous êtes connecté à votre serveur et que vous avez créé un compte non privilégié dont vous avez vérifié qu'il fonctionne avec SSH, vous pouvez désactiver les connexions root en définissant la directive PermitRootLogin no dans /etc/ssh/sshd_config sur votre serveur. puis en redémarrant le processus SSH du serveur avec une commande telle que sudo systemctl restart sshd.

Pare-feu

Un pare-feu est un dispositif logiciel ou matériel qui contrôle la manière dont les services sont exposés au réseau et les types de trafic autorisés à entrer et sortir d'un ou plusieurs serveurs donnés. Un pare-feu correctement configuré garantira que seuls les services qui devraient être accessibles au public sont accessibles depuis l'extérieur de vos serveurs ou de votre réseau.

Sur un serveur typique, un certain nombre de services peuvent être exécutés par défaut. Ceux-ci peuvent être classés dans les groupes suivants :

• Services publics accessibles à tous sur Internet, souvent de manière anonyme. Un exemple de ceci est un serveur Web qui peut permettre l'accès à votre site.
• Services privés qui ne doivent être accessibles que par un groupe restreint de comptes autorisés ou à partir de certains emplacements. Par exemple, un panneau de contrôle de base de données comme phpMyAdmin.
• Services internes qui ne doivent être accessibles que depuis le serveur lui-même, sans exposer le service à l'Internet public. Par exemple, une base de données qui ne devrait accepter que les connexions locales.

Les pare-feu peuvent garantir que l'accès à votre logiciel est limité selon les catégories ci-dessus avec différents degrés de granularité. Les services publics peuvent être laissés ouverts et disponibles sur Internet, et les services privés peuvent être restreints en fonction de différents critères, tels que les types de connexion. Les services internes peuvent être rendus totalement inaccessibles à Internet. Pour les ports qui ne sont pas utilisés, l'accès est entièrement bloqué dans la plupart des configurations.

Comment les pare-feu améliorent-ils la sécurité ?

Même si vos services implémentent des fonctionnalités de sécurité ou sont limités aux interfaces sur lesquelles vous souhaitez qu'ils s'exécutent, un pare-feu sert de couche de protection de base en limitant les connexions vers et depuis vos services avant que le trafic ne soit géré par une application.

Un pare-feu correctement configuré limitera l'accès à tout sauf aux services spécifiques dont vous avez besoin pour rester ouverts. L'exposition de quelques logiciels seulement réduit la surface d'attaque de votre serveur, limitant les composants vulnérables à l'exploitation.

Comment implémenter des pare-feu

Il existe de nombreux pare-feu disponibles pour les systèmes Linux, certains sont plus complexes que d'autres. En général, cependant, la configuration du pare-feu ne devrait prendre que quelques minutes et ne doit avoir lieu que lors de la configuration initiale de votre serveur ou lorsque vous apportez des modifications aux services exécutés sur votre serveur. Voici quelques options pour être opérationnel :

• UFW, ou Uncomplicated Firewall, est installé par défaut dans certaines distributions Linux comme Ubuntu. Un pare-feu populaire, vous pouvez en savoir plus à ce sujet dans notre tutoriel Comment configurer un pare-feu avec UFW sur Ubuntu 20.04
• Si vous utilisez CentOS, vous pouvez suivre Comment configurer un pare-feu à l'aide d'un pare-feu sur CentOS 8
• Si vous souhaitez apprendre à utiliser Iptables, notre tutoriel Iptables Essentials : Common Firewall Rules and Commands montre comment utiliser directement Iptables

Si vous utilisez DigitalOcean, vous pouvez également tirer parti du pare-feu Cloud sans frais supplémentaires, qui peut être configuré en quelques minutes.

Avec l'un des didacticiels mentionnés ici, assurez-vous que la configuration de votre pare-feu bloque par défaut le trafic inconnu. De cette façon, les nouveaux services que vous déployez ne seront pas exposés par inadvertance à Internet. Au lieu de cela, vous devrez autoriser l'accès explicitement, ce qui vous obligera à évaluer comment le service est exécuté, accessible et qui devrait pouvoir l'utiliser.

Réseaux VPC

Les réseaux Virtual Private Cloud (VPC) sont des réseaux privés pour les ressources de votre infrastructure. Les réseaux VPC fournissent une connexion plus sécurisée entre les ressources, car les interfaces du réseau sont inaccessibles depuis l'Internet public et d'autres réseaux VPC dans le cloud.

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

L'utilisation de réseaux privés plutôt que publics pour la communication interne est préférable étant donné le choix entre les deux, car les réseaux VPC vous permettent d'isoler des groupes de ressources dans des réseaux privés spécifiques. Les réseaux VPC ne se connecteront les uns aux autres qu'en utilisant leurs interfaces réseau privées sur un réseau interne, ce qui signifie que le trafic entre vos systèmes ne sera pas acheminé via l'Internet public où il pourrait être exposé ou intercepté. Les réseaux VPC peuvent également être utilisés pour isoler les environnements d'exécution et les locataires.

De plus, vous pouvez configurer des passerelles Internet comme point d'accès unique entre les ressources de votre réseau VPC et l'Internet public, ce qui vous donne plus de contrôle et de visibilité sur le trafic public se connectant à vos ressources.

Comment mettre en œuvre des réseaux VPC

De nombreux fournisseurs d'infrastructure cloud vous permettent de créer et d'ajouter des ressources à un réseau VPC au sein de leurs centres de données.

Si vous utilisez DigitalOcean et que vous souhaitez configurer votre propre passerelle VPC, vous pouvez suivre notre guide Comment configurer une gouttelette en tant que passerelle VPC pour en savoir plus sur les serveurs basés sur Debian, Ubuntu et CentOS.

DigitalOcean place chaque ressource applicable (droplets, équilibreurs de charge, clusters Kubernetes et bases de données) dans un VPC lors de la création sans frais supplémentaires

La configuration manuelle de votre propre réseau privé peut nécessiter des configurations de serveur avancées et des connaissances en réseau. Une alternative à la configuration d'un réseau VPC consiste à utiliser une connexion VPN entre vos serveurs. Si vous utilisez Ubuntu ou CentOS, vous pouvez suivre ce tutoriel Comment installer et configurer un serveur OpenVPN sur Ubuntu 20.04 .

Pour un VPN moins complexe entre les serveurs Ubuntu, suivez ce tutoriel Comment installer Tinc et configurer un VPN de base sur Ubuntu 18.04 .

Audit des services

Une grande partie de la sécurité consiste à analyser nos systèmes, à comprendre les surfaces d'attaque disponibles et à verrouiller les composants du mieux que nous pouvons.

L'audit de service est un moyen de savoir quels services s'exécutent sur un système donné, quels ports ils utilisent pour la communication et quels protocoles sont acceptés. Ces informations peuvent vous aider à configurer les services qui doivent être accessibles au public, les paramètres de pare-feu, ainsi que la surveillance et les alertes.

Comment l'audit de service améliore-t-il la sécurité ?

Les serveurs peuvent exécuter des processus à des fins internes et pour gérer des clients externes. Chaque service en cours d'exécution, qu'il soit destiné à être interne ou public, représente une surface d'attaque étendue pour les utilisateurs malveillants. Plus vous avez de services en cours d'exécution, plus le risque qu'une vulnérabilité affecte votre logiciel est grand.

Une fois que vous avez une bonne idée des services réseau exécutés sur votre machine, vous pouvez commencer à analyser ces services. Lorsque vous effectuez un audit de service, posez-vous les questions suivantes sur chaque service en cours d'exécution :

• Ce service doit-il fonctionner ?
• Le service s'exécute-t-il sur des interfaces réseau sur lesquelles il ne devrait pas s'exécuter ?
• Le service doit-il être lié à une interface réseau publique ou privée ?
• Mes règles de pare-feu sont-elles structurées pour transmettre le trafic légitime à ce service ?
• Mes règles de pare-feu bloquent-elles le trafic qui n'est pas légitime ?
• Ai-je une méthode pour recevoir des alertes de sécurité sur les vulnérabilités de chacun de ces services ?

Ce type d'audit de service doit être une pratique courante lors de la configuration de tout nouveau serveur dans votre infrastructure. La réalisation d'audits de service tous les quelques mois vous aidera également à détecter tous les services dont les configurations peuvent avoir changé involontairement.

Comment effectuer des audits de service

Pour auditer les services réseau qui s'exécutent sur votre système, utilisez la commande ss pour répertorier tous les ports TCP et UDP utilisés sur un serveur. Un exemple de commande qui affiche le nom du programme, le PID et les adresses utilisées pour écouter le trafic TCP et UDP est :

sudo ss -plunt

Vous recevrez une sortie semblable à celle-ci :

OutputNetid       State        Recv-Q       Send-Q             Local Address:Port             Peer Address:Port      Process
tcp         LISTEN       0            128                      0.0.0.0:22                    0.0.0.0:*         users:(("sshd",pid=812,fd=3))
tcp         LISTEN       0            511                      0.0.0.0:80                    0.0.0.0:*         users:(("nginx",pid=69226,fd=6),("nginx",pid=69225,fd=6))
tcp         LISTEN       0            128                         [::]:22                       [::]:*         users:(("sshd",pid=812,fd=4))
tcp         LISTEN       0            511                         [::]:80                       [::]:*         users:(("nginx",pid=69226,fd=7),("nginx",pid=69225,fd=7))

Les principales colonnes qui nécessitent votre attention sont les colonnes Netid, Local Address:Port et Process name. Si l'adresse locale : port est 0.0.0.0, le service accepte les connexions sur toutes les interfaces réseau IPv4. Si l'adresse est [::], le service accepte les connexions sur toutes les interfaces IPv6. Dans l'exemple de sortie ci-dessus, SSH et Nginx écoutent tous les deux sur toutes les interfaces publiques, sur les piles réseau IPv4 et IPv6.

Avec cet exemple de sortie, vous pouvez décider si vous souhaitez autoriser SSH et Nginx à écouter sur les deux interfaces, ou uniquement sur l'une ou l'autre. En règle générale, vous devez désactiver les services qui s'exécutent sur des interfaces inutilisées. Par exemple, si votre site ne doit être accessible que via IPv4, vous empêcherez explicitement un service d'écouter sur les interfaces IPv6 pour réduire le nombre de services exposés.

Mises à jour sans surveillance

Maintenir vos serveurs à jour avec des correctifs est indispensable pour garantir un bon niveau de sécurité de base. Les serveurs obsolètes et les versions non sécurisées des logiciels sont responsables de la majorité des compromis, mais des mises à jour régulières peuvent atténuer les vulnérabilités et empêcher les attaquants de prendre pied sur vos serveurs.

Les mises à jour traditionnelles nécessitent qu'un administrateur vérifie et installe manuellement les mises à jour des différents packages sur son serveur ; cela peut prendre beaucoup de temps et il est possible d'oublier ou de manquer une mise à jour majeure. En revanche, les mises à jour sans surveillance permettent au système de mettre à jour automatiquement la majorité des packages.

Comment les mises à jour sans surveillance améliorent-elles la sécurité ?

La mise en œuvre de mises à jour sans surveillance réduit le niveau d'effort requis pour assurer la sécurité de vos serveurs et raccourcit la durée pendant laquelle vos serveurs peuvent être vulnérables aux bogues connus. En cas de vulnérabilité affectant les logiciels de vos serveurs, vos serveurs seront vulnérables aussi longtemps qu'il vous faudra pour exécuter les mises à jour. Des mises à jour quotidiennes sans surveillance garantissent que vous ne manquez aucun paquet et que tout logiciel vulnérable est corrigé dès que des correctifs sont disponibles.

En conjonction avec l'audit de service mentionné précédemment, l'exécution automatique des mises à jour peut considérablement réduire votre exposition aux attaques et réduire le temps passé à maintenir la sécurité de votre serveur.

Comment implémenter des mises à jour sans surveillance

La plupart des distributions de serveur proposent désormais des mises à jour sans surveillance en option. Par exemple, sur Ubuntu, un administrateur peut exécuter :

sudo apt install unattended-upgrades

Pour plus de détails sur la façon d'implémenter des mises à jour sans surveillance, consultez ces guides pour Ubuntu (sous Mises à jour automatiques) et Fedora.

Remarque : Ces mécanismes ne mettront à jour automatiquement que les logiciels installés via le gestionnaire de packages de votre système. Assurez-vous que tous les logiciels supplémentaires que vous exécutez, comme les applications Web, sont soit configurés pour des mises à jour automatiques, soit vérifiés manuellement de manière régulière.

Désactiver les index de répertoire

La plupart des serveurs Web sont configurés par défaut pour afficher des index de répertoire lorsqu'un utilisateur accède à un répertoire dépourvu de fichier d'index. Par exemple, si vous deviez créer un répertoire appelé downloads sur votre serveur Web sans aucune configuration supplémentaire, tous les fichiers seraient visibles par toute personne parcourant le répertoire. Dans de nombreux cas, ce n'est pas un problème de sécurité, mais il est très possible que quelque chose de confidentiel soit exposé. Par exemple, si vous deviez créer un répertoire d'index sur votre serveur Web pour votre site Web, le répertoire peut contenir le fichier de la page d'accueil de votre site Web et un fichier de configuration contenant les informations d'identification de la base de données principale du site Web. Sans désactiver les index du répertoire, les deux fichiers du dossier seraient visibles par toute personne parcourant le répertoire.

Comment la désactivation des index de répertoire améliore-t-elle la sécurité ?

Les index de répertoire ont des objectifs légitimes, mais ils exposent souvent involontairement des fichiers aux visiteurs. La désactivation des index de répertoire par défaut pour votre serveur Web élimine le risque de perte, de fuite ou d'exploitation accidentelle de données en rendant les fichiers de répertoire invisibles pour les visiteurs. Les visiteurs peuvent toujours accéder aux fichiers s'ils existent dans le répertoire, mais la désactivation de l'indexation rend les fichiers beaucoup plus difficiles à découvrir par inadvertance.

Comment désactiver les index de répertoire

Dans la plupart des cas, la désactivation des index de répertoire consiste à ajouter une ligne à la configuration de votre serveur Web.

• Nginx désactive les index de répertoires par défaut, donc si vous utilisez Nginx, vous ne devriez pas avoir besoin d'apporter de modifications.
• La page DirectoryListings sur Apache Wiki explique comment désactiver les listes de répertoires. Assurez-vous d'utiliser l'option Options -Indexes répertoriée ici pour l'un de vos blocs de configuration Apache Directory.

Sauvegardez fréquemment

Bien qu'il ne s'agisse pas strictement d'une mesure de sécurité, les sauvegardes peuvent être cruciales pour sauvegarder les systèmes et les données compromis, et pour analyser comment le système a été compromis. Par exemple, si votre serveur est compromis par ransomware (un outil malveillant ou un virus qui chiffre les fichiers et ne les déchiffre que si l'attaquant reçoit une certaine somme d'argent), un manque de sauvegardes peut signifier votre seul choix est de payer pour récupérer vos données. Si vos systèmes et vos données sont sauvegardés régulièrement et en toute sécurité, vous pourrez accéder à vos données et les récupérer sans interagir avec le système compromis.

Comment les sauvegardes fréquentes améliorent-elles la sécurité ?

Des sauvegardes fréquentes aident à récupérer les données en cas de suppressions accidentelles et en cas d'attaque où vos données sont supprimées ou corrompues. Dans les deux cas, ils contribuent à atténuer le risque de perte de données en conservant des copies des données antérieures à une suppression accidentelle ou à une attaque.

En plus des cas de rançongiciels, des sauvegardes régulières peuvent aider à l'analyse médico-légale des attaques à long terme. Si vous ne disposez pas d'un historique de vos données, il peut être difficile, voire impossible, de déterminer quand une attaque a commencé et quelles données ont été compromises.

Comment implémenter des sauvegardes fréquentes

Lors de la mise en œuvre de sauvegardes pour vos systèmes, considérez comme objectif la récupération vérifiable des données compromises ou supprimées. Demandez-vous : si mon serveur disparaît demain, quelles mesures doivent être prises pour le remettre en marche en toute sécurité avec le moins de travail ?

Voici quelques autres questions à prendre en compte lors de l'élaboration d'un plan de reprise après sinistre :

• La dernière sauvegarde doit-elle toujours être utilisée ? En fonction de la fréquence à laquelle vos données changent et du moment où un compromis ou une suppression se produit, cela peut réduire le risque d'utiliser par défaut une sauvegarde plus ancienne.
• Quel est le processus réel de restauration de la sauvegarde ? Avez-vous besoin de créer un nouveau serveur ou de restaurer celui existant ?
• Combien de temps pouvez-vous survivre sans ce serveur en action ?
• Avez-vous besoin de sauvegardes hors site ?

Si vous utilisez DigitalOcean Droplets, vous pouvez activer les sauvegardes hebdomadaires à partir du panneau de configuration en suivant ce guide.

Comment sauvegarder des données sur un service de stockage d'objets avec le client de sauvegarde Restic est un didacticiel que vous pouvez utiliser pour concevoir votre propre système de sauvegarde qui chiffrera vos sauvegardes et les stockera hors de vos systèmes de production. Le didacticiel fonctionnera avec des serveurs, ou même des ordinateurs de bureau et portables locaux.

VPN et réseaux privés

Les réseaux privés sont des réseaux qui ne sont disponibles que pour certains serveurs ou utilisateurs. Un VPN, ou réseau privé virtuel, est un moyen de créer des connexions sécurisées entre des ordinateurs distants et de présenter la connexion comme s'il s'agissait d'un réseau privé local. Cela permet de configurer vos services comme s'ils se trouvaient sur un réseau privé et de connecter des serveurs distants via des connexions sécurisées.

Par exemple, les réseaux privés DigitalOcean permettent une communication isolée entre les serveurs du même compte ou de la même équipe au sein de la même région.

Comment améliorent-ils la sécurité ?

L'utilisation de réseaux privés plutôt que publics pour la communication interne est presque toujours préférable étant donné le choix entre les deux. Cependant, étant donné que d'autres utilisateurs du centre de données peuvent accéder au même réseau, vous devez toujours mettre en œuvre des mesures supplémentaires pour sécuriser la communication entre vos serveurs.

L'utilisation d'un VPN est, en fait, un moyen de cartographier un réseau privé que seuls vos serveurs peuvent voir. La communication sera entièrement privée et sécurisée. D'autres applications peuvent être configurées pour faire passer leur trafic sur l'interface virtuelle exposée par le logiciel VPN. De cette façon, seuls les services destinés à être consommés par les clients sur l'Internet public doivent être exposés sur le réseau public.

Est-ce difficile à mettre en œuvre ?

L'utilisation de réseaux privés dans un centre de données doté de cette capacité est aussi simple que d'activer l'interface lors de la création de votre serveur et de configurer vos applications et votre pare-feu pour utiliser le réseau privé. Gardez à l'esprit que les réseaux privés à l'échelle du centre de données partagent l'espace avec d'autres serveurs qui utilisent le même réseau.

En ce qui concerne le VPN, la configuration initiale est un peu plus compliquée, mais la sécurité accrue en vaut la peine pour la plupart des cas d'utilisation. Chaque serveur sur un VPN doit disposer des données de sécurité et de configuration partagées nécessaires pour établir la connexion sécurisée installée et configurée. Une fois le VPN opérationnel, les applications doivent être configurées pour utiliser le tunnel VPN. Pour en savoir plus sur la configuration d'un VPN pour connecter votre infrastructure en toute sécurité, consultez notre tutoriel OpenVPN.

Infrastructure à clé publique et cryptage SSL/TLS

L'infrastructure à clé publique, ou PKI, fait référence à un système conçu pour créer, gérer et valider des certificats permettant d'identifier des individus et de crypter les communications. Les certificats SSL ou TLS peuvent être utilisés pour authentifier différentes entités les unes par rapport aux autres. Après authentification, ils peuvent également être utilisés pour établir une communication cryptée.

Comment améliorent-ils la sécurité ?

L'établissement d'une autorité de certification (CA) et la gestion des certificats pour vos serveurs permettent à chaque entité de votre infrastructure de valider les identités des autres membres et de chiffrer leur trafic. Cela peut empêcher les attaques man-in-the-middle où un attaquant imite un serveur de votre infrastructure pour intercepter le trafic.

Chaque serveur peut être configuré pour faire confiance à une autorité de certification centralisée. Ensuite, tout certificat signé par l'autorité peut être implicitement approuvé. Si les applications et les protocoles que vous utilisez pour communiquer prennent en charge le cryptage TLS/SSL, c'est un moyen de crypter votre système sans la surcharge d'un tunnel VPN (qui utilise aussi souvent SSL en interne).

Est-ce difficile à mettre en œuvre ?

La configuration d'une autorité de certification et la configuration du reste de l'infrastructure à clé publique peuvent impliquer un certain effort initial. De plus, la gestion des certificats peut créer une charge administrative supplémentaire lorsque de nouveaux certificats doivent être créés, signés ou révoqués.

Pour de nombreux utilisateurs, la mise en œuvre d'une infrastructure à clé publique complète aura plus de sens à mesure que leurs besoins en infrastructure augmentent. La sécurisation des communications entre les composants à l'aide d'un VPN peut être une bonne mesure provisoire jusqu'à ce que vous atteigniez un point où la PKI vaut les coûts d'administration supplémentaires.

Si vous souhaitez créer votre propre autorité de certification, vous pouvez vous référer à l'un de nos guides Comment installer et configurer une autorité de certification (CA) en fonction de la distribution Linux que vous utilisez.

Systèmes d'audit de fichiers et de détection d'intrusion

L'audit des fichiers est le processus de comparaison du système actuel avec un enregistrement des fichiers et des caractéristiques des fichiers de votre système lorsqu'il est dans un état correct. Ceci est utilisé pour détecter les modifications du système qui peuvent avoir été autorisées.

Un système de détection d'intrusion, ou IDS, est un logiciel qui surveille un système ou un réseau à la recherche d'activités non autorisées. De nombreuses implémentations IDS basées sur l'hôte utilisent l'audit de fichiers comme méthode pour vérifier si le système a changé.

Comment améliorent-ils la sécurité ?

Semblable à l'audit au niveau du service ci-dessus, si vous voulez vraiment garantir un système sécurisé, il est très utile de pouvoir effectuer des audits au niveau des fichiers de votre système. Cela peut être fait périodiquement par l'administrateur ou dans le cadre d'un processus automatisé dans un IDS.

Ces stratégies sont quelques-unes des seules façons d'être absolument sûr que votre système de fichiers n'a pas été modifié par un utilisateur ou un processus. Pour de nombreuses raisons, les intrus souhaitent souvent rester cachés afin de pouvoir continuer à exploiter le serveur pendant une période prolongée. Ils peuvent remplacer les fichiers binaires par des versions compromises. Faire un audit du système de fichiers vous dira si l'un des fichiers a été modifié, vous permettant d'être confiant dans l'intégrité de votre environnement de serveur.

Est-ce difficile à mettre en œuvre ?

La mise en œuvre d'un IDS ou la réalisation d'audits de fichiers peut être un processus assez intensif. La configuration initiale implique d'informer le système d'audit de toutes les modifications non standard que vous avez apportées au serveur et de définir les chemins qui doivent être exclus pour créer une lecture de référence.

Cela rend également les opérations quotidiennes plus complexes. Cela complique les procédures de mise à jour car vous devrez revérifier le système avant d'exécuter les mises à jour, puis recréer la ligne de base après avoir exécuté la mise à jour pour détecter les modifications apportées aux versions logicielles. Vous devrez également décharger les rapports vers un autre emplacement afin qu'un intrus ne puisse pas modifier l'audit pour brouiller les pistes.

Bien que cela puisse augmenter votre charge d'administration, le fait de pouvoir vérifier votre système par rapport à une copie en bon état est l'un des seuls moyens de s'assurer que les fichiers n'ont pas été modifiés à votre insu. Certains systèmes populaires d'audit de fichiers/de détection d'intrusion sont Tripwire et Aide.

Environnements d'exécution isolés

L'isolation des environnements d'exécution fait référence à toute méthode dans laquelle des composants individuels sont exécutés dans leur propre espace dédié.

Cela peut signifier séparer vos composants d'application discrets sur leurs propres serveurs ou peut faire référence à la configuration de vos services pour qu'ils fonctionnent dans des environnements ou des conteneurs chroot. Le niveau d'isolement dépend fortement des exigences de votre application et des réalités de votre infrastructure.

Comment améliorent-ils la sécurité ?

Isoler vos processus dans des environnements d'exécution individuels augmente votre capacité à isoler tout problème de sécurité susceptible de survenir. De la même manière que les cloisons et les compartiments peuvent aider à contenir les brèches dans la coque des navires, la séparation de vos composants individuels peut limiter l'accès d'un intrus à d'autres éléments de votre infrastructure.

Est-ce difficile à mettre en œuvre ?

Selon le type de confinement que vous choisissez, l'isolation de vos applications peut présenter différents niveaux de complexité. En empaquetant vos composants individuels dans des conteneurs, vous pouvez rapidement obtenir une certaine mesure d'isolement, mais notez que Docker ne considère pas sa conteneurisation comme une fonctionnalité de sécurité.

La configuration d'un environnement chroot pour chaque pièce peut également fournir un certain niveau d'isolation, mais ce n'est pas non plus une méthode d'isolation infaillible car il existe souvent des moyens de sortir d'un environnement chroot. Déplacer des composants vers des machines dédiées est le meilleur niveau d'isolement et, dans de nombreux cas, peut être le moins complexe, mais entraîne des coûts supplémentaires en raison du besoin de machines supplémentaires.

Conclusion

Les stratégies décrites dans ce didacticiel sont un aperçu de certaines des mesures que vous pouvez prendre pour améliorer la sécurité de vos systèmes. Il est important de reconnaître que l'efficacité des mesures de sécurité diminue à mesure que vous attendez pour les mettre en œuvre. Par conséquent, la sécurité ne doit pas être une réflexion après coup et doit être mise en œuvre lors du premier provisionnement de votre infrastructure. Une fois que vous disposez d'une base sécurisée sur laquelle vous baser, vous pouvez alors commencer à déployer vos services et applications avec l'assurance qu'ils s'exécutent dans un environnement sécurisé par défaut.

Même avec un environnement de démarrage sécurisé, gardez à l'esprit que la sécurité est un processus continu et itératif. Une bonne sécurité nécessite un état d'esprit de vigilance et de sensibilisation constantes. Assurez-vous toujours de vous demander quelles pourraient être les implications de sécurité de tout changement et quelles mesures vous pouvez prendre pour vous assurer que vous créez toujours des configurations et des environnements par défaut sécurisés pour votre logiciel.