Jump to content
Sign in to follow this  
Aerendir

Server, SSL e ecommerce: ma che casino!

Recommended Posts

Indipendentemente dall'obbligatorietà o meno, se io vendessi prodotti tramite un E-store farei questa breve considerazione:

 

1) vale la pena, dopo aver investito presumibilmente molti soldi nella creazione del negozio online, risparmiare 10-30 euro all'anno per un certificato SSL? (a tanto ammonta il costo dei certificati, perlomeno quelli più economici, che comunque son meglio di niente)

 

2) posto che uno dei punti chiave di uno shop online è conquistare la fiducia dei propri potenziali clienti, è più rassicurante far loro compilare un questionario su una pagina non sicura oppure sotto https con magari un bel logo che, cliccato, indica l'autenticità del certificato, a quale società è intestato ecc? Che poi questa è la ragione essenziale che determina la differenza di costo tra i vari tipi di certificato

 

Io dunque la metterei in questi termini: la risposta a queste due domande determina se vogliamo che il nostro sito abbia un certificato SSL e di quale tipo.

 

Conoscete pixmania? www.pixmania.it ... eppure il sito non è ssl ne tanto meno l'area clienti sta in SSL .... però vende...è come se vende....pur non avendo i dati criptati con SSL...

Share this post


Link to post
Share on other sites

Alla faccia! Ho sollevato un polverone!!! :D

Facciamo così, anche se siamo OT io provo a rispindervi (studio Giurisprudenza e qualche indicazione ve la posso dare); voi, però mi finite di spiegare come funziona sto benedetto SSL ;)

 

Ora non ricordo le risposte precise di tutti quanti però vi spiego come funziona.

 

Per prima cosa mi preme dirvi che non basta leggere solo un articolo per capire qual è la discplina da applicare. Questo vuol dire che il solo art. 24 non basta. Ma andiamo con ordine.

 

Nel codice ci sono molti articoli che possono essere applicati al commercio elettronico e che contribuiscono a delinearne parte della disciplina.

 

Per prima cosa distinguiamo tra dati personali e dati sensibili.

Per dato personale si intende anche l'identificativo che permette di risalire all'identità della persona. Lo stabilisce l'art. 4 lettera b) quando dispone

 

  • b) "dato personale", qualunque informazione relativa a persona fisica, persona giuridica, ente od associazione, identificati o identificabili, anche indirettamente, mediante riferimento a qualsiasi altra informazione, ivi compreso un numero di identificazione personale;

Per capirci quello che nel DB è memorizzato nel campo ID. Quindi questo

 

Anzi è pure aggirabile usando dei codici identificativi che non associano tale persona a tale scheda.

non è vero. Anche l'id di collegamento tra scheda e cliente è un dato personale proprio perchè permette di risalire all'identità della persona.

 

I dati personali DEVONO ESSERE PROTETTI!

All'art. 11, rubricato "modalità del trattamento e requisiti dei dati", il comma primo dispone che

 

Art. 11

Modalità del trattamento e requisiti dei dati

1. I dati personali oggetto di trattamento sono:

a) trattati in modo lecito e secondo correttezza;

"Secondo correttezza" è una clausola generale. E secondo correttezza io devo conservare i dati personali in una forma che ne impedisca il furto o comunque l'uso illeggittimo e la diretta conseguenza è che anche la trasmissione deve avvenire con modalità tali da evitare il verificarsi di queste situazioni.

 

Già solo questo basterebbe a configurare l'obbligo, in capo ai commercianti titolari di ecommerce, di utilizzo del SSL o di altra tecnologia idonea a garantire la sicurezza dei dati trattati.

 

Ma c'è di più. L'articolo 34 dispone, infatti, che

 

Art. 34

Trattamenti con strumenti elettronici

1. Il trattamento di dati personali effettuato con strumenti elettronici è consentito solo se sono adottate, nei modi previsti dal disciplinare tecnico contenuto nell’allegato B), le seguenti misure minime:

a) autenticazione informatica;

b) adozione di procedure di gestione delle credenziali di autenticazione;

...

e) protezione degli strumenti elettronici e dei dati rispetto a trattamenti illeciti di dati, ad accessi non consentiti e a determinati programmi informatici;

...

h) adozione di tecniche di cifratura o di codici identificativi per determinati trattamenti di dati idonei a rivelare lo stato di salute o la vita sessuale effettuati da organismi sanitari;

Le lettere a) e b) impone l'uso di autenticazione e di procedure di autenticazione Ma qui si potrebbe dibattere sul se questa dizione ricomprenda solo l'uso di coppie di username/password o se ricomprenda anche l'uso di cifratura. Spetta alla dottrina chiarire il concetto e alla giurisprudenza "farlo diventare legge". La cifratura è comunque richiamata nella lettera e) allorquando si parla di "protezione degli strumenti elettronici e dei dati rispetto a trattamenti illeciti di dati, ad accessi non consentiti e a determinati programmi informatici". Tutto questo lo si ottiene proprio con la cifratura. Quindi c'è l'obbligo di utilizzarla.

La cifratura è però espressamente prevista per alcuni dati sensibili. Si richiama, comunque, l'allegato B (che io onestamente non ho letto).

 

All'art. 13 si parla di informativa.

In questa il predisponente deve specificare se la comunicazione dei dati è obbligatori o meno, a chi verranno comunicati i dati e per quali finalità, ecc.

 

Quindi nei social network se si leggono le privacy policy si dovrebbe trovare proprio questa informativa e lo stesso vale per gli altri siti ai quali comunichiamo dati.

Se nella policy c'è scritto che altri utenti potranno prendere visione dei dati e io accetto non è un problema di codice ma di attenzione delle persone: se accetto nessun codice potrà mai fare niente.

 

Art. 24

Art. 24

Casi nei quali può essere effettuato il trattamento senza consenso

1. Il consenso non è richiesto, oltre che nei casi previsti nella Parte II, quando il trattamento:

a) è necessario per adempiere ad un obbligo previsto dalla legge, da un regolamento o dalla normativa comunitaria;

b) è necessario per eseguire obblighi derivanti da un contratto del quale è parte l'interessato o per adempiere, prima della conclusione del contratto, a specifiche richieste dell’interessato;

La parte importante ai fini della fatturazione non è tanto la lettera a) quanto la lettera b): "Eseguire obblighi derivanti da contratto".

Il clinete non potrà mai richiedere la cancellazione dei dati in questo caso poichè essi servono ai fini dell'adempimento fiscale. Al massimo potrà chiedere la cancellazione dell'account ma la fattura dovrà comunque continuare a riportare i dati personali identificativi del cliente. Quindi la fattura non si strappa ;)

 

Alla luce di quanto vi ho sommariamente scritto la regola generale è che la cifratura va utilizzata ogni volta che è necessario il trattamento di dati anche solo personali perchè anche se non espressamente richiamata dalle norme ci sono clausole generali e principi normativi che vi fanno riferimento.

Ovviamente questo vale sia nel frontend, che nel backend.

 

Il problema fondamentale, comunque, non è tanto se esite una normativa o non esiste ma se viene fatta rispettare o non viene fatta rispettare.

 

Esiste il Garante per la Privacy che dovrebbe occuparsi di questo. Se ritenete di essere stati lesi nel vostro diritto alla privacy o andate da un avvocato, o lo segnalate al garante stesso. Comunque è una cosa lunga e credo nemmeno semplice e forse porta anche spese. Avete capito perchè nessuno rispetta la normativa? ;)

 

Detto questo, torniamo al SSL?

Share this post


Link to post
Share on other sites

:) che casino LOL

 

Ritornando al tuo SSL è semplicissimo, acquisti un certificato SSL dove ti pare, nell'hosting dove vai devi avere un ip dedicato, dopo di che da plesk (o altro pannello di controllo ove possibile) ti instali il certificato e stop! :)

Share this post


Link to post
Share on other sites
Alla faccia! Ho sollevato un polverone!!! :D

Facciamo così, anche se siamo OT io provo a rispindervi (studio Giurisprudenza e qualche indicazione ve la posso dare)

 

[.......]

Esiste il Garante per la Privacy che dovrebbe occuparsi di questo. Se ritenete di essere stati lesi nel vostro diritto alla privacy o andate da un avvocato, o lo segnalate al garante stesso. Comunque è una cosa lunga e credo nemmeno semplice e forse porta anche spese. Avete capito perchè nessuno rispetta la normativa? ;)

 

Detto questo, torniamo al SSL?

 

Perdonami, ma la giurisprudenza non hai ancora finito di studiarla e sull'informatica da quello che dici sembra proprio che barcolli.

Il fatto che io rimanga perplesso su come è strutturata la normativa non significa che non la conosca, purtroppo a suo tempo ho dovuto studiarla con l'ausilio di un professionista (ciò che diventerai se finirai)

 

Vediamo se riesco a farti capire il discorso del codice identificativo.

Se io ho su server le cartelle cliniche di tutti i pazienti, ma su ogni cartella c'è solo un numero, se su quello stesso server non ci sono i nomi delle persone ma quei nomi (con relativo numero) sono in uno schedario (per esempio cartaceo) quel database informatico non necessita di essere criptato. Lo si può fare sia chiaro, ma non è necessario.

 

Il comma h dell'articolo 34 che tu hai allegato e che conoscevo

h) adozione di tecniche di cifratura o di codici identificativi per determinati trattamenti di dati idonei a rivelare lo stato di salute o la vita sessuale effettuati da organismi sanitari;

ti dice chiaramente quali sono i casi in cui è necessari la cifratura (o i codici che ho tentato di spiegarti)

 

Te la dico in maniera terra terra, per dati personali comuni (o sanitari senza nominativo e modo di riconoscere la persona) su supporto informatico quando hai una pasword da 8 cifre sei legalmente a posto.

 

Poi nessuno vieta di cifrare il database o usare ssl (che non è la stessa cosa, ma lo sai vero?), ma dal punto di vista legale è necessario solo in caso dei dati del comma sopra citato (cifrare il db, non l'ssl)

Share this post


Link to post
Share on other sites
Vediamo se riesco a farti capire il discorso del codice identificativo.

Se io ho su server le cartelle cliniche di tutti i pazienti, ma su ogni cartella c'è solo un numero, se su quello stesso server non ci sono i nomi delle persone ma quei nomi (con relativo numero) sono in uno schedario (per esempio cartaceo) quel database informatico non necessita di essere criptato. Lo si può fare sia chiaro, ma non è necessario.

In questo caso, ma in questo caso particolare (non nell'ecommerce di cui stiamo parlando) hai ragione, la sicurezza e l'anonimità del dato è assicurata e quindi non c'è bisogno di criptare nulla (ma io lo farei comunque perchè i dati del paziente possono comunque portare ad identificarlo).

 

Il comma h dell'articolo 34 che tu hai allegato e che conoscevo

h) adozione di tecniche di cifratura o di codici identificativi per determinati trattamenti di dati idonei a rivelare lo stato di salute o la vita sessuale effettuati da organismi sanitari;

ti dice chiaramente quali sono i casi in cui è necessari la cifratura (o i codici che ho tentato di spiegarti)

Qua te lo dice chiaramente ma solo per dati sanitari o che riguardino la vita sessuale ecc. ecc..

Ti ho esposto, invece, ancora più chiaramente e analiticamente, il resto delle norme dello stesso codice che ti impongono sia di cifrare il db, sia di comunicare i dati in maniera cifrata (con SSL) negli altri casi che non possono essere ricondotti al trattamento di dati sanitari.

 

Poi nessuno vieta di cifrare il database o usare ssl (che non è la stessa cosa, ma lo sai vero?), ma dal punto di vista legale è necessario solo in caso dei dati del comma sopra citato (cifrare il db, non l'ssl)

Ah aha, si, lo so che non è la stessa cosa :D

E so anche che nessuno lo vieta, lo impongono proprio!

E' questo il punto: il fatto che non sia scritto chiaro e tondo non vuol dire che l'obbligo non ci sia! Ci si arriva per via interpretativa.

Sia chiaro, non è mia intenzione essere polemico, arrogante o presuntuoso ma ti ripeto che è così, ci sono CLAUSOLE GENERALI (http://it.wikipedia.org/wiki/Clausola_generale e si fa proprio riferimento alla "correttezza") e PRINCIPI GIURIDICI che possono essere evinti dalla lettura dell'intero codice della privacy (ed è così che i codici si leggono, non si legge il singolo articolo, MAI!), è l'interpretazione cosiddetta sistematica (Interpretazione giuridica - Wikipedia).

Il mio non era un attacco a te direttamente ma solo un voler mettermi a disposizione della community che a quanto pare a riguardo fa un bel po' di confusione e trova difficoltà.

 

Non so se l'hai studiato, con chi o come e nemmeno mi interessa. Il consiglio che ti posso dare è che se veramente pensi che sia così perchè te l'hanno detto fose l'avvocato da cui sei andato non si è spiegato molto bene o non ha capito bene quale fosse il tuo problema.

 

Poi rimane che è sempre una questione di interpretazione e soprattutto che le regole sono talmente tante e prevedono così tante sfaccettature e varianti che cambiano da caso a caso: basta nulla per modificare interamente la disciplina da applicare. Se ti fidi di quanto ti dico sono contento, se non ti fidi non posso farci niente oltre che dispiacermene, volevo solo essere utile.

 

Tornando al mio benedetto SSL esiste una risorsa in rete che mi spieghi quali sono i tipi di certificati (ora ho scoperto che esitono anche quelli Extended Validation per i quali l'authority pima di emetterli effettua controlli sull'identità di qualcuno ma non ho capito se del server o se del proprietario del server), a che servono, ecc. ? NOn mi interessa la prate tecnica (tipo il funzionamento dei protocolli di cifratura e trasmissione dei dati) ma mi interessa capire cme funzionano a grandi linee e quali sono i vantaggi o gli svantaggi derivanti dall'usarne uno piuttosto che un altro.

Share this post


Link to post
Share on other sites

Aerendir non ho mal interpretato le tue intenzioni, ho compreso benissimo il tuo tentativo di spiegare le cose secondo quello che tu sai. E' su questo che tu sai che non siamo d'accordo ma non importa, ti rispondo per l'ultima volta e poi evito ancora l'o.t.

Non ho estrapolato (e suppongo che non l'abbia fatto neanche il consulente a cui mi sono affidato) un solo articolo da tutta la legge, l'ho letta tutta. Ci sono punti precisi (due) in cui parla di cifratura e se vogliamo dirla tutta oltre che per il discorso sanitario e sulle abitudini sessuali parla di dati giudiziari, cosa che però nel privato potrà essere al più interessante per penalisti... non mi vengono in mente altri, magari ci saranno.

Se vuoi arroccarti sul discorso interpretativo fai pure, ma una password che impedisce la visione a chiunque è una protezione, io con una password proteggo i dati.

Altrimenti con lo stesso principio un archivio cartaceo dove devo conservarlo? A Fort Knox?

Poi è facoltà di chiunque fare il meglio che può, per esempio una carta di credito senza ssl non la farei mai passare, ma nome e cognome, indirizzo e cose simili che sono su qualsiasi elenco del telefono, che possono essere richiesti a qualsiasi anagrafe etc... volendo anche se passa in chiaro non è che poi sia questo gran danno.

Se uno vuole fare tutto per benino, più come immagine che altro ovviamente è libero ma non c'è obbligo di legge.

 

Poi se vogliamo proprio pignoleggiare dovremmo discutere su come è tenuto il server, se il db è cifrato in che modo avviene l'accesso (lo sai che non ne basta uno -di server- se si vogliono far le cose per benino vero?:D)

Ma se sei su shared hosting di che stiamo parlando?

 

Solo per dirti che se interpretando andiamo a cercare il massimo possibile (e non quello che è uso, per via di precedenti) ce n'è da fare.

Il problema a quel punto più che legale diventa di pararsi il sederino da eventuali risarcimenti se stiamo trattando dati molto appetibili (tipo carte di credito).

Cosa che poi è anche mezza fantascientifica... non è un solo sito che viene bucato e non ha risarcito un fischio...

 

Non ci torno più perchè sarebbe inutile, se per te è obbligatorio per legge, va bene ma io ho lasciato chiare indicazioni per chi legge il forum.... ciao :)

Edited by Uno
L'editor è andato il tilt

Share this post


Link to post
Share on other sites
(lo sai che non ne basta uno -di server- se si vogliono far le cose per benino vero?:D)

Veramente no, non lo sapevo:asd:. Non studio Ingegneria, studio Giurisprudenza. Ma lo terrò presente, grazie:zizi:.

 

Sono d'accordo con te, evitiamo l'OT che si sarebbe dovuto evitare dall'inizio. Magari se mi rispondi anche sul SSL mi fai cosa gradita che in tutta sta storia ancora non ci ho capito niente!!!

Share this post


Link to post
Share on other sites

Parti dal presupposto che il certificato potresti fartelo anche da solo, dal punto di vista tecnico è efficace uguale a quelli comprati.

La differenza come hai già capito è che uno emesso da un'autority "famosa" è riconosciuta da tutti(o quasi) i browser, quindi il cliente non vedrà nessuna finestra e il browser scaricherà automaticamente il tuo certificato personale.

 

Ovviamente se si usa l'ssl per questioni commerciali non avrebbe senso risparmiare rischieresti di fare una figura peggio che non usare l'ssl, se giri per i siti che vendono i certificati ce ne sono di tutti i colori, comunque direi che uno a 128bit che costi il meno possibile (avendo l'autority forte per il discorso di cui sopra) secondo me va bene.

 

P.s. il controllo di cui parlavi di solito avviene verificando ed accoppiando il sito/dominio all'ip e/o ad altri dati identificativi del proprietario del sito ( ogni autority stabilisce i suoi parametri), ma non è influente ai fini della sicurezza reale del certificato, ne agli occhi dei clienti sarà più bello o sembrerà più sicuro.

 

P.s. neanche io ho studiato ingegneria :emoticons_dent2020:

Share this post


Link to post
Share on other sites
Ok, grazie, sei stato chiaaarissimo.

Ah, ho capito :approved:

 

La tua diplomazia è più lenta delle dita sulla tastiera, purtroppo sulla notifica mail mi è arrivato il messaggio prima della modifica. :asd:

 

Non importa, non mi arrabbio con te, sono io che sbaglio nel dimenticare che è meglio lasciar che le persone si arrangino.

Ti auguro una buona serata :)

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×