sécurité sql grics des applications windows de la grics ......la base de données locale bdl1 de...

Sécurité SQL GRICS des applications Windows

de la GRICS

Février 2017

Février 2017

Table des matières

1 PRÉSENTATION ............................................................................................................................. 3

2 PRÉALABLES À LA SÉCURITÉ SQL GRICS .................................................................................. 4

3 EMPLACEMENT ET DÉFINITION DES FICHIERS DE SÉCURITÉ SQL GRICS .............................. 5

4 PREMIÈRE EXÉCUTION DE L’UTILITAIRE GRICSDB.EXE ............................................................ 7

5 EXPORTATION ET IMPORTATION DE CLÉS ENTRE LES INSTANCES DE SERVEUR SQL ........ 9

6 IMPLANTATION DE L’AUTHENTIFICATION LDAP ....................................................................... 12

7 ACTIVATION DE L’AUTHENTIFICATION LDAP ............................................................................ 16

ANNEXE A – Démarche pour restaurer une base de données SQL ....................................................... 18

ANNEXE B – Démarche pour déplacer une base de données vers une autre instance de serveur SQL . 20

ANNEXE C – Démarche pour changer le mot de passe du code d’accès GRICS_SECURE ................... 21

ANNEXE D – Démarche pour changer le mot de passe des rôles d’application GRICS .......................... 22

ANNEXE E – Démarche pour changer la clé de jonction d’une instance de serveur SQL ....................... 23

ANNEXE F – Démarche pour changer la phrase secrète d’une instance de serveur SQL ....................... 24

ANNEXE G – Historique des phrases secrètes d’une instance de serveur SQL...................................... 27

ANNEXE H – Démarche pour synchroniser vos codes d’utilisateurs à partir des codes de l’annuaire LDAP .. 28

3 © GRICS, 2013-2017

Sécurité SQL GRICS Chapitre 1

Présentation

1 Présentation

Ce guide explique les étapes nécessaires aux applications GRICS Windows afin de permettre l’authentification à un serveur LDAP et d’accroître la sécurité des échanges de données entre les applications GRICS Windows et les serveurs SQL et LDAP. Dans ce document, l’appellation « Serveur SQL » désigne le produit Microsoft « SQL Server ».

En activant l’authentification LDAP, les utilisateurs peuvent s’identifier à une application GRICS en utilisant leur code d’utilisateur Windows. L’application remet d’abord l’identité de l’utilisateur au serveur SQL et celui-ci relaye ensuite l’information au serveur LDAP pour les besoins d’authentification. Tout le processus d’authentification entre le poste client et le serveur SQL se fait de façon sécurisée.

De plus, l’échange de données entre plusieurs serveurs SQL et l’application profite d’une sécurité accrue par le biais d’une connexion dite de jonction entre les bases de données. Ceci est réalisé par l’établissement d’une zone de confiance entre les différentes instances de serveur SQL et l’application par le biais de l’échange d’une clé (trust).

4


Préalables à la sécurité SQL GRICS

2 Préalables à la sécurité SQL GRICS Dans le cadre de la nouvelle sécurité SQL GRICS des applications Windows de la GRICS, certains préalables sont nécessaires :

1. Un utilitaire de sécurité appelé GricsDB.exe doit être exécuté sur toutes les instances de serveur SQL où une base de données d'application GRICS existe.

2. Cet utilitaire ne peut être exécuté que localement sur le serveur SQL, soit directement sur le poste où se trouve le serveur SQL ou par une connexion de bureau à distance (Remote Desktop Connection) vers ce dernier.

3. Le compte associé au service « SQL Server » doit posséder les droits (Contrôle total) dans le répertoire BINN de l’instance du serveur SQL.

GricsDB.exe octroie automatiquement au compte du service SQL les droits (Contrôle total) dans le répertoire BINN de l’instance du serveur SQL sélectionnée.

Des fichiers de sécurité seront automatiquement créés par l’utilitaire GricsDB.exe dans ce répertoire.

4. Le module « Compatiilité descendante de Microsoft SQL Server 2005 » doit être installé sur le poste où réside le serveur SQL. Le choix de langue de ce module n’est pas important. La version Française fonctionne aussi bien avec la version Anglaise de SQL Server et vice-versa.

Le fichier d’installation de ce module se trouve sur le site de Microsoft à l’adresse suivante : http://www.microsoft.com/fr-fr/download/details.aspx?id=11988.

Vous devrez sélectionner le « package » SQLServer2005_BC_x64.msi pour un système d’exploitation 64 bits ou SQLServer2005_BC.msi pour un système d’exploitation 32 bits.

Lors de l’installation, vous aurez le choix de cinq composants. Seul le deuxième composant est requis « Objets SQL_DMO (SQL Distributed Management Objets) ».

5. Le module « Microsoft .NET Framework 3.5 SP1 » doit être installé sur le poste où réside le serveur SQL. Le nom du fichier d’installation de ce module est « dotnetfx35.exe » et se trouve sur le site de Microsoft à l’adresse suivante : http://www.microsoft.com/fr-ca/download/details.aspx?id=25150.

5 © GRICS, 2013-2017


Emplacement et définition des fichiers de sécurité SQL GRICS

3 Emplacement et définition des fichiers de sécurité SQL GRICS Les fichiers de sécurité SQL GRICS générés par l’utilitaire GricsDB.exe sont situés dans le répertoire BINN de l’instance du serveur SQL et se décrivent comme suit :

Passphrase_1.txt Fichier contenant la phrase secrète qui sert à chiffrer l’information des fichiers grics_secure_pswd.txt, Approlepswd.txt et toute donnée sensible des bases de données sur l’instance du serveur SQL.

Il est très important de prendre une copie de sécurité de ce fichier et de la conserver dans un endroit sûr, car les données sensibles d’une base de données ne sont déchiffrables qu’avec la phrase secrète du fichier Passphrase_1.txt. Si le fichier est perdu et que la phrase secrète est oubliée, toutes les données sensibles de l’instance du serveur SQL seront perdues à jamais.

Une donnée sensible est une information chiffrée dans la base de données à l’aide d’un algorithme dont la clé de chiffrement est la phrase secrète contenue dans le fichier Passphrase_1.txt. Un mot de passe, par exemple, illustre bien la notion d’une donnée sensible. Il existe plusieurs données sensibles à l’intérieur d’une base de données.

Passphrase_n.txt Fichier contenant les clés de jonction des instances de serveur SQL avec lesquelles les applications établissent des connexions vers d’autres serveurs SQL pour récupérer des données. Chaque ligne du fichier contient le nom de l’instance du serveur SQL et la clé séparée par une virgule. Par exemple :

SERVEUR1,MEYFVEZIDGBULODNADYZIVIOXVNMIUYXORKLKKWMRFNPXSBVWDAOIFVNSNRNAN

Grics_secure_pswd.txttxt Fichier contenant le mot de passe du code d’accès GRICS.SECURE.

Approlepswd.txt Fichier contenant le mot de passe des rôles d’application des bases de données GRICS.

LdapConfig.ini Fichier de configuration servant à l'authentification LDAP. Son contenu est entièrement géré par l’utilitaire GricsDB.exe.

Server_App_Accepted.txt Fichier contenant des filtres pour les connexions de jonction :

Chaque ligne du fichier contient un filtre qui est constitué de 1, 2 ou 3 paramètres séparés par une virgule. Les blancs ne sont pas permis.

6


Emplacement et définition des fichiers de sécurité SQL GRICS

Paramètre 1 : * ou nom de la base de données de l’instance courante qui accepte les connexions de jonction provenant d’autres instances de serveur SQL et bases de données. Par exemple :

* L’instance de serveur SQL courante accepte toutes les connexions de jonction, peu importe la provenance des instances de serveur SQL qui se connectent.

BDL1,* La base de données locale BDL1 de l’instance de serveur SQL courante accepte toutes les connexions de jonction, peu importe la provenance des instances de serveur SQL qui se connectent.

Paramètre 2 : Si le paramètre 1 est différent de *, alors le deuxième paramètre sera * ou encore le nom de l’instance du serveur SQL autorisé à établir une connexion de jonction. Par exemple :

BDL1,S1,* La base de données locale BDL1 de l’instance de serveur SQL courante accepte les connexions de jonction provenant de l’instance de serveur SQL S1, peu importe les bases de données de S1.

Paramètre 3 : Si les paramètres 1 et 2 sont différents de *, alors le troisième paramètre sera * ou encore le nom de la base de données de l’instance du serveur SQL autorisé à établir la connexion de jonction. Par exemple :

BDL1,S1,BD1 La base de données locale BDL1 de l’instance de serveur SQL courante accepte les connexions de jonction provenant uniquement de la base de données BD1 de l’instance de serveur SQL S1.

7 © GRICS, 2013-2017


Première exécution de l’utilitaire GricsDB.exe

4 Première exécution de l’utilitaire GricsDB.exe Lors de la toute première exécution de l’utilitaire sur une instance de serveur SQL, il vous sera demandé de saisir une phrase secrète qui servira de base pour le chiffrement des données. Comme expliquée précédemment, cette phrase sera conservée dans le fichier Passphrase_1.txt et également dans un historique de phrases secrètes (sujet abordé plus loin dans le document).

Démarrez d’abord l’utilitaire GricsDB.exe :

Identifiez-vous ensuite avec un code d’utilisateur faisant partie du rôle « SysAdmin » :

8


Première exécution de l’utilitaire GricsDB.exe

Saisissez la phrase secrète en question. Par exemple :

9 © GRICS, 2013-2017


Exportation et importation de clés entre les instances de serveur SQL

5 Exportation et importation de clés entre les instances de serveur SQL Afin d’accroître la sécurité des échanges de données entre les applications et les serveurs SQL, la GRICS a modifié sa façon d’accéder aux données provenant d’une autre instance de serveur SQL.

Lorsqu’une application comme GPI désire accéder aux données de JADE se trouvant sur une autre instance de serveur SQL, il est maintenant nécessaire d’exporter et d’importer des clés afin d’établir une jonction sécurisée entre les deux instances de serveur SQL.

L’application GPI doit connaître la clé de l’instance du serveur SQL de JADE pour être en mesure d’accéder à ses données. Par contre, si ces deux bases de données se trouvent sur la même instance de serveur SQL, alors il est inutile d’exporter et d’importer les clés.

Pour exporter et importer les clés, vous devez exécuter l’utilitaire GricsDB.exe sur le serveur SQL où se trouve la base de données (JADE dans ce cas-ci) et exporter la ou les clés que vous désirez. Ces clés sont inscrites dans un fichier dont l’extension est .GSK (GRICS Security Key).

Démarrez l’utilitaire et choisissez ensuite l’exportation de clés de jonction :

Choisissez les instances voulues parmi la liste des instances de serveur SQL :

10



Choisissez un nom et sauvegardez le fichier à l’emplacement désiré :

Vous devez récupérer ce fichier de façon sécuritaire sur l’instance de serveur SQL où se trouve la base de données (GPI dans ce cas-ci) soit en le déplaçant physiquement à l’aide d’une disquette ou avec une clé USB, ou encore, en déplaçant le fichier dans un répertoire dont l’accès est restreint à l’administrateur.

Si vous n’avez pas accès facilement au serveur, une autre méthode consiste en l’utilisation d’une connexion de bureau à distance (Remote Desktop Connection). Il est important d’éviter de créer un partage réseau (share) sur les répertoires BINN des instances de serveur SQL. Quoique cette option s’avère attrayante de par sa simplicité, elle pourrait induire une faille de sécurité indésirable.

Ensuite, sur l’instance du serveur où se trouve la base de données (GPI dans ce cas-ci), vous devez exécuter l’utilitaire GricsDB.exe et importer la ou les clés.

Choisissez d’abord l’importation de clés de jonction :

11 © GRICS, 2013-2017



Tapez ou recherchez ensuite le fichier à importer :

12


Implantation de l’authentification LDAP

6 Implantation de l’authentification LDAP L’authentification LDAP, dans une application Windows, permet à un utilisateur de se connecter en utilisant son code d’utilisateur et son mot de passe provenant d’un serveur LDAP. Trois technologies d’annuaires sont présentement supportées : « Active Directory » de Microsoft, « eDirectory » de Novell et « OpenLDAP » en source libre sous UNIX/Linux.

Préalables à l’utilisation de l’authentification LDAP

Vous devez avoir complété la conversion des codes d’utilisateurs de la base de données de l’application pour les synchroniser avec leurs valeurs respectives dans le serveur LDAP. Pour plus de détails, consultez l’ANNEXE H – Démarche pour synchroniser vos codes d’utilisateurs à partir des codes de l’annuaire LDAP.

Si un lien sécurisé par SSL est utilisé entre le serveur SQL et le serveur LDAP (recommandé) :

Vous devez importer un certificat d’autorité de certification sur le serveur SQL de l’application, si vous utilisez votre propre certificat pour les connexions sécurisées SSL.

Si vous avez acquis un certificat d’une tierce partie, le certificat d’autorité de certification doit être récupéré chez le fournisseur du certificat.

Principes de fonctionnement

Au démarrage d’une application GRICS Windows en mode d’authentification LDAP, les actions suivantes sont effectuées :

L'application fournit le code d'utilisateur et le mot de passe au serveur SQL de façon sécuritaire.

Le serveur SQL établit une connexion au serveur LDAP et lui relaye le code d'utilisateur. S’il s’agit d’un annuaire eDirectory ou OpenLDAP, une vérification supplémentaire est effectuée pour s’assurer que le code d’utilisateur est présent de façon unique. S’il existe un doublon dans l’une ou l’autre des branches de l’annuaire, un échec se produit à la connexion.

Si tout va bien, le mot de passe est relayé au serveur LDAP pour l’authentification.

L’implantation de l’authentification LDAP nécessite deux actions :

Configuration LDAP.

Activation de l’authentification LDAP.

13 © GRICS, 2013-2017



Configuration LDAP

La configuration LDAP est activée en sélectionnant l’option suivante dans la fenêtre de choix d’actions de l’utilitaire GricsDB.exe exécuté sur l’instance du serveur SQL :

La liste déroulante « Base de données » permet d’appliquer une configuration LDAP à une ou plusieurs bases de données. Si vous ne possédez qu’un seul annuaire LDAP, vous pouvez appliquer une configuration par défaut pour l’ensemble des bases de données à l’aide de l’entrée « Toutes ». Si une ou des bases de données doivent utiliser un second annuaire, veuillez les sélectionner dans la liste déroulante et appliquer une autre configuration LDAP. Seules ces bases de données n’utiliseront pas la configuration par défaut.

L’activation de l’authentification LDAP se fait dans une étape ultérieure. Consultez le chapitre 7 Activation de l’authentification LDAP.

14



Pour appliquer une configuration à une ou plusieurs bases de données, vous devez cocher la case « Configurer les paramètres LDAP ». Pour détruire la configuration, vous n'avez qu'à décocher l'entrée et cliquer sur le bouton « Appliquer ». Ceci aura comme impact de désactiver l’authentification LDAP pour la base de données.

Le champ « Nom du serveur LDAP » doit contenir le nom du domaine et non pas un nom spécifique de serveur.

La liste déroulante « Type de serveur » indique si le serveur est de type « Active Directory » de Microsoft, « eDirectory » de Novell ou encore « Open LDAP » sous UNIX/Linux.

Les accès au serveur se font par un port TCP, généralement 389 ou encore 636, si les connexions se font en utilisant SSL.

Les autres champs de configuration dans « Paramètres avancés » ne sont pas utilisés, si le type de serveur est AD (Microsoft Active Directory).

Le champ « Contexte de recherche » est nécessaire pour eDirectory et OpenLDAP. Ce contexte correspond optionnellement à une suite de « OU » (Organizational Units) et à l’organisation dans le cas de eDirectory (ex. : OU=eleves,O=cs).

Il correspond optionnellement à une suite de « OU » et obligatoirement à une suite de « DC » (Domain Components) pour le type OpenLDAP (ex. : OU=eleves,DC=cs,DC=qc,DC=ca).

Le champ « Usager de recherche » désigne le code d'utilisateur de recherche servant à localiser l'entrée de l'utilisateur à authentifier sur le serveur LDAP. Son format est spécifique à chaque type de serveur. Le « DN » (Distinguished Name) doit être fourni au complet.

Exemple avec eDirectory :

CN=searchuser,OU=applications,O=cs

Exemple avec OpenLDAP :

UID= searchuser,OU=applications,DC=cs,DC=qc,DC=ca

L’usager de recherche saisi doit avoir la permission d’accéder à tous les utilisateurs de l’annuaire OpenLDAP ou eDirectory en mode lecture. La valeur de l’usager de recherche sert à récupérer l’identifiant complet (le « DN ») de l’utilisateur qui désire s’authentifier.

Le champ « Mot de passe » est associé à l’usager de recherche qui est utilisé lors de la connexion.

La case à cocher « Connexion sécurisée SSL » nécessite un certificat SSL sur le serveur LDAP et le certificat CA (Certificate Authorities) correspondant sur le serveur SQL.

15 © GRICS, 2013-2017



Connexion sécurisée SSL

Si la connexion sécurisée SSL est activée, il faut alors gérer le certificat servant à cette connexion.

Selon le type de serveur et si vous utilisez votre propre certificat, vous devrez exécuter au moins un des points suivants selon le type d’annuaire :

eDirectory :

Création d’un certificat pour les échanges SSL avec un serveur « eDirectory ». Point à surveiller : la valeur de l’attribut CN (Common Name) du certificat lors de sa création.

Exportation du certificat d’autorité de certification à partir d’un serveur Novell vers la machine utilisée comme serveur SQL. C’est le ou les certificats d’autorité qui ont servi lors de la création du certificat dans l’étape précédente.

OpenLDAP :

Création d’un certificat pour les connexions sécurisées SSL avec un serveur « OpenLDAP ». Point à surveiller : la valeur de l’attribut CN du certificat lors de sa création.

Exportation d’un certificat d’autorité de certification à partir d’un serveur UNIX/Linux vers la machine utilisée comme serveur SQL. C’est le ou les certificats d’autorité qui ont servi lors de la création d’un certificat dans l’étape précédente.

Active Directory :

Configuration de la console de gestion Microsoft pour importer un certificat d’autorité de certification sur le serveur SQL de l’application.

Importation de certificats d’autorité de certification sur la machine utilisée comme serveur SQL.

16


Activation de l’authentification LDAP

7 Activation de l’authentification LDAP L'authentification LDAP est activée à l’aide de la case d’option de la fenêtre suivante avec l’utilitaire GricsDB.exe exécuté sur le serveur SQL :

Faites passer, de la liste de gauche à la liste de droite, la base de données pour laquelle l’authentification LDAP peut être activée :

Notez que seules les bases de données qui ont préalablement été configurées pour l’authentification LDAP apparaissent dans la liste. À moins bien sûr qu’une configuration pour toutes les bases de données ait été effectuée, toutes les bases de données GRICS seront disponibles.

17 © GRICS, 2013-2017


Activation de l’authentification LDAP

Références

Pour les sections énumérées ci-dessous, consultez le chapitre 8 Implantation de l'authentification LDAP du document suivant :

https://babillard.grics.qc.ca/general/AppInternet/Documentation/GuideDeRéférence-ApplicationsInternet-9Juillet2010.pdf

Selon le service annuaire utilisé, choisissez les sections appropriées :

eDirectory :

Création d’un certificat pour les échanges SSL avec un serveur « eDirectory ».

Exportation d’un certificat d’autorité de certification à partir d’un serveur « Netware ».

OpenLDAP :

Création d’un certificat pour les échanges SSL avec un serveur « OpenLDAP ».

Exportation d’un certificat d’autorité de certification à partir d’un serveur « Linux ».

Active Directory :

Configuration de la console de gestion Microsoft pour importer un certificat d’autorité de certification sur le serveur Internet de l’application (*).

Importation d’un certificat d’autorité de certification sur le serveur Internet de l’application (*).

(*) Notez que ces sections s'appliquent pour le serveur SQL de l'application au lieu du serveur Internet de l'application.

18

Sécurité SQL GRICS Annexe A

Démarche pour restaurer une base de données SQL

Annexe A – Démarche pour restaurer une base de données SQL 1. Vous devez obtenir la phrase secrète correspondant à la base de données à restaurer. Quoique ce

fichier se situe dans le répertoire BINN de l’instance du serveur SQL, si la phrase secrète a été changée depuis la prise de copie, vous devez récupérer la phrase secrète qui correspond chronologiquement avec la copie de la base de données à restaurer.

Pour plus de détails sur le changement de phrase secrète, consultez l’ANNEXE F – Démarche pour changer la phrase secrète d’une instance de serveur SQL.

2. Si la phrase secrète correspondant à la base de données prise en copie de sécurité est identique à la phrase secrète de l’instance de serveur SQL courante, vous n’avez plus qu’à restaurer la base de données en question et ignorer les étapes suivantes.

3. Restaurez la base de données.

4. À partir de l’utilitaire GricsDB.exe, déchiffrez d’abord les données sensibles de la base de données en lui fournissant la phrase secrète correspondant à la base de données prise en copie de sécurité. Par la suite, chiffrez ces données avec la phrase secrète de l’instance de serveur SQL courante.

Pour ce faire, choisissez l’action suivante :

19 © GRICS, 2013-2017

Sécurité SQL GRICS Annexe A

Démarche pour restaurer une base de données SQL

Suivez ensuite l’exemple ci-dessous pour procéder au déchiffrement avec l’ancienne phrase secrète et au chiffrement de la base de données avec la phrase secrète courante. Vous pouvez extraire la phrase secrète d’une instance de serveur SQL en cliquant sur le bouton […]. Vous devez fournir un code ayant le privilège SYSADMIN pour l’extraction.

5. Une fois cette opération terminée, exécutez l’application DB (exemple : GpiDb.exe) avec l’option de recréation des codes d’utilisateurs.

20

Sécurité SQL GRICS Annexe B

Démarche pour déplacer une base de données vers une autre instance…

Annexe B – Démarche pour déplacer une base de données vers une autre instance de serveur SQL 1. Vous devez obtenir la phrase secrète de l’instance du serveur SQL de destination.

2. À partir de l’utilitaire GricsDB.exe, déchiffrez d’abord les données sensibles de la base de données en lui fournissant la phrase secrète de l’instance de serveur SQL d’origine. Par la suite, chiffrez ces données avec la phrase secrète de l’instance de serveur SQL de destination.

Suivez ensuite l’exemple ci-dessous pour procéder au déchiffrement avec la phrase secrète de l’instance de serveur SQL d’origine et au chiffrement de la base de données avec la phrase secrète de l’instance de serveur SQL de destination. Vous pouvez extraire la phrase secrète d’une instance de serveur SQL en cliquant sur le bouton […]. Vous devez fournir un code ayant le privilège SYSADMIN pour l’extraction.

3. Déplacez la base de données vers l’instance du serveur SQL de destination.

4. Sur l’instance du serveur SQL de destination, exécutez l’application DB (exemple : GpiDb.exe) avec l’option de recréation des codes d’utilisateurs.

5. Notez que la base de données source n’est plus utilisable sur l’instance du serveur SQL d’origine, car les données sensibles ne sont plus chiffrées à partir de la phrase de cette instance de serveur SQL.

21 © GRICS, 2013-2017

Sécurité SQL GRICS Annexe C

Démarche pour changer le mot de passe du code d’accès GRICS_SECURE

Annexe C – Démarche pour changer le mot de passe du code d’accès GRICS_SECURE Quoique le mot de passe du code d’accès SQL GRICS_SECURE ne soit exclusivement connu que par l’instance de serveur SQL qui s’en sert, voici tout de même la marche à suivre pour le modifier si jamais vous craignez qu’il puisse être connu.

1. Détruisez le fichier « grics_secure_pswd.txt » du répertoire BINN de l'instance du serveur SQL.

2. Exécutez l’utilitaire GricsDB.exe comme suit :

GricsDB.exe {nom du serveur}, {code d’accès}, {mot de passe}, cf, force

Le paramètre « code d’accès » correspond à la connexion SQL ayant les privilèges « SysAdmin ».

Le paramètre « mot de passe » correspond au mot de passe du code d’accès en question.

Les paramètres « cf » et « force » correspondent respectivement à la langue utilisée (CF = Canadien Français) ainsi qu’à l'exécution inconditionnelle du script.

L'utilitaire GricsDB.exe démarrera en mode silencieux (sans dialogue) et forcera la recréation du fichier « grics_secure_pswd.txt ». Ce dernier contiendra un mot de passe généré aléatoirement et chiffré, associé au code d’accès GRICS_SECURE. De plus, l’utilitaire se chargera de modifier le mot de passe du code d’accès en question pour l’instance de serveur SQL.

22

Sécurité SQL GRICS Annexe D

Démarche pour changer le mot de passe des rôles d’application GRICS

Annexe D – Démarche pour changer le mot de passe des rôles d’application GRICS Quoique le mot de passe des rôles d’application GRICS ne soit exclusivement connu que par l’instance de serveur SQL qui s’en sert, voici tout de même la marche à suivre pour le modifier si jamais vous craignez qu’il puisse être connu.

1. Détruisez le fichier « Approlepswd.txt » du répertoire BINN de l'instance du serveur SQL.






L'utilitaire GricsDB.exe démarrera en mode silencieux (sans dialogue) et forcera la recréation du fichier « Approlepswd.txt ». Ce dernier contiendra un mot de passe généré aléatoirement et chiffré qui servira pour les rôles d’application GRICS : GRICS_MASTER et GRICS_MASTER_JUNCTION. De plus, l’utilitaire GricsDB.exe se chargera de modifier le mot de passe de ces rôles pour toutes les bases de données des applications GRICS se trouvant dans cette instance du serveur SQL.

23 © GRICS, 2013-2017

Sécurité SQL GRICS Annexe E

Démarche pour changer la clé de jonction d’une instance de serveur SQL

Annexe E – Démarche pour changer la clé de jonction d’une instance de serveur SQL Quoique la clé de jonction d’une instance de serveur SQL ne soit exclusivement connue que par l’instance elle-même, voici la marche à suivre pour la modifier si jamais vous craignez qu’elle puisse être connue.

1. Éditez le fichier « Passphrase_n.txt » du répertoire BINN de l'instance du serveur SQL avec Bloc-notes (NotePad) et supprimez la ligne correspondant au nom du serveur de l'instance courante.






L'utilitaire GricsDB.exe démarrera en mode silencieux (sans dialogue) et forcera la recréation d’une entrée dans le fichier « Passphrase_n.txt ». Cette entrée sera constituée du nom du serveur SQL de l'instance courante ainsi que d’une clé générée aléatoirement.

3. À partir de l’utilitaire GricsDB.exe, exportez d’abord la nouvelle clé correspondant au nom du serveur de l'instance courante. Ensuite, il faut importer la clé sur toutes les instances de serveur SQL se connectant par jonction à cette instance. Consultez le chapitre 5 Exportation et importation de clés entre les instances de serveur SQL pour connaître les étapes reliées à cette démarche.

24

Sécurité SQL GRICS Annexe F

Démarche pour changer la phrase secrète d’une instance de serveur SQL

Annexe F – Démarche pour changer la phrase secrète d’une instance de serveur SQL 1. Vous devez mettre l’instance du serveur SQL en mode « Single User ». Pour ce faire, vous devez

arrêter l’instance du serveur SQL et la repartir de la façon suivante :

Dans le menu Outils d’administration de Windows, sélectionnez Services.

Localisez l'instance du serveur SQL à démarrer en mode « Single User ». Le nom du service devrait commencer par « SQL Server (nom de l'instance) ».

À partir du menu contextuel, choisissez Propriétés.

Dans le champ « Paramètre de démarrage », ajoutez les paramètres suivants : -c –m

Cliquez sur le bouton Démarrer.

2. À partir de l’utilitaire GricsDB.exe, déchiffrez les données sensibles de toutes les bases de données en fournissant la phrase secrète de l’instance courante du serveur SQL.

Pour ce faire, choisissez l’action suivante :

25 © GRICS, 2013-2017



Par la suite, suivez l’exemple ci-dessous pour procéder au déchiffrement avec la phrase secrète de l’instance de serveur SQL :

3. Détruisez ou renommez le fichier « Passphrase_1.txt » de l’instance courante du serveur SQL.



Le paramètre « code d’accès » correspond à la connexion SQL ayant les privilèges « SYSADMIN ».



L'utilitaire GricsDB.exe affichera un dialogue pour permettre de saisir la nouvelle phrase secrète et forcera la recréation du fichier « Passphrase_1.txt » avec cette phrase :

26



Il est très important de prendre une copie de sécurité de ce fichier et de la conserver dans un endroit sûr, car les données sensibles d’une base de données ne sont déchiffrables qu’avec la phrase secrète du fichier Passphrase_1.txt. Si le fichier est perdu et que la phrase secrète est oubliée, toutes les données sensibles de l’instance du serveur SQL seront perdues à jamais. Nous recommandons également de conserver toutes les générations du fichier Passphrase_1.txt advenant le cas où il faut restaurer une base de données qui aurait été chiffrée avec une phrase secrète antérieure à la phrase secrète courante.

5. À partir de l’utilitaire GricsDB.exe, chiffrez ensuite les données sensibles de toutes les bases de données en fournissant la nouvelle phrase de l’instance courante du serveur SQL :

6. Vous devez arrêter l’instance du serveur SQL puis la redémarrer, ce qui aura comme effet de la repartir de façon normale.

27 © GRICS, 2013-2017

Sécurité SQL GRICS Annexe G

Historique des phrases secrètes d’une instance de serveur SQL

Annexe G – Historique des phrases secrètes d’une instance de serveur SQL L'utilitaire GricsDB.exe permet de récupérer des phrases secrètes si elles ont été perdues. Elles sont entreposées dans la base de registre sur l’ordinateur utilisé comme serveur SQL. Il est très important de prendre en copie de sécurité la phrase secrète. Cet utilitaire n'est pas un substitut pour les copies de sécurité de phrases secrètes. Si un disque dur fait défaut, par exemple, et que vous n'avez aucune copie de sécurité de votre phrase secrète, il ne sera plus possible de la récupérer.

Marche à suivre :

1. À partir de l’utilitaire GricsDB.exe, sélectionnez l’action suivante :

2. Dans la fenêtre « Historique des phrases secrètes », choisissez la date désirée parmi les dates affichées. La phrase secrète apparaîtra alors dans le champ plus bas. Si vous désirez copier la phrase secrète dans le presse-papier, cliquez sur le bouton Copier.

28

Sécurité SQL GRICS Annexe H

Démarche pour synchroniser vos codes d’utilisateurs à partir des codes…

Annexe H – Démarche pour synchroniser vos codes d’utilisateurs à partir des codes de l’annuaire LDAP 1. Vous devez synchroniser vos codes d'utilisateurs de l’application à partir des codes de l'annuaire LDAP. La

procédure ConversionCodesBD et les fichiers nécessaires à la conversion se trouvent dans le répertoire \UTIL de l'application. Référez-vous au Guide technique de ConversionCodesBD.pdf pour cette étape.

Pour commencer, vous devez alimenter le fichier CVUTIL.DON.

Ce fichier doit être édité avec Bloc-notes (NotePad) afin d’éviter les caractères indésirables.

Une ligne comprend trois éléments : le code d’utilisateur utilisé pour accéder à l’application, une virgule et le code d’authentification utilisé dans LDAP.

Exemple : Michel, [email protected] Marc, [email protected]

Attention! N’oubliez pas de créer le code d’utilisateur de gestion sur votre serveur LDAP et de l’insérer dans le fichier CVUTIL.DON, sinon vous ne pourrez plus accéder à votre application avec ce code. Consultez le tableau des codes d’utilisateurs de gestion à la fin de cette annexe pour utiliser le bon code d’utilisateur de votre application. Le serveur de tâches EXEGRICS utilise également ce code d’utilisateur pour sa connexion à la banque.

2. Exécutez l’application ConversionCodeBD.exe.

a. Choisissez la langue.

29 © GRICS, 2013-2017

Sécurité SQL GRICS Annexe H

Démarche pour synchroniser vos codes d’utilisateurs à partir des codes…

b. Entrez le nom du serveur et de l’instance, s’il y a lieu.

c. Choisissez la banque pour le passage à LDAP.

À partir de maintenant, vous devez accéder à l’application à l’aide de votre code d’authentification LDAP et non plus avec votre code d’utilisateur.

Si le code d’utilisateur de gestion n’existe pas dans l’annuaire, ce code ne fonctionnera pas pour accéder à l’application.

Attention! N’oubliez pas de réinstaller les services associés au serveur de tâches du système, si le mot de passe du code d'utilisateur de gestion se retrouvant à l'annuaire est différent.

Résumé des codes d’utilisateurs de gestion pour les applications :

ACHAT = ACHAT AVANT-GARDE = AG Clé de voûte = CDV DOFIN = DOFIN GÉOBUS = GEOBUS GPI = GPI JADE = JADE La Procure = PROCURE PAIE et GRH = PAIE REGARD = REGARD TFP = TFP

Sécurité SQL GRICS des applications Windows de la GRICS

Soutien : (514) 251-3707, option 2 : SQL administratif option 3 : SQL pédagogique

Site Web : www.grics.ca Courriel : [email protected]

5100, rue Sherbrooke Est Bureau 300, 3e étage

Montréal (Québec) H1V 3R9

sécurité sql grics des applications windows de la grics ......la base de données locale bdl1 de...

Documents