Incidentes

Três comandos no servidor são feitos para incidentes. Cada um pergunta antes de mudar qualquer coisa (--yes pula a pergunta) e cada um fica registrado no log de auditoria, sem ninguém como autor.

• revoke-access --everyone, ou --user EMAIL, encerra as sessões e revoga os tokens de acesso; --sessions-only ou --tokens-only faz só uma das duas coisas. As pessoas fazem login de novo e rodam rmk login; ninguém é desativado e nenhuma senha muda. O --everyone também revoga os tokens SCIM dos provedores de identidade: gere novos na página de cada provedor.
• rotate-secret grava um novo AUTH_SECRET no arquivo de configurações e encerra todas as sessões. O Docker e o rmk-server passam a usá-lo a partir da próxima requisição; um servidor rodando a partir de um clone precisa ser reiniciado. Os tokens de acesso não são assinados com ele: revogue-os também quando eles puderem ter vazado. Os segredos do login em duas etapas são criptografados com ele, então o comando desativa o login em duas etapas de todos que o têm e diz quantos: essas pessoas o configuram de novo. Os client secrets dos provedores de identidade são criptografados de novo, então continuam funcionando.
• disable-sso desativa todos os provedores de identidade, e o SCIM deles, e deixa todo mundo fazer login com senha de novo (Bloqueio e provedores com falha). Ninguém é desconectado.

O que fazer primeiro, conforme o que aconteceu:

• Uma versão nociva foi lançada: retire-a com um motivo (Depreciar ou retirar) e depois encontre no log de auditoria quem a aprovou e a lançou. Os projetos que pedem latest deixam de usá-la no próximo rmk install; os que pedem uma faixa de versões continuam a instalá-la, sem aviso, até rodarem rmk update: avise-os.
• Alguém perdeu o celular e os códigos de backup: um root redefine o login em duas etapas da pessoa em Users, ou no servidor com reset-two-factor --email EMAIL (qualquer conta, inclusive a do root). Isso encerra as sessões dela; ela faz login com a senha e o configura de novo.
• Um provedor de identidade quebrou, ou não é mais confiável: rode disable-sso; quem tem senha faz login com ela, e o root sempre pode. Se o provedor puder ter deixado entrar pessoas que não deveriam, rode também revoke-access para elas, ou --everyone. Se o SCIM dele puder ter sido usado indevidamente, use Revoke no token SCIM dele, na página do provedor, e procure no log de auditoria user.created e mudanças de membro feitas por ele. Depois corrija-o (um novo client secret: Replace), rode Test sign-in e ative-o de novo, e depois o SCIM, com um token novo.
• Alguém saiu: com SCIM, remova a atribuição da pessoa ou desative-a no provedor: a próxima sincronização dele desativa a conta dela aqui (o Entra sincroniza mais ou menos a cada 40 minutos). Para cortar o acesso dela agora, ou sem SCIM, desative-a em Users: as sessões e os tokens dela terminam na hora.
• Um token de acesso vazou: o dono o revoga na página CLI & tokens; se não, revoke-access --user EMAIL --tokens-only.
• Uma conta foi invadida: desative-a em Users (as sessões e os tokens dela terminam na hora), leia os eventos de auditoria dela, redefina a senha e ative-a. Para uma conta root, rode reset-root-password no servidor.
• O arquivo de configurações, um backup ou o servidor vazou: rotate-secret, depois revoke-access --everyone --tokens-only, depois troque a senha do banco de dados e rode o setup de novo com ela.
• Um moderador ou admin agiu contra as regras: mude o papel dele na página do espaço de trabalho e depois revise o que ele aprovou e lançou.

O Ronne não envia mensagens por conta própria: avise as pessoas pelos seus próprios canais. O runbook de incidentes traz cada incidente passo a passo, como conferir se funcionou, o que dizer aos usuários e um modelo.