Restringindo o acesso do S3 a servidores individuais ao usar o endpoint S3 em um VPC privado sem IPs públicos

1

Pergunta

Como você pode restringir o acesso a um bucket S3 a uma única instância da AWS quando as instâncias não tiverem endereço IP público e você estiver usando um endpoint S3 na sua VPC?

Plano de fundo e detalhes

Temos uma VPC que tem um Virtual Private Gateway, que executa uma VPN de volta ao nosso datacenter local. O VPC não tem gateway de internet. Os servidores não possuem endereços IP públicos. Há um terminal S3 e uma tabela de rotas configurados corretamente. Digamos que haja uma sub-rede com três instâncias. Temos dois buckets do S3 ainda a serem criados, que serão criptografados.

Gostaríamos de restringir o acesso da instância A do balde A S3 e da instância B ao depósito S3 B. A instância C não deve ter acesso a nenhum dos intervalos.

Também precisamos poder enviar informações para os intervalos da Internet pública. Esse acesso deve estar disponível apenas por meio de IPs específicos, o que é fácil de usar usando políticas de bucket. Isso pode fazer a diferença na solução.

Esta página na documentação da AWS diz

You cannot use an IAM policy or bucket policy to allow access from a VPC IPv4 CIDR range (the private IPv4 address range). VPC CIDR blocks can be overlapping or identical, which may lead to unexpected results. Therefore, you cannot use the aws:SourceIp condition in your IAM policies for requests to Amazon S3 through a VPC endpoint. This applies to IAM policies for users and roles, and any bucket policies. If a statement includes the aws:SourceIp condition, the value fails to match any provided IP address or range. Instead, you can do the following:

  • Use your route tables to control which instances can access resources in Amazon S3 via the endpoint.
  • For bucket policies, you can restrict access to a specific endpoint or to a specific VPC. For more information, see Using Amazon S3 Bucket Policies.

Não podemos usar as tabelas de rotas, pois temos duas instâncias que precisam de acesso a diferentes intervalos.

Eu também li esta página , o que não ajudou na nossa situação.

Opção: chaves do KMS

Suspeito que, se dermos a cada bloco sua chave KMS e restringir o acesso às chaves da instância apropriada, apenas essa instância poderá acessar os dados descriptografados. Eu acho que isso vai funcionar, mas há alguma complexidade lá, e eu não tenho 100% de certeza, já que eu não fiz muito com o KMS.

Uma vantagem dessa abordagem é que ela nega por padrão concessões por configuração. Devido ao número de usuários da conta, não podemos confiar na configuração para negar por padrão, como foi muito bem sugerido por Alex abaixo.

Pensamentos ou sugestões de ideias

Alguém tem outras sugestões ou ideias que possamos acompanhar? Ou quaisquer pensamentos / detalhes adicionais sobre a ideia do KMS?

    
por Tim 04.10.2018 / 09:18

1 resposta

3

Minha sugestão seria usar papéis de instância. Essas são funções que podem ser assumidas por aplicativos em execução em instâncias específicas, consultando o serviço de metadados - as ferramentas da AWS oferecem suporte nativo - permitindo que os aplicativos em execução nessa instância usem essas credenciais. Mais detalhes sobre eles aqui .

Você teria, então, uma função exclusiva, por exemplo, A e outra, por exemplo, B; depois, analise essa postagem sobre o uso de políticas de balde para restringir o acesso a um intervalo com base em uma função específica. Aqui .

Isso provavelmente deve fazer o que você precisa. Embora o KMS também seja uma abordagem, mas provavelmente mais complicado. Você também pode mover as instâncias para diferentes VPCs e usar uma diretiva de ponto de extremidade para restringir o acesso com base no VPC de origem, mas isso seria muito confuso e traria outras complicações.

    
por 04.10.2018 / 10:45