CI/CD-putkistot ilmavälin puolustusympäristöihin

Standardit CI/CD-putkistot on rakennettu olettaen, että kaikkialla on saatavilla ulospäin suuntautuva internet-yhteys. Jokainen ajoympäristö vetää pohjakuvan julkisesta rekisteristä, jokainen rakentaminen ratkaisee riippuvuudet ylävirtaisista pakettivarastoista ja jokainen skannaustyökalu lataa tuoreet haavoittuvuussignatuurit käynnistyksen yhteydessä. Luokitellussa, ilmavälin puolustusympäristössä mikään näistä oletuksista ei pidä — ja insinööritieteelliset seuraukset ulottuvat jokaiseen työketjun kerrokseen. Tämä opas kattaa arkkitehtuuriset päätökset, työkalustovalinnat ja operatiiviset menettelytavat, joiden avulla jatkuva integraatio ja toimitus toimivat ilman internet-yhteyttä, STIG-kovetetussa infrastruktuurissa, akkreditointirajan sisällä.

Miksi standardi CI/CD epäonnistuu ilmavälin puolustusympäristöissä

Vikamalli ei ole yksittäinen puuttuva ominaisuus — se on ketjureaktio oletuksista, jotka on leivottu jokaiseen moderniin CI/CD-työkaluun ja jotka hajoavat kosketuksessa ilmavälin akkreditointirajaan. Näiden vikamallien ymmärtäminen ennakolta estää turhat hankintajaksot ja viime hetken arkkitehtuurin peruutukset, kun ATO-arviointi alkaa.

Verkkoeristys. Luokiteltu enklaavi Secret-tasolla tai sitä ylempänä ei suunnitelmallisesti käytä ulospäin suuntautuvaa internet-yhteyttä. Ajoympäristöt eivät voi vetää kuvia Docker Hubista, Maven Centralista, npmjs.comista tai PyPI:stä. Rakennustyökalut, jotka lataavat laajennuksia tai lisäosia ensimmäisen käytön yhteydessä, epäonnistuvat äänettömästi tai tuottavat kryptisiä virheitä tavoittamattomista palvelimista. Päivitysmekanismit Jenkinsissä, GitLabissa ja useimmissa kaupallisissa CI-työkaluissa soittavat kotiin käynnistyksen yhteydessä — tämä liikenne estetään ja tuottaa usein hälyä verkon valvontakonsoliin, jonka ISSM:n täytyy selittää AO:lle.

Ohjelmiston hyväksyntä ja akkreditointi. Jokainen DoD:n akkreditointirajan sisällä käyttöön otettava ohjelmistokomponentti on hyväksyttävä Valtuuttavan viranomaisen (AO) toimesta osana järjestelmän valtuutuspakettia. Tähän kuuluu paitsi CI-palvelin, myös jokainen laajennus, jokainen rakennusagentin kuva ja jokainen kirjasto, josta putkisto itse riippuu. "Käytämme uusinta versiota julkisesta rekisteristä" ei ole hyväksyttävä vastaus ATO-kontekstissa. Hyväksyttyjen ohjelmistojen lista on hallittu asiakirja; uusien pakettien lisääminen edellyttää virallista pyyntöä, haavoittuvuusskannausta, lisenssiarvostelua ja — pakettien osalta, joilla ei ole olemassa olevaa STIG-kattavuutta — ylimääräistä dokumentointitaakkaa insinööritiimille. Tämä prosessi kestää tyypillisesti päivistä viikkoihin per paketti, mikä tekee ad-hoc-riippuvuuslisäyksistä yhteensopimattomia modernin CI-putkiston vaatiman kehitysvauhdin kanssa. Ratkaisu on ennakkorasittaa hyväksyntäprosessi tunnistamalla kaikki riippuvuudet ennen putkiston käyttöönottoa eikä sen jälkeen.

Työkalujen hankinta ja lisensointi. Osa CI-työkaluista on suoraviivaisesti saatavilla valtion urakoitsijoille. Osa edellyttää erityisiä lisensointisopimuksia julkishallintokäyttöön. Osa edellyttää vientivalvonnan arviointia (ITAR/EAR-luokittelu). Jenkins OSS ja GitLab CE välttävät suurimman osan näistä ongelmista, mikä osittain selittää niiden hallitsevan aseman luokitelluissa ympäristöissä. Kaupalliset CI-alustat, jotka niputtavat omat ajoympäristönsä, hallinnoidut salaisuuspalvelunsa tai pilvipohjaiset analytiikkapalvelunsa, eivät yleensä ole käyttökelpoisia ilmavälin enklaavin sisällä ilman merkittäviä arkkitehtuurisia muutoksia.

Lopputulos on, että ilmavälin CI/CD täytyy suunnitella ensiperiaatteista lähtien, ei mukauttaa kaupallisesta SaaS-mallista. Rakennuspalikat ovat saatavilla ja todistettuja — ne vaativat yksinkertaisesti eksplisiittisen offline-provisionoinnin jokaiselle komponentille, jonka standardi putkisto ratkaisi dynaamisesti. Laajempaa DevSecOps-kehystä, joka ohjaa näitä päätöksiä, käsitellään oppaassamme DevSecOps puolustuksen putkistoille.

Offline-artefaktirekisterin arkkitehtuuri

Artefaktirekisteri on toimitusketjun ankkuri ilmavälin rakennusympäristössä. Jokainen riippuvuus — JAR-tiedostot, npm-paketit, Python-pyörät, Go-moduulit, RPM:t — täytyy tarjoilla enklaavan sisältä. Kaksi tuotetta hallitsee tätä tilaa luokitelluissa ympäristöissä: Sonatype Nexus Repository (OSS ja Pro) ja JFrog Artifactory (OSS ja Pro). Molemmat ovat käyttöönotettavissa RHEL:llä ilman lähtevää verkkoyhteyttä; molemmat tukevat varastointiformaatteja, joita tyypillinen puolustuksen ohjelmistoprojekti tarvitsee.

Topologia koostuu kahdesta puoliskosta. Matalalla puolella (internet-yhteydellinen mutta ei luokiteltu) kuraattorin työasema ajaa samaa Nexus- tai Artifactory-versiota kuin korkean puolen instanssi. Kuraattori käyttää varastonhallintaohjelman sisäänrakennettua vienti-/tuontityökalua tai skriptattua työnkulkua hyväksyttyjen artefaktien lataamiseen, niiden transitiivisten riippuvuuksien ratkaisemiseen, tarkistussummien varmentamiseen ylävirtaisen rekisterin julkistamia tiivisteitä vastaan ja allekirjoitetun siirtopaketin kokoamiseen. Allekirjoitusvaihe on kriittinen: siirtopaketti on allekirjoitettava ohjelman siirtoavaimella, jotta korkean puolen järjestelmä voi varmentaa eheyden ennen minkään tuomista.

# Low-side curator: assemble and sign the transfer bundle
nexus-curator export \
  --format maven \
  --repos approved-central-proxy \
  --output /transfer/bundle-2026-06-24.tar.gz

# Generate SHA-256 manifest
sha256sum /transfer/bundle-2026-06-24.tar.gz \
  > /transfer/bundle-2026-06-24.manifest

# GPG-sign the manifest with the program transfer key
gpg --detach-sign --armor \
  --local-user transfer@program.mil \
  /transfer/bundle-2026-06-24.manifest

# Physical transfer via encrypted removable media or data diode
# ...

# High-side import: verify before extracting
gpg --verify bundle-2026-06-24.manifest.asc \
              bundle-2026-06-24.manifest
sha256sum -c bundle-2026-06-24.manifest
nexus-curator import --file bundle-2026-06-24.tar.gz
            

Korkealla puolella Nexus- tai Artifactory-instanssi tarjoaa vain isännöityjä varastoja — siellä ei ole proxy-varastoja, jotka osoittavat ulkoisiin URL-osoitteisiin, koska ne URL-osoitteet ovat tavoittamattomissa. Rakennusagentin työkalukonfiguraatiotiedostot viittaavat vain sisäiseen isäntänimeen. Taulukko konfiguraatiotiedostoista, jotka vaativat muokkauksen:

Kuraatiosykli on käytäntöpäätös: tyypillisesti kuukausittain tietoturvakorjauksille, neljännesvuosittain uusille riippuvuusversioille ja välittömästi haavoittuvuuden kohdalla, jonka CVSS-pistemäärä ylittää 8,0. Ohjelman konfiguraation ohjauslauta omistaa päätöksen jokaisesta tuonnista.

STIG-kovennettu CI-palvelin: Jenkins tai GitLab luokitellussa infrastruktuurissa

Kaksi yleisintä valintaa CI-suoritukseen luokitellussa infrastruktuurissa ovat Jenkins (pitkään hallitseva vaihtoehto, laajasti käytössä DoD-ohjelmissa 2010-luvun puolivälistä lähtien) ja GitLab (yhä enemmän suositaan uusissa ohjelmissa sen julkaistun DISA STIG:n ja integroitujen DevSecOps-ominaisuuksien ansiosta). Molemmat voidaan tehdä yhteensopiviksi; työmäärä ja jäljelle jäävä riskiprofiili eroavat.

Jenkinsin osalta koventamisen perustaso on DISA Application Server SRG yhdistettynä RHEL 9 STIG:iin pohjana olevalle käyttöjärjestelmälle. Jenkins-spesifinen koventamistarkistuslista kattaa seuraavat alueet:

• Poista käytöstä Jenkins CLI etäkäytön kautta (CVE-2024-23897-luokan haavoittuvuudet); käytä CLI:tä vain SSH:n kautta tarvittaessa.
• Ota käyttöön Content Security Policy (CSP) -otsikot XSS:n estämiseksi rakentamisen konsolin lähdössä.
• Poista skriptikonsolin käyttöoikeus ei-järjestelmänvalvojakäyttäjiltä; rajoita Groovy-hiekkalaatikosta pakeneminen.
• Konfiguroi matriisipohjainen tietoturva pienimmän oikeuden periaatteella: kehittäjät voivat käynnistää rakentamisia, mutta eivät voi hallinnoida agentteja tai tunnistetietoja.
• Ota käyttöön audit-log-laajennus; lähetä lokit enklaavan SIEM:iin.
• Aseta JENKINS_HOME tiedostojärjestelmälle, jossa on käyttöoikeusvalvonta; rajoita maailmanlaajuisesti luettavia oikeuksia tiedostosta credentials.xml.
• Poista käytöstä päivityspaikan yhteydet (hudson.model.UpdateCenter.never=true tiedostossa jenkins.properties).
• Aja Jenkins dedikoituna ei-root-palvelutilillä; sovella SELinux-konteksteja.

GitLab CE/EE RHEL:llä hyötyy DISA GitLab Enterprise Edition STIG:stä (V1R1, julkaistu 2022), joka kartoittaa kontrollit suoraan GitLab-konfiguraatioasetuksiin. Keskeisiä kontrolleja ovat TLS 1.2 -minimin pakottaminen, rekisteröitymisen ja OAuth-tarjoajien poistaminen käytöstä, kirjautumistapahtumien ottaminen käyttöön syslogiin, Git-protokollan rajoittaminen SSH:lle tunnetulla portilla ja auto-DevOps-ominaisuuksien poistaminen käytöstä ulkopäin soittamisesta. GitLabin integroitu rekisteri, merge request -työnkulku ja putkiston YAML-syntaksi vähentävät erillisesti akkreditoitujen komponenttien määrää verrattuna Jenkins-keskeiseen pinoon, mikä on usein ratkaiseva tekijä ohjelmissa, joissa ATO-aikataulut ovat tiukat.

Kummassakin tapauksessa rakennusagenttien on ajettava saman luokittelurajan sisällä kuin ohjaimen. Agentin kuvat rakennetaan enklaavan kontainerirekisterissä pidetyistä hyväksytyistä peruskuvista, ja ne rakennetaan uudelleen määritellyllä aikataululla (tyypillisesti kuukausittain) kuraatiotyönkulun kautta siirrettyjen käyttöjärjestelmän korjauspäivitysten sisällyttämiseksi.

Irrotettu kontainerirekisteri

Ilmavälin putkiston kontainerikuvat täytyy tallentaa, skannata ja allekirjoittaa enklaavan sisällä. Kaksi tuotetta on yleisimmät: Harbor (CNCF:n hyväksymä, laajasti käytössä DoD Platform One -ympäristöissä) ja Red Hat Quay (tuettu DoD:n yritys-Red Hat -sopimuksen puitteissa, integroituu tiiviisti OpenShiftin kanssa). Molemmat tukevat OCI-kuvan allekirjoittamista, roolipohjaista pääsynhallintaa ja haavoittuvuusskannausta offline-tietokannoilla.

Rekisterin alkuperäinen täyttäminen noudattaa samaa siirtotyönkulkua kuin artefaktirekisteri: hyväksytyt peruskuvat (RHEL UBI, kovennetut Iron Bank -kuvat, hyväksytyt sovelluksen peruskerrokset) viedään matalalta puolelta OCI-tarbaleina, siirretään ja tuodaan Harboriin tai Quayhin käyttäen skopeo copy:

# Low side: export approved images as OCI tarballs
skopeo copy \
  docker://registry.access.redhat.com/ubi9/ubi:9.4 \
  oci-archive:/transfer/ubi9-9.4.tar \
  --override-os linux

# Generate and sign manifest
sha256sum /transfer/ubi9-9.4.tar >> /transfer/images.manifest
gpg --detach-sign --armor --local-user transfer@program.mil \
    /transfer/images.manifest

# High side: verify and import
gpg --verify images.manifest.asc images.manifest
sha256sum -c images.manifest
skopeo copy \
  oci-archive:/transfer/ubi9-9.4.tar \
  docker://harbor.enclave.mil/base/ubi9:9.4 \
  --dest-creds admin:${HARBOR_TOKEN}
            

Kuvan allekirjoittaminen Cosignilla offline-tilassa käyttää enklaavan Vault Transit -moottorissa tallennettua pitkäikäistä allekirjoitusavainta, ohittaen Sigstore-läpinäkyvyysloki (joka on internet-isännöity). Allekirjoitusavain luodaan Vaultin sisällä eikä sitä koskaan viedä; CI-putkisto kutsuu Vaultin Transit-API:a kuvadigestin allekirjoittamiseen ja liittää tuloksena olevan allekirjoituksen OCI-artefaktina kuvan manifestin rinnalle Harborissa. Todentaminen pääsyn yhteydessä hoidetaan Kyverno-käytännöllä, joka kutsuu Cosign-varmistajaa Harboria vastaan enklaavan sisäistä PKI-luottamuspakettia käyttäen.

# Sign image using Vault Transit key (no transparency log)
cosign sign \
  --key hashivault://transit/keys/image-signing-key \
  --no-tlog-upload \
  harbor.enclave.mil/myapp/service:v1.4.2@sha256:abc123...

# Kyverno policy: require valid Cosign signature on every pod
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-image-signature
    match:
      resources:
        kinds: [Pod]
    verifyImages:
    - imageReferences: ["harbor.enclave.mil/*"]
      attestors:
      - entries:
        - keys:
            publicKeys: |-
              -----BEGIN PUBLIC KEY-----
              ... (enclave signing public key) ...
              -----END PUBLIC KEY-----
            rekor:
              ignoreTlog: true
            

Haavoittuvuusskannaus rekisterin sisällä käyttää Trivyä tai Grypeä, joka on konfiguroitu offline-tietokantapaketilla. Haavoittuvuustietokanta (NVD, OSV, RedHat-neuvot) ladataan matalalla puolella, siirretään korkealle puolelle ja ladataan skannerin paikalliseen tietokantapolkuun. Päivittäinen putkistotyö päivittää tietokantapaketin kuraatiotyönkulun kautta pitäen skannerin tietämyksen ajantasaisena siirtosyklin sisällä.

Ohjelmiston kuljetustyönkulku: lähiverkosta turvalliseen päivityspalvelimeen

Termi "lähiverkkokuletus" (sneakernet) on vanhempi kuin CI/CD, mutta konsepti on täsmälleen se, mikä saa ilmavälin ohjelmistotoimituksen toimimaan: tiedon fyysinen kuljetus eri luokitustasojen verkkojen välillä. Moderneissa luokitelluissa laitoksissa tämä kuljetus on systematisoitu dokumentoituun työnkulkuun, jossa on pakolliset portit, tarkastuspolut ja säilytysketjuvaatimukset, jotka peilaavat mitä automaattiset toimitusketjun kontrollit tarjoavat yhdistetyissä ympäristöissä. CI/CD-putkistojen haaste on, että kuljetussyklin aika — tyypillisesti mitattuna päivinä, ei millisekunteina — täytyy sisällyttää julkaisusuunnittelumalliin.

Työnkululla on määritelty rakenne:

Low-side workstation (UNCLASSIFIED)
    │
    ├─ [1] Assemble candidate package set
    │      - download, resolve transitive deps
    │      - verify upstream signatures/checksums
    │      - run malware scan (ClamAV / commercial AV)
    │      - run vulnerability scan (Grype offline db)
    │      - license review
    │
    ├─ [2] Generate signed manifest
    │      sha256sum * > manifest.txt
    │      gpg --detach-sign manifest.txt
    │
    ├─ [3] Submit transfer request (CMT/JIRA ticket)
    │      - package name, version, purpose, license
    │      - vulnerability scan results attached
    │
    ├─ [4] ISSO/AO review and approval (Gate)
    │
    ├─ [5] Physical transfer
    │      - encrypted USB (FIPS 140-2 validated)
    │      - OR hardware data diode (one-way)
    │      - transfer log entry created
    │
High-side secure update server (CLASSIFIED)
    │
    ├─ [6] Verify manifest signature
    │      gpg --verify manifest.txt.asc manifest.txt
    │      sha256sum -c manifest.txt
    │
    ├─ [7] Import into Nexus / Harbor
    │
    └─ [8] Log in configuration management tool
            

Paketin allekirjoittaminen käyttää joko GPG:tä ohjelmakohtaisilla avaimilla tai — ohjelmissa, jotka ovat ottaneet käyttöön PKI-pohjaisen työkalun — sigstore/cosignia ohjelman sisäistä Rekor-instanssia vastaan. Keskeinen kohta on, että siirtoilmoituksen allekirjoittamiseen käytettävä avain eroaa rakennusartefaktin allekirjoittamiseen käytettävästä avaimesta. Siirtoavainta pitää hallussaan kuraattorin rooli, ei automatisoidut rakennusagentit, koska siirron hyväksyntä on ihmisen suorittama portti, jota ei saa automatisoida.

Ohjelmille, jotka ajavat nopeatempoisia korjauspäivityssyklejä, yksisuuntaiset laitteistodatadiodit (kuten Owl Cyber Defenselta tai Waterfall Securityltä peräisin olevat) automatisoivat siirron fyysisen kerroksen säilyttäen samalla yksisuuntaisen takuun. Data virtaa vain matalalta korkealle; korkean puolen järjestelmä ei voi lähettää mitään liikennettä takaisin. Tämä ei poista hyväksyntäporttia, mutta poistaa fyysisen irrotettavan median vaiheen ja sitä voidaan käyttää yöllisten korjauspakettien lähettämiseen määritellyn aikataulun mukaisesti. Laajempaa käsittelyämme toimitusketjun tietoturvasta puolustuksen ohjelmistoille löydät käytäntökehyksestä, joka ohjaa mitä siirtotyönkulkuun syötetään.

STIG-vaatimustenmukaisuuden automatisointi putkistossa

Manuaaliset STIG-tarkistuslistat ovat yhteensopimattomia jatkuvan toimituksen vauhdin kanssa. Rakentaminen, joka otetaan käyttöön päivittäin, ei voi olla manuaalisesti tarkistettu yli 300 STIG-kontrollia vastaan ennen jokaista julkaisua. Ratkaisu on vaatimustenmukaisuus koodina: STIG-kontrollien koodaaminen koneellisesti tarkistettaviksi käytännöiksi, käytännön ajaminen putkistossa automaattisena porttina ja rakenteellisen todistusaineiston tuottaminen, joka täyttää AO:n jatkuvan valvonnan vaatimukset.

Ensisijainen työketju on OpenSCAP ja SCAP Security Guide (SSG). SSG toimittaa XCCDF/OVAL-sisältöä RHEL 8:lle, RHEL 9:lle ja siihen liittyville jakeluille, joka kartoittuu suoraan DISA STIG:eihin. Ilmavälin ympäristössä SSG-sisältö niputetaan rakennusagentin kuvaan lataamisen sijaan käytönaikana:

# Pipeline stage: STIG scan of a deliverable container image
stages:
  - build
  - stig-scan
  - sign
  - promote

stig-scan:
  stage: stig-scan
  image: harbor.enclave.mil/tools/openscap-runner:latest
  script:
    - |
      # Mount the container image filesystem for scanning
      skopeo copy \
        docker://harbor.enclave.mil/${CI_PROJECT_PATH}:${CI_COMMIT_SHA} \
        oci:./image-under-test

      # Run STIG profile evaluation
      oscap-chroot ./rootfs xccdf eval \
        --profile xccdf_org.ssgproject.content_profile_stig \
        --results stig-results.xml \
        --report stig-report.html \
        /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

      # Block on any CAT I (high severity) failures
      python3 /tools/parse-stig-results.py \
        --results stig-results.xml \
        --fail-on-severity high \
        --output stig-summary.json

  artifacts:
    paths:
      - stig-results.xml
      - stig-report.html
      - stig-summary.json
    expire_in: 90 days
            

DISA STIG Viewer -sovellus voi syöttää OpenSCAPista saadun results.xml-tulosteen ja näyttää sen tutussa tarkistuslistamuodossa, jota AO:t ja ISSO:t käyttävät arvostelujen aikana. Ohjelmille, jotka käyttävät jatkuvan valvonnan kojelautaa (tyypillisesti syöttää SIEM:iä tai GRC-työkalua), jäsennyskomentosarjan strukturoitu JSON-tuloste lähetetään todistevarastoon putkiston artefaktina rakentamisen rinnalle.

Yleinen malli on erottaa isäntätason STIG-skannaus (infrastruktuuritiimin ajama rakennusagentin peruskuvia vastaan kuukausittain) kuvatasoisesta STIG-skannauksesta (sovellusputkiston ajama jokaisessa rakentamisessa toimitettavaa kontaineria vastaan). Isäntätason havainnot vaikuttavat CI-infrastruktuurin itsensä ATO:han ja niitä seurataan järjestelmän POA&M:ssä. Kuvatasoiset havainnot seurataan sovellustasolla ja ne ovat kehitystiimin vastuulla. Tarkistuspolku selvästi erottaa minkä tiimin omistaa minkä havainnon, mikä on tärkeää, kun akkreditoija tarkastelee jatkuvan valvonnan todisteistopakettia.

Puolustuksen putkistojen SBOM-valvonnalle STIG-skannaustulos täydentää SBOM:ia tarjoamalla todistusaineistoa, että suoritusympäristö, jossa artefakti suoritetaan, on myös yhteensopiva — ei pelkästään artefaktin ohjelmistokomponentit.

Salaisuuksien hallinta ilman internetiä: HashiCorp Vault ilmavälitilaassa

Salaisuuksien hallinta on komponentti, joka todennäköisimmin improvisoidaan huonosti ilmavälin ympäristöissä. Yleinen improvisaatio — tunnistetietojen tallentaminen CI-palvelimen sisäänrakennettuun tunnistetietosäilöön, jaettuun salasananhallintatyökaluun tai ympäristömuuttujiin, jotka on leivottu agenttikuviin — epäonnistuu samoissa tarkastuskontrolleissa, jotka yhdistetty ympäristö epäonnistuisi. Hyväksytty ratkaisu on dedikoitu salaisuuksienhallinnan järjestelmä, joka on käyttöönotettu akkreditointirajan sisällä.

HashiCorp Vault OSS (avoimen lähdekoodin, ei Enterprise) ei vaadi internet-yhteyttä toimintaan. Se on käyttöönotettavissa STIG-kovennetulla RHEL-isännällä enklaavan sisällä, alustettuna Shamir-salaisuuden jakamisavainjaolla, joka on jaettu valtuutettujen avaimenhaltijoidenjoukossa:

# Initialize Vault with 5 key shares, threshold of 3
vault operator init \
  -key-shares=5 \
  -key-threshold=3

# Example output (each share goes to a separate custodian):
# Unseal Key 1: AbCdEf...
# Unseal Key 2: GhIjKl...
# Unseal Key 3: MnOpQr...
# Unseal Key 4: StUvWx...
# Unseal Key 5: YzAbCd...
# Initial Root Token: hvs.XXXXXX (use once, then revoke)

# Unseal using 3 of 5 shares (separate operator ceremony)
vault operator unseal  # enter share 1
vault operator unseal  # enter share 2
vault operator unseal  # enter share 3
            

PKI-käynnistys ilmavälin ympäristössä käyttää Vaultin sisäänrakennettua PKI-salaisuusmoottoria ohjelman sertifikaatti-infrastruktuurin hallintaan. Prosessi: luo root-CA-avain ja -sertifikaatti offline-tilassa (ilmavälin työasemalla, ei Vaultin sisällä), tallenna root-CA-avain laitteisto-HSM:ään tai salattuun offline-varmuuskopioon ohjelman avainten hallintasuunnitelman mukaisesti. Tuo root-CA-sertifikaatti Vaultiin. Vaultin PKI-moottorin sisällä luo väliaikaisen CA-avainparin ja CSR:n, allekirjoita CSR root-CA:lla (offline-vaihe), tuo allekirjoitettu väliaikainen sertifikaatti Vaultiin. Tästä eteenpäin Vault myöntää kaikki lyhytikäiset TLS-sertifikaatit enklaavan palveluille — CI-palvelimelle, artefaktirekisterille, kontainerirekisterille, salaisuuksienhallinnan järjestelmälle itsellensä — ilman ulkopuolista CA-riippuvuutta.

CI-agentin todennus käyttää Vaultin AppRole-todennusmenetelmää. Jokainen rakennusagentti provisioidaan role_id:llä (ei-salainen, voidaan sisällyttää agentin konfiguraatioon) ja secret_id:llä (lyhytikäinen, injektoi infrastruktuurin provisiointijärjestelmä agentin käynnistyksen yhteydessä). Agentti vaihtaa nämä Vault-tokeniksi, joka on rajattu vain rakentamiensa tarvitsemiin salaisuuksiin. Tokenit ovat lyhytikäisiä (1 tunti oletusarvo, uusittavissa rakentamisen aikana) ja vanhenevat automaattisesti rakentamisen valmistuttua. Tämä malli tarkoittaa, että vaarantuneella rakennusagentilla ei ole pysyvää pääsyä salaisuuksiin — se pitää hallussaan vain tokenia, joka vanhenee, ei tunnistetietoa, joka säilyy loputtomiin.

Salaisuuksien rotaatio ilman internet-yhteyttä noudattaa aikataulutettua seremoniaa: neljännesvuosittainen staattisinten salaisuuksien rotaatio (API-avaimet, palvelutilien salasanat), vuotuinen allekirjoitusavainten rotaatio. Vaultin sisäänrakennetut rotaatiokäytännöt hoitavat ajoituksen; jokaisen rotaation tulos kirjataan Vaultin tarkastuslokin, joka lähetetään enklaavan SIEM:iin. Dynaamisille salaisuuksille — tietokantatunnistetiedot, PKI-sertifikaatit — Vaultin dynaamisten salaisuuksien moottorit luovat per-rakentaminen -tunnistetiedot lyhyillä TTL-arvoilla, tehden rotaatiosta tapahtuma, koska jokainen tunnistieto on jo lyhytkestoinen.

Tämän pinon ajamiseen vaadittava operatiivinen kurinalaisuus on merkittävä. Kuraattorin roolit, siirron hyväksyntämenettelyt, avaimenhaltijan seremoniat ja kuukausittaiset skannauskadensit ovat organisaatiositoumuksia, ei kertaluonteisia insinööriratkaisuja. Ohjelmat, jotka investoivat näiden menettelyjen dokumentointiin osana järjestelmän tietoturvasuunnitelmaa (SSP) eikä epävirallisena heimotietona, ovat huomattavasti kestävämpiä henkilöstön vaihtuvuudelle — mikä turvallisuusselvitysten vaatimusten ja puolustuksen työmarkkinoiden vuoksi on realistinen operatiivinen riski jokaisessa pitkäkestoisessa ohjelmassa.

Toimitusketjun käytäntökerroksesta, joka ohjaa mitä putkistoon syötetään, katso artikkelimme SBOM-valvonnasta puolustuksen putkistoissa. Tässä kuvattu ilmavälin CI-pino on suorituskerros; SBOM-valvonta ja laajempi DevSecOps puolustuksen putkistoille -kehys ovat käytäntökerros, joka määrittää mitä putkisto rakentaa, skannaa ja todistaa.