Amazon Bedrock על AWS: אבטחה, תאימות ומי בעולם הפיננסי משתמש בו

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

נבדק ב-2 בנובמבר 2026 מול התיעוד הרשמי של AWS ועמודי ה-case study של AWS.

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

למי זה מיועד

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

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

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

הבעיה בשלוש שורות

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

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

מה זה Amazon Bedrock

לפי התיעוד של AWS, Amazon Bedrock הוא שירות מנוהל במלואו שנותן גישה למודלי בסיס (foundation models) של חברות AI מובילות, כדי לבנות ולהרחיב אפליקציות של בינה מלאכותית יוצרת.

התיעוד מציין יותר מ-100 מודלי בסיס מספקים שונים, ובהם Amazon, Anthropic, DeepSeek, Moonshot AI, MiniMax, OpenAI ו-xAI. בתיאור הקבוע ש-AWS מצרפת לעמודי ה-case study, השירות מתואר כמציע את המודלים האלה דרך API אחד.

נקודה אחת שצריך לזכור מההתחלה: מודל האחריות המשותפת (shared responsibility) של AWS חל על הגנת המידע ב-Bedrock. לפי העמוד הרשמי, AWS אחראית להגן על התשתית שמריצה את השירותים, והאחריות של הלקוח נקבעת לפי השירותים שהוא בוחר. חלק מההגנות ש-AWS נותנת עובדות רק אם אתם מגדירים אותן. ששת הצעדים הבאים עוסקים בדיוק בחלק הזה.

השיטה ב-6 צעדים

צעד 1: הצפנה ומפתחות ב-KMS

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

איך:

לפי השאלות הנפוצות של AWS, הנתונים ב-Bedrock תמיד מוצפנים במעבר ובמנוחה, ואפשר להצפין אותם גם במפתחות שלכם.
תוכן לקוח ש-Bedrock מעבד מוצפן ונשמר במנוחה ב-Region שבו אתם משתמשים בשירות.
בתקשורת עם AWS, AWS דורשת TLS 1.2 וממליצה על TLS 1.3. בדקו שהספריות והשרתים שלכם לא מנסים להתחבר בגרסה ישנה יותר.
לניהול המפתחות, התיעוד מפנה ל-AWS Key Management Service (KMS). עמוד ההצפנה מפרט אילו משאבים אפשר להצפין במפתח שלכם, למשל מודלים מותאמים שנוצרו בעבודות התאמה (customization jobs), סוכנים, עבודות קליטה של מקורות נתונים ל-knowledge base, ועבודות הערכת מודלים.
אפשר להצפין סוכנים (Agents) במפתח שלכם בזמן היצירה, בקונסולה או בשדה customerEncryptionKeyArn בקריאת CreateAgent. כדאי להחליט על זה לפני שיוצרים את הסוכן.

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

צעד 2: רשת פרטית עם VPC endpoint ו-PrivateLink

מה עושים: מחברים את המערכות שלכם ל-Bedrock בחיבור פרטי, בלי לעבור באינטרנט הציבורי, ומגבילים מה מותר לעשות דרך החיבור.

איך:

לפי התיעוד, אפשר להשתמש ב-AWS PrivateLink כדי ליצור חיבור פרטי בין ה-VPC שלכם ל-Bedrock, בלי internet gateway, בלי NAT, בלי VPN ובלי Direct Connect. השרתים ב-VPC לא צריכים כתובת IP ציבורית.
בשאלות הנפוצות AWS מנסחת את זה כך: חיבור פרטי מה-VPC ל-Bedrock בלי לחשוף את הנתונים לתעבורת אינטרנט.
יוצרים interface endpoint, ומצמידים לו endpoint policy. מדיניות ברירת המחדל מאפשרת גישה מלאה ל-Bedrock דרך ה-endpoint, וכדי להגביל אותה צריך להצמיד מדיניות מותאמת.
בתיעוד יש דוגמת מדיניות שמתירה רק bedrock:InvokeModel ו-bedrock:InvokeModelWithResponseStream. היא מופיעה בדוגמה למטה.

טעות נפוצה: ליצור endpoint ולהשאיר את מדיניות ברירת המחדל. החיבור פרטי, אבל כל פעולה ב-Bedrock עדיין מותרת דרכו.

דוגמה להמחשה · הנתונים בדויים

מדיניות VPC endpoint שמתירה רק הסקה

דוגמת ה-endpoint policy מהתיעוד של AWS, כפי שהיא. מחליפה את ברירת המחדל שמאפשרת גישה מלאה

{
   "Version":"2012-10-17",
   "Statement": [
      {
         "Principal": "*",
         "Effect": "Allow",
         "Action": [
            "bedrock:InvokeModel",
            "bedrock:InvokeModelWithResponseStream"
         ],
         "Resource":"*"
      }
   ]
}

צעד 3: שימוש בנתונים, אימון מודלים וגישה של ספקי המודלים

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

איך:

לפי השאלות הנפוצות, AWS וספקי המודלים לא ישתמשו בקלט או בפלט של Bedrock כדי לאמן את Amazon Nova, את Amazon Titan או מודלים של צד שלישי.
עוד שם: התוכן שלכם לא משמש לשיפור מודלי הבסיס ולא משותף עם ספקי המודלים.
התיעוד מסביר את המנגנון: בכל Region יש Model Deployment Account לכל ספק מודל, בבעלות צוות Bedrock ובתפעולו. לספקי המודלים אין גישה לחשבונות האלה, ולכן אין להם גישה ללוגים של Bedrock או לפרומפטים ולתשובות של הלקוחות.
ההסתייגות: עמוד זיהוי השימוש לרעה אומר ש-במקרים מוגבלים AWS עשויה גם לשמור או לבדוק קלט ופלט של מודלים. זה חל על מודלים מסוימים שמפורטים בעמוד, לא על כל המודלים. ברוב המודלים של OpenAI, תעבורה שסומנה על ידי מסווג נשמרת עד 30 יום לזיהוי אוטומטי של שימוש לרעה. ב-Anthropic Claude Fable 5 וב-Claude Fable 5.1, כל התעבורה נשמרת עד 30 יום, ותעבורה שסומנה על ידי מסווג עשויה לעבור בדיקה אנושית של AWS. קלט ופלט שנשמרים כך מאוחסנים ומעובדים על ידי AWS, ולא משותפים עם ספקי המודלים.
השליטה אצלכם: Bedrock נותן לכם שליטה מפורשת אם הפרומפטים והפלטים של בקשות ההסקה נשמרים. קראו את העמוד, בדקו מה ההגדרה בכל Region שאתם עובדים בו, ובדקו אם המודל שבחרתם נמצא ברשימת השמירה בעמוד זיהוי השימוש לרעה.
לשכבה נוספת על התוכן עצמו, Amazon Bedrock Guardrails מספק אמצעי הגנה שאפשר להגדיר. AWS נותנת שם דוגמה בנקאית: אפליקציה שחוסמת שאלות או תשובות שקשורות לבקשה או למתן ייעוץ השקעות לא חוקי.

טעות נפוצה: לכתוב במסמך הסיכונים "Bedrock לא שומר את הפרומפטים" בלי הסתייגות. הנוסח המדויק: AWS וספקי המודלים לא מאמנים על הקלט והפלט, ספקי המודלים לא מקבלים אותם, אבל במודלים מסוימים שמפורטים בעמוד זיהוי השימוש לרעה AWS עשויה לשמור אותם עד 30 יום (ברוב המודלים של OpenAI, תעבורה שסומנה על ידי מסווג; ב-Claude Fable 5 ו-5.1, כל התעבורה), ואתם שולטים בהגדרות השמירה.

צעד 4: Regions ו-cross-Region inference

מה עושים: מחליטים באיזה Region עובדים, והאם מותר שבקשה תעובד ב-Region אחר.

איך:

ב-cross-Region inference בוחרים פרופיל שקשור לאזור גיאוגרפי (למשל US או EU) או פרופיל גלובלי. בפרופיל גיאוגרפי Bedrock בוחר AWS Region מסחרי בתוך האזור, ובפרופיל גלובלי הוא בוחר AWS Region מסחרי.
בפרופיל גיאוגרפי, בקשות לפרופיל שקשור לאזור גיאוגרפי (למשל US, EU ו-APAC) נשארות בתוך האזור הזה. הפרומפטים והתשובות עשויים לצאת מה-Region שממנו שלחתם, ואם נשמר מידע לזיהוי שימוש לרעה, הוא נשמר ב-Region היעד.
כל המידע שעובר בין Regions נשאר ברשת של AWS ולא עובר באינטרנט הציבורי, והוא מוצפן במעבר.
כשיש דרישות למיקום הנתונים, AWS ממליצה לבחור ב-cross-Region inference גיאוגרפי.
כדי לדעת איפה בקשה עובדה בפועל: CloudTrail רושם את כל בקשות ה-cross-Region inference ב-Region המקור, בשדה additionalEventData.inferenceRegion.
אם הארגון חוסם Regions לא בשימוש עם SCP, צריך לאפשר את כל Regions היעד של הפרופיל הגיאוגרפי, או להוסיף חריגה לפרופיל ההסקה.

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

צעד 5: הרשאות IAM

מה עושים: נותנים לכל אפליקציה הרשאה רק לפעולות ולמודלים שהיא צריכה.

איך:

נקודת הפתיחה: כברירת מחדל למשתמשים ולתפקידים אין הרשאה ליצור או לשנות משאבי Bedrock, ומנהל IAM צריך ליצור מדיניות שנותנת אותה.
בעמוד דוגמאות המדיניות יש דוגמה שמתירה bedrock:InvokeModel ו-bedrock:InvokeModelWithResponseStream על מודל provisioned אחד, ו-דוגמה שחוסמת הסקה על מודל בסיס מסוים, שאפשר להשתמש בה גם כ-SCP לכל הארגון. בדוגמה למטה יש מדיניות שמשלבת את המבנה של הראשונה עם פורמט המשאב של השנייה.
אם עובדים עם פרופילי cross-Region inference, התיעוד מציע להשתמש בתנאי bedrock:InferenceProfileArn כדי להגביל את החריגה לפרופילים מסוימים.

טעות נפוצה: לתת bedrock:* על כל המשאבים "רק לפיתוח", ולשכוח לצמצם לפני שעוברים לייצור. מתחילים מהרשאה צרה ומרחיבים רק כשיש צורך.

דוגמה להמחשה · הנתונים בדויים

מדיניות IAM למודל בסיס אחד

מותאמת משתי דוגמאות של AWS: מבנה ה-Allow מהדוגמה למודל provisioned, ופורמט המשאב מהדוגמה שחוסמת מודל בסיס. זו לא דוגמה רשמית של AWS. מחליפים את {{model-id}} ובודקים בחשבון שלכם לפני שימוש. אם קוראים למודל דרך פרופיל cross-Region inference, המדיניות הזאת לבדה לא מספיקה: צריך להתיר גם את פרופיל ההסקה (ראו https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html)

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "AllowOneFoundationModel",
            "Effect": "Allow",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": "arn:aws:bedrock:*::foundation-model/{{model-id}}"
        }
    ]
}

צעד 6: לוגים עם CloudTrail ו-model invocation logging

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

איך:

Bedrock משולב עם AWS CloudTrail, ו-CloudTrail רושם את כל קריאות ה-API של Bedrock כאירועים.
הקריאות InvokeModel, InvokeModelWithResponseStream, Converse ו-ConverseStream נרשמות כ-management events.
לשמירת נתוני הבקשות והתשובות יש model invocation logging. היעדים הנתמכים הם Amazon CloudWatch Logs ו-Amazon S3, ורק באותו חשבון ובאותו Region.
model invocation logging כבוי כברירת מחדל. אחרי שמפעילים אותו, הלוגים נשמרים עד שמוחקים את הגדרת הלוגים.

טעות נפוצה: להפעיל model invocation logging ולשכוח שהלוגים עצמם מכילים עכשיו נתוני לקוחות. ה-bucket או קבוצת הלוגים צריכים הצפנה, הרשאות צרות ומדיניות מחיקה, בדיוק כמו המערכת המקורית. וההפך: אם הוחלט לא לשמור תוכן, כותבים את ההחלטה ואת הנימוק.

דוגמה להמחשה · הנתונים בדויים

הצ'קליסט של ארנק צפון (חברת פינטק בדויה)

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

נושא	מה הוחלט	מצב
הצפנה	TLS 1.2 ומעלה בכל השירותים. מפתח KMS ייעודי לפרויקט, key policy לתפקיד האפליקציה ולתפקיד האבטחה בלבד	✓
רשת	שרת הסיכומים ב-subnet פרטי. interface endpoint עם מדיניות שמתירה רק הסקה	✓
נתונים	טלפונים ומספרי כרטיס מוחלפים לפני השליחה. Guardrail עם מסנן מידע רגיש	✓
שמירה	נבדק אם המודל ברשימת זיהוי השימוש לרעה. הגדרת השמירה ב-Region נבדקה ותועדה	✓
Regions	Region אחד באירופה. cross-Region inference רק בפרופיל גיאוגרפי של EU. SCP עודכן	✓
IAM	תפקיד ייעודי, InvokeModel ו-InvokeModelWithResponseStream על מודל אחד	✓
לוגים	CloudTrail פעיל. model invocation logging ל-S3 מוצפן, גישה לצוות האבטחה, מחיקה אחרי 90 יום	✓
תאימות	דוח SOC 2 ותעודת ISO 27001 הורדו מ-AWS Artifact ונכנסו לתיק הספקים	✓
אישור	קצין הציות ואיש אבטחת המידע חתמו על מסמך הסיכונים	ממתין

תאימות ותקנים

לפי השאלות הנפוצות, Bedrock נמצא ב-scope של תקני תאימות נפוצים כמו FedRAMP Moderate, SOC ו-ISO, הוא HIPAA eligible, ולקוחות יכולים להשתמש בו באופן שתואם GDPR.

הפירוט לפי תוכנית, כפי שהוא מופיע בעמודי Services in Scope ובעמודים הרשמיים של AWS:

תוכנית	מה AWS מפרסמת על Bedrock	מקור
SOC 1, 2, 3	ב-scope של דוחות SOC 1, 2, 3	Services in Scope: SOC
PCI	מסומן ב-PCI DSS וב-PCI 3DS. לא מסומן ב-PCI PIN וב-PCI P2PE	Services in Scope: PCI
FedRAMP	מסומן ב-Class C (לשעבר Moderate, East/West) וב-Class D (לשעבר High, GovCloud)	Services in Scope: FedRAMP
DoD SRG	מסומן ב-IL2, IL4, IL5 ו-IL6, לפי Region	Services in Scope: DoD
ISO ו-CSA STAR	ברשימת השירותים בעמוד ההסמכות של ISO/IEC 27001, 27017, 27018, 27701, 22301, 20000-1, 9001 ו-CSA STAR CCM v4.0	ISO certified
HITRUST CSF	מסומן	Services in Scope: HITRUST CSF
HIPAA	ברשימת השירותים שהם HIPAA eligible	HIPAA Eligible Services Reference

שלוש הערות לטבלה:

ברוב השורות כתוב ליד Bedrock excludes Amazon Bedrock Marketplace. אם אתם משתמשים במודלים מ-Marketplace, בדקו אותם בנפרד.
רשימת ה-ISO מופיעה גם בשאלות הנפוצות של Bedrock. את CSA STAR מצאנו רק בעמוד ההסמכות המשותף של ISO ו-CSA STAR, לא כרשומה נפרדת.
HIPAA eligible פירושו שהשירות מתאים לעומסי עבודה עם מידע רפואי מוגן (ePHI). זה לא אומר שהמערכת שלכם עומדת ב-HIPAA.

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

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

ארגונים פיננסיים שמדווחים בפומבי

אלה ארגונים פיננסיים ש-AWS פרסמה עליהם case study שמתאר שימוש ב-Bedrock. התיאור כאן מקוצר ונשען רק על מה שכתוב בעמוד.

ארגון	מה פורסם	מקור
Robinhood	מודולים לתחקירי פשיעה פיננסית (FinCrimes) שמשתמשים במודלי שפה שרצים ב-Bedrock. לפי העמוד, המודלים רצים ב-VPC של Robinhood, כך שהמידע הרגיש נשאר בשליטתה	AWS case study
Chime	סיכום של כל שיחת שירות לקוחות בתוך שניות, עם מודלי Claude ב-Bedrock	AWS case study
BankUnited	מודל שאלות ותשובות עם Claude 2 ב-Bedrock. לפי העמוד: דיוק של 95 אחוז וזמני תגובה של פחות מ-10 שניות	AWS case study
Coast Capital Savings	צ'אטבוט פנימי לעובדים. לפי העמוד, אב טיפוס עובד נבנה ב-3 שבועות והורחב אחר כך לתוכן של משאבי אנוש	AWS case study
Nomura	שיתוף פעולה עם AWS Generative AI Innovation Center לשיפור הציות והיעילות התפעולית דרך Bedrock	AWS case study
Broadridge	פתרונות בינה מלאכותית יוצרת על Bedrock: צ'אטבוט למעורבות עובדים, פלטפורמה לסיכום מסמכים, וארכיטקטורת Retrieval Augmented Generation (RAG) מבוססת Bedrock	AWS case study
nCino	שימוש ב-Bedrock כחלק מהמעבר לבנקאות מבוססת סוכנים	AWS case study

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

צ'קליסט לעמוד אחד

הצפנה

TLS 1.2 לפחות בכל החיבורים ל-AWS
רשימה של משאבי Bedrock, ולכל אחד: איזה מפתח KMS מצפין אותו
key policy שמגבילה מי משתמש במפתח

רשת

interface endpoint דרך PrivateLink
endpoint policy מותאמת, לא ברירת המחדל
השרתים שקוראים ל-Bedrock בלי כתובת IP ציבורית

נתונים

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

Regions

Region ראשי נבחר ותועד
החלטה מתועדת על cross-Region inference: בלי, גיאוגרפי או גלובלי
SCP מעודכן אם יש חסימת Regions

IAM

לכל אפליקציה תפקיד משלה
הרשאה רק לפעולות ההסקה ולמודלים שבשימוש
אין bedrock:* בייצור

לוגים

CloudTrail פעיל ונשמר
החלטה מתועדת על model invocation logging
אם הופעל: יעד מוצפן, הרשאות צרות ומדיניות מחיקה

תאימות

הדוחות הרלוונטיים הורדו מ-AWS Artifact
נבדק שהתוכניות שהארגון צריך מסמנות את Bedrock, ושלא מדובר ב-Marketplace

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

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

דוגמה מלאה: ארנק צפון (ארגון בדוי)

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

הנה איך הצוות עובר על ששת הצעדים.

צעד 1, הצפנה. הצוות בודק שכל השירותים הפנימיים מתחברים ב-TLS 1.2 ומעלה. הוא יוצר מפתח KMS ייעודי לפרויקט, ומגדיר ב-key policy שרק תפקיד האפליקציה ותפקיד האבטחה יכולים להשתמש בו. בשלב הראשון אין סוכנים ואין knowledge base, אבל ההחלטה נרשמת: אם יתווספו, הם יוצפנו באותו מפתח כבר ביצירה.

צעד 2, רשת. שרת הסיכומים יושב ב-subnet פרטי, בלי כתובת ציבורית. הצוות יוצר interface endpoint ל-Bedrock ומצמיד לו מדיניות שמתירה רק הסקה. מדיניות ברירת המחדל מוחלפת לפני שהשרת מתחיל לשלוח בקשות.

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

צעד 4, Regions. הצוות בוחר Region אחד באירופה. גורם הציות מאשר cross-Region inference רק בפרופיל גיאוגרפי של EU, אם יש כזה למודל שנבחר, ולא בפרופיל גלובלי. ה-SCP של הארגון מעודכן כך שיאפשר את Regions היעד של הפרופיל.

צעד 5, IAM. לשרת הסיכומים יש תפקיד IAM משלו, עם הרשאה ל-bedrock:InvokeModel ול-bedrock:InvokeModelWithResponseStream על מודל אחד בלבד. אין לו הרשאה ליצור סוכנים, לשנות הגדרות לוגים או לגשת למודלים אחרים.

צעד 6, לוגים. CloudTrail כבר פעיל בחשבון. הצוות מפעיל model invocation logging ל-bucket ייעודי ב-S3, מוצפן באותו מפתח KMS, עם גישה לצוות האבטחה בלבד ומחיקה אוטומטית אחרי 90 יום. ההחלטה על 90 יום היא של ארנק צפון, לא של AWS.

תאימות. קצין הציות מוריד מ-AWS Artifact את דוח SOC 2 ואת תעודת ISO 27001, ומצרף אותם לתיק הספקים. בתיק כתוב במפורש: הדוחות מכסים את התשתית של AWS. ההגדרות של ארנק צפון נבדקות בנפרד, בבדיקה פנימית לפני העלייה לאוויר ופעם ברבעון אחר כך.

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

הבהרה

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

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

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

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

רוצים שנעשה את זה איתכם? aviad@gindiinnovation.com · gindiinnovation.com

לשיחה עם אביעד WhatsApp aviad@gindiinnovation.com