Cocreatie:Denk mee met het GEMMA Gegevenslandschap

Over dit discussiebord

Door op "Onderwerp toevoegen" te klikken gaat u akkoord met de gebruiksvoorwaarden van deze wiki.
NicoKoomen (Overlegbijdragen)

Een Service-oriented architecture is minder geschikt voor batchgewijze verwerking of opvraag. Bv het vervaardigen van een mailing. Of een overzicht van alle percelen in een bepaald gebied. Wordt het maken van rapportages en batchgewijze opvraag van gegevens een service bij de bronhouder?

Is het een idee om eerst API’s te ontwikkelen op bv de databases van het datadistrubutie systeem die volgens het lagen model de data ontsluit. (ge-audit en gepseudonimiseerd) Hier kan dan ervaring mee opgedaan worden en software worden ontwikkeld die zijn gegevens kan betrekken van deze standaard API’s

Consultatie gegevenslandschap (Overlegbijdragen)

De gegevenslandschap architectuur richt zich met name op transactionele dienstverlening. Voor wat betreft processen die data intensieve bewerkingen doen moet onderzocht worden in hoeverre de geschetste architectuur werkbaar is, en onder welke voorwaarden dit het geval is. Een aanpak waarbij moderne APIs worden gepositioneerd op de huidige informatiesystemen zodat ervaring opgedaan kan worden met data intensieve bewerkingen in een SOA architectuur is hierbij een optie om ervaring op te doen.

In de volgende versie van het gegevenslandschap document zal aandacht worden besteed aan de problematiek van data intensieve bewerkingen in een service georiënteerde architectuur.

Waarom staat bedrijfsregels op 2 plekken weergegeven? (vraag uit consultatiesessie 3)

3
Consultatie gegevenslandschap (Overlegbijdragen)

Zowel bij de dienstenaanbieder als bij de dienstenafnemer is een blokje 'bedrijfsregels' opgenomen. Wat is het onderscheid tussen deze twee blokjes?

Consultatie gegevenslandschap (Overlegbijdragen)

Gerelateerd aan deze vraag:

Transparantie over bedrijfsregels en algoritmen wordt steeds belangrijker. Is het niet zo dat de bedrijfsregels die worden uitgevoerd vermeld moeten worden in de API-documentatie?

Consultatie gegevenslandschap (Overlegbijdragen)

Naar aanleiding van de vragen uit de consultatie is besloten om bedrijfsregels als specifieke functionaliteit te verwijderen uit de dienstenlaag. Reden daarvoor is dat de implementatie van bedrijfsregels feitelijk wordt uitgevoerd binnen APIs gebruik makend van onderliggende transformatie en integratiefunctionaliteit.

Waarom is aanvragen en meldingen in de proceslaag gepositioneerd? (vraag uit consultatiesessie 2)

2
Consultatie gegevenslandschap (Overlegbijdragen)

Waarom is de functie aanvragen en meldingen opgenomen in de procesinrichtinglaag?

Consultatie gegevenslandschap (Overlegbijdragen)

Deze positionering klopt niet. In de volgende versie van het gegevenslandschap document wordt deze ondergebracht in de interactielaag.

Leveranciers betrokken bij deze overgang?

2
Rvanrijswijk (Overlegbijdragen)

Ik heb zojuist de stukken m.b.t. het Gemeentelijk gegevenslandschap gelezen. Mijn vraag is in hoeverre de leveranciers mee worden genomen aangezien de wijzigingen een behoorlijke impacht hebben op het huidige gemeentelijke applicatielandschap. Een voorbeeld hierbij is dat basisinformatie niet meer wordt gedistribueerd maar dat via notificatieberichten afnemers worden bericht dat er data is gewijzigd waarop zij zijn geabbonneerd. De afnemende applicaties moeten dan beslissen of zij die data zelf willen ophalen. dat is een grote verandering t.o.v. de huidige distributiesystemen die nu in het land draaien.

Consultatie gegevenslandschap (Overlegbijdragen)

Het is van cruciaal belang dat de leveranciers goed op de hoogte zijn van de strategie van VNG Realisatie aangezien leveranciers een cruciale rol vervullen bij de realisatie van producten die de gegevenslandschap architectuur implementeren. Leveranciers worden daarom betrokken via het Common Ground Groeipact, leveranciersbijeenkomsten, werkgroepen, strategische tafels, bilaterale gesprekken en de reguliere VNG communicatiekanalen.

Jkoeckhoven (Overlegbijdragen)

Op blz 10 punt 12 staat: “Iedere gegevensuitwisseling wordt gelogd”. Bij deze uitspraak, en in heel hoofdstuk 2.3, lijkt het uitgangspunt te zijn dat alle gegevens in een gemeente vertrouwelijk zijn. Dat is natuurlijk niet zo. Als bijvoorbeeld een applicatie aan de BAG-bronregistratie vraagt wat de postcode is van een bepaald adres, dan hoef je dit niet te loggen. Ik denk dat voor heel 2.3 geldt dat dit alleen van toepassing is bij vertrouwelijke gegevens.

Ik denk dat het belangrijk is grenzen te stellen aan het loggen, niet alleen om ontwikkeling van applicaties eenvoudiger te houden, maar ook om de omvang van logbestanden in de perken te houden. Overigens moet er ook helderheid komen over een (beperkte) bewaartermijn van logbestanden.

Een ander onopgelost vraagstuk: moet je het opvragen van gegevens uit logbestanden ook loggen? Je zou denken van wel, want wie wat heeft opgevraagd is een privacygevoelig gegeven. Maar dan moet je ook de bevragingen van deze bevragingen weer loggen, enz. tot in het oneindige, dus hoe ver gaan we hierin?

Consultatie gegevenslandschap (Overlegbijdragen)

Uitgangspunt is dat niet alleen verwerkingen van persoonsgegevens worden gelogd maar alle verwerkingen. We gaan dus verder dan de eisen die vanuit de privacywetgeving wordt gesteld. Doel is maximale transparantie bereiken. Ten aanzien van het loggen van de bevragingen van de logging moeten we nadenken of dat toegevoegde waarde heeft aangezien dit inderdaad tot oneindige logging kan leiden. Ten aanzien van de bewaartermijnen van logging zullen we afstemmen met onder andere de Informatiebeveiligingsdienst (IBD).

Jkoeckhoven (Overlegbijdragen)

zie blz 11 voetnoot onderaan: “De bronregistratie is de plaats waar het gegeven of document voor het eerst wordt vastgelegd (bron: NORA). Deze zijn verplicht om te gebruiken door partijen bij de uitvoering van taken. Voorbeelden zijn de basisregistraties en gemeentelijke kernregistraties.”

Deze definitie is mij niet helder genoeg.

Als componenten strikt toestandsloos zijn, dan bevatten ze alleen instructies (programmacode) en verder helemaal geen gegevens. Hoe ver willen we hierin gaan? Willen we de gebruikersinstellingen per medewerker buiten de applicatie opslaan, in een aparte bronregistratie? Volgens de definitie wel, maar ik denk niet dat we zo ver willen gaan. Of denk aan autorisaties: wie mag wat in welke applicatie? Willen we dat buiten de applicaties in een bronregistratie vastleggen? Uiteraard doe je dat roll-based. Willen we dan dat de applicatie bij elke handeling aan een bronregistratie vraagt: welke rol heeft de bij mij ingelogde medewerker? en vervolgens aan een andere bronregistratie vraagt: mag iemand met rol x de handeling y uitvoeren?

Misschien is het praktischer om onder bronregistratie niet “bijvoorbeeld basis- en kernregistraties” verstaan maar strikter: alleen basis- en kernregistraties. Dus alle gegevens die in meer dan één applicatie worden gebruikt, komen in een bronregistratie. Dit lijkt in elk geval een stuk haalbaarder. Bedenk dat voor alle bronregistraties informatiemodellen en standaarden moeten worden afgesproken (zie blz 14: "we standaardiseren maximaal".)

In elk geval lijkt het me goed hierover een uitspraak te hebben.

Consultatie gegevenslandschap (Overlegbijdragen)

Binnen de kaders van het gegevenslandschap is een bronregister een register waar informatieobjecten in opgeslagen worden door een bronhouder die juridische aansprakelijk is voor de juistheid (kwaliteit/actualiteit) van het object. Binnen het gegevenslandschap hanteren we geen referentiecomponenten voor de gegevensbronnen maar gebruiken we de term "register". Bij registers is het uitgangspunt dat de informatieobjecten die in de registratie worden opgenomen meervoudig gebruikt worden. Dat is een verschil met de GEMMA. Als daar bijvoorbeeld wordt gekeken naar het zakenregistratiecomponent dan heeft dat component een aantal gegevens in zich, zoals besluiten en documenten die potentieel meervoudig gebruikt worden. In het gegevenslandschap valt de zakenregistratiecomponent dus uiteen in een aantal registers (o.a. Besluitenregister, documentenregister en een zakenregister).

Wat is de scope van één register? (vraag uit consultatiesessie 3)

2
Consultatie gegevenslandschap (Overlegbijdragen)

Wat is de scope van één register? Is dat bijvoorbeeld een Besluit of een Zaak of worden registers op een hogere granulariteit ingericht zoals bv. Openbare ruimte, Inkomen of Sociaal Domein?

Consultatie gegevenslandschap (Overlegbijdragen)

De NORA stelt "De bronregistratie is de plaats waar het gegeven of document voor het eerst wordt vastgelegd. De eigenaar van de bronregistratie is verantwoordelijk voor de kwaliteit van de informatie-objecten in de registratie. Bronregistraties kunnen een groot aantal vormen aannemen: denk niet alleen aan databases en registraties zoals de basis- en kernregistraties, maar ook aan websites, publicaties, rapporten, wiki's.". Deze definitie is te breed voor het gegevenslandschap wat zich primair richt op transactionele dienstverlening. Binnen de kaders van het gegevenslandschap is een bronregister een register waar informatieobjecten in opgeslagen worden door een bronhouder die juridische aansprakelijk is voor de juistheid (kwaliteit/actualiteit) van het object. Binnen het gegevenslandschap hanteren we geen referentiecomponenten voor de gegevensbronnen maar gebruiken we de term "register". Bij registers is het uitgangspunt dat de informatieobjecten die in de registratie worden opgenomen meervoudig gebruikt worden. Dat is een verschil met de GEMMA. Als daar bijvoorbeeld wordt gekeken naar het zakenregistratiecomponent dan heeft dat component een aantal gegevens in zich, zoals besluiten en documenten die potentieel meervoudig gebruikt worden. In het gegevenslandschap valt de zakenregistratiecomponent dus uiteen in een aantal registers (o.a. Besluitenregister, documentenregister en een zakenregister).

Duurzame toegankelijkheid (vraag uit consultatiesessie 1)

2
Consultatie Gegevenslandschap (Overlegbijdragen)

Wat is de implicatie van het Gegevenslandschap voor duurzame toegankelijkheid? Wat zijn de gevolgen van het continu gegevens raadpleegbaar en beschikbaar houden?

Consultatie gegevenslandschap (Overlegbijdragen)

De eisen die gesteld worden aan de duurzame toegankelijkheid van gegevens betekenen onder andere dat bronregisters verantwoordelijk worden voor het bijhouden van historie. Daarnaast worden bronregisters verantwoordelijk voor metadatering van de gegevens ten aanzien van doel waartoe gegevens zijn ingezameld. Dit in verband met het aan de hand van de selectielijsten bepalen van de bewaartermijnen van de gegevens. Er wordt momenteel door VNG Realisatie gewerkt aan een nieuw Gegevenslandschap katern ten aanzien van duurzame toegankelijkheid. Dit katern zal het GEMMA katern op dit onderwerp vervangen. In het katern wordt duurzame toegankelijkheid breder beschreven dan enkel het bijhouden van historie en metadatering maar worden bijvoorbeeld ook processen en de relatie van gegevens met het doel van de inzameling en bijbehorende bewaartermijnen beschreven. Het katern zal naar verwachting later dit jaar worden opgeleverd.

Meervoudige doelbinding (vraag uit consultatiesessie 1)

2
Consultatie Gegevenslandschap (Overlegbijdragen)

Bij toepassing van RBAC (Rolgebaseerde toegangscontrole) is het mogelijkheid dat je vanuit verschillende rollen autorisaties hebt voor een functie. Hoe weet je bij het opstarten van een functie vanuit welk doel je werkt?

Consultatie gegevenslandschap (Overlegbijdragen)

Inrichting van autorisatie via role-based access (RBAC) is gezien de eisen die vanuit de AVG worden gesteld ten aanzien van doelbinding niet de beste optie. Nadeel van de RBAC-methode is dat bij meestal rollen ontworpen worden vanuit functies en autorisaties. Autorisaties worden daardoor meestal gekoppeld aan de functies van personen. Beveiligingseisen zijn echter niet alleen afhankelijk van functies van medewerkers. Sommige taken mogen bijvoorbeeld niet op bepaalde systemen worden uitgevoerd, omdat ze op minder veilige plaatsen staan. Denk daarbij aan balie PC's en thuiswerkplekken, maar ook aan meer en minder beveiligde zones en panden. Daarnaast is het zo dat door het gebruik van rollen medewerkers vaak te ruim worden geautoriseerd. Rollen worden immers meestal gedefinieerd op basis van de rechten die een groep van medewerkers nodig heeft. Alle medewerkers krijgt daardoor alle rechten die een ander medewerker nodig heeft. Het is bijna onvermijdelijk dat medewerkers meer rechten krijgen dan waar ze op basis van hun taak recht op hebben.

Om te kunnen voldoen aan de AVG zal geborgd moeten worden dat functies die door een gebruiker worden opgestart moeten naar een unieke doelbinding herleidbaar zijn. Overgang van een RBAC inrichting naar attribuut gebaseerde (ABAC) inrichting lijkt een goede oplossing te zijn. Bij deze methode van autoriseren worden toegangsrechten geassocieerd met een set van regels, die zijn uitgedrukt in meetbare parameters of attributen; die vervolgens worden toegekend aan subjecten die kunnen bewijzen dat zij voldoen aan de regels. ABAC geeft dus toegang tot IT-diensten op basis van een bewering over de eigenschappen (attributen) van de dienstaanvrager (subject). De attributen kunnen allerlei formaten of gedaantes hebben: groepen, rollen, clearance levels, context etc. ABAC past in een omgeving, waar de eigenaar van het object de identiteit van het subject niet exact kent, zoals het internet of een gefedereerde omgeving. Bepaalde kenmerken worden gebruikt om te bepalen of iemand toegang krijgt zonder de identiteit eerst vast te stellen. Die kenmerken kunnen geborgd zijn in certificaten of tokens uitgegeven door een derde partij.

Er wordt op dit moment gewerkt aan een gegevenslandschap architectuur document op het gebied van autorisatie en authenticatie. In dit document wordt deze problematiek nader toegelicht en uitgewerkt.

Wat is de bron? (vraag uit consultatiesessie 1)

2
Consultatie Gegevenslandschap (Overlegbijdragen)

Bij enkele basisregistraties zijn gemeenten bronhouder, maar worden gegevens verstrekt vanuit een landelijke voorziening. Bij migratie naar een gegevenslandschap: wat is dan de bron: de registratie bij gemeenten, of de landelijke voorziening?

Consultatie gegevenslandschap (Overlegbijdragen)

Voor een aantal (basis)registraties zijn landelijke voorzieningen en knooppunten ingericht die worden gebruikt voor de verstrekking van de gegevens uit de (basis)registraties. Voorbeelden hiervan zijn de GBA-V en PDOK. Deze knooppunten en landelijke voorzieningen lopen qua actualiteit van gegevens veelal achter op de bronregisters en zijn geen bronregister zoals bedoeld in het gegevenslandschap. Ze worden door veel afnemers wel als zodanig gebruikt. Reden voor het gebruik van deze voorzieningen liggen meestal in het feit dat de bronregisters niet direct bevraagbaar zijn. De gemeentelijke basisregistratie personen die door elke individuele gemeente wordt gevoerd voor de eigen inwoners is bijvoorbeeld niet extern bevraagbaar. Indien de bronregisters niet direct bevraagbaar zijn is bevraging van een landelijke voorziening een acceptabele (tijdelijke) oplossing.