Защита на базата данни 101:Разбиране на привилегиите за достъп до база данни

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

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

Заплахите за бази данни като цяло имат многобройни и обширни сектори за разглеждане и изследване. Въпреки това, най-честите причини са кражба на данни и пробиви на данни. Друга често срещана заплаха са обширните привилегии или достъп до бази данни, неправилно присвоени и/или предоставени на потребител. Защитата на целия хост на сървъра е грижа за всеки, който управлява база данни. Затегна сигурността ви и се справя с всички видове приложими атаки като подслушване, промяна, възпроизвеждане и отказ на услуга (DDoS) не само за базата данни, но и за целия й основен стек, който има достъп или който взаимодейства с вашето съхранение на данни.

В този блог ще обсъдим степента на необходимост защо трябва да разбирате и да имате привилегии за достъп до базата данни.

Опасности от грешни привилегии за достъп

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

Най-важният момент за осигуряване на вашите привилегии за достъп е нивото на разбиране на сигурността между вашите инженери, като администратор на база данни, инженер по сигурността или администратор на сървър. Ако разбирането е лошо или липсват познания и опит, особено за най-актуалните уязвимости и експозиции, това може да бъде проблем за организацията или компанията.

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

В този раздел нека видим някои често срещани причини за тези заплахи за сигурността.

Привилегия за споделяне на root достъп

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

Например, потребител, който има root достъп, може да причини много щети, като например премахване на всичките ви данни от вашето физическо устройство за съхранение, нулиране на root паролата, създаване на свой собствен потребител/парола, която изглежда като законен потребител (може да се използва много дълго време за събиране на данни, освен ако не бъде хванат рано), sudo за друг потребител на ОС, като потребител на postgres, и много по-страшни неща, на които натрапникът може да се наслади.

Ако използвате MongoDB, потребител с root достъп може да влезе във вашия сървър на база данни. Докато натрапникът може да намери вашия /etc/mongod.conf или вашия конфигурационен файл mongodb и да намери пътя на вашия ключ, е лесно да влезете. Например, използването на тази команда ви позволява да влезете,

[[email protected] ~]# mongo -u __system -p "$(tr -d '\011-\015\040' < /etc/mongo-cluster.key)" --authenticationDatabase local --eval "db.adminCommand( { listDatabases: 1, nameOnly:1 } )"

Помислете за нормална инсталация на MySQL, root достъпът може да бъде оставен без парола за локален достъп. Лесно е да получите достъп, след като сте root. Достъпът до файлове като $HOME/.my.cnf или разглеждането на съдържанието на /etc/my.cnf ще ви накара да получите лесен достъп.

Настоятелно се препоръчва да ограничите само или просто да дадете своя root достъп y на най-малкия брой хора, които работят директно със сървъра за актуализиране на пакетите, актуализации на защитата и прилагане на корекции, които се изискват от екипа за разработка.

Правилно използване на sudoers

Основният софтуер за бази данни с отворен код като PostgreSQL, MySQL/MariaDB, MongoDB изисква създаване на конкретен потребител на ОС. Потребителят на ОС изисква специфична роля, ограничена, за да позволи управлението на неговите възможности в рамките на функционалността на базата данни. Трябва да бъдат зададени правилни разрешения за четене и запис за основния път на устройството за съхранение. Въпреки това, има случаи, че някои, които използват тези конкретни потребители за софтуер за база данни, имат sudo привилегии, които също могат да осъществят достъп до потребителя, определен единствено за достъп до база данни. Потребителските привилегии в операционната система трябва да бъдат ограничени и е най-добре да ограничите достъпа й въз основа на ролята. Например, за Percona Server CVE-2016-6664, въпреки че това е отстранено, този тип уязвимост е пример за възможна атака от конкретен потребител, който има достъп до MySQL акаунта и получава root достъп. Потребителите на Sudo трябва да бъдат прегледани и накарани да разберат, че ролята е ограничена само за извършване на конкретна работа.

Активирането на система за одит на Linux, като auditd, може да помогне за подобряване на сигурността, тъй като повишава пренебрегваните привилегии за достъп на ниво ОС, което може да доведе до уязвимости в сигурността на вашата база данни. SELinux и AppArmor са добри примери за модули за сигурност за вашата Linux среда, които хостват вашата система от бази данни, за да ви помогнат да подобрите сигурността ви срещу натрапници или пробиви, които биха довели до застрашаване на вашите данни.

Предоставяне на права за достъп до база данни

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

Привилегии за общ достъп

Вашите най-често използвани привилегии ще се основават на тези три категории:

Може да чете/намира като SELECT, SHOW VIEW, FIND
Възможност за вмъкване/актуализация/изтриване, като INSERT, UPDATE, DELETE, REMOVE
Може да извършва административни действия като СЪЗДАВАНЕ НА ПОТРЕБИТЕЛ, СЪЗДАВАНЕ НА РОЛЯ, ПРОМЕНИ, РЕПЛИКАЦИЯ, ИЗПУСКАНЕ НА ПОТРЕБИТЕЛ/ТАБЛИЦИ/ СХЕМИ, операции за убиване и др.

Тези категории могат да бъдат разширени до по-усъвършенствани привилегии въз основа на вашия контролен списък за сигурност. Добре е да се определи конкретен потребител, който да бъде създаден със специфични привилегии за конкретна задача. Например, едно приложение може да има множество потребители със собствени определени привилегии. Въпреки че приложението може да бъде толкова сложно с този тип изпълнение. Има случаи, че свързаността на потребител може да бъде ресурсоемка, като например използването на ORM като Hibernate. От друга страна, това зависи от архитектурния дизайн на вашето приложение. Целта на базата за всеки потребител в приложението може да помогне за поддържането на по-прецизно привилегия за достъп до база данни и да се избегне увреждане на вашите данни от нежелани изтривания, актуализации или SQL инжекция, атакуваща вашата база данни.

В повечето случаи едно приложение използва един потребител, за да се свърже с базата данни, което е ограничено само до действията му специално за изпълнение на приложението. Най-добре е да проектирате потребителските права на приложението си само за достъп за четене и запис. Докато ако са необходими административни действия, специфичен скрипт, демон или модул в достъпа на вашето приложение трябва да бъде отделен от нормалните потребители.-.

Достъпът до база данни, който трябва да се избягва

PostgreSQL и MySQL/MariaDB имат тази опция за предоставяне на потребител, използващ ВСИЧКИ привилегии. За PostgreSQL също е най-добре да имате потребител с NOSUPERUSER. Ако е възможно, това трябва да се избягва на всяка цена. Тази привилегия може да извърши повечето от всяко действие, което потенциално може да унищожи или навреди на вашите ценни данни. Можете да използвате ВСИЧКИ привилегии за вашия администраторски или root достъп, но са ограничени само до потребители, които изискват супер привилегии, за да изпълняват административни задачи и да управляват данните.

Достъп на база на таблица или схема

Добра практика е да предоставяте достъп на потребител само за необходимите таблици. . Така че, дори ако потребителят има някои административни привилегии, всяка повреда е само на ограничен набор от таблици. Или можете да зададете на цялата схема; предоставянето на достъп до ограничена таблица предоставя подробен тип привилегии и ви помага да пазите данните си от вреда.

Достъпът е ограничен само до хост

Свързването чрез неговия IP адрес на ресурса помага за ограничаване на достъпа до вашите данни. Избягвайте да използвате '%', така че в MySQL например,

GRANT SELECT, INSERT, DELETE ON mydb TO [email protected]'%' IDENTIFIED BY 'password';

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

За PostgreSQL се уверете, че сте настроили вашия pg_hba.conf и потребителя на неговия специфичен лимит само за хост. Това важи и за MongoDB, за който можете да го зададете във вашия конфигурационен файл на MongoDB или /etc/mongodb.conf. В MongoDB можете да играете с ограниченията за удостоверяване и да зададете съответно clientSource или serverAddress, но само за които изисквате клиентът или потребителят да се свърже или да бъде валидиран.

Контрол на достъп, базиран на роли

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

Въпреки че трябва да имате предвид, че ролите се обработват по различен начин във всяка база данни с отворен код. Например MySQL дефинира ролите, както следва,

Ролята в MySQL е наименувана колекция от привилегии. Подобно на потребителските акаунти, ролите могат да имат привилегии, предоставени и отнети от тях.

На потребителски акаунт могат да бъдат предоставени роли, което предоставя на акаунта привилегиите, свързани с всяка роля. Това позволява присвояване на набори от привилегии към акаунти и предоставя удобна алтернатива на предоставянето на индивидуални привилегии, както за концептуализиране на желаните привилегии, така и за прилагането им.

MongoDB дефинира ролята с RBAC като,

MongoDB използва контрол на достъпа, базиран на роли (RBAC), за да управлява достъпа до система MongoDB. На потребителя се предоставя една или повече роли, които определят достъпа на потребителя до ресурсите и операциите на базата данни. Извън назначенията на роли, потребителят няма достъп до системата.

Като има предвид, че в PostgreSQL,

PostgreSQL управлява разрешенията за достъп до базата данни, използвайки концепцията за роли. Ролята може да се разглежда като потребител на база данни или група потребители на база данни, в зависимост от това как е настроена ролята. Ролите могат да притежават обекти на база данни (например таблици и функции) и могат да присвояват привилегии върху тези обекти на други роли, за да контролират кой има достъп до кои обекти. Освен това е възможно да се предостави членство в роля на друга роля, като по този начин се позволи на ролята на член да използва привилегии, присвоени на друга роля.

Концепцията за роли включва понятията „потребители“ и „групи“. Във версиите на PostgreSQL преди 8.1 потребителите и групите бяха различни видове обекти, но сега има само роли. Всяка роля може да действа като потребител, група или и двете.

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

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

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

Система за управление на потребителите

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

ClusterControl ви помага да управлявате вашите потребители и да проверявате или проверявате привилегиите на вашия потребител от балансьорите на натоварване до основните потребители на базата данни. Той също така предлага съвети и сигнали, така че да ви уведомява за възможни уязвимости или прониквания.

Например, използването на MySQL/MariaDB с ProxySQL предварителни функции за импортиране и добавяне на потребители. За импортиране на потребители, той събира списъка с потребители, които присъстват във вашия текущ MySQL/MariaDB клъстер и ви предлага да прегледате текущите му привилегии. Вижте по-долу,

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

ClusterControl също ви предлага директно да управлявате потребители от вашата база данни, като например за MySQL/MariaDB или PostgreSQL. За MySQL/MariaDB можете да отидете на → Performance → Advisors:

Като щракнете върху бутона Редактиране, можете да персонализирате как ClusterControl ще реагира в случай, че намери потребители с някакъв хост или „%“ или потребител без парола. Вижте как се показва скриптът, след като натиснете бутона Бутон за редактиране.

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

Заключение

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