Meilleures pratiques de sécurité SQL Server pour une application installée sur SQL Server – Serveur d’impression

Par: Svetlana Golovko | Mis à jour: 2019-12-18 | Commentaires | En relation: Plus> Installer et désinstaller

Problème

Nous connaissons tous la meilleure pratique de configuration de SQL Server sur un hôte dédié,
idéalement, SQL Server ne devrait pas partager le serveur avec d'autres applications. Mais
dans la vraie vie, il y a parfois des scénarios où une application doit être installée
avec SQL Server sur la même machine. Ces scénarios incluent généralement des applications isolées
configuration qui nécessite une sécurité stricte ou doit être séparée du reste de
l'environnement. Cela pourrait également s'appliquer aux applications qui doivent
avoir SQL Server Express installé sur le même serveur.

Comment verrouiller SQL Server? Comment pouvons-nous nous assurer que notre serveur est sécurisé et
protégé contre les accès externes?

Solution

Dans cette astuce, nous fournirons des recommandations pour renforcer l'installation de SQL Server
pour la configuration où SQL Server n'est accessible que par l'application installée
sur le même serveur. Dans la plupart des cas, il s'agit d'un serveur autonome qui n'est même pas joint à un domaine. Nous fournirons des exemples et des scripts pour la configuration des autorisations minimales requises
pour les sauvegardes et la maintenance des bases de données.

Étapes de pré-installation

Par défaut, si vous ne créez pas le dossier pour SQL Server à l'avance, le
Les dossiers de données auront certaines des autorisations héritées du dossier parent.
Le groupe local "Utilisateurs" (COMPUTERNAME Users) aura des autorisations de lecture
aux dossiers:

Avant de commencer l'installation, nous créerons des données, des sauvegardes et d'autres dossiers
et assurez-vous que seuls les administrateurs ont accès à ces dossiers.

Nous allons d'abord créer les nouveaux dossiers et désactiver l'héritage des autorisations:

Convertir les autorisations en autorisations explicites lorsque vous y êtes invité et supprimer le local
"Utilisateurs"
Autorisations du groupe ("Lire et exécuter" et "Spécial"):

Les comptes de service SQL Server recevront les autorisations requises lors de l'installation
plus tard, nous n'avons donc pas besoin de le faire maintenant.

Les autorisations du système de fichiers requises pour les comptes de service SQL ont été trouvées

ici.

Installation de SQL Server

Démarrez l'installation de SQL Server comme vous le faites habituellement. Suivez les invites d'installation jusqu'à
Écran "Sélection des fonctionnalités".

Sur l'écran de sélection des fonctionnalités, assurez-vous que seuls les «services du moteur de base de données»
est sélectionné:

Ne sélectionnez pas les fonctionnalités habituelles que vous installez habituellement, telles que: Outils SQL Server,
Recherche plein texte, etc.

Remarque: que le texte intégral peut être requis pour votre
ou reportez-vous à la documentation de votre fournisseur pour connaître les exigences relatives aux fonctionnalités de SQL Server.

En outre, nous supposons qu'il s'agit d'une application simple qui ne nécessite qu'une base de données
fonction moteur (pas de SSRS, SSAS, etc.).

Nous voulons réduire la surface de sécurité, donc l'Agent SQL Server et le Navigateur SQL Server
sera également désactivé. Toutes les tâches de maintenance et de sauvegarde planifiées s'exécuteront sous Windows
Tâches planifiées qui seront configurées ultérieurement:

Gardez les comptes de service par défaut. Lis

cette Article de Microsoft sur les comptes de service et les autorisations nécessaires
pour les comptes.

Si l'application prend en charge l'authentification Windows – conservez l'authentification par défaut
Mode (Windows).

Utilisez le répertoire (ou les répertoires si vous utilisez plusieurs lecteurs) que nous avons créé
avant de commencer l'installation:

Terminez l'installation.

Lis

cette astuce pour le Guide d'installation pas à pas complet de SQL Server 2017.

Configuration de la sécurité de SQL Server

Nous allons configurer ici certaines des fonctionnalités de sécurité.

Désactivez tous les protocoles réseau à l'exception de la "mémoire partagée":

Validez dans SQL Server Configuration Manager que tous les services sauf "SQL"
Serveur "sont désactivés:

Masquez l'instance à l'aide de SQL Server Configuration Manager. Lis

cette astuce sur le masquage des instances SQL Server.

Assurez-vous que l'accès à distance est désactivé:

UTILISATION [master]
ALLER
EXEC sys.sp_configure N'remote access ', N'0'
ALLER
RECONFIGURER AVEC OVERRIDE
ALLER

Activez les stratégies de mot de passe locales si vous configurez SQL Server sur un serveur autonome
serveur. Les serveurs joints au domaine doivent hériter des stratégies de domaine, vous pouvez donc ignorer
cette étape pour les serveurs qui font partie du domaine Active Directory. Le mot de passe
les stratégies pour le domaine sont généralement configurées par vos administrateurs système.

Sur un serveur autonome:

Démarrer la console MMC

Cliquez sur "Fichier"> "Ajouter / Supprimer un composant logiciel enfichable…"

Sélectionnez "Éditeur d'objets de stratégie de groupe", cliquez sur "Ajouter", confirmez
la sélection d'objet de stratégie de groupe "Ordinateur local":

Cliquez sur OK"

Sous "Stratégie de l'ordinateur local", développez "Configuration de l'ordinateur",
puis "Paramètres Windows", puis "Paramètres de sécurité", "Compte
Politiques "," Politique de mot de passe "

Modifiez les politiques à droite pour appliquer des mots de passe forts:

En savoir plus sur la configuration des stratégies de mot de passe locales sous Windows

ici. Lis

cette article sur les stratégies de mot de passe SQL Server.

Laissez la console MMC ouverte pour les étapes suivantes.

Autres étapes de post-installation

Installez les derniers correctifs et correctifs (y compris les correctifs Windows).

Définissez un mot de passe fort, renommez et désactivez la connexion "sa".

Cette astuce possède une liste de contrôle de sécurité pour SQL Server. Assurez-vous d'avoir examiné le
liste de contrôle et

cette guide de sécurité pour toutes les configurations de sécurité supplémentaires qui pourraient être
obligatoire.

Création de compte de service de maintenance

Nous allons créer un compte de service local pour exécuter la maintenance SQL Server planifiée
Tâches (mise à jour des statistiques, sauvegarde des bases de données, etc.). Nous allons utiliser l'ordinateur
Outil de gestion sur notre serveur SQL pour cela:

Ce compte de service exécutera les tâches planifiées de Windows. L'utilisateur n'a pas besoin
être membre de tout groupe, mais il doit avoir

"Se connecter en tant que tâche par lots" autorisations locales afin d'exécuter des travaux Windows.

Revenez à la console MMC pour attribuer la stratégie «Se connecter en tant que tâche par lots»
sur le compte de service:

Cliquez sur le bouton "Ajouter un utilisateur ou un groupe…" et ajoutez "SQLTaskTest"
utilisateur que nous avons créé précédemment:

Autorisations de compte du service de maintenance sur SQL Server et les bases de données

Ce sont les autorisations minimales requises pour le compte de service pour exécuter le
sauvegarde des bases de données et tâches de maintenance:

UTILISATION [master]
ALLER
CRÉER UNE CONNEXION [LOCALSRVNAMESQLTaskTest] DE WINDOWS DEFAULT_DATABASE =[master], CHECK_EXPIRATION = OFF, CHECK_POLICY = ON
ALLER
UTILISATION [_Demo] - pour chaque base de données sauf tempdb
ALLER
CRÉER UN UTILISATEUR [LOCALSRVNAMESQLTaskTest] POUR LA CONNEXION [LOCALSRVNAMESQLTaskTest]
ALLER
ALTER ROLE db_backupoperator AJOUTER UN MEMBRE [LOCALSRVNAMESQLTaskTest]  –- pour créer des sauvegardes
ALLER
DONNER ALTER N'IMPORTE QUEL SCHÉMA À [LOCALSRVNAMESQLTaskTest] –- pour reconstruire des index
ALLER
GRANT IMPERSONATE SUR L'UTILISATEUR :: dbo TO [LOCALSRVNAMESQLTaskTest] –- pour mettre à jour les statistiques
ALLER

La justification de ces autorisations est fournie ci-dessous pour chaque script / tâche.

Scripts de maintenance SQL Server

Nous devrons exécuter les tâches suivantes:

• Sauvegardes de bases de données
• Maintenance des index
• Mises à jour des statistiques
• Contrôles de cohérence des bases de données

Voici les scripts SQL Server et le script du système d'exploitation exécutable (fichier * .bat) qui s'exécuteront
ces scripts SQL:

Script de sauvegarde de toutes les bases de données SQL Server

"BackupAllDBs.sql"script (remplacez le nom du dossier de sauvegarde par votre
dans ce script):

ACTIVER LE NOCOUNT
SELECT GETDATE ()
EXEC sys.sp_MSforeachdb 
'IF (SELECT' '?' ') <>' 'Tempdb' '
COMMENCER
BASE DE DONNÉES DE SAUVEGARDE [?] 
TO DISK = N''D:  Backups  ?. BAK '' 
AVEC NOFORMAT, INIT, NAME = N ''? - SAUVEGARDE COMPLÈTE DE LA BASE DE DONNÉES ''
FIN' 

Ici est une référence aux autorisations requises pour sauvegarder les bases de données:

Nous accorderons les autorisations minimales requises pour créer les sauvegardes de notre service
compte (requis pour chaque base de données qui sera sauvegardée):

ALTER ROLE db_backupoperator AJOUTER UN MEMBRE [LOCALSRVNAMESQLTaskTest] –- pour créer des sauvegardes
ALLER 

Script de maintenance d'index SQL Server

"IndexesMaintenance.sql"script:

J'ai utilisé le script de reconstruction d'index à partir de
cette astuce. Il reconstruit tous les index sur toutes les bases de données (ou les bases de données spécifiées dans
le script). Vous pouvez également créer un script plus sélectif qui ne reconstruit que
index fragmentés, mais nous utiliserons ce script pour la démonstration
de la configuration des autorisations minimales.

Ici est une référence aux autorisations requises pour reconstruire ou réorganiser le
index:

Nous pourrions éventuellement accorder à notre compte de service le rôle "db_ddladmin",
mais cela signifie que notre utilisateur pourra créer et supprimer les tables. Nous allons
accordez au lieu de cela les autorisations suivantes:

DONNER ALTER N'IMPORTE QUEL SCHÉMA À [LOCALSRVNAMESQLTaskTest] –- pour reconstruire des index
ALLER

Nous pouvons tester si l'utilisateur peut créer ou supprimer des tables ou d'autres objets. Nous allons
créer quelques objets de test (en tant que compte sysadmin ou db_owner):

UTILISATION [_Demo]
ALLER
CRÉER LA TABLE dbo.Can_you_drop_table (
col1 INT NOT NULL,
CONTRAINTE PK_Can_you_drop_table CLÉ PRIMAIRE CLUSTERED 
(col1 ASC)
ALLER
CREATE PROC dbo.Can_you_drop_procedure
COMME
SELECT col1 FROM dbo.Can_you_drop_table
ALLER

Maintenant, nous allons nous connecter avec le compte de service et exécuter le script suivant:

UTILISATION [_Demo]
ALLER 
IMPRIMER 'Créer la table'
CREATE TABLE test_perm_tbl (c1 INT)
ALLER
IMPRIMER 'Déposer la table'
DROP TABLE dbo.Can_you_drop_table  
ALLER
IMPRIMER 'Abandonner la procédure'
DROP PROC dbo.Can_you_drop_procedure
ALLER
IMPRIMER «Modification de la table»
ALTER TABLE dbo.Can_you_drop_table ADD col2 INT
ALLER
IMPRIMER «Reconstruire les index»
ALTER INDEX ALL ON dbo.Can_you_drop_table REBUILD
ALLER

Voici les résultats (avec commentaires):

Création de la table
Msg 262, niveau 14, état 1, ligne 2
Autorisation CREATE TABLE refusée dans la base de données '_Demo'. - Impossible de créer la table
Suppression de la table - PEUT supprimer la table
Abandon de la procédure
Msg 3701, niveau 11, état 5, ligne 10
Impossible de supprimer la procédure 'dbo.Can_you_drop_procedure', car elle n'existe pas ou vous ne disposez pas de l'autorisation. - NE PEUT PAS supprimer la procédure
Modification de la table - PEUT changer la table
Reconstruction des index - PEUT reconstruire les index 

Ainsi, même si l'utilisateur peut modifier et supprimer les tables, il ne peut pas supprimer
d'autres objets ou créez-en de nouveaux.

Script de statistiques de mise à jour de SQL Server

""UpdateStatistics.sql"script:

ACTIVER LE NOCOUNT
SELECT GETDATE ()
EXÉCUTER COMME UTILISATEUR = 'dbo'
Exec dbo.sp_updatestats
REVENIR

Ici est une référence à l'article décrivant les autorisations requises pour la mise à jour
statistiques des bases de données:

Au lieu d'accorder les autorisations sysadmin au compte de service, nous utiliserons l'emprunt d'identité
pour notre compte de service. Il usurpera l'identité de l'utilisateur "dbo". Pour que le
compte de service à exécuter "EXÉCUTER
COMME"déclaration, nous devons lui accorder les autorisations suivantes:

UTILISATION [_Demo]
ALLER
GRANT IMPERSONATE SUR L'UTILISATEUR :: dbo TO [LOCALSRVNAMESQLTaskTest]  –- pour mettre à jour les statistiques
ALLER

Vérifications de cohérence de la base de données SQL Server

""CheckDBs.sql":

ACTIVER LE NOCOUNT
SELECT GETDATE ()
EXEC dbo.usp_CheckDB

Nous avons créé une procédure stockée pour vérifier la base de données dans notre base de données de démonstration
pour notre démonstration des tâches de maintenance:

UTILISATION [_Demo]
ALLER
CREATE PROC dbo.usp_CheckDB
COMME
EXÉCUTER COMME UTILISATEUR = 'dbo'
ALTER ROLE [db_owner] AJOUTER UN MEMBRE [LOCALSRVNAMESQLTaskTest]
REVENIR
DBCC CHECKDB AVEC NO_INFOMSGS
EXÉCUTER COMME UTILISATEUR = 'dbo'
ALTER ROLE [db_owner] DROP MEMBER [LOCALSRVNAMESQLTaskTest]
REVENIR
ALLER

Nous allons maintenant accorder au compte de service l'autorisation d'exécuter la procédure stockée:

UTILISATION [_Demo]
ALLER 
GRANT EXECUTE ON dbo.usp_CheckDB TO [LOCALSRVNAMESQLTaskTest]
ALLER

Ici est une référence à l'article décrivant les autorisations requises pour exécuter DBCC
CHECKDB:

La vérification de la cohérence de la base de données ne peut être exécutée que par un utilisateur membre de db_owner
rôle de base de données. L'utilisateur doit être explicitement ajouté au rôle. L'usurpation d'identité de l'utilisateur dbo
ne fonctionne pas dans ce cas:

EXÉCUTER COMME UTILISATEUR = 'dbo'
DBCC CHECKDB AVEC NO_INFOMSGS 
REVENIR

Si l'utilisateur n'est pas membre du rôle db_owner, il y aura une erreur:

Msg 916, niveau 14, état 1, ligne 15
Le serveur principal "sa" n'est pas en mesure d'accéder à la base de données "_Demo" dans le contexte de sécurité actuel.

Ainsi, dans notre procédure stockée usp_CheckDB, nous avons les étapes suivantes:

• Emprunter l'identité de l'utilisateur en tant que dbo
• Accorder le rôle de compte de service de maintenance "db_owner"
• Exécutez DBCC CHECKDB
• Supprimez le compte de service de maintenance du rôle "db_owner"

Cela se fait via la procédure stockée pour vous assurer que le compte de service
n'a pas les autorisations db_owner ou sysadmin de façon permanente.

Veuillez noter que les scripts que nous utilisons dans cette astuce sont très basiques et sont fournis
pour démonstration seulement.

La configuration de la sécurité dans cette astuce peut sembler lourde, mais cela est fait pour démontrer
configuration des autorisations minimales pour le compte de service.

Autorisations de compte de service de maintenance sur les dossiers

Nous aurons tous les scripts de maintenance et de sauvegarde sous le nouveau dossier (par exemple,
D: DBScripts) et les fichiers journaux (sortie) sous le sous-dossier "sortie".

L'exigence de sécurité consiste à s'assurer que le compte de service a une capacité
pour écrire dans le dossier "sortie" et pour vous assurer qu'il ne peut pas modifier ou
écrire dans le dossier scripts (accès en lecture seule au dossier "DBScripts").

Le dossier des sauvegardes devra également être sécurisé. Lis

cette astuce sur la protection du dossier de sauvegarde SQL Server.

Dossier DBScripts

Accédez aux propriétés du dossier "DBScripts"

Cliquez sur l'onglet "Sécurité"

Cliquez sur "Avancé"

Désactiver l'héritage des autorisations

Supprimez tous les utilisateurs à l'exception des administrateurs, SYSTEM, CREATOR OWNER (assurez-vous
avoir accès au dossier, nous supposons que nous sommes membres des administrateurs locaux
groupe lorsque nous apportons ces modifications)

Ajouter un compte de service «SQL Task Test», accorder «Lire et exécuter»
autorisations:

Cochez «Remplacer toutes les autorisations d'objet enfant…» et cliquez sur «OK».

Dossier de sortie

Accédez aux propriétés du dossier "sortie"

Cliquez sur l'onglet "Sécurité"

Cliquez sur "Avancé"

Désactiver l'héritage des autorisations

Supprimez tous les utilisateurs à l'exception des administrateurs, SYSTEM, CREATOR OWNER (assurez-vous
avoir accès au dossier, nous supposons que nous sommes membres des administrateurs locaux
groupe lorsque nous apportons ces modifications)

Ajoutez le compte de service "SQL Task Test", accordez les autorisations "Write":

Cochez «Remplacer toutes les autorisations d'objet enfant…» et cliquez sur «OK».

Configuration et test des tâches de maintenance

Les scripts de maintenance et de sauvegarde seront exécutés en exécutant un seul programme planifié.
tâche. La tâche exécutera le fichier de commandes "Run_DBBackups.bat" (remplacer
les noms de serveur avec vos valeurs dans ce script):

CD / D D:  DBScripts 
SQLCMD -E -S DEMOSQL1 -d master -i BackupAllDBs.sql -o D:  DBScripts  output  out_back.txt
SQLCMD -E -S DEMOSQL1 -d _Demo -i CheckDBs.sql -o D:  DBScripts  output  out_checkDB.txt
SQLCMD -E -S DEMOSQL1 -d _Demo -i IndexesMaintenance.sql -o D:  DBScripts  output  out_ind.txt
SQLCMD -E -S DEMOSQL1 -d _Demo -i UpdateStatistics.sql -o D:  DBScripts  output  out_stats.txt

Exécutez le Planificateur de tâches Windows et cliquez sur «Créer une tâche…» sous «Tâche
Bibliothèque du planificateur ":

Sélectionnez le compte de service créé précédemment en tant qu'utilisateur qui exécutera le
tâche, sélectionnez les 2 autres options sur une capture d'écran:

Sous l'onglet "Déclencheurs", configurez un calendrier pour la tâche de maintenance:

Cliquez sur l'onglet "Actions" et entrez l'emplacement et le nom du script
(fichier * .bat):

Voici la vue finale de l'action:

Cliquez sur "OK" pour enregistrer la tâche et entrez le compte du service
mot de passe lorsque vous y êtes invité:

Cliquez sur "OK" dans la prochaine fenêtre pop-up:

Nous pouvons ignorer ce message car nous avons déjà accordé notre compte de service requis
autorisations.

Démarrez le travail manuellement pour vérifier qu'il s'exécute correctement. Vérifiez le dossier de sortie
pour valider les résultats:

Prochaines étapes

Dernière mise à jour: 2019-12-18

A propos de l'auteur

Svetlana Golovko est une DBA avec 13 ans d'expérience en informatique (y compris SQL Server et Oracle) avec un accent principal sur les performances.

Voir tous mes conseils