Standaarden:Beveiligd Gegevenstransport/FAQ
Het is onduidelijk hoe de 'SAAS certificaten' werken als één (1) leverancier meerdere SaaS applicaties aanbiedt
Moet iedere applicatie dan hetzelfde certificaat gebruiken? Houdt dat dan ook in dat iedere applicatie op dezelfde URL (er van uitgaande dat dat bedoeld wordt met ‘internetadres’ in de memo) dient te worden aangeboden? Dit levert ons inziens ongewenste risico’s op.
De naam 'SAAS certificaat' dekt niet geheel de lading, maar is ondertussen dermate breed gebruikt dat het waarschijnlijk meer problemen dan verduidelijking oplevert om de naamgeving aan te passen. Afhankelijk van de situatie kan het nodig zijn dat een Leverancier meerdere certificaten hanteert. Er moeten in dat geval meerdere certificaten worden aangeschaft. In de uitgegeven certificaten wordt dan aan het OIN/HRN een opvolgend nummer (001, 002, etc.) toegevoegd.
Als een Leverancier meerdere pakketten levert die in dezelfde keten aangesloten worden, dan zijn er twee aanpakken mogelijk:
- Beide pakketten maken gebruik van hetzelfde 'SAAS certificaat'. Aangezien de url per Aanleverpunt wordt geregistreerd, is het mogelijk om met meerdere pakketten binnen dezelfde keten te werken onder de vlag van dezelfde Leverancier.
- Elk pakket heeft zijn eigen 'SAAS certificaat'. In de keten administratie wordt dan ingericht alsof er twee 'losse' Leveranciers zijn. Afhankelijk van organisatorische en/of juridische eisen kan een van deze twee aanpakken de voorkeur krijgen.
Een derde variant is als een School zelf een Systeem 'levert', bijvoorbeeld door in een eigen (private) cloud een applicatie van een Leverancier te hosten. In dat geval kan niet het certificaat van de Leverancier worden gebruikt en moet de School zelf een certificaat gebruiken. Binnen de keten administratie krijgt de school dan ook de rol van Leverancier (voor haar eigen systeem).
Welke stappen moet ik als leverancier doen om met 'SAAS certificaten' te gaan werken?
De nieuwe PKI inrichting heeft een aanzienlijke impact op de beveiliging van de keten. Hieronder worden op hoofdlijnen de acties opgesomd die een Leverancier moet nemen:
- Aanvragen PKIoverheid-certificaat bij een geaccrediteerde certificatiedienstverlener
- Alle systemen: Installeren SAAS certificaat op eigen infrastructuur
- Bronsysteem: aanpassen controle van certificaat van Doelsysteem bij Dossier aanvraag
- Doelsysteem: toevoegen controle van certificaat van Bronsysteem bij ontvangst Notificatie
Hoe moet op Windows(IIS) servers TLS geconfigureerd worden
Het blijkt dat de correcte configuratie van tweezijdige TLS op Windows systemen in de praktijk lastig is. Wij hebben uit laten zoeken hoe dit geconfigureerd moet worden en hiervoor een stappenplan op laten stellen. Dit stappenplan is hier te vinden.
Implementatie 'work around' TLS op .NET niet (altijd) mogelijk
De 'work around' configuratie geeft een optie om TLS 1.2 niet op server maar op applicatie niveau af te dwingen. In de praktijk blijkt deze aanpak in .NET niet(!) te implementeren op dit moment.
De reden hiervoor is dat het niet mogelijk is om in een webapplicatie die binnen IIS draait om het niveau van een TLS 1.2 verbinding te controleren. Omdat een netwerk verbinding in IIS tot stand gebracht wordt (OS niveau) kan op applicatie niveau niet gekeken worden naar de de verbinding. De applicatie kan alleen kijken naar de data die over de verbinding verstuurd wordt.
Helaas maar inderdaad dat is wat ik in de vakantieperiode ook ben tegengekomen. Er zijn geen mogelijkheden om bijv. een global variabele in IIS te vullen met de TLS session metadata. Het is voor een .NET app achter IIS niet mogelijk om achter die TLS gegevens te komen. Hier wordt beschreven hoe IIS omgaat met SSL/TLS (iets dan andere servers).