Сигурността е от първостепенно значение днес в целия IT. От време на време чуваме за атаки на ransomware или течове на данни, които произхождат от незащитени бази данни или ИТ инфраструктура. Може да се чудите:кои са най-добрите практики в архитектурата на MySQL среда, така че да се чувствате сигурни за вашите данни? Ако е така, този блог е за вас. Моля, имайте предвид, че няма да разгледаме темата изцяло - това би се поместило повече в бяла книга, отколкото в блог. Ще направим всичко възможно да споменем най-важните аспекти на защитата на вашата MySQL база данни. Идеята зад този блог е читателят да знае какво не знае и да му помогне да идентифицира темите и ключовите думи за по-нататъшно изследване. Ще го илюстрираме с екранни снимки от нашия продукт ClusterControl, който се предлага с огромен набор от функции, включително някои относно сигурността на базата данни.
Мрежа
На първо място, трябва да внедрим MySQL някъде. Независимо дали става дума за самостоятелен екземпляр, асинхронна реплика на първична реплика или една от по-напредналите топологии за синхронна репликация като Galera или InnoDB Cluster. Без значение какъв е, той трябва да бъде защитен на мрежово ниво. Базата данни съдържа данните, които доста често са най-ценният актив на цялата организация.
Осигуряване на достъпа
Екземплярите на базата данни никога не трябва да се намират в публичната мрежа. Мрежовите сегменти, в които са конфигурирани бази данни, трябва да бъдат достъпни само от ограничен брой други мрежи. Основното правило е - трябва ли даден възел да има достъп до мрежата на базата данни? Ако отговорът е не, мрежите трябва да бъдат разделени.
Разбира се, всичко зависи от точната настройка, но в най-честите случаи, когато имате слоеве на приложение, прокси, кеш и база данни, най-типичната настройка би била, че само проксито трябва да може за достъп до базата данни. Всички други обекти трябва да бъдат конфигурирани така, че да имат достъп до базата данни само чрез прокси слой. Този дизайн е добър в много отношения. Освен повишената сигурност, той също помага да се скрие сложността на нивото на базата данни от приложението.
Прокси слоят трябва да следва топологията на базата данни и трябва да обработва грешките на възлите на базата данни и промените в топологията. Приложението, свързващо се с прокси слоя, винаги трябва да може да достигне до работещ възел на базата данни, свързан с типа на заявката. Същото е и със слоя кеш. Може да бъде внедрен в прокси слоя, някои прокси сървъри като ProxySQL позволяват заявки за кеш в прокси сървъра, но ако това е отделен слой, изграден около, например memcache или Redis, той винаги трябва да достига до базата данни чрез прокси слоя.
Още един тип възли, които може да се наложи да имат директен достъп до слоя на базата данни, са възли за управление – тези, които се използват от оперативните екипи за управление на базите данни. Причината е проста:някои от задачите за поддръжка може да изискват директен достъп до базите данни. Това могат да бъдат скриптове за автоматизация на задачи, ролкови книги на Ansible в цялата база данни или други задачи. В такъв случай, очевидно, трябва да бъдат въведени мерки за сигурност, за да се гарантира, че само хората, които имат достъп, могат да влизат в такъв възел за управление.
Друг възможен тип възли (въпреки че възли за управление също могат да се използват за това), които може да изискват достъп до базата данни, са възлите, участващи в събирането на показатели и представянето им на потребителите - тук говорим за наблюдение и алармиращи дейности.
VPN
За всякакъв вид ниво на база данни, обхващащо множество центрове за данни, трябва да обмислите използването на VPN, за да ги свържете. Отворените, некриптирани връзки през WAN мрежа са нещо, което никога не трябва да се случва. Дори настройката на SSL криптиране не е най-добрият вариант, тъй като ще изисква отваряне на достъп между нивото на базата данни и WAN - SSL връзките между възлите на базата данни изискват те да могат да се свързват директно. VPN решава този проблем, като добавя посредник, който създава сигурен начин за свързване на сегменти от мрежата от ниво база данни.
VPN също трябва да бъде задължителен за всякакъв вид потребителски достъп до мрежата на организацията, тъй като реализира защитена свързаност между работна станция и производствената мрежа.
Защитна стена
Разбира се, докато защитаваме мрежата, трябва да помислим за използването на защитната стена. Най-общо казано, всеки възел на базата данни трябва да получава връзки само от определен набор от източници - имена на хостове и портове. Дори „необходимите“ мрежови сегменти не трябва да имат пълен достъп до мрежата на базата данни, а само до необходимите портове. Ако проксито трябва да се свърже само с порта на базата данни, тогава няма причина той да има достъп до който и да е друг порт на възлите на базата данни. Моля, имайте предвид също, че не трябва да използвате портовете по подразбиране. Очевидно това е сигурност чрез неизвестност - все пак портът е отворен някъде, но помага да се справим поне с някои от проникванията в сигурността, които използват автоматизирани скриптове. Това няма да попречи на някой, който е решен да получи достъп, но може да го забави (когато е съчетано с откриване на сканиране на портове и мерки срещу сканиране), като същевременно предотвратява успеха на автоматизираните атаки.
Сигурност на базата данни
Мрежата е първата линия на защита, има други мерки за сигурност и добри практики, които можете да използвате, за да подобрите сигурността си още повече. Някои от тях могат да бъдат внедрени в самата база данни.
Потребители и хостове
Самите бази данни могат да се използват за прилагане на контрол на достъпа и ограничения. Като за начало можете да приложите базиран на хост контрол на достъпа, предотвратявайки влизането в базата данни на хостове, различни от краткия списък с възли. Разбира се, ако сте използвали защитна стена за ограничаване на достъпа, това може да звучи като дубликат, но все пак е добра идея да ограничите достъпа до самата база данни - никога не знаете кога случайно защитната стена ще бъде деактивирана. В такъв случай все още имате втори слой на защита.
Това, което искате да приложите тук, е списък с потребители и хостове на база данни, на които е разрешен достъп до базата данни. Най-вероятно това, което трябва да имате, е един или повече потребителски предоставен достъп от хостове, разположени в прокси слоя. Колко подробен контрол на достъпа може да имате зависи от системата на базата данни, която имате. MySQL, например, не позволява подробен контрол върху мрежовите маски - той просто използва /32, /24, /16 или /8. В PostgreSQL, от друга страна, можете да използвате всякакъв вид мрежова маска.
Грантове
Ако това позволява вашата база данни, всеки от потребителите трябва да има дефиниран набор от разрешения - като се гарантира, че предоставените им привилегии са минималните необходими за потребителя да изпълнява действията, които трябва да извърши . Системите за бази данни могат да имат различен набор от привилегии и различни нива от тях. Обикновено имаме няколко нива на привилегии - глобални, засягащи целия сървър на база данни, ниво на схема - даден потребител може да има различни привилегии, присвоени на различни схеми. Можете да имате привилегии на ниво таблица или дори колона. Както споменахме по-рано, целта е да се създаде минимален набор от привилегии за всеки потребител. Вероятно ще искате да имате поне един потребител с високи привилегии - той ще се използва за управление на базата данни. Този потребител трябва да бъде строго ограничен, когато става въпрос за свързаност. Не трябва (и всъщност нито един от потребителите не трябва) да се разрешава да се свързва от което и да е място - трябва да бъде или локален хост, или някакъв конкретен възел за управление, предназначен за извършване на операции с базата данни.
Управление на пароли
Всеки потребител в базата данни трябва да има дефинирана парола. Това е безсмислено. Паролата трябва да се съхранява под формата на хеш. Трябва да се уверите, че за съхраняване на паролите използвате най-сигурния хеш алгоритъм, който може да предложи вашата база данни. Паролите не трябва да са лесни за отгатване, нито трябва да са уязвими за атака с речник. Някои системи за бази данни, като MySQL, ви позволяват да дефинирате точно изискванията, на които трябва да отговарят вашите пароли, за да бъдат използвани. Малки и главни букви, цифри, специални знаци, дължина на паролата - всичко това е важно и ако можете да наложите някои правила за силата на паролата, трябва да го направите. Друг важен момент е ротацията на паролата. Паролите не трябва да се създават веднъж за цял живот на базата данни, трябва да имате политика за ротация на пароли. Отново някои от системите за бази данни могат да наложат това вместо вас. Административният потребител може да може да създава нови потребителски акаунти с наложена ротация на пароли. Той може също да е в състояние да наложи редуване на пароли за даден потребител.
Регистъри за одит
Някои от системите за бази данни предлагат регистрационни файлове за одит - идеята е да се събере възможно най-много информация за дейността в базата данни. Кой и кога какво направи? Коя заявка е изпълнена, от кого? Кой се опита да влезе, но не успя? От кой домакин? В идеалния случай логовете, съдържащи такава информация, ще се съхраняват извън възлите на базата данни. Можете да ги предавате поточно към вашия централен лог сървър за съхранение, по-нататъшна обработка и по-добри възможности за търсене.
SQL сигурност
Споменахме потребители и хостове, но атаката може да се случи и от различен източник. Ако приложението ви не е защитено правилно и въвеждането не е правилно валидирано, може да сте изправени пред атаки, произхождащи от вашия уебсайт. Тук говорим за SQL инжекция. В такъв случай защитните стени не са наистина полезни, като се има предвид, че заявката произхожда от валиден източник (вашият уеб сървър и след това прокси възел). Предоставянето на безвъзмездни средства може всъщност да помогне за предотвратяване на някои от този вид атаки, но не е идеално решение - в края на краищата вашето приложение в повечето случаи ще се нуждае от потребител, който може да премахва или променя съдържанието на базата данни. Такъв потребител, когато бъде експлоатиран, може да бъде използван за нанасяне на вреда. Има няколко начина, по които можете да опитате да се противопоставите на лакомството.
SQL защитна стена
Най-простият начин да го направите е чрез внедряване на SQL защитна стена. Може да се осъществи на различни нива и на различни места. Една от опциите е да използвате балансьори на натоварване за това. Някои от тях идват с тази функционалност, поне лесно постижима, ако вече не е внедрена. Идеята зад него е да се изгради списък със заявки, които вашето приложение изпълнява и след това да конфигурирате вашия прокси да преминава само през този вид трафик. Не е идеален, тъй като ще трябва да го поддържате навреме, като добавяте нови заявки и премахвате стари, които вече не се използват. От друга страна, такъв набор от правила ще попречи на всяка заявка, която не е оторизирана, да достигне до базата данни.
Откриване на инжектиране на SQL
Друга възможна опция би била да се внедри откриване на SQL инжектиране в прокси слоя. Има няколко решения, ProxySQL наред с други, които могат да бъдат конфигурирани да се опитват да открият SQL инжекция в трафика, който преминава през тях. Разбира се, всичко това се основава на евристика, така че може да доведе до фалшиви положителни резултати, но може да бъде добро допълнение към SQL защитната стена.
В миналото обсъдихме как можете да внедрите защитна стена на SQL и откриване на SQL инжектиране с помощта на ProxySQL, балансьор на натоварване, който може да бъде разгърнат от ClusterControl:
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-one
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-two
Сигурност на данните
Накрая, сигурността на данните. Досега обсъждахме как може да се укрепи базата данни, как да се ограничи достъпът до нея и как да се предотвратят различни видове атаки, идващи от самото приложение. Все пак трябва да обмислим защитата на самите данни. Това може да има няколко слоя. Физическа сигурност - ако притежавате центъра за данни, уверете се, че е правилно заключен. Ако използвате външни доставчици на интернет услуги или облачни доставчици, уверете се, че имат подходящи протоколи за сигурност, когато става въпрос за достъп до хардуера. Тогава имаме сървър, VM или както използвате. Данните се съхраняват на диск, съхраняват се локално на сървъра. Данните се прехвърлят между приложението, проксито и базата данни. Данните се прехвърлят между възлите на базата данни чрез репликация. Данните се съхраняват извън сайта като резервни копия. Тези данни трябва да бъдат защитени.
Резервни копия
Резервните копия винаги трябва да бъдат криптирани. Ключът за криптиране трябва да се поддържа внимателно и да се върти редовно.
Данните се пренасят
Данните, които се прехвърлят, трябва да бъдат криптирани. Уверете се, че сте конфигурирали вашето приложение, прокси слой и база данни да използват SSL или TSL. Всички средства за прехвърляне на данни между възлите на базата данни също трябва да бъдат защитени и криптирани. Целта е всякакъв вид подслушване на мрежата да стане безсмислено.
Данните в покой
Накрая, самите данни, съхранявани на възела на базата данни. Той също трябва да бъде криптиран. Има няколко метода, които можете да използвате, когато подхождате към тази тема. Първо, криптиране на ниво хост. Томът, на който базата данни има своята директория с данни, може да бъде криптиран (и декриптиран при стартиране). Базите данни също обикновено идват с възможности за криптиране. Какво може да бъде криптирано зависи от точното решение и от типа и версията на базата данни, но в някои случаи опциите са доста обширни. Шифроване на пространството за таблици, криптиране на регистрационни файлове, понякога дори криптиране на структурите в паметта. Ако го направите правилно, достъпът до възела на базата данни няма да е достатъчен за достъп до данните.
Заключение
Както споменахме по-рано, този блог не е предназначен да бъде практическо ръководство за сигурността на базата данни, но засегнахме повечето от аспектите, които трябва да имате предвид, когато проектирате вашата среда на база данни и се надяваме ще намерите това ръководство за полезно.
