Quem pode acessar o código-fonte, o pipeline e o ambiente de produção?
O controle de acesso no desenvolvimento de software trata da questão: quem pode executar qual ação em qual parte de sua cadeia de desenvolvimento: quem pode ler o código, quem pode modificar e integrar o código, quem pode iniciar uma compilação e quem pode lançar uma versão para produção. Esta é uma pergunta mais específica do que o controle de acesso para uma organização em geral, pois uma equipe de desenvolvimento trabalha com múltiplos sistemas simultaneamente: um repositório de código-fonte, um ambiente de compilação e testes, e geralmente um ambiente de produção separado onde o software realmente é executado.
A razão pela qual este tópico específico reaparece em questionários de segurança e nas medidas de proteção da Diretiva NIS2 é que um erro no acesso à sua cadeia de desenvolvimento tem impacto direto em todos os usuários do seu software. Quem conseguir modificar o código sem ser detectado e depois o colocar em produção não afeta apenas sua própria organização, mas também seus clientes. Por isso tanto uma autoridade supervisora quanto um cliente que esteja sujeito à obrigação de proteção perguntam como você estabeleceu isso.
Por que especificamente o código-fonte e o pipeline são relevantes
Uma equipa de desenvolvimento geralmente tem mais pessoas com direitos mais amplos do que estritamente necessário, simplesmente porque funciona bem na prática: todos podem acessar tudo, ninguém precisa esperar por nada. Do ponto de vista da obrigação de proteção, este é exatamente o ponto que fica sujeito a questões adicionais. Não porque a confiança estaria errada, mas porque comprovabilidade é diferente de confiança: uma autoridade supervisora ou um cliente quer saber se você pode demonstrar quem tem acesso, não apenas se você confia nisso.
As perguntas que surgem geralmente abordam três níveis. O primeiro é o próprio repositório de código-fonte: quem pode ler, quem pode modificar, e existe uma revisão obrigatória antes de uma modificação ser integrada à versão principal. O segundo é o ambiente de compilação e testes: quem pode iniciar uma compilação, e esse ambiente tem acesso a dados ou sistemas não destinados para fins de teste. O terceiro é o ambiente de produção: quem pode realmente lançar uma versão, e é um grupo diferente de pessoas daquelas que escrevem o código.
Separação entre redação e lançamento
Uma distinção recorrente nos questionários é se a pessoa que escreve o código é também aquela que lança a versão para produção. Quando é a mesma pessoa, sem uma etapa intermediária de outra pessoa, cria-se uma situação em que um erro ou uma modificação maliciosa chega à produção sem ser detectado. Muitas organizações resolvem isso com uma segunda revisão obrigatória antes de o código ser integrado e com um papel separado ou direitos separados para o lançamento real. Como isso funciona na prática varia muito dependendo da equipa e do tamanho; a diretiva em si não prescreve um procedimento específico, mas as autoridades supervisoras e os clientes verificam a questão subjacente: se uma pessoa pode fazer alterações sem controle que afetam clientes.
Segredos e chaves separados do código
Um segundo ponto sobre o qual os questionários frequentemente indagam é onde as senhas, chaves de API e outros segredos são armazenados. Segredos que estão no próprio código-fonte são visíveis para todos com acesso de leitura a esse código, o que pode ser um grupo muito maior do que aqueles que deveriam realmente trabalhar com essa chave. Um cofre separado para segredos, com direitos de acesso próprios independentes do repositório de código, é uma forma comum de separar isso. Independentemente de como você implementa isso, o que é relevante para seu dossiê é principalmente se você consegue explicar por que a abordagem escolhida é adequada ao tamanho e aos riscos do que você está desenvolvendo.
O que você documenta, não apenas o que você configura
A configuração técnica dos direitos de acesso é uma coisa; demonstrá-la é outra, e essa segunda parte é frequentemente esquecida na prática. Uma lista de quem tem acesso a qual sistema, quando esse acesso foi concedido e em que base, é exatamente o tipo de comprovante que um questionário de segurança ou uma autoridade supervisora solicita. Sem essa lista, você precisa descobrir a resposta novamente a cada pergunta; com um registro vivo ao lado de cada medida, a resposta já está pronta. consultar a explicação de cada medida oferece uma visão de como o controle de acesso se relaciona com as outras nove medidas do dever de cuidado.
Se sua organização está sujeita ao dever de cuidado ou se recebe essa pergunta porque um cliente está, pode ser determinado com algumas perguntas. Para quem se pergunta como exatamente são rigorosos os requisitos de controle de acesso quando um cliente solicita demonstrar o que foi implementado, a explicação sobre proteção e segurança de dados oferece uma visão mais ampla sobre a origem desse tipo de requisito.
Para sua situação específica, por exemplo, se um arranjo específico de sua linha de desenvolvimento é suficiente para o dever de cuidado que incide sobre você ou seu cliente, um jurista ou a autoridade supervisora competente é o lugar apropriado; secria.eu prepara o registro mas não faz nenhuma declaração sobre conformidade individual.
Deseja ver como o controle de acesso se encaixa no restante de seu dossier, ou tem mais dúvidas sobre o que exatamente se entende por essa medida? consultar as perguntas frequentes oferece respostas breves sobre muitos desses pontos, e a verificação rápida gratuita mostra em alguns minutos onde sua organização está neste assunto.