O blog da AWS

Caso de Sucesso: Como o IFRN criou um modelo de arquitetura com alta disponibilidade e resiliência do Sistema Unificado de Administração Pública com a AWS

Por Cristiano Scandura, Solutions Architect, Education, Brazil Public Sector,

Lucas Pereira, IT Analyst, IFRN,

Hugo Sena, IT Analyst, IFRN,

Carlos Breno, IT Analyst, IFRN,

José Augusto, IT Analyst, IFRN,

Welkson Medeiros, IT Analyst, IFRN,

Misael Queiroz, IT Analyst, IFRN.

 

 

O Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte (IFRN) é uma instituição que oferece educação básica, profissional e superior, de forma “pluricurricular”. É uma instituição multicampi, especializada na oferta de educação profissional e tecnológica nas diferentes modalidades de ensino, com base na conjugação de conhecimentos técnicos e tecnológicos às suas práticas pedagógicas. Criado mediante transformação do Centro Federal de Educação Tecnológica do Rio Grande do Norte (CEFET-RN), o IFRN possui hoje unidades de ensino em diversas regiões estratégicas do estado.

Visão Geral

O Sistema Unificado de Administração Pública (SUAP) foi criado pelo IFRN, que segue sendo mantenedor, e é utilizado por 49 instituições públicas no Brasil, com uma média de 185 mil usuários por dia. Criado em 2007, o SUAP é um sistema modular mantido por um time de 31 profissionais especializados, que trabalham constantemente em sua evolução. O sistema conta com 30 módulos que abrangem atividades como recursos humanos, almoxarifado, patrimônio, processo eletrônico e frota, que convergem para a gestão educacional. Visa atender ações desenvolvidas pelas Reitorias, Pró-Reitorias, Diretorias Sistêmicas e Direções-Gerais dos Campi das instituições.

 

O Desafio

Existe uma grande complexidade para se manter no ar um sistema crítico com muitas solicitações, além dos custos envolvidos com links redundantes, geradores, manutenção de hardware, entre outros. Deste modo, garantir a alta disponibilidade e a resiliência do SUAP é crucial, exigindo uma arquitetura desenhada para utilizar múltiplas zona de disponibilidade. Além disso, deve utilizar serviços da AWS que possam ser capazes de automaticamente recuperar-se de falhas.

Da mesma forma, o controle de custos é uma preocupação. Se faz necessário uma gestão de alertas e monitoramento dos gastos em nuvem. Tomando o indicativo de otimização de custos, avalia-se a reconstrução de alguns componentes do SUAP com serviços de menores custos.

Outro fator de preocupação é a segurança da aplicação, pois o SUAP trabalha com dados sensíveis. Assim, a nova arquitetura tem que garantir a monitoração de todo ambiente, exigindo camadas de proteção nas interfaces públicas, além de isolamento dos ambientes e a criptografia dos dados tanto em repouso quanto em trânsito.

 

A Solução

O SUAP é uma aplicação web desenvolvida em Python e Django. Utiliza banco de dados PostgreSQL, o LDAP para autenticação dos usuários, e o REDIS como solução de cache. O primeiro passo ao levar para a AWS é criar uma arquitetura inicial de referência, aplicando pequenas alterações ou modernizações, mas que permitisse ser evoluída e que trouxesse ganhos na sua implantação. Logo, a arquitetura criada para atender os requisitos contém componentes distribuídos em múltiplas zonas de disponibilidade, e o uso de serviços gerenciados. Veja o desenho abaixo:

Tabela 1 – Arquitetura de Referência SUAP na AWS

O uso combinado do Amazon Route 53, do Amazon CloudFront e do Amazon Simple Storage Services (S3) , permitiu ao time do IFRN separar os arquivos estáticos da aplicação sem demandar muito esforço, com regras de redirecionamento das requisições criadas no CloudFront. Para a criptografia nas conexões HTTPS, foi usado o AWS Certificate Manager (ACM), serviço que faz a gestão dos certificados SSL/TLS, com a renovação dos certificados de forma automática e sem custos.

Para o back-end foi criada uma Amazon Virtual Private Cloud (VPC) com 3 subnets em cada zona de disponibilidade, sendo uma DMZ com um NAT Gateway, uma subnet privada para a aplicação, e outra subnet privada para camada de persistência de dados.

O uso do Amazon Relational Database (RDS) em múltiplas zonas de disponibilidade permitiu ao SUAP ter alta disponibilidade e resiliência. Caso uma AZ fique indisponível, o próprio RDS vai garantir o redirecionamento das chamadas ao banco de dados feitos pela a aplicação. Sendo um serviço gerenciado pela AWS, permitiu ao time do IFRN se concentrar na aplicação.

Seguindo com a simplicidade, o Amazon Elasticache for Redis, permitiu ao time do IFRN montar um cluster para a gestão das seções dos usuários do SUAP em multi-AZ.

O primeiro passo na modernização da arquitetura foi a utilização de containers e sua orquestração com o uso do Amazon Elastic Containers Services (ECS). Inicialmente o time criou uma imagem do container e a registrou no Amazon Elastic Container Registry (ECR). A facilidade de uso do ECS com o AWS Fargate, e o fato do time do IFRN não ter a responsabilidade de gerenciar as maquinas virtuais, influenciaram na decisão de não utilizar instâncias EC2. Outro ponto importante é o fato de que o ECS se encarrega de disponibilizar as Tasks em ambas AZs automaticamente, e escalando conforme a demanda com o monitoramento de alarmes do Cloudwatch.

Todas as requisições que vem do front-end para o back-end são distribuídas utilizado o Application Load Balancer (ALB), o balanceador de carga da AWS em camada 7, com certificado SSL/TLS gerado e mantido pelo ACM.

Para reduzir o custo da solução, uma alteração do código do SUAP foi efetuada para que arquivos temporários fossem armazenados no S3, dispensando a necessidade de um volume de dados compartilhado entre os containers. Dessa maneira, não foi necessário usar um serviço de compartilhamento de arquivos como o Amazon Elastic File System (EFS).

Para a autenticação dos usuários, foi debatido a necessidade de uma conexão VPN site-to-site entre o data center do IFRN e a AWS. Além disso, ter em cada zona de disponibilidade um Managed Microsoft Active Directory, utilizando o AWS Directory Service, e estabelecendo a relação de confiança com o AD primário do data-center do IFRN.

 

Monitoração

O time da IT Expert, parceiro AWS que ajudou na Prova de Conceito (PoC) da nova arquitetura do SUAP, desenvolveu um dashboard com o Amazon Cloudwatch. Desta forma, alertas foram criados para notificar o time do IFRN em caso de eventos relacionados a operação, como limites de gastos e alertas de segurança, utilizando o AWS Simple Notification Service.

 

Segurança

Para reduzir a superfície de ataque, foram criadas subnets privadas e Security Groups com regras especificas de acesso, para garantir o isolamento dos recursos. Assim, somente a subnet da aplicação pode acessar os endpoints dos serviços na camada de persistência. Existe também a recomendação para criar diferentes contas por tipo de ambiente: uma para produção, uma para homologação, e assim por diante. Em seguida, permitir acesso a conta de produção e seus recursos usando regras IAM com o nível adequado de acesso para cada grupo de usuários.

Para proteger o SUAP contra ataques DDoS, as interfaces expostas para os usuários pela Internet são apenas o CloudFront e o Route 53. O ALB foi configurado com restriçoes de acesso permitindo apenas soliticações originadas do Cloudfront. Além disto, todos os clientes da AWS se beneficiam gratuitamente com as proteções automáticas do AWS Shield Standard, aplicadas por padrão no CloudFront e no Route 53. Isso oferece uma proteção abrangente de disponibilidade contra todos os ataques conhecidos de infraestrutura (camadas 3 e 4).

A distribuição do CloudFront foi associado o AWS Web Application Firewall (WAF) para proteger o SUAP contra ataques de API e aplicações WEB. O WAF controla o tráfego originado de bots e bloqueia padrões de ataque comuns, como injeção de SQL ou cross-site scripting.

Foram utilizados os certificados SSL/TLS emitidos gratuitamente pelo ACM para proteção de dados em trânsito e estabelecer a identidade do front-end na Internet. Além disso, todos os dados em repouso foram criptografados utilizando chaves gerenciadas pelo AWS Key Management Service (KMS) ou por chaves gerenciadas pelo S3 (SSE-S3).

Para a aplicação acessar os dados armazenados no S3 a partir da subnet privada, foi implementado um S3 PrivateLink Endpoint e uma IAM Role associada ao container com as devidas permissões. Para controle de variáveis de ambiente, foi utilizado o AWS Systems Manager Parameter Store para armazenar chaves e senhas criptografadas.

 

Próximos Passos

Para continuar a evolução da arquitetura do SUAP, planeja-se criar um script de CloudFormation visando padronizar e automatizar a implementação da infraestrutura necessária, além da implantação de esteiras de CI/CD seguindo em um modelo DevOps. Há também um plano de transformação da arquitetura monolítica para micro-serviços.

 

Conclusão

Como vimos neste aqui, ao planejar uma migração é importante entender os requisitos técnicos. Também é fundamental exercitar os serviços a serem utilizados que permitam ao time de desenvolvedores focarem no negócio. Além disso, a transferência de conhecimento feita pela a AWS e o parceiro para o IFRN, foram fundamentais para a construção de uma arquitetura altamente disponível, resiliente e segura.

 

 


Sobre os autores

Lucas Pereira é analista de TI do IFRN desde 2012 e atualmente está como Diretor de sistemas do IFRN. Formado pelo próprio IFRN acredita que a colaboração é a chave para a prestação de serviço público de qualidade e que através do SUAP o IFRN e a rede federal de ensino sempre será referência em inovação tecnológica.

 

 

 

Hugo Sena trabalha com TI a mais de 15 anos, ingressando como Analista de TI no IFRN em 2013. Atualmente, atua como Engenheiro DevOps para o sistema SUAP do próprio IFRN.

 

 

 

 

 

Carlos Breno é analista de TI do IFRN desde 2010 e coordenou o desenvolvimento do SUAP EDU (módulo acadêmico do Sistema Unificado de Administração Pública). Contribuiu na construção de diversos outros módulos e atualmente é envolvido no desenvolvimento, operação e capacitação do SUAP.

 

 

 

 

José Augusto trabalha com TI a mais de 20 anos, ingressando como Analista de TI no IFRN em 2009. Atualmente, atua como coordenado de desenvolvimento da área administrativa no projeto SUAP.

 

 

 

 

Welkson Medeiros trabalha com TI a mais de 20 anos, ingressando como Analista de TI no IFRN em 2012. Atualmente, atua na equipe de infraestrutura e redes. É certificado AWS Solutions Architect – Associate

 

 

 

 

Misael Queiroz atua na área de TI desde 2003, ingressando como Analista de TI no IFRN em 2014. Formado pelo IFRN, entusiasta da colaboração técnica, atuando na comunidade de software livre desde 2008 (Projeto JRimum), acredita no SUAP como meio de ajudar muitas instituições a prestar um serviço público de qualidade, a um baixo custo e de referência em inovação tecnológica.

 

 

 

Cristiano Scandura trabalha com TI há mais de 20 anos, ingressou na AWS em 2018 atuando em projetos para clientes Enterprises. Atualmente, é Arquiteto de Soluções no seguimento de Educação em setor público.