GCP Security Command Center Guide 2026: 14 Steg

En felkonfigurerad Cloud Storage-bucket eller ett för brett IAM-tillstånd räcker för att öppna dörren till en hel GCP-organisation. Under augusti 2026 rullade Google ut flera nya funktioner i Security Command Center, plattformen som ska fånga just den typen av fel innan någon annan gör det. Den här guiden går igenom hur du aktiverar verktyget, kör din första skanning och bygger en rutin som håller nordiska molnmiljöer rena från felkonfigurationer.

Du får 14 konkreta steg, åtta kodblock du kan kopiera rakt av och ett komplett automatiseringsprojekt i slutet. Vi utgår från ett vanligt scenario: ett svenskt team med flera GCP-projekt under en gemensam organisation, som vill ha kontinuerlig koll på sårbarheter, öppna brandväggsregler och AI-arbetslaster utan att betala för funktioner de inte behöver.

Bakgrunden är enkel. Molnmiljöer växer snabbare än de flesta säkerhetsteam hinner granska manuellt, och GCP är inget undantag. Ett projekt som skapades för ett proof of concept för sex månader sedan kan fortfarande ha kvar en öppen brandväggsregel eller en tjänst med för höga rättigheter, helt enkelt för att ingen har haft anledning att titta på det igen. Den typen av glömda resurser är exakt det Security Command Center är byggt för att fånga, oavsett om du kör ett enda projekt eller en hel koncernstruktur med dotterbolag i Sverige, Norge och Danmark.

Vad är Security Command Center och varför behöver du det

Security Command Center (SCC) är Googles centrala plattform för sårbarhets- och hotrapportering på organisations- och projektnivå. Dokumentationen uppdaterades senast i början av augusti 2026, vilket visar att Google fortsätter bygga ut plattformen aktivt snarare än att låta den stå still. SCC samlar in fynd från flera källor, från felkonfigurerade resurser till skadlig aktivitet i drifttid, och visar allt i ett gemensamt gränssnitt.

Skillnaden mot att bara läsa loggar manuellt är att SCC prioriterar fynden åt dig. I stället för tusentals rader i Cloud Logging får du en lista sorterad efter allvarlighetsgrad, med förslag på åtgärd. Det gör verktyget till en naturlig utgångspunkt oavsett om du redan kör molnsäkerhetsskanning i AWS med Prowler eller har härdat IAM och lagring i Azure och nu vill matcha samma nivå i Google Cloud.

Rent tekniskt bygger SCC på Cloud Asset Inventory, som håller en löpande katalog över varenda resurs i din organisation, från VM-instanser till IAM-bindningar. Ovanpå den katalogen körs flera detektionstjänster parallellt. Security Health Analytics jämför konfiguration mot kända bästa praxis-regler. Event Threat Detection letar efter misstänkta mönster i loggar, till exempel ovanliga inloggningsförsök eller plötsliga behörighetsändringar. Container Threat Detection bevakar körningstid i GKE. Genom att kombinera flera detektionslager i samma plattform slipper du sy ihop resultat från olika verktyg för att få en helhetsbild, vilket annars är ett vanligt problem när säkerhetsteam använder separata punktlösningar för varje molntjänst.

Två nyheter från sommaren 2026 gör SCC särskilt relevant just nu. Den 10 augusti 2026 gick “Vulnerability Assessment for Google Cloud” i allmän tillgänglighet (GA), vilket ger automatisk sårbarhetsbedömning av dina GCP-resurser. Samma månad blev integrationen mellan SCC och Application Design Center allmänt tillgänglig, så att designtidsfynd kan skickas till SCC redan innan en tjänst är driftsatt.

Tänk dig ett vanligt scenario på ett medelstort svenskt techbolag. Utvecklingsteamet kör tre GCP-projekt: ett för produktion, ett för staging och ett för interna verktyg. Ingen i teamet har heltid avsatt för säkerhet, utan ansvaret delas mellan en plattformsingenjör och en säkerhetsansvarig som också hanterar Azure och lokala servrar. I det läget blir en verktygslåda som kräver konstant manuell tillsyn opraktisk. Poängen med SCC är att den löpande övervakningen sker i bakgrunden, och att teamet bara behöver agera när något faktiskt kräver ett beslut.

Förutsättningar innan du börjar

Du behöver inte vara molnarkitekt för att följa den här guiden, men några saker måste finnas på plats. Tabellen nedan listar verktyg, behörigheter och versioner du bör ha innan du går vidare till steg ett.

Krav	Version eller nivå	Varför du behöver det
Google Cloud-organisation	Aktiv fakturering kopplad	SCC på organisationsnivå kräver en Cloud Identity- eller Workspace-organisation, inte bara ett enskilt projekt
gcloud CLI	Senaste versionen av Google Cloud SDK	Kör aktivering, skanningar och API-anrop från terminalen
IAM-roll	Security Center Admin Editor (organisationsnivå)	Krävs för att aktivera SCC och konfigurera detektorer
Python	3.11 eller senare	Används i automatiseringsskripten längre ner i guiden
Terraform (valfritt)	Senaste versionen med google-providern	För att versionshantera aktiveringen som infrastruktur som kod
Ett testprojekt	Separat från produktion	Så att du kan testa detektorer och alarmregler utan att störa drift

Räkna med att hela guiden, från aktivering till en fungerande automatiserad rapport, tar ungefär 90 minuter om du redan har ett GCP-konto. Lägg till ytterligare 30 minuter om du behöver skapa organisationsstrukturen från grunden.

Steg 1-2: Skapa testprojekt och aktivera nödvändiga API:er

Börja i ett isolerat testprojekt. Det gör att du kan experimentera med detektorer och trösklar utan risk för produktionsmiljön. Sätt projektet och slå på de API:er som SCC bygger på.

gcloud config set project scc-test-nordics

gcloud services enable \
  securitycenter.googleapis.com \
  cloudasset.googleapis.com \
  cloudresourcemanager.googleapis.com \
  container.googleapis.com

gcloud services list --enabled --filter="name:securitycenter"

Om det sista kommandot inte returnerar någon rad har aktiveringen inte gått igenom, oftast för att kontot saknar rätt IAM-roll eller för att faktureringen inte är kopplad till projektet. Kontrollera bägge delarna innan du fortsätter till nästa steg.

Varför ett separat testprojekt över huvud taget? Den vanligaste nybörjarfällan är att aktivera SCC direkt i produktionsmiljön och sedan bli överraskad av mängden fynd som dyker upp första dagen. Ett moget GCP-projekt som har byggts upp under flera år brukar ha samlat på sig dussintals mindre avvikelser, från gamla brandväggsregler till tjänstekonton som ingen längre använder. Genom att först testa i en isolerad miljö hinner du lära dig gränssnittet, förstå vilka detektorer som ger mest värde för just er verksamhet, och bygga triagerutinen innan den behöver hantera skarpa fynd.

Steg 3-4: Aktivera Security Command Center på organisationsnivå

Med API:erna aktiverade kan du slå på SCC för hela organisationen. Byt ut ORGANIZATION_ID mot ditt eget organisations-ID, som du hittar med gcloud organizations list.

ORG_ID=$(gcloud organizations list --format="value(name)" | sed 's|organizations/||')

gcloud scc settings services enable \
  --organization=$ORG_ID \
  --service=SECURITY_HEALTH_ANALYTICS

gcloud scc settings services describe \
  --organization=$ORG_ID \
  --service=SECURITY_HEALTH_ANALYTICS

Security Health Analytics är motorn som letar efter klassiska felkonfigurationer: öppna brandväggsregler, publika buckets, saknad kryptering och överdrivet breda IAM-roller. Aktiveringen tar några minuter innan de första fynden börjar dyka upp i konsolen under Security & compliance-fliken i Cloud Hub, där SCC-insikter numera visas direkt utan att du behöver öppna ett separat gränssnitt.

Det är värt att skilja på två typer av aktivering här. Att slå på tjänsten SECURITY_HEALTH_ANALYTICS ger dig löpande, passiv övervakning som körs automatiskt i bakgrunden utan att du behöver göra något mer. Det är den delen de flesta team vill ha igång permanent. Andra detektorer, som djupare Event Threat Detection-regler, kan behöva konfigureras separat beroende på vilken servicenivå organisationen ligger på. Ett bra riktmärke är att börja med grunddetektorerna aktiverade överallt, och sedan lägga till fler specialiserade regler i takt med att teamet lär sig vilka fynd som faktiskt är relevanta för just er miljö.

Steg 5-6: Välj rätt servicenivå för din organisation

Security Command Center är sedan sommaren 2026 uppdelat i tre tydliga nivåer: Standard, Premium och Enterprise. Den offentliga funktionsbeskrivningen uppdaterades den 26 augusti 2026, och skillnaderna märks särskilt när det gäller AI-skydd och djupare detektion. Standard är kostnadsfri och passar mindre team som vill ha grundläggande skydd. Premium faktureras löpande utifrån resursanvändning och lägger till bredare sårbarhetsskanning. Enterprise kräver en prenumeration och riktar sig mot organisationer med krav på fullständig hot- och riskhantering över flera moln.

Nivå	Prismodell	Vad du får
Standard	Kostnadsfri	Grundläggande felkonfigurationsdetektering, AI Protection-baslinje på projekt- och organisationsnivå
Premium	Löpande, pay-as-you-go	Bredare sårbarhetsskanning, Vulnerability Assessment för fler resurstyper, utökade detektorer
Enterprise	Prenumeration	Fullständig hothantering, djupare integration med Application Design Center, stöd för hybrid- och multimolnsmiljöer

För de flesta svenska team räcker Standard som startpunkt. Det som gör Standard-nivån intressant 2026 är att AI Protection numera ingår redan där, vilket ger en dedikerad AI-säkerhetsdashboard, en inventering av AI-resurser och baslinjefynd utan extra kostnad. Vill du senare skala upp kan du växla nivå utan att bygga om själva integrationen, eftersom API:et är detsamma oavsett tier.

Ett mindre team på fem till tio utvecklare klarar sig ofta gott och väl på Standard under det första året, särskilt om molnmiljön i huvudsak består av standardtjänster som Compute Engine, Cloud Storage och Cloud SQL. Ett större team med egen plattformsorganisation, flera regioner och krav på kontinuerlig sårbarhetsscanning av containerimages bör räkna med att växla till Premium relativt snart, eftersom Vulnerability Assessment i den bredare formen kräver den nivån för full täckning av alla resurstyper. Enterprise blir sällan aktuellt förrän organisationen redan har en etablerad säkerhetsfunktion som ska koppla samman GCP med andra moln och lokala system i en gemensam riskbild.

Steg 7-8: Kör din första Vulnerability Assessment

Med grunden på plats är det dags att köra en faktisk sårbarhetsbedömning. Funktionen gick i allmän tillgänglighet den 10 augusti 2026 och identifierar kända sårbarheter och felkonfigurationer i dina GCP-resurser, med syftet att stödja riskbedömning och prioritering av åtgärder snarare än att bara lista problem utan sammanhang.

gcloud scc findings list $ORG_ID \
  --filter="state=\"ACTIVE\" AND severity=\"HIGH\" OR severity=\"CRITICAL\"" \
  --format="table(finding.category, finding.severity, finding.resourceName)"

Kör kommandot direkt efter aktivering och du ser sannolikt en tom lista, eller ett fåtal fynd relaterade till standardkonfigurationer. Det är normalt. Full skanning av en organisation med flera projekt tar vanligen några timmar innan Security Health Analytics har hunnit gå igenom alla resurser. Kom tillbaka och kör samma kommando igen senare samma dag för en mer rättvisande bild.

Ett vanligt första fynd i svenska miljöer är brandväggsregler som tillåter inkommande trafik från 0.0.0.0/0 på port 22 eller 3389, ofta kvarlämnade från tidiga testmiljöer. Ett annat är Cloud Storage-buckets med publik läsbehörighet, vanligen ett misstag från när någon behövde dela en fil snabbt och glömde stänga behörigheten igen.

Så tolkar du fynd och sätter rätt prioritet

En lista med fynd är värdelös om ingen vet vad som ska göras med den. SCC sorterar varje fynd efter allvarlighetsgrad i fyra nivåer: Low, Medium, High och Critical. Critical betyder oftast en direkt exponerad resurs, som en databas med publik åtkomst eller ett tjänstekonto med ägarrättigheter på organisationsnivå. High täcker saker som brett öppna brandväggsregler utan direkt extern exponering just nu, men med tydlig risk om nätverket ändras. Medium och Low är i regel avvikelser från bästa praxis som bör åtgärdas, men sällan akuta.

Bygg en enkel triageregel för teamet: Critical-fynd ska åtgärdas eller ha en dokumenterad riskacceptans inom 24 timmar, High inom en vecka, och Medium/Low samlas in i en backlog som gås igenom varannan sprint. Utan den typen av tidsgräns tenderar fynd att samlas på hög utan att någon känner ägarskap, särskilt i organisationer där flera team delar på samma GCP-organisation.

En sak som ofta förvånar team som är nya med SCC är hur många fynd som handlar om identitet snarare än nätverk. Öppna brandväggsregler får mest uppmärksamhet eftersom de är lätta att förstå, men i praktiken är överdrivet breda IAM-roller minst lika vanliga, och ofta svårare att upptäcka utan ett verktyg som SCC. Ett tjänstekonto som fick rollen Editor för tre år sedan, för att spara tid under en deadline, blir sällan nedgraderat i efterhand om ingen aktivt letar efter det. Just den typen av tyst behörighetskrypning är precis vad Security Health Analytics är bra på att fånga upp löpande.

Varje fynd innehåller också en kategori, till exempel PUBLIC_BUCKET_ACL, OPEN_FIREWALL eller OVER_PRIVILEGED_SERVICE_ACCOUNT. Filtrera på kategori när du vill hantera en hel klass av problem på en gång i stället för att gå igenom fynd ett i taget. Ett team som upptäcker tio öppna brandväggsregler löser sällan problemet effektivt genom att stänga dem manuellt en och en. Bättre är att gå till roten, oftast en delad Terraform-modul eller ett gammalt skript som fortfarande används för att skapa nya nätverksregler med för öppen standardkonfiguration.

Steg 9-10: Fånga fel redan i designfasen med Application Design Center

Den mest praktiska nyheten från augusti 2026 är integrationen mellan SCC och Application Design Center, som nu är allmänt tillgänglig. Den gör att designtidsfynd kan skickas till SCC on-demand under driftsättning, alltså innan en tjänst ens är live. Det är samma tanke som ligger bakom att bygga in SBOM och leveranskedjesäkerhet tidigt i utvecklingsflödet i stället för att granska allt i efterhand.

Integrationen gör det också möjligt att filtrera säkerhetsfynd per App Hub-applikation, både på app-aktiverade mappar och enskilda projekt. För en organisation med tio eller tjugo mikrotjänster spridda över flera team är det stor skillnad mot att gräva igenom en enda lång fyndlista. Aktivera kopplingen genom att registrera din applikation i App Hub och sedan länka den till din SCC-instans:

gcloud app-hub applications create nordics-app \
  --location=europe-north2 \
  --scope=organization \
  --display-name="Nordics Production App"

gcloud scc settings describe --organization=$ORG_ID \
  --format="value(applicationDesignCenterIntegration)"

När kopplingen är aktiv kan utvecklare se säkerhetsfynd direkt i designverktyget, innan koden ens når produktion. Det flyttar ansvaret uppströms och minskar antalet fynd som SCC behöver fånga i efterhand.

Den här typen av skift-vänster-arbete brukar möta motstånd i praktiken, oftast för att utvecklare upplever ytterligare ett verktyg som en broms i leveranstakten. Ramar ni in det rätt blir effekten den motsatta: ett fel som upptäcks i designfasen kostar i regel en ändring i ett konfigurationsfilter, medan samma fel upptäckt i produktion kan kräva en akut driftsättning, ett incidentmöte och en förklaring till ledningen. Visa gärna det konkreta exemplet för teamet, snarare än att bara argumentera principiellt för säkerhetens värde, eftersom en tydlig kostnadsjämförelse brukar övertyga bättre än ett allmänt resonemang.

Steg 11-12: Skydda AI-arbetslaster med AI Protection

I takt med att fler team kör agentbaserade AI-tjänster i GKE, Cloud Run och Agent Platform, växer också risken för nya typer av angrepp. I början av augusti 2026 introducerade Google nya detektorer för “Malicious Skill”, riktade mot just den typen av arbetslaster. Detektorerna använder Google Threat Intelligence som källa och slår larm när en AI-agent laddar eller kör en binär som är märkt som en skadlig “LLM-skill”. Konceptet påminner om hur du redan härdar ett Kubernetes-kluster mot körningstidshot, men riktar in sig specifikt på agentens plugin-lager i stället för klassisk container-runtime.

Aktivera AI Protection separat från Security Health Analytics, eftersom det är en egen tjänst med egen inventering:

gcloud scc settings services enable \
  --organization=$ORG_ID \
  --service=AI_PROTECTION

gcloud scc findings list $ORG_ID \
  --filter="category=\"MALICIOUS_SKILL_DETECTED\"" \
  --format="table(finding.eventTime, finding.resourceName, finding.severity)"

Notera att AI Protection under augusti 2026 även fick stöd för dataresidens i Saudiarabien för samtliga servicenivåer, vilket visar att Google aktivt bygger ut regional täckning. För nordiska organisationer med krav på att data stannar inom EU/EES är det värt att dubbelkolla regionsinställningarna innan du rullar ut AI Protection brett, eftersom fel region kan bryta mot interna dataskyddskrav trots att själva säkerhetsfunktionen fungerar korrekt.

Varför är AI-agenter en egen riskkategori i första hand? En klassisk applikation kör kod som en utvecklare har skrivit och granskat. En agentbaserad tjänst kan i stället hämta och köra “skills”, alltså paketerade funktioner eller plugin, som den väljer själv utifrån en uppgift. Det öppnar för en ny typ av leveranskedjerisk: om en skadlig aktör lyckas få in en förgiftad skill i ett bibliotek som agenten litar på, kan den binären köras med samma behörigheter som resten av tjänsten, ofta utan att en människa någonsin granskat koden i förväg. Malicious Skill-detektorerna är Googles svar på just det scenariot, och de blir mer relevanta för varje månad som fler svenska bolag flyttar produktionsnära arbetsflöden till agentbaserade tjänster i GKE och Cloud Run.

Steg 13-14: Automatisera rapportering med Cloud Scheduler och Python

Manuella kontroller glöms bort. Någon är på semester, ett annat brandsläckningsärende tar över veckan, eller så byts helt enkelt personen som brukade komma ihåg att logga in i konsolen varje måndag. Bygg i stället en liten automatisering som hämtar kritiska fynd varje morgon och skickar dem till ett Slack-flöde eller en e-postlista, så att rutinen inte är beroende av att en specifik person minns den. Skriptet nedan använder Security Command Center-klienten för Python och kan köras som en Cloud Function.

from google.cloud import securitycenter

def hamta_kritiska_fynd(organization_id: str) -> list:
    client = securitycenter.SecurityCenterClient()
    parent = f"organizations/{organization_id}/sources/-"
    request = {
        "parent": parent,
        "filter": 'state="ACTIVE" AND severity="CRITICAL"',
    }
    fynd = []
    for result in client.list_findings(request=request):
        fynd.append({
            "kategori": result.finding.category,
            "resurs": result.finding.resource_name,
            "tid": result.finding.event_time.isoformat(),
        })
    return fynd

if __name__ == "__main__":
    for f in hamta_kritiska_fynd("123456789012"):
        print(f["kategori"], "-", f["resurs"])

Schemalägg körningen med Cloud Scheduler så att rapporten skickas automatiskt varje vardagsmorgon:

gcloud scheduler jobs create http scc-daglig-rapport \
  --location=europe-north2 \
  --schedule="0 7 * * 1-5" \
  --uri="https://europe-north2-scc-test-nordics.cloudfunctions.net/hamta_kritiska_fynd" \
  --http-method=POST \
  --oidc-service-account-email=scc-scheduler@scc-test-nordics.iam.gserviceaccount.com

Med det på plats behöver ingen längre logga in i konsolen manuellt för att se om något kritiskt har dykt upp under natten. Samma mönster går att återanvända för daglig bevakning av kända utnyttjade sårbarheter, bara med en annan datakälla.

Det kompletta arbetsflödet: från scan till åtgärd

Ett fungerande skanningsprojekt är mer än ett enda skript. Det är en kedja av beslut som förstärker varandra: rätt aktivering ger rätt data, rätt data gör triagen meningsfull, och en fungerande triage gör att automatiseringen faktiskt levererar värde i stället för att bara generera fler mejl som ingen läser. Nedan är hela flödet du precis byggt, sammanfattat i sex delar som hänger ihop:

Aktivering: API:er, IAM-roll och organisationsomfattande SCC-inställning
Grunddetektion: Security Health Analytics letar löpande efter klassiska felkonfigurationer
Djupanalys: Vulnerability Assessment kör riktade sårbarhetskontroller mot resurser
Skift-vänster: Application Design Center fångar fel innan driftsättning
AI-skydd: AI Protection och Malicious Skill-detektorer bevakar agentbaserade tjänster
Automatisering: Cloud Scheduler och ett Python-skript levererar dagliga rapporter utan manuellt arbete

Vill du versionshantera hela aktiveringen som infrastruktur som kod, i stället för att köra gcloud-kommandon manuellt varje gång du sätter upp ett nytt projekt, gör Terraform det enkelt att återanvända konfigurationen:

resource "google_scc_source" "nordics_source" {
  organization = var.organization_id
  display_name = "Nordics Custom Findings"
  description  = "Egna fynd fran interna kontroller"
}

resource "google_project_service" "securitycenter" {
  project = var.project_id
  service = "securitycenter.googleapis.com"
}

Lägg det i samma repo som resten av din molninfrastruktur, så aktiveras SCC automatiskt varje gång ett nytt projekt skapas via din pipeline i stället för att bero på att någon kommer ihåg att göra det manuellt.

Innan ni rullar ut det här flödet till produktion, testa hela kedjan från fynd till notis i testprojektet. Skapa medvetet en felaktig brandväggsregel eller en publik bucket, och verifiera att den dyker upp i nästa gcloud scc findings list, att Cloud Scheduler-jobbet faktiskt triggar, och att meddelandet når rätt kanal. Det är betydligt bättre att upptäcka ett trasigt notissteg i en testmiljö än att upptäcka det den dag ett riktigt kritiskt fynd tyst faller bort för att en behörighet saknades.

Vanliga fallgropar när du bygger en skanningsrutin

De flesta problem med SCC handlar inte om verktyget i sig utan om hur det rullas ut. Här är de misstag vi ser oftast, oavsett om organisationen är ett litet startup-team eller en etablerad koncern med flera dotterbolag.

Aktivering bara på projektnivå. Utan organisationsomfattande aktivering missar du nya projekt som skapas efteråt, och varje team måste konfigurera sitt eget skydd från noll.
För bred IAM-roll till skanningskontot. Ge tjänstekontot som kör automatiseringen läsrättigheter till fynd, inte fulla ägarrättigheter till hela organisationen.
Ingen triageprocess. Ett verktyg som spottar ut hundratals fynd utan att någon äger uppföljningen blir bara brus som folk lär sig ignorera.
Blandar ihop Standard och Premium-funktioner. Vulnerability Assessment kräver rätt nivå för full täckning. Testa alltid i din faktiska tier, inte bara i dokumentationen.
Glömmer testmiljön. Detektorer som är för känsliga i produktion upptäcks bäst i ett testprojekt innan de stör verkliga incidentflöden.
Ignorerar dataresidens för AI Protection. Regioninställningar påverkar var fyndens metadata lagras, vilket spelar roll för organisationer med interna dataskyddskrav.
Ingen tydlig ägare per fyndkategori. När ansvaret för nätverk, IAM och lagring ligger hos olika personer utan en gemensam lista över vem som äger vad, hamnar fynd ofta i limbo mellan teamen tills någon råkar snubbla över dem av misstag.

Felsökning: vanliga problem och lösningar

Stöter du på fel under uppsättningen är det oftast något av följande som ligger bakom. Ett bra sätt att felsöka systematiskt är att gå igenom kedjan i ordning: börja med att bekräfta att rätt API:er är aktiverade, kontrollera sedan IAM-rollerna på både användar- och tjänstekontonivå, och verifiera till sist att själva tjänsten (Security Health Analytics, Vulnerability Assessment eller AI Protection) faktiskt är påslagen för rätt omfattning, alltså organisation eller projekt. De flesta fel i praktiken visar sig vara en kombination av två av dessa tre saker snarare än ett enda uppenbart fel.

Problem	Trolig orsak	Lösning
“PERMISSION_DENIED” vid aktivering	Kontot saknar rollen Security Center Admin Editor	Tilldela rollen på organisationsnivå, inte bara projektnivå
Inga fynd visas alls efter en timme	Security Health Analytics har inte hunnit skanna klart	Vänta upp till 24 timmar för första fullständiga genomsökning
“API not enabled”-fel	securitycenter.googleapis.com är inte aktiverat i projektet	Kör gcloud services enable på nytt och verifiera med services list
AI Protection visar tom inventering	Tjänsten är aktiverad men inga AI-resurser är taggade korrekt	Kontrollera att GKE- och Cloud Run-tjänster kör i regioner som stöds
Cloud Scheduler-jobbet misslyckas tyst	Fel behörighet på tjänstekontot för OIDC-autentisering	Ge kontot rollen Cloud Functions Invoker på målfunktionen
App Hub-integrationen visar inga fynd per app	Applikationen är inte korrekt registrerad i App Hub	Kör app-hub applications describe för att verifiera registreringen
För många lågprioriterade fynd dränker kritiska	Standardfiltret visar alla allvarlighetsgrader	Filtrera explicit på severity=”CRITICAL” eller “HIGH” i alla frågor
Terraform-planen vill återskapa SCC-källan varje gång	State-filen matchar inte den faktiska resursen i GCP	Importera resursen med terraform import innan nästa apply

Avancerade tips för nordiska molnteam

När grundflödet fungerar finns det ett par knep som gör skillnad i praktiken. Sätt upp en dedikerad mapp per land eller dotterbolag i din organisationsstruktur, och koppla SCC-fynd till respektive mapp i stället för att blanda allt i en gemensam vy. Det gör det lättare att visa efterlevnad separat för svenska, norska och danska enheter vid en revision, och det gör det möjligt att sätta olika säkerhetströsklar för en produktionsmapp jämfört med en mapp för sandlådor och experiment.

Använd egna moduler i Security Health Analytics för att lägga till kontroller som är specifika för er verksamhet, till exempel regler som flaggar resurser utan rätt kostnadsställe-tagg. Standarddetektorerna täcker det mesta av klassiska felkonfigurationer, men interna policyer kräver ofta egna regler ovanpå det.

Håll koll på larmutmattning från dag ett. Ett vanligt mönster är att teamet är entusiastiskt de första veckorna, går igenom varje fynd noggrant, och sedan tappar tempo när fyndlistan växer snabbare än kapaciteten att åtgärda den. Sätt hellre en realistisk budget, till exempel att teamet hanterar fem Critical- och High-fynd per vecka som en fast rutin, än att försöka nolla ut hela listan på en gång och sedan ge upp helt efter en månad. En stadig, förutsägbar takt slår ett intensivt men kortlivat försök varje gång.

Slutligen, dokumentera varje undantag. Ibland finns det goda skäl till att en resurs bryter mot en standardregel, till exempel en lastbalanserare som medvetet exponeras publikt. I de fallen, markera fyndet som “muted” i SCC med en tydlig motivering kopplad till en ägare och ett datum för nästa granskning, i stället för att bara ignorera det tyst. Om undantaget aldrig dokumenteras riskerar nästa person som granskar miljön att missa att exponeringen är avsiktlig, eller ännu värre, anta att allt odokumenterat är säkert eftersom det redan legat kvar länge.

Koppla slutligen SCC-fynden till ert befintliga ärendehanteringssystem via Pub/Sub-exporten, så att kritiska fynd automatiskt skapar ett ärende i stället för att bara synas i konsolen. Det minskar risken att ett fynd fastnar mellan stolarna när flera team delar på ansvaret för molnsäkerhet.

Koppling till NIS2 och styrelsens rapporteringskrav

För svenska organisationer som omfattas av NIS2 är löpande sårbarhetshantering inte bara god praxis, det är ett krav som ska kunna dokumenteras. En daglig SCC-rapport med tidsstämplade fynd, tillsammans med en triagelogg som visar när och hur varje Critical-fynd åtgärdades, blir ett konkret underlag att visa upp om en tillsynsmyndighet frågar. Har ni redan en incidentplan enligt NIS2, är det naturligt att koppla SCC:s automatiska rapportering direkt till den planen, så att ett kritiskt fynd i molnet triggar samma eskaleringskedja som en klassisk säkerhetsincident.

Ett konkret exempel: om AI Protection flaggar en Malicious Skill-detektion i en produktionsmiljö bör det räknas som en säkerhetshändelse enligt samma definition som styr resten av er incidenthantering, inte som en separat molnnotis som bara IT-driften ser. Genom att exportera SCC-fynd till samma system som resten av organisationen använder för incidentspårning slipper ni bygga upp parallella rapporteringsvägar som riskerar att glömmas bort vid en revision.

NIS2 ställer också krav på att organisationer kan visa att de har processer för riskhantering i leverantörskedjan, vilket inkluderar molnleverantörer. Att kunna peka på en dokumenterad, automatiserad skanningsrutin i GCP, med tydliga tidsgränser för åtgärd och en logg över historiska fynd, är ett konkret sätt att visa att kravet är uppfyllt i praktiken snarare än bara på papper.

Styrelser och ledningsgrupper som vill ha en snabb lägesbild kan använda samma Security & compliance-vy i Cloud Hub som nämndes tidigare. Den ger en sammanfattning utan att någon behöver öppna själva SCC-konsolen, vilket gör det enklare att inkludera molnsäkerhetsstatus som en stående punkt på månatliga ledningsmöten i stället för att det bara diskuteras när något redan har gått fel.

Ett praktiskt tips inför en revision: exportera fyndhistoriken regelbundet till ett format som revisorn kan läsa utan tillgång till er GCP-organisation, till exempel en CSV-export via BigQuery. SCC lagrar fynd löpande, men en extern granskare behöver sällan direktåtkomst till konsolen. En färdig kvartalsvis rapport, byggd på samma data som ligger till grund för teamets dagliga triage, sparar tid för alla inblandade och minskar risken att revisionen fastnar på att bara få tillgång till rätt behörigheter.

Security Command Center jämfört med andra alternativ

SCC är inte det enda sättet att hitta felkonfigurationer i GCP. Scout Suite, NCC Groups fler-molnsscanner, stöder också Google Cloud och kan vara ett komplement för team som redan kör den mot AWS eller Azure. Skillnaden är att Scout Suite inte har fått några nya releaser under 2026. Den senaste publicerade versionen är v5.14.0 från maj 2024, medan SCC:s dokumentation och release-noteringar har uppdaterats löpande genom hela augusti och in i september 2026.

Verktyg	Underhåll 2026	Bäst för
Security Command Center	Aktiv, kontinuerliga uppdateringar genom augusti-september 2026	Löpande skanning direkt integrerad i GCP-konsolen
Scout Suite	Ingen ny release sedan maj 2024	Engångsgranskningar över flera moln samtidigt
Manuell granskning	Beror helt på teamets kapacitet	Djupgranskning av enstaka högriskresurser

För de flesta organisationer är slutsatsen enkel: använd SCC som den löpande, automatiserade grunden, och komplettera med Scout Suite eller manuell granskning för punktinsatser där ni vill jämföra konfiguration mellan flera molnleverantörer i samma rapport.

Manuell granskning ska inte underskattas som metod, särskilt vid arkitekturbeslut som ett automatiskt verktyg inte kan bedöma. En detektor kan flagga att ett tjänstekonto har rollen Editor, men bara en människa med kontext kan avgöra om den rollen faktiskt behövs för att tjänsten ska fungera, eller om den bara sattes brett i brist på tid när projektet startades. Låt därför SCC hantera volymen av löpande kontroller, och reservera manuell granskning för de tillfällen då ett team planerar en ny arkitektur eller ska migrera en kritisk arbetslast, där sammanhanget väger tyngre än en generisk regel.

Vanliga frågor om Security Command Center

Kostar Security Command Center något?

Standard-nivån är kostnadsfri och ger grundläggande felkonfigurationsdetektering samt AI Protection-baslinje. Premium faktureras löpande utifrån resursanvändning, och Enterprise kräver en prenumeration för fullständig hot- och riskhantering.

Måste jag ha en organisationsstruktur i GCP för att använda SCC?

För full funktionalitet, ja. SCC kan aktiveras på enskilda projekt, men organisationsomfattande aktivering ger löpande skydd även för projekt som skapas efter aktiveringen, vilket är svårt att uppnå med enbart projektnivå. Saknar er organisation en formell struktur i dagsläget är det första steget att koppla era befintliga projekt till en Cloud Identity-organisation, vilket i regel kan göras utan att flytta eller pausa några befintliga tjänster.

Hur lång tid tar den första fullständiga skanningen?

Räkna med upp till 24 timmar för att Security Health Analytics ska hinna gå igenom alla resurser i en organisation med flera projekt. Mindre miljöer blir ofta klara betydligt snabbare.

Vad är skillnaden mellan Security Health Analytics och Vulnerability Assessment?

Security Health Analytics letar efter felkonfigurationer i hur resurser är inställda, till exempel öppna brandväggsregler. Vulnerability Assessment for Google Cloud, som gick GA den 10 augusti 2026, går djupare och identifierar kända sårbarheter i själva resurserna för att stödja riskprioritering.

Kan jag använda SCC för att skydda AI-agenter?

Ja. AI Protection ger en dedikerad AI-säkerhetsdashboard och resursinventering, och de nya Malicious Skill-detektorerna från augusti 2026 bevakar specifikt GKE, Cloud Run och Agent Platform mot skadliga LLM-plugin. Funktionen ingår redan i Standard-nivån, vilket betyder att även team utan budget för Premium eller Enterprise kan få grundläggande insyn i sina AI-arbetslaster utan extra kostnad.

Ersätter SCC behovet av tredjepartsverktyg som Scout Suite?

Inte helt. SCC är starkast som löpande, inbyggd övervakning direkt i GCP-konsolen. Scout Suite kan fortfarande vara användbart för punktinsatser som jämför konfiguration över flera molnleverantörer samtidigt, även om verktyget inte har fått någon ny release sedan maj 2024.

Fungerar Application Design Center-integrationen för alla applikationer?

Integrationen kräver att applikationen är registrerad i App Hub, antingen på mappnivå eller projektnivå. Utan den registreringen kan SCC inte filtrera eller koppla fynd till rätt applikation.

Var lagras data för AI Protection?

Det beror på region. Under augusti 2026 lade Google till stöd för dataresidens i Saudiarabien för samtliga servicenivåer, vilket visar att regional täckning byggs ut kontinuerligt. Nordiska organisationer bör verifiera vilken region som används innan AI Protection rullas ut brett, särskilt om interna krav pekar mot att data ska stanna inom EU/EES.

GCP Security Command Center: 14 Steg, 90 Min [2026]