Discussion :

[nuke_y]

Bonjour, j'ai une question qui a sûrement du être déjà posée (mais je n'ai rien trouvé).

De nos jours de plus en plus de logiciels/applications se basent sur une BDD (serveur 3 tiers par exemple). Ceci implique que si on a accès à la BDD on a accès au coeur (et à la mémoire) de l'application.

Certes les serveurs sont suffisements bien protégés pour ne pas avoir peur des pirates, mais qu'en est-il des attaques en interne ?

Mon problème s'illustre dans le domaine des Ressources Humaines : une application s'appuie sur une BDD Oracle 9i. Les informations rentrées dans cette application vont du nom et prénom de chaque employé à son salaire en passant par les appréciations de son chef de service pour sa promotion.

Les utilisateurs de l'application sont à Marseille.
Les responsables de l'application sont à Marseille.
Les consultants qui travaillent sur l'application sont à Marseille.
Les DBA et la BDD sont à Paris.

Pour des raisons de performances, la BDD se trouve à Paris dans un grand centre (de l'entreprise) rassemblant les BDD et les DBA de toute la France. Malheureusement, alors que nous ne voulions que profiter de la performance de leurs serveurs, il a été décidé que cette BDD leur appartenait et que nous ne devions plus faire de modification dessus. Pour toute modification, nous devons maintenant ouvrir des tickets à l'équipe de DBA à Paris pour qu'ils appliquent les scripts de modification que nous leur envoyons.

Jusqu'ici c'est lourd pour nous les consultants mais au moins on a des serveurs de BDD efficaces.

Maintenant arrive la difficulté : ces données, stockées dans la BDD de Paris, sont ESTIMEES tellement confidentielles que le département RH ne souhaite plus que n'importe qui puisse y accéder. Ils souhaitent que seuls les utilisateurs de l'application puissent y accéder en lecture via l'application et les Responsables et consultants en lecture/écriture.

Cependant il est envisageable que les DBA gardent la main sur la structure.

Donc ma question :

1) Est-il envisageable de donner :
des droits de lecture seule à un user
ET des droits de manipulation des données (select/delete/insert/update) à un autre user mais AUCUN droit de manipulation de structure
ET des droits de manipulation de structure à un user mais AUCUN droit de manipulation/consultation de données ?

2) Est-il envisageable de crypter les données avec une clé que les Responsables et les consultants seraient les seuls à posséder ? Il faudrait bien entendu que le fait de se connecter avec certains users autorisés permette d'accéder aux données cryptées de manière transparente.

3) Sinon nous conseillez-vous de faire redescendre la BDD à Marseille, sachant qu'il va falloir s'équiper d'un serveur, avoir du personnel, etc ?

4) Une autre idée ?

Merci de vos avis éclairés sur un sujet délicat

[LeoAnderson]

La problématique de sécurisation de données est complexe, vaste et malheureusement, sans solution miracle universelle et simple.

Cependant, il y a plusieurs pistes intérêssantes :

• Les Virtuals Private Database (VPD) : http://download-east.oracle.com/docs...htm#DBSEG13000
  Il s'agit ici de cloisonner logiquement les données
• Le cryptage des données : http://download-east.oracle.com/docs....htm#sthref151
• Après, via CMan, vous pouvez également restreindre les clients en fonction des adresses IP
• Pour les plus exigeants, une cryptage des communications SQL*Net également possible

Voilà, j'en oublie sûrement, mais déjà, ça complexifie les moyens d'accéder à des données non autorisées (mais également l'admin)...

Par contre, je pense que l'emplacement physique de la machine importe peu...

[edit]
Après relecture, vous voulez bien que les DBAs fassent leur boulot mais ne puisse en aucune façon accéder aux données ?
Tant que les données ne sont pas cryptées, il n'y a pas de solutions, un DBA pouvant par définition tout lire et tout modifier (et encore heureux ! C'est comme si root ne pouvait pas avoir accès à /home/ ....)

Voilà pour l'aspect "technique".
Après, pour l'aspect "déontologique", si les DBAs sont de la même entreprise , qu'ils ont de l'ancienneté et tout et tout, que les contrats de travail sont blindés, c'est vraiment se chercher des complications pour le plaisir pour de "simples" données RH...
[/edit]

[orafrance]

en effet, le DBA a part définition l'accés complet à la base de données. Le mieux que vous puissiez faire c'est utilisé un programme tiers qui va crypter les données en base et les décrypter uniquement dans l'application qui elle n'est pas accessible par les DBA mais ça risque d'être assez complexe.

Pour les bases autre que la prod, le plus simple c'est de masquer les données en mettant des valeurs bidons ou en changeant les noms par exemple.

[nuke_y]

Mouaih... ça m'arrange pas ça...

Bon je vais regarder le cryptage, mais en effet le problème se résume bien comme ça : comment empêcher le DBA de voir ses données ?

Ben ouaih ça fait rigoler tout le monde à qui j'en parle mais la liste des plus gros salaires a été balancée en broadcast, alors ça ne fait rigoler personne dans l'entreprise...

[orafrance]

Si je ne m'abuse il y a une clause de confidentialité dans le contrat... c'est plutôt là qu'il faudrait agir... si un DBA divulgue des données sensibles il n'a plus rien à faire dans l'entreprise. On est professionnel ou pas

[nuke_y]

Oui mais le problème c'est QUI a divulgué ces données ?

Comme je l'ai dit, il y a un groupe de 5/10 DBA à Paris, qui tournent entre eux comme ils veulent. C'est un pool de DBA qui se répartissent le travail entre eux. Et c'est ce manque de transparence qui permet à n'importe qui à Paris d'avoir accés aux données.

C'est sur que si les login/mdp n'étaient connus que par les responsables, le consultant et UN SEUL DBA, il n'y aurait pas (trop) de problème.

[Jaouad]

Bonjour ,
Attention de ne pas taper trop vite sur les DBA jusqu'a ce que la ou les personnes puissent être identifié précisément. Il arrive souvent que lorqu'il y a une fuite des données on pense de suite au DBA, alors que cecla vient génèralement d'ailleurs .

Cependant soit les DBA sont sensibilisé sur les risques qu'il encourt et alors dans ce cas je pense qu'il seront plus discret.

Car un DBA peut, s'il le souhaite et s'en donne les moyens consulter n'importe qu'elle donnée crypter ou pas ...

[orafrance]

Désolé mais pour moi ce n'est pas un problème technique mais un problème politique.

On va pas enlevé les armes de tous les policiers parce qu'une bavure a été commise et qu'on ne sait pas qui c'est... bah là c'est pareil. Faut les convoquer et les faire bien flipper pour éviter que ça ne se reproduise.

[nuke_y]

Ben ouaih je suis bien d'accord, c'est un problème politique. C'est pour ça que je cherche des moyens techniques pour empêcher qu'un système qui ne fonctionne pas trop mal ne soit entièrement foutu en l'air pour des raisons politiques.

Quand au problème des DBA coupables ou pas, je ne pense sincérement pas que ce soit eux les responsables, mais comme ils sont à Paris (donc loin) et qu'il y a assez peu de transparence sur leur équipe, ils sont des boucs émissaires pratiques...

Enfin bref, c'est moche...

[Jaouad]

Ben ouaih je suis bien d'accord, c'est un problème politique. C'est pour ça que je cherche des moyens techniques pour empêcher qu'un système qui ne fonctionne pas trop mal ne soit entièrement foutu en l'air pour des raisons politiques.

Nuke si un DBA veut à tout prix lire les données , il le fera

[orafrance]

Sauf si le cryptage/décryptage est laissé au soin de l'appli

[Jaouad]

Sauf si le cryptage/décryptage est laissé au soin de l'appli

et tu penses qu'il ne peux pas tracer les clients

[nuke_y]

Sauf si le cryptage/décryptage est laissé au soin de l'appli

Ce qui est impossible (ou presque) car l'application de restitution c'est BO...

Ben je suis bien d'accord que si un DBA veut lire les données il le peut, mais justement ça m'arrange pas, parce que dans ce cas ça va dans le sens où il vaut mieux lui retirer les données et les mettre dans un serveur hebergé et administrer par les responsables des données, et ça serait FRANCHEMENT n'importe quoi...

L'idéal serait sûrement de réduire le pool de gens qui ont accés à ces données. Genre qu'il n'y ait que 2 DBA a avoir le droit d'accéder à cette base...

[LeoAnderson]

Il n'y guère que la solution du cryptage ET de l'audit sur la tables des salaires ET l'audit de l'audit -au cas où un DBA le désactiverait avant de lire....

[bouyao]

Dans Oracle 9i ce n'est pas possible.
Dans Oracle 10g c'est possible.
Une autre solution que beaucoup d'entreprise l'utilise est d'externaliser la base.(c.a.d une societé externe qui s'occupera de la base).

[nuke_y]

Dans Oracle 9i ce n'est pas possible.

Crotte

Dans Oracle 10g c'est possible.

ah ? Et comment ?

Une autre solution que beaucoup d'entreprise l'utilise est d'externaliser la base.(c.a.d une societé externe qui s'occupera de la base).

Ben tu vas rire mais c'est justement ce qu'on voudrait éviter en fait... Mais effectivement c'est la solution la plus réaliste pour une sécurité accrue.

Il n'y guère que la solution du cryptage ET de l'audit sur la tables des salaires ET l'audit de l'audit -au cas où un DBA le désactiverait avant de lire....

Je vais faire des recherches, mais qu'est-ce que tu entends par "audit" ?

[LeoAnderson]

Audit : http://download-east.oracle.com/docs...htm#sthref2916

C'est un mécanisme de surveillance précis (mais donc consommateur) assez fin de qui fait quoi et qui regarde quoi (et quand).

[nuke_y]

Ok merci, je vais me baser là dessus pour rendre un rapport préliminaire... Mais j'adooOOOOoore parler de trucs que je ne connais pas du tout....

[neguib]

Ok merci, je vais me baser là dessus pour rendre un rapport préliminaire... Mais j'adooOOOOoore parler de trucs que je ne connais pas du tout....

n'oublies pas le bouton en bas à gauche stp

[bouyao]

Protection from the DBA?
Do you need to protect the encrypted data from your own DBA? It's a question that is bound to come up while designing the system, so you will have to address it one way or the other.

A key is stored either in the database or the filesystem. If the key store is the database, thenbecause the DBA is authorized to select from any table (including the table where the keys are stored)he can therefore decrypt any encrypted data. If the key store is the filesystem, it has to be available to the Oracle software owner so that it may be read using UTL_FILE, which the DBA may have access to. Thus, either way, protecting encrypted data from the DBA is probably a fruitless exercise. Is that an acceptable risk in your organization? The answer depends upon your organization's security policies and guidelines. In many cases, the risk is managed by placing trust in the DBA, so this may be a moot point. But in other cases, the encrypted data must be protected even from the DBA.

The only solution in that case is to store the keys on a location that the DBA will not be able to accesssuch as on the application server. But doing so makes key management difficult. You will have to ensure that the keys are backed up and protected from theft.

You can use a more complex system for key management using the master key approach described above. The master key may be placed in a digital wallet, and the application server can request the key every time it needs to encrypt and decrypt the data. Although this makes the key inaccessible to the DBA, it also makes the system complex and increases processing time.

If your objective is to prevent the DBA from altering the key, yet you want her to still be able to see it, you can use the same master-key approach. The master key can be placed in a filesystem that is read-only but accessible to the Oracle software owner to read it. This enables the database (and the DBA) to use it in encryption, but the DBA will not be able to alter it.

To keep your system manageable, especially if you want to make sure that your applications are minimally affected, then you will have to make the keys available to the Oracle software owner, either in a filesystem or inside the database in a table. In that case, it will be impossible to hide them from a DBA.

sous oracle9i tu peut crypter les données en utilisant le package DBMS_OBFUSCATION_TOOLKIT et en 10g le package DBMS_CRYPTO