Suvereeni pilvi puolustusministeriöille: tietojen sijainti, hallintatasot ja kansallinen pilviarkkitehtuuri

Tekijä Corvus Intelligence Engineering Team · Tietoa tiimistä →

25. kesäkuuta 2026 Päivitetty: 25. kesäkuuta 2026 12 min lukuaika

Jokainen puolustusministeriö, joka on siirtänyt kuormia pilveen, kohtaa lopulta saman jännitteen: kaupalliset hyperskaalaajat tarjoavat kykyjä – hallitut tietokannat, tekoäly- ja koneoppimisalustat, globaalin verkon – joita mikään kansallinen toimittaja ei pysty vastaamaan, mutta samat hyperskaalaajat ovat ulkomaisia yhtiöitä, jotka ovat kotivaltionsa oikeusprosessin, vientivalvonnan ja tiedusteluyhteisön käyttöpyyntöjen alaisia. Termi ”suvereeni pilvi” kuvaa yritystä ratkaista tämä jännite hyväksymättä kumpaakaan ääripäätä: ei täyttä hyperskaalaajariippuvuutta eikä teknologisesti jäädytettyä kansallista suurkonesalia. Syntyvä arkkitehtuuri ei ole koskaan yksinkertainen, eivätkä kompromissit ole harvoin ilmeisiä ennen kuin ne on jo tehty tuotannossa.

Tämä artikkeli tarkastelee suvereenin pilven teknistä arkkitehtuuria puolustusministeriöille – ei hankintalistan vaan insinööriongelman näkökulmasta. Käymme läpi, mitä suvereniteetti todella tarkoittaa kullakin kolmesta ulottuvuudestaan, miten suunnitellaan kansallinen hallintataso, joka kestää toimittajan häiriöt, mitkä hyperskaalaajakomponentit tuovat mukanaan hyväksymättömän suvereniteettiriskin, miltä avoimen lähdekoodin suvereeni pino näyttää tuotannossa ja miten suvereniteettirajoitteita tasapainotetaan nykyaikaisen maanpuolustuksen operatiivisten kykyvaatimusten kanssa. Laajemman näkymän kuormien tietoturvavaatimuksiin saat oppaastamme sotilaskuormien pilvitietoturva.

1. Mitä pilvisuvereniteetti tarkoittaa puolustusministeriölle

Toimittajat käyttävät termiä ”suvereeni pilvi” tarkoittamaan lähes mitä tahansa – maassa sijaitsevaa konesalia, sopimuspohjaista sitoumusta tietojen sijainnista, paikallista oikeushenkilöä – eikä yksikään toimittajamarkkinoinnin merkitys riitä vakavan puolustusministeriön arkkitehtuurikatselmointiin. Aito puolustuksen pilvisuvereniteetti kattaa kolme erillistä vaatimusta, jotka on arvioitava itsenäisesti, koska yhden toteuttaminen ei merkitse muiden toteutumista.

Tietojen sijainti on takeita siitä, että salainen tai arkaluontoinen data tallennetaan, käsitellään ja siirretään yksinomaan kansallisella alueella tai hyväksytyn lainkäyttöalueen sisällä – ja että ministeriö, ei pilvitoimittaja, hallitsee sitä suojaavia salausavaimia. Tietojen sijainti on eniten keskusteltu suvereniteettivaatimus ja helpoin väärentää: sopimussitoumus siitä, että data pysyy maassa, ei ole oikeudellisesti täytäntöönpanokelpoinen ulkomaisen valtion tiedusteluviranomaisen pyyntöä vastaan, eikä se anna teknistä suojaa väärin määritettyä replikointityötä vastaan, joka kopioi datan maan ulkopuoliseen käytettävyysalueeseen.

Operatiivinen suvereniteetti on kyky jatkaa pilvialustan käyttöä ilman minkään ulkomaisen toimittajan jatkuvaa yhteistyötä – mukaan lukien kyky selvitä toimittajan konkurssista, kaupallisista pakotteista, vientivalvonnan muutoksista tai ulkomaisen valtion toimittajalle määräämästä palvelun estämisestä tai heikentämisestä. Operatiivinen suvereniteetti edellyttää, että ministeriö pystyy operoimaan alustan jokaisesta komponentista pelkän dokumentaation ja lähdekoodin avulla, ilman jatkuvaa riippuvuutta omistusoikeudellisesta toimittajatuesta, joka voidaan peruuttaa.

Toimitusketjun suvereniteetti on hallintavalta pilven rakentamisessa ja käytössä käytettäviin ohjelmisto- ja laitteistokomponentteihin. Alusta, joka on rakennettu auditoitavaan avoimen lähdekoodin ohjelmistoon mutta ei-liittolaisen valmistajan palvelimille, ei täytä kumpaakaan ulottuvuutta: ohjelmistokerros voi olla auditoitava, mutta laitteiston laiteohjelmisto ei välttämättä ole. Täydellinen toimitusketjun suvereniteettianalyysi kattaa suorittimien laiteohjelmistot, verkkolaitteiden käyttöjärjestelmät, tallennusohjainten laiteohjelmistot ja suvereenin pinon jokaisen komponentin ohjelmistokirjastoriippuvuudet.

Useimmat puolustusministeriöiden nykyiset suvereenit pilviarkkitehtuurit toteuttavat tietojen sijainnin osittain, operatiivisen suvereniteetin osittain ja toimitusketjun suvereniteetin vain minimissään. Kolmen ulottuvuuden tekeminen nimenomaisiksi mahdollistaa rehellisen riskiarvioinnin sen sijaan, että annettaisiin väärien takeiden varassa toimiva ”suvereenin pilven” sertifiointi, joka käsittelee vain näkyvimmän ulottuvuuden.

2. Tietojen sijainnin valvonta

Tietojen sijainnin tekniset hallintakeinot toimivat kolmella kerroksella: salausavainten sijainnissa, datan sijaintikäytäntöjen pakottamisessa sekä auditoinnissa ja todentamisessa. Kaikki kolme vaaditaan; yksinään yksikään niistä ei riitä.

Salausavainten sijainti on tärkein tekninen hallintakeino, koska se määrittää, voidaanko dataa purkaa hyväksytyn alueen ulkopuolella, vaikka se varastettaisiin fyysisesti. Vaatimus on, ettei datan salausavaimia hallussaan pitävä laitteistoturvamoduuli (HSM) tai avainhallintapalvelu (KMS) saa sijaita muualla kuin kansallisella alueella eikä muussa operatiivisessa hallinnassa kuin ministeriön tai kansallisesti akkreditoidun organisaation – ei ulkomaisen pilvitoimittajan hallitsemassa KMS:ssä, jossa lopullinen avainmateriaali on toimittajan hallitsemassa laitteistossa. Käytännössä tämä tarkoittaa:

Paikallisesti sijoitettu HSM (Thales Luna, Utimaco SecurityServer tai vastaava) korkeimmille luokitustasoille, HSM fyysisesti suojattuna ja ministeriön fyysisen turvallisuuskäytännön mukaisesti auditoituna
Kansallisen pilvitoimittajan KMS, jonka tukena on maassa sijaitseva HSM-laitteisto, alemmille luokitustasoille, joilla hallitut avainpalvelut ovat hyväksyttäviä
Kirjekuorisalaus: datan salausavaimet (DEK) luodaan objekti- tai levykohtaisesti ja salataan HSM:ssä säilytettävillä avainten salausavaimilla (KEK) – HSM ei koskaan pidä raakadataa, vain avainmateriaalia
Avainten käyttölokitus, joka on erillinen ja riippumaton tallennusjärjestelmän auditointilokista, jotta luvattomat avainten käyttöyritykset näkyvät, vaikka tallennuskerros kompromettoituisi

Datan sijaintikäytäntöjen pakottaminen edellyttää, että tallennuspalvelut – objektitallennus, lohkolevyt, tietokantainstanssit – on rajoitettu maan sisäisiin käytettävyysalueisiin alustan määritystasolla, eikä vain politiikkalausuman tasolla. OpenStack-käyttöönotossa tämä tarkoittaa käytettävyysalueiden affiniteettisääntöjen määrittämistä Cinderiin ja Swiftiin niin, etteivät replikat päädy määritellyn alueen ulkopuolelle. Hyperskaalaajan käyttöönotossa tämä tarkoittaa palvelunhallintakäytäntöjen (AWS) tai Azure Policy -määritelmien käyttöä, jotka kieltävät minkään tallennusresurssin luonnin maan ulkopuolisilla alueilla, sovellettuna hallintatilin tai hallintaryhmän tasolla niin, etteivät yksittäiset kuormatiimit voi kumota niitä.

Auditointi ja todentaminen on jatkuva operatiivinen prosessi, joka vahvistaa tietojen sijainnin hallintakeinojen toimivan suunnitellusti. Auditointikerroksen on oltava riippumaton tallennuskerroksesta – taho, joka tallentaa dataa, ei voi olla ainoa taho, joka todentaa, missä data sijaitsee. Vaadittavat komponentit:

Automaattinen päivittäinen varmennus siitä, että kaikki kuormien käytössä olevat tallennuspäätepisteet ratkeavat maan sisäisiin IP-osoitteisiin, ja hälytys jokaisesta uudesta päätepisteestä
Verkkoliikenteen seuranta, joka merkitsee kaiken tallennuspalveluiden lähtevän liikenteen maan ulkopuolisiin IP-alueisiin
Neljännesvuosittainen kolmannen osapuolen tekninen auditointi tietojen sijainnin hallintakeinoista, havainnot raportoidaan ministeriön turvallisuusviranomaiselle
Määritykset koodina kaikille datan sijaintikäytännöille, versiohallittuna muuttumattomassa tietovarastossa, jotta käytäntömuutokset tuottavat havaittavan muutoksen ennen voimaantuloa

Sopimuspohjaiset hallintakeinot – tietojenkäsittelysopimukset, datan lokalisaatiolausekkeet – ovat välttämätön täydennys teknisiin keinoihin, mutta niitä ei saa koskaan käyttää ensisijaisena mekanismina. Sopimukset rajoittavat sitä, mitä yhteistyöhaluinen toimittaja tekee; ne eivät rajoita sitä, mitä toimittaja tekee kotivaltionsa laillisen pakon alaisena, eivätkä ne suojaa tekniseltä väärinkonfiguraatiolta.

3. Kansallisen hallintatason suunnittelu

Pilvialustan hallintataso – palvelujoukko, joka hallinnoi orkestrointia, identiteettejä ja salaisuuksia – on siellä, missä suurimman vaikutuksen suvereniteettiriski piilee. Kubernetes-ympäristössä hallintatason komponentit ovat API-palvelin, etcd-klusteri, ajastin, ohjainmanageri ja admission-webhookit, jotka pakottavat politiikkaa kuormien luontivaiheessa. Jos yksikään näistä komponenteista toimii infrastruktuurissa, jota ulkomaisen hyperskaalaajan operointihenkilöstö hallitsee, näillä henkilöillä on tekninen mahdollisuus (sopimuksella kielletysti) muuttaa kuormien määrityksiä, poimia salaisuuksia etcdestä tai häiritä ajastusta kotivaltionsa käskystä.

Kansallinen hallintatasosuunnittelu sijoittaa kaikki nämä komponentit infrastruktuuriin, joka on fyysisesti ja organisaation tasolla ministeriön hallinnassa. Käytännön arkkitehtuuri:

Kubernetes API -palvelin ja etcd. Ota käyttöön itse hallittu Kubernetes-jakelu – kubeadm maksimaaliseen joustavuuteen, k0s yksinkertaisempaan operointiin tai Talos Linux muuttumattoman käyttöjärjestelmän lähestymistapaan – bare metal -palvelimilla tai virtuaalikoneilla ministeriön hallitsemilla hypervisoreilla. Etcd-klusteri vaatii kolme tai viisi solmua kvorumiin erillisellä laitteistolla, jota ei jaeta kuormasolmujen kanssa. Etcd-data on salattava levossa KMS-tarjoajalisäosan kautta, joka on kytketty kansalliseen HSM:ään. Varmuuskopioi etcd-kuvakset salattuun maassa sijaitsevaan objektitallennukseen automaattisine palautustesteineen.

# Example kube-apiserver flag for national KMS encryption provider
--encryption-provider-config=/etc/kubernetes/encryption-config.yaml

# encryption-config.yaml (excerpt)
resources:
  - resources: [secrets, configmaps]
    providers:
      - kms:
          name: national-hsm-kms
          endpoint: unix:///var/run/kmsplugin/socket.sock
          cachesize: 1000
          timeout: 3s
      - identity: {}

Identiteettipalvelu. Keycloak on vakiintunut avoimen lähdekoodin OIDC/SAML-identiteettipalvelu suvereeleihin pilvikäyttöönottoihin. Ota Keycloak käyttöön erillisessä kansallisessa infrastruktuurissa, integroituna ministeriön olemassa olevaan hakemistoon (Active Directory tai LDAP Keycloakin federointiliittimien kautta). Määritä Kubernetesin API-palvelin käyttämään Keycloakia OIDC-todentajanaan:

# kube-apiserver OIDC flags
--oidc-issuer-url=https://keycloak.national.mil/realms/defense
--oidc-client-id=kubernetes
--oidc-username-claim=preferred_username
--oidc-groups-claim=groups
--oidc-ca-file=/etc/kubernetes/pki/keycloak-ca.crt

Keycloakin saatavuus on nyt kriittinen polku klusterin todennukselle. Ota se käyttöön korkean saatavuuden tilassa (vähintään kolme Keycloak-instanssia sisäisen kuormantasaajan taakse jaettuine välimuisteineen istuntotilaa varten) ja dokumentoi hätätoimenpide (break-glass) API-palvelimen käyttöön silloin, kun Keycloak ei ole käytettävissä – tyypillisesti paikallinen kubeconfig asiakasvarmenteella hätäpääsyyn klusterin ylläpitoon, säilytettynä fyysisesti suojatussa paikassa.

Salaisuuksien hallinta. HashiCorp Vault (tai sen avoimen lähdekoodin haarauma OpenBao) kansallisessa infrastruktuurissa tarjoaa salaisuuksien hallintakerroksen. Vault avautuu automaattisesti kansallisen HSM:n avulla, mikä poistaa manuaalisen avausvaiheen, joka muuten olisi yksittäinen vikapiste hallintatason palautuksessa. Vaultin auditointiloki – jokainen salaisuuden luku ja kirjoitus – siirretään reaaliajassa kansalliseen SIEM-järjestelmään, kompromittoidun Vault-käyttöönoton vaikutusalueen ulkopuolelle.

4. Hyperskaalaajariippuvuuksien arviointi

Useimmat puolustusministeriöiden pilviympäristöt käyttävät vähintään yhtä hyperskaalaajaa jossakin infrastruktuurin tasossaan – joko suvereenisti yhdistettyyn topologiaan, katastrofipalautusalueeseen tai vielä siirtämättömiin vanhoihin kuormiin. Ymmärrys siitä, mitkä hyperskaalaajakomponentit tuovat mukanaan suvereniteettiriskiä, on välttämätön kunkin komponentin hallittu vai itse operoitu -päätöksen tekemiseen.

Korkea suvereniteettiriski – korvattava tai operoitava itsenäisesti:

Hallitut Kubernetes-hallintatasot (EKS, AKS, GKE) – API-palvelinta ja etcdeä operoi hyperskaalaajan henkilöstö etuoikeutetulla pääsyllä; korvaa itse hallitulla Kubernetesilla IaaS-primitiivien päällä
Hallitut identiteettipalvelut (AWS IAM, Azure Active Directory ensisijaisena IdP:nä) – auktoritatiiviset identiteettiväitteet tekevät ulkomaisesti operoidut palvelut; korvaa Keycloakilla tai vastaavalla kansallisessa infrastruktuurissa
Hallitut salaisuusvarastot (AWS Secrets Manager, Azure Key Vault hyperskaalaajan hallitsemilla HSM-laitteilla) – avainmateriaali ulkomaisissa HSM-laitteissa; korvaa itse hallitulla Vaultilla kansallisen HSM:n päällä
Globaalit CDN- ja reunaverkot – liikenne reititetään maan ulkopuolisten paikallispisteiden kautta; poista käytöstä tai rajoita vain maan sisäisiin reunasolmuihin

Keskitason suvereniteettiriski – hyväksyttävissä lisähallintakeinoin:

Hyperskaalaajan objektitallennus maassa sijaitsevalla käytettävyysalueella – hyväksyttävä, jos se on salattu ministeriön hallitsemilla avaimilla kansallisesta HSM:stä ja replikointi on lukittu maan sisäisiin alueisiin
Hyperskaalaajan hallitut tietokannat maan sisäisillä alueilla – hyväksyttävät luokittelemattomalle datalle, jos salausavainten hallinta on kansallinen ja alueiden välinen replikointi on poistettu käytöstä
Hyperskaalaajan virtuaaliverkko – VPC:t, aliverkot ja turvaryhmät ovat matalan riskin IaaS-primitiivejä; suvereniteettiriski on niitä hallitsevassa hallintatasossa, ei primitiiveissä itsessään

Pienempi suvereniteettiriski:

IaaS-laskenta (virtuaalikoneet) ilman hallittuja agenttikehyksiä – hyperskaalaaja tarjoaa laitteiston; ministeriö operoi ohjelmistopinoa ja hallitsee kaikkea salausta
Lohkotallennus asiakkaan hallitsemilla avaimilla kansallisesta KMS:stä – hyperskaalaaja pitää hallussaan salattuja lohkoja, joita ei voi purkaa ilman ministeriön hallussa olevaa avainta

Arvioinnin lopputulos on komponenttitason riskikartta, eikä binäärinen ”käytä hyperskaalaajaa”- tai ”älä käytä hyperskaalaajaa”-päätös. Useimmat suvereenit pilviarkkitehtuurit säilyttävät joitakin hyperskaalaajakomponentteja IaaS-kerroksessa ja korvaavat hallintatason ja identiteettikomponentit kansallisilla vaihtoehdoilla. Laajemman näkymän käyttöönottomalleista ja niiden luokitusvaikutuksista saat artikkelistamme luokitellut pilvikäyttöönottomallit.

5. Arkkitehtuurimallit: suvereenisti yhdistetty vs. verkosta eristetty suvereeni

Suvereeleille pilvikäyttöönotoille on olemassa kaksi ensisijaista arkkitehtuurimallia, joiden kustannus-, kyky- ja operointikompleksisuusprofiilit eroavat huomattavasti toisistaan.

Suvereenisti yhdistetty topologia käyttää hyperskaalaajan maassa sijaitsevan konesalin käytettävyysaluetta IaaS-kerroksena, ja ministeriö operoi sen päällä omaa hallintatasoaan (Kubernetes, Keycloak, Vault) hyperskaalaajan laskenta- ja tallennusprimitiivien päällä. Hyperskaalaaja tarjoaa laitteiston uudistussyklit, konesalioperoinnin ja fyysisen turvallisuuden; ministeriö tarjoaa ohjelmistooperoinnin, salausavainten hallinnan ja kaikki hallintatason komponentit.

Tämä topologia antaa ministeriölle pääsyn hyperskaalaajan mittakaavaetuihin, laitteiston luotettavuuteen ja hallittuihin tallennus- ja tietokantapalveluihin (asianmukaisin hallintakeinoin) säilyttäen samalla operatiivisen suvereniteetin ohjelmistokerroksessa. Suvereniteettivaje jää fyysisen laitteiston kerrokseen: hyperskaalaajan konesaliteknikoilla on fyysinen pääsy palvelimiin, ja hyperskaalaajan toimitusketju määrää, mitä laitteistoa on saatavilla. Useimmille puolustusministeriöille, jotka eivät toimi korkeimman riskin uhkaympäristöissä, tämä on hyväksyttävä jäännösriski – edellyttäen, ettei salaus- ja hallintatasoarkkitehtuuri anna fyysisen laitteistopääsyn myöntää selkokielistä dataa tai hallintatason pääsyä.

Suvereenisti yhdistetty topologia mahdollistaa myös purskekapasiteetin: kun ministeriön kansallinen pilviinfrastruktuuri on täynnä, kuormia voidaan ohjata yli hyperskaalaajan maassa sijaitsevalle alueelle ylittämättä lainkäyttörajoja. Tästä seuraa, että se on käytännön valinta ministeriöille, joiden on täytettävä sekä suvereniteettivaatimukset että nykyaikaiset kykyvaatimukset ilman pääomamenoja, jotka kansallisen infrastruktuurin mitoittaminen huippukuormaa varten vaatisi.

Täysin kansallinen pilvi poistaa hyperskaalaajariippuvuuden kokonaan. Kaiken fyysisen infrastruktuurin – palvelimet, verkkolaitteet, tallennusjärjestelmät ja niitä majoittavan konesalin – hankkii, omistaa ja operoi ministeriö tai kansallisesti akkreditoitu organisaatio. OpenStack tarjoaa IaaS-kerroksen tämän laitteiston päälle; Ceph tarjoaa hajautetun tallennuksen; Kubernetes tarjoaa orkestroinnin.

Kompromissit ovat merkittäviä. Pääomamenot ovat selvästi korkeammat kuin suvereenisti yhdistetyssä topologiassa. Palvelinten ja verkkolaitteiden hankintasyklit ovat pitkiä – tyypillisesti 12-24 kuukautta vaatimuksesta operatiiviseen kykyyn. Laitteiston uudistaminen vaatii uusia hankintasyklejä. Operointihenkilöstön tarve on paljon suurempi: OpenStackin, Cephin, Kubernetesin ja Keycloakin tuotantokäyttö vaatii tiimin, jolla on syvä osaaminen kaikista neljästä komponentista, ja jonka kokoaminen on erittäin vaikeaa julkishallinnon palkkatasolla. Ja kykyero hyperskaalaajiin levenee ajan myötä, kun hyperskaalaajat investoivat voimakkaasti hallittuihin tekoäly- ja koneoppimis-, data-analytiikka- ja serverless-alustoihin.

Täysin kansallinen pilvi on oikea valinta korkeimmin luokitelluille kuormille, kuormille, joilla on tiukat eristysvaatimukset (air gap: ei fyysistä eikä verkkoyhteyttä kaupalliseen infrastruktuuriin) ja kyvyille, joissa toimitusketjun suvereniteetti laitteistotasolla on ehdoton vaatimus. Se ei ole oikea valinta modernin puolustusministeriön yleiselle kuormasalkulle – operointikompleksisuus ja kykyero ovat liian korkea hinta suvereniteettivaatimuksista, jotka hyvin suunniteltu suvereenisti yhdistetty topologia pystyy täyttämään.

6. Avoimen lähdekoodin suvereeni pino

Kanoninen avoimen lähdekoodin suvereeni puolustuksen pilvipino rakentuu neljälle komponentille, jotka yhdessä tarjoavat koko IaaS-, tallennus-, orkestrointi- ja identiteettialustan ilman omistusoikeudellisia riippuvuuksia ja täysin auditoitavan lähdekoodin kanssa.

OpenStack on IaaS-kerros: Nova laskentaan, Neutron virtuaaliverkkoon, Cinder lohkotallennukseen, Swift objektitallennukseen, Glance levykuvien hallintaan, Keystone palveluidentiteettiin ja -luetteloon. OpenStackilla on 15 vuoden tuotantohistoria tele-, julkishallinto- ja tieteellisen laskennan ympäristöissä. Operointikompleksisuus on todellinen – OpenStack-käyttöönotot vaativat omistetun alustatiimin ja huolellisen muutoshallinnan – mutta operaattorien, integraattorien ja dokumentaation ekosysteemi on kypsä. Kolla-Ansible-käyttöönottotyökalut tekevät ensikäyttöönotosta hallittavan; jatkuva operointihaaste on päivityshallinta, joka on suunniteltava huolella puolustusympäristössä, jossa muutoksenhallintaprosessit ovat hitaita.

Ceph on hajautettu tallennustausta. Se tarjoaa lohkotallennuksen (RBD) Cinder-levyille, objektitallennuksen (RGW) Swift-yhteensopiville rajapinnoille ja jaetun tiedostojärjestelmän (CephFS) kuormille, jotka vaativat POSIX-semantiikkaa. Cephin arkkitehtuuri jakaa datan kaikille klusterin solmuille säädettävine replikointikerroinne ja tarjoaa kestävyyttä yksittäisten solmujen tai levyjen vikaantumisia vastaan ilman omistusoikeudellisia tallennusjärjestelmiä. Operointikompleksisuus keskittyy suorituskyvyn viritykseen – Ceph vaatii huolellista laitteistovalintaa (NVMe SSD:t OSD-lokeille, suuren kaistanleveyden verkko solmujen välillä) ja jatkuvaa suorituskykyseurantaa välttääkseen ”hidas OSD” -sarjat, jotka voivat heikentää klusterin suorituskykyä raskaan kirjoituskuorman alla.

Keycloak on identiteettipalvelu. Se tukee OIDC:tä, SAML 2.0:aa, OAuth 2.0:aa ja LDAP/AD-federointia, mikä tekee siitä kaiken todennuksen integraatiopisteen suvereenissa pinossa: Kubernetes API -palvelimen todennus, OpenStack Keystonen identiteettifederointi, Vaultin JWT-todennus ja ihmiskäyttäjien todennus. Keycloakin hallintakäyttöliittymä ja REST-rajapinta tarjoavat operointityökalut käyttäjähallintaan, ryhmähallintaan ja asiakasohjelmien (sovellusten) rekisteröintiin. Korkean saatavuuden käyttöönottomalli – useita Keycloak-instansseja, jotka jakavat Infinispan-hajautetun välimuistin ja jaetun PostgreSQL-tietokannan – on hyvin dokumentoitu ja tuotannossa todennettu.

Kubernetes on konttien orkestrointikerros. Kubeadmilla tai Talos Linuxilla OpenStack Nova -laskentainstansseihin käyttöön otettuna Kubernetes tarjoaa kuormien ajastuksen, palveluhauan ja määrityshallintakerroksen, jonka sovellustiimit käyttävät. Suvereenin pinon keskeinen arkkitehtuurivaatimus on, että Kubernetes-jakelun on oltava upstream-yhteensopiva – ei hyperskaalaajan hallittu variantti – jotta hallintataso pysyy ministeriön hallinnassa. Konttiverkkoon Cilium on suositeltu CNI puolustusympäristöihin, koska sen eBPF-pohjainen politiikan pakkotus ja syvä havainnoitavuus eivät vaadi sivuvaunu-välityspalvelinta. Tallennusintegraatiossa Ceph CSI -ajuri tarjoaa yhteyden Kubernetesin PersistentVolumejen ja Ceph RBD:n välillä.

Tämän pinon operointikompleksisuutta ei saa aliarvioida. OpenStackin, Cephin, Kubernetesin ja Keycloakin tuotantokäyttö vaatii erikoisosaamista kaikista neljästä komponentista, jota on vaikea rekrytoida ja pitää julkishallinto-organisaatioissa. Realistisesti pinoa käyttöön ottava ministeriö tarvitsee joko suuren sisäisen alustatiimin (20+ insinööriä keskikokoiseen käyttöönottoon) tai sopimuksen tehneen suvereenin integraattorin, jolla on syvä osaaminen kaikista neljästä komponentista. Vaihtoehto – operointikompleksisuuden vähentäminen ottamalla jokin komponentti hyperskaalaajan hallittuna palveluna – on arvioitava sitä vasten, mitä suvereniteettivaatimuksia se heikentää. Tämän pinon päälle asennettavista tietoturvan hallintakeinoista saat artikkelistamme CSPM puolustuksen pilveen.

7. Suvereniteetin tasapainottaminen nykyaikaisten pilvikykyjen kanssa

Vaikein arkkitehtuuriongelma puolustusministeriön suvereenissa pilvessä eivät ole itse suvereniteetin hallintakeinot – vaan näiden keinojen ylläpitäminen samalla kun tarjotaan nykyaikaisia pilvikykyjä, joita puolustusorganisaatiot yhä enemmän vaativat: tekoäly- ja koneoppimismallien koulutus ja päättely, reaaliaikainen data-analytiikka, serverless-tapahtumalähtöiset arkkitehtuurit ja globaalit yhteistyöalustat. Hyperskaalaajat ovat investoineet miljardeja näiden kykyjen hallittuihin versioihin, joille avoimen lähdekoodin suvereeni pino ei pärjää vuosikymmenen aikajänteellä.

IaC-siirrettävyys Terraformin tarjoaja-abstraktion kautta on käytännöllisin mekanismi tämän jännitteen hallintaan. Strategia on määritellä kaikki infrastruktuuri tarjoajariippumattomina Terraform-moduuleina – sisäisinä abstraktioina, jotka vastaanottavat yhtenäiset syötteet ja tuottavat yhtenäiset lähdöt riippumatta siitä, onko alla oleva tarjoaja OpenStack, AWS vai Azure. ”Laskentaklusterin” moduulirajapinta on sama riippumatta siitä, otetaanko se käyttöön OpenStack Novalla vai AWS EC2:lla; vain tarjoajasidos muuttuu. Tämä abstraktio säilyttää vaihtoehdon siirtää kuormia suvereenin kansallisen pinon ja suvereenisti yhdistetyn hyperskaalaaja-alueen välillä ilman sovellusinfrastruktuurin uudelleenarkkitehtuuria.

# Example provider-agnostic compute module interface
module "compute_cluster" {
  source        = "internal/modules/compute-cluster"
  name          = "sensor-processing"
  instance_type = "c5.4xlarge"  # resolved per provider
  count         = 3
  subnet_id     = module.network.private_subnet_id
  security_groups = [module.security.workload_sg_id]
  user_data     = file("cloud-init/sensor-processor.yaml")
}

# Bind to provider via workspace variable
# terraform.tfvars.national:  provider = "openstack"
# terraform.tfvars.govcloud:  provider = "aws-govcloud"

Hallitut palveluvaihtoehdot strategisesti tärkeimpiin kykyaukkoihin:

Tekoälyn ja koneoppimisen koulutus: paikalliset GPU-klusterit, joilla ajetaan Kubeflow'ta tai MLflow'ta, hankittuina toimittajilta, joiden toimitusketjuasema on hyväksyttävä; suvereenisti yhdistetty purske hyperskaalaajan maassa sijaitseviin GPU-instansseihin koulutustöihin, jotka ylittävät paikallisen kapasiteetin
Data-analytiikka: Apache Spark Kubernetesissa (Spark-operaattorin kautta) korvaa hallitut analytiikkapalvelut; ClickHouse tai Apache Druid reaaliaikaisiin analyyttisiin kyselykuormiin
Hallitut tietokannat: PostgreSQL- (CloudNativePG), Redis- (Redis Operator) ja Kafka-operaattorit (Strimzi) tarjoavat hallittua palvelua muistuttavan operointikokemuksen itse hallitussa Kubernetesissa
Havainnoitavuus: Prometheus, Loki ja Grafana tarjoavat mittari-, loki- ja visualisointipinon ilman omistusoikeudellisia hallittuja havainnoitavuusriippuvuuksia

Suvereenin pilven kykytiekarttaa on käsiteltävä elävänä ohjelmana, eikä kertaluontoisena käyttöönottona. Kuilu suvereenin pinon kykyjen ja hyperskaalaajien hallittujen palveluiden välillä on todellinen mutta ei pysyvä – avoimen lähdekoodin ekosysteemi tuottaa jatkuvasti uusia suvereeineja vaihtoehtoja omistusoikeudellisille hallituille palveluille. Joka kuuden kuukauden välein tehtävä jäsennelty kykykatsaus – jossa nykyisiä suvereenin pinon kykyjä verrataan nykyisiin operatiivisiin vaatimuksiin ja nykyisiin hyperskaalaajavaihtoehtoihin – antaa ministeriölle mahdollisuuden priorisoida, mitkä aukot suljetaan avoimen lähdekoodin käyttöönotolla, mitkä suvereenisti yhdistetyn pääsyn kautta hyperskaalaajan maassa sijaitseviin palveluihin ja mitkä hyväksytään jäännöskykyrajoitteina vastineeksi suvereniteettitakuista.

Keskeinen oivallus: Suvereeni pilvi puolustusministeriöille ei ole tuote, jonka voi ostaa – se on arkkitehtuurinen asenne, joka on suunniteltava, rakennettava, operoitava ja ylläpidettävä jatkuvasti. Ministeriöt, jotka siinä onnistuvat, käsittelevät suvereniteettia ensisijaisena insinöörivaatimuksena suorituskyvyn, luotettavuuden ja kustannusten rinnalla, tekevät nimenomaisia kompromisseja suvereniteettiulottuvuuksien ja kyvykkyyden välillä ja rakentavat operatiivisen kyvyn ajaa suvereeni pino tuotantolaadulla. Ne, jotka käsittelevät sitä vaatimustenmukaisuuden rastiruutuna – hankkimalla ”suvereenin pilven” toimittajasertifikaatin arvioimatta, tuottavatko tekniset hallintakeinot todella tietojen sijainnin, operatiivisen suvereniteetin ja toimitusketjun suvereniteetin – löytävät kuilun vasta, kun geopoliittinen häiriö tai toimittajan politiikkamuutos paljastaa sen.

Suvereeni pilvi puolustusministeriöille on lopulta riskienhallintapäätös, eikä teknologiapäätös. Tässä kuvattu arkkitehtuuri – kansallinen hallintataso, tietojen sijainnin tekniset hallintakeinot, avoimen lähdekoodin suvereeni pino ja Terraformin tarjoaja-abstraktio siirrettävyyteen – on työkalujoukko tietyn riskijoukon hallintaan. Kullekin ministeriölle oikea arkkitehtuuri riippuu siitä, mitkä riskit ovat merkittävimpiä sen uhkaympäristössä, mitä operatiivista kykyä on realistisesti ylläpidettävissä käytettävissä olevalla henkilöstöllä ja budjetilla sekä siitä, mihin suvereniteetin ja kyvyn kompromissikäyrällä sen luokiteltujen kuormien vaatimukset osuvat. Sen kalibrointi oikein vaatii rehellisen uhka-arvioinnin ja insinööriharkinnan – eikä toimittajavakuutuksia.

Keskustele projektistasi

Suunnittelemme ja rakennamme suvereeineja pilviarkkitehtuureja puolustusministeriöille – kansallisen hallintatason käyttöönotosta ja tietojen sijainnin valvonnasta avoimen lähdekoodin pinon operointiin ja IaC-siirrettävyyteen.

Suojatun pilven palvelut → Varaa esittely

Tämän analyysin ovat laatineet Corvus Intelligencen insinöörit, jotka rakentavat tehtäväkriittisiä ohjelmistoja puolustus- ja valtionhallinnon organisaatioille. Tietoa tiimistä →

Usein kysytyt kysymykset

Mitä pilvisuvereniteetti tarkoittaa puolustusministeriölle?

Pilvisuvereniteetti puolustusministeriölle kattaa kolme erillistä mutta toisiinsa liittyvää vaatimusta. Tietojen sijainti on juridinen ja tekninen takuu siitä, että salainen tai arkaluontoinen data tallennetaan, käsitellään ja siirretään yksinomaan kansallisella alueella tai hyväksytyissä lainkäyttöalueissa – ja että ministeriö, ei toimittaja, hallitsee salausavaimia. Operatiivinen suvereniteetti on kyky jatkaa pilvialustan käyttöä riippumatta minkään ulkomaisen toimittajan jatkuvasta yhteistyöstä, lisensseistä tai palvelun saatavuudesta, mukaan lukien kyky selvitä pakotteista, toimittajan konkurssista tai geopoliittisista häiriöistä. Toimitusketjun suvereniteetti on hallintavalta pilven rakentamisessa ja käytössä olevista ohjelmisto- ja laitteistokomponenteista – se varmistaa, ettei mikään vieras valtio voi pakottaa toimittajaa asentamaan takaovia tai keskeyttämään palvelua. Aidosti suvereeni puolustuksen pilvi täytyy täyttää kaikki kolme ulottuvuutta samanaikaisesti; arkkitehtuuriratkaisut, jotka toteuttavat tietojen sijainnin mutta uhraavat operatiivisen tai toimitusketjun suvereniteetin, antavat heikomman suojan kuin paperilla näyttää.

Mitä tietojen sijainnin valvonta tarkoittaa puolustuksen pilvessä?

Tietojen sijainnin valvonta puolustuksen pilvessä tarkoittaa teknisten hallintakeinojen toteuttamista, jotka tekevät fyysisesti ja salausmenetelmin mahdottomaksi – eivät vain sopimuksella kielletyksi – datan poistumisen määritellyn maantieteellisen tai lainkäyttöalueen ulkopuolelle. Keskeiset kerrokset ovat: salausavainten sijainti (datan salausavaimet hallussaan pitävän HSM:n tai KMS:n on oltava fyysisesti maassa ja kansallisessa hallinnassa, joten näillä avaimilla salattua dataa ei voi purkaa alueen ulkopuolella, vaikka se varastettaisiin fyysisesti); tallennustasolla pakotetut datan sijaintikäytännöt (objektitallennus, lohkolevyt ja tietokantareplikat on rajoitettava maan sisäisiin käytettävyysalueisiin); verkon lähtevän liikenteen hallinta (palomuurisäännöt ja DNS-käytännöt, jotka estävät datapolut maan ulkopuolisiin päätepisteisiin); sekä auditointi ja todentaminen (jatkuva valvonta, ettei levossa ja siirrossa olevan datan hallintaa ole ohitettu, ja manipulointia estävät lokit, jotka ministeriön oma tietoturvaoperaatiotiimi tarkistaa toimittajan sijaan).

Mikä kansallinen hallintataso on ja miksi sillä on merkitystä?

Pilvialustan hallintataso on joukko palveluja, jotka hallinnoivat kuormien orkestrointia, identiteettejä ja salaisuuksia – Kubernetes-ympäristössä tämä on API-palvelin, etcd, ajastin ja ohjainmanageri; laajemmassa pilvikontekstissa siihen kuuluvat identiteettipalvelu, salaisuuksien hallintajärjestelmä ja hallinta-API:t. Jos hallintataso toimii ulkomaisen hyperskaalaajan hallinnoimassa infrastruktuurissa, hyperskaalaajan operointihenkilöstöllä on periaatteessa mahdollisuus muuttaa kuormien määrityksiä, poimia salaisuuksia tai häiritä toimintaa kotivaltionsa käskystä. Kansallinen hallintataso ajaa nämä komponentit infrastruktuurissa, joka on fyysisesti ja organisaation tasolla ministeriön hallinnassa, mikä poistaa tämän riippuvuuden. Silloinkin kun käytetään hyperskaalaajan maassa sijaitsevaa konesalia, kansallinen hallintataso tarkoittaa, että Kubernetesin API-palvelin, etcd-klusteri ja identiteettipalvelu toimivat ministeriön omistamalla tai ministeriön hallitsemalla laitteistolla, ja hyperskaalaaja tarjoaa vain laskenta-, verkko- ja tallennusprimitiivit.

Mitkä hyperskaalaajan komponentit aiheuttavat suurimman suvereniteettiriskin?

Suurimman riskin hyperskaalaajan komponentit puolustusministeriölle ovat: hallitut Kubernetes-hallintatasot (EKS, AKS, GKE), joissa API-palvelin ja etcd toimivat hyperskaalaajan infrastruktuurissa ja hyperskaalaajan operointihenkilöstöllä on etuoikeutettu pääsy; hallitut identiteettipalvelut, joissa auktoritatiivisen identiteettiväitteen tekee hyperskaalaajan hallitsema palvelu; globaalit CDN- ja reunavälimuistikerrokset, jotka reitittävät liikenteen maan ulkopuolisten paikallispisteiden kautta; alueiden väliset replikointiominaisuudet, jotka saattavat kopioida dataa hyväksytyn lainkäyttöalueen ulkopuolisiin käytettävyysalueisiin; ja hallitut salaisuusvarastot, joiden avainmateriaali on lopulta hyperskaalaajan hallitsemissa HSM-laitteissa. Hyperskaalaajan IaaS-komponentit – raaka laskenta, lohkotallennus ja virtuaaliverkko ilman hallittua hallintatasoa – aiheuttavat selvästi pienemmän suvereniteettiriskin, koska ministeriö ajaa niiden päällä olevan ohjelmistopinon itse ja hallitsee kaikkia salausavaimia itsenäisesti.

Mitä eroa on suvereenisti yhdistetyllä ja täysin kansallisella pilvellä?

Suvereenisti yhdistetty topologia käyttää hyperskaalaajan maassa sijaitsevaa konesalia, jonka päällä toimii ministeriön hallitsema hallintataso. Hyperskaalaaja tarjoaa IaaS:n – laskennan, tallennuksen, verkon – mutta kaikki orkestrointi-, identiteetti- ja salaisuudenhallintakerrokset operoi ministeriö tai luotettu kansallinen integraattori. Tämä antaa pääsyn hyperskaalaajan mittakaavaetuihin ja hallittuihin palveluihin hinnalla jatkuvasta riippuvuudesta hyperskaalaajan laitteistooperoinnista ja toimitusketjusta. Täysin kansallinen pilvi poistaa hyperskaalaajariippuvuuden kokonaan – kaikki fyysinen infrastruktuuri hankitaan, omistetaan ja operoidaan ministeriössä tai kansallisella suvereenilla toimittajalla. Vastineeksi tulevat selvästi korkeammat pääomamenot, pidemmät hankintasyklit, suurempi operointikompleksisuus ja kykyero hyperskaalaajien hallittuihin palveluihin nähden – mutta maksimaalinen operatiivinen ja toimitusketjun suvereniteetti.

Mitkä avoimen lähdekoodin komponentit muodostavat suvereenin pilvipinon ytimen?

Kanoninen avoimen lähdekoodin suvereeni pilvipino koostuu seuraavista: OpenStack IaaS-kerroksena (laskenta Novalla, objektitallennus Swiftillä, lohkotallennus Cinderillä, verkko Neutronilla, levykuvien hallinta Glansella, identiteetti Keystonella); Ceph hajautettuna tallennuskerroksena, joka tukee OpenStackin Cinder-lohkolevyjä ja Swift-objektitallennusta; Kubernetes konttien orkestrointikerroksena, joka otetaan käyttöön upstream-jakelulla (ei hyperskaalaajan hallitulla variantilla), jotta API-palvelin ja etcd pysyvät ministeriön hallinnassa; ja Keycloak identiteettipalveluna sekä ihmisille (OpenID Connectilla ja SAML:lla) että kuormille (OAuth 2.0 -asiakastunnuksilla). Yhdessä nämä neljä komponenttia tarjoavat koko pilvialustapinon ilman omistusoikeudellisia riippuvuuksia. Operointikompleksisuus on huomattavasti korkeampi kuin hallittuja hyperskaalaajapalveluita käytettäessä, ja ministeriön on ylläpidettävä osaamista jokaisen komponentin operointiin ja paikkaamiseen – mutta suvereniteettitakuut ovat absoluuttiset, koska jokaisen komponentin lähdekoodi on auditointikelpoinen eikä millään ulkomaisella toimittajalla ole etuoikeutettua operointipääsyä.

Miten Terraform tukee siirrettävyyttä suvereenien pilviympäristöjen välillä?

Terraformin tarjoaja-abstraktio mahdollistaa infrastruktuurin kuvaamisen tarjoajariippumattomina moduuleina, joissa tarjoajakohtaiset toteutukset vaihdetaan juurimoduulin tasolla. Suvereenin pilven siirrettävyysmalli määrittelee sisäiset moduulirajapinnat – laskentaklusterimoduuli, hallittu tietokantamoduuli, objektitallennusämpärin moduuli – jotka vastaanottavat samat syötteet ja tuottavat samat lähdöt riippumatta siitä, onko alla oleva tarjoaja OpenStack-käyttöönotto, kansallinen pilvitoimittaja vai hyperskaalaajan maassa sijaitseva alue. Kun ministeriön on siirryttävä yhdestä alustasta toiseen toimittajariskin, sääntelymuutoksen tai kykyjen kehityksen vuoksi, vain tarjoajasidos muuttuu – kuormamoduulien määritykset, julkaisuputket ja infrastruktuuritestit pysyvät ennallaan. Tämän siirrettävyyden käytännön raja on hallitut palvelut: moduulia, joka kietoo ympärilleen hyperskaalaajakohtaisen hallitun tietokantapalvelun, ei voi siirtää suoraviivaisesti OpenStackiin korvaamatta alla olevaa palvelua vastaavalla itse hallitulla käyttöönotolla.

Mitkä ovat suvereenin pilven keskeiset riskit puolustusministeriölle?

Ensisijaiset riskit ovat: kykyero (kansalliset pilvitoimittajat ja avoimen lähdekoodin pinot jäävät usein hyperskaalaajista vuosia jälkeen hallituissa tekoäly- ja koneoppimispalveluissa, serverless-alustoissa ja globaalissa verkkosuorituskyvyssä – tämä rajoittaa nykyaikaisten kykyjen tiekarttaa); operointikompleksisuus (OpenStackin, Cephin, Kubernetesin ja Keycloakin sisäinen ylläpito vaatii syvää osaamista, jota on vaikea rekrytoida ja pitää julkishallinnossa); laitteiston toimitusketjuriski (ei-kansallisilta toimittajilta hankitut palvelimet, verkkolaitteet ja tallennuslaitteisto kantavat omia toimitusketjun suvereniteettiriskejään – täysin kansallinenkin pilvi voidaan kompromittaa laitteistotasolla); ja väärä suvereniteetti (pilvi, joka täyttää tietojen sijainnin vaatimuksen paperilla mutta jossa hyperskaalaajan operointihenkilöstöllä on etuoikeutettu pääsy tai joka käyttää ulkomaisia HSM-laitteita avainten hallintaan, antaa heikompia takeita kuin sen arkkitehtuuridokumentaatio antaa ymmärtää). Riskien hallinta vaatii suvereniteetin käsittelyä spektrinä, jonka ulottuvuudet voidaan todentaa toisistaan riippumatta, eikä binäärisenä sertifiointina.

Miten luokitellut ja luokittelemattomat kuormat erotetaan toisistaan suvereenissa pilvessä?

Luokitellut ja luokittelemattomat kuormat on erotettava fyysisellä tasolla – erilliset Kubernetes-klusterit erillisissä solmuvarannoissa ilman yhteistä etcdeä, yhteistä hallintatasoa tai yhteistä verkko-infrastruktuuria luokitustasojen välillä. Looginen erottelu yhden klusterin sisällä (namespace-eristys, NetworkPolicy) ei riitä eri luokitustasoilla toimiville kuormille, koska hallintatason haavoittuvuus tai kontin karkaaminen voi ylittää namespace-rajat. Käytännössä tämä tarkoittaa erillisiä OpenStack-vuokralaisia fyysisesti erillisillä Ceph-tallennusklustereilla kullekin luokitustasolle, erillisiä Keycloak-realmeja tai kokonaan erillisiä identiteettipalveluita sekä erillisiä CI/CD-putkia erillisillä allekirjoitusavaimilla, jotta luokittelemattoman käännösputken kompromittoituminen ei voi työntää haitallisia levykuvia luokitellulle tasolle. Tasojen välinen datan siirto on kuljettava muodollisesti arvioidun cross-domain-ratkaisun kautta, ei verkkoyhteyden kautta.

Millainen puolustusministeriön suvereenin pilven kykytiekartan tulisi olla?

Realistinen suvereenin pilven kykytiekartta puolustusministeriölle jakautuu kolmeen vaiheeseen. Vaihe 1 (vuodet 1-2) rakentaa perustan: otetaan käyttöön kansallinen IaaS-kerros (OpenStack tai vastaava), siirretään kuormat kaupallisesta pilvestä maassa sijaitsevaan infrastruktuuriin, toteutetaan tietojen sijainnin hallinta ja kansallinen avainhallinta sekä otetaan käyttöön kansallinen Kubernetes-hallintataso. Vaihe 2 (vuodet 2-4) rakentaa alustakerroksen: otetaan käyttöön Keycloak federoitua identiteettiä varten, toteutetaan Terraform-pohjainen IaC tarjoaja-abstraktiolla, rakennetaan sisäinen konttirekisteri toimitusketjun hallinnalla (levykuvien allekirjoitus, haavoittuvuusskannaus) ja perustetaan suvereenisti yhdistetty topologia hyperskaalaajan maassa sijaitsevalta alueelta purske- ja vikasietokykyä varten. Vaihe 3 (vuodet 4+) tähtää kykyjen tasaveroon: rakennetaan tai hankitaan suvereegeja hallittuja tietokanta- ja analytiikkapalveluita, otetaan käyttöön paikallinen tekoäly- ja koneoppimiskoulutuksen infrastruktuuri, toteutetaan zero trust -arkkitehtuuri kaikilla tasoilla ja perustetaan jatkuvan vaatimustenmukaisuuden automaation viitekehys, joka kattaa suvereenin pinon kaikki komponentit.