คุณต้องการใบรับรอง SSL จำนวนเท่าใด - aspnet core + Apache reverse proxy

ไม่มีคำตอบง่าย ๆ ว่าใช่ / ไม่ใช่สำหรับคำถามนี้ที่ฉันเกรงว่า

หาก Kestrel และ Apache ทำงานบนกล่องเดียวกัน แสดงว่าคุณใช้ใบรับรองได้อย่างมีประสิทธิภาพเท่านั้น เนื่องจาก Kestrel ต้องการใบรับรอง ไม่มีการรักษาความปลอดภัยและ ปลอดภัยกว่าไหม? คำถามนี้ใช้ไม่ได้

หาก Kestrel และ Apache อยู่ในกล่องที่แตกต่างกัน แสดงว่าซับซ้อนกว่าเล็กน้อย หากทั้งสองกล่องอยู่ในเครือข่ายที่เชื่อถือได้ คุณสามารถโต้แย้งได้เช่นเดียวกับข้างต้น ใบรับรองมีไว้ที่นั่นเท่านั้นเนื่องจาก Kestrel ต้องการหนึ่งกล่อง

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

• หากแอปพลิเคชัน Kestrel ใช้ FQDN ภายใน (เช่น app.local) และ CA ไม่เต็มใจที่จะรับรองชื่อดังกล่าว (เช่น CA เชิงพาณิชย์จะไม่ทำเช่นนี้) คุณจะถูกบังคับให้ใช้ใบรับรองที่ลงนามด้วยตนเอง
• หาก CA เป็นแบบภายในและยินดีให้การรับรองชื่อท้องถิ่น คุณสามารถพิจารณาใช้ CA สำหรับใบรับรอง Kestrel

ดังนั้น สมมติว่าตอนนี้คุณสามารถใช้ใบรับรอง CA สำหรับ Kestrel ได้ คุณต้องถามตัวเองต่อไปว่าเหตุใดจึงต้องทำเช่นนั้น:

• ใบรับรองที่ลงนามโดย CA โดยทั่วไปจะคุ้มค่าในสถานการณ์แบบหนึ่งต่อกลุ่ม หากคุณมีเซิร์ฟเวอร์เดียวและมีผู้เกี่ยวข้องจำนวนมาก (ไคลเอนต์) ใบรับรองที่ออกโดย CA จะช่วยให้แน่ใจว่า:

  • ฝ่ายที่เกี่ยวข้องจำเป็นต้องเชื่อถือ CA เท่านั้น และใบรับรองที่ออกทุกใบจะเชื่อถือได้โดยปริยาย (ใบรับรองที่ลงนามด้วยตนเองจะต้องได้รับความเชื่อถือจากลูกค้าทั้งหมด)
  • ฝ่ายที่พึ่งพาไม่จำเป็นต้องตรวจสอบการกำกับดูแลและกระบวนการปฏิบัติงานของแต่ละเซิร์ฟเวอร์ที่พวกเขาต้องการเชื่อถือ เนื่องจากพวกเขาสามารถสันนิษฐานได้ว่าถ้า CA รับรองแล้ว ก็จะเชื่อถือได้
  • ทุกอย่างใช้งานได้หลังจากต่ออายุใบรับรอง (เทียบกับการเซ็นชื่อด้วยตนเองซึ่งจะต้องแจกจ่ายให้ ทั้งหมด ลูกค้าหลังจากต่ออายุ);
  • การเพิกถอนใช้งานได้ (ไม่มีแนวคิดในการเพิกถอนใบรับรองที่ลงนามเอง - หากใบรับรองเซิร์ฟเวอร์ถูกละเมิด คุณจะต้องลบใบรับรองออกจาก ทั้งหมด ลูกค้า);

• อย่างไรก็ตาม หากคุณอยู่ในสถานการณ์แบบหนึ่งต่อหนึ่ง (เช่น ระหว่าง reverse proxy และเซิร์ฟเวอร์แอปพลิเคชัน) CA จะให้ประโยชน์น้อยกว่า (การตัดสินใจที่ไว้วางใจได้ง่ายกว่า การต่ออายุทำได้ง่าย และหากเซิร์ฟเวอร์ถูกบุกรุก คุณก็เพียงแค่ลบออก ใบรับรองจากลูกค้ารายหนึ่ง) ในความเป็นจริง หากคุณไม่มี CA ค่าใช้จ่ายในการสร้างและจัดการ CA สำหรับการเชื่อมต่อระหว่างแอปพลิเคชันเซิร์ฟเวอร์และพร็อกซีย้อนกลับนั้นสูงมากจนทำให้ไม่คุ้มค่า

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

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

หากคุณดำเนินการตามเส้นทางของใบรับรองที่ออกโดย CA สำหรับเซิร์ฟเวอร์แอปพลิเคชัน คุณมีการตัดสินใจเพิ่มเติม:

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

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

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