Quais processos ou ferramentas ativam a segregação de funções quando os engenheiros implantam e executam código?

Em ambientes altamente regulamentados, como o setor de serviços financeiros, a segregação de funções é um mecanismo essencial para evitar colisões entre indivíduos com responsabilidades de desenvolvimento e privilégios de produção.

Tradicionalmente, isso significa que os desenvolvedores desenvolvem o código e o entregam ao Operations. No entanto, em muitos modelos operacionais do DevOps, a segregação entre desenvolvimento e operações é, no mínimo, borrada:

• Na prática da Engenharia de confiabilidade do site , ou SRE, do Google, existe uma função SRE separada no Google. No entanto, os desenvolvedores são contratados para apoiar os SREs em momentos de alta carga operacional.

• No modelo "Você constrói, você executa" , não há função de operações separada.

Depois de passar meses pesquisando minuciosamente as causas do mecanismo de Segregação de Deveres, parece existir predominantemente para satisfazer a Seção 404 da Sarbanes Oxley : Avaliação de Gerenciamento de Controles Internos:

(a) Regras necessárias. A Comissão prescreverá regras que exijam que cada relatório anual exigido pelas seções 13 (a) ou 15 (d) da Securities Exchange Act de 1934 contenha um relatório de controle interno, que deve:

(1) declarar a responsabilidade da administração em estabelecer e manter uma estrutura e procedimentos de controle interno adequados para os relatórios financeiros; e

(2) conter uma avaliação, no final do último exercício fiscal do emissor, da eficácia da estrutura de controle interno e procedimentos do emissor para relatórios financeiros.

(b) Avaliação e relatórios de controle interno. Na avaliação de controle interno exigida na subseção (a), cada empresa de contabilidade pública registrada que prepara ou emite o relatório de auditoria para o emissor deve atestar e relatar a avaliação feita pela administração do emissor. Um atestado feito sob esta subseção deve ser feito de acordo com as normas para trabalhos de atestado emitidos ou adotados pelo Conselho. Qualquer atestado desse tipo não deve ser objeto de um compromisso separado.

Com base nos comentários, é importante destacar algumas suposições que estou fazendo:

• Estou considerando predominantemente serviços financeiros de mercado de massa, ou seja, os volumes de transações são altos, mas com valor relativamente baixo. Isso seria contrário aos serviços financeiros comerciais que possuem um perfil de valor de transação diferente.
• A oferta on-line de uma instituição financeira será composta de muitos componentes com diferentes considerações de risco:
  • Mover dinheiro - Mover dinheiro entre contas ou transferências entre contas de diferentes proprietários. Uma operação que deve considerar os países contra lavagem de dinheiro, proteção contra fraudes e embargos, para citar alguns.
  • Aquisição de clientes - menos arriscado, pois possui baixos volumes de transações em comparação com o Move Money, mas ainda precisa ser considerado.
  • Internet Banking - Abrange uma ampla gama de serviços com diferentes níveis de risco, o Move Money seria considerado parte disso.
• É possível que uma abordagem diferente possa ser adotada para cada um, dependendo do risco; no entanto, no interesse de simplificá-lo, estou trabalhando para encontrar uma solução que se aplique a algumas das operações mais arriscadas.

TL; DR : É de responsabilidade da administração garantir a existência de controles internos adequados, em conformidade com os regulamentos da Comissão de Valores Mobiliários .

O Sarbanes Oxley 404 normalmente é satisfeito com a conclusão de uma avaliação de risco de cima para baixo, parte da qual avaliará o risco de conluio e apresenta estratégias de mitigação.

Em uma empresa que emprega a prática e a cultura do DevOps, onde os Desenvolvedores rotineiramente têm acesso ao controle e à produção da fonte, como é possível alcançar a Segregação de Funções ou, de maneira mais geral, como é possível mitigar o risco de conluio.

Sua pergunta não parece ter nenhuma suposição sobre a plataforma / sistema operacional de que trata. É por isso que pode fazer sentido adicionar uma resposta sobre como isso geralmente é feito / resolvido em um ambiente de mainframe, onde os "engenheiros" (como no título da sua pergunta) são na verdade grupos de pessoas onde dezenas (possivelmente centenas) de pessoas são. envolvidos. Minha resposta é baseada no uso do produto SCM em que estou mais familiarizado (não tenho certeza se é necessário divulgar o nome do produto).

---

1. Arquitetura

---

Aqui estão os destaques de como eu responderia sua pergunta:

• Todo o código (e artefatos relacionados, como executáveis, etc) é armazenado em arquivos que, juntos, são o que chamamos de estrutura da biblioteca .
• Para cada ambiente em cada sistema de destino (possivelmente remoto), existe um servidor (uma "tarefa iniciada" no mainframe speak), que cuida das atualizações ALL (repeat: ALL) para qualquer coisa na estrutura da biblioteca. Existem algumas exceções (como pessoal de segurança ou equipe de gerenciamento de espaço), mas, além disso, ninguém (repita: ninguém) tem autorização para aplicar atualizações a qualquer arquivo nessa estrutura de biblioteca. Em outras palavras: o servidor obtém autoridade de atualização exclusiva para toda a estrutura da biblioteca . Atenção: as pessoas da OPS vão enlouquecer se você entrar para limitar o acesso delas (a princípio elas vão resistir ...), portanto, verifique se você está coberto pela gerência superior (CxO) para impor essas regras de acesso ...
• As mudanças reais do software podem consistir em um único componente (uma pequena correção de código no meio da noite ...), ou também pode ser centenas ou milhares de fontes, executáveis ​​ou quaisquer outros artefatos (durante um fim de semana de lançamento). Para torná-los gerenciáveis, as coisas que devem ser movidas (mais ou menos) juntas, ao mesmo tempo, são agrupadas no que é chamado de pacote de mudança de software .

Com o exposto acima, qualquer tipo de atualização a ser aplicada pelo servidor à estrutura da biblioteca só será possível através de um fluxo de trabalho bem definido, que chamamos de ciclo de vida de um pacote de mudança de software (SDLC, se você preferir). Para realmente executar as várias etapas desse fluxo de trabalho, é necessário que isso aconteça:

• Somente o servidor executará as etapas necessárias (e pré-configuradas).
• O servidor executará apenas uma etapa específica (= atualizar algo em algum lugar da estrutura da biblioteca), depois que as aprovações necessárias (de seres humanos) forem reunidas para executar essa etapa.
• As aprovações só podem ser concedidas por usuários que possuem uma função que lhes permita (= permissão) emitir tais aprovações.

---

2. Funções e permissões

---

O servidor garantirá que o usuário que está tentando fazer algo acontecer (como 'aprovar algo') só poderá fazê-lo, se as permissões do usuário forem apropriadas. Essa parte é fácil. Mas você não deseja usar o sistema SCM para administrar todas essas permissões para todos os usuários envolvidos, é isso que pertence ao seu sistema de segurança (não ao sistema SCM!), Para que você possa adaptar seu fluxo de trabalho (no seu sistema SCM) para verificar essas permissões sempre que apropriado. Os passos abaixo fornecem mais alguns detalhes sobre isso.

Etapa 1: configurar as permissões (no sistema de segurança)

• Defina entidades de segurança em seu sistema de segurança, com nomes bem definidos para essas entidades. Algumas amostras (adicione tantas similares para atender às suas próprias necessidades):

  • PrmUnit, usado para obter permissão para solicitar um Promover para dizer teste de unidade .
  • PrmQA, usado para obter permissão para solicitar um teste para promover o teste de Qa (vamos supor que este seja o nível mais alto de teste).
  • PrdEnduser, usado pelos usuários finais envolvidos em algum nível de teste, para indicar que eles estão satisfeitos com os resultados produzidos por algum tipo de teste. E por causa disso, esses usuários finais concordam com a mudança na estrutura da biblioteca.
  • PrdRelmgnt, usado pelos gerenciadores de versão para autorizar uma Ativação em produção (= o último / mais alto nível na estrutura da biblioteca).

• Defina grupos de usuários no seu sistema de segurança. Algumas amostras (adicione tantas similares para atender às suas próprias necessidades):

  • GrpDevs, que (digamos) corresponde aos seus desenvolvedores (provavelmente mais que apenas 1).
  • GrpEnduser, que (digamos) corresponde aos seus usuários finais (pelo menos 1, de preferência com mais usuários semelhantes).
  • GrpRelMgnt, que (digamos) corresponde aos seus gerenciadores de versão (pelo menos 1, de preferência mais alguns usuários).

• Conceda permissões , também usando o seu sistema de segurança, para permitir o acesso a " entidades de segurança " selecionadas para " grupos de usuários " selecionados . Para continuar o exemplo acima, eis o que parece apropriado (adapte-se às suas próprias necessidades):

  • O grupo GrpDevsobtém acesso à (apenas!) Entidade de segurança PrmUnit.
  • O grupo GrpEnduserobtém acesso à (apenas!) Entidade de segurança PrdEnduser.
  • O grupo GrpRelMgntobtém acesso à (ambos!) Entidade de segurança PrmQAe PrdRelmgnt.

Etapa 2: configurar o fluxo de trabalho (no sistema SCM)

Depois que as permissões são configuradas no seu sistema de segurança (como na Etapa 1), tudo o que resta a fazer no seu sistema SCM é configurar como as várias etapas no ciclo de vida correspondem às entidades de segurança relacionadas no seu sistema de segurança. Ou seja, apenas os usuários que têm o acesso apropriado à entidade de segurança necessária têm permissão para solicitar ao servidor que execute a etapa correspondente no fluxo de trabalho.

Aqui estão alguns exemplos de como você configuraria seu sistema SCM para fazer alguma mágica acontecer:

• Se um usuário tiver acesso PrmUnit, ele poderá solicitar um teste Promover à Unidade . Obviamente, os usuários do grupo GrpDevssão os usuários autorizados para isso (nota: não, por exemplo, os usuários do grupo GrpRelMgnt).
• Se um usuário tiver acesso PrmQA, ele poderá solicitar um teste de Promoção ao controle de qualidade . Obviamente, os usuários em grupo GrpRelMgntsão os usuários autorizados para isso (nota: não, por exemplo, os usuários em grupo GrpDevsou em grupo GrpEnduser).
• Se um usuário tiver acesso PrdEnduser, esse usuário poderá autorizar a alteração avançando na estrutura da biblioteca (que normalmente é um pré-requisito para que os usuários do grupo GrpRelMgntpossam revisar uma alteração). Obviamente, os usuários do grupo GrpEndusersão os (únicos) usuários autorizados para isso.
• Se um usuário tiver acesso PrdRelmgnt, ele poderá autorizar uma Ativação em produção (= o último / mais alto nível na estrutura da biblioteca).

---

3. Espere o inesperado e esteja pronto para ele

---

O texto acima é apenas um plano, o que, com sorte, ajuda a entender como, no final, é o servidor que cuida da segregação de tarefas ... desde que você tenha o CxO que o cobre para impor algumas regras de acesso que nem todo mundo vai gostar.

Para concluir a imagem, conforme explicado acima, o servidor cria uma trilha de auditoria (log) de qualquer coisa que esteja acontecendo no sistema. Para que, a qualquer momento, sempre seja possível responder perguntas como

O que aconteceu quando e por que e qual usuário autorizado realmente o aprovou ... antecipadamente?

Mas, provavelmente, a parte mais difícil é ter ferramentas de relatório adequadas disponíveis (e saber usá-las). Pelo menos (facilmente) satisfazer solicitações de auditores de TI (suas perguntas podem ser muito desafiadoras). Mas também aponte para registros de log relevantes em seu sistema SCM para responder a todos os tipos de perguntas "O que aconteceu" em situações de crise em que (parte da) produção está inoperante.

---

PS: Deixo para o julgamento de todos, se minha resposta for sim ou não, compatível com o DevOps.

Resposta baseada no meu conhecimento do regulamento "Controles internos" em francês, equivalente aos regulamentos da SEC que você aponta, presumo que vincular aqui a um texto jurídico em francês não seria realmente útil e não conheço uma boa tradução dele.

Em um modelo ideal de 'você constrói, executa', todos na equipe serão responsáveis ​​pela mudança. A avaliação de risco não pode ser imposta por uma separação de tarefas e a única maneira que conheço para continuar em conformidade com a regulamentação é fazer uma auditoria periódica de ciclo curto das transações, juntamente com um rastreamento de ação inalterável para retornar à pessoa que fez a liberação .
Isso significa que todos os logs de transações e ações são enviados para uma área restrita à qual a equipe não tem acesso, uma alteração no que é registrado "deve" ser detectada pelos testes funcionais aos quais a equipe não tem acesso e, na pior das hipóteses, será detectada pela auditoria e rastreado ao seu autor.

Isso não se aplica a todos os produtos, no momento em que escrevo na França qualquer empresa autorizada a emitir dinheiro (principalmente bancos), deve garantir que todas as transações sejam registradas e, portanto, não pode correr o risco de perder uma transação.
Por outro lado, eles não têm obrigação legal de rastrear qualquer oferta comercial ou avaliação de risco quando alguém solicita um empréstimo e, portanto, os produtos que lidam com essa seleção de clientes e calculam as taxas que estarão na oferta são mais fáceis de caber em um post modelo de auditoria de lançamento.

A ideia principal é que o modelo de liberação precise ser ajustado de acordo com as obrigações de avaliação de risco.

Um recurso relacionado é a norma ISO27001 .

O IMHO, Desenvolvedores e Operações pode ser representado por nada mais do que apenas dois repositórios git para a mesma base de código , com permissões distintas modelando cada um, para que as equipes não interfiram no trabalho uma da outra.

Vamos chamá-los de Dev.mygithub.co & ops.mygithub.co , apenas como exemplo.

A idéia é que os desenvolvedores sejam livres para criar / ramificar / mesclar para o conteúdo de seus corações - o git está fornecendo rastreabilidade total e é isso que importa aqui - enquanto isso, nos momentos em que a estrutura regulamentar implicar um esforço de revisão, uma solicitação de solicitação pode ser levantada, por a fusão ocorra de maneira controlada.

Levando esse conceito ao próximo nível, uma ramificação de desenvolvimento pode ser propagada para a produção das operações remotas por meio de outro ato de solicitação de recebimento. Essa última parte deve acontecer pelas mãos e pelos olhos das operações, uma vez que eles têm a responsabilidade de examiná-la em produção e escolhem o nível de revisão.

Esse esquema permite flexibilidade infinita, rastreabilidade total, capacidade de detectar problemas desde o início através de uma variedade de processos, separação de preocupações e uma experiência muito razoável do usuário no processo !

Nota: O modelo descrito acima pode ser seguido mesmo que Ops e Dev se sobreponham totalmente!

maior é mais caro:

• diferentes sites e métodos de desenvolvimento e operações para realizar o trabalho de um para o outro
• sistemas e métodos distintos de desenvolvimento e operações, como acima
• repositórios distintos de dev e ops git / vcs e métodos relacionados
• ramos distintos do git / vcs do dev e ops (protegido) e métodos relacionados

Dependendo do que você faz, algumas soluções são melhores que outras, por exemplo, se você precisar atender a duas equipes com funções distintas, cada uma com propriedade e fornecer total rastreabilidade, você estará passando o mouse sobre as três primeiras.

Em resumo, qualquer coisa que imponha que um cara ou uma garota não possa pegar a bola sozinha e correr com ela, e ele / ela cruza uma fronteira explícita e distinta entre os desenvolvedores. Agora, dependendo do nível de risco, esse limite pode ser imposto ou não.