วิธีส่งบันทึกของอุปกรณ์ไปยังตัวรวบรวมระยะไกลอย่างปลอดภัย

อุปกรณ์เปล่งบันทึกได้ ตัวรวบรวมอยู่อีกฟากของอินเทอร์เน็ต และคำถามแรกที่ทุกคนถามคือจะสร้างอุโมงค์ใด กรอบความคิดนั้นเริ่มผิดที่ สิ่งที่กำหนดการขนส่งคือรูปแบบที่อุปกรณ์สร้างได้ การพิสูจน์ตัวตนที่ตัวรวบรวมจะยอมรับ และความหมายของ “ส่งถึงแล้ว” เมื่อลิงก์ขาด เขียนคำตอบสามข้อนั้นลงไป แล้วการขนส่งมักเลือกตัวเอง

เริ่มจากสิ่งที่อุปกรณ์เปล่งออกได้

ในทางปฏิบัติมีเพียงสามรูปแบบ คือเหตุการณ์ syslog ทีละรายการผ่าน UDP หรือ TCP การอัปโหลด HTTPS ที่พิสูจน์ตัวตนซึ่งฝังอยู่ในผลิตภัณฑ์ หรือไฟล์ทั้งหมดที่เขียนลงดิสก์และต้องย้าย ไฟร์วอลล์ที่ส่งได้เฉพาะ syslog ผ่าน UDP จะไม่กลายเป็นผู้ส่ง TLS เพราะคุณเพิ่มอุโมงค์ มันยังคงส่งดาตาแกรมที่ไม่มีการยืนยัน ตอนนี้อยู่ในซองที่เข้ารหัส

ดังนั้นจงทำบัญชีผู้ส่งก่อน: โปรโตคอล การรองรับ TLS และไลบรารี TLS ใด สามารถตรวจสอบใบรับรองของตัวรวบรวมได้หรือไม่ สามารถแสดงใบรับรองไคลเอนต์ได้หรือไม่ และบัฟเฟอร์การส่งอยู่รอดหลังรีบูตหรือไม่ ทุกสิ่งที่อุปกรณ์ทำไม่ได้ต้องมีอย่างอื่นในเส้นทางทำ และสิ่งนั้นกลายเป็นส่วนหนึ่งของการออกแบบของคุณ

TLS syslog: เส้นทางที่สั้นที่สุดเมื่อทั้งสองฝั่งพูดมัน

ถ้าอุปกรณ์รองรับ syslog ผ่าน TLS และตัวรวบรวมสิ้นสุดมัน ให้ใช้สิ่งนั้นแล้วหยุด โปรโตคอลแอปพลิเคชันป้องกันตัวเอง ตัวรวบรวมพิสูจน์ตัวผู้ส่ง และไม่มีขั้นตอนพิเศษที่คุณต้องรับผิดชอบความพร้อมใช้งานอีกต่อไป กับดักคือ “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 ของบัญชีระหว่างการจัดเตรียม จำกัดบัญชีให้อยู่ในไดเรกทอรีเป้าหมาย และเลือกใช้ระบบย่อย internal-sftp พร้อม chroot วางแผนเรื่องการส่งซ้ำด้วย: หากไฟล์ถูกส่งซ้ำหลังความล้มเหลวบางส่วน ตัวรวบรวมต้องแยกความแตกต่างระหว่างสำเนากับไฟล์ใหม่ โดยปกติด้วยชื่อบวกเช็กซัม ไม่ใช่เวลาที่มาถึง

เมื่อเกตเวย์ในเครื่องหรืออุโมงค์เป็นคำตอบที่ซื่อสัตย์

อุปกรณ์บางชนิดพูดได้เฉพาะรูปแบบที่ไม่มีใครอยากเปิดเผย ในกรณีนั้นตัวรวบรวมที่ได้รับอนุญาตบนเครือข่ายของอุปกรณ์เองจะรับรูปแบบดั้งเดิมและส่งต่อผ่าน TLS นี่เป็นการออกแบบที่ชอบด้วยกฎหมาย แต่จงแม่นยำเกี่ยวกับสิ่งที่มันซื้อ: การเข้ารหัสที่เริ่มที่เกตเวย์ไม่ได้ปกป้องส่วนระหว่างอุปกรณ์กับเกตเวย์ย้อนหลัง ดังนั้นขั้นตอนนั้นยังต้องมีขอบเขตความเชื่อถือและการควบคุมการเข้าถึงของตัวเอง

อุโมงค์ไซต์หรืออุปกรณ์ที่กำหนดเส้นทางเป็นตัวเลือกที่หนักที่สุดและถูกต้องเมื่อ ตัวรวบรวมต้องเก็บที่อยู่ส่วนตัวไว้ และต้องบรรทุกบริการหลายอย่าง ไม่ใช่แค่บันทึก มันนำการวางแผนที่อยู่ กฎการเข้าถึง เส้นทางย้อนกลับ และวงจรชีวิตของปลายทางอุโมงค์มาด้วย มันไม่ได้ปรับปรุงโปรโตคอลภายในเช่นกัน: syslog ผ่าน UDP ในอุโมงค์ IPsec ยังคงเป็นบริการดาตาแกรมที่ไม่มีการยืนยันการส่งมอบ

ไม่ว่าคุณจะเลือกอะไร จงรักษาสิทธิ์ของตัวรวบรวมให้แคบกว่าการขนส่ง อัตลักษณ์ของอุโมงค์เป็นของปลายทาง และไม่ได้บอกอะไรเกี่ยวกับว่าอุปกรณ์ปลายน้ำใดสร้างฟิลด์ชื่อโฮสต์ที่กำหนดในข้อความ

เขียนสัญญาการส่งมอบก่อนส่ง

การเข้ารหัส การพิสูจน์ตัวตน และการเก็บรักษาตอบคำถามต่างกัน และคิวไม่ใช่นโยบายการเก็บรักษา ก่อนที่บันทึกแรกจะออกจากอุปกรณ์ ให้ตัดสินใจว่าการยืนยันหมายถึงอะไรจริง ๆ บนตัวรวบรวมนี้: รับบนสาย ยอมรับเพื่อประมวลผล หรือเขียนลงที่เก็บอย่างทนทาน สิ่งเหล่านี้เป็นการรับประกันที่แตกต่างกันสามอย่าง และมีเพียงอย่างสุดท้ายที่อยู่รอดหลังรีสตาร์ตตัวรวบรวม

จากนั้นตอบคำถามด้านปฏิบัติการเป็นลายลักษณ์อักษร เหตุการณ์ที่ยังไม่ถูกส่งรออยู่ที่ใด และบัฟเฟอร์นั้นอยู่รอดหลังไฟดับหรือไม่ เกิดอะไรขึ้นเมื่อเต็ม และใครได้รับแจ้ง การลองซ้ำถูกจำกัดอย่างไร และระบุสำเนาซ้ำอย่างไร ฟิลด์ใดพิสูจน์อัตลักษณ์ของผู้ส่ง เมื่อพิจารณาว่าขั้นตอนส่งต่ออาจเขียนชื่อโฮสต์ใหม่

รักษาการออกแบบให้เล็กพอที่จะอธิบายในย่อหน้าเดียว: การขนส่งที่รองรับเล็กที่สุดที่บรรทุกเหตุการณ์ที่ต้องการ พร้อมคำแถลงชัดเจนเกี่ยวกับการรับประกันที่มันไม่ได้ให้ หากคำตอบต้องใช้สองขั้นตอน ให้บอกใน runbook และมอบหมายเจ้าของให้แต่ละขั้นตอน