Blogs de l’ICANN

Lisez les blogs de l’ICANN pour vous tenir au courant des dernières activités d’élaboration de politiques, des événements régionaux et bien plus encore.

Contrôles d'accès, droits d'accès et privilèges des utilisateurs

19 janvier 2016
Par Dave Piscitello

En plus de l’ICANN Languages, ce contenu est aussi disponible en

null

Dans ma dernière publication, Qu'est-ce que l'autorisation et le contrôle d'accès , j'ai expliqué que nous utilisons l'authentification pour vérifier l'identité – prouver que vous êtes la personne vous prétendez être – et aussi pour permettre une politique d'autorisation afin de définir ce que votre identité peut « voir et faire ». Par la suite, nous avons mis en œuvre ces politiques d'autorisation à l'aide de mesures de sécurité visant à accorder ou à refuser l'accès à des ressources que nous voulons contrôler ou protéger.

Les mesures que nous utilisons pour mettre en œuvre des politiques d'autorisation sont dénommées contrôles d'accès, droits d 'accès ou privilèges de l'utilisateur. Le contrôle d'accès de l'utilisateur est couramment utilisé dans le système d'exploitation Windows, dans la documentation du routeur ou du pare-feu, mais le privilège ou le droit d'accès de l'utilisateur sont plus fréquents dans la documentation de Linux. Vous pouvez trouver des fils où l'on discute les différences entre ces termes, mais à des fins d'introduction, les termes seront traités comme s'ils étaient interchangeables. Utilisez le terme avec lequel vous vous sentez plus à l'aise ou que vous rencontrez le plus souvent dans la littérature et qui soit le plus pertinent pour vous.

Lorsque vous définissez une politique d'autorisation, vous définissez des utilisateurs individuels ou des ensembles d'utilisateurs, des applications ou processus qui peuvent effectuer des actions sur une ressource telle qu'une base de données. Vous pouvez être très granulaire avec une politique d'autorisation. Vous pouvez contrôler les actions - que des individus ou ou groupes d'individus peuvent lire, créer ou modifier (écriture), supprimer – sur les entrées individuelles de la base de données, ou même différents éléments (champs) d'une entrée de base de données.

Un exemple de politique d'autorisation

Imaginons un marchand de base de données d'enregistrements où chaque enregistrement contient un nom, une adresse, un téléphone et les informations de la carte de crédit. Le personnel TI du marchand définit une politique d'autorisation qui organise l'accès des employés du marchand en trois catégories de privilèges :

  1. Les administrateurs de bases de données, Joe et Terry, peuvent exécuter toute action sur n'importe quel enregistrement de client dans la base de données. Par exemple, ils peuvent créer un enregistrement, modifier tout élément d'un document et supprimer n'importe quel enregistrement.

    Voici un exemple d'accès complet.

  2. Le personnel comptable, Charlotte et Bert, peuvent lire n'importe quel domaine de n'importe quel enregistrement de client, y compris les informations de la carte de crédit, mais ils ne peuvent pas créer, modifier ou supprimer les enregistrements ou les champs dans les enregistrements.

    Ici, nous permettons l'accès à l'ensemble des enregistrements mais nous refusons la possibilité de créer, modifier ou supprimer des enregistrements ou des champs dans les enregistrements.

  3. Le personnel de marketing, Ahmed et Carlo, peuvent lire n'importe quel enregistrement de client, mais ils ne peuvent pas lire les informations de la carte de crédit et ne sont pas autorisés à créer, modifier ou supprimer n'importe quel enregistrement ou champ.

    Ici, nous permettons l'accès à l'ensemble des enregistrements, mais nous refusons l'accès à des données spécifiques dans chaque enregistrement.

Ces exemples illustrent un concept de sécurité important, le principe de séparation des privilèges (POLP), où une organisation n'accorde aux utilisateurs que les privilèges dont ils ont besoin pour faire le travail qui leur a été attribué. Par exemple, notre société fictive a décidé que les personnel de marketing n'a pas besoin d'accéder aux cartes de crédit. Nos exemples illustrent également le contrôle d'accès basé sur les rôles (RBAC). Dans les exemples, la société a défini des privilèges fondés sur l'ensemble des rôles {administrateur de la base de données, personnel comptable, personnel de marketing...}.

Préparer le terrain

Examinez les contrôles d'accès dans notre exemple et posez-vous la question, « Si vous étiez un pirate souhaitant voler des informations, et si vous pouviez utiliser frauduleusement les informations de la carte de crédit, quels seraient les comptes utilisateur auxquels vous voudriez accéder ? »

Nous verrons comment les pirates essaient d'obtenir un accès et d'augmenter leurs privilègesdans notre prochaine publication.

Authors

Dave Piscitello