Há alguma possibilidade prevista no ScriptCase de se trabalhar com os dados em BD criptografados?
Resumindo: os dados no banco estão totalmente irreconhecíveis, porém são apresentados normalmente nas telas do sistema gerado.
Seria possível se nesse banco de dados você pudesse criar uma função/procedure, para descriptografar os dados dos campos em uma SQL campo a campo antes de apresentar os mesmos em tela para as grids consultas e nos formulários no OnLoad você teria que descriptografar os dados antes de exibir e no OnValidate criptografalos novamente, seria bem trabalhoso criar e manter tal sistema, mas não impossível.
O MySQL/MariaDB tem muitas funções nativas de criptografia.
https://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html
Você pode fazer usando isto na sua linguagem, exemplo este como é feito na guarda da senha, no caso do padrão do Scriptcase usando MD5, ou usando o banco conforme @Jailton colocou… mas também como ele colocou, é muito trabalho.
1 Curtida
Qual o sentido disso.
Como fica cálculos e ordenação?
Jailton, não seria legal deixar uma funcao dentro do banco que mostre como descriptografar os dados.
Se o banco for roubado… as funcoes estariam juntas.
Joelton, seria interessante opcoes dentro do próprio scriptcase. Do tipo setar um campo como sendo criptgrafado (da mesma forma como seta um campo senha).
Mas no caso nao mostraria “*” e sim o dado real descriptografado.
Haroldo, o sentido é para aderência a LGPD que em 1 ano passa a valer.
No caso seria para dados pessoais apenas, com o objetivo de criptografar informações que possam identificar um indivíduo.
Para rastreabilidade de recuperação e acesso ja teriamos a função de log do SC
Daki a um ano, todos os sistemas terao que estar adaptados à LGPD.
apenas para quem nao conhece acompanhar e entender:
LGPD - Lei Geral de Proteção de Dados
Que passa a valer em agosto de 2020, e que todas as empresas que armazenam dados de terceiros será obrigada a adotar, ou poderá tomar multa de 2% sobre o faturamento em cada denuncia.
Acredite: Além o advogado de porta de cadeia, passaremos a ter o advogado de porta ethernet!!!
Isto não teria muita lógica devido por existir várias formas padrões de criptografia, e sem contar que em sua maioria cria sua própria criptografia…
1 Curtida
Você já falou isto em outro tópico que já respondi, estão misturando as coisas, estou observando que está faltando interpretação do texto… vou colar aqui minha resposta do outro tópico…
… já estava acompanhando isto logo em sua homologação…(http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/L13709.htm )
Dependerá de cada sistema e sua finalidade, Scriptcase é ferramenta, PHP é linguagem, e nós somos programadores(“sei que também tem muito que não programam e pensam que a ferramenta faz tudo”), logo a gestão do “negócio” é nossa, tempos que adaptar, eu por exemplo terei que mudar na minha vida uma coisa… criar uma agenda de retenção para dados. Quando os dados chegaram ao final do seu período de retenção, destruirei de acordo com uma política de destruição de dados (minimizando até o volume de dados no banco, inclusive adorei isto), mas por outro lado temos que manter arquivos fiscais por 5 anos, pois se lermos e compreendermos, identificaremos a base legal para processar cada categoria de dados. É importante lembrar que a LGPD não irá se sobrepor a outras regras, sendo assim, é importante entender bem a sua regra de negócios e implementar a LGPD de acordo com CDC , CPC , Marco Civil da Internet , Lei Carolina Dieckmann , etc…
Logo não é bixo de 7 cabeças e não existe este monstro criado, apenas se foque no seu produto e resolva.
Um abraço e fique na paz!
1 Curtida
Caro Joelton, são tópicos distintos, no anterior o Patrick pergunta se alguém já aplicou as regras aos sistemas criados com o scriptcase.
Neste tópico que eu criei eu estou perguntando sobre o SC trabalhar com dados em BD criptografados.
O amigo Haroldo perguntou qual o sentido de minha pergunta e como fica calculos e ordenação, e repondi a ELE.
O único que não enxergou a diferença óbvia entre os dois tópicos, talvez por não perceber a diferença entre eles (como vc mesmo disse, por falta de interpretação de texto) foi você. Aqui é um fórum, e a resposta é atemporal e não seletiva nem de interesse nem de leitores.
Por favor, vc já tumultuou o outro tópico de forma agressiva, e novamente está tumultuando o meu tópico, por favor, vamos nos ater ao assunto. Não tenho como você, nenhum interesse de sobrepor minha opinião, ou demonstrar conhecimento. Apenas enrriquecer o tópico para leitores futuros.
Quero cordialmente pedir que se atenha ao assunto caso tenha algo a agregar à discussão, qualquer outro problema, por favor reporte ao moderador. Mas caso contrário, solicito que se abstenha de fazer flamming.
Desde já agradeço. De coração.
Sr Ciro se recebeu como ofensa, peço mil perdões… finja que não estive aqui para não causar este mal estar… sobre o outro tópico lhe faltou discernimento em tuas palavras… mas enfim… e apenas corrigindo na informalidade da escrita inglesa se diz flaming, não flamming… exemplificando… “We had a flaming row over it last night!”
Um abraço e esteja na paz…
E me desculpe se puder novamente…
Você precisa aplicar isso na prática atualmente?
Aonde aqui aponta sobre criptografia?
http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/L13709.htm
Você somente quero aumentar a segurança? É isto?
Pergunto porque realmente dá uma camada de segurança a mais.
Mas o desempenho poder sofrer alguma coisa com isto.
PS: Somente se for nesta parte aqui Capítulo VII, seção I, § 3º No juízo de gravidade do incidente, será avaliada eventual comprovação de que foram adotadas medidas técnicas adequadas que tornem os dados pessoais afetados ininteligíveis, no âmbito e nos limites técnicos de seus serviços, para terceiros não autorizados a acessá-los.
Esta discussão pode ser muito complexa.
Porque veja bem se estou com dados em transporte justifica a completa criptografia e também com dados guardados que não são usados.
Mas pegue um sistema que você criptografou os dados nas tabelas do banco, usa HTTPS para que os dados trafeguem seguros, usa todas esta parafernália.
Mas:
- Tem seus associados que sabem a chave criptográfica e que podem vazar.
- Os seu fontes em php que não são criptografados (php não é binário ok?) e tem esta chave. Logo, qualquer um que tiver acesso as estes fontes terá com quebrar a criptografia.
Enfim se for usar criptografia com php e SGDB. Tem que criptografar tudo.
A conexão por https, o script PHP, as tabelas no banco, o uso de ssh ou ftp com tls ativo para transito de informações, o local onde guarda as chaves de criptografia, etc.
Mas não terá controle sobre o item 1. O item 1 é o hackerismo social. O meio mais ativo e usado para roubar dados.
Tem que prever no contrato dos colaboradores esta situação.
Com PHP se for para usar criptografia somente no banco não rola. A chave fica exposta nos seu fontes.
Tem que criptografar eles também. E sem o uso de https, ssh ou ftp sem tls fica fácil interceptar a comunicação com sniffer e roubar as chaves.
Acho melhor criar um tópico com assunto LGPD, Scriptcase e banco de dados ou mudar o assunto desde, pois vai muito além de criptografar somente o banco para sistemas PHP com SGDB.
2 Curtidas
Hroldo, necessito sim e até com uma certa urgência. São alguns campos de uma tabela, e que não são campos índice.
Alexandre, fantástica sua explanação. O fato é realmente dar uma camada de segurança a mais e atender o Capítulo citado. Será apenas para alguns campos referentes a dados pessoais, o mínimo possível, já que outros campos que ficarão sem a criptografia estariam anonimizados. Os outros níveis de segurança já estão sendo tratados.
Vai ter que usar controle e tabelas temporárias.
Fazer a criptografia via php, pode ser funções especificas ou na própria aplicação.
Formulário de Controle, antes de carregar os campos descriptografa os dados. Antes de salvar Criptografa.
Consulta, ler a tabela criptografada, salvar os dados em tabela temporária, carregar a consulta na tabela temporária.
1 Curtida
A LGPD não pede nada disso, coloque uma senha forte no BD e resolvido o seu caso.
1 Curtida
E alem de criptografar a base de dados não esqueça de compilar o código do PHP também, tornando ele ilegível, já pensou se na hospedagem acessam seu código e roubam ele e pegam a função de criptografia que você fez, tem que proteger também claro:
https://www.ioncube.com/
e se raptarem os programadores?
Gente desculpe o comentário, mas é insano e improdutivo criptografar os registros do bd sabendo que o banco possui medidas de segurança.
3 Curtidas