Documentação do Mercado Livre

Confira todas as informações necessárias sobre as APIs Mercado Livre.
circulos azuis em degrade

Documentação do

Última atualização em 06/04/2026

Gestão de incidentes

A gestão de incidentes de segurança é o conjunto de processos, funções e ferramentas que permitem a uma organização detectar, responder e se recuperar de eventos que comprometam a segurança de seus sistemas ou dados. Não se trata apenas de reagir quando algo dá errado, mas de ter um plano estruturado que minimize o impacto, acelere a recuperação e converta cada incidente em uma oportunidade de melhoria.

Importante:
Sempre notifique o MercadoLibre pelo e-mail security@mercadolibre.com o mais rápido possível se o incidente envolve tokens, dados de sellers ou compradores, ou afeta a integração.
Sem plano de incidentes Com plano de incidentes
Pânico e confusão Passos claros a seguir
Não saber a quem ligar Contatos e funções definidos
Decisões improvisadas Processos e medidas testadas
Comunicação tardia ou incorreta Notificações planejadas
Repetir os mesmos erros Melhoria contínua com post-mortems

O impacto de uma resposta lenta:

Métrica Sem plano Com plano
Tempo de contenção Dias ou semanas Horas
Custo médio do incidente +55% maior Controlado
Dano reputacional Grave (notícias e mídia) Minimizado
Multas regulatórias Máximas (por não notificar a tempo) Reduzidas ou evitadas
Perda de clientes Uma boa porcentagem pode abandonar Mínima com boa comunicação.

Classificação de incidentes por severidade

Nem todos os incidentes requerem a mesma resposta, classificá-los permite uma priorização correta:

SEVERIDADE CRITÉRIOS TEMPO RESP. EXEMPLO
● Crítica (P1) Violação confirmada, dados expostos, múltiplos sellers afetados. Imediato ( < 15 min ) Tokens de 100+ sellers expostos na internet.
● Alta (P2) Vulnerabilidade explorável, exposição potencial, serviço degradado. < 1 hora SQL injection detectada, exploração não confirmada.
● Média (P3) Vulnerabilidade identificada sem exploração, impacto limitado. < 4 horas Certificado próximo de expirar, dependência vulnerável.
● Baixa (P4) Melhoria de segurança, descoberta menor. < 24 horas Senha fraca em conta de teste.

O ciclo de resposta a incidentes (Framework NIST)

O padrão NIST SP 800-61 define 4 fases para a gestão de incidentes:

Diagrama de atualização automática de tokens

Funções e responsabilidades durante um incidente

Defina quem faz o quê ANTES de ocorrer o incidente:

Função Responsabilidade
Incident Commander (IC) Lidera a resposta, toma decisões, coordena.
Technical Lead Investiga a causa raiz, executa contenção técnica.
Communications Lead Redige e envia comunicações aos afetados.
Scribe / Documentador Registra timeline, decisões, ações.
Subject Matter Expert Fornece conhecimento específico de acordo com o tipo de incidente.
Importante:
  • Defina substitutos para cada função (O que acontece se o IC estiver de férias?).
  • Publique esta informação onde todos possam encontrá-la.
  • Atualize quando houver mudanças de pessoal.

Comunicação durante incidentes

A comunicação pode fazer ou destruir sua reputação. Princípios-chave:

Comunicação interna:

O que comunicar Quando Para quem
Incidente detectado Imediato Equipe de resposta
Atualizações de status A cada 30 - 60 min Liderança e stakeholders
Resolução Ao encerrar Toda a organização

Comunicação externa: sellers / usuários afetados:

  • Seja transparente: não minimize nem oculte.
  • Seja oportuno: comunique o mais rápido possível, mesmo que não tenha todos os detalhes.
  • Seja claro: evite jargão técnico.
  • Seja acionável: informe o que devem fazer (alterar senha, revogar permissões, etc.)

Modelo de notificação:

modelo

Processo Post-mortem eficaz

Um incidente resolvido não é o fim, é o começo do aprendizado. O post-mortem é o processo de analisar o que aconteceu, por que aconteceu, e o que podemos fazer para que não volte a ocorrer. É a diferença entre repetir os mesmos erros e construir um sistema cada vez mais robusto.

Princípios do post-mortem:

  • Assuma boa intenção: todos agiram com as melhores informações disponíveis.
  • Foque em sistemas, não em pessoas: "Por que o sistema permitiu isso?" vs "Quem cometeu o erro?".
  • Busque causas raiz: use "5 Whys" para chegar ao fundo, consiste em perguntar Por quê? repetidamente até chegar à causa fundamental do problema.
  • Gere ações concretas: cada lição deve ter um action item atribuído.

Estrutura de um post-mortem

modelo

Métricas de resposta a incidentes

O que não se mede, não se melhora. As métricas de resposta a incidentes permitem saber se sua equipe está melhorando com o tempo, identificar gargalos no processo e justificar investimentos em segurança com dados concretos.

Métrica O que mede Objetivo
MTTD (Mean Time To Detect) Tempo desde que ocorre até ser detectado. < 1 hora
MTTA (Mean Time To Acknowledge) Tempo desde a detecção até alguém responder. < 15 minutos
MTTC (Mean Time To Contain) Tempo até conter o dano. < 4 horas
MTTR (Mean Time To Resolve) Tempo até resolver completamente. Depende da severidade
Incidents per month Quantidade de incidentes. Tendência descendente
Post-mortems completed % de incidentes P1/P2 com post-mortem. 100%

Exemplo de respostas a incidentes

Vejamos como é uma resposta caótica vs uma organizada:

modelo

Referências


Glossário

Termo Significado
Incidente de segurança Evento que compromete ou pode comprometer a confidencialidade, integridade ou disponibilidade de dados.
Violação Incidente confirmado onde dados sensíveis foram acessados ou exfiltrados.
Contenção Ações imediatas para limitar o dano de um incidente em curso.
Erradicação Eliminar a causa raiz do incidente (ex: fechar a vulnerabilidade).
Recuperação Restaurar sistemas e serviços à operação normal.
Post-mortem Análise posterior ao incidente para aprender e prevenir recorrências.
Playbook Guia passo a passo de como responder a tipos específicos de incidentes.
Tempo de resposta Tempo desde que um incidente é detectado até que ações sejam tomadas.
Notificação Comunicar o incidente às partes afetadas (usuários, reguladores, MercadoLibre).