Skip links
View
Drag

Tech Talk

Alibaba ผู้ให้บริการ IaaS รายใหญ่อันดับ 3 ของโลก โดย Gartner

Alibaba ผู้ให้บริการ IaaS รายใหญ่อันดับ 3 ของโลก โดย Gartner อาลีบาบาได้รับการขนานนามว่าเป็นผู้ให้บริการ IaaS เป็นรายใหญ่อันดับ 3 ของโลก และเป็นอันดับ 1 ในเอเชียแปซิฟิกโดย Gartner Alibaba Cloud  เป็นบริษัทผู้นำด้านโครงข่ายข้อมูลอัจฉริยะหลักของ Alibaba Group ซึ่งได้รับการประกาศว่ามีส่วนแบ่งทางการตลาดที่ใหญ่เป็นอันดับ 3 ของโลกในการให้บริการด้านโครงสร้างพื้นฐาน (IaaS) และในปี 2019 Alibaba Cloud  ยังเป็นผู้ให้บริการในตลาดที่ใหญ่ที่สุดในภูมิภาคเอเชียแปซิฟิกเป็นปีที่ 3 ติดต่อกัน กล่าวในรายงานล่าสุดจากผู้เชี่ยวชาญด้านการวิจัยและที่ปรึกษาระดับโลกของ Gartner ส่วนแบ่งการตลาดของอาลีบาบาในตลาด IaaS ทั่วโลกในปี 2019 ได้ไต่ระดับขึ้นไปที่ 9.1% ขึ้นมา 7.7% เทียบกับปีก่อนหน้า จากรายงานส่วนแบ่งการตลาดบริการด้านไอทีปี 2019 ของ Gartner นอกจากนี้ยังแสดงให้เห็นว่าในส่วนของภูมิภาคเอเชียแปซิฟิก ส่วนแบ่งการตลาดของอาลีบาบาเพิ่มขึ้นเป็น 28.2% ในปีที่ผ่านมาจากเดิมที่ 26.1% ใน2018 “เราเชื่อว่าการเติบโตที่แข็งแกร่งและการเป็นผู้นำในตลาดชั้นนำของเราเป็นข้อพิสูจน์ให้เห็นถึงการทำงานอย่างหนักของทีมงาน ในการสนับสนุน ช่วยเหลือ ลูกค้าและพันธมิตรจำนวนมากของเราทั่วโลกซึ่งเรารู้สึกขอบคุณอย่างแท้จริง” Jeff Zhang ประธาน Alibaba Cloud Intelligence กล่าว “เรามุ่งเน้นที่จะได้ทำงาน ช่วยให้ลูกค้าและพันธมิตรทั่วโลกของเราสามารถปรับกลยุทธ์ให้สามารถเข้าสู่การเปลี่ยนแปลงในรูปแบบดิจิทัลผ่านโครงสร้างพื้นฐานที่สามารถปรับขนาดได้ อย่างมีประสิทธิภาพและปลอดภัย รวมถึงความสามารถในการวิเคราะห์ข้อมูลขั้นสูงและยังพร้อมด้วยระบบนิเวศที่พัฒนาได้อย่างต่อเนื่อง” “รายงานฉบับนี้แสดงให้เห็นถึงความมุ่งมั่นของอาลีบาบาคลาวด์ต่อกลยุทธ์ระดับโลก ที่ตั้งเป้าขยายสถานะไปทั่วโลกด้วยการเสริมสร้างโครงสร้างพื้นฐานและเครือข่ายเน็ตเวิร์คระดับโลกของเรา” Zhang กล่าวเพิ่มเติม ปัจจุบัน Alibaba Cloud สามารถให้บริการในพื้นที่ที่ครอบคลุมมากถึง 63 โซน 21ภูมิภาค และมีความพร้อมในการให้บริการลูกค้านับล้านทั่วโลก อีกทั้งยังได้การรับรองเรื่องความปลอดภัยและปฏิบัติตามมาตรฐานสากลมากกว่า 70 แห่งทั่วโลก Alibaba Cloud มุ่งมั่นที่จะนำเสนอบริการบนระบบคลาวด์ที่เพิ่มมากขึ้นและดียิ่งขึ้น โดยมีแผนที่จะลงทุนเพิ่มอีก 2แสนล้านหยวน (ประมาณ 28พันล้านเหรียญสหรัฐ) ในระหว่าง 3 ปีข้างหน้า โดยการลงทุนจะเน้นไปที่ โครงสร้างพื้นฐานระบบคลาวด์  ทั้งในส่วนเทคโนโลยี ,ระบบปฏิบัติการ, เซิร์ฟเวอร์, หน่วยประมลผล และ เครือข่ายโครงสร้างพื้นฐาน Alibaba Cloud เป็นเทคโนโลยีและแพลตฟอร์มระบบคลาวด์สาธารณะที่ให้การสนับสนุนระบบนิเวศที่หลากหลายตั้งแต่อีคอมเมิร์ซ ระบบการชำระเงินไปจนถึงโซลูชันการจัดการโลจิสติกส์และซัพพลายเชน ซึ่งสามารถรองรับการทำธุรกรรมที่มีมูลค่าสูงถึง 38.4พันล้านเหรียญสหรัฐ ภายในหนึ่งวันของช่วงเทศกาลช้อปปิ้งระดับโลก อาลีบาบา 11.11 ในปีที่ผ่านมา นอกเหนือจากรายงานวิจัยของ Gartner ที่กล่าวถึงแล้ว รายงานก่อนหน้านี้จากการวิจัยตลาดและบริษัทที่ปรึกษา International Data Corporation (IDC) แสดงให้เห็นว่า Alibaba Cloud ได้มีการบันทึกถึงการเติบโตของรายได้ตลอดทั้งปีที่เร็วที่สุด เมื่อเทียบกับผู้ให้บริการระบบคลาวด์ทั่วโลกรายอื่นๆ ในช่วงครึ่งแรกของปีที่ผ่านมา หากต้องการดูรายงาน Gartner โปรดคลิกที่นี่ (เนื้อหาสามารถเข้าถึงได้เฉพาะสมาชิก Gartner เท่านั้น โดยระบุไว้ในรายงานในนามของ Alibaba Group)

admin mfec

admin mfec

คำแนะนำเกี่ยวกับการป้องกันด้านความปลอดภัยด้วย CDN: การจัดการการปลอมแปลง การโจมตี และเนื้อหา

หลังจากวิวัฒนาการทางเทคนิคและประสบการณ์การใช้งานจริงมานานกว่าทศวรรษ เครือข่ายการจัดส่งเนื้อหา (CDN) ของอาลีบาบาคลาวด์ก็ได้ย้ายออกจากการเร่งความเร็วแบบเดิม เพื่อค่อย ๆ สร้างระบบการป้องกันสามมิติโดยใช้เครือข่ายความปลอดภัยแบบ Edge-Cloud ระบบนี้ครอบคลุมการส่งผ่านที่ปลอดภัยแบบ End-to-End, ป้องกันการโจมตีทั่วไปบนโหนด, การปรับใช้ทรัพยากรเฉพาะระดับองค์กร, O&M และการป้องกันความปลอดภัยของเนื้อหา CDN จะช่วยสร้างช่องทางที่ปลอดภัยและเชื่อถือได้ระหว่างองค์กรและอินเทอร์เน็ต ความสามารถด้านความปลอดภัยขั้นพื้นฐานช่วยให้มั่นใจได้ถึงความปลอดภัยในการรับส่งข้อมูลแบบ End-to-End การป้องกันเซิร์ฟเวอร์ต้นทาง เนื่องจากสถาปัตยกรรมแบบกระจายของ CDN ผู้ใช้สามารถรับเนื้อหาได้จากการเข้าถึงโหนดใกล้เคียงซึ่งสามารถซ่อนที่อยู่ IP ต้นทางได้อย่างมีประสิทธิภาพและลดแรงกดดันของการเข้าถึงเซิร์ฟเวอร์ต้นทาง ในกรณีที่มีการโจมตีทางไซเบอร์ขนาดใหญ่โหนดที่ใกล้เคียงจะทำหน้าที่เป็นแนวป้องกันแรกและกระจายความรุนแรงของการโจมตีออกไปอย่างมีนัยสำคัญ แม้ในกรณีของการส่งคำขอ (Request) ที่เป็นอันตรายต่อเนื้อหาแบบไดนามิก ระบบการจัดตารางเวลาอัจฉริยะของ CDN จะช่วยลดแรงกดดันบนเซิร์ฟเวอร์ต้นทางเพื่อให้แน่ใจว่าระบบจะให้การทำงานได้อย่างมีเสถียรภาพ [/cmsmasters_text][cmsmasters_text shortcode_id=”523j6mjj8v” animation_delay=”0″] ความสามารถในการป้องกันการปลอมแปลง CDN มีความสามารถในการป้องกันการปลอมแปลงระดับองค์กรในรูปแบบ End-to-End สำหรับลิงค์ HTTPS และโหนดข้อมูลเพื่อให้แน่ใจถึงความปลอดภัยในการส่งข้อมูลระหว่างเซิร์ฟเวอร์ต้นทางกับไคลเอนต์ HTTPS มีการใช้งานเพื่อป้องกันการถูกแฮคจากแหล่งข้อมูลระดับกลางในขณะที่โหนดจะตรวจสอบความสอดคล้องของไฟล์ต้นทาง หากพบว่าเนื้อหาของไฟล์ต้นฉบับไม่สอดคล้องกันไฟล์จะถูกลบและสำเนาต้นฉบับจะถูกดึงออกจากแหล่งที่มาอีกครั้งก่อนที่จะถูกเผยแพร่ โซลูชันที่สมบูรณ์แบบนี้จะให้ความปลอดภัยในการส่งข้อมูลที่สูงขึ้นและรับประกันความปลอดภัยของเนื้อหาบนเซิร์ฟเวอร์ต้นทาง, ลิงค์, โหนด CDN และไคลเอนต์ การรักษาความปลอดภัยของการเข้าถึงและการตรวจสอบความถูกต้อง CDN สามารถระบุและคัดกรองผู้เข้าใช้งานได้จากการกำหนดค่า ผู้แนะนำ, ผู้ใช้งาน-เอเจนต์ และบัญชีดำที่อยู่ IP หรือรายชื่อผู้ใช้งานที่ได้รับอนุญาต ซึ่งจะช่วยให้สามารถเข้าถึงทรัพยากรได้อย่างปลอดภัย คุณยังสามารถตั้งค่าการใช้งานเข้ารหัสลับเพื่อการเข้าถึง URL เพื่อการป้องกันการใช้งานฮอตลิงค์ขั้นสูงและปกป้องทรัพยากรบนเซิร์ฟเวอร์ต้นทาง ในขณะเดียวกันฐานข้อมูล IP Reputation ถูกสร้างขึ้นเพื่อเสริมความแข็งแกร่งในการเข้าถึงที่อยู่ IP ที่อยู่ในบัญชีดำ การรักษาความปลอดภัยระดับองค์กรช่วยป้องกันการโจมตีทั่วไป ในปี 2019 Alibaba Cloud Security ตรวจพบการโจมตี Distributed Denial Of Service (DDos) บน off-premise เกือบล้านครั้ง การโจมตี DDoS ในชั้นแอปพลิเคชัน เช่น การถูกโจมตีในรูปแบบ HTTP Flood ได้กลายมาเป็นประเภทการโจมตีในรูปแบบทั่วไปเพียงแต่วิธีการโจมตีอาจมีความหลากหลายและมีความซับซ้อนมากยิ่งขึ้น ในขณะเดียวกันปัญหาที่เกี่ยวข้องกับความปลอดภัยของเว็บแอปพลิเคชันก็ยังคงมีการโจมตีอยู่เป็นจำนวนมาก ผ่านการรั่วไหลของข้อมูลซึ่งอำนวยความสะดวกให้กับนักล่าผลประโยชน์ หรือการโจมตีอื่น ๆ ความปลอดภัยของทุกอุตสาหกรรมและเว็บแอปพลิเคชันจะได้รับการทดสอบอยู่ตลอดเวลาเพื่อเพิ่มความปลอดภัยและความน่าเชื่อถือของแพลตฟอร์มเครือข่ายที่โฮสต์การรับส่งข้อมูล ดังนั้น CDN จึงทำงานอย่างต่อเนื่องเพื่อเพิ่มความสามารถด้านความปลอดภัยอย่างสูงสุด DDoS Scrubbing CDN มอบความสามารถในการป้องกัน DDoS ในชั้นแอปพลิเคชันให้กับองค์กร (ความสามารถในการป้องกันการโจมตีด้วย HTTP ในรูปแบบ Flood) บนโหนด ความสามารถนี้จะสามารถตรวจสอบที่อยู่ IP, เฮดเดอร์และพารามิเตอร์ URL, รวบรวมสถิติเกี่ยวกับเหตุการณ์ที่เกิดขึ้น, รหัสสถานะและวิธีการส่งคำขอ, และสกัดกั้นคำขอการเข้าถึงที่เป็นอันตราย ในที่นี้ CDN สามารถตรวจสอบได้อย่างมีประสิทธิภาพว่าการเข้าถึงสำหรับธุรกิจนั้นจะสามารถเข้าถึงได้ตามปกติและจะไม่ได้รับผลกระทบ เพื่อป้องกันการโจมตี DDoS ในชั้นเน็ตเวิร์ค CDN สามารถเชื่อมโยงกับผลิตภัณฑ์ Anti-DDoS ในสถานการณ์การกระจายสามารถใช้ CDN สำหรับการกระจายได้ และเมื่อเกิดการโจมตี DDoS  พื้นที่เป้าหมายที่ถูกโจมตีจะถูกตรวจพบและจะทำการโจมตีต่อการเข้าถึงที่วิ่งเข้ามาใน Anti-DDoS Scrubbing Center เพื่อปกป้องเซิร์ฟเวอร์ต้นทางไว้อย่างมีประสิทธิภาพ โซลูชันการเชื่อมโยงนี้สามารถขัดการจราจรDDoSปริมาณสูงได้อย่างมีประสิทธิภาพและป้องกันการโจมตีแบบน้ำท่วมเช่นSyn,ACK, ICMP, UDP, NTP, SSDP, DNSและHTTP ขึ้นอยู่กับความสามารถในการประมวลผลและอัลกอริทึมการเรียนรู้ลึกของแพลตฟอร์มalibaba Cloud apsaraการคาดการณ์การโจมตีDDoSอัจฉริยะถูกนำมาใช้เพื่อสลับการจราจรไปยังโปรต่อต้านDDoSได้อย่างราบรื่นโดยไม่มีผลต่อเวิร์กโฟลว์ทางธุรกิจในชีวิตประจำวัน โซลูชันการเชื่อมโยงนี้สามารถจัดการรับส่งข้อมูล DDoS ที่มีปริมาณมากได้อย่างมีประสิทธิภาพและป้องกันการโจมตีรูปแบบ Flood เช่น SYN, ACK, ICMP, UDP, NTP, SSDP,

admin mfec

admin mfec

เปิดตัวซูเปอร์เน็ตเวิร์คของอาลีบาบาผู้อยู่เบื้องหลัง Double 11, 2019

ในปี 2019 เทศกาลช้อปปิ้งระดับโลกประจำปีหรือที่เรียกว่า Double11 ได้ถูกเรคคอร์ด Gross Merchandise Volume (GMV) เป็นจำนวนกว่า 268.4 พันล้าน RMB ซึ่งนอกเหนือจากผู้บริโภคในประเทศแล้ว Double 11 ยังดึงดูดผู้บริโภคในต่างประเทศจำนวนมากซึ่งทำให้เป็นเทศกาลช้อปปิ้งระดับโลกอย่างแท้จริง ในปีนี้กลุ่มของประเทศผู้ใช้งาน Double11 สูงสุดทั้ง 10 อันดับประเทศในภูมิภาคที่อยู่นอกเขตประเทศจีนแผ่นดินใหญ่ตาม GMV ได้แก่ ฮ่องกง (จีน), ไต้หวัน (จีน), สหรัฐอเมริกา, ออสเตรเลีย, สิงคโปร์, ญี่ปุ่น, มาเลเซีย, สหราชอาณาจักร, มาเก๊า (จีน) และแคนาดา ด้วยฐานผู้ใช้งานทั่วโลกที่มีขนาดใหญ่เช่นนี้จึงเป็นสิ่งที่ท้าทายทางด้านเทคโนโลยีเพื่อให้แน่ใจว่าผู้ใช้งานจะได้รับประสบการณ์การช็อปปิ้งอย่างราบรื่น และในเหตุการณ์ล่าสุดของ Double 11 ปรากฏว่าอาลีบาบาสามารถกล่าวถึงความท้าทายนี้ได้อย่างสมบูรณ์แบบ ขั้นตอนที่1) สร้างเครือข่ายทั่วโลก  อาลีบาบา กรุ๊ป ได้มีการปรับใช้กลุ่มคลาวด์ส่วนตัวเสมือนจริง(VPCs) สำหรับอาลีบาบาคลาวด์ในหลาย ๆ ภูมิภาค รวมทั้ง Zhangjiakou, เซี่ยงไฮ้, เซินเจิ้น, ฮ่องกง, สิงคโปร์ และสหรัฐอเมริกา โดยใช้ที่อยู่IPแบบยืดหยุ่น (EIP)ในเครือข่าย BGP แบบ multi-lined ซึ่งช่วยให้ผู้ใช้งานสามารถเชื่อมต่อกับเครือข่ายได้อย่างรวดเร็วในบริเวณใกล้เคียง กล่าวอีกนัยหนึ่งการปรับใช้งาน EIP บนอาลีบาบาในหลาย ๆ ภูมิภาคจะช่วยผลักดันเครือข่ายให้อยู่ใกล้กับผู้ใช้งานเพื่อการบริการเครือข่ายที่ครอบคลุมทั่วโลก นอกจากนี้ เครือข่ายคลาวด์สำหรับองค์กร  (CEN) ของอาลีบาบาคลาวด์ สามารถให้อาลีบาบา กรุ๊ป เชื่อมต่อเครือข่ายในภูมิภาคต่างๆ ผ่านการเชื่อมต่อระหว่างกันที่มีประสิทธิภาพสูงโดยเฉพาะเพื่อสร้างเครือข่ายองค์กรส่วนตัวทั่วโลก ด้วย EIP และ CEN อาลีบาบาสามารถสร้างเครือข่ายสำหรับองค์กรทั่วโลกที่มีประสิทธิภาพสูง,ปลอดภัย,และมีความสอดคล้องของการทำงานได้อย่างรวดเร็ว เครือข่ายองค์กรทั่วโลกนี้จะช่วยให้ผู้ใช้งานสามารถเชื่อมต่อเครือข่ายได้จากสถานที่ที่ใกล้เคียงกับแหล่งที่อยู่ของพวกเขาผ่านทางอินเทอร์เน็ต   การเชื่อมต่อทางกายภาพของ CEN และ เซิร์ฟเวอร์หลักและฐานข้อมูลของระบบ เครือข่ายสำหรับองค์กรจะมอบการทำงานที่ให้ความหน่วงที่ต่ำพร้อมทั้งให้การเชื่อมต่อที่มีคุณภาพสูงในรูปแบบเรียลไทม์ ขั้นตอนที่2) สร้างศูนย์ข้อมูลเสมือนในรูปแบบ Hyperscale บนระบบคลาวด์ เพื่อจัดการกับคำขอและการเข้าถึงอย่างพร้อมกันในช่วง Double11 อาลีบาบาจำเป็นต้องปรับใช้ทรัพยากรคอมพิวเตอร์ที่มีประสิทธิภาพนอกเหนือจากเครือข่ายระดับโลกระดับ Tbps หากคุณต้องการใช้ศูนย์ข้อมูลรูปแบบดั้งเดิมเพื่อตอบสนองความต้องการดังกล่าว คุณจะต้องจัดหาเซิร์ฟเวอร์ทางกายภาพเป็นจำนวนมากมาติดตั้งวางไว้บนชั้นวาง เปิดเครื่อง และกำหนดค่าทีละตัว และอาจใช้ระยะเวลาในการปรับใช้งานเป็นเวลาหลายเดือน  ด้วย VPC อาลีบาบาสามารถที่จะสร้างสภาพแวดล้อมของเครือข่ายแยกสำหรับผู้ใช้งานอาลีบาบาคลาวด์และสามารถปรับใช้งานหน่วยประมวลผลแบบยืดหยุ่น (ECS) เป็นจำนวนนับหมื่นอินสแตนซ์ สำหรับผู้ใช้งาน VPCs  ภายในระยะเวลาไม่ถึง 1 ชั่วโมง ในช่วงเทศกาลช้อปปิ้ง Double11 อาลีบาบา กรุ๊ป ได้ใช้งาน VPCs หลายอัตราในหลายๆ ภูมิภาค โดยมี VPC ที่ใหญ่ที่สุดทำหน้าที่สนับสนุนอินสแตนซ์ ECS เป็นจำนวนนับล้านรวมไปถึงกลุ่มคอนเทนเนอร์ VPC ขนาดใหญ่ทำหน้าที่เป็นสมองในการประมวลผลปริมาณงานของเทศกาล Double 11ได้อย่างน่าทึ่ง การดำเนินการทั้ง 2 ขั้นตอนก่อนหน้านี้ อาลีบาบาได้สร้างโครงสร้างพื้นฐานที่สามารถให้การสนับสนุนการเข้าถึงและการใช้งานได้อย่างมหาศาลในเทศกาล Double11 และตอนนี้จะขอนำทุกท่านเข้าสู่เทคโนโลยีเฉพาะและรายละเอียดของผลิตภัณฑ์ ที่อยู่ IP แบบยืดหยึ่ย (EIP)  บริการ EIP ในระบบคลาวด์ มีที่อยู่ IP สาธารณะและแบนด์วิทด์เครือข่ายสาธารณะ อาลีบาบาคลาวด์ใช้ multi-line BGP แบนด์วิทด์ เป็นเครือข่ายสาธารณะสำหรับค่าเริ่มต้น Multi-line BGP แบนด์วิทด์หมายถึงการเชื่อมต่อแบนด์วิทด์ที่อาลีบาบาคลาวด์ได้รับจากหลายผู้ให้บริการโดยตรง ผู้ให้บริการแต่ละรายถือเป็นการเชื่อมต่อทางกายภาพ โดยที่อยู่ IP

admin mfec

admin mfec

Alibaba Cloud ผู้เชี่ยวชาญด้าน Cloud Technology

หากคุณกำลังวางแผนที่จะสร้างสถาปัตยกรรมในรูปแบบ multi-Cloud หรือพิจารณาใช้บริการ Alibaba Cloud บทความนี้จะช่วยให้ลูกค้าเข้าใจผลิตภัณฑ์และบริการของ Alibaba Cloud ได้ดียิ่งขึ้น ในบทความเปรียบเทียบนี้มีความมุ่งมั่นในการช่วยให้ผู้เชี่ยวชาญด้านไอที เช่น วิศวกร, สถาปนิก, ผู้ที่คุ้นเคยกับผลิตภัณฑ์และบริการจากผู้ให้บริการระบบคลาวด์รายอื่นๆ เพื่อให้สามารถประเมินความแตกต่างของข้อเสนอบนระบบคลาวด์ของอาลีบาบา และเพื่อให้เข้าใจในบริการระบบคลาวด์ของอาลีบาบามากยิ่งขึ้น โดยเปรียบเทียบระหว่าง Alibaba Cloud กับ Amazon Web Services (AWS) ในแง่ของข้อเสนอผลิตภัณฑ์ คุณลักษณะและสถาปัตยกรรมโซลูชัน ในปัจจุบันการประมวลผล การเก็บข้อมูล เครือข่ายการจัดส่งเนื้อหา (CDN) และผลิตภัณฑ์การรักษาความปลอดภัย ก็มีให้บริการผ่านผู้ให้บริการทั้งสองรายนี้ ด้วยบทความการเปรียบเทียบนี้เราหวังว่าจะเปิดเผยความคล้ายคลึงกันและความแตกต่างระหว่างแพลตฟอร์มคลาวด์ ทั้งสองแพลตฟอร์มเกี่ยวกับแนวคิด คำศัพท์และการใช้งานจริง การเปรียบเทียบการบริการระหว่าง Alibaba Cloudและ AWSตารางต่อไปนี้จะแสดงให้เห็นถึงแผนที่การเปรียบเทียบการให้บริการแบบตัวต่อตัวระหว่าง AWS และ Alibaba Cloud (International Portal) Compute Description AWS Alibaba Cloud Virtual Servers Elastic Compute Cloud (EC2) Elastic Compute Service (ECS) GPU Servers EC2 Elastic GPUs Elastic GPU Service (EGS) Auto Scale Auto Scaling Auto Scaling Container Management Elastic Container Service (ECS) Container Service Storage & CDN Description AWS Alibaba Cloud Object Storage Amazon Simple Storage Services (S3) Object Storage Service (OSS) NoSQL Database DynamoDB ,SimpleDB Table Store Content Delivery CloudFront Alibaba Cloud CDN Shared File Storage Elastic File System (EFS) Network Attached Storage (NAS) Networking Description AWS Alibaba Cloud Networking Virtual Private Cloud (VPC) Virtual Private Cloud (VPC) Dedicated Network Direct Connect Express Connect NAT Gateway NAT Gateway NAT Gateway Load Balancing Elastic Load Balancing

admin mfec

admin mfec

Pull Backup ทางรอดภัย Ransomware

การวางระบบที่มีความสำคัญมากๆ มักมาพร้อมกับการวางแผนสำรองข้อมูลเป็นเรื่องปกติ แต่แผนสำรองข้อมูลส่วนมากกลับวางแผนไว้เพื่อเตรียมพร้อมกรณีฮาร์ดแวร์เสียหายเป็นหลัก เราจึงมักเห็นเซิร์ฟเวอร์แอปพลิเคชั่นต่างๆ ติดตั้งซอฟต์แวร์สำรองข้อมูลเอาไว้ เพื่อสำเนาข้อมูลไปยังที่ต่างๆ ทั้งไดร์ฟภายนอกและบริการคลาวด์ แนวทางนี้เรียกว่า push backup เป็นการส่งข้อมูลสำรองออกไปจากเครื่องหลัก ปัญหาของ push backup คือหากแอปพลิเคชั่นเซิร์ฟเวอร์ถูกแฮก หรือถูกโจมตีด้วยมัลแวร์ต่างๆ ในเซิร์ฟเวอร์มักมีรหัสผ่านหรือกุญแจสำหรับเข้าถึงเซิร์ฟเวอร์และสตอเรจต่างๆ ที่ใช้เก็บข้อมูลสำรองไปด้วย ในยุค ransomware เช่นทุกวันนี้ ตัวมัลแวร์เริ่มมีความสามารถมากขึ้นรวมถึงบางครั้งมีการทำงานร่วมกับแฮกเกอร์ที่สั่งการโดยตรง (human operated ransomware) ทำให้การทำ push backup ยังเหลือความเสี่ยงอยู่พอสมควร อีกแนวทางหนึ่งคือการทำ pull backup ที่ซอฟต์แวร์สำรองข้อมูลไปติดตั้งอยู่บนเครื่องเก็บข้อมูลสำรอง จากนั้นสร้าง user บนแอปพลิเคชั่นเซิร์ฟเวอร์เพื่อให้ซอฟต์แวร์สำรองข้อมูลสามารถเข้ามากวาดข้อมูลออกไปได้ แนวทางนี้มีข้อดีคือเราสามารถจำกัดสิทธิ์ของ user สำหรับสำรองข้อมูลให้เข้าถึงข้อมูลบนแอปพลิเคชั่นเซิร์ฟเวอร์ได้อย่างจำกัด เช่น สามารถอ่านได้อย่างเดียว ทำให้แม้เซิร์ฟเวอร์สำรองข้อมูลอาจจะถูกแฮก คนร้ายก็ไม่สามารถทำลายข้อมูลในแอปพลิเคชั่นเซิร์ฟเวอร์ได้ ซอฟต์แวร์สำรองข้อมูลจำนวนมากมีทั้งโหมด push และ pull สำหรับลินุกซ์ ผู้ดูแลระบบสามารถเขียนสคริปต์โดยใช้ rsync รวมกับ OpenSSH ได้ คำสั่งจะอยู่ในรูปแบบ rsync -avz backupagent@appserver:/localbackups/ /remotebackups/ จะเป็นการดึงข้อมูลจากแอปพลิเคชั่นเซิร์ฟเวอร์ ในโฟลเดอร์ `/localbackups` มายังเซิร์ฟเวอร์สำรองข้อมูล การออกแบบระบบสำรองข้อมูลมีความสำคัญ การออกแบบที่ดีลดความเสี่ยงกรณีต่างๆ ไปได้มาก นอกจากนั้นแล้วผู้ดูแลระบบควรพิจารณาซักซ้อมกู้คืนระบบเป็นระยะ รวมถึงอาจสำรองข้อมูลในสตอเรจที่แยกออกไปต่างหากไม่เชื่อมต่อกับเน็ตเวิร์คไว้อีกชั้น – – – โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาล Chief Technology Officer, MFEC

admin mfec

admin mfec

Kubernetes ตลาดที่ยังไปได้อีกไกล

ปี 2020 หากไม่เกิด COVID เสียก่อน เราอาจจะได้เห็นธีมเทคโนโลยีของปีนี้ว่าเป็นปีแห่ง Kubernetes ของโลกองค์กร ความนิยมในเทคโนโลยี Kubernetes ที่องค์กรจำนวนมากมองว่าเป็นโอกาสที่จะรวมแพลตฟอร์มที่กระจัดกระจายเข้าเป็นแพลตฟอร์มมาตรฐาน แม้จะใช้ Kubernetes หลากหลายยี่ห้อก็มีโอกาสจัดการได้ด้วยเครื่องมือชุดเดียวกัน ผู้เล่นรายใหญ่อย่าง IBM ซื้อ Red Hat แทบจะเรียกได้ว่าซื้อ OpenShift แถม Linux เพราะสิ่งที่ IBM น่าจะมองเห็นจริงๆ คือโลกองค์กรทั้งหมดในอนาคตจะย้ายโหลดงานขึ้นไปอยู่บน Kubernetes แทบทั้งสิ้น การใช้ Kubernetes ทำให้การสร้าง deploy แอปพลิเคชั่นไม่ว่าจะเป็น on-premise หรือคลาวด์ใดๆ สามารถใช้คอนฟิกชุดเดียวกันได้เสมอ ปีนี้ VMware กำลังลงมาเล่นตลาดนี้เต็มตัวด้วย Tanzu บริษัทซอฟต์แวร์สำหรับองค์กรรายใหญ่ล้วนกำลังก้าวไปยัง Kubernetes ทั้งสิ้น Elasticsearch นั้นรองรับ Elastic Cloud ตั้งแต่ปีที่แล้ว ผมเองได้ลองใช้งานแล้วก็ต้องยอมรับว่าสะดวกกว่าเซ็ตอัพเองมาก แม้กระบวนการอัพเกรดซอฟต์แวร์ที่ลองแล้วยังมีปัญหาอัพเกรดแล้วค้างไปกลางทาง คำถามคือในโลกองค์กรที่เราเห็นเริ่มใช้ Kubernetes กันเรื่อยๆ แล้วยังมีตลาดอีกมากแค่ไหน โพลล์ของ Red Hat แสดงให้เห็นโลกความเป็นจริงว่าตลาด Kubenetes เกิดการแบ่งฝั่ง ระหว่างกลุ่มผู้ใช้และกลุ่มที่ยังไม่ใช้ โลกของสตาร์ตอัพหรือองค์กรที่มีความพร้อมสูงอาจจะสามารถย้ายโหลดงานทั้งหมดขึ้นไปยัง Kubernetes ได้อย่างรวดเร็ว โดยเฉพาะองค์กรที่ย้ายโหลดไปเป็นคอนเทนเนอร์มาก่อนหน้านี้แล้ว อีกด้านองค์กรที่ยังตามไปไม่ทัน โหลดงานแทบทั้งหมดยังเป็น Virtual Machine (หรือแม้แต่เซิร์ฟเวอร์จริงๆ!) องค์กรเหล่านี้อาจจะไม่พร้อมแม้กระทั่งการย้ายโหลดงานขึ้นคลาวด์หรือการแปลงโหลดงานเป็นคอนเทนเนอร์ ยังคงเป็นตลาดที่ Kubernetes สามารถขยายตัวเข้าไปได้อีกมาก กระแสตอนนี้ค่อนข้างชัดเจนว่า Kubernetes กำลังจะกลายเป็นระบบจัดการโหลดไม่ว่าจะเป็นคอนเทนเนอร์หรือ VM ก็ตามจากการที่ OpenShift รองรับ VM เมื่อต้นปีที่ผ่านมา ความเป็นไปได้คือองค์กรที่โหลดยังเป็น VM อยู่บางองค์กร อาจจะย้ายแอปของตัวเองเข้า Kubernetes ไปเลยทีเดียว โดยใช้แนวทางว่าส่วนไหนทำเป็นคอนเทนเนอร์ได้ก็ทำ ส่วนไหนทำไม่ได้ก็ย้ายเข้า Kubernetes ไปทั้ง VM เลยทีเดียว – – – โดยวสันต์ ลิ่วลมไพศาล Chief Technology Officer, MFEC

admin mfec

admin mfec

On-Premise Cloud คลื่นลูกใหม่ที่กำลังเป็นความท้าทายของธุรกิจ SI

นาทีนี้หากจะมีองค์กรใดวางระบบไอที หากเป็นไปได้องค์กรเหล่านั้นมักวางระบบบนคลาวด์แทบทั้งหมด ด้วยเหตุผลสำคัญจากการลดระยะเวลาการพัฒนาบริการใหม่ๆ ที่องค์กรไม่ต้องเสียเวลาจัดซื้อเซิร์ฟเวอร์, วางโครงสร้างเน็ตเวิร์ค และการประเมินความเสี่ยงในระยะยาวอื่นๆ ที่ผ่านมาบริการคลาวด์เหล่านี้กระทบรายผู้ให้บริการวางระบบไอทีไปไม่น้อย จากเดิมที่องค์กรต่างๆ มักต้องวางระบบไอทีด้วยตัวเอง มีการจัดซื้อฮาร์ดแวร์และซอฟต์แวร์จำนวนมาก มาเป็นการซื้อสร้างเซิร์ฟเวอร์ทีละน้อยๆ และขยายตามโหลดที่จำเป็นต่อการใช้งานได้ทันที การวางระบบขนาดใหญ่ๆ เพื่อรองรับการใช้งานทีละ 3-5 ปีข้างหน้าจึงหายไปในกลุ่มองค์กรที่ใช้งานคลาวด์ไปแล้ว Naver Cloud Platform คลาวด์จากเกาหลีใต้ที่ประกาศว่าจะเข้าไทย ก็ประกาศให้บริการ On-Premise Cloud แล้ว อีกจุดสำคัญของธุรกิจคลาวด์คือการทำให้สินค้าสำหรับองค์กรกลายเป็นสินค้าสำหรับผู้บริโภคทั่วไปได้อย่างน่าทึ่ง กระบวนการ “ทำราคา” ที่ออกแบบราคาสำหรับลูกค้าแต่ละรายตามขนาดการสั่งซื้อกลายเป็นการนำเสนอราคาอย่างเปิดเผย ทุกวันนี้เราสามารถดูราคาของเซิร์ฟเวอร์ใน AWS, Azure, หรือ Google Cloud ได้ทั้งหมด ไม่ว่าจะเป็นเครื่องเริ่มต้นเดือนละร้อยกว่าบาท หรือเครื่องขนาดใหญ่เดือนละหลายแสนบาทก็ตามที การเปิดเผยราคาเช่นนี้ทำให้ผู้ให้บริการคลาวด์ทุกรายต้องทำราคาแข่งกันอย่างหนัก เมื่อผู้ให้บริการรายหนึ่งประกาศปรับราคาสินค้าตัวใดลง รายอื่นๆ ก็มักจะประกาศปรับราคาให้เท่าๆ กันภายในไม่กี่วัน ไม่นับว่าบริการเหล่านี้พยายามทำตลาดอย่างหนักด้วยการให้โควต้าใช้งานฟรีจำนวนมาก การแข่งขันกันเช่นนี้บีบให้ส่วนแบ่งของตัวแทนจำหน่ายบริการคลาวด์ทุกรายต่ำกว่าการขายสินค้า On-Premise เดิมๆ ไม่ว่าจะเป็นเซิร์ฟเวอร์, สตอเรจ, หรือระบบเน็ตเวิร์คอื่นๆ แต่องค์กรจำนวนมากก็ยังคงต้องรักษาระบบในองค์กรเอาไว้จากความจำเป็นด้านความปลอดภัย, กฎหมาย, หรือเงื่อนไขอื่นๆ ทำให้ที่ผ่านมาธุรกิจ SI ยังคงสามารถทำกำไรจากลูกค้ากลุ่มนี้ได้ แต่ในช่วงปีที่ผ่านมา ผู้ให้บริการคลาวด์หลายรายเปิดบริการคลาวด์แบบติดตั้งในศูนย์ข้อมูลขององค์กรกันมากขึ้นเรื่อยๆ โดยอาศัยชื่อเสียงและความเชี่ยวชาญที่สร้างจากการให้บริการคลาวด์ขนาดใหญ่ ออกแบบระบบขนาดเล็กลงโดยอาจจะเหลือเพียงตู้เซิร์ฟเวอร์เดียว แล้วนำไปติดตั้งในศูนย์ข้อมูลขององค์กร ที่เข้ามาทำตลาดในไทยก่อนเพื่อน เช่น Cloud@Customer ของ Oracle และตอนนี้ก็ยังมี AWS Outpost เพิ่มเริ่มเข้ามาทำตลาดในไทย แนวทางที่โลกระบบไอทีองค์กรอาจจะไม่เคยเห็นนัก คือการเปิดเผยราคาบนเว็บ แม้แต่เซิร์ฟเวอร์ตู้ละ 50 ล้านบาท คลาวด์ในองค์กรลดข้อได้เปรียบสำคัญของคลาวด์คือการเริ่มจากระบบขนาดเล็กๆ ไป การติดตั้งคลาวด์ในองค์กรทำให้มองค์กรมีภาระผูกพันว่าต้องใช้งานตามขนาดเครื่องที่ซื้อมา เช่น AWS Outpost นั้นเริ่มต้นที่ราคาประมาณ 8 ล้านบาท ขึ้นไปจนถึง 50 ล้านบาท แม้จะมีทางเลือกให้จ่ายรายเดือนได้ตลอดระยะเวลาสามปี แต่ทั้งหมดแล้วองค์กรก็ยังคงมีภาระผูกพันในการจ่ายค่าเซิร์ฟเวอรตามขนาดที่เลือกมาแล้วอยู่ดี ไม่สามารถลดขนาดได้แม้โหลดจะต่ำลงก็ตาม อย่างไรก็ดีองค์กรจำนวนมากกลับให้ความสนใจกับ On-Premise Cloud เหล่านี้ด้วยชื่อเสียงของผู้ให้บริการคลาวด์ที่สามารถรักษาเสถียรภาพของบริการได้ค่อนข้างดี อีกทั้งการใช้ On Premise Cloud เหล่านี้ยังสามารถเข้าถึงซอฟต์แวร์และบริการบางตัวแบบจ่ายเงินตามการใช้งานจริง เช่น บริการระบบฐานข้อมูลสำเร็จรูป RDS, หรือบริการ Kubernetes ทำให้แม้องค์กรจะเสียเงินค่าฮาร์ดแวร์เป็นก้อนใหญ่ แต่ค่าซอฟต์แวร์เฉพาะก็ยังจ่ายเงินตามการใช้งานจริงต่อไป ตัวอย่างเช่น Amazon EKS นั้นคิดค่าบริการ 0.1 ดอลลาร์ต่อคลัสเตอร์ต่อชั่วโมง โดยไม่ต้องซื้อไลเซนส์ราคาแพงล่วงหน้า หรือ Amazon RDS เองก็คิดค่าบริการตามขนาดเซิร์ฟเวอร์ฐานข้อมูล โดยไม่ต้องมีสัญญาการใช้งานซอฟต์แวร์ขั้นต่ำ ธุรกิจ SI กำลังพบความท้าทายจากผู้ให้บริการรายใหญ่เหล่านี้ หากทุกอย่างเป็นไปตามที่ผู้ให้บริการคลาวด์โฆษณาไว้ เซิร์ฟเวอร์เหล่านี้จะซ่อมบำรุงตรงจากผู้ให้บริการคลาวด์รายใหญ่แทบทั้งหมด การทำกำไรจากการติดตั้งฮาร์ดแวร์และซอฟต์แวร์น่าจะทำได้ลำบากขึ้นในอนาคต แม้แต่บริการซัพพอร์ต AWS Outpost เองก็บังคับขายพร้อมกับบริการ AWS Enterprise Support ของตัวเอง ธุรกิจ SI จะอยู่เดินหน้าได้อย่างไร ในยุคที่ Cloud กำลังครอบครองทุกพื้นที่แม้แต่ในศูนย์ข้อมูลลูกค้า เช่นนี้ ความเป็นไปได้อย่างหนึ่งคือการให้บริการที่ระดับสูงขึ้นไป การ Optimize โครงสร้างพื้นฐานเพื่อให้รองรับ peak load ได้ทุกช่วงเวลาอย่างแท้จริง ขณะเดียวกันก็สามารถออกแบบระบบให้ใช้งานทรัพยากรได้เต็มที่จนอาจจะลดต้นทุน กรณี On-Premise Cloud อาจจะต้องวิเคราะห์ได้ว่า

admin mfec

admin mfec

Serverless การพัฒนาแอปพลิเคชันยุคต่อไปที่ไม่ต้องเผื่อทรัพยากรไว้ล่วงหน้า

แนวทางการวางระบบไอทีในองค์กรคงมีขั้นตอนหนึ่งคือการประเมินการใช้ทรัพยากรของแอปพลิเคชันใหม่ที่เรากำลังติดตั้งว่าต้องใช้ซีพียู แรม หรือเน็ตเวิร์คมากน้อยแค่ไหน ซึ่งการประเมินให้ถูกต้องเป็นเรื่องที่แทบเป็นไปไม่ได้ องค์กรต่างๆ จึงมักมีทรัพยากรเหลือๆ ไม่ได้ใช้งานจำนวนมาก หรือแอปพลิเคชันบางส่วนทำงานแค่บางช่วงเวลาก็มักถูกกันทรัพยากรเตรียมไว้ให้ โดยที่ไม่มีแอปพลิเคชันอื่นมาใช้งานได้ การใช้งานคลาวด์ช่วยให้การจัดสรรทรัพยากรทำได้สะดวกขึ้นในช่วงหลังเนื่องจากองค์กรไม่ต้องซื้อฮาร์ดแวร์มาเตรียมการไว้ล่วงหน้า แต่สั่งใช้งานเพิ่มได้ทันทีที่ต้องการ แต่กระนั้นหากแอปพลิเคชันไม่ได้ออกแบบให้เตรียมพร้อมสำหรับการขยายตามโหลดที่ใช้งานจริง องค์กรก็มักต้องเสียค่าใช้จ่ายทรัพยากรสิ้นเปลืองไปเป็นปกติแม้จะใช้คลาวด์ก็ตาม แนวทางการพัฒนาแบบ Serverless จึงเริ่มเป็นที่น่าสนใจสำหรับองค์กรขึ้นเรื่อยๆ ในช่วงหลัง โดยแนวทางนี้คือการที่โค้ดถูกเก็บไว้บนเซิร์ฟเวอร์รอที่จะรัน โดยไม่ต้องจองทรัพยากรใดๆ ล่วงหน้า หากมีเหตุการณ์ (event) ที่เกี่ยวข้องกับโค้ดนั้น เช่น การเรียกใช้งานเว็บ ตัวโค้ดจึงถูกเรียกขึ้นมา จองแรมและซีพียู และประมวลผลข้อมูลเพื่อตอบกลับ บริการคลาวด์ส่วนมากมีบริการ Serverless ให้บริการ เช่น AWS Lambda หรือ Google Cloud Run โดยบริการเหล่านี้คิดค่าใช้งานอย่างละเอียด เช่น การใช้ซีพียูและแรมเป็นวินาที แม้ว่าราคาอาจจะดูแพงหากคิดการเปิดเซิร์ฟเวอร์ตลอดเวลา แต่หากไม่มี event เรียกใช้งานโค้ดเลยก็จะแทบไม่มีค่าใช้จ่ายใดๆ ในองค์กรเอง การใช้เฟรมเวิร์ค เช่น KNative มาสร้างบริการ Serverless ภายในองค์กรเริ่มเป็นตัวเลือกที่น่าสนใจ เพราะการที่ไม่มีแอปพลิเคชันจองทรัพยากรไว้ไม่ว่าจะใช้งานหรือไม่ ทำให้องค์กรสามารถประหยัดทรัพยากรโดยรวมลงได้ อัตราการใช้งานเซิร์ฟเวอร์คุ้มค่ามากขึ้น ข้อจำกัดของ Serverless คือแอปพลิเคชันที่มีอยู่เดิมอาจจะต้องปรับแก้เยอะหรือบางกรณีอาจจะต้องพัฒนาใหม่แต่ต้น และการใช้งานหลายครั้งก็ผูกติดกับผู้ให้บริการคลาวด์อย่างแนบแน่น อาจจะทำให้การย้ายแอปพลิเคชันออกไปยังคลาวด์อื่นทำได้ยาก นับเป็นความท้าทายในการตัดสินใจแนวทางการพัฒนาต่อไป – – –โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาลChief Technology Officer, MFEC

admin mfec

admin mfec

Spear Phishing ภัยธุรกิจสร้างความเสียหายได้มากกว่าที่คิด

ภัยไซเบอร์กลายเป็นความเสี่ยงทางธุรกิจอย่างมากในช่วงหลายปีมานี้ หลายคนอาจจะคิดว่าการโจมตีไซเบอร์นั้นแฮกเกอร์ต้องสร้างโปรแกรมพิเศษมาเจาะเข้าเครือข่าย เข้าถึงข้อมูลในเซิร์ฟเวอร์ ไปจนถึงแอบดูข้อมูลทุกอย่างในเครื่องเราได้ แต่การโจมตีส่วนใหญ่แล้วมาจากการส่งเมลหลอก หรือฟิชชิ่ง (phishing) ที่ไม่จำเป็นต้องอาศัยความรู้ทางเทคนิคอะไรมากมายนัก แต่อาศัยการปรับแต่งอีเมลและสร้างเว็บให้แนบเนียน เพื่อหลอกเอาข้อมูลเท่านั้น ฟิชชิ่งสมัยก่อนนั้นมักอาศัยการส่งอีเมลหว่าน โดยปลอมตัวว่าเป็นอีเมลจากบริการยอดนิยม ไม่ว่าจะเป็นเฟซบุ๊ก, ทวิตเตอร์, อีเมลฟรี, หรือธนาคารดัง เพื่อหลอกให้ผู้ใช้ยอมใส่รหัสผ่าน และแม้แต่ OTP ที่ส่งมาทาง SMS ก็ตาม ผู้ใช้อินเทอร์เน็ตในช่วงหลายปีมานี้เริ่มปรับตัวกันมากขึ้น และผู้ใช้ก็ไม่ค่อยตกเป็นเหยื่ออีเมลฟิชชิ่งกันบ่อยนัก แต่คนร้ายก็ปรับตัวไป โดยมุ่งเป้าไปที่การส่งอีเมลปลอมอย่างเจาะจงมากยิ่งขึ้น ทำให้อีเมลหลอกมักอยู่ในรูปแบบที่น่าเชื่อถือ บางทีเป็นการพูดคุยต่อเนื่องกับบทสนทนาของตัวจริง เรียกการโจมตีแบบนี้ว่า spear phishing เปรียบกับการจับปลาแบบใช้หอกพุ่งตรงไปยังตัวปลาแทนที่จะหว่านแหไป ตัวอย่างของการโจมตี เช่น คนร้ายปลอมตัวเป็นซัพพลายเออร์ที่บริษัทซื้อสินค้าอยู่เป็นประจำ ส่งอีเมลแจ้งเรียกเก็บเงินเหมือนทุกครั้งที่ผ่านมา พร้อมกับโน้ตสั้นๆ ว่าขอเปลี่ยนหมายเลขบัญชีรับเงิน เจ้าหน้าที่ฝ่ายจัดซื้อก็อาจจะพลาดยอมโอนเงินไปยังบัญชีของคนร้ายโดยไม่รู้ตัว การปลอมตัวอาจจะใช้ข้อมูลที่หาได้โดยง่าย เช่น ชื่อของพนักงานที่ทำหน้าที่เรียกเก็บเงินแล้วสร้างอีเมลใหม่ปลอมชื่อ หรือบางครั้งอาจจะผสมกับการแฮกอีเมลพนักงานจริงแล้วใช้ส่งอีเมลหลอกเพิ่มความแนบเนียนไปอีกขั้น การโจมตีคล้ายๆ กันนี้เราอาจจะพบเรื่อยๆ เช่นการแฮกเฟซบุ๊กแล้วส่งข้อความไปยังเพื่อนของเหยื่อเพื่อขอยืมเงิน แต่การแฮกเฟซบุ๊กนั้นคนร้ายอาจจะได้เงินไปปริมาณไม่มากนัก แต่ละครั้งอาจจะหลายพันหรือหลายหมื่นบาท ในกรณี Spear Phishing กับองค์กรความเสียหายอาจจะหลายล้านบาทเลยทีเดียว การป้องกันการโจมตีเช่นนี้มีตั้งแต่มาตรการทางเทคนิค เช่น การเตือนผู้ใช้ว่ากำลังส่งข้อความหรืออีเมลหาใครอยู่ ให้แยกให้ออกอย่างชัดเจนแม้ชื่ออีเมลจะดูคล้ายกัน, ติดตั้งระบบคัดกรองและแจ้งเตือนอีเมลมุ่งร้าย ตลอดจนวางนโยบายการทำงานให้รัดกุมความเปลี่ยนแปลงบางอย่าง เช่น การเปลี่ยนเลขบัญชีจ่ายเงินออก ต้องมีการตรวจสอบข้อมูลเพิ่มเติม เป็นต้น – – –โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาลChief Technology Officer, MFEC

admin mfec

admin mfec

Tags

TDRI EIS Live On-Line Briefing

แม้กระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม (DE) ได้มีการประกาศเลื่อนกำหนดระยะเวลาบังคับใช้ของ พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคลฯ หรือ PDPA ออกไปเป็นวันที่ 1 มิถุนายน 2565 แต่ทุกภาคส่วนก็ยังต้องเตรียมความพร้อมรับมือต่อกฎหมาย ตั้งแต่ระดับบุคคลไปจนถึงภาคธุรกิจขนาดใหญ่ จำเป็นต้องมีความรู้ความเข้าใจ เพื่อนำมาปรับใช้และปรับตัวให้สอดคล้องกับพระราชบัญญัติ⠀⠀ วันที่ 20 พฤษภาคมที่ผ่านมา คุณเล้ง ศิริวัฒน์ วงศ์จารุกร (CEO, MFEC) ได้รับเกียรติจาก TDRI-EIS เข้าร่วม TDRI EIS Live On-Line Briefing พูดคุยในหัวข้อ ” Preparing for PDPA Implementation: Myths and Realities” ร่วมกับ ดร. สมเกียรติ ตั้งกิจวานิชย์ (TDRI) ดร. กิริดา ภาพิชิต (TDRI) ดร. สุนทรี ส่งเสริม (DES) คุณอนุสรา โชควณิชพงศ์ (Lotus’s) และคุณอาภาธร ราชชุมพล (SCB) เพื่อเสริมสร้างความเข้าใจและการเตรียมความพร้อมสำหรับการใช้งาน PDPA⠀⠀ การพูดคุยในครั้งนี้แสดงให้เห็นถึงข้อเท็จจริงเกี่ยวกับการปฏิบัติตาม PDPA พร้อมยกตัวอย่างกรณีศึกษาของบริษัทต่างๆ สะท้อนให้เห็นถึงแนวทางการเตรียมความพร้อม และการสร้างความเข้าใจให้กับพนักงานในแต่ละองค์กร โดยกฎหมาย PDPA อาจส่งผลกระทบและก่อให้เกิดปัญหาให้กับธุรกิจขนาดเล็กหรือธุรกิจที่ยังไม่ได้ดำเนินการอยู่บนดิจิทัล จึงควรเกิดการ Transformation องค์กรก่อนที่จะกฎหมายนี้จะมีผลบังคับใช้ เพื่อสร้างความเชื่อมั่นในการรักษาความปลอดภัยในข้อมูลส่วนบุคคลของลูกค้าที่อาจส่งผลกระทบต่อภาพลักษณ์ในการดำเนินธุรกิจ แต่ทั้งนี้ทั้งนั้นพ.ร.บ.คุ้มครองข้อมูลส่วนบุคคลฯ หรือ PDPA ยังมีกฎหมายย่อยอีกหลายๆ ส่วนที่รอการสรุปที่ชัดเจน ดังนั้นผู้ดำเนินธุรกิจจึงต้องคอยติดตามและศึกษาข้อมูลกฎหมายอย่างละเอียด ผลของกฎหมาย PDPA ทำให้บริษัทต่างๆ ต้องให้ความสำคัญกับการคุ้มครองความปลอดภัยข้อมูลมากยิ่งขึ้น ต้องมีการตรวจสอบความปลอดภัยเพราะไม่เช่นนั้นอาจเกิดความเสี่ยงที่บานปลายขึ้นได้

MFEC

MFEC