Recherche

Mise à jour des plates-formes prises en charge par InterSystems, février 2023 Bienvenue à la toute première Mise à jour des Plates-formes prises en charge ! Nous recevons souvent des questions sur les changements récents et à venir dans la liste des plates-formes et des frameworks pris en charge par la plate-forme de données IRIS d'InterSystems. Cette mise à jour vise à partager les changements récents ainsi que nos meilleures connaissances actuelles sur les changements à venir, mais prévoir l'avenir est une affaire délicate et ceci ne doit pas être considéré comme une véritable feuille de route. Nous prévoyons de publier ce type de mise à jour tous les trois mois environ, puis de procéder à une réévaluation au bout d'un an. Si vous trouvez cette mise à jour utile, faites-le nous savoir ! Nous apprécierions également toute suggestion visant à l'améliorer. Une fois cela dit, passons à la mise à jour... Systèmes d'exploitation de production et architectures de CPU pour IRIS Red Hat Enterprise Linux Les changements récents IRIS 2022.1.2 ajoute la prise en charge de RHEL 9.0.  9.0 est une version majeure du système d'exploitation qui met à jour le Linux Kernel à 5.14, OpenSSL à 3.0, et Python 3.9 IRIS 2022.2.0 supprime la prise en charge de RHEL 7.x.  RHEL 7.9 est toujours pris en charge dans les versions antérieures d'IRIS. Les changements à venir RHEL 9.1 a été publié en novembre 2022. Red Hat prend en charge cette version mineure uniquement jusqu'à la sortie de RHEL 9.2. La sortie de RHEL 9.2 est prévue pour la fin du deuxième trimestre 2023 et. Red Hat prévoit de prendre en charge la version 9.2 pour une période de 4 ans. InterSystems prévoit d'effectuer des tests supplémentaires d'IRIS sur RHEL 9.2 par le biais d'un nouveau processus que nous appelons "certification de la version mineure du système d'exploitation" et qui vise à fournir une sécurité supplémentaire en garantissant qu'une mise à jour mineure du système d'exploitation n'a rien cassé d'évident. La maintenance étendue de RHEL 8.4 se termine le 31 mai 2023, ce qui signifie qu'IRIS cessera également de prendre en charge cette version mineure à cette date. Pour en savoir plus : Page de publication de RHEL   Ubuntu Les changements récents IRIS 2022.1.1 ajoute la prise en charge de Ubuntu 22.04.  22.04 est une version majeure du système d'exploitation qui met à jour le Linux Kernel à 5.15, OpenSSL à 3.0.2, et Python 3.10.6 IRIS 2022.2.0 supprime la prise en charge d' Ubuntu 18.04.  Ubuntu 18.04 est toujours pris en charge dans les versions antérieures d'IRIS. Les conteneurs IRIS 2022.1.1 et suivants sont basés sur Ubuntu 22.04. Les changements à venir Ubuntu 20.04.05 LTS et 22.04.01 LTS ont été récemment publiés. InterSystems prévoit d'effectuer des tests supplémentaires d'IRIS sur 20.04.05 LTS et 22.04.01 LTS par le biais d'un nouveau processus que nous appelons "certification de version mineure de système d'exploitation". Nous vous en dirons plus sur ces "certifications de versions mineures de systèmes d'exploitation" dans une prochaine newsletter. La prochaine mise à jour majeure d'Ubuntu est prévue pour avril 2024. Pour en savoir plus : Page de publication d'Ubuntu   SUSE Linux Les changements récents IRIS 2022.3.0 ajoute la prise en charge de SUSE Linux Enterprise Server 15 SP4.  15 SP4 est une version majeure du système d'exploitation qui met à jour le Linux Kernel à 5.14, OpenSSL à 3.0, et Python 3.9 Les changements à venir Sur la base de leur calendrier de publication, nous nous attendons à ce que SUSE publie 15 SP5 à la fin du deuxième trimestre ou au début du troisième trimestre et que la prise en charge soit ajoutée à IRIS par la suite. Pour en savoir plus : Cycle de vie de SUSE   Oracle Linux Les changements récents IRIS 2022.3.0 ajoute la prise en charge de Oracle Linux 9.  Oracle Linux 9 est une version majeure du système d'exploitation qui fait suite à RHEL 9. Elle met également à jour le Linux Kernel à 5.14, OpenSSL à 3.0 et Python 3.9 Les changements à venir Oracle Linux 9.1 a été publié en janvier 2023. Pour en savoir plus : Politique de prise en charge d'Oracle Linux   Microsoft Windows Les changements récents Nous n'avons apporté aucune modification à la liste des versions de Windows prises en charge depuis l'ajout de Windows Server 2022 dans IRIS 2022.1 Les changements à venir Windows Server 2012 atteindra la fin de sa période de prise en charge étendue en octobre 2023. Si vous utilisez encore cette plateforme, c'est le moment de planifier la migration. Pour en savoir plus : Cycle de vie de Microsoft   AIX Les changements récents Nous n'avons apporté aucune modification à la liste des versions AIX prises en charge depuis l'ajout d'AIX 7.3 et la suppression d'AIX 7.1 dans IRIS 2022.1 Les changements à venir InterSystems coopère étroitement avec IBM pour ajouter la prise en charge d'OpenSSL 3.0. Cette fonctionnalité ne sera pas incluse dans IRIS 2023.1.0 car IBM devra la cibler dans une prochaine version TL. Heureusement, IBM envisage de publier OpenSSL 3.0 pour AIX 7.2 et 7.3. IBM a publié AIX 7.3 TL1 en décembre et la certification est en cours. Les prochains TLs sont attendus en avril. Pour en savoir plus : Cycle de vie d'AIX   Conteneurs Les changements récents Nous publions désormais des manifestes multi-architecture pour les conteneurs IRIS. Cela signifie que le fait de tirer le conteneur IRIS ayant la balise 2022.3.0.606.0 téléchargera le conteneur approprié pour l'architecture du CPU de votre machine (Intel/AMD ou ARM). Si vous devez extraire un conteneur pour une architecture de CPU spécifique, des balises sont disponibles pour les conteneurs spécifiques à une architecture. Par exemple, 2022.3.0.606.0-linux-amd64 extrait le conteneur Intel/AMD et 2022.3.0.606.0-linux-arm64v8 extrait le conteneur ARM. Les changements à venir Nous remplacerons peu à peu les noms d'images spécifiques à l'arm, tels que iris-arm64 par les manifestes multi-architectures au cours du second semestre de l'année. Nous allons également commencer à marquer les conteneurs de prévisualisation avec "-preview" pour qu'il soit clair quel conteneur est la version GA la plus récente.   Systèmes d'exploitation et Architectures de CPU pour IRIS Development MacOS Les changements récents Nous n'avons apporté aucune modification à la liste des versions de MacOS prises en charge depuis le passage à MacOS 11 dans IRIS 2022.1 Les changements à venir Nous prévoyons d'ajouter la prise en charge de MacOS 13 en 2023, peut-être à partir de la version IRIS 2023.1.   CentOS Nous envisageons de supprimer la prise en charge de CentOS/CentOS Stream. Voir le raisonnement ci-dessous. Depuis quelques années, Red Hat a mis en place un programme pour les développeurs, qui leur donne accès à des licences gratuites pour les environnements de non-production. Les développeurs qui utilisent actuellement CentOS sont encouragés à passer à RHEL par le biais de ce programme. CentOS Stream est maintenant "en amont" de RHEL, ce qui signifie qu'il comporte des bogues et des fonctionnalités qui ne sont pas encore inclus dans RHEL. De plus, les mises à jour sont quotidiennes, ce qui peut poser des problèmes aux développeurs qui utilisent cette plate-forme (sans parler de notre propre équipe de test). Nous n'avons apporté aucune modification à la liste des versions de CentOS prises en charge depuis la prise en charge de CentOS 8-Stream et la suppression de CentOS 7.9 dans IRIS 2022.1   Systèmes d'exploitation de production et architectures de CPU pour Caché et Ensemble Les changements récents Cache 2018.1.7 ajoute la prise en charge de Windows 11   Documentation sur les plates-formes prises en charge par InterSystems La documentation des Plates-formes prises en charge par InterSystems est la source de la liste définitive des technologies prises en charge. Plate-formes serveur prises en charge par IRIS 2020.1 Plate-formes serveur prises en charge par IRIS 2021.1 Plate-formes serveur prises en charge par IRIS 2022.1 Plate-formes serveur prises en charge par IRIS 2022.3 Plate-formes serveur prises en charge par Caché & Ensemble 2018.1.7   … et c'est tout, les gars. Encore une fois, s'il y a quelque chose de plus que vous aimeriez savoir, n'hésitez pas à nous le signaler.  

Salut la Communauté! Profitez de regarder la nouvelle vidéo sur la chaîne Youtube d'InterSystems France : 📺 MyPL - Construire avec InterSystems IRIS Data Platform notre business de demain Restez à l'écoute pour plus de vidéos !

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. 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: Guide d'administration de la sécurité Portail de gestion de la sécurité 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

Si vous migrez d'Oracle vers InterSystems IRIS, comme beaucoup de mes clients, vous risquez de rencontrer des modèles SQL spécifiques à Oracle nécessitant une conversion. Prenons l'exemple suivant: SELECT (TO_DATE('2023-05-12','YYYY-MM-DD') - LEVEL + 1) AS gap_date FROM dual CONNECT BY LEVEL <= (TO_DATE('2023-05-12','YYYY-MM-DD') - TO_DATE('2023-05-02','YYYY-MM-DD') + 1); Dans Oracle: LEVEL est une pseudo-colonne utilisée dans les requêtes hiérarchiques (CONNECT BY). Elle commence à 1 et s'incrémente de 1. CONNECT BY LEVEL <= (...) détermine le nombre de lignes à générer. La différence entre les deux dates plus un donne 11, donc la requête génère 11 lignes, en comptant à rebours à partir du 12 mai 2023 jusqu'au 2 mai 2023. Répartition du résultat: LEVEL = 1 → 2023-05-12 LEVEL = 2 → 2023-05-11 ... LEVEL = 11 → 2023-05-02 La question est maintenant de savoir comment obtenir ce résultat dans InterSystems IRIS, qui ne prend pas en charge CONNECT BY? Une solution consiste à implémenter une requête de type SQL à l'aide d'ObjectScript qui imite ce comportement. Vous trouverez ci-dessous un exemple de définition CREATE QUERY qui accepte une date de début STARTDATE et un nombre de jours DAYS, et renvoie la liste des dates par ordre descendant. ✅ InterSystems IRIS: mise en œuvre d'une requête de l'intervalle de date CREATE QUERY GET_GAP_DATE(IN STARTDATE DATE, IN DAYS INT) RESULTS (GAP_DATE DATE) PROCEDURE LANGUAGE OBJECTSCRIPT Execute(INOUT QHandle BINARY(255), IN STARTDATE DATE, IN DAYS INT) { SET QHandle("start") = STARTDATE SET QHandle("days") = DAYS SET QHandle("level") = 1 RETURN $$$OK } Fetch(INOUT QHandle BINARY(255), INOUT Row %List, INOUT AtEnd INT) { IF (QHandle("level") > QHandle("days")) { SET Row = "" SET AtEnd = 1 } ELSE { SET Row = $ListBuild(QHandle("start") - QHandle("level") + 1) SET QHandle("level") = QHandle("level") + 1 } RETURN $$$OK } Close(INOUT QHandle BINARY(255)) { KILL QHandle QUIT $$$OK } Vous pouvez exécuter la commande CREATE QUERY Vous pouvez exécuter la commande CREATE QUERY ci-dessus dans le portail IRIS System Management, ou via un outil tel que DBeaver ou un éditeur Python/Jupyter Notebook utilisant JDBC/ODBC. 🧪 Exemple d'utilisation: Pour générer le même résultat que la requête Oracle ci-dessus, utilisez: SELECT * FROM GET_GAP_DATE( TO_DATE('2023-05-12', 'YYYY-MM-DD'), TO_DATE('2023-05-12', 'YYYY-MM-DD') - TO_DATE('2023-05-02', 'YYYY-MM-DD') + 1 ); Cela donnera le résultat suivant: GAP_DATE ---------- 2023-05-12 2023-05-11 ... 2023-05-02 (11 rows) 🔁 Utilisation avancée: Jointure avec d'autres tables Vous pouvez également utiliser cette requête comme sous-requête ou dans des jointures: SELECT * FROM GET_GAP_DATE(TO_DATE('2023-05-12', 'YYYY-MM-DD'), 11) CROSS JOIN dual; Cela vous permet d'intégrer des plages de dates dans des flux SQL plus importants. J'espère que cela sera utile à tous ceux qui sont confrontés à des scénarios de migration d'Oracle vers IRIS ! Si vous avez mis au point des solutions alternatives ou si vous proposez des améliorations, n'hésitez pas à me faire part de vos commentaires.

Ce message renvoie à 14 avis récents qui ont été publiés sur la page InterSystems Product Alerts and Advisories page. Tous les éléments affectent les produits HealthShare, et les trois premiers éléments affectent également InterSystems IRIS for Health. FHIR Search with an Assigning Authority but no Identifier Omits Results Some FHIR Queries that use _include and _revinclude Fail Silently FHIR Queries May Omit Results FHIR Queries that Specify a Quantity but no Units of Measure Return Incorrect Results Time Zone Offsets not Applied to FHIR Resources FHIR Searches that Specify a Time Range may Improperly Include or Exclude some Data Clinical Viewer may lose “Standard Types” on Upgrade Cross-site Scripting Issue in the Clinical Viewer MPI Demographics May Contain Unconsented Data When No Consent Group is Specified, Clinical Consent Rules May Fail HS.Stream Global in Edge Gateways Not Cleared After Errors HealthShare Care Community Tasks can be Assigned to Members of a Care Team who do not have Permission to View or Take Action on them Cross-site Scripting Vulnerability in HealthShare Patient Index Medications with a Blank “Start Date” may not Display in the Clinical Viewer

Bonjour à tous, Voici le premier concours de programmation de l'année, et une surprise vous attend ! Lisez la suite ! 🏆 Concours de programmation InterSystems IA : Recherche vectorielle, GenAI et agents IA 🏆 Durée : du 17 mars au 6 avril 2025 Prix : 12 000 $ + une chance d'être invité au Sommet mondial 2025 ! Le sujet Développez n'importe quelle solution sur InterSystems IRIS, InterSystems IRIS for Health ou IRIS Cloud SQL qui utilise l'IA (IntegratedML inclus). Exigences générales : Une application ou une bibliothèque doit être entièrement fonctionnelle. Il ne doit pas s'agir d'un import ou d'une interface directe pour une bibliothèque déjà existante dans un autre langage (sauf pour le C++, là il faut vraiment faire beaucoup de travail pour créer une interface pour Iris). Il ne doit pas s'agir d'un copier-coller d'une application ou d'une bibliothèque existante. Applications acceptées : nouvelles applications sur Open Exchange ou existantes, mais avec une améliorations significatives. Notre équipe examinera toutes les candidatures avant de les approuver pour le concours. L'application doit fonctionner sur IRIS Community Edition, IRIS for Health Community Edition ou IRIS Cloud SQL. Les deux peuvent être téléchargés en tant que versions hôtes (Mac, Windows) à partir du site d'évaluation, ou peuvent être utilisés sous la forme de conteneurs extraits d'InterSystems Container Registry ou de Community Containers : intersystemsdc/iris-community:latest ou intersystemsdc/irishealth-community:latest . L'application doit être Open Source et publiée sur GitHub ou GitLab. Le fichier README de l'application doit être en anglais, contenir les étapes d'installation, et la vidéo de démonstration ou/et une description du fonctionnement de l'application. Pas plus de 3 soumissions d’un développeur sont autorisées. N.B. Nos experts auront le dernier mot quant à l'approbation ou non de la candidature au concours en fonction des critères de complexité et d'utilité. Leur décision est définitive et sans appel. Prix ​​du concours : ❗Les auteurs des projets les plus intéressants mettant en valeur l'utilisation d'agents IA seront invités au Global Summit 2025 (les billets pour l'événement et l'hébergement soient fournis). 1. Nomination des experts – les gagnants seront sélectionnés par l'équipe d'experts d'InterSystems : 🥇 1ère place - $5,000🥈 2e place - $2,500🥉 3e place - $1,000🏅 4e place - $500🏅 5e place - $300🌟 6-10e places - $100 2. Gagnants de la communauté – candidatures qui recevront le plus de votes au total : 🥇 1ère place - $1,000 🥈 2e place - $600🥉 3e place - $300🏅 4e place - $200🏅 5e place - $100 Remarque : si plusieurs participants obtiennent le même nombre de votes, ils sont tous considérés comme gagnants et le prix est partagé entre les gagnants. Qui peut participer ? Tout membre de la communauté de développeurs, à l'exception des employés d'InterSystems (sous-traitants ISC autorisés). Créer un compte ! Les développeurs peuvent s'associer pour créer une application collaborative. Autorisé de 2 à 5 développeurs dans une équipe. N'oubliez pas de mettre en évidence les membres de votre équipe dans le README de votre application – profils d'utilisateurs DC. Délais importants : 🛠 Phase de développement et d'inscription de l'application : 17 mars 2025 (00:00 EST): le concours commence. 30 mars 2025 (23:59 EST): la date limite de soumission. ✅ Période de vote: 31 mars 2025 (00:00 EST): le vote commence. 6 avril 2025 (23:59 EST): le vote se termine. Remarque : Les développeurs peuvent améliorer leurs applications tout au long de la période d'inscription et de vote. Ressources utiles : ✓ Documentation : Documentation sur la recherche vectorielle Documentation sur InterSystems IntegratedML ✓ Exemples d'applications et de bibliothèques : IRIS Vector Search llamaindex-iris langchain-iris workshop-vector-face IRIS FHIR SQL Builder DBT IntegratedML integratedml-demo-template integratedml-demo iris-local-ml iris-fine-tune-ml QuinielaML workshop-integratedml-csv iris-rag-demo ✓ Cours en ligne: Using Vector Search for Generative AI IntegratedML Interactive Intro Course Hands-on with IntegratedML ✓ Vidéos: Using Vector Search for Generative AI Adding AI into Interoperability Production Building Models with integratedML in the cloud Generative AI Use Cases in Healthcare ✓ Pour les débutants avec IRIS : Build a Server-Side Application with InterSystems IRIS Learning Path for beginners ✓ Pour les débutants avec ObjectScript Package Manager (IPM) : How to Build, Test and Publish IPM Package with REST Application for InterSystems IRIS Package First Development Approach with InterSystems IRIS and IPM ✓ Comment soumettre votre application au concours : How to submit an application on Open Exchange How to apply for the contest Besoin d'aide ? Rejoignez la chaîne du concours sur le serveur Discord d'InterSystems ou discutez avec nous dans les commentaires de ce post. Nous avons hâte de voir vos projets! Bonne chance 👍 En participant à ce concours, vous acceptez les conditions du concours énoncées ici. Veuillez les lire attentivement avant de continuer.

Il s'agit d'un modèle de base pour un environnement de développement permettant de travailler avec ObjectScript dans InterSystems IRIS. Il vous aide à éditer, compiler, commettre/pousser, déboguer et tester votre code ObjectScript. Il aide également à conditionner votre application en tant que module installable avec IPM. Le modèle est compatible avec Embedded Python. Description Ce référentiel fournit un environnement de développement prêt à l'emploi pour coder de manière productive avec ObjectScript d'InterSystems. Ce modèle: Exécute la version communautaire Community Edition d'IRIS d'InterSystems dans un conteneur docker. Crée un nouvel espace de noms et une nouvelle base de données IRISAPP Charge le code ObjectScript dans la base de données IRISAPP à l'aide du gestionnaire Package Manager. Favorise le développement avec le paradigme 'Package First' (le paquet d'abord). Regardez la vidéo Fournit un environnement de tests unitaires : exemples de tests unitaires, activation de modules de tests. Prêt pour le développement de python intégré : Les variables ENV sont configurées, le service CallIn est activé, tous les modules du fichier requirements.txt seront installés lors de la construction du docker. Utilisation Démarrez un nouveau référentiel de développement avec Intersystems IRIS en l'utilisant comme modèle. Une fois que vous aurez cloné le nouveau dépôt sur votre ordinateur portable et que vous aurez ouvert VSCode (avec le paquet d'extension InterSystems ObjectScript Extension Pack installé), vous pourrez commencer à développer immédiatement. Conditions préalables Assurez-vous que vous avez installé git et Docker desktop. Installation Clone/git extrait le référentiel dans n'importe quel répertoire local. $ git clone https://github.com/intersystems-community/intersystems-iris-dev-template.git Ouvrez le terminal dans ce répertoire et appelez la commande pour construire et exécuter InterSystems IRIS dans le conteneur : Remarque : Les utilisateurs qui exécutent des conteneurs sur une CLI Linux doivent utiliser "docker compose" au lieu de "docker-compose" Voir Installation du plugin Compose $ docker-compose up -d Pour ouvrir le Terminal IRIS, faites: Ouvrez le terminal IRIS et exécutez la méthode ObjectScript Test() pour voir si le script est exécuté et si IRIS renvoie des valeurs : IRISAPP> Pour quitter le terminal, effectuez l'une des opérations suivantes: Saisissez HALT ou H (non sensible à la casse) Comment ça fonctionne Le référentiel d'exemples contient deux exemples très simples de classes ObjectScript : une méthode ObjectScript qui renvoie une valeur et une méthode qui crée un enregistrement persistant. Ouvrez le terminal IRIS et exécutez la méthode ObjectScript Test() pour voir si elle exécute le script et renvoie les valeurs d'IRIS: Ouvrez le terminal IRIS et exécutez la méthode ObjectScript Test() pour voir si le script est exécuté et si IRIS renvoie des valeurs : IRISAPP>write ##class(dc.sample.ObjectScript).Test() Ça marche! 42 La classe dc.sample.PersistentClass contient une méthode CreateRecord qui crée un objet avec une propriété, Test, et renvoie son identifiant. Ouvrez le terminal IRIS et exécutez: IRISAPP>write ##class(dc.sample.PersistentClass).CreateRecord(.id) 1 IRISAPP>write id 1 Dans votre cas, la valeur de l"identifiant pourrait être différente. Et ele sera différente à chaque appel de la méthode. Vous pouvez vérifier si l'enregistrement existe et essayer de redresser la propriété de l'objet par son identifiant. IRISAPP>write ##class(dc.sample.PersistentClass).ReadProperty(id) Chaîne de test Comment lancer le développement Ce référentiel est prêt à être codé dans VSCode avec le plugin ObjectScript. Installez VSCode, Docker et le plugin InterSystems ObjectScript Extension Pack et ouvrez le dossier dans VSCode. Ouvrez la classe /src/cls/PackageSample/ObjectScript.cls et y apportez des modifications - elle sera compilée dans le conteneur docker IRIS en cours d'exécution. N'hésitez pas à supprimer le dossier PackageSample et à placer vos classes ObjectScript sous la forme /src/organisation/package/Classname.cls Lisez plus sur la configuration des dossiers pour InterSystems ObjectScript et ici sur la convention de dénomination. Exécution de tests unitaires Le modèle contient deux classes de test: TestObjectScript.cls et TestPersistentClass.cls Pour exécuter les tests unitaires, nous pouvons utiliser l'environnement du gestionnaire Package Manager. IRISAPP>zpm ============================================================================= || Bienvenue dans le Package Manager Shell (ZPM). || || Saisissez q/quit pour quitter le shell. Saisissez ?/help pour afficher les commandes disponibles || ============================================================================= zpm:IRISAPP>load /irisrun/repo [dc-sample-template] Reload START (/irisrun/repo/) [dc-sample-template] Reload SUCCESS [dc-sample-template] Module object refreshed. [dc-sample-template] Validate START [dc-sample-template] Validate SUCCESS [dc-sample-template] Compile START [dc-sample-template] Compile SUCCESS [dc-sample-template] Activate START [dc-sample-template] Configure START [dc-sample-template] Configure SUCCESS [dc-sample-template] MakeDeployed START [dc-sample-template] MakeDeployed SUCCESS [dc-sample-template] Activate SUCCESS zpm:IRISAPP>test dc-sample-template [dc-sample-template] Reload START (/irisrun/repo/) [dc-sample-template] Reload SUCCESS [dc-sample-template] Module object refreshed. [dc-sample-template] Validate START [dc-sample-template] Validate SUCCESS [dc-sample-template] Compile START [dc-sample-template] Compile SUCCESS [dc-sample-template] Activate START [dc-sample-template] Configure START [dc-sample-template] Configure SUCCESS [dc-sample-template] MakeDeployed START [dc-sample-template] MakeDeployed SUCCESS [dc-sample-template] Activate SUCCESS [dc-sample-template] Test STARTIt works! Utilisez l'URL suivante pour afficher le résultat: http://172.28.0.2:52773/csp/sys/%25UnitTest.Portal.Indices.cls?Index=1&$NAMESPACE=IRISAPP All PASSED [dc-sample-template] Test SUCCESS zpm:IRISAPP> En cas d'erreurs de test, vous pouvez retrouver plus de détails dans le portail UnitTest, qui peut être facilement ouvert via le menu ObjectScript dans VSCode : Ce qu'il y a d'autre dans le référentiel dossier .github Contient deux flux de travail GitHub: github-registry.ymlUne fois que les changements ont été poussés vers le dépôt, l'action construit l'image docker du côté de Github et pousse l'image vers le registre Github qui peut être très pratique pour un déploiement ultérieur dans le cloud, par exemple kubernetes. objectscript-qaulity.yml à chaque poussée vers la branche principale ou master, le workflow lance le test du référentiel sur les problèmes d'Objectscript avec l'outil Objectscript Quality, voir les exemples. Cela fonctionne si le référentiel est uniquement open-source. Les deux flux de travail sont indépendants du référentiel: ils fonctionnent donc avec n'importe quel référentiel où ils existent. dossier .vscode Contient deux fichiers pour configurer l'environnement vscode: .vscode/settings.json Fichier de configuration pour vous permettre de coder immédiatement en VSCode avec le plugin VSCode ObjectScript. .vscode/launch.json Fichier de configuration si vous voulez déboguer avec VSCode ObjectScript dossier src Contient les fichiers sources. src/iris contient le code Objectscript d'InterSystems IRIS. dossier tests Contient des tests unitaires pour les classes ObjectScript dev.md Contient un ensemble de commandes utiles qui vous aideront pendant le développement docker-compose.yml Un fichier d'aide du moteur docker pour gérer la construction d'images et le mappage des ports de règles et de l'hôte aux dossiers (volumes) des conteneurs Dockerfile Le dockerfile le plus simple qui lance IRIS et y importe le code du dossier /src. Utilisez le fichier docker-compose.yml correspondant pour configurer facilement des paramètres supplémentaires tels que le numéro de port et l'emplacement des clés et des dossiers d'hôte. iris.script Contient les commandes objectcript qui sont envoyées à iris lors de la construction de l'image module.xml Description du code du module IPM dans le référentiel. On y trouve une description de ce qui est chargé avec la méthode, de la manière dont on la teste et des applications qui doivent être créées, des fichiers qui doivent être copiés.

.png) Bonjour à la communauté, Dans cet article, je vais présenter mon application iris-mlm-explainer Cette application web se connecte au service SQL d'InterSystems Cloud pour créer, entraîner, valider et prédire des modèles d'apprentissage automatique, faire des Prédictions et afficher un tableau de bord de tous les modèles entraînés avec une explication du fonctionnement d'un modèle d'apprentissage automatique ajusté. Le tableau de bord fournit des graphiques interactifs sur les performances du modèle, les importances des caractéristiques, les contributions des caractéristiques aux prédictions individuelles, les graphiques de dépendance partielle, les valeurs SHAP (interaction), la visualisation des arbres de décision individuels, etc.    ## Conditions préalables * Vous devez avoir un compte à SQL d'InterSystems Cloud * Vous devez avoir <a book="" fr="" getting-started-installing-git="" git-scm.com="" https:="" v2="">**Git**</a> installé localement. * Vous devez avoir <a downloads="" https:="" www.python.org="">**Python3**</a> installé localement.   ## Démarrage Nous allons suivre les étapes suivantes pour créer et afficher le tableau de bord explicatif d'un modèle : * Etape 1 : Fermeture/git pull du référentiel * Étape 2 : Connexion au portail de service SQL d'InterSystems Cloud Étape 2.1 : Ajout et gestion de fichiers Étape 2.2 : Importation des fichiers DDL et des fichiers de données Étape 2.3 : Création du modèle Étape 2.4 : Entraînement du modèle Étape 2.5 : Validation du modèle * Étape 3 : Activation de l'environnement virtuel Python * Étape 4 : Exécution de l'application Web pour la prédiction * Étape 5 : Exploration du tableau de bord explicatif ### Etape 1 : Fermeture/git Extraction du référentiel Commençons donc par la première étape Créer un dossier et Cloner/utiliser le git pull pour le référentiel dans n'importe quel répertoire local. git clone https://github.com/mwaseem75/iris-mlm-explainer.git ###   ### Étape 2 : Connexion au portail de service SQL d'InterSystems Cloud Connectez-vous au portail InterSystems Cloud Service Portal  ###   ###   Sélectionner le déploiement en cours  ###   Étape 2.1 : Ajout et gestion des fichiers Cliquez sur Ajout et gestion de fichiers (Add and Manage Files)  Le référentiel contient les fichiers USA\_Housing\_tables_DDL.sql(DDL pour créer les tables), USA\_Housing\_train.csv(données d'entraînement), et USA\_Housing_validate.csv(pour la validation) dans le dossier datasets. Sélectionnez le bouton de téléchargement pour ajouter ces fichiers.    Étape 2.2 : Importation des fichiers DDL et des fichiers de données Cliquez sur Importation de fichiers, puis sur le bouton radio Instruction(s) DDL ou DML, puis sur le bouton suivant.  Cliquez sur le bouton radio Intersystems IRIS et cliquez ensuite sur le bouton suivant  Sélectionnez le fichier USA\_Housing\_tables_DDL.sql et appuyez sur le bouton d'importation de fichiers.  Cliquez sur le bouton d'importation "Import" dans la boîte de dialogue de confirmation pour créer le tableau.  ###   Cliquez sur le bouton des outils de requête SQL (SQL Query tools) pour vérifier que les tableaux sont créés. ### Importez des fichiers de données Cliquez sur Importation de fichiers (Import files), puis sur le bouton radio Données CSV (CSV data), et enfin sur le bouton suivant. ### Selectionnez le fichier USA\_Housing\_train.csv et cliquez sur le bouton suivant ### ###   Sélectionnez le fichier USA_Housing\_train.csv dans la liste déroulante, cochez les cases d'importation de lignes en tant que ligne d'en-tête et de noms de champs dans la ligne d'en-tête correspondant aux noms de colonnes dans le tableau sélectionné, puis cliquez sur Importation de fichiers.  cliquer sur "importation" dans la boîte de dialogue de confirmation  Assurez-vous que 4000 lignes sont mises à jour  Procédez de la même manière pour importer le fichier USA_Housing\_validate.csv qui contient 1500 enregistrements.  Étape 2.3 : Création du modèle Cliquez sur les outils IntegratedM et sélectionnez Créer un panneau (Create Panel). Saisissez USAHousingPriceModel dans le champ de nom du modèle (Model Name), sélectionnez le tableau usa_housing_train et Prix dans la liste déroulante des champs à prédire (Field to predict). Cliquez sur le bouton "Création du modèle" pour créer le modèle. ###   Étape 2.4 : Entraînement du modèle sélectionnez le panneau d'entraînement (Train Panel), sélectionnez USAHousingPriceModel dans la liste déroulante du modèle à entraîner et saisissez USAHousingPriceModel_t1 dans le champ du nom du modèle d'entraînement (Train Model Name) ### Le modèle sera entraîné une fois l'état de fonctionnement (Run Status) achevé ### ###   Étape 2.5 : Validation du modèle Sélectionnez le panneau de validation (Validate Panel), sélectionnez USAHousingPriceModel\_t1 dans le modèle entraîné pour valider la liste déroulante, sélectionnez usa\_houseing_validate dans le tableau pour valider le modèle à partir de la liste déroulante et cliquez sur le bouton de validation du modèle. ###   Cliquez sur affichage des mesures de validation pour visualiser les mesures.    Cliquez sur l'icône graphique pour afficher le graphique Prédiction VS Réalité.  ###   ### Étape 3 : Activation de l'environnement virtuel Python Le référentiel contient déjà un dossier d'environnement virtuel python (venv) avec toutes les bibliothèques nécessaires. Il suffit d'activer l'environnement Pour Unix ou MacOS : <span class="hljs-meta">$</span><span class="bash"> <span class="hljs-built_in">source</span> venv/bin/activate</span> Pour Windows: venv\scripts\activate ### Étape 4 : Définir les paramètres de connexion à InterSystems SQL Cloud Le référentiel contient le fichier config.py. Il suffit de l'ouvrir et de le paramétrer  Mettez les mêmes valeurs que celles utilisées dans InterSystems SQL Cloud  ###   ### Étape 4 : Exécution de l'application Web pour la prédiction Exécutez la commande suivante dans l'environnement virtuel pour démarrer notre application principale python app.py ### Pour démarrer l'application, naviguez jusqu'à http://127.0.0.1:5000/  Entrez l'âge de la maison, le nombre de pièces, le nombre de chambres et la population de la région pour obtenir la prédiction  ### Étape 5 : Exploration du tableau de bord explicatif Enfin, exécutez la commande suivante dans l'environnement virtuel pour démarrer notre application principale python expdash.py   Pour démarrer l'application, naviguez jusqu'à http://localhost:8050/  **L'application répertorie tous les modèles entraînés ainsi que notre modèle USAHousingPriceModel. Cliquez sur "aller au panneau de bord" ("go to dashboard") pour voir l'explication du modèle.** Importance des fonctionnalités. Quelles sont les fonctionnalités ayant eu l'impact le plus important ?    **Mesures quantitatives de la performance des modèles : dans quelle mesure la valeur prédite est-elle proche de la valeur observée ?**    **Prédiction et Comment chaque fonctionnalité a-t-elle contribué à la prédiction ?**    **Ajustez les valeurs des fonctionnalités pour modifier la prédiction**  **Sommaire des SHAPs, Classement des caractéristiques par valeurs de SHAPs**    **Sommaire des interactions, classement des fonctionnalités par valeur d'interaction de SHAP**    **Arbres de décision, affichage des arbres de décision individuels dans la forêt aléatoire**    Merci

Introduction Aujourd'hui, de nombreuses applications utilisent le cadre d'autorisation ouvert (OAuth) pour accéder aux ressources de toutes sortes de services de manière sûre, fiable et efficace. InterSystems IRIS est déjà compatible avec le cadre OAuth 2.0, en fait, il y a un excellent article dans la communauté concernant OAuth 2.0 et InterSystems IRIS dans le lien suivant [ici](https://community.intersystems.com/post/intersystems-iris-open-authorization-framework-oauth-20-implementation-part-1). Toutefois, avec l'avènement des outils de gestion des API, certaines organisations l'utilisent comme point unique d'authentification, empêchant les demandes non autorisées d'arriver aux services descendants et découplant les complexités d'autorisation/authentification du service lui-même. Comme vous le savez peut-être, InterSystems a lancé son outil de gestion des API, appelé InterSystems API Management (IAM), qui est disponible avec la licence IRIS Enterprise (et non IRIS Community Edition). Vous trouverez [ici](https://community.intersystems.com/post/introducing-intersystems-api-manager) un autre excellent article de la communauté présentant InterSystems API Management.  Il s'agit de la première partie d'une série d'articles en trois parties qui montrent comment vous pouvez utiliser IAM pour ajouter simplement de la sécurité, selon les normes OAuth 2.0, à un service précédemment non authentifié déployé dans IRIS. Dans cette première partie, vous trouverez des informations sur OAuth 2.0 ainsi que des définitions et des configurations initiales d'IRIS et d'IAM afin de faciliter la compréhension de l'ensemble du processus de sécurisation de vos services. Suite à la première partie, cette série d'articles abordera deux scénarios possibles pour sécuriser vos services avec IAM. Dans le premier scénario, IAM validera uniquement le jeton d'accès présent dans la requête entrante et transmettra la requête au backend si la validation réussit. Dans le second scénario, IAM va à la fois générer un jeton d'accès (en agissant comme un serveur d'autorisation) et le valider. Par conséquent, la deuxième partie abordera et montrera en détail les étapes nécessaires pour configurer le scénario 1, et la troisième partie abordera et démontrera les configurations pour le scénario 2, ainsi que quelques considérations finales. Si vous voulez essayer IAM, veuillez contacter votre représentant commercial InterSystems. OAuth 2.0 : contexte Chaque flux d'autorisation OAuth 2.0 se compose essentiellement de 4 parties : 1. Utilisateur 2. Client 3. Serveur d'autorisation 4. Propriétaire de la ressource Pour des raisons de simplicité, cet article utilisera le flux OAuth "Resource Owner Password Credentials" (Identifiants du mot de passe du propriétaire de la ressource), mais vous pouvez utiliser n'importe quel flux OAuth dans IAM. De même, cet article ne spécifiera aucune portée. Note: Vous ne devez utiliser le flux d'informations d'identification du mot de passe du propriétaire des ressources que lorsque l'application cliente est hautement fiable, car elle traite directement les informations d'identification des utilisateurs. Dans la plupart des cas, le client doit être une application de première partie. En général, le flux "Resource Owner Password Credentials" (Identifiants du mot de passe du propriétaire de la ressource) suit les étapes suivantes : 1. L'utilisateur saisit ses identifiants (par exemple le nom d'utilisateur et le mot de passe) dans l'application client. 2. L'application client envoie les identifiants de l'utilisateur ainsi que sa propre identification (identifiant et secret du client, par exemple) au serveur d'autorisation. Le serveur d'autorisation valide les identifiants de l'utilisateur et l'identification du client et renvoie un jeton d'accès. 3. Le client utilise le jeton pour accéder aux ressources du serveur de ressources. 4. Le serveur de ressources valide le jeton d'accès reçu avant de renvoyer toute information au client. Dans cette optique, il existe deux scénarios dans lesquels vous pouvez utiliser IAM pour traiter OAuth 2.0 : 1. IAM agit comme un validateur, vérifiant le jeton d'accès fourni par l'application cliente, transmettant la demande au serveur de ressources uniquement si le jeton d'accès est valide ; dans ce cas, le jeton d'accès serait généré par un serveur d'autorisation tiers. 2. IAM agissant à la fois comme un serveur d'autorisation, fournissant un jeton d'accès au client, et comme un validateur de jeton d'accès, vérifiant le jeton d'accès avant de rediriger la demande vers le serveur de ressources. Définitions d'IRIS et d'IAM Dans ce post, il sera utilisé une application Web IRIS appelée "/SampleService". Comme vous pouvez le voir sur la capture d'écran ci-dessous, il s'agit d'un service REST non authentifié déployé dans IRIS :   En outre, dans le côté IAM est configuré un service appelé "SampleIRISService" contenant un itinéraire, comme vous pouvez le voir dans la capture d'écran ci-dessous :   En outre, dans IAM est configuré un consommateur appelé "ClientApp", initialement sans aucun justificatif d'identité, pour identifier celui qui appelle l'API dans IAM :   Avec les configurations ci-dessus, IAM transmet chaque requête GET envoyée à l'URL suivante à IRIS : **http://iamhost:8000/event** À ce stade, aucune authentification n'est encore utilisée. Par conséquent, si nous envoyons une simple requête GET, sans authentification, à l'URL **http://iamhost:8000/event/1** nous obtenons la réponse recherchée. Dans cet article, nous allons utiliser une application appelée "PostMan" pour envoyer des requêtes et vérifier les réponses. Dans la capture d'écran de PostMan ci-dessous, vous pouvez voir une simple requête GET ainsi que sa réponse. Passez à la deuxième partie de cette série pour comprendre comment configurer IAM pour valider les jetons d'accès présents dans les demandes entrantes.

Dans cette série d'articles en trois parties, il est montré comment vous pouvez utiliser IAM pour ajouter simplement de la sécurité, selon les normes OAuth 2.0, à un service précédemment non authentifié déployé dans IRIS. Dans la [première partie](https://fr.community.intersystems.com/post/s%C3%A9curisation-de-vos-api-avec-oauth-20-dans-le-cadre-de-la-gestion-des-api-dintersystems-partie), nous avons fourni des informations sur OAuth 2.0 ainsi que des définitions et des configurations initiales d'IRIS et d'IAM afin de faciliter la compréhension de l'ensemble du processus de sécurisation de vos services. Cette partie va maintenant discuter et montrer en détail les étapes nécessaires pour configurer IAM pour valider le jeton d'accès présent dans la demande entrante et transmettre la demande au backend si la validation réussit. La [dernière partie](https://fr.community.intersystems.com/post/s%C3%A9curisation-de-vos-api-avec-oauth-20-dans-le-cadre-de-la-gestion-des-api-dintersystems-1) de cette série abordera et démontrera les configurations nécessaires pour que IAM génère un jeton d'accès (agissant comme un serveur d'autorisation) et le valide, ainsi que quelques considérations finales importantes. Si vous voulez essayer IAM, veuillez contacter votre représentant commercial d'InterSystems. Scénario 1 : IAM comme validateur de jetons d'accès Dans ce scénario, il sera utilisé un serveur d'autorisation externe qui génère un jeton d'accès au format JWT (JSON Web Token). Ce JWT est signé à l'aide de l'algorithme RS256 et d'une clé privée. Afin de vérifier la signature du JWT, l'autre partie (dans ce cas IAM) doit avoir la clé publique, fournie par le serveur d'autorisation. Ce JWT généré par le serveur d'autorisation externe comprend également, dans son corps, une déclaration appelée "exp" contenant l'horodatage de la date d'expiration de ce jeton, et une autre déclaration appelée "iss" contenant l'adresse du serveur d'autorisation. Par conséquent, IAM doit vérifier la signature du JWT avec la clé publique des serveurs d'autorisation et l'horodatage d'expiration contenu dans la déclaration "exp" à l'intérieur du JWT avant de transmettre la demande à IRIS. Afin de configurer cela dans IAM, commençons par ajouter un plugin appelé "JWT" à notre "SampleIRISService" dans IAM. Pour ce faire, allez sur la page Services dans IAM et copiez l'identifiant du "SampleIRISService", nous allons l'utiliser plus tard. Ensuite, allez dans Plugins, cliquez sur le bouton "New Plugin", localisez le plugin "JWT" et cliquez sur Enable. Dans la page suivante, copiez l'identifiant "SampleIRISService" dans le champ "service\_id" et cochez la case "exp" dans le paramètre "config.claims\_to_verify". Notez que la valeur du paramètre "config.key\_claim\_name" est "iss". Nous allons l'utiliser plus tard. Ensuite, appuyez sur le bouton "Create" (créer). Cela fait, allez dans la section "Consumers" dans le menu de gauche et cliquez sur notre "ClientApp" précédemment créée. Allez dans l'onglet "Credentials" (identifiants) et cliquez sur le bouton “New JWT Credential” (nouveau Identifiants JWT). Dans la page suivante, sélectionnez l'algorithme utilisé pour signer le JWT ( ici RS256) et copiez la clé publique dans le champ "rsa\_public\_key" (il s'agit de la clé publique qui vous a été fournie par le serveur d'autorisation au format PEM). Dans le champ "key", vous devez insérer le contenu du revendication JWT que vous avez entré dans le champ "config.key\_claim\_name" lors de l'ajout du plugin JWT. Donc, dans ce cas, je dois insérer le contenu de la revendication iss de mon JWT, qui, dans mon cas, est l'adresse du serveur d'autorisation. Après cela, cliquez sur le bouton "Créer". Hint: À des fins de débogage, il existe un outil en ligne permettant de décoder le JWT afin que vous puissiez vérifier les revendications et leurs valeurs et vérifier les signatures en insérant la clé publique. Voici le lien de cet outil en ligne : https://jwt.io/#debugger Maintenant, avec l'ajout du plugin JWT, il n'est plus possible d'envoyer la requête sans authentification. Comme vous pouvez le voir ci-dessous, une simple demande GET, sans authentification, renvoie à l'URL **http://iamhost:8000/event/1** un message non autorisé avec le code de statut "401 Unauthorized". Afin d'obtenir les résultats d'IRIS, nous devons ajouter le JWT à la requête. Par conséquent, nous devons d'abord demander le JWT au serveur d'autorisation. Le serveur d'autorisation personnalisé que nous utilisons ici renvoie un JWT si une demande POST est faite avec quelques paires clé-valeur dans le corps, y compris des informations sur l'utilisateur et le client, à l'URL suivante : **https://authorizationserver:5001/auth** Voici à quoi ressemblent cette requête et sa réponse : Ensuite, vous pouvez ajouter le JWT obtenu à partir de la réponse ci-dessous dans le header d'autorisation en tant que jeton de porteur Bearer Token et envoyer une requête GET à la même URL utilisée précédemment : **http://iamhost:8000/event/1** Vous pouvez également l'ajouter en tant que paramètre de chaîne de recherche, la clé de la chaîne de recherche étant la valeur spécifiée dans le champ "config.uri\_param\_names" lors de l'ajout du plugin JWT qui, dans ce cas, est "jwt" : Enfin, il y a aussi la possibilité d'inclure JWT dans la requête en tant que cookie, si un nom est saisi dans le champ "config.cookie_names". Passez à la troisième et dernière partie de cette série pour comprendre les configurations nécessaires pour générer un jeton d'accès IAM et le valider, ainsi que quelques considérations finales importantes.

Dans cette série d'articles en trois parties, il est montré comment vous pouvez utiliser IAM pour ajouter simplement de la sécurité, selon les normes OAuth 2.0, à un service précédemment non authentifié déployé dans IRIS. Dans la [première partie](https://fr.community.intersystems.com/post/s%C3%A9curisation-de-vos-api-avec-oauth-20-dans-le-cadre-de-la-gestion-des-api-dintersystems-partie), nous avons fourni des informations sur OAuth 2.0 ainsi que des définitions et des configurations initiales d'IRIS et d'IAM afin de faciliter la compréhension de l'ensemble du processus de sécurisation de vos services. La [deuxième partie](https://fr.community.intersystems.com/post/s%C3%A9curisation-de-vos-api-avec-oauth-20-dans-le-cadre-de-la-gestion-des-api-dintersystems-0) discute et montre en détail les étapes nécessaires pour configurer IAM pour valider le jeton d'accès présent dans la demande entrante et transmettre la demande au backend si la validation réussit. Cette dernière partie de cette série abordera et démontrera les configurations nécessaires pour que IAM génère un jeton d'accès (agissant comme un serveur d'autorisation) et le valide, ainsi que quelques considérations finales importantes. Si vous voulez essayer IAM, veuillez contacter votre représentant commercial d'InterSystems. Scénario 2 : IAM comme serveur d'autorisation et validateur de jetons d'accès Dans ce scénario, contrairement au premier scénario, nous allons utiliser un plugin appelé "OAuth 2.0 Authentication". Afin d'utiliser IAM comme serveur d'autorisation dans ce flux d'informations d'identification du propriétaire des ressources et du mot de passe, le nom d'utilisateur et le mot de passe doivent être authentifiés par l'application cliente. La demande d'obtention du jeton d'accès auprès d'IAM ne doit être effectuée que si l'authentification est réussie. Commençons par l'ajouter à notre "SampleIRISService". Comme vous pouvez le voir dans la capture d'écran ci-dessous, nous avons différents champs à remplir afin de configurer ce plugin. Tout d'abord, nous allons copier l'identifiant de notre service "SampleIRISService" dans le champ "service_id" pour activer ce plugin à notre service. Dans le champ "config.auth\_header\_name", nous allons spécifier le nom de l'en-tête qui portera le jeton d'autorisation. Dans ce cas, je vais laisser la valeur par défaut comme "authorization". Le plugin "OAuth 2.0 Authentication" prend en charge les flux OAuth 2.0 Authorization Code Grant, Client Credentials, Implicit Grant ou Resource Owner Password Credentials Grant (respectivement, Attribution de codes d'autorisation, Identifiants client, Attribution implicite et Attribution des informations d'identification du mot de passe du propriétaire de la ressource OAuth 2.0). Comme nous utilisons dans cet article le flux "Resource Owner Password Credentials" (Identifiants du mot de passe du propriétaire de la ressource), nous allons cocher la case "config.enable\_password\_grant".. Dans le champ "config.provision_key", saisissez une chaîne à utiliser comme clé de provision. Cette valeur sera utilisée pour demander un jeton d'accès à IAM. Dans ce cas, j'ai laissé tous les autres champs avec la valeur par défaut. Vous pouvez vérifier la référence complète de chaque champ dans la documentation du plugin disponible [ici](https://docs.intersystems.com/iris20193/csp/docbook/apimgr/plugins/oauth2.html). Voici à quoi ressemble la configuration du plugin à la fin : Une fois le plugin créé, nous devons créer les informations d'identification de notre consommateur "ClientApp". Pour ce faire, allez dans "Consumers" dans le menu de gauche et cliquez sur "ClientApp". Ensuite, cliquez sur l'onglet "Credentials" et ensuite sur le bouton "New OAuth 2.0 Application". Sur la page suivante, entrez un nom quelconque pour identifier votre application dans le champ "name" (nom), définissez un identifiant et un secret de client, respectivement, dans les champs "client\_id" et "client\_secret" et enfin, entrez l'URL dans votre application où les utilisateurs seront envoyés après autorisation dans le champ "redirect_uri". Ensuite, cliquez sur "Create" (créer). Maintenant, vous êtes prêt à envoyer des demandes. La première requête que nous devons faire est d'obtenir le jeton d'accès depuis IAM. Le plugin "OAuth 2.0 Authentication" crée automatiquement un point de terminaison en ajoutant le chemin "/oauth2/token" à l'itinéraire déjà créé. Note: Assurez-vous que vous utilisez le protocole HTTPS et que le port proxy d'IAM prête attention aux requêtes TLS/SSL (le port par défaut est 8443). Il s'agit d'une exigence d'OAuth 2.0. Par conséquent, dans ce cas, nous devrions faire une demande POST à l'URL : **https://iamhost:8443/event/oauth2/token** Dans le corps de la requête, vous devez inclure le JSON suivant : {    "client_id": "clientid",    "client_secret": "clientsecret",    "grant_type": "password",    "provision_key": "provisionkey",    "authenticated_userid": "1" }   Comme vous pouvez le constater, ce JSON contient des valeurs définies à la fois lors de la création du plugin "OAuth 2.0 Authentication", telles que "grant\_type" et "provision\_key", et lors de la création des informations d'identification du Consommateur, telles que "client\_id" et "client\_secret". Le paramètre "authenticated_userid" doit également être ajouté par l'application client lorsque le nom d'utilisateur et le mot de passe fournis sont authentifiés avec succès. Sa valeur doit être utilisée pour identifier de manière unique l'utilisateur authentifié. La demande et sa réponse respective devraient ressembler à ceci :   Avec cela, nous pouvons maintenant faire une requête pour obtenir les données de l'événement en incluant la valeur "access_token" de la réponse ci-dessus comme "Bearer Token" (jeton de porteur) dans une requête GET vers l'URL **https://iamhost:8443/event/1** Si votre jeton d'accès expire, vous pouvez générer un nouveau jeton d'accès en utilisant le jeton de renouvellement que vous avez reçu avec le jeton d'accès expiré en effectuant une requête POST vers le même point de terminaison que celui utilisé pour obtenir un jeton d'accès, avec un corps quelque peu différent : {    "client_id": "clientid",    "client_secret": "clientsecret",    "grant_type": "refresh_token",    "refresh_token": "E50m6Yd9xWy6lybgo3DOvu5ktZTjzkwF" }   La demande et sa réponse respective devraient ressembler à ceci : Une fonctionnalité intéressante du plugin "OAuth 2.0 Authentication" est la possibilité d'afficher et d'invalider les jetons d'accès. Pour répertorier les tokens, envoyez une requête GET au point de terminaison suivant de l'API d'administration d'IAM : **https://iamhost:8444/{workspace\_name}/oauth2\_tokens** où {workspace_name} est le nom de l'espace de travail IAM utilisé. Veillez à saisir les informations d'identification nécessaires pour appeler l'API d'administration d'IAM si vous avez activé RBAC. Notez que "credential\_id" est l'identifiant de l'application OAuth que nous avons créée dans le consommateur ClientApp (dans ce cas, elle s'appelle SampleApp), et "service\_id" est l'identifiant de notre "SampleIRISService" auquel ce plugin est appliqué. Pour invalider un jeton, vous pouvez envoyer une demande DELETE au point de terminaison suivant **https://iamhost:8444/Sample/oauth2\_tokens/{token\_id}** où {token_id} est l'identifiant du jeton à invalider. Si nous essayons d'utiliser le jeton invalidé, nous obtenons un message indiquant que le jeton est invalide ou a expiré si nous envoyons une requête GET contenant ce jeton invalidé comme jeton porteur à l'URL : **https://iamhost:8443/event/1** Considérations finales Dans cet article, nous avons montré comment vous pouvez ajouter l'authentification OAuth 2.0 dans IAM à un service non authentifié déployé dans IRIS. Vous devez tenir compte du fait que le service lui-même continuera à être non authentifié dans IRIS. Par conséquent, si quelqu'un appelle directement le point de terminaison du service IRIS, en contournant la couche IAM, il pourra voir les informations sans aucune authentification. Pour cette raison, il est important d'avoir des règles de sécurité au niveau du réseau pour empêcher les demandes non désirées de contourner la couche IAM. Vous pouvez en savoir plus sur IAM [ici](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=AIAM). Si vous voulez essayer IAM, veuillez contacter votre représentant commercial d'InterSystems.

Salut la communauté, Nous sommes ravis d'annoncer que les webinaires de la communauté sont de retour ! Laissez-nous vous inviter tous au webinaire de @Ron.Sweeney1582 sur la mise à l'échelle du serveur FHIR InterSystems sur Amazon Web Services avec ECP. Rejoignez ce webinaire pour faire une plongée technique approfondie, voir une démonstration et évaluer le serveur InterSystems FHIR de mise à l'échelle horizontale sur Amazon Web Services avec Enterprise Cache Protocol (ECP). ⏱ Date et heure : jeudi 18 août, 8h00 HE | 14h00 CEST👨‍🏫 Speaker: @Ron.Sweeney1582, Full Stack Architect à Integration Required L'info sur Integration Required : Nous sommes une équipe de livraison technique complète pour vos charges de travail InterSystems®, adaptée à répondre aux exigences de votre posture de sécurité et des normes de déploiement organisationnelles. Avec une décennie de partenariats avec InterSystems® et une adhésion rigoureuse à la satisfaction de la clientèle, on nous fait confiance pour les meilleures pratiques. Alors... Ne manquez pas cette occasion d'en savoir plus sur la mise à l'échelle de FHIR, ECP et AWS et sur la façon de tout mélanger ! >> ENREGISTREZ-VOUS ICI <<

Salut les développeurs ! Nous avons souvent besoin de déployer des données en même temps que des morceaux de code de l'application. Et pour les développeurs d'InterSystems IRIS, la question peut se poser comme suit : "Comment puis-je déployer les données que j'ai dans les globales ?" Je vous propose ici l'une des approches suivantes : le déploiement de données globales à l'aide du gestionnaire de paquet ZPM package manager. **Exportation de données globales** Supposons que vous avez le serveur de base de données IRIS où vous avez une globale que vous voulez déployer. Le gestionnaire de paquets ZPM peut déployer des fichiers, vous devez donc exporter votre globale dans un fichier et construire le paquet avec ce fichier. ZPM peut déployer des globales au format XML, donc nous devons d'abord exporter une globale dans un fichier XML. Par exemple, si la globale que vous devez exporter a le nom "DataD", la commande suivante dans le terminal IRIS exportera la globale DataD dans un fichier XML : d $System.OBJ.Export("DataD.GBL","/irisrun/repo/data/DataD.xml") **Comment se présente la ressource** Pour compiler le paquet avec une globale, nous devons introduire certains éléments de ressource dans le module XML comme par exemple : <Resource Name="DataD.GBL"/> Consultez l'exemple dans la documentation. Remarquez que cet élément de ressource cherchera le fichier DataD.XML, et non DataD.GBL comme vous pourriez vous y attendre. Et ZPM cherchera le fichier DataD.XML dans le dossier /gbl à l'intérieur du dossier indiqué dans l'élément . Exemple Voici un exemple de dépôt iris-dataset-countries qui contient un paquet qui déploie les globales avec les données sur différents pays. Voici module XML: <?xml version="1.0" encoding="UTF-8"?> <Export generator="Cache" version="25"> <Document name="dataset-countries.ZPM"> <Module> <Name>dataset-countries</Name> <Description>Module imports the data of Country passengers in dc.data.Tinanic class</Description> <Version>1.0.0</Version> <Packaging>module</Packaging> <SourcesRoot>src</SourcesRoot> <Resource Name="dc.data.Country.CLS"/> <Resource Name="dc.data.CountryD.GBL"/> </Module> </Document> </Export> Et nous pouvions voir la ressource : <Resource Name="dc.data.CountryD.GBL"/> Qui est située dans le fichier du dépôt /src/gbl/dc.data.CountryD.XML: Ainsi, Lorsque le ZPM charge le module dans IRIS, il importe le global conformément au module.xml. Vous pouvez tester l'installation de la globale (et de la classe qui lui permet de faire des requêtes) avec : USER>zpm "install dataset-countries" Vous pouvez également jouer avec l'emballage global avec les ensembles de données Countries ou Titanic.

Bonjour les développeurs! Souvent, lorsque nous développons une bibliothèque, un outil, un package, quel qu’il soit dans InterSystems ObjectScript, nous avons une question, comment pouvons-nous déployer ce package sur la machine cible ? De plus, nous attendons souvent d’autres bibliothèques déjà installées, donc notre paquet dépend d’elles, et souvent d’une version spécifique de celui-ci. Lors de l’encodage javascript, python, etc., le rôle de l’implémentation de packages de gestion des dépendances nécessite un gestionnaire de paquets. C’est pourquoi j’ai le plaisir de vous annoncer que InterSystems ObjectScript Package Manager est disponible ! ATTENTION, ATTENTION ! Clause de non-responsabilité officielle. Le serveur InterSystems ObjectScript Package Manager situé sur le pm.community.intersystems.com et le client objectscript intersystems package manager installé à partir de pm.community.intersystems.com ou Github ne sont pas pris en charge par InterSystems Corporation et sont présentés sous licence MIT. Utilisez-le, développez-le, contribuez-y à vos risques et périls. Comment cela fonctionne-t-il ? Le gestionnaire de package ObjectScript intersystème se compose de deux parties. Il existe un serveur Gestionnaire de package qui héberge les packages ObjectScript et expose l’API pour que les clients ZPM déploient et répertorient les packages. Aujourd’hui, nous avons un serveur Developers Community Package Manager disponible dans pm.community.intersystems.com. Vous pouvez installer n’importe quel paquet dans InterSystems IRIS via le client ZPM installé en premier sur le système IRIS. Comment utiliser InterSystems Package Manager ? 1. Consultez la liste des forfaits disponibles Ouvrez https://pm.community.intersystems.com/packages/-/all pour voir la liste des packages actuellement disponibles. [{"name »:"analyzethis »,"versions »:"1.1.1"}},{"name »:"deepseebuttons,""versions »:"0.1.7"},{"name »:"dsw »,"versions »:"Versions »:""2.1.35"},{"namefoods »:"hole,""versions »:"0.1.0"},{"name »:"isc-dev »,"versions »:"1.2.0"}"},{"name »:"mdx2json »,"versions »:"2.2.0"},{"name »:"objectscript,""versions »:"1.0.0"]},{"name »:"pivotsubscriptions »,"versions »:""versions »:"1.0.0"},{"name »:"pivotsubscriptions,""versions »:"1.0.0"}},{"name pivotsubscriptions,""" » Versions »:"1.0.0"}}{"name »:"pivings »,"vers »:"vers »:"1.0.0"}},{"subscription pivots »,"versions »:"1.0.00.0.3"},{"name »:"restforms »,"versions »:"1.6.1"}},{"name »:"thirdpartychartportlets »,"versions »:""0.0.1"}},{"name »:"webterminal »,"versions »:"4.8.3"},{"name »:"zpm »,"versions »:"0.0.6"]}} Chaque package a le nom et la version. Si vous souhaitez en installer un dans InterSystems IRIS, vous devez d’abord installer le client ObjectScript InterSystems Package Manager, alias ZPM. 2. Installez le gestionnaire de package client Obtenez le lancement du client ZPM à partir du serveur ZPM : https://pm.community.intersystems.com/packages/zpm/latest/installer Il s’agit du package ObjectScript en XML, il peut donc être installé en important des classes via le portail de gestion ou par terminal : USER>Do $System.OBJ.Load(« /votrechemin/zpm.xml"ck ») une fois installé, il peut être appelé n’importe quel espace d’espaces de noms, car il s’installe dans %SYS en tant que package z. 3. Travailler avec le client ZPM Le client Zpm dispose d’une interface cli. Appelez zpm dans n’importe quel espace de noms tel que : UTILISATEUR>zpm zpm : UTILISATEUR> Appelez pour voir la liste de toutes les commandes disponibles. Consultez la liste des paquets actuellement disponibles sur le serveur ZPM (pm.community.intersystems.com) : zpm: USER>repo -list-modules -n record deepseebuttons 0.1.7 DSW 2.1.35 Holefoods 0.1.0 ISC-Dev 1.2.0 MDX2JSON 2.2.0 ObjectScript 1...0 0.0 PivotSubscriptions 0.0.3 Façons de se reposer 1.6.1 Troisième Artportletes 0.0.1 WebTerminal 4.8.3 ZPM 0.0.6 Installation d’un package Pour installer l’appel de package Installer la version du nom du package Cela installera le package avec toutes les dépendances. Vous pouvez omettre la version pour obtenir le dernier package. Voici comment installer la dernière version du terminal Web : zpm: USER> installer webterminal Comment savoir ce qui est déjà installé ? Commande de liste d’appels : zpm:USER> list 0,0,6 zpm 4.8.3 Terminal Web Désinstaller le package zpm : UTILISATEUR> désinstaller webterminal Plates-formes de données InterSystems prises en charge Actuellement, ZPM prend en charge IRIS et InterSystems IRIS for Health intersystems. Je veux que mon package soit répertorié dans le Gestionnaire de package Vous pouvez. Les exigences sont les suivantes : Le code devrait fonctionner chez InterSystems IRIS Vous devez avoir .xml module à la racine. Module.xml est le fichier qui décrit la structure du package et ce que vous devez configurer dans la phase de déploiement. Exemples de modules.xml peuvent être très simples, par exemple. Exemple de ObjectScript Ou relativement simple: BI Samples (anciennement HoleFoods), Web Terminal Module avec dépendances : DeepSee Web s’attend à ce que MDX2JSON soit installé et est décrit dans le module.xml:DeepSeeWeb Si vous souhaitez que votre demande soit répertoriée dans le rapport Community Package Manager, veuillez commenter ce post ou dm. Collaboration et soutien Le code source du serveur ZPM n’est pas disponible actuellement et le sera bientôt. Le code source du client ZPM est disponible ici et est actuellement pris en charge par la communauté des développeurs InterSystems et n’est pas pris en charge par InterSystems Corporation. Vous êtes invités à présenter des problèmes et à retirer des demandes. Script La feuille de route actuelle est la suivante : introduire un support d’échange ouvert, introduire l’automatisation pour la mise à jour et le téléchargement des paquets; serveur ZPM open source. Restez à l’écoute et développez vos packages InterSystems ObjectScript chez InterSystems IRIS ! Découvrez l’application connexe sur InterSystems Open Exchange Aller à l’article original écrit par @Evgeny Shvarov

Résumé des alertes Alert ID Produit et versions concernés Exigences explicites DP-439207 Plateforme de données InterSystems IRIS® 2024.3 (AIX) Installations AIX utilisant le traitement JSON et les caractères Unicode non-Latin-1 DP-439280 InterSystems IRIS 2024.3 (conteneurs avec IntegratedML) Conteneurs IntegratedML utilisant TensorFlow Détail des alertes DP-439207 - Problème d'analyse JSON Unicode AIX Un bug a été identifié dans InterSystems IRIS 2024.3.0 sur les instances AIX. Il affecte l'analyse des chaînes JSON Unicode. Ce problème survient lorsque la méthode %FromJSON() ou %FromJSONFile() analyse des chaînes contenant des caractères dont la valeur est inférieure à $CHAR(256) suivis de caractères Unicode dont la valeur est supérieure à $CHAR(255). Le processus de conversion transforme incorrectement les premiers caractères en $CHAR(0), ce qui entraîne une corruption silencieuse des données. Ce problème concerne uniquement la version AIX 2024.3 des produits suivants : InterSystems IRIS InterSystems IRIS for Health HealthShare® Health Connect Évaluation d'impact Dans ce cas, des caractères incorrects peuvent être stockés dans la base de données ou transmis aux interfaces sans générer d'erreur. Le défaut a été introduit dans IRIS 2024.3.0 et a été résolu avec DP-439207. Workflows concernés : Ce problème se produit uniquement sur les installations Unicode exécutant AIX et affecte les applications traitant des données contenant un mélange de caractères ASCII et Unicode. Résolution Si vous utilisez InterSystems IRIS 2024.3.0 sur des instances AIX, vous devez effectuer la mise à niveau vers InterSystems IRIS 2025.1.0 dès que possible. Actions requises Identification des systèmes concernés : Déterminez si vous exécutez InterSystems IRIS 2024.3.0 sur une instance AIX avec des bases de données Unicode et si vous utilisez un mélange de caractères Unicode et non Unicode. Mise à niveau : Procédez à la mise à niveau vers InterSystems IRIS 2025.1.0 dès que possible. DP-439280 - Problèmes TensorFlow du conteneur IntegratedML Les clients utilisant l'une des versions conteneurisées suivantes d'IRIS 2024.3 peuvent rencontrer des erreurs d'apprentissage lors de l'utilisation d'IntegratedML. containers.intersystems.com/intersystems/iris-ml:2024.3 Évaluation d'impact Les clients utilisant IntegratedML sur les conteneurs IRIS 2024.3 fournis par InterSystems rencontreront des échecs d'apprentissage du modèle en raison de problèmes de compatibilité avec TensorFlow et les dépendances associées. Résolution Les clients souhaitant utiliser IntegratedML avec IRIS ou IRIS for Health dans des conteneurs sont encouragés à créer leurs propres conteneurs en suivant les conseils publiés sur la communauté des développeurs. Actions requises par le client Pour continuer à utiliser IntegratedML avec AutoML, les clients doivent gérer manuellement les dépendances à l'aide du gestionnaire de paquets pip, comme décrit ci-dessus. Cela garantit la compatibilité et le bon fonctionnement des composants AutoML tels que scikit-learn dans votre environnement Python IntegratedML. Pour plus d'informations Si vous avez des questions ou avez besoin d'aide, veuillez contacter le InterSystems Worldwide Response Center (WRC).