Pilvinatiivit puolustussovellukset: mikropalvelut, palveluverkko

Puolustuksen komento- ja kontrollialustat ovat historiallisesti olleet monoliitteja — yksi käyttöönotettava yksikkö, joka sisältää reittien hallinnan, viestintävälityksen, tulenkäytön koordinoinnin ja tiedustelun integroinnin jaetun tietokannan takana. Monoliitti ei ollut sattuma: se yksinkertaisti akkreditointia, minimoi verkon hyökkäyspintaa ja vastasi pienen tiimin henkilöstömallia, joka ylläpiti yhtä artefaktia. Mutta sen aiheuttava hauraus on yhä enemmän hyväksymätöntä. Yhden komponentin päivitys vaatii koko alustan ylläpitoikkunan. ISR-reittien määrän kasvu heikentää tulirajapintaa. Tietokannan skeeman muutos jäädyttää liittymättömät kehityssäikeet viikoiksi.

Pilvinatiivi arkkitehtuuri käsittelee näitä vikatiloja jakamalla alustan itsenäisesti käyttöönnotettaviin palveluihin, joilla kukin on oma tallennuskerroksensa, joita Kubernetes operoi ja joita palveluverkko suojausta lopusta loppuun. Tämä ei ole ensisijaisesti kustannus- tai ketteryyystarina — se on kestävyyden ja operatiivisen itsemääräämisoikeuden tarina. Kun reittien fuusiopalvelu hajoaa pilvinatiivissa C2-alustassa, se hajoaa eristyksissä. Tulien koordinointirajapinta pysyy pystyssä, viestintävälitys jatkaa viestien reititystä ja operaattorit näkevät heikentyneen — mutta ei poissaolleen — yhteisen toimintakuvan, kun epäonnistunut palvelu paranee itsestään. Vastaavaa eristämistä ei ole saavutettavissa monoliitissa ilman tarkoituksellista prosessinsisäistä vahvistamista, joka tuo mukanaan olennaisesti saman monimutkaisuuden.

Tässä artikkelissa käsitellään pilvinatiivien kuvioiden koko pinonaa puolustuksen C2- ja ISR-kuormille: toimialueen jakaminen rajattuihin konteksteihin, palveluverkon käyttöönotto vastavuoroiseen TLS:ään ja havaittavuuteen, Kubernetes-operaattorikuviot tilallisille komponenteille, tapahtumavetoinen sensorifuusio CQRS:n ja tapahtumalähteisen tallennuksen avulla, SRE-käytäntö elintärkeille palveluille sekä hallittu heikkeneminen vastustajan uhkaamissa verkkolosuhteissa.

Miksi pilvinatiivi puolustuksen C2/ISR-sovelluksissa

Peruste pilvinatiiville puolustuksessa ei ole sama kuin kaupallisessa ohjelmistokehityksessä. Kaupalliset tiimit ottavat mikropalvelut käyttöön kehitysnopeuden vuoksi — pienemmät tiimit omistavat pienempiä koodikantoja ja julkaisevat nopeammin ja itsenäisesti. Nämä edut ovat olemassa myös puolustuksessa, mutta ne ovat toissijaisia. Ensisijainen peruste on sitkeys: monoliitin vikatilanteet eivät sovellu tehtävävaatimuksiin.

Monoliitin herkkyys haastavissa ympäristöissä. Monoliittisessa C2-alustalla on yksi vikatila-alue. Muistipaine maalien vastaanotossa heikentää tulenkäyttöliittymää. Juuttunut tietokantatransaktio estää viestien reitityksen. Muistivuotoinen komponentti vaatii koko alustan uudelleenkäynnistyksen — kaikki toiminnot samanaikaisesti offline-tilaan. Nämä vikatilanteet ovat sallittuja, kun järjestelmä toimii hallitussa varusmiestilanteessa suunniteltujen ylläpidon aikoina. Ne eivät ole sallittuja, kun järjestelmä on yksikön ensisijainen tilannekuva-työkalu taistelutilanteessa tai kun vastustaja kohdistaa järjestelmän vakauteen tahallista hyökkäystä.

Itsenäinen käyttöönottonopeus kyvykkyyksien päivityksille. Puolustusohjelmat kohtaavat paradoksin: ohjelmisto on päivitettävä nopeasti (uudet uhkamerkit, päivitetty ROE-logiikka korjatut haavoittuvuudet), mutta toiminnallinen häiriö on minimoitava. Monoliitissa jokainen muutos koskee samaa käyttöönotettavaa pakettia ja vaatii täyden regressiotestauksen sekä koko alustan ylläpidon ajan. Pilvinatiivissa arkkitehtuurissa uhkafuusiopalvelu voidaan päivittää — validoida, ottaa käyttöön ja tarvittaessa palauttaa — koskematta tulenkäyttöliittymään tai viestintävälityspalveluun. Jokaisella palvelulla on oma julkaisutahtinsa, joka vastaa sen muutostaajuutta ja riskiprofiilia.

Vaakasuuntainen skaalaus huippukuormille. ISR-toiminta tuottaa erittäin vaihtelevia datamääriä. Teatteritason harjoitus voi tuottaa kymmenkertaisen maalikuorman suhteessa normaaliin. Monoliitti skaalautuu yhtenä yksikkönä — huippukuorman käsittelemiseksi jokainen komponentti on mitoitettava huippukapasiteettiin, mikä tuhlaa resursseja normaalitoiminnassa. Pilvinatiivissa alustassa maalien fuusiopalvelu skaalautuu vaakasuunnassa kuorman mukaan, kun taas tulenkäyttöliittymä ja viestintävälitys pitävät normaalin replikamääränsä. Kubernetes hoitaa skaalauksen automaattisesti CPU:n, muistin tai mukautettujen mittareiden perusteella sensorien vastaanotinjonon syvyydestä.

Pilvinatiivi puolustuksessa ei ole synonyymi julkiselle pilvelle. Kuvio pätee yhtä lailla luokiteltuun on-premise-infrastruktuuriin, yksityisiin suvereeniin pilviympäristöihin ja eteenpäin sijoitettuihin reunaklusteriin, joissa ajetaan kevyttä Kubernetes-jakelua. Määrittävä piirre on, että palvelut ovat kontteina, hallittuina deklaratiivisesti ja eristettyinä toisistaan — ei se, missä infrastruktuuri sijaitsee.

Mikropalveluihin jakaminen C2-sovelluksissa

Vaikein osa pilvinatiivin käyttöönotossa ei ole tekniikka — vaan se, mihin palvelurajat vedetään. Väärät rajat luovat mikropalveluja, jotka ovat tiukasti kytkettyjä yhteisiin tietokantoihin tai synkronisiin ketjuihin, joiden vika leviää kaikkialle. Oikeat rajat luovat palveluja, jotka voidaan ottaa käyttöön, skaalata ja korvata itsenäisesti ilman koordinaatiota viereisten tiimien kanssa.

Rajatun kontekstin suunnittelu C2-alueille. Toimialalähtöinen suunnittelu tarjoaa kehyksen: tunnista C2-alustan erilliset toimialueet ja ympäröi ne rajoilla tietojen omistuksen, käyttäjäryhmien ja päivityssemanantiikan perusteella. C2-alusta sisältää tyypillisesti vähintään viisi erillistä toimialuetta, jotka vastaavat siististi rajattuja konteksteja:

• Maalien hallinta — omistaa virallisen maalivaraston, fuusioi sensoriraportit, ylläpitää maalien historiaa ja tarjoaa yhteisen toimintakuvan (COP). Päivitystaajuus on korkea (sensoriraportit saapuvat jatkuvasti); käyttäjiin kuuluu käytännössä jokainen muu palvelu.
• Viestintävälitys — hallitsee viestien reititystä, radioverkon topologiaa ja kanavien jakoa. Irrotettu maalien hallinnasta: viestintä toimii riippumatta siitä, onko maalien fuusio terve.
• Tulenjohto — hallitsee tulen tehtäviä, päällekkäisyyksien ratkaisemista ja maalien käsittelyn seurantaa. Kuluttaa maalitietoja mutta omistaa oman tilansa; tulenkäyttöliittymän on pysyttävä käytettävissä, vaikka maalien fuusio olisi tilapäisesti heikentynyt.
• Tiedustelutietojen integrointi — ottaa vastaan tiedustelutuotantoa, korreloi sen maalien kanssa ja julkaisee arvioita. Pitkäkestoisia analyysitöitä, joiden latenssivaatimukset poikkeavat reaaliaikaisesta maalien fuusiosta.
• Logistiikan tila — seuraa yksiköiden huoltovarmuutta, kaluston saatavuutta ja ylläpitöpyyntöjä. Eri päivitystahti ja käyttäjäkunta kuin operatiivisilla C2-toiminnoilla.

Palvelurajapintasopimukset. Jokainen rajattu konteksti julkaisee rajapintasopimuksen — OpenAPI-määrityksen synkronisille REST- tai gRPC-rajapinnoille tai Avro- tai Protobuf-skeeman asynkronisille tapahtumarajapinnoille. Sopimukset ovat ensisijainen kytkentämekanismi palvelujen välillä, ja ne on versioitava ja käsiteltävä rikkovien muutosten herkkinä. Palvelu, joka muuttaa tapahtumaskeemaansa rekisteröimättä uutta versiota skeemarekisteriin, voi vahingoittaa kuluttajia hiljaa — vikatila, joka näkyy vasta, kun kuluttaja käsittelee virheellisen tapahtuman ja tuottaa väärän tuloksen.

Kardinaalinen sääntö: palvelut omistavat tietonsa. Maalien hallintapalvelu omistaa maalivaraston. Tulipalvelu omistaa tulentehtävien tilan. Mikään palvelu ei lue toisen palvelun tietokantaa suoraan. Kaikki palvelujen välinen tietojen käyttö kulkee julkaistun rajapinnan kautta. Tämä rajoitus tekee itsenäisestä käyttöönotosta todellista — ilman sitä maalien hallinnan tietokantaskeeman muutos rikkoo tulipalvelun riippumatta niiden nimellisestä itsenäisyydestä.

Syvällisempään käsittelyyn siitä, miten nämä palvelut vahvistetaan infrastruktuuritasolla, katso Kubernetes defense hardening — pod-turvallisuus, verkkopolitiikka ja pääsynhallinta, jotka täydentävät palvelujen jakoa.

Palveluverkko: mTLS ja havaittavuus

Palveluverkko lisää sidecar-välityspalvelimen (Envoy Iston tapauksessa; kevyt Rust-välityspalvelin Linkerdssä) jokaiseen podiin ja ottaa haltuunsa kaiken saapuvan ja lähtevän verkkoliikenteen. Sovellus kommunikoi localhostin kanssa; sidecar hoitaa salauksen, todennuksen, uudelleenyritykset, piirikatkaisun ja telemetrian keruun. Sovelluksen näkökulmasta verkko on abstrahoitu; operaattorin näkökulmasta jokainen kutsu palveluverkon läpi on näkyvissä ja politiikan ohjaama.

Vastavuoroinen TLS itä-läenne-liikenteelle nolla-luottamuksen C2-verkoissa. Nolla-luottamuksen arkkitehtuuri edellyttää, että yhtäkään verkkokutsua ei luoteta pelkän verkkosijainnin perusteella — palvelun klusterin sisällä on todennettava yhtä ankarasti kuin sen ulkopuolella. Tiukkaan mTLS:ään konfiguroidussa palveluverkossa jokainen itä-läenne-kutsu (palvelusta palveluun klusterin sisällä) todennetaan työkuormatodistuksilla, jotka palveluverkon varmenneviranomainen on myöntänyt. Palvelu, joka ei pysty esittämään kelvollista todistusta — olipa kyse luvattomasta työkuormasta, virheellisestä käyttöönotosta tai kompromitoidusta kontista — hylätään sidecar-välityspalvelimessa ennen kuin pyyntö saavuttaa sovelluksen.

Luokitelluissa ympäristöissä palveluverkon varmenneviranomaisen on integroitava klusterin sisäiseen PKI:hin internetissä saatavilla olevan CA:n sijaan. Istio tukee liitettäviä CA-taustajärjestelmiä — Istion CA voidaan korvata mukautetulla CA:lla, joka myöntää todistuksia luottamusketjusta, jonka juuri on ohjelman akkreditoitu PKI-infrastruktuuri. Todistusten kierrätyksen on oltava automaattista: manuaalinen todistustenhallinta on toiminnallisesti herkkä ja on aiheuttanut käyttökatkoja luokitelluissa järjestelmissä, kun todistukset vanhentuivat harjoitusten aikana.

Istio ja Linkerd luokitelluissa ympäristöissä. Istio tarjoaa monipuolisemmin ominaisuuksia — AuthorizationPolicy HTTP-metodi- ja polkutasolla, liikenteen peilaus kanarianalyysiin, Lua-laajennuskoukut — mutta hinnaksi tulee suurempi monimutkaisuus ja laajempi hallintatason jalanjälki. Linkerdllä on merkittävästi pienempi hyökkäyspinta ja yksinkertaisempi operatiivinen malli, mikä tekee siitä houkuttelevan ohjelmille, joissa luotettavan laskenta-alustan minimointi on tärkeää. Valinta riippuu kunkin ohjelman ominaisuusvaatimuksista: jos tarvitaan polkukohtaista valtuutusta ja liikenteen peilausta, Iston monimutkaisuus on perusteltua; jos ensisijaiset vaatimukset ovat mTLS ja perushavaittavuus, Linkerdin yksinkertaisuus on parempi.

Hajautettu jäljitys latenssianalyysiin. C2-alustassa, jossa kutsuketjussa on seitsemän tai useampi palvelu, latenssiongelmia on lähes mahdotonta diagnosoida ilman hajautettua jäljitystä. Pyyntö, joka kestää 800 ms alusta loppuun, on voinut käyttää 600 ms tietokantakyselyyn maalien hallintapalvelussa ja vain 200 ms siirtoon ja käsittelyyn kuudessa muussa palvelussa. Ilman jäljitystä ainoa saatavilla oleva signaali on kokonaislatenssi — yksittäisten palvelujen osuudet ovat näkymättömissä. Jäljityksen avulla vesiputous näkyy Jaegerissa tai Tempossä: jokainen palveluspanni, sen kesto ja suhde kokonaispyyntöön ovat välittömästi näkyvissä.

Palveluverkko luo jäljitysspanneja automaattisesti jokaiselle välittämälleen kutsulle ilman sovelluskoodin instrumentointia. Sovellustason spannit (tietokantakyselyt, ulkoiset API-kutsut palvelun sisällä) vaativat nimenomaisen instrumentoinnin OpenTelemetry SDK:lla, mutta palvelujen välinen luuranko tulee palveluverkosta ilmaiseksi. Luokitelluissa ympäristöissä jäljityksen taustajärjestelmän (Jaeger, Tempo tai Zipkin) on ajettava akkreditoidun rajan sisällä — jäljitystieto sisältää palvelunnimiä, päätepisteiden polkuja ja ajoitustietoja, jotka voivat olla herkkiä luokitellulle C2-järjestelmälle.

Kubernetes-operaattorikuviot tilallisille puolustuskuormille

Kubernetes hoitaa tilattomat kuormat hyvin suoraan laatikosta — jos podi pettää, ReplicaSet-ohjain luo korvikkeen. Tilalliset kuormat vaativat kehittyneempää hallintaa: järjestys, jossa replikat käynnistyvät ja pysähtyvät, ratkaisee; tiedot on siirrettävä tallennustilaväleillä päivitysten aikana, ja päivitysjärjestyksen on säilytettävä tietojen yhteensopivuustakuut. Operaattorikuviocode tämän operatiivisen tiedon ohjaimeksi, joka ajetaan klusterissa.

Mukautetut resurssimääritykset C2-tilalle. Operaattori rakennetaan Custom Resource Definitionin (CRD) ympärille, joka ilmaisee hallittavan komponentin halutun tilan sovellusalueelle merkityksellisin termein. C2-maalivarastolle CRD voi määrittää replikamäärän, tallennusluokan, säilytyspolitiikan, replikointikertoimen ja vähimmäismäärän synkronoituja replikoita, jotka vaaditaan ennen kuin operaattori sallii päivityksen. Operaattorit tarjoavat deklaratiivisen rajapinnan infrastruktuuritiimeille: ne ilmoittavat haluamansa, ja operaattori määrittää, miten siihen päästään. Miten koodataan kerran operaattoriin, ei johdeta uudelleen jokaiselle käyttöölle.

Operaattorin sovituslooppi itseparantumiseen. Sovituslooppi on operaattorin ydin: se lukee hallittavan resurssin nykytilan, vertaa sitä CRD:n haluttuun tilaan ja toteuttaa vähimmäismäärän toimia konvergenssiin. Jos maalivaraston replikka on CrashLoopBackOff-tilassa, operaattori havaitsee poikkeaman ja aloittaa palautuksen — mahdollisesti käynnistäen replikan korvauksen, siirtymisen varareplikaan tai hälytyksen, joka vaatii ihmisen väliintulon sen mukaan, minkä palautuspolun operaattori on suunniteltu noudattamaan. Operaattori ajaa jatkuvasti, joten palautus alkaa sekunneissa vian havaitsemisesta sen sijaan, että ihminen huomaisi ja vastaisi.

Vierivä päivitys ilman tehtäväkatkoa. Tilallisen C2-komponentin päivittäminen elävässä järjestelmässä ilman tehtäväkatkoa vaatii tietyn järjestyksen: varmenna päivityksen kohde terveeksi ennen aloitusta, tyhjennä yksi replika kerrallaan, odota että korvike saavuttaa tunnetusti terveen tilan ennen seuraavan tyhjentämistä, ja keskeytä, jos terveystarkastukset epäonnistuvat missä tahansa vaiheessa. Kubernetes-operaattori koodaa tämän järjestyksen tilakoneeksi sovituslooppiin. Operaattori pakottaa vähimmäismäärän terveitä replikoita jokaisessa vaiheessa — se ei etene seuraavaan päivitysvaiheeseen, jos järjestelmä laskisi alle konfiguroidun vähimmäismäärän. Tämä on kriittinen etu suhteessa manuaalisiin päivityksiin: rajoitus toteutetaan klusterinopeudella ajalla olevalla koodilla, ei ihmisen mukana operatiivisen paineen alla noudattamalla tarkistuslistaa.

CI/CD-eristetty puolustus -putki, joka rakentaa ja allekirjoittaa operaattorikuvat, on yhtä tärkeä kuin operaattori itse — allekirjoittamattomasta, skannaamattomasta kuvasta käyttöönotettu operaattori on toimitusketjuriski luokitellussa ympäristössä.

Tapahtumavetoinen arkkitehtuuri sensorifuusiolle

Sensorifuusio — useiden sensorityyppien raporttien integrointi yhtenäiseksi kuvaksi toimintaympäristöstä — on yksi C2-alustan vaativimmista kuormista. Se on luonteeltaan tapahtumavetoinen: sensoriraportit saapuvat asynkronisesti, vaihtelevin taajuuksin, useista lähteistä samaan aikaan. Synkroninen pyyntö-vastaus-arkkitehtuuri on rakenteellisesti väärä tälle kuormalle. Tapahtumavetoinen arkkitehtuuri, jonka selkärankana on kestävä loki, on oikea valinta.

Kafkaan pohjautuvat tapahtumavirrat sensoridatalle. Apache Kafka (tai Apache Pulsar monivuokrauksessaan ja kerroksellisen tallennuksen ominaisuuksissaan) tarjoaa kestävän, jaetun lokin, johon sensorifuusioputki perustuu. Jokainen sensurityyppi julkaisee omaan aiheeseensa — tutkaraportit yhteen aiheeseen, elektroninen tiedustelu toiseen, kuvavihjeet kolmanteen. Maalien fuusiopalvelu tilaa kaikki asiaankuuluvat aiheet ja käsittelee raportit niiden saapuessa. Kafkan kuluttajaryhmämekanismi mahdollistaa fuusiopalvelun vaakasuuntaisen skaalauksen: jokainen replikka ottaa osion, joten suorituskyky skaalautuu replikamäärän mukaan. Kafkan kestävä loki tarkoittaa, että jos fuusiopalvelu on tilapäisesti käyttämätön — päivityksen tai solmun petämisen aikana — raportit kertyvät lokiin ja käsitellään järjestyksessä palvelun palautuessa, ilman menetyksiä.

CQRS-kuvio maalien tilan hallintaan. Command Query Responsibility Segregation -kuvio erottaa kirjoituspolun (komennot, jotka muuttavat tilaa) lukupolusta (kyselyt, jotka palauttavat tilaa). Maalien hallintapalvelussa kirjoituspolku käsittelee saapuvia sensoriraportteja ja operaattorikomentoja, päivittää virallista maalivarastoa ja liittää tapahtumia tapahtumalokiin. Lukupolku tarjoaa yhteisen toimintakuvan ja analyytikkoliittymät lukuoptymoidusta projektiosta — materialisoidusta näkymästä maalien tilasta, joka on optimoitu COP-kuluttajien käyttötapoihin, jotka poikkeavat sensorifuusion kirjoitusmalleista.

CQRS mahdollistaa lukupolun skaalauksen riippumatta kirjoituspolusta. Huippukuormatilanteessa, jossa sensoriraporttien määrä on suuri, kirjoituspolku skaalautuu vastaanottamaan kun taas lukupolku ylläpitää vakaata COP-latenssia operaattoreille. Lukupolku voi myös tarjota eri projektioita eri kuluttajille monimuttamatta kirjoituspolkua — COP-kuluttaaja saa viimeisimmän ensin suodatetun näkymän; analyysityökalu saa aikaikkunoitun näkymän, jossa on koko historia.

Tapahtumalähteinen tallennus tapahtumahistoriaksi. Tapahtumalähteinen tallennus laajentaa tapahtumavetoista kuviota pysyvyyteen: nykytilan tallentamisen ja jokaisen päivityksen ylikirjoittamisen sijaan järjestelmä tallentaa tapahtumajonon, joka tuotti nykytilan. Virallinen maalitietue johdetaan toistamalla tapahtumaloki. Tämä lähestymistapa tuottaa useita ominaisuuksia, jotka ovat arvokkaita puolustuksen akkreditointiyhteyksissä: jokaisen tilamuutoksen koko historia säilyy muuttumattomana; järjestelmän tila mihin tahansa menneeseen hetkeen voidaan rekonstruoida toistamalla tapahtumat siihen pisteeseen; ja akkreditointistandardien vaatima tapahtumahistoria on arkkitehtuurin suora tulos, ei erikseen ylläpidetty loki.

SRE elintärkeille puolustuspalveluille

Sivuston luotettavuuden suunnittelun käytännöt — SLO:t, virhebudjetit, rakenteellinen hälytyksenhallinta — pätevät puolustuksen C2-alustoihin, mutta toteutus on mukautettava luokiteltuun toimintaympäristöön, operatiivisen tempon rajoituksiin ja sovellusten seurausmalliin.

SLO- ja SLI-määrittely C2-palveluille. Kaupalliset SLO:t kehystetään tyypillisesti käyttäjäkokemuksen mittareiksi. C2-SLO:t on kehystettävä operatiivisten vaikutusten mittareiksi, jotka määritellään yhdessä operaattoreiden ja tehtävien suunnittelijoiden kanssa, jotka ymmärtävät, mitkä järjestelmän käyttäytymistavat vaikuttavat todella tehtävän tuloksiin. Edustavia SLO:ja C2-alustalle:

• Maalien päivitysviive: Maalien 95. prosenttipisteen ikä COP:lla ei saa ylittää 15 sekuntia. Mitataan erotuksena sensoriraportin aikaleiman ja sen hetken välillä, jona maalien päivitys näkyy COP:lla.
• Viestien toimitusaste: Komentoviestit on toimitettava alle 1 %:n menetyksellä minkä tahansa 30 minuutin ajanjakson aikana. Mitataan vahvistettujen toimitusten suhteena lähetettyihin viesteihin välityspalvelun rajapinnassa.
• Tulenkäyttöliittymän saatavuus: Tulenkoordinointiliittymän on oltava käytettävissä 99,9 %:ssa painotettuja ikkunoita julistettujen operatiivisten jaksojen aikana. Mitataan synteettisillä kokeilla, ei passiivisella pyyntöjen onnistumisasteella.
• Sensorien vastaanottoviive: Sensoriraportit on vastaanotettava ja kirjattava tapahtumalokiin 5 sekunnin kuluessa vastaanotosta 99. prosenttipisteessä. Mitataan verkkovastaanoton aikaleimasta vastaanottoyhdyskäytävässä Kafkan siirroskohdan vahvistusajoitukseen.

SLI-mittausta kannattaa käyttää palveluverkon telemetriaa aina kun mahdollista — palveluverkkotason mittarit ovat riippumattomia sovelluskoodista eivätkä ne voi paisua sovellustason virheistä, jotka alilaskuvat virheitä. Kun palveluverkon mittarit ovat riittämättömiä (esimerkiksi vanhenemisen mittaaminen vaatii sovellustason aikaleimoja, jotka eivät ole saatavilla välitystasolla), instrumentoi sovellus OpenTelemetrylla ja vie se klusterin sisäiseen Prometheus-yhteensopivaan taustajärjestelmään.

Virhebudjettipolitiikka. Virhebudjetti on SLO:n komplementti: jos maalien tuoreuden SLO on 99,5 %:n vaatimustenmukaisuus 30 päivän aikana, virhebudjetti on 0,5 % — noin 2 tuntia ja 10 minuuttia vaatimuksia vastaamattomia ikkunoita kuukaudessa. Kun budjetti on terve, insinööritiimit voivat ottaa käyttöön muutoksia ja hyväksyä laskettuja riskejä. Kun budjetti lähestyy loppuaan, politiikka siirtyy vakauteen: ei kiireellisiä käyttöönottoja, insinööriresurssit ohjataan luotettavuuden parantamiseen ja pakollinen tarkastelu budjetin loputtua. Puolustusohjelmien on kerrostettava operatiiviset ikkunat virhebudjettipolitiikkaan: jotkin jaksot julistetaan operatiivisiksi, ja budjetin kulutus niiden aikana kantaa korotettua hintaa riippumatta kumulatiivisesta saldosta.

Päivystyksen ohjekirjat. Luokiteltujen C2-järjestelmien ohjekirjojen on täytettävä korkeampi kynnys kuin kaupallisten ohjekirjojen. Niiden on oltava suoritettavissa päivystäjille, jotka eivät välttämättä ole palvelun alkuperäisiä suunnittelijoita, mihin tahansa kellonaikaan, operatiivisen paineen alla, käyttäen vain akkreditoidun rajan sisällä saatavilla olevia työkaluja. Jokaiseen ohjekirjaan tulisi sisältyä: oireesta diagnoosiin johtava kartoitus (mitkä hälytykset vastaavat mitäkin vikatilaa), täsmälliset ajettavat komennot (terveen tilan odotettu tuloste ja yleisten vikatapauksien virhetuloste), eskalointikontaktit turvallisuusluokkineen sekä odotetut palautusajat jokaiselle toimenpiteelle.

Hallittu heikkeneminen haastavissa olosuhteissa

Haastavat ympäristöt aiheuttavat vikatilanteita, joita ei esiinny varuskunnassa: tahallinen viestintälinkkien häirintä, GPS-kielto, joka vaikuttaa aikasynkronointiin, verkkoinfrastruktuurin fyysiset vauriot ja vastustajan aiheuttama kuormitus väärennetyillä sensoriraporteilla. Pilvinatiivin C2-alustan on heikennettävä hallitusti näissä kaikissa olosuhteissa — ylläpitäen korkeimman prioriteetin kyvykkyyksia niin kauan kuin mahdollista, määritellyllä ja testatulla käyttäytymisellä jokaisella heikkenemistasolla.

Piirikatkaisimet heikentyneelle liitettävyydelle. Piirikatkaisimet estävät hitaan tai pettäneen riippuvuuden leviämästä vikana kautta kutsuketjun. Iston palveluverkossa piirikatkaisimet konfiguroidaan DestinationRessä olevan OutlierDetection-resurssin kautta: määritä peräkkäisten virheiden kynnys, joka laukaisee piirikatkaisun, ulossulkemisväli ja perusulossulkuika. Kun palvelun virheaste ylittää kynnyksen, palveluverkko lopettaa kutsujen ohjauksen siihen ja palauttaa virheitä välittömästi jonottamisen sijaan. Tämä suojaa kutsujan latenssibudjettia — tulipalvelu ei odota 30 sekuntia maalikyselyn aikakatkaisua, se saa välittömän virheen ja palautuu välimuistin tilaan.

Välimuistista lukemisen varapalvelumallit. Kun yläpuolinen palvelu on käyttämätön, lukupainotteisia kuormia tarjoavat palvelut voivat palautua paikalliseen tai hajautettuun välimuistiin, joka sisältää viimeisimmän tunnetusti terveen tilan. Välimuistin varapalvelu on hyväksyttävissä vain, kun tiedon vanheneminen on rajoitettu ja tuotu esiin operaattoreille — COP, joka hiljaa tarjoaa 10 minuuttia vanhoja maaleja ilman ikää, on huonompi kuin COP, joka merkitsee maalit selvästi vanhentuneiksi. Toteuta varapalvelu nimenomaisella vastausotsikolla tai datakentällä, joka kertoo tiedon iän ja lähteen (live vs. välimuisti), jotta operaattoriliittymät voivat tuoda esiin heikkenemistilan sen peittämisen sijaan.

Offline-kykyinen progressiivinen palvelujen heikkeneminen. Täysi eristys — ei liitettävyyttä mihinkään yläpuoliseen palveluun — vaatii etukäteen sijoitettuja tietoja ja offline-kykyistä sovelluslogiikkaa. Suunnittele alustalle heikkenemismatriisi, joka määrittää, mitkä kyvykkyydet toimivat kussakin liitettävyyden tilassa: täysin liitetty (kaikki palvelut saavutettavissa), osittain liitetty (jotkin palvelut saavutettavissa, toiset eivät) ja täysin eristetty (ei ulkoista liitettävyyttä). Jokaisella matriisin kyvykkyydellä on oltava testattu toteutus heikentyneestä käyttäytymisestä — ei muistutus suunnittelutilastossa vaan testattu koodipolku, jota on harjoiteltu vikainjektiotestauksissa ennen operatiivista käyttöönottoa.

Osittain liitetty tapaus on vaikein suunnitella, koska saatavilla olevien palvelujen joukko on ennakoimaton — maalivarasto voi olla saavutettavissa mutta tiedustelutietojen integrointipalvelu ei, tai päinvastoin. Palvelut on suunniteltava toimimaan millä tahansa riippuvuuksien osajoukolla, joka on saatavilla, heikentyen sujuvasti yksittäisten riippuvuuksien petäessä sen sijaan, että vaadittaisiin kaikki-tai-ei-mitään-liitettävyyttä. Tämä vaatii nimenomaista riippuvuuksien luokittelua palvelutasolla: pakollinen (palvelu ei toimi ilman sitä), ensisijainen (palvelu toimii paremmin sen kanssa mutta voi heikentyä hallitusti ilman sitä) ja valinnainen (palvelu ohittaa sen käyttämättömyyden kokonaan).

Konttien turvallisuuden perustoihin, jotka tukevat tätä koko arkkitehtuuria — kuvien allekirjoitus, haavoittuvuuksien skannaus ja ajoaikainen politiikan toteutus — katso container image security defense. Pilvinatiivi arkkitehtuuri on yhtä turvallinen kuin sen ajamat kuvat; mikropalveluihin jakaminen moninkertaistaa konttien hyökkäyspinnan, jos kuvia ei vahvisteta ja skannata jatkuvasti.

Pilvinatiivi arkkitehtuuri puolustuksen C2- ja ISR-alustoille on merkittävä insinöörisijoitus: rajattujen kontekstien analyysi, palveluverkon käyttöönotto ja ylläpito, operaattorien kehitys, tapahtumavetoisen putken suunnittelu, SLO-määrittely operatiivisten sidosryhmien kanssa ja hallitun heikkenemisen testaaminen kaikki vaativat tietoista insinööripanosta, jota monoliittinen alusta ei vaadi. Tämän sijoituksen tuotto on alusta, jossa vika on paikallinen, päivitykset ovat itsenäisiä, skaalaus on elastinen ja heikkeneminen on suunniteltua eikä sattumanvaraista — ominaisuuksia, joista on tulossa neuvottelukelpoisia puolustusohjelmistolle, joka toimii haastavissa ympäristöissä.