Sécurité du moteur d’exécution
A4SWIFT La réparation des messages et la nouvelle soumission régissent le flux de messages SWIFT entre les utilisateurs professionnels, les systèmes principaux et les points de terminaison réseau SWIFT de manière sécurisée et déterministe. Il authentifie les messages envoyés par les utilisateurs professionnels, valide les messages pour l’exactitude des données et des règles métier, et achemine les messages vers les systèmes principaux ou pour une remise finale au réseau SWIFT. Pour plus d’informations sur les certificats numériques, consultez « Chiffrement et signature des certificats » sur le site Web MSDN Library à l’adresse https://go.microsoft.com/fwlink/?linkid=50285.
La réparation de message et la nouvelle soumission sont une application d’orchestration BizTalk Server, hébergée et exécutée dans le contexte de sécurité BizTalk Server. Il est sécurisé en tant qu’application BizTalk Server par les fonctionnalités de sécurité BizTalk Server décrites précédemment. La réparation des messages et la nouvelle soumission définissent et appliquent également des stratégies de sécurité au niveau de l’utilisateur spécifiques à la création, à la réparation, à l’approbation et à la soumission de messages SWIFT, comme suit :
Tous les messages, nouveaux ou réparés, envoyés à BizTalk Server par le biais de la réparation de message et de la nouvelle soumission doivent provenir d’un utilisateur approuvé.
Les utilisateurs approuvés qui créent ou réparent des messages doivent disposer de l’autorisation et des droits appropriés. Les utilisateurs approuvés qui approuvent ou rejettent des messages doivent disposer de l’autorisation et des droits appropriés.
Tous les messages doivent être approuvés par un nombre connu d’utilisateurs approuvés. Chaque utilisateur approuvé dans la chaîne du créateur, du réparateur et des approbateurs de messages doit être unique. Le même utilisateur ne peut pas créer, réparer, approuver ou rejeter un message. Le même utilisateur ne peut pas entrer plusieurs décisions d’approbation ou de rejet pour un seul message dans un processus d’approbation en plusieurs étapes. Vous ne pouvez pas approuver vos propres messages créés ou réparés, ni approuver le même message que plusieurs approbateurs.
Vous ne pouvez pas modifier un message pendant le processus d’approbation (autrement dit, un message ne peut pas être modifié après sa soumission d’origine à la réparation de messages et à la nouvelle soumission, en tant que message nouveau ou réparé).
Les messages modifiés lors d’une étape de vérification de nouvelle clé doivent correspondre exactement au message d’origine (créé ou réparé).
Pour appliquer cette sémantique de sécurité, la réparation des messages et la nouvelle soumission valident la signature numérique incorporée dans chaque message XML qu’elles reçoivent, à chaque étape du processus de création ou de réparation de soumission d’approbation. La validation de la signature numérique de réparation de message et nouvelle soumission effectue les vérifications suivantes. Si une ou plusieurs de ces vérifications échouent, la réparation des messages et la nouvelle soumission s’arrêtent et sont conservées via la boîte de message, et une erreur de sécurité est enregistrée dans le journal des événements :
Le message XML doit être signé numériquement et doit donc contenir une signature numérique correspondante.
Chaque signature numérique utilisée dans le flux de travail doit être effectuée à l’aide d’un certificat numérique approuvé. Cela garantit que le créateur de messages, le réparateur, le vérificateur et les approbateurs sont approuvés.
Chaque certificat numérique approuvé doit appartenir à un utilisateur de domaine Windows qui est membre du groupe de domaines disposant d’une autorité logique ou de droits pour effectuer des actions dans A4SWIFT. Cela garantit que chaque participant au processus de création ou de réparation-approbation-soumission dispose de l’autorité ou des droits appropriés pour effectuer l’action spécifique qu’il a effectuée.
Les règles précédentes sont appliquées via des listes de contrôle d’accès sur le site SharePoint via des groupes d’utilisateurs de site et par le biais du code d’envoi du formulaire. Si l’utilisateur agissant sur le message n’est pas dans le groupe A4SWIFT Utilisateurs (domaine ou local), la réparation de message et la nouvelle soumission rejettent le message.
Par exemple, un organization qui applique un processus d’approbation en trois phases peut définir ces trois rôles logiques : Réparateurs, Vérificateurs (phase Rekey) et Approbateurs. En conséquence, les utilisateurs participant aux rôles doivent appartenir au groupe de domaines Utilisateurs A4SWIFT. Pour verrouiller davantage le site SharePoint, les utilisateurs doivent être organisés en groupes de domaines logiques (tels que les réparateurs, les vérificateurs, les approbateurs).
Pour plus d’informations sur les groupes d’utilisateurs de site, consultez Windows SharePoint Services Sécurité.
Chaque signature numérique dans la pile doit être unique. Autrement dit, chaque signature numérique doit être effectuée à l’aide d’un certificat numérique unique (par rapport aux autres signatures de la même pile). Cela garantit que le message n’a pas été approuvé par la personne qui a créé/réparé le message et qu’aucune personne n’a approuvé le même message que plusieurs approbateurs.
La réparation des messages et la nouvelle soumission imposent des stratégies de sécurité strictes en ayant des points de contrôle à chaque point d’entrée dans l’infrastructure de création, de réparation, d’approbation et de soumission des messages. Ces points de contrôle sont étroitement associés aux fonctionnalités de base de la réparation des messages et de la nouvelle soumission et ne peuvent pas être contournés. Bien que la réparation des messages et la nouvelle soumission soient conçues pour s’intégrer en toute transparence à la fonctionnalité de signature de formulaire InfoPath, elles sont également conçues pour être suffisamment sécurisées et robustes pour appliquer l’authenticité et la protection des messages SWIFT même si InfoPath n’est pas utilisé et que les messages sont envoyés directement par les utilisateurs finaux aux points de terminaison de réparation de messages et de nouvelle soumission (dossiers Web SharePoint).