Platform as a service (PaaS)

NIST SP 800-145 beskriver PaaS som muligheden for at udrulle applikationer, som kunden selv har udviklet eller anskaffet, bygget med sprog, biblioteker, tjenester og værktøjer, som udbyderen understøtter, uden at drive netværk, servere, styresystemer eller lager, men med kontrol over de udrullede applikationer og eventuelt over konfigurationen af driftsmiljøet. Modellen tog form med Heroku (2007), Google App Engine (2008), det oprindelige Windows Azure (2010) og open source-projektet Cloud Foundry (2011). Twelve-factor app-metoden, skrevet hos Heroku omkring 2011, formaliserede kontrakten mellem applikation og platform: konfiguration i miljøvariabler, tilstandsløse processer, der kan smides væk, eksterne tjenester som tilkoblede ressourcer og logs som hændelsesstrømme.

Mekanisk bliver kildekoden omdannet til en kørbar artefakt af buildpacks (i dag standardiseret som Cloud Native Buildpacks, et CNCF-projekt) eller af et container-image, som kunden leverer. Platformen placerer instanser, router HTTP gennem sin egen load balancer, terminerer TLS, skalerer horisontalt efter antal forespørgsler eller CPU og genstarter processer, der går ned. Lokale filsystemer er flygtige, så al tilstand skal ligge i en managed database, cache eller objektlager. Managed datatjenester (DBaaS, køer) er også PaaS, og serverless-funktioner (AWS Lambda fra 2014, Azure Functions, Google Cloud Functions) og serverless containere (Cloud Run) udvider modellen med skalering til nul, afregning pr. kald og forsinkelse ved kolde starter.

Udbyderen patcher styresystem og sprog-runtime, men kun inden for understøttede runtime-versioner; når en runtime når end of support, bliver opgraderingen kundens opgave. Alt, hvad der følger med applikationen, forbliver kundens: tredjepartsafhængigheder fra npm, NuGet eller Maven, logik for autentificering og autorisation, håndtering af input samt hemmeligheder. Hemmeligheder i miljøvariabler kan læses af alle med ret til at se appens konfiguration og lækker let via debug-sider og crash dumps; referencer til en key vault via en managed identity er sikrere. Mange PaaS-tjenester vender som standard ud mod internettet, med private endpoints og integration i virtuelle netværk som tilvalg, og en SSRF-fejl kan nå platformens lokale identitets-endpoint (fx IDENTITY_ENDPOINT i Azure App Service) og hente tokens til appens managed identity.

Prisen er lock-in via proprietære runtimes og API'er, faste platformsgrænser (timeouts på forespørgsler, loft over hukommelse, ingen egne kernemoduler) og mindre indsigt ved revision: agenter kan ikke installeres på værten, så sikkerheden i de nederste lag må dokumenteres via udbyderens SOC 2- eller ISO/IEC 27001-erklæringer. PaaS adskiller sig fra IaaS ved, at kunden ikke længere ejer styresystemet, og fra SaaS ved, at kunden stadig ejer applikationskoden.