Authentification contre autorisation
J'ai référé ce lien et je sais que
Authentification = login + mot de passe (qui vous êtes)
Autorisation = autorisations (ce que vous êtes autorisé à faire)
Ma question est la suivante: supposons que [~ # ~] a [~ # ~] obtient l'ID de connexion et le mot de passe de [~ # ~] b [~ # ~] qui a une autorité supérieure à A, cela compromettrait l'autorisation car une fois que A est faussement authentifié en tant que B, A obtient tous les privilèges d'accès de B.
Alors, quel est tout le point d'autorisation?
Est-il dépendant ou indépendant de l'authentification?
une fois que A est faussement authentifié comme B ...
Sur tout système à sécurité minimale, ce n'est pas ainsi que cela se passe. Du point de vue du système, tilisateur B s'authentifie lui-même, pas tilisateur A. Il n'était pas faussement authentifié, il utilisait le vrai login et mot de passe. C'est un cas simple de vol d'informations d'identification. Vous pouvez durcir le système en utilisant n'importe quelle forme de 2FA, mais le système fonctionne comme prévu.
Il serait faussement authentifié comme vous l'avez dit si tilisateur A utilise ses propres informations d'identification et se retrouve en quelque sorte avec le profil de tilisateur B. Dans ce cas, l'attaque pourrait être un contournement d'authentification ou une escalade de privilèges, et le système devrait être corrigé.
Alors, quel est tout le point d'autorisation?
Séparer les privilèges selon qui vous êtes. Si quelqu'un peut utiliser vos informations d'identification, c'est essentiellement vous, donc l'autorisation est toujours valable.
Il est dépendant ou indépendant de l'authentification?
Il est indépendant (bien que de nombreux systèmes d'autorisation choisissent de dépendre des informations d'authentification). L'authentification, c'est qui vous êtes. L'autorisation est vos privilèges. Les systèmes d'authentification unique, par exemple, sont utilisés pour appliquer l'identité, et un autre système doit être utilisé pour appliquer les autorisations.
L'autorisation et l'authentification sont les deux faces d'une même médaille, où l'autorisation dépend parfois de l'authentification, mais pas toujours. Comment?
Même sans connexion, un visiteur de Stack Exchange peut voir les questions et réponses. Ici, le visiteur a l'autorisation de voir les réponses mais n'a sûrement pas besoin d'authentification pour cela, donc ici l'autorisation est indépendante de l'authentification.
Un utilisateur connecté est autorisé à publier des questions ou à répondre à une question, mais pour cela, il doit fournir une connexion appropriée, donc ici, l'autorisation dépend de l'authentification.
En bref, bien sûr, si l'authentification est compromise, cela entravera également l'autorisation.
D'une manière générale, c'est une bonne idée de considérer les quatre As (authentification, autorisation/contrôle d'accès, comptabilité, audit) plutôt que deux.
Il n'y a aucune méthode d'authentification qui peut contrer de manière fiable la méthode de la clé à 5 $ (comme décrit par le webcomic XKCD, c'est là que vous frappez quelqu'un avec une clé à 5 $ jusqu'à ce qu'il se connecte pour vous) bien qu'il existe des méthodes (telles que le code d'accès + 1) qui peut alerter le système que la clé de 5 $ est utilisée. C'est un monde méchant.
L'authentification est la seule étape qui ne dépend pas des autres. Cela signifie que cela doit venir en premier. L'authentification peut être explicite (dites-moi qui vous êtes) ou implicite (je vois par vos certificats matériels que vous vous êtes connecté depuis l'intérieur du bunker). Vous pouvez vous authentifier en tant qu'individu (Consultant Rin) ou en tant que "rôle" (n'importe quel assassin). Les entreprises légalement réglementées sont presque toujours tenues d'utiliser l'authentification individuelle explicite pour que l'audit ait une chance de fonctionner. Si un compte de groupe ou de rôle semble nécessaire, quelque chose ne va probablement pas dans votre compréhension du problème, car il y aura une autre solution que vous ne voyez tout simplement pas.
L'autorisation (qui est souvent appelée contrôle d'accès parce qu'il est très facile de mélanger authentification et autorisation en parlant) est l'octroi de droits à un processus (les utilisateurs connectés ne sont qu'un autre processus du point de vue du processeur) en fonction de leur authentification. Par exemple, si vous êtes J. Random Lusr, vous pourriez seulement avoir le droit de créer des fichiers dans votre dossier personnel. Mais si vous êtes Biff Snidely, aristocrate d'entreprise, vous pouvez également obtenir le droit de créer des fichiers dans un dossier de service partagé. Vous pouvez être soumis à des limites d'espace disque ou d'autres ressources, ou non.
La comptabilité est essentiellement l'enregistrement des ressources utilisées par un processus connecté - cela peut être très simple (Joe a utilisé 1000 cycles de processeur aujourd'hui et a utilisé 1 Go de stockage) ou très élaboré (Biff a émis ces commandes dans cet ordre précisément à ces moments-là ). C'est la base de l'audit. Une comptabilité extrêmement bonne enverra des données du système, de sorte qu'elles ne peuvent pas être supprimées du système local si elles sont piratées.
L'audit est défini de façon plus vague; il peut s'agir d'un processus automatique qui recherche les tentatives d'effectuer des actions que l'utilisateur n'est pas autorisé à effectuer, ou il peut s'agir d'une équipe de gnomes enchaînés dans le sous-sol parcourant les journaux de commandes de la journée, ou tout ce que vous pouvez penser. Le point de l'audit est que l'authentification peut être vaincue par une clé de 5 $, vous ne pouvez donc pas simplement supposer que parce que vos utilisateurs ont des mots de passe durs, personne n'a jamais brisé votre sécurité. Vous ne pouvez même pas supposer que vos utilisateurs ne trouveront pas un moyen de briser les contrôles d'accès par accident, vraiment, cela se produit tout le temps.
Une autre chose à considérer est également l'hypothèse que l'OP fait: "une fois que A est faussement authentifié comme B, A obtient tous les privilèges d'accès de B." n'est pas nécessairement correct dans tous les systèmes et cas d'utilisation.
Par exemple, dans un système avec un flux de travail à double contrôle, je dois d'abord m'authentifier, mais également obtenir une autorisation pour une ressource spécifique de son propriétaire. Le propriétaire peut ou non m'accorder cette autorisation en fonction de nombreux autres facteurs en dehors de mon authentification, par exemple, certaines ressources ne doivent être accessibles qu'à des moments précis de la journée.
Une bonne analogie que j'utilise pour penser au sujet est la suivante:
L'authentification, c'est comme avoir une carte-clé pour un bâtiment.
L'autorisation est à quelles pièces du bâtiment je peux accéder une fois que je suis dedans, en particulier si ma carte de construction a été volée et que j'approche d'une pièce gardée par quelqu'un qui ne me reconnaît pas, je ne serai peut-être pas autorisé à l'intérieur :)
Votre question met en évidence la nécessité de mécanismes d'authentification robustes et la raison pour laquelle beaucoup depuis un certain temps ont considéré le mot de passe comme un contrôle "mort". De plus, c'est la raison pour laquelle l'authentification multifacteur gagne du terrain.
Faisons tourner votre question cependant: supposons qu'une organisation dispose d'un système qui héberge des informations financières, administratives et autres sur les ressources humaines. Maintenant, la personne A est authentifiée (correctement) et elle est autorisée à ne voir que les informations administratives. Si nous prenions votre argument et disions: "Eh bien, nous ne pouvons pas faire confiance à notre authentification, alors ne nous soucions pas de l'autorisation", vous donneriez à la personne A un accès aux données financières et RH, même si elle ne devrait pas être autorisée à les voir.
L'authentification répond à cette question: êtes-vous qui vous dites être? De nombreuses façons de le faire, mais comment cela n'a pas d'importance. Certains moyens sont évidemment plus efficaces ou plus fiables que d'autres. Vous pouvez également le considérer comme deux questions: qui êtes-vous? Comment je peux être sûr?
L'autorisation répond à l'une de ces questions: que pouvez-vous faire? Êtes-vous autorisé à faire X? Vous pouvez le faire sans authentification, mais pourquoi le feriez-vous? À quoi ça sert?
Pour moi, l'explication la plus simple est la suivante:
L'authentification indique au système qui vous êtes. L'autorisation indique au système ce que vous pouvez faire.
Si le client A a obtenu le login et le mot de passe de B et a réussi à authentifiez comme B , à toutes fins utiles auprès du serveur "dupé", - A est maintenant B et est autorisé pour faire tout ce que B peut faire.
Bien que l'autorisation fonctionne indépendamment de l'authentification, je dirais que l'authentification est une condition préalable à l'autorisation - comment le système peut-il savoir ce que vous pouvez faire s'il ne sait pas qui vous êtes?
Votre hypothèse n'a pas vraiment de sens. Vous dites que quelque chose est compromis parce que quelqu'un a obtenu les informations d'identification de quelqu'un d'autre qui ont plus d'autorité que les leurs. Il est compromis simplement parce que quelqu'un a obtenu les informations d'identification de quelqu'un d'autre seul. Qu'ils aient une autorité supérieure, identique ou inférieure ne devrait pas avoir d'importance.
Imaginez une situation où un administrateur obtient les informations d'identification d'un utilisateur normal. Maintenant, ils peuvent se faire passer pour cet utilisateur. Avant, bien sûr, ils pouvaient peut-être faire des choses "en tant que" cet utilisateur, mais il y a probablement des journaux quelque part que quelqu'un pourrait vérifier pour voir que c'était l'administrateur agissant en tant qu'utilisateur. Si quelqu'un possède les informations d'identification de cet utilisateur, les journaux montreront que c'était l'utilisateur.
Le point d'autorisation demeure. Différents utilisateurs doivent pouvoir effectuer différentes choses et sans autorisation, ce qui ne peut pas être accompli.
Comme le dit amit thakur dans leur réponse , même les utilisateurs non authentifiés sont autorisés à effectuer certaines tâches telles que l'affichage des questions et des réponses sur ce site Web lorsque vous n'êtes pas connecté. Ainsi, l'autorisation et l'authentification sont des concepts distincts mais étroitement liés.
Imaginez que vous restiez dans un immeuble qui a de nombreux appartements, l'homme de sécurité à la porte sait que vous y habitez réellement, mais ne connaît pas l'appartement exact dans lequel vous vivez, l'authentification se produit au moment où l'homme de sécurité vous identifie comme quelqu'un vivant dans le bâtiment et vous permettre d'entrer.
Cependant, entrer dans le bâtiment ne signifie pas que vous pouvez entrer dans n'importe quel appartement que vous voyez. Par conséquent, l'autorisation se produit lorsque vous accédez à votre propre appartement, car c'est à cela que vous avez été autorisé à accéder.
L'autorisation/l'autorisation dépend de l'authentification, mais ce sont toujours des concepts complètement différents simplement parce que les méthodes d'authentification varient en fonction des niveaux d'autorisation.
Vous pourrez peut-être contourner l'authentification et vous autoriser en tant qu'utilisateur normal, mais pour accéder à la racine, vous devrez peut-être passer par l'authentification multifacteur.
Ma question est la suivante: supposons que A obtient l'ID de connexion et le mot de passe de B qui ont une autorité supérieure à A, cela compromettrait l'autorisation car une fois que A est faussement authentifié en tant que B, A obtient tous les privilèges d'accès de B.
Pas nécessairement. L'autorisation peut être liée à un certain nombre de choses. Par exemple, tilisateur B peut obtenir différents profils d'autorisation en fonction du type d'appareil (ordinateur vs appareil mobile). Ou ils peuvent avoir des profils différents selon la façon dont ils sont connectés au réseau (filaire vs sans fil vs VPN, siège social vs succursale, etc.). Ou, comme dernier exemple, la date/heure peut déterminer quel profil d'autorisation est appliqué à l'utilisateur.
Donc, juste parce que l'utilisateur A peut utiliser les informations d'identification de l'utilisateur B, cela ne signifie pas nécessairement qu'il obtiendra les mêmes privilèges.
Alors, quel est tout le point d'autorisation?
Il vous permet d'administrer de façon centralisée ce qu'un utilisateur/appareil peut faire en fonction d'un grand nombre de facteurs. Il vous permet d'appliquer des privilèges de manière cohérente et plus fiable aux utilisateurs.
Supposons que les responsabilités professionnelles d'un employé changent (il est promu, le poste est modifié, etc.) et vous devez ajuster les privilèges. Vous pouvez le faire en "touchant" chaque ressource dont ils ont besoin pour voir leurs privilèges modifiés. Ou si toutes ces ressources utilisaient un serveur AAA central, une simple modification centralisée des privilèges leur accorderait ces privilèges rapidement et facilement (et moins sujettes à des ressources manquantes ou à des erreurs humaines lors de modifications répétitives). Souvent, cela est aussi simple que de changer/ajouter une appartenance à un groupe à leur compte d'utilisateur.
Ou dites que vous avez plusieurs employés qui devraient avoir les mêmes privilèges. Ils peuvent tous partager le même profil d'autorisation. Encore une fois, plus simple à gérer et assurez-vous que leurs expériences sont toutes cohérentes.
Est-il dépendant ou indépendant de l'authentification?
Dans certains sens, les deux. L'autorisation a lieu après l'authentification, donc d'une part, elle n'a lieu que lorsque l'authentification a lieu (même s'il s'agit d'une "authentification ouverte").
En revanche, l'autorisation est un processus entièrement distinct de l'authentification. L'authentification peut ou non déterminer quel profil d'autorisation est appliqué.