หกการตัดสินใจที่ควรเขียนไว้ในสัญญาการเข้าถึงจากคลาวด์ถึงแบ็กเอนด์

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

ตัดสินใจเรื่องปฏิบัติการก่อนตัวเชื่อมต่อ

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

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

ตัดสินใจเรื่องตัวตนของภาระงาน และมอบเจ้าของให้

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

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

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

ตัดสินใจเรื่องขอบเขตเครือข่าย โดยรู้ว่ามันไม่ใช่สิทธิ์

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

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

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

ตัดสินใจเรื่องการจัดการข้อมูลและการแบ่งความรับผิดชอบ

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

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

ตัดสินใจเรื่องความล้มเหลว การถอน และวิธีที่คุณจะยอมรับ

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

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

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