Wanneer een cyberincident toeslaat, staat identiteitsbeheer zelden bovenaan de herstellijst. Toch is het precies dit onderdeel dat bepaalt of medewerkers binnen uren of pas na dagen weer toegang hebben tot de systemen die er het meest toe doen. In dit artikel beantwoorden we de meest gestelde vragen over de rol van identiteitsbeheer bij disaster recovery, zodat je weet wat er op het spel staat en hoe je het goed aanpakt.<\/p>\n\n
Identiteitsbeheer is het geheel van processen, beleid en technologie waarmee een organisatie bepaalt wie toegang heeft tot welke systemen, applicaties en data. Bij disaster recovery is identiteitsbeheer cruciaal, omdat herstel zonder werkende identiteitsinfrastructuur onmogelijk is: medewerkers kunnen niet inloggen, beheerders missen de rechten om systemen te starten en kritieke applicaties blijven onbereikbaar.<\/p>\n\n
Veel organisaties denken bij disaster recovery in de eerste plaats aan back-ups, servers en netwerken. Maar zonder een functionerende identiteitslaag, zoals Active Directory, Entra ID of een vergelijkbaar systeem, heeft herstel van al die andere componenten weinig zin. Identiteiten zijn de sleutels tot het digitale bedrijf. Als die sleutels ontbreken, beschadigd zijn of in handen van aanvallers vallen, staat alles stil.<\/p>\n\n
Identiteitsbeheer raakt daarmee direct aan het concept van de Minimum Viable Company<\/a>: de minimale set aan systemen en processen die een organisatie nodig heeft om na een incident operationeel te blijven. Identiteit, communicatie en kernapplicaties vormen daarin de eerste prioriteit.<\/p>\n\n Identiteitsbeheer bepaalt direct hoe snel een organisatie na een incident weer operationeel is. Als identiteitssystemen zijn aangetast, versleuteld of onbeschikbaar zijn, kunnen medewerkers en beheerders niet inloggen. Elk uur dat de identiteitsinfrastructuur niet functioneert, verlengt de totale hersteltijd van alle andere systemen die daarvan afhankelijk zijn.<\/p>\n\n In de praktijk zien we dat organisaties die hun identiteitssystemen niet apart hebben beschermd en geborgd, bij een ransomware-aanval vastlopen op een fundamenteel probleem: de beheerders die het herstel moeten uitvoeren, hebben zelf geen toegang meer. Dat leidt tot een vicieuze cirkel waarbij herstelacties vertraging oplopen, niet door technische onmogelijkheden, maar door het ontbreken van werkende identiteiten en rechten.<\/p>\n\n Een ge\u00efsoleerde, schone back-up van de identiteitsinfrastructuur, gecombineerd met een duidelijk herstelproces, kan het verschil maken tussen herstellen in uren of in weken. Moderne platforms zoals Commvault bieden hiervoor specifieke functionaliteit onder de noemer Identity Resilience: het beschermen van identiteitssystemen, het voorkomen van ongewenste wijzigingen en het herstellen van betrouwbare, schone toegang op schaal.<\/p>\n\n Als identiteitsbeheer ontbreekt of niet is meegenomen in de crisisvoorbereiding, ontstaan er tijdens een cyberincident meerdere ernstige risico’s tegelijk. De gevolgen gaan verder dan alleen vertraagd herstel en kunnen de schade van een incident aanzienlijk vergroten.<\/p>\n\n De meest voorkomende risico’s zijn:<\/p>\n\n Identiteitsbeheer gaat over het beheren van wie iemand is binnen een digitale omgeving: accounts, rollen, attributen en de levenscyclus daarvan. Toegangsbeheer gaat over wat iemand mag doen met die identiteit: welke systemen, applicaties en data zijn bereikbaar. Bij disaster recovery zijn beide nodig, maar ze vereisen een andere aanpak en prioriteit.<\/p>\n\n In een herstelscenario is identiteitsbeheer de eerste stap: zorg dat de identiteitsinfrastructuur zelf beschikbaar, schoon en betrouwbaar is. Pas daarna heeft het zin om toegangsbeleid te herstellen en te controleren. Toegangsbeheer zonder een betrouwbare identiteitslaag is als het vergrendelen van deuren terwijl de sloten zelf zijn aangetast.<\/p>\n\n Concreet betekent dit voor een disaster recovery plan dat identiteitssystemen zoals Active Directory of Entra ID een hogere herstelprioritering krijgen dan veel andere applicaties. Zodra de identiteitsinfrastructuur staat, kunnen toegangsrechten worden gecontroleerd, overtollige of gecompromitteerde accounts worden geblokkeerd en medewerkers stap voor stap worden voorzien van werkende, veilige toegang.<\/p>\n\n Identiteitsbeheer inrichten als onderdeel van een disaster recovery plan betekent dat je de identiteitsinfrastructuur behandelt als kritieke bedrijfscomponent met een eigen herstelprocedure, back-upstrategie en testcyclus. Het is geen bijlage bij het plan, maar een kernonderdeel.<\/p>\n\n Een praktische aanpak bestaat uit de volgende stappen:<\/p>\n\n Wil je weten hoe jouw organisatie er nu voor staat op het gebied van identiteitsbescherming en herstel<\/a>? Een gerichte assessment geeft snel inzicht in de kwetsbaarheden en prioriteiten.<\/p>\n\n De meest voorkomende fouten in identiteitsbeheer die disaster recovery vertragen, zijn geen complexe technische problemen. Het zijn organisatorische en procesmatige tekortkomingen die pas zichtbaar worden op het moment dat ze de meeste schade aanrichten: tijdens een crisis.<\/p>\n\n Fouten die we regelmatig terugzien zijn onder andere het niet apart back-uppen van identiteitssystemen, het ontbreken van noodaccounts met gedocumenteerde toegangsprocedures en het niet testen van identiteitsherstel als onderdeel van disaster recovery drills. Daarnaast hebben veel organisaties geen actueel overzicht van alle accounts en rechten, waardoor het tijdens een incident onduidelijk is welke accounts veilig zijn en welke mogelijk zijn gecompromitteerd.<\/p>\n\n Een andere veelgemaakte fout is het behandelen van identiteitsherstel als een technische taak van de IT-afdeling, terwijl het in werkelijkheid een gezamenlijke verantwoordelijkheid is van IT, security en management. Zonder duidelijk eigenaarschap en communicatielijnen ontstaan er tijdens een incident vertragingen die eenvoudig te voorkomen waren.<\/p>\n\n Wij helpen organisaties om identiteitsbeheer structureel te verankeren in hun disaster recovery aanpak, zodat herstel na een cyberincident niet vastloopt op ontbrekende of aangetaste identiteiten. Onze aanpak is concreet en gericht op uitvoerbaarheid, niet op rapporten die in een la verdwijnen.<\/p>\n\n Wat wij bieden op dit vlak:<\/p>\n\n Wil je weten hoe jouw organisatie er nu voor staat? Neem contact met ons op<\/a> en we kijken samen waar de grootste risico’s zitten en hoe we die praktisch aanpakken.<\/p>\n \n De hersteltijd varieert sterk en hangt af van de voorbereiding van een organisatie. Zonder ge\u00efsoleerde back-ups en gedocumenteerde herstelprocessen kan herstel van systemen zoals Active Directory meerdere dagen tot weken duren. Organisaties die identiteitsherstel actief hebben ingericht en getest, slagen er doorgaans in om binnen enkele uren weer basistoegang te bieden aan kritieke medewerkers. <\/p>\n <\/div>\n \n Noodaccounts zijn vooraf aangemaakte beheerdersaccounts die uitsluitend bedoeld zijn voor gebruik tijdens een crisis, wanneer reguliere authenticatiemiddelen niet beschikbaar zijn. Ze worden opgeslagen buiten de normale identiteitsinfrastructuur, bijvoorbeeld in een fysiek beveiligde kluis of een offline wachtwoordmanager, en zijn voorzien van gedocumenteerde toegangsprocedures. Zorg ervoor dat deze accounts periodiek worden getest en dat de toegangsprocedure bekend is bij minimaal twee verantwoordelijke personen binnen de organisatie. <\/p>\n <\/div>\n \n Ja, cloudgebaseerde identiteitsoplossingen zoals Entra ID brengen andere risico's met zich mee dan on-premises systemen zoals Active Directory. Hoewel de beschikbaarheid doorgaans hoger is, blijven risico's zoals gecompromitteerde beheerdersaccounts, verkeerde configuraties en ongewenste wijzigingen in rollen en rechten re\u00ebel. Aanvullende maatregelen zoals het monitoren van wijzigingen, het beschermen van beheerdersaccounts met phishing-resistente MFA en het gebruik van back-upoplossingen specifiek voor cloudidentiteiten zijn dan ook essentieel. <\/p>\n <\/div>\n \n Dit vereist een actueel en volledig overzicht van alle accounts, rechten en recente activiteiten binnen je identiteitsomgeving, iets wat veel organisaties helaas niet op orde hebben. Tijdens een incident kun je gebruikmaken van logbestanden, SIEM-data en identity threat detection tools om verdachte aanmeldingen, ongebruikelijke rechtenwijzigingen of laterale bewegingen te identificeren. Een periodieke audit van accounts en rechten v\u00f3\u00f3r een incident maakt het tijdens een crisis aanzienlijk eenvoudiger om snel onderscheid te maken tussen veilige en mogelijk aangetaste accounts. <\/p>\n <\/div>\n \n Minimaal \u00e9\u00e9n keer per jaar, maar bij voorkeur elk kwartaal of na elke significante wijziging in de identiteitsinfrastructuur. Testen hoeft niet altijd een volledige herstelsimulatite te zijn: gerichte deeltests, zoals het herstellen van een enkele domeincontroller of het valideren van noodaccounts, geven al waardevolle inzichten. Zorg er bovendien voor dat identiteitsherstel onderdeel is van bredere crisisoefeningen, zodat ook de samenwerking tussen IT, security en management wordt getoetst. <\/p>\n <\/div>\n \n Een gewone back-up kan worden overschreven, versleuteld of verwijderd door ransomware als de aanvaller toegang heeft tot de back-upomgeving. Een immutable back-up is onveranderlijk: eenmaal weggeschreven, kan de data gedurende een vastgestelde periode niet worden gewijzigd of verwijderd, ook niet door beheerders met hoge rechten. Voor identiteitssystemen is dit onderscheid cruciaal, omdat aanvallers bij gerichte aanvallen bewust back-ups proberen te vernietigen om herstel te belemmeren. <\/p>\n <\/div>\n \n Dat hangt af van de aard en omvang van het incident. Als een identiteitsincident leidt tot ongeautoriseerde toegang tot persoonsgegevens, geldt in veel gevallen de meldplicht onder de AVG bij de Autoriteit Persoonsgegevens, binnen 72 uur na ontdekking. Onder NIS2 gelden aanvullende meldverplichtingen voor organisaties in kritieke sectoren, waarbij ook significante verstoringen van de dienstverlening gemeld moeten worden. Het is verstandig om meldprocedures vooraf te documenteren als onderdeel van het crisisplan, zodat je tijdens een incident niet ook nog hoeft uit te zoeken wat de wettelijke verplichtingen zijn. <\/p>\n <\/div>\n <\/div>\n Zonder werkend identiteitsbeheer loopt elk disaster recovery plan vast \u2014 ontdek hoe je dit voorkomt.<\/p>\n","protected":false},"author":8,"featured_media":8528,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"page-templates\/post-wpaiseo.php","format":"standard","meta":{"_acf_changed":false,"_seopress_titles_title":"","_seopress_titles_desc":"Identiteitsbeheer bepaalt of herstel uren of weken duurt. Ontdek hoe je identiteit verankert in jouw disaster recovery plan.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"disaster recovery","_seopress_news_disabled":"","_seopress_video_disabled":"","_seopress_video":[],"_seopress_pro_schemas_manual":[],"_seopress_pro_rich_snippets_disable_all":"","_seopress_pro_rich_snippets_disable":[],"_seopress_pro_schemas":[],"_improvement_type_select":"improve_an_existing","_thumb_yes_seoaic":false,"_frame_yes_seoaic":false,"seoaic_generate_description":"","seoaic_improve_instructions_prompt":"","seoaic_rollback_content_improvement":"","seoaic_idea_thumbnail_generator":"","thumbnail_generated":false,"thumbnail_generate_prompt":"","seoaic_article_description":"","seoaic_article_subtitles":[],"footnotes":""},"categories":[1],"tags":[],"class_list":["post-8352","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-geen-onderdeel-van-een-categorie"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.opensight.nl\/en\/wp-json\/wp\/v2\/posts\/8352","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.opensight.nl\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.opensight.nl\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.opensight.nl\/en\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/www.opensight.nl\/en\/wp-json\/wp\/v2\/comments?post=8352"}],"version-history":[{"count":1,"href":"https:\/\/www.opensight.nl\/en\/wp-json\/wp\/v2\/posts\/8352\/revisions"}],"predecessor-version":[{"id":8384,"href":"https:\/\/www.opensight.nl\/en\/wp-json\/wp\/v2\/posts\/8352\/revisions\/8384"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.opensight.nl\/en\/wp-json\/wp\/v2\/media\/8528"}],"wp:attachment":[{"href":"https:\/\/www.opensight.nl\/en\/wp-json\/wp\/v2\/media?parent=8352"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.opensight.nl\/en\/wp-json\/wp\/v2\/categories?post=8352"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.opensight.nl\/en\/wp-json\/wp\/v2\/tags?post=8352"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Hoe be\u00efnvloedt identiteitsbeheer de snelheid van herstel na een incident?<\/h2>\n\n
Wat zijn de grootste risico’s als identiteitsbeheer ontbreekt tijdens een cybercrisis?<\/h2>\n\n
\n
Wat is het verschil tussen identiteitsbeheer en toegangsbeheer bij disaster recovery?<\/h2>\n\n
Hoe richt je identiteitsbeheer in als onderdeel van een disaster recovery plan?<\/h2>\n\n
\n
Welke veelgemaakte fouten in identiteitsbeheer vertragen disaster recovery?<\/h2>\n\n
Hoe OpenSight helpt met identiteitsbeheer bij disaster recovery<\/h2>\n\n
\n
Frequently Asked Questions<\/h2>\n
\n Hoe lang duurt het gemiddeld om een identiteitsinfrastructuur te herstellen na een ransomware-aanval? <\/h3>\n
\n Wat zijn noodaccounts en hoe zet ik ze correct op? <\/h3>\n
\n Moet ik mijn identiteitsinfrastructuur anders beschermen als ik gebruikmaak van cloudoplossingen zoals Microsoft Entra ID? <\/h3>\n
\n Hoe weet ik welke accounts tijdens een incident mogelijk zijn gecompromitteerd? <\/h3>\n
\n Hoe vaak moet ik het herstelproces voor identiteitssystemen testen? <\/h3>\n
\n Wat is het verschil tussen een immutable back-up en een gewone back-up van identiteitssystemen? <\/h3>\n
\n Geldt de verplichting om identiteitsincidenten te melden onder de AVG of NIS2? <\/h3>\n
Related Articles<\/h2>