2-GIA-P1.pdf

INF8102: Sécurité dans les environnements infonuagique 02- Gestion des identitiés et des accès (Partie 1) Abdeljalil Beniiche 1  CONTENU DU COURS Introduction et concepts génér...

INF8102: Sécurité dans les environnements infonuagique 02- Gestion des identitiés et des accès (Partie 1) Abdeljalil Beniiche 1  CONTENU DU COURS Introduction et concepts généraux Authentification, Autorisation, Risques et faiblesses Implémentation et gestion des mécanismes d'autorisation Modèles de contrôle d’accès (AC) Contrôle d’accès discrétionnaire (DAC) Contrôle d’accès obligatoire (MAC) Contrôle d'accès à base de rôles (RBAC) Principes de moindres privilèges et séparation des tâches (SoD) Cycle de vie de la GIA Systèmes et mécanismes d’authentification OIDC, OAuth, Kerberos, RADIUS, TACACS+, Diameter SSO, FIM, MFA, OTP UNIVERSITÉ D’INGÉNIERIE 2 Introduction et Concepts Généraux UNIVERSITÉ D’INGÉNIERIE 3  CONTRÔLE D’ACCÈS AUX ACTIFS 5.1 CONTRÔLERACCÈSAUXACTIFS Information - Sa localisation : appareil, ensemble d’appareils - Sa forme : fichier, base de données Systèmes - Un ou des systèmes qui offrent des services Dispositifs - Détenus par l’organisation ou ses employés (BYOD) Installations : Salles, édifices, etc. UNIVERSITÉ D’INGÉNIERIE 4 AUTHENTICATION VS. AUTHORISATION UNIVERSITÉ D’INGÉNIERIE 5 AUTHENTICATION UNIVERSITÉ D’INGÉNIERIE 6 AUTHENTICATION UNIVERSITÉ D’INGÉNIERIE 7 Modèles de contrôle d’accès (AC) UNIVERSITÉ D’INGÉNIERIE 8 MODÈLES DE CONTRÔLE D’ACCÈS Modèles de Contrôle d’accès (AC) Il y’a plusieurs modèles qui règlementent l’accès aux ressources. Matrices de contrôle d’accès (ACM) Contrôle d’accès discrétionnaire (DAC) Contrôle d’accès obligatoire (MAC et LAC) Contrôle d’accès basé sur les rôles (RBAC) Contrôle d’accès basé sur les attributs (ABAC) Bien sur, ils existent des variations de chaque modèle, selon leurs implémentations. Dans ce cours, on va plus détailler les modèles: MAC, DAC, RBAC UNIVERSITÉ D’INGÉNIERIE 9 Matrices de contrôle d’accès (ACM) UNIVERSITÉ D’INGÉNIERIE 10 MATRICES DE CONTRÔLE D’ACCÈS (ACM) Matrices de contrôle d’accès (ACM) Ceci est un exemple qui montre comment les permissions peuvent être attribuées dans une ACM. Archive Prog. de Dossiers des Imprimante Scanneur (Syslog) monitoring employés LPT1 SCN1 Martin Lire, écrire Lire, écrire, Exécuter Écrire Jean Lire Exécuter Écrire Lire, Écrire, Richard Lire Exécuter Exécuter Paul Exécuter Exécuter Écrire UNIVERSITÉ D’INGÉNIERIE 11 MATRICES DE CONTRÔLE D’ACCÈS (ACM) Caractéristiques des ACM Implémentation initiale: Facile a implémenter au départ. Prends beaucoup de temps, dépendamment de la taille de la compagnie. Granularité: Les permissions sont très détaillées Mise à l’échelle (Scalability): Il faut faire un suivi individuel. Dans la pratique (centaine/milliers d’employés), c’est difficile d’appliquer ce modèle. Les changement fréquents (ex.: mouvement d’employés) sont difficile a gérer. UNIVERSITÉ D’INGÉNIERIE 12 Contrôle d’accès discrétionnaire (DAC) UNIVERSITÉ D’INGÉNIERIE 13 CONTRÔLE D’ACCÈS DISCRÉTIONNAIRE (DAC) Contrôle d’accès discrétionnaire (DAC) Le DAC est un mécanisme logiciel qui sert à contrôler l'accès des utilisateurs aux fichiers et aux répertoires. Les permissions d’accès aux ressources sont attribuées par le propriétaire de la ressource. C’est le mécanisme par défaut dans les systèmes POSIX. Dans DAC, les permissions sont définit par deux mécanismes: Les bits de permission (dans les systèmes POSIX). Liste de contrôle d’accès (Access Control List, ACL). UNIVERSITÉ D’INGÉNIERIE 14 CONTRÔLE D’ACCÈS DISCRÉTIONNAIRE (DAC) Les bits de permission dans POSIX Pour afficher les permissions: Tous les fichiers: – ls –l Un fichier en particulier: – ls –l Types d’utilisateurs: Propriétaire du fichier: représenté par la lettre “u” Groupe de propriétaires: représenté par la lettre “g” Autres utilisateurs: représenté par la lettre “o” Tous les utilisateurs: représenté par “a”, au lieu d’utiliser “ugo” UNIVERSITÉ D’INGÉNIERIE 15 CONTRÔLE D’ACCÈS DISCRÉTIONNAIRE (DAC) Les bits de permission dans POSIX Modèle d’attribution des permissions POSIX u g o UNIVERSITÉ D’INGÉNIERIE 16 CONTRÔLE D’ACCÈS DISCRÉTIONNAIRE (DAC) La liste de contrôle d’accès (ACL) ACLs sont implémenter et supporter dans la plupart des systèmes POSIX. ACLs définit 3 classes d’utilisateurs Propriétaire (owner), groupe (group), Autres (other) ACLs définit 3 types de permissions Lire (read, r), écrire (write, w), exécuter (execute, x) Les permissions sont attribué/changé par le propriétaire pour les trois types d’utilisateurs (u,g,o) Pour visualiser les permissions sur un fichier/liste de fichiers: ls –l ls –l UNIVERSITÉ D’INGÉNIERIE 17 CONTRÔLE D’ACCÈS DISCRÉTIONNAIRE (DAC) La liste de contrôle d’accès (ACL) Les permissions dans les ACLs sont définit pour chaque fichier, a l’aide d’un tableau à plusieurs entrées: Type d’entré Forme textuelle Owner user::rwx Named user user:name:rwx Owning group group::rwx Named group group:name:rwx Mask mask::rwx Others other::rwx UNIVERSITÉ D’INGÉNIERIE 18 Contrôle d’accès obligatoire (MAC) UNIVERSITÉ D’INGÉNIERIE 19 CONTRÔLE D’ACCÈS OBLIGATOIRE (MAC) Contrôle d’accès obligatoire (MAC) MAC est un mécanisme logiciel qui permet au système (non le propriétaire) de définir les accès aux ressources. Les permissions sont définit à travers des politiques. Le système applique d’abord un système d’étiquetage aux ressources et processus. Les politiques sont définit sur la relation entre les étiquettes. Un processus ne peut pas accéder à une ressource (ou communiquer avec un autre processus), sauf si les deux parties possèdent la même étiquette. La lecture est autorisée pour les niveaux d’étiquette égale ou inférieure à celui de l’objet. L'administrateur peut créer ou personnaliser ces politiques. UNIVERSITÉ D’INGÉNIERIE 20 CONTRÔLE D’ACCÈS OBLIGATOIRE (MAC) Propriétés du MAC Les ressources et les processus sont classé selon leurs niveaux de confidentialité: Très secret, Secret, Confidentiel, etc. – En général, il y a trois types de politiques: Minimum – Un nombre minimal de politiques sont appliquées – Idéal pour les systèmes limités en ressources de calcul. Ciblé – Elle couvre un certain nombre de processus, tâches et services. Multi-niveau (MLS) – Très strict. – Idéal dans le contexte militaire. UNIVERSITÉ D’INGÉNIERIE 21 CONTRÔLE D’ACCÈS OBLIGATOIRE (MAC) MAC dans les systèmes POSIX Dans POSIX, il y a quelque logiciels appliquant MAC: Selinux, AppArmor, GRSecurity UNIVERSITÉ D’INGÉNIERIE 22 CONTRÔLE D’ACCÈS OBLIGATOIRE (MAC) MAC dans SELinux Concepts: Sujet: C’est le processus qui agit sur un objet. Objet: C’est la ressource sur laquelle le processus peut agir. – Exemples: fichier, répertoire, port, socket, etc. Domaine: C’est l'environnement d'exécution d'un processus. Type: C’est le contexte de l’objet (utilisation, location, propriétaire, etc.) Rôle: définit quel utilisateur a le droit d’accéder à un processus Permissions: Ce sont les actions que le sujet peut faire sur les objets. UNIVERSITÉ D’INGÉNIERIE 23 CONTRÔLE D’ACCÈS OBLIGATOIRE (MAC) MAC dans SELinux Étiquetage des objets: ls –l -Z Étiquetage des processus: ps –ef -Z UNIVERSITÉ D’INGÉNIERIE 24 CONTRÔLE D’ACCÈS OBLIGATOIRE (MAC) MAC dans SELinux Notation: _r: rôle _u: Utilisateur _t: Décrit les fichiers ou les processus Pour les fichiers, on parle de type (http, etc.) Pour les processus on parle de domaine (kernel, userspace, etc.) UNIVERSITÉ D’INGÉNIERIE 25 Contrôle d'accès à base de rôles (RBAC) UNIVERSITÉ D’INGÉNIERIE 26 CONTRÔLE D'ACCÈS À BASE DE RÔLES (RBAC) Contrôle d'accès à base de rôles (RBAC) Ce type de contrôle essaye de reproduire ce qu’on trouve dans compagnie. Les utilisateurs/employés ont des rôles au sien de leurs institutions. Exemples: PDG, CTO, Chef de projet, Analyste, programmeur, secrétaire, etc. – Les permissions sont attribuées aux rôles, et non aux utilisateurs. – Un utilisateur se voit attribué les permissions qui sont déjà définit dans le rôle qu’il possède. – Un utilisateur peut changer de rôle, selon la politique en place Un sysadmin peut basculer entre son rôle et un autre rôle (ex: staff) UNIVERSITÉ D’INGÉNIERIE 27 CONTRÔLE D'ACCÈS À BASE DE RÔLES (RBAC) Caractéristiques du RBAC La méthode la plus utilisé des systèmes actuels. Idéal pour les grandes compagnies (plus de 500 employés). Une approche pratique qui représente la structure des organisations. Structure hiérarchique basée sur les rôles. Cette approche est appliquée dans les méthodes MAC et DAC. Bien sur, plusieurs variations existent selon l’implémentation de l’approche. UNIVERSITÉ D’INGÉNIERIE 28 CONTRÔLE D'ACCÈS À BASE DE RÔLES (RBAC) Caractéristiques du RBAC UNIVERSITÉ D’INGÉNIERIE 29 GIA – Cycle de vie UNIVERSITÉ D’INGÉNIERIE 30 CONTRÔLE D’ACCÈS – CYCLE DE VIE Création Utilisation Destruction Modification Audit (5.5) UNIVERSITÉ D’INGÉNIERIE 31  CONTRÔLE D’ACCÈS – CYCLE DE VIE CeFTI 5.5 CYCLEDEVIE DESIDENTITÉSETDESACCÈS Revue d'accès utilisateur - Selon les situations, telles mutation, congédiement, promotion, vacances, hospitalisation, enquête, disparition - Identifier les déclencheurs Revue d'accès au compte système - Réviser Provisionnement et désapprovisionnement UNIVERSITÉ D’INGÉNIERIE 32  CONTRÔLE D’ACCÈS – CYCLE DE VIE 5.5 CYCLEDEVIE DESIDENTITÉS ETDESACCÈS Menaces sur les contrôles d’accès - Mystification (spoofing) ▪ Amener à faire quelque chose qu’on ne ferait pas en temps normal - Piratage psychologique UNIVERSITÉ D’INGÉNIERIE 33  CONTRÔLE D’ACCÈS – CYCLE DE VIE 5.5 CYCLEDEVIE DESIDENTITÉS ETDESACCÈS - Attaque par force brute - Attaque au dictionnaire ▪ Essaie de couper le temps par un dictionnaire ▪ Souvent constitué des mots de passe les plus utilisés ▪ Peut ajouter des éléments de complexité ▪ Diminuer par salage, historique, éviter utiliser quand présent dans un dictionnaire ou un site du type HaveIBeenPwnd UNIVERSITÉ D’INGÉNIERIE 34 Systèmes d’Authentification UNIVERSITÉ D’INGÉNIERIE 35 MFA : MULTI FACTOR AUTHENTICATION UNIVERSITÉ D’INGÉNIERIE 36 OTP : ONE TIME PASSWORD UNIVERSITÉ D’INGÉNIERIE 37 OTP : ONE TIME PASSWORD UNIVERSITÉ D’INGÉNIERIE 38 FORCE UNIVERSITÉ D’INGÉNIERIE 39 FAIBLESSE ET RISQUES UNIVERSITÉ D’INGÉNIERIE 40 FAIBLESSE ET RISQUES Quelques enjeux - Les pirates peuvent prendre le contrôle pour devenir des initiés avec privilèges - Quand un système est compromis, il faut réémettre les informations d'identification et d’authentification - Taux de vérification des informations d'identification peut être très élevé - La gestion des identifiants et authentifiants ne peut pas être le maillon faible UNIVERSITÉ D’INGÉNIERIE 41  AUTHENTICATION Kerberos - Client (C) a sa propre clé secrète Kc - Serveur (S) a sa propre clé secrète Ks - KDC connaît Kc et Ktgs - TGS connaît Ks et Ktgs i. Le client (C) demande s’authentifie à AS et reçoit la clé de session TGS du KDC ii. Le client (C) demande le service ID à TGS et reçoit la clé de session client/serveur iii. Le client (C) indique au serveur qu’il est authentifié et reçoit la confirmation qu’il est le boniii. serveur iv. Les services se déroulent avec la clé de session client/serveur ▪ VOIR : https://blog.devensys.com/kerberos-principe-de-fonctionnement/ UNIVERSITÉ D’INGÉNIERIE 42 AUTHENTICATION Attaques Kerberos - Overpass the hash : similaire à pass the hash (PtH) - Pass the Ticket : impersonifie un utilisateur - Silver Ticket - Golden Ticket : vol du ticket système KRBTGT - Kerberos Brute Force : script kerbrute.py - ASREPRoast : faille preauthentification - Kerberoasting : accumule TGS pour les déchiffrer UNIVERSITÉ D’INGÉNIERIE 43  AUTHENTICATION Domaine de sécurité - Collection d'applications qui font toutes confiance à un jeton de sécurité commun pour l'authentification, l'autorisation ou la gestion de session - Exemples ▪ Les applications Web font confiance à un même témoin de session ▪ Applications et services Windows font confiance à un ticket Kerberos émis par Active Directory UNIVERSITÉ D’INGÉNIERIE 44 AUTHENTICATION Responsabilité - Propriétaire de l’actif : définir - Gardien de l’actif : gérer Gestion de session - Déconnexion après un certain temps ▪ De connexion ▪ D’inactivité UNIVERSITÉ D’INGÉNIERIE 45 AUTHENTICATION Enregistrement et preuve d'identité - Fournir les documents requis (certificat de naissance, diplôme d’un établissement d’enseignement reconnu, etc.) - Doit être établi dans une politique UNIVERSITÉ D’INGÉNIERIE 46  AUTHENTICATION Gestion fédérée des identités (FIM) UNIVERSITÉ D’INGÉNIERIE 47 AUTHENTICATION Traçabilité - Par les fichiers journaux ▪ Enregistrement chronologique ▪ Preuve documentaire de la séquence des activités ayant affecté à tout moment une opération, une procédure ou un événement ▪ Différents événements conservés, liés aux utilisateurs, aux applications et aux systèmes UNIVERSITÉ D’INGÉNIERIE 48 AUTHENTICATION - Security information and event management (SIEM) ▪ Collecte : journaux pare-feux, routeurs, serveurs et natif (IDMEF) ▪ Agrégation : mise en relation de sources multiples ▪ Corrélation : remonter à l’événement source ▪ Alertage : automatisation de certains événements corrélés ▪ Recherche : enquête ▪ Analyse et visualisation ▪ Archivage UNIVERSITÉ D’INGÉNIERIE 49  AUTHENTICATION 5.3 INTÉGRATIOND'IDENTITÉ UNIVERSITÉ D’INGÉNIERIE 50  AUTHENTICATION FÉDÉRÉE 5.3 INTÉGRATIOND'IDENTITÉ Fédérée - Expérience utilisateur transparente. - Authentification unique (SSO) - Responsabilités de gestion au fournisseur d'identité résident - Évite les problèmes de confidentialité et de conformité - Accès aux fournisseurs, distributeurs et partenaires ▪ Social (ex. Facebook), bancaire, chercheurs (ORCID) UNIVERSITÉ D’INGÉNIERIE 51 SYSTÈMES D'AUTHENTIFICATION Security assertion markup language - SAML - Norme ouverte pour échange de données d'authentification et d'autorisation entre des tiers - Langage de balisage basé sur XML pour les assertions de sécurité, soient les instructions que les fournisseurs de services utilisent pour prendre des décisions en matière de contrôle d'accès - Permet surtout l’authentification unique (SSO) pour les fureteur Web (jetons SAML) UNIVERSITÉ D’INGÉNIERIE 52 SYSTÈMES D'AUTHENTIFICATION SP’s Assertion Consumer Service (ACS) UNIVERSITÉ D’INGÉNIERIE 53 SYSTÈMES D'AUTHENTIFICATION OpenID - Système d’authentification décentralisé - Permet authentification unique et le partage d’attributs - Authentifier auprès de plusieurs sites en utilisant à chaque fois un identifiant OpenID - Basé sur des liens de confiance établis entre les fournisseurs de services et les fournisseurs d’identité - Utilisé par IBM, Facebook, Yahoo!, Google, Microsoft, etc. UNIVERSITÉ D’INGÉNIERIE 54 SYSTÈMES D'AUTHENTIFICATION 3 acteurs Authentifie UNIVERSITÉ D’INGÉNIERIE 55 SYSTÈMES D'AUTHENTIFICATION OAuth - Protocole délégation d’autorisation - Peut être utilisé pour l’authentification de l’utilisateur (resource owner, RO) - https://tools.ietf.org/html/rfc6749 Authentifie 4 acteurs Site / service UNIVERSITÉ D’INGÉNIERIE 56  SYSTÈMES D'AUTHENTIFICATION 5.6 SYSTÈMESD'AUTHENTIFICATION OpenID Connect - Construit sur OAuth 2.0 - Authentifie avec Authorization Server (AS) - Obtient information identité UNIVERSITÉ D’INGÉNIERIE 57 SYSTÈMES D'AUTHENTIFICATION Remote Authentication Dial-In User (RADIUS) - Protocole AAA complet - RFC 2865, basé sur UDP ▪ Doit implanter le contrôle d’erreur - Utilisé avec IEEE 802.1x UNIVERSITÉ D’INGÉNIERIE 58  SYSTÈMES D'AUTHENTIFICATION 5.6 SYSTÈMESD'AUTHENTIFICATION Terminal Access Controller Access-Control System (TACACS+) - Crypte tout, donc moins vulnerable que RADIUS UNIVERSITÉ D’INGÉNIERIE 59 SYSTÈMES D'AUTHENTIFICATION 5.6 SYSTÈMESD'AUTHENTIFICATION RADIUS TACACS+ Livraison de paquets UDP TCP Crypte seulement le mot de Crypte tout le trafic entre le Cryptage de paquets passe du client Radius client et le serveur jusqu’au serveur Utilise une architecture AAA Combine les services qui sépare les services Plusieurs protocoles tels que Protocoles multiples Protocoles point à point AppleTalk, NetBios et IPX Utilise un challenge simple de Utilise un challenge multiple de réponse d’authentification réponses pour chaque Réponses lorsqu’il authentifie un processus AAA. Chaque utilisateur, lequel est utilisé activité AAA doit être pour toutes les activités des authentifiée. AAA. UNIVERSITÉ D’INGÉNIERIE 60 SYSTÈMES D'AUTHENTIFICATION 5.6 SYSTÈMESD'AUTHENTIFICATION Diameter - Évolution de RADIUS - Soutien SCTP - Extensible - Sécuriser par TLS ou IPSec UNIVERSITÉ D’INGÉNIERIE 61 RÉSUMÉ : AAA OR IAAA Identification Sujet réclame qu’il détient une identité reconnue Authentification Le système vérifie l’identité du sujet Authentication Autorisation Le système vérifie si le sujet peut effectuer les Authorization actions demandés et l’autorise si c’est le cas Traçabilité Accounting / Le système conserve la trace des Auditing actions UNIVERSITÉ D’INGÉNIERIE 62 EXEMPLE : AWS ET AZURE UNIVERSITÉ D’INGÉNIERIE 63  RÉFÉRENCES DAC: https://docs.oracle.com/cd/E56338_01/html/E53984/ugintro-8.html#scrolltoc DAC: https://en.wikipedia.org/wiki/Discretionary_access_control RBAC: https://en.wikipedia.org/wiki/Role-based_access_control MAC: https://docs.oracle.com/cd/E56338_01/html/E53984/ugintro-32.html#scrolltoc Permission POSIX: https://www.linuxsecrets.com/480-linux-unix-permissions-and- attributes RBAC: https://docs.okera.com/odas/2.0.x/catalog/authorization/ ACL in Linux: https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freeni x03/full_papers/gruenbacher/gruenbacher_html/main.html ACL-masque: https://www.cyberciti.biz/tips/understanding-linux-unix-umask-value- usage.html UNIVERSITÉ D’INGÉNIERIE 64