Data & Beveiliging¶

Hoe GitLab Sync je data behandelt en beschermt. Het behandelt wat Exact's App Center Data & Security review vraagt: het doel van de app, de data die het gebruikt, en hoe die data wordt gebruikt en beschermd.

Doel¶

GitLab Sync boekt de tijd gelogd in GitLab als uren in Exact Online, één concept-regel per persoon, issue en dag, zet GitLab-issues (en milestones) om in Exact WBS-activiteiten (en deliverables), en schrijft de uurstatus terug naar GitLab als exact::… labels.

Data die we benaderen¶

Van	Data	Gebruik
GitLab (gitlab.com of jouw self-hosted instance)	tijdslages, issues, milestones, labels en projectmetadata	om de concept-urenlijnen en WBS-regels aan te maken, en statuslabels terug te schrijven
Exact Online	projecten, WBS-deliverables/-activiteiten, urenlijnen (`project/TimeTransactions`) en medewerkers	het synchronisatiedoel, één concept-urenlijn per persoon/issue/dag

GitLab Sync leest nooit je broncode, branches of diffs, alleen de tijdslages, issues, milestones, labels en projectmetadata hierboven vermeld.

Hoe data stroomt¶

Een beheerder koppelt een GitLab-project aan een Exact-project (de koppeling vereist een organisatie-beheerder met two-factor authenticatie).
Op schema, op een webhook of op "Sync nu", leest GitLab Sync tijdslages, issues en labels van GitLab, en de huidige project/WBS/uurstatus van Exact.
Het schrijft naar Exact alleen concept-urenlijnen en WBS-regels (urenlijnen worden nooit anders dan als concept weggeschreven, en alleen zolang ze nog concept of geweigerd zijn), en schrijft de exact::submitted/approved/rejected labels terug naar GitLab.
Elke write wordt geregistreerd met een hash zodat een run idempotent is, hij schrijft dezelfde regel nooit tweemaal.

Wat we bewaren, en waarom¶

Data	Waar	Bescherming
Het GitLab-toegangstoken van elke verbinding	de database van de app	AES-256-GCM versleuteld, één sleutel per organisatie, gebonden aan haar eigen record (AAD). Alleen de laatste vier tekens worden ooit getoond; het token zelf wordt nooit teruggegeven of gelogd
Gekoppelde projecten en sync-state (cursors, laatste run, de hashes van de weggeschreven regels)	de database van de app, per organisatie	om de sync idempotent en herstartbaar te houden
GitLab-gebruikersnamen en e-mailadressen van personen die tijd gelogd hebben, en hun match aan een Exact-medewerker	de database van de app, per organisatie	zodat een tijdslage op de juiste medewerker belandt
Het webhook-secret van elk gekoppeld project	als een SHA-256-hash (het secret zelf wordt niet bewaard)	om te verifiëren dat een webhook van jouw GitLab kwam
Account-, organisatie- en factureringsrecords	in het portaal	zie het data & beveiliging document van het portaal

Wat we niet bewaren¶

Exact-data wordt doorgegeven, niet bewaard. De sync leest een tijdslage, schrijft de urenlijn, en gooit de rest weg. We bewaren geen kopie van je Exact-projecten, medewerkers, facturen of enige andere Exact-data, alleen de identificatiecodes en hashes die een correcte volgende run nodig heeft.
Geen GitLab-broncode, branches of diffs.
Geen Exact refresh tokens. De token-broker van het portaal geeft GitLab Sync een kortlevend access token (10 minuten, alleen in geheugen) per call; het refresh token verlaat nooit het portaal.
Geen cache. GitLab Sync cachet geen Exact- of GitLab-data in welke vorm dan ook.
Geen telemetry of tracking. Geen analytics, geen licentiecontrole, geen reclame.

Hoe de data beschermd is¶

Onderweg¶

TLS overal: browser ↔ GitLab Sync, GitLab Sync ↔ GitLab, GitLab Sync ↔ Exact Online, GitLab Sync ↔ portaal.
Tussen het portaal en de app wisselt de edge de sessie uit voor een kortlevend, EdDSA-gedeclareerd assertion (60 s, gebonden aan deze app); de app en het portaal verifiëren elkaar op een intern netwerk met een per-app service-token.

In rust¶

GitLab-toegangstokens zijn AES-256-GCM versleuteld met een versioned keyring en een AAD gebonden aan de verbinding, zodat een token gekopieerd van één rij niet ontsleutelt in een andere.
Webhook-secrets worden enkel als een SHA-256-hash bewaard en gecontroleerd in constante tijd.

Outbound safety (SSRF)¶

Klant GitLab-URLs worden alleen benaderd via een safe fetch die vastzit aan de host die de tenant configureerde voor dat instance, dus het token kan niets anders bereiken.
Het DNS-antwoord bij connectie wordt gecontroleerd (rebinding-safe), private/loopback/link-local ranges worden geweigerd, redirects worden geweigerd, en alleen de vaste /api/v4 en /api/graphql paden worden gebruikt.
Exact-toegang is beperkt tot de ingeschakelde administraties van de organisatie (via de broker), en de writes zijn beperkt tot de project/WBS/tijd-resources door de resourceschemas.

Toegangsbeheer¶

Wijzigingen (tokens, koppelingen, mappings) vereisen een organisatie-beheerder met two-factor authenticatie; "Sync nu" is beschikbaar voor leden.
Webhooks zijn slechts triggers: het secret wordt geverifieerd, de payload wordt genegeerd, en de sync leest GitLab opnieuw, een spoofed webhook kan geen data injecteren.
Het auditlogboek in het portaal registreert wie wat veranderde.

Hosting en operaties¶

Gehost in de EU. Containers draaien als een non-root gebruiker op een read-only root filesystem met alle capabilities gedropt.
Afhankelijkheden en container images worden dagelijks gescand op kwetsbaarheden (Trivy, HOOG/KRITIEK faalt).
Foutmeldingen (GlitchTip) zijn opt-in en schoongeveegd: geen headers, cookies, lichamen, query strings of gebruikersinformatie worden verzameld.

Bewaring en verwijdering¶

Het verwijderen van de organisatie in het portaal verwijdert onmiddellijk alles wat GitLab Sync daarvoor bewaart: verbindingen (en hun versleutelde tokens), koppelingen, mappings en sync-state.
Een token vervangen via GitLab-verbindingen roteert het zonder de gekoppelde projecten aan te raken.
Het auditlogboek zit in het portaal en wordt bewaard zolang de organisatie bestaat.

Wie ontvangt de data¶

Naar	Wat	Waarom
jouw GitLab-instance	de calls van het token (tijdslages, issues, labels) en de `exact::…` labels teruggeschreven	het doel van de dienst
Exact Online (`start.exactonline.*`)	concept-urenlijnen, WBS-regels, en de project/WBS/uur-leesacties, voor de ingeschakelde administraties	het doel van de dienst
Mollie	de betaling voor het abonnement, in het portaal	facturering