Archief - Vertrouwelijke gegevens

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
s

sarnath

Legacy Member
Ik heb een vraagje in verband met vertrouwelijke gegevens.
Ik heb namelijk voor een kinesist een tijdje geleden een website ontwikkeld die gebruik maakt van een kalender waarop men kan zien of hij beschikbaar is of niet.

De bedoeling is echter dat het mogelijk moet worden dat mensen zelf een afspraak kunnen inplannen.
Hierbij geven ze dan ook de reden op van hun bezoek.

Aangezien ik dus ook graag backups had gemaakt van de database wil dat dus zeggen dat ik toegang heb tot deze gegevens.
Dit wil ik echter niet gezien het natuurlijk op privacy gaat en alleen de kinesist zelf dit mag zien.

Hoe gaat dit precies in zijn werk? Heeft iemand hiermee ervaring? Ik wil de applicatie namelijk graag afwerken, maar wil hiermee absoluut niet in de problemen komen...
d

dJeez

Legacy Member
Encrypteer de gevoelige data dan met een paswoord dat enkel de kinesist zelf kent. Dan kan jij ze zelf niet lezen, maar zonder enig probleem backups/restores van de db doen.
s

sarnath

Legacy Member
Ik had al aan encryptie gedacht, maar als je de data encrypteert met een paswoord dat enkel de kinesist kent, dan kan je dat toch niet opvragen zodra een afspraak wordt ingegeven?

Dus stel : insert voornaam, achternaam, datum, reden

dan heb je toch bij de insert de passkey voor je encryptie nodig (die enkel de kinesist kent).
Dus dan moet ik die toch ergens vandaan halen?
g

goldenglobe

Legacy Member
als je het juist via php insteld is daar geen probleem mee normaal hoor...
s

sarnath

Legacy Member
Maar dan zitten we al aan het logingedeelte, dus met andere woorden het decrypteren.

Het probleem is net dat ik de key ook nodig heb om het te encrypteren.

workflow:

->persoon maakt afspraak -> reden wordt geencrypteerd met een key
->kinesist haalt afspraak op -> reden wordt gedecrypteerd met dezelfde key
S

Scrimrage

Legacy Member
ge kunt toch perfect ne gebruiker maken die alles kan, en 1 die alleen kan schrijven.

Voor te tonen of hij beschikbaar is of niet, heb je niet al de details nodig.
Dus kunde uw gegevens opsplitsen in 2 tabbellen, met ne link tussen.
En op de gevoelige geefde de registratie-user alleen schrijfrechten.

(of vergis ik me nu :unsure:)
l

lykmeraid

Legacy Member
Maak gewoon MD5 hashes van de data die ge wilt encrypteren en schrijf die weg naar de database?

De kinesist heeft dan (als enige) de key om de data in de database te decrypteren.
d

dJeez

Legacy Member
lykmeraid zei:
Maak gewoon MD5 hashes van de data die ge wilt encrypteren en schrijf die weg naar de database?

De kinesist heeft dan (als enige) de key om de data in de database te decrypteren.
Klik om te vergroten...
Leer het verschil tussen een hash (onomkeerbaar) en encryptie (wel omkeerbaar) eens :p.

@sarnath: Oeps, blijkbaar had ik er dus over gelezen dat de bezoekers zelf hun afspraak maakten. Een public/private key gebruiken is in dat geval inderdaad een mogelijke oplossing. De kinesist genereert een key pair en bezorgt u daarvan de public key. Dan encrypteer jij de data daarmee en kan hij met de private key gaan decrypteren. Het probleem daarbij is dan wel dat de gebruiker zijn eigen data niet meer kan consulteren eens ze zijn opgeslagen (en dat de kinesist steeds die private key opnieuw moet doorgeven aan de applicatie telkens hij de data wil consulteren). Maar dat is misschien niet echt onoverkomelijk in dit geval.
s

sarnath

Legacy Member
Inderdaad dJeez, ik moet het nog eens allemaal bekijken, ook hoe het zit met wettelijke bepalingen etc..want zomaar met doktersgegevens werken is sowieso delicaat.

bedankt voor de info :)
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan