Tekniske spørgsmål
Teknisk tillid bør komme fra dokumentation, ikke fra tillægsord
Specify er før produktion. Denne side beskriver det system, vi bygger hen imod, og hvordan det er designet, så en teknisk læser kan vurdere, om ingeniørarbejdet er seriøst, før noget står på spil.
Designprincipperne er isolation, holdbarhed, kontrolleret ændring, observerbar drift og en udtrykkelig grænse mellem det, software må fortolke, og det, en virksomhed faktisk har godkendt. Det sidste er det, de fleste handelssystemer får galt, og det er det, Specify er bygget omkring.
Nuværende stadie: Før produktion
Platformen er under aktiv udvikling og validering og er endnu ikke omfattet af et offentligt produktionstilsagn om tilgængelighed. Kontroller, der nedenfor beskrives som produktionskrav, er designtilsagn frem for udført arbejde, og vi beskriver ikke en foreslået sikkerhedsforanstaltning, som var den allerede afprøvet.
Sådan er det designet
Fem principper, arkitekturen er bygget på
Det er beslutninger, der er truffet tidligt, fordi hver af dem bliver dyr at eftermontere. Det er dem, en arkitekt ville ville udspørge først.
- Fejl inddæmmes, de forhindres ikke
- Systemet er designet til at fejle på afgrænsede, observerbare og genoprettelige måder frem for at påstå, at det ikke vil fejle. Valgfri kapacitet forringes uden at tage de centrale kommercielle registreringer med sig, og langvarigt eller fejludsat arbejde er isoleret fra anmodningsvejen. Det offentlige site er fuldt præ-renderet uden server på anmodningstidspunktet, så det forbliver tilgængeligt uafhængigt af alt bagved.
- Kompetence er udtrykkelig og adskilt fra fortolkning
- Fortolkende tjenester har ingen stående kompetence til at ændre kommercielle registreringer eller forpligte en forhandler. Hvad der må tilbydes, kommer fra godkendt kapacitet, begrænsninger og prisregler, håndhævet deterministisk. Det er arkitektonisk frem for procedurermæssigt: grænsen holder, uanset hvad en prompt eller en model gør.
- Lejerskab håndhæves i datalaget
- Autorisation ender som en forespørgselsbegrænsning frem for et tjek, en kalder kunne påvirke, så en forespørgsel afgrænses til den forhandler, den tilhører, før data læses frem for at blive filtreret bagefter. Isolationen er dækket af test på både enheds- og integrationsniveau.
- Tilstand er holdbar, og skemaændring er bevidst
- Autoritative kommercielle data ligger i administreret PostgreSQL, hvor skemaændringer indføres gennem gennemgåede, versionsstyrede migreringer frem for automatisk synkronisering, og anvendes før den kode, der afhænger af dem.
- Operationer er idempotente
- Gentagne forsøg og genudsendelse er forventede tilstande frem for undtagelser. At gentage en operation må ikke skabe en dobbelt kommerciel registrering, en dobbelt besked eller en dobbelt ekstern handling.
Pålidelige systemer er designet til at fejle på inddæmmede, observerbare og genoprettelige måder.
Produktionsdesign
Hvordan produktion ser ud, og hvor vi står i forhold til det
Designet ligger fast. Noget af det er bygget og i brug i udvikling i dag; resten er produktionskrav, vi holder os selv til, før vi accepterer kundebelastning.
- Bygget og i brug
Topologi
Et statisk serveret offentligt site på kanten og separat udrullede applikationstjenester bag det: en forhandlerapplikation, et commerce-API, en indholdstjeneste og baggrundsarbejdere. Separate udrulninger med separate fejltilstande, så en hændelse ét sted ikke bliver et nedbrud alle steder.
- Bygget og i brug
Identitet og adgang
Administreret identitet med OIDC authorisation-code-flowet og PKCE, HttpOnly-sessionscookies og rollebaseret autorisation håndhævet på serversiden. Administrativ adgang er adskilt fra almindelig forhandleradgang.
- Bygget og i brug
Isolation mellem lejere
Afgrænsning til forhandler håndhæves som en begrænsning i datalaget frem for som et filter i applikationen, og lejeridentitet tages aldrig fra en værdi, kalderen angiver. Adgang på tværs af lejere testes frem for at blive forudsat.
- Bygget og i brug
Ændring og levering
Enhver ændring gennemgås, bygges én gang og testes automatisk, før den når noget miljø, herunder integrationstest mod en rigtig database. Skemamigreringer kører før den kode, der afhænger af dem.
- Produktionskrav
Produktionsudrulning
Godkendelsesstyret produktionsudrulning med trinvis udrulning, sundhedsporte på fejlrate, svartid og gennemførelse af kritiske arbejdsforløb samt en afprøvet tilbagerulningsvej. Bagudkompatible migreringer, hvor destruktiv oprydning er adskilt fra den ændring, der indfører den.
- Produktionskrav
Holdbarhed og genopretning
Automatiserede krypterede sikkerhedskopier med defineret opbevaring og slettebeskyttelse, punkt-i-tid-genopretning og replikering afpasset de fejlklasser, den skal håndtere. Genopretningsmål fastsættes, når en gendannelse faktisk er udført og målt, ikke før.
- Produktionskrav
Observerbarhed
Struktureret telemetri korreleret på tværs af tjenester, serviceniveauindikatorer defineret mod kritiske kunderejser frem for procesliv, og syntetiske tjek, der gennemfører et reelt arbejdsforløb. Følsomme værdier udelukkes fra logs ved konstruktion frem for ved efterfølgende redigering.
- Produktionskrav
Driftsrespons
Alarmer knyttet til kundesynlige fejl, hver med en ansvarlig, en eskaleringsvej og en drejebog, afprøvet fra ende til anden før lancering. En defineret alvorlighedsmodel, en offentlig statuskanal og en forholdsmæssig gennemgang efter enhver væsentlig hændelse.
- Produktionskrav
Sikkerhedsvalidering
Automatiseret afhængigheds- og hemmelighedsscanning i pipelinen, et administreret hemmelighedslager med rotation og uafhængig sikkerhedstest bestilt ved lancering og ved væsentlige risikomilepæle. Fund udbedres og efterprøves, før de beskrives som løst.
Abonnementet er med til at finansiere det ingeniør- og driftsarbejde, der skal til for at bevæge sig fra før-produktion mod en pålidelig produktionstjeneste. At betale for noget gør det ikke produktionsklart, og denne side påstår ikke andet; det, prisen køber, er arbejdet, ikke statussen.
Det er bevidst det niveau, en arkitekt har brug for for at vurdere tilgangen. En kontrol-for-kontrol-redegørelse for, hvad der er implementeret, testet og udestående, er tilgængelig for kunder, partnere og bedømmere under en passende aftale, og formularen nedenfor er vejen dertil.
AI-kontroller
Fortolkning er ikke kompetence
AI kan hjælpe med at forstå en forespørgsel. Den fastslår ikke selvstændigt, hvad en forhandler har godkendt.
Størstedelen af den kommercielle risiko i et AI-understøttet system opstår, når et sandsynligt svar forveksles med et godkendt. Specify behandler det som et arkitekturproblem frem for et prompt-problem, fordi en grænse, der håndhæves med instruktioner, ikke er en grænse.
- Identitet er ikke et modelinput
- Hvilken forhandler en forespørgsel tilhører fastslås ud fra den autentificerede session og indsættes på serversiden. Det er ikke noget, en model kan påstå, og et forsøg på at angive det afvises frem for at blive ignoreret.
- Kapaciteten er afgrænset ved konstruktion
- De handlinger, assistenten har til rådighed, er fastlagt i kode frem for samlet ved kørsel, og destruktive operationer er ikke blandt dem. Ingen prompt kan udvide dem.
- Ændringer klassificeres deterministisk
- Enhver foreslået ændring vurderes af en politikmotor, der kører på den resulterende ændring frem for på erklæret hensigt. Alt uklassificeret afvises som standard, og forhandler- eller platformsoverstyringer må kun stramme en klassificering, aldrig løsne den.
- Kommercielt følsomme data er uden for rækkevidde
- Prisinput, leverandørværdier og interne felter er udelukket fra det, modellen overhovedet kan læse, frem for at blive filtreret fra det, den producerer.
- Ikke-betroet indhold behandles som ikke-betroet
- Forhandler- og kundeindhold håndteres som data frem for som instruktion. En injektion kan i værste fald producere en foreslået handling, som politikmotoren derefter vurderer på dens egne præmisser.
- Utilgængelighed forringes sikkert
- Når modeludbyderen er langsom, fejler eller ikke er konfigureret, melder assistenten sig utilgængelig, og forespørgslen bevares. Intet opfinder et svar for at dække over en fejl.
Systemprompten behandles ikke som en sikkerhedskontrol, for det er den ikke. Hver grænse ovenfor håndhæves i deterministisk kode, og det er den eneste grund til, at den overhovedet kan beskrives som en kontrol her.
Tekniske spørgsmål
De spørgsmål, bedømmere stiller
Besvaret direkte, også hvor svaret er nej.
Er Specify i produktion?
Nej. Specify er før produktion og gennemgår produkt-, infrastruktur-, sikkerheds- og driftsvalidering. Alt, der på denne side beskrives som et produktionskrav, er et designtilsagn frem for udført arbejde.
Hvor hostes Specify?
På Microsoft Azure, hvor det offentlige site serveres statisk på kanten, og applikationstjenesterne udrulles separat bag det. Administreret PostgreSQL rummer autoritative kommercielle data, og objektlagring rummer medier. Regioner, ressourcekonfiguration og netværksdetaljer deles under en teknisk gennemgang frem for at blive offentliggjort.
Hvilket tilgængelighedstilsagn gælder?
Ingen endnu, og vi offentliggør ikke et tal, før det kan måles. En indikator er det, der måles, et mål er en intern målsætning, og en aftale er et kontraktligt tilsagn med misligholdelsesbeføjelser. De tre ting er forskellige, og vi bruger dem ikke i flæng.
Hvordan beskyttes data mod tab?
Gennem automatiserede krypterede sikkerhedskopier med defineret opbevaring og slettebeskyttelse, punkt-i-tid-genopretning og replikering afpasset de fejlklasser, den håndterer. Replikering og sikkerhedskopier løser forskellige problemer, og det ene erstatter ikke det andet. Genopretningsmål offentliggøres, når en gendannelse er udført og målt frem for anslået.
Kan Specify udrulle uden nedetid?
Produktionsmålet er at udrulle rutinemæssige kompatible ændringer uden at afbryde kritiske arbejdsforløb, gennem trinvis udrulning og sundhedsporte. Noget vedligehold, infrastrukturændringer og akutte operationer kan stadig kræve en kontrolleret afbrydelse, og det siger vi hellere end at love andet.
Hvordan isoleres kundedata?
Autorisation ender som en begrænsning i datalaget, så en forespørgsel afgrænses til den forhandler, den tilhører, før data læses frem for at blive filtreret bagefter, og lejeridentitet tages aldrig fra en værdi, kalderen angiver. Adgang på tværs af lejere er dækket af test på enheds- og integrationsniveau.
Kan AI godkende et tilbud eller et tilsagn?
Nej. AI må hjælpe med at fortolke og strukturere en forespørgsel. Kommerciel kompetence kommer fra godkendt kapacitet, begrænsninger, prisregler og autoriserede menneskelige eller deterministiske kontroller, og politikmotoren afviser enhver ændring, den ikke har en klassificering for.
Bruges kundedata til at træne AI-modeller?
Nej. Indsendte kunde- og virksomhedsoplysninger bruges ikke til at træne generelle modeller. Hvad der sendes til en modeludbyder, og hvorfor, fremgår af privatlivspolitikken.
Har Specify gennemført en penetrationstest eller en certificeringsaudit?
Nej. Uafhængig sikkerhedstest bestilles ved lancering og ved væsentlige risikomilepæle. Når en vurdering finder sted, oplyser vi dens type, omfang, dato, bedømmerens uafhængighed og om væsentlige fund blev løst, frem for vagt at henvise til at være blevet auditeret.
Hvilke standarder arbejder I efter?
Vores ingeniørprogram bruger NIST Cybersecurity- og Secure Software Development-rammeværkerne, OWASP Application Security Verification Standard og CISA Secure by Design-principperne som referencepunkter. En henvisning til et rammeværk er ikke det samme som certificering, uafhængig validering eller gennemført implementering, og Specify har ingen certificering i dag.
Kan vi bede om detaljeret sikkerhedsdokumentation?
Ja. Arkitekturresuméer, kontroloversigter, oplysninger om underdatabehandlere, databehandlervilkår og besvarelser af spørgeskemaer er tilgængelige under en passende aftale via formularen nedenfor. Vi offentliggør ikke en detaljeret kontroloversigt på en offentlig adresse, og vi siger til, når noget endnu ikke findes, frem for at sende et beslægtet dokument.
Hvor kan jeg se den aktuelle driftsstatus?
På statussiden, som rapporterer tilstanden før produktion og ikke viser et produktionstal for tilgængelighed, fordi der endnu ikke er en produktionstjeneste at måle.
Teknisk kontakt
Stil et teknisk spørgsmål
Kunder, partnere og investorer kan bede om tekniske, sikkerhedsmæssige eller driftsmæssige oplysninger, det ikke er passende at offentliggøre åbent. Arkitekturresuméer, lister over underdatabehandlere, databehandlervilkår og besvarelser af spørgeskemaer er alle tilgængelige ad denne vej.
Angiv ikke adgangskoder, adgangstokens, private nøgler eller følsomme produktionsdata i denne formular.
Spørg
Stil et teknisk spørgsmål
Kunder, partnere og bedømmere kan bede om de tekniske, sikkerhedsmæssige og driftsmæssige detaljer, det ikke er passende at offentliggøre åbent.