Cassandra ผ่าน VPN: แยกการเข้าถึงสำหรับไคลเอนต์และโหนด

การติดตั้ง Cassandra ไม่ได้มีเครือข่ายฐานข้อมูลเดียวที่ใช้ร่วมกันทั้งระบบ แอปพลิเคชันคุยกับบริการไคลเอนต์ สมาชิกคลัสเตอร์คุยกันเอง และผู้ปฏิบัติงานใช้ส่วนติดต่อผู้ดูแลระบบ และผู้ใช้สามกลุ่มนี้ไม่ควรสืบทอดความสามารถในการเข้าถึงของกันและกัน เส้นทางส่วนตัวอย่าง VPN เป็นจุดเริ่มต้นที่ดี แต่ไม่ใช่ตัวตนผู้ใช้ของฐานข้อมูลและไม่ใช่นโยบายการเข้ารหัสของฐานข้อมูล การตัดสินเรื่องการเชื่อมต่อและการตัดสินเรื่องการอนุญาตควรถูกทบทวนแยกจากกันสองครั้ง

ผู้ใช้ทั้งสามกลุ่มได้คำตอบของตัวเอง และหัวข้อด้านล่างจะพูดถึงตามลำดับการเปิดเผย

สามกลุ่มผู้ใช้ สามการตัดสินใจ

ระบุว่ากลุ่มแต่ละกลุ่มต้องการอะไรจริง ๆ ก่อนจะแตะกฎใด ๆ ไคลเอนต์ต้องการตัวรับฟังฝั่งไคลเอนต์และข้อมูลเพียงพอที่จะไปถึงทุกโหนดที่อาจถูกมอบให้ โหนดคู่ค้าต้องการกันและกันบนพอร์ต internode และผู้ปฏิบัติงานต้องการส่วนติดต่อการจัดการสำหรับสิ่งที่ runbook เรียกร้องจริง ๆ สามรายการ สามกลุ่ม สามระดับความไว้วางใจ

ความผิดพลาดที่พบบ่อยคือสร้างเซกเมนต์ส่วนตัวแบนเดียวแล้วสมมติว่าขอบเขต VPN จัดการที่เหลือ ภายในนั้น แอปพลิเคชันที่ไปถึงพอร์ตไคลเอนต์มักไปถึงพอร์ต internode ได้ด้วย และเครื่องมือผู้ดูแลระบบของผู้ปฏิบัติงานมักอยู่บนโฮสต์กระโดดเดียวกันกับแอปพลิเคชัน การทำให้แบนรวมกันหมายความว่าตัวตนแอปพลิเคชันที่ถูกโจมตีมีความสามารถในการเข้าถึงมากกว่าคิวรีของตัวเองอยู่แล้ว จงวาดสามกลุ่มเป็นสามแถวในเอกสารออกแบบ แต่ละแถวมีกฎที่อนุญาต และช่องว่างจะมองเห็นได้ก่อนที่ใครจะสร้างมัน

สิ่งที่ไคลเอนต์ต้องการ และไม่มีอะไรเกินกว่านั้น

อนุญาตแหล่งแอปพลิเคชันที่ตั้งใจไว้ไปยังจุดปลายฝั่งไคลเอนต์สำหรับเวอร์ชันที่ติดตั้ง และกันบริการคลัสเตอร์และการจัดการที่ไม่เกี่ยวข้องออกจากขอบเขตนั้น จากนั้นตรวจสอบว่าตัวขับค้นหาโหนดอย่างไร จุดติดต่อเริ่มต้นที่เข้าถึงได้ไม่ได้พิสูจน์ว่าทุกที่อยู่โหนดที่ตัวขับเลือกในภายหลังจะเข้าถึงได้จากบริบทไคลเอนต์นั้น เพราะตัวขับถามคลัสเตอร์เรื่องคู่ค้าแล้วจึงเชื่อมต่อกับที่อยู่ที่คลัสเตอร์ประกาศ

นั่นคือเหตุผลที่ความไม่ตรงกันของที่อยู่ส่วนตัวหนึ่งจุดสร้างรูปแบบที่คุ้นเคย คือการเชื่อมต่อครั้งแรกสำเร็จแล้วตามด้วยการหมดเวลา จงกำหนดค่าที่อยู่ที่ประกาศและการกำหนดเส้นทางฝั่งไคลเอนต์อย่างตั้งใจ การเผยแพร่คลัสเตอร์ทั้งหมดสู่อินเทอร์เน็ตเพื่อแก้ความไม่ตรงกันหนึ่งจุดแลกบั๊กการกำหนดเส้นทางกับการเปิดเผยที่คุณเรียกคืนไม่ได้

รักษาการพิสูจน์ตัวตนฐานข้อมูลและสิทธิ์ตามบทบาทของแอปพลิเคชันไว้ด้วย ที่อยู่ VPN ที่แปลแล้วและใช้ร่วมกันอาจแทนผู้ใช้หรือบริการหลายราย ดังนั้นจึงไม่ใช่สิ่งทดแทนตัวตนฐานข้อมูลที่แยกจากกัน

เข้ารหัสไคลเอนต์ถึงโหนดและ internode แยกกัน

เอกสาร ความปลอดภัยของ Apache มองการเข้ารหัสไคลเอนต์ถึงโหนดและ internode เป็นการกำหนดค่าแยกกัน และการเปิดอย่างหนึ่งไม่ได้เปิดอีกอย่าง ความแตกต่างนี้ยังใช้ได้ภายใน VPN เพราะอุโมงค์ปกป้องเซกเมนต์ของตัวเองและไม่ขยายจากกระบวนการแอปพลิเคชันไปยังกระบวนการฐานข้อมูลหรือระหว่างสมาชิกคลัสเตอร์ทุกคู่โดยอัตโนมัติ

การกำหนดค่าที่เปิดทั้งสองอย่างชัดเจน แทนที่จะสืบทอดค่าเริ่มต้นจากแม่แบบ มีลักษณะประมาณนี้

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

บนการกำหนดค่าเซิร์ฟเวอร์ที่อนุญาตการเข้ารหัสฝั่งไคลเอนต์แบบเลือกได้ การยอมรับ TLS สามารถอยู่ร่วมกับการยอมรับการเชื่อมต่อที่ไม่เข้ารหัสได้ ดังนั้นจงอ่านนโยบายที่มีผลจริงไม่ใช่เจตนา วางแผนชื่อใบรับรอง การกระจายความไว้วางใจ และการต่ออายุสำหรับจุดปลายที่ไคลเอนต์แต่ละรายติดต่อจริง การแทนที่ชื่อโฮสต์ด้วยที่อยู่ IP เปลี่ยนการตรวจสอบตัวตนของไคลเอนต์ ไม่ใช่แค่เส้นทาง

เก็บการดูแลระบบไว้บนเส้นทางของตัวเอง

ทราฟฟิก internode ต้องการชุดคู่ค้าที่ได้รับอนุญาตและนโยบายการป้องกันของตัวเอง การเข้าถึงของผู้ดูแลระบบ รวมถึง JMX ในที่ที่ใช้ ต้องการผู้ใช้กลุ่มแยกและการพิสูจน์ตัวตนของตัวเอง แอปพลิเคชันที่ได้รับอนุญาตให้ส่งคิวรีธรรมดาไม่ได้ต้องการความสามารถในการจัดการทั้งหมดเพราะเหตุนั้น และกลับกันก็แย่กว่า คือเส้นทางผู้ดูแลระบบที่เปิดให้เซกเมนต์แอปพลิเคชันเป็นเส้นทางที่สั้นที่สุดจากบั๊กไปสู่การสร้างใหม่ จงเขียนสองกลุ่มนั้นแยกกันและระบุเจ้าของ เพราะโดยปกติเป็นทีมต่างกันที่กฎถูกรวมเข้าด้วยกันโดยอุบัติเหตุ

ทำให้กฎคลาวด์ กฎโฮสต์ และการกำหนดค่าตัวรับฟังที่มีผลสอดคล้องกัน ตัวรับฟังส่วนตัวยังสามารถถูกเปิดเผยผ่านการแปลหรือพร็อกซีที่ไม่ตั้งใจ และกฎสาธารณะที่กว้างสามารถนอนเงียบอยู่ข้างกฎ VPN ที่แคบจนกว่าจะมีคนตรวจทั้งสองพร้อมกัน

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

สิ่งที่การออกแบบสัญญาไว้

ตรวจสอบคำสัญญาทั้งสามข้อด้วยบทบาทจริง ไม่ใช่แค่การทดสอบการเชื่อมต่อ แอปพลิเคชันที่ได้รับอนุมัติควรทำงานที่ได้รับอนุญาตให้เสร็จและไม่มีอะไรเกินกว่านั้น แหล่งที่ถูกกีดกันควรล้มเหลวที่ทางเข้าฝั่งไคลเอนต์ และตัวตนแอปพลิเคชันควรถูกปฏิเสธบนเส้นทางผู้ดูแลระบบที่สงวนไว้ จงเพิ่มการเชื่อมต่อใหม่ของไคลเอนต์และการเลือกโหนดในการทดสอบการเปิดใช้งานเดียวกัน เพราะนั่นคือที่ที่ความผิดพลาดในการค้นหาโผล่ขึ้นมา

จบด้วยสามประโยคในเอกสารออกแบบ: ไคลเอนต์ใดสามารถคิวรีได้ โหนดใดสามารถสื่อสารได้ และผู้ปฏิบัติงานใดสามารถดูแลระบบได้ การอยู่หลัง VPN เป็นข้อมูลโครงสร้างเครือข่ายที่มีประโยชน์ แต่ไม่ใช่คำตอบของคำถามทั้งสามข้อนั้น