Les vulnérabilités de sécurité de SQLite vous inquiètent ?
Il faut se faire à l'idée : le stockage local et persistant des données en périphérie est inévitable
Il est indéniable que l'intelligence en périphérie va se développer, qu'il s'agisse d'applications mobiles fonctionnant sur des smartphones, d'applications IoT intégrées aux voitures connectées (ou aux capteurs sous-jacents), aux centres de divertissement, aux systèmes de navigation, etc. Il existera d'innombrables scénarios mobiles et IoT – considérés dans leur ensemble comme des scénarios en périphérie – où une application native constituera une meilleure approche qu'une application Web, ou où il serait inefficace/potentiellement moins sûr de renvoyer des données brutes depuis les points de collecte IoT – plutôt que de traiter les données et de stocker ou d'effacer localement les données d'entrée.
La complexité des processus et workflow périphérie, la possibilité d'effectuer des analyses directement sur le lieu d'action, ainsi que la nécessité de travailler en mode hors connexion ou avec des connexions instables sont autant d'exemples qui expliquent pourquoi vous aurez besoin d'un stockage de données local et, par conséquent, d'une base de données locale. Il ne fait aucun doute que le volume de données associées à ces applications va exploser.
Malheureusement, il est tout aussi inévitable que les failles de sécurité et les attaques opportunistes qui ciblent ces faiblesses se multiplient dans un avenir proche. Plusieurs études et enquêtes menées ces dernières années montrent clairement que les logiciels destinés à l’IoT et aux appareils mobiles présentent un nombre bien plus important de failles de sécurité que plateformes de bureau ou d’ordinateurs portables, plus matures, sans parler des logiciels fonctionnant sur les serveurs des centres de données. N'oublions pas qu'il y a dix ans, chaque faille de sécurité dans le cloud suscitait un sentiment de panique et a peut-être ralenti l'adoption des services cloud. C'est très bien là où nous en sommes aujourd'hui avecgestion des données localisée et Embarqué gestion des données les appareils en périphérie.
À titre d'exemple, une faille de sécurité très grave a été découverte ce week-end dans SQLite et dans la version intégrée à Chromium (le moteur open source de Google Chrome). Bien qu'il ne s'agisse ni de la première ni de la plus grave faille potentielle découverte dans gestion des données open source gestion des données après tout, le virus Heartbleed de 2014, qui exploitait OpenSSL, détient probablement ces deux records –, cette vulnérabilité étant associée à SQLite, une base de données quasi omniprésente dans les applications mobiles natives et web, ainsi qu'à ses API, nous devons nous préparer à une réaction instinctive : peut-être que les données ne devraient pas être stockées localement sur les appareils périphériques et que tout devrait être géré dans le cloud, où l'on suppose que c'est plus sûr (mon Dieu, comme les temps ont changé).
Une réduction des effectifs serait une réaction excessive
Tout d'abord, SQLite est bien plus performant qu'une combinaison d'allocation de mémoire temporaire et de systèmes de fichiers plats, une approche que je ne recommanderais jamais à quiconque que je considère comme un ami. Pourquoi ? Contrairement à l'allocation de mémoire et à l'utilisation de fichiers plats, qui offrent peu de normalisation, d'indexation intégrée ou d'autres fonctionnalités réelles de manipulation des données, SQLite fournit support de base des bases de données support l'intelligence en périphérie.
SQLite peut fonctionner sur un appareil pour support une utilisation support optimisée des ressources de calcul locales, offrant ainsi à une application la possibilité de gestion des données local gestion des données tout en proposant le même ensemble d'appels d'API pour une version web de cette même application, voire de fonctionner à la fois sur les composants natifs et web d'une application plus complexe. Il prend en charge la plupart des appels d'API SQL, ce qui en fait également un standard.
Se contenter de cela serait tout aussi mauvais
Cependant, SQLite présente de nombreux inconvénients par rapport à une Embarqué commerciale de niveau entreprise. Notamment, elle ne dispose pas de chiffrement intégré pour données au repos en transit, et encore moins avec une clé de 128 bits ou plus. Elle ne peut en outre Embarquer une seule application et Embarquer une seule instance ; elle ne peut donc pas être étendue pour support utilisateurs devant envoyer ou recevoir des données à partir de cette image SQLite.
Par exemple, si vous installiez SQLite sur une passerelle et que plusieurs appareils IoT en aval tentaient d'écrire des données dans cette instance SQLite, il serait impossible de gérer plusieurs clients (appareils IoT en aval) écrivant simultanément dans la base de données SQLite – une exigence dans un environnement IoT comptant souvent des dizaines, des centaines, voire des milliers d'appareils en aval. Cependant, les bases de données client-serveur sont capables de gérer des centaines ou des milliers de clients en aval actifs ; par conséquent, les utilisateurs de fichiers plats et de SQLite doivent toujours associer leurs applications qui envoient ou reçoivent des données à MS SQL, mySQL, Oracle ou une autre base de données client-serveur. Cette association garantit que le reformatage des données ou l'ETL (Extract, Transform, Load) est un mal nécessaire.
L'ETL présente trois inconvénients majeurs auxquels la plupart des architectes de données et des développeurs sont confrontés : le coût de l'intégration, les performances et la sécurité des données. Je réserverai les questions de coût et de perte de performances pour un autre article, mais la sécurité des données mérite d'être abordée ici. En l'absence d'une architecture unique pour la gestion des bases de données client et serveur, même si vous disposiez d'un chiffrement intégré, vous n'auriez d'autre choix que de déchiffrer puis de rechiffrer vos données pour pouvoir exécuter les fonctions ETL – même si vous n'aviez aucune autre manipulation de données à effectuer. Cette nécessité de déchiffrer signifie que vos données sont exposées aux pirates informatiques, même si ce n'est que temporairement.
Une solution optimale pour gérer les données en toute sécurité à la périphérie
La gamme de bases de données Actian Zen repose sur une architecture unique, évolutif qui permet à Zen de fonctionner sur des machines virtuelles dans le cloud, dans pratiquement n'importe quel environnement d'exploitation, qu'il s'agisse de Windows, Linux ou Mac OS en tant que base de données client-serveur à part entière, ou encore de Windows IoT Core, des distributions Linux Raspbian, d'Android et d'iOS en tant que gestion des données en périphérie allégée de 2 Mo, exclusivement côté client. Comme Actian Zen fonctionne sur pratiquement n'importe quel support grâce à des API entièrement transférables (vous pouvez utiliser SQL directement ou des API NoSQL/SQL par programmation à partir des langages de programmation les plus courants), un moteur et un stockage de fichiers sous-jacent, il ne nécessite aucun ETL. Il dispose également d'un chiffrement 192 bits au repos et en transit, ce qui élimine à la fois les coûts d'intégration et les vulnérabilités en matière de sécurité des données, tout en améliorant les performances.
Résumé
En ce qui concerne SQLite et les récentes failles de sécurité mises au jour, la réponse doit consister à combler ces failles et à réduire les risques en corrigeant SQLite ou en adoptant une solution de classe entreprise supérieure telle qu’Actian Zen. La solution ne consiste pas à éviter ou à limiter fortement le stockage des données sur des appareils locaux. De telles contraintes freineraient l’innovation et les améliorations qui découleront sans aucun doute de l’intelligence Embarqué point d’action. La sécurité du cloud a connu des améliorations notables parce que les fournisseurs, les clients du secteur et les organismes de normalisation, ainsi que les pouvoirs publics (spécifications NIST, FEDRamp, etc.) ont relevé le défi, au lieu de se replier sur des environnements hérités. Il y aura toujours des risques, mais l'important est de les gérer en passant de contrôles de sécurité statiques, réactifs et périodiques à une approche de diagnostic et de surveillance continue, fondée sur les risques. Il n’en ira pas autrement à terme pour la sécurité des données mobiles et de l’IoT, car les fournisseurs – comme Actian – travaillent ensemble pour aider les clients à garder leur sang-froid et à sécuriser leurs données à la périphérie.
Si vous êtes prêt à reconsidérer SQLite, renseignez-vous sur Actian Zen. Vous pouvez également vous familiariser gratuitement avec Zen Core, qui est libre de droits pour le développement et la distribution.
Restez connecté
Des informations exploitables à votre disposition.
(par exemple, sales@..., support)
