TechTalkThai ศูนย์รวมข่าว Enterprise IT ออนไลน์แห่งแรกในประเทศไทย
ในบทความก่อนหน้านี้ (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 หลายตัวที่อยู่คนละแอปพลิเคชันกัน เช่น การล็อคอินเข้าใช้ระบบธนาคารออนไลน์หนึ่งครั้งผู้ใช้ควรสามารถตรวจสอบได้ทั้งข้อมูลเกี่ยวกับบัญชีและข้อมูลสินเชื่อ ซึ่งทั้งสองบริการนี้ต่างเป็นแอปพลิเคชันที่แยกออกจากกัน และอาจมีนโยบายด้านความมั่นคงปลอดภัยที่แตกต่างกัน เมื่อลองพิจารณาดูแล้ว หนทางที่มีประสิทธิภาพที่สุดคือระบบจะต้อง
- สามารถส่งต่อความเชื่อใจ (Trust) ข้ามแอปพลิเคชันได้
- มีกลไกที่ผู้ใช้ไม่ต้องทำการยืนยันตัวตนใหม่ทั้งหมด หรือบ่อยจนเกินไป
- มีกลไกที่แต่ละ Microservice สามารถทำความเข้าใจบริบทความมั่นคงปลอดภัยและขอบเขตของสิทธิ์ในการเข้าถึงของผู้ใช้ได้
- สามารถจัดการกับนโยบายความมั่นคงปลอดภัยที่แตกต่างกันของแต่ละ 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 แนวคิดด้านความมั่นคงปลอดภัยที่ต้องคำนึงถึงก็มีได้แก่
- สร้าง End-to-end Trust ให้กับผู้ใช้ตลอดการใช้งานระบบ
- ออกแบบ Authorization ให้เหมาะสม ไม่มากจนเกิดช่องโหว่ ไม่น้อยจนจำกัดการใช้งาน
- จัดกลุ่ม API และใช้ API Gateway บังคับใช้นโยบายความมั่นคงปลอดภัยแบบเป็นกลุ่มเพื่อความสม่ำเสมอ
- ตรวจตราระบบ เก็บ Log และวิเคราะห์เพื่อค้นหาความเสี่ยง
- เสริมความมั่นคงปลอดภัยให้กับทุกๆ เลเยอร์ของระบบ
รายละเอียดเพิ่มเติม: https://developer.ibm.com/technologies/api/articles/securing-modern-api-and-microservices-apps-2
สนใจสอบถามข้อมูลเพิ่มเติมได้ที่ตัวแทนฝ่ายขายหรือฝ่ายผลิตภัณฑ์ บริษัท อินแกรม ไมโคร (ประเทศไทย) จำกัด: TH-IBM@ingrammicro.com
