#SSL

TLS, qu'est-ce que c'est ?

La TLS (Transport Layer Security ou "Sécurité de la couche de transport"), qui succède à SSL (Secure Sockets Layer ou "Couche de sockets sécurisée"), fournit de la sécurité (c'est-à-dire le chiffrement et l'authentification) sur une connexion TCP/IP. Si vous avez déjà remarqué le "s" sur les URLs "https" vous avez reconnu une connexion HTTP "sécurisée" par SSL/TLS. Dans le passé, seules les pages de connexion/autorisation sur le web utilisaient TLS, mais dans l'environnement hostile d'Internet d'aujourd'hui, les meilleures pratiques indiquent que nous devrions sécuriser toutes les connexions avec TLS.

Pourquoi utiliser TLS?

Alors, pourquoi mettre en œuvre TLS pour les connexions HL7 ? Alors que les violations de données, les rançongiciels et les vulnérabilités sont de plus en plus fréquents, chaque mesure que vous prenez pour renforcer la sécurité de ces précieuses sources de données devient plus cruciale. La TLS est une méthode éprouvée et bien comprise pour protéger les données en transit.

TLS fournit deux fonctionnalités principales qui nous sont bénéfiques : 1) le chiffrement et 2) l'authentification.

Chiffrement

Le chiffrement transforme les données en cours de transfert de sorte que seules les deux parties engagées dans la communication peuvent lire/comprendre les informations échangées. Dans la plupart des cas, seules les applications impliquées dans la connexion TLS peuvent interpréter les données transférées. Cela signifie que les acteurs malveillants opérant sur les serveurs ou réseaux de communication ne pourront pas lire les données, même s'ils parviennent à capturer les paquets TCP bruts à l'aide d'un renifleur de paquets (wiretap, wireshark, tcpdump, etc.).

Authentification

L'authentification garantit que chaque partie communique avec la partie prévue et non avec un imposteur. En s'appuyant sur l'échange de certificats (et la vérification de la preuve de propriété associée qui s'est produite lors d'un handshake TLS), lorsque vous utilisez TLS, vous pouvez être sûr que vous échangez des données avec une partie de confiance. Plusieurs attaques consistent à tromper un serveur pour qu'il communique avec un acteur malveillant en redirigeant le trafic vers le mauvais serveur (par exemple, l'emploi de DNS et d'ARP poisoning) Lorsque TLS est impliqué, les imposteurs doivent non seulement rediriger le trafic, mais aussi voler les certificats et les clés appartenant à la partie de confiance.

L'authentification protège non seulement contre les attaques intentionnelles de pirates informatiques ou de acteurs malveillants, mais aussi contre les erreurs de configuration accidentelles qui pourraient envoyer des données vers le ou les mauvais systèmes. Par exemple, si vous attribuez accidentellement l'adresse IP d'une connexion HL7 à un serveur qui n'utilise pas le certificat attendu, la vérification de la négociation TLS échouera avant l'envoi de données vers ce mauvais serveur.

Vérification d'hôte

Lors de la vérification, les clients ont la possibilité d'effectuer une vérification d'hôte. Cette vérification compare l'adresse IP ou le nom d'hôte utilisé dans la connexion avec les adresses IP et les noms d'hôte intégrés dans le certificat. Si cette vérification est activée et que l'adresse IP/l'hôte de la connexion ne correspond pas à une adresse IP/un hôte figurant dans le certificat, le handshake TLS échouera. Vous trouverez les adresses IP et les noms d'hôte dans les champs X.509 « Subject » et « Subject Alternative Name » présentés ci-dessous.

Preuve de la propriété d'un certificat avec une clé privée

Pour prouver la propriété des certificats échangés avec TLS, vous devez également avoir accès à la clé privée liée à la clé publique intégrée au certificat. Nous ne discuterons pas de la cryptographie employée pour la preuve de propriété avec une clé privée, mais vous devez savoir que l'accès à la clé privée de votre certificat est nécessaire pendant le handshake TLS.

TLS mutuel

Pour la plupart des connexions https établies par votre navigateur web, seul le certificat d'authenticité du serveur web est vérifié. Normalement, les serveurs web n'authentifient pas le client avec des certificats. Au lieu de cela, la plupart des serveurs web s'appuient sur l'authentification du client au niveau de l'application (formulaires de connexion, cookies, mots de passe, etc.).

Avec HL7, il est préférable que les deux côtés de la connexion soient authentifiés. Lorsque les deux côtés sont authentifiés, on parle de «TLS mutuel». Avec le TLS mutuel, le serveur et le client échangent leurs certificats et l'autre côté vérifie les certificats fournis avant de poursuivre la connexion et l'échange de données.

X.509 Certificats

X.509 Champs du certificat

Pour fournir le cryptage et l'authentification, les informations sur la clé publique et l'identité de chaque partie sont échangées dans des certificats [X.509] (https://en.wikipedia.org/wiki/X.509). Vous trouverez ci-dessous certains champs courants d'un certificat X.509 qui nous intéresseront:

• Serial Number: numéro unique à un CA qui identifie ce certificat spécifique
• Subject Public Key Info: clé publique du propriétaire
• Subject: nom distinctif (DN) du serveur/service représenté par ce certificat
  • Ce champ peut être vide si des "Subject Alternative Names" (noms alternatifs du sujet) sont fournis.
• Issuer: nom distinctif (DN) du CA qui a émis/signé ce certifica
• Validity Not Before: date de mise en vigueur de ce certificat
• Validity Not After: date d'expiration de ce certificat
• Basic Constraints: indique s'il s'agit d'un CA ou non
• Key Usage: l'utilisation prévue de la clé publique fournie par ce certificat
  • Valeurs d'exemple: digitalSignature, contentCommitment, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly, decipherOnly
• Extended Key Usage: utilisations supplémentaires prévues de la clé publique fournie par ce certificat
  • Valeurs d'exemple: serverAuth, clientAuth, codeSigning, emailProtection, timeStamping, OCSPSigning, ipsecIKE, msCodeInd, msCodeCom, msCTLSign, msEFS
  • Pour les connexions TLS mutuelles, les deux modes d'utilisation serverAuth et clientAuth sont nécessaires.
• Subject Key Identifier: identifie la clé publique du sujet fournie par ce certificat
• Authority Key Identifier: identifie la clé publique du fournisseur utilisée pour vérifier ce certificat
• Subject Alternative Name: contient un ou plusieurs noms alternatifs pour ce sujet
  • Les noms DNS et les adresses IP sont des noms alternatifs fréquemment fournis dans ce champ.
  • Subject Alternative Name est parfois abrégé en SAN.
  • Le nom DNS ou l'adresse IP utilisés dans la connexion doivent figurer dans cette liste ou dans le Common Name du Subject pour que la vérification de l'hôte soit réussie.

Noms distingués

Les champs Subject (Sujet) et Issuer (Émetteur) d'un certificat X.509 sont définis comme des Distinguished Names (DN, Noms Distingués). Les noms distingués sont constitués de plusieurs attributs, chaque attribut ayant le format <attr>=<value>. Voici une liste non exhaustive des attributs courants que l'on trouve dans les champs Subject et Issuer

Selon les exemples du tableau ci-dessus, le DN complet pour cet exemple serait C=US, ST=Massachusetts, L=Cambridge, O=Best Corporation, OU=Finance, CN=server1.domain.com

Notez que le Common Name (nom commun) trouvé dans le Subject (sujet) est utilisé lors de la vérification de l'hôte et correspond normalement au nom de domaine complet (FQDN) du serveur ou du service associé au certificat. Les Subject Alternative Names (noms alternatifs du sujet) du certificat peuvent également être utilisés lors de la vérification de l'hôte.

Expiration du certificat

Les champs Validity Not Before (Validité avant la date) et Validity Not After (Validité après la date) du certificat fournissent une plage de dates entre lesquelles le certificat est valide

Normalement, les certificats feuille ont une validité d'un ou deux ans (bien que les sites Web soient encouragés à réduire leurs délais d'expiration à des périodes beaucoup plus courtes). Les autorités de certification ont généralement un délai d'expiration de plusieurs années.

L'expiration des certificats est une fonctionnalité TLS nécessaire mais peu pratique. Avant d'ajouter TLS à vos connexions HL7, assurez-vous d'avoir un plan pour remplacer les certificats avant leur expiration. Une fois qu'un certificat expire, vous ne pourrez plus établir de connexion TLS à l'aide de celui-ci.

Formats de certificat X.509

Les champs de ces certificats X.509 (ainsi que d'autres) sont structurés suivant le format ASN.1 et généralement enregistrés dans l'un des formats de fichier suivants :

• [DER] (https://en.wikipedia.org/wiki/Distinguished_Encoding_Rules) (format binaire)
• [PEM] (https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) (base64)

Exemple d'encodage PEM d'un certificat X.509:

-----BEGIN CERTIFICATE-----
MIIEVTCCAz2gAwIBAgIQMm4hDSrdNjwKZtu3NtAA9DANBgkqhkiG9w0BAQsFADA7
MQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMQww
CgYDVQQDEwNXUjIwHhcNMjUwMTIwMDgzNzU0WhcNMjUwNDE0MDgzNzUzWjAZMRcw
FQYDVQQDEw53d3cuZ29vZ2xlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IA
BDx/pIz8HwLWsWg16BG6YqeIYBGof9fn6z6QwQ2v6skSaJ9+0UaduP4J3K61Vn2v
US108M0Uo1R1PGkTvVlo+C+jggJAMIICPDAOBgNVHQ8BAf8EBAMCB4AwEwYDVR0l
BAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU3rId2EvtObeF
NL+Beadr56BlVZYwHwYDVR0jBBgwFoAU3hse7XkV1D43JMMhu+w0OW1CsjAwWAYI
KwYBBQUHAQEETDBKMCEGCCsGAQUFBzABhhVodHRwOi8vby5wa2kuZ29vZy93cjIw
JQYIKwYBBQUHMAKGGWh0dHA6Ly9pLnBraS5nb29nL3dyMi5jcnQwGQYDVR0RBBIw
EIIOd3d3Lmdvb2dsZS5jb20wEwYDVR0gBAwwCjAIBgZngQwBAgEwNgYDVR0fBC8w
LTAroCmgJ4YlaHR0cDovL2MucGtpLmdvb2cvd3IyLzlVVmJOMHc1RTZZLmNybDCC
AQMGCisGAQQB1nkCBAIEgfQEgfEA7wB2AE51oydcmhDDOFts1N8/Uusd8OCOG41p
wLH6ZLFimjnfAAABlIMTadcAAAQDAEcwRQIgf6SEH+xVO+nGDd0wHlOyVTbmCwUH
ADj7BJaSQDR1imsCIQDjJjt0NunwXS4IVp8BP0+1sx1BH6vaxgMFOATepoVlCwB1
AObSMWNAd4zBEEEG13G5zsHSQPaWhIb7uocyHf0eN45QAAABlIMTaeUAAAQDAEYw
RAIgBNtbWviWZQGIXLj6AIEoFKYQW4pmwjEfkQfB1txFV20CIHeouBJ1pYp6HY/n
3FqtzC34hFbgdMhhzosXRC8+9qfGMA0GCSqGSIb3DQEBCwUAA4IBAQCHB09Uz2gM
A/gRNfsyUYvFJ9J2lHCaUg/FT0OncW1WYqfnYjCxTlS6agVUPV7oIsLal52ZfYZU
lNZPu3r012S9C/gIAfdmnnpJEG7QmbDQZyjF7L59nEoJ80c/D3Rdk9iH45sFIdYK
USAO1VeH6O+kAtFN5/UYxyHJB5sDJ9Cl0Y1t91O1vZ4/PFdMv0HvlTA2nyCsGHu9
9PKS0tM1+uAT6/9abtqCBgojVp6/1jpx3sx3FqMtBSiB8QhsIiMa3X0Pu4t0HZ5j
YcAkxtIVpNJ8h50L/52PySJhW4gKm77xNCnAhAYCdX0sx76eKBxB4NqMdCR945HW
tDUHX+LWiuJX
-----END CERTIFICATE-----

Comme vous pouvez le voir, l'encodage PEM ajoute -----BEGIN CERTIFICATE----- et -----END CERTIFICATE----- aux données ASN.1 du certificat encodées en base64.

Établir la confiance avec les autorités de certification

Sur l'Internet ouvert, il serait impossible pour votre navigateur Web de connaître et de faire confiance au certificat de chaque site Web. Il y en a tout simplement trop! Pour contourner ce problème, votre navigateur Web délègue la confiance à un ensemble prédéterminé d'autorités de certification (AC). Les autorités de certification sont des entités qui vérifient qu'une personne demandant un certificat pour un site Web ou un domaine est bien propriétaire et responsable du serveur, du domaine ou des activités commerciales associés à la demande de certificat. Une fois que l'autorité de certification a vérifié un propriétaire, elle est en mesure d'émettre le certificat demandé.

Chaque autorité de certification est représentée par un ou plusieurs certificats X.509. Ces certificats CA sont utilisés pour signer tous les certificats émis par la CA. Si vous regardez dans le champ Issuer (Émetteur) d'un certificat X.509, vous trouverez une référence au certificat CA qui a créé et signé ce certificat.

Si un certificat est créé sans autorité de certification, il est appelé certificat auto-signé. Vous savez qu'un certificat est auto-signé si les champs Subject (Sujet) et Issuer (Émetteur) du certificat sont identiques.

En général, la CA crée un certificat root (racine) auto-signé avec une longue fenêtre d'expiration. Ce certificat racine est ensuite utilisé pour générer quelques autorités de certification intermédiaires, qui ont une fenêtre d'expiration légèrement plus courte. La CA racine sera sécurisée et rarement utilisée après la création des CA intermédiaires. Les CA intermédiaires seront utilisées pour émettre et signer les certificats leaf (feuille) au quotidien.

Les CA intermédiaires sont créées au lieu d'utiliser directement la CA racine afin de minimiser l'impact en cas de violation ou de mauvaise gestion d'un certificat. Si une seule CA intermédiaire est compromise, l'entreprise aura toujours les autres CA disponibles pour continuer à fournir le service.

Chaînes de certificats

Un certificat de connexion et tous les certificats CA impliqués dans l'émission et la signature de ce certificat peuvent être organisés en une structure appelée chaîne de certificats. Cette chaîne de certificats (décrite ci-dessous) sera utilisée pour vérifier et approuver le certificat de connexion.

Si vous suivez le certificat feuille d'une connexion jusqu'à la CA émettrice (en utilisant le champ Issuer) puis, à partir de cette CA, jusqu'à son émetteur (et ainsi de suite, jusqu'à ce que vous atteigniez un certificat racine auto-signé), vous aurez parcouru la chaîne de certificats.

Faire confiance à un certificat

Votre navigateur Web et votre système d'exploitation conservent généralement une liste d'autorités de certification approuvées. Lors de la configuration d'une interface HL7 ou d'une autre application, vous dirigerez probablement votre interface vers un fichier CA-bundle contenant une liste de CA approuvées. Ce fichier contiendra généralement une liste d'un ou plusieurs certificats CA encodés au format PEM. Par exemple:

# Probablement, une CA intermédiaire
-----BEGIN CERTIFICATE-----
MIIDQTCCAimgAwIBAgITBmyfz5m/jAo54vB4ikPmljZbyjANBgkqhkiG9w0BAQsF
...
rqXRfboQnoZsG4q5WTP468SQvvG5
-----END CERTIFICATE-----

# Probablement, une CA racine
-----BEGIN CERTIFICATE-----
MIIDqDCCApCgAwIBAgIJAP7c4wEPyUj/MA0GCSqGSIb3DQEBBQUAMDQxCzAJBgNV
...
WyH8EZE0vkHve52Xdf+XlcCWWC/qu0bXu+TZLg==
-----END CERTIFICATE-----

Lorsque votre navigateur Web (ou l'interface HL7) tente d'établir une connexion TLS, il utilise cette liste de certificats CA de confiance pour déterminer s'il fait confiance au certificat échangé lors du handshake TLS.

Le processus commence par le certificat racine et traverse la chaîne de certificats jusqu'au certificat CA suivant. Si le certificat CA n'est pas trouvé dans le magasin de confiance ou le fichier CA-bundle, le certificat racine n'est pas considéré comme fiable et la connexion TLS échoue.

Si le certificat CA ou le fichier CA-bundle est trouvé dans le magasin de confiance, le processus continue en remontant la chaîne de certificats, en vérifiant que chaque CA se trouvant sur le chemin est dans le magasin de confiance. Une fois que le certificat CA racine au sommet de la chaîne est vérifié (ainsi que tous les certificats CA intermédiaires se trouvant sur le chemin), le processus peut approuver le certificat feuille du serveur.

Le handshake TLS

Pour ajouter TLS à une connexion TCP/IP (comme un flux HL7), le client et le serveur doivent effectuer un handshake TLS après que la connexion TCP/IP a été établie. Ce handshake implique de s'accorder sur les chiffrements/méthodes de chiffrement, de s'accorder sur la version TLS, d'échanger des certificats X.509, de prouver la propriété de ces certificats et de valider que chaque partie fait confiance à l'autre.

Les étapes principales d'un handshake TLS sont les suivantes:

1. Le client établit une connexion TCP/IP avec le serveur.
2. Le client lance le handshake TLS.
3. Le serveur envoie son certificat (et la preuve de sa propriété) au client.
4. Le client vérifie le certificat du serveur.
5. En cas de TLS mutuel, le client envoie son certificat (et la preuve de sa propriété) au serveur.
6. En cas de TLS mutuel, le serveur vérifie le certificat du client.
7. Le client et le serveur s'échangent des données encryptées.

1. Le client établit une connexion TCP/IP avec le serveur.

À l'étape n° 1, le client et le serveur effectuent un handshake TCP à la procédure de base « ternaire » [TCP 3-way handshake] (https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment) pour établir une connexion TCP/IP entre eux. Dans un handshake à la procédure de base ternaire:

1. Le client envoie un paquet SYN.
2. Le serveur envoie un paquet SYN-ACK.
3. Le client envoie un paquet ACK.

Une fois ce handshake terminé, la connexion TCP/IP est établie. L'étape suivante consiste à lancer le handshake TLS.

2. Le client lance le handshake TLS.

Une fois la connexion TCP établie, l'une des parties doit agir en tant que client et lancer le handshake TLS. Généralement, le processus qui a initié la connexion TCP est également responsable du lancement du handshake TLS, mais cela peut être inversé dans de rares cas.

Pour lancer le handshake TLS, le client envoie un message ClientHello au serveur. Ce message contient diverses options utilisées pour négocier les paramètres de sécurité de la connexion avec le serveur.

3. Le serveur envoie son certificat (et la preuve de sa propriété) au client.

Après avoir reçu le message ClientHello du client, le serveur répond à son tour par un message ServerHello. Celui-ci inclut les paramètres de sécurité négociés.

Après le message ServerHello, le serveur envoie également un message Certificate et CertificateVerify au client. Cela permet de partager la chaîne de certificats X.509 avec le client et de fournir la preuve de propriété de la clé privée associée au certificat.

4. Le client vérifie le certificat du serveur.

Une fois que le client a reçu les messages ServerHello, Certificate et CertificateVerify, il vérifie que le certificat est valide et approuvé (en comparant les CAs aux fichiers CA-bundle approuvés, au magasin de certificats du système opérationnel ou au magasin de certificats du navigateur web). Le client effectue également toute vérification de l'hôte (voir ci-dessus) pour s'assurer que l'adresse de connexion correspond aux adresses/IP du certificat.

5. S'il s'agit d'une connexion TLS mutuelle, le client envoie son certificat (et la preuve de propriété) au serveur.

S'il s'agit d'une connexion TLS mutuelle (déterminée par l'envoi d'un message CertificateRequest par le serveur), le client enverra un message Certificate incluant sa chaîne de certificats, puis un message CertificateVerify pour prouver qu'il est le propriétaire de la clé privée associée.

6. S'il s'agit d'une connexion TLS mutuelle, le serveur vérifie le certificat client.

Là encore, s'il s'agit d'une connexion TLS mutuelle, le serveur vérifie que la chaîne de certificats envoyée par le client est valide et approuvée.

7. Le client et le serveur s'échangent des données encryptées.

Si la négociation TLS se déroule sans erreur, le client et le serveur s'échangent des messages Finished (Terminé) pour achever la négociation. Après cela, les données encryptées peuvent être échangées entre le client et le serveur.

Configuration de TLS sur les interfaces HL7

Félicitations d'être arrivé jusqu'ici ! Maintenant que vous savez en quoi consiste TLS, comment procéderiez-vous pour mettre en œuvre le protocole TLS sur vos connexions HL7 ? De manière générale, voici les étapes à suivre pour configurer TLS sur vos connexions HL7.

1. Choisissez une autorité de certification.
2. Créez une clé et une demande de signature de certificat.
3. Obtenez votre certificat auprès de votre CA.
4. Obtenez la chaîne de certificats pour votre pair.
5. Créez une configuration SSL pour la connexion.
6. Ajoutez la configuration SSL à l'interface, faites rebondir l'interface et vérifiez le flux de messages.

1. Choisissez une autorité de certification.

La procédure que vous utiliserez pour obtenir un certificat et une clé pour votre serveur dépendra largement des politiques de sécurité de votre entreprise. Dans la plupart des cas, votre certificat sera signé par l'une des autorités de certification suivantes:

1. Votre certificat sera signé par une CA interne à l'entreprise.

• C'est mon option préférée, car votre entreprise dispose déjà de l'infrastructure nécessaire pour gérer les certificats et les CAs. Il vous suffit de travailler avec l'équipe qui possède cette infrastructure pour obtenir votre propre certificat pour vos interfaces HL7.

2. Votre certificat sera signé par une CA publique.

• Cette option est intéressante dans le sens où la CA publique dispose également de toute l'infrastructure nécessaire pour maintenir les certificats et les CAs. Cette option est sans doute exagérée pour la plupart des interfaces HL7, car les CA publiques fournissent généralement des certificats pour l'Internet ouvert ; les interfaces HL7 ont tendance à se connecter via un intranet privé, et non via l'Internet public.
• L'obtention de certificats auprès d'une CA publique peut également entraîner des frai.

3. Votre certificat sera signé par une CA que vous créerez et maintiendrezvous-même.

• Cette option peut vous convenir, mais malheureusement, cela signifie que vous supportez la charge de la maintenance et de la sécurisation de votre configuration CA et de votre logiciel.
• Vous l'utilisez à vos risques et périls!
• Cette option est la plus complexe. Préparez-vous à une courbe d'apprentissage abrupte.
• Vous pouvez utiliser des progiciels open source éprouvés pour gérer votre CA et vos certificats. La suite OpenSSL est une excellente option. Les autres options sont EJBCA, step-ca et cfssl.

2. Créez une clé et une demande de signature de certificat.

Après avoir choisi votre CA, l'étape suivante consiste à créer une clé privée et une demande de signature de certificat (CSR) . La manière dont vous générez la clé et la CSR dépendra de la politique de votre entreprise et de la CA choisie. Pour l'instant, nous allons simplement parler des étapes de manière générale.

Lors de la génération d'une clé privée, la clé publique associée est également générée. La clé publique sera intégrée à votre CSR et à votre certificat signé. Ces deux clés seront utilisées pour prouver la propriété de votre certificat signé lors de l'établissement d'une connexion TLS.

ATTENTION! Veillez à enregistrer votre clé privée dans un endroit sûr (de préférence dans un format protégé par un mot de passe). Si vous perdez cette clé, votre certificat ne sera plus utilisable. Si quelqu'un d'autre accède à cette clé, il pourra se faire passer pour votre serveur.

La demande de signature de certificat inclura des informations sur votre serveur, votre entreprise, votre clé publique, la manière d'utiliser le certificat, etc. Elle inclura également la preuve que vous possédez la clé privée associée. Cette CSR sera ensuite fournie à votre CA pour générer et signer votre certificat.

REMARQUE: lors de la création de la CSR, assurez-vous de demander une Extended Key Usage (utilisation étendue de la clé) à la fois pour serverAuth et clientAuth, si vous utilisez le TLS mutuel. La plupart des CA sont habituées à signer des certificats avec uniquement la clé serverAuth. Malheureusement, cela signifie que le certificat ne peut pas être utilisé comme certificat client dans une connexion TLS mutuelle.

3. Obtenez votre certificat auprès de votre CA.

Après avoir créé votre clé et votre CSR, soumettez la CSR à votre autorité de certification. Après avoir effectué plusieurs vérifications, votre CA devrait être en mesure de vous fournir un certificat signé et la chaîne de certificats associée. Ce certificat et cette chaîne doivent être enregistrés au format PEM. Si la CA a fourni votre certificat dans un format différent, vous devrez le convertir à l'aide d'un outil tel qu'OpenSSL.

4. Obtenez la chaîne de certificats pour votre homologue.

Les étapes précédentes étaient axées sur l'obtention d'un certificat pour votre serveur. Vous devriez pouvoir utiliser ce certificat (et la clé associée) avec chaque connexion HL7 vers/depuis ce serveur. Vous devrez également obtenir les chaînes de certificats pour chacun des systèmes/homologues auxquels vous vous connecterez.

Les chaînes de certificats de chaque homologue devront être enregistrées dans un fichier au format PEM. Ce CA-bundle n'aura pas besoin de contenir les certificats feuille ; il doit uniquement contenir les certificats CA intermédiaires et racine.

Veillez à fournir à votre homologue un CA-bundle contenant vos CA intermédiaires et racine. Cela lui permettra de faire confiance à votre certificat lorsque vous établirez une connexion.

5. Créez une configuration SSL pour la connexion.

Dans Health Connect d'InterSystems, il vous faudra créer des configurations SSL client et serveur pour chaque système auquel votre serveur se connectera. Ces configurations SSL dirigeront vers le fichier CA-bundle du système associé et vers les fichiers clé et de certificat de votre serveur.

Les configurations SSL client sont utilisées lors des opérations pour lancer le handshake TLS. Les configurations SSL serveur sont utilisées sur les services pour répondre aux handshakes TLS. Si un système dispose à la fois de services entrants et de services sortants, il faudra configurer à la fois une configuration SSL client et une configuration SSL serveur pour ce système.

Pour créer une configuration SSL client:

1. Accédez à System Administration > Security > SSL/TLS Configurations (Administration système > Sécurité > Configurations SSL/TLS).
2. Appuyeze sur Create New Configuration (Créer une nouvelle configuration).
3. Donnez un Configuration Name (Nom de configuration) et une Description (Description) à votre configuration SSL.
4. Assurez-vous que votre configuration SSL est Enabled (Activée).
5. Choisissez Client comme Type.
6. Choisissez Require (Obligatoire) pour le champ Server certificate verification (Vérification du certificat serveur). Cela effectue une vérification de l'hôte sur la connexion.
7. Dirigez le champ File (Fichier) contenant le(s) certificat(s) CA de confiance vers le fichier CA-bundle contenant les CA intermédiaires et racines (au format PEM) du système auquel vous vous connectez.
8. Dirigez le champ File (Fichier) contenant le certificat de ce client vers le fichier contenant le certificat X.509 de votre serveur au format PEM.
9. Dirigez le champ File (Fichier) contenant la clé privée associée vers le fichier contenant la clé privée de votre certificat.
10. Le Private key type (type de clé privée) sera très probablement RSA (chiffrement RSA). Cela devrait correspondre au type de votre clé privée.
11. Si votre clé privée est protégée par un mot de passe (comme cela devrait être le cas), saisissez le mot de passe dans les champs Private key password (mot de passe de la clé privée) et Private key password (confirm) (confirmer le mot de passe de la clé privée).
12. Vous pouvez probablement laisser les autres champs à leurs valeurs par défaut.

Pour créer une configuration de serveur SSL:

1. Go to System Administration > Security > SSL/TLS Configurations.
2. Appuyeze sur Create New Configuration (Créer une nouvelle configuration).
3. Donnez un Configuration Name (Nom de configuration) et une Description (Description) à votre configuration SSL.
4. Assurez-vous que votre configuration SSL est Enabled (Activée).
5. Choisissez Server comme Type.
6. Choisissez Require (Obligatoire) pour le champ Client certificate verification (Vérification du certificat client). Cela permettra de s'assurer que le TLS mutuel est exécuté.
7. Dirigez File containing trusted Certificate Authority certificate(s) (Fichier contenant le(s) certificat(s) de l'autorité de certification de confiance) vers le fichier CA-bundle contenant les CA intermédiaires et racines (au format PEM) du système auquel vous vous connectez.
8. Dirigez File containing this server's certificate (Fichier contenant le certificat de ce serveur) vers le fichier contenant le certificat X.509 de votre serveur au format PEM.
9. Dirigez File containing associated private key (Fichier contenant la clé privée associée) vers le fichier contenant la clé privée de votre certificat.
10. Le Private key type (type de clé privée) sera très probablement RSA (chiffrement RSA). Cela devrait correspondre au type de votre clé privée.
11. Si votre clé privée est protégée par un mot de passe (comme cela devrait être le cas), saisissez le mot de passe dans les champs Private key password (mot de passe de la clé privée) et Private key password (confirm) (confirmer le mot de passe de la clé privée).
12. Vous pouvez probablement laisser les autres champs à leurs valeurs par défaut.

6. Ajoutez la configuration SSL à l'interface, relancez l'interface et vérifiez le flux de messages.

Une fois que vous avez créé les configurations SSL client et serveur, vous êtes prêt à activer TLS sur les interfaces. Pour chaque service ou opération, choisissez la configuration SSL associée dans le menu déroulant Connection Settings > SSL Configuration (Paramètres de connexion > Configuration SSL) qui se trouve dans l'onglet Settings (Paramètres) de l'interface.

Après avoir relancé l'interface, vous verrez la connexion se rétablir. Lorsqu'un nouveau message est transféré, un statut Completed (Terminé) indique que TLS fonctionne. Si TLS ne fonctionne pas, la connexion sera interrompue à chaque tentative de message.

Pour vous aider à déboguer les problèmes avec TLS, il se peut que vous ayez besoin d'utiliser des outils tels que tcpdump, Wireshark ou l'utilitaire s_client d'OpenSSL.

Conclusion

Nous avons fait une analyse très approfondie du sujet SSL/TLS. Il y a tellement d'autres informations qui n'ont pas été incluses dans cet article. J'espère que cet article vous a fourni un aperçu suffisant du fonctionnement de TLS pour que vous puissiez rechercher les détails et obtenir plus d'informations si nécessaire.

Si vous recherchez une ressource approfondie sur TLS, consultez le site Web d'Ivan Ristić, fiestyduck.com et son livre, Bulletproof TLS and PKI. J'ai trouvé que ce livre était une excellente ressource pour en savoir plus sur l'utilisation de TLS.

Mise à jour le 19 janvier 2023.

Bonjour à tous,

Je souhaite partager une petite méthode rapide que vous pouvez utiliser pour activer ssl avec un certificat auto-signé sur votre instance locale de développement d'IRIS/HealthShare. Cela vous permet de tester des fonctionnalités spécifiques à https telles que OAuth sans avoir à vous soucier d'un grand nombre de choses.

1. Installer OpenSSL

Windows     : Download from https://www.openssl.org or other built OpenSSL Binary. 

Debian Linux: $ sudo apt-get -y install openssl

RHEL        : $ sudo yum install openssl

Il y a environ un mois, j'ai commencé à travailler sur l'utilisation du logiciel Epic on FHIR.

Création d'une paires de clés publiques-privées

mkdir /home/ec2-user/path_to_key
openssl genrsa -out ./path_to_key/privatekey.pem 2048

Pour les applications back-end, vous pouvez exporter la clé publique vers un certificat X.509 encodé en base64 intitulé publickey509.pem à l'aide de la commande ci-dessous...

openssl req -new -x509 -key ./path_to_key/privatekey.pem -out ./path_to_key/publickey509.pem -subj '/CN=medbank'

où '/CN=medbank' est le nom du sujet (par exemple le nom de l'application) pour lequel la paire de clés est utilisée. Le nom du sujet n'a pas d'impact fonctionnel dans ce cas, mais il est nécessaire pour créer un certificat X.509.

Le logiciel Epic on FHIR est une ressource gratuite pour les développeurs qui créent des applications

J'ai enregistré mon application "medbank" afin d'obtenir un identifiant client J'ai supprimé les identifiants client et modifié l'URL du jeu JWK hors production (Non-Production JWK Set URL) afin de protéger l'adresse IP réelle.

La documentation d'Epic indique que votre application effectue une requête HTTP POST au point de terminaison OAuth 2.0 du serveur d'autorisation pour obtenir un jeton d'accès. J'ai essayé d'écrire du code, mais je n'ai jamais réussi à obtenir un jeton d'accès.

J'ai appelé le WRC InterSystems pour obtenir de l'aide.

Nous avons configuré un client OAuth2 en utilisant le type de certificat "JWT Authorization" et la "private key JWT" pour l'authentification.

Nous avons ensuite essayé de l'exécuter sur le terminal en utilisant IsAuthorized() et GetAccessTokenJWT(), mais la réponse a été "invalid client ID".

Quelques jours plus tard, nous avons vu que le grant_type était en fait supposé être client_credentials, nous avons donc changé pour utiliser cela en passant de GetAccessTokenJWT() à GetAccessTokenClient() et cela a fonctionné.

Je souhaiterais mettre en œuvre Epic sur FHIR en tant que cas d'utilisation pour les iris-http-calls

J'ai utilisé Docker pour déployer les iris-http-calls dans AWS.

sudo docker build --no-cache --progress=plain . -t oliverwilms/iris-http-calls 2>&1 | tee build.log
sudo docker run -d -p57700:52773 oliverwilms/iris-http-calls

J'ai copié des fichiers de clés privées et publiques avec un accès en lecture pour IRIS

chmod 644 privatekey.pem
sudo docker cp ./privatekey.pem container_name:/home/irisowner/dev/ 
sudo docker cp ./publickey509.pem container_name:/home/irisowner/dev/
chmod 600 privatekey.pem

J'ai créé des informations d'identification X509 dans IRIS

Set oX509Credentials = ##class(%SYS.X509Credentials).%New()
Set oX509Credentials.Alias = "medbank"
Set tSC = oX509Credentials.LoadCertificate("/home/irisowner/dev/publickey509.pem")
Do $System.Status.DisplayError(tSC)
Set tSC = oX509Credentials.LoadPrivateKey("/home/irisowner/dev/privatekey.pem")
Do $System.Status.DisplayError(tSC)
Set tSC = oX509Credentials.%Save()
Do $System.Status.DisplayError(tSC)

Configuration d'un client OAuth2

http://localhost:57700/csp/sys/sec/%25CSP.UI.Portal.OAuth2.Client.ServerList.zen

Cliquez sur Create Server Description (Créer une description de serveur)

Création de la description du serveur

https://fhir.epic.com/interconnect-fhir-oauth/oauth2

J'ai cliqué sur Annuler (Cancel) et je suis retourné à

http://localhost:57700/csp/sys/sec/%25CSP.UI.Portal.OAuth2.Client.ServerList.zen

Cliquez sur le lien Client Configurations (configuration des clients).

Création de la configuration des clients

Cliquez sur Create Client Configuration (Créer une configuration des clients)

Sous l'onglet General, indiquez le nom de l'application:

medbank

Choisissez le type de client: Confidential

Choisissez la configuration SSL

Sous l'URL de redirection du client, indiquez le nom de l'hôte

localhost

Port

57700

Décochez la case Use TLS/SSL

Sous Types de certificats requis, cochez la case d'informations d'identification du client "Client Credentials"

Sous Type d'authentification, choisissez clé privée JWT

Sous Algorithme de signature d'authentification, choisissez RS384

Remplissez le champ Audience

https://fhir.epic.com/interconnect-fhir-oauth/oauth2/token

Sous l'onglet JWT Settings (Paramètres JWT), cochez la case Create JWT Settings (Créer des paramètres JWT) à partir d'informations d'identification X509. Choisissez vos informations d'identification dans la liste déroulante. Dans la colonne de signature Signing de la ligne des algorithmes de jetons d'accès, choisissez RS384.

Sous l'onglet Client Credentials (Informations d'identification du client), j'ai copié l'identifiant client hors production que j'avais reçu du logiciel Epic on FHIR. Le code secret client est requis. Je l'ai rempli comme x.

Important: N'oubliez pas de cliquer sur Save (Enregistrer)

Salutations chers membres de la communauté !

J'ai récemment déployé une image IRIS for Health sur un Docker avec une image Webgateway préconfigurée et je suis tombé sur le problème des configurations SSL qui nous permettent de nous connecter à l'instance IRIS en utilisant HTTPS et en passant par notre Webgateway.

Jusqu'à présent, j'avais toujours déployé IRIS for Health avec une licence communautaire, sur laquelle le serveur Web privé était toujours installé, je n'avais donc besoin que de configurer la connexion Webgateway avec l'instance IRIS déployée :

Démarrage rapide des données SQL d'InterSystems Cloud dans Databricks

La mise en œuvre de Databricks en SQL d'InterSystems Cloud se compose de quatre parties.

• Obtention du certificat et du pilote JDBC Driver pour InterSystems IRIS
• Ajout d'un script d'initialisation et d'une bibliothèque externe à votre Cluster de calcul Databricks
• Obtention de données
• Placement des données

Téléchargement du certificat X.509/du pilote JDBC de Cloud SQL

Naviguez vers la page d'aperçu de votre déploiement, si vous n'avez pas activé de connexions externes, faites-le et téléchargez votre certificat et le pilote jdbc depuis la page d'aperçu.

J'ai utilisé intersystems-jdbc-3.8.4.jar et intersystems-jdbc-3.7.1.jar avec succès dans Databricks à partir de la distribution de pilotes Driver Distribution.

Script d'initialisation pour votre cluster Databricks

La façon la plus simple d'importer un ou plusieurs certificats CA personnalisés dans votre cluster Databricks est de créer un script d'initialisation qui ajoute la chaîne complète de certificats CA aux magasins de certificats par défaut SSL et Java de Linux, et définit la propriété REQUESTS_CA_BUNDLE. Collez le contenu du certificat X.509 que vous avez téléchargé dans le bloc supérieur du script suivant:

import_cloudsql_certficiate.sh

#!/bin/bash

cat << 'EOF' > /usr/local/share/ca-certificates/cloudsql.crt
-----BEGIN CERTIFICATE-----
<PASTE>
-----END CERTIFICATE-----
EOF
update-ca-certificates
PEM_FILE="/etc/ssl/certs/cloudsql.pem"
PASSWORD="changeit"
JAVA_HOME=$(readlink -f /usr/bin/java | sed "s:bin/java::")
KEYSTORE="$JAVA_HOME/lib/security/cacerts"
CERTS=$(grep 'END CERTIFICATE'$PEM_FILE| wc -l)
# Pour traiter plusieurs certificats avec keytool, vous devez extraire# chacun d'eux du fichier PEM et l'importer dans le KeyStore Java.for N in $(seq 0 $(($CERTS - 1))); do
ALIAS="$(basename $PEM_FILE)-$N"echo"Adding to keystore with alias:$ALIAS"
cat $PEM_FILE |
awk "n==$N { print }; /END CERTIFICATE/ { n++ }" |
keytool -noprompt -import -trustcacerts 

-alias$ALIAS -keystore $KEYSTORE -storepass $PASSWORDdoneecho"export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt" >> /databricks/spark/conf/spark-env.sh
echo"export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt" >> /databricks/spark/conf/spark-env.sh

Maintenant vous avez le script initial, téléchargez-le dans le catalogue Unity sur un Volume.

Une fois que le script est sur un volume, vous pouvez ajouter le script initial au cluster à partir du volume dans les propriétés avancées de votre cluster.

Ensuite, ajoutez le pilote/la bibliothèque intersystems jdbc au cluster...

...et démarrez ou redémarrez votre calcul.

Station Databricks - Entrée vers le Cloud SQL d'InterSystems IRIS

Créez un Notebook Python dans votre espace de travail, attachez-le à votre cluster et testez le glissement de données vers Databricks.  Sous le capot, Databricks va utiliser pySpark, si cela n'est pas immédiatement évident.

La construction du Dataframe Spark suivant est tout ce qu'il vous faut, vous pouvez récupérer vos informations de connexion à partir de la page d'aperçu comme auparavant.

df = (spark.read
  .format("jdbc")
  .option("url", "jdbc:IRIS://k8s-05868f04-a4909631-ac5e3e28ef-6d9f5cd5b3f7f100.elb.us-east-1.amazonaws.com:443/USER")
  .option("driver", "com.intersystems.jdbc.IRISDriver")
  .option("dbtable", "(SELECT name,category,review_point FROM SQLUser.scotch_reviews) AS temp_table;") 
  .option("user", "SQLAdmin")
  .option("password", "REDACTED")
  .option("driver", "com.intersystems.jdbc.IRISDriver")\
  .option("connection security level","10")\
  .option("sslConnection","true")\
  .load())
df.show()

Illustration de la production d'un dataframe à partir de données dans Cloud SQL... boom!

Station Databricks - Sortie du Cloud SQL d'InterSystems IRIS

Prenons maintenant ce que nous avons lu dans IRIS et écrivons-le avec Databricks. Si vous vous souvenez bien, nous n'avons lu que 3 champs dans notre cadre de données, nous allons donc les réécrire immédiatement et spécifier un mode "écraser".

df = (spark.read
  .format("jdbc")
  .option("url", "jdbc:IRIS://k8s-05868f04-a4909631-ac5e3e28ef-6d9f5cd5b3f7f100.elb.us-east-1.amazonaws.com:443/USER")
  .option("driver", "com.intersystems.jdbc.IRISDriver")
  .option("dbtable", "(SELECT TOP 3 name,category,review_point FROM SQLUser.scotch_reviews) AS temp_table;") 
  .option("user", "SQLAdmin")
  .option("password", "REDACTED")
  .option("driver", "com.intersystems.jdbc.IRISDriver")\
  .option("connection security level","10")\
  .option("sslConnection","true")\
  .load())
df.show()
mode = "overwrite"
properties = {
"user": "SQLAdmin",
"password": "REDACTED",
"driver": "com.intersystems.jdbc.IRISDriver",
"sslConnection": "true",
"connection security level": "10",
}
df.write.jdbc(url="jdbc:IRIS://k8s-05868f04-a4909631-ac5e3e28ef-6d9f5cd5b3f7f100.elb.us-east-1.amazonaws.com:443/USER", table="databricks_scotch_reviews", mode=mode, properties=properties)

Exécution du Notebook

 
Illustration des données dans le Cloud SQL d'InterSystems!

Les points à prendre en considération

• Par défaut, PySpark écrit les données en utilisant plusieurs tâches concurrentes, ce qui peut entraîner des écritures partielles si l'une des tâches échoue.
• Pour garantir que l'opération d'écriture est atomique et cohérente, vous pouvez configurer PySpark de manière à ce que les données soient écrites à l'aide d'une seule tâche (c'est-à-dire en définissant le nombre de partitions à 1) ou utiliser une fonctionnalité spécifique à IRIS, telle que les transactions.
• En outre, vous pouvez utiliser l'API DataFrame de PySpark pour effectuer des opérations de filtrage et d'agrégation avant de lire les données de la base de données, ce qui peut réduire la quantité de données à transférer sur le réseau.

Nous sommes ravis de continuer à déployer de nouvelles fonctionnalités dans InterSystems IRIS Cloud SQLInterSystems IRIS Cloud SQL, telles que la nouvelle capacité de recherche vectorielle Vector Search qui a été lancée pour la première fois avec InterSystems IRIS 2024.1. Le service Cloud SQL est un service en nuage qui offre précisément ce qui suit: l'accès SQL dans le cloud. Cela signifie que vous utiliserez des technologies de pilote standard telles que JDBC, ODBC et DB-API pour vous connecter à ce service et accéder à vos données. La documentation décrit en détail comment configurer les paramètres importants au niveau du pilote, mais ne présente pas les outils tiers spécifiques car, comme vous pouvez l'imaginer, il en existe un nombre infini.

Dans cet article, nous allons compléter cette documentation de référence avec des étapes plus détaillées pour un outil de visualisation de données tiers populaire que plusieurs de nos clients utilisent pour accéder aux données basées sur IRIS : Microsoft Power BI.

Étape 0: Création de votre déploiement

Tout d'abord, connectez-vous au portail des services Cloud Services Portal et créez un déploiement Cloud SQL. Il vous ne faut qu'une chose: cochez la case permettant d'activer les connexions externes. À part cela, tous les paramètres par défaut devraient fonctionner correctement.

Étape 1: Téléchargement du certificat

Afin de se connecter en toute sécurité, nous utiliserons des certificats pour crypter tout ce qui est envoyé sur le réseau. Vous pouvez télécharger le certificat à partir de la page des détails du déploiement en cliquant sur le bouton "Get X.509 certificate" (Obtenir un certificat X.509):

Nous devrons nous référer à ce certificat plus tard, il faudra donc l'enregistrer dans un répertoire approprié. Par exemple, j'utilise C:\Users\bdeboe\odbc\.

Étape 2: Création du fichier SSLDefs.ini

Pour savoir quels certificats et paramètres de cryptage utiliser, le pilote ODBC d'InterSystems recherche un fichier SSLDefs.ini, que nous allons créer ensuite. Par défaut, il recherche ce fichier dans  C:\Program Files (x86)\Common Files\InterSystems\IRIS, mais vous pouvez modifier cet emplacement à l'aide de la variable d'environnement ISC_SSLconfigurationsISC_SSLconfigurations. Pour conserver tous mes paramètres de configuration ensemble, j'ai défini cette variable à C:\Users\bdeboe\odbc\, le répertoire où j'ai également sauvegardé mon certificat.

Le fichier SSLDefs.ini doit contenir deux éléments pour qu'ODBC sache comment se connecter : une configuration de serveur et une configuration SSL. La configuration du serveur déclare simplement le nom de la configuration SSL à utiliser pour une combinaison particulière de nom d'hôte et de port, et la configuration SSL contient tous les détails nécessaires à l'établissement de la connexion cryptée. Il est donc facile de réutiliser une seule configuration SSL pour plusieurs serveurs. Voici le contenu de mon fichier SSLDefs.ini:

[My CloudSQL Server]
Address=k8s-da0bcd5e-a1b3a0c7-545df92ec8-2e44304cebef1543.elb.us-east-1.amazonaws.com
Port=443
SSLConfig=SampleSSLConfig
[SampleSSLConfig]
CAFile=
CertFile=C:\Users\bdeboe\odbc\certificateSQLaaS.pem
KeyFile=
Password=
KeyType=2
Protocols=28
CipherList=ALL:!aNULL:!eNULL:!EXP:!SSLv2
VerifyPeer=0
VerifyDepth=9

La première section contient la configuration du serveur auquel vous pouvez donner un nom de votre choix. Vous devrez modifier l'adresse pour qu'elle corresponde au nom d'hôte de votre déploiement Cloud SQL, qui peut être obtenu à partir de la page des détails du déploiement où vous avez téléchargé le certificat.

La deuxième section contient la configuration SSL, dont le nom doit correspondre à ce que vous avez spécifié pour SSLConfig dans la section de configuration du serveur. La valeurCertFile doit évidemment correspondre à l'endroit où vous avez sauvegardé votre certificat.

Pour plus de détails sur les autres paramètres, veuillez vous référer à la documentation complète sur les paramètres TLS.

Étape 3: Création du DSN de type ODBC

Power BI, comme la plupart des outils basés sur ODBC, fonctionne avec un DSN (Data Source Name), que vous enregistrez à l'aide d'un utilitaire Windows. Il suffit de cliquer sur l'icône Start (Démarrer) de Windows et de taper "ODBC", puis de cliquer sur "ODBC Data Sources (64 bit)" (Sources de données ODBC (64 bit)). Choisissez l'onglet "System DSN" (DSN du système) pour enregistrer une connexion à notre déploiement Cloud SQL. Si vous avez des installations locales d'InterSystems IRIS (j'en ai une douzaine à tout moment 😉), vous verrez que le programme d'installation a créé des entrées DSN par défaut pour:

Cliquez sur "Add..." (Ajouter...) pour créer un nouveau DSN, en choisissant un nom et en renseignant l'hôte, le port et l'espace de noms. J'enregistre habituellement mon nom d'utilisateur et mon mot de passe dans le DSN pour toute instance non productive (et nous en aurons besoin pour tester la connexion dans quelques instants), mais vous pouvez laisser ces champs vides et fournir ces informations d'identification plus tard. Le champ Nom du serveur SSL/TLS est quelque peu superflu (nous y travaillerons!).

 Ensuite, cliquez sur "Test Connection" (Tester la connexion) pour vérifier que tout fonctionne comme prévu. Vous devriez obtenir un message "Connectivity test completed successfully!" (Test de connectivité terminé avec succès). Si ce n'est pas le cas, vérifiez les étapes ci-dessus ou reportez-vous au Guide de dépannage. Un message d'erreur particulier peut vous laisser perplexe (en tout cas, il m'a laissé perplexe !): "No SSL config found in the registry or in ssldefs.ini" (Aucune configuration SSL trouvée dans le registre ou dans ssldefs.ini). Cette erreur signifie que le pilote ODBC n'a pas trouvé de correspondance pour votre combinaison nom d'hôte/port dans le fichier SSLDefs.ini. Comme votre nom d'hôte change à chaque fois que vous créez un nouveau déploiement, vous devrez mettre à jour ou ajouter les configurations de serveur pour chacun d'entre eux.

Étape 4: Connexion à partir de Power BI

Il est maintenant temps d'utiliser notre DSN ODBC pour extraire des données dans Power BI. Après avoir ouvert l'application, sélectionnez la commande "Get Data" (Obtenir des données) ou "Get data from other sources" (Obtenir des données à partir d'autres sources), et choisissez l'option ODBC:

Ensuite, choisissez le DSN que vous venez de créer dans la liste:

Dans l'écran suivant, vous pouvez indiquer votre nom d'utilisateur et votre mot de passe. Aucune propriété des informations d'identification supplémentaire n'est requise.

 Et c'est tout! Vous pouvez maintenant sélectionner les tables que vous souhaitez inclure dans vos rapports Power BI:

Comme vous l'avez probablement remarqué, toutes les étapes de cet article, à l'exception de la dernière, sont universelles pour la configuration ODBC, ce qui devrait vous permettre d'utiliser la plupart des outils basés sur ODBC. J'espère que cet article vous a permis d'avancer, et n'hésitez pas à ajouter vos propres trucs et astuces, ou à partager vos expériences sur la connexion à Cloud SQL. Notez également qu'il n'y a pratiquement rien ici, à part l'étape 0, qui soit spécifique à Cloud SQL, donc vous pouvez utiliser les mêmes étapes pour vous connecter à n'importe quelle instance IRIS qui nécessite des connexions cryptées.

Dans cet article, nous allons voir comment utiliser le service de messagerie instantanée WhatsApp depuis InterSystems IRIS pour envoyer des messages à différents destinataires. Pour ce faire, nous devons créer et configurer un compte dans Meta et configurer une opération métier pour envoyer les messages que nous souhaitons.

Examinons chacune de ces étapes plus en détail.

Créer un compte sur Meta

C'est peut-être le point le plus compliqué de toute la configuration, puisque nous devrons configurer une série de comptes jusqu'à ce que nous puissions avoir la fonctionnalité de messagerie.

Avec la sortie d'InterSystems IRIS Cloud SQL, nous recevons des questions plus fréquentes sur la manière d'établir des connexions sécurisées via JDBC et d'autres technologies de pilotes.

Bien que nous ayons une belle documentation générale et détaillée sur les technologies de pilote elles-mêmes, notre documentation ne va pas aussi loin pour décrire les outils clients individuels, tels que notre DBeaver préféré.

Dans cet article, nous décrirons les étapes pour créer une connexion sécurisée de DBeaver à votre déploiement Cloud SQL.