O documento discute boas práticas de segurança de dados em .NET, abordando riscos como injeção de SQL e acesso indevido a dados. Ele fornece exemplos de ataques e medidas para preveni-los, como uso de ORM, criptografia, mascaramento de dados e controle de acesso por usuário.

1. Acesso a Dados em .NET
BOAS PRÁTICAS DE SEGURANÇA

2. Renato Groffe
◦ Microsoft Most Valuable Professional (MVP)
◦ Multi-Plataform Technical Audience Contributor (MTAC)
◦ Mais de 15 anos de experiência na área de Tecnologia
◦ Autor Técnico e Palestrante

3. Contatos
http://renatogroffe.net/
/renatogroffe /in/renatogroffe
/renatogroff /renatogroffe
/@renato.groffe

4. Canal .NET
/canaldotnet
/canaldotnet

5. Agenda
◦Segurança da Informação e a plataforma .NET
◦Exemplos práticos

6. Segurança da Informação e a plataforma .NET

7. Desenvolvedores e a questão da segurança
◦Nunca vai acontecer comigo
◦A aplicação é pequena, não há
muitos usuários
◦O pessoal de TI é confiável
◦Nossos usuários são leigos demais

8. E se essas “verdades” falharem?
◦Injeção de SQL (SQL Injection)
◦Acesso em produção com permissões
especiais
◦Acesso indevido a informações
confidenciais

9. O que torna possível a injeção de SQL?
◦Concatenação de comandos e
parâmetros em strings
◦Descuidos com a manipulação de
query strings em aplicações Web

10. Simulando um ataque de injeção de SQL

11. Diminuindo o impacto - Injeção de SQL
◦Evitando a concatenação de parâmetros
em comandos SQL
◦Criar um usuário para a aplicação no
servidor de banco de dados
◦ Retirar a possibilidade de execução de
comandos do tipo DDL (CREATE, DROP,
ALTER)
◦Utilizando soluções ORMs como Entity
Framework e NHibernate

12. Há outras formas de ataque...

13. Outras formas de ataque
◦Engenharia social
◦Acesso indevido a dados restritos
◦Espionagem industrial

14. Possíveis causas
◦ Inexistência de políticas de segurança da
informação
◦ Ambientes de produção desprotegidos

15. Possíveis consequências
◦ Vazamento de informações confidenciais
◦ Prejuízos à imagem de uma organização
◦ Problemas jurídicos
◦ Perdas financeiras

16. Como evitar isto?
◦ Mascarar/Obfuscar dados
◦ Criptografia via aplicação e/ou base
de dados
◦ Definindo usuários e permissões de
acesso em uma base

17. Datamask no SQL Server (versão 2016 em diante)

18. Outros cuidados adicionais
◦ Criptografia de arquivos de configuração
◦ Armazenar segredos em alguma solução específica
(Azure Key Vault, por exemplo)
◦ HTTPS sem aplicações Web sempre (sites, serviços,
APIs)
◦ JWT (JSON Web Token) em APIs REST
◦ Implementação de exclusão lógica

19. Dúvidas?

20. Obrigado!