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

18

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:

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.

Richard Slater
fonte
A idéia principal por trás de uma organização de devops é colocar todos na equipe responsáveis ​​pelo que acontece na produção; não pode haver separação de tarefas. Isso significa principalmente que esse tipo de organização não pode ser realmente utilizado quando houver necessidades regulatórias para essa separação.
Tensibai 18/03/19
@Tensbai Não concordo com a afirmação de que o DevOps é incompatível com a Segregação de Deveres. As leis não são prescritivas quanto à maneira dos controles, nem os reguladores impõem um processo predefinido aos bancos e serviços financeiros. Cabe à organização identificar o que é apropriado e ser totalmente transparente com os reguladores e seus auditores designados. Como exemplo, o ING e o Barclays adotaram práticas de DevOps para permitir que eles acelerassem sua capacidade de agregar valor a seus clientes.
Richard Slater
Sim, devops em assuntos não vinculados à separação regulatória e eles aproveitaram a automação em uma organização tradicional baseada em silo para assuntos restritos (que na verdade são muito poucos). Eles só têm dois tipos de orgs, dependendo de qual tipo de operações o software fará
Tensibai
Não existe "Separação Regulatória", os estatutos / leis e órgãos reguladores não impõem separação às instituições financeiras, eles impõem a responsabilidade da administração de ter "Controles Apropriados" para gerenciar o risco financeiro. Da mesma maneira que o Agile levou o desenvolvimento de software de ciclos longos para pequenos, o DevOps está levando as operações para pequenos ciclos, o DevOps no Financial Services precisa encontrar uma maneira de levar a Segregação de Tarefas para pequenos ciclos, criando, por exemplo, um pipeline de CD que aplica "controles apropriados", como promoção por revisão por pares e aprovação.
Richard Slater
1
@ Pierre.Vriens sim, a pergunta mais ampla está no título, tentei expandir a questão fazendo algumas suposições. É provável que as funções façam parte da solução, assim como coisas como Break-Glass e Privileged Account Management. Funções e Responsabilidades são um conceito interessante no DevOps / Agile, pois era uma vez você ter um Desenvolvedor Java, Desenvolvedor F / E, Designer, PM, Engenheiro de Construção, Gerente de Liberação e Engenheiro de Operações - agora você tem um grupo de pessoas que podem use vários chapéus - equipes multifuncionais compostas por "engenheiros" que podem se especializar, mas compartilham responsabilidades.
Richard Slater

Respostas:

8

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.

Pierre.Vriens
fonte
Isso soa como uma implementação básica da avaliação de risco de cima para baixo; não entendo como ela aborda a questão de como isso pode ser implementado de maneira devops, em que os desenvolvedores teriam o direito de acionar a opção 'implantar'. É a ideia de que você não pode fazer isso em uma organização de devops?
Tensibai 20/03/19
@Tensibai "se" os desenvolvedores tiverem a autorização (função) de (por exemplo) aprovação final para o produto (que eles normalmente não têm nessas organizações), esse servidor (tarefa iniciada) iniciará a implantação. E de acordo com o título da pergunta, acho que essa é "uma" resposta possível. Pode-se questionar, no entanto, se é isso que chamaríamos de organização DevOps, mas sei que os auditores realmente gostam desse tipo de segregação "configurável" de tarefas (por exemplo: quatro olhos e variações disso). Talvez Richard possa nos ajudar com seu ponto de vista sobre isso?
Pierre.Vriens
1
Concordo que os auditores gostem absolutamente, só perdi como isso se relaciona / se encaixa com a 'explosão' de acesso, que o auditor geralmente não gosta quando a lista contém mais de 6 a 7 pessoas. Dizer que não se encaixa é uma resposta absolutamente válida para IMHO.
Tensibai 20/03
1
Obrigado por dedicar tanto tempo a uma resposta. Na verdade, estou pensando em implementar uma regra para três pessoas, pois um desenvolvedor escreve o código, um desenvolvedor diferente analisa o código e uma terceira pessoa pressiona o botão de liberação para implantar o código. A outra consideração é que, como isso faz parte da adoção do Agile / DevOps em toda a empresa, as equipes de desenvolvimento são muito pequenas, com o efeito líquido de pequenos grupos de pessoas terem acesso à produção a uma fatia fina da produção, isso parece favorável da perspectiva de risco .
Richard Slater
1
@ Pierre.Vriens não pode upvote duas vezes, grande extensão :)
Tensibai
5

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 .

Tensibai
fonte
Resposta interessante e muito relevante, pois muitos bancos europeus realmente operam na França. Existe alguma chance de você expandir o que significa "Emit Money" (Dinheiro Emitido), ou seja, é apenas dinheiro retirado de um caixa eletrônico ou inclui transferências de saldo. Neste caso, ligando para os estatutos seria valioso, pois dá um ponteiro para as leis relevantes, independentemente do idioma em que estão.
Richard Slater
@RichardSlater Em resumo, qualquer empresa que trabalhe com dinheiro pode ser uma empresa apenas para investimento, bem como corretores de empréstimos nos bancos tradicionais. Principalmente, qualquer coisa que tenha impacto financeiro em algum lugar (das poucas exceções que a autoridade pode dar sob circunstâncias). A "lista" legal em francês está aqui, mas mesmo em francês nem sempre é óbvia.
Tensibai 21/03
Estou assumindo que o link para o padrão ISO deve realmente ser ISO27001: 2013
Richard Slater
@ Richard, de fato, parece que o link de francês para inglês não foi atualizado na Wikipedia. Vou atualizar mais tarde (ou, se quiser, fique à vontade para editar)
Tensibai
0

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!

fgeorgatos
fonte
1
Certamente, esse mesmo controle poderia ser alcançado por meio de solicitações pull e ganchos pós-confirmação que garantiam que os desenvolvedores pudessem se comprometer livremente; no entanto, as confirmações de mesclagem só podiam ser feitas por um grupo aprovado de pessoas. Da mesma forma, esse mesmo gancho pós-confirmação pode garantir que os autores dos confirmações que compuseram a solicitação de recebimento não incluam a pessoa que fez o pedido de recebimento.
Richard Slater
@RichardSlater: a razão pela qual você deseja ter dois repositórios distintos é que você tem a dupla necessidade de permitir que os desenvolvedores se fundam - quando eles trocam livremente o código no modo de desenvolvedor - e impedir a maioria dos desenvolvedores de mesclar o código quando for necessário. ir para a produção (módulo SysOps, isto é, o chamado "grupo de pessoas aprovado").
Fghorgatos
Novamente, você pode conseguir isso com ganchos pós-confirmação e solicitações pull, sem mencionar que o GitHub Enterprise permite ramificações protegidas.
Richard Slater
0

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.

fgeorgatos
fonte