OSO:2018/beveiliging/FAQ: verschil tussen versies
< OSO:2018 | beveiliging
Naar navigatie springen
Naar zoeken springen
(Nieuwe pagina aangemaakt met '=== Het is onduidelijk hoe de 'SAAS certificaten' werken als één (1) leverancier meerdere SaaS applicaties aanbiedt === '''Moet iedere applicatie dan hetzelfde ce...') |
(De pagina is leeggehaald) |
||
| (Een tussenliggende versie door een andere gebruiker niet weergegeven) | |||
| Regel 1: | Regel 1: | ||
| − | === 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.'''<br/> |
||
| − | 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.<br/> |
||
| − | Als een Leverancier meerdere pakketten levert die op OSO 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 OSO te werken onder de vlag van dezelfde Leverancier. |
||
| − | * Elk pakket heeft zijn eigen 'SAAS certificaat'. In de OSO 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.<br/> |
||
| − | 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 OSO administratie krijgt de School dan ook de rol van Leverancier (voor haar eigen systeem). |
||
| − | |||
| − | === Welke stappen moet ik als 'OSO 15 leverancier' doen om met 'SAAS certificaten' te gaan werken? === |
||
| − | De nieuwe PKI inrichting heeft een aanzienlijke impact op de beveiliging van OSO. Hieronder worden op hoofdlijnen de acties opgesomd die een Leverancier moet nemen: |
||
| − | # Aanvragen [[OSO:2018/beveiliging/client_certificaten|PKIoverheid-certificaat]] bij een geaccrediteerde [https://www.logius.nl/diensten/pkioverheid/aanschaffen/ 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 |
||
| − | |||
| − | === Blijven de huidige Aanleverpunten geldig/actief? === |
||
| − | De huidige Aanleverpunten kunnen als 'actief' geregistreerd blijven zowel in de Schoolsystemen als in het TC/Register. Er is '''geen''' gebruikershandeling nodig na het verwijderen van het AP-certificaat. Wanneer een eindgebruiker in het Aanleverpunt een wijziging invoert (en bij het aanmaken van een nieuw Aanleverpunt) moet het Schoolsysteem het [[OSO:2018/Aanleverpunt_Registreren|Aanleverpunt (opnieuw) registreren]]. (Waarbij optioneel ook de [[OSO:2018/Controleren_Aanleverpunt|AP-sleutel moet worden gecontroleeerd]].) |
||
| − | |||
| − | === 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 [[OSO:2018/beveiliging/client_authentication_windows|hier]] te vinden. |
||
| − | |||
| − | === Implementatie 'work around' TLS op .NET niet (altijd) mogelijk=== |
||
| − | De [[OSO:2018/beveiliging/protocollen#Mogelijke_oplossing|'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. <br> |
||
| − | |||
| − | 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.<br> |
||
| − | |||
| − | 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. [https://gist.github.com/SamuelChristie/13a2a29e74c189bcfd9b#iis Hier] wordt beschreven hoe IIS omgaat met SSL/TLS (iets dan andere servers). |
||
| − | |||
| − | [[Categorie:Overstapservice Onderwijs]] |
||
| − | [[Categorie:Book OSO|89]] |
||