Esta aplicação auto-hospedada pode suportar o seu processo de aprovação? Um framework prático de avaliação

Porque uma funcionalidade de aprovação não é o mesmo que um processo de aprovação controlado

Muitas aplicações conseguem marcar um item como aprovado, restringir uma alteração de estado ou notificar um colega para revisão. Isto pode ser útil, mas não proporciona automaticamente um processo controlado para uma compra, despesa, pedido de acesso, alteração de dados de clientes ou decisão de publicação.

Um processo de aprovação controlado exige mais do que uma ação num ecrã. Exige uma decisão definida, decisores elegíveis, regras para determinar quando a sua autoridade se aplica, um registo do que decidiram e salvaguardas contra alterações ou contornos posteriores do processo. A pergunta certa não é «Esta aplicação tem aprovações?». É «Conseguimos configurar e operar esta aplicação de modo a que as decisões exigidas sejam tomadas, aplicadas e comprovadas?».

A [NIST SP 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) considera os controlos flexíveis e personalizáveis no âmbito de um processo de gestão de risco que abrange toda a organização. Aplique aqui o mesmo princípio: traduza os seus requisitos empresariais, de política e de risco em testes observáveis. Uma designação genérica de funcionalidade não substitui esse trabalho.

• Trate uma funcionalidade como ponto de partida, e não como prova de controlo.
• Separe revisões de conveniência de decisões que criam compromissos financeiros, legais, de segurança ou com impacto nos clientes.
• Documente quais requisitos são obrigatórios, quais são desejáveis e quais têm de ser tratados fora da aplicação.

Comece pela decisão do mundo real

Comece pelo evento empresarial, e não pela configuração do software. Descreva um tipo de aprovação de cada vez. «Compras» é geralmente demasiado abrangente: aprovar a renovação recorrente de baixo valor de um fornecedor pode envolver evidências, autoridade e riscos diferentes da aprovação de um novo compromisso de elevado valor com um fornecedor.

Para cada decisão, identifique o requerente, o registo sobre o qual se decide, as evidências exigidas, os possíveis resultados e a ação que só pode ocorrer após aprovação. Identifique também a consequência de uma aprovação incorreta. Isto determina o nível de controlo, visibilidade e revisão de que o fluxo de trabalho necessita.

• O que está a ser aprovado: um pedido, documento, alteração de registo, pagamento, publicação, direito de acesso ou ação sobre dados de clientes?
• Quem pode solicitá-lo e que campos ou anexos têm de estar completos antes da submissão?
• Quem pode aprovar, rejeitar, devolver para alterações ou cancelar?
• Que limiares, categorias de risco, departamentos, localizações ou classificações de dados alteram o encaminhamento?
• Que ação passa a ser permitida após aprovação e quem a executa?
• Durante quanto tempo devem ser retidos o registo da decisão e as evidências de suporte?

Mapeie o fluxo de trabalho mínimo antes de avaliar o software

Escreva o menor fluxo de trabalho completo em linguagem simples e, em seguida, torne cada etapa testável na aplicação. Uma referência útil inclui pedido, revisão, decisão, notificação, execução e retenção de registos. Se uma ferramenta proposta não conseguir representar uma etapa necessária ou preservar a informação exigida, identifique explicitamente o controlo compensatório em vez de assumir que os utilizadores se irão lembrar.

Mantenha a decisão de aprovação distinta da execução subsequente. Por exemplo, um aprovador pode autorizar uma compra, enquanto outra pessoa cria a encomenda. Esta distinção é importante para a responsabilização e a segregação de funções.

• Pedido: criar um item com identificação única e recolher os dados e evidências necessários.
• Revisão: disponibilizar o item ao revisor ou revisores corretos.
• Decisão: registar a aprovação, rejeição ou devolução para retrabalho com a identidade responsável.
• Notificação: informar o requerente e a próxima parte responsável sobre o que aconteceu.
• Execução: permitir ou acionar a ação subsequente autorizada apenas quando as condições forem cumpridas.
• Retenção: preservar o registo da decisão, os anexos e o histórico durante o período exigido.

Avalie estados e transições, incluindo alterações após a aprovação

Um fluxo de trabalho é definido pelos seus estados e pelas transições permitidas entre eles. No mínimo, teste rascunhos, itens submetidos, itens aprovados e itens rejeitados. Em muitos processos, também precisa de estados de devolvido para alterações, cancelado, expirado, substituído ou executado.

O teste mais revelador é uma alteração material após a aprovação. Se o valor, fornecedor, âmbito, anexo, nível de acesso ou finalidade dos dados de clientes mudar, a aplicação bloqueia o registo, invalida a aprovação, cria uma nova revisão ou simplesmente mantém uma aprovação antiga ao lado de conteúdo alterado? O seu processo deve indicar que alterações exigem nova aprovação, e a aplicação deve tornar esse resultado claro.

Teste também quem pode mover cada estado. Um requerente pode poder editar um rascunho, mas não deve necessariamente conseguir marcá-lo como submetido, aprovado ou executado sem que as condições exigidas sejam cumpridas.

• Os utilizadores conseguem ver o estado atual e o histórico completo de estados anteriores?
• As transições são restringidas por função, atribuição ou condições do fluxo de trabalho?
• Os itens rejeitados são encerrados, editáveis para nova submissão ou encaminhados de volta para correção?
• Uma alteração após a aprovação aciona nova aprovação quando a sua política o exige?
• Um item aprovado pode ser cancelado, sendo retidas a razão do cancelamento e a identidade envolvida?
• Os utilizadores conseguem distinguir um registo aprovado de um registo pendente, revisto ou substituído?

Teste as regras de autoridade, não apenas a atribuição de aprovadores

Um aprovador nomeado é simples de compreender, mas pode ser frágil. Uma avaliação robusta testa se a aplicação consegue refletir o modelo de autoridade que realmente utiliza: revisores baseados em funções, limiares, encaminhamentos condicionais e mais de uma etapa de aprovação. Não assuma que um gestor atribuído é sempre a pessoa autorizada para todas as decisões.

Utilize casos representativos. Teste um pedido de rotina, um pedido imediatamente abaixo e outro imediatamente acima de um limiar monetário, um pedido de alto risco, um pedido que abranja dois departamentos e um pedido que exija revisão jurídica, de segurança ou financeira. Registe se o encaminhamento é automático, se pode ser alterado e o que os utilizadores conseguem ver quando não são o revisor atual.

• Autoridade nomeada: uma pessoa responsável específica pode aprovar?
• Autoridade baseada em função: o atual titular de uma função empresarial aprovada pode aprovar?
• Autoridade por limiar: o encaminhamento muda no montante ou nível de risco exigido?
• Autoridade em várias etapas: os revisores obrigatórios podem atuar pela ordem correta?
• Autoridade paralela: quando são necessárias várias revisões, todas têm de aprovar ou basta uma?
• Autoridade condicional: os revisores obrigatórios podem variar por departamento, tipo de dados, país, projeto ou categoria de pedido?

Verifique a segregação de funções e o acesso privilegiado

A segregação de funções significa mais do que atribuir etiquetas diferentes às pessoas. O controlo [AC-5 da NIST SP 800-53](https://csrc.nist.gov/CSRC/media/Projects/risk-management/800-53%20Downloads/800-53r5/SP_800-53_v5_1-derived-OSCAL.pdf) exige separação de funções definida e documentada, bem como autorizações de acesso que a suportem. Converta esse princípio em testes diretos: um requerente pode aprovar o seu próprio pedido, alterar um registo aprovado, escolher um aprovador inelegível ou contornar um revisor obrigatório?

Avalie separadamente as funções normais da aplicação e o acesso operacional. Numa implementação auto-hospedada, pessoas com acesso amplo à implementação ou ao servidor anfitrião podem conseguir alterar o funcionamento, os dados ou a configuração da aplicação fora do fluxo de trabalho empresarial. A [Docker documenta](https://docs.docker.com/engine/extend/plugins_authorization/) que o seu modelo de autorização padrão é de tudo ou nada para utilizadores autorizados a aceder ao daemon do Docker: esses utilizadores podem executar comandos do cliente Docker. Inclua este acesso no seu modelo de ameaças e na conceção da governação.

Os [plugins de autorização do Docker](https://docs.docker.com/engine/extend/plugins_authorization/) podem tomar decisões de permitir ou negar com base na autenticação e no contexto do comando, mas a Docker também documenta limites ao âmbito da sua aplicação. Se pretende depender desses controlos, teste o seu âmbito em relação às ações administrativas relevantes para o seu processo. Não deduza que as restrições do fluxo de trabalho ao nível da aplicação, por si só, limitam os administradores da infraestrutura.

• Utilize contas de teste separadas para requerente, aprovador, executor, administrador da aplicação e administrador da infraestrutura.
• Tente autoaprovação, aprovação por uma função não autorizada e aprovação após reatribuição.
• Tente editar campos-chave e anexos após a aprovação.
• Identifique quem pode alterar regras do fluxo de trabalho, funções, definições de auditoria, armazenamentos de dados, contentores e cópias de segurança.
• Defina quem revê o acesso privilegiado e com que frequência.
• Assegure que o processo reconhece o risco residual quando uma pequena equipa técnica inevitavelmente detém um amplo acesso operacional.

Avalie delegação, ausência e trabalho em atraso sem perder a responsabilização

Os fluxos de trabalho de aprovação falham frequentemente em circunstâncias normais: um aprovador está de licença, mudou de função ou simplesmente não atua. Um processo funcional precisa de uma rota deliberada para delegação, reatribuição e escalonamento. O objetivo é assegurar continuidade sem ocultar quem tinha autoridade e quem tomou a decisão final.

Teste se a aplicação regista o responsável original, a pessoa ou regra que reatribuiu o trabalho, a decisão do delegado e o momento de cada evento. Se a delegação for tratada fora da aplicação, decida como essa instrução será documentada e como será verificada a autoridade do novo aprovador.

• Um aprovador só pode delegar dentro de uma função ou nível de autoridade permitido?
• O sistema preserva o responsável original e o histórico de delegação?
• O proprietário do processo pode reatribuir um item em atraso, sendo registada a razão?
• Os lembretes e escalonamentos são configuráveis o suficiente para o tempo de resposta exigido?
• O que acontece se a conta de um aprovador for desativada ou removida enquanto há trabalho pendente?
• Existe um procedimento de emergência documentado, com revisão posterior, para decisões que não podem esperar?

Avalie as evidências de aprovação e os registos de auditoria

O registo da decisão deve responder a questões básicas sem depender da memória de alguém: o que aconteceu, quando e onde aconteceu, a origem do evento, qual foi o resultado e que identidades estavam associadas. Estes elementos estão alinhados com os elementos de registo de auditoria do controlo [AU-3 da NIST SP 800-53](https://csrc.nist.gov/CSRC/media/Projects/risk-management/800-53%20Downloads/800-53r5/SP_800-53_v5_1-derived-OSCAL.pdf).

Para cada decisão, examine o resultado efetivamente retido em vez de depender de um painel de controlo. Determine se inclui a versão do pedido, a decisão, a data e hora, a identidade do aprovador, comentários, evidências anexadas, atribuições e todas as alterações significativas. Em seguida, teste se um utilizador consegue exportar ou recuperar as evidências num formato que continue compreensível fora da aplicação.

As evidências só são úteis se permanecerem fiáveis. O [AU-9 da NIST SP 800-53](https://csrc.nist.gov/CSRC/media/Projects/risk-management/800-53%20Downloads/800-53r5/SP_800-53_v5_1-derived-OSCAL.pdf) aborda a proteção da informação de auditoria e a restrição da gestão das funções de registo a um subconjunto apropriado de utilizadores privilegiados. Pergunte quem pode modificar, eliminar, desativar ou substituir registos e logs de aprovação e como essas ações são, elas próprias, detetadas ou revistas.

• Identificador do pedido e versão ou revisão aprovada.
• Tipo de evento, hora, origem do evento, resultado e identidades associadas.
• Comentários da decisão, motivos de rejeição e anexos associados, quando exigidos.
• Um histórico completo de atribuições, delegações e alterações de estado.
• Procedimentos de retenção, exportação e recuperação que tenham sido testados.
• Controlos de acesso sobre registos de aprovação e registos de auditoria, incluindo a governação de utilizadores privilegiados.