# Um modelo de ameaças prático para seu projeto hospedado | SwissOctet Insights https://swissoctet.com/pt-br/insights/threat-model-a-hosted-project/ SwissOctet / Insights / Operações do dia dois Operações do dia dois Aplicado · 6 min de leitura Um modelo de ameaça prático para o seu projeto hospedado Mapeie ativos e limites de confiança, escolha alguns cenários de falha realistas e transforme-os em controles que você possa testar. Por SwissOctet Editorial Salvar guia Copiar link NESTA PÁGINA 01 Defina um escopo pequeno o suficiente para raciocinar sobre ele 02 Desenhe os pontos onde a confiança muda 03 Escolha cenários de falha concretos 04 Priorize por impacto e um caminho crível 05 Teste os controles em um ambiente autorizado 06 Mantenha o modelo conectado à mudança Sua lista prática Fontes e leitura adicional Voltar para a biblioteca A RESPOSTA DIRETA Um modelo de ameaças útil explica o que você protege, quem ou o que pode afetá-lo, onde a confiança muda e como você reduzirá e testará os riscos mais importantes. Comece com o projeto real, em vez de uma lista genérica de ferramentas. 01 Defina um escopo pequeno o suficiente para raciocinar sobre ele Comece com um serviço em funcionamento: um portal de clientes, um site de publicação ou uma aplicação interna. Anote os componentes que você opera e os sistemas externos dos quais depende. Um modelo de ameaças deve tornar as suposições visíveis, não sugerir que todo ataque possível foi resolvido. Mantenha a primeira versão pequena o suficiente para que as pessoas que implantam a aplicação possam explicá-la sem um consultor separado interpretando o diagrama. Liste os resultados e ativos valiosos. Eles podem incluir dados de clientes, acesso administrativo, estado de pagamento, conteúdo publicado e a capacidade de restaurar o serviço. A disponibilidade pode ser um ativo mesmo quando a informação é pública. Decida quais falhas seriam inconvenientes e quais prejudicariam pessoas ou a organização. Essa distinção ajuda a priorizar controles em vez de tratar todo alerta igualmente. 02 Desenhe os pontos onde a confiança muda A orientação de modelagem de ameaças da OWASP usa fluxos de dados e limites de confiança para tornar um design compreensível. Para uma pequena aplicação hospedada, desenhe o navegador, o processo web, o banco de dados, o administrador, o destino de backup e as integrações externas. Marque as informações que se movem entre eles. Uma requisição que cruza de um cliente não confiável para uma operação privilegiada do servidor merece validação e autorização explícitas. Não presuma que estar dentro da mesma máquina torna todos os componentes igualmente confiáveis. Um processo de upload público não deve ter as mesmas permissões que a administração do banco de dados. Um trabalho de backup pode precisar de acesso de leitura sem a capacidade de modificar registros ativos da aplicação. Separar esses papéis torna o efeito de um componente comprometido mais fácil de conter e as permissões necessárias mais fáceis de revisar. 03 Escolha cenários de falha concretos Use alguns eventos plausíveis para desafiar o design. Um atacante rouba uma senha de administrador; um usuário solicita o registro de outro usuário; um upload esgota o disco; uma implantação expõe um arquivo de configuração; uma cópia de recuperação não pode ser restaurada. Descreva a condição inicial, o componente afetado e a consequência. Um cenário específico é mais fácil de testar do que uma instrução ampla de melhorar a segurança. Inclua erros e abuso legítimo de fluxo de trabalho, bem como intrusão externa. Uma nova tentativa pode criar duas operações valiosas, ou duas requisições podem competir para alterar o mesmo objeto. A orientação de lógica de negócios da OWASP destaca essas suposições de processo. Verifique quem tem permissão para mover um fluxo de trabalho para seu próximo estado e se repetir ou reordenar uma requisição altera o resultado inesperadamente. Cenário Controle a investigar Evidência a coletar Credencial de administração roubada Acesso restrito e um segundo fator quando suportado Um login não autorizado não pode ser concluído Objeto de outro usuário solicitado Autorização de objeto no lado do servidor Um teste isolado retorna um resultado negado Disco esgotado por uploads Controles de tamanho, cota e retenção Um limite é aplicado antes da falha do serviço Requisição duplicada de fluxo de trabalho Idempotência e limites de transação Uma requisição repetida cria um único resultado 04 Priorize por impacto e um caminho crível Para cada cenário, registre seu impacto potencial e as condições necessárias para que ocorra. Evite fingir que uma pontuação numérica estimada é uma probabilidade precisa. Você ainda pode distinguir uma senha fraca exposta à internet de um evento local altamente condicional. Atribua um responsável e um próximo passo prático aos riscos importantes, para que o modelo crie trabalho que alguém possa realmente concluir. Considere o ciclo de vida da informação, bem como o comprometimento da aplicação. Uma exportação de diagnóstico pode divulgar dados desnecessários durante uma operação normal. Um campo de conta retido pode criar exposição muito depois de sua finalidade terminar. A revisão de privacidade pode, portanto, remover informações ou encurtar a retenção, enquanto a revisão de segurança restringe o acesso ao que permanece. Ambas as mudanças pertencem ao modelo quando protegem o projeto. 05 Teste os controles em um ambiente autorizado Crie um ambiente de homologação com permissões representativas e registros fictícios. Teste acesso negado, limites de requisição, novas tentativas de fluxo de trabalho e recuperação. Não use dados reais de clientes quando dados sintéticos puderem demonstrar o comportamento. O objetivo é verificar o controle, não gerar tráfego de ataque impressionante. Mantenha-se dentro de sistemas que você possui ou está explicitamente autorizado a avaliar. Registre o que passou, o que falhou e o que permanece desconhecido. O resultado de um scanner pode contribuir como evidência, mas não substitui um teste das regras de negócio da aplicação. Da mesma forma, uma opção de proteção de rede não verifica a autorização de objetos nem o tratamento de arquivos secretos. Anexe os resultados úteis ao cenário para que futuros mantenedores entendam por que um determinado controle existe. 06 Mantenha o modelo conectado à mudança Revise as partes relevantes quando você adicionar uma integração, expuser um novo endpoint, alterar um privilégio ou mover dados para outro destino. Você não precisa redesenhar toda a arquitetura para uma pequena edição de texto. O gatilho é uma suposição alterada sobre acesso, informação ou comportamento do sistema. Mantenha o modelo junto à documentação de implantação e recuperação, em vez de deixá-lo como resultado de um workshop pontual. SwissOctet fornece um catálogo de escolhas de infraestrutura, não um modelo de ameaças de aplicação concluído. Escolha a configuração e as opções que apoiam seus controles e, em seguida, verifique a implantação que você construir. Um modelo pequeno e mantido, com ações testadas, é mais útil do que uma grande coleção de produtos de segurança sem uma explicação clara dos riscos que eles abordam. TRANSFORME ISSO EM AÇÃO Sua lista prática. ✓ Liste os ativos e as consequências da falha. ✓ Desenhe os fluxos de dados e os limites de confiança. ✓ Escolha cenários específicos de intrusão, erro e fluxo de trabalho. ✓ Atribua controles e responsáveis aos riscos importantes. ✓ Teste com dados sintéticos em um ambiente autorizado. ✓ Revise o modelo quando uma suposição relevante mudar. Baixar lista PERGUNTAS COMUNS Os detalhes que importam. Preciso de um framework formal para começar? + Não. Um pequeno diagrama e um conjunto documentado de cenários podem ser úteis. Um framework ajuda a garantir que você revise os riscos de forma consistente. Um scanner de vulnerabilidades substitui a modelagem de ameaças? + Não. Os scanners podem encontrar fraquezas técnicas, enquanto um modelo de ameaças também examina suposições de design, permissões e fluxos de trabalho de negócio. Com que frequência devo atualizar o modelo? + Atualize as partes afetadas quando fluxos de dados, integrações, privilégios ou funcionalidades expostas mudarem, e revise os riscos não resolvidos regularmente. REFERÊNCIAS PRINCIPAIS Vá à fonte. Estas referências apoiam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema em produção. OWASP: Folha de referência de modelagem de ameaças cheatsheetseries.owasp.org OWASP: Modelagem de ameaças na prática devguide.owasp.org OWASP: Segurança de lógica de negócio cheatsheetseries.owasp.org Orientação editorial da SwissOctet. Os exemplos são ilustrativos. Especificações de serviço, opções disponíveis e condições contratuais devem ser verificadas separadamente. CONECTE O CONHECIMENTO Infraestrutura relacionada. Vector VPS Suíça Metal Atlas Suíça Canvas Web Suíça MANTENHA O FIO Suas próximas notas de campo. Explore todos os guias NOTA DE CAMPO / 01 + Operações do dia dois Aplicado Construa um backup que você realmente possa restaurar Escolha um alvo de recuperação, proteja uma cópia independente e pratique a restauração antes que um incidente force a questão. 4 min de leitura Leia o guia NOTA DE CAMPO / 02 + Operações do dia dois Aplicado Administração segura do Windows RDP sem perder o acesso Separe a alcançabilidade de rede, a autenticação e o privilégio, depois verifique uma rota de recuperação antes de restringir o acesso remoto. 6 min de leitura Leia o guia NOTA DE CAMPO / 03 + Operações do dia dois Aplicado Uma linha de base de hardening do Linux VPS que você pode manter Administre com segurança, exponha apenas os serviços necessários e estabeleça atualizações e recuperação sem se bloquear. 6 min de leitura Leia o guia