Le cloud hybride peut être un excellent moyen d'ajouter de la flexibilité à vos déploiements sur site existants. Comme nous en avons discuté dans plusieurs blogs, le cloud public peut être un excellent ajout à votre propre centre de données, vous permettant de facilement évoluer pour gérer la charge, réduire vos dépenses d'investissement et être utilisé pour mettre en œuvre des procédures de reprise après sinistre. La sécurité est un autre aspect auquel vous devez penser lorsque vous envisagez de construire de tels systèmes. Dans cet article de blog, nous aborderons certaines des considérations de sécurité pour les déploiements de cloud hybride MariaDB.
Connectivité
VPN
La majeure partie de toute infrastructure hybride est le réseau. Après tout, nous parlons de deux environnements, local, sur site et un cloud public, qui doivent être connectés et former une seule entité. La connexion doit être cryptée. Comment l'aborder, il existe de nombreuses façons de le faire.
L'un d'entre eux consisterait à utiliser une solution mise à disposition par le fournisseur de cloud - la plupart d'entre eux ont une sorte d'option de connectivité disponible. Il peut s'agir d'AWS Direct Connect si vous vous intégrez à Amazon Web Services. Si vous envisagez d'utiliser Google Cloud, les solutions sont présentées sur le site Web suivant :https://cloud.google.com/hybrid-connectivity. En bref, il existe un nombre important d'options différentes qui vont de l'intégration VPN matérielle à la configuration de l'appairage BGP.
De l'autre côté du spectre, nous avons des solutions VPN logicielles. OpenVPN ou un type de logiciel similaire peut être utilisé pour configurer une connexion réseau sécurisée et cryptée entre votre propre centre de données et le cloud public. Dans un tel cas, vous auriez besoin d'une instance distincte s'exécutant dans le cloud public qui sera utilisée pour le serveur VPN. L'utilisation de VPN logiciels vous permet de choisir la solution qui répond le mieux à vos besoins et qui s'adapte le mieux à votre environnement.
Pare-feu
Les bases de données ne doivent jamais être accessibles depuis des réseaux externes. Il est primordial de créer votre environnement de manière à ce que le niveau base de données ne soit accessible qu'à partir d'un ensemble limité d'hôtes. Exactement ce qui est requis et comment le faire, c'est à vous de décider. Une configuration typique consisterait en une couche de base de données sécurisée accessible uniquement à partir de la couche proxy et, si nécessaire, une sorte d'hôte de saut doit être implémentée si nécessaire pour les tâches d'automatisation et d'administration.
Les serveurs d'applications ne doivent pas avoir un accès direct à la base de données - ils n'en ont pas besoin. Tout ce que l'application doit faire est de se connecter à l'équilibreur de charge. Les équilibreurs de charge doivent pouvoir se connecter à la base de données. Un équilibreur de charge comme ProxySQL est parfaitement capable d'effectuer la séparation lecture/écriture et d'envoyer les lectures et écritures aux nœuds de base de données appropriés. L'application devrait pouvoir se connecter au ProxySQL et le reste sera géré par le proxy - authentification de la base de données, mise en forme du trafic, répartition du trafic sur de nombreuses répliques que vous pourriez avoir. Tout accès inutile doit être restreint. Groupes de sécurité, pare-feu - ce sont les outils que vous souhaitez utiliser pour sécuriser votre environnement.
En bref, l'accès aux hôtes de la base de données doit être autorisé uniquement sur les ports requis. Pour MariaDB, ce sera évidemment un port utilisé pour la base de données mais aussi d'autres ports si nécessaire - vous pouvez avoir une sorte d'exportateurs ou d'agents installés. Pour Galera, vous auriez besoin d'ouvrir des ports pour la communication intra-cluster. Vous pouvez également avoir un port ouvert pour les connexions SSH. Idéalement, limitez l'accès par hôte; seul un ensemble limité d'hôtes peut accéder à un port donné. Par exemple, le port de la base de données peut être accessible à partir des autres nœuds de la base de données, de l'hôte local et de la couche proxy. Il n'est pas nécessaire de le garder ouvert pour d'autres nœuds. Vos nœuds de base de données peuvent même être situés sur un sous-réseau séparé, ce qui garantit une sécurité encore plus stricte.
En ce qui concerne les ports, les meilleures pratiques seraient de les changer des paramètres par défaut à autre chose. Idéalement, quelque chose de aléatoire. Changer le port SSH de 22 à 2222 ou le port MariaDB de 3306 à 33306 peut aider à éviter certaines des attaques automatisées, mais il est toujours possible de déterminer si quelqu'un cherche activement à accéder à votre réseau. Si vous voulez une meilleure sécurité, vous pouvez simplement utiliser des valeurs aléatoires. Définissez SSH sur 5762 et MariaDB sur 24359. Il est fort probable que personne ne puisse les deviner. Définissez vos délais d'expiration TCP afin que les analyses de port soient très longues et coûteuses, ce qui augmentera sûrement vos chances.
SSL
En plus du VPN et du pare-feu, vous devez vous assurer que le trafic de votre base de données est crypté à l'aide de SSL.
Idéalement, vous protégerez à la fois les connexions frontales (des équilibreurs de charge) et la communication entre vos nœuds de base de données (que ce soit la réplication ou le transfert intra-cluster dans les clusters Galera). ClusterControl peut vous aider à activer ces options en quelques clics.
Tout ce que vous avez à faire est de laisser ClusterControl créer de nouveaux certificats ou d'utiliser l'un de ceux existants - vous pouvez importer votre propre certificat si vous le souhaitez. L'activation de SSL garantit que le trafic de la base de données ne sera pas lisible même par quelqu'un qui a eu accès à votre réseau.
Sécurité de la base de données
Bien sûr, le réseau n'est pas le seul aspect important de la sécurité. Oui, c'est essentiel, surtout dans l'environnement de cloud hybride, mais il y a aussi d'autres aspects très importants. L'un d'eux est le contrôle d'accès intégré à MariaDB.
Contrôle d'accès basé sur les rôles pour MariaDB
MariaDB est livré avec un ensemble d'instruments pour garantir que l'accès à la base de données est correctement géré et restreint partout où cela est nécessaire. La première ligne d'authentification est celle des utilisateurs. Toute personne et tout ce qui est autorisé à accéder à MariaDB doit utiliser un utilisateur assigné pour se connecter à la base de données. Ces utilisateurs auront un mot de passe approprié - vous pouvez activer la validation du mot de passe dans MariaDB pour vous assurer que les mots de passe sont suffisamment forts. Idéalement, vous limiteriez l'hôte d'accès de l'utilisateur uniquement aux noms d'hôte ou aux adresses IP des équilibreurs de charge - cela devrait toujours être la façon dont les utilisateurs se connectent à la base de données. Pour certains utilisateurs administratifs, vous souhaiterez peut-être conserver l'accès localhost si nécessaire. En plus d'appliquer la force de mot de passe appropriée, vous pouvez configurer le mot de passe pour qu'il expire dans un certain laps de temps ou imposer la rotation du mot de passe aux utilisateurs. Comme vous pouvez l'imaginer, une bonne politique de rotation des mots de passe est quelque chose que vous voudrez mettre en place.
Chaque utilisateur de MariaDB peut se voir attribuer plusieurs privilèges. Les privilèges peuvent être attribués à plusieurs niveaux - niveau global, niveau base de données, niveau table ou même niveau colonne. La meilleure pratique consiste à accorder un ensemble limité de privilèges aux utilisateurs dans la mesure du possible. Si l'utilisateur n'a besoin que d'un accès à une table particulière, accordez-lui simplement cela. Il n'est pas nécessaire que cet utilisateur accède à d'autres tables sans parler d'autres schémas. Vous pouvez définir des droits d'accès assez détaillés en utilisant un large ensemble de privilèges que vous pouvez accorder aux utilisateurs. Cela va des droits de lecture, de mise à jour ou de suppression de données aux privilèges de gestion de base de données jusqu'au privilège "super" qui permet à l'utilisateur d'effectuer des actions telles que la gestion des threads de réplication et le contournement du paramètre read_only.
En plus de cela, MariaDB est livré avec des rôles - pour faciliter la gestion des utilisateurs, il est possible de définir des rôles avec un ensemble donné de privilèges accordés, puis d'attribuer ces rôles aux utilisateurs. Ces utilisateurs hériteront des attributions liées au rôle auquel ils ont été attribués, ce qui facilitera la gestion des attributions à grande échelle :au lieu de modifier les attributions pour plusieurs utilisateurs, vous pouvez les attribuer à un rôle spécifique, puis gérer tous leurs privilèges en modifier les privilèges accordés au rôle auquel ils ont été attribués.
Vous devez également vous assurer que vous n'avez pas d'utilisateurs préexistants sans mot de passe attribué ou avec un trop grand nombre de privilèges. Un tel audit de sécurité doit être effectué de temps à autre, en veillant à ce que vous soyez conscient des risques de sécurité potentiels et que vous puissiez planifier d'agir en conséquence.
Journal d'audit
Si votre base de données est livrée avec un journal d'audit, tout comme MariaDB, vous devriez envisager de l'utiliser pour suivre les actions qui se produisent dans la base de données. Le journal d'audit vous aidera à accomplir cela. Avec cette option activée, vous pourrez suivre même les détails comme quel utilisateur a exécuté quelle requête. Si vous utilisez ClusterControl, vous pouvez activer le journal d'audit en quelques clics :
Pour résumer ce blog, il y a quelques éléments à prendre en compte lors de la conception d'un déploiement MariaDB dans l'environnement de cloud hybride. Certains d'entre eux sont strictement liés à la façon dont l'environnement est conçu, certains sont plutôt liés au type de base de données que vous utilisez et le fait que vous utilisiez le cloud hybride ne change pas grand-chose. Ce qui est vraiment important, c'est de s'assurer que votre base de données est correctement protégée - c'est l'objectif ultime, quel que soit l'environnement.
