Acesso remoto PCI DSS: Seções 8 e 12 explicadas

Você precisa realizar suporte remoto em sistemas que lidam com dados do titular do cartão e demonstrar a um auditor que cumpriu o PCI DSS. Isso normalmente significa provar quem se conectou, que estava autorizado, que foi usada autenticação multifator e privilégio mínimo, e que a sessão e seu escopo foram registrados e aprovados. Este artigo cita os títulos relevantes dos requisitos do PCI DSS, explica o que eles significam para uma sessão típica de suporte e fornece uma lista prática de controles que você pode apresentar a um auditor.

Títulos dos requisitos citados (resumos curtos)

Abaixo estão os títulos exatos, em linha única, dos requisitos do PCI DSS v4.0 que usaremos como âncora para o restante do artigo:

• "Requisito 8: Identificar usuários e autenticar o acesso a componentes do sistema."
• "Requisito 12: Manter uma política que trate da segurança da informação para empregados e contratados."

Esses títulos são as linhas curtas e oficiais. Ambos os conjuntos de requisitos têm muitos subrequisitos; abaixo eu traduzo as partes de 8 e 12 que realmente importam quando um fornecedor ou técnico de suporte se conecta remotamente.

O que o Requisito 8 exige para uma sessão de suporte remoto

O Requisito 8 trata de identidade e autenticação. Para uma sessão de suporte remoto, as implicações práticas são:

• Contas únicas e atribuíveis — sem logins compartilhados. Cada técnico que tocar em um sistema deve usar uma conta individual e auditável. Se você permitir que um fornecedor use uma conta compartilhada para suporte, você falha no Requisito 8.
• Autenticação forte e MFA quando apropriado. O PCI exige autenticação multifator para acesso ao ambiente de dados do titular do cartão (CDE) a partir de redes externas ou para acesso administrativo. Na prática, isso significa que o técnico de suporte deve autenticar‑se com uma senha mais um segundo fator (TOTP, push ou token físico) antes que a ferramenta de suporte abra uma sessão em sistemas do CDE.
• Acesso com tempo limitado e privilégio mínimo. Contas ou autorizações usadas para suporte de fornecedor devem ser restritas apenas aos sistemas e comandos necessários, e devem ser temporárias — criadas ou habilitadas apenas para a janela do trabalho e revogadas imediatamente após.
• Fluxos de acesso aprovados e registros de início de sessão. A organização deve ter uma etapa de aprovação documentada e auditável (uma aprovação por e‑mail ou ticket com assinatura do gerente/fornecedor) que vincule a sessão a uma justificativa de negócio e a um responsável.
• Regras de manuseio de credenciais. Credenciais compartilhadas ou codificadas não devem ser embutidas em scripts; segredos usados pelo pessoal de suporte devem ser emitidos ou armazenados em um cofre conforme sua política de credenciais e rotacionados quando a intervenção terminar.

Em outras palavras: o Requisito 8 transforma a pergunta "quem se conectou e como foi autenticado?" em um conjunto de verificações binárias — ID único, MFA (quando exigido) e uma janela de acesso — que você deve mostrar a um auditor.

O que o Requisito 12 exige para uma sessão de suporte remoto

O Requisito 12 obriga as organizações a codificar como gerenciam a segurança, incluindo acesso remoto e de terceiros. Para sessões de suporte, as partes que importam são:

• Políticas e procedimentos de acesso remoto documentados. Você deve ter uma política escrita que defina métodos de acesso remoto aprovados, o fluxo de aprovação, controles de autenticação exigidos e expectativas de retenção de evidências para acesso de fornecedores.
• Controles de gerenciamento de terceiros/fornecedores. Contratos ou Statements of Work devem especificar obrigações de segurança para qualquer fornecedor que acessará sistemas do CDE: ferramentas aceitáveis, métodos de autenticação, SLAs de reporte de incidentes e retenção de logs de auditoria.
• Aprovações de acesso e revisão periódica. A política deve exigir que o acesso do fornecedor seja aprovado por um responsável autorizado e que os direitos de acesso sejam revisados periodicamente e revogados se não forem mais necessários.
• Resposta a incidentes e prontidão forense. Se uma sessão de suporte levar a atividade suspeita, seu plano de resposta a incidentes deve cobrir como preservar logs de sessão, gravações e artefatos relevantes para que os investigadores possam reconstruir o evento.
• Treinamento e conscientização. Pessoal que concede ou monitora sessões de fornecedores deve ser treinado na política e em como validar a identidade do fornecedor e o escopo do trabalho.

O Requisito 12 trata essencialmente de governança: regras escritas, ferramentas aceitas, obrigações contratuais e um processo repetível de aprovação + auditoria. Um auditor vai querer ver a política e evidências de que ela foi seguida.

Checklist concreto: uma sessão de suporte amigável ao auditor

Abaixo está uma lista prática que você pode seguir para cada sessão de suporte que toque o CDE. Mantenha os artefatos juntos no ticket ou no registro de mudança — é isso que os auditores esperam revisar.

• Artefato de autorização: um ticket, e‑mail assinado ou aprovação de mudança que nomeie o solicitante, aprovador, escopo e justificativa de negócio antes do início da sessão.
• Prova de identidade do usuário: o nome da conta única do técnico e um carimbo de data/hora de autenticação mostrando o sucesso do MFA. Capturas de tela ou logs mostrando o sucesso do MFA são evidências aceitáveis.
• Janela de tempo e escopo: carimbos de início e fim da sessão; lista de hosts alvo e o trabalho específico realizado (comandos executados ou arquivos alterados).
• Aplicação do privilégio mínimo: prova de que a conta usada tinha apenas os privilégios requeridos (membro de função ou snapshot de privilégios) ou que a elevação foi concedida explicitamente e por tempo limitado.
• Gravação de sessão e log de auditoria: logs de conexão (IP de origem, host de destino, versão do cliente), trilha de auditoria das ações e, quando sua política exigir, gravação da sessão ou log de teclas. Armazene isso em um repositório resistente a adulteração.
• Alteração e rotação de credenciais: se o acesso do fornecedor exigiu credenciais compartilhadas ou senhas privilegiadas, rotacione‑as imediatamente após a intervenção e registre o evento de rotação.
• Revisão pós‑sessão: um gerente ou dono do sistema verifica que o trabalho foi concluído e atesta que nenhuma alteração inesperada ocorreu; uma breve nota pós‑suporte adicionada ao ticket é ideal.
• Observação sobre retenção: armazene a autorização, logs e gravações conforme sua política de retenção (veja sua política PCI). Torne‑os pesquisáveis por ticket ou identificador de ativo para que um auditor possa reconstruir a sessão em minutos, não semanas.

Essa checklist responde tanto ao Requisito 8 (quem autenticou e como) quanto ao Requisito 12 (existiu um processo aprovado e documentado e cobertura contratual?).

Onde o relay ou serviço em nuvem se encaixa — o posicionamento da Tenvo

Se sua ferramenta de suporte usa um relay — seja um relay operado pelo fornecedor ou o seu próprio — você precisa entender dois fatos importantes. Primeiro, conexões peer‑to‑peer diretas são end‑to‑end entre os dois endpoints. Segundo, quando o tráfego recai para um relay, a conexão TLS termina no relay, então quem opera esse relay pode tecnicamente acessar o tráfego da sessão. Isso é uma realidade para qualquer serviço de desktop remoto baseado em relay gerenciado; você não deve afirmar que o relay "não pode descriptografar" a menos que você opere o relay e controle as chaves.

Na Tenvo recomendamos nosso relay gerenciado multi‑região como padrão para a maioria dos clientes porque reduz o trabalho operacional: não há plantão para servidores de relay, nenhuma carga de renovação de certificados, e a Tenvo fornece clientes nativos para Windows, macOS e Linux, além de um cliente de navegador em beta público. Nossos níveis de preço são Free $0, Lite $2.99/mo, e Pro $7.99/mo. Use o relay gerenciado a menos que você tenha um requisito de conformidade escrito que proíba infraestrutura de terceiros. Se tal requisito escrito existir — mandatos de residência de dados, uma rede isolada air‑gapped, ou uma cláusula contratual que proíba hospedagem por terceiros — a autohospedagem é a escolha correta, mas ela vem com os custos de manutenção que o auditor esperará que você comprove.

Se você escolher o relay gerenciado da Tenvo, documente essa escolha nos artefatos de gerenciamento de fornecedores e adicione o operador do relay à lista de partes na linguagem contratual de terceiros. Essa transparência é o que os auditores procuram sob o Requisito 12.

Pacote de evidências de exemplo (o que entregar ao auditor)

Quando um auditor pedir prova de uma sessão de suporte, entregue uma única pasta zipada (ou um ticket com links) contendo:

• Trecho da política: a cláusula da política de acesso remoto que define aprovações, MFA e logs (evidência do Requisito 12).
• Artefato de aprovação: o ticket ou aprovação de mudança assinada referenciada na checklist acima.
• Logs de autenticação: uma única exportação mostrando o ID único do técnico, o evento de MFA e carimbos de data/hora (evidência do Requisito 8).
• Logs de sessão e gravação: log de conexão, log de ações e a gravação da sessão se sua política exigir (ou a razão pela qual a gravação não foi usada, com controles compensatórios).
• Snapshot de privilégios: a função ou ACL que se aplicou à conta do técnico durante a sessão e uma declaração de que o acesso foi por tempo limitado.
• Cláusula contratual: acordo com o fornecedor ou SOW que estabelece requisitos de segurança e obrigações de reporte de incidentes (evidência do Requisito 12).
• Atestado pós‑sessão: confirmação do gerente ou do dono do ativo de que o trabalho concluído correspondeu ao escopo e que as credenciais foram rotacionadas quando necessário.

Forneça esses artefatos com nomes de arquivo claros e um documento índice curto que mapeie cada arquivo aos itens da checklist — os auditores apreciam a economia de tempo.

Erros comuns e gatilhos do auditor

Estes são erros que vemos regularmente e que imediatamente estendem o trabalho do auditor:

• Contas compartilhadas. Se vários técnicos usam o mesmo login, você não consegue atribuir ações e o auditor irá reprovar você no Requisito 8.
• Ausência de MFA para acesso externo. Se o técnico se autentica a partir de uma rede externa e o MFA não foi usado para entrar no CDE, isso é uma constatação clara.
• Falta de pré‑aprovação. Permitir aprovações espontâneas, pós‑fato ("deixamos eles entrarem e depois documentamos") falha nas expectativas do Requisito 12 sobre processo documentado.
• Sem logs ou timestamps incompletos. Logs com lacunas, relógios inconsistentes ou falta de marcadores de início/fim forçarão o auditor a solicitar mais evidências.
• Uso não rastreado de ferramentas de fornecedores. Se um fornecedor se conecta com uma ferramenta não listada em sua política e não coberta no contrato, o auditor irá escalar questões de gerenciamento de fornecedores.

Corrija isso antes da sua avaliação: elimine contas compartilhadas, exija MFA para toda conexão remota ao CDE, formalize janelas pré‑aprovadas para fornecedores e centralize a coleta de logs.

Quando autohospedar um relay — e por que não é o padrão

Autohospedar seu relay (ou usar um broker on‑prem) é válido quando você tem uma restrição formal: linguagem de conformidade escrita proíbe infraestrutura de terceiros; você opera em uma rede isolada; ou uma lei de residência de dados força a manter relays dentro de uma região que você controla. Se você autohospedar, o auditor esperará que você comprove que opera o relay de forma segura: cadência de patching, ciclo de vida de certificados, alta disponibilidade, backup e um plano de resposta a incidentes que inclua o relay.

Para a maioria das organizações, um relay gerenciado custa menos no total quando você contabiliza tempo on‑call, patching, custódia de chaves, renovação de certificados e o risco de única região sem failover. O relay gerenciado da Tenvo reduz essa sobrecarga operacional — mas documente a escolha e inclua o operador do relay nos seus controles de terceiros.

Leituras adicionais e guias relacionados

Se você precisa de how‑tos práticos e referências de configuração, comece por estes artigos da Tenvo: Registro de auditoria de Desktop Remoto para formatos de log e retenção; Como conceder acesso remoto a alguém para fluxos de trabalho seguros de sessão; e Segurança de Desktop Remoto: O que Você Precisa Saber para o modelo de ameaça geral e opções de MFA.

Estes ajudarão você a construir os artefatos que os auditores esperam e os hábitos operacionais que sua equipe de segurança precisa.

Conclusão e próximos passos

O Requisito 8 do PCI DSS obriga você a provar identidade, MFA e privilégio mínimo para cada sessão de suporte. O Requisito 12 obriga que você tenha uma política escrita e aplicada que governe essas sessões e seus fornecedores. Combine um fluxo de aprovação aplicado, contas individuais com MFA, privilégio limitado no tempo, registro/gravação de sessão e controles contratuais de fornecedores, e você cobrirá as partes em que os auditores focam para suporte remoto.

Se você quer um ponto de partida prático: documente seu fluxo de aprovação, exija contas únicas + MFA para todo acesso remoto a sistemas do CDE, centralize logs de sessão em um repositório resistente a adulteração e registre uma declaração após cada sessão. Use um relay gerenciado como Tenvo para menor sobrecarga operacional, a menos que uma regra escrita force a autohospedagem.

Baixe o Tenvo para testar um fluxo de trabalho compatível: Baixar.