Хибридният облак може да бъде чудесен начин за добавяне на гъвкавост към съществуващите Ви локални внедрявания. Както обсъдихме в няколко блога, публичният облак може да бъде чудесно допълнение към вашия собствен център за данни, като ви гарантира, че можете лесно да мащабирате, за да се справите с натоварването, да намалите капиталовите си разходи и да бъдете използван за прилагане на процедури за възстановяване след бедствие. Сигурността е друг аспект, който трябва да помислите, когато планирате да изградите такива системи. В тази публикация в блога ще говорим за някои от съображенията за сигурност при внедряването на MariaDB в хибриден облак.
Свързване
VPN
Основната част от всяка хибридна инфраструктура е мрежата. В крайна сметка, ние говорим за две среди, локална, локална и публичен облак, които трябва да бъдат свързани и да образуват едно цяло. Връзката трябва да бъде криптирана. Как да подходите към него, има много начини да го направите.
Едно от тях би било да се използва решение, предоставено от доставчика на облак - повечето от тях имат някаква налична опция за свързване. Може да бъде AWS Direct Connect, ако случайно се интегрирате с Amazon Web Services. Ако планирате да използвате Google Cloud, решенията се обсъждат на следния уеб сайт:https://cloud.google.com/hybrid-connectivity. Накратко, има значителен брой различни опции, които варират от хардуерна VPN интеграция до настройка на BGP peering.
От другата страна на спектъра имаме софтуерни VPN решения. OpenVPN или подобен вид софтуер може да се използва за настройка на сигурна, криптирана мрежова връзка между вашия собствен център за данни и публичния облак. В такъв случай ще ви е необходим отделен екземпляр, работещ в публичния облак, който ще се използва за VPN сървъра. Използването на софтуерни VPN ви позволява да изберете решението, което най-добре отговаря на вашите изисквания и отговаря най-добре във вашата среда.
Защитна стена
Базите данни никога не трябва да бъдат достъпни от външни мрежи. От първостепенно значение е да изградите вашата среда по начин, по който нивото на базата данни ще бъде достъпно само от ограничен набор от хостове. Какво точно се изисква и как да направите това, зависи от вас да решите. Типичната настройка ще се състои от защитено ниво на база данни, до което може да се получи достъп само от прокси ниво и, ако е необходимо, трябва да се приложи някакъв вид хост за прескачане, ако е необходимо за задачи за автоматизация и администриране.
Сървърите на приложения не трябва да имат директен достъп до базата данни - не е необходимо. Всичко, което приложението трябва да направи, е да се свърже с балансира на натоварването. Балансьорите на натоварване трябва да могат да се свързват с базата данни. Балансьор на натоварване като ProxySQL е напълно способен да извърши разделяне на четене/запис и да изпрати четенето и записа до правилните възли на базата данни. Приложението трябва да може да се свърже с ProxySQL и останалото ще се обработва от проксито - удостоверяване на база данни, оформяне на трафика, разпределяне на трафика между множество реплики, които може да имате. Всеки ненужен достъп трябва да бъде ограничен. Групи за сигурност, защитни стени - това са инструментите, които искате да използвате, за да защитите вашата среда.
Накратко, достъпът до хостовете на базата данни трябва да бъде разрешен само на необходимите портове. За MariaDB това ще бъде, очевидно, порт, използван за базата данни, но също и други портове, ако е необходимо - може да имате инсталирани някакви експортери или агенти. За Galera ще трябва да отворите портове за комуникация в клъстера. Може също да искате да имате отворен порт за SSH връзки. В идеалния случай ограничете достъпа за всеки хост; само ограничен набор от хостове има достъп до даден порт. Например портът на базата данни може да бъде достъпен от другите възли на базата данни, локалния хост и прокси слоя. Няма нужда да го държите отворен за други възли. Възлите на вашата база данни може дори да се намират в отделна подмрежа, което гарантира, че сигурността е още по-строга.
Що се отнася до портовете, най-добрите практики биха били да ги промените от настройките по подразбиране към нещо друго. В идеалния случай нещо произволно. Промяната на SSH порт от 22 на 2222 или MariaDB порт от 3306 на 33306 може да помогне да се избегнат някои от автоматизираните атаки, но все пак може да се разбере дали някой активно търси да влезе във вашата мрежа. Ако искате по-добра сигурност, може просто да продължите с някои произволни стойности. Задайте SSH на 5762 и MariaDB на 24359. Много вероятно е никой да не може да ги познае. Задайте вашите TCP изчаквания, така че сканирането на портове да е много продължително и скъпо и това със сигурност ще увеличи шансовете ви.
SSL
В допълнение към VPN и защитната стена, трябва да се уверите, че трафикът на вашата база данни е криптиран чрез SSL.
В идеалния случай ще защитите както връзките на интерфейса (от балансиращите на натоварването), така и комуникацията между вашите възли на базата данни (било то репликация или вътрешноклъстерен трансфер в клъстерите на Galera). ClusterControl може да ви помогне да активирате тези опции само с няколко щраквания.
Всичко, което трябва да направите, е да позволите на ClusterControl да създава нови сертификати или да използва един от съществуващите - можете да импортирате свой собствен сертификат, ако желаете. Активирането на SSL гарантира, че трафикът на базата данни няма да бъде четим дори от някой, който е получил достъп до вашата мрежа.
Сигурност на базата данни
Разбира се, мрежата не е единственият важен аспект на сигурността. Да, критично е, особено в хибридната облачна среда, но има и други много важни аспекти. Един от тях е контролът на достъпа, вграден в MariaDB.
Контрол на достъп, базиран на роли за MariaDB
MariaDB се предлага с набор от инструменти, за да гарантира, че достъпът до базата данни е правилно управляван и ограничен, където и да е необходимо. Първият ред на удостоверяване е потребителите. Всеки и всичко, на което е разрешен достъп до MariaDB, трябва да използва назначен потребител за свързване с базата данни. Такива потребители ще имат правилна парола - можете да активирате валидирането на паролата в MariaDB, за да сте сигурни, че паролите са достатъчно силни. В идеалния случай бихте ограничили хоста за достъп на потребителя само до имена на хостове или IP адреси на балансьори на натоварване - това винаги трябва да бъде начинът, по който потребителите се свързват с базата данни. За някои административни потребители може да искате да запазите достъпа на localhost, ако е необходимо. Освен налагането на правилната сила на паролата, можете да конфигурирате паролата да изтече в рамките на определен период от време или да наложите ротация на паролата за потребителите. Както можете да си представите, правилната политика за ротация на пароли е нещо, което ще искате да приложите.
Всеки потребител в MariaDB може да има присвоени множество привилегии. Привилегиите могат да бъдат присвоени на няколко нива - глобално ниво, ниво на база данни, ниво на таблица или дори ниво на колона. Най-добрата практика е да предоставите възможно най-ограничен набор от привилегии на потребителите. Ако потребителят изисква достъп само до определена таблица, просто му дайте това. Няма нужда този потребител да има достъп до други таблици, да не говорим за други схеми. Можете да дефинирате доста подробни права за достъп, като използвате голям набор от привилегии, които можете да предоставите на потребителите. Тя варира от права за четене, актуализиране или изтриване на данни чрез привилегии за управление на база данни до „супер“ привилегия, която позволява на потребителя да извършва действия като управление на нишките за репликация и заобикаляне на настройката „само за четене“.
Освен това, MariaDB идва с роли - за да се улесни управлението на потребителите, е възможно да се дефинират роли с даден набор от предоставени привилегии и след това да се присвоят тези роли на потребителите. Такива потребители ще наследят грантове, свързани с ролята, на която са им възложени, което улеснява управлението на безвъзмездни средства в голям мащаб:вместо да променяте разрешенията за множество потребители, можете да ги присвоите на една конкретна роля и след това да управлявате всичките им привилегии чрез промяна на привилегиите, предоставени на ролята, на която са възложени.
Трябва също така да се уверите, че нямате вече съществуващи потребители без назначена парола или с твърде голям набор от привилегии. Такъв одит на сигурността трябва да се извършва от време на време, като се гарантира, че сте наясно с потенциалните рискове за сигурността и че можете да планирате да действате по тях.
Регистър на одита
Ако вашата база данни идва с регистрационен файл за одит, точно както прави MariaDB, трябва да помислите да го използвате за проследяване на действията, които се случват в базата данни. Дневникът на одита ще ви помогне да постигнете това. С активиран ще можете да проследявате дори подробности като кой потребител е изпълнил каква заявка. Ако случайно използвате ClusterControl, можете да активирате регистъра на одита само с няколко щраквания:
За да обобщим този блог, има няколко неща, които трябва да имате предвид, когато проектирате внедряване на MariaDB в хибридна облачна среда. Някои от тях са строго свързани с начина, по който е проектирана средата, някои са до голяма степен свързани с типа база данни, който използвате, а фактът, че използвате хибриден облак, всъщност не се променя много. Това, което е наистина важно, е да гарантирате, че вашата база данни е правилно защитена – това е крайната цел, без значение каква е средата.
