Kryptering i hvile og/eller AES_ENCRYPT

Kryptering i hvile

Encryption at rest er dataene i databasen, når de ikke bliver brugt/adgang til eller opdateret. Kryptering på farten er ting som TLS hvor dataene (fra databasen ) transporteres fra server til server til browser, til server, til browser osv. TLS er perfekt i de fleste situationer, hvis det håndteres forsigtigt og behandles med en holdning om, at du skal gøre mere end det absolutte minimum for rent faktisk at gøre det realistisk sikkert.

Et typisk eksempel er, at folk sætter et TLS-certifikat fra LetsEncrypt på deres domæne og tror, ​​at pludselig er alle deres ting sikre; men de krypterer ikke deres sessioner eller deres cookies så de efterlader et massivt potentielt hul i deres forsvar.

Brug ikke MySQL's indbyggede krypteringssystem.

Jeg kan ikke understrege dette nok; det indbyggede krypteringssystem i MySQL er ikke egnet til egentlig sikker databeskyttelse.

Læs venligst mit svar på et meget lignende spørgsmål her med hensyn til detaljerne (Jeg vil ikke bare kopiere/indsætte ).

Ok, så fordi du insisterer... her:

Fra hvad jeg har læst i min egen forskning om dette emne, er linket fra Magnus til defuse/php -kryptering er en af ​​de bedste måder at forhindre, at MySQL nogensinde får dig til at kompromittere dine data, ved aldrig at lade MySQL-programmet/serveren nogensinde se klartekstværdien af ​​dine data.

-- Svar som offentliggjort den 7. maj 2017.

Også Bill Karwins svar på samme spørgsmål giver nogle værdifulde yderligere indsigter:

-- Svar som offentliggjort den 7. maj 2017.

Lukkepunkt:

Sikkerhed er kompleks. Hvis du vil gøre det ordentligt og have tillid til dine beskyttende løgskind, skal du gøre en masse ting (se punkttegn nedenfor); men det første du skal gøre er:

• Definer, hvem du beskytter mod

Helt seriøst. Du har brug for forskellige strategier mod en person, der ønsker at stjæle dine almindelige tekstnavne og adresser i forhold til nogen, der ønsker at overtage din server versus nogen, der blot ønsker at smide dataene ud, bare fordi. Det er en myte, at du kan beskytte dig mod alle hele tiden, efter konceptet er dette umuligt*; så du skal definere de mest sandsynlige aggressorer og derefter finde ud af, hvordan du bedst kan afbøde deres fremskridt.

Sepcifically til MySQL, nogle klare anbefalinger:

• Hold SQL og PHP på samme server. Fjern ikke adgang til MySQL-data.

• Ekskluder ekstern adgang til SQL (så det er localhost). kun)

• Slør dine tabelnavne og kolonnenavne; hvis nogen bryder ind i dine data, og du har HDTBJ^BTUETHNUYT under kolonnen username så ved de, at denne forvanskning sandsynligvis er et brugernavn, så de har en meget god start med at forsøge at bryde din kryptering.

• VIGTIG :Virkelig låse din bordadgang; opsætte masser af MySQL-brugere, hver med kun de absolutte minimumsrettigheder til at gøre, hvad de har brug for; du vil have en bruger til at læse tabellen (kun ) og kun læse visse tabeller; brugere til at skrive til bestemte tabeller, men har ingen adgang til andre tabeller. Det er adskillelse af bekymring, så hvis en bruger på MySQL er kompromitteret; du har ikke automatisk mistet alle stykker data derinde.

• Brug PHP encrpytion-tjenester. Gem krypteringsnøgler på et helt separat sted; for eksempel har en anden server, du udelukkende bruger til backup, som du kun kan få adgang til for at række ud for at få fat i krypteringsnøglerne, så hvis din PHP/MySQL-server er kompromitteret, har du lidt plads til at afskære og låse nøgleserveren ned, så du kan begrænse skaden. Hvis nøgleserveren også har sikkerhedskopier, er du virkelig ikke alt for dårligt kompromitteret (situationsafhængig ).

• Indstil masser af overvågere og e-mail-informatorer til at fortælle dig præcis, hvornår bestemte processer kører, og hvilke serverbrugere (ikke personer, men programmer) der gør hvad. Så du kan se, hvorfor en uventet proces begynder at køre kl. 05.00 for at prøve at måle størrelsen på MySQL-tabellerne. WTF?

• Der er et stort potentiale for at få dine MySQL AES_ENCRYPT'ede data "sniffet", selvom de ikke er i ro i DB'en, men hvis hjemmesiden bliver kompromitteret (eller værre, PHP-koden er usikker), så kan timingangreb fungere dataindhold ved at timing af forespørgselsopslag og datapakkeretur.

• Sikkerhed er et sort hul; på et eller andet tidspunkt kommer du til at tænke "Sådan, jeg har gjort nok". Ingen har nogensinde total sikkerhed, nogle meget dedikerede organisationer har nok sikkerhed. Du skal regne ud, hvor langt du er villig til at gå, før du har gået distancen.

* Hvorfor umuligt? For for at beskytte dine data mod alle trusler, hele tiden, skal de være ulæselige, ubrugelige, som en hash. En hash er beskyttet mod alle, hele tiden. Men en hash kan aldrig blive un-hashed.