Newsgroup: it.comp.www.php
Titolo: protezione database su hosting

Ho pubblicato il mio sito acquistando un servizio di hosting,
apache-php-mysql. Ho notato però che l'azienda che mi offre il servizio mi
ha procurato un username/password per poter interagire tramite phpmyadmin
con il database mysql.
Il problema è che sul db ho dei dati molto sensibili. Come è possibile
impostare l'accesso al db solo da me, e non anche da un dipendente
dell'azienda che offre il servizio di hosting, anche se so che legalmente
non dovrebbe avvenire???
Pur modificando l'username e la password d'accesso dell'utente root del db
non cambia nulla, tramite l'username e password del phpmyadmin riesco sempre
ad accedere via http a tutti i db mysql.
Come potrei fare?

ad accedere via http a tutti i db mysql.
Scusa ma non ho capito che servizio hai acquistato, un server dedicato
o semplice hosting? Sembrerebbe semplice hosting, perň poi non capisco
come puoi tentare di modificare la password di root. Se sei in hosting
semplice non puoi farci nulla, loro sono gli amministratori del server
e hanno accesso a tutto, devi prendere un server dedicato per fare
quello che chiedi.
Francesco Mazzi
Webmaster di AltroPC.it - 
http://www.altropc.it
 
Dev.Staff di E-Xoopport - 
http://dev.e-xoopport.it

 Come potrei fare?
Eviti di memorizzare le informazioni in chiaro, cosi' anche se qualcuno 
vi accede trova solo roba criptata.
~omar

vi accede trova solo roba criptata.
Non serve a nulla, se le può decodificare lui, le può decodificare
anche la ditta di hosting, è solo una complicazione in più.


 non dovrebbe avvenire???
Sostanzialmente non puoi.
Se sei in hosting, l'amministratore può accedere come e quando vuole.
Tralasciamo il fatto che legalmente non possa farlo.
E non ti conviene nemmeno criptare i dati sensibili perchè per utilizzarli 
devi decriptarli in qualche modo e nei tuoi script php ci sarà scritto come 
fare. E anche gli script sono accessibili.
Quello che puoi fare è un contratto di housing, ossia di usare una TUA 
macchina, di cui TU sei l'amministratore.
In questo modo limiti la possibilità di accedere alla macchina agli 
estranei.
Ciao
Marco 

 Il problema č che sul db ho dei dati molto sensibili. Come č possibile


 anche la ditta di hosting, è solo una complicazione in più.
?!
Puo' farlo solo se il server database e il server di hosting sono sulla 
stessa macchina, perche' si andrebbe a leggere la chiave di decodifica 
nella home del cliente.
Questo pero' vorrebbe dire che la ditta lo ha fatto intenzionalmente e 
quindi il cliente puo' procedere come crede.
Se invece mi metti in chiaro le informazioni nel tuo db io potrei dire 
che mi sono capitate davanti mentre controllavo i dump giornalieri e/o 
sistemavo il server...
~omar

quindi il cliente puo' procedere come crede.
perchè mai scusa? Anche se sono su server diversi basta che la ditta
vada a leggere i sorgenti php su un server e poi decodifica i campi
nel db sull'altro server.


 nel db sull'altro server.
Ovviamente se ha accesso al servente database...
se ha le chiavi di decodifica, ma per leggere il valore plain puoi farlo 
solo via web, e' rischioso per te hoster che mi stai violando...
E' ovvio per entrambi che se mi affitti una cosa che gestisci tu, puoi 
sguazzare nel mio codice come un paperotto; ed e' per questo che si 
cercano sempre modi per rendere queste operazioni il piu' loggate possibile.
Quello di cui parlo io e' rendere piu' macchinoso l'accesso 
all'informazione finale utilizzando ad esempio la crittografia.
Tra l'altro questo e' un dibattito tanto OT quanto interessante da fare...
~omar

all'informazione finale utilizzando ad esempio la crittografia.
Forse allora non ci capiamo, perchè secondo me l'hosting lo trova
sempre il modo di leggere le informazioni senza farsi accorgere in
alcun modo dall'utente...puoi spiegarti meglio come intendi proteggere
la cosa?


 la cosa?
INSERT  INTO tabella set campo = AES_ENCRIPT($password,dato)
il problema e' lo storage della password, che puo essere l'unione di 2 o piu
valori
un dato in sessione, un dato del db, una password in chiaro (solo in POST)
conumque per uan cosa del genere ti serve qualcosa tipo https, x509 (2
certificati)


 
Se vuol risparmiare ed avere una "macchina" tutta sua da gestirsi come 
meglio crede (server sql compreso), senza complicarsi la vita, può 
prendersi un server virtualizzato ed il gioco è fatto.
Ciao
Gianni

certificati)
e gli argomenti della funzione aes_encript da dove li prendi?
L'hosting avrà sempre il modo di ricavarseli leggendo i sorgenti php,
a meno che non si utilizzi codice php criptato.


 la cosa?
Non mi sto spiegando...
Se io dovessi seguire la tua filosofia i miei clienti non dovrebbero 
utilizzare mod_ssl perche' tanto *io* posso sempre accedere ai loro 
certificati locali.
E' *ovvio* che colui che ti <affitta> una macchina potra' *sempre* 
guardarci dentro....
Quello di cui parlo io pero' e' semplicemente evitare di mettere in 
bella mostra le informazioni, facendo in modo che, nel caso di 
<filtraggio> delle informazioni, i possibili colpevoli siano ridotti al 
minimo tecnico.
Il fatto che c'e' qualcuno (l'hoster...) che puo' leggere tutto nel tuo 
sistema non deve essere un deterrente per utilizzare sistemi di 
crittografia o quant'altro salvaguardi l'informazione privata.
Sta pur certo che se un mio cliente utilizza sistemi di crittografia di 
un certo livello, e poi le notizie <filtrano>, qualche sguardo 
sospettoso sui tizi con le password di root ci arrivano.
Se invece il mio cliente tiene informazioni delicate in chiaro, fa i 
dump dei database senza criptarli, tiene i documenti in aree aperte del 
suo hosting... allora io potro' *sempre* dire che lui per primo non ha 
adottato politiche di sicurezza adeguate.
E tu sai di questi tempi quanto ci stiano rompendo le scatole con simili 
argomenti (a proposito... il DPS lo hanno prorogato ancora...)
Io di questo parlo...
poi se tu dici <tanto quelli li leggono comunque, quindi lascia tutto in 
chiaro...> pazienza... ognuno ha i suoi metodi, ci mancherebbe altro :-)
~omar

chiaro...> pazienza... ognuno ha i suoi metodi, ci mancherebbe altro :-)
Penso di avere capito quello che intendi dire, sono d'accordo con te,
io rispondevo solo a nek2000 che vuole proteggere il db dai dati
sensibili, ma in realtà è ovvio che bisogna anche proteggere tutto il
resto, ad esempio l'invio in chiaro di questi dati...prima ci i
protegge da sguardi indiscreti provenienti dall'esterno.


 notizia...sarebbe una buona notizia :-)
[OT]
Ne ho scovato traccia su italiaoggi.it...
anche se comunque sarebbe ora di sistemarlo sto dps, ho trovato qualche 
buona base di partenza...
dici che il copia/incolla funziona anche in quel settore? :-D
[/OT]
~omar

[/OT]
Uhm...purtroppo la vedo dura :-(
