Commande Unix STRINGS et données non cryptées : pas bon du tout

Bonjour,

En faisant chez moi des tests, je me suis rendu compte qu'avec la commande Unix Strings on pouvait lire les données des tables Oracle de type texte si elles ne sont pas cryptées; visiblement c'est le but de cette commande.
Plus étrange, si la table est supprimée, les données sont encore visibles dans le datafile :aie: et de pire en pire ou de mieux en mieux, j'ai l'historique des modifs de mes données (sur une base très peu active, je précise) :ptdr:

J'ai posté sur AskTom pour savoir si c'était normal et on m'a répondu que c'était une erreur courante de croire que les données Oracle ne sont visibles que depuis la base et donc qu'il était très fortement recommandé de toujours les crypter.
Le lien ici avec mes tests cases pour ceux que ça intéresse : https://asktom.oracle.com/pls/apex/a...-not-encrypted

Voilà, je savais qu'il fallait crypter les données sur le réseau (datapump, dblink...) mais je ne pensais pas qu'à partir de Unix on pouvait bypasser les règles élémentaires de sécurité d'un SGBD; on en apprend tous les jours.

Savez-vous si je peux régler ce problème sans passer par un cryptage?

Bonjour,
Il faut relativiser le problème: normalement, l'accès au serveur est protégé, de même que l'accès physique au disques dans le datacenter.
A noter que même encrypté sur disque, si on est sur le serveur on peut accéder à la mémoire et y voir les données.

Accès à la mémoire? Tu fais un dump d'un buffer pour voir les données?

Ceci étant dit, ce qui m'a le plus étonné ce n'est pas qu'on voit les données mais qu'elles restent dans le datafile même si la table est truncatée ou supprimée et qu'on ait l'historique des modifs (si l'espace disque est suffisant bien sur).

si tu fais un string sur les redo logs tu verra encore plus d'historique puisqu'il contient redo et undo

Citation:

---

Envoyé par pachot

si tu fais un string sur les redo logs tu verra encore plus d'historique puisqu'il contient redo et undo

---

Oh bordel, j'avais pas essayé, je n'y avais pas pensé :aie:
Voilà un nouveau joujou :lol:

Merci à nouveau pour tes conseils!

Sinon tu peux utiliser ASM, ca ajoutera une complexité supplémentaire pour accéder aux fichiers. Je vais aller tester le strings sur les fichiers, j'avais jamais pensé à tester ca.

Super cette commande strings, je connaissais pas.
Je viens de la tester sur un dump dont je n'ai pas le log, et en tirer les schémas exportés :)

Citation:

---

strings mydump.dmp | grep "^CONNECT"

---

Citation:

---

Envoyé par Ikebukuro

Plus étrange, si la table est supprimée, les données sont encore visibles dans le datafile

---

Hello,
même avec l'option purge ?
Avec la recyclebin à ON par défaut, ça ne me surprendrais pas.

En effet Oracle, Oracle n'a jamais prétendu que les données étaient automatiquement cryptées dans les fichiers.
(Sinon, d'ailleurs, il ne proposerait pas d'options payantes pour le faire).

Concernant la suppression des tables, une petite démo que j'ai l'habitude de faire en formation :

Code:

---

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

SQL> create table scott.demo 2 tablespace users 3 as select * from scott.emp;   Table créée.   SQL> alter tablespace users offline;   Tablespace modifié.   SQL> drop table scott.demo purge;   Table supprimée.   SQL> alter tablespace users online;   Tablespace modifié.

---

Cela illustre le fait qu'une suppression de table n'a pas d'effet physique sur la table, mais uniquement dans le dictionnaire de données (indirectement dans le tablespace SYSTEM). La table est alors réputée ne plus exister, et l'espace qu'elle occupait est déclaré réutilisable.

Le mécanisme de corbeille introduit avec Oracle 10 n'a pas coûté grand chose : toute la "magie" consiste à stocker quelques métadonnées complémentaires lors de la suppression, telles que le nom initial de la table, ce qui fait qu'il est aisé de la récupérer.

Effectivement, un salarié d'Oracle m'a confirmé que par défaut on pouvait voir les données de la base HORS de la base. C'est une erreur fréquente de croire qu'il faille passer obligatoirement par des ordres SQL pour les consulter : accès via Unix avec STRINGS, accès via le réseau (sniffage de paquets), accès via la mémoire avec un dump... ça fait beaucoup!

Maintenant, la commande STRINGS se limite aux champs de type caractères; mais ça peut faire mal : numéro de CB (je les vois mal en Number), adresses mail... on peut récupérer des infos chaudes :mrgreen: