La sécurité informatique est un sujet délicat, d’autant plus qu’il n’existe pas encore de recette miracle permettant de s’assurer qu’un système est protégé correctement.

Il est cependant assez facile d’évaluer la surface d’attaque, c’est à dire les zones visibles de votre service.

Cette méthode s’applique aussi bien à une infrastructure complexe qu’à un site Web basique : seule l’échelle change.

Dans le cas d’une infrastructure, on s’intéressera principalement aux relations qui existent entre les services, et en particulier entre le monde extérieur et nous.

Dans le cas d’un site Web, tout ce qui est visible et modifiable peut être utilisé pour une attaque : les formulaires, les adresses URI, les Cookies … et on tentera de représenter le lien qui existe entre les données entrées par l’utilisateur et les conséquences qu’elles ont (par exemple, appeler une API, lire un fichier et l’afficher, executer une commande).

Dans le cas d’une machine (personnelle ou non), on considère que les surfaces d’attaque sont les logiciels installés et les ports qu’ils ouvrent. Il faut aussi considérer, même si c’est moins fréquent, les accès effectués par les programmes. Deux exemples d’accès à surveiller :

  • Puppet qui récupère sa configuration ailleurs (cet ailleurs est-il protégé ? Des données sensibles sont elles transmises ? Sont-elles vérifiées ?)
  • Un programme qui se met à jour automatiquement: Faille MitM OS X ou encore Un virus distribué avec Puush.

Une image vaut 1000 mots. Voici comment je représenterais une infrastructure type, avec des locaux et un VPN pour restreindre l’accès aux données. Je l’ai bien entendu simplifié : en théorie, un accès existe entre les bureaux et les données.

Il y a globalement 3 zones : le monde extérieur, le réseau privé avec accès restreint et les Bureaux.

En considérant qu’une attaque peut provenir du monde (on fait confiance aux employés), la surface d’attaque est :

  • Le site Web
  • Le serveur mail
  • Les bureaux

C’est bon, notre infrastructure est sécurisée ! Pas tout à fait. On peut faire confiance aux employés, mais encore faut il s’assurer que les droits d’accès sont bien gérés, que les mots de passes sont uniques et changés régulièrement, et qu’une intrusion n’est permise par l’accès internet (les bureaux)

On peut faire confiance au serveur Mail, il est développé par un tiers et probablement utilisé par des milliers de sociétés.

Cependant, pirater un site Web est assez facile, et on va donc se concentrer sur ce point.

Dans le pire des cas, le serveur Web est corrompu. Que se passe-t-il, après ? On regarde notre schéma, et on voit directement à quoi le serveur Web a accès : il est dans notre réseau privé, et possède un accès aux serveurs Mail et Bases de Données. Autant dire un accès global. Et votre “réseau privé” devient inutile. (cf The End Of The Fortress Metaphor sur Clevercloud)

Mais que faire ? Le site Web a besoin de cet accès au serveur MySQL ! Pour commencer, on peut regarder ce que le site permet de faire. Et on peut même le faire sous forme de schéma, pour voir les droits et relations.

Plusieurs choses deviennent alors claires : le serveur Web correspond en fait à deux services : un service interne, sans doute protégé par le réseau interne et par des identifiants, et la partie publique, qui est globalement en lecture seule.

La première chose que l’on peut alors faire est séparer les deux services et leurs accès à la base de données : interne aurait accès à tout en lecture/écriture, et la partie publique n’aurait accès qu’aux données client en écriture. Le contenu, les factures et la liste des employés est déjà un peu plus en sécurité.

Sur ce schéma, on remarque aussi autre chose : le site Web se comporte comme un tunnel et fait le lien entre la base de données et le monde extérieur. Il peut être bon d’ajouter la base de données à la surface d’attaque. Une solution serait d’utiliser une API interne afin de gérer proprement les droits d’accès. De plus, il est peu probable qu’une faille se glisse dans cette API. L’API devra bien évidemment prendre la place du Site Web sur le schéma, mais on peut désormais isoler {Site Web; API} ensemble. Si le site Web est corrompu, l’accès aux données sera ralenti et les actions seront enregistrées.

Pour résumer, en trouvant les surfaces d’attaques, vous êtes en mesure de repenser votre infrastructure afin de limiter les dégâts potentiels. Questionnez tout. Respectez autant que possible le Principe de Moindre Autorité (POLA: Principle of Least Authority) selon lequel vos services ne devraient pas avoir de privilèges superflus.