Configurazione delle credenziali CDN e dell’autenticazione cdn-credentials-authentication
La rete CDN fornita dall’Adobe dispone di diverse funzioni e servizi, alcuni dei quali si basano sulle credenziali e sull’autenticazione per garantire un livello adeguato di sicurezza aziendale. Dichiarando le regole in un file di configurazione distribuito tramite la pipeline config di Cloud Manager, i clienti possono configurare in modo autonomo quanto segue:
- Il valore dell’intestazione HTTP X-AEM-Edge-Key utilizzato dalla rete CDN Adobe per convalidare le richieste provenienti da una rete CDN gestita dal cliente.
- Token API utilizzato per eliminare le risorse nella cache CDN.
- Un elenco di combinazioni nome utente/password che possono accedere a contenuto con restrizioni, inviando un modulo di autenticazione di base.
Ognuna di queste, inclusa la sintassi di configurazione, è descritta nella propria sezione di seguito.
È presente una sezione sulla modalità di rotazione delle chiavi, che è una buona pratica di sicurezza.
Valore intestazione HTTP CDN gestita dal cliente CDN-HTTP-value
Come descritto nella pagina CDN in AEM as a Cloud Service, i clienti possono scegliere di instradare il traffico attraverso la propria rete CDN, denominata anche CDN cliente (talvolta denominata BYOCDN).
Come parte della configurazione, la rete CDN Adobe e la rete CDN cliente devono concordare un valore dell'intestazione HTTP X-AEM-Edge-Key
. Questo valore viene impostato su ogni richiesta, sulla rete CDN del cliente, prima che venga instradato alla rete CDN dell’Adobe, la quale verifica che il valore sia quello previsto, in modo che possa essere considerato attendibile da altre intestazioni HTTP, incluse quelle che consentono di instradare la richiesta all’origine AEM appropriata.
Al valore X-AEM-Edge-Key fanno riferimento le proprietà edgeKey1
e edgeKey2
in un file denominato cdn.yaml
o simile, in una cartella config
di primo livello. Leggi Utilizzo delle pipeline di configurazione per informazioni dettagliate sulla struttura delle cartelle e su come distribuire la configurazione. La sintassi è descritta nell’esempio seguente.
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
Consulta Utilizzo delle pipeline di configurazione per una descrizione delle proprietà al di sopra del nodo data
. Il valore della proprietà kind
deve essere CDN e la proprietà version
deve essere impostata su 1
.
Per ulteriori dettagli, consulta il passaggio tutorial Configurare e distribuire la regola CDN di convalida dell'intestazione HTTP.
Altre proprietà includono:
-
Nodo
Data
che contiene un nodoauthentication
secondario. -
In
authentication
, un nodoauthenticators
e un nodorules
, entrambi array. -
Autenticatori: consente di dichiarare un tipo di token o credenziale, che in questo caso è una chiave Edge. Include le seguenti proprietà:
- name - una stringa descrittiva.
- tipo - deve essere
edge
. - edgeKey1: il valore di X-AEM-Edge-Key, che deve fare riferimento a una variabile di ambiente di tipo segreto Cloud Manager. Per il campo Servizio applicato, selezionare Tutto. Si consiglia che il valore (ad esempio,
${{CDN_EDGEKEY_052824}}
) rifletta il giorno in cui è stato aggiunto. - edgeKey2: utilizzato per la rotazione dei segreti, come descritto nella sezione relativa alla rotazione dei segreti di seguito. Definitelo in modo simile a edgeKey1. È necessario dichiarare almeno uno di
edgeKey1
eedgeKey2
.
-
Regole: consente di dichiarare quale degli autenticatori deve essere utilizzato e se si tratta del livello di pubblicazione e/o anteprima. Include:
- name - una stringa descrittiva.
- when: condizione che determina quando valutare la regola, in base alla sintassi nell'articolo Regole filtro traffico. In genere, include un confronto del livello corrente (ad esempio, Pubblica) in modo che tutto il traffico live venga convalidato come routing tramite la rete CDN del cliente.
- action - deve specificare "authentication" (autentica), facendo riferimento all’autenticatore previsto.
openssl rand -hex 32
.Migrazione sicura per ridurre il rischio di blocco del traffico migrating-safely
Se il sito è già attivo, presta attenzione durante la migrazione alla rete CDN gestita dal cliente, poiché una configurazione errata può bloccare il traffico pubblico; questo perché solo le richieste con il valore di intestazione X-AEM-Edge-Key previsto verranno accettate dalla rete CDN Adobe. Si consiglia un approccio quando nella regola di autenticazione viene temporaneamente inclusa una condizione aggiuntiva, che causa il blocco della richiesta solo se viene inclusa un’intestazione di test o se viene trovato un percorso corrispondente:
- 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
È possibile utilizzare il seguente pattern di richiesta curl
:
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"
Dopo aver completato correttamente il test, è possibile rimuovere la condizione aggiuntiva e ridistribuire la configurazione.
Rimuovi token API purge-API-token
I clienti possono eliminare la cache CDN utilizzando un token API di rimozione dichiarato. Il token è dichiarato in un file denominato cdn.yaml
o simile, in una cartella config
di primo livello. Leggi Utilizzo delle pipeline di configurazione per informazioni dettagliate sulla struttura delle cartelle e su come distribuire la configurazione.
La sintassi è descritta di seguito:
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
Consulta Utilizzo delle pipeline di configurazione per una descrizione delle proprietà al di sopra del nodo data
. Il valore della proprietà kind
deve essere CDN e la proprietà version
deve essere impostata su 1
.
Altre proprietà includono:
-
Nodo
data
che contiene un nodoauthentication
secondario. -
In
authentication
, un nodoauthenticators
e un nodorules
, entrambi array. -
Autenticatori: consente di dichiarare un tipo di token o credenziali, che in questo caso è una chiave di rimozione. Include le seguenti proprietà:
- name - una stringa descrittiva.
- tipo: deve essere purge.
- purgeKey1 - il valore deve fare riferimento a una variabile di ambiente di tipo segreto Cloud Manager. Per il campo Servizio applicato, selezionare Tutto. Si consiglia che il valore (ad esempio,
${{CDN_PURGEKEY_031224}}
) rifletta il giorno in cui è stato aggiunto. - purgeKey2: utilizzato per la rotazione dei segreti, come descritto nella sezione rotating secrets di seguito. È necessario dichiarare almeno uno di
purgeKey1
epurgeKey2
.
-
Regole: consente di dichiarare quale degli autenticatori deve essere utilizzato e se si tratta del livello di pubblicazione e/o anteprima. Include:
- name - una stringa descrittiva
- when: condizione che determina quando valutare la regola, in base alla sintassi nell'articolo Regole filtro traffico. In genere, include un confronto del livello corrente (ad esempio, pubblicazione).
- action - deve specificare "authentication" (autentica), facendo riferimento all’autenticatore previsto.
Puoi fare riferimento a un'esercitazione incentrata sulla configurazione delle chiavi di eliminazione e sull'esecuzione dell'eliminazione della cache CDN.
Autenticazione di base basic-auth
Proteggi alcune risorse di contenuto visualizzando una finestra di dialogo di autenticazione di base che richiede un nome utente e una password. Questa funzione è destinata principalmente a casi di utilizzo di autenticazione leggera, come la revisione dei contenuti da parte delle parti interessate del business, anziché essere una soluzione completa per i diritti di accesso degli utenti finali.
L’utente finale visualizzerà una finestra di dialogo di autenticazione di base simile alla seguente:
La sintassi è la seguente:
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
Consulta Utilizzo delle pipeline di configurazione per una descrizione delle proprietà al di sopra del nodo data
. Il valore della proprietà kind
deve essere CDN e la proprietà version
deve essere impostata su 1
.
Inoltre, la sintassi include:
-
un nodo
data
che contiene un nodoauthentication
. -
In
authentication
, un nodoauthenticators
e un nodorules
, entrambi array. -
Autenticatori: in questo scenario, dichiara un autenticatore di base, con la seguente struttura:
-
name - una stringa descrittiva
-
tipo - deve essere
basic
-
array di un massimo di 10 credenziali, ognuna delle quali include le seguenti coppie nome/valore, che gli utenti finali possono immettere nella finestra di dialogo autenticazione di base:
- user (utente): nome dell’utente
- password: il valore deve fare riferimento a una variabile di ambiente di tipo segreto Cloud Manager, con All selezionato come campo del servizio.
-
-
Regole: consente di dichiarare quali degli autenticatori devono essere utilizzati e quali risorse devono essere protette. Ogni regola include:
- name - una stringa descrittiva
- when: condizione che determina quando valutare la regola, in base alla sintassi nell'articolo Regole filtro traffico. In genere, include un confronto del livello di pubblicazione o di percorsi specifici.
- action - deve specificare "authenticate", con riferimento all’autenticatore previsto, che è basic-auth per questo scenario
Rotazione dei segreti rotating-secrets
-
È buona prassi di sicurezza modificare occasionalmente le credenziali. Questa operazione può essere eseguita come esemplificato di seguito, utilizzando l'esempio di una chiave di spigolo, anche se la stessa strategia viene utilizzata per le chiavi di rimozione.
-
Inizialmente è stato definito solo
edgeKey1
, in questo caso denominato${{CDN_EDGEKEY_052824}}
, che come convenzione consigliata riflette la data di creazione.code language-none authentication: authenticators: - name: edge-auth type: edge edgeKey1: ${{CDN_EDGEKEY_052824}}
-
Quando è il momento di ruotare la chiave, creare un nuovo segreto di Cloud Manager, ad esempio
${{CDN_EDGEKEY_041425}}
. -
Nella configurazione, fare riferimento a essa da
edgeKey2
e distribuire.code language-none authentication: authenticators: - name: edge-auth type: edge edgeKey1: ${{CDN_EDGEKEY_052824}} edgeKey2: ${{CDN_EDGEKEY_041425}}
-
Dopo aver verificato che la vecchia chiave edge non è più utilizzata, rimuoverla rimuovendo
edgeKey1
dalla configurazione.code language-none authentication: authenticators: - name: edge-auth type: edge edgeKey2: ${{CDN_EDGEKEY_041425}}
-
Elimina il riferimento segreto precedente (
${{CDN_EDGEKEY_052824}}
) da Cloud Manager e distribuiscilo. -
Quando sei pronto per la rotazione successiva, segui la stessa procedura; tuttavia, questa volta aggiungerai
edgeKey1
alla configurazione, facendo riferimento a un nuovo segreto di ambiente di Cloud Manager denominato, ad esempio${{CDN_EDGEKEY_031426}}
.code language-none authentication: authenticators: - name: edge-auth type: edge edgeKey2: ${{CDN_EDGEKEY_041425}} edgeKey1: ${{CDN_EDGEKEY_031426}}