Introduction
Dans le contexte actuel où les menaces évoluent rapidement, les organisations qui déploient des applications critiques doivent mettre en œuvre des architectures de sécurité robustes qui protègent les données sensibles tout en maintenant une haute disponibilité et des performances élevées. Cela est particulièrement crucial pour les entreprises qui utilisent des systèmes de gestion de bases de données avancés tels qu'InterSystems IRIS, qui alimentent souvent des applications traitant des données hautement sensibles dans les domaines de la santé, de la finance ou des données personnelles.
Cet article décrivent en détail une architecture de sécurité complète à plusieurs niveaux pour le déploiement de clusters InterSystems IRIS sur AWS à l'aide de Kubernetes (EKS) et InterSystems IAM. En appliquant les principes de défense en profondeur, cette architecture fournit une protection à tous les niveaux, du périmètre du réseau au niveau de l'application et du stockage des données.
Pourquoi une approche à plusieurs niveaux est-elle importante
Les stratégies de sécurité à un seul niveau sont de plus en plus inadéquates face à des vecteurs d'attaque sophistiqués. Lorsqu'un contrôle de sécurité échoue, des niveaux supplémentaires doivent être mis en place pour éviter une compromission totale. Notre architecture implémente des contrôles de sécurité à cinq niveaux critiques:
- Sécurité périmétrique: Utilisation d'AWS WAF et CloudFront pour filtrer le trafic malveillant avant qu'il n'atteigne vos services
- Sécurité réseau: Exploitation des stratégies réseau AWS VPC, des groupes de sécurité et de Kubernetes
- Sécurité des API: Implémentation d'InterSystems IAM avec des plug-ins de sécurité avancés
- Sécurité des applications: Renforcement de la passerelle Web grâce à des restrictions URI rigoureuses
- Sécurité des bases de données: Configuration du cluster IRIS avec authentification et chiffrement robustes
À la fin de cet article, vous comprendrez comment mettre en œuvre chaque couche de sécurité et comment elles fonctionnent conjointement pour créer une stratégie de défense en profondeur qui protège vos déploiements IRIS contre un large éventail de menaces tout en préservant les performances et l'évolutivité.
Aperçu de l'architecture
Notre architecture de sécurité repose sur le principe de la défense en profondeur, chaque niveau fournissant une protection complémentaire. Voici un aperçu général de la solution complète:
.jpeg)
Structure de déploiement du cluster IRIS
Notre cluster IRIS est déployé à l'aide de l'Opérateur Kubernetes d'InterSystems (IKO) selon une topologie soigneusement conçue:
- Niveau de données: Deux instances IRIS dans une configuration en miroir pour une haute disponibilité et une redondance des données
- Niveau d'application: Deux serveurs d'applications IRIS qui accèdent aux données via ECP (Enterprise Cache Protocol)
- Passerelle API: InterSystems IAM (basé sur Kong) pour la gestion et la sécurité des API
- Passerelle Web: Trois instances de passerelle Web (CSP+Nginx) pour traiter les requêtes Web
- Arbitre: Une instance d'arbitre pour le niveau de données en miroir
Cette architecture sépare les problèmes et fournit plusieurs niveaux de redondance:
- Le niveau de données gère les opérations de base de données avec mise en miroir synchrone
- Le niveau d'application se concentre sur le traitement de la logique métier
- Le niveau IAM gère la sécurité des API
- Le niveau de passerelle Web traite les requêtes HTTP/HTTPS
Chaque composant joue un rôle spécifique dans la pile de sécurité:
- AWS WAF (pare-feu d'application Web): filtre le trafic malveillant à l'aide d'ensembles de règles qui protègent contre les exploits Web courants, les injections SQL et les scripts intersites (XSS). Il met également en œuvre une liste blanche d'URI pour restreindre l'accès aux seuls chemins d'application légitimes.
- AWS CloudFront: Agit comme un réseau de diffusion de contenu (CDN) qui met en cache le contenu statique, réduisant ainsi la surface d'attaque en traitant les demandes à la périphérie. Il fournit également un niveau supplémentaire de protection contre les attaques DDoS.
- AWS ALB (Équilibreur de charge d'application): Configuré comme un contrôleur d'entrée Kubernetes, il effectue la terminaison TLS et achemine le trafic vers les services backend appropriés en fonction des chemins d'URL.
- InterSystems IAM: Basée sur Kong, cette passerelle API applique l'authentification, l'autorisation, la limitation du débit et la validation des requêtes avant que le trafic n'atteigne l'application.
- Passerelle Web: La passerelle Web InterSystems, avec sa configuration renforcée, restreint l'accès à des chemins URI spécifiques et fournit une validation supplémentaire.
- Cluster IRIS: La base de données IRIS déployée dans un cluster Kubernetes avec une configuration sécurisée, un chiffrement TLS et des contrôles d'accès basés sur les rôles.
Cette approche à plusieurs niveaux garantit que même si un contrôle de sécurité est contourné, les autres restent en place pour protéger vos applications et vos données.
Niveau 1: Sécurité périmétrique avec AWS WAF et CloudFront
La première ligne de défense de notre architecture se situe au périmètre du réseau, où nous mettons en œuvre AWS WAF et CloudFront pour filtrer le trafic malveillant avant qu'il n'atteigne nos services.
1.1 Mise en œuvre d'AWS WAF
Le pare-feu d'application Web AWS est configuré avec des ensembles de règles personnalisées afin de protéger contre les exploits Web courants et de restreindre l'accès aux chemins URI autorisés uniquement. Voici comment nous l'avons configuré:
# WAF Configuration in Ingress alb.ingress.kubernetes.io/wafv2-acl-arn: arn:aws:wafv2:region-1:ACCOUNT_ID:regional/webacl/app_uri_whitelisting/abcdef123456
Nos règles WAF sont les suivantes:
- Liste blanche des chemins URI: Autorisation du trafic uniquement vers les chemins d'application spécifiés, tels que
/app/, /csp/broker/, /api/, and /csp/appdata - Protection contre les injections SQL: Blocage des requêtes contenant des modèles d'injection SQL
- Protection XSS: Filtrage des requêtes contenant des charges utiles de type cross-site scripting
- Regles basées sur les taux: Blocage automatique des adresses IP qui dépassent les seuils de requêtes
- Règles de limitation géographique: Limitation de l'accès à certaines zones géographiques lorsque cela est nécessaire
En appliquant ces règles à la périphérie, nous empêchons une grande partie du trafic malveillant d'atteindre notre infrastructure d'applications.
1.2 Intégration CloudFront
AWS CloudFront fonctionne avec WAF pour fournir des avantages supplémentaires en matière de sécurité:
- Mise en cache intelligente: le contenu statique est mis en cache à des emplacements périphériques, ce qui réduit la charge sur les services backend et minimise la surface d'attaque
- Protection contre les attaques DDoS: L'infrastructure distribuée à l'échelle globale de CloudFront aide à absorber les attaques DDoS
- Application du protocole TLS: Toutes les connexions sont sécurisées à l'aide du protocole TLS 1.2+ et de suites de chiffrement modernes
- Identité d'accès à l'origine: Garantie que les compartiments S3 hébergeant du contenu statique sont uniquement accessibles via CloudFront
CloudFront est configuré pour transférer des en-têtes spécifiques vers les services backend, garantissant ainsi la préservation des contextes de sécurité tout au long du flux de requêtes:
Cette configuration permet aux services en aval d'identifier l'adresse IP client d'origine à des fins de limitation du débit et de journalisation, même lorsque les requêtes transitent par plusieurs niveaux.
Niveau 2: Sécurité réseau avec AWS VPC et groupes de sécurité
Le deuxième niveau de notre architecture de sécurité se concentre sur les contrôles au niveau du réseau mis en œuvre via AWS VPC, les groupes de sécurité et les stratégies réseau Kubernetes.
2.1 Conception VPC pour l'isolation
Notre déploiement IRIS s'exécute dans un VPC personnalisé avec les caractéristiques suivantes:
- Sous-réseaux privés: Tous les pods IRIS et IAM s'exécutent dans des sous-réseaux privés sans accès direct à l'Internet
- Passerelles NAT: Outbound internet access
- Plusieurs zones de disponibilité: Les ressources sont réparties sur trois zones de disponibilité pour une haute disponibilité
Cette conception garantit qu'aucun service backend n'est directement exposé à l'Internet, tout le trafic passant par des points d'entrée contrôlés.
2.2 Configuration des groupes de sécurité
Les groupes de sécurité agissent comme des pare-feu virtuels qui contrôlent le trafic entrant et sortant. Notre implémentation comprend plusieurs groupes de sécurité avec des règles rigoureusement définies:
# Groupes de sécurité référencés dans Ingress alb.ingress.kubernetes.io/security-groups: sg-000000000, sg-0100000000, sg-012000000, sg-0130000000 Ces groupes de sécurité mettent en œuvre:
- Règles d'entrée: N'autorisent le trafic que sur les ports requis (443 pour HTTPS)
- Restrictions IP source: Limitent l'accès à des blocs CIDR spécifiques pour les interfaces administratives
- Règles de sortie: Restriction des connexions sortantes aux destinations nécessaires
Ce niveau de contrôle très précis garantit que, même si un conteneur est compromis, sa capacité à communiquer avec d'autres ressources est limitée par les règles du groupe de sécurité.
2.3 Stratégies réseau Kubernetes
Au sein du cluster EKS, nous mettons en œuvre des stratégies réseau Kubernetes afin de contrôler la communication de pod à pod:
apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:
name:allow-iam-webgateway
namespace:app1spec:
podSelector:
matchLabels:
app.kubernetes.io/component:webgateway
policyTypes:
-Ingress
ingress:
-ports:
-protocol:TCP
port:443
Ces stratégies garantissent que:
- Les pods IRIS n'acceptent que les connexions provenant de sources autorisées (passerelle Web, IAM)
- Les pods IAM n'acceptent que les connexions provenant du contrôleur Ingress
- Les pods de passerelle Web n'acceptent que les connexions provenant d'IAM
Cette approche de sécurité réseau à plusieurs niveaux crée des périmètres d'isolation qui contiennent les violations de sécurité potentielles et limitent les mouvements latéraux au sein de l'environnement d'application.
Niveau 3: Sécurité des API avec IAM d'InterSystems
Au cœur de notre architecture de sécurité se trouve IAM d'InterSystems , une solution de gestion des API puissante basée sur Kong. Ce composant fournit des fonctionnalités de sécurité essentielles, notamment l'authentification, l'autorisation, la limitation du débit et la validation des requêtes.
3.1 Aperçu d'IAM d'InterSystems
IAM d'InterSystems sert de passerelle API pour toutes les requêtes adressées aux services IRIS, garantissant que seul le trafic autorisé et légitime atteint votre application. Dans notre implémentation, IAM est déployé en tant que StatefulSet au sein du même cluster Kubernetes que les instances IRIS, ce qui permet une intégration transparente tout en maintenant l'isolation des préoccupations.
La passerelle IAM est configurée avec une terminaison TLS/SSL et n'est exposée que par des points de terminaison sécurisés. Toutes les communications entre IAM et la passerelle Web IRIS sont cryptées, ce qui garantit la confidentialité des données en transit.
3.2 Configuration avancée de la limitation des taux
Afin de vous protéger contre les attaques par déni de service et l'utilisation abusive de l'API, nous avons mis en place une limitation avancée des taux via le rate-limiting-advanced plugind'IAM. Cette configuration utilise Redis comme magasin backend pour suivre les taux de requêtes sur les instances IAM distribuées.
.png)
.png)
.png)
{ "name": "rate-limiting-advanced", "config": { "identifier": "ip", "strategy": "redis", "window_type": "sliding", "limit": [2000, 3000], "window_size": [60, 60], "redis": { "host": "my-release-redis-master.default.svc.cluster.local", "port": 6379, "timeout": 2000, "keepalive_pool_size": 30 }, "error_message": "API rate limit exceeded" } }
Cette configuration fournit deux niveaux de limitation des taux:
- Niveau 1: 2,000 requêtes par minute avec une fenêtre glissante
- Niveau 2: 3,000 requêtes par minute avec une fenêtre glissante
L'approche par fenêtre glissante fournit une limitation des taux plus précise que les fenêtres fixes, empêchant ainsi les pics de trafic aux périmètres des fenêtres. Lorsqu'un client dépasse ces limites, il reçoit un code d'état 429 accompagné d'un message d'erreur personnalisé.
3.3 Gestion sécurisée des sessions
Pour les applications nécessitant des sessions utilisateur, nous avons configuré le plugin de session IAM avec des paramètres sécurisés afin d'empêcher le détournement de session et de maintenir un cycle de vie approprié à la session:
{ "name": "session", "config": { "secret": "REDACTED", "cookie_secure": true, "cookie_same_site": "Strict", "cookie_http_only": true, "idling_timeout": 900, "absolute_timeout": 86400, "rolling_timeout": 14400 } }
Les principales fonctionnalités de sécurité mises en œuvre sont les suivantes:
- Uniquement des cookies HTTP: Cela empêche JavaScript d'accéder aux cookies de session, ce qui atténue les attaques XSS
- Indicateur de sécurité: Assure que les cookies ne sont envoyés que via des connexions HTTPS
- Restriction au même site: empêche les attaques CSRF en limitant l'utilisation des cookies aux requêtes provenant du même site
- Plusieurs mécanismes de timeout:
- Timeout d'inactivité (15 minutes): Met fin aux sessions après une période d'inactivité
- Timeout glissant (4 heurs): Nécessite une réauthentification périodique
- Timeout absolu (24 heurs): Durée maximale de la session, quelle que soit l'activité
3.4 Validation des requêtes pour la sécurisation des entrées
Afin de nous protéger contre les attaques par injection et les requêtes malformées, nous avons mis en place une validation de requêtes stricte à l'aide du plugin de validation des requêtes IAM. Cela est particulièrement important pour sécuriser le broker CSP, qui est un composant essentiel chargé de gérer la communication client-serveur dans les applications InterSystems.
.png)
{ "name": "request-validator", "config": { "version": "kong", "body_schema": [ { "RequestParam": { "type": "integer", "required": true, "between": [1, 10] } }, { "EventType": { "type": "string", "required": true, "match": "^[a-zA-Z0-9$_]{100}$" } }, { "SessionID": { "type": "string", "required": true, "match": "^00b0[a-zA-Z0-9]{40}$" } } ], "verbose_response": true, "allowed_content_types": ["application/x-www-form-urlencoded"] } }
Cette configuration impose des règles de validation rigoureuses:
- Les champs de saisie doivent correspondre exactement aux types de données et aux contraintes
- Les entrées de chaîne doivent correspondre à des modèles d'expressions régulières spécifiques
- Les types de contenu autorisés sont les seuls acceptés
Le broker CSP est particulièrement sensible, car il sert de canal de communication entre les navigateurs clients et le serveur IRIS. En validant toutes les requêtes au niveau IAM avant qu'elles n'atteignent le broker, nous créons une barrière de sécurité supplémentaire qui protège contre les requêtes malformées ou malveillantes ciblant ce composant critique. Lorsqu'une requête échoue à la validation, l'IAM renvoie une réponse d'erreur détaillée qui aide à identifier le problème de validation sans révéler d'informations sensibles sur vos systèmes backend.
3.5 Configuration d'adresses IP fiables/p>
Pour renforcer encore davantage la sécurité, l'IAM est configuré pour reconnaître les proxys fiables et déterminer correctement les adresses IP des clients:
{ "trusted_ips": [ "10.0.0.0/24", "10.1.0.0/24", "10.0.3.0/24" ], "real_ip_header": "X-Forwarded-For", "real_ip_recursive": "on" }
Cette configuration garantit que:
- La limitation du taux identifie correctement les adresses IP des clients, même via des proxys
- Les règles de sécurité utilisant l'identification IP fonctionnent correctement
- Les journaux d'accès enregistrent les adresses IP réelles des clients plutôt que celles des proxys
En implémentant ces fonctionnalités de sécurité avancées dans InterSystems IAM, nous avons créé un niveau de sécurité API robuste qui complète les mesures de sécurité périmétrique et réseau tout en protégeant les niveaux application et base de données contre le trafic malveillant ou excessif.
Niveau 4 : Sécurité des applications avec renforcement de la passerelle Web
Le quatrième niveau de notre architecture de sécurité se concentre sur le renforcement de la passerelle Web InterSystems, qui sert d'interface entre la passerelle IAM API et la base de données IRIS.
4.1 Configuration de la passerelle Web dans Kubernetes
TLa passerelle Web est déployée dans le cadre de la ressource personnalisée IrisCluster, avec une configuration spécifique axée sur la sécurité:
webgateway:
image:containers.intersystems.com/intersystems/webgateway-nginx:2023.3
type:nginx
replicas:2
applicationPaths:
-/csp/app1
-/csp/app2
-/app3
-/csp/app4
-/app5
-/csp/bin
alternativeServers:LoadBalancing
loginSecret:
name:iris-webgateway-secret
Cette configuration limite la passerelle Web à la prise en charge de chemins d'accès spécifiques aux applications, ce qui réduit la surface d'attaque en empêchant l'accès aux points de terminaison non autorisés.
4.2 Renforcement de la sécurité de CSP.ini
La configuration CSP.ini de la passerelle Web est renforcée par plusieurs mesures de sécurité:
[SYSTEM]No_Activity_Timeout=480System_Manager=127.0.0.1Maximum_Logged_Request_Size=256KMAX_CONNECTIONS=4096Server_Response_Timeout=60Queued_Request_Timeout=60Default_Server=IRIS[APP_PATH:/app]Alternative_Servers=LoadBalancingAlternative_Server_0=1~~~~~~server-compute-0Response_Size_Notification=ChunkedTransferEncodingandContentLengthKeepAlive=NoActionGZIP_Compression=EnabledGZIP_Exclude_File_Types=jpeggificopnggzzipmp3mp4tiffGZIP_Minimum_File_Size=500
Les principales fonctionnalités de sécurité de cette configuration sont les suivantes:
- Gestionnaire de système désactivé: L'interface du gestionnaire de système est désactivée, sauf pour localhost
- Configuration manuelle uniquement: La configuration automatique est désactivée pour empêcher toute modification non autorisée
- Restrictions d'accès aux chemins: Chaque chemin d'application a des paramètres de sécurité spécifiques
- Mise en œuvre de l'authentification: AutheEnabled=64 impose l'authentification
- Timeout de session: Timeout de session de 15 minutes conformément aux paramètres IAM
- Les noms CSP verrouillés: Empêche les attaques transversales en verrouillant les noms CSP
4.3 Configuration avancée de la sécurité Nginx
Notre implémentation utilise une configuration Nginx fortement renforcée pour la passerelle Web, qui fournit plusieurs niveaux de défense:
# Définition d'une liste blanche à l'aide d'une carte
map $request_uri $whitelist_uri {
default 0;
"~^/app/.*$" 1;
"~^/app/.*\.(csp|css|ico|js|png|woff2|ttf|jpg|gif)$" 1;
"~^/csp/broker/cspxmlhttp.js$" 1;
"~^/csp/broker/cspbroker.js$" 1;
"~^/csp/app/.*$" 1;
"~^/csp/bin/Systems/Module.cxw.*$" 1;
}
# Blocage global d'URI spécifiques
map $request_uri $block_uri {
default 0;
"~*%25login" 1;
"~*%25CSP\.PasswordChange\.cls" 1;
"~*%25ZEN\.SVGComponent\.svgPage" 1;
}
# Pages d'erreur personnalisées
error_page 403 /403.html;
# Application de la liste blanche d'URI
if ($whitelist_uri = 0) {
return 403;
}
# Interdirction d'accès aux types de fichiers interdits
location ~* \.(ppt|pptx)$ {
deny all;
return 403;
}
# Interdiction d'accès aux URI bloqués
if ($block_uri) {
return 403;
}
# Journalisation complète for security analysis
log_format security '$real_client_ip - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$http_x_forwarded_for" "$request_body"';
Cette configuration met en œuvre plusieurs commandes de sécurité essentielles:
- Liste blanche d'URI: Seuls les chemins explicitement autorisés sont accessibles
- Blocage des chemins dangereux: Blocage automatique de l'accès aux points de terminaison dangereux
- Blocage des types de fichiers à risque: Cela empêche l'accès aux types de fichiers potentiellement dangereux
- Journalisation sécurisée: Journalisation détaillée de toutes les requêtes à des fins d'analyse
- Extraction de l'adresse IP client: Extraction correcte des adresses IP réelles des clients à partir des en-têtes X-Forwarded-For
- Pages d'erreur personnalisées: Réponses d'erreur standardisées qui ne divulguent pas d'informations sur le système
De plus, nous mettons en œuvre des en-têtes de sécurité renforcés et des limites de requêtes:
# Les en-têtes de sécurité
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# Limites de taille des tampons et des requêtes
client_max_body_size 50M;
client_body_buffer_size 128k;
client_header_buffer_size 1k;
large_client_header_buffers 4 4k;
# Sécurité SSL/TLS
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
Ces paramètres protègent contre les menaces suivantes:
- Script inter-sites (XSS)
- Attaques par confusion de types MIME
- Clickjacking
- Attaques par rétrogradation SSL
- Tentatives de débordement de mémoire tampon
- Attaques à charge utile importante
4.4 Configuration TLS
La passerelle Web est configurée pour utiliser des paramètres TLS modernes, garantissant ainsi une communication sécurisée:
tls:
webgateway: secret: secretName:iris-tls-secret
Notre implémentation TLS garantit:
- Seuls les protocoles TLS 1.2+ sont autorisés
- Des suites de chiffrement robustes avec confidentialité persistante sont renforcées
- Les certificats sont correctement validés
- La gestion des sessions est sécurisée
En mettant en œuvre ce dispositif complet de renforcement de la sécurité de la passerelle Web, nous créons un niveau de sécurité robuste qui protège la base de données IRIS contre les accès non autorisés et les vulnérabilités courantes des applications Web.
Niveau 5: Sécurité des bases de données dans les clusters IRIS
Le dernier niveau de notre architecture de sécurité vise à sécuriser la base de données IRIS elle-même, afin de garantir la protection des données même si tous les niveaux précédents sont compromis.
5.1 Configuration sécurisée d'IrisCluster avec l'Opérateur Kubernetes d'InterSystems (IKO)
Le cluster IRIS est déployé à l'aide de la définition de ressource personnalisée IrisCluster fournie par l'opérateur InterSystems Kubernetes (IKO), avec une configuration axée sur la sécurité:
apiVersion:intersystems.com/v1alpha1kind:IrisClustermetadata:
name:example-app
namespace:example-namespacespec:
tls:
common:
secret:
secretName:iris-tls-secret
mirror:
secret:
secretName:iris-tls-secret
ecp:
secret:
secretName:iris-tls-secret
topology:
data:
image:containers.intersystems.com/intersystems/iris:2023.3
preferredZones:
-region-1a
-region-1b
mirrored:true
podTemplate:
spec:
securityContext:
runAsUser:51773
runAsGroup:51773
fsGroup:51773
irisDatabases:
-name:appdata
mirrored:true
ecp:true
irisNamespaces:
-name:APP
routines:appdata
globals:appdata
compute:
image:containers.intersystems.com/intersystems/iris:2023.3
replicas:1
compatibilityVersion:"2023.3.0"
webgateway:
image:containers.intersystems.com/intersystems/webgateway-nginx:2023.3
replicas:1
type:nginx
applicationPaths:
-/csp/sys
-/csp/bin
-/api/app
-/app
iam:
image:containers.intersystems.com/intersystems/iam:3.4
arbiter:
image:containers.intersystems.com/intersystems/arbiter:2023.3
preferredZones:
-region-1c
Notre déploiement IKO comprend plusieurs fonctionnalités de sécurité essentielles:
- Cryptage TLS: Toutes les communications entre les instances IRIS sont cryptées à l'aide du protocole TLS
- Mise en miroir de la base de données: Haute disponibilité avec mise en miroir synchronisée garantissant l'intégrité des données
- Exécution non root: IRIS s'exécute en tant qu'utilisateur irisowner sans privilèges
- Sécurité ECP: Les connexions Enterprise Cache Protocol sont sécurisées avec TLS
- Répartition par zone: Les composants sont répartis entre plusieurs zones de disponibilité pour assurer la tolérance aux pannes
- Isolation des ressources: Séparation nette entre les données et les nœuds de calcul
- Espaces de noms IRIS: Espaces de noms correctement configurés et mappés à des bases de données sécurisées
- Nœud arbitre: Nœud arbitre dédié dans une zone de disponibilité distincte
5.2 Paramètres de sécurité de la base de données IRIS
Au sein de la base de données IRIS, les meilleures pratiques en matière de sécurité comprennent la mise en œuvre de plusieurs paramètres de sécurité clés:
- Authentification déléguée: Configuration IRIS pour utiliser des mécanismes d'authentification externes pour la gestion centralisée des identités
- Journalisation des audits: Activation d'un audit complet pour les événements liés à la sécurité, tels que les connexions, les modifications de configuration et l'augmentation des privilèges
- Sécurité du système: application des paramètres de sécurité au niveau du système conformément aux normes de l'industrie
Ces pratiques garantissent une gestion centralisée de l'authentification, la journalisation de toutes les activités liées à la sécurité à des fins d'analyse et la conformité du système aux normes de configuration sécurisées.
5.3 Sécurité basée sur les ressources IRIS
IRIS fournit un cadre de sécurité robuste basé sur les ressources et les rôles qui permet un contrôle d'accès très précis. Ce cadre peut être utilisé pour mettre en œuvre le principe du moindre privilège, en accordant aux utilisateurs et aux services uniquement les autorisations dont ils ont besoin pour exercer leurs fonctions.
Modèle de sécurité basé sur les ressources
Le modèle de sécurité basé sur les ressources d'IRIS comprend:
- Ressources: Objets sécurisés tels que les bases de données, les services, les applications et les opérations systèmes
- Autorisations: Différents niveaux d'accès aux ressources (lecture, écriture, utilisation)
- Rôles: Ensembles d'autorisations sur les ressources qui peuvent être attribués aux utilisateurs
- Utilisateurs: Comptes auxquels des rôles sont attribués et qui peuvent se connecter au système
Ce modèle permet aux administrateurs de sécurité de créer une structure de sécurité qui restreint l'accès en fonction des tâches et des besoins. Par exemple:
- Les administrateurs de bases de données peuvent avoir un accès complet aux ressources de la base de données, mais un accès limité aux ressources de l'application
- Les utilisateurs de l'application peuvent avoir accès uniquement à certaines fonctions spécifiques de l'application
- Les comptes de service pour les intégrations peuvent avoir des autorisations restreintes adaptées à leurs besoins spécifiques
Documentation InterSystems
La mise en œuvre de la sécurité basée sur les rôles dans IRIS est bien documentée dans la documentation officielle d'InterSystems:
En tirant parti du cadre de sécurité intégré d'IRIS, les organisations peuvent créer un modèle de sécurité respectant le principe du moindre privilège, ce qui réduit considérablement le risque d'accès non autorisé ou d'augmentation des privilèges.
5.4 Cryptage des données
Les fichiers de la base de données IRIS sont cryptés à l'aide du cryptage AWS EBS au repos avec des clés KMS gérées par l'utilisateur:
kind:StorageClassapiVersion:storage.k8s.io/v1metadata: name:iris-ssd-storageclassprovisioner:kubernetes.io/aws-ebsparameters: type:gp3 encrypted:"true"volumeBindingMode:WaitForFirstConsumerallowVolumeExpansion:true
Le cluster EKS est configuré pour utiliser des volumes EBS chiffrés pour tout le stockage persistant, garantissant ainsi que les données inactives sont protégées par un chiffrement AES-256.
5.5 Sauvegarde et reprise après incident
Pour protéger contre la perte de données et garantir la continuité des activités de nos clients, notre architecture met en œuvre les mesures suivantes:
- Mise en miroir des journaux: Les journaux IRIS sont stockés sur des volumes distincts et mis en miroir
- Sauvegardes automatisées: Sauvegardes régulières vers des buckets S3 cryptés
- Réplication AZ croisée: Les données critiques sont répliquées vers une zone de disponibilité (AZ) AWS secondaire
Cette approche garantit que même en cas de panne catastrophique ou d'incident de sécurité, les données peuvent être récupérées avec un minimum de pertes.
Guide de mise en œuvre
Pour mettre en œuvre cette architecture de sécurité à plusieurs niveaux pour vos propres déploiements IRIS sur AWS, suivez ces étapes générales:
Étape 1 : Configuration de l'infrastructure AWS
- Créez un VPC avec des sous-réseaux privés et publics dans plusieurs zones de disponibilité
- Configurez des passerelles NAT pour la connectivité sortante à partir des sous-réseaux privés
- Créez des groupes de sécurité avec des règles d'entrée et de sortie appropriées
- Déployez un cluster EKS dans des sous-réseaux privés
Étape 2: Configuration des services de sécurité AWS
- Créez une liste de contrôle d'accès Web AWS WAF avec les ensembles de règles appropriés
- Configurez la distribution CloudFront avec l'association WAF
- Configurez AWS ALB pour Kubernetes Ingress
Étape 3 : Déployez l'IAM d'InterSystems
- Créez les informations secrètes Kubernetes nécessaires pour les certificats et les informations d'identification
- Déployez l'IAM StatefulSet à l'aide de l'opérateur IrisCluster
- Configurez les plugins de sécurité IAM (limitation du taux, gestion des sessions, validation des requêtes)
Étape 4 : Déploiement et sécurisation du cluster IRIS
- Créez une ressource personnalisée IrisCluster avec des configurations de sécurité
- Configurez TLS pour toutes les communications
- Déployez la passerelle Web avec une configuration renforcée
- Configurez la mise en miroir de la base de données et la sécurité ECP
Étape 5 : Mise en œuvre de la surveillance et de la journalisation
- Configurez la journalisation centralisée avec ElasticSearch
- Configurez la surveillance de la sécurité avec Datadog
- Mettez en œuvre des alertes pour les événements de sécurité
- Activez la journalisation d'audit IRIS
Surveillance et réponse aux incidents
Une architecture de sécurité robuste doit inclure des capacités de surveillance continue et de réponse aux incidents. Notre mise en œuvre comprend:
6.1 Surveillance de la sécurité
L'architecture comprend une surveillance complète à l'aide de Datadog et ElasticSearch:
- Analyse des journaux en temps réel: Tous les composants envoient leurs journaux à un cluster ElasticSearch centralisé
- Tableaux de bord de sécurité: Les tableaux de bord Datadog visualisent les mesures de sécurité et les anomalies
- Alertes automatisées: Des alertes sont générées en cas d'activités suspectes ou de violations de la sécurité
6.2 Réponse aux incidents
Un processus défini de réponse aux incidents garantit une réaction rapide aux événements de sécurité:
- Détection: Détection automatisée des incidents de sécurité grâce à la surveillance
- Classification: Les incidents sont classés par gravité et par type
- Contention: procédures visant à contenir les incidents, y compris les réponses automatisées
- Éradication: Mesures visant à éliminer la menace et à rétablir la sécurité
- Récupération: Procédures de restauration du fonctionnement normal
- Leçons apprises: Analyse post-incident pour améliorer le niveau de sécurité
Considérations relatives aux performances
La mise en œuvre de plusieurs niveaux de sécurité peut avoir un impact sur les performances. Notre architecture répond à ce problème grâce aux éléments suivants:
7.1 Stratégies de mise en cache
- Mise en cache CloudFront: Le contenu statique est mis en cache à la périphérie
- Mise en cache de la passerelle API: IAM implémente la mise en cache des réponses pour les points de terminaison appropriés
- Mise en cache de la passerelle Web: Les pages CSP sont mises en cache lorsque cela est possible
7.2 Équilibrage de charge
- Déploiement multizone de disponibilité (AZ): Les services sont répartis entre plusieurs zones de disponibilité
- Mise à l'échelle horizontale: Les composants peuvent être mis à l'échelle horizontalement en fonction de la charge
- Paramètres d'affinité: L'anti-affinité des pods garantit une distribution adéquate
7.3 Mesures de performance
Au cours de la mise en œuvre, nous avons observé les impacts suivants sur les performances:
- Latence: La latence moyenne des requêtes n'a augmenté que de 20 à 30 ms malgré toutes les niveaux de sécurité
- Débit: Le système peut traiter plus de 2 000 demandes par seconde avec toutes les mesures de sécurité
- Utilisation des ressources: Les composants de sécurité supplémentaires ont augmenté l'utilisation du processeur d'environ 15%
Ces mesures démontrent qu'une architecture de sécurité robuste peut être mise en œuvre sans dégradation significative des performances.
Conclusion
L'architecture de sécurité à plusieurs niveaux décrite dans cet article fournit une protection complète pour les déploiements InterSystems IRIS sur AWS. En mettant en œuvre des contrôles de sécurité à chaque niveau, du périmètre du réseau à la base de données, nous créons une stratégie de défense en profondeur qui réduit considérablement le risque d'attaques réussies.
Les principaux avantages de cette approche sont les suivants:
- Protection complète: Plusieurs niveaux fournissent une protection contre un large éventail de menaces
- Défense en profondeur: Si une mesure de sécurité échoue, les autres restent en place
- Évolutivité: l'architecture est scalable horizontalement pour gérer une charge accrue
- Simplicité de gestion: L'approche "infrastructure en tant que code" rend les contrôles de sécurité reproductibles et versionnables
- Conformité: L'architecture aide à respecter les exigences réglementaires en matière de protection des données
En tirant parti des services de sécurité AWS, d'IAM d'InterSystems et des configurations IRIS sécurisées, les organisations peuvent créer des applications sécurisées et hautement performantes tout en protégeant les données sensibles contre les menaces émergentes.
Références
- Documentation InterSystems: Guide de sécurité IRIS
- Meilleures pratiques en matière de sécurité AWS: Pilier de la sécurité AWS
- Sécurité Kubernetes: Guide des meilleures pratiques EKS
- Sécurité API OWASP: Les 10 principaux risques liés à la sécurité API
- Registre de conteneurs InterSystems: containers.intersystems.com
.png)