Premiär! Fyndchans i SweClockers Månadens Drop

Krypterad data i databas, hur söka?

Permalänk
Medlem

Krypterad data i databas, hur söka?

Hej!

Jag har en PHP-applikation som ska användas av personer som jobbar med känslig data. Därav behöver jag kryptera det mesta innan det förvaras i DB. Men för att den här applikationen ska vara användarvänlig behöver denna data även vara sökbar på ett smidigt sätt, dvs wildcard-sökningar osv. Jag har tänkt skriva något eget för detta men det är förmodligen en dålig idé, då risken är rätt stor att jag missar någon viktig detalj. Det måste väl finnas någon beprövad och smart lösning som löser detta åt mig. Jag känner inte till några bra lösningar och skulle behöva lite hjälp med hur jag kan lösa detta.
Är även lite osäker över vilka sökord jag kan använda mig av för att googla efter detta.

Tacksam för all information.

Permalänk

Du kan inte bara lägga datafilerna på en krypterad partition, och ge endast din databasmjukvara läs/skrivrättigheter?
Då är filerna krypterade, men access via databasen funkar precis som vanligt.

Permalänk
Medlem
Skrivet av Awakeruad:

Du kan inte bara lägga datafilerna på en krypterad partition, och ge endast din databasmjukvara läs/skrivrättigheter?
Då är filerna krypterade, men access via databasen funkar precis som vanligt.

Det låter som en bra idé. Men om lösenord och användare av DB kommer ut så är datan läsbar. Jag tror att risken för att någon ska komma åt datan utifrån är större än att någon får tag på själva servern. Men jag kanske har fel

Permalänk
Medlem

Det är väl bara att styra rättigheterna i applikationslagret? Du får bygga ett användarsystem med olika behörighetsnivåer och sedan mappar du dessa mot objekt eller API:er.

Permalänk
Medlem
Skrivet av Xclusiv8:

Det låter som en bra idé. Men om lösenord och användare av DB kommer ut så är datan läsbar. Jag tror att risken för att någon ska komma åt datan utifrån är större än att någon får tag på själva servern. Men jag kanske har fel

Allt går att knäcka, kryptering bygger på att det skall ta för mycket tid.

Läs på om salt+hash. Med salt'ning och hash'ning sparar i princip alla alla lösenord krypterade i databaskolumen för lösenord.

Visa signatur

Intel Core i7 8700K, MSI GeForce GTX 1080 Ti 11GB Gaming X, Samsung 960 EVO 1TB, MSI Z370 GAMING M5, Corsair 32GB (4x8GB) DDR4 3200MHz CL16 Vengeance, EVGA Supernova G3 850W

INTEL CORE I7 3930K 3.20GHZ 12MB S-2011, FRACTAL DESIGN MIDITOWER DEFINE R3, CORSAIR HX 1050W, ASUS RAMPAGE IV FORMULA, Asus STRIX GTX970, CORSAIR 16GB DDR3 DOMINATOR QUAD 1866MHZ CL9 (4X4GB) Ljud: ASUS Xonar D2X/XDT 7.1 | Elac 5.1 +förstärkare | Cambridge dacmagic plus | Astro gaming A40 | Sennheiser HD 650
You ask me if I have a god complex? Let me tell you something, I am god!

Permalänk
Medlem
Skrivet av Xclusiv8:

Det låter som en bra idé. Men om lösenord och användare av DB kommer ut så är datan läsbar. Jag tror att risken för att någon ska komma åt datan utifrån är större än att någon får tag på själva servern. Men jag kanske har fel

Se till att bara era servrar kan ansluta till databasen, blockera alla andra IP adresser.

Vad för attack scenarion ska krypteringen skydda mot? Vid SQL injections spelar det ingen roll om datan är krypterad eller inte. Lyckas en hackare hacka sig in på servern / köra egen kod på servern så spelar kryptering antagligen ingen roll (hackaren lär ha läs rättigheter till programmet = kan se vilken nyckel ni använder för (de)kryptering).

Däremot skyddar kryptering av hårddisken / varje fält mot någon som tex lyckas få tag på den fysiska hårddisken där databasen finns (förutsatt att programmet finns på en annan hårddisk som angriparen inte får tag på).

Visa signatur

Programmerare -> PHP | HTML | CSS | JS | Java.

Permalänk
Medlem

MySQL:

Lägga in:
INSERT into tblsexuelllaggning (namn, laggning) VALUES (AES_ENCRYPT('Kalle', 'minhemliganyckel'),AES_ENCRYPT('Hetro', 'minhemliganyckel'));

Söka fritext:
SELECT * FROM tblsexuelllaggning WHERE AES_DECRYPT(`laggning`,'minhemliganyckel') LIKE '%etro%';

För att dekryptera redan i MySQL:
SELECT AES_DECRYPT(namn, 'minhemliganyckel'), AES_DECRYPT(laggning, 'minhemliganyckel') from tblsexuelllaggning WHERE id = n;

Naturligtvis så får nyckeln kryddas några gånger med lite peppar och salt och skall förvaras på annan plats än där databasen förvaras.

Visa signatur

Grundregel för felsökning: Bryt och begränsa.

Permalänk
Medlem

Tänkbart nyckelord : https://en.wikipedia.org/wiki/Homomorphic_encryption
Men detta känns overkill. Blir du hackad så är troligtvis data helt öppen. Säkerhet är svårt.
Eftersom du frågar här på Swec så skulle jag nog anlita en säkerhetsexpert.

Permalänk
Skrivet av Xclusiv8:

Men om lösenord och användare av DB kommer ut så är datan läsbar.

Jag skulle bara tillåta anslutning från kända datorer, t.ex. inom domänen och via certifikat.
Men som andra har sagt, är det verkligen känsliga data så är det nog läge att fråga en expert.

Permalänk
Medlem
Skrivet av Veni:

MySQL:

Lägga in:
INSERT into tblsexuelllaggning (namn, laggning) VALUES (AES_ENCRYPT('Kalle', 'minhemliganyckel'),AES_ENCRYPT('Hetro', 'minhemliganyckel'));

Söka fritext:
SELECT * FROM tblsexuelllaggning WHERE AES_DECRYPT(`laggning`,'minhemliganyckel') LIKE '%etro%';

För att dekryptera redan i MySQL:
SELECT AES_DECRYPT(namn, 'minhemliganyckel'), AES_DECRYPT(laggning, 'minhemliganyckel') from tblsexuelllaggning WHERE id = n;

Naturligtvis så får nyckeln kryddas några gånger med lite peppar och salt och skall förvaras på annan plats än där databasen förvaras.

Hur fungerar det med loggar? Kommer frågan loggas som den är på servern eller loggas den i krypterad form?

Permalänk
Medlem
Skrivet av Xclusiv8:

Hur fungerar det med loggar? Kommer frågan loggas som den är på servern eller loggas den i krypterad form?

Absolut i klartext. Du har helt rätt. Antingen får man kompilera om MySQL så att inga loggningar tillåts utav en DB-ansvarig eller så får Ni kompilera om personen som är DB-ansvarig :).

Ett alternativ beroende på innehåll och vilka sökmöjligheter som önskas är att AES_ENCRYPT/DECRYPT data som man vill kunna fritextsöka som inte klassas som högrisk data och sedan använda applikations(de)kryptering utav övrig data, dvs fritextsökbar data krypteras via AES_ENCRYPT/DECRYPT, men så fort mer data skall plockas fram ur registret(dvs så fort steg 1 dvs sökningen är färdig) så hanteras dekrypteringen i Er egen applikation istället för utav MySQL. På så sätt så blir det svårt för en DB-ansvarig att se känslig data om denna ungtupp försöker ge sig på det riktigt viktiga innehållet.

Förstår problemet om där finns flera parter inblandade i dom olika leden och man inte har egen exklusiv kontroll utav hela flödet efter att förfrågan kommit fram till PHP applikationen som sen skall malas vidare ner i ledet.

Om Ni däremot har exklusiv tillgång till MySQL servern så stäng av all loggning och härda så att det ej går att slå på loggning och inte går att byta ut MySQL servern(de binära filerna) utan att det upptäcks per automatik(egen kompilering utav MySQL med loggningarna helt borttagna samt härdning utav filsystemet).

Där finns kanske flera punkter att kika på:

* Kryptering i dom olika leden(från användarapplikation hela vägen ner till databasdata).
* Fysisk åtkomst till servrarna.
* Fjärrmässig åtkomst till servrarna på OS nivå.
* Exponering utav den administrativa delen mot Internet.
* Härda filsystemet(kanske ha olika partitioner/lagringsenheter i läs-endast läge för att underlätta lite på vägen).
* Realtidskontroll utav härdningen.
* Validering av data.
* Slumpmässig kontroll utav härdningen på samtliga filer.
* Filtrering utav användardata.
* Hur kommer säkerhetskopieringar hanteras.
* Kommer minnesytan på den server som exponeras närmast nyttjarna att skriva över minnet(den del som innehöll den specifika nyttjarens data) i servern efter användarutloggning/inaktivitet?
* Verifiering utav användarbehörighet.
* Redundans/klustring. Olika placeringar?
* Flerfaktors-inloggning.
* Isolerad koppling mellan databas/applikationsserver och förfrågnings/presentationsserver istället för Ethernet-baserade lösningar. T.ex en 921 kb/s seriell koppling med en svart låda som innehåller en simpel liten processor med en enkel inbyggd applikation som hanterar sekundärkrypterad information(just ifall någon ungtupp tror att byta ut den mot en egen processor skulle ge klartextåtkomst till den data som förflyttar sig mellan systemen) som inte tillåter sig förändras utav fjärrkommandon mellan systemen samt utför en extra filtrering, förhindrar smitta samt förhindrar bulkstöld. Enbart förfrågningar och svar går över denna uppkoppling. Presentationsgränssnittet ligger kvar på förfrågningsservern/presentationsservern.
* Operativsystem som är till viss del redan härdade när en normal installation sker.
* Och en massa andra punkter som jag inte kommer på just nu men som man ser när man bygger den specifika lösningen.

Dold text
Visa signatur

Grundregel för felsökning: Bryt och begränsa.