Cihaz qeydlərini uzaq toplayıcıya necə təhlükəsiz göndərməli

Cihaz qeydləri çıxara bilir, toplayıcı internetin o biri tərəfində oturur və hamının soruşduğu ilk sual hansı tunelin qurulacağıdır. Bu çərçivə yanlış yerdən başlayır. Nəqliyyatı müəyyən edən cihazın istehsal edə bildiyi format, toplayıcının qəbul edəcəyi autentifikasiya və link düşəndə “çatdırıldı” sözünün nə demək olduğudur. Bu üç cavabı yazın, sonra nəqliyyat adətən özünü seçir.

Cihazın nə çıxara bildiyindən başlayın

Təcrübədə yalnız üç forma var. UDP və ya TCP üzərindən fərdi syslog hadisələri, məhsula quraşdırılmış autentifikasiyalı HTTPS yükləməsi və ya diskə yazılan və köçürülməli olan tam fayllar. Yalnız UDP syslog göndərə bilən firewall, tunel əlavə etdiyiniz üçün TLS göndərəninə çevrilməyəcək; yenə təsdiqlənməmiş datagramlar göndərəcək, indi şifrələnmiş zərf içində.

Buna görə əvvəlcə göndərəni inventarlaşdırın: protokol, TLS dəstəyi və hansı TLS kitabxanası, toplayıcının sertifikatını yoxlaya bilirmi, müştəri sertifikatı təqdim edə bilirmi və göndərmə buferi yenidən başlatmaya dözürmü. Cihazın edə bilmədiyi hər şeyi yolda başqa bir şey etməlidir və o başqa şey dizaynınızın hissəsi olur.

TLS syslog: iki tərəf də danışanda ən qısa yol

Cihaz TLS üzərindən syslog dəstəkləyirsə və toplayıcı onu sonlandırırsa, bundan istifadə edin və dayanın. Tətbiq protokolu özünü qoruyur, toplayıcı göndərəni autentifikasiya edir və indi mövcudluğunu sahibləndiyiniz əlavə heç bir addım yoxdur. Tələ isə “TLS syslog”un geniş bir tətbiq diapazonunu əhatə etməsidir və mövcud təhlükəsiz syslog təlimatları köhnə dərsliklərdəki şifrə siyahılarından irəli gedib, kitabxana yenilənməsindən sonra işləyən ötürücünün necə pozulduğu budur.

rsyslog-da təkcə nəqliyyat modulunun adı hansı dövrdə olduğunuzu deyir: lmnsd_gtls GnuTLS-i bükür, lmnsd_ossl isə OpenSSL-i bükür və hazırkı 8.x paketləri bunu gətirir. Sertifikat yoxlaması ilə yönləndirmə əməliyyatı təxminən belə görünür və dəqiq parametr adlarını quraşdırılmış versiyanızla yoxlamağa dəyər:

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

Göndərəni sazlamadan əvvəl son nöqtəni yoxlayın. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error ya etibarlı zəncirlə əl sıxma tamamlayır, ya da hansı yoxlamanın uğursuz olduğunu dəqiq deyir. Cihazdan sınayın, noutbukdan yox, çünki vacib olan cihazın etibarlılıq anbarıdır.

SFTP: fayllar üçün yaxşı, axınlar üçün yanlış

Fayl əsaslı çatdırılma yalnız fırlanan qeydlər yazan cihazlara uyğundur. SSH əsaslı ötürmə sizə host açarları, hesab başına açarlar və audit edə biləcəyiniz fayl sistemi verir ki, bu da TLS-i heç edə bilməyən cihaz üçün ağlabatan etibar hekayəsidir. Hadisə axınları üçün zəif seçimdir, çünki “fayl hər saat yazılır” demək fasilənin sizə cari saatın quyruğunu itirdiyini bildirir.

Host yoxlamasını açıq saxlayın. Sorğudan qaçmaq üçün onu söndürən toplu çağırış nəqliyyatın malik olduğu yeganə autentifikasiyanı puç edir:

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

Provisioninq zamanı host açarını hesabın known_hosts faylına bərkidin, hesabı hədəf kataloqla məhdudlaşdırın və chroot ilə internal-sftp alt sisteminə üstünlük verin. Yenidən göndərmə hekayəsini də planlaşdırın: qismən uğursuzluqdan sonra fayl yenidən göndərilirsə, toplayıcı dublikatı yeni fayldan ayıra bilməlidir, adətən gəliş vaxtı ilə deyil, ad üstəgəl yoxlama məbləği ilə.

Yerli şlüz və ya tunel dürüst cavab olanda

Bəzi cihazlar yalnız heç kimin ifşa etmək istəmədiyi formatda danışa bilir. Bu halda cihazın öz şəbəkəsindəki səlahiyyətli toplayıcı doğma formatı qəbul edir və onu TLS üzərindən irəli ötürür. Bu qanuni dizayndır, lakin nə aldığınızı dəqiq bilin: şlüzdə başlayan şifrələmə cihazla şlüz arasındakı seqmenti geriyə dönük qorumur, ona görə o addımın öz etibar sərhədi və giriş nəzarəti lazımdır.

Marşrutlanmış sayt və ya cihaz tuneli ən ağır seçimdir və toplayıcı şəxsi ünvanı saxlamalı və yalnız qeydləri deyil, bir neçə xidməti daşımalı olduqda doğru seçimdir. Ünvan planlaması, giriş qaydaları, qayıdış yolları və tunel son nöqtəsinin həyat dövrünü gətirir. Daxili protokolu da yaxşılaşdırmır: IPsec tuneli içindəki UDP syslog yenə çatdırılma təsdiqi olmayan datagram xidmətidir.

Nə seçsəniz də, toplayıcı səlahiyyətini nəqliyyatdan dar saxlayın. Tunel kimliyi son nöqtəyə aiddir və mesajdakı müəyyən hostname sahəsini hansı aşağı cihazın istehsal etdiyi barədə heç nə demir.

Göndərməzdən əvvəl çatdırılma müqaviləsini yazın

Şifrələmə, autentifikasiya və saxlanma fərqli suallara cavab verir və növbə saxlanma siyasəti deyil. İlk qeyd cihazı tərk etməzdən əvvəl bu toplayıcıda təsdiqin həqiqətən nə demək olduğunu qərar verin: naqildə qəbul edildi, emal üçün qəbul edildi və ya davamlı olaraq yaddaşa yazıldı. Bunlar üç fərqli zəmanətdir və toplayıcının yenidən başlamasından yalnız sonuncusu sağ çıxır.

Sonra əməliyyat suallarını yazılı cavablandırın. Göndərilməmiş hadisələr harada gözləyir və bu bufer elektrik kəsilməsinə dözürmü? Dolanda nə olur və kimə xəbər verilir? Təkrar cəhdlər necə məhdudlaşdırılır və dublikatlar necə müəyyən edilir? Yönləndirmə addımı hostname-i yenidən yaza bildiyi halda, göndərənin kimliyini hansı sahə sübut edir?

Dizaynı bir abzasla izah etmək üçün kifayət qədər kiçik saxlayın: tələb olunan hadisələri daşıyan ən kiçik dəstəklənən nəqliyyat, üstəgəl təmin etmədiyi zəmanətlərin açıq ifadəsi. Cavab iki addım tələb edirsə, bunu runbook-da deyin və hər addıma bir sahib verin.