WEBVTT

00:00.150 --> 00:03.540
-: เวอร์ชวลไลเซชันชนิดใหม่ล่าสุดที่กำลังเป็นที่นิยมในเครือข่ายของเราเรียกว่า

00:03.540 --> 00:05.790
เวอร์ชวลไลเซชันแบบอิงคอนเทนเนอร์ หรือที่เรียกว่า

00:05.790 --> 00:07.980
คอนเทนเนอร์ไรเซชัน

00:07.980 --> 00:12.780
การจำลองเสมือนประเภทนี้จะเน้นที่เซิร์ฟเวอร์มากกว่าผู้ใช้ปลายทาง

00:12.780 --> 00:16.440
ด้วยการจำลองเสมือนประเภทนี้ เคอร์เนลของระบบปฏิบัติการจะถูกแชร์ระหว่างเครื่องเสมือนหลายเครื่อง

00:16.440 --> 00:22.740
แต่พื้นที่ผู้ใช้สำหรับเครื่องเสมือนแต่ละเครื่องจะถูกสร้างขึ้นและจัดการโดยไม่ซ้ำกัน

00:22.740 --> 00:31.230
Containerization คือการจำลองเสมือนประเภทหนึ่งที่ระบบปฏิบัติการโฮสต์ใช้เพื่อจัดเตรียมสภาพแวดล้อมการดำเนินการแบบแยกสำหรับแอปพลิเคชัน

00:31.230 --> 00:38.280
การบรรจุลงตู้คอนเทนเนอร์ถือว่ามีความปลอดภัยพอสมควรเพราะบังคับใช้การแบ่งส่วนและการแยกทรัพยากรในระดับระบบปฏิบัติการ

00:38.280 --> 00:40.290
ขณะนี้การทำคอนเทนเนอร์มักใช้กับเซิร์ฟเวอร์

00:40.290 --> 00:43.950
Linux และตัวอย่างบางส่วนของการทำเวอร์ชวลไลเซชันตามคอนเทนเนอร์นี้

00:43.950 --> 00:48.960
ได้แก่ โครงการ Docker, Parallels Virtuozzo และ OpenVZ

00:48.960 --> 00:51.870
ตอนนี้การบรรจุคอนเทนเนอร์มีลักษณะอย่างไร

00:51.870 --> 00:53.610
คุณมีฮาร์ดแวร์ชิ้นหนึ่ง และนอกเหนือจากฮาร์ดแวร์นั้นแล้ว

00:53.610 --> 00:59.430
คุณมีระบบปฏิบัติการโฮสต์ ซึ่งโดยปกติจะเป็น Linux และจากนั้นคุณก็มีตัวจัดการคอนเทนเนอร์

00:59.430 --> 01:02.820
บางอย่างเช่น Kubernetes หรือ Docker หรืออะไรทำนองนั้น

01:02.820 --> 01:05.100
ตอนนี้ตัวจัดการคอนเทนเนอร์นี้จะถูกใช้เพื่อสร้างคอนเทนเนอร์ต่างๆ

01:05.100 --> 01:08.070
ที่มีแอปพลิเคชันที่แตกต่างกัน

01:08.070 --> 01:10.290
ในกรณีนี้ ฉันมีคอนเทนเนอร์สามคอนเทนเนอร์

01:10.290 --> 01:12.000
ฉันมีสภาพแวดล้อมแรก ซึ่งอิงตามเคอร์เนลของระบบปฏิบัติการโฮสต์

01:12.000 --> 01:16.170
ในตัวอย่างนี้ ระบบ Linux ที่กำลังใช้งานอยู่

01:16.170 --> 01:20.700
ดังนั้นเราจึงมีคอนเทนเนอร์หนึ่งที่ใช้ Linux และมีแอปพลิเคชันบางตัวอยู่ที่นั่น

01:20.700 --> 01:23.130
ตอนนี้คอนเทนเนอร์ 2 สามารถทำสิ่งเดียวกันได้ และคอนเทนเนอร์

01:23.130 --> 01:25.290
3 สามารถทำสิ่งเดียวกันได้

01:25.290 --> 01:28.980
เนื่องจากคอนเทนเนอร์ทั้งสามแชร์ไฟล์ระบบปฏิบัติการโฮสต์เดียวกัน

01:28.980 --> 01:33.690
สิ่งนี้ใช้ทรัพยากรน้อยกว่าการทำเวอร์ช่วลไลเซชั่นโดยตรงโดยใช้เครื่องเสมือน

01:33.690 --> 01:35.730
เหมือนที่เราพูดถึง virtualization

01:35.730 --> 01:40.860
หากเราใช้เครื่องเสมือนแต่ละเครื่องแทน แต่ละเครื่องจะต้องมีระบบปฏิบัติการของตนเอง

01:40.860 --> 01:43.740
และนั่นอาจเป็น 8 ถึง 10 กิกะไบต์สำหรับแต่ละอัน

01:43.740 --> 01:47.280
แต่ด้วยคอนเทนเนอร์ เราทุกคนสามารถใช้ระบบปฏิบัติการเดียวกันร่วมกันได้

01:47.280 --> 01:52.260
ดังนั้นการทำคอนเทนเนอร์จึงใช้ฐานการจัดเก็บน้อยกว่ามากและใช้พลังงานในการประมวลผลน้อยกว่ามาก

01:52.260 --> 01:56.970
นี่คือประโยชน์ที่แท้จริงของการใช้บางอย่างเช่นคอนเทนเนอร์จากมุมมองของการปฏิบัติงาน

01:56.970 --> 01:59.970
ตอนนี้ เนื่องจากคอนเทนเนอร์เหล่านี้ถูกแยกออกอย่างมีเหตุผล

01:59.970 --> 02:02.100
พวกเขาไม่สามารถติดต่อกันได้

02:02.100 --> 02:04.080
ถ้าฉันต้องการให้สองคอนเทนเนอร์คุยกัน ฉันต้องเชื่อมต่อผ่านเครือข่ายเสมือน

02:04.080 --> 02:09.330
และทำการกำหนดเส้นทางและสลับให้ถูกต้องเพื่อให้คอนเทนเนอร์พูดได้

02:09.330 --> 02:11.970
โดยค่าเริ่มต้น พวกเขาไม่มีทางพูดคุยกันได้

02:11.970 --> 02:14.310
และนี่เป็นสิ่งที่ดีจากมุมมองด้านความปลอดภัย

02:14.310 --> 02:16.410
เพราะเรามีการแบ่งส่วนนี้

02:16.410 --> 02:20.010
ต่อไปนี้เป็นคำเตือนสำคัญของคุณเมื่อต้องจัดการกับคอนเทนเนอร์

02:20.010 --> 02:22.890
หากผู้โจมตีบุกรุก OS โฮสต์ข้างใต้ เช่น

02:22.890 --> 02:24.990
ระบบปฏิบัติการ Linux ที่ฉันเพิ่งพูดถึง

02:24.990 --> 02:27.960
ลองเดาดูว่าเกิดอะไรขึ้น

02:27.960 --> 02:30.810
ตอนนี้การโจมตีนี้สามารถเข้าถึงคอนเทนเนอร์ทั้งหมดในข้อมูลของพวกเขาได้

02:30.810 --> 02:35.790
เนื่องจากคอนเทนเนอร์ทั้งหมดที่ถูกโฮสต์ใช้ระบบปฏิบัติการเดียว

02:35.790 --> 02:38.820
นี่เป็นหนึ่งในช่องโหว่ที่ใหญ่ที่สุดเมื่อคุณใช้คอนเทนเนอร์

02:38.820 --> 02:40.470
ฉันสามารถมีระบบคอนเทนเนอร์ที่ใช้งานเซิร์ฟเวอร์ที่แตกต่างกัน

02:40.470 --> 02:42.240
50 เครื่องได้ในขณะนี้

02:42.240 --> 02:46.230
และแต่ละอันกำลังเรียกใช้เซิร์ฟเวอร์และบริการที่แตกต่างกันโดยใช้คอนเทนเนอร์

02:46.230 --> 02:49.050
แต่ถ้ามีใครสามารถเข้าถึงเซิร์ฟเวอร์ที่อยู่ภายใต้ระบบปฏิบัติการ

02:49.050 --> 02:52.020
Linux นั้น ตอนนี้พวกเขาสามารถเข้าถึงเซิร์ฟเวอร์ที่โฮสต์เหล่านั้นทั้งหมด

02:52.020 --> 02:55.290
50 เครื่องและข้อมูลทั้งหมดของพวกเขา

02:55.290 --> 02:57.480
ความเสี่ยงอีกประการหนึ่งที่ต้องพิจารณาคือวิธีโฮสต์คอนเทนเนอร์และเครื่องเสมือนอื่นๆ

02:57.480 --> 03:00.390
ของคุณ

03:00.390 --> 03:03.210
เมื่อเราเริ่มพึ่งพาการจำลองเสมือนและการประมวลผลแบบคลาวด์

03:03.210 --> 03:09.660
สิ่งสำคัญคือต้องตระหนักว่าข้อมูลของเราอาจถูกโฮสต์บนเซิร์ฟเวอร์จริงเดียวกันกับข้อมูลขององค์กรอื่น

03:09.660 --> 03:13.920
ด้วยการทำเช่นนั้น เราแนะนำช่องโหว่บางอย่างในการรักษาความปลอดภัยของระบบของเรา

03:13.920 --> 03:16.950
ประการแรก หากเซิร์ฟเวอร์จริงล่มเนื่องจากสิ่งที่องค์กรอื่นกำลังทำอยู่

03:16.950 --> 03:22.500
อันที่จริงแล้วอาจส่งผลกระทบต่อองค์กรทั้งหมดบนเซิร์ฟเวอร์เดียวกันนั้น

03:22.500 --> 03:24.960
ในทำนองเดียวกัน หากองค์กรหนึ่งไม่รักษาความปลอดภัยของสภาพแวดล้อมเสมือน

03:24.960 --> 03:26.760
พวกเขาถูกโฮสต์บนเซิร์ฟเวอร์จริงนั้น

03:26.760 --> 03:31.470
มีความเป็นไปได้ที่ผู้โจมตีสามารถใช้สิ่งนั้นเพื่อสร้างความเสียหายให้กับองค์กรอื่น

03:31.470 --> 03:35.880
ๆ ทั้งหมดที่โฮสต์บนเซิร์ฟเวอร์เดียวกันนั้น

03:35.880 --> 03:38.220
เช่นเดียวกับที่มีข้อกังวลเมื่อเชื่อมต่อระหว่างเครือข่ายของเรากับของผู้อื่น

03:38.220 --> 03:44.010
ก็มีข้อกังวลเกี่ยวกับการโฮสต์ข้อมูลขององค์กรหลายแห่งบนเซิร์ฟเวอร์จริงเดียวกัน

03:44.010 --> 03:50.820
เป็นสิ่งสำคัญสำหรับเราในการกำหนดค่า จัดการ และตรวจสอบการเข้าถึงเครื่องเสมือนที่โฮสต์บนเซิร์ฟเวอร์เหล่านั้นอย่างเหมาะสม

03:50.820 --> 03:53.850
นอกจากนี้ เราต้องการให้แน่ใจว่าเครื่องเสมือนของเรามีแพตช์ล่าสุด

03:53.850 --> 03:58.410
แอนตี้ไวรัส แอนิมอลไวร์ และการควบคุมการเข้าถึงในสถานที่

03:58.410 --> 04:02.490
เพื่อลดความเสี่ยงของการที่ทรัพยากรของเซิร์ฟเวอร์ทางกายภาพถูกใช้งานมากเกินไป

04:02.490 --> 04:04.920
คุณควรตั้งค่าเครื่องเสมือนของเราด้วยการเฟลโอเวอร์ที่เหมาะสม

04:04.920 --> 04:08.280
ความซ้ำซ้อน และความยืดหยุ่นที่เหมาะสม

04:08.280 --> 04:13.500
การตรวจสอบประสิทธิภาพเครือข่ายและทรัพยากรของเซิร์ฟเวอร์จริงทำให้เราสามารถปรับสมดุลของโหลดระหว่างเครื่องจริงหลายๆ

04:13.500 --> 04:17.370
เครื่องแทนที่จะใช้เพียงเครื่องเดียว

04:17.370 --> 04:24.420
ช่องโหว่อื่นที่อาจถูกโจมตีโดยผู้โจมตีคือเมื่อเราใช้ไฮเปอร์ไวเซอร์ประเภทเดียวกันในเครื่องเสมือนทั้งหมดของเรา

04:24.420 --> 04:27.180
ตัวอย่างเช่น หากองค์กรของเราใช้ไฮเปอร์ไวเซอร์

04:27.180 --> 04:32.280
ESXi ของ VMware เพียงอย่างเดียว และมีการสร้างช่องโหว่ใหม่สำหรับไฮเปอร์ไวเซอร์นั้น

04:32.280 --> 04:35.790
ผู้โจมตีก็สามารถใช้สิ่งนั้นกับระบบทั้งหมดของเรา

04:35.790 --> 04:38.400
ดังนั้น หากประสบความสำเร็จในเซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งของเรา

04:38.400 --> 04:40.830
พวกเขาน่าจะลองใช้งานบนเซิร์ฟเวอร์ที่เหลือของเรา

04:40.830 --> 04:43.260
และหากเซิร์ฟเวอร์ทั้งหมดของเราใช้แพลตฟอร์มเดียวกันในกรณีนี้

04:43.260 --> 04:49.350
ESXi ของ VMware ช่องโหว่นี้อาจถูกโจมตีทั่วทั้งองค์กรของเรา

04:49.350 --> 04:51.420
ความท้าทายในเรื่องนี้ก็คือ หากเราใช้แพลตฟอร์มไฮเปอร์ไวเซอร์หลายตัว

04:51.420 --> 04:57.360
ค่าใช้จ่ายในการสนับสนุนและข้อกำหนดการฝึกอบรมของเราก็เพิ่มขึ้นเช่นกัน

04:57.360 --> 05:00.090
ด้วยเหตุนี้องค์กรส่วนใหญ่จึงเลือกที่จะใช้แพลตฟอร์มเดียว

05:00.090 --> 05:04.800
แต่อย่างน้อยพวกเขากำลังทำการตัดสินใจเกี่ยวกับความเสี่ยงที่วัดได้เมื่อทำเช่นนั้น

05:04.800 --> 05:07.290
เพื่อลดความเสี่ยงดังกล่าว องค์กรควรใช้การกำหนดค่าที่เหมาะสม

05:07.290 --> 05:16.830
ตรวจสอบให้แน่ใจว่าไฮเปอร์ไวเซอร์ยังคงได้รับการแพตช์และอัปเดตอยู่เสมอ และเข้าถึงได้ผ่านอินเทอร์เฟซการจัดการที่ปลอดภัยเท่านั้น เช่นเดียวกับการควบคุมการเข้าถึงอย่างเข้มงวด

05:16.830 --> 05:25.410
ต่อไปนี้คือบางสิ่งที่คุณต้องพิจารณาเมื่อเริ่มห่างไกลหากคุณกำลังจะทำระบบเสมือนจริงและย้ายระบบไปยังโซลูชันในองค์กรหรือบนคลาวด์

05:25.410 --> 05:27.540
อันดับแรก คุณจะทำเวอร์ชวลไลซ์หรือไม่

05:27.540 --> 05:32.430
ถ้าเป็นเช่นนั้น คุณจะใช้เครื่องเสมือนแบบเดิมหรือจะใช้การบรรจุคอนเทนเนอร์

05:32.430 --> 05:34.410
อะไรคือความเสี่ยงและผลตอบแทนที่นี่?

05:34.410 --> 05:35.970
มีการกระทำที่สมดุลที่คุณต้องทำ

05:35.970 --> 05:39.780
เป็นการตัดสินใจทางธุรกิจและเป็นการตัดสินใจด้านความปลอดภัยในโลกไซเบอร์ด้วย

05:39.780 --> 05:45.723
ดังนั้น คุณจะต้องวัดสิ่งเหล่านี้และตัดสินใจเลือกสิ่งที่ดีที่สุดสำหรับองค์กรของคุณและกรณีการใช้งานเฉพาะ