Modelos de segurança e responsabilidade compartilhada
Nos últimos anos, o desenvolvimento de aplicativos mudou para a arquitetura serverless tão rapidamente que a maioria de nossos clientes agora está focada em serviços gerenciados em nuvem e sem servidor como primeira escolha. Mudar do modelo clássico de TI para um modelo serverless de TI é uma transformação significativa e traz desafios técnicos e culturais. Parte das transformações disruptivas da nuvem é a jornada para implementar as práticas recomendadas de arquitetura para novos projetos ou redesenhar aplicativos legados.
É responsabilidade do arquiteto fornecer a melhor recomendação para a modernização do empreendimento. Ao arquitetar soluções em nuvem, é vital ter conhecimento e compreensão fundamentais do Well-Architected Framework. Essa estrutura fornece as melhores práticas, recomendações e os principais serviços nativos da nuvem para garantir a entrega bem-sucedida do projeto e operações.
Os provedores de nuvem pública AWS, Azure e Google Cloud Platform construíram essa estrutura em 5 pilares: excelência operacional, segurança, confiabilidade, eficácia de desempenho e otimização de custos.
Principais riscos e diferenças para aplicativos clássicos e serverless
Para entender a arquitetura serverless, o primeiro passo é entender a responsabilidade de segurança das equipes de desenvolvimento. As recomendações do OWASP Top Web Application Security Risks para aplicativos serverless estão evoluindo. Como resultado, as equipes de arquitetos de soluções, desenvolvedores e operações de TI enfrentam novos desafios em relação à mudança de funções e responsabilidades quando se trata de ambientes e aplicativos seguros.
Aqui estão alguns dos principais riscos para o desenvolvimento de aplicativos
Ao resumir os principais riscos para o aplicativo serverless, é importante seguir as práticas recomendadas para uma arquitetura distribuída. Nosso foco deve estar na configuração de serviços em nuvem, implantação de aplicativos e criptografia de banco de dados em repouso e em trânsito. Os serviços de nuvem nativos forneceram IAM e políticas gerenciadas para serem implementadas dentro de ambientes de nuvem para acesso a serviços sem servidor e criptografia de banco de dados. A nuvem externa que fornece conexões de terceiros como HTTP precisará de outra solução, pois os métodos de segurança dentro da nuvem não podem ser transferidos para fora das nuvens. Todas as solicitações fora do ambiente de nuvem devem ocorrer em uma conexão segura como HTTPS e devem ser monitoradas em firewalls e serviços gerenciados por API.
A arquitetura sem servidor é altamente distribuída e pode ser um desafio para testes e monitoramento. Portanto, é importante habilitar o monitoramento e a autenticação de funções fornecidos por serviços de nuvem nativos para testes de unidade e integração.
Modelos de responsabilidade compartilhada
O Modelo de Responsabilidade Compartilhada para a nuvem fornece e os clientes também estão transferindo a responsabilidade para a equipe de desenvolvimento. Os diagramas a seguir vêm da documentação da AWS, mas representam princípios de alto nível adotados pelos provedores de nuvem AWS, Azure e GCP.
Aqui está o modelo de responsabilidade compartilhada para a solução clássica
O Modelo de Responsabilidade Compartilhada para a Arquitetura de Soluções Clássicas geralmente é adotado durante a migração de data centers locais que implementam estratégias de aumento e mudança (re-hospedagem e re-plataforma) e recompra. Costumo me referir a essas estratégias de migração como hospedagem de computação que a nuvem oferece.
Esse modelo mostra que os provedores de nuvem são responsáveis pelos recursos da nuvem com controles de segurança integrados. Os clientes estão aproveitando esses recursos e segurança. Eles são responsáveis pela segurança "na" nuvem do código do aplicativo, banco de dados, armazenamento, gerenciamento de identidade e acesso (IAM), configuração e segurança de nossas redes privadas virtuais, login e monitoramento de nossa infraestrutura e conectividade interna e externa.
Modelo de responsabilidade compartilhada para soluções sem servidor
O Modelo de Responsabilidade Compartilhada para Serverless é mais adaptado por estratégias de migração de refatoração/rearquitetura e desenvolvimento de novos aplicativos. Como clientes, precisamos lembrar que somos responsáveis pela segurança do código do aplicativo sem servidor, banco de dados, armazenamento, login e monitoramento, por observar todas as transações do aplicativo e gerenciamento de identidade e acesso (IAM).
Com o desenvolvimento sem servidor, pode haver desafios com o aumento da superfície de ataque e a complexidade do ataque devido a um conjunto muito maior de fontes de entrada. O próximo desafio é escolher novas ferramentas que forneçam informações sobre nossos sistemas. Também precisamos entender que a linha pontilhada em torno do gerenciamento de plataforma, criptografia de código, tráfego de rede, configuração de firewall e sistema operacional e configuração de rede ainda é nossa responsabilidade.
Quer saber como alcançar todo o potencial da nuvem? Clique aqui e baixe o nosso ebook. Nele você encontrará:
- O valor de uma solução de Migração de Cargas de Trabalho SAP;
- Os benefícios reais para sua organização;
- Casos de sucesso de nossos clientes que já adotaram o AWS Cloud com o suporte da Techedge.
