Estabelecendo controles granulares de rede com VPC Endpoint e API Gateway

Quando clientes iniciam sua jornada para nuvem é muito comum tentarem replicar o mesmo modelo operacional do ambiente on-premises inclusive o de gestão de rede, contudo trazer esta governança exatamente como ela foi concebida no ambiente on-premises pode trazer dificuldades.

Empresas que seguem as recomendações da AWS para o uso de ambientes com várias contas precisam gerenciar muitos pontos de conexões entre o ambiente on-premises e as contas da AWS o que pode levar muito tempo. A disponibilidade de blocos de IP livres acaba sendo um desafio para seguir essa boa prática.

Segregação de conexão

Um requisito bastante comum em empresas é a segregação da comunicação entre os diversos ambientes das aplicações. É comum as empresas implementarem Virtual routing and forwarding (VRF) para criar segmentações no ambiente on-premises. Com isso, por exemplo, uma aplicação no ambiente de desenvolvimento não pode se comunicar com outra aplicação no ambiente de produção, e vice-versa.

Imagem 2: Segmentação de conexões usando VPC Endpoint.

Utilizando um VPC Endpoint para cada tipo de ambiente, teremos uma segmentação das conexões conforme os requisitos de segurança. Você pode fazer uma associação de um para um entre a quantidade de endpoints e a quantidade de VRF’s.

Políticas de perímetro

Em ambientes on-premises tradicionais, uma rede confiável e uma autenticação forte são a base da segurança. Onde estabelecem um perímetro de alto nível para impedir a entrada de entidades não confiáveis e a saída de dados. Esse perímetro fornece um limite claro de confiança e propriedade.

Você pode estabelecer um perímetro de dados usando guardrails que restringem o acesso fora dos limites de uma organização. Isso é obtido usando três recursos principais da AWS, políticas de controle de serviço (SCP) do AWS Organizations, políticas baseadas em recursos e políticas de VPC endpoint.

Aplicando as políticas do AWS Identity and Access Management (IAM) podemos estabelecer perímetros em três principais níveis: VPC Endpoint, API Gateway e Organizational Unit (OU) da Organização.

Política para ser aplicada no VPC Endpoint.

{
"Version": "2012-10-17",

      "Statement": [

           {

                 "Effect": "Allow",

                 "Principal": "*",

                 "Action": "*",

                 "Resource": "*",

                 "Condition": {

                      "StringEquals": {

                            "aws:ResourceOrgID": "o-1a2b3c4d5e"

                      },

                      "ForAnyValue:StringLike": {

                            "aws:ResourceOrgPaths": [

                                 "o-1a2b3c4d5e/r-ab12/ou-ab12-1111/*"

                            ]

                      },

                      "IpAddress": {

                            "aws:VpcSourceIp": "10.10.10.0/24"

                      }

                 }

           }

      ]

}

Nas condições da política aplicada no VPC Endpoint podemos observar o uso de uma condição com várias chaves ou valores “aws:ResourceOrgID” que indica o ID da organização da AWS do recurso que está sendo acessado. Além da segunda condição “aws:ResourceOrgPaths” que indica o caminho da organização do recurso que está sendo acessado, além da condição “aws:VpcSourceIp” para restringir o IP de origem, onde o bloco 10.10.10.0/24 representa o nosso ambiente on-premises, Dev ou Prod. Cada VPC Endpoint terá a sua própria política onde a Organizational Unit (OU) será diferente e o bloco de IP de origem também será diferente.

Política para ser aplicada no API Gateway.

{

"Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Deny",

            "Principal": "*",

            "Action": "execute-api:Invoke",

            "Resource": "arn:aws:execute-api:sa-east-1:12341234:1a2b3c/*",

            "Condition": {

                "StringNotEquals": {

                    "aws:SourceVpce": "vpce-12345abcde"

                }

            }

        },

        {

            "Effect": "Allow",

            "Principal": "*",

            "Action": "execute-api:Invoke",

            "Resource": "arn:aws:execute-api:sa-east-1: 12341234:1a2b3c/*"

        }

    ]

}

Nas condições da política aplicada no API Gateway podemos observar o uso da condição “aws:SourceVpce” que indica o ID do VPC Endpoint da conta central de Network. Cada ambiente da sua organização terá um VPC Endpoint específico, portanto a política aplicada no API Gateway deve utilizar o VPC Endpoint ID específico do seu ambiente.

Política para ser aplicada na OU da Organização.

{

"Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Deny",

            "Action": "execute-api:Invoke",

            "Resource": "*",

            "Condition": {

                "StringNotEquals": {

                    "aws:SourceVpce": "vpce-12345abcde"

                }

            }

        }

    ]

}

Nas condições da política aplicada na OU podemos observar o uso da chave de condição “aws:SourceVpce” que indica o ID do VPC Endpoint da conta central de Network, aonde cada OU terá sua própria política restringindo qual VPC Endpoint pode ser utilizado.

Dessa maneira conseguimos restringir o perímetro em diferentes pontos, conforme os diagramas abaixo:

Imagem 3: Conta externa sem permissão de conexão usando o VPC Endpoint através da política plicada.