X
Failles processeurs Meltdown & Spectre
Vincent Habchi / vendredi 9 mars 2018 / Thèmes: Développement, Sécurité SI, Dossier

Failles processeurs Meltdown & Spectre

Un compromis qui a mal tourné

Il faudra bien se faire une raison : nous devrons vivre sans doute quelques années avec les deux failles découvertes par différentes équipes de chercheurs. Ce n’est qu’à partir de 2019 qu’une nouvelle génération de processeurs apportera un remède définitif à Meltdown et Spectre. Il est temps de faire mieux connaissance avec ces défauts de conception.

L’informatique moderne se construit autour de deux piliers : la performance et la sécurité. Malheureusement, ces deux objectifs sont parfois contradictoires : la sécurité nécessite des contrôles permanents que la performance exècre. Parfois, les ingénieurs réussissent à allier les deux sans trop de souci ; parfois, les exigences sont si incompatibles que des compromis doivent être trouvés, au prix d’un certain risque, conscient ou non. Meltdown et Spectre, ces deux failles présentes dans toutes les itérations récentes des processeurs Intel – et, pour Spectre, également AMD et ARM – sont les rejetons d’un compromis qui a mal tourné.

Depuis que la course aux mégaHertz s’est terminée en cul-de-sac, les fondeurs ont tout misé sur l’exécution parallèle : les processeurs actuels renferment plusieurs cœurs qui eux-mêmes exécutent plusieurs instructions simultanément (architecture « superscalaire »).

Les ressources d’exécution du processeur (unité arithmétique, unité d’accès mémoire, etc.) sont mutualisées. Chaque instruction assembleur est décodée, puis décomposée en micro-instructions (µOP). Celles-ci s’exécutent dès que les ressources qu’elles nécessitent deviennent disponibles, pourvu qu’elles ne dépendent pas d’une autre micro-instruction en cours. Certaines instructions s’exécutent donc avant que d’autres, pourtant antérieures, ne soient terminées.

Pensez à la Poste : si tous les gens attendent pour une opération bancaire et que vous venez pour affranchir une lettre, vous serez sorti bien avant le dernier d’entre eux. Lorsque toutes les micro-instructions correspondant à une instruction ont fini de s’exécuter, l’instruction est mise en attente. Elle est ensuite « retirée » du pipeline, dans l’ordre chronologique d’exécution attendu : sa légitimité est vérifiée et, le cas échéant, ses résultats sont entérinés.

Pourquoi retirer dans l’ordre chronologique ? Premièrement parce que l’exécution d’un programme ne doit pas dépendre des détails de l’implémentation. Ensuite, parce que parfois les choses se passent mal : par exemple une division par zéro. Or, quand le processeur rencontre une instruction fautive, il doit générer une exception. Mais si les instructions étaient retirées dans le désordre, le core dump pourrait indiquer un état des registres différent de celui qui a provoqué l’erreur.

Les processeurs pratiquent également une autre optimisation appelée « branchement spéculatif ». Il s’agit de prédire le résultat d’un test avant que celui-ci ne soit calculé. Pour cela, le processeur collecte le résultat du test à chaque fois qu’il l’exécute, en déduit une probabilité de succès dont il se sert pour commencer à exécuter « spéculativement » les instructions de la branche la plus probable. Quitte à tout détricoter si jamais le test retourne in fine la valeur inverse.

Espace mémoire virtuel noyau et utilisateur

Tous les systèmes d’exploitation modernes, Windows ou UNIXlike (Linux, Mac OS X), utilisent le concept de « mémoire virtuelle ». Chaque processus s’exécute dans un espace de mémoire dit « virtuel » à 64-bit (contenant donc 264 ~ 1020 octets). Un circuit appelé MMU (Memory Management Unit) se charge de traduire ces adresses virtuelles en adresses RAM réelles (physiques). La MMU découpe les mémoires virtuelle et physique en « pages » (généralement 4 ko) et gère des tables de translation entre adresses virtuelles et adresses physiques. Chaque processus possède sa propre table. Une gestion correcte de la MMU évite ainsi que les processus ne « se marchent » les uns sur les autres.

En outre, il existe deux niveaux d’exécution : « utilisateur » et « superviseur » – ou « privilégié ». Toutes les tâches courantes tournent en mode utilisateur ; seul le noyau tourne en mode superviseur. Ce dernier dispose d’un espace mémoire virtuel protégé : les données qui s’y trouvent ne peuvent être lues/écrites que par lui-même ; toute tentative d’accès par un processus utilisateur se solde par une exception du type Segmentation fault. Et pour cause : on trouve dans cet espace des données sensibles, par exemple, des clefs cryptographiques privées. Un jeu de drapeaux propre à une page ou à une zone de pages indique le statut de chaque page, privilégiée ou non, lecture-seule ou lecture/écriture, etc.

Les processus utilisateurs font plus ou moins fréquemment appel au noyau, qui offre tous les services d’entrée-sortie et de gestion de mémoire, entre autres. Ces appels au noyau, par l’intermédiaire de « trappes » logicielles, provoquent un changement de niveau de privilège, mais pas de changement d’espace mémoire virtuel. Logiquement, il faudrait donc, à chaque « trappe », que le noyau sauvegarde la table de translation du processus en mémoire, charge la sienne propre, exécute le service demandé, puis recharge la table de translation sauvegardée avant de rendre la main. Ces opérations ont un coût. Les développeurs des noyaux UNIX – et Windows dans une moindre mesure – ont donc décidé d’inclure l’espace mémoire virtuel du noyau dans l’espace virtuel de chaque processus. Inutile alors de changer de table de translation lors d’un appel système, puisque les deux espaces mémoire coexistent. Mais, dans ces conditions, comment empêcher qu’un processus utilisateur accède aux données du noyau ? Aucun souci : privilégiées, ces données sont protégées de tout accès en mode utilisateur. Il n’y a donc aucune fuite possible. Du moins en théorie…

MELTDOWN

Oui, mais pas en pratique ! L’attaque Meltdown [★1] [★3] (CVE-2017-5754) exploite une faille, ouverte par l’exécution anticipée d’instructions, qui modifie l’état du processeur en fonction de la valeur d’une donnée pourtant interdite en lecture. Voyons comment. Supposons que nous ayons alloué, à l’adresse A, une zone de mémoire utilisateur de 4 096 × 256 = 1 Mo. Considérons le pseudo-code suivant :

 


Nous l’avons vu, le contrôle de validité de l’instruction (1) n’intervient qu’au moment où l’instruction est retirée. En attendant, l’exécution anticipée se poursuit avec (2) dès que la donnée demandée par (1) arrive. Que fait (2) ? (2) utilise la donnée chargée par (1) comme index pour accéder à une adresse non-privilégiée. La donnée contenue à cette adresse est chargée dans R1, mais également dans le cache.

Pourquoi la multiplication par 4 096, c’est-à-dire la taille d’une page ? Parce qu’une ligne du cache ne peut pas stocker des données issues de pages différentes(*). La multiplication par 4 096 assure donc que, selon la valeur de R0, nous allons lire dans une page différente, et donc remplir une ligne de cache différente. Quand le processeur s’aperçoit que (1) viole la protection superviseur, il déclenche une exception. R0 est effacé – ce qui raisonnable, autrement la valeur illicitement lue serait disponible dans le core dump –, R1 reprend sa valeur initiale… mais le cache lui n’est pas réinitialisé. Ainsi, nous avons maintenant dans le cache une donnée qui ne devrait pas y être, à une adresse qui dépend directement de la donnée illicitement lue. La belle affaire ! Et pourtant. Supposons que, préalablement à (1), nous ayons exécuté une instruction vidant le cache (clflush). Après (2), nous sommes sûrs de n’avoir qu’une seule adresse de notre table dans le cache. Pour savoir laquelle, il nous suffit, après coup, de lire toutes les données aux adresses A, A + 4096, A + 2 * 4096, …, A + 255 * 4096 et de mesurer les temps d’accès : la donnée en cache sera lue plus vite que les autres, si vite qu’il sera facile de deviner à quelle adresse elle se trouve. Une fois cette adresse connue, on en déduira la valeur transitoire de R0, bien qu’elle provienne d’un espace normalement inaccessible. Bingo !

Recommençons (1) sur l’ensemble de l’espace virtuel du noyau, et voilà : nous obtenons un dump intégral de la mémoire accessible à ce dernier. Sachant que, pour des raisons de performance, le noyau possède un accès direct à toute la mémoire physique de la machine, nous avons ainsi accès à toute la mémoire, donc aux codes et données de tous les processus qui s’exécutent sur la machine.

On pourra objecter que la faille existe mais qu’elle déclenche à chaque lecture illicite une exception qu’il faut gérer, faute de quoi le programme plante. Lire l’intégralité de la mémoire signifie gérer plusieurs milliards de ces exceptions, soit un temps tellement long qu’il ne présente aucun intérêt pratique. C’est malheureusement faux. Les processeurs Intel disposent d’une pseudo-instruction appelée TSX qui groupe un bloc d’instructions en une « méta-instruction » atomique – à la manière d’une transaction dans une base de données. Si l’une des instructions de ce bloc provoque une erreur, toute la transaction est annulée, mais aucune exception n’est levée. Les registres reviennent à leur état initial, mais le cache, lui, continue à porter les traces des instructions annulées. Dans la pratique, les programmes d’attaque utilisent quelques raffinements supplémentaires (cf. [★1] pour plus de précisions. Grâce à TSX, un démonstrateur parvient à dumper la mémoire à un débit d’environ 512 ko/s avec un taux d’erreur quasi-nul. Ce qui signifie environ 30 minutes par gigaoctet, ou une journée pour une machine avec 48 Go de mémoire.

Implications de Meltdown en termes de sécurité

Meltdown démontre que la cloison, que l’on pensait étanche, entre données utilisateur et données superviseur, est en réalité poreuse. N’importe quel processus peut lire n’importe quelle donnée accessible au noyau, pourvu que l’espace virtuel du noyau soit contenu dans l’espace mémoire virtuel du processus d’attaque, ce qui est le cas en pratique sur tous les OS courants.

L’originalité de cette attaque tient à sa discrétion : elle se déroule à l’insu de tous les autres utilisateurs, noyau compris. Meltdown ne laisse aucune trace dans les logs. Aucune faille logicielle n’est en cause, le code n’est pas touché. Un simple programme d’attaque en mode utilisateur (sans rootkit) suffit. Ce n’est pas un virus. Ce n’est pas un cheval de Troie. Personne n’est à blâmer.

Bien entendu, ce sont les serveurs qui sont les plus exposés : les machines multi-utilisateurs en général et, particulièrement, les serveurs mutualisés « bas de gamme », où l’hyperviseur maître partage le même noyau entre les différentes machines virtuelles. Dans ce cas, la mémoire virtuelle de ce noyau partagé contient toutes les données présentes sur la machine physique, ce qui signifie que n’importe qui, depuis une machine virtuelle, peut lire les données stockées sur les autres machines virtuelles co-hébergées, voire les données de l’hyperviseur lui-même. Comme le code d’attaque se contente d’accéder à de la mémoire sans avoir recours à aucun service du noyau, aucune mesure ne peut empêcher son exécution.

Parades

Il n’existe, à l’heure actuelle, aucune parade hardware disponible contre Meltdown. Intel a confirmé qu’une mise à jour du microcode des processeurs ne servirait à rien. La seule solution efficace, interdire l’exécution parallèle, aurait de telles conséquences en termes de performance qu’elle est inenvisageable. Notons que les processeurs AMD et ARM paraissent immunisés contre Meltdown : la faille existerait bien, mais semble – pour l’instant du moins – inexploitable par des programmes simples.

On pourrait croire que la politique des noyaux Linux récents, à partir de la version 4.12, consistant à tirer au sort la position de l’espace virtuel du noyau à chaque boot pourrait éventuellement protéger les machines contre Meltdown. En réalité, ce mécanisme est limité à 40 bits, et comme l’espace mémoire noyau demeure contigu, il suffit de réaliser des lectures régulièrement espacées de quelques gigaoctets pour trouver la bonne gamme d’adresses. Conclusion : ce mécanisme, contourné en quelques secondes, n’offre aucune protection. L’unique voie de contournement consiste à réaliser une isolation totale des espaces mémoire du noyau et des processus, ce que les développeurs Linux ont baptisé KPTI (Kernel Page Table Isolation) [★5]. Dans ce cas, l’espace virtuel du noyau n’est plus inclus dans l’espace virtuel des processus. Meltdown ne fonctionne plus, car la mémoire virtuelle des processus ne contient plus que les données des processus eux-mêmes.

Cette parade est désormais en place sur les noyaux Linux les plus récents. Windows devrait avoir été mis à jour à l’heure où ces lignes paraîtront et Mac OS a déjà été patché depuis la version 10.13.2 [★4]. FreeBSD ne l’est malheureusement pas [★5], car les équipes de développement n’ont été prévenues que fin décembre. Les autres xBSD sont également vulnérables, et pour l’ensemble de ceux-ci, il ne faut pas s’attendre à des versions corrigées avant plusieurs semaines au mieux, vu l’ampleur des modifications à apporter. KPTI fonctionne, mais son impact sur les performances n’est pas négligeable. À chaque appel système, le processeur doit maintenant jongler entre les tables de translation du noyau et celles des processus utilisateurs et vider le cache de niveau 1(**). Le résultat est une perte de performance estimée entre 5 % et 30 % parfois, voire plus. En réalité, l’impact dépend du profil de l’application. Les applications purement graphiques, comme les jeux, ou les applications de calcul intensif, qui ne réalisent que très peu d’entrée-sortie, ne seront pas vraiment ralenties. En revanche, les bases de données et les serveurs web subiront le contre-coup de plein fouet. [★7] donne plus de détails sous Linux. Toutefois, les propriétaires de processeurs disposant de l’extension PCID semblent pouvoir s’en tirer mieux que les autres : leurs processeurs ne seraient que très légèrement affectés par KPTI. Apple, dont la plupart des machines sont équipées de processeurs possédant cette extension, a affirmé n’enregistrer que des ralentissements marginaux [★4].

 

SPECTRE

La deuxième attaque, baptisée Spectre, se base sur le même principe : leurrer l’unité spéculative du processeur pour lui faire faire exécuter des instructions « fantômes » qui ne seront jamais validées, mais laisseront une trace dans le cache. Spectre recouvre deux aspects distincts. La vulnérabilité CVE-20175753 concerne l’accès aux données hors bornes. Considérons le programme C suivant :



Les bonnes pratiques exigent qu’une variable d’index soit systématiquement vérifiée avant un accès indirect à une table pour s’assurer qu’elle n’excède pas le maximum permis. Mais ici, cette mesure de bon sens va se retourner contre nous. Supposons :

A. Que la variable size_of_array ne soit pas dans le cache ;

B. Que le test ait été (quasiment) toujours vérifié dans le passé ;

C. Qu’un « hacker » ait réussi à injecter dans la variable index une valeur hors limites, de telle sorte que array [index] pointe vers une donnée sensible dans la mémoire utilisateur du processus ;

Que se passe-t-il ? Le processeur, pour calculer la valeur logique du test, est obligé d’accéder à la valeur de la variable size_of_array, qui se trouve hors cache, et doit donc être rapatriée depuis la RAM. Il ne va pas attendre sans rien faire. Au contraire, il va utiliser son unité de prédiction pour deviner le résultat du test (ici, en raison de la condition B, vrai), puis va commencer à exécuter (2) et (3). Si (2) va chercher une donnée en cache, celle-ci sera disponible bien avant que le résultat de (1) le soit. Le processeur va donc poursuivre avec (3), et on se retrouve dans le même cas que Meltdown : l’accès spéculatif à la zone de mémoire quelconque pointée par array2 provoquera le chargement d’une ligne particulière du cache, qui dépendra directement de foo. Si aucune des adresses de la table array2 ne se trouve dans le cache, alors il sera facile de deviner quelle est la valeur de foo, simplement en mesurant les temps d’accès à la table. [★2] présente et discute une implémentation possible de cette attaque en C et en Javascript.

Malheureusement, l’unité spéculative de test n’est pas la seule qui semble attaquable. L’unité spéculative de branchement l’est aussi, ce qui constitue une attaque séparée (CVE-2017-5715). Cette unité se charge de communiquer une adresse de saut probable lorsque celle-ci ne peut être déterminée rapidement, ce qui arrive, par exemple, lorsqu’elle se trouve à un emplacement mémoire référencé par un registre (jmp*%eax), et que cet emplacement mémoire ne se trouve pas en cache. Ici aussi, il semble théoriquement possible de « corrompre » cette unité pour leurrer le processeur vers une fausse adresse à laquelle il exécutera spéculativement une série d’instructions préalablement choisie, conduisant vraisemblablement à la divulgation d’une donnée secrète par le même mécanisme que précédemment. Les détails d’implémentation manquent à ce stade, car le fonctionnement de l’unité spéculative de branchement reste assez nébuleux.

 

Temps d'accès en lecture de 256 pages consécutives. L'unique page résidente dans le cache est aisément identifiable, son temps d'accès étant en moyenne inférieur de moitié aux autres. D'après [★1].

Implications de Spectre en termes de sécurité

Spectre permet de gagner un accès à des données sensibles qui se trouvent dans l’espace mémoire utilisateur d’un processus, par exemple des mots de passe. Cette faille paraît difficile à exploiter sur des exécutables purs : il faut manipuler l’une des unités d’exécution spéculative à son insu, ce qui est faisable, mais délicat. Hélas, ces unités spéculatives semblent partagées entre hyper-threads, ce qui signifie qu’un processus peut délibérément influencer un autre processus qui tournerait dans un hyper-thread différent mais sur le même cœur. Heureusement, les cœurs semblent isolés entre eux. En revanche, les navigateurs internet constituent des cibles faciles, car ils sont conçus pour exécuter des programmes en JavaScript à l’origine non-contrôlée, et, comme le prouve [★2], quelques lignes suffisent pour exploiter la faille. Des patches seraient en cours de développement pour le JavaScript avec, là aussi, un impact minimal sur la performance [★4]. Spectre affecte un nombre plus important de processeurs que Meltdown : les modèles récents d’Intel, d’AMD et mêmes certains modèles ARM sont touchés [★2]. Les smartphones sont donc également concernés.

Parades contre Spectre

Une parade purement logicielle contre Spectre semble difficile à créer. Là aussi, la seule mesure vraiment efficace consisterait à « sérialiser » l’exécution des applications, ce qui est impossible. En attendant, les compilateurs pourraient insérer certaines instructions telles que mfence et lfence en x86, qui provoquent une synchronisation de l’exécution, après chaque test. Cependant, cette solution reste à évaluer. Une autre possibilité consiste à insérer une boucle d’attente calibrée après chaque test, ce qui paralyse le processeur le temps que le résultat du test arrive ; une nouvelle fois, l’impact sur la performance paraît non-négligeable, d’autant que le processeur peut parfois exécuter spéculativement plus de cent instructions à l’avance.

Un antidote simple, baptisé retpoline [ 8], contre l’exploitation de l’unité spéculative de branchement (CVE2017-5715), déjà intégré aux branches de développement de LLVM et GCC, consiste à remplacer le saut indirect jmp *%eax par la séquence (syntaxe AT&T) :

Un appel à un sous-programme se substitue au branchement. Cet appel sauvegarde l’adresse de retour dans la pile, pointée par le registre rsp, et simultanément dans un cache interne. Le sous-programme écrase l’adresse de retour normale par l’adresse de destination du saut contenue dans eax, puis exécute ret. En attendant que l’adresse de retour réelle soit rapatriée, le processeur utilise l’adresse en cache. Il retourne donc au programme principal et tombe en stall sur une boucle d’attente infinie. Lorsque l’adresse de retour, égale maintenant à la valeur contenue dans eax, arrive, le processeur s’y rend. L’unité spéculative de branchement n’est plus utilisée. [ 8] discute l’impact de retpoline sur les performances et la manière de le minimiser.

Conclusion

Meltdown et Spectre exploitent la fragilité inhérente à l’exécution spéculative des instructions, une optimisation présente dans la plupart des processeurs gravés depuis dix ans. Meltdown, en particulier, représente une menace grave pour le fonctionnement de tous les serveurs multi-utilisateurs ou hébergeant des machines virtuelles à noyau partagé. Les solutions déployées en urgence pour contrer ces deux failles majeures ne sont que des pis-aller, dans la mesure où l’impact sur les performances des machines ne sera pas négligeable. Les anciennes machines, ou celles équipées de processeurs d’entrée de gamme, seront les plus touchées. Certains systèmes d’exploitation, comme FreeBSD, seront vulnérables pendant encore plusieurs semaines. On pourra déplorer que leurs équipes de développement n’aient pas été prévenues plus tôt.

La réaction des principaux hébergeurs à Meltdown semble rapide (par exemple [★9]), malgré le coût que cela représente. Ceux-ci devront également retirer les versions vulnérables des noyaux proposés aux utilisateurs, quitte à les forcer à changer pour une version corrigée. Les petits fournisseurs, qui proposent souvent des noyaux en retard d’une ou deux itérations, se retrouvent au pied du mur. Si Meltdown semble sous contrôle, Spectre ne l’est que partiellement. Il est à noter que les mesures palliatives prises contre Meltdown n’affectent pas Spectre, et vice-versa. Seul un changement matériel d’architecture permettra de corriger simultanément ces failles. L’itération 10 nm des processeurs Intel, déjà repoussée à la fin 2018, risque de subir un nouveau retard. D’ici là, le fondeur continuera à commercialiser des processeurs vulnérables. Comme la transition vers la nouvelle architecture ne sera pas instantanée, préparons-nous à cohabiter pendant quelques années avec ces failles.

(*) Une ligne de cache ne contient qu'un seul jeu de drapeaux de statut de page : impossible d'y stocker des données issues d'une page utililisateur et d'une page superviseur, par exemple.
(**) Ce cache fonctionne en adresses virtuelles qui peuvent être identiques mais pointer vers des adresses physiques différentes en fonction de la table de translation active.

 


BIBLIOGRAPHIE

[★1] M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, S. Mangard, P. Kocher, D. Genkin, Y. Yarom, M. Hamburg : Meltdown. https://meltdownattack.com/meltdown.pdf

[★2] P. Kocher, D. Genkin, D. Gruss, W. Haas, M. Hamburg,  M. Lipp, S. Mangard, T. Prescher, M. Schwarz, Y. Yarom : Spectre. https://spectreattack.com/spectre.pdf

[★3] J. Horn : Reading privileged memory with a sidechannel. https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html

[★4] https://support.apple.com/en-us/HT208394

[★5] https://www.freebsd.org/news/newsflash.html#event20180104:01

[★6] https://lwn.net/Articles/740608/

[★7] https://www.phoronix.com/scan.php?page=article&item=linux-kpti-pcid

[★8] https://reviews.llvm.org/D41723

[★9] https://news.gandi.net/en/2018/01/meltdown-and-spectre-vulnerabilities

3542

x
Rechercher dans les dossiers
Les derniers dossiers...
Réduire

Actuellement à la Une...
Après l'infrastructure sous-jacente, c'est au tour des systèmes de paiement des applications de Facebook d'être unifiés. Le géant annonce le lancement de Facebook Pay, une solution de paiement mobile pour le réseau social, Messenger, Instagram et WhatsApp.

L’éditeur du système de fichiers de stockage pour les environnements de haute performance a revisité PANFS, le système de fichiers maison, et l’installe sur ses appliances haut de gamme ActiveStore Ultra.

L’éditeur de solutions de monitoring et de sécurité des environnements en container annonce la version 3 de Sysdig Secure.

Aucun détail n’a été donné sur la transaction de rachat de CloudSploit par Aqua Security, un éditeur de solutions de sécurité pour les environnements clouds natifs (serverless, containers).

Cemex, un des plus grands cimentiers dans le monde, a opté pour la technologie d’une jeune start-up pour accélérer la transformation de ses cimenteries et les faire entrer dans l’ère de l’industrie 4.0.

Si longtemps la réputation d’un centre de données s’est limitée au seul critère de continuité de service, de nouvelles caractéristiques ont aujourd’hui pris de l’importance, à l’instar de la consommation énergétique, de la performance environnementale ou encore de la sécurité des systèmes d’informations. De nombreux référentiels sont donc venus s’ajouter afin d’apporter non seulement une garantie de sérieux, mais aussi une meilleure lisibilité du marché. Article publié dans L'Informaticien n°181.

Tout ceci est parfaitement légal, mais pose des questions ne serait-ce qu'éthiques. Le groupe de Mountain View, par le biais d'un partenariat avec une association d'hôpitaux américains, peut accéder aux données de millions de patients sans que ces derniers en soient informés.

Lancés en pleine vague Big Data afin d’aider les organisations à entrer dans l’ère de la donnée, les DataLabs doivent aujourd’hui évoluer. Fini “ l’usine à poc ”, l’heure est au pragmatisme, à l’industrialisation des modèles d’IA et à leur intégration aux équipes agiles. Article paru dans L'Informaticien n°181.

Fondée en 2015, RapidAPI s’est vite fait un nom en créant une vaste place de marché des APIs qui alimente près d’un million de développeurs dans le monde.

L'enceinte intelligente d'Orange, annoncée en 2017, sera commercialisée à compter de jeudi. Débarquant sur un marché monopolisé par les géants américains et vraisemblablement plus limité que la concurrence en termes de fonctionnalités, on se demande si la seule promesse d'une confidentialité des données renforcée suffira à ce que Djingo tire son épingle du jeu.

Toutes les News
LIVRES BLANCS
Les entreprises et les organismes publics se focalisent aujourd’hui sur la transformation numérique. En conséquence, les DevOps et l’agilité sont au premier plan des discussions autour des stratégies informatiques. Pour offrir ces deux avantages, les entreprises travaillent de plus en plus avec les fournisseurs de services de cloud public et développent désormais des clouds sur site à partir d’une infrastructure qui répond à trois exigences de base:
1. Agilité sans friction des ressources physiques
2. Systèmes de contrôle optimisant l'utilisation des ressources physiques et offrant un retour sur investissement maximal
3. Intégration des divers composants de l'infrastructure pour un provisionnement et une gestion des ressources automatisés.


Pour fonctionner, votre entreprise doit pouvoir compter sur une solution de sauvegarde efficace, essentielle dans un monde marqué par une croissance exponentielle des données. Vous devez à la fois accélérer vos sauvegardes et pouvoir y accéder plus rapidement pour satisfaire les exigences actuelles de continuité d’activité, disponibilité, protection des données et conformité réglementaire. Dans cette ère de croissance effrénée, les cibles sur bande hors site et autres approches traditionnelles sont simplement dépassées.


L’Intelligence Artificielle promet de révolutionner la perception de la cybersécurité au coeur des entreprises, mais pas uniquement. Ce changement de paradigme engage, en effet, une redéfinition complète des règles du jeu pour les DSI et les RSSI, ainsi que l’ensemble des acteurs de la sécurité.


Lorsque l'on déploie des postes de travail, ils ont généralement tous la même configuration matérielle et logicielle (avec certaines spécificités selon les services). Mais on ne peut pas toujours tout prévoir et il arrive par exemple que de nouveaux programmes doivent être installés ou n’aient pas été prévus. L’accumulation de logiciels « lourds » est susceptible de provoquer des lenteurs significatives sur un PC allant jusqu’à l’extinction nette de l’application. Ce livre blanc explique comment optimiser les performances au travers de 5 conseils rapides à mettre en place.


Ce guide est conçu pour aider les entreprises à évaluer les solutions de sécurité des terminaux. Il peut être utilisé par les membres de l'équipe de réponse aux incidents et des opérations de sécurité travaillant avec des outils de sécurité des points finaux sur une base quotidienne. Il peut également être utilisé par les responsables informatiques, les professionnels de la sécurité, les responsables de la conformité et d’autres personnes pour évaluer leurs performances. les capacités de l’entreprise en matière de cybersécurité, identifier les lacunes dans la sécurité des terminaux et sélectionner les bons produits pour combler ces lacunes.


Tous les Livres Blancs