Acesso centralizado a endpoints VPC privados

Um VPC endpoint permite que você conecte você de forma privada VPC aos AWS serviços compatíveis sem precisar de um gateway de internet ou de um NAT dispositivo, VPN conexão ou AWS Direct Connect conexão. Portanto, você não VPC está exposto à Internet pública. As instâncias em seu VPC não exigem endereços IP públicos para se comunicar com os endpoints AWS de serviço com esse endpoint de interface. O tráfego entre seus VPC e outros serviços não sai do backbone da AWS rede. VPCendpoints são dispositivos virtuais. Eles são componentes dimensionados horizontalmente, redundantes e altamente disponíveis. VPC Atualmente, dois tipos de endpoints podem ser provisionados: endpoints de interface (alimentados por AWS PrivateLink) e endpoints de gateway. Os endpoints do gateway podem ser utilizados para acessar os serviços Amazon S3 e Amazon DynamoDB de forma privada. Não há cobrança adicional pelo uso de endpoints do gateway. Aplicam-se as cobranças padrão pela transferência de dados e pela utilização de recursos.

VPC endpoints de interface

Um endpoint de interface consiste em uma ou mais interfaces de rede elásticas com um endereço IP privado que serve como ponto de entrada para o tráfego destinado a um serviço compatível AWS . Quando você provisiona um endpoint de interface, um custo é incorrido por cada hora em que o endpoint está funcionando junto com as cobranças de processamento de dados. Por padrão, você cria um endpoint de interface em cada um VPC dos quais deseja acessar o AWS serviço. Isso pode ter um custo proibitivo e desafiador de gerenciar na configuração da Landing Zone, em que um cliente deseja interagir com um serviço específico em váriosAWS. VPCs Para evitar isso, você pode hospedar os endpoints da interface de forma centralizadaVPC. All the spoke VPCs usará esses endpoints centralizados via Transit Gateway.

Ao criar um VPC endpoint para um AWS serviço, você pode ativar o modo privadoDNS. Quando ativada, a configuração cria uma zona hospedada privada AWS gerenciada do Route 53 (PHZ), que permite a resolução do endpoint de AWS serviço público para o IP privado do endpoint da interface. O gerenciado PHZ só funciona dentro do VPC endpoint da interface. Em nossa configuração, quando queremos que o spoke seja VPCs capaz de resolver VPC endpoints DNS hospedados de forma centralizadaVPC, o gerenciado não PHZ funcionará. Para superar isso, desative a opção que cria automaticamente o privado DNS quando um endpoint de interface é criado. Em seguida, crie manualmente uma zona hospedada privada do Route 53 que corresponda ao nome do endpoint do serviço e adicione um registro de Alias com o nome completo do AWS service (Serviço da AWS) endpoint apontando para o endpoint da interface.

1. Faça login AWS Management Console e navegue até o Route 53.

2. Selecione a zona hospedada privada e navegue até Criar registro.

3. Preencha o campo Nome do registro, selecione Tipo de registro como A e ative o Alias.

   Observe que alguns serviços, como o Docker e o OCI client endpoints (dkr.ecr), exigem que um alias curinga (*) seja usado para o nome do registro.

4. Na seção Rotear tráfego para, selecione o serviço para o qual o tráfego deve ser enviado e selecione a região na lista suspensa.

5. Selecione a política de roteamento apropriada e ative a opção Avaliar a integridade do alvo.

Você associa essa zona hospedada privada a outra VPCs dentro da Landing Zone. Essa configuração permite que o spoke resolva VPCs os nomes dos endpoints de serviço completo para interfacear os endpoints no centralizado. VPC

nota

Para acessar a zona hospedada privada compartilhada, os hosts no spoke VPCs devem usar o IP do Resolvedor Route 53 de seusVPC. Os endpoints de interface também podem ser acessados a partir de redes locais VPN e do Direct Connect. Use regras de encaminhamento condicional para enviar todo o DNS tráfego dos nomes de endpoints de serviço completo para os endpoints de entrada do Route 53 Resolver, que resolverão as DNS solicitações de acordo com a zona hospedada privada.

Na figura a seguir, o Transit Gateway permite o fluxo de tráfego do raio VPCs para os terminais da interface centralizada. Crie VPC endpoints e a zona hospedada privada para eles na conta de serviços de rede e compartilhe-os com as contas spoke VPCs in the spoke. Para obter mais detalhes sobre o compartilhamento de informações de endpoints com outras pessoasVPCs, consulte a postagem do blog Integrating AWS Transit Gateway with AWS PrivateLink and Amazon Route 53 Resolver.

nota

Uma abordagem de VPC endpoint distribuído, ou seja, um endpoint per VPC permite que você aplique políticas de privilégios mínimos em endpoints. VPC Em uma abordagem centralizada, você aplicará e gerenciará políticas para VPC acesso integral em um único endpoint. Com o aumento do número deVPCs, a complexidade de manter o mínimo de privilégios com um único documento de política pode aumentar. Um único documento de política também resulta em um raio de explosão maior. Você também está restrito quanto ao tamanho do documento de política (20.480 caracteres).

Centralizando os endpoints da interface VPC

Acesso a endpoints entre regiões

Quando você quiser várias VPCs configurações em diferentes regiões que compartilham um VPC endpoint comum, use umPHZ, conforme descrito anteriormente. Ambos VPCs em cada região serão associados ao PHZ com o alias do endpoint. Para rotear o tráfego VPCs em uma arquitetura multirregional, os gateways de trânsito em cada região precisam ser interligados. Para obter mais informações, consulte este blog: Usando zonas hospedadas privadas do Route 53 para arquiteturas multirregionais entre contas.

VPCsde diferentes regiões podem ser roteados entre si usando Transit Gateways ou VPC Peering. Use a seguinte documentação para emparelhar os Transit Gateways: Transit Gateway peering attachments.

Neste exemplo, a EC2 instância da Amazon na VPC us-west-1 região usará o PHZ para obter o endereço IP privado do endpoint na us-west-2 região e rotear o tráfego para a região pelo peering ou VPC peering do Transit Gateway. us-west-2 VPC Usando essa arquitetura, o tráfego permanece dentro da AWS rede, permitindo com segurança que a EC2 instância acesse o VPC serviço us-west-2 sem passar pela Internet. us-west-1

Endpoints multirregionais VPC

nota

As taxas de transferência de dados entre regiões se aplicam ao acessar endpoints em todas as regiões.

Referindo-se à figura anterior, um serviço de endpoint é criado VPC em uma us-west-2 região. Esse serviço de endpoint fornece acesso a um AWS serviço nessa região. Para que suas instâncias em outra região (comous-east-1) acessem o endpoint na us-west-2 região, você precisa criar um registro de endereço PHZ com um alias para o endpoint desejadoVPC.

Primeiro, certifique-se de que os VPCs em cada região estejam associados ao PHZ que você criou.

Ao implantar um endpoint em várias zonas de disponibilidade, o endereço IP do endpoint retornado DNS será de qualquer uma das sub-redes alocadas na zona de disponibilidade.

Ao invocar o endpoint, use o nome de domínio totalmente qualificado (FQDN) que está no. PHZ

Acesso Verificado pela AWS

Acesso Verificado pela AWS fornece acesso seguro a aplicativos em rede privada sem umVPN. Ele avalia as solicitações em tempo real, como identidade, dispositivo e localização. Esse serviço concede acesso com base na política para aplicativos e conecta os usuários, melhorando a segurança da organização. O Acesso Verificado fornece acesso a aplicativos privados atuando como um proxy reverso com reconhecimento de identidade. A identidade do usuário e a integridade do dispositivo, se aplicável, são executadas antes de rotear o tráfego para o aplicativo.

O seguinte diagrama fornece uma visão geral de alto nível sobre como o Acesso Verificado funciona. Os usuários enviam solicitações para acessar um aplicativo. O Acesso Verificado avalia a solicitação em relação à política de acesso do grupo e a qualquer política de endpoint específica do aplicativo. Se o acesso for permitido, a solicitação será enviada para o aplicativo por meio do endpoint.

Visão geral do acesso verificado

Os principais componentes de uma Acesso Verificado pela AWS arquitetura são:

• Instâncias de Acesso Verificado: uma instância avalia as solicitações de aplicativos e concede acesso somente quando seus requisitos de segurança são atendidos.

• Endpoints de Acesso Verificado: cada endpoint representa um aplicativo. Um endpoint pode serNLB, ALB ou interface de rede.

• Grupo de Acesso Verificado: uma coleção de endpoints de Acesso Verificado. Recomendamos que você agrupe os endpoints para aplicativos com requisitos de segurança semelhantes para simplificar a administração de políticas.

• Políticas de acesso: um conjunto de regras definidas pelo usuário que determinam se o acesso a um aplicativo deve ser permitido ou negado.

• Provedores de confiança — O Acesso Verificado é um serviço que facilita o gerenciamento das identidades dos usuários e dos estados de segurança do dispositivo. É compatível com provedores confiáveis AWS e terceirizados, exigindo que pelo menos um provedor de confiança seja anexado a cada instância de acesso verificado. Cada uma dessas instâncias pode incluir um único provedor de confiança de identidade, bem como vários provedores de confiança de dispositivos.

• Dados confiáveis — Os dados de segurança que seu provedor de confiança envia ao Verified Access, como o endereço de e-mail do usuário ou o grupo ao qual ele pertence, são avaliados de acordo com suas políticas de acesso sempre que uma solicitação de aplicativo é recebida.

Mais detalhes podem ser encontrados nas postagens do blog do Verified Access.