Ce guide décrit la nouvelle console d'administration AWS Wickr, publiée le 13 mars 2025. Pour obtenir de la documentation sur la version classique de la console d'administration AWS Wickr, consultez le Guide d'administration classique.

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.

Chiffrement au repos

Le service de conservation des données AWS Wickr chiffre de manière transparente tous les messages et pièces jointes conservés au repos par défaut. Vous n'avez pas besoin d'effectuer de configuration supplémentaire pour vous assurer que vos données sont chiffrées au repos. Le service de conservation des données applique le chiffrement côté serveur à toutes les données clients stockées dans Amazon S3.

Le service de conservation des données chiffre les données clients au repos à l'aide d'une clé KMS gérée par le client (CMK). Lorsque vous déployez le service de conservation des données via AWS Service Catalog, une clé CMK symétrique est automatiquement créée dans votre compte et configurée comme clé de chiffrement par défaut pour toutes les données conservées. Vous conservez le contrôle total de cette clé, y compris la possibilité d'auditer l'utilisation, de faire pivoter la clé et de révoquer l'accès.

Chiffrement des données au repos à l'aide de clés KMS gérées par le client pour la conservation des données

Comment le service de conservation des données utilise une clé KMS gérée par le client

Lorsque le service de conservation des données est déployé, une clé KMS symétrique gérée par le client (RetentionKey) est créée dans votre AWS compte. Cette clé est utilisée pour chiffrer les ressources suivantes :

Cross-account architecture des rôles

Le service de conservation des données fonctionne sur un Wickr-managed AWS compte et accède aux ressources des clients via un rôle IAM multicompte (). DRSCustomerCrossAccountRole-{networkId}-{region} Le rôle Wickr DRS Enclave assume ce rôle côté client en utilisant AWS STS un ID externe (wickr-drs-{networkId}) pour effectuer des opérations KMS et S3.

Attestation Nitro Enclave

kms:DecryptLes appels directs (en dehors de S3 SSE-KMS) nécessitent une attestation Nitro Enclave. La politique des clés KMS impose que les kms:RecipientAttestation:PCR2 conditions et kms:RecipientAttestation:PCR0kms:RecipientAttestation:PCR1, soient présentes, garantissant que le déchiffrement des données sensibles (état du compte, contenu du message) ne peut avoir lieu qu'à l'intérieur de l'enclave vérifiée. Cela empêche tout opérateur, y compris Wickr, de déchiffrer les données des clients en dehors de l'enclave.

AWS Nitro Enclaves traite les messages à l'aide de votre clé KMS pour déchiffrer les clés privées du module de conservation des données, déchiffrer le contenu du Wickr-encrypted message et le rechiffrer avec une clé de données unique par message avant de le stocker dans votre compartiment S3.

Configuration des clés KMS gérées par le client dans le service de rétention des données

Le service de conservation des données prend en charge les clés KMS symétriques avec leur utilisation ENCRYPT_DECRYPT et leurs spécificationsSYMMETRIC_DEFAULT. La rotation automatique des clés est activée par défaut lorsque la clé est créée via Service Catalog.

En outre, une deuxième clé KMS asymétrique (ECC_NIST_P384, KEY_AGREEMENT) est créée pour le flux de travail de récupération du mot de passe. Cette clé est utilisée pour l'accord de clé de l'ECDH et ne peut pas être utilisée à des fins générales encryption/decryption. Cette clé est éventuellement utilisée pour les clients qui migrent depuis une architecture basée sur Docker Data Retention Bot.

Configuration des autorisations pour utiliser une clé KMS gérée par le client

La politique clé suivante est automatiquement configurée lors du déploiement via Service Catalog. Si vous devez configurer manuellement une clé, appliquez la politique de moindre privilège suivante :

{
  "Version": "2012-10-17", 
  "Statement": [
    {
      "Sid": "YourExistingStatements",
      "Effect": "...",
      "...": "..."
    },
    {
      "Sid": "EnclaveGenerateDataKey",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{customer-account-id}:role/DRSCustomerCrossAccountRole-{networkId}-{region}"
      },
      "Action": "kms:GenerateDataKey",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "kms:RecipientAttestation:PCR0": "*",
          "kms:RecipientAttestation:PCR1": "*",
          "kms:RecipientAttestation:PCR2": "*"
        },
        "ForAnyValue:StringEquals": {
          "kms:EncryptionContextKeys": [
            "aws:wickr:network:id",
            "aws:wickr:app:id"
          ]
        }
      }
    },
    {
      "Sid": "EnclaveDescribeKey",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{customer-account-id}:role/DRSCustomerCrossAccountRole-{networkId}-{region}"
      },
      "Action": "kms:DescribeKey",
      "Resource": "*"
    },
    {
      "Sid": "EnclaveDecryptWithAttestation",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{customer-account-id}:role/DRSCustomerCrossAccountRole-{networkId}-{region}"
      },
      "Action": "kms:Decrypt",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "kms:RecipientAttestation:PCR0": "*",
          "kms:RecipientAttestation:PCR1": "*",
          "kms:RecipientAttestation:PCR2": "*"
        },
        "ForAnyValue:StringEquals": {
          "kms:EncryptionContextKeys": "aws:wickr:app:id"
        }
      }
  },
    {
      "Sid": "DRSDecryptionLambda",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{customer-account-id}:role/{DecryptionLambdaRoleName}"
      },
      "Action": "kms:Decrypt",
      "Resource": "*",
      "Condition": {
        "ForAnyValue:StringEquals": {
          "kms:EncryptionContextKeys": "aws:wickr:network:id"
        }
      }
    }
  ]
}

Objectif de chaque déclaration :

Si une migration est requise depuis une installation de conservation des données précédente, vous devez fournir le mot de passe de votre Docker-bot module au service pour que la conservation des données sans serveur puisse être activée. Pour plus d'informations, voirInstructions pour récupérer le mot de passe. Pour plus de détails sur la politique requise pour votre clé de récupération de mot de passe, consultezConfiguration personnalisée de la clé KMS pour le service de conservation des données.

Si vous devez configurer manuellement la clé KMS, consultez la politique Configuration personnalisée de la clé KMS pour le service de conservation des données la moins permissive pour votre clé.

Création d'un nouveau déploiement de conservation des données avec une clé KMS gérée par le client

Le service de conservation des données est déployé via AWS Service Catalog. Lorsque vous lancez le WickrDataRetentionProduct produit, le CloudFormation modèle :

L'ARN de la clé KMS est également enregistré via le point de terminaison du SDK Wickr Admin :

PUT /networks/{networkId}/serverless-resources
{
  "s3BucketName": "wickr-drs-{networkId}-{region}-{suffix}",
  "kmsKeyArn": "arn:aws:kms:{region}:{accountId}:key/{keyId}",
  "passwordRecoveryKmsKeyArn": "arn:aws:kms:{region}:{accountId}:key/{keyId}"
}

Le kmsKeyArn paramètre doit être un ARN de clé KMS valide. L'API valide le format ARN avant de le stocker.

Modification de la configuration de chiffrement sur un déploiement existant

Le service de conservation des données ne prend actuellement pas en charge la modification de la clé CMK après le déploiement. La clé KMS est étroitement associée à :

Pour modifier la clé de chiffrement, vous devez :

Délimitation de l'accès à la clé KMS gérée par le client

Attestation Nitro Enclave (contrôle d'accès principal)

Le principal mécanisme permettant de délimiter l'accès au CMK est l'attestation Nitro Enclave. La politique clé exige kms:RecipientAttestation:PCR0 et PCR2 conditionne les kms:Decrypt appels directs. PCR1 Cela garantit :

Protection adjointe confuse

Le rôle multi-comptes utilise un identifiant externe (wickr-drs-{networkId}) dans l'AssumeRoleappel STS. Cela permet d'éviter les attaques secondaires confuses dans lesquelles un autre service pourrait tenter d'utiliser le rôle d'enclave Wickr DRS pour accéder à vos ressources.

km : ViaService état

Les opérations de SSE-KMS déchiffrement S3 sont définies à l'aide de cette condition. kms:ViaService Cela garantit que S3-mediated le déchiffrement n'est autorisé que lorsque la demande passe par le service S3.

Contexte de chiffrement

S3 inclut SSE-KMS automatiquement l'ARN de l'objet S3 comme contexte de chiffrement. La politique des clés utilise ce contexte de chiffrement pour étendre les autorisations de déchiffrement S3 à des préfixes spécifiques (par exemple, le préfixe de l'outil de mot de passe).

Surveillance de l'interaction du service de conservation des données avec AWS KMS

Vous pouvez surveiller tous les appels d'API KMS effectués par le service de conservation des données à l'aide de CloudTrail. Pour rechercher des entrées de CloudTrail journal, utilisez la CloudTrail console ou l' CloudTrail LookupEventsopération.

Les champs CloudTrail d'événements suivants peuvent être utilisés pour vérifier l'utilisation du KMS par le service de conservation des données :

Principaux événements à surveiller :

En outre, le produit Service Catalog crée un CloudWatch tableau de bord (WickrDataRetentionService-{networkId}) qui inclut des widgets pour les indicateurs de réussite clés du KMS (opérations de chiffrement GenerateDataKey, de déchiffrement) et une alarme d'erreur de déchiffrement qui se déclenche lorsque des échecs de déchiffrement sont détectés.