J'ai des données très confidentielles dans ma base de données. J'essaie de sécuriser mes données de DBA.
Je suis membre de l'équipe de développement. Nous développons notre logiciel et Delpoy sur un serveur qui a son propre DBA. Nous avons un contrôle limité sur le serveur.
Dans ce scénario, comment puis-je refuser DBA du serveur de rechercher mes données et de les refuser de les modifier.
est-ce possible?
5 Réponses :
chiffrer du côté client, envoyer et stocker et stocker des données cryptées dans la base de données.
Dans une instance SQL Server, Sysadmin peut tout faire et ne peut pas être bloqué.
Certaines pensées ... Pourquoi votre équipe des développeurs est plus fiable que le dBA Single DBA que je suppose s'occupe d'une autre boîte de serveur SQL? Pouvez-vous expliquer plus s'il vous plaît?
Coz j'espère sur le serveur partagé.
Vous pouvez toujours chiffrer toutes les données qui entrent dans la base de données.
Cependant, un DBA aura un contrôle total sur ces données - il peut ne pas être capable de le déchiffrer, mais pourra le lire (sous forme cryptée), la mettre à jour et même la supprimer. Rien que vous puissiez faire à ce sujet.
Vous avez vraiment besoin de repenser les choses - Comment pouvez-vous travailler avec un DBA que vous ne pouvez pas faire confiance? La plupart des endroits auront un accord de service qui interdit à DBAS de faire certaines choses. Vous devez compter sur ce type d'assurance si vous ne pensez pas que vos dabas soient dignes de confiance.
Pour mettre à jour et la suppression, puis-je savoir qui l'a déclenché? Soit moi [mon programme] ou dba
@Koolkabin - Vous pouvez enregistrer ces actions par des déclencheurs sur la table. Mais devinez quoi, un DBA peut remplacer ceux-ci. Si cela se produit sur la base de données, le DBA a le contrôle. Vous ne pouvez rien y faire.
Si triste d'entendre que mon DB peut être complètement modifié par DBA dans l'environnement d'hébergement partagé.
@Koolkabin - DBAS contrôle total des bases de données. Dans l'hébergement partagé et tout autre environnement. C'est leur travail. Assurez-vous que l'accord d'hébergement ne leur permet pas de regarder vos données ou votre désordre avec celui-ci (à part les travaux de maintenance requis).
in Oracle, vous pouvez utiliser l'option Vault de base de données.
Il y a 2 façons
1 Crypter manuel déchiffrer avec un mot de passe (Seule la personne qui connaît le mot de passe peut crypter / déchiffrer)
2 Cryptage automatisé (à l'intérieur du code), décryptage (Le développeur qui a écrit le code peut voir les données)
Ajouter CRC pour vérifier si les données ont été modifiées Conservez la sauvegarde des données sensitives pour restaurer si supprimé ou modifié
Toujours crypté sera la meilleure façon de choisir le cryptage des données de cryptage et le décryptage sur le côté du client, de sorte que les données ne sont pas révélées dans les bases de données, mais que DBA sera à nouveau en mesure de voir et de supprimer / modifier / modifier les données car d'autres utilisateurs ont conseillé.
Vous ne voulez pas l'administrateur de la base de données, à administrer les données? Je suis confus. Cet hébergement partagé ou quelque chose est?
@Kyle Je pense que ce est une question légitime. Les données Base Administrateur possèdent certainement les données base , mais les données elles-mêmes est une quantité différente, ce qui peut par exemple être légalement privilégié. Pour utiliser une analogie du monde réel, le locataire d'un coffre-fort bancaire s'attendrait raisonnablement s'attendre à ce qu'ils tiennent la seule clé de leur boîte - la banque administre la boîte, mais son contenu est le locataire.
En termes généraux si vous ne pouvez pas faire confiance à la DBA, vous êtes bourré (de la même chose que vous devez faire confiance à l'équipe DEV) - cela ne veut pas dire que vous ne pouvez pas faire les choses comme @Oded suggère à Cachez les données de la vue - et cela peut être souhaitable quelles que soient les autres raisons, mais je vous inquiéterais si le DBA était votre première préoccupation.
@Aakashm: L'analogie est mauvaise. En supposant ne pas héberger etc ... la société possède les données, les DBA et les développeurs travaillent pour la société, la société dispose de politiques pour les DBA et les développeurs à suivre. Simple. Je suis d'accord avec Murph en ce qu'ils sont "bourrés" ...
Ouais je suis inquiet sur l'hébergement partagé.
HMM, pour une base de données avec des "données très confidentielles", vous ne devriez pas vraiment utiliser une solution d'hébergement partagée de toute façon.
Je viens de voir cette question était déjà deux ans, oh bien.