Technische en organisatorische maatregelen

1. Reikwijdte en opzet

• Bedrijf: CreatorFlow Labs S.L., Madrid, Spanje. Een klein team dat volledig op afstand werkt. Wij beheren geen eigen servers, serverruimtes of kantoornetwerk, en er worden geen persoonsgegevens opgeslagen in bedrijfsruimtes.
• Hosting: De volledige dienst draait op Amazon Web Services (AWS) in de Europese Unie, regio eu-west-1 (Ierland). De applicatie, databases, caches, objectopslag en back-ups staan allemaal in die regio.
• Verwerkte gegevens: Instagram-gebruikersnamen en openbare profiel-ID's, de tekst van reacties en DM's die automatiseringen starten of eruit voortkomen, e-mailadressen die via automatiseringen zijn verzameld, linkklikken, en account- en factuurgegevens van klanten. Het is niet de bedoeling dat er bijzondere categorieën van persoonsgegevens in de zin van art. 9 AVG worden verwerkt.
• Gedeelde verantwoordelijkheid: AWS zorgt voor de fysieke beveiliging en de beveiliging van de omgeving van de datacenters. CreatorFlow beheert alles vanaf het besturingssysteem en hoger. Elk artikel hieronder vermeldt bij welke partij een maatregel ligt.

2. Fysieke toegangscontrole (Zutrittskontrolle)

• Bedrijfsruimtes: Niet van toepassing. In de bedrijfsruimtes van CreatorFlow staan geen servers, netwerkapparatuur of gegevensdragers met persoonsgegevens. Afsluitbare serverruimtes, serverkasten, sleutelbeheer, bezoekersregistratie, alarmsystemen en regels voor schoonmaak- of onderhoudspersoneel zijn daarom niet op ons van toepassing.
• Datacenters (AWS): Overgenomen van AWS. De datacenters van AWS hebben perimeterbeveiliging, toegangscontrole met badges en biometrie, begeleiding van bezoekers, camerabewaking (CCTV) en logging van toegang. Deze maatregelen worden geaudit volgens ISO 27001 en SOC 2. De rapporten zijn op verzoek beschikbaar voor klanten, via ons of rechtstreeks via AWS Artifact.
• Noodstroom en brandbeveiliging: Overgenomen van AWS. De datacenters hebben redundante stroomtoevoer, ononderbroken stroomvoorzieningen en generatoren, en automatische branddetectie en brandblussing. Dit valt onder dezelfde auditrapporten.

3. Toegangscontrole tot systemen (Zugangskontrolle)

• Authenticatie van klanten: Klanten loggen in met een e-mailadres en wachtwoord, of met Google. Het registratieformulier vereist wachtwoorden van minstens 8 tekens. Dit minimum wordt op dit moment alleen in de browser afgedwongen, niet op de server. Wachtwoorden worden opgeslagen als hashes met een salt, nooit in platte tekst. De overstap naar een modern hash-algoritme voor wachtwoorden (bcrypt of argon2) staat geregistreerd als openstaand punt. Nieuwe accounts worden aangemaakt na een reCAPTCHA-controle. Bevestiging van het e-mailadres vóór het eerste gebruik wordt op dit moment niet afgedwongen.
• Sessies: Sessies worden op de server opgeslagen en zijn gekoppeld aan een ondertekende cookie met de HttpOnly-vlag. Deze cookie geldt alleen voor ons domein en verloopt na 7 dagen. De Secure-vlag is nog niet ingesteld op deze cookie. Het toevoegen ervan staat op onze beveiligingsroadmap. Een wachtwoordwijziging beëindigt de huidige sessie en trekt remember-me-tokens in, maar beëindigt op dit moment geen andere actieve sessies op andere apparaten. Als een beheerder het e-mailadres van een account wijzigt, worden alle sessies van die gebruiker ongeldig.
• Accountblokkering: Er is nog geen automatische blokkering van accounts na herhaalde mislukte inlogpogingen. Extra bescherming tegen misbruik van het inloggen staat op onze beveiligingsroadmap. Links om het wachtwoord opnieuw in te stellen worden alleen verstuurd naar het e-mailadres dat bij het account is geregistreerd.
• Toegang tot Instagram: Wij vragen nooit om Instagram-wachtwoorden en slaan ze nooit op. Instagram-accounts worden gekoppeld via de officiële OAuth 2.0-flow van Meta. De toegangstokens die dat oplevert, worden op applicatieniveau versleuteld (AES-256) voordat ze worden opgeslagen.
• Toegang van medewerkers tot de infrastructuur: Toegang tot de AWS-console, servers en beheerfuncties is beperkt tot medewerkers die bij naam zijn aangewezen en persoonlijke inloggegevens hebben. Servertoegang verloopt via SSH met persoonlijke sleutels. Beheerfuncties in de applicatie zijn beperkt tot één expliciet toegestaan beheerdersaccount, en het aantal verzoeken naar deze functies is begrensd.

4. Toegangscontrole tot gegevens (Zugriffskontrolle)

• Afbakening per tenant: Elk gegevensrecord van een klant (automatiseringen, contacten, activiteit, analyses) wordt opgeslagen met de ID van de workspace waartoe het hoort. De applicatie toont een gebruiker alleen de workspaces waarvan die gebruiker lid is. Op een deel van de API controleert de server al of iemand lid is van de workspace. Deze controles worden uitgebreid naar elk endpoint dat aan een workspace is gebonden. Totdat dat klaar is, beschrijven wij de scheiding tussen tenants niet als volledig afgedwongen op de API-laag.
• Need-to-know: Alleen medewerkers die bij naam zijn aangewezen en de dienst beheren, hebben toegang tot productiegegevens, en alleen voor support, afhandeling van incidenten en onderhoud.
• Bescherming van toegangsgegevens: Toegangstokens van Instagram worden versleuteld opgeslagen en standaard uitgesloten bij het uitlezen van de database. Gewone query's of exports geven ze daardoor niet terug.
• Betalingsgegevens: Kaartgegevens worden volledig door Stripe verwerkt. CreatorFlow ontvangt of bewaart nooit volledige kaartnummers.

5. Doorgiftecontrole (Weitergabekontrolle)

• Versleuteling tijdens verzending: Verbindingen tussen gebruikers en de dienst, en tussen de dienst en Meta, Stripe en onze aanbieders van e-mail en logging, worden versleuteld met TLS.
• Subverwerkers: Persoonsgegevens worden alleen gedeeld met de subverwerkers die in artikel 5 van de verwerkersovereenkomst staan, onder gegevensverwerkingsvoorwaarden. De gegevens worden gehost en gelogd in de Europese Unie. Doorgiften aan subverwerkers buiten de EU zijn gebaseerd op Standaardcontractbepalingen of het EU-VS Data Privacy Framework, zoals beschreven in de verwerkersovereenkomst.
• Exports: Klanten kunnen hun verzamelde contacten exporteren als CSV-bestand. Na de export vallen die gegevens onder de controle en verantwoordelijkheid van de klant.
• Verwisselbare media: Niet van toepassing. Voor persoonsgegevens worden geen verwisselbare gegevensdragers (USB-sticks, externe schijven, back-uptapes) gebruikt. Er is daarom geen inventaris van gegevensdragers nodig.

6. Logging en invoercontrole (Eingabekontrolle)

• Applicatielogs: De applicatie schrijft gestructureerde logs voor elke verwerkte webhook, elke uitvoering van een automatisering, elk verzonden bericht en elk API-verzoek. Elke logregel bevat een correlatie-ID, zodat één gebeurtenis van begin tot eind te volgen is.
• Toegangslogs: De HTTP-laag legt per verzoek één regel vast in het toegangslog.
• Centrale opslag en bewaring: Alle logs worden verzonden naar een loggingplatform dat in de EU wordt gehost (New Relic, EU-dataregio) en worden 30 dagen bewaard. Gebruikers van de applicatie kunnen logs niet bewerken.
• Auditlog voor beheer: Handelingen die medewerkers van CreatorFlow via de beheeromgeving op klantaccounts uitvoeren, waaronder het verwijderen van accounts en het wijzigen van het e-mailadres van accounts, worden vastgelegd in een auditlog. Daarbij worden de uitvoerende beheerder, het tijdstip en het resultaat vastgelegd.
• Mislukte inlogpogingen: Mislukte inlogpogingen van klanten worden op dit moment niet vastgelegd in een apart beveiligingslog. Dit staat op onze beveiligingsroadmap.

7. Scheidingscontrole (Trennungskontrolle)

• Scheiding tussen klanten: Klantgegevens zijn op de gegevenslaag logisch gescheiden op basis van de ID van de workspace (multi-tenancy). Klanten kunnen via de applicatie geen gegevens zien die bij andere workspaces horen.
• Functionele scheiding: Account- en authenticatiegegevens staan in een aparte database, gescheiden van de applicatiegegevens (automatiseringen, contacten, analyses).
• Omgevingen: Geautomatiseerde tests draaien op een geïsoleerde in-memory database en gebruiken nooit productiegegevens. Voor de dagelijkse ontwikkeling worden lokale databases gebruikt. Medewerkers die bij naam zijn aangewezen, raadplegen productiegegevens ook rechtstreeks voor support, debuggen en onderzoek naar incidenten. Er is één productieomgeving en geen aparte stagingomgeving. Wijzigingen worden vóór de release lokaal en met de geautomatiseerde testsuite gecontroleerd, en kunnen worden teruggedraaid.
• Fysieke scheiding: Niet van toepassing buiten de grens van het AWS-account. Alle workloads draaien in een apart AWS-account dat eigendom is van CreatorFlow.

8. Beschikbaarheid en veerkracht (Verfügbarkeitskontrolle)

• Infrastructuur: De dienst draait in één AWS-regio (eu-west-1), in een Auto Scaling-groep die een uitgevallen compute-host automatisch vervangt. De gegevens staan op persistente opslagvolumes die blijven bestaan als de host wordt vervangen.
• Snapshots: Vóór wijzigingen aan de infrastructuur worden snapshots van de volumes gemaakt en binnen dezelfde AWS-regio bewaard. Snapshots die persoonsgegevens kunnen bevatten, worden bij rotatie verwijderd.
• Veerkracht van webhooks: Na een tijdelijke storing levert Meta Instagram-webhooks nog een periode opnieuw af. Stripe probeert webhooks voor facturering meerdere dagen opnieuw te versturen. Daardoor gaan bij korte onderbrekingen geen gebeurtenissen verloren.
• Monitoring: De gezondheid van de applicatie, de doorvoer en de foutpercentages worden bewaakt via ons loggingplatform. Elke uitrol wordt gevolgd en vergeleken met een basismeting van vóór de uitrol.
• Beperkingen: Er is geen failover over meerdere regio's, en er is geen formeel toegezegde doelstelling voor de hersteltijd of het herstelpunt. De dienst is niet bedoeld voor toepassingen waarbij gegarandeerde, ononderbroken beschikbaarheid nodig is.
• Veerkracht van datacenters: Overgenomen van AWS (redundante stroom, koeling en netwerk, brandblussing), zie artikel 2.

9. Patch- en wijzigingsbeheer

• Wijzigingsproces: Niet-triviale wijzigingen beginnen met een schriftelijke specificatie en een implementatieplan. De code wordt gedekt door een geautomatiseerde testsuite die draait op geïsoleerde testdatabases. Elke release wordt vóór de uitrol gebouwd en doorloopt een typecontrole.
• Releases: De applicatie wordt uitgerold als containerimages met een versienummer. Een eerdere image kan opnieuw worden uitgerold om een release terug te draaien. Functionaliteit met een hoger risico wordt uitgebracht achter feature flags. Die kunnen worden uitgeschakeld zonder opnieuw uit te rollen, en kunnen eerst voor een deel van de workspaces worden ingeschakeld.
• Verificatie: Belangrijke meetwaarden worden vóór een uitrol vastgelegd en daarna vergeleken, om regressies vroeg op te sporen.
• Afhankelijkheden en besturingssysteem: Afhankelijkheden van derden en basisimages van containers worden bijgewerkt via het normale releaseproces. Het besturingssysteem van de host wordt vernieuwd wanneer de compute-host wordt vervangen. Er is geen vaste patchkalender. Updates die relevant zijn voor de beveiliging, krijgen voorrang op basis van hun ernst.
• Beveiligingsregister: Bevindingen uit onze eigen beveiligingsaudits worden bijgehouden in een intern register, met een score voor de ernst. Ze worden verholpen in volgorde van risico.

10. Afhandeling van incidenten en datalekken

• Contact: Zorgen over beveiliging kunnen worden gemeld via security@creatorflow.so. Wij bevestigen de ontvangst van meldingen en onderzoeken ze. Wij hebben geen betaald bugbountyprogramma.
• Afhandeling: Incidenten worden onderzocht met behulp van de centrale logs, ingedamd, vastgelegd met een tijdlijn en de grondoorzaak, en verholpen. De geleerde lessen worden verwerkt in het beveiligingsregister.
• Melding aan klanten: Als een inbreuk op persoonsgegevens de gegevens van een klant treft, informeren wij die klant zonder onredelijke vertraging nadat wij er kennis van hebben genomen. Wij geven daarbij de informatie die in artikel 8 van de verwerkersovereenkomst staat, zodat de klant aan zijn eigen verplichtingen onder art. 33 en 34 AVG kan voldoen.

11. Organisatorische maatregelen

• Vertrouwelijkheid: Medewerkers met toegang tot persoonsgegevens zijn gebonden aan contractuele of wettelijke vertrouwelijkheidsverplichtingen.
• Levenscyclus van toegang: Toegang tot de infrastructuur en de beheerfuncties wordt per persoon verleend en ingetrokken wanneer iemand vertrekt of een andere functie krijgt.
• Apparaten en werken op afstand: Het team werkt op afstand. Productiegegevens worden alleen geraadpleegd met persoonlijke inloggegevens via versleutelde verbindingen (TLS, SSH). Als vaste werkwijze worden productiegegevens niet op lokale apparaten opgeslagen. Er is geen kantoornetwerk, dus er wordt geen VPN gebruikt. Elke beheerverbinding wordt afzonderlijk geauthenticeerd en versleuteld.
• Clean desk en papieren documenten: Niet van toepassing in de klassieke zin. Persoonsgegevens die via de dienst worden verwerkt, bestaan alleen in elektronische vorm binnen AWS. Er worden geen papieren documenten met klantgegevens bewaard.
• Derden en onderhoud: Externe onderhouds-, schoonmaak- of supportmedewerkers hebben geen toegang tot productiesystemen. Er vindt geen onderhoud op afstand door derden plaats. Alleen medewerkers van CreatorFlow beheren de infrastructuur.
• Endpointbeveiliging op servers: Productieworkloads draaien als Linux-containers onder gebruikers zonder rootrechten, op een host waarop publiek alleen HTTPS bereikbaar is. Werkplekken van medewerkers maken geen deel uit van het productienetwerk.

12. Verwijdering en bewaartermijnen

• Verwijdering van accounts: Op verzoek wordt een account verwijderd, samen met al zijn workspaces, automatiseringen, contacten, activiteitsgegevens, openstaande automatiseringsstatussen en Instagram-koppelingen. Het bijbehorende contact voor marketing-e-mails wordt ook verwijderd. Elke verwijdering wordt vastgelegd in een auditlog.
• Verwijdering van contacten: De klant kan afzonderlijke contacten (verzamelde e-mailadressen) verwijderen. Dit ondersteunt verzoeken van betrokkenen om gegevenswissing.
• Automatisch verlopen: Tijdelijke gegevens die worden gebruikt terwijl een automatisering wacht op een actie van een gebruiker (bijvoorbeeld een antwoord met een e-mailadres of het volgen van het account), zijn afhankelijk van het type automatisering binnen 24 tot 48 uur niet meer bruikbaar. Ze worden binnen 48 uur fysiek uit de database verwijderd.
• Logs: Applicatie- en toegangslogs worden 30 dagen bewaard.
• Snapshots: Zie artikel 8. Snapshots worden alleen teruggezet om de dienst te herstellen na een systeemstoring. Persoonsgegevens die vóór zo'n herstel al waren verwijderd, zouden daarna opnieuw moeten worden verwijderd. Hiervoor is geen geautomatiseerde afstemming. Daarom voeren wij verwijderingen op verzoek handmatig opnieuw uit.

13. Evaluatie van deze maatregelen