2010-11-27 16 views
5

Il existe certaines tables critiques dont je dois m'assurer qu'elles ne seront jamais supprimées ou modifiées. seule l'action possible est de le lire et le dba peut ajouter plus de lignes. C'est tout.Prévenir la suppression/la mise à jour des tables par superadmin/dba?

Maintenant, pour plus de sécurité, je veux empêcher même le dba de pouvoir supprimer/modifier les enregistrements, donc, fondamentalement, personne ne peut jamais supprimer ou modifier un enregistrement, pas de super administrateur aussi. Ces tables sont essentielles pour le suivi d'activité de certains types d'utilisateurs dont les données doivent être conservées indéfiniment et certaines sont des tables de recherche critiques. Donc, un mélange de valeurs verrouillées par le système et des valeurs suivies par l'utilisateur.

L'idée est si quelqu'un veut détruire les données dont il a besoin pour détruire cette base de données. Y a-t-il un moyen de faire cela?

Répondre

5

Non, impossible, le superutilisateur contrôle toujours la base de données. Vous pouvez REVOIR mettre à jour et supprimer des autorisations, mais un superutilisateur peut toujours lui accorder à nouveau ces autorisations.

+0

Donc, si nous avons une personne malhonnête à l'intérieur avec un accès administrateur alors rien ne peut être fait? Comment contrôlent-ils l'information sur les systèmes gouvernementaux? – Markus

+2

Confiance. Parce que chaque système peut être piraté, en particulier par les superutilisateurs parce qu'ils doivent le faire. Et ne donnez pas à tout le monde l'accès super-utilisateur, il n'est pas nécessaire. Et n'oubliez pas vos sauvegardes, celles-ci peuvent également être piratées si vous ne les stockez pas dans un endroit très sécurisé. La sécurité est très difficile lorsque vous travaillez avec des gens. http://wiki.postgresql.org/wiki/SEPostgreSQL –

0

Pour MySQL, l'approche suivante peut être prise. Une fois que vous avez vos comptes d'application en place, supprimez le compte de superutilisateur (en fait, n'importe quel compte "WITH GRANT OPTION"). Les comptes d'administrateur système doivent uniquement avoir l'autorisation d'arrêter et de démarrer le système, mais pas de lire à partir de votre table sensible.

Ensuite, modifiez votre table afin qu'elle utilise le moteur MEMORY. Cela signifie que l'administrateur de l'application (et non le DBA) devra restaurer le contenu à chaque redémarrage de la base de données. Cela signifie également que l'administrateur de base de données ne peut pas redémarrer la base de données avec l'option "skip-grants" pour accéder aux données - car les données s'évaporeront lors du redémarrage. (Toutefois, l'utilisateur racine du système peut toujours vider la mémoire système et y trouver vos données.)

Une meilleure approche consiste à crypter vos données dans l'application avec une clé connue uniquement par l'administrateur de l'application.

+0

Postgres n'a pas de moteur * MEMORY * –

+0

Et maintenant vous rencontrez les mêmes problèmes, mais à un endroit différent. Et vous ne pouvez pas laisser tomber le super-utilisateur de toute façon, vous n'avez pas les permissions pour le faire: vous avez besoin des autorisations super-utilisateur –

+0

@a_horse_with_no_name: désolé, je n'avais pas remarqué le tag Postgres. J'ai mis à jour la réponse pour dire que c'est spécifique à MySQL. – Martin

2

Vous ne pouvez en aucun cas empêcher un superutilisateur de faire quelque chose. La seule chose que vous pouvez faire est d'empêcher tout utilisateur de ACCIDENTALLY supprimer ou mettre à jour les enregistrements. Cela peut être réalisé en créant une règle à la mise à jour et à la suppression.

CREATE [ OR REPLACE ] RULE name AS ON event 
    TO table [ WHERE condition ] 
    DO [ ALSO | INSTEAD ] { NOTHING | command | (command ; command ...) } 

Voir ceci link pour référence.