Sécurité des applications

La vérité sur la sécurité des applications, c'est qu'il ne s'agit pas vraiment de sécurité des applications. Les pratiques de codage sécurisé sont une bonne chose — s'il te plaît, nettoie tes entrées, les amis. Mais en réalité, c'est peut-être la plus petite pièce d'un puzzle de cybersécurité bien plus vaste.

Les objectifs fondamentaux de la sécurité des applications sont simples : tu ne veux pas te faire pirater et tu ne veux pas que tes applications tombent en panne.

Malheureusement, un nombre incroyablement élevé de personnes, pour une raison ou une autre, veulent te pirater et mettre tes systèmes hors service. Et ce n’est même pas personnel. C’est leur travail. Ils sont payés pour ça. Et leurs patrons ne veulent pas perdre leur temps inutilement. 

Comme tout bon professionnel, ces pirates automatisent leurs actions. 

Tu n’as pas besoin d’être quelqu’un de spécial pour être une cible. Tu n’as pas besoin d’avoir un milliard en banque. Et tu ne peux pas te cacher dans la foule. Les ordinateurs sont rapides. Souvent plus rapides que ce qu’on imagine intuitivement. Même si tu as quelque chose caché derrière un milliard de permutations, il faut moins d’une seconde à un ordinateur pour toutes les essayer.

J'adore cette blague : quelques touristes se promènent dans la jungle quand ils aperçoivent un magnifique tigre qui a l'air affamé. « Sauvez-vous ! » crie quelqu'un. Et tous, sauf un, se mettent à courir. Il s'arrête, sort des chaussures de course de son sac à dos et les enfile. Un autre de ses camarades, toujours en train de courir, lui crie : « Mais tu es fou ?! Tu crois que tu peux courir plus vite qu’un tigre ?! » – Il répond : « Je n’ai pas besoin de courir plus vite que le tigre, j’ai juste besoin de courir plus vite que toi. »

Cette blague a été utilisée pour expliquer aux gens qu’ils ne doivent pas être des « cibles faciles » : tu dois te montrer assez fort pour que le tigre affamé passe à la prochaine proie appétissante. 

Mais, comme tu le sais peut-être, le grand tueur des forêts n’est pas le redoutable tigre. Ce sont les moustiques qui t’attrapent. Il y a assez de cibles pour tous les moustiques assoiffés et assez de moustiques pour piquer quiconque n’est pas couvert.

Et même si certains systèmes sont évidemment plus importants que d’autres et méritent davantage de protection – tous les systèmes informatiques de la planète ne contiennent pas des codes de lancement nucléaire –, tous en ont besoin. La question n’est pas de savoir si tu vas être attaqué, mais quand. Et « quand », c’est pratiquement tout le temps, et quelques minutes après la mise en service de ton système (voire avant, nous y reviendrons).

Partons du principe que tu es un développeur de logiciels sérieux et que tu appliques des pratiques de codage sécurisé. Tu nettoies tes entrées comme tes parents te l’ont appris. Tu réduis la surface d’attaque. Tu mets en place une défense en profondeur. Tu construis ton système pour utiliser des secrets éphémères (afin qu’ils ne traînent évidemment pas sur des disques durs). 

Le problème, c’est que le logiciel en soi ne fait pas grand-chose. Ou rien du tout. Pour faire des choses utiles, il a en fait besoin de bien plus. Un moyen de le construire — y compris ses dépendances. Un endroit où le construire. Une configuration. Parfois avec des secrets (car même si tu n’utilises que des secrets éphémères, l’API que tu utilises pourrait exiger une clé API statique). Des systèmes d’exploitation sous-jacents dotés d’un stack réseau — qui, espérons-le, ne l’expose que comme elle est censée l’être. Des bases de données. Des files d’attente de messages. Des caches. Il y a aussi des données. Des données qui peuvent servir de vecteur (les noms d’utilisateur et les mots de passe sont aussi des données).

En fait, quand on y regarde de plus près, si l’on prend un système trivial et le nombre de lignes de code qui s’exécutent, toutes pourraient cacher un problème de sécurité. Imaginons une application Ruby on Rails typique :

• Application Rails typique : 15 443 lignes de code. 
• Ruby on Rails : 338 728 lignes de code. 
• Dépendances par défaut de Ruby on Rails : 1 161 724 lignes de code. 
• Postgres : 1 491 985 lignes de code. 
• Linux : 34 279 868 lignes de code. 

Le petit carré vert, c'est ton code. Sur une vraie image, tu ne pourrais même pas le voir. Et ça, c'est sans SystemD : ajoute 1,3 million de lignes rien que pour ça. Et ça, c'est sans distribution. Sans OpenSSL, etc. – et avant même de prendre en compte tout le reste du code qui va entrer en jeu pour déployer et faire tourner ton application. Ta pile d'observabilité. Tes outils d'orchestration.

Source : https://xkcd.com/2347/ 

Tu connais XKCD 2347… c’est un peu la même situation, mais à l’envers. Et imagine qu’on superpose les deux images : la vérité, c’est que la majeure partie de l’application n’a pas été écrite par toi, donc il y aura forcément une faille quelque part. Et même ça, c’est une vision assez statique des choses. La réalité est différente.

Les gens sont le maillon faible

Le logiciel le plus sécurisé peut être compromis par une seule personne qui commet une erreur ou qui est victime d’une attaque d’ingénierie sociale. Sensibiliser les utilisateurs aux bonnes pratiques de sécurité est tout aussi important, sinon plus, que les fonctionnalités de sécurité intégrées au logiciel.

L'infrastructure compte

Même si une application est sécurisée, l’infrastructure sur laquelle elle fonctionne doit également l’être. Cela inclut les serveurs, le réseau et même les installations physiques qui hébergent le matériel. Une faille dans l’un de ces domaines peut compromettre la sécurité de l’application.

Une approche globale de la sécurité

Un environnement véritablement sécurisé prend en compte non seulement la sécurité des applications, mais aussi la sécurité du réseau, la sécurité des terminaux, la gestion des identités et des accès, la sécurité des données, et bien plus encore. Tous ces éléments fonctionnent ensemble.

C'est une question de gestion des risques

La sécurité absolue est impossible. Il s'agit de comprendre les risques, de les hiérarchiser et de les gérer efficacement. Cela inclut des évaluations de sécurité régulières, une surveillance et une approche proactive face aux vulnérabilités potentielles.

Un processus continu

La sécurité n'est pas une action ponctuelle. De nouvelles vulnérabilités sont découvertes chaque jour, et les acteurs malveillants font évoluer leurs techniques en permanence. Des mises à jour, des correctifs et une surveillance réguliers sont essentiels pour garantir que les mesures de sécurité sont toujours à jour.

Considérations relatives à la confidentialité

Une application sécurisée respecte également la vie privée des utilisateurs. Parfois, la frontière entre sécurité et vie privée peut être floue. Par exemple, si la collecte de données utilisateur peut renforcer les mesures de sécurité, elle peut aussi porter atteinte au droit à la vie privée des utilisateurs.

Conformité et réglementations

La sécurité des applications implique également le respect de diverses réglementations et normes, qui peuvent varier selon le secteur et la région. Cela peut inclure le RGPD pour la protection des données, la norme PCI DSS pour la sécurité des cartes de paiement, la loi HIPAA pour les informations de santé, et bien d’autres encore.

Risques liés aux fournisseurs et aux tiers

Une application peut être sécurisée, mais si elle s'intègre à des services tiers ou à des fournisseurs qui ne le sont pas, l'ensemble du système devient vulnérable. Cela signifie que sécuriser une application implique également de s'assurer que toutes ses connexions et intégrations sont sécurisées.

La dure réalité, c'est que cet enchevêtrement de risques et de préoccupations est en grande partie inévitable dans la mise à disposition des applications modernes. On ne peut pas être experts en tout, ni surveiller tous ces éléments qui changent constamment autour de nous.

Au final, mieux vaut l’accepter le plus tôt possible, et choisir une plateforme d’applications cloud axée sur la sécurité comme Upsun facilite grandement cette démarche. Upsun apporte son expertise en matière de sécurisation de l’infrastructure, en s’appuyant sur des définitions explicites pour définir le contrôle d’accès, et en gérant les services en continu en arrière-plan pour atténuer les risques et rester toujours conforme, même pour les données les plus sensibles. 

Protéger le code que tu n’écris pas toi-même est difficile, pour de nombreuses raisons différentes. Apprends tout ce que tu peux et veille à ce que ton équipe et toi-même soyez aussi bien informés que possible sur les meilleures pratiques. Sinon, accepte le fait que nous ne pouvons pas tous être des experts, contrôle ce que tu peux de la manière la plus stricte possible, et considère qu’en matière d’infrastructure et de DevOps, un expert comme Upsun pourrait être ton arme secrète.