Шифроване в състояние на покой и/или AES_ENCRYPT

Шифроване в покой

Шифроването в състояние на покой са данните в базата данни, когато тя не се използва/достъп или актуализира. Шифроването в движение е неща като TLS където данните (от базата данни ) се пренася от сървър на сървър на браузър, на сървър, на браузър и т.н. TLS е напълно добър в повечето ситуации, ако се обработва внимателно и се подхожда с нагласа, че трябва да направите повече от минималния минимум за да го направи реалистично сигурен.

Типичен пример е хората, които поставят TLS сертификат от LetsEncrypt на своя домейн и си мислят, че изведнъж всичките им неща са безопасни; но не криптират своите сесии или бисквитки така оставяйки огромна потенциална дупка в защитата им.

Не използвайте вградената система за криптиране на MySQL.

Не мога да подчертая това достатъчно; вградената система за криптиране в MySQL не е подходяща за действителна сигурна защита на данните.

Моля, прочетете моя отговор на много подобен въпрос тук относно подробностите (Не искам просто да копирам/поставям ).

Добре тогава, защото настоявате... тук:

От това, което прочетох в собственото си изследване по тази тема, връзката, предоставена от Магнус към defuse/php -криптиране е един от най-добрите начини за предотвратяване на MySQL да ви кара да компрометирате данните си, като никога не позволявате на MySQL програмата/сървъра да види стойността на обикновения текст на вашите данни.

-- Отговорът е публикуван на 7 май 2017 г.

Също така отговорът на Бил Карвин на същия въпрос дава някои ценни допълнителни прозрения:

-- Отговорът е публикуван на 7 май 2017 г.

Точка на затваряне:

Сигурността е сложна. Ако искате да го направите правилно и да имате доверие в защитните си люспи от лук, тогава трябва да направите много неща (вижте куршумите по-долу); но първото нещо, което трябва да направите, е:

• Определете от кого защитавате

Сериозно. Имате нужда от различни стратегии срещу някой, който иска да открадне вашите отворени имена и адреси, срещу някой, който иска да поеме сървъра ви, срещу някой, който просто иска да изхвърли данните само защото. Мит е, че можете да защитавате срещу всички през цялото време, като концепция това е невъзможно*; така че трябва да дефинирате най-вероятните агресори и след това да измислите как най-добре да смекчите напредъка им.

По отношение на MySQL, някои ясни препоръки:

• Дръжте SQL и PHP на един и същ сървър. Не осъществявайте отдалечен достъп до MySQL данните.

• Изключете външен достъп до SQL (така че това е localhost само)

• Обфускирайте имената на вашите таблици и колони; ако някой проникне във вашите данни и имате HDTBJ^BTUETHNUYT под колоната username тогава те знаят, че това изкривяване вероятно е потребителско име, така че имат много добро начало в опитите си да разбият криптирането ви.

• ВАЖНО :Наистина заключете достъпа до вашата маса; настройте много потребители на MySQL, всеки с минималните привилегии, за да прави това, от което се нуждае; искате потребител да чете таблицата (само ) и четете само определени таблици; потребителите да пишат в определени таблици, но нямат достъп до други таблици. Това е разделяне на загриженост, така че ако някой потребител на MySQL е компрометиран; не сте загубили автоматично всяка част от данни там.

• Използвайте услуги за криптиране на PHP. Съхранявайте ключовете за криптиране на напълно отделно място; например имате друг сървър, който използвате само за архивиране, до който можете да получите достъп само за да вземете ключовете за криптиране, следователно, ако вашият PHP/MySQL сървър е компрометиран, имате малко място да отрежете и заключите Key сървъра, така че да можете ограничаване на щетите. Ако ключовият сървър също има резервни копия, тогава наистина не сте много компрометирани (зависи от ситуацията ).

• Настройте много наблюдатели и имейл информатори, които да ви казват точно кога се изпълняват определени процеси и кои потребители на сървъра (не хора, а програми) какво правят. Така че можете да видите защо неочакван процес започва да се изпълнява в 5 сутринта, за да опитате да измерите размера на MySQL таблиците. WTF?

• Има голям потенциал вашите MySQL AES_ENCRYPT данни да бъдат "подушени", дори ако не са в покой в ​​DB, ​​но ако уебсайтът бъде компрометиран (или по-лошо, PHP кодът е несигурен), тогава атаките по време могат да работят съдържание на данни чрез търсене на времеви заявки и връщане на пакети с данни.

• Сигурността е черна дупка; в един или друг момент ще си помислите:„Сега това, направих достатъчно“. Никой никога не разполага с пълна сигурност, някои много посветени организации имат достатъчно сигурност. Трябва да разберете колко далеч сте готови да извървите, преди да преминете разстоянието.

* Защо невъзможно? Защото, за да защитите данните си от всички заплахи, през цялото време, те трябва да бъдат нечетими, неизползваеми, като хеш. Хешът е защитен от всички, през цялото време. Но хешът никога не може да бъде дехеширан.