OSO:2018/Architectuur/Beveiliging: verschil tussen versies

Uit Kennisnet Developers Documentatie
Naar navigatie springen Naar zoeken springen
 
Regel 70: Regel 70:
   
 
== TC controles==
 
== TC controles==
* [[OSO:2016/Architectuur/TCcontroles|Controles door het TC]]
+
* [[OSO:2018/Architectuur/TCcontroles|Controles door het TC]]
   
 
[[Categorie:Overstapservice Onderwijs]]
 
[[Categorie:Overstapservice Onderwijs]]

Huidige versie van 26 mrt 2018 om 10:45

Beveiligingsrequirements

In de OSO keten worden gegevens over leerlingen in het basis- en voortgezet- onderwijs getransporteerd tussen scholen. De gegevens zijn gekwalificeerd als vallende in risicoklasse II, zoals gedefinieerd in het document AV-23, opgesteld door de Registratiekamer. Deze informatie moet goed afgeschermd zijn tegen inzage en wijzigen door derden.

De hoofdveiligheidseisen die gelden en de bijbehorende maatregelen voor de OSO overdracht zijn:

  • Alleen vertrouwde Systemen mogen gebruik maken van OSO
    • Kwalificatie van Leveranciers van Systemen
    • Identificatie van Systemen door OIN in PKI Overheidscertificaat
    • Sessie uitgifte en controle in TC
    • Logging in TC
  • Alleen toegang tot Dossiers voor geautoriseerde gebruikers
    • Kwalificatie van Scholen
    • Beheer door Schoolmedewerkers van Aanleverpunten
    • Versleuteling van het transport van de Dossiers
    • OSO Register voor controle School-Leverancier relatie
    • Logging in Systemen

Kwalificatie Leveranciers

Om toegang te krijgen tot de OSO keten moeten zowel scholen als softwarelevernciers een kwalificatie traject doorlopen.

  • Schoolkwalificatie: Dit traject is beschreven op de Overstap Service Onderwijs site.
  • Leverancier kwalificatie: Informatie hier over is hier te vinden.

Aangesloten leveranciers

Certificaten

In OSO wordt gewerkt met zogenaamde 'SAAS certificaten'*; een leverancier wordt geauthenticeerd door zijn PKI Overheid certificaat. Een 'SAAS certificaat' bevat het OIN/HRN van de leverancier, wat doorgaans het KVK nummer van de Leverancier zal zijn. Er zijn twee speciale gevallen van het gebruik van een 'SAAS certificaat' voorzien:

  • De Leverancier heeft meerdere systemen die aangesloten worden op OSO én binnen het OSO verkeer onderscheiden moeten worden. In dit geval moet de betreffende Leverancier per systeem een certificaat aanmaken, waarbij in het OIN veld de optioneel postfix ('001', '002', etc.) wordt toegevoegd.
  • Een School werkt met een eigen (instantie van) een schoolsysteem. Een voorbeeld hiervan is wanneer een School zelf een pakket huurt/koopt en in een eigen 'private cloud' omgeving host. In dat geval kan het certificaat van de Leverancier NIET wordt gebruikt en moet de School zelf een certificaat inbrengen.

*Een betere naam zou 'SAAS instantie certificaat' zijn, maar deze naamgeving is ondertussen breed ingeburgerd.

Register

Het register is een onderdeel van het Traffic Center. Het bevat alle registraties van, en koppelingen tussen Leveranciers, Scholen* en Aanleverpunten. Het register wordt gevoed door OfficeHeart en mijnOSO. De volgende punten zetten de rol van het register uiteen. Het register houdt bij:

  • Scholen
    • Registratie van het BRIN, naam en de sector waarin de School actief is en of de school gekwalificeerd is voor OSO
  • Leveranciers
    • Registratie van het OIN/HRN en de naam van de Leverancier waaronder deze binnen OSO bekend is
  • Aanleverpunten:
    • Registratie van de internetlocatie (URL) waarop een schoolsysteem bereikt kan worden. Met de Aanleverpunt registereren aanroep kan deze vanuit het Schoolsysteem worden beheerd.
    • Registratie van welke Leverancier namens een School mag optreden. Vanuit mijnOSO kan een Schoolbestuurder de Aanleverpunten van de School beheren. In het Register wordt per Aanleverpunt opgeslagen welk Systeem (Leverancier) dit Aanleverpunt 'implementeert'.
  • Beheren Aanleverpunten. Bij het invoeren van een Aanleverpunt in mijnOSO worden de volgende velden geregistreerd:
    • BRIN van de School (deze wordt vanuit OfficeHeart ingevoerd door Kennisnet, een schoolbestuurder kan deze waarde niet zelf beheren)
    • Aanleverpunt-index (APindex). Een doortellend numeriek veld dat geen eigen betekenis heeft. Samen met de BRIN vormt de APindex een unieke combinatie die een Aanleverpunt identificeert.
    • Een tekstlabel, dit wordt deels vast ingevoerd (BRIN en APindex) en is deels een vrij veld voor het aangeven van bruikbare informatie ("Aanleverpunt voor vestiging X")
  • Aanleverpunten in Schoolsystemen. Een Aanleverpunt wordt beheerd in mijnOSO en vastgelegd in het Register. In het Schoolsysteem moet overeenkomend met de informatie in het Register het Aanleverpunt worden aangemaakt. De eigenaar van de Schoolaccount op mijnOSO moet daarbij de informatie over het Aanleverpunt doorgeven aan de eindgebruiker in het Schoolsysteem die het Aanleverpunt beheert.
  • Registreren URLs bij Aanleverpunten. De url voor het Aanleverpunt wordt niet via mijnOSO beheerd, maar vanuit het Schoolsysteem ingesteld door de registreerURL aanroep. Op het moment dat een Schoolsysteem deze aanroep uitvoert, controleert het Traffic Center of het aanroepende systeem in het Register geregistreerd is als het systeem bij dit Aanleverpunt. Alleen als dit het geval is, wordt de aanroep geaccepteerd.

*'School' kan hier slaan op de instelling, (hoofd)vestiging of administratieve eenheid.

Controles binnen het proces

  • Account beheer mijnOSO. Tijdens het School-kwalificatie traject wordt vastgelegd namens welke school (BRIN(4)) een bestuurder mag optreden in mijnOSO.
  • Aanleverpunt invoer. Het aanmaken van nieuwe Aanleverpunten wordt telefonisch ondersteund vanuit Kennisnet. In mijnOSO kan een eindgebruiker alleen pakketten van gekwalificeerde Leveranciers kiezen bij een Aanleverpunt.
  • AP validatie. Op het moment van aanmaken/beheren van een Aanleverpunt binnen een Schoolsysteem vinden twee controles plaats:
    • Op basis van het 'SAAS-certificaat wordt vastgesteld dat de Leverancier toegelaten is op OSO.
    • Op basis van de informatie in de aanroep (BRIN-APindex) wordt vastgesteld of de Leverancier voor dit Aanleverpunt is vastgelegd door de School) in het Register.
  • Sessie aanvragen. Bij het aanvragen van een Sessie wordt:
    • Op basis van het 'SAAS-certificaat wordt vastgesteld dat de Leverancier toegelaten is op OSO.
    • Op basis van de informatie in de aanroep (BRIN-APindex) wordt vastgesteld of de Leverancier voor dit Aanleverpunt is vastgelegd door de School) in het Register. NB:Een Aanleverpunt mag alleen een dossier opvragen namens de BRIN die bij het Aanleverpunt is vastgelegd(!).
    • In het Register wordt gecontroleerd dat het Aanleverpunt actief is, dat wil zeggen: De School heeft de schoolkwalificatie voor OSO succesvol doorlopen.
    • Er wordt een sessieID toegekend, waarbij door het Traffic Center de combinatie bronBRIN, bronAPindex, zoeksleutel (PGN) wordt vastgelegd.
  • Dossier opvragen. Een Bronsysteem valideert of het 'SAAS certificaat' van het aanvragende Bronsysteem valide is.
  • Sessie controleren. Een Bronsysteem moet voordat een Dossier wordt uitgeleverd, de aanvraag van het Doelsysteem valideren bij het Traffic Center. Op basis van het sessieID wordt gecontroleerd of de doelBRIN, doelAPindex en zoeksleutel overeenkomen met de bij deze sessieID geregistreerde waarden.

Logs en monitoring


TC controles