Como gerenciar governança e riscos de segurança baseados em nuvem

Ao mesmo tempo em que oferece eficiências de negócios, benefícios de custos e vantagens competitivas, a mudança para serviços baseados na nuvem (ou seja, Azure, AWS e Google Drive) tem suas próprias implicações — não menos importante é a segurança. Muitos assumem que a mudança para serviços baseados na nuvem e o uso de suas ferramentas de segurança corrigirá vulnerabilidades ou deficiências de segurança pré-existentes — mas isso simplesmente não é o caso.

As nuvens públicas fornecem segurança de perímetro para os dados armazenados em seus centros de dados, o que é uma função importante. Mas essa é apenas uma das muitas considerações para garantir a segurança.

Os CIOs costumam falar sobre a necessidade de construir contêineres seguros para acelerar a velocidade de entrada no mercado. Embora haja um foco recente no espaço de nuvem em Kubernetes e containerização, não percamos a floresta pelas árvores. As necessidades de segurança são amplas e o Kubernetes é apenas uma pequena parte dessa equação.

Outros componentes críticos incluem considerações de conformidade, automação de DevOps e criação de uma plataforma de teste robusta que inclui varredura de vulnerabilidade estática (versus dinâmica).

Considerações de Conformidade

Várias indústrias verticais (por exemplo, cuidados de saúde) têm seus próprios padrões de conformidade complexos e rígidos que são conhecidos por serem caros e onerosos de manter. E atualizar a aplicação e a infraestrutura para atender aos padrões de conformidade muitas vezes deixa você propenso a várias vulnerabilidades de segurança e conformidade.

Mas, como escrevi anteriormente, você pode combater vulnerabilidades investindo em automação e varredura de segurança para desenvolvimento e implantação de código. Automatizar esses processos significa acesso mais rápido às informações que podem identificar vulnerabilidades de segurança para que você possa responder a elas com mais eficiência.

Depois de identificar suas vulnerabilidades de segurança, é natural se perguntar quais funções de segurança seus serviços baseados na nuvem podem ser capazes de cumprir e quais você ainda precisará manter a responsabilidade. Como um colega da Unisys explicou, a realidade é que a segurança na nuvem é uma responsabilidade compartilhada.

Como observei, os provedores de serviços baseados em nuvem normalmente gerenciam a segurança do perímetro para os dados armazenados em seus centros de dados, bem como controles de conformidade limitados para a infraestrutura. No entanto, para cada aplicação que você leva para a nuvem, você é responsável por configurar controles de segurança apropriados, identificar e certificar a adesão aos requisitos de conformidade e gerenciar o ciclo de vida dos dados.

Se isso parece ser muito com o que lidar, é porque é.

Como você pode facilitar isso? Usando automação.

Cultura de Automação de DevSecOps

Avaliar sua rede e aplicação de forma contínua e reportar qualquer não conformidade ou risco potencial identificado é um processo incrivelmente tedioso e tradicionalmente manual. Imagine derramar mais de dezenas, se não centenas, de padrões de conformidade, certificando-se de que cada um deles seja atendido e conhecendo as ramificações se esses padrões não forem atendidos.

Um dos desafios para incorporar a segurança é mudar a mentalidade da organização. Com a cultura DevSecOps, os desenvolvedores não só estão "conscientes da segurança", como também podem agir como a primeira linha de defesa. Compreender que uma cultura consciente da segurança é necessária para que os membros de todas as equipes funcionais comuniquem potenciais anomalias. Traduzir os controles aplicáveis (política como código) em componentes de software apropriados como parte do processo SDLC em evolução.

No entanto, essa é uma receita para erros, que podem resultar em multas pesadas.

Em vez de se expor a riscos de responsabilidade desnecessários, construa uma cultura de automação de DevSecOps. Ao automatizar o relatório e o monitoramento de riscos, você garantirá que sua rede e aplicação estejam sendo constantemente monitoradas.

Teste como um serviço

Você pode estar pensando que a automação é ótima, mas o monitoramento constante de riscos é caro e exige que você a construa do zero. É por isso que você deve considerar o teste como um serviço.

O teste como um serviço permite contratar uma organização central para lidar com o aparelho de teste em nome da sua empresa. Esses testes não são específicos à segurança. Também pode ser aplicado à integração, regressão, desempenho e muito mais. Normalmente, é mais rentável do que criar a infraestrutura e a organização em torno de uma plataforma de testes tão robusta internamente.

Não há necessidade de começar do zero quando você pode comprar recursos de testes prontos para uso de um fornecedor externo — ou, melhor ainda, pedir ao fornecedor para criar um programa de testes específico para sua empresa.

Por exemplo, peça-lhes para padronizar os modelos de teste-como-serviço (planejamento, execução e relatório de testes) de ponta a ponta com reutilizabilidade, manutentibilidade e redução de custos como metas principais. Isso lhe dará a flexibilidade de expandir os recursos sem qualquer bloqueio de fornecedores e garantirá que você desafie os fornecedores de nuvem pública a fazer o trabalho pesado por você. Eles podem criar uma estrutura como a seguinte para você:

• Estrutura: Estrutura do Modelo de Objeto da Página Maven
• Linguagem de programação: Java
• Plataformas: aplicativo web (Selenium), móvel (Appium), teste de API (REST Assured), banco de dados (PostgreSQL)
• Testes: Desempenho (Jmeter), segurança através de varredura de vulnerabilidade estática e dinâmica (Veracode)
• Relatórios: Relatório de extensão, Log4J
• CI (Integração contínua) e CD (Implementação contínua): Azure DevOps

Quando você estiver criando sua estratégia em torno de testes de vulnerabilidades potenciais, também precisará ponderar os prós e contras da varredura dinâmica ou estática.

A varredura estática é realizada com a aplicação desligada e envolve o exame do código-fonte ou binários da aplicação para identificar vulnerabilidades de segurança. Se você estiver examinando milhões de linhas de código, esse processo pode rapidamente se tornar complicado e altamente ineficiente.

A varredura dinâmica ocorre enquanto a aplicação está sendo executada e envolve a manipulação da aplicação — como ela seria usada no mundo real — para descobrir áreas de risco. Isso tende a ser mais abrangente, mas também é uma maneira ineficiente de digitalizar, pois descobri que 10 milhões de linhas de código podem levar mais de um mês.

A conclusão não é decidir entre varredura estática e dinâmica. É que você deve entender a necessidade de desafiar os fornecedores de testes para desenvolver uma alternativa melhor. Essa alternativa pode ser oferecida por meio de inovação tecnológica ou melhorias em sua varredura dinâmica. As empresas também desempenham um papel na otimização da varredura de segurança, inclusive refazendo e modernizando seu código.

Mas se há apenas uma lição que você recebe deste artigo, é que você deve assumir o controle da segurança contínua de sua aplicação na nuvem. Evite repetir o que você fez com implementações on-premise legadas. As partes interessadas de segurança com visão de futuro entendem que a melhor maneira de evitar o risco de responsabilidade futura é implementar um programa de segurança robusto desde o início.