Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
  
Université de Carthage
  
Institut National des Sciences
Appliquées et de Technologie

Projet de Fin d’Etudes

Pour l’obtention du

Diplôme National d’Ingénieur

en Sciences Appliquées et en Technologie

Filière : Réseaux Informatiques et Télécommunications

Sujet :
Sécurisation des flux et contenus avec la technologie
BlueCoat

Réalisé par : Dorra KESKES

Entreprise d’accueil :

2SB (Security Solution for Business)

Soutenu le 07/10/17

Président : M. Abderrazak JEMAI

Examinateur : M. Anis MOURALI
Responsable à l’INSAT: M. Raki HAMMAMI
Responsable à l’entreprise : M. Roshan MANDIL

Année Universitaire : 2016/2017

Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
  
Université de Carthage
  
Institut National des Sciences
Appliquées et de Technologie

Projet de Fin d’Etudes

Pour l’obtention du

Diplôme National d’Ingénieur

en Sciences Appliquées et en Technologie

Filière : Réseaux Informatiques et Télécommunications

Sujet :
Sécurisation des flux et contenus avec la technologie
BlueCoat

Réalisé par : Dorra KESKES

Entreprise d’accueil :

2SB (Security Solution for Business)

Soutenu le 07/10/17

Responsable à l’entreprise : Responsable à l’INSAT :

Prénom et NOM: Roshan MANDIL Prénom et NOM: Raki HAMMAMI

(Cachet & Signature obligatoires) (Signature obligatoires)

Année Universitaire : 2016/2017

 Dédicaces

Je dédie ce modeste travail, symbole de ma profonde gratitude et couronnement

de leur assistance à…

Mes très chers parents Hassène et Leila

Pour avoir été, les épaules solides, le réconfort moral et les personnes les plus dignes de
mon estime et de mon respect.

A mes sœurs Donia et Hind

Pour leur soutien, leur encouragement, et leur affection sans égale.

A ma tendre famille
Pour leur bienveillance et amour

A mes adorables amis

Pour tous les moments agréables que j’ai passés avec eux et pour leur présence continue
dans ma vie.

A toutes les personnes

Qui me sont chères, qui ont cru en moi et à toutes celles qui veulent partager ma réussite
et mon bonheur

Keskes Dorra
 Remerciements

Avant tout, J’exprime mes sincères reconnaissances à l’égard de tous ceux qui ont contribué à ma
formation.

En gratitude et témoignage de ma profonde reconnaissance, je tiens à remercier toutes les personnes

qui ont participé de près ou de loin au bon déroulement de mon stage au sein de la société 2SB
(Security Solution for Business), pour l’expérience enrichissante et pleine d’intérêt qu’elles nous ont
fait vivre durant ces six mois de stage, notamment :

Monsieur Fayçal KABANI, pour m’avoir accepté en stage au sein de son entreprise, pour m’avoir fait
confiance, et pour m’avoir permise d’intervenir auprès des clients de 2SB et d’assister aux différentes
formations dont j’ai pu bénéficier.

Monsieur Roshan MANDIL mon encadrant de stage qui a dirigé mon projet de fin d’études, pour son
engagement permanent, son soutien sans faille, ses conseils et explications et la confiance totale qu’il
m’a accordée.

Je leur exprime mes profonds remerciements pour cette coopération professionnelle.

J’adresse aussi mes profonds remerciements à Monsieur Raki HAMMAMI, mon encadrant au sein de
l’INSAT, pour son encadrement, son soutien, sa disponibilité et ses conseils qui m’ont guidé tout au
long de mon stage.

Je tiens, par ailleurs, à exprimer ma profonde gratitude et mon immense reconnaissance à :

Monsieur JEMAI Abderrazak, pour l’honneur qu’il a bien voulu me faire en acceptant de présider le
jury chargé d’évaluer ce travail.

Et Monsieur MOURALI Anis, d’avoir accepté d’examiner ce travail.

Toutefois, il faut souligner que ce travail n’aurait pu voir le jour sans la formation et le savoir-faire
acquis durant mon cursus universitaire au sein de l’Institut National des Sciences Appliquées et de
Technologie. C’est donc avec une énorme reconnaissance que j’adresse mes remerciements les plus
sincères à tous mes enseignants.

J’espère que le présent projet sera à la hauteur de vos attentes.

 Table des matières

Introduction générale ........................................................................................................................................ 1

Chapitre1 : Cadre général et concepts de base .............................................................................................. 3

1 Présentation générale ............................................................................................................................ 4

1.1 Organisme d’accueil ...................................................................................................................... 4

1.2 Présentation du projet .................................................................................................................. 6

2 Concepts de base : Sécurisation des flux et contenus ...................................................................... 9

2.1 Flux et contenus web .................................................................................................................... 9

2.2 Risques et attaques liés à l’accès internet ................................................................................... 9

2.3 Les menaces potentielles (Advanced Threats) ........................................................................13

2.4 Méthodologie des attaques et Stratégies de protection .........................................................15

2.5 Sécurisation dynamique des points d’accès internet ..............................................................17

Chapitre2 : Etude de l’existant et spécification des besoins ......................................................................19

1 Analyse de l’existant ............................................................................................................................19

1.1 Architecture de l’entreprise ........................................................................................................20

1.2 Les principaux équipements de sécurité ..................................................................................20

2 Critique de l’existant............................................................................................................................21
3 Spécifications des besoins ..................................................................................................................21
3.1 Les besoins fonctionnelles .........................................................................................................22

3.2 Les besoins non fonctionnels ....................................................................................................23

4 Identification des acteurs....................................................................................................................23

5 Modélisation des besoins....................................................................................................................24
5.1 Diagramme de cas d'utilisation .................................................................................................24

5.2 Description de quelques cas d'utilisation .................................................................................25

Chapitre3 : Etude de la solution de sécurisation des flux et de leurs contenus ......................................26

1 Conception et étude des solutions du marché ................................................................................27

1.1 Conception globale .....................................................................................................................27

1.2 Conception détaillée ...................................................................................................................28

1.3 Etude comparative des solutions existantes ............................................................................32

1.4 Choix du client ............................................................................................................................35

2 Présentation du ProxySG de BlueCoat ............................................................................................36

2.1 Les fonctionnalités du ProxySG ...............................................................................................36

2.2 Les architectures supportées......................................................................................................37

2.3 Authentification...........................................................................................................................38

2.4 Application de la politique de sécurité .....................................................................................39

2.5 Analyse des flux SSL ...................................................................................................................41

2.6 Optimisation des performances ................................................................................................42

2.7 Protection contre les attaques DOS .........................................................................................42

2.8 Logs d’accès .................................................................................................................................42

3 Présentation du service Cloud « Web Security Service » de BlueCoat.........................................43

3.1 Définir le service Sécurité Web en Cloud ................................................................................43

3.2 Fonctionnalités du Web Security Service ................................................................................44

3.3 Les modes de déploiement du service Cloud WSS : ..............................................................45

3.4 Gestion des politiques de sécurité ............................................................................................47

3.5 Accès Logs : Tableau de bord en temps réel ..........................................................................47

Chapitre4 : Mise en place de la solution .......................................................................................................49

1 Environnement de travail et dimensionnement de l’architecture cliente ....................................50

1.1 Environnement de travail ..........................................................................................................50

1.2 Dimensionnement de l’architecture cliente .............................................................................50

2 Mise en place de l’architecture hybride ............................................................................................51

2.1 Architecture cible avec les équipements BlueCoat.................................................................51
 2.2 Choix technologiques et leurs mise en place...........................................................................53

2.3 Couplage du service Cloud avec le CASB d’Elastica .............................................................67

3 Mise en place d’un tunnel IPsec/VPN vers le Cloud. ...................................................................68

3.1 Architecture réseau du site de Lyon .........................................................................................68

3.2 Description du problème ...........................................................................................................69

3.3 Description de la solution : ........................................................................................................70

Chapitre5 : Tests et validation ........................................................................................................................72

1 Vérification de la configuration du ProxySG ..................................................................................72

2 Vérification de la mise en place de la solution ................................................................................73
2.1 Vérification de la mise en place d’une architecture hybride..................................................73

2.2 Vérification de la mise en place de l’authentification des utilisateurs ..................................77

2.3 Vérification de la mise en place d’un filtrage par catégorie / applications .........................79

2.4 Vérification de la mise en place de l’interception SSL. ..........................................................81

2.5 Vérification de la gestion de la bande passante ......................................................................82

2.6 Vérification de la traçabilité des historiques d’accès. .............................................................83

2.7 Vérification de la configuration des fonctions de sécurisation contre les attaques DOS .83

3 Vérification du couplage du Service de Sécurité Web avec un CASB .........................................84

Conclusion générale.........................................................................................................................................86

Bibliographies et Webographies ....................................................................................................................87

 Liste des Acronymes

AD: Active Directory

AES: Advanced Encryption Standard
API: Application Programming Interface
APT: Advanced Persistent Threat
AV: Antis Virus
BCAAA: Blue Coat Authentication and Authorization Agent
CA: Certificate Authority
CASB: Cloud Access Security Broker
CN: Common Name
CSS: Cross-Site Scripting
DDOS: Distributed Deny Of Service
DLP: Data Loss Prevention
DMZ: Demilitarized Zone
DNS: Domain Name System
DOS: Deny Of Service
DSI: Directeur du Système d’Information
ELFF: Extended Log File Format
FTP: File Transfer Protocol
GIN: Global Intelligence Network
GPO: Group Policy Object
HTML: HyperText Markup Language
HTTP(S): HyperText Transfer Protocol (Secure)
ICMP: Internet Control Message Protocol
IDS: Intrusion Detection System
IPS: Intrusion Prevention System
IWA: Integrated Windows Authentication
KDC: Key Distribution Center
LAN: Local Area Network
LDAP: Lightweight Directory Access Protocol
MPLS: MultiProtocol Label Switching
NTLM: New Technology Lan Manager
NTP: Network Time Protocol
PAC: Proxy Auto-Configuration File
PHP: Hypertext Preprocessor
PKI: Public Key Infrastructure
PPPoE: Point-to-Point Protocol over Ethernet
PSK: Pre-Shared Key
RAM: Read Access Memory
RFC: Requests For Comments
RH: Ressources Humaines
SGOS: Secure Gateway Operating System
SIEM: Security Information Management System
SQL: Structured Query Language
SSH: Secure SHELL
SSL: Secure Sockets Layer
SSO: Single Sign-On
TCP: Transmission Control Protocol
UDP: User Datagram Protocol
URL: Uniform Resource Locator
VPM: Visual Policy Manager
VPN: Virtual Private Network
WAN: Wide area network
WSA: Web Security Appliance
WSS: Web Security Service
XML: eXtensible Markup Language
 Table des figures

Figure 1: Logo de 2SB ....................................................................................................................................... 4

Figure 2: Organigramme de l'entreprise ......................................................................................................... 6
Figure 3: Diagramme de Gantt ........................................................................................................................ 9
Figure 4: Forward Proxy .................................................................................................................................18
Figure 5: Reverse Proxy ..................................................................................................................................18
Figure 6: Architecture existante de l'entreprise ...........................................................................................20
Figure 7: Diagramme de cas d'utilisation de la solution à concevoir .......................................................24
Figure 8: Architecture globale de la solution envisagée .............................................................................28
Figure 9: Diagramme de séquence pour l'utilisateur du site central .........................................................29
Figure 10: Diagramme de séquence pour l'utilisateur du site Lyon ..........................................................30
Figure 11: Diagramme de séquence pour l'utilisateur du site Toulouse ..................................................31
Figure 12: Diagramme de séquence pour un utilisateur nomade..............................................................32
Figure 13: Comparaison des solutions existantes ........................................................................................35
Figure 14: Mode Proxy Explicite ...................................................................................................................37
Figure 15: Mode Proxy Transparent .............................................................................................................38
Figure 16: Schématisation de la catégorisation des applications ...............................................................39
Figure 17: Architecture simplifiée du déchiffrement des flux SSL ...........................................................41
Figure 18: Schématisation du réseau de Datacenters du service WSS .....................................................43
Figure 19: Vue générale des modes de déploiement du WSS....................................................................45
Figure 20: Schématisation de la gestion des politiques de sécurité ...........................................................47
Figure 21: Aperçu du tableau de bord du WSS ...........................................................................................48
Figure 22: Dimensionnement du ProxySG ..................................................................................................50
Figure 23: Architecture cible avec les équipements BlueCoat ...................................................................51
Figure 24: Interface de gestion du ProxySG ................................................................................................52
Figure 25: configuration du ProxySG en mode Reverse............................................................................52
Figure 26: Interface de gestion du service Cloud ........................................................................................53
Figure 27: Création des hébergeurs pour le chainage du trafic vers le Cloud .........................................54
Figure 28: Mise en place de la politique de redirection du trafic ..............................................................55
Figure 29: Ajout de la localisation du site de Paris au niveau du WSS.....................................................55
Figure 30: Paramétrage du Tunnel IPSec/VPN au niveau de fortinet ....................................................56
Figure 31: Ajout de la localisation du site de Lyon au niveau du WSS ....................................................56
Figure 32: Ajout de la localisation du site de Toulouse au niveau du WSS .............................................57
Figure 33: Description du fonctionnement d'un IWA BCAAA ...............................................................58
Figure 34: Configuration de l’IWA BCAAA avec kerberos ......................................................................59
Figure 35: Définition d'une politique pour l'authentification BCAAA ....................................................59
Figure 36: Configuration du Auth_Connector ............................................................................................60
Figure 37: Mise en place d'une règle de filtrage par catégorie ...................................................................61
Figure 38: Mise en place d'une règle de filtrage par application................................................................61
Figure 39: Définition d'une politique de sécurité pour l’affichage de la page d'exception ....................62
Figure 40: Configuration des services pour l'interception des flux SSL ..................................................62
Figure 41: Création d'un certificat de confiance auto-signé par le ProxySG ..........................................63
Figure 42: Règle de sécurité pour l'interception SSL du trafic ..................................................................63
Figure 43: Configuration de l'interception SSL au niveau du service Cloud ...........................................64
Figure 44: Mise en place du caching .............................................................................................................64
Figure 45:Mise en place de la page de coaching ..........................................................................................65
Figure 46: Activation de la traçabilité des évènements...............................................................................66
Figure 47: Définition d'une politique de sécurité pour mettre en place la traçabilité ............................66
Figure 48: Sécurisation du client contre une attaque DOS ........................................................................67
Figure 49: Sécurisation du Serveur contre une attaque DOS ....................................................................67
Figure 50: Intégration du module CASB au service Cloud........................................................................68
Figure 51: Architecture simplifiée du réseau du site de Lyon ...................................................................69
Figure 52: Architecture simplifiée de la solution apportée au réseau du site de Lyon...........................70
Figure 53: Ajout de l'interface logique au niveau du firewall.....................................................................70
Figure 54: Configuration du protocole PPPoE sur l'interface logique ....................................................71
Figure 55: Vérification de la bonne configuration du ProxySG ...............................................................73
Figure 56: Vérification de la connectivité côté WSS ...................................................................................73
Figure 57: Vérification de la connectivité côté client (Paris) .....................................................................74
Figure 58: Vérification de la connectivité côté WSS ...................................................................................74
Figure 59: Vérification de la connectivité côté fortinet ..............................................................................74
Figure 60: Vérification de la connectivité côté Client Lyon ......................................................................75
Figure 61: Vérification de la connectivité côté WSS ...................................................................................75
Figure 62: Vérification de la connectivité côté client Toulouse ................................................................76
Figure 63: Vérification de la connectivité de l'Unified Agent....................................................................76
Figure 64: Vérification de la connectivité du client nomade .....................................................................77
Figure 65: Vérification de la configuration de l'authentification ...............................................................78
Figure 66: Connectivité de l'agent d'authentification..................................................................................78
Figure 67: Synchronisation entre l'AD et le « Auth_Connector » ............................................................79
Figure 68: "Pop-up" d'authentification au service WSS .............................................................................79
Figure 69: Filtrage par catégorie ....................................................................................................................80
Figure 70:Filtrage par application ..................................................................................................................80
Figure 71: Page d'exception pour une URL non catégorisée ....................................................................81
Figure 72: Vérification de l'interception SSL au niveau du ProxySG ......................................................81
Figure 73: Vérification de l'interception SSL au niveau du service Cloud...............................................82
Figure 74: Vérification d'apparition de la page de coaching ......................................................................82
Figure 75: Vérification de l'activation de la traçabilité ................................................................................83
Figure 76: Vérification de l'atteinte de la limite de connexion ..................................................................83
Figure 77: Vérification que l'adresse ip est bloquée au niveau du ProxySG ...........................................84
Figure 78: vérification du couplage du WSS avec le CASB .......................................................................84
 Table des tableaux

Tableau 1: Tableau descriptif de quelques cas d'utilisation ....................................................................... 25

Tableau 2: Tableau comparatif des solutions existantes sur le marché ................................................... 35
Tableau 3: Tableau de spécification des rôles du Control et Data POD ................................................ 44
 Introduction générale

Aujourd’hui, la connectivité à Internet ne cesse de s’étendre non seulement auprès des grandes
entreprises mais aussi auprès du public (particuliers) et des organisations. On s’aperçoit que dès lors le
paradigme informatique change, la protection des organisations, du gouvernement et des citoyens
contre les logiciels malveillants devient un défi car les attaques sont d’une part de plus en plus
sophistiquées et d’autre part très dynamiques.
En effet, Les premières activités malicieuses avaient pour but de détruire les données par contre les
logiciels malveillants actuels se focalisent, désormais, sur le vol des données sensibles et autres activités
illicites.
Malgré l'existence de solutions de sécurité traditionnelles, les entreprises constatent des augmentations
des équipements défectueux. Cependant, ils ne sont généralement pas en mesure de localiser la source
de la menace avec précision et de prendre les actions correctives correspondantes.
Aussi, l’accélération du télétravail et la mobilité complique la capacité des responsables informatiques
à soutenir efficacement et à protéger les utilisateurs finaux en dehors de l’entreprise.
De plus, L'année dernière, les menaces Web ont augmenté de plus de 500%, le volume des variantes
de code malveillant augmentant de près de 300% et des attaques de phishing de 600%. Et ils évoluent
constamment. 90% des menaces Web proviennent désormais de sites Web fiables et plus de 40% des
menaces de codes malveillants ciblent les navigateurs Internet plutôt que les systèmes d'exploitation
sous-jacents, ce qui a été la cible traditionnelle. En outre, l'ampleur et la nature dynamique de tous les
organismes de services Web 2.0 et Cloud signifient que les attaques réussies contre ces services peuvent
se propager plus rapidement et avoir un impact plus large.
Pour lutter contre ce paysage de menaces énormes, des couches de sécurité supplémentaires s’imposent
pour fournir une diversité de protection pour prévoir les nouveaux risques et optimiser le niveau de
sécurité.
C’est dans ce cadre que s’articule notre projet de fin d’étude intitulé mettre en place une solution pour la
sécurisation des flux et des contenus d’une entreprise.
Le présent rapport qui détaille notre contribution, se compose de Cinque chapitres.
Un premier chapitre qui permet de délimiter le cadre du projet entre la présentation de l’organisme
d’accueil et la mise du sujet dans son contexte. Un deuxième chapitre conçu à base d’analyses qui nous
1
ont menés à la rédaction des besoins fonctionnels et des choix techniques. Ensuite, le troisième
chapitre de conception sert à exposer l’architecture de la solution et de présenter les différentes
technologies que nous avons utilisées. Un quatrième chapitre viendra démontrer les réalisations
effectuées pour aboutir à la solution finale qui a été intégrée, mise en service et testée. Et nous
concluons ce rapport par un cinquième chapitre pour valider le travail effectué et répondre aux
exigences de notre client.

2
 Chapitre 1

Cha pitre1 : Cadre général et concepts de base

Plan
1 Présentation générale............................................................................................................................ 4
1.1 Organisme d’accueil ..................................................................................................................... 4

1.2 Présentation du projet .................................................................................................................. 6

2 Concepts de base : Sécurisation des flux et contenus ..................................................................... 9

2.1 Flux et contenus web ................................................................................................................... 9

2.2 Risques et attaques liés à l’accès internet................................................................................... 9

2.3 Les menaces potentielles (Advanced Threats) ....................................................................... 13

2.4 Méthodologie des attaques et Stratégies de protection ......................................................... 15

2.5 Sécurisation dynamique des points d’accès internet .............................................................. 17

Introduction

L’étude préliminaire est la première phase de tout projet réussi. Elle consiste à bien positionner le
projet. Ainsi, ce premier chapitre va servir dans un premier temps à la description du contexte général,
définissant l’organisme d’accueil, ses activités, ses fonctionnalités, et son domaine de travail. Nous
aborderons, ensuite, le cadre de notre projet, nos objectifs et la méthodologie à suivre. Dans un
deuxième temps nous allons effectuer une étude préalable des notions de bases pour comprendre
l'aspect général du projet.

3
1 Présentation générale
1.1 Organisme d’accueil

Figure 1: Logo de 2SB

1.1.1 Le secteur d’activité

L'industrie de la sécurité informatique est a vu le jour grâce à la non sureté des produits et services
informatiques. Les entreprises compétitives savent que la sécurité des infrastructures, des applications
et des données de même que la protection des identités constituent l’un des piliers de leur réussite.
Cependant l’évolution rapide des technologies, la pression accrue du marché, et la sophistication
croissante des actes de piratage informatique, incitent les organisations informatiques à aller au-delà de
la simple mise en conformité et de miser sur la défense proactive. Et aujourd’hui c’est exactement où
2SB intervient.
1.1.2 L’entreprise
2SB est une société crée en 2001, grossiste de solutions de sécurité informatique faisant de la vente
indirecte. L’entreprise fournit des produits de sécurité informatique mondialement reconnus, tout en
offrant des solutions innovantes et adaptées aux besoins d’aujourd’hui. En outre, les spécialistes des
solutions de sécurité de 2SB capitalisent sur plusieurs années d’expérience, sur leurs solides
connaissances sectorielles et leur expertise des processus métier pour aider les entreprises à se protéger
des menaces, limiter les risques et adopter les nouvelles technologies nécessaires à leur croissance. La
mise en œuvre de solutions complètes de sécurité permet ainsi aux organisations:
 d’accroître la valeur tout en réduisant les risques et les coûts
 d’atteindre les objectifs de conformité
 d’augmenter la productivité
 d’accroître la confiance des clients en protégeant les informations et les systèmes des
différentes menaces et divers risques de piratage informatique
Les avantages 2SB incluent aussi (mais ne sont pas limités à) :
 L'engagement de fournir à ses clients et partenaires les meilleures offres en termes de services
et de produits de sécurité.
 Des programmes et pratiques de partenariat élaborés

4
  Un support technique de haute qualité assuré par des spécialistes ayant à leur actif plusieurs
années d'expériences.
 Un support commercial au service des revendeurs avec un apport régulier d'affaires, un support
produit adapté et des possibilités de prêts de matériel.
 Une logistique performante à votre service, suivi de commandes et factures.
Le métier de grossiste en tant que tel est basé essentiellement sur la revente de produits des fournisseurs
mais ne se limite pas qu’à ça. L’entreprise 2SB tout en étant grossiste offre des valeurs ajoutées, en
proposant plusieurs services comme l’intégration à ses clients, qui le positionne aujourd’hui comme
l’un des leadeurs du marché. [1]
1.1.3 Positionnement de L’entreprise
Le positionnement généralement correspond à l'image que l’entreprise veut donner à son client et
concurrents de ses produits. Chaque entreprise à un positionnement particulier tout en prenant
compte:
 Les attentes, les spécificités et les besoins des cibles.
 Le positionnement des concurrents.
 Et les caractéristiques du produit (son avantage concurrentiel) et des capacités de l’entreprise.
2SB a mis en œuvre les moyens nécessaires pour permettre à l’entreprise de pénétrer durablement son
marché. Et il se trouve que 2SB se positionne, aujourd’hui, comme étant un des leadeurs du secteur.[1]
1.1.4 Gamme de produits et services proposés
2SB distribue des produits de sécurité informatique et on trouve dans leur portefeuille, des produits de
marques reconnues mondialement tel que BlueCoat ainsi que des solutions innovantes et adaptées aux
besoins d'aujourd'hui.
De la sélection des meilleures solutions de sécurité informatique à la formation de ses partenaires
revendeurs, 2SB aide les clients dans leurs processus d'intégration.
La société porte un effort particulier sur la notion de Service Client en leur apportant une approche
globale sur l’ensemble solution/environnement. [1]
2SB propose différents produits :
 Firewalls
 Cryptage et Gestion des VPNs
 Proxy
 Anti-virus
 Sondes de détection d’intrusion

5
  Analyseurs de logs
 Scanners de vulnérabilité
 Accélérateurs SSL et de flux
 Equilibreurs de charge
 Solutions d’administration centralisée
1.1.5 L’organigramme de l’entreprise

Directeur Général
"KABANI Fayçal"

Directrice
Direction Marketing Direction Financière Direction Technique
Commerciale
"DZEGO Falonne Line" "LAGARRE Caroline" "MANDIL Roshan"
"LAAROUSSI Hédia"

Stagiaire
"KESKES Dorra"

Figure 2: Organigramme de l'entreprise

1.2 Présentation du projet

Pour présenter le projet, nous commençons par exposer le contexte général ainsi que les différentes
problématiques. Puis, nous poursuivons par l’énoncé des différents objectifs de la solution à concevoir.
Nous finissons par la méthodologie à suivre et la planification du déroulement du projet.

1.2.1 Contexte du projet et problématiques

À une époque plus « simple », les employés disposaient d'un seul appareil pour se connecter via un
réseau unique à un centre serveur qui exécutait un nombre limité d'applications. Donc La protection
de l'utilisateur et des données se résumait à sécuriser l'infrastructure.
Aujourd’hui, cet espace s'est considérablement étendu, modifiant les exigences de sécurité pour
toujours.
En effet, La zone de sécurité ne cesse de s'étendre dans trois dimensions clés qui sont les équipements,
les réseaux, et les applications.

6
Les leaders technologiques dans ce domaine se focalisent plus que jamais sur une sécurité globale
intégrant le réseau interne, les services Cloud, les applications mobiles, et l’Internet des objets (IoT).
Les DSI et autres responsables ont besoin d'un nouveau modèle de sécurité qui mélange le Cloud et
les installations sur site pour maîtriser le chaos. La sécurisation des flux et des données sur site doit
être complétée par une sécurisation des flux et des données sur le Cloud.
Il n'est clairement plus possible de relier entre eux des dizaines de produits de point de sécurité qui
protègent des équipements individuels, des réseaux, et des applications.
Désormais, pour gérer la sécurité et la gouvernance de la génération Cloud, il faut une plateforme
réseau unifiée et une architecture de sécurité flexible. [2]
C’est dans ce contexte que plusieurs acteurs majeurs de la sécurité informatique mondiale se
positionnent pour proposer leurs solutions.
De ce fait, Une société Cliente a fait appel à 2SB vu les défaillances présentes dans son système
d'information et son architecture réseau.
 Absence de contrôle et de visibilité sur la totalité de ses sites (site central, sites distants,
utilisateurs nomades)
 Absence d’une politique de filtrage uniforme et centralisée
 Mauvaise gestion de la bande passante
 Absence d’analyse du trafic transitant depuis et vers le réseau de l’entreprise
1.2.2 Objectifs du projet
L’objet du stage que nous avons effectué, c’est précisément de répondre aux besoins de protéger les
utilisateurs et les données quel que soit l'appareil utilisé où qu'il soit dans le monde, quel que soit le
réseau utilisé sur site, sur internet, ou sur le Cloud et quelle que soit l'application utilisée partant du
contrôle des accès, la protection contre les menaces avancées, l'analyse des réseaux jusqu’à la sécurité
pour l'entreprise.
L'objectif est aussi de garantir la visibilité complète, l'application des politiques en vigueur, et
l’inspection détaillée de la charge pour protéger les utilisateurs et les données, même en cas de
chiffrement, sur n’importe quel terminal (mobile, véhicule connecté, site Internet connecté, ou centre
de données)et en conservant ce contrôle tout en migrant en partie vers le Cloud en toute sécurité .
1.2.3 Planification du déroulement du projet
Les différentes tâches et responsabilités incluent :
 l'analyse des besoins et des contraintes,
 l’étude des technologies existantes,

7
  la spécification des architectures et des solutions de sécurisation,
 la réalisation des maquettes,
 la validation des produits,
 la qualification des solutions,
 la réalisation des présentations et des démonstrations techniques,
 la rédaction des documentations,
 la contribution aux réponses aux cahiers des charges,
 le support technique
Pour accompagner le client dans la gestion de ce projet d’intégration ambitieux et complexe, La
méthodologie était de s’appuyer sur trois phases du métier d’intégration :
 Phase1 : phase de conception
Cette phase comporte différentes réunions techniques avec le client. Ces réunions vont
permettre de se mettre d’accord sur la solution adéquate et sur les différents impacts de cette
solution sur le fonctionnement du réseau. La réunion d’initialisation avec le client a pour
objectif de présenter l’équipe de projet ainsi que le planning et les différentes étapes de
déroulement du projet. Parallèlement à ces réunions, l'équipe de projet met en place une
maquette de l’architecture cible pour tester et valider le fonctionnement de la nouvelle solution.
 Phase2 : phase d’intégration et de déploiement
Cette phase consiste à livrer les différents équipements utilisés dans le projet, à installer
physiquement les différents équipements (installation dans la Baie, câblage, etc.) puis à mettre
en place la nouvelle solution (configuration des équipements, tests, etc.). Cette phase représente
la phase la plus importante du projet et son bon déroulement est décisif.
 Phase3 : phase de validation
Cette phase consiste à s’assurer du bon fonctionnement de la solution mise en place.
Afin de modéliser cette organisation, nous allons présenter le planning que nous avons suivi pendant
la réalisation du projet.
Ce projet est divisé en 6 étapes :
- Etape 1 : Documentation et recherche préliminaires.
- Etape 2 : Analyse des besoins du client et conception de la solution de sécurisation des flux et
des contenus.
- Etape 3 : Mise en place de la solution

8
 - Etape 4 : Test et validation de la solution
- Etape 5 : Rédaction des documents d’exploitation
- Etape 6 : Rédaction du rapport

Figure 3: Diagramme de Gantt

2 Concepts de base : Sécurisation des flux et contenus

2.1 Flux et contenus web
2.1.1 Flux web
Le trafic Web est la quantité de données envoyées et reçues par les visiteurs sur un site Web. [3]
2.1.2 Contenu web
Le contenu Web se réfère au contenu textuel, auditif ou visuel publié sur un site web. C’est à dire tout
élément créatif (texte, applications, images, messages électroniques archivés, données, e-services,
fichiers audio et vidéo, etc.).
Donc, le contenu Web est la clé derrière la génération de trafic vers les sites Web. [4]
2.2 Risques et attaques liés à l’accès internet
2.2.1 Définition du risque
Un risque est un événement susceptible de se produire. Selon la nature physique, on peut classer les
risques en plusieurs catégories dont voici quelques-unes : Accident, perte de services, vols, fuites
d'information.
2.2.2 Définition d’une attaque
Une attaque est une activité malveillante qui consiste à exploiter une faille d'un système informatique
(serveurs, routeurs, système d'exploitation, logiciel, etc.) à des fins non connues. Les attaques sont
souvent menées suite aux motivations diverses [5]
 Perturbation du bon fonctionnement d'un système ou d'un service
 Vol des informations sensibles (données bancaires par exemple)
 Utilisation des ressources du système à d'autres fins.

9
 2.2.3 Risques et types d’attaques liés au aux flux entrants
2.2.3.1 L’attaque déni de service (DoS : Deny of Service)
L’attaque DoS vise à saturer un réseau et rendre indisponible un système et les services associés.
Dans ce type d’attaque, l’attaquant utilise un ou plusieurs systèmes informatiques pour forcer la
surcharge d’un système ciblé hors ligne avec un trafic inutile.
Une telle attaque peut rendre un site web ou des services injoignables pendant longtemps ce qui aura
pour cause la perte potentielle de clients, et ainsi des conséquences désastreuses pour les entreprises.
Les attaques par déni de service peuvent être effectuées selon différents méthodes :
 Ping Flood (ICMP Flood) : Le principe de cette attaque est :
- envoyer des « ICMP echo requests » à un grand nombre d’hôtes en utilisant une adresse de
broadcast, et ayant comme adresse IP source celle de la victime.
- Les « ICMP echo reply » vont donc être dirigés vers la victime et ainsi rapidement épuiser
la bande passante du réseau, cela empêchera alors les paquets légitimes de passer vers leur
destination.
 SYN/TCP Flood : Le principe de cette attaque est :
- envoyer une multitude de paquets TCP avec le flag SYN ayant une adresse source falsifiée
à une victime pour saturer un serveur.
- Chaque paquet correspond à une demande de connexion, d’où l’ouverture de plusieurs
connexions ‘half-opened’, en renvoyant un paquet TCP/SYN-ACK (Acknowledge) à
l’adresse IP source falsifiée.
- La victime reste en attente d'un paquet en réponse qui ne viendra jamais provenant de
l'adresse IP de l'expéditeur.
- Les connexions ‘half-opened’ saturent donc le nombre de connexions que le serveur est
capable de faire, l'empêchant ainsi de répondre aux demandes légitimes jusqu'à la fin de
l'attaque.
 UDP Flood : Le principe de cette attaque est :
- envoyer une multitude de paquets UDP ayant une adresse source falsifiée à destination de
ports aléatoires sur un hôte distant. Le trafic UDP étant prioritaire sur le trafic TCP, ce
type d'attaque peut vite troubler et saturer le trafic transitant sur le réseau.
- En conséquence l’hôte distant va vérifier quelles applications écoutent sur ces ports, il va
se rendre compte qu’aucunes applications n’écoutent sur ces ports et va donc répondre à

10
 l’expéditeur avec des paquets ‘ICMP Destination Unreachable’. Ainsi, pour un grand
nombre de paquets UDP, le système victime sera contraint à répondre par un grand
nombre de paquets ICMP et finalement être injoignable par d'autres clients. Généralement
les attaquants usurpent l'adresse IP des paquets UDP pour veiller à ce que les paquets de
retour ICMP excessives ne les atteignent. [6]
2.2.3.2 L’attaque par virus et codes malicieux
Le virus est un morceau de code logiciel avec la possibilité unique de se multiplier et de se propager
sur d'autres ordinateurs et qui a pour but de consommer ou paralyser les ressources système.
Les virus sont de plus en plus évolués, ils peuvent s'auto modifier pour échapper à une éventuelle
détection (virus polymorphes). D'autres types peuvent tenter de leurrer le système en s'installant dans
des secteurs défectueux ou non utilisés (virus furtifs).
Le code malveillant en général se réfère à des programmes informatiques qui sont écrits spécifiquement
pour causer des dommages aux ordinateurs qui y sont infectés. [6]
2.2.3.3 Chevaux de Troie
Le cheval de Troie est une autre forme de code malveillant. Il est similaire à un virus par la façon dont
il est transmis. Cependant, contrairement à un virus, un cheval de Troie ne se réplique pas. Plutôt, il
reste dans la machine cible, infligeant des dégâts ou de permettre à quelqu'un sur un site distant de
prendre le contrôle de l'ordinateur.
Un cheval de Troie se fait passer souvent comme un programme légitime mais, une fois installé sur la
machine de la victime, il effectue des activités illicites et destructrices. En général, le but d’un cheval
de Troie est de créer une porte dérobée (backdoor) pour qu’un pirate informatique puisse ensuite
accéder facilement l’ordinateur ou le réseau informatique. Il peut alors voler des mots de passe, copier
des données ou exécuter des actions nuisibles. [6]
2.2.3.4 Les vers
Le ver est connu comment étant un autre type de code malveillant. C’est un type de virus qui peut se
reproduire à travers tous les différents nœuds ou connexions qui composent le réseau. Les vers peuvent
contenir des charges nuisibles mais généralement ils causent la plupart de leurs dommages en
s’attachant au réseau et ainsi utilisent les ressources précieuses telles que la mémoire et le temps de
traitement des processeurs. Par conséquent ils ralentissent voir même paralysent complètement le
réseau d’une entreprise. [6]

11
 2.2.3.5 Les applications web vulnérables
Une vulnérabilité dans une application est généralement un défaut du système ou d’une faiblesse dans
l’application qui pourrait être exploitée pour compromettre la sécurité de l'application.
Une fois que l'attaquant a trouvé une faille et a déterminé comment y accéder, l'attaquant a la possibilité
d'exploiter la vulnérabilité dans l’application pour compromettre la confidentialité et l'intégrité des
ressources possédées par l’application, ses créateurs et ses utilisateurs. Les pirates s'appuient
généralement sur des outils ou des méthodes spécifiques pour découvrir les vulnérabilités dans les
applications web.
 SQL injection : Les failles SQL donnent la possibilité d’injecter du code dans les requêtes SQL
qui sont appelées sur une page web. Les conséquences d'une faille SQL peuvent être multiples,
du contournement de formulaires d'authentification au dump complet de la base de données
en passant par l'exécution arbitraire de code.
Dans le plus simple et général des cas une application est vulnérable aux attaques de ce
type quand elle permet aux potentiels attaquants d’interagir avec la base de données et
d’exécuter des requêtes arbitraires.
 Cross Site Scripting (XSS) : Cross Site Scripting (XSS également connu sous le nom de CSS)
est considéré comme l'une des techniques les plus courantes de piratage de la couche
application. Cette technique permet à un attaquant d'intégrer un code malveillant JavaScript,
VB Script ou HTML dans le code source d’une page web dynamique vulnérable dont le but
est de tromper l’utilisateur. L'exécution du script sur sa machine permet à l’attaquant de:
- Recueillir des informations privées
- Rediriger l'utilisateur vers un autre site sous son contrôle
- Voler les cookies
- Exécuter du code malveillant sur les systèmes des utilisateurs finaux.
 File Inclusion : Dans ce type d’attaque attaque, l’attaquant exécute son propre code sur une
page web vulnérable. L’attaque implique une importation du code dans un programme en
profitant du fait que ce programme ne procède à aucune vérification et validation de ses
entrées. Si un attaquant arrive à inclure son propre code malveillant sur une page web, il est
possible de ‘convaincre’ un script PHP d’inclure un fichier distant au lieu d'un fichier du
système de fichiers local.
Comme nous le voyons il existe beaucoup de types d’attaques qui sont associés aux flux entrants dans
une entreprise et qui peuvent avoir des conséquences désastreuses. Les entreprises doivent dès lors
12
mettre en œuvre les moyens efficaces pour lutter contre ces attaques. Cependant les attaques ne se
limitent pas qu’aux flux entrants. [6]
2.2.4 Risques et types d’attaques liés au aux flux sortants
La préoccupation d’un administrateur réseau/sécurité au sein d’une entreprise est le périmètre de son
réseau. Dans la plupart des cas, les entreprises dépensent beaucoup de temps à se protéger contre les
trafics qui pourraient entrer dans leurs réseaux alors qu’elles ne consacrent pas assez de temps aux
trafics qui pourraient quitter leurs réseaux. Or, les risques associés à ces trafics sortants sont aussi
important que ceux liés aux flux entrants.
S'il n'y avait qu'une seule raison qui faisait clairement ressortir la nécessité de filtrer le trafic sortant
tout comme les entreprises filtrent les flux entrants, alors la raison serait les attaques de déni de service
distribué (DDoS). Des entreprises qui ont des flux sortants non filtrés sont très susceptibles de devenir
un participant d’un tel type d’attaque. Mais les attaques DDoS ne sont pas la seule raison pour filtrer
les flux sortants.
Dans le cas des connexions sortantes, les risques potentiels comprennent toutes les variantes des
logiciels installés sur chaque machine capable de faire les connexions sortantes. Cela comprend des
technologies telles que Flash, programmes FTP, Google Chrome, Internet Explorer, Adobe Acrobat,
Mozilla Firefox, entre autres.
Pour lutter contre ces différents types d’attaques liées aux flux entrants et sortants que nous avons
vues, les entreprises ont recours à des solutions de sécurités traditionnelles. Ces solutions de sécurités
sont très efficaces pour contenir ces types attaques. Néanmoins ces solutions traditionnelles basées sur
les signatures sont inefficaces contre les menaces avancées (Advanced Threats) car elles ne disposent
de signatures connus pour les détecter. [6]
2.3 Les menaces potentielles (Advanced Threats)
2.3.1 Définition d’une menace avancée
La menace informatique est le résultat de diverses actions susceptibles de nuire dans l’absolu à un
système informatique en provenance de plusieurs origines.
Une menace avancée « Advanced Persistent Threat (APT) », comme on les appelle, est une attaque
réseau dans laquelle une personne non autorisée obtient l’accès à un réseau et reste inaperçue pendant
une longue période. L’intention derrière une telle attaque est de voler des données plutôt que de causer
des dommages au réseau ou à l’entreprise. [7]

13
 2.3.2 Les menaces avancées
Les attaques APT visent surtout les entreprises, qui traitent des informations à forte valeur ajoutée,
comme la défense, le secteur financier, entre autres.
Dans une attaque basique, l'intrus essaie d'entrer et de sortir le plus rapidement possible afin d'éviter
d’être détecté par des systèmes de détection d'intrusion réseau (IDS). Alors que pour une attaque APT,
l'objectif n'est pas d'entrer et de sortir, mais d’assurer un accès continu. Pour éviter d’être détecté,
l'intrus doit constamment réécrire le code et employer des techniques d'évasion sophistiquées.
Les caractéristiques des attaques APT sont :
 Ciblées : elles ciblent des entreprises spécifiques dans le but de voler des données spécifiques
ou de causer des dommages spécifiques.
 Persistantes : elles ont différentes phases pendant lesquelles elles évoluent sur une longue
période. Avant de lancer une attaque APT, les attaquants connaissent seulement l’entreprise et
ses objectifs. Ils ne savent pas où les données ciblées sont sauvegardées, quels contrôles de
sécurité sont déjà en place ou quelles vulnérabilités existent qui pourraient être exploitées.
 Evasifs : elles sont systématiquement conçues pour contourner les produits de sécurité
traditionnels que la plupart des entreprises ont utilisé pendant des années.
 Complexes : Une menace APT donnée peut impliquer:
- l'ingénierie sociale à travers le téléphone pour identifier les personnes clés au sein de
l'entreprise ciblée.
- les emails de phishing envoyés à ces personnes clés avec des liens vers un site Web qui
exécute le code JavaScript personnalisé pour installer un outil d'accès à distance
- la technologie de cryptage
Parmi les APT, les vecteurs d’attaques les plus fréquents sont:
 Les malwares personnalisés
Un morceau de code malveillant écrit pour compromettre une ou plusieurs entreprises ayant des
profils/activités similaires. Les APT faisant usage de logiciels malveillants sont très ciblés et spécifiques.
Il est possible de développer des signatures AV pour les attaques utilisant des malwares personnalisés.
Cependant, les attaquants ont compris que plus une attaque est nouvelle et qu’elle ne se propage pas
au-delà d’une petite communauté d’utilisateurs plus la chance d’être détectée diminue
considérablement. [6]

14
  Le spear phishing
Spear phishing combine l'attaque de phishing, qui consiste à usurper l'identité d'un utilisateur en ayant
recours à des Spams et des sites web factices, avec des techniques d'ingénierie sociale pour construire
des attaques très ciblées. Spear phishing est largement utilisé contre les institutions financières.
L'attaquant exploite les informations personnelles ou publiques sur les individus afin de personnaliser
un email qui semble provenir d'une source légitime et ainsi inciter les personnes à répondre avec des
informations personnelles telles que nom d'utilisateur et mot de passe. [6]
 Le ransomware
Ransomware est un code malveillant qui compresse les fichiers importants dans une archive cryptée et
supprime les fichiers originaux, rendant ainsi impossible l'accès aux fichiers à moins qu'une rançon soit
payée. Une fois la 'rançon' payée, l'utilisateur obtient le mot de passe pour déverrouiller ses fichiers.
Les attaques ransomware utilisent les émotions des utilisateurs cibles telles que la peur et l’embarras en
leurs indiquant que le ransomware a été causé suite à une des leurs action (téléchargement illégale,
visiter des sites inappropriés, entre autres.).
Aujourd’hui, aucun produit de sécurité seul ne peut offrir une couverture contre toutes ces stratégies
d’attaques APT. Il se doit d’adopter une stratégie de protection et une méthodologie multicouche dans
laquelle les mécanismes de détection multiples travaillent conjointement pour identifier des modèles
complexes de comportement évasifs. [6]
2.4 Méthodologie des attaques et Stratégies de protection
Pendant les trois dernières décennies, les logiciels anti-virus étaient très efficaces contre les
attaques de virus. Toutefois, les codes malveillants d’aujourd'hui se caractérisent différemment de ceux
du passé.
Les pirates ne cessent de concevoir de nouveaux codes malveillants pour éviter d’être détectés
par les logiciels anti-virus. Les attaques modernes pénètrent les systèmes de protection basés sur les
signatures existants en utilisant des techniques à multiples facettes visant à compromettre les systèmes.
La stratégie des pirates était alors d’examiner comment les solutions de sécurité traditionnelles
fonctionnent pour développer de nouveaux codes malveillants afin d’exploiter les failles. Du coup, Les
codes malveillants modernes ont la possibilité d’éviter d’être découverts et ainsi de déjouer l'ensemble
du processus sur lequel se reposent les systèmes de sécurité traditionnels.
En étant furtives et précis, les codes malveillants modernes évitent d’être détectés et n’infectent
pas un grand nombre de systèmes.

15
 Les mesures de sécurités traditionnelles ne répondent pas adéquatement aux menaces
d'aujourd'hui. Sans une nouvelle posture de sécurité, de nombreuses attaques qui s’appuient sur les
techniques APT vont continuer à atteindre leurs objectifs. Pour faire face à cela il convient dans un
premier temps de comprendre les méthodes utilisées par les menaces APT et ainsi de développer une
stratégie de protection adéquate. [6]
Une menace APT procède selon trois phases qui peuvent durer plusieurs mois :
 Phase 1
L’attaquant effectue une reconnaissance de l’infrastructure réseau de l’entreprise, identifie les
vulnérabilités, cordonne une attaque et infecte les hôtes cibles.
 Phase 2
L’attaquant contrôle les hôtes infectés, met à jour son code malveillant, le propage à d’autres machines
et identifie les données ciblées.
 Phase 3
L'attaquant extrait les données ciblées du réseau et procède à des actions sur celles-ci.

A ce stade, les attaquants contrôlent un ou plusieurs hôtes dans le réseau cible, peuvent établir
les connexions en utilisant des identifiants qui ont un accès privilégié et ont déjà identifiés les données
cibles (en supposant que les données étaient le but). La seule chose qui reste à faire est d'extraire les
données depuis le réseau vers leur serveur. Ce serveur peut être situé au même emplacement que
l'attaquant ou dans un pays étranger.
En se basant sur les caractéristiques et les modes de fonctionnement des attaques APT vus
précédemment, nous pouvons décrire les principales exigences d'une solution de sécurité efficace.
Ainsi une telle solution doit être :
- Sensible au contenu des données : Puisque les APT arrivent à pénétrer le pare-feu des
réseaux, en intégrant des codes malveillants dans le contenu transporté par les protocoles (qui
sont couramment utilisés et autorisés), les solutions doivent cependant être capables de faire
une analyse profonde des contenus qui sont transportés par les protocoles.
- Sensible au contexte : Comme la plupart des attaques APT utilisent du code développé sur
mesure et ciblent les vulnérabilités zero day, aucune signature d’antivirus n’est susceptible de
les identifier avec certitude. Sans signatures d'attaques définitives, nous devons compter sur
des indicateurs moins explicites. Bien que seul un indicateur suspect ne puisse suffire pour
identifier une attaque, il se doit d’analyser les autres indicateurs suspects qui sont dans le même

16
 contexte et ainsi récolter suffisamment de preuves pour identifier de manière fiable les activités
malveillantes.
- Conscience des données : Bien que les entreprises cibles puissent ne pas savoir exactement
à quoi ressemble une attaque APT, la plupart des entreprises peuvent identifier leurs propres
données sensibles. Par conséquent, un ‘Data Loss Prevention’ (DLP) peut être appliqué
comme une couche de sécurité pour identifier les données sensibles et empêcher les transferts
sortants de ces données. [6]
2.5 Sécurisation dynamique des points d’accès internet
2.5.1 Définition du proxy
2.5.1.1 Serveur Proxy
Un proxy est un système matériel ou logiciel faisant fonction d'intermédiaire entre les ordinateurs d'un
réseau local et internet. Ses objectifs, le filtrage des services Internet auxquels les utilisateurs peuvent
accéder, l’accélération des performances du réseau et la protection des réseaux contre les intrusions
extérieures. [8]
2.5.1.2 Passerelle de sécurité
La passerelle web sécurisée est une solution de sécurité Web efficace assurant une protection contre
les menaces inégalée. C’est est un proxy évolutif conçu pour sécuriser vos communications web et
accélérer vos applications professionnelles. L'architecture proxy unique de cette solution lui permet de
surveiller, contrôler et sécuriser le trafic pour offrir une expérience sécurisée sur le Web et dans le
Cloud. [9]
2.5.1.3 Rôle du proxy
 Identifier, gérer et connecter les protocoles les plus populaires web.
 Définir des politiques globales d'utilisation qui peuvent être appliquées à tous les utilisateurs
(individuels ou des groupes).
 Authentifier et autoriser l’accès utilisateur quand c'est nécessaire.
 Filtrer les URL en utilisant la base de données et des définitions personnalisées.

17
 2.5.2 Les types de proxy
2.5.2.1 Forward proxy

Figure 4: Forward Proxy

Un proxy en mode forward est un proxy "mandaté" par une application pour effectuer une requête
sur Internet à sa place. Ainsi, lorsqu'un utilisateur se connecte à internet à l'aide d'une application
cliente configurée pour utiliser un serveur proxy, celle-ci va se connecter en premier lieu au serveur
proxy et lui donner sa requête.
Le serveur proxy va alors se connecter au serveur que l'application cliente cherche à joindre et lui
transmettre la requête. [8]
Le serveur va ensuite donner sa réponse au proxy, qui va à son tour la transmettre à l'application cliente.
2.5.2.2 Reverse proxy

Figure 5: Reverse Proxy

On appelle reverse-proxy un serveur proxy-cache "monté à l'envers", c'est-à-dire un serveur proxy

permettant non pas aux utilisateurs d'accéder au réseau internet, mais aux utilisateurs d'internet
d'accéder indirectement à certains serveurs internes. [8]

Conclusion
Avec ce premier chapitre nous avons défini le contexte général du projet ainsi que la méthodologie de
gestion du projet proposée par 2SB, chose qui nous a permis de dégager un plan précis du déroulement
du projet. Nous avons fini par expliquer les notions abordées dans le lexique du projet
Le chapitre qui suit va se baser sur une analyse de l’architecture existante du client afin de dégager ces
besoins pour la sécurisation des flux et contenus.

18
 Chapitre 2

Chapi tre2 : Etude de l’existant et spécification des

besoins

Plan
1 Analyse de l’existant ........................................................................................................................... 19
1.1 Architecture de l’entreprise ....................................................................................................... 20

1.2 Les principaux équipements de sécurité.................................................................................. 20

2 Critique de l’existant ........................................................................................................................... 21

3 Spécifications des besoins.................................................................................................................. 21
3.1 Les besoins fonctionnelles ........................................................................................................ 22

3.2 Les besoins non fonctionnels ................................................................................................... 23

4 Identification des acteurs ................................................................................................................... 23

5 Modélisation des besoins ................................................................................................................... 24
5.1 Diagramme de cas d'utilisation ................................................................................................. 24

5.2 Description de quelques cas d'utilisation ................................................................................ 25

Introduction
La phase de spécification des besoins est une phase vitale dans le cycle de vie de tout projet. Elle
permet de dégager ces exigences et d’en définir les besoins et les attentes du client. Dans ce deuxième
chapitre, nous allons analyser l’architecture cliente pour en dégager les failles et ainsi pouvoir
déterminer les besoins fonctionnels et non fonctionnels.

1 Analyse de l’existant
Une bonne compréhension de l’environnement informatique de notre société cliente aide à déterminer
la portée de notre projet de mise en place d’une solution avancée de sécurisation des flux et contenus.

19
Il est essentiel de disposer d’informations précises sur l’infrastructure réseau physique. En effet, ces
informations affectent en grande partie les décisions que nous allons prendre en considération dans la
conception de l’architecture hybride à mettre en place.
Le système d'information de notre client est complexe vu qu’il dispose d’un siège central, de deux sites
distants et beaucoup d’utilisateurs nomades.
En conséquent, une étude de l'architecture et de ces équipements de sécurité est primordiale
1.1 Architecture de l’entreprise

Figure 6: Architecture existante de l'entreprise

1.2 Les principaux équipements de sécurité

Pour fournir une bonne protection de ses données, Notre client dispose de plusieurs outils de sécurité.
Le réseau prend en charge un large éventail de périphériques. Il est composé essentiellement de :
 un firewall pour filtrer le trafic entrant et sortant de son réseau
 une solution de filtrage URLs « squid » dans son siège central qui est un serveur Proxy/cache
libre, son rôle est de partager un accès Internet entre plusieurs clients d’un réseau privé. Squid
est capable de manipuler les protocoles HTTP, FTP, SSL etc.
 Un tunnel MPLS est monté entre un site distant et le siège central afin de garantir une qualité
de service et bénéficier de la protection offerte à ce niveau

20
  des antivirus sont utilisés sur toutes les machines branchées sur le réseau afin de vérifier si des
virus ont pu se propager.
Malheureusement, plusieurs sites distants ainsi que des utilisateurs nomades ne sont pas encore
protégés contre les risques d’attaques liés à l’accès à Internet.

2 Critique de l’existant
La solution de sécurité adoptée actuellement par l’entreprise cliente ne satisfait plus aux besoins.
En effet, la solution de filtrage Squid propose une multitude d’options et de services comme :
 Le filtrage des requêtes des clients.
 La restriction de l’accès à l’Internet.
 L’authentification des clients.
 L’accélération des accès aux ressources grâce au système de cache.
Mais, il ne permet pas
 Le filtrage du trafic en fonctions des catégories et des applications
 La visibilité sur le trafic chiffré qui représente un besoin primordial pour le client vu que
son trafic chiffré représente plus de 30%.
 Le Contrôle de l'utilisation du Web dans le Cloud
 L’analyse des contenus et la détection des malwares
De plus, l’utilisation d’une liaison MPLS est assez coûteuse afin de permettre à un site distant de
bénéficier de la protection existante au niveau du siège central.
Finalement, Suite à plusieurs réclamations de ralentissements lors de l’accès à Internet, nous avons
constaté l’absence de gestion de la qualité de service.

3 Spécifications des besoins

L’objectif de ce projet est de concevoir et mettre en place une solution avancée pour la sécurisation
des flux et contenus sur une architecture hybride en local et sur le Cloud. Suite à l’analyse de
l’architecture existante, La solution à concevoir doit pallier à certaines contraintes. De ce fait, quelques
besoins ont été relevés.

21
 3.1 Les besoins fonctionnelles
La spécification fonctionnelle permet de décrire les principaux besoins que la solution doit satisfaire.
L'objectif principal est de concevoir et mettre en place une solution avancée pour la sécurisation des
flux et contenus sur une architecture hybride on promises et sur le Cloud.
Pour atteindre cet objectif, La solution doit répondre aux besoins suivants :
 Mettre en place une architecture hybride (en local et sur le Cloud):
La solution doit garantir une sécurité des contenus et des flux pour le siège central ainsi que les
sites distants et les postes nomades. Cette sécurité doit englober les données locales ainsi que
celle sur le Cloud.
 Garantir la confidentialité par authentification des utilisateurs:
La solution doit garantir l’un des principaux caractéristiques de la sécurité informatique qui est
la confidentialité en fournissant un moyen d’authentifier les utilisateurs selon le profil et selon
la localisation.
 Etablir une politique de filtrage uniforme et centralisée en fonctions des catégories et des
applications:
La solution doit garantir que la politique de sécurité à mettre en place soit appliquée d’une
façon centralisée pour tout utilisateur quel que soit sa géolocalisation (dans le siège central,
dans un des sites distants ou nomades).
 Analyser le trafic chiffré par une interception SSL:
La solution doit garantir l’interception de tout trafic même chiffré pour analyser et inspecter
son contenu.
 Gérer la bande passante et mettre en place l’accélération web grâce au caching:
La solution doit garantir l'accélération Web, la mise en cache des objets et la mise en place de
techniques d'optimisation des protocoles telles que le pipelining. Elle doit fournir également
une compression de niveau HTTP et un cadre de stratégie granulaire pour contrôler ou réécrire
des classes spécifiques de requêtes et de réponses http afin de gérer la bande passante.
 Dégager des tableaux de bord et des rapports:
La solution doit fournir un tableau de bord de rapport, qui affiche des résumés de haut niveau
des activités de navigation Web ainsi qu’une visibilité puissante sur toutes les activités des
utilisateurs liées au Web.

22
 3.2 Les besoins non fonctionnels
Les besoins non fonctionnels représentent les exigences implicites auxquelles la solution doit répondre.
Ainsi à part les besoins fondamentaux, Il s’agit des caractéristiques en matière de:
 Flexibilité : Vu la croissance de l’Internet, la solution doit être flexible pour des éventuels
changements en termes de configuration de la politique de sécurité.
 Usage : la partie de la solution concernant la gestion des logs et des rapports doit être facile à
manipuler.
 Transparence: La solution de sécurisation doit être assez transparente pour les utilisateurs.
 Délai : La mise en place de la solution doit être effectuée dans le temps imparti.

4 Identification des acteurs

Cette étude consiste à identifier les acteurs et leur interaction avec la solution. Les acteurs seront
déterminés en identifiant les utilisateurs responsables de la configuration, de la mise en place et de la
maintenance de la solution et ceux qui subissent les politiques mises en place au niveau des
équipements.
 Administrateur Réseaux et Sécurité
C'est l'ingénieur sécurité chargé d'administrer la solution, il a accès à tous les équipements en SSH et
en Https via la console de gestion, il gère la solution (mise en place de la politique de sécurité,
configuration du moyen d’authentification des utilisateurs, gestion de la communication et du bon
fonctionnement entre la partie on prémisses et la partie Cloud de la solution)
 Responsable RH
Ce sont les personnes, qui font partie des ressources humaines et qui sont responsables du suivi des
normes acceptables d'utilisation du Web établies par l’entreprise cliente.
Ces utilisateurs ont accès aux liens du tableau de bord et des rapports dans chaque module (filtrage de
contenu, protection contre les menaces, protocoles d'application Web).
 Utilisateur
C’est un utilisateur passif car il s’agit de toute personne authentifiée au niveau de l’équipement et qui
subit l’application des politiques de filtrages configurées au niveau des équipements.

23
5 Modélisation des besoins
Nous allons modéliser les besoins de notre solution au moyen de diagramme de cas d’utilisation qui
sert à donner une vision globale du comportement fonctionnel du système et décrire des interactions
entre les acteurs et les fonctionnalités du système.
5.1 Diagramme de cas d'utilisation
Un cas d’utilisation est un flot d’événements complet et significatif, il est initié par un acteur pour
invoquer des fonctionnalités du système. La collection de tous les cas d’utilisations constitue l’ensemble
des possibilités d’utilisation du système.

Figure 7: Diagramme de cas d'utilisation de la solution à concevoir

24
 5.2 Description de quelques cas d'utilisation
Nom Acteur Pré condition Description
Effectuer les Administrateur Authentification L’administrateur accède aux équipements
configurations de l'administrateur afin d’effectuer les configurations de base
basiques (DNS, NTP, Services, etc…)

Gérer les Administrateur Authentification L’administrateur met en place un mode

utilisateurs de l’administrateur d’authentification pour les utilisateurs et
gère les différents comptes et groupes au
niveau de l’AD (Active Directory)
Mettre en place Administrateur Authentification L'administrateur met en place la politique de
la politique de de l'administrateur sécurité de l’entreprise sous forme de règles
sécurité pour les de sécurité, de paramétrage au niveau des
connexions Web équipements et de moyens d’accès pour
centraliser la sécurisation des sites distants
et des utilisateurs nomades avec le siège
central
Consulter les logs Administrateur/ Authentification L'administrateur/Le responsable RH
Responsable RH de pourra visualiser des tableaux de bord et des
L'administrateur/ statistiques calculés.
Le reporteur
Tableau 1: Tableau descriptif de quelques cas d'utilisation

Conclusion
Au cours de ce chapitre nous avons pu mettre le point sur les défaillances de l’architecture réseau de
notre client et ainsi dégager les besoins fonctionnels et proposer une solution pour palier à ces
problèmes

25
 Chapitre 3

Chapi tre3 : Etude de la solution de sécurisation des flux

et de leurs contenus
Plan
1 Conception et étude des solutions du marché ................................................................................ 27
1.1 Conception globale..................................................................................................................... 27

1.2 Conception détaillée ................................................................................................................... 28

1.3 Etude comparative des solutions existantes ........................................................................... 32

1.4 Choix du client ............................................................................................................................ 35

2 Présentation du ProxySG de BlueCoat............................................................................................ 36

2.1 Les fonctionnalités du ProxySG............................................................................................... 36

2.2 Les architectures supportées ..................................................................................................... 37

2.3 Authentification .......................................................................................................................... 38

2.4 Application de la politique de sécurité..................................................................................... 39

2.5 Analyse des flux SSL .................................................................................................................. 41

2.6 Optimisation des performances ............................................................................................... 42

2.7 Protection contre les attaques DOS ........................................................................................ 42

2.8 Logs d’accès................................................................................................................................. 42

3 Présentation du service Cloud « Web Security Service » de BlueCoat ........................................ 43

3.1 Définir le service Sécurité Web en Cloud ............................................................................... 43

3.2 Fonctionnalités du Web Security Service ................................................................................ 44

3.3 Les modes de déploiement du service Cloud WSS : ............................................................. 45

3.4 Gestion des politiques de sécurité ............................................................................................ 47

3.5 Accès Logs : Tableau de bord en temps réel .......................................................................... 47

26
Introduction
Le but de ce troisième chapitre est d’effectuer, dans un premier temps, la conception de l’architecture
à déployer. Dans un second temps, Nous allons présenter les différentes solutions existantes sur le
marché afin d’appuyer le choix du client pour la solution BlueCoat. Nous finissons par aborder les
différentes fonctionnalités des solutions de la technologie élue.

1 Conception et étude des solutions du marché

1.1 Conception globale
D’après l’analyse des besoins effectuée précédemment, Nous avons confirmé que l’entreprise cliente a
besoin d'une solution de sécurisation des contenus et flux web. Cette solution a pour objectif de
permettre la mise en place d’une politique de sécurité centralisée qui s’applique sur tous les utilisateurs
du siège central ainsi que ceux des sites distants et les utilisateurs nomades.
La solution à mettre en place consiste à :
 La mise en place un nouveau proxy avec une passerelle sécurisé à la place de l’ancienne solution
de filtrage « squid ».
 L’utilisation d’un service de sécurité Cloud pour la sécurisation des sites distants et les
utilisateurs nomades.
 L’élimination du lien MPLS entre le site de Lyon et le site central.
 La modification de l’architecture au niveau du site Lyon.
 Mise en place d’un tunnel sécurisé pour rediriger le trafic généré par les utilisateurs du site
distant de Lyon vers le Cloud.
 La redirection du trafic généré par les utilisateurs du site central vers la solution Cloud.
 La redirection du trafic généré par les utilisateurs nomades vers le Cloud avec l’installation
d’agents sur les postes.
 La redirection du trafic généré par les utilisateurs du site distant de Toulouse avec une
configuration explicite d’un proxy.
La figure suivante présente l'architecture globale de la solution envisagée.

27
 Solution Internet
Cloud
Internet

Redirection du trafic vers

la solution Cloud
5 utilisateurs
Redirection du trafic vers 1000 utilisateurs 1 Mbps
la solution Cloud avec Firewall 30 Mbps
Redirection du trafic
l installation d agent
vers la solution Cloud
avec un proxy Explicit

Proxy avec une

passerelle sécurisée Redirection du trafic
vers la solution Cloud
dans un tunnel sécurisé

Utilisateurs nomades
Firewall
LAN2 Zone
DMZ 50 utilisateurs
LAN1
10 Mbps

Solution Internet
Cloud

Figure 8: Architecture globale de la solution envisagée

1.2 Conception détaillée

Dans cette partie, nous allons détailler et enrichir les éléments constituants notre solution par des
diagrammes de séquence qui montrent non seulement les acteurs externes interagissant directement
avec le système, mais également le système lui-même et les événements système déclenchés par les
acteurs.

28
1.2.1 Diagramme de séquence de la sécurisation d’un utilisateur du siège central

Figure 9: Diagramme de séquence pour l'utilisateur du site central

29
1.2.2 Diagramme de séquence de la sécurisation d’un utilisateur du site de Lyon

Figure 10: Diagramme de séquence pour l'utilisateur du site Lyon

30
1.2.3 Diagramme de séquence de la sécurisation d’un utilisateur du site de Toulouse

Figure 11: Diagramme de séquence pour l'utilisateur du site Toulouse

31
 1.2.4 Diagramme de séquence de la sécurisation d’un utilisateur nomade

Figure 12: Diagramme de séquence pour un utilisateur nomade

1.3 Etude comparative des solutions existantes

Nous avons effectué une étude comparative pour les solutions existantes sur le marché afin d’appuyer
sur le choix du Client.
1.3.1 Solution Cisco
Le Cisco WSA a été l'une des premières passerelles Web sécurisées à combiner les principales
protections pour aider les entreprises à relever les défis croissants de sécuriser et de contrôler le trafic
Web. Il permet un déploiement plus simple et plus rapide avec moins d'exigences de maintenance, une
latence réduite et des coûts d'exploitation plus faibles. Les options de déploiement flexibles et
l'intégration avec une infrastructure de sécurité existante permettent de répondre rapidement aux
exigences de sécurité évolutives. [10]

32
  une protection Web rapide et complète grâce au plus grand réseau de détection des menaces
au monde, avec la plus grande visibilité et la plus grande empreinte
 un filtrage d'URL traditionnel avec une analyse de contenu dynamique pour atténuer les risques
de conformité, de responsabilité et de productivité
 une protection avancée contre les logiciels malveillants
 empêcher les données confidentielles de quitter le réseau en créant des règles contextuelles
pour DLP basique
 contrôler facilement l'utilisation de centaines d'applications Web 2.0 et plus de 150 000 micro-
applications.

1.3.2 Solution BlueCoat

Le ProxySG de BlueCoat offre la protection et les performances complètes pour faire avancer une
entreprise. En tant que passerelle Web la plus sécurisée au monde, utilisée par plus de 70% du Fortune
500, le ProxySG est un élément fondamental de l'architecture de sécurité d'une entreprise.
Le ProxySG consolide un large éventail de fonctionnalités qui protège votre entreprise de la
sophistication et du volume de menaces toujours croissants dans votre trafic Web. Assis entre les
utilisateurs et leurs interactions avec Internet, le ProxySG inspecte le contenu pour identifier les
charges utiles malveillantes, puis filtre, décompose, bloque ou remplace le contenu Web pour atténuer
les risques et prévenir la perte de données (DLP). Le ProxySG offre:
 Une défense contre les menaces « Negative Day Threat »
 Une authentification des utilisateurs
 Une visibilité sur le trafic crypté
 Une intégration des dernières protections de menaces avancées
 Un contrôle de l'utilisation du Web et dans le Cloud
 Des performances et fiabilité inégalées [11]

1.3.3 Solution MacAfee

McAfee Web Gateway constitue une ligne de défense critique pour toute entreprise désireuse de se
protéger contre les logiciels malveillants émergents (malware). Cette solution offre aux entreprises un
accès Internet sécurisé tout en réduisant considérablement les risques grâce à une approche avancée
de la sécurité, qui combine des fonctions puissantes d'analyse des intentions en local et une protection
via le Cloud.

33
  une protection complète de tous les aspects du trafic web au sein d'une architecture de
composants logiciels de hautes performances.
 une protection contre les fuites de données et d'informations confidentielles, sensibles ou
réglementées via des vecteurs tels que les sites de réseaux sociaux, les blogs et les wikis. [12]

1.3.4 Solution Zscaler

Zscaler Web Security vous fournit une passerelle Internet et Web sécurisée livrée en tant que service.
Zscaler offre une pile de sécurité complète avec toute la protection en profondeur dont vous aurez
besoin. Il suffit de pointer votre trafic de bureau ou d'utilisateur vers la plate-forme Zscaler, et il
commence instantanément à interrompre les logiciels malveillants, les menaces avancées, le phishing,
les exploits du navigateur, les URL malveillantes et plus encore.
Zscaler permet de libérer des modèles d'appareils traditionnels, à rompre avec le MPLS et aux coûts
de réseau, et à restaurer la sécurité dans un premier monde en Cloud.
 Améliorer et rationaliser le modèle de sécurité.
 Offrir une expérience utilisateur plus rapide et plus sécurisée.
 Mettre en place une politique unifiée et générer des rapports. [13]

1.3.5 Comparaison des solutions

Après la présentation des solutions les plus connues sur le marché, nous constatons qu’elles offrent
toutes des fonctionnalités similaires. Pour essayer de les différencier, nous avons comparé ces solutions
selon des caractéristiques spécifiques présentées dans le tableau suivant :

Caractéristiques Cisco BlueCoat McAfee zscaler

Antimalware
(filtrage, AV, X   
Sandboxing) (Pas de Sandboxing)

Écosystème de
l'Intelligence de X   
la menace
Application
d’une politique    
granulaire

34
 Application,
opérations,    
contrôles
Proxy SSL et
décryptage des X  X X
flux (Pas de décryptage) (Pas de décryptage) (Pas de décryptage)

Qualité de
service
(Gestion de la    
bande passante)
Tableau 2: Tableau comparatif des solutions existantes sur le marché [14]

Figure 13: Comparaison des solutions existantes [15]

1.4 Choix du client

En se référant à toute l’étude comparative des solutions existantes et après la conception de la solution,
Nous constatons bien que la technologie BlueCoat est le leader dans le marché. En effet, Les
équipements de sécurité de BlueCoat, qui sont les premières solutions entièrement dédiées au Port 80,

35
garantissent la protection des réseaux d’entreprise contre les menaces issues du Web grâce à la large
gamme de produits de sécurité Web, des solutions de création et de configuration de règles de sécurité,
un puissant logiciel de reporting et une solution de filtrage des contenus.
De plus, suite aux présentations et différentes démonstrations techniques que nous avons effectuées
pour notre client, Nous avons réussi à le convaincre d’opter pour la meilleure solution qui répond à
son besoin qui est la solution BlueCoat.

2 Présentation du ProxySG de BlueCoat

La passerelle Web sécurisée de BlueCoat (SWG), le ProxySG, figure parmi les principaux produits sur
le marché SWG.
Dans cette partie, nous allons présenter les différentes fonctionnalités qu’offre cette solution pour la
sécurisation des flux et contenus Web.
2.1 Les fonctionnalités du ProxySG
Le ProxySG protège les entreprises d’aujourd’hui contre l’avènement de menaces dans le trafic Web
grâce à une panoplie de fonctionnalités parmi lesquelles, nous citons:
 Une défense contre les menaces en temps réels
Le ProxySG garantit une protection contre des dernières menaces en s’appuyant sur le réseau Global
Intelligence Network basé sur le Cloud de BlueCoat qui fournit des informations précieuses et à jour
sur les derniers risques pour les moteurs d'analyse afin d'accélérer les réponses aux menaces basées sur
le Web. Un milliard de nouvelles demandes Web par jour, provenant de plus de 15 000 clients
d'entreprise et des millions d'utilisateurs, sont collectées et analysées pour maintenir le ProxySG à jour.
 Une Authentification des utilisateurs
Le ProxySG possède le support le plus large pour les fournisseurs d'authentification dans l'industrie,
offrant la possibilité d'intégrer facilement de nouveaux utilisateurs et groupes, même ceux qui utilisent
des technologies d'authentification complètement différentes. Le ProxySG prend en charge plusieurs
domaines et permet aux d'interroger séquentiellement plusieurs références nécessaires pour trouver un
utilisateur.
 Une visibilité sur le trafic crypté
Le ProxySG dispose d'un proxy SSL qui permet la visibilité du trafic SSL. Il élimine les points cachés
SSL, en donnant une visibilité et un contrôle complets sur le trafic crypté par SSL pour empêcher les
applications parasites, les logiciels malveillants et les cyberattaques d'utiliser SSL pour cacher leurs
activités

36
  Contrôle de l'utilisation du Web et du Cloud
Le ProxySG permet un contrôle des contenus sensibles et l’identification des applications en Cloud. Il
permet ainsi de réduire les risques posés par les «Shadow IT».
 Performance accélérée de l'application Cloud
Le ProxySG fournit la mise en cache de contenu et l'optimisation du trafic afin d'assurer la disponibilité
des applications Cloud. Il offre une gestion avancée de la bande passante, avec des compressions de
médias en continu. [11]
2.2 Les architectures supportées
La solution Blue Coat offre une grande flexibilité de déploiements. Les différentes architectures sont
réparties en 2 familles :
 Mode proxy explicite
 Mode proxy transparent
2.2.1 Mode Proxy Explicite
Dans ce mode, le proxy est explicitement déclaré dans le navigateur. Les méthodes généralement
utilisées sont :
 le fichier PAC (Proxy Auto_configuration File)
 l’auto détection de proxy
 une configuration IP ou DNS
Il est possible de contrôler cette configuration de manière centralisée grâce aux GPO Microsoft ou
tout outil de gestion de parc.
Le proxy peut être positionné à tout endroit du réseau, une DMZ ou le réseau local sont en général
utilisés. [8]
Voici un exemple de proxy en DMZ avec un fichier PAC :

Figure 14: Mode Proxy Explicite

2.2.2 Proxy Transparent

Le principe du mode transparent est d’éviter toute configuration du navigateur.
37
Pour ce mode, Le ProxySG de BlueCoat supporte l’ensemble des architectures transparentes
possibles :
 En coupure de niveau 2 (bridge)
 En routeur
 Avec un switch de niveau 4
 Par routage DNS [8]
Voici un exemple d’architecture en coupure de niveau 2 :

Figure 15: Mode Proxy Transparent

2.3 Authentification
Le ProxySG offre un large choix d’authentification, avec une mise en œuvre qui est dépendante des
normes RFC et du choix d’architecture.
2.3.1 Protocoles d’authentification
Sur l’équipement les protocoles supportés sont :
 Active Directory avec un agent BCAAA (avec tous les types : basic, NTLM, Kerberos)
 Active Directory avec intégration au domaine sans agent (avec tous les types : basic,
NTLM, Kerberos)
 Active Directory en mode SSO
 LDAP(s)
 Base locale
2.3.2 Mécanismes d’authentification
A travers les multiples protocoles supportés, plusieurs types d’authentification s’appliquent :
 Authentification http de type proxy : ce mode utilise le code HTTP 407 et n’est autorisé
qu’en proxy explicite
 Authentification http de type serveur : ce mode utilise le code HTTP 401 et nécessite une
redirection sur une virtual URL lors de l’authentification. Il est notamment utilisé pour les
déploiements en proxy transparent
 Lecture de jetons de session utilisés dans les mécanismes SSO
 Identification d’IP source utilisé avec un Active Directory (Windows SSO)

38
  Lecture d’entête HTTP notamment utilisé lors du chainage de proxy
Une fois l’authentification réalisée, il est nécessaire d’utiliser un mécanisme de persistance pour
reconnaître l’utilisateur lors de ses requêtes suivantes :
 Session TCP : toutes les requêtes de la session en cours appartiennent à l’utilisateur, il y a
une authentification par session TCP
 IP : toutes les requêtes de l’IP source sont automatiquement authentifiées pendant une
durée paramétrable
 Cookie : un cookie de session permet de suivre l’utilisateur, la durée du cookie est
paramétrable [8]
2.4 Application de la politique de sécurité
2.4.1 Introduction
Chaque client a des besoins spécifiques liés à son métier et à l’évolution de son système d’information.
L’application de la politique de sécurité et le traitement des cas particuliers nécessite donc un système
flexible et performant.
Pour répondre à l’ensemble des situations, la politique de sécurité est définit dans une interface
graphique appelée le Visual Policy Manager ou VPM. Cet outil permet la définition de règles pour
le traitement de chacune des requêtes traitées par le ProxySG. [8]
2.4.2 Webfilter / Webpulse
Notre solution de catégorisation Blue Coat Webfilter constitue un élément crucial pour la mise en
place de la politique de l’entreprise. En effet, elle délivre des informations précises sur la qualité du site
accédé par l’utilisateur.
Le résultat de la catégorisation est accessible en tant que critère de destination dans le VPM. [8]
2.4.2.1 Catégorisation des applications

Figure 16: Schématisation de la catégorisation des applications

39
Avec le Web 2.0, les sites web peuvent devenir des applications aussi riches que des logiciels installés
sur un système d’exploitation. Afin de fournir les moyens d’identifier et de contrôler ces nouveaux
usages, webfilter permet d’identifier l’application utilisée ainsi que de détailler les tâches réalisées par
l’utilisateur. [8]
2.4.2.2 Catégorisation dynamique
Suivre l’évolution d’internet en temps réel est un vrai challenge. La catégorisation dynamique permet
d’obtenir une solution hybride à la fois performante et très réactive :
 Les sites connus sont catégorisés en local par le proxySG qui dispose de la base webfilter
en RAM
 Les requêtes non catégorisées sont transmises au cloud WebPulse pour analyse en temps
réel et le résultat est mémorisé dans un cache.
Cette technologie est utilisée depuis 2004 et permet d’enrichir la base webfilter en continu. Lorsqu’il
n’est pas possible de déterminer automatiquement la catégorie d’un site, une analyse à l’œil humain
permet la catégorisation de ce site.
Aujourd’hui, WebPulse est constitué de 7 datacenter à travers le monde et réalise aussi bien la détection
de catégorie que de malware.
Ainsi nos 75 millions d’utilisateurs protégés à travers le monde génèrent quotidiennement pas moins
de 1,2 milliards de requêtes, ces requêtes nous permettent une grande réactivité par rapport à
l’évolution d’Internet. [8]
2.4.2.3 Protection contre les menaces
WebFilter/WebPulse n’est pas uniquement une solution permettant de contrôler l’usage d’internet.
C’est également un outil de sécurité puissant permettant de bloquer les requêtes malicieuses.
Pour ce faire, nos experts sécurités surveillent et analysent de nombreux paramètres afin de noter la
dangerosité des sites :
 Le contenu exécutable, en particulier les javascripts
 La réputation du serveur hébergeant le site
 L’historique du nom de domaine
 Tout fichier dangereux est analysé dans une batterie d’antivirus différent (plus de 10)
 Une empreinte ADN est prise sur tous les sites malicieux afin d’en détecter les clones

40
  Enfin, une grande attention est portée aux malnets. Nous réalisons la surveillance
permanente de plus de 1500 réseaux à travers le monde afin d’identifier et de catégoriser
toute nouvelle source s’ajoutant au réseau en temps réel. [8]
2.5 Analyse des flux SSL
Le ProxySG permet de réaliser plusieurs traitements sur les flux SSL :
 Le contrôle et la catégorisation des certificats
 Le déchiffrement des flux SSL [8]
2.5.1 Contrôle et catégorisation des certificats
Il est possible de contrôler le certificat serveur avant d’autoriser l’établissement de la session SSL.
Les champs contrôlés sont :
 La date de validité du certificat
 L’autorité émettrice du certificat (Issuer)
 Le Common Name (CN) du certificat indiquant les domaines certifiés.
De plus, le CN du certificat est catégorisé grâce à Webfilter et permet l’application de la politique de
sécurité sur les flux SSL de façon efficace.
L’analyse du certificat ne nécessite pas l’interception complète de la session. [8]
2.5.2 Déchiffrement des flux SSL
Les flux SSL représentent aujourd’hui 30% à 40% du trafic, il est donc recommandé de déchiffrer ces
flux pour les inspecter. ProxySG réalise alors une interception du flux de type « man in the middle » :

Figure 17: Architecture simplifiée du déchiffrement des flux SSL

La session cliente est terminée par le ProxySG et une nouvelle session SSL est initiée par le BlueCoat
pour se connecter au serveur.
Le certificat présenté à l’utilisateur est automatiquement généré par le ProxySG, il reprend l’ensemble
des informations contenues dans le certificat d’origine (CN, dates, …). Seul l’émetteur du certificat est
remplacé par l’autorité installée dans l’appliance.
L’implémentation de ce mécanisme nécessite donc la distribution d’une autorité de confiance sur les
postes utilisateurs, cette tâche étant facilement réalisable avec les GPO Microsoft.

41
Enfin, les certificats serveurs issus d’une autorité non reconnue sont signés par une deuxième autorité
non déployée sur les postes utilisateurs. Cela permet de conserver l’affichage du message
d’avertissement sur les navigateurs. [8]
2.6 Optimisation des performances
2.6.1 Mise en cache des pages web
Le ProxySG se base sur les headers HTTP standard pour réaliser la mise en cache. Le taux de
cachabilité dépend des indications fournies par les sites web et varie en général entre 20 et 30%.
Les headers sont également modifiable pour améliorer la cachabilité ou corriger d’éventuels problèmes
de cache sur les navigateurs utilisateurs. [8]
2.6.2 Accélération des accès aux pages web
En addition au caching, le ProxySG intègre les fonctions de pipeline et prefetch permettant de
télécharger les objets d’une page en anticipant les requêtes de l’utilisateur. Pour cela, chaque page est
analysée et les images, scripts et feuilles de styles sont téléchargées immédiatement.
2.7 Protection contre les attaques DOS
Le ProxySG intègre une fonction de protection contre les attaques DOS et DDOS grâce à une analyse :
 Du nombre de sessions TCP
 Du nombre de requêtes TCP
 Du nombre de requêtes TCP retournant des codes d’erreur
Il est possible de définir des seuils de protection sur ces différentes valeurs par serveur, site, IP source
de la session TCP ou IP source définie par header HTTP.
Si la valeur seuil est atteinte, il est possible de générer des alertes et bloquer les attaques. [8]
2.8 Logs d’accès
Afin de comprendre comment Internet est utilisé par ses collaborateurs, chaque entreprise souhaite
disposer de rapport détaillés sur le trafic traité par le proxy.
Le ProxySG génère des logs d’accès regroupant l’ensemble des informations de chaque requête qui
peuvent être envoyées à un SIEM pour une analyse plus détaillée.
Le ProxySG offre une grande flexibilité dans la génération de logs d’accès :
 Le format des logs est totalement personnalisable au format ELFF ou Custom. Plusieurs
centaines de champs sont disponibles
 Une requête peut être loguée dans plusieurs fichiers de logs simultanément, ces fichiers
peuvent avoir des formats différents
 L’export des fichiers de logs peut être réalisé :

42
  En FTP(s) ou HTTP(s) à heure fixe, toutes les x minutes ou au bout d’une certaine taille.
Le fichier peut être compressé.
 Au fil de l’eau dans un Blue Coat Reporter
 Au fil de l’eau en syslog TCP [8]

3 Présentation du service Cloud « Web Security Service » de BlueCoat

L'augmentation de l'utilisation du Web, l'adoption rapide du Cloud, la démocratisation de la mobilité
et les utilisateurs distants exposent le réseau d’entreprise à des risques.
La solution Cloud « BlueCoat Web Security Service » offre une protection en temps réel contre les
menaces sur le Web.
En effet, grâce aux contrôles étendus d'applications Web et des fonctionnalités de reporting détaillées,
les administrateurs informatiques peuvent utiliser ce service de sécurité Cloud pour créer et appliquer
des stratégies granulaires instantanément à tous les utilisateurs couverts, y compris les sites fixes et les
utilisateurs itinérants. [16]
3.1 Définir le service Sécurité Web en Cloud
Le service « BlueCoat Web Security Service » fournit les mêmes fonctionnalités de protection Web
proactives offertes par le leader sur le marché « Secure Web Gateway », le « Blue Coat ProxySG », mais
livré en tant que service de sécurité en Cloud résilient et performant.
Le service protège votre entreprise des menaces cybernétiques, contrôle et protège l'utilisation
corporative du cloud et du Web, empêche les fuites de données et assure le respect de l'ensemble de
l'information et du Web de votre entreprise / Politiques d'accès au Cloud.
Le WSS offre la sécurité du Web et du Cloud à partir d'un réseau diversifié de datacenters certifiés.
[16]

Figure 18: Schématisation du réseau de Datacenters du service WSS

43
 Control POD Data POD
Administration des consoles Traitement du trafic (connexion)
Politiques de sécurité du Client Application de la politique
Reporting Balayage des logiciels malveillants
Systéme de gestion Serveur d'évaluation
Tableau 3: Tableau de spécification des rôles du Control et Data POD

3.2 Fonctionnalités du Web Security Service

Le service Cloud WSS applique des politiques d'accès et de sécurité granulaires qui gèrent l'utilisation
d'internet par application, périphérique, utilisateur ou emplacement.
Les fonctionnalités offertes par ce service Cloud sont les suivantes:
 Un filtrage et une catégorisation d'URL
- 9 catégories de sécurité pour bloquer 90% de toutes les menaces
- un score unique de risque de menace d'URL pour augmenter la sécurité sans blocage
excessif
- une classification des URL dans une des 70 catégories couvrant plus de 50 langues
 Une authentification des utilisateurs
- des identifiants "ID" d’utilisateurs avec plusieurs méthodes d'authentification
- une intégration dans plusieurs systèmes d'authentification utilisés par votre entreprise
 Une protection avancée contre les menaces
- une analyse double anti-virus et heuristique pour bloquer les logiciels malveillants
- une utilisation des fonctionnalités « White-List / Black-List » personnalisées et l'analyse
de la réputation des fichiers
 Une gestion et une visibilité des rapports
- une définition des politiques de sécurité
- un accès à la visibilité centralisée et à la génération de rapports sur les passerelles Cloud
et sur site
- une surveillance de l'utilisation d'Internet, des menaces, des incidents par l'utilisateur,
l'emplacement et l'application en temps réel
 Une inspection de trafic cryptée
- des pratiques conformes pour l'interception, le décryptage et l'inspection du trafic
crypté SSL

44
 - l'emploi d’une autorité de certification sécurisée, avec les autorités centrales Root et
Intermediate de BlueCoat PKI hébergées
- une validation de l'autorité de certification du serveur avec vérification de la révocation
 Une connectivité universelle
- des Datacenters globaux distribués fournissent un accès au cloud local
- une connexion facile des ordinateurs portables, des appareils mobiles, des pare-feux,
des proxies
Symantec a racheté BlueCoat et a intégré le service de sécurité Web avec d'autres produits dans son
vaste portefeuille de sécurité. L’une des principales solutions supplémentaires est :
 Un courtier de sécurité d’accès au Cloud (CASB) qui permet :
- une identification des applications "Shadow IT": identifier les applications Cloud
auxquelles vos utilisateurs ont accès et évaluer les risques de ces applications.
- une définition des politiques d'accès et de contrôle basées sur des données du Cloud
afin de gérer les risques, les menaces et protéger les informations [17]
3.3 Les modes de déploiement du service Cloud WSS :

Figure 19: Vue générale des modes de déploiement du WSS

Le service de sécurité Cloud « WSS » offre plusieurs modes de déploiement afin de bénéficier de ces
différentes fonctionnalités.

45
 3.3.1 Mode de déploiement avec un tunnel IPSec VPN (site à site)
La méthode d'accès Firewall / VPN permet de configurer le pare-feu ou le périphérique de routage
pour envoyer le trafic Web du réseau interne de l'entreprise au service de sécurité Cloud de Blue Coat.
Cela se produit sur une connexion Internet Protocol Security (IPsec).
Le concept le plus bas pour cette méthode est de:
 Configurer le périphérique pour acheminer tout le trafic lié à Internet (port 80 et
443) vers le service de sécurité Cloud en utilisant un VPN site-to-site à partir d'un
périphérique de pare-feu existant.
 Configurer les règles de stratégie de l'appareil pour envoyer un trafic Web au service
et ignorer tout le reste.
 C'est la méthode de la clé pré-partagée (PSK).

Blue Coat utilise des algorithmes de cryptage forts standard de l'industrie, y compris AES-256, pour
s'assurer que tout le trafic est gardé privé lorsqu'il passe à ce service de sécurité Web. Pendant la
configuration, Il faut spécifier une clé de pré-coupure pour la connexion VPN de site à site. Cela
permet un plus grand contrôle de la sécurité du tunnel IPsec. [16]
3.3.2 Mode de déploiement avec un chainage de proxies (Proxy Forwarding)
Cette méthode permet d’établir une connexion au service Cloud de Blue Coat en utilisant un proxy de
réseau existant. Dans ce cas, le trafic de l'utilisateur est dirigé depuis le proxy local du client (tel qu'un
Blue Coat ProxySG ou un périphérique similaire), en fonction d'une politique de transfert qui
sélectionne le trafic qui devrait être sécurisé par le Cloud.
Les utilisateurs sont authentifiés et le trafic est sélectivement transmis au service WSS, ainsi que les
informations utilisateur et de groupe, en utilisant la politique de proxy établie. Toute méthode
d'authentification compatible avec le proxy fonctionnera. [16]
3.3.3 Mode de déploiement avec un proxy explicite « Proxy Pac »
Un fichier proxy auto-config (PAC) est un JavaScript qui permet aux requêtes du navigateur Web dans
le pare-feu d'une entreprise de contourner le serveur proxy en fonction de l'adresse IP de l'ordinateur
utilisé pour accéder aux sites Web internes. Les ordinateurs à l'intérieur du pare-feu ont accès à des
sites sur l'intranet de l'entreprise sans être acheminés via le service de sécurité Web de Blue Coat.
Les demandes de sites Web externes ou les demandes effectuées par des ordinateurs appartenant à
l'entreprise à l'aide d'une adresse IP externe sont acheminées via le service.

46
Les fichiers PAC peuvent également diriger la demande du navigateur Web vers un proxy spécifique
et peut restreindre l'accès en fonction des règles et des restrictions régissant l'accès au Web. [16]
3.3.4 Mode de déploiement avec connecteur de bureau « Unified-Agent »
L'agent unifié de BlueCoat fournit une sécurité Web aux utilisateurs distants lorsqu'un itinéraire via le
réseau d'entreprise n'est pas possible ou pratique. Dans le cas de notre entreprise cliente, les utilisateurs
distants sont définis comme des utilisateurs avec des ordinateurs portables qui sont pris en dehors du
réseau de l'entreprise (utilisateurs nomades).
Une fois l’agent installé, aucune configuration supplémentaire n'est requise sur le système client. Il
dirige les demandes de contenu au service de sécurité Web Blue Coat (ThreatPulse) sur une connexion
sécurisée (port 443).
Pour imposer l’application des règles de filtrage au niveau du service de sécurité Cloud, l'agent unifié
détecte et supprime les requêtes de méthode HTTP_CONNECT à toute adresse IP externe. Lorsque
ces connexions sont supprimées, l'utilisateur est incapable de contourner le filtrage et la numérisation
de logiciels malveillants. [16]
3.4 Gestion des politiques de sécurité
Le service Web de BlueCoat permet différents types de contrôles de politique. Pour la solution Blue
Coat Web Security Service, la politique se réfère aux contrôles de configuration qui restreignent ou
autorisent les éléments du réseau et du Web tels que les adresses IP et les catégories de filtrage de
contenu.

Figure 20: Schématisation de la gestion des politiques de sécurité

3.5 Accès Logs : Tableau de bord en temps réel

Chaque module Blue Coat Web Security Service fournit un tableau de bord de rapport, qui affiche des
résumés de haut niveau des activités de navigation Web qui s'appliquent au module sélectionné. En

47
outre, le tableau de bord « Vue d'ensemble » fournit des résumés généralement surveillés à partir de
tous les modules. [16]

Figure 21: Aperçu du tableau de bord du WSS

Conclusion
Le succès de presque toutes les organisations dans le monde en réseau d'aujourd'hui repose sur la
capacité à sécuriser la connexion Internet tout en veillant à ce que les utilisateurs aient accès à
l'information et aux ressources dont ils ont besoin pour faire leur travail. Au cours de ce chapitre, nous
avons enfin dévoilé le choix de la solution et nous avons montré les fonctionnalités des équipements
BlueCoat, en collaboration avec la communauté WebPulse et ses technologies de détection des
menaces, afin de garantir au client les outils dont il a besoin pour réduire les risques et maximiser les
activités productives en ligne.
Le chapitre suivant va s’appuyer sur la mise en place de la solution avec les différentes analyses
d’ingénieurs à faire pour valider certains choix.

48
 Chapitre 4

Chapi tre4 : Mise en place de la solution

Plan
1 Environnement de travail et dimensionnement de l’architecture cliente ................................... 50
1.1 Environnement de travail .......................................................................................................... 50

1.2 Dimensionnement de l’architecture cliente ............................................................................ 50

2 Mise en place de l’architecture hybride ............................................................................................ 51

2.1 Architecture cible avec les équipements BlueCoat ................................................................ 51

2.2 Choix technologiques et leurs mise en place .......................................................................... 53

2.3 Couplage du service Cloud avec le CASB d’Elastica ............................................................ 67

3 Mise en place d’un tunnel IPsec/VPN vers le Cloud. ................................................................... 68

3.1 Architecture réseau du site de Lyon ........................................................................................ 68

3.2 Description du problème .......................................................................................................... 69

3.3 Description de la solution : ....................................................................................................... 70

Introduction
Dans ce chapitre nous détaillons les différents axes du travail effectué pour la mise en place de la
solution conçue pour la sécurisation des flux et contenus avec la technologie BlueCoat en passant par
le dimensionnement de l’architecture du client à la configuration des tous les points convenus dans la
politique de sécurité et l’exposition des analyses à faire pour valider certains choix et résoudre certains
dysfonctionnements.

49
1 Environnement de travail et dimensionnement de l’architecture cliente
1.1 Environnement de travail
Les équipements de sécurité BlueCaot constituant la solution à mettre en place pour notre client sont :
 Un « ProxySG » en appliance physique avec une version de système d’exploitation SGOS
6.6.2.3.
 Un compte d’accès au service Cloud « Web Security Service » avec les différents modules
commandés pour la sécurité Web, la gestion de rapports et le couplage avec le service
CASB d’Elastica.
1.2 Dimensionnement de l’architecture cliente
Pour un dimensionnement répondant au mieux aux besoins de notre client, nous avons effectué une
capture complète de son réseau lors d’une période de la journée où le trafic est élevé. L’analyse des
informations sur le nombre de sessions actives, le nombre d’utilisateurs et sur la bande passante vers
Internet nous a permis d’avoir une connaissance de l’état de charge du réseau. Selon les caractéristiques
de l’architecture de notre client après le dimensionnement de son réseau, notre choix était de partir sur
un équipement « ProxySG S200-20-PR » parce qu’il a la capacité de couvrir jusqu’à 1200 employés,
6000 sessions actives et pour une bande passante de 25-30 Mbps pouvant atteindre les 60 Mbps.

Figure 22: Dimensionnement du ProxySG [11]

50
2 Mise en place de l’architecture hybride
2.1 Architecture cible avec les équipements BlueCoat

Figure 23: Architecture cible avec les équipements BlueCoat

2.1.1 Mise en place du proxySG

Après la phase de dimensionnement et le choix de l’équipement adéquat pour notre client. Nous allons
mettre en place le ProxySG. Nous avons décidé de déployer l’équipement en mode explicit avec une
GPO.
Lors de la configuration initiale du ProxySG, on lui attribue une adresse IP de gestion. La procédure
détaillée d’installation du ProxySG est décrite en Annexe.
Nous accèderons ainsi, via l’URL suivante : htttps://@ipProxySG :8082, à une interface utilisateur
pour la gestion de la passerelle Web qui se présente comme suit :

51
 Figure 24: Interface de gestion du ProxySG

A travers cette interface de gestion, nous avons configuré les services au niveau du proxy, l’interception
SSL, la gestion de la bande passante et des utilisateurs, le filtrage des contenus et des applications,
l’analyse et la protection contre les menaces, la traçabilité des évènements ainsi que l’application des
règles de sécurité conformément à la stratégie de la société.
Nous avons aussi configuré le ProxySG en mode « Reverse » pour écouter les requêtes sur le site web
de l’entreprise hébergé en interne et pour les transmettre à l'adresse IP du serveur. La configuration du
mode « Reverse » est décrite en Annexe.

Figure 25: configuration du ProxySG en mode Reverse

2.1.2 Mise en place du service « Web Security Service »

Lors de la commande du service Web Security Service auprès de Symantec/Bluecoat, des identifiants
relatifs au compte nous ont été communiqué tels que :
 Un identifiant d'abonnement « Subscription ID », qui a été envoyé dans un courriel de
bienvenue par Blue Coat.

52
  Une adresse e-mail de l'administrateur principal lié au compte du service.
Nous avons saisi ces informations au niveau du portail d’inscription au service Cloud pour commencer
la configuration du Web Security Service. Ainsi, le wizard de configuration initiale du service est lancé.
Une fois l’installation terminée, l’interface de gestion du service Cloud suivante s’affiche.

Figure 26: Interface de gestion du service Cloud

A travers cette interface de gestion, nous pouvons configurer le filtrage des contenus et des
applications, l’analyse et la protection contre les menaces, la gestion des journaux et des rapports,
l’interception du trafic SSL ainsi que l’application des règles de sécurité conformément à la stratégie de
la société.

2.2 Choix technologiques et leurs mise en place

Lors de la mission de mise en place de la solution sécurisée, nous avons tâché à répondre à tous les
besoins du client.
Dans cette partie, nous allons décrire les interventions que nous avons effectuées pour satisfaire chaque
besoin relevé précédemment.
2.2.1 Mise en place d’une architecture hybride (en locale et sur le Cloud)
Afin de concrétiser ce besoin, Nous avons mis en place une solution composée d’un équipement
physique, qui est le ProxySG de BlueCoat, au niveau du site central de Paris et une solution Cloud, qui
est le « Web Security Service » de BlueCoat, offrant une sécurité à tous les utilisateurs sur sites ou
mobiles.

53
Ainsi, le site central est protégé par le ProxySG en premier lieu et par le WSS grâce au chainage du
trafic.
Nous avons alors configuré le proxySG afin de transférer le trafic HTTP / HTTPS des
périphériques/clients en aval au service de sécurité Cloud. Pour cela, nous avons créé des hébergeurs
qui transmettent le trafic HTTP, HTTPS et SSL. Cette procédure est décrite en détails en Annexe.

Figure 27: Création des hébergeurs pour le chainage du trafic vers le Cloud

Nous avons mis en place une politique de transfert installée sur le ProxySG pour rediriger le trafic vers
l'hôte de transfert correct.
 Le trafic SSL non intercepté va être remis sur le port 8443 (chiffré).
 Le trafic http va être renvoyé sur le port 8080.
 Le trafic SSL intercepté (les informations d'authentification de l'utilisateur (en plus du
trafic) au service de sécurité Web) va être renvoyé sur le port 8084.

54
 Figure 28: Mise en place de la politique de redirection du trafic

Pour la redirection du trafic depuis les hôtes de transfert vers le service de sécurité Cloud, il est
nécessaire de configurer une localisation relative à leur emplacement. Nous avons alors ajouté au
niveau du portail du service Cloud la localisation du Proxy Forwarding.

Figure 29: Ajout de la localisation du site de Paris au niveau du WSS

Ensuite, Nous avons éliminé la liaison MPLS entre le site de Lyon et le site central et nous avons établi
un tunnel IPSec/VPN entre ce site distant et le service WSS pour sécuriser le trafic Web généré par
les utilisateurs. Pour cela, nous avons configuré un tunnel VPN au niveau du pare-feu « fortinet » de
ce site en saisissant les paramètres adéquats au service Cloud et au DataPod de la région parisienne. La
procédure détaillée est décrite en Annexe.

55
 Figure 30: Paramétrage du Tunnel IPSec/VPN au niveau de fortinet

Nous avons aussi configuré l’autre extrémité du tunnel au niveau du service Cloud, en définissant la
localisation du site de Lyon.

Figure 31: Ajout de la localisation du site de Lyon au niveau du WSS

Pour le site de Toulouse qui est protégé grâce à la méthode d’accès Proxy Explicit, nous avons
configuré l’URL du fichier PAC au niveau des navigateurs Web des utilisateurs et nous avons aussi
défini au niveau du service Cloud la localisation de ce site distant.

56
 Figure 32: Ajout de la localisation du site de Toulouse au niveau du WSS

Finalement, Nous avons configuré l’agent « Unified Agent » pour rediriger le trafic des utilisateurs
nomades vers le service Cloud.
2.2.2 Mise en place de l’authentification des utilisateurs
Suite à la réunion de mise en place de la politique de sécurité, l’authentification des différents
utilisateurs était l’un des points primordiaux à mettre en place.
Nous avons étudié la situation de l’architecture cliente afin de choisir un mode d’authentification
suffisant et adéquat.
Les utilisateurs du site central de Paris ont un nombre conséquent. La configuration d’un mode
d’authentification robuste au niveau du ProxySG est essentielle. Nous sommes arrivés à convaincre
l’entreprise cliente de mettre en place le mode d’authentification IWA avec agent BCAAA et avec le
type « Kerberos ». En effet, c’est le protocole d'authentification recommandé pour IWA car il est plus
sécurisé que NTLM ou Basic et il met le moins de charge sur le réseau.

57
Nous allons commencer par faire une description du mode d’authentification IWA BCAAA avec
Kerberos.

Figure 33: Description du fonctionnement d'un IWA BCAAA [18]

1. Le client envoie une requête à un proxy pour une URL. Le ProxySG vérifie la substitution
(cookie ou IP). Si la souscription est présente et valide, la demande est considérée comme
authentifiée et le ProxySG ne communique pas avec BCAAA.
2. Si l'authentification doit être effectuée, le ProxySG envoie un défi d'authentification au client.
3. Dans notre cas, Le client décide d'utiliser Kerberos. Il contacte le Centre de distribution de
clés (KDC) sur le contrôleur de domaine et demande un ticket Kerberos.
4. Le KDC envoie le ticket au client.
5. Le client renvoie sa demande au ProxySG. La demande comprend maintenant une en-tête
d'autorisation ainsi que le ticket Kerberos.
6. Le ProxySG envoie une demande d'authentification, y compris le ticket Kerberos à BCAAA.
7. BCAAA transmet cette demande à l'API Windows « AcceptSecurityContext() » pour
authentifier l'utilisateur. L'API Windows décide si la requête est valide et renvoie la valeur à
BCAAA.
8. BCAAA passe le résultat de l'authentification au proxySG qui répond par la suite au client. [18]

Nous avons alors configuré ce mode d’authentification au niveau du ProxySG. La procédure est décrite
en détails en Annexe.

58
 Figure 34: Configuration de l’IWA BCAAA avec kerberos

Une fois le domaine d’authentification est bien configuré, nous avons appliqué au niveau de l’interface
de gestion des politiques de sécurité (VPM) du proxySG la règle suivante qui permet d’appliquer
l’authentification pour tous les utilisateurs du site central.

Figure 35: Définition d'une politique pour l'authentification BCAAA

Pour les utilisateurs des sites distants et les utilisateurs nomades, vu que leur nombre est réduit et
l’architecture au niveau des sites est assez simplifiée, Nous avons opté pour une solution
d’authentification légère. Elle consiste à une simple correspondance entre l’adresse IP de la machine
et le nom d’utilisateur. Pour cela, nous avons configuré un agent d'authentification que nous avons
installé sur le contrôleur de domaine Active Directory du site central. Cet agent permet de transmettre
les informations des utilisateurs et des groupes au service de sécurité Cloud et de surveiller l'activité de
connexion et de déconnexion des utilisateurs du domaine pour créer une matrice de correspondance
IP/nom d’utilisateur.

59
Nous avons alors configuré cet outil d’authentification au niveau du service Cloud. La procédure est
décrite en détails en Annexe.

Figure 36: Configuration du Auth_Connector

2.2.3 Mise en place d’une politique de filtrage uniforme et centralisée en fonctions

des catégories et des applications
Avec l’avènement du Web 2.0, les sites web peuvent devenir des applications aussi riches que des
logiciels installés sur un système d’exploitation. Afin de fournir des moyens d’identifier et de contrôler
ces nouveaux usages, nous avons exploité la technologie « Webfilter/WebPulse » et nous avons
manipulé au niveau de l’interface de gestion de la politique de sécurité du service Cloud les fonctions
spécifiques aux applications et aux catégories. Nous avons défini ainsi des règles centralisées et bien
granulées pour s’assurer que tous les utilisateurs protégés par le service Cloud ne peuvent pas accéder
aux applications et catégories indésirables et malveillantes.
La règle de filtrage suivante empêche tous les utilisateurs appartenant au groupe « SNAISO/DT » et
qui sont protégés grâce à la méthode d’accès « Proxy Forwarding » c’est-à-dire ceux du site central de
Paris d’accéder à des pages Web catégorisées comme « Adult mature content » pendant les horaires de
travail.

60
 Figure 37: Mise en place d'une règle de filtrage par catégorie

Cette règle de filtrage empêche tous les utilisateurs sur site ou mobiles à utiliser certaines applications
telles que « Facebook ».

Figure 38: Mise en place d'une règle de filtrage par application

61
Dans le cadre d’améliorer la mise en place de la politique de filtrage, nous avons mis en place une page
personnalisée à afficher à l’utilisateur dans le cas de l’application de règles de restrictions.
Il s’agit d’une page d'exception qui permet de prévenir, conseiller et bloquer les utilisateurs en fonction
de leurs tentatives d'accès à des sites Web particuliers.
Pour mettre en place la page d’exception, nous l’avons défini au niveau de l’interface de gestion du
ProxySG.

Figure 39: Définition d'une politique de sécurité pour l’affichage de la page d'exception

2.2.4 Analyse du trafic chiffré par une interception SSL

L’interception SSL et l’analyse du trafic chiffré veillent à ce que le trafic web sécurisé par le protocole
SSL puisse être traité et mis à la disposition des autres fonctions de filtrage. Pour cela, nous avons
configuré au niveau du ProxySG, en premier lieu, les services pour intercepter les flux HTTPS.

Figure 40: Configuration des services pour l'interception des flux SSL

Nous avons créé, en deuxième lieu, un certificat de confiance auto-signé par le ProxySG afin de
déchiffrer le trafic crypté et l’analyser en toute sécurité.

62
 Figure 41: Création d'un certificat de confiance auto-signé par le ProxySG

Enfin, nous avons mis en place une règle de sécurité pour appliquer cette interception sur le trafic
généré. Nous n’avons pas activé l’interception SSL pour le trafic catégorisé dans « Finance », « Banque »
et « Santé » parce que nous ne pouvons pas déchiffrer leurs contenus vu les informations confidentielles
que l’utilisateur pourra saisir.

Figure 42: Règle de sécurité pour l'interception SSL du trafic

Nous avons aussi activé au niveau du service Cloud, l’interception du trafic chiffré pour l’appliquer sur
tout le flux sortant des sites distants et des utilisateurs nomades et nous avons téléchargé le certificat
SSL depuis le servie. Ce certificat sera un certificat de confiance et tout le trafic web sécurisé sera
envoyé à la plateforme afin d’inspecter son contenu. Nous importons le certificat téléchargé dans la
stratégie de groupe de l’AD dans l’autorité de certification racine afin que tous les utilisateurs puissent
le désigner comme certificat de confiance.

63
 Figure 43: Configuration de l'interception SSL au niveau du service Cloud

2.2.5 Gestion de la bande passante et mise en place de l’accélération web

La bande passante est connue pour être une ressource rare et chère. Dans notre architecture, le
problème de gestion de bande passante peut se poser au niveau du site central de Paris vu le nombre
conséquent des utilisateurs et du coup le nombre de sessions actives et du trafic généré. Le proxySG
que nous avons intégré au niveau de ce site peut palier à ce problème vu la fonctionnalité de mise en
cache dont il dispose. En effet, la mise en cache pour rendre l'accès à l'information par les clients plus
rapide et libère ainsi la bande passante.
Nous avons ainsi configuré une règle au niveau de l’interface de gestion de la politique de sécurité pour
activer cette fonctionnalité au niveau du ProxySG.

Figure 44: Mise en place du caching

La deuxième est une page de coaching qui s'affiche lorsqu'un utilisateur visite un site web bloqué par
une stratégie de filtrage de contenu. Cette page explique pourquoi le site est bloqué et les conséquences
d'un accès non autorisé.

64
Pour mettre en place la page de coaching, nous avons défini une page personnalisée relative à notre
client et nous l’avons inséré au niveau de l’objet action de la règle de sécurité.

Figure 45:Mise en place de la page de coaching

2.2.6 Gestion et analyse des tableaux de bord et des rapports

La mise en place de la traçabilité permet de suivre le trafic pour l'ensemble du réseau ou des
informations spécifiques sur les utilisateurs ou les services. Chaque fois qu'un utilisateur demande une
ressource, Les informations sur cette demande sont enregistrées dans un journal. L’analyse de log est
un point essentiel pour la sécurisation d’une architecture. En effet, les rapports générés permettent
d’avoir une visibilité sur le trafic et facilite le diagnostic de certains problèmes techniques. Nous avons
alors configuré au niveau du ProxySG la traçabilité du trafic qui va être présenté par la suite au niveau
de la solution Cloud sous forme de graphes et de rapports facilement lisibles et interprétables.
Pour avoir un journal du trafic transitant par le ProxySG, nous avons, en premier lieu, autorisé la
traçabilité au niveau de l’interface de gestion du proxy.

65
 Figure 46: Activation de la traçabilité des évènements

Nous avons, en deuxième lieu, mis en place une « Web Access Layer » dans laquelle nous avons activé
le « logging » au niveau de l’objet action de la règle.

Figure 47: Définition d'une politique de sécurité pour mettre en place la traçabilité

2.2.7 Mise en place de fonctions de sécurisation contre les attaques DOS

Pour sécuriser le réseau contre les attaques DoS et DDoS, Nous avons manipulés les commandes
offertes au niveau du ProxySG afin de définir pour chaque groupe de clients, un nombre de connexions
simultanées maximales, un nombre maximum d'échecs autorisés sur une période de temps et pour
chaque serveur un nombre maximal de requêtes et une limite pour le nombre d'échecs pour les clients.

66
 Figure 48: Sécurisation du client contre une attaque DOS

Figure 49: Sécurisation du Serveur contre une attaque DOS

2.3 Couplage du service Cloud avec le CASB d’Elastica

La solution mise en place jusqu’à maintenant permet de répondre aux besoins de notre client en termes
de sécurisation et de protection contre les menaces lié à l’accès à Internet. Pour raffiner notre solution,
nous avons décidé d’exploiter un service d'audit CASB fourni au niveau du service Cloud qui offre une
visibilité à 15 000 applications Cloud sur plus de 60 attributs par application. Ce service permet aussi
de mettre en place une politique évolutive pour contrôler les applications « Shadow IT » et l'accès aux
applications en Cloud.
Le service d'audit CASB est une intégration entre le service de sécurité Cloud et la plate-forme Elastica
CloudSOC acquise par Blue Coat. Le CloudSOC contient une applet Audit, qui offre une visibilité
granulaire des applications Web.
Nous avons alors configuré cette licence complémentaire au niveau du service Cloud afin de pouvoir
nous connecter à cette applet Audit depuis le portail de service. Ainsi, nous pouvons afficher les
rapports d'application Web et les analyser pour affiner d’avantage les politiques d'accès et de sécurité
des applications Web. [16]

67
 Figure 50: Intégration du module CASB au service Cloud

3 Mise en place d’un tunnel IPsec/VPN vers le Cloud.

Lors de la mission d'intégration du service Cloud dans le site de Lyon, Nous avons décidé de monter
un tunnel IpSec/VPN entre le pare-feu « fortinet » de l’entreprise et le proxy de la solution Cloud
BlueCoat.
Pour la configuration du tunnel, nous avons spécifié une adresse publique du côté du service Cloud
qui est celle du centre de données « DataPod » pour la France et l’autre adresse du côté du pare-feu
qui est attribuée grâce au protocole PPPoE du boitier Orange.
Pour rediriger le trafic du boitier Orange vers le « fortinet », nous avons mis une règle de redirection
au niveau du boitier qui spécifie que tout trafic reçu aura comme destination la passerelle du pare-feu.
Au cours de la configuration, nous avons rencontré un problème avec le tunnel IpSec/VPN.
Nous allons vous décrire dans cette partie l’origine du dysfonctionnement et la procédure effectuée
pour palier à ce problème.
3.1 Architecture réseau du site de Lyon
Voici un aperçu de l’architecture réseau du site de Lyon une fois la mission d'intégration du service
Cloud de Bluecoat effectuée.

68
 Figure 51: Architecture simplifiée du réseau du site de Lyon

3.2 Description du problème

Le problème rencontré est que la phase1, qui consiste à l'établissement d'une session
sécurisée ISAKMP entre les deux extrémités, a échoué. Nous avons eu comme message d’erreur:
“Rejected an IKE packet on eth*/* from x.x.x.x:500 to x.x.x.x:500 with cookies xxxx because
The peer sent a packet with a message ID before Phase 1 authentication was done.” [19]
Nous avons effectué plusieurs recherches sur des forums relatifs au boîtier « Orange » ainsi que
plusieurs tests de troubleshooting via les commandes suivantes :
# diagnose vpn tunnel list
# diagnose debug flow
# diagnose vpn ike log filter name <phase1-name>
# diagnose debug app ike -1
# diagnose debug enable
Les différents diagnostiques ont révélé que l’origine du problème revient au fait que:
 la fibre attend une réponse avec un tagging spécifique venant d’une interface logique Vlan
ayant pour ID=835. [20]
 Il existe un double nattage effectué sur les deux réseaux privés.

69
 3.3 Description de la solution :

Figure 52: Architecture simplifiée de la solution apportée au réseau du site de Lyon

Afin de résoudre ce problème, la solution était de :

 Contourner le boîtier « Orange » c’est-à-dire que la fibre devient directement connectée
au pare-feu.
 Ajouter au niveau de l’interface WAN du firewall, une interface logique Wan1.835 avec le
Tag attendu par la fibre.

Figure 53: Ajout de l'interface logique au niveau du firewall

 Configurer le protocole PPPoE sur l’interface logique.

70
 Figure 54: Configuration du protocole PPPoE sur l'interface logique

Suite aux différentes modifications que nous avons apportées à l’architecture, le tunnel a été monté
avec succès et le trafic y transite sans problème.

Conclusion
A la fin de ce quatrième chapitre, nous venons de terminer l’intégration et la configuration de tous les
éléments de la solution de sécurisation de l’architecture de notre client. Nous allons ainsi pouvoir
passer à la phase des tests pour la phase de validation de la solution.

71
 Chapitre 5

Chapi tre5 : Tests et validation

Plan
1 Vérification de la configuration du ProxySG ................................................................................. 72
2 Vérification de la mise en place de la solution................................................................................ 73
2.1 Vérification de la mise en place d’une architecture hybride ................................................. 73

2.2 Vérification de la mise en place de l’authentification des utilisateurs ................................. 77

2.3 Vérification de la mise en place d’un filtrage par catégorie / applications......................... 79

2.4 Vérification de la mise en place de l’interception SSL. ......................................................... 81

2.5 Vérification de la gestion de la bande passante ...................................................................... 82

2.6 Vérification de la traçabilité des historiques d’accès.............................................................. 83

2.7 Vérification de la configuration des fonctions de sécurisation contre les attaques DOS 83

3 Vérification du couplage du Service de Sécurité Web avec un CASB ........................................ 84

Introduction
Après avoir expliqué et configuré les différentes parties convenues de notre solution de sécurisation,
nous allons procéder dans ce dernier chapitre à présenter les résultats de certains tests pour vérifier
que la solution mise en place répond convenablement aux exigences de l'entreprise cliente.

1 Vérification de la configuration du ProxySG

Nous avons consulté l’onglet « Health Checks » au niveau du proxy et nous avons vérifié que les
fonctionnalités de bases du proxySG sont bien configurées. Aussi, L’authentification avec kerberos, la
redirection du trafic du site central vers le service Cloud et le mode reverse du proxySG ont un statut
vert « OK ».

72
 Figure 55: Vérification de la bonne configuration du ProxySG

2 Vérification de la mise en place de la solution

2.1 Vérification de la mise en place d’une architecture hybride
Dans cette partie, nous allons valider les différentes connectivités des sites et des utilisateurs mobiles
avec le service de sécurité Cloud.
Pour le site central de Paris, nous avons bien vérifié précédemment au niveau du proxySG que les
hôtes de redirections sont bien fonctionnels. Nous remarquons aussi qu’au niveau du service Cloud,
la localisation du « Proxy Forwarding » est bien détectée comme le montre la figure suivante.

Figure 56: Vérification de la connectivité côté WSS

Nous nous sommes aussi connectés depuis le site central et nous avons testé la page de démonstration
de connectivité « demo.threatpulse.com ». Nous avons bien vérifié que nous sommes protégés par le
service de sécurité Cloud avec le message « You are Protected ».

73
 Figure 57: Vérification de la connectivité côté client (Paris)

Pour valider la partie d’intégration du service WSS au niveau du site de Lyon, nous avons vérifié la
connectivité au niveau du service Cloud, du pare-feu et du client.
Nous remarquons alors qu’au niveau du service Cloud, la localisation du « IpSec/VPN » est bien valide.

Figure 58: Vérification de la connectivité côté WSS

Nous avons aussi consulté le statut du tunnel IPSec/VPN au niveau au niveau du pare-feu. Nous
constatons qu’il est en mode « up » et qu’il y a du trafic entrant et du trafic sortant.

Figure 59: Vérification de la connectivité côté fortinet

Nous nous sommes aussi connectés depuis le site de Lyon et nous avons testé la page de démonstration
de connectivité. Nous avons bien vérifié que nous sommes protégés par le service de sécurité Cloud
avec le message « You are Protected ».

74
 Figure 60: Vérification de la connectivité côté Client Lyon

Lors de la vérification de l’intégration du Web Security Service sur le site de Toulouse avec la méthode
Pac file nous avons vérifié la connectivité de la localisation du « ProxyExplicit » au niveau du service
Cloud, nous remarquons alors que est bien valide grâce au statut vert.

Figure 61: Vérification de la connectivité côté WSS

Nous avons accéder depuis ce site à la page de démonstration de la connectivité .Nous avons bien
vérifié que nous sommes protégés par le service de sécurité Cloud avec le message « You are
Protected ».

75
 Figure 62: Vérification de la connectivité côté client Toulouse

Finalement pour les utilisateurs nomades, nous avons consulté le statut de l’agent « BlueCoat Unified
Agent » installé sur leurs machines. Nous vérifions que l’agent est bien connecté au service Cloud.

Figure 63: Vérification de la connectivité de l'Unified Agent

76
Nous avons accéder depuis le navigateur d’une machine distante à la page de démonstration de la
connectivité. Nous avons bien vérifié que nous sommes protégés par le service de sécurité Cloud avec
le message « You are Protected ».

Figure 64: Vérification de la connectivité du client nomade

2.2 Vérification de la mise en place de l’authentification des utilisateurs

Lorsque nous avons effectué une capture réseau au niveau du proxySG du site central, nous avons
remarqué que l’authentification est bien requise pour tout utilisateur. Nous pouvons ainsi vérifier que
l’authentification mise en place est bien une authentification avec un agent BCAAA de type
« kerberos ».

77
 Figure 65: Vérification de la configuration de l'authentification

Pour les utilisateurs des sites distants et les utilisateurs nomades, l’authentification s’effectue avec
l’agent d’authentification « Auth_Connector ».Nous avons commencé par vérifier la connectivité de
l’agent au niveau du service Cloud.

Figure 66: Connectivité de l'agent d'authentification

Ensuite, nous avons vérifié que, lors de la synchronisation de l’agent avec l’AD, tous les utilisateurs
sont importés au niveau du service « Web Security Service ».

78
 Figure 67: Synchronisation entre l'AD et le « Auth_Connector »

Ainsi, lorsqu’un utilisateur distant se connecte un Internet, une fenêtre d’authentification s’affiche pour
la saisie des identifiants. Si les utilisateurs ne se sont pas authentifiés la navigation Web sera bloquée.

Figure 68: "Pop-up" d'authentification au service WSS

2.3 Vérification de la mise en place d’un filtrage par catégorie / applications

Afin de vérifier la mise en place de la règle de filtrage par catégorie, Nous nous sommes connectés
avec un compte appartenant au groupe « SNAISO\DT » depuis le site central de Paris et nous avons
accédé à une page de test catégorisé comme « Adult Content » pendant les horaires de travail.
L’accès nous a été refusé conformément à la règle de sécurité mise en place au niveau du service Cloud.

79
 Figure 69: Filtrage par catégorie

Pour vérifier que la règle mise en place pour le filtrage des applications est bien appliquée, nous nous
sommes connecté depuis le navigateur d’un utilisateur mobile et nous avons accédé à « Facebook ».
L’accès nous a été refusé conformément à la règle de sécurité mise en place au niveau du service Cloud.

Figure 70:Filtrage par application

De plus, lorsque nous avons accéder à une URL non catégorisée, nous avons vérifié que la page
d’exception créé pour notre client a été affichée.

80
 Figure 71: Page d'exception pour une URL non catégorisée

2.4 Vérification de la mise en place de l’interception SSL.

Pour vérifier la configuration de l’interception SSL au niveau du ProxySG mis en place dans le site
central, Nous nous sommes connectés à des sites Web en https et nous avons accédé aux sessions
actives au niveau du proxy. Ainsi,nous avons remarqué dans la colonne « Protocol », la valeur HTTPS
fwd qui prouve qu’une interception SSL a eu lieu.

Figure 72: Vérification de l'interception SSL au niveau du ProxySG

Pour vérifier l’interception SSL du côté du service Cloud WSS, Nous avons accédé au site
https://www.google.fr depuis un utilisateur mobile et nous avons vérifié au niveau du certificat qu’il
est bien celui du « Cloud Services Root CA ».

81
 Figure 73: Vérification de l'interception SSL au niveau du service Cloud

2.5 Vérification de la gestion de la bande passante

Pour vérifier la gestion de la bande passante, nous avons accédé à un site web qui représente un risque
de dépassement de la bande passante allouée, nous avons vérifié qu’une page de coaching est apparue
afin d’alerter l’utilisateur d’un éventuel incident.

Figure 74: Vérification d'apparition de la page de coaching

82
 2.6 Vérification de la traçabilité des historiques d’accès.
En ce qui concerne la traçabilité des logs, nous avons accédé au journal du proxySG dans la fenêtre
« Access Logging » et nous avons vérifié qu’il existe des lignes de traçabilité des évènements.

Figure 75: Vérification de l'activation de la traçabilité

2.7 Vérification de la configuration des fonctions de sécurisation contre les attaques DOS
Pour vérifier que les fonctions de sécurisation du réseau interne contre les attaques Dos sont
opérationnelles, nous avons accédé au site web hébergé en interne. Nous avons actualisé la page
plusieurs fois. Lorsque la limite a été atteinte un message d’avertissement est apparu.

Figure 76: Vérification de l'atteinte de la limite de connexion

Nous avons continué à actualiser la page alors notre adresse Ip a été bloquée. Nous avons pu consulter
ça au niveau de l’interface de gestion du ProxySG.

83
 Figure 77: Vérification que l'adresse ip est bloquée au niveau du ProxySG

3 Vérification du couplage du Service de Sécurité Web avec un CASB

Lorsque nous avons accédé à l’onglet « Cloud App audit » au niveau du service Cloud, une redirection
vers le service CASB d’Elastica a été effectuée.
Nous avons remarqué qu’il y bien les informations relatives aux applications installées sur les postes
utilisateurs ainsi qu’une possibilité de gestion avancée de rapport à partir des journaux du proxySG
BlueCoat.

Figure 78: vérification du couplage du WSS avec le CASB

84
Conclusion
Au terme de ce chapitre, nous venons de conclure la dernière phase du projet, à savoir la validation de
la solution conçue et mise en place dans l’architecture de notre client. Cette architecture offre
désormais une sécurisation avancée des flux et contenus web comme exigés par l'entreprise cliente.
Cette solution a été intégrée et validé par l'entreprise. Et nous restons à sa disposition pour un support
continue durant les 3 prochaines années.

85
 Conclusion générale

Au terme de notre projet, nous dressons le bilan de notre travail effectué au sein de l’entreprise 2SB et
pour le compte de l’un de ces clients.
Le travail entrepris lors de ce projet de fin d’études avait comme finalité de mettre en place une
solution de sécurisation des flux et contenu avec la gamme de produits BlueCoat.

Durant ce projet, nous avons montré une nouvelle définition de la sécurité Web dans une véritable
architecture hybride avec une politique universelle qui permet de contrôler tous les utilisateurs sur un
service de sécurité Web basé sur le Cloud.
Nous avons aussi pu intégrer une protection avancée contre les menaces et les risques liés au Web et
la sécurité des données.

Ce travail nous a permis d’acquérir beaucoup de connaissances concernant la sécurité informatique de

point de vue concept général et de puis vue prévention contre la cybercriminalité.
Aussi, il nous a apporté de nombreux avantages aussi bien sur le plan technique que personnel. Sur le
plan technique, ce stage était une occasion pour appliquer et exploiter les connaissances théoriques
acquises au cours de notre formation académique à l’Institut National des Sciences Appliquées et de
Technologie. Sur le plan personnel, cette expérience nous a offert une bonne préparation à notre
insertion professionnelle. Elle fut pour nous une expérience enrichissante et complète qui nous a assuré
l’intégration et la collaboration avec le personnel de l’entreprise d’une part et l’interaction avec le client.
Nous estimons avoir satisfait les besoins initialement fixés.

Nous proposons aussitôt en guise de perspectives d’étendre les fonctionnalités de la passerelle Web en
local et sur le Cloud en ajoutant d’autres règles qui renforce la stratégie de sécurité du client, de
renforcer le mode d’authentification des utilisateurs à distance avec une authentification forte et de
mettre en place la prévention des fuites de données (DLP) en évitant la perte d’éléments de propriété
intellectuelle, en garantissant la conformité aux réglementations et en fournissant des données
d’investigation numérique en cas d’infraction.

86
 Bibliographies et Webographies

[1] http://www.2sb.fr [consulté le 12 juin 2017]

[2] https://www.bluecoat.com/fr/innovation-for-the-cloud-generation?src=&lg=&elqEmailName=
[consulté le 13 juin 2017]

[3] https://www.techopedia.com/definition/24756/rss-feed [consulté le 25 juillet 2017]

[4] https://www.techopedia.com/definition/23885/web-content [consulté le 25 juillet 2017]

[5] https://etskblog.wordpress.com/2014/05/17/comment-et-avec-quoi-les-systemes-sont-ils-
attaques/ [consulté le 30 juin 2017]

[6] ATP for dummies

http://be.security.westcon.com/documents/48318/ATP%20for%20Dummies.pdf [consulté le 30
juin 2017]

[7] Définition d’une menace avancée : http://www.lemagit.fr/definition/Menace-persistante-

avancee-APT [consulté le 30 juin 2017]

[8] BCCPA Student Manual v4.2

Le support de cours BCCPA

[9] Bluecoat Secure Web Gateway Appliance https://www.symantec.com/fr/fr/products/secure-

web-gateway-proxy-sg-and-asg [consulté le 27 juillet 2017]

87
[10] Cisco Web Security Appliance
https://www.cisco.com/c/en/us/products/collateral/security/content-security-management-
appliance/datasheet-c78-729630.html [consulté le 12 juillet 2017]

[11]Bluecoat ProxySG https://www.bluecoat.com/documents/download/1173ad34-88d3-4077-

8979-0c0f43c3a5c8/a91e7b81-16a5-4560-b8e9-c7c0e26fbc6f [consulté le 20 juillet 2017]

[12] McAfee Secure Web Gateway Appliance https://www.mcafee.com/fr/resources/data-

sheets/ds-web-gateway.pdf [consulté le 12 juillet 2017]

[13] zscaler Secure Web Gateway Appliance https://www.zscaler.com/resources/solution-

briefs/swg-web-security.pdf [consulté le 12 juillet 2017]

[14] SWG-PlayBook-ASG.pdf [consulté le 12 juillet 2017]

[15] https://resource.elq.symantec.com/gartner-magic-quadrant-secure-web-gateways-2016 [consulté

le 12 juillet 2017]

[16] https://portal.threatpulse.com/#help|userGuide [consulté le 27 juillet 2017]

[17] https://www.symantec.com/content/dam/symantec/docs/data-sheets/web-security-service-
en.pdf [consulté le 20 juillet 2017]

[18] BCCPP Student Manual v4.2

Le support de cours BCCPP

[19] http://cookbook.fortinet.com/ipsec-vpn-troubleshooting/ [consulté le 15 mai 2017]

[20]https://benjamin.sonntag.fr/Se_debarasser_de_la_livebox_fibre_orange_pppoe_mode_d_empl
oi_ [consulté le 15 mai 2017]

88