Cross-domain-ratkaisun arkkitehtuuri luokiteltuihin sotilasverkkoihin

Kirjoittanut Corvus Intelligence Engineering Team · Tietoa tiimistä →

24. kesäkuuta 2026 12 min lukuaika

Kun sotilastietojärjestelmän täytyy siirtää dataa SECRET-verkosta UNCLASSIFIED-verkkoon — tai TOP SECRET -kompartmentoidusta ympäristöstä koalition partneriverkkoon — liikennettä ei voi yksinkertaisesti reitittää tavallisen palomuurin kautta. Luokittelun raja ei ole pääsynhallintaongelma, jonka voisi ratkaista verkkopolitiikalla. Se on sisällön eheysongelma: itse tieto voi sisältää merkintöjä, kompartmentteja tai upotettuja dataelementtejä, joita ei saa poistaa korkeamman luokittelun enklaavista. Tähän tarkoitukseen suunniteltu mekanismi on cross-domain-ratkaisu, ja sen oikea suunnittelu edellyttää gaardiarkkitehtuurin, sisältösuodatuslogiikan, merkintästandardien ja valtion akkreditointiprosessin ymmärtämistä — prosessin, joka vie tyypillisesti kauemmin kuin itse suojattava sovellus.

Tässä artikkelissa selitetään, miten CDS-gaardit toimivat sisältä päin — viitevalvontamalli, joka on jokaisen hyväksytyn tuotteen perustana, suodatinsääntölogiikka, jolla CAPCO-merkintöjen valvonta toteutetaan, protokollakohtaiset tarkastustekniikat XML- ja SMTP-putkille sekä NSA:n akkreditointipolku, joka määrittää, onko käyttöönotto laillisesti hyväksytty toimimaan. Artikkeli on kirjoitettu insinööreille ja ohjelmapäälliköille, jotka tarvitsevat rajoitusten ymmärtämistä ennen arkkitehtuurista sitoutumista.

Mitä on cross-domain-ratkaisu ja milloin se vaaditaan

Cross-domain-ratkaisu on tuote tai järjestelmä, joka valvoo tietoturvapolitiikkaa, kun dataa liikkuu eri luokittelutasoilla akkreditoitujen verkkojen välillä tai yhteensopimattomien pääsynhallintamekanismien välillä. Termi kattaa laitteistodatadiodit, ohjelmistopohjaiset kaksisuuntaiset gaardit sekä niiden yhdistelmät. Se, mikä erottaa CDS:n tavallisesta verkkoyhyhdyskäytävästä, on se, että se toimii sisältötasolla eikä pakettitasolla — se tarkastaa hyötykuormat, lukee luokittelumerkinnät, soveltaa jäsenneltyjä suodatinsääntöjä ja tekee salli/hylkää-päätöksen jokaiselle dataerällä erikseen.

CDS vaaditaan aina, kun kaksi ehtoa täyttyvät samanaikaisesti: lähdeverkko sisältää tietoa korkeammalla luokittelutasolla kuin kohdeverkko on akkreditoitu vastaanottamaan, ja operatiivinen vaatimus on siirtää osa — mutta ei kaikki — tiedosta alempaan verkkoon. Jos korkealta matalalle ei pitäisi koskaan siirtyä mitään, fyysinen eristys (air gap) on halvempi ja turvallisempi ratkaisu. Jos kaikki korkean puolen tieto voidaan siirtää matalalle puolelle, verkot pitäisi yhdistää tai kohdeverkko uudelleenakkreditoida. Valikoiva siirto on tapaus, joka edellyttää CDS:ää.

Yleisiä tilanteita, joissa CDS on pakollinen puolustusohjelmissa: puhdistetun seurantadatan siirtäminen SECRET-yhteisoperatiivisesta kuvasta (COP) UNCLASSIFIED-koalitionäyttöön; julkaistavien tiedustelutuotteiden julkaiseminen TS/SCI-analyysistä SECRET-jakeluverkkoon; sensoridatan syöttäminen luokitellulta keräysalustalta luokittelemattomaan arkistoon pitkäaikaiseen säilytykseen; sekä kansallisen tiedusteluverkon yhdistäminen NATO-akkreditoituun yhteisverkkoon, jossa luokittelujärjestelmät eroavat toisistaan. Kaikissa tapauksissa CDS on rajan valvontamekanismi — ja sen akkreditointi antaa yhteyden myöntävälle viranomaiselle varmuuden siitä, että rajaa valvotaan oikein.

Vaihtoehto CDS:lle joissain rajoitetuissa tilanteissa on manuaalinen tarkastus: ihminen lukee asiakirjan, toteaa sen olevan julkaistavissa ja kirjoittaa tai luonnostelee sisällön uudelleen matalammassa verkossa. Tämä on alkuperäinen cross-domain-"ratkaisu" ja on edelleen käytössä pienivolyymisissa, erittäin arkaluonteisissa siirroissa, joissa automaattiseen suodatukseen ei voida luottaa kaiken arkaluonteisen sisällön havaitsemisessa. Automaattiset CDS-tuotteet sopivat vain silloin, kun sisältö on riittävän jäsenneltyä (merkittyä XML:ää, SMTP:tä luokitteluotsakkeilla, hyvin määriteltyjä viestimuotoja), jotta suodatin voi luotettavasti valvoa politiikkaa ilman ihmisharkintaa jokaisen siirron osalta. Jäsentämätön vapaa teksti — kerronnalliset arviot, analyyttiset raportit, komentajan arviot — vaatii usein edelleen ihmistarkistuksen ennen julkaisemista, vaikka CDS-gaardi olisi läsnä teknisessä siirrossa.

Ohjelmille, joiden täytyy käsitellä paitsi siirtomekanismia myös luokitellun ympäristön laajempaa tietoturva-asentoa, zero trust -arkkitehtuuri puolustusohjelmistoille tarjoaa ympäröivän pääsynhallintakehyksen, johon CDS integroituu.

CDS-gaardiarkkitehtuurit

Neljä arkkitehtuurimallia kattaa suurimman osan CDS-käyttöönotoista. Jokainen tasapainottaa turvallisuuden varmuutta, operatiivista monimutkaisuutta ja ominaisuuksia toisiaan vastaan.

Laitteistodatadiodi. Fyysinen laite, joka käyttää optista tai sähköistä eristystä taatakseen yksisuuntaisen dataliikenteen laitteistotasolla. Elektronit — ja siten signaalit — eivät voi kulkea estettyyn suuntaan. Diodi luokitellun ja luokittelemattoman verkon välillä varmistaa, että vaikka matalan puolen ohjelmisto olisi täysin vaarantunut, mikään signaali matalalta puolelta ei voi saavuttaa korkeaa puolta. Rajoitus on tiukka: sovelluksen protokollan on siedettävä yksisuuntainen liikenne. TCP:n kuittausmekanismi ei toimi diodin yli; UDP-suoratoisto, syslog ja tiedostojen replikointi mukautettujen protokollien yli toimivat. Diodit sopivat bulkki-yksisuuntaisiin vienteihin — sensorien suoratoisto, lokin replikointi, videojakelu — joissa korkea puoli ei koskaan tarvitse toimituksen vahvistusta.

Kaksisuuntainen gaardi erillisillä välitinprosesseilla. Yleisin arkkitehtuuri sovelluksille, jotka vaativat pyyntö-vastaus-protokollia. Gaardi ajaa korkean puolen välitinprosessia ja matalan puolen välitinprosessia ilman jaettua osoiteavaruutta, jaettua tiedostojärjestelmää tai suoraa prosessien välistä viestintää niiden välillä. Ainoa polku korkealta matalalle — ja matalalta korkealle — kulkee gaardiydinten kautta, joka valvoo tietoturvapolitiikkaa jokaisen siirron osalta. Korkean puolen sovellus yhdistyy korkean puolen välittimeen; matalan puolen sovellus yhdistyy matalan puolen välittimeen. Verkon näkökulmasta kumpikin puoli näkee vain oman välittimensä. Gaardiydin on viitevalvoja — pieni, muodollisesti määritelty, itsenäisesti arvioitu komponentti, jonka ainoa tehtävä on valvoa siirtopolitiikkaa.

Sisältösuodatinpaaardi. Gaardi, jonka ensisijainen valvontamekanismi on sisällöntarkastus — hyötykuorman jäsentäminen, luokittelumerkintöjen poiminta, suodatinsääntöjen soveltaminen sekä sisällön läpäiseminen, hylkääminen tai puhdistaminen ennen edelleenlähetystä. Sisältösuodatinpaardit toteuttavat CAPCO-merkintäsanaston politiikkakielenään. Ne sopivat tilanteisiin, joissa siirrettävä data on jäsenneltyä ja hyvin merkittyä, ja joissa politiikka edellyttää valikoivaa läpäisyä eikä kokonaisvaltaista estoa. Useimmat nykyaikaiset kaksisuuntaiset gaardit sisältävät sisältösuodattimen ensimmäisenä vaiheena kaksisuuntaisen erotuksen jälkeen.

Viitevalvontamalli. Perustavanlaatuinen tietoturvaperiaate, jonka kaikki neljä arkkitehtuuria toteuttavat. Viitevalvoja on komponentti, joka: välittää jokaisen pääsypyynnön subjektin (lähettäjän) ja objektin (siirrettävän dataelementin) välillä; käynnistyy aina (mikään siirto ei ohita sitä); on peukaloinninkestävä (kumpikaan puoli ei voi muokata tai poistaa sitä käytöstä); ja on riittävän pieni muodolliseen todentamiseen. CDS-termein viitevalvoja on gaardiydin — ja sen peukaloinninkestävyys- ja täydellinen välitys -ominaisuudet ovat juuri se, mitä arvioijat tarkistavat akkreditointiprosessin aikana. CDS-tuote, joka sallii siirtojen ohittaa gaardiydinteen missä tahansa tilanteessa — huoltotilassa, korkean kuorman varajärjestelmässä, virhetilassa — ei täytä viitevalvontavaatimusta eikä sitä voida akkreditoida luokiteltuja verkkorajoja varten.

Seuraava kaavio näyttää kaksisuuntaisen gaardiarkkitehtuurin erillisillä välitinprosesseilla:

  ┌──────────────────────┐          ┌──────────────────────┐
  │  SECRET Network       │          │  UNCLASSIFIED Network │
  │  (High Side)          │          │  (Low Side)           │
  │                       │          │                       │
  │  ┌─────────────────┐  │          │  ┌─────────────────┐  │
  │  │  C2 Application │  │          │  │  COP Display    │  │
  │  └────────┬────────┘  │          │  └────────▲────────┘  │
  │           │            │          │           │            │
  │  ┌────────▼────────┐  │          │  ┌────────┴────────┐  │
  │  │  High-Side Proxy│  │          │  │ Low-Side Proxy  │  │
  └──┴────────┬────────┴──┘          └──┴────────▲────────┴──┘
              │                                   │
              │         ┌─────────────────┐       │
              └────────►│  Guard Kernel   ├───────┘
                        │  (Reference     │
                        │   Monitor)      │
                        │                 │
                        │  ┌───────────┐  │
                        │  │ Filter    │  │
                        │  │ Rules     │  │
                        │  │ (CAPCO)   │  │
                        │  └───────────┘  │
                        │                 │
                        │  ┌───────────┐  │
                        │  │ Audit Log │  │
                        │  │ (Signed)  │  │
                        │  └───────────┘  │
                        └─────────────────┘
                        Physical separation
                        of proxy processes
                        No shared memory/FS

Sisältöpohjainen suodatus: mitä gaardit tarkastavat

Sisältöpohjainen suodatus on mekanismi, joka antaa CDS-gaareille niiden valikoivan läpäisykyvyn. Sen sijaan, että kaikki estetään tai kaikki päästetään läpi, sisältösuodatingaardi lukee datan, poimii tietoturvan kannalta merkitykselliset kentät, soveltaa politiikkasääntöjä ja tekee salli/hylkää/puhdista-päätöksen viestiä kohti.

CAPCO-merkintöjen jäsentäminen. Yhdysvaltojen luokiteltujen järjestelmien sisältösuodatuksen perusta on CAPCO-merkintästandardi, joka määrittelee kontrolloidun sanaston tunnisteista, jotka esiintyvät luokitteluotsakkeissa, osa-merkinnöissä ja jäsennellyissä metatietokentissä. Gaardin CAPCO-jäsennin lukee luokittelumetadataelementtejä jokaisesta saapuvasta viestistä ja poimii komponenttitunnisteet. Viestille, joka on merkitty SECRET//SI//REL TO USA,GBR, jäsennin tuottaa: luokittelutaso = SECRET; SCI-kompartmentti = SI; levityshallinta = REL TO; julkaistavuus = USA, GBR. Jokainen tunniste tarkistetaan sitten kohdeverkon politiikkamatriisia vasten. Jos kohde ei ole akkreditoitu SI-kompartmentille, siirto hylätään. Jos kohde on akkreditoitu REL TO GBR -sisällölle, siirto sallitaan — mutta suodatin tarkistaa silti, onko jokin muu viestin sisältökenttä merkitty korkeammalle tasolle kuin asiakirjatason merkintä väittää.

Arkaluonteisten kompartmenttien valvonta. SCI-kompartmenttien valvonta edellyttää, että gaardi tunnistaa kaikki kompartmenttitunnisteet, jotka on määritelty hallitsevassa luokitteluohjeessa. Yleisimmät kompartmentit yhdysvaltalaisissa järjestelmissä ovat SI (Signals Intelligence), TK (Talent Keyhole, avaruudesta otetut kuvat), HCS (Humint Control System) ja G (Gamma, SI:n alakompartmentti). Jokainen on tarkistettava erikseen kohdeverkon kompartmenttiakkreditointia vasten. Kohdeverkko, joka on akkreditoitu SI:lle mutta ei TK:lle, ei saa vastaanottaa TK-merkinnällä varustettuja viestejä — vaikka asiakirjatason luokittelu olisi sallitulla alueella.

Osa-merkintöjen valvonta. Luokiteltu asiakirja sisältää usein kappaleita, osia tai dataelementtejä, joilla on eri herkkyystasot. CAPCO edellyttää, että jokainen osa kantaa omaa merkintäänsä. Osa-merkintöjä valvova gaardi ei jäsennä vain asiakirjatason otsikkoa, vaan myös jokaisen kappalekohtaisen (S//SI)- tai (U//FOUO)-tunnisteen ja tekee erillisen politiikkapäätöksen kunkin osalta. Puhdistaminen — politiikan hylkäämien osien poistaminen lopun välittämiseen — on monimutkaisempaa kuin kokonaisvaltainen hylkääminen, mutta operatiivisesti välttämätöntä sekasisältöisille asiakirjoille.

Liitteiden poistaminen. SMTP-viestit ja HTTP-moniosainen hyötykuorma sisältävät usein liitteitä, jotka gaardin on tarkistettava riippumatta viestirungosta. Jokainen liiteosa jäsennetään erikseen: MIME-sisältötyyppi määrittää käytettävän jäsentimen, liite tarkistetaan upotetun luokittelumetadatan osalta (PDF-asiakirjan ominaisuudet, Wordin mukautetut ominaisuudet, kuvan EXIF-kentät) ja politiikka sovelletaan kuhunkin liitteeseen erikseen. Liitteet muodoissa, joita gaardi ei osaa jäsentää — tuntemattomat binäärimuodot, salatut arkistot — hylätään oletusarvoisesti eikä niitä koskaan päästetä läpi tarkastamatta.

CAPCO-merkintöjen valvonnan ja taustalla olevan datamallin välinen vuorovaikutus CDS-tasolla on kuvattu yksityiskohtaisesti artikkelissa sotilastietojen yhdistäminen selitettynä, jossa käsitellään luokittelun leviämistä monilähteisen seurantatietokannan kautta. NATO-ympäristöissä CAPCO-ekvivalenttien merkintöjen ja NATO:n luottamuksellisuusmerkintästandardin välinen sidonta on kuvattu STANAG 4774/4778 -merkintöjen toteutuksen viiteartikkelissa.

Nykyaikaisten CDS-tuotteiden tukemat dataformaatit ja protokollat

CDS-gaardi on yhtä hyödyllinen kuin sen tuki sovelluksesi tosiasiallisesti käyttämille formaateille. Gaardin jäsentimen on ymmärrettävä formaatti riittävän syvällisesti poimiakseen luokittelukentät ja tarkistaakseen sisällön — pintatasoinen otsikon tarkistus ei riitä.

Formaatti / Protokolla	Luokittelukentän sijainti	Tyypillinen sotilaallinen käyttö	Gaarditarkastuksen monimutkaisuus
XML (IC-ISM / UCORE)	Nimiavaruusattribuutit juurielementissä ja jokaisessa luokitellussa osassa	Seurantaviestit, tiedustelutuotteet, NiemXML-raportit	Korkea — täydellinen schemaa tunteva XPath-arviointi
JSON ISM-metatiedolla	Ylätason `ism:classification`-kenttä tai upotetut merkintäobjektit	REST API -hyötykuormat, modernit C2-mikropalvelut	Keskitaso — schemariippuvainen, rekursiivinen tarkistus tarpeen
SMTP / MIME	`X-Classification:` -otsake + rungon otsikko + liitekohtainen merkintä	Tiedustelutuotteiden jakelu, SITREP-jakelu	Korkea — rekursiivinen MIME-jäsennys, liitetyypin tunnistus
HTTP/HTTPS (REST)	Mukautettu otsake + hyötykuormarunko	API-kutsut luokiteltujen ja luokittelemattomien palvelujen välillä	Keskitaso — TLS-purku + sisällön uudelleentarkistus tarpeen
MTF (Message Text Format)	CLASSIFICATION-kenttä viestin otsikkojoukossa	NATO/perinteiset sotilasviestit, USMTF, ADatP-3	Keskitaso — kiinteäkenttäinen formaatti, hyvin määritelty jäsennys
PDF / Office-asiakirjat	Mukautetut asiakirjaominaisuudet, XMP-metadata, otsikkoteksti rungossa	Valmiit tiedustelutuotteet, käskyt, suunnitelmat	Erittäin korkea — upotetut objektit, makrot, metadatan poisto tarpeen
Video (RTP/RTSP)	Virtauksen metatietootsakkeet (jos läsnä); ruututason päällysteksti	ISR-videoalavirtaus, UAV-syötteet	Erittäin korkea — vaatii tyypillisesti diodin + erillisen videovälittimen

XML-pohjaisten sotilasviestien suodatinsäännöt ilmaistaan XPath-kielellä. Sääntö, joka hylkää minkä tahansa TK-kompartmenttitunnisteen kantavan viestin, näyttää tältä:

<!-- Guard filter rule: reject if TK compartment is present -->
<FilterRule id="REJ-TK-001" action="REJECT">
  <Description>Reject messages carrying Talent Keyhole (TK) compartment</Description>
  <Condition>
    <XPathExpression>
      //*[contains(
        translate(
          @ism:SCIcontrols,
          'ABCDEFGHIJKLMNOPQRSTUVWXYZ',
          'abcdefghijklmnopqrstuvwxyz'
        ),
        'tk'
      )]
    </XPathExpression>
  </Condition>
  <AuditMessage>Transfer rejected: TK compartment detected in payload</AuditMessage>
</FilterRule>

<!-- Sanitization rule: strip SI-marked portion elements before forwarding -->
<FilterRule id="SAN-SI-001" action="SANITIZE">
  <Description>Strip SI-marked portions from otherwise-releasable documents</Description>
  <Condition>
    <XPathExpression>//*[@ism:SCIcontrols='SI']</XPathExpression>
  </Condition>
  <SanitizeAction>REMOVE_ELEMENT</SanitizeAction>
  <AuditMessage>Sanitized: SI-marked element removed from document</AuditMessage>
</FilterRule>

NSA:n hyväksyntä- ja akkreditointiprosessi

CDS-gaardin, joka suojaa kahden Yhdysvaltain hallituksen luokitellun verkon välistä yhteyttä, on oltava NSA/CSS:n hyväksymä ennen toimintaa. Operatiiviselle kiireellisyydelle ei ole poikkeuspolkua — hyväksymättömän CDS:n käyttöönotto on raportoitava tietoturvapoikkeama. Akkreditointiprosessin ja sen aikataulun ymmärtäminen on edellytys mille tahansa ohjelmalle, johon sisältyy luokiteltu raja.

NSA/CSS:n arvioitujen tuotteiden luettelo (EPL). NSA arvioi CDS-tuotteita ja julkaisee tulokset Evaluated Products List -luettelossa. EPL-listaus sertifioi, että tietty tuoteversio tietyssä konfiguraatiossa toteuttaa viitevalvontamallin oikein ja kestää arvioijien testaamat hyökkäysluokat. EPL-listaus määrittää tarkan laitteistomallin ja laiteohjelmistoversion, ohjelmistoversion sekä arvioidut konfigurointivaihtoehdot. Arvioidusta konfiguraatiosta poikkeaminen — jopa sellaisen käyttöjärjestelmäkorjauksen soveltaminen, joka ei ollut osa arvioitua perustaa — edellyttää uudelleenarviointia tai poikkeamisvaltuutusta. Ohjelmien on seurattava, mihin EPL-versioon käyttöönotettu gaardi vastaa, ja ylläpidettävä tätä vastaavuutta gaardin koko käyttöiän ajan.

Raise the Bar (RTB) -aloite. Useiden tapausten jälkeen, joissa riittämättömästi suunnitellut gaardit sallivat tiedon kulkea virheellisesti, NSA/CSS antoi Raise the Bar -vaatimukset CDS-tuotteille. RTB edellyttää korkean ja matalan puolen käsittelypolkujen laitteistoerotusta, muodollista dokumentaatiota jokaisesta suodatinsäännöstä ja sen tietoturvaperusteluista, kryptografisesti allekirjoitettuja auditointilokeja (jotta lokien peukalointi on havaittavissa), riippumatonta kolmannen osapuolen todentamista gaardilohkon logiikalle sekä määriteltyä korjausprosessia, joka sisältää uudelleentodentamisen tietoturvan kannalta merkittävien muutosten jälkeen. RTB-vaatimukset täyttävät tuotteet listataan EPL:ssä eksplisiittisellä RTB-merkinnällä. Tuotteet, jotka eivät täytä RTB-vaatimuksia, voivat edelleen olla vanhemmissa EPL-luetteloissa, mutta niitä ei voi uudelleen hyväksyä Yhdysvaltain hallituksen luokkiteltujen verkkorajojen suojaksi.

DISA:n yhtenäisten ominaisuuksien hyväksyttyjen tuotteiden luettelo (UC APL). DoD-ohjelmille DISA UC APL -listaus vaaditaan NSA EPL:n lisäksi. UC APL -arviointi keskittyy yhteentoimivuuteen DoD-verkkoinfrastruktuurin kanssa ja vaatimustenmukaisuuteen DoD:n tietoturvan toteutusohjeiden (STIG) kanssa. Tuote voi olla NSA EPL:ssä mutta ei UC APL:ssä, tai päinvastoin — molemmat vaaditaan useimpiin DoD:n luokiteltujen verkkojen käyttöönottoihin. Tarkista molemmat luettelot arvioidessasi CDS-kandidaattituotteita.

Paikkakohtainen käyttövaltuutus (ATO). Vaikka käytettäisiin EPL/UC APL -tuotetta, jokainen käyttöönotto edellyttää paikkakohtaista ATO:a, joka kattaa: käyttöönotetun laitteiston ja ohjelmiston tarkan konfiguraation; verkkotopologian ja gaardiasenuksen fyysisen turvallisuuden; suodatinsääntöjoukon ja sen suhteen yhdistettyjen verkkojen luokittelupolitiikkoihin; jatkuvan valvonnan menettelyt; sekä korjausten hallinnan ja konfigurointimuutosprosessin. ATO-paketin tarkistavat rajan kummankin puolen järjestelmien hyväksyvä viranomainen (AO). Eri virastojen omistamien verkkojen välisiin yhteyksiin vaaditaan ATO:n myöntämiseksi kahden AO:n välinen kahdenvälinen sopimus. Aikataulu: 6–18 kuukautta tuotteelle, joka on jo EPL:ssä monimutkaisuudeltaan yksinkertaisessa konfiguraatiossa.

Integrointimallit C2- ja ISR-putkiin

CDS-gaardin integroiminen operatiiviseen C2- tai ISR-putkeen edellyttää sekä datavirta-arkkitehtuurin että gaardin aiheuttamien suorituskykyrajoitusten läpikäyntiä.

SECRET-to-UNCLASSIFIED COP -malli. Yleisin integrointi on julkaise-tilaa-putki, jossa SECRET-välittäjä syöttää luokiteltuja seurantapäivityksiä, ja CDS-gaardi tilaa SECRET-välittäjää, tarkistaa jokaisen päivityksen ja julkaisee puhdistetut päivitykset UNCLASSIFIED-välittäjälle, jota koalitionkumppanit tai matalan puolen kuluttajat tilaavat. Gaardi toimii tässä arkkitehtuurissa suodattavana tilaajana korkealla puolella ja julkaisevana tuottajana matalalla puolella — ei koskaan läpivientiinä reitittimenä. Tämä varmistaa, ettei kahden välittäjän välille synny suoraa yhteyttä.

SECRET Network                     UNCLASSIFIED Network
─────────────                      ────────────────────

┌─────────────┐   track updates   ┌─────────────────────────────┐
│ SECRET      │ ─────────────────►│     CDS Guard               │
│ Message     │                   │                             │
│ Broker      │                   │  High-Side     Low-Side     │
│             │                   │  Subscriber    Publisher    │
│             │                   │      │              │       │
│             │                   │      ▼              │       │
│             │                   │  CAPCO Filter       │       │
│             │                   │  SI/TK/HCS check    │       │
│             │                   │  Sanitize/Reject     │       │
│             │                   │      │              │       │
│             │                   │      └──────────────►       │
└─────────────┘                   └─────────────────────────────┘
                                               │
                                               ▼ sanitized updates
                                   ┌───────────────────┐
                                   │ UNCLASSIFIED      │
                                   │ Message Broker    │
                                   └─────────┬─────────┘
                                             │
                                             ▼
                                   ┌───────────────────┐
                                   │ Coalition COP /   │
                                   │ UNCLASSIFIED      │
                                   │ Display           │
                                   └───────────────────┘

Viiveen suunnittelu. CDS-gaardi lisää käsittelyviivettä jokaiselle tarkistamalleen viestille. Pienille XML-seurantapäivitysviesteille (alle 4 KB) kaupalliset gaardit lisäävät tyypillisesti 50–200 millisekuntia tarkistusviivettä. Suurille viesteille, jotka sisältävät binääriliitteitä tai vaativat useiden osien puhdistamista, viive voi olla 500 millisekuntia–2 sekuntia. PDF-asiakirjojen tai monimutkaisten MIME-viestien käsittely voi kestää useita sekunteja. Tämä on otettava huomioon COP-päivitysnopeudessa ja tiedustelutuotteiden jakelun palvelutasosopimuksessa (SLA). Gaardin läpäisykykyluokitukset julkaistaan EPL-dokumentaatiossa — varmista, että arvioitu läpäisykyky sovelluksesi viestikoossa ja monimutkaisuudessa on riittävä ennen tuotteeseen sitoutumista.

ISR-sensoridatapolut. ISR-sensoreille, jotka toimivat luokitellulla tasolla ja joiden täytyy syöttää dataa alhaisemman luokituksen kuluttajille, datapolku sisältää tyypillisesti luokitellun käsittelyvaiheen, joka tuottaa puhdistettuja johdannaistuotteita, jotka sitten ylittävät CDS-rajan. Raa'an sensoridatan (täydentarkkuuskuvien, raakojen SIGINT-sieppausten) ei pitäisi koskaan olla suunniteltu kulkemaan CDS-gaardin kautta — raakojen ISR-tietojen luokittelu on tyypillisesti paljon korkeampi kuin mitä matala puoli voi vastaanottaa, ja raakasensoridatan sisältösuodatus on epäluotettavaa. Suunnittelumalli on: käsittele datan luokittelutasolla, tuota johdannaistuotteita joista arkaluonteiset lähdeindikaattorit on poistettu, ja siirrä vain johdannaistuotteet gaardin kautta.

Operatiivinen tietoturva CDS-käyttöönotossa

CDS-gaardi on korkean arvon kohde juuri siksi, että sen vaarantaminen vastaa luokitellun rajan poistamista. Käyttöönotetun gaardin ympärillä olevien operatiivisten tietoturvakontrollien on oltava oikeassa suhteessa tähän riskiin.

Fyysinen turvallisuus. Gaardilaitteisto on asennettava fyysisesti turvalliseen paikkaan — lukittuun laitehuoneeseen, jossa on pääsynhallinnan alainen sisäänpääsy ja vierailijalokit. Sekä korkean puolen verkkoyhteys että gaardilaitteisto on oltava korkeamman luokituksen verkon fyysisessä turvallisuuspiirissä. Gaardin peukalointi — piilotetulle kanavalle tarkoitetun laitteen lisääminen verkkoyhteyteen, laiteohjelmiston korvaaminen — on todellinen uhka, johon fyysiset kontrollit vastaavat.

Out-of-band-hallinta. Gaardin hallintaliittymän on oltava erillisessä fyysisessä verkossa, joka on erillinen sekä operatiivisista korkean puolen että matalan puolen verkoista. Hallintaliikenne — konfigurointimuutokset, ohjelmistopäivitykset, lokien nouto — joka kulkee jommankumman operatiivisen verkon kautta, luo piilotetulle kanavalle alttiuden. Hallintaasemien on sijaittava korkeamman luokituksen turvallisuuspiirissä ja ne on akkreditoitava vastaavasti.

Lokien eheys ja peukaloinnin havaitseminen. CDS-auditointilokikirjaukset ovat ensisijainen todiste siitä, että rajaa on valvottu oikein. Lokien on oltava kryptografisesti suojattuja — jokainen lokitietue sisältää HMAC:n tietueen sisällöstä ja edellisen tietueen tiivisteen (hash-ketju). Tämä tekee minkä tahansa tietueen lisäämisestä, poistamisesta tai muokkaamisesta havaittavaa, kun ketju tarkistetaan. Lokien on oltava kirjoitettuna järjestelmään, johon kumpikaan korkean eikä matalan puolen verkko voi kirjoittaa tai poistaa — erillinen lokipalvelin, johon pääsee vain tietoturvavalvoja out-of-band-hallintaverkon kautta. Lokien tarkistuksen on oltava aktiivinen, päivittäinen toimenpide: hylkäämispoikkeamat, epätavalliset viestivolyymit tai saman lähettäjän toistuvat politiikkarikkomukset ovat merkkejä luotauksesta tai hyökkäysyrityksestä.

Konfigurointimuutosten hallinta. Jokainen muutos suodatinsääntöjoukkoon — säännön lisääminen, ehdon muokkaaminen, säännön poistaminen — on läpikäytävä dokumentoidussa muutosprosessissa, joka sisältää: kirjallinen muutospyyntö tietoturvallisin perustein; toisen tietoturvaupseerin riippumaton tarkistus; testisuoritus edustavaa liikennenäytettä vasten; sekä tuotantopäätösten ensimmäisen 24 tunnin jälkitarkastus varmistaakseen, että sääntö toimii tarkoitetulla tavalla. Muutoksia, joita ei ole käyty läpi tämän prosessin kautta, ei saa soveltaa tuotantogaardin konfiguraatioihin. Kiinteä muutoskielto tulisi soveltaa korkean toimintatempon operatiivisina kausina, jolloin gaardikonfigurointivirhe olisi tuhoisinta.

Korjausten hallinta. Gaardin käyttöjärjestelmän ja sovelluksen tietoturvakorjauksien käsittely vaatii huolellista harkintaa. Korjauksen soveltaminen, joka ei ole osa arvioitua konfiguraatiota, voi mitätöidä ATO:n — mutta tietoturvakorjausten soveltamatta jättäminen luo hyödynnettäviä haavoittuvuuksia. Menettely on: vastaanota ja arvioi korjaus; määritä, vaikuttaako se arvioituun konfiguratioperustaan; jos vaikuttaa, konsultoi EPL-toimittajaa ja hanki arviointipoikkeamisvaltuutus tai aikatauluta uudelleenarviointi; testaa korjaus eristetyssä gaardisympäristössä, joka peilaa tuotantoa; sovella tuotantoon aikataulutetun huoltoikkunan aikana lyhyellä palvelukatkolla; varmista, että suodatinsääntöjen toiminta on muuttumaton korjauksen jälkeen.

Red-team-testaus. Vuosittainen penetraatiotestaus CDS-asennuksesta pitäisi olla vaatimus tietoturvasuunnitelmassa. Testauksen laajuuteen pitäisi kuulua: luokitellun sisällön poistamisyritys matalan puolen liittymän kautta formaattisyöttö- ja koodaushyökkäyksillä; piilotetulle kanavalle perustuvan hyökkäyksen yritys ajoitus-, tallennustila- ja protokollatasoisten kanavien kautta; gaardin hallintaliittymään pääsyn yritys operatiivisista verkoista; sekä fyysisen peukaloinnin skenaariot. Red-team-testauksen havainnot syötetään suoraan jatkuvan valvonnan raporttiin ja voivat käynnistää konfigurointimuutoksia tai uudelleenarviointia.

Keskeinen havainto: Yleisin operatiivinen vikaantumistapa CDS-käyttöönotossa ei ole suodatinsääntöaukko — se on konfiguraatioajautuminen. Määritellylle konfiguraatiolle akkreditoitu gaardi erkaantuu vähitellen siitä konfiguraatiosta luvattomien korjausten, ad hoc -sääntömuutosten ja laitteistokomponenttien korvausten kautta. 18 kuukauden toiminnan jälkeen ilman muodollista konfigurointiauditointia useimmat gaardit toimivat konfiguraatiossa, jota ei ole koskaan arvioitu. Sisällytä konfigurointiauditoinnit operatiiviseen aikatauluun alusta alkaen.

Keskustele projektistasi

Suunnittelemme dataintegraatioarkkitehtuureja puolustusohjelmille, jotka toimivat luokiteltujen ja luokittelemattomien verkkorajojen yli — mukaan lukien CDS-integraatio, CAPCO-tietoiset dataputket ja monidomeeniset C2-yhteydet.

Dataintegraatiopalvelut → Varaa esittely

Tämän analyysin ovat valmistelleet Corvus Intelligencen insinöörit, jotka rakentavat kriittistä ohjelmistoa puolustus- ja viranomaisorganisaatioille. Lue lisää tiimistämme →

Usein kysytyt kysymykset

Mikä on ero cross-domain-ratkaisun ja palomuurin välillä?

Palomuuri valvoo pääsynhallintaa verkkokerroksella — se sallii tai kieltää yhteydet isäntien välillä IP-osoitteiden, porttien ja protokollien perusteella. Cross-domain-ratkaisu (CDS) toimii sisältökerroksella: se tarkistaa jokaisen viestin hyötykuorman, varmistaa luokittelumerkintöjen läsnäolon ja oikeellisuuden, soveltaa sisältöön suodatinsääntöjä sekä puhdistaa tai hylkää siirron ennen kuin se ylittää matalan luokittelun verkkoon. Palomuuri ei voi lukea XML:ään upotettuja CAPCO-merkintöjä eikä poistaa luokiteltuja liitteitä SMTP-viesteistä; CDS on tarkoitukseen rakennettu näihin tehtäviin. CDS-tuotteet ovat myös muodollisen valtion akkreditoinnin (NSA/CSS EPL, DISA UC APL) kohteena, jota tavalliset palomuurit eivät läpikäy.

Mitä CAPCO tarkoittaa ja miksi sitä käytetään CDS-suodatinsäännöissä?

CAPCO on lyhenne sanoista Controlled Access Program Coordination Office. CAPCO-standardit määrittävät kontrolloidun sanaston Yhdysvaltain luokittelumerkinnöille — jäsennellyille merkkijonoille, jotka esiintyvät otsakkeissa, osa-merkinnöissä ja XML-metatietokentissä. Esimerkkejä ovat TOP SECRET//SI//REL TO USA,FVEY ja SECRET//NOFORN. CDS-gaardien suodatinsäännöt kirjoitetaan näitä jäsenneltyjä merkintöjä vasten, koska ne koodaavat tarkan luokittelutason, levityshallintakontrollit ja julkaistavuuden. Gaardi, joka jäsentää CAPCO-merkinnän, poimii luokittelutason, SCI-kompartmentit (SI, TK, HCS) ja käsittelylausekkeet (NOFORN, ORCON, REL TO). Jos jokin näistä tunnisteista ylittää sen, mihin kohdeverkko on valtuutettu vastaanottamaan, siirto hylätään ennen kuin hyötykuorma poistuu lähdeenklaavista.

Mikä on datadiodi ja milloin yksisuuntainen gaardi on riittämätön?

Datadiodi on laitteistolla pakotettu yksisuuntainen linkki, joka käyttää optista eristystä tai vastaavaa teknologiaa varmistaakseen, ettei mikään signaali voi kulkea estettyyn suuntaan. Diodit sopivat bulkki-vientiin luokitellusta verkosta, kun vastavirtaliikennettä ei koskaan tarvita, kuten videovirrat tai lokin replikointi. Ne käyvät riittämättömiksi, kun protokolla vaatii kättelyä tai kuittausta, sovellus tarvitsee kaksisuuntaista tiedonvaihtoa tai sisältötarkistus vaaditaan ennen siirtoa. Näissä tapauksissa tarvitaan kaksisuuntainen gaardi erillisillä korkean puolen ja matalan puolen välitinprosesseilla — viitevalvontamallia noudattaen.

Kuinka CDS-gaardi valvoo NEED-TO-KNOW-vaatimusta luokittelutason lisäksi?

Luokittelutaso on vain ulompi raja. Luokittelutason sisällä on lisäpääsynhallintakontrolleja, kuten SCI-kompartmentit (SI, TK, HCS), NOFORN-rajoitukset, ORCON-kontrollit, REL TO -merkinnät ja silmät-vain -nimitykset. CDS-gaardi valvoo näitä ylläpitämällä politiikkamatriisia, joka kuvaa jokaisen kohdeverkon akkreditoinnin sallittuihin merkintätunnisteisiin. Objekti, joka on merkitty SECRET//REL TO USA,GBR, sallitaan verkossa, johon kuuluu UK-selvitettyjä käyttäjiä, mutta hylätään verkossa, jolla ei ole REL TO GBR -valtuutusta. Tämä matriisi on pidettävä synkronoituna jokaisen yhdistetyn enklaavan akkreditointidokumentaation kanssa.

Mikä on NSA:n Raise the Bar -aloite ja miten se vaikuttaa CDS-hankintaan?

Raise the Bar (RTB) on NSA/CSS:n aloite, joka asetti tiukempia arviointistandardeja CDS-tuotteille useiden tapausten jälkeen, joissa riittämättömät gaardit sallivat tietovuodon. RTB-vaatimusten täyttävien tuotteiden on osoitettava laitteistoerotus korkean ja matalan puolen käsittelypolkujen välillä, muodollinen tietoturvapolitiikan dokumentaatio, kryptografinen lokieheys, riippumaton gaardilohkon logiikan todentaminen sekä määritelty korjaus- ja uudelleenarviointiprosessi. RTB-vaatimukset täyttävät tuotteet listataan NSA/CSS EPL:ssä eksplisiittisellä RTB-merkinnällä. RTB:n vaatimusten täyttämättömän CDS:n hankkiminen luokiteltujen verkkorajojen suojaksi on kielletty nykyisen politiikan mukaan.

Mitä tiedostoformaatteja nykyaikaiset CDS-gaardit suodattavat, ja mitkä ovat tukemattomien formaattien riskit?

Nykyaikaiset CDS-tuotteet tukevat XML:ää (IC-ISM, UCORE, NIEM-schemaa), JSONia luokittelumetatietokentillä, SMTP:tä MIME-liitteineen, HTTP/HTTPS:ää hyötykuormatarkistuksella, PDF-asiakirjoja upotetulla metatiedolla sekä MTF-viestimuotoja. Tukemattomien formaattien riskinä on binääriläpivirtaus tai täydellinen esto: jos gaardi ei pysty jäsentämään formaattia, se joko estää kaikki saman tyypin liikenteen (häiriten toimintaa) tai päästää sen läpi tarkistamatta (luoden tietovuotokanavan). Tuntemattomat binäärimuodot on oletusarvoisesti hylättävä, ei koskaan päästettävä läpi. Mikä tahansa uusi dataformaatti, joka tuodaan CDS-suojattuun putkeen, edellyttää eksplisiittistä formaattituen vahvistamista akkreditointitestauksessa.

Kuinka CDS-gaardit pitäisi integroida C2-putkeen, joka syöttää sekä SECRET- että UNCLASSIFIED-kuluttajia?

Vakiomalli on julkaise-tilaa-topologia luokituskohtaisilla välittäjillä ja CDS-gaardilla rajalla. SECRET-välittäjä vastaanottaa kaikki seurantapäivitykset ja tiedustelutuotteet. CDS-gaardi tilaa SECRET-välittäjää, tarkistaa jokaisen viestin konfiguroitua politiikkaa vasten, poistaa kompartmenttimerkinoillä varustetut kentät ja julkaisee puhdistetut viestit UNCLASSIFIED-välittäjälle. Gaardi ei koskaan paljasta kaksisuuntaista yhteyttä suoraan kahden välittäjän välillä. Gaardin aiheuttama viive (tyypillisesti 50–500 ms tekstiviesteille) on otettava huomioon COP-päivitysnopeuden SLA-suunnittelussa.

Mitä lokikirjausvaatimuksia CDS-gaardikäyttöönottoihin sovelletaan?

CDS-gaardien on tuotettava peukaloinninkestävät auditointilokikirjaukset jokaisesta siirtopäätöksestä. Jokaisen lokitietueen on sisällettävä GPS-synkronoitu aikaleima, lähettäjäyksikkö, kohdeenklaavi, viestihyötykuorman tiiviste, poimitut merkintätunnisteet, käynnistynyt politiikkasääntö ja päätöstuotos. Lokien on oltava tallennettuna järjestelmään, johon kumpikaan korkean eikä matalan puolen verkko voi kirjoittaa tai poistaa. Lokien eheys varmistetaan HMAC-ketjulla — jokainen tietue sisältää edellisen tietueen HMAC:n, jolloin mikä tahansa muutos on havaittavissa. Säilytysaika on tyypillisesti vähintään kolme vuotta luokiteltujen järjestelmien auditointilokien osalta.

Voiko CDS-gaardi käsitellä reaaliaikaista suoratoistettuä dataa, kuten video- tai seurantasyötteitä?

Kyllä, mutta arkkitehtuuri eroaa viestiperusteisesta siirrosta. Videolle yksisuuntainen datadiodi yhdistettynä videotranskoodausvälittimeen on vakioratkaisu: luokiteltu videovirta tulee välittimeen korkean puolen kautta, välittin koodaa sen uudelleen puhtaaksi bittivirraksi poistaen kaiken metatiedon, ja puhdas virta poistuu diodin kautta matalan puolen näyttöön. Reaaliaikaisille seurantasyötteille sisältöä tunteva gaardi välittää jokaisen seurantapäivitysviestin, tarkistaen luokittelukentät ennen edelleenlähetystä. CDS-tuotteita, jotka on luokiteltu korkean suorituskyvyn suoratoistoon, on EPL:ssä, mutta ne on arvioitava erikseen aiotun käyttöympäristön viestinopeuksia varten.

Kuinka kauan NSA/DISA-akkreditointi uudelle CDS-käyttöönotolle tyypillisesti kestää?

CDS-käyttöönotto, joka käyttää jo NSA/CSS EPL:ssä ja DISA UC APL:ssä olevaa tuotetta, vaatii tyypillisesti 6–18 kuukautta paikkakohtaiselle ATO-käsittelylle, olettaen että tietoturvasuunnitelma on valmis ja konfiguraatio vastaa arvioitua perustaa. Mukautetulla tavalla kehitettyjä gaardikokoonpanoja käyttävät käyttöönotot vaativat täydellisen valtion rahoittaman arvioinnin, joka kestää tyypillisesti 18–36 kuukautta. Ohjelmat, jotka vievät tuotantoon ennen akkreditoinnin valmistumista, kohtaavat tyypillisesti pakotettuja sammutuskäskyjä, kun tarkastajat havaitsevat puutteen. ATO-prosessin sisällyttäminen ohjelman aikatauluun alusta alkaen realistisilla aikatauluilla on välttämätöntä CDS-riippuvaisille ohjelmille.