Säkerhet

Digital Plattform Sverige AB, ett svenskt bolag i Linköping. Plattformen byggs och drivs av samma team — det finns ingen utlagd driftleverantör mellan oss och de körande systemen.

Teamet är litet. Vi behandlar det som en åtgärd snarare än en brasklapp: åtkomst ges till namngivna personer, och listan över dem som kan nå produktion är kort nog att granskas genom att läsas.

Varje kund kör sitt eget system med sin egen databas, ihopsatt av gemensamma plattformsfunktioner. Kunduppgifter är åtskilda på databasnivå, inte av en kundkolumn i en delad tabell.

Förbättringar i plattformen landar under varje system utan ett migreringsprojekt, vilket är vad som gör en gemensam funktionsuppsättning värd att ha.

Det här Trust Center är huvuddokumentet, och det är offentligt så att en granskare kan börja utan att kontakta oss. Ett personuppgiftsbiträdesavtal finns på begäran.

För ett säkerhetsformulär, en arkitekturgenomgång eller en specifik åtgärd vi inte tagit upp här, hör av er till security@digitalplatform.ai så svarar en ingenjör som arbetar med plattformen.

I den AWS-region som ligger närmast er. Regionen sätts utifrån var ni finns när ert system sätts upp, och hela systemet körs där: beräkning, plattformsdatabasen, fillagring, säkerhetskopior och utgående mejl.

Det är i första hand ett svarstidsbeslut: ett system som betjänar människor i en del av världen ska inte besvara deras förfrågningar från andra sidan av den. I andra hand är det ett beslut om var uppgifterna finns — en kund inom EU får sina uppgifter kvar i EU för att systemet körs i en EU-region.

Undantaget är en tjänst ni väljer att slå på vars leverantör ligger någon annanstans. AI-funktionerna är fallet som spelar roll; sidan om underbiträden namnger varje leverantör och den region den behandlar i.

Ja. Närmaste region är standardvalet, inte en begränsning — namnge den region ert system måste köras i så driftsätts det där, förutsatt att vi stöder den.

Stöd är den ärliga reservationen: en region vi kör i är en där hela systemet körs, inte en halv driftsättning med delar kvar någon annanstans. Fråga vilka regioner som stöds i dag så får ni den aktuella listan i stället för ett påstående om alla.

Det täcker det vanliga upphandlingskravet — uppgifter får inte lämna en namngiven jurisdiktion — och svarar på det med var systemet är driftsatt i stället för med en policyformulering om saken.

Amazon Web Services. Fysisk säkerhet och miljösäkerhet i datacentren är AWS ansvar enligt deras modell för delat ansvar; allt ovanför hypervisorn är vårt.

Vi kör på egna AWS-konton snarare än en återförsäljares, så kontonivåns åtgärder, fakturering och granskningsspår tillhör oss direkt. Samma plattform driftsätts i vilken AWS-region som helst, så valet av region kostar er aldrig en annan arkitektur eller en annan uppsättning åtgärder.

Plattformsdatabasen kör som en replikuppsättning av MongoDB i egen drift, så att en nod som faller bort varken tar ned datalagret eller kräver en fullständig återläsning för att ersättas.

Applikationsservrar kör på andra instanser än databasen. Säkerhetskopior tas oberoende av replikuppsättningen, så att förlorade uppgifter och utebliven tillgänglighet återställs av olika mekanismer.

Planerat: omkoppling över flera tillgänglighetszoner för applikationsservrar. I dag är vägen tillbaka för en förlorad instans en ombyggnad från den dagliga maskinavbilden, inte en automatisk omkoppling.

Publika ändpunkter avslutar TLS i nginx och ingenting annat är exponerat. Administrativ åtkomst sker över SSH på en icke-standardport, begränsad till nyckelbaserad autentisering — lösenordsinloggning är avstängd.

Plattformsdatabasen går inte att nå från det publika internet. Den tar emot anslutningar bara på det interna nätverket.

Planerat: en formell genomgång av nätverkssegmentering och dokumenterade ingångsregler per tjänstelager.

Ja, och åtskillnaden upprätthålls i plattformen snarare än av vana. Produktion, test och lokal utveckling är skilda miljöer med skild konfiguration och skilda inloggningsuppgifter.

Miljöer utanför produktion hindras från att agera mot omvärlden: de skickar inga riktiga mejl eller sms, och de behandlar aldrig betalningar. Det är regler per miljö i plattformens konfiguration, inte något en ingenjör måste komma ihåg att stänga av.

En utvecklare som arbetar med en funktion har inte produktionsuppgifter som en bieffekt av det arbetet.

All publik trafik är HTTPS. TLS 1.2 eller högre krävs, certifikaten utfärdas av Let's Encrypt och förnyas automatiskt, och vanlig HTTP omdirigeras i stället för att besvaras.

Trafiken mellan applikationen och plattformsdatabasen stannar på det interna nätverket och exponeras inte mot det publika internet.

Säkerhetskopior är krypterade i vila. AWS Backup-valvet med maskinavbilder är krypterat med AWS KMS, och databasens säkerhetskopior skrivs till S3 i samma region.

Applikationens hemligheter är krypterade i vila oberoende av lagringslagret, som nästa svar beskriver.

Planerat: full diskkryptering på databasens och applikationernas primära volymer. Vi har inte slagit på det på de befintliga volymerna, och vi säger hellre det här än låter en granskare anta något annat.

Hemligheter ligger aldrig i källkodshantering och aldrig i klartextfiler på en server. Varje par av system och miljö har ett eget RSA-nyckelpar i ett krypterat valv. Den privata nyckeln är krypterad med AES-256-GCM under en nyckel härledd med scrypt ur ett operatörslösenord, och själva hemligheterna lagras som ett hybridkrypterat block under det nyckelparet.

Vid körning avkrypterar en server blocket till minnet. Den cache en server håller på disk går bara att läsa för det tjänstekonto som äger den.

Den praktiska följden: att läsa en databasexport, ett säkerhetskopiearkiv eller ett källkodsarkiv ger inte en angripare fungerande inloggningsuppgifter.

Nyckelpar skapas per system och miljö, så att en komprometterad miljös nyckel inte blottar en annans. Varje post i valvet noterar när den senast byttes.

Nycklar för AWS-hanterad kryptering — säkerhetskopievalvet — hanteras av AWS KMS inne i vårt eget konto.

Planerat: ett fast schema för nyckelbyte med automatisk efterlevnad. Byte är i dag en operatörsåtgärd som utförs när omständigheterna kräver det snarare än på tid.

E-post och lösenord är standardsättet. Tvåfaktorsinloggning med en engångskod via mejl kan krävas för varje inloggning till ett system, och den ställs in per system och per miljö snarare än överlåts åt varje användare att välja till.

BankID stöds för svensk e-legitimation där ett system kräver styrkt identitet.

Planerat: SAML 2.0, OpenID Connect och gemensam inloggning för organisationer. De är inte införda i dag. Är gemensam inloggning ett krav för er organisation — säg det under utvärderingen snarare än efter; det påverkar tidplanen.

Ja, som en engångskod via mejl ovanpå lösenordet. Den kan göras obligatorisk för ett helt system, så det är ett administratörsbeslut snarare än en inställning per användare.

Planerat: autentiseringsappar med TOTP och hårdvarunycklar. Mejl är den enda andra faktorn som finns i dag.

Rollbaserad åtkomstkontroll med en rollhierarki — läsare, användare, administratör, superadministratör — där en högre roll ärver behörigheterna från de under. Ovanpå rollerna kan åtkomstregler kopplas till enskilda användare eller till grupper, och till särskilda resurser eller enskilda poster.

Behörigheter prövas per resurs och per åtgärd: läsa, skriva, skapa och radera är åtskilda. Gruppmedlemskap är det vanliga sättet att ge åtkomst i stor skala, och bara aktiva grupper ger något.

Åtkomstbeslut fattas på servern vid varje förfrågan. Att dölja en knapp i gränssnittet är inte hur åtkomst upprätthålls.

Genom nyckelbaserad SSH till namngivna konton. Lösenordsautentisering är avstängd, och det finns ingen delad administratörsinloggning.

Produktionsuppgifter ligger i det krypterade valvet och avkrypteras per operatörssession snarare än delas ut som filer. Driftsättningar körs från en operatörs egen maskin mot en bestämd miljö, så en åtgärd mot produktion går alltid att härleda till en person.

Planerat: formella återkommande åtkomstgenomgångar med dokumenterat utfall. I dag är åtkomstlistan kort och granskas när den ändras, men den granskningen är ännu inte en schemalagd, dokumenterad åtgärd.

Bara när det finns ett skäl: ett supportärende ni själva öppnat, eller en incident som drabbar ert system. Vi bläddrar inte i kunduppgifter.

Där ett systems uppgifter nås genom applikationen registrerar granskningsloggen vem som gjorde det, vad de rörde och när — samma logg som registrerar era egna användares åtkomst, utan någon separat ologgad personalväg.

Varje post registrerar den handlande användaren och dennes e-postadress, kontot åtgärden hörde till, själva åtgärden, resurstypen och dess identifierare, klientens IP-adress, en allvarlighetsgrad och fritext där åtgärden bär någon.

Åtgärderna som täcks är läsa, skriva, skapa, radera, logga in och nekad åtkomst. Ett nekat åtkomstförsök registreras lika medvetet som ett lyckat — ett spår av nekad åtkomst är vad som visar att någon provar sig fram.

Ja. Inloggningar granskningsloggas med handlande användare och ursprungs-IP, liksom nekad åtkomst. Misslyckad autentisering och administrativa åtgärder utförda genom applikationen hamnar i samma spår.

Ja. Infrastrukturmått och larm körs i Amazon CloudWatch över hela maskinparken och täcker värdarnas och tjänsternas hälsa.

Planerat: samlad logghopsamling med sökning och bevarandetider över applikations-, system- och granskningsloggar. I dag ligger de loggarna på sina respektive värdar och i plattformsdatabasen snarare än i en gemensam sökbar lagring.

Ja. Granskningsspåret är era uppgifter — det tillhör ert systems databas och går att exportera som allt annat i den. Hör av er så visar vi hur ni når det för ert system.

Planerat. Vi har inte beställt ett oberoende penetrationstest av plattformen från tredje part, och vi tänker inte antyda något annat.

Är ett penetrationstest ett villkor i er upphandling — säg det under utvärderingen. Vi diskuterar omfattning och tidpunkt, och ett kundbeställt test mot en testmiljö är något vi går med på.

Beroenden uppdateras som en del av vanligt utvecklingsarbete, och plattformen kör en enda gemensam uppsättning beroenden snarare än en per kund — så en uppdatering når varje system på en gång i stället för att införas installation för installation.

Planerat: automatisk sårbarhetsskanning av beroenden inbyggd i bygget med ett bestämt åtgärdsfönster. Genomgång av beroenden sker i dag för hand.

Uppdateringar av operativsystem och paket införs av operatörer som del av underhållet, och maskinavbilder tas dagligen, så att en uppdatering som slår fel går att backa till gårdagens avbild.

Planerat: en dokumenterad uppdateringstakt med uppföljda tider per allvarlighetsgrad. Vi utfäster i dag inget fast fönster för att införa en viss allvarlighetsgrad, och att skriva ett här som vi inte mäter vore värdelöst för er.

Mejla security@digitalplatform.ai med tillräckligt underlag för att återskapa problemet. Ta med berörd adress eller ändpunkt, stegen, och vad ni lyckades visa.

Vi ber er ge oss rimlig möjlighet att rätta ett problem innan ni offentliggör det, att inte komma åt, ändra eller radera uppgifter som tillhör någon annan, och att inte köra tester som försämrar tjänsten för andra kunder. Inom de ramarna vidtar vi inga rättsliga åtgärder mot en rapport i god tro.

Vi bekräftar er rapport, säger vad vi hittade och säger till när det är rättat. Planerat: ett bug bounty-program. Det finns ingen betald belöning i dag.

Ändringar granskas mot en skriven ingenjörsregelbok som täcker struktur, dataåtkomst och säkerhetsrelevanta mönster. Regelboken upprätthålls i granskningen snarare än överlåts åt enskilt omdöme, vilket är vad som gör granskningen likadan i ett litet team.

Plattformens gemensamma arkitektur är i sig en del av den kontrollen: dataåtkomst, behörighetskontroller och validering är byggda en gång i plattformen snarare än om igen per funktion, så en granskning kontrollerar att en funktion använde rätt mekanism, inte om den hittade på en säker.

Ja. Plattformen har enhets- och integrationstester, plus tester som driver den riktiga applikationen i en webbläsare från början till slut. Testerna körs före ett släpp, och ett släpp går inte vidare på en svit som fallerar.

Planerat: löpande integration som kör hela sviten automatiskt vid varje ändring. Testkörningar utlöses i dag som del av släppprocessen snarare än av en driftad bygg-kedja.

En ändring går till test före produktion. Varje släpp märks, och ett produktionssläpp driftsätter exakt den incheckning som släpptes till test och verifierades där — inte en ombyggnad från grenens senaste läge.

Varje släpp tar en ögonblicksbild i förväg, och det finns en dokumenterad rutin för att gå tillbaka. Att backa är en vanlig åtgärd snarare än en improvisation i nödläge.

Släpp utförs av en operatör snarare än automatiskt vid sammanslagning. Det är ett medvetet byte: färre automatiska driftsättningar, och en namngiven person ansvarig för var och en.

Kundsystem sätts ihop av plattformsfunktioner, så det mesta som ändras kommer som en plattformsförbättring som redan gått genom test och verifiering innan den når någon kund.

Ändringar som rör just ert system kommer vi överens om med er först. Ni är inte testmiljö för någon annans funktion.

Varje server säkerhetskopierar sig själv dagligen till krypterad objektlagring i sin egen region, på ett automatiskt schema, med sju dagars bevarandetid upprätthållen av en livscykelregel i lagringen. Kopiorna stannar i den region systemet körs i, så en säkerhetskopia blir aldrig det som flyttar era uppgifter över en gräns. De ligger skilda från servern som skapade dem — ingenting hänger på att en lokal kopia överlever.

Plattformsdatabasen kopieras dessutom med en löpande operationslogg, vilket gör det möjligt att läsa tillbaka till en tidpunkt i stället för bara till den senaste nattliga kopian.

Maskinavbilder av varje server tas dagligen och sparas i tre dagar, så att en hel värd byggs om snarare än installeras om.

Återläsningar görs från de här kopiorna i praktiken, och rutinen är dokumenterad snarare än något som återuppfinns under press. Den kräver att arkivet verifieras som helt innan något skrivs över, och att en färsk säkerhetskopia tas först, så att en återläsning som går fel i sin tur går att ångra.

Planerat: schemalagda återläsningsövningar med noterat utfall. Återläsningar verifieras i dag när de utförs snarare än enligt kalender.

Vi publicerar varken mål för återställningstid eller för hur mycket data som får gå förlorad, eftersom vi ännu inte mäter återställning mot ett sådant mål och en siffra vi inte prövat inte vore värd något för er.

Vad vi kan säga som fakta: säkerhetskopior körs dagligen, plattformsdatabasen klarar återläsning till tidpunkt ur sin operationslogg, och maskinavbilder från dagen innan finns för varje server.

Planerat: uppmätta och publicerade mål för återställningstid och dataförlust, underbyggda av övningsresultat.

Ni får dem. Era uppgifter går att exportera när som helst i maskinläsbar form, och exporten är inte villkorad av varför ni frågar eller av läget i en affärsrelation.

Först begränsa, sedan återställa, sedan förklara. En incident bedöms efter omfattning och kundpåverkan, begränsas och återställs med de dokumenterade rutinerna för återläsning och återgång. Tillståndet i drabbade system bevaras där det går utan att fördröja återställningen, så att orsaken kan fastställas efteråt.

Samma människor som bygger plattformen svarar på dess incidenter. Det finns ingen eskaleringskö mellan en anmälan och någon som kan agera på den.

Genom direktkontakt med de personer ni utsett för det, inte genom en statussida ni skulle behöva bevaka. Ni får veta vad som hänt, vad det påverkade, vad vi gjorde och vad ni behöver göra — även när svaret är ingenting.

Vi hör av oss medan en incident pågår snarare än först när den är löst, även när vi ännu inte har hela bilden. En delvis uppdatering i tid är värd mer än en fullständig i efterhand.

Där vi agerar personuppgiftsbiträde och får kännedom om en personuppgiftsincident underrättar vi er som personuppgiftsansvariga utan onödigt dröjsmål, så att ni kan uppfylla er egen skyldighet att anmäla till tillsynsmyndigheten inom 72 timmar enligt artikel 33 i GDPR.

Underrättelsen beskriver vad vi vet: incidentens art, kategorierna och den ungefärliga mängden uppgifter som berörs, de sannolika följderna, och de åtgärder som vidtagits eller föreslås. Där vi ännu inte vet något säger vi det i stället för att skjuta upp underrättelsen tills vi gör det.

För en incident som drabbade ert system, ja — ni får en skriftlig redogörelse för vad som hände, varför, och vad som ändrades till följd av det.

Internt registreras incidenter och deras orsaker så att rättningen landar i plattformen snarare än i en operatörs minne. Planerat: att publicera händelserapporter för plattformsövergripande incidenter på statussidan.

Ni. Uppgifter ni lägger in i ert system, och uppgifter systemet skapar, tillhör er organisation. Vi gör inte anspråk på dem, och vi får inga rättigheter till dem genom att behandla dem.

Vi behandlar dem för att driva den tjänst ni betalar för, på era instruktioner. Där personuppgifter är inblandade är ni personuppgiftsansvariga och vi personuppgiftsbiträde.

Nej. Kunduppgifter används inte för att träna modeller, varken våra eller någon annans. Se sidan om ansvarsfull AI för exakt vad som händer med uppgifter som passerar en AI-funktion.

Ja, när som helst, i maskinläsbar form. Ert system kör dessutom på en vanlig databas snarare än en egen lagring, vilket gör exporten till en riktig datamängd i stället för en rapport om en.

Ja. På begäran raderar vi kunduppgifter ur det levande systemet, och de faller ur säkerhetskopiorna i takt med att kopiorna når slutet av sin bevarandetid snarare än plockas bort kirurgiskt ur varje arkiv.

Den bevarandetiden står på integritetssidan tillsammans med raderingsprocessen. Behöver ni en bestämd tidplan för radering av avtalsmässiga eller regulatoriska skäl — säg till, så bekräftar vi skriftligt vad vi kan åta oss.