Computer >> บทช่วยสอนคอมพิวเตอร์ >  >> การเขียนโปรแกรม >> Redis

เชื่อมต่อ SSL/TLS กับ Redis Enterprise: คู่มือสำหรับนักพัฒนา Java

การสร้างซอฟต์แวร์ที่ใช้การเชื่อมต่อแบบปลอดภัยไปยังเซิร์ฟเวอร์ ควรเป็นทักษะที่นักพัฒนาทุกคนควรมี แม้คุณจะเลือกไม่เปิดใช้งาน SSL ในสภาพแวดล้อมการผลิตเฉพาะเจาะจง คุณก็ควรทราบวิธีรักษาความปลอดภัยของการเชื่อมต่อไปยังเซิร์ฟเวอร์ทุกตัวที่คุณทำงานร่วมกัน บทความนี้เป็นการตอบสนองต่อคำขอสำหรับผู้ใช้ Java หลังจากบทความ Enabling Secure Connections to Redis Enterprise Cloud in Python

บทความนี้จะแนะนำขั้นตอนที่ง่ายดายในการเปิดใช้งาน ทดสอบ และกำหนดค่าการเชื่อมต่อที่เข้ารหัสระหว่าง Redis Enterprise Cloud และโปรแกรมไคลเอ็นต์ Java โดยใช้ SSL สิ่งที่ทำให้สับสนในการเปิดใช้งาน SSL สำหรับโปรแกรม Java คือ การแปลงใบรับรองและคีย์ให้อยู่ในรูปแบบที่ Java เข้าใจ นี่คือขั้นตอนเฉพาะ Java ที่เราต้องแทรกไว้ระหว่างขั้นตอนการทดสอบและกำหนดค่า

เครื่องมือที่จำเป็น

เตรียมเครื่องมือเหล่านี้เพื่อให้คุณสามารถปิดตั๋วการเปิดใช้งาน SSL บน Redis ได้:

  • บัญชี Redis Enterprise Cloud
  • OpenSSL
  • Java SE JDK
  • Jedis (ไคลเอ็นต์ Java สำหรับ Redis)

คุณยังต้องมี Bash shell ติดตั้งไว้ เพื่อให้สามารถรันสคริปต์เล็กๆ ที่เราเตรียมไว้ได้ หากระบบปฏิบัติการของคุณไม่มี Bash ติดตั้งมากับระบบ คุณจะต้องติดตั้งมัน หรือแปลงสคริปต์ของเราให้เหมาะกับ shell ที่คุณชอบ

เพื่อใช้ SSL บัญชี Redis Enterprise Cloud ของคุณต้องเปิดใช้งานฟีเจอร์ SSL แล้ว หากบัญชีของคุณยังไม่ได้เปิดใช้งาน SSL คุณจะต้องติดต่อทีมสนับสนุนของ Redis เพื่อเปิดใช้งาน คุณจะพบลิงก์ติดต่อทีมสนับสนุนในเมนูหลักของแดชบอร์ดบัญชี เอกสารสำหรับการตั้งค่า SSL สามารถหาได้ในคู่มือปฏิบัติการและการจัดการ Redis Enterprise Cloud

SSL เทียบกับ TLS

เพียงแค่เตือนใจ: ตามบทความ Python ของเรา เราจะปฏิบัติตามข้อตกลงที่ไม่เป็นทางการในการใช้คำย่อ "SSL" เพื่ออ้างถึงการเชื่อมต่อที่ปลอดภัยด้วย "SSL" หรือ "TLS" ทั้งสอง แม้ Redis Enterprise Cloud จะใช้โปรโตคอล TLS เวอร์ชัน 1.2 ในการรักษาความปลอดภัยของการเชื่อมต่อ (ณ มิถุนายน 2018) แต่ Redis Enterprise Cloud และ Jedis ใช้คำว่า "SSL" ทั้งคู่ เราจึงจะปฏิบัติตามกัน

ขั้นตอนที่ 1 และ 2

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

กระบวนการเริ่มแตกต่างสำหรับ Java หลังจากขั้นตอนที่ 2 ดังนั้นเราจะแทรกขั้นตอนที่ 2.5 ที่นี่ เพื่อแปลงไฟล์ข้อมูลประจำตัวที่คุณดาวน์โหลดจาก Redis Enterprise Cloud ให้อยู่ในรูปแบบที่ทำงานได้ดีกับ Java SE

ขั้นตอนที่ 2.5: การแปลงข้อมูลประจำตัว

บรรทัดฐานของ Java SE Oracle มอบบริการความปลอดภัยหลากหลาย รวมถึง Java Cryptography Architecture (JCA) JCA กำหนดชุด API สำหรับแอปพลิเคชัน Java เพื่อเรียกใช้บริการความปลอดภัยที่ถูกนำไปใช้โดยผู้ให้บริการปลั๊กอิน แอปพลิเคชันสามารถใช้ผู้ให้บริการที่พร้อมใช้งานได้ทุกตัว (ซึ่งมักให้บริการเพิ่มเติมนอกเหนือจาก API มาตรฐาน) แต่แอปพลิเคชันส่วนใหญ่ใช้ผู้ให้บริการเริ่มต้นที่มาพร้อมกับ JDK

ความท้าทายในการใช้ผู้ให้บริการเริ่มต้นคือ พวกเขาไม่รองรับรูปแบบ PEM ที่มักใช้กับไลบรารี SSL ของ Linux เพื่อจัดเก็บใบรับรองและคีย์ ใน JCA วัสดุข้อมูลประจำตัวจะถูกจัดเก็บในที่เก็บคีย์ (keystore) ที่ป้องกันด้วยรหัสผ่าน ในแอปพลิเคชัน Java มักใช้ที่เก็บสองแห่ง: หนึ่งเรียกในเอกสารว่า keystore และอีกหนึ่งเรียกว่า truststore Keystore ใช้จัดเก็บใบรับรองและคีย์ส่วนตัวสำหรับซอฟต์แวร์ไคลเอ็นต์ ส่วน truststore ใช้จัดเก็บใบรับรองที่เชื่อถือได้จากหน่วยออกใบรับรอง เนื่องจาก Redis Enterprise Cloud ใช้รูปแบบ PEM เราจึงสร้างสคริปต์โดยใช้ OpenSSL และ Java Keytool เพื่อรันคำสั่งทั้งหมดที่จำเป็นในการแปลงไฟล์ PEM ของคุณให้กลายเป็น truststore และ keystore ที่ใช้งานได้สำหรับโปรแกรมไคลเอ็นต์ Java ของคุณ

สคริปต์ต่อไปนี้ transmogrify.sh ควรรันจากไดเรกทอรีที่คุณแตกไฟล์ redis_credentials.zip ไว้ สคริปต์ใช้ใบรับรอง Certificate Authority ของ Redis (redis_ca.pem) เพื่อสร้าง truststore (redis_truststore.p12) และใช้ใบรับรองไคลเอ็นต์ (redis_user.crt) พร้อมคีย์ส่วนตัวที่สอดคล้อง (redis_user_private.key) เพื่อสร้าง keystore (redisclient_keystore.p12) แม้ keystore ของไคลเอ็นต์จะได้รับการป้องกันด้วยรหัสผ่าน คุณยังควรดำเนินการเพื่อให้แน่ใจว่าความปลอดภัยของ keystore ของคุณ ทั้ง keystore และ truststore จะต้องถูกแจกจ่ายไปยังทุกไคลเอ็นต์ที่เชื่อมต่อกับอินสแตนซ์ฐานข้อมูล Redis เฉพาะตัว ดังนั้นคุณจะต้องรวมไฟล์เหล่านี้เข้าในระบบจัดการข้อมูลประจำตัวของคุณ

Java เวอร์ชันก่อน JDK 9 ใช้รูปแบบ Java KeyStore (JKS) ที่เป็นของตนเอง แต่เริ่มจาก JDK 9 เป็นต้นไป Java ใช้รูปแบบมาตรฐานอุตสาหกรรม PKCS12 เป็นค่าเริ่มต้น สคริปต์นี้สร้างที่เก็บในรูปแบบ PKCS12 แต่หากคุณสามารถแก้ไขสคริปต์ได้ คุณสามารถใช้รูปแบบ JKS โดยการเปลี่ยนตัวเลือกประเภทที่เก็บและนามสกุลไฟล์

ขั้นตอนที่ 3: กำหนดค่า SSL ในโค้ดไคลเอ็นต์ของคุณ

ขั้นตอนสุดท้ายในการเปิดใช้งาน SSL ในไคลเอ็นต์ Java ของคุณคือการแก้ไขโค้ดไคลเอ็นต์เพื่อสร้างการเชื่อมต่อ SSL โค้ดตัวอย่างของเราจะสร้างการเชื่อมต่อปลอดภัยไปยังอินสแตนซ์ Redis Enterprise Cloud ของเรา จากนั้นส่งคำสั่ง Redis PING โค้ดที่ปรับปรุงแล้วมีลักษณะดังนี้:

คุณจะสังเกตว่า ไม่มีที่ไหนในโค้ดที่เราอ้างอิงถึง keystore หรือ truststore ที่เราสร้างสำหรับโปรแกรม Java ในขั้นตอนที่ 2.5 พฤติกรรมเริ่มต้นของผู้ให้บริการ JCA คือการยืนยันตัวตนของเซิร์ฟเวอร์ เราเพียงแค่ต้องให้ข้อมูลคีย์และใบรับรองของเรา ซึ่งสามารถทำได้ด้วยพร็อพเพอร์ตี้ระบบที่ผู้ให้บริการ JCA อ่าน ให้เพิ่มพารามิเตอร์ต่อไปนี้ในการกำหนดค่าแอปพลิเคชัน IDE หรือบรรทัดคำสั่ง java:

พร็อพเพอร์ตี้ Keystore:

  • javax.net.ssl.keyStoreType=PKCS12
  • javax.net.ssl.keyStore=/path/to/redisclient_keystore.p12
  • javax.net.ssl.keyStorePassword=your_password

ระบุประเภท (รูปแบบ) ตำแหน่ง และรหัสผ่านสำหรับ keystore ที่สร้างโดยสคริปต์ transmogrify ทำนองเดียวกัน พร็อพเพอร์ตี้ TrustStore:

  • javax.net.ssl.trustStoreType=PKCS12
  • javax.net.ssl.trustStore=/path/to/redis_truststore.p12
  • javax.net.ssl.trustStorePassword=your_password

ระบุประเภท ตำแหน่ง และรหัสผ่านของ trustStore พร็อพเพอร์ตี้สุดท้าย javax.net.debug=ssl:handshake เป็นพร็อพเพอร์ตี้ทางเลือกที่ใช้เปิดใช้งานข้อมูลดีบัก

การกำหนดค่า Jedis ให้ใช้ SSL ไม่ได้ยากมาก แต่อาจดูน่ากลัวในตอนแรกหากคุณไม่คุ้นเคยกับขั้นตอนที่จำเป็นในการแปลงข้อมูลประจำตัว PEM ให้กลายเป็น keystore และ truststore ของ Java

หวังว่าบทความนี้จะให้การแนะนำที่นุ่มนวลสำหรับแฟนๆ Java ในการตั้งค่าการเชื่อมต่อปลอดภัยไปยัง Redis Enterprise Cloud เหมือนกับที่เราทำให้กับนักพัฒนา Python ฉันต้องการเตือนอีกครั้งเรื่องความปลอดภัย: องค์กรส่วนใหญ่มีนโยบายและขั้นตอนเฉพาะสำหรับการจัดการรหัสผ่านและคีย์ส่วนตัว โปรดตรวจสอบกับทีมปฏิบัติการและความปลอดภัยของคุณเพื่อให้แน่ใจว่าคุณปฏิบัติตามแนวทางของพวกเขา