Webapp multi user - safety best practice
De bedoeling is om o.a. artikels aan te maken , offertes, facturen,...
Nu wanneer je dit enkel voor jezelf zou doen opteer ik voor 1 database met alle artikelen.Maar wanneer elk klant zijn eigen artikelen in het systeem kan aanmaken en wenselijk er geen mengelmoes ontstaat had ik graag een database per klant aangemaakt indien dit al een goede manier zou zijn.
// Veiligheid ( BIG ISSUE )
Vervolgens vraag ik mij af of ik in plaats van de gekende manier van inloggen index.php -> login.php, beter gebruik maak van verschillende API als lagen die werken om het bronbestand niet vrij te geven mocht men toch binnen geraken...
Er is zoveel te doen rond veiligheid dat ik geen zin heb om aan 100+ klanten uit te leggen dat de app gehackt is en de gegevens de loop hebben genomen.
Hoe denken jullie hierover?Wat zou jij doen in het kader van veiligheid en opzet van een webapp?
Alvast bedankt.
En ik neem aan dat je alle achterliggende code zelf host? Daar hoeven klanten ook niet bij te komen.
Als je dan zorgt dat ELKE query die je opbouwt ALTIJD WHERE klant_id = $klant_id bevat, dan kan hij niet aan de andere data komen.
(en let ook op bij query's die over meerdere tabellen gaan met een join)
Losse tabellen of zelfs databases zijn best wel niet-onderhoudbaar.
1. Row Level Security (RLS): binnen dezelfde database heb je per (applicatie-)account een andere set rijen. Dat werkt door op elke tabel een kolom bij te voegen met de accountnaam, met een constraint dat die moet matchen met de huidige account
2. Scheiding in schema's (MariaDB, MySQL) en/of clusters (PostgreSQL): je hebt dan meerdere databases, al dan niet met postfixes in de schemanaam, maar wel binnen dezelfde instantie van de database server (software). Een cluster gaat nog net iets verder, dan heb per database met 1 of meer schema's een eigen instantie van de database server
3. Scheiding van systemen, dan trek je het volledig uit elkaar. Kan je doen door elke klant een eigen VPS te geven. Het hangt af van de omzet en de risico's of je zo ver moet gaan, maar het kan wel. Geeft wel wat meer overheadkosten.
Als je het bronbestand niet weg wil geven zijn er twee mainstream opties: SaaS, of geen SaaS maar dan met encryptie van de code, bijvoorbeeld met IronCube of SourceGuardian. In het geval van SaaS ben je wel verwerkingsverantwoordelijk, in het andere geval loop je meer risico met license overuse.
Het veiligst is om de software van goede kwaliteit te laten zijn, zie hiervoor alle Cheat Sheets van OWASP: https://cheatsheetseries.owasp.org/IndexTopTen.html
Bouw goede beveiliging in, maak je webapp MFA, en het beste is om alles zoveel mogelijk te scheiden. Maak alleen gebruik van de laatste encryptietechnologie (TLS 1.3 met EC-curve, met curves conform advies NCSC.nl)
Als je dat alles doet, zit je behoorlijk veilig.
De klanten zullen de mogelijkheid krijgen om offertes en facturen te maken via de app alsook beheer van zijn/haar projecten.
Daarom is het van cruciaal belang dat de gegevens niet verdwijnen of misbruikt worden.
Misbruik van informatie zoals weten hoeveel omzet en met welke materialen concurrenten werken + aankoopprijzen enz.
Uiteraard zal ik er alles aan doen om in de eerste plaats alles zo veilig mogelijk te doen verlopen en daarom ook mijn vraag naar jullie toe.
Indien ik één database gebruik en telkens een WHERE clause dien te gebruiken gaat dit op termijn niet veel vertragingen opleveren? Elke klant kan immers zijn eigen artikelen aanmaken.
Ik maak mij voornamelijk zorgen dat wanneer men toch ergens binnen geraakt ze meteen ook alles hebben.
Ik kan immers niet vermijden om het wachtwoord van de database in de broncode te zetten. Ik kan de schrijfrechten in de hoofdmap van de API wel veranderen.
@ Arien
Beheer van meerdere databases is een grote uitdaging en deze denkpiste zal ik dan ook wijselijk verlaten.
** quoteknip**
Gewijzigd op 23/10/2022 15:05:43 door - Ariën -
Laat een externe audit uitvoeren!!!
Bart Smulders op 23/10/2022 14:38:47:
Daarom is het van cruciaal belang dat de gegevens niet verdwijnen of misbruikt worden.
Misbruik van informatie zoals weten hoeveel omzet en met welke materialen concurrenten werken + aankoopprijzen enz.
Misbruik van informatie zoals weten hoeveel omzet en met welke materialen concurrenten werken + aankoopprijzen enz.
Als je verantwoording van de gegevens nodig hebt, is het logischer om een audit trail aan te leggen die forensisch sluitend is. Bij PostgreSQL heb je daarvoor pgAudit. Een generieke, meer gebruikte tactiek is om elke tabel te voorzien van triggers en aanpassingen weg te schrijven naar een logtabel (evt. in een ander schema). Op de logtabellen zit dan natuurlijk geen schrijfrechten voor je webapp. Dan kun je de logbestanden monitoren en zelf of via een SIEM-oplossing kijken of er rare dingen mee gebeuren.