‫اﻟﺟﻣﮭــورﯾﺔ اﻟﺟزاﺋـرﯾـﺔ اﻟدﯾﻣﻘــراطﯾـﺔ اﻟﺷﻌﺑﯾــﺔ‬

‫وزارة اﻟﺗﻛـــوﯾــن واﻟﺗﻌﻠﯾــم اﻟﻣﮭﻧﯾــﯾن‬

‫اﻟﻣﻌﮭـــد اﻟوطـــﻧﻲ اﻟﻣﺗﺧﺻص ﻓﻲ اﻟﺗﻛـوﯾـــن اﻟﻣﮭﻧﻲ‬

‫‪ -‬اﻟﺴﯿﻨﯿﺎ – ﺗﯿﺎرت ‪-‬‬

‫رﻣز اﻟﺗﺧﺻص‪INT0704 :‬‬ ‫اﻟﺗﺧﺻص‪ :‬اﻟﻣﻌﻠوﻣﺎﺗﯾﺔ ‪ /‬ﺧﯾﺎر‪ :‬ﺻﯾﺎﻧﺔ اﻷﻧظﻣﺔ اﻟﻣﻌﻠوﻣﺎﺗﯾﺔ‬

‫دروس ﻣــــﺎدة‪:‬‬
‫‪Gestion des droits d’accès‬‬
‫اﻟﺣﺟم اﻟﺳﺎﻋﻲ‪h136 :‬‬ ‫رﻣز اﻟﻣـــﺎدة‪MQ5 :‬‬

‫اﻟﻣﺳﺗوى‪ :‬اﻟﺧﺎﻣس )ﺗﻘﻧﻲ ﺳﺎﻣﻲ(‬

‫ﻣن إﻋداد‪ :‬أ‪ .‬ﺑوﺧﺎﺗﻣﻲ ﻋﺑد اﻟﻘﺎدر‬

‫اﻟﺳﻧﺔ اﻟﺗﻛوﯾﻧﯾﺔ ‪2024-2023 :‬‬

 Gestion des droits d’accès CHAPITRE 1 : GERER LES COMPTES UTILISATEURS

CHAPITRE 1 : GERER LES COMPTES UTILISATEURS

I. Convention de nomenclature [1]

1. Définition : [2]
Une convention de nomenclature est une pratique qui encadre la
façon que l'on nomme nos objets (fichier, dossier, Serveurs, nom
d’utilisateurs, Programmation…), permettant ainsi de maintenir une
cohérence dans l'organisation de la documentation, ce qui favorise
l'accessibilité à l'information.
Quelle convention de nommage utiliser pour ses serveurs ?
2. Présentation
Établir une convention de nommage afin de donner un petit nom à
chacun de ses serveurs, c’est à la fois très simple à expliquer et
compliquer à maîtriser.
L’intérêt de nommer les serveurs plutôt que de retenir leur adresse
IP, c’est essentiel. C’est d’ailleurs le principe de la technologie DNS, qui est au cœur d’Internet.
On peut très vite s’y perdre, et la gestion de nos serveurs peut vite ressembler à un casse-
tête.
Pour choisir une convention pratique, facile et efficace afin de nommer nos serveurs.
3. L’art de nommer ses serveurs
Le nom d’un serveur est un choix des plus importants pour un administrateur, d’autant plus
qu’il l’utilisera au quotidien.
Voici un tour d’horizon des conventions de nommage les plus répandues. Personnellement :
A. Laisser parler sa créativité
Je me souviens d’entreprises et de sysadmin qui avaient choisi des conventions de nommage
originales :
Chaque serveur portait le nom d’un personnage du Seigneur des anneaux : Gandalf pour le
serveur de fichiers par exemple.
Les serveurs Linux avaient tous un nom se terminant en -us : Sinus, Cosinus, Proximus,..
Noms de serveurs inspirés des héros et dieux de la mythologie grecque, romaine, etc.
Le souci, c’est que dès que vous multipliez les serveurs, ça devient compliqué de se souvenir
du rôle d’Astérix par rapport à Hercule.
Du coup, ça vous oblige régulièrement à consulter votre documentation pour vous rappeler
exactement de qui fait quoi.
Par contre l’avantage, c’est qu’un attaquant ne peut pas déduire le rôle d'un serveur à partir
de son nom.
Cette méthode est déconseillée.

2
 Gestion des droits d’accès CHAPITRE 1 : GERER LES COMPTES UTILISATEURS

B. La méthode itérative
Lorsqu’on a commencé à multiplier les serveurs (un rôle = un serveur virtuel), on a essayé
d’attribuer des noms plus évocateurs à nos serveurs.
Sont donc apparus les SRVAD01, SRVFIC03, SRVWEB112, etc.
Le nom est certes évocateur et vous permet d’identifier rapidement qui fait quoi, mais si je
vous demande quelle est la différence entre SRVWEB87 et SRVWEB112, vous allez bien vous
creuser les méninges.
Ok, ce sont deux serveurs web. Mais tournent-ils sous Windows / IIS ? sous Linux / Apache
? Et pour quelle application ? Mystère...
Autre problème que cette méthode amène : Vous migrez SRVFIC01 et SRVFIC02 sur 2
nouveaux serveurs : SRVFIC03 et SRVFIC04. Puis vous supprimez les deux premiers, car ils sont
vieillissants.
Pour un petit parc de serveurs, c’est assez simple à suivre, mais pour un parc de serveurs
conséquent, vous vous demanderez toujours s’il existe 4 serveurs de fichiers, ou seulement 2. Et
si vous devez en ajouter un nouveau, faut-il l'appeler SRVFIC05, ou peut-on réutiliser SRVFIC01
? À première vue si le serveur n'existe plus, on est tenté de dire que c'est OK. Mais peut-être ya-
t-il des redirections DNS de SRVFIC01 vers SRVFIC03.
Bref, c'est mieux que la méthode précédente, mais je ne pense pas que cela soit viable sur
le long terme, ou dans le cas d'une infrastructure multi cloud.
C. La méthode préfixe - suffixe
Un nom du style SRVWEB112 permet de donner une information sur le rôle du serveur. Mais
on est toujours dans le flou en ce qui concerne l’environnement du serveur, ainsi que sa
localisation.
On utilise donc couramment des préfixes ou des suffixes pour cela. Par exemple :
P pour un serveur de Production
D pour un serveur de Développement
T pour un serveur de Test
On choisit aussi souvent un préfixe de 3 lettres pour indiquer la localisation du serveur : Par
exemple, PAR pour indiquer que le serveur est hébergé à Paris, ou BDX pour indiquer qu’il se
trouve à Bordeaux.
PARPSRVWEB04
BDXTSRVFIC02
Cela permet de donner beaucoup d’informations dans le nom de votre serveur, ce qui est
toujours un plus quand vous devez administrer un gros parc de serveurs, ou par exemple un parc
de serveurs multi-clients. Cependant, ça implique d’avoir un document décrivant avec exactitude
les différents sigles utilisés. Et l’inconvénient majeur, c’est bien sûr qu’en cas d’attaque
informatique, vous transmettez de précieuses informations à votre attaquant, via le nom du
serveur.

3
 Gestion des droits d’accès CHAPITRE 1 : GERER LES COMPTES UTILISATEURS

D. La méthode du berger
Car on va considérer nos serveurs comme on considère un troupeau de moutons.
On a tendance à avoir aujourd’hui de plus en plus de machines, et on démultiplie les
environnements : Production, Dev, Test, Préprod, Qualification, etc...
Et contrairement à il y a quelques années, nos serveurs ont pour certains une durée de vie
éphémère : parfois de l’ordre de quelques minutes, le temps de tester une nouvelle fonctionnalité
avant déploiement en production.
Pour des questions de haute disponibilité, on a aussi aujourd’hui nos serveurs qui sont
éparpillés chez différents providers / hébergeurs, ce qu'on appelle le multi cloud : Azure, AWS,
GCP, Digital Ocean, Cloud privé, etc, ce qui complexifie la gestion.
Dans ce contexte-là, pour savoir où se trouve réellement SRVVWEB112 et quel est son rôle,
pas le choix, vous devrez vous taper les 500 pages de documentation interne, en priant pour qu’elle
soit à jour.
On a donc une nouvelle méthode de nommage qui a vu le jour : on regroupe ainsi nos
serveurs par cluster indépendant, qui correspondent à des applications.
Par exemple, pour faire tourner mon site web, disons que j’ai les serveurs suivants :
2 serveurs web
1 serveur de cache
2 serveurs base de données
Ces serveurs vont donc appartenir au cluster applicatif « webprod ».
Et comme ils sont potentiellement hébergés aux quatre coins du monde, je vais indiquer dans
leur hostname leur localisation, ainsi que le nom du provider chez qui ils sont, ce qui nous donnera:
<cluster-applicatif>-<rôle><id>-<localisation-datacenter>-<provider>.<domaine>
Dans notre cas, pour un serveur web hébergé chez AWS dans le Datacenter de Paris, cela
pourrait donner : [Link]
L’avantage de cette méthode, c’est qu’elle est scalable, vous pouvez donc rapidement
déployer de nouveaux serveurs pour un nouveau cluster applicatif, sans vous demander s’il s’agit
du serveur web 97 ou 113.
Le second avantage que j’y vois, c’est que si vous déplacez un serveur de cluster applicatif,
vous faites évoluer nécessairement son nom. Alors certes, ça demande des manipulations
supplémentaires, mais vous êtes certain que le nom du serveur reflète bien son rôle actuel.
4. Comment construire sa convention de nommage
Peu importe la manière de nommer vos serveurs, vous devrez rédiger une convention de
nommage, et faire en sorte qu’elle soit partagée et connue de tous dans l’équipe.
Prenons le cas de la méthode du berger. Vous souhaitez passer le plus d’informations possible
dans le hostname de votre serveur, et pour éviter les noms à rallonge, vous allez devoir utiliser
des sigles.

4
 Gestion des droits d’accès CHAPITRE 1 : GERER LES COMPTES UTILISATEURS

Votre convention viendra donc expliquer quels sigles choisir.

Pour le rôle du serveur, vous pouvez partir sur 2 ou 3 lettres. Par exemple DC pour Domain
Controller, DB pour base de données, ou FIC pour serveur de fichiers.
Pour la localisation physique du serveur (et donc du datacenter) 2 ou 3 lettres peuvent
également correspondre : BDX pour Bordeaux, PAR pour Paris.
Si vous souhaitez faire apparaître le cloud provider, utiliser 3 lettres peut également être
intéressant : AZU pour Azure, AWS, GCP, DIO pour Digital Ocean, etc
L’environnement (production, test, dev, préprod) est également important. Personnellement,
je le code sur 1 lettre.
Le type de serveur : physique, virtuel, container, etc.
Vous pouvez également ajouter le code du pays (US, FR), la localisation de bâtiments
Note : vous pouvez aller encore plus loin et appliquer cette convention de nommage à tout
équipement se connectant à votre système d’information : PC, smartphone, système de
visioconférence, copieur, imprimante, objets connectés, etc, et identifier chaque type de terminal
via un code dans le nom.

Pour notre travail on va proposer une nomenclature :

Pour les noms des machines virtuelles on va prendre les initiales des attributs suivants :
<Nom><Prénom><Spécialité><S><N°Semestre><W><version> ----- ABMSIS4W16
Pour les noms des serveurs :
<Nom><Prénom><Spécialité><S><N°Semestre><W><version><Rôle>ABMSIS4W16CPD