Sécurité dynamique dans les cubes SSAS avec SQL Server 2012

Avec l’ouverture des données Power BI Self-Service vers les utilisateurs (vu dans plusieurs de mes missions) les métiers veulent gérer eux même les droits ou périmètres sur de nombreux utilisateurs finaux (>1000).

En effet dans certains domaines, nous avons une forte contrainte de confidentialité des données contenues dans les cubes SSAS. Les juridictions qui doivent s’appliquer peuvent être changées avec des cadences variables allant de la journée, à des cadences inférieures (temps réel). Pour cela, l’ensemble de la sécurité mise en œuvre est stocké dans la source de données du cube, qui détermine qui peut voir quoi.

A travers cet article, nous allons voir comment rendre dynamique une sécurité de cube SSAS basée sur l’appel à une procédure stockée.

Lire la suite

SQL 2014 et la gestion de la sécurité

  • Mercredi 12 février : 16h30-17h15
  • Salle : 242B
  • Audiences : Professionnels de l’IT
  •  Thèmes : Infrastructure des systèmes d’information
  • Intervenant : Franck Mercier (Microsoft France), Pascale DOZ (Pascale Doz Consulting)
  • Niveau : Intermédiaire (200)

Durant cette session nous passerons en revue les fondamentaux de la sécurité dans une base de données. Puis nous vous présenterons des méthodes de protection des données, ainsi que les outils pour superviser les bases. Et bien entendu, nous parlerons aussi des nouveautés apportés par la version 2014 de SQL Server !

1.     Sécurisation des comptes

–        Sécuriser le compte SA

  • Pas de mot de passe sous le clavier
  • Pas de mot de passe sur l’écran
  • Pas de mot de passe avec une sécurité faible ou qui ne change jamais

–        Donner les bons droits aux bonnes personnes

–        Essayer d’utiliser les comptes AD avec les droits correspondant à l’usage des utilisateurs

–        Utiliser une politique de changement de MDP régulière

2.     Accès aux données

–        Contrôle sur les droits 

–        SQL 2014 offre la possibilité de bloqué la visibilité  des données aux administrateurs pour l’ensemble des versions :

  • Ce système est actuellement buggé pour le moment car l’administrateur peut récupérer l’accès aux données par l’intermédiaire d’un GRANT le point a été remonté à Microsoft …

–        L’accès aux données peut être filtré pour les autres utilisateurs par l’intermédiaire des servers ROLE dispo depuis SQL SERVER 2012.

Certificat

–        L’accès aux données peut être attribué par l’intermédiaire de certificat :

  • Ex : Les données du marketing ne peuvent être visibles par les vendeurs.

–        Pour donner l’accès on met en place un système de certificat permettant de contrôler qui accède aux données.

Utilisation de l’impersonation

–        Empêcher l’emploi de l’impersonation sur le serveur

3.     Mise en place d’audit

L’objectif des audits est de contrôler qui accède aux données et de voir leurs utilisations

(Création d’audit d’utilisation)

4.     Utiliser contained DB

Cette base de données contient les logins de l’instance, l’intérêt est de faciliter la migration des bases de données

5.     D’autres outils peuvent servir à sécuriser la base :

  • Chiffrement des backups
  • SQL injection
  • Gestion de l’environnement de Chiffrement
  • DLL trigger
  • Gestion de la stratégie des instances
  • Truthworthy

Point fort de la session : Sensibilisation aux problèmes de sécurisation des de données SQL Server avec une vue panoramique des outils et des best practice de sécurité

Liens utile : http://blogs.technet.com/b/sql/archive/2013/10/01/sql-server-chez-les-clients-confidentialite-des-donnees.aspx

Vidéo : https://www.youtube.com/watch?feature=player_embedded&v=E9cGpjkxBik

Slides : http://fr.slideshare.net/TechnetFrance/sql-2014-et-la-gestion-de-la-scurit-31662361

Securing Windows Store Applications and REST Services with Active Directory (3-518)

Session animée par Vittorio Bertocci

L’objectif de la session est de montrer comment sécuriser son app avec un AD on-premise ou dans Azure (du coup dans un contexte business).

Comment faire face aux ressources déportées en dehors du réseau interne, aux apps dans le cloud qui ont besoin de l’AD, au BYOD ou aux devices hors domaine… sans rendre fou l’IT ?

# Accéder aux ressources hors du réseau d’entreprise

Il  commence par expliquer les principes d’un serveur d’authentification avec un endpoint d’authentification + un endpoint  de jeton d’accès qu’on pourra ensuite utiliser pour accéder aux ressources.

Puis les jetons de refresh pour ne pas avoir à redemander ses credentials à l’utilisateur toutes les 5 minutes.

On passe maintenant à Windows Azure Active Directory qui, dans un contexte business, sera une projection de votre AD on-premise.

Azure AD dispose :

  • de différents endpoints d’authentification : OAuth2, SAML, WS-Federation, Metadata
  • un portail web de gestion des comptes
  • une API Graph pour récupérer les permissions

Début des démos.

1ère démo : présentation de la gestion de l’AD sur le portail Azure avec la configuration d’une app

2ème démo : une app de test pour montrer les différents types d’appels

Windows Server 2012 R2 ADFS supporte maintenant OAuth2.

# Authentification et session

Windows Azure Authentication Library (AAL) pour aider le développeur pour gérer les échanges de token , le cache… Dispo via un package NuGet.

AAL fonctionne avec Windows Azure AD et Windows Server ADFS.

On nous montre les quelques lignes de codes pour un appel sécurisé depuis une app Win8 (récupération d’un token et appel d’un service REST avec ce token).

AAL wrappe le WebAuth broker. Nouveauté avec Win8.1 on a la possibilité d’implémenter la sélection d’un compte dans les settings (plus de details dans la session 3-113)

# Device hors domaine

Nouveauté 8.1 : Workplace-join pour configurer un accès à un AD qu’on peut ensuite utiliser dans une app

On est en retard, les slides vont très vite…

Session intéressante, à creuser pour voir comment mettre tout ça en œuvre.

Pierre-Yves Hemery

Comment ne pas simplifier la vie aux pirates sur votre site ASP.NET MVC

Voici une capture d’écran de l’en-tête de la réponse HTTP envoyée par une application ASP.NET MVC hébergée par un serveur web IIS :

Capture de réponse HTTP

Comme on le voit, avec chaque requête à laquelle l’application répond sont envoyées un certain nombre d’informations concernant :

  • Server : le type de serveur hébergeant l’application, ainsi que sa version.
  • X-AspNet-Version : la version du moteur ASP.NET utilisé par l’application.
  • X-AspNetMvc-Version : la version spécifique d’ASP.NET MVC utilisée par l’application.
  • X-Powered-By : Le langage de programmation utilisé côté serveur.

Tout cela peut s’avérer extrêmement néfaste pour votre application! En effet, ces informations ne regardent personne, et surtout pas les pirates qui ne demandent rien de mieux que d’essayer de s’infiltrer par toutes les failles de sécurité concernées par ces technologies, et auxquelles votre serveur est susceptible d’être sensible s’il n’a pas été correctement mis à jour.

Pour vous donner une idée, cela revient à donner à un cambrioleur votre adresse ainsi que la marque et le modèle de votre serrure. Tout ce qui lui manque, c’est la forme de la clef.

Malheureusement, communiquer ces informations est le comportement par défaut de toute application ASP.NET MVC. Nous allons voir néanmoins comment modifier ce comportement pour faire disparaître ces données de nos en-têtes de réponse HTTP.

Commençons par le plus simple : pour retirer l’en-tête X-AspNetMvc-Version, il suffit de rajouter la ligne suivante dans la méthode Application_Start qui se trouve dans la classe MvcApplication de votre fichier Global.asax.cs.

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();
    // Ajoutez cette ligne :
    MvcHandler.DisableMvcResponseHeader = true;

    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);
}

Pour ce qui est des en-têtes X-AspNet-Version et X-Powered-By, il va vous falloir effectuer quelques modifications dans le fichier web.config à la racine de votre application web.

D’abord, s’il n’est pas encore présent, ajoutez un nœud « configuration/system.web/httpRuntime ». Pour désactiver l’en-tête X-AspNet-Version, ajoutez-y un attribut « enableVersionHeader » et donnez-lui la valeur « false ».

<system.web>
    <httpRuntime enableVersionHeader="false" />
    <!-- Ici le reste de la section system.web -->
</system.web>

Ensuite, pour supprimer l’en-tête X-Powered-By, rendez-vous dans la section « configuration/system.webServer ». S’ils ne sont pas encore présents, ajoutez-y la série de nœuds « httpProtocol/customHeaders », et adjoignez-y un nœud « remove » dont l’attribut « name » devra avoir la valeur « X-Powered-By ». Notez que comme pour tout ce qui a trait à la section « configuration/system.webServer », vous pouvez directement effectuer cette manipulation dans la console d’IIS 7.x.

<system.webServer>
    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>
    <!-- Ici le reste de la section system.webServer -->
</system.webServer>

L’en-tête Server est le cas le plus délicat. En effet, il est impossible de supprimer cet en-tête, que ce soit dans la configuration de notre application web, ou dans celle d’IIS. Pour arriver à nos fins, nous allons donc devoir intercepter la réponse HTTP avant que celle-ci soit envoyée au client, et la modifier.

Pour effectuer cette opération, nous allons altérer le pipeline de traitement de notre application web, en utilisant un HttpModule. Pour cela, il suffit de créer une classe héritant de IHttpModule. J’ai choisi d’appeler ma classe « CustomHeadersModule ». Nous devons d’ores et déjà implémenter les membres de l’interface « IHttpModule »; il s’agit des méthodes « Init » et « Dispose ». Vous pouvez laisser « Dispose » vide. Par contre dans « Init », nous allons nous abonner à l’évènement « PreSendRequestHeaders ».

public class CustomHeadersModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.PreSendRequestHeaders += OnPreSendRequestHeaders;
    }

    public void Dispose()
    {
    }

    private void OnPreSendRequestHeaders(object sender, EventArgs e)
    {
        HttpContext.Current.Response.Headers.Remove("Server");
        // Ou bien
        HttpContext.Current.Response.Headers.Set("Server", "Apache");
    }
}

Dans l’EventHandler qui va nous servir à nous abonner, nous allons pouvoir librement et au choix, soit supprimer complètement l’en-tête Server, soit plus sournoisement la modifier pour donner l’impression que nous utilisons en réalité une autre technologie de serveur web (ici en l’occurrence Apache, très populaire et principal concurrent d’IIS).

Il reste toutefois une action à effectuer : enregistrer ce HttpModule dans le pipeline de traitement de notre application ASP.NET MVC, ce qui se fait soit directement dans le console d’IIS, soit en modifiant à nouveau la section « configuration/system.webServer » de notre fichier web.config, cette fois-ci dans la sous-section « modules ».

<system.webServer>
    <modules>
        <add name="CustomHeadersModule" type="VotreNamespace.CustomHeadersModule" />
    </modules>
    <!-- Ici le reste de la section system.webServer -->
</system.webServer>

Toutes ces customisations vont contribuer à rendre votre application web plus sûre. Mais bien sûr, avoir un serveur web correctement mis à jour est encore le meilleur moyen de se prémunir des attaques de pirates.