Traitement précis des accès et gestion des données avec une sécurité au niveau de la ligne

De nombreuses applications contiennent des informations ou des données spécifiques à l’utilisateur auxquelles un certain groupe d’utilisateurs et non d’autres peuvent accéder. Ces types d’exigences s’accompagnent d’une demande de gestion d’accès fine. Que ce soit pour des raisons de sécurité ou de confidentialité, le traitement des données sensibles est un sujet important pour toute application. Grand ou petit, personne ne veut être du mauvais côté d’un scandale de fuite de données. Voyons donc ce que signifie gérer des informations sensibles ou confidentielles dans nos applications.

Prenez ça au sérieux

Peu importe si vous demandez l’accès sur Twitter, une banque ou votre bibliothèque locale, vous identifier est une première étape cruciale. Toute sorte de passerelle a besoin d’un moyen fiable pour vérifier si une demande d’accès est légitime.

« L’usurpation d’identité n’est pas une blague. »
— Dwight Schrute

Sur le Web, nous encapsulons le processus d’identification d’un utilisateur et lui accordons l’accès en tant que Authentificationqui représente deux actions liées mais distinctes :

• Authentification: action de confirmer l’identité d’un utilisateur.
• Autorisation: accorder à un utilisateur authentifié l’accès à une ressource.

Il est possible d’avoir une authentification sans autorisation, mais pas l’inverse. La stratégie de mise en œuvre de l’autorisation au niveau de la gestion des données peut être vaguement appelée Sécurité au niveau de la ligne (RLS), mais RLS est en fait un peu plus que cela. Dans cet article, nous approfondirons la gestion des données utilisateur sensibles et définirons les rôles d’accès à une base d’utilisateurs.

Sécurité au niveau de la ligne (RLS)

Une « ligne », dans ce cas, fait référence à une entrée dans une table de base de données. Par exemple, dans un des postes table, une ligne serait un seul articleVérifiez ça json représentation:

{
    "posts": [
        {
            "id": "article_23495044",
            "title": "User Data Management",
            "content": "<huge blob of text>",
            "publishedAt": "2023-03-28",
            "author": "author_2929292"
        },
        // ...
    ]
}

Pour comprendre le RLS, chaque object à l’intérieur des postes est une « ligne ».

Les données ci-dessus sont suffisantes pour créer un algorithme de filtrage afin d’appliquer efficacement la sécurité au niveau des lignes. Néanmoins, il est crucial pour l’évolutivité et la gestion des données que de tels relation est défini sur votre couche de données. De cette façon, tout service qui se connecte à votre base de données disposera de toutes les informations nécessaires pour mettre en œuvre sa propre logique de contrôle d’accès selon les besoins. Ainsi, pour l’exemple ci-dessus, le schéma pour le des postes table ressemblerait à peu près à ce qui suit :

{
    "posts": {
        "columns": [
            {
                "name": "id",
                "type": "string"
            },
            // ... other primitive types
            // establish relationship with "authors"
            {
                "name": "author",
                "type": "link",
                "link": "authors"
            }
        ]
    }
}

Dans l’exemple ci-dessus, nous définissons le type de chaque valeur dans notre des postes base de données et créer une relation au auteurs tableau. Ainsi, chaque poste recevra le id d’un seul auteur. Il s’agit d’une relation un-à-plusieurs : un l’auteur peut avoir beaucoup des postes.

Bien sûr, il existe également des modèles pour définir les relations plusieurs-à-plusieurs. Prenez, par exemple, le backlog d’une équipe. Vous voudrez peut-être que seuls les membres d’une certaine équipe aient accès. Dans ce cas, vous pouvez créer une liste d’utilisateurs ayant accès à une ressource spécifique (et donc être très précis à ce sujet), ou vous pouvez définir une table pour équipeet reliant ainsi un équipe à plusieurs tâches, et un équipe à plusieurs utilisateurs : ce modèle est appelé un tableau de jonction et est idéal pour définir accès délimité dans votre couche de données.

On comprend maintenant ce que autorisation est et ressemble dans quelques cas. Cela devrait suffire à concevoir un modèle mental pour définir l’accès à nos données. Nous comprenons que pour utiliser efficacement l’accès granulaire à nos données, notre application doit être consciente de qui l’utilisateur utilise cette instance particulière de l’application (c’est-à-dire qui est derrière la souris).

Authentification

Il est temps de mettre en place une solution fiable et rentable authentification. Rentable car il est contre-productif de ré-authentifier l’utilisateur à chaque requête. Et cela augmente le facteur de risque d’attaques, alors réduisons au minimum les demandes d’authentification. La façon dont notre application stocke les informations d’identification de l’utilisateur pour les réutiliser dans un cycle de vie défini s’appelle un session.

Il existe plusieurs façons d’authentifier les utilisateurs et de gérer les sessions. Je vous invite à consulter l’article d’Eric Burel sur «Authentification sur les sites Web : une analogie bancaire”. C’est une excellente explication approfondie du fonctionnement de l’authentification.

À partir de ce moment, supposons que nous ayons fait preuve de diligence raisonnable : nom d’utilisateur et mot de passe sont stockés en toute sécurité, un fournisseur d’authentification est en mesure de vérifier de manière fiable l’identité de notre utilisateur et renvoie un sessionqui est un objet portant un userId correspondant à la ligne de notre utilisateur dans la base de données.

Joindre les points

Alors maintenant que nous avons établi ce que cela signifie et les exigences que chaque pièce mobile apporte pour le faire fonctionner, notre objectif est le suivant :

1. Authentification
   Le fournisseur effectue l’authentification de l’utilisateur, la bibliothèque crée un sessionet l’application le reçoit en tant que payload de la demande d’authentification.
2. Demande de ressources
   L’utilisateur authentifié effectue la demande avec resourceId; l’application prend userId depuis session.
3. Accorder l’accès
   Il filtre toutes les ressources de la table uniquement celles appartenant à userId et renvoie (s’il existe) celui avec resourceId.

Avec le modèle mental défini ci-dessus, il est possible de réaliser n’importe quel type de mise en œuvre et de concevoir correctement vos requêtes. Par exemple, sur notre premier schéma défini (messages et auteurs), nous pouvons utiliser des filtres sur notre service de récupération pour ne donner accès qu’aux résultats qu’un utilisateur devrait avoir :

async function getPostsByAuthor(authorId: string) {
    return sdk.db.posts
        .filter({
            author: authorId
        })
        .getPaginated()
}

Cet extrait artificiel est juste pour illustrer une implémentation RLS simple. Peut-être comme matière à réflexion pour que vous puissiez vous en servir.

Conclusion

Espérons que ces concepts ont offert une clarté supplémentaire sur la définition de la gestion de l’accès aux données privées et/ou sensibles. Il est important de noter qu’il existe des problèmes de sécurité avant et autour du stockage de ce type de données qui sortaient du cadre de cet article. En règle générale: stockez aussi peu que nécessaire et ne fournissez que la quantité nécessaire d’accès aux données. Moins les données sensibles transitent par le réseau ou sont stockées par votre application, moins votre application est susceptible d’être la cible ou la victime d’attaques ou de fuites.

Faites-moi part de vos questions ou de vos commentaires dans la section des commentaires ou sur Twitter.

(oui)