eIDAS is volop in ontwikkeling en in de actualiteit. Het team van House of Trust bevindt zich in de unieke positie dat ze onlangs een Qualified Trust Service Provider heeft gelanceerd. Op 4 december 2024 organiseert House of Trust een webinar om beknopt toe te lichten wat dit inhoudt. We bieden je ruim de gelegenheid om vragen te stellen en in gesprek te gaan met onze teamleden.
Een van de onderwerpen die we introduceren is het ontwikkelen van de vertrouwensdienst zelf. Wij ontwikkelden een dienst voor de uitgifte van certificaten voor gekwalificeerde handtekeningen, maar de principes in het ontwerpproces zijn voor gedeeld over alle vertrouwensdiensten die Gekwalificeerd moeten zijn.
Voor veel mensen die willen surfen op de golf van eIDAS is het complex om de materie en haar structuur te doorgronden. In dit webinar bieden we je houvast en delen we de lessen die we de afgelopen jaren hebben geleerd tijdens de ontwikkeling van onze eigen QTSP (Qualified Trust Service Provider).
Hoe ontwikkel je een gekwalificeerde vertrouwensdienst?
Bij het ontwikkelen van de software die je vertrouwensdienst handen en voeten geeft moet je er vanaf het eerste moment rekening mee houden dat er beoordeeld wordt op kwaliteit, beoordeling van risico’s en de mogelijkheid om verantwoording af te leggen. Met die bril moet je kijken naar de manier waarop je software ontwikkelt, uitrolt naar de productie-omgeving, maar ook hoe binnen die software verantwoording afgelegd kan worden over de processen die erbinnen zijn uitgevoerd.
Je zult een balans moeten vinden tussen enerzijds snel en iteratief werken zoals software meestal wordt gemaakt en langzame en nauwkeurige ‘change management’ processen. Zaken als ultrasnelle ‘continuous deployment’, ‘a/b-testing’ of paradigma’s als ‘failing fast’ pas je beter niet zomaar toe in de processen om een vertrouwensdienst te bouwen en onderhouden.
Maar wat dan wel? Wij hebben een uitgebreid ontwerp gemaakt voordat we starten. Dat wijkt misschien af van een bondige product vision en veel ontwerp in user stories en neigt naar een waterval-aanpak. Toch is het belangrijk, want het moet aantoonbaar zijn dat het ontwerp is beoordeeld en goedgekeurd. In alle processen binnen een QTSP spelen vastgelegde goedkeuringsprocessen een cruciale rol! Terwijl er aan het ontwerp geschreven wordt, kunnen ontwikkelaars natuurlijk wel starten met proof-of-concepts en vooronderzoek van aspecten van de software, maar uiteindelijk moet het ontwerp gevolgd worden en kan het zijn dat die voorbereiding overboord gaat. Na goedkeuring van het ontwerp, hebben we de use cases daaruit omgezet naar user stories en is het team die gaan implementeren, waarbij de productowner en architect continue meekijken of het ontwerp juist geïnterpreteerd en geïmplementeerd wordt.
Verder is het softwareontwikkelproces en de waarborgen die daarin zijn voorzien essentieel. De organisatie heeft risicomanagement geimplementeerd en kan het niet anders dan dat er risico’s binnen zelf-ontwikkelde software zijn geidentificeerd. Denk aan zelf geproduceerde bugs, anti-patterns, kwetsbaarheden in runtimes, dependencies en omringingende software. Het softwareontwikkelproces moet voorzien in mitigerende maatregelen voor dat soort risico’s, bijvoorbeeld met peer reviews, pull requests, een conventie voor branching van de code. Maar ook het scannen van software op anti-patterns, kwetsbare afhankelijkheden, etc. Het proces moet voorzien in testen en dat moet gedocumenteerd en navolgbaar gebeuren. Dat kan zowel procedureel of automatisch, maar in beide gevallen moet het proces goed worden uitgedacht en minutieus uitgevoerd en vastgelegd.
De resultaten van het softwareontwikkelproces - hoe goed ook - is beter geen automatische deployment. Wij kozen ervoor om releases die uit het ontwikkelproces kwamen rollen in het change-managementproces in te brengen. Het change-managementproces is een overkoepelend proces dat veel breder is dan alleen het goedkeuren van deployments, maar het kan als generiek, organisatiebreed proces daar wel goed voor gebruikt worden. Het change-managementproces zorgt ervoor dat impact en risico’s worden bepaald en beoordeeld door het juiste gremium. Zij controleren testrapporten en geven vanuit hun individuele perspectief akkoord op verdere uitrol en acceptatie van de risico’s die daaraan kleven. Uiteraard wordt dit vastgelegd, zodat ook jaren later deze beslissing en de ratio daarachter nog kan worden achterhaald.
Binnen de software spelen vergelijkbare randvoorwaarden. De software ondersteunt een proces en de stappen in dat proces en de keuzes die daarbinnen gemaakt worden moeten minutieus worden vastgelegd. Wij kozen ervoor een audit trail te implementeren die een hash van de voorgaande regel opneemt in de regel die geschreven wordt. Hiermee wordt vastlegging opgebouwd en kan de integriteit ervan worden bewezen.
Uiteraard speelt ook identity & access management een rol en moeten de informatiesecuritypolicies van de organisatie hierin worden geïmplementeerd. Dat is is gebeurd moet weer bewezen (kunnen) worden.
Wil je meer weten over waar je aan moet denken als je wilt beginnen met bouwen aan je vertrouwensdienst? Onze architect Aniek is aanwezig op het webinar dat we op 4 december organiseren over onze ervaringen met het ontwikkelen van een Qualified Trust Service Provider: “Becoming Q”!
Aniek Hannink
Anniek Hannink is als consultant verbonden aan House of Trust. Als Architect overziet ze de de kader waarbinnen de dienst ontwikkeld moet worden en waarbinnen de infrastructuur geïmplementeerd moet worden.
Schrijf je in!
Werk je aan diensten rondom identiteit, elektronische handtekeningen of andere vertrouwensdiensten? Wil je deze op het hoogste kwaliteitsniveau aanpakken? Schrijf je dan in voor ons webinar "Becoming Q"! Ons team heeft de afgelopen jaren een QTSP gerealiseerd en met succes laten certificeren. We delen graag onze ervaringen met je!
Datum: 4 december 2024
Tijd: 15:00 - 16:30
Plaats: Online:
Disclaimer
Het mag duidelijk zijn dat kleine lettertjes ons niet vreemd zijn. In dit webinar deelt het team van House of Trust haar professionele werkervaring van de afgelopen jaren. We zullen niet ingaan op de specifieke situatie of details van de QTSP die we hebben opgezet.
Comments