Configurando Credenciais e Autenticação da CDN cdn-credentials-authentication
A CDN fornecida pela Adobe tem vários recursos e serviços, alguns dos quais dependem de credenciais e autenticação para garantir um nível apropriado de segurança corporativa. Ao declarar regras em um arquivo de configuração implantado com o uso do pipeline de configuração do Cloud Manager, os clientes podem configurar, por autoatendimento, o seguinte:
- O valor do cabeçalho HTTP X-AEM-Edge-Key usado pela CDN da Adobe para validar solicitações provenientes de um CDN gerenciado pelo Cliente.
 - O token de API usado para limpar recursos no cache do CDN.
 - Uma lista de combinações de nome de usuário/senha que podem acessar conteúdo restrito, enviando um formulário de Autenticação básica.
 
Cada uma dessas opções, incluindo a sintaxe de configuração, é descrita em sua própria seção abaixo.
Há uma seção sobre como girar chaves, o que é uma boa prática de segurança.
Valor do cabeçalho HTTP da CDN gerenciada pelo cliente CDN-HTTP-value
Conforme descrito na página CDN no AEM as a Cloud Service, os clientes podem optar por rotear o tráfego por meio de sua própria CDN, que é chamada de CDN do cliente (também chamada às vezes de BYOCDN).
Como parte da configuração, a CDN da Adobe e a CDN do cliente devem concordar com um valor do Cabeçalho HTTP X-AEM-Edge-Key. Esse valor é definido em cada solicitação no CDN do cliente, antes de ser roteado para o CDN da Adobe, que então valida se o valor está conforme o esperado, para que possa confiar em outros cabeçalhos HTTP, incluindo aqueles que ajudam a rotear a solicitação para a origem apropriada do AEM.
O valor X-AEM-Edge-Key é referenciado pelas propriedades edgeKey1 e edgeKey2 em um arquivo chamado cdn.yaml ou similar, em algum lugar sob uma pasta config de nível superior. Leia Usando Pipelines de Configuração para obter detalhes sobre a estrutura de pastas e como implantar a configuração. A sintaxe é descrita no exemplo abaixo.
Para obter mais informações sobre depuração e erros comuns, verifique Erros Comuns.
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
            Consulte Usando Pipelines de Configuração para obter uma descrição das propriedades acima do nó data. O valor da propriedade kind deve ser CDN e a propriedade version deve ser definida como 1.
Consulte a etapa do tutorial Configurar e implantar regra CDN de validação de cabeçalho HTTP para obter mais detalhes.
As propriedades adicionais incluem:
- 
                  
Nó
Dataque contém um nóauthenticationfilho. - 
                  
Em
authentication, um nóauthenticatorse um nórules, ambos com matrizes. - 
                  
Autenticadores: permite declarar um tipo de token ou credencial, que, nesse caso, é uma chave de borda. Inclui as seguintes propriedades:
- name - uma cadeia de caracteres descritiva.
 - tipo - deve ser 
edge. - edgeKey1 - o valor de X-AEM-Edge-Key, que deve fazer referência a uma variável de ambiente do tipo secreto do Cloud Manager. Para o campo Serviço Aplicado, selecione Todos. É recomendável que o valor (por exemplo, 
${{CDN_EDGEKEY_052824}}) reflita o dia em que foi adicionado. - edgeKey2 - usado para a rotação de segredos, que é descrita na seção de rotação de segredos abaixo. Defina-a de forma semelhante a edgeKey1. Pelo menos um de 
edgeKey1eedgeKey2deve ser declarado. 
 
- 
                  
Regras: permite declarar quais dos autenticadores devem ser usados e se são para o nível de publicação e/ou pré-visualização. Inclui:
- name - uma cadeia de caracteres descritiva.
 - when - uma condição que determina quando a regra deve ser avaliada, de acordo com a sintaxe no artigo Regras de filtro de tráfego. Normalmente, ela incluirá uma comparação da camada atual (por exemplo, publicar) para que todo o tráfego ativo seja validado como roteamento pela CDN do cliente.
 - ação - deve especificar "autenticar", com o autenticador desejado referenciado.
 
 
openssl rand -hex 32.Migração segura para reduzir o risco de tráfego bloqueado migrating-safely
Se seu site já estiver ativo, tenha cuidado ao migrar para o CDN gerenciado pelo cliente, pois uma configuração incorreta pode bloquear o tráfego público; isso ocorre porque somente as solicitações com o valor do cabeçalho X-AEM-Edge-Key esperado serão aceitas pelo CDN da Adobe. Uma abordagem é recomendada quando uma condição adicional é temporariamente incluída na regra de autenticação, o que faz com que ela bloqueie a solicitação somente se um cabeçalho de teste for incluído ou se um caminho for correspondido:
    - 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
            O seguinte padrão de solicitação curl pode ser usado:
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"
            Após um teste bem-sucedido, a condição adicional pode ser removida e a configuração reimplantada.
Processo de migração se o Suporte da Adobe tiver gerado anteriormente o valor do Cabeçalho HTTP X-AEM-Edge-Key migrating-legacy
        Anteriormente, o processo de integração com um CDN gerenciado pelo cliente envolvia clientes que solicitavam um valor de cabeçalho HTTP X-AEM-Edge-Key do suporte da Adobe, em vez de definir o valor sozinhos. Para migrar para a abordagem de autoatendimento mais recente, em que você define seus próprios valores de chave de borda, siga estas etapas para garantir uma transição suave sem tempo de inatividade:
- 
                  
Defina a configuração da CDN com os segredos novos (gerados pelo cliente) e antigos (gerados pela Adobe) especificados como
edgeKey1eedgeKey2. Esta é uma variação da documentação de segredos em rotação. - 
                  
Implante os segredos e a configuração do CDN de autoatendimento. Nesse ponto do processo, o segredo antigo definido pela Adobe ainda deve permanecer como o valor X-AEM-Edge-Key transmitido pela CDN gerenciada pelo cliente.
 - 
                  
Entre em contato com o Suporte da Adobe, solicitando que o Adobe alterne para usar a configuração de autoatendimento, especificando que você já a implantou.
 - 
                  
Depois que a Adobe confirmar que executou essa ação, configure sua CDN gerenciada pelo cliente para usar a nova chave definida pelo cliente para o valor do Cabeçalho HTTP
X-AEM-Edge-Key. - 
                  
Remova a chave antiga da configuração do CDN e implante o pipeline de configuração novamente.
 
Limpar token de API purge-API-token
Os clientes podem limpar o cache da CDN usando um token de API de limpeza declarado. O token é declarado em um arquivo chamado cdn.yaml ou similar, em algum lugar sob uma pasta config de nível superior. Leia Usando Pipelines de Configuração para obter detalhes sobre a estrutura de pastas e como implantar a configuração.
A sintaxe é descrita abaixo:
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
            Consulte Usando Pipelines de Configuração para obter uma descrição das propriedades acima do nó data. O valor da propriedade kind deve ser CDN e a propriedade version deve ser definida como 1.
As propriedades adicionais incluem:
- 
                  
Nó
dataque contém um nóauthenticationfilho. - 
                  
Em
authentication, um nóauthenticatorse um nórules, ambos com matrizes. - 
                  
Autenticadores: permite declarar um tipo de token ou credencial, que, nesse caso, é uma chave de limpeza. Inclui as seguintes propriedades:
- name - uma cadeia de caracteres descritiva.
 - tipo - deve ser expurgado.
 - purgeKey1 - o valor deve fazer referência a uma Variável de ambiente do tipo secreto do Cloud Manager. Para o campo Serviço Aplicado, selecione Todos. Recomenda-se que o valor (por exemplo, 
${{CDN_PURGEKEY_031224}}) reflita o dia em que foi adicionado. - purgeKey2 - usado para a rotação de segredos, que é descrita na seção segredos em rotação abaixo. Pelo menos um de 
purgeKey1epurgeKey2deve ser declarado. 
 - 
                  
Regras: permite declarar quais dos autenticadores devem ser usados e se são para o nível de publicação e/ou pré-visualização. Inclui:
- nome - uma sequência descritiva
 - when - uma condição que determina quando a regra deve ser avaliada, de acordo com a sintaxe no artigo Regras de filtro de tráfego. Normalmente, incluirá uma comparação do nível atual (por exemplo, publicar).
 - ação - deve especificar "autenticar", com o autenticador desejado referenciado.
 
 
Você pode fazer referência a um tutorial focado na configuração de chaves de limpeza e na execução da limpeza do cache do CDN.
Autenticação básica basic-auth
Proteja determinados recursos de conteúdo abrindo uma caixa de diálogo de autenticação básica que requer um nome de usuário e senha. Esse recurso destina-se principalmente a casos de uso de autenticação simples, como a análise de conteúdo pelas partes interessadas, e não como uma solução completa para os direitos de acesso do usuário final.
O usuário final terá uma caixa de diálogo de autenticação básica surgindo da seguinte maneira:
          
          
A sintaxe é a seguinte:
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
            Consulte Usando Pipelines de Configuração para obter uma descrição das propriedades acima do nó data. O valor da propriedade kind deve ser CDN e a propriedade version deve ser definida como 1.
Além disso, a sintaxe inclui:
- 
                  
um nó
dataque contém um nóauthentication. - 
                  
Em
authentication, um nóauthenticatorse um nórules, ambos com matrizes. - 
                  
Autenticadores: neste cenário, declare um autenticador básico, que tenha a seguinte estrutura:
- 
                      
nome - uma sequência descritiva
 - 
                      
tipo - deve ser
basic - 
                      
uma matriz de até 10 credenciais, cada uma incluindo os seguintes pares de nome/valor, que os usuários finais podem inserir na caixa de diálogo de autenticação básica:
- usuário - o nome do usuário.
 - senha - seu valor deve fazer referência a uma variável de ambiente do tipo secreto do Cloud Manager, com Todos selecionados como o campo de serviço.
 
 
 - 
                      
 - 
                  
Regras: permite declarar quais dos autenticadores devem ser usados e quais recursos devem ser protegidos. Cada regra inclui:
- nome - uma sequência descritiva
 - when - uma condição que determina quando a regra deve ser avaliada, de acordo com a sintaxe no artigo Regras de filtro de tráfego. Normalmente, isso incluirá uma comparação do nível de publicação ou caminhos específicos.
 - ação - deve especificar "autenticar", com o autenticador desejado referenciado, que é basic-auth para este cenário
 
 
Rotação de segredos rotating-secrets
É uma boa prática de segurança alterar as credenciais regularmente. Lembre-se de que as variáveis de ambiente não devem ser alteradas diretamente. Em vez disso, crie um novo segredo e faça referência ao novo nome na configuração.
Esse caso de uso é exemplificado abaixo, usando o exemplo de uma chave de borda, embora a mesma estratégia também possa ser usada para chaves de limpeza.
- 
                  
Inicialmente, apenas
edgeKey1foi definido, neste caso referenciado como${{CDN_EDGEKEY_052824}}, que, como uma convenção recomendada, reflete a data em que foi criado.code language-none authentication: authenticators: - name: edge-auth type: edge edgeKey1: ${{CDN_EDGEKEY_052824}} - 
                  
Quando for a hora de girar a chave, crie um novo segredo do Cloud Manager, por exemplo
${{CDN_EDGEKEY_041425}}. - 
                  
Na configuração, faça referência a ele a partir de
edgeKey2e implante.code language-none authentication: authenticators: - name: edge-auth type: edge edgeKey1: ${{CDN_EDGEKEY_052824}} edgeKey2: ${{CDN_EDGEKEY_041425}} - 
                  
Depois de ter certeza de que a chave de borda antiga não será mais usada, remova-a removendo
edgeKey1da configuração.code language-none authentication: authenticators: - name: edge-auth type: edge edgeKey2: ${{CDN_EDGEKEY_041425}} - 
                  
Exclua a referência secreta antiga (
${{CDN_EDGEKEY_052824}}) da Cloud Manager e implante. - 
                  
Quando estiver pronto para a próxima rotação, siga o mesmo procedimento. No entanto, dessa vez, você adicionará
edgeKey1à configuração, fazendo referência a um novo segredo do ambiente do Cloud Manager chamado, por exemplo,${{CDN_EDGEKEY_031426}}.code language-none authentication: authenticators: - name: edge-auth type: edge edgeKey2: ${{CDN_EDGEKEY_041425}} edgeKey1: ${{CDN_EDGEKEY_031426}} 
Ao girar segredos definidos em cabeçalhos de solicitação, por exemplo, para autenticação em um back-end, é recomendável fazer a rotação em duas etapas para garantir que o valor do cabeçalho seja alternado sem intervalos temporários.
- 
                  
Configuração inicial antes da rotação. Nesse estado, a chave antiga é enviada para o back-end.
code language-none requestTransformations: rules: - name: set-api-key-header actions: - type: set reqHeader: x-api-key value ${{API_KEY_1}} - 
                  
Introduza a nova chave
API_KEY_2definindo o mesmo cabeçalho duas vezes (a nova chave deve ser definida após a chave antiga). Depois de implantar isso, você verá a nova chave no back-end.code language-none requestTransformations: rules: - name: set-api-key-header actions: - type: set reqHeader: x-api-key value ${{API_KEY_1}} - type: set reqHeader: x-api-key value ${{API_KEY_2}} - 
                  
Remova a chave antiga
API_KEY_1da configuração. Depois de implantar isso, você verá a nova chave no back-end e é seguro remover a variável de ambiente da chave antiga.code language-none requestTransformations: rules: - name: set-api-key-header actions: - type: set reqHeader: x-api-key value ${{API_KEY_2}}