แชร์ผ่าน

คำแนะนำสำหรับการรักษาความปลอดภัยวงจรชีวิตการพัฒนา

  • บทความ

ใช้กับคำแนะนำรายการตรวจสอบความปลอดภัยที่ได้รับการออกแบบอย่างดีนี้: Power Platform

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

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

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

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

คำจำกัดความ

เงื่อนไข ข้อกำหนด
วงจรชีวิตการพัฒนาความปลอดภัย (SDL) ชุดของแนวทางปฏิบัติของ Microsoft ซึ่งสนับสนุนข้อกำหนดด้านการประกันความปลอดภัยและการปฏิบัติตามข้อกำหนด
วงจรชีวิตการพัฒนาซอฟต์แวร์ (SDLC) กระบวนการหลายขั้นตอนที่เป็นระบบสำหรับการพัฒนาระบบซอฟต์แวร์

กลยุทธ์การออกแบบที่สำคัญ

มาตรการรักษาความปลอดภัยควรบูรณาการในหลายจุดในวงจรชีวิตการพัฒนาซอฟต์แวร์ (SDLC) ที่มีอยู่ของคุณเพื่อให้แน่ใจว่า:

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

ส่วนต่อไปนี้เป็นกลยุทธ์ด้านความปลอดภัยสำหรับระยะที่ปฏิบัติกันโดยทั่วไปของ SDLC

ขั้นตอนความต้องการ

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

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

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

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

ขั้นตอนการออกแบบ

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

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

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

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

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

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

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

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

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

  • หลีกเลี่ยงการเขียนฮาร์ดโค้ด หลีกเลี่ยงการเขียนฮาร์ดโค้ดของ URL และคีย์ ตัวอย่างเช่น หลีกเลี่ยงการเขียนฮาร์ดโค้ดในการดำเนินการ HTTP ของ Power Automate กับ URL หรือคีย์ไปยังบริการแบ็กเอนด์ ให้ใช้ตัวเชื่อมต่อแบบกำหนดเองหรือใช้ตัวแปรสภาพแวดล้อมสำหรับ URL และใช้ Azure Key Vault สำหรับคีย์ API แทน

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

หมายเหตุ

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

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

ดูข้อมูลเพิ่มเติมที่คำแนะนำในการวิเคราะห์ภัยคุกคาม

ขั้นตอนการพัฒนาและการทดสอบ

ในขั้นตอนนี้ เป้าหมายคือ การป้องกันข้อบกพร่องด้านความปลอดภัย และการดัดแปลงในไปป์ไลน์โค้ด การสร้าง และไปป์ไลน์การปรับใช้งาน

ได้รับการฝึกอบรมมาเป็นอย่างดีเกี่ยวกับหลักปฏิบัติด้านโค้ดที่ปลอดภัย

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

นักพัฒนาควรต้องผ่านการฝึกอบรมนี้ก่อนที่จะเริ่มทำงานกับเวิร์กโหลด Power Platform

ดำเนินการตรวจสอบโค้ดจากผู้ทรงคุณวุฒิภายในเพื่อส่งเสริมการเรียนรู้อย่างต่อเนื่อง

ใช้เครื่องมือวิเคราะห์โค้ด

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

ทำการทดสอบสุ่มป้อนข้อมูล

ใช้ข้อมูลที่ผิดรูปแบบและไม่คาดคิดเพื่อตรวจสอบช่องโหว่และตรวจสอบการจัดการข้อผิดพลาด โดยเฉพาะอย่างยิ่งกับโซลูชันที่รวมถึง Power Pages

พัฒนาโค้ดแค่เท่าที่จำเป็น

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

ป้องกันสภาพแวดล้อมของนักพัฒนา

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

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

การปรับใช้งานโค้ดที่ปลอดภัย

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

รักษารายการของทุกส่วนประกอบที่รวมเข้ากับแอปพลิเคชันของคุณให้เป็นปัจจุบัน

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

เราขอแนะนำให้ใช้ ไปป์ไลน์สำหรับ Power Platform สำหรับการปรับใช้งานของคุณ ขยายไปป์ไลน์โดยใช้ GitHub Actions หากคุณใช้เวิร์กโฟลว์ GitHub ให้เลือกงานที่เขียนโดย Microsoft นอกจากนี้ ตรวจสอบความถูกต้องของงานเนื่องจากงานเหล่านั้นทำงานในบริบทความปลอดภัยของไปป์ไลน์ของคุณ

สำรวจการใช้บริการหลักสำหรับการปรับใช้งาน

ขั้นตอนการทำงานจริง

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

เก็บอาร์ทิแฟกต์ที่มีเวอร์ชันไว้

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

การแก้ไขกรณีฉุกเฉิน

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

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

หมายเหตุ

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

แยกสภาพแวดล้อมที่แตกต่างกันออกจากกัน

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

ใช้การเปิดเผยแบบเป็นขั้นตอน

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

ขั้นตอนการบำรุงรักษา

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

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

ปลดระวางสินทรัพย์เก่า ที่ไม่ได้ใช้งานอีกต่อไป การทำเช่นนี้จะช่วยลดเลเยอร์ส่วนติดต่อของแอปพลิเคชัน

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

ปรับปรุงแนวทางปฏิบัติในการเขียนโค้ดที่ปลอดภัยของคุณอย่างต่อเนื่องเพื่อให้ทันกับรูปแบบภัยคุกคาม

SDL ใน Microsoft Power Platform

Power Platform สร้างขึ้นจากวัฒนธรรมและวิธีการของการออกแบบที่ปลอดภัย ทั้งวัฒนธรรมและวิธีการได้รับการเสริมความแข็งแกร่งอย่างต่อเนื่องผ่านแนวทางปฏิบัติ วัฏจักรการพัฒนาความปลอดภัย (SDL) ชั้นนำในอุตสาหกรรมของ Microsoft และ รูปแบบความเสี่ยง

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

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

SDL ของ Microsoft เทียบเท่ากับ OWASP Software Assurance Maturity Model (SAMM) ทั้งสองสร้างขึ้นบนสมมติฐานที่ว่าการออกแบบที่ปลอดภัยเป็นส่วนสำคัญในการรักษาความปลอดภัยของเว็บแอปพลิเคชัน สำหรับข้อมูลเพิ่มเติม โปรดดู ความเสี่ยง 10 อันดับแรกของ OWASP: การลดความเสี่ยงใน Power Platform

การอำนวยความสะดวกของ Power Platform

Microsoft Security Development Lifecycle (SDL) แนะนำแนวทางปฏิบัติที่ปลอดภัยที่คุณสามารถนำไปใช้กับวงจรชีวิตการพัฒนาของคุณได้ สำหรับข้อมูลเพิ่มเติม โปรดดู Microsoft Security Development Lifecycle

เครื่องมือ Defender for DevOps และ SAST (การทดสอบความปลอดภัยของแอปพลิเคชันแบบคงที่) รวมเป็นส่วนหนึ่งของ GitHub Advanced Security และ Azure DevOps เครื่องมือเหล่านี้ช่วยคุณติดตามคะแนนความปลอดภัยสำหรับองค์กรของคุณได้

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

รายการตรวจสอบความปลอดภัย

โปรดดูชุดคำแนะนำทั้งหมด

รายการตรวจสอบความปลอดภัย