Considerações de segurança para canaries do Synthetics

As seções a seguir explicam os problemas de segurança que devem ser levados em conta ao criar e executar canaries no Synthetics.

Usar conexões seguras

Como o código do canário e os resultados das execuções de teste do canário podem conter informações confidenciais, não conecte o seu canário a endpoints por conexões não criptografadas. Sempre use conexões criptografadas, como as que começam com https://.

Considerações sobre a nomenclatura de canaries

O nome do recurso da Amazon (ARN) de um canário está incluído no cabeçalho de atendente-usuário como parte das chamadas de saída feitas de um navegador Chromium orientado para Puppeteer que está incluído como parte da biblioteca wrapper do CloudWatch Synthetics. Isso ajuda a identificar o tráfego do canário do CloudWatch Synthetics e relacioná-lo de volta aos canários que estão fazendo chamadas.

O ARN do canário inclui o nome do canário. Escolha nomes do canário que não revelem informações proprietárias.

Além disso, aponte os canaries somente a sites e a endpoints controlados por você.

Segredos e informações sigilosas no código canário

Se você passar seu código canário diretamente para o canário usando um arquivo zip, o conteúdo do script poderá ser visto em logs do AWS CloudTrail.

Se você tiver informações sigilosas ou segredos (como chaves de acesso ou credenciais de banco de dados) em um script do canário, é altamente recomendável armazenar o script como um objeto versionado no Amazon S3 e passar a localização do Amazon S3 para o canário, em vez de passar o código do canário por um arquivo zip.

Se você usar um arquivo zip para transmitir o script do canário, é altamente recomendável não incluir segredos ou informações sigilosas no código-fonte do canário. Para obter mais informações sobre como usar o AWS Secrets Manager para ajudar a manter os segredos seguros, consulte O que é o AWS Secrets Manager?.

Considerações sobre permissões

Recomendamos que você restrinja o acesso aos recursos criados ou usados pelo CloudWatch Synthetics. Use permissões restritas nos buckets do Amazon S3 onde os canaries armazenam os resultados de execução de teste e outros artefatos, como logs e capturas de tela.

Da mesma maneira, mantenha permissões restritas nos locais onde o código-fonte do canário está armazenado para que nenhum usuário acidentalmente ou maliciosamente exclua as camadas do Lambda ou as funções Lambda usadas para o canário.

Para ajudar a garantir que você execute o código do canário pretendido, é possível usar o versionamento de objeto no bucket do Amazon S3 onde o código do canário está armazenado. Então, ao especificar esse código para ser executado como canário, você poderá incluir o objeto versionId como parte do caminho, conforme os exemplos a seguir.

https://bucket.s3.amazonaws.com/path/object.zip?versionId=version-id
https://s3.amazonaws.com/bucket/path/object.zip?versionId=version-id
https://bucket.s3-region.amazonaws.com/path/object.zip?versionId=version-id

Rastreamentos de pilha e mensagens de exceção

Por padrão, os canários do CloudWatch Synthetics capturam qualquer exceção lançada pelo script do canário, independetemente se o script for personalizado ou de um esquema. O CloudWatch Synthetics registra tanto a mensagem de exceção como o rastreamento de pilha em três locais:

Se quiser enviar e armazenar menos informações, será possível capturar exceções antes que elas retornem à biblioteca wrapper do CloudWatch Synthetics.

Também pode haver URLs de solicitação em seus erros. O CloudWatch Synthetics verifica se há URLs no erro gerado pelo script e edita parâmetros de URL restritos deles com base na configuração restrictedUrlParameters. Se estiver registrando mensagens de erro em seu script, poderá usar getSanitizedErrorMessage para redigir URLs antes de registrar.

Definir de forma estrita o escopo das funções do IAM

Recomendamos que você não configure o canário para acessar URLs ou endpoints possivelmente maliciosos. Apontar o canário para sites ou endpoints não confiáveis ou desconhecidos pode expor o código da função Lambda para scripts de usuários maliciosos. Supondo que um site malicioso possa escapar do Chromium, ele poderia ter acesso ao código do Lambda de maneira semelhante se você estivesse conectado a ele usando um navegador de Internet.

Execute a função Lambda com uma função de execução do IAM com permissões de escopo restrito. Dessa forma, se a função Lambda for comprometida por um script malicioso, ela estará limitada às ações que pode realizar ao ser executada como a conta da AWS do canário.

Ao usar o console do CloudWatch para criar um canário, ele será criado com uma função de execução do IAM de escopo restrito.

Redação de dados sigilosos

O CloudWatch Synthetics captura URLs, código de status, motivo de falha (se houver), cabeçalhos e corpos de solicitações e respostas. Isso permite que um usuário do canário compreenda, monitore e depure canários.

As configurações descritas nas seções a seguir podem ser definidas em qualquer ponto da execução do canário. Também é possível optar por aplicar diferentes configurações a diferentes etapas do Synthetics.

URLs de solicitação

Por padrão, o CloudWatch Synthetics registra URLs de solicitação, códigos de status e o motivo do status de cada URL nos logs do canário. URLs de solicitação também podem aparecer em relatórios de execução do canário, arquivos HAR etc. Sua URL de solicitação pode conter parâmetros de consulta sigilosos, como tokens de acesso ou senhas. É possível redigir informações sigilosas que estejam sendo registradas pelo CloudWatch Synthetics.

Para redigir informações confidenciais, defina a propriedade de configuração restrictedUrlParameters. Para ter mais informações, consulte Classe SyntheticsConfiguration. Isso faz com que o CloudWatch Synthetics edite parâmetros de URL, inclusive valores de parâmetros de caminho e consulta, com base em restrictedUrlParameters antes de registrar. Se estiver registrando URLs em seu script, poderá usar getSanitizedUrl(url, stepConfig = null) para redigir URLs antes de registrar. Para ter mais informações, consulte SyntheticsLogHelper class.

Cabeçalhos

Por padrão, o CloudWatch Synthetics não registra cabeçalhos de solicitação/resposta. Para canaries de interface do usuário, este é o comportamento padrão para canaries que usam a versão de runtime syn-nodejs-puppeteer-3.2 e posteriores.

Caso seus cabeçalhos não contenham informações sigilosas, será possível habilitar cabeçalhos no arquivo HAR e nos relatórios HTTP definindo as propriedades includeRequestHeaders e includeResponseHeaders como true. É possível habilitar todos os cabeçalhos, mas optar por restringir valores de chaves de cabeçalho sigilosos. Por exemplo, você pode optar por apenas redigir cabeçalhos Authorization de artefatos produzidos por canaries.

Corpo da solicitação e da resposta

Por padrão, o CloudWatch Synthetics não registra o corpo da solicitação/resposta em logs e relatórios do canário. Essa informação é útil principalmente para canaries da API. O Synthetics captura todas as solicitações HTTP e pode exibir corpos de cabeçalhos, de solicitações e de respostas. Para ter mais informações, consulte executeHttpStep(stepName, requestOptions, [callback], [stepConfig]). Você pode optar por habilitar o corpo da solicitação/resposta definindo as propriedades includeRequestBody e includeResponseBody como true.