Vertrouwen is een mechanisme,
geen badge.

Gefundeerde antwoorden

De catalogus is de bron van waarheid.

De server haalt kandidaatproducten op voordat het model draait. Het model mag alleen ID's uit die set kiezen. Ongeldige ID's worden weggegooid, en prijs, voorraad, varianten en aanbiedingen worden aan de serverkant getoond. Heeft de catalogus geen antwoord, dan zegt de agent dat en biedt hij een overdracht aan.

Inloggegevens in rust

Geheimen zijn versleuteld, gebonden en geversioneerd.

Inloggegevens van aanbieders gebruiken AES-256-GCM met een random IV van 96 bits per record. Aanvullende geauthenticeerde gegevens binden de ciphertext aan provider:{providerId}:account:{accountId}:credentials, zodat een record dat naar een andere tenant is gekopieerd niet kan worden ontsleuteld. keyVersion ondersteunt sleutelrotatie; een mislukte ontsleuteling faalt veilig in plaats van een geheim terug te geven.

Salewise-verzoeken

Ondertekend, niet alleen bearer.

Verzoeken naar de Salewise-hoofd-API dragen een HMAC-SHA256-handtekening over de methode, het pad, de tijdstempel, de nonce en de SHA-256 van de body. De handtekening wordt in constante tijd vergeleken en begrensd door een replay-venster. De hoofdsleutel staat aan de serverkant, wordt één keer geconfigureerd, in rust versleuteld en nooit aan een browser teruggegeven.

Accounts en rollen

Een winkeliersaccount is geen serverbeheerder.

Sage heeft rollen voor winkelier en serverbeheerder. Wachtwoorden gebruiken scrypt met een salt per account. Toegangstokens verlopen na 15 minuten; refresh tokens worden als hash opgeslagen, bij gebruik geroteerd en verlopen na 30 dagen. Uitnodigingen verlopen na 7 dagen en zijn gebonden aan het uitgenodigde e-mailadres.

Tenant-isolatie

Een winkelopzoeking is een eigenaarscontrole.

Elke winkelroute bepaalt de winkel en controleert of die bij het geauthenticeerde account hoort voordat gegevens worden teruggegeven. Repository-methoden zijn afgebakend per account en winkel, en SQL staat achter de repository-laag in plaats van in routehandlers.

Kaartgegevens

Geen betalingen, geen PAN's.

Salewise neemt geen betalingen aan en slaat geen kaartgegevens op. De klant-PWA heeft geen afrekenproces, en de transactie blijft binnen het POS van de winkelier. We claimen geen PCI DSS-scope voor kaartbetalingen omdat we geen kaartbetalingen verwerken.

Bewaring

Geconfigureerd, niet oneindig.

De referentie-implementatie is ingesteld op 180 dagen voor sessietranscripten en 365 dagen voor gebeurtenisrecords, via omgevingsvariabelen en de DPA. Bewaring per winkelier wordt in de DPA afgesproken, en verwijdering gebeurt op verzoek. Een geplande opschoning claimen we vandaag niet.

Auditspoor

Beveiligingsrelevante gebeurtenissen laten een record achter.

Registratie, inloggen, mislukte login, uitnodigingen, inrichting en wijzigingen in integratie-inloggegevens worden naar een auditlogboek geschreven. E-mailadressen worden gehasht in auditdetails in plaats van ruw opgeslagen. Het logboek is vandaag intern; er is nog geen auditscherm voor winkeliers.

Modelgrens

Het model krijgt het minimum dat het nodig heeft.

Het model ontvangt de vraag van de klant, opgehaalde cataloguskandidaten, winkelinstellingen en relevante beleidstekst. Het ontvangt geen wachtwoorden, API-inloggegevens of kaartgegevens, en het heeft geen tool die naar het POS kan schrijven.

“Gebouwd” betekent dat de controle vandaag in het product bestaat. Het betekent niet dat elke controle onafhankelijk is geaudit. De leemte staat onderaan deze pagina.