> Data > 7 étapes pour le cryptage SSL

7 étapes pour le cryptage SSL

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Gary Zaika - Mis en ligne le 21/01/2004

Instaurez le cryptage automatique dans un environnement SQL Server 2000 en cluster

Dans SQL Server 2000, Microsoft a introduit de nouvelles fonctions pour apporter toujours plus à  ses clients en matière de sécurité des données. A cet égard, il existe une fonction peu comprise : le support automatique du trafic de réseau crypté par SSL ( Secure Sockets Layer) entre les clients et le serveur.

Dans SQL Server 2000, Microsoft a introduit de nouvelles fonctions pour apporter toujours plus à  ses clients en matière de sécurité des données. A cet égard, il existe une fonction peu comprise : le support automatique du trafic de réseau crypté par SSL ( Secure Sockets Layer) entre les clients et le serveur. Certes, le cryptage ralentit légèrement la performance parce qu'il demande des actions supplémentaires des deux côtés de la connexion réseau. Mais, pour les utilisateurs soucieux de sécuriser leurs communications en réseau, les avantages du cryptage l'emportent largement sur ce léger ralentissement. Le cryptage est particulièrement utile quand les clients se connectent au SQL Server par Internet et que les données empruntent des réseaux publics.
Le cryptage SSL est devenu un standard : c'est celui que la plupart des entreprises utilisent pour leurs applications Internet et e-commerce. Il existe deux niveaux de cryptage SSL, 40 bits et 128 bits, qui offrent différents types de protection. SQL Server 2000 gère les deux niveaux de cryptage. Pour faire fonctionner le cryptage SSL, vous devez obtenir une clé (ou certificat) valide auprès d'une CA (Certificate Authority) de confiance ou trusted. Après avoir installé le certificat sur un système qui utilise SQL Server 2000, vous pouvez configurer SQL Server pour qu'il impose le cryptage entre les clients et le serveur. Windows 2000 est livré avec son propre CA utilisable pour des applications intranet. La plupart des sociétés utilisent des CA tierce partie pour les applications Internet. (Pour plus d'informations sur les CA, voir l'encadré « Principes de base du CA », ci-après).
Le cryptage SSL est différent du cryptage Multiprotocol Net-Library que l'on trouve dans les releases SQL Server antérieures à  SQL Server 2000. Le cryptage SSL supporte toutes les bibliothèques et protocoles de réseau, y compris les types les plus répandus : TCP/IP et Name Pipes (pour des installations en cluster, seules ces deux bibliothèques de réseau sont disponibles). Vous pouvez aussi utiliser le cryptage SSL pour des instances multiples de SQL Server, alors que le cryptage Multiprotocol Net-Library qui utilise l'API de cryptage Windows RPC, ne reconnaît que l'instance par défaut de SQL Server 2000. Le client ou le serveur (mais pas les deux) peut demander le cryptage SSL. Le cryptage demandé par le client précise que toutes les communications allant de ce client à  tous les serveurs connectés seront cryptées. Le cryptage demandé par le serveur stipule que toutes les connexions entrant dans le serveur seront cryptées puis décryptées sur celui-ci.
Il est plus difficile de configurer le cryptage pour des instructions en cluster que pour un serveur autonome. Beaucoup de sources expliquent comment installer le cryptage SSL sur une seule boîte, mais il est plus difficile de trouver des informations sur l'installation du cryptage SSL dans un environnement en cluster. Malheureusement, SQL Server Books Online (BOL) ne renseigne pas beaucoup sur la manière de configurer le cryptage SSL et ne fait qu'effleurer les exigences de configuration pour un environnement en cluster. Il faut aussi chercher à  l'extérieur de BOL pour obtenir des informations sur la manière d'installer les certificats d'authentification appropriés. Mais, avec des instructions claires, la mise en place du cryptage SSL s'effectue sans mal. Voyons en détail comment installer le cryptage SSL dans un environnement en cluster pour une société fictive appelée IDM.

Pour cet exemple, imaginons que
notre société fictive opère dans un environnement
en cluster classique.
(Quand je parle d’un cluster dans cet
article, il s’agit de deux à  quatre ordinateurs
indépendants fonctionnant
comme un système.) IDM est un fabricant
qui communique avec ses vendeurs
sur le terrain dans le pays en utilisant
le serveur idmsql comme le tiers
données pour ses applications. Les
clients se connectent au serveur sur le
Web en utilisant le protocole SSL pour
échanger des informations dans les
deux sens avec le serveur idmsql. Dans
ce scénario, il est plus pertinent de demander
(et de gérer) le cryptage sur le
serveur.

Pour configurer le clustering dans
un tel environnement, le service
Microsoft Cluster doit être installé sur
chaque machine, ou noeud. Tous les
noeuds doivent fonctionner sur Win2K
Datacenter Server, Win2K Advanced
Server, ou Windows NT 4.0 Enterprise
Edition. Un environnement en cluster
est efficace quand on recherche une
haute disponibilité des données. En
cas de panne, les clusters peuvent réduire
l’immobilisation du système à 
une ou deux minutes. Pour plus d’informations sur la manière de configurer
un cluster de serveurs, voir la
section « Creating a Failover Cluster »
dans SQL Server 2000 BOL.

IDM héberge ses bases de données
SQL Server sur deux machines :
idmdb1 et idmdb2. Toutes deux tournent
sur Win2K AS Service Pack 2 (SP2)
et elles ont la même configuration matérielle.
Elles font partie du domaine
tiga.tld et sont membres du cluster appelé
MyCluster. Le service Cluster est
installé sur les deux machines.
L’instance virtuelle par défaut non
nommée de SQL Server 2000
Enterprise Edition est appelée idmsql
et est installée sur MyCluster. (Un serveur
virtuel est l’option par défaut
quand on installe SQL Server dans un
environnement en cluster.) Le service
MSSQLServer fonctionne sous le
compte tiga\sqlsvc qui fait partie du
groupe d’utilisateurs Administrators
sur chaque noeud. Un CA autonome
appelé TIGA2 est installé dans le domaine
tiga sur le PDC tiga-dc-01.

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Data - Par iTPro.fr - Publié le 24 juin 2010