Compare obrigações operacionais em vez de rótulos de implantação
Auto-hospedado e SaaS descrevem modelos de entrega, não resultados completos de segurança ou confiabilidade. Uma plataforma de autenticação auto-hospedada pode dar a uma organização mais controle sobre a infraestrutura e, ao mesmo tempo, adicionar obrigações de manutenção. Um serviço SaaS pode transferir partes dessa manutenção para um fornecedor, deixando a configuração do cliente, o acesso e as decisões de dados com a organização. A comparação útil é uma matriz de responsabilidade baseada em evidências para o serviço real, e não uma afirmação de que um rótulo é sempre mais seguro.
Orientação de responsabilidade compartilhada da Microsoft ilustra como as responsabilidades mudam nos modelos locais, IaaS, PaaS e SaaS. Também identifica as responsabilidades que os clientes mantêm. Esta fonte descreve a estrutura de nuvem da Microsoft; não é uma alocação contratual para EmailAuth ou prova de que EmailAuth oferece um produto auto-hospedado. Este manuscrito propõe um método de comparação sem implantação de software ou acesso à infraestrutura.
Defina o que realmente está incluído em cada opção
Registre a edição do produto compatível, o modelo de implantação, o limite do ambiente, o provedor de infraestrutura e a assistência do fornecedor descritos na documentação atual ou em uma oferta aprovada. “Auto-hospedado” pode significar software operado em hardware próprio ou em infraestrutura em nuvem; esses acordos podem alocar responsabilidades físicas, de sistema operacional e de aplicativos de maneira diferente. “Privado” pode referir-se à conectividade de rede, recursos dedicados ou um acordo contratual. Nenhum destes termos deve substituir uma arquitetura concreta e uma fronteira de suporte.
Pergunte quais componentes existem e quem os opera: tempo de execução de aplicativos, armazenamentos de dados, filas, ingestão de relatórios, autenticação, backups, monitoramento e interfaces administrativas. Trate esta lista como perguntas, não como uma afirmação de que a plataforma usa esses componentes. Se o fornecedor não puder fornecer evidências para uma opção de implantação reivindicada, marque a opção como não verificada em vez de preencher uma arquitetura da documentação de um produto diferente.
Atribuir manutenção e alterar propriedade
Para cada componente suportado, identifique quem corrige, quem aprova as alterações, quem agenda a manutenção e quem verifica a recuperação. Um fornecedor pode publicar atualizações enquanto o cliente deve instalá-las. Um serviço gerenciado pode aplicar atualizações enquanto o cliente deve avaliar as alterações nas integrações ou na política de acesso. A responsabilidade pela distribuição de uma correção não é a mesma que a responsabilidade pela confirmação de que o fluxo de trabalho real do cliente ainda funciona posteriormente.
A estrutura da Microsoft distingue a infraestrutura de nuvem subjacente dos dados, identidades e configurações dos clientes. Aplique essa distinção à comparação sem copiar a sua matriz como um contrato universal. O fornecedor real deve indicar as suas responsabilidades e exclusões. O cliente deve identificar um proprietário interno nomeado para as obrigações retidas, em vez de atribuí-las vagamente à “TI”. As responsabilidades não reconhecidas constituem uma lacuna, mesmo quando o modelo de implantação é adequado.
Mapeie dependências externas explicitamente
Uma operação de autenticação pode depender de hospedagem DNS , provedores de envio, sistemas de identidade, fontes de relatórios e monitoramento externo. Mover a plataforma não transfere automaticamente o controle dessas dependências. Um aplicativo auto-hospedado não pode alterar o comportamento de envio de um fornecedor sem a autoridade relevante, e um painel SaaS não pode garantir que cada destinatário forneça relatórios. Registre o proprietário da dependência, a interface suportada, o modo de falha e as evidências usadas para verificar seu estado.
RFC 9990 define DMARC relatórios agregados como um processo de relatório distinto. A sua disponibilidade e cobertura não devem ser inferidas apenas pelo tempo de atividade da plataforma. RFC 9989 define relacionamentos de autenticação de domínio, que também dependem da configuração de envio real. A matriz operacional deve separar a disponibilidade da plataforma da integridade das observações e da correção da autenticação do remetente.
Avalie o acesso e as responsabilidades do locatário
Diretrizes de identidade multilocatário do Azure distingue identidade, autorização e direitos. Uma comparação de implantação deve perguntar quem configura a confiança do provedor de identidade, funções de usuário, identidades de serviço, ligações de locatário e permissões de exportação. Uma implantação dedicada não significa automaticamente que todos os usuários dentro dela devam acessar todos os dados. Um serviço compartilhado não implica automaticamente que os dados do cliente sejam expostos entre locatários.
Exigir provas reais dos controlos e limites administrativos suportados. Registre o acesso ao suporte do fornecedor, o acesso de emergência e as responsabilidades de auditoria, quando aplicável. Não presuma que a propriedade da infraestrutura pelo cliente elimine o acesso do fornecedor ou que a propriedade do SaaS elimine o papel do cliente na remoção de usuários. Nenhuma permissão, conta ou configuração de segurança foi alterada para este artigo; estas são perguntas para revisão autorizada.
Compare evidências de recuperação e capacidade operacional
Pergunte quais obrigações de backup, restauração e recuperação de desastres cada opção atribui, quais componentes são cobertos e quais evidências demonstram a recuperação. Uma configuração de backup não é um teste de restauração bem-sucedido. Uma declaração de disponibilidade do fornecedor não é prova de que os dados e integrações de um cliente individual possam ser recuperados dentro dos requisitos do comprador. Registre os compromissos suportados reais e o trabalho de verificação restante do cliente sem inventar tempos de recuperação.
Estime a carga de trabalho apenas a partir de insumos organizacionais aprovados. Inclua manutenção do sistema operacional ou do tempo de execução, quando retido, atualizações de aplicativos, resposta a incidentes, revisão de acesso, suporte à integração e exercícios de recuperação. Não presuma que a auto-hospedagem é mais barata porque as taxas de assinatura são diferentes, ou que o SaaS é mais barato porque o trabalho de infraestrutura é menos visível. Este rascunho não calcula necessidade de pessoal, custo total ou economia. Fornece categorias para uma comparação transparente.
Uma planilha de responsabilidade operacional
Crie uma linha por obrigação com componente, dependência, proprietário do cliente, proprietário do fornecedor, parte de execução, parte de aprovação, referência de evidência, gatilho de revisão e lacuna não resolvida. Distinguir a responsabilidade pela execução de uma tarefa da responsabilidade pelo seu resultado. Adicione a versão de implantação suportada e a referência do contrato para que a alocação possa ser revisada quando alguma delas for alterada. Mantenha credenciais e detalhes arquitetônicos confidenciais fora de cópias amplamente compartilhadas.
A secção de decisão deve identificar lacunas inaceitáveis, controlos compensatórios aprovados e dependências que exijam mais provas. Uma linha marcada como compartilhada deve nomear a transferência: o que cada parte faz, qual sinal aciona a próxima etapa e quem verifica a conclusão. “Compartilhado” sem uma transferência definida pode ocultar o limite de falha mais importante. Esta planilha proposta não foi preenchida com um contrato de fornecedor ou ambiente operacional real.
Diagnóstico fictício: atualizações sem proprietário da instalação
Uma equipe fictícia compara um serviço gerenciado com uma opção auto-hospedada. O fornecedor auto-hospedado promete fornecer atualizações de segurança e o comprador inicialmente trata os patches como propriedade do fornecedor. A análise detalhada revela que o fornecedor distribui os pacotes enquanto o cliente deve agendar a instalação, avaliar a compatibilidade e verificar o serviço resultante. Nenhuma equipe interna aceitou esse trabalho.
A resposta proposta é designar um proprietário autorizado e avaliar a capacidade antes de selecionar a opção, ou escolher um acordo apoiado com uma atribuição de responsabilidade diferente. A equipe não deve declarar o produto inseguro apenas porque existe a obrigação. Este cenário é fictício e não descreve as ofertas do EmailAuth , um patch real perdido ou uma implantação realizada durante este trabalho.
Tome a decisão com as lacunas visíveis
Uma comparação defensável explica quais obrigações são movidas, quais permanecem e quais dependências permanecem inalteradas. Não trata o controle como prova de competência ou a terceirização como prova de cobertura completa. O modelo preferido depende das opções de produtos suportados, da capacidade organizacional, dos controles necessários e dos compromissos verificados dos fornecedores.
O catálogo requer uma matriz de responsabilidade operacional e dependência baseada em evidências. Esse artefato original permanece aberto. A revisão de especialistas humanos, a aplicabilidade da fonte, as rotas de produção, a acessibilidade e a liberação do proprietário também permanecem em aberto. Este rascunho fornece uma estrutura e um exercício fictício, não uma arquitetura implementada ou um acordo de responsabilidade aprovado. A publicação exige evidências atuais das opções reais que estão sendo comparadas e uma propriedade claramente atribuída para o trabalho retido.