Entenda Self-Hosting corporativo: infraestrutura própria ou em cloud, redes, Docker, segurança, backup, custos, operação e critérios para escolher entre SaaS e hospedagem própria.
Confira!
Self-Hosting é a prática de hospedar e administrar aplicações, dados e serviços sob controle técnico da própria organização ou de sua equipe, em infraestrutura local, dedicada ou virtual contratada. Diferentemente de um serviço SaaS integralmente gerenciado, a responsabilidade por instalação, atualização, segurança, disponibilidade e recuperação passa a ser assumida em maior grau por quem opera a plataforma. Self-Hosting não significa obrigatoriamente manter servidores dentro da empresa: uma máquina virtual contratada em um Data Center também pode executar serviços autogerenciados.
Para uso corporativo, a decisão envolve mais que autonomia tecnológica. É necessário verificar custos, riscos cibernéticos, requisitos legais e contratuais, maturidade da equipe, capacidade de suporte e proteção dos dados. O modelo pode ser vantajoso para aplicações que exigem controle, integração ou customização, mas tende a ser inadequado quando a operação não dispõe de processos para monitoramento, patching, backup e recuperação.
O que é Self-Hosting e como se diferencia de SaaS e cloud
O conceito descreve um modelo de responsabilidade operacional, e não um local físico específico. A empresa pode executar uma wiki corporativa em um servidor interno, hospedar uma aplicação em máquina virtual de um provedor ou implantar um serviço de arquivos em infraestrutura de colocation. Se a equipe da empresa mantém o software, aplica atualizações, controla os acessos e responde pelo funcionamento, a operação se enquadra no modelo autogerenciado.
No SaaS, por sua vez, o provedor costuma administrar a aplicação e parte relevante de sua infraestrutura. A organização cliente permanece responsável por usuários, classificação dos dados, contratos, configurações e decisões de uso. É incorreto tratar o self-hosting como alternativa automaticamente mais privada ou segura. O resultado depende da arquitetura, dos controles e da competência de cada parte.
Um servidor alugado não fornece continuidade automaticamente. O provedor pode garantir energia, conectividade ou disponibilidade da máquina física, sem responder pela integridade do banco instalado pelo cliente. Da mesma forma, uma solução em rede interna pode sofrer indisponibilidade, ransomware, erro humano ou falha de hardware mesmo sem conexão direta à internet.
| Modelo | Infraestrutura | Administração da aplicação | Verificações principais |
| SaaS | Em geral do fornecedor | Predominantemente do fornecedor | Contrato, integração, dados e saída |
| IaaS autogerenciado | Provedor cloud | Equipe contratante | SO, backup, rede e segurança |
| On-premises | Organização | Organização ou contratado | Energia, hardware, suporte e recuperação |
| Colocation | Hardware próprio em instalação de terceiros | Conforme contrato | Matriz de responsabilidade e SLA |
| Managed hosting | Provedor ou contratado | Compartilhada | Escopo exato do gerenciamento |
A estratégia precisa ser definida serviço a serviço. Aplicações com grande dependência de integração local ou requisitos específicos de customização podem justificar gestão direta. Sistemas commoditizados, como algumas funções de colaboração corporativa, podem apresentar melhor custo e disponibilidade quando fornecidos por terceiros especializados.
Arquitetura de um ambiente Self-Hosted
Uma instalação corporativa deve separar camadas de acesso, aplicação e dados. O usuário chega por conexão autorizada; um reverse proxy ou outro componente de entrada aplica políticas de TLS e encaminhamento; serviços de aplicação processam requisições; bancos ou volumes persistentes preservam informações. Gestão de identidade, registros de auditoria, monitoração e backup envolvem todas as camadas.
A topologia pode utilizar máquinas virtuais, containers ou uma combinação. A opção deve refletir a arquitetura da aplicação e as competências de administração. Em uma implantação pequena, uma VM com serviços bem segregados pode ser suficiente. Em ambientes que exigem atualizações frequentes e múltiplos componentes, uma configuração declarativa com containers ajuda a manter consistência, mas não substitui governança.
O diagrama é conceitual: componentes podem residir em uma única instalação ou em múltiplos servidores. Não se recomenda interpretar o desenho como autorização para expor bancos de dados ou painéis administrativos à internet. A publicação de serviços deve considerar segmentação, autenticação, requisitos de disponibilidade e caminhos seguros de administração.
Na documentação técnica, registre endereços de serviço, nomes DNS, portas, dependências, autoridade certificadora, forma de renovação dos certificados, administração de secrets, recursos de CPU e memória, storage, política de atualização e critérios de recuperação. O conjunto forma uma base que permite manter a solução após mudanças de equipe ou fornecedor.
Um aspecto frequentemente negligenciado é o acoplamento. Uma aplicação pode depender de e-mail para redefinir senhas, provedor externo de identidade, armazenamento de objetos ou API de pagamentos. Se esses serviços falharem, a instalação local poderá estar funcionando e ainda assim ser incapaz de atender usuários. A matriz de dependências precisa registrar esses riscos.
Quando utilizar Self-Hosting em empresas
O benefício potencial mais evidente é o controle sobre configuração e ciclo de vida do software. Isso pode ser útil para sistemas com integrações específicas, componentes de engenharia, plataformas de gerenciamento documental ou aplicações que processam informações internas sob regras de retenção e acesso próprias. Também pode facilitar customizações que não seriam oferecidas por um SaaS padronizado.
Outra motivação é reduzir dependência de determinado fornecedor. Contudo, trocar lock-in comercial por dependência de administrador, infraestrutura ou comunidade de software não elimina risco. A portabilidade deve ser testada por exportação, documentação de dados, uso de formatos conhecidos e capacidade de reconstruir o serviço em outro ambiente.
Os custos são condicionais. Em uma aplicação estável com muitos usuários e licenciamento SaaS crescente, o self-hosting pode se tornar financeiramente atrativo. Já uma instalação pequena pode custar mais quando se somam patches, monitoramento, energia, suporte, backup, alta disponibilidade e resposta a incidentes. O cálculo deve considerar o TCO de todo o ciclo de vida.
| Situação | Potencial de Self-Hosting | Principal condição |
| Wiki interna e documentação técnica | Alto em alguns cenários | Controle de identidade e backup |
| Ferramentas internas de desenvolvimento | Variável | Segurança de repositórios e suporte |
| Armazenamento de documentos | Variável | Integridade, capacidade e retenção |
| E-mail corporativo público | Exige avaliação rigorosa | Entregabilidade, segurança e abuso |
| Gestão de senhas ou identidades | Crítico | Disponibilidade e proteção de secrets |
| Sistemas com integração OT | Dependente do projeto | Segmentação e continuidade |
Uma boa decisão começa pela classificação da informação, criticidade do serviço e condições de suporte. Se não há equipe para responder a vulnerabilidades e incidentes fora do horário comercial, a promessa de autonomia pode ocultar risco operacional. O desenho deve priorizar sistemas para os quais exista capacidade real de administração.
Para aplicações expostas publicamente, avalie reputação de domínio, proteção contra ataques, limitações de banda, políticas de firewall, atualização de dependências e existência de suporte. Para aplicações internas, ainda são necessários mecanismos de autenticação, segmentação, log e backup: a ausência de exposição direta não equivale à ausência de ameaça.
Servidores, virtualização e containers: critérios de infraestrutura
A arquitetura depende da carga de trabalho. Aplicações que exigem sistema operacional específico ou determinadas integrações podem executar em máquinas virtuais; serviços modulares podem utilizar containers. Em instalações menores, Docker e configurações declarativas com Compose ajudam a definir redes, volumes, variáveis e serviços de forma reproduzível.
O container não é backup da aplicação. A imagem permite reconstruir executáveis, mas os dados persistentes precisam de volumes ou serviços externos e procedimentos próprios de proteção. Em ambientes Linux, controles de privilégios e recursos exigem avaliação específica. Containers executados com acesso administrativo indevido ao host podem comprometer a segregação esperada.
O conteúdo sobre Virtualização e Containers compara requisitos de isolamento, operação e custo. A escolha não deve pressupor que containers sempre consomem menos energia ou que VMs sempre entregam maior segurança; o desempenho e o modelo de ameaça devem ser verificados no ambiente real.
O dimensionamento inclui picos de CPU, RAM, espaço de dados, IOPS, throughput, tráfego simultâneo, crescimento, backup e espaço livre para atualizações. Uma aplicação que utiliza poucos recursos em laboratório pode depender de cache, consultas ao banco ou processamento de arquivos que crescem com a demanda. O projeto deve prever margem de capacidade e critérios objetivos para expansão.
A alta disponibilidade não surge pela simples existência de múltiplas VMs ou containers. Se todos dependem do mesmo storage, switch ou servidor de identidade, há um componente único de falha. Topologias redundantes exigem análise de domínios de falha, política de replicação, comportamento de failover e testes de recuperação.
Redes, DNS, acesso remoto e certificados
A conectividade é parte central do self-hosting. Em uma instalação residencial ou pequena empresa, limitações de endereço IP, CGNAT, upload, disponibilidade de conexão e políticas do provedor podem inviabilizar a publicação direta de serviços. Em ambientes corporativos, enlaces dedicados, balanceamento e políticas formais podem atender melhor à necessidade, mas exigem projeto.
Para serviços externos, a arquitetura deve definir DNS, TLS, controle de entrada e saída, reverse proxy, registros de acesso e procedimentos de renovação de certificados. Certificados válidos protegem a comunicação, mas não resolvem autenticação fraca, vulnerabilidades da aplicação, configurações inseguras ou exposição inadequada de administração.
Painéis de gestão, SSH, banco de dados e interfaces de orquestração não devem ser publicados indiscriminadamente. Sempre que possível, isole a administração por acesso privado com autenticação forte e menor privilégio. A política de acesso remoto precisa registrar quem pode se conectar, de onde, por qual mecanismo e como serão auditadas as sessões.
Também é necessário tratar dependências de rede de saída. A aplicação pode precisar de APIs, atualizações de sistema, serviços de hora, DNS e notificações por e-mail. Bloquear indiscriminadamente todo tráfego externo pode afetar funções legítimas, enquanto permitir saída irrestrita aumenta exposição. A matriz de portas deve representar necessidades reais e ser revisada periodicamente.
O artigo sobre portas TCP e UDP complementa a especificação dos fluxos. Projetos que integram zonas de TI e OT devem respeitar segmentação e DMZ, evitando transformar a hospedagem local em ponte não controlada entre sistemas.
Segurança, hardening e gestão de identidade
Assumir o serviço implica assumir a gestão de vulnerabilidades. O processo inclui manter inventário de ativos, identificar versões, acompanhar avisos de segurança, aplicar patches, revisar permissões e verificar configurações após mudanças. Atualizações precisam ser testadas e possuir plano de reversão, especialmente quando modificam bancos de dados ou dependências críticas.
A autenticação deve utilizar identidade individual e, quando compatível, multifactor authentication. Contas administrativas precisam ter escopo reduzido e ser distintas das contas de uso cotidiano. Credenciais, tokens de API e certificados devem ser armazenados em mecanismos adequados, com rotação e trilha de auditoria. Compartilhar a mesma senha de administrador entre aplicações elimina parte da rastreabilidade.
Na proteção do host, controle serviços ativos, usuários, firewall, logs, permissões de arquivos, execução de processos e mecanismos de isolamento. Em ambientes de containers, avalie rootless mode ou outras medidas de redução de privilégios quando apropriadas, reconhecendo suas limitações técnicas. Uma imagem de fonte desconhecida ou um volume de host montado com permissões excessivas pode introduzir riscos substanciais.
A equipe deve possuir procedimento de resposta a incidentes: como isolar o serviço, preservar evidências, revogar credenciais, restaurar dados e comunicar responsáveis. O projeto também precisa considerar períodos de indisponibilidade por manutenção e falta de profissionais. Uma tecnologia segura na instalação pode se tornar vulnerável após meses sem atualização.
| Controle | Evidência mínima | Falha a evitar |
| MFA e contas nominais | Políticas e teste de login | Administrador compartilhado |
| Patching | Inventário e histórico de atualização | Software sem suporte |
| Firewall e segmentação | Matriz de comunicação testada | Portas administrativas públicas |
| Gestão de secrets | Rotação e controle de leitura | Segredos em repositórios |
| Auditoria | Logs protegidos e retenção | Ausência de rastreabilidade |
| Backup independente | Restore testado | Cópias no mesmo domínio de falha |
Self-hosting não equivale a soberania de dados de maneira automática. É preciso verificar onde os dados são armazenados, onde backups permanecem, quais integrações externas processam informações e quais pessoas possuem acesso administrativo. A avaliação de riscos e obrigações aplicáveis deve ser específica a cada sistema e contrato.
Dados persistentes, backup e disaster recovery
A proteção dos dados é um dos maiores desafios. Um serviço pode ser reconstruído rapidamente a partir de um container versionado, mas essa reconstrução será inútil se volumes de documentos, arquivos de configuração ou bancos transacionais tiverem sido perdidos. O desenho de persistência precisa separar dados efêmeros, dados de negócio, configurações, secrets e registros necessários à operação.
Volumes de containers preservam arquivos independentemente do ciclo de vida das instâncias, mas não são backups. Em bancos de dados, copiar arquivos em momento inadequado pode produzir conteúdo inconsistente. O procedimento deve utilizar mecanismos de backup compatíveis com o banco, realizar testes de restauração e definir como os dados restaurados serão validados.
A regra de múltiplas cópias em domínios diferentes pode reduzir riscos, desde que considere proteção contra exclusão, ransomware, credenciais comprometidas e falha de localidade. Uma cópia conectada permanentemente ao mesmo host pode ser comprometida juntamente com a origem. Cópias imutáveis, offline ou segregadas são opções a avaliar conforme criticidade e orçamento.
RPO representa a perda máxima tolerável de dados ao longo do tempo; RTO representa a duração máxima aceitável para recuperação do serviço. Esses objetivos devem derivar do negócio e ser medidos em ensaios. Se a instalação precisa recuperar em minutos, uma cópia diária e restauração manual de várias horas não são coerentes com o requisito.
| Elemento | Pergunta de projeto | Teste de aceite |
| Backup de banco | Há consistência transacional? | Restore em ambiente isolado |
| Arquivos do usuário | Qual versão e retenção? | Recuperação de arquivos excluídos |
| Configuração | O serviço pode ser reconstruído? | Reimplantação documentada |
| Secrets e certificados | Como restaurar com segurança? | Recuperação com acesso controlado |
| Continuidade | RTO/RPO são atendidos? | Simulação com tempo medido |
O Backup e Disaster Recovery deve ser tratado como parte do serviço contratado ou operado. Nenhuma arquitetura deve ser aprovada apenas porque uma tarefa automática registra “backup concluído”; a evidência relevante é a capacidade de restauração íntegra dentro do tempo exigido.
Operação, observabilidade e manutenção
Um ambiente Self-Hosted precisa de rotinas de operação previstas desde o projeto. As equipes devem monitorar uptime, taxa de erros, latência, espaço disponível, CPU, memória, uso de conexões, logs e status de backups. Alarmes sem responsáveis ou procedimentos geram notificações, mas não asseguram correção de incidentes.
Os indicadores devem ser avaliados por aplicação. Um servidor ativo pode sustentar uma aplicação indisponível por erro de banco ou certificado expirado. Portanto, os testes de saúde devem incluir funções representativas e dependências relevantes. O uso de synthetic monitoring, transações de teste e alertas por serviço oferece visão mais próxima da experiência do usuário.
Atualizações demandam janela, avaliação de impacto e rollback. Uma mudança de major version pode alterar schema do banco, formatos de configuração ou APIs. Antes da atualização, a equipe deve verificar changelog, compatibilidade, backup e possibilidade de retorno. Atualizar a imagem e depender exclusivamente de reinicialização automática é insuficiente para operações críticas.
A manutenção também envolve capacidade. Avalie evolução de storage, crescimento de logs, retenção de arquivos, desgaste de hardware e desempenho do sistema. Quando o uso se aproxima de limites críticos, a resposta deve ser planejada. Esperar o disco ficar cheio pode gerar indisponibilidade e corrupção de dados.
Uma rotina trimestral ou outra periodicidade definida pelo risco pode revisar inventário, patches, usuários, certificados, backups e capacidade. O objetivo é manter um ciclo verificável de melhoria. Sem registros, a operação passa a depender de memória individual e intervenções reativas.
Self-Hosting com Docker Compose e quando considerar Kubernetes
Em muitas aplicações, um conjunto de serviços pode ser descrito em um arquivo Compose: frontend, API, banco, volumes, redes internas e healthchecks. A declaração permite reconstruir componentes com menos divergência entre ambientes, desde que imagens, configurações e secrets sejam tratados corretamente. A automação da instalação não substitui atualização de software nem recuperação de dados.
Compose funciona bem quando a quantidade de hosts, o perfil de disponibilidade e as características da aplicação permitem administração relativamente simples. Quando surge necessidade de múltiplos nós, distribuição de réplicas, políticas centralizadas e mudanças frequentes entre equipes, pode fazer sentido avaliar uma plataforma de orquestração. A decisão exige estudo de complexidade e maturidade.
O artigo Kubernetes: arquitetura, Pods, segurança e operação aprofunda a operação de clusters. Adotá-lo para uma wiki ou ferramenta de poucos usuários, sem requisitos adicionais, pode aumentar a superfície operacional e o custo sem melhorar de maneira proporcional o nível de serviço.
O controle por Git de arquivos de configuração contribui para rastreabilidade, mas não deve expor tokens ou senhas. Recomenda-se parametrizar ambientes e integrar repositórios com processo de revisão. O resultado deve ser uma implantação reproduzível, com documentação de dependências e procedimentos de rollback, e não um conjunto de comandos conhecidos apenas por um administrador.
Uma arquitetura com containers pode incluir banco fora dos containers ou serviço gerenciado, conforme requisitos. É importante decidir explicitamente os limites entre aplicação, infraestrutura e dados. A facilidade de reiniciar uma instância não deve ser confundida com disponibilidade do sistema integral.
Custos: licenciamento, TCO, suporte e capacidade de equipe
O custo de self-hosting inclui servidores ou VMs, discos, rede, energia, backup, segurança, monitoramento, suporte, licenças e manutenção de software. Em infraestrutura local, também são relevantes UPS, climatização, espaço físico, contratos de reposição e renovação de equipamentos. Em cloud, considere tráfego de saída, snapshots, volumes, endereços públicos, ferramentas e variações de consumo.
Uma comparação com SaaS precisa utilizar requisitos equivalentes. Um serviço gerenciado pode incluir suporte, proteção operacional e alta disponibilidade que não estarão presentes em uma instalação autogerenciada básica. Comparar mensalidade SaaS com preço de uma VM pequena sem esses custos não produz TCO confiável.
O trabalho humano é decisivo. A organização precisa prever horas de atualização, análise de vulnerabilidades, gestão de contas, documentação, backup, troubleshooting e incident response. Um sistema instalado por uma única pessoa pode ter custo aparente baixo, mas risco elevado de continuidade caso essa pessoa não esteja disponível.
| Categoria | Self-Hosting | SaaS gerenciado |
| Infraestrutura | Contratada ou mantida diretamente | Em geral embutida no serviço |
| Patches da aplicação | Responsabilidade interna ou contratada | Predominantemente do fornecedor |
| Customização | Potencialmente ampla | Limitada ao produto e contrato |
| Backup de dados | Deve ser definido e comprovado | Verificar escopo e exportação |
| Suporte | Depende de equipe e contratos | Conforme SLA contratado |
| Custo previsível | Depende do modelo | Geralmente por assinatura e consumo |
Também é necessário planejar encerramento e migração. A possibilidade de exportar dados e reconstruir serviços em outro provedor reduz dependência de infraestrutura específica. A saída deve ser verificada com testes, documentação e validação de integridade, e não apenas constar como intenção contratual.
Exemplo aplicado: portal interno de documentação de engenharia
Considere uma empresa de engenharia que deseja manter documentação técnica, manuais de sistemas, procedimentos operacionais e materiais de apoio em uma plataforma interna. A aplicação deve oferecer autenticação corporativa, busca, controle de versões, trilha de acesso e backup independente. A decisão pelo self-hosting pode ser justificável quando existem integrações próprias e requisitos de retenção que não são atendidos adequadamente pelas opções contratadas.
No projeto, a equipe identifica informações restritas, perfis de acesso, integrações com identity provider e necessidades de pesquisa. O desenho estabelece aplicação, banco de dados, armazenamento de anexos, reverse proxy, backup e monitoramento, com políticas de tráfego e controle de credenciais. A infraestrutura pode ser virtualizada para aproveitar recursos existentes ou hospedada em ambiente cloud autogerenciado.
Durante a homologação, são testados login e revogação de usuários, pesquisa, upload e recuperação de arquivos, atualização da aplicação, perda temporária de conexão e restauração de banco. O aceite precisa comprovar que um documento é recuperável, que usuários sem autorização não conseguem acessá-lo e que a indisponibilidade não ultrapassa os limites definidos.
A equipe produz documentação as-built, inventário, matriz de acesso, políticas de atualização e registros de testes. Com isso, o serviço não depende exclusivamente do desenvolvedor que realizou a implantação. O caso ilustra que autonomia tecnológica exige engenharia de integração, governança, critérios de continuidade e entrega operacional consistente.
Erros mais comuns e como evitá-los
O primeiro erro é presumir que executar a aplicação em infraestrutura própria garante privacidade ou segurança. Sem controles, o ambiente pode ficar mais vulnerável do que uma plataforma gerenciada. Outro erro é utilizar o mesmo servidor como produção e único destino de backup, criando um domínio de falha compartilhado.
Também são recorrentes a exposição pública de interfaces administrativas, o uso de senhas compartilhadas, o atraso na aplicação de patches, volumes sem política de retenção e dependências externas não inventariadas. Em containers, uma imagem desatualizada pode reunir vulnerabilidades mesmo quando o host está em dia. Na operação, a falta de monitoramento impede detectar degradação antes da falha.
A estratégia de redução de risco envolve requisitos claros, hardening, segregação, inventário de serviços, autenticação forte, monitoramento e testes periódicos de backup. Em aplicações críticas, a arquitetura precisa prever componentes redundantes e equipes responsáveis por incidentes fora do horário normal.
Outra armadilha é iniciar com ferramentas excessivamente complexas. Um cluster distribuído requer conhecimentos e procedimentos próprios. A solução deve crescer por necessidade comprovada e manter documentação e capacidade de operação compatíveis com a complexidade introduzida.
Considerações finais
Self-Hosting é uma escolha de responsabilidade operacional. Pode ampliar controle sobre aplicações, integrações e dados, mas transfere à organização obrigações de segurança, atualização, suporte e continuidade que não podem ser ignoradas. O benefício depende da adequação entre requisitos técnicos, capacidade da equipe e risco assumido.
Uma implantação consistente estabelece arquitetura, identidades, rede, persistência, backup, observabilidade, manutenção e critérios verificáveis de aceite. Quando esses elementos estão definidos e testados, o self-hosting pode contribuir para autonomia tecnológica sem comprometer a confiabilidade dos serviços.
Referências técnicas
[1] Docker Inc.. Volumes — Docker Engine documentation. Disponível em: https://docs.docker.com/engine/storage/volumes/.
[2] Docker Inc.. Docker Compose: running multi-container applications. Disponível em: https://docs.docker.com/compose/.
[3] Docker Inc.. Rootless mode. Disponível em: https://docs.docker.com/engine/security/rootless/.
[4] NIST. Application Container Security Guide, SP 800-190. Disponível em: https://csrc.nist.gov/pubs/sp/800/190/final.
[5] CISA. Cybersecurity guidance for managed service providers and small and mid-sized businesses. Disponível em: https://www.cisa.gov/sites/default/files/publications/CISA%20Insights_Guidance-for-MSPs-and-Small-and-Mid-sized-Businesses_S508C.pdf.
Perguntas frequentes
É administrar aplicações e serviços sob responsabilidade técnica própria, em infraestrutura local, contratada ou virtual.
Não. Pode ser executado em servidores dedicados ou VMs contratadas, desde que a administração da aplicação seja autogerenciada.
Não necessariamente. Segurança depende de controles, manutenção, arquitetura e responsabilidade operacional.
On-premises indica localização da infraestrutura; Self-Hosting indica quem administra o serviço. Os conceitos podem coexistir.
Não. Aplicações podem executar diretamente no sistema operacional, em VMs ou em containers.
Não. Só se justifica quando escala e requisitos operacionais exigem orquestração mais complexa.
Não. Ele permite persistência dos dados, mas exige estratégia independente de proteção e restauração.
A exposição aumenta riscos; recomenda-se acesso restrito, autenticação forte, segmentação e registro das sessões.
Compare requisitos, classificação de dados, integração, suporte, disponibilidade, custos de ciclo de vida e maturidade da equipe.
RPO é a perda de dados tolerável no tempo; RTO é o tempo máximo desejado para recuperar o serviço.
Autenticação, TLS, DNS, firewall, dependências, backups, monitoramento, atualizações e plano de resposta a incidentes.
