Құрылғы журналдар шығара алады, жинағыш интернеттің арғы жағында тұр, ал бәрі қоятын бірінші сұрақ — қай туннель салу керек. Бұл тұжырым дұрыс емес жерден басталады. Тасымалдауды құрылғы шығара алатын формат, жинағыш қабылдайтын аутентификация және байланыс үзілгенде «жеткізілді» дегеннің мағынасы анықтайды. Осы үш жауапты жазып алыңыз, сонда тасымалдау әдетте өзі таңдалады.

Құрылғы шығара алатын нәрседен бастаңыз

Іс жүзінде тек үш пішін бар. UDP немесе TCP арқылы жеке syslog оқиғалары, өнімге кіріктірілген аутентификацияланған HTTPS жүктеу, немесе дискіге жазылған және жылжыту қажет толық файлдар. Тек UDP syslog жібере алатын брандмауэр туннель қосқаныңыз үшін TLS жіберушісіне айналмайды; ол әлі де расталмаған датаграммаларды жібереді, енді шифрланған конверттің ішінде.

Сондықтан алдымен жіберушіні түгендеңіз: хаттама, TLS қолдауы және қай TLS кітапханасы, жинағыштың сертификатын тексере ала ма, клиент сертификатын ұсына ала ма және жіберу буфері қайта жүктеуден өте ме. Құрылғы жасай алмайтынның бәрін жолдағы басқа бір нәрсе жасауы керек, ал сол басқа нәрсе сіздің дизайныңыздың бөлігіне айналады.

TLS syslog: екі жақ та сөйлескендегі ең қысқа жол

Егер құрылғы TLS арқылы syslog-ты қолдаса және жинағыш оны аяқтаса, соны пайдаланып, тоқтаңыз. Қолданба хаттамасы өзін қорғайды, жинағыш жіберушіні аутентификациялайды және енді сізге тиесілі қосымша секіріс жоқ. Қақпан — «TLS syslog» іске асырулардың кең ауқымын қамтиды, және қауіпсіз syslog бойынша қазіргі нұсқаулық ескі оқулықтардағы шифрлар тізімінен ілгері кетті, сондықтан жұмыс істеп тұрған форвардер кітапхана жаңартылған соң бұзылады.

rsyslog-та тасымалдау модулінің атауы ғана қай дәуірде екеніңізді айтады: lmnsd_gtls GnuTLS-ті қаптайды, ал lmnsd_ossl OpenSSL-ді қаптайды және қазіргі 8.x пакеттері осыны жеткізеді. Сертификатты тексерумен жіберу әрекеті шамамен осылай көрінеді, ал нақты параметр атауларын орнатылған нұсқаңызбен салыстырып тексерген жөн:

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")

Жіберушіні жөндеуге кіріспес бұрын соңғы нүктені тексеріңіз. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error не жарамды тізбекпен қол алысуды аяқтайды, не қай тексерістің сәтсіз болғанын нақты айтады. Құрылғыдан сынаңыз, ноутбугіңыздан емес, өйткені құрылғының сенім қоймасы маңызды.

SFTP: файлдарға жақсы, ағындарға жарамсыз

Файлға негізделген жеткізу айналатын журналдар жазатын және басқа ештеңе жасамайтын құрылғыларға сәйкес келеді. SSH-ке негізделген тасымалдау хост кілттерін, әр тіркелгінің кілттерін және аудиттеуге болатын файлдық жүйені береді, бұл TLS-ті мүлде жасай алмайтын құрылғы үшін орынды сенім тарихы. Оқиғалар ағындары үшін бұл нашар таңдау, өйткені «файл сағат сайын жазылады» дегені үзіліс ағымдағы сағаттың құйрығын жоғалтатынын білдіреді.

Хостты тексеруді қосулы ұстаңыз. Сұрауды болдырмау үшін оны өшіретін топтама шақыру тасымалдаудың жалғыз аутентификациясын жояды:

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

Дайындау кезінде хост кілтін тіркелгінің known_hosts ішіне бекітіңіз, тіркелгіні мақсатты каталогпен шектеңіз және chroot-пен internal-sftp ішкі жүйесін қалаңыз. Қайта жіберу тарихын да жоспарлаңыз: егер файл ішінара сәтсіздіктен кейін қайта жіберілсе, жинағыш көшірмені жаңа файлдан ажырата білуі керек, әдетте атау және бақылау сомасы бойынша, келу уақыты бойынша емес.

Жергілікті шлюз немесе туннель шынайы жауап болғанда

Кейбір құрылғылар ешкім жариялағысы келмейтін форматта ғана сөйлей алады. Бұл жағдайда құрылғының өз желісіндегі уәкілетті жинағыш табиғи форматты қабылдап, оны TLS арқылы әрі қарай жібереді. Бұл заңды дизайн, бірақ оның не сатып алатынын нақты айтыңыз: шлюзде басталатын шифрлау құрылғы мен шлюз арасындағы сегментті кері күшпен қорғамайды, сондықтан сол секіріске өз сенім шекарасы мен қатынауды бақылау қажет.

Маршрутталған сайт немесе құрылғы туннелі — ең ауыр нұсқа және мына жағдайда дұрыс: жинағыш жеке мекенжайды сақтауы керек және бірнеше қызметті тасымалдауы керек, тек журналдарды емес. Ол мекенжайларды жоспарлауды, қатынау ережелерін, қайтару жолдарын және туннельдің соңғы нүктесінің өмірлік циклін әкеледі. Ол ішкі хаттаманы да жақсартпайды: IPsec туннелінің ішіндегі UDP syslog әлі де жеткізу растауынсыз датаграмма қызметі.

Не таңдасаңыз да, жинағыштың уәкілеттігін тасымалдаудан тар ұстаңыз. Туннельдің жеке басы соңғы нүктеге тиесілі және хабарламадағы белгілі бір хост атауы өрісін қай төменгі құрылғы жасағаны туралы ештеңе айтпайды.

Жібермес бұрын жеткізу шартын жазыңыз

Шифрлау, аутентификация және сақтау әртүрлі сұрақтарға жауап береді, ал кезек сақтау саясаты емес. Бірінші журнал құрылғыдан шықпас бұрын осы жинағышта растаудың шын мәнінде нені білдіретінін шешіңіз: желіде қабылданды, өңдеуге қабылданды немесе қоймаға тұрақты жазылды. Бұл үш түрлі кепілдік және тек соңғысы ғана жинағыштың қайта жүктелуінен өтеді.

Содан кейін операциялық сұрақтарға жазбаша жауап беріңіз. Жіберілмеген оқиғалар қайда күтеді және бұл буфер электр қуатының үзілуінен өте ме? Ол толғанда не болады және кімге хабарланады? Қайталаулар қалай шектеледі және көшірмелер қалай анықталады? Қай өріс жіберушінің жеке басын дәлелдейді, өйткені жіберу секірісі хост атауын қайта жаза алады?

Дизайнды бір абзацта түсіндіруге болатындай шағын ұстаңыз: қажетті оқиғаларды тасымалдайтын ең кіші қолдау көрсетілетін тасымалдау, оның үстіне ол бермейтін кепілдіктер туралы нақты мәлімдеме. Егер жауап екі секірісті қажет етсе, мұны runbook-та айтып, әр секіріске жауапты тағайындаңыз.

Қатысты мақалалар