התשובה הקצרה: איזו שיטה מתאימה לאיזה מצב
רוב העצות על שיתוף סיסמאות מתווכחות על כלים. השאלה המועילה פשוטה יותר: כמה זמן פרטי ההתחברות צריכים להתקיים, ומי צריך אותם? כשעונים עליה, השיטה ברורה מאליה.
| מצב | במה להשתמש | למה |
|---|---|---|
| פרטי התחברות שכל הצוות משתמש בהם במשך חודשים (התחברות משותפת לשירות SaaS, חשבון שירות) | כספת משותפת במנהל סיסמאות | צריך לעדכן אותם, להחליף אותם במקום אחד ולהסיר את הגישה אליהם ממי שעוזב. |
| מסירה חד-פעמית (ההתחברות הראשונה של עובד חדש, סיסמת המנהל של לקוח, מחרוזת החיבור למסד הנתונים של קבלן) | קישור סודי חד-פעמי | קוראים את הערך פעם אחת, ואז הוא מושמד. שום דבר לא נשאר בתיבת הדואר או בהיסטוריית הצ'אט של אף אחד. |
| סיסמה למישהו שאין לו גישה לכספת שלכם (לקוח, ספק, פרילנסר) | קישור סודי חד-פעמי, וביטוי הסיסמה נשלח בנפרד | אי אפשר להזמין אנשים מבחוץ לכספת של החברה. קישור וביטוי סיסמה שנמסר בערוץ אחר לא דורשים חשבון בצד שלהם. |
| מפתח Wi-Fi אחד או קוד לדלת, פנים אל פנים | אמרו אותו בקול | לא נוצר שום עותק. השיטה לא מתאימה לכמויות ויש טעויות הקלדה, אבל לערך אחד היא בסדר. |
| כל דבר, תמיד | לא אימייל, Slack, Teams או SMS | ארבעתם שומרים עותק שאפשר לחפש בו ושאינו בשליטתכם. ראו למה אלה הערוצים הגרועים ביותר. |
5 הדרכים שבהן צוותים משתפים סיסמאות, בהשוואה
כל אחת מהשיטות שלמטה נמצאת בשימוש יומיומי במקום כלשהו. הטבלה משווה ביניהן לפי התכונות שחשובות אחרי שהסיסמה כבר נשלחה, כי אז דברים משתבשים.
| שיטה | מי יכול לקרוא אותה אחר כך | כמה זמן היא נשמרת | אפשר לבטל | יומן ביקורת | מאמץ מצד הנמען | הכי מתאימה ל |
|---|---|---|---|---|---|---|
| כספת של מנהל סיסמאות | חברי הכספת שיש להם גישה | עד שמחליפים או מוחקים אותה | כן (הסרת הגישה) | כן (יומן אירועים בתוכניות לצוותים) | צריך חשבון והזמנה | פרטי התחברות ארוכי טווח של הצוות |
| קישור סודי חד-פעמי | רק מי שפותח אותו ראשון | עד הצפייה הראשונה או עד התפוגה (ב-LinkPilot: 1 שעה, 24 שעות או 7 ימים בכל תוכנית עם התחברות, ותאריך ושעה לבחירתכם ב-Pro. בכלי שלא דורש חשבון ברירת המחדל היא 7 ימים) | כן, עד שצופים בו | כן (נוצר / נצפה / נמחק / בוטל) | אין: קישור, ובתוכנית Pro גם ביטוי סיסמה | מסירות, קליטת עובדים, אנשים מבחוץ |
| צ'אט (Slack, Teams, Signal) | חברי הערוץ, המנהלים, מי שיצטרף בעתיד, קבצי ייצוא | כברירת מחדל כל עוד סביבת העבודה קיימת, בתוכניות בתשלום של Slack | מחיקה מסירה עותק אחד. קבצי ייצוא וצילומי מסך נשארים | חלקי (ביקורת של מנהלים, לא לכל סוד) | אין | שום דבר רגיש: שלחו את הקישור, אף פעם לא את הערך |
| אימייל | שתי תיבות הדואר, שני הספקים, הגיבויים וכל מכשיר שמסתנכרן | ללא הגבלת זמן | לא | לא | אין | העברת קישור לסוד, אף פעם לא הסוד עצמו |
| בעל פה, בטלפון או ב-SMS | בעל פה: אף אחד. SMS: שני המכשירים והספק הסלולרי | בעל פה: בכלל לא. SMS: ללא הגבלת זמן | לא | לא | נמוך, אבל קל לטעות בהקלדה | ערך אחד, פנים אל פנים |
נבדק ב-2026-10-02. ברירת המחדל של Slack לשמירת נתונים והנתונים על החלפת SIM מופיעים במקורות בסוף המדריך. ההתנהגות של LinkPilot תואמת את עמוד ארכיטקטורת האבטחה.
כספות משותפות במנהל סיסמאות
לפרטי התחברות שמשמשים חודשים, כספת משותפת במנהל סיסמאות כמו 1Password, Bitwarden, Keeper, Psono ואחרים היא ברירת המחדל הנכונה. הסיסמה נמצאת במקום אחד, החלפה מעדכנת אותה אצל כולם, הגישה ניתנת לפי אוסף, כשמישהו עוזב מספיק להסיר את המושב שלו, ותוכניות לצוותים מוסיפות יומני אירועים. החיסרון: כל מי שצריך את הסיסמה חייב להיות בתוך הכספת, ולכן אי אפשר למסור פריט מהכספת ללקוח, לפרילנסר או לעובד חדש שעוד לא קיבל גישה.
קישור מוצפן חד-פעמי
לרגע המסירה, קישור סודי חד-פעמי הוא הכלי הנכון. מדביקים את הסיסמה, מקבלים כתובת URL ושולחים אותה בכל ערוץ שכבר משתמשים בו. הנמען פותח אותה פעם אחת: התוכן מוצג ואז מושמד, והכתובת שנשארת בשרשור לא מובילה לשום מקום. הוסיפו תפוגה קצרה, כדי שקישור שלא נפתח ימות מעצמו, וביטוי סיסמה שנמסר בערוץ שני, כדי שקישור שיורט לבדו לא יועיל. אפשר ליצור קישור עכשיו בלי חשבון. העמודים LinkPilot מול Password Pusher ואיך לשתף מפתחות API בצורה מאובטחת מסבירים את אותו מנגנון לטוקנים.
צ'אט (Slack, Teams, Signal)
צ'אט מרגיש זמני, והוא בדיוק ההפך. התיעוד של Slack עצמו קובע שבתוכניות בתשלום "הנתונים נשמרים כברירת מחדל כל עוד סביבת העבודה קיימת", ובעלי סביבת העבודה יכולים לייצא אותם. Teams ו-Google Chat כפופים למדיניות שמירה ו-eDiscovery שנבנו כדי שאי אפשר יהיה להעלים הודעות. Signal טוב יותר, עם הודעות נעלמות ובלי היסטוריה בשרת, אבל גם בו יש עותק בשני טלפונים, עם צילומי מסך וגיבויים שאינם בשליטתכם. כל אפליקציית צ'אט גם פותחת תצוגה מקדימה של קישור ברגע שהוא מתפרסם, ולכן קישור חד-פעמי חייב להיות בנוי כך שתצוגה מקדימה לא תמחק אותו.
אימייל
סיסמה שנשלחה באימייל נשמרת כטקסט גלוי בשרת הדואר של השולח, בשרת של הנמען, בגיבויים של שניהם ובכל מכשיר שסנכרן את תיבת הדואר. היא שורדת העברה הלאה, ארכוב ופריצה לחשבון, ופריצה לתיבת הדואר אחרי שנים חושפת כל סיסמה שאי פעם נשלחה דרכה. אימייל מתאים להעברת קישור לסוד. הוא אף פעם לא מקום מתאים לסוד עצמו.
בעל פה, בטלפון וב-SMS
כשמקריאים סיסמה בקול באותו חדר, לא נוצר שום עותק. זו השיטה היחידה בעמוד הזה שלא משאירה שום שארית, וגם היחידה שלא מתאימה לכמויות. SMS הוא הקרוב המסוכן שלה: ההודעה נשארת בשני המכשירים וברישומים של הספק הסלולרי, ומספרי טלפון נגנבים. המרכז לתלונות על פשיעה באינטרנט של ה-FBI רשם ב-2021 לבדה 1,611 תלונות על החלפת SIM, עם הפסדים של יותר מ-$68 מיליון, לעומת 320 תלונות בכל השנים 2018–2020 יחד. SMS מתאים לביטוי סיסמה קצר שאין בו תועלת בלי הקישור שנמסר בנפרד. הוא לא מתאים לסיסמה עצמה.
למה אימייל, Slack ו-SMS הם הערוצים הגרועים ביותר
לאימייל, לצ'אט ול-SMS יש תכונה משותפת אחת שפוסלת אותם: הם מערכות שמירה. כל אחד מהם בנוי לשמור עותק נאמן של כל הודעה, לתמיד, במקומות שאתם לא רואים. סיסמה שהודבקה באחד מהם היא בפועל סיסמה שפורסמה לתוקף העתידי שלכם. בפירוט:
- שמירה ללא הגבלת זמן. Slack שומר כברירת מחדל את הנתונים של סביבות עבודה בתשלום כל עוד סביבת העבודה קיימת. שרתי דואר שומרים הודעות עד שמישהו מוחק אותן, והגיבויים שומרים אותן עוד יותר זמן.
- גישה של מנהלים וייצוא. בעלי סביבת העבודה יכולים לייצא את היסטוריית הצ'אט, ומנהלי הדואר יכולים לפתוח כל תיבת דואר, בלי רשות של השולח.
- eDiscovery והקפאה משפטית. הקפאה כזו קיימת כדי למנוע מחיקה של הודעות. אי אפשר להסיר סיסמה שנתפסה בה.
- העברה הלאה וצילומי מסך. כל עותק אפשר להעתיק שוב, ומספר המקומות שבהם נמצאת סיסמה בטקסט גלוי רק עולה.
- תצוגות מקדימות של קישורים וסורקי אבטחה. אפליקציות צ'אט ושערי אימייל ניגשים לכל כתובת URL ברגע שהיא מתפרסמת. בוט התצוגה המקדימה מוחק קישור סודי שלא תוכנן לזה עוד לפני שאדם פותח אותו. ראו איך LinkPilot מונע את זה.
- החלפת SIM והצצה מעבר לכתף ב-SMS, ולספק הסלולרי יש עותק משלו.
הפתרון אינו כלי צ'אט טוב יותר. צריך לשנות את מה שעובר בערוץ: הפניה שמתה, לא הערך עצמו. עוד על כך במאמר למה כתובות URL מדליפות מידע רגיש.
מנהל סיסמאות או קישור חד-פעמי? מתי להשתמש בכל אחד
הם משלימים זה את זה ולא מתחרים. כספת היא אחסון, וקישור חד-פעמי הוא מסירה. הכספת שומרת את פרטי ההתחברות כל עוד הצוות צריך אותם, והקישור מעביר אותם למישהו פעם אחת ולא משאיר אחריו כלום.
אם ישתמשו בפרטי ההתחברות שוב ושוב בתוך הארגון, שתפו את הפריט בכספת. אם הם צריכים להגיע לאדם אחד פעם אחת, במיוחד למישהו מחוץ לכספת, שלחו קישור חד-פעמי. הדפוס השגוי הוא אימייל או צ'אט לכל אחת מהמשימות. עוד על כך במאמר קישורים סודיים מול מנהלי סיסמאות.
איך קישור סודי חד-פעמי עובד בפועל
אין כאן הבטחות ל"הצפנה ברמה צבאית". זה המודל האמיתי, והוא תואם שורה אחר שורה את עמוד ארכיטקטורת האבטחה שלנו. אם יש ביניהם סתירה, העמוד ההוא קובע.
ההצפנה נעשית בדפדפן שלכם
מאז 29 בספטמבר 2026 התוכן מוצפן בצד הלקוח ב-AES-GCM-256, עם מפתח של 256 ביט שנוצר בדפדפן שלכם, לפני ששום דבר נשלח. מה שמגיע אלינו הוא טקסט מוצפן, בטבלה secret_links שמבודדת מהטבלאות של סטטיסטיקות הקליקים. קבצים מצורפים מוצפנים באותה דרך, במפתח שנגזר מהמפתח של הסוד עצמו, כך שקישור אחד פותח את שניהם. הפרטים ההנדסיים: הצפנה בצד הלקוח לשיתוף סודות.
המפתח נמצא בחלק של הקישור שאחרי הסימן #
קישור השיתוף נראה כך: shrd.link/s/<slug>#k=<key>. כל מה שאחרי הסימן # הוא מפתח הפענוח, ודפדפנים אף פעם לא שולחים את החלק הזה לשום שרת: לא אלינו ולא ל-CDN שמגיש את עמוד ההצגה. המפתח אף פעם לא מגיע אלינו, ולכן אנחנו לא יכולים לקרוא את הסוד, לשחזר אותו אם הקישור אבד או ליצור מחדש את הכתובת אחר כך. במילים פשוטות: מי שמחזיק בקישור המלא מחזיק במפתח.
ביטוי סיסמה מוסיף גורם שני
בתוכנית Pro ביטוי הסיסמה עובר הקשחה ב-PBKDF2-SHA256 (210,000 איטרציות) ומשולב עם המפתח שבקישור דרך HKDF-SHA256, כך שלא הקישור לבדו ולא ביטוי הסיסמה לבדו מפענחים את הסוד. השרת מקבל גם hash מסוג SHA-256 של ביטוי הסיסמה, כדי שיוכל לסרב להחזיר את הטקסט המוצפן למי שלא יודע אותו. ביטוי הסיסמה עצמו אף פעם לא נכתב למסד הנתונים או ליומנים שלנו. מספר הניסיונות מוגבל ל-5 בדקה לכל כתובת IP ולכל סוד, וכל כישלון נרשם ביומן הביקורת. להשוואה, NIST SP 800-63B מחייב לשמור סודות שמשתמשים זוכרים עם salt ו-hash, באמצעות פונקציה לגזירת מפתח כמו PBKDF2, ב-10,000 איטרציות לפחות.
מחיקה לאחר קריאה היא פעולה אטומית
קישור עם מחיקה לאחר קריאה נותן לנמען הזדמנות אחת לראות את התוכן. הצפייה נרשמת דרך פונקציה אחת במסד הנתונים עם נעילה ברמת השורה, כך ששני אנשים שפותחים את הקישור באותו רגע לא יכולים לקרוא אותו שניהם. כשמגיעים למגבלת הצפיות, הסטטוס משתנה לנמחק והתוכן השמור נדרס בערך [REDACTED]. ביקורים מאוחרים יותר מקבלים HTTP 410 ועמוד ברור שאומר שהתוכן כבר נצפה. סודות שתוקפם פג ושבוטלו נמחקים באותה דרך, ובכוונה אין דרך לשחזר אותם.
תצוגה מקדימה של הקישור לא יכולה למחוק אותו
בקשת GET לנקודת הקצה של ההצגה מחזירה רק מטא-נתונים: הסטטוס והאם נדרש ביטוי סיסמה. צפייה נרשמת רק בבקשת POST מפורשת, שאדם מפעיל כשהוא לוחץ על הצגה, וכל תגובה של הצגה כוללת את הכותרת Cache-Control: no-store. אפליקציות צ'אט ושערי אבטחה של אימייל ניגשים לקישורים בבקשות GET רגילות, ולכן התצוגות המקדימות שלהם לא רואות כלום ולא מוחקות כלום. בדיקה שאפשר להריץ בעצמכם: סורקי קישורים וסודות חד-פעמיים.
מה אנחנו עדיין רואים: שלוש מגבלות, בכנות
- סודות שנוצרו לפני 29 בספטמבר 2026 נשמרו כטקסט גלוי עד שתוקפם פג. הם אף פעם לא נכתבו מחדש בשקט: הם המשיכו לעבוד כמו קודם ונמחקו כשתוקפם פג. מפעיל מערכת יכול היה לקרוא סוד כזה כל עוד היה פעיל. קבצים מצורפים שהועלו לפני התאריך הזה נשארו שמורים כקבצים לא מוצפנים.
- מי שמחזיק בקישור המלא מחזיק במפתח. הצפנה בצד הלקוח מוציאה אותנו, את מסד הנתונים שלנו ואת שרתי הקצה שלנו ממעגל האמון. היא לא מגינה על קישור שהועבר הלאה, צולם במסך או נרשם ביומן אצל הנמען.
- השם, הגודל והסוג של קובץ גלויים לנו. אלה עמודות של מטא-נתונים, והתוכן לא. בכל ניסיון הצגה אנחנו שומרים גם חותמת זמן, hash של כתובת ה-IP (SHA-256 עם salt שמתחלף כל יום, מקוצר), מיקום גאוגרפי כללי ואת ה-user-agent. אף פעם לא את הסוד, את ביטוי הסיסמה המקורי או את כתובת ה-IP המקורית, ואין עוגיות אצל הנמען.
יומני ביקורת ועמידה בתקנות: מה מבקר שואל
כשפרטי התחברות עוברים מיד ליד, מבקר שואל שלושה דברים: מי שלח מה ולמי, האם זה נפתח, ואיך מוכיחים שזה כבר לא קיים. כספת עונה על השאלה הראשונה לגבי אנשים מבפנים. קישור חד-פעמי עם יומן ביקורת עונה על שלושתן לגבי המסירה.
- אירועים לכל סוד. לכל סוד יש יומן משלו: נוצר, נצפה, ניסיון כושל להזין ביטוי סיסמה, נמחק, פג תוקף ובוטל, כל אירוע עם חותמת זמן ו-hash של כתובת ה-IP. צפייה שלא ציפיתם לה היא יירוט שאחרת לא הייתם יודעים עליו. החליפו את פרטי ההתחברות.
- הוכחה שהמידע לא נשמר. התוכן של סודות שנמחקו, שתוקפם פג או שבוטלו נדרס במסד הנתונים, ולא רק מסומן. המשפט "הסיסמה כבר לא נמצאת בשום מקום" נשען על ההתנהגות הזו, לא על הבטחה.
- צמצום מידע. אין כתובות IP גולמיות, אין עוגיות אצל הנמען, ותוכן הסודות לא מגיע לסטטיסטיקות או לתכונות AI. הצינורות מופרדים ברמת הנתונים וברמת הקוד. עמוד ה-GDPR שלנו מתעד את המדיניות, ועמוד השקיפות מפרט את הבקשות שאנחנו מקבלים.
- גבולות ברורים. LinkPilot לא מצהיר על אישורי SOC 2, HIPAA או PCI DSS לקישורים סודיים. התייחסו אליו כאל ערוץ מסירה מבוקר בתוך תוכנית העמידה בתקנות שלכם, הכלי שמחליף אימייל וצ'אט, ולא כאל מערכת רשומות מאושרת.
עובדות על התוכניות, כדי שאף אחד לא יגלה מגבלה רק אחרי הלחיצה: תוכנית Free כוללת 5 קישורים סודיים פעילים עם מחיקה לאחר קריאה ותפוגת ברירת המחדל. ביטויי סיסמה, תפוגה מותאמת אישית ויומן הביקורת המלא זמינים בתוכנית Pro, ב-$29 לחודש. ביטול קישור דורש חשבון, כי לכלי האנונימי אין לוח בקרה. הפרטים בעמוד המחירים.
אם אתם מפעילים MSP: קליטה, מסירות וסיום התקשרות
ספק שירותים מנוהלים משתף פרטי התחברות בשלושה מצבים שחוזרים על עצמם, ולכל אחד מהם צורה אחרת. הטבלה מראה איזו שיטה מתאימה, לפי אותו היגיון כמו בשאר המדריך: כמה זמן פרטי ההתחברות מתקיימים ומי צריך אותם.
| מצב | במה להשתמש | למה |
|---|---|---|
| קליטת לקוח: סיסמת המנהל הראשונה, התחברות לנתב, חשבון global admin ב-M365 | קישור סודי חד-פעמי, וביטוי הסיסמה נשלח בטלפון או ב-SMS | ללקוח אין מושב בכספת שלכם. קישור שנמחק בקריאה הראשונה לא משאיר כלום בתיבת הדואר שלו, וביטוי הסיסמה בערוץ שני אומר שאימייל שיורט לבדו לא מועיל. |
| מסירת פרטי התחברות בין הטכנאים שלכם (כרטיס עובר מיד ליד, החלפת תורנות) | כספת משותפת לפרטי ההתחברות הקבועים, וקישור חד-פעמי לערך החדש אחרי החלפה | הכספת שומרת את הערך העדכני במקום אחד. כשמחליפים אותו, הערך החדש עובר פעם אחת ומושמד. |
| סיום עבודה עם לקוח או עם טכנאי | החליפו את הסיסמאות בכספת, אחר כך הסירו את הגישה, ובטלו מלוח הבקרה כל קישור שלא נקרא | קישור שאף פעם לא נפתח הוא פרטי התחברות שעדיין בדרך. מהר יותר לבטל אותו מאשר לנחש אם נקרא. |
| הוכחה לביקורת או לשאלון אבטחה של לקוח | היומן של כל סוד (Pro) | נוצר, נצפה, נמחק, פג תוקף ובוטל, כל אירוע עם חותמת זמן: כך עונים על השאלה "למי הייתה גישה ומתי" בלי לחפש בצ'אט. |
שתי הערות מעשיות. הראשונה: האפליקציה LinkPilot ל-Slack יוצרת סודות חד-פעמיים מהערוץ שבו הטכנאים כבר עובדים, כך שההרגל לשלוח קישורים לא תלוי בכך שמישהו יזכור אתר. השנייה: מחולל הקישורים הסודיים החד-פעמיים החינמי לא דורש חשבון. זה שימושי כשאנשי הצוות של לקוח צריכים לשלוח לכם סיסמה: שלחו להם קישור לכלי, ולא בקשה להדביק אותה בצ'אט.
מדיניות לשיתוף סיסמאות שאפשר להעתיק
רוב הדליפות של פרטי התחברות בצוותים קטנים נובעות מהרגלים, לא מתוקפים. שישה כללים מבטלים את ההרגל. העתיקו אותם למדריך העובדים כמו שהם.
מדיניות שיתוף פרטי התחברות
- סיסמאות, מפתחות API, טוקנים ומחרוזות חיבור אף פעם לא נכתבים באימייל, בצ'אט או ב-SMS. אף לא פעם אחת, וגם לא "רק הפעם".
- פרטי התחברות משותפים לטווח ארוך נשמרים בכספת של הצוות. משתפים את הפריט בכספת, לא את הערך.
- מסירות חד-פעמיות נעשות בקישור סודי חד-פעמי, עם התפוגה הקצרה ביותר שעדיין מעשית ועם מחיקה לאחר קריאה פעילה.
- הקישור וביטוי הסיסמה עוברים בערוצים שונים, הקישור באימייל וביטוי הסיסמה בטלפון או בהודעה פרטית בצ'אט, ואף פעם לא משתמשים שוב באותו ביטוי סיסמה.
- בקליטה, פרטי ההתחברות הראשונים של עובד חדש מגיעים בקישורים חד-פעמיים ומוחלפים בהתחברות הראשונה. כשעובד מחליף תפקיד או עוזב, הגישה שלו לכספת מתעדכנת באותו יום, וכל פרטי התחברות שהיו בידיו מחוץ לכספת מוחלפים.
- כל דבר שאי פעם הודבק בצ'אט או באימייל מוחלף בפעם הבאה שנוגעים בו, וההודעה בצ'אט נמחקת. כל צפייה לא צפויה ביומן של סוד מחייבת החלפה מיידית.
ספקים וקבלנים מקבלים את אותו יחס, עם תוספת אחת: לפרטי ההתחברות שלהם בכספת נקבע תאריך תפוגה שזהה לתאריך סיום החוזה, והם מוחלפים כשהתאריך עובר.
צרו עכשיו קישור חד-פעמי לסיסמה
הדביקו את הסיסמה, קבעו תפוגה ושלחו את הקישור. לסוד בסיסי לא צריך חשבון. חשבון מוסיף ביטול קישורים ויומן, ותוכנית Pro מוסיפה ביטויי סיסמה ותפוגה מותאמת אישית.
מקורות
- Slack: התאמה אישית של מדיניות שמירת הודעות וקבצים ("הנתונים נשמרים כברירת מחדל כל עוד סביבת העבודה קיימת")
- FBI IC3: עבריינים מרחיבים את השימוש בהונאות החלפת SIM כדי לגנוב מיליוני דולרים מהציבור בארה"ב (הודעה לציבור, 8 בפברואר 2022)
- NIST SP 800-63B: הנחיות לזהות דיגיטלית, אימות וניהול מחזור חיים, §5.1.1.2 מאמתים של סודות שמשתמשים זוכרים
- Bitwarden: על Send (פריטי Send של טקסט וקבצים, תפוגה, מספר גישות)
- LinkPilot: ארכיטקטורת האבטחה (התיאור המחייב של המודל שמתואר למעלה)