Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Comment cegedim.cloud gère le patching des serveurs ?
cegedim.cloud s'assure que tous les serveurs sont patchés lors d'événements appelés Patch Party. Ces événements ont lieu tous les trimestres un dimanche, soit 4 fois par an.
Lors d'une Patch Party, les patchs sont installés sur tous les serveurs non exclus de l'événement puis suivis d'un redémarrage.
Les services seront interrompus pendant une Patch Party !
Les Patch Parties ont lieu tous les trimestres, soit 4 fois par an. Deux Patch Parties sont programmées chaque trimestre :
Patch Party de QA : elle a lieu en premier pendant les heures ouvrées, le jeudi, et ne concerne que les environnements de non-production.
Patch Party de Production : elle a lieu 3 semaines après la Patch Party de QA, le dimanche, et ne s'applique qu'aux environnements de production.
Les événements Patch Party sont disponibles dans le calendrier de notre outil de gestion de plateforme cloud ITCare.
Sur chaque page de détails d'une ressource, un panneau intitulé Patch status vous permet de consulter les informations suivantes :
La dernière fois que la ressource a été mise à jour avec succès
Le timestamp de la mise à jour
Le tag du correctif de la mise à jour avec ce format : YYYY-QQ (par exemple 2022-Q4)
La prochaine Patch Party programmée si la ressource n'est pas exclue
La personne qui a exclu la ressource et la date si la ressource est exclue
Sur chaque page de détails d'une ressource, un bouton Patch Party vous permet d'inclure ou d'exclure définitivement la ressource des Patch Party.
L'exclusion d'une ressource doit être motivée par une raison. Inclure vous permet de sélectionner le Patch Group qui affectera le moment où votre ressource sera effectivement mise à jour au cours de la journée de correctifs.
Dans le même bouton Patch Party que celui décrit ci-dessus, vous pouvez changer le Patch Group souhaité à tout moment.
3 groupes de patches sont disponibles pour diviser vos ressources. Chaque groupe sera traité à des moments différents.
Ceci est utile si vous ne voulez pas que plusieurs ressources soient patchées (et interrompues) en même temps, améliorant ainsi la résilience de votre application.
Des produits PaaS en topologie cluster auront déjà des assignations de Patch group optimisés pour garantir la disponibilité du cluster pendant les Patch parties.
Pour demander l'ajout d'une réplique en lecture seule de MariaDB, il est nécessaire de créer un ticket requête via ITCare.
Dans la section Support du menu latéral gauche, cliquer sur le bouton Formuler une demande.
Dans la catégorie Base de données puis MariaDB, sélectionner et remplir le formulaire : Mise en place d'une réplication passive MariaDB
Un ticket d'assistance sera créé à la soumission.
Veuillez prévoir jusqu'à 10 jours ouvrables pour le traitement de votre demande.
Bienvenue dans la documentation publique de cegedim.cloud !
Notes de mise à jour cegedim.cloud
Un nouveau système de filtrage est maintenant disponible dans la section Ressources ! Les filtres s'ajustent automatiquement en fonction du type de ressource choisi, permettant ainsi une expérience plus personnalisée et une présentation optimisée des informations attendues.
Une démonstration interactive est disponible dans la section démo : #filtres-dynamiques
Nous sommes heureux d'annoncer que Redis 7.2.5 est désormais disponible sur notre plateforme ITCare. Vous pouvez également demander la mise à jour en version 7.2.5 d'un PaaS Redis déjà existant via un ticket requête.
La sélection de votre politique de sauvegarde pour les instances virtuelles Linux et Windows est maintenant disponible en autonomie lors de la création de vos ressources dans ITCare !
Cette fonctionnalité est présentement en phase Bêta accessible à tous.
La distribution Oracle Linux est désormais disponible en libre service via ITCare, notre plateforme de gestion du Cloud. Cette distribution est disponible dans le cadre de notre produit d'instances virtuelles avec les mêmes options et propriétés.
Bot Defense a été mis à jour pour introduire le mode transparent, vous permettant de voir les requêtes jugées illégitimes sans impacter le trafic. Ce mode facilite l'analyse des logs et l'identification des faux positifs, ce qui permet d'affiner les réglages en ajoutant des IP légitimes à la liste blanche avant de passer au mode blocage.
Pour plus d'informations, merci de lire la documentation Bot Defense.
OverDrive, basé sur la technologie Nextcloud, offre une plateforme de stockage et de synchronisation de fichiers avec de puissantes capacités de collaboration avec des interfaces de bureau, mobiles et web. Ce nouveau produit est disponible en libre-service par l'intermédiaire d'ITCare dans la taille XS et est hébergé sur site avec des normes de sécurité élevées.
Pour plus d'informations, veuillez lire la documentation OverDrive.
Pour simplifier la création d'un load balancer, il est désormais possible de créer un load balancer sur votre cluster Kubernetes directement depuis le menu déroulant Gérer.
Un nouvel indicateur de santé a été ajouté à tous les clusters Kubernetes dont la surveillance est activée pour surveiller l'API Kubernetes.
Le système d'exploitation utilisé par les PaaS a été mis à niveau en dernière version lorsque cela était possible. Cela garantit que tous les nouveaux déploiements seront à jour et bénéficieront des correctifs de sécurité.
Une nouvelle fonctionnalité est disponible pour les clusters OpenSearch afin de migrer d'une topologie basique vers une topologie avec master dédiés. Cette migration ajoutera 3 nœuds dédiés au rôle de maître (n'hébergeant pas de données).
Des nœuds spécialisés dédiés au rôle d'ingestion peuvent maintenant être ajoutés à votre cluster OpenSearch. Cette nouvelle fonctionnalité est disponible dans le menu déroulant Gérer et ajoutera 2 nouveaux nœuds dédiés au rôle d'ingestion.
Les versions 3.12 et 3.13 sont désormais supportées par le PaaS RabbitMQ ! Pour plus d'informations, merci de lire la documentation RabbitMQ ainsi que les notes de mises à jour officielles.
La version 16 est maintenant supportée par le PaaS PostgreSQL ! Pour plus d'informations, merci de lire la documentation PostgreSQL ainsi que les notes de mises à jour officielles.
L'installation d'extensions PostgreSQL sur vos PaaS est désormais possible en libre service via ITCare. La liste des extensions supportées est disponible dans la documentation PostgreSQL - Architecture.
Cette fonctionnalité n'est disponible que pour les déploiements PostgreSQL 15 et supérieur.
Le PaaS OpenSearch a été mis à jour pour supporté et permettre le déploiement de la version 2.11.1.
Le menu principal d'ITCare a été amélioré afin d'offrir une meilleure navigation en réduisant le nombre de pages en cascade.
L'ancien moteur de notification a été supprimé et remplacé par un meilleur système de notification capable de gérer des règles de notification très précises. Cela vous permet de personnaliser exactement les notifications que vous souhaitez recevoir à l'aide d'abonnements ainsi que les destinataires à l'aide de groupes de diffusion d'e-mails.
Vos anciennes souscriptions de notification ont été conservées.
Il est désormais possible de sélectionner l'Ingress provider que vous souhaitez pour Kubernetes dans l'assistant de création. Les Ingress provider disponibles sont : NGINX, Istio et Traefik.
SQL Server 2022 est disponible au provisioning dans ITCare. Comme précédemment, il est possible de choisir l'édition Standard ou Entreprise au provisioning.
Dans ITCare, l'affichage de Kubernetes a été amélioré pour afficher le rôle Ingress sur vos nœuds ainsi que la version du système d'exploitation déployé sur chaque nœud.
Après avoir amélioré la gestion des URL dans ITCare, il est maintenant possible de créer vos propres alertes HTTP sur des URL directement depuis ITCare sur votre load balancer en utilisant l'onglet URL.
La version 12 de la distribution Linux Debian est disponible pour le déploiement dans ITCare. L'automatisation a été améliorée et l'approvisionnement est désormais plus rapide.
L'amélioration de la sécurité, précédemment disponible dans Debian 11, est toujours en vigueur, mais elle est désormais facultative et peut être désactivée dans l'assistant.
La nouvelle version LTS de MariaDB est disponible pour le déploiement dans ITCare. Consultez les notes de version officielles de MariaDB pour plus d'informations.
Les ressources peuvent désormais être incluses ou exclues en mode batch à partir de votre page Service. Nous avons également amélioré les informations sur l'état des correctifs grâce à un panneau dédié dans la vue d'ensemble de votre ressource, qui vous permet de voir rapidement si votre ressource a été patchée et quand aura lieu la prochaine Patch Party.
Des descriptions personnalisées peuvent être ajoutées à vos ressources et Services dans ITCare pour identifier rapidement vos applications.
Pour vous aider à naviguer vers vos ressources préférées, vous pouvez désormais ajouter des ressources à votre liste personnelle de favoris que vous pouvez appeler à partir de l'en-tête ITCare.
Un nouvel onglet est disponible dans la section Calcul pour parcourir les réseaux disponibles pour votre cloud avec leurs propriétés.
Le calendrier de maintenance a été amélioré pour afficher les événements personnalisés propres à chaque client. Les RFC et les événements privés apparaîtront désormais dans le calendrier ITCare de votre cloud.
La section Sécurité a été améliorée avec un nouveau point d'entrée pour Bot Defense & DoS Protection avec ses détails concernant les requêtes bloquées et les attaques.
La version 3.6.0 de Apache Kafka, plateforme open-source de streaming d'événements distribués, est disponible au déploiement via ITCare.
Cette nouvelle version utilise l'algorithme de consensus Raft et permet de s'affranchir de Zookeeper.
La version 15 de PostgreSQL est disponible au déploiement via ITCare. Elle est compatible avec toutes les fonctionnalités précédemment proposées.
La fonctionnalité PostgreSQL de restauration en libre-service, qui vous permet de restaurer une sauvegarde d'une source vers une autre destination, est disponible en libre-service dans ITCare.
Un nouveau mode "Strict" a été rajouté à la fonctionnalité Bot Defense.
Ce profil plus restrictif est déployable rapidement en cas d'attaque en cours sur vos Load balancers. Son paramétrage plus fin est destiné à bloquer un nombre de requêtes plus conséquent.
Vous pouvez créer jusqu'à 5 ressources supplémentaires avec la même configuration. Les ressources supplémentaires seront situées dans la même région, mais les zones de disponibilité peuvent être différentes.
Vous pouvez maintenant utiliser une ressource existante comme modèle pour créer une nouvelle ressource. Vous pouvez la dupliquer dans le même service ou en sélectionner un autre. Attention, cette fonctionnalité ne clone pas les données !
Lors de la création d'une ressource, la sélection du réseau est maintenant consciente de l'environnement du Service.
Si le Service a :
un environnement de Production, les réseaux de production sont affichés par défaut.
un environnement de Non-production, les réseaux de non-production sont affichés par défaut.
Dans les deux cas, les réseaux de production et de non-production restent disponibles pour la sélection.
Les maintenances peuvent maintenant être planifiées sur plusieurs ou toutes les ressources au niveau du service.
Une instance PostgreSQL unique peut maintenant être convertie en un cluster PostgreSQL hautement disponible avec deux nœuds. Cette opération n'est pas réversible.
De nouvelles actions de gestion sont maintenant disponibles sur les clusters :
Redimensionnement : il peut également être effectué au niveau du nœud en fonction de la configuration du produit.
Patch party : les statuts de chaque ressource sont maintenant visibles dans la vue étendue du service.
Il est désormais possible de mettre à jour votre cluster Conteneurs (K8s) vers la dernière version supportée à partir du menu de gestion du cluster :
La mise à niveau vers la version supérieure suivante est possible - le saut de version n'est pas autorisé
Le retour à une version antérieure n'est pas possible
Les URL liées à un équilibreur de charge peuvent désormais être gérées individuellement :
Un onglet URL dédié est disponible dans la page de l'équilibreur de charge
Les actions suivantes peuvent être effectuées par URL ou sur un groupe d'URL : planifier la maintenance, activer / désactiver la surveillance
La création d'URL est disponible dans les actions de gestion de l'équilibreur de charge
L'API REST ITCare respecte les spécifications standard OpenAPI.
La documentation en ligne est disponible à cette adresse : https://api.cegedim.cloud/
Exemple - Récupérer le statut de ITCare
L'API ITCare utilise le protocole OAuth 2.0 pour l'authentification et les autorisations. Elle supporte les scénarios OAuth 2.0 habituels tels que ceux utilisés pour les serveurs web et les applications clientes.
Cela signifie que chaque requête API doit contenir un header "Authorization" embarquant un token d'accès précédemment obtenu grâce à des identifiants.
Pour interroger l'API ITCare, un compte API est requis afin de pouvoir obtenir le token d'accès obligatoire.
Pour obtenir ce compte API, une requête doit être soumise aux équipes Support cegedim.cloud en fournissant les informations suivantes :
L'organisation cible
Une description simple de l'usage cible de l'API
Pour obtenir un token d'accès, le client doit soumettre une requête au endpoint /token.
Le serveur d'autorisation exige l'authentification du client pour délivrer un access_token.
Voici un exemple de demande d'access_token :
Si la demande d'access_token est autorisée et valide, voici un exemple de réponse :
Lorsque le token expire, il est possible de :
Demander un nouvel access_token
Rafraîchir le token en interrogeant le endpoint /token
L'API ITCare utilise le format JSON pour les messages (payload) à la fois en entrée (input) et en sortie (output).
Cela inclut aussi les corps des messages HTTP de type PUT, PATCH, POST et DELETE.
Elle respecte donc les standards d'une API REST en terme de verbe HTTP et de code retour HTTP.
Pour plus d'informations concernant l'implémentation standard RESTful :
JSON ne supporte pas nativement le format Date/Time.
Tous les paramètres tagués en tant que Date par l'API sont donc des string au format ISO8601.
Z correspond à la timezone : +0200 par exemple.
Pour les requêtes GET, ne pas oublier d'URL-Encoder ces paramètres.
Certaines méthodes autorisent le test des appels API sans que cela ne déclenche réellement l'action dans ITCare.
La validation s'effectue cependant.
Pour activer le mode Dry Run, il suffit d'ajouter un header personnalisé dans vos requêtes HTTP :
Une fois que le serveur traitera votre requête, le même header personnalisé sera inclus dans la réponse.
Certaines méthodes sont asynchrones et nécessitent un délai après leur invocation.
Cela s'applique à des longues transactions telles que l'administration des ressources ou l'envoi de rapports.
Les méthodes qui fonctionnent de manière asynchrone répondront :
un code retour HTTP 202
un corps contenant un ID de suivi de l'opération asynchrone en cours
Voici un exemple de code en Python qui explique le fonctionnement asynchrone :
Les statuts des actions peuvent être :
IN_PROGRESS
SUCCESS
ERROR
Pré-requis :
Python3
pip (pour installer le SDK)
Téléchargez l'archive suivante qui contient le SDK ITCare : itcare-sdk.tar.gz
Décompressez-le puis entrez dans le répertoire.
Exécutez les commandes suivantes pour installer le SDK Python d'ITCare.
Afin de vous aider à appréhender et maitriser chaque aspect de la plateforme ITCare, nous proposons un ensemble de démos interactives spécifiques à des fonctionnalités disponible dans notre Cloud Management Platform.
En fonction des ressources sélectionnées dans la fenêtre de filtrage, des filtres dynamiques seront désormais disponibles pour afficher plus efficacement ce qui vous intéresse.
Vos notifications sont configurables et personnalisables via des abonnements. Nous vous montrons cela ci-dessous !
La première étape incontournable : créer un abonnement selon vos critères personnalisés.
Maintenant que vous savez comment créer un abonnement, voyons comment le gérer.
Les abonnements tirent partie de groupes de diffusions. Nous vous montrons comment les gérer.
Lorsque vos notifications sont paramétrées, il est essentiel de savoir comment les superviser.
Il n'est pas possible de créer son propre compte ITCare pour accéder à la plateforme.
Pour obtenir un compte ITCare, le représentant de la sécurité de votre organisation doit soumettre une demande de création de compte.
Veuillez contacter votre Service Delivery Management ou l'équipe commerciale de cegedim.cloud.
L'authentification ITCare est basée sur une adresse e-mail et un mot de passe conformes aux normes de la politique de sécurité de cegedim.cloud.
Les comptes API utilisent le protocole OpenID. Plus d'informations sur l'API ITCare sont disponibles dans la page API ITCare.
L'authentification multi-facteurs est disponible et obligatoire pour certaines actions à haut privilège et vous devrez :
Répondre à un appel téléphonique
Ou bien valider une notification sur un smartphone
Au cours du processus d'intégration, vous recevrez toutes les informations nécessaires pour configurer correctement l'authentification multifactorielle.
Les privilèges dans ITCare sont divisés en rôles assignés à des profils. Les profils sont attribués aux utilisateurs.
Le MFA doit être configuré et sera obligatoire pour les rôles suivants :
Gérer les maintenances
Modifier les ressources
Gérer les ressources
Ce tableau non exhaustif décrit les actions basiques autorisées par profil :
La topologie de la plateforme d'hébergement cegedim.cloud est divisée en :
Régions : un groupe de centre de données à faible latence ( < 1 ms)
Zones de disponibilité : ensemble de composants d'infrastructure dédiés dans un centre de données
Voici la liste des régions disponibles pour nos clients :
Une ressource est un composant d'infrastructure ou middleware déployé dans le cloud de cegedim.cloud.
Elle ne peut appartenir qu'à un seul Service. Voir #presentationitcare-commentmesressourcesitcaresont-ellesorganisees pour la définition d'un Service.
Une ressource est systématiquement définie par les propriétés suivantes :
un id : identifiant unique de la ressource.
un type : le type de la ressource e.g. instance virtuelle, cluster Kubernetes, etc..
un nom : plus pratique à manipuler qu'un id.
un statut : défini l'état de la ressource (active, inactive).
un environnement : défini le type d'environnement de la ressource (production, qa, dev, test, etc..).
des tags : permet de taguer vos ressources avec des clés/valeurs personnalisables qui sont requêtables.
Voici les statuts possibles d'une ressource qui sont visibles par la web UI ou renvoyés par l'API :
Tout client cegedim.cloud possède une Organisation qui matérialise son existence au sein de notre SI.
Plusieurs Clouds peuvent être créés au sein d'une Organisation. Ceux-ci permettent de cloisonner les ressources et les droits utilisateurs.
Par défaut, un seul Cloud est défini pour une nouvelle Organisation. Des Clouds supplémentaires peuvent être créés sur demande.
Vous pouvez donc définir, au niveau d'un Cloud, qui a accès à quoi et quelles actions peuvent être réalisées. Il est donc possible, par exemple, d'avoir un Cloud offrant pleins pouvoirs à vos équipes de développement pour ne pas perturber la production.
Au sein d'un Cloud, les ressources sont ensuite regroupées dans des Services.
Les Services permettent de regrouper vos ressources de manière logiques selon plusieurs critères libres :
Le périmètre d'une application
Par environnement
Tout autre critère libre : par client par exemple
Les Services ne permettent pas d'appliquer des restrictions des droits utilisateurs.
Dans ITCare, les Services ont des pages dédiées qui permettent de consulter aisément l'ensemble des ressources qui leur est attaché.
Pour créer une nouvelle instance virtuelle, rendez-vous sur ITCare et recherchez votre service global cible où vous créerez votre nouvelle instance.
Recherchez votre service global dans la barre de recherche supérieure et cliquez dessus pour afficher sa page d'information. Une fois dans votre service global, cliquez sur le bouton Créer une ressource, sélectionnez Linux, Windows ou AIX et la version et/ou la distribution souhaitée.
Remplir les champs :
Nom de la machine virtuelle
Dimensionnement du CPU/RAM
Disques et capacité de stockage pour chaque disque
Emplacement de la cible
Réseau cible
Options de gestion (sauvegarde, surveillance, surveillance 24x7, réplication des données)
Cliquez sur Suivant une fois que tous les champs ont été remplis.
Lors de l'étape de personnalisation, vous pouvez :
Formuler une requête spécifique (il est à noter que cela retardera la tâche automatisée car cela déclenchera une intervention humaine)
Créer plusieurs instances avec la même configuration (noms et emplacement à fournir)
Cliquez ensuite sur Suivant.
Lisez le résumé avant de soumettre le formulaire.
L'approvisionnement peut prendre jusqu'à 2 heures, en fonction de la charge d'automatisation actuelle.
Une fois que le déploiement est prêt, vous en serez informé par e-mail.
Quelle que soit l'instance ou le système d'exploitation auquel vous devez vous connecter, l'utilisation d'un Bastion est obligatoire. Vous devez d'abord vous connecter au Bastion assigné à votre locataire, à partir duquel vous pouvez ensuite initier une connexion SSH ou RDP à vos instances.
Connexion SSH en utilisant Putty ou mRemoteNG installé sur votre Bastion. Les identifiants à utiliser sont vos propres identifiants d'utilisateur adm.corp.
La connexion directe en tant qu'utilisateur root est désactivée sur toutes les instances virtuelles Linux. Vous devez vous connecter avec un utilisateur non root, puis utiliser les permissions sudoers pour effectuer des actions à haut privilège.
Deux méthodes d'authentification sont autorisées :
LDAP
Clé publique et privée
Pour se connecter via SSH en utilisant la méthode d'authentification LDAP, vous devez avoir un compte valide dans le même domaine LDAP que celui dans lequel votre instance virtuelle est inscrite.
Il n'est pas nécessaire de spécifier le nom du domaine LDAP dans votre login.
Lors de la première connexion, votre répertoire personnel sera automatiquement créé : /home/<yourlogin>/
Pour obtenir la liste des commandes autorisées, entrez la commande suivante : sudo -l
Pour se connecter à une instance virtuelle linux avec votre clé publique SSH, votre clé doit être ajoutée au fichier /home/<user>/.ssh/authorized_keys.
Où <user> est le nom du compte local sur le serveur cible et login spécifie le nom de l'utilisateur local : ssh user@host
Connexion RDP en utilisant Remote Desktop de mRemoteNG ou Windows mstsc intégré sur votre Bastion. Les identifiants à utiliser sont ceux de l'utilisateur adm.corp.
Connexion SSH en utilisant Putty ou mRemoteNG installé sur votre Bastion. Un compte utilisateur local avec un accès sudo ou root sera fourni lors de la livraison de l'instance.
our lister les utilisateurs et groupes LDAP autorisés à se connecter, utilisez la commande suivante :
simple_allow_groups : groupes LDAP
simple_allow_users : utilisateurs LDAP
Vous ne pouvez ajouter que des groupes ou des utilisateurs inscrits dans le même domaine LDAP que votre instance virtuelle.
Pour autoriser la connexion d'un utilisateur LDAP, utilisez la commande suivante :
Pour autoriser la connexion à un groupe LDAP, utilisez la commande suivante :
Pour supprimer l'accès à un utilisateur ou groupe LDAP, utilisez la commande suivante :
Pour accorder des droits sudo à des utilisateurs ou groupes LDAP (ainsi qu'à des utilisateurs ou groupes locaux), créez un nouveau fichier dans /etc/sudoers.d
Il n'est pas recommandé d'ajouter des instructions sudoers dans le fichier /etc/sudoers. Réservé au système.
Utilisez la commande visudo pour éditer votre fichier sudoers :
Comme les groupes UNIX, les groupes LDAP dans le fichier sudoers doivent être préfixés par un '%'.
Matomo (anciennement appelé Piwik) est un logiciel de mesure open source qui fournit des statistiques de données sur l'utilisation d'une page web, telles que les visites, les pages vues, l'origine des visites et bien plus encore.
Matomo offre la possibilité d'avoir une analyse complète sur certains aspects de vos sites web avec des informations concernant : vos visiteurs, leur comportement, leurs habitudes et plus encore.
Matomo est un excellent substitut à Google Analytics pour les raisons suivantes :
Pleine propriété des données
Protection de la vie privée
Pas d'échantillonnage de données
Conformité RGPD (recommandé par la CNIL)
Flexibilité (portabilité des données, accès brut, open source, etc...)
Matomo est déployé sur site dans les centres de données de cegedim.cloud et est fourni en tant que service.
cegedim.cloud garantit le niveau de service managé suivant : le déploiement des instances, le maintien en condition opérationnelle, la flexibilité, la sécurité et le monitoring sont ainsi assurés par nos experts.
La facturation est mensuelle et varie en fonction de la taille choisie. Veuillez contacter votre Service Delivery Manager pour plus d'informations concernant la tarification.
Plusieurs produits sont disponibles au catalogue cegedim.cloud.
Ils sont classés par catégories dans les sections ci-dessous afin d'en avoir un aperçu rapide et la possibilité de naviguer directement vers la documentation publique associée.
La grande majorité de ces produits sont disponibles en self-service via ITCare, notre outil de gestion de plateforme cloud.
Pour plus d'informations sur nos offres commerciales, merci de consulter notre site officiel.
Elles sont hautement personnalisables (stockage, surveillance, sauvegarde, réplication) et redimensionnables (processeurs et mémoire). Elles offrent la meilleure flexibilité lorsqu'un produit n'est pas disponible en mode plateforme en tant que service (PaaS).
Voici les systèmes d'exploitation et distributions supportés par cegedim.cloud :
Linux
Debian
Ubuntu
Centos
Red Hat Linux Enterprise (RHEL)
Windows Server
AIX
Kubernetes est une plateforme d'orchestration de conteneurs open-source qui automatise le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Elle est fournie en tant que service géré par cegedim.cloud et bénéficie de l'infrastructure, des opérations et du support que nous fournissons.
Cela inclut des fonctionnalités telles que la mise à l'échelle, la surveillance, les correctifs de sécurité et le déploiement simplifié, ce qui permet aux développeurs et aux équipes de se concentrer sur le développement d'applications et d'éviter les complexités liées à la gestion de l'infrastructure sous-jacente.
Selon le dimensionnement choisi pour faire face au nombre de pages suivies par mois, plusieurs composants seront déployés et managés par cegedim.cloud afin de vous permettre de vous focaliser sur l'utilisation et la configuration de Matomo.
Ce service n'est pas disponible en libre-service et nécessite une prise de contact avec l'équipe commerciale de cegedim.cloud.
Elle est activable individuellement sur vos répartiteurs de charge directement depuis notre plateforme de gestion de cloud nommé ITCare.
Ce service n'est pas disponible en libre-service et nécessite une prise de contact avec l'équipe commerciale de cegedim.cloud.
Ce service n'est pas disponible en libre-service et nécessite une prise de contact avec l'équipe commerciale de cegedim.cloud.
Vault est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Ce service est activable en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Grâce à sa capacité à évoluer et à gérer de grandes quantités de données, GlusterFS offre des avantages tels que l'amélioration de la capacité de stockage, la tolérance aux pannes et la haute disponibilité pour diverses applications et charges de travail.
GlusterFS est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Les avantages d'une solution de stockage d'objets S3 comprennent une haute disponibilité, un stockage à faible coût, des contrôles d'accès flexibles, une redondance automatique des données et la possibilité de choisir différents fournisseurs et d'éviter la dépendance à l'égard d'un fournisseur.
Connectez-vous à la plateforme ITCare, cliquez sur le bouton Statistiques dans le menu principal à gauche. Cliquez sur "Créer une instance Matomo" et suivez les instructions.
Indiquez le service global dans lequel vous souhaitez créer une instance Matomo.
Donnez le nom de l'instance que vous voulez créer. Un nom de site web et une URL par défaut peuvent être configurés pendant le provisionnement. Ils sont facultatifs. S'ils sont laissés vides, des valeurs fictives seront utilisées. Cliquez sur Suivant.
Choisissez la taille de l'instance de Matomo Analytics correspondant à vos besoins et cliquez sur Suivant.
Fournissez le mot de passe du super utilisateur nommé "administrator" qui vous sera donné.
Le mot de passe du super utilisateur n'est pas sauvegardé par cegedim.cloud.
Veillez à sauvegarder votre mot de passe!
A l'étape suivante, vous pouvez configurer les options de gestion :
Surveillance (fortement recommandé)
Surveillance 24/7
Sauvegarde (fortement recommandé)
Réplication du stockage
Cliquez sur Suivant.
Sélectionnez la région dans laquelle vous souhaitez créer votre instance Matomo.
Cliquez sur Suivant.
Vérifiez vos entrées dans la page de synthèse. Vous pouvez :
Vérifier l'instance qui sera créée
Voir le service global cible
Enregistrer votre mot de passe administrateur
Vérifier les options de gestion
Cliquer sur Soumettre une fois prêt.
Une fois que l'instance est prête, vous recevrez un e-mail contenant les informations nécessaires pour vous y connecter.
La création d'une instance peut prendre jusqu'à 2 heures en fonction de la charge actuelle de l'automatisation. L'instance sera alors affichée dans la page de gestion, dans la section Analytique.
Allez dans le menu Statistiques du menu principal de gauche et cliquez sur le lien Gérer.
Une fois que toutes les instances Matomo sont présentées, cliquez sur le bouton de démarrage de l'instance de votre choix. Le démarrage d'une instance Matomo démarre tous les composants.
Une notification par e-mail sera envoyée lorsque le service sera activé.
Allez dans le menu Statistiques du menu principal de gauche et cliquez sur le lien Gérer.
Une fois que toutes les instances de Matomo sont présentées, cliquez sur le bouton d'arrêt de l'instance de votre choix. Saisissez un numéro RFC pour le suivi (facultatif) puis validez en cliquant sur Stop. L'arrêt d'une instance Matomo arrêtera tous les composants et la surveillance sera désactivée.
Une notification par e-mail sera envoyée lorsque l'instance sera arrêtée.
Allez dans le menu Statistiques à partir du menu principal de gauche et cliquez sur le lien Gérer.
Une fois que toutes les instances Matomo sont affichées, cliquez sur le bouton de suppression de l'instance de votre choix.
Vous ne pouvez supprimer qu'une instance déjà arrêtée.
Cette action supprimera tous les composants utilisés par cette instance Matomo.
Veuillez noter que cette action n'est pas récupérable.
Saisissez un numéro RFC pour le suivi (facultatif) et le nom de l'instance (captcha obligatoire) pour confirmer votre choix, puis cliquez sur Supprimer.
Une notification par e-mail sera envoyée lorsque l'instance sera supprimée.
Allez dans le menu Statistiques du menu principal de gauche et cliquez sur le lien Gérer.
Une fois que toutes les instances de Matomo sont présentées, cliquez sur le bouton de redimensionnement de l'instance de votre choix.
Vous ne pouvez redimensionner que si l'instance est démarrée.
Sélectionnez la nouvelle taille qui ne peut être que supérieure à la taille actuelle et cliquez sur Redimensionner.
Le service sera interrompu pendant la durée de l'opération (quelques minutes).
Une notification par e-mail sera envoyée lorsque l'instance sera redimensionnée.
Connectez-vous à votre instance Matomo Analytics avec l'utilisateur "administrator" que vous avez fourni lors du provisionnement.
Cliquez sur l'icône Administration représenté par une roue crantée :\
Sélectionnez le menu "Extensions" dans la catégorie "Système"
Allez à la fin de la page et cliquez sur le bouton "Installer de nouveaux composants" :
Recherchez, installez et activez les modules à votre guise :\
Connectez-vous à votre instance Matomo Analytics avec l'utilisateur "administrator".
Cliquez sur l'icône d'administration
Cliquez en haut de la page sur le message indiquant une nouvelle version
Confirmer la mise à jour automatique\
Attendre la fin de la mise à jour avec un message de réussite\
Il existe 3 topologies possibles pour le cluster K8s fourni par cegedim.cloud :
Standalone : les charges de travail sont déployées dans un seul centre de données sans plan de reprise après sinistre.
Standard : les charges de travail sont toujours déployées dans un seul centre de données, mais elles sont protégées contre un désastre du centre de données en utilisant un centre de données secondaire comme basculement.
Haute disponibilité : les charges de travail sont déployées dans deux centres de données et aucune interruption des services en cas de sinistre du centre de données ne peut être obtenue avec un déploiement multi-réplica correctement distribué.
cegedim.cloud fournit une topologie de calcul basée sur :
Région : une paire de centres de données
Area : isolation du réseau d'infrastructure entre les locataires
Zones de disponibilité : à l'intérieur d'une zone, infrastructure isolée pour le calcul et le stockage.
Les clusters Kubernetes peuvent être déployés à l'aide de 2 topologies :
En fonction de vos exigences en termes de RTO et de coûts, vous pouvez choisir la topologie la mieux adaptée à vos besoins.
cegedim.cloud utilise des clés topologiques standard :
Depuis Kubernetes > 1.20, failure-domain.beta.kubernetes.io/zone est obsolète mais reste disponible en cas de préexistence. Seul topology.kubernetes.io/zone sera officiellement maintenu.
Voici la liste des composants et des outils qui sont déployés dans un cluster standard livré :
Voici un schéma avec tous les composants du réseau expliqués :
Deux pods de 2 namespaces appartenant au même projet Rancher peuvent communiquer entre eux.
Deux pods de 2 namespaces appartenant à deux projets Rancher différents ne peuvent pas communiquer entre eux à moins que l'utilisateur ne définisse une Network Policy dédiée à ce besoin.
Les pods d'un projet Rancher nommé System peuvent communiquer avec les pods d'autres projets Rancher.
Les pods ne peuvent envoyer des requêtes qu'aux serveurs du même VLAN, à moins qu'une règle d'ouverture de réseau spécifique ne soit configurée entre les deux VLANs.
Les pods ne peuvent pas envoyer de requêtes à Internet à moins qu'un proxy ne soit configuré à l'intérieur du pod ou qu'une règle d'ouverture de réseau spécifique ne soit configurée pour le VLAN concerné.
Les requêtes vers le serveur api kube peuvent faire l'objet d'une proxy inverse par l'URL Rancher.
La charge de travail hébergée par les pods ne peut pas être directement accessible depuis l'extérieur du cluster K8S, mais via une couche d'entrée pour le protocole HTTP ou via un service NodePort pour le protocole TCP avec un équilibreur de charge respectif.
nginx est l'ingress controller déployé pour exposer vos workloads. Vous pouvez trouver la documentation pertinente sur le Github officiel à l'adresse :
Deux ingress controllers sont déployés :
Un exposé au réseau interne de Cegedim
ingress controller nginx
écoute sur chaque nœud de travail sur le port :80
il s'agit de la classe d'entrée par défaut (aucune classe d'entrée ne doit être spécifiée).
Un exposé à internet
nginx ingress controller - vous pouvez demander à avoir un ingress controller externe pour nginx.
écoute de chaque nœud de travail sur le port : 8081
cette ingress classe est : nginx-ext
en utilisant l'annotation : kubernetes.io/ingress.class:"nginx-ext"
Un cluster K8s est livré avec :
Un Elastic Secured Endpoint, géré par des appliances F5, exposant la charge de travail K8s au réseau interne de Cegedim (une fois que vous êtes connecté au LAN de Cegedim, soit physiquement, soit par VPN).
Une résolution DNS *.<votreclustername>.ccs.cegedim.cloud
vers ce point d'accès.
Un certificat SSL *.<votreclustername>.ccs.cegedim.cloud
configuré
Vous pouvez utiliser ITCare en cas de besoin d'une configuration spécifique :
Exposition de vos charges de travail à l'Internet ou à un lien privé
Utilisation d'un FQDN spécifique pour déployer votre charge de travail
Utilisation d'un certificat spécifique pour déployer votre charge de travail
Utilisation de Traefik comme fournisseur d'intrusion au lieu de nginx
Ajout d'autres fournisseurs d'entrée
Accès aux ressources en dehors du cluster
cegedim.cloud fournit des clusters Kubernetes gérés, avec le plus haut niveau de sécurité et de résilience intégré.
En utilisant ces clusters, vous pouvez déployer vos workloads Kubernetes standards dans les centres de données cegedim.cloud afin de maximiser la disponibilité de vos applications.
cegedim.cloud fournit également une console Rancher, où vous pouvez gérer vos workloads, et configurer les capacités d'observabilité intégrées (Logging et Métrologie) pour la connecter à vos propres plateformes (Grafana, ElasticSearch...).
Les principaux objectifs du projet Container en tant que Service sont :
Capacité à fournir des clusters Kubernetes de dernière génération à la demande.
Application Stateful supportée
Prise en charge des volumes persistants avec Auto-Provisioning et Haute Disponibilité
Respecter les normes réseau, les règles de stockage et de sécurité.
Une sécurité renforcée
Système de surveillance et de métriques intégré à la demande pour chaque application
Prise en charge des règles de réseau dynamiques
La facturation est mensuelle et basée sur le nombre de nœuds et sur les coûts supplémentaires tel que le stockage et la sauvegarde.
L'estimation des coûts pour un cluster Kubernetes est disponible via votre Service Delivery Manager.
Kubernetes dispose de fonctionnalités et de mécanismes intégrés pour maintenir en bonne santé les nœuds et les workoads kubernetes :
kube-scheduler décide sur quels nœuds placer les pods en fonction des ressources demandées par les pods et des ressources non réservées des nœuds.
kubelet Out-Of-Memory tue les pods qui consomment plus de ressources que les valeurs limitées définies dans la spécification (OOM killed).
Pour quelque raison que ce soit, si le nœud est à court de ressources, kubelet expulse les pods afin d'alléger la pression sur les nœuds (éviction des pods). La décision d'éviction des pods est basée sur la qualité de service des pods.
Gardez à l'esprit que cegedim.cloud fournit des clusters Kubernetes standard avec ces fonctionnalités et a qualifié les documentations officielles de Kubernetes ci-dessous :
Le problème se situe au niveau de l'application dans la vie réelle :
toutes les technologies ne sont pas nativement compatibles avec les conteneurs
les mesures d'utilisation des ressources collectées par le kubelet (ou l'exportateur de nœuds, etc.) ne sont pas en temps réel
les mesures d'utilisation des ressources ne sont pas prises en compte par le planificateur kube
kubelet, en tant que processus Linux, n'est pas toujours le processus le plus prioritaire, en particulier lorsque les nœuds n'ont plus de CPU.
L'incapacité à gérer les contraintes de ressources sur les nœuds par kubelet conduit à des défaillances de nœuds et au redéploiement de toutes les charges de travail correspondantes. Dans le pire des cas, un effet domino sur la défaillance des nœuds peut se produire.
cegedim.cloud fournit une solution de hardening appelée cgdm-hardening :
Un esclave de hardening de pods par nœuds de travail : écrit la consommation de CPU et de RAM dans une base de données centralisée.
Un pod de hardening-maître déployé sur les nœuds maîtres : il lit les métriques dans la base de données et prend des mesures en cas de crise.
L'empreinte de la pile de hardening sur les ressources est très faible
Le pod Hardening-master
peut agir selon deux modes :
Mode préventif (en tant qu'assistant du planificateur kube, mode par défaut) :
Place le taint cegedim.io/overload=true:NoSchedule pour éviter de placer plus de pods sur des nœuds sous pression (85% RAM ou 90% CPU). Lorsque le CPU est inférieur à 85% et que la RAM est inférieure à 80%, l'altération est supprimée.
Mode de protection (en tant qu'assistant du contrôleur de kube) :
Lorsque la consommation de RAM atteint 95 %, il tue les pods les plus récents, l'un après l'autre, pour soulager la pression. Il n'est pas activé par défaut.
Vous ne devez jamais utiliser la wildcard tolérance dans les applications, sinon l'effet préventif de cette solution ne sera pas valable.
Limitation : cette solution ne permet pas de protéger les nœuds qui tombent en panne en raison d'un pic d'utilisation extrêmement élevé du CPU pendant une période de temps très courte.
Le nouveau cluster Kubernetes sera provisionné avec le hardeing préventif activé.
Si les charges de travail déployées par les clients entraînent un grand nombre de défaillances de nœuds (TLS_K8_NODES), le mode de protection sera activé.
Le client peut désactiver ce hardening en créant un ticket requête dans ITCare.
Par conséquent, la vérification TLS_K8_NODES de centreon au niveau du cluster et la vérification de l'état de santé de centreon sur les nœuds de travail seront désactivées.
Cela signifie que les clients doivent redémarrer eux-mêmes les nœuds en cas de crise.
Le client peut réactiver ce hardening en faisant un ticket requête ITCare à tout moment.
Les distributions Linux suivantes sont disponibles lorsque vous sélectionnez Linux comme système d'exploitation pour votre Instance Virtuelle :
Centos
Debian
Ubuntu
Red Hat Linux Enterprise (RHEL)
Oracle Linux
Oracle Linux 9 propose deux noyaux : l'un entièrement compatible avec RedHat 9 et l'autre qualifié d'« incassable », optimisé pour les applications Oracle.
Windows Server est disponible comme système d'exploitation pour votre Instance Virtuelle. cegedim.cloud supporte plusieurs versions de Windows Server 2022 à Windows Server 2012R2.
cegedim.cloud supporte le système d'exploitation IBM AIX sur les systèmes IBM Power. La version actuellement supportée est la version majeure 7 et les versions de niveau technologique associées.
Les instances virtuelles sont disponibles dans les centres de données cegedim.cloud suivants :
EB4 - Boulogne-Billancourt, France
EB5 - Magny-les-Hameaux, France
ET1 - Labège, France
ET2 - Balma, France
Une Instance Virtuelle peut être configurée et personnalisée selon vos besoins :
Calcul : nombre de vCPU
RAM : quantité de mémoire allouée (varie en fonction du nombre de vCPU)
Stockage : disques et stockage supplémentaires en Go à allouer à l'instance virtuelle
Cette section énumère les fonctions / capacités disponibles pour le client, et la manière de les demander / de les exécuter :
L'authentification dans l'instance virtuelle est basée sur Active Directory pour Linux et Windows (pas pour AIX qui reste en utilisateurs locaux). L'utilisateur demandeur sera automatiquement ajouté en tant qu'administrateur de l'instance virtuelle. Cet utilisateur est ensuite libre de configurer et d'ajouter d'autres utilisateurs avec les privilèges souhaités.
La sauvegarde est une option qui peut être activée pour votre instance virtuelle. Dans un environnement de production, l'option de sauvegarde sera toujours activée par défaut dans ITCare.
Vous pouvez désactiver l'option de sauvegarde à vos risques et périls.
Les sauvegardes sont effectuées tous les jours et sauvegardées dans le centre de données local, puis répliquées dans un second centre de données sur le campus. La durée de conservation des sauvegardes pour les instances virtuelles est de 28 jours par défaut, mais elle peut être adaptée à vos besoins avec votre Service Delivery Manager.
La date de la dernière sauvegarde et l'empreinte de stockage de la sauvegarde peuvent être consultées directement dans ITCare sur la page des détails de la ressource de votre instance virtuelle.
Comme indiqué, les instances virtuelles sont gérées et la surveillance est donc assurée si l'option a été cochée. Dans un environnement de production, l'option de surveillance est toujours activée par défaut.
Vous pouvez désactiver l'option de surveillance à vos risques et périls.
En activant la surveillance, plusieurs contrôles de santé seront déployés pour s'assurer que votre instance virtuelle fonctionne et reste saine. Si l'un de ces contrôles est déclenché, notre équipe de support est avertie par un ticket afin de résoudre le problème dans le cadre du niveau d'accord de service autorisé.
Ces alertes de surveillance peuvent être consultées directement dans ITCare et des métriques de performance sont également fournies pour les indicateurs clés tels que le CPU, la mémoire, le disque et la consommation du réseau.
Lorsque la surveillance est activée, elle n'est effective que pendant les heures ouvrées. Pour étendre la surveillance en dehors des heures ouvrées, l'option 24x7 peut être activée et des frais supplémentaires seront appliqués.
Cette option garantit que votre instance virtuelle est surveillée à tout moment par notre équipe de support et que des mesures seront prises pour escalader et résoudre tout problème.
La surveillance 24x7 n'est pas obligatoire et ne peut être activée que lorsque l'option de surveillance est activée.
La réplication des données est une fonction qui permet la protection de la reprise après sinistre. Lorsque cette fonction est activée, les données de votre instance virtuelle sont répliquées depuis la baie de stockage locale vers une baie de stockage hors site.
Cela signifie qu'en cas de perte du centre de données local, vos données sont toujours en sécurité dans un autre centre de données et la procédure de restauration et de relance de votre Instance Virtuelle peut être activée.
Vous pouvez désactiver l'option de réplication à vos risques et périls.
Les distributions Linux suivantes peuvent être renforcées pendant l'approvisionnement :
Debian à partir de la version 11
Ubuntu à partir de la version 22.04
Oracle Linux à partir de la version 9
Certains systèmes de fichiers faibles sont désactivés dans le noyau
Points de montage séparés pour les systèmes de fichiers très actifs : /var/log, /var/log/audit, /var/tmp
Protection des points de montage /var/log, /tmp et /var/tmp
Désactivation du stockage amovible
S'assurer que le mot de passe root est requis pour démarrer en mode de secours
Traçage de chaque utilisation de la commande sudo
Plusieurs paramètres sont activés dans le noyau pour protéger les processus en cours d'exécution
Les services réseau inutiles ou faibles sont désactivés (appliqué par le gestionnaire de configuration)
Le service de gestion du temps est configuré et actif
IPV6 est désactivé
Plusieurs paramètres du noyau sont définis pour protéger le réseau
Désactiver les protocoles réseau peu courants
Centralisation des journaux du système
S'assurer que chaque événement est enregistré
S'assurer que le service cron est actif et configuré
S'assurer que les répertoires cron sont protégés
S'assurer que ssh est actif et configuré
Forcer les protocoles et paramètres sécurisés de ssh
S'assurer de la désactivation des sessions inactives
S'assurer que les règles de mot de passe fort sont appliquées
S'assurer que les fichiers d'authentification sensibles sont protégés
cegedim.cloud propose désormais une plateforme de stockage Ceph multi-locataires en tant que fournisseur de CSI avec les spécifications suivantes :
Les données sont répliquées 4 fois et réparties uniformément (à l'aide de Ceph Crush Map) sur 2 centres de données afin de garantir que, dans les scénarios de catastrophe, 2 répliques de données sont toujours disponibles.
Chaque cluster Kubernetes, en tant que client Ceph, dispose de son propre pool de données sur le serveur Ceph et consomme des services avec ses propres identifiants.
Seul le RBD Ceph CSI est fourni pour le moment.
cegedim.cloud utilise External Snapshotter pour prendre des clichés et restaurer le PVC de vos clusters Kubernetes.
Toutes les informations relatives à cette application sont disponibles à l'adresse suivante :
Il est recommandé de nommer la classe d'instantanés d'après la classe de stockage. Il suffit d'exécuter la commande ci-dessous pour vérifier :
Pour répertorier tous les CSI disponibles dans un cluster Kubernetes, procédez comme suit :
Voici une correspondance entre la classe de stockage et le CSI :
Managed MariaDB
MariaDB est un système de gestion de base de données open-source créé par les développeurs de MySQL. MariaDB utilise des tables pour stocker les données de manière organisée et il est possible d'interagir avec la base de données à l'aide de requêtes SQL.
Il prend en charge des concepts tels que les clés primaires, les index et les relations entre les tables. MariaDB est largement utilisé pour le stockage et la gestion des données dans diverses applications, des sites web aux systèmes d'entreprise. C'est un choix populaire en raison de sa fiabilité, de ses performances et de sa nature open-source.
MariaDB est déployé on-premise dans les centres de données de cegedim.cloud.
La version support à long terme (LTS) peut être déployée en self-service à l'aide d'ITCare.
Le même niveau de service que l'offre Compute est garanti : déploiement d'instances, maintien en condition opérationnelle, flexibilité, sécurité et monitoring sont ainsi assurés par nos experts.
Deux topologies sont disponibles en libre-service :
Instance autonome
Cluster Galera (3 nœuds)
Le cluster Galera est prêt pour la production avec au moins 3 nœuds répartis sur toutes les zones de disponibilité d'une Région cible.
Le dimensionnement peut être configuré selon vos besoins.
La facturation est mensuelle et basée sur le nombre d'instance plus des coûts supplémentaires pour le stockage, la sauvegarde, la surveillance 24/7.
L'estimation du coût d'une instance MariaDB est disponible via votre Service Delivery Manager.
Ce guide présente l'ensemble des éléments de configuration nécessaires pour améliorer la disponibilité et la continuité de service de vos applications déployées dans un cluster Kubernetes managés par cegedim.cloud.
Il s'agit d'un guide indispensable pour que votre stratégie de reprise après sinistre réponde aux exigences de cegedim.cloud.
Une fois votre cluster Kubernetes configuré pour fonctionner selon la topologie de haute disponibilité (HA), certaines bonnes pratiques de configuration sont nécessaires pour permettre à vos applications :
pour fonctionner de façon simultanée sur tous les centres de données de la région.
de disposer d'une capacité suffisante dans tous les centres de données en cas de catastrophe sur l'un d'entre eux
Pour rappel, les nœuds des clusters Kubernetes sont répartis dans 3 zones de disponibilité (AZ) et 2 centres de données :
AZ "A" et "B" fonctionnent sur le centre de données primaire.
AZ "C" fonctionne sur le centre de données secondaire.
Pour les services sans état qui prennent en charge la mise à l'échelle, la meilleure pratique consiste à faire fonctionner au moins trois pods :
Ces 3 pods doivent être correctement configurés pour qu'au moins un pod fonctionne sur chaque zone de disponibilité :
Nous utilisons preferedDuringSchedulingIgnoredDuringExecution
et non requiredDuringSchedulingIgnoredDuringExecution
car nous voulons que cette exigence soit "souple" : Kubernetes permettra alors de programmer plusieurs pods sur la même AZ si vous exécutez plus de répliques que d'AZ, ou en cas de défaillance d'une zone.
Dans kube 1.20, failure-domain.beta.kubernetes.io/zone
sera déprécié, la nouvelle clé de topologie sera topologie.kubernetes.io/zone
Si vous utilisez la topologie de cluster haute disponibilité, votre objectif est de déployer des applications résilientes en cas de panne du centre de données.
Cette page décrit quelques bonnes pratiques pour déterminer le dimensionnement des nœuds de travail pour chaque zone de disponibilité où vos charges de travail sont exécutées.
Pour rappel, Kubernetes Cluster est déployé dans 3 zones de disponibilité, et 2 centres de données. Dans le pire des cas, une seul zone de disponibilité fonctionnera si le centre de données primaire subit un sinistre majeur.
C'est l'hypothèse à prendre en compte pour déterminer le dimensionnement "nominal", que l'on peut appeler "Si le centre de données primaire tombe en panne, de quelle capacité de CPU / RAM ai-je besoin pour continuer à faire fonctionner mon application ?".
Pour déterminer cette capacité, puis les nœuds de travail déployés dans la zone de disponibilité "C" (combien, et avec quelles ressources), vous aurez besoin de 3 paramètres :
Vous avez alors deux possibilités pour calculer la taille :
Au niveau de la granularité "Cluster Level": si vous débutez le processus et que vos charges de travail ne sont pas aussi complexes ou variables, utilisez cette option :
Déterminer un MBCO global pour les déploiements croisés
Additionner toutes les demandes de ressources des pods pour obtenir un numéro unique.
Additionner toutes les ressources utilisées par les pods pour obtenir un nombre unique.
Au niveau de la granularité "Pod Level" : Si vous voulez que le dimensionnement soit parfaitement adapté et que vous en avez le temps, prenez le temps de déterminer ces paramètres pour chaque déploiement de votre cluster Kubernetes, car le MBCO peut varier ! Par exemple :
Une application web nécessitera un MBCO avec 100 %.
Un cache nécessitera un MBCO de 50%.
Une fonctionnalité "agréable à avoir" ou un outil interne peut être à 0 %.
Le calcul au "niveau de cluster" n'est pas assez précis pour être absolument certain que le cluster sera d'une taille appropriée. Il suffit de le savoir et d'évaluer si cela vaut la peine de prendre le risque.
Dans tous les cas, ce dimensionnement doit être réévalué régulièrement, en fonction des nouveaux déploiements ou des redimensionnements que vous effectuez dans vos opérations quotidiennes.
Si vous avez additionné toutes les demandes et l'utilisation, et que vous avez déterminé le MBCO au niveau du "cluster", vous pouvez utiliser cette formule simple pour calculer le dimensionnement requis pour l'AZ "C" dans le centre de données secondaire :
Si vous avez déterminé un MBCO par déploiement, vous devrez calculer votre dimensionnement avec une formule plus complexe :
Une fois que vous avez calculé votre MBCO, il est important de tirer parti des capacités de Kubernetes (QoS, notamment PodDisruptionBudget
) pour que votre déploiement suive votre décision.
Utilisez ITCare ou demandez l'aide de notre support pour dimensionner votre cluster.
Au cours de cette phase, vous devrez hiérarchiser vos actifs et définir les composants qui sont essentiels à la disponibilité de vos services.
connaître l'utilisation de vos ressources, une fois le déploiement effectué, il est bon d'observer la consommation de ressources de votre charge de travail.
Dans Kubernetes il y a 3 classes de QoS :
Garantie
Burstable
BestEffort
Pour les charges de travail critiques, vous pouvez utiliser la QOS "garantie", qui définit simplement les limites de ressources égales aux demandes de ressources :
Pour les charges de travail moins critiques, vous pouvez utiliser le QOS "Burstable", qui définira les limites de ressources et les demandes.
Le budget de perturbation des pods vous permettra de configurer votre tolérance aux pannes et le nombre de pannes que votre application peut supporter avant d'être indisponible.
Avec une charge de travail sans état, l'objectif est d'avoir un nombre minimum de pods disponibles à tout moment, pour ce faire vous pouvez définir un simple budget de perturbation des pods :
Avec une charge de travail à état, le but est d'avoir un nombre maximum de pods indisponibles à tout moment, afin de maintenir le quorum par exemple :
Scénarios de trafic élevé :
Rancher supporte la même authentification SSO que ITCare.
Selon la localisation de votre cluster, Rancher est accessible avec les URL suivantes :
Dans ITCare, vous pouvez trouver l'URL de votre cluster dans la page de détail de celui-ci :
Rancher demandera une authentification lors de la première connexion : cliquez simplement sur "Login with Keycloak".
Vous serez ensuite redirigé vers la mire de connexion :
Une fois connecté, vous devriez avoir un écran listant tous les clusters auxquels vous avez accès :
Si l'interface se coince après l'authentification, merci d'essayer ces liens :
Si lors de la première connexion vous ne voyez pas votre cluster dans la liste des clusters, vous pouvez vous déconnecter et vous reconnecter.
Vous pouvez gérer vos préférences d'interface utilisateur (thème sombre, nombre de lignes par tableau...) en configurant vos préférences utilisateur. Veuillez vous référer ici à la documentation complète ci-dessous.
Afin de se connecter au cluster en utilisant la CLI, vous avez deux options :
par kubectl
normal à distance
en utilisant rancher online kubectl
.
Les deux sont disponibles en accédant à la page "cluster" dans Rancher.
Il y a deux façons de le faire :
Cliquez sur le nom du cluster dans la liste des clusters.
Cliquez sur le nom du cluster dans le menu supérieur gauche.
Une fois sur la page d'accueil du cluster, vous pouvez télécharger le "KubeConfig File" :
Ou bien juste copier le contenu du "Kubeconfig File" :
Si vous ne disposez pas dekubectl,
nous vous conseillons vivement d'installer kubectl
sur votre poste d'administration en suivant le lien ci-dessous.
Cette configuration peut être mélangée avec d'autres configurations kubectl.
L'authentification peut être partagée avec tout cluster géré par la même instance de rancher.
Une fois sur la page d'accueil du cluster, vous pouvez utiliser le web CLI en cliquant sur l'icône ci-dessous:
Cela devrait lancer un shell web comme celui-ci :
Ce shell est temporaire, tout changement effectué à l'intérieur sera supprimé une fois la fenêtre fermée.
Cette session peut être déconnectée si aucune entrée/sortie n'est observée.
La gestion des jetons est disponible juste en dessous de l'avatar de l'utilisateur :
Il existe deux champs d'application :
no-scope : global scope : utilisé pour interagir avec l'API globale de Rancher
cluster-scoped : jeton dédié à l'accès à un cluster spécifique
Un jeton à portée de cluster est nécessaire pour utiliser helm 3. Cela signifie que vous avez besoin d'un jeton par cluster dans vos pipelines CI/CD
Les jetons peuvent avoir des cycles de vie différents :
Une durée de vie illimitée, il suivra le cycle de vie du compte qui lui est rattaché
Une durée limitée
Vous pouvez utiliser ITCare pour ajouter ou supprimer des nœuds à votre cluster.
Rancher gère les espaces de noms via project, qui est un concept n'existant spécifiquement que dans les clusters Kubernetes gérés par Rancher.
Le projet n'est pas une ressource native de Kubernetes. Par défaut, un cluster Kubernetes est provisionné avec 2 projets :
System : contenant les espaces de noms des composants principaux comme : kube-system, etc.
Default : contenant l'espace de noms "par défaut".
Les utilisateurs sont libres de créer d'autres projets si nécessaire. En se basant sur le niveau du projet, Rancher offre une automatisation intégrée comme : l'octroi de droits d'accès, l'isolation du réseau, etc.
Les utilisateurs sont fortement encouragés à classer les espaces de noms dans un projet.
Passer à la vue projet
Créer un nouvel espace de noms à partir de la vue du projet
Insérez un nom unique et remplissez les autres champs si nécessaire, puis cliquez sur "Créer"
Si vous créez un espace de noms avec le CLI de kubernetes, par exemple kubectl, l'espace de noms créé sera déplacé dans le projet parent de l'espace de noms "default" (qui est, par défaut, le projet nommé Default).
cegedim.cloud recommande et supporte officiellement la gestion des droits d'accès via les groupes AD.
Seuls les groupes AD commençant par G_EMEA_* et G_K8_* sont connus par Rancher.
Par défaut, lors de la création d'un cluster :
Le rôle d'utilisateur standard est donné au groupe G_K8_<NOM_DU_CLUSTER>_USERS qui contient les power users du Cloud associé.
Le rôle d'administrateur est attribué au groupe G_K8_<NOM_DU_CLUSTER>_ADMINS qui est vide par défaut et peut être complété par des utilisateurs compétents et certifiés via un ticket ITCare vers l'équipe de support AD.
Par exemple, l’utilisateur user1@cegedim.com a besoin d’accès standard au cluster test-preprod, il doit faire une demande pour l'ajouter dans le groupe AD nommé G_K8_TEST_PREPROD_USERS.
Lorsque les utilisateurs créent un nouveau projet, en tant que propriétaire par défaut, ils sont libres de lier n'importe quel rôle à n'importe quel groupe AD dans le cadre de ce projet.
Si les rôles prédéfinis de Rancher ne peuvent pas répondre à vos besoins, veuillez contacter les administrateurs de votre cluster pour configurer un rolebinding personnalisé ou un clusterrolebinding.
Dans cette partie, nous supposerons que les droits sont donnés à un groupe et non à un utilisateur.
Pour gérer les droits sur un projet, il existe deux moyens : L'interface utilisateur ou l'API.
L'un des rôles les plus élevés que vous pouvez attribuer est "Project Admin".
Utilisation de l'interface utilisateur
Éditez le projet dont vous êtes propriétaire ou sur lequel vous avez suffisamment de droits accordé par le propriétaire.
Sélectionnez le groupe et le rôle dans la formulaire.
A noter que seuls les groupes préfixés par G_EMEA_* and G_K8_* sont reconnus par Rancher.
Utilisation de l'API
En utilisant l'API, c'est assez simple. Vous aurez d'abord besoin de quelques paramètres :
Obtenir l'ID du projet
Pour obtenir l'ID du projet, vous pouvez utiliser l'explorateur d'API en utilisant simplement le bouton "View in API".
Obtenir l'ID du rôle
Pour obtenir l'ID du rôle, il se peut que vous ne soyez pas autorisé à l'afficher via l'interface utilisateur, mais vous l'obtiendrez via cette requête API :
Donner des autorisations
En utilisant votre clé API, vous pouvez faire une demande POST pour créer le lien de rôle :
Les version api de ressources Kubernetes peuvent être obsolètes, voire supprimés lors de la mise à jour de version Kubernetes.
Il y a une risque de cassure si vous avez des ressources avec une version api supprimé dans la nouvelle version de Kubernetes.
Pour éviter cela, une des solutions est d'utiliser l'outil "kubent" pour vérifier la compatibilité .
Kubent détecte les objets obsolètes du cluster Kubernetes. Vous devez migrer/modifier les ressources identifiés avant la mise à jour de version Kubernetes.
Pour installer kubent :
Pour identifier les objets obsolètes qui vont être supprimés dans la prochain version Kubernetes :
Un exemple de l'output :
Dans ce tutoriel, si votre cluster est planifié pour une mise à jour vers version Kubernetes 1.22, vous devez migrer votre resource ingress nommé "toto" de version api networking.k8s.io/v1beta1
vers networking.k8s.io/v1
avant la mise à jour.
Cette migration peut impliquer une modification des champs supplémentaires de la ressource. Veillez consulter la documentation officielle :
Dans cet exemple, nous allons configurer le transfert de logs d'un cluster Kubernetes vers un cluster OpenSearch.
Le cluster OpenSearch est dans cet exemple my-cluster.es.cegedim.cloud
Le nom de la sortie du cluster est my-cluster-output
.
Dans Rancher, sous Logging > ClusterOutput et Logging > Output, modifiez la configuration YAML et changez ceci :
ClusterFlow/ClusterOutput présentent de nombreux problèmes lors de l'envoi de logs à OpenSearch / ELK cluster : Conflit de type de valeur attendue avec la même clé (par exemple, une valeur changée de "long" à "string" sera rejetée par OpenSearch / ELK Cluster).
Cela peut se produire isi vous avez activé Dynatrace.
Voici des exemples complets de la spécification ClusterOutput/Output pour ElasticSearch et OpenSearch :
Il y a deux options :
Migration vers Flow/ClusterOutput : poussera tous les logs des espaces de noms vers le même index OpenSearch.
Migration vers Flow/Output : poussera les logs des espaces de noms séparés vers des index OpenSearch dédiés.
La recommandation est de migrer vers "Flow/Output", et même d'avoir un index OpenSearch dédié pour les applications très importantes.
Créer un fichier avec tous les espaces de noms :
Créer des fichiers K8s YAML pour configurer les logs sur tous les espaces de noms :
Appliquer la configuration :
Créer un fichier avec tous les espaces de noms :
Créer des fichiers K8S YAML :
Appliquer la configuration :
Aucun tampon important ne devrait se produire si tout se passe bien. Vérifions le
Vérifions les 5 dernières lignes du journal de Fluentd :
Jetez un coup d'œil dans /fluentd/log/out
à l'intérieur du pod fluentd
, mais la plupart du temps, ce qui suit vous aidera :
Il est facile d'identifier le pod à l'origine du problème :
Il faut comprendre que l'erreur n'est pas dans Kubernetes, c'est le conteneur qui produit des logs incohérents au format json. Ensuite, OpenSearch rejette les journaux envoyés. Banzai réessayera et tôt ou tard, le débordement arrivera.
Sources :
Une solution à court terme peut être choisie ci-dessous :
Retirer le pod du flux (exclusion du pod) ou désactiver l'ensemble du flux de l'espace de noms concerné.
Nettoyer l'index lié dans le serveur ES
Solution à long terme :
Adapter l'application pour produire un journal plus cohérent
Voir s'il est possible de configurer ES pour qu'il ignore gentiment, mais ne rejette pas, le paquet entier envoyé par Banzai.
L'édition communautaire de MariaDB est disponible en libre-service en deux topologies :
Un cluster Galera s'appuyant sur 3 instances actives/actives
Pour plus d'informations sur l'architecture de MariaDB :
Les instances MariaDB sont accessibles sur le port 3306 par défaut.
MariaDB est disponible dans les centres de données cegedim.cloud suivants :
EB4 (Boulogne-Billancourt, France)
ET1 (Labège, France)
Dans certains cas, lorsqu'un troisième nœud est déployé (cluster Galera), des centres de données secondaires proches peuvent également être utilisés pour assurer une résilience maximale :
EB5 (Magny-les-Hameaux, France)
ET2 (Balma, France)
La plateforme en tant que service de MariaDB est hébergée sur la distribution Linux Debian 10.
La taille minimale requise est de 2 CPU et 4GB de RAM.
Le stockage peut être configuré pendant le provisionnement et augmenté par la suite sur demande.
Il s'agit d'une instance simple déployée dans un seul centre de données.
Deux instances MariaDB sont déployées dans le même centre de données : le nœud principal avec une réplique en lecture seule.
Déployé uniquement sur requête !
Un cluster MariaDB Galera est un cluster multi-primaire virtuellement synchrone pour MariaDB.
Un cluster basé sur 3 instances actives/actives est déployable dans n'importe quel centre de données de cegedim.cloud.
La version prise en charge est la dernière LTS (long term support) actuellement disponible.
Pour plus d'informations, veuillez consulter les versions de MariaDB.
Cette section énumère les fonctionnalités disponibles pour le client, ainsi que la manière de les demander ou de les exécuter :
Quelques paramètres MariaDB par défaut configurés par cegedim.cloud :
La politique de sauvegarde pour MariaDB est configurée comme suit :
Sauvegarde complète chaque week-end (en ligne)
Sauvegarde différentielle tous les jours (en ligne)
Sauvegarde de Binlog toutes les deux heures
La rétention de sauvegarde par défaut pour les sauvegardes complètes et les sauvegardes dépendantes est de deux semaines.
L'authentification de MariaDB est basée sur l'utilisateur interne.
Un utilisateur d'administration est fourni au client lorsque le provisionnement est terminé.
Le mot de passe de cet utilisateur n'est pas stocké ni sauvegardé par cegedim.cloud. Veillez à l'enregistrer dans votre propre coffre-fort.
Dans le cadre de notre offre de bases de données gérées, MariaDB fait l'objet d'une surveillance spécifique en plus du système sous-jacent afin de garantir la disponibilité et les performances du service.
Les indicateurs clés suivants de MariaDB sont surveillés et suivis :
Nombre de connexions client interrompues
Nombre de tentatives de connexion au serveur ayant échoué
Nombre de connexions refusées en raison d'erreurs internes du serveur
Nombre maximal de connexions simultanées ouvertes
Connectez-vous à la plateforme ITCare, recherchez le service global auquel attacher le cluster et cliquez dessus.
Cliquez sur le bouton Créer une ressource dans votre Service Global et sélectionnez OpenSearch. Donnez un nom unique au cluster et définissez un nom de préfixe qui sera utilisé pour nommer les machines virtuelles. Cliquez sur Suivant.
Sélectionnez le nombre de nœuds et la taille des nœuds. Cliquez sur Suivant.
Sélectionnez le volume de stockage. Cliquez sur Suivant.
Sélectionnez la région et la zone dans laquelle vous souhaitez installer votre cluster. Cliquez sur Suivant.
Sélectionnez le VLAN dans lequel vous souhaitez déployer votre cluster. Cliquez sur Suivant.
Activez ou désactivez les options supplémentaires :
Surveillance des machines virtuelles et des clusters
Surveillance 24/7
Sauvegarde
Réplication des machines virtuelles (récupération en cas de désastre)
Cliquez sur Suivant.
Sélectionnez la version et définissez un mot de passe administrateur qui sera utilisé pour gérer votre cluster.
Les mots de passe ne sont pas sauvegardés par cegedim.cloud.
Assurez-vous de sauvegarder votre mot de passe!
A l'étape finale, vous pouvez vérifier la synthèse de votre demande : vérifier les noms des machines virtuelles à créer, sauvegarder votre mot de passe administrateur, modifier les options de gestion.
Cliquez sur Soumettre.
Une fois que le cluster est prêt, vous serez notifié par email avec les informations requises pour se connecter au cluster.
La création d'un cluster peut prendre jusqu'à 2 heures en fonction de la charge actuelle de l'automatisation. Le cluster sera ensuite affiché dans votre service global, dans le panneau de contrôle de gauche, sous la section cluster associé. La flèche verte indique que le cluster est actif.
Dans le panneau de contrôle gauche, cliquez sur le nom du cluster pour afficher la page de détails de celui-ci. En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Démarrer et confirmer.
Le démarrage d'un cluster démarre toutes les machines virtuelles attachées au cluster.
Une notification par courriel sera envoyée lorsque le service sera activé.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Stop.
Saisissez un numéro RFC pour le suivi (facultatif). Cliquez sur Soumettre.
L'arrêt d'un cluster arrêtera toutes les machines virtuelles attachées au cluster et la surveillance sera désactivée.
Une notification par courrier électronique sera envoyée lorsque le cluster sera arrêté.
En haut de la page du cluster, cliquez sur le nom du cluster OpenSearch, puis sur Ajouter des nœuds.
Sélectionnez le nombre de nœuds que vous souhaitez ajouter (nombre pair) et sélectionnez la nouvelle taille (cpu/ram). Spécifiez la taille du disque de données.
Une notification par courrier électronique sera envoyée lorsque tous les nœuds auront été ajoutés.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Redimensionner les nœuds.
Sélectionnez les nœuds que vous souhaitez redimensionner et sélectionnez la nouvelle taille (cpu/ram).
Chaque nœud sera redimensionné et redémarré de manière séquentielle.
Une notification par courriel sera envoyée lorsque tous les nœuds auront été redimensionnés.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Supprimer. Cette action arrêtera et supprimera toutes les machines virtuelles.
Veuillez noter que cette action n'est pas récupérable!
Saisissez un numéro RFC pour le suivi (facultatif), puis cliquez sur Soumettre.
Une notification par courriel sera envoyée lorsque le cluster sera supprimé.
La mise à niveau d'un cluster n'est pas encore implémentée dans ITCare.
Si vous souhaitez mettre à niveau votre cluster existant vers une version plus récente, vous devez envoyer une demande au support en indiquant la version souhaitée.
Pendant la mise à jour, le cluster OpenSearch continuera à fonctionner correctement car nous effectuons une mise à jour continue. Cependant, il se peut que vous constatiez une courte indisponibilité pendant la mise à jour des serveurs de tableaux de bord, qui est effectuée après la mise à jour du cluster OpenSearch.
La mise à jour de la topologie d'un cluster est proposée pour un cluster Opensearch initialement constitué de trois nœuds (topologie basique).
La mise à jour est implémentée dans ITCare via l'option "Gérer-Migrer vers un master dédié"
La migration permet d'ajouter deux nœuds Master, tout en spécialisant les (n-1) nœuds existants au rôle de Data. Le cluster sera ainsi composé de trois nœuds Master et du reste des nœuds dédiés au rôle de Data.
Pendant la mise à jour vers une topologie "Master dédié", le cluster continuera de fonctionner,bien qu'il puisse temporairement passer à un statut "Yellow".Cependant, certains objets du cluster, comme les tableaux de bord, peuvent être temporairement indisponibles. Tout reviendra à la normale une fois la migration terminée.
La fonctionnalité d'ajout de nœuds dédiés au rôle d'ingestion est disponible pour un cluster OpenSearch avec une topologie « master dédié » (cluster de cinq nœuds).
La mise en place de nœuds d'ingestion dédiés est implémentée dans ITCare via l'option "Gérer-Ajouter des noeuds d'ingestion"
Grâce à ces nœuds d'ingestion, il est possible d'isoler le processus d'ingestion des données, ce qui permet de limiter l'impact sur l'indexation ou la recherche, même en cas de volumes élevés de données entrantes. Cela améliore ainsi la stabilité et les performances globales du cluster.
Voici une version optimisée et corrigée de votre texte :
OpenSearch propose une gestion du cycle de vie des données via une architecture multi-niveaux, permettant une organisation optimisée des ressources pour s'adapter à divers cas d'utilisation de la recherche.
Les nœuds du cluster peuvent être structurés de manière à ce qu'un groupe de nœuds gère les données les plus fréquemment consultées (nœuds avec l'attribut hot). D'autres nœuds, destinés aux données moins fréquemment consultées, sont désignés avec l'attribut warm. En plus des différences d'attributs, le nombre de nœuds à chaque niveau peut également varier pour répondre aux besoins spécifiques des requêtes de recherche.
La configuration des attributs de nœud est disponible dans ITCare via l'option « Action - Définir les attributs du nœud », accessible au niveau de chaque nœud.
Usage | Méthode | Exemple | Description |
---|---|---|---|
Code | Description | Corps de réponse |
---|---|---|
Rôles | Description |
---|---|
Profils | Voir les ressources | Gérer les maintenances | Modifier les ressources | Gérer les ressources |
---|---|---|---|---|
Fonctionnalités | Label | Disponible pour |
---|---|---|
Régions | Description | Centre de données |
---|---|---|
Zone de disponibilité | Description | Centre de données |
---|---|---|
Zone de disponibilité | Description | Centre de données |
---|---|---|
Statut | Description | Code API |
---|---|---|
Instance |
---|
Pour plus d'information, veuillez consulter la page .
Les managées cegedim.cloud sont toutes, sauf AIX, disponibles à la consommation en libre-service via notre plateforme de gestion de cloud appelée ITCare.
Les sont des clusters Kubernetes dédiés disponibles à la consommation en libre-service dans notre plateforme de gestion de cloud nommé ITCare.
est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Instance autonome | Cluster Galera |
---|
est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Cluster |
---|
est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Instance autonome | Haute disponibilité |
---|
est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Instance autonome | Cluster |
---|
est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Instance autonome | Always On |
---|
est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Cluster |
---|
est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Instance autonome | Cluster |
---|
La solution est un service d'analyse et de détection de vulnérabilités sur vos ressources exposées sur Internet.
est une fonctionnalité de protection contre les bots malicieux ainsi que les dénis de service distribués.
Le service est un service sur mesure qui permet d'évaluer l'efficacité de la sensibilisation à la sécurité du courrier électronique.
La solution transforme les données sensibles contenues dans les bases de données en données moins sensibles, selon vos propres spécifications et besoins.
est un produit développé par HashiCorp qui fournit un emplacement sécurisé et centralisé pour stocker, accéder et gérer des informations sensibles, telles que des mots de passe, des clés API et des clés de cryptage. Il garantit la sécurité en offrant un contrôle d'accès, un cryptage, une journalisation d'audit et une gestion dynamique des secrets.
Cluster |
---|
La solution de supervision avancée basée sur permet d'accéder à des tableaux de bords détaillés sur vos ressources.
est un système de fichiers distribué open-source qui permet un stockage évolutif et performant sur plusieurs serveurs. Il regroupe les ressources de stockage de plusieurs machines en un seul pool de stockage, offrant un espace de noms unique pour faciliter la gestion et l'accès.
Cluster |
---|
La solution de compatible S3 (Simple Storage Service) de cegedim.cloud est un service de stockage basé dans le cloud. Elle offre un stockage évolutif, sécurisé et durable pour différents types de données, notamment des fichiers, des images, des vidéos et des sauvegardes.
Fonctionnalités | Disponibilité |
---|
Topologies | Centre de données des masters | Centre de données des workers | Zones de disponibilité des workers | Zones de disponibilité du cluster | Protection reprise après sinistre | Recovery Time Objective (RTO) |
---|
Topology | EB-EMEA | EB-HDS | ET-EMEA | ET-HDS |
---|
Pour plus de détails sur la topologie de haute disponibilité, veuillez suivre cette page :
Clé | Composant |
---|
Composants | Versions |
---|
Pour plus d'informations concernant le hardening de Kubernetes, nous vous invitons à consulter cette page :
Pour plus d'informations sur la solution de stockage persistant disponible pour cegedim.cloud de cegedim.cloud, veuillez suivre cette page :
Cluster |
---|
Pour plus d'information, veuillez consulter la page .
Fonctionnalités | Libre service | Sur demande | Commentaires |
---|
Les recommandations des ont été suivies afin de renforcer et sécuriser nos systèmes d'exploitation Linux.
De plus amples informations sur le Ceph CSI sont disponibles via le lien ci-dessous
Composant | Version |
---|
Nom | Description |
---|
EB | ET |
---|
CSI Ceph-rbd |
---|
Classes de stockage | CSI |
---|
Instance autonome | Cluster Galera |
---|
Pour plus d'information, veuillez consulter la page .
Paramètre | Description |
---|
vous pouvez accéder à vos métriques via l'interface utilisateur de rancher ou via un client comme .
cegedim.cloud utilise comme plateforme de gestion de .
Region |
---|
Kubent pourrait échouer de reporter certaine information, e.g. espace de nom de l'ingress, vous pouvez remonter l'issue à l'éditeur :
Une instance autonome (avec une réplique sur demande)
Caractéristiques | Libre service | Sur demande | Commentaires |
---|
Paramètre | Valeur | Description |
---|
Pour plus d'information sur la configuration des attributs de noeud:
Demander une liste de ressources
GET
GET /resources
Renvoie une liste d'objets de type ressources
Chercher parmi une liste de ressources
GET
GET /resources?attribute=xxxx
Renvoie une liste d'objets de type ressources filtrée sur l'attribut xxxx
Demander une ressource
GET
GET /resources/1234
Renvoie un objet de type ressources identifié par l'ID 123
Créer une ressource
POST
PATCH /resources/1234
Crée un objet ressource grâce aux attributs JSON spécifiés dans le corps de la requête
Mettre entièrement à jour une ressource
PUT
PUT /resources/1234
Met à jour complètement l'objet ressource identifié par l'ID 1234 grâce aux attributs JSON spécifiés dans le corps de la requête
Mettre partiellement à jour une ressource
PATCH
DELETE /resources/1234
Met à jour partiellement un objet grâce au contenu du corps de la requête
Supprimer une ressource
DELETE
POST /resources
Supprime l'objet ressource identifié par l'ID 1234
200
Requête traitée avec succès
Varie selon ce qui a été demandé
201
Objet créé avec succès
Objet créé
202
Ordre de création de l'objet traité avec succès, la demande sera traitée de manière asynchrone
Vide ou objet de suivi décrivant le traitement de la requête asynchrone
400
Mauvaise requête - Erreur de syntaxe ou de cohérence de la requête. Doit être corrigée par l'émetteur.
Vide ou indication de l'erreur à corriger côté client
401
Accès non authentifié à la ressource
Vide
403
Accès non autorisé
Vide
404
Ressource inexistante
Vide
409
Conflit
Vide
422
Données incohérentes
Vide
500
Erreur fatale de l'API
Vide
503
Service temporairement indisponible
Vide
Voir les ressources
Voir toutes les ressources et leurs informations. Lecture seule.
Gérer les maintenances
Capacité de gérer les maintenances.
Modifier les ressources
Capacité de modifier les ressources sauf création et suppression.
Gérer les ressources
Gestion complète des ressources.
Standard (STD)
Maintenance (DTM)
Operator (OPE)
Power (POW)
Bodies
create-instance
POW
start-instance
OPE
stop-instance
OPE
reset-instance
OPE
resize-compute-instance
OPE
delete-instance
POW
Instance monitoring
enable-monitoring-instance
OPE
disable-monitoring-instance
OPE
Snapshot of instances
create-snapshot
OPE
recover-snapshot
POW
delete-snapshot
OPE
DNS aliases of instances
create-dns
OPE
delete-dns
OPE
LoadBalancers
create-lb
POW
start-lb
OPE
stop-lb
OPE
delete-lb
POW
Monitoring of LoadBalancers
enable-monitoring-lb
OPE
disable-monitoring-lb
OPE
Manage LoadBalancers
add-member-lb
OPE
delete-member-lb
OPE
update-member-state
OPE
DNS alias of LoadBalancers
create-dns-lb
OPE
delete-dns-lb
OPE
Manage maintenance
create-maintenance
MNT
delete-maintenance
MNT
Indicators
create-indicator
POW
update-indicator
POW
delete-indicator
POW
SMS
subscribe-vortext
POW
Storage Object
create-object-stores
POW
update-object-stores
OPE
delete-object-stores
POW
Storage Object - Users
create-user-objectstores
POW
update-user-objectstores
POW
delete-user-objectstores
POW
K8S Clusters
create-cluster
POW
create-cluster-namespace
OPE
delete-cluster-namespace
OPE
create-cluster-nodes
POW
delete-cluster-nodes
POW
EB
Zone Parisienne
EB4 : Boulogne-Billancourt
EB5 : Magny-les-Hameaux
ET
Zone Toulousaine
ET1 : Labège
ET2 : Balma
EB-HDS-A
Zone cliente
EB4
EB-HDS-B
Zone cliente
EB4
EB-HDS-C
Zone cliente
EB5
EB-A
Zone réservée au groupe Cegedim
EB4
EB-B
Zone réservée au groupe Cegedim
EB4
EB-C
Zone réservée au groupe Cegedim
EB5
ET-HDS-A
Zone cliente
ET1
ET-HDS-B
Zone cliente
ET1
ET-A
Zone réservée au groupe Cegedim
ET1
ET-B
Zone réservée au groupe Cegedim
ET1
Actif
La ressource est active et le service est disponible.
ACTIVE
Préparation
La ressource est en cours d'installation ou configuration. Le service n'est pas encore disponible.
PREPARATION
Inactif
La ressource est inactive et le service est indisponible.
INACTIVE
Standard | 1 | 1 | 2 | 2 | 4h |
Haute Disponibilité | 3 | 2 | 3 | 4 | 0 - 5 min |
Standard |
High Availability |
topology.kubernetes.io/region | Région |
topology.kubernetes.io/zone | Zone de disponibilité |
kubernetes.io/hostname | FQDN du noeud |
Rancher | 2.7.6 |
Kubernetes | 1.26 |
Ingress controllers NGINX | 1.9.0 |
Prometheus | 2.38.0 |
Grafana | 9.1.5 |
Helm | 3.11.3 |
CSI Ceph | 3.9.0 |
Node OS | Ubuntu 20.04 |
CNI - canal (Calico+Flannel) | 3.25 |
Docker | 20.10.8 |
Libre service | Le client peut effectuer une action de manière autonome. |
Sur demande | Le client peut demander à l'équipe de support de cegedim.cloud de prendre les mesures nécessaires via un ticket. |
Accès SSH ou RDP | L'accès SSH ou RDP est autorisé et automatiquement fourni au demandeur de l'instance virtuelle. |
Démarrer, arrêter, redémarrer, supprimer et redimensionner une instance virtuelle | Actions disponibles en libre-service dans notre outil de gestion de la plateforme en nuage ITCare. |
Créer, supprimer, restaurer un instantané | Actions disponibles en libre-service dans notre outil de gestion de la plateforme en nuage ITCare. |
Activer ou désactiver la surveillance, le 24x7, la sauvegarde et la réplication des données | Actions disponibles en libre-service dans notre outil de gestion de la plateforme en nuage ITCare. |
Ajouter ou supprimer une plage de maintenance | Actions disponibles en libre-service dans notre outil de gestion de la plateforme en nuage ITCare. |
Modifier l'allocation de l'espace de stockage | Un ticket de requête est nécessaire pour modifier l'allocation de stockage d'une Instance Virtuelle. |
Modifier un fichier de configuration | Certains fichiers de configuration (tels que les repository) seront gérés par cegedim.cloud. Un ticket requête est nécessaire pour modifier certains de ces composants. |
Ceph Cluster | 17.2.5 |
CSI Ceph | 3.9.0 |
cgdm-rwo | Utiliser CSI Ceph rbd pour provisioner des volumes persistants |
cgdm-rwo | Ceph RBD |
Libre service | Le client peut effectuer des actions de manière autonome sur ses propres bases de données. |
Sur demande | Le client peut demander à l'équipe de support de cegedim.cloud de prendre les mesures nécessaires. |
Accès SSH | L'accès SSH n'est pas autorisé. |
Modifier le fichier de configuration de MariaDB | Sur demande via un ticket. Revue par l'équipe de cegedim.cloud. |
Jeu de caractères | utf | Jeu de caractères par défaut de la base de données |
transaction_isolation | READ-COMMITTED | Type de transaction |
max_connexions | 1000 | Nombre maximum de connexions autorisées à l'instance |
innodb_buffer_pool_size | 50% de la RAM | Mémoire tampon Innodb allouée à l'instance |
requêtes lentes | désactivé | Les requêtes lentes ne sont pas enregistrées par défaut |
Pour commencer, rendez-vous sur ITCare et recherchez votre service global cible où vous créerez votre nouveau PostgreSQL.
Recherchez votre service Global dans la barre de recherche supérieure et cliquez dessus pour afficher sa page d'information.
Une fois dans votre Service Global, cliquez sur le bouton Créer une ressource et sélectionnez PostgreSQL.
Aller sur Bases de données managées, choisir PostgreSQL et sélectionner la version requise.
Remplir le formulaire et cliquer sur Suivant. Définir les personnalisations et cliquer sur Suivant.
Valider la synthèse et soumettre le formulaire.
Le provisionnement peut prendre jusqu'à 2 heures en fonction de la charge actuelle de l'automatisation.
Une fois le déploiement prêt, vous en serez informé par e-mail.
Sur la page de ressources de votre PostgreSQL, vous pouvez effectuer toutes les actions disponibles en utilisant le bouton Gérer dans le coin supérieur droit. Cela inclut le démarrage, l'arrêt, la suppression, le redémarrage, le redimensionnement et bien plus encore.
Lorsque votre cluster est créé avec ITCare, vous avez obtenu un rôle sql avec des informations d'identification.
Avec ces informations d'identification, vous pouvez vous connecter au cluster avec son nom sur le port tcp 5432. Vous pouvez utiliser la base de données postgres pour vous connecter.
Si votre cluster s'appelle "mycluster" vous pouvez utiliser le code python suivant :
Lorsque votre cluster est créé avec ITCare, vous avez obtenu un rôle sql avec des informations d'identification.
Si vous choisissez d'activer TLS, vous avez reçu le certificat racine auquel vous devez faire confiance et que vous devez donner à la bibliothèque que vous utilisée pour vous connecter, par exemple psycopg2.
Avec ces informations d'identification, vous pouvez vous connecter au cluster avec son nom sur le port tcp 5432. Vous pouvez utiliser la base de données postgres pour vous connecter.
Si votre cluster s'appelle "mycluster" vous pouvez utiliser le code python suivant :
Il est plus sûr de ne pas utiliser un rôle d'administrateur pour les applications.
Une fois connecté, vous pouvez créer un rôle standard comme suit (remplacez <a_role>
et <very_strong_password>
par vos propres informations d'identification) :
Si vous voulez créer une base de données dont le propriétaire sera le rôle que vous venez de créer, utilisez les requêtes SQL suivantes :
Vous pouvez utiliser les requêtes SQL suivantes avec la base de données template0 comme base de données template :
Le PaaS PostgreSQL dispose d'une fonctionnalité permettant de restaurer un PaaS PostgreSQL (source) vers un autre PaaS PostgreSQL (destination) à un moment donné (en utilisant le Point-In-Time Recovery) sous les contraintes suivantes :
l'utilisateur doit avoir accès au cloud de la ferme source et de la ferme de destination
la source doit être sauvegardée (option choisie lors de la création)
la source et la destination doivent être actives
la source et la destination doivent être différentes
la source et la destination doivent être dans la même version de PostgreSQL
la source et la destination doivent être en version 12 ou supérieure
l'heure cible ne doit pas être dans le futur (délimitée à droite par l'heure actuelle).
l'heure cible ne doit pas être inférieure à 7 jours (pour les services de non-production) ou à 14 jours (pour les services de production) avec pour référence l'heure actuelle (délimitée à gauche par la rétention des sauvegardes).
Vous pouvez choisir d'inclure ou d'exclure la cible temporelle dans le processus de restauration.
Pour commencer, rendez-vous sur ITCare et recherchez votre service global cible où vous créerez votre nouveau déploiement Redis.
Recherchez votre service Global dans la barre de recherche supérieure et cliquez dessus pour afficher sa page d'information.
Une fois dans votre Service Global, cliquez sur le bouton Créer une ressource, sélectionnez Redis et la version requise.
Remplir le formulaire :
Sélectionner une topologie
Définir le nom du futur déploiement
Le dimensionnement
Le stockage requis sur chaque instance
La localisation cible
Le réseau cible
Les options de gestion (sauvegarde, surveillance, 24/7, réplication site distant)
Cliquer sur Suivant une fois les champs remplis.
A l'étape de personnalisation :
Saisir le mot de passe du compte administrateur qui sera fourni
Sélectionner les options de persistance requises
Activer ou non le chiffrement TLS
Puis cliquer sur Suivant.
Les mots de passe ne sont pas sauvegardés par cegedim.cloud.
Assurez-vous de sauvegarder votre mot de passe!
Réviser la synthèse avant de soumettre le formulaire.
Le provisionnement peut prendre jusqu'à 2 heures en fonction de la charge actuelle de l'automatisation.
Une fois le déploiement prêt, vous en serez informé par e-mail.
Ce code décrit comment se connecter sur Redis lorsque la topologie est une instance unique. Ce code est volontairement simplifié (les erreurs ne sont pas gérées), il est destiné à la démonstration uniquement.
Le langage Python est utilisé. Nous supposons que l'instance Redis est nommée pcluredis01.hosting.cegedim.cloud.
Ce code décrit comment se connecter sur Redis lorsque la topologie est Cluster (avec Sentinel). Il est volontairement simplifié (les erreurs ne sont pas gérées), il est destiné à la démonstration uniquement.
Le langage Python est utilisé.
Nous supposons que le cluster Redis est nommé redis-cluster avec un préfixe pclu. Il existe donc 3 machines :
pcluredis01.hosting.cegedim.cloud
pcluredis02.hosting.cegedim.cloud
pcluredis03.hosting.cegedim.cloud
Deux exemples sont proposés, avec et sans TLS.
Vortext est une API qui vous permet d'intégrer facilement l'envoi de SMS dans vos applications. Son API permet :
pour envoyer des SMS (max 600 caractères) aux clients des applications
pour récupérer l'état des livraisons précédentes
Cette API permet à vos applications de :
abstrait d'un fournisseur de services comme Orange ou SFR
bénéficier de tarifs avantageux, même pour un petit volume de données
bénéficient de garde-fous : nombre limité de SMS / minute ou par heure, ou liste blanche des numéros autorisés à contacter. Les intégrations sur les plateformes de développement et de test sont donc sans risque, même en cas de bug / régression de l'application, évitant les risques d'envoyer trop de SMS, ou à des destinataires que l'on voudrait éviter (clients réels).
La demande d'un compte d'accès au service se fait directement dans le portail ITCare via la page de détail du service.
Vous pouvez également demander un compte en créant une demande de support dans ITCare : vous devrez préciser dans quelle application et dans quel environnement ce compte d'accès doit être créé, ainsi que les limites que vous souhaitez.
Le mot de passe vous sera ensuite transmis par courrier électronique.
Pour plus d'information, veuillez consulter la page SMS - Didacticiels.
Vous pouvez estimer le nombre de SMS nécessaires à son envoi pour vous permettre de réduire vos coûts.
Pour plus de détails et découvrir un système de comptage, merci de visiter: https://developers.mtarget.fr/tools#main
Demandez à votre gestionnaire de compte technique les tarifs actuels par SMS envoyés sur la plateforme Vortext.
Pour commencer, allez sur ITCare et recherchez votre service global cible où vous créerez votre nouveau cluster GlusterFS.
Recherchez votre service global dans la barre de recherche supérieure et cliquez dessus pour afficher sa page d'information.
Une fois dans votre service global, cliquez sur le bouton Créer une ressource, sélectionnez GlusterFS et la version requise.
Remplissez le formulaire :
Définissez le nom du futur cluster
Stockage requis sur chaque instance
Emplacement cible
Réseau cible
Options de gestion (sauvegarde, surveillance, 24/7, réplication sur site distant)
Cliquez sur Suivant une fois que tous les champs ont été remplis.
Dans l'étape suivante, ajoutez un utilisateur et définissez le mot de passe pour le compte utilisateur qui accèdera aux volumes, puis cliquez sur Suivant.
Les mots de passe ne sont pas sauvegardés par cegedim.cloud. Veillez à sauvegarder votre mot de passe !
Lisez le résumé avant de soumettre le formulaire.
L'approvisionnement peut prendre jusqu'à 2 heures, en fonction de la charge d'automatisation actuelle.
Une fois que le déploiement est prêt, vous en serez informé par courrier électronique.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Démarrer et confirmer.
Le démarrage du cluster démarre toutes les machines virtuelles attachées au cluster.
Une notification par e-mail sera envoyée lorsque le service sera activé.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Arrêter.
Saisissez un numéro RFC pour le suivi (facultatif). Cliquez sur Soumettre.
L'arrêt d'un cluster arrêtera toutes les machines virtuelles attachées au cluster et la surveillance sera désactivée.
Une notification par e-mail sera envoyée lorsque le cluster sera arrêté.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Redimensionner.
Sélectionnez les nœuds que vous souhaitez redimensionner et choisissez la nouvelle taille (cpu/ram).
Chaque nœud sera redimensionné et redémarré séquentiellement.
Une notification par courriel sera envoyée lorsque tous les nœuds auront été redimensionnés.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Supprimer. Cette action arrêtera et supprimera toutes les machines virtuelles.
Veuillez noter que cette action n'est pas récupérable !
Saisissez un numéro RFC pour le suivi (facultatif), puis cliquez sur Soumettre.
Une notification par courrier électronique sera envoyée lorsque le cluster sera supprimé.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Ajouter un volume.
Avant de soumettre, veuillez fournir :
Le volume de stockage souhaité en Go
Le nom d'utilisateur du propriétaire qui accèdera au volume et son mot de passe.
Une notification par e-mail sera envoyée lorsque le volume aura été créé.
Dans l'onglet Volumes de la page du cluster, cliquez sur le bouton Flèche dans la colonne Actions, puis sur Supprimer.
Confirmez la suppression en tapant le nom du volume, puis validez.
Une notification par courriel sera envoyée lorsque le volume aura été supprimé.
Dans l'onglet Volumes de la page du cluster, cliquez sur le bouton Flèche dans la colonne Actions, puis sur Redimensionner.
Indiquez la taille souhaitée en Go, puis validez.
Une notification par courriel sera envoyée lorsque le volume aura été redimensionné.
Dimensions |
|
Surveillance |
Surveillance 24x7 |
Sauvegarde |
Réplication de données (PRA) |
Disponibilité | 99,8% |
Choix de la région |
Libre-service |
Instances | 1 | 3 |
CPU (par instance) | 2 - 16 vCPU | 2 - 16 vCPU |
RAM (par instance) | 4 - 384 Go | 4 - 384 Go |
Stockage (par instance) | 10 - 2048 Go | 10 - 2048 Go |
Version(s) supportée(s) | 10.6 | 10.6 |
Surveillance |
Surveillance 24/7 |
Sauvegarde |
Réplication (PRA) |
Disponibilité | 99,8% | 99,9% |
Déploiement Multi-AZ |
Instances | 3 - 5+ |
CPU (par instance) | 2 - 16 vCPU |
RAM (par instance) | 4 - 384 Go |
Stockage (par instance) | 100 - 8000 Go |
Version(s) supportée(s) |
|
Surveillance |
Surveillance 24/7 |
Sauvegarde |
Réplication (PRA) |
Disponibilité | 99,9% |
Déploiement Multi-AZ |
Instance | 1 | 2 |
CPU (par instance) | 2 - 16 vCPU | 2 - 16 vCPU |
RAM (par instance) | 4 - 384 Go | 4 - 384 Go |
Stockage (par instance) | 10 - 2048 Go | 10 - 2048 Go |
Versions supportées | 10 à 15 | 12 à 15 |
Surveillance |
Surveillance 24/7 |
Sauvegarde |
Réplication (PRA) |
Disponibilité | 99,8% | 99,9% |
Déploiement Multi-AZ |
Instance(s) | 1 | 3 |
CPU (par instance) | 2 - 16 vCPU | 2 - 16 vCPU |
RAM (par instance) | 4 - 384 Go | 4 - 384 Go |
Stockage (par instance) | 10 - 2048 Go | 10 - 2048 Go |
Version(s) supportée(s) | 6.2 | 6.2 |
Surveillance |
Surveillance 24/7 |
Sauvegarde |
Réplication (PRA) |
TLS/SSL |
Disponibilité | 99,8% | 99.9% |
Déploiement Multi-AZ |
Instance(s) | 1 | 3 |
CPU (par instance) | 2 - 16 vCPU | 2 - 16 vCPU |
RAM (par instance) | 4 - 384 Go | 4 - 384 Go |
Stockage (par instance) | 10 - 4096 Go | 10 - 4096 Go |
Version(s) supportée(s) |
|
|
Surveillance |
Surveillance 24/7 |
Sauvegarde |
Réplication (PRA) |
Disponibilité | 99,8% | 99.9% |
Déploiement Multi-AZ |
Brokers | 3+ |
Contrôleurs | 3 |
CPU (par broker) | 2 - 16 vCPU |
RAM (par broker) | 4 - 384 Go |
Stockage | 40 - 1024 Go |
Version(s) supportée(s) | 3.6.0 |
Surveillance |
Surveillance 24/7 |
Sauvegarde |
Réplication (PRA) |
Disponibilité | 99.9% |
Déploiement Multi-AZ |
Instances | 1 | 3 |
CPU (par instance) | 2 - 16 vCPU | 2 - 16 vCPU |
RAM (par instance) | 4 - 384 Go | 4 - 384 Go |
Stockage (par instance) | 10 - 2048 Go | 10 - 2048 Go |
Version(s) supportée(s) | 3.11 | 3.11 |
Surveillance |
Surveillance 24/7 |
Sauvegarde |
Réplication (PRA) |
Disponibilité | 99,8% | 99,9% |
Déploiement multi-AZ |
Instances | 3 |
CPU (par instance) | 2 vCPU |
RAM (par broker) | 4 Go |
Stockage | 90 Go |
Version(s) supportée(s) | 1.8.1 |
Surveillance |
Surveillance 24/7 |
Sauvegarde |
Réplication (PRA) |
Disponibilité | 99.9% |
Déploiement Multi-AZ |
Instance(s) | 2 |
CPU (par instance) | 2 vCPU |
RAM (par instance) | 4 Go |
Version(s) supportée(s) | 10.2 |
Surveillance |
Surveillance 24/7 |
Sauvegarde |
Réplication (PRA) |
Disponibilité | 99.9% |
Déploiement Multi-AZ |
Compatibilité S3 |
Géo-réplication |
Quota |
Object Lock |
Cycle de vie des fichiers |
URLs pré-signées |
Nœuds | 2 - 256 |
CPU (par nœud) | 2 - 16 |
RAM (par nœud) | 8 - 384 Go |
Surveillance |
Surveillance 24x7 |
Sauvegarde des nœuds |
Sauvegarde ETCD | Toutes les 2 heures avec 7 jours de rétention |
Sauvegarde des volumes persistants |
Réplication de données (PRA) |
Haute disponibilité |
Disponibilité | 99,9% |
Choix de la région |
Libre-service |
Réplication | x4 | x4 |
Tolérance de panne : Une AZ indisponible |
Tolérance de panne : Un DC indisponible |
Approvisionnement de nouveaux PV |
Remonter le PV existant |
Compatible avec toutes les applications K8S |
Montage multiple (RWX) |
Redimensionnable |
Aperçu |
Tolérance de panne : perte de 1 AZ |
Tolérance de panne : perte de 1 DC |
Compatible avec K8S 1.22+ |
Compatible avec K8S 1.22- |
Instances | 1 | 3 |
CPU (par instance) | 2 - 16 vCPU | 2 - 16 vCPU |
RAM (par instance) | 4 - 384 Go | 4 - 384 Go |
Version(s) supportée(s) | 10.6 | 10.6 |
Surveillance |
Surveillance 24x7 |
Sauvegarde |
Réplication de données (PRA) |
Disponibilité | 99,8% | 99,9% |
Déploiement multi-AZ |
Libre-service |
Minimum Business Continuity Objective (MBCO) | Comme le RTO / RPO, le MBCO est un paramètre majeur pour dimensionner votre DRP. En résumé, il s'agit du pourcentage de capacité de votre application déployée qui est nécessaire pour que votre entreprise soit opérationnelle. Selon la taille de vos charges de travail lorsque vous les exécutez dans 3 AZ, la performance que vous jugez suffisante peut être de 30%, 50% ou 100%. Par exemple, si vous avez une application avec 3 répliques de 4GB RAM sur chaque AZ, vous pouvez déterminer le MBCO de manière très différente :
Le choix vous appartient ! |
Pods Ressources Demandes | Comme Kubernetes essaiera de replanifier vos pods en cas de panne, les requêtes sont un paramètre absolument majeur à gérer. Si l'AZ-C n'a pas assez de ressources pour satisfaire toutes les exigences des déploiements de pods souhaités, Kubernetes ne les déploiera pas, et peut-être que vos applications ne seront pas disponibles ! Pour connaître vos demandes, vous pouvez exécuter cette commande :
|
Utilisation des ressources | Déterminer les demandes, c'est bien pour être sûr que Kubernetes déploiera autant de pods que vous le souhaitez, mais qu'en est-il de la capacité réelle utilisée par vos pods ? Il faut également en tenir compte pour avoir une idée des ressources "brutes" dont vos applications ont besoin. Pour le déterminer, vous pouvez exécuter cette commande pour connaître l'utilisation actuelle de votre pod :
|
EB (Boulogne-Billancourt) |
ET (Toulouse-Labège) |
OpenSearch managé
OpenSearch est une suite de recherche et d'analyse open source pilotée par la communauté et dérivée d'Elasticsearch 7.10.2 & Kibana 7.10.2 sous licence Apache 2.0.
Il se compose d'un démon de moteur de recherche, OpenSearch, et d'une interface de visualisation et d'utilisation, OpenSearch Dashboards. Il permet d'ingérer, de sécuriser, de rechercher, d'agréger, de visualiser et d'analyser facilement les données.
Ces capacités sont populaires pour des cas d'utilisation tels que la recherche d'applications, l'analyse des journaux, etc.
Les serveurs OpenSearch Cluster et la configuration des services sont gérés par cegedim.cloud. Le produit est disponible en libre-service dans ITCare.
Les utilisateurs ont un accès complet à la base de données et aux tableaux de bord d'OpenSearch. Il est de la responsabilité des utilisateurs de gérer la sécurité des index et de leur cycle de vie.
OpenSearch est déployé en tant que cluster sur site dans nos centres de données.
Le même niveau de service que l'offre Compute est garanti : déploiement d'instances, maintien en condition opérationnelle, flexibilité, sécurité et monitoring sont ainsi assurés par nos experts.
Le dimensionnement peut être configuré en fonction de vos besoins.
Le nombre minimum de nœuds pour un cluster est de 3 serveurs mais n'est pas recommandé pour la production. Il est conseillé de déployer au moins 5 nœuds ou plus pour une utilisation en production.
Pour plus d'information, veuillez consulter la page OpenSearch - Architecture.
La facturation est mensuelle et basée sur le nombre de nœuds, plus des coûts supplémentaires pour le stockage, la sauvegarde et la surveillance 24/7.
L'estimation du coût d'un cluster OpenSearch est disponible auprès de votre Responsable de compte Technique.
OpenSearch amène plusieurs changements, vous devez donc vérifier la compatibilité de votre application avec ceux-ci.
Il s'agit du principal changement induisant une rupture et il n'est pas spécifique à OpenSearch car il était déjà prévu par ElasticSearch avant le fork.
Vous devez donc vous assurer que vos applications n'utilisent plus les paramètres "type".
Voici quelques solutions concernant les produits souvent utilisés avec les solutions élastiques et comment les configurer pour qu'ils fonctionnent avec OpenSearch 2.x
Si le client est Fluentbit, la solution la plus simple est de définir le paramètre Suppress_Type_Name sur On.
Il est également possible de changer le plugin de sortie pour le plugin natif d'OpenSearch qui fait partie de Fluentbit depuis la version 1.9.
L'article suivant peut s'avérer utile pour débuter avec Fluentbit et OpenSearch :
Si le client est Fluentd, c'est plus délicat. Il existe également unsuppress_type_name mais le plugin n'utilise ce paramètre que s'il détecte une version d'Elastic >= 7.
Nous devons donc ajouter d'autres paramètres :
verify_es_version_at_startup = false - pour ne pas laisser le plugin détecter la version
default_elasticsearch_version = '7'
Voici par exemple les changements à effectuer sur les spécifications du plugin de sortie que nous utilisons dans Kubernetes.
Il y a aussi un plugin de sortie pour OpenSearch.
Le plugin OpenSearch n'est pas encore disponible dans le système de journalisation de Rancher.
PostgreSQL est actuellement le principal SGBDR (système de gestion de base de données relationnelle) open source, avec une large gamme de fonctionnalités et une grande communauté qui le soutient.
cegedim.cloud fournit des instances de bases de données PostgreSQL entièrement gérées pour vous permettre de construire vos applications sans vous soucier de la disponibilité, la sécurité et la résilience des bases de données PostgreSQL.
PostgreSQL est déployé sur site dans les centres de données de cegedim.cloud.
cegedim.cloud garantit le même niveau de service que l'offre Compute & Database : déploiement des instances, maintien en condition opérationnelle, flexibilité, sécurité et monitoring sont ainsi assurés par nos experts.
Deux types de déploiements PostgreSQL sont disponibles :
Le mode Instance autonome fournit une instance PostgreSQL standard.
Le mode Haute disponibilité fournit un déploiement PostgreSQL multi-instances avec des capacités de résilience et d'évolutivité améliorées.
Le dimensionnement peut être configuré en fonction de vos besoins.
Pour plus d'information, veuillez consulter la page PostgreSQL - Architecture.
La facturation est mensuelle et basée sur le nombre de nœuds plus les coûts supplémentaires pour le stockage, la sauvegarde et le monitoring 24x7.
L'estimation du coût d'un nœud PostgreSQL est disponible via votre Service Delivery Manager.
SQL Server est disponible dans les centres de données de cegedim.cloud dans les régions suivantes :
EB4 - Boulogne-Billancourt, France
ET1 - Labège, France
Disposition du système de fichiers pour le PaaS SQL Server de cegedim.cloud :
En raison des préfixes appliqués aux objets Active Directory, le nom de la machine virtuelle provisionnée est limité à 13 caractères maximum pour un PaaS SQL Server.
Liste des ports :
Seuls les ports de l'écouteur SQL Server et du navigateur SQL Server sont ouverts en entrée dans le pare-feu Windows par défaut et appliqués via une GPO sur l'unité organisationnelle.
Liste des modules installés par défaut lors de la provision :
Moteur de base de données
Réplication
Recherche en texte intégral
Connectivité des outils client
SDK
Cette section vise à répertorier les fonctionnalités/capacités disponibles pour le client, et comment les demander/exécuter :
Le PaaS SQL Server fonctionne exclusivement dans un environnement Windows. La méthode standard de connexion à l'instance est le RDP (Remote Desktop Protocol).
Pour vous connecter à la machine virtuelle, vous devez disposer des privilèges requis au niveau du domaine ou au niveau de la machine locale.
L'authentification est configurée par défaut en mode mixte, ce qui offre deux types de connexion :
Connexion SQL Server: au niveau de l'instance
Utilisateur Active directory: au niveau du domaine - Authentification Windows intégrée
La connexion à l'instance est disponible localement ou à distance :
Localement : une fois connecté en RDP, lancez le SQL Server Management Studio local
A distance: lancez le SQL Server Management Studio et spécifiez l'instance cible Localement
SSMS peut utiliser les informations d'identification de l'utilisateur Windows avec lequel vous êtes déjà connecté via RDP pour vous connecter à l'instance SQL Server.
L'authentification avec un login SQL est également possible localement.
Spécifiez une instance cible dans le champ du nom du serveur en imposant le protocole : tcp:HOSTNAME\INSTANCENAME
Sélectionnez simplement "SQL Server Authentication" et fournissez le login SQL avec le mot de passe associé.
Les autorisations pour cegedim.cloud sont gérées par GPO.
Cette section répertorie la gestion des mots de passe pour le PaaS SQL Server :
Les autorisations pour les clients sont gérées par les clients eux-mêmes.
Le client qui demande une instance SQL Server via ITCare sera automatiquement autorisé à se connecter à l'instance. Il peut accorder l'accès à tout utilisateur ou groupe Active Directory.
Les patchs sont installés lors des "Patch parties" gérées par cegedim.cloud tous les trimestres. Une instance peut être patchée manuellement exceptionnellement si la sécurité ou la correction de bugs l'exige.
Les données pour le PaaS SQL Server de cegedim.cloud sont stockées sur les machines virtuelles dédiées créées lors de la demande d'un PaaS. Ces machines virtuelles et le stockage associé sont hébergés et gérés dans les propres centres de données de cegedim.cloud.
Le cluster OpenSearch est disponible en tant que :
Cluster de 3 nœuds - non recommandé pour une utilisation en production
Cluster de 5 nœuds ou plus - recommandé pour une utilisation en production
Dans la topologie à 3 serveurs, tous les serveurs jouent le rôle de maître, deux d'entre eux sont également utilisés comme nœuds de données. Chaque index est répliqué par défaut sur ces deux nœuds de données.
Avec 5 serveurs ou plus, trois nœuds sont utilisés comme nœuds maîtres et n'hébergent pas de données. En fonction de la zone, les nœuds maîtres sont répartis sur 2 ou 3 zones de disponibilité. Les nœuds restants n'hébergent que des données et sont répartis sur deux zones de disponibilité.
Dans une Area avec 3 zones de disponibilité, le cluster est résilient face à une défaillance d'une zone de disponibilité.
Dans une Area avec 2 zones de disponibilité, le cluster peut tomber en panne si la zone de disponibilité contenant deux maîtres n'est pas disponible.
Cette section énumère les fonctionnalités / capacités disponibles pour les utilisateurs, ainsi que la manière de les demander / de les exécuter :
L'authentification utilise le système de sécurité interne d'OpenSearch. Il peut être configuré sur demande pour accepter Active Directory comme backend d'authentification.
Les autorisations sont effectuées à l'aide de RBAC. Il peut être configuré sur demande pour accepter Active Directory comme fournisseur de rôles.
TLS/SSL est activé par défaut pour les flux réseau entrants et internes.
Cette section explique comment est gérée la gestion des mots de passe :
Redis est déployable en self-service via notre outil de gestion de plateforme cloud : ITCare.
Deux topologies sont disponibles :
Instance autonome
Cluster Sentinel
Dans les deux cas, vous pouvez choisir de faire persister ou non les données sur le disque lors de la demande de création, voir #persistance.
L'instance autonome, une fois déployée, est accessible sur le port d'écoute 6379.
Le cluster Redis Sentinel est déployé sur 3 instances répartis sur toutes les Zones de disponibilité d'une Area.
Le cluster, une fois déployé, est accessible sur le port d'écoute 6379.
Chaque instance exécute les processus Redis et Sentinel
Port d'écoute Sentinel : 26379
Sur les 3 instances, l'une d'elle est primaire et les deux autres sont des répliques
Les répliques sont ouvertes en lecture seule
La persistance fait référence à l'écriture de données sur un support durable, tel qu'un disque SSD (solid-state disk). Redis propose une série d'options de persistance.
RDB (Redis Database) : La persistance RDB réalise des instantanés ponctuels de votre ensemble de données à des intervalles spécifiés.
AOF (Append Only File) : La persistance AOF enregistre chaque opération d'écriture reçue par le serveur. Ces opérations peuvent ensuite être rejouées au démarrage du serveur, reconstituant ainsi l'ensemble de données d'origine. Les commandes sont enregistrées dans le même format que le protocole Redis lui-même.
Pas de persistance : Vous pouvez désactiver complètement la persistance. Cette option est parfois utilisée pour la mise en cache.
RDB + AOF : Vous pouvez également combiner AOF et RDB dans la même instance.
Si l'instance primaire tombe en panne, une réplique sera automatiquement promue en tant que nouveau primaire. La réplique sera reconfigurée automatiquement pour suivre le nouveau primaire.
Sentinel fournit les informations concernant l'instance primaire et les instances répliques.
Cette section énumère les fonctionnalités disponibles pour le client, ainsi que la manière de les demander ou de les exécuter :
Si la persistance AOF est active, les paramètres suivants seront appliqués :
si RDB est actif, les paramètres suivants seront appliqués :
Les paramètres noyau suivants ont été modifiés afin d'optimiser les performances du système d'exploitation pour Redis :
vm.overcommit_memory = 1
vm.swappiness = 1
net.core.somaxconn = 65535
Le mode d'authentification utilisé est le mode interne : Redis 6 ACL.
Les mots de passe sont hashés avec SHA-256 et n’apparaissent pas en clair dans le fichier ACL.
Les ACL de Redis 6 sont utilisées pour gérer les autorisations.
Sur Sentinel, le compte client dédié a les droits sur :
Sur Redis, le compte client dédié a les droits sur :
Le client peut choisir d'activer le non le transport TLS lors de la demande de création en libre-service via ITCare.
Cette section énumère la gestion des mots de passe :
Les éléments suivants sont surveillés et sont accessibles dans ITCare.
Pour tirer pleinement parti d'Apache Kafka en tant que système distribué, le PaaS Apache Kafka de cegedim.cloud s'assure que les brokers sont dispatchés sur plusieurs Zones de Disponibilité afin de maximiser la résilience et la redondance.
La taille du cluster par défaut comprend 3 brokers répartis sur 3 Zones de Disponibilité en fonction de votre centre de données.
La configuration par défaut garantit également que le facteur de réplication est fixé à 3 pour les topics et que le paramètre minimum in-sync replica soit configuré à deux.
Cette configuration garantit que tous vos topics et messages sont répliqués sur tous les brokers dans toutes les Zones de Disponibilité.
A noter que le provisionnement de plus de 3 brokers rendra les choses plus complexes.
Plus il y a de brokers, plus vous répliquerez vos données. Si vous ne voulez pas répliquer plus de 3 fois, vous devrez gérer quels topics et partitions sont répliqués et où afin de respecter votre DRP par exemple.
Le cluster Apache Kafka est sécurisé par les moyens suivants :
Communications entre brokers sécurisées avec SASL_SSL
Communications entre le client et le broker sécurisées par SASL_SSL
Contrôleurs sécurisé avec des ACLs
Les contrôleurs sont gérés par cegedim.cloud et simplifie votre administration.
Pour se connecter à votre cluster Apache Kafka sécurisé, les éléments suivants seront requis :
Le certificat correspondant
Un utilisateur existant et autorisé avec un mot de passe (SCRAM-SHA-256)
Veuillez vous référer à la page Apache Kafka - Didacticiels pour vous connecter et interagir avec votre cluster Apache Kafka.
Paramètres importants du broker Kafka conservés par défaut :
Voici les paramètres du broker Apache Kafka que cegedim.cloud va modifier lors du provisionnement :
Apache Kafka est une plateforme de streaming d'événements.
Apache Kafka combine trois fonctionnalités clés pour vous permettre de mettre en œuvre vos cas d'utilisation du streaming d'événements de bout en bout avec une seule solution éprouvée :
Pour publier (écrire) et s'abonner (lire) à des flux d'événements, y compris l'importation/exportation continue de vos données à partir d'autres systèmes.
Pour stocker des flux d'événements de manière durable et fiable, aussi longtemps que vous le souhaitez.
Traiter des flux d'événements au moment où ils se produisent ou rétrospectivement.
Et toutes ces fonctionnalités sont fournies de manière distribuée, hautement évolutive, élastique, tolérante aux pannes et sécurisée.
Apache Kafka est déployé sur site dans les centres de données de cegedim.cloud.
cegedim.cloud garantit le même niveau de service que l'offre Compute : déploiement des instances, maintien en condition opérationnelle, flexibilité, sécurité, monitoring sont ainsi assurés par nos experts.
Le déploiement d'un cluster de 3 nœuds minimum en version 3.6.0 est disponible en libre-service dans ITCare. Cette topologie est prête pour la production avec :
3 brokers minimum répartis sur plusieurs zones de disponibilité
3 contrôleurs dédiés répartis sur plusieurs zones de disponibilité
Les clusters livrés sont sécurisés à la fois pour les communications inter-brokers mais aussi clients <-> brokers avec le mode SASL_SSL :
SSL pour la couche transport
SASL SCRAM-SHA-256 pour l'authentification et les autorisations
Le dimensionnement peut être configuré en fonction de vos besoins.
Pour plus d'information, veuillez consulter la page Apache Kafka - Architecture.
L'estimation du coût d'un cluster Apache Kafka est accessible via votre Service Delivery Manager.
La facturation est basée sur le nombre de nœuds, plus les coûts supplémentaires de stockage, de sauvegarde et de la surveillance 24/7.
Au moins 6 machines virtuelles Linux seront facturées : 3 brokers Apache Kafka et 3 nœuds contrôleurs Apache Kafka.
Pour commencer, rendez-vous sur ITCare et recherchez votre service global cible où vous créerez votre nouveau cluster Apache Kafka.
Recherchez votre service Global dans la barre de recherche supérieure et cliquez dessus pour afficher sa page d'information.
Une fois dans votre Service Global, cliquez sur le bouton Créer une ressource, sélectionnez Apache Kafka et la version requise.
Remplir le formulaire :
Définir le nom du futur cluster
Le nombre de broker (3+)
Le dimensionnement
Le stockage requis sur chaque broker
La localisation cible
Le réseau cible
Les options de gestion (sauvegarde, surveillance, 24/7, réplication site distant)
Cliquer sur Suivant une fois les champs remplis. A l'étape suivante, saisir le mot de passe du compte super user qui sera fourni puis cliquer sur Suivant.
Les mots de passe ne sont pas sauvegardés par cegedim.cloud.
Assurez-vous de sauvegarder votre mot de passe!
Réviser la synthèse avant de soumettre le formulaire.
Le provisionnement peut prendre jusqu'à 2 heures en fonction de la charge actuelle de l'automatisation.
Une fois le déploiement prêt, vous en serez informé par e-mail.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Démarrer et confirmer.
Le démarrage d'un cluster démarre toutes les machines virtuelles attachées au cluster.
Une notification par courriel sera envoyée lorsque le service sera activé.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Stop.
Saisissez un numéro RFC pour le suivi (facultatif). Cliquez sur Soumettre.
L'arrêt d'un cluster arrêtera toutes les machines virtuelles attachées au cluster et la surveillance sera désactivée.
Une notification par courrier électronique sera envoyée lorsque le cluster sera arrêté.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Redimensionner les nœuds.
Sélectionnez les nœuds que vous souhaitez redimensionner et sélectionnez la nouvelle taille (cpu/ram).
Chaque nœud sera redimensionné et redémarré de manière séquentielle.
Une notification par courriel sera envoyée lorsque tous les nœuds auront été redimensionnés.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Supprimer. Cette action arrêtera et supprimera toutes les machines virtuelles.
Veuillez noter que cette action n'est pas récupérable!
Saisissez un numéro RFC pour le suivi (facultatif), puis cliquez sur Soumettre.
Une notification par courriel sera envoyée lorsque le cluster sera supprimé.
Pour interagir avec votre cluster sécurisé en utilisant les scripts Kafka, vous devez d'abord télécharger l'archive Apache Kafka depuis le site officiel.
Idéalement, vous devriez télécharger la version exacte correspondant à votre cluster.
Une fois dézippé et désarchivé sur votre serveur ou client Linux, vous trouverez les scripts shell Kafka dans le répertoire /bin.
Ces scripts permettent de :
Produire et consommer
Gérer les utilisateurs
Gérer les sujets
ACL de gestion
Gérer les configurations des articles
Ce guide n'entrera pas dans les détails de tous les scripts mais vous aidera à démarrer avec des commandes simples.
Pour se connecter à un cluster Kafka sécurisé, vous devez configurer un keystore et un fichier de propriétés.
Créez le keystore avec le certificat fourni :
Alias : alias du certificat dans le keystore
Import-file: nom du fichier de certificat contenant le certificat fourni
Storepass et keypass : mot de passe pour protéger votre keystore, doivent être identiques
Pour lister le contenu de votre keystore, utilisez cette commande :
Une fois le keystore créé, il vous faut maintenant un fichier de propriétés :
username : le super utilisateur kafka qui vous est fourni par email
mot de passe : le mot de passe de cet utilisateur que vous avez fourni lors du provisionnement.
ssl.truststore.location : l'emplacement de votre keystore précédemment créé
ssl.truststore.password : le mot de passe pour déverrouiller votre keystore (storepass / keypass utilisé)
Avec ces éléments, vous pouvez maintenant utiliser n'importe quel script shell Kafka avec le paramètre suivant :
Kcat est un producteur et consommateur générique non-JVM pour Apache Kafka >=0.8.
La version 1.5.0 et supérieure doit être utilisée pour prendre en charge l'authentification SASL_SSL.
De plus amples informations concernant Kcat sont disponibles sur le site de Confluent :
Veuillez vous référer à cette documentation pour créer un client Kafka dans la langue de votre choix :
Veuillez vous référer à cette documentation pour en savoir plus sur les connecteurs Kafka :
Pour commencer, connectez-vous à ITCare et recherchez votre service global cible où vous créerez votre nouveau serveur SQL. Une fois dans votre service global, cliquez sur le bouton Créer une ressource dans le coin supérieur droit.
Dans la catégorie Bases de données managées, sélectionnez SQL Server :
Choisissez la version et l'édition souhaitées :
Nom : Indiquez le nouveau nom de la machine virtuelle SQL Server.
Dimensionnement : Sélectionnez un dimensionnement pour votre instance. La valeur par défaut et le dimensionnement le plus bas est 2 CPUs / 4 Go RAM.
Stockage : Sélectionnez la capacité de stockage requise pour SQL Server. Cinq disques sont nécessaires.
La valeur par défaut et la capacité de stockage minimale sont de 30 Go pour les disques de l'instance racine et des bases de données utilisateur, de 10 Go pour les disques du journal utilisateur et de tempdb.
Localisation : Sélectionnez la région dans laquelle vous souhaitez effectuer le déploiement. Choisissez une zone dans cette région et enfin une zone de disponibilité.
Réseau : Sélectionnez le VLAN dans lequel vous voulez déployer. Idéalement, il s'agit du VLAN de votre backend.
Authentification : Sélectionnez le domaine d'authentification dans lequel vous souhaitez vous déployer.
Options de gestion : Activez les options de gestion.
Activer ou désactiver la surveillance
Activer ou désactiver la surveillance 24/7
Activer la sauvegarde de votre machine virtuelle
Activer la réplication de vos machines virtuelles (sur le site de Reprise d'activité après sinistre)
Indiquez le mot de passe de l'administrateur que vous utiliserez pour l'utilisateur de l'administrateur du serveur SQL.
cegedim.cloud n'enregistrera pas ce mot de passe. Veuillez donc le conserver en lieu sûr dans votre coffre-fort.
Confirmez votre mot de passe.
Choisissez votre collation SQL.
Ajouter des technologies supplémentaires disponibles dans SQL Server : SSIS, SSAS, SSRS
Vous pouvez ajouter une demande spécifique avant de la soumettre, mais cela retardera le provisionnement automatique.
Cliquez sur Suivant lorsque vous avez terminé.
Cette page reprendra vos données, veuillez vérifier que tout est correct avant de les soumettre. Vous pouvez afficher et enregistrer votre mot de passe administrateur. Une fois les données vérifiées, cliquez sur Soumettre.
Une fois que le déploiement est prêt, vous serez notifié par email. Le provisionnement peut prendre jusqu'à une heure en fonction de la charge actuelle de l'automatisation.
En haut de la page de la ressource, cliquez sur le bouton Gérer, puis sur Démarrer et confirmer.
Le démarrage du cluster démarre toutes les machines virtuelles attachées au cluster.
Une notification par courrier électronique sera envoyée lorsque le service sera activé.
En haut de la page de la ressource, cliquez sur le bouton Gérer, puis sur Arrêter. Saisissez un numéro RFC pour le suivi (facultatif). Cliquez sur Soumettre.
L'arrêt d'un cluster entraîne l'arrêt de toutes les machines virtuelles attachées au cluster et la désactivation de la surveillance.
Une notification par courrier électronique sera envoyée lorsque le cluster sera arrêté.
En haut de la page des ressources, cliquez sur le bouton Gérer, puis sur Redimensionner. Sélectionnez la nouvelle taille (CPU / RAM).
Chaque nœud sera redimensionné et redémarré séquentiellement. Le redimensionnement interrompra le service SQL Server !
Une notification par courrier électronique sera envoyée lorsque tous les nœuds auront été redimensionnés.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Supprimer. Cela arrêtera et supprimera toutes les machines virtuelles.
Veuillez noter que cette action n'est pas récupérable !
Saisissez un numéro RFC pour le suivi (facultatif), puis cliquez sur Soumettre. Une notification par courrier électronique sera envoyée lorsque le déploiement sera supprimé.
RabbitMQ est un courtier de messages open source léger et populaire.
Il prend en charge plusieurs protocoles de messagerie et peut être déployé dans des configurations distribuées pour répondre aux exigences à grande échelle et de disponibilité.
RabbitMQ fournit un large éventail d'outils de développement pour les langages les plus courants.
RabbitMQ est déployé sur site dans les centres de données de cegedim.cloud.
cegedim.cloud garantit le même niveau de service que l'offre Compute : déploiement des instances, maintien en condition opérationnelle, flexibilité, sécurité, monitoring sont ainsi assurés par nos experts.
Deux topologies sont disponibles :
Instance autonome
Cluster
La topologie Cluster est prête pour la production avec au moins 3 nœuds (jusqu'à 5) répartis sur toutes les Zones de Disponibilité d'une région cible.
Le protocole pris en charge par défaut est AMQP (d'autres protocoles peuvent être activés sur demande). Le TLS/SSL peut être activé pour le protocole AMQP lors de l'approvisionnement ou ultérieurement sur demande.
Le dimensionnement peut être configuré en fonction de vos besoins.
Pour plus d'information, veuillez consulter la page RabbitMQ - Architecture.
L'estimation des coûts pour un nœud RabbitMQ est disponible via votre Service Delivery Manager.
La facturation est basée sur le nombre de nœuds auxquels s'ajoutent les frais supplémentaires de stockage, de sauvegarde, surveillance 24/7.
Pour commencer, rendez-vous sur ITCare et recherchez votre service global cible où vous créerez votre nouveau cluster RabbitMQ.
Recherchez votre service Global dans la barre de recherche supérieure et cliquez dessus pour afficher sa page d'information.
Une fois dans votre Service Global, cliquez sur le bouton Créer une ressource, sélectionnez RabbitMQ et la version requise.
Remplir le formulaire :
Sélectionner une topologie
Définir le nom du futur cluster
Si topologie Cluster : sélectionner le nombre de broker (3+)
Le dimensionnement
Le stockage requis sur chaque broker
La localisation cible
Le réseau cible
Les options de gestion (sauvegarde, surveillance, 24/7, réplication site distant)
Cliquer sur Suivant une fois les champs remplis. A l'étape suivante, saisir le mot de passe du compte super user qui sera fourni puis cliquer sur Suivant.
Les mots de passe ne sont pas sauvegardés par cegedim.cloud.
Assurez-vous de sauvegarder votre mot de passe!
Réviser la synthèse avant de soumettre le formulaire.
Le provisionnement peut prendre jusqu'à 2 heures en fonction de la charge actuelle de l'automatisation.
Une fois le déploiement prêt, vous en serez informé par e-mail.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Démarrer et confirmer.
Le démarrage d'un cluster démarre toutes les machines virtuelles attachées au cluster.
Une notification par courriel sera envoyée lorsque le service sera activé.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Stop.
Saisissez un numéro RFC pour le suivi (facultatif). Cliquez sur Soumettre.
L'arrêt d'un cluster arrêtera toutes les machines virtuelles attachées au cluster et la surveillance sera désactivée.
Une notification par courrier électronique sera envoyée lorsque le cluster sera arrêté.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Redimensionner.
Sélectionnez les nœuds que vous souhaitez redimensionner et sélectionnez la nouvelle taille (cpu/ram).
Chaque nœud sera redimensionné et redémarré de manière séquentielle.
Une notification par courriel sera envoyée lorsque tous les nœuds auront été redimensionnés.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Supprimer. Cette action arrêtera et supprimera toutes les machines virtuelles.
Veuillez noter que cette action n'est pas récupérable!
Saisissez un numéro RFC pour le suivi (facultatif), puis cliquez sur Soumettre.
Une notification par courriel sera envoyée lorsque le cluster sera supprimé.
Une fois que votre déploiement est prêt, vous pouvez accéder à l'interface utilisateur de gestion de votre déploiement à partir d'ITCare.
Ce lien est disponible dans le panneau "Configuration" de votre déploiement.
RabbitMQ peut également être géré via une API.
Une fois que vous avez obtenu le lien vers votre interface de gestion, l'API est disponible en ajoutant simplement /api à la fin de l'URL.
Pour obtenir plus d'informations sur l'utilisation de l'API, veuillez consulter la documentation ci-dessous.
Cette section fournit des exemples de code Python pour produire des messages vers une queue simple ou une queue de quorum.
Bien sûr, vous pouvez utiliser le langage de développement de votre choix ou n'importe quel middleware qui supporte AMQP.
En outre, si AMQPS est activé (TLS/SSL), une configuration supplémentaire est nécessaire. Il y a aussi un exemple pour cela.
Fortement recommandé dans une configuration en cluster pour une résilience maximale !
Lorsque TLS/SSL est activé pour AMQP procotol, le certificat doit être géré soit en le déclarant, soit en l'ajoutant à votre magasin de certificats.
Cette section fournit des exemples de code Python pour consommer des messages.
RabbitMQ peut être provisionné en tant qu'instance autonome en libre-service en utilisant ITCare.
Propriétés
Une fois déployée, l'instance unique aura les propriétés suivantes :
RabbitMQ peut être provisionné en tant que cluster en libre-service en utilisant ITCare.
Un cluster RabbitMQ peut être déployé selon une topologie à 3 ou 5 nœuds, adaptée à l'utilisation des quorums.
Les nœuds seront répartis sur toutes les zones de disponibilité disponibles dans la zone ciblée.
Les files d'attente quorum sont fortement recommandées avec les clusters RabbitMQ émis à partir du PaaS Cegedim.cloud pour une résilience maximale !
Une file d'attente de quorum sera nativement répliquée sur tous les nœuds participant au cluster.
La mise en miroir classique n'est pas conseillée sur un cluster RabbitMQ car la Quorum Queue est son amélioration naturelle.
Cette section énumère les fonctionnalités disponibles pour le client, ainsi que la manière de les demander ou de les exécuter :
L'authentification utilise la base de données interne de RabbitMQ.
Cette section énumère la gestion des mots de passe pour le PaaS RabbitMQ :
TLS/SSL peut être activé pour le protocole AMQP lors du provisionnement ou par la suite.
Par défaut, il est désactivé pour éviter toute surcharge inutile.
Cette section énumère la gestion des politiques pour le PaaS RabbitMQ :
Merci d'ouvrir un ticket de demande si vous avez besoin de modifier ces politiques.
Les données pour le PaaS RabbitMQ de cegedim.cloud sont stockées sur des machines virtuelles dédiées créées lors de la demande.
Ces machines virtuelles et le stockage associé sont hébergés et gérés dans les centres de données de cegedim.cloud.
La solution Data Masking transforme les données sensibles contenues dans les bases de données en données moins sensibles, selon vos propres spécifications et besoins.
La solution permet aux entreprises d'utiliser ces données tout en réduisant l'impact des violations de données. Elle offre une réponse aux questions de sécurité et de réglementation (par exemple, le RGPD).
Une quantité importante de techniques de masquage et des paramètres de pseudonymisation efficaces sont utilisables tout en conservant la cohérence des données.
La solution est adaptable et couvre une grande variété de types de bases de données telles que Oracle, DB2, SQL Server, MySQL, MongoDB, Sybase, Teradata.
Pour bénéficier de ce service, veuillez contacter votre Service Delivery Manager pour évaluer la complexité de la base de données à pseudonymiser et le devis correspondant.
Le service Data Masking s'appuie sur TDM (Test Data Management).
Un dictionnaire est un fichier plat ou une table relationnelle qui contient des données de substitution et un numéro de série. Les dictionnaires peuvent être utilisés pour remplacer des données sensibles dans une table.
Divers dictionnaires existent déjà dans TDM (prénom, nom, noms de pays, poste, etc.). Les dictionnaires peuvent être utilisés dans les règles de masquage afin de créer des règles de masquage par substitution.
Des dictionnaires personnalisés peuvent être importés ou créés :
Si les résultats doivent contenir des données spécifiques. Exemple : pour le prénom, seulement un sous-ensemble du nom de la liste ; pour le pays, seulement le pays de l'UE, etc.
Si les dictionnaires ne correspondent pas aux spécifications d'un projet
Les règles de masquage sont des outils utilisés pour masquer les données. Différents types de règles de masquage peuvent être définis et de nombreuses règles de masquage existent par défaut.
Exemple de propriétés de la règle de masquage :
Une sortie répétable renvoie une valeur déterministe à chaque fois que les valeurs de la source et de la graine sont les mêmes. Cela dépend de la semence, qui peut être modifiée à volonté.
Substitution unique : les données renvoient une valeur unique pour chaque entrée et graine unique.
Dictionnaire : dictionnaire utilisé dans la règle
Valeur masquée : détermine la valeur qui sera masquée dans la base de données (et quelle colonne est "appliquée").
Colonne de consultation : pour les règles plus avancées, définit une condition de consultation qui peut être utilisée pour déclencher des résultats conditionnels.
colonne Numéro de série : identifiant utilisé par l'application (transparent pour l'utilisateur)
Des règles de masquage personnalisées avancées peuvent être créées si nécessaire.
Exemples :
Règle de masquage basée sur plusieurs entrées. Ex : concaténation prénom + nom de famille
Règle de masquage avancée combinant plusieurs règles de masquage. Ex : masquage d'un champ à l'aide de différents dictionnaires en fonction du contenu d'un autre champ de la base de données.
Vous trouverez ci-dessous quelques techniques de masquage non exhaustives :
Substitution : Remplace une colonne de données par des données similaires provenant d'un dictionnaire
Randomisation : Produit des résultats aléatoires pour les mêmes données sources et règles de masquage
Floutage : Renvoie une valeur aléatoire proche de la valeur originale
Clé : Produit des résultats déterministes pour les mêmes données sources, règle de masquage et valeur de départ
Expression : Applique une expression aux données et renvoie les données masquées ou modifiées. Exemple : concaténation
Nullification : Remplacer une colonne ou une donnée par une valeur nulle
Cryptage : Transformer des données en données inintelligibles à l'aide d'un algorithme cryptographique et d'une clé définie.
Carte de crédit : Applique une technique intégrée pour déguiser le numéro de carte de crédit
Adresse IP : Applique une technique intégrée pour déguiser l'adresse IP
Téléphone : Applique une technique intégrée pour déguiser le numéro de téléphone
Courriel : Applique une technique intégrée pour déguiser l'adresse électronique
Shuffle : Applique des valeurs de colonnes sensibles au hasard d'une ligne à une autre dans le même tableau
Advanced : Applique une technique de masquage personnalisable à plusieurs colonnes d'entrée et de sortie.
Un projet est une entité qui définit le lien entre les règles de masquage et les bases de données.
Connexions aux projets : Chaque projet est associé à une (en cas de masquage en place) ou plusieurs (en cas de masquage en flux) bases de données en utilisant des connexions (ex : oracle jdbc string).
Mappage des règles : Une fois créées, les règles peuvent être mises en correspondance avec les entrées de la base de données dans "Projets". Pour chaque colonne qui doit être masquée, une règle de masquage est ajoutée :
Une fois que tous les attributs de cartographie ont été saisis en fonction des besoins du client, le projet peut être lancé.
Exécution du travail : Chaque projet peut être exécuté pour effectuer le masquage. L'opération de masquage est appelée "travail". Pendant un travail, l'application TDM effectue le masquage de la base de données "à la volée". La base de données n'est pas stockée localement sur le nœud de travail, ni conservée dans l'application.
Les nœuds désignent la machine virtuelle sur laquelle le travail est effectué. Pour chaque client, un nœud est créé. Les performances du nœud dépendent de la complexité du travail de masquage.
Différents types de masquage peuvent être réalisés en fonction des bases de données utilisées :
In-Stream : Il s'agit du type de masquage le plus couramment utilisé. Elle implique deux bases de données : une "source" contenant les données que vous voulez masquer, et une base de données vide de destination. Le masquage est effectué "à la volée" pendant la copie des données de la base de données source vers la base de données de destination. La base de données de destination doit être vide.
In-place : une seule base de données. Le masquage est effectué sur la base de données.
Bot Defense est un produit en libre service disponible sur votre instance pour protéger votre site web contre les attaques DDoS et les attaques Bot.
Cette section énumère les actions disponibles pour le client, ainsi que la manière de les demander ou de les exécuter :
La protection DDoS est basée sur un calcul de taux de transaction côté client (basé sur les TPS) ou sur la latence côté serveur ("Stress based detection").
La détection basée sur le "TPS" ( transactions par seconde) se situe côté "client". Suivant le seuil de requêtes par seconde, le DDoS protection va venir bloquer les tentatives DDoS.
Le "Stress-based detection" permet de détecter le ralentissement du serveur. Cela offre une couche de protection plus précise grâce aux seuils de latence et de requêtes par seconde.
Le produit offre deux types de protection contre les attaques DDoS ou bot :
Le profil standard, comprenant une phase d'apprentissage. Les seuils de détection sont calculés automatiquement.
Le profil strict, ne nécessitant pas de phase d'apprentissage, avec des seuils plus restrictifs, bloquera un grand nombre de tentatives. Il limitera également un grand nombre de tentatives en provenance de pays sensibles.
Les bots peuvent être classés de plusieurs façons : les bots simples ou les bots malveillants.
Bot Defense offre deux types de protection contre les attaques DDoS ou bot :
Le profil standard, basé sur un profil générique adapté à la majorité des sites web, avec le moins d'impact possible sur le site concerné. Les seuils de détection des attaques DDoS, par exemple, sont calculés automatiquement. Déconseillé si des attaques DDoS sont en cours.
Le profil strict, basé sur un profil plus restrictif, qui peut être déployé rapidement lors d'une attaque. Ses paramètres plus fins sont conçus pour bloquer un plus grand nombre de requêtes. La protection contre les attaques DoS intègre un mécanisme de géolocalisation qui, en cas d'attaque, bloque les requêtes malveillantes en fonction du pays d'origine. Ce profil peut entraîner l'apparition de faux positifs et nécessite donc une surveillance accrue lorsqu'il est mis en œuvre.
Par ailleurs, en fonction du type de bot lors d'une attaque DDoS, il atténuera :
Les logs sont sécurisés dans Splunk et gérés dans ITCare.
Dans l'onglet "Bot Defense" sur ITCare, il existe un tableau de bord spécifique pour avoir une visibilité sur votre trafic.
Les campagnes de phishing peuvent être utilisées pour évaluer l'efficacité de la sensibilisation à la sécurité du courrier électronique.
Ce nouveau service est proposé aux clients qui souhaitent tester la vigilance de leurs employés :
Utilisation de la solution de Gophish
Demande simplifiée via un modèle Excel à remplir
Tests effectués au préalable avec validation du demandeur
Progression de la campagne en temps réel
Lorsque vous souscrivez une campagne de phishing, vous devez remplir un tableau excel où vous spécifiez les éléments de votre scénario souhaité.
À la fin de la campagne, vous recevrez un rapport de synthèse.
Si vous souhaitez planifier une campagne de phishing, veuillez contacter votre Service Delivery Manager ou l'équipe commerciale de cegedim.cloud.
Bot Defense protège vos applications Internet contre les attaques automatisées en identifiant et en atténuant les bots malveillants. Il protège également votre site web grâce à notre protection DDoS qui détecte et atténue automatiquement les attaques DDoS.
Les bots sont des logiciels automatisés conçus pour effectuer des tâches relativement simples et répétitives sur internet.
L'une de ses principales caractéristiques est que le robot peut effectuer cette tâche à une vitesse bien supérieure à celle d'un être humain, et ce 24h/24, 7j/7, sans aucun temps mort.
Il y a de bons et de mauvais bots. Un bon robot appartient généralement à une entreprise légitime et bien connue (par exemple, Google ou Facebook), il ne cache pas son identité de robot et respecte les règles du fichier robots.txt de votre site Web. Un mauvais robot, en revanche, peut essayer de se déguiser en humain, ce qui entraîne toutes sortes de problèmes.
Le produit offre deux types de protection contre les attaques DDoS ou bot :
Le profil standard, comprenant une phase d'apprentissage. Les seuils de détection sont calculés automatiquement.
Le profil strict, ne nécessitant pas de phase d'apprentissage et grâce à des seuils plus restrictifs, bloquera un grand nombre de tentatives. Il limitera également un grand nombre de tentatives provenant de pays sensibles.
Vous aurez également le choix entre 2 modes pour chacun des profils : transparent ou bloquant. L’activation de votre profil en mode transparent vous permettra d’avoir une vue sur les requêtes jugées illégitimes. Toutefois, celle-ci n’entrainera aucun impact sur votre trafic puisque cette remontée de logs est affichée à titre indicatif. Il vous permettra de faire une première analyse des logs et ainsi repérer d’éventuels faux-positifs (comptez un délai de 24 heures pour faire cette analyse). Vous pourrez alors ajuster votre Bot Defense en ajoutant les IP légitimes en whitelist avant de basculer sur le mode bloquant. Nous vous recommandons de choisir le mode transparent lors de l'activation du Bot Defense (hors attaque en cours) afin d’éviter tout blocage non désiré.
Les robots malveillants d'aujourd'hui sont extrêmement sophistiqués, et il est désormais très difficile de distinguer une visite de ces robots de celles de vrais humains.
Ces robots malveillants se comportent non seulement comme le ferait un visiteur humain légitime, mais ils peuvent également utiliser des empreintes digitales/signatures typiques des utilisateurs humains, comme une adresse IP légitime, un en-tête de navigateur et des données de système d'exploitation cohérents, ainsi que d'autres informations apparemment légitimes.
En fonction de la capacité d'un mauvais robot à copier les comportements humains, on peut distinguer quatre groupes de mauvais robots :
Les robots simples : ces robots accèdent au site à l'aide de scripts automatisés (ils ne prétendent pas utiliser un navigateur) et n'accèdent généralement au site qu'à partir d'une seule adresse IP (attribuée par le FAI). Par conséquent, ces bots sont très faciles à détecter avec les solutions anti-bots actuelles.
Les bots de niveau modéré : ces bots utilisent généralement des navigateurs sans tête (logiciels virtuels qui simulent des navigateurs) pour se faire passer pour des visiteurs légitimes utilisant de vrais navigateurs.
Les bots sophistiqués : ils peuvent imiter des comportements humains simples comme des mouvements de souris non linéaires, des clics aléatoires, etc. Ils utilisent également des navigateurs sans tête et/ou des logiciels d'automatisation des navigateurs pour tromper la solution de gestion des robots.
Les bots avancés : ces bots combinent toutes les différentes technologies pour imiter les comportements humains, falsifier leurs agents utilisateurs (UA) et passer par un grand nombre d'adresses IP.
Pour gérer les activités du bot, Bot Defense utilise la technique suivante :
Challenger le robot : nous pouvons challenger le robot avec un CAPTCHA ou avec des tests invisibles, comme demander soudainement au client de déplacer le curseur de la souris d'une certaine manière, ce qui sera très difficile à résoudre par un robot.
Étranglement/limitation du débit : permettre au robot d'accéder au site, mais ralentir l'allocation de la bande passante pour rendre son fonctionnement beaucoup moins efficace. L'espoir est que l'opérateur abandonne en raison de la vitesse très lente.
Vous pouvez configurer des whitelists de sources IP à considérer comme étant sûres afin que le système n'ait pas besoin de les valider. Cela accélère le temps d'accès au site web.
Une fois que Bot Defense est activé et configuré, vous pouvez visualiser et filtrer les statistiques de trafic et de transaction avec le tableau de bord Bot Defense dans ITCare pour voir quels utilisateurs sont malveillants et comment ils sont atténués.
Coût mensuel par IP publique disponible auprès de votre Service Delivery Manager.
La documentation Swagger API est disponible ici :
Le chemin de base de l'API Vortext est situé à l'adresse :
https://vortext.cloud.cegedim.com pour les services hébergés dans les centres de données cegedim.cloud.
https://messages.cloud.cegedim.com pour les applications tierces qui atteignent Vortext sur Internet.
Toutes les méthodes sont relatives à cette URL.
Par exemple, si vous voulez obtenir le statut de Vortext, vous devez utiliser :
Toutes les demandes à l'API de Vortext sont effectuées par le protocole HTTP, en utilisant le cryptage de transport TLSv1.
Pour l'instant, l'authentification de base est utilisée pour chaque demande faite au service de Vortext.
Chaque demande est complètement apatride, de sorte que vous pouvez utiliser le service Vortext avec une simple ligne decurl.
Si vous ne connaissez pas l'authentification de base, il suffit d'un en-tête de requête http 'Authorization' :
L'identifiant utilisé est username:password
encodé en base 64. La plupart des bibliothèques vous demanderont simplement de fournir un nom d'utilisateur et un mot de passe.
Cette API est principalement destinée à traiter les messages json dans les corps de demande et de réponse http.
Utilisez l'en-tête Content-Type : application/json
pour indiquer au service Vortext le format du corps de votre requête.
Utilisez l'en-tête Accept : application/json
pour indiquer au service Vortext le format que vous souhaitez pour le corps de la réponse.
Comme json ne supporte pas nativement la date et l'heure, tous les paramètres étiquetés comme date dans cette API sont des chaînes au format ISO8601 :
où Z est le fuseau horaire (comme+0200).
Exemples : 2016-06-01T12:27:19.000+0200
Pour les paramètres de requête, n'oubliez pas d'encoder ces paramètres en url.
Vous pouvez personnaliser le nom de l'expéditeur du SMS, au lieu d'un numéro classique tel que "30180". Pour ce faire, veuillez faire une demande dans ITCare à notre équipe en demandant la mise en place de cette fonctionnalité.
Une fois votre compte configuré, tous les SMS envoyés le seront avec ce nom d'expéditeur. Pour l'instant, il n'est pas possible d'avoir plusieurs noms d'expéditeur par compte.
Il est possible de recevoir des réponses PUSH (appel REST https) dès qu'un client répond à un SMS envoyé précédemment. Pour activer cette fonctionnalité, veuillez faire une demande dans ITCare à notre équipe.
Voici les spécifications des demandes sortantes que vous recevrez une fois activées :
Vous pouvez fixer des limites pour éviter les appels multiples / mauvaises boucles et empêcher certaines inondations :
total de SMS envoyés par minute
total de SMS envoyés par heure
Pour activer cette fonctionnalité, veuillez faire une demande dans ITCare à notre équipe.
GlusterFS est disponible sous la forme d'un cluster de deux nœuds avec des pools de stockage répliqués.
GlusterFS est fourni dans les régions de Boulogne et de Toulouse.
Un cluster est composé de deux nœuds dans deux zones de disponibilité différentes pour des raisons de résilience.
Des volumes de stockage peuvent être ajoutés à votre gré en libre-service à partir d'ITCare.
Il est recommandé de ne pas dépasser 2 To.
Cette section énumère les fonctionnalités disponibles pour le client, ainsi que la manière de les demander ou de les exécuter :
Les données sont accessibles par un montage CIFS autorisé uniquement à l'utilisateur ayant le même nom que le volume et authentifié avec le mot de passe défini lors de la création.
Toutes les données sont stockées dans les centres de données cegedim.cloud sur des baies de stockage cryptées.
Le mot de passe fourni par le client lors de la création n'est stocké nulle part par cegedim.cloud. Il ne peut être modifié que sur demande spéciale.
GlusterFS et les composants associés sont surveillés par notre équipe de support.
Un état de santé global est affiché dans ITCare pour votre confort.
OverDrive est une solution de partage, de stockage et de synchronisation de documents en libre-service déployable via ITCare.
Basée sur la solution open source Nextcloud, OverDrive permet à vos utilisateurs de partager des fichiers tout en limitant les risques de fuites de données : c'est une alternative sécurisée aux plateformes standards d'hébergement de fichiers.
L'application est directement administrable via un portail web.
Solution open source hautement sécurisée conforme aux exigences HDS
Hébergement souverain : stockage situé en France dans les datacentres cegedim.cloud
Serveur de transfert sécurisé et multiprotocole avec cryptage SSL/TLS
Partage sécurisé avec des tiers (liens protégés par mot de passe, expiration automatique des liens)
L'authentification multifacteur (MFA):
Activé par défaut pour les comptes d'administrateur
Peut être activé pour les utilisateurs via la console d'administration
Enregistrement de toutes les activités des utilisateurs et des administrateurs
Sauvegardes automatisées et réplication hors site (DRP)
Accessible partout et à tout moment (ordinateur de bureau, navigateur et accès mobile, fonctionnement hors ligne)
Synchronisation en temps réel, importation de fichiers et accès instantané aux données
Versionnement des fichiers et conservation de l'historique pendant 30 jours
Assistance aux utilisateurs par e-mail, téléphone et ITCare
Prise en charge des fichiers volumineux (plus de 1 Go)
Autonomie dans la gestion des partages (création de groupes d'utilisateurs)
Accès à l'interface d'administration de la plateforme
Modification du thème
Gestion de l'accès des utilisateurs
cegedim.cloud garantit le niveau de service managé suivant : déploiement des instances, maintien en condition opérationnelle, flexibilité, sécurité et monitoring sont ainsi assurés par nos experts.
La facturation est mensuelle, dépend de la taille choisie et de la sélection ou non de l'option de surveillance 24/7. L'estimation des coûts pour OverDrive est disponible auprès de votre Service Delivery Manager.
OverDrive est un système d'hébergement de fichiers basé sur la solution Nextcloud.
Le serveur Nextcloud est configuré et accessible via une interface web sécurisée, permettant aux utilisateurs autorisés de contrôler le stockage, de définir des politiques d'accès aux fichiers ou de mettre en place un traitement automatisé des fichiers, de gérer les utilisateurs, d'activer ou de désactiver des fonctionnalités, etc.
Nextcloud est une application web PHP fonctionnant sur un serveur web Linux. Elle stocke les informations sur le partage de fichiers, les détails sur les utilisateurs, les données et la configuration de l'application ainsi que les informations sur les fichiers dans une base de données PostgreSQL.
OverDrive utilise le service de stockage d'objets (S3) comme stockage principal.
Le produit est actuellement disponible dans toutes nos régions ainsi que dans toutes les zones de disponibilité.
OverDrive s'appuie sur le produit d'instance virtuelle Linux de cegedim.cloud.
cegedim.cloud prend en charge la version 27 de Nextcloud dans ce produit OverDrive.
La mise à jour peut être exécutée par cegedim.cloud : soit sur demande, soit lors d'une mise à jour groupée.
Cette section énumère les fonctions / capacités disponibles pour le client et la manière de les demander / de les exécuter :
Dimensionnement supporté de 1 à 49 utilisateurs :
1 Nextcloud Frontend (instance virtuelle Linux - 2/4)
Bucket S3 dédié
Monitoring 24/7 (En option)
Réplication des données activée (reprise après sinistre de l'instance virtuelle)
Les journaux sont accessibles avec le compte administrateur (admin_client) via l'interface web, dans la section "Paramètres" > "Journalisation".
Les journaux sont envoyés à cegedim.cloud SIEM pour détecter les problèmes de sécurité et les actions sensibles.
Un compte admin_client est provisionné par défaut.
Le client peut accéder à son compte en se connectant à l'URL du drive (se terminant par *.mydrive.cegedim.cloud), en choisissant "Authentification directe", et en utilisant le compte admin_client avec le mot de passe choisi lors du provisionnement.
L'authentification des comptes locaux (par exemple : admin_client) est protégée par TOTP.
Le TOTP peut être configuré lors de la première connexion, après le provisionnement de l'OverDrive par ITCare. Il garantit que seul le client peut se connecter au compte admin_client.
cegedim.cloud a toujours la possibilité d'activer le compte admin pour des raisons de sécurité (" bris-de-glace "). Ce mot de passe ne permet pas d'accéder aux données hébergées sur les serveurs web.
Lorsque cela est nécessaire, ces accès sont protégés par plusieurs mesures de sécurité :
Utilisation du TOTP
Accès par le bastion, tel que présenté sur les diagrammes
Traçabilité complète
L'accès au système est réservé aux administrateurs de cegedim.cloud. Ces accès sont nécessaires pour fournir des services obligatoires à l'application, par exemple:
Opérations de monitoring (ex : redémarrage d'un service).
Mise à jour de la version
Mise à jour de la sécurité
Les serveurs fournissant les services OverDrive sont accessibles par SSH et nécessitent d'être authentifiés par le Bastion de cegedim.cloud. Ces accès sont limités aux administrateurs de cegedim.cloud et entièrement journalisés afin de s'assurer que seules des opérations légitimes sont réalisées.
SSL est utilisé lors de la connexion à l'application Nextcloud.
Un profil sécurisé est déployé pour éviter l'utilisation d'un chiffrement obsolète.
L'infrastructure est située en France et les données sont stockées dans les centres de données de cegedim.cloud.
Les fichiers sont stockés sur la solution de stockage d'objets de cegedim.cloud (compatible S3).
Le mot de passe de l'utilisateur final n'est pas stocké dans notre solution de gestion des mots de passe et n'est connu que du client. Ce mot de passe est créé lorsque l'utilisateur final commande son OverDrive sur ITCare.
Le compte admin de cegedim.cloud est désactivé pendant le processus de création de l'OverDrive.
Cette section énumère la gestion des mots de passe :
Chaque instance OverDrive déployée par l'intermédiaire d'ITCare est monitorée. Un contrôle automatique vérifie la disponibilité du service Nextcloud.
Lorsque le site web du lecteur est indisponible, l'alerte est prise en compte par nos équipes de monitoring qui mettent en place des mesures correctives.
L'option 24/7, disponible dans ITCare, permet d'étendre le monitoring aux heures non ouvrables.
Les serveurs sont protégés par l'antivirus cegedim.cloud (SentinelOne).
Les machines virtuelles OverDrive sont toujours sauvegardées par défaut.
La surveillance avancée à l'aide d'ExtraHop est une fonction qui peut être activée dans ITCare au niveau du service global. Elle permet d'accéder à des tableaux de bord avancés sur vos ressources.
Les graphiques suivants sont disponibles dans le tableau de bord Activité :
Bande passante
Trafic total
Code retour HTTP 20*
Requêtes HTTP par Membre de Pool
Top URI demandé
Ce graphique montre l'évolution de la bande passante.
Bits In : largeur de bande moyenne de l'extérieur vers l'IP publique.
Bits Out : bande passante moyenne de l'IP publique vers l'extérieur.
TCP established max : nombre maximal de sessions TCP établies.
Analyse : Une bande passante nulle ou un pic de bande passante peut indiquer un problème.
Bytes In : total de l'extérieur vers l'IP publique.
Bytes Out : total de l'IP publique vers l'extérieur.
Ce graphique montre le nombre total de demandes avec un code de statut de 200+. Les demandes avec un code de statut 400+ ou 500+ ne sont pas affichées ici.
Ce graphique montre le nombre total de requêtes HTTP reçues par les membres du pool.
Analyse : montre que l'équilibrage de la charge est bien fait et si certains membres du pool reçoivent 0 ou trop de requêtes.
Affiche le total des URI demandées au membre du pool.
Analyse : montre les URI qui sont demandées trop souvent, ce qui permet d'améliorer le code.
Ce graphique montre la latence du réseau entre le client et l'IP publique.
Définition du temps d'aller-retour = latence du réseau / temps de traitement = temps de traitement du serveur / URI le plus lent.
Ce graphique montre le temps de réponse des Membres du Pool.
Analyse : peut indiquer un problème de performance du serveur.
Ce graphique montre le top des erreurs HTTP 400+.
Top des erreurs 500/404/400 avec les informations suivantes :
IP Cliente
IP du Membre du Pool
Erreur
URI
Il s'agit d'un tableau de bord de la sécurité. Les meilleures pratiques évoluent rapidement.
Total des réponses envoyées par le serveur aux membres du pool VS le nombre d'erreurs.
Analyse : un changement de comportement peut indiquer un problème. Faites attention à l'échelle entre les erreurs et les réponses.
Temps de traitement du serveur (comme le temps de traitement HTTP). Il indique le temps nécessaire aux serveurs de base de données pour répondre aux membres du pool.
Analyse : Peut indiquer un problème de performance de la base de données ou une mauvaise efficacité des requêtes effectuées par les membres du pool.
GlusterFS est un système de fichiers réseau évolutif open source qui regroupe les ressources de stockage sur disque de plusieurs serveurs dans un seul espace de noms global.
Les cas d'utilisation de GlusterFS comprennent l'informatique en nuage, la diffusion de médias en continu et la livraison de contenu.
Les systèmes de stockage évolutifs basés sur GlusterFS conviennent aux données non structurées telles que les documents, les images, les fichiers audio et vidéo et les fichiers journaux.
GlusterFS est déployé sur site dans les centres de données de cegedim.cloud.
cegedim.cloud garantit le même niveau de service que l'offre Compute : déploiement des instances, maintien en condition opérationnelle, flexibilité, sécurité, monitoring sont ainsi assurés par nos experts.
GlusterFS présente de multiples avantages :
Évolutivité
Traite des milliers de clients
Compatible POSIX
Peut utiliser n'importe quel système de fichiers sur disque qui supporte les attributs étendus.
Accessible à l'aide de protocoles standards comme NFS et SMB.
Fournit la réplication, les quotas, la géo-réplication, les snapshots et la détection de bitrot.
Permet l'optimisation pour différentes charges de travail
Source ouverte
Le dimensionnement peut être configuré en fonction de vos besoins.
L'estimation des coûts pour GlusterFS est disponible via votre Service Delivery Manager.
La facturation est basée sur le nombre de nœuds auxquels s'ajoutent les frais supplémentaires de stockage, de sauvegarde, surveillance 24/7.
Si vous souhaitez limiter les accès réseau à un Bucket, vous devrez créer une politique de gestion de Bucket en utilisant la condition suivante aws:SourceIp
.
Nous utilisons les utilitaires aws s3 et aws s3api issues du client S3 AWSCLIv2 sur Linux.${S3_ENDPOINT}
et ${S3_PROFILE}
sont des variables d'environnement.
Créez un fichier et insérez votre politique de gestion au format JSON :
La politique ci-dessus aura pour effet :
de refuser toutes opérations dont l'adresse IP source n'appartient pas aux réseaux 10.0.0.0/8 et 192.168.0.0/16
Modifiez <bucket>
par le nom de votre Bucket.
Le service de Stockage d'Objets de cegedim.cloud est un service dit "S3 compatible". Certaines fonctionnalités spécifiques d'AWS S3 ne sont pas supportées.
Avec la condition aws:SourceIp
, prend en charge des adresses IPV4 ou des plages d'adresses IPV4. Les adresses en IPV6 ne sont pas supportées.
Lorsque aws:SourceIp
est un réseau complet (ex: 10.0.0.0), il faut indiquer le masque de sous réseau au format CIDR (Classless Inter-Domain Routing).
Exemple:
10.0.0.0/8
192.168.0.0/16
10.45.2.0/24
Lorsque aws:SourceIp
est une adresse IP (ex: 98.2.3.123), il ne faut pas indiquer le masque de sous réseau au format CIDR (Classless Inter-Domain Routing).
Exemples:
98.2.3.123
192.168.1.23
10.45.2.67
Appliquez la politique sur votre Bucket :
Vérifiez si la politique est correctement définie :
Connectez-vous à ITCare et accéder à la section Stockage via le menu latéral gauche.
Cliquez sur Créer un espace de stockage.
Sélectionnez le Centre de données qui sera le site primaire de votre Object Store :
La géo-réplication ne peut pas être activée ou désactivée une fois que l'Object Store est créé.
Recherchez et sélectionnez un Service :
Vous pouvez également définir un Quota. Le quota peut être modifié à tout moment après la création de l'Object Store.
Le nom de votre Object Store sera préfixé par " cos " + le nom du "cloud" auquel appartient le service global sélectionné :cos-<cloud>-<votre nom d'object-store>
Exemple: cos-cegedimit-hello
La dernière étape résume votre demande de création d'Object Store.
Vérifiez si les informations sont correctes et cliquez sur le bouton Submit pour lancer la création.
Une fois la création terminée (cela peut prendre quelques minutes), une pop-up apparaît, affichant vos informations d'identification et les endpoints disponibles pour votre Object Store :
Nom d'utilisateur → votre access_key
Mot de passe → votre secret_key
Gardez votre secret_key en sécurité, elle ne sera plus affiché.
Si vous avez sélectionné un centre de données avec la géo-Réplication activée (étape 2), vous aurez deux endpoints, un pour chaque centre de données.
Si vous avez sélectionné un centre de données avec la géo-réplication désactivée (étape 2), vous n'aurez qu'un seul endpoints, correspondant au centre de données sélectionné.
Cette page présente des informations détaillées sur votre Object Store :
Le service global dont fait partie l'Object Store
Le centre de données où se trouve l'Object Store
Taille globale et nombre d'objets
Statut du quotas
La liste des Object Users
Vous avez également la possibilité de gérer :
Le quota
Les Object Users
Supprimer l'Object Store
Vous avez créé votre Object Store, il est temps maintenant de créer un Bucket.
Nous utilisons les utilitaires aws s3 et aws s3api issues du client S3 AWSCLIv2 sur Linux.${S3_ENDPOINT}
& ${S3_PROFILE}
sont des variables d'environnement.
Utilisez la commande mb
pour créer un Bucket :
Lister les Buckets :
Nous avons maintenant un Bucket, nous allons y charger des objets.
Nous utilisons les utilitaires aws s3 et aws s3api issues du client S3 AWSCLIv2 sur Linux.${S3_ENDPOINT}
& ${S3_PROFILE}
sont des variables d'environnement.
Utilisez la commande cp
pour téléchargez un objet :
Vous pouvez spécifier un préfixe lorsque vous téléchargez un objet dans un Bucket :
Vous pouvez spécifier un quota sur votre Object Store afin de limiter l'espace utilisé.
Lorsque le quota est atteint, le téléchargement des objets dans un Bucket de l'Object Store est refusé.
Pour gérer les quotas, rendez-vous sur la page d'information détaillée de votre Object Store et cliquez sur le bouton Gestion du quota.
Vous pouvez définir un quota de 1 Go à 8 To.
Si vous avez besoin de plus de 8 To de Quota, veuillez contacter cegedim.cloud.
Une fois le Quota appliqué, vous pouvez suivre le statut du Quota sur la page d'information détaillée de votre Object Store :
Lorsque la limite du Quota est atteinte, le téléchargement est refusé (HTTP 403 Forbidden) :
AWS CLI est l'interface en ligne de commande officielle d'AWS (disponible Windows, Linux et MacOS). Il offre toutes les fonctionnalités et les meilleures performances pour être utilisé avec le service de Stockage Objet de cegedim.cloud.
s5cmd est une alternative à AWS CLI. Client performant pour des opérations sur l'API S3 et sur les systèmes de fichiers locaux.
Nous recommandons d'utiliser le SDK officiel d'AWS :
Une bonne pratique consiste à utiliser un client avec une capacité de bascule entre les deux endpoints pour:
Basculer automatiquement vers un autre endpoints lorsque le première est indisponible.
Aucune configuration nécessaire pour permettre le basculement de votre application vers un autre endpoints.
Vider un Bucket est une opération irréversible
Les objets ou les Buckets supprimés ne peuvent pas être restaurés.
L'opération de suppression peut prendre un certain temps, en fonction du nombre d'objets et de versions stockés dans le Bucket.
Si le versionnage n'est pas activé, vous pouvez utiliser la commande rm (remove) avec l'option --recursive
pour vider le Bucket (ou supprimer un sous-ensemble d'objets avec un préfixe spécifique).
La commande suivante supprime les objets qui ont le préfixe doc
, doc/object-1
et doc/object-2
.
Utilisez la commande suivante pour supprimer tous les objets sans spécifier de préfixe.
Vous ne pouvez pas supprimer des objets dans Bucket où le versionnage est activé.
S3 ajoute un marqueur de suppression
(**DeleteMarker)
**lorsque vous supprimez un objet.
Vous ne pouvez pas supprimer des objets où Object Lock est activé, tant que le délai de rétention défini n'est pas atteint ou que la protection "Legal Hold" n'est pas levée.
Si vous utilisez une configuration de cycle de vie pour vider un Bucket, la configuration de cycle de vie doit inclure :
Vous pouvez ajouter des règles de configuration du cycle de vie pour supprimer tous les objets ou un sous-ensemble d'objets ayant un préfixe spécifique. Par exemple, pour supprimer tous les objets d'un Bucket, vous pouvez définir une règle de cycle de vie pour que les objets expirent 1 jour après leur création.
Ci-dessous quelques configurations de cycle de vie pour vider Bucket :
Les règles suivantes s'appliquent au nom des Object Stores du service Stockage Objet de cegedim.cloud :
Le nombre de caractères du nom doit être compris entre 1 et 255 caractères.
Peut inclure un trait d'union (-) et des caractères alphanumériques ([a-zA-Z0-9]).
Évitez l'utilisation de caractères de soulignement (underscore) (_).
Évitez l'utilisation des majuscules.
Ne peut pas commencer par un point (.).
Ne peut pas contenir un double point (..).
Ne peut pas se terminer par un point (.).
Ne peut pas contenir d'espaces.
Ne doit pas être formaté comme une adresse IPv4.
Les noms des Object Stores doivent être uniques.
Créer un Object Store par projet ou par application.
La géo-réplication ne peut pas être activée ou désactivée une fois l'Object Store créé.
Pour de meilleures performances, il est recommandé d'avoir moins de 1000 Buckets dans un seul Object Store.
Le nom d'un Object Store doivent être compatibles avec le format des URL web.
Les règles suivantes s'appliquent au nom des Buckets du service Stockage Objet de cegedim.cloud**:**
Le nombre de caractères doit être compris entre 3 et 255 caractères.
Peut inclure les caractères point (.), tiret (-) et caractères de soulignement (_) et les caractères alphanumériques ([a-zA-Z0-9]).
Évitez l'utilisation des majuscules..
Peut commencer par un trait d'union (-) ou un caractère alphanumérique.
Ne peut pas commencer par un point (.).
Ne peut pas contenir un double point (..).
Ne peut pas se terminer par un point (.).
Ne peut pas contenir d'espaces.
Ne doit pas être formaté comme une adresse IPv4.
Le nom d'un Bucket doivent être uniques au sein d'un Object Store.
Utilisez les Buckets pour un environnement, un flux de travail ou des utilisations spécifiques. Par exemple : dev, test, finance, opérations, etc.
Dans un Object Store dont la Géo-replication est activée, créez des Buckets en utilisant le endpoint le plus proche (EB4 ou ET1) de l'application qui accède aux objets.
Il y a des opérations supplémentaires liés à la vérification de la dernière version d'un objet, si le site interrogé n'est pas le propriétaire de l'objet en question. Cela peut avoir un impact sur les performances.
Pour de meilleures performances, il est recommandé d'avoir moins de 1000 Buckets dans un seul Object Store.
Les noms des Buckets doivent être compatibles avec le format des URL web.
Les règles suivantes s'appliquent à la dénomination des Objets dans la base de données de cegedim.cloud :
Ne peut pas être null ou une chaîne vide.
La longueur est comprise entre 1 et 255 (caractères Unicode).
Évitez d'utiliser l'espace.
Pas de validation sur les caractères.
Les noms d'objets doivent être compatibles avec le format des URL web.
Cette section fournit des bonnes pratiques pour la manipulation d'objets de petite et de grande taille dans votre application. Il fournit également des informations sur les options de gestion version et les détails sur la compression.
Un objet est considéré comme petit lorsqu'il a une taille inférieur à 100 Ko.
Le service Stockage Objet de cegedim.cloud a un mécanisme interne qui améliore la performance pour les écritures de données des objets de faible taille. Il agrège plusieurs objets de mis en file d'attente en mémoire, puis les écrit en une seule opération sur le disque, et cela jusqu'à 2 Mo de données.
Cela améliore les performances en réduisant le nombre d'allers-retours pour traiter les écritures individuelles au niveau du stockage.
Bien que le service Stockage Objet de cegedim.cloud dispose d'optimisations pour les écritures de faible volumétrie, si vous avez la possibilité, dans votre application de définir la taille d'un objet
choisissez alors une taille plus grande (par exemple 1 Mo plutôt que 64 Ko) ou une valeur qui s'aligne sur la norme du service Stockage Objet de cegedim.cloud de 2 Mo pour des raisons de performance.
L'un des problèmes liés à la lecture et à l'écriture des objets de grande taille est la performance.
Le service Stockage Objet de cegedim.cloud fournit certaines fonctionnalités API pour réduire l'impact sur les performances des objets de grande taille, tels que les téléchargements "multipart". Voici quelques conseils pour mitiger certains des problèmes liés à l'accès aux objets volumineux :
Lorsque vous travaillez avec des objets volumineux (> 100 Mo), utilisez la fonction de téléchargement en plusieurs parties. Cela permet de mettre en pause et de reprendre les téléchargements pour les objets volumineux.
Pour des objet avec un taille inférieur à 1 Go, la taille du tampon interne étant de 2 Mo, utilisez un multiple de 2 Mo (par exemple 8 Mo).
Pour des objets de taille supérieur à 1 Go utilisez une taille de 128 Mo.
Le débit des performances peut être amélioré en parallélisant les téléchargements depuis votre application ou client.
Utilisez des API qui permettent un chargement et un téléchargement faciles, par exemple :
En Java, utilisez le TransferManager
En .NET, utilisez TransferUtility
Object Lock empêche la suppression des objets et de leurs versions, pendant une période définie par l'utilisateur.
La politique de rétention est définie à l'aide de l'API S3 ou des valeurs par défaut au niveau du Bucket ou directement sur l'objet.
Les objets sont verrouillés pour la durée de la période de rétention. Les scénarios de rétention légale sont également pris en charge.
Il existe deux types de protection:
Retention period: Spécifie une période de temps fixe pendant laquelle une version d'objet est verrouillée. Pendant cette période, votre version de l'objet est protégée en écriture et ne peut pas être modifiée ou supprimée.
Legal hold: Offre la même protection qu'une période de rétention, mais sans date d'expiration. Au contraire, Legal hold reste en place jusqu'à ce que vous la désactiviez explicitement. Les legal hold sont indépendantes des périodes de rétention.
Il existe deux modes pour la période de rétention :
Avec le mode conformité, si vous appliquez une période de rétention par erreur (par exemple 6 ans au lieu de 6 jours), cegedim.cloud n'a aucune possibilité de supprimer ou de réduire la période de rétention.
Une bonne pratique consiste à commencer avec le mode gouvernance pour effectuer des tests, puis de passer ensuite, en mode conformité.
Pour plus d'informations, voir :
Object Lock nécessite la désactivation de la fonctionnalité ADO (Access During Outage) au niveau du magasin d'objets.
Les Object Stores sans ADO ne peuvent pas être créés au travers d'ITCare et doivent manuellement par les équipes de cegedim.cloud.
Object Lock ne fonctionne qu'avec les Object Users de type IAM.
Object Lock ne fonctionne qu'avec des Buckets où le versionnage est activé.
L'activation de Object Lock sur le Bucket active automatiquement le versionnage .
Une fois Object Lock activé, il n'est pas possible de le désactiver ou de suspendre le versionnage au niveau du Bucket.
Object Lock n'est pas compatible avec les Buckets où la fonctionnalité "système de fichiers" est activée.
Object Lock est uniquement supporté l'API S3.
Un Bucket peut avoir une configuration Object Lock par défaut comprenant un mode de rétention (gouvernance ou conformité) et une période de rétention (exprimée en jours ou en années).
Object Lock s'appliquent uniquement aux versions individuelles des objets
Les différentes versions d'un même objet peuvent avoir des modes et des périodes de rétention différents.
Object Lock empêche la suppression ou la modification d'un objet. La modification ne signifie pas que de nouvelles versions ne peuvent pas être créées (de nouvelles versions peuvent être créées avec leurs propres paramètres de rétention).
Un objet peut toujours être supprimé en fonction de sa version. Un marqueur de suppression est créé. La version existe toujours et est verrouillée.
Le mode conformité est plus strict : les périodes de rétention ne peuvent pas être supprimées, réduites ou déclassés en mode gouvernance.
Le mode gouvernance est moins strict : les période de rétention peuvent être supprimées, contournées, ou même élevés en mode conformité.
La mise à jour des métadonnées d'une version d' un objet, qui se produit lorsque vous placez ou modifiez Object Lock, n'écrase pas la version de l'objet et ne réinitialise pas son horodatage "Last-Modified".
La période de rétention peut être placée explicitement sur un objet ou implicitement, par le biais d'une configuration Object Lock définit au niveau du Bucket.
Le fait de placer une une configuration Object Lock sur un Bucket n'a aucun effet les objets déjà présents dans le Bucket.
La modification de période de rétention définit au niveau du Bucket ne change pas la période de rétention sur les objets déjà présent dans le Bucket.
Les objets sous verrou sont protégés contre les suppressions de cycle de vie.
La logique du cycle de vie est rendue difficile en raison de la variété des comportements des différents verrous.
Du point de vue du cycle de vie, il existe des verrous sans date, des verrous dont la date peut être prolongée et des verrous dont la date peut être réduite.
Pour le Mode de conformité : la date de conservation ne peut pas être réduite, mais elle peut être augmentée.
Pour le Mode de gouvernance : la date de verrouillage peut augmenter, diminuer ou être supprimée.
Pour la protection de type Legal Hold, la rétention est indéfinie.
Le contrôle d'accès au travers des politiques IAM est une partie importante de la fonctionnalité Object Lock.
La permission s3:BypassGovernanceRetention
est importante car elle permet supprimer un objet protégé par Object Lock avec une configuration en mode gouvernance.
Les conditions des politiques IAM sont décrites ci-dessous et vous permettent de limiter la période de rétention et le type de protection (Legal Hold) spécifiés sur les objets.
Il n'est pas possible de gérer les politiques IAM avec ITCare.
Ces condition peuvent être utilisées dans les politiques de gestion des Buckets et IAM pour contrôler les comportements de Objet Lock sur objets.
Par exemple: s'assurer à ce que la période de rétention ne dépasse pas 5 ans.
Nous utilisons les utilitaires aws s3 et aws s3api issues du client S3 AWSCLIv2 sur Linux. ${S3_ENDPOINT}
& ${S3_PROFILE}
sont des variables d'environnement.
Créez un Bucket avec le Object Lock activé :
Vous ne pouvez activer Object Lock uniquement à la création d'un Bucket.
Vous ne pouvez pas activer Object Lock sur un Bucket existant.
Ajoutez une configuration Object Lock sur votre Bucket :
Obtenir la configuration Object Lock actuelle d'un Bucket :
Dans ce contexte, il n'y a pas de configuration Object Lock définie au niveau du Bucket.
Mais le Bucket a été créé avec le paramètre --object-lock-enabled-for-bucket.
Nous utilisons les utilitaires aws s3 et aws s3api issues du client S3 AWSCLIv2 sur Linux. ${S3_ENDPOINT}
& ${S3_PROFILE}
sont des variables d'environnement.
Téléchargez un objet dans un Bucket :
Appliquez la période de rétention sur l'objet :
Utilisez head-object
pour obtenir les métadonnées de l'objet et les informations sur la rétention :
Augmentez la rétention (+1 jours) :
Supprimez l'objet :
Vérifiez la version :
Cela affichera toutes les versions de l'objet ainsi que le marqueur de suppression
(DeleteMarker)
, créé lorsque nous avons supprimé l'objet.
Supprimez le marqueur de suppression
(DeleteMarker)
en utilisant l'identifiant de la version :
Uploadez une nouvelle version de l'objet :
Nous avons maintenant 2 versions de l'objet feather.ttf.
Supprimez une version spécifique :
La version de l'objet supprimée "devient" un marqueur de suppression
(DeleteMarker).
Lister les versions :
Utilisez l'option --bypass-governance-retention
pour contourner la mode gouvernance et supprimer le marqueur de suppression
(DeleteMarker)
:
Lister les versions :
Supprimer la dernière version de l'objet avec --bypass-governance-retention
:
Lister les versions :
Résultat vide.
Résultat vide - bucket vide.
Les configurations Object Lock peuvent être appliquées au niveau du Bucket.
La rétention sera appliquée sur chaque objet mis dans le Bucket.
Definition d'une configuration Object Lock
La configuration Object Lock est un document JSON :
Le mode de rétention par défaut que vous souhaitez appliquer aux nouveaux objets placés dans le Bucket. Doit être utilisé avec Jours ou Années.
Les valeurs possibles sont COMPLIANCE ou GOVERNANCE.
Le nombre de jours de la période de rétention appliquée par défaut. Doit être utilisé avec Mode.
Années
Le nombre d'années de la période de rétention appliquée par défaut. Doit être utilisé avec Mode. Les jours et les années sont mutuellement exclusif.
s3Browser ne vous permet pas de gérer les configurations Object Lock sur les Buckets ou les objets.
Avec s3Browser, vous pouvez voir les métadonnées des objets et obtenir la configuration Object Lock actuellement définie sur l'objet :
Le service de stockage Stockage Objet de cegedim.cloud prend en charge la génération d'URL pré-signées afin d'accorder l'accès aux objets sans avoir besoin d'authentification.
Les URL pré-signées sont utilisées pour fournir un accès à durée limitée, à un objet privé dans votre Bucket S3. Ils fonctionnent en ajoutant une Access key
, une date d'expiration et une signature (Sigv4) comme paramètres de requête à l'objet S3.
Il y a deux cas d'utilisation courants où vous pouvez les utiliser :
Partage simple et occasionnel d'objets.
Accès fréquent et programmatique pour visualiser un objet dans une application
Accès fréquent et programmatique au téléchargement d'un objet par l'intermédiaire d'une application
Nous utilisons les utilitaires aws s3 et aws s3api issues du client S3 AWSCLIv2 sur Linux. ${S3_ENDPOINT}
et ${S3_PROFILE}
sont des variables d'environnement.
Dans cet exemple, l'URL générée a une expiration de 10 minutes. Passé ce délai, l'objet ne sera plus accessible, via cette URL.
--expires-in : Nombre de secondes avant l'expiration de l'URL pré-signée. La valeur par défaut est de 3600 secondes. Le délai maximal d'expiration est de 7 jours (604800 secondes).
Si un objet ayant la même clé existe déjà dans le bucket spécifié dans l'URL pré-signée, l'objet existant sera remplacé.
aws s3 et aws s3api ne supportent pas la génération d'url pré-signées pour l'upload.
Vous devez utiliser AWS SDK pour créer une url pré-signée pour l'upload.
L'URL pré-signée d'upload ne fonctionne qu'avec un adressage de type chemin.
Remplacez aws_access_key_id
et aws_secret_access_key
par vos propres identifiants.
ExpiresIn
(entier) : Nombre de secondes avant l'expiration de l'URL pré-signée. La valeur par défaut est de 3600 secondes. Le délai d'expiration maximal est de 7 jours.
Vous pouvez utiliser un outil tel que curl
pour télécharger votre fichier dans le bucket, en utilisant l'URL générée précédemment :
Par défaut, le service de Stockage Objet cegedim.cloud ne fournit pas de capacités de sauvegarde. Cela signifie que si vous supprimez accidentellement un objet, il n'est pas possible de le restaurer.
Le versionnage consiste à conserver plusieurs versions d'un objet dans le même Bucket. Vous pouvez utiliser la fonctionnalité S3 Versioning pour préserver, récupérer et restaurer chaque version de chaque objet stocké dans votre Bucket.
Grâce à la gestion des versions, vous pouvez vous même restaurer facilement vos objets suite à des actions involontaires d'utilisateurs ou d'applications défaillantes.
Les Buckets dont la gestion des versions est activée peuvent vous aider à récupérer des objets après une suppression ou un écrasement accidentel. Par exemple, si vous supprimez un objet, un marqueur de suppression est créé au lieu de le supprimer définitivement.
Le marqueur de suppression devient la version actuelle de l'objet. Si vous écrasez un objet, il en résulte une nouvelle version de l'objet dans le Bucket.
Par défaut, le versionnage S3 est désactivé sur les Buckets et vous devez l'activer explicitement. Pour gérer les versions de Bucket et d'objet, vous pouvez utiliser le client AWS CLI ou tout autre outil compatible avec l'API AWS S3.
Vous serez facturé pour l'espace utilisé par l'ensemble des versions d'un objet.
Le nombre maximum de version conseillé pour un objet et de 50 000. Il est déconseillé d'aller au-delà de ce seuil.
Nous utilisons les utilitaires aws s3 et aws s3api issues du client S3 AWSCLIv2 sur Linux.${S3_ENDPOINT}
&${S3_PROFILE}
sont des variables d'environnement
Si la gestion des versions n'a jamais été défini sur un Bucket, il n'a pas d'état de versionnage. L'utilisation de la CLI AWS aws s3api , get-bucket-versioning
, ne renvoie rien :
Pour un Bucket avec le versionnage activé :
Pour un Bucket avec versionnage suspendu :
Une fois que le versionnage est activé sur un Bucket, il ne peut plus être supprimé. Mais vous avez la possibilité de la suspendre.
Vous pouvez utiliser la fonction list-object-versions
de la commande s3api à partir de l'AWSCLI :
Pour obtenir une version spécifique d'un objet en utilisant get-object
et --version-id
<Version ID>
Un marqueur de suppression **(DeleteMarker)
**d'un objet, a également un identifiant de version, vous pouvez le supprimer en utilisant son identifiant de version afin de restaurer votre objet.
Vous pouvez supprimer une version spécifique sur un objet. Si la version spécifiée n'est pas la version courante, la version spécifiée de l'objet est supprimée et aucun marqueur de suppression (DeleteMarker)
n'est créé.
Vault sécurise, stocke et contrôle étroitement l'accès aux jetons, aux mots de passe, aux certificats, aux clés API et aux autres secrets de l'informatique moderne.
Il est hautement disponible car il est hébergé sur trois VM, chacune d'entre elles se trouvant dans une zone de disponibilité différente.
Répartition des nœuds par zone de disponibilité :
Cette section liste les fonctionnalités disponibles pour le client, ainsi que la manière de les demander ou de les exécuter :
Chacun des trois nœuds possède les caractéristiques matérielles suivantes : 2 CPU, 4 Go de RAM et 90 Go de disque SSD.
Le PaaS Vault est disponible sur HTTPS en utilisant les comptes d'administration. Cela garantit une authentification centralisée.
Par défaut, il existe deux rôles :
l'administrateur sécurité, qui dispose d'un accès complet en lecture sur les clusters Vault.
l'administrateur du cluster, qui peut :
Lire le bilan de santé du système
Activer et gérer les méthodes d'authentification dans Vault
Créer et gérer des politiques ACL dans Vault, sauf sur les politiques cluster_admin et security_admin.
Activer et gérer les clés/valeurs des secrets/paths.
Activer et gérer le moteur de secrets
Gérer les identités
Tout le trafic est envoyé par HTTPS. Aucune donnée n'est envoyée en clair.
Vault dispose de deux types de logs : les logs opérationnels du serveur Vault et les logs d'audit. Les logs d'audit enregistrent chaque demande faite à Vault ainsi que la réponse envoyée par Vault.
Les logs du serveur sont des logs opérationnels qui donnent un aperçu de ce que le serveur fait en interne et en arrière-plan pendant l'exécution de Vault.
Les dispositifs d'audit sont activés et les logs de sortie sont stockés dans le fichier /var/log/vault/vault_audit.log
. Les serveurs de Vault reçoivent l'application UF_ALL_IT-vault qui envoie les fichiers de logs à Splunk par syslog, dans l'index vault
et applique le sourcetype vault
.
Les données sont situées dans EB ou ET, en fonction du DC choisi par le client lors de la commande du cluster Vault.
Cette section énumère les politiques de gestion :
Un ticket devra être créé pour modifier ces politiques.
Il n'y a qu'un seul compte intégré en cas d'urgence. C'est le root token et il a tous les droits sur le cluster Vault.
Il est stocké en toute sécurité dans le serveur Vault de transit et toute utilisation du root token déclenche une alerte dans le SIEM.
cegedim.cloud fournit une surveillance de base sur la mémoire, le CPU, le réseau et l'espace disque.
Les surveillances personnalisées suivantes ont été ajoutées dans Centreon :
Un Object Store est un conteneur logique pour les Buckets et les objets stockés dans le service de stockage objet de cegedim.cloud.
Il est accompagné d'un Object User dédié qui est le seul autorisé à lister et à gérer les objets dans cet Object Store. Vous pouvez créer d'autres Object User.
Lors de la création d'un Object Store, vous devez choisir :
Un centre de données :
EB4 - Centres de données Boulogne (non répliqué)
ET1 - Centres de données Toulouse (non répliqué)
EB4-ET1 - Les données sont répliquées sur EB4 et ET1 et sont accessibles depuis les deux centres de données.
Vous n'êtes pas limité et pouvez créer autant de Object Store que vous le souhaitez.
Néanmoins, il peut être préférable de segmenter les objets par Bucket pour les objets d'une même application ou de différentes applications.
Nous recommandons d'utiliser un Object Store au niveau projet, "groupe de projets" ou application, et un Bucket au niveau de la "typologie des fichiers" ou de l'environnement.
Un Bucket est un conteneur d'objets délimité logiquement. Chaque objet est stocké dans un Bucket.
Un Bucket peut être créé à l'aide d'un client S3 et possède des attributs que vous pouvez utiliser pour contrôler son comportement et celui de ses objets, par exemple :
Les politiques de gestion de version qui vous permettent le versionnage des objets
Les politiques de gestion de Bucket qui vous permettent de configurer les autorisations et les restrictions pour les objets situés dans un Bucket**.**
Un objet est l'équivalent d'un fichier sur un système de fichiers classique.
Chaque objet appartient à un Bucket et possède une "clé"
comme identifiant unique.
Notez que la notion de dossiers n'existent pas dans un service de stockage objet, mais vous pouvez utiliser des préfixes et des délimiteurs pour organiser les objets que vous stockez dans les Buckets.
Un préfixe est une chaîne de caractères au début du nom de la "clé" de l'objet.
Un délimiteur est un caractère, généralement le slash "/
", utilisé pour séparer chaque niveau d'objets et simuler une hiérarchie semblable à système de fichiers.
Par exemple, si vous stockez des informations sur les clients, organisées par années et par mois :
Dans cet exemple "/
" est le délimiteur, et client1/2020/04
est un un préfixe.
Le service de Stockage Objet de cegedim.cloud fournit 2 points endpoints:
Permet d'utiliser le service de Stockage Objet via EB4 - Centre de données de Boulogne.
Permet d'utiliser le service de Stockage Objet via ET1 - Centre de données de Toulouse.
Dans le cas d'un Object Store géo-répliqué (EB4-ET1), les deux endpoints vous permettent d'accéder à vos objets.
Si vous téléchargez un objet en utilisant le endpoint EB4, le site EB4 deviendra le propriétaire de l'objet, et vice versa pour ET1.
L'accès aux Buckets se fait par l'intermédiaire d'un Object User.
Lorsqu'un Object Store est créé, un Object User est automatiquement créé avec le label "Initial S3 user".
L'Object User dispose d'une access_key et d'une secret_key qui sont toutes deux générées automatiquement par cegedim.cloud.
Vous avez la possibilité de créer d'autres Object Users au sein de votre Object Store.
Un Object Users est lié à un seul Object Store et ne peut pas être utilisé pour effectuer des opérations sur un autre Object Store.
A tout moment, vous avez la possibilité de re-générer la secret_key d'un Object User, pour des raisons de sécurité ou lorsque l'Object User est compromis.
Lors de la modification de la secret_key, vous pouvez ajouter une "période de grâce" pendant laquelle l'ancienne et la nouvelle clé secret_key sont valides et acceptées par cegedim.cloud.
Les autorisations sont gérées au niveau du Bucket en utilisant les politiques de gestion des Buckets.
Les politiques de gestion des Buckets vous permettent d'avoir une gestion fine des permissions à appliquer sur les objets et les Object Users, basées ou non sur des déclarations conditionnelles, comme l'access_key de l'Object User ou le Adresse IP source.
Lors de la création d'un Bucket, par défaut, aucune politique de gestion n'existe. Aussi, par défaut, un Bucket ne dispose pas d’accès public/anonyme.
Cela signifie que seul l'Object Users qui a créé le Bucket peut y accéder.
Le service de stockage objet cegedim.cloud est uniquement disponible via le protocole HTTPS sur le port 443.
La fonctionnalité S3 Bucket logging n'est pas supporté le service de Stockage Objet cegedim.cloud.
Toutes les opérations sont enregistrées par cegedim.cloud.
Les journaux incluent les opérations sur l'Object Store, l'Object User, ainsi que les opérations faites au niveau des Buckets et des objets (GET, PUT, DELETE,...).
Si vous avez besoin d'une extraction des opérations réalisées sur vos ressources, veuillez contacter le support cegedim.cloud.
Le service de Stockage Objet cegedim.cloud supporte le partage d'objets à l'aide d'URLs pré-signées. Vous pouvez partager des objets avec un tiers en créant une URL pré-signée.
Lorsque vous créez une URL pré-signée, vous devez fournir :
Vos informations d'identification de sécurité
Un nom de bucket et une clé d'objet
Une méthode HTTP (PUT pour le téléchargement d'objets)
Un délai d'expiration
Les URL pré-signées ne sont valables que pour la durée spécifiée.
Le service de Stockage Objet cegedim.cloud supporte la définition de politiques des gestion des Buckets.
Ces politiques fournissent à des utilisateurs spécifiques, ou à tous les utilisateurs, des autorisations conditionnelles et granulaires pour des actions spécifiques.
Les conditions de politique peuvent être utilisées pour attribuer des autorisations à une gamme d'objets qui correspondent à la condition et peuvent être utilisées pour attribuer automatiquement des autorisations aux objets nouvellement créés.
Exemple de politique de gestion d'un Bucket :
Le service de Stockage Objet cegedim.cloud supporte les configuration de cycle de vie des objets dans un Bucket.
Une configuration de cycle de vie est un ensemble de règles définissant les actions applicables à un groupe d'objets. Seules les actions d'expiration sont prises en charge.
Vous pouvez définir une configuration de cycle de vie pour supprimer automatiquement les objets.
Exemple de configuration du cycle de vie :
Le service de stockage objet cegedim.cloud supporte le verrouillage des objets (Object Lock).
Object Lock empêche la suppression des objets et de leurs versions, pendant une période définie par l'utilisateur.
La politique de rétention est définie à l'aide de l'API S3 ou des valeurs par défaut au niveau du Bucket ou directement sur l'objet.
Les objets sont verrouillés pour la durée de la période de rétention. Les scénarios de rétention légale sont également pris en charge.
Il existe deux types de protection:
Retention period: Spécifie une période de temps fixe pendant laquelle une version d'objet est verrouillée. Pendant cette période, votre version de l'objet est protégée en écriture et ne peut pas être modifiée ou supprimée.
Legal hold: Offre la même protection qu'une période de rétention, mais sans date d'expiration. Au contraire, Legal hold reste en place jusqu'à ce que vous la désactiviez explicitement. Les legal hold sont indépendantes des périodes de rétention.
Il existe deux modes pour la période de rétention :
Avec le mode conformité, si vous appliquez une période de rétention par erreur (par exemple 6 ans au lieu de 6 jours), cegedim.cloud n'a aucune possibilité de supprimer ou de réduire la période de rétention.
Une bonne pratique consiste à commencer avec mode gouvernance pour effectuer des tests, puis de passer ensuite, en mode conformité.
Comportements spécifiques par rapport à l'API AWS.
La création de Buckets utilisant des noms de moins de trois caractères échoue avec le message :
Lors de la création d'un Bucket ou d'un objet avec un contenu vide, le service de Stockage Objet cegedim.cloud renvoie une erreur 400 invalid content-length
ce qui diffère d'AWS qui renvoie une erreur 400 Bad Request
.
La copie d'un objet dans un autre Bucket qui indexe la même clé d'indexation des métadonnées utilisateur mais avec un type de données différent n'est pas prise en charge et échoue avec une erreur 500 Server Error
.
Lors de l'énumération des objets d'un Bucket, si vous utilisez un préfixe et un délimiteur mais fournissez un marker invalide, le service de Stockage Objet cegedim.cloud renvoie une erreur 500 Server Error
ou 400 Bad Request
pour un Bucket si la fonctionnalité "Système de fichier" est activée.
Cependant, AWS renvoie 200 OK
et les objets ne sont pas répertoriés.
Pour les Buckets où la gestion des versions est activée, le service de Stockage Objet cegedim.cloud ne crée pas de marqueur de suppression (Delete marker) lorsqu'un objet déjà supprimé est supprimé à nouveau.
Cela diffère de l'API AWS S3, qui insère toujours un marqueur de suppression (Delete marker) pour la suppression d'objets supprimés dans les Buckets où le versionnage est activé.
Ce changement de comportement n'est applicable que lorsque l'objet supprimé est à nouveau supprimé de la zone propriétaire.
Lorsqu'une tentative est faite pour créer un Bucket avec un nom déjà existant, le comportement de service de Stockage Objet cegedim.cloud peut différer de celui d'AWS.
l'API AWS retourne toujours une erreur 409 Conflit
lorsqu'un utilisateur disposant des permissions (ACL) FULL_CONTROL
sur le Bucket, ou de toute autre autorisation, tente de recréer le Bucket.
Lorsqu'un Object User avec les permissions (ACL) FULL_CONTROL
ou WRITE_ACP
sur le Bucket tente de recréer le Bucket,
Le service de Stockage Objet cegedim.cloud renvoie 200 OK
et l'ACL est écrasée, cependant, le propriétaire n'est pas modifié.
Un Object User avec des permissions WRITE/READ
obtiendra une erreur 409 Conflit
s'il tente de recréer un bucket.
Lorsqu'une tentative de recréer un bucket est faite par le propriétaire du bucket, le service renvoie 200 OK
et écrase l'ACL. L'API AWS S3 se comporte de la même manière.
Lorsqu'un Object User n'a pas de privilèges d'accès au Bucket, une tentative pour recréer le Bucket entraîne une erreur 409 Conflit
. L'API AWS S3 se comporte de la même manière.
Vault peut être déployé via ITCare depuis la section Sécurité du menu latéral gauche.
Un bouton Créer une instance Vault vous permet d'accéder au formulaire de déploiement.
Chercher et sélectionner le Service Global dans lequel vous allez créer votre nouvelle instance Vault. Cliquer sur Suivant.
A l'étape suivante, fournir les informations suivantes :
Le nom de l'instance de Vault
Le groupe AD de sécurité pour l'administration
Si la création d'un nouveau groupe AD de sécurité est nécessaire, merci de créer une ticket requête via le formulaire Gestion des groupes AD.
Cliquer sur Suivant, puis sélectionner la Région dans laquelle vous souhaitez effectuer le déploiement.
Enfin, la synthèse de votre demande s'affiche. Vérifier les informations saisies puis soumettre pour lancer la création de votre instance Vault.
Une fois l'instance créée, vous serez notifié par e-mail.
Depuis votre Bastion, accédez ensuite à votre instance Vault : https://<cluster>.vault.cegedim.cloud
Cette procédure vous explique comment déployer le CLI Vault sur votre bastion.
Copier le fichier téléchargé "vault_x.x.x_windows_amd64.zip" sur votre Bastion dans C:\temp.
Ouvrir un cmd shell et exécutez la commande ci-dessous :
Cet article décrit comment demander le prérequis de Vault sur les Services de conteneurs de cegedim.cloud**.**
Un cluster Kubernetes existant est requis pour configurer une intégration avec Vault
Après la résolution du ticket, allez dans Rancher Cluster Manager → Cluster → Modifier pour vérifier si l'Authorized EndPoint est activé.
À partir de Rancher Cluster Explorer → Apps & Marketplace, vérifiez si le graphique de la voûte est disponible.
Cet article décrit comment configurer l'injecteur Vault sur le service Kubernetes fourni par cegedim.cloud**.**
Créer un projet et un espace Vault
Créer un projet : vault
Créer un espace : vault
Déployer Vault Agent Injector
Depuis Rancher, allez dans "Apps & Marketplace" → "Charts".
Recherchez "vault" et sélectionnez "vault - Official HashiCorp Vault Chart".
Sélectionnez l'espace "vault" et nommez votre déploiement "vault-injector"
Allez dans "Values YAML" et recherchez le paramètre "externalVaultAddr" pour définir la valeur avec l'URL de votre cluster de vault : https://<cluster>.vault.cegedim.cloud
Cliquez sur Installer.
Le déploiement sera créé dans l'espace vault :
ClusterRole :
vault-injector-agent-injector-clusterrole
ServiceAccounts _:_
vault-injector : ce compte de service sera utilisé par vault pour se connecter à l'API Kubernetes.
vault-injector-agent-injector : ce compte de service est utilisé par le vault-injector-agent-injector
CusterRoleBindings :
vault-injector-agent-injector-binding: attache le ClusterRole vault-injector-agent-injector-clusterrole au compte de service vault-injector-agent-injector
vault-injector-server-binding : fournit system:auth-delegator au compte de service vault-injector
Déploiement :
vault-injector-agent-injector
Cet article décrit comment activer la méthode auth de kubernetes pour s'authentifier sur l'instance Vault cegedim.cloud en utilisant un jeton de compte de service Kubernetes.
Conditions préalables :
CLI de Vault
Point d'accès autorisé de Kubernetes pour Vault
certificat kubernetes
Activer Méthode d'authentification Kubernetes sur votre cegedim.cloud Services de conteneurs Depuis Vault CLI configuré et connecté à votre cegedim.cloud Vault instance cluster.
Vous pouvez vérifier avec l'interface utilisateur de Vault la configuration de cette méthode d'authentification dans l'onglet Accès.
Conditions préalables :
jeton_reviewer_jwt: Token à obtenir de Rancher Kubernetes Secret vault-injector-token
kubernetes_host: Kubernetes Authorized Endpoint API pour obtenir de la configuration de Rancher Kubernetes Cluster.
kubernetes_ca_cert: Utiliser ci-dessous le certificat racine de l'AC de l'API Kubernetes Authorized Endpoint
Il ne s'agit pas de l'AC de Kubernetes car l'API Kubernetes Authorized Endpoint est exposée par cegedim.cloud Load Balancer et par Let's Encrypt.
Copiez/collez le fichier de certificat ci-dessous sur C:\Temp dans votre profil bastion pour permettre l'accès avec Vault CLI.
À partir du shell cmd, exécutez la commande ci-dessous avec les valeurs prérequises correctes ci-dessus pour configurer la méthode Auth :
Cet article décrit comment déployer la base de données PostgreSQL avec le nom d'utilisateur et le mot de passe stockés dans l'instance Vault.
Conditions préalables :
Cluster Kubernetes cegedim.cloud
Instance Vault cegedim.cloud
CLI de Vault
Kubernetes connecté à Vault
Kubectl
Connectez-vous à votre Vault
Créer le moteur demopostgres
Il est important de préfixer tout engine path par ce chemin statique secret/ sinon vous ne pourrez pas administrer avec le rôle d'administrateur de votre BU.
Créez votre nom d'utilisateur et votre mot de passe DB Secret
Créer le fichier de politique de lecture JSON C:\Temp\policy_demopostgres.json
Créer une politique
Appliquer la politique sur le secret
Cette action connecte le compte de service Kubernetes sa-demopostgres, de l'espace de noms vault-demopostgres avec la politique Vault policy_demopostgres.
Le jeton renvoyé après l'authentification est valide pendant 24 heures.
Créer un espace de nom
Créer un compte de service Kubernetes
Créer le fichier de déploiement vault_demopostgres.yaml
Déploiement de Vault Postgres Demo
Vérifiez votre déploiement dans Rancher
Cet article décrit comment déployer SonarQube une application avec une base de données PostgreSQL dont le nom d'utilisateur et le mot de passe sont stockés dans l'instance Vault de cegedim.cloud.
Conditions préalables :
Cluster Kubernetes cegedim.cloud
Instance Vault cegedim.cloud
CLI de Vault
Kubernetes connecté à Vault
Kubectl
Connectez-vous à votre Vault
Créer le moteur demopostgres
Il est important de préfixer tout engine path par ce chemin statique secret/ sinon vous ne pourrez pas administrer avec le rôle d'administrateur de votre BU.
Créez votre nom d'utilisateur et votre mot de passe DB Secret (ou réutiliser le DB Secret créé précédemment)
Créer le fichier de politique de lecture JSON C:\Temp\policy_demopostgres.json
Créer une politique
Appliquer la politique sur le secret
Cette action connecte le compte de service Kubernetes sa-demopostgres, de l'espace de noms vault-demopostgres avec la politique Vault policy_demopostgres.
Le jeton renvoyé après l'authentification est valide pendant 24 heures.
Créer un espace de nom (ou réutiliser un Namespace créé précédemment)
Créer un compte de service Kubernetes (ou réutiliser le compte de service créé précédemment)
Créer le fichier de déploiement vault_demosonarqube.yaml
Déployer la démo de Vault SonarQube
La configuration d'un cycle de vie vous permet de définir une politique d'expiration de vos objets et de les supprimer automatiquement.
Dans cet exemple, nous allons créer une politique de gestion du cycle de vie pour supprimer les objets dont la clé commence par rapports/
et qui ont plus de 90 jours.
La gestion des configuration des Cycle de Vie est possible avec des clients avec interface graphique (S3 Browser) ou les SDK AWS.
Dans cet exemple, nous utiliserons le client en ligne de commande AWS CLI.
Le cycle de vie est définit au niveau du Bucket.
Un maximum de 1000 règles de cycle de vie par Bucket est applicable.
Il peut y avoir un délai entre la date d'expiration et la date à laquelle le service de Stockage Objet supprime l'objet.
Toujours arrondir l'heure au jour suivant à minuit UTC.
Un objet supprimé ne peut être restauré.
La configuration d'un cycle de vie peut être gérée en utilisant aws s3api (d'autres outils ou SDK fonctionnent aussi) :
put-bucket-lifecycle
get-bucket-lifecycle
delete-bucket-lifecycle
Nous utilisons les utilitaires aws s3 et aws s3api issues du client S3 AWSCLIv2 sur Linux.${S3_ENDPOINT}
&${S3_PROFILE}
sont des variables d'environnement
Créez un fichier et insérez votre configuration au format JSON :
Appliquez-le au Bucket : bucket-test
Les politiques de gestion des Buckets fournissent à des Object Users spécifiques, ou à tous les Object Users, des autorisations conditionnelles et granulaires pour des actions spécifiques.
Les conditions des politiques peuvent être utilisées pour attribuer des autorisations à une série d'objets qui correspondent à la condition souhaitée et peuvent être utilisées pour attribuer automatiquement des autorisations aux objets nouvellement téléchargés.
Cette section fournit des informations de base sur l'utilisation des politiques de gestion des Buckets.
Les politiques de gestion des Buckets peuvent être gérées en utilisant le client aws s3api (d'autres outils ou SDK fonctionnent aussi):
get-bucket-policy
put-bucket-policy
delete-bucket-policy
Nous utilisons les utilitaires aws s3 et aws s3api issues du client S3 AWSCLIv2 sur Linux. ${S3_ENDPOINT}
& ${S3_PROFILE}
sont des variables d'environnement.
Créez un fichier et insérez votre politique de gestion au format JSON :
L’élément Principal spécifie les Access Key des Object Users qui sont autorisés ou non, à effectuer les actions sur les différentes ressources spécifiées.
Vous pouvez spécifier un wildcard '*
' pour indiquer tous les Object Users.
Attention, utiliser le wildcard '*
' dans une politique de gestion de Buckets, signifie que tout le monde peut accéder aux ressources spécifiées et effectuer les actions spécifiées
Appliquez la politique des gestions sur le Bucket: bucket-test
Le service de Stockage d'Objet de cegedim.cloud est directement accessible depuis Internet.
Si vous accordez un accès public à votre Bucket ou à un sous-ensemble de votre Bucket, tout le monde peut obtenir vos objets.
Avec l'accès public, le contenu du Bucket peut être consulté directement à l'aide d'un navigateur web.
L'URL pour accéder à un Bucket public suit ce format : https://<objectstore_name>.storage-[eb4|et1].cegedim.cloud/<bucket_name>
Par exemple : https://cos-cegedimit-myit.storage-eb4.cegedim.cloud/mybucket
Le service de Stockage d'Objet de cegedim.cloud est directement accessible depuis Internet.
Si vous accordez un accès public à votre Bucket ou à un sous-ensemble de votre Bucket, tout le monde peut obtenir vos objets.
Avec la politique suivante, tous les objets du Bucket my-bucket
et sous le préfixe public/
sont accessibles publiquement, sans authentification :
L'élément "condition" est utilisé pour spécifier les conditions qui déterminent quand une règle s'applique.
Les tableaux suivants référencent les conditions qui sont supportées par le service de Stockage Objet de cegedim.cloud et qui peuvent être utilisées dans les expressions de condition.
Les Object users sont des utilisateurs pouvant effectuer des opérations sur le service de Stockage Objet de cegedim.cloud, en utilisant l'API S3.
Un Object user est représenté par :
une access key
une secret key
Lorsque vous créez un Object Store, un Object User est automatiquement créé, avec le label "Inital S3 user".
Dans la page détaillée de votre Object Store, cliquez sur le bouton "Add User".
Saisissez un "Label" pour identifier facilement ce nouvel Object User, puis cliquez sur le bouton "Submit" :
Une fois l'Object User créé, une fenêtre pop-up apparaît, affichant ses Access Key
et Secret Key
.
Vous pouvez fermer cette pop-up une fois que vous avez enregistré vos informations d'identification.
L'Object User nouvellement créé est affiché dans l'onglet User:
Si vous changez le secret d'un Object User, toutes les applications ou clients utilisant cette secret key, obtiendront une erreur de type 401 Unauthorized Error
.
Le changement d'une secret key peut prendre quelques minutes pour se propager sur l'ensemble des sites du service de Stockage Objet de cegedim.cloud.
Vous avez la possibilité de spécifier une "période", en secondes, pendant laquelle, l'ancienne et la nouvelle secret key sont valides et acceptées par le service de Stockage Objet de cegedim.cloud.
À la fin de cette période, l'ancienne clé secrète est invalidée.
Une fois l'action soumise, un popup apparait, affichant la nouvelle secret key.
Vous pouvez fermer cette pop-up une fois que vous avez enregistré vos informations d'identification.
Il n'est pas possible de restaurer un Object User supprimé.
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Les pods sont déployés en utilisant les Kubernetes.
Cluster | |
---|---|
Instance autonome | Haute disponibilité | |
---|---|---|
Hébergement | Version | OS | Edition |
---|---|---|---|
Disque | Label | Taille par défaut | Description |
---|---|---|---|
Ports | Description | Protocol |
---|---|---|
Fonctionnalités | Libre-service | A la demande | Commentaires |
---|---|---|---|
Mot de passe | Stocké par cegedim.cloud | Stocké par le client | Enforcé |
---|---|---|---|
Fonctionnalités | Libre-service | Sur requête | Commentaires |
---|---|---|---|
Mot de passe | Stocké par cegedim.cloud | Stocké par le client | Enforcé | Commentaires |
---|---|---|---|---|
Scénario | Paramètrage |
---|---|
Fonctionnalités | Libre service | Sur demande | Commentaires |
---|---|---|---|
Paramètre | Valeur personnalisée | Enforcé | Commentaires |
---|---|---|---|
Paramètre | Valeur personnalisée | Enforcé |
---|---|---|
Paramètre | Valeur personnalisée | Enforcé |
---|---|---|
Mot de passe | Stocké par cegedim.cloud | Stocké par le client | Enforcé | Algorithme de hash |
---|---|---|---|---|
Alertes | Description |
---|---|
Paramètre | Défaut | Description |
---|---|---|
Paramètre | Valeur | Défaut | Description |
---|---|---|---|
Cluster | |
---|---|
Instance autonome | Cluster | |
---|---|---|
Composant | Valeur |
---|---|
Composant | Valeur |
---|---|
Fonctionnalité | Libre service | Sur demande | Commentaires |
---|---|---|---|
Compte | Stocké par cegedim.cloud | Stocké par le client | Enforcé | Algorithme de Hash |
---|---|---|---|---|
Politiques | Défaut | Enforcé | Commentaires |
---|---|---|---|
Caractéristiques | Libre service | Sur demande | Commentaires |
---|---|---|---|
Seuil TPS | Mitigation |
---|---|
Seuil TPS | Mitigation |
---|---|
Type de Bot | Mitigation |
---|---|
Fonctionnalités | Libre Service | Sur Requête | Comments |
---|---|---|---|
Fonctionnalités | |
---|---|
Action | Libre service | Sur demande | Commentaires |
---|---|---|---|
Rôles | Permissions |
---|---|
Mot de passe | Stocké par Cegedim.cloud | Stocké par Customer | Obligatoire | Algorithme de hachage |
---|---|---|---|---|
Cluster |
---|
Pour plus d'informations, veuillez consulter la page .
Pour une documentation complète sur les politiques de gestion des Buckets, veuillez vous référer à .
Lorsque la géo-réplication est activée, les Objects sont disponibles depuis les 2 URL API du service de Stockage Objet. Voir .
Entrez un nom pour votre Object Store (voir ).
Vous avez la possibilité de régénérer une secret_key , voir
S3Browser est un logiciel gratuit pour Windows (uniquement). Il offre des fonctionnalités de base avec la version gratuite. Pour les fonctionnalités avancées, il faut acquérir la .
Java :
.NET :
Node.js:
Python :
Si vous utilisez un Object Store géo-répliqué, vos objets seront disponibles depuis des deux endpoints (voir: ) du service de de Stockage Objet de cegedim.cloud.
Vous pouvez utiliser n'importe quel client S3, comme , ou .
Vous pouvez vider un Bucket à l'aide de ce type client uniquement si le versionnage n'est pas activé sur le Bucket (voir ) .
Voir pour plus d'informations.
Si le versionnage est activé, vous pouvez également configurer la règle pour supprimer les version non courants de vos objets ()
Pour vider complètement un Bucket où le versionnage est activé, vous devez configurer une configuration de cycle de vie pour les objets courant () et non courant () du Bucket.
Vous pouvez ajouter une configuration de cycle de vie sur le Bucket en utilisant AWS CLI ou un client avec interface graphique comme .
Pour plus d'informations, voir
Cela signifie que, sans ADO, toutes opérations (lecture, création, mise à jour et suppression ainsi que lister des buckets), sur un site qui n'est pas propriétaire de l'objet ou du bucket, échoueront.
Les Object Users de type IAM ne peuvent pas être gérés au travers d'ITCare et doivent être créés manuellement par les équipes de cegedim.cloud.
Condition | Description |
---|
est un client Windows freeware pour .
Ci-dessous, un exemple simple utilisant [AWS SDK pour Python (Boto3)]
Vous pouvez utiliser une configuration de cycle de vie pour supprimer les versions de vos objets :
Région | Area | Zone de disponibilité A | Zone de disponibilité B | Zone de disponibilité C |
---|
Zone de disponibilité A | Zone de disponibilité B | Zone de disponibilité C |
---|
Fonctionnalités | Libre-service | Sur demande | Commentaires |
---|
Politiques | Défaut | Enforcé | Commentaires |
---|
Nom du serveur | Nom du service | Les conditions de succès |
---|
Un nom simple (voir )
Pour plus d'informations sur la création d'un Object Store, veuillez lire les .
Voir la page pour la liste des API S3 supportées, non supportées ainsi que les comportements spécifiques à la solution de stockage objet de cegedim.cloud.
Pour plus d'informations, reportez-vous à la page .
Pour plus d'informations sur les politiques de gestion des Buckets, reportez-vous à la page .
Pour plus d'informations sur l'URL pré-signée, reportez-vous à la page .
Pour plus d'informations sur les politiques de gestion des Buckets, reportez-vous à la page .
Pour plus d'informations sur la gestion des configurations de cycle de vie, reportez-vous à la page .
Pour plus d'informations sur Object Lock, reportez-vous à la page .
Méthodes | Notes |
---|
Fonctionnalité | Notes |
---|
Télécharger la dernière version de Vault CLI depuis sur votre poste de travail.
Utilisez ITCarepour Formuler une demande via le formulaire de demande de support "Toutes autres sollicitations relatives aux Solutions/Outils IT".
Nom | Description | Requis |
---|
La manière dont l'accès aux ressources est gérée lors de l'utilisation du protocole S3 est décrite dans et vous pouvez utiliser ces informations comme base pour comprendre et utiliser les politiques de gestion des Buckets fournit par le service de Stockage d'Objet de cegedim.cloud.
Pour plus d'informations, consulter .
Permissions | Opérations S3 |
---|
Permissions | Opérations S3 |
---|
Permissions | Opérations S3 |
---|
Condition | Description | Opérateurs applicables |
---|
Nom de la clé | Description | Autorisations applicables |
---|
Nom de la clé | Description | Autorisations applicables |
---|
Vous pouvez modifier le label d'un Object User en utilisant le bouton :
Vous pouvez verrouiller ou déverrouiller un Object User en utilisant le bouton :
Un Object User verrouillé est identifié par un cadenas fermé situé à gauche du label et ne peut effectuer aucune opération sur l'API S3.
Vous pouvez à tout moment modifier la secret key d'un Object User en cliquant sur le bouton .
Vous pouvez supprimer un Object User en cliquant sur le bouton .
Virtuel
SQL Server 2022
Windows Server 2022
Standard ou Entreprise
Virtuel
SQL Server 2019
Windows Server 2019
Standard ou Entreprise
Virtuel
SQL Server 2017
Windows Server 2019
Standard ou Entreprise
Virtuel
SQL Server 2016
Windows Server 2016
Standard ou Entreprise
D:\
MSSQL
30 Go
Racine de l'instance
E:\
MSSQL_USER_DATA
30 Go
Base de données utilisateurs
F:\
MSSQL_USER_LOG
10 Go
Log des bases de données utilisateurs
G:\
MSSQL_TEMPDB
10 Go
TempDB
1433
Écouteur de port statique du serveur
TCP
1434
SQL Server Browser
UDP
2382
Serveur d'écoute de SQL Server Analysis Services
UDP
2383
Serveur d'écoute de SQL Server Analysis Services
TCP
5022
SQL Server BDM/AG Endpoint
TCP
Libre-service
Le client peut effectuer l'action de manière autonome.
A la demande
Le client peut demander que l'équipe de support de cegedim.cloud effectue l'action.
Database Collation
Integration Services
Analysis Services
Reporting Services
Recherche en texte intégral
Export, Import SQL Server backup
Création de cluster Always On
Demander conseil à votre responsable de prestation de services
compte admin
AUTRE compte
compte cgdm_admin
compte monitoring
Libre-service
Le client peut effectuer des actions de manière autonome à l'aide d'ITCare.
Sur requête
Le client peut demander à l'équipe de support de cegedim.cloud de prendre les mesures nécessaires.
Accès SSH
L'accès SSH est désactivé et réservé aux administrateurs de cegedim.cloud
Changement de configuration
Sur requête via ticket
Compte admin
Autre compte
Compte kibana
Utilisé par le serveur de tableau de bord pour se connecter au cluster
Compte support
Utilisé par l'équipe de support de cegedim.cloud (il a un accès limité et ne peut pas lire les données d'index)
Compte centreon
Utilisé par le système de surveillance cegedim.cloud (il n'a accès qu'aux informations de surveillance)
Compte prometheus
Utilisé par le système de métrologie de cegedim.cloud (il n'a accès qu'aux informations de surveillance)
Si Persistance RDB activée
save 3600 1
save 300 100
save 60 10000
Si Persistance AOF activée
append fsync every sec
Libre service
Le client peut effectuer une action de manière autonome.
Sur demande
Le client peut demander à l'équipe de support de cegedim.cloud de prendre les mesures nécessaires.
Accès SSH
L'accès SSH est désactivé et réservé aux administrateurs de cegedim.cloud.
Modifier le fichier de configuration
Sur demande via un billet.
Accès à Redis/Sentinel
Le client peut se connecter avec un compte à Redis et Sentinel (mot de passe défini par le client dans l'assistant de provisionnement).
bind
@IP 127.0.0.1
Adresse d'écoute
timeout
300
Fermer la connexion après qu'un client soit inactif pendant N secondes (0 pour désactiver)
logfile
/var/log/redis/redis-server.log
Chemin du fichier journal
supervised
systemd
Interaction de supervision
appendonly
oui
dir
/var/lib/redis/persistance
appendfsync
everysec
save
3600 1
save
300 100
save
60 10000
rdb_compression
oui
rdbchecksum
oui
dir
/var/lib/redis/persistance
compte du client
SHA-256
TOUT autre compte
SHA-256
compte cgdm_admin
SHA-256
compte cgdm_monitor
SHA-256
DBS_REDIS_CLI_CLIENTS
Vérifier le nombre de clients connectés
DBS_REDIS_CLI_AOF_STATUS
Vérifier l'état de l'aof
DBS_REDIS_CLI_COMMANDS
Nombre de commandes traitées
DBS_REDIS_CLI_CONNECTIONS
Nombre de connexions
DBS_REDIS_CLI_CPU
Utilisation du CPU
DBS_REDIS_CLI_MEMORY
Utilisation de la mémoire
DBS_REDIS_CLI_REPL_REPLICAS_COUNT
Vérifier le nombre de répliques
DBS_REDIS_CLI_RDB_STATUS
Statut de la RDB
DBS_REDIS_PING
Vérifie la disponibilité du nœud
DBS_REDIS_SENTINEL_MASTER_UP
Vérifie l'état du maître à partir de Sentinel
DBS_REDIS_SENTINEL_SLAVES_COUNT
Vérifier le nombre de répliques à partir de Sentinel
DBS_REDIS_SENTINEL_SENTINELS_COUNT
Vérifier Sentinelscount
DBS_REDIS_SENTINEL_QUORUM
Vérifier l'état du quorum
TLS_REDIS_CERT_EXPIRATION
Vérifier l'expiration du certificat Redis
TLS_SENTINEL_CERT_EXPIRATION
Vérifier l'expiration du certificat Sentinel
168
Le nombre d'heures à conserver un fichier journal avant de le supprimer.
-1
La taille maximale du journal avant sa suppression : aucune limite.
1073741824 (1 gibyte)
La taille maximale d'un seul fichier journal.
300000 (5 minutes)
La fréquence en millisecondes à laquelle le nettoyeur de journaux vérifie si un journal peut être supprimé.
Faux
Vrai
Active la création automatique de topics sur le serveur.
3
1
Nombre par défaut de partitions de journal par sujet. Un plus grand nombre de partitions permet un plus grand parallélisme pour la consommation, mais entraînera également un plus grand nombre de fichiers dans les brokers.
Dynamique
1
Le facteur de réplication est égal au nombre de brokers participant au cluster. (3 à 5)
2
1
Le nombre minimum de répliquas qui doivent accuser réception d'une écriture pour que celle-ci soit considérée comme réussie pour un producteur qui définit les acks sur "all" (ou "-1").
Dynamique
1
Est égal au nombre de CPU de la machine virtuelle.
2
1
Nombre de threads de récupération utilisés pour répliquer les messages d'un broker source. En l'augmentant, on peut accroître le degré de parallélisme des E/S dans le broker suiveur.
Port d'écoute AMQP
5672 si TLS est désactivé
5671 si TLS est activé
Endpoint Prometheus
http://my-instance.hosting.cegedim.cloud:15692/metrics
URL d'administration
http://my-instance.hosting.cegedim.cloud:15672/
Endpoint API REST
http://my-instance.hosting.cegedim.cloud:15672/api
Port d'écoute AMQP
5672 si TLS est désactivé
5671 si TLS est activé
Endpoint Prometheus
http://nodex.hosting.cegedim.cloud:15692/metrics
URL d'administration
https://cluster-name.rmq.hosting.cegedim.cloud/
Endpoint API REST
https://cluster-name.rmq.hosting.cegedim.cloud/api
Libre service
Le client peut effectuer une action de manière autonome.
Sur demande
Le client peut demander que l'action soit effectuée auprès de l'équipe de support de cegedim.cloud.
Accès SSH
L'accès SSH est désactivé et réservé aux administrateurs de cegedim.cloud.
Gestion des paramètres
La modification de rabbitmq.conf et des autres paramètres internes est effectuée par cegedim.cloud sur demande.
Accès Admin RabbitMQ
Le client peut se connecter avec un compte administrateur à l'interface utilisateur de gestion RabbitMQ (mot de passe défini par le client dans l'assistant d'approvisionnement).
Certains objets sont nécessaires et réservés aux opérations de cegedim.cloud. Des mesures coercitives peuvent être appliquées.
Exporter, importer des définitions RabbitMQ
Disponible en libre-service en utilisant l'interface utilisateur de gestion ou l'API.
Gérer les plugins RabbitMQ
Les plugins RabbitMQ sont gérés par cegedim.cloud et peuvent être installés sur demande par notre équipe de support.
Compte admin
sha256
TOUT autre compte
sha256
Compte cgdm_admin
sha256
Compte monitoring
sha256
TTL
Les messages datant de plus de 28 jours expireront automatiquement
HA
ha-mode configuré à ALL
Libre service
Le client peut effectuer une action de manière autonome.
Sur demande
Le client peut demander à l'équipe de support de cegedim.cloud de prendre les mesures nécessaires.
Activer/Désactiver
Le client peut activer ou désactiver le Bot Defense.
Ajouter / Supprimer une adresse IP sur la whitelist
Le client peut ajouter ou supprimer une adresse IP dans la whitelist.
Choisir son type de profil
Le client opte pour un profil strict ou standard.
Choisir son mode
Le client peut activer son Bot Defense en mode transparent ou boquant.
Modifier la configuration
Sur demande via un ticket.
Seuil calculé automatiquement
La première mesure d'atténuation est un captcha. Si le captcha n'est pas résolu, toutes les tentatives seront bloquées.
200 TPS atteints
Blocage des demandes avec limitation du débit
Bot non fiable
Bloqué
Navigateur suspect
Bloqué
Bot malveillant
Bloqué
Protocole
https
URL
<votre>
Méthode HTTP
POST
Authentification
Aucun
Content-Type
application/json
Corps du message
{ "response": { "content": "Response of your customer", "answeredAt" : "2020-02-12T13:00:00.000+0000" }, "message": { } }
Libre service
Le client peut effectuer une action de manière autonome.
Sur Requête
Le client peut demander à l'équipe de support de cegedim.cloud de prendre les mesures nécessaires.
Accès SSH
L'accès SSH est désactivé et réservé aux administrateurs de cegedim.cloud.
Gérer les volumes
La gestion des volumes peut être effectuée en libre-service à partir d'ITCare.
Modifier le fichier de configuration
Sur demande via un ticket.
Libre-service
✅
Sélection des régions
✅
Dimensionnement
XS
Version Nextcloud supportée
27
Monitoring
✅
Monitoring 24/7
✅ Optionnel
Sauvegarde
✅
Réplications des données (DRP)
✅
Disponibilité
99.8%
Libre service
Le client peut effectuer une action de manière autonome
Sur demande
Le client peut demander que l'action soit effectuée par l'équipe de support de cegedim.cloud.
Utilisateurs
Utiliser le produit
Administrateurs
Utiliser le produit et gérer les utilisateurs
Super Admin
Toutes
| Permet l'application de la protection "Legal Hold" sur l'objet spécifié. |
| Active l'application de la protection "Retention Period" sur l'objet spécifié. |
| Permet l'application d'une date de conservation spécifique. |
| Permet l'exécution d'un objet par rapport aux jours de rétention restants. |
EB | EB-EMEA |
EB | EB-HDS |
ET | ET-EMEA |
ET | ET-HDS |
Nœud 1 |
Nœud 2 |
Nœud 3 |
Libre-service | Le client peut effectuer une action de manière autonome. |
Sur demande | Le client peut en faire la demande auprès de l'équipe support de cegedim.cloud. |
Accès SSH | L'accès SSH est désactivé et réservé aux administrateurs de cegedim.cloud. |
Accès à l'API | Les clients peuvent utiliser Vault via des appels API |
Accès HTTPS | Les clients peuvent utiliser Vault via HTTPS WebUI |
TTL | 30 minutes |
HA | ha-mode configuré à ALL |
Toutes les URL Vault | TLS_HTTPS_CONNECT | HTTP OK : Le statut de la ligne correspond à "200,301,302,303,401,403,429" |
Tous les serveurs Vault | APP_VAULT_HEALTH | HTTP OK : Le statut de la ligne correspond à "200,429" |
DELETE Bucket tagging |
DELETE Bucket website |
GET Bucket location |
GET Bucket logging |
GET Bucket notification |
GET Bucket tagging |
GET Bucket requestPayment | Le service de Stockage Objet cegedim.cloud utilise son propre modèle pour les paiements. Cette fonctionnalité n'est pas supportée. |
GET Bucket website |
PUT Bucket logging |
PUT Bucket notification |
PUT Bucket tagging |
PUT Bucket requestPayment | Le service de Stockage Objet cegedim.cloud utilise son propre modèle pour les paiements. Cette fonctionnalité n'est pas supportée. |
PUT Bucket website |
Object APIs |
GET Object torrent |
POST Object |
POST Object restore | Cette opération est liée à AWS Glacier. Cette fonctionnalité n'est pas supportée. |
|
| Oui, si vous spécifiez plus d'une condition de filtre (par exemple, un préfixe et une ou plusieurs tags). |
|
| Oui, si |
|
| Oui, si |
|
Note:
| Oui, si aucune autre action n'est présente dans la règle. |
|
| Oui |
|
| Non |
|
| Oui, si le parent |
|
| Oui |
|
| Oui. si |
|
| Oui |
|
| Oui, si aucune autre action est présente dans le conteneur Rule. |
|
Note: Prise en charge <Prefixe> avec et sans <Filtre>. PUT Bucket lifecycle avec un filtre:
| Non |
|
| Oui |
|
| Oui |
|
| Oui, si le parent |
|
|
|
|
| Objet Objet PUT Terminer un téléchargement "mulitpart" |
|
|
|
|
|
|
|
|
|
|
|
|
| Liste des ''parts" dans un téléchargement "mulitpart" |
| Terminer le téléchargement "mulitpart" |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Utilisé pour vérifier les conditions basées sur la date et l'heure | Opérateur de date |
| Utilisé pour vérifier les conditions basées sur la date et l'heure en utilisant le format EPOCH (voir Opérateurs de condition de date). | Opérateur de date |
| Utilisé pour vérifier le type de principal (utilisateur, compte, utilisateur fédéré, etc.) pour la requête en cours. | Opérateur de chaîne de caractères |
| Utilisé pour vérifier l'adresse IP source. | Opérateur de chaîne caractères |
| Utilisé pour vérifier "UserAgent" du demandeur. | Opérateur de chaîne caractères |
| Utilisé pour vérifier le nom d'utilisateur du demandeur. | Opérateur de chaîne caractères |
| Condition pour exiger des autorisations d'accès spécifiques lorsque l'utilisateur télécharge un objet. | s3:PutObject s3:PutObjectAcl s3:PutObjectVersionAcl |
(pour les permissions explicites), où la permission peut être : lecture, écriture, lecture-acp, écriture-acp, contrôle total | Le propriétaire du Bucket peut ajouter des conditions en utilisant ces clés pour exiger certaines permissions. | s3:PutObject s3:PutObjectAcl s3:PutObjectVersionAcl |
| Oblige l'utilisateur à spécifier cet en-tête dans la requête. | s3:PutObject s3:PutObjectAcl |
| Restreindre l'utilisateur à l'accès aux données uniquement pour une version spécifique de l'objet. | s3:PutObject s3:PutObjectAcl s3:DeleteObjectVersion |
| Définir une condition pour exiger des autorisations d'accès spécifiques lorsque l'utilisateur télécharge un objet. | s3:CreateBucket s3:PutBucketAcl |
(pour les permissions explicites), où la permission peut être : lecture, écriture, lecture-acp, écriture-acp, contrôle total | Le propriétaire du Bucket peut ajouter des conditions en utilisant ces clés pour exiger certaines permissions. | s3:CreateBucket s3:PutBucketAcl |
| Oblige l'utilisateur à spécifier cet en-tête dans la requête. | s3:PutObject s3:PutObjectAcl |
| Exiger que l'utilisateur spécifie le paramètre de délimitation dans la requête Get Bucket (List Objects). | s3:PutObject s3:PutObjectAcl s3:DeleteObjectVersion |
| Limitez le nombre de clés que Object Storage Service renvoie en réponse à la requête Get Bucket (List Objects) en demandant à l'utilisateur de spécifier le paramètre max-keys. | s3:ListBucket s3:ListBucketVersions |
Instances
3
5 (recommandé)
CPU (par instance)
2 - 16 vCPU
RAM (par instance)
4 - 384 Go
Version(s) supportée(s)
2.11.0
2.15.0
Surveillance
Surveillance 24x7
Sauvegarde
Réplication de données (PRA)
Disponibilité
99,9%
Déploiement multi-AZ
Libre-service
Instance
1
2
CPU (par instance)
2 - 16 vCPU
2 - 16 vCPU
RAM (par instance)
4 - 384 Go
4 - 384 Go
Versions supportées
10, 11, 12, 13, 14, 15, 16
12, 13, 14, 15, 16
Surveillance
Surveillance 24x7
Sauvegarde
Réplication de données (PRA)
Disponibilité
99,8%
99,9%
Déploiement multi-AZ
Libre-service
Brokers
3+
Contrôleurs
3
CPU (par broker)
2 - 16 vCPU
RAM (par broker)
4 - 384 Go
Version(s) supportée(s)
3.6.0
Protection contre la reprise après sinistre
Disponibilité
99.9%
Déploiement multi-AZ
Brokers
1
3 - 5
CPU (par broker)
2 - 16 vCPU
2 - 16 vCPU
RAM (par broker)
4 - 384 Go
4 - 384 Go
Version(s) supportée(s)
3.10, 3.11
3.10, 3.11
Protection contre la reprise après sinistre
Disponibilité
99,8%
99.9%
Déploiement multi-AZ
Modifier la configuration d'OverDrive
✅
Via les paramètres d'administration
Patchs de sécurité / Mise à jour des versions
✅
La mise à jour est effectuée par cegedim.cloud : soit sur demande, soit lors d'une mise à jour groupée.
Ajouter un produit SSO existant
✅
La mise à jour est effectuée par cegedim.cloud : soit sur demande, soit lors d'une mise à jour groupée.
Ajouter des utilisateurs / Redimensionner le stockage des utilisateurs
✅
Accessible via le compte administrateur, dans les paramètres "Utilisateurs".
Ajouter une nouvelle application
✅
Accessible via le compte administrateur, dans les paramètres "Applications".
(à venir) Élargir la taille d'OverDrive
✅
(à venir) Possible grâce au bouton de redimensionnement sur ITCare.
Compte admin_client
sha256
N'importe quel autre compte
sha256
Instance(s) | 2 |
Version(s) supportée(s) | 10.2 |
Protection contre la reprise après sinistre |
Disponibilité | 99.9% |
Déploiement Multi-AZ |
Service GET | Le service de stockage objet cegedim.cloud supporte les paramètres |
DELETE Bucket |
DELETE Bucket cors |
DELETE Bucket lifecycle
| Seules les actions d'expiration sont supportées. Les configurations liées à l'archivage (comme AWS Glacier) ne sont pas supportées. Les configurations de cycle de vue ne sont pas supportées les buckets où la fonctionnalité " |
DELETE Bucket policy |
GET Bucket (List Objects) | Pour les buckets où la fonctionnalité " |
GET Bucket cors |
GET Bucket acl |
GET Bucket lifecycle | Seule les actions d'expiration sont supportées. Les configurations liées à l'archivage (comme AWS Glacier) ne sont pas supportées. Les configurations de cycle de vue ne sont pas supportées les buckets où la fonctionnalité " |
GET Bucket policy |
GET Bucket Object versions |
GET Bucket versioning |
HEAD Bucket |
List Multipart Uploads |
PUT Bucket | Lorsqu'une requête de type PUT est effectuée sur un buckets existant, reportez-vous à la section "Comportements spécifiques" lorsque le buckets existe déjà. |
PUT Bucket cors |
PUT Bucket acl |
PUT Bucket lifecycle | Seule les actions d'expiration sont supportées. Les configurations liées à l'archivage (comme AWS Glacier) ne sont pas supportées. Les configurations de cycle de vue ne sont pas supportées les buckets où la fonctionnalité " |
PUT Bucket policy | Les politiques de gestion des Buckets ne peuvent pas être configurées pour des opérations qui ne sont pas prises en charge par le service de stockage objet cegedim.cloud. |
PUT Bucket versioning |
DELETE Object |
Delete Multiple Objects |
GET Object |
GET Object ACL |
HEAD Objec |
PUT Object | Supports chunked PUT |
PUT Object acl |
PUT Object - Copy |
OPTIONS object |
Initiate Multipart Upload |
Upload Part |
Upload Part - Copy |
Complete Multipart Upload | Le service de Stockage Objet cegedim.cloud renvoie un ETag de 00 pour cette requête. Cette réponse diffère de celle d'Amazon S3. |
Abort Multipart Upload |
List Parts |
ITCare est la plateforme de gestion Cloud de cegedim.cloud.
Elle intègre une interface d'administration web et une API qui offrent une vue à 360° de vos ressources Cloud hébergées et gérées par cegedim.cloud.
Conçue comme un service web unifié, elle régit les points clés suivants :
Gestion des ressources Cloud : déployer et administrer vos ressources
Supervision : surveiller la santé et la performance de vos applications, être notifié en cas d'incident
Support : contactez nos équipes de support pour toute question ou incident
Gouvernance : consultez les rapports de sécurité et d'obsolescence, gérez les créneaux de maintenance
Intégration : intégrez vos processus d'entreprise à votre cloud via l'API ITCare
Vous pouvez accéder à ITCare à partir de n'importe quelle page de ce site web en utilisant le lien ITCare dans l'en-tête.
La page Débuter avec ITCare explique en détail comment accéder à ITCare, avec des informations sur l'authentification et les autorisations.
Toutes les informations nécessaires à la découverte et à la bonne utilisation de l'API ITCare sont disponibles dans la page API ITCare.
Si vous êtes client, vous pouvez joindre notre Service Desk via cette ligne téléphonique directe pour toute demande de support : +33 (0)1 49 09 22 22
Pour toute demande d'information ou de contact, vous pouvez utiliser ce formulaire :
Comment cegedim.cloud supporte-t-il ses produits managés ?
Les offres managées de cegedim.cloud incluent du support. Ce support se découpe en 4 phases :
Phase standard : cegedim.cloud offre un support complet du produit.
Phase fin de vente : phase secondaire indiquant qu'une nouvelle version a été élue en phase de support Standard. Il est fortement conseillé d'effectuer une migration vers une version plus récente.
Phase support étendu : troisième phase qui débute à la date de fin de vie (EOL) annoncée par l'éditeur pour le produit. Cela signifie que plusieurs services ne sont plus garantis et passent en meilleurs efforts.
Phase fin de Support : phase terminale activée quand cegedim.cloud n'est plus en mesure de fournir du support. Des frais peuvent s'appliquer si le système est considéré comme un risque pour la sécurité (violation, compromission des données, nécessité d'isolation).
Voici un listing détaillé des fonctionnalités selon les phases de support :
Depuis de notre gestionnaire de plateforme cloud ITCare, vous pouvez créer un ticket de demande d'assistance.
Depuis la page d'accueil ou bien depuis la section Support dans le menu latéral gauche, cliquez sur le bouton Formuler une demande.
Recherchez d'abord le formulaire correspondant au produit pour lequel vous avez besoin d'aide en tapant le nom du produit dans la barre de recherche. Sélectionnez le formulaire et fournissez les informations requises.
Un ticket d'assistance sera créé lors de la soumission.
Veuillez prévoir jusqu'à 7 jours ouvrables pour le traitement de votre demande.
Les ressources gérées sont surveillées par cegedim.cloud si la surveillance a été activée.
Cependant, un formulaire d'incident est disponible dans notre gestionnaire de plateforme cloud ITCare si vous avez besoin de nous faire part d'un problème que nous aurions manqué.
Depuis la page d'accueil ou la section Support du menu latéral gauche, cliquez sur le bouton Déclarer un incident.
Pour mieux traiter votre incident, un niveau de gravité est requis :
Pas d'impact
Dégradation
Interruption de service
Recherchez le formulaire approprié en recherchant le nom du produit avec lequel vous avez un problème, puis fournissez les informations requises.
Un ticket d'incident sera créé et notre équipe de support vous contactera dès que possible.
Le partage des responsabilités
Pour avoir une compréhension commune des responsabilités et des devoirs entre cegedim.cloud et le client, nous utilisons une matrice RACI applicable à nos produits managés.
Vous trouverez ci-dessous les matrices RACI décrivant les actions liées à la gestion des produits managés du catalogue cegedim.cloud.
Il existe de légères différences en fonction du plan souscrit par le client :
Certains de nos produits disposent d'actions spécifiques qui peuvent être réalisées au autonomie et en libre-service depuis notre outils de gestion de cloud ITCare. Les matrices ci-dessous sont donc complémentaires à la matrice RACI générique.
*Chaque exécution comprend : la vérification des prérequis, l'exécution du script, le suivi de l'exécution par un expert en sécurité informatique en contact direct avec le client.
L'instance virtuelle est un produit entièrement géré proposé par cegedim.cloud, conçu pour simplifier et améliorer votre expérience d'hébergement. Avec les instances virtuelles, vous n'avez plus à vous soucier de la complexité de la gestion de votre infrastructure d'hébergement - notre équipe d'experts s'occupe de tout.
Notre produit prend en charge une variété de systèmes d'exploitation tels que Linux, Windows et AIX, ce qui vous donne la liberté de choisir l'environnement qui répond le mieux à vos besoins. Il peut être déployé sans effort grâce à notre outil de gestion de plateforme cloud convivial appelé ITCare.
Cet outil vous donne la possibilité de démarrer l'instance souhaitée, de sélectionner le système d'exploitation de votre choix et de personnaliser les ressources pour répondre à vos besoins spécifiques en quelques clics, garantissant ainsi que vos instances sont adaptées aux exigences de votre entreprise.
Nous comprenons l'importance des performances et de la fiabilité, c'est pourquoi les instances virtuelles sont équipées de systèmes de surveillance, de services de sauvegarde et de réplication des données. Cela garantit une visibilité en temps réel de la santé de vos instances et une sécurité accrue.
En résumé, que vous ayez besoin d'un système d'exploitation Linux, Windows ou AIX, et quelles que soient vos exigences en matière de ressources, les instances virtuelles vous offrent la flexibilité et l'évolutivité dont vous avez besoin.
La configuration des ressources peut varier en fonction du système d'exploitation cible.
La facturation est mensuelle et basée sur le nombre d'instances et les coûts supplémentaires pour le stockage, la sauvegarde, la surveillance 24x7.
L'estimation du coût d'une instance virtuelle est disponible auprès de votre Service Delivery Manager.
Matomo est disponible en libre-service dans ITCare pour tous les utilisateurs autorisés.
En fonction du dimensionnement choisi (voir les dimensionnements ci-dessous), plusieurs composants seront déployés avec un strict minimum de :
1 serveur web frontal
1 serveur de base de données
1 équilibreur de charge avec une adresse IP publique (certificat inclus)
Les tailles supérieures (pour suivre plus de pages vues par mois) peuvent inclure plus de serveurs web pour l'équilibrage de charge. Pour les tailles supérieures à XL, un ticket de demande sera nécessaire.
Une fois provisionnée, votre instance Matomo est accessible au public via l'URL fournie dans ITCare.
L'installation de plugins et les mises à jour de Matomo peuvent être effectuées par le client en toute autonomie.
Matomo est disponible dans les régions suivantes :
EMEA - France - Boulogne-Billancourt
EMEA - France - Toulouse
Les tailles suivantes sont disponibles :
Le redimensionnement est disponible dans le self-service ITCare mais ne permet que le redimensionnement vers le haut.
Le redimensionnement vers le bas n'est pas possible !
La version de Matomo déployée dépend de la dernière mise à jour de nos repository lors de la dernière patch party.
La dernière version sera souvent disponible mais il peut arriver que la version déployée ne soit pas la dernière.
Dans ce cas, la mise à jour peut être déclenchée par le client en autonomie directement depuis l'interface web UI ou sur demande en créant un ticket de demande dans ITCare.
Cette section énumère les fonctionnalités / capacités disponibles pour le client, ainsi que la manière de les demander / de les exécuter :
Le client dispose d'un compte local super utilisateur.
OpenOIDC est configuré pour ajouter et autoriser facilement d'autres utilisateurs à accéder à Matomo.
L'accès à votre instance Matomo se fait de manière sécurisée via HTTPS.
Toutes les données sont stockées dans les centres de données de cegedim.cloud sur des baies de stockage cryptées.
Le mot de passe du compte super utilisateur fourni au client n'est pas stocké ni sauvegardé par cegedim.cloud.
Matomo et les composants associés sont surveillés par notre équipe de support. Un état de santé global est affiché dans ITCare pour votre confort.
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Vous pouvez retrouver la liste complète des opérations et des conditions supportées .
Description | Standard | Fin de vente | Support étendu | Fin de support |
---|---|---|---|---|
Plan | Description |
---|---|
Actions | Plan | cegedim.cloud | Client | Commentaires |
---|---|---|---|---|
Actions | Plan | cegedim.cloud | Client | Commentaires |
---|---|---|---|---|
Actions | Plan | cegedim.cloud | Client | Commentaires |
---|---|---|---|---|
Actions | Plan | cegedim.cloud | Client | Commentaires |
---|---|---|---|---|
Actions | Plan | cegedim.cloud | Client | Commentaires |
---|---|---|---|---|
Actions | Plan | cegedim.cloud | Client | Commentaires |
---|---|---|---|---|
Actions | Plan | cegedim.cloud | Client | Commentaires |
---|---|---|---|---|
Actions | Plan | cegedim.cloud | Client | Commentaires |
---|---|---|---|---|
Actions | Plan | cegedim.cloud | Client |
---|---|---|---|
Actions | Plan | cegedim.cloud | Client | Commentaires |
---|---|---|---|---|
Actions | Plan | cegedim.cloud | Client | Commentaires |
---|---|---|---|---|
Actions | Plan | cegedim.cloud | client | Commentaires |
---|---|---|---|---|
Instance |
---|
Pour plus d'information sur les instances virtuelles, vous pouvez consulter .
Tailles | Capacité estimée |
---|
Fonctionnalités | Libre-service | Sur requête | Commentaires |
---|
Supervision & Support d'incident technique
Requêtes standards
Temps de restauration garantie
Support 24x7 (option)
Sauvegarde, restauration et géo-réplication de données
Reprise d'activité en cas de désastre
Cybersécurité managée
Patches de sécurité et mise à jour mineures trimestrielles
Patches de sécurité critiques et mise à jour
Déploiement via ITCare
R
Responsable (acteur)
Assigné à la réalisation de la tâche ou du produit à livrer
A
Responsable (décisionnaire)
A le pouvoir de décision final et la responsabilité de l'achèvement (1 seul par tâche)
C
Consulté
Un conseiller, une partie prenante ou un expert en la matière qui est consulté avant une décision ou une action.
I
Informé
Doit être informé après une décision ou une action
Libre-service
Le client peut créer des ressources directement à travers ITCare, en utilisant le libre-service et le paiement à l'utilisation.
Sur requête
Les ressources sont provisionnées et livrées par cegedim.cloud à la demande du client.
Créer, Arrêter, Démarrer, Supprimer une instance ou un cluster
Libre-service
I
A / R
La décision de provisionner / arrêter / démarrer / supprimer est prise par le client.
Les actions sont effectuées :
par les clients par le biais d'ITCare s'ils ont souscrit au service "On Demand".
pour d'autres clients, par l'équipe des services professionnels de cegedim.cloud
Utiliser une instance ou un cluster
*
I
A / R
Le client est responsable de l'utilisation saine du produit.
Modifier les configurations
Sur requête
A / R
I
À la demande du client, certains paramètres de configuration peuvent être modifiés.
Surveillance standard
*
A / R
I
La surveillance est obligatoire et le client peut y accéder par le biais d'ITCare.
Métriques de performance
*
R
I
Les mesures de performance sont fournies par défaut et sont accessibles via ITCare.
Sauvegarde et restauration
*
R
A / I
La politique de sauvegarde est définie par le client et appliquée par cegedim.cloud, qui est chargé de s'assurer que les sauvegardes sont effectuées, et de restaurer les données sur demande.
Le client dispose d'informations sur la sauvegarde dans ITCare.
Protection contre la reprise après sinistre
*
R
A / I
Le Disaster Recovery est activé par le client et appliqué par cegedim.cloud, qui est chargé de s'assurer que les RTO et RPO associés sont atteints.
Le client dispose d'informations sur la protection contre les sinistres dans ITCare.
Correctifs de sécurité
*
R
A / I
cegedim.cloud applique les patchs de sécurité dans l'environnement d'exécution, trimestriellement, lors des "Patch parties", par défaut.
Le client peut choisir d'exclure une instance de l'application des correctifs via ITCare.
Mises à jour des versions
Sur requête ou Libre-service
R
A / I
La mise à jour peut parfois être effectuée par le client depuis ITCare en autonomie OU une demande peut être émise par le client, et si la transition est possible, cegedim.cloud effectuera la mise à jour ou l'upgrade de la version du produit.
Ajouter un nœud Kubernetes
Libre-service
I
A / R
Le Client peut ajouter des nœuds Kubernetes en libre-service via ITCare.
Redimensionner un nœud Kubernetes
Libre-service
I
A / R
Le Client peut redimensionner des nœuds Kubernetes en libre-service via ITCare.
Supprimer un nœud Kubernetes
Libre-service
I
A / R
Le Client peut supprimer des nœuds Kubernetes en libre-service via ITCare.
Activer le mode HA sur un cluster Kubernetes
Libre-service
I
A / R
Le Client peut activer la Haute disponibilité sur un cluster Kubernetes en libre-service via ITCare.
Ajouter une réplique MariaDB en lecture seule
Sur requête
A / R
I
Sur demande, une réplique MariaDB en lecture seule peut être configurée pour un nœud MariaDB autonome.
Gestion des Index
*
I
A / R
Le client est responsable de la création et de la gestion de ses index. cegedim.cloud n'y a pas accès à l'exception de l'index security_audit.
Restaurer PostgreSQL source vers destination
Libre-service
I
A / R
La décision de restaurer un PostgreSQL sur un autre déploiement PostgreSQL est prise par le client. Les actions sont effectuées:
par le biais d'ITCare s'ils ont souscrit au service "On Demand".
par l'équipe Professionnals Services de cegedim.cloud
Conversion en Haute disponibilité
Libre-service
I
A / R
La décision de restaurer un PostgreSQL sur un autre déploiement PostgreSQL est prise par le client. Les actions sont effectuées:
par le biais d'ITCare s'ils ont souscrit au service "On Demand".
par l'équipe Professionnals Services de cegedim.cloud
Gérer les objets Apache Kafka
*
I
A / R
Le client est responsable de la gestion des objets Apache Kafka (topics, partitions, etc.) et de leur bonne utilisation.
Gérer les objets RabbitMQ
*
I
A / R
Le client est responsable de la gestion des objets RabbitMQ (échanges, files d'attente, etc.) et de leur bonne utilisation.
Activer / Désactiver l'option Bot Defense sur un Load Balancer
Libre-service
I
A / R
La décision d'activer/désactiver l'option Bot Defense est prise par le client.
Ajouter ou supprimer une IP sur la whitelist
Libre-service
I
A / R
Le client peut ajouter ou supprimer une IP sur la whitelist.
Accès aux DDOS et aux requêtes bloquées de Bot Defense et Dos Protection
Libre-service
I
A / R
Signalez en temps réel les demandes bloquées (y compris l'adresse IP bloquée, la raison du blocage et l'ID du support).
Demande de détails sur la demande bloquée
Sur requête
A / R
I
À la demande du client, des informations supplémentaires peuvent être fournies pour une demande bloquée en fournissant l'identifiant du support.
Désigner un champion et définir les objectifs de masquage des données
*
I
A / R
Définir le contexte du masquage
*
I
A / R
Identifier les données sensibles à masquer (spécifications)
*
I
A / R
Identifier les contraintes d'intégrité des données dans la base de données
*
I
A / R
PDM : découverte et marquage des données sensibles
*
A / R
I / C
PDM : Définition des règles de masquage et de la politique de masquage
*
A / R
I / C
PDM : Facultatif : mise en œuvre de règles et de dictionnaires personnalisés
*
A / R
I / C
PDM : Création et exécution du plan de masquage*
10 traitements d'anonymisation inclus
Abonnement de 12 mois
Options : Paquet de 10 traitements d'anonymisation supplémentaires à utiliser pendant la période d'abonnement.
*
A / R
I / C
Vérification des résultats et validation de l'efficacité du masquage
*
I
A / R
Modifier les configurations
Sur requête
A / R
I
À la demande du client, certains paramètres de configuration peuvent être modifiés.
Gérer les chemins des secrets
*
A / R
Il s'agit de créer les chemins dans Vault où sont sauvegardés les secrets.
Gérer les secrets engines
*
A / R
Il consiste à créer, modifier et supprimer des secrets engines dans Vault
Gérer les méthodes d'authentification
*
A / R
Elle consiste à créer, modifier et supprimer des méthodes d'authentification dans Vault
Gérer les ACLs
*
A / R
Il s'agit de créer une liste de contrôle d'accès pour limiter les droits d'accès des utilisateurs.
Configurer les endpoints
*
A / R
Le endpoint peut être un serveur, un script, etc.
Gérer les volumes de stockage
Libre-service
I
A / R
Le client est responsable de la gestion (création, suppression, redimensionnement) des volumes de stockage pour son cluster.
Créer un Object Store
Libre-service
I
A / R
La décision de provisionner / supprimer / modifier un Object Store et les paramètres associés est prise par le client.
Les actions sont effectuées :
par les clients par le biais d'ITCare s'ils ont souscrit au plan "Libre service".
pour les autres clients, par les équipes Professional Services de cegedim.cloud
Gérer le quota des Object Store
Libre-service
I
A / R
Supprimer un Object Store
Libre-service
I
A / R
Créer un Object User
Libre-service
I
A / R
La décision de créer un utilisateur d'objet et les paramètres associés est prise par le client.
Les actions sont effectuées :
par les clients par le biais d'ITCare s'ils ont souscrit au plan "Libre service".
pour d'autres clients, par les équipes Professional Services de cegedim.cloud
Gérer les Object Users
Libre-service
I
A / R
La décision de modifier un utilisateur d'objet et les paramètres associés est prise par le client.
Ces actions comprennent le renouvellement de la clé secrète ou le verrouillage de l'utilisateur de l'objet.
Les actions sont effectuées :
par les clients par le biais d'ITCare s'ils ont souscrit au plan "Libre service".
pour les autres clients, par les équipes Professional Services de cegedim.cloud
Supprimer un Object User
Libre-service
I
A / R
La décision de supprimer un utilisateur d'objet et les paramètres associés est prise par le client.
Les actions sont effectuées :
par les clients par le biais d'ITCare s'ils ont souscrit au plan "Libre service".
pour les autres clients, par les équipes Professional Services de cegedim.cloud
Créer un Bucket
Libre-service
I
A / R
La création des buckets et des paramètres associés est faite par le client.
Les actions sont effectuées en utilisant l'API S3
Supprimer un Bucket
Libre-service
I
A / R
La suppression des buckets et des paramètres associés est effectuée par le client.
Les actions sont effectuées en utilisant l'API S3
Appliquer une politique de gestion des buckets
Libre-service
I
A / R
La gestion de la politique du panier est effectuée par le client.
Les actions sont effectuées en utilisant l'API S3
Appliquer une politique de gestion du cycle de vie
Libre-service
I
A / R
La gestion du cycle de vie de la configuration est assurée par le client.
Les actions sont effectuées en utilisant l'API S3
Gérer la configuration Object Lock
Libre-service
I
A / R
les configurations Object Lock, appliquées sur les buckets ou les objets, sont réalisés par le client
Les actions sont effectuées en utilisant l'API S3
Disponibilité et Supervision
*
R / A
I
cegedim.cloud s'assure que le service de stockage d'objets est disponible et fonctionnel à tout moment.
Réplication multi-régions
*
R / A
I
La réplication des données entre les régions est gérée par cegedim.cloud qui assure que les RTO et RPO associés sont atteints.
Le client dispose d'informations sur la protection contre les sinistres dans ITCare.
Correctifs de sécurité
*
R / A
I
cegedim.cloud est en charge d'appliquer les correctifs de sécurité.
Cette action est transparente pour les utilisateurs et n'entraîne pas d'interruption de service.
Mises à jour
*
R / A
I
cegedim.cloud est en charge d'appliquer les mises à jour.
Cette action est transparente pour les utilisateurs et n'entraîne pas d'interruption de service.
l'API S3 est susceptible d'être modifiée.
XS | Suivi de 100 000 pages vues par mois ou moins |
S | Suivi de 1 million de pages vues par mois ou moins |
M | Suivi de 10 millions de pages vues par mois ou moins |
L | Suivi de 100 millions de pages vues par mois ou moins |
XL | Suivi de plus de 100 millions de pages vues par mois |
Libre-service | Le client peut effectuer des actions de manière autonome à l'aide d'ITCare. |
Sur requête | Le client peut demander à l'équipe de support de cegedim.cloud de prendre les mesures nécessaires. |
Mise à jour de Matomo | La mise à jour peut être effectuée par le super utilisateur. |
Installer et activer des plugins | Les plugins peuvent être installés par le super utilisateur à partir de l'interface web. |
Gérer les privilèges | Le super utilisateur peut accorder des privilèges à n'importe quel utilisateur. |
Accès SSH | L'accès SSH est désactivé et réservé aux administrateurs de cegedim.cloud. |
Modifier des fichiers de configuration | Sur demande avec un ticket. |
Systèmes d'exploitation supportés |
|
CPU (par instance) | 2 - 16 |
RAM (par instance) | 4 - 384 Go |
Stockage (par instance) | 35 - 4096 Go |
Surveillance |
Surveillance 24x7 |
Sauvegarde |
Réplication de données (PRA) |
Disponibilité | 99,8% |
Choix de la région et de la zone de disponibilité |
Libre-service |
Redis qui signifie Remote Dictionary Server, est un magasin de données clé-valeur rapide, open source, en mémoire.
Redis est déployé sur site dans les centres de données cegedim.cloud.
cegedim.cloud garantit le même niveau de service que l'offre Compute : déploiement des instances, maintien en condition opérationnelle, flexibilité, sécurité et monitoring sont ainsi assurés par nos experts.
Deux topologies sont disponibles :
Instance autonome
Cluster Sentinel de 3 instances
La topologie cluster Sentinel est prête pour la production avec 3 instances réparties sur toutes les Zones de Disponibilité d'une Area cible.
Chaque instance exécute les processus Redis et Sentinel. Une instance est primaire et les deux autres sont des répliques.
Le dimensionnement peut être configuré en fonction de vos besoins.
L'estimation des coûts pour un PaaS Redis est disponible via votre Service Delivery Manager.
La facturation est basée sur le nombre de nœuds auquel s'ajoutent les frais supplémentaires de stockage, de sauvegarde, surveillance 24/7.
PostgreSQL est actuellement le principal SGBDR (système de gestion de base de données relationnelle) open source, avec une large gamme de fonctionnalités et une grande communauté qui le soutient.
cegedim.cloud fournit des instances de bases de données PostgreSQL entièrement gérées pour vous permettre de construire vos applications sans exploiter la disponibilité, la sécurité et la résilience des bases de données PostgreSQL.
Les versions de PostgreSQL actuellement supportées sont : 10, 11, 12, 13, 14, 15, 16.
cegedim.cloud prend en charge deux types de déploiements PostgreSQL :
Le mode Single Instance fournit une instance PostgreSQL standard.
Le mode Haute disponibilité fournit une instance PostgreSQL multi-instances, avec des capacités de résilience et d'évolutivité améliorées
PostgreSQL est disponible à la fois sur le centre de données de cegedim.cloud :
EB4 (Boulogne-Billancourt, France)
ET1 (Labège, France)
Dans certains cas, lorsqu'un deuxième nœud est déployé (haute disponibilité), un centre de données secondaire proche peut également être utilisé pour assurer une résilience maximale :
EB5 (Magny-les-Hameaux, France)
ET2 (Balma, France)
Dans le cas d'une topologie à haute disponibilité, le PaaS est construit de manière à être résilient au DC si possible.
Ci-dessous, un exemple de répartition des nœuds :
Cette section énumère les fonctionnalités disponibles pour le client, ainsi que la manière de les demander ou de les exécuter :
Il est possible d'ajouter des fonctionnalités à PostgreSQL à travers ce qu'on appelle des extensions. Ces extensions peuvent ajouter de nouveaux types, des fonctions supplémentaires aussi bien pour les administrateurs que pour des utilisateurs "classiques", voire même des applications complètes.
Une fois que le PaaS PostgreSQL 15 et supérieur a été provisionné, vous pouvez installer certaines de ces extensions à travers ITCare.
Ci-dessous la liste des extensions supportées par le PaaS PostgreSQL à partir de la version 15:
Attention l'installation de certaines extensions peut nécessiter un redémarrage de PostgreSQL et donc entrainer une indisponibilité de votre PaaS PostgreSQL.
Le client se voit attribuer un rôle dont il choisit le mot de passe.
Le mot de passe de cet utilisateur n'est pas stocké ni sauvegardé par cegedim.cloud. Veillez à l'enregistrer dans votre propre coffre-fort.
Le rôle fourni au client dispose des autorisations suivantes :
LOGIN
CREATEROLE
CREATEDB
Ainsi, le client peut créer un rôle d'application et des bases de données dédiées.
Le transport sécurisé est une option lors du provisionnement et n'est disponible qu'à partir de la version 13.
Si le transport sécurisé est sélectionné, TLS/SSL sera activé pour le protocole PostgreSQL et seule une connexion TLS des clients sera acceptée.
Toutes les données sont stockées dans les centres de données cegedim.cloud sur des baies de stockage cryptées.
Cette section énumère la gestion des mots de passe :
Si la sauvegarde est activée lors du provisionnement (activée par défaut pour un service de type Production), les politiques de sauvegarde suivantes s'appliquent :
Dans le cadre de notre offre de bases de données gérées, PostgreSQL fait l'objet d'une surveillance spécifique au-dessus du système sous-jacent afin de garantir la disponibilité et les performances du service.
Les indicateurs clés PostgreSQL suivants sont surveillés et suivis :
Connexions
Utilisation de la mémoire
Dépassement des IDs de transactions (TXID wraparround)
État de santé
Merci de préciser si celle-ci doit être réalisée en heures non ouvrées pour planification d'une RFC.
Il est recommandé de procéder à la mise à jour de vos environnements de non production d'abord afin de pouvoir estimer le temps d'interruption généré par l'opération ainsi que de recetter vos applications dans la nouvelle version du moteur.
La mise à jour d'un déploiement PostgreSQL (mono-instance ou haute disponibilité) se déroule en deux étapes complètement automatisées :
Mise à jour du système d'exploitation préalable
Plusieurs mises à jour selon le scénario : Debian 9 → Debian 10 → Debian 11 -> Debian 12
Mise à jour du moteur PostgreSQL dans la version cible
La durée d'une mise à jour est variable selon :
Les ressources cpu et ram configurées
La quantité de données dont les entêtes doivent être modifiés par le moteur PostgreSQL.
La quantité de données à réindexer suite au changement de librairie C, après une mise à jour de l'OS.
Le mode de sauvegarde :
Point-in-time Recovery (PITR) à partir de PostgreSQL 12 et supérieur.
Le mode de sauvegarde "dump" disparait donc au profit du "PITR" et ne reste utilisé que dans les versions de PostgreSQL inférieures à la version 12.
A titre indicatif, voici les durées pour chaque étape d'une mise à jour d'une base de données pgbench de 100 Go :
Mise à jour de Debian : 10 minutes en moyenne
Réindexation PostgreSQL : 5 minutes en moyenne
Mise à jour de PostgreSQL : 1 minute en moyenne
Checksum PostgreSQL : 3 minutes en moyenne
Vacuuming de PostgreSQL : 1 minute en moyenne
Sauvegarde complète de PostgreSQL (mode PITR) : 16 minutes en moyenne
En mode PostgreSQL HA, nous devons également mettre à jour le réplica et le synchroniser avec le leader :
Synchronisation PostgreSQL : 4 minutes en moyenne
Durée moyenne totale pour une base de données de 100GB : 40 minutes
Distribution Linux supportées par cegedim.cloud en fonction de la version de PostgreSQL :
La mise à jour du système d'exploitation, si elle a lieu, peut nécessiter une réindexation complète (aussi prise en charge par cegedim.cloud) du fait des évolutions de la librairie C lors de la mise à jour du système d'exploitation.
Selon la quantité de données, cette opération peut prendre un certains temps.
Ci-dessous les chemins de mises à jour supportés par cegedim.cloud :
* Une migration du système d'exploitation est requise.
** Une double migration du système d'exploitation est requise.
*** Une triple migration du système d'exploitation est requise.
Option
Option
Option
Option
Il fournit une réplication intégrée, différents niveaux de persistance sur le disque, et offre une haute disponibilité avec .
Il existe un .
Instance autonome | Cluster |
---|
Pour plus d'information, veuillez consulter la page .
Pour mettre à jour votre PaaS PostgreSQL, veuillez vous référer à cette page :
Fonctionnalité | Libre-service | Sur requête | Commentaires |
---|
Certaines de ces extensions sont développées au sein même du projet PostgreSQL et suivent donc les évolutions des différentes version de PostgreSQL. Vous pouvez en trouver la liste .
D'autres sont développées par des entreprises tierces et suivent leur propre rythme à l'instar de ou de pour ne citer que les plus connues.
Mot de passe | Stocké par cegedim.cloud | Stocké par le client | Enforcé | Algorithme de Hash |
---|
PostgreSQL version 11 et inférieure | PostgreSQL version 12 et supérieure |
---|
La mise à jour d'un PaaS PostgreSQL est de la responsabilité de cegedim.cloud et peut être demandée via un soumis depuis ITCare en précisant un créneau de disponibilité pour l'opération.
Selon la version source et cible de PostgreSQL, il peut donc être nécessaire de migrer d'abord le système d'exploitation dans une version supportée par cegedim.cloud (voir ).
Versions de PostgreSQL | Distribution Linux supportée |
---|
Version Source | PostgreSQL 11 | PostgreSQL 12 | PostgreSQL 13 | PostgreSQL 14 | PostgreSQL 15 | PostgreSQL 16 |
---|
Libre-service | Le client peut effectuer une action de manière autonome. |
Sur requête | Le client peut demander que l'action soit effectuée auprès de l'équipe de support de cegedim.cloud. |
Accès SSH | L'accès SSH est désactivé et réservé aux administrateurs de cegedim.cloud. |
Modifier le fichier de configuration | Sur demande via un ticket. Seulement possible si cela n'affecte pas la surveillance et la résilience. |
Installer une extension | Les extensions PostgreSQL autorisées sont installables en libre service par les utilisateurs depuis ITCare à partir de la version 15 et supérieure. Autrement, une demande via ticket requête est toujours requise. |
compte client dédié | SCRAM-SHA-256 |
TOUT autre compte | SCRAM-SHA-256 |
compte cegedim.cloud | SCRAM-SHA-256 |
compte de surveillance | SCRAM-SHA-256 |
Sauvegarde complète tous les jours conservée pendant 14 jours |
Point-in-Time recovery prise en charge pendant 14 jours. |
PostgreSQL 10 | Debian 9 |
PostgreSQL 11 | Debian 10 |
PostgreSQL 12 | Debian 10 |
PostgreSQL 13 | Debian 11 |
PostgreSQL 14 | Debian 11 |
PostgreSQL 15 | Debian 11 |
PostgreSQL 16 | Debian 12 |
Instance(s) | 1 | 3 |
CPU (par instance) | 2 - 16 vCPU | 2 - 16 vCPU |
RAM (par instance) | 4 - 384 Go | 4 - 384 Go |
Version(s) supportée(s) |
|
|
TLS/SSL |
Surveillance |
Surveillance 24x7 |
Sauvegarde |
Réplication de données (PRA) |
Disponibilité | 99,8% | 99,9% |
Déploiement multi-AZ |
Libre-service |
PostgreSQL 10 | Debian 9 → Debian 10 | Debian 9 → Debian 10 | Debian 9 → Debian 11 | Debian 9 → Debian 11 |
PostgreSQL 11 |
| Debian 9 → Debian 10 | Debian 9 → Debian 11 | Debian 9 → Debian 11 |
PostgreSQL 12 |
|
| Debian 10 → Debian 11 | Debian 10 → Debian 11 |
PostgreSQL 13 |
|
|
|
PostgreSQL 14 |
PostgreSQL 15 |
Microsoft SQL Server est un système de gestion de base de données relationnelle développé par Microsoft.
Il est conçu pour stocker et récupérer des données telles que demandées par d’autres applications logicielles. Les fonctionnalités principales de SQL Server incluent :
Stockage et récupération de données : SQL Server offre une plateforme sécurisée et scalable pour stocker une grande quantité de données structurées et semi-structurées de manière efficace.
Interrogation et manipulation de données : Il propose des capacités avancées d’interrogation, telles que la possibilité d’écrire des requêtes complexes en utilisant le langage SQL, de joindre des tables, de créer des vues et de récupérer des données en fonction de critères spécifiques.
BI et analytique : SQL Server fournit des outils et des services pour l’analyse, le reporting et la visualisation des données, permettant aux utilisateurs de tirer des enseignements des données stockées afin de prendre des décisions basées sur les données.
Sécurité et intégrité des données : Il propose des fonctionnalités de sécurité solides, telles que l’authentification, le contrôle d’accès et le chiffrement, pour protéger les données sensibles contre tout accès ou modification non autorisé.
Haute disponibilité et évolutivité : SQL Server prend en charge des fonctionnalités comme le clustering, la bascule en cas de panne et la réplication pour assurer une disponibilité continue des données et pour répondre aux exigences croissantes en adaptant l’infrastructure de la base de données en termes de taille ou de performance.
SQL Server est déployé sur site dans les centres de données de cegedim.cloud .
Le même niveau de service que l'offre Compute est garanti : le déploiement des instances, la maintenance en condition opérationnelle, la flexibilité, la sécurité et la surveillance sont ainsi assurés par nos experts.
SQL Server 2016, 2017, 2019 et 2022 sont déployables en libre-service via notre plateforme de gestion de cloud ITCare.
Deux éditions sont supportées : Standard et Entreprise.
Deux topologies sont disponibles :
Instance autonome
Cluster Always On
La topologie de cluster Always On est prête pour la production mais n'est produite que sur demande.
Le dimensionnement peut être configuré selon vos besoins.
Pour plus d'information, veuillez consulter la page SQL Server - Architecture.
La facturation est basée sur le nombre de nœuds, plus des coûts supplémentaires pour le stockage, la sauvegarde, surveillance 24/7.
Les coûts sont disponibles auprès de votre Service Delivery Manager.
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
*
*
**
**
** Debian 9 → Debian 11
*** Debian 9 → Debian 12
*
**
**
** Debian 9 → Debian 11
*** Debian 9 → Debian 12
*
*
* Debian 10 → Debian 11
** Debian 10 → Debian 12
* Debian 11 → Debian 12
* Debian 11 → Debian 12
* Debian 11 → Debian 12
Instance autonome | Cluster Always On | |
---|---|---|
Instances
1
3
CPU (par instance)
2 - 16 vCPU
2 - 16 vCPU
RAM (par instance)
8 - 384 Go
8 - 384 Go
Version(s) supportée(s)
2016
2017
2019
2022
2016
2017
2019
2022
Sauvegarde
Surveillance
Surveillance 24x7
Réplication de données (PRA)
Disponibilité
99,8%
99,9%
Déploiement Multi-AZ
Libre-service
Option
Option
Option
Option
Option
Option
Option
Option
Advanced Vulnerability Assessment (AVA) est une combinaison d'un audit de vulnérabilité du système et d'un audit de vulnérabilité de l'application pour une vue à 360° de votre niveau de sécurité.
Le service AVA est géré par un ingénieur en cybersécurité qui effectue une série de tests de sécurité sur les cibles sélectionnées et vous fournit un rapport d'audit complet et détaillé. Pour chaque vulnérabilité identifiée, le rapport fournit : la criticité, la description, le vecteur d'attaque, l'impact potentiel et la solution.
Le service AVA est basé sur deux solutions d'audit de vulnérabilité complémentaires et leaders sur le marché :
Qualys Vulnerability Management pour les vulnérabilités des systèmes, des infrastructures et des logiciels intermédiaires (CVE)
Analyse des vulnérabilités des adresses IP publiques et privées de tous les composants de votre application.
Acunetix pour les vulnérabilités des applications web (OWASP Top 10)
Solution de test dynamique de la sécurité des applications (DAST)
Scan non authentifié : test de la résistance des formulaires d'authentification, des formulaires d'inscription, des réinitialisations de mot de passe, etc.
Analyse authentifiée : exploitation des fonctions internes de l'application, partitionnement des données, élévation des privilèges, etc.
Analyse de l'API : Types d'API pris en charge : SOAP/XML, REST, GraphQL
Identifiez et corrigez vos failles de sécurité avant que d'autres ne les exploitent !
La première étape consiste à évaluer le périmètre en demandant un test de sécurité. Ce périmètre doit inclure tous les serveurs qui interagissent avec le service d'application.
Dans cet exemple, il s'agira de :
Tous les serveurs exposés sur le frontend.
Tous les serveurs qui calculent le service dans le backend.
Tous les serveurs connexes, comme les serveurs BDD.
Le service est divisé en deux étapes :
Scanner de vulnérabilité du système et de l'infrastructure : Vous devez identifier tous les serveurs actifs du service.
Un scanner d'application web : l'URL de l'application + un profil de scan doit être livré.
Toutes ces informations doivent être remplies dans un document intitulé "Questionnaire de qualification technique" pour vous aider à identifier le champ d'application.
Trois rapports seront envoyés :
Un rapport de cegedim.cloud qui résume toutes les informations et fournit des recommandations sur le statut de sécurité du produit
Un rapport de Qualys Scanner avec toutes les vulnérabilités du système
Un rapport de Acunetix avec toutes les vulnérabilités des applications web
Vault est destiné à être le référentiel unique de vos secrets, qu'il s'agisse de mots de passe, de jetons, de certificats, de clés publiques/privées, etc.
C'est vers là que vos applications et services se tourneront pour consommer les secrets dont ils ont besoin. Dites adieu aux mots de passe en clair dans vos fichiers de configuration, vos scripts ou votre code source et sécurisez votre pipeline CI/CD !
Vault fournit un chiffrement fort des secrets, une gestion des authentifications et des autorisations. La ressource peut être un utilisateur humain ou une machine.
Gestion des secrets
Centralisation des secrets dans un espace sécurisé et hautement disponible
Réduire les risques et respecter les normes de sécurité et les meilleures pratiques : les mots de passe ne sont plus stockés ou affichés en clair.
Secrets dynamiques : créer, renouveler et révoquer automatiquement des secrets à la volée.
Le chiffrement en tant que service
Cryptez vos données à la volée sans vous soucier de la gestion des clés de cryptage
Mise à jour et rotation faciles des clés de chiffrement
" API First " : tout peut être contrôlé par API, en plus de l'interface Web
Gestion granulaire des profils et des droits d'accès
Traçabilité complète des actions de l'administration et de l'accès aux secrets
Vault a pour but de répondre aux besoins suivants :
Partage d'informations sensibles de manière sécurisée
Contrôle d'accès avec possibilité de révoquer l'accès
Granularité via des politiques permettant de ne partager que certaines données
Il est composé de quatre services principaux :
Le service Storage (Consul par exemple) est l'endroit où les données persistantes et cryptées de Vault seront stockées.
Le service Secret permet de stocker des secrets statiques et de générer des secrets dynamiques (pour AWS, Azure ou GCP par exemple).
Le service Audit vous permet d'enregistrer chaque demande afin de suivre toutes les interactions avec Vault.
Le service Auth backend gère plusieurs méthodes d'authentification permettant à Vault d'être adaptable à tout type d'utilisation. Par exemple, nous pouvons utiliser la méthode AppRole pour authentifier les applications mais aussi GitHub pour un groupe de développeurs.
Vault est déployé on-premise dans les datacenters de cegedim.cloud.
Le même niveau de service que pour l'offre Compute est garanti : déploiement des instances, maintien en condition opérationnelle, flexibilité, sécurité et monitoring sont ainsi assurés par nos experts.
La topologie disponible est la topologie de cluster prête avec 3 nœuds répartis sur toutes les zones de disponibilité d'une zone cible. La version actuelle supportée est la version 1.8.1.
cegedim.cloud déploie Vault avec auto-unseal pour réduire la complexité opérationnelle du maintien de la sécurité de la clé d'unseal. La clé racine cryptée est stockée dans un Transit Secrets Engine à l'intérieur d'un autre cluster Vault géré exclusivement par cegedim.cloud.
Vault est facturé mensuellement par cluster, quel que soit le nombre d'utilisateurs et le nombre de secrets stockés.
Pour connaître les coûts exacts d'un cluster Vault, veuillez contacter votre Service Delivery Manager.
Un plan de masquage des données approfondi et bien pensé garantit une sécurité maximale et conserve la plus grande valeur commerciale.
L'utilisation des directives de meilleures pratiques suivantes garantira que le masquage des données aboutira à des données sensibles sécurisées.
Le tableau des responsabilités#data-masking détaille les étapes qui sont de la responsabilité du client et celles qui sont de celle de cegedim.cloud.
Créez un catalogue de chaque source de données. Documentez les types d'informations suivants :
Accès à partir de : onshore, offshore, ou les deux.
Utilisation : développement, AQ, tests, formation ou autres types d'utilisation.
Type de base de données : Oracle, MS SQL Server, IMS, DB2 for z ou autres bases de données.
Mouvement des données : liste des flux de données dans l'environnement.
Fréquence d'actualisation : annuelle, trimestrielle, ad hoc, ou autres intervalles.
Propriétaires : propriétaires de la base de données et de l'application.
Niveau de risque : élevé, moyen ou faible.
Il est également important de définir quelles réglementations s'appliquent à l'organisation cliente et de déterminer le type de données sensibles ou confidentielles pour l'entreprise.
Recherchez quelles réglementations s'appliquent au projet de masquage (ex : GDPR, HDS, etc.) et assurez-vous que les obligations connexes ont été exécutées (ex : informer la personne concernée, ajouter le processus au registre des activités de traitement, réaliser une analyse d'impact sur la protection des données (DPIA) si nécessaire, etc.)
Désignez une personne ayant une bonne connaissance des problèmes de confidentialité de la base de données du projet. Cette personne doit avoir une bonne connaissance de la base de données à masquer, de ses dépendances et des contraintes d'intégrité qu'elle contient.
Il peut s'agir par exemple du responsable du projet, ou de l'administrateur de la base de données, à condition qu'il dispose d'informations suffisantes sur le contexte de la confidentialité.
Cette personne sera le point de contact privilégié pour compléter les informations concernant l'expression des besoins et le fichier contenant les informations sur le projet.
Définir une liste de domaines de données sensibles ou confidentielles, comme le nom, le prénom, la carte de crédit, etc. Décrire les caractéristiques de chaque domaine de données, notamment le type de données probable, la sensibilité des données, les descriptions et les modèles de données et de métadonnées. Cette étape garantit la collaboration entre les entreprises, la sécurité, la gouvernance des données et l'informatique.
Identifier les contraintes d'identité dans la base de données : les contraintes telles que les clés étrangères doivent être identifiées pour que le travail de masquage puisse être effectué.
Certaines informations sont nécessaires avant d'effectuer les travaux de masquage.
Type de masquage : In-Place ou In-Stream
In-Place : une seule base de données. Le masquage est effectué sur la base de données.
In-Stream : Il s'agit du type de masquage le plus couramment utilisé. Il implique deux bases de données : une "source" contenant les données que le client veut masquer, et une base de données vide de destination. Le masquage est effectué "à la volée" pendant la copie des données de la base de données source vers la base de données de destination. La base de données de destination doit être vide.
Complexité : Simple, Moyen ou Complexe. Ces catégories représentent la difficulté globale de mise en œuvre du projet de masquage. Elle dépend directement de la complexité de la base de données. Il tient également compte du fait que les spécifications de masquage nécessitent des paramètres personnalisés (règles ou dictionnaires de masquage).
Type de base de données : Oracle, MS SQL Server, IMS, DB2 for z ou autres bases de données.
Afin d'effectuer le masquage, nous devons comprendre comment le client souhaite que les données soient masquées.
Pour ce faire, le client doit définir pour chaque colonne de chaque table de la base de données quelle "règle de masquage" il souhaite voir appliquer. Une règle de masquage est appliquée à une ligne.
Par exemple, le client peut utiliser les techniques suivantes :
Réduire à néant les données hautement sensibles
Utiliser une substitution répétable non unique (basée sur des dictionnaires).
Utiliser le masquage aléatoire avec une plage (pour une valeur numérique)
Utiliser des techniques spéciales (masquage de carte de crédit, masquage d'adresse IP, etc.)
Des règles de masquage personnalisées peuvent être définies pour répondre aux besoins de projets complexes.
La conception de règles de masquage peut nécessiter des explications détaillées (voir la colonne "spécification avancée des règles de masquage"), plus de temps et plus d'échanges d'informations entre les deux parties.
Ces informations seront nécessaires pour la mise en œuvre des règles de masquage. Le client doit remplir le document joint "spécification" donné en annexe 1. Il doit contenir toutes les informations nécessaires à la mise en place des règles de masquage : tables, colonnes, description du masquage que le client souhaite effectuer, règle de masquage correspondante à appliquer, demandes spécifiques (ex : règle de masquage personnalisée, bijection du masquage).
Le livrable est la base de données contenant les données masquées. Comme cegedim.cloud n'a pas d'accès direct à la base de données, il appartient au client de mettre en place des règles de validation pour vérifier que toutes les données sensibles sont masquées dans l'environnement de non-production selon les spécifications souhaitées.
Complexité | Nombre de colonnes | Complexité du masquage |
---|---|---|
Simple
< 10
Seulement des règles de masquage préexistantes, peu de règles de masquage différentes
Moyen
> 10 et < 20
Complexe
> 20
règles de masquage spécifiques, nombreuses contraintes (clé étrangère, etc.), dictionnaires spécifiques
cegedim.cloud fournit un service de Stockage Objet, offrant des Object Stores dédiés, permettant à votre application de stocker des documents sans se soucier de la capacité, de la sécurité et de la disponibilité, avec les plus hauts standards déjà intégrés.
C'est un excellent moyen d'améliorer la disponibilité de vos applications et de décharger les documents, les médias, les données structurées ou non structurées que vous stockez habituellement dans des systèmes de fichiers ou des bases de données, et de réduire vos coûts de stockage.
Ce service de stockage objet est compatible avec les API AWS S3, facilitant l'intégration dans vos applications en utilisant les SDK fournis par AWS, en Java, Python, javascript, .NET, Go et beaucoup d'autres langages.
Les données sont transférées par HTTPS, de sorte que toutes les données transférées sont cryptées sur le réseau. Les données sont également cryptées côté serveur, sur les disques.
En outre, vous pouvez également utiliser un cryptage côté client avec votre propre clé en utilisant un client crypté S3 à partir du SDK AWS.
Le service de Stockage Objet de cegedim.cloud est un service entièrement géré, vous n'avez donc pas à vous soucier de la gestion d'un système de fichiers, de sa capacité ou de sa sécurité.
Vous pouvez ainsi vous concentrer sur votre application.
Les coûts sont bien moins élevés que ceux du stockage traditionnel par blocs. Vous pouvez réduire votre facture jusqu'à 90 % en transférant vos données vers ce service.
Le service de Stockage Objet de cegedim.cloud s'appuie sur des composants redondants, avec des solutions intégrées et transparentes de failover / failback.
Vous pouvez choisir de créer des Object Stores géo-répliqués, améliorant ainsi la capacité de vos applications à gérer les problèmes de DR.
Les données sont automatiquement répliquées dans deux régions différentes et vous pouvez accéder à vos données avec des opérations de lecture/écriture sur toutes les régions.
Le modèle de tarification est entièrement basé sur l'utilisation du stockage, vous payez ce que vous utilisez. Il n'y a pas de frais d'installation.
Il existe deux niveaux de service :
Object Storage standard: les données ne sont pas géo-répliquées
Object Storage répliqué: les données sont géo-répliquées dans deux régions.
Vous serez facturé à l'usage, en gibytes (2^30 octets = 1 GiB) par mois, sur la base du stockage moyen alloué au cours du mois.
Le prix mensuel est calculé sur une base annuelle (365,25 jours) et peut donc varier légèrement d'un mois à l'autre en fonction du nombre de jours du mois concerné.
Pour déterminer votre facture mensuelle, nous convertissons les "octets par heure" en "gibytes par mois".
Pour des informations détaillées sur la facturation, veuillez contacter cegedim.cloud.