Hvernig á að senda skrár tækis á fjarlægan safnara á öruggan hátt

Tækið getur gefið frá sér skrár, safnarinn situr hinum megin við internetið, og fyrsta spurningin sem allir spyrja er hvaða göng skuli byggja. Þessi rammi byrjar á röngum stað. Það sem ræður flutningnum er sniðið sem tækið getur framleitt, auðkenningin sem safnarinn mun samþykkja, og hvað „afhent“ á að þýða þegar tengingin dettur. Skrifaðu þessi þrjú svör niður, og flutningurinn velur sig venjulega sjálfur.

Byrjaðu á því sem tækið getur gefið frá sér

Í reynd eru aðeins þrjú form. Einstök syslog-atburðir yfir UDP eða TCP, auðkennd HTTPS-hleðsla sem er innbyggð í vöruna, eða heil skrár sem skrifaðar eru á disk og verður að flytja. Eldveggur sem getur aðeins sent UDP-syslog verður ekki TLS-sendandi vegna þess að þú bættir við göngum; hann mun áfram senda óstaðfest datagram, nú inni í dulkóðuðu umslagi.

Byrjaðu því á að skrá sendandann: samskiptareglur, TLS-stuðning og hvaða TLS-safn, hvort hann getur staðfest skírteini safnarans, hvort hann getur lagt fram biðlaraskírteini, og hvort sendingarbiðflýtirinn lifir endurræsingu. Allt sem tækið getur ekki gert verður eitthvað annað á leiðinni að gera, og það eitthvað annað verður hluti af hönnun þinni.

TLS syslog: stysta leiðin þegar báðir endar tala hana

Ef tækið styður syslog yfir TLS og safnarinn lýkur því, notaðu það og stoppaðu. Forritasamskiptareglurnar verja sig sjálfar, safnarinn auðkennir sendandann, og það er engin auka hopp sem þú átt nú tiltækileika á. Gildran er að „TLS syslog“ nær yfir breitt svið útfærsla, og núverandi leiðbeiningar um öruggt syslog hafa færst framhjá dulritunarlistum í eldri kennsluefni, og þess vegna brotnar vinnandi framsending þegar safn er uppfært.

Í rsyslog segir nafn flutningsmátulans eitt og sér hvaða tímabil þú ert á: lmnsd_gtls vefur GnuTLS, á meðan lmnsd_ossl vefur OpenSSL og það er það sem núverandi 8.x-pakkar senda. Framsendaaðgerð með skírteinisstaðfestingu lítur nokkurn veginn svona út, og nákvæm heiti færibreytna er þess virði að bera saman við uppsettu útgáfuna:

action(type="omfwd" target="collector.example" port="6514" protocol="tcp"
       StreamDriver.Name="ossl" StreamDriver.Mode="1" StreamDriver.AuthMode="x509/name"
       StreamDriver.CAFile="/etc/pki/ca.pem"
       queue.type="LinkedList" queue.filename="fwdq" queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on" action.resumeRetryCount="-1")

Staðfestu endapunktinn áður en þú villuleitar sendandann. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error annaðhvort lýkur handabandi með gildri keðju eða segir þér nákvæmlega hvaða athugun mistókst. Prófaðu frá tækinu, ekki frá fartölvunni, því traustgeymsla tækisins skiptir máli.

SFTP: gott fyrir skrár, rangt fyrir streymi

Skrárbundin afhending hentar tækjum sem skrifa snúningsskrár og ekkert annað. SSH-flutningur gefur þér hýsilinnlykla, lykla fyrir hvern reikning og skráarkerfi sem þú getur endurskoðað, sem er sanngjörn traustssaga fyrir tæki sem getur alls ekki TLS. Það er slæmt val fyrir atburðastreymi, þar sem „skráin er skrifuð á klukkustundar fresti“ þýðir að bil kostar þig hala núverandi klukkustundar.

Haltu hýsilstaðfestingu á. Raðkall sem slokknir á henni til að komast hjá kvaðningu eyðileggur eina auðkenninguna sem flutningurinn hefur:

sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes      -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]

Festu hýsilinnlykilinn í known_hosts reikningsins við undirbúning, takmarkaðu reikninginn við markmöppuna, og veldu internal-sftp undirkerfið með chroot. Skipuleggðu líka endursendingarsöguna: ef skrá er send aftur eftir hluta mistök, verður safnarinn að greina tvírit frá nýrri skrá, venjulega eftir nafni auk gátsummu en ekki komutíma.

Þegar staðbundin gátt eða göng er heiðarlegt svar

Sum tæki geta aðeins talað snið sem enginn vill afhjúpa. Í því tilviki tekur heimilaður safnari á eigin neti tækisins við upprunalega sniðinu og sendir það áfram yfir TLS. Það er lögmæt hönnun, en vertu nákvæmur um hvað hún kaupir: dulkóðun sem byrjar við gáttina verndar ekki afturvirkt hlutað milli tækisins og gáttarinnar, svo það hopp þarf enn sína eigin traustmörk og aðgangsstýringu.

Beint staðar- eða tækjagöng er þyngsti valkosturinn og sá rétti þegar safnarinn verður að halda einkaaðsetri og bera nokkrar þjónustur, ekki bara skrár. Það færir áætlanagerð um heimilisföng, aðgangsreglur, endurleiðir og lífsferil endapunkts ganganna. Það bætir heldur ekki innra samskiptareglunum: UDP-syslog inni í IPsec-göngum er áfram datagram-þjónusta án afhendingarstaðfestingar.

Hvað sem þú velur, haltu heimild safnarans þrengri en flutningnum. Auðkenni ganga tilheyrir endapunkti og segir ekkert um hvaða tæki neðar framleiddi tiltekið hýsilnafnasvið í skilaboðum.

Skrifaðu afhendingarsamninginn áður en þú sendir

Dulkóðun, auðkenning og varðveisla svara mismunandi spurningum, og biðröð er ekki varðveislustefna. Áður en fyrsta skráin yfirgefur tækið, ákveddu hvað staðfesting þýðir í raun á þessum safnara: móttekið á línunni, samþykkt til vinnslu, eða varanlega skrifað í geymslu. Þetta eru þrjár mismunandi ábyrgðir og aðeins sú síðasta lifir endurræsingu safnarans.

Svaraðu síðan rekstrarspurningunum skriflega. Hvar bíða ósendir atburðir, og lifir sá biðflýtir rafmagnsleysi? Hvað gerist þegar hann fyllist, og hverjum er tilkynnt? Hvernig eru endurtilraunir takmarkaðar, og hvernig eru tvírit auðkennd? Hvaða svið sannar auðkenni sendandans, í ljósi þess að framsendingarhopp getur endurskrifað hýsilnafnið?

Haltu hönnuninni nógu lítilli til að útskýra hana í einni málsgrein: minnsti studdi flutningurinn sem ber nauðsynlega atburði, auk skýrrar yfirlýsingar um þær ábyrgðir sem hann veitir ekki. Ef svarið þarf tvö hopp, segðu það í runbooknum og gefðu hverju hoppi eiganda.