חלק 5: בראשית לשחזור חשבונות - אבטחה תפעולית | פִּנקָס

עד כה, הראינו בחלק 1 ו-2, כיצד לדג'ר מתאושש מפצל את הזרע שלך למניות ו שולח את המניות הללו בצורה מאובטחת ל חברים ספקי גיבוי מהימנים. בחלק 3, הראינו איך זה מאחסן (ומשחזר) בבטחה את מניות הזרע שלך, מוגן על ידי הצפנת חומרה, קשור לזהות שלך ומגוונת. בחלק 4, חקרנו איך Ledger Recover מצליח לתת גישה לגיבוי שלך רק לך ולך.

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

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

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

הקשחת תשתיות

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

להלן סקירה של האמצעים העיקריים שלנו להקשיח את התשתית של Ledger Recover:

זמינות השירות

התשתית מתוכננת כך שיש אין נקודת כשל בודדת (NSPOF), כלומר המערכת עמידה בפני כשל של כל רכיב. ניקח את הדוגמה הבאה: מרכזי הנתונים שלנו מוגשים על ידי שני ספקי שירותי אינטרנט עצמאיים (ISP), בשני קצוות מנוגדים של הבניין. אם הסיב ניזוק עקב עבודות בנייה מתמשכות בחלק אחד של הבניין, הנתונים פשוט ינותבו דרך ספק האינטרנט השני. תחזוקה ללא הפרעות היא יתרון נוסף שמשפר את הזמינות. בהתחשב בכך שיש לפחות שני מופעים של כל רכיבי התוכנה של Ledger Recover, אנו יכולים להגדיר מחדש את המערכת כך שתשתמש רק במופע A תוך החלפה/שדרוג/תיקון מופע B.

גישת מנהל מוגבלת ליישומי Ledger Recover

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

מרכזי נתונים פיזיים מאובטחים

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

בידוד משאבי השחזור של Ledger

כל משאבי Ledger Recover מבודדים מכל משאב אחר בתוך ספקי השירות של Ledger Recover, כולל בתוך Coincover ו- Ledger. בידוד זה נחוץ כדי להבטיח שנוכל להכיל התקפות פוטנציאליות מפרוסת רשת אחת שמטרתה לנצל משאבים של פרוסות רשת אחרות.

אבטחה ברמת הקוד מובטחת באמצעות עמודים מרובים

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

בקרת תעבורה ברשת

תעבורת הרשת נשלטת באופן הדוק באמצעות מדיניות המגדירה כללים עבור זרימות תעבורה עבור כל 3 ספקי הגיבוי. על ידי הגדרת כללים לתעבורה מותרת ונמנעת, אנו מגבילים את משטח ההתקפה ומצמצמים את הסיכון לגישה לא מורשית. כמו כן, הגבלת התקשורת בין שירותים בודדים מבטיחה כי התנועה הצידית של התוקף מוגבלת, גם אם רכיב אחד נפגע. בנוסף, אנו מיישמים אימות TLS הדדי (mTLS) כדי למנוע התקפות Man-in-the-Middle (MiM). על ידי אימות הזהות של שני הצדדים באמצעות אישורים, TLS הדדי מבטיח זאת רק ישויות מהימנות יכולות ליצור חיבור מאובטח.

סיבוב מפתח

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

אבטחת תנועה יוצאת

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

אבטחת תנועה נכנסת

תעבורה נכנסת מוגנת על ידי שילוב של אנטי-DDoS, סינון יישומי אינטרנט (WAF) וטכניקות סינון IP. התקפות מניעת שירות מבוזרות (DDoS) גורמות נזק על ידי הצפת מערכת היעד שלהן בבקשות. הגבלת מספר הבקשות הנכנסות הוא אמצעי ידוע נגד התקפות כאלה. כעת, לא כל ההתקפות עוסקות בכמות, חלקן עוסקות באיכות. כאן נכנס לתמונה WAF. WAF מסתכל על בקשות נכנסות ו בודק את התנהגותם המיועדת: אם הבקשה מכוונת להשיג גישה לא מורשית או לתפעל נתונים, המסנן חוסם את הבקשה. לבסוף, סינון IP משתמש בטכניקה הכפולה של a) רישום לבן, כלומר, מאפשרים תעבורה רק מכתובות IP ספציפיות או טווחים, וב) החרמה, כלומר, חסימה תעבורה מכתובות IP ידועות של תוקפים.       

ניהול פגיעות

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

הפרדת תפקידים

הפרדת תפקידים היא הליבה של אסטרטגיית האבטחה של Ledger Recover. 

הפרדת התפקידים בין השונים ספקי גיבוי (חלק 3) ו ספק IDVs (חלק 4) תואר בפוסטים הקודמים. אתה אולי זוכר שיש:

• 3 מניות של ביטוי השחזור הסודי המנוהלים על ידי 3 ספקי גיבוי עצמאיים (עם גיוון מסד הנתונים למעלה כדי למנוע קנוניה)
• 2 נותני זהות עצמאיים (ספקי IDV)

ברמת התשתית, הפרדת תפקידים מוחל בין התפקידים השונים המעורבים בפיתוח ובתפעול של Ledger Recover.

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

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

ממשל: קוורום

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

למרות בדיקות הרקע החזקות שלנו עבור העובדים שלנו, העובדה היא שבני אדם יכולים להיות חוליה חלשה בכל מערכת, והקריפטוספירה אינה יוצאת דופן. אירועי אבטחה בפרופיל גבוה, כגון הפריצה ל-Mt. Gox של 2014, להדגים כיצד ניתן לנצל אנשים או להוביל לפסילות אבטחה. ניתן להשפיע או לכפות על אנשים באמצעות מניעים שונים - כסף, אידיאולוגיה, כפייה, אגו (aka, MICE(S)) - מה שהופך אפילו את בדיקות הרקע המחמירות ביותר ללא חסינות לחלוטין.

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

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

להלן כמה מהפעילויות שבהן אנו משתמשים במניינים:

1. הפקת המפתחות הפרטיים עבור Ledger Recover HSMs: פעולה קריטית זו מוגנת על ידי מניינים עצמאיים בתוך כל ישות - Coincover, EscrowTech ו- Ledger. כל אחד מחברי המניינים הנבדלים הללו חייב להיות נוכח כדי ליצור מפתחות פרטיים ב-HSM בהתאמה. לכל חבר במניין יש גישה למפתח גיבוי, שהוא חיוני לשחזור וחידוש סודות ה-HSM שלו במידת הצורך. מבנה זה לא רק מגן מפני הסיכון של כל אדם שיש לו השפעה בלתי הוגנת על אחד משלושת ה-HSMs של ספקי הגיבוי אלא גם משפר את שלמות המערכת הכוללת שכן כל מניין פועל באופן עצמאי ואינו מודע לפרטים הספציפיים של זה.

2. החלטה על שחרור חריג של נתח לקוח: מצבים ספציפיים, אם כי נדירים, עשויים לדרוש שחרור חריג של חלקו של הלקוח. אלה יכולים להיות בגלל כשלים באימות זהות (שינוי שם, עיוות פיזי וכו'), או אם אמצעי האבטחה הלא נחשפים שלנו רשימת מכשיר באופן שגוי. כאשר מתעורר מצב כזה, מתכנס מניין המורכב ממספר אנשים מספקי הגיבוי. הליך זה, המחייב הסכמה רחבה, מבטיח שהחלטות לא מתקבלות בחיפזון או באופן חד צדדי, ובכך מגביר את אבטחת הלקוחות. כל אחד מחברי המניין משתמש במכשיר Ledger Nano שלו (עם סיכה משלו) כדי לאשר את השחרור, ומוסיף שכבת אבטחה נוספת מפני קנוניה אפשרית או שגיאות בודדות.

3. חתימה על עדכון קוד קושחה של HSM: לפני פריסת עדכון קושחה חדש ל-HSMs, צוות אבטחת המוצר שלנו, Ledger Donjon, עורך תהליך סקירה מקיף. בהיותו חלק ממניין הקושחה, ה- Ledger Donjon מבטיח שלא הוכנסו דלתות אחוריות או קוד זדוני על ידי מקורב זדוני או צינור פיתוח שנפגע באמצעות התקפת שרשרת אספקה. כך הם שומרים על השלמות והאבטחה של עדכון הקושחה.

4. עדכון קוד קושחה של מכשירי Ledger (Nano & Stax): בדומה לקושחה עבור ה-HSMs, עדכונים לקושחה של מכשיר ה- Ledger שלנו עוברים תהליך בדיקה קפדני ודורשים אישור מניין לפני שהם מוצעים למשתמשים שלנו דרך Ledger Live.

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

ניטור רכיבים ופעולות קריטיות

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

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

הבה נחקור כמה דוגמאות לגישה הרב-שכבתית שלנו:

מעקב אחר פעילויות מנהל: אנו אוכפים בקרת גישה מחמירה עבור המנהלים שלנו. לא רק שאנו דורשים 2FA (אימות דו-גורמי) עבור כל החיבורים האדמיניסטרטיביים לתשתית שלנו, אלא שאנו גם מחייבים אימות מרובה אנשים עבור גישה לתשתית מנהלים בחלקים קריטיים של המערכת. יתר על כן, המערכות שלנו רושמות ועוקבות בקפדנות אחר כל פעילות ניהולית. יומנים אלה מוצלבים באופן אוטומטי עם מערכות הכרטוס הפנימיות שלנו כדי לזהות פעולות לא מתוכננות. מתאם זהיר זה מאפשר לנו להתריע מיידית על צוותי האבטחה שלנו על כל התנהגות חריגה או חשודה, ולחזק את האבטחה התפעולית שלנו.

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

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

מינוף מידע אבטחה וניהול אירועים (SIEM): פתרון SIEM מהווה חלק מכריע באסטרטגיית הניטור של Ledger Recover. SIEM ייעודי זה משפר את היכולת לזהות ולהגיב לבעיות אבטחה פוטנציאליות בזמן אמת. זה מותאם לזיהוי מגוון של אינדיקטורים של פשרה (IoCs) המבוססים על יומני אשכול ו- Ledger Recover, הודות לכללי זיהוי ספציפיים שפותחו במיוחד עבור שירות Ledger Recover. אם מזוהה IoC מותאם אישית, התגובה היא אוטומטית ומיידית - האשכול כולו ננעל עד לביצוע ניתוח יסודי. בשירות Ledger Recover יש עדיפות לסודיות על פני זמינות השירות כדי להבטיח את ההגנה המרבית על נכסי המשתמשים.

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

תגובת תקרית ספציפית לשחזור חשבונות

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

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

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

סיכום

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

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

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• PlatoData.Network Vertical Generative Ai. העצים את עצמך. גישה כאן.
• PlatoAiStream. Web3 Intelligence. הידע מוגבר. גישה כאן.
• PlatoESG. פחמן, קלינטק, אנרגיה, סביבה, שמש, ניהול פסולת. גישה כאן.
• PlatoHealth. מודיעין ביוטכנולוגיה וניסויים קליניים. גישה כאן.
• מקור: https://www.ledger.com/blog/part-5-genesis-of-ledger-recover-operational-security