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. Questa funzione è disponibile per gli utenti che la utilizzano in anticipo.

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 l'articolo 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: 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

Per una descrizione delle proprietà sopra il nodo data, consulta l'articolo Pipeline di configurazione. 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 nodo authentication secondario.

  • In authentication, un nodo authenticators e un nodo rules, 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 e edgeKey2.
  • 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.
NOTE
La chiave Edge deve essere configurata come variabile di ambiente Cloud Manager di tipo segreto, prima che venga distribuita la configurazione che vi fa riferimento.

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 l'articolo sulla 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

Per una descrizione delle proprietà al di sopra del nodo data, consulta l'articolo 🔗 della pipeline di configurazione . 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 nodo authentication secondario.

  • In authentication, un nodo authenticators e un nodo rules, 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 e purgeKey2.
  • 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.
NOTE
La chiave di eliminazione deve essere configurata come variabile di ambiente Cloud Manager di tipo segreto, prima che venga distribuita la configurazione che vi fa riferimento.

Autenticazione di base basic-auth

NOTE
Questa funzione non è ancora disponibile al pubblico. Per partecipare al programma di adozione anticipata, inviare un'e-mail a aemcs-cdn-config-adopter@adobe.com.

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:

basicauth-dialog

La sintassi è la seguente:

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  experimental_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

Per una descrizione delle proprietà al di sopra del nodo data, consulta l'articolo 🔗 della pipeline di configurazione . 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 nodo experimental_authentication (il prefisso sperimentale verrà rimosso al rilascio della funzionalità).

  • In experimental_authentication, un nodo authenticators e un nodo rules, 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 credenziali, ciascuna 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
NOTE
Le password devono essere configurate come variabili di ambiente Cloud Manager di tipo segreto, prima che venga distribuita la configurazione che vi fa riferimento.

Rotazione dei segreti rotating-secrets

  1. È 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.

  2. Inizialmente è stato definito solo edgeKey1, in questo caso denominato ${{CDN_EDGEKEY_052824}}, che come convenzione consigliata riflette la data di creazione.

    code language-none
    experimental_authentication:
      authenticators:
        - name: edge-auth
          type: edge
          edgeKey1: ${{CDN_EDGEKEY_052824}}
    
  3. Quando è il momento di ruotare la chiave, creare un nuovo segreto di Cloud Manager, ad esempio ${{CDN_EDGEKEY_041425}}.

  4. Nella configurazione, fare riferimento a essa da edgeKey2 e distribuire.

    code language-none
    experimental_authentication:
      authenticators:
        - name: edge-auth
          type: edge
          edgeKey1: ${{CDN_EDGEKEY_052824}}
          edgeKey2: ${{CDN_EDGEKEY_041425}}
    
  5. Dopo aver verificato che la vecchia chiave edge non è più utilizzata, rimuoverla rimuovendo edgeKey1 dalla configurazione.

    code language-none
    experimental_authentication:
      authenticators:
        - name: edge-auth
          type: edge
          edgeKey2: ${{CDN_EDGEKEY_041425}}
    
  6. Elimina il riferimento segreto precedente (${{CDN_EDGEKEY_052824}}) da Cloud Manager e distribuiscilo.

  7. 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
    experimental_authentication:
      authenticators:
        - name: edge-auth
          type: edge
          edgeKey2: ${{CDN_EDGEKEY_041425}}
          edgeKey1: ${{CDN_EDGEKEY_031426}}
    
recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab