[JSS 2014] Sécurité Via policies

Description :

Basée sur mon expérience dans les banques suisses, je vous propose une manière simple de contrôler la sécurité via les policies. Quels types de contrôle doit-on mettre en place au niveau de l’instance, au niveau de la base de données? Comment les gérer sur plusieurs serveurs? Avoir de beaux petits rapports ou emails en retour… Essayons de répondre ensemble à toutes ces petites questions que nous avons aux niveaux des audits de sécurité…

Level : 200

Date & heure : 2 décembre 2014 – 10h30

Speaker(s) : Stéphane Haby

 

Dans cette session Stéphane Haby nous a expliqué comment le DBA peut-il devenir le Gardien des données.

Dans un 1 er temps nous avons fait un tour des Bests practices de sécurisation générale puis dans un second nous avons vu comment mettre en place des policies sur SQL Server :

1.     Bests practices de sécurisation :

Afin de s’assurer de la sécurité des données existantes dans notre environnement Stéphane Haby nous propose de l’auditer afin de lister l’ensemble des points à surveiller.

Des résultats obtenus de son expérience, il va nous proposer de contrôler les niveaux suivants :

  1. Server
  2. Instance
  3. Database
  4. Data

1.Server :

Dans cette partie, nous avons fait le tour des bonnes pratiques à mettre place coté sécurité sur le serveur hébergeant la ou les instances de bases :

 

  • Permission sur les disques des serveurs (enlever le Read / Read & execute / List Folder) pour tous les utilisateurs)

Sec_Pol_1

 

  • Formater les partitions en NTFS ( Le format NTFS a pour avantage de disposer d’une encryptions et de l’ALS)
  • Installation que des outils nécessaires sur les instances ( faire attention aux outils ajouté automatiquement : par exemple DQS s’installe automatique lors de l’installation d’une infrastructure en cluster )
  • Installer les derniers Services Packs et Security Fix
  • Supprimer les scripts d’installation => un mdp administrateur peut trainer par la …
  • Désactiver NetBios et SMB

2. Coté instance :  

Dans cette partie Stéphane Haby nous expose les modifications à effectuer coté instance SQL Server permettant d’améliorer la sécurité : 

  • Changer les ports (il est facile d’attaquer le 1433)
  • Enlever le browser (on masque les instances … Seul les utilisateurs connaissant les bonnes chaines de connexions peuvent les trouver …)
  • Depuis la version 2012, il est possible de cacher les instances
  • Il est utile de créer un compte de service pour chaque instance
  • Utiliser des password Complexes
  • Préférer l’Authentication Windows
  • Eviter le Grant Control server to [public]
  • Revoke Extended and OLE Automation stored procedures for the public Role
  • Supprimer les BUILTIN\Administrator
  • Sa => mdp complexes
  • Supprimer les login obsolète
  • Désactiver le cmd shell
  • Désactiver cross db ownership chaining
  • Désactiver le sql Server web assistant
  • Désactiver CLR intégration
  • Désactiver le Ad hoc remote queries
  • Activer l’audit de sécurité
  • Activer les traces par défaut

3.Database :

 Dans cette partie nous avons fait une revue des bonnes pratiques coté base de données : 

  • Minimiser les rôles DBO
  • Supprimer les comptes orphelins (comptes d’utilisateurs n’ayant plus de bases rattachés ou plus utilisés)
  • Supprimer les schémas dbo 

4.Data 

   Enfin coté données nous avons vu que la meilleur sécurité était le cryptage de celles-ci

2.     Mise en place de policy  :

Les policies SQL Server correspondent à une stratégie de sécurité mis en place pour automatiser les contrôles de conformités du Serveur. 

Objectif :

  • Mettre en place des règles et vérifier les écarts sur les différentes instances ( par exemple : différences de droits sur les bases entre l’instance de DEV et de PROD , auditer les modifications intempestive de donnée effectué par des développeurs malin qui incluent des Grant dans les scripts , verifier l’arrivée de nouveaux utilisateurs … )
  • Automatiser le contrôle des instances par l’intermédiaire de reporting ou de mail  (Automatiser cet « Audit » en envoyant des mails réguliers aux DBA’s et aux équipes de sécurité)

Pour avoir une meilleure compréhension sur le concept de gestion axée sur les policies il ya quelques termes à comprendre :

  • Target– Permet à l’administrateur de gérer ses règles sur un type d’entité : Par exemple, une table, une base de données ou un index
  • Facet – Permet de gérer la gestion des règles. Un exemple de Facet est le nom d’un trigger ou la propriété de Réduction automatique de la base de données (Auto Shrink).
  • Conditions – Critères qui spécifie l’état de la « Facet » à vrai ou faux. Par exemple, vous pouvez vérifier et régler l’état d’une Facet qui vous donne des informations de toutes les procédures stockées dans le schéma «dbo».
  • Policy – Un ensemble de règles définies pour les objets de serveur ou les propriétés de base de données.

Sec_Pol_2

 

Sec_Pol_3

 

Après avoir compris ces différents concepts Stéphane Haby nous a présenté comment créer une policy et comment les déployer pour les exécutés : 

  • A la demande
  • De manière automatique
  • Lors de detection de changement

Dans sa démo Stéphane Haby nous détail chaque étape en nous présentant les tenant et les aboutissant et les différents rendus présentés aux DBA qui peuvent s’avérer utile sur le terrain:

  1. Créer une condition
  2. Créer la policy
  3. Evaluer la policy
  4. Le déployer sur plusieurs serveurs
  5. L’automatiser (par l’intermédiaire de rapport ou de mail)

Julien PIERRE

Consultant Décisionnel

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s