TLS แบบเนทีฟ การส่งต่อ SSH หรือ VPN สำหรับบริการคลาวด์เดียว

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

เริ่มจากบริการ ไม่ใช่เครือข่าย

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

ใช้ API ภายในขนาดเล็กที่ให้บริการ HTTPS บนพอร์ต 8443 อยู่แล้ว พร้อมใบรับรองสำหรับ api.internal.example ss -ltnp บนโฮสต์แสดงว่ามันผูกกับอะไร และ openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example แสดงว่าใบรับรองใช้ได้กับชื่อที่ไคลเอนต์จะใช้จริงหรือไม่ หากทั้งสองแข็งแรง บริการสามารถปกป้องสตรีมของตัวเองได้ และเหลือเพียงการเข้าถึงเท่านั้น นั่นเป็นปัญหาที่เล็กกว่าการสร้างเครือข่ายมาก

ขั้นที่ 1: บริการปกป้องตัวเองหรือไม่

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

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

ขั้นที่ 2: พอร์ต TCP เดียวคือข้อกำหนดทั้งหมดหรือไม่

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

รูปแบบคือ ssh -N -L 8443:127.0.0.1:8443 [email protected] และรายละเอียดที่สำคัญคือที่อยู่ปลายทาง: 127.0.0.1 ถูกแก้ไขฝั่งไกล ดังนั้นการเชื่อมต่อกับบริการจึงเปิดจาก bastion ไม่ใช่จากแล็ปท็อปของคุณ ผูกตัวรับฟังภายในเครื่องให้แคบเป็น -L 127.0.0.1:8443:... เพื่อไม่ให้เผยแพร่บริการไปยังเครือข่ายภายในของคุณเองโดยไม่ตั้งใจ ฝั่งเซิร์ฟเวอร์ จำกัดสิ่งที่บัญชีสามารถส่งต่อได้แทนการเชื่อถือพฤติกรรมที่ดีของไคลเอนต์ PermitOpen AllowTcpForwarding local และค่าเริ่มต้น GatewayPorts no คือการตั้งค่าสามอย่างที่เปลี่ยนรีเลย์ทั่วไปให้เป็นช่องทางเฉพาะ

สัญญาแคบทั้งสองทิศทาง SSH ปกป้องช่องทางของตัวเอง และการกระโดดต่อไปจาก bastion ไปยังแอปพลิเคชันอื่นต้องมีการปกป้องของตัวเอง บริการที่รับฟังเฉพาะ loopback ของ bastion มีการเปิดเผยที่แตกต่างจากบริการที่เข้าถึงผ่านเครือข่ายอื่นโดยสิ้นเชิง และการส่งต่อไม่เปลี่ยนสิ่งนั้น รักษาการรับรองและตรวจสอบ TLS ของแอปพลิเคชันไว้แทนการถือว่าอุโมงค์เป็นสิ่งทดแทน

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

ขั้นที่ 3: การกำหนดเส้นทางเป็นข้อกำหนดจริงหรือไม่

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

การกำหนดเส้นทางกลายเป็นคำตอบที่ถูกต้องเมื่อการกำหนดเส้นทางคือข้อกำหนด แอปพลิเคชันหลายตัวที่ต้องการการเชื่อมต่อ IP ปกติ โปรโตคอลที่การส่งต่อ TCP ไม่สามารถพาไปได้ หรือบริการที่ย้ายระหว่างโฮสต์ ล้วนชี้ไปทางเดียวกัน

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

สิ่งที่คุณเป็นเจ้าของหลังจากนั้น

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

การเดินชมสิ้นสุดที่จุดเริ่มต้น คือที่บริการ เลือกขอบเขตที่ครอบคลุมทราฟฟิกจริงและตรวจสอบเพื่อนที่คุณตั้งใจจะตรวจสอบ จากนั้นจดว่าการเข้าถึงได้รับการอัปเดต ตรวจสอบ และถอดถอนอย่างไร เอกสารอ้างอิง OpenSSH คือสถานที่ยืนยันตัวเลือกการส่งต่อก่อนให้สัญญาที่แคบ หากคุณไม่สามารถอธิบายขั้นตอนการถอดถอนในหนึ่งประโยคได้ ขอบเขตนั้นใหญ่กว่าปัญหา