Gegevens leerlingvolgsysteem openstellen voor automatiseren

[rosecodemonkey]

Mijn vraag
Ik werk als (uit de hand gelopen) studentenbaantje bij de ICT op een middelbare school, met als hoofddoel het automatiseren van tijdrovende taken.
Meestal is een beetje knutselen met Excel en PowerQuery al voldoende voor een flinke werkdrukverlichting, alleen is het aanleveren van brongegevens (leerlingen, docenten, leerling-mentor-koppelingen, etc.) elke keer een bottleneck. Handmatig exporteren uit het leerlingvolgsysteem (Magister) kan, maar is in de praktijk vaak niet werkbaar.

Kortom: ik ben op zoek naar de beste/makkelijkste manier om deze gegevens automatisch en up-to-date beschikbaar te maken voor automatiseren, uiteraard rekening houdend met privacyregels en de gebruikersrechten van medewerkers.

Relevante software en hardware die ik gebruik
• Magister
• Excel
• Google Sheets
• Appsmith
• Activepieces

Wat ik al gevonden of geprobeerd heb
Als proef heb ik een MySQL database van onze webhosting gevuld met deze gegevens. Afgezien van wat geneuzel met drivers in Excel werkte dat eigenlijk echt top, zelfs de niet-technici konden er uiteindelijk redelijk mee overweg via PowerQuery.
Ik overweeg om dit breder in te gaan zetten, maar je loopt dan al snel tegen beperkingen aan in het beheren van gebruikers(rechten).

Na flink wat ronddwalen ben ik tot dit concept gekomen:
1. Een Postgres database met LDAP authenticatie gekoppeld aan Google Workspace, in combinatie met iets als pg_ldap_sync.
2. Deze database automatisch vullen met Magister Web Services, eventueel via een zelfgeschreven foreign data wrapper.
3. Databaserollen en bijbehorende tabel/kolom/rij-rechten automatisch toewijzen op basis van de rollen/rechten ingesteld in Magister.

Een database op deze manier openstellen voelt ergens riskant, al kan ik niet helemaal plaatsen waarom. Een extra laag zoals een OData API zou een alternatief kunnen zijn, maar ik zie daar eigenlijk niet echt een voordeel in. Dan zou ik bijvoorbeeld het rechtensysteem van Postgres moeten nabouwen, dat lijkt mij juist foutgevoeliger. Daarnaast is makkelijk kunnen koppelen met programma's als Appsmith en Activepieces een gigantisch voordeel van een database, OData connectors lijken veel zeldzamer te zijn.

Zie ik ergens iets over het hoofd, is er misschien toch ergens een makkelijkere manier?
Ik heb ruime ervaring als programmeur, dus de implementatie maak ik me geen zorgen om, maar doordat dit vooral hobbymatig was wil ik nog weleens een blinde vlek hebben voor dit soort zaken...

[ Voor 1% gewijzigd door rosecodemonkey op 08-03-2024 03:37 . Reden: Verduidelijking gebruikersrechten & privacy ]

[grasmanek94]

Zoals ik hier lees zit de crux er in dat dit natuurlijk veilig moet, en ook alle privacyregels gevolgd moeten worden.

Uiteindelijk zal de developer (jij) en de school moeten kunnen aantonen "kijk dit is veilig, en dit is waarom" (onderbouwd dus).

Kan je dat met je huidige oplossingen?
End-users (laag of hoogdrempelig) direct (of tot een bepaalde hoogte direct, zoals met je FDW link) toegang geven tot een database is zelden sprake van in end-user applicaties. Zoals je al aangeeft, dit voelt niet fris.

Wil je rechten beheren, kan je dan niet SSO doen met de magister gegevens of een school login? (is er uberhaupt een SSO dienst beschikbaar?)

Dit zal vereisen dat je natuurlijk een tussen (web)server maakt, die dan een API bloot stelt naar de data (voor je tools, Excel e.d.), en daar de rechten/gebruiksbeheer/toegangscontrole doet. Ik denk niet dat je daar aan ontkomt wil je kunnen aantonen dat alleen medewerkers met de juiste rechten, toegang krijgen.
Waarschijnlijk ontkom je dus niet aan een API/server tussen de gebruikers/tools, en de database.

Waar die web server in is maakt natuurlijk niet uit, be it python, php, ruby, ASP, zolang het maar doet wat het moet doen, en veilig doet.

Je komt best gevorderd over, dus pluspunten voor dat, en je herkent al dat er zeker mensen zijn die mee kunnen denken en meer kennis hebben - gebruik dat in je voordeel.

Een tip; Mocht alles klaar zijn vraag de school dan om een security assessment te regelen alvorens in gebruikt te nemen.
Denk ook na over logging, wie welke data wanneer, hoeveel en hoe lang 'accessed'. Ik ben geen expert hierin (daar hebben wij op het mijn werk de legal en compliance mensen voor, niet mij), maar ik kan mij voorstellen dat dit handig zal zijn om welles-nietes discussies te voorkomen bij een eventueel lek (de queries + aantal resultaten, zonder resultaten loggen ivm privacy?).

[ Voor 12% gewijzigd door grasmanek94 op 08-03-2024 07:36 ]

[TripleQ]

Ik zit zelf ook in de wereld van lvs/swv achtige systemen, dus ik weet hoe belangrijk privacy en certificeringen zijn.

Wat ik nog mis in dit verhaal is waar alles gehost / verwerkt wordt. Is dit een Europese partij/server?

Wat zijn daar de afspraken mee? Verwerkingsovereenkomst? Ik lees google Workspace.

Maar ook de bewaartermijnen zijn vaak een vergeten iets. Kinderen die een x aantal jaar op school gezeten hebben moeten er automatisch uit verwijderd worden etc.

[internet]

Belangrijkste om te focussen naast de technische oplossing, is privacy (denk aan bewaartermijn), auditing en loggin, security. Dit kan heel gemakkelijk na een jaar of drie op Tweakers verschijnen als "jeetje wie dacht ooit dat dat een goed idee was, alle data uit het veilige systeem gexporteerd en in een db gepleurd waar docenten zonder limiet data uit konden trekken, vrij spel voor die hacker toen die eenmaal binnen was!"

Dat is niet om af te doen aan je technische kennis uiteraard, maar laat het door een externe audit goedkeuren wat je ook bouwt. CYA

PS Ze hebben een API maar staat niet open zo te zien. Misschien eens bij de software leverancier zelf navragen of ze een andere ingang hebben?
https://www.magister.nl/o...#gebruikersvoorwaardenapi


Edit: was niet als pessimistische post bedoelt, meer een item voor op je checklist. Op technisch vlak heb ik helaas geen kennis voor deze casus om je te helpen :-)

[ Voor 11% gewijzigd door internet op 08-03-2024 08:23 ]

[grasmanek94]

Een lek zal sowieso ooit gebeuren, de focus moet idd liggen op voorkomen, data minimaliseren die gelekt wordt, en daarna ook het "hoe wordt de lek afgehandeld".

Maar laten we ook niet meteen een project afschrijven omdat er risico's zijn, negatief doen op Tweakers zijn wij goed in.
Er is een duidelijk tijdwinst, en die mensen daar (docenten die het veelal al te druk hebben) krijgen het beter / kunnen makkelijker te werk.
Zo lang best practices aangehouden worden, en idd aan alle voorwaarden voldaan wordt, gewoon goed implementeren en gaan met die banaan.

[99ruud99]

Hoeveel mag het kosten? Ik weet dat er bedrijven zijn die softwarepakketten aanbieden, zodat de lijst automatisch gepushed wordt bij wijzigingen.

Maar dat kost teveel voor een hobby project.
Let op dat je vantevoren met de PO van je scholengroep goed door spreekt via welke kanalen waar welke data wordt opgeslagen. Leerlingen data bevat vaak data van minderjarigen, die hebben een extra beschermde status.

Voor je het weet gebruik je iets als Google spreadsheets met een koppeling naar je bronbestand, waardoor de data gekopieerd wordt naar servers die niet van school zijn.

[BCC]

Ja inderdaad, je bent goed genoeg om gevaarlijk te zijn maar laat dat je vooral niet tegenhouden, vaak is dat erg leerzaam. Normaliter zet je nog een “app” voor je database en die helpt de gebruiker dan met het vinden wat hij zoekt - een rapportage of een overzicht in dit geval denk ik. Authorisatie kan je daar weer via Google workspace doen. Dat kun je eenvoudig bouwen in Ruby , nodejs of php. Veel plezier 👍

[rosecodemonkey]

Dank voor al jullie reacties op deze vroege ochtend!
Ik loop er even stap voor stap doorheen.

grasmanek94 schreef op vrijdag 8 maart 2024 @ 07:15:
Uiteindelijk zal de developer (jij) en de school moeten kunnen aantonen "kijk dit is veilig, en dit is waarom" (onderbouwd dus).
Kan je dat met je huidige oplossingen?

Dit is inderdaad een van mijn grote knelpunten. Een security assessment is inderdaad een goede, zal ik zeker doorgeven aan mijn werkgever!

grasmanek94 schreef op vrijdag 8 maart 2024 @ 07:15:
Wil je rechten beheren, kan je dan niet SSO doen met de magister gegevens of een school login?

Dat is in ons geval Google Workspace. Authenticatie met LDAP (via Google Workspace) is naar mijn weten ook een (ouderwetse) vorm van SSO, maar misschien mis ik iets.
Ik zie de link tussen SSO en rechtenbeheer niet helemaal ben ik bang. Ik neem aan dat dit dan via Google IAM oid zou lopen, maar ben je dan niet juist het rechtenbeheer aan het uitsmeren/dupliceren over meerdere systemen?

grasmanek94 schreef op vrijdag 8 maart 2024 @ 07:15:
Dit zal vereisen dat je natuurlijk een tussen (web)server maakt, die dan een API bloot stelt naar de data (voor je tools, Excel e.d.), en daar de rechten/gebruiksbeheer/toegangscontrole doet. Ik denk niet dat je daar aan ontkomt wil je kunnen aantonen dat alleen medewerkers met de juiste rechten, toegang krijgen.

Ik zie (tot nu toe) de meerwaarde van een extra API-laag hier alleen niet in. Is het niet veel efficiënter en veiliger om gebruik te maken van het battle-tested rechtenbeheer in de database zelf?

Ter illustratie: als een gebruiker in Magister rechten heeft om "Leerlingen" te lezen (eventueel per klas/jaar/afdeling/etc.) kan de bijbehorende databasegebruiker SELECT rechten krijgen op de databasetabel "Leerlingen" (eventueel per kolom/rij).
Wat is precies de meerwaarde van het bouwen van een apart eigen tabel/kolom/rij rechtenbeheer?

Misschien goed om expliciet te benoemen: ik hoef natuurlijk niet de gehele Magister database te linken aan deze eigen database.
Magister Web Services werkt al met SQL queries, de "services" zijn eigenlijk een soort views over hun database. Vanzelfsprekend maak ik natuurlijk alleen "services" aan voor de gegevens die voor automatiseren relevant zijn, bijvoorbeeld wel de kolom voor "leerling heeft extra tijd", maar niet de stoornis waar dit recht vandaan komt.
Een API-laag zou toegang moeten hebben tot al deze "services", dus het is ook niet zo dat een deel van de database extra afgeschermd is als er een keer iets lekt.

TripleQ schreef op vrijdag 8 maart 2024 @ 07:28:
Wat ik nog mis in dit verhaal is waar alles gehost / verwerkt wordt. Is dit een Europese partij/server?
Wat zijn daar de afspraken mee? Verwerkingsovereenkomst? Ik lees google Workspace.
Maar ook de bewaartermijnen zijn vaak een vergeten iets. Kinderen die een x aantal jaar op school gezeten hebben moeten er automatisch uit verwijderd worden etc.

Hosting ben ik nog aan het onderzoeken, maar dat zal hoogstwaarschijnlijk een VPS worden bij mijn.host.
Google Workspace wordt al jaren gebruikt en zijn inderdaad alle verwerkingsovereenkomsten en bijbehorende leukigheden voor geregeld.
Bewaartermijnen is een goeie, maar in dit geval vrij makkelijk: alleen de gegevens van het huidige schooljaar hoeven beschikbaar te zijn

internet schreef op vrijdag 8 maart 2024 @ 07:31:
Dit kan heel gemakkelijk na een jaar of drie op Tweakers verschijnen als "jeetje wie dacht ooit dat dat een goed idee was!"

Mijn grootste nachtmerrie inderdaad

internet schreef op vrijdag 8 maart 2024 @ 07:31:
PS Ze hebben een API maar staat niet open zo te zien. Misschien eens bij de software leverancier zelf navragen of ze een andere ingang hebben?

Magister staat helaas bekend als een partij die pertinent weigert samen te werken met anderen, tenzij ze echt niet anders kunnen

grasmanek94 schreef op vrijdag 8 maart 2024 @ 07:40:
Een lek zal sowieso ooit gebeuren, de focus moet idd liggen op voorkomen, data minimaliseren die gelekt wordt, en daarna ook het "hoe wordt de lek afgehandeld".

Dit is inderdaad mijn instelling. Het is onvermijdelijk dat er een keer iets lekt, maar de huidige methode (handmatig Excel exports rondslingeren) is naar mijn inzien eigenlijk juist onveiliger.

Magister is hier overigens ook absoluut geen heilige in. Ik zal niet te veel in detail treden, maar ik heb ondertussen al 4 vrij serieuze vulnerabilities gevonden in hun systemen. Als leerling leek het mij altijd enorm cool om Magister te hacken, maar het heeft mij eigenlijk alleen maar heel veel stress over de belabberde staat van sommige delen van onze sector gegeven

99ruud99 schreef op vrijdag 8 maart 2024 @ 07:49:
Hoeveel mag het kosten? Ik weet dat er bedrijven zijn die softwarepakketten aanbieden, zodat de lijst automatisch gepushed wordt bij wijzigingen.

Het standaardantwoord: "hoe minder hoe beter"
Er is wel budget, maar dat wordt liever uitgegeven aan duurzame eigen oplossingen dan duurbetaalde softwarebedrijven.

BCC schreef op vrijdag 8 maart 2024 @ 08:09:
Ja inderdaad, je bent goed genoeg om gevaarlijk te zijn

Precies dit...

[Rolfie]

rosecodemonkey schreef op vrijdag 8 maart 2024 @ 12:51:
Dit is inderdaad een van mijn grote knelpunten. Een security assessment is inderdaad een goede, zal ik zeker doorgeven aan mijn werkgever!

En privacy.

Dat is in ons geval Google Workspace. Authenticatie met LDAP (via Google Workspace) is naar mijn weten ook een (ouderwetse) vorm van SSO, maar misschien mis ik iets.
Ik zie de link tussen SSO en rechtenbeheer niet helemaal ben ik bang. Ik neem aan dat dit dan via Google IAM oid zou lopen, maar ben je dan niet juist het rechtenbeheer aan het uitsmeren/dupliceren over meerdere systemen?

Ik zou denken SecureLDAP?
Maar ik denk dat SAML Authenticatie beter zou zijn voor je eigen applicatie. Wel iets complexer, maar ook veiliger.

Hosting ben ik nog aan het onderzoeken, maar dat zal hoogstwaarschijnlijk een VPS worden bij mijn.host.

Dit zou voor mij een red flag zijn.

VPS moet je ook beheren en onderhouden en backupen. Wie heeft er eventueel toegang tot deze VPS? Waar staat je backup?

Ik zou persoonlijk dit soort data nooit zomaar in een mysql database willen hebben draaien, op een systeem dat zomaar ergens draait zonder goede auting/siem integratie ergens bij een hoster.

Er goed maar 1 regel code fout te zijn in je website en die kan al misbruikt worden, waarna de data in de database en API keys openbaar zijn voor een hacker.

Privacy, AVG (en security) zie ik wat uitdagingen.

Maar waarom geen PAAS, als je specifiek MySQL wilt hebben?
Zit in ieder geval een stuk beter te beheren.

Dit is inderdaad mijn instelling. Het is onvermijdelijk dat er een keer iets lekt, maar de huidige methode (handmatig Excel exports rondslingeren) is naar mijn inzien eigenlijk juist onveiliger.

Is ook verre van ideaal, maar niet direct publikelijk benaderbaar.

Positief puntje, je weet inderdaad dat je gevaarlijk bezig bent. Complimenten hierover.

[kouk]

Met alle respect voor de TS, maar je wil als school toch ook niet dat iemand die als bijbaantje af en toe wat in elkaar zet dit soort zaken gaat doen?

[BCC]

kouk schreef op vrijdag 8 maart 2024 @ 13:21:
Met alle respect voor de TS, maar je wil als school toch ook niet dat iemand die als bijbaantje af en toe wat in elkaar zet dit soort zaken gaat doen?

Als ik de houding zie van integrators in de zorg/onderwijs op het moment zie is het denk ik wel slim - op het moment is alles extreem duur / lange wachttijden / veel geblaat, weinig gefixt - dan kun je op deze manier best top een knuppel in het hoenderhok gooien. "Kijk, het kan wel, het is niet moeilijk en hoeft dus denk ik niet een ton te kosten voor deze rapportage?"

En aangezien de organisatie al in Google workspace zit, kun je heel veel optuigen binnen de veiligheid van de bestaande afspraken - bij Azure is dat ook top.

Anyway - je hebt het over authenticatie (jantje is echt jantje) en authorisatie (jantje mag pietje's gegevens bekijken, maar niet die van keesje).

De meeste organisaties hebben hier iets van centraal (SSO authenticatie met daaraan wat rollen voor authorisatie). Afhankelijk van welke gegevens je "publiek" maakt kan Authenticatie al voldoende zijn (geannonmiseerde rapportage) of heb je zo'n explicite authorisatie nodig dat je zelf een model moet bouwen in je applicatie.

De organisatie moet je hier wel bij kunnen helpen om hier inzicht in te krijgen.

[ Voor 37% gewijzigd door BCC op 08-03-2024 13:44 ]

[grasmanek94]

rosecodemonkey schreef op vrijdag 8 maart 2024 @ 12:51:

Ter illustratie: als een gebruiker in Magister rechten heeft om "Leerlingen" te lezen (eventueel per klas/jaar/afdeling/etc.) kan de bijbehorende databasegebruiker SELECT rechten krijgen op de databasetabel "Leerlingen" (eventueel per kolom/rij).
Wat is precies de meerwaarde van het bouwen van een apart eigen tabel/kolom/rij rechtenbeheer?

Als je voor elke gebruiker een 1:1 gebruiker in de DB maakt, en die deactiveert ook wanneer de magister account inactief wordt, en de rechten updaten zodra deze in magister updaten, zie ik voor intern schoolnetwerk gebruik ook niet veel problemen.

Toch kan ik mij voorstellen dat je dan alsnog een security assessment wil doen met extra oog voor privilege escalation of enige vorm van 'escape' van restricties.

Wanneer er nog meer automatisering nodig is, is de volgende stap al snel van excel naar een full fledged backend-en-frontend website gemaakt

[rosecodemonkey]

Jeetje, ik had nooit verwacht zoveel reactie te krijgen, dank allemaal!
Ik probeer mijn reacties een beetje te beperken om het enigszins leesbaar te houden, maar met zoveel goede input valt er een hoop te zeggen

Rolfie schreef op vrijdag 8 maart 2024 @ 13:14:
Maar ik denk dat SAML Authenticatie beter zou zijn voor je eigen applicatie. Wel iets complexer, maar ook veiliger.

Met een API-laag zou ik absoluut voor SAML gaan, maar voor zover ik weet bestaat er geen (betaalbare) SAML-integratie voor Postgres. Wat bedoel je precies met "ook veiliger"? Dit zou natuurlijk een reden kunnen zijn om toch zo'n API-laag (met bijbehorend eigen rechtenbeheer) te bouwen.

Rolfie schreef op vrijdag 8 maart 2024 @ 13:14:
VPS moet je ook beheren en onderhouden en backupen.

Dit is inderdaad mijn tweede grote knelpunt, echter: wat is het alternatief?
mijn.host is voor zover ik kan zien een betrouwbare partij, zelf iets in een kast gooien lijkt mij niet bepaald veiliger

Als dit project doorgaat ben ik absoluut van plan om een aantal cursussen/certificaten rondom systeembeheer te gaan doen (suggesties zeer welkom). Ik ben altijd extreem terughoudend geweest als het gaat om beheer en beveiliging, maar door dingen alleen maar niet te doen kom je ook nooit verder...

Rolfie schreef op vrijdag 8 maart 2024 @ 13:14:
Er goed maar 1 regel code fout te zijn in je website en die kan al misbruikt worden, waarna de data in de database en API keys openbaar zijn voor een hacker.

Vandaar mijn vraag wat precies de meerwaarde is van een extra API-laag. Voor zover ik kan zien centraliseert zo'n laag dit soort credentials/toegang juist alleen maar, waardoor je bij een lek veel sneller een echt groot probleem hebt.
Met directe databasegebruikers is er, op een strengbeveiligde root/superuser na, geen centraal punt dat toegang tot alles heeft. Een hacker zou de inlog van een docent kunnen bemachtigen, maar kan daarmee alleen de gegevens uitlezen waar deze docent toegang tot heeft. Dat lijkt mij vrijwel hetzelfde als hoe Magister is ingericht.

Rolfie schreef op vrijdag 8 maart 2024 @ 13:14:
Maar waarom geen PAAS, als je specifiek MySQL wilt hebben?

(Onvoorspelbare) kosten. Heel kort door de bocht: een VPS kost €20/maand en kan voor verschillende taken ingezet worden, alleen de database is bij PAAS vaak al veel duurder.
Daarnaast hebben dit soort managed varianten vaak drempels/beperkingen rondom zaken als gebruikersbeheer en/of FDW/SQL-MED, al heb ik dat bij Azure specifiek (nog) niet uitgebreid doorgelicht.
(Voor de goede orde: Postgres heeft mijn voorkeur boven MySQL vanwege RLS en FDW.)

Rolfie schreef op vrijdag 8 maart 2024 @ 13:14:
Is ook verre van ideaal, maar niet direct publikelijk benaderbaar.

Zeker waar, maar dit risico kan (voor zover ik weet) geminimaliseerd worden door de boel alleen toegankelijk te maken vanaf het schoolnetwerk, eventueel in combinatie met een VPN.

kouk schreef op vrijdag 8 maart 2024 @ 13:21:
Met alle respect voor de TS, maar je wil als school toch ook niet dat iemand die als bijbaantje af en toe wat in elkaar zet dit soort zaken gaat doen?

Ik begrijp je zorgen helemaal, maar met een aantal jaren in de dubbele cijfers gaat mijn ervaring gelukkig echt wel een stuk verder dan "af en toe wat in elkaar zetten"

Uiteraard heb ik dit ook uitgebreid besproken met mijn werkgever, zij hebben een duidelijke voorkeur voor het investeren in kennis en een duurzame oplossing. Het alternatief, in de vorm van (tien)duizenden euro's aan belastinggeld weggooien zoals @BCC benoemd, zijn ze inmiddels een beetje zat
Bovendien heeft bijvoorbeeld een Magister zoals eerder genoemd hun zaakjes ook absoluut niet op orde, dus om daar nou blindelings op te vertrouwen...

BCC schreef op vrijdag 8 maart 2024 @ 13:25:
De meeste organisaties hebben hier iets van centraal (SSO authenticatie met daaraan wat rollen voor authorisatie).

In deze context is dat het rechtenbeheer van Magister, maar die bieden helaas geen SAML-integratie oid.
Synchroniseren met iets als Google IAM ipv databasegebruikers/rollen, en dat dan inzetten voor SAML icm een API-laag zou ook nog kunnen, maar dan moet je alsnog het CLS/RLS wiel opnieuw uitvinden.

grasmanek94 schreef op vrijdag 8 maart 2024 @ 14:34:
Wanneer er nog meer automatisering nodig is, is de volgende stap al snel van excel naar een full fledged backend-en-frontend website gemaakt

Precies

[smesjz]

Dit klinkt vooral als weinig begeleiding vanuit school want ik verwacht dat er iets een ontwerp komt, DPIA (hallo GDPR) wordt besproken, risicos worden besproken voordat het gehobby start. Dus als je security audit zelf moet aangeven omdat werkgever dat niet als eis vooraf heeft aangegeven baart ook al zorgen.

Nu lijkt de focus erg te liggen op de "happy flow" werkend te krijgen en dat alles als beheer / beveiliging / updates? / monitoring / logging geen duidelijke eisen hebben gehad. Een security audit / pen test whatever is ook erg duur, dus heb je iets van een budget gekregen?

[rosecodemonkey]

smesjz schreef op vrijdag 8 maart 2024 @ 15:34:
Dit klinkt vooral als weinig begeleiding vanuit school want ik verwacht dat er iets een ontwerp komt, DPIA (hallo GDPR) wordt besproken, risicos worden besproken voordat het gehobby start.
[...]
Nu lijkt de focus erg te liggen op de "happy flow" werkend te krijgen en dat alles als beheer / beveiliging / updates? / monitoring / logging geen duidelijke eisen hebben gehad.

Je noemt het zelf al: eerst moet er een ontwerp komen, daar probeer ik nu hier feedback op te verzamelen
De eerste proef om te kijken of dit überhaupt levensvatbaar is was kleinschalig, zonder gevoelige gegevens en met mensen die toch al toegang hadden tot alles, daar maakte niemand zich druk om.

Het is natuurlijk wel zo dat een school geen IT-specialist is en qua eisen vaak niet veel verder komt dan "het moet veilig zijn". Ik ben me natuurlijk bewust van de basiselementen die je noemt, maar alle input is welkom.

smesjz schreef op vrijdag 8 maart 2024 @ 15:34:
Dus als je security audit zelf moet aangeven omdat werkgever dat niet als eis vooraf heeft aangegeven baart ook al zorgen.
[...]
Een security audit / pen test whatever is ook erg duur, dus heb je iets van een budget gekregen?

Oeps, dat had ik beter kunnen verwoorden. Uiteraard heb ik als eis meegekregen dat alles gecheckt moet worden, ik bedoelde meer dat ik ze er aan moet herinneren dat we dat moeten gaan regelen. Inderdaad duur, maar een schijntje in vergelijking met een "professioneel" geknutselde oplossing.

[Anoniem: 80910]

Om het veilig te maken moet je minimaal 2 systemen hebben. Een database en een api. Voor elk veld wat niet opzoekbaar/ sorteerbaar moet zijn of gevoelige informatie dient in de database te worden encrypt, hier zijn libraries voor. De Keys bewaar je dan bij de api, zodat mochten ze de database hacken, ze ook de api server moeten hacken. Het liefst heb je de key server ook apart. Als je wilt kijken naar een role based account control (rbac) en je api niet te groot is, doe je dat in 2-4 weken. Dan wachtwoord vergeten mailtjes etc. Een rest api is bijvoorbeeld beheersbaar en uitbreidbaar