Modèle de sécurité
Assurer la sécurité sans sacrifier les performances Les produits InterSystems offrent des capacités de sécurité flexibles et robustes tout en minimisant la charge sur les performances et le développement des applications.
Nos produits sont conçus pour prendre en charge le déploiement d'applications sécurisées de trois manières, à savoir :
- Sécuriser l'environnement du produit lui-même
- Faciliter l'intégration de fonctions de sécurité dans les applications par les développeurs
- Garantir que nos produits fonctionnent efficacement avec - et ne compromettent pas - la sécurité de l'environnement d'exploitation
Authentification
La sécurité de nos produits est basée sur l'authentification. L'authentification est la manière dont les utilisateurs (humains, dispositifs, autres applications) prouvent qu'ils sont bien ceux qu'ils prétendent être.
Nos produits prennent en charge un certain nombre de mécanismes d'authentification (LDAP, Kerberos, mots de passe directs, OpenAM et OpenID), et incluent la prise en charge de l'authentification à deux facteurs si nécessaire.
Autorisation
L'autorisation détermine les ressources qu'un utilisateur est autorisé à utiliser, visualiser ou modifier.
L'attribution et la gestion des privilèges (y compris les privilèges basés sur les rôles et les applications) s'effectuent facilement par le biais des API et des applications interactives.
Nous prenons également en charge la sécurité au niveau des lignes et des colonnes, ainsi que le RBAC.
Cryptage
Nous fournissons des mécanismes pour chiffrer les données au repos et en mouvement.
Le cryptage des données à l'état repos crypte l'ensemble de la base de données, y compris les index.
Nos produits détectent si le matériel sous-jacent prend en charge l'accélération des algorithmes de cryptage et les utilisent.
En outre, nous prenons en charge le cryptage des éléments de données pour chiffrer les informations très sensibles.
Ceux-ci peuvent même être ré-encryptés au moment de l'exécution.
Audit
Dans nos produits, tous les événements liés au système et aux applications sont enregistrés dans un journal annexe inviolable, compatible avec tout outil de requête ou de rapport utilisant SQL pour examiner et analyser les enregistrements d'audit.
Outre les événements d'audit intégrés, les clients peuvent également enregistrer des événements spécifiques à une application.
Fiabilité
Réduire les temps d'arrêt planifiés et non planifiés
Il est important de conserver vos données intactes et de faire fonctionner vos applications importantes 24 heures sur 24, 7 jours sur 7.
InterSystems IRIS offre plusieurs options de haute disponibilité (HA) et de reprise après sinistre (DR), notamment le clustering, la virtualisation HA et une technologie élégante et facile à mettre en œuvre pour la mise en miroir des bases de données.
Mise en miroir de bases de données
Un miroir de base de données est un regroupement logique de deux systèmes InterSystems IRIS.
Au démarrage, le miroir désigne automatiquement l'un de ces deux systèmes physiquement indépendants comme système primaire ; l'autre devient automatiquement le système de secours.
Les bases de données en miroir sont synchronisées entre le membre primaire et le membre de secours en temps réel par le biais d'un canal TCP.
Les architectures de bases de données en sharded nécessitent la mise en place d'un miroir de base de données pour chaque shard, éliminant ainsi tout point de défaillance unique.
Le déploiement dans un environnement en nuage nécessitera quelques étapes de configuration supplémentaires pour assurer la redirection automatique du trafic entrant vers le nœud primaire.
Avec la mise en miroir des bases de données, le temps de récupération des applications est généralement réduit à quelques secondes.
L'utilisation de la mise en miroir permet également des mises à niveau à temps d'arrêt minimal (voire nul).
Utilisation de la mise en miroir de bases de données pour la reprise après sinistre
Un membre miroir asynchrone peut être mis en place sur un site distant et mis à jour quasiment en temps réel.
Si le centre de données primaire tombe en panne, vos données ne seront pas perdues.
La reprise après sinistre lorsque les deux membres sont déployés dans un cloud public dépend des capacités du fournisseur, mais peut être réalisée en configurant des membres asynchrones dans différentes "régions", ou même entre des nuages de différents fournisseurs.
Mise en grappe et virtualisation
Les systèmes en grappe dépendent généralement d'un accès partagé aux disques, mais avec un seul système actif à la fois.
Si le système actif tombe en panne, InterSystems IRIS est automatiquement lancé sur un autre serveur qui reprend les responsabilités de traitement.
Les utilisateurs doivent se reconnecter au nouveau serveur, ce qui peut entraîner un retard notable. La virtualisation HA fonctionne à peu près de la même manière.