Encryptage, isolement, authentification et surveillance sont les pierres angulaires d’une architecture sécuritaire, que ce soit dans un nuage ou un centre de données. Les organisations qui envisagent un projet de déploiement dans un nuage se butent à des difficultés variées, l’un des principaux étant la sécurité. Que votre organisation s’apprête à exploiter l’infonuagique ou reparte à neuf, gérer et atténuer les risques n’est pas une mince affaire.
Apprenez-en plus sur les pratiques exemplaires en sécurité dans l’infonuagique
Avec ce tutoriel, nous voulons vous inculquer des rudiments solides qui vous apprendront à vous protéger dans le milieu contemporain de l’infonuagique. Pour cela, nous aborderons les sujets les plus importants que sont l’architecture d’un nuage, l’authentification, la réseautique, la journalisation et le fonctionnement des applications à l’intérieur de ces paramètres. De cette façon, les membres de votre équipe et vous vous poserez les questions adéquates au moment d’échafauder l’infrastructure de votre projet dans le nuage. Ensuite, le tutoriel présentera quelques modèles courants en sécurité que vous pourrez adopter.
Pour illustrer ces concepts, nous utiliserons une entreprise fictive baptisée « Pretendco », jeune pousse spécialisée dans les données scientifiques sur l’espace ne comptant que cinq employés et qui souhaite créer un modèle d’apprentissage automatique puis le partager avec ses clients capables d’en télécharger une image afin de l’intégrer à leurs services et d’établir si la formation assistée par ordinateur leur convient ou pas.
Sensibilité et analyse des risques
Authentification et autorisations
Architecture sensible à la sécurité
Modèle du fromage suisse (défense en profondeur)
Par où commencer?
La sécurité d’un projet est cruciale, aussi devrait-on y songer dès que commence la planification. La meilleure façon de le faire consiste à déterminer quels éléments du projet devront être protégés. Ne perdez donc pas de vue la sécurité quand vous prendrez des décisions sur ce qui suit :
- votre architecture;
- les données recueillies ou utilisées;
- les éléments qui pourraient être compromis sciemment ou accidentellement.
En confirmant les hypothèses émises à la genèse du projet, on saura où des mesures de contrôle adéquates sont nécessaires en vue d’atténuer des risques.
En ce qui concerne Pretendco, nous supposerons que le minimum nécessaire sur le plan de la sécurité consiste à sécuriser l’infrastructure en nuage qui hébergera les données et les modèles de formation. L’entreprise devrait également sécuriser les éléments qui font face à l’extérieur ou au public, c’est-à-dire la manière dont les clients peuvent transmettre en toute sécurité leurs données pour que Pretendco les analyse.
Sensibilité et analyse des risques
Lorsque vous examinerez vos services, faites-le sous les angles de la sensibilité, des menaces et des retombées économiques. Déterminez quelles données seront transmises et conservées, de même que le cycle de vie complet de ces dernières. Saisir l’importance de chaque aspect vous aidera à établir quels compromis on doit faire pour protéger les données, votre projet, l’entreprise et sa clientèle.
Nous n’aborderons pas la manière exacte d’effectuer une telle analyse, car cela déborde du sujet de ce tutoriel. Pour vous familiariser davantage avec l’analyse des risques cependant, nous vous recommandons de lire cet article d’Intel ou celui de l’Information Systems Audit and Control Association (ISACA).
Premiers éléments à analyser
Plusieurs aspects communs au déploiement doivent absolument être auscultés si l’on veut déterminer les meilleurs moyens de gérer la sécurité. Par la suite, nous les examinerons en profondeur et vous présenterons diverses approches pouvant être combinées afin d’atténuer les risques.
Les six catégories que voici correspondent à des aspects cruciaux du déploiement.
- Authentification et autorisations – Que ferez-vous pour que seules les bonnes personnes aient accès aux données requises à l’interne et à l’externe?
- Protection des données – Comment protégerez-vous les données?
- Accès au réseau – Dans quelle mesure peut-on accéder au service et à ses composantes? L’accès devrait-il être si facile?
- Sécurité des logiciels – De quelle façon appliquerez-vous les rustines de sécurité et atténuerez-vous les vulnérabilités connues?
- Gestion de la configuration – Comment vérifierez-vous que votre configuration est telle comme vous l’espériez et avec quelle facilité pourrez-vous la modifier si on découvre une erreur?
- Journalisation et visibilité – Comment surveillez-vous les activités imprévues?
Autre importante considération, les erreurs et les prouesses les plus fréquentes ne ressemblent en rien à ce qu’on peut voir dans les superproductions hollywoodiennes. En effet, selon les rapports annuels sur les brèches et les incidents en sécurité, les formes de piratage les plus courantes sont les attaques de l’intercepteur, les dénis de service, l’abus de privilèges (identifiants découverts ou mal protégés), les bogues, le scriptage entre sites et les rançongiciels.
Chaque type d’attaque exige une approche différente. Cependant, toutes ont des points en commun et il existe des façons de les prévenir ou d’en atténuer les conséquences. Ces attaques surviennent parce qu’une erreur se glisse aisément dans un système complexe, et le déploiement d’une application dans un nuage n’y échappe pas. Prendre le temps de planifier et de bien saisir les risques rapportera gros, car la réputation de l’entreprise est en jeu et réparer des erreurs coûte cher. Peu d’entreprises peuvent se permettre d’interrompre leurs activités des heures ou des jours entiers pour résoudre un problème de sécurité. C’est pourquoi, une planification hâtive et générale est primordiale.
Aux fins de ce tutoriel, nous formulerons quelques hypothèses sur l’analyse des risques effectuée par Pretendco. L’entreprise souhaite protéger ses données internes et celles fournies par ses clients. La sensibilité de ces données et du programme ne justifie toutefois pas des mesures additionnelles comme l’isolement du système ou le débranchement d’Internet. Connaissant les besoins de Pretendco en matière d’accès et d’exposition, et sachant que l’entreprise ne recueillera que peu de données, suivre les pratiques exemplaires qui ont été normalisées devrait suffire.
De quoi suis-je responsable?
Avant d’aborder plus en détail les six catégories mentionnées précédemment, il importe de voir en quoi le déploiement dans un nuage diffère ou pas d’un déploiement physique usuel dans un local ou dans une installation en colocation.
En infonuagique, il existe une différence fondamentale sur le plan de la sécurité physique. Le nuage est comme une installation colouée. Vous y placez votre équipement, dont la protection vous incombe. Quand on recourt à des services comme l’infrastructure (IaaS) ou les logiciels (SaaS) en tant que services (Amazon EC2 et Amazon Redshift, respectivement), on cède la maîtrise de certains éléments. Pareil compromis signifie des économies au niveau des coûts, mais aussi que l’on dépendra d’un tiers, extérieur à l’entreprise, pour mettre l’infrastructure de cette dernière à l’abri du feu et d’une intrusion par un inconnu ou une entité quelconque.
Notez bien que si vous confiez l’exécution du service à quelqu’un d’autre, vous contrôlerez toujours la façon dont on l’utilise ou le protège. Par exemple, bien qu’Amazon Web Services garantisse la sécurité physique de l’infrastructure, il vous revient de veiller à ce que les clés API soient gardées en lieu sûr et qu’on s’en serve de la façon appropriée (réglementée).
Maintenant que vous connaissez vos responsabilités et savez quels aspects demeurent sous votre contrôle, attardons-nous à la question « comment intégrer la sécurité au déploiement ou à l’application? »
Authentification et autorisations
Par « authentification », on veut dire prouver qu’une entité est bien ce qu’elle prétend être, alors que le terme « autorisation » désigne le système permettant à la personne authentifiée de réaliser ou pas ce qu’elle aimerait faire. Faire en sorte que seuls les utilisateurs authentifiés et dûment autorisés aient accès à vos services est une étape capitale dans l’atténuation des risques.
Sans authentification ni autorisation adéquates avant ou pendant que l’application utilise les services, une erreur est aisément commise.
Pour l’éviter, voici ce que nous préconisons.
- N’employez pas de mots de passe trop simples, ne réutilisez pas les mots de passe et préférez les clés et les certificats aux mots passe pour l’authentification.
- Dans la mesure du possible, privilégiez l’authentification multifactorielle quand la connexion est établie par un être humain.
- Appliquez le principe du moindre privilège – l’utilisateur qui n’a accès qu’au strict minimum ne pourra exécuter de commande imprévue.
- Évitez de partager les comptes entre utilisateurs ou services.
- Passez régulièrement en revue les autorisations et ceux à qui vous les avez accordées, abolissez les privilèges inutiles.
- Dites « non » par défaut – à moins qu’on le permette explicitement, tout comportement anormal devrait être proscrit. C’est ce que font souvent les fournisseurs de services d’infonuagique. Les règles du pare-feu sont configurées de la sorte au départ, ce qui vous oblige à autoriser/configurer manuellement l’accès à des sources spécifiques.
Voici ce que cela signifie que nos amis fictifs de l’entreprise Pretendco :
- Ils s’assureront que vous ne pouvez vous connecter à leurs instances qu’avec une clé SSH afin qu’on ne puisse deviner votre mot de passe;
- Ils configureront quelques comptes (admin, par exemple) sur leur application avec l’authentification bifactorielle (on peut recourir pour cela à des fournisseurs indépendants comme Authy ou Auth0, ou utiliser une banque de mots de passe temporaires uniques);
- Ils veilleront à ce que le même mot de passe ne s’applique pas à différents services afin qu’on ne puisse s’en resservir pour créer une brèche ailleurs (HaveIBeenPwned.com est une ressource fabuleuse pour surveiller l’imminence d’une attaque par abus d’identifiants);
- Ils produiront des mots passe aléatoires que stockeront des gestionnaires de mots de passe comme 1Password ou Hashicorp Vault afin de freiner les attaques par usage de dictionnaire.
Pretendco pourrait envisager d’autres approches, mais cela serait exagéré pour un service aussi rudimentaire. Le modèle à confiance nulle ou le contrôle d’accès basé sur les rôles (RBAC) sont des concepts que connaissent bien les grandes entreprises et qui permettent de mieux gérer les authentifications et les autorisations dans l’organisation. Chaque approche enlève d’une manière légèrement différente un peu de pouvoir à l’agent malfaisant qui parviendrait à accéder au service grâce à une fausse autorisation, à la fuite d’un mot de passe ou à l’absence de protection par mot de passe.
Protection des données
Stocker des données sensibles comme les informations permettant d’identifier quelqu’un ou le numéro d’une carte de crédit vient avec des responsabilités légales. L’encryptage est un moyen important pour mettre pareilles données à l’abri le temps qu’elles parviennent à un client ou à un service (par SSL/TLS, par exemple), ou quand elles sont « au repos » (encryptage sur disque).
Les données « au repos » hors de la plateforme active, les données de sauvegarde ou celles conservées dans des services comme S3 et SharePoint, par exemple, doivent elles aussi être protégées. Beaucoup de services d’infonuagique proposent l’encryptage des volumes ou des objets. L’automatisation de ce processus permet de sécuriser plus facilement les données. En effet, un volume encrypté ne pourra être récupéré après avoir été supprimé ou si l’on perd la clé de chiffrement, avec la réduction des risques d’une exposition accidentelle que cela suppose.
Outre l’encryptage, l’abstraction des informations personnelles dans une base de données facilite la ségrégation des données sensibles. La segmentation utilise des jetons plutôt que les informations personnelles, ce qui permet de séparer celle qui sont confidentielles de celles qui ne le sont pas, et de les garder dans une enclave distincte, plus sûre. Le jeton permettra de récupérer ces données du service sécurisé lorsqu’on en a besoin.
La plupart des services d’infonuagique vous proposeront d’encrypter les données stockées sur disque et s’assureront que celles transférées d’un service à l’autre ne le soient pas « en clair », mais par HTTPS ou par une autre méthode de chiffrement, ce qui atténuera les risques de vol durant le transfert.
Pour Pretendco, ceci signifie :
- s’assurer que les données de formation se trouvent dans un volume encrypté;
- établir la connexion à la base de données par SSL/TLS;
- empêcher qu’on fouine dans le trafic en connectant les clients à l’interface Web par HTTPS.
Accès au réseau
Dans tous les nuages, peu importe leur modèle, c’est le fournisseur qui gère physiquement le réseau. Les avantages qu’on en retire sont pour la plupart similaires à ceux obtenus quand on confie le calcul et le stockage physique des données à un tiers. Bref, c’est le fournisseur qui assume la responsabilité d’une panne et gère entièrement l’exploitation du matériel. Toutefois, les réseaux virtuels qu’utilisent les instances méritent peut-être votre attention.
La configuration du réseau est indissociable de sa sécurisation. En effet, un réseau correctement sécurisé réduira à la fois l’exposition et les risques. On y parviendra en utilisant les réseaux privés et les réseaux secondaires comme des enclaves sécuritaires dans lesquelles ne circulera qu’un trafic prédéterminé. Des pare-feu et des groupes de sécurité pourront en restreindre l’accès, conformément au principe du moindre privilège, de telle sorte que seules les bonnes adresses IP auront accès aux différents services.
La façon d’y parvenir peut se résumer à s’assurer que les ports (SSH) du service ne soient pas accessibles à tout le monde par l’Internet, afin de restreindre les attaques par piratage du mot de passe. On pourrait aussi créer une enclave de sécurité dans laquelle seuls les serveurs de la base de données converseront entre eux.
Enfin lorsqu’il est question d’accès au réseau, il importe d’envisager l’application des normes relatives aux communications chiffrées (SSH, RDP ou VNC avec SSL). Si on ne peut se passer de communications non sécurisées, forer un tunnel sécurisé avec un réseau privé virtuel ou un autre outil empêchera les importuns de venir voir ce qui se passe sur votre réseau.
Avec un site Web client et une seule base de données, Pretendco pourra :
- s’assurer que sa base de données et son instance ne soient accessibles que par le réseau interne, donc empêcher les intrus d’accéder au serveur de la base de données en le dissimulant;
- bloquer les ports de l’instance Web, sauf ceux dont les clients ont besoin pour accéder au service.
Sécurité des logiciels
Garder les composants de l’application à jour n’est pas facile, que ce soit dans un nuage ou à l’extérieur de celui-ci. Selon la nature de vos responsabilités, vous pourriez devoir gérer les mises à niveau du système d’exploitation, des bibliothèques partagées, du cadre des applications et, bien sûr, du code de ces dernières. Un logiciel désuet pose un risque majeur sur le plan de la sécurité et c’est l’une des principales raisons à l’origine des exploits reposant sur l’exécution d’un code à distance. Dès que la vulnérabilité d’un logiciel ou d’une bibliothèque a été rendue publique, des robots commenceront souvent à balayer les sites Web et les plages d’adresses en quête d’une cible. C’est pourquoi il est si important de garder les logiciels à jour, surtout pour les applications Web.
Outre les mises à niveau, un autre processus important est le « renforcement ». Les paramètres par défaut du système d’exploitation et des services ne conviennent pas toujours à la plateforme de production. Le renforcement modifiera la configuration par défaut des services et des éléments sous-jacents (comme le système d’exploitation et les protocoles) en insistant sur la sécurité. Le renforcement devait faire partie intégrante du développement.
Une façon courante de s’assurer que les paramètres sont les bons et sont assez sûrs consiste à effectuer un test de pénétration. Beaucoup d’outils de source ouverte (Kali ou OpenVAS, par exemple) vous permettront d’effectuer ce test à l’interne, mais nous préconisons vivement de faire appel à un professionnel ou à une agence externe. En effet, bien que maintes vérifications de la vulnérabilité réalisées avec de tels outils soient automatisées, il n’en va pas autant de l’interprétation des résultats, ni des mesures qui devront être adoptées par la suite. Certes, avec un peu d’efforts, vous tirerez des renseignements utiles des rapports, mais il est difficile de remplacer le savoir-faire d’un professionnel aguerri.
Pour ne pas sombrer dans la désuétude, Pretendco a ajouté les éléments que voici à son infrastructure. Chaque méthode tient à jour ou renforce différents composants de l’infrastructure.
- Mise à niveau de sécurité automatique par paquets du fournisseur du système d’exploitation (à savoir, Ubuntu Security Updates ou rustines de sécurité Windows)
- Système de surveillance Dependabot sur GitHub signalant la désuétude ou une vulnérabilité des dépendances associées à l’application Web
- Au moment du déploiement, Pretendco a interrompu les services superflus, ce qui a réduit la « surface d’attaque » éventuelle, donc accru la sécurité de l’ensemble.
D’autre part, l’entreprise a pris d’autres mesures que mentionnent les guides techniques de sécurisation. Ainsi, elle s’est assurée qu’on ne puisse accéder à ses serveurs qu’avec des clés SSH et elle a activé le pare-feu pour éviter que n’importe qui ait accès aux ports et aux services.
Gestion de la configuration
Par là, on entend l’usage d’Ansible, de Puppet, de Chef ou d’autres outils qui configureront l’infrastructure de la manière souhaitée. Certains de ces outils fonctionnent automatiquement et veillent en permanence à la conformité de la configuration, alors que d’autres n’entrent en jeu qu’à chaque déploiement.
Quand on gère la configuration (avec des scripts d’automatisation), autre mesure de sécurité préventive, les erreurs humaines ou celles attribuables à une mauvaise configuration voire à l’omission d’une étape deviennent beaucoup moins fréquentes. Vous économiserez aussi du temps au moment de configurer l’infrastructure et pourrez fixer des valeurs par défaut avant que l’infrastructure interagisse avec les applications ou les utilisateurs.
D’envergure assez modeste, Pretendco a décidé d’utiliser son système d’intégration et d’exécution continues (CI/CD) pour appliquer les scripts d’Ansible toutes les six heures ou chaque fois que la plateforme de production est mise à jour, afin qu’il n’y ait pas dérive de la configuration. De cette façon, l’entreprise n’a plus besoin d’effectuer certaines tâches aussi souvent (renouvellement du certificat SSL, installation de paquets hors des mises à jour automatiques programmées, concordance des autorisations concernant les fichiers). Bien que ces activités puissent se dérouler séparément, les intégrer à la gestion de la configuration aboutira à des résultats cohérents, aussi bien la première que la centième fois.
Grâce à une gestion de la configuration efficace, Pretendco maintiendra sa conformité, mais garantira également que l’entreprise est mieux équipée pour rebâtir rapidement son infrastructure si jamais survient un pépin.
Journalisation et visibilité
Une journalisation centrale est fondamentale à la sécurité des infrastructures modernes. Il en va autant d’une bonne connaissance de la diversité des problèmes, notamment les difficultés d’accès ou les erreurs pouvant survenir quand on utilise telle ou telle fonctionnalité du service. Pour savoir d’où vient le problème (permission accordée à l’utilisateur, connexion erronée à la base de données, etc.), on analysera les journaux qui recensent les activités des composantes de l’application.
Une plateforme de journalisation centrale facilitera l’examen des incidents touchant divers systèmes ou services. Pareille centralisation a aussi son importance en empêchant les intrus de modifier les journaux du système advenant le cas où ce dernier a été compromis.
Les journaux du serveur de l’application Web, par exemple, renferment certaines informations tandis que ceux du service ou du serveur de la base de données ne fournissent de renseignements que sur les accès à la base de données ou les erreurs internes. Or, il faut savoir ce que l’utilisateur faisait au moment où l’erreur est survenue.
Pour que tout fonctionne correctement, les codes d’erreur, les unités de mesure et le format des journaux devraient être relativement cohérents et instructifs. La plupart des plateformes d’infonuagique proposent des services de journalisation centraux, mais les solutions offertes par des indépendants (Loggly, Elasticsearch, Splunk, etc.) pourraient comprendre des fonctionnalités supplémentaires que votre équipe jugerait utiles.
Journalisation mise à part, surveiller l’environnement actif vous renseignera sur l’état et le comportement de vos systèmes, ce qui s’avère d’une grande utilité, car vous serez alerté quand des problèmes surviennent, ce qui vous permettra de les résoudre. Pareille surveillance autorise l’usage de solutions aisément accessibles, commandées par les événements, c’est-à-dire celles qui déclencheront automatiquement des remèdes comme la reconstruction d’un service ou la suppression d’un nœud dans une grappe active selon l’état de l’application. Par ailleurs, on devrait configurer les alertes afin que le système signale tout usage anormal des ressources ou un problème d’authentification. En général, tout ce qui réduit l’accessibilité ou nécessite une intervention manuelle devrait déclencher un signal d’alarme, même s’il existe des moyens automatisés pour remédier au problème.
Chez Pretendco, les journaux de chaque service sont transmis à un serveur rsyslog central, si bien qu’ils se retrouvent tous au même endroit. Le débogage et l’identification des problèmes de sécurité s’en trouvent donc passablement facilités. Si l’analyse des journaux devient une nécessité, leur centralisation facilitera considérablement l’usage d’outils comme Elasticsearch ou Splunk.
Conseils sur l’architecture
Architecture sensible à la sécurité
Tous les modèles de sécurité sont constitués de couches d’éléments connectés ou isolés. Pour sécuriser votre architecture, il importe d’envisager les facteurs de risque propres au cas d’utilisation et s’assurer que l’architecture intègre les contrôles et les moyens de compensation nécessaires pour garder l’application, les données et les utilisateurs en sécurité.
Chaque service, chaque connexion entre les composants qui sous-tendent l’application constitue une occasion d’explorer et d’ajouter une couche de défense afin de prévenir les activités mal intentionnées.
Le diagramme ci-dessous illustre les couches de sécurité habituellement rencontrées lors d’un déploiement en nuage.
Servez-vous de ce diagramme pour vérifier vos responsabilités et les points fragiles, puis adapter l’infrastructure en conséquence. Lors de la planification d’urgence, dressez la liste des composants de l’application situés dans chaque couche. Ensuite, selon vos responsabilités, prévoyez comment éviter une brèche ou relancer le système en cas de défaillance.
Comme on a pu le voir tout au long de ce tutoriel, Pretendco s’est efforcée de mettre en place des contrôles à différents niveaux pour parer à toute exploitation. L’entreprise à restreint l’accès à son réseau, recouru à l’encryptage et instauré des méthodes d’autorisation et d’authentification fiables.
Le diagramme suivant montre comment chaque élément de l’architecture peut utiliser les moyens indiqués au-dessus pour éviter que l’exploitation d’un élément s’étende ou empêcher d’emblée la formation d’une brèche.
Modèle du fromage suisse (défense en profondeur)
Ne pas mentionner le paradigme à la base des diverses mesures qui doivent être combinées serait une négligence de notre part. Le modèle du fromage suisse (ou défense en profondeur) montre comment des mesures multiples, une fois combinées, pallieront les faiblesses d’un système grâce aux forces d’un autre. Aucune mesure en soi ne protège entièrement l’application, mais, ensemble, elles réduisent nettement la probabilité qu’une attaque soit couronnée de succès.
En concevant ou modifiant l’architecture, déterminez l’emplacement et l’origine des lacunes dans les différentes stratégies de défense. Il sera plus facile d’établir quelles autres stratégies on devra échafauder afin d’y remédier.
Par exemple, Pretendco identifiera rapidement une faille dans la gestion de sa configuration qui a permis à un nouveau service de s’activer par erreur sans authentification. Cependant, le risque a été étouffé avant même qu’il suscite un problème, car l’entreprise avait mis en place des mesures pour que le pare-feu ne donne accès qu’aux ports prévus (pas à celui qu’utilise le nouveau service).
Dernières réflexions
Les outils et les pratiques exemplaires en sécurité ne cessent d’évoluer, mais les principes fondamentaux restent les mêmes : encrypter, isoler, authentifier et surveiller sont les b.a.-ba d’une architecture sûre, que ce soit dans un nuage ou un centre de données. Les méthodes modernes de sécurisation n’en sont que le prolongement, l’automatisation en multipliant l’utilité. En effet, on peut automatiser les tâches qui se faisaient naguère à la main (l’encryptage des données, par exemple) et profiter des services d’infonuagique qui gèrent une grande partie des technologies à notre place.
Structurer une infrastructure pour la rendre sécuritaire est la responsabilité de chacun. Pour donner des résultats, une stratégie doit s’appuyer sur des politiques, des méthodes et la connaissance. Les fournisseurs de services d’infonuagique proposent des solutions qui allègent en partie ce fardeau, mais chacun doit connaître son rôle et ses points faibles. Que vous échafaudiez l’architecture d’une petite instance ou un important microservice, la sécurité devrait être planifiée rapidement et revue régulièrement à mesure que le système évolue.
La surveillance et la journalisation sont indispensables. Heureusement, ces deux aspects sont bien desservis sur le marché. Trouver les méthodes qui vous aideront à comprendre ce qui se passe quand survient un incident vous incitera à chercher des moyens pour remédier automatiquement à un plus grand nombre de difficultés mineures. En suivant et en vérifiant régulièrement les autorisations, vous verrez les erreurs de configuration accidentelles ou les conséquences imprévues de certains changements.
Les risques qu’une cyberattaque pose pour l’organisation changent constamment, mais les outils pour les parer également. Les fournisseurs de services d’infonuagique et les outils qu’ils mettent au point se trouvent au front dans la guerre pour obtenir vos données. Toutefois, sans planification ni exécution, les protocoles de protection même les plus sophistiqués n’avèreront guère plus efficaces qu’une porte moustiquaire dans un ouragan.
Lectures complémentaires
Nous vous recommandons vivement de lire ce qui suit (documentation en anglais).