คลังเก็บป้ายกำกับ: APPLICATION_SECURITY

การรักษาความมั่นคงปลอดภัยให้กับ API ในระบบแบบ Microservices [Part 2]

ในบทความก่อนหน้านี้ (Part 1) เราได้พูดถึงการออกแบบระบบให้มีความมั่นคงปลอดภัยภายในด้วย End-to-end (E2E) Trust ซึ่งหนึ่งในวิธีที่ได้พูดถึง คือ การใช้ Security Token Service ในการออก Token ให้กับผู้ใช้ทุกครั้งที่มีการล็อคอิน (หรือ Authentication) เข้ามาในระบบ

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

โปรโตคอลสำหรับ Authentication และ Authorization

โปรโตคอลที่นิยมใช้กันมากในการจัดการกับการพิสูจน์ตัวตน (Authentication) และการกำหนดสิทธิ์ (Authorization) ในปัจจุบัน คือ OpenID Connect และ OAuth 2.0 ซึ่งเป็นโปรโตคอลที่ทำงานร่วมกับแอปพลิเคชันแบบ HTTPS-based ได้เป็นอย่างดี โดย OpenID แต่เดิมนั้นถูกพัฒนาขึ้นเพื่อจัดการกับ Authentication ส่วน OAuth นั้นถูกพัฒนาขึ้นเพื่อจัดการกับขั้นตอน Authorization และการส่งต่อความเชื่อใจ (Trust) จากผู้ใช้ไปยัง Service ในระยะยาว

และเนื่องจาก Authentication และ Authorization มักจะมาคู่กันเสมอ OpenID Connect จึงได้เพิ่มขั้นตอนในการทำ Authentication ด้วยการเชื่อมต่อกับ OAuth 2.0 เกิดเป็นโปรโตคอลที่สามารถจัดการได้ทั้งสองแง่มุมและถูกใช้แทน OpenID จนกระทั่งในปัจจุบัน OpenID Connect นั้นทำงานผ่าน HTTPS, JSON, และ JWT จึงได้รับความนิยมมากในการพัฒนาเว็บและแอปพลิเคชันสมาร์ตโฟน

นอกจาก OpenID Connect และ OAuth 2.0 แล้ว SAML ก็เป็นอีกหนึ่งทางเลือกที่ได้รับความนิยมในการจัดการกับ Authentication และ Authorization สำหรับแอปพลิเคชันเว็บภายในองค์กร ทว่าโปรโตคอลนี้ก็มีข้อจำกัดจากตัวโปรโตคอลที่ค่อนข้างเทอะทะและต้องใช้ XML และ SOAP

เมื่อ Service ต้องติดต่อกับ Service อื่นนอกแอปพลิเคชัน

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

  1. สามารถส่งต่อความเชื่อใจ (Trust) ข้ามแอปพลิเคชันได้
  2. มีกลไกที่ผู้ใช้ไม่ต้องทำการยืนยันตัวตนใหม่ทั้งหมด หรือบ่อยจนเกินไป
  3. มีกลไกที่แต่ละ Microservice สามารถทำความเข้าใจบริบทความมั่นคงปลอดภัยและขอบเขตของสิทธิ์ในการเข้าถึงของผู้ใช้ได้
  4. สามารถจัดการกับนโยบายความมั่นคงปลอดภัยที่แตกต่างกันของแต่ละ Service

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

ไปให้ไกลกว่า Authentication และ Authorization

นอกจากความสามารถในการตรวจสอบและยืนยันตัวตนที่เราได้พูดถึงไปแล้ว องค์กรยังสามารถใช้ API Gateway ในการบังคับใช้นโยบายด้านความมั่นคงปลอดภัยอื่นๆ เช่น การกำหนด Rate limit ในการเข้าถึง API, การป้องกันการโจมตีผ่าน JSON และ XML ด้วยการกำหนดโครงสร้างเอกสารที่จะส่งผลเสียต่อ API, และการเป็นช่องทางกลางสำหรับการกำหนดนโยบายความมั่นคงปลอดภัยอื่นๆ ที่องค์กรอาจต้องการให้ Service ต่างๆ มีร่วมกัน

นอกจากนี้ สิ่งที่นักพัฒนาสามารถทำเพื่อเสริมการป้องกันให้กับระบบได้ที่น่าสนใจก็ยังมีอีก 2 ประการ ได้แก่ การเก็บ Log และสถิติเพื่อวิเคราะห์หาความเสี่ยง และการกำหนด Group Policy เพื่อสร้างระดับความมั่นคงปลอดภัยที่สม่ำเสมอ

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

ส่วน Group Policy นั้นคือการจัดรวม Service หรือแอปพลิเคชันเข้าเป็นกลุ่ม และสร้างนโยบายด้านความมั่นคงปลอดภัยที่เหมาะสมกับกลุ่มนั้นๆ เช่น API ที่มีการตอบสนองเป็นข้อมูล XML ก็จะมีการรักษาความมั่นคงปลอดภัยและต้องระวังการโจมตีในลักษณะคล้ายๆ กัน ซึ่งจะช่วยให้นักพัฒนาไม่ต้องสร้างนโยบายความมั่นคงปลอดภัยใหม่ทุกครั้งสำหรับ Service แต่ละตัว ช่วยให้การรักษาความมั่นคงปลอดภัยนั้นเสมอต้นเสมอปลายสำหรับ Microservices ในระบบ อีกทั้งยังง่ายต่อการแก้ไขและดูแลรักษาด้วย

Microservices ต้องการการดูแลเป็นพิเศษ

ระบบแบบ Microservices นั้นมีการแยกแอปพลิเคชันออกเป็นส่วนประกอบต่างๆ และสื่อสารกันผ่านเครือข่าย ทำให้ต้องมีแบบแผนในการรักษาความมั่นคงปลอดภัยที่รัดกุมและมีประสิทธิภาพเพื่อให้ได้มาซึ่งความมั่นคงปลอดภัยที่เทียบเท่ากับระบบแบบ Monolithic ในบทความทั้ง 2 Parts ที่จบไปนี้ เราได้พูดถึงการนำ API Gateway เข้ามาช่วยบังคับใช้นโยบายความมั่นคงปลอดภัย และกลไกในการจัดการขั้นตอน Authentication และ Authorization ที่สามารถส่งต่อความเชื่อใจระหว่าง Service ต่างๆ ได้

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

  1. สร้าง End-to-end Trust ให้กับผู้ใช้ตลอดการใช้งานระบบ
  2. ออกแบบ Authorization ให้เหมาะสม ไม่มากจนเกิดช่องโหว่ ไม่น้อยจนจำกัดการใช้งาน
  3. จัดกลุ่ม API และใช้ API Gateway บังคับใช้นโยบายความมั่นคงปลอดภัยแบบเป็นกลุ่มเพื่อความสม่ำเสมอ
  4. ตรวจตราระบบ เก็บ Log และวิเคราะห์เพื่อค้นหาความเสี่ยง
  5. เสริมความมั่นคงปลอดภัยให้กับทุกๆ เลเยอร์ของระบบ

รายละเอียดเพิ่มเติม: https://developer.ibm.com/technologies/api/articles/securing-modern-api-and-microservices-apps-2

สนใจสอบถามข้อมูลเพิ่มเติมได้ที่ตัวแทนฝ่ายขายหรือฝ่ายผลิตภัณฑ์ บริษัท อินแกรม ไมโคร (ประเทศไทย) จำกัด: TH-IBM@ingrammicro.com

from:https://www.techtalkthai.com/secure-api-and-microservices-apps-part-2/

รวมคลิปวิดีโอ Fortinet Webinar Series EP #1 – 10 (ภาษาไทย)

สำหรับผู้ที่พลาดไม่ได้เข้าร่วม Fortinet Webinar Series ตั้งแต่ EP #1 จนถึง EP #10 ที่จัดขึ้นตั้งแต่เดือนเมษายนถึงมิถุนายนที่ผ่านมา หรือต้องการฟังบรรยายซ้ำอีกครั้ง สามารถติดตามบันทึกวิดีโอย้อนหลังทั้งหมด (ภาษาไทย) ได้ที่นี่

EP #1: Work from Home ให้ปลอดภัยจากการถูกโจมตีทางไซเบอร์

ใน Webinar นี้ ท่านจะได้รับฟังข้อมูลที่น่าสนใจดังนี้

  • ทำอย่างไรที่จะจัดการ 3 จุดเสี่ยง ได้แก่ Endpoint Protection, Access Control และ Cloud Access ให้มั่นคงปลอดภัยที่สุด
  • เราจะรักษาความต่อเนื่องของธุรกิจ (Business Continuity) ได้ด้วยการวางแผนนโยบายการทำงานจากที่บ้านผ่าน VPN ได้อย่างไร

ผู้บรรยาย: คุณวีร์ หิรัญพานิช System Engineer จาก Fortinet Thailand

EP #2: Preparing for Cybersecurity Act

ภายใน Webinar นี้ท่านจะได้พบกับเนื้อหาสรุปถึงกฎหมายด้าน Cybersecurity ของประเทศไทย และการนำเทคโนโลยีด้านความมั่นคงปลอดภัยจาก Fortinet มาประยุกต์ในการตอบรับต่อกฎหมายฉบับดังกล่าว ซึ่งจะมาร่วมกันเล่าถึงแง่มุมต่างๆ ที่เกี่ยวข้องกับตัวบทกฎหมายและเทคโนโลยีต่างๆ ที่เกี่ยวข้อง

ผู้บรรยาย: ดร.รัฐิติ์พงษ์ พุทธเจริญ Senior Manager Systems Engineering จาก Fortinet Thailand

EP #3: Preparing for Personal Data Protection Act

เนื้อหาที่น่าสนใจใน EP #3 จะครอบคลุมเกี่ยวกับเทคโนโลยีที่จะตอบโจทย์รับการคุกคามทางโซเบอร์ส่วนต่างๆ และการควบคุมข้อมูลให้เป็นไปตาม พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล ดังนี้

  • การป้องกันข้อมูลรั่วไหล (Data Loss Prevention)
  • การควบคุมการเข้าใช้งานในเครือข่ายและทรัพยากร (Access Control)
  • การควบคุมให้ข้อมูลถูกต้องอยู่เสมอ (Data Integrity)

ผู้บรรยาย: ดร.รัฐิติ์พงษ์ พุทธเจริญ Senior Manager Systems Engineering จาก Fortinet Thailand

EP #4: Proactive Advanced Endpoint Protection, Visibility and Control for Critical Assets

EP #4 นี้ท่านจะพบกับแนวทางการปกป้องอุปกรณ์ Endpoint ในรูปแบบใหม่ที่ตอบโจทย์ด้วยคุณสมบัติ 3 ประการ ได้แก่ การบริหารจัดการความปลอดภัยอุปกรณ์ปลายทางได้อย่างเรียลไทม์ ครอบคลุมการเข้าถึงทรัพยากรขององค์กรจากภายนอกองค์กรอย่างไรให้ปลอดภัย และการตอบสนองต่อภัยคุกคามแบบอัตโนมัติ ท่านจะได้รับฟัง!

  • ประโยชน์ของการรวมจุดทางปลายทางและความปลอดภัยของเครือข่าย
  • ความแตกต่างของอุปกรณ์ปลายทางและความปลอดภัยเครือข่ายที่แตกต่างกัน
  • แนวปฏิบัติที่เหมาะสมที่สุดสำหรับการเลือกและใช้งานความปลอดภัยของอุปกรณ์ปลายทาง

ผู้บรรยาย: คุณศรัณย์ ศรีแย้ม Systems Engineer จาก Fortinet Thailand

EP #5: Constructing Secure SD-WAN Architecture by Fortinet

โดยเนื้อหาที่น่าสนใจใน EP #5 จะนำเสนอโดยทีมวิศวกรจาก Fortinet Thailand ที่จะมาเจาะลึกถึงองค์ประกอบต่างๆ ในการสร้าง SD-WAN Architecture พร้อมคำแนะนำในสิ่งที่ต้องพิจารณาในการติดตั้ง ตั้งแต่ศูนย์ข้อมูลไปยังสำนักงานสาขา

ผู้บรรยาย: คุณวิทูร กันทา Systems Engineer จาก Fortinet Thailand

EP #6: Multi Cloud Security for Public, Private and SaaS

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

ผู้บรรยาย: คุณสุมิตร อ่อนแพง Systems Engineer จาก Fortinet Thailand

EP #7: Fortinet’s Management and Analytics

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

  • การตรวจจับภัยคุกคามระดับสูง (Advanced Treat Detection)
  • การตรวจประเมินและดำเนินการให้สอดคล้องกับระเบียบข้อบังคับ (Audit and Compliance)
  • การตอบสนองต่อภัยคุกคามอย่างรวดเร็ว (Rapid Response)

ผู้บรรยาย: คุณโสภณ ธนรติกุล Systems Engineer จาก Fortinet Thailand

EP #8: เตรียมความพร้อมในการป้องกันภัยไซเบอร์ขั้นสูงที่พุ่งเป้ามาที่อีเมลองค์กรได้อย่างไร

EP #8 นี้ท่านจะได้พบกับโซลูชันความปลอดภัยสำหรับอีเมลขั้นสูงเพื่อรับมือกับการโจมตีแบบขั้นสูงและรายละเอียดดังต่อนี้

  • Click Protect ที่ระบุหาเว็บไซต์ที่ถูกหลอกใช้เป็นอาวุธในการโจมตีหลังจากที่ส่งอีเมลไปแล้ว
  • Content Disarm & Reconstruction ที่ช่วยกำจัดโค้ดที่ฝังไว้เพื่อให้ส่งไฟล์ได้อย่างมั่นคงปลอดภัย
  • การระบุหาการโจมตีรูปแบบใหม่ทั้งในแบบมัลแวร์ เอกสารแนบ และเว็บไซต์
  • การวิเคราะห์การเลียนแบบเพื่อตรวจจับการปลอมแปลงและตัวบ่งชี้อื่นๆ ของการฉ้อโกงทางอีเมล

ผู้บรรยาย: วีร์ หิรัญพานิช Channel Systems Engineer จาก Fortinet Thailand

EP #9: Protect the Heart of Your Business

EP #9 จะเกี่ยวกับความคล่องตัวของ Modern Web Application Firewall ที่สามารถช่วยให้ทำงาน ได้อย่างมั่นใจ เช่น

  • ปกป้องเว็บแอปพลิเคชันให้มั่นคงปลอดภัยโดยที่ไม่ต้องชะลอกระบวนการทำงาน
  • ลดค่าใช้จ่ายในการจัดการ
  • ลดการตรวจจับที่ผิดพลาด

ผู้บรรยาย: คุณชนาธิป อิ่มทองคำ Systems Engineer จาก Fortinet Thailand

EP #10: Build the Advanced SOC

EP #10 นี้ท่านจะได้พบกับโซลูชันการป้องกันของ Fortinet ที่ใช้ AI ในหลากหลายรูปแบบและหลากหลายช่องทางในระบบเครือข่าย เพื่อให้เกิดประโยชน์ที่เอื้อต่อกันได้อย่างครอบคลุม, การนำข้อมูล Global Threat Intelligence จากศูนย์วิเคราะห์ภัยคุกคามทั่วโลกของ FortiGuard Labs มาใช้เพื่อควบคุมความมั่นคงปลอดภัยให้ทั่วทั้งองค์กร, การทำ Centralized Advanced Threat Detection รวมถึง Advanced Analytics เพื่อสร้างศูนย์ปฏิบัติการด้านความมั่นคงปลอดภัยไซเบอร์ (SOC) ที่ชาญฉลาด ช่วยให้องค์กรสามารถป้องกันแบบเชิงรุกต่อภัยคุกคามที่ล้าหน้านี้ได้อย่างทันท่วงที

ผู้บรรยาย: คุณภีมะ เอกโพธิ์ Systems Engineer จาก Fortinet Thailand

กด Subscribe เพื่อติดตาม YouTube Channel ของ Fortinet Thailand User Group ได้ที่: https://www.youtube.com/channel/UC-oRoZgu8MPKwQeKx9w1SpA?sub_confirmation=1

from:https://www.techtalkthai.com/fortinet-webinar-series-ep-1-to-10-videos/

การรักษาความมั่นคงปลอดภัยให้กับ API ในระบบแบบ Microservices [Part 1]

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

Monolithic คืออะไร ทำไมถึงกลายเป็น Microservices?

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

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

Microservices เป็นแนวคิดที่เริ่มต้นจากการที่องค์กรขนาดใหญ่ต้องการนำ Service บางส่วนของระบบ Monolithic ออกมาแยกเป็น Service เดี่ยวเพื่อให้ระบบอื่นสามารถเข้ามาใช้ Service นี้ร่วมกันได้ในรูปแบบที่เรียกว่า Service-Oriented Architecture และต่อมาแนวคิด Microservices ก็เริ่มแพร่หลายในช่วงปี 2000 ต้นๆ จากการเข้ามาของ Web Services ซึ่งตลอดช่วงเวลาที่ผ่านมาก็มีการพัฒนาแนวคิด แนวทางปฏิบัติ และการนำแนวคิดดังกล่าวไปใช้ในการออกแบบระบบและแอปพลิเคชันมากมาย

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

ความแพร่หลายของ Microservices นี้นำไปสู่ความจำเป็นในการใช้ API ซึ่งเรียกได้ว่าเป็นช่องทางในการสื่อสารระหว่าง Service ต่างๆใ นระบบแบบ Microservices โดย API มักถูกพัฒนาขึ้นเพื่อเป็นช่องทางในการเชื่อมต่อกับฟังก์ชันของ Service ที่เปิดให้บุคคลภายนอกใช้ โดยผู้ที่เข้ามาเชื่อมต่อไม่จำเป็นจะต้องเข้าใจถึงกลไกการทำงานและความซับซ้อนที่ซ่อนอยู่ข้างใน เมื่อมี API การพัฒนาให้ Service ต่างๆ ในระบบสื่อสารกันได้ก็ย่อมสะดวกและรวดเร็วขึ้น โดยในปัจจุบัน API ที่นิยมใช้งานกันมากทื่สุดคือ RESTful API ซึ่งสื่อสารกันผ่าน HTTP และมีโครงสร้างของข้อความเป็น JSON หรือ XML

จาก API สู่ API Gateway

แน่นอนว่าการเชื่อมต่อระหว่าง Service ต่างๆ นั้นจะขาดการรักษาความมั่นคงปลอดภัยไปเสียไม่ได้ และเมื่อ API เป็นประตูเชื่อมต่อ ก็ย่อมต้องมีตัวล็อคประตูตามไป ทว่าระบบแบบ Microservices นั้นไม่เหมือน Monolithic ที่การไขกุญแจเข้าบ้านหนึ่งครั้งเท่ากับการเชื่อมต่อกับทุกอย่างในระบบ เพราะ API และ Service แต่ละตัว ก็จำเป็นจะต้องมีการรักษาความมั่นคงปลอดภัยให้กับ API ของตัวเอง ดังนั้น แปลว่าหากต้องการเชื่อมต่อกับ Service ใดผ่าน API ก็ต้องมีการพิสูจน์ตัวตน (Authentication) ด้วย

อย่างไรก็ตาม หากลองนึกภาพว่าในการจะเชื่อมต่อ Service แต่ละครั้ง นักพัฒนาต้องผ่านขั้นตอน Authentication ด้วย Credential (เช่น API Key) ที่แตกต่างกันออกไป เมื่อต้องเชื่อมต่อหลาย Service เข้า จำนวนครั้งที่ต้องยืนยันตัวและกุญแจไขประตูที่ต้องเก็บก็ยิ่งเยอะตามไปด้วย การทำเช่นนี้นั้นทั้งเสียเวลาและมีความเสี่ยงที่จะถูกขโมยกุญแจไป ในระบบสมัยใหม่จึงมีสิ่งที่เรียกว่า API Gateway เข้ามาช่วยทำหน้าที่จัดการความมั่นคงปลอดภัยและการเข้าถึง Service แต่ละตัว

จากภาพประกอบด้านล่าง นักพัฒนาอาจนำ API Gateway เข้ามาช่วยเป็นระบบรักษาความมั่นคงปลอดภัยแบบ Heavy (เช่นการล็อคอินด้วย Username และ Password) ซึ่งจะช่วยยืนยันตัวตน และส่งต่อความมั่นคงปลอดภัยแบบ Light (เช่น Access Token) ไปยัง API ของ Service ภายในระบบ การทำเช่นนี้ API Gateway ก็จะรับหน้าที่ผู้จัดการความมั่นคงปลอดภัย ช่วยให้นักพัฒนาไม่ต้องสร้างหรือเก็บ Credential สำหรับ API แต่ละตัวด้วยตัวเอง ในขณะที่ก็ยังรักษาความมั่นคงปลอดภัยของ API ของแต่ละ Service ไว้ได้อย่างแน่นหนา

โดยนอกจากประโยชน์ด้านความมั่นคงปลอดภัยแล้ว API Gateway ยังมีประโยชน์ต่อระบบ Microservices ในด้านอื่นๆ เช่น การเปิด API ให้กับ Client, การจัดการส่งต่อ Request ที่วิ่งเข้ามาจากช่องทางที่แตกต่าง (เช่น โทรศัพท์ หรือ Desktop) ให้ไปยัง Service ที่เหมาะสม, และการแปลง Protocol ในการสื่อสาร เป็นต้น

เมื่อความมั่นคงปลอดภัยไม่ได้มีแค่ 1 เลเวล

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

การสื่อสารให้ทั้งระบบรู้โดยทั่วกันว่าบริบทของความมั่นคงปลอดภัยและสิทธิ์ของผู้ใช้แต่ละรายมีมากน้อยแค่ไหนนั้นเป็นใจความสำคัญของสิ่งที่เรียกกันว่า End-to-end (E2E) Trust การสร้าง E2E Trust ขึ้นในระบบจะช่วยให้ Service แต่ละตัวรู้บทบาทของตนว่าทำได้แค่ไหน ให้ข้อมูลได้มากเท่าไหร่ และส่งต่อความเชื่อใจนี้ให้ Service อื่นใดในระบบได้บ้าง ซึ่งช่วยเสริมความมั่นคงปลอดภัยให้กับระบบ และทำให้การขโมยข้อมูลเป็นไปได้ยาก

การทำ E2E Trust ในระบบ Microservices นั้นทำได้ 2 แบบ วิธีแรกคือการใช้ Token-exchange Service เพื่อส่งต่อ Token ซึ่งเป็นตัวแทนของความเชื่อใจให้กับ Service อื่นๆ ตามลำดับ เช่นหากผู้ใช้ต้องการทำธุรกรรมหนึ่งซึ่งประกอบไปด้วยการใช้ Service A, B และ C ขั้นตอนในการทำงานก็คือระบบจะนำ Token ที่ผู้ใช้ได้จากการล็อคอิน ไปแลกเป็น Token เพื่อใช้งาน Service A และจาก Service A ไปแลกเพื่อใช้งาน Service B ตามลำดับ การแลกเปลี่ยนเช่นนี้บังคับทั้งตัวตนและแหล่งที่มาของความมั่นคงปลอดภัย

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

คำแนะนำ: ใช้ API Gateway เมื่อเป็นไปได้

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

API Gateway เป็นเทคโนโลยีที่จะช่วยบังคับใช้นโยบายความมั่นคงปลอดภัยและสร้างกลไกส่งต่อความมั่นคงปลอดภัย End-to-end Trust ให้กับระบบและการเข้าใช้ Service ต่างๆ ที่อยู่เบื้องหลัง นอกจากนี้ ยังช่วยในการจัดการการสื่อสารกับ API ทั้งจาก Request ภายนอก และการส่งต่อไปยัง Service ภายในอีกด้วย

รายละเอียดเพิ่มเติม: https://developer.ibm.com/technologies/api/articles/securing-modern-api-and-microservices-apps-1

สนใจสอบถามข้อมูลเพิ่มเติมได้ที่ตัวแทนฝ่ายขายหรือฝ่ายผลิตภัณฑ์ บริษัท อินแกรม ไมโคร (ประเทศไทย) จำกัด: TH-IBM@ingrammicro.com

from:https://www.techtalkthai.com/secure-api-and-microservices-apps-part-1/

Cisco ออกแพตช์อุดช่องโหว่ให้ WebEx Meetings แนะผู้ใช้ควรอัปเดต

มีการเปิดเผยช่องโหว่ใหม่บน Cisco WebEx Meetings Client บน Windows ซึ่งทำให้คนร้ายสามารถลอบเข้ามาขโมยข้อมูลละเอียดอ่อน หรือได้รับ Authentication Token ได้

ช่องโหว่หมายเลข CVE-2020-3347 ถูกค้นพบโดย Trustwave SpiderLabs เพราะเกิดการแชร์หน่วยความจำอย่างไม่ปลอดภัยของ WebEX Meetings Clientเพื่อใช้แลกเปลี่ยนข้อมูลกับ Windows OS หรือแอปอื่น ด้วยเหตุนี้เองคนร้ายใน Local อาจลอบเข้าถึงข้อมูลละเอียดอ่อนเช่น Authen Token, Username, Email และ URL ที่ให้ Host การประชุมได้ 

อย่างไรก็ดีช่องโหว่จะกระทบกับ WebEx Meetings บน Windows ที่คอนฟิคให้มีการล็อกอินอัตโนมัติเท่านั้น (โดย Default ส่วนใหญ่เป็นแบบนี้) ดังนั้นผู้ใช้งานควรอัปเดตเป็นเวอร์ชัน 40.6.0 โดยไว นอกจากนี้เมื่อวาน Cisco ก็เพิ่งอัปเดต Meeting Desktop บน Windows และ macOS ที่มีช่องโหว่ลอบรันโค้ดไป

ที่มา :  https://www.bleepingcomputer.com/news/security/new-cisco-webex-meetings-flaw-lets-attackers-steal-auth-tokens/

from:https://www.techtalkthai.com/cisco-patches-webex-meeting-cve-2020-3347/

[Webinar] เพิ่มความมั่นคงปลอดภัยให้กับธุรกิจและ Web Apps ด้วย F5 Advanced WAF

F5 และ Westcon Group (Thailand) ร่วมกับ G-Able ขอเชิญร่วมงาน Webinar: Secure Applications by F5 AWAF สำหรับผู้ที่ต้องการเพิ่มความมั่นคงปลอดภัยให้กับธุรกิจและ Web Apps ในวันพุธที่ 24 มิถุนายน 2020 เวลา 14:00 น. ผ่านช่องทาง F5 On24 Webinar ฟรี

รายละเอียดการบรรยาย

หัวข้อ: Secure Applications by F5 AWAF
ผู้บรรยาย: คุณ Kotchagorn Kontokornburi, Product and Solution Consultant จาก Westcon Group (Thailand)
วันเวลา: วันพุธที่ 24 มิถุนายน 2020 เวลา 14:00 – 15:00 น.
ช่องทางการบรรยาย: F5 On24 Webinar
ลิงค์ลงทะเบียน: https://event.on24.com/wcc/r/2368375/981C294A11F6250447848DC275856629?partnerref=FBbyTechtalkthai

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

หัวข้อการบรรยายประกอบด้วย

  • ภาพรวมของโซลูชัน Advanced WAF
  • ภาพรวมของโซลูชัน BOT Protection
  • การสาธิตเทคโนโลยี (Demo): การใช้งาน BOT Protection

from:https://www.techtalkthai.com/webinar-secure-applications-by-f5-awaf/

GitHub เตือนนักพัฒนา Java พบมัลแวร์พยายามกระจายตัวผ่าน NetBeans IDE

GitHub เตือนนักพัฒนา Java ให้ระมัดระวังการใช้งาน NetBeans IDE เนื่องจากพบมัลแวร์พยายามกระจายตัวผ่าน IDE โดยพบแล้วใน 26 Repositories บน GitHub

 
GitHub ได้ตั้งชื่อมัลแวร์ตัวนี้ว่า Octopus Scanner ซึ่งมัลแวร์เองมีลักษณะการทำงานเช่นเดียวกับไวรัส สามารถทำงานได้ทั้งบน Windows, Linux และ macOS เมื่อผู้ใช้งานดาวน์โหลด Project และพยายาม Compile ตัวมัลแวร์จะมีการทำงานพยายามกระจายตัวไปยังเครื่องอื่นๆในระบบเครือข่าย นอกจากนี้ยังพยายามฝังตัวลงใน Java Project ของเหยื่อที่มีการติดตั้ง NetBeans IDE อีกด้วย ซึ่งท้ายที่สุดแล้วมัลแวร์จะทำการดาวน์โหลด Remote Access Trojan (RAT) เพื่อใช้ในการสร้าง Backdoor และดึงข้อมูลออกไป ซึ่งข้อมูลที่ได้ออกไปนั้นอาจเป็นซอร์สโค้ดหรือข้อมูลความลับต่างๆของเหยื่อ
 
GitHub ได้ให้ความเห็นไว้ว่ามัลแวร์ตัวนี้อาจถูกสร้างขึ้นมาเพื่อโจมตีแบบ Targeted Attack เนื่องจาก NetBeans นั้นไม่ได้รับความนิยมในปัจจุบัน และมีการใช้งานจากผู้ใช้งานบางกลุ่มเท่านั้น อย่างไรก็ตามมัลแวร์ตัวนี้ถูกพบมานานกว่า 1 ปีแล้ว จึงอาจมีการฝังตัวใน Java Project อื่นๆอีกมาก นักพัฒนาจึงควรระมัดระวัง
 

from:https://www.techtalkthai.com/githubs-finds-malware-spread-through-netbeans-ide/

SAP ออกแพตช์ 6 ช่องโหว่ร้ายแรงประจำเดือนพฤษภาคม แนะผู้ใช้ควรอัปเดต

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

Credit:alexmillos/ShutterStock

ช่องโหว่ที่น่าสนใจมีดังนี้

  • CVE-2020-6262 (9.9/10) – ช่องโหว่ Code Injection ใน NetWeaver Application Server ABAP เวอร์ชัน 2008_1_46C, 2008_1_620, 2008_1_640, 2008_1_700 และ 2008_1_710, 740
  • CVE-2020-6242 (9.8/10) – ช่องโหว่ที่เกิดจากการขาดการพิสูจน์ตัวตนบน SAP Business Objects Business Intelligence Platform (เวอร์ชัน 1.0, 2.0 และ 2.x)
  • CVE-2020-6219 (9.1/10) – ช่องโหว่ Deserialization บน SAP Business Objects Business Intelligence Platform (อัปเดตเพิ่มของเดือนเมษายน)
  • CVE-2020-6248 (9.1/10) – ช่องโหว่ Code Injection ใน Backup Server ของ Adaptive Server Enterprise (ASE)
  • CVE-2020-6252 (9/10) – ช่องโหว่ Information Disclosure บน Adaptive Server Enterprise Cockpit
  • CVE-2020-6241 (8.8/10) – ช่องโหว่ SQL Injection บน ASE

นอกจากนี้ยังมีช่องโหว่อื่นๆ กว่า 12 รายการ ผู้สนใจสามารถติดตามเพิ่มเติมได้ที่นี่

ที่มา :  https://www.securityweek.com/saps-may-2020-security-updates-include-six-critical-patches และ  https://www.bleepingcomputer.com/news/security/sap-may-2020-security-patch-day-delivers-critical-updates/

from:https://www.techtalkthai.com/sap-patches-6-critical-vulnerabilities-for-may-2020/

ผลสำรวจชี้แอปพลิเคชันทางธุรกิจกว่า 91% ใช้งานโอเพ่นซอร์สที่ถูกทิ้งร้างและไม่อัปเดต

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

Credit: ShutterStock.com

สถิติที่น่าสนใจมีดังนี้

  • 99% ของโค้ดที่สำรวจมีส่วนประกอบของโอเพ่นซอร์สอยู่ ซึ่งเพิ่มขึ้นอย่างมีนัยสำคัญกว่าปี 2018 และคาดว่าโอเพ่นซอร์สจะได้รับความนิยมเช่นนี้เพิ่มขึ้นเรื่อยๆ ต่อไป
  • 91% ของโค้ดที่สำรวจจะมีส่วนประกอบที่หมดอายุไปมากกว่า 4 ปีหรือไม่มีความเคลื่อนไหวในการพัฒนาใน 2 ปีหลัง ซึ่งอาจนำไปสู่ปัญหาด้าน Security 
  • ส่วนประกอบของโอเพ่นซอร์สกว่า 75% มีช่องโหว่ซึ่งเพิ่มขึ้นกว่าปีก่อนหน้าที่มีแนวโน้มลดลง (2017-2018) นอกจากนี้ยังมีช่องโหว่รุนแรงสูงถึง 49% ที่เพิ่มขึ้นกว่าปีก่อนเช่นกัน
  • แม้ว่าโอเพ่นซอร์สจะฟรีแต่ก็มีเอกสิทธิ์เรื่องของสิทธิทางปัญญาเช่นกัน โดย 68% ของโค้ดที่สำรวจมีรูปแบบที่ละเมิดลิขสิทธิ์ รวมถึง 33% ยังไม่มีลิขสิทธิ์ที่ระบุได้

ผู้สนใจติดตามเพิ่มเติมได้ที่ 2020 OpenSource Security and Risk Analysis (OSSRA) 

ที่มา :  https://www.securitymagazine.com/articles/92368-synopsys-study-shows-91-of-commercial-applications-contain-outdated-or-abandoned-open-source-components และ  https://www.zdnet.com/article/out-of-date-insecure-open-source-software-is-everywhere/

from:https://www.techtalkthai.com/91-percents-of-business-app-include-obsolete-or-abandoned-opensource/

พบช่องโหว่สามารถ Hijack บัญชี Microsoft Teams ด้วยรูป GIF

ผู้เชี่ยวชาญจาก CyberArk ได้สาธิตการโจมตีเพื่อขโมยบัญชีของผู้ใช้งาน Microsoft Teams เพียงแค่หลอกให้เหยื่อเปิดลิงก์หรือภาพเคลื่อนไหว (GIF)

credit : CyberArk

วิธีการโดยภาพรวมสามารถสรุปเป็นรูปได้ตามภาพด้านบน นั่นคือการหลอกให้เหยื่อเปิดลิงก์อันตรายหรือไฟล์ .GIF เพื่อ Hijack บัญชีของเหยื่อ ทั้งนี้กระทบกับ Microsoft Teams ทั้งเวอร์ชัน Web-based และ Desktop

ไอเดียคือผู้เชี่ยวชาญได้ศึกษาและสังเกตการทำงานของ Microsoft Teams ดังนี้

1.) ทุกครั้งที่เปิดแอปตัว Client จะมีการสร้าง Temporary Access Token เพื่อใช้พิสูจน์ตัวตนกับ login.microsoft.com

2.) มีการสร้าง Token อื่นเพื่อเข้าถึงบริการสนับสนุนเช่น Sharepoint หรือ Outlook

3.) มีการสร้าง Cookies 2 ตัวเพื่อจำกัดการเข้าถึงคือ Authtoken และ Skypetoken_asm โดยตัวหลังจะถูกส่งให้ teams.microsoft.com และโดเมนย่อยภายใต้อื่นๆ ซึ่งตรงนี้เองผู้เชี่ยวชาญพบว่ามี 2 โดเมนย่อยมีช่องโหว่จากการโจมตีแบบ Subdomain takeover ดังนั้นถึงแม้ว่า authtoken ซึ่งเป็น HTTPS จะสามารถป้องกันการส่งข้อมูลไปหาคนอื่นได้ แต่ด้วยช่องโหว่ Subdomain takeover ทำให้คนร้ายสามารถผ่านข้อจำกัดตรงนี้ 

สุดท้ายแล้วกล่าวคือหากลวงให้ผู้ใช้งานเปิดลิงก์หรือรูป .GIF อันตรายได้ Browser ของผู้ใช้ก็จะยอมส่ง Authentoken Cookie (ถูกใช้เพื่อ Authen ผู้ใช้ให้สามารถโหลดรูปจาก Teams และ Skype) ไปที่เซิร์ฟเวอร์ของคนร้าย เพื่อนำไปสร้าง Skype Token จนนำไปสู่การขโมยข้อมูลบัญชีในที่สุด (ข้อมูลที่ถูกขโมยได้ รูปประกอบด้านล่าง) ผู้สนใจสามารถอ่านและชมรายละเอียดเพิ่มเติมได้จากเว็บของ CyberArk 

credit : CyberArk

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

ที่มา :  https://www.zdnet.com/article/this-is-how-viewing-a-gif-in-microsoft-teams-triggers-account-hijacking-bug/ และ  https://www.bleepingcomputer.com/news/security/microsoft-teams-patched-against-image-based-account-takeover/

from:https://www.techtalkthai.com/cyberark-found-microsoft-teams-accounts-could-hijacked-by-gif-picture/

เชิญร่วม Webinar Series: บทบาทของ DevSecOps เพื่อเร่งการส่งมอบธุรกิจอย่างมีคุณค่า

การส่งมอบธุรกิจอย่างมีคุณค่าเข้าสู่ระบบเศรษฐกิจดิจิทัล จำต้องมีกระบวนการเข้าถึงแบบ High-Speed ซึ่งมีส่วนสำคัญอย่างมากท่ามกลางวิกฤติทั่วโลกอย่างเช่นทุกวันนี้ วิธีการของ DevSecOps จะช่วยให้เรา สนับสนุนแผนงานความต่อเนื่องขององค์กร (Business Continuity) และเร่งให้เกิดผลลัพธ์ทางธุรกิจที่เด่นชัดภายในระยะเวลาอันสั้นได้ การวางแผนและการทำงานแบบ Agile Planning เช่นนี้นั้น ต้องดำเนินงานในเชิงรุกและมีคุณภาพด้วย รวมทั้งต้องมี Framework ในการกำกับดูแลที่ดีเพื่อช่วยลดความเสี่ยงที่อาจจะเกิดขึ้นจากความผันผวนของการเปลี่ยนแปลง เพื่อประกันความปลอดภัยและต้องมั่นใจด้วยว่าจะไม่มีการละเมิดนโยบายใด ๆ ขององค์กรด้วย

ในซีรี่ส์นี้ที่ประกอบด้วย Webinar 2 ส่วน คุณจะได้เรียนรู้เกี่ยวกับโซลูชันของ Micro Focus ที่จะทำให้องค์กรได้นำแนวทางปฏิบัติของ DevSecOps มาทำให้เกิดแอปพลิเคชันได้รวดเร็ว มีคุณภาพและปลอดภัย

กรอบการปฏิบัติงานเชิงรุกอย่างมีคุณภาพเพื่อการปรับปรุงอย่างต่อเนื่อง

วันอังคารที่ 28 เมษายน 2020 | 13.00 -14:00 น.

การประเมินคุณภาพ (Quality) และความปลอดภัย (Security) เชิงรุกท่ามกลางกระแสความผันผวนซึ่งเป็นปัจจัยที่มีผลต่อการปรับปรุงอย่างต่อเนื่องนั้น จะทำให้เราตรวจสอบได้อย่างถูกต้องในแต่ละขั้นของ Lifecycle Stage และช่วยให้ผู้เกี่ยวข้องทุกคนทำงานร่วมกันได้ดีขึ้น การวางแผนการปล่อย Release อย่างสม่ำเสมอและการทำงานด้วยระบบอัตโนมัติ (Automation) จะปรับปรุงและเร่งกระบวนการพัฒนาซอฟต์แวร์ให้สำเร็จเร็วขึ้นได้

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

เร่งกระบวนการพัฒนาซอฟต์แวร์ด้วยกระบวนการแบบ Shift-Left Testing

วันอังคารที่ 30 เมษายน 2563 | 13.00-14.00 น.

ในการใช้ Shift Left-Testing Strategy สำหรับการทดสอบทั้งในเชิง Functional, Performance และ Security Testing นั้น ทีมพัฒนาซอฟต์แวร์ต้องพิจารณาว่าอะไรคือสิ่งสำคัญและจำเป็นแรกสุดก่อน (Prioritize) จากนั้น จึงเลือกเครื่องมือที่จะใช้ และรู้ว่าการจะบริหารจัดการข้อมูลเขิงลึกหรือ Harness Insight ตลอดจนการขยายสิ่งที่ทำได้ดีอยู่แล้วให้ใหญ่ขึ้นได้อย่างไร

ในหัวข้อนี้ คุณจะได้เรียนรู้โซลูชันของ Micro Focus ที่มีชื่อว่า Unified Functional Testing (UFT) LoadRunner และ Fortify ที่มอบความสามารถให้แก่ Tester และ Developer ในการสร้างและรักษา test assets ทั้งหมดไว้ รวมทั้งแชร์ความรู้ และปรับปรุงคุณภาพระหว่างทีมที่ต้องทำงานร่วมกันด้วย โดยเราจะแชร์ขอเสนอเกี่ยวกับโซลูชั่นนี้เพื่อให้คุณสามารถนำไปปรับใช้กับความท้าทายที่คุณกำลังประสบอยู่ในปัจจุบันได้

DevSecOps ในความเป็นจริงแล้วเป็นอย่างไร

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

from:https://www.techtalkthai.com/micro-focus-webinar-series-devsecops/