Webapp multi user - safety best practice

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Top Low-Code Developer Gezocht!

Bedrijfsomschrijving Unieke Kansen, Uitstekende Arbeidsvoorwaarden & Inspirerend Team Wij zijn een toonaangevende, internationale organisatie die de toekomst van technologie vormgeeft door het creëren van innovatieve en baanbrekende oplossingen. Ons succes is gebaseerd op een hecht en gepassioneerd team van professionals die altijd streven naar het overtreffen van verwachtingen. Als jij deel wilt uitmaken van een dynamische, vooruitstrevende en inspirerende werkomgeving, dan is dit de perfecte kans voor jou! Functieomschrijving Als Low-Code Developer ben je een cruciaal onderdeel van ons team. Je werkt samen met collega's uit verschillende disciplines om geavanceerde applicaties te ontwikkelen en te optimaliseren met behulp van Low-code

Bekijk vacature »

Bart Smulders

Bart Smulders

19/10/2022 21:43:45
Quote Anchor link
Bij het nadenken over wat de beste manier zou zijn om de veiligheid te garanderen voor mijn webapp kom ik er niet uit.
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.
 
PHP hulp

PHP hulp

06/12/2024 02:00:01
 
- Ariën  -
Beheerder

- Ariën -

20/10/2022 00:46:47
Quote Anchor link
Hoe ga je met de structuur van een database per klant, updates uitvoeren en de integriteit van talloze bewaken? En wat is volgens jou het probleem van een mengelmoes?

En ik neem aan dat je alle achterliggende code zelf host? Daar hoeven klanten ook niet bij te komen.
 
Ivo P

Ivo P

20/10/2022 09:40:27
Quote Anchor link
in je api weet je welke klant het is.

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.
 

20/10/2022 11:03:17
Quote Anchor link
Er zijn meerdere manieren om een database in verschillende compartimenten op te delen:

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.
 
Bart Smulders

Bart Smulders

23/10/2022 14:38:47
Quote Anchor link
Dank voor je uitgebreide korte uiteenzetting :)

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 -
 
- Ariën  -
Beheerder

- Ariën -

23/10/2022 15:05:02
Quote Anchor link
Het belangrijkste als je data van cruciaal belang is:

Laat een externe audit uitvoeren!!!
 

24/10/2022 11:53:23
Quote Anchor link
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.

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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.