Sécurité des applications

La vérité sur la sécurité des applications 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 vous plaît, désinfectez vos entrées. Mais en réalité, il s'agit probablement de la plus petite pièce d'un puzzle de cybersécurité beaucoup plus vaste.

Les objectifs de base de la sécurité des applications sont les suivants : vous ne voulez pas être piraté et vous ne voulez pas que votre (vos) application(s) tombe(nt) en panne.

Malheureusement, un nombre incroyablement élevé de personnes, pour une raison ou une autre, veulent vous pirater et faire tomber vos systèmes. Et ce n'est même pas personnel. C'est leur travail. Ils sont payés pour cela. Et leurs patrons ne veulent pas perdre leur temps inutilement.

Comme tout bon professionnel, ces hackers automatisent.

Il n'est pas nécessaire d'être spécial pour être une cible. Il n'est pas nécessaire d'avoir un milliard à la banque. Et vous ne pouvez pas vous cacher dans la foule. Les ordinateurs sont rapides. Souvent plus vite que nous ne l'imaginons intuitivement. Même si quelque chose est caché derrière un milliard de permutations, il faut moins d'une seconde à un ordinateur pour essayer chacune d'entre elles.

J'adore cette blague : quelques touristes se promènent dans la jungle lorsqu'ils aperçoivent un tigre magnifique et affamé. "Quelqu'un s'écrie : "Courez pour sauver votre peau ! 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 dépasser un tigre ?!". - Il répond : "Je n'ai pas besoin de dépasser le tigre, j'ai seulement besoin de te dépasser".

Cette blague a été utilisée pour expliquer aux gens qu'ils ne doivent pas être des "cibles faciles" - vous devez vous montrer suffisamment fort pour que le tigre affamé passe à la prochaine cible délicieuse.

Mais, comme vous le savez peut-être, le grand tueur des forêts n'est pas l'impressionnant tigre. Ce sont les moustiques qui vous attaquent. Il y a suffisamment de cibles pour tous les moustiques assoiffés et suffisamment de moustiques pour piquer tous ceux qui ne sont pas couverts.

Et 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 les codes de lancement nucléaire -, tous en ont besoin. La question n'est pas de savoir si l'on est attaqué, mais quand on l'est. Et quand, c'est la plupart du temps tout le temps et quelques minutes après que votre système a été mis en service (et peut-être même avant, nous y reviendrons).

Prenons pour acquis que vous êtes un développeur de logiciels sérieux et que vous appliquez des pratiques de codage sécurisées. Vous désinfectez vos entrées comme vos parents vous l'ont dit. Vous minimisez la surface. Vous créez une défense en profondeur. Vous construisez votre système de manière à utiliser des secrets éphémères (il est donc évident qu'ils ne traînent pas sur les disques durs).

Le problème est que les logiciels en eux-mêmes ne font pas grand-chose. Ou rien du tout. Pour faire des choses utiles, il a besoin de beaucoup plus. Un moyen de le construire - y compris ses dépendances. Un endroit où le construire. Une configuration. Parfois avec des secrets (parce que même si vous ne faites que des secrets éphémères, l'API que vous utilisez peut vouloir une clé d'API statique). Des systèmes d'exploitation sous-jacents avec une pile réseau - qui, espérons-le, ne l'expose que de la manière dont elle souhaite être exposée. Bases de données. Files d'attente de messages. Caches. Il y a aussi les données. Des données qui peuvent être un vecteur (les noms d'utilisateur et les mots de passe sont également des données).

En fait, si l'on considère un système trivial et le nombre de lignes de code qui s'exécutent, il est possible qu'un problème de sécurité s'y cache. Imaginons une application Ruby on Rails typique :

• Une application Rails typique : 15 443 lignes de code.
• Ruby on Rails : 338 728 lignes de code.
• Les 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 est votre code. Dans une image réelle, vous ne pourriez pas le voir. Ceci sans SystemD : ajoutez 1,3 millions de lignes rien que pour celui-ci. Et ceci sans distribution. Sans openssl etc - et avant de considérer tout le reste du code qui sera dans la boucle pour déployer et exécuter votre application. Votre pile d'observabilité. Votre outil d'orchestration.

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

Vous savez, XKCD 2347 ... c'est un peu la même chose, mais dans l'autre sens. Et je pense que si nous combinons les deux images, la vérité est que la plus grande partie de l'application n'a pas été écrite par vous - elle aura une lacune quelque part. Et même cela est une sorte de vue statique des choses. La surface réelle est différente.

Les personnes sont le maillon faible

Le logiciel le plus sûr peut être sapé par une simple personne qui commet une erreur ou qui est ciblée avec succès par l'ingénierie sociale. La formation des utilisateurs aux meilleures pratiques de sécurité est tout aussi importante, sinon plus, que les fonctions de sécurité intégrées du logiciel.

L'infrastructure est importante

Même si une application est sécurisée, l'infrastructure sur laquelle elle fonctionne doit l'être également. Il s'agit des serveurs, du réseau et même des installations physiques abritant le matériel. Une faille dans l'un de ces domaines peut compromettre la sécurité de l'application.

Approche holistique 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, etc. 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 implique des évaluations régulières de la sécurité, une surveillance et une approche proactive des vulnérabilités potentielles.

Un processus continu

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

Respect de la vie privée

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

Conformité et réglementation

La sécurité des applications implique également d'adhérer à diverses réglementations et normes, qui peuvent varier selon le secteur et la région. Il peut s'agir du GDPR pour la protection des données, du PCI DSS pour la sécurité des cartes de paiement, de l'HIPAA pour les informations de santé, etc.

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 pour sécuriser une application, il faut également s'assurer que toutes ses connexions et intégrations sont sécurisées.

La dure réalité est que cet enchevêtrement de risques et de préoccupations est en grande partie inévitable dans la fourniture d'applications modernes. Nous ne pouvons pas être experts en tout, ni surveiller tous ces éléments qui changent en permanence autour de nous.

En fin de compte, nous nous porterons mieux si nous l'acceptons le plus tôt possible, et le choix d'une plateforme d'application Cloud axée sur la sécurité comme Upsun facilite grandement les choses. Upsun apporte son expertise dans la 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 continuellement les services en coulisses pour atténuer les risques afin de toujours rester conforme, même pour les données les plus sensibles.

Protéger le code que vous n'écrivez pas vous-même est difficile - pour de nombreuses raisons. Apprenez ce que vous pouvez et tenez votre équipe et vous-même au courant des meilleures pratiques. Sinon, acceptez le fait que nous ne pouvons pas tous être des experts, contrôlez ce que vous pouvez aussi strictement que possible, et considérez qu'en matière d'infrastructure et de DevOps, un expert comme Upsun pourrait être votre arme secrète.