Wie kan er bij jouw klantgegevens?
Een CRM is het adresboek van je omzet. Hieronder staat in gewone taal hoe het is afgeschermd, wat wij wel en niet kunnen zien, en wat we niet beweren.
Scheiding in de database
Je organisatie is afgeschermd in Postgres zelf, niet alleen in de applicatie. Een fout in een scherm kan daardoor geen gegevens van een ander bedrijf tonen.
Een logboek dat alleen aangroeit
Wat er gebeurt, wordt vastgelegd. Een regel wijzigen of wissen kan niet — ook niet door ons, ook niet door de hoogste beheerder.
Supporttoegang met een klok erop
Wij kunnen niet onopgemerkt in je omgeving kijken. Dat gaat alleen via een sessie met een reden, een einddatum en een logregel.
Tweede factor voor ons personeel
Iedereen bij Nermio die bij het beheergedeelte kan, moet er per sessie door een authenticator-code heen. Een gestolen wachtwoord is niet genoeg.
Rem op inlogpogingen
Te veel pogingen in korte tijd worden geweigerd. Dat gebeurt centraal, dus het werkt ook als er meerdere servers naast elkaar draaien.
Binnen de Europese Unie
De database staat bij Supabase, op Postgres, binnen de EU. Je gegevens blijven van jou: vraag een kopie op en je krijgt hem.
De scheiding zit in de database, niet in het scherm
Dat verschil is het belangrijkste punt van deze pagina.
In veel software wordt bepaald wie wat mag zien op de plek waar het scherm wordt opgebouwd. Dat werkt zolang elk scherm het goed doet. Vergeet één pagina de controle, dan staat er data van een ander bedrijf op, en dat merk je pas als iemand het meldt.
Bij Nermio ligt die grens een laag lager: in de database. Elke tabel met klantgegevens heeft regels die bepalen welke rijen een ingelogd account mag zien, en de database past die regels toe bij élke vraag — ongeacht welk scherm of welke route hem stelt. Een bug in de applicatie kan daardoor wel een fout opleveren, maar geen gegevens van een andere organisatie. Bezoekers zonder account hebben helemaal geen leesrecht op die tabellen.
Binnen je eigen organisatie bepaal jij het verder zelf. Er zijn vier rollen — eigenaar, manager, gebruiker en alleen lezen — en wie op “alleen lezen” staat, kan ook via een omweg niets wijzigen: dat is dezelfde laag die het afdwingt.
Een logboek dat niemand kan bijwerken
Nermio houdt twee logboeken bij. Het ene legt vast wat er in je omgeving wordt gedaan en door wie. Het andere legt vast wat er met accounts gebeurt: inlogpogingen, het instellen van een tweede factor, een wachtwoordwijziging. Die twee staan apart, zodat je bij een incident het ene kunt lezen zonder het uit het andere te hoeven vissen.
Belangrijker is wat er níet mee kan: een regel die erin staat, kan niet worden gewijzigd en niet worden gewist. Dat is geen afspraak maar een eigenschap van de tabel — de database weigert het, ook als de vraag van onze hoogste beheerdersrol komt. Een logboek dat de beheerder kan opschonen is geen logboek.
Wij kijken niet stil mee
Soms moet iemand van ons in je omgeving kijken om een probleem op te lossen. Dat kan, maar niet ongemerkt en niet onbeperkt. Een medewerker start daarvoor een supportsessie en moet daarbij een reden opgeven. Die sessie heeft een einde — vijftien, dertig of zestig minuten, nooit een open einde — en sluit automatisch als de tijd om is. Eén medewerker kan niet twee sessies tegelijk open hebben, dus “ik stond er nog ergens ingelogd” bestaat niet.
Bij de start wordt gekozen of de sessie alleen mag lezen of ook mag wijzigen; meekijken is de standaard. Verwijderen kan tijdens een supportsessie nooit — daar is geen enkele route voor, ook niet met de juiste rol. Het is bovendien geen inloggen-als-jou: je ziet in het logboek niet jouw naam staan, maar die van de medewerker, met de sessie erbij.
En je kunt het nalezen. De eigenaar van een organisatie heeft leesrecht op zijn eigen supportgeschiedenis: welke sessies er waren, met welke reden, wanneer, en wat er tijdens die sessie in zijn omgeving is gebeurd. Dat is geen extraatje — het is wat supporttoegang uitlegbaar maakt.
Inloggen
Je wachtwoord bewaren we niet. Het gaat versleuteld naar Supabase Auth en is daarna niet meer uit te lezen — ook niet door ons, ook niet tijdens een supportsessie. Een vergeten wachtwoord kan dus alleen opnieuw worden ingesteld, niet opgezocht. Iemand die zich voordoet als jou en belt om zijn wachtwoord te laten voorlezen, krijgt het niet, omdat het niet kan.
Op inloggen en wachtwoord-vergeten zit een limiet: te veel pogingen binnen een paar minuten worden geweigerd. Die teller staat in de database en niet in het geheugen van één server, want bij meerdere servers naast elkaar zou een aanvaller in de praktijk nauwelijks een limiet merken.
Voor ons eigen personeel geldt een stap extra. Wie bij het beheergedeelte van Nermio kan, moet een authenticator hebben ingesteld én er in díe sessie een code uit hebben ingevoerd. Niet “dit account heeft ooit 2FA aangezet”, maar “deze sessie is er doorheen” — anders zou een gestolen wachtwoord alsnog genoeg zijn.
Waar je gegevens staan
Op een Postgres-database bij Supabase, binnen de Europese Unie. Het verkeer tussen je browser en Nermio gaat over een versleutelde verbinding. Je gegevens blijven van jou: vraag een volledige kopie op via info@nermio.nl en je krijgt hem — niet alleen als je weggaat.
Wat we niet beweren
Nermio is een jong product, en op een veiligheidspagina is dat relevant. We hebben geen ISO 27001- of SOC 2-verklaring, en geen rapport van een externe penetratietest. Software die zulke logo’s laat zien zonder ze te hebben, is het soort bewering dat je pas controleert als er iets misgaat.
Wat hier staat, is daarom geen keurmerk maar een beschrijving van wat er in de code en de database staat. Vind je een zwakke plek, dan horen we dat graag via info@nermio.nl — melden is nuttiger dan zwijgen, en we nemen een melding serieus.
Bekijk het zelf met je eigen gegevens
Je maakt een eigen omgeving aan, zet er een paar bedrijven in en kijkt of de afspraken hierboven kloppen. Een kopie van je gegevens krijg je op verzoek.