Solution Architectuur I-Bridge 3.0 De IST en de SOLL
:
Auteur Status Versienummer Datum
: : : :
Drs. V.G. Hoek Definitief V1.0 03-12-2012
1
Inhoudsopgave
1.
INLEIDING ....................................................................................................................... 4
2.
MANAGEMENT SAMENVATTING ................................................................................. 5 2.1 2.2 2.3
3.
DOEL VAN DIT DOCUMENT ........................................................................................................... 5 REVISIEGEGEVENS ..................................................................................................................... 5 SAMENVATTING VAN DIT DOCUMENT ............................................................................................ 5 EISEN AAN DE DOELARCHITECTUUR (SOLL) ........................................................... 7
3.1 VISIE ......................................................................................................................................... 7 3.2 KETENPARTNERS ....................................................................................................................... 8 3.3 BURGERS .................................................................................................................................. 8 3.4 LOCATIE .................................................................................................................................... 8 3.5 W ERKPROCESSEN ..................................................................................................................... 8 3.6 PRINCIPES ................................................................................................................................. 9 3.6.1 De NORA basisprincipes ..................................................................................................... 9 3.6.2 Dienstenaanbod................................................................................................................. 10 3.6.3 Standaard oplossingen ...................................................................................................... 10 3.6.4 Kanalen .............................................................................................................................. 10 3.6.5 Informatie ........................................................................................................................... 11 3.6.6 Vraaggerichtheid op een hoger plan ................................................................................. 11 3.6.7 Sturing en verantwoordelijkheid ........................................................................................ 11 3.6.8 Betrouwbaarheid................................................................................................................ 11 3.6.9 Ontwerpeisen ..................................................................................................................... 11 3.6.10 Argumenten ................................................................................................................... 13 3.6.11 Bouwstenen ................................................................................................................... 13 3.7 FUNDAMENTEN VOOR REALISATIE ............................................................................................. 14 3.8 NEDERLANDSE OVERHEID ......................................................................................................... 15 4.
EISEN AAN DE DOELARCHITECTUUR (IST) ............................................................. 16 4.1 4.2 4.3 4.5
5.
DE INFORMATIE ARCHITECTUUR (IST) .................................................................... 23 5.1 5.2 5.3 5.4
6.
ORGANISATIE COMPONENTEN (W IE) ......................................................................................... 16 BOUWSTENEN (W AT) ............................................................................................................... 17 W ERKPROCESSEN (HOE) ......................................................................................................... 18 ONTWERPREGELS (DESIGN RULES EN ONTWERPSCENARIO’S)..................................................... 22
INFORMATIE ARCHITECTUUR UITGANGSPUNTEN ......................................................................... 23 GEBRUIKERS APPLICATIES (WIE) .............................................................................................. 24 INFORMATIE UITWISSELING (HOE) ............................................................................................. 24 BERICHTEN GEGEVENS (W AT) .................................................................................................. 24 BEVEILIGING ................................................................................................................ 26
6.1.1 Databeveiliging .................................................................................................................. 26 6.2 ARGUMENTEN .......................................................................................................................... 27 6.3 UITWERKING VAN HET BEVEILIGING CONCEPT ............................................................................ 28 7.
NETWERK (HOE) .......................................................................................................... 30
8.
BIJLAGE 1 COMPONENTEN VAN I-BRIDGE ............................................................. 31
9.
BIJLAGE 2: UITLEG GEFEDEREERD IDENTITEIT MANAGEMENT (FIM) ............... 43
2
3
1.
Inleiding
In dit document staat de Solution Architectuur van I-Bridge 3.0 beschreven, inclusief de technische configuratie van de basis infrastructuur die gebruikt is tijdens de gerealiseerde Proofs of Concept. Hierbij is de hoofdstukindeling als volgt is opgebouwd:
Figuur 1.Solution Architectuur i-Bridge
4
2.
Management samenvatting
2.1
Doel van dit document
Het doel van dit document is om de Oplossing en Doel Architectuur van I-Bridge 3.0 te beschrijven, zodat alle beoogde en al concreet gerealiseerde kernfunctionaliteiten en configuraties herleidbaar en interpreteerbaar voor derden zijn. Het I-Bridge programma is de realisatiepoging van verschillende aspecten van het I-Bridge concept: een concept dat ervan uitgaat dat in een gedigitaliseerde samenleving elke vorm van OOV verstoring leidt tot een domino effect van onbedoelde bijverschijnselen. De notie van onvoorspelbaarheid die hieruit voortvloeit heeft geleid tot het I-Bridge concept dat niet standaardiseert, harmoniseert en centraliseert, maar helpt verbinden ‘wat het nog doet’ om tot een veerkrachtig platform te komen dat alle aspecten van commandovoering kan ondersteunen.
2.2
Revisiegegevens
Versie
Datum
Status
Auteur
0.1
16/09/’12
Concept
0.2
29/10/’12
Concept
Drs.V.G. Hoek Drs. V.G. Hoek
0.3
02/12/’12
Concept
Drs. V.G. Hoek
2.3
Goedgekeurd door
Omschrijving
Samenvatting van dit document
Dit document beschrijft de samenhang en werking van de componenten in i-Bridge 3.0. Om meer gevoel te krijgen bij het doel van dit document, de beschrijving van de i-Bridge Solution Architectuur, wordt allereerst aandacht geschonken aan de gedachten achter het i-Bridge concept zelf. Het i-Bridge concept echter, gaat uit van een visie dat op generieke wijze C2 netwerken, informatienetwerken en sociale netwerken in hun onderlinge mogelijkheden optimaliseert, om Situational Awareness (SA) te optimaliseren door de inzet van Networked Enabled Capabilities (NEC). De succesvolle i-Bridge PoCs zou de politieke wil moeten motiveren om dergelijke concepten verder te ontwikkelen door in te zetten op een nog betere schaalbaarheid bij grotere uitrol en de verdere verfijning van ad-hoc samenwerking. Niet door applicaties te kopen en de organisaties daarop aan te passen, maar om de onderlinge mogelijkheden van generieke COTS software creatief te benutten om data onder businessrules te verrijken. I-Bridge heeft aangetoond dat het mogelijk is dat allerlei data contexten en transport middelen elkaar tijdelijk kunnen vinden, om netcentrisch een gedeeld situatiebeeld op te bouwen.
5
Het is een socio-technisch platform dat is gebouwd op het idee dat het faciliteren van ad-hoc data syndicalisatie een noodzakelijke voorwaarde is, om ongelijke gegevens, van organisaties die door omstandigheden (on)verwacht samen moeten werken, zo te verrijken en te verdelen dat men er meer aan heeft. Dit alles tegen de natuurkundige achtergrond dat je in een crisis niet zeker kunt zijn van ononderbroken energie- en bandbreedte voorziening. De gedistribueerde peer2peer benadering van i-Bridge is stabieler gebleken dan de traditionele hub-spoke benadering van de portal of centrale server die niet zonder stroom en stabiele bandbreedte kan. Aangezien i-Bridge een innovatie omgeving is en geen platform dat gebruikt wordt in de dagelijkse operatiën wordt integraal uitgegaan van een prescriptieve doelarchitectuur (“SOLL” situatie) en niet voor een descriptieve bedrijfsarchitectuur. De bijlagen illustreren welke delen van de Visie daadwerkelijk gerealiseerd zijn in de diverse Proof of Concept opstellingen. De tekst volgt hierbij de volgende opbouw:
De doelarchitectuur, uitgesplitst naar: o Organisatie componenten (Wie)\ o Bouwstenen (Wat) o Werkprocessen (Hoe)
De informatie architectuur, uitgesplitst naar: o Gebruikers applicaties (Wie) o Berichten gegevens (Wat) o Informatie uitwisseling (Hoe)
De technische architectuur, uitgesplitst naar: o Technische componenten (Wie) o Gegevens (Wat) o Netwerk (Hoe)
Voor de omschrijving van de beheer architectuur en de beveiligingsarchitectuur wordt dezelfde structuur aangehouden, waardoor de samenhang/communicatie tussen de componenten helder is. De beveiligingsarchitectuur wordt echter wel diepgaander uitgewerkt en besteed tevens aandacht aan de conceptuele architectuur en de contextuele architectuur van de voorgestelde beveiliging. In paragraaf 3 worden de gebruikte koppen in figuur 1 nader toegelicht.
6
3.
3.1
Eisen aan de doelarchitectuur (SOLL)
Visie
Het i-Bridge concept is uitgewerkt naar het Cyclisch Innovatie Model (CIM) van Prof. Dr. Ir. Berkhout (leerstoelinnovatiemanagement TU Delft). Meer over CIM is na te lezen op http://www.scienceworks.nl/nederlands/methoden2.htm
De vierde generatie innovatietheorie stelt dat Visie veel meer is dan een politieke mening. Het is een ‘plausible promise’, een bereikbaar te maken stip op de horizon, een concreet te maken perceptie, waarmee aannemelijk gemaakt wordt dat een herkenbaar, maatschappelijk vraagstuk afdoende kan worden opgelost, op een bruikbare wijze, waar geld voor kan worden betaald en op een manier die ook daadwerkelijk gebruikt kan worden. Zo’n visie is bij uitstek pragmatisch, omdat slechts een visie die kan worden omgezet in een concreet object of werkwijze die aantoonbaar een vraagstuk oplost op een manier die begrepen en gebruikt wordt door een breder publiek ook een werkelijke innovatie is. Je kunt dus ook innovatief gebruik maken van iets dat eigenlijk uit de samenleving is op komen borrelen, maar nooit in een door jou bedachte vorm gebruikt is. Zo is nummerherkenning in telefonie al zo oud als de telefonie. Zonder die ‘handshake’ geen verbinding tussen twee punten. Er was alleen een schermpje nodig om de getallen ook te kunnen zien. SMS was een bijproduct van mobiele telefonie, maar werd op het schoolplein gebruikt om tikken uit te sparen en door slimme televisieproducenten innovatief ingezet om contact met het publiek te krijgen. Zo -beschouwd is i-Bridge een succesvolle visie op genetwerkt crisisbeheer gebleken en daarom ook wordt uitgegaan van die visie als startpunt voor de doelarchitectuur. I-Bridge is ontwikkeld vanuit de visie dat onze samenleving doordrenkt is van communicatiemiddelen en manieren om elektrische stroom te genereren. Men kan bij een calamiteit daarom beter leren combineren ‘wat het nog doet’, dan terugvallen op een gecentraliseerd, gestandaardiseerd en geharmoniseerd noodmiddel. I-Bridge gaat hiermee uit van veerkracht (resilience); niet van robuustheid. De ambitie hierbij is om met elegant gecombineerde informatie, een zo helder mogelijk situationeel bewustzijn inzicht te verwerven: optimaal inzicht, met minimale overlast. Vanuit die gedachte is i-Bridge over de jaren stapsgewijs ontwikkeld. De weg van ruw idee naar de opbouw van het benodigde sociale netwerk, naar het verkrijgen van politiek vertrouwen en financiële voedingsbodem geeft het beeld van de ‘innovatie ecologie’. Door vanuit een heldere visie pragmatisch de juiste mensen, beelden en middelen op te lijnen kon de interoperabiliteit ontstaan waarbij apparatuur, programmatuur en (sociale) infrastructuur van dezelfde en juist verschillende producenten, dankzij de beschikbaarheid van informatie over technische interfaces, op elkaar konden aansluiten en samenwerken. De gebruiksvriendelijkheid voor de – liefst ongetrainde – eindgebruiker is hierbij intuïtief gebleken. Over de jaren is zo een zowel robuuste als veerkrachtige omgeving ontstaan, die geen ‘centrum’ hoeft te kennen. Dankzij de inzet op peer-2-peer technieken is succesvol afgestapt van het kwetsbare
7
portalconcept. Ook als bij i-Bridge de stroom of de bandbreedte hapert, blijkt het individu door te kunnen werken en blijken delta’s naadloos gesynchroniseerd te kunnen worden.
Illustratie: de innovatie ecologie
3.2
Ketenpartners
In eerste instantie richt I-Bridge zich op de veiligheidsregio’s, brandweer, politie, Geneeskundige Hulporganisatie(s) en de Krijgsmacht in haar Derde Hoofdtaak, maar het kan evengoed actoren uit overheid, industrie en wetenschap op tal van manieren onderling helpen communiceren. Natuurlijk is IBridge een hub waar informatie kan worden samengebracht, verrijkt en verdeeld, maar met de samenwerking met de VPK Multi-Apps aangetoond is dat het platform kan samenwerken met andere hub typen. Dit geeft voedingsbodem om het traditionele hub/spoke model (centralisatie met lineaire ontsluiting van informatie) te vervangen voor een gefedereerd hub/node model, dat niet meer uitgaat van ‘ketens’, maar van een dynamisch ecosysteem.
3.3
Burgers
De ‘Burger’ wordt in I-Bridge geïdentificeerd en gefaciliteerd als individu (met bijvoorbeeld op de persoonlijke smartphone te gebruiken publieke Augmented Reality app bij evenementen) en geïnterpreteerd als groep (door bijvoorbeeld geanonomiseerde twitter feeds te correleren op een kaart).
3.4
Locatie
Voor de doelarchitectuur van I-Bridge wordt het concept locatie breed genomen: van een speciek punt op een kaart tot een Area of Interest (AOI) danwel een Area of Responsibility een (AOR). Door locatie zo te interpreteren is het platform multi-inzetbaar voor verschillende doeleinden.
3.5
Werkprocessen
De werkprocessen die I-Bridge ondersteunt hangen af van de constellatie van actoren waarmee gewerkt moet worden. In principe kunnen allerlei processen ondersteund worden. Soms zijn dit al bekende processen, soms vraagt een alternatieve combinatie van actoren om een alternatief werkproces. De essentie E-Bridge is dat een ‘proces’ geen in beton gegoten lopende band is. Traditioneel wordt Bedrijfsvoering (BV), Informatie Voorziening (IV) en Informatie Technologie (IT) lineair bekeken vanuit een functioneel en technisch ontwerp. Flexibel aanpasbare processen zijn hiervan het slachtoffer, omdat de IT te rigide wordt om de dynamiek van de BV bij te kunnen houden. Dat hoeft geen probleem te zijn in een statische en simpele wereld met weinig variabelen die bekend zijn en in de tijd niet tot weinig veranderen, zoals bij functioneel-hiërarchisch, top down aangestuurde actoren, zoals de traditionele zwaailichtdiensten waar vaste procedures leiden tot optimale inzet van schaarse middelen. Het wordt wel een probleem als de wereld zich niet meer gedraagt zoals
8
verwacht. I-Bridge is niet alleen bedoeld voor strikte procedures, maar ook voor Net centrisch optreden.In dat geval zijn niet alle variabelen bekend en maken die variabelen onder druk van de omstandigheden onvoorspelbare combinaties. Zo werken vandaag de dag bekent geachte organisaties met ingehuurde commerciële partijen die zelf weer werken met lokaal ingehuurde ZZP specialisten. De diversiteit die hieruit ontstaat, maakt dat vaste procedures ondersteund door inflexibele informatie voorziening niet meer werken, omdat de werkpopulatie niet langer homogeen geuniformeerd is. Er zal gewerkt moeten worden op basis van een intelligente dialoog tussen transparante objecten en actoren waarbij BV, IV en IT als samenhangend Systeem wordt bezien, onder een gemeenschappelijk businessmodel. Onderstaande model geeft die benadering weer. Onder een eenduidig concept hoe waarde wordt gegenereerd en betaald (het businessmodel), wordt de ‘know’ (hoe doe je dingen, proces), gescheiden van de ‘how’ (de dingen mogelijk te maken). In het dagelijks leven zijn belangen en perspectief van de bedrijfsvoering (de Brug) en de IT-technici (de Machinekamer) niet in balans. Wel in het model dat bij de I-Bridge ontwikkeling wordt gebruikt.
3.6
Principes
I-Bridge houdt zo goed mogelijk de overheid brede architectuurprincipes van de Nederlandse overheidsreferentie-architectuur (de NORA) aan binnen de praktische beperkingen van het programma als innovatie laboratorium voor niet-operationeel gebruik. De NORA kent de volgende basis principes: 3.6.1
De NORA basisprincipes
Proactief: afnemers krijgen de dienstverlening waar ze behoefte aan hebben. Het I-Bridge programma werkte altijd op basis van ‘best effort’ dienstverlening, met afnemers die actief betrokken waren bij de werking van de dienstverlening. De testpopulatie kreeg per PoC wat men in co-creatie verwachtte.
Vindbaar: afnemers kunnen de dienst eenvoudig vinden. Die NORA eis ging voor het I-Bridge programma niet op:
9
oefeningen werden met de gebruikersorganisatie van dat moment doorgesproken en het hing van de (veiligheid)situatie af hoe de backoffice bereikt kon worden.
Toegankelijk: afnemers hebben eenvoudig toegang tot de dienst.
Standaard: afnemers ervaren uniformiteit in de dienstverlening door het gebruik van standaardoplossingen.
Gebundeld: afnemers krijgen gerelateerde diensten gebundeld aangeboden.
Transparant: afnemers hebben inzage in voor hen relevante informatie.
Noodzakelijk: afnemers worden niet geconfronteerd met overbodige vragen.
Vertrouwelijk: afnemers kunnen erop vertrouwen dat informatie niet wordt misbruikt.
Betrouwbaar: afnemers kunnen vertrouwen dat de dienstverlener zich aan afspraken houdt
Ontvankelijk: afnemers kunnen input leveren over de dienstverlening.
En een aantal afgeleide principes:
3.6.2
Dienstenaanbod
De dienst is zodanig opgezet, dat anderen haar in principe kunnen hergebruiken. Hier is I-Bridge op gebouwd, maar feitelijk operationeel hergebruik was uitgesloten. De stappen uit het dienstverleningsproces zijn ontsloten als dienst. De dienst vult andere diensten aan en overlapt deze niet. De dienst is helder gepositioneerd in het dienstenaanbod; hierbij zij ‘dienst’ geïnterpreteerd als ‘specifiek te testen configuratie of functionaliteit’. De dienst is nauwkeurig beschreven: dit gebeurde bij I-Bridge vooraf, aangezien elk deelconcept eerst goed werd beschreven voor zij werd gerealiseerd, al vereist de weerbarstigheid van ‘wetten en praktische bezwaren’ dat het eindresultaat soms iets anders kon zijn gerealiseerd dan oorspronkelijk beschreven.
Met het specifieke doel van I-Bridge voor ogen, de onvoorspelbare Openbare Orde en Veiligheid omgeving waarin de ononderbroken zekerheid van elektriciteit en bandbreedte niet gegarandeerd kan worden, is een aantal aanvullende principes geformuleerd:
Het I-Bridge platform maakt informatie uitwisseling tussen organisaties mogelijk, op een manier die niet gebonden hoeft te zijn aan staande functioneel-hiërarchische verhoudingen. Het I-Bridge platform houdt de data structuur ook onder druk stabiel Alle beschikbare informatie is via web services doorzoekbaar Data importeer processen zijn XML-gebaseerd Het veiligheid model van I-Bridge is flexibel uitbreidbaar gehouden Het I-Bridge platform kan het zoeken dwars door organisaties mogelijk maken I-Bridge functionaliteiten laten zich APATAD en op locatie bedienen.
3.6.3
De dienst maakt gebruik van standaard oplossingen. De dienst maakt gebruik van de landelijke bouwstenen van de e-overheid, zoals PKI Overheid, Basis Registraties en open standaarden.
3.6.4
Standaard oplossingen
Kanalen
De dienst kan via internet worden aangevraagd; geïnterpreteerd als ‘via Internet ontsloten’. De dienst kan, behalve via internet, via minimaal één ander kanaal worden aangevraagd. (er is succesvol geëxperimenteerd met diverse frequenties en datadragers) Het resultaat van de dienst is gelijkwaardig, ongeacht het kanaal waarlangs de dienst wordt aangevraagd of geleverd.
10
3.6.5
De afnemers wordt niet naar al bekende informatie gevraagd. Alle gebruikte informatie-objecten kennen bronregistratie. Dit ging niet altijd op, omdat uit de aard van de zaak ook gewerkt moest worden met onzin-data die ‘in het echt’ nog niet bestond. De dienstverlener meldt twijfel aan de juistheid van informatie aan de bron. Het doel waarvoor informatie wordt (her)gebruikt is verenigbaar met het doel waarvoor deze is verzameld. Alle gebruikte informatie-objecten zijn uniek geïdentificeerd; waar mogelijk. Alle gebruike informatie-objecten zijn systematisch beschreven; waar mogelijk. De dienst ontsluit ruimtelijke informatie locatiegewijs
3.6.6
Sturing en verantwoordelijkheid
Eén organisatie is verantwoordelijk voor de dienst. Dienstverlener en de afnemer hebben afspraken over de levering van de dienst. De dienstverlener draagt de consequenties wanneer de dienst afwijkt van afspraken en standaarden. De wijze waarop de dienst geleverd is, kan worden verantwoord. De kwaliteit van de dienst wordt bestuurd op basis van cyclische terugkoppeling. Sturing op kwaliteit van dienst is verankerd op het hoogste niveau van de organisatie. De dienst voldoet aan de baseline kwaliteit. De dienstverlener legt verantwoording af over de mate van control, in overleg met de afnemers.
3.6.8
Vraaggerichtheid op een hoger plan
De dienst is opgezet vanuit het perspectief van de afnemer. De dienst benadert geïdentificeerde afnemers op persoonlijke wijze. De dienst is gebundeld met verwante diensten zodat deze samen met één aanvraag afgenomen kunnen worden. Per oefening werden specifieke functies samengesteld. Dat overheidsloketten gericht naar de dienst doorverwijzen ging bij I-Bridge niet op. De dienst wordt na bepaalde signalen automatisch geleverd. De dienst ondersteunt proactiviteit van dienstverleners binnen en buiten de organisatie. De afnemer wordt geïnformeerd over de stand van zaken bij de gevraagde dienst. De afnemer heeft inzage in de eigen informatie en het gebruik ervan.
3.6.7
Informatie
Betrouwbaarheid
De levering van de dienst is continu gewaarborgd. Wanneer de levering van de dienst mislukt, wordt de uitgangssituatie hersteld. Dienstverlener en afnemer zijn geauthenticeerd wanneer de dienst een vertrouwelijk karakter heeft. De betrokken faciliteiten zijn gescheiden in zones. De betrokken systemen controleren informatie-objecten op juistheid, volledigheid en tijdigheid. De berichtenuitwisseling is onweerlegbaar; binnen I-Bridge is soms geavanceerder beveiliging gebruikt die verder gaat dan de standaard beveiliging middelen van de Rijksoverheid.
3.6.9
Ontwerpeisen
De verschillende overwegingen en randvoorwaarden leidden een groeiend inzicht in ontwerpeisen, die gedurende de diverse stadia waarin I-Bridge evolueerde in meer of mindere mate konden worden uitgewerkt. Niet vergeten mag worden dat I-Bridge een cyclisch innovatieproject is, dat itteratief is gegroeid op basis van imagineering principes: learning by doing. De traditionele benadering van functioneel ontwerp naar technisch ontwerp ging hier niet op. Vraagstukken werden probleemcentrisch en niet product centrisch uitgewerkt, wat leidde tot een mix van peer-to-peer interacties binnen bestaande werkprocessen door de combinatie van traditionele bedrijfsprocessen en samenwerking met behulp van sociale media technologie. I-Bridge moet in staat zijn tot organisatie-vrije informatiedeling: geen muren meer. Integraal behoud van de data structuur op basis van object-relatie-attribuut data Integrale zoekfunctie Notificatie en alarmeringen binnen grenzen zelfstandig instelbaar
11
Integraal rapportage en analyse raamwerk XML-gebaseerd data importeer process op basis van de Web Ontologie taal OWL. OWL beschrijft de context van de gebruiker, zijn locatie en de context van de datastromen. OWL is sinds 2004 in gebruik en is erkend en aanbevolen door het W3C: het instituut dat allerlei Web standaarden analyseert en beschrijft. OWL kan zowel op mensen- als op doel gerichte apps aansturen; maakt filtering en het prioriseren van mogelijkheden voor de gebruiker mogelijk. Ook externe sensor informatie wordt automatisch geïntegreerd. GIS web dienst op basis van open standaarden Uitbreidbaar beveiligingsmodel Zoeken over organisaties heen Ingericht op Bring Your Own Device (BYOD), Bring Your Own Network (BYON) en Any Place, Any Time, Any Device (APATAD) gebruik. Policy-gebaseerde zichtbaarheid en controle over applicaties, gebruikers en content voor alle dataverkeer. Applicaties kunnen identificeren ongeacht hun port, protocol, pogingen om zich onzichtbaar te maken of SSL Gebruikers kunnen identificeren ongeacht hun IP adres Verfijnde zichtbaarheid en policy controle over alle toegang tot applicaties en de aangevraagde functionaliteit Real-time bescherming tegen dreiging ingebakken in alle applicaties Traploos schaalbaar zonder performance verlies Elk afzonderlijke data pakketje in één controleren op: - dataverkeer classificatie (applicatie identificatie) – WAT wordt opgevraagd? - gebruiker/groep mapping - DOOR WIE wordt iets opgevraagd? - content scanning – dreigingen, URLs, vertrouwelijke data Dit alles onder één I-BRIDGE breed beleid Het transport van gevoelige gegevens in data en bestanden moet uiteindelijk op type kunnen worden gestopt. (dit stelt zowel aparte eisen aan de data als aan de apparatuur en viel buiten de mogelijkheden van het programma, al is bekend hoe het zou moeten). Applicaties moeten op termijn op data niveau herkend gaan worden, bijvoorbeeld door de inzet van context gevoelige firewalls die data op packet niveau sniffen. Applicaties worden gebouwd om er toegang toe te krijgen. Er is beveiliging om die toegang te reguleren. Er zijn echter steeds meer manieren om beveiliging te omzeilen, zoals gegevens naar jezelf emailen, messaging via sociale media, web apps, BYOD, p2p en browser based file-sharing, dropbox etc. Traditionele oplossingen zoals firewalls kunnen hier niet mee om gaan. Poorten zijn niet hetzelfde als applicaties. IP adressen staan niet gelijk aan gebruikers. Datapakketjes zijn niet hetzelfde als content. Applicaties dragen risico’s in zich: business continuïteit, data lekkage, compliance, audit eisen, productiviteitverlies en operationele kosten. Je moet pakketsniffing dus echt in je generieke basisinfrastructuur inbouwen, om integraal de gemaakte afspraken ook te kunnen monitoren en garanderen.
Meer kennis van applicaties en hun gebruik, zorgt dat je veel eenvoudiger performance kunt garanderen door de inzet van traffic shaping technieken (gegarandeerde bandbreedte, priority dataverkeer, maximum toekenning). Met fijnmazig inzicht kun je het verkeer afstemmen op applicatie, gebruikers, bron, bestemming, IPSec VPN tunnel etc.
Daardoor ook veel meer inzicht in het daadwerkelijk gebruik en de kosten per applicatie en daarmee kun je SLA’s veel strakker monitoren; je kunt bepaalde applicaties (op bepaalde tijden of voor bepaalde (groepen) medewerker(s) blokkeren of alleen op bepaalde tijden toestaan. Voorbeeld zorgsoftware tijdens werkuren.
Door gebruikers niet alleen op IP adres te monitoren, kun je meer waarde halen uit de bestaande LDAP/Active Directory infrastructuur door bv Citrix gebruikers te herkennen en te koppelen aan specifieke regels op de gebruiker(sgroep).
Intuitief en flexibel management
12
Rol-gebaseerde administratie maakt delegeren tot op de individuele persoon mogelijk
Panorama centrale management applicatie (integraal overzicht op de organisatie)
Organisatiebreed + digitaal afdwingbaar beleid tbv consistente applicatie controle Alle interfaces zijn altijd ‘bij’ voor wat betreft configuratie; geen synch verschillen
3.6.10 Argumenten
De business van I-BRIDGE is ad hoc en slecht planbaar, waardoor de traditionele schedule push benadering niet langer de druk van reality pull eisen kan weerstaan. De OOV gebruikt geen product meer, maar een muterende informatieverzameling. De arena waarin I-BRIDGE opereert laat zich niet sturen en is zelf ook in flux. Het heeft daarom geen zin om strakke afspraken te maken en in beton te gieten. Veel zinniger is strategisch te kiezen voor ingebouwde flexibiliteit obv middleware. De kosten van flexibiliteit moeten worden afgezet tegen de omstelkosten – de kosten om achteraf (delen van) systemen aan te passen aan (onverwacht) veranderde omstandigheden. Door I-BRIDGE te zien als container voor verschillende deelgemeenschappen, ontstaat een basis voor gecoördineerde besluitvorming en gerichte alarmering van functionarissen. Cross Domain Sharing by design: niet de organisatie in beton gieten, maar zorgen dat gegevens over organisatorische grenzen kan stromen, maar wel beschermd tegen ongeautoriseerde toegang. Collaboratie tools (zoals Sharepoint, Team Room…) zijn als push mechanismen ideaal voor de ontsluiting van de grote verzamelingen ongestructureerde informatie die een logisch gevolg zijn van sociale dynamiek die ontstaat als mensen vrijer samenwerken in I-BRIDGE ’s interne sociale netwerk: een abonnee model waar geautoriseerde medewerkers zich bij aan kunnen sluiten om informatie te delen. Collaboratie tooling maakt dat content management en sociale netwerk software zich vermengt. Door de wens om Any Place, Any Time, Any Device data ontsluiting zal data organisch vermengen. Het hoofdstuk veiligheid toont aan dat een volgende generatie I-Bridge daarom zou moeten kiezen voor een gefedereerd veiligheid model. Zorg dat gegevens grafisch en in verschillende combinaties kunnen worden weergegeven: dat dwingt tot flexibiliteit en transparantie informatie huishouding en vereenvoudigt het komen tot betekenisvolle informatie op basis waarvan operationele besluiten kunnen worden genomen. Controle door de individuele gebruiker, binnen de grenzen van zijn rol Door uit te gaan van een claim gebaseerd model hoeft niet gekozen te worden voor een specifieke definitie van identiteit. Dit levert een relatief goedkoop, maar veilig model op. Transparant, maar veilig en met respect voor context Op toegang en accuratesse gerichte verzameling van gegevens Verantwoording toekenning Door helderder te hebben uit welke onderdelen het business proces bestaat zijn kleinere bedragen effectiever in te zetten door kleine modules te kopen. Met data-re-integratie strategie zijn, om verrijkte data terug te voeren naar de systemen. Gebruik maken van bestaande claim uitwisseling standaarden zoals OASIS.
3.6.11 Bouwstenen I-Bridge is opgebouwd uit Commercial-of-the-Shelve software pakketten en herbruikt configuraties zoveel mogelijk voor de diverse deelprojecten cloud computing, ad-hoc (data) infrastructuur, secure collaboratie met behulp van PKI Overheid, crowd sourcing, intelligentie in kaartlagen, gebruik van sensoren/plaatsbepaling in crisissituaties en Augmented Reality. De samenwerking met het afzonderlijk gehoste Virtueel Politie Korps maakt nog meer combinaties mogelijk waarbij dezelfde bouwstenen kunnen worden (her)gebruikt. Onderstaande illustratie toont in abstractie de verschillende invalshoeken die in een uitgewerkte ideaaltypische SOLL architectuur terug zouden moeten komen. Zouden moeten, want gezien het experimentele karakter van I-Bridge zijn in de test omgeving lang niet al deze factoren operationeel geweest of zelfs maar gerealiseerd. Er zijn bijvoorbeeld voor het deel ‘Enterprise Service Bus’ verkennende gesprekken geweest met de Overheidsservicebus (OSB), maar dat heeft niet geleid tot concrete opvolging. De reden hiervan lag in tekort aan menskracht en een focus op demonstrators voor oefeningen. Binnen het I-Bridge programma is wel kennis genomen van de mogelijkheden. Er is concrete ervaring opgedaan met de Gemeenschappelijke ontsluiting
13
basisregistraties (GOB), wat onder meer geleid heeft tot BAG ontsluiting op de geo-faciliteit van 1 i-Bridge . Verder zijn over de jaren diverse combinaties met Basis Registraties aan de orde geweest en in sommige oefeningen ook echt of gesimuleerd ingezet.
3.7
Fundamenten voor realisatie Het Nederlands recht is van toepassing, waarbij ervan is uitgegaan dat data het grondgebied van het Koninkrijk der Nederlanden niet verlaat. Dit lijkt triviaal maar bepaalt voor een belangrijk deel de gedachtenlijn of en welke data ook vanuit de overheidsvrije sfeer betrokken kan worden. (de 2 ‘echte’ publieke cloud, zoals crisismaps.com) I-Bridge is zelf zo ‘leeg’ mogelijk gehouden: er is zo min mogelijk data centraal opgeslagen. Dit ‘travel light’ principe is kenmerkend voor i-Bridge , dat ten slotte bedoeld is voor crisismanagement en in een crisis is bandbreedte een onbetrouwbaar en schaars goed. Het verklaart ook de keuze voor Microsoft Groove, dat een synchronisatie middel is en geen content management systeem en niet bedoeld is voor zeer grote aantallen gebruikers. De inzet van Groove werkte uitstekend om Any Place, Any Time, Any Device te leren ‘denken’ om bij alle keuzes uit te gaan van minimalisering van de netwerkbelasting. I-Bridge wordt zo veel mogelijk gevoed met basisgegevens vanuit externe bronnen. Hierbij geldt een voorkeur voor Basis/Kern Registraties en Open Data bronnen. Er is niet gekozen voor de ene bron boven de andere: die keus is aan de gebruiker gelaten.
1
De Basis Registraties betreft de Gemeentelijke Basisregistratie Personen (GBA), de Registratie Niet Ingezetenen (RNI), het Nieuw Handelsregister (NHR), de Basisregistraties Adressen en Gebouwen (BAG), Topografie, Kadaster en de Basisregistratie Grootschalige Topografie (BGT ook bekend als Grootschalige Basiskaart Nederland (GBKN). Hiervan zijn alleen de BGT en de BAG concreet getest. 2
De Nederlandse vertaling van de vooral Engelstalige literatuur rond cloud computing leidt tot verwarring. Het Engelstalige ‘Public/Private’ is niet gelijk aan het Nederlandse ‘Publiek/Privaat’. Hier slordig mee om gaan heeft juridische consequenties voor oa aansprakelijkheid en heeft in het kader van de cloud discussie onder andere te maken met bewaartermijnen van data en dataportabiliteit verzekering. Het feit dat een overheid data in een ‘niet-overheid cloud’ op zou staan, ontslaat haar niet van aansprakelijkheid. In I-Bridge is data daarom nergens anders opgeslagen dan op gecontroleerde omgevingen en is hooguit data van buiten betrokken om bij te dragen aan verrijking van data die al beschikbaar was, maar nooit andersom.
14
Te ontginnen databronnen kunnen zowel van overheden, NGO’s als commerciële partijen zijn. I-Bridge past zich niet aan één beveiligingsbeleid aan, maar harmoniseert beveiligingseisen. I-Bridge ondersteunt de collaboratieve implementatie van federatieve beveiliging ontwikkelingen en werkt in principe toe naar Level of Authentication (LoA) 3 en 4 federatie (end-to-end beveiliging), zo actueel mogelijke ID Proofing & Verification (IPV), Privacy en Device Authenticatie, maar die ambitie was binnen de grenzen van het programma onhaalbaar. Er is kennis opgedaan van de Europese ontwikkelingen rond en implicaties van (zich ontwikkelende) standaarden als ITU-T/ISO 24760/29115, het Kantara Initiative Identity Assurance Framework, Pancras anti-fraude, Supply chain collaboratie ontwikkelingen zoals het Transglobal Secure Collaboration Programme (TSCP.org) en de Architecture for the Secure Identification of Natural Persons (ASINP).
Beveiliging in I-Bridge voornamelijk de uitdaging van organisatorische en technische diversiteit. Hierbij stellen zowel de IST situatie als de SOLL situatie hun beveiligingseisen. De IST situatie in de zin dat het I-Bridge platform binnen een staande Defensie organisatie met strikte procedures wordt gehost. De SOLL situatie in de zin dat I-Bridge testen uitvoert met de nieuwe beveiligingsvormen die een noodzakelijke voorwaarde vormen voor netcentrische samenwerking. Voor elke PoC zijn langs officiële weg de benodigde waivers verkregen.
3.8
Nederlandse overheid
I-Bridge is in principe bedoeld als ad-hoc collaboratief platform van en voor de Nederlandse Overheid. Hieruit volgt dat politieke en juridische ontwikkelingen binnen de Staat leidend zijn voor de Visie uitwerking. Denk hierbij aan ontwikkelingen als het Nationaal Uitvoeringsprogramma Dienstverlening en E-Overheid (NUB), waar een eventueel operationeel te maken I-Bridge toch aan zou moeten voldoen. Denk aan de ontwikkelingen in het gedachtengoed en de politieke realiteit in IGO en NEC: IBridge moet aanhaken bij de terminologie en de standaarden van de beoogde eindgebruikers. Dit heeft er tijdens PoCs in de civiel-militaire context bijvoorbeeld toe geleid dat militaire eisen en communicatieprotocollen in een oefening doorgaans leidend waren. Bij het doordenken van deelconcepten werd steeds gedacht vanuit de Nederlandse context, met Nederlandse contactpersonen, afstanden die zich beperkten tot Nederland, keuze voor de Nederlandse taal en waar mogelijk keuze voor Nederlandse technologie.
15
4.
4.1
Eisen aan de Doelarchitectuur (IST)
Organisatie componenten (Wie)
Het I-Bridge platform is een context broker; een data syndicalist die vraag en aanbod van informatie combineert. Het platform is doordacht om content en context te kunnen bieden aan de gehele veiligheidcyclus:
Detecteren: toon mij alle … o kinderdagopvanghuizen in het overstromingsgebied o bejaardenhuizen en scholen in het effectgebied van een gaswolk o kwetsbare objecten bij een pijplijn o ‘verticals’ die kwetsbaar zijn voor een gelijksoortige dreiging (vb alle varkensboerderijen) Voorkomen o Rampenplannen Voorbereiden o Evacuatie plannen o Aanvals plan o Samenwerking oefeningen o “Black Swan” scenario’s waarin het onvoorstelbare als opgave gesteld wordt o Een “Zen” benadering op crisisbeheersing: bewust, maar niet gefocussed o Ultra responsief – maar geen “tunnelvisie”, inzetten op het behouden van optimale flexibiliteit. o Ingebouwde “ad-lib” en improvisatie: ook last minute input moet plaats en begrip kunnen krijgen o Uitgaan van decentralisatie van energievoorziening en data bronnen (geen hub spoke meer) o Ingesteld op het faciliteren van een flexibele infrastructuur, bv met het webportaal. Reageren o Contacten, expert bronnen o Bouwplannen, inventaris lijsten o Kwetsbare populaties o Locaties die als schuilplaats zouden kunnen dienen o Think Global – Act Local o Zoveel mogelijk gebruik van lokaal opgeslagen data, waar mogelijk (peer2peer) o Liever “inclusief”zijn dan “exclusief” (I-Bridge Viewer en de Telestick) o Delen o Leren o Terugkoppelmomenten faciliteren: niet zenden, maar verrijken. Herstellen o Prioriteiten o Onderlinge afhankelijkheden Register citizens o People Finder Identification File (PFIF) tbv registratie vermisten/gevonden mensen en objecten o Triage o Voorraad overzichten o Voorkomen van overreacties
De organisatie splitst hiermee in vier elementen uit:
De ‘voorkant’ van de organisatie stelt de vraag wat er moet gebeuren?Wat is het probleem? Hierbij probeert het I-Bridge team zelfstandig om op basis van maatschappelijke trends concrete maatschappelijke vraagstukken te identificeren die te kenschetsen zijn als ‘bottleneck’. Een bottleneck staat voor een probleem, waarvan mag worden aangenomen dat het oplossen van dat vraagstuk zal leiden tot een breed pallet aan nieuwe mogelijkheden. Bijvoorbeeld:“Als klimaat verandering leidt tot langduriger droogte, dan is het risico op natuurbranden verhoogd. Als daarbij de bezuinigingen leiden tot de situatie dat meer gedaan zal moeten worden, met minder mensen en dat hierdoor minder tijd over zal zijn om op noodsituaties te reageren, dan moet er een
16
businesscase zijn om met automatisering natuurbranden te kunnen voorspellen, feitelijke branden eerder te onderkennen en beschikbare assets efficiënter en effectiever ter plaatste te krijgen”. De bottleneck in dit vraagstuk bleek de beperkte dekking van de radioverbindingen te zijn. De bottleneck innovatie die het probleem oploste was het MANET ad-hoc radio netwerk. Met het communicatieprobleem uit de weg, was de weg vrij voor de inzet van andere I-Bridge deelprojecten als het natuurbrand bestrijdingsmodel en de intelligente kaart, maar ook de Augmented Reality apps konden nu in principe breder worden ingezet.
Het 2e deel van de organisatie vraagt: wat is het belang van de oplossing en wie ziet dat? Hierbij is binnen het sociale netwerk van het I-Bridge team aansluiting gezocht bij (potentiële) stakeholders en op basis van hun jargon, budget, politieke en oefenagenda de vraagkant actief georganiseerd. Inzet van juridische kennis, recente Kamervragen, media actualiteit, oefenagenda’s (schaarste aan resources) en de ambities van individuelen speelt in deze fase een belangrijke rol om de raison d’etre van de gepercipieerde oplossing te rechtvaardigen.
Het 3e deel van de organisatie, de ontwikkelaars, vraagt vervolgens welke informatie nodig en voor handen is. Het antwoord op deze vraag leidt het team naar databronnen en datavormen, met hun specifieke techno-juridische consequenties.
Het 4 deel van de organisatie, de beheerders, vragen welke tooling, hoe moet worden ingezet. Hierbij worden alternatieve configuraties op dezelfde software en nieuwe combinaties tussen software uitgedacht, uitgewerkt en op hun merites getest.
e
Onderstaande figuur is een visuele representatie van bovenstaande tekst en positioneert I-Bridge als ‘hub’, als informatie marktplaats, in het hart van het business proces management concept.
4.2
Bouwstenen (Wat)
De bouwstenen waar I-Bridge uit bestaat zijn grotendeels ingericht op (ad-hoc) collaboratie. Samenwerking kan verbaal, visueel en tekstueel plaats vinden. Daartoe zijn software componenten verkrijgbaar, die ook zaken als ‘aanwezigheid’/presence en andere status informatie tonen. Om goed te kunnen samenwerken, is ook toegang tot processen en documenten (met document management) noodzakelijk. Het totaal is een pallet aan middelen die in de afgelopen I-Bridge versies in verschillende combinaties succesvol, maar nooit zo compleet als hieronder geïllustreerd, zijn gecombineerd. De volgende bouwstenen worden onderscheiden in drie categorieën:
Werkvormen: ad hoc communicatie, proces gedreven samenwerking en content centrische samenwerking.
17
4.3
Diensten: unified communications, community (enterprise) breed sociaal netwerken, collaboratie tools, content/document management, intranetten, portals en website (waaronder de I-Bridge Viewer), workflow/Business Proces Management en Business Intelligence. Inzetmogelijkheden, want samen zijn de diensten en werkvormen in te zetten voor: presence awareness, co-creatie en peer productie (denk aan Surphase tafel interfaces), interactie en discussie, workflow samenwerking, het delen en/of verfijnen van informatievormen, het ontsluiten van locatie kennis, het behouden van kennis, informatie management, gebruikers educatie, het managen van activiteitenstromen en analyse/inlichtingen.
Werkprocessen (Hoe)
Werkprocessen zijn hier bedoeld als de werkprocessen die bijdragen aan het opbouwen, in stand houden en uitbreiden van het I-Bridge platform vanuit een platte en informele structuur. Hier zijn de volgende stappen gevolgd om tot een coherente deel project definiëring te komen.
18
Het I-Bridge team borgt vervolgens de verkregen inzichten met de volgende Systeembenadering:
De hechte samenwerking tussen de teamleden borgt de kennis vooral door dialoog. Geadviseerd wordt om bij opschaling de werkwijze te faciliteren met full service Business Process Management Modelering (BPMM) software om deze complexe materie in de hand te houden. Wat hierbij ook zou helpen is vanaf het begin aan uitgaan van object georienteerd ontwerpen en inrichten op end2end veilige gefedereerde identiteit management. Ook in programmeren wordt steeds meer in objecten gedacht als kleinste gemene deler van informatie en er bestaan robuuste programmeerconcepten voor, zoals OBEX. Voor I-Bridge 3.0 is nog geen gebruik gemaakt van OBEX, maar het is wel een aanbeveling voor volgende generaties. Er is wel gebruik gemaakt van Microsoft C#, eveneens een Object Oriented Programmeer taal.
19
Bij object-georiënteerd programmeren (OOP), zijn objecten die zaken waar het eerst aan gedacht wordt als een programma geschreven wordt. Het zijn ook de code blokjes die uiteindelijk uit dat programmering proces kunnen worden afgeleid. De verhouding tussen die objecten wordt verkregen door elk object onder te brengen in een specifieke klasse. Door generieke klassen te definiëren kunnen object ’families’ worden ondergebracht in modellen, waar binnen de klasse definities van de code objecten kunnen worden hergebruikt. Dit maakt elk object een functie van een specifieke klasse, of van een subklasse binnen een familie van generieke methodes en procedures. Een informatie-object wordt hiermee een cluster van gegevens die bepaalde eigenschappen bezit. Een familie kan bijvoorbeeld zijn ‘wetgeving’. Andere informatie zal een andere classificatie hebben. Het is dit objectmodel waaromheen het datamodel gebouwd is, waaromheen het content management gebouwd is, waaromheen de applicaties gebouwd zijn, waaromheen de reken- en opslagkracht gebouwd is, waaromheen uiteindelijk het hele fysieke datacentrum ontwerp gebouwd is. De keuzes die hier gemaakt worden, kosten of besparen belastinggeld. Grofweg zijn er slechts drie tabellen in het Object georiënteerde data model: Entiteiten (dingen, objecten) Attributen (eigenschappen) Relaties (tussen entiteiten) Uiteindelijk was de ambitie te komen tot een I-Bridge ecosysteem dat federatief is opgebouwd. Hierbij wordt geen mens, geen machine, geen organisatie, geen proces en geen softwaremodule nog zomaar vertrouwd, maar hooguit de tijdelijke wiskundig verzekerde checks&balances in de trust relatie daartussen. Tegen die tijd omvat de te creëren omgeving een eenduidig beeld van: Organisatie Organisatieonderdeel (budgethouder) Personen Autorisatie-levels Locaties Apparatuur (waarschijnlijk nader te definiëren in sub-classificaties als servers, werkstations, switches, routers) Computerruimtes of patchkasten Netwerk Interfaces (NICs) Ip-nummers Tokens Licenties SLA Data communicatie lijnen Leveranciers Verwerving codes Cases (support - of storing incidenten) Etc. etc. Entiteiten hebben generieke kenmerken als bijv. datum aanschaf/ingebruikname en buitengebruikstelling etc.) Bij elk van de entiteiten zijn een aantal duidelijke eigenschappen (attributen) te bedenken, maar bij het migreren van de legacy data uit de nu operationele systemen zijn die attributen al aan te vullen met de reeds bekende en gebruikte benamingen en overige relevante informatie. (bed – type, maatvoering, speciale aspecten - ….) Vervolgens worden de entiteiten logisch gekoppeld via linktypes (gebruiker van, gekoppeld aan, op budget van etc.). Anders dan bij het klassieke data model is hier geen complexe data structuur met bijbehorende normalisatieslagen van toepassing. Bestaande tabellen zijn zoveel mogelijk herbruikbaar. Zo bouwt het inzicht zich op naarmate het systeem verder gevuld wordt. Boven alles voorkomt deze werkwijze een uitputtende standaardisatie discussie tussen de huidige datamodellen: alle input is goed. Vervolgens bouwen we weer op tot geïntegreerde IV. De voorgestelde methode van het indikken van data tot objecten, attributen en relaties, levert de grondstof waarmee data vervolgens eenvoudiger in real time geabstraheerd en gedistribueerd kan worden naar de juiste instanties en personen, voor gebruik binnen de juiste juridisch-organisatorische context. Uitgaande van dit conceptueel datamodel is een roadmap uit te zetten, die de infrastructuur (I-BRIDGE ), geïnterpreteerd volgens Informatie Gestuurd Optreden (IGO), binnen de lijnen van
20
content en informatie management (ECM/EIM), zou kunnen ontsluiten via (een variant op) De Rijks Werkplek (DWR) in enkele, concrete, inherent stabiele stappen mogelijk maakt. Het I-Bridge team is gekomen tot een structuur waarin deelprojecten in samenhang zijn gebracht.
21
4.5
Ontwerpregels (design rules en ontwerpscenario’s)
De richtingen en verplichtingen die gesteld moeten worden aan de toekomstige I-BRIDGE gebruik infrastructuur zijn ingedeeld naar vier onderling afhankelijke en elkaar versterkende componenten in de architectuur: stevige en coherente beleidskeuzes (visie) (technologie) richtlijnen die de waarde propositie mogelijk maken het business model dat de waardeketen en de beoogde relaties tussen de betrokken actoren in termen van toegevoegde waarde helder stelt en een doordachte marktbenadering waaruit de perceptie op het gekozen marktsegment eenduidig wordt gesteld. (lopende ben of klant is koning?) De wijze waarop de markt wordt bezien en daaruit volgend de manier waarop de productie is ingericht, heeft drastische gevolgen voor de wijze waarop de organisatie is ingericht en heeft daarmee invloed op de wijze waarop I-Bridge als Systeem moet worden ontworpen. Juist het feit dat in de legacy organisatie marktpercepties (voor zover bewust aanwezig) niet in hun consequentie zijn doorgevoerd en door elkaar bestaan is een van de oorzaken van de huidige verwarring die in de organisatie wel is opgemerkt, maar niet wordt verklaard. Een noodzakelijke voorwaarde om altijd en overal, veilige, geautoriseerde toegang tot de juiste en volledige informatie, nodig voor een doeltreffend functioneren bij onvoorspelbaarheid te kunnen bieden is het creëren van vertrouwen (trust) en niet op basis van functioneel-hiërarchische handtekeningen, maar op Systeem niveau. Er zijn de volgende principes te destilleren: In plaats van harde eisen te gaan stellen aan de ketenpartners, gaat I-BRIDGE zelf de verloopstekker leveren door te kiezen voor flexibele middleware die om kan gaan met markt- en standaardfluctuaties. Dezelfde groep gegevens moet modulair gecombineerd en ter beschikking gesteld kunnen worden voor verschillende doeleinden en doelgroepen. Hiervoor worden de volgende ontwerpprincipes voorgesteld, die vervolgens moeten worden vertaald in producten/diensten, processen, organisatie, gegevens, applicaties en technische infrastructuur. Uiteindelijk moet de I-Bridge alle voorzieningen beheersen om informatie door middel van communicatie en informatie integratie te verwerken, te delen, te presenteren, te beveiligen en het geheel te beheren. Open Standaarden Het Systeem moet voor alle betrokken entiteiten qua logica transparant zijn. Dit betekent dat de software code intrinsiek bekend moet zijn op bit niveau. Hiervoor zijn tools in de markt die precies kunnen laten zien hoeveel code nodig is om tot een 3 functie te komen . Bijkomend voordeel van deze benadering is dat Dynamic Whitelisting, het dynamisch bijhouden van de integriteit van de data, een belangrijke bescherming is tegen digitale inbreuk als malware wat weer precies past in de cyberambities van het Rijk. Data integriteit is noodzakelijk voor de wederzijds transparante SLA’s die je met diverse gebruikerspopulatie nodig hebt Interoperabiliteit De data zouden over meer bruggen bereikbaar moeten zijn en achter minder muren moeten liggen om kruisbestuiving tussen de verschillende gebruiker gemeenschappen mogelijk te maken. Om dit mogelijk te maken moeten online samenwerkingsverbanden in staat worden gesteld om zich onder voorwaarden open te kunnen stellen naar elkaar. Hiertoe is interoperabiliteit tussen de verschillende omgevingen en het opzet van ontologische raamwerken noodzakelijk. Ook om het kunnen voldoen aan compliancy wetten, voorschriften (SOX, HIPAA, EU data Directieven, etc.) en beleidsafspraken. 4 Zo vereisten ministeries steeds meer zekerstelling dat IAM, Security, Privacy en Data Management processen draaien als verwacht mag worden, willen service providers zekerheid dat
Overigens zit hier dan al een besparingskans in, want teveel onnodige data is ook teveel onnodig datatransport, teveel rekenkracht, teveel onderhoud kosten etc. 4 Privacyregels raken alle bedrijven en overheidsorganisaties in hun bedrijfsvoering, omdat beiden klantgegevens en personeelsinformatie verwerken: lokaal of in de (private) cloud. 3
22
hun diensten integer en stabiel draaien en willen eindgebruikers zekerstelling rond Privacy, Data controle, etc. Inclusiviteit Hoe meer mensen met het beoogde Systeem werken, hoe efficiënter en effectiever het wordt, mits die mensen vrijelijk onderling kunnen communiceren binnen de noodzakelijke grenzen. Het zou dus zo moeten zijn dat iemand die aan de standaarden en principes voldoet mee moet kunnen doen. Laagdrempelige opt-in, opt-out. De infrastructuur die zoiets mogelijk maakt is daarom waarde-neutraal, open en inclusief over open internet protocollen. Respect voor Privacy Online privacy bescherming is een noodzakelijke voorwaarde voor een levendige ‘ civil society’: het discours waarbinnen probleemoplossend vermogen wordt gegarandeerd – de user generated productivity. Dit betekent dat iedere gebruiker er zeker van moet kunnen zijn dat zijn gegevens privé blijven, behoudens inzichten door logische partijen die ook bekend mogen worden verondersteld. Decentralisatie Zelf oplossend vermogen werkt het best wanneer systemen niet via een top down commando structuur worden aangestuurd, maar ‘bottom up’ op kunnen borrelen. De gedachte is daarom een marktplaats omgeving, de hub, waarin partijen informatie kunnen halen en brengen. Net als marktplaats (wie ben je, wat heb je gekocht en heb je betaald) is door deze design rule op basis van eenvoudige uitgangspunten een complex systeem te bouwen. Zo kun je dus op modulaire wijze ‘ grow as you go’ toepassen. i Gezien de relatieve nieuwheid van de concepten worden ze nader toegelicht in de bijlage .
5.
De informatie architectuur (IST)
5.1
Informatie architectuur uitgangspunten
Met het positioneren van I-Bridge als syndicalisatieplatform is uitgegaan van het kunnen combineren van allerlei soorten informatie. De informatie architectuur is daarom afgestemd op:
Transparantie Door data te zien als grondstof en niet als product, is veel aandacht besteed aan de reden ‘waarom’ data ergens gebruikt moet worden. Zo is toegewerkt naar een platform dat goed op bedrijfsvoering aspecten laat sturen, wat uiteindelijk moet leiden tot een flexibeler, efficiënter en effectiever gebruik van schaarse mensen en middelen.
Veiligheid De transparantie maakt niet alleen een zeer fijnmazige beveiliging mogelijk op basis van Federatieve Identiteit Management (zie het hoofdstuk Veiligheid) en is daarmee robuuster dan een traditionele aanpak. Zij is ook veerkrachtiger (resilient), omdat eenvoudiger over geschakeld kan worden naar IT alternatieven zonder verlies aan controle over de data.
Eenvoud De complexiteit vermindering die voortvloeit uit het voorgestelde object-relatie-attribuut gebaseerde datamodel maakt IT beheer, communicatie beheer en administratie veel eenvoudiger. Door het toegenomen gemak kunnen veel dedicated systemen worden vermeden, wat kapitaal scheelt in machines, beheer, onderhoud, energie, verzekering en software kosten.
Al die data doet een enorm beroep op de vereiste rekenkracht en traploze schaalbaarheid van de applicaties. Traploos flexibele schaalbaarheid is een kenmerk van cloud computing en daarom de aandacht voor cloud computing in I-Bridge 3.0. Clouds vragen om self-provisioning, gebruiker gebaseerde accounting, multi-tenancy (medehuurders), toegang tot API’s (Application Programming Interface) en andere cloud-specifieke attributen dat van invloed is op het te kiezen data model.
23
5.2
Gebruikers applicaties (Wie)
Over de jaren is een breed portfolio aan tijdelijke gebruikersapplicaties gegenereerd. Van een interface en proces voor het Nationaal Pokkendraaiboek (vaccinatie- en gezinshereniging) tot geavanceerde Geo Informatie Systeem analyse. In alle geval was het uitgangspunt of de Proof of Concept de confrontatie met de ongetrainde eindgebruiker overleeft in real life situaties en of de potentie gehaald zou kunnen worden om een dergelijke gebruikersapplicatie desgewenst op te schalen naar een robuust, landelijk uitrolbaar crisismanagement systeem dat in alle veiligheidsregio’s kan worden ingezet.
5.3
Informatie uitwisseling (Hoe)
De informatie uitwisseling op en met I-Bridge gaat uit van een aantal randvoorwaarden:
Er wordt gewerkt met functionele commando lijnen Overhead moet worden voorkomen: elke schakel moet een toegevoegde waarde hebben. Een architectuur principe dat zich onder meer uit door de voorkeur voor Kern registraties.
Geverifieerde informatie Met een goed integraal datamodel is eenvoudiger onderscheid te maken tussen feiten en aannames, zodat besluitvorming plaats kan vinden op basis van geverifieerde feiten.
Duidelijke opdrachten Een goed datamodel kan bijdragen dat opdrachten begrepen en uitvoerbaar zijn en dat de besluitvorming zich ook door feedbackloops kan bijstellen. Dit kan betekenen dat verrijkte data moet kunnen worden terug geplaatst in de databanken achter de applicaties en stelt daarmee eisen aan de structuur.
Duidelijk communicatie Met de doorbraak van trends als Bring Your Own Device, Any Place, Any Time, Any Device en Sociale Media op Smartphones stroomt informatie en communicatie tussen media. Met de doorbraak van context gestuurde media (location based services etc.) zal die interactie nog versnellen. Het I-Bridge datamodel is er op ingesteld om ruis te onderdrukken en zorg te helpen dragen voor kwalitatieve en gecontroleerde communicatie verspreiding via verifieerbare media, waarbij wordt geregeld hoe ondersteuning via niet-verifieerbare media kan worden herkend en ingepast.
In de opeenvolgende IST generaties I-Bridge is ervaring opgedaan met de combinatie van Peer2Peer en Webservices om informatie uit te wisselen, draaiend op OGC protocollen als WMS, WFS en Esri REST. De enige ervaring op het vlak van P2P protocollen was met Microsoft Groove. De reden voor de combinatie van P2P en Webservices is geboren uit de praktijk, maar zie je momenteel op allerlei plaatsen waar a priori processen te kampen hebben met de data dynamiek. Sociale media gebruik en APATAD proliferatie leiden nu eenmaal tot data volatiliteit waar legacy organisaties niet mee om kunnen gaan, tenzij zij een verbinding leggen tussen P2P en Webservices. Binnen I-Bridge opgelost door Groove zich te laten gedragen als client op het Sharepoint platform. Dankzij die combinatie was full tekst search mogelijk en kon management informatie worden gegenereerd. Ook ontstond al snel de behoefte om browser gebaseerd toegang te kunnen verlenen aan derden die Groove niet geïnstalleerd hadden. Al in de eerste generatie I-Bridge is daarom gekozen voor een combinatie tussen p2p en webservices, om het veld en kantoor van dezelfde informatie te kunnen voorzien. Zo zijn diverse oefenconfiguraties geconfigureerd, vanuit overwegingen als: Haalbaarheid (realiteitszin: is het concept door te ontwikkelen naar een operationeel systeem.) Schaalbaarheid (hoeveel gebruikers kunnen er op het systeem, hoeveel tegelijkertijd, hoe snel kunnen ze bij/af schakelen, met welke gevolgen voor de stabiliteit van het Systeem etc.) Betaalbaarheid (tegen welke kosten kan het concept doorontwikkeld worden naar een robuust systeem, wat zouden de beheer- en exploitatiekosten van zo’n systeem zijn, etc.)
5.4
Berichten gegevens (Wat)
Binnen I-Bridge kan van alles gecommuniceerd worden, beelden, tekst, databestanden …. Hoewel I-Bridge een test omgeving is, wordt wel zoveel mogelijk geleerd van en gewerkt met
24
5
ontwikkelingen in de OOV markt, zoals het IMOOV informatiemodel , het stelsel van basisregistraties, het gebruik en toepassing van semantiek en symbolensets binnen i-Bridge . Voor het berichtenverkeer gelden de volgende statements: Gebruik van technische standaarden (LDAP, ISO etc) 6 Gebruik van sector specifieke semantiek en symbolen . Gebruik van Microsoft technologie en Open Source technologie in optimale mix. Active Directory Service met geïntegreerde DNS. Kennisopbouw van Federatief Identiteit Management in brede zin, waaronder de Windows Azure Active Directory (Federation Services) ontwikkelingen. Gebruik van een virtuele omgeving. Gehost in hosting center met beperkt aantal Publieke IP adressen. Directe koppeling met een internet edge over een transparante firewall Gebruik maken van Hardware HP BladeSystem Gebruik maken van verschillende subnets/vlans die met elkaar kunnen communiceren. Een remote VPN connectie naar de infrastructuur Voor gebruikers werkplekken worden laptops met draadloos internet gebruikt I-Bridge heeft geen koppeling met Mulan of andere defensie netwerken. Data zijn geen product, maar de grondstof (ruwe olie) waar alles mee begint. Analyse instrumenten nemen de plaats in van business intelligence/data mining. Ingesteld is op het zoeken naar patronen binnen een conceptuele danwel juridische context en een hoge mate aan automatisering in situational awareness, door structureel te zoeken naar specifieke patronen binnen een Area of Interest (AoI). Dit heeft geleid tot succesvolle PoCs zoals Maritime Situational Awareness en de natuurbrand scanner. Cloud computing brengt de toegevoegde waarde hoger in de waardeketen: de eindgebruiker staat centraal en moet worden gefaciliteerd met geïndividualiseerde massaproductie. Voor de berichten gegevens heeft dit tot gevolgd dat bij voorkeur data los bezien wordt van applicaties en dat zo veel mogelijk wordt ingezet op data-object-relatie-attribuut gedefinieerde data stromen. De I-Bridge architectuur is eerder service-centrisch dan server-centrisch. Data privacy gaat uit van risico profielen en niet van toegangsbeheer Sociale omgevingen ontpoppen zich als nieuwe bron van business intelligence, wat eveneens leidt tot een voorkeur in object data als basis voor de berichtenstroom. Uiteindelijk draaide alles om de gebruikservaring van de eindgebruikers. Dit alles heeft de volgende consequenties: Het conceptueel datamodel gaat uit van het identificeren van data als data object, met zijn relaties en attributen. In de realiteit was dat nog niet altijd haalbaar. Traditioneel wordt data namelijk gezien als content dat een product is van de software applicaties, danwel onderdeel uitmaakt van specifieke software. In I-Bridge is data wel zoveel mogelijk gezien als herbruikbaar data object, met relaties en attributen. Waar dit niet mogelijk is, zoals bij basisregistraties, is getracht de data combineerbaar (verrijkbaar) en deelbaar te houden. Context gaat boven content. Toegang tot data gaat boven bezit van data. Het datamodel gaat uit van het identificeren van gebruikers boven IP adressen. Er is toegewerkt naar het werken met rollen, die op basis van claims en binnen de grenzen van regels en beleidsinstellingen worden bekeken. De intelligente kaart is hier een voorbeeld van. De benadering draagt eveneens bij tot een optimale beveiliging in context en opent desgewenst de deur tot de inzet van context gebaseerde firewalls, die niet alleen ‘monitoren’ of data wel door een specifieke poort mag, maar ook waar die data naar toe wil, langs welke wegen, op welke manier, voor wie, in welke volgorde en waarom. Hiermee zou voor een volgende generatie weer een stap richting end2end beveiliging zijn gezet. Aangezien conceptueel uitgegaan is van data als grondstof en niet van data als product, is het interessanter geworden waar data vandaan komt en waar het nu is, dan hoe data tot stand gekomen is en wie er het eigenaarschap op claimt. 5
Het Informatiemodel voor de Openbare Orde en Veiligheid (IMOOV) maakt soepele uitwisseling van geoinformatie mogelijk tussen brandweer, politie en hulpdiensten. 6 De betekenis van informatie objecten en het tonen van specifieke selecties van informatie objecten o.b.v. de inhoud van een meldkamerbericht e n/of de ingelogde functionaris is een aandachtspunt binnen het I-Bridge programma, waar onder andere mee is geëxperimenteerd met de Semantische Kaartlagen.
25
Door toe te werken naar een architectuur met data-objecten, is uiteindelijk controle op object, relatie en attribuutniveau mogelijk. Dit zou voor een volgende generatie I-Bridge moeten leiden tot een veel fijnmaziger en beter digitaal beheerbaar systeem met veel meer ‘zelfdiagnostische kennis’ en een real-time audit en informatie dashboard capaciteit. Hiermee ligt een een mooie brug naar het IIK project dat toewerkt naar ‘informatie op maat’.
Met data als platform kunnen gebruikers nieuwe informatie samenstellen die leidt tot zingeving: inzicht en daarmee tot User Generated Productivity. Data die beschikbaar is, leidt tot innovatie in gebruik en daarmee tot probleemoplossend vermogen. Precies wat je bij een crisis nodig hebt, wanneer veel zaken tegelijk gebeuren.
Het resultaat is een datastroom die voortdurend (her)gebruik van content in verschuivende contexten mogelijk maakt. Bijvoorbeeld in het hier geïllustreerde voorbeeld van een dataflow die inlichtingen kan omzetten in missie toekenning, asset management en resultaat verantwoording.
6.
6.1.1
Beveiliging
Databeveiliging
De dreiging die computernetwerken en computersystemen ondervinden groeit exponentieel en de impact van de digitale dreiging kan – zeker in de OOV - niet worden overschat. Hoewel de realisatie van de i-Bridge PoCs zich niet richtte op het verfijnen van databeveiliging is daar wel over nagedacht. Met data als de kern van I-Bridge is het grootste risico voor een sterk geautomatiseerd platform dat een onbekend programma dat heimelijk in de datastroom is binnen geslipt, dat: Data kan stelen Dataverkeer kan verstoren of data zelf kan verminken Dataverkeer en data zelf kan vernietigen. Hoogmobiele medewerkers versturen data over commerciële mobiele netwerken die weer hun eigen beveiliging uitdagingen kennen. I-Bridge data moet dus integraal beveiligd worden en databeveiliging en een diepgeworteld gevoel voor digitale risico’s heeft gedurende het programma deel uitgemaakt van het integrale I-Bridge pakket. Daarnaast is aandacht geschonken aan ontwikkelingen in Open 7 Standaarden en bij andere overheden. Met een zo eenvoudig en helder mogelijk datamodel kan met iedereen worden samengewerkt. Behalve gericht op integrale beveiliging, bouwt het datamodel voort op het concept van multi-tenancy: het gelijktijdig gebruik van eenzelfde generieke infrastructuur door onafhankelijk van elkaar opererende gebruikers. Gedeelde infrastructuur verandert de onderliggende bedrijfseconomische overwegingen van Enterprise applicaties. Het stelt de aanbieder in staat om een eenduidige infrastructuur te onderhouden voor duizenden gebruikers die allemaal hun eigen wensen hebben.
7
Er zijn diverse data synchronisatie standaarden erkend en in voortdurende ontwikkeling. Zo is er een specifieke toepassing van XML om de EDXL specificatie mogelijk te maken, wat weer leidt tot het bijvoorbeeld het Common Alerting Protocol (EDXL-CAP) dat als consistent waarschuwing format wordt geaccepteerd. EDXL-CDP is de standaard voor het uitwisselen van gevaar, noodsignalen en publieke waarschuwingen EDXL-DE (Distribution Element) is de standaard voor het routeren van de juist geformuleerde XML noodberichten, zoals geografische kenmerken, incident type en de ID’s van zender en ontvanger. EDXL-RM (Resource Messaging) levert een set standaardberichten voor het managen van resources tijdens een incident zoals het opvragen, toewijzen, terugkeren en deployen van resources. Dan is er nog het Hospital Availability Exchange (EDXL-HAVE) format, dat communicatie met een ziekenhuis allocatie centrum mogelijk maakt om vragen te stellen over bed capacity en beschikbaarheid, de kwaliteit van de noodvoorzieningen, de beschikbaarheid en aard van beschikbare van diensten en de technische mogelijkheden van het ziekenhuis.
26
Het resultaat gaat veel verder dan schaalvoordelen: multi-tenantcy vergroot flexibiliteit en versnelt innovatie, omdat er gewerkt kan worden met een eenduidige code basis, terwijl de klant populatie én de machinekamer als geheel kan worden gemonitord. Die transparantie maakt het mogelijk om zo efficiënt mogelijk met schaarse middelen als hardware en bandbreedte om te gaan. We kunnen stellen dat hoe helderder het datamodel, hoe beter een infrastructuur gedeeld wordt door de gebruikers, hoe groter het voordeel per gebruiker. Uiteindelijk draait alles om Trust, om vertrouwen en om ‘onmiddellijkheid’: datgene dat je wilt, moet je niet later moeten opzoeken in een databank, maar moet beschikbaar zijn en gepresenteerd worden op het moment dat de data gegenereerd wordt: real-time informatie. Een datamodel maakt die snelheid mogelijk, door structureel aandacht te geven aan de kenmerken:
Personalisatie: Generieke content kan iedereen leveren, maar echt op de persoon/rol toegespitste informatie heeft meerwaarde, die bestaat bij de gratie van dialoog tussen producent en afnemer. Interpretatie: inzicht in wat je krijgt, als het datamodel transparant is helpt dit interpretatie Authenticiteit: zeker weten dat de code die je krijgt gevalideerd is, betrouwbaar is en vrij van smetten. Een optimaal datamodel maakt uiteindelijk dynamic whitelisting mogelijk. Het is dan wiskundig onmogelijk geworden dat gepresenteerde data niet integer is. In het nieuwe datamodel zouden deze middelen (vb software als Coretrace) nog moeten worden aangevuld met technieken als Adress Space Layout Randomization (ASLR), Data Executing Prevention (DEP) en sandboxing van drivers (waarmee afgesloten ruimtes worden gecreëerd waarbinnen opdrachten worden kunnen uitgevoerd). Toegankelijkheid: de eindgebruiker wil veel zaken niet ‘hebben’ (blijven betalen), maar hij wil er wel snel bij kunnen. Je ziet dus al snel abonnement modellen en app stores ontstaan. Embodiment: de wijze waarop een goed zich manifesteert. Boek content is gratis, gebonden print is duur. Patronage: een groep gebruikers die de maker ‘willen’ betalen. Findability: ‘gevonden’ kunnen worden kan een prijs hebben.
De gekozen oplossingsrichting voor dataopslag/datagebruik voldoet hier mee aan het NORA uitgangspunt van eenmalige opslag en meervoudig gebruik, wat impact heeft op onder andere databeveiliging, aansprakelijkheid, doorzoekbaarheid, governance in termen van heldere rollen en verantwoordelijkheden (mandaten) en accountability (toekenbaarheid van kosten). Het I-Bridge datamodel is zo gekozen dat contextualisatie van informatie mogelijk wordt gemaakt en niet langer uitsluitend het managen van content. Het streven was om de integriteit van de data tot in het diepste detail door e voeren doorgevoerd. Een ezelsbruggetje is het acroniem MOVE:
Modellen die alle kennis omvatten die de I-Bridge applicatie ‘weet’ Operaties die alle acties omvatten de de applicatie op basis van die kennis ‘doet’. Views die de interface genereren tussen de applicatie en de eindgebruiker. (die hoogmobiel andere visualisatie mogelijkheden voor handen heeft dan op een werkplek) Events die maken dat alle tijdelijk benodigde componenten elkaar veilig weten te vinden.
Het mag duidelijk zijn dat onder de programma beperkingen dat ideaaltypische niveau niet is bereikt.
6.2
Argumenten
De business van I-Bridge is ad hoc en slecht planbaar, waardoor de traditionele schedule push benadering niet langer de druk van reality pull eisen kan weerstaan. Dankzij digitialisering staan crises niet langer op zichtzelf, maar gedragen zij zich als een muterende informatieverzameling. De arena waarin I-Bridge opereert laat zich niet sturen en is zelf ook in flux. Het heeft daarom weinig zin om strakke afspraken te maken en in beton te gieten. Veel zinniger is het om strategisch te kiezen voor ingebouwde flexibiliteit obv middleware. De kosten van flexibiliteit moeten worden afgezet tegen de omstelkosten – de kosten om achteraf (delen van) systemen aan te passen aan (onverwacht) veranderde omstandigheden.
27
Door I-Bridge te zien als container voor verschillende deelgemeenschappen, ontstaat een basis voor gecoördineerde besluitvorming en gerichte alarmering van functionarissen. Cross Domain Sharing by design: niet de organisatie in beton gieten, maar zorgen dat gegevens over organisatorische grenzen kan stromen, maar wel beschermd tegen ongeautoriseerde toegang. Collaboratie tools (zoals Groove, Sharepoint, Team Room…) zijn als push mechanismen ideaal voor de ontsluiting van de grote verzamelingen ongestructureerde informatie die een logisch gevolg zijn van sociale dynamiek die ontstaat als mensen vrijer samenwerken in I-Bridge ’s interne sociale netwerk. Dit is een abonnee model waar geautoriseerde medewerkers zich bij aan kunnen sluiten om informatie te delen. Collaboratie tooling maakt dat content management en sociale netwerk software zich vermengt. Door de wens om Any Place, Any Time, Any Device data ontsluiting zal data organisch vermengen. Ook hierom zou men bij doorontwikkeling moeten kiezen voor een gefedereerd model. Zorg dat gegevens grafisch en in verschillende combinaties kunnen worden weergegeven: dat dwingt tot flexibiliteit en transparantie informatie huishouding en vereenvoudigt het komen tot betekenisvolle informatie op basis waarvan operationele besluiten kunnen worden genomen. Controle door de individuele gebruiker, binnen de grenzen van zijn rol Door uit te gaan van een claim gebaseerd model hoeft niet gekozen te worden voor een specifieke definitie van identiteit. Dit levert een relatief goedkoop, maar veilig model op. Transparant, met respect voor context, veilig in toegang en accuratesse Gerichte verzameling van gegevens en verantwoording toekenning Door helderder te hebben uit welke onderdelen het business proces bestaat zijn kleinere bedragen effectiever in te zetten door kleine modules te kopen. Er moet een data-re-integratie strategie zijn, om verrijkte data terug te kunnen voeren. Gebruik maken van bestaande claim uitwisseling standaarden zoals OASIS.
6.3
Uitwerking van het beveiliging concept
De realisatie van de PoCs heeft plaatsgevonden binnen de vigerende veiligheideisen van Defensie. Aangezien deze eisen doorgaans zwaarder waren dan de veiligheidseisen van civiele partners en aangezien binnen de PoCs niet zelden werd geëxperimenteerd met nog zwaardere concepten, zoals de CompuWall voor mobiele telefonie, was de beveiliging voor de PoCs ruim voldoende afgedekt. Echter, I-Bridge is ook bedoeld als leeromgeving en voor doorontwikkeling kan het nog beter. Op basis van de opgedane ervaringen wordt geadviseerd om bij doorontwikkeling van I-Bridge toe te werken naar een Federatief Identiteit Management model met een claim/rule/policy uitwerking. De reden hiervoor zit met name in de uitwerking van cloud computing. Cloud computing heeft als kenmerk dat IT geen product meer is, maar een nutsvoorziening. Een dienst waarbij de mogelijkheden zich traploos, schaalbaar, naar behoefte aanpassen aan de behoeften van eindgebruikers uit diverse deelorganisaties. De traploze combinaties van functionaliteiten die de soepele communicatie tussen processen mogelijk maakt, vereist een geautomatiseerd samenspel op vijf lagen tegelijk: Proces Informatie Applicaties Data Infrastructuur
: hier worden alle beslissingen genomen. : hier vindt de ondersteuning van de beslissingen plaats : systemen die de data weergeeft als informatie : de interoperabele grondstof van hoge en consistente kwaliteit : levert de veilige hosting en communicatie
Het Informatie Management Model dat hierbij hoort moet zijn ingericht op het type informatie dat gedeeld moet worden en het verzekeren van de kwaliteit van de gedeelde informatie, wat cruciaal is om goede beslissingen te kunnen nemen. Informatie moet tijdig zijn, kloppen en voldoende rijkheid 8 hebben. Door de inzet van federatie, de 4 A’s en de juiste taxonomieën, wordt het mogelijk dat I-Bridge nog beter een rol als knooppunt van onafhankelijke informatiestromen kan innemen. Hiervoor zijn Informatie Deling Afspraken nodig, die voor de PoCs vanzelfsprekend nog niet voor handen waren. Een Information Sharing Agreement (ISA) is een overeenkomst tussen samenwerkende organisaties, waarin de verificatie en compliancy methodologie staat beschreven, waaronder: 8
Authenticatie, Autorisatie, Access en Audit =de 4 A’s.
28
Scope en type van de te delen informatie + omstandigheden waaronder informatie gedeeld wordt. Hoe informatie gebruikt, gedeeld, verspreid, beveiligd, geschoond en gemanaged moet worden Ook gespecificeerd wordt eventueel verder gebruik van de vrij te geven informatie. o Wie (organisatie en rol) is betrokken in het delen en managen van informatie: hier worden de rollen en verantwoordelijkheden beschreven. o Welk toegangscontrole model met welke afspraken wordt gebruikt. o Welke taxonomie en data labeling wordt gebruikt. o Welke juridische en beleidslijnen bepalen het gebruik, het management en de opslag van informatie. o Welke procedures worden gevolgd om compliance te kunnen afdwingen, om conflicten op te kunnen lossen en om na incidenten de normale informatie deling weer te kunnen hervatten. o Welke juridische, kader stellende en beleid voorschrijvende documenten van kracht zijn en die leidend zijn bij de compliance inspanningen. Denk aan Non-disclosure Agreements, Memorandum of Understanding, contracten en huishoudelijke voorwaarden.
De volgende illustratie toont helder aan dat als we praten over de voorwaarden waaronder mensen en objecten toegang tot informatie mogen krijgen, we moeten zien te komen tot een beslissingsmodel. Dat model moet een afgeleide zijn van de bedrijfsdoelstelling (wat wil je bereiken), het organisatiemodel (hoe wil je je bronnen inzetten), je gemeenschappelijke taal (hoe begrijpen we elkaar), je processen (wie doet wat in welke volgorde en waarom) en je beschikbare technologie.
In de I-Bridge PoCs zijn zoveel mogelijk leermomenten op deze weg hergebruikt. De technische architectuur uitdaging voor een volgende generatie I-Bridge is te komen tot een platform dat de federatie van identiteiten, rollen, claim modellen en procespatronen tussen al deze aspecten integraal kan faciliteren met profiel gebaseerde dienstverlening, uitgewerkt op basis van flexibele, schaalbare en elastische, integrale beveiliging die uitgaat van de identiteit van de gebruiker (mens of object). Wat daarvoor nodig is, is Gefedereerd Identiteit Management (FIM). In de bijlage wordt FIM verder toegelicht. Om samen te werken en informatie te kunnen delen, moet elke organisatie (of organisatie onderdeel, of actor) in de keten betrouwbaar zijn. Hiervoor moet het ID management van elke ketenpartner intern homogeen en extern interoperabel zijn. Als dat het geval is, dan kan gefedereerd worden, op basis van gemeenschappelijke beleidsafspraken, procedures en mechanismen. De ambitie voor een hoogwaardige Enterprise Service Bus met Federatief Identiteit Management en claim/policy based toegang mogelijkheden in te richten ging te ver voor i-Bridge . Wel zie je dat de benodigde architecturen en configuratie diensten in rap tempo op de markt komen, evenals logische raamwerken als het Open Identity Trust Framework (OITF). Dat de eerste ESB-FIMs als managed service geleverd kunnen worden maakt dat een doorontwikkeling van I-Bridge de aandacht kan focussen op het modeleren van de operatiën.
29
Wie is waarvan? Hoe moeten processen lopen? Welke beleidsafspraken gaan gelden? Je kunt dan FIM configureren, zonder dat het nodig is om zelf een dergelijk systeem te ontwerpen. In de bijlage over gefedereerd identiteit management worden de lessons learned verder uitgewerkt.
7.
Netwerk (Hoe)
I-Bridge is ontworpen om in een productieve omgeving te voldoen aan randvoorwaarde dat alle soorten communicatie systemen op I-Bridge aangesloten moeten kunnen worden: TCP/IP is het standaard communicatie protocol Ieder device kan als client aangesloten worden, met beperking in functionele mogelijkheden Data in I-Bridge is Departementaal vertrouwelijk geclassificeerd. Alle dataverkeer in I-Bridge is encrypted op basis van (?) met (?) Mits de topologie goed is uitgevoerd kan I-Bridge enige honderden gelijktijdige gebruikers aan. Dankzij de gebruikte peer2peer technologie varieert de performance hierbij tussen de langzaamste en snelste verbinding, maar komt uiteindelijk de data (vectoren) altijd aan. I-Bridge is als (cloud) omgeving bedoeld om diverse calamiteiten tegelijk te ondersteunen. In principe kunnen alle handelingen die binnen de I-Bridge omgeving plaats vinden worden gelogd voor latere evaluatie. Hiervoor is in eigen beheer een unieke tool gemaakt, die ook zaken logt die normaal niet zo eenvoudig te loggen zijn, zoals het beeld op buienradar.nl. Ook netwerkverkeer, dataroutering, gesprekken en locatiegegevens worden voortdurend gelogd. Hierdoor zijn dwarsdoorsnedes mogelijk waarmee vragen kunnen worden beantwoord als ‘wie zei wat tegen wie, op welk moment, vanaf welke locatie en op welke manier’. Voor de toekomst kan deze data uitstekend dienen als input voor Serious Gaming, maar ook eventuele Kamer-vragen zouden dankzij deze near-real time logging methode razendsnel kunnen worden beantwoord. Niet vergeten mag worden dat I-Bridge een Open Innovatie opstelling is. ‘Echt’ loggen is een wetenschap op zich en zou professionele middelen vereisen, zoals gebruikt worden bijvoorbeeld de luchtvaartindustrie.Dergelijke middelen maken ook het veilig exporteren van data-uitsnedes mogelijk op mobiele datadragers, zoals USB-sticks, die eventueel zonder schade verloren mogen worden door verregaande versleuteling.
30
8.
Bijlage 1 Componenten van i-Bridge
Met de SOLL architectuur als evoluerende stip op de horizon, is de IST architectuur ingevuld door zo generiek mogelijke COTS elementen te combineren. Hier staan de gebruikte componenten genoemd. Clients Functie Systeem Versie Leverancier Esri ArcGIS Desktop Esri Inc (www.esri.com), Onafhankelijke Microsoft Corporation ClientFat client (Groove (www.microsoft.com) client) Surface Table (Groove client) Locatie tracker Mobiele telefoon TETRA Radio Gateway C2000 Radio Gateway FM9000 Radio FM9000 Radio Gateway Gateway Netwerk infrastructuur Functie Fysiek netwerk Fysiek netwerk Fysiek netwerk Fysiek netwerk Authenticatie database
Systeem Switches Routers Firewalls Reverse Proxy Firewall Active Directory Domain Service
Domain Name Services Public Key Infrastructure (PKI) Plaatsbepaling (op basis van civiele GPS) Functie Systeem Plaatsbepaling Movida Plaatsbepaling Tracker Spraak Functie Systeem OCS Edge OCS Frontend Server OCS Mediation VOIP gateway naar PSTN VOIP Telefooncentrale Wave management Server Wave mediator Server Content Management Functie Systeem Sharepoint Peer-2-peer technologie voor geo en collaboratie Functie Systeem Groove Relay Servers Groove Management Groove Databridge Databases Functie Systeem
Versie
Leverancier
Versie
Leverancier www.geodan.nl www.cosetec.nl
Versie
Leverancier
Versie 2010
Leverancier www.microsoft.com
Versie
Leverancier
Versie
Leverancier
31
OCS Logging SQL Servers Oracle Servers GeoGis (centraal) Functie
Crypto Functie VPN Concentrators
Systeem ArcGIS Server Movida Location Server
Versie
Leverancier www.esri.com www.geodan.nl
Systeem
Versie
Leverancier
De volgende paragrafen beschrijven de functie en werking van componenten binnen I-Bridge in samenhang met de afhankelijkheden per architectuurlaag. Clients I-Bridge is ontwikkeld om gebruikt te kunnen worden door een breed scala aan clients die ieder een bepaalde mate van functionaliteit krijgen, afhankelijk van de geïnstalleerde software. Een onafhankelijke client krijgt basale toegang tot een website, terwijl de volledige I-Bridge client (fat client) de mogelijkheid heeft om met kaart materiaal te werken en via de microfoon gesprekken te voeren met een hulpverlener ter plaatse. Een belangrijke cliënt applicatie is Microsoft Groove. De I-Bridge client is een schil bovenop de Microsoft Groove client. Groove verzorgt de communicatie tussen de gebruikers in het team op basis van Peer-to-Peer technologie. Groove heeft op de representatielaag een ‘present service’ nodig die aan clients kan vertellen welke clients aanwezig zijn en welk IP adres zij hebben. De centrale Groove infrastructuur manifesteert zich voor de gebruikers als een reguliere Groove client. Waar Groove in de eerste generaties van I-Bridge nog voldeed, zou het voor een cloudversie verstandig zijn te kiezen voor een schaalbaarder concept als Sharepoint 2010 werkgroepen. Groove client data staat versleuteld op de harddisk en verstuurt alleen versleutelde delta’s richting de Groove clients. Een aparte client is de Surface tafel client, een soort enormedit is tafel met aanraakscherm, deze client maakt ook gebruik van Groove om GEO coördinaten uit te wisselen met de andere clients, maar maakt gebruikt van third party service van Bingmaps en Cyclomedia. De meest elementaire client is een telefoon waarmee iemand gebeld kan worden. Binnen I-Bridge worden verstrekte mobiele telefoons gevolgd via GPS. De locatieserver kan hierbij zowel bij de telecomprovider staan, als in de eigen (virtuele) omgeving. De locatie gegevens kunnen in real-time op een kaart worden weergegeven zodat te zien is waar het toestel is. Dit toestel kan eventueel ook een auto of een ander object zijn waar een SIM in is gestopt. Ander voorbeelden van spraakclients zijn C2000 en FM9000 radiosystemen, die via VOICE gateways worden gekoppeld aan het Voip systeem van I-Bridge . Presentatie Front-End De representatielaag is het externe koppelvlak van I-Bridge naar het internet. Hier bieden we een aansluiting naar de GeoGis diensten Collaboratie- , telefonie en IM diensten. De Groove Relay communiceert met de buitenwereld mbv het Simple Symmetric Transfer (SSTP) protocol. De relay server is de verbindende schakel tussen verschillende domeinen. De verbinding tussen de client en de server is versleuteld. De OCS Edge services is de koppeling met de clients over het Internet. De server zorgt ervoor dat IM en Voipsoftclient (MS Office Communicator) via een versleutelde verbinding over het internet met de fatclient kan communiceren. De TMG Reverse Proxy firewall publiceert alle websites waar de I-Bridge client mee communiceert. De Voip Telefooncentrale zorgt ervoor dat VOIP telefoons en andere clients aangesloten worden op de client. De VPN concentrator zorgt ervoor dat er een remote locatie via een versleutelde verbinding gekoppeld kan worden aan de backoffice. Presentatie Front-End Web In de presentatie backend staan webservers die gepubliceerd worden naar het intranet via de reverse proxy server in de Presentatie Frontend laag. De webserver bieden Geo, GPS en collaboratie websites aan. Verder worden er website ten behoeve van de security authenticatie gepubliceerd.
32
Processing Op de processing laag staat applicatie servers die verzoeken van de client via de presentatie laag afhandelt. De servers die hierin staan zijn het hart van I-Bridge . Voorbeelden hiervan zijn de GIS applicatie server, de Groove databridge servers, de OCS servers en de Wave servers, die tevens een koppeling hebben naar de database servers waar de gegevens worden opgeslagen. Storage De volgende typen gegevens worden opgeslagen Logbestanden van communicatie (tekst en audio) Kaart materiaal (Microsoft Virtual Earth en Arcgis servers) Operationele gegevens (verplaatsingen, van personen, objecten etc) Documenten Backup van de data-informatie van de Fatclients Websites Authenticatie database (Active Directory) met user credentials. Beschrijving functionele Architectuur Om een beeld te krijgen van de werking, (dataflow) dienen we te weten welke componenten binnen I-Bridge gebruikt worden, wat de componenten doen, welke input hiervoor nodig is en waar de output van een bepaald component voor gebruikt wordt. Dit wordt beschreven in de functionele architectuur. Per component worden tevens de afhankelijkheden beschreven. Clients We onderkennen een ‘Onafhankelijke Client’ die vooraf niet bekend is bij het i-Bridge team. Het is belangrijk dat deze client een Internet browser heeft met Silverlight plugin, zodat hij toegang kan krijgen tot de Sharepoint webpagina, zoals gepubliceerd via de Reverse proxy Server. Fatclient Deze Client heeft als functie dat hier de gebruikers gebruik kunnen maken van de I-Bridge toepassingen. Zij maken gebruikt van IP Protocol over het internet. De datastromen zijn versleuteld. De datastromen van de client hebben een directe connectie met de Groove Relay server, OCS Edge Server en de Reverse proxy server. Surface Client De surface werkt hetzelfde als de FATclient, alleen deze client heeft het kaart materiaal niet local staan. Verder zijn er extra functies aanwezig, zoals streetview en 3d view. Locatie tracker De locatietracker client haalt via GPS zijn locatie coördinaten binnen en stuurt deze dan via het internet naar de Movida Server. Deze server wordt aangesproken via de Reverse proxy firewall. Hardware matige Voip Client De VOIP client maakt een directe, versleutelde verbinding over VPN naar de VOIP telefooncentrale. PSTN Client De PSTN client kan verbinding maken met I-Bridge , door het telefoonnummer te bellen wat achter de Voip gateway van I-Bridge staat. Door de juiste extentie te bellen, wordt men doorverbonden met Wave voor communicatie met Radio systemen, of men kan direct een voice client bellen. C2000 en FM9000 client Daar C2000 en FM9000 radio systemen zijn, kan een koppeling met I-Bridge Voip gemaakt worden via een speciale gateway. Er is dan wel een systeem nodig dat de verschillende radio kanalen kan koppelen met normaal telefoon verkeer. Hier wordt Wave voor gebruikt. Presentatie Front-End Er staan diverse servers met verschillende services in de Presentatie Frontend laag. Deze zijn hieronder beschreven. Reverse Proxy De reverse proxy firewallheeft als functie om de client te authenticeren en website in de Presentatie backend aan de client te presenteren.
33
De website die worden gepresenteerd zijn Sharepoint.Het content management systeem van I-Bridge . Hiermee kan collaboratie en geo informatie worden opgeroepen via een onafhankelijke client. Cosetec / Movida.Dit zijn frontend servers van het plaatsbepalingssysteem van I-Bridge . Clients met GPS sturen hun locatie coördinaten hiernaartoe, en clients die willen opvragen waar een bepaalde client is, gebruikt deze website om de coördinaten te downloaden. Cosetec word alleen maar gebruik om GPS coördinaten naar toe te sturen door de leverancier Cosetec. Certificate authorityCRL.Dit wordt door client aangeroepen om te kijken of een certificaat nog geldig is. Groove Management.Groove client kijken via deze server of het Grooveaccount nog geldig is en of er eventuele Groove policies zijn veranderd voor deze gebruiker. De authenticatie van de Grooveclient gebeurt locaal. OCSEdge De OCS Edge server heeft een directe verbinding met de Client via een versleutelde verbinding. Ook heeft de OCS Edge een verbinding met de OCS frontend server. Alle data die de OCS edge ontvangt van de client word doorgestuurd naar de OCS Front-End Groove Relay De Groove relay server heeft een verbinding met alle Groove client. De relay server houdt de delta tussen de clients aan etc. Aan de binnenkant heeft de Groove relay een SOAP connectie met de Groove manager. Ook heeft de Groove relay een verbinding met de Groove databridge. Deze server wordt gezien als een Groove client en gebruikt dus dezelfde datastromen als de normale Groove client. Presentatie Front-end Web Movida Server De movida server is een plaatsbepaling server voor movidaclient en kan ook een koppeling maken naar third party plaatsbepaling systemen. De movida client (meestal een windows mobile device) maakt verbinding via http naar de movida service en geeft de GPS coördinaten door aan movida. Andere clients kunnen via dezelfde manier movida aanroepen om te bekijken waar bepaalde movida devices zich bevinden. De datastroom gaat via de reverse proxy server. Sharepoint Server Elke webclient kan verbinding maken via de reverse proxy server naar de Sharepoint server. Op de Sharepoint wordt informatie weergegeven. De Sharepoint heeft een connectie met de SQL server. Ook publiceert Sharepoint webpagina’s van de arcgis liveviewer website en Bingmaps. Online Enterprise CA De online Enterprise CA is de server die certificaten uitgeeft. Deze certificaten kunnen worden gekoppeld aan het ADDS. Via de reverse proxy word de Website van de CRL (certificate Revoke List) geplubliceerd, zodat client op het internet kunnen nakijken of de certificaten nog geldig zijn. Groove management De Groove management server is een webserver waar je Groove accounts kunt managen, dit kan doormiddel van policies. De Groove manager heeft een SOAP connectie met de Groove Relay server. Zodat deze ook weet welke instellingen bij elke client gemaakt heeft. De wachtwoorden voor authenticatie van Groove worden niet in de Groove manager op geslagen. Er wordt een klein gedeelt van de Groove management server gepubliceerd zodat de Groove client kunnen opvragen of het Groove account geldig is en of er policy wijzigingen hebben plaats gevonden. OCS Frontend De OCS Fronted server is de belangrijkste Server van OCS. Deze server slaat de OCS instellingen op en communinceerd userinstellingen met de active directory. Ok houd deze server de status van de gebruikers bij en doet de authenticatie voor de gebruikers van OCS. Gebruikers die willen aanloggen via het internet, komen binnen via de OCS Edge. De OCS Frontend communiceerd met andere spraak systemen via de OCS mediator server. Deze Speciale OCS server kan communiceren naar andere Voip Systemen en Voice Gateways.
34
Wave Mediator Server De Wave mediator Server heeft connectie met Radio gateways via Multicast. Binnen I-Bridge zijn dit de C2000 en FM9000 radio gateway. De Wave mediator server communiceert met de Wave configuratie server voor overige gateways. Processing ARCGIS Server De Arcgis server is een server welke de geografische informative van de I-Bridge FAT client afbeeld op de Kaart Dit gebeurt via een Website. Deze website wordt via Sharepoint en de Reverse proxy server op het Internet gepubliceerd. De informatie wordt opgeslagen in de SQL database server. Movida Locatie Server Movida is het meest geavanceerde real time locatie systeem (RTLS) dat op de markt voor geo-ICT beschikbaar is. Movida is zowel voor gps- als voor RFID-toepassingen geschikt. Met Movida is op ieder moment een actueel beeld aanwezig van de locatie waar medewerkers, voertuigen of goederen zich bevinden: onderweg of op kantoor, in de werkplaats of daarbuiten. Er is zicht op de besteding van hun resources. Het levert de mogelijkheid om gericht locatiegebonden notificaties te genereren om bedrijfskritische processen te stroomlijnen en de interne en externe veiligheid te verhogen. Het kan uitgebreide rapporten genereren voor het analyseren van de operationele efficiency en het nemen van strategische beslissingen en het voorziet in geactualiseerde en geoptimaliseerde informatiestromen door tijd en plaats om in dit alles een sturende rol te geven (op netcentrische werkwijze). Groove Databridge De Groove databridge moet gezien worden als een intelligente Groove Client. Op netwerk gebied gedraagt de databridge zich ook als client, en maakt verbinding met de Groove relay en de Groove manager. Verder heeft een een connectie met de SQL server. Via een speciale applicatie wordt de informatie van de I-Bridge FAT client GEO applicatie in de SQl database opgeslagen, waarna de ARCGIS server deze informatie weer ophaalt voor de webapplicatie. De Groove databridge wordt ook gebruikt voor het backups maken van Groove spaces zodat deze informatie altijd geborgd wordt. OCS Mediator Server De OCS mediator zorgt er voor dat client die gebruik maken met OCS kunnen communiceren met andere spraak clients. De OCS mediator heeft een connectie met de Voice gateway welke er zorg voordraagd dat de spraakstroom naar het juiste device wordt gerouteerd. Dit kan zijn de waveserver, ip telefooncentrale of PSTN. I-Logger Deze server houdt alle i-Bridge informatie bij en publiceert deze op één dashboard. De I-Logger heeft connecties met Wave en met de Arcgis server en slaat alle informatie op in SQL. Database Movida DB (Oracle) De movida DB heeft de locatie gegevens van alle clients met een GPS tracker in zich. De movida DB heeft een connectie met de movida applicatie server. Bing maps Bingmaps bevat kaart materiaal van heel Nederland, daaraan vast zit een SQL database met verschillende lagen in de kaarten, bijvoorbeeld het wegennet, electriciteitsnet riolering etc. Bingmaps wordt gepubliceerd via de Sharepoint server. SQL Database In de SQL server staan verschillende databases. Hieronder beschreven I-Bridge database, hierstaan de informatie die de arcgis applicatie server gebruikt. Deze database wordt gevult door de Groove databridge. Groove management Database, hierin de info die betrekking heeft op de Groove databridge. I-Logger, hierin staat de informatie die betrekking heeft tot de I-Logger
35
ADDS De ADDS is een LDAP directory met alle objecten op client en user niveau. De ADDS server heeft een connectie met de reverse proxy, Groove management, Sharepoint, SQL server en de OCS front-end. Dit heeft allemaal te maken met de authenticatie en authorizatie. OCS is compleet geïntegreerd binnen de ADDS. OCS kan dus ook niet zonder de ADDS. OCS Monitoring De OCS Monitoring server logt alle informatie van OCS en heeft alleen connectie met de OCS Frontend server. Afhankelijkheden Componenten Om te kunnen functioneren heeft Component X de volgende componenten: Groove: aangezien de I-Bridge FAT client gebruik maakt van Groove is dit programma één van de belangrijkste elementen van I-Bridge en daarmee de Groove Relay en Groove Management servers en alle bijbehorende verbindingen. Arcgis: is afhankelijk van de data die binnenkomt via de SQL server en alle Groove componenten.Verder is Arcgis afhankelijk van de goede werking van Sharepoint. OCS is afgehankelijkvan de Active Directory. Om OCS vanuit het internet te gebruiken is de OCS noodzakelijk. Om met OCS naar buiten te kunnen bellen is er een afhankelijkheid van de mediator en de Voip gateway. Sharepoint is afhankelijk van de Sql database en van de reverse proxy om Sharepoint content te kunnen publiceren naar het internet. Movida is afhankelijk van de reverse proxy en van de achterliggende database. Cosetec is afhankelijk van de reverse proxy en van Movida. Wave is afhankelijk van de Mediator server, de Voip gateways en van werkend multicast routering. Schaalbaarheid De schaalbaarheid van het systeem is afhankelijk van de volgende componenten De beschikbare bandbreedte en het gebruik van bandbreedte per functie De beschikbare communicatiemiddelen Het maximale aantal gebruikers in een Groove folder Beschikbaarheid Beschikbaarheid is een vereiste voor een crisis management systeem, maar gezien het Open Laboratorium gehalte van de inzet zijn redelijke grenzen gesteld aan de gerealiseerde redudantie. Een beschikbaarheid van 100% is niet te garanderen, maar om de hoogste beschikbaarheid te verkrijgen moet aan het volgende gedacht worden Geografisch redudantie, dat wil zeggen op twee verschillende locaties een I-Bridge back-office waardoor altijd (in nood) een van de twee locaties gebruikt kan worden voor crisis management Systeem redudantie, alle systemen per locatie dubbel uitvoeren, servers en netwerk ontsluiting. Beschrijving benodigde software Component
Leverancier
Versie
Microsoft
5.2
Microsoft
6.0
Microsoft
Beta 3
4
Windows Server 2003 Windows Server 2008 Threat Management Gateway ASA
Cisco
8.2
5
ESX
VM Ware
4.0
6
Advanced Security IOS
Cisco
12(4)
1 2 3
Opmerking
36
7
Workstation
VM Ware
6.51
8
Windows XP
Microsoft
5.2
9
Windows Vista Enterprise Windows 7 Enterprise
Microsoft
6.0
Microsoft
6.1
Office Enterprise 2007 Sophos
Microsoft
12.0
Sophos
7.6
10 11 12
Technische architectuur De I-Bridge 3.0 infrastructuur bestaat uit een HP blade enclosure met een 7-tal HP Blade servers met een tweetal interne Switchesm die zijn ingedeeld in een x-tal VLANS: VLAN
Component
Versie
Leverancier
VLAN10 – 10.10.10.0/24 OAM/Management ESX machines HP Management addressen (ILO, Switches etc) Router/firewall management Virtual Servers Management Install / management/ loggings Servers VLAN20 – 10.10.20.0/28 Perimeter Intern Edge servers Intern VLAN21 – 10.10.20.16/28 Infrastructure Intern DNS servers / ADDS VLAN22 – 10.10.20.32/28 Unified communications Intern Email en OCS servers VLAN23 – 10.10.20.48/28 Web Servers Intern Web en applicatie Servers VLAN24 – 10.10.20.64/28 Database Intern Database Servers VLAN25 – 10.10.20.80/28 Voip Intern Voip Gateway servers/ call managers VLAN120 – 10.10.120.0/25 Perimeter External Private Edge servers Intern VLAN130 – Perimeter External Public Edge servers External Vlan x —10.20.10.128/25 Demo LAN Vlan x – 10.20.10.64/26 Demo WLAN De connecties naar de Hardware Servers zijn allemaal Trunks.(tagged dot1q) Vanuit hier is er in VMWare voor elk VLAN een Virtual Switch gecreerd. Het Data Intern VLAN zal niet rechstreeks naar buiten gerouteerd worden. De andere VLAN’s zullen met een fysieke kabel uitkomen op 1 van de Cisco routers of Cisco ASA firewall. De connectie met het DEMO LAN gaat doormiddel van 2 connecties. Een Cisco Site-2-Site easy VPN setup. Het eindpunt van deze VPN is de L3 Cisco router aan het buiten kan van het I-Bridge netwerk. Al het verkeer wat op deze router uitkomt, wordt eerst gefiltert en komt daarna op het OAM netwerk segment uit. Dit is gedaan omdat de VPN gebruikt werd als beheer oogpunt. De encryptie van deze VPN = 3des over ESP. Een Suphice Site-2-site VPN. Het eindpunt van deze VPN is in het intern perimeter netwerk. Deze VPN is opgebouwd volgens het suphice concept. Dit is een POC binnen de firma’s Thales en
37
Avensus. Het werkt tevens op ESP, maar de encryptie protocollen zijn variable. Dit wordt apart besproken in de TO van de kernfuncionaliteit cryptoharmosatie. INTERNET
PSTN
vlan10 vlan24 Wave Router
VPN Router vlan130
Vlan10 Vlan120
vlan10 vlan24
Blade Switch 1
Blade Switch2
vlan23
ESX6 ESX1
vlan
Virtual Earth
vlan vlan
10 20
21
vlan vlan
22 23
vlan
24
vlan
25
vlan vlan
120
130
ESX2
ESX3
vlan
10
vlan
10
vlan
10
vlan
20
vlan
20
vlan
20
21
vlan
21
vlan
vlan
vlan
22
vlan
vlan vlan vlan vlan
21
22
vlan
23
vlan
23
vlan
23
24
vlan
24
vlan
24
25
vlan
25
vlan
25
120
vlan 130
vlan vlan
120
130
ESX5
ESX4
vlan
22
120
vlan 130
vlan
10
vlan
20
vlan
21
vlan
22
vlan
23
vlan
24
vlan
25
vlan vlan
120
130
vlan
10
vlan
20
vlan
21
vlan
22
vlan
23
vlan
24
vlan
25
vlan
120
vlan 130
De Virtual servers worden dan via een untagged poort verbonden naar een virtual Switch. De virtual switches hebben elk één native VLAN. Met welk VLAN alle virtual servers verbonden zijn, dat hangt af van de functie van de server. De VLANs voor Intern gebruik zijn routable via de L3 Switch in de HP Enclosure. Edge Servers zullen verbonden zijn met VLAN20. Dit is het intern Perimeter network. Aan de External kant zijn de edge servers of verbonden met het “perimeter external private” network. Of met de “ perimeter external public” network. Het verschil hiertussen is dat de public DMZ afgeschermd word door een transparant firewall en dat de private DMZ wordt afgeschermd door een L3 router/firewall. Dit is nodig omdat er op dit moment niet genoeg public IP address beschikbaar zijn voor de proeftuin testruimte op de Defensie locatie Maasland. De volgende netwerken zijn aanwezig in de basis infrastructuur( backoffice) van I-Bridge 10 Management-Intern 20 Perimeter-Intern 21 Infrastructuur-Intern 22 Unified Communications-Intern 23 Web-Applications-Intern 24 Voip-Intern 25 Databaste-Intern 120 Perimeter-External 130 Internet-External
38
DEMO Location
C2000
GEO en COL DEMO
Wave Mediation FM9000
WAVE DEMO
LOGGING DEMO
Suphice Data Cryptor
Suphice
INTERNET
VLAN120 – Private Perimeter
ESX-Servers
HP-Enclosure Management Exchange Edge
CACTIE
SYSLOG
DNS Cache
WSUS
GrooveSuphice Authentication relay1 Server
ISA
OCS Edge
Suphice
Suphice Data cryptor
Management / Install Server VLAN20 – Perimeter Internal
Movida Arcgis
Groove management
OWA
Sharepoint
Virtual Earth
Cosetek
Logviewer
Exchange
OCS Standaard
VLAN21 – Unify Communications Internal
SQL
CA
ADDS DNS
VLAN20 – Infrastructure Internal
Groove Databridge
Oracle
OCS Mediation
VLAN21 – Unify Communications Internal
PSTN (PRI E1 / ISDN30)
HP Blade C7000 System Alle virtuele systemen zijn geïnstalleerd op HP Blade systemen van het type: HP Proliant BL460c G1 2x Quad-Core Intel Xeon, 2666 MHz processer 16384 Mb intern geheugen 2 * 146GB (15K SAS DP HDD (3.5") interne harde schijven; geconfigureerd als Raid 1 (Mirror) Deze systemen zijn gemonteerd in HP BladeSystem c-Class 7000 serie enclosure Voor het opzetten van de omgeving is gebruik gemaakt van 7 fysieke systemen: Serie nummer Productnaam Server Blade nummer CZJ804014L ProLiant BL460c G1 Server Blade #2 CZJ804011F ProLiant BL460c G1 Server Blade #3 CZJ921027X ProLiant BL460c G5 Server Blade #8 CZJ804013N ProLiant BL460c G1 Server Blade #10 DEH9121935 ProLiant BL460c G1 Server Blade #11 CZJ917043G ProLiant BL460c G5 Server Blade #12 CZJ8040132 ProLiant BL460c G1 Server Blade #16 En 4 extra storage blades . Storage blade #1 is gekoppeld aan Server Blade #2 Storage Blade #9 is gekoppeld aan Serverblade #10. Storage Blade #7 is gekoppeld aan Serverblade #8. Storage Blade #15 is gekoppeld aan Serverblade #16. Serie nummer SGI802003T SGI802002K DEH90717SL DEH913196J
Productnaam HP StorageWorks SB40c HP StorageWorks SB40c HP StorageWorks SB40c HP StorageWorks SB40c
Server Blade nummer Server Blade #1 Server Blade #9 Server Blade #15 Server Blade #7
In de Enclosure zitten 2 intern L2/L3 switches Serie nummer MY38241V67 MY38231ULF
Productnaam HP GbE2c Layer 2/3 Ethernet Blade Switch HP GbE2c Layer 2/3 Ethernet Blade Switch
39
Cisco ASA 5510 Transparante Firewall Voor de internet edge is de beste oplossing een firewall appliance. Dit omdat we de publieke range niet geheel tot onze eigen beschikking hebben. De ASA5510 is als Transparant Firewall als Laag 2 device tussen de Publiek Internet router en edge servers geplaats. De Edge servers die achter de firewall staan hebben gewoon een Publiek IP nummer uit dezelfde range als daarvoor. De Config van de transparante Firewall is als bijlage bij dit document toegevoegd. Serie nummer JMX1318L0TE
Productnaam Cisco ASA 5510
Cisco 2621XM Layer 3Router/Firewall Aan de andere kant hebben we een Layer3 als internet Edge, deze dient als site-2-site aes ipsec verbinding naar het demolan, en doet verschillende NAT translaties naar oa, de Groove relay servers. TMG L3 Firewall Achter de transparant firewall staat de TMG Firewall, deze firewall word oa gebruikt voor remote ipsec vpn verbindingen, publisheren van de interne website binnen I-Bridge . Voorbeelden hiervan zijn de Sharepointportal, webmail en de PKI infrastructuur. ADDS/DNS Intern Server CA PKI Server DNS Perimeter Server WSUS Server Minimum eisen werkplekken Hardware De I-Bridge werkplekken hebben de volgende hardware eisen Laptop computer met microsoft Vista hardware requirements Snelle graphic card met Hoge resulutie Mobile Internet Connecties Software Microsoft Windows Vista of Microsoft windows 7 Microsoft Office 2007 Enterprise (Inc Groove Client) Microsoft Office communicator2007 R2 Client Sophos Antivirus Microsoft Live Meeting Fysiek netwerk Verbindingen naar externe netwerken Het I-Bridge netwerk is direct aangesloten op het internet. Het heeft een ontsluiting met internet via 1 transparante firewall of 1L3 firewall. Achter de transparante Firewall worden public IP addressen gebruikt en achter de L3 firewall worden Private IP addressen gebruikt. Achter de firewalls is een perimeter netwerk waarin de Edge servers zich bevinden.De servers zijn speciaal gehardened via Microsoft Forefront Firewall Software. Er is een verbinding via de Cisco wave router publieke PSTN netwerk deze router is strak beveiligd en valt in een intern netwerk, zodat er geen verkeer vanuit het internet mogelijk is richting deze router. Verder is er geen enkele andere koppeling naar een extern of publiek netwerk binnen de I-Bridge infrastructuur. Active Directory Service and DNS (IST situatie) Single Domain Model Er is gekozen voor een single domain model binnen het Innovatie Project I-Bridge 2. Dit domein is ook direct het forest Root domain. Dit heeft de volgende voordelen Elke domein controller kan elke gebruiker authenticeren in de forest.
40
We hebben maar 1 domain controller nodig, deze is ook global catalog server. Eenduidig en snel te implementeren. Dit heeft de volgende nadelen Alle domain administrators hebben altijd ook master rechten in de forest. Wanneer er trusts gemaakt moeten worden met andere domains zal deze minder beheersbaar zijn. DNS Split DNS Configuratie Er is gekozen voor een split DNS oplossing: dezelfde Domein benamingen worden zowel intern als voor de externe PoCs gebruikt. Het voordeel is dat overal dezelfde suffix gebruik kan worden, of je nu met VPN of rechtstreeks van buiten af bent ingelogd op de omgeving. In de perimeter zone is een ‘caching only’ DNS server geplaatst, zodat niet alle servers door de firewall met het trusted gedeelte hoeven te communiceren als men een DNS lookup wil doen. De chached DNS server communiceert met de internet DNS root servers en functioneert intern als data Vlan en heeft de DNS server in het perimeter netwerk als forwarding adres onder DPOS.EU NTP Een belangrijke eis in het project is dat alle apparatuur dezelfde tijdregistratie heeft. Dit in verband met de kernfunctionaliteit ‘verslaglegging’. Dit is gerealiseerd met het NTP protocol, waarbij de Cisco Border Router als NTP master is geconfigureerd. De ESX servers zijn NTP client en distribueren de juiste tijd naar de virtuele machines. Dit omdat juist bij virtual machines de tijd nog wel eens kan afwijken, wat met het NTP protocol wordt voorkomen. Alle overige apparatuur is geconfigureerd als NTP client. Beveiliging Netwerk niveau Op netwerk niveau is de beveiliging als volgt. Er wordt gebruik gemaakt van VLANs, er wordt slechts 1 subnet per vlan gebruikt. Er wordt gebruik gemaakt van een 3-tier firewall topology: de interne netwerken hebben geen directe internet verbinding. Om het interne netwerk te komen vanaf het internet, moet een aanvaller drie verschillende soorten firewalls penetreren. External perimeter netwerken en het intern perimeter netwerk is gescheiden door een Microsoft Forefront firewalls en edge servers Het internet en het perimeter netwerk is gescheiden door een Cisco IOS of ASA transparante firewall Voor beheer wordt gebruikt gemaakt van een speciaal subnet in een apart vlan, dit is alleen te bereiken via een remote VPN verbinding welke IPsec gebruikt. Het remote DEMO Lan is met een speciale site-to-site IPSEC vpn gekoppeld aan het I-Bridge netwerk. Het netwerk komt uit in het private perimeter network. OS niveau Microsoft windows Edge servers hardened volgens Microsoft security baseline documentation. Voip Gateways worden geharded dmv laag 3 en laag 4 Access controll list en packets filters, alleen geconfigureerde devices kunnen gebruik maken van de telefoonlijn naar buiten. Applicatie niveau Nader te bepalen, zie ander kernfunctionaliteiten Database niveau Nader te bepalen, zie ander kernfunctionaliteiten Standaard Virtuele Server Configuratie Windows Server 2003 x86 Diskindeling C-System (minimaal ? GB) D- Application/Data (minimaal ? GB) E- Logs (minimaal ? GB) Minimaal Intern Geheugen Standaard opties Windows Server 2003 x64 Diskindeling
41
C-System (minimaal ? GB) D- Application/Data (minimaal ? GB) E- Logs (minimaal ? GB) Minimaal Intern Geheugen Standaard opties Windows Server 2008 x64 Diskindeling C-System (minimaal ? GB) D- Application/Data (minimaal ? GB) E- Logs (minimaal ? GB) Minimaal Intern Geheugen Standaard opties
42
9.
Bijlage 2: Uitleg Gefedereerd Identiteit Management (FIM)
Gefedereerd Identiteit Management (FIM) is een methode om acties herleidbaar te begeleiden binnen dynamische samenwerkingsverbanden. Gefedereerd Identiteit Management (FIM) en Identity Access Management (IAM) raken elk onderdeel van elke organisatie. Het basisidee is simpel: je geeft hen die je wilt, toegang tot de spullen en informatie die zij nodig hebben en je ontzegt die toegang aan derden. Hiervoor moet je zeker weten wie, wie en wat, wat is (identiteit) en pas toegang verlenen als ze door de geautomatiseerde ballotage zijn gekomen (access). FIM is het vermogen om de identiteiten die de ene organisatie accepteert, ook te laten vertrouwen door een andere organisatie. Hierdoor kan worden aangenomen dat medewerkers, afnemers en toeleveranciers ook zijn wie ze claimen te zijn. Hierbij wordt een set specifieke gegevens gekoppeld aan een (rechts)persoon, die zo kan worden onderscheiden van andere (rechts)personen. De set specifieke gegevens die nodig is om een (rechts)persoon uniek te identificeren hangt af van de context. Zo is er een BSN nummer voor burgers, een RSIN nummer voor bedrijven, of het KvK-nummer, of soms nummers voor specifieke beroepsgroepen, zoals bij Advocatenregister, BIG, UZI, of codes voor specifieke machines (TDM, LEI). Vervolgens wordt het geïdentificeerde en geautoriseerde subject of object gecontroleerd toegang gegeven tot een fysieke of virtuele omgeving, waar zij hun rol verder vervullen. Alleen, of met derden. Elke entiteit in het netwerk van onderlinge relaties in een keten kan heel goed een ogenschijnlijk eenduidige code op een eigen manier hebben geïnterpreteerd; heeft ooit zijn eigen beslissingen genomen in hard- en software keuze (pasjes, tokens etc.) enzovoort. Er zal daarom een ICT infrastructuur aan ten grondslag moeten liggen en alle actoren zullen ook toegang moeten hebben tot het digitale domein, om tot toegang verlening en datadeling over te gaan. De IST realisaties van I-Bridge hebben aangetoond dat een dergelijke benadering werkt. Zij het met de inzet van de traditionele aanpak om identiteit te garanderen met PKI Overheid. Een tussen(rechts)persoon, ook wel bekend als de “identity service provider” die de identiteit van een mens of object A bevestigt in naam van de ontvangende partij B. Dit alles volgens een proces waarbij de identiteit service provider de risico’s zoveel mogelijk probeert te minimaliseren en de efficiëntie probeert te optimaliseren door de uitgifte van een complex geheel van digitale certificaten die bijvoorbeeld wiskundig bevestigen dat een persoon is wie hij zegt dat hij is, in zijn betreffende rol en met de daarbij behorende rechtenstructuur. Onderstaand figuur toont dit model:
Bekende voorbeelden van het simplistische Trusted Third Party model vindt men in het dagelijks leven in SAML 2.0 gebaseerde oplossingen, zoals Microsoft ADFS 1.0 and 2.0, bij oAUTH 1.0/2.0 gebaseerde web authenticatie diensten zoals Google login, Instagram, Facebook, Salesforce.com, Windows live (Hotmail, Messenger, Xbox), Dropbox, Flickr, LinkedIn, Myspace, Twitter en Yahoo! en
43
bij OpenID web authenticatie oplossingen zoals gebruikt door Facebook, Google, Microsoft, PayPal, Symantec, Yahoo en Ping Identity. I-Bridge gebruikt PKI Overheid.
De reden dat de traditionele technieken hier worden benoemd is om het verschil aan te tonen met gefedereerd identiteit management. Traditionele PKI gaat nog niet ver genoeg. Om toegang tot zaken te kunnen verlenen aan een mens of een object, moeten zeker vier aspecten worden geadresseerd: authenticatie (wil of wat wil toegang), autorisatie, (mag hij of het toegang krijgen), het feitelijke toegang verlenen, ofwel tot een fysieke ofwel tot een virtuele wereld en het administreren van die toegang voor zowel audit als accountancy redenen. Authenticatie, Autorisatie, Access en Audit: samen de 4 A’s. En dan nog zegt dit niets over de zekerheden die gebruikers willen dat hun communicatie partners zich daadwerkelijk aan redelijke technische, operationele en juridische veiligheidsnormen hebben gehouden. Is de autorisatie van een mens of machine wel afgegeven volgens de regels en herleidbare procedures? Iemand kan wel een pasje bezitten, maar wie zegt dat dat echt is? Iemand kan claimen vanaf een machine te werken, maar is dat ding niet gehackt? Dergelijke overwegingen voor ‘echte authenticatie’ riep op tot verfijning zoals het Open Identity Trust Framework (OITF) dat uitgaat van een zeker basis niveau van transparantie, herleidbaarheid en open competitie tussen aanbieders. Naast de logische reden dat het traditionele model niet zo heel veilig meer is, is er ook een economische reden: de traditionele driehoeksverhouding is niet schaalbaar in netwerken van grote aantallen ketenpartners, uittredende en bijkomende deelnemers en gebruikers die geen manier hebben om iets zinnigs te zeggen over de technische, operationele en juridische instellingen van ‘de anderen’. Het I-Bridge programma leert dat hier een uitdaging ligt. Om ketens schakel na schakel bilateraal uit te discussiëren levert onbetaalbare besluitvormingskosten. Echt vertrouwd samenwerken in de complexe, dynamische netwerken die waardeketens inmiddels zijn is complex. Mede daarom plegen legacy organisaties zich meer te richten op autorisatie, dan op de authenticatie en audit aspecten van toegang verlening. Zij zijn hiermee onvoldoende flexibel om in te spelen op de dynamiek van een moderne samenleving in een crisissituatie. Dit komt omdat het op het eerste gezicht eenvoudiger is om toegang te bieden tot een systeem of object, dan om grip te krijgen op het gehele proces waarmee je vaststelt of die toegang eigenlijk wel verleend mag worden. Elke fout in de verificatie van de identiteit schaadt de kwaliteit van de toegangscontrole op onrepareerbare wijze. De kosten van dit hiaat worden steeds groter. Het duurt niet lang meer voor overheden elkaar boetes op zullen gaan leggen voor datalekkage. Zonder adequate administratie, wordt onterechte toegang tot objecten of informatiemiddelen niet opgemerkt en is verbetering van het proces en herstel van schade achteraf niet mogelijk. Een volgende generatie I-Bridge zal integraal alle vier de A’s moeten adresseren: Authenticatie, Autorisatie, Access en Audit. Het OITF levert hiervoor de benodigde checks & balances tussen de verschillende actoren: gebruikers, identiteit leveranciers en content partijen. 9 Dit levert een complexer, maar veel stabielere architectuur met politieke steun op.
9
De Amerikaanse National Strategy for Trusted Identities in Cyberspace legt al een sterke nadruk op het toch vooral incorporeren van robuuste privacy bescherming in systeem ontwerp. (Schwartz, 2011)
44
Met een helder identificeerbaar niveau van ‘zekerheid’, de “Level of Assurance” (LOA) waaraan een identiteit service provider moet voldoen om vertrouwen te geven in de informatie stroom die hij mogelijk helpt maken. De LOA gaat vergezeld van de “Level of Protection” (LOP), de bescherming die een ketenpartner moet kunnen bieden aan de integriteit van de datastroom. De eerste specificatie profielen voor LOA/LOP verhoudingen zijn nu verkrijgbaar op de markt, zoals blijkt uit samenwerkingsverbanden als het Transglobal Secure Collaboration Platform (www.tscp.org) waar ook Nederland in deel neemt. In plaats van zelf het wiel uit te vinden, is een markt aan het ontstaan waarin – voornamelijk Amerikaanse Federale organisaties – aanhaken bij en positie kiezen in de vier voor gedefinieerde LOA niveaus in het Identity, Credential, en Access Management (ICAM) proces, zoals neergelegd door het U.S. National Institute of Stenards en Technology (NIST). In Europa worden in hoog tempo vergelijkbare en aansluitende initiatieven ontplooid, die onder meer leiden tot nieuwe end2end beveiligde International Organization for Standardization standaarden, als 10 ISO 29115/ITU-T 24760 , anti-fraude concepten als het Kantara Initiative Identity Assurance Framework, anti document fraude programma’s als Pancras en Supply Chain Collaboration standaarden als GS1met hun wereldwijde standaarden voor herleidbare acties in transport/logistiek/gezondheidszorg. Bovenstaande inzichten zijn een bijproduct van de I-Bridge PoCs, maar waren in de IST architectuur om begrijpelijke redenen van budget, mankracht en schaalbaarheid technisch niet te realiseren. Voorgesteld wordt daarom om voor een opvolger van I-Bridge een toekomstvaste Off the Shelve FIM/IAM oplossing toe te voegen aan de proeftuin, hiermee kostbare architectuurtijd te winnen en de aandacht toe te spitsen op de organisatorische consequenties van FIM, zoals het moeten komen tot heldere rollen, policy afspraken en organisatorische proces transparantie in – tenminste – de overheid. Naast de commercial-off-the-shelve FIM/IAM oplossingen wordt tevens geadviseerd om een autorisatie middleware platform toe te voegen aan de I-Bridge proeftuin. Fysieke, logische en internet toegang ondersteunen een breed en niet zelden gemengd pallet aan authenticatie oplossingen, variërend van gebruikersnaam/paswoord, smartcards, (soft)tokens en biometrie-vormen, om toegang te helpen verlenen tot applicatie omgevingen, zoals Single Sign On (SSO)-platforms als Active Identity, Passlogix, Oracle, Microsoft en andere Active Directory ondersteunde systemen, die op hun beurt weer de verbinding aansturen naar autorisatie en transactie systemen als SAP R3, inclusief alle bijbehorende verslaglegging, alarmering en rapportage functionaliteiten. Zeker in een dynamische keten van ad hoc samenwerkende actoren uit overheid en bedrijfsleven is het niet realistisch om al die
10
ISO/IEC/ITU-T 29115 – End Entity Authentication zie ook US SP800-86-1.
45
variabelen gestandaardiseerd, gecentraliseerd en geharmoniseerd te krijgen. De reden wordt uitgelegd in de volgende paragraaf over autorisatie uitdagingen. Autorisatie: beheer van toegang controle Nu digitalisering zich tot in de haarvaten van de samenleving uitstrekt, is het mogelijk tot vrijwel alles een vorm van digitaal ondersteunde toegang te krijgen: fysiek, logisch, via het internet en offline. (denk aan USB sticks, tijdsloten etc.) Eén van de zaken die moet gebeuren is het beheer van toegang controle simplificeren en hanteerbaar maken voor de C2-organisatie die I-Bridge faciliteert. Dit houdt in een eenduidig beeld zien te krijgen van de mogelijke rollen en verantwoordelijkheden, het uitsplitsen van taken en het identificeerbaar uitsplitsen van waardevolle data transacties, life cycle management van gerelateerde gebruikers en hun rechten, rollen en verantwoordelijkheden. Dit alles over de assen van de eerder besproken 4A’s: authenticatie (is de persoon wie hij zegt te zijn), autorisatie (heeft hij het juiste menaat om toegang tot de gevraagde informatie te krijgen), access (het proces van het verlenen van feitelijke toegang tot de data) en Audit (de administratie, boekhouding, verslaglegging, logging en rapportage van verleende toegang en afgewezen toegangspogingen). Authenticatie Als I-Bridge in een volgende generatie met gefedereerd identiteit management om wil kunnen gaan, zal ze drie vragen aan ketenpartners positief beantwoord willen zien: Ben je wie je zegt dat je bent? Mag je bij de informatie die je vraagt? Kan jouw organisatie mij dat onomstotelijk bewijzen? Dit stelt hoge eisen aan authenticatie. Voor de I-Bridge PoCs was authenticatie relatief eenvoudig, omdat gewerkt werd met vooraf bekende actoren, maar die luxe bestaat vanzelfsprekend niet meer wanneer zou worden opgeschaald. In Nederland wordt je identiteit in eerste instantie bepaald door de Staat op basis van je formele geboorte registratie. Alle andere identiteit aspecten zijn hiervan afgeleid. Aangezien informatie systemen geen paspoorten hebben worden andere middelen gebruikt, zoals tokens of andere hulpmiddelen. Sleutels die sloten openen. Kaarten die in kaartlezers passen. Biometrische verificatie. SMS-verificatie. Tijdsloten. Usernaam/paswoord combinaties en wat dies meer zij. De identiteit controle gaat doorgaans vooraf aan het authenticatie besluit, maar dan moeten er wel autorisatie procedures zijn die om weten te gaan met identificatiemiddelen die verloren, verkeerd gebruikt of gecorrumpeerd zijn. Een volgende generatie I-Bridge zal die situaties automatisch moeten herkennen om geen hick-ups in het proces te krijgen. Authenticatie methoden kunnen zijn gebaseerd op een of meer van de volgende drie factoren: bezit, kennis en ‘zijn’. Wat HEB je, wat WEET je en wat BEN/DOE je?
Bezit van een sleutel Herinnering van een code Verificatie van bv je vingerafdruk Bezit en kennis en zelfs biometrie factoren laten zich (on)vrijwillig delen. Zo kunnen authenticatie factoren door hele gebruikersgroepen gedeeld worden. Een nachtmerrie vanuit veiligheid optiek. Dit maakt de diefstal van identiteit een reële bedreiging voor een digitale werk omgeving. Vooral username/password oplossingen zijn kwetsbaar voor hacken, bijvoorbeeld door het gebruik van keylog software die de toetsaanslagen doorgeeft aan derden. Ook sociale overredingskracht kan gebruikers toegangscodes ontfutselen. Mensen zijn ook niet bijster creatief met wachtwoorden, waardoor je met software ogenschijnlijk waterdichte codes snel en eenvoudig kunt breken. Het is daarom vrijwel zeker dat in een operationele situatie I-Bridge gebruikers een of meer authenticatiemethoden in combinatie zullen gebruiken. Die authenticatiemethoden zijn onderling niet gestandaardiseerd, dus een volgende generatie I-Bridge zal die vertaalslag zelf moeten maken om te kunnen omgaan met gecombineerde, gelaagde authenticatiemethoden van ketenpartners, zoals: Elk type biometrie in combinatie met een kaart en/of usernaam/wachtwoord Elk type identiteit kaart in combinatie met een PIN-code Een fysieke token in combinatie met een gebruikersnaam/wachtwoord, bijvoorbeeld van het type one time password generators (OTP) zoals banken en overheden gebruiken. Soft token gebaseerde oplossingen (SMS) in combinatie met gebruikersnaam/wachtwoord.
46
De criteria welke authenticatie methode wordt ingezet, kan per situatie verschillen en zal hoe dan ook veranderingen in de tijd kennen, omdat keuzen kunnen veranderen en techniek zich rap ontwikkelt. Aangezien auditen een integraal onderdeel is van een volwassen beveiliging concept, is vooral de betrouwbaarheid van de uitgifte van authenticatie middelen, de overdraagbaarheid en de graad van kopieerbaarheid iets waar een volgende generatie I-Bridge zich rekenschap van zal moeten geven, alvorens derden toegang te geven tot specifieke data verderop in het Gefedereerd Identiteit Management proces. De autorisatie wereld is kortom duur, veelzijdig en in zijn complexiteit voor de gebruiker irritant. Organisaties proberen daarom hun authenticatie architectuur generiek te maken met Identity Access Management (IAM) suites, die alle besproken moeilijkheden gestructureerd helpt uitwerken. Denk hierbij aan middleware oplossingen die als verloopstekker werken tussen de diverse aspecten: schaalbaar, modulair en volledig geïntegreerd met bijvoorbeeld Microsoft Windows Active Directory, open industrie standaarden als BioAPI (www.bioapi.org) en open genoeg om ook nieuwe generaties authenticatie hardware aan te kunnen. Naast een Identiteit Service Provider met bijbehorend backoffice, zou een volgende generatie I-Bridge ook een Biometrie Service Provider (BSP) moeten worden, die een vertaalslag kan maken tussen allerhande biometrie oplossingen door de standaarden te ijken aan Vector Segment Technologie (VST): een van de meest accurate en betrouwbare vingerafdruk algoritmen. Met de juiste middleware technologie zou I-Bridge 4.0 in staat zijn te interfacen met allerlei systemen van door ketenpartners mogelijk gebruikte leveranciers als Authentec, Digital Persona, Fingertech, Hyundai, L1 Indentity Solutions, Precise Biometrics, Secugen, Startek, Tacoma technology Inc., Targus, UPEK, Zvetco, maar ook met niet-biometrische fysieke systemen als smartcards, flashdrivers, Mifare, HID iClass en andere fysieke systemen. Samengevat: door de juiste middleware te kiezen als integraal onderdeel van een volgende itteratie van I-Bridge wordt kostbare architectuurtijd en kostbare specialistische kennis bespaard en kan ook I-Bridge voort bouwen met gefedereerde dienstverlening. Denk aan concrete inzet van persoonsidentificatie met onafhankelijke verificatie (dat iemand een paspoort heeft zegt niets over het systeem op basis waarvan dat paspoort tot stand gekomen is), denk aan Legal Data labelling (dat iemand iets schrijft wil niet zeggen dat hij ook over dat onderwerp mag praten), denk aan het omgaan met variaties in encryptie en ondertekening tussen organisaties. (een laag gekwalificeerde organisatie zal nooit een hoog gekwalificeerde persoon naar voren kunnen schuiven, omdat zij nooit in staat zullen zijn om een persoon hoog te kwalificeren). De ontwikkelingen gaan erg snel. I-Bridge 3.0 is met de voorbereiding van de PoCs met deze vraagstukken in aanraking gekomen, maar een volgende generatie zal ze op moeten lossen. Claim-gebaseerde architectuur als onderdeel FIM Het opzetten van Federatieve beveiliging kent ook bij implementatie een aantal uitdagingen. Het eerste aandacht aspect is account creatie en authenticatie. Moeten de cloud accounts handmatig of geautomatiseerd tot sten komen? Handmatig heeft flexibiliteit maar is fysiek vrijwel niet te doen, maar geautomatiseerd impliceert integrale keuzes op de bedrijfsvoering, die vooralsnog niet gemaakt zijn. Komt er voor de eindgebruiker weer een nieuw login en password bij om te onthouden? Kunnen bestaande wachtwoorden over de diverse cloud omgevingen worden gesynchroniseerd? Gaan de kosten van de helpdesk toenemen? Het tweede aandacht aspect is het realiseren van rollen en het toewijzen van kenmerken aan die rollen. Hoe worden de autorisatie besluiten voor wat betreft de cloud omgeving gemaakt? Door wie worden de autorisatie besluiten voor wat betreft de cloud omgeving gemaakt? Wordt ook de autorisatie informatie handmatig ingevoerd in een afzonderlijk proces? Welke persoonskenmerken moeten in de cloud worden gesynchroniseerd? Hoe verhoudt zich dat tot de privacy wetgeving en vigerende wetgeving voor crisisn? Worden ook de onderlinge verhoudingen tussen medewerkers opgeslagen, bijvoorbeeld management gegevens om de workflow te helpen managen? Is dat een security issue? Beide aandachtsgebieden laten zich oplossen met een model gebaseerd op claims.
47
Claims gebaseerde systemen stellen de gebruikersgemeenschap in staat om te authenticeren, te authoriseren, te personaliseren en om data te ontsluiten op een manier die zich niets hoeft aan te trekken van traditionele organisatie grenzen. Een claims-gebaseerd model is daarmee een extra abstractie laag voor het authentiseren, autoriseren en het verkrijgen van informatie over gebruikers, middelen en diensten. Verderop wordt dieper ingegaan op de kenmerken, maar in het kort komt het er op neer dat een claim een stelling is, die wordt geponeerd door een subject, over een ander subject. Een dergelijke claim wordt in eerste instantie betwijfeld. Zo kunnen er checks op worden uitgevoerd die steeds beter bewijzen dat een claim ‘waar’ of ‘niet waar’ is, waarna volgende acties kunnen worden ondernomen, zoals het verlenen van toegang. Een claim kan zijn een registratienummer, een leeftijd (>21), de naam van een manager, de rol binnen de organisatie en paswoorden, tokens, certificaten en biometrische kenmerken die de aanvrager beweert te bezitten. Voor de veelheid aan legacy autorisatiebronnen is middleware verkrijgbaar die de diversiteit desgewenst harmoniseert. Zo ontstaat een generieke stekkerdoos voor de autorisatie middelen van externe partners, waar een volgende generatie I-Bridge zich nog beter zou positioneren als harmonisatie platform.
Door te kiezen voor een claim-architectuur, wordt identiteit een functie van een metasysteem: een op open standaarden (OASIS, XACML 3.0, EDXL, ADFS etc.) gebaseerde architectuur voor de uitwisseling van claims die in essentie vanuit de gebruiker zelf geïnitieerd worden. Er zijn grote voordelen te behalen door de gebruiker de controle over zijn data te geven. Door de gebruiker in te schakelen om data daar te brengen waar hij het nodig heeft, worden authenticatie en data-integratie conceptueel onder één dak gebracht.
48
Als de claims zijn bewezen kunnen mensen (of objecten, zoals deuren, auto’s, camera’s, beeldschermen) toegang krijgen tot elkaar en tot databronnen. Of ze dat ook mogen hangt af van de beveiliging afspraken en die zijn weer een afgeleide van beleidskaders, proceskeuzen, wetgeving en zelfs praktische ervaring. Het is kortom zaak deze beveiliging afspraken weliswaar robuust, maar ook flexibel te maken. Keuze voor de beveiligingsvorm De uitdagingen rond data-integratie tonen aan dat de kijk op beveiliging moet worden aangepast om te kunnen werken met Cloud gegevens en helemaal met de onvermijdelijke mix tussen Cloud gegevens en traditionele applicatie methoden. Het Internet is gebouwd zonder manieren om echt te weten met wie of wat je verbonden bent. Het gebruik beperkte zich mede hierom tot het eenzijdig publiceren van content (het maken van websites, het vullen en gestructureerd ontsluiten van databanken voor bepaalde, beperkte populaties), terwijl je nu juist ziet dat internetgebruik meer draait om interacties. De toenemende cross-disciplinaire, cross-mediale, cross-departementale, transnationale, keten brede samenwerking die I-Bridge faciliteert, meer en meer gebaseerd op Web-gebaseerde, browser en met de widget/tile/app ontsloten dienstverlening die het Virtueel Politie Korps laat zien is het gevolg.
Voor de I-Bridge zijn de vrijheidsgraden beperkt, wat extra eisen stelt aan de private Cloud en de netwerken. ‘Vertrouwen/trust’ moet optimaal blijven om een gevoel van veiligheid, privacy en zekerheid in het digitale domein te behouden. De claims moeten daarom onderdeel zijn van een bredere trust architectuur.
49
Om de I-Bridge nog beter te helpen om van user-generated content naar user-generated productivity te komen, zal er een eenduidig identiteit systeem moeten komen, dat nochtans flexibel genoeg is om de verschillende combinaties die mensen in sociale netwerken maken bij te benen. Een meta-identiteit systeem met aspecten als: Een verbod op een “ droit à l ‘oublie”, het recht om te vergeten waarom je ooit ergens mee begonnen bent: ALLE data krijgt een begin datum, een einddatum en een half waarde tijd danwel stempel van geldigheidsduur. User control en consent: de gebruiker moet er ‘ blij’ mee zijn en vertrouwen hebben Minimal disclosure for a defined use: minimale informatie voor een helder doel vrijgeven, zodat de kans minimaal is dat de identiteit van een aanvrager herleidbaar is uit de context. Justifiable parties: informatie moet alleen worden vrijgegeven om logische redenen aan duidelijk geïdentificeerde entiteiten. Directional identity: een universeel identiteit systeem moet zowel omnidirectionaal als unidirectionale elementen in kunnen zetten, zodat ook de externe gebruik kan maken van delen van het concept, maar zonder te correleren informatie vrij te geven. Een voorbeeld is een pinpasscanner. Een pinpasscanner is een publiek systeem, maar moet wel gewaarmerkt zijn. Het moet niet mogelijk zijn dat identiteit phishing mogelijk is door het contact tussen een pinpaslezer en de pinpas af te luisteren. Open technologie: je wilt niet vastzitten aan een provider. Integratie van de menselijke factor: er moet altijd menselijke tussenkomst mogelijk blijven. Consistente context vrije gebruikservaring: de ‘ single log-in’ uitdaging moet eenzelfde gebruikerservaring opleveren, waar in de cloud de gebruiker zich ook bevindt. Afhankelijk van het ambitieniveau is de beveiliging van data en personen in een dynamische omgeving een uitdaging, die nauw samenhangt met gevoel voor de risico’s wat weer samenhangt voor begrip van het economische model. Dit is geen exercitie die achteraf moet worden uitgevoerd, maar het is aan te raden de beveiligingsdiscussie gelijk op te laten lopen. Het is niet eenvoudig. Federatieve Identiteit Management gaat niet om deuren sluiten, maar om het formuleren van de situaties waarin deuren open mogen, voor hoe lang, voor wie en hoe ver ze open mogen. Het gaat om beleid, tastbaar gemaakt en ontsloten via Web services. Web services zijn er op gemaakt om robuuste, flexibele, gedistribueerde systemen te kunnen bouwen die belangrijke toegevoegde waarde hebben voor productieprocessen. Juist hun flexibiliteit stelt ze in staat om mee te wuiven met de dynamiek van de bedrijfsvoering. Zij zijn daarom bij uitstek losjes samenhangend en dat staat lijnrecht tegenover het traditionele portal denken met strakke toegangsrechten. Dit gaat veel verder dan een gestandaardiseerde identiteit dienst achter een SSL verbinding. Een digitale identiteit is gerelateerd aan context en de essentie van genetwerkte content is juist de wereld inmiddels bestaat uit duizenden vormen van content verweven in duizenden contexten. Het is vaak ook nog eens de bedoeling dat de contexten gescheiden blijven. Niemand hoeft te weten hoeveel aspecten een casus van een crisis eigenlijk heeft, of digitaal in staat worden gesteld het totaalplaatje te herleiden. De genetwerkte applicaties binnen een logisch gecentraliseerde proeftuin zullen hun gebruikers kortom alleen onder een metasysteem van identiteit management kunnen dienen.
50
Om succesvol te kunnen worden ingezet behoeft een opvolger van I-Bridge daarom een unificerend identiteit metasysteem, dat applicaties kan beschermen tegen de interne complicaties van specifieke implementaties (je mag niet zomaar alles kunnen combineren), maar dat tegelijkertijd identiteiten voor de duur van een bevraging losjes kan koppelen. Hoe meer gefedereerd de netwerken en de ketens worden, hoe moeilijker het wordt voor een rechtspersoon om de claims van een subject te kunnen evalueren. Een dienstverlenend uitgeefmodel zal, anders dan het productiemodel dat uit gesloten domeinen bestaat, integraal om moeten kunnen gaan met het bewijzen of afwijzen van de claims van de subjects. 11
De opvolger van I-Bridge zal alles in zich moeten wantrouwen. Geen identiteit van mens, machine, proces, organisatie of software onderdeel nog op face value vertrouwen. Het platform moet leren wantrouwen of data integer is, of apparaten zijn wie ze claimen dat ze zijn, wantrouwen dat verbindingen lopen hoe ze claimen dat ze lopen en wantrouwen of opgevraagde zaken relevant zijn voor de ontvanger. Niet alleen omdat het verstandig is nu al de IV zo in te richten, maar ook om alvast in te spelen op Europese regelgeving op het terrein van auditen, datalekkage boeten, verzekeringen en sensorgebruik. De IT achter de IV in de proeftuin zal een integraal meta systeem moeten worden, dat in staat moet zijn om de rationele elementen in digitale identiteiten te interpreteren vanuit een breed pallet aan mogelijke implementaties en manieren om dingen te doen. Anders dan in een traditioneel concept hoeven identiteiten niet langer uniek te zijn binnen een gegeven context. De standaardisatie benadering houdt stovepipes alsnog in stand, want een dergelijke beveiliging methode is verplicht over alle contexten. Het is juist het spelen met de context dat tot real-time inzicht leidt. Het gaat er in de nieuwe situatie om dat de presentatie van claims helder gescheiden kan worden van de bewijsbaarheid van de claim in relatie tot een echt subject/object (mens, machine) in de echte wereld. Het is niet zo dat de claim de sleutel is tot toegang. Of de sleutel daadwerkelijk gegeven wordt en een deurtje opengaat en een functie vrijkomt voor gebruik of informatie vrij komt voor inzage, hangt af van de evaluatie van de claim in de context die wordt aangevraagd. Het zou heel goed kunnen dat de validatie van een claim slechts leidt tot een volgende laag uitdagingen (challenges) om dieper de context in te komen. Om een dergelijke uiterst robuuste, maar toch flexibele omgeving op te kunnen zetten, moeten de uitgangspunten volkomen transparant zijn. Een voorwaarde die vraagt om een benadering van architectuur met Business Process Management Modelering om alle variabelen, hanteerbaar te kunnen kneden. i
Persistent Identity Als overeenstemming gevonden is dat op basis van de maatschappelijke trends i-Bridge zou moeten bijdragen 11
Een digitale identiteit is een set claims die een digitaal subject over zichzelf maakt of die een digitaal subject over een ander digitaal subject maakt. Een subject is een persoon of zaak/ding waarover kan worden gesproken, dat kan worden beschreven en waarmee kan worden geïnteracteerd. Een digitaal subject is hiermee een persoon of ding dat wordt gerepresenteerd in een digitale omgeving, waarna het kan worden beschreven en waarmee kan worden geïnteracteerd. Vele van de besluitvorming die machines afhandelen binnen netwerken zijn het resultaat van een of andere communicatie over en weer tussen een ‘ initiator’ of ‘ requester’ en een digitaal subject. Dat kunnen mensen zijn, maar ook computers of devices als printers, dan wel bestanden of beschreven checklists met beleid en gewenste relaties tussen het ene subject en andere subjecten. Een (digitaal) subject is een centrale substantie of kern en kan daarmee worden losgezien van zijn attributen. Het zijn de attributen die digitaal worden neergelegd in claims. Voor een flexibel, maar robuust identiteit beheer is het nu zoeken naar een entiteit die zowel om kan gaan met het ‘ ding’ (mens, object) als met de claims die het maakt, in relatie tot de context waarin zij gemaakt worden. Een claim is een bewering over de waarheid van iets, maar doorgaans wel iets waaraan getwijfeld mag worden of waarover tegenstrijdige beweringen gemaakt worden. Een claim kan een naam of nummer zijn. Een claim kan de bewering zijn dat het subject iets weet, is of fysiek bij zich heeft en hij moet in staat zijn dat feit te demonstreren. Een combinatie claims kunnen een individu identificeren door bijvoorbeeld naam, adres, woonplaats en geboortedatum te kunnen overleggen. Een claim kan zijn dat het subject beweert tot een specifieke groep te behoren. Een claim kan inhouden dat het subject stelt bepaalde rechten te hebben, bijvoorbeeld om een specifiek bestand te mogen inzien of wijzigen.
51
aan ‘user generated productivity’ dan volgt hier de business case voor het concept van Persistent Identity uit. Net als op het bredere internet gaan federatieve netwerk identiteiten de komende jaren gemeengoed worden. Denk aan het generieke Skype nummer of Twitter adres waarmee een individu over allerlei netwerken te vinden is, maar ook aan een Microsoftdienst als Passport en OpenID waarmee allerlei diensten met een eenduidige identificatie kunnen worden benaderd. De Persistent Identity is te zien als een digitaal profiel dat de interesses en zorgen van een individu representeert binnen de context van - in dit geval – de crisismanagement omgeving. Een aspect hiervan is dat de eindgebruiker een hoge mate van autonomie moet hebben hoe zijn of haar profiel wordt gebruikt. Zo zou het profiel affiniteiten en capaciteiten moeten kunnen weergeven, maar bijvoorbeeld ook (indien van toepassing) aanwezigheid, uurtarief of wellicht zelfs actuele fysieke locatie. Een dergelijk profiel draagt bij aan het geautomatiseerd vinden en matchen van collega’s die vergelijkbare belangen delen. Om tot een dergelijke Persistent Identity te kunnen komen (die dus over alle ICT heen gedeeld moet kunnen worden, anders blijf je in de stovepipe structuur zitten) moeten introductieprotocollen worden doorlopen. Hiertoe is het noodzakelijk om een besluit te nemen over interoperabiliteit protocollen die de communicatie moeten verzorgen tussen de management databanken die de ledenprofielen beheren en de verschillende online communitie infrastructuren, opdat de betrokken informatiestroom tot stand kan komen. Hierbij zijn ook modulaire applicaties nodig die op het meest efficiënte moment en op de meest efficiënte manier ‘ pre-processing en post-processing’ acties kunnen uitvoeren, zoals het ‘ alvast op locatie zetten’ van grote bestanden of het ‘ archiveren’ van handeling. Hier ligt een nauwe relatie met het e-depot gedachtengoed, omdat data zal moeten worden samengesteld, geadresseerd en getagged. Die verfijnde handelingen die transparantie van de data vooronderstellen en daarmee een heldere visie op het content management, maken het vervolgens mogelijk dat specifieke gebruikers, specifieke informatie tijdig en op de juiste wijze krijgen voorgeschoteld. In termen van kennismanagement, kennisbehoud en validatie van de input van individuele gebruikers ontstaan zo interessante nieuwe mogelijkheden, zoals de implementatie van Reputatie Management, gebaseerd op context en business rules binnen de specifieke community. Je zou bijvoorbeeld eenvoudig kunnen herleiden welke inzichten van welk persoon doorslaggevend zijn geweest voor beeldvorming, afgezet tegen de succesrate, bijvoorbeeld op basis van semantische analyse (hoe vaak is de man gequoot? Dan is hij authoriteit). Matching Technologie De huidige netwerk architectuur leunt in het gebruik sterk op zoekmachines, maar als i-Bridge zo zou kunnen worden ingericht dat data transparantie een bouwvoorwaarde is, dan is ook hoogwaardiger matching mogelijk geworden, waaronder de inzet van ontologieën en taxonomieën gebaseerd op standaarden als XML en RDF, waardoor eenzelfde set aan data vanuit verschillende perspectieven benaderd kan worden. Data ontsluiting Om een robuuste, maar veerkrachtige data ontsluiting op te zetten is het volgende nodig:
Commodity hardware – betaalbare, eenvoudig verkrijgbare en snel installeerbare hardware die zich niet leent als single point-of-failure afhankelijkheid van de grote commerciële spelers.
Diversiteit van routes en protocollen. Hoe meer wegen naar Rome kunnen leiden, hoe minder vatbaar I-Bridge is voor virus aanvallen en privacy kwesties.
Elk knooppunt moet in principe in staat zijn om alle rollen te vervullen. Dit hoeft niet te betekenen dat elk knooppunt dezelfde rol heeft, maar het zou kunnen. De designrule is samen te vatten dat het kleinste gedistribueerde netwerk zou kunnen bestaan uit één knooppunt.
Het network moet ‘latency tolerant’ zijn, want de enige manier om afstanden te overbruggen tussen A en B is het maken van netwerk tussenstappen en die kosten altijd tijd: latency is dus een fact of life maar dan moet je geen zaken die serverbased werken vereisen waar dat niet hoeft.
I-Bridge zou moeten gaan werken met helder gedefinieerde algoritmen (waarschijnlijk geoperationaliseerd over geografische redundantie) en bijbehorende reset mechanismen hebben voor het geval kritische data verloren dreigt te raken. (zo kunnen DNS bestanden gecorrumpeerd raken als de verkeerde knooppunten in de verkeerde combinaties onderuit gaan en als zoiets een systeempunt zwakte is, dan is juist een dergelijke infrastructuur een aanvalsdoel voor hackers.)
Ook de consistentie van data moet integraal bewaakt worden. In hoeverre zijn bijvoorbeeld kopieën gelijk in de tijd? Bij een verstoord netwerk ontstaan als snel reparatiepunten die verschillen van de master.
Veerkracht/Resilience Het menselijk lichaam is een biologisch gedistribueerd immuun systeem bestaande uit complexe trust verhoudingen binnen een integraal netwerk. De randen van dat netwerk worden streng bewaakt tegen integriteit inbreuk (dynamic whitelisting: witte bloedlichaampjes vallen alle cellen/data aan die ze niet als lichaamseigen (h)erkennen). Mocht een beschermingsvorm beschadigd raken, dan nemen ander functies de rol over. Indringers in het trusted interne systeem zijn onmiddellijk identificeerbaar en uitschakelbaar. Het door ontwerp van i-Bridge moet daarom vanaf de tekentafel rekening houden met misbruik en gebouwd
52
worden met de gedachte aan moduleerbare quarantaine gebieden. Meer informatie over deze denklijn is te vinden op sites als het http://www.openmeshproject.org/
53
