Kryptering i vila och/eller AES_ENCRYPT

Kryptering i vila

Kryptering i vila är data i databasen när den inte används/åtkoms eller uppdateras. Kryptering på resande fot är saker som TLS där data (från databasen ) transporteras från server till server till webbläsare, till server, till webbläsare etc. TLS är perfekt i de flesta situationer om det hanteras försiktigt och närmar sig med en attityd att du behöver göra mer än det absoluta minimum för att faktiskt göra det realistiskt säkert.

Ett typiskt exempel är människor som sätter på ett TLS-certifikat från LetsEncrypt på sin domän och tror att plötsligt är alla deras grejer säkra; men de krypterar inte sina sessioner eller sina cookies så lämnar ett enormt potentiellt hål i deras försvar.

Använd inte MySQL:s inbyggda krypteringssystem.

Jag kan inte nog betona detta; det inbyggda krypteringssystemet i MySQL är inte lämpligt för faktiskt säkert dataskydd.

Läs mitt svar på en mycket liknande fråga här när det gäller detaljerna (Jag vill inte bara kopiera/klistra in ).

Ok, då, för att du insisterar... här:

Från vad jag har läst i min egen forskning om detta ämne, länken från Magnus till defuse/php -kryptering är ett av de bästa sätten att förhindra att MySQL någonsin får dig att äventyra dina data, genom att aldrig låta MySQL-programmet/servern någonsin se klartextvärdet av dina data.

-- Svar som postat 7 maj 2017.

Även Bill Karwins svar på samma fråga ger några värdefulla ytterligare insikter:

-- Svar som postat 7 maj 2017.

Stängningspunkt:

Säkerheten är komplex. Om du vill göra det ordentligt och ha ett förtroende för dina skyddande lökskal måste du göra en massa saker (se punkter nedan); men det första du behöver göra är:

• Definiera vem du skyddar mot

Allvarligt. Du behöver olika strategier mot någon som vill stjäla dina namn och adresser i klartext jämfört med någon som vill ta över din server kontra någon som helt enkelt vill kasta data bara för att. Det är en myt att du kan skydda mot alla hela tiden, av konceptet är detta omöjligt*; så du måste definiera de mest sannolika angriparna och sedan ta reda på hur du bäst kan mildra deras framsteg.

Specifikt till MySQL, några tydliga rekommendationer:

• Behåll SQL och PHP på samma server. Få inte fjärråtkomst till MySQL-data.

• Uteslut extern åtkomst till SQL (så det är localhost). endast)

• Obfuskera dina tabellnamn och kolumnnamn; om någon bryter sig in i din data och du har HDTBJ^BTUETHNUYT under kolumnen username då vet de att den här förvanskningen förmodligen är ett användarnamn så de har en mycket bra start på att försöka bryta din kryptering.

• VIKTIGT :Lås verkligen ner din bordsåtkomst; ställ in massor av MySQL-användare, var och en med endast de absoluta minimirättigheterna att göra vad de behöver; du vill att en användare ska läsa tabellen (endast ) och bara läsa vissa tabeller; användare att skriva till vissa tabeller men har ingen tillgång till andra tabeller. Det är separation av oro så att om någon användare på MySQL äventyras; du har inte automatiskt förlorat varje bit av data därinne.

• Använd PHP encrpytion tjänster. Lagra krypteringsnycklar på en helt separat plats; till exempel har en annan server som du använder enbart för säkerhetskopiering som du kan komma åt enbart för att nå ut för att ta tag i krypteringsnycklarna, därför om din PHP/MySQL-server äventyras har du lite utrymme att skära av och låsa nyckelservern så att du kan begränsa skadan. Om nyckelservern också har säkerhetskopior är du verkligen inte alltför komprometterad (situationsberoende ).

• Ställ in många tittare och e-postinformatörer för att berätta exakt när vissa processer körs och vilka serveranvändare (inte personer utan program) som gör vad. Så du kan se varför en oväntad process börjar köras klockan 05:00 för att försöka mäta storleken på MySQL-tabellerna. WTF?

• Det finns en stor potential att få din MySQL AES_ENCRYPT-editerade data "sniffad" även om den inte är i vila i DB, men om webbplatsen äventyras (eller ännu värre, PHP-koden är osäker) kan tajmingsattacker fungera datainnehåll genom att tidsstyra sökfrågor och returer av datapaket.

• Säkerhet är ett svart hål; vid ett eller annat tillfälle kommer du att tänka "Så här, jag har gjort nog". Ingen har någonsin total säkerhet, vissa mycket dedikerade organisationer har nog säkerhet. Du måste räkna ut hur långt du är villig att gå innan du har gått sträckan.

* Varför omöjligt? För att skydda din data från alla hot, hela tiden, skulle den behöva vara oläsbar, oanvändbar, som en hash. En hash är skyddad från alla, hela tiden. Men en hash kan aldrig avhaschas.