この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ครั้งนี้ผมจะมาเขียนบทความ 3 รูปแบบที่ใช้ในการกำหนดโครงสร้างการยืนยันตัวตนของ WorkSpaces
บทความนี้แปลมาจากบทความที่เป็นภาษาญี่ปุ่นที่ชื่อว่า WorkSpaces設計時に検討する認証に関する構成３パターン ซึ่งเจ้าของบทความนี้ก็คือ คุณ Toyosaki เป็นคนญี่ปุ่นครับ
เนื่องจากว่าบทความนี้แปลมาจากภาษาญี่ปุ่น เมื่อแปลมาเป็นภาษาไทยแล้วผมได้เรียบเรียงเนื้อหาใหม่เพื่อให้เข้าใจง่ายขึ้น ! เมื่อพร้อมแล้วเราไปดูรายละเอียดกันเลยครับ
ผม Toyosaki ครับ สบายดีกันไหมครับ?
WorkSpaces นั้นจะมีรูปแบบการออกแบบของ Directory Service หลายแบบ ซึ่งในบทความนี้ผมจะมาแนะนำการออกแบบที่เน้นไปที่การตรวจสอบสิทธิ์ทั้ง 3 รูปแบบ อย่างไรก็ตามผมคิดว่านอกจากจะใช้กับ WorkSpaces แล้ว ยังสามารถนำไปปรับใช้กับการออกแบบ Directory Service ทั่วไปได้ด้วยครับ
1: รูปแบบที่ใช้แค่การเชื่อมต่อภายใน VPC
รูปแบบที่ 1 เป็นรูปแบบที่ใช้ในกรณีที่ไม่มีความจำเป็นต้องเชื่อมต่อกับ On-premise ก็แนะนำให้ใช้การตั้งค่านี้ เป็นการยืนยันตัวตนที่เสร็จสมบูรณ์ภายใน VPC ครับ
Active Directory ที่สร้างบน EC2 มีความจำเป็นต้องใช้การกำหนดค่าที่ซ้ำซ้อน(Redundant configuration) ตามความจำเป็นของผู้ใช้งาน โดยนอกเหนือจาก Active Directory แล้ว จะเป็นการกำหนดค่าที่ซ้ำซ้อน(Redundant configuration) ระดับ AZ ใน Managed service แทน โดยแนะนำให้แบ่ง AZ และทำซ้ำ(Redundancy) โดยปรับรูปแบบให้เข้ากับ Managed service อื่นๆ
นอกจากนี้ การยืนยันตัวตนของ WorkSpaces จะทำแค่ภายใน VPC เดียวกันเท่านั้น ทำให้การยืนยันตัวตนไม่มีความจำเป็นต้องคำนึงถึงส่วนของการเชื่อมต่อระหว่าง On-premise เหมือนกับรูปแบบที่จะแนะนำหลังจากนี้
2: รูปแบบ On-premise AD＋AD Connector
รูปแบบที่ 2 คือการสร้าง AD Connector บน AWS และอ้างอิง Actice Directory ของ On-premise ในขณะที่ยืนยันตัวตน ซึ่งตัว AD Connector จะถูกทำซ้ำในระดับ AZ เพราะตัว AD Connector จะไม่แคชข้อมูลการยืนยันตัวตน ดังนั้นในกรณีที่เกิดปัญหาใน Direct Connect หรือ VPN จะไม่สามารถเข้าสู่ระบบ WorkSpaces ได้
AD Connector เป็น Directory gateway ที่สามารถใช้เพื่อเปลี่ยนเส้นทาง Directory request ไปยัง Microsoft Active Directory ของ On-premise ได้โดยไม่ต้องแคชข้อมูลใน Cloud
จำเป็นต้องตรวจสอบการรองรับการทำซ้ำของเส้นทางการเชื่อมต่อ โดยใช้ Direct Connect 2 ตัว หรือทั้ง Direct Conect และ VPN
3: รูปแบบขยาย AD DS ของ On-premise บน AWS
รูปแบบที่ 3 คือการสร้าง Active Directory ใน EC2 บน AWS และขยาย Domain service ของ Active Directory ของ On-premise ซึ่งการเพิ่ม Domain controller ใน AWS จะทำให้เมื่อเกิดปัญหาการเชื่อมต่อระหว่าง On-premise จะสามารถยืนยันตัวตนเองได้บน AWS ซึ่งผมคิดว่า Domain controller บน AWS ควรเป็นการตั้งค่าที่ซ้ำซ้อนด้วย
นอกจากนี้ อาจเป็นการดีที่เมื่อลองพิจารณาเรื่องการแยกเว็บไซต์ On-premise กับ AWS เพื่อแยกเว็บไซต์ของ Domain controller บน On-premise ของสำนักงานใหญ่ในโตเกียวและสาขาโอซาก้า ทำให้ความถี่การทำซ้ำในตอนที่เปลี่ยนฐานข้อมูล Active Directory จะลดลงและสามารถลดปริมาณข้อมูลที่ถูกส่งไปเพื่อบีบอัดข้อมูลจำลองได้
สุดท้ายนี้
ผมได้แนะนำเกี่ยวกับรูปแบบการออกแบบของ Directory Service จากมุมมองของการใช้ WorkSpaces ไปแล้ว เราจำเป็นต้องคิดถึงเรื่องต่างๆในการออกแบบโครงสร้างที่เหมาะสม เช่น เงื่อนไข ขนาดของโครงสร้างที่ใช้ และ ความเสี่ยงต่างๆ เป็นต้น
ผมหวังว่าบทความนี้จะเป็นประโยชน์ให้กับผู้อ่านได้นะครับ
แปลโดย: POP จากบริษัท Classmethod (Thailand) ครับ !
Link อ้างอิง
- WorkSpaces設計時に検討する認証に関する構成３パターン (ภาษาญี่ปุ่น)
- Planning Regional Domain Controller Placement (ภาษาอังกฤษ)
- Active Directoryに「サイト」が必要な理由 (ภาษาญี่ปุ่น)
- Active Directory Connector (ภาษาอังกฤษ)
ดูรายละเอียดเพิ่มเติมได้ที่นี่
|
สอบถามเพิ่มเติมเกี่ยวกับ AWS คลิกที่นี่
|
25
