Bonne continuation aux GMSICP2015 !

Encore une promotion de GMSI qui se termine, rendez-vous à la rentrée pour ceux qui poursuivent et en Mars 2018 pour les autres lors de la cérémonie des diplômés 2017.

Merci aux tuteurs, intervenants et membres de jury sans qui cet oral de fin d’année n’aurait pas pu se dérouler aussi bien. Encore bravo à tous !

WP_20170721_11_42_23_Pro

WP_20170721_11_41_47_Pro

Email : comment améliorer la délivérabilité et réduire les abus liés au phishing par Geoffrey en RISR2015

 

1. Présentation

Depuis la démocratisation de l’informatique en 1975, notamment par Microsoft, le volume de données généré ne cesse de croitre chaque année. La ou en 1975, 2 Mo suffisaient à supporter le système d’exploitation et les fichiers de l’utilisateur, en 2010 la création de données dans le monde dépassait le téraoctet par jour, en 2020 les experts estiment que nous en créeront 109 téraoctets par jour, et nous produiront plus données que nous pourrons en stocker.

Ainsi la protection d’une telle quantité de données est devenue l’un des enjeux majeurs du 21eme siècle, car nombre de données numériques sensibles sont accessibles via le réseau des entreprises. Et pour qui aurait à intérêt à les exploiter ou les « prendre en otage », ces données sont une vraie mine d’or, et tous les moyens sont bon pour les récupérer ou les détruire, exposant les utilisateurs, souvent néophyte, à des dangers qu’ils ne soupçonnent pas.

Parmi ces dangers nous pouvons en distinguer 2 groupes, tout d’abord les menaces directes :

– Virus / vers / chevaux de Troie

– Malware

– Ransomware

– Spam

Actuellement, nous avons à disposition plusieurs solutions (antivirus, antimalware, antispam) qui nous permette de lutter efficacement (sans être infaillible) et de protéger les utilisateurs de nos systèmes d’informations, même si bien entendu la première des protections reste la sensibilisation.

Ensuite nous avons les menaces indirectes :

– Man In the Middle

Par exemple, en temps normal, le transite des données se fait (pour schématiser) du point A au point B, mais si un pirate se met au milieu, il est capable de capter les données, soit pour les récupérer et les exploiter, soit pour les corrompre et faire du dégât dans le système d’information cible.

– L’usurpation d’identité par mail,

Il est facile de vérifier l’identité de son interlocuteur par téléphone par exemple, vous recevez un appel, vous voyez le numéro s’afficher, le nom de la personne si elle est dans vos contact, puis vous décrochez, vous entendez sa voix, vous êtes sûr que c’est elle, sauf si vous tombé sur un(e) bon(ne) imitateur(trice), ou la NSA qui dispose de système perfectionner pour imiter une voix, ce qui reste très peu probable …

Mais le scénario n’est pas le même quand vous recevez un mail, comment pouvez-vous vérifier l’identité de l’expéditeur ?

Pour ce faire, plusieurs bonnes pratiques peuvent être appliquer afin de certifier a votre destinataire que vous êtes bien qui vous prétendez être.

2. FCrDNS

La première mesure à mettre en place (qui devrait être une bonne pratique systématique d’ailleurs) si elle n’est pas déjà existante, est la création d’un enregistrement Pointeur (PTR) dans la zone de recherche indirecte de votre serveur DNS Publique (contenant le domaine de vos emails). Cela permettra notamment au contrôle de réception de l’email de vérifier si les serveurs DNS sont en pleine maitrise du propriétaire émetteur. C’est une forme d’authentification établissant une relation fiable entre le propriétaire du nom de domaine et le propriétaire de la machine qui a initiée la requête SMTP.

image

3. FQDN HELO

La seconde mesure à vérifier sur les serveurs de messagerie sortants est le nom de domaine configuré lors de la réponse FQDN HELO, il doit de l’ordre de « monentreprise.fr » et non « monentreprise.local ». Dans les faits, ceci n’est pas bloquant pour le transfert du message mais distingue les serveurs correctement installés des autres pour un anti-spam. Quand un serveur mail établi une connexion, il se présente avec la commande HELO. Par exemple: « HELO mail.company.com ». Le nom de serveur fourni doit être conforme FQDN (Fully Qualified Domain Name). Ce qui veut dire que ce nom est valide et joignable sur internet.

image

4. Sender Policy Framework

La troisième mesure à mettre en place consiste à créer un type d’enregistrement DNS de type TXT qui détermine les serveurs de messagerie autorisés à envoyer des messages au nom de votre domaine. Cette norme de vérification s’appelle le Sender Policy Framework (SPF).

Voici quelques exemples de ce qu’il est possible de faire avec les enregistrements SPF :

v=spf1 ip4:5.5.5.0/24 –all

Autorise toutes les adresses IP comprises entre 5.5.5.1 et 5.5.5.254

v=spf1 a:mailers.example.com –all

Autorise toutes les adresses IP de tous les enregistrements de type A pour le domaine

v=spf1 mx/24 mx:offsite.domain.com/24 -all

Autorise toutes les adresses IP de tous les enregistrements de type MX pour le domaine avec une marge de range (Peut être qu’un serveur MX de domaine a reçu un mail sur une adresse IP, mais a envoyé le mail sur une adresse IP différente mais proche)

image

5. Domain Key Identified Mail

Nous pouvons également signer chaque mail sortant en ajout une signature numérique à l’en-tête des messages de façon à ce que le processus anti-spam du destinataire puisse vérifier que le mail n’a pas été déformé depuis l’expédition en décodant la signature avec la clé publique contenue dans un enregistrement DNS. Cela permet de lutter contre le spoofing.

image

6. Dmarc

DMARC (Domain-based Message Authentication, Reporting and Conformance) est une norme d’authentification des emails basée sur SPF et/ou DKIM. Il ne remplace pas ces protocoles mais il va les rendre plus intelligent en les unissant.

Il standardise la façon dont un MTA destinataire doit gérer un message dont les vérifications DKIM et/ou SPF ont échoué.

DMARC est implémenté sous la forme d’un enregistrement txt dans le DNS du MTA expéditeur.

Par exemple :

v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@mondomaine.com

DMARC possède 3 politiques :

– none

Avec cette configuration activée « en monitor mode », l’adresse courriel indiquée (dans l’option mailto) reçoit des rapports quotidiens des fournisseurs en ce qui concerne le nombre de messages qui ont été reçus et qui ont passés les contrôles de la politique ou non.

– Quarantine

Avec cette configuration activée, les messages qui ne passent les contrôles de politiques sont mis en quarantaine.

– Reject

Avec cette configuration activée, les messages qui ne passent les contrôles de politiques sont rejetés par le MTA destinataire.

La balise rua permet à l’administrateur du MTA expéditeur de recevoir des rapports quotidiens. Les rapports quotidiens sont présentés au format XML. Leur lecture permet de mieux comprendre les flux de messages. Ces rapports aident à vérifier que les sources de courrier sortant sont correctement authentifiées. Lorsque des règles de blocage sont en place, les rapports permettent également aux administrateurs de réagir rapidement si une nouvelle source de courrier apparaît en ligne ou si la configuration d’une source existante n’est plus appliquée.

DMARC demeure l’arme la plus puissante jamais conçue pour lutter contre les tentatives d’usurpation d’identité (spoofing) et d’hameçonnage (phishing). Ce protocole d’authentification des emails a transformé de manière radicale le paysage des pratiques frauduleuses ciblant la messagerie électronique et enrayé des tactiques de phishing de longue date, protégeant des marques, l’image des sociétés sur Internet, des effectifs et des usagers.

HyperConvergence par Kevin et John en RISR2015

I. Hyperconvergence (ou Infrastructure Hyperconvergée)

A. Introduction

Depuis quelques années une nouvelle tendance prend de l’ampleur au sein des infrastructures systèmes, il s’agit des Infrastructures Hyperconvergées.

Au cours de cet article, nous vous présenterons cette nouvelle tendance, tout d’abord par un rappel de définitions. Qu’est ce qu’un infrastructure hyperconvergée, par opposition aux infrastructures classiques actuelles.

Nous évoquerons ensuite les acteurs de ce nouveau marché et nous mettrons en lumière deux d’entre eux, leaders respectifs dans leur domaine à savoir Nutanix et Rubrik.

Enfin nous verrons la part actuel de ce marché et son potentiel.

II. Définitions

A. Les infrastructures classiques

La majorité des infrastructures systèmes que l’on connaît se base sur des éléments distincts à savoir : les serveurs, les équipements réseaux et le stockage.

image

Souvent, le réflexe pour un informaticien sera de choisir ce qui se fait de mieux dans chacun de ces domaines, en pensant rendre la totalité de l’infrastructure solide.

Or cela n’est pas forcément vrai. Choisir ce qui se fait de mieux dans chaque domaine ne garantie pas forcément l’interopérabilité des éléments entre eux.

En outre chaque élément étant distinct, cela nécessite des ressources d’administration pour chacun (administrateur système, réseau et stockage) et des compétences techniques pour câbler, connecter et rendre interopérable chaque élément.

Pour pallier à ces problèmes, sont apparues les infrastructures convergées.

B. Infrastructures convergées

Pour faire face aux contraintes citées précédemment, les principaux constructeurs proposent ce que l’on appelle les Infrastructures convergées.

imageCe type d’infrastructure n’est ni plus ni moins qu’un assemblage des éléments que l’on retrouve dans les infrastructures classiques si ce n’est que chaque élément a été validé par le constructeur, les rendant de fait « Interopérables ».

Les avantages de ce types de plateformes sont :

· Plates-formes livrées pré-intégrées et prêtes à l’emploi

· Mise en œuvre rapide

· Incertitudes liées à l’intégration éliminées

   

Cependant l’encombrement important de ce type de plateforme nécessite de prévoir des locaux adéquats ainsi que les alimentations électriques et ventilations nécessaires. En outre, il n’en reste pas moins que ce type de plateforme est juste une une infrastructure classique « validée ». Elle nécessite toujours des compétences relatives à chaque composant (système, réseaux , stockage).

Pour faire face à ces deux derniers inconvénients, sont apparues les infrastructures hyperconvergées.

C. Infrastructures Hyperconvergées

Les infrastructures hyperconvergées peuvent être assimilées à une compression des infrastructures convergées.

image

En effet dans un seul boitier, souvent de taille 2U, nous allons retrouver les serveurs, le réseau et le stockage. Dès lors les avantages de ce types de boitiers sont évidents, notamment au niveau de l’encombrement ou de la facilité d’administration. En effet bien souvent, ces appliances hyperconvergées viennent avec une seule et unique interface d’administration pour l’ensemble du boitier.

Beaucoup d’acteurs et de constructeurs se sont lancés sur ce marché de l’hyperconvergence, parmi lesquels nous retrouvons bien surs les grands noms du domaine que sont DELL, EMC, Vmware.

image

En ce qui nous concerne, nous nous attarderons sur deux acteurs leaders et pionniers dans le domaine : NUTANIX et RUBRIK.

III. NUTANIX

A. Présentation

Créée en 2009, Nutanix est une société qui propose depuis 2011 des appliances combinant serveurs, stockage et virtualisation. Elle propose une approche distribuée des ressources pour les infrastructures systèmes.

Nutanix souhaite proposer un « Datacenter in a box »

image

B. Fonctionnement

1. Problématiques des infrastructures classiques

Si l’on considère une infrastructure classique comme ci-dessous :

image

Il existe une problématique située au niveau des contrôleurs des baies de stockage qui peut être assimilé à la présence d’un goulot d’étranglement.

En effet, les contrôleurs des baies de stockages sont les seuls responsables de la disponibilité et de la vitesse d’accès aux données. Dès lors, plus on ajoute d’hyperviseurs ou de serveurs, plus ces contrôleurs vont être sollicités, pouvant créer potentiellement des files d’attentes, ou goulot d’étranglement.

De plus, ce type d’infrastructure demande des compétences spécifiques notamment pour la création des groupes de raid, leur dimensionnement ou le zonig des espaces de stockages. Il faut aussi des compétences spécifiques pour créer l’agrégation des liens réseaux.

Ces différentes problématiques sont annihilées au sein d’un boitier Nutanix

2. L’architecture d’un boitier NUTANIX

Un boitier Nutanix (2U) est composé de 4 nœuds.

Ci-dessous ; un zoom sur 2 nœuds :

image

Chaque nœud est composé d’un hyperviseur à base de processeur x86, d’un contrôlleur iSCSI et d’un contrôleur de stockage virtualisé. Pour chaque nœud, on trouvera aussi du stockage sous la forme de disques SSD et SATA.

La grande force de NUTANIX réside dans le contrôleur de stockage virtualisé (CVM). En effet, ce dernier étant dédié à l’hyperviseur et au stockage du nœud, au plus proche de ces éléments, il assure l’accès et la disponibilité des données de la manière la plus optimale.

Les nœuds peuvent en outre communiquer entre eux, les machines virtuelles peuvent migrer d’un nœud à l’autre grâce au NDFS, un system de fichier propriétaire de NUTANIX qui permet d’utiliser le stockage de chaque nœud en un seul et unique stockage unifié.

image

C. Avantages

1. Facilité d’utilisation et d’administration

NUTANIX supporte les principaux hyperviseurs du marché (Vmware, Hyper V). Il propose en outre son propre hyperviseur.

De par son système de fichiers propriétaire NDFS, il peut supporter ces deux environnements en même temps. Ainsi une machine sous Hyper V peut facilement basculer sur un hyperviseur Vmware de façon transparente (et vice et versa).

Le contrôleur de stockage virtuel (CVM) assure le tiering, c’est-à-dire le provisionnement du stockage en fonction du taux d’utilisation de la donnée. Ainsi des données chaudes, souvent utilisées seront placées de façon prioritaire sur le stockage SSD alors que des données froides, peu utilisées seront déplacées petit à petit vers les disques classiques SATA.

Enfin, NUTANIX, propose une seul interface d’administration, unifiée pour l’ensemble du boitier, rendant la gestion et l’administration de l’infrastructure système plus facile.

2. Souplesse du dimensionnement

Les boitiers NUTANIX sont « stackables » un peu à la manière des switches réseau. Ainsi à chaque ajout de nœud, on ajoute de façon simple, à la fois de la puissance de calcule et du stockage. Dès lors il facile de dimensionner une infrastructure système et de prévoir son évolution future.

Si l’activité ou la demande augmente, il suffira d’ajouter le nombre de nœuds adéquats.

Ce mode de fonctionnement est appelé le « PAY AS YOU GROW ».

image

3. Un encombrement réduit

Comme indiqué, l’encombrement d’un boitier hyperconvergé étant minime ; cela réduit les dépenses relatifs aux apports électriques et au refroidissement.Cela permet d’optimiser le dimensionnent des locaux techniques et les coûts liés.

Par exemple une baie de 42 Unités peut être aisément remplacée par deux boitiers NUTANIX occupant 4 Unités.

image

IV. Rubrik

A. Présentation

Rubrik est une startup basée dans la Silicon Valley qui a été créée en 2013. En 2015, ils proposent une appliance qui gère les parties sauvegarde et archivage des données de l’entreprise.

Pour l’instant les Rubrik sont dédiés aux infrastructures virtualisées sous Vmware. Cela va évoluer vers les machines physiques au fil des mises à jour.

image

B. Le boîtier Rubrik

L’appliance est un boîtier 2U qui contient 4 nœuds afin de ne laisser aucun spof.

Rubrik gère le tiering pour placer les données qu’il juge chaude ou froide sur les bons disques (SSD <> HDD). Cette solution a été conçue pour s’interconnecter au Cloud. Il permet alors d’envoyer les snapshots sur un compte Amazon S3 ou Microsoft Azur afin de gérer au mieux la volumétrie de stockage on premise.

C. La gestion des données

Intégrer au sein de son infrastructure les solutions Rubrik modifie grandement notre manière de gérer les données de sauvegarde.

En effet, Rubik permet de s’affranchir de serveurs dédiés à la sauvegarde et de baies de stockage production et Disaster Recovery (DR).

Avant l’intégration de Rubrik, la gestion des données de sauvegardes ressemble à cela :

image

On remarque que notre infrastructure est éclatée et pas forcément synchronisée entre tous nos sites. Rubrik propose de s’affranchir d’une partie de l’infrastructure afin de simplifiée celle-ci :

image

On remarque le lien entre les Rubrik ainsi que vers le Cloud comme indiqué précédemment. Que la donnée soit stockée sur le Rubrik du site de Prod, ou celui du site DR ou encore sur le Cloud, cela ne change rien pour lui. Il ne s’agit que d’un seul stockage virtuel dans lequel nous allons naviguer via l’interface web de Rubrik, qui regroupe tous les Rubrik de l’infrastructure.

D. Configuration

La configuration d’un Rubrik ne prend que quelques minutes. Après les paramètres d’usage (nom DNS, IP, etc.) nous allons pouvoir effectuer un scan des hosts vSphere. A ce jour l’intégration des serveurs physique est en conception et seul VMware est intégré.

Le scan des vSphere va permettre au Rubrik de lister tous les hosts, datastores et VMs de l’infrastructure.

L’étape suivante est la création des SLA Domains. Ces domaines vont nous permettre de configurer différentes niveaux de sécurité pour nos VMs. Nous pourrons choisir à quelle fréquence les snapshots auront lieu et combien de temps ils seront stockés. La configuration des SLA Domains prévoit aussi le paramétrage de la migration automatique des snapshots vers le Cloud, si souhaité.image

Il est possible de donner des délais plus ou moins longs pour la prise de snapshots et la durée de rétention. Nous pouvons aussi choisir à quel moment de la journée le snapshot se fera, dans le but de ne pas impacter le business et de choisir si l’on va stocker le snapshot dans le Cloud et si oui, combien de temps.

Suite à la création des SLA Domains, nous devons attribuer ces SLA aux VMs (détectées par Rubrik lors du scan des vSphere).

E. Utilisation

L’une des fonctionnalités importantes et impressionnante de Rubrik est le Global File Search.

Rubrik a mis au point un système permettant de stocker les meta data de toutes les data sauvegardées dans la mémoire flash, ce qui permet depuis l’interface web de retrouver un fichier, quelque soit son emplacement en quelques secondes.

Nous n’avons plus besoin de savoir dans quel répertoire se trouvait ce fichier. Il nous suffit de savoir sur quel serveur était stockée la donnée.image

Je peux voir quels jours le serveur a été snapshot. ensuite je n’ai qu’à taper le nom du fichier dans la barre de recherche, et Rubrik va effectuer une recherche à travers tous les snaphots de ce serveur.

Rubrik a trouvé 37 versions de mon fichier à travers tous les snapshots, et je n’ai plus qu’à choisir la date à laquelle je veux restaurer le fichier.

imageimage

Schéma global de l’infrastructure avec Rubrik.

image

Enfin, dans le but de réduire le RTO, Rubrik peut se monter comme datastore afin de remonter une VM plus rapidement (on évite le transfert vers le datastore VMware d’origine). Cela ressemble à l’Instant Recovery de Veeam.


V. Conclusion

Les infrastructures hyperconvergées ont le vent en poupe. Le marché mondial a été multiplié par 2.7 en 2015 et le chiffre d’affaire de Nutanix a bondi de 80 %.

Le HCI permet aux entreprises d’être plus agile, en utilisant le pay-as-you-grow.

La gestion est facilitée, puisque la partie système, réseau et stockage est réunit en une seul interface. Dans le cas d’une infrastruture Nutanix + Rubrik, avec 2 interfaces web il est possible de gérer un datacenter.

L’encombrement réduit diminue les dépenses foncières, logistiques et énergétique.

Gestion de l’identité avec Office 365 par Adrien et Benjamin en MSI2016

https://www.youtube-nocookie.com/embed/NbxNvmdF-zc

SDN par Vincent et Rémi en MSI2016

Poster_SDN

Au revoir les GMSIA2015 !

Et voilà…Encore une promotion qui se termine après une semaine de jury qui se sont plutôt bien passés. (3 travaux complémentaires sur 15 étudiants). Merci aux membres de jurys qui se sont déplacés ainsi qu’aux tuteurs qui ont été nombreux cette année à soutenir leurs poulains !

C’est autours d’un barbecue que se termine la formation avec de nombreux projets. Tous sont en emploi ou en étude supérieure !

Soyez de fiers représentants de votre diplôme GMSI et à très bientôt, gardons le contact ! (en RISR ou à la cérémonie de remise des diplômes 2017)

Barbecue Fin d'année GMSIA2015

Blockchain par Alexandre en MSI2016

https://www.youtube-nocookie.com/embed/hy5fPoqDCug

L’authentification unique par Kamel Bouhadoun en MSI2016


Introduction

Face à la multiplication des applications web dans l’entreprise, avec des technologies multiples, les utilisateurs sont obligés de s’authentifier sur chaque application.

L’utilisateur est perdu entre les différents mots de passes des applications web, et l’expérience de connexion de ce dernier est médiocre.

La solution serai de s’authentifier une seul fois, avec un seul nom utilisateur et mot de passe, et accéder à toutes les applications web utilisées.

Présentation du SSO CAS apereo

L’authentification unique, SSO en anglais (Single Sign-On) est la fonction qui permet à un utilisateur de se connecter une seul fois et d’accéder à plusieurs applications web sans contrainte de reconnexion

Nous avons choisi de présenter la solution SSO de la fondation apereo nommé le Central Authentication Service (CAS).

Le CAS apereo est un projet open source développé en JAVA, avec une communauté de développement très active, le projet est très bien documenté sur le site de la fondation apereo

Pourquoi utiliser l’authentification unique?

L’authentification unique permet de faciliter la vie de l’utilisateur, il a un seul login et mot passe à retenir.

Le support informatique aura une seule identité utilisateur à gérer.

On réduit les demandes de réinitialisation de mot de passe.

La sécurité de connexion est embarquée dans le serveur CAS, qui est très sécurisée, toutes les connexions se font en https, avec des certificats coté client et serveur

L’expérience utilisateur lors de la navigation est améliorée

Cinématique d’utilisation

Le schéma suivant résume le fonctionnement du CAS

clip_image002

Architecture du CAS

Le schéma suivant présente l’architecteur du CAS

clip_image004

La partie CAS client : cette partie est embarquée dans l’application client, c’est le lient entre l’application web et le serveur CAS

La partie CAS serveur : cette partie gére le processus d’authentification

Les modes d’authentification

Le serveur CAS supporte plusieurs sources d’authentification :

· Active Directory

· JAAS

· JDBC

· LDAP

· RADIUS

· SPNEGO

· Trusted

· X.509 Certificates

Vous pouvez aussi définir votre méthode d’authentification

Les clients CAS

Les clients CAS sont des librairies utilisées pour communiquer avec les le serveur CAS avec un protocole de communication.

Les protocoles de communications supportés:

· CAS (versions 1, 2, and 3)

· SAML 1.1

· OpenID

· OAuth (1.0, 2.0)

Le client CAS est intégré dans les applications web cassifiée

Il existe différents clients CAS open source développés avec plusieurs langages de programmation :

· Apache httpd Server (mod_auth_cas module)

· Java (Java CAS Client)

· .NET (.NET CAS Client)

· PHP (phpCAS)

· Perl (PerlCAS)

· Python (pycas)

· Ruby (rubycas-client)

On a des applications avec des clients CAS embarqués :

· Outlook Web Application (ClearPass + .NET CAS Client)

· Drupal

· Liferay

· uPortal

· WordPress

Vous avez toujours la possibilité de développer votre propre client CAS.

Fonctionnalités du serveur CAS

Le serveur cas fourni d’autres fonctionnalités en plus de la gestion de la connexion

Les fonctionnalités sont les suivantes :

· API REST : permet d’appeler les services d’authentification en mode REST

Exemple : une application mobile peut utiliser les services de connexion du serveur CAS

· Audit : avoir un audit de toutes les connexions

Le serveur CAS respecte les normes de sécurité tous les connexions sont tracé dans un fichier de log

· Monitoring : avoir un état des sessions et des logs et des statistiques de connexion

La gestion des services CAS

Le stockage des services sont stockéq soit en base de données ou dans des fichiers JSON avec un format défini

Une application indépendante est créée pour l’ajout et la suppression de services

clip_image006

clip_image008

Mise en œuvre et intégration

Pour la mise en œuvre du serveur CAS vous pouvez partir sur les deux projets template disponibles sous le github d’apereo

cas-gradle-overlay-template : ce projet permet d’avoir la partie serveur CAS

cas-services-management-overlay : ce projet permet la gestion des services utilisée, d’ajouter, supprimer et mettre à jour les services.

Les pré requis en termes de langage et d’infrastructure sont :

· Langages : JAVA

· Serveur d’application web java : Tomcat , JBOSS, WebLogic

· Framework : Spring Core, Security, MVC

Si vous êtes sous docker vous pouvez utiliser le projet cas-webapp-docker pour le déploiement du serveur CAS

Inconvénients du CAS serveur

· Si le serveur CAS ne répond pas, la connexion aux applications est impossible.

· Si le serveur CAS est corrompu, toutes les applications sont vulnérables

· La personnalisation des processus de connexion est complexe, il faut une très bonne maitrise de Spring

· La gestion de la déconnexion n’est pas très bien gérée avec les serveurs en load balancer

Conclusion

Le serveur CAS d’apereo est une très bonne solution à mettre en place pour centraliser l’identité utilisateur et l’accès aux applications.

Elle apporte une meilleure expérience de navigation au client, facilite l’accès aux applications

Cette solution diminue la sollicitation du service informatique.

Cette solution est open source, ne coute rien à l’entreprise à part la mise en œuvre, c’est une solution fiable est sécurisée.

Azure Site Recovery par Alejendro et Khalifa en MSI2016

1 Introduction

Au cours des dernières années, l’informatique a pris une place importante au sein des activités des entreprises. Les services sont de plus en plus « dématérialisés » et l’informatique contrôle la productivité.

Les entreprises ne voyaient pas la nécessité d’un Plan de Reprise d’Activité avant le « 11 Septembre ».

Quelques chiffres liés à l’absence d’un Plan de Récupération d’Activités :

– 80% des entreprises ayant subi une perte significative de données, déposent le bilan dans les deux ans qui suivent.

– Suite à la destruction des moyens informatiques et télécoms, une entreprise disparaitra au-delà d’un arrêt de 72h dans 40% des cas.

– Lorsqu’elles n’y sont pas préparées 43% des entreprises ferment au moment d’un sinistre et 29% de celles qui survivent disparaissent dans les 2 ans qui suivent

o Source : Politique de sécurité des systèmes d’information et sinistralité en France (bilan 2002 – 2003) par le CLUSIF.

Un Plan de Récupération d’Activité demande un investissement préalable qui doit être minutieusement calibré pour éviter :

– Un surdimensionnement : engendre des charges financièrement inutiles

– Un sous-dimensionnement : ne garantissant pas la pérennité de l’entreprise

2 Présentation de l’Azure Site Recovery

2.1 Azure Site Recovery

Azure Site Recovery (ASR) est la solution de Plan de Reprise d’Activité (PRA) de Microsoft qui contribue à la continuité des activités de l’entreprise et à la récupération d’urgence.

Cette solution se base sur des services Cloud fournis par Microsoft Azure.

L’ASR permet ainsi de protéger une infrastructure étant sur son site en la réplication vers le site distant situé sur Azure.

2.2 Type d’infrastructure prise en charge

L’Azure Site Recovery est relativement modulable. En effet, il est compatible avec des infrastructures sous hyper-V mais également des infrastructures sous VmWare ainsi que des infrastructures physiques.

2.2.1 Infrastructure Hyper-V

image

L’infrastructure sous Hyper-V est l’exemple type du fonctionnement de l’ASR. Les VHDX sont répliqués vers l’infrastructure factice d’Azure. Les réplications se font en https et la bande passante utilisée pour la réplication n’est pas facturée. Les réplications sont considérées comme des « éléments protégés » et n’ont pas d’enveloppe « de type VM ». Le retour sur site nécessitera une interconnexion entre le site local et Azure de type VPN ou mpls.

2.2.2 Infrastructure Physique

image

L’infrastructure physique fonctionne de la même façon que l’infra Hyper-V sauf qu’il y aura des éléments supplémentaires :

Process server sur site : permet de convertir les machines à destination d’Azure en « vhd » (format hyperV).

Config Server sur Azure : permet de manager les réplications

Master Target : Permet la gestion de la rétention

Le retour sur site nécessitera une interconnexion et le process Server qui fournira un processus en sens inverse : vhd to physique.

2.2.3 Infrastructure VmWare

image

L’infrastructure VmWare fonctionne de la même façon que l’infrastructure physique, concernant la conversion du format « vmdk » en « vhd ».

La découverte des hôtes se fait de deux façons :

– En passant par un VCenter

– En passant par l’ESX

Le retour sur site utilisera le processus inverse afin de convertir le « vhd » en « vmdk ».

2.3 Technologie Hyper-V Réplica

2.3.1 Fonctionnement

La réplication des machines virtuelles permet de mettre en place un système de réplication d’un site hyper-V primaire vers un site hyper-V secondaire.

Ces réplications peuvent se faire toutes les :

– 5min – 10min ou 15min

Les réplications se font de façon asynchrone.

image

En cas de problème sur la VM primaire, la VM « réplica » prendrait le relais. Cette problèmatique fonctionne également pour l’hôte hyper-V : en cas de crash de l’hyper-V primaire, l’hyper-V secondaire avec les machines « réplica » sera toujours disponible et permettra aux réplicas de prendre le relais.

image

2.3.2 Matching entre hyper-V on-premise

La technologie Hyper-V s’appuie sur un système de certificats se présentant entre les « nœuds » (node) ou avec le broker (selon l’architecture).

L’hyper-V présente son certificat afin de garantir la source et vérifie la destination avec le certificat du nœud de destination.

Ces certificats doivent être délivrés par une autorité de certificat (CA) installées sur le domaine auquel appartiennent les nœuds.

image

2.3.3 Machting entre hyper-V et le Coffret Azure

Le matching entre les deux sites est fait à l’aide des « Vault Credentials ». Cette clef privée est générée automatiquement par le coffret Azure Site Recovery lors de la création d’un hôte hyper-V. La clef est unique et est destinée à l’hôte hyper-V que l’on déclare sur Azure. Cette clef est cryptée et est demandée lors de l’installation du client « Azure Site Recovery Provider » en local (on-prem). La liaison établie entre les deux hôtes est en HTTPS.

3 Activation des Plans de récupérations

Une fois que le composant est installé sur le serveur on-prem, le plan de réplication activé, il est possible d’activer les plans de récupération.

Un plan de récupération permet la création de machines virtuelles d’après les dernières réplications. Les VM seront créées seulement si elles font parties du plan de récupération.

3.1 Type de plans

Il existe deux types de plans de récupération :

Le plan de récupération planifié (planned recovery plan)

Ce plan permet d’activer son PRA sans sinistre sur l’infrastructure on-prem. Les charges de travail sont inversées et le site de réplication devient le site primaire. Les réplications sont inversées et vont donc d’Azure to on-prem.

image

Le plan de récupération non planifié (unplanned recovery plan)

Ce plan est utilisé en cas de sinistre sur son site local. Le site Azure devient le site primaire, les réplications sont arrêtées et le basculement est finalisé.

image

3.2 Sens des plans

Les plans de récupérations permettent d’aller dans deux sens différents :

On-prem to Azure

Ce sens permet l’activation du PRA, suite à un problème ou une défaillance de l’infrastructure local ou pour tester son PRA en conditions réelles. Il est possible d’avoir plusieurs plans correspondant à plusieurs infrastructures ou à des sites. Les plans peuvent contenir une ou plusieurs Machines. Une fois activé, la réplication est automatiquement arrêtée sur la machine on-prem et celle-ci ne peut plus démarrer sur le site local. Ceci est fait afin de ne pas avoir de delta entre les deux machines.

Ce sens ne nécessite aucune interconnexion entre le site on-prem et Azure.

Azure to on-prem

Ce sens correspond au « failback », le retour sur site de l’infrastructure. Le retour arrière nécessite une interconnexion entre le site on-prem et Azure, de type VPN ou MPLS. La bande passante sera facturée à la consommation du Go. Lors du failback il est nécessaire de déclarer à nouveau son hôte hyper-V on-prem sur l’infrastructure Recovery (si l’hôte change).

4 Conclusion

La mise en place d’un PRA nécessitait la copie « miroir » de l’infrastructure sur un site secondaire :

Schéma on-premise vers on-premise : Illustration de la complexité de la gestion d’une infra de Réplication Interne.

image

Avec Azure, nous avons simplement besoin d’activer le système de réplication. Azure s’occupe du reste. Le PRA devient beaucoup plus simple en utilisant Azure Site Recovery :

– Moins cher

– Moins compliqué

– Flexibilité

Schéma on-premise vers Azure : Illustration de la flexibilité d’Azure Site Recovery.

image

Autre la capacité de « PRA », Azure Site Recovery permet également la migration de VM ou d’une infrastructure vers Azure.

Le point négatif vient au coût du failback, la volumétrie vers Azure n’est pas facturée alors que la volumétrie d’Azure vers le on-premise est facturée au Go.

Infographie Sharepoint par Alexandre et Xavier en MSI2016

infographie

%d blogueurs aiment cette page :