Quem é responsável por esta aplicação autoalojada? Crie um registo de responsabilidades da aplicação

Porque é que uma aplicação pode estar tecnicamente em funcionamento, mas sem responsável operacional

Uma página de início de sessão funcional não é prova de responsabilidade. Uma aplicação pode ter um domínio funcional, certificado TLS válido, recursos de servidor e cópias de segurança agendadas e, ainda assim, não ter responsável nos aspetos importantes quando é necessária uma decisão de negócio. Quem decide se a ferramenta continua a ser necessária? Quem aprova um novo administrador? Quem determina se uma exportação pode ser partilhada? Quem pode decidir que restaurar os dados de ontem é a resposta correta a um erro?

Esta lacuna é comum em portefólios pequenos e médios. Um departamento pede uma ferramenta, alguém faz a implementação e o trabalho de infraestrutura é concluído. Com o tempo, o requisitante original muda de função, as pessoas que compreendem o processo saem e as credenciais, integrações e dados permanecem. A aplicação continua a funcionar, mas a responsabilização é distribuída apenas de forma informal — ou não existe de todo.

O NIST Cybersecurity Framework 2.0 defende que as funções, responsabilidades e autoridades de cibersegurança sejam estabelecidas e comunicadas. Este princípio aplica-se bem ao software autoalojado: responsabilidade clara não é burocracia por si só. Torna as decisões correntes mais rápidas e as decisões sob pressão menos improvisadas.

A solução é um registo de responsabilidades de aplicações autoalojadas: um registo mantido de cada aplicação, do motivo da sua existência, de quem tem autoridade de decisão, de onde se encontram dependências importantes e do que tem de acontecer se o serviço mudar ou falhar. Pode começar por ser uma folha de cálculo. O NIST nota explicitamente que um inventário pode ser tão simples como uma folha de cálculo; o valor resulta de o manter utilizável, atualizado e ligado às decisões operacionais reais.

• Considere «a pessoa que a implementou» como um facto temporário, não automaticamente como o responsável permanente.
• Acompanhe aplicações, dados, software, serviços e dependências de fornecedores — não apenas servidores e contentores.
• Atribua a cada aplicação de produção um responsável principal nomeado e uma rota de substituição ou escalonamento também nomeada.
• Reveja a responsabilidade após uma mudança de função, uma alteração importante de integração, um incidente de segurança ou uma alteração do processo de negócio.

Separe as quatro funções de responsabilidade antes de atribuir nomes

Numa equipa muito pequena, uma pessoa pode desempenhar várias funções, mas as próprias funções devem manter-se distintas. Isto evita esperar que um operador de infraestrutura decida a política de retenção de um departamento, ou que um responsável de negócio diagnostique um problema de encaminhamento. O registo deve identificar a pessoa ou equipa responsável por cada função e especificar a autoridade associada.

O responsável de negócio responde pelo resultado que a aplicação suporta. Define porque existe, quem a deve utilizar, que nível de interrupção o negócio pode tolerar e se a aplicação deve continuar, mudar ou ser descontinuada. É quem toma decisões sobre o processo de negócio, não necessariamente quem configura o software.

O administrador da aplicação trata da operação ao nível da aplicação: contas, funções, configuração, administração de rotina e coordenação de primeira linha com os utilizadores. Consoante a aplicação, pode ser um utilizador avançado de um departamento, um generalista de TI ou uma função de suporte externa. O administrador não deve tornar-se silenciosamente na autoridade final para decisões de negócio ou dados pessoais apenas porque pode clicar nos controlos.

O responsável pelos dados toma ou escala decisões sobre a informação no sistema: classificação de dados, uso permitido, partilha, exportações, retenção e eliminação. Para o tratamento abrangido pelo RGPD, o responsável pelo tratamento é a entidade que determina as finalidades e os meios de tratamento dos dados pessoais; um subcontratante trata dados pessoais em nome do responsável pelo tratamento. As funções jurídicas dependem dos factos e dos acordos, pelo que um registo operacional não deve ser usado como substituto de análise jurídica. A distinção continua a ser útil operacionalmente porque separa as decisões sobre a finalidade dos dados do trabalho técnico de alojamento ou tratamento.

O operador de infraestrutura responde pela camada de cloud e plataforma que envolve a aplicação. O seu âmbito pode incluir operação de servidores, ciclo de vida das cargas de trabalho, encaminhamento, certificados, verificações de DNS e cópias de segurança, de acordo com o acordo de serviço. Esta função não assume automaticamente a responsabilidade pelos utilizadores da aplicação, pelo processo de negócio, pelas escolhas de retenção de dados ou pela aprovação de todas as alterações. Com a Airbip, as instâncias das aplicações são executadas como cargas de trabalho Docker nos servidores cloud da Airbip, enquanto a Airbip trata dos serviços de infraestrutura em seu redor, incluindo automatização de encaminhamento e TLS, verificações de DNS, gestão do ciclo de vida e agendamentos de cópias de segurança configuráveis. Os clientes continuam a precisar de pessoas nomeadas para tomar as decisões relativas à aplicação, aos acessos e aos dados que não podem ser inferidas a partir da infraestrutura.

• Responsável de negócio: responde pelo propósito, utilizadores, criticidade e decisões de continuidade ou descontinuação.
• Administrador da aplicação: responsável pela configuração diária da aplicação e administração de contas.
• Responsável pelos dados: responde pela classificação, uso permitido, retenção, eliminação e decisões de exportação.
• Operador de infraestrutura: responsável pelo âmbito acordado de alojamento e operação da plataforma.
• Contacto de segurança ou privacidade: adicione esta função quando o risco, a política ou a regulamentação exigirem uma revisão especializada.

Os campos mínimos de um registo de responsabilidades da aplicação

Comece com uma linha por aplicação de produção ou instância de produção distinta. Um registo fácil de preencher e rever é melhor do que um sistema sofisticado que ninguém atualiza. Adicione ligações para documentos de apoio em vez de transformar o registo num repositório de todos os detalhes de configuração.

As orientações de gestão de ativos do NIST apoiam um inventário suficientemente abrangente para incluir software, sistemas, serviços, dados e serviços fornecidos por fornecedores. Também recomendam priorizar ativos com base na classificação, criticidade, recursos e impacto na missão. Por isso, o seu registo deve combinar factos operacionais com informação sobre responsabilidade e decisão.

Utilize identificadores estáveis. Os nomes de produtos, por si só, são frequentemente ambíguos quando uma equipa tem uma instância de teste e uma de produção, várias implementações departamentais ou uma instância descontinuada que retém dados. Registe um ID interno único, o ambiente e o URL canónico do serviço.

• Identidade da aplicação: ID interno, nome da aplicação, ambiente de produção ou não produção, URL do serviço e data de implementação, se conhecida.
• Contexto de negócio: propósito, responsável de negócio, departamentos utilizadores, população de utilizadores e contacto de substituição nomeado.
• Contactos operacionais: administrador da aplicação, operador de infraestrutura, contacto de escalonamento de segurança ou privacidade e contacto do fornecedor, quando relevante.
• Criticidade: um nível simples e uma declaração de impacto em linguagem simples que explique o que para se a aplicação ficar indisponível.
• Acessos: responsável pela aprovação de contas, responsável por acessos privilegiados, responsável pelo offboarding e cadência de revisão.
• Dados: responsável pelos dados, classificação, principais categorias de dados, localizações, exportações, regra de retenção, responsável pela decisão de eliminação e referências legais ou de políticas aplicáveis.
• Dependências: domínio, conta ou responsável de DNS, serviço de envio de e-mail, fornecedor de identidade, integrações, responsável pelas credenciais de API, armazenamento persistente e âmbito das cópias de segurança.
• Alteração e recuperação: aprovador de alterações, responsável pela decisão de atualização, responsável pela decisão de recuperação, contactos de recuperação, data do último teste de restauro e ligações para runbooks ou evidências de testes.

Registe o propósito, os utilizadores e a criticidade de negócio em linguagem de negócio

Não descreva o propósito de uma aplicação como «CRM», «wiki» ou «ferramenta de automatização». Escreva a atividade de negócio que permite realizar: por exemplo, «mantém os registos de potenciais clientes e acompanhamento de clientes da equipa comercial» ou «publica a documentação pública utilizada por clientes e suporte». Isto permite que alguém fora da equipa técnica avalie o impacto e aprove prioridades.

Liste tanto os utilizadores previstos como os utilizadores afetados. Um painel interno pode ter dez utilizadores diretos, mas suportar um serviço utilizado por todos os clientes. Um sistema de fluxos de trabalho pode ter apenas dois administradores, mas ser essencial para um processo financeiro mensal. Inclua períodos de pico, prazos ou alternativas manuais se afetarem materialmente a forma como uma interrupção deve ser tratada.

Escolha um método de criticidade que a sua equipa consiga aplicar de forma consistente. Não precisa de ser um modelo de pontuação complexo. Um nível prático pode combinar a consequência da indisponibilidade, a sensibilidade dos dados, a concentração de dependências e a disponibilidade de um processo manual viável. O NIST apoia a priorização de ativos por classificação, criticidade, recursos e impacto na missão.

A criticidade é um contributo para as decisões, não uma garantia. Ajuda o responsável de negócio e o operador de infraestrutura a acordar que serviços precisam do plano de recuperação mais claro, de revisão de responsabilidade mais frequente e de aprovação de alterações mais deliberada.

• Indique o processo de negócio, não apenas a categoria do produto.
• Nomeie o departamento que detém o resultado e a pessoa com autoridade de decisão.
• Registe utilizadores diretos, partes interessadas afetadas e quaisquer ciclos sensíveis ao tempo.
• Descreva em termos concretos o impacto de um dia sem a aplicação.
• Indique se existe uma solução manual alternativa, quem a pode executar e os seus limites práticos.
• Defina uma data de revisão; a criticidade pode mudar à medida que o processo, as integrações ou os dados mudam.

Atribua responsabilidades por contas, funções e acesso privilegiado

A administração de acessos é um dos pontos mais claros onde «todos pensavam que alguém tratava disso» cria risco. O registo deve responder a quem pode pedir acesso, quem o aprova, quem cria ou altera contas, quem pode conceder permissões elevadas e quem verifica os acessos após uma mudança de função ou saída.

As orientações gerais do NIST recomendam contas únicas para os colaboradores e acesso limitado aos recursos necessários para o seu trabalho. Traduza isto numa regra operacional prática: evite contas de utilizador nomeadas partilhadas quando forem possíveis contas individuais, conceda apenas o acesso necessário ao trabalho atribuído e torne visível o percurso de aprovação.

O acesso privilegiado necessita de um campo separado. Um utilizador normal da aplicação, um administrador da aplicação, um administrador de domínio e um administrador de infraestrutura podem afetar o serviço de formas diferentes. Registe que função pode aceder à administração da aplicação, aos controlos do servidor ou da carga de trabalho, ao DNS, às definições de envio de e-mail, às cópias de segurança e a quaisquer credenciais de integração. Não coloque segredos no registo; guarde apenas o sistema de registo do segredo e o responsável por ele.

Inclua um gatilho de offboarding. Um registo não substitui os processos de identidade e recursos humanos, mas deve identificar quem confirma que as contas e os acessos privilegiados são revistos quando um trabalhador, prestador de serviços ou administrador sai ou muda de responsabilidades.

• Percurso de pedido de conta: requerente, aprovador e administrador.
• Modelo de funções: funções padrão, quem as pode atribuir e quem pode criar funções personalizadas.
• Responsável por acesso privilegiado: pessoa ou equipa nomeada para cada superfície administrativa.
• Cadência de revisão de acessos: defina o evento ou intervalo que desencadeia a revisão.
• Responsável pelo offboarding: identifique quem confirma a remoção ou reatribuição de acessos.
• Acesso de emergência: documente quem o pode autorizar e como a decisão é registada posteriormente.

Atribua responsabilidades pela classificação, retenção, exportações e eliminação de dados

A infraestrutura pode preservar dados, mas não pode decidir que dados devem ser recolhidos, se podem ser exportados ou durante quanto tempo devem permanecer identificáveis. Estas são decisões de governação que pertencem aos responsáveis de negócio e pelos dados, informados por requisitos de privacidade, segurança, contratuais e de gestão documental, quando aplicável.

Para o tratamento abrangido pelo RGPD, o artigo 30 identifica elementos úteis do registo, como os dados de contacto do responsável pelo tratamento, as finalidades do tratamento, as categorias de titulares dos dados e de dados pessoais, os destinatários, as transferências, os prazos para apagamento e uma descrição geral das medidas de segurança. O seu registo de responsabilidades da aplicação não precisa de duplicar um registo formal das atividades de tratamento, mas deve estabelecer ligação a um ou conter informação suficiente para identificar o responsável pelos dados e o registo oficial.

A retenção deve ser expressa como uma decisão associada a uma finalidade, não apenas como «guardar para sempre» ou o número de dias durante os quais existe uma cópia de segurança. O princípio da limitação da conservação do RGPD exige que os dados pessoais não sejam conservados de forma identificável durante mais tempo do que o necessário para a finalidade, sujeito a exceções especificadas. Se e como isto se aplica à sua organização exige contexto; o ponto operacional é nomear quem detém a decisão de retenção e onde ela está documentada.

Separe, no seu raciocínio, os dados ativos, exportações, registos de eventos e cópias de segurança. Um administrador pode conseguir eliminar um registo na aplicação enquanto uma cópia de segurança permanece sujeita a um ciclo de vida diferente. No fim dos serviços de subcontratação ao abrigo do RGPD, o responsável pelo tratamento escolhe a eliminação ou a devolução dos dados pessoais, sujeito a requisitos legais de conservação. O seu registo deve tornar visíveis a autoridade de decisão e o processo esperado, em vez de assumir que uma ação de infraestrutura resolve a questão.

• Nomeie o responsável pelos dados e estabeleça ligação ao inventário de dados, política ou registo de tratamento aplicável.
• Classifique os principais tipos de dados, incluindo informação pessoal, confidencial, financeira ou operacional de acordo com o esquema da sua organização.
• Registe onde residem os dados: base de dados da aplicação, armazenamento de ficheiros, serviços ligados, exportações e localizações ou âmbitos de cópias de segurança.
• Defina quem pode aprovar exportações, importações, transferências em massa e transferências baseadas em integrações.
• Registe os responsáveis pelas decisões de retenção e eliminação, a regra aplicável e as exceções que exigem aprovação.
• Documente a eliminação na aplicação, a retenção de cópias de segurança e a terminação do serviço como questões operacionais distintas.

Documente dependências de domínios, DNS, e-mail e integrações

Muitas indisponibilidades de aplicações são indisponibilidades de dependências. Um serviço pode estar saudável enquanto os utilizadores não lhe conseguem aceder porque o domínio, o registo DNS, o percurso de certificados, o fornecedor de identidade, a configuração de e-mail ou uma integração externa mudou. Estas dependências devem ser registadas com o mesmo cuidado que a própria aplicação.

Para encaminhamento público, a documentação do Traefik distingue pontos de entrada que recebem tráfego, routers que ligam pedidos a serviços e middleware opcional. A sua documentação TLS refere que a gestão automática de certificados para domínios configurados depende de os registos DNS relevantes apontarem para o Traefik. A lição operacional é simples: registe o domínio canónico, o responsável pelo DNS, onde o DNS é administrado e quem pode aprovar ou efetuar uma alteração. Não dependa da conta de registador de um ex-colaborador ou de credenciais não documentadas.

Se a aplicação envia e-mail, registe o domínio ou serviço de envio, o responsável pelos registos DNS relevantes e a pessoa responsável pelas decisões de configuração. Para integrações, registe o que a ligação faz, os dados que troca, o responsável pelas credenciais, o responsável de negócio de cada lado e a consequência caso falhe. Uma ligação à documentação da integração é mais útil do que uma nota vaga que diga «ligado à automatização».

Para implementações em contentores, registe o armazenamento persistente separadamente da carga de trabalho em execução. O Docker suporta volumes externos cujo ciclo de vida é gerido fora da aplicação. Um contentor pode ser recriado enquanto o armazenamento de dados tem um ciclo de vida, responsável e consideração de recuperação separados. As etiquetas do Docker também podem anotar contentores, volumes, redes, imagens e serviços com metadados de chave-valor; quando a sua prática de implementação o suportar, utilize etiquetas não sensíveis, como um ID interno de aplicação ou grupo de responsabilidade, para melhorar a rastreabilidade. Mantenha o registo como o registo de negócio oficial, em vez de depender apenas de etiquetas técnicas.

• URL canónico, domínios alternativos e URLs específicos de cada ambiente.
• Responsável pelo registador de domínio e pela gestão de DNS, com uma rota de escalonamento.
• Responsabilidade pelo encaminhamento e TLS, incluindo o limite acordado do serviço de infraestrutura.
• Dependência de envio de e-mail, responsável pelo domínio do remetente e contacto de configuração.
• Dependências de identidade, pagamentos, análise, armazenamento, API e automatização.
• Finalidade da integração, dados trocados, responsável pelo sistema de credenciais e impacto da falha.
• Volumes persistentes ou outro armazenamento durável, âmbito das cópias de segurança e responsável pelo armazenamento.

Defina decisões de alteração, atualização e recuperação antes de um incidente

Um incidente é a pior altura para descobrir que o operador de infraestrutura consegue restaurar uma cópia de segurança, mas não tem autoridade para escolher um ponto de recuperação, ou que o responsável de negócio pretende adiar uma atualização, mas ninguém sabe quem avalia o risco. Defina o percurso de decisão antes de ser urgente.

Utilize uma matriz de alterações simples. A administração de rotina da aplicação, reversível, pode ser delegada ao administrador da aplicação. Alterações que afetam utilizadores, tratamento de dados, integrações, domínios públicos ou fluxos de trabalho de negócio devem ter um aprovador identificado. Alterações à infraestrutura, encaminhamento, configuração de cópias de segurança ou ciclo de vida da plataforma devem ser coordenadas com o operador de infraestrutura de acordo com o âmbito de serviço acordado. O objetivo não é atrasar todas as alterações; é distinguir o trabalho de rotina das decisões com impacto material.

Para a recuperação, documente quem declara que o processo de negócio está afetado, quem seleciona o objetivo ou ponto de recuperação depois de consultar o responsável de negócio, quem executa a ação técnica e quem verifica o serviço e os dados restaurados. O NIST CSF 2.0 afirma que as ações de recuperação devem ser selecionadas, delimitadas, priorizadas e executadas, e que as cópias de segurança e os ativos de restauro devem ser verificados antes da utilização. Também exige a confirmação da integridade e do estado normal de funcionamento após o restauro.

Um agendamento de cópias de segurança, por si só, é insuficiente. O NIST recomenda testar que os dados com cópia de segurança podem ser restaurados com êxito. No registo, inclua a data do último teste de restauro, a pessoa ou equipa que o verificou, o que foi testado e uma ligação à evidência ou ao runbook. A Airbip disponibiliza cópias de segurança diárias, semanais e mensais configuráveis, mas os clientes devem ainda atribuir os responsáveis do lado do negócio e da aplicação que decidem que recuperação é aceitável e quem verifica se a aplicação recuperada está apta para utilização.

Reveja o registo num intervalo previsível e após alterações significativas. A revisão deve ser curta: confirme que os responsáveis nomeados continuam presentes, os contactos ainda funcionam, os domínios e dependências estão atualizados, os acessos privilegiados são compreendidos, as decisões de retenção continuam válidas e a evidência de recuperação é suficientemente recente para a criticidade da aplicação.

• Defina que alterações são de rotina, quais exigem aprovação de negócio e quais exigem revisão de dados ou segurança.
• Nomeie um responsável pela decisão de atualização e um coordenador técnico.
• Documente um percurso de contacto para incidentes que funcione fora do horário normal de trabalho se a criticidade da aplicação o exigir.
• Nomeie a autoridade que seleciona uma abordagem e um ponto de recuperação.
• Exija verificação de negócio e técnica antes de declarar a recuperação concluída.
• Registe testes de restauro, lições aprendidas e ações necessárias para manter o registo correto.