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.
Os segredos do ambiente ou do pipeline (etapa de implantação) podem ser referenciados com a sintaxe ${{..}} e podem ser usados sempre que um valor literal puder ser usado, em condições ou definidores.
kind: "CDN"
version: "1"
data:
originSelectors:
rules:
- name: select-origin-example
when: { reqHeader: "x-auth-header", equals: "${{AUTH_HEADER}}" }
action:
type: selectOrigin
originName: origin-name
headers:
Authorization: "${{AUTH_HEADER}}"
...
Estas são algumas diretrizes que devem ser lembradas ao trabalhar com segredos:
-
Os segredos do ambiente devem ser implantados como uma variável de ambiente do tipo secreto do Cloud Manager. Para o campo Serviço Aplicado, selecione Todos.
-
As referências secretas não são interpoladas dentro de cadeias de caracteres (por exemplo,
"Token ${{AUTH_TOKEN}}"não funcionará) -
Um segredo de ambiente referenciado não deve ser removido se ainda estiver referenciado na configuração.
note warning WARNING Não remova as variáveis de ambiente referenciadas na sua configuração de CDN. Isso pode causar falhas na atualização da configuração do CDN (por exemplo, atualização de regras ou domínios e certificados personalizados). -
Os segredos devem ser girados periodicamente. Há uma seção sobre como girar chaves, o que é uma boa prática de segurança.
note note NOTE Segredos definidos como variáveis de ambiente devem ser considerados imutáveis. Em vez de alterar o valor, você deve criar um novo segredo com um novo nome e fazer referência a esse segredo na configuração. Não fazer isso resultará na atualização não confiável dos segredos.
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"
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"
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"
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}}