QA ובקרת שחרורים

בדיקות חדירה

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

מי מזמין בדיקת חדירה

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

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

היקף וכללי עבודה אופייניים

היקף להמחשה למוצר ווב; ההיקף שלכם מוסכם ונחתם לפני תחילת הבדיקות.

  • בהיקף

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

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

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

ראו את המוצר שלכם כמו שתוקף רואה אותו

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

איסוף מידע בסיוע AI, ניצול חולשות בהובלה אנושית

איך ה-AI מסייע

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

מה באחריות המומחים שלנו

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

מה תקבלו

בדיקות בהיקף מוגדר, ראיות ברורות ובדיקות חוזרות

  • בדיקות אפליקציות ווב

    אימות זהות, בקרת גישה, הזרקות, Cross-Site Scripting, זיוף בקשות (request forgery) ופגמים בלוגיקה העסקית, לפי הנחיות הבדיקה של OWASP.

  • בדיקות חדירה ל-API

    הרשאות פגומות ברמת האובייקט וברמת הפונקציה, Mass Assignment, הזרקות וחולשות בטוקנים בממשקי REST ו-GraphQL.

  • סקירת ענן ותשתית

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

  • בדיקות לפיצ'רים של AI

    Prompt Injection, דליפת נתונים דרך תשובות, והרשאות רחבות מדי לכלים או לנתונים בצ'אטבוטים, בסוכנים ובפיצ'רים אחרים מבוססי LLM.

  • דוח מבוסס ראיות

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

  • בדיקה חוזרת של תיקונים

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

איך מתנהלת בדיקת חדירה

  1. 01

    היקף וכללים

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

  2. 02

    איסוף מידע

    מיפוי משטח התקיפה בתוך ההיקף, כולל נתיבים, ממשקי API, תפקידים, טכנולוגיות ושירותים חשופים, עם ניתוח בסיוע AI.

  3. 03

    ניצול מבוקר

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

  4. 04

    דוח ובדיקה חוזרת

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

שתי דרכים לעבוד עם כלי AI

ה-AI עוזר לנסח טיוטות לבדיקות ולחקור באגים. בחרו היכן הוא רשאי לעבד את הקוד ואת נתוני הבדיקה שלכם.

לא בטוחים? נמליץ על אחת מהן בשלב הגדרת ההיקף. השוואת אפשרויות עבודה עם AI

בקשות אופייניות לבדיקות חדירה

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

  • דוח בדיקה בשביל לקוח ארגוני

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

  • חשבון ענן שהוקם בחיפזון

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

  • חולשות קטנות שעלולות להצטבר

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

המגבלות של בדיקת חדירה

  • הבודקים בוחנים את נתיבי התקיפה שפתוחים בחלון הבדיקות; שחרורים מאוחרים יותר ומערכות שמחוץ להיקף עדיין יכולים להכיל חולשות.
  • בדיקת הרשאות של כל נקודת קצה, לכל תפקיד, היא חלק משירות אבטחת API; בדיקת חדירה מתייחסת ל-API כאל אחד מנתיבי הכניסה.
  • השאלה אם פיצ'ר AI עונה היטב, וממשיך לעשות זאת אחרי שינויים במודל או בפרומפט, שייכת לשירות הערכה ובדיקות של AI; אנחנו בודקים אותו כנקודת כניסה.
  • קריאה של קוד המקור שורה אחר שורה היא חלק משירות ביקורת וסקירת קוד; כאן הבודקים תוקפים את המערכת בזמן שהיא רצה.

איך בדיקות האבטחה מתחברות לעיצוב, ל-QA ולתפעול

  • עיצוב: אבטחה שנשארת שמישה

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

  • QA: תיקונים שנשארים מתוקנים

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

  • תפעול: לזהות, לא רק למנוע

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

  • באופן שוטף: בדיקה חוזרת אחרי שינויים גדולים

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

שאלות ותשובות

שאלות נפוצות

האם בדיקת חדירה תפריע למשתמשים שלנו?

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

כמה זמן לוקחת בדיקת חדירה?

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

האם בדיקת חדירה תהפוך אותנו לתואמי רגולציה?

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

איך מטפלים בממצאים ובנתונים שלנו, כולל בכלי AI?

הממצאים נשלחים רק לאנשי הקשר שאתם מגדירים, בערוצים שסוכמו בשלב הגדרת ההיקף. הניתוח בסיוע AI רץ בתוך הגבולות שאתם בוחרים: הנדסת AI פרטית / מקומית על תשתית שבשליטתכם או בסביבה מבודדת שאנחנו מסכמים, או הנדסת Claude Code / OpenAI Codex לפי תנאי טיפול בנתונים ושמירה שסוכמו מול הספק.

גלו למה תוקף יכול להגיע

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