Redis Enterprise 6.2.4 ได้นำเสนอ internode encryption (การเข้ารหัสระหว่างโหนด) ขอบเขตของ internode encryption ใน Redis Enterprise คือ เพื่อให้ได้ TLS encryption สำหรับการเชื่อมต่อ Redis cluster ภายในระหว่างโหนดทั้งหมด รวมถึง:
- เพิ่มความปลอดภัย control plane connections เพื่อเข้ารหัส CCS (Cluster Configuration Store) replication
- การเชื่อมต่อทั้งหมดไปยัง primary node CCS จาก replica nodes
- Data plane connections เพื่อเข้ารหัส shard replication ระหว่างโหนด
- Proxy to shard connections ทั้งหมดระหว่างโหนด
Redis Enterprise: การพิจารณาด้านการออกแบบ (Design Considerations)
Redis Enterprise ใช้เทคนิคหลายอย่างเพื่อเพิ่มประสิทธิภาพและ availability Redis cluster ใช้ shared-nothing architecture ซึ่งเพิ่ม reliability และ availability และทำให้เพิ่มและลบโหนดง่ายขึ้น เมื่อเข้าสู่ข้อกำหนดในการเข้ารหัสการเชื่อมต่อระหว่างโหนดทั้งหมด ทีมโฟกัสที่ availability และ operational simplicity
ระบบ distributed, always-on เช่น Redis Enterprise ให้พลังกับ mission-critical applications หลายอย่าง จำเป็นต้องตอบสนองมาตรฐาน operational availability สูงสุด Redis Cloud ขับเคลื่อนโดย Redis Enterprise ให้ 99.999% availability หมายถึงมันสามารถ down ได้เพียงไม่กี่นาทีต่อปี Internode cluster communications สำคัญต่อการรักษา quorum (control path operations) และเปิดใช้งาน Redis replication (data path operation) ดังนั้น จึงเป็นสิ่งจำเป็นที่ต้องมี high availability เพื่อรักษาความน่าเชื่อถือของ internode communications ตลอดเวลา
Private Certificate Authority (CA) คืออะไร?
Private Certificate Authority (CA) คือ cluster-specific certificate authority ที่ทำงานเหมือน publicly-trusted CA Redis cluster สร้าง private root certificate ของตัวเอง ซึ่งสามารถออก private certificates ให้แต่ละโหนดได้ Private certificates ที่ออกโดย Private CA ไม่ได้ trusted publicly Private CA ไม่ได้ exposed ภายนอก cluster Private CA ไม่ได้ shared ระหว่าง Redis clusters หรือกับ external client หรือ service ใดๆ Certificates ที่ signed โดย Private CA (end-entity certificates) เป็น exclusive (เฉพาะเจาะจง) ต่อโหนดที่ออกให้
Private CA ที่ใช้ใน Redis Enterprise ให้ seamless internal self-rotation mechanism การหมุนเวียน certificate (Certificate rotation) จะทำโดยอัตโนมัติก่อนหมดอายุ การหมุนเวียน certificate ยังสามารถทำได้ عند请求 (upon request) ผ่าน REST API Alerting จะถูกให้สำหรับ monitoring โดย application, database, และ security teams Private CA กำจัด dependency บน external CA availability สำหรับ certificate rotation กำจัด potential point of failure และปรับปรุง overall availability ของ cluster
Redis Enterprise บรรลุสิ่งนี้ผ่านการใช้ Private Certificate Authority (CA) เพื่อจัดการ certificates ที่จำเป็นสำหรับ internode encryption ลูกค้ามักมี primary concerns หลักต่อไปนี้เกี่ยวกับการใช้ Private CA
Customer Concerns (ข้อกังวลของลูกค้า):
- ไม่อนุญาต self-signed certificates หรือ Private CA ใน environment ของเรา
- Private CA ไม่ได้ trusted publicly และจึงไม่สามารถสร้าง trust สำหรับ external communication ได้
- Private CA บ่อยครั้งไม่ได้ protected อย่างเพียงพอต่อการถูก compromise
ข้อกังวลข้อแรก ไม่ได้เป็น security concern จริงๆ นี่คือ compliance requirement หลายองค์กรมีนโยบายทั่วไป (blanket policies) ที่ запрещает (disallow) self-signed certificates ทั้งหมด โดยไม่พิจารณา valid use cases ที่ self-signed certificate เป็นตัวเลือกที่ดีที่สุด ข้อกำหนดนี้มีความสมเหตุสมผลในหลายกรณี แต่ไม่ใช่ทั้งหมด และทำให้องค์กรเหล่านั้นต้องมีกระบวนการลึกซึ้งเพื่อให้ exclusions (ข้อยกเว้น) ในกรณีที่ blanket policy ไม่พอดี ตัวอย่างหนึ่งคือ Redis Enterprise internode encryption ในตัวอย่างเฉพาะนี้ Private CA ทำหน้าที่เฉพาะเจาะจง
ก่อนอื่น มากำหนด self-signed certificate Self-signed certificate คือ certificate ที่ไม่ได้ถูก sign โดย publicly trusted third-party CA ประเภท certificate นี้ถูกสร้าง ออก และ sign โดยองค์กรที่รับผิดชอบ website หรือ application ที่ certificate ถูกออกให้ Certificates นี้ฟรีในการออก และใช้ ciphers เดียวกับ certificates ที่ออกโดย trusted third-party CA
คุณอาจถาม: "ถ้าองค์กรไม่อนุญาต self-signed certificates ทางเลือกคืออะไร?" ทางเลือกทั่วไปคือใช้ certificates ที่ออกโดย trusted third-party CA องค์กรสามารถซื้อ certificates จาก third parties trusted CA หลายแห่ง และออก certificates ให้ website หรือ application ของพวกเขา Certificate ที่ออกโดย trusted third-party CA เหมือน self-signed certificate ในแง่ของ security
คำถามต่อไปที่เราควรถามคือ - มีความแตกต่างอะไรบ้างระหว่าง self-signed certificate และ certificate ที่ออกโดย trusted third-party CA? แต่ละ certificate รองรับ ciphers เดียวกัน แต่ละอันประกอบด้วย root, intermediate, และ leaf certificates แต่ละอันก็สามารถ expired หรือ revoked ได้ตามต้องการ ความแตกต่างเดียวคือ functional difference ระหว่าง self-signed certificate และ certificate ที่ออกโดย trusted third-party CA ฟังก์ชันนั้นคือ trust (ความไว้วางใจ) Trusted third-party CA สามารถออก certificates ที่ใช้สร้าง trust ระหว่าง unrelated entities สอง entidad
เมื่อไหร่ Trust จำเป็น? Trust เป็นส่วนที่จำเป็นของ solution เมื่อ unrelated entities สองฝ่าย communicate ตัวอย่างดีคือ communication ระหว่าง web browser และ web application การใช้ third-party trusted CA-issued certificate อนุญาต encrypted communication แต่ยังให้ web browser รู้ว่า web application คือใครที่มันนำเสนอ ผลลัพธ์ browser จะ prompt ผู้ใช้ว่ไว้วางใจ web application และต้องการดำเนินการต่อหรือไม่
เมื่อไหร่ Trust ไม่จำเป็น? Trust ไม่ใช่ส่วนที่จำเป็นของ solution เมื่อ related entities สองฝ่าย communicate Redis Enterprise's internode encryption เป็นตัวอย่างดีของ communication ประเภทนี้ Redis Enterprise ประกอบด้วย one cluster และ single cluster สามารถมี multiple nodes ได้ สามารถมี single หรือ multiple databases บน node ได้เช่นกัน เพราะแต่ละโหนดเป็นของ cluster เดียวกัน ไม่มี third party จำเป็นต้องสร้าง trust แต่ละโหนดไว้วางใจโหนดอื่นๆ ทุกตัวแล้ว เพราะพวกเขาเป็นของ cluster เดียวกัน
Redis Enterprise Solution:
Redis Enterprise ลดความกังวล compliance และ security เหล่านี้ เพราะ Private CA-generated certificates ถูกใช้เฉพาะภายใน cluster เนื่องจากแต่ละโหนดเป็นที่รู้จักและไว้วางใจโดยโหนดอื่นๆ ทั้งหมดภายใน cluster เดียวกัน third-party trusted CA ไม่เพิ่มอะไรและไม่จำเป็นต้องสร้าง trust ภายใน Redis cluster
