Serverside encryptie opslag data

[I-King]

Mijn vraag
Bestaat er de mogelijkheid om een webservice te ontwikkelen waarbij data wordt opgeslagen die alleen toegankelijk is voor de gebruiker?
Ik ben wel bekend met de algemene termen en ik kan me voorstellen dat er zoiets bestaat dat data opgeslagen wordt met encryptie bestaande uit password en username.

Ik verwacht echter dat je als ontwikkelaar altijd hier omheen kan werken (wachtwoord plaintext afvangen?)

Zijn hier mogelijkheden zodat we als bedrijf zijnde de verantwoordelijkheid hiervoor kunnen afdragen op de klant en dat wij niet meer verantwoordelijk zijn voor de data?

Ik ben geen programmeur maar we zijn bezig de randzaken uit te zoeken om een ontwikkelaar de juiste richting op te sturen. Vandaar dat ik op jullie kennis vertrouw.

PS: Ja, ik weet dat alles te hacken is, maar het gaat net zoals Apple Iphone erom dat we het zo sluitend mogelijk maken dat de gegevens alleen door de klant toegankelijk zijn.

[Question Mark]

Wat wil je precies?

Data opslaan die alleen toegankelijk is voor een bepaalde gebruiker is iets wat een beetje fatsoenlijk fileserver standaard al kan. Dat heeft te maken met toegangsrechten en staat compleet los van encryptie.

Welke verantwoordelijkheden wil je nu precies afdragen aan een klant?

[I-King]

Dag Mark, het gaat erom dat wij als eigenaar van de server ook niet bij deze data kunnen. Wij slaan bijvoorbeeld klantgegevens op van klanten van onze gebruikers en als wij die toegang kunnen beperken tot alléén de gebruiker dan beperkt ons dat in risico.

Zoals jij aangeeft met fileserver, dat betreft access rechten tot bepaalde bestanden, maar als systeem admin kun je dat toch makkelijk overrulen?

Dus eigenlijk bedoel ik: Hoe kunnen we toegang tot data zo maken dat alleen de eindgebruiker (onze klant dus) er toegang tot heeft, zonder dat wij er nog bij kunnen? (En access rights lijken me makkelijk aan te passen als server admin).

[Question Mark]

I-King schreef op vrijdag 19 februari 2016 @ 14:46:
Zoals jij aangeeft met fileserver, dat betreft access rechten tot bepaalde bestanden, maar als systeem admin kun je dat toch makkelijk overrulen?

Klopt, maar zo had ik de topicstart niet begrepen.

Je wilt dus dat klanten data bij op jullie systemen gaan stallen, zonder dat jullie als eigenaar en beheerder van dat systeem (leesbare) toegang tot deze data hebben.

En die data moet verder alleen maar via een webservice ontsloten gaan worden? (waar jullie ook eigenaar en beheerder van zijn?)

Volgens mij houdt dat automatisch in dat encryptie en decryptie dan op de client van de klant moet gaan plaatsvinden. Als dat pas op de webservice gebeurt hebben jullie immers toegang tot de encryptiesleutel, én de nog-niet encrypte data komt binnen op een systeem van jullie wat in theorie betekend dat jullie daar gewoon bij kunnen.

Overigens zijn hier best wel wat standaarden voor. Hebben jullie al uitgezocht aan welke standaard/regulatie jullie oplossing moet gaan voldoen. Als je dat hebt bepaald weet je namelijk wat duidelijk wat je allemaal op moet gaan lossen. Zie ook:

https://www.sans.org/read...-encryption-applies-34675

[Semt-x]

Stel dat je voor encryptie,gaat en de klant verliest zijn private key, is al zijn data meteen ontoegankelijk voor de klant? hoe krijg je die private key op verschillende devices? of is de data alleen van 1 machine of 1 user toegankelijk?

Ik word ongemakkelijk van iemand die zonder security kennis een "veilige" dienst wil ontwerpen.
"password en username" is geen encryptie, maar authenticatie. Blijkbaar ben je toch niet zo bekend met "algemene termen ".

Wat bedoel je in juridische zin met "verantwoordleijkheid voor de data afdragen" ?
klanten stallen hun data bij jullie, maar jullie willen / dragen geen enkele verantwoordleijkheid voor die data? Wat is dan precies de dienst die je levert?

[I-King]

Question Mark schreef op vrijdag 19 februari 2016 @ 14:58:
[...]

Klopt, maar zo had ik de topicstart niet begrepen.

Je wilt dus dat klanten data bij op jullie systemen gaan stallen, zonder dat jullie als eigenaar en beheerder van dat systeem (leesbare) toegang tot deze data hebben.

En die data moet verder alleen maar via een webservice ontsloten gaan worden? (waar jullie ook eigenaar en beheerder van zijn?)

Volgens mij houdt dat automatisch in dat encryptie en decryptie dan op de client van de klant moet gaan plaatsvinden. Als dat pas op de webservice gebeurt hebben jullie immers toegang tot de encryptiesleutel, én de nog-niet encrypte data komt binnen op een systeem van jullie wat in theorie betekend dat jullie daar gewoon bij kunnen.

Overigens zijn hier best wel wat standaarden voor. Hebben jullie al uitgezocht aan welke standaard/regulatie jullie oplossing moet gaan voldoen. Als je dat hebt bepaald weet je namelijk wat duidelijk wat je allemaal op moet gaan lossen. Zie ook:

https://www.sans.org/read...-encryption-applies-34675

Bedankt, een zetje in deze richting had ik inderdaad nodig. Ik begrijp ook jouw stuk en vandaar dat ik ook al aangaf dat het niet waterdicht is als de encryptie alleen op onze server is, want dan kunnen wij idd de sleutel afvangen en decrypten. Toch zou dat al een acceptabele oplossing zijn omdat er duidelijke grenzen gebroken worden om een dergelijke handeling uit te voeren.

Semt-x:
Ik begrijp wat je bedoelt. Ik ga dit dan ook niet ontwerpen of ontwikkelen, maar ik wil wel zoeken naar een dergelijke oplossing. Een andere partij zal dit dan ook verder gaan uitwerken, maar als ik alvast een beeld heb wat wel of niet mogelijk is is voor mij voldoende. Wellicht dat ik het dan niet met de exact juiste termen benoem.

[begintmeta]

I-King schreef op vrijdag 19 februari 2016 @ 15:32:
...Toch zou dat al een acceptabele oplossing zijn omdat er duidelijke grenzen gebroken worden om een dergelijke handeling uit te voeren.
...

Voor goede monitoring hoef je verder geen encryption te hebben in principe.

[Question Mark]

I-King schreef op vrijdag 19 februari 2016 @ 15:32:
[...]
Toch zou dat al een acceptabele oplossing zijn omdat er duidelijke grenzen gebroken worden om een dergelijke handeling uit te voeren.

Dan hoef je ook geen encryptie toe te passen.

Jezelf (toegangs)rechten toe gaan kennen op data waar je volgens procedures niet bij mag komen is immers het doorbreken van diezelfde grenzen.

[I-King]

Dat is ook weer waar, ik zat echter ook met de gedachten als deze database gehackt zou worden dat deze gegevens niet zonder meer bruikbaar zijn.
Natuurlijk kun je niet alles afvangen als je gebruiksgemak/vrijheid afweegt tegen veiligheid, daarom zoek ik het in de breedte, wat is er mogelijk en wat niet? Dat geeft me in ieder geval een basis voor een discussie. Ik ben geen programmeur maar wil wel begrijpen waar het over gaat.

[begintmeta]

IMHO is het toch echt handig eerst een duideelijke wenslijst te formuleren en vervolgens te kijken naar wat mogelijk is, en wat voor- of nadelen zijn.

[Orion84]

begintmeta schreef op vrijdag 19 februari 2016 @ 15:43:
IMHO is het toch echt handig eerst een duideelijke wenslijst te formuleren en vervolgens te kijken naar wat mogelijk is, en wat voor- of nadelen zijn.

Precies, met als onderdeel daarvan dus ook welke risico's je ziet, welke daarvan acceptabel zijn en welke je wilt afdekken met een technische maatregel.

Bedenk ook dat als je de boel dusdanig versleutelt dat alleen de klant zelf er wat mee kan, dat je dan dus als bedrijf ook niets/weinig meer met die data kan. Je hebt niet veel verteld over wat voor soort applicatie het is, maar moet bijvoorbeeld de klantenservice ook bij de klantengegevens kunnen? Als jullie zelf als bedrijf niets met de gegevens doen (immers wil je enkel de klant toegang geven), waarom sla je ze dan op?

[MAX3400]

Geen idee wie jij bent en wat de klant doet en wie uiteindelijk het beheer over de server voert, hardware-technisch, OS-technisch, applicatie-technisch maar ik kan me voorstellen dat er altijd 1 account is die alles mag, namelijk voor backup/restore-doeleinden?

Daarnaast, maar dat lijkt ook wel uit wat andere antwoorden hier; als de klant niet wil dat jullie data kunnen zien/bewerken/verplaatsen, dan mag daar wel een hele grote exception in een SLA op komen. Want "bij de data" komen is ook "kan iemand Miepje permissies geven op mapje declaraties?" of gaat de klant dat ook zelf doen?

[mcDavid]

I-King schreef op vrijdag 19 februari 2016 @ 15:41:
Dat is ook weer waar, ik zat echter ook met de gedachten als deze database gehackt zou worden dat deze gegevens niet zonder meer bruikbaar zijn.
Natuurlijk kun je niet alles afvangen als je gebruiksgemak/vrijheid afweegt tegen veiligheid, daarom zoek ik het in de breedte, wat is er mogelijk en wat niet? Dat geeft me in ieder geval een basis voor een discussie. Ik ben geen programmeur maar wil wel begrijpen waar het over gaat.

Hoe wou je in dit model garanderen dat de hacker niet de sleutels in handen krijgt - die ook op de server aanwezig moeten zijn om te en/de-crypten?

Ik ben groot voorstander van end-to-end encryptie, maar je moet het goed doen of je moet het niet doen. En niet alleen maar ergens een nutteloze encryptieslag tussenbouwen omdat encryptie nou eenmaal een buzzword is en je met de hype mee wilt doen. Dan kun je net zo goed je database op een encrypted filesystem opslaan, ben je er ook.

[gekkie]

Encryptie bij een webserver gaat niet werken tegen hackers die root rechten op je server krijgen.
Je kunt hooguit encryptie toepassen op het filesystem voor het geval je hoster een defecte harddisk uit je systeem haalt en deze niet netjes verwerkt.

Probleem is dat:
A ) ofwel de keys op de server staan,
B ) ofwel de keys naar de server verzonden worden,
C ) ofwel er encryptie clientside plaatsvindt maar doormiddel van code die door de server verzonden is.

In al deze gevallen kan iemand die rootrechten heeft aan de sleutels komen.
Het enige waar B & C tegen zouden kunnen beschermen is dat bij tijdig opgemerkte hack .. alleen de gegevens in gevaar zouden zijn van mensen die er gebruik van gemaakt hebben sinds de hack.

[CAPSLOCK2000]

Encryptie kun je alleen laten doen door een partij die je blind vertrouwt.
In dit geval ga je er (terecht) van uit je harde garanties wil bieden en geen "blind vertrouwen".

Dat kan alleen als de partij die de software levert geen toegang heeft tot de data en als de partij die de data opslaat geen toegang heeft tot de encryptiesoftware of hardware. Als één partij toegang heeft tot beide dan kan die altijd achter je rug om de software aanpassen om de sleutels of de data door te lekken of een keysniffer te installeren of zo iets.

De meeste online backup- en storage-diensten gaan op dit punt in de fout. Ze beloven wel encryptie maar vertellen er niet bij dat dit niet helpt tegen een aanval van binnen uit. (Binnen het backup bedrijf bedoel ik dan). Dat is leuk om je gegevens te beschermen tegen per ongeluk uitlekken maar tegen echt goede hackers, machtige overheidsdiensten of kwaadwillende medewerkers helpt het niet. Die kunnen eenzijdig de encryptiesoftware infilteren (met of zonder hulp van de leverancier) en zo bij je sleutels en de data komen.

[I-King]

Bedankt voor alle tips. Het geeft me wel een beeld van wat er wel en niet mogelijk is en in ieder geval heb ik nu een kader wat mij helpt bij verdere (interne) discussies. Nogmaals ik hou van goed werk, geen houtje-touwtje. Ik programmeer dus zelf ook niet maar wil wel de randvoorwaarden kunnen begrijpen. Ik denk dat het nu alweer een stapje duidelijker is.