Um cliente no setor de varejo tem uma rede com terminais de ponto de venda (PDV) que se conectam a um servidor PDV. Além disso, a maioria das estações de trabalho do Windows em áreas de não vendas também se conecta ao mesmo servidor. Isso ocorre porque o software POS é apenas um módulo de um aplicativo legado maior que executa tudo para a empresa (estoque, compras, contabilidade, etc.).
De acordo com o nosso auditor PCI (QSA), qualquer sistema que se conecta diretamente ao ambiente de dados do portador do cartão é considerado no escopo (não apenas nos sistemas que armazenam, processam ou transmitem dados CC).
O problema é como limitar o escopo para que as centenas de estações do Windows que não têm nada a ver com dados CC não estejam no escopo do PCI DSS.
Este diagrama mostra como as estações POS e Windows se conectam atualmente ao servidor:
EstediagramamostracomoelesseconectamcomumhostBastionimplementado:
O Windows WS usa Putty ou semelhante ao SSH para o host Bastion usando autenticação baseada em senha. O script de login ou shell personalizado no Bastion hospeda auto-SSHes para o POS Server usando a autenticação baseada em chave e o usuário entra no aplicativo de negócios de forma transparente (o usuário nunca obtém um shell ou a capacidade de quebrar o shell).
Mas o que isso realmente faz em termos de segurança aprimorada?
Sem um host de bastiões:
Se o Windows WS estiver comprometido e eles obtiverem a senha de login para o servidor de POS, eles poderão enviar o SSH para ele, mas eles ainda só entrarão no aplicativo de negócios sem acesso ao shell.
Com um host de bastiões:
Se o Windows WS estiver comprometido e eles obtiverem a senha de login no servidor Bastion, eles poderão enviar SSH para ele, mas eles ainda só entrarão no aplicativo comercial sem acesso ao shell.
Não vejo que o host Bastion ofereça muita segurança extra nesse cenário.
Feedback e / ou sugestões sobre isso seriam apreciados.