SSO e um log de auditoria, sem uma ligação de vendas enterprise

Single sign-on é tratado como um recurso de nível enterprise na maioria das plataformas, trancado atrás de uma conversa de vendas e um preço que assume algumas centenas de assentos. A maioria das equipes que de fato querem isso são pequenas — um punhado de engenheiros que prefeririam não manter uma senha separada para a única ferramenta que consegue reiniciar a produção.

Configurando

Settings → Single sign-on, só admins. Os dois casos comuns são suportados diretamente, não um com o outro parafusado depois:

OpenID Connect — Google Workspace, Okta, Microsoft Entra, Authentik, Keycloak, ou qualquer outro provedor OIDC:

1. Crie um app web OpenID Connect no seu provedor de identidade, usando a URI de redirecionamento que a página mostra.
2. Preencha a Issuer URL, Client ID, Client secret, e o domínio de e-mail ao qual isso se aplica.
3. Escolha o papel com o qual pessoas novas entram — viewer, deployer ou admin.
4. Opcionalmente exija SSO para esse domínio, o que desliga o login por senha completamente para ele.

SAML 2.0 — escolha na mesma página, cole a URL de login e o certificado do provedor de identidade, e o Railyard mostra a URL do ACS, o entity ID e os metadados do SP para entregar ao Okta, Entra, OneLogin, JumpCloud ou ADFS. As respostas são checadas quanto a assinatura, audiência, tempo e ID de requisição — não só aceitas porque foram interpretadas corretamente.

Antes de qualquer um conseguir de fato entrar por qualquer um dos dois métodos, o domínio precisa ser verificado com um registro TXT (_railyard-sso.<domain>) — o SSO nunca loga numa conta de operador do site ou numa conta fora da equipe, e dois fatores ainda são exigidos mesmo para quem entra pelo SSO.

SCIM, depois que o SSO é salvo

Aponte o app SCIM 2.0 do seu provedor de identidade para https://app.railyard.run/scim/v2 com um token bearer gerado, e a entrada na equipe para de ser uma etapa manual: atribuir alguém no provedor de identidade adiciona ele à equipe, desativar remove. Owners nunca são removidos desse jeito — esse papel continua sendo uma ação deliberada e humana.

O log de auditoria, e o que ele de fato cobre

Activity no menu lateral registra deploys, mudanças de variável, mudanças de membro, aprovações e jobs de dados — filtrável por membro, app, tipo e intervalo de data, exportável como CSV. Mudanças de variável mostram quem mudou qual nome e quando, nunca o valor em si, então o log é útil sem se tornar um segundo lugar de onde segredos vazam.

A parte que vale saber: ações que um operador do Railyard toma na sua equipe — mudando limites, suspendendo, reintegrando — caem nesse mesmo log, não um separado que só nós vemos. Se algo foi feito à sua equipe, você consegue ver da mesma forma que veria qualquer coisa que seus próprios membros fizeram.

O score que te diz se algo disso está de fato ativo

Settings → Security checa dez coisas e dá uma nota de 0–100 à equipe: dois fatores em todo membro, admins que não fazem login há 90 dias, servidores com atualizações de segurança pendentes, sistemas operacionais fora de suporte, portas abertas, expiração de certificado, verificação de backup, stagings desprotegidas, e tokens de API sem expiração. Cada checagem que falha leva direto para a correção, então “a gente tem um score de segurança” não fica só parado sem ninguém ler no fim de uma página de configurações.

Referência completa: Teams, SSO and access.