Key Takeaways
A conformidade é uma necessidade: A conformidade regulamentar é fundamental para as empresas, especialmente para as que operam online. A conformidade afeta todas as organizações e está a tornar-se essencial para realizar negócios virtualmente em qualquer lugar.
A sopa de letras dos regulamentos: As empresas enfrentam inúmeras normas regulamentares, como a HIPAA, a PCI DSS, o RGPD e a SOX. Estas regras afetam o desenvolvimento moderno de software, tornando a conformidade uma responsabilidade crucial para as equipas de DevOps.
Antecipar com a conformidade DevOps: A conformidade DevOps procura integrar as verificações regulamentares numa fase inicial do ciclo de vida do desenvolvimento de software (SDLC). Esta abordagem proativa reduz os riscos ao garantir a conformidade em várias fases do desenvolvimento, e não apenas antes da implementação.
A automatização é a salvação da conformidade: A automatização no ciclo de vida do desenvolvimento de software deve incluir a conformidade para minimizar riscos e custos. Garantir a conformidade durante o desenvolvimento de funcionalidades evita correções dispendiosas após a implementação e promove o cumprimento contínuo dos regulamentos.
Desafios de visibilidade e colaboração: Uma conformidade DevOps eficaz depende da eliminação das lacunas entre as equipas de engenharia e de governação, risco e conformidade (GRC), através de visibilidade, comunicação melhorada, colaboração e ferramentas tecnológicas avançadas. Ambos os lados precisam de trabalhar em conjunto de forma integrada.
A conformidade regulamentar pode ser um dos temas menos glamorosos de toda a tecnologia.
No entanto, é absolutamente necessária. Os requisitos de conformidade afetam organizações grandes e pequenas e todas as que ficam entre estes extremos — especialmente qualquer empresa que opere online, o que, nesta altura, significa todas as empresas.
“Atualmente, a maioria das empresas está a assistir a uma mudança no panorama regulamentar, com novos regulamentos a serem publicados todos os anos, por vezes todos os trimestres”, afirma Daniel Marashlian, CTO e cofundador da Drata, uma empresa de automatização da segurança e da conformidade. “A conformidade está a tornar-se indispensável para fazer negócio [praticamente em qualquer lugar].”
Com efeito, o desfile de acrónimos regulamentares parece um teste no optometrista: HIPAA, PCI DSS, RGPD, SOX, FISMA, NIST — ainda está connosco? Isto é apenas a ponta do icebergue das possíveis regras e estruturas que poderá ter de cumprir, especialmente no mundo moderno do software.
Dado que o software empresarial se cruza com praticamente todas as áreas de uma empresa, é natural que o software — sem esquecer os seus dados e a sua infraestrutura — faça, em grande medida, parte do panorama regulamentar. Isto significa, por sua vez, que as equipas de DevOps têm cada vez mais responsabilidade pela estratégia e pela postura de conformidade da sua organização.
“É cada vez mais pedido às organizações de DevOps que cumpram estes novos requisitos regulamentares”, afirma Marashlian.
Neste artigo, analisaremos mais detalhadamente a conformidade em DevOps — o que é, por que motivo é importante e como as equipas a estão a implementar.
O que é a conformidade em DevOps?
O DevOps sempre se centrou na criação de melhores processos, ferramentas e equipas — com o objetivo final de fornecer rapidamente e de forma fiável software de qualidade. A conformidade em DevOps centra-se, portanto, em garantir que o ciclo de vida de entrega de software (SDLC) cumpre todos os requisitos de conformidade, quer sejam ditados por políticas organizacionais, regulamentos governamentais, normas do setor ou outras regras.
No passado, a conformidade podia ser vista como uma verificação final antes da implementação — ou até como algo que não era prioritário, a menos que houvesse um problema numa versão de produção. Atualmente, existe uma tendência para deslocar a conformidade — tal como a segurança, a QA e outros processos — o mais “para a esquerda” possível no SDLC, ou seja, para as fases mais iniciais do desenvolvimento de software. Isto torna-a uma parte mais integrada do SDLC e permite que as equipas verifiquem regularmente o seu código e os seus sistemas quanto à conformidade, em várias fases, para reduzir os riscos.
Have an account? Log In
Porque é importante a conformidade em DevOps?
O DevOps tornou-se uma das principais abordagens ao desenvolvimento de software. Basta dizer que muitas aplicações de software — e, certamente, todos os sistemas que geram, utilizam ou armazenam dados sensíveis — estão sujeitas às várias políticas, regulamentações e estruturas de segurança que regem o funcionamento das empresas.
A conformidade em DevOps é importante porque, sem ela, é muito mais difícil minimizar os riscos e garantir uma conformidade consistente à medida que as equipas de software implementam código de forma mais rápida e frequente — na realidade, continuamente — do que nunca. Isto é ainda mais verdade tendo em conta o grau de automatização alcançado por muitos elementos do SDLC, incluindo pipelines de integração contínua/entrega contínua (CI/CD), automatização da infraestrutura, automatização da segurança e muito mais. Essa mesma mentalidade que privilegia a automatização deve também incluir a conformidade.
“Integrar a conformidade nas funcionalidades à medida que estão a ser desenvolvidas, em vez de identificar estes problemas depois de a funcionalidade ser implementada, pode evitar correções dispendiosas”, afirma Marashlian.
Desafios da conformidade nas implementações de DevOps
A conformidade em DevOps também é importante porque representa uma mudança contínua na forma como as equipas de engenharia de software interagem com o resto da organização. Tal como o próprio DevOps procurou derrubar as barreiras tradicionais entre os domínios de TI — nomeadamente, entre o desenvolvimento e as operações, mas também entre funções como a segurança e a QA —, a conformidade em DevOps deve igualmente reduzir os atritos entre as equipas de software e outras partes interessadas fundamentais, especialmente com o pessoal de governação, risco e conformidade (GRC).
“Quando se trata de alterações efetuadas pelas equipas de engenharia, as equipas de GRC não têm visibilidade sobre o impacto dessas alterações na sua postura de conformidade, uma vez que a única forma de obter essa visibilidade é através de auditorias manuais ou de ferramentas automatizadas que analisam o ambiente de produção”, afirma Marashlian.
Isto evidencia vários desafios de conformidade sobrepostos nas empresas que adotam DevOps: falta de visibilidade, falta de comunicação, falta de colaboração e falta de ferramentas tecnológicas eficazes — especialmente ferramentas que possam ajudar a implementar, automatizar e gerir um “estado pretendido” para os requisitos de conformidade da empresa.
A conformidade em DevOps “significa proporcionar aos programadores visibilidade sobre as estruturas de conformidade e os requisitos regulamentares de forma acessível e prática, para que possam garantir que os objetivos empresariais da organização relacionados com a conformidade são cumpridos pelas alterações que efetuam ao código”, afirma Marashlian.
É uma via de dois sentidos: as equipas de GRC também precisam de visibilidade e compreensão sobre a forma como o software de uma organização afeta a sua postura de conformidade, mas de uma forma que não cause atritos com os programadores e engenheiros de DevOps, nem crie estrangulamentos no SDLC.
Boas notícias: Estes desafios devem ser familiares aos profissionais experientes de DevOps, porque são semelhantes aos conflitos que costumavam existir entre as equipas de Desenvolvimento e Operações. As práticas de DevOps, como incentivos partilhados e análises pós-incidente sem culpabilização, também podem ser valiosas neste contexto.
A automatização também é fundamental, pois permite verificações frequentes que começam numa fase inicial do SDLC e minimizam os incidentes em produção mais tarde. Se esses incidentes ocorrerem, uma abordagem colaborativa para os resolver — em vez de apontar o dedo — é crucial.
“Quando são identificados problemas críticos de conformidade em produção, as equipas de GRC e de Engenharia devem trabalhar em conjunto para dar prioridade às correções desses problemas, garantindo que a organização continua a cumprir os seus objetivos de conformidade”, afirma Marashlian. “Isto ajuda a evitar silos e facilita uma colaboração mais estreita entre as duas equipas.”
Boas práticas para a conformidade DevOps
Independentemente das ferramentas específicas ou de outras soluções que selecione para a conformidade DevOps, existem alguns componentes essenciais e boas práticas que devem ser considerados como fundamentos do seu programa. Estes incluem:
Regras e objetivos claros: Não é possível cumprir os requisitos se não souber qual é o objetivo. Por isso, naturalmente, qualquer programa de conformidade DevOps deve começar por identificar os regulamentos e as estruturas que precisa ou pretende cumprir e, em seguida, implementar políticas e ferramentas em conformidade. Por vezes, estes podem ser definidos como “intervalos aceitáveis”, o que significa que existe um conjunto de possíveis resultados aceitáveis para as verificações de conformidade à medida que estas são executadas durante diferentes fases do SDLC.
Controlo de versões: Os sistemas de controlo de versões, como o Git, já são normalmente utilizados nas cadeias de ferramentas de DevOps. Isso é positivo, porque o controlo de versões é amplamente considerado indispensável para a conformidade DevOps — entre outras razões, por ser uma tecnologia facilitadora das auditorias de segurança e conformidade.
Infraestrutura como código (IaC): As ferramentas de infraestrutura como código — ou de automatização da infraestrutura — permitem aos engenheiros de DevOps e a outros profissionais gerir programaticamente tarefas de gestão da infraestrutura, como aprovisionamento, escalabilidade ou configurações. Isto permite às equipas de DevOps gerir a infraestrutura de forma consistente e automática, poupando tempo e esforço significativos no trabalho manual e repetitivo de infraestrutura.
Automatização da segurança / DevSecOps: Embora a segurança e a conformidade sejam normalmente consideradas domínios distintos, estão certamente relacionadas, especialmente no que diz respeito aos dados. Simplificando a relação: se tiver vulnerabilidades de segurança no seu software, na infraestrutura ou nos dados, provavelmente também terá vulnerabilidades de conformidade. Uma forma de encarar a conformidade DevOps é considerá-la semelhante ao DevOps e à segurança — uma combinação por vezes designada por DevSecOps —, na medida em que exige uma mentalidade de “deslocação para a esquerda” e o abandono de paradigmas antigos, nos quais a segurança (e a conformidade) era tratada como uma lista de verificação final no momento da implementação.
Os processos de conformidade também se cruzam frequentemente com várias normas e estratégias de cibersegurança, como o controlo de acesso (por exemplo, MFA/2FA e controlo de acesso baseado em funções) e estruturas de segurança, como as publicadas pelo NIST ou pela OWASP.
Conformidade como código (CaC): A conformidade como código (CaC) — por vezes designada por automatização da conformidade — utiliza scripts e ferramentas de automatização para mitigar os riscos relacionados com a configuração manual e garantir a consistência em toda a pilha de TI e o SDLC de uma organização.
A CaC melhora a rastreabilidade e a responsabilização pelas alterações efetuadas à infraestrutura e ao software. Em conjunto com a infraestrutura como código (IaC), as empresas podem conseguir alterações de infraestrutura sustentáveis, repetíveis e auditáveis, alinhadas com os requisitos de conformidade — e fazer o mesmo nas respetivas bases de código de software.
Na próxima secção, analisaremos mais atentamente algumas ferramentas de CaC.
More Articles
Ferramentas e soluções de conformidade DevOps
Como Marashlian observa acima, um dos desafios gerais da conformidade em qualquer organização é o facto de se tratar de um cenário em constante evolução. São aprovados novos regulamentos e leis, as estruturas ou regras existentes são alteradas, e assim por diante.
Essa é uma das principais propostas de valor das ferramentas de CaC. Estas conferem maior normalização, consistência e automatização às verificações de conformidade em todo o SDLC — preservando simultaneamente um registo de auditoria claro.
Como escreve Jim Bird, autor do livro da O’Reilly DevOpsSec: “A normalização deixa os auditores satisfeitos. As auditorias deixam os auditores satisfeitos (obviamente). A conformidade como código proporciona um excelente registo de auditoria para cada alteração, desde o momento em que a alteração foi solicitada e o motivo, passando por quem efetuou a alteração e o que essa pessoa alterou, quem analisou a alteração e o que foi encontrado nessa análise, como e quando a alteração foi testada, até ao momento em que foi implementada.”
À medida que o DevOps amadureceu, parece que mais organizações estão a perceber a importância desta abordagem: Marashlian, da Drata, cita um relatório recente da Gartner que prevê que “até 2026, 70% das empresas terão integrado a conformidade como código nas suas cadeias de ferramentas de DevOps, reduzindo o risco e melhorando o tempo de disponibilização em pelo menos 15%”.
A Drata lançou recentemente uma capacidade de CaC na sua plataforma. «As equipas de DevOps e GRC obtêm visibilidade sobre os problemas de conformidade numa fase inicial do ciclo de vida do desenvolvimento, [podem] corrigir estes problemas no código de forma fácil e rápida e [podem] criar barreiras de proteção para controlar se é permitido efetuar alterações ao código que tenham impacto na postura de conformidade da organização», afirma Marashlian.
Se, por exemplo, for uma organização de cuidados de saúde que pretende automatizar uma parte maior da sua conformidade com a HIPAA, pode configurar uma ferramenta de CaC para o fazer. Isto é semelhante ao que acontece com a maioria dos outros regulamentos importantes, como o SOC 2, o RGPD e a ISO 27001. As ferramentas de CaC podem ajudar a automatizar a validação de diferentes normas de conformidade ao longo do SDLC, avançando para um modelo de conformidade contínua – não muito diferente da entrega contínua e dos pipelines de CD.
Além da Drata, existem várias outras opções, incluindo a Vanta, a Sprinto e a Scrut. Obviamente, um dos seus critérios básicos de seleção deve ser garantir que qualquer ferramenta utilizada consegue suportar os seus requisitos específicos de conformidade.
Tenha também em conta que existe um conjunto muito mais amplo de ferramentas de software que pode estar abrangido pelo conceito de conformidade de DevOps: sistemas de controlo de versões, como o Git, plataformas de automatização, como o Terraform e o Ansible, e até o Kubernetes. As principais plataformas de nuvem também disponibilizam as suas próprias versões destas e de outras ferramentas.
Conclusão
A conformidade regulamentar pode não ser um excelente tema para iniciar uma conversa num jantar, mas é indispensável para a maioria das organizações. E a conformidade – especialmente no que diz respeito a aplicações de software, dados e infraestrutura – é cada vez mais gerida como código, de forma altamente automatizada.
Que papel desempenha o seu DevOps na conformidade da sua organização? Subscreva o boletim informativo do The CTO Club para receber mais notícias e discussões do setor!