Segurança

Modelo de segurança

O Riversoft® STCP DirectLink aplica os controles da transferência gerenciada de arquivos (MFT) a todos os protocolos e conectores: só usuários autenticados trocam arquivos, os dados trafegam cifrados, cada operação é validada contra as regras do usuário e tudo fica registrado. A segurança é organizada em camadas:

Protocolos e conectores

Os protocolos e conectores do Riversoft® STCP DirectLink usam conexões cifradas e autenticação por usuário. Os mecanismos variam conforme o protocolo e as políticas de segurança do ambiente.

TLS 1.2 e TLS 1.3

O portal, a API REST, o AS2, o Webhook, o FTPS e os conectores de nuvem (Amazon S3, Azure Blob Storage, Google Cloud Storage e Oracle Cloud Object Storage) usam TLS 1.2 ou TLS 1.3.

SFTP

O SFTP (SSH File Transfer Protocol) usa um canal seguro SSH-2. A autenticação pode ser feita por usuário e senha ou por par de chaves pública e privada. Os algoritmos e as políticas de segurança são negociados no estabelecimento da conexão.

O SFTP Server aceita autenticação de dois fatores (2FA) e MFA, conforme a configuração do usuário.

AS2

O AS2 (Applicability Statement 2) é voltado à troca de documentos entre organizações. Ele usa TLS 1.2 e 1.3, certificados X.509, S/MIME, assinatura digital, MDN (Message Disposition Notification) e MIC (Message Integrity Check).

• O MDN comprova a entrega da mensagem e pode ser síncrono ou assíncrono, com assinatura digital.
• A combinação de MIC e assinatura digital garante o não repúdio de envio e de recebimento.
• São suportados EDI, EDIFACT, X12, XML, JSON, arquivos binários e outros tipos de conteúdo.
• O MDN pode ser criptografado no envio e na recepção, conforme a configuração do usuário.
• O usuário pode se autenticar no serviço AS2 por token Bearer.

FTPS, Webhook e armazenamento em nuvem

Autenticação no Riversoft STCP DirectLink Portal

O acesso ao portal pode ser feito:

• Diretamente, com usuário e senha do STCP. Quando exigido pela configuração, o login é concluído com um segundo fator (MFA): PIN enviado por e-mail ou SMS, ou código TOTP de um aplicativo autenticador.
• Por SSO (Single Sign-On), com Google, Microsoft, Apple ou qualquer provedor de identidade compatível com OAuth 2.0 e 2.1/OpenID Connect ou SAML 2.0.

Após o login, a sessão é mantida pelo cookie __Host-dirl_session, emitido com os atributos HttpOnly, Secure e SameSite=Strict. O logout remove o cookie. Por isso, o portal precisa ser publicado por HTTPS.

Proteção contra automação

O administrador pode habilitar o Cloudflare Turnstile no login, no primeiro acesso e na recuperação de senha. Com o recurso habilitado, o portal exibe a verificação da Cloudflare antes de enviar as credenciais, e a requisição só é processada com um token válido. O token é de uso único e expira em 300 segundos. Integrações que chamam essas rotas diretamente devem seguir o contrato da API.

Autenticação na API

A partir da versão 9, as rotas protegidas da API (upload, listagens, relatório e logout) aceitam somente um token Bearer. A autenticação Basic (usuário e senha) é aceita apenas no login.

Quando o header Authorization e o cookie estão presentes, o header tem prioridade. O token expira após o tempo informado em expires_in.

O token autentica o usuário, mas não libera o acesso por si só: a API também aplica as regras do usuário no servidor STCP (conexão liberada, janela de horário, filtros e limite de sessões). Por isso, um token válido pode receber 403.

Token de impersonação

Integrações técnicas que precisam de uma credencial de longa duração podem usar um token de impersonação, gerado pelo administrador na interface de supervisão. O token tem um identificador de sessão registrado para o usuário; a API confere esse identificador a cada chamada, e um token cujo identificador não esteja registrado é rejeitado. Detalhes em Tokens OAuth.

A API pode seguir o OAuth 2.1. Veja Compatibilidade com OAuth 2.1.

Autenticação por JWT de confiança

Para integrar o Riversoft STCP DirectLink a portais de serviços, o portal emite um token JWT para o usuário, assinado com a sua chave privada, e o troca por um token Bearer do Riversoft STCP DirectLink (token exchange, RFC 8693). O Riversoft STCP DirectLink valida o JWT de origem com a configuração do provedor JWT cadastrada pelo administrador.

    sequenceDiagram
    autonumber
    participant PS as Portal de serviços
    participant DL as API Riversoft STCP DirectLink
    PS->>PS: Emite o JWT do usuário (chave privada)
    PS->>DL: POST /auth/token (token exchange, subject_token = JWT, provider)
    DL->>DL: Valida assinatura, issuer, audience e validade
    DL->>DL: Confere o usuário e as regras de acesso
    DL-->>PS: access_token (Bearer)
    PS->>DL: Chamadas às rotas protegidas com Authorization: Bearer
  

Requisição de troca do token

curl -X POST "https://<dominio>/directlink/v2/auth/token" \
  --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
  --data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:jwt" \
  --data-urlencode "subject_token=<jwt-de-origem>" \
  --data-urlencode "provider=<provedor-jwt>"

• provider é o identificador do provedor JWT cadastrado pelo administrador. Ele também pode ser enviado no header X-STCPDIRECTLINK-JWT-ISSUER; se os dois forem informados, o campo do formulário prevalece. O valor não precisa ser igual à claim iss.
• O único subject_token_type aceito é urn:ietf:params:oauth:token-type:jwt.
• O usuário identificado nas claims precisa existir no servidor STCP e corresponder ao perfil configurado.

Estrutura do token de origem

Header

Payload (claims)

A chave pública (ou o material de validação) que confere a assinatura é cadastrada pelo administrador na configuração do provedor JWT. Os campos kid e alg devem corresponder aos da chave cadastrada. Proteja a chave privada do portal de serviços.

Link seguro e código de segurança

O link seguro enviado a destinatários externos identifica o e-mail ou celular vinculado ao arquivo. O download só é liberado com o código de segurança (PIN), que é enviado somente a esse e-mail ou celular. Veja o fluxo em Conceitos e arquitetura.

A validade é definida pelo administrador:

Gestão de senha

O usuário define ou redefine a senha em duas etapas:

1. Solicita o link de alteração em Primeiro acesso ou Esqueceu a senha.
2. Confirma a nova senha em Alteração de senha, com o PIN de segurança enviado ao e-mail cadastrado.

Chave de criptografia das senhas

As senhas gravadas no banco de configuração são criptografadas com uma chave que precisa ser a mesma em todos os módulos do ambiente. Veja como definir a chave e o que fazer para trocá-la em Configuração: chave de criptografia das senhas.

Boas práticas

• Publique o Riversoft STCP DirectLink somente por HTTPS (o cookie de sessão exige Secure).
• Nas integrações, obtenha o token uma vez e reutilize-o até a expiração; não envie a senha em cada chamada.
• Guarde tokens, inclusive os de impersonação, em um cofre de segredos e defina a rotação.
• Habilite somente os modos de autenticação necessários ao ambiente.
• Considere habilitar o Cloudflare Turnstile no login, no primeiro acesso e na recuperação de senha.
• Implemente o limite de requisições (rate limiting) no firewall de borda: a API não aplica esse limite.
• Use o hash SHA-256 do arquivo (h ou X-STCPDIRECTLINK-HASH) para validar a integridade dos uploads.
• Proteja a chave privada usada na assinatura dos tokens JWT de origem.
• Use a mesma chave de criptografia (applConfigPassPhrase) em todos os módulos do ambiente. Veja Chave de criptografia das senhas.

Privacidade

O portal do Riversoft STCP DirectLink usa apenas o cookie de sessão __Host-dirl_session, necessário para manter o login, e não usa cookies de rastreamento. O cookie é removido no logout.

Quando o Cloudflare Turnstile está habilitado, a verificação é feita pela Cloudflare, que recebe o token do desafio e o endereço IP do usuário.