[asp.net] beveiliging data

[joopst]

We zijn bezig een site te maken waar persoonlijke en dus gevoelige data verzameld wordt. De site wordt gehost op win2003. De data wordt opgeslagen in een sql2000 database. De hosting wordt gedaan door een andere partij.

Hoe kunnen we er nou voor zorgen dat de hostingpartij de data in de database niet kan lezen ?

Wat we al hadden uitgevonden is: dbencrypt en de site laten werken met impersonation .. dan wordt alle data in de database al versleuteld.
Blijft het probleem van het pw voor het impersonation account dat gewoon uit de web.config gelezen kan worden zodat de hosting partij (in theorie) de database kan decrypten ..

We hebben ons ondertussen helemaal suf gepiekerd .. HEELP!!

[whoami]

Je paswoord in je web.config encrypten.

[joopst]

en waar wordt dan de key om te decrypten bewaard ?

[mulder]

Misschien je hostingpartij meer vertrouwen? Op het moment dat je je spullen daar host, kunnen ze er altijd wat mee lijkt me?

[neh]

IDD, zolang het voor je website mogelijk moet zijn om de informatie uit de database te decrypten kan de hoster dat ook.

Als je website na het opslaan de informatie niet meer hoeft te benaderen zou je eventueel asymmetrische cryptografie kunnen gebruiken.

[NMe]

Als iets vertrouwelijke informatie bevat waarvan je niet wil dat een derde eraan kan, dan zit er niets anders op dan het niet op een webserver te zetten, of gewoon je host vertrouwen. Of zelf gaan hosten.

[axis]

Nog maar niet te spreken over het performanceverlies.. Zoek een hoster die je vertrouwt, of bouw een server die je zelf dichtspijkert, en hang die colocated bij je hoster?

Of je huurt een dedicated server, je huurt de server + os + sql licentie, en je kunt hem zelf helemaal dichtzetten..

[gorgi_19]

joopst schreef op woensdag 04 mei 2005 @ 13:30:
en waar wordt dan de key om te decrypten bewaard ?

In een compiled assembly, welke je met een goede obfuscator behandeld.

[joopst]

Bedankt voor de snelle reacties

@Axis: Wil je het zo secure doen,dan heb je het nadeel dat je zelf natuurlijk alle beveiligingsupdates moet doen. Maar het is idd wel de overweging waard.

@gorgi_19: Heb je nog een tip voor een goeie obfuscator?

[neh]

gorgi_19 schreef op woensdag 04 mei 2005 @ 13:43:
[...]

In een compiled assembly, welke je met een goede obfuscator behandeld.

Security through obscurity is bad practice is de consensus dacht ik zo?

[gorgi_19]

plork schreef op woensdag 04 mei 2005 @ 13:51:
[...]


Security through obscurity is bad practice is de consensus dacht ik zo?

Als je een systeem admin niet vertrouwd; dan is je complete security in principe nonsense.

[Janoz]

plork schreef op woensdag 04 mei 2005 @ 13:51:
[...]


Security through obscurity is bad practice is de consensus dacht ik zo?

Niet 'bad practice', maar 'no security at all'.;)

[neh]

gorgi_19 schreef op woensdag 04 mei 2005 @ 13:58:
[...]

Als je een systeem admin niet vertrouwd; dan is je complete security in principe nonsense.

Met asymmetrische encryptie van de data is tenminste een nog enigzins tamper-proof oplossing te bouwen. Zodra de key uit jouw methode achterhaald is is meteen alle data zichtbaar.

Met asymmetrische encryptie moet de beheerder of in het geheugen rond gaan kijken (en kan dan alleen data zien die op dat moment opgeslagen wordt) of moet de public key vervangen (waarna er dus 'corrupte' data in de database komt.

Het nadeel is wel dat je website ook niet meer bij de data kan.

Maargoed, het is inderdaad zo dat het eigenlijk al stom is dat de TS vertrouwelijke gegevens op wil slaan op een host die hij niet vertrouwt.

[neh]

Janoz schreef op woensdag 04 mei 2005 @ 14:00:
[...]


Niet 'bad practice', maar 'no security at all'.;)

True

[MSalters]

Stom is één ding. Wettelijk verboden een ander. Persoonlijke gegevens vallen vrijwel zeker onder de Wet Bescherming Persoonsgegevens. Je zult dus moeten voldoen aan de eisen die de wet stelt. Dat betekent o.a. dat personen buiten je bedrijf (lees:de host) niet bij die data mag komen.

De conclusie is dus dat je geen pw op de server mag opslaan, en dus altijd (via https) een password aan de website gebruiker moet vragen.

[alienfruit]

Overigens lijkt mij het slim dat als het mogelijk de gegevens wekelijkse via een verbinding a la VPN/SSL de data op te halen, en lokaal op te slaan ipv. laten staan op de server.

[whoami]

joopst schreef op woensdag 04 mei 2005 @ 13:30:
en waar wordt dan de key om te decrypten bewaard ?

Nergens.

New Rule: Storing the connection string in the web.config file unencrypted is too risky - store it in the web.config file encrypted.

Of course this brings up the next question, "Where do I store my encryption key?" The answer, "You don't - let Windows do it for you using the Data Protection API (DPAPI)."

[Gerco]

Zorg dat je site de gegevens zelf ook niet kan lezen zonder dat een user ingelogd is. Bijvoorbeeld alleen de users table unencrypted maken, zet daar een md5 encoded versie van het password. Zodra een user ingelogd is gebruik je een ander algoritme (SHA-1 oid) om het password te hashen en die hash gebruik je als decryptie key voor zijn data.

Op die manier kan je hoster niet aan de data, je website niet en jij zelf ook niet. Alleen de user kan met zijn originele password aan zijn data. Je hebt alleen een klein probleempje als iemand zijn password wil veranderen (dat is op te lossen door de data te crypten met een random key per user en die key te crypten met het password).

Hierbij uiteraard voorbijgegaan dat je geen indexen kan gebruiken (data is met verschillende keys gecrypt in 1 tabel) en dat het continue en- en decrypten behoorlijk zwaar gaat worden. De hoster kan natuurlijk altijd met een sniffer achtige tool of een debugger achter de keys komen, helemaal dicht krijg je het nooit.

[ Voor 21% gewijzigd door Gerco op 04-05-2005 14:51 ]

[axis]

Voor een 500 euro de maand ofzo huur je een dual xeon doos met een paar scsi schijven, en een win 2003 licentie en connectie naar de buitenwereld. Doet er nog 175 p/m bij, en je hebt ook nog een sql2000 licentie.

Heb je een compleet geinstalleerde server, dan moet je zelf wel iemand hebben met wat verstand van zaken om sql2000 en IIS te beheren, en de backups (naar bijv. seperate disk) te regelen etc, en om patches e.d. bij te houden.

Maar dan heb je dus wel alles in eigen beheer, niets geshared e.d.. Maarja, wat heb je er voor over?