Rapport [PDF]

Zitiervorschau

Page 1

Mémoire de Projet de Fin d’Études Pour l’Obtention du Diplôme

Master Spécialisé en Informatique Option

Réseaux Informatiques, Télécommunications et Multimédia Sujet

Etude et Mise en place d’une solution d’accès logique

Soutenu par :

Sous la direction de :

M.Abdelhalim SOURI

M. Mohamed SENHADJI - ENSIAS M. Annouar BOUCHAAL – Al Barid Bank

M. Amine HAMDOUCHI

Etude et Mise en place d’une solution d’accès logique

Soutenu par :

Membres du jury :

M.Abdelhalim SOURI

M.Amine HAMDOUCHI

M. Mohammed EL KOUTBI – Examinateur (ENSIAS) M. Abdellatif KOBBANE – Président (ENSIAS)

Dédicace

Nous aimerons dédier ce travail :

A nos très chers parents A tous nos chers amis A toutes nos familles A nos chers collègues A nos chers frères A nos chères soeurs Aucun terme et aucune langue ne pourra exprimer notre amour, notre gratitude et nos sentiments envers vous. Pour tout le soutien que nous avez offert , nous vous disons MERCI .

1

Remerciements C’est parce que nous estimons beaucoup tous ceux qui nous ont écouté, conseillé, critiqué et encadré que nous tenons à leur faire part de toute notre gratitude, et plus particulièrement, nous tenons à remercier à travers ces courtes lignes : Notre encadrant externe Mr Annouar BOUCHAAL qui nous a incité à mener à bien ce travail, pour son aide, son temps passé pour nous guider, ses efforts pour nous intégrer dans l’environnement professionnel, pour son dévouement et ses précieux conseils. Notre encadrant interne Mr Mohamed SENHADJI parce qu’il a accepté de nous superviser et suivre les détails de l’avancement de notre travail, ainsi que son aide et ses conseils dans plusieurs étapes du projet. Tous les membres de l’équipe du système d’information , pour leurs aides, leurs remarques, leurs esprits ouverts et leur respect. Nos familles que nous ne pourrons guère oublier de remercier, pour leur soutien à la fois moral et matériel durant toute notre carrière et surtout durant les moments difficiles. Nous tenons aussi à remercier ceux qui ont partagé le même espace de travail dans le département « Département sécurité du système d’information ». Et nous tenons aussi à remercier toute autre personne ayant contribué d’une façon ou d’une autre au bon déroulement de notre projet de stage.

2

Résumé Le présent document constitue une synthèse de notre projet de fin d’études pour l’obtention du Diplôme de Master Spécialisé en Informatique option Réseau Informatique , Télécommunication et Multimédia , au terme d’un stage effectué au sein de la direction des systèmes d’information de AL Baird Banque , sous le thème :Etude et mise en place d’une solution d’accès logique . Notre projet a pour objectif d’instaurer une politique d’accès aux ressources informatiques et de proposer une solution qui facilitera la résolutions des anomalies qui surviennent. dans le système informatique . A cet effet, une étude comparative des différentes solutions existantes sur le marché, a été menée afin d’aboutir à un choix adéquat répondant aux besoins ainsi qu’aux contraintes de l’environnement architectural du système d’information de Al Barid Bank, la mettre en place, la configurer, et la déployer. Pour ce faire il a fallu commencer par mener une étude de l’existant de l’outil open source choisi ainsi que l’étude architecturale de l’environnement. En exploitant les résultats obtenus des études cités précédemment, un cahier de charges a été établi pour cadrer le périmètre du projet pour but de répondre aux attentes de sécurité du SI de la société . Après avoir retenu la solution adéquate, nous l’avons déployé sur un environnement de test qui est une simulation de l’environnement réel.

Mots clés: SIEM, AL Barid Bank . 3

Abstract This report is the result of four months of work , carried out as part of our graduation project inside AL BARID BANK. The project objective is to establish a strong authentication policy and manage logical access. The purpose is is indeed classify and define a security policy that will allow automated permissions management within the company. To achieve this, our mission is to establish a central platform for the correlation logs to manage traceability.

Mots clés: SIEM,AL Barid Bank . 4

Liste des figures 1.1 1.2 1.3

Organigrame Al barid Bank : . . . . . . . . . . . . . . . . . . . . . . . . . Organisationnelle Al barid Bank . . . . . . . . . . . . . . . . . . . . . . . Diagramme de Gantt : . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 2.2 2.3

NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Architecture de packetFence . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Composants de packetFence . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1

Architecture Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 4.2 4.3 4.4 4.5 4.6 4.7

Matrice de contrôle d’accès : . . . Schèma de ORBAC . . . . . . . . Interaction d’ORBAC . . . . . . Hiérarchique du modèle ORBAC Conflit de permission : . . . . . . Simulation du modèle ORBAC . Simulation sur les roles ORBAC :

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

34 38 39 40 43 44 45

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17

Statistiques des évènement des logs : . . . . . . . . . . . . . . . . . Statistiques des transmissions des données . . . . . . . . . . . . . . Tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . Top 10 IP adresses . . . . . . . . . . . . . . . . . . . . . . . . . . . Les champs de l’indice PacketBeat . . . . . . . . . . . . . . . . . . L’archivage ou le traitement avec un serveur de cloud d’amazon S3. Fonctionnement du packetbeat . . . . . . . . . . . . . . . . . . . . Fonctionnement du Packetbeat avec Logstash . . . . . . . . . . . . Architecture générale d’ELK . . . . . . . . . . . . . . . . . . . . . . Les sources des differentes addresses ip . . . . . . . . . . . . . . . . Règles de filtrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pays visités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Plugin Bigdesk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Plugin KOPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Plugin head . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Plugin head . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Plugin Whatson . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

53 53 54 54 55 57 59 60 60 61 62 62 66 67 68 68 70

. . . . . . .

5

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

5 6 9

LISTE DES FIGURES

5.18 Capture d’écran de Logstash

. . . . . . . . . . . . . . . . . . . . . . . . . 72

Page 6

Liste des tableaux 1.1

Tableau des livrables de projet . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1

Comparaison entre les outils opensource NAC . . . . . . . . . . . . . . . . 16

5.1 5.2

Etude comparative des outils SIEM . . . . . . . . . . . . . . . . . . . . . . 50 Etude comparative entre Logstash et Fluentd . . . . . . . . . . . . . . . . 57

7

Liste des abréviations AAA Authentification , Autorisation, Accounting. 44 ACS Access Control System. 36 AD Active Directory. 19 AP Access Point. 17 BLP Bell et Lapadula. 49 BYOD Bring Your Own Device. 38 CCP compte chèque postal. 5 DAC Discretionary Access Control. 45 DAF directeur des affaires financières. 7 HRU Harrison, Ruzzo and Ullmann. 49 I-BAC Identity Based Access Control. 51 IOS Internet Operating Sytem. 17 MAC Mandatory Access Control. 45 MOA Maître d’Ouvrage. 14 NAC Network Access Control. 9 OrBAC Organisation-Based Access Control. 46 PDP Policy Decision Point. 18 PKI Public Key Infrastructure. 35 RBAC Role-Based Access Control. 46 8

Liste des abréviations

Redis REmote DIctionary Server. 84 SEM Security Event Management. 66 SHA System Health Agent. 18 SIEM Security Information and Event Management. 66 SSO Single Sign ON. 36 TBAC Task-based Authorization Controls. 46 TMAC Team-Based Access Control. 46 VMPS VLAN Management Policy Server. 19

Page 9

Sommaire dédicace

1

Remerciements

2

Liste des figures

5

Liste des tableaux

7

Liste des abréviations

8

Introduction

2

1 Contexte général du projet : 1.1 Présentation de l’organisme : . . . . . 1.1.1 L’organisme d’accueil : . . . . 1.1.2 L’organigramme organisationnel 1.2 Présentation du projet : . . . . . . . . 1.2.1 Contexte du projet : . . . . . . 1.2.2 Objectif du projet : . . . . . . . 1.2.3 Conduite du projet : . . . . . . 1.2.4 Planning du projet . . . . . . . 1.2.5 Diagramme de gantt : . . . . . 1.3 Périmètre du projet . . . . . . . . . . . 1.4 Mission du projet : . . . . . . . . . . . 1.5 Livrables du projet . . . . . . . . . . . 1.6 Conclusion : . . . . . . . . . . . . . .

. . : . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

2 Network Access Control 2.1 Introduction : . . . . . . . . . . . . . . . . . . . 2.2 Solutions libre et commerciales . . . . . . . . . 2.3 Acteurs commerciaux du NAC . . . . . . . . . . 2.3.1 Cisco System : . . . . . . . . . . . . . . 2.3.2 NetClarity NAC Walls : . . . . . . . . . 2.3.3 Microsoft : Network Access Protection :

10

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

4 4 4 4 7 7 7 8 9 9 10 10 11 12

. . . . . .

13 13 14 14 14 14 14

SOMMAIRE

2.4

2.5 2.6

2.7

2.3.4 McAfee NAC . . . . . . . . . . . . . . . . . . . . . . . . . Solution libre du NAC : . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 PacketFence . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 FreeNac: . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 OpenNac : . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.4 Net Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.5 Rings Security Analyser . . . . . . . . . . . . . . . . . . Etude comparative des solutions open source . . . . . . . . . . . Solution PacketFence . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Conformité . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1.1 Détection des anomalies des Activités du réseau: 2.6.1.2 Les analyses proactives de vulnérabilité . . . . . . 2.6.1.3 Isolement de périphériques problématiques . . . . 2.6.2 Architecture de packetFance . . . . . . . . . . . . . . . . . 2.6.3 Fonctionnalités : . . . . . . . . . . . . . . . . . . . . . . . 2.6.3.1 Gestion flexible VLAN et le contrôle d’accès basé rôles . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.3.2 Accès clients . . . . . . . . . . . . . . . . . . . . 2.6.3.3 Profils . . . . . . . . . . . . . . . . . . . . . . . . 2.6.3.4 Plus intégrités sur les types de violation . . . . . 2.6.3.5 Enregistrement automatique : . . . . . . . . . . . 2.6.3.6 Authentification flexible : . . . . . . . . . . . . . Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Authentification forte 3.1 Définition de l’authentification : . . . . . . . . . . . . . . . . . . 3.2 Les facteurs d’authentification : . . . . . . . . . . . . . . . . . . 3.3 Definition de l’authentification forte : . . . . . . . . . . . . . . . 3.4 les facteurs d’authentification . . . . . . . . . . . . . . . . . . . 3.4.1 OTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 Code NIP . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4 Biométrie . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.5 SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.6 ACS (Access Control System ) et l’authentification forte 3.4.7 Authentification par Active Directory : . . . . . . . . . . 3.5 Etude de l’existant : . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 NeXus Hybrid Access Gateway : . . . . . . . . . . . . . 3.5.1.1 -Simplicité pour les utilisateurs . . . . . . . . . 3.5.1.2 -Plus de sécurité, moins d’administration . . . . 3.5.1.3 La solution hybride : . . . . . . . . . . . . . . . 3.6 Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . sur les . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

Page 11

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

14 15 15 15 15 15 15 15 16 17 17 17 17 17 18

. . . . . . .

18 19 19 19 20 20 21

. . . . . . . . . . . . . . . . . .

22 22 22 23 25 25 25 25 25 25 25 26 26 26 29 29 29 30 30

SOMMAIRE

3.8

Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Autorisation 4.1 Définition de la politique d’accès : . . . . . . . . . . . . . . . . . 4.2 Politique de sécurité : . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Définition : . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Les politiques et les modèles de contrôle d’accès : . . . . . 4.3 Les modèles de sécurité informatique : . . . . . . . . . . . . . . . 4.3.1 Le contrôle d’accès discrétionnaire (DAC) : . . . . . . . . . 4.3.2 Le modèle I-BAC (Identity Based Access Control ) . . . . 4.3.3 Le modèle R-BAC (Role Based Access Control) . . . . . . 4.3.4 Le modèle T-BAC(Task Based Acces Control) . . . . . . . 4.3.5 Le modèle T-MAC(Team Based Acces Control) . . . . . . 4.3.6 Le modèle OR-BAC (Organization Based Access Control) 4.3.6.1 Les objectifs et avantages d’Or-BAC : . . . . . . 4.3.6.2 Les interactions d’Or-BAC : . . . . . . . . . . . . 4.3.6.3 La notion de contexte : . . . . . . . . . . . . . . 4.3.6.4 La notion de hiérarchie : . . . . . . . . . . . . . 4.3.6.5 La notion de délégation: . . . . . . . . . . . . . 4.3.6.6 La gestion de conflit : . . . . . . . . . . . . . . . 4.4 Application du modèle OR-BAC : . . . . . . . . . . . . . . . . . 4.5 Conclusion: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Centralisation / Corrélation des logs et Traçabilité 5.1 Corrélation des logs . . . . . . . . . . . . . . . . . . . 5.1.1 Définition de l’outil SIEM : . . . . . . . . . . 5.1.2 Les fonctionnalités d’un SIEM : . . . . . . . . 5.1.2.1 Collecte : . . . . . . . . . . . . . . . 5.1.2.2 Normalisation : . . . . . . . . . . . . 5.1.2.3 Agrégation : . . . . . . . . . . . . . . 5.1.2.4 Corrélation : . . . . . . . . . . . . . 5.1.2.5 Reporting : . . . . . . . . . . . . . . 5.1.2.6 Archivage : . . . . . . . . . . . . . . 5.1.3 Rejeu des évènements : . . . . . . . . . . . . . 5.2 Comparaison des outils open source SIEM : . . . . . 5.2.1 Les besoins et les contraintes de choix . . . . 5.2.2 Les critères du Choix de l’outil SIEM . . . . 5.2.3 ELK : . . . . . . . . . . . . . . . . . . . . . . 5.2.3.1 Avantages : . . . . . . . . . . . . . . 5.2.3.2 Inconvénients : . . . . . . . . . . . . 5.2.4 OSSIM : . . . . . . . . . . . . . . . . . . . . . 5.2.4.1 Avantages : . . . . . . . . . . . . . . 5.2.4.2 Inconvénients : . . . . . . . . . . . . 5.2.5 Synthèse de choix de la solution . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

Page 12

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

31 31 32 32 33 34 34 35 35 36 37 37 37 38 39 41 42 42 43 45

. . . . . . . . . . . . . . . . . . . .

46 46 46 47 47 47 47 48 48 48 48 49 50 51 51 51 52 52 52 52 52

SOMMAIRE

5.2.6 Quelques capture d’écran de notre solution ELK 5.3 Solution ELK : . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Les Composantes d’ELK : . . . . . . . . . . . . 5.3.2 Elasticsearch : . . . . . . . . . . . . . . . . . . . 5.3.2.1 Stockage dans elasticsearch . . . . . . 5.3.3 Logstash : . . . . . . . . . . . . . . . . . . . . . 5.3.4 Packbeat : . . . . . . . . . . . . . . . . . . . . . 5.3.5 Kibana : . . . . . . . . . . . . . . . . . . . . . . 5.4 Traçabilité . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Les contraintes techniques de la traçabilité . . 5.4.2 traçabilité sur ABB . . . . . . . . . . . . . . . . 5.5 Perspective : . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Installation d’Elasticsearch et ses plugins . . . . . . . 5.6.1 Plugin Marvel . . . . . . . . . . . . . . . . . . . 5.6.2 Plugin BigDesk . . . . . . . . . . . . . . . . . . 5.6.3 Plugin Elasticsearch Kopf . . . . . . . . . . . . 5.6.4 Plugin Elasticsearch-head . . . . . . . . . . . . 5.6.5 Plugin Whatson . . . . . . . . . . . . . . . . . . 5.7 Installation du Logstash . . . . . . . . . . . . . . . . . 5.8 Installation du Logstash-forwarder . . . . . . . . . . . . 5.9 Installation du PacketBeat . . . . . . . . . . . . . . . . 5.10 Installation du Kibana . . . . . . . . . . . . . . . . . .

: . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

Conclusion générale

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

53 55 55 55 56 56 58 60 60 61 61 63 64 65 65 66 67 68 71 72 76 77 78

Webographie 79 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Page 1

Introduction L’information est un élément vital pour l’entreprise du monde moderne, cette ressource stratégique est confrontée à la diffusion et au partage perpétuellement accentué par le développement rapide des technologies de l’information, chose qui peut engendrer une perte de sa valeur et son contenu initial. C’est pourquoi la sécurité et la fiabilité de l’information doivent impérativement être garanties au sein de l’entreprise. En effet, le système d’information doit permettre d’effectuer les choix stratégiques de l’entreprise par un management de qualité. Il permet la coordination entre différentes structures, facilite les échanges internes, soutient les activités de l’organisation et contribue ainsi à l’amélioration des performances de l’entreprise. Ainsi, le Système d’Information nécessite une attention particulière en matière de maintenance et de sécurité, étant donné qu’il est exposé à des pannes et des menaces qui, de nos jours, ne cessent de s’accroître, d’où l’exigence de l’instauration d’un système qui garantit la sécurité les données sensibles de l’entreprise. Pour cela, de nombreuses techniques de sécurisation sont mises en place, afin d’assurer le respect de bonnes pratiques de sécurité. La Sécurité des Systèmes d’Information devient donc un enjeu crucial pour garantir la continuité des processus « Métier », la protection du patrimoine constitué par les informations (applications, données, documents, etc.) et le respect des législations et des réglementations. Partant de ces considérations, Barid banque ne cesse de développer et d’améliorer la sécurité de son système informatique en respectant les normes en vigueur afin de renforcer le niveau de sécurité de toutes les communications engageant le système d’information de la Banque, cet objectif a été satisfait grâce à la robustesse de la solution déployée. Cependant, malgré les efforts déployés la banque reste en défi continuel pour améliorer l’administration de son système informatique tout en essayant de résoudre le dilemme sécurité informatique et l’entrave à la facilité d’utilisation du système ou à la productivité des employés. Dans ce contexte, et vu son engagement actif dans l’amélioration et l’évolution structurantes de ses moyens Informatiques, Barid Banque a décidé de lancer un projet de centralisation et de corrélation des fichiers journaux. Ce projet vise à déterminer une politique d’accès,

2

SOMMAIRE

garder une traçabilité et renvoyer des alertes en cas d’incidents qui touchent le Data Center. Le présent rapport se compose de cinq chapitres. Le premier définit le contexte général du projet à savoir ; la présentation de l’organisme d’accueil, et la description de notre projet. Le second intitulé « Network accès control» débutera par le contexte dans lequel est apparu le besoin du contrôleur d’accès réseaux pour après définir ce qu’est ce mécanisme , faire une étude comparative des outils et ensuite choisir une solution open source (PacketFence), enfin , l’explication détaillé de l’architecture de cet outil sera présenté ainsi qu’une description de ses fonctionnalités et le chapitre sera clôturé par une simulation . Le troisième chapitre dit « authentification forte » commencera par une définition de ce mécanisme, une présentation des facteurs déterminants de cette technologie, ensuite l’importance d’instaurer l’authentification forte au sein de toutes entreprises marocaines et enfin une étude de l’existant pour dégager les points fort de cette solution. Une étude fonctionnelle et technique est présente dans le quatrième chapitre afin de définir les exigences fonctionnelles de l’autorisation considérée comme la clé de la voute de la sécurité informatique, suivie d’une description des modèles de la securité , et en une application du modèle ORBAC sur les profils de Al Barid Bank . Arrive juste après le cinquième chapitre «Centralisation / corrélation des logs et Traçabilité » dans lequel on trouvera un benchmarking des outils SIEM leurs fonctionnalités ainsi que leurs descriptions, ensuite on présentera les besoins et les contraintes de notre choix. L’élaboration de la partie centralisation et corrélation des logs va nous faciliter le traitement de la partie Traçabilité dans laquelle on va traiter ses contraintes et on va présenter la matrice de traçabilité ainsi que ses avantages. Finalement on présentera une conclusion qui reprendra, d’une vision de recul et plus global, le travail effectué durant notre stage de fin d’étude suivi des perspectives que pourrait avoir la solution pour ainsi tirer profits des fonctionnalités et services qu’elle offre.

Page 3

Chapter 1 Contexte général du projet : Dans ce chapitre, nous exposons le contexte général du projet. On présente dans un premier temps l’organisme d’accueil et ses services. Ensuite nous allons présenter les organismes ciblés par notre projet. Et enfin introduire le travail demandé.

1.1 1.1.1

Présentation de l’organisme : L’organisme d’accueil :

Al Barid Bank, filiale de Barid Al-Maghrib, a été lancée le 8 juin 2010, pour être au service du plus grand nombre de marocains. Héritière de l’activité des services financiers du groupe Barid Al-Maghrib, Al Barid Bank s’appuie sur un savoir-faire reconnu. En effet, l’exercice des services financiers par remonte à 1926, année de création du compte chèque postal CCP. Citoyenne, accessible, proche de ses clients, Al Barid Bank dispose d’un très large réseau, avec plus de 1800 agences réparties sur le Royaume, aussi bien dans les zones urbaines que dans les zones rurales les plus reculées. Offrant une large gamme de produits et services bancaires à une tarification adaptée, Al Barid Bank facilite l’accès aux services financiers et contribue ainsi à l’accélération de la bancarisation des citoyens marocains. sous le slogan Al Barid Bank se veut la banque de tous, la banque de tous les Marocains

1.1.2

L’organigramme organisationnel :

L’organigramme Al Barid Bank se présente comme suit :

4

chapitre 1

1.1. PRÉSENTATION DE L’ORGANISME :

Figure 1.1: Organigrame Al barid Bank :

Projet Fin d’Etudes

5

2014-2015

chapitre 1

1.1. PRÉSENTATION DE L’ORGANISME :

Figure 1.2: Organisationnelle Al barid Bank

Barid Bank est hiérarchisé de la manière décrite par l’organigramme précédent. Elle est constituée d’un directeur général qui collabore avec le directeur délégué. Le directeur général interagit directement avec la directrice des ressources humaines ainsi qu’avec le directeur de site. Par ailleurs, le directeur délégué, quant à lui, interagit avec le directeur des affaires financières DAF , avec le directeur commercial et finalement avec le directeur du système d’information. En parallèle, le département du système d’information est divisé cinq parties, à savoir, le département infrastructure, le département application, le département support ainsi que le département service delivery et dernièrement le département qui s’occupe de la sécurité des systèmes d’information dans lequel nous effectuons notre stage.

Projet Fin d’Etudes

6

2014-2015

chapitre 1

1.2 1.2.1

1.2. PRÉSENTATION DU PROJET :

Présentation du projet : Contexte du projet :

Al Barid Bank héritière de l’activité des services financiers du groupe Barid al Maghrib elle s’appuie sur un savoir faire reconnue . Offrant une large gamme de produits et services bancaires à une tarification adaptée aux citoyens marocains . L’exigence de la securité des données au sein d’une banque est tres capitale dans nos jours .De nombreuses affaires récentes ont mis en avant le probléme du respect de la vie privée sur les lieu de travail au travers de l’utilisation parfois abusive de l’informatique et des reseaux . Pour lutter contre la menace accidentelle ou intentionnelles de ses données , Al Barid Bank s’engage à mettre en place des moyens pour réduire la vulnérabilité de son système . Il convient alors d’identifier les exigences fondamentales en matière de sécurité informatique . Elles caractérisent en quoi s’attendent les utilisateurs de systèmes informatiques en regard de la securité . Afin de répondre aux exigences cités ci-dessous ,le département de la securité des systèmes informatiques a opter pour faire signé un contrat de confidentialité pour chaque intervenant sur le système informatique . De surcroit , en vue de suivre les bonnes maniéres de securité des systèmes d’informations ,il est imperatif d’intégrer un système de centralisation des logs et de les corréler afin de générer des alertes pour un dysfonctionnement du système . Finalement ,determiner une politique d’accés aux ressources informatiques ainsi que les rapports d’invesigations seront générés d’une maniéres automatique ou manuelle .En effet , les rapports seront générées d’une maniére mensuelle et annuelle .Ces rapports sont destinés pour des investigations des auditeurs internes à la société pour vue de régler le dysfonctionnement du système et avoir une transparence et une traçabilité des évènements survenus .

1.2.2

Objectif du projet :

Notre projet a pour objectif d’instaurer une politique d’accès aux ressources informatiques de plus proposer une solution qui facilitera la résolutions des anomalies qui surviennent dans le système :

• Mise en place d’une solution d’authetification forte . Projet Fin d’Etudes

7

2014-2015

1.2. PRÉSENTATION DU PROJET :

chapitre 1

• Mise en place d’une politique d’accès (Autorisation) . • Mise en place d’une solution NAC (Network Access Control) basée sur open source. • Centraliser les fichiers journaux survenus dans un seul serveur . • Corrélation des fichiers journaux . • Faciliter la recherche des incidents. • Génération des rapports mensuelles et annuelle . • La Traçabilité .

1.2.3

Conduite du projet :

Un processus de développement est une démarche visant à organiser de bout en bout le bon déroulement d’un projet informatique. C’est une étape très importante dans un projet informatique qui peut affecter largement son aboutissement, de telle façon qu’un mauvais choix du processus de développement peut conduire à son échec. Un processus de développement définit une séquence d’étapes, en parties ordonnées, qui concoure à l’obtention d’un système logiciel nouveau ou à l’évolution d’un système existant. Ce processus a pour objectif de produire des solutions informatiques de qualité répondant aux besoins des utilisateurs dans des temps et des coûts prévisibles. De ce fait, l’adéquation du projet au processus de développement peut largement affecter le sort d’un projet informatique. Vu les spécificités de notre projet résumées dans ce qui suit : • Une grande évolutivité . • Les exigences spécifiques de notre encadrant. • La grande taille du projet. Nous nous sommes focalisés sur une partie limitée et maitrisable du projet chaque itération a un but bien précis. A cet effet , nous avons décidé de travailler avec un processus qui s’adapte le mieux à notre projet à savoir la méthode agile Scrum. Scrum est une méthode agile basée sur un concept itératif et incrémental visant à produire des sous-produits à chaque itération appelée « Sprint ». Le mode de fonctionnement de la méthode Scrum est comme suit : Projet Fin d’Etudes

8

2014-2015

1.2. PRÉSENTATION DU PROJET :

chapitre 1

• Le projet est divisé en un ensemble de fonctionnalités. • Les fonctionnalités sont réparties sur des itérations appelées Sprint. • Chaque sprint dure entre 3 et 4 semaines.

1.2.4

Planning du projet

La planification du projet est une phase importante d’avant-projet. Elle consiste non seulement à délimiter le périmètre temporel du projet, mais aussi à prévoir le déroulement des activités tout au long de la période allouée à ce dernier. Cinq étapes ont été définies : la première est dédiée à l’étude préliminaire pour bien délimiter le périmètre du projet. La seconde est consacrée à l’étude fonctionnelle dont les objectifs sont de bien cerner le sujet. Quant à la troisième étape, elle traite l’étude technique du projet. L’étape suivante consiste en la conception de la solution, et finalement, la dernière étape consiste à la réalisation, la validation et au déploiement de la solution. La figure suivante détaille la planification du projet.

1.2.5

Diagramme de gantt :

Figure 1.3: Diagramme de Gantt :

Projet Fin d’Etudes

9

2014-2015

1.3. PÉRIMÈTRE DU PROJET

chapitre 1

La première phase consiste à réaliser une analyse préliminaire technique consistant à : • Recueillir l’information et les témoignages. • Déterminer les besoins. • Établir la liste des contraintes à respecter. • Réaliser l’étude préliminaire. • Offrir un deuxième avis concernant une étude préliminaire existante.

La deuxième phase est l’élaboration d’un des outils SIEM open source permettant de réaliser une comparaison directe des fonctionnalités de chaque outil afin de procéder au choix de l’outil qui respecte les normes, les besoins fonctionnels ainsi que les contraintes. La phase suivante à savoir, la phase de l’étude fonctionnelle. Cette phase est divisée en deux sous parties; la première partie permet de capturer les besoins technique de la société pour vue de procéder à l’analyse. La quatrième phase du projet permet l’élaboration d’une étude technique permettant la capture des besoins techniques à partir de tous les intervenants de l’outil afin de satisfaire au maximum la société en intégrant un outil de la sécurité des systèmes. Ainsi, éditer un document technique décrivant toutes les fonctionnalités désirées. La dernière phase de la réalisation du projet est la phase de l’implémentation de l’outil. Celle-ci permet de suivre un enchainement structuré de l’implémentation de l’outil SIEM. En effet, pour implémenter la solution il faudrait commencer tout d’abord par centraliser tous les logs circulants dans le système d’information, ensuite procéder à la corrélation de certains évènements souhaités. Ensuite, intégrer un détecteur d’intrusion et adapter la solution du reporting selon les besoins souhaités. Finalement, la dernière sous partie est de réaliser un jeu de test d’intrusions.

1.3

Périmètre du projet

L’objectif de cette partie est l’identification du projet ainsi que l’organisation de la mise en oeuvre.

1.4

Mission du projet :

Dans le cadre du projet, des principales missions sont à accomplir, à savoir: Projet Fin d’Etudes

10

2014-2015

1.5. LIVRABLES DU PROJET

chapitre 1

• Etude préliminaire. • Etude comparative des outils. • Etude de l’existant. • Etude fonctionnelle. • Analyse. • Implémentation d’une solution pour chaque partie partie : Authentification , Autorisation , la corrélation des événements . • Intégration et test. • Déploiement • Documentation du projet.

1.5

Livrables du projet

A la fin de ce projet, des livrables doivent être clairement définis pour un résultat conforme à des normes de qualité, pour le moindre coût et dans le meilleur délai possible. Quelques-uns devront être livrés avec le produit final, alors que d’autres seront à la disposition du client et l’équipe de développement comme illustré dans le tableau ci-dessous :

se

ion lidat a v e ble d a s n o Resp

able

Pha

Livr

Initialisation

Benchmark des outils cahier de charge planning

MOA

Analyse

Spécifications générales

MOA

Conception

Spécification fonctionnelles ,Spécifications techniques

MOA

Projet Fin d’Etudes

11

2014-2015

1.6. CONCLUSION :

chapitre 1

Réalisation

Integration Dépoiement

et

Centralisation des logs - Corrélation des logs - Traçabilité - Reporting personalisé

MOA

Personnalisation de la solution existante

MOA

Table 1.1: Tableau des livrables de projet

1.6

Conclusion :

Ce chapitre nous a permis de situer le contexte général du projet. Il nous a permis de présenter l’organisme d’accueil, d’avoir un aperçu sur la problématique du projet ainsi de comprendre ses objectifs. Le chapitre suivant décrira l’ approche de la sécurité informatique Network Access Control (NAC) .

Projet Fin d’Etudes

12

2014-2015

Chapter 2 Network Access Control 2.1

Introduction :

Network Acces Control : Un Contrôleur d’accès au réseau (Network Access Control ou NAC) est une méthode informatique permettant de soumettre l’accès à un réseau d’entreprise à un protocole d’identification de l’utilisateur et au respect par la machine de cet utilisateur des restrictions d’usage définies pour ce réseau. Plusieurs sociétés comme Cisco Systems , Microsoft ou Nortel Networks ont développé des frameworks permettant d’implémenter des mécanismes de protection d’accès au réseau d’entreprise et de vérifier le respect par les postes clients, des règles de sécurité imposées par l’entreprise : état de la protection antivirus, mises à jour de sécurité, présence d’un certificat, et bien d’autres. Le concept du NAC existe pour répondre à une solution de sécurité toujours croissante. Le contrôle d’accès au réseau (NAC) tient un rôle toujours plus important dans la stratégie globale de sécurité du réseau de l’entreprise. Dès lors, les stratégies d’attaque ne dépendent plus seulement de l’action physique de l’utilisateur, mais dépendent aussi très souvent de sa machine qui est capable d’initier seule des processus malveillants. Le NAC constitue donc une nouvelle phase dans la définition des critères d’accès au réseau d’où sa nécessité.

Figure 2.1: Network Access Control

13

chapitre 2

2.2 2.3 2.3.1

2.2. SOLUTIONS LIBRE ET COMMERCIALES

Solutions libre et commerciales Acteurs commerciaux du NAC Cisco System :

Cisco Network Admission Control (NAC) exploite au maximum l’infrastructure réseau pour limiter les dégâts occasionnés par les virus et les vers. Le principal atout de Cisco se trouve dans IOS (Internet Operating Sytem). Grâce à Cisco, l’entreprise peut fournir aux unités d’extrémité comme les PC et les serveurs, un accès réseau qui respecte scrupuleusement les politiques de sécurité en place. Le dispositif de Cisco met en scène 3 acteurs : • un serveur chargé de la politique de sécurité du réseau Cisco Secure ACS (Access Control Server) • un protocole de contrôle sur le point d’accès au réseau ( AP Wifi, routeur, Switch...), • un trust agent sur le poste de l’utilisateur (petite application).

2.3.2

NetClarity NAC Walls :

Les appareils de NetClarity « NACwalls » fournissent une évaluation des systèmes d’extrémité. Cela garantit la conformité aux politiques de sécurité tout en bloquant les tentatives malveillantes d’accéder au réseau. Les appareils « NACwalls » peuvent augmenter la qualité de l’audit et elles générent des rapports de conformité qui permet considérablement de réduire le temps, les efforts et les frais à cet égard, ils fournissent en temps réel le contrôle interne et l’accès au réseau avec les e-mails ou les téléphones portables .

2.3.3

Microsoft : Network Access Protection :

Network Access Protection se compose d’un serveur NPS (Network Policy Server), qui est un serveur RADIUS, des (System Health Validator) chargés de communiquer avec les SHA (System Health Agent) pour évaluer le système d’extrémité et un serveur PDP (Policy Decision Point) qui définit la politique de sécurité à accorder pour chaque machine. Du coté client on trouve un agent NAP qui se charge de fournir un bilan de santé de la machine. On peut lui ajouter différents plugins SHA qui regardent chacun un aspect spécifique du système d’extrémité (anti-virus,pare-feu , registre, etc).

2.3.4

McAfee NAC

La solution McAfee NAC protège les sociétés contre les risques en contrôlant l’accès à leurs réseaux par leurs employés, invités et sous-traitants, en tout temps et depuis tout point. McAfee NAC apporte: Un accès accordé uniquement aux machines exemptes d’infections. Une gestion et un respect des politiques de sécurité grâce à « McAfee Policy Enforcer»

Projet Fin d’Etudes

14

2014-2015

2.4. SOLUTION LIBRE DU NAC :

chapitre 2

2.4

Solution libre du NAC :

Il existe une multitude de solutions libres pour un NAC. Nous n’en retiendrons que quelques-unes à savoir : PacketFence, FreeNAC, NetPass, Ring Security Analyser

2.4.1

PacketFence

Une solution comme PacketFence permet de sécuriser les branchements au réseau. Donc, au moment où on branche le fil réseau dans son ordinateur ou au moment où on se connecte sur le réseau sans fil, PacketFence vérifie si l’ordinateur s’est déjà connecté.

2.4.2

FreeNac:

C’est un projet actif présenté comme offrant une gestion simplifiée des VLANs, un contrôle d’accès au réseau et un outil d’inventaire, FreeNAC est basé principalement sur le protocole VMPS (authentification sur adresse MAC). Il permet aussi l’utilisation 802.1X en interaction avec un serveur RADIUS. La partie évaluation n’est pas vraiment prise en compte

2.4.3

OpenNac :

OpenNAC est un opensource Network Access Control pour les environnements LAN / WAN d’entreprise. Il permet l’authentification, l’autorisation et l’audit des politiques sur la base tous les accès au réseau. Il prend en charge les diférents fournisseurs de réseau comme Cisco, Alcatel, 3Com ou Extreme Networks, et les différents clients comme les PC avec Windows ou Linux, Mac, appareils comme les smartphones et les tablettes. Basé sur des composants open source , l’auto-développement et sur les normes de l’industrie telles que FreeRadius, ,802.1x AD , , ... Il est très extensible, de nouvelles fonctionnalités peuvent être incorporés car il est architecturé en plugins. Facilement intégrable avec les systèmes existants . Il fournit des services à valeur ajoutée tels que la gestion de configuration, réseau, configurations de sauvegarde, la découverte du réseau et de surveillance de réseau.

2.4.4

Net Pass

C’est un projet non actif, par défaut les systèmes d’extrémité sont positionnés dans un VLAN de quarantaine, celui-ci laisse passer les requêtes DHCP et DNS mais bloque le trafic Web sauf liste blanche (sites de mise à jour). L’évaluation est faite avec Nessus, si la conformité est bonne, le serveur Net Pass change le VLAN du poste. Une réévaluation est possible à intervalles réguliers. Net Pass est Basé sur Open VMPS, le principe est d’isoler les systèmes d’extrémité en les positionnant en quarantaine si leurs comportements réseau ne sont pas en adéquation avec la politique de sécurité.

2.4.5

Rings Security Analyser

C’est un projet en production actuellement créé à l’Université du Kansas, c’est un portail Web qui utilise une applet Java pour évaluer (système, logiciel anti-virus, etc...) les machines cherchant à accéder au réseau (autorisation valide pendant sept jours). En cas d’échec, les accès sont réduits aux sites de mises à jour de logiciels, d’anti-virus,...

2.5

Etude comparative des solutions open source

Projet Fin d’Etudes

15

2014-2015

2.6. SOLUTION PACKETFENCE

chapitre 2

Analyse des besoins authentification gestion des bandes passantes vendor Support pour l’infrastructure filaire et sans fil Intégration du logiciel communauté interface d’administration Compte-rendu

nce

C nNA Ope équitablement oui non

etFe Pack oui oui oui

Nac Free non internet oui non

multivendor oui

multivendor oui

multivendor oui

oui active interface web

oui active interface web

oui

oui

commercial assez active basé principalem sur les fenêtres oui

Table 2.1: Comparaison entre les outils opensource NAC

2.6

Solution PacketFence

P

acketFence est une solution open source de contrôle d’accès gratuite . Bénéficiant d’un ensemble de fonctionnalités impressionnantes, y compris un captif portail pour l’enregistrement et l’assainissement, la gestion centralisée filaire et sans fil, de puissantes options de gestion du BYOD, support 802.1X, l’isolation de couche 2 du modèle OSI des dispositifs problématiques; PacketFence peut être utilisé pour sécuriser efficacement les petits réseaux à très grands réseaux hétérogènes. Parmi ses différents marchés sont: • Les banques • Les collèges et les universités • les sociétés d’ingénierie • Les centres de congrès et d’exposition • Les hôpitaux et centres médicaux • hôtels. • Les entreprises manufacturières • les conseils scolaires • Les entreprises de télécommunications Distribué sous la licence GPL. Projet Fin d’Etudes

16

2014-2015

2.6. SOLUTION PACKETFENCE

chapitre 2

2.6.1

Conformité

2.6.1.1 Détection des anomalies des Activités du réseau: les Activités de réseau anormales (virus d’ordinateur, les vers, les logiciels espions, trafic nié par la politique de l’établissement, etc.) peuvent être détectés à l’aide locale et distante Snort . Au-delà de la simple détection, les couches PacketFence ont leurs propre mécanisme d’alerte et de suppression sur chaque type d’alerte.Elles proposent Un ensemble d’actions configurables pour chaque violation pour les administrateurs. 2.6.1.2 Les analyses proactives de vulnérabilité Les analyses de vulnérabilité peuvent être effectuées lors de l’enregistrement, prévu ou sur une base ad hoc. PacketFence corrèle les Nessus / openvas les identifiants de la vulnérabilité de chaque balayage de la configuration de la violation, le retour est contenu dans des pages web spécifiques, que la vulnérabilité de l’hôte peut avoir. 2.6.1.3 Isolement de périphériques problématiques acketFence prend en charge plusieurs techniques d’isolation, y compris l’isolement VLAN VoIP avec le soutien (même dans des environnements hétérogènes) pour de multiples fournisseurs de commutateurs.

P

2.6.2

Architecture de packetFance

Figure 2.2: Architecture de packetFence

Projet Fin d’Etudes

17

2014-2015

2.6. SOLUTION PACKETFENCE

chapitre 2

Figure 2.3: Composants de packetFence

2.6.3

Fonctionnalités :

Note : Dans la section suivante, noeud est utilisé pour désigner un dispositif sensible au réseau qui est contrôlé et surveillé par PacketFence. Il peut être un PC, un ordinateur portable, une imprimante, un téléphone IP, etc 2.6.3.1 Gestion flexible VLAN et le contrôle d’accès basé sur les rôles La solution est construite autour de la notion d’isolement du réseau par affectation de VLAN. En raison de sa longue expérience et plusieurs déploiements, la gestion des VLAN PacketFence a grandi pour être très flexible au fil des ans. La topologie du VLAN peut être maintenu telle qu’elle est et que deux nouvelles options doivent être ajoutées tout au long du réseau: enregistrement VLAN et l’isolement VLAN. En outre, PacketFence peut également faire usage de rôles soutien de nombreux fournisseurs d’équipements. Les rôles peuvent être assignés en utilisant les divers moyens: • Par commutateur (par défaut pour VLAN) . • Par catégorie de client (par défaut pour les rôles). • par client. • Utilisation de toute décision arbitraire (si vous utilisez nos points d’extension de perl). Projet Fin d’Etudes

18

2014-2015

2.6. SOLUTION PACKETFENCE

chapitre 2

Aussi, le procédé par-interrupteur peut être combiné avec les autres. Par exemple, avec une configuration de PacketFence par défaut, un VLAN ou un rôle peuvent être assignés à vos imprimantes et vos pc (si classés correctement) sur la base de ce que l’équipement qu’ils sont connectés. Cela implique que vous pouvez facilement avoir le type par périphérique par le renforcement des réseaux locaux virtuels. 2.6.3.2 Accès clients De nos jours, la plupart des organisations traitent avec beaucoup de consultants auprès de diverses entreprises sur place qui nécessitent un accès à Internet pour leur travail. Dans la plupart des cas, un accès au réseau d’entreprise est donné avec peu ou pas de vérification de l’individu ou le périphérique. En outre, il est rarement nécessaire qu’ils aient accès à l’infrastructure interne de l’entreprise, il est fait de cette façon pour éviter (gestion de VLAN par port) les fardeaux administratifs. PacketFence prend en charge un VLAN d’invité spécial ou le rôle de la boîte. Si vous utilisez un VLAN invité, vous configurez votre réseau afin que le VLAN invité ne va que vers l’Internet et le VLAN d’inscription et le portail captif sont les composants utilisés pour expliquer au client comment s’inscrire à l’accès et comment ses œuvres/ d’accès. Ceci est habituellement marqué par l’organisation qui offre l’accès au réseau. Plusieurs moyens des enregistrements des clients sont possibles: • L’enregistrement manuel des clients. • Mot de passe de la journée. • Auto-inscription (avec ou sans pouvoirs). • Accès invité parrainage (employé se portant garant pour un invité). • Accès invité activé par courriel de confirmation. • Accès invité activé par la confirmation de la téléphonie mobile (par SMS). • Accès invité activé par une authentification Facebook / Google / GitHub 2.6.3.3 Profils PacketFence soutient le concept de profil du portail. Un profil de portail définit le flux de travail d’enregistrement qui sera utilisé, avec des pages d’inscription et d’assainissement. Avec PacketFence, vous pouvez définir des profils de portails différents basés sur un VLAN ou un attribut SSID. Cela signifie, par exemple, que vous pouvez définir des profils de portails différents pour vos réseaux filaires et sans fil. Ou, vous pouvez définir par- portail. 2.6.3.4 Plus intégrités sur les types de violation PacketBeat peut bloquer automatiquement des périphériques particuliers dans votre réseau . En plus d’utiliser Snort, OpenVAS ou Nessus comme une source d’information, PacketFence peut combiner les mécanismes de détection suivantes pour bloquer efficacement l’accès au réseau à partir de ces périphériques indésirables:

Projet Fin d’Etudes

19

2014-2015

2.6. SOLUTION PACKETFENCE

chapitre 2

DHCP empreintes : PacketFence peut bloquer les périphériques en fonction de leur empreinte DHCP. Presque tous les systèmes d’exploitation là-bas ont une empreinte DHCP unique. PacketFence peut faire usage de cet accès de ces dispositifs réseau d’informations et de bloc. Basé sur les empreintes digitales DHCP, vous pouvez bloquer automatiquement, par exemple: •Appareils Sony PlayStation ou d’autres consoles de jeux . •les points d’accès sans fil WAP •les téléphones VoIp. User-Agent PacketFence: peut bloquer les appareils basés sur la condition User-Agent lorsque ces dispositifs particuliers effectuent l’activité du réseau en utlisant leur navigateur Web integré . Avec cela , vous pouvez bloquer automatiquement ,par exemple : •les appareils iPhone ou Apple iPod . •Toute personne utilisant l’ancien navigateur Web Internet Explorer . Adresses MAC : PacketFence peut bloquer l’accès réseau aux périphériques ayant une adresse MAC modèle spécifique. Avec cela, vous pouvez bloquer automatiquement, par exemples, tous les périphériques à partir d’un fournisseur de réseau spécifique. 2.6.3.5 Enregistrement automatique : Par dispositif de réseau Un dispositif de réseau (Switch, AP, manette sans fil) peut être configuré pour enregistrer automatiquement toutes les adresses MAC qui demandent l’accès au réseau. Très utile pour une transition en production. Par DHCP empreintes digitales Les empreintes DHCP peuvent être utilisé pour enregistrer automatiquement certains types de périphériques (par exemple. Les téléphones ,... ). Par adresse MAC vendeur La partie de fournisseur d’une adresse MAC peut être utilisé pour enregistrer automatiquement les périphériques à partir d’un fournisseur. Par exemple, tous les produits Apple pourraient être enregistrés automatiquement en utilisant une telle règle. 2.6.3.6

Authentification flexible :

PacketFence peut authentifier vos utilisateurs en utilisant plusieurs protocoles et normes. Cela vous permet d’intégrer PacketFence dans votre environnement sans que vos utlisateurs ne soient obligés de se rappeler plusieurs nom d’utlisateurs et mot de passe . Les sources d’authentification prises en charge sont: • LDAP – – – –

Microsoft Active Directory Novell eDirectory OpenLDAP ... Ou tout serveur compatible LDAP

Projet Fin d’Etudes

20

2014-2015

2.7. CONCLUSION :

chapitre 2

• RADIUS – – – –

Cisco ACS RADIUS (FreeRADIUS, radiateur, etc.) Microsoft NPS NPS ... Ou tout serveur compatible RADIUS Fichier utilisateur local (format htpasswd Apache)

• OAuth2 – – – – –

Facebook Google GitHub LinkedIn Microsoft Live

En outre, PacketFence peut également utiliser sa base de données SQL interne pour authentifier les utilisateurs créés localement.

2.7

Conclusion :

Au terme de notre étude qui portait sur l’étude de la sécurisation d’un réseau par la mise en ouvre d’un NAC, il en ressort que, l’idée du NAC ressemble à une combinaison d’outils de protection déjà connus : authentification renforcée, application de politiques de sécurité par utilisateurs, application et ressource réseau, vérification des mises à jour de sécurité et gestion d’un annuaire. Les solutions de contrôle d’accès réseau permettent aux employés et aux non employés, ainsi qu’aux équipements gérés et non gérés, de partager un accès à la même infrastructure de réseau. Ces systèmes de sécurité par le contrôle des accès au réseau représentent une solution de sécurisation complète des ressources et applications par le contrôle de l’accès de tous les utilisateurs. Pour mener à bien notre projet, nous avons fait une étude détaillée des contrôleurs d’accès réseau et une mise en ouvre d’une solution de sécurité (PacketFence). Nous pouvons donc retenir qu’avec une solution de contrôle d’accès réseau, l’entreprise peut contrôler les connexions distantes d’une part, imposer des règles de sécurité selon les différents réseaux et les rôles des utilisateurs d’autre part, ou bien encore mettre à jour ses postes de travail et les nettoyer en cas d’infection. Enfin, une solution NAC gère les profils par le biais d’un annuaire, le pare-feu se reliant directement aux annuaires.

Projet Fin d’Etudes

21

2014-2015

Chapter 3 Authentification forte Dans ce chapitre on donnera une définition de l’authentification ainsi que ses différents facteurs, ensuite on va se focaliser sur l’authentification forte et enfin on présentera l’outil utilisé par Al Barid Banque pour répondre à ses besoins .

3.1

Définition de l’authentification :

L’authentification est la procédure qui consiste, pour un systeme informatique , à vérifier l’identité d’une personne ou d’un ordinateur afin d’autoriser l’accès de cette entité à des ressources (systemes, reseaux , application . . . )1 . L’authentification permet donc de valider l’authenticité de l’entité en question.

3.2

Les facteurs d’authentification :

L’authentification désigne le processus visant à confirmer qu’un commettant est bien celui qu’il prétend être. Il existe quatre facteurs d’authentification classiques qui peuvent être utilisés pour confirmer l’identité d’un commettant: Facteur mémoriel (ce qu’il sait) • Empreinte : une information qu’il a mémorisée. • Exemples : le nom de sa mère ou un mot de passe. Facteur matériel (ce qu’il possède) • Empreinte : une information contenue dans un objet qu’il utilise. • Exemples : une clé USB, un identifiant sur bande magnétique , un certificat numérique sur une carte à puce . Facteur corporel (ce qu’il montre) • Empreinte : une trace corporelle qu’il peut laisser quelque part. • Exemples : une empreinte digitale , les caractéristiques de sa pupille, sa voix. Facteur réactionnel (ce qu’il fait) duire. 22

• Empreinte : un geste qu’il peut repro-

3.3. DEFINITION DE L’AUTHENTIFICATION FORTE :

chapitre 3

• Exemples : sa signature . D’autres facteurs d’authentification peuvent parfois être utilisés comme les contraintes temporelles ou les capacités de localisation

3.3

Definition de l’authentification forte :

On appelle authentification forte tout système permettant un accès informatique après une double vérification ,donc c’est une procédure d’identification qui requiert la concaténation d’au moins deux facteurs d’authentification .L’objectif est de pallier les faiblesses de l’authentification unique par mot de passe. En effet, les mots de passe peuvent être volés, forcés et posent un problème de mémorisation à l’utilisateur et de renouvellement à l’entreprise. L’authentification forte s’appuie sur d’autres concepts que celui des mots de passe. Le premier d’entre eux étant celui du jeton unique. Le principe est simple : il s’agit d’un algorithme de génération de mots de passe unique, à durée de vie courte, qui se synchronise avec une application cliente installée sur le poste de travail. Cet algorithme peut être installé sur une calculette se contentant alors d’afficher le code généré, sur une clé USB, qu’il faudra brancher à l’appareil, ou sur une carte à puces qui transmet le code par contact avec un appareil de lecture. Le mot de passe ainsi généré n’est valable que pour une période de temps de 1 à 2 minutes. Il existe également des cartes reposant sur le principe du jeton unique mais sans code à saisir pour l’utilisateur. La transmission de ce code s’effectue alors par ondes sonores, mais nécessite la mise en place d’un récepteur. Enfin, le principe du jeton est aussi appliqué sur des cartes plastiques imprimés. Sur ces cartes figurent une série de numéro et l’utilisateur découvre leur ordre d’entrée et la composition du code unique lors de la phase d’authentification. Le logiciel client se charge de lui indiquer la ligne et la colonne du chiffre à saisir pour s’authentifier. Deuxième solution d’authentification forte mise en place, cette fois-ci pour sécuriser les accès aux services Internet : les certificats électroniques, qui appliquent en partie le principe du jeton sur le Web. Les certificats électroniques sont des fichiers attestant de l’identité de l’auteur en liant par exemple son mot de passe à des renseignements personnels (date de naissance, numéro de sécurité sociale). Le certificat électronique envoie ensuite ces informations à un serveur central qui vérifie que ce fichier est bien représenté dans sa base de données avant de lui autoriser l’accès aux services Web. Contrairement au principe du jeton, les certificats électroniques disposent d’une durée de vie plus longue, en moyenne de quelques semaines mais qui peut s’étaler sur plusieurs années. Autre différence, le jeton n’est pas émis par une carte que possède l’utilisateur mais par le serveur, après saisie des données personnelles de l’utilisateur. Aussi, si l’utilisateur perd son certificat électronique, il peut en redemander un autre et s’authentifier rapidement. Il existe toutefois deux limites aux certificats électroniques. D’abord, cela implique un cadre juridique strict de gestion des identifiants utilisateurs et il paraît délicat Projet Fin d’Etudes

23

2014-2015

chapitre 3

3.3. DEFINITION DE L’AUTHENTIFICATION FORTE :

d’imposer à l’utilisateur une base de données centrale où repose l’ensemble de ses certificats traçant ses connexions. D’autre part, le certificat électronique peut être intercepté, volé, répliqué et utilisé en accédant au poste de l’internaute, ce qui ne garantit donc pas que le porteur du certificat soit bien son créateur. Sans doute la méthode la plus prometteuse, mais aussi la plus délicate à mettre en ouvre, la biométrie appartient à la catégorie des technologies d’authentification forte. Elle repose sur des systèmes de capture d’images couplés à une base de données centrale stockant les informations personnelles. On distingue 4 catégories d’applications à la biométrie : la reconnaissance digitale, la reconnaissance d’iris, la reconnaissance faciale et la reconnaissance vocale. L’avantage de ces méthodes est clair : l’utilisateur a toujours sur lui ses "codes d’authentification" et ne peut les perdre ou les oublier... Il existe toutefois - outre son coût - plusieurs limites à la biométrie. Tout d’abord l’aspect juridique, les droits des personnes étant fichés, leurs caractéristiques morphologiques aussi. Ces bases de données sont à rapprocher de celles utilisées par la police et donc soumises à des lois très strictes. D’autre part, les données peuvent être falsifiées dans le cas de la reconnaissance digitale ou de la reconnaissance vocale. Enfin, la biométrie pose le problème de la qualité de l’authentification. Ces méthodes ne sont en effet pas toujours fiables à 100%, ce qui empêche des utilisateurs de bonne foi d’accéder à leur système. L’un des axes de recherche de la biométrie porte donc sur la multimodalité, c’est-à-dire la combinaison de plusieurs méthodes d’identification par voie biométrique Les solutions d’authentification forte s’appuient sur de nombreux protocoles de sécurité, de manière à acheminer l’information personnelle de l’utilisateur de la manière la plus sure jusqu’au serveur d’authentification. Sur le Web, le protocole HTTPS se base sur le procédé de cryptographie SSL (Secure Sockets Layers) qui s’assure que les paquets échangés entre le serveur et le client ne sont pas lisibles de l’extérieur. Dans les réseaux étendus d’entreprise, cette fonction est assumée par le protocole IPSec, géré par la majorité des réseaux privés virtuels (VPN). Dans les réseaux internes, il existe différentes couches de sécurité. Sur les réseaux mobiles, le protocole 802.11i remplit ce rôle de cryptage tandis que les réseaux fixes utilisent depuis longtemps le 802.10. Mais derrière l’ensemble de ces protocoles se trouve l’algorithme de cryptage AES (Advanced Encryption Standard), créé en 1998 et capable de générer des clés uniques de 128 à 256 bits. Ce système offre des milliards de possibilités de code, ce qui le rend presque insensible à des techniques de déchiffrage par la force (en essayant de multiples combinaisons). Parallèlement à AES, il existe le protocole de cryptage PGP, fréquemment utilisé pour chiffrer le contenu des e-mails envoyés sur Internet. Cet algorithme est mis à disposition de tous en libre accès depuis 1991 et a donné lieu à de nombreuses implémentations depuis. L’authentification est traitée dans le chapitre 11 de la norme ISO/CEI 27001 qui est le contrôle d’accès, la norme souligne qu’il faut utiliser une authentification à deux facteurs pour les ressources critiques de l’entreprise, ces ressources seront identifié

Projet Fin d’Etudes

24

2014-2015

3.4. LES FACTEURS D’AUTHENTIFICATION

chapitre 3

lors de la présentation de l’existant dans le chapitre suivant.La certification ISO 27001 est une certification accessible à tous, elle fait une démonstration universelle et formelle, de sa volonté de s’améliorer en sécurité et de respecter un minimum en sécurité, elle offre une description pratique et détaillée de la mise en œuvre des objectifs et mesures de sécurité. La norme fournit des indicateurs clairs et fiables ainsi que des éléments de pilotage financier aux directions générales ; et permet entre autre d’identifier plus efficacement les risques et les coûts associés,

3.4 3.4.1

les facteurs d’authentification OTP

(One Time Password) : technologie basée sur l’utilisation d’un secret partagé qui permet de s’authentifier avec un mot de passe à usage unique.

3.4.2

PKI

PKI (Public Key Infrastructure) : Infrastructure à clés publiques (ICP) ou infrastructure de Gestion de Clefs (IGC), ensemble de ressources et de procédures destinées à gérer le cycle de vie des certificats numériques. Certificat Numérique : Carte d’identité numérique dont l’objet est d’identifier une ressource du système d’information, une autorité de certification fait foi de tiers de confiance et atteste du lien entre l’identité numérique et la ressource.

3.4.3

Code NIP

: suite de chiffres destinée à authentifier le propriétaire d’une carte de GAB, d’une carte de paiement, d’une carte à puce ou d’une carte SIM. Le NIP ne doit être composé que de chiffres, quatre ou plus,

3.4.4

Biométrie

identification des personnes en fonction de caractéristiques biologiques telles que les empreintes digitales, palmaires, traits du visage, etc.

3.4.5

SSO

L’authentification unique (ou identification unique ; en anglais Single Sign-On :SSO ) est une méthode permettant à un utilisateur d’accéder à plusieurs applications informatiques (ou sites web sécurisés) en ne procédant qu’à une seule authentification.

3.4.6

ACS (Access Control System ) et l’authentification forte

La version actuelle à ABB sous forme d’ACS « appliance » hormis l’usage du mot de passe pour s’authentifier,ACS supporte l’authentification par certificats électroniques pour un usage avec les protocoles d’authentifications (EAP-TLS, EAP- FAST, PEAP) et pour accéder à l’interface web de l’ACS en utilisant le protocole https. Pour cela une confiance mutuelle exige que l’ACS a un certificat installé qui peut Projet Fin d’Etudes

25

2014-2015

3.5. ETUDE DE L’EXISTANT :

chapitre 3

être vérifié par l’utilisateur, ce certificat serveur peut être fournit par une autorité de certification ou un certificat auto-signé. Avec une bonne gestion l’utilisation des certificats peut être plus sure que le mot de passe. En ce qui concerne l’intégration de l’authentification forte il faut généralement passer par un ACS tournant sur un serveur Windows pour pouvoir l’implémenté avec d’autres solutions

3.4.7

Authentification par Active Directory :

L’Active Directory est un système d’exploitation réseau de «Microsoft», développé en dessus du système d’exploitation Windows . Ce dernier permet aux administrateurs de gérer d’une manière efficace les informations d’une entreprise en s’appuyant sur un dépôt central de données qui peut être globalement distribué. Les informations sur les utilisateurs, les groupes, les machines, les applications et les services sont ajoutés à l’AD, elles sont stockées sous formes d’objets, c’est-à-dire un ensemble d’attributs représentant un élément concret. Les objets sont organisés hiérarchiquement selon un schéma (lui-même stocké dans l’annuaire) définissant les attributs et l’organisation des objets. La base de données qui va abriter ces objets est stockée dans un fichier NTDS.DIT dans le contrôleur de domaine. L’interrogation et la modification du service d’annuaire se fait par le protocole LDAP. AD utilise le protocole de sécurité Kerberos comme mécanisme d’authentification .

3.5

Etude de l’existant :

Dans le but de bien sécuriser l’accès à son Datacenter Barid bank a investi dans les nouvelles technologies par suite il utilise la solution NeXuS pour l’authentification forte . Cette technologie offre aux utilisateurs et partenaires de Barid bank , des solutions d’accès distants pour accéder de façon sécurisée aux applications critiques, depuis tout type de dispositif et depuis n’importe quel lieu

3.5.1

NeXus Hybrid Access Gateway :

NeXus Hybrid Access Gateway est une solution qui nous permet de gérer tout type d’accès en toute sécurité et avec la simplicité d’une application virtuelle, quels que soient les équipements. Pas de logiciel à installer ni de système d’exploitation à maintenir : installez simplement l’appliance par le Cloud . NeXus Hybrid Access Gateway offre une remarquable solution d’accès distant qui assure la disponibilité des applications sur site et sur le cloud sur n’importe quel périphérique ou plate forme. La solution est également parfaitement adaptée à des scénarios de type BYOD (Bring Your Own Device). L’utilisation des technologies HTML5 et des websockets permet la virtualisation des applications, les rendant accessibles à partir de n’importe quels périphérique ou plateforme.Les bénéfices qu’ON pourrait tirer grâce à l’utlisation de cette solution : Projet Fin d’Etudes

26

2014-2015

3.5. ETUDE DE L’EXISTANT :

chapitre 3

• Une plus grande sécurité . • Une utilisation simplifiée . • Une administration minimale. Parmi les avantages de Nexus Hybrid Authentification polyvalente et adaptée en fonction des risques : Une authentification solide à plusieurs facteurs protège contre l’hameçonnage, le cassage de mot de passe, les enregistreurs de frappe et autres méthodes d’usurpation d’identité. La solution NeeXus Hybrid Access Gateway offre un grand nombre de méthode d’authentification avec différents degrés au sein d’une seule solution polyvalente et intégrée. Les organisations peuvent autonomiser leurs utilisateurs en leur fournissant une technolo gie d’authentification conviviale, facile à gérer, économique et sûre. L’étendue des différentes méthodes d’authentification permet une stratégie d’authentification polyvalente. Sécurité des applications mobiles : La solution NeXus propose également une authentification solide et des identités électroniques sécurisées pour les applications mobiles grâce à la prise en charge des normes OAuth 2.0. Le système d’autorisation OAuth 2.0 fournit aux applications (sur le web ou mobiles) un accès délégué et limité à des services HTTP et API. Politiques d’accès: La fonction SSL VPN / reverse proxy sécurise le canal entre l’utilisateur et l’application. D’autre part le serveur d’authentification forte embarqué et la fonction de Single Sign On (SSO) apportent un niveau de sécurité et une convivialité optimale. Un portail adaptatif Le serveur web intégré améliore la facilité d’utilisation et la sécurité. Le portail s’adapte à tout type de dispositifs pour un affichage optimal (écrans tactiles, tablettes, smartphones). Les utilisateurs peuvent organiser leurs favoris et les politiques d’accès garantissent que seuls les utilisateurs autorisés accèdent à leurs applications et données. Toutes les applications web sont accessibles. HTML5 et les websockets permettent également l’utilisation d’applications non web virtualisées dans les browsers ainsi que la prise en charge des bureaux à distance.

Projet Fin d’Etudes

27

2014-2015

3.5. ETUDE DE L’EXISTANT :

chapitre 3

Figure 3.1: Architecture Nexus -Single Sign On L’authentification unique est une fonction très importante. Elle réduit considérablement l’administration des mots de passe et simplifie l’expérience utilisateur qui s’authentifie une seule fois. Le support de SAML ( Security Assertion Markup Language ) permet de sécuriser les identités et d’implémenter la fédération d’identité vers des applications Cloud privées ou publiques. Les fonctions SAML supportées sont : • SAML identité et fournisseur de services . • Les Profils de bases. • Navigateur Web SSO Profil Avec redirection. -L’Autorisations et Politiques des Accès Tous les accès au système sont basés sur des politiques dyna miques pour une sécurité optimale. La gestion des autorisations est très granulaire et peut s’appliquer sur de nombreux critères (type d’accès, type d’authentification, plage horaire, etc.). L’Authentification unique (SSO) est un fondement dans le système : toutes les autorisations d’accès sont faites par le moteur d’autorisation à l’aide de contrôles d’accès basés sur les rôles et les attributs. -L’Administration En tant qu’appliance virtuelle, NeXus Hybrid Access Gateway bénéficie d’une administration simplifiée en facilitant les dé ploiements, les Projet Fin d’Etudes

28

2014-2015

3.5. ETUDE DE L’EXISTANT :

chapitre 3

mises à niveau et la maintenance, le tout grâce à des processus automatisés paramétrables dans une interface web. -L’Audit Lors d’un audit, toutes les données sont à votre disposition. La fonction d’audit consolidée vous révèle qui a fait quoi, quand, où et comment, apportant une aide précieuse pour les responsables de la conformité. Il est possible d’effectuer un reporting en temps réel ou historique sous différents formats, tels que : graphiques par secteurs, linéaires, 3D et histogrammes. Toutes les données sont exportables en format texte pour qu’elles puissent être facilement retraitées, par exemple dans un tableur. -Données des utilisateurs Les données liées aux utilisateurs de NeXus Hybrid Access Gateway contiennent des informations cruciales telles que les paramétrages des méthodes d’authentification, les credentials SSO et les attributs. Ces objets résident par défaut dans un annuaire LDAP intégré. Il est bien évidement possible de s’appuyer sur un annuaire tiers, tel que Microsoft Active Directory (AD), Novell eDirectory, SUN, OpenLDAP. 3.5.1.1

-Simplicité pour les utilisateurs

Ce système simplifie la vie des utilisateurs finaux car tout est géré au moyen d’un navigateur. Du fait qu’il est indépendant des plateformes, aucune installation sur les postes clients n’est requise. Le portail web adaptif détecte l’appareil favori de chaque utilisateur : chacun obtient la même expérience, avec une optimisation pour les caractéristiques spécifiques de certains appareils, par exemple les écrans tactiles et les tablettes. 3.5.1.2

-Plus de sécurité, moins d’administration

« Security Through Simplicity » : ce thème est un objectif majeur chez NeXus. Nous pensons que les solutions de sécurité trop complexes ne sont pas toujours les plus sécurisantes. Hybrid Access Gateway simplifie l’administration tout en augmentant la flexibilité. Vous constaterez les avantages au quotidien. Par exemple, pas besoin d’administrer les appareils mobiles, car rien n’est installé sur les appareils des utilisateurs. La gestion des groupes d’utilisateurs s’appuie le plus souvent sur les référentiels déjà en place. Toutes les communications sont chiffrées pour assurer une sécurité optimale, et l’authentification forte garantie que seuls les utilisateurs autorisés peuvent se connecter et accéder au portail. 3.5.1.3

La solution hybride :

Le fort potentiel des applications déployées dans le Cloud crée un nouveau type d’architecture pour les entreprises dites à « connexions hybrides ». La capacité de placer des applications dans le cloud et dans les locaux de l’entreprise facilite leur utilisation tout en supprimant les contraintes liées à l’administration des serveurs. Projet Fin d’Etudes

29

2014-2015

3.6. AVANTAGES

chapitre 3

La solution Hybride assure également des accès sécurisés aux applications, car les identités et l’authentification des utilisateurs sont transférées entre des domaines de sécurité.

3.6

Avantages

NeXus Hybrid Access est une solution qui allie entre la simplicité et l’efficacité parmi ses avantages on trouve : • Une vue unifiée pour l’utilisateur final quant aux applications autorisées • Des étapes de configuration simples • Une protection instantanée • Toutes les applications web traditionnelles demeurent accessibles

3.7

Fonctionnalités

Les fonctionnalités de cette solution sont : • Authentification forte (plusieurs méthodes : authentification à 1/2 facteurs, authentification tièrces parties, ...) • Interfaces annuaires Microsoft Active Directory (AD), Novell eDirectory, SUN, OpenLDAP • SSO ( Single Sign On)

3.8

Conclusion :

A travers ce chapitre nous avons montré l’importance de l’authentification forte au sein d’une entreprise et nous avons présenté la solution utilisée par AL BARID BANK . En adaptant le modèle AAA (Authentification , Autorisation, tracabilité) , le chapitre suivant présentera le deuxième point de ce modèle qui est l’Autorisation.

Projet Fin d’Etudes

30

2014-2015

Chapter 4 Autorisation Ce chapitre est consacré à la définition de la politique de sécurité et la présentation des différents modèles de contrôle d’accès ainsi que leurs limites et avantages. Après cette étude , on a choisi le modèle O-RBAC pour réaliser une simulation sur des profils virtuels .

4.1

Définition de la politique d’accès :

Le contrôle d’accès : consiste à vérifier si un sujet (utilisateur, processus, etc.) demandant d’accéder à une ressource (fichier, mémoire, etc.) possède suffisamment le droit pour le faire. Le contrôle d’accès est basé sur une politique de contrôle d’accès qui est spécialisée pour la gestion des permission.La politique de contrôle d’accès est structurée selon un modèle qui est responsable de la prise de décision (accord ou refus) d’une demande d’accès. Les modèles traditionnels de contrôle d’accès sont : le contrôle d’accès par mandat (Mandatory Access Control -MAC ), le contrôle d’accès discrétionnaire (Discretionary Access Control - DAC ). MAC est un mécanisme de contrôle d’accès basé sur l’étiquetage (exemple : Top Secret , Secret , Unclassified ) des différentes entités (sujets et objets) du système. DAC est un mécanisme décentralisé basé sur l’utilisateur dans lequel le créateur d’une donnée possède la pleine discrétion de définir les autorisations. En 2003, il avait l’apparition du modèle de contrôle d’accès basés sur les rôles (Rôle-Based Access Control-RBAC) .une politique RBAC est, d’une part un ensemble d’affectation des utilisateurs à des rôles et d’autre part un ensemble d’attributions des permissions à ces des rôles et par la suite, une demande d’accès d’un sujet à une ressource est accordée s’il joue un rôle auquel est associé ce privilège. Plusieurs modèles se sont inspirés de RBAC pour, soit organiser des politiques au moyen de concepts supplémentaires (par exemple, équipe, tâche, organisation) pour améliorer leur pouvoir expressif et leur flexibilité: le contrôle d’accès basé sur l’équipe (Team-Based Access Control - TMAC ), contrôle d’accès basé sur des tâches (Task-based Authorization Controls - TBAC ) et le contrôle d’accès basé sur l’organisationv(Organisation-Based Access Control - ). Soit de l’étendre en ajoutant par exemple, des contraintes temporelles, spatiales ou 31

4.2. POLITIQUE DE SÉCURITÉ :

chapitre 4

géographiques).

4.2 4.2.1

Politique de sécurité : Définition :

Une politique de sécurité est « l’ensemble des lois, règles et pratiques qui régissent la façon dont l’information sensible et les autres ressources sont gérées, protégées et distribuées à l’intérieur d’un système spécifique» . Une politique de sécurité se construit en définissant les propriétés à satisfaire par le système, et en établissant un schéma d’autorisation qui doit avoir, en principe, une politique cohérente. La politique de sécurité prend en compte les aspects organisationnels et techniques qui définissent comment les utilisateurs peuvent manipuler l’information. Les propriétés de sécurité peuvent être définies en fonction de la confidentialité, l’intégrité et la disponibilité . Le développement d’une politique de sécurité peut être réalisé dans trois directions distinctes, à savoir : physique, administrative et logique. • Physique : Cette politique précise un ensemble de procédures et de moyens qui protègent les locaux et les biens contre des risques majeurs (incendie, inondation, etc.) et contrôlent les accès physiques aux matériels informatiques et de communication (gardiens, codes, badges, ...). • Administrative : cette politique définit un ensemble de procédures et moyens qui traite tout ce qui ressort de la sécurité d’un point de vue organisationnel au sein de l’entreprise. La structure de l’organigramme ainsi que la répartition des tâches (séparation des environnements de développement, d’industrialisation et de production des applicatifs) en font partie. Les propriétés de sécurité recherchées visent, par exemple, à limiter les cumuls ou les délégations abusives de pouvoir, ou à garantir une séparation des pouvoirs.

• Logique : C’est la politique de sécurité qui fait référence à la gestion du contrôle d’accès logique, lequel repose sur un triple service : . Service Identification : Identifier de façon unique un sujet grâce à un identifiant. . Service d’authentification : S’assurer que l’identité du sujet est bien celle qu’il prétend être. .Service d’autorisation : Déterminer si le sujet authentifié peut effectuer l’action désirée sur l’objet spécifié. Le contrôle d’accès spécifie qui peut accéder à quoi et dans quelle circonstance, l’autorisation consiste à administrer et à examiner les droits d’accès, en fonction Projet Fin d’Etudes

32

2014-2015

4.2. POLITIQUE DE SÉCURITÉ :

chapitre 4

des spécifications de la politique de sécurité, ces spécifications sont généralement des : 1. Permission : Sujet a le droit de lire Objet. 2. Interdiction Sujet n’a pas le droit d’écrire dans Objet. 3. Obligation Sujet doit conserver Objet.

4.2.2

Les politiques et les modèles de contrôle d’accès :

Le modèle de contrôle d’accès est matérialisé par un ensemble de mécanismes. Il peut être défini comme un formalisme, souvent mathématique, qui consiste à vérifier si un sujet (utilisateur, processus . . . ) demandant d’accéder à un objet (ressource, autre sujet...) possède les droits nécessaires pour le faire. Le contrôle d’accès permet donc de limiter l’accès des sujets aux objets, il a pour but principal de protéger les données et les ressources du système contre la révélation et la modification non autorisées tout en assurant leur disponibilité aux utilisateurs légitimes. Le système de contrôle d’accès doit être capable de contrôler tout accès au système et à ses ressources en assurant les accès autorisés et seulement ceux-ci. Les schémas d’autorisation des politiques de sécurité sont classés en trois grandes familles: • Les politiques discrétionnaires (Discretionary Access Control - DAC) • Les politiques obligatoires (Mandatory Acces control-MAC) • Les politiques basées sur les rôles (Role-Based Access Control - RBAC) Généralement, on adapte à des organisations particulières d’autres politiques comme: TBAC (Team-Based Access Control Model) ,TMAC (Task-Based Access Control) , HRU (Harrison, Ruzzo and Ullmann) , BLP (Bell et Lapadula) et ORBAC (Organization Based Access Control) . Normalement, il faut construire une politique de sécurité de telle sorte qu’aucune séquence valide d’applications des règles (du schéma d’autorisation) ne puisse amener le système dans un état tel qu’un objectif de sécurité soit violé, en partant d’un état initial sûr (on parle de politique de sécurité cohérente). Ceci suppose l’utilisation d’une méthode formelle de construction des règles du schéma d’autorisation, à partir d’une spécification formelle des objectifs de sécurité. Matrice de contrôle d’accès : La matrice de contrôle d’accès (introduite par Butler Lampson en 1971 ) est une matrice à deux dimensions représentant, pour chaque sujet, les actions qu’il peut effectuer sur chaque objet. Il s’agit donc d’une représentation naturelle des relations entre les sujets et les objets. Les sujets sont les lignes et les objets (ou les sujets) sont les colonnes de la matrice et chaque cellule (se trouvant sur la ligne i et sur la colonne j) correspond à un ensemble de droits d’accès qui constituent l’ensemble des opérations que le sujet (i) peut réaliser sur Projet Fin d’Etudes

33

2014-2015

4.3. LES MODÈLES DE SÉCURITÉ INFORMATIQUE :

chapitre 4

l’objet (j). La construction d’une telle matrice nécessite l’identification et le contrôle des objets à protéger, des sujets qui demandent accès aux objets, et des actions qui peuvent être exécutées sur les objets. Elle est structurée sous forme d’une machine à états, où le triplet (S, O, M) représente chaque état, avec : S est un ensemble des sujets (dans notre cas S= s1,..,sM) O est un ensemble d’objets (dans notre cas O= o1,..,oN) M une matrice de contrôle d’accès (dans notre cas M (si, oj)=Lecture) Le modèle de Lampson associé aux DAC, ne permet pas d’exprimer directement des interdictions ou des obligations, aussi s’ajoute-t-il la complexité de la mise à jour de la matrice d’accès.

Figure 4.1: Matrice de contrôle d’accès : Théoriquement, il y a autant de colonnes que de nombre d’objets (et de sujets) du système et autant de lignes que de nombre de sujets du système, cela rend notre matrice impraticable, car à chaque fois qu’un sujet est introduit (ou un objet est créé) dans le système, tous les droits d’accès accordés devront être enregistrés. Par conséquent, la mise à jour d’une politique de sécurité exprimée par ce modèle est fastidieuse, d’où l’utilisation de deux vecteurs:

4.3 4.3.1

Les modèles de sécurité informatique : Le contrôle d’accès discrétionnaire (DAC) :

Le contrôle d’accès discrétionnaire (Discretionary Access Control - DAC)[14] permet à un sujet d’attribuer des permissions à d’autres sujets. Ce contrôle d’accès est Projet Fin d’Etudes

34

2014-2015

4.3. LES MODÈLES DE SÉCURITÉ INFORMATIQUE :

chapitre 4

flexible mais il peut générer des erreurs. Les manipulations des droits d’accès à chaque objet restent à l’entière discrétion du sujet qui en est le responsable. Dans un tel modèle tout sujet ayant créé un objet en est le propriétaire. Ce type de mécanisme est utilisé dans les systèmes d’exploitation traditionnels : Unix, Linux, Windows et Macintosh, il est implémenté généralement avec des listes de contrôle d’accès (Access Control Lists - ACL) Les modèles DAC que nous présentons dans cette section sont ceux qui se basent sur la matrice de contrôle d’accès: le modèle de Lampson et le modèle de Harrison Ruzzo Ullman. A partir du début des années 70, plusieurs modèles de sécurité se sont succédés : I-BAC, R-BAC, V-BAC, T-MAC et plus récemment Or-BAC. Nous allons évoquer brièvement ces modèles de sécurité mais nous marquerons un temps d’arrêt sur le modèle Or-BAC que nous utiliserons dans la suite.

4.3.2

Le modèle I-BAC (Identity Based Access Control )

I-BAC Premier modèle de contrôle d’accès proposé dans la littérature, ce modèle introduit les concepts fondamentaux de sujet, d’action et d’objet : • le sujet est l’entité active du SI (utilisateur, ordinateur, processus, programme,...) ; • l’objet est l’entité passive du SI (fichier, base de donnée, ordinateur, programme,...) ; • l’action désigne l’effet recherché lorsqu’un sujet accède à un objet (lire, écrire, modifier,...). L’objectif du modèle I-BAC est de contrôler tout accès direct des sujets aux objets via l’utilisation des actions. Ce contrôle est basé sur l’identité du sujet et l’identificateur de l’objet, d’où le nom du modèle I-BAC. Le modèle I-BAC présente cependant des limites. La politique d’autorisation devient complexe à exprimer et administrer. Il est en effet nécessaire d’énumérer les autorisations pour chaque sujet, action et objet. En particulier, lorsqu’un nouveau sujet ou objet est créé, il est nécessaire de mettre à jour la politique d’autorisation pour définir les nouvelles permissions associées à ce sujet ou objet.

4.3.3

Le modèle R-BAC (Role Based Access Control)

Le modèle RBAC (Role Based Access Control) propose de structurer l’expression de la politique d’autorisation autour du concept de rôle. Un rôle est un concept organisationnel : des rôles sont affectés aux utilisateurs conformément à la fonction attribuée à ces utilisateurs dans l’organisation. Le principe de base du modèle RBAC est de considérer que les autorisations sont directement associées aux rôles. Dans R-BAC, les rôles reçoivent donc des autorisations de réaliser des actions sur des objets. Un autre concept introduit par le modèle R-BAC est celui de session. Pour pouvoir Projet Fin d’Etudes

35

2014-2015

4.3. LES MODÈLES DE SÉCURITÉ INFORMATIQUE :

chapitre 4

réaliser une action sur un objet, un utilisateur doit d’abord créer une session et, dans cette session, activer un rôle qui a reçu l’autorisation de réaliser cette action sur cet objet. Si un tel rôle existe et si cet utilisateur a été affecté à ce rôle, alors cet utilisateur aura la permission de réaliser cette action sur cet objet une fois ce rôle activé. Lorsqu’un nouveau sujet est créé dans le SI, il suffit d’affecter des rôles au sujet pour que ce sujet puisse accéder au SI conformément aux permissions accordées à cet ensemble de rôles. Comparé au modèle I-BAC, la gestion de la politique d’autorisation s’en trouve simplifiée puisqu’il n’est plus nécessaire de mettre à jour cette politique chaque fois qu’un nouveau sujet est créé. Mais comme I-BAC, le modèle R-BAC ne considère que des autorisations positives (permissions) et fait donc l’hypothèse que la politique est fermée. Bien plus, dans les modèles I-BAC et R-BAC, les actions correspondent généralement à des commandes élémentaires, comme la lecture du contenu d’un objet ou l’écriture dans un objet. Dans les applications récentes, le besoin apparaît de contrôler la réalisation d’actions composites, appelées tâches ou activités. Par exemple, dans une agence de voyage, la tâche d’achat d’un billet d’avion se décompose en plusieurs actions plus élémentaires telles que la réservation du billet, le paiement du billet et l’édition d’une facture.

4.3.4

Le modèle T-BAC(Task Based Acces Control)

Le modèle T-BAC fut le premier modèle à introduire le concept de tâche. D’autres modèles ont ensuite été développés pour contrôler l’exécution des activités dans un workflow. En particulier, l’utilisateur ne doit obtenir une permission que lorsque c’est nécessaire pour poursuivre l’exécution de l’activité considérée ("just in time" permission). Ainsi, dans l’exemple d’achat d’un billet d’avion, la permission d’éditer une facture ne doit être activée qu’après la réservation et l’achat du billet. Il est parfaitement possible de combiner les concepts de rôle et de tâche pour spécifier une politique d’autorisation et obtenir ainsi un modèle que l’on peut appeler TR-BAC (Task and Role Based Access Control). Dans ce cas, les permissions affectées aux rôles portent sur la réalisation des tâches. Diverses contraintes peuvent être spécifiées pour par exemple spécifier qu’un même sujet doit intervenir dans certaines actions nécessaires à la réalisation de la tâche (éventuellement avec des rôles différents). Les modèles R-BAC et T-BAC ont respectivement introduit les concepts de rôle et de tâche pour structurer les sujets et les actions. Pour faciliter l’expression et la gestion d’une politique d’autorisation, nous avons également besoin d’un concept pour structurer les objets. Parmi les modèles de contrôle d’accès proposant une telle structuration des objets, on peut citer le modèle de sécurité proposé par SQL pour les bases de données relationnelles. L’expression d’une politique de sécurité en SQL repose sur le concept de vue. Ce type de modèle de contrôle d’accès basé sur les vues est appelé V-BAC

Projet Fin d’Etudes

36

2014-2015

chapitre 4

4.3. LES MODÈLES DE SÉCURITÉ INFORMATIQUE :

4.3.5

Le modèle T-MAC(Team Based Acces Control)

Le modèle T-MAC introduit la notion d’équipe. Dans T-MAC, des autorisations sont associées aux rôles ainsi qu’aux équipes. Les autorisations que possède un sujet résultent de la combinaison des autorisations associées aux rôles exercés par le sujet et des autorisations associées à l’équipe à laquelle est affecté le sujet. Plusieurs combinaisons (par exemple, l’union des autorisations) sont envisagées. En fait, le modèle T-MAC est incorrect car il introduit deux relations binaires : rôle-autorisation et équipe-autorisation. Si l’on introduit la notion d’équipe, il est en fait nécessaire de considérer une relation ternaire équipe-rôle-autorisation pour spécifier que les autorisations dépendent non seulement du rôle mais aussi de l’équipe dans laquelle est exercé ce rôle. A l’aide d’une telle relation ternaire, on pourra ainsi facilement spécifier que les autorisations du rôle médecin changent suivant qu’il s’agit d’un médecin dans une équipe de garde ou d’un médecin dans une équipe d’urgence. Cette imperfection du modèle T-MAC a été corrigée dans le modèle Or-BAC, que nous allons présenter dans les sections suivantes.

4.3.6

Le modèle OR-BAC (Organization Based Access Control)

4.3.6.1

Les objectifs et avantages d’Or-BAC :

L’objectif d’Or-BAC est de permettre la modélisation d’une variété de politiques de sécurité basées sur le contexte de l’organisation. Pour arriver à ce but, et afin de réduire la complexité de gestion des droits d’accès, le modèle Or-BAC repose sur quatre grands principes : • L’organisation est l’entité centrale du modèle. • Il y a deux niveaux d’abstraction : – Un niveau concret : sujet, action, objet. – Un niveau abstrait : rôle, activité, vue. • La possibilité d’exprimer des permissions, des interdictions, et des obligations • La possibilité d’exprimer les contextes. Ainsi, en plus d’avoir une politique de sécurité indépendante de son implémentation, Or-BAC a d’autres avantages. Il permet d’exprimer aussi bien des permissions, que des interdictions et des obligations. Il prend en compte les contextes, les hiérarchies et la délégation. L’introduction d’un niveau permet aussi la structuration des entités comme on le voit sur le schéma suivant:

Projet Fin d’Etudes

37

2014-2015

4.3. LES MODÈLES DE SÉCURITÉ INFORMATIQUE :

chapitre 4

Figure 4.2: Schèma de ORBAC Ainsi dans Or-BAC, un rôle est un ensemble de sujets sur lesquels sont appliquées les mêmes règles de sécurité. Identiquement, une activité est un ensemble d’actions sur lesquels sont appliquées les mêmes règles de sécurité et une vue est un ensemble d’objets sur lesquels sont appliquées les mêmes règles de sécurité 4.3.6.2

Les interactions d’Or-BAC :

Sur le schéma suivant, on peut apercevoir les interactions existantes dans Or-BAC. Afin de ne pas surcharger celui-ci l’interaction entre le contexte et les entités concrètes n’est pas représentée

Projet Fin d’Etudes

38

2014-2015

4.3. LES MODÈLES DE SÉCURITÉ INFORMATIQUE :

chapitre 4

Figure 4.3: Interaction d’ORBAC 4.3.6.3

La notion de contexte :

On voit apparaître sur ce schéma des interactions d’une entité qui n’apparait pas dans les autres modèles de contrôle d’accès : le contexte. Celui-ci est défini pour une organisation, un sujet, une action, des objets donnés. Les contextes permettent d’exprimer des permissions ou des interdictions dans certaines circonstances (urgence à l’hôpital, heures de travail dans une entreprise,...). Il est facile d’imaginer que dans un contexte d’urgence, on désirera qu’un infirmier puisse accéder au dossier d’un patient sans avoir besoin d’appeler l’administrateur afin que celui-ci lui donne les droits (peut-être trop tard). Cette possibilité de nuancer les autorisations n’est pas offerte par les autres modèles, alors que dans de nombreuses organisations (hôpital, entreprise,...) il existe un réel besoin de ne donner des droits que dans des circonstances précises

Projet Fin d’Etudes

39

2014-2015

chapitre 4

4.3. LES MODÈLES DE SÉCURITÉ INFORMATIQUE :

Figure 4.4: Hiérarchique du modèle ORBAC Pour le modèle Or-BAC, on a regroupés les différents contextes par type (comme sur le schéma ci-dessus) : contexte temporel : Ce sont des contextes régissant la durée de validité des privilèges . contexte spatial : Il peut être lié à l’appartenance à un réseau, ou la position géographique, ou à toute autre situation spatiale . contexte déclaré par l’utilisateur : ce type de contexte est activé, par exemple, par le médecin en cas d’urgence, ou pour signaler que l’on effectue un audit. Dans ces cas exceptionnels, des permissions peuvent être données alors qu’elles seraient interdites dans un cas normal. L’utilisateur qui déclare le contexte est obligé en contrepartie de faire un compte-rendu des opérations effectuées et peut être des raisons qui l’ont motivé à déclarer ce contexte . contexte prérequis : Leur utilisation permet de contraindre les sujets concernés par les permissions ou les interdictions dépendant de ces contextes et qui vient réduire ou étendre les droits d’accès hérités du rôle associé ; contexte provisionnel : Ce contexte permet de donner des privilèges en fonction de l’historique. Par exemple, le contexte "accès limités à 2 fois" regarde si le document, objet de l’action, a été accédé au moins 2 fois.

Projet Fin d’Etudes

40

2014-2015

4.3. LES MODÈLES DE SÉCURITÉ INFORMATIQUE :

chapitre 4

A noter que dans une modélisation Or-BAC, on définit toujours un contexte par défaut. 4.3.6.4

La notion de hiérarchie :

Afin de gérer plus facilement des sous-organisations, en automatisant la dérivation des permissions, Or-BAC permet de définir des hiérarchies sur les rôles, les activités, les vues et les contextes. On a ainsi l’héritage des permissions et des interdictions en descendant dans la hiérarchie des rôles, des activités, des vues et des contextes. Tout comme dans R-BAC, l’héritage permet de simplifier la tâche de l’administrateur en automatisant partiellement l’attribution des privilèges. Comme dans R-BAC, il existe deux façons de définir la hiérarchie de l’héritage : • La première vision pour définir la hiérarchie est la hiérarchie organisationnelle. Le directeur est hiérarchiquement supérieur à un ingénieur. Dans certains cas, il peut donc hériter de toutes les permissions de ce rôle (pour vérifier le travail de celui-ci). On dit alors que R1 est senior de R2 et R2 est junior rôle de R1, si un utilisateur jouant le rôle R1 est supérieur hiérarchique de R2 ; • La deuxième vision est la hiérarchie obtenue par la relation de spécification/généralisation est définie telle que R1 est un senior rôle de R2 si chaque fois qu’un utilisateur joue le rôle de R1, elle joue le rôle de R2. Par exemple un ingénieur est un technicien . Donc à chaque fois qu’un utilisateur est associé au rôle ingénieur il joue aussi le rôle d’un technicien . Le rôle ingénieur est un senior rôle du rôle technicien . Un rôle R1 senior de R2 hérite donc les permissions affectées à R2 . Dans Or-BAC, ces deux hiérarchies réapparaissent mais les droits qui leur sont associés sont quelque peut modifiés. En effet, avec le modèle Or-BAC, on peut définir des permissions mais aussi des interdictions. Dans Or-BAC, on peut aussi spécialiser un rôle. On voit donc apparaître une hiérarchie liée à cette spécification. Dans cette hiérarchie si on veut qu’un rôle senior puisse avoir plus de pouvoir que son rôle junior, alors il faut que le rôle senior hérite des permissions de son rôle junior et que les interdictions liées au rôle senior soient héritées par son rôle junior. De plus, par rapport à R-BAC, Or-BAC introduit le concept d’organisation, ce qui donne une nouvelle dimension à l’héritage. En effet, il est possible qu’un rôle puisse toujours englober un certain sous-rôle quelle que soit l’organisation dans laquelle on se place. Par exemple, dans tout département informatique , le rôle d’ingénieur est une spécialisation du sous-rôle technicien. Or-BAC permet donc à l’ingénieur d’hériter de tous les droits du technicien en ne définissant qu’une seule fois les droits. Le reste se fait grâce à la relation de spécialisation/généralisation. Identiquement, les vues et les activités possèdent des sous-vues et des sous-activités. On les hiérarchise donc afin de créer pour elles aussi cette relation de spécialisation/généralisation.

Projet Fin d’Etudes

41

2014-2015

4.3. LES MODÈLES DE SÉCURITÉ INFORMATIQUE :

chapitre 4

4.3.6.5

La notion de délégation:

La délégation permet de donner à un utilisateur particulier un privilège, sans donner ce privilège à toutes les personnes ayant le même rôle que lui. La délégation, bien que très utilisée, est très peu modélisée dans les politiques de sécurité car ce concept est très complexe. En effet, grâce à une délégation, une permission peut être donnée par le détenteur d’un droit à un tiers pour agir à sa place ou à la place d’un autre. On voit déjà ici apparaître qu’une délégation peut faire intervenir plusieurs parties : • Le sujet qui possède le privilège, • Le sujet a qui on délègue le privilège, • Le sujet qui délègue le privilège (pour agir à sa place ou à la place d’un autre). Il existe trois types de situation dans lesquelles la notion de délégation apparaît : • La maintenance d’un rôle, • La décentralisation de l’autorité, • Le travail de collaboration. 4.3.6.6

La gestion de conflit :

Or-BAC permet d’exprimer des permissions et des interdictions. Or-BAC offre donc la possibilité de spécifier une politique mixte. Il existe dans Or-BAC une troisième catégorie de privilège : l’obligation. La notion d’obligation décrit les actions qu’un utilisateur doit faire sur un ensemble d’objets. Par exemple, dans un contexte d’urgence, un technicien aura le droit d’accéder aux dossiers d’administration mais uniquement s’il fait ensuite un rapport, c’est une obligation La politique mixte pose de nombreux problèmes liés à la gestion des conflits potentiels et des règles redondantes. Afin d’éluder le problème des règles redondantes, on ajoute des prédicats. Ceux-ci, pour deux règles données R1 et R2, interdisent d’avoir la priorité de R1 moindre que celle de R2, lorsque toutes les conditions suivantes sont vérifiées : • R1 et R2 sont définies pour une même organisation . • R1 est définie pour un rôle r1 et R2 est définie pour un rôle r2, avec r1 sous-rôle de r2 . • R1 est définie pour une activité a1 et R2 est définie pour une activité a2, avec a1 sous-activité de a2 . • R1 est définie pour une vue v1 et R2 est définie pour une vue v2, avec v1 sous-vue de v2 . • R1 est définie pour un contexte c1 et R2 est définie pour un contexte c2, avec c1 sous-contexte de c2 .

Projet Fin d’Etudes

42

2014-2015

4.4. APPLICATION DU MODÈLE OR-BAC :

chapitre 4

Il peut apparaître un conflit, par exemple si un même utilisateur possède deux rôles et que l’un de ces rôles lui permet de faire une activité et l’autre lui interdit. On est sûr que s’il n’y a aucun conflit au niveau abstrait, il n’y en aura pas au niveau concret. Ceci est dû au fait que les permissions concrètes sont déduites des permissions organisationnelles, de même pour les interdictions. Donc on résout les conflits potentiels au niveau abstrait On décide pour cela de donner des priorités aux interdictions et permissions du niveau abstrait. Cependant, si le conflit subsiste (par exemple: l’interdiction et la permission ont même priorité) alors Or-BAC prévient le concepteur de la politique. Celui-ci choisit alors de modifier les règles liées aux privilèges, ou le niveau des priorités des privilèges.

Figure 4.5: Conflit de permission : Donc, Or-BAC simplifie la conception de la politique de contrôle d’accès en automatisant la dérivation des permissions, il a l’avantage d’offrir une politique mixte qui gère les problèmes conflictuels.

4.4

Application du modèle OR-BAC :

Dans le cas d’une grande entreprise comme AL BARID BANK les données sont très critiques et le volume des données est trop grand . Autre chose , Barid Banque travaille sur l’élaboration d’un profiling pour ses fonctionnaires , pour le moment ce projet est en phase d’implémentation ,donc on n’a pas eu l’occasion pour appliquer Projet Fin d’Etudes

43

2014-2015

chapitre 4

4.4. APPLICATION DU MODÈLE OR-BAC :

cette politique d’accès , on a fait juste une simulation pour ce modèle . les sujets et les objets sont virtuels , on a utilisé l’outil motorbac pour faire la simulation du politique d’accés ORBAC

Figure 4.6: Simulation du modèle ORBAC

Projet Fin d’Etudes

44

2014-2015

4.5. CONCLUSION:

chapitre 4

Figure 4.7: Simulation sur les roles ORBAC :

4.5

Conclusion:

Pour résumer ce chapitre, on peut dire que la politique d’Accès est d’une importance remarquable dans la mise en place d’une politique de sécurité et que le choix du meilleur modèle de sécurité dépend du contexte de l’entreprise et de la confidentialité des données ainsi que la vision de l’administrateur qui implémente la politique dans un contexte. Le modèle de sécurité OR-BAC comme tous les autres a des avantages et des inconvénients mais jusqu’à présent il reste le premier choix dans les grandes entreprises et les banques. Dans le chapitre suivant on va traiter le troisième point du modèle AAA qui est (Accounting) traçabilité

Projet Fin d’Etudes

45

2014-2015

Chapter 5 Centralisation / Corrélation des logs et Traçabilité 5.1

Corrélation des logs

Dans ce chapitre nous vous donnons une vision gobale sur la notion SIEM et les diffirents outils open source et payantes qui existent , les avantages , les inconvinients de chacun parmi eux ,puis les critères du choix d’un meilleur outil SIEM .

5.1.1

Définition de l’outil SIEM :

5.1.1.0.1 Le terme SIEM (Security Information and Event Management) est une combinaison de la carte SIM (Security Information Management) et SEM (Security Event Management), qui sont des catégories d’outils disparates. Alors que la carte SIM est destinée à fournir un stockage à long terme, l’analyse et la présentation des données des journaux, SEM traite la surveillance en temps réel, la corrélation des événements, notifications et vues de la console. Maintenant, un SIEM combine ces deux fonctionnalités dans un seul outil. Le terme SIEM ( sécurité de l’information et la gestion des événements ) décrit la capacité de collecte, d’analyse et de présentation de l’information à partir de sources très différentes que des dispositifs de réseau et de sécurité, l’identité et les applications de gestion des accès, système d’exploitation, les journaux de base de données et d’applications et les données des menaces même externes. Habituellement, ils sont renvoyés de leur source respective de la SIEM que les messages (messages de log, les déclencheurs, les pièges, les fichiers soumis, présentations de table de base de données, etc.) Alors que les sources sont au moins en partie très différents de ceux de la criminalistique informatique, les capacités sont presque les mêmes. Typiquement, les outils SIEM modernes peuvent également intégrer une fonctionnalité externe, comme flux de travail et de billetterie par exemple, pour l’ensemble 46

5.1. CORRÉLATION DES LOGS

chapitre 5

du processus de l’incident pour être appliqués dans une seule interface utilisateur. Étant donné que chaque environnement est différent, les meilleurs outils SIEM offrent un ensemble souple des capacités d’intégration. Intégrer un logiciel spécialisé pour la criminalistique informatique dans un SIEM est donc, par définition, pas un défi insoluble.

5.1.2

Les fonctionnalités d’un SIEM :

5.1.2.1

Collecte :

Les logiciels de SIEM prennent en entrée les événements collectés du système d’information d’un environnement spécifique : les journaux système des équipements (pare feux, routeurs, switch, serveurs, bases de données. . . ), les évènements survenus dans des machines supervisées, des fichiers retournés par des applications. Ils permettent de prendre en compte différents formats (syslog, Traps SNMP, fichiers plats, OPSEC, formats propriétaires, etc.) ou nativement le format IDMEF (Intrusion Detection Message Exchange Format), spécialement conçu et validé par l’IETF sous forme de RFC pour partager l’information qui intéresse un système de détection et protection aux intrusions. La collecte peut être de façon passive en mode écoute ou active en mettant en place des agents directement sur les équipements ou à distance. Les solutions permettent également de développer des collecteurs pour prendre en compte des nouveaux formats de journaux systèmes (API, expression régulière. . . ). 5.1.2.2

Normalisation :

Les traces brutes des évènements survenus sont stockées sans modification pour garder leur valeur juridique. On parle de valeur probante. Ces traces sont généralement copiées puis normalisées sous un format plus lisible pour une exploitation normalisée. En effet, la normalisation permet de faire des recherches multi critères, sur un champ ou sur une date. Ce sont ces évènements qui seront enrichis avec d’autres données puis envoyés vers le moteur de corrélation. 5.1.2.3

Agrégation :

L’agrégation d’évènements consiste à définir un certain nombre de types d’évènements produits, de tester la similitude entre eux. De ce constat, plusieurs règles de filtrage peuvent être appliquées. Ils sont ensuite agrégés selon les solutions, puis envoyés vers le moteur de corrélation. Néanmoins, il est communément admis dans les applications de veille en sources ouvertes que l’information manipulée par les analystes est incertaine à plusieurs niveaux : l’information en elle-même, la source, les traitements opérés, etc. Pourtant de ce constat, nous voulons laisser à l’administrateur le choix final de fusionner (ou non) deux évènements jugés similaires, et cela dans le but d’éviter toute perte d’information pouvant survenir avec une fusion totalement automatisée.

Projet Fin d’Etudes

47

2014-2015

5.1. CORRÉLATION DES LOGS

chapitre 5

5.1.2.4

Corrélation :

Les règles de corrélation permettent d’identifier un évènement qui a causé la génération de plusieurs autres (un hacker qui s’est introduit sur le réseau, puis a manipulé tel équipement. . . ).Ces règles sont mises en place afin de chercher des séquences et des motifs dans les évènements du journal qui ne sont pas visibles par une analyse individuelle. Elles permettent aussi de remonter une alerte via un trap, un mail, sms ou ouvrir un ticket si la solution SIEM est interfacée avec un outil de gestion de tickets. Ces alertes représentent les évènements importants produits dans le réseau, qui sont corrélés, afin d’en tirer profit pour reconnaitre les risques de sécurité. Les règles de gestion se mettent à jour par l’administrateur, lorsque l’analyse et la corrélation d’évènements deviennent répétitives. 5.1.2.5

Reporting :

Les SIEM permettent également de créer et générer des tableaux de bord et des rapports. Ainsi, les différents acteurs du système d’information, responsable de la sécurité des systèmes d’informations, administrateurs, utilisateurs peuvent avoir une visibilité sur le système d’information (nombre d’attaques, nombre d’alertes par jour. . . ). 5.1.2.6

Archivage :

Les solutions SIEM sont utilisées également pour des raisons juridiques et réglementaires. Un archivage à valeur probante permet de garantir l’intégrité des traces. Néanmoins, l’archivage des logs est effectué pour une certaine durée qui serait précisée par l’administrateur du système d’information. En cas de défaillance du disque dur ou pour une raison quelconque, il est nécessaire d’avoir une copie, stockée quelque part, des données concernant les logs et leurs traitements d’analyse et pouvoir y accéder en cas de perte de celles-ci. De surcroit, il existe deux types d’archivages des données présentés comme suit : .Archivage local : La sauvegarde des données est effectuée sur un dispositif de stockage alternatif, contenant une copie des informations personnelles, que ça soit une sauvegarde sur un disque dur externe, sur un disque dur d’une autre machine. •Archivage sur internet : La sauvegarde est effectuée sur un site internet qui offre la possibilité de sauvegarde, tel que la sauvegarde en Cloud. En cas d’un crash du disque dur, on pourrait éventuellement récupérer nos données en se connectant sur Les solutions pouvant utiliser des disques en RAID, calculer l’empreinte, utiliser du chiffrement ou autre pour garantir l’intégrité des traces.

5.1.3

Rejeu des évènements :

La majorité des solutions permettent également de rejouer les anciens évènements pour mener des investigations post incident. Il est également possible de modifier une règle et de rejouer les évènements pour voir son comportement

Projet Fin d’Etudes

48

2014-2015

5.2. COMPARAISON DES OUTILS OPEN SOURCE SIEM :

chapitre 5

5.2

Comparaison des outils open source SIEM :

Afin de procéder au choix de l’outil que nous allons utiliser pour collecter, corréler et finalement de mettre en place un outil de détection d’intrusion, un benchmarking des outils SIEM s’impose en vue de choisir l’outil le plus performant et le plus adapté aux besoins de la société. Nous allons dans cette partie introduire les deux concurrents élus d’être l’outil open source capables de répondre aux fonctionnalités cités précédemment ainsi que de répondre aux besoins et aux contraintes de centralisation et de corrélation de logs.

l outi

Logalyse

splunk

s tage n a v a -Exportation des rapports ou des listes aux formats CVS,XLS,PDF,HTML. ,Offre deux types de corrélation (corrélation manualle ,corrélation en temps réel) ,Collecte les logs a partir de n’importe quel équipement ,Compatible avec syslog , rsyslog ,windows et linux -Moteur de recherche intelligent pour les logs . -Combine trois projet open source Elasticsearch , Kibana, Fluentd

Apache ALOIS

-Collectant les informations de securité , il est destine à la sécurite du contenu

Cyberoam

-Compatible avec windows et linux . -Possible de modifier le code source -Possibilté de personnalisation en fonction du besoin le controle et l’analyse tres rapide -Offre une corrélation en temps réel -Corrélation et aggrégation avancés -Transmission des données sécurisée -Authentifications https

prelude oss

Projet Fin d’Etudes

49

nt

e véni n o c n

i -Documentation assez maigre et dispersée. -Difficile de bien exploiter ses fonctionalitées -il n’est pas developpé par rapport aux autres projets open source

Surveillence et alert des événements limités n’est pas open source

-N’est pas assez amelioré . -N’est plus developpé, -N’est compatible qu’avec windows -Documentation dipersée -Il ne support pas des quantites massives des données les équipements cisco supportés: uniquement cisco asa on ne pourrait ajouter que 5 serveurs syslog

-N’offre pas la possibilite de générer des rapports -Pas de performance de base de données Le nombre des équipements supportés ne dépasse pas 50 -N’est pas compatible avec windows 2014-2015

chapitre 5

5.2. COMPARAISON DES OUTILS OPEN SOURCE SIEM :

OSSIM

-Unifie plusieurs outils de gestion reseau, de securite ,de corrélation , qualification des données - compatible avec tous les agents possible

ELK

-Offre une corrélation en temps réel. -Corrélation et aggrégation avancés. -Transmission des données sécurisée. -Gratuit et open source . -Compatible avec windows linux mac ,.. -Moteur de recherche intelligent pour les logs . -Pleine de fonctionnalités .

-Architecture monolithique (illisible pour un simple utilsateur ). -Systeme d’exploitation impose debian version gratuite n’est pas complet. -Moins de fonctionnalites pour version gratuit. necessite un administrateur bien familialisé avec les open sources

Table 5.1: Etude comparative des outils SIEM

5.2.1

Les besoins et les contraintes de choix

Les besoins fonctionnels qu’il faudrait prendre en considération afin de procéder au choix de l’outil pour qu’il soit le plus adapté à la solution qu’on voudrait mettre en place, sont cités ci-dessous : • Pouvoir centraliser tous les logs générés par les hôtes (machine, serveur), par les équipements réseaux (swtich, routeur) ainsi que par les logs des fichiers plats générés par les applications. Ces logs collectés doivent être mis sous un format défini et adapté pour être exploité de manière facile et visible. • Avoir la possibilité de corréler les événements collectés à partir des différentes sources qui interagissent avec la solution, en vue de générer de nouveaux événements appelés alarmes. • Permettre d’intégrer un détecteur d’intrusion pour éviter toute tentative d’écouter le trafic circulant dans le système d’information. • La solution doit avoir un module de reporting en vue de générer des rapports personnalisés pour garder la traçe des logs survenus dans le système afin d’être exploitable par l’auditeur interne à l’organisme ou l’auditeur externe. Les contraintes à respecter afin de procéder au choix adapté avec l’environnement de travail sont citées ci-dessous :

Projet Fin d’Etudes

50

2014-2015

chapitre 5

5.2. COMPARAISON DES OUTILS OPEN SOURCE SIEM :

• Avoir une solution qui peut être installée sur un serveur Windows, car Barid Bank dès son départ jusqu’à aujourd’hui a adopté un environnement basé sur le système d’exploitation Windows. • La solution permet de collecter les logs à partir des hôtes (machine, serveur) doté d’un système d’exploitation Windows, ainsi que des équipements réseaux (switch, serveur) Cisco.

5.2.2

Les critères du Choix de l’outil SIEM

D’après cette étude préliminaire des outils open source existants dans le marché des solutions SIEM. Nous avons fait le choix de deux outils OSSIM et ELK susceptibles d’être utils pour répondre à nos besoins ainsi qu’à nos contraintes. Pour ce faire, nous allons étudier de plus prêt nos deux solutions afin de pouvoir choisir la solution la plus adéquate à notre situation.

5.2.3

ELK :

E

lk Est un projet combiné des outils open source permettant à la fois d’identifier, analyser, normaliser et indexer les messages entrants afin de pouvoir les stocker. Il permet également de générer des rapports et des alertes. 5.2.3.1

Avantages :

Les principales fonctionnalités de l’outil ELK sont les suivantes : • - ELK Collecte les logs à partir de n’importe quel équipements réseaux ou logiciels ( pare-feu, proxy, Windows, Linux. . . ) • - Il est compatible avec la collecte des logs de plusieurs formats rsyslog, syslogng, snare ,... • - Convertit les champs analysés dans un format normalisé aux fins d’analyse et reporting et synchronise l’heure en GMT • - Le module de corrélation recueille les messages de différents systèmes et de trouver tous les messages appartenant à un seul évènement • - Il offre la possibilté de corrélation grace à des règles de filtrage . • - Il peut détecter les anomalies dans un système de travail (nouveaux messages non apparus auparavant) La solution permet d’offrir des rapports ou des listes aux formats CSV, XLS, PDF ou HTML • - Il offre un dashboard pour l’administration • - Il utilise un moteur de recherche intilligent pour l’indexation des logs • - Il utilise multiple techniques pour le stockage des données • - Une communaué très active et large • - Il supporte multiple input/out put formats des logs

Projet Fin d’Etudes

51

2014-2015

chapitre 5

5.2.3.2

5.2. COMPARAISON DES OUTILS OPEN SOURCE SIEM :

Inconvénients :

Cependant, chaque outil open source aussi puissant soit-il a toujours ses inconvénients , ces derniers seront listés ci-dessous : • ELK nécessite un administrateur expert systéme pour bien organiser , administrer , collecter et corréler les logs . • difficile à mettre en oeuvre .

5.2.4

OSSIM :

OSSIM fournit toutes les fonctionnalités qu’une garantie des besoins professionnels d’une offre SIEM : collecte d’événements, de normalisation, et de corrélation. Créé et lancé par les ingénieurs de sécurité par nécessité, OSSIM a été créé avec une compréhension de la réalité, de nombreux professionnels de la sécurité font face: un SIEM est inutile sans les contrôles de sécurité de base nécessaires à la visibilité de la sécurité. OSSIM aborde cette réalité en fournissant les fonctions de sécurité essentielles intégrées dans une plate-forme unifiée. Debout sur les épaules des nombreux contrôles de sécurité open source éprouvées intégrées dans la plate-forme, OSSIM continue d’être le moyen le plus rapide de faire les premiers pas vers la visibilité de sécurité unifiée. 5.2.4.1

Avantages :

Les principales fonctionnalités de l’outil open source puissant OSSIM ainsi que ses avantages par rapport aux autres solutions existantes dans le marché, sont citées ci-dessous : • Pouvoir centraliser les logs de tous les équipements systèmes, réseaux et logiciels de nombreuses façons possibles grâce à ses plugins • La définition des règles de corrélation via des fichiers xml facilement exploitables • Peut être installé sur tous les types d’agents possibles (Linux,Windows) • Il offre la possibilité de reporting audit grâce à un plugin puissant iReport 5.2.4.2

Inconvénients :

• Le système d’exploitation est imposé (Debian) • Architecture monolithique (illisible par un utilisateur non professionnel) • L’architecture de clusturing est offerte par la solution payante d’Alienvault (USM)

5.2.5

Synthèse de choix de la solution

Nous remarquons d’après l’étude approfondie des deux solutions susceptibles d’être choisies,l’outil open source qui répond aux besoins de notre projet ainsi que les contraintes de notre architecture de Al Barid Bank Group, est ELK . Projet Fin d’Etudes

52

2014-2015

chapitre 5

5.2.6

5.2. COMPARAISON DES OUTILS OPEN SOURCE SIEM :

Quelques capture d’écran de notre solution ELK :

Figure 5.1: Statistiques des évènement des logs : Cette figure nous donne les statistiques des évènements envoyés au serveur et l’usage des indices utilisés .

Figure 5.2: Statistiques des transmissions des données

la figure ci-dessus montre les statistiques des transmissions des données et les Requêtes envoyées au serveur

Projet Fin d’Etudes

53

2014-2015

chapitre 5

5.2. COMPARAISON DES OUTILS OPEN SOURCE SIEM :

Figure 5.3: Tableau de bord

La figure ci-dessus nous donne un dashboard en fonction du temps sur les fichiers journaux stockés dans Elasticsearch et affiché dans kibana

Figure 5.4: Top 10 IP adresses

Cette figure montre les dix premières adresses ip visités par les clients Projet Fin d’Etudes

54

2014-2015

5.3. SOLUTION ELK :

chapitre 5

Figure 5.5: Les champs de l’indice PacketBeat

Cette figure montre la maniére avec laquelle l’information est organisée dans un indice du cluster.

5.3 5.3.1

Solution ELK : Les Composantes d’ELK :

ELK est un outil open source basé principalement sur trois outils open source et libre . • Elasticsearch • Logstash • Kibana dans le contexte de notre stage on a ajouté l’outil suivante : • packetbeat pour analyser le trafic réseau et perfectionner notre solution.

5.3.2

Elasticsearch :

C’est un moteur de recherche libre open source utilisant Lucene (un des projets de l’Apache Software Foundation). • Il est distribué (architecture de type cloud computing). • Il utilise Lucene pour le stockage de ses données dans un format NoSQL.

Projet Fin d’Etudes

55

2014-2015

5.3. SOLUTION ELK :

chapitre 5

• Il utilise la méthode REST. L’indexation des données s’effectue à partir d’une requête HTTP PUT. La recherche des données s’effectue avec la requête HTTP GET. Le flux d’information est codé selon le format JSON. • Il est associé à deux autres produits open source : Kibana et Logstash qui sont respectivement un visualiseur de données et un ETL (initialement destiné aux logs). 5.3.2.1

Stockage dans elasticsearch

L’indice peut être soit stocké en mémoire (pas persistance) ou sur disque (par défaut). En mémoire les indices fournissent une meilleure performance au prix d’une limitation de la taille de l’index à la quantité de mémoire physique disponible. Lorsque vous utilisez une passerelle locale (par défaut), le stockage des fichiers en mémoire est nécessaire pour maintenir la cohérence de l’indice. Ceci est nécessaire, car la passerelle locale construit l’état de l’indice local de chaque nœud. Un autre aspect important de stockage à base de mémoire est le fait que ElasticSearch permet de stocker l’index en mémoire, en dehors de l’espace du pile JVM .Ce stockage se traduit par le fait qu’il n’y a pas besoin de très grands pile JVM (avec leurs conséquences) pour stocker l’index dans la mémoire. Stockage : 5.3.2.1.1

Types de stockage :

Il existe différentes implémentations ou des types de stockage, le meilleur pour l’environnement d’exploitation sera sélectionné automatiquement : • File system : est un stockage basé sur le système de fichier c’est le stockage utilisé par défaut. • simplefs : Ce type est une mise en œuvre simple de stockage de système de fichiers en utilisant un fichier d’accès aléatoire. • niofs : Il permet à plusieurs threads (fils) de lire à partir du même fichier en même temps. Il est déconseillé sur Windows en raison d’un bug dans l’implémentation de Sun Java.

5.3.3

Logstash :

Fluentd est un outil concurrent de Logstash , pour choisir la technologie qui répond le plus à nos besoins et qui respecte les critères imposés par le cahier de charge on a fait une étude comparative entre ces deux outils afin d’identifier l’outil compatible avec l’environnement AL BARID BANK . Logstash et Fluentd sont deux projets open-source qui mettent l’accent sur le problème de l’exploitation centralisée . Les deux projets portent sur l’aspect

Projet Fin d’Etudes

56

2014-2015

5.3. SOLUTION ELK :

chapitre 5

de la collecte et le transport des fichiers journaux utilisant des approches différentes . Le problème est de ne pas comprendre ce qui est le meilleur , mais plutôt de voir quel serait un meilleur ajustement pour notre environnement.

Figure 5.6: L’archivage ou le traitement avec un serveur de cloud d’amazon S3.

l outi Exigences d’installation

Fonctionnalités

securité

ash logst -Il fonctionne sur la JVM .La JVM utilise plus de mémoire qu’on veux utiliser pour le transport des journaux -Il peut fonctionner sur n’importe quel systeme d’exploitation :Linux, Mac OSX et Windows. -Logstash prend en charge un nombre d’entrées, des codecs, des filtres et des sorties . -Les filtres traitent les actions sur les événements et nous permet de modifier ou de supprimer des événements comme s’ils sont traités.

td fluen -Il fonctionne sur Linux et Mac OSX, mais ne fonctionne pas sur Windows pour le moment -Il est principalement développé par une société commerciale

les transferts de journaux sont chiffrées

les transferts de journaux sont transférés en claire

les messages de journal sont convertis en JSON qui fournit la structure à un message de journal non structuré .

Table 5.2: Etude comparative entre Logstash et Fluentd

Projet Fin d’Etudes

57

2014-2015

5.3. SOLUTION ELK :

chapitre 5

Probablement la différence la plus significative entre Fluentd et Logstash est leur foyer de conception. Logstash souligne la flexibilité et l’interopérabilité alors Fluentd privilégie la simplicité et la robustesse. Cela ne signifie pas que Logstash n’est pas robuste ou Fluentd n’est pas flexible, mais chacun d’eux a des priorités caractéristiques différentes . Fluentd a moins d’entrées que Logstash , mais il gère tres bien l’équilibrage de charge, les délais d’attente et les tentatives. Ces types de caractéristiques sont nécessaires pour assurer de manière fiable la livraison des données. Logstash et Fluentd sont des outils d’exploitation centralisés viables qui peuvent transférer des journaux à partir de plusieurs hôtes à un emplacement central. Logstash est incroyablement flexible avec de nombreux plugins d’entrée et de sortie alors Fluentd fournit moins de sources d’entrée et de sortie. Après cette étude comparative on a choisi Logstash pour l’utliser dans notre environement AL Brid BANK .

5.3.4

Packbeat :

Packetbeat est un analyseur de réseau en temps réel qui peut être utilisé avec ElasticSearch afin de fournir un système de surveillance d’application et d’analyse de performance. Il fonctionne en capturant le trafic réseau entre les serveurs d’applications, le décodage des protocoles de couche d’application (HTTP, HTTPS, SSH, etc.), la corrélation des demandes avec les réponses des opérations et l’enregistrement des domaines intéressants pour chaque transaction. Le système se compose des éléments suivants: • Packetbeat • ElasticSearch • Kibana L’analyseur Packetbeat permet de analyser le trafic qui passe entre les serveurs, corréler les messages dans les transactions. Actuellement, l’analyseur Packetbeat supporte les protocoles suivants: • • • • •

HTTP HTTPS SSH FTP ...

L’analyseur peut insérer les opérations corrélés directement dans ElasticSearch ou via une file d’attente centrale créée avec Redis et Logstash. Packetbeat peut fonctionner sur les mêmes serveurs que vos processus d’application Projet Fin d’Etudes

58

2014-2015

5.3. SOLUTION ELK :

chapitre 5

ou sur leurs propres serveurs. Lors de l’exécution sur des serveurs dédiés, il peut obtenir le trafic en provenance des ports des commutateurs , ou bien d’autres dispositifs . Après le décodage des messages de la couche 7 du modèle OSI , Packetbeat corrèle les demandes avec leurs réponses dans ce que nous appelons les «transactions» et, pour chaque transaction, il insère un document JSON dans ElasticSearch .

Figure 5.7: Fonctionnement du packetbeat

ElasticSearch et l’instance Kibana qui sont utilisés pour analyser le trafic réseau recueillies par Packetbeat peuvent être utilisés pour analyser les fichiers journaux recueillies par Logstash. De cette façon, vous pouvez avoir le trafic réseau et l’analyse des journaux dans le même système. Packetbeat peut également insérer les opérations dans une liste Redis. Cela permet d’utiliser Redis + Logstash comme un collecteur central et file d’attente pour les données sur les transactions. Voir l’architecture de Packetbeat avec Logstash pour plus de détails.

Projet Fin d’Etudes

59

2014-2015

5.4. TRAÇABILITÉ

chapitre 5

Figure 5.8: Fonctionnement du Packetbeat avec Logstash

Redis est un système de gestion de base de données clef-valeur scalable, très hautes performances, écrit avec le langage de programmation C ANSI et distribué sous licence BSD. Il fait partie de la mouvance NoSQL et vise à fournir les performances les plus élevées possibles.

5.3.5

Kibana :

5.3.5.0.2 Kibana est une interface web permettant de rechercher des infos stockées par Logstash dans ElasticSearch.

Figure 5.9: Architecture générale d’ELK

5.4

Traçabilité

Dans cette partie nous détaillerons comment faire la traçabilte dans une grande entreprise comme Al Barid Bank par l’exploitation des logs et des outils cités ci-dessus ,et à la fin de ce chapitre vous découvrez comment tracer le trafic Projet Fin d’Etudes

60

2014-2015

5.4. TRAÇABILITÉ

chapitre 5

entrant et sortant avec l’analyse de ce derniere via un dashboard graphique et une map de traffic . En exploitant la notion de map pour bien analyser le trafic dans un réseau et avec l’utilisation de la GEOIP pour bien déterminer la provenance et la destination de trafic .

5.4.1

Les contraintes techniques de la traçabilité

• Jusqu’où la traçabilité doit-elle aller ? • Faut-il identifier les événement un par un, ou par groupe ? • La source et le trajet d’un événement doivent-ils être accessibles au public ? • Combien de temps conserver les archives, etc.

5.4.2

traçabilité sur ABB

Nous avons utilisé ELK comme solution pour la traçabilité malgré ses limites , on a amélioré les règles de filtrages par la focalisation sur le champs Geoip , et d’autres champs pour savoir les sources et les destinataires en fonctionnement de leurs adresses ip

Figure 5.10: Les sources des differentes addresses ip Apres l’activation de la régle de filtrage Geoip , on peut determiner toutes les connexions établies et connaitre la localisation des differents adresses IP visités comme le montre la figure ci-dessus

Projet Fin d’Etudes

61

2014-2015

5.4. TRAÇABILITÉ

chapitre 5

Figure 5.11: Règles de filtrage L’utilisateur peut selectionner la règle de filtrage selon ses besoins par exemple pour déterminer l’emplacement géo-graphique des adresses IP visitées , il doit cocher les champs longitude ,latitude et coordonnées comme le montre la figure 5.13.

Figure 5.12: Pays visités on peut savoir les pays visites par les utilsateurs Projet Fin d’Etudes

62

2014-2015

5.5. PERSPECTIVE :

chapitre 5

5.5

Perspective :

L

e but principal de notre projet se manifeste dans la combinaison de plusieurs solutions open source afin d’obtenir une seule plateforme simple et facile à gérer par un administrateur Datacenter. Il faut également noter que nous avons essayé d’homogénéiser le lien entre ces solutions, cela va nous permettre de faciliter leur gestion.

Projet Fin d’Etudes

63

2014-2015

Annexe Dans ce chapitre nous présenterons les étapes de déploiement de la solution choisie (ELK) au sein du système d’information de Al Barid Bank. Nous allons détailler la configuration de notre plateforme ELK .

5.6

Installation d’Elasticsearch et ses plugins

Pour la mise en oeuvre du plateforme de centralisation/corrélation des logs On commence par l’installation d’Elasticsearch 1 2 3

4 5

mkdir −pv p r o j e t cd p r o j e t wget h t t p s : / / download . e l a s t i c . co / e l a s t i c s e a r c h / e l a s t i c s e a r c h / e l a s t i c s e a r c h − 1 . 6 . 0 . t a r . gz t a r x f e l a s t i c s e a r c h − 1 . 6 . 0 . t a r . gz cd e l a s t i c s e a r c h − 1 . 6 . 0

Pour les familles Ubuntu/debian 1

2

h t t p s : / / download . e l a s t i c . co / e l a s t i c s e a r c h / e l a s t i c s e a r c h / e l a s t i c s e a r c h − 1 . 6 . 0 . deb #dpkg − i e l a s t i c s e a r c h − 1 . 6 . 0 . deb

Pour les familles redhat/centos 1

2

h t t p s : / / download . e l a s t i c . co / e l a s t i c s e a r c h / e l a s t i c s e a r c h / e l a s t i c s e a r c h − 1 . 6 . 0 . noarch . rpm #rmp −i v h e l a s t i c s e a r c h − 1 . 6 . 0 . noarch . rpm

Dans les deux cas précédent ubuntu/debian et redhat/centos les fichiers de configurations se trouvent dans le répertoire 1

/ etc / elasticsearch /

et les repertoires principales de configuration se trouvent dans le chemin suivant 1

/ usr / share / e l a s t i c s e a r c h /

Puis on va éditer le fichier elasticsearch.yml et on ajoute les lignes suivants 1 2

http . jsonp . enable : true http . http . enable : true

puis on décommente les lignes suivants et on les modifie 64

5.6. INSTALLATION D’ELASTICSEARCH ET SES PLUGINS

chapitre 5

1 2 3 4 5

#c l u s t e r . name : e l a s t i c s e a r c h #node . name : " s t a g e p f e " #h t t p . p o r t : 9200 #t r a n s p o r t . t c p . p o r t : 9300 #i n d e x . number_of_shards : 5

Après l’installation d’Elasticsearch on va ajouter les plugins nécéssaires qui répondent à nos besoins .

5.6.1

Plugin Marvel

Marvel est un plugin d’Elasticsearch pour simplifier la supervision et la gestion des logs . Pour ajouter ce plugin de supervision Marvel il suffit de télécharger la version d’essaie 1

b i n / p l u g i n − i e l a s t i c s e a r c h / marvel / l a t e s t

5.6.2

Plugin BigDesk

Installer des plugin pour simplifier la gestion du cluster et des noeuds http://bigdesk.org/ 1

. / b i n / p l u g i n − i n s t a l l l u k a s −v l c e k / b i g d e s k / 2 . 4 . 0

BigDesk est un gestionnaire de plugins d’ElasticSearch . On va télécharger et installer ce plugin via les sources de Bigdesk: 1 2

3

4 5

6

7

8

9 10

−> I n s t a l l i n g l u k a s −v l c e k / b i g d e s k / 2 . 4 . 0 . . . Trying h t t p : / / download . e l a s t i c s e a r c h . o r g / l u k a s −v l c e k / b i g d e s k / bigdesk − 2 . 4 . 0 . zip . . . Trying h t t p : / / s e a r c h . maven . o r g / r e m o t e c o n t e n t ? f i l e p a t h=l u k a s − vlcek / bigdesk /2.4.0/ bigdesk − 2 . 4 . 0 . zip . . . Trying h t t p s : / / o s s . s o n a t y p e . o r g / s e r v i c e / l o c a l / r e p o s i t o r i e s / r e l e a s e s / c o n t e n t / l u k a s −v l c e k / b i g d e s k / 2 . 4 . 0 / b i g d e s k − 2 . 4 . 0 . zip . . . Trying h t t p s : / / g i t h u b . com/ l u k a s −v l c e k / b i g d e s k / a r c h i v e / v2 . 4 . 0 . zip . . . Downloading ............................................................ DONE I n s t a l l e d l u k a s −v l c e k / b i g d e s k / 2 . 4 . 0 i n t o /home/ halimou / p r o j e c t s / e l a s t i c s e a r c h −1.6.0/ plugins / bigdesk I d e n t i f i e d a s a _ s i t e p l u g i n , moving t o _ s i t e s t r u c t u r e . . .

ou bien les cloner via github 1 2 3 4 5 6

7

$ g i t c l o n e h t t p s : / / g i t h u b . com/ l u k a s −v l c e k / b i g d e s k . g i t Cloning i n t o ’ bigdesk ’ . . . remote : Counting o b j e c t s : 4 9 4 7 , done . remote : Compressing o b j e c t s : 100% ( 2 7 2 6 / 2 7 2 6 ) , done . remote : T o t a l 4947 ( d e l t a 1 8 3 1 ) , r e u s e d 4883 ( d e l t a 1 7 9 2 ) R e c e i v i n g o b j e c t s : 100% ( 4 9 4 7 / 4 9 4 7 ) , 1 7 . 7 8 MiB | 1 . 0 8 MiB/ s , done . R e s o l v i n g d e l t a s : 100% ( 1 8 3 1 / 1 8 3 1 ) , done .

Projet Fin d’Etudes

65

2014-2015

5.6. INSTALLATION D’ELASTICSEARCH ET SES PLUGINS

chapitre 5

1 2 3 4 5 6 7 8

$ cd b i g d e s k / $ g i t tag [ . . . some t a g s l e f t out f o r b r e v i t y . . . . ] v2 . 4 . 0 $ g i t c h e c k o u t v2 . 4 . 0 Note : c h e c k i n g out ’ v2 . 4 . 0 ’ . [ . . . o p t i o n a l g i t m ess age s . . . ] HEAD i s now a t 4 a23042 . . . R e l e a s e v2 . 4 . 0 − E x t r a c t t h e c l u s t e r s t a t u s CSS and . . . .

Figure 5.13: Plugin Bigdesk

5.6.3

Plugin Elasticsearch Kopf

Kopf est un outil simple d’administration web pour ElasticSearch écrit en JavaScript , angularjs , jQuery , Twitter bootstrap.

Projet Fin d’Etudes

66

2014-2015

5.6. INSTALLATION D’ELASTICSEARCH ET SES PLUGINS

chapitre 5

Ce plugin offre un moyen facile d’éffectuer des tâches courantes sur un cluster d’ElasticSearch. Demarrer Localement : 1 2 3 4

1 2

g i t c l o n e g i t : / / g i t h u b . com/ l m e n e z e s / e l a s t i c s e a r c h −k o p f . g i t cd e l a s t i c s e a r c h −k o p f g i t checkout { v e r s i o n } open i n d e x . html . / b i n / p l u g i n −− i n s t a l l l m e n e z e s / e l a s t i c s e a r c h −k o p f /{ v e r s i o n } open h t t p : / / l o c a l h o s t : 9 2 0 0 / _plugin / k o p f

Figure 5.14: Plugin KOPF

5.6.4

Plugin Elasticsearch-head

Ce plugin est une interface web pour un cluster ElasticSearch 1 2

/ b i n / p l u g i n − i n s t a l l mobz/ e l a s t i c s e a r c h −head open h t t p : / / l o c a l h o s t : 9 2 0 0 / _plugin / head /

Projet Fin d’Etudes

67

2014-2015

chapitre 5

5.6. INSTALLATION D’ELASTICSEARCH ET SES PLUGINS

Figure 5.15: Plugin head

Figure 5.16: Plugin head

5.6.5

Plugin Whatson

Whatson est un Plugin d’ElasticSearch pour visualiser l’état d’un cluster. Il est inspiré par d’autres excellents plugins: • ES Head Projet Fin d’Etudes

68

2014-2015

chapitre 5

5.6. INSTALLATION D’ELASTICSEARCH ET SES PLUGINS

• Bigdesk • SegmentSpy 1 2

b i n / p l u g i n − i n s t a l l xyu/ e l a s t i c s e a r c h −whatson / 0 . 1 . 3 open h t t p : / / l o c a l h o s t : 9 2 0 0 / _plugin / whatson /

Projet Fin d’Etudes

69

2014-2015

chapitre 5

5.6. INSTALLATION D’ELASTICSEARCH ET SES PLUGINS

Figure 5.17: Plugin Whatson Projet Fin d’Etudes

70

2014-2015

5.7. INSTALLATION DU LOGSTASH

chapitre 5

pour plus des plugins on peut visiter le site

https://www.elastic.co/guide/en/elasticsearch/reference/current/modulesplugins.htmlsite

5.7

Installation du Logstash

Pour la corrélation des logs on va installer l’outil Logstash 1

2 3

wget h t t p s : / / download . e l a s t i c . co / l o g s t a s h / l o g s t a s h / l o g s t a s h − 1 . 5 . 1 . t a r . gz t a r x f l o g s t a s h − 1 . 5 . 1 . t a r . gz cd l o g s t a s h − 1 . 5 . 1

Pour les distributions Linux Ubuntu/debian ou bien Redhat/Centos on télécharge les paquets rmp /deb . et on édite un fichier 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 26 27 28 29 30

input { s t d i n {} file { path => " / var / l o g / ∗ . l o g " type => s y s l o g } } filter { i f [ type ] == " s y s l o g " { grok { match => { " message " => "%{SYSLOGTIMESTAMP: syslog_timestamp } %{SYSLOGHOST: syslog_hostname } %{DATA: syslog_program } ( ? : \ [ % {POSINT : syslog_pid }\]) ? : %{GREEDYDATA: s y s l o g _ m e s s a g e } " } a d d _ f i e l d => [ " r e c e i v e d _ a t " , "%{@timestamp } " ] a d d _ f i e l d => [ " r e c e i v e d _ f r o m " , "%{h o s t } " ] } syslog_pri { } date { match => [ " syslog_timestamp " , "MMM d HH:mm: s s " , "MMM dd HH :mm: s s " ] } } i f [ type ] == " halimou " { grok { match => { " message " => " H e l l o from HALIMOU" } } geoip { s o u r c e => " c l i e n t i p " t a r g e t => " s r c \ _ip " d a t a b a s e => " / opt / backup / G e o L i t e C i t y . dat " a d d _ f i e l d => [ " [ g e o i p ] [ c o o r d i n a t e s ] " , " %{[ g e o i p ] [ l o n g i t u d e ]} " ]

Projet Fin d’Etudes

71

2014-2015

5.8. INSTALLATION DU LOGSTASH-FORWARDER

chapitre 5

31

" }

32 33 34

a d d _ f i e l d => [ " [ g e o i p ] [ c o o r d i n a t e s ] " , " %{[ g e o i p ] [ l a t i t u d e ] } ]

} }

35 36 37 38 39 40 41 42

output { elasticsearch { h o s t => l o c a l h o s t i n d e x => b a r i d l o g } s t d o u t { c o d e c => rubydebug } }

et puis on lance les services 1

. / b i n / l o g s t a s h −f l o g . c o n f

et voici une capture d’écran

Figure 5.18: Capture d’écran de Logstash

5.8

Installation du Logstash-forwarder

On utilise logstash-forwarder comme un agent pour envoyer les logs vers logstash server 1

Projet Fin d’Etudes

72

2014-2015

chapitre 5

2 3 4 5 6 7 8 9 10 11 12 13

14 15

5.8. INSTALLATION DU LOGSTASH-FORWARDER

input { 2 3 lumberjack { 4 p o r t => 5040 5 s s l _ c e r t i f i c a t e => / opt / backup / t e s t a / ca . c r t 6 type => s y s l o g # s t r i n g ( o p t i o n a l ) 7 } 8 } 9 filter { 10 i f [ type ] == " s y s l o g " { 11 grok { 12 match => { " message " => "%{SYSLOGTIMESTAMP: syslog_timestamp } %{SYSLOGHOST: syslog_hostname}%{DATA: syslog_program } ( ? : \ [ % {POSINT : s y s l o g _ p i d } \ ] ) ? : %{GREEDYDATA: s y s l o g _ m e s s a g e } " }

16 17 18 19 20 21 22

23 24 25

26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

13 14 15 16 17 18

a d d _ f i e l d => [ " r e c e i v e d _ a t " , "%{@timestamp } " ] a d d _ f i e l d => [ " r e c e i v e d _ f r o m " , "%{h o s t } " ]

} syslog_pri { } date { match => [ " syslog_timestamp " , "MMM d HH:mm: s s " , "MMM dd HH:mm: s s " ] 19 } 20 } mutate { 21 r e p l a c e => [ " @source_host " , " f i r e w a l l −name . ad . company . com " ] 22 r e p l a c e => [ " @message " , "%{message } " ] 23 remove => [ " s y s l o g _ m e s s a g e " , " syslog_timestamp " ] 24 } 25 kv { 26 s o u r c e => " @message " 27 } 28 } 29 30 output { 31 elasticsearch { 32 p r o t o c o l => " h t t p " input { 2 3 lumberjack { 4 p o r t => 5040 5 s s l _ c e r t i f i c a t e => / opt / backup / t e s t a / ca . c r t s s l _ k e y => / opt / backup / t e s t a / ca . key 6 type => s y s l o g # s t r i n g ( o p t i o n a l ) 7 } 8 } 9 filter { 10 i f [ type ] == " s y s l o g " { 11 grok { 12 match => { " message " => "%{SYSLOGTIMESTAMP: syslog_timestamp }

Projet Fin d’Etudes

73

2014-2015

5.8. INSTALLATION DU LOGSTASH-FORWARDER

chapitre 5

%{SYSLOGHOST: syslog_hostname } %{DATA: syslog_program } ( ? : \ [ % {POSINT : s y s l o g _ p i d } \ ] ) ? : %{GREEDYDATA: s y s l o g _ m e s s a g e } " } 13 a d d _ f i e l d => [ " r e c e i v e d _ a t " , "%{@timestamp } " ] 14 a d d _ f i e l d => [ " r e c e i v e d _ f r o m " , "%{h o s t } " ] 15 } 16 syslog_pri { } 17 date { 18 match => [ " syslog_timestamp " , "MMM d HH:mm: s s " , "MMM dd HH:mm: s s " ] 19 } 20 } mutate { 21 r e p l a c e => [ " @source_host " , " f i r e w a l l −name . ad . company . com " ] 22 r e p l a c e => [ " @message " , "%{message } " ] 23 remove => [ " s y s l o g _ m e s s a g e " , " syslog_timestamp " ] 24 } 25 kv { 26 s o u r c e => " @message " 27 } 28 } 29 31 elasticsearch { 32 p r o t o c o l => " h t t p " 33 h o s t => " 1 2 7 . 0 . 0 . 1 " 34 manage_template => f a l s e 35 i n d e x => " windows−%{+YYYY.MM. dd} " 36 } 37 s t d o u t { c o d e c => rubydebug } 38 } . / b i n / l o g s t a s h −f windows . c o n f

50 51 52 53 54 55 56 57 58

59 60 61

62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78

puis on installe logstash forwarder via la commande suivante 1 2 3

g i t c l o n e g i t : / / g i t h u b . com/ e l a s t i c s e a r c h / l o g s t a s h −f o r w a r d e r . g i t cd l o g s t a s h −f o r w a r d e r go b u i l d −o l o g s t a s h −f o r w a r d e r

par la suite on édite le fichier logstash-forward.conf 1 2 3 4 5

6 7 8 9 10

{ # The network s e c t i o n c o v e r s network c o n f i g u r a t i o n : ) " network " : { # A l i s t o f downstream s e r v e r s l i s t e n i n g f o r our me ssa ges . # l o g s t a s h −f o r w a r d e r w i l l p i c k one a t random and o n l y s w i t c h if # t h e s e l e c t e d one a p p e a r s t o be dead o r u n r e s p o n s i v e " s e r v e r s " : [ " b a r i d . ma: 5 0 4 3 " ] , # The path t o your t r u s t e d s s l CA f i l e . This i s used # t o a u t h e n t i c a t e your downstream s e r v e r . " s s l ca " : " / opt / backup / t e s t a / ca . c r t " ,

11 12

# Network t i m e o u t i n s e c o n d s . This i s most i m p o r t a n t f o r

Projet Fin d’Etudes

74

2014-2015

5.8. INSTALLATION DU LOGSTASH-FORWARDER

chapitre 5

# l o g s t a s h −f o r w a r d e r d e t e r m i n i n g whether t o s t o p w a i t i n g f o r an # acknowledgement from t h e downstream s e r v e r . I f an t i m e o u t i s reached , # l o g s t a s h −f o r w a r d e r w i l l assume t h e c o n n e c t i o n o r s e r v e r i s bad and # w i l l c o n n e c t t o a s e r v e r c h o s e n a t random from t h e s e r v e r s list . " t i m e o u t " : 15 },

13

14

15

16

17 18 19

# The l i s t o f f i l e s c o n f i g u r a t i o n s " files ": [ # An a r r a y o f h a s h e s . Each hash t e l l s what p a t h s t o watch and # what f i e l d s t o a n n o t a t e on e v e n t s from t h o s e p a t h s . { " paths " : [ # s i n g l e paths are f i n e " / var / l o g / m ess age s " , # g l o b s a r e f i n e too , they w i l l be p e r i o d i c a l l y e v a l u a t e d # t o s e e i f any new f i l e s match t h e w i l d c a r d . " / var / l o g / ∗ . l o g " ],

20 21 22 23 24 25 26 27 28 29 30 31 32

# A d i c t i o n a r y o f f i e l d s t o a n n o t a t e on each e v e n t . " f i e l d s " : { " type " : " s y s l o g " } }, { # A path o f " −" means s t d i n . " p a t h s " : [ "−" ] , " f i e l d s " : { " type " : " s t d i n " } }, { " paths " : [ " / var / l o g / apache / httpd −∗. l o g " ], " f i e l d s " : { " type " : " apache " } }

33 34 35 36 37 38 39 40 41 42 43 44

]

45 46

}

ensuite on lance le service logstash-forward 1

. / l o g s t a s h −f o r w a r d −c o n f i g l o g s t a s h −f o r w a r d . c o n f

mais avant on doit générer une certificat et configurer DNS ou bien seulement on modifie le fichier /etc/hosts 1 2

c a t