Introdução
O caminho público de uma aplicação de entregas já funciona, mas a regra fornecida permite HTTP de qualquer origem IPv4. Você atribuirá à aplicação um grupo de segurança separado que permita somente o cliente e a porta previstos. Solicitações reais mostrarão como restrições de origem, de porta e respostas com estado afetam o acesso.
Conclua primeiro “Conectar uma sub-rede pública à Internet”. Este ambiente novo fornece sua própria rede, endereço público, rotas e aplicação; ele não reutiliza sua VM anterior. A CLI já está configurada. Preserve os recursos fornecidos e a rede de referência alheia ao exercício. Apenas o novo grupo de segurança é um recurso de prática a excluir.
Relação com certificações
Este laboratório oferece prática para os seguintes tópicos de exame.
- Cloud Practitioner (CLF-C02) · Tarefa 3.5: controles de acesso com grupos de segurança em uma VPC.
- Solutions Architect – Associate (SAA-C03) · Tarefa 1.2: controles básicos de segurança de aplicações para origens, portas e protocolos de rede.
- CloudOps Engineer – Associate (SOA-C03) · Tarefas 5.1 e 5.3: configuração básica de grupos de segurança e verificação do efeito sobre a conectividade.
- Security – Specialty (SCS-C03) · Tarefa 3.3: prática fundamental de permitir e impedir o tráfego necessário com grupos de segurança.
Associar um grupo de segurança de prática vazio
Nesta etapa, você inspecionará a aplicação funcional e substituirá seu grupo de acesso amplo por seu próprio grupo vazio.
Execute comandos em Terminal e clique em AWS View ao lado. A visualização lê o mesmo estado dos recursos que a CLI. Ela mostra application-network, suas sub-redes pública e privada e uma aplicação no endereço privado 10.20.1.10. O endereço público e a rota para o gateway de Internet já são fornecidos; não os altere.
cd /home/labex/project
Selecione a VPC pela tag Name. --filters limita os resultados do servidor, --query seleciona o ID e $(...) salva o resultado em uma variável do shell:
VPC_ID=$(aws ec2 describe-vpcs \
--filters Name=tag:Name,Values=application-network \
--query 'Vpcs[0].VpcId' \
--output text)
Selecione a interface fornecida da aplicação dentro dessa VPC:
ENI_ID=$(aws ec2 describe-network-interfaces \
--filters "Name=vpc-id,Values=$VPC_ID" Name=tag:Name,Values=application-interface \
--query 'NetworkInterfaces[0].NetworkInterfaceId' \
--output text)
Um grupo de segurança controla o tráfego permitido na interface de rede do recurso associado. Regras de entrada permitem tráfego que chega à aplicação; regras de saída permitem tráfego que ela inicia. Salve o ID do único grupo fornecido para restaurá-lo na limpeza. [0] seleciona o primeiro item desta lista com um só grupo:
SUPPLIED_GROUP_ID=$(aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[0].Groups[0].GroupId' \
--output text)
Leia as regras sem alterá-las:
aws ec2 describe-security-groups \
--group-ids "$SUPPLIED_GROUP_ID" \
--query 'SecurityGroups[].{ID:GroupId,Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
--output json
O grupo fornecido permite TCP de entrada na porta 80 de 0.0.0.0/0, ou seja, qualquer origem IPv4, e todo o tráfego de saída. HTTP usa solicitações e respostas; uma porta identifica o serviço receptor. A aplicação oferece HTTP nas portas TCP 80 e 8081, mas a regra fornecida permite somente a porta 80.
Em AWS View, clique em Request application · client A e depois em Request application · client B. Ambos retornam Success e Application online na porta 80. O cliente A usa 198.51.100.10; B usa 198.51.100.20. Clique em Request port 8081; essa solicitação do cliente A falha porque a porta não é permitida.
Crie um grupo separado na mesma VPC. --group-name define o nome, --description explica a finalidade e a especificação de tags entre aspas adiciona tags de propriedade como um único argumento. Salve o novo ID:
GROUP_ID=$(aws ec2 create-security-group \
--group-name parcel-web \
--description "Parcel HTTP access" \
--vpc-id "$VPC_ID" \
--tag-specifications 'ResourceType=security-group,Tags=[{Key=Name,Value=parcel-web},{Key=Project,Value=parcel}]' \
--query 'GroupId' \
--output text)
Um grupo novo não tem permissões de entrada e permite todo o tráfego de saída. Grupos de segurança contêm regras de permissão, não regras de negação explícita. Tráfego sem uma regra de permissão correspondente é bloqueado.
--groups substitui a lista de grupos da interface. Associe somente seu novo grupo; manter também o grupo amplo combinaria suas permissões e continuaria permitindo os dois clientes:
aws ec2 modify-network-interface-attribute \
--network-interface-id "$ENI_ID" \
--groups "$GROUP_ID"
Uma alteração bem-sucedida não produz saída. Confirme que a interface agora tem somente seu grupo:
aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[].{ID:NetworkInterfaceId,Groups:Groups}' \
--output json
AWS View agora mostra parcel-web e Inbound · none. Envie novas solicitações dos clientes A e B; ambas passam a Connection failed. O endereço público e a rota permanecem, mas o grupo vazio não permite solicitações de entrada. Mantenha este Terminal aberto para conservar os IDs salvos.
Permitir somente o cliente HTTP previsto
Nesta etapa, você concederá ao cliente A acesso à porta 80 e verificará que a outra origem e a outra porta permanecem bloqueadas.
Uma regra de entrada especifica um protocolo, um intervalo de portas e uma origem. --protocol tcp seleciona TCP, --port 80 seleciona somente essa porta e --cidr 198.51.100.10/32 seleciona apenas o endereço IPv4 do cliente A. Um /32 contém um endereço IPv4 e é mais restrito que 0.0.0.0/0.
Adicione a regra ao seu grupo, não ao grupo fornecido:
aws ec2 authorize-security-group-ingress \
--group-id "$GROUP_ID" \
--protocol tcp \
--port 80 \
--cidr 198.51.100.10/32
A resposta indica sucesso e pode incluir o novo ID de regra. Leia todas as regras de entrada:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissions' \
--output json
Há uma regra TCP com FromPort e ToPort iguais a 80 e origem 198.51.100.10/32. AWS View mostra a mesma origem e porta de entrada.
Clique em Request application · client A. O resultado é Success, origem 198.51.100.10, porta de destino 80 e corpo Application online. Essa é uma resposta real da aplicação fornecida.
Agora clique em Request application · client B e Request port 8081. Ambos retornam Connection failed. A primeira solicitação tem a origem errada; a segunda usa o cliente A, mas a porta errada. Um endereço público e uma rota fornecem um caminho, enquanto o grupo de segurança decide qual tráfego pode usá-lo.
Testar e remover uma permissão temporária de porta
Nesta etapa, você demonstrará que uma segunda porta em escuta só fica acessível quando sua própria regra existe e depois removerá a permissão temporária.
A aplicação fornecida também oferece HTTP na porta 8081. Mantenha a mesma origem permitida e adicione uma regra temporária para essa porta:
aws ec2 authorize-security-group-ingress \
--group-id "$GROUP_ID" \
--protocol tcp \
--port 8081 \
--cidr 198.51.100.10/32
Leia as regras novamente:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissions' \
--output json
Agora há duas regras TCP: portas 80 e 8081, ambas restritas ao cliente A. AWS View mostra as duas. Clique em Request port 8081. O resultado muda para Success, com porta de destino 8081 e corpo Application online. Isso confirma que o segundo serviço está funcionando; a falha anterior era uma restrição da regra de acesso.
Exemplo de AWS View: as duas regras de entrada restritas estão presentes e o cliente A recebe a resposta da aplicação na porta 8081. Os IDs gerados dos recursos serão diferentes no seu ambiente.
O exercício requer apenas a porta 80. Revogar uma regra remove sua permissão. Especifique o mesmo protocolo, porta e origem para remover somente a regra temporária:
aws ec2 revoke-security-group-ingress \
--group-id "$GROUP_ID" \
--protocol tcp \
--port 8081 \
--cidr 198.51.100.10/32
A resposta indica sucesso. Consulte as regras resultantes:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissions' \
--output json
Permanece apenas a regra da porta 80 do cliente A. Quando AWS View remover a regra de 8081, clique novamente em Request port 8081; agora a solicitação falha. A porta 80 do cliente A continua funcionando, e a do cliente B continua falhando. Você mudou uma permissão de porta sem substituir a aplicação ou sua rota.
Observar respostas HTTP com estado
Nesta etapa, você removerá a regra de saída padrão do seu grupo e confirmará que as respostas ao HTTP de entrada permitido ainda funcionam.
Grupos de segurança mantêm o estado das conexões: uma resposta a uma solicitação de entrada permitida pode sair da aplicação mesmo sem uma regra de saída que permita uma nova conexão. Uma regra de saída governa o tráfego iniciado pela aplicação; ela não é necessária para permitir essa resposta HTTP.
Leia suas permissões de saída atuais:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissionsEgress' \
--output json
O grupo novo tem o destino padrão 0.0.0.0/0 para todo o tráfego. No próximo comando, --ip-permissions recebe uma lista JSON de especificações de regras como um único argumento entre aspas. O valor -1 de IpProtocol significa todos os protocolos, e IpRanges identifica os destinos de uma regra de saída. Remova exatamente essa regra padrão:
aws ec2 revoke-security-group-egress \
--group-id "$GROUP_ID" \
--ip-permissions '[{"IpProtocol":"-1","IpRanges":[{"CidrIp":"0.0.0.0/0"}]}]'
A resposta indica sucesso. Leia as duas direções:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].{Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
--output json
A entrada ainda permite somente o cliente A na porta 80; a saída está vazia. AWS View mostra Outbound · none. Clique novamente em Request application · client A. Success e Application online ainda são retornados: a resposta pertence à conexão de entrada permitida.
Verifique novamente Request application · client B e Request port 8081. Ambos ainda falham. Respostas com estado não concedem novo acesso de entrada a outra origem ou porta. Esse teste comprova o comportamento de resposta; ele não testa uma nova conexão de saída iniciada pela aplicação.
Exemplo de AWS View: a entrada permite somente o cliente A na porta 80, a saída está vazia e a resposta HTTP real ainda funciona. Os IDs gerados dos recursos serão diferentes no seu ambiente.
Restaurar o grupo fornecido e excluir o seu
Nesta etapa, você restaurará a associação original da aplicação e excluirá somente seu grupo de segurança de prática.
Um grupo associado a uma interface de rede não pode ser excluído. Primeiro substitua seu grupo pelo grupo fornecido que foi salvo; não exclua nem edite o grupo fornecido:
aws ec2 modify-network-interface-attribute \
--network-interface-id "$ENI_ID" \
--groups "$SUPPLIED_GROUP_ID"
Confirme a associação:
aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[].{ID:NetworkInterfaceId,Groups:Groups}' \
--output json
Somente o grupo original supplied-application está associado. Agora exclua seu grupo que não está mais em uso:
aws ec2 delete-security-group --group-id "$GROUP_ID"
Uma exclusão bem-sucedida não produz saída. Consulte o inventário completo de grupos para demonstrar a ausência independentemente de tags que podem ser removidas:
aws ec2 describe-security-groups \
--query 'SecurityGroups[].{ID:GroupId,Name:GroupName,VPC:VpcId}' \
--output table
parcel-web está ausente. Os grupos fornecido e padrão permanecem, assim como VPCs, sub-redes, interface da aplicação, endereço público e rotas. Uma falha na consulta do inventário não comprova a exclusão.
AWS View mostra supplied-application novamente. Clique nos botões de solicitação dos clientes A e B; ambos retornam Success na porta 80, como no estado inicial. Request port 8081 falha porque o grupo fornecido, que não foi alterado, permite somente a porta 80.
Execute a verificação de conclusão desta etapa.
Resumo
Você criou e associou um grupo de segurança separado, permitiu apenas o cliente A na porta TCP 80, testou e revogou uma permissão temporária de segunda porta e confirmou respostas HTTP com estado sem permissões de saída. Solicitações reais distinguiram tráfego permitido e bloqueado. Por fim, restaurou o grupo fornecido e excluiu apenas seu grupo de prática.
Continue com “Dar acesso de saída a uma sub-rede privada” para construir o caminho de saída de uma aplicação privada sem permitir acesso externo não solicitado.
