WEBVTT

00:00:00.000 --> 00:00:01.460
דמיינו את התרחיש הבא.

00:00:01.540 --> 00:00:07.360
אתם בונים אפליקציה וזקוקים למפתח API כדי להתחבר לשירות, לסיסמת בסיס נתונים או למפתח של חשבון נכסון.

00:00:07.480 --> 00:00:11.380
אז אתם מכניסים אותו ישירות לקוד שלכם, אולי בקובץ הגדרות או במשתנה סביבה.

00:00:11.520 --> 00:00:16.580
זה עובד והקול רץ מצוין עד שאתם דוחפים את הקוד לג'יפאב או משתפים החברת עם חבר לצוות.

00:00:16.700 --> 00:00:19.140
וככה, הסוד שלכם כבר לא כל כך סודי.

00:00:19.280 --> 00:00:22.860
אם הקוד הזה נופל לידיים הלא נכונות, המערכת כולה נחשפת.

00:00:22.860 --> 00:00:26.040
ובכן, Azure Key Vault הוא הכלי שפותר את הבעיה הזו.

00:00:26.140 --> 00:00:29.620
הוא נותן לכם מקום מאובטח לשמור סודות כדי שלא יגיעו לעולם לקוד שלכם.

00:00:29.720 --> 00:00:31.760
אבל הנה הדבר שרוב האנשים טועים לגביו.

00:00:31.940 --> 00:00:35.060
עצם קיומו של Key Vault לא הופך אתכם למאובטחים באופן אוטומטי.

00:00:35.160 --> 00:00:39.080
הדרך שבה אתם מגדירים אותו, שולטים בגישה ומקצים הרשאות חשובה לא פחות.

00:00:39.180 --> 00:00:43.580
עד סוף הפרק הזה תדעו מהו Key Vault באמת, מה אפשר לשמור בו, איך הגישה עובדת,

00:00:43.580 --> 00:00:46.740
והטעות הגדולה ביותר שעלולה להשאיר את הסודות שלכם חשופים.

00:00:46.860 --> 00:00:50.120
הכל בשפה פשוטה, בלי מונחים מסובכים, רק המידע שאתם צריכים.

00:00:50.240 --> 00:00:51.980
אז מה זה בעצם Azure Key Vault?

00:00:52.180 --> 00:00:53.260
מהו Azure Key Vault?

00:00:53.440 --> 00:00:55.040
הנה ההגדרה הפשוטה ביותר.

00:00:55.160 --> 00:00:58.540
Azure Key Vault הוא כספת דיגיטלית מבוססת ענן עבור הסודות שלכם.

00:00:58.680 --> 00:01:02.400
זהו שירות מנוהל מבית מייקרוסופט למפתחות API, סיסמאות בסיס נתונים,

00:01:02.600 --> 00:01:05.600
מחרוזות חיבור, מפתחות הצפנה ותעודות במקום מרכזי אחד.

00:01:05.600 --> 00:01:09.780
אתם לא צריכים לדאוג לתשתית כי Azure מטפלת בידכונים, בזמינות ובאבטחה.

00:01:09.860 --> 00:01:11.020
אתם פשוט משתמשים בו.

00:01:11.140 --> 00:01:12.820
תחשבו על זה כמו על בניין משרדים.

00:01:13.000 --> 00:01:15.140
יש לכם עמדות עבודה, חדרי ישיבות וערונות טיוק,

00:01:15.340 --> 00:01:18.520
אבל אפשרו במרטף יש חדר כספת מאובטח שבו שומרים את הדברים החשובים.

00:01:18.660 --> 00:01:20.960
מפתחות ראשיים, מזומן, מסמכים משפטיים.

00:01:21.140 --> 00:01:23.100
אף אחד לא נכנס פנימה בלי אישור ואימות.

00:01:23.220 --> 00:01:25.660
ובכל פעם שמי שהוא פותח את הדלת, זה נרשם ביומן.

00:01:25.660 --> 00:01:29.800
זה ה-Key Vault, החדר המאובטח במרטף של ארכיטקטורת האז'ל שלכם.

00:01:29.920 --> 00:01:31.800
עכשיו, השבו זאת לדרך הישנה.

00:01:31.980 --> 00:01:34.700
לפני עשרים שנה, אם הייתם צריכים סיסמת בסיס נתונים,

00:01:34.960 --> 00:01:36.940
הייתם מקודדים אותה בקשיכות בקובץ הגדרות,

00:01:37.120 --> 00:01:38.960
אולי במשתנה סביבה, או גרוע מכך,

00:01:39.100 --> 00:01:40.780
משאירים אותה כטקסט גלוי בקוד המקור.

00:01:40.900 --> 00:01:43.320
אם מי שהוא השיג גישה לשרת ההוא, היה לו הכל.

00:01:43.460 --> 00:01:45.240
ואם הייתם צריכים לרענן את הסיסמה,

00:01:45.240 --> 00:01:47.060
הייתם צריכים לעדכן אותה בכל מקום.

00:01:47.060 --> 00:01:49.780
בכל קובץ הגדרות, בכל סביבה, בכל פריסה.

00:01:49.920 --> 00:01:50.660
זה היה סיוט.

00:01:50.840 --> 00:01:52.300
Key Vault משנה את כל זה.

00:01:52.480 --> 00:01:55.100
במקום לפזר סודות ברחבי הקוד וקובצי ההגדרות,

00:01:55.300 --> 00:01:56.840
אתם שומרים אותם במקום מרכזי אחד.

00:01:57.020 --> 00:02:00.420
האפליקציות שלכם מבקשות אותם בזמן הריצה רק כשהן זקוקות להם.

00:02:00.440 --> 00:02:02.100
ומכיוון שהכל מרוכז במקום אחד,

00:02:02.340 --> 00:02:03.920
ניתן להחליף סוד במקום אחד בלבד.

00:02:03.920 --> 00:02:07.240
וכל אפליקציה שמשתמשת בו תמשוך את הערך החדש באופן אוטומטי,

00:02:07.360 --> 00:02:08.960
ללא שינויי קוד או פריסות מחדש.

00:02:08.960 --> 00:02:12.540
אבל העניין הוא ש-Key Vault אינו רק מנהל סיסמאות עבור האפליקציות שלך.

00:02:12.720 --> 00:02:14.160
זהו שירות הבטחה מרכזי.

00:02:14.260 --> 00:02:16.280
כל שירות ב-Azure יכול להשתלב איתו.

00:02:16.400 --> 00:02:22.280
App Service, Functions, AKS, Data Factory, Synapse, Logic Apps וצינורות DevOps כולם יודעים לתקשר עם Key Vault.

00:02:22.420 --> 00:02:25.300
הוא הופך לעמוד הסדרה של ארכיטקטורת הענן המאובטחת שלך.

00:02:25.300 --> 00:02:29.040
וברגע שמגדירים אותו נכון, מפסיקים לחלוטין לחשוב על ניהול אישורים.

00:02:29.180 --> 00:02:30.220
מה ניתן להחסן בו?

00:02:30.220 --> 00:02:34.340
עכשיו, כשאתה יודע מהו Key Vault, בוא נדבר על מה שבאמת ניתן לשים בתוכו.

00:02:34.460 --> 00:02:38.080
ישנן שלוש קטגוריות עיקריות, סודות, מפתחות ותעודות.

00:02:38.240 --> 00:02:42.800
לכל אחת תפקיד שונה, והבנת ההבדלים תעזור לך להשתמש ב-Key Vault בצורה הנכונה.

00:02:42.940 --> 00:02:43.820
נתחיל בסודות.

00:02:44.000 --> 00:02:46.160
זהו הפריט הנפוץ ביותר שאנשים מאחסנים.

00:02:46.160 --> 00:02:49.260
סודות הם אחרוזות חיבור, מפתחות API, סיסמאות למסעד נתונים,

00:02:49.260 --> 00:02:54.000
מפתחות לחשבונות איחסון, בעיקרון כל אישורי הגישה היומיומיים שהאפליקציות שלך צריכות כדי לתקשר עם שירותים אחרים.

00:02:54.160 --> 00:02:57.660
במקום להכניס אותם לקוד או לקובץ ההגדרות, אתה מאחסן אותם ב-Key Vault.

00:02:57.860 --> 00:03:01.280
האפליקציה שלך מושכת אותם בזמן הריצה, ואף אחד לא רואה אותם בטקסט גלוי.

00:03:01.440 --> 00:03:04.140
חשוב על זה כעל מגירה נעולה בארון הטיוק הדיגיטלי שלך.

00:03:04.140 --> 00:03:05.520
הבאים בתור הם מפתחות.

00:03:05.660 --> 00:03:07.920
אלו הם מפתחות הצפנה עבור נתונים במצב מנוחה.

00:03:07.920 --> 00:03:10.560
אם אתה משתמש במפתחות המנוהלים על ידי הלקוח עבור יחסון ב-Azure,

00:03:10.720 --> 00:03:13.120
מסדי נתונים של סיקוואל או הצפנת דיסקים של מכונות וירטואליות,

00:03:13.260 --> 00:03:14.640
המפתחות הללו יכולים לשכון ב-Key Vault.

00:03:14.820 --> 00:03:17.460
זה מעניק לך שליטה מלאה על מי יכול להשתמש בהם ומתי.

00:03:17.600 --> 00:03:20.080
ואם אתה זקוק למפתחות מבוססי חומרה עבור רגולציה,

00:03:20.320 --> 00:03:22.160
גרסת הפרימיום מציעה הגנת HSM.

00:03:22.160 --> 00:03:23.760
לאחר מכן יש לנו תעודות.

00:03:23.900 --> 00:03:26.160
תעודות TLS וSSL עבור אפליקציות האינטרנט,

00:03:26.160 --> 00:03:27.840
ה-API והשירותים הפנימיים שלך.

00:03:27.980 --> 00:03:30.240
Key Vault יכול להחסן אותן, לנהל את מחזור החיים שלהן,

00:03:30.360 --> 00:03:32.380
ואף לחדש אותן אוטומטית כשהן קרובות לפקיעת תוקף.

00:03:32.540 --> 00:03:34.560
זה מציל חיים עבור כל מי שחווה פעם תעודה

00:03:34.560 --> 00:03:37.020
שפג תוקפה בית מינוס 3 לפנות בוקר ביום ראשון.

00:03:37.160 --> 00:03:38.180
הנה דוגמה מעשית.

00:03:38.180 --> 00:03:41.520
דמיין שיש לך אפליקציית אינטרנט שזקוקה למחרוז את חיבור למסד נתונים

00:03:41.520 --> 00:03:43.160
ולמפתח API עבור שירות חיצוני.

00:03:43.300 --> 00:03:46.580
בדרך הישנה, היית מכניס את שניהם לקובץ הג'סון של הגדרות האפליקציה.

00:03:46.740 --> 00:03:49.140
סביר להניח שאם הקובץ הזה יגיע למאגר הקוד שלך,

00:03:49.340 --> 00:03:52.040
כל מי שיש לו גישה על הקוד יוכל לראות את אישורי מסד הנתונים שלך.

00:03:52.160 --> 00:03:54.700
בעזרת Key Vault, אתה מאחסן את שני הערכים כסודות.

00:03:54.860 --> 00:03:57.860
האפליקציה מושכת אותם בעת העלייה, והם לעולם לא מופיעים בקוד המקור שלך.

00:03:57.860 --> 00:03:59.720
צריך להחליף את סיסמת מסד הנתונים?

00:03:59.860 --> 00:04:00.960
עדכן אותה ב-Key Vault.

00:04:00.960 --> 00:04:04.120
האפליקציה תמשוך את הערך החדש באופן אוטומטי בהפעלה מחדש הבאה.

00:04:04.200 --> 00:04:06.000
ללא שינויי קוד, ללא פריסה מחדש.

00:04:06.140 --> 00:04:08.740
דבר אחד שתופס אנשים לא מוכנים הוא שניהול גרסאות מובנה בפנים.

00:04:08.900 --> 00:04:11.520
כאשר מעדכנים סוד, Key Vault לא דורס את הערך הישן.

00:04:11.640 --> 00:04:12.780
הוא יוצר גרסה חדשה.

00:04:12.940 --> 00:04:16.220
הגרסאות הישנות נשמרות, כך שניתן לחזור לאחור עם מה שהוא משתבש.

00:04:16.220 --> 00:04:18.520
זה שימושי להפליא בזמן אירועים חריגים.

00:04:18.640 --> 00:04:22.500
ניתן לחזור במהירות לסוד קודם מבלי לזכור מה היה הערך הישן.

00:04:22.660 --> 00:04:27.180
ניתן להחסן את כל שלושת הסוגים, סודות, מפתחות ותעודות, באותו כספת.

00:04:27.280 --> 00:04:29.940
אבל הדרך הטובה ביותר היא הפרדה לפי סביבות.

00:04:30.140 --> 00:04:33.540
החזיקו כספת אחת לפיתוח, אחת לבדיקות ואחת ליצור.

00:04:33.740 --> 00:04:37.880
זה מונע ממישהו להשתמש בטעות בסוד של סביבת ייצור בסביבת פיתוח,

00:04:37.880 --> 00:04:40.220
ומקביל את הנזק אם כספת אחת נפגעת.

00:04:40.260 --> 00:04:42.560
אבל יחסון סודות הוא רק חצי מהסיפור.

00:04:42.700 --> 00:04:44.940
השאלה האמיתית היא למי יש גישה עליהם?

00:04:45.060 --> 00:04:46.400
איך בקרת גישה עובדת?

00:04:46.400 --> 00:04:48.460
עכשיו, בואו נדבר על מי מקבל גישה.

00:04:48.600 --> 00:04:51.480
לכי וולט יש שתי דרכים שונות לשלוט בגישה לתוכן,

00:04:51.520 --> 00:04:53.020
והבחירה שלכם משמעותית מאוד.

00:04:53.180 --> 00:04:55.560
המודל הראשון הוא מדיניות גישה מדור קודם.

00:04:55.740 --> 00:04:56.740
זו הדרך הישנה.

00:04:56.940 --> 00:04:59.020
אתם יוצרים מדיניות ישירות על הכספת,

00:04:59.020 --> 00:05:02.640
ומקצים הרשאות למשתמשים או קבוצות ספציפיות עבור סוגי נתונים,

00:05:02.900 --> 00:05:04.360
סודות, מפתחות או תעודו.

00:05:04.560 --> 00:05:07.200
הבעיה היא שמדיניות זו קשורה ישירות לכספת.

00:05:07.360 --> 00:05:08.580
אם יש לכם מספר כספות,

00:05:08.580 --> 00:05:10.880
עליכם לנהל את המדיניות בכל אחת בנפרד.

00:05:11.040 --> 00:05:12.120
זה לא מתרחב היטב.

00:05:12.300 --> 00:05:14.520
מייקרוסופט ממליצה כעת לא להשתמש בהן,

00:05:14.560 --> 00:05:16.520
מכיוון שיש להן בעיות הבטחה ידועות.

00:05:16.620 --> 00:05:18.540
הן לא תומכות בניהול זהויות מועדפות,

00:05:18.620 --> 00:05:21.180
ויכולות ליצור נתיבי הסלמת הרשאות לא צפויים.

00:05:21.180 --> 00:05:23.120
המודל השני הוא Azure RBSC,

00:05:23.300 --> 00:05:24.780
בקרת גישה מבוססת תפקידים.

00:05:24.980 --> 00:05:26.040
זו הדרך המודרנית.

00:05:26.160 --> 00:05:27.700
היא משתמשת בזהויות של Enter ID,

00:05:27.700 --> 00:05:30.780
והיא עקבית לאופן שבו אתם מנהלים הרשאות בכל מקום אחר ב-Azure.

00:05:30.920 --> 00:05:34.540
אם אתם כבר יודעים איך לתת למישהו גישה לחשבון נחסון או למכונה וירטואלית,

00:05:34.720 --> 00:05:36.480
אתם כבר יודעים איך לתת גישה ל-Key Vault.

00:05:36.680 --> 00:05:38.360
אותה מערכת, אותם דפוסים.

00:05:38.540 --> 00:05:40.700
הנה כלל הזהב, הרשאות מינימליות.

00:05:40.700 --> 00:05:43.940
תנו רק את הגישה המינימלית שמישהו צריך, לא יותר מזה.

00:05:44.080 --> 00:05:45.680
אם מישהו צריך רק לקרוא סודות,

00:05:45.880 --> 00:05:47.840
אל תתנו לו הרשאה ליצור או למחוק אותם.

00:05:48.000 --> 00:05:49.740
אם מישהו צריך רק לנהל תעודות,

00:05:49.740 --> 00:05:51.200
אל תתנו לו גישה למפתחות.

00:05:51.300 --> 00:05:53.020
הרשו לי לעבור על התפקידים העיקריים.

00:05:53.240 --> 00:05:54.560
יש לכם את Key Vault Reader.

00:05:54.780 --> 00:05:56.240
זה מאפשר למישהו להציג רשימת סודות,

00:05:56.380 --> 00:05:57.460
אך לא לקרוא את הערכים שלהם.

00:05:57.600 --> 00:05:58.720
Key Vault Secrets User.

00:05:58.980 --> 00:06:01.340
זה מאפשר למישהו לקרוא בפועל את ערכי הסודות.

00:06:01.340 --> 00:06:02.880
ו-Key Vault Secrets Officer.

00:06:03.100 --> 00:06:04.380
זה מאפשר למישהו ליצור,

00:06:04.580 --> 00:06:05.720
לעדכן ולמחוק סודות.

00:06:05.880 --> 00:06:06.820
שימו לב לדפוס.

00:06:07.000 --> 00:06:09.380
כל תפקיד ספציפי לנתונים שבתוך הכספת,

00:06:09.560 --> 00:06:10.400
לא לכספת עצמה.

00:06:10.520 --> 00:06:12.280
כעת, השבו זאת לתפקידים הכלליים,

00:06:12.480 --> 00:06:13.760
בעלים, תורם, קורא.

00:06:13.860 --> 00:06:15.860
תפקידים אלו חלים על הכספת כמשאב,

00:06:16.020 --> 00:06:16.940
לא על המידע שבתוכה.

00:06:17.040 --> 00:06:18.900
בעלים יכול למחוק את הכספת כולה.

00:06:19.000 --> 00:06:21.020
תורם יכול לשנות את הגדרות הכספת.

00:06:21.020 --> 00:06:22.780
אך אף אחד מהתפקידים הללו,

00:06:22.860 --> 00:06:24.900
כשלעצמו לא מעניק גישה על הסודות שבפנים,

00:06:25.100 --> 00:06:26.600
זוהי שכבת הרשאות נפרדת,

00:06:26.720 --> 00:06:27.860
וזו הנקודה המרכזית.

00:06:27.980 --> 00:06:29.680
בקרת גישה היא עניין מדורג.

00:06:29.820 --> 00:06:31.300
אתם זקוקים לגישה לכספת עצמה,

00:06:31.480 --> 00:06:32.240
זו השכבה הראשונה,

00:06:32.240 --> 00:06:34.480
ואתם זקוקים לגישה על המידע שבתוך הכספת,

00:06:34.620 --> 00:06:35.340
זו השכבה השנייה.

00:06:35.460 --> 00:06:37.060
יש להעניק את שתיהן בנפרד.

00:06:37.220 --> 00:06:39.420
רוב המתחילים חושבים רק על השכבה הראשונה,

00:06:39.520 --> 00:06:40.480
ושוכחים את השנייה.

00:06:40.680 --> 00:06:41.760
שם מתחילות הצרות.

00:06:41.900 --> 00:06:43.400
טעות האבטחה מספר אחת.

00:06:43.400 --> 00:06:44.200
הנה העניין.

00:06:44.360 --> 00:06:45.300
רוב האנשים מסתכלים על תפקיד,

00:06:45.400 --> 00:06:46.140
תורם כספת מפתחות,

00:06:46.260 --> 00:06:47.640
וחושבים שהוא בטוח.

00:06:47.760 --> 00:06:48.860
הם רואים את המילה, תורם,

00:06:48.940 --> 00:06:50.740
ומניחים שהם יכולים לנהל את הגדרות הכספת,

00:06:50.900 --> 00:06:51.960
אך לא לגעת בסודות שבפנים.

00:06:52.120 --> 00:06:54.740
התיעוד של מייקרוסופט עצמה אמר במקור בדיוק את זה.

00:06:54.860 --> 00:06:57.100
תפקיד זה אינו מאפשר לך לגשת לסודות,

00:06:57.260 --> 00:06:58.320
מפתחות או תעודות.

00:06:58.400 --> 00:06:59.660
רק שזה לא בדיוק נכון.

00:06:59.860 --> 00:07:00.760
משתמש עם תפקיד,

00:07:00.900 --> 00:07:02.040
תורם כספת מפתחות,

00:07:02.240 --> 00:07:04.180
יכול לשנות את מדיניות הגישה לכספת.

00:07:04.180 --> 00:07:06.980
ואם הכספת עדיין משתמשת במדיניות גישה מדור קודם,

00:07:07.140 --> 00:07:07.920
כפי שרבות עושות,

00:07:08.100 --> 00:07:11.080
אזי הם יכולים פשוט להעניק לעצמם גישת קריאה מלאה לכל סוד,

00:07:11.200 --> 00:07:12.380
מפתח ותעודה שבפנים.

00:07:12.540 --> 00:07:13.880
אין צורך בפרצה מיוחדת,

00:07:14.000 --> 00:07:15.260
ואין פגיעות שצריך לתקן.

00:07:15.420 --> 00:07:16.800
כך פשוט עובדות ההרשאות.

00:07:16.980 --> 00:07:19.800
חוקרי הבטחה בדי הדוג הוכיחו זאת בית מינוס 2024.

00:07:20.220 --> 00:07:23.000
הם הראו שתורם יכול לשדרג להרשאות גישה מלאות למידע

00:07:23.000 --> 00:07:25.480
בכל כספת המשתמשת במדיניות גישה מדור קודם.

00:07:25.480 --> 00:07:27.680
התגובה של מייקרוסופט הייתה מעניינת.

00:07:27.800 --> 00:07:29.140
הם אמרו שזו אינה פגיעות,

00:07:29.220 --> 00:07:31.360
מכיוון שתורמים מיועדים לנהל מדיניות גישה,

00:07:31.620 --> 00:07:34.060
אך הם גם ידכנו את התיעוד כדי להזהיר במפורש

00:07:42.380 --> 00:07:46.880
תורם לא נשמע כמו מישהו שיכול לקרוא את סיסמאות מסד הנתונים שלכם,

00:07:47.040 --> 00:07:48.000
אבל בפועל הם יכולים.

00:07:48.160 --> 00:07:49.180
חישבו על הסיכון.

00:07:49.340 --> 00:07:53.060
אם תוקף פורץ לחשבון עם תפקיד תורם בחשפת המפתחות שלכם,

00:07:53.280 --> 00:07:54.980
הוא לא צריך לפרוץ לכספת עצמה.

00:07:54.980 --> 00:07:56.620
הוא לא צריך לפצח עצפנה.

00:07:56.760 --> 00:07:58.460
הוא פשוט משנה את מדיניות הגישה,

00:07:58.680 --> 00:08:00.080
נותן לעצמו גישת קריאה,

00:08:00.280 --> 00:08:02.260
ושואב בשקט כל סוד ששמרתם,

00:08:02.420 --> 00:08:03.260
מחרוזות חיבור,

00:08:03.440 --> 00:08:04.300
מפתחות API,

00:08:04.620 --> 00:08:05.060
תעודות,

00:08:05.160 --> 00:08:05.520
הכל.

00:08:05.520 --> 00:08:08.640
ומכיוון ששינויי מדיניות גישה הם פעילות ניהולית רגילה,

00:08:08.840 --> 00:08:10.320
ייתכן שזה לא יפעיל שום התראה.

00:08:10.420 --> 00:08:11.320
אז מהו הפתרון?

00:08:11.480 --> 00:08:11.800
ראשית,

00:08:11.920 --> 00:08:15.380
השתמשו באז'ר RBSC עבור גישה למישור הנתונים במקום במדיניות גישה מדור קודם.

00:08:15.540 --> 00:08:18.400
RBSC מפריד בין ניהול הכספת לבין המידע שבתוכה.

00:08:18.400 --> 00:08:18.820
שנית,

00:08:18.900 --> 00:08:22.640
לעולם אל תעניקו את תפקיד הקונטריביוטר בקי וולט למי שלא זקוק לו באופן מוחלט.

00:08:22.700 --> 00:08:23.120
שלישית,

00:08:23.220 --> 00:08:24.920
אם כבר יש לכם משתמשים בעלי תפקיד זה,

00:08:24.920 --> 00:08:26.220
ביצעו להם ביקורת עוד היום.

00:08:26.360 --> 00:08:28.600
החליפו את הקונטריביוטר בתפקידים ספציפיים יותר,

00:08:28.780 --> 00:08:31.220
כמו Key Vault Secrets User או Key Vault Secrets Officer.

00:08:31.420 --> 00:08:33.280
יש טעות שנייה שמחמירה את הראשונה,

00:08:33.560 --> 00:08:35.540
והיא לשמור את כל הסודות בחשפת אחת.

00:08:35.640 --> 00:08:38.060
אם יש לכם כספת אחת לכל דבר פיתוח,

00:08:38.240 --> 00:08:38.680
בדיקות,

00:08:38.880 --> 00:08:39.360
סטייג'ינג,

00:08:39.360 --> 00:08:41.280
ייצור וכל האפליקציות שלכם,

00:08:41.340 --> 00:08:42.660
ואותה כספת נפרצת,

00:08:42.740 --> 00:08:43.440
הכל חשוף.

00:08:43.560 --> 00:08:45.100
זוהי נקודת קשל בודדת.

00:08:45.220 --> 00:08:47.640
נדבר עוד מעט על אסטרטגיה של ריבוי כספות,

00:08:47.640 --> 00:08:48.660
אבל העיקרון פשוט.

00:08:48.840 --> 00:08:50.580
אל תשימו את כל הביצים בסל אחד,

00:08:50.800 --> 00:08:53.800
במיוחד כשהסל הזה מחזיק את המפתחות לכל התשתית שלכם.

00:08:53.960 --> 00:08:54.880
Managed Identity,

00:08:55.140 --> 00:08:55.880
תקן הזהב.

00:08:56.020 --> 00:08:57.180
אז איך עושים את זה נכון?

00:08:57.360 --> 00:08:59.800
בואו נדבר על הדרך הטובה ביותר לגשת ל-Key Vault.

00:09:00.000 --> 00:09:01.160
יש כאן בעיה מהותית.

00:09:01.160 --> 00:09:02.720
כדי לקבל אישורים מ-Key Vault,

00:09:02.900 --> 00:09:04.280
האפליקציה צריכה להזדהות,

00:09:04.440 --> 00:09:06.160
אך כדי להזדהות היא זקוקה לאישורים.

00:09:06.280 --> 00:09:09.620
איפה מאחסנים את האישורים שהאפליקציה צריכה כדי להשיג אישורים אחרים?

00:09:09.820 --> 00:09:11.440
זו בעיית הביצה והתרנגולת.

00:09:11.560 --> 00:09:14.480
התשובה הישנה הייתה Service Principal in Client Secret,

00:09:14.740 --> 00:09:16.380
אבל הסוד הזה חייב לשבת איפשהו,

00:09:16.620 --> 00:09:17.620
אולי בקובץ הגדרות,

00:09:17.760 --> 00:09:19.780
במשתני סביבה או בפייפליין של פריסה.

00:09:19.880 --> 00:09:21.580
ועכשיו חזרתם לאותה הבעיה.

00:09:21.720 --> 00:09:23.600
פשוט העברתם את הסוד למקום אחר.

00:09:23.600 --> 00:09:25.680
Managed Identity פותר זאת לחלוטין.

00:09:25.800 --> 00:09:26.600
כך זה עובד.

00:09:26.780 --> 00:09:29.180
כשמפעילים Managed Identity על משאב Azure,

00:09:29.420 --> 00:09:32.040
כמו Web App, פונקציה או מכונה וירטואלית,

00:09:32.320 --> 00:09:35.360
Azure יוצרת אוטומטית זהות למשאב הזה ב-Entra ID.

00:09:35.360 --> 00:09:38.100
הזהות הזו מנוהלת לחלוטין על ידי Azure.

00:09:38.320 --> 00:09:41.640
אין אישורים ליצור, אין סודות להחליף, אין מה להכסן.

00:09:42.060 --> 00:09:44.600
למשאב פשוט יש זהות ש-Azure מכירה.

00:09:44.760 --> 00:09:45.880
ישנם שני סוגים.

00:09:46.120 --> 00:09:49.600
System Assigned Managed Identity קשורה למשאב ספציפי אחד.

00:09:49.600 --> 00:09:52.160
אם מוחקים את המשאב, גם הזהות נעלמת.

00:09:52.280 --> 00:09:55.480
הם חולקים מחזור חיים משותף, מה שהופך את הניהול לפשוט.

00:09:55.680 --> 00:10:00.280
User Assigned Managed Identity היא זהות עצמאית שניתן להקצות למספר משאבים.

00:10:00.440 --> 00:10:02.640
היא לא חולקת מחזור חיים עם אף אחד מהם,

00:10:02.640 --> 00:10:05.640
ולכן היא שימושית כשצריך את אותה זהות במספר שירותים.

00:10:05.820 --> 00:10:07.200
הנה איך זה נראה בפועל.

00:10:07.320 --> 00:10:11.480
נניח שיש לכם Web App שצריך לקרום מחרוז את חיבור למסעד נתונים מ-Key Vault.

00:10:11.620 --> 00:10:14.660
אתם מפעילים System Assigned Managed Identity על ה-Web App.

00:10:14.660 --> 00:10:19.040
לאחר מכן אתם מעניקים לזהות הזו את תפקיד ה-Key Vault Secrets User בכספת שלכם.

00:10:19.160 --> 00:10:22.980
וזהו, אין מחרוזות חיבור בקוד ואין Client Secrets בגבצי הגדרות.

00:10:23.140 --> 00:10:26.940
אפליקציית האינטרנט מאמתת את עצמה מול Key Vault באמצעות הזהות המנוהלת שלה,

00:10:26.940 --> 00:10:29.320
ואז'ר מטפל בכל ניהול האישורים מאחורי הקלעים.

00:10:29.480 --> 00:10:32.380
זהו הדבר הקרוב ביותר לאימות ללא אישורים באז'ר.

00:10:32.580 --> 00:10:34.700
זה משנה את כללי המשחק בתחום האבטחה,

00:10:34.900 --> 00:10:38.300
כיוון שזה מבטל את וקטור התקיפה הנפוץ ביותר, גניבת אישורים.

00:10:38.300 --> 00:10:41.560
אם אין אישורים לגנוב, אין לתוקף שום דבר לפרוץ אליו.

00:10:41.660 --> 00:10:43.780
תן לי לתת לך דוגמה מהעולם האמיתי.

00:10:43.920 --> 00:10:47.300
דמיין צינור נתונים בסינאפס שצריך לגשת לחשבון איחסון.

00:10:47.300 --> 00:10:51.240
בדרך הישנה, היית שומר את מפתח חשבון איחסון בהגדרות הצינור.

00:10:51.400 --> 00:10:54.180
אם מי שהוא השיג גישה לצינור הזה, היה לו את המפתח.

00:10:54.360 --> 00:10:57.540
אם זהות מנוהלת, לסביבת העבודה של סינאפס יש זהות.

00:10:57.540 --> 00:11:01.620
לזהות הזו ניתנת גישה ל-Key Vault שבו מאוכסן מפתח חשבון איחסון.

00:11:01.720 --> 00:11:06.060
הצינור מושך את המפתח בזמן הריצה, משתמש בו, ולעולם לא שומר אותו בשום מקום.

00:11:06.220 --> 00:11:08.800
אין מפתחות בקוד, אין סודות בהגדרות הצינור.

00:11:08.800 --> 00:11:14.560
כשמשלבים זהות מנוהלת עם RBSC ועקרון ההרשאה המינימלית, מקבלים בסיס מאובטח לכל אומס עבודה באז'ר.

00:11:14.720 --> 00:11:17.040
האפליקציות שלך מבצעות עימות ללא אישורים.

00:11:17.160 --> 00:11:20.620
הן ניגשות רק למה שהן צריכות, וכל גישה מתועדת וניתנת לביקורת.

00:11:20.620 --> 00:11:23.740
זהו הדפוס שמייקרוסופט ממליצה עליו כמעט לכל תרחיש.

00:11:23.880 --> 00:11:27.440
ברגע שתתחיל להשתמש בזה, תתהה למה אי פעם עשית זאת בדרך אחרת.

00:11:27.560 --> 00:11:29.520
עלות ואסטרטגיית ריבוי כשפות.

00:11:29.520 --> 00:11:31.040
אז בואו נדבר על עלות.

00:11:31.220 --> 00:11:32.640
כאן רוב האנשים מופתעים.

00:11:32.820 --> 00:11:34.640
כמה באמת עולה Azure Key Vault?

00:11:34.840 --> 00:11:36.140
מודל התמכור הוא פשוט.

00:11:36.280 --> 00:11:37.620
אין תשלום מכסון לכל סוד.

00:11:37.760 --> 00:11:40.260
אתה לא משלם עבור כל סיסמה או מפתח API שאתה מאחסן.

00:11:40.260 --> 00:11:42.000
במקום זאת, אתה משלם לפי פעולה.

00:11:42.100 --> 00:11:45.260
עבור שכבת הסטנדרט, זה בערך שלושה סנט על כל עשרת אלפים פעולות.

00:11:45.440 --> 00:11:47.620
קריאה לקבלת סוד נחשבת כפעולה אחת.

00:11:47.720 --> 00:11:50.420
כך גם יצירת סוד או הצגת רשימת התוכן של הכספת.

00:11:50.420 --> 00:11:53.860
עבור אפליקציה טיפוסית קטנה עד בינונית, זה מסתכם בפרוטות לחודש.

00:11:53.960 --> 00:11:55.220
פרוטות במובן המילולי.

00:11:55.360 --> 00:11:57.460
השווה את זה אלא את WS Secrets Manager.

00:11:57.680 --> 00:12:00.040
הם גובים 40 סנט לכל סוד לחודש רק עבור היחסון,

00:12:00.240 --> 00:12:01.900
פלוס עמלות נוספות עבור קריאות API.

00:12:01.900 --> 00:12:05.620
אם יש לך מאה סודות, זה 40 דולר לחודש לפני שבכלל קראת אחד מהם.

00:12:05.720 --> 00:12:09.380
עם Azure Key Vault, מאה סודות עם שימוש מתון עשויים לעלות לך 15 סנט.

00:12:09.520 --> 00:12:11.740
ההבדל גדל במהירות ככל שהקף הפעילות גדל.

00:12:11.740 --> 00:12:13.240
כעת, קיימת שכבת פרימיום.

00:12:13.400 --> 00:12:17.800
היא מוסיפה מפתחות מבוססי HSM עבור עומסי עבודה הזקוקים לרמה הגבוהה ביותר של הבטחה קריפטוגרפית.

00:12:17.900 --> 00:12:21.060
חשוב על עסקאות פיננסיות, נתוני בריאות, מערכות ממשלתיות.

00:12:21.060 --> 00:12:26.540
העלות לכל פעולה גבוהה יותר, סביב 15 סנט למד מינוס 10 אלפים פעולות עבור סוגי מפתחות מתקדמים,

00:12:26.780 --> 00:12:28.620
פלוס עמלה חודשית לכל מפתח HSM.

00:12:28.800 --> 00:12:32.020
אבל עבור רוב האפליקציות, שכבת הסטנדרט היא די ויותר.

00:12:32.160 --> 00:12:34.600
הנה הפתעת העלות שתופסת אנשים לא מוכנים.

00:12:34.820 --> 00:12:38.840
עבור אפליקציית אינטרנט טיפוסית עם מספר מצומצם של סודות וכמה אלפי פעולות בחודש,

00:12:39.040 --> 00:12:40.400
הקי וולט יעלה פחות מדולר.

00:12:40.400 --> 00:12:42.960
תוציא יותר על הקפה שתשתה בזמן ההגדרה שלו.

00:12:43.040 --> 00:12:45.160
אבל יש אסטרטגיה שחשובה יותר מהעלות.

00:12:45.300 --> 00:12:47.020
כמה כספות, וולטס, אתה משתמש?

00:12:47.180 --> 00:12:49.320
הגישה החכמה היא אסטרטגיה של ריבוי כספות.

00:12:49.480 --> 00:12:52.660
השתמש בחשפות נפרדות לפיתוח, בדיקות, סביבת ביניים וסביבת ייצור.

00:12:52.840 --> 00:12:54.680
זה מונע את התאונה הנפוצה ביותר.

00:12:54.840 --> 00:12:59.800
מישהו שמריץ סקריפט בדיקה שקורה בטעות מסד נתונים של ייצור כי מחרוזת החיבור הייתה באותה כספת.

00:12:59.900 --> 00:13:02.680
כשהסביבות מופרדות, הטעות הזו הופכת לבלתי אפשרית.

00:13:02.680 --> 00:13:05.620
כדאי גם להפריד לפי יחידה עסקית או תחום עמידה בתקנים.

00:13:05.760 --> 00:13:09.360
אם אתה מטפל בנתוני כרטיסי תשלום, שים את הסודות האלה בחשפת משלהם.

00:13:09.500 --> 00:13:12.780
עומסי עבודה עסקיים כלליים ילכו לאחרת ונתוני בריאות לשלישית.

00:13:12.780 --> 00:13:15.880
זה לא עניין של להקשות, זה עניין של הגבלת רדיוס הנזק.

00:13:16.020 --> 00:13:19.240
אם כספת אחת נפרצת, רק הסודות באותה כספת נחשפים.

00:13:19.420 --> 00:13:21.340
שאר התשתית של לך נשארת בטוחה.

00:13:21.420 --> 00:13:23.740
ושתי רשתות ביטחון מובנות שתמיד כדאי להפעיל.

00:13:23.740 --> 00:13:27.580
מחיקה רכה, סוף דליט, אומרת שאם מישהו מוחק סוד, הוא לא נעלם לצמיתות.

00:13:27.720 --> 00:13:31.560
הוא עובר למצב שניתן לשחזור לתקופת שמירה שתבחר עד 90 יום.

00:13:31.720 --> 00:13:34.700
הגנת ניקוי, פורג' פרוטקשן, לוקחת את זה צעד אחד קדימה.

00:13:34.800 --> 00:13:38.600
אף אחד לא יכול למחוק לצמיתות את הכספת או את תוכנה עד שתקופת השמירה תפוג.

00:13:38.780 --> 00:13:43.220
יחד, הם מונעים את סוג אובדן הנתונים המקרי שגורם לצוותי הבטחה לא לישון בלילה.

00:13:43.300 --> 00:13:44.220
איך הכל מתחבר?

00:13:44.220 --> 00:13:47.200
בואו נחבר את כל זה יחד ונראה איך החלקים משתלבים.

00:13:47.340 --> 00:13:48.700
כי וולט הוא לא ייבודד.

00:13:48.820 --> 00:13:52.320
הוא מערכת העצבים המרכזית לסודות בארכיטקטורת האז'ר שלך.

00:13:52.460 --> 00:13:55.640
כשמבינים איך כל המערכת זורמת, הכל נופל למקום.

00:13:55.820 --> 00:13:57.900
הנה מה שקורה כשיישום זקוק לסוד.

00:13:57.900 --> 00:14:00.880
היישום ביקש זאת באמצעות הזהות המנוהלת שלו.

00:14:01.020 --> 00:14:03.360
הזהות הזו כבר רשומה ב-Entra ID.

00:14:03.560 --> 00:14:07.220
Azure יצרה אותה אוטומטית כשהפעלת זהות מנוהלת על המשאב.

00:14:07.760 --> 00:14:12.200
Entra ID מעמד שהזהות לגיטימית, ואז מעביר את הבקשה ל-KeyVault.

00:14:12.320 --> 00:14:15.240
KeyVault בודק את הרשאות ה-RBSC שהקצאתה.

00:14:15.320 --> 00:14:20.740
אם לזהות יש את התפקיד הנכון, למשל KeyVault Secrets User, הסוד מוחזר, כל זה קורה במילי שניות.

00:14:20.920 --> 00:14:24.360
היישום לעולם לא רואה את אישור הכניסה, Credential, ולעולם לא מאכסן סיסמה.

00:14:24.360 --> 00:14:26.000
הוא פשוט מקבל את הערך שהוא צריך.

00:14:26.120 --> 00:14:28.620
עכשיו, תחשוב כמה שירותי Azure יכולים להתחבר לזה.

00:14:28.760 --> 00:14:33.260
App Service, Functions, AKS, Data Factory, Synapse, Logic Apps, DevOps Pipelines.

00:14:33.500 --> 00:14:34.800
כולם יודעים איך לדבר עם KeyVault.

00:14:34.920 --> 00:14:38.820
ניתן להגדיר אפליקציית אינטרנט שתפנה לסוד ישירות בהגדרות היישום שלה.

00:14:38.940 --> 00:14:43.920
ניתן להגדיר צינור איבוד, Pipeline, של Data Factory, שימשוך מפתח חשבון יחסון מ-KeyVault בזמן הריצה.

00:14:44.020 --> 00:14:48.360
ניתן להגדיר אשכול קוברנטיז, שימשוך סודות באמצעות מנהל ההתקן, KeyVault CSI.

00:14:48.360 --> 00:14:54.480
כל שירות משתלב באותה הדרך, תוך שימוש באותה מערכת זהויות, אותם תפקידי RBSC, ואותו רישום ביקורת.

00:14:54.540 --> 00:14:56.740
תבנית ה-C, CD, היא עוצמתית במיוחד.

00:14:56.860 --> 00:15:00.060
צינורות האיבוד, Pipelines, שלך מושכים סודות מ-KeyVault בזמן הפריסה.

00:15:00.160 --> 00:15:03.160
הם לעולם לא שומרים אותם במשתני הפייפליין או בסודות של מאגר הקוד.

00:15:03.320 --> 00:15:06.520
אם עליך לרענן סיסמת בסיס נתונים, פשוט עדכן אותה ב-KeyVault.

00:15:06.640 --> 00:15:09.900
בפעם הבאה שהפייפליין ירוץ, הוא ימשוך את הערך החדש באופן אוטומטי.

00:15:09.900 --> 00:15:12.940
ללא שינויי פייפליין, ללא שינויי קוד וללא פריסות מחדש.

00:15:13.080 --> 00:15:14.740
זה הדבר שגורם להקל להתחבר.

00:15:14.920 --> 00:15:19.560
ברגע שמגדירים KeyVault עם זהות מנוהלת או RBSC, מפסיקים לחשוב על ניהול אישורים לחלוטין.

00:15:19.680 --> 00:15:21.240
היישומים שלך פשוט עובדים.

00:15:21.420 --> 00:15:23.460
סודות מתרעננים מבלי שאף אחד ישים לב.

00:15:23.580 --> 00:15:25.880
אישורים מתחדשים ללא קריאות חירום באמצע הלילה.

00:15:26.000 --> 00:15:27.800
המערכת מטפלת בהקל ברקע.

00:15:27.940 --> 00:15:29.840
זוהי גישת ההבטחה שבאמת חשובה.

00:15:29.960 --> 00:15:31.700
הזהות היא ההיקף, לא הרשת.

00:15:31.700 --> 00:15:35.300
לא משנה אם מי שהוא נמצא בתוך הרשת הווירטואלית שלך או מחוץ עלה.

00:15:35.380 --> 00:15:38.500
מה שחשוב הוא האם יש לו זהות תקפה עם ההרשאות המתאימות.

00:15:38.660 --> 00:15:40.880
KeyVault אוכף זאת כחלק מהתכנון שלו.

00:15:41.020 --> 00:15:46.560
כל בקשת גישה עוברת עימות מול Entry ID והרשאת RBSC ללא קשר למקור הבקשה.

00:15:46.700 --> 00:15:47.580
והכל מתועד.

00:15:47.700 --> 00:15:50.500
כל קריאת סוד, כל פעולת מפתח, כל שליפת אישור.

00:15:50.640 --> 00:15:52.280
ניתן לראות מי ניגש למה ומתי.

00:15:52.440 --> 00:15:55.440
אם מה שהוא נראה חשוד, יש לך את הנתונים כדי לחקור זאת.

00:15:55.440 --> 00:15:59.600
זה קריטי עבור ציאות, תגובה לאירועים ופשוט לדעת מה קורה בסביבה שלך.

00:15:59.760 --> 00:16:01.100
זו היופי בכל העניין.

00:16:01.260 --> 00:16:06.440
KeyVault, Entry ID, RBSC וזהות מנוהלת עובדים יחד כמסגרת הבטחה מאוחדת.

00:16:06.520 --> 00:16:08.160
כל רכיב מחזק את האחרים.

00:16:08.380 --> 00:16:15.800
וכשהכל מוגדר נכון, יש לך מערכת לניהול אישורים שהיא גם מאובטחת יותר וגם פשוטה יותר לתפעול מכל דבר שתוכל לבנות בעצמך.

00:16:15.940 --> 00:16:16.920
תובנות מעשיות.

00:16:17.100 --> 00:16:19.060
אז מה עליך לעשות בפועל ממש עכשיו?

00:16:19.260 --> 00:16:20.920
בוא נהפוך את הידע הזה לפעולה.

00:16:20.920 --> 00:16:22.960
הנה הדברים שניתן לטפל בהם השבוע.

00:16:23.080 --> 00:16:24.580
התחל עם מודל ההרשאות שלך.

00:16:24.720 --> 00:16:27.820
פתח את ה-KeyVault בפורטל, עבור להגדרות הגישה ובדוק מה רשום שם.

00:16:27.920 --> 00:16:30.880
אם אתה רואה מדיניות גישת כספת, Vault Access Policy, זו הדרך הישנה.

00:16:31.020 --> 00:16:33.660
עדיף להשתמש בבקרת גישה מבוססת תפקידים של Azure.

00:16:33.880 --> 00:16:34.900
המעבר הוא פשוט.

00:16:35.060 --> 00:16:39.940
החלף את מודל ההרשאות והקצה תפקידי RBSC לאותם אנשים שהיו להם מדיינויות גישה.

00:16:40.060 --> 00:16:40.980
עשה זאת עוד היום.

00:16:40.980 --> 00:16:44.600
מייקרוסופט ממליצה על כך, והמחקר שדיברנו עליו הראה בדיוק למה.

00:16:44.700 --> 00:16:47.520
לאחר מכן, בצע ביקורת על חשבונות בעלי תפקיד תורם, Contributor.

00:16:47.980 --> 00:16:51.600
ב-KeyVault, פתח את לשונית העים בכספת שלך ובדוק למי יש גישת תורם.

00:16:51.740 --> 00:16:54.180
לכל אדם עם התפקיד הזה צריכה להיות סיבה מוצדקת.

00:16:54.340 --> 00:16:55.460
ברוב המקרים, הם לא.

00:16:55.640 --> 00:16:57.840
החליפו את ה-Contributor במה שהוא ספציפי יותר.

00:16:58.040 --> 00:17:01.080
אם מי שהוא רק צריך לקרוא סודות, תנו לו הרשאת KeyVault Secrets User.

00:17:01.080 --> 00:17:04.320
אם הוא צריך לנהל סודות, השתמשו ב-KeyVault Secrets Officer.

00:17:04.460 --> 00:17:06.940
המטרה היא לסגור את נתיב ההסלמה הזה לחלוטין.

00:17:07.080 --> 00:17:09.280
לאחר מכן, ניצלו את ה-Managed Identity.

00:17:09.400 --> 00:17:12.580
כל שירות Azure שזקוק לגישה ל-KeyVault צריך להשתמש בזה.

00:17:12.720 --> 00:17:19.040
אם יש לכם אפליקציית ווב, פונקציה, דטה פקטורי או מכונה וירטואלית שעדיין משתמשים ב-Service Principal עם Client Secret,

00:17:19.280 --> 00:17:20.360
עברו ל-Managed Identity.

00:17:20.540 --> 00:17:24.480
זה פשוט יותר, מאובטח יותר, וזה פותר את בעיית הביצה והתרנגולת שסקרנו.

00:17:24.480 --> 00:17:27.180
Azure מטפל בניהול האישורים עבורכם מאחורי הקלעים.

00:17:27.320 --> 00:17:31.380
עוד דבר אחד, הפעילו מחיקה רכה, Soft Delete, והגנת מחיקה, Purge Protection, בכל כספת.

00:17:31.480 --> 00:17:35.040
מחיקה רכה מופעלת כברירת מחדל בחשפות חדשות, אך הגנת מחיקה לא.

00:17:35.200 --> 00:17:35.860
הפעילו אותה.

00:17:35.980 --> 00:17:40.600
ההגדרה הזו מונעת מכל אחד למחוק לצמיתות, כספת או עת תוכנה במהלך תקופת השמירה.

00:17:40.740 --> 00:17:43.100
זה הציל יותר מצוות אחד מתאויות הרסניות.

00:17:43.300 --> 00:17:44.800
הנה הקריאה שלכם לפעולה.

00:17:44.940 --> 00:17:47.100
בדקו את גישת ניהול הסודות הנוכחית שלכם.

00:17:47.100 --> 00:17:51.140
מצאו סוד אחד שעדיין יושב בקובץ הגדרות, במשתנה סביבה או בתוך הקוד.

00:17:51.280 --> 00:17:52.860
העבירו אותו לכי וולט השבוע.

00:17:53.020 --> 00:17:55.980
רק אחד, ברגע שתראו כמה זה פשוט, תרצו להעביר את השאר.

00:17:56.100 --> 00:17:57.620
הבטחה היא לא הגדרה חד פעמית.

00:17:57.780 --> 00:17:58.740
זה תהליך מתמשך.

00:17:58.900 --> 00:18:01.840
כי וולט הופך את התהליך הזה לקל יותר, אבל רק כשמשתמשים בו נכון.

00:18:01.980 --> 00:18:02.840
הכלים קיימים.

00:18:03.040 --> 00:18:04.040
התבניות מוכחות.

00:18:04.200 --> 00:18:06.080
עכשיו, זה תלוי בכם ליישם אותן.

00:18:06.260 --> 00:18:06.980
זו המערכת.

00:18:06.980 --> 00:18:11.260
כי וולט הוא הכספת הדיגיטלית שלכם, אך הוא מאובטח רק כמידת בקרות הגישה שתציבו סביבו.

00:18:11.380 --> 00:18:13.080
התחילו עם הבדיקה שתיארתי הרגע.

00:18:13.200 --> 00:18:14.740
בדקו את מודל ההרשאות שלכם.

00:18:14.900 --> 00:18:18.180
בדקו את הקצאות הקונטריביוטר שלכם, והעבירו סוד אחד לכספת השבוע.

00:18:18.340 --> 00:18:23.940
הרשמו לעוד טיפים בהבטחת ענן בשפה פשוטה, ושתפו את זה עם מישהו שעדיין שומר סודות בקבצי הגדרות.