Uma aplicação autoalojada ou várias? Um modelo de decisão para separar equipas e clientes

Um espaço de trabalho, uma função e uma implementação resolvem problemas diferentes

A questão não é apenas saber se as pessoas devem ver pastas, projetos ou registos diferentes. É determinar que fronteira tem de ser aplicada, quem é considerado de confiança para operar de cada lado dessa fronteira e com que independência cada grupo precisa de mudar e recuperar.

Uma função na aplicação define normalmente o que um utilizador autenticado pode fazer. Um espaço de trabalho, organização, projeto ou contentor lógico semelhante pode organizar registos e limitar quais os utilizadores que os podem visualizar ou editar. Estes controlos podem ser eficazes quando a aplicação os implementa corretamente e quando são configurados, revistos e testados. Continuam, no entanto, a ser controlos dentro de uma única implementação da aplicação.

Uma implementação separada é uma fronteira de infraestrutura e operações. Numa configuração baseada em contentores, um projeto Docker Compose (https://docs.docker.com/compose/intro/compose-application-model/) agrupa os recursos de uma implementação e pode isolá-los de outras instalações que utilizem parâmetros diferentes. Um projeto separado também pode ter a sua própria rede predefinida. Isto não o torna um anfitrião totalmente independente nem elimina a importância da administração do anfitrião, mas é materialmente diferente de criar outro espaço de trabalho na mesma aplicação.

Não use o nome de um espaço de trabalho como abreviatura de uma arquitetura de segurança. Primeiro, determine o que a aplicação realmente isola; depois, decida se esse isolamento corresponde à promessa feita a uma equipa, cliente, entidade jurídica ou regulador.

• Fronteira de funções de utilizador: que ações podem executar os utilizadores com sessão iniciada.
• Fronteira lógica de dados: a que registos, projetos ou espaços de trabalho os utilizadores podem aceder dentro de uma aplicação.
• Fronteira de implementação: que serviços da aplicação, configuração, dados persistentes, credenciais, rotas e calendário de versões pertencem ao mesmo conjunto.
• Fronteira do administrador do anfitrião: quem pode administrar o servidor, o runtime de contentores, o armazenamento e a configuração da implementação.
• Fronteira de recuperação: que dados podem ser restaurados de forma independente, por quem e com que efeito nos restantes utilizadores.

Comece por identificar a fronteira real

Uma equipa nem sempre é a unidade que precisa de separação. A fronteira relevante pode ser uma organização cliente, uma entidade jurídica, uma unidade de negócio com administradores distintos, um ambiente de produção ou uma categoria de dados com requisitos especiais de tratamento. Um desenho útil começa com uma declaração, em linguagem simples, do que não pode atravessar essa fronteira.

Por exemplo: “Os colaboradores do Cliente A não podem aceder aos registos do Cliente B” é, sobretudo, um requisito de acesso à aplicação. “O Cliente A tem de ter um conjunto de dados restaurável separadamente, integrações sob propriedade separada e não depender da aprovação do Cliente B para lançamentos” exige uma fronteira operacional mais forte. “Um cliente externo não deve ter de confiar nos nossos administradores internos para aceder à configuração do seu serviço e aos dados armazenados” levanta uma questão de alojamento e confiança administrativa, e não apenas uma questão de desenho de funções.

Quando estão envolvidos dados pessoais, a governação deve abranger tanto a prevenção como a recuperação. O artigo 5.º do RGPD (https://eur-lex.europa.eu/eli/reg/2016/679/oj?locale=EN) exige medidas técnicas ou organizativas adequadas que protejam contra o tratamento não autorizado ou ilícito e contra a perda, destruição ou danos acidentais. Também inclui a limitação da conservação: os dados pessoais identificáveis não devem ser conservados durante mais tempo do que o necessário para a finalidade a que se destinam, sujeito às exceções indicadas. Obrigações diferentes de retenção ou eliminação são frequentemente uma razão prática para evitar um património de dados único e indiferenciado.

• Identifique a população protegida: colaboradores internos, um cliente, uma entidade jurídica, uma função regulada ou um ambiente de produção.
• Indique a consequência de um erro de acesso: incómodo, incumprimento contratual, exposição de informação confidencial ou impacto regulamentar.
• Liste as pessoas que necessitam de acesso elevado: administradores da aplicação, responsáveis por integrações, administradores de infraestrutura e pessoal de suporte.
• Registe se os dados têm de ser exportados, retidos, eliminados ou restaurados num calendário diferente para cada grupo.
• Documente se a fronteira é uma preferência de organização ou um requisito contratual, jurídico ou de segurança.

Quando uma instância partilhada é a opção mais simples e adequada

Uma instância partilhada pode ser a resposta certa quando os grupos trabalham verdadeiramente sob o mesmo modelo de governação. Centraliza atualizações, monitorização, administração da autenticação, configuração da aplicação, rotinas de cópias de segurança e suporte aos utilizadores. Também pode tornar a colaboração e os relatórios entre equipas menos fragmentados quando a partilha é intencional e o modelo de acesso da própria aplicação suporta as restrições necessárias.

Um modelo partilhado é mais sólido quando a organização consegue definir e operar um único domínio administrativo. Os mesmos administradores de confiança podem gerir o sistema, um único calendário de lançamentos é aceitável, as integrações podem ser geridas centralmente e uma restauração que afete toda a aplicação é um evento de recuperação aceitável. Esta é frequentemente uma base sensata para departamentos internos de uma organização com necessidades comparáveis de sensibilidade e ciclo de vida.

A contrapartida é o acoplamento. Uma alteração de configuração a nível de toda a aplicação, uma função de administrador abrangente, uma credencial de integração partilhada ou uma restauração de toda a instância pode ter consequências para todos os grupos. O modelo não é inseguro por definição; precisa apenas de uma governação disciplinada e proporcional aos dados e às partes interessadas envolvidas.

• Escolha uma instância partilhada quando a colaboração entre grupos é esperada e permitida.
• Confirme que a aplicação dispõe das funções e dos controlos de isolamento lógico necessários antes de integrar grupos sensíveis.
• Aplique o princípio do menor privilégio tanto a utilizadores comuns como a administradores; não conceda acesso administrativo abrangente apenas por conveniência.
• Mantenha um processo regular de revisão de acessos, especialmente após alterações de pessoal ou o fim da relação com um cliente.
• Trate atualizações, alterações de configuração, exportações e restauros ao nível de toda a aplicação como alterações que podem afetar todos os grupos.

Quando instâncias separadas são geralmente a opção operacional mais segura

Instâncias separadas são geralmente a opção mais segura quando os grupos têm dados geridos de forma independente, administradores de confiança diferentes, credenciais de integração incompatíveis ou requisitos distintos de ciclo de vida e recuperação. As agências encontram frequentemente esta situação quando cada cliente espera ter os seus próprios utilizadores, domínio, serviços ligados, exportações de dados, processo de saída e circuito de aprovação de alterações.

Instâncias separadas podem reduzir o raio de impacto de uma alteração de configuração ou restauração incorreta, porque cada instância pode ter a sua própria configuração de aplicação e âmbito de dados persistentes. Também tornam a titularidade mais fácil de explicar: este domínio, rota, instância, conjunto de credenciais, âmbito de cópias de segurança e manual operacional pertencem a esta organização. O benefício não é que os contentores façam desaparecer todos os riscos. É que os controlos operacionais podem alinhar-se mais estreitamente com a fronteira organizacional real.

A Docker aconselha (https://docs.docker.com/engine/security/) que apenas utilizadores de confiança controlem o daemon Docker, porque as suas capacidades podem permitir montar diretórios do anfitrião em contentores sem limitar os direitos de acesso do contentor. Por conseguinte, aplicações separadas num anfitrião partilhado não eliminam a necessidade de governar o acesso dos administradores de infraestrutura. O modo Rootless da Docker (https://docs.docker.com/engine/security/rootless/) pode reduzir a exposição ao executar o daemon e os contentores como utilizador sem privilégios de root, mas é uma medida de reforço do anfitrião, não um substituto para domínios administrativos independentes.

• Separe por organização quando um cliente necessita de decisões independentes sobre titularidade, saída ou recuperação.
• Separe quando o administrador de um grupo não deve administrar a configuração da aplicação de outro grupo.
• Separe quando credenciais, webhooks, chaves de API ou contas externas têm de ser detidos e rotacionados de forma independente.
• Separe quando o calendário de lançamentos, a configuração personalizada, a retenção ou a aprovação de alterações divergem de forma material.
• Vá além de instâncias separadas num único anfitrião quando a fronteira exigida inclui confiança independente nos administradores de infraestrutura ou um isolamento contratual mais forte.

Avalie cinco fatores de decisão antes de escolher o modelo

Use os fatores seguintes como teste prático. Atribua a cada fator uma classificação para cada grupo proposto: necessidade de independência baixa, média ou alta. Um único requisito de alto risco pode superar várias vantagens de conveniência de um modelo partilhado.

O essencial é avaliar controlos demonstrados, e não rótulos. Se a aplicação afirma ter organizações ou espaços de trabalho, teste as ações exatas que importam: visualizar registos, pesquisar, exportar, convidar utilizadores, alterar permissões, administrar integrações e eliminar dados. Se um requisito não puder ser demonstrado num ambiente de teste ou sustentado pela documentação da aplicação, trate-o como não cumprido até prova em contrário.

• 1. Visibilidade dos dados: os utilizadores, administradores e equipa de suporte conseguem ver apenas os registos que estão autorizados a tratar? Teste navegação direta, pesquisa, relatórios, notificações, exportações e ações em massa — não apenas a interface normal de utilizador.
• 2. Acesso de administrador: quem pode alterar funções, configuração, armazenamento, registos de atividade e definições de implementação? Distinga as funções da aplicação do acesso ao anfitrião Docker, ao runtime e ao armazenamento persistente. Aplique segregação de funções e o princípio do menor privilégio sempre que seja prático.
• 3. Integrações e segredos: cada grupo precisa das suas próprias chaves de API, conta de e-mail, destino de webhook, configuração de identidade ou ligação a dados externos? O Docker Compose pode conceder um segredo (https://docs.docker.com/compose/how-tos/use-secrets/) apenas aos serviços que o declaram explicitamente e monta-o como ficheiro. Evite tratar variáveis de ambiente como um armazenamento inofensivo de segredos; a Docker alerta que palavras-passe e chaves de API aí presentes podem ser expostas inadvertidamente, incluindo através de registos de depuração.
• 4. Independência de ciclo de vida: cada organização pode aceitar a mesma janela de atualização, configuração base, processo de suporte e circuito de aprovação de alterações? Caso contrário, a partilha cria dívida de coordenação.
• 5. Fronteiras de cópia de segurança e restauro: um grupo pode ser restaurado sem reverter, expor ou perturbar outro? A questão importante é saber se o procedimento de restauro planeado demonstra a fronteira de que necessita.

Mapeie o modelo de isolamento da aplicação antes de depender dele

Cada aplicação tem o seu próprio modelo, e termos genéricos não são suficientes. Antes de decidir que uma instância partilhada é adequada, crie um mapa dos seus controlos baseado em evidências. Utilize a versão e a documentação relevantes para a implementação planeada e valide pressupostos importantes com contas de teste.

Comece pelo comportamento dos utilizadores comuns e avance para fora. O que define a pertença? Uma pessoa pode pertencer a mais do que um espaço de trabalho? As funções têm âmbito global ou estão limitadas a um espaço de trabalho? Os utilizadores podem descobrir registos através de pesquisa, ligações, relatórios, notificações ou exportações fora do âmbito esperado? Os ecrãs de auditoria, administração e integração estão disponíveis para uma classe de utilizadores mais ampla do que os ecrãs operacionais?

Em seguida, mapeie o percurso dos dados. Identifique a base de dados ou armazenamento persistente, ficheiros carregados, registos da aplicação, exportações, destinos de e-mail ou webhook e cópias de segurança. Um contentor de front-end separado não é uma fronteira de recuperação independente se duas organizações continuarem a utilizar o mesmo armazenamento de dados ou artefacto de cópia de segurança. As orientações da Docker sobre volumes (https://docs.docker.com/engine/storage/volumes/) incluem procedimentos para arquivar e restaurar volumes com nome, reforçando uma regra básica de planeamento: os dados persistentes e um procedimento de restauro testado têm de fazer parte do desenho da fronteira.

• Documente separadamente as funções globais e as funções com âmbito limitado.
• Teste a remoção de pertença, a desativação de utilizadores, os fluxos de convite e a transferência de administração.
• Teste a visibilidade de registos através dos ecrãs normais, pesquisa, APIs quando aplicável, relatórios gerados, notificações e exportações.
• Identifique onde residem anexos, registos, exportações e dados persistentes.
• Documente quem pode aceder à configuração da aplicação, manifestos de implementação, armazenamento do anfitrião, cópias de segurança e material secreto.
• Guarde evidências de teste com o registo da decisão, especialmente para compromissos com clientes ou dados sensíveis.

Compare três padrões práticos de implementação

O primeiro padrão é uma aplicação partilhada. É economicamente eficiente do ponto de vista operacional e pode funcionar bem para uma única organização ou um conjunto de equipas internas estreitamente governado. Depende fortemente do modelo de autorização da aplicação e da gestão cuidadosa de administradores globais, configuração partilhada, integrações e procedimentos de recuperação.

O segundo padrão é uma instância da aplicação por organização. Cada organização recebe a sua própria configuração de implementação, âmbito de dados persistentes, nome de anfitrião ou regra de encaminhamento, administração da aplicação e registo operacional. Isto oferece normalmente uma base mais clara para credenciais separadas, decisões de lançamento, exportações, ações de retenção e restauros. Introduz trabalho operacional repetido que deve ser planeado, e não improvisado.

O terceiro padrão consiste em serviços de infraestrutura partilhados com instâncias de aplicação separadas. Por exemplo, projetos Compose separados podem utilizar (https://docs.docker.com/compose/how-tos/networking/) as suas próprias redes específicas do projeto para componentes internos, como uma aplicação e uma base de dados, ligando-se deliberadamente a uma rede partilhada criada externamente quando é necessária a comunicação com um serviço de edge ou suporte partilhado. Isto pode equilibrar consistência com conectividade limitada da aplicação, mas a pertença à rede e as rotas têm de ser desenhadas e revistas explicitamente.

• Uma instância partilhada: melhor quando a governação, administração, ciclo de vida e recuperação são verdadeiramente partilhados.
• Uma instância por organização: melhor quando a titularidade e as decisões operacionais têm de ser independentes.
• Serviços partilhados com instâncias de aplicação separadas: melhor quando uma organização pode centralizar com segurança determinadas funções de plataforma, mantendo distintas as fronteiras da aplicação e da camada de dados.
• Para cada padrão, decida explicitamente se a administração do anfitrião é partilhada, restrita ou exige um modelo de separação mais forte.

Planeie o trabalho operacional que se multiplica com cada instância

Instâncias separadas reduzem algum acoplamento de governação, mas aumentam o inventário operacional. Cada instância precisa de um proprietário identificado, um modelo de acesso, um domínio ou regra de encaminhamento, configuração da aplicação, credenciais, âmbito de cópia de segurança, expectativas de monitorização, histórico de atualizações e um percurso de resposta a incidentes. Uma agência que cria instâncias rapidamente, mas não consegue identificar o proprietário ou o procedimento de restauro, criou um risco evitável.

A gestão de domínios e TLS faz parte deste trabalho. A configuração dinâmica do Traefik (https://doc.traefik.io/traefik/reference/routing-configuration/dynamic-configuration-methods/) determina como os pedidos recebidos são encaminhados para serviços, e essa configuração pode ser fornecida através de mecanismos que incluem etiquetas Docker e ficheiros. Por isso, cada instância precisa de um mapeamento preciso e mantido entre o nome de anfitrião ou regra e o respetivo serviço. Um router Traefik configurado para TLS (https://doc.traefik.io/traefik/v3.2/routing/routers/) processa pedidos HTTPS e termina TLS antes de enviar tráfego desencriptado para o serviço configurado.

A automatização de certificados também tem um ciclo de vida. A Let’s Encrypt aplica limites de emissão (https://letsencrypt.org/docs/rate-limits/) aos pedidos efetuados através do endpoint da API de novas encomendas. Use uma convenção de nomes controlada, valide o DNS antes da entrada em produção, evite pedir certificados repetidamente durante testes ad hoc e mantenha um procedimento claro para alterações de domínio.

A Airbip executa instâncias de aplicações como cargas de trabalho Docker em servidores cloud da Airbip e automatiza o encaminhamento e os certificados TLS através do Traefik e da Let’s Encrypt. Também disponibiliza verificações de DNS, gestão do ciclo de vida dos serviços, cópias de segurança diárias, semanais e mensais configuráveis, e a escolha entre um subdomínio da Airbip ou um domínio personalizado compatível. Estas capacidades da plataforma podem reduzir o trabalho repetitivo de infraestrutura, mas os clientes continuam a ter de definir titularidade, acesso, tratamento de dados, âmbito de cópias de segurança, procedimentos de restauro e o modelo de separação adequado.

• Mantenha um registo de instâncias: organização, proprietário, finalidade, domínio, administradores, serviços ligados, classificação dos dados e data de saída, quando aplicável.
• Utilize uma convenção de domínio previsível e verifique a titularidade do encaminhamento antes do lançamento.
• Acompanhe versões da aplicação, alterações de configuração e requisitos de aprovação por instância.
• Defina contactos de monitorização e resposta a incidentes para cada instância; não presuma que uma equipa central conhece o contexto relevante de cada cliente.
• Agende testes de cópia de segurança e restauro no âmbito prometido à organização.
• Planeie o trabalho de migração antes de adotar instâncias separadas, incluindo como os dados são transferidos, como o acesso é comutado e como os dados originais são retidos ou eliminados.