[9i] Crypter les données mais pas la structure

Apparemment DBMS_OBFUSCATION_TOOLKIT ne peut pas être tracer, donc on peut crypter les données avec sans craindre qu'un DBA détecte la clé de chiffrement dans les traces :)

Bon ok, on a bien fait le tour je crois. Merci beaucoup, je pense que je vais utiliser la solution suivante :
- Seulement 2 DBA de Paris possèdent les codes de la base.
- les données "sensibles" vont être cryptées simplement (genre transformation des number en varchar2 et puis un décalage ASCII). Le problème va être d'arriver à décoder dans la restitution et pas dans la requête... On verra.

Merci en tous cas.

avec une fonction wrappée ça devrait le faire

Ah ouaih pas bête du tout ça... Une fonction wrappée et un appel de la fonction pour chaque champ. Et en plus je peux faire des index dessus...

Bon alors j'avais dit que je reviendrais dessus alors je le fais. Voila un proof of concept de la possibilité de crypter les données.

La fonction de cryptage :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

CREATE OR REPLACE FUNCTION F_Encrypt_Number_To_Varchar2_2 ( PN$NumberToEncrypt IN NUMBER ) Return VARCHAR2 IS LN$DataInVarchar2 VARCHAR2(50); LN$CharacterCountInData NUMBER(3); LN$CharacterMeter NUMBER(3); LN$EncryptedDataInVarchar2 VARCHAR2(50); BEGIN LN$DataInVarchar2 := TO_CHAR(PN$NumberToEncrypt); LN$CharacterCountInData := LENGTH(LN$DataInVarchar2);   LN$CharacterMeter := 1; LN$EncryptedDataInVarchar2 := '';   While LN$CharacterMeter <= LN$CharacterCountInData Loop LN$EncryptedDataInVarchar2 := CHR(ASCII(SUBSTR(LN$DataInVarchar2,LN$CharacterMeter,1))+LN$CharacterMeter)||LN$EncryptedDataInVarchar2; LN$CharacterMeter := LN$CharacterMeter + 1; End Loop; Return(LN$EncryptedDataInVarchar2) ; END; /

---

La fonction de decryptage :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

CREATE OR REPLACE FUNCTION F_Decrypt_Varchar2_To_Number_2 ( PN$Varchar2ToDecrypt IN VARCHAR2 ) Return NUMBER IS LN$EncryptedDataInVarchar2 VARCHAR2(50); LN$CharacterCountInData NUMBER(3); LN$CharacterMeter NUMBER(3); LN$DataInVarchar2 VARCHAR2(50); LN$DataInNumber VARCHAR2(50); BEGIN LN$EncryptedDataInVarchar2 := PN$Varchar2ToDecrypt; LN$CharacterCountInData := LENGTH(LN$EncryptedDataInVarchar2);   LN$CharacterMeter := 1; LN$DataInVarchar2 := '';   While LN$CharacterMeter <= LN$CharacterCountInData Loop LN$DataInVarchar2 := LN$DataInVarchar2||CHR(ASCII(SUBSTR(LN$EncryptedDataInVarchar2,(LN$CharacterCountInData-LN$CharacterMeter+1),1))-LN$CharacterMeter); LN$CharacterMeter := LN$CharacterMeter + 1; End Loop; LN$DataInNumber := To_NUMBER(LN$DataInVarchar2); Return(LN$DataInNumber) ; END; /

---

Comment wrapper ces fonctions :

Code:

---

1 2 3 4 5 6 7

D:>wrap iname=F_Decrypt_Varchar2_To_Number_2.sql   PL/SQL Wrapper: Release 9.2.0.1.0- Production on Ve Fev 24 16:01:03 2006   Copyright (c) Oracle Corporation 1993, 2001. All Rights Reserved.   Processing F_Decrypt_Varchar2_To_Number_2.sql to F_Decrypt_Varchar2_To_Number_2.plb

---

Et comment compiler ces fonctions :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

D:>sqlplus USER/PASS@BDD   ...   ConnectÚ Ó :   SQL> @F_Encrypt_Number_To_Varchar2_2.plb   Fonction crÚÚe.   SQL> @F_Decrypt_Varchar2_To_Number_2.plb   Fonction crÚÚe.   SQL> exit

---

Et maintenant l'utilisation :

Code:

---

1 2 3 4

select 27472.34 "Valeur non codée", DWH_DRH.F_Encrypt_Number_To_Varchar2_2(27472.34) "Valeur codée", DWH_DRH.F_Decrypt_Varchar2_To_Number_2(DWH_DRH.F_Encrypt_Number_To_Varchar2_2(27472.34)) "Valeur décodée" FROM DUAL;   Valeur non codée Valeur codée Valeur décodée 27472,34 <:27;793 27472,34

---

Alors évidemment l'algo est simple, c'est juste un proof of concept. Je pense que celui que j'implementerai possèdera demandera en plus une clé de cryptage et de décryptage, pour que seules les personnes connaissant cette clé et l'application tiers puissent coder et décoder les valeurs.

Dans le principe d'utilisation : la personne responsable construit les fonctions en local, les wrapp et les compile sur le serveur de production. Puis (après de nombreux tests hein ?) elle lance un update des valeurs à protéger en mettant 0 à la place et en insérant la valeur codée. Avec une chaine de cryptage ça donnera à peu près ça :

Code:

---

update MATABLE set MA_VALEUR=null, MA_VALEUR_CRYPT=F_Encrypt_Number_To_Varchar2(MA_VALEUR,'Ceci est ma chaine de cryptage');

---

Pour retrouver la valeur cryptée il faudra utiliser la fonction de décryptage avec la clé comme ceci :

Code:

---

select F_Decrypt_Varchar2_To_Number(MA_VALEUR_CRYPT,'Ceci est ma chaine de cryptage') from MATABLE;

---

Ce qui fait que la seule solution pour obtenir les valeurs cryptées sont
1) de torturer des heures durant les personnes la possédant
2) de pirater l'ordinateur qui a encore les sources
3) de décompiler les fonctions wrappées
4) de sniffer le réseau
5) de regarder le code de la session qui tourne pour connaître la clé de décryptage.

Si vous connaissez des parades à ces problèmes là (par exemple cryptage du code SQL envoyé à Oracle), merci de m'en faire part (à part le fait de retirer les droits d'accès aux sessions qui tournent ou aux objets à tout le monde).

Si vous avez des commentaires :wink:

5) étant enfantin pour un DBA...

Je vous conseille la lecture de mon article (encore en beta) : http://leoanderson.developpez.com/securisation_oracle/

;-)

Bah oui mais si on couple ça avec le fait que on a plus qu'un seul DBA et qu'il est de confiance ça roule je pense...


Merci pour l'article. Je vais me pendre parce qu'il y a pleins de choses à prendre en compte en plus et puis je le lit. Merci.

Honnêtement, votre proposition va allourdir vos procédures pour rien puisque le DBA étant de confiance, ce n'est pas les données qu'il faut protéger, mais les communications... (TCP+SSL = TCPS)

Certes mais de toutes façons j'ai juste fait un proof of concept là. En fait pour moi il n'y a que 2 solutions viables :
- DBA de confiance
- externaliser la base.

Tout le reste ne sont que des ... bouts de scotch destinés à embêter le plus possible les gens qui voudraient attaquer ces données.

Car si je parle du DBA comme source potentielle d'insécurité, je pense plutôt à toutes les personnes qui ont pu à un moment donné avoir accès à la base (installation de BO sur leur poste, etc.) et qui n'ont pas tous les moyens des DBA à leur disposition.

Je pense aussi à ceux qui pourraient récupérer les sauvegardes pour les remonter sur d'autres machines. La sauvegarde est sous-traitée, et donc ce n'est plus un DBA de confiance mais une équipe entière de confiance qu'il faut, et on retombe dans notre problématique.

PS : il y a une faute :

Citation:

---

I-B. Surveiller les connections SYS
Il est promordial...

---

AMHA, dans votre cas, vous devriez mettre en place

• CMan
• TCPS sur SQL*Net
• TDE

avec un DBA de confiance ou dans le cadre d'une base externalisée, cela revient strictement au même.

Ainsi, vous seriez sûr que

• N'importe qui ne pourrait pas techniquement accéder aux bases
• Un sniffer réseau ne pourra rien capter
• Une exploitation brute des fichiers en dehors de la base sera possible mais ne permettra d'accéder qu'aux données non sensibles

Si votre application n'est pas encore développée, il est également possible d'intégrer des VPD (Virtual Private Database) afin de contrôler plus finement les autorisations d'accès.

Bon bon bon..

bon bon...

bon...

* Ouvre la porte des toilettes, jette son rapport préliminaire et tire la chasse *

Bon alors déjà j'aime beaucoup ce passage, c'est en effet notre problématique.

Code:

---

Le cryptage n'est pas à proprement parler un élément contribuant à la sécurité de la base. En effet, la sécurité consiste à assurer l'intégrité et la disponibilité des données. Les procédures de chiffrement ont quant à elles un autre but : empêcher que les données puissent être exploitées si elles tombent entre de "mauvaises mains".

---

La question maintenant c'est quels sont les différents cas qui font que les données puissent tomber entre de mauvaises mains.

Il y a le 1er cas, le plus évident : les mauvaises mains viennent chercher les données. Là avec un DBA de confiance + une bonne application des règles de sécurité de base + une gestion liste blanche des postes qui ont accés à la base (merci de l'info d'ailleurs), on devrait s'en sortir.

Maintenant qu'est-ce qu'il y a comme autres solutions :
- les sauvegardes.
- l'espionnage réseau.
- la diffusion des données APRES requêtage.

et les solutions :
- crypter les données en base avec une fonction de cryptage ou plus simplement en utilisant les possibilités d'Oracle.
- crypter les échanges réseaux (mais avec des produits comme BO est-ce possible) ?
- défoncer la tronche aux utilisateurs qui laissent trainer des rapports avec des infos sensibles.

D'ailleurs une remarque pour l'exemple du cryptage des salaires (puisque ça me concerne), on peut très bien imaginer que la requête sera

Code:

---

select * from TABLE_SALAIRE where F_Decryptage(SALAIRE)>1500

---

non ?

Et on peut faire un index sur une colonne + fonction il me semble, non ?

En tous cas merci pour l'article qui donne quand même des petites infos intéressantes même s'il ne fait que confirmer ce que je craignais, c'est-à-dire que la solution magique n'existe pas.

Ok merci, je vais mettre cette solution en avant alors. Mais TDE c'est quoi ? C'est le cryptage par Oracle de certaines colonnes c'est ça ?

Pour les VPD, j'ai regardé en vitesse mais je n'ai pas vraiment eu le temps de me pencher dessus. L'application existe déjà mais il ne s'agit que d'un datawarhouse avec BO greffé dessus donc il y a peu de contraintes techniques.

EDIT:
Transparent Data Encryption, ok c'est bien ce que je pensais.

Concerant, les possibilités de fuite que vous évoquez...

• les mauvaises mains viennent chercher les données : en filtrant les connections et en sécurisant les mots de passes, on limite les risques d'intrusion frauduleuse => pas de méchant pirate sorti de null part (mais attention, cela allourdit les procédures de nouveau poste, changement de réseau, personnes nomades, ...)
• les sauvegardes : avec la technique de TDE, no problem... les sauvegardes ne révèleront aucun secret s'ils n'ont pas de quoi re-créer le ewallet qui va bien (mais attention, cela vous complexifie également vos procédures de sauvegarde et surtout restauration)
• l'espionnage réseau : avec des communications chiffrées avec SSL, y'a peu de risque (et côté logiciels clients, il n'y a pas de soucis puisque c'est SSL qui s'intercale entre le client (BO) et TCP...)
• la diffusion des données APRES requêtage : là, il n'y a aucune solution technique. Cependant, prévenir les utilisateurs que les accès sont audités, journalisés (et donc déclarés à la CNIL) permettra à tous de prendre conscience de ce qu'ils font...
  Ce dernier point est déjà très important car il inclut évidemment le DBA...

Et là, c'est déjà pas mal, non ? :-)

De toute façon, c'est clair qu'il n'y a pas de solutions miracle, que rien n'est infaillible, mais surtout, tout ceci a un réel coût !!!

Ouaih c'est pas mal du tout.

Ca va bien me servir. Depuis le début je cherche à appuyer d'une manière argumentée le fait que la seule solution (hors externalisation) est un DBA de confiance, là ça devrait rouler.

Merci beaucoup, beaucoup.

Dernière question : puis-je imprimer votre dossier (en conservant toutes les informations dessus évidemment) pour appuyer mes conclusions dans ma réunion ?

Citation:

---

Envoyé par nuke_y

D'ailleurs une remarque pour l'exemple du cryptage des salaires (puisque ça me concerne), on peut très bien imaginer que la requête sera

Code:

---

select * from TABLE_SALAIRE where F_Decryptage(SALAIRE)>1500

---

non ?

---

Oui, mais dans ce cas, le DBA n'a aucun mal à accéder aux données non cryptées (suffit de tracer les sessions).
Donc cela gêne les utilisateurs "normaux" qui ont le droit d'accéder à la base (grâce au filtrage, aux grants et aux mots de passes robustes, on en est sûr à 99,99%).... donc, ça ne gêne que ceux qui sont censés décrypter... :? pas génial, non ? ;-)

Citation:

---

Envoyé par nuke_y

Ca va bien me servir. Depuis le début je cherche à appuyer d'une manière argumentée le fait que la seule solution (hors externalisation) est un DBA de confiance, là ça devrait rouler.

---

L'externalisation n'est pas une solution, c'est simplement botter en touche en disant "débrouillez-vous avec ça", mais c'est donc surtout prendre le risque de ne pas maitriser le processus....
C'est effectivement en ayant des personnes de confiance que vous aurez les meilleurs résultats.

Attention tout de même, aux coûts que tout cela va engendrer.... des personnes moins nombreuses, plus expertes, avec des astreintes plus fréquentes, ... des liaisons spécialisées plus rapides (pour compenser un peu la lourdeur engendrée par CMan et SSL), des campagnes de tests plus contraignantes, ....

Sinon, no problemo pour imprimer le dossier.
Si vous pouvez patienter un peu, il devrait y avoir une version pdf plus adaptée à l'impression...

Bah la réunion c'est mardi alors on verra.

Disons que l'externalisation est une solution idéale dans le cas où les données touchent les employés. Par exemple les salaires, les promotions, les entretiens annuels, etc. On a les mêmes dangers à l'extérieur qu'à l'intérieur sauf qu'il y a moins de chance que ça se propage en interne.

Sinon pour le cryptage c'était juste pour pinailler sur ce point là, mais c'est vrai que ça sert à rien...

Citation:

---

Envoyé par LeoAnderson

Je vous conseille la lecture de mon article (encore en beta) : http://leoanderson.developpez.com/securisation_oracle/

---

8O prometteur :ccool:

Citation:

---

Envoyé par nuke_y

D'ailleurs une remarque pour l'exemple du cryptage des salaires (puisque ça me concerne), on peut très bien imaginer que la requête sera

Code:

---

select * from TABLE_SALAIRE where F_Decryptage(SALAIRE)>1500

---

non ?

---

Moi je le casse comme je veux ça :

Code:

---

select F_Decryptage(SALAIRE) from TABLE_SALAIRE

---

j'suis un pro du hacking :mrgreen:

Citation:

---

Envoyé par nuke_y

Disons que l'externalisation est une solution idéale dans le cas où les données touchent les employés. Par exemple les salaires, les promotions, les entretiens annuels, etc. On a les mêmes dangers à l'extérieur qu'à l'intérieur sauf qu'il y a moins de chance que ça se propage en interne.

---

Il y a des sociétés spécialisées dans ce type de grestion d'information, le secret est une des garanties qu'elles offrent. Il n'y a pas plus de risque que retrouver son RIB sur internet à cause d'un agent de banque peu scrupuleux :?

C'est vrai sauf que l'externalisation ne se ferait pas dans une société spécialisée mais auprès d'une grosse SSII, ce qui ne m'arrange pas...

Citation:

---

Envoyé par nuke_y

C'est vrai sauf que l'externalisation ne se ferait pas dans une société spécialisée mais auprès d'une grosse SSII, ce qui ne m'arrange pas...

---

peu importe... après il y a des obligations contractuelles et pénalités en cas de non respect... en général ça dissuade ;)