Как да използвате криптиране, за да защитите вашите MongoDB данни

Сигурността на базата данни е ключов фактор, който трябва да се вземе предвид за всяко приложение, което включва изключително чувствителни данни, като финансови и здравни отчети. Защитата на данните може да бъде постигната чрез криптиране на различни нива, като се започне от самото приложение до файловете, съдържащи данните.

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

От друга страна, за SQL СУБД трябва да се дефинират колони за данните, следователно всички редове имат едни и същи колони. Човек може да реши да шифрова отделни колони, целия файл на базата данни или данни от приложението, преди да бъде включен в процеса на базата данни.

Криптирането на отделни колони е най-предпочитано, тъй като е по-евтино и се криптират по-малко данни, като по този начин се подобрява латентността. Като цяло, цялостната производителност влияе в резултат на криптирането.

За NoSQL СУБД този подход обаче няма да е най-добрият. Като се има предвид, че не всички документи може да имат всички полета, които искате да използвате във вашето криптиране, криптирането на ниво колона не може да се извърши.

Криптирането на данни на ниво приложение е доста скъпо и трудно за изпълнение. Поради това оставаме с опция за криптиране на данни на ниво база данни.

MongoDB предоставя естествено криптиране, което не изисква да плащате допълнителни разходи за защита на вашите чувствителни данни.

Криптиране на данни в MongoDB

Всяка операция с база данни включва една от тези две форми на данни, данни в покой или данни в движение.

Данните в движение са поток от данни, движещи се през всякакъв вид мрежа, докато данните в покой са статични, следователно не се движат никъде.

И двата типа данни wo са податливи на външна намеса от анонимни потребители, освен ако не е включено криптиране. Процесът на криптиране включва:

• Генериране на главен ключ за цялата база данни
• Генериране на уникални ключове за всяка база данни
• Криптиране на вашите данни с генерираните от вас ключове за база данни
• Криптиране на цялата база данни с главния ключ

Шифроване на данни при пренасяне

Данните се предават между MongoDB и сървърното приложение по два начина, а именно чрез защита на транспортния слой (TLS) и слой на защитени гнезда (SSL).

Тези два са най-използваните протоколи за криптиране за защита на изпратени и получени данни между две системи. По принцип концепцията е да се криптират връзки към mongod и mongos екземпляри, така че мрежовият трафик да се чете само от предвидения клиент.

TLS/SSL се използват в MongoDB с някои сертификати като PEM файлове, които се издават от сертифициращия орган или могат да бъдат самоподписан сертификат. Последното има ограничение, тъй като въпреки това комуникационният канал е криптиран, винаги няма валидиране срещу идентичността на сървъра, следователно уязвима за външни атаки по средата. Поради това е препоръчително да използвате сертификати за доверен орган, които позволяват на драйверите на MongoDB също да проверяват самоличността на сървъра.

Освен криптирането, TLS/SSL може да се използва за удостоверяване на клиента и вътрешни удостоверения на членове на набори реплики и разчленени клъстери чрез сертификатите.

TLS/SSL конфигурация за клиенти

Има различни настройки за опции за TLS/SSL, които могат да се използват при конфигурирането на тези протоколи.

Например, ако искате да се свържете с екземпляр на Mongod с помощта на криптиране, ще стартирате своя екземпляр като,

mongo --ssl --host example.com --sslCAFile /etc/ssl/ca.pem

--ssl активира TLS/SSL връзката.

--sslCAFile указва pem файла на сертифициращия орган (CA) за проверка на сертификата, представен от mongod или mongos. Следователно обвивката на Mongo ще провери сертификата, издаден от екземпляра mongod, спрямо посочения CA файл и името на хоста.

Може също да искате да свържете екземпляр на MongoDB, който изисква клиентски сертификат. Използваме примерния код по-долу

mongo --ssl --host hostname.example.com --sslPEMKeyFile /etc/ssl/client.pem --sslCAFile /etc/ssl/ca.pem

Опцията --sslPEMKeyFile указва .pem файла, който съдържа сертификата на mongo shell и ключ за представяне на mongod или mongos екземпляр. По време на процеса на свързване:

Обвивката mongo ще провери дали сертификатът е от посочения сертифициращ орган, който е (--sslCAFile) и ако не, черупката няма да успее да се свърже.

Второ, черупката също ще провери дали името на хоста, посочено в опцията --host, съвпада със SAN/CN в сертификата, представен от mongod или mongos. Ако това име на хост не съвпада с нито едно от двете, връзката ще се провали.

Ако не искате да използвате самоподписани сертификати, трябва да се уверите, че мрежата за връзка е надеждна.

Освен това, трябва да намалите излагането на частния ключ, особено когато участват набори от реплики/разчленен клъстер. Това може да се постигне чрез използване на различни сертификати на различни сървъри.

Допълнителни опции, които могат да се използват в връзките са:

изисква SSL:това ще ограничи всеки сървър да използва само TLS/SSL криптирани връзки.

--sslAllowConnectionsWithoutCertificates:Това позволява валидиране, ако само клиентът представи сертификат, в противен случай, ако няма сертификат, клиентът все още ще бъде свързан в криптиран режим. Например:

mongod --sslMode requireSSL --sslAllowConnectionsWithoutCertificates --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

sslDisabledProtocols:тази опция не позволява на сървърите да приемат входящи връзки, които използват специфични протоколи. Това може да стане с:

mongod --sslMode requireSSL --sslDisabledProtocols TLS1_0,TLS1_1 --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

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

От версия 3.2, MongoDB въведе собствена опция за криптиране за машината за съхранение на WiredTiger. Достъпът до данните в това хранилище от трета страна може да бъде постигнат само чрез ключ за декриптиране за декодиране на данните в четим формат.

Често използвания алгоритъм за криптиране в MongoDB е AES256-GCM. Той използва същия таен ключ за криптиране и декриптиране на данни. Шифроването може да се включва с помощта на режим FIPS, като по този начин се гарантира, че криптирането отговаря на най-високия стандарт и съответствие.

Целите файлове на базата данни са криптирани с помощта на прозрачно криптиране на данни (TDE) на ниво съхранение.

Всеки път, когато файлът е криптиран, се генерира уникален частен ключ за криптиране и е добре да се разбере как тези ключове се управляват и съхраняват. Всички генерирани ключове на базата данни след това се криптират с главен ключ.

Разликата между ключовете на базата данни и главния ключ е, че ключовете на базата данни могат да се съхраняват заедно със самите криптирани данни, но за главния ключ, MongoDB съветва той да се съхранява на различен сървър от криптираните данни, като корпоративен ключ на трета страна решения за управление.

При репликирани данни критериите за криптиране не се споделят с другите възли, тъй като данните не са естествено криптирани по кабела. Човек може да използва повторно същия ключ за възлите, но най-добрата практика е да се използват уникални индивидуални ключове за всеки възел.

Въртящи се ключове за криптиране

Управляваният ключ, използван за декриптиране на чувствителни данни, трябва да се сменя или сменя поне веднъж годишно. Има две опции в MongoDB за постигане на ротация.

Основна ротация на KMIP

В този случай се променя само главният ключ, тъй като се управлява външно. Процесът за завъртане на ключа е както е описано по-долу.

1. Главният ключ за вторичните членове в набора реплика се завърта един по един. т.е.

   mongod --enableEncryption --kmipRotateMasterKey \ --kmipServerName <KMIP Server HostName> \--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

   След като процесът приключи, mongod ще излезе и ще трябва да рестартирате вторичния без параметър kmipRotateMasterKey

   mongod --enableEncryption --kmipServerName <KMIP Server HostName> \
     --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

2. Основният набор от реплики се намалява:
   С помощта на метода rs.stepDown() основният се деактивира, като по този начин се принуждава избор на нов първичен.

3. Проверете състоянието на възлите с помощта на метода rs.status() и ако основният показва, че е бил намален, завъртете главния му ключ. Рестартирайте намаления член, включително опцията kmipRotateMasterKey.

   mongod --enableEncryption --kmipRotateMasterKey \
     --kmipServerName <KMIP Server HostName> \
     --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

Регистриране

MongoDB винаги работи с регистрационен файл за запис на някакво състояние или определена информация на различни интервали.

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

От MongoDB версия 3.4 има настройката security.redactClientLogData, която предотвратява записването на потенциално чувствителни данни в дневника на процеса на mongod. Тази опция обаче може да усложни диагностиката на журнала.

Ефективност на криптиране в MongoDB

Шифроването в даден момент води до повишена латентност, което влошава производителността на база данни. Това обикновено се случва, когато става въпрос за голям обем документи.

Шифроването и декриптирането изискват повече ресурси, следователно е важно да се разбере тази връзка, за да се коригира съответно планирането на капацитета.

По отношение на тестовете на MongoDB, криптирана машина за съхранение ще изпита латентност между 10% до 20% при най-високо натоварване. Това често се случва, когато потребителят записва голямо количество данни в базата данни, което води до намалена производителност. При операции за четене влошаването на производителността е незначително, около 5 - 10%.

За по-добра практика на криптиране в MongoDB, механизмът за съхранение на WiredTiger е най-предпочитан поради неговата висока производителност, сигурност и мащабируемост. Освен това, той оптимизира криптирането на файловете на базата данни на ниво страница, което има голямо предимство в това, че ако потребителят чете или запише данни в криптираната база данни, операцията за пропускателна способност ще бъде приложена само към страницата, на която се съхраняват данните, а не към цялата база данни.

Това ще намали количеството данни, които ще трябва да бъдат криптирани и декриптирани за обработка на една част от данни.

Резюме

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

MongoDB предоставя стабилни естествени процедури за криптиране, които могат да ни помогнат да защитим данните си както в покой, така и в движение. Освен това процедурите за криптиране трябва да отговарят на определените стандарти от различни организации.

Усъвършенстваният механизъм за съхранение на WiredTiger предоставя по-добър вариант поради свързаните с него предимства като висока производителност, мащабируемост и сигурност. Когато криптирате данни в набори от реплики, е добра практика да използвате различни главни ключове за всеки, освен да ги променяте поне веднъж годишно.

Въпреки това наличието на опции за криптиране на трети страни, няма гаранция, че вашето внедряване ще съвпада с тях по отношение на мащабируемост. Поради това е доста внимателно да се използва криптиране на ниво база данни.