Skydd som är inbyggt i hur Ginsi fungerar.
Identitet, företagsmedlemskap, Case-åtkomst och integritet har var sina kontroller. Tillsammans styr de vem som får tillgång till företagets information och vad en analys får visa.
Inloggningen är bara första kontrollen.
Ginsi verifierar identiteten på servern. Godkänt företagsmedlemskap och roll kontrolleras separat innan åtkomst till företaget beviljas.
Så fungerar kontrollen
Supabase Auth hanterar signerade sessioner och verifiering av inloggningsuppgifter. Ginsi verifierar bearer-token på servern innan den autentiserade identiteten används i åtkomstkontrollerna.
Godkänt företagsmedlemskap och databasägda roller fastställer organisationsåtkomst. Behörigheter på dokumentationsnivå och produktåtkomst kontrolleras separat. Företagsadministration och Ginsis plattformsdrift använder skilda roller.
Företagets data har tydliga gränser.
Databaspolicyer och kontroller på servern styr åtkomsten till företagets dokumentation. Varje Case följer sin målgrupp och sina Workroom-behörigheter. Åtkomst till originalkällan prövas separat.
Så fungerar kontrollen
Radnivåsäkerhet (RLS) avgränsar databasåtkomst till relevant företag och dokumentation. Tjänster som läser Cases validerar en fast synlighetsprojektion och kontrollerar behörigheten igen efter privilegierade läsningar. Databaspolicyer och tjänstebehörighet utgör separata kontroller.
Analysen har integritetsgränser.
Case-underlag använder källspecifika grupptrösklar och undertryckning för att minska risken att individer identifieras. Fritext behöver hanteras separat och kan fortfarande innehålla indirekta identifierare.
Så fungerar kontrollen
Case-projektioner tillämpar aktuell synlighet och maskeringsstatus. Underlagspaket använder källspecifika grupptrösklar och undertryckning av kompletterande grupper före analys, så att integritetsbeslut ingår i databehandlingsvägen.
Ändrade behörigheter spelar roll.
Läsfunktionerna för Cases kontrollerar åtkomsten igen efter att innehållet hämtats. Ändrat medlemskap, synlighet eller integritetsstatus kan stoppa ett svar innan det lämnas ut.
Så fungerar kontrollen
Ett tidigare åtkomstbeslut räcker inte för ett senare svar. Granskade Case- och analyskövägar validerar aktuell behörighet och relevant integritetsstatus igen vid sin effekt- eller svarsgräns. Återkallande, maskering och ändrat medlemskap måste bedömas i den domän som äger dokumentationen.
Skyddet följer med genom analysen.
Ginsi förbereder tillåtet underlag, knyter kölagd analys till en verifierad arbetsuppgift och kontrollerar integritetsstatus innan Case-baserade resultat lämnas ut. Varje steg har en uttrycklig kontroll.
Förbered underlaget
Vägen för genererade Cases förbereder tillåtet underlag och tillämpar källspecifika regler för gruppintegritet före analys.
Teknisk fördjupning
Vägen för genererade Cases bygger ett avgränsat underlagspaket före modellinferens: tillåtna aggregat, källtäckning, dataluckor och relevant företagskontext. Källspecifika undertryckningsregler avgör vilka statistiska uppdelningar som får ingå.
Källomfattning · gruppintegritet · minimering
Avgränsa modellanropet
Utvalda indata skickas över HTTPS. Kölagd analys måste motsvara en aktuell, verifierad arbetsuppgift innan modellanropet fortsätter.
Teknisk fördjupning
Modellintegrationen skickar utvalda indata över HTTPS. Kölagd analys validerar ett giltigt körningsanspråk (claim) i databasen som binder företaget, arbetsuppgiften, körningsförsöket och integritetsrevisionen innan modellanropet fortsätter.
Verifierad arbetsomfattning · uttrycklig modellindata
Kontrollera igen före utlämning
Läsfunktionerna för Cases kontrollerar aktuell synlighet och maskeringsstatus igen innan innehåll lämnas ut.
Teknisk fördjupning
Case-operationer använder kontroller av integritetsrevisionen vid känsliga läsningar, skrivningar och utlämning av svar. Läsfunktionerna för Cases fastställer aktuell synlighet och maskeringsstatus, så att svaret följer åtkomstbeslutet vid utlämning.
Aktuell behörighet · aktuell integritetsstatus
Vissa analysvägar använder också indata på källnivå och sanerad fritext. Text kan fortfarande innehålla indirekta identifierare.
Så hanteras fritext
Fritext hanteras separat. Vissa aktiverade analysvägar kan skicka indata på källnivå och sanerad text till modellleverantören, inklusive enkätsvar där den analysvägen är tillämplig. Mönsterbaserad sanering tar bort vissa direkta identifierare. Text kan fortfarande innehålla indirekta identifierare; urval av indata och integritetshantering förblir specifika för analysvägen.
Tillåtelse att analysera
är inte tillåtelse att identifiera.
Statistiskt underlag använder källspecifik gruppundertryckning och minimering för att minska exponeringen. Fritext och importerade attribut kan fortfarande identifiera människor indirekt och behöver hanteras särskilt. Där enkätsvar finns i underlaget är de fortsatt pseudonyma, inte garanterat anonyma.
Skyddet måste hålla när förutsättningarna ändras.
När åtkomst återkallas
Läsfunktionerna för Cases validerar behörigheten igen efter privilegierade läsningar. Case-baserad analys kontrollerar också integritetsrevisionen innan ett resultat sparas eller lämnas ut. Ändrad behörighet eller integritetsstatus kan stoppa svaret.
När ett modellanrop behöver granskas
Integrationen för kölagd analys reserverar ett logiskt modellanrop innan det skickas. Dess idempotenskontroller blockerar dubbla sändningar för samma reserverade anrop. Ett oklart transportresultat hålls kvar för granskning, så att ett återförsök inte tyst skapar ännu en betald förfrågan.
När en grupp är för liten
Relevanta underlagsuppdelningar räknar separata deltagare och tillämpar undertryckning av kompletterande grupper. Att bara hålla tillbaka den lilla gruppen räcker inte om ett annat resultat skulle avslöja den genom subtraktion.
När något går fel
Identitetsverifieringen, administrations-API:et och hanteraren för operativa importer använder fasta klientfel och avgränsade diagnostikfält. Dessa hanterare begränsar feldetaljer som visas i webbläsaren och data som skrivs till deras diagnostik.
Granska kontrollerna bakom produkten.
Utforska arkitekturen och kontrollmekanismerna med er IT-avdelning. Ta med era krav på identitet, databehandling och drift i granskningen.
Implementationsunderlag
Arkitektur, behörighetsgränser och fokuserade kontrolltester. Dessa förklarar mekanismen och det beteende som testet prövar.
Driftunderlag
Granska målmiljö, konfigurerad identitetsleverantör, sessionsinställningar och driftsatta kontroller för ert företag.
Avtalsåtaganden
Diskutera behandlingsvillkor, underbiträden, behandlingsplatser, lagring och tjänstekrav som en del av er säkerhetsgranskning och ert avtal.
Identitet och åtkomst, i detalj.
| Kontroll | Implementerad mekanism | Kontrollens omfattning |
|---|---|---|
| SAML SSO | Provisionering härleder leverantören från verifierade autentiseringsuppgifter och en aktiv serverägd anslutning. Företag och standardroll kommer från den anslutningen. | Konfigureras per företag. Kundens IdP-konfiguration och fullständiga acceptanstest måste verifieras före användning. |
| Inbjudningar | Serverägda inbjudningar och accepterande fastställer medlemskap. Samtidigt accepterande, återkallande och rolländringar använder transaktions- och låsningsgränser. | Åtkomst följer godkänt medlemskap och aktuell roll. Återkallande gör tidigare inbjudningar ogiltiga. |
| Flerfaktorsautentisering | Användare kan registrera TOTP. Den skyddade applikationen begär verifiering av en registrerad användare när sessionen kan gå från AAL1 till AAL2. | Valfri, användarkonfigurerbar TOTP. Applikationen kontrollerar sessionens säkerhetsnivå för registrerade användare. |
| Kund- & Case-isolering | Organisationsavgränsade databaspolicyer och avgränsade Case-projektioner upprätthåller tillåten synlighet. Läsfunktionerna för Cases validerar behörigheten igen efter privilegierade innehållsläsningar. | Företagsmedlemskap, tillämplig Workroom-omfattning, Case-synlighet och aktuell integritetsstatus. |
| Operatörsåtkomst | Plattformsadministration använder databasbaserad operatörsbehörighet och en verifierad administrationsgräns, åtskild från kundens ägar- och administratörsroller. | Administrations-API:et verifierar plattformsoperatörens behörighet innan en administrativ åtgärd skickas vidare. |
Säkerhet, i praktiken.
Ta med ert frågeformulärHur skyddas modell- och e-postförfrågningar under överföring?
Ginsis modell- och transaktionsmejlintegrationer använder HTTPS med TLS för att kryptera förfrågningar under överföring. Inloggningsuppgifter på serversidan autentiserar dessa tjänsteanrop. Analysindata och e-postinnehåll väljs av respektive applikationsväg.
Hur styrs åtkomsten till företagsdokumentation?
Godkänt företagsmedlemskap och databasägda roller fastställer organisationsåtkomst. Radnivåsäkerhet (RLS) och dokumentationsspecifika behörighetskontroller tillämpar relevant företags- och synlighetsomfattning. Tjänster som läser Cases validerar en fast projektion av tillåten dokumentation och kontrollerar åtkomsten igen efter privilegierade läsningar.
Vilken information når AI-modellen?
Vägen för genererade Cases förbereder ett underlagspaket med tillåtna aggregat, källtäckning, dataluckor och relevant företagskontext. Andra aktiverade analysvägar kan innehålla indata på källnivå och sanerad text, inklusive enkätsvar där den analysvägen är tillämplig. Urvalet av indata beror på vägens underlagskontrakt; fritext kan fortfarande innehålla indirekta identifierare. Integritetspolicyn beskriver AI-behandlingen, och krav på leverantörens dataanvändning och lagring hanteras genom tillämpliga behandlingsvillkor.
Hur behörighetsstyrs plattformsadministrationen?
Administrations-API:et verifierar den autentiserade identiteten och kontrollerar databasbaserad plattformsoperatörsbehörighet innan en administrativ åtgärd skickas vidare. Rollen är åtskild från kundföretagets ägare och administratörer. Kundroller styr den egna organisationen; plattformsoperationer använder en egen behörighetsgräns.
Vad händer när åtkomst eller integritetsinställningar ändras?
Återkallat medlemskap gör tidigare inbjudningar ogiltiga. Läsfunktionerna för Cases bedömer aktuell synlighet och maskeringsstatus och validerar sedan behörigheten igen efter privilegierade innehållsläsningar. Case-baserad analys knyter sitt arbete till en integritetsrevision och kontrollerar den revisionen innan ett resultat sparas eller lämnas ut. Kontrollerna gör att ett ändrat tillstånd kan stoppa arbetet vid relevant gräns.
Hur skyddas små grupper i underlaget?
Statistiska uppdelningar använder källspecifika trösklar för minsta gruppstorlek. Relevanta kontroller räknar separata deltagare och tillämpar undertryckning av kompletterande grupper, vilket håller tillbaka relaterade resultat när subtraktion skulle kunna avslöja en liten grupp. Fritext och importerade attribut får separat integritetshantering. Där enkätsvar finns i underlaget är de fortsatt pseudonyma, inte garanterat anonyma.
Hur dokumenteras åtkomständringar?
Workroom-åtkomständringar skapar transaktionella händelseposter tillsammans med behörighetsändringen. Varje post binder aktören, berörd medlem och behörighetsrevisionen. Utvalda administrations- och importhanterare använder också avgränsade diagnostikfält. Åtkomsthändelser, operativ diagnostik och underlagshistoriken i ett Case fyller skilda granskningssyften.
