[vraag] in hoeverre loggen wat user/mod/admin doet?

[Jboy1991]

Goedendag,

Ik ben bezig met een eigen loginsysteem. Nu heb ik het registreren,activeren,account aanpassen etc af.

Alleen nu zit ik met een vraag aan mensen die zelf zon systeem gemaakt hebben of beheren.

In hoeverre is het van belang dat er wordt bijgehouden wat een user mod of admin doet? Ik neem aan dat het vrij logisch is dat je in een database bijhoudt als een admin een user wijzigt dat dat opgeslagen wordt in de database zodat het altijd terug gezien kan worden welke admin het deed en waarom.

Maar hoever trekken jullie dit door? En hoe kan je dit het beste loggen?

[gedonie]

Hoe je dit in de praktijk moet doen hangt sterk af van welke backend taal je gebruikt, welke frameworks je daarbinnen gebruikt en hoe je die toepast.

Wat je zoekt, vermoed ik, is een audit trail van wijzigingen op je data. Dit kun je op meerdere manieren bereiken. De makkelijkste, maar ook duurste qua opslag, is de data bij iedere mutatie dupliceren in een audit tabel en daarbij vastleggen wie het heeft gedaan.

Een wellicht elegantere manier is enkel de wijzigingen ten opzichte van de vorige stand van zaken in de database vast te leggen in een audit tabel, met daarbij de gebruiker en datum van wijziging.

Over je vraag hoever je dit moet doorvoeren ben ik bang dat er geen goed antwoord is. Het hangt met name af hoe belangrijk het is dat zichtbaar is welke wijzigingen wanneer en door wie worden gedaan. Je kunt je voorstellen dat bij basis gegevens van een gebruiker dat minder belangrijk is dan bij bijvoorbeeld de meta data van een product in een webwinkel. Je moet vooral per model in je applicatie bekijken of het meerwaarde en belang heeft.

[Jboy1991]

gedonie schreef op vrijdag 5 mei 2017 @ 14:29:
Hoe je dit in de praktijk moet doen hangt sterk af van welke backend taal je gebruikt, welke frameworks je daarbinnen gebruikt en hoe je die toepast.

Wat je zoekt, vermoed ik, is een audit trail van wijzigingen op je data. Dit kun je op meerdere manieren bereiken. De makkelijkste, maar ook duurste qua opslag, is de data bij iedere mutatie dupliceren in een audit tabel en daarbij vastleggen wie het heeft gedaan.

Een wellicht elegantere manier is enkel de wijzigingen ten opzichte van de vorige stand van zaken in de database vast te leggen in een audit tabel, met daarbij de gebruiker en datum van wijziging.

Over je vraag hoever je dit moet doorvoeren ben ik bang dat er geen goed antwoord is. Het hangt met name af hoe belangrijk het is dat zichtbaar is welke wijzigingen wanneer en door wie worden gedaan. Je kunt je voorstellen dat bij basis gegevens van een gebruiker dat minder belangrijk is dan bij bijvoorbeeld de meta data van een product in een webwinkel. Je moet vooral per model in je applicatie bekijken of het meerwaarde en belang heeft.

Oh ja sorry het gaat over php -> mysql

Nja de reden is dat stel een user gehackt wordt moet ik daar als aanbieder van een login systeem dan wat mee. Ik zal kunnen bijhouden dat elke keer dat een user ingelogd het ip waarvan de login plaatst vindt op te slaan in een db. Maar als ik dat voor elke user moet doen ben ik enorm veel tables kwijt in de database. Of ik moet elke maand de database leeg gooien en wat erin staat naar toe mailen.

Maar daarom vraag ik in hoeverre ben ik verplicht te loggen.Als een user zijn mail veranderd heb ik bijv al een manier gedaan dat er naar het oude mailadres een code gestuurd wordt. Puur om te checken of die gene echt de persoon is die de wijziging doorvoert.

Ik denk dat het voor mijzelf het beste is dat ik alleen log welke actie een mod of admin uithaalt. Puur om mocht er iets mis gaan dat ik kan achterhalen door wie

[Stoelpoot]

Jboy1991 schreef op vrijdag 5 mei 2017 @ 14:41:
[...]
Ik zal kunnen bijhouden dat elke keer dat een user ingelogd het ip waarvan de login plaatst vindt op te slaan in een db. Maar als ik dat voor elke user moet doen ben ik enorm veel tables kwijt in de database. Of ik moet elke maand de database leeg gooien en wat erin staat naar toe mailen.

Als je nou alles in 1 tabel zet met de user id erbij? Zo veel gaat dat niet kosten. Als het de spuigaten uit zo lopen, zou je evt een geautomatiseerd script laten runnen die elke x maanden die tabel leeggooit.

Maar zeker als je cookie-based gaat inloggen (dus de volgende dag gewoon verder kunnen) gaan daar helemaal niet zo veel records in zitten.

Vraagje trouwens, waarvoor ben je je eigen login systeem aan het uitrollen? In de praktijk is dat geen heel goed idee. Als je het voor studie / zelfstudie doet is het natuurlijk wel hartstikke leerzaam!

[Jboy1991]

rikpro schreef op vrijdag 5 mei 2017 @ 14:55:
[...]
Vraagje trouwens, waarvoor ben je je eigen login systeem aan het uitrollen? In de praktijk is dat geen heel goed idee. Als je het voor studie / zelfstudie doet is het natuurlijk wel hartstikke leerzaam!

Waarom zal het geen goed idee zijn? Ik werk met pdo en dubbel check alle inputs. Ook gebruik ik encrypted passwoords en komt er een ssl verbinding Dus zie niet in waarom ikzelf geen eigen login zal kunnen maken

Deze vraag stel ik hier enkel om te kijken wat voor meerden het heeft of dat ik het zelfs verplicht ben qua wetgeving.

[NMe]

Jboy1991 schreef op vrijdag 5 mei 2017 @ 14:41:
enorm veel tables kwijt

Tables kwijt? Hoezo? Het zou gewoon één table zijn? Wat je wil loggen is het user-ID van degene die de wijziging doet, het ID van de entity die aangepast wordt ("User", "Post", "Topic", etc. in het geval van bijvoorbeeld een forum) en een stringrepresentatie van het type van die entity. En natuurlijk een omschrijving van de actie/wijziging, een timestamp en eventueel een IP. Dan heb je al je audit logs in één makkelijk te filteren tabel staan.

[Gomez12]

Jboy1991 schreef op vrijdag 5 mei 2017 @ 14:59:
[...]

Waarom zal het geen goed idee zijn? Ik werk met pdo en dubbel check alle inputs. Ook gebruik ik encrypted passwoords en komt er een ssl verbinding Dus zie niet in waarom ikzelf geen eigen login zal kunnen maken

Waarom het geen goed idee zal zijn is voornamelijk omdat ik vermoed dat je niet de schrijver van pdo bent, noch van je encryptie functie en al helemaal niet van het principe ssl.

Je pakt die dingen juist over omdat die zich al bewezen hebben in de praktijk en het jou gewoon een shitload aan bugs oplossen scheelt.

[Stoelpoot]

Jboy1991 schreef op vrijdag 5 mei 2017 @ 14:59:
[...]

Waarom zal het geen goed idee zijn? Ik werk met pdo en dubbel check alle inputs. Ook gebruik ik encrypted passwoords en komt er een ssl verbinding Dus zie niet in waarom ikzelf geen eigen login zal kunnen maken

Deze vraag stel ik hier enkel om te kijken wat voor meerden het heeft of dat ik het zelfs verplicht ben qua wetgeving.

Als je je wachtwoorden encrypt, kan je beter stoppen Verder kan je checken tot je een ons weegt, maar als je niet op de juiste manier checkt help het ook niet. Verder zijn er met wachtwoordresets ook meer gevaren dan er Arabische nachten zijn. Wat gebeurd er tenslotte als je een ander wachtwoordhashing algoritme gaat gebruiken? Etc etc etc.

Mensen maken er hun fulltime baan van dit soort systemen veilig te krijgen en te houden. Als je productie systemen wilt gaan maken, kan je je beter daarop focussen dan zelf het wiel opnieuw uit te vinden.

[Jboy1991]

Gomez12 schreef op vrijdag 5 mei 2017 @ 15:09:
[...]

Waarom het geen goed idee zal zijn is voornamelijk omdat ik vermoed dat je niet de schrijver van pdo bent, noch van je encryptie functie en al helemaal niet van het principe ssl.

Je pakt die dingen juist over omdat die zich al bewezen hebben in de praktijk en het jou gewoon een shitload aan bugs oplossen scheelt.

Klopt ben niet de schrijven van pdo. Dit is namelijk een Mysql verbinding tussen php en myqslserver (http://php.net/manual/en/ref.pdo-mysql.php).

Ook van de encrypt ben ik niet de schrijver dit is een phpfunctie: password_hash($pass, PASSWORD_BCRYPT)

Ook schrijf ik dus wel de site vanaf base met framework bootstrap. Dit omdat ik niet afhankelijk wil zijn van patches maar het zelf compleet wil maken.

Best jammer dat hier zo negatief tegen aan wordt gekeken. Ik maak de site juist omdat het uniek is en ik niet afhankelijk wil zijn van wat de hoofdontwikkelaar mij te bieden heeft. Daarnaast hoorde je vroeger juist van dat bijv phpbb gehackt werd door simpele sql injections. Dus in hoeverre kan je dat vertrouwen?

[ Voor 15% gewijzigd door Jboy1991 op 05-05-2017 15:17 ]

[NMe]

Ik denk dat het nuanceverschil hier vooral ligt in: maak je een loginservice en is dat je hele product? Of is die login gewoon deel van een groter geheel, bijvoorbeeld een communitysite of iets dergelijks?

In het eerste geval zou ik er niet aan beginnen tenzij je het vooral doet om ervan te leren aangezien er al prima OAuth-providers zijn met een goeie staat van dienst. In het laatste geval is er geen enkel probleem met zelf je eigen login en userbeheer doen.

[Jboy1991]

NMe schreef op vrijdag 5 mei 2017 @ 15:20:
Ik denk dat het nuanceverschil hier vooral ligt in: maak je een loginservice en is dat je hele product? Of is die login gewoon deel van een groter geheel, bijvoorbeeld een communitysite of iets dergelijks?

In het eerste geval zou ik er niet aan beginnen tenzij je het vooral doet om ervan te leren aangezien er al prima OAuth-providers zijn met een goeie staat van dienst. In het laatste geval is er geen enkel probleem met zelf je eigen login en userbeheer doen.

Ah dat zal het kunnen verklaren inderdaad. Maar het betreft dus het laatste. Het is een login systeem waarbij users een eigen profiel hebben (logische) en een forum Zodat mensen die een bepaalde game spelen elkaar makkelijker kunnen vinden.

Maar ik had niet door dat dit relevant kan zijn op mijn vraag. Ik weet dus nog steeds niet in hoeverre ik verplicht ben qua wetgeving om alles te loggen. Bepaalde zaken lijken mij vrij logisch voor de eigen ''administratie''. Maar is het bijv van belang om bij te houden wat erin het topic/reactie stond voordat het gewijzigd werd.

-update-
En daarnaast is het voor eigen gebruik dus niet voor verkoop.

[ Voor 20% gewijzigd door Jboy1991 op 05-05-2017 15:29 ]

[DaCoTa]

Jboy1991 schreef op vrijdag 5 mei 2017 @ 15:22:
[...]

Ah dat zal het kunnen verklaren inderdaad. Maar het betreft dus het laatste. Het is een login systeem waarbij users een eigen profiel hebben (logische) en een forum Zodat mensen die een bepaalde game spelen elkaar makkelijker kunnen vinden.

Maar ik had niet door dat dit relevant kan zijn op mijn vraag. Ik weet dus nog steeds niet in hoeverre ik verplicht ben qua wetgeving om alles te loggen. Bepaalde zaken lijken mij vrij logisch voor de eigen ''administratie''. Maar is het bijv van belang om bij te houden wat erin het topic/reactie stond voordat het gewijzigd werd.

-update-
En daarnaast is het voor eigen gebruik dus niet voor verkoop.

Wat zou het doel zijn van logging/audit trails/tracing? Is er iets wat jij of een gebruiker zou kunnen doen aan de hand van die logging? Want als het niet actionable is, heb je niks aan de logs.

[Jboy1991]

DaCoTa schreef op zaterdag 6 mei 2017 @ 01:03:
[...]

Wat zou het doel zijn van logging/audit trails/tracing? Is er iets wat jij of een gebruiker zou kunnen doen aan de hand van die logging? Want als het niet actionable is, heb je niks aan de logs.

Nja ik heb dus 1account die Superadmin is. Dit houdt ik dat dit account nooit gewijigd kan worden door derden en veel meer kan inzien dan de gewone admin of mod

Gewone admin kan ook nooit een mede admin wijzigen maar wel een mod of user

Een mod kan dus alleen een user wijzigen etc

Nu wil ik een simpele forum maken maar daarbij moet onaangenaam gedraag gewijzigd kunnen worden. Echter als een mod bijv iets ongenaam vindt is het maar de vraag of admin het daarmee eens is.

In zon geval zal het ideaal zijn dat een admin deze actie kan omdraaien maar ook kan zien welke userid deze wijziging heeft gedaan en waarom (evt notitie erbij ).


Hiervoor lijkt mij het handig dat er een log plaatst vindt zodat wijzigingen die verkeerd beoordeeld zijn. Terug gezet kan worden.


Qua wetgeving:
Stel een account wordt gehackt en die persoon doet aangifte. Aan mij als aanbieder ben ik neem ik aan verplicht mee te werken. Alleen wanneer ik geen logs heb zal ik dus niet kunnen helpen dmv het achterhalen van het laatst ingelogde ip. Dus in zoverre de vraag of ik het verplicht ben bij te houden uit juridisch oogpunt

[Thijsmans]

Mij is geen wet bekend op grond waarvan je als aanbieder van een dienst verplicht bent zulke gegevens bij te houden. Andersom geldt wel dat hoe meer je bijhoudt, hoe meer verantwoordelijkheid je daarvoor draagt. Daarbij denk ik bijvoorbeeld aan de meldplicht bij datalekken voor organisaties.

Praktisch gezien, is het wellicht handig om - zoals NMe ook al aangeeft - een revisie-tabel te maken, waarin tijd, user-id, IP-adres, aanduiding van het type van de bewerkte entiteit, id van die entiteit en de relevante data worden opgeslagen. Voorbeeld:

code:

1494415362  |  100  |  127.0.0.1  |  post  |  500  |  { message : "dit is de fipo" }

Je tabel met forum-posts zou dan een entry bevatten waarin niet de post zelf staat, maar wel de corresponderende post-id (500, in dit geval). Je kunt er natuurlijk ook voor kiezen de initiële post (of andere entiteit) wél in de eigen tabel op te slaan, en bij het ophalen van de post eventuele revisies daarover plaatsen. De revisietabel kun je natuurlijk ook gelijktijdig vullen met info over bewerkte users (met een user-id, en bijvoorbeeld data "{ username: Thijsmans, email: me@localhost }"), topics, etc. Voordeel is dat je dan, zoals je zegt, alles makkelijk kunt rollback'en.

Hoewel het schrijven van een forum waarschijnlijk in het "CV" van iedere scriptkiddo (/me ) en developer staat, zou ik tegenwoordig zeggen: gebruik bestaande software waarbij de revisies automatisch worden bijgehouden...

[Hydra]

Het is niet erg gangbaar dit in dezelfde tabel te doen als waar een admin sowieso al toegang op heeft. Het idee van een audit log (dit is de gangbare term hiervoor) is dat deze immutable is: entries kunnen niet door iemand aangepast worden. Nu is dat voor een simpel systeem misschien overkil maar dit geeft ook wel aan waarom het nuttig is om gewoon in eerste instantie gewoon een logfile te gebruiken en dit niet in de DB op te slaan; je wil de audit logs over het algemeen erg lang bewaren. Ik werk zelf bij een grote bank en daar wordt eigenlijk alles op een dergelijke manier gelogged en jaren bewaard.

Je kunt in specifiek jouw geval dus inderdaad kiezen om oude versies van posts bij te houden in de database maar je kunt ook voordat je de update doet de vorige versie in een logfile wegschrijven.

[TRON]

'k Ben aan het experimenteren op SQL-niveau. Een update van bepaalde tabellen triggert een 'trigger' () met die trigger wordt de updatedatum, oude waarden en nieuwe waarden + ingelogde user (non-SQL) weggeschreven in een audit-tabel, behorende bij de tabel waarin iets gewijzigd wordt.

Tot nu toe werkt dat voor zover ik kan zien goed.