Architecture de sécurité de l’adaptateur InterAct
La sécurité de la transmission et de la réception des messages est implémentée à l’aide des fonctionnalités de certificat et de chiffrement inhérentes à SWIFTNet Link (SNL) et à SWIFTAlliance Gateway (SAG). SWIFT recommande aux services conçus pour InterAct d’appliquer une signature « de bout en bout », c’est-à-dire de signer à la fois les messages de demande et de réponse.
Les opérations de chiffrement sont implémentées par le module de sécurité de SWIFTNet Link. Ce module autorise la signature et le chiffrement à l’aide de clés PKI. La nature et l’étendue des opérations de chiffrement sont spécifiées dans le cadre des structures de données Request et Response Control passées aux API.
SWIFTNet prend en charge la signature/chiffrement de RequestPayload ou ResponsePayload. Le RequestHeader ou ResponseHeader peut également être signé.
Signature/chiffrement des demandes et des réponses
Les règles d’application d’opérations de chiffrement sur les éléments de demande d’interact SWIFTNet sont les suivantes :
RequestControl : il est destiné uniquement à SWIFTNet. SWIFTNet fournit un RequestDescriptor au répondeur (et certains éléments également au demandeur). Par conséquent, aucune opération de chiffrement de processus client vers serveur ne peut être effectuée sur celle-ci.
RequestE2EControl : cet élément contient des informations pour garantir une messagerie fiable de bout en bout. Aucune opération de chiffrement ne peut être effectuée sur celui-ci.
RequestHeader : il est utilisé par SWIFTNet et transmis sans modification au répondeur. Par conséquent, cela ne peut être signé que.
RequestPayload : toutes les opérations de chiffrement peuvent être effectuées à ce sujet.
Élément(s) de chiffrement : ils concernent des opérations de chiffrement précédemment activées sur cette demande. Aucune opération de chiffrement ne peut être effectuée sur ces opérations.
Les règles d’application des fonctions de chiffrement sur les réponses SWIFTNet InterAct sont les suivantes :
ResponseControl : il est destiné uniquement à SWIFTNet. SWIFTNet fournit un ResponseDescriptor au demandeur. Par conséquent, aucune opération de chiffrement de processus serveur vers le client ne peut être effectuée sur celle-ci.
ResponseE2EControl : cet élément contient des informations pour garantir une messagerie fiable de bout en bout. Aucune opération de chiffrement ne peut être effectuée sur celui-ci.
ResponseHeader : cet élément peut être signé (il est transféré sans modification vers le demandeur).
ResponsePayload : peut être chiffré et/ou signé.
Élément(s) de chiffrement : ils concernent des opérations de chiffrement précédemment activées sur cette demande. Aucune opération de chiffrement ne peut être effectuée sur ces opérations.
Réception de requêtes avec chiffrement
Un processus serveur peut recevoir des requêtes qui ont été soumises à des opérations de chiffrement par le demandeur. La requête entrante contient toutes les informations pertinentes pour activer les opérations de chiffrement inverse. Les informations CryptoInternal sont telles que la fonction de déchiffrement et de vérification fonctionne désormais efficacement.
Le processus serveur doit activer les contextes de sécurité du nom de domaine pour lequel le déchiffrement doit avoir lieu
La demande sera ensuite modifiée par les opérations de chiffrement inverse (vérification, déchiffrement) de telle sorte que la demande d’origine soit rendue disponible sans modification pour le processus serveur, car elle a été remise à l’origine par le processus client aux opérations de chiffrement. Pour la réponse, un traitement similaire a lieu. Il est important de se rendre compte que la vérification d’une signature permet non seulement de vérifier que ce qui a été signé n’a pas été modifié, mais qu’elle authentifie si le signataire est authentique. Pour cela, signDN doit utiliser un certificat valide. Un certificat valide est qu’un certificat n’a pas été révoqué (une recherche dans la liste de révocation de certificat, conservée de manière centralisée dans SWIFTNet).
Activation
SWIFTNet Link peut effectuer la vérification et le déchiffrement en mode automatique pour toutes les demandes entrantes et les réponses entrantes. Cela signifie que SWIFTNet Link traite automatiquement (vérifier et déchiffrer) le dernier bloc de chiffrement de toutes les demandes entrantes (côté serveur) ou les réponses entrantes (côté client). Les conditions préalables sont que le contexte de sécurité requis pour le déchiffrement (si le déchiffrement est demandé) soit ouvert et que SWIFTNet Link a été initialisé en mode automatique (ce paramètre en mode automatique est effectué sur Sw :InitRequest ou Sw :HandleInitResponse, en définissant le CryptoMode sur « Automatique » ou mieux encore « Avancé » pour InterAct. (Nous utiliserons toujours « Avancé » pour l’adaptateur InterAct, car cela permet à l’application cliente ou serveur de récupérer un chiffrement inattendu par le côté distant ou à partir d’un certificat expiré.
SWIFTNet Link opère la signature et le chiffrement automatiquement sur une requête sortante (ou une réponse sortante) si le champ RequestCrypto (ResponseCrypto) est initialisé sur « TRUE » dans le RequestControl (ResponseControl) de la requête (réponse).
Dans ce cas, SWIFTNet Link traite le dernier bloc de chiffrement. Les conditions préalables sont que le contexte de sécurité requis pour la signature (si la signature est demandée) soit ouvert, que le bloc de chiffrement soit présent dans la demande avec une indication sur la signature et le chiffrement requis, et que l’indicateur RequestCrypto (ResponseCrypto) soit défini sur « TRUE » dans le RequestControl (ResponseControl). Cela est toujours effectué, quel que soit le CryptoMode utilisé lors de l’initialisation du client ou du serveur.
Voir aussi
Architecture de l’adaptateur InterAct
Composants de l’adaptateur InterAct
Messages de l’adaptateur InterAct pour les échanges d’entreprise
Application cliente de l’adaptateur InterAct
Application serveur de l’adaptateur InterAct
Stockage et redirection de l’adaptateur InterAct
Remise fiable de bout en bout de l’adaptateur InterAct
Surveillance de l’état de l’adaptateur InterAct
Non-répudiation de l’adaptateur InterAct