VPS hosting ปลอดภัยไหม? สรุปสิ่งที่ต้องดูแลเอง

VPS hosting ปลอดภัยหรือไม่? คำตอบโดยสรุป

ปลอดภัย VPS hosting มีความปลอดภัยเพียงพอสำหรับงานส่วนใหญ่ที่ผู้ใช้ซื้อบริการ และถือเป็นการยกระดับจาก shared hosting อย่างแท้จริง VPS (virtual private server) คือเครื่องเสมือนที่มี kernel, หน่วยความจำ, พื้นที่จัดเก็บข้อมูล และบัญชีผู้ใช้เป็นของตนเอง โดยมี hypervisor ทำหน้าที่แยกทรัพยากรเหล่านี้ไม่ให้ผู้ใช้รายอื่นเข้าถึงได้ ผู้ที่เช่าเซิร์ฟเวอร์เครื่องถัดไปจากคุณบนฮาร์ดแวร์เดียวกันจะไม่สามารถอ่านไฟล์, ดูรายการ process, ล็อกอินเข้าสู่เซิร์ฟเวอร์ หรือดักจับ network traffic ของคุณได้

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

สิ่งที่ hypervisor แยกออกจากกันจริงๆ

Hypervisor คือซอฟต์แวร์ที่ทำหน้าที่รัน virtual machine บนโฮสต์ทางกายภาพหนึ่งเครื่อง สำหรับ KVM VPS (KVM ย่อมาจาก kernel based virtual machine ซึ่งเป็นมาตรฐานบนโฮสต์ Linux) เซิร์ฟเวอร์ของคุณจะเป็น virtual machine เต็มรูปแบบ มันจะบูต kernel ของตัวเอง โฮสต์จะจัดสรรพื้นที่หน่วยความจำทางกายภาพที่กำหนดไว้ให้ และหน่วยจัดการหน่วยความจำ (memory management unit) ของโปรเซสเซอร์จะปฏิเสธการเข้าถึงใดๆ ที่อยู่นอกเหนือพื้นที่ดังกล่าว ดังนั้นโค้ดที่รันอยู่ใน guest อื่นจึงไม่สามารถเข้าถึง RAM ของคุณได้เลย ทั้งนี้ไม่มีการใช้ระบบไฟล์ร่วมกันและไม่มีการใช้ตารางผู้ใช้ร่วมกัน ดังนั้นสิทธิ์การเข้าถึงไฟล์บนเซิร์ฟเวอร์ของเพื่อนบ้านจึงไม่มีผลใดๆ ต่อเซิร์ฟเวอร์ของคุณ

Shared hosting ทำงานต่างออกไป เว็บไซต์จำนวนมากอาศัยอยู่ภายในระบบปฏิบัติการเดียว ภายใต้เว็บเซิร์ฟเวอร์เดียวและการติดตั้ง PHP เดียวกัน ในฐานะบัญชีผู้ใช้ทั่วไป ขอบเขตเดียวที่มีคือสิทธิ์การเข้าถึงไฟล์ ดังนั้นความผิดพลาดในการตั้งค่าสิทธิ์ หรือปลั๊กอินที่มีช่องโหว่ซึ่งรันในฐานะผู้ใช้ที่สามารถอ่านไฟล์ได้มากเกินไป จึงอาจเข้าถึงไฟล์ของบัญชีอื่นได้ นั่นคือช่องว่างที่ การย้ายจาก shared hosting ไปยัง VPS ช่วยปิดลง

ตรวจสอบสิ่งที่คุณกำลังซื้อ เพราะไม่ใช่ทุกแผนที่ขายในชื่อ VPS จะเป็น virtual machine แผนที่ใช้ container (OpenVZ, LXC, Virtuozzo) จะใช้ kernel ของโฮสต์ร่วมกันและแยกผู้ใช้งานด้วย namespaces และ cgroups แทนการทำ virtualization ในระดับฮาร์ดแวร์ ซึ่งเป็นขอบเขตที่อ่อนแอกว่า เพราะบั๊กของ kernel บนโฮสต์ก็คือบั๊กของ kernel ในเซิร์ฟเวอร์ของคุณด้วยเช่นกัน นอกจากนี้คุณยังไม่สามารถโหลด kernel module บนแผนเหล่านี้ได้ ซึ่งทำให้ซอฟต์แวร์บางตัวไม่สามารถใช้งานได้ KVM จึงเป็นตัวเลือกเริ่มต้นที่ปลอดภัยกว่า ควรสอบถามให้แน่ชัดว่าคุณจะได้รับบริการประเภทใดก่อนทำการชำระเงิน

ผลกระทบจากเพื่อนบ้านที่ใช้ทรัพยากรหนาแน่น

การแชร์โฮสต์ทางกายภาพทำให้คุณเสียความเร็ว และความเร็วเป็นสิ่งเดียวที่ต้องแลกไป แขกที่ใช้งานบนเครื่องเดียวกันจะแชร์ CPU และดิสก์ทางกายภาพร่วมกัน เมื่อ CPU ยุ่งอยู่กับการประมวลผลของผู้อื่น vCPU ของคุณจะต้องรอ และ Linux จะรายงานการรอนั้นว่าเป็น steal time ซึ่งคือฟิลด์ %st ใน top และ vmstat หากค่า steal time สูงกว่าไม่กี่เปอร์เซ็นต์ต่อเนื่องเป็นเวลาหลายชั่วโมง แสดงว่าโฮสต์นั้นมีการใช้งานเกินขีดจำกัด (oversubscribed) แต่นั่นไม่ได้หมายความว่ามีใครกำลังอ่านข้อมูลของคุณอยู่ วิธีแก้ไขคือการเปลี่ยนแผนการใช้งานหรือเปลี่ยนผู้ให้บริการ โดยคุณสามารถ วัดประสิทธิภาพ CPU และดิสก์ที่คุณได้รับจริง ก่อนตัดสินใจ

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

สิ่งที่เพื่อนบ้านที่ไม่ประสงค์ดีทำไม่ได้ และกรณีที่หาได้ยากซึ่งพวกเขาสามารถทำได้

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

การหลุดออกจาก Hypervisor เป็นเรื่องจริง บั๊กในเลเยอร์การจำลองเสมือนสามารถทำให้โค้ดภายใน guest หนึ่งเครื่องเข้าถึงโฮสต์ได้ และจากโฮสต์สามารถเข้าถึงทุก guest ที่อยู่บนนั้น บั๊กเหล่านี้ถูกค้นพบ เผยแพร่พร้อมรหัสระบุ CVE (common vulnerabilities and exposures) และได้รับการแก้ไข โดยผู้ให้บริการโฮสติ้งจะทำการแพตช์อย่างรวดเร็วเนื่องจากธุรกิจทั้งหมดของพวกเขาตั้งอยู่บนเลเยอร์นั้น การใช้ประโยชน์จากบั๊กเหล่านี้ต้องอาศัย exploit ที่ใช้งานได้จริงสำหรับเวอร์ชันของ Hypervisor นั้นๆ ซึ่งเป็นสิ่งที่ราคาแพงเกินกว่าจะนำมาใช้กับบัญชีโฮสติ้งขนาดเล็ก

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

ขอบเขตความรับผิดชอบระหว่างผู้ให้บริการและตัวคุณ

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

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

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

ผู้ให้บริการโฮสติ้งสามารถเข้าถึงข้อมูลของคุณได้หรือไม่

ในทางทฤษฎีสามารถทำได้ และนี่คือข้อจำกัดตามความเป็นจริงของบริการ VPS ข้อมูล disk image ของคุณถูกจัดเก็บอยู่บนพื้นที่เก็บข้อมูลของผู้ให้บริการ คอนโซลของผู้ให้บริการสามารถเข้าถึงหน้าจอของเครื่องเสมือน (virtual machine) ของคุณได้โดยตรง โหมดกู้คืน (rescue mode) สามารถบูตระบบปฏิบัติการอื่นโดยเชื่อมต่อกับดิสก์ของคุณได้ VPS ช่วยป้องกันคุณจากลูกค้าคนอื่น แต่ผู้ให้บริการยังคงอยู่นอกเหนือขอบเขตการป้องกันนั้น

หากคุณมีข้อมูลที่ต้องไม่ให้โฮสต์อ่านได้ คุณควรเข้ารหัสข้อมูลนั้นในระดับแอปพลิเคชันก่อนทำการเขียนลงดิสก์ การเข้ารหัสทั้งดิสก์ (full disk encryption) ภายใน guest OS ช่วยป้องกันกรณีที่มีการคัดลอกไฟล์ image ไป แต่กุญแจเข้ารหัสยังคงต้องอยู่ในหน่วยความจำขณะที่เซิร์ฟเวอร์ทำงานอยู่ ดังนั้นวิธีนี้จึงไม่ได้ตัดผู้ให้บริการออกจากการเข้าถึงข้อมูลได้ทั้งหมด ความเชื่อใจในระดับเดียวกันนี้ยังคงใช้กับ เซิร์ฟเวอร์เฉพาะ (dedicated server) ที่คุณเช่าใช้งานเพียงผู้เดียว เพียงแต่มีชั้นการทำงานที่ต้องเชื่อใจน้อยลงหนึ่งชั้นเท่านั้น

สิ่งที่ทำให้ VPS ถูกบุกรุก

บริการที่เปิดรับการเชื่อมต่อจากทุกอินเทอร์เฟซ ฐานข้อมูล, แคช, คิวข้อความ และแผงควบคุมผู้ดูแลระบบมักตั้งค่าเริ่มต้นให้ผูกกับ 0.0.0.0 ซึ่งหมายถึงทุกอินเทอร์เฟซเครือข่ายรวมถึงอินเทอร์เฟซสาธารณะ การสแกนเครือข่ายอินเทอร์เน็ตเกิดขึ้นอย่างต่อเนื่องและเป็นอัตโนมัติ ดังนั้น IP address ใหม่จะถูกตรวจสอบโดยไม่ได้รับเชิญภายในไม่กี่นาทีหลังจากออนไลน์ Redis ที่ไม่มีรหัสผ่าน, โหนด Elasticsearch ที่ไม่มีการยืนยันตัวตน, Docker API ที่เปิดพอร์ต 2375 และแผงควบคุมที่ยังใช้รหัสผ่านเริ่มต้น ล้วนถูกค้นพบด้วยวิธีนี้โดยสแกนเนอร์ที่ไม่ทราบว่าคุณเป็นใคร ให้ผูกบริการกับ 127.0.0.1 เมื่อต้องการใช้งานเฉพาะภายในเครื่องเท่านั้น และบล็อกการเชื่อมต่อส่วนที่เหลือที่ไฟร์วอลล์

Docker ที่ข้ามการทำงานของไฟร์วอลล์ การประกาศพอร์ตของคอนเทนเนอร์จะเขียนกฎ Network Address Translation (NAT) ซึ่งถูกประเมินก่อนกฎจาก ufw (Uncomplicated Firewall) ดังนั้นคอนเทนเนอร์จึงอาจเข้าถึงได้จากอินเทอร์เน็ตในขณะที่ ufw status ระบุว่าพอร์ตนั้นถูกปฏิเสธ สิ่งนี้มักทำให้ผู้ที่ตั้งค่าส่วนอื่นถูกต้องทั้งหมดพลาดไป เหตุผลที่พอร์ตของ Docker ไม่สนใจ ufw เป็นสิ่งที่ควรอ่านก่อนที่จะประกาศพอร์ตของคอนเทนเนอร์

SSH ที่เปิดใช้งานการล็อกอินด้วยรหัสผ่าน หากอ่าน /var/log/auth.log บนเซิร์ฟเวอร์สาธารณะใดๆ คุณจะพบรายการเช่น Failed password for root from 203.0.113.10 port 54312 ssh2 นับพันรายการทั้งกลางวันและกลางคืน บอทจะพยายามสุ่มชื่อผู้ใช้และรหัสผ่านที่พบบ่อย การล็อกอินด้วยรหัสผ่านรวมถึงบัญชี root ที่ยอมรับการล็อกอินคือสิ่งที่ผู้โจมตีต้องการ การใช้เฉพาะคีย์และปิดการล็อกอินด้วย root จะเปลี่ยนทราฟฟิกเหล่านั้นให้กลายเป็นเสียงรบกวนที่คุณสามารถเพิกเฉยได้

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

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

ความลับที่รั่วไหล รหัสผ่านฐานข้อมูลและ API keys มักอยู่ในไฟล์ .env และไฟล์เหล่านั้นอาจถูกคอมมิตไปยัง repository สาธารณะ หรือถูกเสิร์ฟโดยเว็บเซิร์ฟเวอร์ที่ชี้ไปยังไดเรกทอรีที่ไม่ถูกต้อง สิ่งใดก็ตามที่ถูกวางลงในบริบทของ AI coding agent อาจไปปรากฏใน log ได้เช่นกัน ซึ่งเป็นหัวข้อเฉพาะ: การเก็บความลับให้พ้นจากมือของ agent

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

หน้าที่ของคุณ

งานทั้งหมดต่อไปนี้ไม่ใช่หน้าที่ของ hypervisor แต่เป็นหน้าที่ของคุณโดยตรง ซึ่งเป็นส่วนที่ตัดสินว่า VPS ของคุณมีความปลอดภัยหรือไม่

• ดำเนินการตั้งค่าเริ่มต้นให้ถูกต้อง: สิบนาทีแรกบน VPS ใหม่ ครอบคลุมการสร้างผู้ใช้ที่ไม่ใช่ root และการตั้งค่า firewall
• จำกัดการเข้าถึงจากระยะไกล: การเพิ่มความปลอดภัยให้ SSH บน VPS
• ปิดพอร์ตที่ไม่ได้ใช้งาน: พื้นฐานการใช้งาน ufw firewall
• ให้สิทธิ์การเข้าถึงแก่แต่ละบริการเท่าที่จำเป็นเท่านั้น: การใช้สิทธิ์ขั้นต่ำสำหรับผู้ใช้บน VPS
• ชะลอการพยายามล็อกอินแบบ brute force: fail2ban บน Ubuntu 24.04
• สำรองข้อมูลและทดสอบการกู้คืนอย่างน้อยหนึ่งครั้ง: การสำรองข้อมูลด้วย restic สำหรับ VPS

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

FAQ

ลูกค้ารายอื่นบนเซิร์ฟเวอร์กายภาพเดียวกันสามารถอ่านไฟล์ของฉันได้หรือไม่?

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

VPS ปลอดภัยกว่า shared hosting หรือไม่?

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

ผู้ให้บริการโฮสติ้งสามารถอ่านข้อมูลของฉันได้หรือไม่?

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

วิธีที่พบบ่อยที่สุดที่ทำให้ VPS ถูกบุกรุกคืออะไร?

ส่วนใหญ่เกิดจากบริการที่เปิดเผยต่อสาธารณะหรือการล็อกอิน SSH ที่อ่อนแอ สแกนเนอร์อัตโนมัติจะตรวจสอบทุก IP address ที่เป็นสาธารณะอยู่ตลอดเวลา ดังนั้นฐานข้อมูลที่ผูกกับ 0.0.0.0 โดยไม่มีรหัสผ่าน หรือแผงควบคุมผู้ดูแลระบบที่ยังใช้รหัสผ่านเริ่มต้น จะถูกพบภายในเวลาไม่กี่นาทีไม่ใช่เป็นเดือน /var/log/auth.log บนเซิร์ฟเวอร์สาธารณะใดๆ จะแสดงให้เห็นส่วนของ SSH: บรรทัด Failed password for root ที่ซ้ำๆ กันจากที่อยู่ทั่วโลก การเจาะทะลุ Hypervisor นั้นมีอยู่จริง แต่เป็นงานระดับวิจัยที่มุ่งเป้าไปยังเป้าหมายที่มีมูลค่าสูง ไม่ใช่สาเหตุของการบุกรุกทั่วไป