SAAS ontwikkeling: performance vs ISO 27001 in achterhoofd

[Erpenator2]

Voor een advies ben ik op zoek naar best practices voor het ontwikkelen van een SAAS waarbij schaalbaarheid, performance en beveiliging conform de ISO 27001 normering belangrijk zijn.

Er zijn een aantal ideeën op tafel gelegd waarbij ik mij afvraag hoe (grote) andere partijen dat doen. Zo is de wens om voor iedere klant een aparte database aan te maken zodat klantgegevens gescheiden blijven. Met het idee is dat dit veiliger is en beter schaalbaar. Wat applicatie ontwikkeling zal het mogelijk lastiger zijn omdat je in theorie met verschillende versies van de database kan komen te zitten per klant.

Daarnaast is het plan om een algemene database voor toegangsrechten (lees inloggen, rechten tot de applicatie), een database logging, en een database voor policies waarbij ik aanneem dat deze wensen vanuit de ISO normering komen en daarnaast met het idee dat dit de applicatie schaalbarer maakt. Vanuit die uitgangspunten zullen er meerdere connecties opgebouwd moeten worden naar al deze verschillende databases. Maar uit ervaring heb ik geleerd dat het opbouwen van een databaseconnectie relatief gezien veel performance kost, laat staan naar 5 of meer verschillende databases. Vanuit schaalbaarheid zou ik zeggen dat meer CPU cores / geheugen of andere hardware matige oplossingen voldoende zouden moeten zijn i.p.v. losse databases op verschillende servers. Dit o.a. met netwerk latancy in het achterhoofd. Maar waar de limiet ligt weet ik niet.

Daarnaast is het de bedoeling om de data in de de databases te encrypten, zodat wanneer er toch oneigenlijk toegang is verkregen tot de database de data waardeloos is zonder key. De key voor de encryptie moet in de applicatie komen om bij iedere insert de data te encrypten. De wens voor encryptie van de data kan ik goed begrijpen, maar kom dit nu nog zelden tegen bij andere projecten of applicaties. Daarnaast lijkt het mij veiliger om data door het OS of door de database software zelf te laten doen, dan zelf wat te ontwikkelen. Sowieso heeft encryptie best wat praktische uitdagingen, zoals lastiger kunnen zoeken in de database en een performance cost voor en-decrypten. Wat is een goede oplossing voor encryptie?

Daarmee komt de vraag naar voren hoe grote partijen als bijvoorbeeld Exact de software per klant opzetten om de software schaalbaar te maken en welke veiligheidsmaatregelen zou zo'n partij nemen om al dan niet aan deze ISO normering te voldoen? De ISO normering geeft volgens mij geen concrete requirements alleen richtlijnen dus dat geeft in ieder geval wel flexibiliteit.

[Cartman!]

Even los van techniek, bij ISO 27001 bepaal je als organisatie zelf wat de risicos zijn en of en hoe je daar mee om gaat. ISO 27001 zelf dicteert niet dat je moet encrypten of hoe je dit zou moeten doen.

Sommige dingen moet je ook praktisch bekijken, als je ergens een lek hebt dan kan een aanvaller alsnog bij die databases komen of t er nu 1 is of 10.

Zelf doe ik encryptie met AES256 met een key per user zowel met oog op security als de AVG/GDPR. De event log bevat alleen encrypted data en die kunnen we decrypten zolang de key bestaat. Als een gebruiker de account verwijderd wil hebben dan verwijderen we het user record incl key en zijn de huidige gegevens weg en kunnen historische logs niet meer decrypt worden. Voor analytics doeleinden is de informatie van wat er gebeurd is dan nog wel beschikbaar, alleen niet meer door wie. Misschien heb je er iets aan

edit: disclaimer: de producten waar ik aan werk zijn geen SAAS, het scheiden van verschillende klanten heb ik geen ervaring mee.

[ Voor 7% gewijzigd door Cartman! op 09-12-2024 11:19 ]

[Erpenator2]

Dat was inderdaad ook mijn indruk van ISO 207001, wat mij betreft dan ook fijn dat je dit bevestigt.

Cartman! schreef op maandag 9 december 2024 @ 11:17:
Sommige dingen moet je ook praktisch bekijken, als je ergens een lek hebt dan kan een aanvaller alsnog bij die databases komen of t er nu 1 is of 10.

Hier kan ik mij ook erg in vinden. Ook lijkt het mij dat als je toegang hebt tot (een deel van) de server dat het erg lastig wordt om de aanvaller buiten je applicatie te houden. Het lijkt mij dat je juist op server en applicatie niveau zo veel mogelijk wilt beveiligen, maar dat het (zelf) encrypten van data in veel gevallen waarschijnlijk niet meer veiligheid toevoegt dan dat het 't systeem complexer maakt. Wel zag ik dat een aantal databases encryptie van data in de software zelf al "aangezet" kan worden.

Cartman! schreef op maandag 9 december 2024 @ 11:17:
Zelf doe ik encryptie met AES256 met een key per user zowel met oog op security als de AVG/GDPR. De event log bevat alleen encrypted data en die kunnen we decrypten zolang de key bestaat. Als een gebruiker de account verwijderd wil hebben dan verwijderen we het user record incl key en zijn de huidige gegevens weg en kunnen historische logs niet meer decrypt worden. Voor analytics doeleinden is de informatie van wat er gebeurd is dan nog wel beschikbaar, alleen niet meer door wie. Misschien heb je er iets aan

Begrijp ik je goed dat je alleen de AVG gegevens voor de eventlog encrypt, maar niet hele tabellen en de inhoud daarvan?

[Cartman!]

Erpenator2 schreef op maandag 9 december 2024 @ 14:06:
Begrijp ik je goed dat je alleen de AVG gegevens voor de eventlog encrypt, maar niet hele tabellen en de inhoud daarvan?

Ook binnen de tabellen sla ik alles encrypted op. De enige uitzondering die we hebben is dat we een deel van de informatie ook opslaan in een search engine waar het wel plain opgeslagen wordt omdat onze customer service moet kunnen zoeken op (partial) gegevens van een gebruiker. Die data ruimen we na X tijd ook weer op.

Ik principe blijft alles bij ons binnen ons VPC (virtual private network) maar maak desondanks gebruik van de encryption at rest en in transit van de diverse diensten die we op AWS gebruiken. Het kost in gebruik niks extra en heeft hooguit wat meer tijd nodig voor setup en configuratie

[ Voor 22% gewijzigd door Cartman! op 09-12-2024 14:38 ]

[whatyoudoing]

Erpenator2 schreef op maandag 9 december 2024 @ 10:58:
Voor een advies ben ik op zoek naar best practices voor het ontwikkelen van een SAAS waarbij schaalbaarheid, performance en beveiliging conform de ISO 27001 normering belangrijk zijn.

Er zijn een aantal ideeën op tafel gelegd waarbij ik mij afvraag hoe (grote) andere partijen dat doen. Zo is de wens om voor iedere klant een aparte database aan te maken zodat klantgegevens gescheiden blijven. Met het idee is dat dit veiliger is en beter schaalbaar. Wat applicatie ontwikkeling zal het mogelijk lastiger zijn omdat je in theorie met verschillende versies van de database kan komen te zitten per klant.

Daarnaast is het plan om een algemene database voor toegangsrechten (lees inloggen, rechten tot de applicatie), een database logging, en een database voor policies waarbij ik aanneem dat deze wensen vanuit de ISO normering komen en daarnaast met het idee dat dit de applicatie schaalbarer maakt. Vanuit die uitgangspunten zullen er meerdere connecties opgebouwd moeten worden naar al deze verschillende databases. Maar uit ervaring heb ik geleerd dat het opbouwen van een databaseconnectie relatief gezien veel performance kost, laat staan naar 5 of meer verschillende databases. Vanuit schaalbaarheid zou ik zeggen dat meer CPU cores / geheugen of andere hardware matige oplossingen voldoende zouden moeten zijn i.p.v. losse databases op verschillende servers. Dit o.a. met netwerk latancy in het achterhoofd. Maar waar de limiet ligt weet ik niet.

Daarnaast is het de bedoeling om de data in de de databases te encrypten, zodat wanneer er toch oneigenlijk toegang is verkregen tot de database de data waardeloos is zonder key. De key voor de encryptie moet in de applicatie komen om bij iedere insert de data te encrypten. De wens voor encryptie van de data kan ik goed begrijpen, maar kom dit nu nog zelden tegen bij andere projecten of applicaties. Daarnaast lijkt het mij veiliger om data door het OS of door de database software zelf te laten doen, dan zelf wat te ontwikkelen. Sowieso heeft encryptie best wat praktische uitdagingen, zoals lastiger kunnen zoeken in de database en een performance cost voor en-decrypten. Wat is een goede oplossing voor encryptie?

Daarmee komt de vraag naar voren hoe grote partijen als bijvoorbeeld Exact de software per klant opzetten om de software schaalbaar te maken en welke veiligheidsmaatregelen zou zo'n partij nemen om al dan niet aan deze ISO normering te voldoen? De ISO normering geeft volgens mij geen concrete requirements alleen richtlijnen dus dat geeft in ieder geval wel flexibiliteit.

Dit idee kan prima hoor, en ook op schaal. Het maakt voor bv MySQL of MariaDB niet uit of je een select doet op `table` of op `database1`.`table`. Je kan prima een join vanuit `database1`.`table` naar `database2`.`table` doen, zonder performanceverlies.

In theorie kan je idd met verschillende database-versie komen te zitten, maar dan heb je in de praktijk je migrations niet goed gedaan en geen controle op afwijkingen.

Het is iig niet moeilijker om te ontwikkelen. Wat het makkelijker maakt:

- performance (je tabellen zijn kleiner omdat t per klant gaat)
- performance (want je kan als nodig distribueren over meerdere database-servers)
- backup restores: dat kan veel makkelijker op klantniveau

Zelf data in de databases encrypten doe je als je een passwordmanager oid bent. Maar verder zou ik het afraden, idd om wat je al zegt: performance en ook bv kunnen zoeken. Ja, je hebt een aanvalsvector minder maar de kans is (meestal) groter dat iemand via de applicatie er in komt (en dus credentials heeft) dan dat 'ie direct database-toegang heeft.

[Erpenator2]

whatyoudoing schreef op maandag 9 december 2024 @ 14:49:
[...]
Dit idee kan prima hoor, en ook op schaal. Het maakt voor bv MySQL of MariaDB niet uit of je een select doet op `table` of op `database1`.`table`. Je kan prima een join vanuit `database1`.`table` naar `database2`.`table` doen, zonder performanceverlies.

Dat zou in dit geval betekenen dat 1 SQL gebruiker toegang heeft tot alle databases (ook van alle klanten). Dan heeft deze opzet geen performance verlies, maar het lijkt mij ook geen extra veiligheid op te leveren door de data te scheiden? Want met de credentials van de sql user kan je nog overal bij. Wat betreft scheiding van data per klant zie ik ook zeker wel de voordelen.

whatyoudoing schreef op maandag 9 december 2024 @ 14:49:
[...]
In theorie kan je idd met verschillende database-versie komen te zitten, maar dan heb je in de praktijk je migrations niet goed gedaan en geen controle op afwijkingen.

Eens! Ik ben benieuwd wat goede (standaard) oplossingen hiervoor kunnen zijn.

whatyoudoing schreef op maandag 9 december 2024 @ 14:49:
[...]
Het is iig niet moeilijker om te ontwikkelen. Wat het makkelijker maakt:
- performance (je tabellen zijn kleiner omdat t per klant gaat)
- performance (want je kan als nodig distribueren over meerdere database-servers)
- backup restores: dat kan veel makkelijker op klantniveau

Backup restores is een zeer terecht punt waar ik nog niet eens bij stil heb gestaan wat zeker een groot voordeel is. Van het scheiden van databases / data/ zie ik nog wel het voordeel in. Maar wanneer al je gebruikersrechten in dezelfde database zitten van al je klanten lijkt het mij geen voordeel te geven wat betreft beveiliging. In dat geval zou je bijna een stand-alone database versie per klant moeten creëren waarbij iedere klant zijn eigen complete database structuur heeft.

whatyoudoing schreef op maandag 9 december 2024 @ 14:49:
[...]
Zelf data in de databases encrypten doe je als je een passwordmanager oid bent. Maar verder zou ik het afraden, idd om wat je al zegt: performance en ook bv kunnen zoeken. Ja, je hebt een aanvalsvector minder maar de kans is (meestal) groter dat iemand via de applicatie er in komt (en dus credentials heeft) dan dat 'ie direct database-toegang heeft.

Hier ben ik het mee eens, maar wordt nu "gedwongen" om over opties na te denken om het toch te implementeren. @Cartman! lijkt het wel toe te passen zonder dat het extra problemen lijkt op te leveren. Het versleutelen per klant in combinatie met een database per klant zou een mooie oplossing kunnen zijn waarbij het minder erg is wanneer deze SQL gebruiker wél toegang heeft tot alle data. Want deze is dan alsnog versleuteld per klant. Ik denk hier maar hardop, zonder dat ik direct voor een specifieke oplossing kies.

[edeboeck]

Erpenator2 schreef op maandag 9 december 2024 @ 15:39:
Dat zou in dit geval betekenen dat 1 SQL gebruiker toegang heeft tot alle databases (ook van alle klanten). Dan heeft deze opzet geen performance verlies, maar het lijkt mij ook geen extra veiligheid op te leveren door de data te scheiden? Want met de credentials van de sql user kan je nog overal bij. Wat betreft scheiding van data per klant zie ik ook zeker wel de voordelen.

1 SQL user betekent niet per se toegang tot alle databases, je kan die rechten immers per user instellen.
Je zou zelfs ook nog verschillende users binnen 1 DB onderscheid kunnen maken met behulp van DB schema's (ik ken al zeker 1 online hoster waar het zo gebeurt).
Of alle mogelijkheden in het kader van ISO certificering ook aan te raden zijn, is wat anders.

[Erpenator2]

edeboeck schreef op maandag 9 december 2024 @ 17:11:
[...]
1 SQL user betekent niet per se toegang tot alle databases, je kan die rechten immers per user instellen.

Dat is waar inderdaad. Dit deel zou inderdaad in een admin applicatie nog redelijk goed in te richten zijn.

edeboeck schreef op maandag 9 december 2024 @ 17:11:
[...]
Je zou zelfs ook nog verschillende users binnen 1 DB onderscheid kunnen maken met behulp van DB schema's (ik ken al zeker 1 online hoster waar het zo gebeurt).

Met onderscheid maken van DB schema's bedoel je db_klant1_tabelnaam o.i.d. en dan voor een andere klant db_klant2_tabelnaam?

Als veiligheid de hoogste prioriteit zou hebben zou ik de optie waarbij je 1 algemene database hebt waarin gebruikersrechten aan databases/klanten worden gekoppeld niet super veilig vinden. (Dat is nu één van de ideeën die op tafel ligt). Want je hebt vanuit de applicatie toegang tot dat stuk dat de rechten dat alle andere delen bepaald. Normaal gesproken zou je dan kunnen zeggen dat iedere klant alleen zijn eigen rechten en database krijgt, maar dan kun je gebruiker1 die zowel voor klant als klant 2 werkt niet centraal zijn/haar rechten managen. Wat ook belangrijke een wens is. Dus lijkt het mij dat er compromissen gesloten moeten worden (dat moet altijd).

[ThomasG]

Je kunt dit op verschillende manieren aanpakken, afhankelijk van je behoeften: een aparte instantie per klant, een aparte database per klant, of shared multi-tenancy. Elk van deze opties heeft zijn eigen voor- en nadelen.

• Aparte instantie per klant: biedt de hoogste mate van isolatie, maar brengt ook de meeste overhead met zich mee.
• Shared multi-tenancy (alle tenants in één database, gescheiden door een TenantID): heeft de minste overhead en isolatie, maar is ook het meest complex om te implementeren.
• Aparte database per klant: zit qua isolatie en overhead tussen de andere twee opties in. Je gebruikt hierbij één gedeelde instantie, waarbij je per klant van database wisselt.

Welke aanpak het beste is voor jouw applicatie, hangt af van je specifieke situatie. Let op: shared multi-tenancy lastig achteraf in te bouwen is. Als je grote ambities hebt of verwacht dat je veel (kleine) klanten zult hebben, is dit waarschijnlijk wel de beste keuze. Over prestaties hoef je je in dat geval geen zorgen te maken; dat wordt pas een uitdaging bij vele miljoenen records per tabel. Zelfs dan zijn er uitstekende oplossingen, zoals table partitioning.

Wij maken gebruik van shared multi-tenancy, verdeeld over meerdere databases en systemen. Sommige tabellen zijn gepartitioneerd; de meeste partities bevatten dan meerdere tenants, verdeeld op basis van de TenantID-hash, terwijl enkele grote klanten een eigen partitie hebben (zodat het de performance van de kleinere tenants niet beinvloed). Alleen gevoelige informatie wordt versleuteld, waarbij per tenant een aparte sleutel wordt gebruikt. Dit is conform ISO 27001, mits er een goede risicoanalyse en risicobeheersings is en regelmatig een audit doet.

[edeboeck]

Erpenator2 schreef op maandag 9 december 2024 @ 18:22:
[...]

Dat is waar inderdaad. Dit deel zou inderdaad in een admin applicatie nog redelijk goed in te richten zijn.


[...]


Met onderscheid maken van DB schema's bedoel je db_klant1_tabelnaam o.i.d. en dan voor een andere klant db_klant2_tabelnaam?

Als veiligheid de hoogste prioriteit zou hebben zou ik de optie waarbij je 1 algemene database hebt waarin gebruikersrechten aan databases/klanten worden gekoppeld niet super veilig vinden. (Dat is nu één van de ideeën die op tafel ligt). Want je hebt vanuit de applicatie toegang tot dat stuk dat de rechten dat alle andere delen bepaald. Normaal gesproken zou je dan kunnen zeggen dat iedere klant alleen zijn eigen rechten en database krijgt, maar dan kun je gebruiker1 die zowel voor klant als klant 2 werkt niet centraal zijn/haar rechten managen. Wat ook belangrijke een wens is. Dus lijkt het mij dat er compromissen gesloten moeten worden (dat moet altijd).

Eigenlijk is het subtieler: je kan ook rechten toekennen op schema's (met wat goede wil te vergelijken met namespaces bij ontwikkeling, met dat verschil dat je dan ook op de namespaces rechten kan toekennen). Stel dat je schema's KlantX en KlantY hebt, en je richt de rechten goed in, kan je met usrX wel aan KlantX.Producten, maar niet aan KlantY.Producten.

P.S. Mijn frank is net gevallen dat "schema's" een typische SQL Server-term zijn (mijn excuses als ik daarmee verwarring creëerde!). Deze pagina brengt je pal in de security van een SQL Server.

[ThomasG]

edeboeck schreef op maandag 9 december 2024 @ 20:20:
[...]
Eigenlijk is het subtieler: je kan ook rechten toekennen op schema's (met wat goede wil te vergelijken met namespaces bij ontwikkeling, met dat verschil dat je dan ook op de namespaces rechten kan toekennen). Stel dat je schema's KlantX en KlantY hebt, en je richt de rechten goed in, kan je met usrX wel aan KlantX.Producten, maar niet aan KlantY.Producten.

P.S. Mijn frank is net gevallen dat "schema's" een typische SQL Server-term zijn (mijn excuses als ik daarmee verwarring creëerde!). Deze pagina brengt je pal in de security van een SQL Server.

Schemata zijn een standaard onderdeel van SQL.. Alleen ondersteunen een aantal SQL databases het niet (goed).

Idealiter geef je klanten helemaal geen directe toegang tot de database; alleen de applicatie zou dat moeten kunnen, en daarbij maakt het vrij weinig dat het bij records kan van een andere tenant. De applicatie isoleerd dat. Maar, als je toch kiest voor een dergelijke opzet, is het beter om met views te werken en de onderliggende tabellen volledig te verbergen. Er zullen namelijk altijd kolommen zijn die niet voor iedereen zichtbaar of toegankelijk zouden mogen zijn. Om nog maar niet te spreken van alle joins die je nodig zult hebben bij een enigszins complexe database.

[edeboeck]

ThomasG schreef op maandag 9 december 2024 @ 21:04:
[...]
Schemata zijn een standaard onderdeel van SQL.. Alleen ondersteunen een aantal SQL databases het niet (goed).

Idealiter geef je klanten helemaal geen directe toegang tot de database; alleen de applicatie zou dat moeten kunnen, en daarbij maakt het vrij weinig dat het bij records kan van een andere tenant. De applicatie isoleerd dat. Maar, als je toch kiest voor een dergelijke opzet, is het beter om met views te werken en de onderliggende tabellen volledig te verbergen. Er zullen namelijk altijd kolommen zijn die niet voor iedereen zichtbaar of toegankelijk zouden mogen zijn. Om nog maar niet te spreken van alle joins die je nodig zult hebben bij een enigszins complexe database.

Het gaat hier over het verbergen voor andere klanten, toch? Elke klant richt het daarbinnen dan in zoals die zelf wil. Als ik me goed herinner, werkten views enkel voor read-only data wat hen niet geschikt maakt als enige oplossing voor de meeste toepassingen (tenzij ik me dat dus niet goed herinner).

[ThomasG]

edeboeck schreef op maandag 9 december 2024 @ 21:52:
[...]
Het gaat hier over het verbergen voor andere klanten, toch? Elke klant richt het daarbinnen dan in zoals die zelf wil. Als ik me goed herinner, werkten views enkel voor read-only data wat hen niet geschikt maakt als enige oplossing voor de meeste toepassingen (tenzij ik me dat dus niet goed herinner).

Maar wat wil je precies verbergen voor andere klanten? Normaal gesproken werken zij via de applicatie en niet rechtstreeks met de database. Dat is namelijk vragen om problemen. De applicatie voegt het TenantID toe aan de queries, waardoor klanten nooit gegevens van andere klanten te zien krijgen.

Voor de klant maakt het dus geen verschil of het een database per klant, of schema per klant, of shared multi-tenancy is. Die ziet en merkt daar niets van. Qua schaalbaarheid en onderhoud merk je het verschil wel. En in de kosten bij eventuele groei met veel (kleine) klanten.

[Voutloos]

Elke DB software heeft ‘db’ of ‘schema’ als core feature, dus voor de isolatie is dat lekker out of the box.

Zelfs liability: een aantal scenario’s die fout gaan, kan je dan verwijzen naar De Grote Fout van $Leverancier (zie Crowstrike). Dat kan je misschien eerder weer goed slapen dan bij ‘de fout van het team dat het zelf in views heeft lopen hanessen’ if shits hit the fan.

En tenant filtertje toevoegen is als idee geen moeilijk iets. Het in 100% vd queries doen, dus de uitvoering, wel. Dat controleren kan, maar is zeker niet 0 als kostenpost.

[Voutloos]

Overigens, uiteraard vinden wij techies de db altijd het probleem bij schaalbaarheid of performance vraagstukken. Voor ISO is het echter zeker niet de hoofdmoot. Dus misschien is dit vooral de interesse of expertise van ts, maar let op dat je niet enkel voor de DB naar perfectie zoekt, want dan faal je gewoon op een ander gebied.

Authenticatie, autorisatie, auditing, processen. O, en ook nog processen, processen en processen.

[Erpenator2]

Zeer waardevolle input allemaal, waarvoor dank!

Ik krijg de vraag als ontwikkelaar om een "veilig" systeem te ontwikkelen dat voldoet aan de ISO 27001 norm. Met deze norm was/ben ik niet bekend. Ik benader het vraagstuk in eerste instantie dus vooral vanuit de techniek. Enerzijds heb ik het idee dat KISS bijna altijd de beste weg is en waarbij je de applicatie aanpast naar mate deze groeit. Aan de andere kant als de doelstellingen groot zijn kan je bepaalde zaken maar beter meteen implementeren. Ik hoef deze beslissing gelukkig niet te maken

De bedenkingen die ik heb zijn bijna allemaal naar voren gekomen met onderbouwde oplossingen met daarbij de voor en nadelen, dus dat is echt zeer nuttig. Wanneer deze goed op een rijtje gezet zijn is het uiteindelijk een kwestie van keuzes maken en met de best mogelijke oplossingen komen.

Mijn bedenkingen zijn/waren:

• Alleen gegevens in een aparte database zetten per tenant maakt het niet per definitie veiliger. Dat wordt door jullie ook bevestigt. In deze video kwam ik enkele nuttige tips tegen om gegevens per tenant in de basis zo goed mogelijk te scheiden en uit welke opzet gekozen kan worden: YouTube: Multi-Tenant: Database Per Tenant or Shared? Met jullie tips en die in de video kan ik de opties mooi (visueel) op een rij zetten
• Gezien de grote wensen voor de applicatie lijkt mij de beste optie om per tenant een database én applicatie versie te creëren. Zo kan je gefaseerd updaten, en de grote klanten die veel van het systeem vragen apart zetten van de rest. Het maakt e.e.a. wel een stuk ingewikkelder, maar wel flexibeler en schaalbaar (wat nu nog een wens is).
• Maak je voor iedere tenant een nieuwe database user aan welke alleen rechten heeft tot de eigen database + algemene databases? Deze vraag heb ik nog niet 100% helder. Uiteraard is het alleen de applicatie welke communiceert met de database, en klanten krijgen geen directe toegang tot de database.
• Encryptie toepassen op alleen gevoelige informatie. Alleen nog bepalen wat dan precies "gevoelige informatie" is en of de implementatiekosten opwegen tegen de verwachte extra veiligheid. Verder gegevens encrypten per klant i.p.v 1 encryptie wat oorspronkelijk het plan was. Daarmee bescherm je gegevens tussen tenants én mogelijk tegen pottenkijkers van buitenaf.

Hopelijk ben ik met bovenstaande punten ook de voor jullie overgebleven onduidelijkheden weggenomen.

[Creepy]

ISO 27001 draait om de processen die je volgt voor o.a. Software ontwikkeling. Het is een norm om informatiebeveiliging in te richten op management niveau. Software die voldoet aan de norm bestaat dan ook niet, je hebt hoogstens je processen zo ingericht dat je softwareontwikkelproces voldoet aan de norm.

Dus een vraag of je wel of niet een eigen database inricht per klant is niet een vraag die ISO 27001 kan beantwoorden. Wel of je een proces hebt gevolg om een zo veilig mogelijk situatie te creeeren , dat je dat zelf hebt gedocumenteerd waarom je welke keuzes hebt gemaakt en dat je hebt gedocumenteerd dat je het proces hebt gevolgd. Als er overwegingen zijn om niet de DB volledig te encrypten dan kan dat nog prima aan de ISO 27001 norm voldoen.

Maar ISO 27001 is veel breder dan alleen de softwareontwikkeling. Dus ik denk dat aan jou de verkeerde vraag is gesteld van iemand die niet doorheeft wat ISO 27001 nu echt inhoudt. Laat je eens adviseren zou ik zeggen. Er zijn genoeg toko's die je kunnen helpen met ISO 27001 en het inrichten en onderhouden van een information security management system (ISMS).

[ Voor 61% gewijzigd door Creepy op 10-12-2024 21:42 ]

[armageddon_2k1]

Even een domme vraag... maar heb je de normen gelezen? Het is niet zo gek veel werk namelijk. Download het PDF'je eens een loop door de eisen heen. Mijn ervaring is dat de meeste mensen binnen de bedrijven zelf, zelfs inclusief de CISO's, nooit eens dat documentje zelf bekijken.

Je duikt nu in oplossingen, maar zijn je requirements (de normen dus) waar je de oplossingen voor verzint wel duidelijk? ISO27001 is echt zo moeilijk niet namelijk en je moet je afvragen voor welke eisen je de oplossingen aandraagt.

Ik moet zeggen dat ik ISO27001 veel en veel te losjes vond overigens. Maar ik ben dan ook getraumatiseerd door IEC62304 in de medical device industry. Welke overigens ook grotendeels common sense is.

Wat wij altijd deden was _elke_ norm langs en schrijven:
- hoe je hem implementeert, of gaat implementeren
- als je hem niet implementeert, waarom dan. Want ook dat kan.

Ik proef een beetje heel veel bangmakerij en weinig concrete kennis namelijk.

Ik heb dit voor ISO27001 ook gedaan en was echt maximaal een hele werkdag bezig om erdoorheen te lopen.

[ Voor 33% gewijzigd door armageddon_2k1 op 15-12-2024 11:59 ]

[sig69]

Wat @Creepy zegt. Het gaat om het proces, hoe je de techniek inricht boeit ze niet. Ik heb nog nooit een regel code of iets technisch op m'n scherm gehad tijdens een audit. En dat proces mag je inrichten zoals je wil, kunnen ze ook mee helpen. En waar het dan om gaat is dat je tijdens een audit kan aantonen dat je het proces volgt. Even heel kort door de bocht.
Bedenk even waar je met dit topic heen wil. De iso kant of de technische inrichting op dit project. Iso doe je als bedrijf, niet op project basis.
Qua inrichting, mijn mening: eigen database per klant. En daarnaast ook een apart release pipeline per klant. Webservices, etc, alles gescheiden.

[ Voor 30% gewijzigd door sig69 op 19-12-2024 03:07 ]