Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Résoudre les problèmes liés au flux de travail Cette section décrit les solutions possibles aux problèmes liés aux flux de travail gérés. **Topics** + [Résoudre les problèmes liés aux flux de travail gérés](#workflow-errors) + [Résoudre les problèmes de déchiffrement du flux de travail](#workflows-decrypt-issues) ## Résoudre les problèmes liés aux flux de travail gérés Cette section décrit les solutions possibles aux problèmes de flux de travail suivants. **Topics** + [Résoudre les erreurs liées au flux de travail à l'aide d'Amazon CloudWatch](#workflows-cloudwatch-errors) + [Résoudre les erreurs de copie du flux de travail](#source-bucket-region) ### Résoudre les erreurs liées au flux de travail à l'aide d'Amazon CloudWatch **Description** Si vous rencontrez des problèmes avec vos flux de travail, vous pouvez utiliser Amazon CloudWatch pour en rechercher la cause. **Cause** Il peut y avoir plusieurs causes. Utilisez Amazon CloudWatch Logs pour effectuer des recherches. **Solution** Transfer Family transmet le statut d'exécution du flux de travail dans CloudWatch Logs. Les types d'erreurs de flux de travail suivants peuvent apparaître dans CloudWatch les journaux : + `"type": "StepErrored"` + `"type": "ExecutionErrored"` + `"type": "ExecutionThrottled"` + `"Service failure on starting workflow"` Vous pouvez filtrer les journaux d'exécution de votre flux de travail à l'aide de différentes syntaxes de filtre et de modèle. Par exemple, vous pouvez créer un filtre de journal dans vos CloudWatch journaux pour capturer les journaux d'exécution du flux de travail contenant le **ExecutionErrored**message. Pour plus de détails, consultez les [Real-time sections Traitement des données de journal avec les abonnements](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions.html) et [Syntaxe des filtres et](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html) des modèles dans le *guide de l'utilisateur Amazon CloudWatch Logs*. *StepErrored* ``` 2021-10-29T12:57:26.272-05:00 {"type":"StepErrored","details":{"errorType":"BAD_REQUEST","errorMessage":"Cannot tag Efs file","stepType":"TAG","stepName":"successful_tag_step"}, "workflowId":"w-abcdef01234567890","executionId":"1234abcd-56ef-78gh-90ij-1234klmno567", "transferDetails":{"serverId":"s-1234567890abcdef0","username":"lhr","sessionId":"1234567890abcdef0"} ``` Ici, `StepErrored` indique qu'une étape du flux de travail a généré une erreur. Dans un seul flux de travail, vous pouvez configurer plusieurs étapes. Cette erreur vous indique à quelle étape l'erreur s'est produite et affiche un message d'erreur. Dans cet exemple particulier, l'étape a été configurée pour étiqueter un fichier ; toutefois, le balisage d'un fichier dans un système de fichiers Amazon EFS n'est pas pris en charge, de sorte que l'étape a généré une erreur. *ExecutionErrored* ``` 2021-10-29T12:57:26.618-05:00 {"type":"ExecutionErrored","details":{},"workflowId":"w-w-abcdef01234567890", "executionId":"1234abcd-56ef-78gh-90ij-1234klmno567","transferDetails":{"serverId":"s-1234567890abcdef0", "username":"lhr","sessionId":"1234567890abcdef0"}} ``` Lorsqu'un flux de travail ne peut exécuter aucune étape, il génère un `ExecutionErrored` message. Par exemple, si vous avez configuré une seule étape dans un flux de travail donné et si l'étape ne peut pas s'exécuter, le flux de travail global échoue. *Exécution limitée* L'exécution est limitée si un flux de travail est déclenché à un rythme supérieur à celui que le système peut supporter. Ce message de journal indique que vous devez ralentir le taux d'exécution des flux de travail. [Si vous ne parvenez pas à réduire le taux d'exécution de votre flux de travail, contactez Contact AWS Support . AWS](https://aws.amazon.com/contact-us) *Défaillance du service au démarrage du flux de travail* Chaque fois que vous supprimez un flux de travail d'un serveur et que vous le remplacez par un nouveau, ou que vous mettez à jour la configuration du serveur (ce qui a un impact sur le rôle d'exécution d'un flux de travail), vous devez attendre environ 10 minutes avant d'exécuter le nouveau flux de travail. Le serveur Transfer Family met en cache les détails du flux de travail et met 10 minutes au serveur pour actualiser son cache. En outre, vous devez vous déconnecter de toutes les sessions SFTP actives, puis vous reconnecter après la période d'attente de 10 minutes pour voir les modifications. ### Résoudre les erreurs de copie du flux de travail **Description** Si vous exécutez un flux de travail contenant une étape permettant de copier le fichier chargé, le message d'erreur suivant peut s'afficher : ``` { "type": "StepErrored", "details": { "errorType": "BAD_REQUEST", "errorMessage": "Bad Request (Service: Amazon S3; Status Code: 400; Error Code: 400 Bad Request; Request ID: {{request-ID}}; S3 Extended Request ID: {{request-ID}} Proxy: null)", "stepType": "COPY", "stepName": "{{copy-step-name}}" }, "workflowId": "{{workflow-ID}}", "executionId": "{{execution-ID}}", "transferDetails": { "serverId": "{{server-ID}}", "username": "{{user-name}}", "sessionId": "{{session-ID}}" } } ``` **Cause** Le fichier source se trouve dans un compartiment Amazon S3 qui se trouve dans un compartiment différent Région AWS de celui de destination. **Solution** Si vous exécutez un flux de travail qui inclut une étape de copie, assurez-vous que les compartiments source et de destination se trouvent dans les mêmes Région AWS compartiments. ## Résoudre les problèmes de déchiffrement du flux de travail Cette section décrit les solutions possibles aux problèmes suivants liés aux flux de travail chiffrés. **Topics** + [Résoudre les problèmes de chiffrement des destinataires anonymes](#workflows-decrypt-anonymous) + [Résolution d'une erreur liée au fichier de chiffrement signé](#workflows-decrypt-signed) + [Résolution d'une erreur liée à un algorithme FIPS](#workflows-decrypt-fips) ### Résoudre les problèmes de chiffrement des destinataires anonymes **Description** Votre flux de déchiffrement échoue lors du traitement de certains fichiers chiffrés, mais fonctionne avec d'autres. **Cause** Les fichiers peuvent avoir été chiffrés sans spécifier de destinataire (chiffrement anonyme), ce qui complique la tâche du flux de travail lorsqu'il s'agit de déterminer la clé à utiliser pour le déchiffrement. **Solution** Chiffrez toujours les fichiers dont le destinataire n'est pas anonyme à l'aide de ce `-r` paramètre. Par exemple : ``` gpg -e -r {{user@example.com}} --openpgp file.txt ``` Pour vérifier si un fichier a été crypté auprès d'un destinataire spécifique ou de manière anonyme, utilisez la `--list-packets` commande suivante : ``` gpg --list-packets file.txt.gpg ``` Cette commande affiche la structure des paquets du GPG-encrypted fichier sans déchiffrer son contenu. Recherchez une sortie qui inclut des informations sur le destinataire, telles que : ``` :pubkey enc packet: version 3, algo 1, keyid 1A2B3C4D5E6F7G8H ``` Si vous voyez des informations d'identification de clé, le fichier a été crypté pour un destinataire spécifique. Si ces informations sont manquantes, le fichier a peut-être été chiffré de manière anonyme, ce qui peut entraîner des échecs de déchiffrement dans les flux de travail de Transfer Family. Vous pouvez également utiliser cette commande pour vérifier : + Quels algorithmes de chiffrement ont été utilisés + Méthodes de compression (le cas échéant) + Horodatages de création Pour consulter la liste des algorithmes de chiffrement pris en charge pour votre installation GPG, utilisez : ``` gpg --version ``` Ces informations peuvent vous aider à vous assurer que vous utilisez des algorithmes de chiffrement compatibles avec les flux de travail Transfer Family, en particulier lorsque la conformité à la norme FIPS est requise. ### Résolution d'une erreur liée au fichier de chiffrement signé **Description** Votre flux de déchiffrement échoue et le message d'erreur suivant s'affiche : ``` "Encrypted file with signed message unsupported" ``` **Cause** Transfer Family ne prend actuellement pas en charge la signature de fichiers chiffrés. **Solution** Dans votre client PGP, s'il existe une option permettant de signer le fichier chiffré, assurez-vous de désactiver cette option, car Transfer Family ne prend actuellement pas en charge la signature pour les fichiers chiffrés. ### Résolution d'une erreur liée à un algorithme FIPS **Description** Votre flux de déchiffrement échoue et le message du journal ressemble au suivant : ``` { "type": "StepErrored", "details": { "errorType": "BAD_REQUEST", "errorMessage": "File encryption algorithm not supported with FIPS mode enabled.", "stepType": "DECRYPT", "stepName": "{{step-name}}" }, "workflowId": "{{workflow-ID}}", "executionId": "{{execution-ID}}", "transferDetails": { "serverId": "{{server-ID}}", "username": "{{user-name}}", "sessionId": "{{session-ID}}" } } ``` **Cause** Le mode FIPS est activé sur votre serveur Transfer Family et dispose d'une étape de flux de travail de déchiffrement associée. Lorsque vous chiffrez les fichiers avant de les télécharger sur votre serveur Transfer Family, le client de chiffrement peut générer des fichiers chiffrés utilisant des algorithmes de chiffrement symétriques non approuvés par la norme FIPS. Dans un tel scénario, le flux de travail n'est pas en mesure de déchiffrer les fichiers. Dans l'exemple suivant, la version 2.4.0 de **GnuPG** utilise l'OCB (un mode de chiffrement par blocs non FIPS) pour chiffrer des fichiers : cela entraîne l'échec du flux de travail. **Solution** Vous devez modifier la clé GPG que vous avez utilisée pour chiffrer vos fichiers, puis les rechiffrer. La procédure suivante décrit les étapes à suivre. **Pour modifier vos clés PGP** 1. Identifiez la clé que vous devez modifier en exécutant `gpg ‐‐list-keys` Cela renvoie une liste de clés. Les détails de chaque clé sont similaires aux suivants : ``` pub ed25519 2022-07-07 [SC] wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY uid [ultimate] Mary Major sub cv25519 2022-07-07 [E] ``` 1. Identifiez la clé que vous souhaitez modifier. Dans l'exemple présenté à l'étape précédente, l'ID est`wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`. 1. Exécutez `gpg ‐‐edit-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`. Le système répond en fournissant des détails sur le programme **GnuPG** et la clé spécifiée. 1. À l'`gpg>`invite, entrez`showpref`. Les informations suivantes sont renvoyées : ``` [ultimate] (1). Mary Major Cipher: AES256, AES192, AES, 3DES AEAD: OCB Digest: SHA512, SHA384, SHA256, SHA224, SHA1 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, AEAD, Keyserver no-modify ``` Notez que les algorithmes préférés enregistrés sur la clé sont répertoriés. 1. Nous voulons modifier la clé pour conserver tous les algorithmes à l'exception de l'**OCB**. Exécutez la `setpref` commande en spécifiant tous les algorithmes à conserver : ``` gpg> setpref AES256, AES192,AES,3DES,SHA512, SHA384, SHA256, SHA224, SHA1,ZLIB, BZIP2, ZIP, Uncompressed ``` Cela renvoie les informations suivantes : ``` Set preference list to: Cipher: AES256, AES192, AES, 3DES AEAD: Digest: SHA512, SHA384, SHA256, SHA224, SHA1 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify Really update the preferences? (y/N) ``` 1. Entrez `y` pour effectuer la mise à jour, puis entrez votre mot de passe lorsque vous êtes invité à confirmer la modification. 1. Enregistrez les Modifications. ``` gpg> save ``` Avant de réexécuter votre flux de travail de déchiffrement, vous devez rechiffrer vos fichiers à l'aide de la clé modifiée.