microservices ควรเป็นผู้ใช้หรือไม่


13

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

เรามีข้อกำหนดดังต่อไปนี้:

  1. ผู้ใช้ควรถูก จำกัด ให้ดำเนินบทบาทบางอย่าง เช่นผู้ใช้ควรสามารถสร้าง / แก้ไข / อ่านเนื้อหาที่เขาเป็นเจ้าของได้เท่านั้น

  2. Microservices ควร จำกัด เฉพาะการอนุญาตที่จำเป็นเท่านั้น เช่นบริการไมโครเว็บที่เพียงต้องการอ่านข้อมูลจากบริการอื่นควรถูกห้ามอย่างชัดเจนจากการเขียนข้อมูลไปยังบริการนั้น

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

เป็นวิธีที่ดีในการบรรลุเป้าหมายข้างต้นโดยใช้โทเค็น JWT คืออะไร? วิธีแก้ปัญหาบางอย่างที่เรากล่าวถึงคือ:

  1. บริการเก็บรูปภาพแสดง 2 APIs หนึ่งที่พร้อมใช้งานภายนอก (ให้สิทธิ์การเข้าถึง CRUD ผู้ใช้) และอีกหนึ่งที่พร้อมใช้งานภายใน (ให้การเข้าถึงแบบอ่านอย่างเดียวภายใน) ดูเหมือนว่าไม่ยืดหยุ่น - จะเกิดอะไรขึ้นถ้าบริการภายในอื่นต้องการการเข้าถึงเพื่ออ่าน / เขียนภาพทั้งหมด (เช่นภาพที่ลบภาพที่ไม่ชัดเจนโดยอัตโนมัติ)

  2. เราตั้งค่าสองสิทธิ์ใน JWT ของผู้ใช้หนึ่งคือ CRUD_OwnImages ส่วนอีก READ_ForAnalysis บริการติดแท็กสามารถดูว่าผู้ใช้มีสิทธิ์ READ_ForAnalysis หรือไม่และดำเนินการตามคำขอที่เหมาะสมหรือไม่ เรามี microservice อื่นที่ตรวจสอบเพื่อดูว่าผู้ใช้มี CRUD_OwnImages สำหรับการดำเนินการ CRUD ในภาพของผู้ใช้เองหรือไม่ สิ่งนี้ทำให้เกิดความรับผิดชอบในแต่ละไมโครบริการเพื่อให้แน่ใจว่าผู้ใช้ถูก จำกัด การกระทำที่เขาต้องการ ที่เก็บรูปภาพไม่มีวิธี จำกัด microservice แต่ละรายการด้วยวิธีนี้ดังนั้นจึงอาจมีข้อผิดพลาดและเป็นไปได้ง่าย

  3. เราให้บริการการแท็ก microservice ผู้ใช้ของตนเองโดยได้รับอนุญาต READ_ForAnalysis จากนั้นเมื่อบริการติดแท็กร้องขอภาพจากที่เก็บรูปภาพบริการดังกล่าวจะได้รับการเข้าถึง แต่ไม่ได้รับอนุญาตให้แก้ไข ผู้ใช้ของผู้ใช้มีสิทธิ์ CRUD_OwnImages เท่านั้นดังนั้นเขาจึงสามารถดึงและเข้าถึงเฉพาะภาพของเขาจากส่วนหน้า หากบริการอื่นต้องการ CRUD กับข้อมูลทั้งหมดเราสามารถให้ CRUD_AllData หรือที่คล้ายกัน เราชอบวิธีนี้เนื่องจากแต่ละบริการรับผิดชอบข้อมูลของตัวเอง (แทนที่จะใช้ตรรกะนั้นซ้ำซ้อนในหลายบริการ) แต่ถ้าบริการนั้นต้องใช้ทั้งสิทธิ์ผู้ใช้และสิทธิ์ในการให้บริการไมโคร? เราสามารถส่งโทเค็น JWT สองอัน (ทั้งผู้ใช้และบริการไมโคร) ได้อย่างปลอดภัยหรือไม่? มีวิธีการรวมสิทธิ์อย่างปลอดภัยและส่งผ่านหรือไม่ เช่น

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


1
คุณเป็นผู้พัฒนารายย่อยเพียงรายเดียวหรือไม่หรือ บริษัท / องค์กร / แผนกอื่น ๆ (เช่นสิ่งใดก็ตามที่มีขอบเขตความปลอดภัย) เขียนไมโครไซต์เป้าหมายที่ระบบของคุณหรือไม่
Robert Harvey

1
เป็นไปได้มากว่าจะมีบริการอื่น ๆ คอยดูแลระบบและเราต้องการออกแบบสำหรับกรณีนั้น
awr

คำตอบ:


6

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

และโดยทั่วไปคุณมีสถานการณ์สามประเภทด้วยไมโครไซต์:

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

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

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

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

แต่โดยทั่วไป microservices ตัวเองไม่ควรเป็นผู้ใช้


1
ย่อหน้าแรกและย่อหน้าสุดท้ายของคุณไม่ขัดแย้งกันใช่หรือไม่
Robert Harvey

1
ไม่มี? การดำเนินการควรเชื่อมโยงกับผู้ใช้ Microservices ตัวเองไม่ใช่ผู้ใช้ ... ฉันจะชี้แจง
Telastyn

1
ฉันเจอวิธีแก้ไขปัญหาที่แนะนำ: กำหนดขอบเขตสำหรับ microservice แต่ละรายการซึ่งระบุจุดสิ้นสุดที่สามารถเข้าถึงได้ในโทเค็นการเข้าถึง ส่งต่อโทเค็น JWT id ของผู้ใช้เป็นส่วนหัวอื่น วิธีนี้เราสามารถ จำกัด ทั้งไมโครไซต์และผู้ใช้ (การป้องกันในเชิงลึก) บทที่ 10 ของmanning.com/books/microservices-in-net-core
awr

สถานการณ์ที่ 3 เป็นสิ่งที่น่าสนใจซึ่งทำให้เราตัดสินใจว่าผู้ใช้ควรใช้ไมโครไซต์ แต่ดูเหมือนว่าอาจเป็นข้อยกเว้นมากกว่ากฎ
awr
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.