De beveiligingswereld bevindt zich in een constante staat van evolutie, waarbij vrijwel elke nieuwe release nieuwe methoden met zich meebrengt die ontworpen zijn om eerder ontdekte beveiligingslekken te omzeilen. Een goede ICT architectuur is cruciaal voor een soepel verlopend bedrijfsproces. Door de steeds groeiende behoefte aan veiligere softwaresystemen en het ontbreken van een wondermiddel dat bescherming garandeert, is een holistische aanpak, waarbij alle mogelijke risico's in aanmerking worden genomen, noodzakelijk geworden. Het Security through Architecture Design (SATIS) initiatief is uit deze noodzaak geboren: de algemene toepassing van ontwerpbeginselen zoals het Single Responsibility Principle (SRP), Separation of Concerns (SoC), Dependency Inversion en andere hebben software-ingenieurs niet alleen in staat gesteld begrijpelijker programma's te schrijven, maar ook hun onderhoudscycli gestroomlijnd. Als zodanig werd het noodzakelijk om deze concepten uit te breiden buiten het bereik van individuele projecten en ze af te dwingen op architectuurniveau. Met dit artikel willen wij u een kort overzicht geven van hoe u deze ontwerpprincipes in uw organisatie kunt toepassen.
SRP: hoe veilige code te schrijven
Als software engineer bent u zich waarschijnlijk al bewust van het belang van het schrijven van veilige code. Het is echter belangrijk te benadrukken dat de veiligheid van uw software niet alleen afhangt van de code die u schrijft: het gaat er meer om hoe de code is geschreven en welke ontwerpprincipes u volgt. Met andere woorden, die veiligheidsproblemen zijn vaak het gevolg van de code die u niet kunt zien. In die zin is een van de belangrijkste regels voor het schrijven van veilige code het naleven van het Single Responsibility Principle (SRP). Hoewel het onderscheiden van de verschillende rollen die een stuk code kan spelen belangrijk is in elk systeem, is het vooral relevant binnen een applicatie. Een enkel stuk code moet een enkele verantwoordelijkheid hebben, anders is het vatbaar voor afhankelijkheidsproblemen, de belangrijkste oorzaak van beveiligingsproblemen.
SoC: hoe uw app op te breken
Een ander belangrijk ontwerpprincipe is de Separation of Concerns (SoC): het idee dat code die één specifieke functie uitvoert moet worden gescheiden van code die een bredere focus heeft. Wanneer het correct wordt uitgevoerd, stelt het ontwikkelaars in staat zich op één taak tegelijk te concentreren, terwijl ze ook gemakkelijk kunnen profiteren van herbruikbare code. Op die manier leidt het tot een beter onderhoudbaar systeem, omdat de inspanningen voor refactoring niet zo kritisch zijn, en het maakt het ook gemakkelijker voor een team om te schalen. Dit principe is bijzonder relevant in de context van beveiliging. Veel beveiligingsproblemen worden veroorzaakt door afhankelijkheden tussen verschillende stukken code; door deze afhankelijkheden te doorbreken door de concerns van je applicatie te scheiden, kun je veiligere code schrijven. Als u bijvoorbeeld een app hebt met een gebruikersbeheerfunctie en een boekhoudfunctie, zou het gevaarlijk zijn om financiële gegevens op te slaan en te verwerken als de gebruikersinformatie in dezelfde applicatie wordt opgeslagen. Om dit te voorkomen, moet u de app daarom opsplitsen in twee onafhankelijke toepassingen.
Omkering van controle
Een imperatieve benadering van het bouwen van software is gebaseerd op het idee dat beslissingen het best genomen kunnen worden door de componenten op het laagste niveau, zodat je alles in de software op één niveau kunt afhandelen. Deze aanpak, bekend als "inversion of control", is een van de meest effectieve middelen om complexiteit te vermijden en afhankelijkheden te doorbreken. Deze aanpak, die een lange geschiedenis heeft in de softwarearchitectuur en -engineering, gebruikt een concept op hoog niveau als basis en creëert daar vervolgens een abstractie omheen die geschikt is voor verschillende gebruikssituaties (zoals bedrijfslogica, een API of systeemcontrole). Deze abstractie wordt vervolgens geïmplementeerd door alle componenten die ze nodig hebben: het is een implementatie van het high-level concept dat kan variëren naargelang de use case.
Laatste gedachten
In dit artikel hebben we ons gericht op de richtlijnen die u kunnen helpen een veiliger systeem te bouwen, maar dit is niet het einde van het verhaal: het is essentieel om uw beveiligingshouding regelmatig te evalueren en uw aanpak aan te passen aan de huidige bedreigingen. Dit is een dynamisch proces zonder een uniforme oplossing, en daarom kan het moeilijk zijn om een consistent beveiligingsniveau te handhaven.