Suivez-nous

• Analyse des risques
• Par où commencer?
• Le modèle de la responsabilité partagée
• Authentification et données
• Réseau et disponibilité
• Visibilité et protection des logiciels
• Conclusion
• Pour en savoir plus

Analyse des risques

Les applications modernes ont de nombreux rouages. Lorsqu’on entreprend un projet d’envergure, il est important de commencer par en cerner les risques afin d’établir dans quelle mesure il vous exposera. Bien que ses étapes débordent du cadre de ce document (lisez cet article d’Intel ou cet article d’isaca.org pour en savoir plus sur le sujet), les trois aspects principaux qu’une telle analyse devrait couvrir sont

1. la sensibilité;
2. les menaces;
3. et l’impact économique.

Il est impérieux de bien saisir la nature sensible des données qu’on recueille et les risques que cela implique. Sachant cela, vous pourrez évaluer les répercussions d’une faille éventuelle sur l’entreprise.

D’après les rapports annuels sur les atteintes à la sécurité et les incidents, les types d’attaques les plus courants sont les suivants :

• abus de privilèges – exploitation abusive de justificatifs d’identité mal protégés ou dévoilés par accident;
• déni de service distribué (DDOS) – perturbation des services par un essaim d’inforobots;
• injection de code SQL – introduction de chaînes malveillantes dans une base de données au moyen d’un formulaire ou par un point d’accès public.

L’Internet a envahi la vie quotidienne. Les cyberattaques ne peuvent donc que se multiplier. La nature des menaces évolue rapidement, à l’instar des meilleures pratiques en matière de sécurité. Prendre le temps de planifier et de comprendre les risques liés au déploiement d’une application ou d’un service dans un nuage rapportera gros, car il y va de la renommée de l’entreprise et, si celle-ci est compromise, on en payera le prix. Peu d’entreprises peuvent se permettre d’interrompre leurs activités quelques heures ou quelques jours pour régler un problème de sécurité. C’est pourquoi une planification rapide et minutieuse revêt tant d’importance.

Par où commencer?

Peu importe la complexité du projet, sécuriser une application et l’infrastructure dont elle dépend commence quelque part. Nous reviendrons en détail aux principaux points à considérer au départ plus loin dans le tutoriel.

Authentification et autorisations – Comment vous y prendrez-vous pour que les bonnes personnes puissent consulter les données adéquates?

• N’utilisez pas de mots de passe simples. Ne réutilisez pas les mêmes mots de passe
• Privilégiez l’authentification multifactorielle quand la chose est possible
• Respectez le principe du moindre privilège.
• Vérifiez périodiquement la liste de permissions et d’utilisateurs autorisés et supprimez les privilèges superflus.

Protection des données – De quelle façon protégez-vous vos données?

• Encryptez les données lors de leur transmission ou quand on ne s’en sert pas.
• Séparez les données sensibles de celles qui le sont moins.

Accès au réseau – Dans quelle mesure peut-on accéder librement au service? Devrait-il être si accessible?

• Utilisez un pare-feu ou des groupes de sécurité pour restreindre l’accès aux services et éviter les fuites ou une intrusion.
• Utilisez un pare-feu Web pour les applications (WAF) afin de bloquer le trafic malveillant avant qu’il perce la plateforme.

Protection des logiciels – Que faites-vous pour mettre les applications en sécurité à niveau et colmater les vulnérabilités?

• Configurez les machines virtuelles (MV) dans le nuage afin que les mises à jour s’effectuent automatiquement et que les rustines s’exécutent sur le système d’exploitation (OS).
• Recourez à des services d’infonuagique gérés, s’il y a lieu.
• Procédez régulièrement à des essais de pénétration afin de déceler les problèmes.
• Mettez en place une procédure pour suivre les mises à niveau des composants développés par des tiers.

Gestion de la configuration – Comment vous assurez-vous que la configuration est la bonne?

• Renforcez les systèmes et les services (n’activez que les services indispensables).
• Automatisez la configuration et le déploiement des services quand la chose est réalisable.

Journalisation et visibilité – De quelle manière paramétrez-vous l’application pour surveiller les différents composants et détecter si quelque chose cloche?

• Utilisez une plateforme centrale de journalisation pour rassembler et organiser les journaux venant de différentes parties de la plateforme.
• Établissez des alertes et des avis utiles.

Le modèle de la responsabilité partagée

Dans les situations classiques, où l’hébergement est commun, c’est vous qui assumez la responsabilité du système entier, du châssis aux logiciels. Avec l’infonuagique, une partie du système appartient au fournisseur de services. Ce système à double appartenance est ce qu’on appelle le « modèle à responsabilité partagée ».

Le fournisseur de services d’infonuagique utilise des outils internes et son savoir-faire pour procurer à sa clientèle une expérience homogène. La rigidité d’une telle configuration permet au fournisseur de garantir la sûreté de son environnement et d’agir sans délai quand de nouvelles menaces se présentent. Le locataire profite de l’expérience que son partenaire acquise et celui-ci l’aide avec les principaux composants de l’infrastructure. Le revers est qu’ainsi, on perd en souplesse et en liberté dans l’usage des composants en question. Les entreprises comme Amazon RDS proposent des grappes de bases de données qu’elles gèrent de manière uniforme voire des modèles autogérés, mais les services plus spécialisés comme les fonctions Lambda peuvent être assortis de restrictions inattendues.

Le modèle à responsabilité partagée peut couvrir l’ensemble du système. Les infrastructures/plateformes/fonctions/logiciels en tant que service (IaaS/PaaS/FaaS/SaaS) confèrent de plus en plus de responsabilités au fournisseur, cependant les données de l’utilisateur et l’usage sécuritaire de la plateforme restent la responsabilité du locataire. Bien que le fournisseur offre des services sécurisés, une mauvaise configuration peut toujours affecter la sécurité générale de l’environnement.

Une architecture sensible à la sécurité

Beaucoup d’entreprises se bornent à transférer une infrastructure ou une application existante « telle quelle » dans un nuage. Pareille approche n’exploitera toutefois pas tous les avantages qui accompagnent le nuage. En effet l’infrastructure et les applications devront sans doute subir certaines modifications pour surmonter les problèmes de sécurité inhérents à l’infonuagique.

La plupart des architectures en nuage se concentrent sur l’interaction des services. Dans une architecture orientée services (SOA), les applications sont bâties comme autant de services distincts fonctionnant de concert sur les réseaux publics et privés pour qu’une application s’exécute. Les microservices, une variante de cette architecture, séparent les services en tâches les plus simples possibles. Séparer tâches et services de cette manière présente plusieurs avantages. Pour commencer, on contrôle mieux l’utilisation des ressources, dont le nombre peut augmenter ou diminuer avec la demande. Des services d’essai et de surveillance accroîtront aussi sécurité et fiabilité. Advenant un incident ou une panne, des procédures de restauration automatiques pourront entrer en jeu et enverront des avertissements d’erreur. Plus modeste sera le service, plus ténu sera l’impact d’un incident, et le service sera restauré plus vite.

Le « lift and shift » (soulever et déplacer)

L’exemple qui précède (diagramme 2) illustre la stratégie du « lift and shift » (littéralement « soulever et déplacer ») en vertu de laquelle l’infrastructure ou les applications existantes sont transférées sans refonte dans le nuage, souvent sous la forme d’une seule instance. Songez à une maison qu’on détache de ses fondations et qu’on transporte pour être posée à un nouvel endroit. Si elle facilite la tâche des profanes qui souhaitent s’installer dans un nuage, cette stratégie ne tire pas parti des véritables atouts d’une architecture en nuage.

Dans un centre de données, le serveur est un peu comme un château-fort entouré de douves sur lequel règne un seul seigneur. Les nuages sont structurés de façon plus complexe. Des barrières virtuelles et non physiques séparent les clients. Les attaques comme les fausses requêtes des serveurs (SSRF), qui recourent aux services de métadonnées pour contraindre les ressources du nuage à se connecter au mauvais locataire, sont à l’origine des brèches subies par de célèbres entreprises. C’est notamment ce qui est arrivé à Capital One.

Souvent, on déplace l’infrastructure et les applications dans le nuage, sans les modifier, comme si elles avaient été conçues d’un bloc, c’est-à-dire interface utilisateur, données et code de l’application sur la même instance. Quand on procède de la sorte, le piratage ou l’exploitation d’une partie quelconque du bloc peut compromettre la totalité du système. Renforcer le système d’exploitation et les services (modifier les configurations par défaut pour en rehausser la sécurité et la performance) réduira la surface d’attaque et protègera relativement bien le système. Néanmoins, une erreur de configuration dans un service pourra toujours compromettre les autres services, voire l’instance au complet.

Même si ce n’est pas l’idéal, une mesure obligatoire pour sécuriser les systèmes monolithiques de ce genre consiste à envelopper le système de couches supplémentaires. Le diagramme 2 montre une application incluant des modules de sécurité au niveau du serveur Web et du cadre de l’application, un bon point de départ, car, ainsi, certains attaquants seront repoussés lorsqu’ils s’en prennent au serveur. De plus, on peut accentuer ces mesures en recourant à des filtres du nuage pour valider le trafic avant qu’il atteigne le serveur. Les procurations sensibles à l’application et les pare-feu Web pour applications (WAF) constituent une première ligne de défense en filtrant les attaques les plus courantes sur le Web avant qu’elles parviennent à l’application.

Architecture naturelle d’un nuage

La configuration du diagramme 3 montre le déploiement d’un pare-feu Web pour applications (WAF) par le fournisseur de services d’infonuagique. Le WAF crée des journaux qui sont ensuite analysés. Un programme d’automatisation reposant sur les incidents modifie les règles du pare-feu à la volée et lance des alertes qui font ressortir les menaces davantage. Les services d’applications (derrière le pare-feu) sont séparés par des groupes de sécurité qui n’établissent de connexion qu’en cas de nécessité. Une telle architecture permet de tirer avantage des outils naturels de l’infonuagique comme l’équilibrage de la charge, pour préserver la grande disponibilité des applications, et l’analyse du trafic, pour détecter les menaces.

Bien qu’elle soit plus complexe, cette approche engendre aussi une boucle de rétroaction permettant de contrôler de façon dynamique les règles de sécurité qui déterminent qui aura ou pas accès à une application (le WAF, dans le cas qui nous intéresse). Puisque chaque demande est sauvegardée et analysée, le WAF peut modifier les règles de sécurité, de sorte que l’application s’adapte à la majorité des attaques en temps réel.

À l’intérieur du périmètre sécurisé par le WAF, les composants sont isolés les uns des autres, dans leur propre groupe de sécurité. Les répercussions sont donc minimisées, advenant une faille. Nous approfondirons cet aspect du cadre « aucune confiance » dans la partie « Autorisations et disponibilité ».

Authentification et données

L’authentification et les autorisations ne sont pas traitées de la même manière dans un nuage et un centre de données. On le doit en partie à l’architecture naturelle du nuage, qui exige la vérification d’un plus grand nombre de justificatifs, mais aussi à la nature partagée du nuage public, qui restreint la capacité d’isoler les réseaux de gestion. En effet, les systèmes mêmes les plus sûrs peuvent être compromis quand les comptes sont protégés par un mot de passe trop simple.

On prendra particulièrement soin de configurer et gérer les données stockées dans l’infrastructure. Outre les attaques qui exploitent les vulnérabilités SSRF (Server-Side Request Forgery) déjà mentionnées, le stockage des données dans un nuage naturel peut facilement introduire des erreurs de configuration qui n’existeraient pas dans une infrastructure physique classique. En effet, dans un nuage, la distinction entre accès privé et accès public peut se résumer à une simple case que l’on coche.

Authentification

L’authentification est le processus qui consiste à vérifier l’identité d’un utilisateur ou d’un service. Une fois cette identité vérifiée, l’utilisateur se voit accorder ou refuser l’accès aux ressources qu’il réclame, en fonction des permissions établies.

L’usage de mots de passe simples et les méthodes d’authentification à un facteur sont des problèmes courants lorsqu’on configure l’authentification. Les serveurs publics sont souvent la cible des attaques, car un mot de passe peut être deviné ou dérobé. On préconise donc vivement des mesures de vérification supplémentaires à la connexion – ce qu’on appelle l’authentification multifactorielle (MFA) -, soit un deuxième mot de passe, des paramètres biométriques ou l’envoi d’un texto au téléphone de l’utilisateur. La MFA interdit virtuellement les accès non autorisés, les probabilités qu’un attaquant franchisse toutes les mesures de sécurité étant extrêmement faibles.

En plus de sécuriser l’accès des utilisateurs, il convient d’examiner les mesures qui sécuriseront la connexion aux services. L’encryptage de la clé publique sécurisera les services comme les protocoles SSH ou les réseaux privés virtuels (VPN), alors que des jetons de sécurité authentifieront les communications qui transitent par une API. Les clés de ce genre sont plus sûres qu’un mot de passe, car il n’y en a jamais deux pareilles (elles sont conçues pour un seul utilisateur ou appareil) et il est facile d’en changer.

Autorisations et disponibilité

L’autorisation est le moyen par lequel on établit à quelles ressources un compte a accès. Quand un utilisateur tente une action après avoir été authentifié, le système vérifie les privilèges associés à son compte pour déterminer si ladite action doit être permise ou pas.

Le cadre « aucune confiance » suscite passablement d’intérêt depuis quelques années. L’approche traditionnelle du « château-fort entouré de douves » considère que les ressources du réseau protégées par le périmètre sécurisé sont fiables. Avec la politique « aucune confiance », en revanche, toutes les entités hors du périmètre sécurisé doivent obtenir une autorisation. Le « refus par défaut » en est une variante extrême, car il bloque automatiquement les communications, sauf celles qui font l’objet d’une permission expresse. Les politiques de ce genre permettent de stocker dans un nuage (une infrastructure non fiable) des ressources sensibles avec lesquelles ne pourront communiquer que d’autres ressources explicitement autorisées à le faire.

Le contrôle des accès d’après les attributs ou un rôle (ABAC/RBAC) est une autre approche de type « aucune confiance » ou « refus par défaut ». Dans ce cas, l’utilisateur n’a accès qu’à ce dont il a besoin pour son travail. Une base de données, par exemple, ne sera souvent accessible qu’à partir de l’application proprement dite. L’utilisateur n’aura pas accès au reste du réseau. De nombreux services d’infonuagique adoptent le « refus par défaut » comme norme, ce qui oblige l’utilisateur à configurer ou à autoriser manuellement les sources auxquelles il se connecte.

Outre les restrictions associées au réseau, une bonne précaution consiste aussi à limiter les actions d’un compte. Quand un service alimente une base de données et qu’un autre la consulte, l’accès devrait se limiter à ce dont le service en question a besoin. De cette façon, les erreurs de code éventuelles n’auront pas de trop vastes répercussions et on atténuera l’impact général des justificatifs qui pourraient avoir été compromis.

Confidentialité et protection des données

Le stockage de données sensibles comme les renseignements permettant d’identifier une personne (RIP) ou le numéro des cartes de crédit suppose certaines responsabilités juridiques. L’encryptage contribue beaucoup à garder de telles informations en sûreté pendant leur transit (leur transmission au client ou à un autre service) ou quand elles sont inactives (durant leur stockage).

Les données « au repos » gardées hors de la plateforme (celles, par exemple, gardées en mémoire ou stockées dans un service comme AWS Simple Storage Service (S3) ou Office 365/SharePoint) doivent elles aussi être sécurisées. Beaucoup de fournisseurs de services d’infonuagique offrent des services d’encryptage de volumes et d’objets. Automatiser un tel processus facilitera la sécurisation des données délicates. Les volumes chiffrés ne peuvent être restaurés après destruction ou lorsque la clé de chiffrement a été perdue – ce qui réduit aussi les risques de divulgation accidentelle.

Outre l’encryptage, l’abstraction des RIP dans une base de données active permettra une séparation plus facile des données sensibles. La segmentation recourt à des jetons uniques plutôt qu’aux RIP proprement dits, ce qui autorise la séparation des données personnelles, qu’on conservera dans un compartiment distinct sécurisé. Le jeton donne accès aux RIP gardés dans le service séparé, et sécurisé, lorsqu’on en a besoin.

Réseau et disponibilité

Quel que soit le type de nuage, c’est le fournisseur qui gère le réseau physique. On bénéficie donc de la plupart des mêmes avantages que lorsqu’on confie les calculs ou le stockage à un tiers : plus besoin de gérer les pannes ni les activités du matériel. Cependant, les réseaux virtuels qu’utilisent les instances pourraient mériter qu’on y accorde attention.

La manière dont le réseau est configuré joue un rôle déterminant dans une architecture sensible à la sécurité. Une bonne configuration diminuera les risques de pannes et permettra d’isoler les services sensibles. Certes, une panne n’est pas aussi grave qu’une faille, mais la moindre interruption coûtera de l’argent. Le réseau devrait être configuré de manière à être assez résilient afin que vous ayez le temps utilisable dont vous avez besoin tout en étant assez sûr pour vous mettre à l’abri du trafic imprévu.

Isolement du réseau

La sécurité du nuage débute par un réseau sûr. L’utilisateur aura le contrôle absolu des réseaux secondaires, des groupes de sécurité et de l’architecture générale. Pareille souplesse autorisera la séparation du trafic et la maîtrise du débit, mais cela pourrait créer la confusion et entraîner des erreurs de configuration. Les réseaux publics devraient être traités comme des zones démilitarisées (ZDM). La ZDM du réseau proposera des services faisant face au public auxquels le réseau interne, sécurisé, n’accorde pas une entière confiance, tout en permettant des connexions précises, après autorisation. Il y aura donc une zone tampon entre l’Internet public et les services internes.

On pourra se servir des réseaux privés et des réseaux secondaires comme une enclave protégée à laquelle où pourra accéder un certain type de trafic (la grappe de bases de données nécessaire pour reproduire les données sur chaque nœud de la grappe, par exemple). Pareille opération pourrait s’effectuer sur un réseau privé secondaire dédié qui recourra à des groupes de sécurité afin de n’autoriser que les activités de reproduction. En ne plaçant que les serveurs nécessaires aux bases de données sur ce réseau, les opérations de reproduction se feront à l’insu des autres réseaux publics ou privés.

S’il faut communiquer avec une ressource protégée sur un réseau public, on sécurisera la communication en la chiffrant avec le protocole SSH ou un réseau privé virtuel (VPN), par exemple. Les outils de ce genre créent un tunnel sûr à travers les protocoles de communication moins sûrs comme le Remote Desktop Protocol (RDP) ou l’informatique virtuelle en réseau (VNC). En faisant passer les communications non sécurisées à travers un tunnel sécurisé, on empêchera les inconnus de fureter parmi elles et d’intercepter des renseignements sensibles ou des justificatifs d’identité.

Intégrité de la communication

Quand le trafic doit traverser un réseau public, l’encryptage assure une sécurité de base. Les certificats SSL ne font pas que chiffrer l’information, ils valident les identités. Quand le client établit une connexion sécurisée, le serveur lui remet un certificat et une « clé » qu’il utilise pour vérifier l’identité du serveur auquel il s’adresse. La clé encrypte la communication d’une manière que le serveur original est le seul à pouvoir décrypter.

Quoique l’encryptage soit un processus assez direct, il n’en va pas autant de la vérification des identités. En effet, pour obtenir un certificat valable, l’exploitant du service doit vérifier la propriété du domaine. C’est une tierce partie, l’autorité de certification (CA), qui procède à la vérification et délivre le certificat, avec une clé privée que doit installer l’exploitant.

Quand on se connecte à un service sécurisé grâce à un certificat, ce dernier est validé de diverses manières. On vérifie auprès de la CA émettrice si elle a bien délivré le certificat puis on détermine si la période de validité de ce dernier n’a pas expiré. Enfin, on vérifier le domaine du certificat pour s’assurer qu’il correspond au domaine recherché. Si l’un de ces contrôles échoue, le certificat se voit attribuer une marque qui l’identifie comme douteux.

Les services comme Let’s Encrypt (une autorité de certification automatique gratuite et ouverte) permet d’obtenir et de maintenir aisément un certificat valable pour les sites et les services Web. Autre solution pour un usage interne, on pourrait mettre sur pied sa propre CA et attester soi-même les certificats. Dans un tel cas, tout certificat qui ne figure pas sur la liste approuvée dans le navigateur ou l’ordinateur de l’entreprise serait rejeté. Certes, le certificat pourrait encore encrypter les communications, mais l’identité du serveur ne pourrait être vérifiée avec certitude. C’est pourquoi on a besoin d’un certificat public attesté valable avant de passer à la production.

Disponibilité

Par « disponibilité », on entend la capacité de l’application à fonctionner de la manière prévue. Le déni de service (DoS) est une cyberattaque populaire ayant pour but de rendre l’application indisponible et d’empêcher les personnes autorisées à le faire à utiliser le service. Même si le service continue de fonctionner partiellement, les attaques de ce genre en ralentiront les réponses ou créeront un écran de fumée derrière lequel se dérouleront d’autres activités malveillantes.

L’Internet des objets (IdO) et l’engouement pour l’informatique en périphérie de réseau ont rendu la variante distribuée de telles attaques (DDoS) plus fréquentes et plus dangereuses. Les systèmes compromis s’ajoutent à de vastes réseaux d’inforobots (regroupements lâches de systèmes asservis sous le contrôle d’un pirate) et sont orchestrés pour expédier une masse de pourriels au site ciblé. Selon l’importance de l’assaut, il peut s’ensuivre une perturbation plus ou moins grave du service. Il est difficile de contrer les attaques de ce genre, car elles émanent de diverses régions et peuvent inonder la largeur de bande de l’infrastructure. Une des plus importantes attaques DDoS reconnue était de l’ordre de 1,2 Tbps (térabits par seconde) et a mis à terre une grande partie de l’Internet aux États-Unis et en Europe. Si vous dispensez un service 24/7/365, assurez-vous que son architecture résistera aux attaques et aux pannes.

Beaucoup de services d’infonuagique proposent des solutions pour atténuer les attaques de cette nature. La plus courante est le pare-feu Web pour applications (WAF), que l’on combine à un équilibreur de charge et à un réseau de diffusion du contenu (CDN). Pareille configuration dotera l’application de serveurs par procuration robustes et sécurisés (par ex., CloudFlare, CloudFront) qui intercepteront et filtreront les communications malveillantes. Certes, le débit de votre serveur se trouvera restreint, soit de 1 à 10 Gbps (gigaBits par seconde), mais le WAF filtrera un grand nombre des communications malveillantes avant qu’elles atteignent le système, qui fonctionnera donc normalement pendant l’attaque. Si vous êtes tenu de vous conformer à la norme de sécurisation des données de l’industrie des paiements par carte (PCI-DSS), vous devrez recourir à un WAF.

En planifiant la disponibilité, rappelez-vous qu’il y a une distinction entre une infrastructure de « grande disponibilité » et une autre « tolérant les pannes ». La première est conçue pour que les opérations se poursuivent même quand un service tombe en panne, mais la performance ou le service peuvent se détériorer le temps que la situation se rétablisse; la seconde est conçue pour garantir une fonctionnalité complète en dépit de pannes multiples, l’idée étant que rien n’interrompe l’expérience de l’utilisateur. La seconde infrastructure exige souvent une plateforme entièrement distincte, capable de prendre la relève en acheminant le trafic qui ne peut traverser la plateforme principale, en panne. Si elle s’avère plus onéreuse, pour certaines applications, pareille infrastructure pourrait coûter moins cher qu’une interruption du service.

Visibilité et protection des logiciels

La visibilité et la maintenance des logiciels jouent un grand rôle dans l’efficacité et la longévité d’une application. Les projets modernes intègrent souvent les logiciels de tierces parties sous forme de bibliothèques, de cadriciels ou de modules. Ces composants doivent être gardés à niveau, comme le reste de l’application, mais bénéficient des avantages que procurent le développement et la vérification des mises à niveau par des équipes externes. Selon la place occupée dans le modèle à responsabilité partagée, il se pourrait que vous deviez procéder vous-mêmes aux mises à niveau que requiert votre application.

Par ailleurs, une surveillance et une journalisation adéquates maintiendront la plateforme en bon état et tiendront votre équipe au courant de la situation au moyen d’alertes qui lui signaleront les modifications et les erreurs avant – il faut l’espérer – qu’elles nuisent à la disponibilité de l’application.

Maintenance et configuration

Garder les composants de l’application à niveau n’est pas aisé, dans le nuage comme à l’extérieur de celui-ci. Selon les responsabilités qui vous incombent (voir la partie sur le modèle à responsabilité partagée), il se pourrait que vous deviez mettre à niveau le système d’exploitation, les bibliothèques communes, les cadriciels de l’application et, cela va de soi, le code de l’application proprement dite. Les logiciels périmés posent un sérieux risque pour la sécurité et sont une des principales causes à l’origine des méfaits reposant sur l’exécution d’un code à distance. Dès que la vulnérabilité d’un cadriciel ou d’une bibliothèque partagée est connue, des inforobots commencent à en décortiquer les propriétés Web et les plages d’adresses IP, en quête de cibles à exploiter. C’est pourquoi il est si important d’actualiser les logiciels, surtout les applications Web.

Outre les mises à niveau, le « renforcement » est un autre processus dont il ne faut pas négliger l’importance. Les paramètres par défaut du système d’exploitation et des services ne conviennent pas toujours aux conditions particulières à la production. Un renforcement actualisera la configuration par défaut des services et des composants sous-jacents (notamment celles du système d’exploitation et de la plateforme réseau) sous l’angle de la sécurité. Le renforcement devrait toujours faire partie du plan de développement, de manière à ne pas être négligé.

Une façon courante de s’assurer que les paramètres sont les bons et concourent à la sécurité de l’ensemble consiste à effectuer un test de pénétration. Beaucoup d’outils de source libre (Kali ou OpenVAS, par exemple) permettent d’effectuer de tels tests à l’interne, mais nous recommandons vivement de retenir les services d’un professionnel indépendant ou d’une agence. En effet, si de nombreuses vérifications qu’autorisent de tels outils sont automatisées, il n’en va pas autant de l’analyse et de l’interprétation des résultats, ni des mesures qui en découlent. En y mettant un peu d’efforts, on tirera quelque chose d’utile de ces rapports, mais on ne pourra jamais remplacer le savoir-faire d’un professionnel compétent.

Visibilité et centralisation des journaux

Centraliser la journalisation est une étape élémentaire si l’on veut sécuriser une infrastructure moderne et bien cerner les difficultés que cela implique. Une plateforme de journalisation centrale permettra de mieux suivre les incidents d’un système et d’un service à l’autre. Pareille centralisation a son importance, car lorsqu’un système est infecté, les journaux peuvent avoir été modifiés eux aussi. Pour que la centralisation donne de bons résultats, les codes d’erreur, les unités de mesure et le formatage des journaux devraient être raisonnablement uniformes et instructifs. La plupart des fournisseurs de services d’infonuagique proposent des services de journalisation centralisés, mais les solutions indépendantes offrent parfois des fonctionnalités supplémentaires qui auront leur utilité pour l’équipe.

Outre la journalisation, une surveillance active de la plateforme vous renseignera sur la vitalité et le comportement de vos systèmes, ce qui s’avère particulièrement utile pour repérer et résoudre les problèmes. Une telle surveillance favorisera l’adoption de solutions d’une grande disponibilité articulées sur les incidents. En d’autres termes, l’état de l’application déclenchera automatiquement des remèdes, comme la reconstitution du service ou la suppression d’un nœud dans une grappe active. On devrait aussi configurer les alertes pour qu’elles signalent une utilisation anormale des ressources ou une authentification douteuse. Une bonne règle générale est que l’alerte indique tout ce qui exerce une influence sur la disponibilité ou pourrait exiger une intervention manuelle, même s’il y a des automatismes en place pour y remédier.

Conclusion

Tous les modèles de sécurité se composent de couches de composants raccordés entre eux ou séparés. Le diagramme 4 illustre les couches de sécurité typiques d’une plateforme en nuage.

Vous pouvez vous servir de ce diagramme pour examiner vos responsabilités et les points névralgiques. Dans le cadre de la planification d’urgence, on dressera la liste des composants de l’application situés dans chaque couche. Ensuite, selon les responsabilités qui vous incombent, on déterminera comment prévenir une brèche ou relancer le système après une panne.

Dernières réflexions

Les outils de protection et les pratiques exemplaires en sécurité évoluent constamment, mais les principes de base sont immuables. Encrypter, isoler, authentifier, surveiller : tels sont les fondements d’une architecture sûre, qu’il s’agisse d’un nuage ou d’un centre de données. Les méthodes de protection modernes ne sont souvent qu’un prolongement de ces principes, dont l’utilité a été poussée au maximum par l’automatisation. Désormais, on peut automatiser des tâches qui exigeaient naguère une intervention manuelle (l’encryptage des données, par exemple) et profiter des services d’infonuagique qui gèrent une grande partie des fonctions technologiques. Le partage des responsabilités dans le nuage rend une telle infrastructure plus abordable et plus sûre.

Bâtir une architecture sécuritaire demeure la responsabilité de chacun. Pour être efficace, la stratégie s’appuiera sur des politiques, des procédures et la sensibilisation. Les fournisseurs de services d’infonuagique proposent des solutions qui répartissent ce fardeau, mais chacun doit comprendre le rôle qu’il joue sur ce plan et connaître ses points névralgiques. Qu’on crée une petite application à une instance ou une imposante architecture reposant sur des microservices ne change rien à la chose : il faut planifier très tôt la sécurité et faire le point régulièrement. Séparer des systèmes étroitement liés entre eux n’est pas facile une fois la machine en branle. Il est capital de commencer par bien sécuriser le système et isoler les services, car il est fort probable qu’on ne pourra revenir en arrière. En investissant très tôt dans la sécurité, on évitera les interruptions, préservera la réputation de l’organisation et épargnera les frais qui découlent de la reconstruction des applications existantes pour mieux les sécuriser. N’importe quelle construction doit reposer sur des fondations solides.

La surveillance facilitera une architecture articulée sur les événements. Avec une maintenance homogène et des règles de sécurité dynamiques, on repèrera maintes difficultés avant qu’elles deviennent problématiques. En suivant et en vérifiant les autorisations relatives aux services, on découvrira les erreurs de configuration de manière à éviter une brèche, si elles sont identifiées assez tôt. Enfin, tester et surveiller le fonctionnement des services permettra à l’automatisation de régler les problèmes avant qu’ils ne réduisent la disponibilité. Les alertes transmises à l’équipe après un incident permettront d’en élucider l’origine. Avec une telle visibilité, on pourra adopter des mesures supplémentaires, s’il y a lieu, pour éviter la répétition des mêmes erreurs à l’avenir.

Les risques qu’une cyberattaque pose pour l’organisation ne cessent d’augmenter, mais il en va autant des outils pour y remédier. Dans la guerre dont données sont l’enjeu, le fournisseur de services d’infonuagique et les outils qu’il procure constituent votre première ligne de défense. Examinez les pratiques exemplaires décrites dans ce document et rappelez-vous que sans planification et exécution adéquates, les mesures de sécurité même les plus pointues peuvent échouer elles aussi.

Pour en savoir plus

Nous vous suggérons vivement de prendre connaissance des ressources complémentaires que voici.

• Guide de la Cloud Security Alliance (en anglais seulement)
• Guide du Canadian Chapter of the Cloud Security Alliance (en anglais seulement)
• Open Web Application Security Project (OWASP) (en anglais seulement)
• Guides d’application technique du Department of Defense Security (en anglais seulement)
• Diagrammes de l’architecture d’AWS (en anglais seulement)