Beveiligingsmodel
Hosted Kanera is ontworpen met gelaagde controles op het gebied van applicatiebeveiliging, infrastructuur, monitoring, toegangsbeheer en operationele beoordeling.
Zelf-gehoste Kanera geeft uw team controle over de runtime-omgeving. Die controle betekent ook dat uw organisatie verantwoordelijk is voor het versterken van de implementatie, patching, back-ups, netwerkblootstelling en monitoring.
Huidige applicatiecontroles
De onderstaande controles beschrijven de huidige Kanera-implementatie, beoordeeld op 20 augustus 2026. Ze vertegenwoordigen niet dat Kanera over een onafhankelijke beveiligingscertificering of auditoordeel beschikt. We werken deze sectie bij wanneer de bedieningselementen of de architectuur wezenlijk veranderen.
- Wachtwoorden worden gehasht met Argon2id met behulp van een expliciete geheugen-harde configuratie. Inlogverificatie maakt ook gebruik van een pad met gelijke timing om signalen van accountopsomming te verminderen.
- Vernieuwingstokens zijn willekeurig, worden alleen opgeslagen als SHA-256-hashes, worden gerouleerd bij gebruik en worden als familie ingetrokken wanneer hergebruik wordt gedetecteerd. De productievernieuwingscookie is HttpOnly, Secure, SameSite=Lax en beperkt tot authenticatieroutes.
- Op tijd gebaseerde MFA met een eenmalig wachtwoord omvat gecodeerde geheimen, herstelcodes voor eenmalig gebruik die zijn opgeslagen als hashes, bescherming tegen opnieuw afspelen en uitsluiting van pogingen. Organisatiebeheerders kunnen MFA vereisen voor leden en bestuursgasten die toegang hebben tot hun gegevens.
- Authenticatie, het opnieuw instellen van wachtwoorden, MFA, openbare API, MCP en andere gevoelige routes maken gebruik van snelheidslimieten of proberen controles uit te voeren. Cloudflare Turnstile kan gehoste aanmeldings- en wachtwoordresetstromen beschermen.
- Organisatie-, werkruimte-, bord-, gast-, API-sleutel- en OAuth-machtigingen worden aan de serverzijde afgedwongen. Workspace API-sleutels hebben een lees-, schrijf- of beheerdersbereik; persoonlijke sleutels volgen de huidige machtigingen van de eigenaar; OAuth gebruikt exacte omleidings-URI's en PKCE.
- API-sleutels, OAuth-tokens, verificatiecodes, uitnodigingstokens en klantgeheimen worden opgeslagen als hashes. MFA en geconfigureerde integratiegeheimen worden in rust versleuteld.
- HTTP-reacties maken gebruik van besturingselementen, waaronder HSTS, bescherming tegen snuiven van inhoudstypen, framebeperkingen, een verwijzingsbeleid, inhoudbeveiligingsbeleid en machtigingenbeleid.
- Ondersteuningstoegang voor meerdere tenants is beperkt tot geautoriseerde platformbeheerders, in de tijd beperkt, herroepbaar, zichtbaar aangegeven in het product en vastgelegd met de operator, doelorganisatie, reden, IP-adres, user-agent, start-, verval- en eindtijd. Administratieve mutaties worden naar een aparte audit trail geschreven.
Verantwoordelijkheden voor zelfhosting
- Voer Kanera uit achter HTTPS met vertrouwde certificaten.
- Houd Kanera, afhankelijkheden, besturingssystemen, containers, databases en reverse proxy's bijgewerkt.
- Beperk beheerderstoegang, bescherm geheimen en wissel inloggegevens wanneer dat nodig is.
- Schakel de optionele, zelf-gehoste back-uptools van Kanera in en configureer deze, of zorg voor een gelijkwaardig back-upproces, en test vervolgens regelmatig het herstel.
- Controleer de netwerkblootstelling, firewallregels, opslagrechten en integratiereferenties.
Uw beveiligingsverantwoordelijkheden
- Gebruik een uniek wachtwoord en schakel multi-factor authenticatie in waar beschikbaar of vereist door uw organisatie.
- Houd uw browsers, apparaten, Kanera-implementatie en verbonden tools up-to-date en bescherm apparaten en back-ups tegen ongeautoriseerde toegang.
- Geef gebruikers, API-sleutels, OAuth- of MCP-clients, webhooks en andere integraties alleen de rechten die ze nodig hebben, en controleer die toegang regelmatig.
- Verwijder ongebruikte gebruikers en integraties, trek inloggegevens en sessies in waarvan u denkt dat deze gecompromitteerd zijn, en meld onmiddellijk vermoedelijke ongeautoriseerde accounttoegang.
- Controleer de beveiligings- en privacypraktijken van externe leveranciers voordat u vertrouwelijke, persoonlijke of gereguleerde informatie verzendt via een integratie.
Gegevensbescherming
Werkruimte-eigenaren bepalen welke gebruikers worden uitgenodigd, welke toegang ze krijgen en welke inhoud in Kanera wordt geplaatst.
Kanera mag niet worden gebruikt om sterk gereguleerde gegevens op te slaan, tenzij uw organisatie de implementatie, configuratie, contractvoorwaarden en wettelijke vereisten voor dat gebruik heeft beoordeeld.
Voor gehoste Kanera worden onze verplichtingen op het gebied van contractuele beveiliging, incidentmelding, subverwerker, assistentie, audit en verwijdering uiteengezet in het Addendum Gegevensverwerking. We brengen getroffen klanten zonder onnodige vertraging op de hoogte van een bevestigde inbreuk op persoonlijke gegevens en verstrekken informatie die redelijkerwijs beschikbaar is om hun reactie te ondersteunen.
Het melden van kwetsbaarheden
E-mail vermoedelijke kwetsbaarheden naar [email protected]; gebruik geen publieke kwestie. Vermeld de getroffen component, versie, URL, eindpunt of implementatiemodus; reproductiestappen of een minimale proof of concept; waarschijnlijke impact; relevante verzoeken, logs of screenshots waaruit de geheimen zijn verwijderd; en de contactgegevens van uw voorkeur en of u openbare vermelding wilt. Wij streven ernaar om een melding binnen 3 werkdagen te bevestigen en binnen 10 werkdagen een eerste beoordeling of verzoek om meer informatie te geven. Dit zijn doelstellingen, geen garanties.
In de reikwijdte vallen authenticatie en autorisatie, huurderisolatie, toegang tot privéborden, opgeslagen geheimen en tokenlekken, uploads en bestandsverwerking, API's, OAuth, MCP, webhooks, realtime functies, factureringsgrenzen en de standaard zelf-gehoste implementatie. Social engineering, spam, bevindingen die alleen afhankelijk zijn van opzettelijk zwakke ontwikkelingsinstellingen en denial-of-service-testen tegen productie zonder schriftelijke toestemming vallen buiten het bereik.
We publiceren momenteel geen PGP-sleutel en gewone e-mail is geen end-to-end gecodeerd rapportagekanaal. Stuur geen live inloggegevens of persoonlijke gegevens. Vraag in de eerste e-mail of u een veiligere uitwisseling van gevoelig bewijsmateriaal wilt regelen.
Veilige haven en openbaarmaking
Als u te goeder trouw handelt, alleen accounts, gegevens en systemen test waarvan u de eigenaar bent of waarvoor u expliciete toestemming heeft om te testen, binnen de bovenstaande reikwijdte blijft, schendingen van de privacy en verstoring van de dienstverlening vermijdt, alleen toegang krijgt tot de gegevens die minimaal nodig zijn om het probleem aan te tonen, stopt en rapporteert als u gegevens van iemand anders tegenkomt, die gegevens niet bewaart of openbaar maakt en voldoet aan de toepasselijke wetgeving, zullen wij het onderzoek behandelen als geautoriseerd in het kader van ons beleid en zullen wij voor het onderzoek zelf geen juridische stappen tegen u ondernemen. Dit is geen toestemming om systemen of infrastructuur van derden buiten onze controle te testen, social engineering of fysieke aanvallen te gebruiken, of betaling te eisen.
Geef ons een redelijke kans om dit te onderzoeken en te verhelpen voordat het openbaar wordt gemaakt. We zullen met u samenwerken aan een tijdlijn voor openbaarmaking op basis van de ernst, de getroffen gebruikers, de beschikbaarheid van oplossingen en de implementatiebehoeften, en we streven ernaar u op de hoogte te houden van belangrijke mijlpalen. Als u van mening bent dat dringende openbaarmaking noodzakelijk is, leg dan het risico uit aan [email protected], zodat we kunnen coördineren.
Verwijder testgegevens en vertrouwelijk bewijsmateriaal wanneer deze niet langer nodig zijn. Als u onbedoeld toegang krijgt tot persoonlijke gegevens, inloggegevens of klantinhoud, stop dan met testen, kopieer of deel deze niet en vertel ons waartoe toegang is verkregen, zodat we op passende wijze kunnen reageren.
Versiegeschiedenis
Versie 2 is van kracht vanaf 20 augustus 2026. Het onderscheidt implementatiebeoordeling van onafhankelijke certificering en koppelt de contractuele incident- en beveiligingsverplichtingen in de DPA. Versie 1 ging in op 16 juli 2026.