Não te responsabilizes: Este é um blogue convidado enviado por Srinivasa R. Atta e Goutham Bandapati
Sejamos honestos. Durante anos,a “segurança” para muitos de nós, profissionais da Web, foi um item da lista de verificação de última hora.
Constróis a aplicação, testas as funcionalidades e , mesmo antes do lançamento, tens um ligeiro pânico. “Ah, pois. Precisas de segurança.” Por isso, instala uma firewall, um plugin de segurança, adiciona um SSL e fica por aí.
Isso é como construir um arranha-céus inteiro e depois, quando estás prestes a abri-lo, contratares um tipo para verificar a fechadura da porta da frente.
Os principais fornecedores de serviços em nuvem e as empresas perceberam que este modelo “bolt-on” estava completamente estragado. O resultado? O surgimento da segurança na nuvem DevSecOps.
Parece mais uma palavra-chave empresarial intimidante, mas a ideia central é simples: A segurança não é um passo final. É uma responsabilidade partilhada, integrada em cada uma das partes do ciclo de vida do desenvolvimento.
Já não se trata apenas de “Desenvolvimento” e “Operações”. É “Desenvolvimento”, “Segurança” e “Operações” trabalhando juntos, o tempo todo. E na nuvem, isso evoluiu de uma ideia agradável para uma realidade inegociável.
Aqui está o que essa evolução parece e como podes aplicar esses mesmos conceitos de grande liga para as aplicações que executas na Cloudways.
A grande mudança: De “porteiro” a “guarda-corpo”
O modelo antigo era um “portão de segurança”. Acabavas o teu código e atiravas-o por cima do muro para uma equipa de segurança separada, que passava duas semanas a testá-lo antes de o aprovar ou (mais provavelmente) rejeitar. Isto era lento, frustrante e toda a gente o detestava.
O novo modelo baseia-se em barreiras de proteção automatizadas. Em vez de um portão no final, a segurança é um conjunto de controlos automatizados que ocorrem constantemente.
- Estás a escrever código? Uma ferramenta no teu editor avisa-te de uma potencial vulnerabilidade à medida que a escreves.
- Estás a enviar código? Um processo automatizado analisa o teu código em busca de palavras-passe codificadas ou permissões com fugas.
- Estás a criar a tua aplicação? Uma ferramenta analisa todas as tuas dependências (como um plugin do WordPress ou uma biblioteca PHP) em busca de problemas conhecidos.
- A implementar a tua aplicação? A própria plataforma verifica duas vezes se o teu servidor está configurado corretamente.
O objetivo é mover a segurança “para a esquerda” – o mais cedo possível no processo (isto é o que eles chamam de “Shift-Left”).
Porquê?
Porque corrigir um erro no teu editor de código demora 5 minutos. Corrigir esse mesmo erro depois de ter sido implementado na produção e descoberto por um hacker é um fogo de 5 alarmes.
Como as “3 grandes” nuvens públicas lidam com DevSecOps
Para ver isto em ação, basta olhar para as cadeias de ferramentas que os hiperescaladores construíram. Não vendem “uma ferramenta de segurança”; vendem uma linha completa de serviços integrados.
1. Serviços Web da Amazon (AWS)
A AWS fornece um ciclo estreito de serviços que automatizam todo o pipeline “code-to-cloud”.
- Codifica: Os programadores escrevem código no AWS Cloud9 (o seu IDE) e armazenam-no no AWS CodeCommit (um repositório Git privado).
- Constrói e testa: O AWS CodePipeline detecta um novo commit, pega o código e usa o AWS CodeBuild para executar testes. É aqui que o “Sec” entra em ação: O CodeBuild pode executar uma análise estática para verificar se há falhas.
- Implanta: Se as verificações forem aprovadas, o pipeline implanta o aplicativo.
- Monitoriza: Uma vez em funcionamento, o Amazon Inspetor analisa continuamente a aplicação e o servidor em execução em busca de novas vulnerabilidades, enquanto o AWS Secrets Manager trata de todas as chaves de API e palavras-passe de bases de dados para que nunca sejam codificadas.
2. Microsoft Azure
O Azure está empenhado em integrar a sua plataforma de nuvem com o GitHub, de que é proprietário.
- Codifica: Um programador envia o código para um Repositório GitHub.
- Constrói e testa: Este envio desencadeia automaticamente uma ação do GitHub. Este é o cavalo de batalha do DevSecOps. O fluxo de trabalho pode usar o GitHub Advanced Security para verificar o código (CodeQL), encontrar vulnerabilidades em dependências e verificar se há segredos vazados.
- Implanta: Se os exames forem aprovados, o mesmo fluxo de trabalho do GitHub Action pode implantar o aplicativo em um Serviço de Aplicativo do Azure.
- Monitoriza: Uma vez em execução, o Microsoft Defender para a Nuvem actua como o “chefe”, monitorizando tudo – servidores, bases de dados e contentores – para detetar configurações incorrectas e ameaças, enquanto o Azure Key Vault protege todos os segredos.
3. Google Cloud Platform (GCP)
O GCP está muito focado na segurança da “cadeia de fornecimento de software”, que é uma forma elegante de perguntar: “O código que está a ser executado na produção é exatamente o código que pensas que é?”
- Codifica: Um programador utiliza o Gemini Code Assist no seu IDE, que utiliza IA para detetar falhas de segurança em tempo real.
- Constrói e testa: Faz o commit nos Repositórios de código-fonte da nuvem. Isso aciona o Cloud Build, que cria o código em um ambiente seguro e temporário e gera uma “certidão de nascimento” para o aplicativo (chamada de proveniência SLSA). Simultaneamente, a Análise de Artefactos verifica a aplicação em busca de vulnerabilidades.
- Implanta: Aqui está a magia. Um programador tenta implementar no Google Kubernetes Engine (GKE). Um serviço chamado Autorização Binária entra em cena e diz: “Alto! Mostra-me os teus documentos”. Verifica se há uma “certidão de nascimento” válida do Cloud Build e uma verificação de vulnerabilidade limpa da Artifact Analysis. Se algum deles estiver em falta, a implementação é automaticamente bloqueada.
- Monitoriza: O Security Command Center fornece um painel único para todas as vulnerabilidades, ameaças e configurações incorrectas em toda a organização.
Trazendo-o para casa: DevSecOps prático na nuvem em Cloudways
“Isso é ótimo para as grandes empresas”, estás a pensar, “mas eu sou uma pequena agência que tem uma dúzia de sites WordPress na Cloudways. O que é que isto tem a ver comigo?”
Tudo. Podes aplicar exatamente os mesmos princípios usando as ferramentas que a Cloudways fornece e as ferramentas CI/CD que já usas.
DevSecOps na Cloudways é uma parceria:
- A Cloudways cuida da “segurança” e das “operações” da infraestrutura: Firewalls no nível do servidor, patches de segurança do sistema operacional, acesso SSH/SFTP e lista de permissões de IP.
- Tu tratas do “Dev” e do “Sec” da aplicação: O teu código, os teus plugins, os teus temas e o teu fluxo de trabalho de implementação.
Eis como podes criar o teu próprio pipeline DevSecOps simples e prático.
Caso de utilização 1: A implementação segura e automatizada (o teu pipeline CI/CD)
Em vez do velho método de “codificação à cowboy” (editar ficheiros em tempo real através de SFTP… já todos o fizemos), podes automatizar a tua implementação a partir do Git.
- Código e Compromisso (Dev): Corrige um bug em um plugin personalizado do WordPress. Testa-o localmente e depois faz git push do seu ramo principal para o seu repositório GitHub (ou GitLab/Bitbucket).
- Verifica e testa (Sec): Este push aciona automaticamente uma ação do GitHub. Podes encontrar ações pré-construídas no Marketplace que:
- Procura vulnerabilidades no PHP.
- Verifica as tuas dependências JavaScript (npm audit).
- Procura erros óbvios no teu código.
- Implementa (Ops): Aqui está o ponto de integração. Somente se essas verificações forem aprovadas, a etapa final da tua Ação do GitHub será executada. Esta etapa usa a API do Cloudways (por meio de uma ação do GitHub criada pela comunidade) para acionar o recurso “Implantação via Git” no seu servidor. Seu servidor Cloudways então puxa o código limpo e digitalizado do seu repositório.
Acabaste de criar uma barreira de proteção automatizada. Não há mais “oops, eu coloquei um erro de digitação que quebrou o site”. Se as verificações automatizadas falharem, a implementação na Cloudways nem sequer começa.
Caso de utilização 2: Segurança de aplicações em camadas (a parte “Ops”)
O “Ops” em DevSecOps também significa monitorar e proteger o aplicativo ao vivo. A Cloudways fornece a segurança no nível do servidor, mas você é responsável pela camada do aplicativo.
- Segurança de servidor gerenciada (Cloudways): A Cloudways já está a fazer uma grande parte das “Operações” por ti. Seus patches de segurança regulares significam que o sistema operacional subjacente e os pacotes (como PHP e Nginx) são mantidos atualizados, fechando vulnerabilidades. Esse é um princípio central do DevSecOps (gerenciamento de vulnerabilidades) que você obtém automaticamente.
- Segurança de aplicativos gerenciada (Cloudways): Usa os recursos de segurança incorporados. O complemento Bot Protection (desenvolvido pela MalCare) é seu firewall no nível do aplicativo (WAF), bloqueando bots ruins antes mesmo que eles possam acessar sua página de login do WordPress. Vê este vídeo sobre o recurso de Proteção contra bots do Cloudways, que é um ótimo exemplo de construção de segurança diretamente em sua plataforma de hospedagem. Uma olhada no recurso de proteção de bots do Cloudways Este vídeo é um passo a passo útil do recurso de proteção de bots embutido no Cloudways, que é uma parte fundamental do quebra-cabeça “Sec” e “Ops” que discutimos.
- Verificação de vulnerabilidade gerenciada (Cloudways): Para sites WordPress, a colaboração do Patchstack fornece a verificação de vulnerabilidades. Alerta-o no painel do Cloudways se um plugin ou tema que está a utilizar tiver uma vulnerabilidade conhecida. Este é o seu “Inspetor da Amazon” para WordPress.
- WAF de terceiros (tu): Você pode ir ainda mais longe, colocando em camadas um serviço como o Sucuri. O Cloudways protege o perímetro do seu servidor, enquanto o Sucuri protege a “porta da frente” do seu aplicativo, oferecendo regras avançadas de WAF e limpeza de malware.
A segurança não é um produto, é um processo
DevSecOps não se trata de comprar uma ferramenta mágica. É uma mudança cultural. Trata-se de perguntar “Como podemos incorporar a segurança?” em vez de “Como podemos instalar a segurança?”
Combinando a segurança gerenciada e os gatilhos de implantação automatizados da Cloudways com o poder dos pipelines de CI/CD em plataformas como o GitHub, você pode parar de ser um “guardião da segurança” e começar a construir “grades de segurança”. Seus clientes estarão mais seguros, suas implantações serão mais suaves e você dormirá muito melhor à noite.
Autores
Abdul Rehman
O Abdul é um profissional de marketing experiente em tecnologia, movido a café e criativo, que adora manter-se a par das últimas actualizações de software e gadgets tecnológicos. É também um escritor técnico competente que consegue explicar conceitos complexos de forma simples para um público alargado. Abdul gosta de partilhar os seus conhecimentos sobre a indústria da nuvem através de manuais de utilizador, documentação e publicações em blogues.
