La problématique
Le contrôle d’accès vise à garantir qu’un utilisateur particulier a les permissions suffisantes pour :
Créer, lire, mettre à jour ou supprimer une ressource sécurisée ;
Accéder à une fonction sécurisée (back end d’administration par exemple) ;
Réaliser un processus métier protégé.
Mettez en place les bonnes pratiques
Le principe du moindre privilège
Les bonnes pratiques en la matière sont les suivantes :
Identifier des privilèges nécessaires à un composant. Il s’agit d’identifier une liste d’actions qu’il doit être capable de mener à bien dans son environnement d’exécution ;
Créer un environnement d’exécution réduit à cette liste d’actions (ou s’en rapprocher le plus possible). Des mécanismes de cloisonnement, disponibles au niveau de l’environnement d’exécution, sont mis en œuvre dans ce but. Par exemple, les dispositifs de contrôle d’accès dans le système de fichiers ou pour les accès réseau, l’utilisation de modes du processeur pour différencier les pages accessibles en mode privilégié des pages accessibles en mode utilisateur, l’usage de machines virtuelles différentes au sein d’un hyperviseur ;
Itérer cette pratique sur chaque composant. Scinder l’environnement d’exécution global d’un ensemble de composants en une série de sous-environnements appauvris.
Autres bonnes pratiques
Les accès par défaut pour des ressources protégées doivent être interdits. Ils ne doivent être autorisés que si le demandeur possède explicitement les droits ;
Il est recommandé de réaliser le contrôle d’accès sur le serveur ;
Il peut être utile d’implémenter un accès limité à quelques requêtes sur la base d’une fréquence raisonnable. Par exemple, le nombre de requêtes HTTP sur une ressource peut être limité ou bien l’accès des requêtes sur la couche de la base de données pour empêcher les téléchargements abusifs. À ce titre, Google a limité l’accès à l’API Google Maps à 10 000 requêtes par jour et par utilisateur ;
Il convient d’utiliser un mécanisme de contrôle d’accès centralisé. Si les décisions d’accès sont réalisées séparément dans chaque composant, des mises à jour pourraient ne pas être propagées dans l’ensemble de l’application ;
Il peut être intéressant de tracer toutes les décisions d’accès dans des journaux (ou logs) afin de pouvoir les étudier plus facilement.
L’exemple de la bibliothèque OAuth 2.0
Pour illustrer ces mécanismes, je vous propose de voir comment on peut intégrer le contrôle d’accès grâce au service web OAuth 2.0.
Découvrez OAuth 2.0
Le protocole définit 4 rôles :
Le détenteur des données (vous) ;
Le serveur de ressources qui héberge les accès dont l’accès est protégé (les informations de votre profil Facebook par exemple) ;
Le client qui souhaite accéder au serveur de ressources ;
Le serveur d'autorisation qui délivre des jetons au client.
Contrôlez les accès avec OAuth 2.0
Le client demande l’accès aux ressources contrôlées par le détenteur et hébergées sur le serveur de ressources. Le client reçoit alors un certain nombre de privilèges différents de ceux que le détenteur possède.
Le client utilise ensuite le jeton d’accès pour travailler avec les données protégées hébergées sur le serveur de ressources (Google ou Facebook par exemple).
OAuth 2.0 prévoit par ailleurs 4 niveaux d’autorisation possibles :
L’autorisation via un code est utilisée dès que possible et en particulier quand le client est un serveur Web ;
L’autorisation implicite est utilisée quand l’application se trouve côté client (développée en JavaScript par exemple) ;
L’autorisation par mot de passe est utilisée quand une confiance absolue existe entre le client et le serveur d'autorisation, car les identifiants leur sont envoyés ;
L’autorisation de serveur à serveur est utilisée lorsque le client est lui-même le détenteur de données.
Pour comprendre son utilisation, voyons en détail un exemple pratique dans le cas d’une autorisation via code. Imaginons la situation suivante :
Détenteur des données (Resource Owner) : vous ;
Serveur de ressources (Resource Server) : un serveur Google ;
Client (Client Application) : l’application Slack qui permet la conversation instantanée entre membres d’une même équipe ;
Serveur d’autorisation (Authorization Server) : un serveur Google.
Le processus de demande est le suivant :
Slack souhaite accéder aux informations de votre profil Google ;
Vous êtes redirigé par Slack vers le serveur d’autorisation Google ;
Si vous autorisez l’accès, le serveur d’autorisation (Google) envoie un code d’autorisation à Slack grâce une requête HTTP qui pourrait être :
POST /oauth2/v4/token HTTP/1.1 Host: www.googleapis.com Content-Type: application/x-www-form-urlencoded code=code_autorisation& client_id=identifiant& client_secret=secret& redirect_uri=https://example.com/oauth2-redirect& grant_type=authorization_code
En réponse à cette requête, Google génère le jeton d’accès au format JSON :
{
"access_token":"access_token_1",
"expires_in":3000,
"token_type":"Bearer"
}Slack peut maintenant accéder à votre profil utilisateur en ajoutant dans chacune des requêtes un entête HTTP Authorization contenant la valeur Bearer access_token_1 .
En conclusion, ce protocole met à disposition des RSSI et développeurs un large spectre d’outils. Les documentations officielles de Google et de Facebook contiennent des exemples simples sur l’utilisation du framework OAuth 2.0 et sur les possibilités d’extension de celui-ci.
Les règles de sécurité en jeu pour implémenter un serveur OAuth 2.0 fiable étant assez nombreuses et complexes, je vous recommande d’utiliser une librairie déjà existante. Si, cependant, votre objectif est d’implémenter un service propre à votre organisation, je vous conseille la RFC 6749 qui demeure la meilleure référence.
