ความปลอดภัยของซอฟต์แวร์ให้เช่า: คำถามที่ควรถามก่อนมอบข้อมูลธุรกิจให้แพลตฟอร์ม

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

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

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

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

จึงคุ้มค่าที่จะถามคำถามที่เป็นรูปธรรมสามข้อกับผู้ให้บริการรายใดก็ตาม มีการยืนยันตัวตนสองปัจจัย (2FA) ให้ใช้หรือไม่ เพื่อให้รหัสผ่านที่ถูกขโมยหรือเดาได้เพียงอย่างเดียวไม่เพียงพอต่อการเข้าสู่ระบบ ทีมของคุณสามารถเข้าสู่ระบบผ่านระบบ single sign-on (SSO) ของบริษัทตัวเองได้หรือไม่ เพื่อให้การเข้าถึงระบบให้เช่าเพิ่มขึ้นหรือลดลงตามบัญชีกลางของแต่ละคน แทนที่จะพึ่งพาการเข้าสู่ระบบแยกต่างหากที่ต้องมีใครสักคนคอยจำไว้จัดการเอง และมี passkey ให้เลือกใช้หรือไม่ ซึ่งเป็นวิธียืนยันตัวตนแบบใหม่ที่แทนที่รหัสผ่านที่ต้องพิมพ์ด้วยคีย์เข้ารหัสที่ผูกกับอุปกรณ์ ทำให้กลลวงฟิชชิงที่พบบ่อยที่สุด นั่นคือหน้าเข้าสู่ระบบปลอมที่ขอให้พิมพ์รหัสผ่าน แทบไม่มีผลอีกต่อไป เพราะไม่มีรหัสผ่านให้พิมพ์ตั้งแต่แรก

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

คำตอบของ Renttix ต่อคำถามนี้ตรงไปตรงมา SSO, passkey และ 2FA ใช้ได้กับการเข้าสู่ระบบทุกครั้ง แทนที่จะเป็นตัวเลือกเสริมที่สงวนไว้สำหรับแพ็กเกจระดับองค์กร หรือซ่อนอยู่หลังตั๋วขอความช่วยเหลือ ไม่ว่าคุณกำลังประเมินผู้ให้บริการรายใด ก็คุ้มค่าที่จะถามตรงๆ แบบนี้ว่า คุณรองรับข้อไหนในสามข้อนี้บ้าง และสิ่งนี้พร้อมให้เราใช้งานในฐานะลูกค้าตั้งแต่วันนี้เลยหรือไม่ ไม่ใช่แค่รายการในแผนงานอนาคต

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

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

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

ตัวอย่างประกอบ

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

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

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

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

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

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

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

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

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

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

ในฐานะเช็กลิสต์สั้นๆ ที่จะนำไปใช้ในบทสนทนากับผู้ให้บริการ แพลตฟอร์มรองรับ 2FA, SSO และ passkey สำหรับการเข้าสู่ระบบหรือไม่ สิทธิ์ถูกตรวจสอบที่เซิร์ฟเวอร์ในทุกคำขอหรือไม่ หรือถูกควบคุมเพียงแค่ด้วยสิ่งที่อินเทอร์เฟซแสดง มีบันทึกการตรวจสอบหรือไม่ และมันปิดบังฟิลด์ที่อ่อนไหวขึ้นอยู่กับว่าใครเป็นผู้ดูหรือไม่ API key ถูกจำกัดให้ตรงกับสิ่งที่การเชื่อมต่อแต่ละอย่างจำเป็นต้องใช้จริงๆ หรือไม่ และสามารถเพิกถอนเป็นรายตัวได้หรือไม่ แทนที่จะใช้ร่วมกันในทุกการเชื่อมต่อ

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