กรอบการบริหารจัดการ API: เมทริกซ์การควบคุมเชิงปฏิบัติสำหรับองค์กร

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

รายละเอียดการดำเนินงานนั้นคือความแตกต่างระหว่างเอกสารการกำกับดูแลและระบบการกำกับดูแล

คู่มือนี้ให้กรอบการทำงานเชิงปฏิบัติสำหรับโปรแกรม API ขององค์กร ซึ่งประกอบด้วย:

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

หากคุณต้องการคำจำกัดความที่กว้างขึ้น, กรณีธุรกิจ, ตัวชี้วัด และหมวดหมู่เครื่องมือก่อนอื่น ให้เริ่มต้นด้วย API Governance คืออะไร? บทความนี้จะเริ่มต้นด้วยการนำไปใช้จริง

กรอบการกำกับดูแล API คืออะไร?

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

กรอบการทำงานที่สมบูรณ์ควรตอบคำถามเจ็ดข้อ:

1. ผลลัพธ์: เรากำลังพยายามปกป้องผลลัพธ์ทางธุรกิจ, ผู้บริโภค, ความปลอดภัย หรือการดำเนินงานใด?
2. ขอบเขต: API, ทีม, สภาพแวดล้อม และขั้นตอนวงจรชีวิตใดบ้างที่ครอบคลุม?
3. สิทธิ์ในการตัดสินใจ: ใครเป็นผู้กำหนดเกณฑ์มาตรฐาน, เป็นเจ้าของ API แต่ละตัว, อนุมัติข้อยกเว้น และแก้ไขข้อค้นพบ?
4. ความเสี่ยง: API ใดต้องการการควบคุมที่เข้มงวดกว่า และเพราะเหตุใด?
5. การควบคุม: ทีมต้องทำอะไร และการควบคุมควรรูปแบบการแนะนำ, เตือน, บล็อก หรือต้องมีการตรวจสอบ?
6. หลักฐาน: องค์กรจะทราบได้อย่างไรว่าการควบคุมทำงาน?
7. การปรับปรุง: การวัดผลใดที่แสดงว่าการกำกับดูแลช่วยลดความเสี่ยงโดยไม่ส่งผลกระทบต่อการส่งมอบ?

ไม่มีมาตรฐานการกำกับดูแล API สากลเดียวที่ทุกบริษัทสามารถคัดลอกได้โดยไม่เปลี่ยนแปลง กรอบการทำงานต้องสะท้อนสถาปัตยกรรม, ผู้บริโภค, ข้อมูล, โมเดลการปรับใช้, บริบทด้านกฎระเบียบ และความเสี่ยงที่องค์กรยอมรับได้ ข้อมูลอ้างอิงภายนอกสามารถให้ข้อมูลได้: OpenAPI Specification กำหนดรูปแบบสัญญา API ที่เครื่องอ่านได้; OWASP API Security Top 10 ให้ข้อมูลความเสี่ยงด้านความปลอดภัย; และ NIST Cybersecurity Framework ให้โมเดลที่กว้างขึ้นสำหรับการกำกับดูแล, บทบาท, นโยบาย, ความเสี่ยง และการกำกับดูแล ไม่มีแหล่งข้อมูลใดที่สามารถมาแทนที่การเป็นเจ้าของและการตัดสินใจเฉพาะขององค์กรได้

กรอบการกำกับดูแล API เจ็ดชั้น

ให้ถือว่ากรอบการทำงานนี้เป็นเจ็ดชั้นที่เชื่อมโยงกัน แทนที่จะเป็นเอกสารนโยบายที่ยาวเหยียด

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

1. กำหนดผลลัพธ์และขอบเขตก่อนเขียนนโยบาย

เริ่มต้นด้วยชุดผลลัพธ์เล็กๆ ที่ผู้บริหาร, ทีมแพลตฟอร์ม และทีมส่งมอบสามารถรับรู้ได้ ตัวอย่างเช่น:

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

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

กำหนดขอบเขตที่ชัดเจน

จัดทำเอกสารสิ่งที่กรอบการทำงานครอบคลุม:

• REST, GraphQL, gRPC, API ที่ขับเคลื่อนด้วยเหตุการณ์ หรือประเภทอินเทอร์เฟซอื่นๆ;
• API ภายใน, พันธมิตร, สาธารณะ และบุคคลที่สาม;
• การออกแบบ, การพัฒนา, การเผยแพร่, การดำเนินงาน, การเปลี่ยนแปลง, การเลิกใช้ และการยกเลิก;
• สัญญา API, เอกสารประกอบ, การทดสอบ, ที่เก็บข้อมูล, ข้อมูลประจำตัว และพื้นที่ทำงานร่วมกัน;
• เกตเวย์รันไทม์, ระบบระบุตัวตน, บันทึก, การสังเกตการณ์ และกระบวนการจัดการเหตุการณ์;
• เฉพาะ API ใหม่ หรือทั้ง API ใหม่และ API ที่มีอยู่

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

2. เลือกโมเดลการดำเนินงานและกำหนดสิทธิ์ในการตัดสินใจ

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

องค์กรขนาดใหญ่ส่วนใหญ่ต้องการโมเดลแบบสหพันธ์:

• แพลตฟอร์ม API กลางหรือกลุ่มที่ส่งเสริมการใช้งานเป็นเจ้าของเกณฑ์มาตรฐานขององค์กร, เทมเพลตที่ใช้ร่วมกัน, เครื่องมือทั่วไป และการรายงานโปรแกรม;
• ผู้ดูแลโดเมนแปลเกณฑ์มาตรฐานให้เป็นแนวทางเฉพาะโดเมนและช่วยให้ทีมนำไปใช้;
• เจ้าของผลิตภัณฑ์ API ยังคงรับผิดชอบต่อ API แต่ละตัวและผลลัพธ์ของผู้บริโภค;
• ผู้เชี่ยวชาญด้านความปลอดภัย, ความเป็นส่วนตัว, IAM, SRE และการปฏิบัติตามข้อกำหนดเป็นเจ้าของหรือตรวจสอบการควบคุมในโดเมนของตน;
• ทีมส่งมอบดำเนินการควบคุมและแก้ไขข้อค้นพบ;
• เจ้าของความเสี่ยงที่กำหนดไว้อนุมัติข้อยกเว้นที่มีกรอบเวลา

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

รวมศูนย์, สหพันธ์ หรือกระจายอำนาจ?

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

แผนผัง RACI การกำกับดูแล API ที่ใช้งานได้จริง

ใช้บทบาทแทนชื่อบุคคล เพื่อให้โมเดลยังคงอยู่แม้จะมีการเปลี่ยนแปลงองค์กร

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

3. ทำรายการ API และกำหนดระดับความเสี่ยง

คุณไม่สามารถนำกรอบการทำงานไปใช้กับพอร์ตโฟลิโอที่ไม่รู้จักได้ อย่างน้อยที่สุด ให้บันทึก:

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

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

ตัวอย่างโมเดลสามระดับ

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

4. สร้างไลบรารีการควบคุมที่มีเวอร์ชัน

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

ตัวอย่างเช่น:

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

โดเมนการควบคุมหลัก

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

5. เลือกโหมดการควบคุมที่เหมาะสม: แนะนำ, เตือน, บล็อก หรือทบทวน

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

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

ก่อนที่จะบล็อก ให้ยืนยันว่า:

1. กฎมีเจ้าของที่ระบุชื่อและเหตุผลที่จัดทำเป็นเอกสาร;
2. การตรวจสอบสามารถระบุได้อย่างเพียงพอสำหรับความเสี่ยงที่ตั้งใจไว้;
3. ทีมได้รับคำอธิบายที่ชัดเจนและตัวอย่างที่สอดคล้อง;
4. การแก้ไขมีอยู่ในเวิร์กโฟลว์ปกติ;
5. มีเส้นทางข้อยกเว้นและมีเป้าหมายการตอบสนอง;
6. องค์กรสามารถวัดผลบวกปลอม, การข้าม และผลกระทบต่อการส่งมอบได้

6. สร้างเมทริกซ์การควบคุมการกำกับดูแล API

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

อย่างน้อยที่สุด ให้รวมถึง:

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

ตัวอย่างเมทริกซ์การควบคุมการกำกับดูแล API

ตัวอย่างนี้เป็นจุดเริ่มต้น ไม่ใช่รายการตรวจสอบการปฏิบัติตามข้อกำหนดสากล