TAK Federation Hub: arkkitehtuuri, käyttöönotto ja milloin valita se suoran federaation sijaan

TAK Federation Hub on valinnainen brokeri, joka julkaistiin TAK Serverin rinnalla. Sen sijaan että jokainen TAK Server federoidaan suoraan jokaisen muun kanssa, kukin palvelin avaa yhden federaatioyhteyden hubiin; hubi todentaa federaatit ja välittää datan ylläpitäjän määrittelemän käytäntögraafin mukaan ryhmäsuodattimet jokaisessa kaarella. Ota se käyttöön, kun yhdistät enemmän kuin kolme palvelinta tai useita hallinnollisia toimialueita.

Tämä sivu käsittelee arkkitehtuuripäätöstä (hub vai suora palvelimesta palvelimeen -federaatio) ja sitä, mitä hubin ylläpito edellyttää: protokollaversiot ja oletusportit, käytäntömalli, PKI, käyttöönotto, ylläpito ja vianetsintä. Yksittäisen suoran yhteyden kahden palvelimen välillä konfiguroit meidän TAK Server -federaation käyttöönotto-oppaamme avulla.

• Mikä se on: tähtimallinen (hub and spoke) brokeri TAK Server -federaatiolle (käytännönhallinta, viestintäbrokeri, ylläpitäjän web-käyttöliittymä).
• Oletusportit: 9102/tcp federaatio v2, 9101/tcp federaatio v1, 9100/tcp ylläpitokäyttöliittymä.
• Riippuvuudet: Java 17 ja MongoDB; toimitetaan RPM-, DEB- ja Docker-pakettina.
• Kypsyys: TAK Serverin konfiguraatio-opas (versio 5.7, maaliskuu 2026) merkitsee hubin asentimen edelleen ”betaksi”.

Miksi Federation Hub: suoran federaation N²-ongelma

Suora federaatio on ohjelmistolla toteutettu kaksikantainen sopimus. TAK Serverin konfiguraatio-oppaan mukaan kaksi ylläpitäjää vaihtaa CA-sertifikaatteja, jotka kukin palvelin säilyttää federaation luottamusvarastossa erillään paikallisten käyttäjien varastosta, joten kumppanin palvelin voi yhdistää mutta kumppanin ATAK-laitteet eivät. Toinen kahdesta palvelimesta luo lähtevän yhteyden, ja molemmat osapuolet valitsevat, mitkä ryhmät saavat lähteä heidän palvelimeltaan ja saapua sille. Asiakkaat eivät vaadi uudelleenkonfigurointia.

Kahdelle tai kolmelle palvelimelle se riittää. Täysverkon (full mesh) n palvelinta vaatii n(n−1)/2 yhteyttä: 6 neljällä palvelimella, 45 kymmenellä. Jokainen yhteys tarkoittaa CA-vaihtoa, palomuurin avausta kuuntelevalla puolella ja ryhmäasetuksia molemmissa päissä, ja jokainen käytännön muutos toistetaan yhteyttä kohti.

Federation Hub korvaa verkon tähtiverkolla. Jokainen TAK Server federoiduu kertaalleen, hubiin, joka hallinnoi yhteyksiä ja luottamusta ja välittää jokaisen viestin käytäntögraafin kaaria pitkin suodatettuna TAK-ryhmittäin. Kolme asiaa muuttuu:

• Luottamus: kukin TAK Server tuo sisään yhden ulkoisen CA:n — hubin — yhden kumppania kohden sijaan. Kumppanien CA:t pitää hubi.
• Saavutettavuus: haarat soittavat yleensä itse hubiin, joten NAT:n tai yksisuuntaisten palomuurien takana olevat etupalvelimet eivät tarvitse saapuvia aukkoja. Vain hubi kuuntelee.
• Käytäntö: kuka saa mitä, elää yhdessä graafissa kymmenien palvelinkohtaisten asetusten sijaan, ja kukin palvelin silti ohjaa, mitä sen rajalta lähtee.

Kustannukset ovat yhtä todellisia: ylimääräinen brokerivälitys jokaisessa palvelinten välisessä viestissä, uusi arvokas järjestelmä, joka päättää jokaisen federaatioistunnon ja näkee kaiken välitetyn liikenteen, sekä yksittäinen vikapiste palvelinten väliselle vaihdolle. Kun hubi on poissa käytöstä, kunkin palvelimen paikallinen tilannekuva jatkaa toimintaansa; vain vaihto pysähtyy.

Federaatioprotokollan versiot ja oletusportit

TAK Server puhuu kahta federaatioprotokollaa. Federaatio v1 on alkuperäinen: pitkäikäinen TLS-soketti, joka kantaa protobuf-koodattuja federaatiotapahtumia. Federaatio v2 kuljettaa protobuf-viestit gRPC:n (HTTP/2) yli samalla keskinäisellä TLS:llä, ja se on se versio, joka on käytössä TAK Serverin esimerkkikonfiguraatiossa, jossa v1 toimitetaan pois käytöstä. Protokolla valitaan lähtevää yhteyttä kohden, ja oppaan varoitus pätee: valitse protokollaversio, joka vastaa porttia, johon yhdistät. Asiakaspuolesta lue TAK-protokolla: CoT XML vs. protobuf.

Nämä ovat oletusarvoja; vahvista ne omista tiedostoistasi. TAK Serverin esimerkkikonfiguraatio:

<federation>
  <federation-server port="9000" v1enabled="false" v2port="9001" v2enabled="true">
    <tls context="TLSv1.2" keymanager="SunX509"
         keystore="JKS" keystoreFile="certs/files/takserver.jks" keystorePass="atakatak"
         truststore="JKS" truststoreFile="certs/files/fed-truststore.jks" truststorePass="atakatak"/>
  </federation-server>
</federation>

Ja hubin brokerikonfiguraatio, /opt/tak/federation-hub/configs/federation-hub-broker.yml (otteen):

v1Enabled: true
v1Port: 9101
v2Enabled: true
v2Port: 9102
dbPort: 27017

Käytännön sääntö: yhtenäistä kaikki yhteydet v2:een, osoita TAK Serverin lähtevät yhteydet hubin porttiin 9102 ja sammuta v1 hubista, ellei vanha vertainen enää tarvitse sitä. Myös ryhmäsuodatus riippuu siitä: v1-yhteydet eivät kanna TAK-ryhmätietoa hubille, joten mikä tahansa kaarista, joka suodattaa ryhmän mukaan, hylkää v1-liikenteen.

Miten Federation Hub reitittää liikennettä: käytäntögraafi ja ryhmäsuodattimet

Hubi toimii yhteistyötä tekevinä Java-palveluina yhden federation-hub-järjestelmäpalvelun alla: käytännönhallinta, viestintäbrokeri ja ylläpitäjän web-käyttöliittymä (uusimmat paketit lisäävät lisäosahallinnan). Reititys tulee käyttöliittymässä piirtämästäsi käytäntögraafista. Sen solmut ovat:

• CA-ryhmät: jokainen federaatti, jonka sertifikaatti ketjuuntuu palveluun ladattuun CA:han, liittyy kyseisen CA:n ryhmään. Useimmat käytännöt kirjoitetaan CA-ryhmiä vasten, mikä käytännössä tarkoittaa organisaatioita vasten.
• Federaatit: yksittäiset TAK Serverit, silloin kun yksi palvelin tarvitsee eri kohtelun kuin organisaationsa loput.
• Lähtevät yhteydet: yhteydet, jotka hubi itse avaa TAK Serveriin tai toiseen hubiin — näin rakennetaan monihyppyiset hubista hubiin -topologiat.
• Token-ryhmät: federaatit, jotka todentavat tokenilla keskinäisen TLS:n sijaan.

Kaaret ovat suunnattuja. Kaari A:sta B:hen antaa A:n liikenteen saavuttaa B:n, ei päinvastoin, joten kaksisuuntainen jakaminen vaatii kaksi kaarta, ja yksisuuntaiset syötteet (kumppani, joka vastaanottaa omien joukkojesi tilannekuvan mutta ei lähetä mitään takaisin) ovat täysivaltinen malli. Jokainen kaari kantaa ryhmäsuodattimen: kaikki ryhmät, sallitut ryhmät, kielletyt ryhmät tai sallitut ja kielletyt. Ryhmät ovat kuhunkin viestiin kiinnittyviä TAK Server -ryhmiä, jotka ATAK-käyttäjät näkevät kanavina. Viesti läpäisee sallittujen luettelon kaaren, jos vähintään yksi sen ryhmistä on luettelossa, ja kaatuu estettyjen luettelon kaareen, jos yksikin sen ryhmistä on luettelossa; viesti ilman ryhmiä läpäisee vain kaikki-ryhmät-kaaren.

CA-ryhmillä on myös Interconnected-lippu: yhdistetyn ryhmän jäsenet vaihtavat keskenään kaiken — ilman kaarta ja ilman suodatusta. Se on kätevää yhden organisaation sisällä ja vaarallista koalitiossa, joten tarkista se jokaisesta lisäämästäsi ryhmästä. Editori erottaa myös käytännön tallentamisen sen aktivoinnista; tallennettu mutta passiivinen käytäntö ei muuta mitään.

Dataminimointi: kolme suodatusvaihetta

1. Lähtevä TAK Server: hubin federaatille asetetut lähtevät ryhmät ratkaisevat, mitä palvelimesi rajalta ylipäätään lähtee. Koalitiossa tämä on ainoa vaihe, jota hallitset täysin.
2. Hubin kaaret: ne ratkaisevat, mitkä kohteet saavat mitkä ryhmät.
3. Kohde-TAK Server: saapuvat ryhmät ja federroitujen ryhmien määritys ratkaisevat, mitkä paikalliset käyttäjät näkevät saapuvan liikenteen.

Tiedostot tarvitsevat omat säännöt. TAK Serverin Data Package- ja Mission File -esto estää federoidut tiedostot päätteen mukaan (oletuksena pref, jolloin konfiguraatiotiedostot eivät voi uudelleenkonfiguroida kumppanien laitteita), ja missioiden federaatio on erillinen päätös CoT-jakamisesta; katso TAK:n datapaketit ja missiopaketit. Opas esittää rajan myös suoraan: kukin toimialue ohjaa sitä, mitä se jakaa, ei sitä, mitä toinen toimialue sillä tekee. Asiakkaat pysyvät kaiken tämän ulkopuolella: ATAK, WinTAK ja selainasiakkaat kuten CloudTAK puhuvat edelleen omalle palvelimelleen.

Sertifikaattien luottamusmalli: CA:t, federaattien identiteetit ja peruutus

Federaation luottamus on CA-pohjaista keskinäistä TLS:ää. Hubitopologiassa:

• Jokainen TAK Server tuo hubin CA:n federaationsa luottamusvarastoon (hubin käyttöliittymä osaa ladata oman CA:nsa) ja esittää palvelinsertifikaattinsa yhdistyessään.
• Hubi tuo kunkin organisaation CA:n; lataaminen luo CA-ryhmän, johon käytäntö viittaa.
• Federaatin identiteetti on sen sertifikaatti, ja myöntöketju ratkaisee sen CA-ryhmät. Palvelin, jonka ketju sisältää väli-CA:n, voi päätyä useisiin CA-ryhmiin — silloin kaikkien niiden kaarien on annettava liikenteen kulkea.

Tästä seuraa neljä suunnittelusääntöä:

• Käytä omaa federaatio-CA:ta joka organisaatiolle. Konfiguraatio-opas kuvaa tämän vaihtoehtoisen järjestelyn — erillisen CA:n ja palvelinsertifikaatin vain federaatiolle — jotta kumppanit eivät koskaan näkisi asiakassertifikaattisi allekirjoittavaa CA:ta, ja yhden CA:n poistaminen hubista katkaisee täsmälleen yhden organisaation.
• Suunnittele peruutus ennen kuin tarvitset sitä. CA-ryhmään kirjoitetut kaaret koskevat jokaista kyseisen CA:n palvelinta. Katkaistaksesi yhden vaarantuneen palvelimen koskematta sen organisaatioon, anna korkean riskin vertaisille federaattikohtaiset kaaret tai nojaa peruutustarkistukseen (hubin brokerissa on OCSP-valinta, oletuksena pois). Eristetyt verkot ilman OCSP-vastaajaa nojaavat lyhyisiin sertifikaattien voimassa-aikoihin ja harjoiteltuun CA:n poistomenettelyyn.
• Suojaa hubin avain kuin CA:n avain ja vaihda avainvarastojen oletussalasanat (atakatak toimitetuissa esimerkeissä): kenellä hubin avain on, voi esiintyä hubina jokaista haaraa kohtaan.
• Pitä token-todennusta poikkeuksena. TAK Server ja hubi voivat todentaa federaation tokenilla siellä, missä TLS-tarkastusta tekevät välityspalvelimet (”break and inspect”) tekevät keskinäisestä TLS:stä mahdottoman; opas itsekin toteaa tokenien olevan mTLS:ää vähemmän turvallisia.

PKI-suunnittelusta kumppanimaiden kesken katso koalition identiteettien hallinta.

Federation Hubin asennus ja käyttöönottovaihtoehdot

Hubi levitetään tak.gov:ssa omana pakettinaan TAK Serverin rinnalla: takserver-fed-hub RPM:nä (RHEL, Rocky) tai DEB:nä (Ubuntu, Debian), plus Docker-paketti, joka parittaa hubikuvan erillisen MongoDB-kuvan kanssa. Se vaatii Java 17:n ja MongoDB:n, johon brokeri tallentaa federaatiotapahtumat ja metatiedot, ja toimii samalla isännällä olevan TAK Serverin kanssa tai ilman sitä. Anna teatterin tai koalition hubille oma isäntäkone: se on luottamusankkuri jokaiselle kumppanille, eikä sen pitäisi jakaa vikatoimialuetta tai ylläpitotiimiä minkään haaran kanssa.

1. PKI. Luo hubin CA ja palvelinsertifikaatti samoin skriptein ja menettelyin kuin TAK Serverille (konfiguraatio-oppaan liite B); avainvarasto ja luottamusvarasto sijaitsevat polussa /opt/tak/federation-hub/certs/files/.
2. Asennus. Asenna Java 17, hubin paketti ja MongoDB; aseta tietokannan tunnukset tiedostoon federation-hub-broker.yml ja aja hubin tietokannan konfigurointiskripti.
3. Käynnistys ja valtuutus. Käynnistä palvelu, valtuuta ylläpitosertifikaatti ja kirjaudu sillä käyttöliittymään portissa 9100 (komennot alla).
4. CA-vaihto. Lataa kunkin kumppanin federaatio-CA hubin käyttöliittymässä ja lähetä jokaiselle kumppanille hubin CA.
5. Piirrä käytäntö. Lisää CA-ryhmät (ja yksittäisiä federaatteja tarvittaessa), yhdistä ne suunnatuilla kaarilla, aseta kunkin kaaren ryhmäsuodatin, päätä Interconnected ryhmäkohtaisesti ja tallenna ja aktivoi sitten.
6. Yhdistä jokainen TAK Server. Ota federaatio v2 käyttöön, lataa hubin CA kohtaan Federate Certificate Authorities, luo lähtevä yhteys hubiin portissa 9102 protokollalla v2 ja aseta sitten hubin federaatin lähtevät ja saapuvat ryhmät.
7. Testaa molempiin suuntiin. Lähetä tunnettu testijälki ryhmässä, jonka pitää läpäistä, ja toinen ryhmässä, joka pitää estää (meidän annotoidut CoT-viestiesimerkkimme ovat käteviä koekappaleita), ja varmista sitten, että hubin Active Connections -näkymä näyttää odotetun protokollaversion ja ryhmäidentiteetit.

sudo systemctl restart federation-hub
sudo systemctl enable federation-hub

# authorize an administrator certificate (written to authorized_users.yml)
sudo su tak
java -jar /opt/tak/federation-hub/jars/federation-hub-manager.jar /path/to/admin.pem
exit

# then open https://hub.example.org:9100/ and log in with that certificate

Federation Hubin käytettävyys ja valvonta

Federation Hubin julkinen dokumentaatio ei kuvaa aktiivis-aktiivista, klusteroitua hubia, joten suunnittele nopeasti heräävä lämmin varajärjestelmä nollan katkon sijaan:

• Varmuuskopioi hubin tila: sertifikaatit ja avainvarastot, käytäntötiedostot, authorized_users.yml, configs-hakemisto ja MongoDB-tietokanta. Hubin päivitysmuistiinpanot kehottavat tallentamaan ensin käytäntötiedoston ja valtuutetut käyttäjät.
• Pidä varajärjestelmä identtisillä sertifikaateilla ja käytännöllä siirrettävän DNS-nimen tai virtuaali-IP:n takana. TAK Serverit yhdistävät uudelleen itse, kunkin lähtevän yhteyden uudelleenyhdistysvälin mukaisesti.
• Tee haaroista kestäviä: hubin katko pysäyttää jakamisen, ei paikallisia toimintoja, joten suurin osa käytettävyystyöstä kuuluu kullekin palvelimelle; katso TAK Serverin korkea käytettävyys ja klusterointi.
• Mitoita mittauksista: erillistä julkaistua hubin mitoitusta ei ole. Lähde oppaan TAK Server -peruslinjasta (4 ydintä, 8 GT RAM-muistia, 40 GB levyä) ja seuraa sitten kekoa ja viestitiheyttä harjoituskuormassa; palvelinpuolen säätimet ovat TAK Serverin suorituskyvyn virityksessä.

Valvo kolmella tasolla. Hubin käyttöliittymässä mittaristö näyttää yhteydet yhteensä, luet ja kirjoitetut sekunnissa, tavut sekunnissa, suorittimen ja keon, ja Active Connections -taulukko luettelee kunkin federaatin etäosoitteen, protokollaversion ja ryhmäidentiteetit. Isäntäkoneilla kerää /opt/tak/federation-hub/logs ja seuraa kunkin TAK Serverin federaatiotilaa. Ulkopuolelta kokeile portteja 9102 ja 9100, hälytä jokaisen federaatin CA:n ja palvelinsertifikaatin vanhenemisesta, seuraa NTP-poikkeamaa ja hälytä, kun yhdistettyjen federaattien määrä putoaa odotetun alle.

Käyttömallit: teatterin, koalition, harjoituksen ja toimialueen hubit

Teatterin hubi

Alayksiköt pyörittävät omia TAK Serverejään ja federoiduvat ylöspäin ylempänä esikunnassa olevaan hubiin. Yksiköt pitävät paikallisen tilannekuvansa, kun taustayhteys (backhaul) pettää, hubi päättää, mikä johtoportas näkee mitkä ryhmät, ja itsesoittavat haarat sopivat NAT:n tai satelliittiterminaalien takana oleville etupalvelimille.

Koalition hubi

Kukin valtio pitää oman TAK Serverinsä, CA:nsa ja ylläpitäjänsä; johtavan valtion tai molemmin puolin luotetun osapuolen pyörittämä hubi kantaa yhteisen tilannekuvan, ja suunnatut kaaret ja sallittujen luettelot koodaavat julkaisupäätökset. Kansalliset lähtevät ryhmät pysyvät ensimmäisenä ohjauslinjana. Jos koalitio käyttää myös NATO-muotoja, kansallisen rajan ylityspalvelu hoitaa kääntämisen; katso CoT:n ja NATO-standardien siltaaminen sekä FMN-affiliaatin toteutus.

Harjoituksen hubi

Oman harjoitus-CA:n, lyhytikäisten sertifikaattien ja skenaariokohtaisen käytännön hubi antaa osallistujien liittyä ja lähteä koskematta toistensa palvelimiin. Jälkikäteen poistat yhden CA:n ja käytät käytännön pois; tapahtuman aikana hubin yhteyttaulu palvelee myös läsnäolo- ja kuntotaulua.

Yksi hubi per luokittelutaso

Hubi suodattaa ryhmän mukaan; se ei ole vartija. Se ei tarkasta sisältöä julkaisusääntöihin nähden eikä sillä ole akkreditointia siirtää dataa luokittelutasojen välillä. Aja erillinen hubi jokaista turvallisuusaluetta kohti ja yhdistä alueet vain akkreditoidun toimialueiden välisen ratkaisun (CDS) kautta — erillisen tuotteen, jolla on oma akkreditointinsa; katso toimialueiden välisen ratkaisun vartiointiarkkitehtuuri.

Hubit voivat myös avata lähteviä yhteyksiä muihin hubeihin, joten kansallinen hubi voi pariautua koalition hubin kanssa. Pidä tällaiset ketjut lyhyinä: jokainen hyppy lisää viiveen ja vielä yhden käytännön, joka pitää pitää yhdenmukaisena.

Federation Hub -yhteyden vianetsintä

• TLS-kättely epäonnistuu tai yhteys yhdistää jatkuvasti uudelleen. Yleensä ketju: haaran on luotettava hubin CA:han (ei vain sen palvelinsertifikaattiin), hubin on pidettävä haaran myöntävä CA väli-CA:t mukaan lukien, kukaan ei saa olla vaihtanut asiakassertifikaattia, eikä mikään saa olla vanhentunut.
• Yhdistetty, mutta mikään ei kulje. Käytäntö, ei verkko: onko haaran CA-ryhmä aktiivisessa käytännössä, onko kaari olemassa odottamassasi suunnassa, asettiko lähtepalvelin lähtevät ryhmät hubin federaatille ja asettiko kohde saapuvat ryhmät?
• Osa ryhmistä kulkee, osa ei. Ryhmänimien on vastattava tarkasti, viesti ilman ryhmiä läpäisee vain kaikki-ryhmät-kaaret, eivätkä v1-yhteydet kanna ryhmiä. Vastaanottavassa TAK Serverissä federroitujen ryhmien määritys palautuu federaatin ryhmäasetuksiin, kun mikään määritys ei osu.
• Kulkee liikaa. Etsi ensin Interconnected-CA-ryhmä tai kaikki-ryhmät-kaari.
• Kellojen ero. Sertifikaattien tarkistus sekä CoT:n aika ja tuoreus riippuvat kellosta; aja NTP yhteisestä lähteestä hubissa ja jokaisessa haarassa.
• Palomuuri, NAT ja välityspalvelimet. Hubin on hyväksyttävä 9102/tcp (ja 9100/tcp vain ylläpitoverkoista); tilalliset palomuurit lyhyillä joutoajan katkaisuilla katkaisevat hiljaiset yhteydet; TLS-tarkastusta tekevät välityspalvelimet rikkovat keskinäisen TLS:n — jätä federaatiopolku tarkastuksen ulkopuolelle tai käytä token-todennusta.
• Versioristiriita. Lähtevä yhteys, joka on asetettu v2:lle mutta osoittaa v1-porttiin — tai päinvastoin — ei nouse koskaan.
• Kloonatut palvelimet. TAK Server kirjoittaa satunnaisen palvelintunnisteen CoreConfig.xml:ään ensimmäisellä käynnistyksellä ja leimaa sen virtausmerkinnäksi käsiteltyihin viesteihin hyläten kaiken, joka kantaa jo sen omaa merkintää, estääkseen reititysilmukat. Kloonatusta, jo alustetusta palvelimesta tehdyt federaatit jakavat saman tunnisteen; anna jokaiselle oma.

# Which certificate chain does the hub present on the v2 port?
openssl s_client -connect hub.example.org:9102 -showcerts </dev/null

# Which CAs does this TAK Server trust for federation?
keytool -list -keystore /opt/tak/certs/files/fed-truststore.jks

# Is this host's clock synchronised?
timedatectl status

Suora federaatio vs. Federation Hub vs. yksi yhteinen TAK Server

Nyrkkisääntö: kahdelle tai kolmelle vakaalle kumppanille federoi suoraan. Neljälle tai useammalle palvelimelle, useille hallinnollisille toimialueille tai joka harjoituksessa vaihtuvalle kumppaniluettelolle käytä hubia. Yhdelle organisaatiolle yhdellä ylläpitotiimillä yksi klusteroitu TAK Server ryhmineen on yksinkertaisempi kuin mikään federaatio.

Federaation suunnittelun tarkistuslista

1. Inventoi jokainen federaatti: omistaja, TAK Server -versio, saavutettavuus ja protokolla (v2).
2. Valitse topologia yllä olevan taulukon mukaan; nimeä hubin operaattori ja sen konfiguraation hyväksyjä.
3. Suunnittele PKI: federaatio-CA joka organisaatiolle, sertifikaattien voimassa-ajat, uusintapäivät ja peruutusmenettely; vaihda avainvarastojen oletussalasanat.
4. Sopikaa kumppanien kanssa ryhmäluettelosta: tarkat ryhmänimet, mitä kukin palvelin lähettää (lähtevät) ja vastaanottaa (saapuvat).
5. Piirrä käytäntögraafi ensin paperille: suunnatut kaaret, suodatintyyppi kaarta kohti ja eksplisiittinen Interconnected-päätös jokaista CA-ryhmää kohti.
6. Päätä tiedostojen ja missioiden federaatio erikseen CoT:sta ja pidä pref-tiedostoestois päällä.
7. Avaa palomuuri: 9102/tcp saapuvana hubiin, 9100/tcp vain ylläpitoverkoista, haaroille vain lähtevä; tarkista NAT:n joutoajan katkaisut ja TLS-tarkastus.
8. Synkronoi aika jokaisessa isäntäkoneessa.
9. Kirjoita testimatriisi, jossa on yksi pakosti läpäistävä ja yksi pakosti estettävä tapaus jokaista kaarta kohti, ja aja se uudelleen jokaisen käytännön muutoksen jälkeen.
10. Rakenna valvonta, varmuuskopiot ja harjoiteltu siirtyminen varahubiin.
11. Pidä yksi hubi per turvallisuusalue; kaikki alueiden yli menevä kulkee akkreditoidun toimialueiden välisen ratkaisun kautta.