Technische infrastructuur voor e dienstverlening en ketensamenwerking
Upcoming SlideShare
Loading in...5
×
 

Technische infrastructuur voor e dienstverlening en ketensamenwerking

on

  • 394 views

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

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

Statistics

Views

Total Views
394
Views on SlideShare
394
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Technische infrastructuur voor e dienstverlening en ketensamenwerking Technische infrastructuur voor e dienstverlening en ketensamenwerking Document Transcript

  • 2013Technische Architectuurvoor dienstverlening enketensamenwerking“Simpel, want complex betekent fouten maken en is dus niet veilig. ”PAUL GEURTS, BAS VAN DER HOEVEN, GERARD DE WITTE, NICO VAN DERVEEN, PAUL VAN BERGENGEMEENTE NIJMEGEN | Afdeling I&A
  • Technische Infrastructuur voor E-dienstverlening en Ketensamenwerking“Simpel, want complex betekent fouten maken en is dus niet veilig.”InleidingOnze huidige technische infrastructuur is vooral geoptimaliseerd voor het goed kunnen(samen)werken door eigen collegas binnen de eigen gebouwen.Het digitaal samenwerken met externe partijen, waaronder e­dienstverlening aan burgers enbedrijven, 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 situatieTot nu toe hebben we dit opgelost in een hybride infrastructuur met gescheiden platformen voorintern en extern gebruik.Intern is het eigen LAN en het Microsoft platform dominant in de infrastructuur. Extern is internetintussen de facto het dominante platform.Daartussen hebben we voorzieningen om informatie uit te wisselen tussen deze gescheidenplatformen, zoals een firewall, DMZ, broker, internetfeed voor medewerkers.Daarnaast hebben we voor eigen gebruik een aantal internetvoorzieningen gekopieerd naar heteigen platform, bijvoorbeeld MS Exchange voor e­mail, Intranet als interne website, webservicesop de Centric backoffice applicaties. Tenslotte kopiëren/emuleren we het interne domein Karelstadook deels weer naar buiten, bijvoorbeeld via Citrix en OWA.IT­sec heeft afgelopen jaar een audit gedaan op onze infrastructuur. Hoewel het rapport vanuittechnisch perspectief nuttige aanbevelingen geeft om besmetting en hacks te voorkomen, zal hetverder dichttimmeren van onze omgeving zeker geen bijdrage leveren aan de samenwerkingen, enzijn de maatregelen die worden voorgesteld praktisch en financieel niet allemaal even makkelijk uit tevoeren. Onze infrastructuur is complex en ingewikkeld en heeft zeer veel koppelingen in zich. Demaatregelen die worden voorgesteld maken de infrastructuur nog duurder en complexer, waardoordeze waarschijnlijk door menselijke fouten kwetsbaardere wordt dan zonder. 1|Pagina
  • Gewenste situatieBij een nieuwe infrastructuur voor e­dienstverlening zou je daarom moeten overwegen om dehuidige hybride infrastructuur om te bouwen naar een integrale infrastructuur, die zowel geschiktis 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 alsketensamenwerking wordt beschouwd)Februari 2013Auteurs: Paul Geurts, Bas van der HoevenRedactie: Gerard de Witte en Nico van der VeenMet medewerking van Paul van Bergen. 2|Pagina View slide
  • InhoudsopgaveInleiding ................................................................................................................................................... 1 Huidige situatie ................................................................................................................................ 1 Gewenste situatie ............................................................................................................................ 2Inhoudsopgave ........................................................................................................................................ 31. 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 ....................................................................................................... 82. 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. .......................................................................................................... 133. Conclusies en aanbevelingen ........................................................................................................ 13 Conclusies .......................................................................................................................................... 13 Aanbevelingen ................................................................................................................................... 14 3|Pagina View slide
  • 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 dewereldstandaarden en architecturen, de landelijke, door de overheid vastgestelde principes enpassen 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)KenmerkenKenmerkend 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 softwareDe SOA-principes zijn al decennia bekend binnen de softwareontwikkeling. Sinds het begin van de21e eeuw heeft de software-industrie SOA aangegrepen voor technische dienstverlening,zoals ESB, XML, SOAP, webservices. De technologische benadering van SOA is alleen geschikt omplatformonafhankelijke communicatie te bewerkstelligen. SOA komt tot zijn recht wanneer eenorganisatie(onderdeel) de SOA principes toepast op zichzelf en daarmee ook de ICT dienstverleninghierop aanpast. 4|Pagina
  • SOA GovernanceSOA 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.ESBEnterprise service bus (ESB). Hoewel de definitie van een ESB zeer afhankelijk is van wiens opiniemen vraagt, zijn er toch enkele gemeenschappelijke kenmerken te herkennen. Zo wordt detransformatie van berichten en routing binnen een SOA-omgeving toegewezen aan deverantwoordelijkheid van de ESB.VoordelenEr 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
  • NORA IIIDe Nationale Overheids Referentie Architectuur (NORA III) kiest ook voor service oriëntatie.Zij vertaalt deze serviceoriëntatie naar 10 basisprincipes.Gemeentelijk FundamentBovenliggen principes voor service oriëntatie zijn op het gebied van de technische architectuur nietverder vertaald naar de Gemma. Deze doet alleen handreikingen op proces en informatiearchitectuur. Het gemeentelijk fundament werkt deze laag wel verder uit. 6|Pagina
  • Het fundament geeft dus een kader waarbinnen de gemeente vrij is haar eigen keuzes te maken overde technische inrichting en toont ook de problemen die spelen op het gebied van de koppelbaarheidvan diensten. Communicatie binnen de overheid is goed geregeld middels digikoppeling en de STUFstandaard. Voor elke communicatie daarbuiten zijn nog geen concrete richtsnoeren te vinden.Dossier Informatie beveiligingOp http://e­overheid.nl/onderwerpen/architectuur­en­nora/982­dossier­informatiebeveiliging is in2010 het dossier Informatie beveiliging een best­practise uitgewerkt. Deze best practise geeft ons eeninzicht in de componenten en onderdelen die onder informatiebeveiliging vallen.http://e­overheid.nl/images/stories/nieuws_2010/normenit_noradossier_informatiebeveiliging.pdfgeeft een normenkader voor informatiebeveiliging en de inrichting van de technische infrastructuuren zijn deels ontleed aan de Code voor informatiebeveiliging. Het model is een doorontwikkeling vanISO­NEN 7498­2. 7|Pagina
  • Lokaal principe Triple A voor dataIn 2012 is binnen de gemeente de notitie “Triple A voor data” vastgesteld. Hieronder het citaat datgaat over de aanleiding van de notitie.In de notitie worden op basis van onderzoek uiteindelijk de onderstaande richtlijnen enaanbevelingen geformuleerd die nu van toepassing zijn op databeveiliging. 8|Pagina
  • 2. Technische Architectuur voor dienstverlening en ketensamenwerking.Voor de uitwerking van deze technische architectuur volgen we het normenkader van het NORAdossier informatiebeveiliging. Onderstaand model komt uit dit normenkader en geeft aan waaromafspraken gemaakt moeten worden. Het normenkader beschrijft de “WAT”–laag. Het is aan de lokaleorganisatie om de “HOE” en “WAARMEE” laag zelf in te vullen. De onderstaande componenten zijnniet uitputtend, maar indicatief. Het is aan ons om aan de hand van deze hoofdfuncties de HOE enWAARMEE 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 staatuit te werken. We focussen ons binnen deze opdracht op die componenten die bijdragen aan hetrealiseren van de infrastructuur voor e­dienstverleningen ketensamenwerking. We adviseren hetnormenkader te omarmen en te gaan toepassen en voor die delen waar we afwijken, uit te leggenwaarom we dit anders doen. Dit zou een vervolgopdracht moeten zijn. Daarna kan dit verder wordenuitgewerkt voor de abstractielaag “Waarmee”. 9|Pagina
  • Technische ArchitectuurOnderstaand schema geeft op logisch het “HOE” niveau de technische architectuur weer voordienstverlening en ketensamenwerking. Onder dit schema worden verschillende onderdelen verderuitgewerkt.ToegangToegang tot gemeente diensten en gegevens gaat via onze eerste firewall, de webguard. Via dewebguard 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 serviceBus (ESB), die als een gateway functioneert. 10 | 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 aanmelderzal deze een autorisatie krijgen toegewezen om binnen het LAN en service of API van een applicatieaan te roepen. Eigenlijk vervangt de ESB die ADA­buiten voorziening. De ESB heeft een eigendirectory 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 viaencryptie plaatsvinden.Als een applicatie draait in de Private Service Cloud een eigen Service bus voorziening heeft en dezevoldoende veilig is bevonden, kan deze rechtstreeks via http met het interne netwerk communicerenzoals 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 enberichten zoals STUF. Wij beschouwen deze services bussen als generieke koppelvlakken voorbackofficeapplicaties en niet als ESB functionaliteit.Www.nijmegen.nlNijmegen.nl is de publieke cloud en portaal voor onze bezoekers. Communicatie met het LAN vindtplaats via de ESB.Private Service CloudWebapplicaties zonder AD koppeling, de mid­office suite, applicaties voor ketensamenwerking enapplicaties voor regionale samenwerking plaatsen we in een private service cloud. Deze cloud is geenMicrosoft 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 Appwordt bepaald wat de best passende identificatie en authenticatie methode is. Steeds meerapplicaties gaan webbased in deze private service cloud draaien. Communicatie vindt plaats via deESB voor customer­application communicatie en application – application communicatie. 11 | P a g i n a
  • Communicatie met de overheidWe vertrouwen de overheidspartijen in standaarden en technische oplossingen. De communicatiemet en tussen de overheid gaat via digikoppeling over Gemnet. We maken van deze voorzieninggebruik voor application to application koppelingen en beveiligde email verbindingen. De 2e firewallrouteert verzoeken van de ESB naar interne servers en services. Alleen http en ftp verkeer wordthierover toegestaan.Karelstad en regio domeinenBinnen het LAN is plaats voor verschillende domeinen. Deze zijn onderling verbonden via glasvezel.Domeinen worden, indien noodzakelijk, onderling vertrouwd (trust) waardoor informatieuitwisselingen kan plaatsvinden tussen de verschillende domeinen. Binnen het Microsoft DomeinKarelstad bieden we services aan voor dienstverlening en applicaties voor samenwerking die omdiverse redenen nog niet in de Private Servicecloud geplaatst kunnen worden.VoorbeeldenMid-officeDe nieuwe mid­office is afhankelijk van deze nieuwe infrastructuur. Intelligente Webformulierenmaken gebruik van gegevens afkomstig uit het interne netwerk. Het zaaksysteem moet zodanigworden neergezet dat niet alleen exclusief medewerkers van de gemeente Nijmegen hierbij kunnenkomen. 12 | 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 kanvia domeintrust gegevens en rechten worden verdeeld over en tussen de domeinen. Het nieuwe VTHkan vervolgens in de Private Service Cloud worden ondergebracht, of kan volledig extern gehostworden en kan ten alle tijden gegevens op halen van basisregistraties ( lokaal of landelijk) en digitalezaakdossiers aanmaken per gemeente of later centraal. 3. Conclusies en aanbevelingenConclusies 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
  • 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