Autorização do usuário
Visão geral
As aplicações Web que expõem conteúdo privado exigem mecanismos de controle de acesso para garantir que somente usuários autorizados possam acessar o conteúdo. Os exemplos incluem portais internos baseados em SPA que exigem autenticação do usuário e download de arquivos confidenciais. O controle de acesso pode ser implementado no nível de origem ou no nível da CDN, de acordo com o caso de uso.
Casos de uso comuns
Autorização baseada na origem
Se você estiver usando o CloudFront como um proxy reverso sem cache habilitado (ou seja, o Armazenamento em cache desabilitado está configurado em Política de cache gerenciado), pode simplesmente usar os recursos de autorização nativos de sua origem (por exemplo, API Gateway). Para que isso funcione corretamente, configure a Política de solicitação de origem para encaminhar para sua origem o atributo de solicitação que contém as informações de autorização, como o Cabeçalho de autorização.
Se seu conteúdo puder ser armazenado em cache, mas você preferir continuar gerenciando a autorização em sua própria infraestrutura, considere integrar o CloudFront aos seus servidores de autorização usando o Lambda@Edge. Essa arquitetura permite que você se beneficie do cache do CloudFront. Leia mais sobre essa implementação neste blog.
Considere as seções a seguir se quiser transferir a lógica de autorização dos componentes da sua aplicação Web para o CloudFront.
Autorização baseada no CloudFront usando tokens assinados
O CloudFront fornece um mecanismo de autorização nativo usando URLs assinados ou cookies assinados. Para usar esse método, siga as etapas explicadas na documentação:
- Configure uma chave criptográfica assimétrica para assinar tokens usando grupos de chaves de assinatura.
- Em seu fluxo de trabalho de autenticação, acrescente os campos de token necessários nos parâmetros de consulta ou cookies do URL do recurso fornecido. O token contém uma data de validade, o ID da chave de assinatura, a política e uma assinatura. A política permite que você defina as condições que precisam ser atendidas por uma solicitação para passar no teste de validação do token pelo CloudFront. Por exemplo, você pode usar uma política personalizada para gerar um token válido para todos os URLs que começam com um caminho específico.
- Habilite a assinatura no comportamento de cache do CloudFront que é usado para conteúdo privado. A partir desse momento, todas as solicitações serão controladas pelo CloudFront para validação do token. Solicitações não autorizadas recebem um erro 403, que pode ser personalizado usando a Funcionalidade de página de erro personalizada do CloudFront.
Use o aws-sdk para gerar um token válido com sua chave privada. Como ilustração, o código abaixo em Nodejs gera um URL assinado do CloudFront para um objeto específico edge-image.jpg, válido por duas horas.
const AWS = require('aws-sdk');
// It's recommended not to store signing keys in code. The below is just an illustrative example.
const cloudfrontAccessKeyId = 'K25ULYFPSTHQP9';
const cloudFrontPrivateKey = '-----BEGIN RSA PRIVATE KEY-----\nMIIEowIBAAKCAQ....2gvvIH\n-----END RSA PRIVATE KEY-----';
const signer = new AWS.CloudFront.Signer(cloudfrontAccessKeyId, cloudFrontPrivateKey);
const signedUrl = signer.getSignedUrl({
url: 'https://d3jqlnxofenq2x.cloudfront.net/edge-image.jpg',
expires: Math.floor((Date.now() + 2 * 60 * 60 * 1000) / 1000),
});
console.log(signedUrl);A saída do trecho de código acima tem a seguinte aparência:
https://d3jqlnxofenq2x.cloudfront.net/edge-image.jpg?Expires=1660317158&Key-Pair-Id=K25ULYFP9THQP9&Signature=agW2XF9S5AW0YCc6c7pkCwccJmxaIAWFO~uXn9KtOXtz4JTY7eRF07opJiseGXJxzlMeD4V6FUH8I-gOH~Gvafa16RFV9IryxCyzL9mIYt-XbDKMrY0ONzTWUk2x16AKDK27VoUwEPiI9dpPXMp7f4MsrpKA-u6huZCsulh0~aAYN~x25uNoDO-WgZpfkKFeKc910u4PVnEaKLlZlpuJ0hqWUjMVPes9DfA~msToJeyjrVzLi2R8O8LuuYHsAMAHXr7E9qB8tAoDWz24CurCirxc6sB45Zc-oK9JigX0L4~F~F1TE9i39ysmQF4UrOyu0bp7MKGSDBwLE1P2C3gWNw__
Autorização baseada no CloudFront usando o CloudFront Functions
Se o token assinado nativo do CloudFront não atender aos seus requisitos de autorização, você poderá criar uma lógica de autorização personalizada usando funções de borda. Por exemplo, talvez você queira usar uma criptografia diferente para assinar tokens, como criptografia simétrica, ou talvez queira incluir atributos não padrão na assinatura, como o cabeçalho do agente do usuário, ou talvez queira implementar uma lógica de tokenização condicional com base na rede do usuário. As seguintes implementações personalizadas ilustram algumas das possibilidades das funções de borda:
- CloudFront Functions para validar o token baseado em JWT. Observe que o CloudFront Functions não permite chamadas de rede externas no momento e, consequentemente, as chaves de assinatura precisam ser armazenadas no código da função. Para reduzir o risco de armazenar a chave de assinatura no código da função do CloudFront, não configure manualmente a chave no código, mas use uma automação que alternas as chaves e gera o código da função antes da implantação no CloudFront. Dessa forma, as chaves não correm o risco de serem enviadas para repositórios públicos, como o Github.
- Solução da AWS: Secure Media Delivery at the Edge. Essa solução da AWS usa o CloudFront Functions para implementar um mecanismo de autorização personalizado adaptado para streaming de vídeo.
- Usaar o OpenID Connect para autenticar uma aplicação de página única hospedado no S3. As soluções usam o AWS Secrets Manager para armazenar chaves de assinatura e podem funcionar com um provedor de identidades (IdP) externo, como o Cognito ou o Okta. Essa implementação foi publicada antes do lançamento do CloudFront Functions e, por isso, depende totalmente do Lambda@Edge. Ele pode ser otimizado para usar o CloudFront Functions para a parte de autorização e o Lambda@Edge para a integração com IdPs.
