Teknisk genomgång
Så fungerar Gateway – från köp till AI-svar
Gateway är en container som körs i er miljö, mellan era applikationer och de AI-tjänster ni godkänner. Här är hela kedjan: vad kundportalen gör, hur installation och företagsinloggning fungerar, vad som händer i varje anrop och exakt vad ni köper.
Först: det är två separata system
Kundportalen och Gateway har olika uppgifter och olika data. Ett konto på app.maskera.dev ger tillgång till leveransen; det är inte där texten maskeras.
Kundportalen hos Maskera
app.maskera.dev
Här hanterar ni organisation, konto, köp, licens och tillgängliga versioner. Portalen bygger installationspaketet i er webbläsare men tar aldrig emot text, återställningsnycklar eller AI-svar från er Gateway.
Gateway i er miljö
Ert Docker- eller Kubernetes-kluster
Här autentiseras anrop, policy tillämpas och text maskeras i arbetsminnet. Containern har ingen databas och behöver inte kontakta Maskera under drift.
Kundportalen hos Maskera
hämtas vid installation
- Er webbläsare
- Kundportal
- Installationspaket
trafik under drift
Hos er valda leverantör
Maskeras servrar ligger aldrig i vägen mellan er applikation och er AI-leverantör.
Från köp till körbar Gateway
Leveransen är gjord för att de känsligaste hemligheterna ska skapas och stanna hos er.
1. Åtkomst i kundportalen
Organisationens ägare får tillgång till avtalad pilot eller årslicens och den godkända Gateway-versionen.
2. Versionslåst leverans
Portalen lämnar ut en offline-licens och en exakt containerreferens. Versionen är signerad och har en komponentförteckning (SBOM).
3. Paketet byggs lokalt
Webbläsaren skapar en slumpad 256-bitars API-nyckel. Den öppna nyckeln visas en gång; bara dess SHA-256-verifierare skrivs till konfigurationen.
4. Ni driftsätter
ZIP-paketet startas med Docker Compose eller används som underlag för Helm. Ni lägger hemligheter i er egen hemlighetshanterare och sätter TLS framför tjänsten.
Det finns i installationspaketet
Samma paket täcker en enkel Linux-installation och en Kubernetes-installation:
- README med installationsordning
- Docker Compose-konfiguration
- Helm-värden för Kubernetes
- Gateway-konfiguration med hashad nyckel
- Signerad offline-licens och publik verifieringsnyckel
- Den öppna Gateway-nyckeln i en separat fil, visad en gång
- Automatiskt funktionstest efter start
- Exakt, versionslåst containerreferens
Paketet innehåller startfilerna och pekar ut den exakta signerade containerversionen. Modellen följer med i containern och hämtas inte vid varje start.
Vad ”företagsinloggning” betyder här
Gateway har ingen inloggningssida, användarsession eller egen katalog med medarbetare. Det är ett internt API. Identiteten följer därför med varje API-anrop.
Ingen ny inloggning för användaren
Er applikation fortsätter logga in användaren med exempelvis Microsoft Entra ID, Okta eller Keycloak. Applikationen skickar sedan användarens OIDC-token till Gateway som en Bearer-token.
Två autentiseringssätt
Lokal API-nyckel
Nyckeln skapas i webbläsaren när paketet byggs. Gateway jämför en SHA-256-hash och Maskera har aldrig den öppna nyckeln.
- Passar installationstest, tjänst-till-tjänst-anrop och mindre miljöer
- Behörigheter och policy kopplas till nyckelns konfiguration
- Rotera genom att skapa och driftsätta en ny nyckel
OIDC och företagets identitet
Gateway verifierar token mot er identitetsutfärdare och översätter användarens roller till behörigheter och en policy.
- Stöd för Entra ID, Okta, Keycloak och andra OIDC-kompatibla utfärdare
- Fjärr-JWKS eller en lokal JWKS-fil i er miljö
- Ingen användardatabas eller inloggningssession i Gateway
OIDC-flödet, steg för steg
Användaren loggar in hos er
Er applikation hämtar en signerad access-token från er vanliga identitetsutfärdare.
Token följer med anropet
Applikationen skickar Authorization: Bearer tillsammans med anropet till Gateway.
Gateway verifierar token
Signatur, tillåten algoritm, utfärdare, målgrupp och tidsgränserna nbf och exp måste stämma.
Roll blir behörighet och policy
Ert valda rollfält mappas till mask, proxy eller metrics och till exakt en namngiven policy. Motstridiga policyer nekas.
Exempel på en rollmappning
Rollnamnen bestämmer ni. Gatewayns fasta behörigheter är mask, proxy och metrics; klienten får aldrig välja policy i anropet.
| Roll från token | Tillåts göra | Tillämpad policy |
|---|---|---|
| Maskera.Support | mask, proxy | support-arenden |
| Maskera.Analys | mask | analys-utan-karta |
| Maskera.Overvakning | metrics | drift |
{
"auth": {
"mode": "oidc",
"issuer": "https://login.example.com/tenant/v2.0",
"audience": "api://maskera-gateway",
"jwksUri": "https://login.example.com/tenant/discovery/v2.0/keys",
"algorithms": ["RS256"],
"roleClaim": "roles",
"roles": {
"Maskera.Support": {
"permissions": ["mask", "proxy"],
"policy": "support-arenden"
}
}
}
}Om ni använder en JWKS-adress hämtar Gateway publika signeringsnycklar från den adress ni har angett, utan att följa omdirigeringar. Vill ni ha helt stängd nätverksdrift monterar ni i stället en lokal JWKS-fil.
Två sätt att koppla in Gateway
Välj proxy när ni använder ett OpenAI-kompatibelt chattflöde. Använd maskerings-API:et när ni vill styra vidarebefordran själva eller använder ett annat modell-API.
1. Maskera och hantera svaret själva
POST /v1/mask returnerar maskerad text och, om policyn tillåter, en återställningskarta. Er applikation bestämmer därefter vart texten skickas och om något ska återställas.
Er app → /v1/mask → maskerad text + eventuell karta → er fortsatta kod
curl -s https://maskera-gateway.ert-natverk.internal/v1/mask \
-H "Authorization: Bearer $MASKERA_GATEWAY_KEY" \
-H "Content-Type: application/json" \
-d '{
"text": "Lars Svensson ringde om fakturan.",
"return_map": true
}'2. Låt Gateway skydda hela AI-anropet
Byt basadress i en OpenAI-klient till Gateway. Den maskerar textdelarna, anropar endast den exakt tillåtna HTTPS-adressen och återställer platshållare i AI-svaret innan det går tillbaka.
Er app → Gateway → godkänd AI-tjänst → Gateway → er app
const client = new OpenAI({
apiKey: process.env.MASKERA_GATEWAY_KEY,
baseURL: "https://maskera-gateway.ert-natverk.internal/v1/openai",
})
const answer = await client.chat.completions.create({
model: "gpt-4o-mini",
messages: [{ role: "user", content: "Sammanfatta: Lars ringde om fakturan." }],
})Den inbyggda proxyn stöder i dag OpenAI-formatets Chat Completions. Andra leverantörer och format kan fortfarande användas genom /v1/mask, där er applikation gör AI-anropet.
Vad som händer i ett proxyanrop
Varje anrop går igenom samma ordning. Ett fel stoppar kedjan; Gateway skickar inte omaskerad text vidare som reservväg.
1. Driftberedskap
Gateway kontrollerar att offline-licensen är giltig, modellen är laddad och anropet ryms inom satta gränser.
2. Autentisering
API-nyckeln eller OIDC-token verifieras. Identiteten måste ha behörigheten proxy.
3. Policy
Gateway väljer den policy som serverkonfigurationen kopplat till identiteten. Klienten kan inte begära en mildare policy.
4. Maskering i minnet
Tillåtna textfält läses, personuppgifter upptäcks och ersätts med stabila platshållare. Återställningskartan hålls i arbetsminnet.
5. Exakt AI-adress
Den maskerade förfrågan skickas till den HTTPS-adress som finns i er tillåtelselista. Omdirigeringar och godtyckliga mål accepteras inte.
6. Återställning
Om policyn kräver det ersätter Gateway kända platshållare i AI-svarets textdelar med originalvärdena.
7. Svar och mätvärden
Svaret går till er applikation. Endast grov metadata som status, tid och antal tecken kan loggas eller mätas – inte nyttolasten.
Policyn är kontrollpunkten
En namngiven policy bestämmer samma regler för alla anrop från en identitet. Den kan bland annat styra:
- om den svenska NER-modellen ska användas och vilka etiketter som får upptäckas
- om bara regelbaserade identifierare får användas
- maximal text- och kroppsstorlek
- om /v1/mask får lämna ut en återställningskarta
- om proxyn ska återställa AI-svaret eller alltid lämna platshållarna kvar
- vilka textfält som stöds; okända eller otillåtna fält nekas i stället för att passera oskyddade
Policyn väljs på serversidan. Ett fält i kundens anrop kan därför inte stänga av ett skydd som policyn kräver.
Data, loggar och nätverk
Gateway är tillståndslös mellan anrop. Det gör gränsen tydlig, men er omgivande infrastruktur är fortfarande en del av helheten.
I arbetsminnet
Originaltext, maskerad text, återställningskarta och AI-svar finns bara medan anropet behandlas och skrivs inte till Gatewayns databas eller logg. Gateway har ingen databas.
På nätverket
Vid proxy går bara den maskerade förfrågan till er tillåtna AI-tjänst. Gateway kontaktar inte Maskera. OIDC kan använda den JWKS-källa som ni uttryckligen har konfigurerat.
I loggar och mätvärden
Gateway loggar inte nyttolast, Authorization-header eller återställningskarta. Driftdata begränsas till exempelvis statuskod, svarstid och mängd text.
Det ni driver runt Gateway räknas också
En ingress, lastbalanserare, APM-agent eller AI-leverantör kan ha egen loggning. Ni behöver konfigurera även dessa så att de inte sparar originaltext, headers eller återställda svar på ett sätt ni inte avsett.
Licens, versioner och uppdateringar
Gateway är byggd för att kunna köras utan en löpande anslutning till Maskera och för att ni själva ska styra när produktionsmiljön ändras.
Offline-licens
Licensfilens signatur och giltighet kontrolleras lokalt med den publika nyckeln i paketet. Ingen aktiveringsserver kontaktas under drift.
Signerad och låst version
Containern anges med en oföränderlig digest, signeras och publiceras med SBOM så att leveransen kan granskas och låsas i er ändringsprocess.
Ni väljer uppdateringstid
Nya godkända versioner blir tillgängliga i kundportalen. Ni testar och driftsätter dem när det passar er miljö.
När licensen har löpt ut fortsätter /healthz visa att processen lever, men /readyz och produktionsanrop stoppas. Gateway fortsätter inte med ett oskyddat reservflöde.
När något går fel
Fel svarar med en statuskod och ett nyttolastfritt felmeddelande. De vanligaste gränserna är:
| Status | Gateway stoppar anropet när |
|---|---|
| 400 | Texten saknas eller anropet har fel format |
| 401 | Nyckeln eller inloggningen saknas, är fel eller har stängts |
| 403 | Er policy eller identitet tillåter inte åtgärden |
| 413 | Texten eller hela anropet är för stort |
| 422 | AI-anropet innehåller fält som proxyn inte stödjer |
| 502 | AI-tjänsten gick inte att nå eller svarade felaktigt |
| 503 | Licensen är ogiltig, modellen är inte redo eller tjänsten är tillfälligt full |
Det här är det ni faktiskt köper
Gateway-licensen är en företagsleverans av maskeringslagret i er miljö. Den är inte en driftad AI-tjänst och flyttar inte driftansvaret för er infrastruktur.
Det ingår
- Gateway-container med den svenska modellen inbyggd
- Docker Compose-filer och Helm-värden
- Stöd för lokal API-nyckel och OIDC
- Policyer, OpenAPI-specifikation och funktionstest
- Offline-licens för avtalade miljöer
- Signerade, oföränderliga versioner med SBOM
- Säkerhetsuppdateringar och e-postsupport enligt erbjudandet
- Dokumentation för installation, drift och felsökning
Det ingår inte automatiskt
- Servrar, Kubernetes, nätverk, TLS eller driftövervakning
- Konto, avtal eller API-nyckel hos er AI-leverantör
- Konfiguration av Entra ID, Okta, Keycloak eller era interna roller
- Anpassning av era applikationer och era egna textflöden
- Garanti att automatisk maskering hittar varje personuppgift
- Juridisk bedömning eller garanti att er helhetslösning uppfyller alla regelverk
- Särskilt servicenivåavtal, installationsuppdrag eller jour om det inte avtalats separat
Inför produktion behöver ni fortfarande testa era verkliga texttyper, välja policy och validera identitet, nätverk, loggning och AI-leverantör. Det är kundspecifikt – men produktens tekniska gräns och leverans är densamma.
Fortsätt på rätt detaljnivå
Den här sidan förklarar helheten. API-referensen visar exakta anrop och fel, datasidan beskriver behandlingsgränsen och prissidan visar de kommersiella villkoren.