Beveiligingsverklaring

Deze verklaring beschrijft de technische en organisatorische maatregelen die de dienst RavSolutions en de daarin bewaarde gegevens beschermen. Zij is geschreven om te worden nagegaan: zij noemt maatregelen die daadwerkelijk zijn getroffen, en onderdeel 15 vermeldt, even duidelijk, wat wij niet hebben.

Zij is geen garantie en schept geen toezegging over serviceniveau; de contractuele voorwaarden staan in de algemene voorwaarden. Waar dezelfde maatregel ook in de AVG-verklaring of in de informatie over gegevensverwerking voorkomt, is inhoudelijk hetzelfde bedoeld.

Zij ziet op de dienst die wij exploiteren. De beveiliging van de accounts, apparaten en wachtwoorden binnen de eigen werkruimte van een abonnee is de verantwoordelijkheid van die abonnee; geen van de hier beschreven maatregelen beschermt een werkruimte waarvan de inloggegevens zijn gedeeld of hergebruikt.

De dienst bestaat uit drie front-ends — de website, de applicatie en het klantenportaal — één API, een PostgreSQL-database, een Redis-instantie en objectopslag. De front-ends bereiken de API uitsluitend via HTTPS.

Alles behalve de objectopslag draait achter een reverse proxy op infrastructuur van RackForest Zrt. in Hungary (EU). De database en Redis zijn uitsluitend op een intern netwerk aangesloten en publiceren geen poort, zodat geen van beide vanaf internet bereikbaar is; alleen de API kan met hen communiceren.

Geüploade bestanden worden niet op de applicatieservers bewaard, maar in Cloudflare R2-objectopslag die is geconfigureerd voor European Union. De bucket is privé: hij heeft geen openbare toegang en geen eigen domein ervoor, en elk bestand wordt geleverd via een link die de API ondertekent.

Geheimen — databasegegevens, ondertekeningssleutels, API-sleutels van aanbieders — worden bij het uitrollen via de omgeving aangeleverd en worden nooit in de broncoderepository vastgelegd.

Al het verkeer naar de website, de applicatie, het portaal en de API loopt over HTTPS. Certificaten worden automatisch uitgegeven en vernieuwd door Let's Encrypt, en gewone HTTP-verzoeken worden doorgestuurd naar HTTPS.

De reverse proxy stuurt HTTP Strict Transport Security mee met een max-age van één jaar, inclusief subdomeinen en met preload, zodat een browser die de site eenmaal heeft gezien niet terugvalt op een onversleutelde verbinding.

Antwoorden dragen X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, een referrerbeleid strict-origin-when-cross-origin en een permissiebeleid dat camera, microfoon en locatiebepaling weigert. Headers die de server en het framework identificeren, worden verwijderd. De API accepteert cross-origin verzoeken uitsluitend van de origins van de applicatie en het portaal.

De website, de applicatie en het portaal worden geleverd met een Content Security Policy. Scripts mogen uitsluitend van de dienst zelf worden geladen en, in de applicatie, van Google Identity Services om met Google in te loggen; de website en het portaal staan in het geheel geen script van derden toe. Insluiten in een frame, plug-ininhoud en het herschrijven van de documentbasis worden geweigerd, en de API antwoordt met een beleid dat niets toestaat.

Een wachtwoord moet ten minste acht tekens lang zijn en een hoofdletter, een kleine letter en een cijfer bevatten. Wachtwoorden worden uitsluitend bewaard als een met salt versterkte cryptografische hash, gemaakt door de wachtwoordhasher van ASP.NET Core Identity; zij worden nooit bewaard in een vorm die kan worden teruggelezen, en wij kunnen een vergeten wachtwoord niet herstellen, alleen opnieuw instellen.

Na tien mislukte aanmeldpogingen wordt een account vijftien minuten geblokkeerd. De teller staat op het account en niet op de aanroeper, zodat een poging die over veel adressen wordt verspreid toch wordt gestopt, ook al blijft elk adres onder de limiet per aanroeper.

Inloggen met een Google-account is beschikbaar. Het door Google uitgegeven identiteitstoken wordt bij Google geverifieerd voordat er een sessie wordt aangemaakt, en wij ontvangen het Google-wachtwoord nooit.

Bij registratie wordt een bevestigingsbericht naar het opgegeven adres gestuurd, en het adres wordt als bevestigd gemarkeerd zodra de link erin wordt gebruikt. Een vergeten wachtwoord wordt opnieuw ingesteld via een eenmalige link naar het geregistreerde adres; een geslaagde herinstelling heft ook een bestaande blokkering op, omdat een blokkering de gebruikelijke reden is om opnieuw in te stellen.

Toegangstokens zijn JSON Web Tokens die vijftien minuten geldig zijn. Bij elk verzoek worden uitgever, doelgroep, handtekening en vervaldatum gecontroleerd, zonder enige klokmarge.

Een vernieuwingstoken bestaat uit vierenzestig bytes uit een cryptografische willekeurgenerator. De database bevat uitsluitend de SHA-256-hash daarvan, zodat het token zelf niet uit een kopie van de database kan worden gelezen.

Bij elke vernieuwing roteert het token: het vorige wordt ingetrokken en er wordt een nieuw uitgegeven. Vernieuwingstokens verlopen na dertig dagen, en uitloggen trekt het token onmiddellijk in.

Een vernieuwing wordt geweigerd als de gebruiker is gedeactiveerd of de werkruimte inactief is gemaakt, zodat het intrekken van iemands toegang uiterlijk van kracht wordt wanneer diens huidige toegangstoken verloopt.

Elke gebruiker heeft een rol binnen de werkruimte en de endpoints controleren die. Pakketafhankelijke functies worden daarnaast bewaakt door eigen autorisatiebeleid, zodat een functie buiten het afgenomen pakket door de API wordt geweigerd en niet slechts in de interface wordt verborgen.

Werkruimten zijn op gegevensniveau gescheiden: elk gegeven draagt de identificatie van de werkruimte waartoe het behoort, en elke zoekopdracht blijft beperkt tot de werkruimte van de aanroeper. Een gegeven dat bij een andere werkruimte hoort, wordt niet uit het resultaat verborgen — het komt er nooit in terecht.

De werkruimte wordt afgeleid uit een claim in het ondertekende toegangstoken en op de server bepaald. Een door de client aangeleverde werkruimte-identificatie wordt nergens voor vertrouwd.

Realtimeverbindingen gebruiken dezelfde authenticatie als de rest van de API; een verbinding zonder geldig token wordt geweigerd, de omvang van binnenkomende berichten is begrensd, en gedetailleerde foutinformatie wordt uitsluitend in de ontwikkelomgeving teruggegeven.

Een klant ontvangt een link met een willekeurig gegenereerd token dat bij één opdracht hoort en een vervaldatum draagt. Het token opent die ene opdracht en niets anders in de werkruimte.

Voordat de opdracht wordt getoond, moet de bezoeker het e-mailadres of het telefoonnummer bevestigen dat voor die klant is vastgelegd. Een geslaagde bevestiging levert een bewijs op dat twaalf uur geldig is, ondertekend met HMAC met een sleutel die is afgeleid van — maar cryptografisch onafhankelijk is van — het ondertekeningsgeheim van de server, en dat in constante tijd wordt geverifieerd.

Bevestigingspogingen worden per aanroeper beperkt en bewust niet per token: beperken per token zou iedereen in staat stellen een klant uit zijn eigen opdracht te sluiten door simpelweg het budget ervan op te maken.

Uploads zijn beperkt tot een vaste lijst met bestandstypen — JPEG, PNG, WebP, PDF, DOCX, XLSX en platte tekst — en tot een maximale omvang die afhangt van het afgenomen pakket. Afbeeldingen worden op de server opnieuw gecodeerd voordat zij worden opgeslagen.

Bestanden worden geleverd via kortlevende ondertekende links die de API genereert. Omdat de bucket zelf privé is, geeft een verlopen of gewijzigde link in het geheel geen toegang.

Uploaden en downloaden kennen afzonderlijke limieten per aanroeper, zodat een uitgelekte link of een op hol geslagen client niet kan worden gebruikt om opslag of bandbreedte onbeperkt leeg te trekken.

Opgeslagen bestanden worden door de opslagaanbieder in rust versleuteld.

De API past limieten toe die per aanroeper zijn verdeeld — op werkruimte en gebruiker uit het token waar dat er is, en anders op clientadres. Aanmelden, aanmelden met Google, wachtwoordherstel en portaalbevestiging zijn beperkt tot tien pogingen per minuut; registratie tot vijf.

De limiteerders lezen het werkelijke adres van de aanroeper uit de doorgestuurde headers van de proxy, en alleen de proxy zelf wordt vertrouwd om die te zetten. Zonder die configuratie zou elk verzoek van de proxy lijken te komen en zou iedereen één budget delen, wat de bescherming in een storing zou veranderen.

De reverse proxy past vóór de applicatie een verdere algemene limiet toe, zodat het verkeer al wordt begrensd voordat het de API überhaupt bereikt.

Binnenkomende gegevens worden op de server gevalideerd voordat zij de domeinlogica bereiken, en fouten worden als gestructureerde berichten teruggegeven: er worden geen stacktraces, databaseberichten of interne paden naar de client gestuurd.

De database en Redis staan uitsluitend op het interne netwerk en accepteren alleen verbindingen van de API; geen van beide is aan internet blootgesteld.

De objectopslag versleutelt opgeslagen bestanden in rust, en de bucket is niet openbaar leesbaar.

Er worden regelmatig back-ups gemaakt en het terugzetten daarvan wordt getest. Gegevens die aan het einde van een abonnement worden gewist, verdwijnen uit de back-ups naarmate die back-ups in hun normale rotatie verlopen, en tot dat moment worden zij voor geen enkel ander doel gebruikt.

De applicatie schrijft serverlogs, en elke werkruimte heeft een activiteitengeschiedenis die vastlegt welke gebruiker wat wanneer heeft gewijzigd. De geschiedenis is voor de abonnee zichtbaar binnen de applicatie.

Server-, applicatie- en beveiligingslogs worden 90 dagen bewaard, behalve waar een bepaald gegeven langer wordt bewaard voor een lopend beveiligingsonderzoek.

Logs bestaan om de dienst te exploiteren en incidenten te onderzoeken. Wij loggen geen wachtwoorden, sessietokens of betaalkaartgegevens.

Toegang tot productiesystemen en productiegegevens is beperkt tot het personeel dat die nodig heeft voor beheer of ondersteuning, volgens het beginsel van minimale rechten en onder een geheimhoudingsverplichting die na afloop van hun betrekking blijft gelden.

Afhankelijkheden van derden zijn vastgezet en worden centraal beheerd, zodat een versie op één plek wordt gewijzigd; wij passen beveiligingsupdates voor het platform en zijn afhankelijkheden toe zodra die beschikbaar komen.

Wijzigingen in het databaseschema worden bij het starten van de dienst als geversioneerde migraties toegepast, zodat het schema in productie altijd overeenkomt met de code die erop draait.

De aanbieders die namens ons gegevens verwerken — hosting, objectopslag, e-mailbezorging, betaling en facturering — worden met hun rol en regio genoemd in onderdeel 5 van de AVG-verklaring en onderdeel 8 van de informatie over gegevensverwerking.

Een nieuwe aanbieder wordt ten minste 30 dagen aangekondigd voordat deze met verwerken begint, zodat een abonnee die bezwaar maakt tijd heeft om te handelen.

Wij houden een intern register bij van inbreuken in verband met persoonsgegevens en volgen een procedure die detectie, beoordeling, indamming en melding omvat.

Wanneer een inbreuk waarschijnlijk een risico inhoudt voor de rechten en vrijheden van natuurlijke personen, melden wij deze zonder onnodige vertraging en, indien mogelijk, binnen 72 uur nadat wij ervan kennis hebben genomen bij de bevoegde toezichthoudende autoriteit (art. 33 AVG); is het risico hoog, dan informeren wij ook de betrokken personen in duidelijke taal (art. 34 AVG).

Waar wij als verwerker optreden, stellen wij de abonnee die als verwerkingsverantwoordelijke optreedt zonder onnodige vertraging in kennis nadat wij van een inbreuk kennis hebben genomen, en staan wij hem bij met zijn eigen meldingsplichten.

Geen enkele onlinedienst kan absoluut veilig worden gemaakt. Deze pagina beschrijft maatregelen, geen garanties, en de algemene voorwaarden geven geen toezegging over beschikbaarheid of serviceniveau.

Wij beschikken niet over een certificering ISO/IEC 27001 en niet over een SOC 2-rapport, en de dienst is niet onderworpen aan een onafhankelijke penetratietest. Mocht daarin iets veranderen, dan is dit het onderdeel waarin dat zal worden vermeld.

Tweefactorauthenticatie voor gebruikersaccounts is nog niet beschikbaar. De beveiliging van een account berust daarom op de sterkte van het wachtwoord, de accountblokkering en de hierboven beschreven limieten, en daarom vragen wij om een wachtwoord dat nergens anders wordt gebruikt.

De dienst draait in één regio zonder failover naar een andere regio, en valt die regio uit, dan is de dienst onbeschikbaar tot zij terugkeert. Wij benoemen dit omdat een beveiligingsverklaring die alleen sterke punten opsomt, niet kan worden gebruikt om een beslissing op te baseren.

Vindt u een kwetsbaarheid, schrijf dan naar info@ravsolutions.eu met een beschrijving, de stappen die nodig zijn om haar te reproduceren en het getroffen adres. Wij bevestigen de ontvangst en laten u weten hoe wij haar willen afhandelen.

Geef ons een redelijke gelegenheid het probleem te verhelpen voordat u het openbaar maakt. Benader, wijzig of verwijder tijdens het testen geen gegevens die niet van u zijn, verslechter de dienst niet voor anderen, en gebruik geen social engineering tegen ons personeel of onze aanbieders.

Wij voeren geen betaald bugbountyprogramma. Wij ondernemen geen stappen tegen een melder die te goeder trouw en binnen de bovenstaande grenzen handelt.

Deze verklaring wordt actueel gehouden met de dienst. Het versienummer en de ingangsdatum boven aan de pagina tonen welke tekst van kracht is, en eerdere versies zijn op verzoek beschikbaar.

Verandert een hier beschreven maatregel, dan verandert deze pagina mee. Vragen over de inhoud kunt u sturen naar info@ravsolutions.eu.