ก่อนเปิด MQTT ออกนอกบ้าน ลองจัดสิทธิ์ให้แต่ละอุปกรณ์ก่อน

ก่อนเปิด MQTT ออกนอกบ้าน ลองจัดสิทธิ์ให้แต่ละอุปกรณ์ก่อน - Image 1
24/10/2025•Admin Team•
IoTMQTTTutorial

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

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

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

ต่อเข้าได้กับทำอะไรได้เป็นคนละเงื่อนไข

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

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

แยกช่องทาง TLS การยืนยันตัวตน และสิทธิ์ใน topic พร้อมข้อสังเกตว่า Client ID อย่างเดียวไม่ใช่การยืนยันตัวตน

ชื่อ Client ID ที่ปรากฏใน log ช่วยอ้างอิงการเชื่อมต่อได้ แต่ไม่ควรถูกถือเป็นหลักฐานยืนยันตัวตนเพียงอย่างเดียว หากการตั้งค่าเปิดให้ผู้เชื่อมต่อเลือกชื่อได้เอง การมีชื่อที่คุ้นเคยบนจอก็ยังไม่ได้ยืนยันว่าเป็นอุปกรณ์เดิมจริง

ก่อนเลือกเครื่องมือ ลองเขียนรายชื่อบทบาทให้ครบ เช่น เซนเซอร์ อุปกรณ์ควบคุม ตัวเก็บประวัติ และหน้า Dashboard แล้วกำหนดข้อมูลที่แต่ละบทบาทต้องใช้ จะช่วยให้กติกาเกิดจากหน้าที่ ไม่เริ่มจากอนุญาตทั้งหมดแล้วค่อยหาว่าจะห้ามตรงไหน

ให้แต่ละอุปกรณ์มีขอบเขตของตัวเอง

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

โครง topic ที่วางไว้ก่อนหน้านี้ช่วยจัดสิทธิ์ได้ เช่น กลุ่ม devices/<device-id>/state สำหรับข้อมูลที่อุปกรณ์รายงาน และ devices/<device-id>/command สำหรับสิ่งที่อุปกรณ์รับ แต่การตั้งชื่อแยกกันยังต้องมี rule ที่บังคับจริง ไม่ใช่พึ่งให้ firmware เลือกชื่อถูกเอง

ตัวอย่างบัญชีอุปกรณ์แยกกันและสิทธิ์ส่งสถานะกับรับคำสั่งในพื้นที่ของตัวเอง ไม่ใช่สิทธิ์อ่านเขียนทั้งระบบ

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

เมื่อต้องใช้ wildcard ในสิทธิ์ ควรตรวจผลที่มันครอบคลุมจริง โดยเฉพาะการอนุญาตกว้างระดับอาคารหรือทั้งระบบ เพราะการเพิ่ม topic ใหม่ในอนาคตอาจอยู่ใต้ขอบเขตเดิมและได้รับสิทธิ์ตามไปด้วย แม้ตอนเขียนกติกาครั้งแรกจะยังไม่มีข้อมูลชนิดนั้น

ปกป้องช่องทางส่งข้อมูลด้วย

บัญชีและสิทธิ์ไม่ได้แทนการเข้ารหัสระหว่างทาง หากใช้รหัสผ่านบนช่องทางที่ไม่มีการป้องกัน เราก็ยังต้องคิดถึงการถูกอ่านข้อมูลบนเส้นทางนั้น การใช้ TLS จึงควรดูทั้งฝั่ง broker และการตรวจใบรับรองของ client ให้ตรงตามการตั้งค่าจริง

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

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

สำหรับข้อมูลลับบนบอร์ด ต้องดูวิธี provision การเก็บ และทางหมุนค่าเมื่อเปลี่ยนเครื่องด้วย ไม่พิมพ์ความลับทั้งหมดลง log หรือฝังบัญชีร่วมไว้ในไฟล์ตัวอย่างที่นำไปแจกต่อ การจัดสิทธิ์จะดูแลต่อได้ก็ต่อเมื่อมีทางเปลี่ยนข้อมูลที่ใช้ยืนยันตัวตนอย่างเหมาะสม

ทดสอบสิ่งที่ต้องถูกปฏิเสธด้วย

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

การเชื่อมต่อสำเร็จเพียงอย่างเดียวไม่ใช่ผลทดสอบ ACL ทั้งชุด ควรดูทั้ง publish, subscribe และข้อความ retained ที่เกี่ยวข้องตามการใช้งานจริง รวมถึงอ่าน log หรือสถานะที่ broker รองรับ เพราะพฤติกรรมรายงานความผิดพลาดอาจต่างกันตามระดับ protocol และ client

เมื่อเปลี่ยน rule ควรตรวจเงื่อนไข reload และผลต่อการเชื่อมต่อที่มีอยู่ตามเอกสารรุ่นที่ใช้ ไม่คิดว่าการแก้ไฟล์บนดิสก์แปลว่าทุก session เปลี่ยนสิทธิ์แล้วทันที และควรมีบัญชีผู้ดูแลที่ไม่ปนกับบัญชีบอร์ดไว้สำหรับจัดการตามขอบเขตที่เหมาะสม

การเลิกใช้อุปกรณ์ก็เป็นขั้นตอนหนึ่ง

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

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

สรุป

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

Command Eng Logo
CMD yourNgineers
เลขประจำตัวผู้เสียภาษี0805564000814
บทความ
ติดต่อบริษัท คอมมานด์ เอ็นจ์ จำกัด
81/36 เพอร์เฟค พาร์คบางนาตำบลบางเสาธง อำเภอบางเสาธงจังหวัดสมุทรปราการ 10570
team@commandeng.in.th+66 89 393 5191
Facebook Page | Command EngLine | Command Eng Official
© Copyright 2022-2026 Command Eng Co., Ltd.v1.0.4 · 0d556ab · 2026-11-03 15:23