Page 3 of 3 FirstFirst 1 2 3
Results 31 to 41 of 41

Thread: Avg

  1. #31
    Although under the GDPR encryption is not mandatory, it is certainly important to see where and why encryption is advised.
    GDPR compliance, as we wrote before is a business strategy challenge and encrypting personal data STRICTLY SPEAKING is not mandatory.
    Voor een creditcardnummer, bsn-nummer of andere echt gevoelige informatie kan ik me encryptie nog wel voorstellen. Maar ik heb alleen persoonsnaam, telefoon en een e-mail adres in mijn bestanden staan. Daar ga ik echt niet speciaal encryptie op toepassen.

  2. #32
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,308
    Quote Originally Posted by Marcel View Post
    Heb jij een lokale kopie van NLDelphi die nog niet over https gaat?
    Je heb gelijk. Heb het niet eens opgemerkt.
    Delphi is great. Lazarus is more powerfull

  3. #33
    @Marcel, Werkt niet altijd.
    Last edited by GolezTrol; 18-May-18 at 10:34.
    1+1=b

  4. #34
    Het hangt er ook erg vanaf hoe serieus je beveiliging wilt en kunt nemen en of je het je kunt veroorloven dat er data lekt. Bij de gegevens van de voetbalvereniging is dat net weer even anders dan bij een bedrijf met tienduizenden regels adresgegevens. Ik heb ook klanten die het juist als argument gebruiken dat ze hun zaakjes extra goed voor elkaar hebben, dus als de klant dat wil dan regel ik dat voor ze.

    Quote Originally Posted by rvk View Post
    Voor een creditcardnummer, bsn-nummer of andere echt gevoelige informatie kan ik me encryptie nog wel voorstellen. Maar ik heb alleen persoonsnaam, telefoon en een e-mail adres in mijn bestanden staan. Daar ga ik echt niet speciaal encryptie op toepassen.
    Marcel

  5. #35
    Ik hang toch ook een beetje naar de aanpak van Rik. Met alleen versleutelen van een database ben je er ook niet. Ook bv een map met PDF bestanden van facturen of brieven bevat pricacy gevoelige info. Die zul je dus ook extra moeten beveiligen en voorzien van een audit mogelijkheid.

    Verder denk ik dat het encrypten van een database een hele slechte keuze is. De optimizers en indexing engines in de DB server zijn gemaakt om hun werk te doen op zinnige data. Data die encrypted is is per definitie niet zinnig. Je DB ontwerp zelf zal in de basis dus ook op de schop moeten omdat indexen zetten zoals we gewend zijn nutteloos is geworden en performance dus een drol zal worden.

    Voorlopig kies ik dan ook voor het versleutelen van bepaalde velden (BSN, geboortedatum e.d.), iets wat relatief simpel kan als je alle data toegang laat lopen via middleware.

  6. #36
    Wel even inlezen in de materie Benno, je reactie is te kort door de bocht. Met encryptie op kolom niveau heb je gelijk, dan is zoeken en sorteren niet meer mogelijk. Met Transparent Data Encryption wordt je database transparent encrypted (hence the name ) alle indexen, zoekfuncties en sorteringen blijven dus gewoon werken zoals je bent gewend. Dit is ook de encryptie die DbDefence je biedt.

    En inderdaad, ook de bestanden die buiten de database worden opgeslagen heb ik encrypted.

    Ik geef meteen toe dat het vel werk is, maar dat geldt voor elk project waar beveiliging belangrijk is. Maar dan heb je ook een klant die daarvan doordrongen is, dus dan is het ook makkelijk uit te leggen dat dit tijd en dus geld kost.

    Quote Originally Posted by Benno View Post
    Ik hang toch ook een beetje naar de aanpak van Rik. Met alleen versleutelen van een database ben je er ook niet. Ook bv een map met PDF bestanden van facturen of brieven bevat pricacy gevoelige info. Die zul je dus ook extra moeten beveiligen en voorzien van een audit mogelijkheid.

    Verder denk ik dat het encrypten van een database een hele slechte keuze is. De optimizers en indexing engines in de DB server zijn gemaakt om hun werk te doen op zinnige data. Data die encrypted is is per definitie niet zinnig. Je DB ontwerp zelf zal in de basis dus ook op de schop moeten omdat indexen zetten zoals we gewend zijn nutteloos is geworden en performance dus een drol zal worden.

    Voorlopig kies ik dan ook voor het versleutelen van bepaalde velden (BSN, geboortedatum e.d.), iets wat relatief simpel kan als je alle data toegang laat lopen via middleware.
    Marcel

  7. #37
    Ik heb die site van je bekeken. Je encryptie kan wel transparant zijn t.o.v. de client, maar de interne routines op de dbserver draaien dan toch met encrypted content? Indexen zijn dan nutteloos geworden, net als optimizers in de db engine. Die db engine heeft immers geen kennis meer van relevante content.

    Vanuit de client is het allemaal transparant, dat volg ik nog wel. Maar indexen en optimalisaties draaien niet op de client maar op de db server.

  8. #38
    Als het zou gaan om simpelweg wat kolommen encrypten zou je helemaal gelijk hebben, maar deze techniek gaat veel verder. Zo kun je bijvoorbeeld een bepaald proces (alleen jouw software) toegang geven tot de database, of alleen een bepaalde gebruiker. En zoals je hieronder ziet, je indexen blijven gewoon hun werk doen.

    Click image for larger version. 

Name:	2018-05-19 11_06_53-SQLQuery1.sql - HIRO.CursusDb (HIRO_marce (56))_ - Microsoft SQL Server Mana.png 
Views:	12 
Size:	15.5 KB 
ID:	7770
    Marcel

  9. #39
    Marcel,

    dat begrijp ik. Ik heb de software niet gedownload of getest dus mogelijk heb ik het mis.

    Waar het mij om gaat is dat de db engine verantwoordelijk is voor het indexeren. Indexeren heeft alleen nut voor zinnige data. Als ik de beschrijving en uitleg op die site lees is het een tool die op sql server ligt en zorgt voor encryptie en decryptie (voor geldige processen of gebruikers).

    De enige manier waarop dit zou kunnen werken is als de logica voor het indexeren en de query optimizers (het plan) is vervangen door hun eigen code en dus feitelijk geen gebruik meer maakt van sql server.

    Dat laatste heb ik ernstig mijn twijfels bij.

  10. #40
    Ik denk niet dat dat de enige manier is. Maar dat is het voordeel van iets kopen dat het probleem voor me oplost, ik hoef het wiel niet zelf uit te vinden. Het is een pittige aanschaf, maar ik weet ook dat ik het voor dat bedrag zelf niet kan bouwen.
    Marcel

  11. #41
    tja dat is de aard van het beestje ik probeer dat soort dingen uit te denken, terwijl 90% van de databases te klein is om er last van te hebben.

    Ben gisteren nog wat aan het googlen geweest op die tool, maar het blijft allemaal een beetje vaag.

    Succes met de laatste loodjes naar de 25e.

Page 3 of 3 FirstFirst 1 2 3

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •