1. #1
    Membre expérimenté
    Homme Profil pro
    DBA SQL Server
    Inscrit en
    octobre 2012
    Messages
    703
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA SQL Server
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : octobre 2012
    Messages : 703
    Points : 1 519
    Points
    1 519

    Par défaut Questions avant désactivation du compte SA

    Bonjour à tous,

    Je dois pour la première fois, désactiver le compte SA sur toutes nos instances.

    J'ai des réponses ici : https://www.developpez.net/forums/d1...vation-compte/ : mais j'ai besoin de précisions et désolé si je me répète sur la précédente discussion.

    Mais je vais en profiter pour revoir tous les owners et les modifier si nécessaire sur 50 instances (Prod et NonProd)

    Je commence par l'environnement DEV bien sûr.

    Sur 82 DB, il y en a :
    34 avec le compte SA
    18 sans owner, le champ est vide
    25 avec comme owner un compte AD
    5 avec un compte SQL

    Pour les jobs, il y en a 20 :
    3 avec le compte SA
    7 sans owner, le champ est vide
    6 avec comme owner un compte AD
    4 avec un compte SQL

    Pour les jobs, dans le post, Nicolas dit :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Ceci est du au fait que le propriétaire d'un job indique seulement qui peut l'exécuter, Un job peut ne pas avoir de propriétaire, et dans ce cas, seul un utilisateur membre du rôle de serveur sysadmin peut l'exécuter.
    Si je comprends bien donc, si je mets SA comme owner des jobs et que je le désactive ensuite, cela veut dire que seul un membre du rôle de sysadmin pourra exécuter le job manuellement. Mais s'il y a un schedule, ça ça ne change rien, il sera exécuté normalement?
    Et si je mets un compte AD, seul ce compte ou un sysadmin pourra exécuter ce job?


    Pour les DB, Nicolas dit :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    Dans le cas des bases de données non-contenues, le fait que le login sa soit désactivé empêche simplement de se connecter à l'instance sous ce nom de login.
    Cela n'empêche pas un membre du rôle se serveur sysadmin de l'utiliser une fois qu'il est authentifié et qu'il a été établi qu'il est bien membre de ce rôle de serveur.
     
    L'avantage d'utiliser ce nom de login, bien qu'il soit désactivé, est qu'il est présent sur toute instance SQL Server.
    Dès lors, un déplacement de base de données ou une copie de job se fait sans encombre.
    Par ailleurs, si le propriétaire de la base de données est un groupe AD, ou pire, un utilisateur AD, le jour où l'on modifie le groupe ou désactive le compte d'utilisateur AD ... patatra !
    Donc idéalement, je devrais mettre SA comme owner de toutes les DB même si après je le désactive pour éviter le problème avec un groupe ou user AD qu'on désactiverait, cela n'a pas de conséquences?
    Mais alors pourquoi c'est différent si on met un compte ou groupe AD et qu'on le désactive dans l'AD, par rapport à SA qu'on désactive?

    Donc si je résume, si je désactive SA:

    Pour les jobs : Mettre SA comme owner sauf si un compte "extérieur" doit l'exécuter manuellement?
    Et quelle est la conséquence si je ne mets pas d'owner à un job? Que je laisse le champ vide?
    Pour les DB : Mettre SA comme owner n'a pas de conséquences sur les applications qui se connectent à ces DB (mais qui n'utilisent pas le compte SA bien sûr!), et donc pour éviter le problème avec un groupe/compte AD, c'est mieux de mettre SA?
    Et quelle est la conséquence si je ne mets pas d'owner à une DB? Que je laisse le champ vide?

    Si j'ai oublié des problèmes à la désactivation du compte SA, je suis à votre écoute.
    Ce que nous avons fait pour nous-même meurt avec nous, ce que nous avons fait pour les autres et le monde est immortel. Albert Pike

    http://www.datacrossroad.be

  2. #2
    Membre expérimenté

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    653
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2003
    Messages : 653
    Points : 1 431
    Points
    1 431
    Billets dans le blog
    5

    Par défaut

    Bonjour janlouk,

    Avoir 'sa' comme propriétaire d'une base de données est incontestablement une mauvaise pratique en terme de sécurité. Ceci dit, dans la pratique, il n'est pas rare que les bases de données aient comme propriétaire 'sa', ou bien pire encore, l'utilisateur connecté (login autre que 'sa' ) au moment de la création de la base, qui sont généralement aussi à 99.99 % des cas, membre du rôle sysadmin, qu'il s'agisse de compte AD ou autre compte SQL !!!

    En résume, voilà ce que je peux te dire ce sujet, sans donner d'explications détaillées :

    1 - Eviter à tout prix que le propriétaire de la base soit membre du rôle 'sysadmin'. Donc cela exclue 'sa' et autres principaux de niveau Serveur membres du rôle 'sysadmin'

    2 - La situation devient carrément critique en terme de sécurité lorsque la base est marquée "digne de confiance" au niveau de l'instance et que le propriétaire de la dite base est membres du rôle 'sysadmin' !!!

    3 - Une solution consiste à créer un "login" spécial, destiné à être le propriétaire de la base. Ce "login" ne sera doté d'aucune autorisation particulière, sera désactivé (comme pour 'sa'), et même avec un refus explicite de connexion (DENY CONNECT SQL).

    4 - Généralement, les DBA, commencent à s'"intéresser" au propriétaire de la base lorsque, sous SSMS, ils obtiennent des messages erreurs en voulant consulter les propriétés de la base de données, parce que, tout simplement, le propriétaire de la base n'existe plus !
    Attention : le nom du propriétaire peut d'apparence afficher un nom correct, en consultant les vues système, mais "ID du principal" au niveau de la base de données peut être différent et ne pas correspondre à l'identificateur de sécurité du propriétaire externe de la base de données, tel qu'il est enregistré sur le serveur (dans la base 'master'). Cela arrive généralement après restauration de la base depuis un autre Serveur SQL et où le propriétaire de la base portait le même nom sur l'autre serveur, d'où le confusion !

    5 - Autre scénario classique où les DBA, s'"intéressent" au propriétaire de la base, c'est lorsqu'ils mettent en œuvre les fonctionnalités du Service Broker et obtiennent une batterie d'erreurs lorsque le propriétaire de la base est incorrect.

    A+
    "Une idée mal écrite est une idée fausse !"
    http://hamid-mira.blogspot.com

Discussions similaires

  1. Question avant execution d'une requete
    Par viny123456789 dans le forum Requêtes et SQL.
    Réponses: 13
    Dernier message: 10/07/2007, 12h01
  2. Questions avant de me lancer tête baissée
    Par ustilago dans le forum Access
    Réponses: 3
    Dernier message: 11/08/2006, 17h16
  3. questions avant projet + crypter un fichier ?
    Par Lorenzo77 dans le forum Delphi
    Réponses: 2
    Dernier message: 01/07/2006, 13h45
  4. [LDAP] AD : désactiver un compte
    Par pogy dans le forum Bibliothèques et frameworks
    Réponses: 2
    Dernier message: 03/05/2006, 16h50
  5. Dernière question avant installation
    Par Iceman6259 dans le forum Mandriva / Mageia
    Réponses: 8
    Dernier message: 25/05/2005, 18h57

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo