חשיבות אבטחת המידע בפיתוח מערכת ארכיב דיגיטלי.

מאת: רונן כהן צמח מנכ"ל קבוצת ארכיביון ומומחה בתחום אבטחת המידע.

מתוך ילקוט מאמרים: מאמר מספר 20

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

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

מנקודת המבט של מנהל צוות פיתוח התוכנה שלנו , יש להתייחס לפיתוח ארכיב דיגיטלי כאל פרויקט הדורש רמת הקשחה ועמידה בתקני אבטחת מידע בדומה למערכות בנקאיות או ממשלתיות.
הרגולציה המחייבת בפרויקט זה היא תקנות  GDPR האירופיות להגנת פרטיות, ולכן עקרונות של Privacy by Design  הגנת פרטיות בשלב התכנון מיושמים כבר מהשלבים הראשונים של האיפיון.
העבודה בסביבה של טכנולוגיות Microsoft מסייעת להישען על מתודולוגיות ותקני אבטחה מוכרים של החברה, כדוגמת Security Development Lifecycle SDL של מיקרוסופט, המשולבים בתהליך.
נהלי אבטחה קפדניים ומדיניות ארגונית ברורה יבטיחו עמידה בדרישות חוק ורגולציה, הגנה מפני שינוי או אובדן מידע, שמירה על אותנטיות החומרים הדיגיטליים ומתן אפשרות לבקרת שינויים מלאה.

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

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

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

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

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

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

תהליך הפיתוח : משלבי האיפיון עד ההשקה

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

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

שלב א': איסוף דרישות ואפיון ראשוני

בשלב הפתיחה מנהל המוצר שלנו וצוות האיפיון נפגשים עם הלקוח כדי להבין את הצרכים העסקיים והדרישות התפעוליות של מערכת הארכיב הדיגיטלי.
כבר בשיחות הראשונות על הדרישות, מעלים שאלות קריטיות של אבטחת מידע: איזה סוג מידע יישמר בארכיב? מי יהיו המשתמשים המורשים לצפות בו או לעדכן אותו? האם נדרש שימוש בחתימה דיגיטלית על המסמכים המאוחסנים לצורך אימות חוקי?
הצוות מברר גם דרישות רגולטוריות – למשל, עמידה ב־ GDPR בכל הנוגע לשמירת מידע אישי, תקופות שמירה ומחיקה, הצפנה של מידע רגיש בעת מנוחה at rest ובהעברה in transit, ועוד.
על סמך השיחות הללו מכינים אפיון ראשוני שמתאר את פונקציונליות הליבה של המערכת, את דרישות האבטחה המרכזיות כגון : הצורך במנגנון הרשאות מפורט, תיעוד פעולות משתמשים לצורכי ביקורת, ותמיכה בחתימה דיגיטלית על מסמכים, ואת גבולות הגזרה של הפרויקט.
האיפיון הראשוני הזה עובר לעיון ואישור הלקוח, כדי לוודא שהבנת הדרישות הדדית ומדויקת.

שלב ב': עיצוב המערכת ותכנון ארכיטקטורה מאובטחת

בשלב הבא, צוות הארכיטקטורה ומעצבי המערכת שכולל גם מעצב UX/UI לצורך חוויית משתמש, במקרה הצורך לוקחים את הדרישות ומגבים אותן בעיצוב מערכת מפורט.
ארכיטקט התוכנה מתכנן את המרכיבים השונים של מערכת הארכיב הדיגיטלי – למשל, מודול לניהול מסמכים וקבצים, מודול ניהול משתמשים והרשאות, רכיב חתימה דיגיטלית המאשר חתימה ואימות של מסמכים, וממשקים למערכות אחרות אם ישנן.
הצוות שואל את עצמו שאלות כגון: היכן עלולים נתונים רגישים לדלוף? איך נוודא שהמערכת מתגוננת מפני התקפות SQL Injection, XSS או מתקפות אחרות הידועות לפי עקרונות OWASP 

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

שלב ג': תכנון פרויקט, צוותים ולוחות זמנים

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

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

שלב ד': פיתוח ובנייה בסביבת פיתוח מאובטחת

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

שלב ה': בדיקות תוכנה ואבטחת איכות QA פנימיות

לאחר השלמת הקידוד, צוות בקרת האיכות QA מבצע סדרת בדיקות מקיפה על המערכת בסביבת הבדיקות.
סביבת בדיקות זו משקפת ככל האפשר את סביבת הייצור המתוכננת, תוך שימוש באותן הגבלות אבטחה למשל, עדיין ללא חיבור חופשי לאינטרנט, שימוש בהרשאות כפי שיגדרו במציאות, וכו'.
הבודקים מריצים תרחישי שימוש עסקיים כדי לוודא שהמערכת עומדת בכל הדרישות התפקודיות: הוספת מסמכים לארכיב הדיגיטלי, שליפה וחיפוש מידע, ניהול משתמשים, הגדרת הרשאות על תיקיות ומסמכים, וכן תהליך חתימה דיגיטלית על מסמך ובדיקת החתימה.
במקביל, מבוצעות בדיקות עומס ועמידה בזמינות – מוודאים שהארכיב הדיגיטלי יכול לטפל בכמות גדולה של מסמכים ומשתמשים ללא ירידה בביצועים, ושהמערכת נשארת יציבה גם תחת עומסים חריגים.
מנקודת מבט אבטחתית, ה־QA  בודק תרחישי קצה של הרשאות: מוודאים שמשתמש ללא הרשאה לא יכול לצפות במסמך חסוי, או שמשתמש בעל תפקיד מסוים לא יכול למחוק מידע באופן שאינו מורשה.
מתבצעות גם בדיקות ידניות ואוטומטיות לזיהוי פרצות אבטחה נפוצות – למשל, ניסיון להזין סקריפטים בשדות קלט בדיקת XSS, ניסיון להעלות קובץ זדוני לארכיב, ובחינת התגובה של המערכת.
כל תקלת תוכנה או ליקוי אבטחה שמתגלים בשלב הבדיקות מתועדים במערכת ניהול תקלות, ומועברים חזרה למפתחים לתיקון במסגרת תהליך לולאתי של בדיקה תיקון בדיקה עד לקבלת תוצאה משביעת רצון.
בסיום שלב זה, המערכת אמורה להיות יציבה, נכונה תפקודית, וללא בעיות אבטחה ידועות.

שלב ו': בדיקות אבטחה חיצוניות ובדיקות קבלה

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

שלב ז': פריסה לסביבת ייצור והשקת המערכת

בשלב האחרון, צוות ה־DevOps  והתשתיות מבצע את הפריסה Deployment של מערכת הארכיב הדיגיטלי לסביבת הייצור.
סביבת הייצור עצמה כבר מוכנה ומאובטחת: שרתי היישום ומסדי הנתונים מוקשחים כלומר, הוגדרו בהתאם להנחיות אבטחה מחמירות – למשל ביטול שירותים לא נחוצים, שימוש בתצורות הצפנה עדכניות, הגבלת הגישה הפיזית לשרתים.
לאחר ההעלאה לאוויר, מבוצעים בדיקות קצרות לוודא שהפריסה עברה בהצלחה Smoke Tests – למשל בדיקה שמסמכים נטענים ונשלפים כראוי, שמשתמש יכול לחתום דיגיטלית על מסמך ושצד הלקוח מציג את הנתונים כנדרש.
הגרסה שנפרסה מסומנת כגרסת Production ומוכרזת כזמינה לשימוש הלקוחות. הלקוחות משתמשי המערכת בארגון מקבלים הדרכה ראשונית על השימוש במערכת, עם דגש על נוהלי אבטחה: הסבר על החשיבות של שמירת סודיות אישורי הגישה, חתימה דיגיטלית על מסמכים לפי הנהלים, ודיווח מיידי על כל אירוע אבטחה או תקלה חריגה.
במקביל, מוגדרים מנגנוני ניטור בזמן אמת על סביבת הייצור – ניטור תעבורה חריגה, ניסיונות גישה כושלים, ניטור עומסים – כדי לאפשר איתור התנהגויות חשודות לאחר ההשקה.
צוות הפיתוח נשאר בכוננות בתקופה הראשונה לאחר ההשקה Hypercare לטיפול בתקלות דחופות אם תצוצנה, ובפרט לוודא שלא מתגלות פרצות אבטחה בלתי צפויות בזמן אמת.

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

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

סיכום

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