Estou de volta após um longo período sem postagens. Essa ausência foi devido à festas de fim de ano, projetos pessoais e um projeto longo em que estive envolvido e que me consumiu quase que 16 horas por dia, 7 dias por semana. Enfim, cá estou de volta com mais um artigo.
Vou falar um pouco sobre a norma PCI DSS, e suas implicações no desenvolvimento de soluções para auto-atendimento em geral.
O que é PCI DSS?
PCI - Payment Card Industry: Está associada às indústrias de cartões de crédito e débito, ATM, terminais POS e etc, e seu conselho foi originalmente formado pelas principais bandeiras de cartões de crédito no mundo, como Visa, Master Card e American Express. O objetivo desse conselho é manter e evoluir o PCI DSS. DSS é a sigla para Data Security Standard, que é uma norma de segurança da informação, de abrangência mundial, para ajudar a evitar fraudes junto a indústria de pagamentos à cartão.
Essa norma descreve 12 requisitos que devem ser atendidos integralmente para garantir a segurança, ou dirimir as chances de fraudes em qualquer sistema que lide com cartões de crédito. Além disso, a PCI estabelece uma certificação a qual as empresas devem se submeter, para serem reconhecidas como empresas aderentes ao PCI DSS.
Abaixo seguem os 12 requisitos:
| Control Objectives | PCI DSS Requirements |
|---|---|
| Build and Maintain a Secure Network | 1. Install and maintain a firewall configuration to protect cardholder data |
| 2. Do not use vendor-supplied defaults for system passwords and other security parameters | |
| Protect Cardholder Data | 3. Protect stored cardholder data |
| 4. Encrypt transmission of cardholder data across open, public networks | |
| Maintain a Vulnerability Management Program | 5. Use and regularly update anti-virus software on all systems commonly affected by malware |
| 6. Develop and maintain secure systems and applications | |
| Implement Strong Access Control Measures | 7. Restrict access to cardholder data by business need-to-know |
| 8. Assign a unique ID to each person with computer access | |
| 9. Restrict physical access to cardholder data | |
| Regularly Monitor and Test Networks | 10. Track and monitor all access to network resources and cardholder data |
| 11. Regularly test security systems and processes | |
| Maintain an Information Security Policy | 12. Maintain a policy that addresses information security |
Esses são os 12 principais requisitos, mas existem cerca de 220 sub-requisitos aplicáveis a todas as áreas de um sistema que envolva pagamento com cartão de crédito.
O que isso tem a ver com você?
Bom, se você desenvolve sistemas para auto-atendimento, ou mesmo drivers proprietários, SPI ou DS para esses sistemas, então você precisa realmente observar bem esses requisitos e, em especial, os ítens 3 e 4, que compõem o objetivo "Protect Cardholder Data", ou seja, Proteja os Dados do Cliente contidos no cartão.Isso pode parecer óbvio mas, na prática, as pessoas realmente não se dão conta das implicações:
Cardholder Data: diz respeito à todos os elementos de dados contidos no cartão (tanto no chip quanto nas trilhas magnéticas), tais como: PAN (Primary Account Number), nome do cliente, código de serviço (service code), data de expiração do cartão, além de dados ainda mais sensíveis como PIN Block ou senha do cartão, e os dados completos das trilhas magnéticas.
Quando o sistema executa em ambiente de produção, se você armazenar em log sem criptografia qualquer uma dessas informações, ou transmiti-las por rede de dados pública (como a Internet), sem os dados estarem devidamente criptografados, então isso implica na impossibilidade de atendimento da norma, o que causaria problemas em um eventual processo de certificação a que o cliente poderia se submeter.
Todas essas informações são importantes para o acionamentos dos fluxos funcionais de qualquer aplicação de auto-atendimento. O ponto é que, a manipulação desses dados precisa ser realmente realizada com cautela, observando os requisitos da norma, e embora os logs de algumas dessas informações seja realmente importante durante o processo de desenvolvimento, os mesmo precisam ser suprimidos quando o sistema for compilado em modo release, para envio á produção.
Implicações para o projeto
Ás vezes, os requisitos do cliente exige que parte desses dados sejam acessados através do sistema. Por exemplo: permitir que um operador do sistema consiga ter acesso à logs que contenham essas informações. Nesse caso, os requisitos 7, 8 e 9 da norma especificam que esse acesso precisa ser implementado através de um sistema de controle de acesso para que somente pessoas autorizadas possam ter acesso a esses dados, e contando com a identificação única dessas pessoas.
Note que essas coisas tem fortes implicações na parte de design e implementação quando o sistema que está sendo desenvolvido pretende atender á norma. Portanto, se você se deparar com algo como: "...o sistema precisa estar aderente à norma PCI DSS.". Bom, então leve conta todos os 12 requisitos da norma, desde o processo de análise e levantamento do esforço, pois o retrabalho depois poderá ser grande!
Conclusão
Embora controverso e muitas vezes alvo de críticas em função de seu alto custo de implementação e pouca clareza em algum pontos, o PCI DSS é uma norma que, em pelo menos seus 12 principais requisitos, estabelece um nível mínimo de segurança, a que todos os desenvolvedores, projetistas e profissionais que lidam com sistemas de auto-atendimento deveriam estar atentos.
Bem é isso :)
