Security-by-design kan applicatieontwikkeling vereenvoudigen

Dat het custom management systeem dat ik bouw telkens meer vorm begint te krijgen is natuurlijk heerlijk. Bij een dergelijk bouwproces is het ook belangrijk om rekening te houden dat alleen gebruikers die bevoegd zijn of te wel de juiste autorisatie hebben bepaalde acties kunnen uitvoeren. Het is belangrijk dat het security ingebouwd zit in het systeem. Of in andere woorden security-by-design is belangrijk.

In het Wpx framework is er behoefte aan autorisatie op het niveau van een post die als “root” functioneert. De autorisaties die er op die post zijn, bepalen of de gebruiker iets wel of niet mag. In de applicatie waarmee ik het prototype ontwikkel heb je een “company”, “hostingbase” en “hostingpackage”. De toegang tot een bepaalde “company” post bepaald dat je geautoriseerd bent op de daaraan gekoppelde “hostingbase” en “hostingpackage” posts.

Als security-by-design principe wordt bij elke actie die door het custom mangement systeem wordt uitgevoerd altijd eerst de “root” post gezocht, wat in dit geval een “company” post is. Daarna wordt er gekeken of dat de gebruiker geautoriseerd is op die post. Als dat het geval is, dan mag de actie worden uitgevoerd. Als dat niet het geval is dan blokkeert het systeem.

Alleen al het feit dat je in staat moet zijn om de “root” post te vinden maakt security-by-design zo belangrijk. Stel dat onder bepaalde omstandigheden in het custom management systeem deze post niet te vinden is. Dan heb je dus al een probleem dat je moet oplossen. Of mogelijk nog erger dat deze post om een of andere reden niet betrouwbaar is vast te stellen of zelfs ontbreekt voor een bepaalde bewerking.

Daarom is het zo belangrijk om bij elke stap in het bouwproces rekening te houden met dit principe. Als het niet mogelijk is om de “root” post vast te stellen, dan moeten er andere oplossingen worden gekozen waarbij dat wel het geval is.

Het mooie aan dit systeem is dat zodra je de “root” post eenmaal hebt je centraal kan vaststellen of dat de gewenste autorisatie aanwezig is. Sterker nog de actie zelf hoeft alleen de “root” post voor het systeem klaar te zetten. Vervolgens controleert het autorisatiesysteem of dat de gebruiker die de actie probeert uit te voeren bevoegd is. Alleen als dat het geval kan de gebruiker door en in andere gevallen wordt de actie geblokkeerd.

Het custom management systeem heeft hierdoor een gelaagdheid gekregen, waarbij eerste de routing de actie naar de juiste functie doorstuurt. Deze functie zet alle variabelen klaar voor verdere verwerken. Daarna wordt de actie doorgezet naar een functie die lager in het systeem zit. Op dat niveau kan dan meteen worden gekeken of dat de gebruiker geautoriseerd is.

Op applicatieniveau hoef je daardoor nauwelijks nog bewust te zijn van de autorisaties. Het enige dat je moet doen is er voor zorgen dat de “root” post beschikbaar is. Wanneer dat niet zo is, dan blokkeert het systeem ook automatisch omdat er geen autorisaties zijn om te controleren. Op deze manier zorgt security-by-design voor zowel veiligheid áls gemak voor de ontwikkeling op basis van het custom management systeem op applicatieniveau.