Un accès non autorisé, appelé Unauthorized Access en anglais, désigne la consultation, l'utilisation, la modification ou l'exploitation d'une ressource informatique sans disposer de la permission légitime nécessaire. Cette ressource peut être un ordinateur, un serveur, un réseau, une base de données, une application Web ou un fichier confidentiel. L'accès non autorisé constitue l'une des principales préoccupations de la cybersécurité, car il peut compromettre la confidentialité, l'intégrité et la disponibilité des systèmes d'information.
1. À propos de l'accès non autorisé en cybersécurité
Définition d'un accès non autorisé
Un accès non autorisé se produit lorsqu'une personne ou un programme accède à une ressource informatique sans avoir reçu les permissions nécessaires.
Cette situation peut résulter d'une action volontaire, d'une erreur de configuration, d'une compromission de compte ou d'une vulnérabilité informatique.
Exemple concret
Dans un établissement scolaire, un enseignant dispose d'un compte lui permettant de consulter les informations de ses propres classes.
S'il accède aux dossiers confidentiels d'autres utilisateurs sans autorisation, il s'agit d'un accès non autorisé, même si son compte est authentifié.
Accès autorisé et accès non autorisé
| Critère | Accès autorisé | Accès non autorisé |
|---|---|---|
| Permission | Accordée. | Absente ou insuffisante. |
| Identité | Compte reconnu et habilité. | Compte non habilité ou identité usurpée. |
| Ressource | Accessible selon les droits attribués. | Consultée ou utilisée sans droit. |
| Exemple | Un enseignant consulte ses propres documents. | Un utilisateur consulte des dossiers confidentiels sans permission. |
| Conséquence | Utilisation normale. | Risque de violation de sécurité. |
Authentification et autorisation
L'authentification consiste à vérifier l'identité d'un utilisateur.
L'autorisation consiste à déterminer les ressources et les opérations auxquelles cet utilisateur a droit.
Un utilisateur correctement authentifié peut donc réaliser un accès non autorisé s'il consulte une ressource pour laquelle il ne dispose pas de permission.
Accès non autorisé interne
Un Insider Threat peut impliquer une personne appartenant à une organisation et utilisant ses accès de manière abusive.
La menace peut être intentionnelle ou résulter d'une négligence.
Accès non autorisé externe
Un accès non autorisé externe peut provenir d'une personne située en dehors de l'organisation.
Il peut notamment résulter de la compromission d'un compte ou de l'exploitation d'une vulnérabilité.
Accès non autorisé physique
Un accès non autorisé peut également être physique, par exemple lorsqu'une personne utilise un ordinateur ou un équipement sans permission.
Accès non autorisé logique
Un accès logique concerne les ressources numériques : applications, systèmes d'exploitation, fichiers, réseaux et bases de données.
Les trois piliers de la sécurité
L'accès non autorisé peut affecter les trois propriétés fondamentales de la sécurité informatique :
- Confidentialité : empêcher la divulgation des informations à des personnes non habilitées.
- Intégrité : protéger les données contre les modifications non autorisées.
- Disponibilité : garantir l'accès aux ressources pour les utilisateurs légitimes.
2. Les principales causes et techniques d'accès non autorisé
Mots de passe faibles
Les mots de passe faibles peuvent faciliter la compromission d'un compte utilisateur.
Les mots de passe prévisibles ou réutilisés sur plusieurs services présentent des risques importants.
Brute Force
Une attaque Brute Force consiste à essayer de nombreuses valeurs afin de découvrir un mot de passe ou un autre secret.
La limitation des tentatives et l'authentification multifacteur contribuent à réduire ce risque.
Credential Stuffing
Le Credential Stuffing consiste à tester des combinaisons d'identifiants précédemment compromises sur d'autres services.
Cette technique exploite notamment la réutilisation des mots de passe.
Phishing
Le Phishing est une technique de tromperie destinée à obtenir des informations sensibles ou à provoquer une action dangereuse.
Un utilisateur peut être amené à divulguer ses identifiants à un site frauduleux.
Vol de session
Le Session Hijacking désigne la prise de contrôle non autorisée d'une session utilisateur.
La protection des cookies, des jetons et des communications contribue à limiter ce risque.
SQL Injection
Une SQL Injection, ou SQLi, est une vulnérabilité permettant à des entrées non fiables d'influencer une requête SQL lorsque celle-ci est construite de manière dangereuse.
Selon le contexte, cette vulnérabilité peut conduire à la consultation ou à la modification non autorisée de données.
Broken Access Control
Le Broken Access Control désigne des défaillances dans les mécanismes chargés de vérifier les permissions des utilisateurs.
Il peut permettre à un utilisateur d'effectuer des opérations normalement interdites.
IDOR
Une vulnérabilité Insecure Direct Object Reference, ou IDOR, survient lorsqu'une application expose une référence à un objet sans vérifier correctement que l'utilisateur est autorisé à y accéder.
Par exemple, une application ne doit pas autoriser la consultation d'un dossier simplement parce que son identifiant est connu.
Privilege Escalation
L'élévation de privilèges consiste à obtenir des permissions supérieures à celles initialement accordées.
Elle peut résulter d'une vulnérabilité ou d'une mauvaise configuration.
Mauvaise configuration des permissions
Des fichiers, répertoires ou applications peuvent être exposés lorsque leurs permissions sont trop larges.
Services réseau exposés
Un service d'administration accessible depuis un réseau non fiable peut augmenter la surface d'attaque d'un système.
Les services comme SSH ou RDP doivent être correctement protégés.
Malware
Un Malware peut permettre à un acteur malveillant d'accéder à des données ou à des fonctionnalités d'un système compromis.
Remote Access Trojan
Un Remote Access Trojan, ou RAT, est un logiciel malveillant permettant un contrôle distant non autorisé.
Erreurs humaines
Une erreur de partage, une permission mal attribuée ou l'envoi d'informations au mauvais destinataire peuvent également provoquer un accès non autorisé.
Tableau des principales causes
| Cause | Risque | Protection recommandée |
|---|---|---|
| Mot de passe faible | Compromission de compte. | Mot de passe robuste et MFA. |
| Phishing | Vol d'identifiants. | Formation et authentification résistante au phishing. |
| SQL Injection | Accès abusif aux données. | Requêtes paramétrées. |
| IDOR | Consultation de ressources d'autrui. | Vérification des autorisations sur chaque objet. |
| Permissions excessives | Accès à des données sensibles. | Moindre privilège. |
| Service exposé | Tentatives d'intrusion. | Restriction réseau et MFA. |
| Malware | Compromission du système. | Mises à jour et protection des terminaux. |
3. Les conséquences et les moyens de prévention
Vol de données
Un accès non autorisé peut permettre la consultation ou l'extraction de données confidentielles.
Modification des informations
Un utilisateur non habilité peut modifier des fichiers, des enregistrements ou des paramètres.
Suppression de données
Un accès abusif peut entraîner la suppression accidentelle ou volontaire de données.
Compromission des comptes
Un compte compromis peut être utilisé pour accéder à d'autres ressources ou usurper l'identité de son propriétaire.
Interruption des services
Certaines activités non autorisées peuvent perturber le fonctionnement normal d'un système.
Conséquences financières
Les incidents peuvent entraîner des coûts de remédiation, des interruptions d'activité et des pertes économiques.
Conséquences juridiques
L'accès non autorisé peut constituer une infraction selon la législation applicable et les circonstances.
Il peut également entraîner des obligations liées à la protection des données personnelles.
Contrôle d'accès
Le Access Control regroupe les mécanismes permettant de déterminer qui peut accéder à une ressource et quelles actions sont autorisées.
RBAC
Le Role-Based Access Control, ou RBAC, attribue des permissions selon les rôles des utilisateurs.
ABAC
L'Attribute-Based Access Control, ou ABAC, utilise des attributs pour déterminer les permissions.
Principe du moindre privilège
Le Least Privilege consiste à accorder uniquement les permissions nécessaires à l'accomplissement des tâches autorisées.
Authentification multifacteur
La Multi-Factor Authentication, ou MFA, renforce la protection des comptes.
Gestion des sessions
Les sessions doivent utiliser des identifiants imprévisibles, des cookies protégés et des mécanismes d'expiration adaptés.
Vérification des autorisations côté serveur
Les permissions doivent être contrôlées sur le serveur pour chaque opération sensible.
Masquer un bouton dans l'interface utilisateur ne suffit pas à empêcher un accès non autorisé.
Journalisation
La journalisation permet d'enregistrer les événements importants afin de faciliter la surveillance et l'investigation.
IDS et IPS
Un Intrusion Detection System, ou IDS, peut détecter certains comportements suspects.
Un Intrusion Prevention System, ou IPS, peut également appliquer des mesures de blocage.
SIEM
Un Security Information and Event Management, ou SIEM, permet de centraliser et d'analyser des événements de sécurité.
Zero Trust
Le Zero Trust est une approche de sécurité reposant sur la vérification explicite des demandes d'accès et la limitation des privilèges.
Bonnes pratiques de prévention
- Utiliser des mots de passe robustes et uniques.
- Activer la MFA pour les comptes sensibles.
- Appliquer le principe du moindre privilège.
- Contrôler les permissions côté serveur.
- Mettre régulièrement les logiciels à jour.
- Protéger les interfaces d'administration.
- Surveiller les journaux d'accès.
- Limiter les tentatives d'authentification.
- Révoquer les comptes et sessions inutiles.
- Former les utilisateurs aux risques de phishing.
Réponse à un incident d'accès non autorisé
- Identifier les comptes et ressources concernés.
- Conserver les journaux et les éléments utiles à l'investigation.
- Limiter ou suspendre les accès suspects.
- Révoquer les sessions potentiellement compromises.
- Renouveler les identifiants concernés depuis un environnement sain.
- Rechercher la cause initiale de l'incident.
- Corriger les vulnérabilités et les permissions incorrectes.
- Vérifier l'intégrité des données.
- Rétablir les services en sécurité.
- Renforcer la surveillance après l'incident.
4. Exemples pratiques de contrôle et de détection avec Python
Les programmes suivants illustrent différents mécanismes de contrôle d'accès, de vérification des permissions et de détection des accès suspects.
Les exemples utilisent des données fictives et ne nécessitent aucune tentative d'accès à des systèmes tiers.
Exemple 1 : vérifier si un utilisateur est autorisé
Le programme suivant compare le nom d'un utilisateur à une liste de comptes autorisés. Il permet d'illustrer le principe d'une liste d'autorisation.
1 2 3 4 5 6 | utilisateurs_autorises = ["alice", "bob", "sara"] utilisateur = "alice" if utilisateur in utilisateurs_autorises: print("Accès autorisé") else: print("Accès non autorisé") |
Output :
1 | Accès autorisé |
Exemple 2 : refuser un utilisateur inconnu
Le programme suivant vérifie si un utilisateur figure dans la liste des comptes reconnus. Lorsqu'il n'y figure pas, la demande est refusée.
1 2 3 4 5 6 | utilisateurs = ["admin", "enseignant"] utilisateur = "inconnu" if utilisateur not in utilisateurs: print("Accès refusé : utilisateur inconnu") else: print("Utilisateur reconnu") |
Output :
1 | Accès refusé : utilisateur inconnu |
Exemple 3 : vérifier une permission
Le programme suivant simule un contrôle d'autorisation. Il vérifie si un utilisateur dispose de la permission nécessaire pour lire une ressource.
1 2 3 4 5 6 7 8 9 10 | permissions = { "alice": ["lecture", "ecriture"], "bob": ["lecture"] } utilisateur = "bob" action = "ecriture" if action in permissions.get(utilisateur, []): print("Opération autorisée") else: print("Opération non autorisée") |
Output :
1 | Opération non autorisée |
Exemple 4 : contrôler l'accès selon le rôle
Le programme suivant applique une politique RBAC simplifiée. Seuls les utilisateurs ayant le rôle administrateur peuvent accéder à la fonctionnalité concernée.
1 2 3 4 5 | role = "enseignant" if role == "administrateur": print("Accès à l'administration autorisé") else: print("Accès à l'administration refusé") |
Output :
1 | Accès à l'administration refusé |
Exemple 5 : protéger l'accès à un document
Le programme suivant simule un contrôle de propriété. Un utilisateur ne peut consulter le document que s'il en est le propriétaire ou s'il dispose d'une autorisation particulière.
1 2 3 4 5 6 7 8 9 10 | document = { "titre": "Rapport confidentiel", "proprietaire": "alice" } utilisateur = "bob" administrateur = False if utilisateur == document["proprietaire"] or administrateur: print("Consultation autorisée") else: print("Consultation interdite") |
Output :
1 | Consultation interdite |
Exemple 6 : simuler la prévention d'une vulnérabilité IDOR
Le programme suivant vérifie qu'un utilisateur est autorisé à consulter un dossier avant d'en afficher le contenu. Il illustre la nécessité de vérifier les permissions pour chaque ressource.
1 2 3 4 5 6 7 8 9 10 11 12 13 | dossiers = { 101: {"proprietaire": "alice", "contenu": "Dossier Alice"}, 102: {"proprietaire": "bob", "contenu": "Dossier Bob"} } utilisateur = "alice" identifiant = 102 dossier = dossiers.get(identifiant) if dossier is None: print("Dossier inexistant") elif dossier["proprietaire"] != utilisateur: print("Accès refusé") else: print(dossier["contenu"]) |
Output :
1 | Accès refusé |
Exemple 7 : appliquer une politique de moindre privilège
Le programme suivant attribue des permissions selon le rôle. Il vérifie si un enseignant peut effectuer une opération d'administration.
1 2 3 4 5 6 7 8 9 10 11 | roles = { "administrateur": ["lecture", "ecriture", "suppression"], "enseignant": ["lecture", "ecriture"], "visiteur": ["lecture"] } role = "enseignant" operation = "suppression" if operation in roles[role]: print("Permission accordée") else: print("Permission refusée") |
Output :
1 | Permission refusée |
Exemple 8 : détecter plusieurs échecs de connexion
Le programme suivant analyse des événements fictifs et compte les échecs d'authentification d'un utilisateur.
1 2 3 4 5 6 7 8 9 10 11 | evenements = [ "ECHEC alice", "ECHEC alice", "SUCCES bob", "ECHEC alice", "ECHEC alice" ] echecs = sum(e == "ECHEC alice" for e in evenements) print("Nombre d'échecs :", echecs) if echecs >= 4: print("Alerte : échecs répétés") |
Output :
1 2 | Nombre d'échecs : 4 Alerte : échecs répétés |
Exemple 9 : vérifier une authentification multifacteur
Le programme suivant simule une politique exigeant une identité vérifiée et une MFA validée avant d'autoriser l'accès.
1 2 3 4 5 6 | identite_verifiee = True mfa_validee = False if identite_verifiee and mfa_validee: print("Accès autorisé") else: print("Accès refusé : authentification insuffisante") |
Output :
1 | Accès refusé : authentification insuffisante |
Exemple 10 : détecter des accès à des ressources sensibles
Le programme suivant analyse des événements fictifs. Il affiche une alerte lorsqu'un utilisateur non habilité tente d'accéder à une ressource sensible.
1 2 3 4 5 6 7 8 9 10 11 12 13 | evenements = [ {"utilisateur": "alice", "ressource": "public", "autorise": True}, {"utilisateur": "bob", "ressource": "confidentiel", "autorise": False}, {"utilisateur": "sara", "ressource": "public", "autorise": True} ] for evenement in evenements: if not evenement["autorise"]: print( "ALERTE :", evenement["utilisateur"], "vers", evenement["ressource"] ) |
Output :
1 | ALERTE : bob vers confidentiel |
Exemple 11 : enregistrer les refus d'accès
Le programme suivant utilise le module logging pour enregistrer une tentative d'accès refusée dans un fichier local.
1 2 3 4 5 6 7 8 9 10 | import logging logging.basicConfig( filename="acces_refuses.log", level=logging.WARNING, format="%(levelname)s : %(message)s", force=True ) utilisateur = "inconnu" logging.warning("Accès refusé pour %s", utilisateur) print("Événement enregistré") |
Output :
1 | Événement enregistré |
Exemple 12 : créer un mini système de contrôle d'accès
Le programme suivant combine une liste d'utilisateurs, leurs rôles et les permissions correspondantes. Il vérifie chaque demande avant d'autoriser ou de refuser une opération.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | utilisateurs = { "alice": "administrateur", "bob": "enseignant", "sara": "visiteur" } permissions = { "administrateur": ["lecture", "ecriture", "suppression"], "enseignant": ["lecture", "ecriture"], "visiteur": ["lecture"] } def verifier_acces(utilisateur, action): role = utilisateurs.get(utilisateur) if role is None: return "REFUSE : utilisateur inconnu" if action not in permissions.get(role, []): return "REFUSE : permission insuffisante" return "AUTORISE" demandes = [ ("alice", "suppression"), ("bob", "suppression"), ("sara", "lecture"), ("inconnu", "lecture") ] for utilisateur, action in demandes: print(utilisateur, action, ":", verifier_acces(utilisateur, action)) |
Output :
1 2 3 4 | alice suppression : AUTORISE bob suppression : REFUSE : permission insuffisante sara lecture : AUTORISE inconnu lecture : REFUSE : utilisateur inconnu |
Ce système est une simulation pédagogique. Une application réelle doit vérifier les identités, protéger les sessions, contrôler les permissions côté serveur et enregistrer les événements de sécurité.
Mini laboratoire pédagogique : tester les autorisations d'une application
Un laboratoire de contrôle d'accès peut être réalisé avec Python ou avec une application Web locale développée pour l'apprentissage.
Les étapes recommandées sont les suivantes :
- Créer trois comptes fictifs : administrateur, enseignant et visiteur.
- Définir les permissions associées à chaque rôle.
- Créer plusieurs ressources fictives.
- Attribuer un propriétaire à chaque ressource.
- Écrire une fonction de vérification des autorisations.
- Tester un accès autorisé.
- Tester un accès refusé.
- Tester la consultation d'une ressource appartenant à un autre utilisateur.
- Enregistrer les décisions dans un journal.
- Vérifier que les opérations interdites ne modifient aucune donnée.
Ce laboratoire permet de comprendre les mécanismes de contrôle d'accès, de RBAC et de prévention des IDOR.
5. À retenir
Un accès non autorisé correspond à la consultation ou à l'utilisation d'une ressource informatique sans permission légitime.
Il peut concerner les ordinateurs, les serveurs, les réseaux, les applications, les bases de données et les fichiers.
L'authentification permet de vérifier l'identité d'un utilisateur, tandis que l'autorisation détermine ses permissions.
Un utilisateur authentifié peut effectuer un accès non autorisé s'il dépasse les droits qui lui sont attribués.
Les causes possibles comprennent les mots de passe faibles, le phishing, les mauvaises configurations, les vulnérabilités logicielles et les permissions excessives.
Les vulnérabilités Broken Access Control et IDOR peuvent permettre à un utilisateur d'accéder à des ressources qui ne lui appartiennent pas.
Les conséquences peuvent affecter la confidentialité, l'intégrité et la disponibilité des systèmes d'information.
Les mécanismes RBAC, ABAC et le principe du moindre privilège contribuent à limiter les accès abusifs.
La MFA, la journalisation et la surveillance des événements renforcent la sécurité.
Les permissions doivent être vérifiées côté serveur pour chaque opération sensible.
Enfin, Python permet de simuler les mécanismes d'autorisation et de développer des outils pédagogiques de détection des accès suspects.
Auteur : Younes Derfoufi
Lieu de travail : CRMEF OUJDA
Site Web : www.tresfacile.net
Chaine YouTube : https://www.youtube.com/user/InformatiquesFacile
Me contacter : https://www.tresfacile.net/me-contacter/
