Hoppa till huvudinnehållet
FromNine
Meny

Programvara och moln

En molngrund som gör releaser till vardag.

Vi bygger molngrunder och interna utvecklarplattformar där miljöer är kod, releaser är signerade och upprepbara och varje krona i molnkostnad har en ägare.

För svenska företag, koncerner och offentliga aktörer som omfattas av cybersäkerhetslagen eller Dora och vill ha en gemensam molngrund för flera bolag eller verksamheter.

Berätta om ditt projektSe referens­arkitekturen
Moln- och plattforms­utveckling: förmågor i lagerFyra lager staplade på djupet. Uppifrån och ned: produktteamens arbetslaster, den interna utvecklarplattformen, de signerade byggkedjorna och längst ned molngrunden (landing zone) med identitet, nätverk och regler.01Produktteamens arbetslaster02Intern utvecklar­plattform03Signerade byggkedjor04Landing zone och regler
  1. 01Landing zones med regler som kod och var data lagras bestämt per arbetslast
  2. 02Standardvägar som tar en ny tjänst till drift på ett upprepbart sätt
  3. 03Servicenivåmål, testad återställning och kostnad per produkt, synliga för dem som beslutar

01 Problem

Tecken på att grunden håller dig tillbaka

  1. 01

    Varje miljö är unik

    Test och produktion skiljer sig åt på sätt som ingen har skrivit ned, och rättningar som görs för hand i konsolen försvinner vid nästa ombyggnad.

  2. 02

    En release kräver ett möte

    Driftsättningar är sällsynta, manuella och läggs på kvällstid. Teamen samlar ihop ändringar, vilket gör varje release mer riskfylld.

  3. 03

    Molnfakturan överraskar alla

    Kostnaderna syns per prenumeration, inte per produkt. GPU-kapacitet för AI-arbete reserveras av den som frågade först.

  4. 04

    Ingen vet om återställningen fungerar

    Det finns säkerhetskopior. Återläsning har inte testats, och mål för återställningstid och dataförlust har aldrig stämts av med verksamheten.

02 Leveranser

Det här levererar vi

  1. 01 Landing zones och suveräna alternativ

    Struktur för konton och prenumerationer, identitet, nätverk och skyddsräcken hos de stora molnleverantörerna och i europeiska suveräna molntjänster, med regler som kod och var data lagras bestämt per arbetslast.

    Det här gör vi

    • Utformning av organisation, hanteringsgrupper och konton
    • Navnätverk, kontroll av utgående trafik och privat uppkoppling
    • Regler som kod för datalagring, kryptering och märkning
    • Koppling till de säkerhetsintyg som dina kunder och upphandlare efterfrågar

    Det här får du

    • Landing zone som helt definieras i kod
    • Regelbibliotek med process för undantag
    • Underlag om suveräna alternativ per klass av arbetslaster

  2. 02 Infrastruktur som kod och interna utvecklar­plattformar

    Terraform eller OpenTofu och Bicep för infrastrukturen, GitOps för driftsättningar, Kubernetes eller förvaltade körmiljöer där de passar och standardvägar så att ett team kan starta en tjänst som följer reglerna utan att skicka ärenden.

    Det här gör vi

    • Modulbibliotek för infrastruktur som kod
    • GitOps med befordran mellan miljöer
    • Kubernetes-plattform eller förvaltade alternativ
    • Tjänstemallar och en utvecklarportal

    Det här får du

    • Intern utvecklarplattform med standardvägar
    • Miljöer med självservice
    • Färdplan för plattformen som ägs av ett plattformsteam

  3. 03 Byggkedjor och säkerhet i leverantörs­kedjan

    Byggkedjor som bygger en gång, signerar artefakter, registrerar härkomst i linje med SLSA, hanterar hemligheter ordentligt och för samma artefakt från test till produktion.

    Det här gör vi

    • Mallar för byggkedjor med kvalitets- och säkerhetsspärrar
    • Signering av artefakter och intyg om härkomst
    • Hantering av hemligheter och nyckelrotation
    • Regler för befordran och ändringsloggar

    Det här får du

    • Återanvändbara mallar för byggkedjor
    • Signerade artefakter med verifierbar härkomst
    • Underlag från releaser för ändringshanteringen

  4. 04 Observerbarhet och SRE

    Servicenivåmål som avtalas med verksamheten, felbudgetar som styr releasetakten, OpenTelemetry genom hela stacken och en incidentprocess som också klarar rapporteringskraven i cybersäkerhetslagen och Dora där de gäller.

    Det här gör vi

    • Servicenivåmål som definieras med tjänsteägarna
    • Instrumentering med OpenTelemetry och översikter
    • Larm på symtom, inte på orsaker
    • Incidenthantering och genomgångar efter incidenter

    Det här får du

    • Katalog över servicenivåmål
    • Stack och översikter för observerbarhet
    • Rutiner för incidenter och rapportering

  5. 05 FinOps och AI-kapacitet

    Kostnadsfördelning per produkt och team, enhetskostnader som kostnad per transaktion och planering och kostnadskontroll av GPU-kapacitet för AI-arbetslaster.

    Det här gör vi

    • Märkningsregler och fördelningsmodell
    • Enhetskostnader per produkt
    • Planering av åtaganden och reservationer
    • Schemaläggning, kvoter och rätt dimensionering av GPU:er

    Det här får du

    • Kostnadsöversikter per produktägare
    • Lista över besparingar med ägare
    • Kapacitetsplan för AI

  6. 06 Återställning och exit

    Säkerhetskopiering och katastrofåterställning med uttryckliga mål för återställningstid (RTO) och återställningspunkt (RPO), som testas enligt schema, och en exitstrategi som använder rätten att byta leverantör i dataförordningen.

    Det här gör vi

    • RTO och RPO som avtalas per tjänst
    • Tester av återläsning och omkoppling
    • Kartläggning av beroenden för kritiska tjänster
    • Exitplan och kontroller av dataportabilitet

    Det här får du

    • Testade rutiner för återställning
    • Rapporter från återställningstester
    • Dokumenterad exitstrategi

03 Arkitektur

En illustrativ referens­arkitektur

Koden går in till vänster och arbetslaster i drift kommer ut till höger. Däremellan signerar byggkedjan det den bygger, registret lagrar bara signerade artefakter och en GitOps-styrning för dem genom miljöerna enligt reglerna.

Under allt ligger molngrunden: organisationsstruktur, identitet, nätverk, nycklar, återställning och kostnadskontroller, definierade en gång i kod och gemensamma för alla produktteam.

Lager i bilden

Leverans
Kodförråd, byggkedjor, signerade artefakter och befordran med GitOps.
Plattform
Utvecklarplattformen, regler som kod och körmiljön som produktteamen driftsätter till.
Landing zone
Organisation, identitet, nätverk, nycklar, återställning och FinOps-kontroller.
Drift
Telemetri, servicenivåmål, felbudgetar och incidenthantering för allt detta.
Illustrativt exempel

  1. Leverans

    • Kodförråd för kod och IaC
    • Bygga, signera, intyga
    • Register för signerade artefakter
    • Befordran med GitOps

  2. Plattform

    • Utvecklar­plattform och standardvägar
    • Regler som kod
    • Kubernetes och förvaltade tjänster
    • Produktteamens arbetslaster

  3. Landing zone

    • Hanterings­struktur
    • Identitet och åtkomst
    • Navnätverk och utgående trafik
    • Nycklar och hemligheter
    • Säkerhets­kopiering och återställning
    • Kostnads­fördelning

  4. Drift

    • OpenTelemetry, servicenivåmål och felbudgetar, incident­hantering
Signerade leveranser till en regelstyrd landing zone

Illustrativ arkitektur, inte en kunds system.

Läs diagrammet som text

Huvudflödet går från kodförråd för kod och infrastruktur via byggkedjor som bygger, signerar och intygar, till ett artefaktregister, sedan till en GitOps-styrning och till sist till produktteamens arbetslaster.

En intern utvecklarplattform ger standardvägar till byggkedjorna. Regler som kod begränsar GitOps-styrningen. En körplattform med Kubernetes och förvaltade tjänster driver arbetslasterna. Kundhanterade nycklar matar regellagret.

Molngrunden underst omfattar hanteringsstruktur, identitet och åtkomst, ett navnätverk, nycklar, säkerhetskopiering och återställning samt FinOps-kontroller. Observerbarhet med servicenivåmål och incidenthantering omfattar hela plattformen.

04 Överväganden och begränsningar

Tekniska överväganden och begränsningar

  • Suveränitet är en skala

    Så hanterar vi det

    Vi klassar arbetslaster efter känslighet och matchar varje klass mot ett alternativ: EU-regioner hos en stor molnleverantör, en suverän molntjänst eller egen infrastruktur. Avvägningarna i funktioner, kostnad och drift skrivs ned.

    Begränsningar och beroenden

    Suveräna molntjänster ligger ofta efter när det gäller förvaltade tjänster, även för AI. Vissa arbetslaster kostar mer eller kan mindre där, och det är ett verksamhetsbeslut.

  • En plattform behöver en produktägare

    Så hanterar vi det

    Vi behandlar den interna plattformen som en produkt med användare, färdplan och återkoppling, och hjälper dig att sätta upp teamet som driver den.

    Begränsningar och beroenden

    En plattform utan team blir en flaskhals. Om du inte kan bemanna den rekommenderar vi förvaltade tjänster och färre abstraktioner.

  • Regelverk formar driften

    Så hanterar vi det

    Klassning av incidenter, tidsfrister för rapportering och insamling av underlag byggs in i incidentprocessen där cybersäkerhetslagen eller Dora gäller för dig.

    Begränsningar och beroenden

    Bedömningen av om din organisation omfattas, och av vilken tillsynsmyndighet, gör din regelefterlevnadsfunktion och dina jurister.

  • Kostnadskontroll är ett gemensamt ansvar

    Så hanterar vi det

    Vi gör kostnaderna synliga per produkt och lägger till skyddsräcken som budgetar, kvoter och schemalagd avstängning av miljöer som inte används.

    Begränsningar och beroenden

    De största besparingarna kommer oftast från arkitektur- och användningsbeslut som produktägarna fattar, inte från plattformen ensam.

05 Så arbetar vi

Så arbetar vi

Grunden först, sedan ett team på standardvägen och därefter alla andra.

  1. 01

    Bedöm och klassa

    Arbetslaster, datas känslighet, nuvarande kostnader och de kontroller som dina revisorer förväntar sig.

    ResultatKlassning av arbetslaster och alternativ för målbilden

  2. 02

    Bygg molngrunden

    Allt som kod, granskat med säkerhetsfunktionen, med en process för undantag.

    ResultatLanding zone i drift

  3. 03

    Börja med ett pilotteam

    Ett produktteam flyttar till standardvägen; det som skaver för dem formar plattformen.

    ResultatFörsta tjänsten på plattformen

  4. 04

    Skala upp och lämna över

    Fler team ansluter, plattformsteamet tar över ägarskapet och återställning testas enligt schema.

    ResultatFärdplan för plattformen och rapporter från återställningstester

06 Mänsklig kontroll

Där människor behåller kontrollen

Automatiseringen driver plattformen. Människor äger de beslut som innebär risk eller kostnad.

  • Ändringar i produktion är spårbara

    Varje ändring i produktion kommer från en granskad incheckning, så det finns alltid uppgift om vem som ändrade vad och vem som godkände det.

  • Nödåtkomst är sällsynt och loggas

    Nödåtkomst är tidsbegränsad, kräver motivering och granskas i efterhand.

  • Undantag från reglerna har en ägare

    När en arbetslast behöver ett undantag från ett skyddsräcke godkänner en namngiven riskägare det, med ett slutdatum.

  • Tjänsteägarna sätter målen

    Mål för återställning och servicenivåer avtalas med verksamhetsägaren för varje tjänst och sätts inte av plattformsteamet ensamt.

07 Tekniker

Tekniker vi arbetar med

Moln
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Europeiska suveräna molntjänster
Infrastruktur och leverans
  • Terraform och OpenTofu
  • Bicep
  • Argo CD och Flux
  • GitHub Actions, GitLab CI och Azure DevOps
Körmiljö
  • Kubernetes och förvaltade varianter
  • Serverlösa plattformar och containerplattformar
  • Service mesh där det lönar sig
  • GPU-nodpooler för AI-arbetslaster
Drift
  • OpenTelemetry
  • Prometheus och Grafana
  • Molnleverantörernas egen övervakning
  • Regelmotorer som OPA

Att vi listar en teknik beskriver vår tekniska erfarenhet. Det innebär inte ett partnerskap med leverantören eller att leverantören står bakom oss.

08 Exempel

Ett illustrativt exempel

Illustrativt exempel

En gemensam molngrund för en kommunal koncern med energi och VA

01Utgångsläge
En kommunal koncern har ett elnätsföretag, ett fjärrvärmebolag och ett VA-bolag med var sin molnmiljö och olika säkerhetskontroller. Bolagen omfattas av cybersäkerhetslagen inom olika sektorer, med Statens energimyndighet och Livsmedelsverket som tillsynsmyndigheter, och ingen kan visa koncernens säkerhetsläge i en samlad bild.
02Det här skulle vi bygga
En molngrund i kod med regeluppsättningar per bolag, gemensam loggning och en incidentprocess som klassar incidenter och tar fram underlag för rapportering till CSIRT-enheten vid FRA.
03Här beslutar människor
Säkerhetsansvarig i varje bolag godkänner undantag från reglerna för bolagets arbetslaster; koncernens säkerhetschef äger den gemensamma grundnivån.
04Det här skulle vi mäta
Tid från upptäckt incident till klassning, andel arbetslaster som omfattas av reglerna och antal godkända återställningstester per kvartal.

09 Branscher

I din bransch

  • Offentlig sektor

    Alternativ för var data lagras per informationsklass, de säkerhetsintyg som efterfrågas och exitplaner som håller vid nästa upphandling enligt LOU.

  • Finansiella tjänster

    Operativ motståndskraft enligt Dora, med Finansinspektionen som behörig myndighet: testad återställning, kontroll över IKT-tredjepartsleverantörer och incidentrapportering inbyggd i driften.

Sverige

Underlag en gång, för varje tillsyns­myndighet

Cybersäkerhetslagen (2025:1506) genomför NIS 2-direktivet i Sverige och har gällt sedan den 15 januari 2026. Tillsynen är sektorsvis: Statens energimyndighet för energi, Livsmedelsverket för dricksvatten och avloppsvatten, Transportstyrelsen för transport och sex länsstyrelser för den offentliga förvaltningen. Föreskrifterna om säkerhetsåtgärder gäller sedan den 1 oktober 2026, och incidenter rapporteras till CSIRT-enheten vid FRA. För banker och andra finansiella företag gäller dessutom Dora, med Finansinspektionen som behörig myndighet.

Vi utformar molngrunder där var data lagras, loggning och klassning av incidenter är regler och inte projekt, så att ett nytt bolag eller en ny verksamhet ansluts genom konfiguration. Exitplanerna bygger på rätten att byta leverantör enligt dataförordningen och testas, de skrivs inte bara.

Frågor om moln- och plattforms­utveckling

Vilken molnleverantör rekommenderar ni?

Den som passar dina arbetslaster, dina befintliga avtal och dina krav på suveränitet. Vi arbetar med de stora molnleverantörerna och med europeiska suveräna alternativ, och vi dokumenterar avvägningarna så att valet går att försvara i en upphandling och kan omprövas senare.

Behöver vi Kubernetes?

Inte alltid. Kubernetes lönar sig när du kör många tjänster och har ett team som driver plattformen. För ett fåtal tjänster är förvaltade container- eller serverlösa plattformar ofta enklare och billigare att driva.

Hur arbetar ni med säkerhet?

Säkerheten byggs in i molngrunden och byggkedjorna: identiteter med minsta behörighet, regler som kod, signerade artefakter och hemligheter som aldrig ligger i koden. FromNine är själva certifierade enligt ISO/IEC 27001 för ledningssystem för informationssäkerhet.

Kan ni sänka våra molnkostnader?

Oftast ja, men vi lovar ingen procentsats innan vi har sett datan. Vi börjar med att göra kostnaderna synliga per produkt och arbetar sedan igenom en lista över besparingar med de ägare som kan genomföra dem.

Hur undviker vi inlåsning?

Genom att medvetet välja var du blir beroende av leverantörsspecifika tjänster, hålla infrastrukturen i kod och ha en dokumenterad och testad exitplan. Dataförordningen stärker din rätt att byta leverantör; en exitplan gör att rätten går att använda.

Visa oss dina tre nästa releaser

Vi berättar vad som skulle göra dem till vardag och vad den grunden skulle kosta att bygga och driva.

Berätta om ditt projektLäs om arkitektur