Pilven tietoturvatilanteen hallinta puolustukselle: CSPM luokitelluissa ympäristöissä

Kirjoittanut Corvus Intelligencen insinööritiimi · Tietoa tiimistä →

25. kesäkuuta 2026 11 min lukuaika

Pilven virheellinen konfiguraatio on nykyään yleisin tietomurtojen aiheuttaja pilvipalveluinfrastruktuurissa — ja ongelma on huomattavasti vakavampi puolustusympäristöissä, joissa yhden paljastuneen resurssin seuraus ei ole liiketoimintahäiriö vaan mahdollinen tiedusteluoperaatioiden epäonnistuminen. Puolustusorganisaatiot, jotka siirtävät työkuormia julkishallinnon pilveen — AWS GovCloud, Azure Government tai luokiteltu kaupallinen pilvi IL4- ja IL5-vaikutustasoilla — perivät laajan ja dynaamisen hyökkäyspinnan, jota ei voida suojata pelkillä määräaikaisilla manuaalisilla auditoinneilla.

Pilven tietoturvatilanteen hallinta (CSPM) tarjoaa jatkuvan näkyvyyskerroksen, jota puolustuksen pilviympäristöt tarvitsevat: automaattisen, käytäntöpohjaisen pilven konfiguraatiotilan skannauksen vaatimustenmukaisuuden lähtötasoihin nähden, reaaliaikaiset hälytykset poikkeamista sekä integraation ATO-todistuspaketteja varten vaadittaviin virallisiin korjaus- ja akkreditointityönkulkuihin. Tässä artikkelissa käsitellään, miten CSPM toimii luokitelluissa ympäristöissä, mitä se skannaa, miten ajautumisen havaitseminen toimii ja miten CSPM-tuloste syötetään ATO-todistuspaketteihin, joita valtuuttavat viranomaiset edellyttävät.

Mitä CSPM kattaa ja miksi luokiteltu pilvi tarvitsee sitä

CSPM-työkalut arvioivat jatkuvasti pilviresurssien konfiguraatiotilaa määriteltyyn käytäntölähtötasoon nähden — arvioivat IAM-rooleja, verkon suojausryhmiä, tallennusbucketin käyttöoikeuksia, salausasetuksia, lokituskonfiguraatiota ja satoja muita resurssimääritteitä — ja nostavat poikkeamat havaintoina, jotka on korjattava tai hyväksyttävä virallisesti. Tämä on periaatteellisesti erilaista kuin haavoittuvuusskanneri, joka etsii ohjelmistoheikkouksia (CVE:t, puuttuvat korjaustiedostot, hyödynnettävät koodipolut); CSPM etsii konfiguraatioheikkouksia.

Ero on erittäin merkittävä luokitellussa pilviympäristössä. Puolustuksen pilvitenantit käyttävät tyypillisesti kovennetulla, korjatulla infrastruktuurilla, jota pilvipalveluntarjoaja ylläpitää jaetun vastuumallin mukaisesti. Työkuormat itse voivat olla hyvin korjattuja. Mutta näiden työkuormien käyttöönoton konfiguraatio — IAM-käytännöt, jotka ohjaavat pääsyä niihin, verkkoäärisäännöt, jotka määrittävät, mitä liikennettä niille pääsee, lokitusasetukset, jotka määrittävät, mitkä toiminnot kirjataan — on tenantin vastuulla, ja se muuttuu jatkuvasti operatiivisten vaatimusten kehittyessä.

Pistemittaus — perinteinen lähestymistapa, jossa arvioitsija tarkastaa konfiguraation määritellyllä hetkellä ATO-prosessin aikana — tuottaa vaatimustenmukaisuuskuvan, joka on tarkka kyseisellä hetkellä ja mahdollisesti epätarkka seuraavana päivänä. Valtuutettu käyttäjä, joka tekee laillisen muutoksen suojausryhmäsääntöön, järjestelmänvalvoja, joka luo uuden palvelutilin liian laajoilla käyttöoikeuksilla, kehittäjä, joka ottaa käyttöön ominaisuuden, joka muuttaa tallennuksen käyttöoikeusasetuksia: mikä tahansa näistä voi aiheuttaa virheellisen konfiguraation, joka luo hyödynnettävän aukon. Luokitelluissa ympäristöissä tämä aukko voi pysyä kuukausia auditointien välillä.

CSPM korvaa pistemittauksen jatkuvalla näkyvyydellä. Tapahtumaohjattuissa CSPM-arkkitehtuureissa uuden virheellisen konfiguraation havaitsemisviive voidaan mitata sekunteina — juuri luotu julkinen S3-bucket tai IAM-käytäntömuutos, joka myöntää liiallisia oikeuksia, käynnistää hälytyksen ennen kuin virheellistä konfiguraatiota ehditään hyödyntää. Tämä on keskeinen arvolupaus sotilastyökuormien pilven tietoturvan osalta: ei virheellisten konfiguraatioiden mahdollisuuden poistaminen (mikä operatiivisten todellisuuksien takia on väistämätöntä) vaan niiden havaitseminen ja korjaaminen ennen kuin niistä tulee tiedustelu- tai operatiivinen turvallisuuspoikkeama.

Lähtötason käytäntökehykset puolustuksen pilvelle

CSPM on yhtä hyödyllinen kuin sen valvoma käytäntölähtötaso. Puolustuksen pilviympäristöissä sovellettavat kehykset on hyvin määritelty, mutta kerrostettu, ja oikean kartoituksen saaminen on edellytys sille, että CSPM-havainnot ovat toimintakelpoisia ATO-kontekstissa.

DISA STIG Cloud Computing SRG. Pilvilaskennan turvallisuusvaatimusopas on viranomaisen DISA-asiakirja, joka määrittelee turvallisuusvalvonnan kaikille DoD-pilvipalvelujen käyttöönottoille. Se päällekkäistää NIST 800-53:n DoD-spesifisillä vaatimuksilla ja jakaa valvontavastuut pilvipalveluntarjoajan, tenantin ja niiden jaetun rajan välillä. SRG määrittelee vaatimukset virtualisointikerrokselle, käyttöjärjestelmäkerrokselle, sovelluskerrokselle ja pilvipalvelukerrokselle — kaikki näistä on käsiteltävä DoD-ATO-paketissa. CSPM-käytäntösäännöt on kartoitettava SRG-hallintotunnisteisiin, jotta havainnot voidaan yhdistää suoraan ATO-vaatimuksiin.

NIST SP 800-53 Rev 5. Kaikkien liittovaltion järjestelmien taustalla oleva hallintoluettelo. Pilven osalta olennaisimmat hallintoperheet ovat: Konfiguraatiohallinta (CM) — luvattomien konfiguraatiomuutosten ehkäisy ja havaitseminen; Järjestelmä- ja viestintäsuojaus (SC) — salaus kuljetuksen aikana ja levossa, verkkosegmentointi; Auditointi ja vastuuvelvollisuus (AU) — lokitus, lokien eheys ja säilytys; sekä Pääsynhallinta (AC) / Tunnistus ja todennus (IA) — IAM-käytäntö ja etuoikeushallinta. Hyvin konfiguroitu CSPM-käyttöönotto kartoittaa säännöt tiettyihin hallintatunnisteisiin (esim. CM-6, CM-7, AC-3, AU-2), jotta jokaisessa havainnossa on sen hallintaviittaus.

FedRAMP High -lähtötaso. DoD-järjestelmien IL4- ja IL5-tasoilla käyttämillä pilvipalveluilla on oltava FedRAMP High -valtuutus tai vastaava. FedRAMP High -lähtötaso laajentaa 800-53 Rev 4/5:ä tiukemmilla parametriarvoilla — esimerkiksi edellyttäen monivaiheistodennusta kaikille etuoikeutetuille ja ei-etuoikeutetuille tileille, ei vain etuoikeutetuille. FedRAMP High -käytäntöpaketit CSPM:lle ovat saatavilla AWS:lle, Azure Governmentille ja GCP:lle, ja nämä muodostavat lähtökohdan tenanttipuolen CSPM-konfiguraatiolle useimmissa puolustuspalvelujen käyttöönotoissa.

Seuraava taulukko havainnollistaa, miten keskeisimmät CSPM-tarkistusluokat kartoittuvat kolmeen ensisijaiseen kehykseen:

CSPM-tarkistusluokka	NIST 800-53 Rev 5	STIG SRG	FedRAMP High
IAM-käytännön sallivuus	AC-3, AC-6, IA-2	SRG-APP-000033	AC-6 (1)(2)(5)
Tallennuksen julkinen altistuminen	AC-3, SC-28	SRG-APP-000440	SC-28 (1)
Salaus levossa	SC-28	SRG-APP-000428	SC-28 (1)
Auditointilokituksen käyttöönotto	AU-2, AU-3, AU-12	SRG-APP-000089	AU-2, AU-12
Verkon rajoittamaton pääsy	SC-7, AC-17	SRG-NET-000019	SC-7 (3)(4)(5)
MFA-pakottaminen	IA-2 (1)(2)	SRG-APP-000149	IA-2 (1)(2)(3)(6)

Virheellisten konfiguraatioiden havaitseminen: mitä CSPM skannaa

Hyökkäyspinta, jota CSPM käsittelee puolustuksen pilviympäristössä, jakautuu viiteen ensisijaiseen luokkaan. Jokainen edustaa virheellisen konfiguraation luokkaa, joka on esiintynyt todellisissa DoD-ATO-havainnoissa ja joka luo hyödynnettäviä olosuhteita, jos sitä ei havaita jatkuvasti.

IAM-virheelliset konfiguraatiot ovat yleisin korkean vakavuuden havaintoluokka. Liian sallivat roolikäytännöt — erityisesti käytännöt, joissa käytetään jokerimerkkiä resurssimäärittelijöinä (Resource: "*") arkaluonteisille toiminnoille, tai hallinnollisten käytäntöjen liittäminen ei-hallinnollisiin pääoikeuksiin — rikkovat vähimpien oikeuksien periaatetta ja luovat sivuttaisliikkumispolkuja hyökkääjälle, joka vaarantaa jonkin pääoikeuden näillä käyttöoikeuksilla. CSPM-IAM-tarkistukset etsivät: käyttämättömiä rooleja ja käyttöavaimia (vanhentuneet tunnistetiedot, joita ei koskaan poistettu käytöstä), oikeuksien eskalaatiopolkuja (roolikäytännöt, joiden avulla pääoikeus voi muokata omia käyttöoikeuksiaan), tilien väliset luottamussuhteet ja juuritilin toiminta.

Verkon altistumistarkistukset tunnistavat suojausryhmäsäännöt, verkon ACL:t tai palomuurikäytännöt, jotka sallivat saapuvan pääsyn rajoittamattomista osoitealueista (0.0.0.0/0 tai ::/0) arkaluonteisiin portteihin — SSH (22), RDP (3389), tietokantaportit ja hallintoliitynnät. Luokitellussa pilviympäristössä hallintoliityntöjen altistuminen laajoille verkoalueille on STIG-luokan I havainto. CSPM-verkkotarkistukset varmistavat myös, että VPC-virtauslokitus on käytössä, ettei julkista IP-osoitteen määritystä ole käytössä yksityisen aliverkon resursseilla ja että verkon peering-suhteet ovat asianmukaisia.

Salauksen puuttuminen levossa on FedRAMP High- ja STIG-kova vaatimus — jokainen DoD-dataa sisältävä volyymi, tietokanta ja objektivarasto on salattava FIPS 140-2 -validoidulla algoritmilla. CSPM-salaustarkistukset luetteloivat tallennusresurssit (EBS-volyymit, RDS-instanssit, S3-bucketit, DynamoDB-taulukot) ja merkitsevät ne, jotka ovat salaamattomia tai salattu ei-validoidulla algoritmilla. Avainten hallintatapatarkistukset varmistavat, että salausavaimet ovat asiakashallittuja (CMK) eikä palveluntarjoajahallittuja, kun SSP niin edellyttää, ja että avainten kierto on käytössä.

Lokituksen puutteet ovat erityisen hankala virheellinen konfiguraatio, koska niiden puuttuminen on näkymätöntä, kunnes tapahtuman jälkeen tarvitaan oikeuslääketieteellistä rekonstruktiota. CSPM-lokitustarkistukset varmistavat, että CloudTrail (tai vastaava) on käytössä jokaisella alueella ja tilillä, että lokitallennuksessa on eheyden validointi käytössä (esim. CloudTrail-lokitiedoston validointi), että lokin säilytysaika täyttää vähimmäissäilytysajan (tyypillisesti 1–3 vuotta DoD-järjestelmissä) ja että hallintotapahtumat — konfiguraatiota muuttavat API-kutsut — tallennetaan erityisesti. Lokituspuutteet rikkovat suoraan AU-hallintoperheen vaatimuksia ja voivat tuottaa ATO-havaintoja, joita on vaikea kompensoida arkkitehtuurisesti.

Tallennuksen julkinen altistuminen — objektitallennusbucketit julkisella luku- tai kirjoitusoikeudella — pysyy CSPM-tarkistussarjoissa, koska se esiintyy edelleen todellisissa tapauksissa. Puolustuksen pilviympäristössä virheellisesti konfiguroidulla S3-bucketilla tai Azure Blob -kontainerilla, johon on julkinen pääsy, on suora CUI- tai luokiteltu datavuotopolku. CSPM tarkistaa bucket-tason julkisen pääsyn esto-asetukset, bucket-ACL:t, bucket-käytännöt, jotka sallivat todentamattoman pääsyn, ja julkisen pääsyn tilitasolla (AWS S3 Account Public Access Block).

Tyypillinen CSPM-skannaustulos keskiraskaaseen puolustuksen pilviympäristöön voi näyttää tältä:

CSPM Scan Summary — GovCloud Account: 123456789012
Scan Date: 2026-06-25T08:14:32Z  |  Framework: FedRAMP-High + STIG-SRG

Category                  Total  PASS   FAIL   WARN   SUPPRESSED
────────────────────────────────────────────────────────────────
IAM                         142   118     17      4          3
Network Security             89    82      5      2          0
Encryption at Rest           54    51      2      1          0
Audit Logging                31    28      3      0          0
Public Exposure              18    18      0      0          0
Key Management               22    20      1      1          0
────────────────────────────────────────────────────────────────
TOTAL                       356   317     28      8          3

Severity Breakdown (FAIL):
  Critical / Cat-I:   3  ← SLA: 15 days
  High     / Cat-II: 14  ← SLA: 30 days
  Medium   / Cat-III: 11  ← SLA: 90 days

Ajautumisen havaitseminen ja käytäntöjen valvonta

CSPM-skannaus tallentaa tilanteen tietyllä hetkellä; ajautumisen havaitseminen tallentaa tilanteen muutoksen. Operatiivisissa puolustuksen pilviympäristöissä konfiguraatiomuutokset ovat tiheitä — infrastruktuuri koodina -käyttöönotot, järjestelmänvalvojan toiminnot, palvelutilien provisiointi, ominaisuuslipun päivitykset ja pilvipalveluntarjoajan ylläpito voivat kaikki muuttaa resurssikonfiguraatioita. Ajautumisen havaitseminen tunnistaa, milloin nykyinen tila poikkeaa hyväksytystä lähtötasosta, ja se tekee niin riskiin nähden sopivalla viiveellä.

Kaksi ensisijaista skannausarkkitehtuuria ovat ajoitettu skannaus ja tapahtumaohjattu skannaus. Ajoitettu skannaus suorittaa täyden konfiguraatioläpikäynnin määritetyin välein — tunneittain, neljän tunnin välein tai päivittäin — ja on peruslähestymistapa useimmille CSPM-käyttöönotoille. Se on yksinkertainen, kattava ja toimii hyvin matalatahtisissa ympäristöissä. Sen rajoitus on viive: virheellinen konfiguraatio, joka on otettu käyttöön heti syklinalkamisen jälkeen, saatetaan havaita vasta lähes koko välin kuluttua.

Tapahtumaohjattu skannaus vähentää tätä viivettä sekunteihin käynnistämällä kohdennetut tarkistukset, kun konfiguraatiomuutostapahtumia havaitaan. AWS EventBridge voi reitittää CloudTrail-tapahtumat tietyille API-kutsuille (CreateBucket, PutBucketAcl, AuthorizeSecurityGroupIngress, AttachRolePolicy) CSPM-arviointifunktiolle, joka tarkistaa vain muutetun resurssin heti muutoksen jälkeen. Tämä arkkitehtuuri on välttämätön korkeimman riskin tarkistusluokille — IAM ja verkon altistuminen — joissa virheellisen konfiguraation luomisen ja hyödyntämisen välinen aika voi olla tunteja eikä päiviä.

Automaattiset korjaussuojakaiteet vievät tapahtumaohjatun havaitsemisen asteen pidemmälle: havaittuaan virheellisen konfiguraation CSPM-järjestelmä korjaa sen automaattisesti odottamatta ihmisen toimintaa. Julkisen bucketin luomista vastaan oleva suojakaidesuoja esimerkiksi havaitsee uuden bucketin, jolla on julkinen pääsy käytössä, ja asettaa välittömästi julkisen pääsyn eston, sitten hälyttää turvatiimin ja luo tiketin, jossa dokumentoidaan tapahtunut. Suojakaiteet ovat tehokkaita, mutta edellyttävät huolellista rajausta. Puolustusympäristöissä konservatiivinen suojakaiteiden suunnittelu on perusteltua:

Sovella automaattista korjausta vain hallintakeinoihin, joissa korjaava toiminto on yksiselitteinen ja riski laillisten toimintojen häiritsemisestä on lähes nolla (tallennuksen julkisen pääsyn estäminen, MFA-token-vaatimusten pakottaminen)
Älä koskaan korjaa automaattisesti IAM-käytäntömuutoksia tai verkkosääntömuutoksia ilman riippuvuuksien validointia — sovellukset saattavat riippua korjattavasta konfiguraatiosta
Jokainen automaattinen korjaustoiminto on kirjattava lokiin ja sen on tuotettava hälytys — suojakaiteet eivät saa luoda näkymätöntä konfiguraatiotilaa
Ylläpidä hätäpoistokytkimen estomekanismia, jotta valtuutettu järjestelmänvalvoja voi estää automaattisen korjauksen tietylle resurssille suunniteltujen ylläpitoikkunoiden aikana

Hätäpoistokytkimen poikkeuksen käsittely on täydentävä prosessi tilanteille, joissa korjausta ei voida toteuttaa välittömästi. Jos CSPM-havaintoa ei voida korjata SLA:n puitteissa teknisen rajoitteen tai operatiivisen riippuvuuden vuoksi, ISSO käynnistää virallisen riskinhyväksymistyönkulun: dokumentoi havainnon, tunnistaa kompensoivat hallintakeinot, hankkii AO-allekirjoituksen aikarajoitetulle hyväksymiselle ja kirjaa poikkeuksen eMASS:iin avoimena POA&M-kohteena. CSPM-työkalun tulisi heijastaa hyväksyttyjä poikkeuksia poistamalla havainto aktiivisilta kojelaudoilta säilyttäen sen auditoinnin historiassa, ja sen tulisi nostaa havainto automaattisesti uudelleen esiin hyväksymisjakson päätyttyä.

CSPM ilmarakostetuissa ja IL4/IL5-ympäristöissä

Vakio-kaupallinen CSPM-käyttöönottomalli — SaaS-alusta, joka muodostaa yhteyden pilvi-API:hin, kokoaa havainnot toimittajan isännöimässä taustajärjestelmässä ja tarjoaa verkkopohjaisen kojelaudan — on periaatteellisesti yhteensopimaton IL5- ja luokiteltujen pilvivaatimusten kanssa. Tietoja luokiteltujen pilven konfiguraatioista, resurssien inventaarioista, IAM-rakenteista ja tietoturva-havainnoista ei voida siirtää luokitellun rajan ulkopuolelle toimittajan kaupalliseen pilveen. Jopa IL4:ssä (Controlled Unclassified Information), monet ohjelmat soveltavat konservatiivista tietojen käsittelyä, joka estää SaaS-CSPM:n käytön.

Tämä luo arkkitehtuurirajoitteen, joka puolustuksen CSPM-käyttöönottojen on ratkaistava nimenomaisesti. Toimivat lähestymistavat ovat:

On-premises CSPM-moottorin käyttöönotto. Avoimen lähdekoodin CSPM-moottorit — Prowler (AWS), Steampipe vaatimustenmukaisuuden modeilla, Checkov (IaC-staattinen analyysi) tai Scout Suite — voidaan ottaa käyttöön kokonaan luokitellun enklaavin sisällä. Työkalu toimii rajan sisällä, kyselee pilvi-API:ita rajan sisältä, tallentaa havainnot sisäiseen tietokantaan ja luo raportteja, jotka eivät koskaan poistu luokitellulta alueelta. Tämä lähestymistapa edellyttää CSPM-työkalun omistajuutta operatiivisesti (päivitykset, allekirjoitusten ylläpito, sääntöpakettien hallinta), mutta tarjoaa täyden hallinnan ja nollan dataegression riskin.

Valtuutettu kaupallinen CSPM vaikutustasolla. Useilla kaupallisilla CSPM-tuotteilla on FedRAMP High -valtuutukset, ja ne tarjoavat käyttöönottotiloja AWS GovCloudissa tai Azure Government -alueilla. Nämä voivat olla hyväksyttäviä IL4-työkuormille, kun CSPM-työkalun tietojen käsittely on valtuutetun rajan sisällä. Ohjelmien tulisi varmistaa, että tietyn CSPM-tuotteen FedRAMP-valtuutus kattaa arvioitavat tietotyypit ja että tuote toimii GovCloud-residentissä käyttöönottotilassa, ei kaupallisen alueen taustajärjestelmässä, joka vastaanottaa GovCloud-dataa.

Agentittoman vs. agentipohjaisen skannauksen kompromissi on merkittävä luokitelluissa ympäristöissä:

Ageniiton CSPM kyselee pilvipalveluntarjoajan API:ita (AWS Config, Azure Resource Graph, GCP Asset Inventory) luetteloidakseen ja arvioidakseen pilven natiiveja resursseja. Se ei vaadi ohjelmiston asentamista laskentainstansseihin, sillä ei ole suorituskykyvaikutusta työkuormiin, ja se on suoraviivainen valtuuttaa, koska hyökkäyspinta on rajoitettu vain luku -API-tunnistetietoihin. Se on kuitenkin sokea käyttöjärjestelmätason konfiguraatiotilalle — se voi varmistaa, että EC2-instanssiin on liitetty oikea suojausryhmä, mutta ei voi varmistaa, onko käyttöjärjestelmän palomuuri oikein konfiguroitu tai pyöriikö instanssin sisällä kielletty palvelu.

Agenttipohjainen CSPM asentaa kevyen sensorin jokaiseen laskentainstanssiin, joka tarjoaa käyttöjärjestelmätason näkyvyyden: käynnissä olevat prosessit, asennetut paketit, tiedoston eheyden valvonta, käyttöjärjestelmätason konfiguraatioasetukset, jotka vastaavat STIG-isäntäohjaimia. Tämä tarjoaa kattavuuden hallintakeinoihin, joita pilvi-API:t eivät pysty arvioimaan. Kompromissi on, että agenttiohjelmisto itse on valtuutettava sovellettavalla luokitustasolla, otettava käyttöön akkreditointiprosessin kautta ja ylläpidettävä (päivitykset, allekirjoitusmuutokset) luokitellun rajan sisällä. Luokitelluissa ympäristöissä agentin valtuutusprosessi on usein ensisijainen rajoite agenttipohjaiselle CSPM:n käyttöönotolle.

Useimmat kypsät IL4/IL5-CSPM-käyttöönotot käyttävät ageniiton skannausta pilvi-API:n näkyvissä oleviin hallintakeinoihin ja erillistä HBSS (Host-Based Security System) tai päätelaitteen agentinratkaisua — usein DoD-standardin McAfee HIP/HBSS — isäntätason STIG-vaatimustenmukaisuuteen, integroiden molemmat tietolähteet yhtenäiseen vaatimustenmukaisuuden kojelautaan. Tämä DevSecOps puolustuksen putkistoille -asema, jossa CSPM syöttää samaan vaatimustenmukaisuusrekisteriin kuin putkiston tietoturvahallinnat, tarjoaa kattavimman ATO-todistuskuvan.

Korjaustyönkulun integraatio

CSPM-havainnoilla, jotka ovat vain CSPM-työkalun kojelaudalla, on rajallinen arvo puolustusprojektille. Institutionaalinen prosessi tietoturvalöydösten seurantaan on POA&M eMASS:issa — ja CSPM-havainnot on syötettävä tähän prosessiin automaattisesti, ei manuaalisen ISSO:n kautta, joka tarkistaa CSPM-kojelaudan ja kopioi havainnot manuaalisesti eMASS-tietueisiin.

Luokiteltujen ohjelmien integrointiarkkitehtuuri sisältää tyypillisesti kaksi vaihetta. Ensinnäkin CSPM-havainnot viedään ohjelman valtuutettuun tiketti- tai ongelmaseurantajärjestelmään — ServiceNow Government Cloud, Jira luokitellulla instanssilla tai mukautettu työkalu — missä niistä tulee toiminnallisia työkohteita, jotka on osoitettu pilvipalvelualustatiimille tai sovellustiimille, joka vastaa kyseisestä resurssista. Jokaisessa tiketissä on CSPM-havainnon tunniste, kyseessä oleva resurssi-ARN tai vastaava, vakavuus, sovellettavat vaatimustenmukaisuuden hallintaviittaukset, suositeltu korjausmenettely ja SLA-eräpäivä, joka on laskettu havainnon luomisajankohdasta ja vakavuuspohjaisesta SLA-käytännöstä.

SLA-seuranta on oltava nimenomainen ja näkyvä ohjelmajohdolle. Havainnolle, joka vanhenee SLA:nsa yli sulkematta, tulisi käynnistyä automaattinen eskalaatio: ensin tiiminvetäjälle, sitten ISSO:lle, sitten järjestelmänomistajalle. Ohjelmien tulisi julkaista viikoittainen SLA-vaatimustenmukaisuusmittari — prosenttiosuus havainnoista suljettu SLA:n puitteissa vakavuuden mukaan — ohjelmaterveysindikaattorina, joka syötetään AO:n saamaan jatkuvan valvonnan raportointiin.

Luokitellulle infrastruktuurille tiketti-integraatiolla on lisärajoitteita. Tiketit, jotka sisältävät erityisiä havainnon yksityiskohtia (resurssinimet, IP-osoitteet, konfiguraation erityiskohdat), saattavat täytyä olla luokitelluissa järjestelmissä, jos tieto itsessään on luokiteltu. Ohjelmien tulisi arvioida, nousevatko CSPM-havainnon yksityiskohdat CUI- tai korkeammalle tasolle — usein ne nousevat, erityisesti kun havainnot kuvaavat luokiteltujen isäntänimien resurssien verkon altistumista — ja reitittää tiketit vastaavasti. Luokittelemattomat yhteenvetomittarit (havaintojen lukumäärät, SLA-suorituskyky) voidaan raportoida luokittelemattomissa järjestelmissä.

Riskinhyväksymistyönkulut formalisoivat sellaisten havaintojen käsittelyn, joita ei voida välittömästi korjata. Työnkulku on:

ISSO toimittaa riskinhyväksymispyynnön, jossa dokumentoidaan: tietty havainto, tekninen tai operatiivinen syy siihen, miksi korjaus ei ole välittömästi toteutettavissa, tunnistetut kompensoivat hallintakeinot, jotka vähentävät riskiä välillä, ja ehdotettu hyväksymisjakso (ei ylitä 90 päivää korkean vakavuuden havainnoille)
Turvatiimi tarkistaa ja validoi kompensoivat hallintakeinoväitteet
AO tarkistaa ja allekirjoittaa riskinhyväksymismemon, hyväksyy virallisesti jäännösriskin
Havainto kirjataan avoimena POA&M-kohteena eMASS:iin allekirjoitettu memo liitettynä
CSPM poistaa aktiivisen havaintohälytyksen säilyttäen sen auditoinnin historiassa merkittynä hyväksymistietuenumerolla
Kalenterimuistutus asetetaan 30 päivää ennen hyväksynnän vanhentumista uudistamisen tai korjauksen käynnistämiseksi

Tämä prosessi varmistaa, että hyväksytyt poikkeukset ovat AO:n näkyvissä, aikarajoitettuja eikä ne kasaudu hiljaa. Zero trust -mikrosegmentointi puolustuksessa -arkkitehtuurit hyötyvät suoraan tästä työnkulusta, koska mikrosegmentoinnin käytäntömuutokset, jotka vaikuttavat CSPM-havaintoihin, on seurattava saman virallisen poikkeusprosessin kautta ATO-jatkuvuuden ylläpitämiseksi.

Jatkuva vaatimustenmukaisuusraportointi

DoD-järjestelmien ATO-prosessi riskinhallintakehyksen (RMF) mukaisesti edellyttää kattavaa todistusaineistoa (Body of Evidence, BOE), joka osoittaa, että tietoturvahallinnat on toteutettu ja ne ovat tehokkaita. Pilvi-infrastruktuurin hallintakeinojen osalta tämä todistusaineisto koostui perinteisesti manuaalisesti tuotetuista STIG-skannausraporteista ja konfiguraatiokaappauksista, jotka tuotettiin arviointihetkellä. CSPM mahdollistaa periaatteellisesti erilaisen mallin: todistusaineisto, joka tuotetaan jatkuvasti ja on saatavilla pyydettäessä, eikä tuoteta intensiivisen todistuskeräilysprint-jakson aikana ennen jokaista arviointia.

CSPM-jatkuvan vaatimustenmukaisuusraportoinnin arkkitehtuuri tuottaa kolme tulosluokkaa:

Automaattiset ATO-todistuspaketit. CSPM-vaatimustenmukaisuusraportit, jotka viedään viikoittain ja ennen jokaista arviointitapahtumaa, tarjoavat jäsenneltyä todistusaineistoa hallintakeinon toteutuksen tilasta. Raportit kartoitetaan eMASS-hallintotunnisteisiin — AU-2-havaintoihin suodatettu CSPM-raportti osoittaa auditointitapahtuman konfiguraation tilan; CM-6-raportti osoittaa konfiguraatiolähtötason valvonnan. Nämä voidaan lähettää eMASS:iin REST API:n kautta tai ladata todistusartefakteina. ISSO:n rooli siirtyy todistusaineiston tuottamisesta järjestelmän automaattisesti tuottaman todistusaineiston tarkistamiseen ja sertifiointiin.

Hallintokeinon perinnön kartoitus. Jaetun vastuumallin mukaisissa pilviympäristöissä monet hallintakeinot peritään CSP:ltä (pilvipalveluntarjoajalta) eikä tenantti toteuta niitä. CSPM on konfiguroitava heijastamaan tätä perintöä: fyysistä pääsynhallintaa, hypervisorin korjausta ja konesalin fyysistä turvallisuutta koskevat tarkistukset kartoitetaan CSP-perittyihin hallintakeinoihin eivätkä ne saa esiintyä tenantin havaintoina. Tenantin vastuulla olevat hallintakeinot — IAM, verkko, salaus, lokitus — ovat CSPM:n soveltamisala. Oikein konfiguroitu CSPM-järjestelmä tuottaa perintökartan, joka vastaa järjestelmän tietoturvasuunnitelmaa, välttäen sekä väärät havainnot perityistä hallintakeinoista että aukkoja tenantin vastuulla olevissa hallintakeinoissa.

Automaattiset POA&M-päivitykset. Avoimet CSPM-havainnot on syötettävä automaattisesti eMASS-POA&M:iin avoimina kohteina. Kun havainnot korjataan ja CSPM vahvistaa korjatun konfiguraation, vastaavat POA&M-kohteet on päivitettävä sulkemistodistusaineistolla. Tämä sulkee silmukan tietoturvatyökalun ja hallintakeinon toteutuksen auktoritatiivisen tietueen välillä — ISSO:n ei enää tarvitse siirtää tietoja manuaalisesti järjestelmien välillä, ja AO:lla on aina tarkka kuva avoimista havainnoista ja niiden korjauksen tilasta.

Esimerkki CSPM:stä eMASS:iin -integraatiovuosta havainnollistaa tietoliikennettä:

# CSPM → eMASS integration (illustrative)

CSPM Finding:
  id: CSPM-2026-06-25-0041
  check: aws-s3-bucket-encryption-enabled
  resource: arn:aws:s3:::dod-app-data-prod
  severity: High
  controls: [SC-28, SC-28(1), SRG-APP-000428]
  status: FAIL
  detected: 2026-06-25T09:14:22Z
  sla_due: 2026-07-25T09:14:22Z

eMASS POA&M Entry (auto-created):
  weakness_name: S3 bucket without encryption at rest
  control: SC-28(1) / SRG-APP-000428
  scheduled_completion: 2026-07-25
  milestone: Enable SSE-KMS with CMK on bucket dod-app-data-prod
  resources_required: Cloud platform team, 2h estimated
  status: Ongoing
  evidence_artifact: cspm-finding-CSPM-2026-06-25-0041.json

Tämän integraation pitkän aikavälin hyöty on muutos ATO-uusimisten toimintamallissa. Sen sijaan, että ennen arviointia olisi intensiivinen todistuskeräilyjakso — joka perinteisissä ohjelmissa kuluttaa viikkoja turvatiimin aikaa ja lisää todistusaukkojen riskiä — ohjelma, jolla on kypsä CSPM-integraatio, voi tuottaa ajantasaisen ja kattavan todistuspaketin tunneissa. Jatkuvan valvonnan data on todistusaineisto. Tämä on se toimintamalli, jonka DoD:n siirtyminen jatkuvaan valtuutukseen (jatkuva ATO) tavoittelee, ja CSPM on perustyökalu, joka tekee sen saavutettavaksi pilvipalveluilla isännöidyille puolustustyökuormille.

Keskeinen havainto: Yleisin epäonnistumistapa puolustuksen CSPM-käyttöönotoissa ei ole työkalun valinta tai käytäntöjen kattavuus — se on integraation täydellisyys. CSPM-työkalu, joka skannaa oikein, mutta ei reititä havaintoja eMASS:iin, ei valvo SLA-vastuullisuutta eikä tuota ATO-valmista todistusaineistoa, tuottaa murto-osan mahdollisesta arvostaan. Puolustusprojektien tulisi panostaa yhtä paljon integrointiarkkitehtuuriin (tiketti, eMASS API, raportointiputkistot) kuin itse CSPM-työkaluun. Jatkuva tilanteen hallinta on prosessi ja tietovirta, ei pelkkä skanneri.

Keskustele projektistasi

Suunnittelemme ja toteutamme CSPM-arkkitehtuureja luokiteltuihin ja julkishallinnon pilviympäristöihin — käytäntölähtötason kartoituksesta ja ajautumisen havaitsemisesta eMASS-integraatioon ja jatkuviin ATO-todistusputkistoihin.

Kyberturvallisuuspalvelut → Kehityspalvelut

Tämän analyysin ovat laatineet Corvus Intelligencen insinöörit, jotka suunnittelevat tietoturva-arkkitehtuureja puolustuksen ja julkishallinnon pilviohjelmille. Lue lisää tiimistämme →

Usein kysytyt kysymykset

Mikä on CSPM ja miksi puolustuksen pilvi tarvitsee sitä?

Pilven tietoturvatilanteen hallinta (CSPM) on työkaluluokka, joka arvioi jatkuvasti pilvi-infrastruktuurin konfiguraatioita tietoturvakäytäntöjen lähtötasoja ja vaatimustenmukaisuuskehyksiä vasten — tunnistaa virheelliset konfiguraatiot, käytäntöpoikkeamat ja hallintakeinon aukkoja reaaliajassa. Puolustuksen pilviympäristöt tarvitsevat CSPM:ää, koska luokitelluilla ja julkishallinnon pilven työkuormilla on tiukat vaatimustenmukaisuusvaatimukset (DISA STIGs, NIST 800-53, FedRAMP High, IL4/IL5-lähtötasot), jotka muuttuvat jokaisen STIG-päivityksen myötä ja voivat ajautua operatiivisten muutosten jälkeen. CSPM korvaa pistemittausauditoinnet — jotka saattavat tapahtua vain vuosittain — jatkuvalla, automaattisella skannauksella, joka havaitsee virheelliset konfiguraatiot ennen kuin ne muuttuvat hyödynnettäviksi haavoittuvuuksiksi tai ATO-löydöksiksi.

Miten CSPM eroaa perinteisestä haavoittuvuusskannausohjelmasta?

Perinteiset haavoittuvuusskannausohjelmat kohdistuvat ohjelmistohaavoittuvuuksiin — CVE:t paketeissa, puuttuvat käyttöjärjestelmän korjaustiedostot, tunnetut sovelluksen heikkoudet. CSPM kohdistuu konfiguraatiotilaan: ovatko IAM-käytännöt liian sallivia, ovatko tallennusbucketit julkisesti saavutettavissa, onko salaus levossa käytössä jokaisella volyymilla, onko auditointiloki käytössä ja reitittyy oikein, salliko verkkosuojausryhmät rajoittamattoman saapuvan pääsyn arkaluonteisiin portteihin. Puolustusympäristöissä virheellinen konfiguraatio on usein todennäköisempi hyökkäysvektori, koska luokitelluilla pilvitenantilla on epätodennäköistä olla korjaamattomia CVE:itä mutta erittäin todennäköistä kerääntyä konfiguraatioajautumaa sadoissa pilviresursseissa, kun operatiiviset tarpeet kehittyvät kuukausien aikana.

Mihin vaatimustenmukaisuuskehyksiin CSPM kartoittuu DoD-ympäristöissä?

DoD CSPM:n ensisijaiset kehykset ovat: DISA STIG Cloud Computing SRG, joka määrittelee pilvispesifisen hallintakeinon lähtötason kaikille DoD-pilvitenantille; NIST SP 800-53 Rev 5, joka tarjoaa taustalla olevan hallintoluettelon; FedRAMP High -lähtötaso, joka laajentaa 800-53-hallintakeinoja pilvavaltuutusta varten; sekä ympäristöspesifiset päällekkäisyydet IL4:lle (Controlled Unclassified Information) ja IL5:lle. CSPM-työkaluissa on tyypillisesti valmiita käytäntöpaketteja 800-53:lle ja FedRAMP:lle, ja niitä voidaan laajentaa mukautetuilla säännöillä STIG Cloud SRG -hallintakeinoille, joita geneerisemmät kaupalliset paketit eivät kata.

Mitkä ovat korkeimman riskin virheellisen konfiguraation luokat puolustuksen pilviympäristössä?

DISA STIG Cloud SRG -vaatimusten ja yleisten IL4/IL5 ATO-löydösten perusteella korkeimman riskin luokat ovat: (1) IAM-virheelliset konfiguraatiot — liian sallivat roolikäytännöt, jokerimerkkiset resurssioikeudet, passiiviset käyttöavaimet, joita ei kierrätetä; (2) tallennuksen julkinen altistuminen — objektitallennusbucketit julkisilla ACL:llä tai bucket-käytännöillä, jotka sallivat todentamattoman lukemisen; (3) salauspuutteet — volyymit tai objektivarastot ilman salausta levossa tai salattu ei-FIPS-validoiduilla algoritmeilla; (4) lokituspuutteet — CloudTrail tai vastaava ei ole käytössä jokaisella alueella tai tilillä, lokitallennus ilman eheyden validointia; (5) verkon altistuminen — suojausryhmät tai palomuurisäännöt, jotka sallivat saapuvan pääsyn osoitteesta 0.0.0.0/0 hallintaportteihin. Nämä viisi luokkaa kattavat suurimman osan DoD-pilvi-ATOjen kriittisistä löydöksistä.

Voivatko CSPM-työkalut toimia ilmarakostetuissa tai luokitelluissa ympäristöissä?

Kyllä, mutta käyttöönotto-arkkitehtuuria on mukautettava merkittävästi. Kaupalliset CSPM SaaS -tuotteet, jotka lähettävät telemetriaa toimittajan pilvi-infrastruktuuriin, eivät sovellu IL5- tai sitä ylemmille tasoille ilman huolellista arviointia — monilla ei ole valtuutusta niille vaikutustasoille. Toimivia lähestymistapoja ovat: avoimen lähdekoodin CSPM-moottoreiden, kuten Prowlerin tai Steampipe-ohjelman, on-premises-käyttöönotto luokitellun enklaavin rajan sisällä; agenttipohjainen CSPM, joka toimii skannaustoimintalogiikkaa enklaavin sisällä ilman uloslähtevää telemetriaa; sekä valtuutetut kaupalliset CSPM-tuotteet, joilla on FedRAMP High tai IL4/IL5 -valtuutukset ja jotka voidaan ottaa käyttöön GovCloudissa tai luokitelluilla alueilla. Kaikissa lähestymistavoissa haavoittuvuus- ja käytäntötietokannat on päivitettävä hyväksyttyjen verkkotoimialueiden ylittämismekanismien kautta eikä suorista internet-syötteistä.

Mitä tarkoittaa ajautumisen havaitseminen CSPM-kontekstissa ja miksi se on tärkeää ATO:n jälkeen?

Ajautumisen havaitseminen tarkoittaa sen tunnistamista, milloin pilviresurssin nykyinen konfiguraatio poikkeaa hyväksytystä, vaatimustenmukaisesta lähtötasosta — konfiguraatio, joka arvioitiin ja hyväksyttiin ATO-prosessin aikana. ATO:n jälkeinen ajautuminen on erittäin yleistä operatiivisissa puolustuksen pilviympäristöissä, koska valtuutetut käyttäjät tekevät konfiguraatiomuutoksia ratkaistakseen operatiivisia ongelmia käymättä läpi virallista muutoksenhallintaprosessia. CSPM-ajautumisen havaitseminen tallentaa nämä muutokset niiden tapahtuessa — sekunteina tapahtumaohjattuisissa arkkitehtuureissa — ei seuraavassa vuosiarvioinnissa, antaen ISSO:lle mahdollisuuden korjata ennen kuin altistumisikkuna pitenee.

Miten CSPM-havainnon vakavuus tulisi kartoittaa korjaustoimien SLA:hin?

Puolustuksen CSPM-korjaustoimien SLA:t tulisi noudattaa DoD:n haavoittuvuudenhallintarakennetta: Kriittinen / STIG-luokka I — korjaa 15 päivässä tai hanki virallinen riskinhyväksyntä AO:lta; Korkea / Luokka II — korjaa 30 päivässä; Keskisuuri / Luokka III — korjaa 90 päivässä; Matala — dokumentoi ja seuraa POA&M:ssa seuraavaan tarkistussykliin. CSPM-havainnot on syötettävä suoraan ohjelman POA&M:iin eMASS:issa, ja jokaisella havainnolla on oltava nimetty omistaja, korjauksen tavoitepäivämäärä ja nykyinen tila. Hyväksytyt poikkeukset edellyttävät AO-allekirjoitusta ja niissä on dokumentoitava jäännösriski.

Mikä on automaattinen korjaussuojakaidesuoja ja milloin se soveltuu puolustuksen CSPM:ään?

Automaattinen korjaussuojakaidesuoja on CSPM-käytäntö, joka havaittuaan virheellisen konfiguraation korjaa sen automaattisesti vaatimatta ihmisen hyväksyntää — esimerkiksi poistaa julkisen pääsyn juuri luodusta tallennusbucketista. Puolustusympäristöissä suojakaiteet soveltuvat kapeaan joukkoon korkean luottamuksen, vähäisen sivuvaikutuksen korjauksia, joissa korjaava toiminto on yksiselitteinen ja riski laillisten toimintojen häiritsemisestä on lähes nolla. Ne eivät sovellu muutoksiin, jotka voisivat rikkoa operatiivisia työnkulkuja, kuten IAM-oikeuksien peruuttamiseen sovellukset, joista sovellukset riippuvat, tai tuotantoliikenteen kulkemien verkkosääntöjen muuttamiseen ilman riippuvuuskaavion validointia ensin.

Miten CSPM integroituu eMASS:iin jatkuvan ATO-todistusaineiston osalta?

eMASS on DoD:n tietuejärjestelmä RMF-valtuutuksille. CSPM-tuloste voidaan syöttää eMASS:iin jatkuvasti useiden integrointimallien kautta: suora API-lähetys, jossa CSPM-työkalut käyttävät eMASS REST API:ta lähettääkseen havainnon päivityksiä ja hallintakeinon tilan muutoksia reaaliajassa; SIEM-integraatio, jossa CSPM-havainnot reititetään SIEM:n kautta, joka kokoaa ja vie jäsennellyt todistuspaketit; sekä ajoitettu todistusvienti, jossa CSPM-raportit generoidaan määritetyllä syklillä eMASS-hallintakeinon todistuksen lataamisen kanssa yhteensopivissa muodoissa. Tavoitteena on, että pilvi-infrastruktuurin hallintakeinojen ATO-todistusaineisto generoidaan automaattisesti CSPM-datasta eikä turvatiimi kokoa sitä manuaalisesti.

Mikä on ero agentittoman ja agenttipohjaiseen CSPM-skannaukseen luokitellussa pilviympäristössä?

Ageniiton CSPM käyttää pilvipalveluntarjoajan API:ita resurssien luettelointiin ja niiden konfiguraatiotilan arviointiin asentamatta ohjelmistoa itse resursseihin. Se on kevyt, kattaa pilven natiivit resurssit hyvin eikä sillä ole suorituskykyvaikutusta työkuormiin. Agenttipohjainen CSPM asentaa sensorin jokaiseen laskentainstanssiin, joka kerää käyttöjärjestelmätason konfiguraatiodataa, ajonaikaista prosessitilaa ja tiedoston eheyden tietoja, jotka eivät ole nähtävissä pilvi-API:iden kautta. Luokitellussa pilviympäristössä ageniiton on helpompi valtuuttaa ja sillä on vähemmän hyökkäyspintaa, mutta se ei havaitse käyttöjärjestelmätason STIG-hallinnan laskentainstansseilla. Useimmat kypsät luokiteltujen pilviympäristöjen CSPM-käyttöönotot käyttävät ageniiton skannausta pilvi-API-näkyvissä oleviin hallintakeinoihin ja erillistä HBSS- tai päätelaitteen ratkaisua isäntätason STIGeille, integroiden molemmat tietolähteet yhtenäiseen vaatimustenmukaisuuden kojelautaan.