[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-faqs-cloud-access-vendor-transition-th":3,"blog-post-cloud-access-vendor-transition-th":28},[4,8,12,16,20,24],{"answer":5,"id":6,"question":7},"มาตรฐานอย่าง NIST SP 800-53 ไม่ได้กำหนดตัวเลขตายตัว แต่ให้แต่ละองค์กรกำหนดความถี่ตามความเสี่ยงของระบบนั้น ในทางปฏิบัติเครื่องมืออย่าง Microsoft Entra เปิดให้ตั้งรอบทบทวนได้ตั้งแต่รายสัปดาห์ถึงรายปี ระบบที่แตะข้อมูลลูกค้าหรือมีสิทธิ์ระดับ admin ควรทบทวนถี่กว่าระบบภายในทั่วไป","rjku6h66ti1smhz","ควรทบทวนสิทธิ์เข้าถึงบัญชี Cloud ขององค์กรบ่อยแค่ไหนเมื่อไม่มีเหตุการณ์เปลี่ยนทีม",{"answer":9,"id":10,"question":11},"ควรเริ่มจาก service account และ API key ที่คนนั้นดูแลอยู่ก่อน เพราะไม่ผูกกับ MFA และมักถูกมองข้าม จากนั้นจึงปิด human account ทุกระบบ ตามด้วยการหมุนเวียน shared secret ที่คนนั้นเคยรู้ค่า และปิดท้ายด้วยการตรวจ audit log ย้อนหลังก่อนวันที่ออกจริง","4qbc9i23jtfrtzr","เมื่อพนักงานหรือนักพัฒนาออกจากโครงการ ควรเพิกถอนสิทธิ์อะไรก่อน",{"answer":13,"id":14,"question":15},"Service account มักเชื่อมกับ pipeline หรือระบบอัตโนมัติที่ยังทำงานอยู่ และไม่ผูกกับ MFA เหมือนบัญชีคน การลบทันทีอาจทำให้ระบบอื่นพังโดยไม่รู้ตัว จึงควรปิดการใช้งานก่อนแล้วค่อยลบจริงหลังมั่นใจว่าไม่มีอะไรเรียกใช้อยู่ ต่างจาก human account ที่ปิดได้ทันทีเมื่อคนออกจากตำแหน่ง","dmqfun55bn02th5","Service account ต่างจาก human account อย่างไรตอน offboarding",{"answer":17,"id":18,"question":19},"ควรตรวจว่าสิทธิ์ทั้งหมดที่เคยให้ทีม vendor ถูกเพิกถอนครบ ทั้งบัญชีบุคคลและ service account ที่พวกเขาสร้างไว้ หมุนเวียน secret ที่เคยแชร์ร่วมกัน และตรวจ audit log ช่วงใกล้สิ้นสุดสัญญา ก่อนเซ็นปิดงานอย่างเป็นทางการ","j5goandae9nh4nu","เมื่อสัญญากับ vendor ผู้พัฒนาระบบสิ้นสุดลง ควรตรวจสอบอะไรก่อนปิดเคส",{"answer":21,"id":22,"question":23},"ฝ่ายบุคคลควรเป็นจุดเริ่ม trigger เมื่อพนักงานพ้นสภาพ ฝ่ายจัดซื้อหรือกฎหมายแจ้งเมื่อสัญญา vendor สิ้นสุด เจ้าของระบบเซ็นรับรู้ว่าเพิกถอนครบ และฝ่ายความปลอดภัยหรือ compliance ดูแลการตรวจ audit log ส่วน IT เป็นคนลงมือทำจริงตามที่แต่ละฝ่ายแจ้ง","ewseligughnmk6b","ใครในองค์กรควรเป็นเจ้าของกระบวนการเพิกถอนสิทธิ์เข้าถึง Cloud ไม่ใช่แค่ IT",{"answer":25,"id":26,"question":27},"ถ้าเป็นระบบภายในขนาดเล็ก ผู้ใช้ไม่กี่คน ไม่มีข้อมูลส่วนบุคคลของลูกค้า และแทบไม่เปลี่ยนตัวผู้ดูแล การตรวจสอบด้วยมือทุกไตรมาสก็เพียงพอ ไม่จำเป็นต้องลงทุนเครื่องมือ identity governance หรือ automated access review เต็มรูปแบบ","c5k67kvz76wmz5z","องค์กรขนาดเล็กที่มีระบบไม่กี่ระบบ จำเป็นต้องมีกระบวนการ offboarding สิทธิ์ที่ซับซ้อนขนาดนี้ไหม",{"id":29,"parentId":30,"title":31,"excerpt":32,"content":33,"image":34,"date":35,"isoDate":36,"views":37,"tag":38,"categorySlug":39,"slug":40,"to":41,"readTime":42,"isHighlight":43,"sortOrder":44,"video":45,"video_id":45,"keywords":46},"a4go9qx8jsnmhoj","k15mzy5f9l0f12r","ใครถือกุญแจบัญชี Cloud ขององค์กรอยู่จริง: จัดการสิทธิ์เข้าถึงเมื่อทีมพัฒนาเปลี่ยนมือ","เมื่อนักพัฒนาลาออกหรือสัญญา vendor หมดอายุ สิทธิ์เข้าถึง Cloud ที่ไม่มีใครเพิกถอนคือความเสี่ยงที่ไม่มีนัดตรวจ วางลำดับเพิกถอนสิทธิ์และเจ้าของงานที่ไม่ใช่แค่ IT","\u003Cp>เดือนที่นักพัฒนาหลักของโครงการลาออก ทีมที่เหลือมักถามคำถามเดียวกันสองข้อพร้อมกัน คนคนนั้นยังเข้าบัญชี Google Cloud ของบริษัทได้อยู่หรือไม่ และมีใครรู้บ้างว่าเขาเคยสร้าง service account หรือ API key อะไรทิ้งไว้ระหว่างทาง คำถามแบบนี้ไม่ได้เกิดเฉพาะตอนพนักงานลาออก แต่เกิดซ้ำทุกครั้งที่สัญญากับ vendor ผู้พัฒนาระบบหมดอายุ หรือทีม outsource ย้ายไปรับงานที่อื่น จุดเปลี่ยนมือเหล่านี้คือช่วงเวลาที่สิทธิ์เข้าถึงหลุดออกจากสายตาคนดูแลได้ง่ายที่สุด เพราะไม่มีใครกำหนดไว้ล่วงหน้าว่าการเพิกถอนสิทธิ์เป็นหน้าที่ของใคร\u003C\u002Fp>\u003Cp>ไม่มีใครนัดวันตรวจสิทธิ์ที่ไม่มีใครจำได้ว่าเคยให้ไป\u003C\u002Fp>\u003Ch2>จุดเปลี่ยนมือคือจุดที่สิทธิ์เข้าถึงหลุดจากการตรวจสอบ\u003C\u002Fh2>\u003Cp>ตอนเริ่มงาน ทุกคนให้ความสำคัญกับการให้สิทธิ์เพราะงานเดินต่อไม่ได้ถ้านักพัฒนาเข้าระบบไม่ได้ กระบวนการอนุมัติจึงมีเจ้าของชัดเจนและมีคนตามงานจนเสร็จ แต่ตอนเลิกงานกลับตรงข้ามกัน ไม่มีใครติดขัดถ้าลืมปิดสิทธิ์สักบัญชี งานยังเดินต่อได้ตามปกติ ความเสี่ยงจึงไม่ได้แสดงออกทันที แต่ค่อย ๆ สะสมเป็น IAM role ที่ไม่มีใครกล้าลบเพราะไม่แน่ใจว่ายังมีอะไรผูกอยู่ เป็น service account ที่สร้างไว้ทดสอบแล้วลืมปิด และเป็น shared credential ที่รู้กันในทีมแต่ไม่เคยหมุนเวียนตั้งแต่วันที่ตั้งค่า\u003C\u002Fp>\u003Ch2>ลำดับการเพิกถอนสิทธิ์ที่ควรทำเมื่อมีคนออกจากโครงการ\u003C\u002Fh2>\u003Cp>ความผิดพลาดที่เกิดได้ง่ายคือปิด human account ของคนที่ออกแล้วถือว่าจบ ทั้งที่ความเสี่ยงจริงมักซ่อนอยู่ในสิทธิ์ที่ไม่ได้ผูกกับหน้าคนโดยตรง ลำดับที่ควรทำมีสี่ขั้น\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>ตรวจสอบและปิดหรือหมุนเวียน service account และ API key ที่คนนั้นสร้างหรือดูแลอยู่ก่อน เพราะ service account มักไม่ผูกกับ MFA และถูกมองข้ามในการตรวจสอบประจำวัน เอกสารแนวปฏิบัติของ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fcloud.google.com\u002Fiam\u002Fdocs\u002Fbest-practices-service-accounts\">Google Cloud\u003C\u002Fa> แนะนำให้ปิดการใช้งาน service account ที่ไม่ใช้แล้วก่อน แล้วค่อยลบทิ้งจริงหลังผ่านไประยะหนึ่ง เพราะถ้าลบแล้วสร้างใหม่ด้วยชื่อเดิม IAM binding เดิมจะไม่ตามมา ขณะที่การปิดแล้วเปิดกลับยังเก็บ binding ไว้ครบ ผลในทางปฏิบัติคือถ้ามี pipeline อัตโนมัติที่ยังผูกอยู่โดยไม่มีใครรู้ ก็เปิดกลับได้โดยไม่เสียสิทธิ์เดิม\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ปิด human account หรือ SSO identity ของคนนั้นในทุกระบบที่เกี่ยวข้อง ไม่ใช่แค่ระบบหลักที่นึกออกก่อน\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>หมุนเวียน secret ที่ใช้ร่วมกันในทีม เช่น database password หรือ API key ที่หลายคนเคยเห็นค่าจริง เพราะคนที่ออกไปมีโอกาสรู้ค่าที่ไม่ได้ผูกกับบัญชีตัวเองด้วย\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ตรวจสอบ audit log ย้อนหลังในช่วงก่อนวันที่ออกจริง เพื่อดูว่ามีการสร้างสิทธิ์ใหม่ ดาวน์โหลดข้อมูลจำนวนมาก หรือเปลี่ยนค่า configuration ที่ผิดปกติหรือไม่\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>การเขียนเงื่อนไขนี้ไว้ล่วงหน้าใน\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Ftor-conditions-for-a-maintainable-system\">TOR หรือสัญญาจ้างงาน\u003C\u002Fa>ทำให้เมื่อถึงวันจริง ทีมไม่ต้องมานั่งคิดลำดับขั้นตอนกลางความเร่งรีบ\u003C\u002Fp>\u003Ch2>ทบทวนสิทธิ์แบบ least privilege ให้เป็นวงจร ไม่ใช่แค่ตอนมีคนออก\u003C\u002Fh2>\u003Cp>หลักการ least privilege (สิทธิ์เท่าที่จำเป็น) ตามนิยามของ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fcsrc.nist.gov\u002Fglossary\u002Fterm\u002Fleast_privilege\">NIST SP 800-53\u003C\u002Fa> คือการให้แต่ละ entity ได้รับทรัพยากรและสิทธิ์ของระบบเพียงขั้นต่ำที่จำเป็นต่อการทำหน้าที่ของตัวเอง หลักการนี้ได้ผลจริงก็ต่อเมื่อมีการทบทวนเป็นรอบ ไม่ใช่ให้สิทธิ์ไปแล้วปล่อยไว้จนกว่าจะมีเหตุการณ์บังคับให้ต้องตรวจ มาตรฐานของ NIST เองไม่ได้กำหนดตัวเลขตายตัวว่าต้องทบทวนทุกกี่วัน ข้อ AC-6(7) ใน \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Fsp\u002F800\u002F53\u002Fr5\u002Fupd1\u002Ffinal\">SP 800-53 Rev. 5\u003C\u002Fa> ให้แต่ละองค์กรกำหนดความถี่เอง ซึ่งเราแนะนำให้ผูกกับความเสี่ยงของระบบนั้น ในทางปฏิบัติ เครื่องมืออย่าง Microsoft Entra เปิดให้ตั้งรอบทบทวนสิทธิ์แบบ\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fentra\u002Fid-governance\u002Faccess-reviews-overview\">รายสัปดาห์ รายเดือน รายไตรมาส หรือรายปี\u003C\u002Fa>ได้ตามระดับความเสี่ยงของแต่ละกลุ่มสิทธิ์ ระบบที่แตะข้อมูลลูกค้าหรือมีสิทธิ์ระดับ admin ควรทบทวนถี่กว่าระบบภายในทั่วไป และเมื่อพูดถึงสิทธิ์ที่ควรอยู่ในวงจรทบทวนเดียวกัน สิทธิ์ของ AI agent ที่เชื่อมต่อระบบเองก็ควรถูกนับรวมด้วย แม้จะมีรายละเอียดเฉพาะของตัวเองที่ต่างออกไป\u003C\u002Fp>\u003Ch2>ใครควรเป็นเจ้าของกระบวนการนี้ ไม่ใช่ IT ฝ่ายเดียว\u003C\u002Fh2>\u003Cp>ข้อผิดพลาดที่พบบ่อยคือมองว่าการเพิกถอนสิทธิ์เป็นงานของ IT ล้วน ทั้งที่ IT มักไม่ใช่ฝ่ายแรกที่รู้ว่ามีคนออกจากโครงการ ฝ่ายบุคคลรู้วันที่พนักงานพ้นสภาพก่อนใคร จึงควรเป็นจุดเริ่มของ trigger ที่แจ้งไปยัง IT โดยอัตโนมัติ ฝ่ายจัดซื้อหรือกฎหมายรู้วันที่\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Fma-sla-contract-checklist-before-signing\">สัญญากับ vendor\u003C\u002Fa>สิ้นสุดหรือไม่ต่ออายุ จึงควรเป็นคนแจ้งเช่นกัน เจ้าของระบบ (system owner) ควรเป็นคนเซ็นรับรู้ว่าสิทธิ์ถูกเพิกถอนครบตามรายการ ส่วนฝ่ายความปลอดภัยหรือ compliance ควรเป็นเจ้าของการตรวจ audit log และเก็บหลักฐานไว้ตอบผู้ตรวจสอบ IT ยังเป็นคนลงมือทำจริง แต่ไม่ควรเป็นฝ่ายเดียวที่รู้ว่าต้องทำเมื่อไหร่\u003C\u002Fp>\u003Ch2>เมื่อไม่จำเป็นต้องวางกระบวนการหนักขนาดนี้\u003C\u002Fh2>\u003Cp>ข้อจำกัดที่ต้องพูดให้ชัดคือ ระบบภายในขนาดเล็กที่มีผู้ใช้ไม่กี่คน ไม่มีข้อมูลส่วนบุคคลของลูกค้า และแทบไม่มีการเปลี่ยนตัวผู้ดูแลหรือ vendor ไม่จำเป็นต้องลงทุนกับเครื่องมือ identity governance หรือ automated access review เต็มรูปแบบ การตรวจสอบด้วยมือทุกไตรมาส พร้อมรายชื่อสิทธิ์ที่มีอยู่จริงในตอนนั้น ก็เพียงพอสำหรับความเสี่ยงระดับนี้ สิ่งที่องค์กรขนาดนี้ต้องการคือมีคนรับผิดชอบทำจริงตามรอบที่วางไว้ ไม่ใช่ระบบอัตโนมัติที่ซับซ้อนเกินความจำเป็นของงาน\u003C\u002Fp>\u003Ch2>ข้อโต้แย้งที่ได้ยินบ่อย\u003C\u002Fh2>\u003Cp>ข้อโต้แย้งที่ได้ยินบ่อยที่สุดคือ ทีมงานหรือ vendor รายนี้ทำงานด้วยกันมานานหลายปี ไว้ใจกันได้อยู่แล้ว ทำไมต้องรีบปิดสิทธิ์ทันทีที่สัญญาไม่ต่อ คำถามนี้เข้าใจได้ และคำตอบไม่ได้แปลว่าความสัมพันธ์ที่ผ่านมาไม่มีความหมาย ประเด็นคือความไว้ใจไม่ใช่กลไกควบคุมที่ตรวจสอบได้ เมื่อสัญญาสิ้นสุด ความรับผิดตามกฎหมายและขอบเขตความรับผิดชอบเปลี่ยนไปแล้ว การเพิกถอนสิทธิ์ตามกำหนดจึงไม่ใช่การกล่าวหาใคร แต่เป็นการปิดงานให้เรียบร้อยตามที่ทั้งสองฝ่ายควรทำอยู่แล้ว และเป็นหลักฐานที่ผู้ตรวจสอบภายนอกมักขอดูเมื่อองค์กรต้องผ่านการประเมินความปลอดภัยหรือ PDPA\u003C\u002Fp>\u003Cdiv data-type=\"horizontalRule\">\u003Chr>\u003C\u002Fdiv>\u003Ch2>จะเริ่มตรงไหน\u003C\u002Fh2>\u003Cp>ถ้ายังไม่เคยทำเรื่องนี้อย่างเป็นระบบ จุดเริ่มต้นที่ทำได้จริงภายในไตรมาสนี้มีสี่ข้อ\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>ทำ inventory สิทธิ์เข้าถึงทั้งหมดที่มีอยู่จริงตอนนี้ ทั้งใน Google Cloud, Microsoft Azure และ Cloudflare ว่าใครหรือ service account ไหนเข้าถึงอะไรได้บ้าง\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>เขียน checklist ลำดับการเพิกถอนสิทธิ์ไว้ล่วงหน้า ก่อนที่จะมีคนออกจริง เพื่อไม่ต้องคิดขั้นตอนกลางความเร่งรีบ\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>กำหนดเจ้าของกระบวนการให้ชัดว่าใครแจ้ง ใครลงมือทำ และใครเซ็นรับรู้ว่าทำครบ\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ผูกเงื่อนไขการเพิกถอนสิทธิ์เข้ากับสัญญาจ้างงานและสัญญา vendor ตั้งแต่ต้น ไม่ใช่เขียนเพิ่มตอนใกล้สิ้นสุดสัญญา\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>ทีมของเรา (\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\">Superdev\u003C\u002Fa>) มองกระบวนการนี้เป็นส่วนหนึ่งของงานวางระบบตั้งแต่ต้น ไม่ใช่งานเสริมที่ค่อยคิดทีหลัง\u003C\u002Fp>\u003Cp>สรุปสั้น ๆ ความเสี่ยงของบัญชี Cloud ในช่วงเปลี่ยนมือไม่ได้มาจากภายนอกอย่างเดียว แต่อยู่ที่สิทธิ์เข้าถึงที่ไม่มีใครนัดตรวจตอนคนออกจากทีม ถ้าจะหยิบไปใช้อย่างเดียวจากบทความนี้ ให้เขียนลำดับเพิกถอนสิทธิ์เป็นเอกสารไว้ล่วงหน้า และมอบหมายเจ้าของกระบวนการให้ชัดตั้งแต่วันนี้ หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล contact@superdev.tech สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างทบทวนแนวทางเรื่องสิทธิ์เข้าถึงภายใน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ\u003C\u002Fp>","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fpbc_2128795511\u002Fa4go9qx8jsnmhoj\u002Fcover_cover_jq18t0cags.webp","29 กันยายน 2569","2026-09-29 04:12:02.564Z",109,"Enterprise","enterprise","cloud-access-vendor-transition","\u002Fblogs\u002Fcloud-access-vendor-transition",2,false,0,"",[47,48,49,50,51,52],"IAM","การจัดการสิทธิ์เข้าถึง","cloud security","offboarding","least privilege","audit log"]