Federoitu tehtäväverkko: FMN-affiliaatin toteutus

Federated Mission Networking (FMN) on NATO:n viitekehys, jolla kootaan koalition komento- ja ohjausverkko tarpeen mukaan itsenäisten kansakuntien ja organisaatioiden panoksista ilman, että kenenkään tarvitsee luopua omien järjestelmiensä hallinnasta. Lupaus on suoraviivainen: tehtävä voi pystyttää jaetun verkon päivissä kuukausien sijaan, koska jokainen osallistuja rakentaa samoja julkaistuja määrityksiä noudattaen. Työ, joka tarvitaan FMN-affiliaatiksi tulemiseen — oikeiden palvelukäyttöliittymäprofiilien toteuttaminen, liittymisohjeistuksen noudattaminen ja vaatimustenmukaisuuden todistaminen — on se, missä varsinainen tekninen työ sijaitsee. Tässä artikkelissa käydään läpi, mitä affilioituminen edellyttää, miten standardit on jäsennetty ja mikä on käytännön polku kansallisesta C2-pinosta todennetuksi panokseksi toimivassa tehtäväverkossa.

Mitä FMN-affiliaatti oikeastaan on

FMN-affiliaatti on mikä tahansa kansakunta, virasto tai organisaatio, joka vapaaehtoisesti osallistuu federoituun tehtäväverkkoon sovittujen FMN-määritysten mukaisesti. Affilioituminen on viitekehyksen keskeinen käsite: FMN-verkolla ei ole yksittäistä omistajaa eikä keskusjärjestelmää, johon kaikki muodostaisivat yhteyden. Sen sijaan jokainen affiliaatti tuo omat järjestelmänsä ja tarjoaa palveluja, jotka ovat yhteisen peruslinjan mukaisia, niin että tusinan eri kansallisen pinon panokset toimivat yhteen kuin ne olisi rakennettu yhdessä. Viitekehys on samanaikaisesti sekä standardeihin perustuva että federaatiopohjainen — pidät oman infrastruktuurisi, oman akkreditointisi ja oman palvelunhallintasi, ja sopit ainoastaan käyttöliittymistä, joissa kosketat federaatiota.

Tämä erottaa FMN:n jaetun järjestelmän mallista. Jaetun järjestelmän mallissa jokainen osallistuja kirjautuu yhden palveluntarjoajan verkkoon ja hyväksyy kyseisen tarjoajan työkalut. FMN-mallissa osallistuja pysyy suvereenina ympäristönsä suhteen ja tuottaa palveluja, jotka täyttävät julkaistut käyttöliittymäsopimukset. Tämä suunnittelu on se, mikä tekee FMN:stä skaalautuvan muuttuvan koostumuksen koalitioille: affiliaatti voi liittyä yhtä operaatiota varten ja poistua seuraavaa varten, ja verkko rekonfiguroituu kulloinkin läsnä olevien affiliaattien joukon ympärille. Vastineena vaatimustenmukaisuuden kurinalaisuus siirtyy affiliaatille — yhteentoimivuus on yhtä hyvää kuin kunkin affiliaatin uskollisuus määritykselle.

Spiraalit, profiilit ja instanssit: miten standardit on kerrostettu

Kolme termiä ankkuroivat jokaisen FMN-toteutuskeskustelun, ja niiden sekoittaminen on yleisin varhaisten suunnitteluvirheiden lähde.

Spiraali on versioitu peruslinja koko FMN-määritysjoukolle, joka julkaistaan toistuvalla tahdilla. Kukin spiraali kuvaa arkkitehtuurin, palvelujen luettelon, käyttöliittymäprofiilit ja ohjeet, jotka yhdessä määrittelevät, mitä vaatimustenmukainen yhteentoimivuus tarkoittaa kyseisellä hetkellä. Spiraalit etenevät asteittain — ominaisuudet kypsyvät, uusia palveluja lisätään ja aiemmat alustavat elementit tiukentuvat — minkä vuoksi mallia kutsutaan spiraaliksi eikä kiinteäksi standardiksi. Näiden peruslinjojen kehitystä ja kunkin tuomia vaatimuksia käsitellään tarkemmin artikkeleissamme FMN-spiraalin 4 vaatimuksista ja spiraalikarttasuunnitelmasta spiraalin 4 jälkeen.

Palvelukäyttöliittymäprofiilit (SIP) ovat spiraalin normatiiviisia yhteentoimivuussopimuksia. SIP ottaa avoimen standardin ja rajoittaa sitä — kiinnittää protokollasidoksen, pakolliset parametrit, merkistökoodauksen ja versiot — niin, että kaksi itsenäisesti saman SIP:n pohjalta rakennettua järjestelmää toimii yhteen ilman kahdenvälisiä neuvotteluja. Epävirallista viestintäpalvelua koskeva SIP ei esimerkiksi ainoastaan sano "käytä XMPP:tä"; se määrittää tarkat sidokset, ryhmäkeskustelukäyttäytymisen ja osoittamisjärjestelmän niin, että yhden affiliaatin chat-asiakas ja toisen chat-palvelin sopivat jokaisesta yksityiskohdasta. Vaatimustenmukaisuus on profiilille — ei tietylle tuotteelle.

Mission Network Instance (MNI) on konkreettinen, operatiivinen verkko, joka on rakennettu tiettyä tehtävää tai harjoitusta varten affiliaattien panoksista, jotka toteuttavat valitun spiraalin. Spiraali on kirjallinen standardi; MNI on toimiva verkko. Yksi spiraaliperusta voi olla useiden itsenäisten MNI:iden pohjana, joista kullakin on eri isäntäviranomainen ja eri affiliaattijoukko. Kun suunnittelijat sanovat verkon "ajavan spiraalin 4", he tarkoittavat, että MNI koottiin spiraalin 4 palvelukäyttöliittymäprofiileja vastaan.

Panoksesi laajuuden määrittäminen ennen rakentamista

Ensimmäinen insinöörillinen päätös ei ole tekninen vaan laajuutta koskeva: mitä palveluja tuotat ja mitä ainoastaan kulutat? Palvelun tuottaminen — chat-palvelimen, geospatiaalisen palvelun tai hakemiston isännöinti — tuo mukanaan täyden vaatimustenmukaisuuden ja saatavuuden taakan kyseisen palvelun SIP:lle. Palvelun kuluttaminen vaatii ainoastaan vaatimustenmukaisen asiakkaan. Realistinen affiliaattikartta kansalliselle C2-panokselle voisi isännöidä kaksi tai kolme palvelua ja kuluttaa loput muilta affiliaateilta.

Kartoita kukin operatiivinen vaatimus sitä tyydyttäviin profiileihin. Tilannetietoisuudella, epävirallisella viestinnällä, virallisella viestinnällä, puheella, sähköpostilla, geospatiaalisilla palveluilla ja yhteisellä hakemistolla on kullakin oma SIP:nsä tietyssä spiraalissa, ja osa on merkitty pakollisiksi osallistumiselle, osa valinnaisiksi. Tämän kartan rakentaminen ensin estää klassisen virheen, jossa toteutetaan avoimen standardin koko optiovalikoima, kun SIP edellyttää vain kapeaa, rajoitettua osajoukkoa — ja, mikä pahempaa, vahingossa otetaan käyttöön valinnaisia protokollaominaisuuksia, jotka rikkovat yhteentoimivuuden affiliaattejen kanssa, jotka toteuttivat vain pakollisen profiilin.

Palvelukäyttöliittymäprofiilien toteuttaminen

SIP:n toteuttaminen tarkoittaa rajoitetun profiilin toteuttamista — ei emo-standardin toteuttamista. Siellä, missä profiili edellyttää tiettyä protokollaversiota, tiettyä sidontaa, määriteltyä merkistöä tai kiinteää osoittamisjärjestelmää, toteutuksen on vastattava täsmälleen — eikä se saa tarjota vaihtoehtoja, joihin vertaistaho voisi neuvotella. Kurinalaisuus tässä heijastaa opetusta NATO:n yhteentoimivuusstandardeista yleisemmin: profiilin arvo on juuri siinä, että se poistaa valinnaisuuden, ja toteutus, joka palauttaa valinnaisuuden, vesittää tarkoituksen.

Generoi konfiguraatio SIP-taulukoista aina, kun työkalupohja sen sallii. Profiili määrittää tyypillisesti kymmeniä parametreja — aikakatkaisut, uudelleenyrityksen käyttäytyminen, nimeämiskäytännöt, viestikokorajoitukset, pakolliset otsikkokentät. Näiden käsin siirtäminen konfiguraatiotiedostoon on virhealtista, ja tuloksena syntyvät epäsopivuudet ovat juuri sellaisia, jotka läpäisevät omaa asiakastasi vastaan tehdyn pöytätestin, mutta epäonnistuvat, kun toisen affiliaatin toteutus testaa rajaa. Käsittele SIP:tä totuuden lähteenä ja johda konfiguraatio siitä.

Nimeäminen, osoittaminen ja hakemisto

Useat profiilit nojaavat yhteiseen nimeämis- ja osoittamisjärjestelmään, joka asetetaan Mission Network Instance -kohtaisesti eikä spiraalikohtaisesti. Hakemistopalvelu, DNS-rakenne ja osoitteen allokointi on määritelty instanssin ohjeissa, ja jokaisen palvelun, joka julkaisee päätepisteitä tai ratkaisee vertaistahoja, on käytettävä niitä johdonmukaisesti. Affiliaatti, joka toteuttaa jokaisen toiminnallisen SIP:n oikein mutta käyttää vaatimustenmukaista nimeämissuunnitelmaa, epäonnistuu silti federoinnissa, koska vertaistahot eivät pysty löytämään tai ratkaisemaan sen palveluja. Käsittele nimeämistä ja osoittamista toteutuksen ensiluokkaisena osana — ei jälkiajatuksena, joka hoidetaan yhteyshetkellä.

Liittymisohjeistus ja federaatioraja

Jokainen Mission Network Instance julkaisee Joining, Membership and Exit Instructions (JMEI) -ohjeet. Nämä määrittelevät osallistumisen käytännölliset ehdot: nimeämis- ja osoittamissuunnitelman, tietoturva- ja luokittelupolitiikan, palvelunhallinnan käyttöliittymät, rekisteröintiprosessin ja ehdot, joiden vallitessa affiliaatti muodostaa yhteyden, pysyy yhteydessä ja katkai sen. Affilioitumista hallinnoidaan sopimuksella, ja JMEI on se sopimus konkretisoituna tietylle verkolle.

Federaatioraja on se, missä kansallinen tai yritysverkko kohtaa tehtäväverkon, ja se on toteutuksen korkeariskisin osa. Täällä affiliaatti valvoo luokittelu-, vapautus- ja suodatushallintaa, jota tietoturva-ohjeet edellyttävät, ja akkreditoi mahdolliset rajoja suojaavat tai verkon välisiä yhteyksiä mahdollistavat komponentit sovitun riskiasennon mukaisesti. Virheellisesti konfiguroidut vapautussäännöt tässä rajassa ovat johtava syy kahteen vastakkaiseen epäonnistumiseen: palvelut, jotka eivät federoidu, koska laillinen liikenne on estetty, ja tietovuodot, koska liikenne, joka olisi pitänyt pidättää, vapautettiin. Tässä vaadittava kurinalaisuus liittyy suoraan laajempaan koalition tiedonjaon ongelmaan, jossa politiikka- ja luokittelupäätökset merkitsevät yhtä paljon kuin protokollavaatimustenmukaisuus.

Palvelunhallinta federaation laajuudella

FMN käsittelee palvelunhallintaa federoituna toimintona. Jokainen affiliaatti hallitsee omia palvelujaan, mutta sen on tarjottava sovittuja palvelunhallintatietoja — saatavuus, häiriöt, muutosilmoitukset — jotta verkko kokonaisuudessaan voidaan operoida. Tehtäväverkkoon liittyvä affiliaatti perii velvoitteen raportoida ja koordinoida verkon palvelunhallintaprosessin kautta — ei ainoastaan ajaa palvelujaan eristyksissä. Tämän operatiivisen sitoumuksen aliarviointi on yleistä: tekninen yhteys on kertaluonteinen tapahtuma, mutta palvelunhallintavelvoite jatkuu koko affilioitumisen ajan.

Vaatimustenmukaisuuden todentaminen

Vaatimustenmukaisuuden todentaminen etenee kahdessa vaiheessa. Ensimmäinen on referenssitestaus: kunkin tuotetun palvelun testaaminen spiraalin palvelukäyttöliittymäprofiileja vastaan laboratorio- tai referenssiympäristössä, protokollasidosten, viestirakenteiden, nimeämisen, osoittamisen ja tietoturvaparametrien vahvistaminen profiilinmukaisiksi. Tämä on välttämätöntä, mutta se testaa toteutuksen itseään ja kontrolloitua referenssiä vastaan — eli helppoa tapausta.

Toinen vaihe on federoitu todentaminen muiden affiliaattien todellisia toteutuksia vastaan, tyypillisesti koalition testitapahtumassa kuten CWIX:ssä. Tässä toteutus kohtaa itsenäisesti rakennettuja vertaistahoja, jotka testaavat samoja profiileja, ja tässä jäljelle jääneet epäsopivuudet paljastuvat — hienovaraiset merkistöerot, ajoitusoletukset, valinnaiset ominaisuudet, jotka toinen osapuoli otti käyttöön ja toinen ei, nimeämissuunnitelman poikkeamat. Itseilmoitettu vaatimustenmukaisuus ei koskaan riitä; federoitu todentaminen on se vaihe, joka muuttaa paperilla vaatimustenmukaisen toteutuksen sellaiseksi, joka todella toimii yhteen. Suunnittele iteroiminen ensimmäisen federoidun tapahtuman jälkeen, koska ensimmäinen kohtaaminen todellisten vertaistahoja kanssa paljastaa lähes aina jotain sellaista, mitä kahdenvälinen labtestaustestaus ei pystyisi havaitsemaan.

Kun todentamis- ja akkreditointiedellytykset täyttyvät, Mission Network Instancen isäntäviranomainen hyväksyy yhteyden, ja todennetut palvelut siirtyvät operatiiviselle verkolle. Tästä hetkestä lähtien affiliaatti on täysi osallistuja — tuottaa palveluja, joihin muut luottavat, kuluttaa palveluja, joihin se itse luottaa, ja kantaa palvelunhallintavelvoitteet, jotka pitävät federaation toimintakykyisenä.