• Azure IaaS : Gérer votre infrastructure Azure IaaS avec PowerShell

    Partie 1 : Initiation à la création des éléments Azure.

    Auteur: Jérémy Leflon – Jeremy.Leflon@microsoft.com

     

    Microsoft a mis à disposition des exploitants Azure un set de Cmdlet PowerShell permettant la création et la gestion des objets Azure. L’objectif de cet article est de présenter les commandes principales à utiliser par les administrateurs pour la création des machines virtuelles dans les cloud services correspondants.

    Cet article se consacre à la gestion des artefacts suivants :

    • Groupes d’affinités,

    • Cloud Services,

    • Comptes de stockage,

    • Machine Virtuelles et groupes de disponibilité

    • Disques de données supplémentaires

     

    Prérequis pour l’accès à la souscription Azure

    • Téléchargez et installez le module Windows Azure PowerShell à travers le Microsoft Web Platform Installer (http://azure.microsoft.com/en-us/documentation/articles/install-configure-powershell/).

    Plus d’informations sont disponibles sur : http://azure.microsoft.com/en-us/documentation/articles/install-configure-powershell/

     

    • Pour utiliser le module de cmdlets PowerShell pour Azure, il faut ouvrir le raccourci « Windows Azure PowerShell » ou importer le module Azure PowerShell dans votre prompt PowerShell ou ISE par la commande suivante : 

    Import-Module "C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\ServiceManagement\Azure\Azure.psd1"

     

    • Être administrateur de la souscription Azure

       

    Connexion à la souscription Azure

    Source : http://azure.microsoft.com/fr-fr/documentation/articles/install-configure-powershell/

    Les opérations de gestion de la souscription nécessite une authentification préalable auprès du service Azure.

    Pour cela, il existe deux méthodes d’authentification à la souscription Azure :

    1. Par l’utilisation de la cmdlet « Add-AzureAccount » qui ouvre un prompt demandant les credentials. L’authentification n’est valable qu’à travers le contexte du prompt utilisé et doit être réalisé si la session a expiré.
    2. Par certificat d’authentification
      1. Ouvrir le prompt Azure PowerShell
      2. Exécuter la commande Get-AzurePublishSettingsFile qui ouvrira une page web nécessitant les informations de connexion   Note : il peut être nécessaire de supprimer les cookies existants si vous utilisez plusieurs Microsoft Account.
      3. Téléchargez le fichier de profil
      4. Retournez sur le prompt PowerShell et exécutez la commande suivante :

    Import-AzurePublishSettingsFile « Chemin du file-credentials.publishsettings »

     

    1            Sélection de la souscription d’exécution

    Suite à l’authentification de l’utilisation à la plateforme Azure, il est nécessaire de préciser la souscription d’exécution si vous êtes administrateur de plusieurs plateformes.

    Pour sélectionner la souscription, exécutez la cmdlet suivante :

    • Définition Variable prérequis

      • $mySubscription

    • Cmdlet :

    select-azureSubscription $mySubscription

    Pour connaître la liste des souscriptions Azure disponible pour le compte authentifié, utilisez la cmdlet suivante

    Get-AzureSubscription

     

    2            Création des artefacts de la souscription

    2.1            Création des groupes d’affinités

    Les groupes d'affinités permettent de regrouper les services qui doivent fonctionner ensemble afin d'optimiser les performances. Cela permet de réduire la latence et augmente les performances.

    Référence : http://msdn.microsoft.com/fr-fr/library/windowsazure/jj156085.aspx

    La création d’un groupe d’affinité est un prérequis à la création des Cloud Services.

    • Définition Variable prérequis

    $affinityGroupName : nom du groupe d’affinité du service

    $location : « West Europe » / « North Europe » …

    $label : Label du groupe d’affinité – visible en PowerShell

    $description : Description du groupe d’affinité – visible en PowerShell

    • Cmdlet :

       New-AzureAffinityGroup -Name $affinityGroupName -Location $location -Label $label -Description $description

    2.2            Création de Cloud Service

    Le cloud service Azure est un ensemble regroupant d’autres artefacts azure, joignables par l’intermédiaire du Cloud Service qui porte une adresse publique.

    Le nom du service de cloud sera unique et sous la forme {$cloudServiceName}.cloudapp.net

    • Définition Variable prérequis

    $cloudServiceName : nom du Cloud Service à créer

    $affinityGroupName : nom du groupe d’affinité du service

     

    • Cmdlet :

       

    New-AzureService –ServiceName $cloudServiceName –AffinityGroup $affinityGroupName

     

    2.3            Création des comptes de stockage

    Azure fournit 3 types de comptes de stockage, de façon à laisser le choix en termes de performances et sécurité la main mise sur leur infrastructure :

    • LRS : Locally Redundant Storage : Toutes les données stockées sont répliquées de manière synchrone sur trois nœuds de stockage différents dans la même région

      • 10 Gbps en entrée

      • 15 Gbps en sortie

    • GRS : Geo-Redundant Storage : En plus de la réplication sur trois nœuds de stockage comme sur le LRS, les transactions sont aussi mises en queues pour une réplication asynchrone sur une seconde région où les données sont aussi stockées sur trois autres nœuds de stockage.

      • 5 Gbps en entrée

      • 10 Gbps en sortie

    • RA-GRS : Read-Access Redundant Storage

      • Même capacités de transfert que le GRS.

      • Un accroissement des vitesses de lecture / disponibilité.

    Note : Par défaut, les comptes de stockage sont créés en GRS.

    • Définition Variable prérequis

    $storageAccountName="nomduStockage"

    $storageAccount_Description="Description du Stockage"

    $affinityGroupName

    • Cmdlet

    new-azurestorageaccount -storageaccountname $storageAccountName -AffinityGroup $affinityGroup 

    set-azurestorageaccount -storageaccountname $storageAccountName  -description $storageAccount_Description

    Pour définir un compte de stockage en LRS :

     Set-AzureStorageAccount -StorageAccountName $storageAccountName -GeoReplicationEnabled $false 

    Informations complémentaires : http://blogs.msdn.com/b/windowsazurestorage/archive/2013/12/04/introducing-read-access-geo-replicated-storage-ra-grs-for-windows-azure-storage.aspx

     

    2.4            Création des machines virtuelles

    2.4.1        Description des Availability Set

    Pour garantir la disponibilité des ressources, Azure met à disposition une fonctionnalité gérant un couche supplémentaire de redondance appelée “Availability Set”.

    Ce mécanisme va forcer l’exécution de 2 machines virtuelles opérant les mêmes fonctions ou services sur au moins deux hyperviseurs différents de façon à garantir le niveau de service.

     

    Dans le schéma suivant, les machines virtuelles tournent sur 2 « Racks » au sens physiques du terme.

    2.4.2        Définition de l’image disque source

    Les machines virtuelles sont provisionnées avec une image OS.  La liste des noms des images sources peuvent être récupérées par l’utilisation de la cmdlet :

    Get-AzureVmImage

     

     

    Pour éviter de parcourir l’ensemble des éléments, il est possible d’utiliser la commande suivante pour variabiliser le nom de la dernière image Windows Server 2012 par exemple :

    $imageName=(Get-AzureVMImage -Verbose:$true | Where-Object {$_.label -like “Windows Server 2012 R2 Datacenter*”}| Sort-Object –Descending PublishedDate)[0].ImageName

    2.4.3        Création de la configuration de la machine

    Avant de provisionner la machine, il est nécessaire de configurer l’élément à l’aide de la cmdlet New-AzureVMConfig sur lequel vous pouvez Piper le cmdlet Add-AzureProvisioningConfig permettant de définir des informations systèmes (nom et mot de passe de l’administrateur), la timezone de la machine.

    Il est aussi possible d’y ajouter les informations réseaux tels que le subnet d’appartenance et l’adresse IP fixe de la machine (cas des contrôleurs de domaine).

    Note : le currentStorageAccount de la souscription utilisée doit être provisionnée

    • Définition des variables :

    #Information de connexion :

    $subscription : Souscription de creation de machine

     #information sur la machine à créer

    $cloudServiceName : Nom du cloud service pour la machine

    $NomVm : nom de la machine virtuelle cible

    $storageAccountName : Nom du compte de stockage du disque OS de la machine

    $size : taille de la machine : Small / Large / A6/A7/A8

    $availSet : nom du groupe de disponibilité de la machine

    $imageName=(Get-AzureVMImage -Verbose:$true | Where-Object {$_.label -like “Windows Server 2012 R2 Datacenter*”}| Sort-Object –Descending PublishedDate)[0].ImageName

     #information sur le disque OS

    $diskName : nom du disque utilisé pour le stockage

    $diskLabel = $diskName + "- OS"

    $urlMedia = “https://"+$storageAccountName+”.blob.core.windows.net/vhds/”+$diskName+”.vhd”

     #Information OS Windows

    $admUser : nom du compte administrateur local

    $admPwd : mot de passe du compte administrateur local

     $timeZone : Nom de la zone time pour la machine ("Romance Standard Time" pour Paris par ex)

     #Information Réseau

    $vNET : nom du réseau virtuel d’appartenance

    $subnetName : nom du subnet d’appartenance de la machine

    $staticIP : adresse IP de la machine

     

     

    Le script ci-dessous créé la machine correspondant aux paramètres définis plus haut :

             $VM1 = New-AzureVMConfig -Name $NomVm -InstanceSize $size -ImageName $imageName -DiskLabel $diskLabel –MediaLocation $urlMedia -AvailabilitySetName $availSet `

                 | Add-AzureProvisioningConfig -adminUserName $admUser -Password $admPwd -Windows -TimeZone $timeZone `

    | Set-AzureSubnet -SubnetNames $subnetName `

                 | Set-AzureStaticVNetIP -IPAddress $staticIP

     New-AzureVM -VMs $VM1 -ServiceName $cloudServiceName –VnetName $vNET

     

     

    Note : si le currentStorageAccount n’est pas défini, il est possible que le script décrit ne s’exécute pas et l’erreur PowerShell suivante se produit :


     

    Pour connaitre la valeur de cet attribut, utilisez la ligne de commande PowerShell suivante :

     Get-AzureSubscription

    Pour résoudre cette erreur, tapez la commande suivante :

     

    set-AzureSubscription -SubscriptionName $subscription -CurrentStorageAccount $storageAccountName

    3            Ajout d’un disque de données

    Chaque machine virtuelle créée possède un disque OS et un disque non persistent. Pour ajouter un disque de données persistant supplémentaire, il est possible d’ajouter des volumes par l’utilisation de cmdlet PowerShell.

     

    En plus des variables définies précédemment, les variables suivantes doivent être provisionnées :

     

    $storageAccountName     : Nom du compte de stoickage Cible

    $vmName    : Nom de la machine virtuelle

    $cloudServiceName : Nom du cloud Service

    $typeDisk :      Type de disque pour information ("DATA"/"LOG"/"BACKUP"...)

    $diskSize :      Taille de l’espace disque du volume à créer en Go

    $lunID : Index de LUN (3/4/5…)

    $diskNameDataDisk= $vmName+ « . » + $typeDisk      Nom du disque généré automatiquement

    $urlMediaDataDisk = « https:// » +$storageAccountName+ «.blob.core.windows.net/vhds/”+$diskName+”.vhd”    URI d’accès au fichier VHD généré automatiquement pour le disque supplémentaire

     

    Création du disque supplémentaire et rattachement à la VM :

    Get-AzureVM -ServiceName $cloudServiceName -Name $vmName `

    | Add-AzureDataDisk -CreateNew -DiskSizeInGB $diskSize -LUN $lunID -MediaLocation $urlMediaDataDisk -DiskLabel $diskNameDataDisk`

    | Update-AzureVM

     

    - Commande Get-AzureVM

    • Le paramètre -ServiceName correspond au nom du Cloud Service

    • Le paramètre -Name correspond au nom de la VM

             

    - Commande Add-AzureDataDisk

    • Le paramètre -CreateNew est obligatoire

    • Le paramètre -DiskSiezInGb indique la taille du disque en GB

    • Le paramètre -LUN correspond au numéro d'attachement du disque (cf Raw Device mapping), cet index doit être incrémenté à chaque disque ajouté.

    • Le paramètre -MediaLocation correspond à l'URL du disque virtuel VHD.

                    

     

    Voilà qui clôture le premier billet sur la création des artefacts IaaS sur Azure.

     

    Jérémy Leflon – Jeremy.Leflon@microsoft.com

  • Security Intelligence Report - Volume 13

    Le rapport Microsoft sur la sécurité des données (Microsoft Security Intelligence Report) étudie les vulnérabilités logicielles, leurs exploitations, ainsi que les logiciels potentiellement indésirables.

     

    Le volume 13 du rapport est disponible depuis fin 2012, il couvre la moitié de l'année calendaire 2012 (janvier à juin) et aborde les points suivants :

    Téléchargements malveillants: logiciel, musique et films

    La catégorie des menaces la plus fréquemment signalée en 1H12 était Win32/Keygen ;  qui des outils qui génèrent des clés pour différents logiciels. De plus, Keygen a été reconnu en tant qu’une des 10 principales menaces pour 98% des 105 pays / régions étudiées dans le SIR v13.

     

    À noter que la menace ne provient pas directement du Keygen, de la musique ou des films, mais des malwares cachés dans ces éléments.

     

    En 1H12, plus que 76% des ordinateurs ont été touchés par des Keygen et d’autres familles de malware, un pourcentage qui reste assez élevé.

    Évaluation des menaces dans le monde entier

    Les industries ont eu une hausse de vulnérabilité de 11,3% depuis 2H11 comme on peut le voir sur le graphique suivant.

     

     

    • Après une baisse régulière de plusieurs périodes, les vulnérabilités des applications ont fortement augmentées en 1H12, ce qui représente plus de 70 % de toutes les vulnérabilités  sur 1H12.
    • Les vulnérabilités de  navigateur et système d'exploitation, qui étaient à peu près à égalité en 2H11, ont changé de place par rapport aux périodes précédentes.

     

    Le taux de vulnérabilité du système d'exploitation a chuté  à son plus bas niveau depuis 2003, tandis que les vulnérabilités des navigateurs Web poursuivent une tendance à la hausse depuis quelques années.

      

     

    Les sujets les plus concernés par les attaques sont HTML/JavaScript et Java.

     

    • La détection des codes malveillants propagés via HTML ou JavaScript a considérablement augmenté au cours du second semestre 2011, principalement en raison de l'émergence de JS/Blacole, une famille de codes malveillants utilisés par le kit de codes malveillants « Blackhole » pour propager des logiciels malveillants par le biais de pages Web infectées.

     

    • La détection des codes malveillants qui ciblent les vulnérabilités des lecteurs et des éditeurs de documents a connu une hausse lors du 4T11, plaçant ainsi ces vulnérabilités en troisième position des types de codes malveillants le plus souvent détectés au cours de ce trimestre, principalement à cause du nombre croissant de codes malveillants ciblant Adobe Reader.

     

     

     

    Évaluation des menaces par zone

     

    La Corée, le Pakistan, la Turquie et la Palestine  font partie des pays présentant des taux d’infection très élevés (> à 10%, qui est le taux moyen d’infection mondial).

     

     

     

    D’autres pays par contre, présentent des taux d’infection plus faibles que le taux moyen d’infection mondial tel que la Chine, le Japon, la Finlande et le Danemark.

      

     

     

    Comment appliquer SIR ?

     

    SIR permet aux clients de protéger leurs organisations, leurs logiciels et leurs employés.

     

    Au niveau organisationnel

    Au niveau individuel

    Garder tous les logiciels des systèmes à jour (Systèmes tiers, ainsi que Microsoft)

     

    A noter qu’à partir du 8 avril 2014, Microsoft ne fournira plus de support pour les utilisateurs de Windows XP. Cela signifie que les clients et les partenaires ne recevront plus de mises à jour de sécurité pour le système d'exploitation et ils ne seront plus en mesure d’avoir le support technique de Microsoft à partir de cette date.

     

    Faire preuve de prudence lorsque l’on clique sur les liens vers des pages Web

    (Être prudent avec les pièces jointes et les transferts de fichiers)

     

    Utiliser Microsoft Update, pas Windows Update

    (Les mises à jour concernent tous les logiciels Microsoft)

    Éviter de télécharger des logiciels piratés

    Exécuter un logiciel antivirus auprès d'un fournisseur de confiance

    (Et le tenir à jour)

     

    Se protéger contre les attaques d'ingénierie sociale

     

     Sally MAHAMDEH – Consultante Sécurité & Identité

     

  • Document Microsoft de décembre 2012 pour prévenir les attaques "Pass the Hash"

    Introduction

    Microsoft a publié en décembre dernier un document technique expliquant les mesures de protection à prendre pour se prémunir des attaques utilisant le mécanisme PtH (Pass The Hash).

    On assiste en effet depuis environ deux ans à une aggravation sans précédent des activités criminelles sous la forme d’attaques depuis Internet, visant la propriété intellectuelle des entreprises et des administrations.

    Ces attaques visent dans la quasi-totalité des cas à voler des documents concernant un sujet précis en fonction de l’ordre du commanditaire.

    Ces attaques, qui sont de véritables opérations professionnelles d'espionnage, réussissent avec une facilité déconcertante car les entreprises ne sont pas protégées contre des attaques d’un tel niveau, bien au-dessus des divers virus qui ont longtemps été l’illustration d’une conception artisanale d’actes malveillants.

    Le mécanisme "Pass the Hash"

    L’analyse des attaques montre une préparation méthodique et une détermination sans faille pour pénétrer le réseau interne, s’installer puis s’approprier les privilèges de comptes d’administration afin d’accéder ensuite aux informations qu’il n’y a plus qu’à faire sortir par le même chemin (Internet). La discrétion est le propre de ces attaques sophistiquées et persistantes (Advanced Persistent Threats) qui peuvent durer plusieurs années sans que personne ne s’en rende compte.

    La facilité pour mener avec succès de telles attaques a été facilitée par la mise à disposition sur Internet d’outils permettant de récupérer très facilement l’identité (credentials) des comptes privilégiés qui ont accès par défaut à beaucoup d’ordinateurs des entreprises.

    Ce mécanisme s’appelle "Pass the Hash" car il permet de récupérer ces identités depuis la mémoire d’un ordinateur sous la forme d’un hash, c’est-à-dire d’un authentifiant lié au mot de passe d’un compte utilisateur.

    L’analyse des attaques montre que ce mécanisme "Pass the Hash" est utilisé dans la grande majorité des attaques afin de permettre à l’attaquant qui a réussi à prendre pied sur un poste de travail d’étendre son emprise sur votre infrastructure :

    • Soit de manière latérale pour prendre possession d’un ordinateur de même valeur
    • Soit d’élever ses privilèges pour prendre possession d’un système de plus grande valeur (contrôleur de Domaine ou serveur contenant des données de valeur)

    Et vous, êtes-vous concerné ?

    Pour savoir si vous êtes concerné, demandez-vous simplement si de temps en temps un administrateur informatique de votre société ne va pas s’authentifier avec son compte privilégié sur des postes de travail standards, qui ont accès à Internet.

    Cette façon de faire qui est malheureusement courante, associée au trop grand nombre souvent observé de comptes privilégiés, suffit à faire de votre entreprise une proie facile si elle devenait la cible d’une attaque. En fait, il suffit d’un instant à un logiciel malveillant présent sur un poste pour acquérir les privilèges de ce compte, et de quelques minutes pour se rendre maître de votre infrastructure informatique, et en plus à votre insu.

    Face au décalage entre les pratiques qui avaient cours jusqu’à présent et la gravité extrême de ces attaques, il faut un changement de comportement pour s’en protéger.

    Afin de vous aider, Microsoft a donc publié le document Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques qui contient les principes à appliquer ainsi que les procédures pas à pas à dérouler dans votre infrastructure.

    Les mesures contenues dans le document de décembre

    Les mesures qui sont expliquées dans ce document visent à empêcher la réussite des attaques utilisant le mécanisme "Pass the Hash", notamment en protégeant les comptes privilégiés.

    Le document qui est très pédagogique, contient les procédures pas à pas à dérouler, de façon à ce que vous puissiez très vite vous organiser pour planifier leur mise en œuvre.

    Les actions sont classées dans les quatre catégories suivantes :

    • Restriction et protection des comptes privilégiés
    • Restriction et protection des comptes d’administration locaux
    • Blocage du trafic entrant sur les postes de travail avec le pare-feu Windows
    • Actions complémentaires

    Ces actions sont passées en revue dans les paragraphes ci-dessous.

    Restriction et protection des comptes privilégiés

    L’objectif est ici de se protéger contre les élévations de privilèges avec les mesures suivantes :

    • Faire en sorte que les comptes d’administration et autres comptes privilégiés ne s’authentifient que sur des serveurs ou postes hautement sécurisés
    • Affecter aux administrateurs un compte d’administration dédié, différent de leur compte standard
    • Leur affecter un poste de travail spécial pour les tâches d’administration
    • Marquer ces comptes comme "sensible et ne peut pas être délégué"
    • Configurer des services ou des tâches planifiées avec un compte privilégié de domaine seulement sur des serveurs hautement sécurisés

    Restriction et protection des comptes d’administration locaux

    L’objectif est ici de se protéger contre les mouvements latéraux avec les mesures suivantes :

    • Désactiver tous les comptes administrateur locaux
    • Interdire l’authentification depuis le réseau ou par Remote Desktop Services aux comptes locaux
    • Créer des mots de passe différenciés pour chaque compte administrateur local

    Blocage du trafic entrant sur les postes de travail avec le pare-feu Windows

    L’objectif est ici aussi de se protéger contre les mouvements latéraux avec un compte qui aurait été attaqué, avec la mesure suivante :

    • Interdire le trafic réseau entrant vers les postes de travail, sauf le trafic justifié et  venant d’une source sûre

    Actions complémentaires

    Il s’agit de mesures venant renforcer les actions ci-dessus :

    • Ne pas aller sur Internet avec un compte privilégié
    • Retirer les utilisateurs standards des groupes locaux Administrateurs
    • Configurer les proxy sortants pour interdire l’accès Internet aux comptes privilégiés
    • Vérifier que les comptes d’administration n’ont pas de compte de messagerie ou de boîte mail associée
    • Utiliser des outils d’administration à distance qui ne risquent pas de placer des identités réutilisables dans la mémoire d’ordinateurs distants : net use, PowerShell WinRMwithout CredSSP, PsExec without explicit creds, Remote Registry, Remote Desktop Gateway, IIS "Integrated Windows Authentication"
    • Mettre à jour les systèmes d’exploitation et les applications avec les correctifs disponibles
    • Limiter le nombre et l’utilisation des comptes privilégiés de domaine
    • Gérer de manière sécurisée les Contrôleurs de Domaine
    • Retirer les hash de type Lan Manager le cas échéant

    Conclusion

    Une fois réalisée la prise de conscience de la gravité des attaques PtH, il faut vraiment changer d’attitude face aux risques encourus par votre infrastructure informatique en :

    • Prenant connaissance et en vous familiarisant avec le contenu du document publié en décembre
    • Planifiant la mise en œuvre des recommandations du document en fonction de votre contexte
    • Déroulant les procédures détaillées qui sont là pour que vous soyez en mesure de les mettre en place sans assistance extérieure

    Ces mesures, à la fois techniques et concernant la manière d’administrer votre infrastructure, renforceront votre protection contre les attaques PtH.

     

    Renaud Depagne - Consultant Senior II MCS France.

  • Scénarios de fédération avec Forefront UAG 2010 et ADFS 2.0

    Nouveautés avec le SP2 (août 2012)

    Quelles sont les nouveautés apportées par le SP2 ? http://technet.microsoft.com/en-us/library/jj590875.aspx.

    Outre un support amélioré de Sharepoint 2010 et de systèmes d’exploitation d’appareils mobiles (Windows Phone 7.5, iOS 5.X pour iPone et iPad, Android 4.X pour smartphones et tablettes), le SP2 apporte principalement des fonctionnalités autour de la publication d’applications « claims-aware » avec ADFS 2.0. Il est désormais possible :

    • D’utiliser un même serveur ADFS avec plusieurs trunks

    • De publier le serveur ADFS avec un ADFS proxy plutôt qu’UAG, et ainsi de supporter (entre autres) les scénarios de fédération avec Office365

     

    UAG et ADFS : le pouvoir des claims avec le contrôle d’accès UAG

    Partons du constat suivant : si la gestion du cycle de vie des identités « employés internes » et de leurs droits d’accès est un challenge pour les entreprises, c’est presque mission impossible pour des identités externes. Or aujourd’hui, les scénarios suivants sont monnaie courante :

      1.      Donner/Contrôler un accès à des utilisateurs externes (partenaires, fournisseurs) à des sites et services hébergés sur un intranet de l’entreprise

          2.      Faciliter l’accès des employés depuis l’intranet ou en mobilité à des sites et services hébergés en externe (clouds publics ou privés)

              3.      Proposer un accès contrôlé à tout type d’utilisateur (interne ou externe) à certains sites web hébergés sur un intranet. Dans un contexte BYOD (Bring Your Own Device), les composants clients peuvent être utilisés pour contrôler l’accès en fonction de caractéristiques du device (non disponible aujourd’hui pour les OS mobiles).

                 

                Déployer Forefront UAG 2010 SP2 avec ADFS 2.0 permet de proposer une solution technique à ces besoins, et nous allons voir comment. L’article suivant fait référence concernant l’interopérabilité UAG et ADFS (http://blogs.technet.com/b/edgeaccessblog/archive/2010/04/14/forefront-uag-and-adfs-better-together.aspx), cependant avec le SP2 d’UAG il est désormais possible d’utiliser un ADFS Proxy dans l’architecture.

                Accès à des applications internes par des utilisateurs externes

                Forefront UAG fournit les fonctionnalités portail, reverse proxy et contrôle d’accès (authorization and endpoint policies). ADFS est quant à lui la brique de fédération : consommation, génération et transformation de jetons contenant des claims, utiles à l’authentification et l’autorisation des utilisateurs.

                Ci-dessous un exemple de scénario :

                Notez qu’il est possible de publier le serveur au travers d’UAG si le déploiement d’un serveur ADFS Proxy n’est pas souhaité.

                Enfin, la relation de confiance avec le partenaire peut être établie avec des passerelles de fédération tierces, autres qu’AD FS. Les guides How-To sur Technet détaillent notamment l’interopérabilité avec les solutions RSA SecurID, IBM Tivoli Federated Identity Manager, Ping Identity, CA Federation Server, Oracle Identity Federation, Shibboleth 2 : http://technet.microsoft.com/en-us/library/adfs2-step-by-step-guides(v=WS.10).aspx.

                 

                Accès à des applications cloud pour des employés

                Grâce à la publication d’ADFS via ADFS Proxy, il devient possible d’utiliser cette architecture simplement pour donner accès aux internes à des applications cloud. UAG peut être alors utilisé par exemple pour rediriger les utilisateurs sur des applications internes (par exemple Sharepoint Online qui ferait référence à des liens sur une application publiée par UAG). L’employé bénéficie ainsi d’un SSO entre les applications internes et cloud.

                 

                Accès à des applications internes dans des scénarios BYOD

                Lorsque l’on donne accès à une application à travers un portail UAG, il est possible de régler différents paramètres d’authentification et d’autorisation. En plus du résultat dépendant du jeton de sécurité fourni (claim d’authentification et claims d’attributs), il est possible de configurer dans UAG des règles spécifiques au client utilisé. L’intérêt de la solution est l’application d’une politique de sécurité d’entreprise ; les devices considérés comme non sûrs et où l’information pourrait être détournée sont interdits d’accès.

                Les informations sur le device peuvent être transmises via deux technologies :

                • UAG EndPoint Components : cela nécessite l’installation d’un composant client UAG sur le device, et la configuration de politiques d’accès dans UAG. Cette solution est la plus souple, et fonctionne sur divers systèmes (activeX pour Windows/IE, applet Java pour Linux-Mac/Firefox-Safari). Elle est recommandée dans la plupart des scénarios.

                • NAP (Network Access Protection) : cela nécessite l’ajout d’un serveur NPS, la configuration de politique de santé, et la présence d’un client NAP activé et configuré sur l’OS. Cette solution est plutôt à privilégier pour des déploiements DirectAccess ou VPN/SSL avec des PCs Windows.

                Forefront UAG sait donc s’adapter en fonction du device. La matrice de compatibilité complète est disponible ici : http://technet.microsoft.com/en-us/library/dd920232.aspx

                Dans l’exemple ci-après, on aurait :

                • Authentification au trunk portail UAG déléguée à ADFS

                • Accès au portail autorisé uniquement si

                  • Les conditions de claims utilisateur sont respectées

                  • Les composants client UAG Endpoint sont installés

                  • Les conditions définies dans les règles d’accès EndPoint sont respectées (par exemple Windows, Linux ou Mac avec antivirus installé, refusé pour les mobiles et autres)

                • Accès à l’application web uniquement si

                  • Les conditions de claims utilisateur spécifiques à l’application sont respectées

                  • Les conditions définies dans les règles d’accès EndPoint spécifiques à l’application sont respectées

                • Accès à l’URL web finale de l’application si le type de requête est autorisé

                Bien entendu, la fédération n’est pas indispensable ici et il est tout à fait possible d’adapter le scénario avec d’autres types d’authentification au niveau du portail UAG. La liste est disponible ici : http://technet.microsoft.com/en-us/library/dd861486.aspx.

                 

                 

                Conclusion

                Ces scénarios rappellent les intérêts principaux de la solution couplée ADFS / UAG, à savoir :

                • Pas de comptes à gérer pour les partenaires pour l’authentification et l’autorisation aux applications publiées

                • Du SSO aux applications et une expérience unifiée pour l’utilisateur

                • Une interopérabilité avec les partenaires grâce aux standards de fédération (WS-Federation et SAML 2.0)

                • Un contrôle d’accès en fonction de caractéristiques du device utilisé. Avec l’arrivée prochaine des tablettes Windows 8, ces scénarios ont de l’avenir

                 

                Enfin il faut noter qu’il est possible :

                • De publier conjointement dans un même portail des applications non claims-aware, mais dans ce cas, un compte d’accès à l’application est nécessaire et on perd le SSO.

                • De faire du SSO à partir de l’authentification AD FS avec des applications supportant KCD (Kerberos Constrained Delegation), mais dans ce cas des comptes shadow sont nécessaires.

                Il est alors presque indispensable de mettre en œuvre une solution supplémentaire de provisioning comme Forefront Identity Manager pour la gestion de ces comptes supplémentaires, et/ou d’AD RMS pour la protection des données.


                François TACHOIRES - Consultant Sécurité

              1. Un point sur les solutions Microsoft Forefront TMG, Forefront UAG et DirectAccess

                Suite à l’annonce de l’arrêt du produit Forefront TMG (http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx), faisons un point sur les solutions Microsoft de proxy / firewall / accès distant. Les éléments importants à retenir sont :

                • Forefront TMG sera supporté par Microsoft jusqu’en 2020 (en support étendu, cf. http://support.microsoft.com/lifecycle/?c2=12300)
                • La roadmap de Forefront UAG reste inchangée – c’est depuis 4 ans et continue à être la passerelle de Microsoft. Le produit va donc notamment continuer à bénéficier de nouvelles fonctionnalités au travers de Service Packs et de futures versions ; pour la roadmap officielle, encore un peu de patience !
                • DirectAccess peut désormais être déployé (sans Forefront UAG) via le rôle « Remote Access » de Windows Server 2012

                Quelle solution pour quel usage ?

                Si vous utilisez Forefront TMG en tant que firewall, VPN site-à-site ou forward proxy web (filtrage d’URL, inspection), vous continuerez à bénéficier du support de Forefront TMG comme indiqué précédemment.

                Pour un accès au réseau interne pour des employés en mobilité, la solution autrefois basée sur le couple Forefront UAG / DirectAccess est désormais à déployer de préférence avec Windows Server 2012. En effet, le nouveau rôle Remote Access dans Windows Server 2012 permet de mettre en œuvre DirectAccess ou un VPN, plus simplement et avec son lot d’améliorations.

                Pour les autres besoins de mobilité, dans lesquels on souhaite publier des applications web à diverses populations, Forefront UAG reste la solution recommandée par Microsoft, en raison de ses services de sécurité applicative, de single sign on et surtout car nos équipes valident nos solutions exclusivement sur cette plateforme. Si vous utilisiez TMG pour publier des applications web de l’entreprise, vous pouvez envisager une migration vers Forefront UAG, plus adapté pour sur ce type de scénario et toujours maintenu.

                 

                Focus sur les bénéfices de Forefront UAG

                Forefont UAG vous permet principalement de mettre à disposition de vos employés, partenaires et fournisseurs un portail d’accès aux applications internes que vous souhaitez partager. Les points forts de la solution sont :

                • Une publication simple et rapide via des assistants de vos applications web, avec une sécurité intégrée (couche applicative). En effet les applications Web sont depuis longtemps très complexes à publier (HTMLl, Javascript, Ajax), et nécessitent donc des moteurs spécifiques de publication (et non un simple reverse proxy) et de sécurité applicative (firewall applicatif, conformité, …).
                • Une intégration complète et unique sur le marché avec les solutions Microsoft telles Exchange et Sharepoint, grâce à la collaboration inter-équipes produits chez Microsoft
                • Son extensibilité (SSO aux applications, modification du contenu à la volée, définition de politiques de contrôle d’accès en fonction des clients, personnalisation des interfaces…). C’est particulièrement utile pour des scénarios de BYOD (Bring Your Own Device).
                • Sa simplicité de gestion : une console d’administration pour la configuration et une interface web pour le monitoring
                • Son interopérabilité avec les protocoles de fédération via AD FS : un prochain article décrira quelques scénarios possibles dans cette configuration d’avenir

                François TACHOIRES - Consultant Sécurité.