Redis Enterprise 6.2.4 แนะนำการเข้ารหัสปล้อง ขอบเขตของการเข้ารหัสปล้องใน Redis Enterprise คือการบรรลุการเข้ารหัส TLS สำหรับการเชื่อมต่อคลัสเตอร์ Redis ภายในทั้งหมดระหว่างโหนด ซึ่งรวมถึง:
- ปรับปรุงการเชื่อมต่อระนาบควบคุมเพื่อเข้ารหัสการจำลองแบบ CCS (Cluster Configuration Store)
- การเชื่อมต่อทั้งหมดไปยังโหนดหลัก CCS จากโหนดเรพพลิกา
- การเชื่อมต่อระนาบข้อมูลเพื่อเข้ารหัสการจำลองชาร์ดระหว่างโหนด
- พร็อกซี่ทั้งหมดเพื่อเชื่อมต่อชาร์ดระหว่างโหนด
Redis Enterprise:ข้อควรพิจารณาในการออกแบบ
Redis Enterprise ใช้เทคนิคหลายอย่างเพื่อเพิ่มประสิทธิภาพและความพร้อมใช้งาน คลัสเตอร์ Redis ใช้สถาปัตยกรรมแบบไม่มีการแบ่งใช้ ซึ่งเพิ่มความน่าเชื่อถือและความพร้อมใช้งาน และทำให้เพิ่มและลบโหนดได้ง่าย เมื่อเข้าใกล้ข้อกำหนดในการเข้ารหัสการเชื่อมต่อปล้องทั้งหมด ทีมงานได้เน้นที่ความพร้อมใช้งานและความเรียบง่ายในการปฏิบัติงาน
ระบบแบบกระจายและเปิดตลอดเวลา เช่น Redis Enterprise ขับเคลื่อนแอปพลิเคชันที่สำคัญต่อภารกิจมากมาย จะต้องเป็นไปตามมาตรฐานสูงสุดของความพร้อมในการปฏิบัติงาน Redis Cloud ที่ขับเคลื่อนโดย Redis Enterprise ให้ความพร้อมใช้งาน 99.999% ซึ่งหมายความว่าสามารถล่มได้เพียงไม่กี่นาทีต่อปี การสื่อสารคลัสเตอร์ปล้องมีความสำคัญต่อการรักษาองค์ประชุม (การดำเนินการพาธควบคุม) และการเปิดใช้งานการจำลองแบบ Redis (การดำเนินการพาธข้อมูล) ดังนั้นจึงจำเป็นที่จะต้องมีความพร้อมใช้งานสูงเพื่อรักษาความน่าเชื่อถือของการสื่อสารปล้องตลอดเวลา
ผู้ออกใบรับรองส่วนตัว (CA) คืออะไร:
ผู้ออกใบรับรองส่วนตัว (CA) เป็นผู้ออกใบรับรองเฉพาะคลัสเตอร์ที่ทำงานเหมือน CA ที่สาธารณชนเชื่อถือ คลัสเตอร์ Redis สร้างใบรับรองรูทส่วนตัวซึ่งสามารถออกใบรับรองส่วนตัวอื่น ๆ สำหรับแต่ละโหนด ใบรับรองส่วนตัวที่ออกโดย CA ส่วนตัวนั้นไม่น่าเชื่อถือต่อสาธารณะ Private CA จะไม่เปิดเผยนอกคลัสเตอร์ Private CA จะไม่ถูกแชร์ระหว่างคลัสเตอร์ Redis หรือกับไคลเอ็นต์หรือบริการภายนอกใดๆ ใบรับรองที่ลงนามโดย Private CA (ใบรับรองเอนทิตีปลายทาง) มีเอกสิทธิ์เฉพาะกับโหนดที่ออกให้
Private CA ที่ใช้ใน Redis Enterprise มีกลไกการหมุนตัวเองภายในที่ราบรื่น การหมุนเวียนใบรับรองจะทำได้สำเร็จโดยอัตโนมัติก่อนหมดอายุ การหมุนเวียนใบรับรองสามารถทำได้ตามคำขอผ่าน REST API จะมีการแจ้งเตือนสำหรับการตรวจสอบโดยแอปพลิเคชัน ฐานข้อมูล และทีมรักษาความปลอดภัย Private CA จะลบการพึ่งพาความพร้อมใช้งาน CA ภายนอกสำหรับการหมุนเวียนใบรับรอง ลบจุดที่อาจเกิดความล้มเหลว และปรับปรุงความพร้อมใช้งานโดยรวมของคลัสเตอร์
Redis Enterprise ทำได้โดยใช้ผู้ออกใบรับรองส่วนตัว (CA) เพื่อจัดการใบรับรองที่จำเป็นสำหรับการเข้ารหัสปล้อง ลูกค้ามักมีข้อกังวลหลักที่เกี่ยวข้องกับการใช้ CA ส่วนตัวดังต่อไปนี้
ความกังวลของลูกค้า:
- ไม่อนุญาตให้ใช้ใบรับรองที่ลงนามเองหรือ CA ส่วนตัวในสภาพแวดล้อมของเรา
- CA ส่วนตัวไม่ได้รับการเชื่อถือแบบสาธารณะ ดังนั้นจึงไม่สามารถสร้างความเชื่อถือสำหรับการสื่อสารภายนอกได้
- หน่วยงาน CA ส่วนตัวมักไม่ได้รับการปกป้องอย่างเพียงพอต่อการประนีประนอม
ข้อกังวลแรกไม่ใช่ปัญหาด้านความปลอดภัย นี่เป็นข้อกำหนดการปฏิบัติตามข้อกำหนด หลายองค์กรได้เขียนนโยบายแบบครอบคลุมเพื่อไม่อนุญาตให้ใช้ใบรับรองที่ลงนามเองทั้งหมด โดยไม่คำนึงถึงกรณีการใช้งานที่ถูกต้อง ซึ่งใบรับรองที่ลงนามเองเป็นตัวเลือกที่ดีที่สุด ข้อกำหนดนี้สมเหตุสมผลสำหรับหลายกรณี แต่ไม่ใช่ทั้งหมด และทำให้องค์กรเดียวกันนั้นต้องการกระบวนการในเชิงลึกเพื่อให้มีการยกเว้นสำหรับอินสแตนซ์ที่ไม่เหมาะกับนโยบายแบบครอบคลุม ตัวอย่างหนึ่งคือการเข้ารหัสปล้อง Redis Enterprise ในตัวอย่างนี้ Private CA มีจุดประสงค์เฉพาะ
ขั้นแรก มากำหนดใบรับรองที่ลงนามเอง . ใบรับรองที่ลงนามด้วยตนเองคือใบรับรองที่ไม่ได้ลงนามโดย CA บุคคลที่สามที่น่าเชื่อถือต่อสาธารณะ ใบรับรองประเภทนี้สร้าง ออก และลงนามโดยองค์กรที่รับผิดชอบเว็บไซต์หรือแอปพลิเคชันที่ออกใบรับรองให้ ใบรับรองเหล่านี้ออกได้ฟรีและใช้รหัสลับเดียวกันกับใบรับรองที่ออกโดย CA บุคคลที่สามที่เชื่อถือได้
คุณอาจถามตัวเองว่า:“หากองค์กรไม่อนุญาตให้ใช้ใบรับรองที่ลงนามด้วยตนเอง ทางเลือกอื่นคืออะไร” ทางเลือกทั่วไปคือการใช้ใบรับรองที่ออกโดย CA บุคคลที่สามที่เชื่อถือได้ องค์กรสามารถซื้อใบรับรองเหล่านี้จาก CA ที่เชื่อถือได้จากบุคคลที่สามหลายราย จากนั้นออกใบรับรองไปยังเว็บไซต์หรือแอปพลิเคชันของตน ใบรับรองที่ออกโดย CA บุคคลที่สามที่เชื่อถือได้จะเหมือนกับใบรับรองที่ลงนามเอง ในแง่ของความปลอดภัย
คำถามต่อไปที่เราควรถามคือ – อะไรคือความแตกต่างระหว่างใบรับรองที่ลงนามเองกับใบรับรองที่ออกโดย CA บุคคลที่สามที่เชื่อถือได้? ใบรับรองแต่ละใบรองรับการเข้ารหัสเดียวกัน แต่ละใบประกอบด้วยใบรับรองรูท ระดับกลาง และลีฟ แต่ละรายการสามารถหมดอายุหรือเพิกถอนได้ตามต้องการ ข้อแตกต่างเพียงอย่างเดียวคือความแตกต่างในการทำงานระหว่างใบรับรองที่ลงนามเองกับใบรับรองที่ออกโดย CA บุคคลที่สามที่เชื่อถือได้ หน้าที่นั้นคือความไว้วางใจ CA บุคคลที่สามที่เชื่อถือได้สามารถออกใบรับรองที่สามารถใช้เพื่อสร้างความเชื่อถือระหว่างสองหน่วยงานที่ไม่เกี่ยวข้อง
เมื่อใดจึงจำเป็นต้องไว้วางใจ? ความเชื่อถือเป็นส่วนที่จำเป็นของโซลูชันเมื่อสองหน่วยงานที่ไม่เกี่ยวข้องกำลังสื่อสารกัน ตัวอย่างที่ดีคือการสื่อสารระหว่างเว็บเบราว์เซอร์และเว็บแอปพลิเคชัน การใช้ใบรับรองที่ออกโดย CA ที่เชื่อถือได้ของบุคคลที่สามช่วยให้สามารถสื่อสารด้วยการเข้ารหัส แต่ยังช่วยให้เว็บเบราว์เซอร์รู้ว่าเว็บแอปพลิเคชันคือตัวตนที่แท้จริงของพวกเขา ด้วยเหตุนี้ เบราว์เซอร์จะแจ้งให้ผู้ใช้ทราบหากพวกเขาเชื่อถือเว็บแอปพลิเคชันและต้องการสื่อสารต่อไป
เมื่อใดที่ไม่จำเป็นต้องไว้วางใจ ความเชื่อถือไม่ใช่ส่วนที่จำเป็นของโซลูชันเมื่อสองหน่วยงานที่เกี่ยวข้องกำลังสื่อสารกัน การเข้ารหัสปล้องของ Redis Enterprise เป็นตัวอย่างที่ดีของการสื่อสารประเภทนี้ Redis Enterprise ประกอบด้วยคลัสเตอร์เดียว และคลัสเตอร์เดียวสามารถมีได้หลายโหนด สามารถมีฐานข้อมูลเดียวหรือหลายฐานข้อมูลบนโหนดได้เช่นกัน เนื่องจากแต่ละโหนดเป็นของคลัสเตอร์เดียวกัน จึงไม่จำเป็นต้องมีบุคคลที่สามเพื่อสร้างความเชื่อถือ แต่ละโหนดเชื่อถือโหนดอื่นอยู่แล้วเนื่องจากอยู่ในคลัสเตอร์เดียวกัน
โซลูชัน Redis Enterprise:
Redis Enterprise บรรเทาข้อกังวลด้านการปฏิบัติตามข้อกำหนดและความปลอดภัยเหล่านี้ เนื่องจากใบรับรองที่สร้างโดย CA ส่วนตัวจะใช้ภายในคลัสเตอร์เท่านั้น เนื่องจากโหนดแต่ละโหนดเป็นที่รู้จักและเชื่อถือโดยโหนดอื่นๆ ทั้งหมดภายในคลัสเตอร์เดียวกัน CA ที่เชื่อถือได้ของบุคคลที่สามจึงไม่เพิ่มอะไรเลยและไม่จำเป็นต้องสร้างความเชื่อถือภายในคลัสเตอร์ Redis
