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.
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 noeudauthentication
enfant. -
Sous
authentication
, un noeudauthenticators
et un noeudrules
, 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
etedgeKey2
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é.
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 noeudauthentication
enfant. -
Sous
authentication
, un noeudauthenticators
et un noeudrules
, 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
etpurgeKey2
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é.
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 :
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 noeudauthentication
. -
Sous
authentication
, un noeudauthenticators
et un noeudrules
, 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 :
- user : nom de l’utilisateur
- password : sa valeur doit faire référence à une variable d’environnement de type secret Cloud Manager, All étant sélectionné en tant que champ de service.
-
-
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.
Rotation des secrets rotating-secrets
-
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.
-
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}}
-
Lorsque le temps est venu de faire pivoter la clé, créez un secret Cloud Manager, par exemple
${{CDN_EDGEKEY_041425}}
. -
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}}
-
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}}
-
Supprimez l’ancienne référence secrète (
${{CDN_EDGEKEY_052824}}
) de Cloud Manager et déployez-la. -
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}}