GGZ-instellingen laten gegevens patiënten uitlekken
Twee GGZ-instellingen hebben de gegevens van circa 8500 patiënten laten uitlekken. De gegevens stonden op een slecht beveiligde ontwikkelingsserver. Het ging onder meer om namen, adressen, geboortedata en burgerservicenummers.
Het beveiligingslek werd ontdekt door een groep die zichzelf het Genootschap van Hackende Huisvrouwen noemt en die het aan NU.nl rapporteerde.
Van circa 8500 patiënten waren onder meer naam, adres, geboortedatum, het zeer fraudegevoelige burgerservicenummer en niet nader toegelichte gegevens voor uitwisseling via het Elektronisch Patiëntendossier toegankelijk. Alle getroffenen waren patiënten in de geestelijke gezondheidszorg.
De gegevens stonden op een slecht beveiligde ontwikkelingsserver, waarop ook gegevens van een aantal andere instellingen te zien waren. Daarbij ging het om logingegevens van medewerkers, maar niet om patiëntgegevens. Van één zorginstelling waren voorgeschreven recepten in te zien, maar die waren niet te herleiden naar een persoon. De verantwoordelijke automatiseerder, FarMedvisie, heeft het beveiligingsprobleem inmiddels verholpen.
Reacties (47)
Heb je het artikel uberhaupt gelezen?
Het betreft een ontwikkelserver van een leverancier. Wat had de overheid hier aan kunnen doen?
De leverancier claimt het binnen 2 minuten verholpen te hebben: http://www.farmedvisie.nl/index.php?content_id=57
Het betreft een ontwikkelserver van een leverancier. Wat had de overheid hier aan kunnen doen?
De leverancier claimt het binnen 2 minuten verholpen te hebben: http://www.farmedvisie.nl/index.php?content_id=57
Wat doet zulke gevoelige data op een ontwikkelserver? Gebruik dan dummy data.Het betreft een ontwikkelserver van een leverancier. Wat had de overheid hier aan kunnen doen?
Geweldig... Maar hoe lang was het lek er al? En hoe vaak is het misbruikt voordat het was ontdekt?De leverancier claimt het binnen 2 minuten verholpen te hebben: http://www.farmedvisie.nl/index.php?content_id=57
Uit het artikel waar je een link naar geeft:
Dus er is pas een aanleiding om beveiligingsmaatregelen te evalueren zodra er een aanval is geweest?Voor ons is de aanval direct aanleiding geweest onze getroffen beveiligingsmaatregelen te evalueren. Vanaf 22 mei zijn er door ons aanvullende beveiligingsmaatregelen getroffen.
Verder uit dat artikel:
Dat was dan een goede evaluatie...Naar aanleiding van de door NU.nl aan ons op 31 mei jl. verstrekte informatie, hebben wij tot onze spijt moeten concluderen, dat wij toch iets over het hoofd hebben gezien.
[Reactie gewijzigd door The Zep Man op vrijdag 1 juni 2012 14:27]
Dat komt vaak genoeg voor. Het is immers veel makkelijker om gewoon alle bestaande data maar te gebruiken ipv nieuwe (voor een mens logische) data te genereren. Veilig is het idd absoluut niet.
Het is niet alleen makkelijker, het is ook de enige manier die werkt. Niet echte data is altijd precies volgens de specificaties, en je kunt er dus niet mee testen met de corrupte, vervuilde data die in een echte database zit.
Niet alles simuleer je zomaar even met dummy data. Wat dacht je bijvoorbeeld van data migratie bij updates. Je dummy data kan werken, maar bij de echte data kan het mislopen. Eerst even dus een dry run doen met de echte data. En zo zijn er nog wel situaties te bedenken waar je liever toch echte data wenst te gebruiken.
En ja, de overheid blijft verantwoordelijk voor eventuele schade, maar het is niet de schuld van de overheid dat deze data gelekt is. Iedereen staat altijd maar te roepen dat het bij de overheid altijd misgaat en dat ze dit soort taken aan een private firma moeten uitbesteden. Doen ze dat geef jij hen nog altijd de schuld. Zullen we de hele overheid dan misschien maar per direct privatiseren?
En ja, de overheid blijft verantwoordelijk voor eventuele schade, maar het is niet de schuld van de overheid dat deze data gelekt is. Iedereen staat altijd maar te roepen dat het bij de overheid altijd misgaat en dat ze dit soort taken aan een private firma moeten uitbesteden. Doen ze dat geef jij hen nog altijd de schuld. Zullen we de hele overheid dan misschien maar per direct privatiseren?
Ik had mijn opmerking over de (eind)verantwoordelijkheid van de overheid al weggehaald, aangezien ik niet 100% zeker ben hoe het zit met deze data (zijn GGZ instellingen misschien niet (deels) geprivatiseerd, etc.).En ja, de overheid blijft verantwoordelijk voor eventuele schade, maar het is niet de schuld van de overheid dat deze data gelekt is. Iedereen staat altijd maar te roepen dat het bij de overheid altijd misgaat en dat ze dit soort taken aan een private firma moeten uitbesteden. Doen ze dat geef jij hen nog altijd de schuld. Zullen we de hele overheid dan misschien maar per direct privatiseren?
Maar je moet niet schrijven dat ik de overheid de schuld gaf, want dat deed ik namelijk niet. Ik schreef dat ze eindverantwoordelijk waren.
Inderdaad, en ik maakte me ook regelmatig schuldig aan het gebruiken van live data, ik werk ook aan een systeem met patientdata.
Dummy data is eenvoudig een stukje minder persoonlijk te maken door een query als deze (in geval van MySQL):
UPDATE patienten SET BSN='12345678', naam=MD5(naam);
Dat de BSN nummers niet echt zijn en de naam gescrambled is zorgt meestal niet voor data die niet met een live omgeving te vergelijken is en anders werkt. Twee veldjes zijn nog wel af te vangen.
Net zo belangrijk is dat je op de testomgeving dezelfde beveiliging toepast als op live.
Dummy data is eenvoudig een stukje minder persoonlijk te maken door een query als deze (in geval van MySQL):
UPDATE patienten SET BSN='12345678', naam=MD5(naam);
Dat de BSN nummers niet echt zijn en de naam gescrambled is zorgt meestal niet voor data die niet met een live omgeving te vergelijken is en anders werkt. Twee veldjes zijn nog wel af te vangen.
Net zo belangrijk is dat je op de testomgeving dezelfde beveiliging toepast als op live.
@Blokker_1999, wat een onzin. Je kan data prima scramblen. Zo doet de concurent het ook 
I know that for a fact!
I know that for a fact!
Ik wil het niet goedpraten, maar je kunt in je specificaties natuurlijk mooi hebben staan watvoor informatie er binnen het systeem zou moeten komen, maar je komt vaak in 'het echt' gewoon informatie tegen die op heel andere manieren zijn ge-encode, of toch, ondanks alle restricties vreemde tekens bevatten.
Je kunt je testdata nog zo "reeel" proberen te houden, er kan net zo goed iemand iets direct in een database-record hebben aangepast, wat normaliter niet door een validatiesysteem zou komen. Als jij die data dan weer (op welke wijze dan ook) in je systeem tegenkomt, dan kan het best fout gaan. Het zou dus best een manier kunnen zijn om dit testen.
Nogmaals, ik praat het niet goed, maar er zijn best situaties denkbaar dat je echte data door je systeem wilt laten lopen. Dat het dan foutgaat en dat de data niet is weggehaald, is inderdaad een zeer kwalijke zaak.
Je kunt je testdata nog zo "reeel" proberen te houden, er kan net zo goed iemand iets direct in een database-record hebben aangepast, wat normaliter niet door een validatiesysteem zou komen. Als jij die data dan weer (op welke wijze dan ook) in je systeem tegenkomt, dan kan het best fout gaan. Het zou dus best een manier kunnen zijn om dit testen.
Nogmaals, ik praat het niet goed, maar er zijn best situaties denkbaar dat je echte data door je systeem wilt laten lopen. Dat het dan foutgaat en dat de data niet is weggehaald, is inderdaad een zeer kwalijke zaak.
Je valideert gewoon alle bestaande data volgens dezelfde regels (op een niet remote toegankelijk systeem), lost evt. problemen op, en dan migreer je pas.
Echte data gebruiken tijdens de ontwikkeling is luiheid en verkeerd om werken.
Echte data gebruiken tijdens de ontwikkeling is luiheid en verkeerd om werken.
Het probleem is niet in 2 minuten verholpen.
Ze hebben de aanval binnen 2 minuten gesignaleerd. Er staat niets over hoe snel ze het probleem verholpen hebben.
Ze hebben de aanval binnen 2 minuten gesignaleerd. Er staat niets over hoe snel ze het probleem verholpen hebben.
Waarschijnlijk hebben ze de ontwikkel server offline gehaald, dan is het probleem "verholpen".
GGZ instellingen zijn doorgaans helemaal geen overheid.
Genootschap van Hackende Huisvrouwen.
Klinkt beter dan Anonymous; Internet Hate Machine.
En wie zei nou dat persoonsgegevens altijd veilig zijn bij de overheid? Lang leve het EPD.
Klinkt beter dan Anonymous; Internet Hate Machine.
En wie zei nou dat persoonsgegevens altijd veilig zijn bij de overheid? Lang leve het EPD.
Mét een EPD was dit waarschijnlijk niet voorgekomen.... Daar was namelijk bij voorbaat zoveel heibel over, dat alles driedubbel gecontroleerd wordt op de veiligheid.
Het probleem is nú juist dat zorginstellingen zelf individueel allerlei kleine bedrijfjes gaan inschakelen om de software te schrijven, i.p.v. dat dit integraal in een groot process wordt gedaan. En bij die kleinschalige projectjes, zal juist de veiligheid makkelijker vergeten worden.
Het probleem is nú juist dat zorginstellingen zelf individueel allerlei kleine bedrijfjes gaan inschakelen om de software te schrijven, i.p.v. dat dit integraal in een groot process wordt gedaan. En bij die kleinschalige projectjes, zal juist de veiligheid makkelijker vergeten worden.
tjsah, alhoewel dit niet direct opgaat voor de GGZ, had een -door experts- centraal beheerd systeem dit kunnen voorkomen. Ik heb het dan natuurlijk over het EPD.
Dit zal zeker niet de laatste schandelijke fout zijn in de zorgsector, helaas.
@wnoise92 dit heeft natuurlijk niets te maken met overheid, maar met een private instelling / bedrijf
Dit zal zeker niet de laatste schandelijke fout zijn in de zorgsector, helaas.
@wnoise92 dit heeft natuurlijk niets te maken met overheid, maar met een private instelling / bedrijf
[Reactie gewijzigd door TheNymf op vrijdag 1 juni 2012 14:17]
Het EPD waar jij het over had was een koppeling van lokale EPDs en zou dit probleem dus niet verhelpen. Iedereen blijft dan het eigen systeem houden maar die communiceren via een landelijk schakelpunt. Dit zou het risico juist vergroten omdat de systemen aangesloten moeten worden op de buitenwereld.
Tja, als je ervan uitgaat dat er geen toelatingseisen zijn.
Gelukkig zijn die er, en worden ze gehandhaafd. Zie hier het commentaar van het Servicecentrum Zorgcommunicatie:
Gelukkig zijn die er, en worden ze gehandhaafd. Zie hier het commentaar van het Servicecentrum Zorgcommunicatie:
Bron: http://www.hpdetijd.nl/20...overheid-laat-ons-hacken/Servicecentrum Zorgcommunicatie 1 juni 2012 om 16:58
In de pers wordt gesteld dat EPD gegevens van een tweetal GGZ instellingen gelekt zijn door een hack op de applicatie van het bedrijf FarMedvisie. De link wordt gelegd met de doorstart van het LSP in gewijzigde vorm. Deze link is onterecht. FarMedvisie is momenteel niet gekoppeld aan het LSP en heeft nooit daadwerkelijke patiëntgegevens uitgewisseld over het LSP. Wel is FarMedvisie in voorbereiding daarop.
Daartoe worden testen en kwalificatietrajecten doorlopen, waarbij testgegevens worden uitgewisseld. In 2007 is FarMedvisie gekwalificeerd tegen de toen geldende kwailiteits-eisen. Momenteel worden zij geherkwalificeerd tegen de huidige kwaliteits-eisen, maar dit traject is niet afgerond. Voordat aan deze zware eisen is voldaan, is het klanten van FarMedvisie niet toegestaan gegevens uit te wisselen via het LSP.
Waarom zou je echte gegevens gebruiken op een ontwikkelingsserver? Kleine moeite om een database met dummy data te maken lijkt me.
Een kleine moeite om dummy data van 8500 personen te generen? Dat is een verdomd groot karwei!
NB: Je dummy data wil je niet met een computer genereren. Want dan weet je dat alles perfect is ingevuld. Je wilt juist tegen met handmatig ingevulde data, omdat er dan allerlei rare bugs naar boven komen, die je anders nooit was tegengekomen.
Helemaal niet zo raar dat ze dus echte data gebruiken, want dat is de ultieme test omgeving. Maar wel fout natuurlijk dat het dan zo slecht beveiligd is. Verder hadden ze natuurlijk even de namen en service nummers kunnen anonymiseren.
NB: Je dummy data wil je niet met een computer genereren. Want dan weet je dat alles perfect is ingevuld. Je wilt juist tegen met handmatig ingevulde data, omdat er dan allerlei rare bugs naar boven komen, die je anders nooit was tegengekomen.
Helemaal niet zo raar dat ze dus echte data gebruiken, want dat is de ultieme test omgeving. Maar wel fout natuurlijk dat het dan zo slecht beveiligd is. Verder hadden ze natuurlijk even de namen en service nummers kunnen anonymiseren.
[Reactie gewijzigd door AHBdV op vrijdag 1 juni 2012 15:11]
Een deel van een database shuffle-en. Her en der wat data verminken of veranderen, en het resultaat als dummy gebruiken. Gaat heel goed.Een kleine moeite om dummy data van 8500 personen te generen? Dat is een verdomd groot karwei!
NB: Je dummy data wil je niet met een computer genereren. Want dan weet je dat alles perfect is ingevuld.
dat het moeite kost is geen reden om geen dummy data te gebruiken. Alle beveiliging en privacy kost moeite. Privacy gevoelige data hoort per definitie niet op ontwikkelservers te staan.
Lees de laatste zin eens...
In principe mag je gewoon geen echte data gebruiken bij test en ontwikkeling, echte data wordt pas valide wanneer je functionele testen gaat doen met gebruikers waarbij het systeem al onderdeel uit maakt van de omgeving van de klant.
Ten eerste wil ik niet dat een niet gecertificeerd persoon welke de waarde van de data kan inschatten inzage heeft in mijn persoonlijke gegevens. Het zou toch van de zotte zijn dat alle medische en overige informatie over jou bij een conculega bedrijf ligt en dat mensen daar inzage in hebben.
Daarnaast voldoen de eigenlijke gebruikers aan een aantal verplichtingen met betrekking tot geheimhouding etc. en een ontwikkelaar/tester per definitie niet.
Daarnaast is er ook nog zo iets als gebruik van je persoonlijke gegevens. Een software bedrijf gebruikt jouw gegevens voor ontwikkeling/testen van een product waar ze geld aan verdienen. Persoonlijk ben ik van mening dat ik dan ook recht heb op een gedeelte van de opbrengst. Stel je zit in een testset van 10.000 records. Het bedrijf verdiend 1.000.000 euro met verkoop van het product, dat wil zeggen dat ik recht heb op 100 euro, want dat zijn die gegevens waard binnen de testset. Argumenten dat het minder moet zijn zijn voor mij niet valide want dan hadden ze me maar uit de testset moeten gooien.
Overigens is het annonimiseren van een database met zinnige data totaal geen probleem, het is vrij intensief en kan geautomatiseerd plaatsvinden. Het enige wat moeilijk te anonimiseren is zijn adressen. Telefoonnummers (met behoud van kengetal), namen, sofi nummers, bankrekeningnummers, etc. etc. zijn binnen een database te shuffelen. Zolang er maar geen directe koppeling is tussen adres - telefoon - sofinummer - bankrekeningnummer is het goed. Geboorteplaatsen en -datum's zijn ook makkelijk te annonimiseren. dus ik zie het probleem niet.
Ten eerste wil ik niet dat een niet gecertificeerd persoon welke de waarde van de data kan inschatten inzage heeft in mijn persoonlijke gegevens. Het zou toch van de zotte zijn dat alle medische en overige informatie over jou bij een conculega bedrijf ligt en dat mensen daar inzage in hebben.
Daarnaast voldoen de eigenlijke gebruikers aan een aantal verplichtingen met betrekking tot geheimhouding etc. en een ontwikkelaar/tester per definitie niet.
Daarnaast is er ook nog zo iets als gebruik van je persoonlijke gegevens. Een software bedrijf gebruikt jouw gegevens voor ontwikkeling/testen van een product waar ze geld aan verdienen. Persoonlijk ben ik van mening dat ik dan ook recht heb op een gedeelte van de opbrengst. Stel je zit in een testset van 10.000 records. Het bedrijf verdiend 1.000.000 euro met verkoop van het product, dat wil zeggen dat ik recht heb op 100 euro, want dat zijn die gegevens waard binnen de testset. Argumenten dat het minder moet zijn zijn voor mij niet valide want dan hadden ze me maar uit de testset moeten gooien.
Overigens is het annonimiseren van een database met zinnige data totaal geen probleem, het is vrij intensief en kan geautomatiseerd plaatsvinden. Het enige wat moeilijk te anonimiseren is zijn adressen. Telefoonnummers (met behoud van kengetal), namen, sofi nummers, bankrekeningnummers, etc. etc. zijn binnen een database te shuffelen. Zolang er maar geen directe koppeling is tussen adres - telefoon - sofinummer - bankrekeningnummer is het goed. Geboorteplaatsen en -datum's zijn ook makkelijk te annonimiseren. dus ik zie het probleem niet.
Je hebt gewoon gelijk, Bedrijf X gebruikt hier gevoelige data van een zorginstelling om een product mee te ontwikkelen. Dat lijkt me gewoon een schending van je privacy en het overtreden van een aantal wetten.
Ik ben benieuwd naar welke 2 GGZ-instellingen gegevens hebben laten uitlekken.
Hier staan de klanten van FarMedvisie: http://www.farmedvisie.nl/index.php?content_id=19
en daar staan niet zo veel GGZ-instellingen bij.
en daar staan niet zo veel GGZ-instellingen bij.
Leuk is dat. Ik sta zelf nog ergens bij een aantal GGZ-instellingen in het dossier en kan dus nu ook niet uitvissen of ik (misschien) tot één van de gedupeerden behoor.Omdat de betrokkenen nog niet zijn geïnformeerd en het een kwetsbare groep mensen betreft met een hulpvraag in de geestelijke gezondheidszorg, heeft NU.nl ervoor gekozen de namen van de zorginstellingen nog niet naar buiten te brengen.
Mijn NAW-gegevens en BSN maak ik me niet zo'n zorgen om, die moet ik als eigen ondernemer toch al publiceren, maar mijn medische achtergrondgegevens hou ik toch liever privé.
idem 
liever niet dat m'n dossiers gewoon rondzwerven op het internet
wat doen die dossiers op een ontwikkelingsserver? echt kansloos dit
dankje E-Rick, mijn instelling zit er iig niet bij
liever niet dat m'n dossiers gewoon rondzwerven op het internet
wat doen die dossiers op een ontwikkelingsserver? echt kansloos dit dankje E-Rick, mijn instelling zit er iig niet bij
[Reactie gewijzigd door ArcticWolf op vrijdag 1 juni 2012 14:30]
zie mijn reply hier boven 
Als wij het hier op het werk in ons hoofd krijgen (een bank!) om produktiedata op een Test of Ontwikkelserver te zetten, kunnen we net zo goed direct de boel sluiten en zijn we zo onze banklicentie kwijt.
Je gebruikt NOOIT proddata op een ontwikkelomgeving... en al helemaal niet als het om gevoelige info gaat.
Dan kan je zeggen "ja maar soms is het nodig voor testen"... dan blijft het antwoord NEE.. dan verzin je maar een list.
Je gebruikt NOOIT proddata op een ontwikkelomgeving... en al helemaal niet als het om gevoelige info gaat.
Dan kan je zeggen "ja maar soms is het nodig voor testen"... dan blijft het antwoord NEE.. dan verzin je maar een list.
Je wilt zeggen dat je handmatig een dummyset gaat aanmaken?
Bij een bank heb je vaak klanten, rekeningen, rekeningsoorten, medewerkers, transacties, leningen en zo nog een aantal tabellen. Dat is zo enorm veel data dat het amper te vullen is.
Wat wel een optie is, is om de productie data te gebruiken, de foreign keys ongemoeid te laten en alle gegevens die tot personen kunnen herleiden (NAW-gegevens) te vervangen door dummy-data.
Bij een bank heb je vaak klanten, rekeningen, rekeningsoorten, medewerkers, transacties, leningen en zo nog een aantal tabellen. Dat is zo enorm veel data dat het amper te vullen is.
Wat wel een optie is, is om de productie data te gebruiken, de foreign keys ongemoeid te laten en alle gegevens die tot personen kunnen herleiden (NAW-gegevens) te vervangen door dummy-data.
Euh, wij hebben op onze ontwikkelomgevingen ook dummy data, en de staging omgeving zit in dezelfde beveiligingszone als de productieomgeving. De staging omgeving wordt alleen maar opgebouwd vanuit productie, op de dag voor de migratie van productie, voor het testen van de conversiescripts en de geconverteerde kopie van productie en daarna weer afgebouwd. Test- en development draaien op de dummy data.
En dan hebben we niet eens medische gegevens in de DB. Lijkt me standaard practice imho.
En dan hebben we niet eens medische gegevens in de DB. Lijkt me standaard practice imho.
Dev/staging/production is een omgeving die lang niet ieder bedrijf heeft. Daarvoor moet je een zekere minimum grootte hebben.
Als opdrachtgever zou je dat als eis mee moeten nemen in je leveranciersselectie, zeker bij privacy gevoelige data volgens Wet Bescherming Persoonsgegevens II. De wet is hier ook van toepassing: medische gegevens zijn hoogste categorie.
Dus elke leverancier die niet in staat is tot OTAP / Dev-staging/prod valt imho af.
Ik heb zelf jarenlang conversies gedraaid. Opties die we hadden:
- op een virtual, lokaal, zonder internetverbinding.
- via een subnet van het LAN, zonder toegang van buitenaf.
- sommige omgevingen zijn complex en niet eenvoudig na te bouwen: dan via een remote sessie (RDT, Citrix) op een in een DMZ geplaatste ontwikkeldesktop met toegang tot de omgeving, inclusief token.
Nogmaals, elke leverancier die niet in staat is te voldoen aan passende beveiligingsmaatregelen, ook voor OTAP, valt af. Wat passend is, is aan de opdrachtgever om te bepalen in de requirements. De opdrachtgever kan de oplossing altijd laten valideren door een ingehuurde expert. Ook daarvoor zou een opdrachtgever capaciteit moeten inhuren.
Dus elke leverancier die niet in staat is tot OTAP / Dev-staging/prod valt imho af.
Ik heb zelf jarenlang conversies gedraaid. Opties die we hadden:
- op een virtual, lokaal, zonder internetverbinding.
- via een subnet van het LAN, zonder toegang van buitenaf.
- sommige omgevingen zijn complex en niet eenvoudig na te bouwen: dan via een remote sessie (RDT, Citrix) op een in een DMZ geplaatste ontwikkeldesktop met toegang tot de omgeving, inclusief token.
Nogmaals, elke leverancier die niet in staat is te voldoen aan passende beveiligingsmaatregelen, ook voor OTAP, valt af. Wat passend is, is aan de opdrachtgever om te bepalen in de requirements. De opdrachtgever kan de oplossing altijd laten valideren door een ingehuurde expert. Ook daarvoor zou een opdrachtgever capaciteit moeten inhuren.
Het meest verontrustende vind ik nog dat er nogal wat waarde aan een burgerservicenummer wordt gehangen, wat in principe niet geheim zou moeten hoeven worden gehouden (het staat immers ook open en bloot op je rijbewijs en paspoort).
Maar kennelijk is alleen dit nummer vaak afdoende omdat bedrijven cq de overheid het de burger "makkelijk" wil maken om zaken te regelen.
Maar kennelijk is alleen dit nummer vaak afdoende omdat bedrijven cq de overheid het de burger "makkelijk" wil maken om zaken te regelen.
Het gaat trouwens o.a. om GGZ Noord-Holland-Noord:
http://www.ggz-nhn.nl/Nie...ke-gezondheidszorg-gelekt
http://www.ggz-nhn.nl/Nie...ke-gezondheidszorg-gelekt
Misschien is het al geroepen, maar wat doet een ontwikkelserver dan aan een blijkbaar publiekelijk toegankelijk netwerk?
Misschien simplistisch gedacht, maar als je dan om welke reden dan ook met prod-data moet gaan testen, zorg er dan voor dat het op een geisoleerde infra draait.
Of zie ik iets over het hoofd ?
Misschien simplistisch gedacht, maar als je dan om welke reden dan ook met prod-data moet gaan testen, zorg er dan voor dat het op een geisoleerde infra draait.
Of zie ik iets over het hoofd ?
Op dit item kan niet meer gereageerd worden.
Populair: Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Politiek en recht Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
