Skype: hoe ‘gratis’ is het?

Dat allerlei ‘gratis’ diensten op internet niet zo gratis zijn als ze lijken, dringt steeds meer door bij veel mensen. Dat er risico’s zitten aan met name het zakelijk gebruiken van online diensten als Dropbox, Skype, enz., erkennen veel mensen ook wel. De praktijk wijst echter uit, dat het gebruiksgemak van zulke diensten toch belangrijker is dan de risico’s en dat ze dus wel worden gebruikt.

In de voorwaarden van zulke diensten is het vaak zoeken naar de risico’s. Deze week werd ik geattendeerd op een soort, die ik nog niet eerder had opgemerkt: in de voorwaarden van Skype staat, dat je als gebruikeSkype_logor ermee akkoord gaat, dat anderen jouw computer gebruiken om Skype te kunnen gebruiken. Verwacht nu niet dat ineens iemand anders achter je computer kruipt. Zo erg is het nou ook weer niet. Of misschien is het eigenlijk nog wel erger: je ziet het niet en toch gebeurt het. Skype gebruikt namelijk op de achtergrond de processor en het geheugen van je computer voor andere Skype-gebruikers binnen hetzelfde netwerk en als je deze software gebruikt, ben je daarmee akkoord gegaan. Lees het gecursiveerde deel in artikel 5.2 van de voorwaarden maar eens:

5.2 Gebruik van uw benodigdheden: De Software voor internetcommunicatie kan gebruikmaken van de rekencapaciteit, het geheugen en de bandbreedte van de computer (of andere relevante apparatuur) die u gebruikt, met als enkel doel het faciliteren van de communicatie en het tot stand brengen van de verbinding tussen gebruikers van Software voor internetcommunicatie. Indien uw gebruik van de Software voor internetcommunicatie afhankelijk is van het gebruik van een processor en de bandbreedte die eigendom zijn van of beheerd worden door derden, erkent u en stemt u ermee in dat u om gebruik te kunnen maken van uw licentie voor het gebruik van de Software voor internetcommunicatie, eerst toestemming voor dat gebruik moet krijgen van de betreffende derden. Door acceptatie van deze Voorwaarden geeft u te kennen deze toestemming te hebben verkregen.

Wat er precies gebeurt en in hoeverre je computer wordt gebruikt als anderen Skypen, heb ik nog niet kunnen achterhalen. Ik ben een beetje bang dat dit een analyse van het netwerkverkeer vraagt, want de website van Skype zwijgt hierover. Helaas heb ik geen (betaalde) optie kunnen vinden om dit soort dingen te voorkomen en dat is nu weer best jammer van dat soort diensten. Een klein bedrag betalen voor het gebruik zou het mij wel waard zijn om dit soort dingen te voorkomen.

Advertenties

IT-beleid op de schop dankzij nieuwe devices

Dit artikel is gepubliceerd in Accountancynieuws op 6 april 2012

Het aantal soorten apparaten dat kan worden gebruikt om toegang te krijgen tot bedrijfsinformatie neemt toe. Tien jaar geleden werden laptops gangbaar. Vijf jaar geleden was het nog redelijk uniek als iemand de beschikking had over een smartphone. Twee jaar geleden waren er nog geen tablets en kwam je hooguit af en toe iemand tegen met een e-reader. Inmiddels zijn deze apparaten volop in gebruik en het duurt vast geen vijf jaar voor er weer iets nieuws bijkomt.

De vraag of deze nieuwe apparaten – die op het eerste gezicht vaak een behoorlijk ‘gadget’-gehalte hebben – zinvol zijn moet op een andere manier worden beoordeeld. De afweging puur op basis van te berekenen productiviteitsverbetering voldoet niet meer. In de praktijk hebben medewerkers vaak zelf al de beschikking over tools die binnen de organisatie nog niet in gebruik zijn. Deze tools willen ze graag ook zakelijk kunnen gebruiken. Het levert gemak op en het is een manier van werken die bij hen past. Hiervoor worden termen als ‘Bring Your Own Device’ en ‘consumerization’ gebruikt.

In een ‘netwerkwereld’ zijn de persoonlijke contacten van medewerkers belangrijk voor een organisatie. De technische mogelijkheden moeten dan niet in de weg staan om op een moderne manier productief te kunnen zijn. De medewerkers die het IT-beleid negeren volgens het genoemde onderzoek (zie kader), weten niet beter dan altijd online te zijn en willen ook niet anders. En last but not least: IT-afdelingen kunnen het gebruik van deze nieuwe apparaten best op een goede en veilige manier faciliteren. De argumenten met betrekking tot beveiliging en beheer om het gebruik tegen te houden, houden geen stand en moeten en kunnen op een praktische manier effectief worden ingevuld.

Bedrijfsmatige afweging

Het doet niets af aan het feit dat op een normale bedrijfsmatige manier de afweging moet worden gemaakt wat vanuit de organisatie wordt gefaciliteerd en hoe dat wordt gedaan. Het toestaan van allerhande apparaten betekent niet automatisch dat dan ook alle applicaties en gegevens daar vanaf toegankelijk moeten zijn. Zo is een telefoon of tabletcomputer niet echt geschikt om een grote hoeveelheid gegevens in te voeren en heeft een telefoon nog extra beperkingen door het kleine scherm. Een zakelijke afweging blijft dus nodig, want elke uitbreiding kost tijd en/of geld en brengt risico’s met zich mee op het gebied van beveiliging. Probeer echter niet bij voorbaat alles tegen te houden, want voor veel dingen is er een goede reden aanwezig om het juist wel te doen. Overigens vinden de medewerkers anders ook snel genoeg een eigen manier om het toch te regelen. Die manieren blijven dan helemaal buiten het beeld van de IT-afdeling en dat levert nog meer risico’s op.

Flexibel gebruik IT-infrastructuur

‘Jonge medewerkers negeren IT-beleid’ is de titel van een onlangs verschenen artikel naar aanleiding van een onderzoek van Cisco. Twee op de drie in dit onderzoek ondervraagde personen geeft aan dat het IT-beleid moet worden aangepast aan de vraag naar meer arbeidsflexibiliteit. In AN, afl. 22, 2011 zijn zes scenario’s beschreven om aan de ‘achterkant’, binnen de organisatie, de juiste voorwaarden in de infrastructuur te creëren voor een flexibel IT-beleid. In dit artikel een aantal mogelijkheden op een rij om flexibel gebruik te kunnen maken van die infrastructuur, want dat is toch waar het uiteindelijk om gaat.

Wensen

De meest eenvoudige variant van het toegang krijgen tot het bedrijfsnetwerk vanaf een willekeurige locatie is het inloggen met de (bedrijfs)laptop via een beveiligde verbinding. Als gebruik wordt gemaakt van een gecentraliseerde omgeving is dit relatief eenvoudig te realiseren en vaak ook al geregeld. Een veelgehoorde wens sinds de opkomst van de smartphones is het kunnen synchroniseren van mail, agenda, contactpersonen en eventueel takenlijsten. Met de komst van de tablets zijn daar enkele redelijk universele wensen bij gekomen:

  • vergaderstukken digitaal kunnen verspreiden binnen de organisatie en ook achteraf nog kunnen raadplegen;
  • kunnen benaderen van interne kennisdelingsplatformen.

Het gebruik van social media staat bewust niet in dit lijstje, omdat de organisatie daar in het algemeen in technische zin niets voor hoeft te regelen (behalve het opheffen van eventuele eerder ingestelde blokkades hierop). Dat hebben de medewerkers zelf al lang gedaan. Het kunnen benaderen van de bedrijfsapplicaties is ook een minder belangrijk punt, omdat deze vaak (nog) niet gebruiksvriendelijk werken vanaf touchscreens. Het op een geschikte manier ontsluiten van relevante informatie vanuit deze applicaties voor de mobiele apparaten is wel een uitdaging voor de komende tijd.

Beveiliging data

Een van de mooie zaken bij het extern inloggen op het kantoornetwerk via een Citrix- en/of Microsoft-oplossing is dat alle data binnen het kantoornetwerk blijven. In steeds meer gevallen is dat ondergebracht binnen een goed geconditioneerd en fysiek beveiligd datacenter. De beveiliging van het apparaat, waarmee wordt ingelogd, is in deze situatie veel minder relevant. Ten opzichte van de situatie waarbij de cliëntgegevens werden opgeslagen op de laptop om ze mee te nemen naar de klant is dit een grote vooruitgang.

Op basis van deze voordelen met betrekking tot de beveiliging lijkt het voor de hand te liggen om vanaf andere apparaten op dezelfde manier in te loggen. Alle getroffen beveiligingsmaatregelen, zoals two-factor authenticatie, zijn dan onverminderd van toepassing. In de praktijk zijn hier twee bezwaren tegen:

  • verminderde gebruiksvriendelijkheid van de applicaties op touchscreens;
  • licentievoorwaarden van sommige applicaties.

Het gebruik van ‘apps’ op smartphones en tablets kent deze problemen niet, maar geeft wel een lastiger situatie als het gaat om beveiliging, doordat data lokaal op de apparaten terecht kunnen komen.

Beveiliging apparaten

Passende beveiliging van de toegang tot mobiele apparaten is een vereiste in een zakelijke omgeving. Het afdwingen van een wachtwoord met bijbehorende en- cryptie en zorgen dat een apparaat na een aantal foutief ingevoerde wachtwoorden wordt gewist, zijn toch wel de minimaal te nemen maatregelen. Ook de mogelijkheid om een apparaat op afstand handmatig te kunnen wissen hoort erbij. De benodigde beveiligingsinstellingen kunnen in veel gevallen vanaf de mailserver via de mailsynchronisatie worden afgedwongen. Niet accepteren van de vereiste policy betekent dan automatisch het niet kunnen synchroniseren van mail, agenda, e.d. Als een mailserver wordt gebruikt die dit niet ondersteunt, zijn er andere beheertools genoeg die kunnen worden ingezet voor dit doel. Als medewerkers gebruikmaken van persoonlijke smartphones en tablets is er een bijzonder aandachtspunt. In het belang van de organisatie kan het nodig zijn om een apparaat op afstand te wissen. In veel gevallen betekent dit wissen het herstellen van de fabrieksinstellingen, waarbij alle persoonlijke gegevens en instellingen verloren gaan. Het is verstandig om dit als recht van de organisatie in een korte overeenkomst vast te leggen.

‘In een netwerkwereld zijn de persoonlijke contacten van medewerkers belangrijk voor een organisatie. Techniek moet dan niet in de weg staan.’

Licenties

Het licentiemodel van veel van de in de accountancy gebruikte software is gebaseerd op ‘named users’. Voor elke medewerker die toegang heeft tot de applicatie moet een licentie worden aangeschaft. Vanaf welk apparaat diegene toegang krijgt, is niet van belang. Dit is de eenvoudigste situatie, die met alle extra apparaten geen problemen oplevert. Lastiger wordt het met de meest gebruikte Office suite. De licenties hiervan die bij kleine en middelgrote organisaties worden gebruikt, zijn vrijwel altijd gebonden aan een ‘device’. Voor elk apparaat dat toegang krijgt tot de applicatie via bijvoorbeeld Citrix, moet een extra licentie worden aangeschaft. Als iemand dus een bedrijfscomputer, een tablet en een privé-computer gebruikt, zijn drie licenties nodig en dat wordt dan wel een erg kostbare zaak.

Toegang tot informatie

Veel van de genoemde wensen kunnen via webbased oplossingen worden gerealiseerd. Een voorbeeld: als een organisatie beschikt over een intranet, kan daar een onderdeel worden ingericht voor alle vergaderstukken waar geautoriseerde personen toegang toe krijgen. Als het intranet dan wordt ontsloten voor toegang vanaf tablets, bij voorkeur met een geschikte ‘app’ voor het gebruiksgemak, dan kan op een heel efficiënte en goedkope manier de verspreiding van documenten worden gerealiseerd. En de extra kosten en milieubelasting van de tablets kunnen dan weer worden terugverdiend. Een soortgelijke invulling is voor meer zaken te maken.

Cloud en privacy

De smartphones en tablets bieden via alle beschikbare ‘apps’ nog heel veel extra mogelijkheden. Vaak wordt daarbij informatie ergens op internet opgeslagen, ofwel ‘in the cloud’. Het verdient aandacht om te zorgen dat cliëntgegevens niet op deze manier ergens op internet terechtkomen. Zeker als het gaat om persoonsgegevens (en daar hebben accountantskantoren vaak mee te maken) stelt de Wet Bescherming Persoonsgegevens (WBP) strenge eisen, waaraan veel cloud-oplossingen niet voldoen. De beste manier om het onveilig opslaan van gegevens te voorkomen, is het zelf realiseren van een passende oplossing die de gewenste mogelijkheden biedt. Dat is soms nog lastig, maar wordt steeds beter in te vullen.

Zes scenario’s voor de ICT- infrastructuur van een accountantskantoor

Dit artikel is gepubliceerd in Accountancynieuws op 9 december 2011

De wensen zijn eenvoudig. ICT moet goed beveiligd zijn, medewerkers moeten overal – ook thuis – kunnen inloggen, toegang moet ook mogelijk zijn via smartphones en tablets. Achter wensen die in een zin zijn samen te vatten, liggen er werelden van mogelijkheden en scenario’s om de ICT-infrastructuur binnen een kantoor te regelen. Een aantal mogelijkheden op een rij.

De manier waarop ICT wordt gebruikt, kan behoorlijk verschillen tussen organisaties. Toch zijn er ook veel overeenkomsten in de ICT-wensen bij middelgrote en kleinere accountantskantoren:

  • medewerkers moeten overal toegang hebben tot cliëntgegevens;
  • het gebruik van nieuwe soorten apparaten moet mogelijk zijn. Medewerkers gebruiken privé de nieuwste dingen en willen het bij het werk niet met minder doen;
  • de noodzaak van een goede beveiliging van het geheel wordt steeds meer onderkend, waarbij het woord beveiliging breed moet worden uitgelegd en ook continuïteit eronder valt.

Als een organisatie uit meerdere vestigingen bestaat, kunnen hier nog zaken bij komen als organisatiebreed toegang verzorgen tot applicaties of informatie of het integreren van processen.

Huidige situatie applicaties

Met betrekking tot de huidige ICT-infrastructuur komt een aantal zaken vrijwel altijd overeen tussen heel veel kantoren:

  • de basis van de infrastructuur wordt gevormd door een op Microsoft Windows gebaseerd netwerk. De belangrijkste reden hiervoor is dat de meeste gebruikte applicaties binnen de accountancy alleen voor dit besturingssysteem beschikbaar zijn;
  • veel applicaties zijn nog niet in een echte webbased variant beschikbaar of de webbased versie biedt nog onvoldoende functionaliteit.

Voor sommige applicaties, zoals de financiële en salarisadministratie, zijn overigens al wel langere tijd echte webapplicaties beschikbaar.

Integratie en SBR

Een van de ontwikkelingen, die na jaren afwachten nu echt doorzet, is SBR. Om aanleveringen van o.a. de SBR-kredietrapportage naar de banken efficiënt te kunnen doen, is een vergaande integratie tussen allerlei gegevensbronnen nodig. Inhoudelijk ga ik daar nu niet verder op in, maar bij het inrichten van de infrastructuur voor de komende jaren is het wel van belang om er rekening mee te houden, dat de technische gegevensuitwisseling tussen applicaties geen belemmering meer vormt voor inhoudelijke integratie.

Andere aandachtspunten

Naast de aan het begin reeds genoemde wensen m.b.t. de ICT, zijn er nog meer aspecten waar kantoren rekening mee moeten houden; daarbij heb ik niet de illusie te denken dat de hierna volgende opsomming volledig is.

  • In de eerste plaats is er de vraag: zijn de applicaties inhoudelijk nog voldoende? Als dat het geval is en de applicatie draait technisch stabiel en de performance is goed, dan zal het uitgangspunt meestal zijn om deze applicatie te handhaven.
  • In de tweede plaats komen de vragen: is de stabiliteit en performance van het eigen systeem goed en is de bestaande infrastructuur nog toekomstbestendig?
  • In de derde plaats komt de vraag: is de infrastructuur al gecentraliseerd? Dit geldt met name bij organisaties met meerdere vestigingen. Als dit niet het geval is, heeft dit invloed op de te nemen maatregelen om overal toegang te krijgen tot applicaties en cliëntgegevens.
  • De vierde vraag luidt: is er voldoende kennis in huis om de infrastructuur en het technisch onderhoud aan de applicaties op het juiste niveau te houden?

Scenario’s

Op basis van deze wensen en aandachtspunten kunnen we een aantal scenario’s bedenken voor de inrichting van de ICT-infrastructuur in een accountantskantoor. De basisvoorwaarde voor ieder scenario, inclusief mogelijke variaties, bestaat uit stabiele dataverbindingen met voldoende bandbreedte.

Scenario 1: zelf blijven doen

In het gunstige scenario dat zowel de applicaties als de infrastructuur berekend zijn op de toekomst, de infrastructuur is gecentraliseerd en er voldoende kennis in huis is om dit zo te houden, kan de keuze worden gemaakt om alles zelf te blijven doen. Voor de benodigde uitbreidingen kan gekozen worden om zelf de kennis op te doen of deze in te kopen. Bij vervanging van apparatuur of applicaties is een herbeoordeling aan te bevelen.

Scenario 2: optimaliseren huidige infrastructuur

Als de applicaties voldoen, maar de infrastructuur niet helemaal, verdient het de voorkeur om eerst na te gaan of daarin verbetering mogelijk is. Hierin zijn allerlei varianten mogelijk. Een paar voorbeelden:

  • als de performance of stabiliteit van het systeem niet goed is, kan een gespecialiseerde partij hier mogelijk verbetering in brengen. Dit brengt kosten met zich mee, maar die kosten zijn er ook als de situatie niet wordt verbeterd. Hooguit zijn ze in het eerste geval wat meer zichtbaar;
  • in een kleine organisatie met één vestiging is het mogelijk om iedereen op afstand toegang te geven tot zijn eigen computer op kantoor. Soms is het voldoende om één extra server in te zetten voor de externe toegang. Met een geringe inspanning kan dan mogelijk al het gewenste doel worden bereikt;
  • het beheer blijft in dit geval wel de eigen verantwoordelijkheid. Als dat niet de bedoeling is, vervalt dit scenario.

Scenario 3: centraliseren

Een minder voor de hand liggend scenario is het zelf gaan centraliseren van de infrastructuur met behulp van oplossingen van Microsoft en/of Citrix. Telt een organisatie meerdere vestigingen met per vestiging een eigen infrastructuur, dan kan dit een belemmering zijn om de aan het begin van dit artikel genoemde wensen te realiseren. In een grotere organisatie kunnen er redenen zijn om de infrastructuur in eigen beheer op te gaan bouwen en zelf de kennis in huis te halen, maar de scenario’s 4, 5 of 6 liggen meer voor de hand als de centralisatie nog moet beginnen.

Scenario 4: hosting

Als de infrastructuur niet voldoet en de applicaties wel, dan is het op huurbasis afnemen van de applicaties bij een hostingpartij een reële optie. Veel applicaties zijn gebaseerd op Windows. Een hostingpartij kan ze dan in de meeste gevallen via Microsoft- en/of Citrixoplossingen beschikbaar stellen. Technisch maakt dit dus niet zoveel verschil met scenario 3. Inhoudelijk is er wel een groot verschil, want de verantwoordelijkheid voor de investeringen en het beheer liggen nu bij de hostingpartij. Overigens zijn performance en stabiliteit in dit scenario niet altijd gegarandeerd en ook als het gaat om continuïteit is er bijvoorbeeld niet altijd een uitwijklocatie geregeld in het geval van een ernstige calamiteit. Dit scenario heeft andere risico’s dan een eigen infrastructuur. Breng deze risico’s goed in kaart voor u in zee gaat met een hostingpartij.

Scenario 5: hosting eigen infrastructuur met extern beheer

Dit is een combinatie van de scenario’s 3 en 4. Het kantoor doet zelf de investeringen, realiseert zelf een serverruimte of huurt ruimte in een professioneel datacenter voor de apparatuur. De inrichting en het beheer worden dan verzorgd door een externe gespecialiseerde partij. Het nadeel hiervan is dat de investeringen voor eigen rekening komen. Extra aandacht verdient hierbij wel de exit-strategie: maak vooraf duidelijke afspraken met de beherende partij over de werkwijze voor een eventueel afscheid en het overgaan naar een andere beheerder.

…veel overeenkomsten in de ICT-wensen bij middelgrote en kleinere accountantskantoren.

Scenario 6: volledig webbased

De meeste webbased applicaties zijn nu nog op zichzelf staande oplossingen. Met name voor kantoren die nu met een volledig geïntegreerde ERP-oplossing werken is het overgaan naar zulke losstaande applicaties vaak niet wenselijk, omdat dan de voordelen van de bestaande integratie deels verloren gaan. Wanneer een aanzienlijk deel van de infrastructuur of de applicaties aan vervanging toe is, verdient het aandacht om na te gaan of het volledig gaan werken met webapplicaties mogelijk is. De afhankelijkheid van één partij (scenario 4) en het nodig hebben van een uitgebreide eigen infrastructuur (scenario’s 1, 2, 3 en 5) spelen dan bijna geen rol meer. Daar staat wel een nadeel tegenover. Voor de integratie van de verschillende applicaties zijn meerdere partijen nodig. Dat loopt niet altijd even soepel. Overigens is wel te verwachten dat dit scenario over een aantal jaren de standaard zal zijn.

Thin clients

Tot slot nog een paar opmerkingen over thin clients. In bijna alle scenario’s speelt centralisatie op basis van de oplossingen van Microsoft en/of Citrix een rol. Het ligt dan voor de hand om gebruik te gaan maken van thin clients, zoals ook Martine van de Merwe in haar artikel al heeft beschreven in AN afl. 19, 2011.

Thin clients zijn qua hardware (nog) niet goed berekend op de moderne media, waarin veelvuldig gebruik wordt gemaakt van video en audio. Daarnaast lopen de op de thin clients gebruikte versies van de clientsoftware van Microsoft (RDP) en Citrix (ICA) nogal eens achter bij de versies die voor gewone computers beschikbaar zijn. Met name voor modernere ontwikkelingen, zoals video en audio, maar ook voor het gebruik van meerdere monitoren per werkplek, is dit soms hinderlijk. En als laatste: nu is op een thin client alleen een ICA- of RDP-client nodig. Mogelijk is er in de nabije toekomst alleen nog een browser nodig. Zorg dat u thin clients kiest die dit aan kunnen.

Hoe lang kunnen we nog werken als de computer uitvalt?

Als je bij een organisatie werkt, die redelijk vergaand is gedigitaliseerd, zit het antwoord op deze vraag waarschijnlijk ergens in de reeks tussen de vijf minuten en een kwartier. Als het één computer is, die uitvalt, is het leed nog wel te overzien en redelijk eenvoudig op te lossen. Maar wat als de automatiseringsomgeving in een organisatie is gecentraliseerd en die centrale omgeving valt uit? Het lijkt me toch een verplichting tegenover klanten en medewerkers, om hier op een goed onderbouwde manier keuzes in maken en maatregelen nemen. Dit wil niet zeggen dat elk risico, koste wat het kost, moet worden uitgesloten, maar wel dat de risico’s op een goede manier in kaart worden gebracht en dat vervolgens passende maatregelen worden genomen.

Een voorbeeld: als bijna alle medewerkers kunnen telewerken, hoeven waarschijnlijk geen dubbel uitgevoerde verbindingen tussen de kantoorvestigingen en het datacenter met de centrale infrastructuur aanwezig te zijn. Bij uitval van de verbinding kan iedereen thuis verder werken.

Beslissingen op managementniveau en niet (alleen) door IT-afdeling
In dit artikel wil ik wat zaken noemen, waarover het management van een organisatie vooraf een beslissing moet nemen. Deze beslissingen zijn nodig om te kunnen bepalen welke maatregelen ‘passend’ zijn. De afdeling IT kan wel helpen om alle relevante informatie beschikbaar te krijgen en ook zal deze afdeling een groot deel van de uitvoering van de maatregelen, waartoe wordt besloten, voor zijn rekening nemen, maar de beslissingen horen echt op het hoogste niveau in de organisatie te worden genomen.

Maximale uitvaltijd (Recovery Time Objective)
Een van de eerste beslissingen, die moet worden genomen, betreft de maximale tijd waarbinnen de beschikbaarheid van een uitgevallen systeem moet worden hersteld (afgekort RTO). De waarde van de RTO is afhankelijk van de schade, die wordt verwacht bij uitval, in wat voor vorm dan ook, dus zowel financiële schade als bijv. imageschade moet worden beoordeeld. Dit laatste wordt o.a. beinvloed door het feit of klanten toegang hebben tot de systemen, via bijvoorbeeld een klantenportal op de website. Ook is telefonie steeds meer geïntegreerd in de datanetwerken, dus denk hierover ook goed na.

Let wel: dit betreft een beslissing over een uitgangspunt vooraf, die tijdens het maken van een ontwerp voor een passende infrastructuur of nog later mogelijk moet worden bijgesteld. Zeker als de RTO in hoofdzaak is afgeleid van de mogelijke financiële schade kan achteraf bijstellen nodig zijn als de kosten om schade te voorkomen niet in redelijke verhouding tot de schade door uitval blijken te staan.

Maximaal dataverlies (Recovery Point Objective)
Een tweede vereiste betreft het vaststellen van het maximaal toegestane dataverlies (RPO). Bij een storing kan de data, die is toegevoegd of gewijzigd sinds de laatste back-up, verloren gaan. In de wat traditionelere netwerken is deze RPO vaak 24 uur, omdat één keer per dag een back-up wordt gemaakt. Als dan aan het einde van de werkdag een systeem zou crashen, zou het werk van de hele dag verloren zijn. Dit wordt steeds minder acceptabel in moderne bedrijfsomgevingen. Het is belangrijk om de RPO per proces vast te stellen om onnodig investeren te voorkomen. Daarnaast moeten de mogelijkheden om de data na een crash te reconstrueren in overweging worden genomen: inkomende e-mail van buiten de organisatie is bijna niet te reconstrueren en tegenwoordig wel van zeer groot belang, dus mogelijk is de RPO voor e-mail één uur, terwijl die voor andere data twee of vier uur is of nog langer.

Combinatie van RTO en RPO
De combinatie van RTO en RPO moet ook worden beoordeeld. Als een storing optreedt, die binnen vier uur moet worden opgelost (RTO) en er mag maximaal vier uur data verloren gaan (RPO) is het nog steeds mogelijk om in bedrijfsprocessen een dag achterstand op te lopen (vier uur werk kwijt en vier uur niet benutte uren). Maar als medewerkers bij uitval van een proces andere werkzaamheden uit kunnen voeren, hebben we weer een heel andere situatie en telt eigenlijk alleen de RPO mee.

Maken ontwerp als infrastructuur niet aan eisen voldoet
Als (delen van) de infrastructuur niet aan de eisen voldoet, moet een ontwerp worden gemaakt voor een gewijzigde of nieuwe infrastructuur, die dat wel doet. Dit is vooral een technische aangelegenheid, waarover ik een andere keer nog wat hoop te schrijven. Aan de hand van dit ontwerp moet ook een inschatting worden gemaakt van de benodigde investeringen en kosten. Neem bij dit soort projecten ook een post ‘onvoorzien’ op, want die komt er vrijwel zeker aan. In mijn blog van 14 november heb ik kort overzicht gegeven van wat maatregelen, die ik in de loop van de jaren genomen heb zien worden bij een groeiende organisatie.

Controleren en eventueel bijstellen van RTO en RPO
Als het ontwerp gereed is, is het tijd om na te gaan of dit aan de RTO en RPO voldoet. Ook moet aan de hand van de inschatting van investeringen en kosten worden nagegaan, of de financiële component in de beslissing voor de waarden van de RTO en RPO in redelijke verhouding staat tot de investeringen en kosten. In een ‘urenfabriek’ is bijvoorbeeld de verhouding tussen enerzijds de gemiste omzet tijdens de uitval gecombineerd met het eventuele dataverlies en anderzijds de te maken kosten een goed uitgangspunt om dit te beoordelen.

Realisatie
De realisatie is, evenals het ontwerp, vooral een technische aangelegenheid. Zoals reeds genoemd, hoop ik daar een andere keer wat over te schrijven. Momenteel ben ik zelf bezig in zo’n project en als dat een stukje verder is in de uitvoering, heb ik vast weer genoeg te melden in een nieuwe blog.

Gebruik maken van ASP of Software as a Service (SaaS)
Als je gebruikt maakt van een ASP of SaaS lijkt het bovenstaande niet van toepassing, maar dat is niet helemaal het geval. Ga maar eens na of de ASP daadwerkelijk maatregelen heeft genomen om de afgeloten Service Level Agreement (SLA) na te komen. En vraag ook eens wat is geregeld voor het geval brand ontstaat in het datacenter in de vorm van een uitwijkscenario.

Tenslotte
Het bovenstaande is misschien niet het meest boeiende in een organisatie om je mee bezig te houden, maar in het kader van informatiebeveiliging wel van essentieel belang. Misschien goed om eens een IT audit uit te laten voeren op de eigen organisatie?

Continuïteit van informatiesystemen

Bij informatiebeveiliging draait het om drie belangrijke zaken: vertrouwelijkheid, integriteit en beschikbaarheid. Alle drie moeten deze voldoende zijn gewaarborgd om van een passende informatiebeveiliging te kunnen spreken. Een van de hoofdpunten van het onderdeel beschikbaarheid is continuïteitsmanagement van de informatiesystemen en van dat onderdeel wil ik nu kort laten zien hoe ik dat sinds het begin van deze eeuw heb zien ontwikkelen. In dit artikel ga ik niet in op ontwikkelingen als ‘Sofware as a Service’ of meer recente ontwikkelingen als ‘cloud computing’, maar neem ik de eigen infrastructuur als uitgangspunt. Over die andere ontwikkelingen een andere keer vast nog wel meer.

Extra servers
Rond de eeuwwisseling, dus zo’n 10 jaar geleden, was een eerste stap het verdelen van data over meerdere servers en het dubbel uitvoeren van compenenten in de servers. Als deze maatregelen goed werden uitgevoerd, werd de beschikbaarheid wat hoger, omdat bij een probleem met een server iedereen nog wel verder kon werken. Applicaties die gebruik maakten van de andere servers, bleven dan gewoon werken. Overigens had toen elke bedrijfslocatie vaak nog z’n eigen servers en waren storingen daardoor niet zo veel omvattend. Ook werd ICT toen nog veel minder intensief gebruikt. Bij de organisatie, waar ik werk, was dit in 1999 de eerste stap toen we ons bewust werden, dat we toch wel redelijk afhankelijk aan het worden waren van computers.

Centralisatie
Eigenlijk hoort centralisatie niet thuis in het rijtje maatregelen, dat de continuïteit beter waarborgt. Door centralisatie wordt één locatie namelijk heel kritisch in de infrastructuur en worden de risico’s voor de continuïteit dus groter. Hierbij kun je denken aan de stroomvoorziening, brandveiligheid, maar ook bijv. de afhankelijkheid van de dataverbinding op de centrale locatie. Zo’n centralisatieslag heb ik zelf in 2003 uitgevoerd, omdat dit functioneel grote voordelen op ging leveren bij de implementatie van een ERP-applicatie.

Functioneel en beheerstechnisch gezien heeft centralisatie grote voordelen en door een aantal maatregelen kunnen de risico’s voor de continuïteit natuurlijk wel worden beperkt. Een praktische manier, die ik vaak zie,  is dat de centrale infrastructuur wordt verplaatst van een eigen serverruimte naar een professioneel datacenter, waardoor bijv. stroomvoorziening, brandveiligheid, koeling en dataverbindingen veel beter zijn geregeld, dan in de meeste interne serverruimtes in eigen kantoren.

Hogere beschikbaarheid bij centralisatie
In een gecentraliseerde omgeving is het wel beter mogelijk om een groot deel van de infrastructuur dubbel uit te gaan voeren en hierdoor een hogere beschikbaarheid te waarborgen. Doordat de apparatuur fysiek op
één locatie staat, is de benodigde apparatuur en/of software om hogere beschikbaarheid te regelen ook voor kleinere organisaties redelijk betaalbaar. Vaak wordt in dit stadium ook virtualisatie toegepast. De ruimte waar de apparatuur staat, blijft echter nog steeds net zo kritisch. De kans dat deze ruimte door een calamiteit wordt getroffen is misschien niet zo groot, de gevolgen zijn dat zeker wel.

In dit stadium heb ik zelf twee belangrijke trajecten uitgevoerd: in 2005 het invoeren van een databasecluster en het redundant uitvoeren van dataverbindingen. In 2007 hebben wij het grootste deel van de backend-servers gevirtualiseerd, waardoor aanzienlijk minder hardware nodig was en de beschikbaarheid toch hoger werd. Daarnaast werd door deze virtualisatieslag de recovery bij een eventuele calamiteit veel makkelijker. Na het virtualiseren van een groot deel van de servers hebben wij ook het volledige serverpark verplaatst vanuit een eigen serverruimte naar een professioneel datacenter.

Redundant datacenter of uitwijklocatie
Nog een stap verder in het waarborgen van de continuïteit is het gebruik maken van twee datacenters. Afhankelijk van de locatie van de datacenters en de beschikbare verbindingen tussen de twee datacenters zijn hiervoor twee opties.

Uitwijklocatie
De eerste optie is het opzetten van een uitwijklocatie: een ingerichte infrastructuur in een tweede datacenter, dat alleen wordt gebruikt bij een calamiteit in het eerste. Het voordel hiervan is, dat de verbinding tussen de twee locaties alleen nodig is om de data regelmatig te dupliceren. Het nadeel hiervan is dat de apparatuur op de tweede locatie in principe nooit wordt gebruikt, ofwel een erg hoge verzekeringspremie wordt betaald. Een rekenvoorbeeld: als bij uitval van de hooflocatie nog 80% van de capaciteit moet kunnen worden gebruikt, is totaal 180% nodig (100% productie plus 80% uitwijk). Daarnaast is beheertechnisch het risico best groot, dat de applicatieversies e.d. op de uitwijklocatie achterlopen op de productielocatie.

Redundant datacenter
De gunstigere optie, waarvoor wel een aanzienlijk betere verbinding tussen de datacenters nodig is, is het verdelen van de apparatuur over beide locaties, waarbij alle apparatuur actief wordt gebruikt. Bij uitval van één locatie blijft dan nog de helft van de capaciteit beschikbaar. Als dit te weinig is, hoeft in verhouding minder te worden toegevoegd dan bij de optie van de uitwijklocatie. In hetzelfde rekenvoorbeeld is dan maar 80% nodig op beide locaties, dus totaal 160%. Als beide locaties actief zijn, kan worden geprofiteerd van 160% capacteit, terwijl bij uitval van één locatie nog voldoende overblijft. Uiteraard komt er bij deze optie nog veel meer kijken, maar als ik dat allemaal ga noemen, wordt dit artikel nog drie keer zo lang. Als ik tijd en zin heb, ga ik me daar overigens nog wel een keer aan wagen in een redelijk technisch artikel.

Momenteel ben ik bezig met de uitbreiding van onze infrastructuur naar een tweede datacenter. In een bijna volledig gedigitaliseerde omgeving is dit nodig om voldoende waarborgen te hebben voor de continuïteit van de geautomatiseerde infrastructuur. Overigens zullen wij het grootste deel van de apparatuur in een active/active configuratie verdelen over de twee locaties, maar niet alles. Hoe mooi dit technisch ook mogelijk zou zijn, de kosten moeten nog steeds in redelijke verhouding staan tot de risico’s en dan is niet alles te verdedigen.

%d bloggers liken dit: