Technische Architectuur

voor dienstverlening en

ketensamenwerking

2013

“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

1 | P a g i n a

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.

2 | P a g i n a

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.

3 | P a g i n a

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

4 | P a g i n a

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.

5 | P a g i n a

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).

6 | P a g i n a

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.

7 | P a g i n a

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.

8 | P a g i n a

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.

9 | P a g i n a

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”.

10 | P a g i n a

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.

11 | P a g i n a

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.

12 | P a g i n a

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.

13 | P a g i n a

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.

14 | P a g i n a

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.