Beveiliging van database en applicatie

[Verwijderd]

Hoi,

Ik ben een nieuwe applicatie aan het bouwen waarin zeer veel privacy-gevoelige gegevens worden opgeslagen. Ik wil daarom zo goed als al het mogelijke doen om mijn data te beveiligen.

Ik heb de volgende constructie bedacht:
- Alle gevoelige data in de tabellen wordt m.b.v. de MySQL functie AES_ENCRYPT encrypted met een key die ik in mijn PHP- applicatie gedefineerd heb staan, zodat als de toegang tot de database gekraakt wordt er niets van data uit kan worden gelezen;
- Ik maak een MySQL user die enkel en alleen stored procedures mag uitvoeren;
- In mijn PHP code roep ik de stored procedures aan met daarbij de encryption key. Als de key klopt dan retouneren de stored procedures de decrypte data en belanden deze op het scherm van de gebruiker;

Ik maak gebruik van 2-factor login(gebruikersnaam, nummer en wachtwoord en vervolgens een SMS met unieke 6-cijferige code die eenmalig gebruikt kan worden) en beschik over een EV SSL certificaat.

Nu ben ik benieuwd wat jullie - gelet op al het bovenstaande - vinden van mijn applicatieontwerp.

[RobIII]

Verwijderd schreef op dinsdag 27 maart 2012 @ 21:30:
Nu ben ik benieuwd wat jullie - gelet op al het bovenstaande - vinden van mijn applicatieontwerp.

Een applicatieontwerp zou ik 't niet noemen, hooguit een implementatiedetail

En hoewel er, tot op zekere hoogte, iets te zeggen is voor 't encrypten van data in een DB; op 't moment dat kwaadwillenden toch toegang hebben tot je DB is de key natuurlijk ook zo gevonden. Iets met "Once you're in the vault all bets are off"; ofwel: als iemand al zo ver is gekomen en al voldoende toegang heeft weten krijgen tot 't belangrijkste in je applicatie dan zullen ze die key ook in no-time te pakken hebben. Dat moet je dus wel afwegen tegen, bijv, de performance-implicaties die je ontwerp hebben voor je applicatie, het niet (goed) doorzoekbaar/sorteerbaar zijn van je encrypted data, de overhead (qua onderhoud/code, niet zo zeer performance-wise oid) van alles via SP's moeten doen etc. En je pint jezelf natuurlijk ram vast op MySQL op deze manier; migreren naar een ander RDBMS is nooit pijnloos, maar met dit ontwerp wordt 't wel een pak pijnlijker dan. Je moet afwegen of je de tijd/energie die je hier in gaat steken misschien beter gebruikt kan worden om überhaupt te voorkomen dat iemand zo ver komt.

Having said that; een extra barrière kan natuurlijk geen kwaad. Ik zou niet weten wat er, verder, op aan te merken zou zijn.

[ Voor 6% gewijzigd door RobIII op 27-03-2012 22:19 ]

[Verwijderd]

Ik zit precies met hetgeen wat jij zegt: "Once you're in the vault all bets are off".

Ik twijfel sterk of al deze maatregelen wel "de moeite waar zijn", hoewel dat begrip natuurlijk relatief is..

[To_Tall]

Ik ben geen developer, Maar is het niet mogelijk om de encrytie key niet te parsen via een tokken? Zoals RSA, of met een SMS??

De SMS is dan je encryptie token, als je die in een goed weet te genereren, via b.v 6 alfanumeriek. Of zelf met wat de Rabo gebruikt indetiefier... zal je denk redelijk ver komen..

Ik weet alleen niet of MYSQL hier wel geschikt voor is.. Soort gelijk systeem heb ik wel gehad op SharePoint DB 2010 en MSSQL 08 r2

[keejoz]

Als je in de database raakt (Injection oid) dan zit je nog niet automatisch in het file system hoor.. Lijkt me een prima oplossing.

[Verwijderd]

To_Tall schreef op dinsdag 27 maart 2012 @ 22:27:
Ik ben geen developer, Maar is het niet mogelijk om de encrytie key niet te parsen via een tokken? Zoals RSA, of met een SMS??

De SMS is dan je encryptie token, als je die in een goed weet te genereren, via b.v 6 alfanumeriek. Of zelf met wat de Rabo gebruikt indetiefier... zal je denk redelijk ver komen..

Ik weet alleen niet of MYSQL hier wel geschikt voor is.. Soort gelijk systeem heb ik wel gehad op SharePoint DB 2010 en MSSQL 08 r2

Als de data encrypted is met een bepaalde sleutel dan moet die sleutel die tijdens het encrypten gebruikt is ook gebruikt worden tijdens het decrypten. Die sleutel moet dus ergens opgeslagen zijn(behalve als de gebruiker deze lokaal heeft opgeslagen)... Het probleem is dat ik niet van de gebruikers kan verwachten dat zij een sleutel van minimaal 32 tekens uit hun hoofd leren...

keejoz schreef op dinsdag 27 maart 2012 @ 22:34:
Als je in de database raakt (Injection oid) dan zit je nog niet automatisch in het file system hoor.. Lijkt me een prima oplossing.

Ben ik het ergens ook wel mee eens maar feit blijft dat als ze zo ver zijn om in je DB in te breken dan is de kans imho flink aanwezig dat ze ook bij je PHP code kunnen...

[ Voor 18% gewijzigd door Verwijderd op 27-03-2012 22:41 ]

[azerty]

Verwijderd schreef op dinsdag 27 maart 2012 @ 22:40:
[...]

Als de data encrypted is met een bepaalde sleutel dan moet die sleutel die tijdens het encrypten gebruikt is ook gebruikt worden tijdens het decrypten. Die sleutel moet dus ergens opgeslagen zijn(behalve als de gebruiker deze lokaal heeft opgeslagen)... Het probleem is dat ik niet van de gebruikers kan verwachten dat zij een sleutel van minimaal 32 tekens uit hun hoofd leren...

Het eerste wat dan in mij op komt: local-storage met HTML5. Natuurlijk, als de pc van die gebruiker crasht is hij al zijn versleutelde data ook kwijt

[RobIII]

keejoz schreef op dinsdag 27 maart 2012 @ 22:34:
Als je in de database raakt (Injection oid) dan zit je nog niet automatisch in het file system hoor..

Dat is ook nergens beweerd; mijn punt was dat je beter wat extra energie steekt in 't "niet in de db kunnen raken" i.t.t. de gegevens die erin staat encrypten (en daarbij zei ik ook nog dat er, tot op bepaalde hoogte, ook nog wel iets voor encrypten te zeggen is).

wsitedesign schreef op dinsdag 27 maart 2012 @ 22:42:
Het eerste wat dan in mij op komt: local-storage met HTML5. Natuurlijk, als de pc van die gebruiker crasht is hij al zijn versleutelde data ook kwijt

Ik neem aan dat degene die de DB beheert ook nog iets met die gegevens wil/moet kunnen of dat juist centralisatie het doel is van de applicatie; waarom zou je anders überhaupt een server-side oplossing kiezen of die gegevens opslaan? Hoe je bij localstorage uit komt zie ik dan ook niet helemaal... Maar het is natuurlijk wel goed voor de buzzword-bingo Gebruik dan ook meteen XML om 't in local-storage op te slaan, dat was rond y2k ook zo'n lekkere buzz Oeh, was "cloud" al genoemd?

[ Voor 44% gewijzigd door RobIII op 27-03-2012 22:49 ]

[Verwijderd]

wsitedesign schreef op dinsdag 27 maart 2012 @ 22:42:
[...]


Het eerste wat dan in mij op komt: local-storage met HTML5. Natuurlijk, als de pc van die gebruiker crasht is hij al zijn versleutelde data ook kwijt

Dat kwam ook in mij op en dan nog ergens een sleutel lekker ouderwets op papier geschreven in een kluis bewaren, maar ja, dat gaat wel heel ver..

Ik wordt nogal eens paranoide genoemd in mijn "beveiligingsdriften" vandaar ben ik erg benieuwd naar jullie menigen

[azerty]

RobIII schreef op dinsdag 27 maart 2012 @ 22:42:
[...]

Dat is ook nergens beweerd; mijn punt was dat je beter wat extra energie steekt in 't "niet in de db kunnen raken" i.t.t. de gegevens die erin staat encrypten (en daarbij zei ik ook nog dat er, tot op bepaalde hoogte, ook nog wel iets voor encrypten te zeggen is).


[...]

Ik neem aan dat degene die de DB beheert ook nog iets met die gegevens wil/moet kunnen of dat juist centralisatie het doel is van de applicatie; waarom zou je anders überhaupt een server-side oplossing kiezen of die gegevens opslaan? Hoe je bij localstorage uit komt zie ik dan ook niet helemaal... Maar het is natuurlijk wel goed voor de buzzword-bingo Gebruik dan ook meteen XML om 't in local-storage op te slaan, dat was rond y2k ook zo'n lekkere buzz Oeh, was "cloud" al genoemd?

Ik doelde puur op het opslaan lokaal van de AES key, zodat de eindgebruiker hem niet moet onthouden, niet om alle gegevens lokaal op te slaan. Natuurlijk kan de dev dan niets meer met de gegevens, dat is correct, maar dat is de afweging die gemaakt moet worden veronderstel ik?

[Verwijderd]

Precies, dat is de afweging..

De klant wil vanaf verschillende computers gebruik kunnen maken van de applicatie zonder daar naast de 2-factor login nog andere stappen voor te moeten maken, dus de local strage van HTML 5 is ook geen optie..