IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration SQL Server Discussion :

Cryptage, sécurisation des données


Sujet :

Administration SQL Server

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé
    Développeur informatique
    Inscrit en
    Juin 2004
    Messages
    423
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Juin 2004
    Messages : 423
    Par défaut Cryptage, sécurisation des données
    Bonjour,

    Je viens vers vous pour une demande que je n'ai jamais eu l'occasion de gérer, je ne sais pas du tout comment cela fonctionne.
    J'ai développé une appli couplée avec une base de données SQL SERVER 2014.
    Les données sont sensibles (salaires) et je ne dois pas y avoir accès.

    Quelle méthode me conseilleriez vous ?

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 010
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 010
    Billets dans le blog
    6
    Par défaut
    D'implémenter des utilisateurs dotés de privilèges....

    À me lire : https://blog.developpez.com/sqlpro/p..._et_utilisateu

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre éclairé
    Développeur informatique
    Inscrit en
    Juin 2004
    Messages
    423
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Juin 2004
    Messages : 423
    Par défaut
    Ok merci, mais si je suis cette méthode, cela implique que j'ai les droits admin pour gérer les users, et que donc je pourrai toujours avoir accès aux données, non ?

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 010
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 010
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par devdev Voir le message
    Ok merci, mais si je suis cette méthode, cela implique que j'ai les droits admin pour gérer les users, et que donc je pourrai toujours avoir accès aux données, non ?

    Posons la question à l'envers... Si vous supprimez tout accès aux données... Qui pourra les exploiter ?

    Vous devez comprendre qu'il doit y avoir toujours possibilité de retour arrière sur les privilèges (on ne parle pas de droits dans un SGBDR). Pour donner un privilège il faut préalablement le détenir. Il y a un GRANTOR (celui qui donne) et un GRANTEE (celui qui reçoit). Si vous êtiez en mesure de supprimer le GRANTOR alors le GRANTEE ne pourrait plus exploiter les données !

    Il faut donc toujours un compte ayant tous les pouvoirs.

    Cela dit, laisser les DBA utiliser le compte "sa" par défaut est juste une imbécilité.

    Il faut créer des comptes spécifiques pour les DBA et éventuellement les mettre dans les rôle de BD db_denydatareader et db_denydatawriter afin qu'ils puissent tout faire, sauf lire ou mettre à jour les données des bases sensibles. Et il faut tracer leur activité, au minimum au niveau LOGON/LOGOFF.

    Ajouter du chiffrement ne fera que compliquer les applications en sus de les rendre horriblement contre performantes. Il faut réserver ces données pour des informations ultra sensibles (n° de carte bancaire, n° de secu.. par exemple).

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. Sécurisation des données sur clé USB
    Par kommen dans le forum Sécurité
    Réponses: 2
    Dernier message: 04/11/2011, 08h51
  2. [PHP 5.1] Sécurisation des données saisies
    Par alain78 dans le forum Langage
    Réponses: 3
    Dernier message: 02/04/2011, 11h10
  3. HP simplifie le stockage et la sécurisation des données
    Par Mejdi20 dans le forum Communiqués
    Réponses: 0
    Dernier message: 24/09/2010, 22h47
  4. Sécuriser des données
    Par Mindiell dans le forum Sécurité
    Réponses: 2
    Dernier message: 08/09/2010, 06h43
  5. sécuriser des données avant envoi
    Par Daviloppeur dans le forum Langage
    Réponses: 2
    Dernier message: 04/03/2010, 00h31

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