Sikkerhetspolitikk

Sikkerhetsmodell

Hosted Kanera er designet med lagdelte kontroller på tvers av programsikkerhet, infrastruktur, overvåking, tilgangsadministrasjon og operasjonell gjennomgang.

Selvbetjent Kanera gir teamet ditt kontroll over kjøretidsmiljøet. Denne kontrollen betyr også at organisasjonen din er ansvarlig for distribusjonsherding, patching, sikkerhetskopiering, nettverkseksponering og overvåking.

Gjeldende programkontroller

Kontrollene nedenfor beskriver den nåværende Kanera-implementeringen som ble gjennomgått 20. august 2026. De er ikke en representasjon av at Kanera har en uavhengig sikkerhetssertifisering eller revisjonsuttalelse. Vi oppdaterer denne delen når kontroller eller arkitektur endres vesentlig.

• Passord hashed med Argon2id ved hjelp av en eksplisitt minne-hard konfigurasjon. Innloggingsverifisering bruker også en tidsutjevnet bane for å redusere konto-telling signaler.
• Oppdateringstokens er tilfeldige, lagret bare som SHA-256 hashes, rotert ved bruk og tilbakekalt som en familie når gjenbruk oppdages. Produksjonsoppdateringsinformasjonskapselen er HttpOnly, Secure, SameSite = Lax og begrenset til godkjenningsruter.
• Tidsbasert engangspassord MFA inkluderer krypterte hemmeligheter, engangsgjenopprettingskoder lagret som hash, avspillingsbeskyttelse og forsøk på lockout. Organisasjonsadministratorer kan kreve MFA for medlemmer og styregjester som får tilgang til dataene sine.
• Autentisering, tilbakestilling av passord, MFA, offentlig API, MCP og andre sensitive ruter bruker hastighetsgrenser eller forsøk på kontroller. Cloudflare Turnstile kan beskytte vertsbaserte registrering og passordtilbakestillingsflyter.
• Organisasjons-, arbeidsområde-, tavle-, gjeste-, API-nøkkel- og OAuth-tillatelser håndheves på serversiden. Arbeidsområde-API-nøkler har lese-, skrive- eller admin-omfang; personlige nøkler følger eierens gjeldende tillatelser; OAuth bruker nøyaktige omdirigerings-URIer og PKCE.
• API-nøkler, OAuth-tokens, verifiseringskoder, invitasjonstokens og klienthemmeligheter lagres som hash. MFA og konfigurerte integrasjonshemmeligheter krypteres i ro.
• HTTP-svar bruker kontroller, inkludert HSTS, beskyttelse mot sniffing av innholdstype, rammebegrensninger, en henvisningspolicy, sikkerhetspolicy for innhold og tillatelsespolicy.
• Støttetilgang på tvers av leietakere er begrenset til autoriserte plattformadministratorer, tidsbegrenset, gjenkallelig, synlig angitt i produktet og registrert med operatøren, målorganisasjonen, grunnen, IP-adressen, brukeragenten, start-, utløps- og slutttidspunktet. Administrative mutasjoner skrives til et eget revisjonsspor.

Selvbetjeningsansvar

• Kjør Kanera bak HTTPS med klarerte sertifikater.
• Hold Kanera, avhengigheter, operativsystemer, beholdere, databaser og omvendt proxyer oppdatert.
• Begrens administrativ tilgang, beskytt hemmeligheter og roter legitimasjon når det er nødvendig.
• Aktiver og konfigurer det valgfrie sikkerhetskopieringsverktøyet for selvdriftet Kanera, eller etabler en tilsvarende sikkerhetskopieringsprosess. Test deretter gjenoppretting regelmessig.
• Se gjennom nettverkseksponering, brannmurregler, lagringstillatelser og integrasjonslegitimasjon.

Ditt sikkerhetsansvar

• Bruk et unikt passord og aktiver multifaktorautentisering der det er tilgjengelig eller kreves av organisasjonen.
• Hold nettlesere, enheter, Kanera-distribusjon og tilkoblede verktøy oppdatert, og beskytt enheter og sikkerhetskopier mot uautorisert tilgang.
• Gi brukere, API-nøkler, OAuth- eller MCP-klienter, webhooks og andre integrasjoner bare de tillatelsene de trenger, og gjennomgå tilgangen regelmessig.
• Fjern ubrukte brukere og integrasjoner, tilbakekall legitimasjon og økter du tror kan bli kompromittert, og rapporter mistenkt uautorisert kontotilgang umiddelbart.
• Se gjennom sikkerhets- og personvernpraksisen til tredjepartsleverandører før du sender konfidensiell, personlig eller regulert informasjon gjennom en integrasjon.

Databeskyttelse

Arbeidsområdeeiere kontrollerer hvilke brukere som inviteres, hvilken tilgang de mottar og hvilket innhold som plasseres i Kanera.

Kanera bør ikke brukes til å lagre sterkt regulerte data med mindre organisasjonen har gjennomgått distribusjon, konfigurasjon, kontraktsvilkår og juridiske krav for den bruken.

For vertsbaserte Kanera er våre kontraktsmessige sikkerhets-, hendelses-, underbehandler-, assistanse-, revisjons- og slettingsforpliktelser angitt i databehandlings tillegget. Vi varsler berørte kunder om et bekreftet brudd på personopplysninger uten unødig forsinkelse og gir informasjon rimelig tilgjengelig for å støtte deres svar.

• Databehandlings tillegg
• Underprosessorer

Rapportering av sårbarheter

E-post mistenkte sårbarheter til [email protected]; ikke bruk et offentlig problem. Inkluder den berørte komponenten, versjonen, URL-adressen, endepunktet eller distribusjonsmodusen; reproduksjonstrinn eller et minimalt bevis på konsept; sannsynlig innvirkning; relevante forespørsler, logger eller skjermbilder med hemmeligheter fjernet; og dine foretrukne kontaktdetaljer og om du vil ha offentlig kreditt. Vi tar sikte på å anerkjenne en rapport innen 3 virkedager og gi en innledende vurdering eller forespørsel om mer informasjon innen 10 virkedager. Dette er mål, ikke garantier.

I omfang er autentisering og autorisasjon, leietaker isolasjon, private-board tilgang, lagrede hemmeligheter og token lekkasje, opplastinger og filhåndtering, APIer, OAuth, MCP, webhooks, sanntidsfunksjoner, fakturering grenser, og standard selv vert distribusjon. Social engineering, spam, funn som avhenger bare på forsettlig svake utviklingsinnstillinger, og nektelse av service testing mot produksjon uten skriftlig tillatelse er ute av omfang.

Vi publiserer for øyeblikket ikke en PGP-nøkkel og vanlig e-post er ikke en ende-til-ende kryptert rapporteringskanal. Ikke send live legitimasjon eller personlige data. Spør i den første e-posten hvis du trenger oss for å arrangere en sikrere utveksling for sensitive bevis.

• Send e-post til sikkerhetsteamet
• Maskinlesbar sikkerhetskontakt

Trygg havn og avsløring

Hvis du handler i god tro, bare tester kontoer, data og systemer du eier eller har eksplisitt tillatelse til å teste, holde deg innenfor omfanget ovenfor, unngå brudd på personvernet og tjenesteforstyrrelser, få tilgang til bare de minste dataene som trengs for å demonstrere problemet, stoppe eller rapportere hvis du støter på en annen persons data, ikke beholder eller avslører dataene, og overholder gjeldende lov, vil vi behandle forskningen som godkjent for formålet med vår policy og vil ikke forfølge rettshandling mot deg for forskningen.

Gi oss en rimelig mulighet til å undersøke og rette opp før offentliggjøring. Vi vil jobbe med deg på en tidslinje for offentliggjøring basert på alvorlighetsgrad, berørte brukere, fikse tilgjengelighet og distribusjonsbehov, og vi tar sikte på å holde deg informert om meningsfulle milepæler. Hvis du mener at hasteavsløring er nødvendig, forklar risikoen for å [email protected] Da kan vi koordinere.

Slett testdata og konfidensielle bevis når det ikke lenger er nødvendig. Hvis du utilsiktet får tilgang til personopplysninger, legitimasjon eller kundeinnhold, må du slutte å teste, ikke kopiere eller dele det, og fortelle oss hva som ble tilgang til slik at vi kan svare på riktig måte.

Versjonshistorikk

Versjon 2 er effektiv 20. august 2026. Den skiller implementeringsgjennomgang fra uavhengig sertifisering og knytter kontraktshendelsen og sikkerhetsforpliktelsene i DPA. Versjon 1 var effektiv 16. juli 2026.