Onderhoud aan de website veroorzaakte bij Rabobank donderdagochtend 7 april 2011 een storing in het internetbankieren. Klanten kregen de bankrekening van een ander te zien. Rabobank haalde direct het internetbankieren offline en zegt het probleem inmiddels te hebben opgelost.
Onderhoud aan de Rabobank-website was de aanleiding van de storing. De bank zoekt nog uit wat het onderhoud precies inhield en wat er dus voor heeft gezorgd dat het fout ging bij het internetbankieren. Voor de zekerheid heeft Rabobank zowel het internetbakieren uit de lucht gehaald, als de normale website, de mobiele apps en de telefonische bankierfunctie. Voor zover bekend konden er tijdens de storing geen betalingen worden gedaan vanaf andermans rekening.
Eerdere storing
In oktober 2010 had Rabobank ook te maken met een storing. Toen kon een deel van de Rabobank-klanten niet inloggen bij het internetbankieren. Het probleem zat toen in de automatische systeemkoppeling tussen de wereldpassen en internetbankieren. Passen die op 5 en 6 augustus 2010 waren aangemaakt, kampten met het probleem. Volgens de Rabobank waren toen enkele tientallen klanten de dupe.
Het maakt helemaal niks uit welke webservers gebruikt zijn voor een dergelijke fout, of er nou IIS of iets anders gebruikt wordt. Waarschijnlijk is er een verkeerde query gedraaid waardoor na inloggen de verkeerde rekeninggegevens opgehaald worden. Als dat het geval is, is de oplossing simpel voor in de toekomst: check, check en dubbelcheck NOG BETER je queries voordat je deze uitvoert…
Knutsel
Onzinverhaal. Je zei dat de Rabobank geen IIS gebruikt. Dat doen ze dus wel, over welke laag is nu geen relevante discussie aangezien je zei dat ze het NIET gebruiken.
@knutsel e.a.
Ik zeg ook niet dat alle applicatie servers een IIS frontend farm gebruiken. Kan me voorstellen dat voor een hybride oplossing is gekozen en dat de financiele transactiesystemen strict gescheiden moet zijn qua technologie als de frontend servers…. Anders kom je de audits al meteen niet door. Dus die queries waar IT-er mee komt, lijken me ook niet de oorzaak.
ECHTER, dit probleem lijkt alles te maken te hebben met de frontend servers, die delen de sessieIDs uit. Veel architecten vinden frontend servers minder belangrijk ,zetten daar de stempel “niet business/mission critical” op,want deze hebben de functie om gegevens vanuit backend systemen alleen maar te tonen; wie wat mag zien wordt daar niet geregeld. (hoop ik) Dat ze ook nog een functie hebben om het HTTP protcol statefull te ‘laten lijken’ , wordt vaak vergeten of geacht dat een webserver dat automagisch regelt. Dat klopt ! Maar dus niet altijd ! Aannemlijk is dat dat de login een sessionID heeft opgeleverd die meerdere keren is uitgegeven. Tijdens je sessie was de gebruiker eerst nog jezelf op de frontend server, maar na een aantal requests kun je dan iemand anders worden, omdat de webserver de requests niet meer uit elkaar kan halen.
Ik weet niet of dat hier ook gebeurt is, maar ik geef alleen aan dat deze casus me iets te bekend voor komt. Ook omdat je dit in labtests bijna niet kunt reproduceren, omdat dit alleen voorkomt onder specifieke high-load omstandigheden. Voordat ik deze conclusie in mijn geval kon trekken, heeft mij dit een half jaar onderzoek gekost i.s.m. Microsoft Redmond die daarna heeft besloten deze kernel caching in volgende versies uit te zetten !
Ik denk ook wel dat de fout in verwisseling van sessies zit. Misschien stelt iemand zich voor dat een bank draait op 2 PC’s en dat de hele administratie van de bank bestaat uit een paar MySQL tabellen. Zo is het niet. Alles draait om onvoorstelbaar grote getallen en een tekening met alle betrokken hardware voor telebankieren beslaat meerdere A3-tjes. Wat denk je dat er gebeurt als alle 5 miljoen klanten van een bank kerstinkopen gaan doen ? Daar zijn die systemen op berekend. Ik denk eerder dat het iets banaals is als 2 machines hetzelfde ip-adres geven, na een verhuizing. Ik denk niet dat dit de schuld is van een programmeur.
@SP: Rabobank en Rabobank International, zijn 2 totaal verschillende partijen, zelfs hun bestuur is niet gelijk, dus wat probeer je nu met Schuberg Phillis aan te geven?
Daarnaast is Schuberg Phillis één van de meest hoogstaanste beheer partijen die Nederland ooit heeft gekend, kijk maar eens naar hun klanten portifolio, dat is niet voor niks, met zulke extreem grote namen er in.
Geeft me wel te denken over welke kennis jij beschikt…
Ik kan me ook voorstellen dat dit een ordinair caching probleem is. Er wordt een sessieId uitgedeeld, die staat nog in cache (van een tijd geleden) en wordt wordt vervolgens doodleuk verkeerd gekoppeld. Het niet schonen van cache kan dergelijke problemen opleveren.
Dat zou even logisch als simpel als stupide zijn.
Wat de (technische) oorzaak ook geweest is, dit mag nooit en ten nimmer gebeuren. Dat zou (en zal waarschijnlijk) ook wel als hoofdrequirement gesteld zijn, maar is onvoldoende uitgewerkt naar subrequirements die zowel technisch als procesmatig kunnen zijn. In de praktijk zie je vaak dat als er aandacht wordt besteed aan requirements, dat het dan vaak nog high level requirements zijn. We weten echter dat de devil in the detail zit en dus zou er meer aandacht besteed moeten worden aan risico-analyse, subrequirements en last but not least degelijk testen. Dat testen zal wel gebeurd zijn, geen twijfel, maar het verschil tussen testen en goed testen kan ook bij grote bedrijven nog het verschil maken.
Betalen met mijn PINpas lukte donderdagmiddag 7 april niet; mijn pas werd geblokkeerd omdat ik een verkeerde code zou hebben gebruikt. Gelukkig kon de blokkering wel opgeheven worden. Later in de middag werkte de PINcode weer prima.
Lees ook eens de reacties bij:
https://www.computable.nl/artikel/ict_topics/internet/3879480/1282763/markt-gist-naar-oorzaak-storing-rabobank.html?utm_source=Nieuwsbrief#3880068
Internetbankieren, het versturen van email en andere internettoepassingen waarvan verwacht wordt dat het allemaal de gewoonste zaak is van de wereld is in werkelijkheid op de achtergrond nog steeds een complexe zaak. Het draait allemaal om komma’s, puntjes, codes , regeltjes, procedures, processen etc. Erg fragiel dus. Daarom kan nooit 100% garantie worden gegeven worden.
En als het een keer fout gaat, dan gaat het goed fout en sta je met je gezicht in de media en word je slachtoffer van de belevenis en perceptie van de maatschappij die over je heen valt. Want als je als bedrijf honderden miljoenen per jaar spendeert aan IT, hoe kan zoiets ‘simpels’ dan fout gaan?