Investeer in digitale veiligheid van applicaties en voorkom herstelwerk achteraf

Een Low-Code Development Platform kan veel zorgen uit handen nemen bij het veilig houden van applicaties. Iedere aanpassing kan immers tot nieuwe en onvoorziene veiligheidsproblemen leiden. Een LCDP helpt je zicht te houden op het totaal. Zo werk je aan veiligheid ‘by design’.

Privacyschendingen en security breaches zijn niet alleen een probleem binnen applicaties, maar treden nog vaker en makkelijker op zodra er datauitwisseling plaatsvindt. Deze gegevensstromen blijven te vaak buiten beeld van de architect en worden pas achteraf gecontroleerd. Dan is er vaak veel herstelwerk nodig om alles weer op orde te krijgen. Hoe kan het gebruik van een low-code-platform dit voorkomen en bijdragen aan privacy en veiligheid by design?

Er zijn diverse redenen waarom organisaties hun applicaties ontwikkelen met een low-code-platform: ze willen sneller kunnen reageren op veranderingen in hun markt, ze willen sneller hun legacy-systemen uitfaseren, of ze hebben moeite om applicatieontwikkelaars te vinden. Het verhogen van hun digitale veiligheid is vrijwel nooit een reden. Terwijl juist security een heel valide argument is om voor low-code te kiezen. Want doordat high code-softwareontwikkeling zoveel tijd kost en er continu druk is vanuit de business om sneller software op te leveren, schiet aandacht voor veiligheid er vaak bij in.

Ingebakken beveiligingsmaatregelen

Een Low-Code Development Platform (LCDP) neemt in de eerste plaats alle zorgen uit handen rond de onderliggende technologie die nodig is om je applicaties up-and-running te houden. Denk hierbij aan veiligheidscontroles op het gebied van infrastructuur. Dit geldt zowel voor de cloud als voor on-premise gebruik. Daarnaast garandeert een LCDP dat je nadenkt over zaken als identity management en rolgebaseerde toegang voor gebruikers van de applicatie en voor softwareontwikkelaars. Maar ook over beleid waarbij ontwikkelaars elkaars werk controleren.

Ook bieden sommige low-code-platforms een functionaliteit voor het analyseren van security breaches. Zo bestaat er een LCDP die het ook identificeert als er onveilige dingen gebeuren aan de ontwikkelkant. Het platform herkent het als je bijvoorbeeld een invoerveld maakt en biedt op dat moment best practises aan voor hoe je dat input-veld moet beveiligen. Negeer je een best practise en kies je als ontwikkelaar voor een onveilige methode, dan wordt dit via het managementdashboard inzichtelijk voor de CTO.

Beveilig de volledige datastroom en niet alleen de applicatie

Er kan overigens best een goede reden zijn om te kiezen voor een onveilige manier. Vaak heeft een in low-code ontwikkelde applicatie meerdere interfaces naar high-code legacy-software. Aan die high-code-kant is de beveiliging lang niet altijd op het niveau dat je vandaag de dag zou wensen. Als je dan toch data wilt importeren uit een andere applicatie, kan dat tot gevolg hebben dat een mogelijke bedreiging ook de met low-code ontwikkelde applicatie kan binnendringen. Het dashboard in het LCDP toont dit, zodat de CTO op de hoogte is. Tegelijkertijd doet het LCDP de ontwikkelaar voorstellen voor andere maatregelen om dit gevaar te reduceren. Die opties worden aan de ontwikkelaar getoond in de vorm van de al genoemde best practises.

LCDP’s werken vaak met voorgedefinieerde templates die je kunt gebruiken bij je applicatieontwikkeling. Enkele zijn zo gemaakt dat de volledige datastroom wordt beveiligd en niet alleen de data in de desbetreffende applicatie. Normaal gesproken is het zo dat ontwikkelaars alleen maar de coderegels kunnen beveiligen die ze zelf programmeren. In dat geval moeten anderen op de IT-afdeling (meestal een architect) zicht houden op de datastroom en daarmee op het onderwerp “security by design“.

Full-stack-benadering

Het is ook mogelijk om  de volledige context en de daarbij horende dataflow centraal te stellen, een full stack-benadering dus. Daarmee neemt het platform een deel van die architectenrol over. Een voorbeeld: misschien werkt de te ontwikkelen applicatie wel met geanonimiseerde klantgegevens, maar worden die data daarna doorgestuurd naar de volgende applicatie die via het klantnummer de NAW-gegevens erbij plaatst. Vaak kennen ontwikkelaars in DevOps-teams dit soort gegevensstromen niet. Ze richten zich puur en alleen op het ontwikkelen van een applicatie. Dan is het fijn dat het LCDP die taak op zich neemt en er wél rekening mee houdt dat die geanonimiseerde klantdata in de volgende applicatie wordt samengevoegd met de NAW-gegevens.

Broncode en life-cycle management

Het is daarnaast ook prettig dat ontwikkelaars altijd de broncode kunnen bekijken die door het LCDP is gegenereerd. Je kunt, voor extra geruststelling de gegenereerde code met behulp van standaard codeanalyse controleren. Let er dan wel op dat de broncode die het LCDP genereert is geschreven in bekende programmeertalen, zodat die door iedere software-engineer te begrijpen is.

Een laatste punt dat ik in dit verband wil aanstippen is Life-Cycle Management (LCM). De meeste LCDP’s geven DevOps-teams proactief een seintje als het tijd is om een in gebruik zijnde applicatie nog eens te bekijken. Zo’n review vindt standaard eens in de zoveel tijd plaats, maar je kunt ook kiezen voor een LDCP waarin dit gebeurt als een applicatie waar een koppeling mee is een aanpassing ondergaat.

Die aanpassing kan immers invloed hebben op de gegevensstroom. Zo voorkom je dat er gaandeweg toch ineens onveilige datastromen ontstaan door aanpassingen in high code-applicaties.

Proactieve ondersteuning

“Privacy and security by design” is makkelijk gezegd, maar veel moeilijker gedaan. Zeker in een complex applicatielandschap met veel verschillende datastromen. Het is fijn te weten dat er LDCP’s zijn die je daar actief bij kunnen ondersteunen. Zo kun jij je weer richten om waar het echt om gaat: jouw businessuitdagingen.

Over de auteur: Arjan Waardenburg is lead solutions architect bij OutSystems.

Op de hoogte blijven van het laatste nieuws binnen je vakgebied? Volg Emerce dan ook op social: LinkedIn, Twitter en Facebook.