Behold kontrollen over appens cloudkonti og platforme

Kontrolplanet er større end selve appen

Appens kontrolplan er de konti og platforme, som kan ændre eller afbryde løsningen. Det omfatter ofte kode, deployment, cloudprojekt, database, domæne, identitet, betalingsmetode, mailudbyder og overvågning. En administrator på dette niveau kan have større praktisk magt end en administrator inde i appen.

Lav et ejerskabsregister uden at gemme adgangskoder

Start med et register over de platforme, der faktisk bruges. Det kan ligge i den interne driftsdokumentation, men skal beskrive adgangsvejen uden at kopiere passwords, recovery-koder eller tokens ind i dokumentet.

• Platform og ressource: Navn, URL, projekt- eller konto-id, miljø og hvad den styrer.
• Virksomhedsejerskab: Organisation, team, tenant eller administreret domæne, som ressourcen ligger under.
• Menneskelig adgang: Navngivne ejere, administratorer, daglige roller og eventuelle eksterne konsulenter.
• Maskinadgang: Pipelines, servicekonti, apps og integrationer, der fortsætter, selv når en person fjernes.
• Gendannelse: Godkendte metoder, opbevaringssted for recovery-materiale og hvem der må bruge det.
• Drift: Betalingsansvar, supportniveau, sikkerhedsvarsler og dato for seneste adgangskontrol.

Flyt ejerskabet til virksomheden

Den konkrete struktur afhænger af platformen. GitHub bruger eksempelvis organisationer, Netlify bruger teams, Microsoft bruger tenants og abonnementer, mens Google Cloud kan samle projekter under en organisation. På Google Cloud betyder organisationens ressourcehierarki, at projekterne tilhører organisationen frem for medarbejderen, der oprettede dem, så de kan blive liggende, når personen fjernes.

1. Kortlæg før flytning: Find afhængigheder, fakturering, loginmetoder, domæneverifikation og integrationer.
2. Opret den rigtige struktur: Brug virksomhedens administrerede identitet, organisation eller team, når platformen understøtter det.
3. Tilføj verificeret adgang: Giv en anden navngiven person den nødvendige rolle, og lad vedkommende logge ind fra egen konto.
4. Kontrollér hele kæden: Udgiv en ufarlig ændring, åbn fakturering, se logs, og bekræft adgang til support og gendannelse.
5. Fjern gammel afhængighed forsigtigt: Nedgradér eller fjern den private eller eksterne ejer, når erstatningen er bevist – ikke før.

Undgå både én flaskehals og for mange superbrugere

Redundans betyder ikke, at alle skal være ejere. GitHub anbefaler mindst to ejere pr. organisationskonto, fordi ressourcerne ellers kan blive utilgængelige, når den eneste ejer ikke kan nås. Netlify tillader flere team-ejere. Andre platforme har andre roller og gendannelsesmodeller, så kontrollen skal tilpasses den faktiske leverandør.

Beskyt login og gendannelse som to forskellige veje

Stærk MFA beskytter kun, hvis virksomheden også kan håndtere en mistet telefon, sikkerhedsnøgle eller password manager. Registrér flere godkendte metoder, hvor platformen tillader det, og opbevar recovery-materiale adskilt fra den daglige enhed. GitHub gør udtrykkeligt opmærksom på, at Support ikke kan gendanne en 2FA-beskyttet konto, hvis alle recovery-metoder er mistet.

• Brug ikke én privat mailboks eller ét privat telefonnummer som eneste vej tilbage.
• Kontrollér at sikkerheds- og betalingsvarsler når en overvåget virksomhedsadresse med en stedfortræder.
• Gem ikke recovery-koder i samme konto, mappe eller enhed, som de skal redde.
• Dokumentér identitetsbevis, kontonumre og supportvej uden at gemme hemmelige autentificeringsdata i runbooken.
• Afprøv login og recovery med en ufarlig øvelse; antag ikke, at gamle oplysninger stadig virker.

Planlæg nødadgang uden en delt hverdagskonto

En nødvej er til situationer, hvor normal identitet eller adminadgang ikke virker. Den bør være adskilt fra daglig drift, stærkt beskyttet, overvåget og testet. Microsofts Entra-vejledning anbefaler specifikt to eller flere cloud-only nødadgangskonti til deres miljø, alternative stærke autentificeringsmetoder, alarm ved brug og jævnlige valideringsøvelser. Den opskrift skal ikke kopieres blindt til andre platforme, men principperne kan bruges til at vurdere deres egne recovery-muligheder.

• Formål: Beskriv præcist hvilken normal afhængighed nødvejen skal overleve.
• Adgang: Beslut hvem der må åbne den, hvordan godkendelsen foregår, og hvor materialet opbevares.
• Alarm: Brug skal skabe en hændelse, som en anden ansvarlig ser og følger op på.
• Øvelse: Verificér login, nødvendige handlinger og logning uden at ændre kritisk produktion.
• Efterkontrol: Gennemgå handlinger, rotér materiale efter behov, og luk midlertidige rettigheder.

Gør fratrædelse til en kontrolleret driftsændring

En person kan være fjernet fra virksomhedens hovedlogin og stadig eje et repository, modtage domænevarsler eller have personlige tokens og aktive sessioner. Offboarding skal derfor følge ressourcekortet og ikke kun medarbejderlisten.

1. Overfør ejerskab, fakturering, domæner, supportsager og varsler til verificerede virksomhedsmodtagere.
2. Kontrollér at mindst én anden godkendt administrator kan udføre de kritiske driftsopgaver.
3. Fjern personens medlemskaber, roller, aktive sessioner, personlige tokens, SSH-nøgler og godkendte enheder.
4. Gennemgå apps, servicekonti, CI/CD og integrationer, som personen oprettede eller alene administrerede.
5. Rotér delte eller kopierede credentials, når der ikke kan bevises en ren individuel afgrænsning.
6. Læs relevante auditlogs og afprøv deployment, alarmer, backup og supportvej efter ændringen.

Typiske fejl

• Virksomhedsmail forveksles med virksomhedsejerskab: Kontoen kan stadig være personlig, uden organisation, ekstra ejer eller dokumenteret recovery.
• Den gamle ejer fjernes for tidligt: Ny adgang er inviteret, men ikke accepteret og afprøvet gennem hele driftskæden.
• Alle bliver ejere: Redundans løses med permanente superbrugere i stedet for afgrænsede roller og en særskilt nødvej.
• Et fælles login bruges hver dag: Handlinger kan ikke knyttes til en person, og MFA eller offboarding bliver skrøbelig.
• Kun mennesker gennemgås: Gamle servicekonti, OAuth-apps, deploynøgler og tokens beholder brede rettigheder.
• Fakturering overses: Den tekniske adgang virker, men betalingskort, fakturaadresse eller budgetvarsler ligger stadig hos en utilgængelig person.
• Nødadgang testes under en rigtig hændelse: Recovery-koden er gammel, sikkerhedsnøglen mangler, eller alarmen når ingen.

Tjekliste: Behold kontrollen

• ☐ GitHub, hosting, cloud, database, domæne, identitet, mail, betaling og overvågning står i ejerskabsregisteret.
• ☐ Hver ressource ligger under en passende virksomhedsorganisation, tenant eller team, hvor platformen understøtter det.
• ☐ Kritiske platforme har dokumenteret redundans, der passer til deres egen rolle- og recovery-model.
• ☐ Hver administrator bruger en navngiven personlig konto med stærk autentificering.
• ☐ Daglig adgang er afgrænset efter opgave, ressource og tidsrum frem for permanent ejeradgang.
• ☐ Recovery-metoder og nødmateriale er adskilt fra den daglige loginvej og kan nås af godkendte personer.
• ☐ Sikkerheds-, drifts- og betalingsvarsler går til overvågede virksomhedsmodtagere.
• ☐ Personer, grupper, apps, servicekonti, tokens og deploynøgler indgår i adgangsgennemgangen.
• ☐ Offboarding omfatter ejerskab, sessioner, tokens, enheder, integrationer, fakturering og varsler.
• ☐ En anden person har afprøvet login, ufarlig deployment, logs, fakturering, support og recovery efter runbooken.
• ☐ Brug af nødadgang udløser en alarm og en efterfølgende gennemgang.
• ☐ Seneste test, fund, ændringer og ansvarlig er dokumenteret uden passwords eller recovery-koder.

Relaterede guides

• Driftsdokumentation og overdragelse
• API-nøgler, secrets og maskinadgang
• Sikkert login, MFA og kontogendannelse i appen
• DNS, domæneejerskab og sikker flytning
• Dataeksport og exit-plan ved leverandørskifte

Officielle kilder

De konkrete platformseksempler er kontrolleret mod aktuelle primærkilder. Roller, recovery og kontostruktur varierer, så brug altid dokumentationen for den tjeneste og kontotype, jeres app faktisk anvender.

• Google Cloud: Ressourcehierarki og virksomhedsejerskab
• Firebase: Administrér projektadgang med IAM
• GitHub Docs: Brug mindst to ejere pr. organisation
• GitHub Docs: Gendan adgang efter tab af 2FA
• GitHub Docs: Gennemgå organisationens auditlog
• Microsoft Learn: Nødadgangskonti i Microsoft Entra
• Microsoft Learn: Mindst mulige administratorrettigheder
• Netlify Docs: Roller og flere team-ejere