Architecture de sécurité à plusieurs niveaux pour les déploiements IRIS sur

Article

Guillaume Rongier · 4 hr il y a 27m de lecture

#API #AWS #Cloud #Contrôle d'accès #CSP #InterSystems API Manager (IAM) #Kubernetes #Sécurité #Web Gateway #InterSystems IRIS

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:

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:

X-Forwarded-For
X-Real-IP

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/v1
kind: NetworkPolicy
metadata:
  name: allow-iam-webgateway
  namespace: app1
spec:
  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.

{ "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.

{ "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.

p data-end="14302" data-start="14268">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=480
System_Manager=127.0.0.1
Maximum_Logged_Request_Size=256K
MAX_CONNECTIONS=4096
Server_Response_Timeout=60
Queued_Request_Timeout=60
Default_Server=IRIS

[APP_PATH:/app]
Alternative_Servers=LoadBalancing
Alternative_Server_0=1~~~~~~server-compute-0
Response_Size_Notification=Chunked Transfer Encoding and Content Length
KeepAlive=No Action
GZIP_Compression=Enabled
GZIP_Exclude_File_Types=jpeg gif ico png gz zip mp3 mp4 tiff
GZIP_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/v1alpha1
kind: IrisCluster
metadata:
  name: example-app
  namespace: example-namespace
spec:
  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  # irisowner
            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: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: iris-ssd-storageclass
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  encrypted: "true"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: 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

Aller à la publication initiale écrit par @Roy Leonov

Architecture de sécurité à plusieurs niveaux pour les déploiements IRIS sur AWS avec IAM d'InterSystems

Niveau 1: Sécurité périmétrique avec AWS WAF et CloudFront

Niveau 2: Sécurité réseau avec AWS VPC et groupes de sécurité

Niveau 3: Sécurité des API avec IAM d'InterSystems