Air-gap on tietokonejärjestelmän tai verkon fyysinen eristäminen suojaamattomista verkoista, mukaan lukien julkinen internet. Air-gapped-järjestelmillä ei ole langallisia tai langattomia yhteyksiä ulkoisiin verkkoihin; tiedonsiirto vaatii hyväksytyn tallennusmedian tai yksisuuntaisten tiedonsiirtolaitteiden fyysistä siirtämistä. Air-gapit ovat kaikkein arkaluonteisimpien luokiteltujen tietojärjestelmien perustavanlaatuisin turvallisuuden ohjaus: mikään ohjelmiston tietoturva ei voi korvata fyysistä verkkoyhteyttä, kun uhkamalliin kuuluu valtiollisia vastustajia, joilla on kehittyneitä offensiivisiä kyberkapasiteetteja.
Nykyaikaisen ohjelmiston käyttöönotto ja ylläpito air-gapped-järjestelmissä vaatii perustavanlaatuisesti erilaisen insinöörillisen lähestymistavan internet-yhteyksissä oleviin käyttöönottoihin verrattuna. Kehitystiimien luottamat mukavuusominaisuudet — automatisoidut paketinhallintajärjestelmät, jotka vetävät riippuvuuksia julkisista repositorioista, konttikuvat Docker Hubista tai julkisista rekistereistä, CI/CD-putket, jotka ulottuvat ulkoisiin SaaS-palveluihin, konfiguroinninhallintatyökalut, jotka kommunikoivat pilven ohjaustasojen kanssa — kaikki epäonnistuvat air-gapped-ympäristöissä. Ohjelmiston on toimittava ilman näitä yhteyksiä, ja kehitys- ja käyttöprosessi on suunniteltava tukemaan tätä alusta alkaen.
Mitä air-gap tarkoittaa ja missä sitä vaaditaan
Air-gapit vaaditaan kaikkialle, missä käsiteltävän datan luokitus tai arkaluonteisuus tai ohjattavien järjestelmien arkaluonteisuus oikeuttaa fyysisen verkkoeristyksen. Sotilaallisissa yhteyksissä:
Sensitive Compartmented Information Facilities (SCIFs) ovat fyysisesti suojattuja huoneita tai rakennuksia, joissa luokiteltua tietoa SECRET-tason yläpuolella — erityisesti SCI (Sensitive Compartmented Information) — voidaan käsitellä ja keskustella. SCI-tason dataa käsittelevät tietojärjestelmät SCIFissä on oltava air-gapped verkoista, joita ei ole akkreditoitu samalle luokitustasolle. SCIFin fyysinen turvallisuus (valvottu pääsy, äänenvaimennus, tietyissä tapauksissa sähkömagneettinen suojaus) yhdistettynä air-gapiin luo turvallisuusrajan.
Luokitellut operatiiviset verkot — SECRET tai korkeampi — ovat air-gapped luokittelemattomista verkoista. Tiedonsiirto luokitustasojen välillä vaatii Cross-Domain Solutionin (CDS): laitteisto-ohjelmistojärjestelmän, joka valvoo tiedonsiirtosääntöjä (sisällön tarkastus, formaatin validointi, yksisuuntaisen siirron valvonta) kahden verkkotason välillä. CDS itsessään on erikoistunut turvallisuustuote, joka on arvioitava ja hyväksyttävä kansallisen turvallisuusbehörigheten toimesta.
Asejärjestelmien ohjainsäätölaitteet ja sulautetut järjestelmät — tuliohjauksen tietokoneet, navigointijärjestelmät, tutka- ja anturiohjaimet — ovat air-gapped operatiivisista verkoista osana turvallisuusarkkitehtuuriaan. Näiden järjestelmien ohjelmistopäivitykset toimitetaan alustan ylläpitoliitynnän kautta, hyväksyttyjä mediaa käyttäen, seuraten dokumentoitua ja testattua menettelyä.
Ohjelmiston käyttöönotto ilman internetiä: Artefaktirekisterit ja pakettiapeilit
Air-gapped-ympäristössä jokaisen sovelluksen tarvitseman ohjelmistoriippuvuuden on oltava ympäristössä ennen käyttöönottoa. Mitään ei voida vetää internetistä käyttöönottoaikana. Tämä vaatii sisäisen artefaktieko-systeemin rakentamista, joka peilaa ulkoisia resursseja, joihin sovellus muuten luottaisi.
Harbor on CNCF-valmistunut avoimen lähdekoodin konttirekirsteri, ja se on vakiomuotoinen valinta sisäisille konttikuvarekistereille air-gapped-puolustusympäristöissä. Harbor tarjoaa: kuvan tallennuksen ja replikaation (kuvien jakamiseksi useisiin air-gapped-ympäristöihin yhdestä lähteestä), kuvan haavoittuvuustarkistuksen (Trivyn kautta), sisällön luottamuksen (kuvien digitaalinen allekirjoitusvarmennus) ja roolipohjaisen pääsynhallinnan. Harborin rekisterin täyttäminen vaatii prosessin esihyväksyttyjen, esiskannattujen konttikuvien tuomiseksi air-gapin ulkopuolelta hyväksyttyjä mediaa käyttäen.
Offline-pakettiapeilit replikoivat julkisia pakettirepositorioita air-gapin sisäiseen käyttöön. Pythonille sisäinen PyPI-peili (käyttäen työkaluja kuten bandersnatch tai devpi) palvelee pip-pyyntöjä ympäristöstä. npm:lle Nexus- tai Artifactory-instanssi (tai avoimen lähdekoodin Verdaccio) palvelee npm-pyyntöjä. Konttiperusskuville prosessi synkronoi hyväksytyt kuvat ulkoisesta rekisteristä sisäiseen Harbor-instanssiin. Pakettipeili on täytettävä ja pidettävä ajan tasalla hyväksytyn median siirtoprosessin kautta.
Riippuvuuksienhallinnan prosessin on oltava eksplisiittinen: ennen ominaisuuden kehittämistä, joka otetaan käyttöön air-gapped-ympäristössä, kehittäjän on eksplisiittisesti tunnistettava kaikki riippuvuudet (mukaan lukien transitiiviset riippuvuudet) ja varmistettava, että ne ovat läsnä sisäisessä peilissä. Uuden riippuvuuden lisääminen vaatii median siirtopyyntöä ja hyväksymisprosessia — yleensä sisältäen uuden paketin tietoturvatarkistuksen ennen sen myöntämistä air-gapped-ympäristöön. Tämä prosessi hidastaa kehitystä ja se on budjetoitava sprinttien suunnitteluun.
Korjausten hallinta: Testatut paketit ja muutosten hallinta
Air-gapped-ympäristöjen korjausten hallinta ei voi käyttää automatisoituja korjaustenhallinnan järjestelmiä, jotka vetävät päivityksiä toimittajien pilvipalveluista. Sen sijaan korjausten hallinta vaatii määritellyn, dokumentoidun prosessin korjausten tuomiseksi air-gapin ulkopuolelta sisälle, niiden testaamiseksi edustavassa ympäristössä ja niiden soveltamiseksi hallitusti.
Korjauspakettien valmistelu alkaa air-gapin ulkopuolella: korjaustenhallintatiiimi tunnistaa vaaditut korjaukset (toimittajien tietoturvatiedotteista, CISA Known Exploited Vulnerabilities -luettelosta ja STIG-päivityksistä), lataa ne toimittajien lähteistä, tarkistaa niiden aitouden (tarkistussumma ja digitaalinen allekirjoitusvarmennus) ja pakkaa ne siirtoa varten. Paketti tarkistetaan tietoturvatiimin toimesta ja hyväksytään siirrettäväksi hyväksytyn media-työnkulun kautta.
Siirto hyväksytyn irrotettavan median kautta on vakiomekanismi korjausten siirtämiseksi air-gapin yli. Hyväksytyn median menettelyt sisältävät yleensä: vain organisaation hallitseman median käytön (ei henkilökohtaisesti omistettuja USB-asemia), median virustarkistuksen air-gapin molemmilla puolilla, kirjoita kerran -median (optiset levyt) käyttämisen peruuttamattomille tarkistusketjuille, jokaisen siirron dokumentoinnin sisällöllä, päivämäärällä, hyväksyjällä ja käsittelijällä, sekä median tuhoamisen, joka on ylittänyt korkeammasta alempaan luokitusympäristöön luokituksen tuhoamismenettelyjen mukaisesti.
Vaiheistettu testaus on ei-neuvoteltavissa air-gapped-operatiivisille järjestelmille: korjaukset on testattava staging-ympäristössä, joka peilaa tuotantokonfiguraatiota, ennen kuin ne sovelletaan tuotantoon. Korjausta, joka destabilisoi air-gapped-tuotantojärjestelmän, ei voida palauttaa yksinkertaisesti vetämällä edellinen versio internet-lähteestä — paluumekanismin on myös oltava esiasemoitu ympäristössä.
Salaisuuksien kierto air-gapped-ympäristöissä
Salaisuudet — TLS-sertifikaatit, tietokantakredentiaalit, API-avaimet — vanhenevat ja niitä on kierrätettävä. Internet-yhteyksissä olevissa ympäristöissä salaisuuksien kierto on yhä enemmän automatisoitu: HashiCorp Vault luo ja kierrättää dynaamisia kredentiaaleja; sertifikaatinhallintatyökalut (cert-manager Kubernetesissa) uusivat automaattisesti TLS-sertifikaatit ACME:n kautta. Mikään näistä automatisoiduista mekanismeista ei toimi air-gapped-ympäristöissä, koska ne luottavat verkkoyhteyteen sertifikaattiviranomaisiin ja salaisuuksienhallinnan API:hin, joihin ei pääse air-gapin sisältä.
Hardware Security Modules (HSMs) tarjoavat kryptografisten toimintojen luottamuksen juuren air-gapped-luokitelluissa ympäristöissä. HSM (kuten Thales Luna tai nCipher nShield -laite) tallentaa yksityiset avaimet peukaloinninkestävään laitteistoon, suorittaa kryptografiset toiminnot paljastamatta avainmateriaalia, ja tarjoaa FIPS 140-2 Taso 3 tai Taso 4 validoidun tietoturvan — täyttäen luokiteltujen järjestelmien kryptografisten moduulien vaatimukset CNSSP No. 15:n mukaisesti.
Offline-holvin ja avainseremonian menettelyt määrittelevät, miten salaisuuksia kierrätetään ilman automatisoitua työkalustoa. Avainseremonia on muodollinen, dokumentoitu menettely — useilla valtuutetuilla henkilöillä läsnä — kryptografisten avainten generoimiseksi, lataamiseksi tai kierrättämiseksi. Seremonia tallennetaan yksityiskohtaisesti (kuka oli läsnä, mitä toimia tehtiin, missä järjestyksessä) tarkistusketjun tarjoamiseksi. TLS-sertifikaatin kierrätyksessä seremonia sisältää uuden sertifikaattipyynnön generoimisen, sen allekirjoittamisen offline-CA:n avaimella (tallennettu HSM:ään) ja uuden sertifikaatin jakelun kuluttaville järjestelmille hyväksyttyjä mediaa käyttäen.
CI/CD air-gapped-ympäristöille
Jatkuvat integraatio- ja käyttöönottoputket voivat toimia air-gapped-ympäristöissä oikeilla työkaluvalinnoilla. Putken infrastruktuurin on oltava täysin itsenäinen air-gapin sisällä, ilman pilvipalveluiden riippuvuuksia.
GitLab Community Edition paikallisesti käyttöönotettuna on vakio itse isännöity git ja CI/CD-alusta air-gapped-ympäristöille. GitLab CE tarjoaa git-repositorion isännöinnin, yhdistämispyyntötyönkulut, CI/CD-putken suorituksen (käyttäen samassa ympäristössä käyttöönnotettuja GitLab Runnereita), pakettirekirsterin (artefakteille) ja konttirekirsterin (Docker-kuville). Pilviyhteyttä ei tarvita — kaikki GitLabin toiminnallisuus on itsenäinen.
GitLab Runnerit on konfiguroitava pääsyllä sisäisiin pakettipeileihin (sisäiset PyPI-, npm-, Maven-peilit) eikä ulkoisiin pakettirepositorioihin. Putken vaiheet, jotka normaalisti kutsuisivat ulkoisia palveluja (konttihaavoittuvuustarkistus pilvi-API:en kautta, lisensointivahvistusta vaativat SAST-työkalut, ilmoituswebhookit) on uudelleenkonfiguroitava käyttämään sisäisiä vastaavia tai poistettava käytöstä.
Keskeinen havainto: Kallein virhe air-gapped-puolustusohjelmisto-ohjelmissa on suunnitella ohjelmisto internet-yhteyksissä olevaa käyttöönottoa varten ja yrittää mukauttaa se jälkikäteen air-gapped-toimintaan kehityssyklin loppuvaiheessa. Air-gap-yhteensopivuuden on oltava suunnitteluvaatimus päivästä yksi: ei pilvipalveluriippuvuuksia ydinsovelluksessa, kaikki riippuvuudet eksplisiittisesti luetteloidaan ja saatavilla sisäisissä peileissä, sekä käyttöönotto- ja käyttöprosessi suunniteltuna siirtötyönkulun ympärille alusta alkaen.