הצפנה ואימות ב־Amazon S3: סקירה מלאה

תאריכי המאמר: פורסם במקור באנגלית ב־16 במאי 2026. התרגום והבדיקה הטכנית הראשונים נערכו ב־25 באוקטובר 2026; התרגום נבדק שוב ועודכן מול המקור האנגלי המתוקן ב־27 באוקטובר 2026. תאריכי התרגום והעדכון אינם תאריך הפרסום המקורי.

מקור המאמר: לקריאת הגרסה המקורית באנגלית.

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

מבוא: למה אבטחת S3 חשובה

Amazon S3, ראשי תיבות של Simple Storage Service, משמש לאחסון אובייקטים כגון גיבויי יישומים, קובצי מדיה, רשומות רפואיות ונתונים כספיים. הגדרת הרשאות שגויה עלולה לחשוף מידע גם כאשר הוא מוצפן במנוחה. לכן חשוב שכל מי שמתכננים או מפתחים ב־AWS יבינו הן את ההצפנה והן את מודל האימות וההרשאות של S3.

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

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

Amazon S3: סקירת ארכיטקטורת האבטחה

הצפנה במנוחה

• SSE-S3 — מפתחות בניהול Amazon S3
• SSE-KMS — שירות ניהול המפתחות של AWS
• SSE-C — מפתחות שמספק הלקוח
• DSSE-KMS — שתי שכבות הצפנה בצד השרת
• CSE — הצפנה בצד הלקוח

אימות והרשאות

• מדיניות IAM המבוססת על זהות
• מדיניות דלי המבוססת על משאב
• כתובות חתומות מראש; עוגיות חתומות דרך CloudFront (תיעוד העוגיות החתומות של CloudFront)
• מדיניות נקודת קצה של VPC
• הגדרות חסימת גישה ציבורית

בתעבורה

אכיפת HTTPS באמצעות תנאי במדיניות הדלי

ביקורת

יומני גישה ואירועי CloudTrail בהתאם לתצורה

שמירה ותאימות

Object Lock לשמירה בלתי ניתנת לשינוי; ניהול גרסאות ושחזור בנפרד

הצפנה במנוחה: הסבר על כל האפשרויות

SSE-S3: הצפנה בצד השרת עם מפתחות בניהול Amazon S3

מאז ינואר 2023, כל העלאה חדשה ל־S3 מוצפנת אוטומטית לפחות ב־SSE-S3, אלא אם הוגדרה אפשרות הצפנה אחרת. אובייקטים מוצפנים באמצעות AES-256 ומפתחות נתונים ש־S3 מנהל ומגן עליהם. ההצפנה הבסיסית אינה מחייבת ניהול מפתחות מצד היישום או תשלום נוסף עבורה. אין להסיק מכך שאובייקטים היסטוריים הוצפנו מחדש או שהרשאות הגישה שלהם תקינות.

מתי להשתמש ב־SSE-S3: כאשר דרושה הצפנה בסיסית ואין דרישה לשליטה במפתח באמצעות KMS או לביקורת נפרדת של פעולות במפתח.

SSE-KMS: הצפנה בצד השרת באמצעות מפתחות AWS KMS

SSE-KMS מוסיפה בקרות לניהול המפתחות באמצעות AWS Key Management Service ‏(KMS). בין היתר:

• בקרת גישה נפרדת למפתח באמצעות מדיניות KMS, לצד הרשאות הגישה לאובייקט ב־S3.
• אפשרויות החלפת חומר מפתח אוטומטית, בהתאם לסוג המפתח ולתצורתו.
• תיעוד פעולות KMS נתמכות ב־CloudTrail; שימוש ב־S3 Bucket Keys משנה את תדירות הקריאות ואת פירוט הביקורת.
• שיתוף אובייקטים בין חשבונות באמצעות SSE-KMS דורש מפתח בניהול הלקוח והרשאות מתאימות הן ב־S3 והן ב־KMS. המפתח חייב להיות באותו אזור כמו הדלי. מפתח רב־אזורי אינו שיתוף אוטומטי של מפתח יחיד לכל דלי. דרישות מפתח וגישה בין חשבונות.
• הגנת חומר המפתח באמצעות המנגנונים והמודולים המתועדים של KMS. בדקו את אישורי FIPS העדכניים ואת סוג מאגר המפתחות; אין לזהות כל מפתח KMS עם AWS CloudHSM.

SSE-KMS: דוגמה עם AWS SDK ל־.NET

using Amazon.S3;
using Amazon.S3.Model;

var s3Client = new AmazonS3Client();

// העלאה עם SSE-KMS — החליפו את הדלי ואת ARN המפתח בתצורת בדיקה מורשית
var putRequest = new PutObjectRequest
{
    BucketName = "my-secure-bucket",
    Key = "sensitive-data.json",
    ContentBody = "{ \"secret\": \"data\" }",
    ServerSideEncryptionMethod = ServerSideEncryptionMethod.AWSKMS,
    ServerSideEncryptionKeyManagementServiceKeyId = "arn:aws:kms:us-east-1:123456789012:key/my-key-id"
};

var response = await s3Client.PutObjectAsync(putRequest);
Console.WriteLine($"מפתח SSE-KMS: {response.ServerSideEncryptionKeyManagementServiceKeyId}");


// אכיפת סוג הצפנה במדיניות מחייבת Statement מלא ובדיקת ברירת המחדל.
// אין להעתיק קטע Condition חלקי כמדיניות מוכנה.

SSE-C: הצפנה בצד השרת עם מפתחות שהלקוח מספק

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

• יש לספק את המפתח בבקשות הקריאה והכתיבה הרלוונטיות. אל תשמרו אותו לצד הנתונים באופן שמבטל את ההפרדה האבטחתית.
• אובדן המפתח ללא עותק שניתן לשחזר ממנו הופך את האובייקטים שהוצפנו בו לבלתי ניתנים לשחזור. יש לשמור גם את המיפוי בין מפתח לבין אובייקט וגרסה.
• AWS מחייבת HTTPS לשימוש ב־SSE-C.
• S3 אינו שומר את המפתח; הוא שומר HMAC ממולח לצורך אימות המפתח שנמסר בהמשך.

// SSE-C: דוגמה בלבד. נדרשת תמיכה מפורשת בדלי.
// השתמשו במפתח קיים שנשמר וגובה במנגנון סודות מאובטח.
// אסור לייצר מפתח זמני ולאבד אותו אחרי העלאת הנתונים.
using System;

throw new InvalidOperationException("יש לשלב קודם טעינה מאובטחת ושחזור של מפתח SSE-C בן 32 בתים");
// לאחר שילוב ניהול מפתחות, הגדירו בבקשת PutObjectRequest:
// ServerSideEncryptionCustomerMethod = ServerSideEncryptionCustomerMethod.AES256
// ServerSideEncryptionCustomerProvidedKey = Convert.ToBase64String(keyBytes)
// הדוגמה אינה מפעילה SSE-C בדלי ואינה מעלה קובץ.

DSSE-KMS: הצפנה דו־שכבתית בצד השרת

DSSE-KMS מפעילה שתי שכבות עצמאיות של הצפנת AES-256. לפי תיעוד AWS, השכבה הראשונה משתמשת במפתח נתונים שנוצר ב־KMS, והשנייה במפתח נפרד בניהול S3. השירות עשוי לסייע במילוי דרישה להצפנה רב־שכבתית, אך אינו מעניק לבדו אישור תאימות משפטית. יש להביא בחשבון עלויות ועומס נוסף; S3 Bucket Keys אינם נתמכים ב־DSSE-KMS. אין להניח שהמחיר או מספר הקריאות תמיד כפולים בדיוק. תיעוד ההצפנה הדו־שכבתית.

הצפנה בצד הלקוח — CSE

בהצפנה בצד הלקוח, המידע מוצפן לפני שהוא נשלח ל־S3, והשירות מאחסן את התוכן המוצפן. מודל האמון תלוי גם במיקום היישום, בניהול המפתחות, בהרשאות KMS ובמטא־נתונים שנותרים גלויים; אין הבטחה גורפת ש־AWS לעולם אינה מעורבת בגישה למידע. AWS מספקת את AWS Encryption SDK ואת S3 Encryption Client, שאינו מבוטל כמוצר כולו. בחרו גרסה נתמכת; הדוגמה להלן משתמשת בממשק V4 המתועד ל־.NET ואינה בדיקת שילוב מלאה. ההגדרה RequireEncryptRequireDecrypt מחייבת התחייבות למפתח (key commitment) גם בפענוח, ולכן אינה מפענחת תוכן ישן שהוצפן ללא מנגנון זה. יש לבדוק תאימות ותוכנית מעבר לנתונים קיימים. תיעוד לקוח ההצפנה של S3 עבור .NET.

using System.Collections.Generic;
using Amazon.S3.Model;
using Amazon.Extensions.S3.Encryption;
using Amazon.Extensions.S3.Encryption.Primitives;

// דוגמה לממשק V4 המתועד; דורשת חבילה תואמת, הרשאות ואזור מוגדרים.
// החליפו את מזהה המפתח והדלי רק בסביבת בדיקה מורשית.
var context = new Dictionary<string, string>();
var materials = new EncryptionMaterialsV4(
    "1234abcd-12ab-34cd-56ef-1234567890ab", KmsType.KmsContext, context);
var config = new AmazonS3CryptoConfigurationV4(
    SecurityProfile.V4,
    CommitmentPolicy.RequireEncryptRequireDecrypt,
    ContentEncryptionAlgorithm.AesGcmWithCommitment);
using var client = new AmazonS3EncryptionClientV4(config, materials);
await client.PutObjectAsync(new PutObjectRequest {
    BucketName = "my-bucket",
    Key = "encrypted-file.bin",
    FilePath = "/tmp/file.bin"
});

השוואה בין אפשרויות ההצפנה של S3

מאפיין	SSE-S3	SSE-KMS	DSSE-KMS	SSE-C	CSE
ניהול מפתחות	Amazon S3	AWS KMS	KMS ו־S3, בשתי שכבות	הלקוח	לפי תכנון הלקוח
ביקורת פעולות מפתח	ללא יומן KMS ללקוח	CloudTrail	CloudTrail	לפי ניהול המפתח	לפי הספרייה וניהול המפתח
החלפת חומר מפתח	בניהול השירות	לפי סוג המפתח והתצורה	לפי סוג המפתח והתצורה	באחריות הלקוח	באחריות הלקוח או KMS
תוכן גלוי ב־S3 במהלך עיבוד?	כן, בעיבוד מורשה	כן, בעיבוד מורשה	כן, בעיבוד מורשה	כן, בעיבוד מורשה	תוכן האובייקט מגיע מוצפן
השפעה על ביצועים	הצפנת בסיס מובנית	תלויה בעומס ובקריאות KMS	עיבוד נוסף בשתי שכבות	תלויה בעומס ובניהול המפתח	תלויה בלקוח ובספרייה
עלויות נוספות	ללא תוספת עבור SSE-S3	לפי KMS והתצורה	לפי תמחור DSSE-KMS ו־KMS	תפעול וניהול מפתח אצל הלקוח	מחשוב, מפתחות ואחסון לפי התצורה

הצפנה בתעבורה

השתמשו ב־HTTPS לחיבור ל־S3. חיבורי HTTPS אל נקודות הקצה של S3 API משתמשים ב־TLS 1.2 או בגרסה מאוחרת יותר; הטענה ההיסטורית על תמיכה ב־TLS 1.0 אינה עדכנית. מכאן לא נובע שכל בקשה חייבת להשתמש ב־HTTPS: S3 יכול לקבל גם HTTP, ונקודות קצה לאתרים סטטיים אינן מספקות HTTPS. אפשרויות התעבורה והאכיפה. הדוגמה הבאה חוסמת בקשות שאינן משתמשות בתעבורה מאובטחת עבור גורמים שאינם שירותי AWS. התאימו ובדקו מדיניות בסביבת בדיקה לפני החלתה, כדי לא לחסום תהליכים מורשים. תנאי תעבורה וחריגים לשירותי AWS.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyHTTP",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false",
          "aws:PrincipalIsAWSService": "false"
        }
      }
    }
  ]
}

אימות ובקרת גישה

מדיניות IAM: גישה המבוססת על זהות

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

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/reports/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-bucket",
      "Condition": {
        "StringLike": {
          "s3:prefix": [
            "reports/",
            "reports/*"
          ]
        }
      }
    }
  ]
}

מדיניות דלי: גישה המבוססת על משאב

מדיניות דלי משויכת לדלי עצמו. היא יכולה להגדיר הרשאות לגורמים בחשבון, בחשבונות אחרים או לשירותי AWS, בכפוף לכללי ההרשאה החלים. היא משמשת לגישה בין חשבונות ולאכיפת תנאים כמו הצפנה ו־TLS. הימנעו מפתיחת דלי לציבור ללא צורך; להגשת אתר אפשר להשתמש ב־CloudFront מול דלי פרטי בתצורה מתאימה.

רשימות בקרת גישה — ACL: מנגנון ותיק

ACL הן מנגנון ותיק ברמת הדלי והאובייקט. AWS ממליצה בדרך כלל לבטל אותן באמצעות Bucket owner enforced ולהשתמש במדיניות IAM ודלי. בצעו בדיקת תאימות לכלים ישנים לפני שינוי הבעלות וההרשאות; אין צורך גורף ב־ACL רק משום שהגישה היא בין חשבונות.

כתובות חתומות מראש: גישה מוגבלת בזמן

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

using Amazon.S3;
using Amazon.S3.Model;

// דוגמה נפרדת; הגדירו אישורים ואזור בסביבת בדיקה מורשית
using var s3Client = new AmazonS3Client();

// יצירת כתובת חתומה מראש להורדה — עד שעה, בכפוף לתוקף האישורים
var request = new GetPreSignedUrlRequest
{
    BucketName = "my-bucket",
    Key = "confidential-report.pdf",
    Verb = HttpVerb.GET,
    Expires = DateTime.UtcNow.AddHours(1)
};
string presignedUrl = s3Client.GetPreSignedURL(request);

// יצירת כתובת חתומה מראש להעלאה
var uploadRequest = new GetPreSignedUrlRequest
{
    BucketName = "my-bucket",
    Key = "uploads/user-file.jpg",
    Verb = HttpVerb.PUT,
    Expires = DateTime.UtcNow.AddMinutes(15),
    ContentType = "image/jpeg"
};
string uploadUrl = s3Client.GetPreSignedURL(uploadRequest);

Block Public Access: רשת ביטחון

הגדרות S3 Block Public Access (BPA) חוסמות סוגים של גישה ציבורית ברמת הארגון, החשבון, הדלי ונקודת הגישה, לפי התצורה. S3 מחיל את הצירוף המחמיר של ההגדרות החלות; מדיניות ארגונית עשויה לאכוף את הגדרות החשבון. ארבע ההגדרות הן: כללי חסימת גישה ציבורית.

• BlockPublicAcls: דחיית בקשות להחלת ACL ציבורית על דלי או אובייקט.
• IgnorePublicAcls: התעלמות מהרשאות ציבוריות הניתנות באמצעות ACL.
• BlockPublicPolicy: דחיית מדיניות דלי או נקודת גישה שמעניקה גישה ציבורית לפי כללי ההערכה של S3.
• RestrictPublicBuckets: כאשר לדלי או לנקודת גישה יש מדיניות ציבורית, הגישה מוגבלת לזהויות שירות של AWS ולמשתמשים מורשים בחשבון הבעלים. ההגדרה חוסמת גישה בין חשבונות, לרבות הרשאות מפורשות וממוקדות שהמדיניות הייתה מעניקה בלעדיה.

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

מדיניות נקודות קצה של VPC

נקודת קצה מסוג Gateway ל־S3 מאפשרת למשאבים בתצורת VPC מתאימה להגיע ל־S3 בלי לעבור באינטרנט הציבורי. מדיניות נקודת הקצה מוסיפה בקרת גישה, אך אינה מחליפה מדיניות IAM או דלי. תנאי aws:sourceVpce יכול להגביל בקשות לנקודת קצה מסוימת. מדיניות Deny כזאת עלולה לחסום גם גישת מסוף ושירותים מורשים; בדקו אותה ותכננו שחזור לפני החלה. הדוגמה מגינה על משאב הדלי ועל האובייקטים, אך אינה מעניקה הרשאה בפני עצמה. מדיניות דלי ונקודות קצה.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideNamedVPCEndpoint",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-0123456789abcdef0"
        }
      }
    }
  ]
}

Object Lock ואחסון שאינו ניתן לשינוי

Amazon S3 Object Lock מספק אחסון מסוג WORM — כתיבה פעם אחת וקריאה פעמים רבות — עבור גרסאות אובייקטים. הוא מחייב הפעלת ניהול גרסאות (Versioning) ומגן על גרסת האובייקט שננעלה; אפשר עדיין ליצור גרסאות חדשות או סמני מחיקה בהתאם להרשאות. הנעילה אינה מגינה מפני אובדן הגישה למפתחות או מחיקתם, ולכן אינה תחליף לניהול חיי מפתח ושחזור. Object Lock והצפנה. הוא עשוי לסייע בדרישות שמירת רשומות, ובהן דרישות אמריקאיות מסוימות, אך אינו מבטיח עמידה אוטומטית ב־SEC, ב־CFTC, ב־HIPAA או בדין אחר. אין להסיק מכאן דבר לגבי הדין בישראל. קיימים שני מצבי שמירה: תיעוד Object Lock.

• מצב Compliance: אי אפשר למחוק גרסה מוגנת או לקצר את תקופת השמירה שלה, גם באמצעות משתמש root, כל עוד התקופה לא הסתיימה. בחרו תקופה רק אחרי בדיקת צורכי השמירה, העלות וההשלכות המשפטיות.
• מצב Governance: גורם בעל ההרשאה s3:BypassGovernanceRetention יכול לעקוף את ההגנה כאשר בקשתו כוללת גם את מנגנון העקיפה הנדרש. המצב מתאים למדיניות ארגונית עם אפשרות עקיפה מבוקרת, ולא מבטיח חסינות מפני מחיקה של בעלי הרשאה זו.

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

ניטור אבטחה וביקורת

AWS CloudTrail עבור S3

CloudTrail Event history מציג אירועי ניהול נתמכים במסגרת ברירת המחדל של השירות. שמירה מתמשכת ותיעוד פעולות נתונים כמו GetObject, PutObject ו־DeleteObject דורשים תצורה מתאימה של trail או event data store ואירועי נתונים. בדליים עמוסים נפח התיעוד והעלות עשויים להיות משמעותיים; בחרו כיסוי בהתאם לרגישות ולצורכי הביקורת. תיעוד אירועי S3 ב־CloudTrail.

Amazon Macie

Amazon Macie מסייע לגלות ולסווג מידע רגיש בנתוני S3 נתמכים, למשל מזהים אישיים, מספרי אשראי, מידע רפואי ודפוסים מותאמים. הוא גם מפיק ממצאים לגבי סוגים נתמכים של סיכון במדיניות או בתצורה. הכיסוי תלוי בסוגי קבצים, בהרשאות ובתצורת הסריקה; אין להניח שכל סוג מידע או כל בעיית תצורה יזוהו. Macie אינו מפענח תוכן שהוצפן ב־SSE-C או בצד הלקוח, ויכול לדווח עליו רק מטא־נתונים. לניתוח אובייקטים שהוצפנו באמצעות מפתח KMS בניהול הלקוח, נדרשת הרשאה להשתמש במפתח המתאים. תמיכה בסוגי הצפנה ב־Macie. היכולות והמגבלות של Macie.

רשימת בדיקה לאבטחת S3

שיטות עבודה להגנה על S3 בסביבת ייצור

הצפנה

• שקלו SSE-KMS לדליים רגישים הזקוקים לבקרת מפתחות נפרדת.
• בחרו DSSE-KMS כאשר יש צורך מוגדר בהצפנה רב־שכבתית.
• אכפו את סוג ההצפנה הנדרש, תוך התחשבות בהצפנת ברירת המחדל.
• אכפו HTTPS ובדקו חריגים נדרשים לשירותי AWS.
• הגדירו החלפת חומר מפתח בהתאם לסוג מפתח KMS.

בקרת גישה

• הפעילו Block Public Access בשכבות המתאימות.
• העדיפו Bucket owner enforced ללא ACL, לאחר בדיקת תאימות.
• השתמשו בנקודות קצה של VPC לפי צורכי הגישה הפנימית.
• החילו מדיניות IAM לפי עקרון ההרשאה המזערית.
• הגדירו תוקף קצר ככל שמתאים לכתובות חתומות מראש.

גרסאות ושחזור

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

ניטור

• הפעילו אירועי נתונים ב־CloudTrail לדליים הרגישים.
• הגדירו יומני גישה לשרת S3 לפי הצורך.
• שקלו Macie לגילוי מידע רגיש לאחר בדיקת עלויות וכיסוי.
• הגדירו התראות על ממצאים ושינויים רלוונטיים בגישה הציבורית.

סיכום

S3 מציע שכבות של הגנה על נתונים במנוחה ובתעבורה. SSE-KMS מתאים כשדרושות בקרת מפתחות וביקורת נפרדות; הצפנה בצד הלקוח משנה את גבול האמון אך מחייבת ניהול מפתחות ותכנון שחזור. בצד ההרשאות, חסימת גישה ציבורית, מדיניות מצומצמת ונקודות קצה מתאימות הן בסיס חשוב. שלבו הצפנה, הרשאות, שמירת גרסאות, Object Lock כשנדרש וניטור מותאם. בדקו עלויות והשלכות לפני הפעלת שירותים: המאמר מסביר אפשרויות ואינו מבצע שינוי בחשבון.

מקורות להבהרות ולעדכונים

התרגום כולל תיקוני דיוק והבהרות על בסיס תיעוד רשמי. הבדיקה המקורית נערכה ב־25 באוקטובר 2026; המקורות הרלוונטיים לתיקון הנוכחי נבדקו שוב ב־27 באוקטובר 2026.

• אבטחת Amazon S3 וברירת המחדל של SSE-C
• אכיפת הצפנה בתעבורה ב־S3
• הצפנה דו־שכבתית ב־S3
• לקוח ההצפנה של S3 עבור .NET
• תנאים במדיניות S3
• חסימת גישה ציבורית ב־S3
• שילוב S3 עם IAM
• אישורי FIPS של AWS