A mentalidade de segurança em primeiro lugar para desbloquear a oportunidade da AWS

A Amazon Web Services provou ser líder no mercado de nuvem nos últimos mais de 15 anos, desde que o EC2 foi lançado, e qualquer empresa nascida na nuvem geralmente escolhe a AWS para decolar. Isso criou uma comunidade global próspera e um mercado de ferramentas para desenvolvedores que priorizam a nuvem, possivelmente na maior escala disponível atualmente.

As oportunidades que tanto o console quanto o mercado abriram para as empresas que priorizam a tecnologia são imensas. É por isso que a maioria das empresas cria desde o início uma estratégia de venda conjunta e parceria com a AWS, para alcançar um tempo de lançamento no mercado e adoção mais rápido de seus produtos e serviços complementares.

Para desbloquear esta oportunidade, existem algumas caixas que precisam ser marcadas na Amazon Partner Network para ser elegível para listar serviços em seu mercado e em outros canais da AWS.

A AWS é conhecida por ser uma empresa obcecada pelo cliente e, portanto, qualquer empresa que queira fornecer serviços à sua base de clientes existente por meio de seus canais de venda conjunta deve cumprir seus requisitos mínimos de segurança e privacidade. Essa linha de base de segurança é chamada de Revisão Técnica Fundamental (FTR) e é essencialmente uma série de políticas e controles que as empresas precisam cumprir e ativar para atingir essa linha de base de segurança.

A Jit, como uma empresa baseada na arquitetura sem servidor da AWS e cujo produto atende empresas que priorizam os desenvolvedores com demandas de segurança nativas da nuvem, entendeu que a AWS seria um parceiro natural para alcançar uma maior adoção de produtos. Nesta postagem, vamos nos aprofundar em como Jit usou práticas de dogfooding para cumprir rapidamente o FTR e ser listado no mercado AWS em questão de semanas, e o que você pode fazer para acelerar seu FTR AWS e estratégia de rede de parceiros.

O que você precisa saber sobre FTR

O FTR, como muitos outros padrões comuns e conhecidos do setor, é essencialmente uma lista de itens em diversas categorias, desde controles de segurança até processos e cultura, bem como política e governança da AWS para garantir que qualquer usuário conjunto possa confiar nos serviços que eles oferecem. selecione na rede de parceiros.

O FTR cobre áreas relacionadas com:

• Gerenciamento de identidade e acesso
• Segurança operacional
• Segurança de rede
• Restaurar e recuperar
• Acesso entre contas
• Resiliência
• Validação de conformidade regulatória

Esta não é uma lista exaustiva, mas apenas algumas das áreas que precisam de ser avaliadas em função de verificações específicas. Eles estão sujeitos a alterações dependendo se você é um parceiro implantado na AWS – e esta postagem cobre o FTR da perspectiva de um cliente hospedado ou implantado na AWS. Esta revisão fundamental tem como objetivo verificar a solidez da arquitetura, bem como o nível de serviço e suporte esperados que a AWS exige para seus clientes e, basicamente, os requisitos mínimos para se tornar um fornecedor confiável da AWS.

Por que o FTR parece assustador

O processo AWS FTR pode parecer assustador para muitos, já que seus líderes geralmente não são especialistas em segurança. O que eles veem pode parecer uma longa lista de requisitos vagos e abstratos, e é difícil entender como aplicá-los na prática em sua arquitetura e sistemas. Isso ocorre porque a lista é em grande parte uma autoavaliação que acaba exigindo bastante trabalho de ambos os lados, sem a capacidade de realmente verificar, além de algumas verificações automatizadas. Isso é seguido por uma revisão manual por um PSA (Partner Solution Architect).

É por isso que na Jit entendemos que em 2023, provavelmente podemos e devemos fazer melhor para agilizar esse processo comum por meio da automação para estarmos mais alinhados com nossa crença central de evitar auditorias pontuais tanto quanto possível e trabalhar para substituir com segurança e conformidade contínuas.

Muitas vezes, esse é o mesmo problema que as equipes de engenharia enfrentam ao passar por processos de conformidade, um tópico que discutimos em detalhes historicamente. No entanto, esta lista, assim como outros padrões e estruturas conhecidos do setor, como MVSP (produto seguro mínimo viável), são apenas planos de segurança. Se há uma coisa que aprendemos no Jit é que listas de verificação e planos são criados para serem automatizados.

Tivemos sucesso ao operacionalizar isso com o DSOMM da OWASP e até mesmo com o OWASP Serverless Top 10 para nossas próprias implantações sem servidor. Assim como todos os nossos planos de segurança, decidimos nos tornar usuário zero e fazer o trabalho para automatizar o FTR e aumentar rapidamente os aspectos de segurança que constituem a maior parte da revisão.

Mapeando Requisitos para Ações… Depois Automatizando!

O maior avanço com a automação do processo FTR foi mapear os requisitos para controles práticos que atendam às necessidades. A seguir, mergulharemos em alguns exemplos de como levar o FTR da teoria à prática e os locais onde isso pode ser automatizado com ou sem Jit (plug sem vergonha).

Gerenciamento de identidade e acesso

Isso abrange aspectos relacionados a como você gerencia a identidade e o acesso em sua solução, como:

• Gerenciamento de credenciais
• Armazenamento de credenciais
• Ultimo privilégio
• Autenticação
• Auditoria

Todas essas são áreas bem conhecidas que exigem atenção de segurança em qualquer organização de engenharia, embora sem uma lista definida sejam fáceis de ignorar. É por isso que é recomendado usar listas de verificação de segurança definidas ao implementar a segurança, semelhantes aos manuais para incidentes de segurança, para garantir que você marque todas as caixas. A parte interessante é que muitos desses requisitos técnicos podem ser automatizados assim que você compreender os controles necessários.

Portanto, se adotarmos o gerenciamento e o armazenamento de credenciais, tornando uma prática o uso de um scanner secreto que é executado, assim como suas verificações de CI/CD são executadas em cada solicitação pull (PR), você terá certeza de que nunca cometerá nenhum código rígido. segredos ou credenciais para produzir. Mais importante ainda, mesmo na eventualidade de você fazer isso inadvertidamente, com esse controle em vigor, você será alertado para que essas credenciais não vazem mais e você possa reciclá-las rapidamente. O armazenamento de credenciais, a rotação e o acesso com privilégios mínimos (garantindo que o menor número de recursos tenha acesso apenas ao nível de acesso realmente necessário) também podem ser ativados e validados integrando um armazenamento secreto e definindo suas políticas em suas verificações automatizadas de pipeline.

Auditorias regulares (neste caso trimestrais) para garantir que continua a cumprir estes requisitos, o que chamamos de segurança contínua, também é uma política que pode ser facilmente definida e automatizada num plano de segurança. Ele garante que essas validações sejam feitas no momento necessário. No entanto, se realmente quisermos implementar o processo ideal, isso envolveria a verificação contínua de que não há acesso redundante, com controlos que executem estas verificações continuamente e não como segurança pontual, como parte de um processo baseado em alterações. Isso permitirá que as organizações eliminem auditorias trimestrais dispendiosas pontuais ou as utilizem apenas para “testes de sanidade” rápidos ou à prova de falhas, para um processo automatizado contínuo.

Segurança Operacional

A segurança operacional no contexto do FTR mapeia basicamente um grande segmento que requer cobertura, que é o gerenciamento de vulnerabilidades. Isso significa que você não só precisa de uma maneira de identificar vulnerabilidades em seu sistema e identificar continuamente vulnerabilidades em seu sistema, mas também de um plano de ação viável para remediá-las, incluindo suas dependências de terceiros.

Existem muitas ferramentas disponíveis hoje – de código aberto e comerciais – para quase todas as pilhas e linguagens de programação. Automatizar isso se tornou um requisito básico de segurança para qualquer organização de engenharia, mas fazer isso antes que o código seja implantado na produção é a maior vitória. Ao identificar vulnerabilidades – fazê-lo antes que elas sejam confirmadas (como por meio de um plug-in IDE) é ainda melhor – você pode economizar muitas horas de trabalho na caça a esses riscos após o fato – desde a propriedade do código até encontrar a linha de código e a compreensão como corrigi-lo. Depois de incorporar a verificação de vulnerabilidades em seus processos de controle de PR, você verá seu backlog de vulnerabilidades começar a diminuir e maior sanidade no gerenciamento de vulnerabilidades será alcançada para seus desenvolvedores.

Segurança de rede

Uma das áreas que a validação de segurança de rede cobre são as “regras menos permissivas” para grupos de segurança, muito semelhantes ao privilégio mínimo. É mais um controle que pode ser implementado e automatizado através da Política como Código. Existem várias ferramentas de código aberto disponíveis que permitem definir as políticas GitOps que você gostaria de aplicar para acesso à rede (e outros acessos a produtos e plataformas). Eles não só podem ser ativados, mas também monitorados continuamente para conformidade contínua a longo prazo.

Uma vez identificados os controles que mapeiam cada um desses requisitos, a automação passa a ser a parte fácil, que pode ser aplicada através de ferramentas open source comuns ou mesmo de ferramentas comerciais já adotadas, tornando a implantação uma questão de clique de um botão. No entanto, isso não o levará a 100% do caminho para concluir o FTR. Tal como acontece com outras normas, como a SOC2, ainda haverá alguns aspectos administrativos a cobrir. No entanto, ele cobrirá grande parte da sua revisão técnica básica e as partes mais difíceis de realizar ao fazê-lo manualmente.

FTR para diversão e lucro

Se você deseja iniciar sua jornada de parceiro da AWS e está em pânico com a lista de verificação FTR, mantenha a calma, automatize e orquestre. É possível cobrir a maioria dos aspectos técnicos complexos através das melhores ferramentas de código aberto que podem ser automatizadas através de pipelines CI/CD, e até mesmo através de plataformas de orquestração de segurança que irão consolidar os diferentes controles e centralizá-los em um único lugar para gestão e monitoramento contínuos.

Jit está trabalhando para automatizar todo esse processo por meio de nossa própria plataforma, construindo um plano FTR automatizado que nos ajudou a passar pelo processo rapidamente. Assim que o plano FTR automatizado for produzido e submetido a uma bateria de testes para garantir qualidade e controle, ele estará disponível para a comunidade global da AWS para ajudar a agilizar esse processo para qualquer pessoa que queira aproveitar a oportunidade disponível por meio da comunidade da AWS.

Uma nota final sobre estruturas de conformidade e listas de verificação que podem parecer assustadoras à primeira vista. Depois que descobrimos que um único plano de segurança nos ajuda a alcançar outra estrutura ou lista de verificação, como SOC2 ou MVSP, aprendemos que o DevSecOps pode obter os mesmos benefícios da automação e reutilizar outras disciplinas de engenharia que têm sido empregadas há anos. Adotar esta mentalidade de automação e reutilização será uma grande vitória para a indústria de segurança como um todo.

A postagem A mentalidade de segurança em primeiro lugar para desbloquear a oportunidade da AWS apareceu pela primeira vez em The New Stack.