Encryptie in rust en/of AES_ENCRYPT

Encryptie in rust

Encryptie in rust zijn de gegevens in de database wanneer deze niet worden gebruikt/geopend of bijgewerkt. Encryptie onderweg is zaken als TLS waar de gegevens (uit de database ) wordt getransporteerd van server naar server naar browser, naar server, naar browser, enz. TLS is perfect in de meeste situaties als het zorgvuldig wordt behandeld en benaderd met een houding dat je meer moet doen dan het absolute minimum om het echt realistisch te beveiligen.

Een typisch voorbeeld is dat mensen een TLS-certificaat van LetsEncrypt op hun domein zetten en denken dat al hun spullen ineens veilig zijn; maar ze versleutelen hun sessies of hun cookies niet dus laten ze een enorm potentieel gat in hun verdediging achter.

Gebruik het ingebouwde coderingssysteem van MySQL niet.

Ik kan dit niet genoeg benadrukken; het ingebouwde coderingssysteem in MySQL is niet geschikt voor daadwerkelijke veilige gegevensbescherming.

Lees mijn antwoord op een zeer vergelijkbare vraag hier wat betreft de details (Ik wil niet zomaar kopiëren/plakken ).

Ok dan, omdat je erop staat... hier:

Van wat ik heb gelezen in mijn eigen onderzoek over dit onderwerp, is de link die door Magnus is verstrekt naar defuse/php -encryptie is een van de beste manieren om te voorkomen dat MySQL u ooit uw gegevens in gevaar brengt, door het MySQL-programma/server nooit de leesbare tekst van uw gegevens te laten zien.

-- Beantwoord zoals gepost op 7 mei 2017.

Ook Bill Karwins antwoord op dezelfde vraag geeft waardevolle aanvullende inzichten:

-- Beantwoord zoals gepost op 7 mei 2017.

Sluitingspunt:

Beveiliging is complex. Als je het goed wilt doen en vertrouwen hebt in je beschermende uienschillen, dan moet je veel dingen doen (zie opsommingstekens hieronder); maar het eerste wat je moet doen is:

• Definieer tegen wie u beschermt

Ernstig. U hebt verschillende strategieën nodig tegen iemand die uw namen en adressen in platte tekst wil stelen versus iemand die uw server wil overnemen of iemand die simpelweg de gegevens wil weggooien, alleen maar omdat. Het is een mythe dat je je altijd tegen iedereen kunt beschermen, per concept is dit onmogelijk*; dus je moet de meest waarschijnlijke agressors definiëren en vervolgens uitzoeken hoe je hun agressiviteit het beste kunt beperken.

Specifiek voor MySQL, enkele duidelijke aanbevelingen:

• Houd de SQL en de PHP op dezelfde server. Geen externe toegang tot de MySQL-gegevens.

• Sluit externe toegang tot de SQL uit (dus het is localhost alleen)

• Verdoezel uw tabelnamen en kolomnamen; als iemand inbreekt in uw gegevens en u heeft HDTBJ^BTUETHNUYT onder de kolom username dan weten ze dat deze onleesbaarheid waarschijnlijk een gebruikersnaam is, dus ze hebben een zeer goede start bij het proberen om uw codering te doorbreken.

• BELANGRIJK :Vergrendel uw tafeltoegang echt; stel veel MySQL-gebruikers in, elk met alleen de absolute minimumrechten om te doen wat ze nodig hebben; u wilt dat een gebruiker de tabel leest (alleen ) en lees alleen bepaalde tabellen; gebruikers om naar bepaalde tabellen te schrijven, maar hebben geen toegang tot andere tabellen. Het is een scheiding van zorg, zodat als een gebruiker op de MySQL wordt gecompromitteerd; je bent niet automatisch alle gegevens daarin kwijt.

• Gebruik PHP-coderingsservices. Bewaar coderingssleutels op een volledig aparte plaats; heb bijvoorbeeld een andere server die u uitsluitend gebruikt voor back-up waartoe u alleen toegang hebt om de coderingssleutels te pakken, dus als uw PHP/MySQL-server is gecompromitteerd, heeft u wat ruimte om de sleutelserver af te sluiten en te vergrendelen, zodat u kunt de schade beperken. Als de sleutelserver ook back-ups heeft, ben je echt niet al te erg gecompromitteerd (afhankelijk van de situatie ).

• Stel veel kijkers en e-mailinformanten in om u precies te vertellen wanneer bepaalde processen worden uitgevoerd en welke servergebruikers (geen mensen maar programma's) wat doen. U kunt dus zien waarom een ​​onverwacht proces om 5 uur 's ochtends begint om te proberen de grootte van de MySQL-tabellen te meten. WTF?

• Er is veel potentieel om uw MySQL AES_ENCRYPT-gegevens te laten "snuiven", zelfs als deze zich niet in de DB bevinden, maar als de website wordt gecompromitteerd (of erger nog, de PHP-code is onveilig), dan kunnen timingaanvallen werken gegevensinhoud door zoekopdrachten en gegevenspakketretouren te timen.

• Beveiliging is een zwart gat; op een gegeven moment ga je denken "Zod dit, ik heb genoeg gedaan". Niemand heeft ooit totale beveiliging, sommige zeer toegewijde organisaties hebben genoeg beveiliging. Je moet uitzoeken hoe ver je bereid bent te lopen voordat je de afstand hebt afgelegd.

* Waarom onmogelijk? Want om uw gegevens te allen tijde tegen alle bedreigingen te beschermen, zou het onleesbaar, onbruikbaar, als een hash moeten zijn. Een hash is altijd en voor iedereen beschermd. Maar een hash kan nooit ongedaan worden gemaakt.