Betrouwbaarheid berichten uitwisseling op basis van Message Queuing

Transcriptie

1 23 Betrouwbaarheid berichten uitwisseling op basis van Message Queuing Martine van Dijk en Ronald Holsbeeke Message Queuing (communicatie op basis van berichtenverkeer) is een manier om applicaties aan elkaar te kop pelen zodat ze gegevens kunnen uitwisselen. De gegevens worden uitgewisseld door het versturen en ontvangen van berichten via voorgedefinieerde communicatie kanalen, queues genoemd. Binnen organisaties wordt message queuing veelal toegepast om nieuwe applicaties te koppelen aan bestaande mainframeapplicaties. Een voorbeeld is een financiële instelling die een elektronische betalingsapplicatie wil koppelen aan het transactieverwerkende systeem dat op het mainframe draait. Het doel van dit artikel is inzichtelijk te maken: welke risico s ontstaan als organisaties message queuing gebruiken; welke maatregelen het message queuing-product (van IBM) tegenover deze risico s stelt; en welke aanvullende maatregelen de organisaties die message queuing gebruiken kunnen nemen om de risico s te beperken. Inleiding Message queuing verzorgt communicatie tussen applicaties op basis van berichtenuitwisseling. Tussen de applicaties en de platforms waarop deze applicaties draaien wordt een softwarelaag gevoegd, het message queuing-systeem, dat de berichtenuitwisseling verzorgt. Message queuing onderscheidt zich van andere communicatievormen door het asynchrone karakter; applicaties die gegevens met elkaar uitwisselen hoeven niet gelijktijdig actief te zijn. Dit is mogelijk doordat het message queuing-systeem het verzenden van een bericht combineert met de tijdelijke opslag van het bericht in een queue buiten de verzendende Drs. M. van Dijk RE en R.A. Holsbeeke RE RA zijn werkzaam bij Fortis Audit Services/ICT Audit. applicatie (zie figuur 1, p. 24). Na overdracht van het bericht aan het message queuing-systeem is alleen de beschikbaarheid van dit systeem als tussenstation en als brievenbus noodzakelijk. De verzendende applicatie kan vervolgens andere werkzaamheden uitvoeren en hoeft niet te wachten op een reactie van de ontvanger. Het message queuing-systeem biedt het bericht aan het platform van de ontvangende applicatie aan. Het verschil tussen synchrone en asynchrone communicatie is vergelijkbaar met het verschil tussen telefoneren en het versturen van een brief. In het eerste geval spreken beide partijen tegelijk met elkaar om hun zaken af te handelen. In het geval van een brief wordt het bericht opgepakt als het prioriteit heeft en op het moment dat het goed uitkomt. Bij het gebruik van message queuing zijn uit het oogpunt van beheersbaarheid, enkele kanttekeningen te plaatsen. Indien applicaties met elkaar communiceren door middel van message queuing vindt de gegevensuitwisseling en verwerking niet plaats in één sessie (zie figuur 1). Vanwege het asynchrone karakter vinden achtereenvolgens gespreid in de tijd de volgende gebeurtenissen plaats: het verzenden van het bericht door A, de opslag in de queue, het transport van het bericht en vervolgens de ontvangst en verwerking van het bericht door B. Het message queuing-systeem voorziet in principe niet in terug koppeling over het transport, de ontvangst en

2 24 de EDP-Auditor nummer Middleware is een verzameling softwarefunctionaliteiten waarmee toepassingsapplicaties gegevens met elkaar kunnen uitwisselen, zonder dat in deze applicaties rekening gehouden hoeft te worden met technische low level -aspecten 1, zoals bijvoorbeeld platformafhankelijke communicatieprotocollen, verschillen in databaseomgevingen en datarepresentatie. Middleware is een softwarelaag die boven het besturingssysteem maar onder de applicatie ligt. Dit wordt schematisch weergegeven in figuur 2. De eerste laag, het platform, wordt gevormd door de Figuur 1. Basisprincipe message queuing Machine A Machine B Machine C verwerking van het bericht. De vraag is dan hoe vastgesteld kan worden dat een betrouwbare uitwisseling en verwerking van gegevens tussen A en B heeft plaatsgevonden. Het doel van dit artikel is een inventarisatie te geven van risico s en mogelijke maatregelen die als uitgangspunt kan dienen bij de beoordeling van de betrouwbaarheid van de gegevensuitwisseling tussen applicaties met behulp van message queuing. In dit artikel wordt van IBM als voorbeeld en uitgangspunt genomen. is een veel gebruikt product dat message queuing-diensten levert. Achtereenvolgens wordt behandeld: definiëren van message queuing als specifieke verschijnings vorm van een tweetal andere begrippen; middleware en berichtencommunicatie; uitleg van de werking van message queuing aan de hand van enkele objecten; definiëren van risico s en maatregelen die een rol spelen indien message queuing in een bedrijfssituatie wordt toegepast. Message queuing als verschijningsvorm van middleware Na introductie van message queuing in het vorige hoofdstuk, zal hieronder verder worden ingegaan op een aantal karakteristieken van message queuing. Dat doen we door message queuing als specifieke verschijningsvorm te zien van een tweetal andere begrippen, te weten middleware en berichtencommunicatie. Bovendien zal kort worden ingegaan op de componenten van een message queuing-systeem. Om het concept van message queuing goed voor het voetlicht te kunnen brengen, is het belangrijk eerst kort in te gaan op de algemene kenmerken van middleware. Laag 1: gedistribueerde applicaties Z/OS Mainframe Laag 2: Middleware Laag 3: Hardware & OS Unix Sun Netwerk Figuur 2. Positie van middleware in een gedistribueerde omgeving Windows NT Dell ge bruikte hardware en het besturingssysteem (in figuur 2 aangeduid als besturingssysteem). De derde laag bestaat uit de toepassingsapplicaties. De tweede laag, de middleware, is het geheel aan standaardinterfaces en protocollen dat de applicaties onafhankelijk maakt van het gebruikte hardware- en softwareplatform. Het gebruik van middleware (en zijn populariteit) is verklaarbaar aan de hand van twee karakteristieken waarmee (IT-)organisaties zich geconfronteerd zien. In de eerste plaats is dat de heterogeniteit van de infrastructuur en de gebruikte platforms. Deze heterogeniteit bemoeilijkt het koppelen of integreren van applicaties die op de verschillende platforms operationeel zijn. Op de tweede plaats speelt de behoefte van ontwikkelorganisaties om platformonafhankelijke applicaties te kunnen bouwen. Dit vermindert de complexiteit van het ontwikkelproces, vergroot mogelijk de markt voor een applicatie, en maakt de portabiliteit van de applicaties veel eenvoudiger. Message queuing geeft invulling aan deze platformonafhankelijkheid. Om een koppeling met andere applicaties tot stand te brengen heeft een applicatie een interface naar het message queuing-systeem, dat vervolgens het transport en de aflevering van het bericht verzorgt. De applicatie hoeft geen codering te bevatten om de communicatie over het netwerk en de communicatie met de ontvangende

3 25 applicatie te regelen. Dit is een voordeel uit oogpunt van ontwikkeling en beheer dat toeneemt naarmate het aantal onderling communicerende applicaties toeneemt en deze op uiteenlopende technieken zijn gebaseerd. Message Queuing als verschijningsvorm van berichtencommunicatie Bij de implementatie en het beheer van message queuing (en de beoordeling daarvan) krijgt een organisatie te maken met een aantal vraagstukken die voortvloeien uit het specifieke karakter van berichtencommunicatie. We typeren berichtencommunicatie in eerste instantie als de (ogenschijnlijk) simpele situatie, waarin twee of meer applicaties berichten met elkaar uitwisselen. Die berichtenuitwisseling is noodzakelijk omwille van de functionaliteit die de applicaties aan hun gebruikers bieden, bijvoorbeeld bij het doorsturen van berichten tussen een orderinvoer- en een orderverwerkende applicatie. Elk van de applicaties is operationeel op een platform (de combinatie van onderliggende infrastructuur en besturingssysteem). Voorzover de applicaties niet op hetzelfde platform operationeel zijn, zorgt een tussenliggend netwerk voor de koppeling tussen de platforms. Op basis van dit eenvoudige voorbeeld kunnen nu verschillende communicatievormen worden onderscheiden, die samenhangen met een combinatie van de volgende factoren. Synchroniciteit Synchroniciteit zegt iets over de mate waarin een zendende applicatie voor zijn werking afhankelijk is van de daadwerkelijke ontvangst en verwerking van het bericht door de ontvangende applicatie. Bij asynchrone berichtencommunicatie kan de zender direct na het verzenden van het bericht verder gaan met andere activiteiten. Het bericht wordt opgeslagen in een lokale buffer. In het geval van synchrone communicatie is de zendende applicatie geblokkeerd totdat het bericht is ontvangen door de ontvangende applicatie, of zelfs werkelijk is afgeleverd aan de ontvanger. De sterkste vorm van synchrone communicatie is wanneer de zender is geblokkeerd totdat de ontvanger het bericht heeft ontvangen en verwerkt. Vergankelijkheid Vergankelijkheid zegt iets over hetgeen er met een bericht gebeurt indien het bericht niet kan worden afgeleverd aan de ontvangende applicatie. Er kan hier sprake zijn van persistente (aanhoudende) berichtenuitwisseling, of van transient (vergankelijke) berichtenuitwisseling. In het eerste geval zal een verzonden bericht opgeslagen worden totdat de ontvangende applicatie beschikbaar is en het bericht afgeleverd kan worden. Bij transiente berichtencommunicatie zal het bericht vervallen als het niet kan worden afgeleverd bij de ontvangende applicatie. Bij gebruik van message queuing zijn deze factoren vanuit beheersoogpunt essentieel. Message queuing is te categoriseren als persistent asynchrone berichtencommunicatie. In figuur 3 hebben we persistent asynchrone communicatie vergeleken met transient synchrone communicatie. In het geval van persistent asynchrone communicatie, dat is weergegeven in figuur 3(a), wordt een bericht opgeslagen in een buffer op de lokale host of op de communicatieserver. Applicatie A en B kunnen onafhankelijk van elkaar opereren. Figuur 3(b) geeft transient synchrone communicatie weer, de zender A is geblokkeerd totdat het een antwoord ontvangt van de ontvangende partij B. Deze vorm van transient communicatie gaat uit van simultane verwerking, de zender en ontvanger zijn allebei actief. A verzend bericht en gaat verder met andere werkzaamheden A is niet meer actief A B B is niet actief B begint en ontvangt het bericht (a) persisten asynchrone comunicatie Message queuing uitgelegd aan de hand van In de voorgaande paragraaf is uitgelegd dat message queuing een implementatie is van persistent asynchrone berichtencommunicatie tussen twee applicaties. Die persistentie en asynchroniciteit worden verzorgd door componenten van het message queuing-systeem, waarop hieronder kort wordt ingegaan. Er is hierbij gekozen voor een uitleg aan de hand van van IBM, een veel toegepast message queuing-systeem. We hebben niet gepoogd volledig te zijn; het is een beknopte beschrijving die slechts dient als illustratie bij dit artikel. Berichten Berichten bestaan uit twee delen: 1. de data die betekenis heeft voor applicaties (bijvoorbeeld een transactie); tijd A verzoek is ontvangen B Figuur 3. Persistent asynchrone communicatie A verzend verzoek en wacht op antwoord B is actief maar verricht andere werkzaamheden verzoek is geacepteerd verzoek wordt verwerkt (b) transient synchrone communicatie

4 26 de EDP-Auditor nummer applicatie A lokale queue 2. de message header die door wordt toegevoegd aan het bericht. De header bevat informatie waarmee de opslag, de routering en de aflevering van berichten gestuurd wordt, zoals de message ID, het adres van de bestemmingsqueue en het adres van de queue waar het antwoord naar verstuurd wordt. Het formaat van de header is voorgeschreven door IBM. MQPUT queue manager A MCA message channel queue manager B MCA MQGET applicatie B lokale queue Figuur 4. Werking In bovenstaand voorbeeld verzendt applicatie A een bericht naar applicatie B die zich op een remote (gekoppeld via een netwerk) computersysteem bevindt. Op beide systemen is een lokale queue manager geïnstalleerd. Ten behoeve van applicatie A is er een lokale queue voor verzending van berichten gedefinieerd (ook wel transmission queue genoemd) en voor de ontvangst is er in de omgeving van applicatie B een lokale queue die voor de te ontvangen berichten bestemd is. netwerk Queuemanager De queuemanager speelt een centrale rol in ; iedere implementatie van moet ten minste één queuemanager bevatten. De queuemanager is een programma dat het berichtenverkeer regelt door berichten op te pakken en naar de juiste bestemmingsqueue door te zenden (zie figuur 4). Applicaties roepen functies van de queuemanager aan met behulp van de Message Queuing Interface (MQI), dit zijn API calls. Zo instrueert een applicatie de queuemanager bijvoorbeeld met de MQOPEN call om een queue te openen. Met MQPUT wordt het bericht in de queue geplaatst. Deze API calls kunnen in elke taal geprogrammeerd worden, bijvoorbeeld met Cobol. De applicatie hoeft niets van de interne structuur van de queuemanager te weten. In een situatie waarin applicaties met elkaar communi ceren via message queuing zal het vaak voorkomen dat de zendende en ontvangende applicatie op verschillende computers of zelfs op verschillende platforms draaien. In de berichtenverzending spelen dan meerdere queuemanagers een rol. In dit geval moet tevens een communicatielink tot stand gebracht worden. In wordt dit gerealiseerd door message channels te definiëren tussen de queuemanagers. Hierover meer in de volgende paragrafen. Queues Queues zijn objecten die bij de installatie van gedefinieerd worden, waarin de queuemanager (namens de zendende applicatie) berichten opslaat, en waaruit de queuemanager (namens de ontvangende applicatie) berichten ophaalt. Binnen kan een queue één functie vervullen; of het ontvangen of het verzenden van berichten. verwerkt berichten op basis van het FIFOprincipe. Indien bepaalde berichten snel moeten worden verwerkt, kan hiervoor een aparte queue worden gedefinieerd die met voorrang wordt verwerkt. Berichten die niet naar hun bestemming kunnen worden gerouteerd, worden in de dead letter queue (of niet afgeleverde berichten -queue) geplaatst. Dit kan bijvoorbeeld het geval zijn als het adres van de bestemmingsqueue onjuist is. Message channels en message channel agent Een message channel is een abstractie van een verbinding op transportniveau. Het is een éénrichtingsverbinding tussen een zendende en ontvangende queuemanager, waarover berichten worden verzonden. Voor tweerichtingsverkeer (bijvoorbeeld om een antwoord te verzenden) moet een tweede message channel worden opgezet. Om een message channel tot stand te brengen wordt gebruikgemaakt van onderliggende protocollen en netwerk verbindingen. Een message channel voor een internettoepassing wordt bijvoorbeeld geïmplementeerd als een TCP/IP-verbinding. Elk uiteinde van een message channel wordt beheerd door een message channel agent (MCA). Zie figuur 3. Een MCA is een programma dat berichten doorzendt van een verzendende queue naar een communicatielink en van een communicatielink naar de bestemmingsqueue. Een zendende MCA ert zendqueues op de aan wezigheid van berichten, pakt berichten in als een transport level pakket en verzendt het pakket over de verbinding naar de ontvangende MCA. De taak van de ontvangende MCA is het oppakken van ontvangen berichten, het uitpakken van het pakket en het opslaan van het bericht in de juiste queue. Dit werkt als volgt. Met de MQOPEN call activeert applicatie A de lokale queuemanager. Nadat deze het bericht heeft geïdentificeerd, en heeft bepaald dat het bericht naar applicatie B verstuurd moet worden, zet de lokale queuemanager het bericht in de transmission queue. De MCA verstuurt het bericht over het message channel naar B. De MCA op systeem B pakt het bericht op en zet het in de lokale queue voor B. Programma B haalt met MQGET het bericht op uit de lokale queue.

5 27 De MCA wordt geactiveerd door de transmission queue een trigger te laten afgeven wanneer er een nieuw bericht in de queue zit. De zendende MCA kan de ontvangende MCA activeren door het verzenden van een control message. Om een bericht te verzenden, moeten berichten een bestemmingsadres bevatten. Een adres bestaat in uit twee delen. Het eerste deel bevat de queuemanager waarnaar het bericht verzonden wordt. Het tweede deel is de bestemmingsqueue waarnaar het bericht verstuurd moet worden. Daarnaast wordt de route die het bericht moet volgen gespecificeerd. Dit wordt gedaan door het toevoegen van de naam van de lokale transmission queue waar een bericht naar toe moet. In de vorige paragraaf is aangegeven dat elke message channel één transmission queue heeft. Door nu aan te geven naar welke transmission queue een bericht verstuurd moet worden, wordt impliciet de MCA, en dus ook de queuemanager gespecificeerd. Zoals gezegd is dit een eenvoudig voorbeeld. In het geval dat applicatie B ook berichten aan applicatie A terug dient te sturen, moeten daarvoor een apart message channel en aparte queues worden gedefinieerd. Message Broker Bij grote gegevensverwerkende instellingen, zoals banken en verzekeraars, zal het in de praktijk zo zijn dat meerdere applicaties door middel van message queuing aan elkaar gekoppeld worden. Hierdoor kan het aantal queues snel groeien. biedt een aantal mogelijkheden om in die situatie het systeem beheersbaar en onderhoudbaar te houden. Ten eerste kan onderscheid maken tussen de logische verbinding (op applicatieniveau) en de technische verbinding (dit betreft de technische componenten op de OSI-transportlaag zoals servers, hubs en netwerk). Een logische verbinding kan gebruikmaken van meerdere technische verbindingen. Daarnaast kunnen meerdere logische verbindingen gebruikmaken van één technische verbinding. Een voordeel van de ontkoppeling van de technische en logische verbinding is dat gewerkt kan worden met aliasnamen voor queues en queuemanagers. Aliasnamen worden gebruikt om te voorkomen dat de technische namen van queues en queuemanagers in de applicatie-interface naar worden opgenomen. Omdat de aliasnamen onafhankelijk zijn van de onderliggende fysieke infrastructuur, hoeft de applicatie interfaces niet aangepast te worden als de technische adressering van een queue of queuemanager wijzigt. Daarnaast zal de beheerorganisatie er naar streven het aantal technische verbindingen te minimaliseren. Om dit te kunnen bereiken kan een centrale message broker ingericht worden. De message broker staat centraal in de infrastructuur en heeft slechts één technische verbinding met elk ander platform. In figuur 5 wordt het principe van een message broker verder uitgewerkt. De logische verbinding tussen applicaties worden via de technische infrastructuur met een message broker gerouteerd. Dit kan betekenen dat een logische verbinding tussen twee applicaties gebruikmaakt van meerdere technische verbindingen. Architectuur met directe verbindingen Applicatie 1 Applicatie 4 Applicatie 1 Applicatie 2 Applicatie 3 Figuur 5. Message Broker Applicatie 5 Applicatie 6 Applicatie 2 Applicatie 3 Message broker Kwaliteitsaspecten message queuing aan de hand van een voorbeeld Architectuur met message broker In dit hoofdstuk zal aan de hand van algemene kwaliteitseisen worden beschreven, welke maatregelen biedt om aan deze eisen te beantwoorden en tevens in welke maatregelen niet voorziet, en waarvoor dus additionele maatregelen nodig zijn. Helderheid hierover is belangrijk, omdat een verkeerde inschatting van de services die biedt, de organisatie potentieel aan risico s blootstelt. Wij hebben in de praktijk bovendien gezien dat zowel de IT- als de gebruikersorganisatie soms een te rooskleurig beeld heeft van de maatregelen die op het gebied van controls levert. Kwaliteitsaspecten We gaan bij de beoordeling van message queuing uit van de volgende kwaliteitsaspecten 2 : Integriteit (vertaald naar: juistheid, volledigheid, tijdigheid) Exclusiviteit Controleerbaarheid Continuïteit Beheersbaarheid De eisen die aan de kwaliteitsaspecten worden gesteld en de daaruit voortvloeiende maatregelen, hangen af van de context en aard van de gegevenuitwisseling. Hoe strikt of soepel de eisen behoren te zijn, is niet zomaar te zeggen; Applicatie 4 Applicatie 5 Applicatie 6

6 28 de EDP-Auditor nummer Online Bankieren Handmatige invoer 1 Applicatie Betalingsverkeer (windows) dat wordt immers bepaald door het belang van de (bedrijfs)processen waarin deze berichtencommunicatie wordt toegepast. In deze paragraaf gaan we uit van het voorbeeld van de verwerking van een betalingsopdracht door een financiële instelling. Voorbeeld betalingsopdracht Een internationale betaling wordt verwerkt via het Swiftnetwerk, een wereldwijd netwerk tussen banken en financiële instellingen voor het verzenden van transacties. Het risicoprofiel van de transactie is hoog, omdat het veelal om grote bedragen gaat en de financiële instelling direct een verplichting aangaat met de ontvangende bank. De financiële instelling stelt in haar beveiligingsbeleid voor deze transacties een end-to-end beveiliging als eis. Endto-end wil in ons voorbeeld zeggen van ontvangst van de betalingsopdracht tot en met de verzending via Swift. M Q M Q MQ Broker (unix) 2 3 MQ MQ Back office systemen Bank (mainframe) 4 Proces betalingsopdracht De verwerking van de betalingsopdracht bestaat uit een aantal stappen: 1. Een klant van de financiële instelling initieert een betalingsopdracht. Als de opdracht via elektronisch bankieren is doorgegeven, wordt deze direct aangeleverd aan de backofficesystemen van de bank. Indien de opdracht via een overschrijving of acceptgiro formulier wordt aangeleverd, wordt de opdracht door de financiële instelling ingevoerd in de Applicatie Betalingsverkeer. Vervolgens moet binnen de financiële instelling een aantal stappen worden uitgevoerd. 2. De transactie wordt verwerkt in de eigen backofficesystemen van de bank. Hierbij wordt onder meer het transactiebedrag van de rekening van de klant afgeboekt. 3. De opdracht wordt, via het Swift-netwerk, verzonden naar de ontvangende bank. 4. Van de verwerking van de betalingsopdracht vindt terugkoppeling plaats naar de Applicatie Betalingsverkeer. M Q Swift (unix) Figuur 6. Voorbeeld internationale betalingsopdracht ondersteund door M Q Logische en technische verbinding Omdat de verschillende applicaties geïnstalleerd zijn op diverse technische platformen, heeft de financiële instelling ervoor gekozen de applicaties aan elkaar te koppelen met behulp van. Daarbij wordt gebruikgemaakt van een centrale message broker. Dit heeft tot gevolg dat bijvoorbeeld de logische verbinding tussen de transactie aanleverende applicatie en de backofficesystemen technisch gezien bestaat uit twee verbindingen. Het eerste deel is de verbinding tussen het windows-platform en de message broker en het tweede deel is de verbinding tussen de message broker en de backofficesystemen op het mainframe. Zoals in het vervolg zal blijken heeft het feit dat de logische verbinding bestaat uit twee technische verbindingen gevolgen voor de maatregelen. Integriteit Integriteit betekent in ons voorbeeld dat gewaarborgd zal moeten zijn dat end-to-end alle berichten, tijdig en ongewijzigd op hun bestemming aankomen. Aspecten van integriteit zijn juistheid, tijdigheid en volledigheid. Vertaald naar betekent dit dat: een bericht ongeschonden/ongewijzigd wordt ontvangen; alle berichten worden ontvangen; een bericht slecht één keer wordt ontvangen; de berichten tijdig worden ontvangen. Maatregelen Om de juistheid en volledigheid te garanderen biedt een aantal diensten op transportlaagniveau (dus van queue tot queue), zoals of het aantal bits ongewijzigd is (juistheid) en of het bericht is aangekomen (volledigheid). Indien een bericht echter meerdere queues passeert, zoals in ons voorbeeld van de betalingsopdracht, dan is deze niet voldoende omdat de end-to-end juistheid en volledigheid niet gegarandeerd zijn. De tijdigheid van de berichtverzending wordt gegarandeerd doordat de berichten verzendt via het First-In- First-Out (FIFO) principe, berichten worden dus in de volgorde van aanlevering verwerkt. Dit mechanisme werkt voor berichten die gebruikmaken van dezelfde queue. Tussen verschillende queues kan wel prioriteit van verwerking worden aangegeven. Hiermee kan worden geregeld dat bepaalde berichten sneller worden verwerkt. Ten slotte biedt de mogelijkheid dat berichten die niet afgeleverd kunnen worden, worden opgeslagen in een Dead Letter queue. Hiermee wordt gewaarborgd dat deze niet afgeleverde berichten niet verloren gaan en gesignaleerd kunnen worden. Maatregelen op applicatieniveau Uit het bovenstaande blijkt dat de integriteit op

7 29 het niveau van de technische verbinding waarborgt. Echter, in ons voorbeeld van de betalingsopdracht eist de financiële instelling dat de integriteit op applicatieniveau (end-to-end) gewaarborgd is. Daarom zijn aanvullende maatregelen nodig. Hash Om de end-to-end juistheid te garanderen, kan aan een bericht een getal of hash worden toegevoegd. De zendende applicatie berekent met behulp van gegevens uit het oorspronkelijke bericht een getal en voegt deze toe aan het bericht. De ontvangende applicatie (in ons voorbeeld Swift) berekent het getal opnieuw en vergelijkt de uitkomst met de waarde in het bericht. De functie om deze berekening uit te voeren moet zowel in de verzendende als in de ontvangende applicatie worden geprogrammeerd. Generieke Services Vanuit beheeroogpunt is het inefficiënt om functies als het berekenen en aan het bericht toevoegen van een hashtotal in de zendende en ontvangende applicatie te programmeren. Als de berekening wijzigt moet de programmatuur van beide applicaties worden aangepast. Daarom kan ook een generieke toepassing worden ingezet voor deze functie. Deze generieke service wordt opgestart door de verzendende en ontvangende applicatie en voert voor hun de hash-berekening uit. Als de berekening wijzigt hoeft alleen de generieke toepassing te worden aangepast. Antwoordmechanisme en doorlopende nummering van berichten Om de end-to-end volledigheid te waarborgen kan gebruik worden gemaakt van een antwoordmechanisme. Dit betekent dat de ontvangende applicatie een bevestiging stuurt naar de zendende applicatie als het bericht ontvangen of verwerkt is. Deze functie wordt niet door ondersteund en moet in de zendende en ontvangende applicatie geprogrammeerd worden. Een andere op de volledigheid is doorlopende nummering van de berichten. De zendende applicatie kent een doorlopend nummer aan het bericht toe dat wordt geerd door de ontvangende applicatie. Indien een bericht wordt ontvangen waarvan het doorlopend nummer incorrect is, dan geeft de ontvangende applicatie een signaal af. ondersteunt deze functie niet. Exclusiviteit Exclusiviteit betekent in ons voorbeeld dat alleen geautoriseerde bronnen (personen of applicaties) toegang hebben tot het berichtenverkeer en berichten kunnen lezen, wijzigen of verzenden. Aspecten van exclusiviteit zijn: privacy, confidentialiteit, identificatie, authenticatie, autorisatie en van bevoegdheden. Specifiek voor betekent dit dat: de inhoud van het bericht niet leesbaar is tijdens het transport en tijdens de opslag in een queue; er geen ongeautoriseerd toegang wordt verkregen tot het message queuing-systeem waardoor onbevoegden berichten zouden kunnen verzenden, wijzigen, lezen of ontvangen. Maatregelen binnen Autorisatie en authenticatie ondersteunt identificatie en autorisatie van aanleverende bronnen. In de header van een bericht wordt de identificatie van de verzender opgenomen. Tevens kan beperken of de aanleverende bronnen gebruik mogen maken van een queue. ondersteunt niet de authenticatie van de aan leverende bron. Authenticatie is van belang om te voorkomen dat ongeautoriseerde berichten worden verstuurd. In ons voorbeeld van het betalingsverkeer zou bij onvoldoende authenticatie een betalingsbericht rechtstreeks aan SWIFT kunnen worden aangeboden buiten de verwerking in de systemen van de financiële instelling om, zodat bijvoorbeeld de betaling niet wordt afgeboekt van de rekening van de klant. Encryptie van berichten kan op transportlaagniveau (dus van queue tot queue) het berichtenverkeer versleutelen door gebruik te maken van het Secure Socket Layer-protocol (SSL). De encryptie wordt gehanteerd op de technische verbinding. Echter, het bericht is niet encrypt als het is opgeslagen in een queue. Bij de verwerking van de betalingsopdracht wordt het bericht versleuteld aangeleverd aan de broker die het ontsleutelt en opslaat in een queue voor verzending naar de backofficesystemen. Voor verzending naar de backofficesystemen wordt het bericht weer versleuteld en verzonden. In de queue bij de message broker staat het bericht in leesbare tekst, zodat beheerders de inhoud van de berichten kunnen lezen en muteren. Om dit te voorkomen zullen algemene beveiligingsmaatregelen moeten worden getroffen voor de server waar de broker op is geplaatst. In dit geval is dit echter niet voldoende, omdat de financiële instelling end-to-end beveiliging van de betalingsopdracht eist Daarom zullen aanvullende maartregelen moeten worden getroffen. Hierover meer in de volgende paragraaf. Maatregelen op applicatieniveau Message Authentication Code (MAC) Ter authenticatie van de aanleverende bron kan een

8 30 de EDP-Auditor nummer MAC aan het bericht worden toegevoegd. De MAC is een totaal dat wordt berekend met behulp van de inhoud van het bericht en een algoritme en crypto grafische sleutel, die de zender uniek maakt. De ontvangende applicatie voert dezelfde berekening uit en kan zo de echtheid van het bericht en de aanleverende bron vast stellen. Door de berekening met het algoritme geeft de MAC ook integriteitwaarborg zoals de Hash. De MAC-functionaliteit moet in de zendende en de ontvangende applicatie geprogrammeerd worden. Ook hiervoor geldt (net als bij de hashtotals) dat het efficiënter kan zijn hiervoor een generieke toepassing in te zetten, afhankelijk van het aantal applicaties die aan elkaar gekoppeld zijn. End-to-end encryptie De betalingsopdracht in ons voorbeeld is fraudegevoelig, daarom eist de financiële instelling end-to-end beveiliging van het berichtenverkeer. Uit het voorgaande bleek dat in een complexe omgeving waarin de Message Broker wordt toegepast, onvoldoende beveiliging biedt omdat de berichten in klare taal in een queue op de Message Broker staan. Een mogelijke maatregel is encryptie van het bericht op applicatieniveau. De versleuteling zal in de zendende en ontvangende applicatie moeten worden geprogrammeerd of door middel van aanvullende generieke toepassing. Controleerbaarheid Controleerbaarheid is in het algemeen gericht op het verifiëren van de werking van de overige kwaliteitsaspecten zoals integriteit en continuïteit. Vertaald naar is dit met name de audit trail en logging. Maatregelen binnen biedt de mogelijkheid berichten te loggen bij de zendende en de ontvangende queue. Deze logging is actief op de technische verbinding. De logging is slechts beperkt bruikbaar als basis voor een functionele logging tussen de applicaties, omdat de logging geen end-to-end informatie of uniform message-id bevat. Gezien de beperkte toegevoegde waarde is deze logging in de praktijk vaak niet actief, omdat dit een aanzienlijke opslagcapaciteit vraagt. Maatregelen op applicatieniveau In ons voorbeeld van de betalingsopdracht is het van groot belang dat alle bewerkingen in het verwerkingsproces te traceren zijn. Bij de inrichting van het proces dient de organisatie te bepalen op welke bewerkingen de organisatie het proces wil monitoren. Vervolgens zal via de applicatie en de inhoud van het te verzenden bericht gewaarborgd moeten worden dat op al deze locaties het unieke transactie-id wordt vastgelegd. Continuïteit en Beschikbaarheid Continuïteit is in het algemeen de mate waarin de gegevensverwerking ongestoord voortgang kan hebben. Beschikbaarheid is de mate waarin gegevens en ITprocessen de organisatie ondersteunen op de momenten dat de organisatie dit eist. Aspecten van continuïteit zijn de bedrijfs zekerheid, de herstelbaarheid en de uitwijkmogelijkheid. Aandachtspunten met betrekking tot zijn: het opvangen van verstoringen als gevolg van het niet beschikbaar zijn van een component; het opsporen en verhelpen van verstoringen. Maatregelen binnen ondersteunt asynchrone communicatie, waardoor het geen probleem hoeft te zijn dat een applicatie tijdelijk niet beschikbaar is. Als een applicatie niet beschikbaar is, worden de berichten opgeslagen in een queue. In het voorbeeld van de betalingsopdracht zijn bijvoorbeeld de backofficesystemen (op het mainframe) slechts tien uur per dag beschikbaar voor on line transacties. Een klant kan echter 24 uur per dag een betalingsopdracht via elektronisch bankieren doorgeven aan de financiële instelling. De opdracht wordt opgeslagen in de queue op het windows platform. Als de backofficeapplicatie weer actief is, haalt deze de queue op het windows platform leeg. De berichten worden vervolgens verwerkt in de backoffice-applicaties. Kanttekening bij dit mechanisme is dat de omvang van de queue voldoende moet zijn (de maximumomvang wordt via een parameterinstelling in vooraf ingesteld). Bij overschrijding van deze omvang kan de data-integriteit van de queue (een bestand) niet worden gegarandeerd. Maatregelen in de beheerorganisatie De beschikbaarheid en continuïteit van is voor een groot deel afhankelijk van de technische infrastructuur, waar gebruik van maakt. De beheerorganisatie kan de infrastructuur monitoren door de omvang/nog beschikbare ruimte van een queue te monitoren. Ook de beschikbaarheid en performance van de queues kan via aanvullende tooling bewaakt worden. Het verdient aanbeveling de tooling aan te laten sluiten met de beheertools voor het netwerk en de technische component. Bij uitval van een deel van de technische infrastructuur zal het veelal niet mogelijk zijn om terug te vallen op handmatige procedures. Er zullen daarom maatregelen moeten worden genomen om de voortgang van het berichtenverkeer ook bij verstoringen te waarborgen. Bijvoorbeeld

9 31 door het in duplo uitvoeren van computer- of datacommunicatieapparatuur en het creëren van alternatieve routes voor de datacommunicatie uitwijk. Dergelijke voor zie ningen moeten periodiek getest worden. Beheerbaarheid Beheerbaarheid is de mate waarin het object kan worden aangestuurd of bijgestuurd, zodat het object bij voortduring aan de daaraan gestelde eisen voldoet of kan vol doen. Aspecten van beheersbaarheid zijn flexibiliteit, onderhoudbaarheid, connectiviteit. Aandachtspunten voor zijn: beschikbaarheid van op een groot aantal platformen; de mogelijkheid om snel en eenvoudig aan te passen of uit te breiden. Maatregelen binnen kan op gangbare platformen worden geïnstalleerd, waardoor het als generiek communicatiemiddel in de meeste technische infrastructuren kan worden gebruikt. Om de flexibiliteit en onderhoudbaarheid te bevorderen, biedt de mogelijkheid om de logische en technische verbindingen los te koppelen. Hierdoor wordt voorkomen dat alle interfaces moeten worden aangepast indien de onderliggende fysieke infrastructuur wijzigt. Daarnaast kunnen binnen queues dynamisch worden aangemaakt. Hierdoor is de omgeving snel aan te passen of uit te breiden. Maatregelen binnen de beheerorganisatie Zeker in grotere omgevingen is het beheer van complex. In deze omgevingen is snel sprake van honderden queues. Een goede naamgevingconventie en adequate documentatie is noodzakelijk om het gebruik van een queue te kunnen identificeren en te beheren. Daarnaast is de keuze van de architectuur van groot belang voor de beheersbaarheid. Een splitsing van logische en fysieke verbindingen is een aspect dat in de architectuur moet worden gedefinieerd. Daarnaast kan het gebruik van een centrale message broker het aantal fysieke verbindingen beperken. Conclusie Doel van dit artikel was het inzichtelijk maken van risico s van gegevensuitwisseling tussen applicaties op basis van message queuing en maatregelen die deze risico s kunnen beperken. Message queuing wordt gebruikt voor het koppelen van applicaties in een complexe technische omgeving met verschillende systeemomgevingen. Message queuing is een vorm van asynchrone persistente communicatie. Asynchroon betekent dat het bestand wordt opgeslagen in een soort postbus en dat de verzendende applicatie niet afhankelijk is van de ontvangst/verwerking van het bericht door de ontvangende applicatie. Persistent betekent dat het bericht blijft bestaan, totdat het afgeleverd is. biedt op de transportlaag een aantal waarborgen om de integriteit, exclusiviteit erbaarheid van het berichtenverkeer te waarborgen. biedt echter geen mogelijkheden om end-to-end s uit te voeren, op integriteit van het berichtenverkeer (bijvoorbeeld door hashtotals) of exclusiviteit (encryptie) te waarborgen. Dit betekent dat met name in grote complexe omgevingen, waarbij het aantal MQ-objecten kan oplopen tot meer dan honderd, aanvullende maatregelen noodzakelijk zijn. Het verdient aanbeveling om deze services generiek via aanvullende tools te implementeren, in plaats van ze in elke toepassingsapplicatie opnieuw te ontwikkelen. De mate waarin aanvullende maatregelen nodig zijn, is afhankelijk van de business context waarin message queuing wordt toegepast. Het is aan de gebruikers van het message queuing-systeem om in kaart te brengen welke risico s verbonden zijn aan het berichtenverkeer en op basis daarvan te bepalen of aanvullende maatregelen nodig zijn. Literatuur [BERN96] Bernstein, P.A, (1996), Middleware: a model for distributed system services, in: Communications of the ACM, Vol. 39, February. [MORR99] Morris, J.H., (1999), Interface issues in computer support for asynchronous communication, in: Communications of the ACM, Vol. 31. [ORPH99] Orphali, R., (1999), Client Server Survival Guide, Third edition, Wiley Computer Publishing. [SPHA98] Sphani, S. en J.-R. Scherrer, (1998), Consensual trends for optimizing the constitution of middleware, in: Communications of the ACM, Vol. 28, October. [TANE96] Tanenbaum, A.S., (1996), Computer Networks, Third edition, Prentice Hall, New Jersey. [TANE02] Tanenbaum, A.S., (2002), Distributed Systems Principles and Paradigms, Prentice Hall, New Jersey. [WACK99] Wackerow, D., (1999), MQ Series Primer, Enterprise Application Integration Center, IBM Redbooks, October. Noten 1 Hiermee worden de lagere niveaus van een netwerkarchitectuur bedoeld (onderste lagen OSI-model). 2 Deze kwaliteitsaspecten zijn gebaseerd op Noreageschrift 1 IT Auditing aangeduid.

10 32 de EDP-Auditor nummer BIJLAGE Tijdigheid Audit Raamwerk message queuing Deze bijlage bevat een inventarisatie van risico s en mogelijke maatregelen die als uitgangspunt kunnen dienen bij de beoordeling van de betrouwbaarheid van de gegevens uitwisseling tussen applicaties met behulp van. Per risico is aangegeven: welke maatregelen hier tegenover stelt; welke maatregelen in de zendende en ontvangende applicaties kunnen worden getroffen (applicatieve s); welke procedurele maatregelen in de administratieve organisatie getroffen kunnen worden. Tijdigheid Tijdigheid Berichten worden tijdig ontvangen. Tussen verschillende queues kan prioriteit van verwerking worden aangegeven. Hiermee kan worden geregeld dat bepaalde berichten sneller worden verwerkt. Tijdmechanisme instellen om te voorkomen dat een bericht dat niet kan worden verzonden, de zendende queue blokkeert. In de message header van een bericht kan een expiratietijd worden meegegeven. Na een zekere tijdspanne (bijvoorbeeld 5 seconden) wordt de verwerking van het bericht overgeslagen. Het bericht valt uit de zendende queue en er verschijnt via een monitoring tool een signaal bij de 1e-lijnssupport. Berichten worden in de juiste volgorde ontvangen en verwerkt. (Bijvoorbeeld een annulering van een transactie wordt niet eerder ontvangen dan de transactie zelf.) Geen. Doorlopende nummering van berichten en hierop door de ontvangende applicatie. Juistheid Exclusiviteit Juistheid Een bericht wordt ongeschonden/ongewijzigd ontvangen. Er is voldoende afscherming van privacygevoelige of vertrouwelijke gegevens. Geen end-to-end op de juistheid indien een bericht meerdere queues passeert. Op transportlaagniveau (dus van queue tot queue) mogelijkheid tot of het bericht is aangekomen en of het aantal bits ongewijzigd is. MQ kan op transportlaagniveau (dus van queue tot queue) het berichtenverkeer versleutelen door gebruikmaking van het SSL-protocol. biedt geen end-to-end encryptie. Encryptie van gegevens in een bericht dat is opgeslagen in een queue wordt niet ondersteund door. Volledigheid Controle op end-to-end juistheid door getal (hash) op te nemen in het bericht. End-to-end encryptie in de zendende en ontvangende applicatie programmeren. Aanvullende generieke services buiten voor beveiliging. Volledigheid en procedurele maatregel Alle berichten worden ontvangen. Geen end-to-end garantie dat alle berichten worden ontvangen indien een bericht meerdere queues passeert. Op de transportlaag biedt MQ de mogelijkheid om het bericht opnieuw te versturen als het bericht niet ontvangen wordt. Berichten die niet afgeleverd kunnen worden (bijvoorbeeld door verkeerde adressering) worden naar een dead letter queue gerouteerd zodat ze niet verloren gaan. Ontvangstbevestiging van de ontvangende applicatie naar de zendende applicatie. De zendende applicatie geeft bij het ontbreken van een ontvangstbericht een signaal af dat via een monitoring tool opgepakt wordt door de 1e-lijnssupport. MQ Er wordt geen ongeautoriseerd toegang verkregen tot het message queuing-systeem waardoor onbevoegden berichten zouden kunnen verzenden, wijzigen, lezen of ontvangen. biedt functionaliteit om een bron (persoon of applicatie) te identificeren, maar niet om een bron te authenticeren. Het is mogelijk de toegang tot de objecten (queue manager en queues) te beperken tot bepaalde gebruikers of tot bepaalde applicaties (via de Interface). Hiertoe bevat het bericht een user ID. Authenticatie van het bericht en de aanleverende bron op basis van een Message Authentication Code (MAC). en procedurele maatregel Doorlopende nummering van berichten en hierop door de ontvangende applicatie. Indien een nummer ontbreekt of dubbel wordt ontvangen geeft de ontvangende applicatie een signaal af dat via een monitoring tool opgepakt wordt door de 1e-lijnssupport. Volledigheid Een bericht wordt slechts één keer ontvangen. Doorlopende nummering van berichten en hierop door de ontvangende applicatie.

11 33 Controleerbaarheid Er is voldoende inzicht in de uitgevoerde activiteiten (audittrail) van het berichtenverkeer. biedt de mogelijkheid berichten te loggen bij de zendende en de ontvangende queue. In de praktijk is deze logging vaak niet actief omdat dit een aanzienlijke opslagcapaciteit vraagt. De MQ logging is gebaseerd op het verwerkings-id, dit is het nummer dat het bericht krijgt voor de technische verbinding van queue tot queue. Er is dus geen logging op basis van een uniek transactienummer van een bericht over de hele keten heen (end-to-end). Logging van berichten op basis van een uniek transactie-id (over de technische componenten heen), gericht op de key controls van het business proces. Continuïteit en Beschikbaarheid Beheersbaarheid Er treedt geen verstoring van de gegevensverwerking op als gevolg van het niet beschikbaar zijn van een systeem of applicatie. slaat de berichten op in queues en verzendt ze in de volgorde van aanlevering naar de ontvangende applicatie. Kantekening hierbij is dat de maximale omvang van een queue via parameterinstelling vooraf ingesteld dient te worden. Bij overschrijding van deze omvang kan de data-integriteit van de queue (een bestand) niet gegarandeerd worden. De inrichting van is eenvoudig aan te passen of uit te breiden. Binnen kunnen queues dynamisch worden aangemaakt, waardoor de omgeving snel aan te passen of uit te breiden is. Dit betekent dat niet bij elke aanpassing de gehele MQ-omgeving opnieuw gedefinieerd hoeft te worden. biedt de mogelijkheid de fysieke en de logische verbinding los te koppelen door gebruik te maken van aliasnamen voor queues en queuemanagers. Procedureel De werking van kan via monitoring van de omvang/ nog beschikbare capaciteit van de queues plaatsvinden. Beschikbaarheid en performance kan via aanvullende tooling worden bewaakt. De inrichting van is onderhoudbaar. biedt geen specifieke tooling voor het beheer van queues. Naamgevingsconventie voor MQ-objecten. Een splitsing van logische en fysieke verbindingen is een aspect dat in de architectuur moet worden gedefinieerd. Daarnaast kan het gebruik van een message broker het aantal fysieke verbindingen beperken. Procedureel De continuïteit van het netwerk of het message queuingsysteem wordt niet verstoord. Geen. Het terugvallen op handmatige procedures zal veelal niet mogelijk zijn. Er zullen daarom maatregelen moeten worden genomen om de voortgang van het berichtenverkeer ook bij verstoringen te waarborgen. Bijvoorbeeld door het in duplo uitvoeren van computer- of datacommunicatieapparatuur en het creëren van alternatieve routes voor de datacommunicatieuitwijk. Dergelijke voorzieningen moeten periodiek getest worden. Procedureel heeft geen beperkingen wat betreft de connectiviteit en interoperabiliteit. is op de meeste besturingssystemen te installeren. Daarnaast is het niet noodzakelijk dat alle systemen tegelijk actief zijn door het asynchrone karakter.