วิธีเพิ่ม Doconut ให้กับแอปพลิเคชัน .NET ที่คำนึงถึงความปลอดภัย

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

บทความของ Doconut เกี่ยวกับ แนวปฏิบัติการดูเอกสารอย่างปลอดภัย อธิบายการเรนเดอร์ฝั่งเซิร์ฟเวอร์เป็นหนึ่งในชั้นของการออกแบบแบบ defense-in-depth. ดังนั้นบทความนี้จึงมุ่งเน้นที่ความรับผิดชอบของแอปพลิเคชันรอบ ๆ Doconut และชี้ให้รายละเอียดการนำไปใช้ไปยังเอกสารผลิตภัณฑ์ที่ได้รับการดูแล

---

เริ่มต้นด้วยโมเดลภัยคุกคาม

“Private” และ “secure” ไม่ได้เป็นการตั้งค่า. ให้กำหนดเหตุการณ์ที่คุณต้องการป้องกันหรือค้นพบก่อนเลือกการควบคุม

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

จัดลำดับความสำคัญของความเสี่ยงตามเอกสารและผู้ใช้ในระบบของคุณ. ห้องสมุดโบรชัวร์สาธารณะและพอร์ทัลหลักฐานทางกฎหมายไม่ควรใช้แนวนโยบายเดียวกันเพียงเพราะใช้ตัวดูเดียวกัน.

กรณีการตรวจสอบเอกสารทางกฎหมาย ของ Doconut เป็นแหล่งอ้างอิงที่มีประโยชน์สำหรับบทบาทของผลิตภัณฑ์ภายในกระบวนการทำงานที่ได้รับการรับรองของคดี, สัญญา, หลักฐาน, และการปฏิบัติตาม. มันยังย้ำขอบเขตสถาปัตยกรรม: สิทธิ์, การจัดเก็บ, บันทึกของลูกค้า, และกฎธุรกิจยังคงอยู่ใกล้กับแอปพลิเคชันโฮสต์.

อนุญาตก่อนเปิดเอกสาร

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

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

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

แยกตัวดูออกจากนโยบายการจัดเก็บ

ตัวดูไม่ควรกำหนดระยะเวลาการเก็บรักษาของคุณ. เอกสารแต่ละคลาสการจัดเก็บและเจ้าของ:

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

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

ใช้อ้างอิงระยะสั้นอย่างระมัดระวัง

อ้างอิงระยะสั้นสามารถลดเวลาที่ใช้ในการรีเพลย์, แต่ไม่สามารถแทนที่การอนุญาตได้. หากการออกแบบของคุณใช้เส้นทางที่ลงนามหรือโทเคนเซสชัน:

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

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

เข้าใจว่าการควบคุมฝั่งไคลเอนต์ทำอะไรได้และไม่ได้

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

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

อย่าแปลงคุณลักษณะของผลิตภัณฑ์ให้เป็นข้ออ้างการปฏิบัติตาม

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

สำหรับการประเมิน GDPR, เอกสารอย่างน้อย:

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

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

เพิ่มหัวข้อความปลอดภัยและกฎแคช

สำหรับเส้นทางพรีวิวที่ต้องยืนยันตัวตน, ประเมิน Content Security Policy ที่เข้มงวด, นโยบายเฟรม, การป้องกัน MIME‑sniffing, และนโยบาย referrer. หากพรีวิวปรากฏภายใน iframe, ระบุแหล่งที่มาของพาเรนท์ที่ตั้งใจอย่างชัดเจน.

เลือกหัวข้อแคชตามความอ่อนไหวและเส้นทางการเรนเดอร์. no-store อาจเหมาะกับบางการตอบสนอง, แต่ก็อาจส่งผลต่อประสิทธิภาพและไม่ลบเนื้อหาที่ถูกจับไว้แล้ว. ทดสอบพฤติกรรมของเบราว์เซอร์, พร็อกซี่, และ CDN แทนการพึ่งพาหัวข้อเดียวในแยกส่วน.

บันทึกการตัดสินใจ, ไม่ใช่ความลับ

เหตุการณ์ตรวจสอบที่มีประโยชน์อาจประกอบด้วย:

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

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

ตรวจสอบกระบวนการทั้งหมด

การทดสอบความปลอดภัยควรรวมกรณีเชิงลบ:

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

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

สรุป

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