Informatie/technische architectuur hoe de gemeente Nijmegen verdere stappen zet in service orientatie en edienstverlening , ketensamenwerking en regionalisering gaat ondersteunen

1. 2013
Technische Architectuur
voor dienstverlening en
ketensamenwerking
“Simpel, want complex betekent fouten maken en is dus niet veilig. ”
PAUL GEURTS, BAS VAN DER HOEVEN, GERARD DE WITTE, NICO VAN DER
VEEN, PAUL VAN BERGEN
GEMEENTE NIJMEGEN | Afdeling I&A

2. Technische Infrastructuur voor E-
dienstverlening en Ketensamenwerking
“Simpel, want complex betekent fouten maken en is dus niet veilig.”
Inleiding
Onze huidige technische infrastructuur is vooral geoptimaliseerd voor het goed kunnen
(samen)werken door eigen collega's binnen de eigen gebouwen.
Het digitaal samenwerken met externe partijen, waaronder e­dienstverlening aan burgers en
bedrijven, wordt echter steeds belangrijker:
 Via het digitale kanaal maken klanten steeds vaker direct gebruik van onze interne data
en voorzieningen (webformulieren,selfservice, extranet, afspraaksysteem,
zaakregistratie, MijnNijmegen)
 Hetzelfde geldt voor ketenpartners, zoals uitvoeringsdiensten en woningcorporaties.
Eigen medewerkers werken steeds vaker buiten de eigen gebouwen, deels via een
externe infrastructuur zoals eigen apparatuur, een thuisnetwerk, internet e.d.
 We willen zelf ook extern samenwerken met anderen, bijvoorbeeld met regiogemeenten
of binnen projecten.
 Onze basisregistraties worden binnenkort gemigreerd naar centrale landelijke voorzieningen.
 Sommige backoffice systemen worden al volledig extern als SaaS afgenomen (GBA­V,
RAN, Permixx, Leerplicht, SuWiNet, Bekendmakingen)
Huidige situatie
Tot nu toe hebben we dit opgelost in een hybride infrastructuur met gescheiden platformen voor
intern en extern gebruik.
Intern is het eigen LAN en het Microsoft platform dominant in de infrastructuur. Extern is internet
intussen de facto het dominante platform.
Daartussen hebben we voorzieningen om informatie uit te wisselen tussen deze gescheiden
platformen, zoals een firewall, DMZ, broker, internetfeed voor medewerkers.
Daarnaast hebben we voor eigen gebruik een aantal internetvoorzieningen gekopieerd naar het
eigen platform, bijvoorbeeld MS Exchange voor e­mail, Intranet als interne website, webservices
op de Centric backoffice applicaties. Tenslotte kopiëren/emuleren we het interne domein Karelstad
ook deels weer naar buiten, bijvoorbeeld via Citrix en OWA.
IT­sec heeft afgelopen jaar een audit gedaan op onze infrastructuur. Hoewel het rapport vanuit
technisch perspectief nuttige aanbevelingen geeft om besmetting en hacks te voorkomen, zal het
verder dichttimmeren van onze omgeving zeker geen bijdrage leveren aan de samenwerkingen, en
zijn de maatregelen die worden voorgesteld praktisch en financieel niet allemaal even makkelijk uit te
voeren. Onze infrastructuur is complex en ingewikkeld en heeft zeer veel koppelingen in zich. De
maatregelen die worden voorgesteld maken de infrastructuur nog duurder en complexer, waardoor
deze waarschijnlijk door menselijke fouten kwetsbaardere wordt dan zonder.
1|Pagina

3. Gewenste situatie
Bij een nieuwe infrastructuur voor e­dienstverlening zou je daarom moeten overwegen om de
huidige hybride infrastructuur om te bouwen naar een integrale infrastructuur, die zowel geschikt
is voor eigen medewerkers binnen de eigen gebouwen, als voor het digitaal extern samenwerken.
Deze infrastructuur gaat uit van vergaande service oriëntatie.
In deze notitie wordt eerst een aantal architectuurprincipes beschreven op basis van wereldwijde­
landelijke­ en lokale standaarden en principes. Daarna wordt de technische architectuur op het ”hoe”
niveau uitgewerkt voor dienstverlening en ketensamenwerking. (Waarbij de regio ook als
ketensamenwerking wordt beschouwd)
Februari 2013
Auteurs: Paul Geurts, Bas van der Hoeven
Redactie: Gerard de Witte en Nico van der Veen
Met medewerking van Paul van Bergen.
2|Pagina

4. Inhoudsopgave
Inleiding ................................................................................................................................................... 1
Huidige situatie ................................................................................................................................ 1
Gewenste situatie ............................................................................................................................ 2
Inhoudsopgave ........................................................................................................................................ 3
1. Geldende principes en kenmerken van serviceoriëntatie. .............................................................. 4
Wereldwijde principes op het gebied van service georiënteerde architectuur (SOA) ........................ 4
NORA III ............................................................................................................................................... 6
Gemeentelijk Fundament .................................................................................................................... 6
Dossier Informatie beveiliging ............................................................................................................. 7
Lokaal principe Triple A voor data ....................................................................................................... 8
2. Technische Architectuur voor dienstverlening en ketensamenwerking.......................................... 9
Technische Architectuur .................................................................................................................... 10
Toegang.......................................................................................................................................... 10
Enterprise servicebus. (ESB) .......................................................................................................... 10
Www.nijmegen.nl .......................................................................................................................... 11
Private Service Cloud ..................................................................................................................... 11
Communicatie met de overheid .................................................................................................... 12
Karelstad en regio domeinen......................................................................................................... 12
Voorbeelden ...................................................................................................................................... 12
Mid­office ...................................................................................................................................... 12
ODRN / Sociale Wijkteams. .......................................................................................................... 13
3. Conclusies en aanbevelingen ........................................................................................................ 13
Conclusies .......................................................................................................................................... 13
Aanbevelingen ................................................................................................................................... 14
3|Pagina

5. 1. Geldende principes en kenmerken van serviceoriëntatie.
In het oplossen van deze uitdaging zijn we gelukkig niet uniek. De hele
wereld wisselt immers steeds meer informatie uit. Hierbij wordt uitgegaan
van een vergaande service oriëntatie. Ook de landelijke overheid, de lokale
overheid en wij als gemeente doe dit ook door het omarmen van de
principes van NORA, GEMMA en het gemeentelijk fundament. Deze
principes moeten uiteindelijk vertaald worden naar een eigen technische
infrastructuur. KING laat dit over aan de gemeente.
Zowel wereldwijd, nationaal als lokaal gelden architectuurprincipes. We volgen de
wereldstandaarden en architecturen, de landelijke, door de overheid vastgestelde principes en
passen deze toe op lokaal niveau.
Wereldwijde principes op het gebied van service georiënteerde architectuur (SOA)
Wikipedia beschrijft de volgende kenmerken voor service oriëntatie.
(http://nl.wikipedia.org/wiki/Service­ori%C3%ABntatie)
Kenmerken
Kenmerkend voor de diensten (en contracten) is:
 Een service is virtueel: de afnemer heeft geen weet van de implementatie van de dienst. De
dienst is onafhankelijk van de afnemer. Scheiding van verantwoordelijkheid is expliciet
vastgesteld. Voordeel hiervan is onafhankelijkheid van veranderingen van afnemer en leverancier.
Voldoen aan het contract staat immers centraal;
 Een service is gestandaardiseerd: er is slechts één implementatie aanwezig van een
verantwoordelijkheid. Voordeel is het rationaliseren van de standaard. Standaardiseren=massa,
massa=kassa. De dienst wordt 'commodity' en eenvoudig te vervangen door een andere
leverancier of goedkoper door een efficiëntieslag;
 Een service is modulair (vervangbaar) en compositioneerbaar. Standaard is niet flexibel.
Flexibiliteit wordt bereikt door combineren (componeren) van standaards tot een nieuwe
standaard;
 Een service is abstract: generiek, niet afgestemd voor 1 specifieke afnemer, maar op een
doelgroep van afnemers;
 Losgekoppeld: afnemer en leverancier zijn maximaal onafhankelijk van implementatie van beide.
Elke service is daarom autonoom. Er bestaat geen directe link of relatie tussen verschillende
services. Services zijn zich ook niet van elkaar bewust.
SOA en software
De SOA-principes zijn al decennia bekend binnen de softwareontwikkeling. Sinds het begin van de
21e eeuw heeft de software-industrie SOA aangegrepen voor technische dienstverlening,
zoals ESB, XML, SOAP, webservices. De technologische benadering van SOA is alleen geschikt om
platformonafhankelijke communicatie te bewerkstelligen. SOA komt tot zijn recht wanneer een
organisatie(onderdeel) de SOA principes toepast op zichzelf en daarmee ook de ICT dienstverlening
hierop aanpast.
4|Pagina

6. SOA Governance
SOA Governance bestaat in de basis uit drie onderdelen:
 Eigenaarschap van diensten (vaststellen van verantwoordelijkheden);
 Levenscyclus van diensten: de identificatie van een nieuwe (versie van) een dienst, tot en met de
dood van een dienst;
 Funding-model: wie betaalt hoeveel voor wat? Zoals 'flat fee' en 'pay-per-use' abonnementen.
ESB
Enterprise service bus (ESB). Hoewel de definitie van een ESB zeer afhankelijk is van wiens opinie
men vraagt, zijn er toch enkele gemeenschappelijke kenmerken te herkennen. Zo wordt de
transformatie van berichten en routing binnen een SOA-omgeving toegewezen aan de
verantwoordelijkheid van de ESB.
Voordelen
Er zijn verschillende voordelen van een SOA aanpak:
 Flexibiliteit: Door de beschreven principes van de services wordt het veel eenvoudiger om
services te veranderen en nieuwe varianten te combineren zonder consequenties voor andere
onderdelen.
 Governance: Grip hebben op kosten en scheiding van verantwoordelijkheden.
 Kosten: Standaardisatie zorgt voor één implementatie van een dienst, welke weer
gerationaliseerd kan worden. Combineren van diensten tot een nieuwe dienst is relatief
goedkoop.
 Specialisatie: Focus op strategische waarden: massaproductie van een standaard of combineren
van jouw unieke combinatie
 Business-procesvereenvoudiging: diensten vormen ontkoppelpunten binnen businessprocessen.
Hierdoor kunnen proceseigenaren (diensteigenaren) concreter worden aangewezen. De
verantwoordelijkheid van de (deel)proceseigenaar is te overzien. De proceseigenaar weet precies
waar hij/zij aan moet voldoen (service contract).
5|Pagina

7. NORA III
De Nationale Overheids Referentie Architectuur (NORA III) kiest ook voor service oriëntatie.
Zij vertaalt deze serviceoriëntatie naar 10 basisprincipes.
Gemeentelijk Fundament
Bovenliggen principes voor service oriëntatie zijn op het gebied van de technische architectuur niet
verder vertaald naar de Gemma. Deze doet alleen handreikingen op proces en informatie
architectuur. Het gemeentelijk fundament werkt deze laag wel verder uit.
6|Pagina

8. Het fundament geeft dus een kader waarbinnen de gemeente vrij is haar eigen keuzes te maken over
de technische inrichting en toont ook de problemen die spelen op het gebied van de koppelbaarheid
van diensten. Communicatie binnen de overheid is goed geregeld middels digikoppeling en de STUF
standaard. Voor elke communicatie daarbuiten zijn nog geen concrete richtsnoeren te vinden.
Dossier Informatie beveiliging
Op http://e­overheid.nl/onderwerpen/architectuur­en­nora/982­dossier­informatiebeveiliging is in
2010 het dossier Informatie beveiliging een best­practise uitgewerkt. Deze best practise geeft ons een
inzicht in de componenten en onderdelen die onder informatiebeveiliging vallen.
http://e­overheid.nl/images/stories/nieuws_2010/normenit_noradossier_informatiebeveiliging.pdf
geeft een normenkader voor informatiebeveiliging en de inrichting van de technische infrastructuur
en zijn deels ontleed aan de Code voor informatiebeveiliging. Het model is een doorontwikkeling van
ISO­NEN 7498­2.
7|Pagina

9. Lokaal principe Triple A voor data
In 2012 is binnen de gemeente de notitie “Triple A voor data” vastgesteld. Hieronder het citaat dat
gaat over de aanleiding van de notitie.
In de notitie worden op basis van onderzoek uiteindelijk de onderstaande richtlijnen en
aanbevelingen geformuleerd die nu van toepassing zijn op databeveiliging.
8|Pagina

10. 2. Technische Architectuur voor dienstverlening en
ketensamenwerking.
Voor de uitwerking van deze technische architectuur volgen we het normenkader van het NORA
dossier informatiebeveiliging. Onderstaand model komt uit dit normenkader en geeft aan waarom
afspraken gemaakt moeten worden. Het normenkader beschrijft de “WAT”–laag. Het is aan de lokale
organisatie om de “HOE” en “WAARMEE” laag zelf in te vullen. De onderstaande componenten zijn
niet uitputtend, maar indicatief. Het is aan ons om aan de hand van deze hoofdfuncties de HOE en
WAARMEE zelf in te gaan vullen. Het hoe deel wordt uitgewerkt in dit hoofdstuk.
Het ligt niet binnen de scope van deze opdracht om het gehele pallet dat hierboven getekend staat
uit te werken. We focussen ons binnen deze opdracht op die componenten die bijdragen aan het
realiseren van de infrastructuur voor e­dienstverleningen ketensamenwerking. We adviseren het
normenkader te omarmen en te gaan toepassen en voor die delen waar we afwijken, uit te leggen
waarom we dit anders doen. Dit zou een vervolgopdracht moeten zijn. Daarna kan dit verder worden
uitgewerkt voor de abstractielaag “Waarmee”.
9|Pagina

11. Technische Architectuur
Onderstaand schema geeft op logisch het “HOE” niveau de technische architectuur weer voor
dienstverlening en ketensamenwerking. Onder dit schema worden verschillende onderdelen verder
uitgewerkt.
Toegang
Toegang tot gemeente diensten en gegevens gaat via onze eerste firewall, de webguard. Via de
webguard wordt 90% van de bedreigingen tegen gehouden. Hieraan zijn geen aanpassingen nodig.
Op de Webguard draait ook de certificatenserver.
Enterprise servicebus. (ESB)
Voor communicatie vanuit het LAN naar het internet maken we gebruik van een Enterprise service
Bus (ESB), die als een gateway functioneert.
10 | P a g i n a

12. De ESB ondersteunt verschillende soorten van identificatie. Dit kan zijn DigID, AD, username­
wachtwoord combinaties, maar b.v. ook Open ID. Afhankelijk van de authenticiteit van de aanmelder
zal deze een autorisatie krijgen toegewezen om binnen het LAN en service of API van een applicatie
aan te roepen. Eigenlijk vervangt de ESB die ADA­buiten voorziening. De ESB heeft een eigen
directory service. Single Sign On wordt mogelijk door het gebruik van een volledig emailadres.
Verkeer vanaf de ESB naar het LAN vindt plaats zonder encryptie. Verkeer naar de ESB kán via
encryptie plaatsvinden.
Als een applicatie draait in de Private Service Cloud een eigen Service bus voorziening heeft en deze
voldoende veilig is bevonden, kan deze rechtstreeks via http met het interne netwerk communiceren
zoals de generiek ESB ook doet.
Noot: Veel leveranciers (Centric, Gouw, Vicrea) verkopen bij een backofficeapplicatie ook een
(Enterprise) servicebus. Deze bus is voornamelijk bedoeld voor het uitwisselen van gegevens en
berichten zoals STUF. Wij beschouwen deze services bussen als generieke koppelvlakken voor
backofficeapplicaties en niet als ESB functionaliteit.
Www.nijmegen.nl
Nijmegen.nl is de publieke cloud en portaal voor onze bezoekers. Communicatie met het LAN vindt
plaats via de ESB.
Private Service Cloud
Webapplicaties zonder AD koppeling, de mid­office suite, applicaties voor ketensamenwerking en
applicaties voor regionale samenwerking plaatsen we in een private service cloud. Deze cloud is geen
Microsoft domein en maakt geen gebruik van Identificatie en authorisatie van het Karelstad domein.
Hiermee voorkomen we dat we het Karelstad domein eindeloos uitrekken. Per applicatie of App
wordt bepaald wat de best passende identificatie en authenticatie methode is. Steeds meer
applicaties gaan webbased in deze private service cloud draaien. Communicatie vindt plaats via de
ESB voor customer­application communicatie en application – application communicatie.
11 | P a g i n a

13. Communicatie met de overheid
We vertrouwen de overheidspartijen in standaarden en technische oplossingen. De communicatie
met en tussen de overheid gaat via digikoppeling over Gemnet. We maken van deze voorziening
gebruik voor application to application koppelingen en beveiligde email verbindingen. De 2e firewall
routeert verzoeken van de ESB naar interne servers en services. Alleen http en ftp verkeer wordt
hierover toegestaan.
Karelstad en regio domeinen
Binnen het LAN is plaats voor verschillende domeinen. Deze zijn onderling verbonden via glasvezel.
Domeinen worden, indien noodzakelijk, onderling vertrouwd (trust) waardoor informatie
uitwisselingen kan plaatsvinden tussen de verschillende domeinen. Binnen het Microsoft Domein
Karelstad bieden we services aan voor dienstverlening en applicaties voor samenwerking die om
diverse redenen nog niet in de Private Servicecloud geplaatst kunnen worden.
Voorbeelden
Mid-office
De nieuwe mid­office is afhankelijk van deze nieuwe infrastructuur. Intelligente Webformulieren
maken gebruik van gegevens afkomstig uit het interne netwerk. Het zaaksysteem moet zodanig
worden neergezet dat niet alleen exclusief medewerkers van de gemeente Nijmegen hierbij kunnen
komen.
12 | P a g i n a

14. ODRN / Sociale Wijkteams.
De ODRN gaat via een tussenvariant samen met andere Gelderse RUDs samenwerken aan een zgn.
ontwikkelvariant.
De tussenvariant gaat uit van de huidige systemen, gebruikers en documentenopslag. Hiervoor kan
via domeintrust gegevens en rechten worden verdeeld over en tussen de domeinen. Het nieuwe VTH
kan vervolgens in de Private Service Cloud worden ondergebracht, of kan volledig extern gehost
worden en kan ten alle tijden gegevens op halen van basisregistraties ( lokaal of landelijk) en digitale
zaakdossiers aanmaken per gemeente of later centraal.
3. Conclusies en aanbevelingen
Conclusies
1. Deze architectuur vraagt geen zware aanpassingen in het domein Karelstad. Binnen Karelstad
is alles open. Naar buiten toe zetten we zoveel mogelijk alles dicht, alleen http verkeer vanaf
de ESB kan zijn weg naar binnen vinden. Door deze via de 2e firewall te laten wordt slechts
een beperkt aantal servers gekoppeld aan de buitenwereld. Alle informatie die binnen het
domein is dus beveiligd op het hoogste niveau.
2. We passen wereldwijde, nationale en lokale principes toe en leggen uit waarom we hier op
onderdelen vanaf wijken.
3. Deze architectuur is eenvoudig en goed te begrijpen. Met de inzet van een volwaardige ESB
komt er een singel point of access naar het verder gesloten LAN.
4. We hebben met deze architectuur een architectuur die klaar is voor de toekomst, die uitgaat
van een vergaande serviceoriëntatie. Hiermee worden andere methoden van Identificatie,
Authenticatie mogelijk.
5. We komen tegemoet aan de wensen van de klant voor een private servicecloud, we kunnen
dienstverleningsprocessen optimaal ondersteunen en bieden voorzieningen die
ketensamenwerking mogelijk maakt.
13 | P a g i n a

15. Aanbevelingen
1. Start met de selectie van en het in beheer nemen van een ESB. Mogelijke producten zijn ,
Layer7, OpenTunnel, BizzTalk, synapse.apache, Oracle Service bus.
2. Realiseer daarbinnen ook een digikoppeling, digimelding en digilevering voorziening.
3. Start met de inrichting van en het beheer nemen van de private service cloud. Inventariseer
van de huidige applicaties welke applicaties hiervoor in aanmerking komen en welke niet.
4. Werk de technische architectuur op basis van het normen kader voor Informatie beveiliging
verder uit en beleg het beheer van de technische architectuur bij een functionaris.
5. Breidt het GBS dat meegaat bij aanbestedingen uit met een hoofdstuk over technische
architectuur. Toets applicaties vooraf hieraan. Pas het beleid toe of leg uit waarom ervan
wordt afgeweken.
14 | P a g i n a