Configurer les informations d’identification et l’authentification du réseau CDN cdn-credentials-authentication

Le réseau de diffusion de contenu fourni par l’Adobe dispose de plusieurs fonctionnalités et services, dont certains dépendent des informations d’identification et de l’authentification afin d’assurer un niveau approprié de sécurité de l’entreprise. En déclarant des règles dans un fichier de configuration déployé à l’aide du pipeline de configuration Cloud Manager config, les clientspeuvent configurer, en libre-service, les éléments suivants :

  • La valeur d’en-tête HTTP X-AEM-Edge utilisée par le réseau de diffusion de contenu Adobe pour valider les requêtes provenant d’un réseau de diffusion de contenu géré par le client.
  • Jeton API utilisé pour purger les ressources dans le cache CDN.
  • Liste de combinaisons nom d’utilisateur/mot de passe pouvant accéder à un contenu restreint, en envoyant un formulaire d’authentification de base.

Chacune d’elles, y compris la syntaxe de configuration, est décrite dans sa propre section ci-dessous.

Il existe une section sur la façon de faire pivoter les clés, ce qui est une bonne pratique de sécurité.

Valeur d’en-tête HTTP CDN gérée par le client CDN-HTTP-value

Comme décrit dans la page CDN dans AEM as a Cloud Service, les clients peuvent choisir d’acheminer le trafic par le biais de leur propre CDN, qui est appelé le CDN client (également parfois appelé BYOCDN).

Dans le cadre de la configuration, le réseau de diffusion de contenu Adobe et le réseau de diffusion de contenu client doivent s’entendre sur une valeur de l’en-tête HTTP X-AEM-Edge-Key. Cette valeur est définie sur chaque requête, sur le réseau de diffusion de contenu client, avant d’être acheminée vers le réseau de diffusion de contenu Adobe, qui valide ensuite que la valeur est comme prévu, de sorte qu’il puisse faire confiance à d’autres en-têtes HTTP, y compris ceux qui aident à acheminer la demande vers l’origine AEM appropriée.

La valeur X-AEM-Edge-Key est référencée par les propriétés edgeKey1 et edgeKey2 dans un fichier nommé cdn.yaml ou similaire, quelque part sous un dossier de niveau supérieur config. Lisez Utilisation des pipelines de configuration pour plus d’informations sur la structure de dossiers et sur le déploiement de la configuration. La syntaxe est décrite dans l’exemple ci-dessous.

WARNING
Un accès direct sans X-AEM-Edge-Key correct sera refusé pour toutes les requêtes correspondant à la condition (dans l’exemple ci-dessous, cela signifie toutes les requêtes au niveau de publication). Si vous devez introduire progressivement l'authentification, reportez-vous à la section Migration en toute sécurité pour réduire le risque de trafic bloqué .
kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  authentication:
    authenticators:
      - name: edge-auth
        type: edge
        edgeKey1: ${{CDN_EDGEKEY_052824}}
        edgeKey2: ${{CDN_EDGEKEY_041425}}
    rules:
      - name: edge-auth-rule
        when: { reqProperty: tier, equals: "publish" }
        action:
          type: authenticate
          authenticator: edge-auth

Voir la section Utiliser les pipelines de configuration pour obtenir une description des propriétés situées au-dessus du nœud data. La valeur de la propriété kind doit être CDN et la propriété version doit être définie sur 1.

Pour plus d’informations, voir l’étape du tutoriel Configuration et déploiement de la règle CDN de validation d’en-tête HTTP .

Autres propriétés :

  • Noeud Data contenant un noeud authentication enfant.

  • Sous authentication, un noeud authenticators et un noeud rules, qui sont tous deux des tableaux.

  • Authentificateurs : vous permet de déclarer un type de jeton ou d’informations d’identification, qui dans ce cas est une clé de périphérie. Elle comprend les propriétés suivantes :

    • name : chaîne descriptive.
    • type - doit être edge.
    • edgeKey1 : valeur de la X-AEM-Edge-Key, qui doit référencer une variable d'environnement de type secret Cloud Manager. Pour le champ Service appliqué, sélectionnez Tous. Il est recommandé que la valeur (par exemple,${{CDN_EDGEKEY_052824}}) reflète le jour où elle a été ajoutée.
    • edgeKey2 : utilisé pour la rotation des secrets, qui est décrite dans la section de secrets tournants ci-dessous. Définissez-le de la même manière que edgeKey1. Au moins un des edgeKey1 et edgeKey2 doit être déclaré.
  • Règles : vous permet de déclarer quels authentificateurs doivent être utilisés et s’il s’agit du niveau de publication et/ou d’aperçu. Il comprend :

    • name : chaîne descriptive.
    • when - condition qui détermine quand la règle doit être évaluée, selon la syntaxe de l’article Règles de filtrage du trafic . En règle générale, il comprend une comparaison du niveau actuel (par exemple, publication) afin que tout le trafic en direct soit validé en tant que routage via le réseau de diffusion de contenu du client.
    • action : doit spécifier "authenticate", avec l’authentificateur prévu référencé.
NOTE
La clé Edge doit être configurée en tant que variable d’environnement Cloud Manager de type secretavant le déploiement de la configuration qui la référence. Il est recommandé d’utiliser une clé aléatoire unique d’une longueur minimale de 32 octets ; par exemple, la bibliothèque cryptographique Open SSL peut générer une clé aléatoire en exécutant la commande openssl rand -hex 32.

Migration sécurisée pour réduire le risque de trafic bloqué migrating-safely

Si votre site est déjà actif, soyez prudent lors de la migration vers le réseau de diffusion de contenu géré par le client, car une mauvaise configuration peut bloquer le trafic public. En effet, seules les demandes avec la valeur d’en-tête X-AEM-Edge-Key attendue seront acceptées par le réseau de diffusion de contenu Adobe. Une approche est recommandée lorsqu’une condition supplémentaire est temporairement incluse dans la règle d’authentification, ce qui la fait bloquer uniquement si un en-tête de test est inclus ou si un chemin d’accès est trouvé :

    - name: edge-auth-rule
        when:
          allOf:
            - { reqProperty: tier, equals: "publish" }
            - { reqHeader: x-edge-test, equals: "test" }
        action:
          type: authenticate
          authenticator: edge-auth
    - name: edge-auth-rule
        when:
          allOf:
            - { reqProperty: tier, equals: "publish" }
            - { reqProperty: path, like: "/test*" }
        action:
          type: authenticate
          authenticator: edge-auth

Le modèle de requête curl suivant peut être utilisé :

curl https://publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com -H "X-Forwarded-Host: example.com" -H "X-AEM-Edge-Key: <CONFIGURED_EDGE_KEY>" -H "x-edge-test: test"

Une fois le test réussi, la condition supplémentaire peut être supprimée et la configuration redéployée.

Purge du jeton API purge-API-token

Les clients peuvent purger le cache CDN à l’aide d’un jeton API de purge déclaré. Le jeton est déclaré dans un fichier nommé cdn.yaml ou similaire, quelque part sous un dossier de niveau supérieur config. Lisez Utilisation des pipelines de configuration pour plus d’informations sur la structure de dossiers et sur le déploiement de la configuration.

La syntaxe est décrite ci-dessous :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  authentication:
    authenticators:
       - name: purge-auth
         type: purge
         purgeKey1: ${{CDN_PURGEKEY_031224}}
         purgeKey2: ${{CDN_PURGEKEY_021225}}
    rules:
       - name: purge-auth-rule
         when: { reqProperty: tier, equals: "publish" }
         action:
           type: authenticate
           authenticator: purge-auth

Voir la section Utiliser les pipelines de configuration pour obtenir une description des propriétés situées au-dessus du nœud data. La valeur de la propriété kind doit être CDN et la propriété version doit être définie sur 1.

Autres propriétés :

  • Noeud data contenant un noeud authentication enfant.

  • Sous authentication, un noeud authenticators et un noeud rules, qui sont tous deux des tableaux.

  • Authentificateurs : vous permet de déclarer un type de jeton ou d’informations d’identification, qui dans ce cas est une clé de purge. Elle comprend les propriétés suivantes :

    • name : chaîne descriptive.
    • type : doit être purge.
    • purgeKey1 : sa valeur doit référencer une variable d’environnement de type secret Cloud Manager. Pour le champ Service appliqué, sélectionnez Tous. Il est recommandé que la valeur (par exemple, ${{CDN_PURGEKEY_031224}}) reflète le jour où elle a été ajoutée.
    • purgeKey2 : utilisé pour la rotation des secrets, qui est décrite dans la section Rotation des secrets ci-dessous. Au moins un des purgeKey1 et purgeKey2 doit être déclaré.
  • Règles : vous permet de déclarer quels authentificateurs doivent être utilisés et s’il s’agit du niveau de publication et/ou d’aperçu. Il comprend :

    • name - chaîne descriptive
    • when - condition qui détermine quand la règle doit être évaluée, selon la syntaxe de l’article Règles de filtrage du trafic . En règle générale, il comprend une comparaison du niveau actuel (par exemple, publication).
    • action : doit spécifier "authenticate", avec l’authentificateur prévu référencé.
NOTE
La clé de purge doit être configurée en tant que variable d’environnement de Cloud Manager de type secretavant le déploiement de la configuration qui la fait référence. Il est recommandé d’utiliser une clé aléatoire unique d’une longueur minimale de 32 octets ; par exemple, la bibliothèque cryptographique Open SSL peut générer une clé aléatoire en exécutant la commande openssl rand -hex 32.

Vous pouvez référencer un tutoriel axé sur la configuration des clés de purge et l’exécution de la purge du cache CDN.

Authentification de base basic-auth

Protégez certaines ressources de contenu en affichant une boîte de dialogue d’authentification de base nécessitant un nom d’utilisateur ou d’utilisatrice et un mot de passe. Cette fonctionnalité est principalement destinée aux cas d’utilisation de l’authentification légère, tels que la révision du contenu par les parties prenantes de l’entreprise, plutôt qu’en tant que solution complète pour les droits d’accès des utilisateurs finaux.

Une boîte de dialogue d’authentification de base s’affiche pour l’utilisateur final comme suit :

basicauth-dialog

La syntaxe est la suivante :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  authentication:
    authenticators:
       - name: my-basic-authenticator
         type: basic
         credentials:
           - user: johndoe
             password: ${{JOHN_DOE_PASSWORD}}
           - user: janedoe
             password: ${{JANE_DOE_PASSWORD}}
    rules:
       - name: basic-auth-rule
         when: { reqProperty: path, like: "/summercampaign" }
         action:
           type: authenticate
           authenticator: my-basic-authenticator

Voir la section Utiliser les pipelines de configuration pour obtenir une description des propriétés situées au-dessus du nœud data. La valeur de la propriété kind doit être CDN et la propriété version doit être définie sur 1.

En outre, la syntaxe comprend :

  • un noeud data contenant un noeud authentication.

  • Sous authentication, un noeud authenticators et un noeud rules, qui sont tous deux des tableaux.

  • Authentificateurs : dans ce scénario, déclarez un authentificateur de base, qui possède la structure suivante :

    • name - chaîne descriptive

    • type - doit être basic

    • un tableau de 10 informations d’identification au maximum, dont chacune comprend les paires nom/valeur suivantes, que les utilisateurs finaux peuvent entrer dans la boîte de dialogue d’authentification de base :

  • Règles : vous permet de déclarer quels authentificateurs doivent être utilisés et quelles ressources doivent être protégées. Chaque règle comprend :

    • name - chaîne descriptive
    • when - condition qui détermine quand la règle doit être évaluée, selon la syntaxe de l’article Règles de filtrage du trafic . En règle générale, il comprend une comparaison du niveau de publication ou des chemins spécifiques.
    • action : doit spécifier "authenticate", avec l’authentificateur prévu référencé, qui est une authentification de base pour ce scénario.
NOTE
Les mots de passe doivent être configurés en tant que variables d’environnement Cloud Manager de type secretavant le déploiement de la configuration qui y fait référence.

Rotation des secrets rotating-secrets

  1. Il est recommandé de modifier occasionnellement les informations d’identification en toute sécurité. Vous pouvez y parvenir comme illustré ci-dessous en utilisant l’exemple d’une clé de périphérie, bien que la même stratégie soit utilisée pour les clés de purge.

  2. Initialement, seul edgeKey1 a été défini, dans ce cas appelé ${{CDN_EDGEKEY_052824}}, qui, comme convention recommandée, reflète la date à laquelle il a été créé.

    code language-none
    authentication:
      authenticators:
        - name: edge-auth
          type: edge
          edgeKey1: ${{CDN_EDGEKEY_052824}}
    
  3. Lorsque le temps est venu de faire pivoter la clé, créez un secret Cloud Manager, par exemple ${{CDN_EDGEKEY_041425}}.

  4. Dans la configuration, référencez-la à partir de edgeKey2 et déployez-la.

    code language-none
    authentication:
      authenticators:
        - name: edge-auth
          type: edge
          edgeKey1: ${{CDN_EDGEKEY_052824}}
          edgeKey2: ${{CDN_EDGEKEY_041425}}
    
  5. Une fois que vous êtes certain que l’ancienne clé Edge n’est plus utilisée, supprimez-la en supprimant edgeKey1 de la configuration.

    code language-none
    authentication:
      authenticators:
        - name: edge-auth
          type: edge
          edgeKey2: ${{CDN_EDGEKEY_041425}}
    
  6. Supprimez l’ancienne référence secrète (${{CDN_EDGEKEY_052824}}) de Cloud Manager et déployez-la.

  7. Lorsque vous êtes prêt pour la rotation suivante, procédez de la même manière. Toutefois, cette fois, vous ajouterez edgeKey1 à la configuration, en référençant un nouveau secret d’environnement Cloud Manager nommé, par exemple ${{CDN_EDGEKEY_031426}}.

    code language-none
    authentication:
      authenticators:
        - name: edge-auth
          type: edge
          edgeKey2: ${{CDN_EDGEKEY_041425}}
          edgeKey1: ${{CDN_EDGEKEY_031426}}
    
recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab