REST-API-suunnittelu Naton C2-järjestelmien yhteentoimivuudelle

Johtamis- ja valvontajärjestelmä, joka ei voi jakaa operatiivista kuvaansa koalitiokumppaneiden kanssa, on kansallinen siilo, ei koalitiokyvykkyys. Naton siirtyessä kohti palvelukeskeisiä arkkitehtuureja REST-API:sta on tullut käytännöllinen rajapinta jäsenneltyjen C2-tietojen vaihtoon kansallisten järjestelmien välillä IP-verkoissa. Mutta pelkkä REST-API ei takaa mitään: yhteentoimivuus syntyy skeemasta, jota API tarjoaa, ei siitä, että se puhuu HTTP:tä. Tämä opas käy läpi suunnittelupäätökset, jotka tekevät C2-REST-API:sta aidosti yhteentoimivan Nato-koalitiossa.

Miksi REST-API-rajapintoja C2-yhteentoimivuuteen

Vuosikymmenten ajan koalitioyhteentoimivuus tarkoitti piste-pisteeseen-taktisia tietolinkkejä — Link 16, VMF, Link 22 — kukin räätälöity, laitteistoon kytketty integraatio. Nämä linkit pysyvät olennaisina taktisella reunalla, mutta ne eivät skaalaudu esikunta- ja operatiivisen tason kyselyrikkaisiin pyyntö-vastaus-vuorovaikutuksiin. Taisteluvoiman hakeminen, tehtävän lähettäminen, karttapeitteen noutaminen tai kohdepäivityksiin tilaaminen ovat verkkopalveluvuorovaikutuksia, eivät yleislähetystaktisia sanomia.

Naton siirtymä palvelukeskeiseen arkkitehtuuriin heijastaa tätä. Federated Mission Networking -kehys kohtelee C2-kyvykkyyksiä palveluina, joilla on dokumentoidut rajapinnat, löydettävissä rekisterin kautta, suojattuna federoidulla identiteetillä. REST — resurssikeskeinen, tilaton, välimuistitettava, rakennettu kaikkialla läsnä olevan HTTP-työkaluston päälle — sopii luontevasti tähän malliin. Koalitiokumppani, joka voi tehdä HTTPS-pyynnön, voi käyttää REST-palvelua ilman erikoistunutta laitteistoa.

REST ei kuitenkaan korvaa sanomapohjaisia linkkejä. Link 16:n aikaviipalepohjainen, vähäviiveinen yleislähetys on korvaamaton korkeatempoiseen taktisen datan jakeluun; VMF kuljettaa muotoiltuja maasanomia rajoitetuilla kantoaaltoilla. Insinööriarvostelu on siirtotavan sovittamista vuorovaikutukseen: taktiset tietolinkit kone-koneeseen-aikakriittiseen jakeluun reunalla; REST jäsenneltyihin tietotuotteisiin, joita vaihdetaan IP-yhdistettyjen järjestelmien välillä. Useimmat todelliset arkkitehtuurit ajavat molempia, yhdyskäytävän silloittaessa taktisen ja palvelukeskeisen alueen. Laajempaa standardimaisemaa käsitellään täydellisessä Naton yhteentoimivuusoppaassamme.

Resurssimallinnus sotilasaloille

Ensimmäinen suunnittelutehtävä on API:n tarjoamien aluentiteettien tunnistaminen ja niiden mallintaminen REST-resursseiksi. C2-operatiivinen kuva hajoaa luontevasti kohteisiin, yksiköihin, tehtäviin, käskyihin ja peitteisiin — kukin resurssi, jolla on vakaa identiteetti ja selkeä URI. Kohteet sijaitsevat osoitteissa /tracks ja /tracks/{id}; yksiköt osoitteessa /units/{id}; käskyt ja niiden tehtävät osoitteessa /orders/{id}; graafiset peitteet osoitteessa /overlays/{id}. Viitetiedoilla — symboliluetteloilla, koordinaattijärjestelmillä — on omat vakaat päätepisteensä.

Kokoelma-vastaan-elementti-erottelu ohjaa kyselysuunnittelua. Kokoelmapäätepiste, kuten /tracks, tukee suodatusta yleisille käyttömalleille: spatiaalinen rajaava suorakulmio (?bbox=…), aikaikkuna (?since=…), turvaluokituskatto, yksikkökuuluvuus. Elementtipäätepiste palauttaa yksittäisen resurssin täyden esityksen. Suhteet — kohde kuuluu yksikköön, käsky viittaa tehtäviin — esitetään joko upottamalla tai linkittämällä, mikä on tarkoituksellinen kompromissi edestakaisten kutsujen ja hyötykuorman koon välillä.

Ratkaiseva kohta: resurssimalli on API-suunnittelijan valinta, mutta kunkin resurssin sisäinen esitys ei ole. Hyötykuorman tulisi kartoittua MIP4-tiedonvaihtomalliin (IEDM), Naton tietomalliin maapohjaiselle operatiiviselle kuvalle, eikä keksittyyn sisäiseen rakenteeseen. Puhdas URI-suunnittelu, joka tarjoaa räätälöityä JSON:ia, ei ole yhteentoimiva kenenkään kanssa; puhdas URI-suunnittelu, joka tarjoaa MIP4-yhteensopivia hyötykuormia, on kenen tahansa MIP4:ää toteuttavan kumppanin käytettävissä.

Yhteensovitus Naton tietostandardeihin

Standardienmukaisuus tapahtuu hyötykuorman skeematasolla, joten jokaisen resurssiesityksen on kartoituttava STANAG:in määrittämään malliin. Jäsennelty operatiivisen kuvan data — kohteet, yksiköt, käskyt — kartoittuu MIP4 IEDM:ään. Taktinen grafiikka ja peitteet kartoittuvat NATO Vector Graphics (NVG):iin. Muotoillut operatiiviset sanomat kartoittuvat ADatP-3 / APP-11 -sanomaluetteloihin. Kartoitus on integraatiotyötä: API:n sisäinen tietomalli käännetään kenttä kentältä standardiskeemaan ulos mennessä ja jäsennetään takaisin sisään tullessa.

Sisällön neuvottelu antaa yksittäisen resurssin tarjota useita esityksiä eri kyvykkyyksien asiakkaille. Peiteresurssi voi palauttaa application/vnd.nvg+xml NVG-tietoiselle asiakkaalle; kohdekokoelma voi palauttaa MIP4-esityksen tai GeoJSON:n Accept-otsikosta riippuen. Tämä pitää resurssimallin vakaana ja mukautuu samalla koalition heterogeenisiin työkaluketjuihin.

Skeemavalidointi tekee yhteensopivuudesta todellista eikä tavoitteellista. Sekä pyyntö- että vastaushyötykuormat validoidaan julkaistuja Nato-skeemoja vasten API:n rajalla, ja vaatimustenvastaiset hyötykuormat hylätään suoraan. Ilman pakotettua validointia skeemaeroavaisuus hiipii sisään — tässä jätetty pois valinnainen kenttä, tuolla laajennettu koodiluettelo — ja API poikkeaa hiljaa standardista, kunnes se epäonnistuu yhteentoimivuudessa kumppanin kanssa juuri väärällä hetkellä. Tiukka validointi rajalla on halpa vakuutus kalliita integraatiovirheitä vastaan.

Turvallisuus ja turvaluokitus API-kerroksessa

Koalition C2-data on turvaluokiteltua ja varauksellista, ja API-kerros on paikka, jossa nämä hallinnat pannaan täytäntöön — ei käyttöliittymä. Jokainen resurssiesitys kantaa STANAG 4774 -luottamuksellisuusmerkintää, joka määrittää sen turvaluokitustason (esimerkiksi NATO SECRET) ja sen luovutusvaraukset (REL TO nimetylle kansakuntien joukolle). Merkintä on kryptografisesti sidottu dataan STANAG 4778:n mukaisesti, joten sitä ei voi erottaa sisällöstä eikä muuttaa siirrossa.

Pääsynvalvontakerros arvioi pyytäjän kunkin resurssin merkintää vasten ennen kuin mitään palautetaan. Kokoelmakysely ei palauta jokaista vastaavaa kohdetta; se palauttaa vain ne kohteet, joiden merkinnän pyytäjällä on selvitys ja kansallinen valtuutus nähdä, suodattaen vastauksen luovutettavaan osajoukkoon. Tämä resurssikohtainen arviointi suoritetaan jokaisessa pyynnössä, ja jokainen pääsypäätös kirjataan auditointia varten.

Siirron turvallisuus on molemminpuolinen TLS — sekä asiakas että palvelin esittävät varmenteet — joten kutsuvan järjestelmän identiteetti muodostetaan kryptografisesti. Kutsuvan käyttäjän federoitu identiteetti muodostetaan OAuth2/OIDC:n kautta, jolloin API on määritetty hyväksymään koalitiokumppaneiden identiteettitarjoajien myöntämät tunnukset Federated Mission Networking -käyttöönotossa. Tämä federoitu luottamusmalli antaa kumppanikansakunnan operaattorin todentautua toisen kansakunnan palvelua vasten ilman jaettua käyttäjähakemistoa. RBAC-perustat ja käytäntömoottorin mallit käsitellään API-yhdyskäytävä koalition tiedonjakoon -oppaassamme.

Versiointi ja taaksepäin yhteensopivuus

Koalition C2-API:lla on monia kuluttajia, eivätkä ne päivity tahdistetusti. Versiointi ei siksi ole valinnaista viimeistelyä — se pitää kumppanijärjestelmät toimivina API:n kehittyessä. Kaksi yleistä strategiaa ovat URI-versiointi (/v2/tracks), joka on eksplisiittinen ja välimuistiystävällinen, ja otsikkopohjainen neuvottelu (versio Accept-otsikossa), joka pitää URI:t vakaina. Käytännöllinen yhdistelmä käyttää URI-pohjaisia pääversioita rikkoville muutoksille ja otsikkoneuvottelua vähäisempään, taaksepäin yhteensopivaan kehitykseen.

Skeeman kehityksen on oltava kurinalaista, koska hyötykuormat seuraavat ulkoisia Nato-standardeja, jotka itse versioituvat. Valinnaisten kenttien lisääminen on taaksepäin yhteensopivaa; kenttien poistaminen, nimeäminen uudelleen tai validoinnin tiukentaminen on rikkovaa ja vaatii uuden pääversion. API:n on kartoitettava eri kumppaneiden toteuttamien MIP4- tai NVG-skeemaversioiden välillä, mikä tarkoittaa useamman kuin yhden skeemaversion tukemista samanaikaisesti siirtymäikkunoiden aikana.

Monikansalliselle järjestelmälle tämä edellyttää julkaistua vanhentamiskäytäntöä: kuinka kauan vanhentunutta versiota tuetaan, kuinka kumppaneille ilmoitetaan ja kuinka siirtymää koordinoidaan. Sellaisen version poistaminen, josta koalitiokumppani yhä riippuu, on operatiivinen häiriö, ei rutiinisiivous. Kuri on jokaisen rikkovan muutoksen kohtelemista monivuotisena siirtona, joka koskettaa suvereeneja kumppaniohjelmia, ja vanhentamisten aikatauluttamista niiden päivityssyklien mukaan, ei sinun julkaisutahtisi mukaan.

NATO Vector Graphics ja taktiset peitteet REST:in kautta

NATO Vector Graphics (NVG) on STANAG-standardoitu XML-muoto graafisen yhteisen operatiivisen kuvan — sotilassymbolien, taktisten johtamistoimenpiteiden, alueiden, reittien — vaihtoon kansallisten C2-järjestelmien välillä. NVG paljastetaan luontevimmin REST-palveluna: asiakas pyytää peitettä päätepisteestä, kuten /nvg/{overlay}, ja saa NVG-XML-asiakirjan, jonka elementit kantavat sijainteja, APP-6 / MIL-STD-2525 -symbolikoodeja ja metatietoja.

Symboliikka tekee NVG:stä yhteentoimivan: koska jokainen grafiikka kantaa vakiomuotoista APP-6- tai MIL-STD-2525-symbolikoodia, vastaanottava järjestelmä renderöi kumppanin peitteen omalla symbolikirjastollaan, ja operaattori näkee oikean, tutun kuvan. Symbolin merkityksestä ei neuvotella; standardi vahvistaa sen.

Kaistanleveys koalitiolinkeillä on rajoitettu, joten päivitysmallit merkitsevät. Naiivi asiakas hakee koko peitteen uudelleen ajastimella; hyvin suunniteltu NVG-palvelu tukee inkrementaalisia päivityksiä, palauttaen vain elementit, jotka muuttuivat asiakkaan viimeisestä kyselystä. Valinta kyselyn ja suoratoiston välillä on todellinen arkkitehtuuripäätös: kysely on yksinkertaista ja palomuuriystävällistä, mutta vaihtaa viiveen pyyntökuormaan, kun taas palvelinpuolen push-suoratoisto antaa pienemmän viiveen avoinna pidettyjen yhteyksien kustannuksella, joita jotkin koalitioverkkorajat kieltävät. Useimmissa NVG-käyttöönotoissa inkrementaalinen kysely järkevällä välillä on käytännöllinen oletusvalinta. Laajempaa FMN-integraatiota käsitellään Federated Mission Networking -toteutusoppaassamme.

Polku FMN- ja CWIX-validointiin

API on yhteentoimiva, kun kumppanijärjestelmä todella käyttää sitä testissä, ei kun sen suunnittelija uskoo skeeman olevan oikein. Federated Mission Networking määrittää palveluvaatimukset: kullekin kyvykkyysalueelle FMN Spiral määrittää pakollisen palvelurajapintaprofiilin, jonka yhteensopivan palvelun on toteutettava. Operatiivisen kuvan API toteuttaa tyypillisesti NVG-palvelun grafiikalle ja MIP4-yhteensopivan palvelun jäsennellylle datalle, soveltaa STANAG 4774/4778 -merkintää, tukee vaadittuja molemminpuolisen TLS:n ja federoidun identiteetin mekanismeja ja rekisteröi itsensä federoituun palvelurekisteriin, jotta kumppanit voivat löytää sen.

Palvelurekisteri saa federoidun ympäristön toimimaan: kovakoodattujen kumppanipäätepisteiden sijaan kukin kansakunta julkaisee palvelunsa rekisteriin, ja kuluttajat löytävät ne ja sitoutuvat niihin dynaamisesti. Tämä on arkkitehtoninen siirtymä piste-pisteeseen-integraatiosta aitoon federaatioon.

Yhteensopivuus todistetaan CWIX:issä, vuosittaisessa Coalition Warrior Interoperability eXercise -harjoituksessa, jossa palvelua testataan reaaliaikaisesti kumppanitoteutuksia vasten. Kurinalainen polku on validoida kumppaneiden viitetoteutuksia vasten ennen CWIX:iä, jotta epäselvyydet — eri tavoin tulkittu valinnainen kenttä, koodiluettelon reunatapaus — ratkaistaan halvassa paikassa eikä havaita harjoituksessa. Sen dokumentointi, mikä FMN Spiral -profiili, mitkä STANAG-versiot ja mitkä skeemaversiot API toteuttaa, on osa akkreditointipakettia ja todistusperustaa hankinnalle.