Per i database.

[Thefrog]

Quando si accede ad una base dati normalmente viene chiesto un username ed una password. Ora pero' io facendo il "dump" di un "area" di un datbase ho tristemente scoperto che tutto cio' che e' a caratteri ascii puo' tanquillamente essere letto, essendo tranquillamente scollegati dalla base dati.

Dunque ritengo che per i database siano necessarie crittografia e, aggiungo, la compressione dei dati.

Opinioni in merito sonogradite.

Regards,
The frog
(P.S. nel caso in cui il sistema non disponga di un'utility di dump e' banalissimo scriverla. Io l'ho realizzata in due rige di linguaggio C ANSI.

 

[alfistaConvinto]

Quando si accede ad una base dati normalmente viene chiesto un username ed una password. Ora pero' io facendo il "dump" di un "area" di un datbase ho tristemente scoperto che tutto cio' che e' a caratteri ascii puo' tanquillamente essere letto, essendo tranquillamente scollegati dalla base dati.

Dunque ritengo che per i database siano necessarie crittografia e, aggiungo, la compressione dei dati.

Opinioni in merito sonogradite.

Regards,
The frog
(P.S. nel caso in cui il sistema non disponga di un'utility di dump e' banalissimo scriverla. Io l'ho realizzata in due rige di linguaggio C ANSI.

stai confondendo delle cose
una cosa è il login dentro il dbms che nei database seri cè ed è difficilmente violabili es mysql o oracle
una cosa è un file dump per copiare dei dati temporanei che si devono tenere da conto!
cmq non sarebbe difficile creare una procedura per criptare l'accesso al file dump.. comunque non ne vedo la necessità

 

[Thefrog]

Quando si accede ad una base dati normalmente viene chiesto un username ed una password. Ora pero' io facendo il "dump" di un "area" di un datbase ho tristemente scoperto che tutto cio' che e' a caratteri ascii puo' tanquillamente essere letto, essendo tranquillamente scollegati dalla base dati.

Dunque ritengo che per i database siano necessarie crittografia e, aggiungo, la compressione dei dati.

Opinioni in merito sonogradite.

Regards,
The frog
(P.S. nel caso in cui il sistema non disponga di un'utility di dump e' banalissimo scriverla. Io l'ho realizzata in due rige di linguaggio C ANSI.

stai confondendo delle cose
una cosa è il login dentro il dbms che nei database seri cè ed è difficilmente violabili es mysql o oracle
una cosa è un file dump per copiare dei dati temporanei che si devono tenere da conto!
cmq non sarebbe difficile creare una procedura per criptare l'accesso al file dump.. comunque non ne vedo la necessità

Ma se il database contiene informazioni criptate in base ad una cript stile Unix nessun dump che non conosca la sequenza della crittografia potrebbe mai decriptare le informazioni contenute nel file di dump dell'area del database. Io non mi riferivo alla crittografia per l'accesso via sql al database, mi riferivo proprio al contenuto del database criptato.

E' sempre possibile fare un dump di una data area della base dati, area che in questo caso viene vista semplicemente come un "file", senza fare accesso via SQL alla base dati stessa.

Regards,
The frog

 

[Thefrog]

Non solo. Ma se proprio non si vuole adottare un cripting per i dati presenti nella base dati diciamo Oracle, pensiamo a quanti dati viaggiano in rete (bati pensare ai db-link di Oracle). allora sarebbe necessario che almeno a livello di application della pila OSI i dati venano criptati e compressi -magari adottando una compressione di tipo "prolog2" - (la compressione serve per affaticare meno la rete).

Opiioni in merito sono gradite.

Regards,
The frog

 

[alfistaConvinto]

Quando si accede ad una base dati normalmente viene chiesto un username ed una password. Ora pero' io facendo il "dump" di un "area" di un datbase ho tristemente scoperto che tutto cio' che e' a caratteri ascii puo' tanquillamente essere letto, essendo tranquillamente scollegati dalla base dati.

Dunque ritengo che per i database siano necessarie crittografia e, aggiungo, la compressione dei dati.

Opinioni in merito sonogradite.

Regards,
The frog
(P.S. nel caso in cui il sistema non disponga di un'utility di dump e' banalissimo scriverla. Io l'ho realizzata in due rige di linguaggio C ANSI.

stai confondendo delle cose
una cosa è il login dentro il dbms che nei database seri cè ed è difficilmente violabili es mysql o oracle
una cosa è un file dump per copiare dei dati temporanei che si devono tenere da conto!
cmq non sarebbe difficile creare una procedura per criptare l'accesso al file dump.. comunque non ne vedo la necessità

Ma se il database contiene informazioni criptate in base ad una cript stile Unix nessun dump che non conosca la sequenza della crittografia potrebbe mai decriptare le informazioni contenute nel file di dump dell'area del database. Io non mi riferivo alla crittografia per l'accesso via sql al database, mi riferivo proprio al contenuto del database criptato.

E' sempre possibile fare un dump di una data area della base dati, area che in questo caso viene vista semplicemente come un "file", senza fare accesso via SQL alla base dati stessa.

Regards,
The frog

sinceramente nn capisco ne il problema ne quello che stai dicendo ti dico solo che fare dei bakup dei db è un procedimento standard che nn ha mai portato a problemi fino ad ora! ti stai facendo problemi che non esistono

 

[alfistaConvinto]

cmq frog l'informatica nn è una scenza esatta nn ci sono regole fisse quindi se tu credi che il sistema di bakup dei database nn sia corretto è tuo diritto dovere provare a costruire un alternativa..
quindi fai un programma e migliora il tutto..

 

[Thefrog]

Non mi sono spiegato. NESSUN BACKUP.

Alla fie un database e' costituito da tabelle che poggiano i loro dati in "files piatti". Se scrivo una procedura di "dump" ESTERNA AL DATABASE, procedura che e' in grado di guardare quello che c'e' dentro i file che compongono i database, se i dati non sono criptati, tutto quello che e' in carattere ASCII in ogni file piatto all'interno del database sono in grado di vederlo. E questo senza fare alcun accesso alla base dati.

Regards,
The frog

 

[Thefrog]

Per inciso io ho scritto due righe di codice C che erano in grado di guardare perfino quello che era presente in un file eseguibile (cioe' compilato e linkato), in ambito Unix.

Regards,
The frog
(P.S. spero di essere stato chiaro adesso)