Microservices Security วิธีการรักษาความปลอดภัยโครงสร้างพื้นฐานไมโครเซอร์วิสของคุณ?

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

• ไมโครเซอร์วิสคืออะไร?
• ปัญหาที่ต้องเผชิญในไมโครเซอร์วิส
• แนวทางปฏิบัติที่ดีที่สุดในการรักษาความปลอดภัยของไมโครเซอร์วิส

ไมโครเซอร์วิสคืออะไร?

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

ฟังก์ชันกำลังใน java สำหรับจำนวนเต็ม

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

ดังนั้นต่อไปในบทความเกี่ยวกับการรักษาความปลอดภัยไมโครเซอร์วิสให้เราเข้าใจปัญหาที่ต้องเผชิญในสถาปัตยกรรมไมโครเซอร์วิส

ปัญหาที่ต้องเผชิญในไมโครเซอร์วิส

ปัญหาที่พบในไมโครเซอร์วิสมีดังนี้:

ปัญหาที่ 1:

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

ปัญหา 2:

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

ปัญหาที่ 3:

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

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

แนวทางปฏิบัติที่ดีที่สุดสำหรับการรักษาความปลอดภัยไมโครเซอร์วิส

แนวทางปฏิบัติที่ดีที่สุดในการปรับปรุงความปลอดภัยในไมโครเซอร์วิสมีดังนี้:

การป้องกันในกลไกเชิงลึก

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

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

โทเค็นและ API เกตเวย์

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

หลาม __init__

โทเค็น

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

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

เกตเวย์ API

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

การติดตามและการจัดการเซสชันแบบกระจาย

การติดตามแบบกระจาย

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

การจัดการเซสชัน

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

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

เซสชันแรกและ SSL ร่วมกัน

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

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

def __init __ (ตัวเอง) python

3^ถการเข้าถึงแอปพลิเคชันปาร์ตี้

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

การใช้ OAuth

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

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

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

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

มีคำถามสำหรับเรา? โปรดระบุไว้ในส่วนความคิดเห็นของ ' Microservice Security ” แล้วฉันจะติดต่อกลับไป