چگونه گزارش‌های دستگاه را به‌صورت امن به یک جمع‌کننده راه دور بفرستیم

دستگاه می‌تواند گزارش منتشر کند، جمع‌کننده در آن سوی اینترنت قرار دارد و نخستین پرسشی که همه می‌پرسند این است که کدام تونل ساخته شود۔ این چارچوب از جای اشتباه آغاز می‌شود۔ چیزی که حمل‌ونقل را تعیین می‌کند قالب‌هایی است که دستگاه می‌تواند تولید کند، احراز هویتی که جمع‌کننده می‌پذیرد و معنایی که «تحویل‌شده» باید داشته باشد وقتی پیوند قطع می‌شود۔ آن سه پاسخ را بنویسید و حمل‌ونقل معمولاً خودش را انتخاب می‌کند۔

از آنچه دستگاه می‌تواند منتشر کند آغاز کنید

در عمل فقط سه شکل وجود دارد۔ رویدادهای syslog تک‌تک روی UDP یا TCP، بارگذاری HTTPS احرازشده‌ای که در محصول تعبیه شده است، یا فایل‌های کامل نوشته‌شده روی دیسک که باید جابه‌جا شوند۔ دیوار آتشی که فقط می‌تواند syslog روی UDP بفرستد به‌خاطر افزودن تونل به فرستنده TLS تبدیل نمی‌شود؛ همچنان داده‌نگارهای تأییدنشده می‌فرستد، این بار درون پاکتی رمزگذاری‌شده۔

پس نخست فرستنده را فهرست کنید: پروتکل، پشتیبانی TLS و اینکه کدام کتابخانه TLS، آیا می‌تواند گواهی جمع‌کننده را اعتبارسنجی کند، آیا می‌تواند گواهی کارخواه ارائه دهد و آیا بافر ارسال از راه‌اندازی دوباره جان سالم به در می‌برد۔ هر کاری که دستگاه نمی‌تواند انجام دهد باید چیز دیگری در مسیر انجام دهد و آن چیز دیگر بخشی از طراحی شما می‌شود۔

syslog روی TLS: کوتاه‌ترین مسیر وقتی هر دو سو آن را می‌فهمند

اگر دستگاه از syslog روی TLS پشتیبانی می‌کند و جمع‌کننده آن را پایان می‌دهد، از آن استفاده کنید و بس۔ پروتکل کاربرد از خودش محافظت می‌کند، جمع‌کننده فرستنده را احراز می‌کند و هیچ پرش اضافه‌ای وجود ندارد که اکنون دسترس‌پذیری‌اش مال شما باشد۔ نکته این است که «syslog روی TLS» طیف گسترده‌ای از پیاده‌سازی‌ها را در بر می‌گیرد و راهنمای کنونی 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 حساب سنجاق کنید، حساب را به پوشه هدف محدود کنید و زیرسامانه internal-sftp با chroot را ترجیح دهید۔ داستان ارسال دوباره را هم برنامه‌ریزی کنید: اگر فایلی پس از شکست جزئی دوباره فرستاده شود، جمع‌کننده باید تکراری را از فایل تازه تشخیص دهد، معمولاً با نام به‌همراه جمع کنترلی و نه با زمان رسیدن۔

وقتی دروازه محلی یا تونل پاسخ صادقانه است

برخی دستگاه‌ها فقط به قالبی سخن می‌گویند که هیچ‌کس نمی‌خواهد افشا کند۔ در این حالت جمع‌کننده مجاز در شبکه خود دستگاه قالب بومی را دریافت می‌کند و آن را از طریق TLS جلوتر می‌فرستد۔ این طراحی مشروعی است، اما دقیق باشید که چه می‌خرد: رمزگذاری که از دروازه آغاز می‌شود بخش میان دستگاه و دروازه را به‌صورت گذشته‌نگر محافظت نمی‌کند، پس آن پرش همچنان مرز اعتماد و کنترل دسترسی خودش را لازم دارد۔

تونل مسیریابی‌شده سایت یا دستگاه سنگین‌ترین گزینه و گزینه درست است وقتی جمع‌کننده باید یک نشانی خصوصی را حفظ کند و چند سرویس را حمل کند، نه فقط گزارش‌ها۔ برنامه‌ریزی نشانی، قواعد دسترسی، مسیرهای بازگشت و چرخه عمر نقطه پایانی تونل را به همراه می‌آورد۔ همچنین پروتکل درونی را بهبود نمی‌دهد: syslog روی UDP درون تونل IPsec هنوز خدمت داده‌نگاری بدون تأیید تحویل است۔

هر چه برمی‌گزینید، مجوز جمع‌کننده را تنگ‌تر از حمل‌ونقل نگه دارید۔ هویت تونل به یک نقطه پایانی تعلق دارد و هیچ چیزی درباره اینکه کدام دستگاه پایین‌دست یک میدان نام میزبان معین را در پیام تولید کرده است نمی‌گوید۔

پیش از ارسال، قرارداد تحویل را بنویسید

رمزگذاری، احراز هویت و نگه‌داری به پرسش‌های متفاوتی پاسخ می‌دهند و صف یک سیاست نگه‌داری نیست۔ پیش از آنکه نخستین گزارش دستگاه را ترک کند، تصمیم بگیرید تأیید در این جمع‌کننده واقعاً چه معنایی دارد: دریافت روی سیم، پذیرفته‌شده برای پردازش، یا نوشته‌شده به‌صورت پایدار در ذخیره‌سازی۔ اینها سه تضمین متفاوت‌اند و تنها آخری از راه‌اندازی دوباره جمع‌کننده جان سالم به در می‌برد۔

سپس به پرسش‌های عملیاتی به‌صورت نوشتاری پاسخ دهید۔ رویدادهای فرستاده‌نشده کجا منتظر می‌مانند و آیا آن بافر از قطع برق جان سالم به در می‌برد؟ وقتی پر شود چه می‌شود و به چه کسی اطلاع داده می‌شود؟ تلاش‌های دوباره چگونه محدود می‌شوند و تکراری‌ها چگونه شناسایی می‌شوند؟ کدام میدان هویت فرستنده را اثبات می‌کند، با توجه به اینکه یک پرش ارسال می‌تواند نام میزبان را بازنویسی کند؟

طراحی را به‌قدری کوچک نگه دارید که در یک بند توضیح داده شود: کوچک‌ترین حمل‌ونقل پشتیبانی‌شده که رویدادهای لازم را حمل می‌کند، به‌همراه بیانی صریح از تضمین‌هایی که ارائه نمی‌دهد۔ اگر پاسخ به دو پرش نیاز دارد، آن را در runbook بگویید و به هر پرش یک مسئول بدهید۔