כיצד להוסיף את Doconut ליישום .NET מודע לאבטחה

Doconut Viewer הופך לחלק מגבול האבטחה של היישום שלך ברגע שהוא מציג חוזים, חשבוניות, שרטוטים הנדסיים או רשומות לקוחות. Doconut מספק את שכבת הצפייה; היישום הסביבתי עדיין צריך להחליט מי רשאי לפתוח קובץ, היכן מאוחסן המקור, כמה זמן הנתונים המופקים נשארים זמינים, ומה נרשם לצורך חקירה.

המאמר של Doconut על שיטות צפייה מאובטחות במסמכים מתאר רינדור בצד השרת כשכבה אחת בעיצוב הגנה בעומק. לכן מאמר זה מתמקד באחריות היישום סביב Doconut ומפנה את פרטי היישום לתיעוד המוצר המתוחזק.

---

התחילו עם מודל אי‑איום

„פרטי” ו‑„מאובטח” אינם תצורות. הגדרו את האירועים שעליכם למנוע או לאתר לפני בחירת הבקרות.

סיכון	דוגמה	בקרת יישום
גישה בלתי מורשית	משתמש משנה מזהה מסמך ב‑URL	אימות הרשאות ברמת האובייקט בכל בקשה
חציית שכירות	משתמש תקף מבקש קובץ של לקוח אחר	היקף השוכר נכלל בהחלטת ההרשאה
חשיפת מקור	נתיב אחסון או קובץ מקורי מוחזרים ישירות	תהליך חיפוש ורינדור מבוקר על‑ידי השרת
גישה מיושנת	קישור נשאר שמיש לאחר שינוי תפקיד או מקרה	חיי סשן קצרים יחד עם אימות הרשאה מחדש
שמירה מופרזת	קלט או פלט זמני מצטבר	משימות מחזור חיים מפורשות עם תוצאות ניתנות לצפייה
רישום רגיש	אסימונים או מיקומי קבצים מופיעים ברשומות	הסתרה מובנית וטלמטריה של מזהים בלבד

סדרו את הסיכונים לפי המסמכים והמשתמשים במערכת שלכם. ספריית עלונים ציבורית ופורטל ראיות משפטיות לא צריכים לשתף את אותה מדיניות רק בגלל שהם משתמשים באותו מציג.

ה‑מקרה שימוש לבחינת מסמכים משפטיים של Doconut הוא ייחוס מועיל לתפקיד המוצר בתוך תהליכי מקרה, חוזה, ראיות וציות מאומתים. הוא גם מחזק את גבול האדריכלות: הרשאות, אחסון, רשומות לקוחות וכללי עסק נותרים קרובים ליישום המארח.

הרשאה לפני פתיחת המסמך

בצעו אימות והרשאת אובייקט לפני פתיחת המסמך עם Doconut. המדריך הרשמי ל‑הגדרת .NET 6 ומעלה מציג כיצד המציג מוגדר וכיצד נפתח מסמך בצד השרת; הציבו את זהות היישום שלכם, השוכר ובדיקות ההרשאות למסמך לפני שלב המוצר הזה.

חזרו על אותו כלל הרשאה עבור כל פעולה קשורה שהיישום שלכם מציג, כולל דפים, תמונות ממוזערות, חיפוש, הערות, המרה, הורדה והדפסה. הסתרת כפתור אינה מגנה על הבקשה הבסיסית.

הימנעו מקבלת נתיב מערכת קבצים, מפתח אחסון או URL מרוחק ישירות מהדפדפן. המירו מזהה מסמך בבעלות היישום למיקום האחסון שלו בשרת, ולאחר מכן אשרו שהאובייקט המומר שייך לשוכר המורשה ולזרימת העבודה.

הפרידו את המציג ממדיניות האחסון

המציג לא צריך להגדיר את תקופת השמירה שלכם. תעדו כל מחלקת אחסון ובעלים:

• מסמך מקור — נשלט על‑ידי מדיניות התוכן או הרישומים הראשית שלכם.
• קבצים זמניים לעבודה — נוצרו לעיבוד ומוסרים על‑ידי מחזור חיים מתוזמן ונצפה.
• דפים מרונדרים או מטמונים — מוגדרים לתקופת חיים מינימלית שימושית ומוגנים כמו המקור.
• ייצוא וקבצים מוכנים להדפסה — נוצרו רק כאשר למשתמש יש את ההרשאה המתאימה.
• רשומות ואירועי ביקורת — מכילים מזהים ותוצאות, ולא תוכן מסמך או אישורים.

הצפנה במעבר ובמנוחה תלויה בשרת האינטרנט שלכם, ספק האחסון, ניהול המפתחות והגדרות הפריסה. אמתו את הבקרות הללו בסביבה האמיתית; אל תסיקו אותן מנוכחות ספריית מציג.

השתמשו בהתייחסויות קצרות חיים בזהירות

התייחסות קצרה יכולה לצמצם את זמן האפשרות לשחזור, אך אינה מחליפה הרשאה. אם העיצוב שלכם משתמש במסלול חתום או בטוקן סשן:

1. קשרו אותה למסמך אחד ולפעולה המיועדת.
2. העניקו לה חיי חיים קצרים בהתאם לזרימת העבודה.
3. הימנעו מהצבת טענות רגישות או מיקומי אחסון בטקסט גלוי.
4. אמתו מחדש את ההרשאה עבור פעולות מיוחדות.
5. הגדירו מה משמעות הביטול לפני זמן הפקיעה הטבעי.
6. החזיקו את הטוקנים מחוץ לניתוחים, מפנים, הודעות שגיאה וצילומי מסך.

כאשר סשן דפדפן פג, הציגו הודעה נייטרלית והציעו דרך בטוחה לאימות מחדש. אל תחשפו האם שוכר אחר הוא בעל המסמך.

הבינו מה שליטה בצד הלקוח יכולה ולא יכולה לעשות

הסרת בקרות הורדה או הדפסה יכולה לשפר את זרימת העבודה המיועדת, אך אינה ערובה לסודיות. משתמש שיכול לראות תוכן עדיין יכול לצלם את המסך, לצלם אותו בתמונה, או להשתמש ביכולות הדפדפן מחוץ למציג.

התייחסו למגבלות בצד הלקוח כאמצעי שימושיות והרתעה. שליטה חזקה יותר נובעת מהשארת קבצי המקור מאחורי השרת, יישום הרשאות על כל בקשה קשורה, הגבלת ייצוא, ושימוש במי‑watermarks נראים כאשר המדיניות שלכם דורשת זאת.

אל תהפכו תכונות מוצר לטענות ציות

הצייתנות הרגולטורית תלויה במטרה, קטגוריות הנתונים, בסיס חוקי, חוזים, עיבוד אזורי, שמירה, תגובה לאירועים, ונהלים ארגוניים. מציג יכול לתמוך בעיצוב צייתני, אך הוא אינו הופך יישום לצייתן בפני עצמו.

להערכת GDPR, תעדו לפחות:

• היכן מקבצי המקור והמופקים מעובדים ומאוחסנים
• מי משמש כבקר ומעבד עבור כל שירות
• אילו תתי‑מעבדים והעברות מעורבות
• כיצד בקשות מחיקה מגיעות לכל מחלקת אחסון ולמדיניות הגיבוי
• אילו אירועים נרשמים וכמה זמן הרשומות זמינות
• כיצד מתבצעות סקירות גישה ותגובה לאירועים

הביאו בעלי עניין בפרטיות ובמשפט לאמת את ההחלטות הללו עבור הפריסה שלכם.

הוסיפו כותרות אבטחה וכללי מטמון

לנתיבי תצוגה מקודדים, העריכו מדיניות אבטחת תוכן (CSP) מגבילה, מדיניות מסגרות, הגנה מפני ניחוש MIME, ומדיניות מפנה. אם התצוגה מופיעה בתוך iframe, ציינו במפורש את מקורות ההורה המיועדים.

בחרו כותרות מטמון בהתאם לרגישות ולנתיב הרינדור. no-store עשויה להיות מתאימה לתגובות מסוימות, אך היא יכולה להשפיע על הביצועים ולא למחוק תוכן שכבר נלכד במקום אחר. בדקו את התנהגות הדפדפן, הפרוקסי ו‑CDN במקום להסתמך על כותרת לבד.

רשמו החלטות, לא סודות

אירוע ביקורת שימושי עשוי לכלול:

• מזהי משתמש ושוכר
• מזהה המסמך
• הפעולה המבוקשת
• תוצאת ההרשאה
• חותמת זמן ומזהה קורלציה
• תוצאה של שמירה או ניקוי

הימנעו מרישום אסימונים גולמיים, מחרוזות שאילתה, URL‑ים של אחסון, שמות מסמכים המכילים נתונים אישיים, או טקסטים שהוצאו. הגנו על יומני הביקורת משינויים והגבילו גישה לצוותים הזקוקים להם.

אמתו את הזרימה המלאה

בדיקות האבטחה צריכות לכלול מקרים שליליים:

• שינוי מזהה המסמך תוך שמירה על אימות.
• שימוש חוזר ב‑URL תצוגה ממשתמש או שוכר אחר.
• קריאה ישירה לנקודות הקצה של דף, תמונה ממוזערת, הדפסה וייצוא.
• פג תוקף הסשן במהלך תצוגה ארוכה.
• הסרת הרשאת משתמש בזמן שהמסמך פתוח.
• שליחת קלט לא נתמך, גדול מדי, פגום או מוגן בסיסמה.
• אימות שמשרות ניקוי מסירות נתונים מתאימים ומדווחות על כשלונות.
• בדיקת יומנים, ניתוחים, ודפי שגיאה עבור ערכים רגישים.

אוטומטו את המקרים היציבים ושמרו על סקירה ידנית עבור תצורת האחסון, מדיניות הדפדפן ושינויים בגרסת המציג.

סיכום

אינטגרציה מודעת לאבטחה כוללת בעלות ברורה. Doconut מספקת את יכולת הצפייה במסמכים המתוארת בתיעוד הרשמי; היישום שלכם מספק אימות, הרשאה, בקרות אחסון, שמירה, ניטור ותגובה לאירועים. שמירת האחריות הזו באופן מפורש מייצרת שליטה חזקה יותר וטענות פרטיות כנות יותר.