Aan deze wiki wordt momenteel gewerkt. Het kan zijn dat tijdens deze werkzaamheden links niet werken of dat sommige views niet of onvolledig getoond worden.

Thema Architectuur Mobiel


Mobiele architectuur gemeenten

Beschouwingsgebied

Door KING wordt ‘mobiel’ gezien als een kanaal via welke (gemeentelijke) informatie (ook) ter beschikking gesteld kan worden aan inwoners, ondernemers, medewerkers en keten en netwerkpartijen. De gehele keten van gebruikers, mobiele apparaten, besturingssysteem, mobiele applicaties, netwerk, het mobiele kanaal en de gemeentelijke informatiediensten wordt beschouwd. Deze architectuur zal hier zoveel mogelijk op aansluiten en de ontbrekende aspecten en verbindingen nader beschrijven.

Ter verduidelijking van het beschouwingsbied worden er verder in de bijlage enkele voorbeelden gegeven van actuele mobiele initiatieven in het gemeentelijk domein en voorbeelden uit het publieke domein.

Visie


De markt heeft maximale vrijheid voor het ontwikkelen van innovatieve, nuttige en flexibele mobiele applicaties in een dynamische omgeving die (mede) gebruik maken van gemeentelijke informatie. Gemeenten ondersteunen dit door het beschikbaar stellen van robuuste, landelijk gestaardiseerde informatie- en beheerdiensten op hun gemeente-specifieke inrichting van het IT landschap.


Een uitgangspunt in deze visie is dat gemeenten de ontwikkeling van mobiele applicaties zoveel mogelijk aan de markt overlaten. Hiervoor moeten de gemeenten landelijk gestandaardiseerde informatiediensten ter beschikking stellen ontkoppeld van de gemeente specifieke inrichting van het IT-landschap. Dit gaat verder dan het beschikbaar stellen van informatie en het kunnen muteren van deze informatie. Het gaat ook om beheerdiensten die voor de beveiliging zorgen en die de eigenaar van de gegevens (waaronder de burger) de mogelijkheid geven zelf te bepalen wie toegang krijgt tot diens informatie.

Relatie NORA en GEMMA

Dit katern geeft een speciale view op de GEMMA – en daarmee ook de NORA - vanuit het oogpunt van het mobiele kanaal. Hierbij raakt het katern impliciet of expliciet diverse aspecten die in de GEMMA beschreven staan. In hoofdstuk 4 staan de van toepassing zijnde principes beschreven. Verder bouwt dit katern voort op de informatiearchitectuur van de GEMMA. Er worden in dit katern niet expliciet bedrijfsfuncties, applicatiefuncties en applicatiecomponenten beschreven aangezien deze niet anders zijn dan in de algemene GEMMA-architectuur. Het enige verschil is dat deze via het mobiele kanaal ontsloten worden.

De NORA stelt dat internet het voorkeurskanaal is voor het leveren van diensten (NORA AP09), echter de NORA stelt ook dat de dienst ook minimaal via één ander kanaal geleverd moet kunnen worden (NORA AP10). Bij het leveren van formele gemeentelijke diensten dient hier expliciet rekening mee gehouden te worden. Voor het leveren van informele, toegevoegde diensten en innovaties is dit minder belangrijk.

Onderdelen mobiele keten

De essentie van het vraagstuk waar deze architectuur zich op richt is het toegankelijk maken van de gemeentelijke informatie en dienstverlening via het mobiele kanaal. De scope is nadrukkelijk breder dan alleen een verlengstuk van de huidige gemeentelijke dienstverlening over het mobiele kanaal. Enerzijds biedt dit kanaal mogelijkheden voor het ontwikkelen van innovatieve concepten die toegevoegde waarde bieden aan de afnemers, anderzijds kan de kracht en creativiteit van de markt gebruikt worden door het beschikbaar stellen van (generieke) informatieservices.

De mobiele architectuur kent de onderstaande deelgebieden:

Schakels in de architectuur van mobiele toepassingen.png

Figuur 1: Schakels in de architectuur van mobiele toepassingen

Elk deelgebied zal in dit hoofdstuk nader beschreven worden:

  1. Gebruikers en doelgroepen;
  2. Mobiele applicaties;
  3. Mobiele apparaten;
  4. Het mobiele kanaal en kanaalstrategie;
  5. Generieke informatiediensten;
  6. De bronsystemen;
  7. Informatiebeveiliging

Context

Context van de mobiele architectuur.png

Figuur 2: Context van de mobiele architectuur

Gebruikers en Doelgroepen

De gebruikers van het mobiele kanaal kunnen worden samengevat in inwoners, ondernemers, (gemeente)medewerkers, ketenpartners en bestuurders. Hoewel er voor de technische implementatie niet veel verschillen zijn tussen doelgroepen zijn er op het vlak van bijvoorbeeld informatiebeveiliging en kosten/baten wel de nodige aandachtspunten. Zo liggen er kansen om inwoners meer te betrekken bij de processen die de gemeenten voor haar uitvoert en helpt de digitalisering om een deel van de administratieve werkzaamheden richting de inwoner te verplaatsen. Aan de kant van de gemeentelijk medewerkers liggen er kansen op het vlak van tijd en plaatsonafhankelijk werken, maar er liggen zeker ook kansen voor (bijvoorbeeld) buitendiensten om laagdrempelig, ter plaatse administratieve werkzaamheden te kunnen verrichten. Denk bij dit laatste bijvoorbeeld aan het melden van constateringen of toetsen van registraties aan de hand van deze constateringen.

Mobiele applicaties


Onder mobiele applicaties – of apps - wordt in deze context verstaan software die specifiek gemaakt is voor het gebruik op mobiele apparaten (als tablets, smartphones, wearables, etc.) en responsive webapps.


Een mobiele applicatie is dus een ‘gewone’ applicatie met een aantal bijzondere kenmerken en uitgangspunten. Ook zijn niet alle mobiele applicaties te relateren een het gemeentelijke bedrijfsfunctie domein.

Kenmerken

  • Mobiele applicaties zijn laagdrempelig en veel gebruikt;
  • Autorisatie en authenticatie via mobiele apparaten is in opkomst (denk aan betalingen);
  • Mobiele apparaten hebben vaak rijke functionaliteit als een camera, GPS, etc.
  • Mobiele apparaten hebben een andere gebruikersinterface als desktopsystemen (in omvang, toetsenbord, swiping, etc.);
  • Uitgangspunt is dat de beveiliging van mobiele apparaten vaak slecht is (principe MA5);
  • Uitgangspunt is dat de gebruikte internetverbinding vaak slecht is (principe MA5);
  • Er is een grote diversiteit aan platforms en soorten apparaten;
  • Informatie is vluchtig en wordt normaliter niet opgeslagen.


Soorten mobiele applicaties
In de referentiearchitectuur voor mobiele applicaties voor EZ [06] worden de onderstaande soorten mobiele applicaties onderscheiden en is er een beslisboom opgesteld die helpt op de hierin de juiste keuze te maken. Een hierop gebaseerde beslisboom wordt in paragraaf 2.6 besproken.

  1. Desktop virtualisatie op mobiele clients. De werkplekomgeving met desktopapplicaties wordt gepresenteerd op de mobiele client; bijvoorbeeld door middel van een VPN-verbinding met een Citrix client. Enerzijds is dit een bijzonder eenvoudige oplossing, anderzijds is de gebruikersgroep (voornamelijk de gemeentelijk buitendienst medewerkers) en de beschikbare mobiele apparaten (de grotere tablets) beperkt.
  2. Native apps. Native apps zijn mobiele applicaties die voor een specifiek besturingssysteem en vaak ook voor een specifiek soort mobiel apparaat ontwikkeld zijn (Android, IOS, Windows 10, smartwatch of tablet, etc.). Het voordeel is dat ze geoptimaliseerd voor een specifieke omgeving gemaakt kunnen worden en dat ze gebruik kunnen maken van specifieke hardware (camera, GPS, etc.) van het mobiele apparaat. Het nadeel is dat er een keuze gemaakt moet worden voor een specifiek platform, of dat er verschillende versies voor de verschillende platforms ontwikkeld gaat worden.
  3. Mobiele Webapps. In tegenstelling tot native apps werken deze applicaties in de context van een browser. Data en business logica staat grotendeels op de server. De applicatie is minder afhankelijk van het specifieke besturingssysteem of de afmetingen van het scherm. In principe werkt een webapp op elk mobiel apparaat (met een gangbare browser en bibliotheken) waardoor er niet voor elk type mobiel apparaat een aparte versie gemaakt hoeft te worden. De keerzijde is dat er niet of nauwelijks support is voor specifieke functies van het mobiele apparaten zoals de camera en de GPS.
  4. Hybride apps. Dit zijn native apps waarvan een groter of kleine gedeelte in de vorm van een webapp bestaat.


App ontwikkeling
Dit katern gaat niet expliciet in op de ontwikkeling van applicaties – dit valt ook buiten de scope van de GEMMA. Wel zijn hiervoor reeds leidraden opgesteld:

  • Enterprise Mobility Rijks - Handreiking app ontwikkeling en beheer (15)
  • Het CIP geeft een aantal expliciete beveiligingseisen voor mobiele applicaties, zie (16)

Mobiele apparaten

Er zijn allerlei soorten mobiele apparaten – de apparaten. Enerzijds hebben deze apparaten beperkingen qua gebruikersinterface, opslag etc. Anderzijds hebben ze vaak specifieke functies (zoals camera’s en GPS) die ze bijzonder geschikt maken voor bepaalde taken. De volgende soorten worden onderscheiden:

  1. Smartphones; op dit moment is dit verreweg de meest gebruikte groep mobiele apparaten. Ook is er een grote mate van standaardisatie bij deze groep. Kenmerken zijn de relatieve geringe afmeting - wat visuele en invoerbeperkingen met zich meeneemt – en de rijke uitrusting aan functionaliteiten (GPS, camera, near field communication (NFC), Wifi/Bluetooth, etc.). Ook worden mobiele apparaten erg veel gebruikt (medio 2016 had 86% van de Nederlanders en smartphone). Uitgangspunt is dat de beveiliging van deze apparaten slecht is geregeld (door de gebruiker).
  2. Tablets; qua functionaliteit zijn tablets vergelijkbaar ‘grote smartphones’ – meestal zonder telefoonvoorzieningen. Ze onderscheiden zich echter door grote schermen, betere specificaties (opslag, processor) en betere invoermogelijkheden. Tablets nemen vaker de plek van laptops in – en (grotere) smartphones nemen vaker de plek in van tablets.
  3. Wearables; apparaten die op het lichaam gedragen kunnen worden. Kenmerken is dat dit een relatief nieuwe groep is en dat er nog een grote diversiteit is. Sommige apparaten hebben geen of zeer kleine schermen (smartwatches) en andere weer zeer uitgebreide visuele mogelijkheden (google glass). Deze diversiteit inachtnemend vallen ze binnen deze architectuur.
  4. Internet of things; het IoT is een infrastructuur die fysieke apparaten aan elkaar verbindt. Gaat om bijvoorbeeld auto’s, sensoren, pompen, etc. Aangezien deze apparaten niet worden gebruikt om de doelgroepen van deze architectuur te benaderen valt deze categorie buiten beschouwing.
  5. Embedded mobiele devices; kort door de bocht zijn dit dezelfde apparaten als in het IoT maar dan niet (expliciet) verbonden via een netwerk. Deze categorie valt om dezelfde reden buiten beschouwing.
  6. Desktops en laptops; deze apparaten vallen formeel niet onder onze noemer mobiele apparaten maar er is wel een duidelijke trend dat het onderscheid tussen mobiel en niet mobiel vervaagt. Bij laptops is dat al evident maar ook op desktops worden steeds vaker mobiele applicaties gebruikt (denk aan windows apps of webapplicaties). De verwachting is dan ook dat het onderscheid tussen mobiel en niet mobiel vervaagt.

Kanaalstrategie

De inzet van het mobiele kanaal moet aansluiten bij de gekozen kanaalstrategie (principe MA3). Dit verschilt per gemeente. Een cross- of OMNI-channel benadering is innovatief en klantvriendelijk maar is ook complex.

  • Multi-channel benadering. De afnemer kan het kanaal van zijn/haar voorkeur kiezen. De kanalen zijn echter afzonderlijk ingericht, niet aan elkaar verbonden en tussentijds van kanaal wisselen is niet mogelijk;
  • Cross-channel benadering. De afnemer kan het kanaal van zijn/haar voorkeur kiezen en tussentijds aanpassen;
  • OMNI channel benadering. De afnemer kan op elk moment het kanaal van zijn/haar voorkeur gebruiken zonder dat er een expliciet kanaalovergang merkbaar is.

De keuze voor een specifieke kanaalstrategie of de implementatie hiervan valt buiten de scope van deze architectuur en zal per gemeente verschillen. Een expliciete keuze voor een kanaalstrategie is echter wel randvoorwaardelijk voor een goede implementatie van het mobiele kanaal.

Generieke informatiediensten

Een kenmerk van mobiele applicaties is dat ze veelal zwaar steunen op online informatiediensten. Het uitgangspunt is dat een mobiele applicatie zelf geen data lokaal (of in de cloud) opslaat. Indien er toch informatie wordt opgeslagen wordt deze op basis van de dataclassificatie beveiligd (principe MA5.1). Informatiediensten en bijhorende beheerdiensten dienen dus ‘dunne’ front-end applicaties te ondersteunen door onder andere te zorgen voor (eigen) opslagmogelijkheden, transactiemanagement, herstel na het, al dan niet tijdelijk, wegvallen van de mobiele applicatie en beveiliging.

Bronsystemen

De generieke informatiediensten ontkoppelen de mobiele applicaties van de achterliggende bronsystemen van de gemeenten (en andere partijen). Dit geeft elke gemeente de vrijheid om, gegeven de specifieke kenmerken van de gemeente zoals omvang en budget, de best passende oplossing te kiezen. De GEMMA biedt hierbij ondersteuning door middel van o.a. de bedrijfsarchitectuur, de applicatiearchitectuur en de software catalogus.

Informatiebeveiliging

De informatiebeveiliging in de mobiele architectuur is feitelijk een keten van informatiebeveiligingsaspecten op verschillende niveaus :

  1. De beveiliging van de mobiele apparaten zelf;
  2. De beveiliging van het mobiele platform (native, web, hybride, virtualisatie)
  3. De beveiliging van de applicaties en opgeslagen informatie. Hoewel principe MA5 stelt dat er geen (gevoelige) data lokaal opgeslagen mag worden zal er in de praktijk een afweging met de beschikbaarheid van de applicatie gemaakt moeten worden. Den bijvoorbeeld aan een applicatie met inspectiegegevens voor een inspectie op locatie;
  4. De beveiliging van de generieke informatiediensten (buiten scope van deze architectuur);
  5. De beveiliging van de achterliggende bronsystemen (buiten scope van deze architectuur);
  6. De beveiliging van de onderliggende infrastructuur (buiten scope van deze architectuur).

Merk op dat hoewel de beveiliging van informatiediensten, achterliggende bronsystemen en de onderliggende infrastructuur buiten de scope van dit katern vallen, hier vanuit het mobiele kanaal wel aanvullende beveiligignseisen aan gesteld kunnen worden. Deze vormen dan samen met de beveiligingseisen uit de andere kanalen een integraal pakket van beveiligingseisen.

Daarnaast moet er een onderscheid gemaakt worden tussen de verschillende vormen van bedreigingen (16):

  1. Remote. Dit zijn bedreigingen afkomstig vanaf het netwerk op de entry points van de applicatie (webview, JSON-client, vanuit een gecompromitteerde server, etc.);
  2. Lokaal. Bedreigingen vanaf het eigen apparaat doordat er elektronisch toegang tot het apparaat verkregen wordt (malware, jailbreak, etc.);
  3. Fysiek. Toegang bij verlies of diefstal van het apparaat. Vergrendeling van het apparaat vormt dan slechts een eerste barrière.

Architectuurmodel

Inleiding

KING ziet mobiele applicaties als een middel om via het mobiele kanaal aan te sluiten op de gemeentelijke informatievoorziening. Figuur 3 toont een concept model van het gemeentelijk gegevenslandschap en de positie van mobiele applicaties hier in [1].

Gemeentelijk gegevenslandschap v0.72.png

Figuur 3: Gemeentelijk gegevenslandschap v0.72 (11)

Een essentieel aspect van dit model is dat er een strikt onderscheid gemaakt wordt tussen de gebruikerstoepassingen en de gebruikte informatiediensten met het achterliggende, gemeente specifieke IT-inrichting. Deze scheiding faciliteert een bimodale inrichting van de informatievoorziening met enerzijds een robuuste, veilige en stabiele inrichting van het gemeentelijk IT-landschap ontsloten via informatiediensten en anderzijds een flexibele front-end waarin mobiele applicaties zeer snel ontwikkeld en aangepast kunnen worden.

Bimodaal IV model.png

Figuur 4: Bimodaal IV model

Een ander belangrijk aspect is dat er, naast de informatiediensten die gemeentelijke informatie zelf toegankelijk maken, er ook beheerdiensten zijn die bijvoorbeeld de toegang tot informatie regelen. Zo kan een burger bijvoorbeeld zelf bepalen wie er toegang tot zijn gegevens krijgt. Dit geeft een expliciete invulling van het uitgangspunt dat de burger zelf eigenaar is van zijn/haar gegevens. Dit uitgangspunt is ook de essentie van de Inwonerscloud van de gemeente Woerden.

Op basis van dit model toont Figuur 2 de ‘lagen’ die onderscheiden worden in de architectuur mobiel:

  1. De gebruiker(s)
  2. De front-end (de app)
  3. Het (fysieke) mobiele apparaat
  4. Het besturingssysteem van het mobiele apparaat
  5. Het netwerk (internet)
  6. De generieke informatiediensten waar de front-end gebruik van maakt
  7. De achterliggende bronsystemen
  8. Informatiebeveiliging op de verschillende lagen.

De mobiele architectuur is niet specifiek gerelateerde aan bepaalde bedrijfsfuncties. Mobiele applicaties kunnen, net als andere applicaties, vrijwel alle bedrijfsfuncties ondersteunen. Overigens kunnen er ook mobiele applicaties ontwikkeld worden die geen directe relatie hebben met het gemeentelijk bedrijfsfunctiemodel. Dit architectuuraspect wordt daarom niet behandeld in dit katern. De onderstaande paragrafen gaan dieper in op de verschillende lagen.

Applicatielaag

De keuze welke technologie gebruikt wordt voor het realiseren van een mobiele applicatie hangt van een aantal factoren af zoals de herbruikbaarheid, het gebruik van specifieke functionaliteiten van mobiele apparaten, de doelgroep etc. Aangezien dit per gemeente, per doelgroep en per functie verschilt is er expliciet geen principe opgesteld die hier een voorkeur voor uitspreekt. In (15) is een hoofdstuk over de softwarearchitectuur opgenomen met daarin een ‘scorelijst’ waarbij native, web en hybride apps op detailpunten aan elkaar worden gewogen. Dit katern volstaat met de onderstaande beslisboom :

800px

Figuur 5: Beslisboom mobiele applicatie technieken

Kwaliteitseisen en -richtlijnen mobiele applicaties Naast generieke kwaliteitseisen kennen mobiele applicaties een aantal specifieke kwaliteitseisen. De onderstaande tabel somt deze op alsmede een aantal generieke eisen die ook op andere applicaties van toepassing maar (nog) niet eerder expliciet benoemd zijn.

Eis/ richtlijn Toelichting Bron
De applicatie dient ontworpen te zijn om om te kunnen gaan met niet beschikbare informatiediensten en internet. Door de mobiele aard van apparaten kan de internet connectie regelmatig wegvallen of zelfs niet beschikbaar zijn. MA2
Voorkeuren van de afnemer worden bewaard en hergebruikt. Dit geldt binnen een applicatie, maar ook in de keten en over kanalen. NORA AP20
Mobile first webdesign Mobiele apparaten worden ook vaak gebruikt om websites te bezoeken. Om deze toegankelijk en gebruikersvriendelijk te maken op mobiele apparaten zullen hiervoor specifieke maatregelen genomen moeten worden. Een best practice ontwerpfilosofie hiervoor is mobile first.
  • Websites worden in eerste instantie ontwikkeld voor het kleinste scherm en van vandaar uit opgeschaald naar grotere viewports (17);
  • Invoermogelijkheden zullen getuned moeten worden voor mobiele apparaten;
-
Vermijd lokale opslag van gevoelige informatie Opslag van gevoelige informatie op een mobiel apparaat dient vermeden, of minimaal versleuteld, te worden (zero-footprint) op basis van de data classificatie. Ook moet er geen ‘technisch gevoelige informatie’ op het apparaat opgeslagen (wachtwoorden, sleutels, interne URLs). Zie CIP (16) eis 5 en eis 8. MA5
Vermijd lokale opslag van relevante business logica Voor ‘relevante’ business logica in applicaties geldt hetzelfde als voor gevoelige informatie. MA5
Applicaties zorgen zelf voor veilige toegang tot de applicatie en de informatie. Applicaties dienen zelf maatregelen te nemen voor beveiligde toegang tot gevoelige informatie indien de dataclassificatie-niveau dat vereist. Waar mogelijk maken de applicaties gebruik van standaard bouwblokken zoals bijvoorbeeld voor authenticatie. MA5
Controleer op aansluitvoorwaarden In het geval van niet openbare gegevens controleren applicaties of er aan een minimale set aansluitwaarden voldaan is voordat ze (mogen) aanloggen op de gegevensdiensten. Dit geldt ook voor het betreffende besturingssysteem. Zie CIP (16) eis 2. MA5
Bepaal vooraf de lifecyle- en updatestrategy Zowel de architectuur van de applicatie als de in te regelen ondersteuning en beheer zijn in belangrijke mate afhankelijk van de life-cycle- en updatestrategie. Ook de informatiebeveiligingsrisico’s zijn hieraan gerelateerd.
  • Bepaal de life-cyclestrategie van de applicatie. Is het experiment, een éénmalig product of is het een integraal onderdeel van de gemeentelijke dienstverlening?
  • Bepaald hiermee de ontwikkelstrategie (hardcoded/configurabel, 100% of 80/20, zware invoercontrole, etc.)
  • Richt hier ook de juiste ondersteuning op in en communiceer duidelijk welke ondersteuning verwacht kan worden en hoe lang;
  • Bepaal of er een verplichte updatestrategie is (o.a. vanuit informatiebeveiligingsperspectief) en of oudere versies geblokkeerd worden 16 eis 3];
  • Bepaal of de applicatie eisen stelt aan een up-to-date besturingssysteem en of de applicatie op oudere besturingssystemen geblokkeerd moet worden.
EMR (15),CIP (16) eis 3 (up-to-date apps)
Scheiding gebruikersinterface en data en business logica De gebruikersinterface wordt gescheiden van data en business logica en gekoppeld via open standaarden. Light-weight userinterfaces hebben de voorkeur. De business logica en data worden waar mogelijk geïntegreerd in gemeentelijke informatiediensten.
  • De modules en koppelingen tussen de modules worden ‘fail-safe’ ontworpen. In het bijzonder is het niet beschikbaar kunnen zijn van andere modules en diensten een uitgangspunt (zie ook MA1: design for failure);
Apps gebruiken alleen vertrouwde broncode bibliotheken van derden (16) eis 5)
GEMMA principe 5, 6 en 7.
Deelfunctionaliteiten worden in (herbruikbare) modules ontwikkeld GEMMA principe 5, 6 en 7.
De modules en koppelingen tussen de modules worden ‘fail-safe’ ontworpen. In het bijzonder iMA1s het niet beschikbaar kunnen zijn van andere modules en diensten een uitgangspunt. MA1

Een belangrijk vraagstuk is hoe de gemeenten de kwaliteit van applicaties – en hierin de beveiliging in het bijzonder – kunnen borgen (zie ook de eerste vraag van het GPO in hoofdstuk 1). Zeker gezien de visie dat de applicatieontwikkeling aan de markt wordt overgelaten. Om deze vraag te beantwoorden moeten onderscheid gemaakt worden tussen drie soorten applicatiegroepen:

  1. Applicaties die gebruik maken vrij beschikbare data en/of informatiediensten; Voor deze categorie mobiele applicaties kan de gemeente weinig tot geen eisen stellen aan de kwaliteit van de applicatie en gezien de wens om de markt hier vrij te laten is het ook de vraag of dit wenselijk is.
  2. Applicaties die ontwikkeld worden in opdracht van de gemeente en waar het eigenaarschap bij de gemeente ligt; Voor deze categorie applicaties is de gemeente opdrachtgever en eigenaar en heeft een verantwoordelijkheid de kwaliteit te borgen. Als basis hiervoor kan dit katern en de gerelateerde stukken gebruikt worden.
  3. Applicaties die gebruik maken niet vrij beschikbare informatiediensten – dus met minimaal een vorm van autorisatie. Voor deze categorie applicaties is het moeilijk om invloed op de kwaliteit van de applicatie zelf uit te oefenen. Wel is sturing op het juiste gebruik van de informatiediensten mogelijk. Hiervoor kunnen leveringsafspraken gemaakt worden en kan er op de naleving gestuurd worden.

Een ander instrument is het gebruik van een app-store. Bij de rijksdiensten er is bijvoorbeeld een rijksapp-store beschikbaar waarin alleen apps worden opgenomen die aan bepaalde voorwaarden voldoen. Ook voor de gemeenten kan er een app-store opgezet worden of de gemeenten kunnen aansluiten bij een bestaande app-store van de overheid. KING heeft aangegeven hier niet de juiste organisatie voor te zijn. Merk overigens op dat hiermee alleen de native apps geraakt worden.

Besturingssysteem

Voor elke toepassing moet expliciet bekeken worden welke besturingssystemen ondersteund worden. Dit geldt niet alleen voor native applicaties, maar ook voor webapplicaties. Elk besturingssysteem heeft zijn eigen specifieke kenmerken, maar ook de gebruikte browsers op dit besturingssysteem hebben hun eigen specifieke kenmerken. Er kan niet van uitgegaan worden dat een webapplicatie op elke browser werkt.

Bij het vaststellen welke besturingssystemen ondersteund moeten gaan worden spelen (minimaal) de volgende afwegingen mee:

  1. Welke voorkeuren heeft de gebruiker (principe MA 4)?
  2. Wat zijn de kosten en baten (in termen van aansluiting bij de gebruikersvraag) voor het ondersteunen van welke platformen. In (15) wordt een indicatie gegeven van het gebruik van mobiele platformen in Q3-2016:
    • Android 87%
    • iOS 12,5%
    • Windows 0,3%
    • Overig 0,4%
  3. Zijn er specifieke beveiligingsrisico’s voor een bepaald besturingssysteem?

Mobiel apparaat

Bij deze keuze voor een mobiel apparaat spelen min of meer dezelfde afwegingen als voor het mobiele besturingssysteem. Daarnaast spelen ook zaken als:

  1. Smartphone of tablet? In het bijzonder spelen hier de omvang van het scherm en de performance eisen mee.
  2. Gaat het om incidenteel gebruik of structureel gebruik? Een mobiel apparaat mag in geen geval als vervanger van de werkplek apparatuur gezien worden, mede vanwege de Arbowetgeving.

Internet

De mobiele applicaties worden via het internet gekoppeld aan de informatiebronnen. In sommige gevallen gaat het om publieke gegevens maar soms ook over gevoelige gegevens. Principe MA5.1 stelt dat de dataclassificatie bepaald welke beveiligingsmaatregelen er nodig zijn. Mogelijke maatregelen zijn:

  • Het versleutelen van het berichtenverkeer;
  • Alleen veilige, afgeschermde WiFi-netwerken gebruiken;
  • Alleen internet via 4G toestaan (en geen WiFi);
  • Etc.

Ook moet er rekening mee gehouden worden dat de internetverbinding regelmatig weg kan vallen. Dit houdt in dat er maatregelen genomen moeten worden om (zie principe GEMMA-principe 5):

  • De stabiele werking van de applicatie te kunnen blijven garanderen bij het (tijdelijk) wegvallen van de internetverbinding;
  • Gegevens transactioneel worden bijgewerkt om data consistentie te garanderen;
  • De applicatie herstartbaar is in een stabiele toestand.

Dezelfde eisen gelden voor het ‘wegvallen van de verbinding’ doordat de batterij van het mobiele apparaat leeg is.

Generieke informatiebronnen

De volgende groepen generieke informatiebronnen worden onderscheiden:

  1. Basisregistraties;
  2. Gemeentelijke (open) datadiensten;
  3. Overige publieke informatiebronnen van de overheid
  4. Private informatiebronnen.

De generieke informatiebronnen zijn om een aantal redenen belangrijk. Enerzijds stelt de NORA dat de geleverde dienst via de verschillende kanalen hetzelfde resultaat heeft (NORA AP11) anderzijds zijn er veel principes die het gebruik van standaarden en herbruikbare componenten promoten (AP06, AP07, AS08, GEMMA-principe 5 en MA6). Voordelen zijn onder meer (niet limitatief):

  • Schaalvoordeel bij de ontwikkeling van toepassingen;
  • Verkorten ontwikkeltijden (o.a. door hergebruik van interfaces en functies hierop);
  • Gegevensportabiliteit (bij migraties, overdracht tussen gemeenten onderling, etc.);
  • Betere kwaliteit;
  • Vereenvoudiging gegevensuitwisseling tussen gemeentelijke afdelingen, gemeenten onderling en ketenparters;
  • Etc.

Basisregistraties

Het stelsel van Nederlandse basisregistraties is volledig beschreven en zal in dit katern niet verder uitgewerkt worden. Een goede ingang voor meer informatie is (21).

Gemeentelijke (open) databronnen

Qua gegevensstandaarden kent KING twee gegevenssets die via gestandaardiseerde koppelvlakken ontsloten kunnen worden:

  • Basisregistraties, conform het RSGB (25)
  • Zakendiensten, conform het RGBZ (26)
  • Zaaktypen, conform het ImZTC (27)

Voor ontsluiting van sectorale gegevens zijn geen berichtstandaarden beschikbaar.

Berichtenstandaarden

De gegevensdiensten die door KING worden ondersteund zijn gebaseerd op StUF-berichten (soap/XML). Voor mobiele applicaties is het gebruik van soap/ XML, mede door de grote overhead van gegevens die overgedragen worden met XML niet aan te raden. Bij mobiele applicaties is het gebruik van rest/json koppelingen gebruikelijk. Door KING zijn i.c.m. de gemeente Den Haag de eerste stappen gezet op het vlak van JSON (19). Vanuit de omgevingswet, en dan specifiek het DSO, is een API-strategie opgesteld die specifiek gaat over de wijze van toepassing van REST [20]/JSON. Adoptie van deze API-strategie door KING is in het kader van de standaardisatie van berichtuitwisseling in de overheid gewenst.

Gemeentelijke API-strategie

Mobiele applicaties nemen gegevens van de gemeente af via Application Programming Interfaces ofwel APIs. Een API is een gebruikersinterface voor ontwikkelaars – hiervoor geldt, zoals bij elke gebruikersinterface, dat het belangrijk is dat de gebruikerservaring goed doordacht is. Deze gebruikerservaring dient ook, ongeacht de gemeente die een API aanbiedt, identiek te zijn. Vanuit het oogpunt van een ontwikkelaar zouden alle gemeenten een uniforme API-strategie moeten hanteren en ook identieke APIs bieden. Om dit te bereiken wordt vanuit KING gewerkt aan een kaderstellende gemeentelijke API-strategie. Deze API-strategie gaat uit van een API-first strategie. Dit betekent dat de API ontworpen en gebouwd wordt onafhankelijk van de front-end(s) waarin deze gebruikt wordt. Een API is hiermee een product op zichzelf. Een API moet elk kanaal kunnen bedienen en niet één specifiek kanaal. Dit wil niet zeggen dat de API los van de werkelijkheid wordt ontwikkeld. Er wordt afgestemd met de verschillende partijen en hun input wordt gebruikt bij het ontwikkelen, beheren en onderhouden. Een API is een combinatie van het koppelvlak, documentatie en andere ondersteunde hulpmiddelen.

Onderdeel van de API-strategie is een segmentering naar interactiepatronen. Voorbeelden van interactiepatronen zijn vraag-antwoord, synchronisatie, levering en transactionele interacties. Per interactiepatroon worden kaders opgesteld die gelden voor de APIs die binnen dat interactiepatroon gehanteerd worden. Te denken valt hierbij aan kaders en richtlijnen ten aanzien van architectuurconcepten (SOAP/WSDL, REST) en berichtstandaarden (XML, StUF, JSON).

De gemeentelijke API-strategie wordt door KING in samenwerking met het Digitaal Stelsel Omgevingswet (DSO) ontwikkeld. Doel is te komen tot een landelijk geldende overheid API-strategie, of als dat een brug te ver is een gemeentelijke API-strategie die in lijn is met de API-strategie van het DSO.

(24) Beschrijft een aantal afwegingen ten aanzien van gebruiksvriendelijkheid versus beveiliging bij mobiele interfaces. Ook wordt hierin de standaard OAuth 2.0 beschreven die op de PTOLU lijst in de lijst van te onderzoeken standaarden staat. Deze staat nog voor de introductie van deze standaard on-hold tot een toepassingsprofiel voor de Nederlandse overheid is gedefinieerd. De authenticatie (SAML) en de autorisatie (OAuth/OpenID connect) aspecten van mobiele applicaties zijn goede kandidaten om later in de architectuur op te nemen.

Overige publieke databronnen

Deze worden in dit katern niet nader beschreven.

Private informatiebronnen

Deze worden in dit katern niet nader beschreven.

Bronsystemen

Dit zijn de achterliggende gemeentelijke informatiesystemen. Voor de scope van deze architectuur is hun enige functie het zorgen dat de generieke informatiediensten de juiste informatie hebben.

Informatiebeveiliging

Mobiele apparaten en platform

Voor de beveiliging van mobiele apparaten moeten wordt een tweedeling gemaakt. Enerzijds hebben zijn er de mobiele apparaten van afnemers van de gemeentelijke diensten (inwoners, ondernemers en ketenpartners). En anderzijds de eigen medewerkers. Voor de afnemers van de gemeentelijke diensten is er weinig invloed uit te oefenen welke mobiele apparaten gebruikt worden en welke beveiligingsmaatregelen ze zelf dienen te gebruiken. Stuurmiddelen op dit gebied beperken zich tot ondersteuning in de bewustwording (principe MA2) en eventueel het softwarematig beperken van de type mobiele apparaten. Voor de eigen medewerkers zou een CYOD-beleid gevoerd kunnen worden. Dit geeft de mogelijkheid om mobile device management (MDM) technieken te gebruiken om updates, beveiligingsinstellingen, etc. af te dwingen (principe MA6.5). In de praktijk zal er echter een groei naar BYOD plaatsvinden (principe GEMMA-principe 5).

Mobiele applicaties

De beveiliging van de applicaties zelf valt formeel buiten de scope van dit katern. Dit is echter wel een belangrijk onderdeel in de keten van beveiligingsmaatregelen. Het CIP (16) geeft een uitgebreide baseline met beveiligingseisen aan mobiele applicaties en wordt sterk aanbevolen om als basis te gebruiken.

Mobiele informatiediensten

Mobiele informatiediensten van de gemeente worden ontwikkeld volgens de geldende (gemeentelijke) richtlijnen uit onder meer de GEMMA [09] en de BIG [22]. De gebruikte integratiearchitectuur staat beschreven in (18). Dit alles borgt dat de gemeentelijke informatie die wordt aangeboden aan publieke maar ook interne mobiele applicaties voldoende beveiligd is tot en met het niveau van connectie. Hiervoor worden de standaard authorisatiemechanismen gebruikt die hiervoor beschikbaar zijn (principe MA5.2).
  1. Op het moment van schrijven is dit model en de uitwerking nog ontwikkeling. Desalniettemin geeft dit wel een duidelijke visie op dit vlak.