Versterken beveiliging van Exact Online

forums · 10 oktober 2024 om 06:50

Samenvatting

Het afdwingen van tweestapsverificatie door Exact Online sinds 25 mei 2018 is een grote stap van een grote speler in de online ERP-markt voor het bereiken van sterke authenticatie om uw gegevens en die van uw relaties te beschermen, zowel voor vertrouwelijkheid als voor integriteit. Vooral interactief gebruik kan beter worden beveiligd in lijn met de vertrouwelijke aard van de beheerde gegevens met een inspanning van het eenmaal per week invoeren van een nieuwe 6-cijferige code.

Desalniettemin kunnen onwillige interactieve gebruikers gemakkelijk de beveiliging van Exact Online als geheel voor uw bedrijf in gevaar brengen. In dat geval is uw autorisatiematrix een tweede verdedigingslinie.

Beveiliging opgelegd aan externe applicaties van derden zal nauwelijks verbeteren, dus vermijd het gebruik van externe applicaties tenzij dit absoluut noodzakelijk wordt geacht.

Deze notitie geeft een aantal aanbevelingen om de beveiliging van externe applicaties voor gebruik met Exact Online te versterken.

Tweestapsverificatie en sterke authenticatie

Exact Online zal, in combinatie met het van kracht worden van GDPR, vanaf 25 mei alle gebruikers verplichten om tweestapsverificatie te gebruiken voor interactieve sessies. Tweestapsverificatie kan worden gebruikt om sterke authenticatie te bereiken. Ook kan tweestapsverificatie, mits correct geïmplementeerd, multi-factor authenticatie bewerkstelligen. Exact is de eerste essentiële speler in de online ERP-business die dit afdwingt, wat een grote stap voorwaarts is. Sterke authenticatie is al tientallen jaren de maatstaf voor informatiebeveiliging in Nederland voor niet-omkeerbare financiële transacties en persoonlijke gegevens. Sterke authenticatie vereist implementatie van ten minste twee van de volgende zaken:

Kennis, zoals wachtwoord of pincode.
Locatie, zoals een vast IP-adres of fysiek adres.
Bezit, zoals een apparaat of token.

Tweestapsverificatie garandeert echter geen sterke authenticatie en ook geen multifactorauthenticatie. U moet goed opletten en uw gebruikers zorgvuldig instrueren om sterke authenticatie te bereiken:

Sterke authenticatie vereist een sterke gebruikersmentaliteit

Anders gezegd: wanneer sommige van uw gebruikers onwillig zijn, kunnen ze gemakkelijk de beveiliging van Exact Online als geheel voor uw bedrijf in gevaar brengen. In dat geval is uw autorisatiematrix de tweede verdedigingslinie: wat kan een gecompromitteerde gebruiker doen in termen van schade aan uw gegevens, zowel in termen van Vertrouwelijkheid als Integriteit. Die verdedigingslinie kan worden uitgebreid met de hoeveelheid schade die u bereid bent toe te brengen op onwillige gebruikers (grapje).

De autorisatiematrix van Exact Online wordt toegepast op elk verzoek om gegevens voor zowel interactief als API gebruik. Exact Online heeft op dit moment geen dekkende ondersteuning voor “scopes”, waardoor meer fijnmazige toegangscontrole per applicatie mogelijk is.

Deze notitie geeft een aantal aanbevelingen om de beveiliging van Exact Online te versterken, met name in de authenticatie van applicaties van derden. Het is echter niet bedoeld of gepland als een overzicht van alle mogelijke aanvalsvectoren die kunnen worden afgesloten door het versterken van uw beveiliging. De notitie richt zich grotendeels op technologie en laat de menselijke risico’s zoals social engineering grotendeels buiten beschouwing. Raadpleeg uw lokale beveiligingsfunctionaris voor risicobeoordeling, aanbevelingen en uitzonderingen.

Merk op dat tweestapsverificatie momenteel alleen van toepassing is op interactieve sessies. Typisch niet-interactief gebruik is het gebruik van gecertificeerde en niet-gecertificeerde applicaties. Applicaties hebben verschillende manieren om gegevens uit te wisselen met Exact Online. Het gebruikte OAuth-protocol voor authenticatie definieert hiervoor verschillende scenario’s (“flows”), waarvan sommige beschikbaar zijn op het Exact Online API-platform. In deze notitie wordt uitsluitend naar de populaire Code Grant Flow en Implicit Grant Flow gekeken.

Tweestapsverificatie grotendeels uitgeschakeld (update oktober 2024)

Merk op dat met de introductie van Azure B2C als onderdeel van One Exact Identity tweestapsverificatie feitelijk al vele maanden irrelevant is gemaakt, omdat een enkele aanmelding in een land het mogelijk maakt om aan te melden vanaf andere IP-adressen en apparaten in dat land zonder het bezit van de tokengenerator aan te tonen door de dan geldende verificatiecode in te voeren.

OAuth Code Grant Flow

Algemene aanbevelingen

De Code Grant Flow gebruikt een client ID en client secret als een soort gebruikersnaam en wachtwoord voor een applicatie om zich als applicatie te authenticeren. De Code Grant Flow is bedoeld voor gebruik in omgevingen die vertrouwd worden door de eigenaar van de applicatie, zoals op de eigen webserver. Het is niet bedoeld voor gebruik in omgevingen die niet onder controle staan van de eigenaar van de applicatie, zoals apparaten van gebruikers (laptop, telefoon, pc) of servers, omdat het client secret gemakkelijk kan worden gecompromitteerd.

Bij het eerste gebruik genereert de Code Grant Flow een zogenaamd “refresh token”, een soort gebruikersspecifiek wachtwoord dat samen met de applicatie toegang geeft tot de gegevens.

Tijdens het genereren authenticeert de gebruiker zichzelf, gevolgd door authenticatie van de applicatie. Tussen deze twee stappen wordt een tijdelijk geldige authentication code beschikbaar gesteld, tijdens welke de applicatie zichzelf moet authenticeren om een refresh token te verkrijgen.

Het genereren van het refresh token vereist enkel tweestapsverificatie tijdens het generatieproces. Het resulterende refresh token heeft een lange levensduur, meestal voor de eeuwigheid, zonder de noodzaak voor tweestapsverificatie tijdens die levensduur. Na het generatieproces kan het refresh token worden opgeslagen (bij voorkeur op een sterk geauthenticeerde en beveiligde manier) als niet-sterke authentication code en worden gebruikt om kortlevende zogenaamde “access tokens” te genereren totdat de gebruiker de toegang tot de applicatie intrekt vanuit het Exact Online Beveiligingscentrum (klik op gebruikersnaam rechtsboven, Mijn Exact Online, Beveiligingscentrum).

In het Exact Online Beveiligingscentrum kunt u ook het sturen van een e-mailbericht activeren wanneer u aanmeldt vanaf een eerder niet geregistreerd IP-adres (standaard staat dit uit) en kunt u Google Analytics registraties uitschakelen (standaard is het registreren van uw Exact Online activiteiten bij Google Analytics ingeschakeld):

Aanbeveling 1: schakel in het Exact Online Beveiligingscentrum het sturen in van e-mail bij een nieuw IP-adres.

Aanbeveling 2: schakel de registratie van Google Analytics uit in het Exact Online Beveiligingscentrum.

Volgens Je’kob is “de veiligste seks helemaal geen seks” en op dezelfde manier is het veiligste gebruik van applicaties helemaal geen applicaties:

Aanbeveling 3: weeg de mogelijke voor- en nadelen van het gebruik van een applicatie af. Vermijd het gebruik van applicaties van derden die niet zijn opgenomen in de [Exact Online App Store] (https://apps.exactonline.com) en applicaties die worden geleverd door leveranciers die zich niet in uw rechtsgebied bevinden.

Aanbeveling 4: gebruik als applicatie-ontwikkelaar nooit de Code Grant Flow om applicaties uit te voeren op het apparaat van een eindgebruiker, zoals een iPhone of server app.

Aanbeveling 5: maak een client ID aan per wettelijke eigenaar die de omgeving beheert als u de Code Grant Flow moet gebruiken om applicaties in een niet-vertrouwde omgeving te draaien. Dit voorkomt aanvalsvectoren door een partij die zich voordoet als een app, gericht op een andere partij die eerder die app heeft geauthenticeerd.

Merk op dat de client ID als publieke informatie wordt beschouwd. Beveiligingscontroles die alleen gebaseerd zijn op openbare informatie zoals client ID zijn inherent onveilig. Aangezien het gebruik van de Code Grant Flow geen sterke authenticatie garandeert na het aanmaken, wordt het sterk aanbevolen om aanvullende maatregelen toe te passen:

Aanbeveling 6: maak een apart Exact Online gebruikersaccount aan per aangesloten app, zodat het mogelijk is om uit de auditinformatie te halen welke applicatie een wijziging heeft veroorzaakt of gegevens heeft opgehaald. Hoewel dit uitsluitend een reactieve maatregel is, maakt het een betere analyse van een feitelijk of verondersteld beveiligingsincident mogelijk. Dit geldt voor alle authenticatiescenario’s. Zie voor meer details Voorkom een Exact Online datalek: hoe pareer je de gevaren van data scope en Wat is "data scoping" op Exact Online?.

Aanbeveling 7: controleer regelmatig welke applicaties toegang hebben gekregen door uw gebruikersgemeenschap en pas preventieve maatregelen toe, zoals gebruikers verplichten om vooraf een intern formulier te laten ondertekenen. Het is momenteel niet mogelijk om de gebruikte applicaties centraal te beperken zoals op Office 365, maar deze maatregel vermindert het risico dat applicaties die niet zijn goedgekeurd door het management voor langere tijd toegankelijk zijn. Overweeg als alternatief het gebruik van een firewall op applicatieniveau.

Bovendien, zodra een applicatie (zoals geïdentificeerd door client ID) is geautoriseerd door een eindgebruiker om toegang te krijgen tot hun gegevens, voorkomt aanbeveling 7 grotendeels scenario’s waarin een eindgebruiker die al is aangemeld op Exact Online volledig transparant toegang geeft tot Exact Online via een app. De volgende aanbeveling vermindert dit risico ook:

Aanbeveling 8: Dit risico, dat enigszins lijkt op de “Facebook pixel”, kan ook worden vermeden door ervoor te zorgen dat gebruikers Exact Online en dan ook Exact Online alleen op dedicated omgevingen draaien, zoals een aparte terminal server.

Invantive en Code Grant Flow

De Code Grant Flow was alleen beschikbaar op de Online SQL Editor en Invantive Producer webapplicaties van Invantive, omdat deze draaien op door Invantive gecontroleerde servers. De meeste Invantive producten draaien op omgevingen die niet door Invantive worden beheerd. Door gebruik te maken van client ID’s per wettelijke eigenaar, hebben we aanbeveling 5 geïmplementeerd. We eisen ook dat gebruikers erkennen dat ze zich bewust zijn van het feit dat de Code Grant Flow met refresh token niet-sterke authenticatie voor applicaties toestaat (zie https://cloud.invantive.com).

Om de Code Grant Flow te gebruiken kunt u een database kiezen met ten minste één Exact Online datacontainer zoals hieronder weergegeven. In plaats van gebruiker/wachtwoord kunt u de client ID, client secret, refresh token en redirect URI invullen. Dit geldt voor alle Windows-, opdrachtregel- en webproducten:

invantive-code-grant-flow-exact-online

OAuth Implicit Grant Flow

De Implicit Grant Flow is ontworpen voor gebruik in interactieve omgevingen die niet worden vertrouwd door de leverancier van de applicatie. Implicit Grant kan bijvoorbeeld worden gebruikt om applicaties toegang te verlenen tot uw Exact Online gegevens via uw browser met behulp van JavaScript. Een tijdelijk geldig zogenaamd “toegangstoken” wordt gebruikt om toegang te krijgen tot de beschermde bronnen van code die wordt uitgevoerd op het apparaat van de gebruiker.

In zo’n scenario zijn er minstens vier partijen betrokken:

de gebruiker die de browser bedient;
de leverancier die de omgeving levert (Google bijvoorbeeld voor Google Chrome of het SQL tool “Invantive Query Tool”);
de bronnen waarvoor authenticatie nodig is (Exact Online);
de applicatie en de webserver die deze bronnen teruggeeft.

De Implicit Grant Flow lijkt op de Code Grant Flow, maar de toepassing wordt niet geauthenticeerd. In plaats daarvan navigeert de browser via de redirect URI, wat op zichzelf ook een aantal veiligheidsrisico’s met zich meebrengt.

Desalniettemin kan de client ID die de applicatie identificeert ter informatie aan de bronnen worden getoond. Merk nogmaals op dat de client ID als publieke informatie wordt beschouwd en dat het nooit gebruikt mag worden om toegang te controleren; het is eenvoudig om de client ID van bijna elke applicatie te achterhalen.

De eindgebruiker die de omgeving (de browser en de applicatie) controleert, zal moeten vaststellen of hij de leverancier van de browser en de applicatie vertrouwt om toegang te krijgen tot zijn gegevens. Het toegangstoken dat wordt geretourneerd door de Implicit Grant Flow heeft echter een beperkte levensduur om het risico van ongecontroleerd gebruik van het token in de toekomst te verkleinen. Deze levensduur op Exact Online is tien minuten.

Voor reactieve doeleinden kunt u de volgende aanbevelingen toepassen:

Aanbeveling 9: maak een apart Exact Online gebruikersaccount aan per aangesloten app, zodat het mogelijk is om uit de auditinformatie te halen welke applicatie een wijziging heeft veroorzaakt of gegevens heeft opgehaald. Hoewel dit uitsluitend een reactieve maatregel is, maakt het een betere analyse van een feitelijk of verondersteld beveiligingsincident mogelijk. Dit geldt voor alle authenticatiescenario’s. Zie voor meer details Voorkom een Exact Online datalek: hoe pareer je de gevaren van data scope en Wat is "data scoping" op Exact Online?.

Aanbeveling 10: controleer regelmatig welke applicaties toegang hebben gekregen door uw gebruikers en pas preventieve maatregelen toe, zoals gebruikers verplichten om vooraf een formulier te laten ondertekenen. Het is momenteel niet mogelijk om de gebruikte applicaties centraal te beperken zoals op Office 365, maar deze maatregel vermindert het risico dat applicaties die niet zijn goedgekeurd door het management voor langere tijd toegankelijk zijn. Overweeg als preventief alternatief het gebruik van een firewall op applicatieniveau.

Maar omdat de (mogelijk niet-vertrouwde) code wordt uitgevoerd op de apparaten die onder controle staan van de organisatie van de eindgebruiker, kunt u ook aanvullende preventieve maatregelen nemen:

Aanbeveling 11: zorg ervoor dat gebruikers alleen browsers uitvoeren die als betrouwbaar worden beschouwd.

Aanbeveling 12: dwing gebruikers alleen clientprogramma’s (zoals Invantive Control voor Excel) uit te voeren die als betrouwbaar worden beschouwd.

Aanbeveling 13: dwing gebruikers alleen toegang te kunnen krijgen tot vertrouwde websites die code bevatten die gebruik maakt van Implicit Grant Flow.

Aanbeveling 14: zoals eerder beschreven kan het risico van de “Facebook pixel” ook worden vermeden door ervoor te zorgen dat gebruikers Exact Online en dan Exact Online alleen op dedicated omgevingen draaien, zoals een aparte terminal server.

Invantive en Implicit Grant Flow

Alle interactieve Invantive producten ondersteunen en gebruiken al jaren de impliciete grant flow.

Interactieve applicaties zoals Invantive Query Tool maken het mogelijk om de gebruikersnaam en het wachtwoord in te voeren bij het aanmelden in een applicatiespecifiek browservenster. Een nieuw access token wordt voor nog eens tien minuten verkregen wanneer het access token verloopt en resource toegang nodig is.

Serverapplicaties zoals de opdrachtregel tool Invantive Data Hub wisselen HTTP-berichten direct uit met Exact Online, waarbij de gebruikersnaam en het wachtwoord worden uitgewisseld die aan de applicatie worden gepresenteerd in apparaat-gebonden encryptie formaat als opdrachtregel argumenten of versleuteld opgeslagen in de centrale database directory settings.xml of [Invantive Keychain] (What is Invantive Keychain?).

Met de introductie van tweestapsverificatie op Exact Online moet de gebruiker ook een code van zes cijfers presenteren die elke 30 seconden verandert, gebaseerd op een tekst (het zogenaamde “geheim”) en de huidige UTC-tijd. Raadpleeg voor meer details RFC 6238.

Voor interactieve toepassingen kan de gebruiker de zescijferige code interactief invoeren in het Invantive browservenster. Als alternatief kan de gebruiker de geheime tekenreeks opslaan of onthouden in een vertrouwde omgeving. Omdat de geheime tekenreeks over het algemeen niet verandert, kan de gebruiker het geheim ook in een extra veld met de naam “Tweestapsgeheim” weergeven. De zescijferige code om in te loggen wordt berekend uit de inhoud van dit veld:

exact-online-2fa-secret-field

Het gebruik van het Tweestapsgeheim neemt de voordelen van tweestapsverificatie voor het bereiken van sterke authenticatie volledig weg. We raden het gebruik van Tweestapsgeheim af om in te loggen, tenzij dit noodzakelijk is vanwege redenen die opwegen tegen de nadelen en tenzij het wordt gecompenseerd door aanvullende beveiligingsmaatregelen. Het brengt echter geen extra veiligheidsrisico’s met zich mee, omdat het volgende nog steeds geldt en is geïllustreerd in bovenstaande voorbeelden: