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.

WARNING
L’accesso diretto senza una chiave X-AEM-Edge-Key corretta verrà negato per tutte le richieste che corrispondono alla condizione (nell’esempio seguente significa tutte le richieste al livello di pubblicazione). Se devi introdurre gradualmente l'autenticazione, consulta la sezione Migrazione sicura per ridurre il rischio di traffico bloccato.
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 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. Si consiglia di utilizzare una chiave casuale univoca della lunghezza minima di 32 byte. Ad esempio, la libreria di crittografia Open SSL può generare una chiave casuale eseguendo il comando 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 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. Si consiglia di utilizzare una chiave casuale univoca della lunghezza minima di 32 byte; ad esempio, la libreria di crittografia Open SSL può generare una chiave casuale eseguendo il comando openssl rand -hex 32

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:

basicauth-dialog

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 nodo authentication.

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