Hoofdinhoud
1. Inleiding
Vanaf 19 februari 2018 is het systeem BSN-koppelregister Polymorf Pseudoniem (hierna te noemen BSNk PP) beschikbaar voor afnemers. BSNk PP is een voorziening in het kader van de Wet Digitale Overheid (WDO) die het mogelijk maakt om publieke en private authenticatiemiddelen te gebruiken in het publiek domein.
Dit document beschrijft het niveau van de dienstverlening voor alle Afnemers die zijn aangesloten op BSNk PP en maakt de (service) afspraken concreet.
BSNk biedt een aantal (deel-)diensten aan, te weten: Activatie, Transformatie, Sleutelbeheer, Stelselbeheer en InzageRegister. Hieronder wordt kort de functie van deze diensten uiteengezet.
BSNk-Activatie
BSNk biedt een activeringsdienst aan waar een erkende Middeluitgever (MU) een BSN kan activeren. Om de kans op fouten te minimaliseren moet het BSN en de bijbehorende persoonsgegevens gevalideerd worden bij de Basisregistratie Personen (BRP). Als een MU zelf deze mogelijkheid niet heeft, dan voert het BSNk deze validatie uit. Vervolgens wordt er een aantal cryptografische bewerkingen uitgevoerd op het BSN, zodat er een Polymorf Pseudoniem (PP) en een Polymorfe Identiteit (PI) ontstaan, specifiek voor - en alleen bruikbaar door – de betreffende MU en daaraan gelieerde Authenticatiediensten.
BSNk-Transformatie
Als een erkende Authenticatiedienst (AD) een Gebruiker wil identificeren ten behoeve van een Dienstverlener (DV) transformeert deze een PI naar een Versleutelde Identiteit (VI). Uit de VI kan de DV vervolgens de originele BSN afleiden. Wanneer de DV niet gemachtigd is om een BSN te ontvangen, dan zal er een Versleuteld Pseudoniem (VP) worden aangeboden. Deze kan gebruikt worden voor publieke diensten zonder behoefte aan of recht op een BSN. Het BSNk-InzageRegister werkt bijvoorbeeld op basis van deze VP’s. De AD kan deze transformatie zelf uitvoeren met een BSNk Transformatie-HSM. Maar een AD kan deze transformatie ook door de dienst BSNk-Transformatie uit laten voeren.
BSNk-Sleutelbeheer
Het BSNk kent ook een Sleutelbeheerfunctie, die ervoor moet zorgen dat alle partijen (AD’s en DV’s) over het juiste sleutelmateriaal kunnen beschikken om (polymorfe) cryptografie werkend te krijgen. Deze functie is ook verantwoordelijk voor de verstrekking van de benodigde BSNk- Transformatie HSM-sleutels, waarbij de BSNk-Transformatie-HSM’s bij de AD’s zelf kunnen draaien.
BSNk-Stelselbeheer
BSNk-Stelselbeheer zorgt voor de publicatie van de Autorisatie Lijst BSN (ALB). In deze lijst staan de DV’s opgenomen waarvan is toegestaan dat zij gebruikmaken van BSN’s. Daarnaast wordt binnen deze functie de metadata geaggregeerd.
In het BSNk-netwerk wordt SAML-metadata gebruikt voor het beschrijven van de Uniform Resource Locators (URL's) en certificaten, die worden gebruikt op de verschillende koppelvlakken. Actuele metadata is van belang om twee redenen:
- De metadata geeft weer voor welke rol en op welk betrouwbaarheidsniveau een Afnemer is toegetreden. Met andere woorden, op basis van de metadata wordt bepaald wie wat mag in het netwerk.
- De metadata geeft weer hoe systemen van Afnemers kunnen worden benaderd en met welke certificaten deze systemen zijn te authentiseren. Hierdoor speelt de metadata een belangrijke rol in het bewaken van de integriteit en authenticiteit van de verklaringen en gegevens die door het netwerk worden geleverd.
Alle Afnemers leveren hun metadata conform specificaties aan. BSNk-Stelselbeheer controleert de gepubliceerde metadata en aggregeert dit vervolgens in één centraal bestand.
BSNk-InzageRegister
Het BSNk-InzageRegister is bedoeld om ervoor te zorgen dat een Gebruiker centraal, via Mijnoverheid.nl, een overzicht kan krijgen van de authenticatiemiddelen, die bruikbaar zijn in het Publieke Domein. Het BSNk-InzageRegister wordt primair gevuld door de MU’s, die middel- statusgegevens aan moeten leveren met een VP van de Belanghebbende. Deze statusgegevens kunnen niet gebruikt worden om Belanghebbenden te identificeren. Hierdoor is de (privacy)gevoeligheid van de gegevens bij het InzageRegister zo minimaal mogelijk. Daarnaast informeert BSNk- Activatie ook bij elke activatie het BSNk-InzageRegister, zodat de compleetheid van de inzagegegevens niet uitsluitend leunt op de correcte aanlevering van de MU’s.
Doel
Deze SNO geeft Afnemers van BSNk PP duidelijkheid over het niveau van de dienstverlening voor BSNk PP en maakt de (service-)afspraken concreet. De verantwoordelijkheid voor de BSNk PP-dienstverlening begint op het moment dat een compleet en correct bericht door BSNk PP is ontvangen en eindigt op het moment dat een correct bericht BSNk PP heeft verlaten (i.c. aan de betreffende Afnemer is verzonden).
Doelgroep
Dit document is bedoeld voor de Afnemers van BSNk PP. Een Afnemer is een publiekrechtelijke of privaatrechtelijke organisatie, die voor de uitoefening van die publieke taak, als een Authenticatiedienst, MU, Toegangsdienst, Makelaar, Machtigingenregister of als eIDAS- berichtenservice optreedt. BSNk PP wordt niet direct geleverd aan Dienstverleners of burgers.
Beheer
Logius is eigenaar van de SNO BSNk PP. Jaarlijks vindt er een evaluatie plaats van de SNO door de leden van het Operationeel Overleg BSNk PP.
Logius BSNk PP informeert alle Afnemers wanneer zij wijzigingen in de SNO doorvoert. Wijzigingen op de afgesproken dienstenniveaus moeten aan het Tactisch Overleg worden voorgelegd en worden goedgekeurd. Overige wijzigingen stellen de leden van het Operationeel Overleg BSNk PP vast. Wijzigingsverzoeken mogen worden ingediend via het Logius Servicecentrum.
Geldigheid SNO
Afnemers maken gezamenlijk gebruik van BSNk PP. BSNk PP heeft een gelimiteerde capaciteit. Wanneer het aantal berichten, onder invloed van het gebruik door Afnemers, per seconde hoger is dan de maximale capaciteit, kan Logius de werking van BSNk PP niet meer garanderen en vervallen de afspraken uit deze SNO.
Logius heeft maatregelen genomen om de continuïteit te waarborgen. Echter, Afnemers kunnen op de afspraken in deze SNO geen aanspraak maken als de dienstverlening wordt verstoord door:
- het toedoen als Afnemer
- het overschrijden van de capaciteitsgrenzen
- calamiteiten bij Logius of haar infrastructuur, waar tegen geen of slechts beperkt maatregelen te treffen zijn, zoals aardbevingen, terroristische aanslagen etc.
- een verstoring van (publieke) internet(verbindingen)
De gehanteerde normen en eisen zijn voor alle Afnemers gelijk. De dienstverlening wordt niet tegen afwijkende eisen of afwijkende voorwaarden aan afzonderlijke (groepen van) Afnemers geleverd.
Aansluiten en toegang tot BSNk PP
Om gebruik te kunnen maken van BSNk PP, dient een Afnemer aangesloten te worden. Hiertoe dient men te voldoen aan de aansluitvoorwaarden en daarnaast een verzoek tot aansluiten in te dienen bij het Ministerie van Binnenlandse Zaken en Koninkrijkrelaties.
Meer informatie over de aansluitvoorwaarden en het aansluitproces is aan te vragen via Logius.
Leeswijzer
Er zijn twee inhoudelijke hoofdstukken.
- Hoofdstuk 2 - Serviceniveaus. Hierin staan de serviceniveaus voor BSNk PP. Een beschrijving van de afgesproken prestatie- indicatoren (het wat) over de beschikbaarheid, performance, continuïteit en beveiliging van BSNk PP.
- Hoofdstuk 3 - Beheerprocessen. Dit hoofdstuk beschrijft de processen (het hoe), die aangegeven hoe de prestatie-indicatoren worden gerealiseerd.
2. Serviceniveaus BSNk PP
Dit hoofdstuk beschrijft per service-onderdeel wat de serviceniveaus voor BSNk PP zijn. De kwaliteit van BSNk PP als geheel wordt geborgd door de serviceniveaus op de dienstonderdelen.
De volgende service-onderdelen worden beschreven:
- Beschikbaarheid van BSNk PP
- Beschikbaarheidsvenster
- Servicevenster
- Onderhoudsvenster
- Performance van BSNk PP
- Continuïteit van BSNk PP
- Informatiebeveiliging van BSNk PP
BSNk PP bestaat uit verschillende deeldiensten:
- BSNk-Activatie
- BSNk-Transformatie
- BSNk-Sleutelbeheer
- BSNk-Stelselbeheer
- BSNk-InzageRegister
Waar relevant wordt onderscheid gemaakt tussen deze deeldiensten.
Beschikbaarheid van BSNk PP
Openstellingvenster
De periode per dag dat BSNk PP wordt geacht toegankelijk te zijn, oftewel de tijd waarbinnen een omgeving, inclusief functionaliteit, door de Afnemers te benaderen is. Alle omgevingen kennen een openstellings- venster van 24 uur voor alle dagen per jaar. Logius geeft echter geen garanties af voor de werking van de dienst in het openstellingsvenster, met uitzondering van de tijden binnen het beschikbaarheidsvenster.
Beschikbaarheidsvenster
Het beschikbaarheidsvenster zijn de tijden binnen het openstellingsvenster, waarbinnen Logius garanties voor beschikbaarheid van BSNk PP afgeeft.
Omgeving | Openstellings- venster | Beschikbaarheidsvenster | Minimaal te realiseren per maand (excl. gepland onderhoud) |
---|---|---|---|
Productieomgeving | 7 x 24 | Werkdagen van 8.00 uur tot 17.00 uur | 99,2 % |
Ketentestomgeving (preproductie) | 7 x 24 | Werkdagen van 8.00 uur tot 17.00 uur | 98 % |
Tabel: Performance indicatoren Beschikbaarheidsvenster
Buitengebruikstelling van BSNk PP door Logius ten behoeve van spoedonderhoud wordt, indien mogelijk, altijd vooraf gemeld aan de afnemers. Dit wordt gerapporteerd als onbeschikbaarheid van de dienst. Indien het een calamiteit betreft wordt dit zo spoedig als mogelijk gemeld.
Zoals aangegeven in Hoofdstuk 1, kent BSNk PP verschillende (deel-) diensten. Het is dus mogelijk dat één of meerdere diensten niet of beperkt beschikbaar zijn.
Het meten van beschikbaarheid van BSNk PP
De performance-indicator voor de beschikbaarheid wordt als volgt gemeten:
(Uren per maand in beschikbaarheidsvenster -/- uren onbeschikbaar -/- uren gepland onderhoud) gedeeld door (uren per maand in beschikbaarheidsvenster -/- uren gepland onderhoud) x 100 = performance-indicator.
Servicevenster
Het servicevenster is de tijd waarbinnen Afnemers Logius kunnen benaderen voor ondersteuning. Tijdens onderstaand servicevenster is het Servicecentrum van Logius bereikbaar voor meldingen over de dienstverlening en het product. Denk daarbij aan incidenten, vragen en/of klachten.
Type dienstverlening | Norm productieomgeving | Norm ketentestomgeving (preproductie) |
---|---|---|
Voor Afnemers het:
|
Werkdagen van 8.00 uur tot 17.00 uur | Werkdagen van 8.00 uur totb17.00 uur |
Voor Afnemers het:
|
24 uur per dag, 7 dagen per week, alle dagen van het jaar. Stand-by dienst. NB: applicatieve incidenten kunnen alleen op werkdagen van 8.00 uur tot 17.00 uur worden aangemeld. | N.v.t |
Tabel: Performance indicatoren voor Servicevenster BSNk PP
De reactietijden voor vragen of klachten staan in onderstaande tabel.
Reactietijd | Norm |
---|---|
Binnen 3 werkdagen | Per maand wordt 99% van de vragen of klachten volgens de norm beantwoord. |
Tabel: Reactietijden voor behandeling van BSNk PP vragen of klachten door Afnemers
Onderhoudsvenster
Het onderhoudsvenster stelt Logius in staat op vooraf vastgestelde tijdsvensters regulier onderhoud op BSNk PP uit te voeren. Dit onderhoud wordt via het Releasebeheer proces uitgevoerd (zie de paragraaf Releasebeheer BSNk PP).
Tijdens het onderhoudsvenster kan het voorkomen dat (onderdelen van) BSNk PP tijdelijk niet beschikbaar is (zijn). Afnemers worden hier minimaal 10 werkdagen vooraf van op de hoogte gesteld via een e- mailbericht. In dat bericht wordt, indien mogelijk, aangegeven welke onderdelen onbeschikbaarheid zullen kennen, en hoe lang de onbeschikbaarheid zal duren.
Logius streeft ernaar om die periode zo klein mogelijk te houden. Het onderhoudsvenster valt onder gepland regulier onderhoud. Daarom nemen we dit niet mee in de beschikbaarheidsprestatie-indicator (zie de paragraaf over het meten van beschikbaarheid).
Indien het onderhoud vereist dat er ook wijzigingen uitgevoerd dienen te worden in de Infrastructuur of Applicatie(s) van de Afnemer dan zal dit minimaal 1 maand van tevoren gemeld worden door Logius.
Soort onderhoud | Onderhoudsvenster productie | Onderhoudsvenster ketentestomgeving (preproductie) |
---|---|---|
Gepland applicatief onderhoud voor de dienst. | Maximaal 1 keer per maand één onderhoudsvenster. De eerste dinsdag van de maand. Duur: maximaal 6 uur per onderhoudsvenster (00:00 tot 06:00 uur). NB: Wanneer het onderhoudsvenster op een erkende feestdag valt, wordt het onderhoud op de eerstvolgende dinsdag uitgevoerd. |
Onderhoud wordt gedurende kantoortijden uitgevoerd. |
Gepland technisch onderhoud voor de dienst | Maximaal 1 keer per maand één onderhoudsvenster. Elke tweede woensdag van de maand. Duur: maximaal 6 uur per onderhoudsvenster (00:00 tot 06:00 uur). | Buiten het beschikbaarheidsvenster. |
Gepland onderhoud GBA-V (RvIG) | Maximaal 1 x per maand één onderhoudsvenster. Elke laatste zondag van de maand. Duur: maximaal 6 uur (09:00 tot 15:00 uur). NB: niet relevant voor publieke MU’s. |
N.v.t. |
Tabel: Performance-indicatoren voor onderhoudsvenster
In uitzonderingsgevallen, bij incidenten, kan onderhoud plaatsvinden buiten het afgesproken onderhoudsvenster. In uitzonderingsgevallen, bijvoorbeeld naar aanleiding van incidenten of calamiteiten of in het geval van uitzonderlijk lange doorlooptijden kan de implementatie buiten het gedefinieerde onderhoudsvenster plaatsvinden. Logius stelt in zo’n geval de Afnemers z.s.m. op de hoogte.
BSNk PP heeft het recht de bij het BSNk behorende (technische) eisen, beveiligingsmiddelen en beveiligingsmaatregelen te wijzigen. De afnemer wordt van een dergelijke wijziging minimaal 1 maand, en eerder indien mogelijk, voordat hieraan voldaan moet worden, schriftelijk of elektronisch geïnformeerd. Dit tenzij een kortere termijn noodzakelijk is in verband met (mogelijke) beveiligingsincidenten.
Releases
De handelingen die moeten worden verricht, om een nieuwe versie van de BSNk applicatie te installeren in de productieomgeving, passen niet in een regulier onderhoudsvenster. Daarom worden de productie- releasemomenten (2 tot 3 per jaar) op zondagen ingepland.
Zodra er een releasemoment is vastgesteld, zal dit zo spoedig mogelijk, maar uiterlijk 1 maand van tevoren, worden gecommuniceerd naar de afnemers.
BSNk werkt ernaar toe om per iteratie te gaan releasen. Hierdoor zullen in de toekomst de releases een stuk kleiner zijn en kan de doorlooptijd van de uitrol worden verminderd. Daardoor kan mogelijk de uitrol van een nieuwe release wel tijdens een normaal onderhoudsvenster gaan plaatsvinden.
Continuïteit van BSNk PP
Ondanks alle voorzorgsmaatregelen kan het voorkomen dat gegevens verloren gaan, bijvoorbeeld in het geval van calamiteiten. Logius heeft maatregelen genomen om schade door gegevensverlies zoveel mogelijk te beperken.
Standaard service | Maximale periode gegevensverlies |
---|---|
Maximum periode gegevensverlies | 24 uur |
Tabel: continuïteit Performance Indicatoren
BSNk PP heeft maatregelen genomen om het gegevensverlies te minimaliseren. De maatregelen bestaan uit:
- De beschikbaarheid van de BSNk PP-applicatie op minimaal twee verschillende geografisch gescheiden locaties.
- Het uitvoeren van frequente database back-ups.
Logius voert minimaal 1 uitwijktest per jaar uit. Bij de uitwijktest hanteert Logius de norm om uiterlijk binnen 4 uur weer operationeel te zijn op de uitwijklocatie.
Daarnaast wordt minimaal 1 keer per jaar de back-up- en restore procedure getest.
Informatiebeveiliging van BSNk PP
Het stelsel van informatiebeveiligingsmaatregelen rond BSNk PP richt zich op de beschikbaarheid, integriteit en exclusiviteit (vertrouwelijkheid). Logius waarborgt de informatiebeveiliging door het uitvoeren van een periodieke toets, het gaat hier om:
- Baseline Informatiebeveiliging Rijksdiensten (BIR) interne toets
- Jaarlijkse security penetratietest
De definitie van deze drie aspecten luidt:
- Beschikbaarheid. BSNk PP moet volgens afspraken met de Afnemers beschikbaar zijn. De normen en minimale realisatie voor de beschikbaarheid staan in paragraaf Beschikbaarheid van BSNk PP
- Integriteit. De informatie binnen de systemen van BSNk PP moet juist, volledig en tijdig zijn.
- Exclusiviteit. Alleen daarvoor bevoegde personen mogen de gegevens van BSNk PP inzien.
3. Beheerprocessen BSNk PP
In dit hoofdstuk wordt per beheerproces beschreven hoe de serviceniveaus voor BSNk PP worden gehaald.
Er wordt een beschrijving gegeven van de volgende beheerprocessen:
- Servicecentrum Logius
- Incidentbeheer
- Wijzigingenbeheer
- Releasebeheer
- Beschikbaarheidsbeheer
- Capaciteitsbeheer
- Continuïteitsbeheer
Servicecentrum Logius
Het servicecentrum is de ingang voor Afnemers binnen Logius en vervult daarmee de loketfunctie. Het Logius Servicecentrum is verantwoordelijk voor support op de meldingen over BSNk PP.
Het support betreft:
- ondersteunen van Afnemers bij het gebruik van BSNk PP
- het verstrekken van informatie
- aannemen en beantwoorden van vragen
- in behandeling nemen van storingen van, en klachten over, BSNk PP
- In behandeling nemen van wijzigingsvoorstellen
- Ondersteuning bij het aansluiten op BSNk PP
Afnemers kunnen vrijelijk gebruik maken van de publiek beschikbare informatie m.b.t. BSNk, bijvoorbeeld op www.logius.nl, ten behoeve van externe communicatie.
De communicatie over BSNk t.a.v. storingen en onderhoud wordt door het servicecentrum van Logius verzorgd. Logius kan aanwijzingen geven over de wijze van aanduiden en communicatie ten aanzien van de diensten van BSNk. De afnemers zijn verplicht te handelen conform deze aanwijzingen.
In het Dossier Afspraken en Procedures is in bijlage 4 een aantal communicatieberichten opgenomen die door afnemers kunnen worden gebruikt in de in bijlage 4 beschreven situaties.
Incidentbeheer
Het Incidentbeheer heeft als doel zo snel mogelijk de normale gang van zaken te hervatten en de impact op de bedrijfsprocessen te minimaliseren.
Onder ‘incidenten’ wordt elke gebeurtenis verstaan die niet tot de standaardoperatie van de dienst behoort en die een interruptie of een vermindering van de kwaliteit van de dienst kan veroorzaken.
Om op een juiste wijze met de incidenten om te gaan, worden deze geprioriteerd volgens onderstaande tabel. Impact en urgentie worden in de tabellen daaronder toegelicht.
Impact | ||||
---|---|---|---|---|
Hoog | Midden | Laag | ||
Hoog | 1 | 2 | 3 | |
Urgentie | Midden | 2 | 2 | 3 |
Laag | 3 | 3 | 3 |
Met urgentie wordt aangegeven of en hoe er uitstel van herstel mogelijk is.
Urgentie | |
---|---|
Hoog | Uitstel van de dienstverlening is niet mogelijk. De dienstverlening moet onmiddellijk worden hersteld. Dit betreft de (deel-)diensten Activatie en Transformatie of de gehele BSNk PP-voorziening. |
Midden | Uitstel is mogelijk, bijvoorbeeld tot het einde van de dag, waarna ’s nachts herstel mogelijk is. Dit betreft de (deel-)diensten Sleutelbeheer, Stelselbeheer en InzageRegister. |
Laag | Uitstel is mogelijk. Het moment van herstel wordt in overleg met Afnemer bepaald (kan enkele dagen, weken of maanden duren). |
Met impact wordt aangegeven wat de graad van de uitval van BSNk PP is. In onderstaande tabel wordt aangeven hoe het impactniveau wordt bepaald.
Impact | |
---|---|
Hoog | BSNk PP functioneert in het geheel niet. Uitval van het volledige informatiesysteem of de diensten Activatie of Transformatie. |
Midden | BSNk PP genereert ongewenste resultaten die niet schadelijk zijn voor de Afnemers |
Laag | BSNk PP vertoont (ver)storende tekortkomingen, maar niet zo dat het geclassificeerd is als hoog of midden. |
Bereikbaarheid
Bij Logius kan een incident worden aangemeld.
Wijzigingenbeheer
De doelen van Wijzigingenbeheer zijn:
- Het anticiperen op de veranderende business van Afnemers.
- Het reageren op Requests for Changes (RfC’s, wijzigingsverzoeken) van Afnemers of IT.
Wijzigingenbeheer garandeert een planmatige en gecontroleerde verwerking van RfC’s om een probleem op te lossen of een nieuwe functionaliteit toe te voegen. Wijzigingenbeheer evalueert verzoeken of laat deze evalueren, voert een impactanalyse uit, bereidt besluitvorming en communicatie voor.
Bereikbaarheid
Via Logius kan een wijzigingsverzoek worden ingediend (zie ook de paragraaf over het Servicevenster). Na een eerste beoordeling krijgt de indiener van dit verzoek informatie over de afhandeling en de eventuele impact daarvan. Voor een vlotte afhandeling van een wijzigingsverzoek is de onderstaande informatie nodig.
Wijzigingsverzoek – benodigde informatie | |
---|---|
Indiener | Naam en contactgegevens van de indiener van het wijzigingsverzoek. |
Onderwerp | Een korte titel van het wijzigingsvoorstel. |
Datum | De datum waarop het wijzigingsverzoek is ingediend. |
Achtergrond | Beschrijf de achtergronden van het voorstel: Het probleem, het idee of de ambitie achter de gevraagde wijziging. Beschrijf ook de relatie met het beoogde doel achter de voorziening. Welke bijdrage levert deze wijziging aan de bedrijfsdoelstelling/doelstelling van de voorziening? Wat gebeurt er als de wijziging niet wordt doorgevoerd? Welke baten levert deze wijziging op voor het eerder vastgestelde resultaat van de voorziening? |
Voorgestelde wijziging | Doe een voorstel voor de voorgestelde wijziging in termen van op te leveren resultaat (wat is er klaar als het klaar is?). |
Gewenste invoerdatum | De datum waarop de wijziging in de projectscope/beslisdocumenten en/of resultaten moet zijn doorgevoerd en waarom. |
Releasebeheer BSNk PP
De doelen van Releasebeheer zijn:
- opstellen van releaseplannen/kalender
- succesvol uitrollen van release packages
- zorgen voor een minimale verstoring van BSNk PP
- Afnemer informeren over de planning van releases
Geaccepteerde wijzigingen worden ingepland op de BSNK PP- releasekalender en worden gecommuniceerd aan de Afnemers. Vervolgens worden deze wijzigingen doorgevoerd tijdens het eerder gedefinieerde onderhoudsvenster (zie de paragraaf Onderhoudsvenster).
Ketentesten
Bij het uitvoeren van ketentesten, die Afnemers moeten uitvoeren in het kader van onderhoud en/of in-productie-name van nieuwe releases van BSNk PP, zal Logius aan alle Afnemers communiceren dat zij 2 weken de tijd hebben om hun koppelingen te testen op de Logius ketentestomgeving. Het beheerteam BSNk PP is beschikbaar voor vragen, maar de Afnemers zijn zelf verantwoordelijk of en hoe ze dit doen.
Andersom wordt ook van ketenpartijen verwacht dat zij onderhoud op systemen of infrastructuur die relevant zijn voor het BSNk PP 10 werkdagen van tevoren aankondigen richting Logius.
De afnemer informeert Logius schriftelijk of elektronisch over wijzigingen in de organisatie of techniek van de afnemer, die verband houden met BSNk PP, indien de ingeschatte impact van de wijziging groter is dan ‘laag’.
Beschikbaarheidsbeheer
Beschikbaarheidsbeheer is gericht op het borgen en optimaliseren van de dienstverlening. Beschikbaarheidsbeheer is verantwoordelijk voor het monitoren en rapporteren van de beschikbaarheidsprestaties van de totale dienstverlening en de individuele componenten. Indien de beschikbaarheid structureel onvoldoende is of dit dreigt te worden, zorgt dit proces ervoor dat er verbeteringen worden voorgesteld.
Activiteiten binnen beschikbaarheidsbeheer:
- Monitoren beschikbaarheid
- Rapporteren
- Analyseren beschikbaarheid
- Verbeteren beschikbaarheid
Capaciteitsbeheer
Een Afnemer is verplicht om viermaal per jaar een prognose aan te leveren via het Operationeel Overleg.
Deze prognoses betreffen (waar van toepassing op de betreffende Afnemer):
- Het aantal verwachte activaties
- Het aantal verwachte transformaties
- Het aantal aanroepen van het InzageRegister
- Het aantal verwachte sleutelbeheerverzoeken
Logius heeft maatregelen genomen om de continuïteit te waarborgen. Wanneer uit het capaciteitsmanagement proces blijkt dat een grotere capaciteit nodig is, zal Logius maatregelen nemen om de capaciteit te vergroten.
Continuïteitbeheer BSNk PP
De doelen van continuïteitsbeheer zijn:
- zorgen dat de gewenste continuïteits- en herstelmechanismen klaar zijn voor gebruik
- het (laten) onderhouden van continuïteitsplannen en herstelplannen
- het (laten) houden van reguliere business impactanalyse
Een calamiteit is een ongeplande gebeurtenis die de algehele diensten van de voorziening in gevaar brengt (bv. bommelding, brand, overstroming), waarbij verwacht wordt dat de duur van het niet beschikbaar zijn van één of meerdere IT-diensten afgesproken drempelwaarden zal overschrijden. Voor technische verstoringen bestaat een uitwijkmogelijkheid. Als er van deze uitwijkmogelijkheid gebruik moeten worden gemaakt, garandeert Logius de overeengekomen serviceniveaus niet
Definities
Voor de betekenis van en toelichting op de gebruikte begrippen in dit document verwijzen we u naar de begrippenlijst van Logius.
Document versiegeschiedenis
Versie | Datum | Aanpassingen |
---|---|---|
1.0 | 23-04-2018 | Akkoord CAB BSNk |
1.1 | 28-12-2018 | Regulier onderhoudsvenster aangepast, kleine tekstuele aanpassingen |
1.2 | 10-04-2019 | Verduidelijkingen aangebracht in paragrafen 1.7, 2.1.2, 2.1.5, 3.1 en 3.4.1 |
1.3 | 11-06-2019 | Zondagonderhoud (releases) toegevoegd in 2.1.6 |