אפשר לקשר את מהדורת Enterprise של Security Command Center לסביבת Amazon Web Services (AWS) כדי לבצע את הפעולות הבאות:
- זיהוי ותיקון של נקודות חולשה בתוכנה ושל טעויות בהגדרות בסביבת AWS
- יצירה וניהול של מצב אבטחה ב-AWS
- זיהוי נתיבי תקיפה פוטנציאליים מהאינטרנט הציבורי אל נכסי AWS בעלי ערך גבוה
- מיפוי התאימות של משאבי AWS לתקנים ולמדדים שונים
כשמחברים את Security Command Center ל-AWS, נוצר מקום אחד שבו צוות אבטחת המידע יכול לנהל ולתקן איומים ונקודות חולשה ב-Google Cloud וב-AWS.
כדי לאפשר ל-Security Command Center לעקוב אחרי הארגון שלכם ב-AWS, צריך להגדיר חיבור באמצעות סוכן שירות וחשבון AWS שיש לו גישה למשאבים שרוצים לעקוב אחריהם.Google Cloud Security Command Center משתמש בחיבור הזה כדי לאסוף נתונים באופן תקופתי בכל החשבונות והאזורים ב-AWS שאתם מגדירים. הנתונים האלה מטופלים באותו אופן כמו נתוני שירות, בהתאם להודעת הפרטיות של Google Cloud.
אפשר ליצור חיבור אחד ל-AWS לכל Google Cloud ארגון. המחבר משתמש בקריאות ל-API כדי לאסוף נתוני נכסים של AWS. יכול להיות שיחולו חיובים על קריאות ה-API האלה ב-AWS.
במאמר הזה מוסבר איך להגדיר את החיבור ל-AWS. כשמגדירים חיבור, קובעים את ההגדרות הבאות:
- סדרה של חשבונות ב-AWS שיש להם גישה ישירה למשאבי AWS שרוצים לעקוב אחריהם. במסוף Google Cloud , החשבונות האלה נקראים חשבונות לאיסוף נתונים.
- חשבון ב-AWS שיש בו את הכללים והתפקידים המתאימים שמאפשרים אימות לחשבונות של כלי האיסוף. במסוף Google Cloud , החשבון הזה נקרא חשבון עם הרשאת גישה. גם החשבון שהוקצו לו הרשאות וגם החשבונות המרכזים צריכים להיות באותו ארגון AWS.
- סוכן שירות ב- Google Cloud שמתחבר לחשבון המוקצה לצורך אימות.
- צינור להעברת נתונים לאיסוף נתוני נכסים ממקורות AWS.
- (אופציונלי) הרשאות ל-Sensitive Data Protection ליצירת פרופיל של תוכן AWS.
המחבר לא קולט יומני AWS שנדרשים ליכולות איתור מותאמות אישית של SIEM ב-Security Command Center Enterprise. מידע על הטמעת הנתונים האלה זמין במאמר קישור ל-AWS לצורך הטמעת יומנים.
החיבור הזה לא רלוונטי ליכולות ה-SIEM של Security Command Center, שמאפשרות להטמיע יומנים של AWS לצורך זיהוי איומים.
התרשים הבא מציג את ההגדרה הזו. פרויקט הדייר הוא פרויקט שנוצר באופן אוטומטי ומכיל את מופע צינור איסוף נתוני הנכסים.
סקירה כללית של שלבי ההגדרה
אחרי שמבצעים את השלבים בקטע לפני שמתחילים, פועלים לפי השלבים בכל קטע כדי לקשר את מהדורת Enterprise של Security Command Center לסביבת Amazon Web Services (AWS):
- הגדרת המחבר של AWS
- מגדירים את סביבת AWS באחת מהשיטות הבאות:
- באופן אוטומטי באמצעות תבניות CloudFormation
- באופן ידני על ידי הזנת חשבונות AWS
- השלמת תהליך השילוב של מחבר AWS
לפני שמתחילים
צריך להשלים את המשימות האלה לפני שממשיכים למשימות הנותרות בדף הזה.
הגדרת הרשאות ב Google Cloud
כדי לקבל את ההרשאות שדרושות לשימוש במחבר AWS, צריך לבקש מהאדמין להקצות לכם ב-IAM את התפקיד בעלים של נכס ב-Cloud (roles/cloudasset.owner).
להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.
יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.
יצירת חשבונות AWS
ודאו שיש לכם את משאבי AWS הבאים:
משתמש AWS IAM עם גישה ל-AWS IAM למסופי חשבון AWS של הנציג והמאסף.
מספר חשבון AWS של חשבון AWS שאפשר להשתמש בו כחשבון מוקצה. החשבון שהוקצו לו הרשאות צריך לעמוד בדרישות הבאות:
החשבון שהוקצו לו הרשאות צריך להיות מצורף לארגון AWS. כדי לצרף חשבון לארגון AWS:
- יוצרים או מזהים ארגון שאליו יצורף החשבון עם הרשאת הגישה.
- מזמינים את החשבון שקיבל הרשאת גישה להצטרף לארגון.
החשבון שהוקצו לו הרשאות חייב להיות אחד מהסוגים הבאים:
- חשבון ניהול ב-AWS.
- אדמין עם הרשאות ב-AWS.
- חשבון AWS עם מדיניות הרשאות מבוססת-משאבים שמעניקה את ההרשאה
organizations:ListAccounts. דוגמה למדיניות מופיעה במאמר יצירת מדיניות להענקת הרשאות לפי משאבים באמצעות AWS Organizations במסמכי התיעוד של AWS.
הגדרת המחבר של AWS
פותחים את הכרטיסייה מחברים בדף הגדרות.
בוחרים את הארגון שבו הפעלתם את Security Command Center Enterprise.
בוחרים באפשרות מחברים > הוספת מחבר > Amazon Web Services.
בקטע מזהה חשבון מואצל, מזינים את מזהה החשבון ב-AWS שאפשר להשתמש בו כחשבון מואצל.
כדי לאפשר ל-Sensitive Data Protection ליצור פרופיל של נתוני AWS, צריך להשאיר את האפשרות Grant permissions for Sensitive Data Protection discovery מסומנת. האפשרות הזו מוסיפה הרשאות של AWS Identity and Access Management (IAM) בתבנית CloudFormation לתפקיד של כלי האיסוף.
הרשאות AWS IAM שניתנות באמצעות האפשרות הזו
s3:GetBucketLocations3:ListAllMyBucketss3:GetBucketPolicyStatuss3:ListBuckets3:GetObjects3:GetObjectVersions3:GetBucketPublicAccessBlocks3:GetBucketOwnershipControlss3:GetBucketTaggingiam:ListAttachedRolePoliciesiam:GetPolicyiam:GetPolicyVersioniam:ListRolePoliciesiam:GetRolePolicyce:GetCostAndUsagedynamodb:DescribeTableReplicaAutoScalingidentitystore:ListGroupMembershipsidentitystore:ListGroupsidentitystore:ListUserslambda:GetFunctionlambda:GetFunctionConcurrencylogs:ListTagsForResources3express:CreateSessions3express:GetBucketPolicys3express:ListAllMyDirectoryBucketswafv2:GetIPSet
אופציונלי: בודקים ועורכים את האפשרויות המתקדמות. אפשרויות נוספות מפורטות במאמר התאמה אישית של הגדרות מחבר AWS.
לוחצים על Continue. נפתח הדף Connect to AWS (חיבור ל-AWS).
צריך לבחור אחת מהאפשרויות האלה:
משתמשים בתבניות AWS CloudFormation, ואז מורידים ובודקים את תבניות CloudFormation לתפקיד המוקצה ולתפקיד של כלי האיסוף.
הגדרה ידנית של חשבונות AWS: בוחרים באפשרות הזו אם הגדרתם את האפשרויות המתקדמות או אם אתם צריכים לשנות את שמות התפקידים ב-AWS שמוגדרים כברירת מחדל (aws-delegated-role, aws-collector-role ו-aws-sensitive-data-protection-role). מעתיקים את מזהה סוכן השירות, את שם התפקיד שהוקצה, את שם התפקיד של הכלי לאיסוף נתונים ואת שם התפקיד של הכלי לאיסוף נתונים של Sensitive Data Protection.
אחרי שיוצרים את הקישור, אי אפשר לשנות את שמות התפקידים.
לא לוחצים על שמירה או על המשך. במקום זאת, מגדירים את סביבת AWS.
הגדרת הסביבה של AWS
אפשר להגדיר את סביבת AWS באחת מהשיטות הבאות:
- משתמשים בתבניות CloudFormation שהורדתם בקטע הגדרת מחבר AWS. הוראות מפורטות זמינות במאמר בנושא שימוש בתבניות CloudFormation להגדרת סביבת AWS.
- אם אתם משתמשים בהגדרות או בשמות תפקידים בהתאמה אישית, אתם צריכים להגדיר את חשבונות AWS באופן ידני. הוראות מפורטות זמינות במאמר הגדרה ידנית של חשבונות AWS.
שימוש בתבניות CloudFormation להגדרת סביבת AWS
אם הורדתם תבניות של CloudFormation, אתם יכולים להשתמש בשלבים הבאים כדי להגדיר את סביבת AWS:
- נכנסים למסוף של חשבון הנציג ב-AWS. חשוב לוודא שאתם מחוברים לחשבון הנציג שמשמש להנפקת הרשאות לחשבונות AWS אחרים של כלי האיסוף (כלומר, לחשבון ניהול של AWS או לכל חשבון חבר שרשום כאדמין עם הרשאות גישה).
יוצרים מחסנית שמקצה את תפקיד הנציג. מידע נוסף זמין במאמר בנושא יצירת מחסנית.
חשוב לזכור:
- אם שיניתם את שם התפקיד של התפקיד שהוקצו לו הרשאות, של תפקיד המאסף או של התפקיד Sensitive Data Protection, צריך לעדכן את הפרמטרים בהתאם. הפרמטרים שאתם מזינים צריכים להיות זהים לאלה שמופיעים בדף Connect to AWS במסוף Google Cloud .
- ממתינים ליצירת ה-stack. אם מתרחשת שגיאה, אפשר להיעזר בקטע פתרון בעיות. מידע נוסף זמין במאמר בנושא יצירת מחסנית במסוף AWS CloudFormation במסמכי התיעוד של AWS.
יוצרים מחסנית שמקצה את תפקידי האוסף. מידע נוסף על התהליך הזה זמין במאמר יצירת CloudFormation StackSets עם הרשאות שמנוהלות על ידי שירות.
חשוב לזכור:
אם בחרתם להוסיף חשבונות AWS בנפרד (על ידי בחירה באפשרות הוספת חשבונות בנפרד כשמגדירים את המחבר במסוףGoogle Cloud ), אתם יכולים גם ליצור מחסניות נפרדות לכל חשבון AWS במקום ליצור קבוצת מחסניות אחת.
- ההגדרה המומלצת היא הרשאות שמנוהלות על ידי השירות. אפשר לבחור להשתמש בהרשאות בניהול עצמי, אבל אז צריך להעניק את ההרשאות באופן ידני.
הערה: אם בוחרים בהרשאות בניהול עצמי, אפשר לבחור לאילו חשבונות AWS רוצים לפרוס. תבנית CloudFormation לא תומכת ברשימה של חשבונות AWS שרוצים לכלול או להחריג, כמו שמתואר במאמר הגדרה בהתאמה אישית.
אם רוצים ליצור רשימה של חשבונות AWS שרוצים לכלול או להחריג, יכול להיות שקבוצת ה-stack תיצור כמה stacks שלא נדרשים. אפשר להתעלם מהערימות האלה או להסיר אותן.
אם שיניתם את שם התפקיד של התפקיד שהוקצו לו הרשאות, של תפקיד המאסף או של התפקיד Sensitive Data Protection, צריך לעדכן את הפרמטרים בהתאם. הפרמטרים שאתם מזינים צריכים להיות זהים לאלה שמופיעים בדף Connect to AWS במסוף Google Cloud .
מגדירים את האפשרויות של קבוצת הערימות בהתאם לדרישות הארגון.
כשמציינים את אפשרויות הפריסה, בוחרים את יעדי הפריסה. אפשר לפרוס את התוסף בכל הארגון ב-AWS או ביחידה ארגונית (OU) שכוללת את כל החשבונות ב-AWS שמהם רוצים לאסוף נתונים.
מציינים את האזורים ב-AWS שבהם רוצים ליצור את התפקידים ואת כללי המדיניות. מכיוון שתפקידים הם משאבים גלובליים, לא צריך לציין כמה אזורים.
אם מופיעה הודעת שגיאה, אפשר להיעזר בפתרון בעיות. מידע נוסף זמין במאמר בנושא יצירת CloudFormation StackSets עם הרשאות שמנוהלות על ידי השירות במסמכי העזרה של AWS.
- אם אתם צריכים לאסוף נתונים מחשבון הניהול, אתם צריכים להיכנס לחשבון הניהול ולפרוס מחסנית נפרדת כדי להקצות את תפקידי האוסף. כשמציינים את התבנית, מעלים את קובץ התבנית של תפקיד המאסף.
השלב הזה נדרש כי ערכות מחסניות של AWS CloudFormation לא יוצרות מופעי מחסניות בחשבונות ניהול. מידע נוסף זמין במאמר בנושא DeploymentTargets במסמכי התיעוד של AWS.
- ההגדרה המומלצת היא הרשאות שמנוהלות על ידי השירות. אפשר לבחור להשתמש בהרשאות בניהול עצמי, אבל אז צריך להעניק את ההרשאות באופן ידני.
הערה: אם בוחרים בהרשאות בניהול עצמי, אפשר לבחור לאילו חשבונות AWS רוצים לפרוס. תבנית CloudFormation לא תומכת ברשימה של חשבונות AWS שרוצים לכלול או להחריג, כמו שמתואר במאמר הגדרה בהתאמה אישית.
אם רוצים ליצור רשימה של חשבונות AWS שרוצים לכלול או להחריג, יכול להיות שקבוצת ה-stack תיצור כמה stacks שלא נדרשים. אפשר להתעלם מהערימות האלה או להסיר אותן.
מבצעים את השלבים שמפורטים בקטע השלמת תהליך השילוב.
הגדרה ידנית של חשבונות AWS
אם אתם לא יכולים להשתמש בתבניות CloudFormation (לדוגמה, אם אתם משתמשים בשמות תפקידים שונים או מבצעים התאמה אישית של השילוב), אתם יכולים ליצור באופן ידני את מדיניות AWS IAM ואת תפקידי AWS IAM הנדרשים.
בודקים את הקטעים הבאים וממלאים אותם לפי הסדר:
- יצירת מדיניות AWS IAM לתפקיד המוקצה
- יצירת תפקיד AWS IAM ליחסי האמון בין AWS לבין Google Cloud
- יצירת מדיניות AWS IAM לאיסוף נתוני הגדרות של נכסים
- יצירת תפקיד AWS IAM לאיסוף נתוני תצורה של נכסים בכל חשבון
- יצירת מדיניות AWS IAM עבור Sensitive Data Protection
צריך ליצור מדיניות IAM ב-AWS ותפקידי IAM ב-AWS עבור החשבון המוקצה וחשבונות האיסוף.
יצירת מדיניות AWS IAM לתפקיד עם הרשאות הניהול
כדי ליצור מדיניות AWS IAM לתפקיד שהוקצו לו הרשאות (מדיניות שהוקצו לה הרשאות), פועלים לפי השלבים במאמר יצירת מדיניות בתיעוד של AWS.
כשיוצרים את המדיניות, מדביקים את אחת האפשרויות הבאות בשלב JSON, בהתאם לתיבת הסימון Grant permissions for Sensitive Data Protection discovery (הענקת הרשאות לגילוי נתונים רגישים) שסימנתם בConfigure Security Command Center (הגדרת Security Command Center).
מתן הרשאות לגילוי נתונים ב-Sensitive Data Protection: בוטל
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam:::role/COLLECTOR_ROLE_NAME",
"Effect": "Allow"
},
{
"Action": [
"organizations:List",
"organizations:Describe"
],
"Resource": "",
"Effect": "Allow"
}
]
}
מחליפים את COLLECTOR_ROLE_NAME בשם של תפקיד המאסף שהעתקתם כשהגדרתם את Security Command Center (ברירת המחדל היא aws-collector-role).
מתן הרשאות לגילוי Sensitive Data Protection: נבחר
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::*:role/COLLECTOR_ROLE_NAME",
"arn:aws:iam::*:role/SCAN_SENSITIVE_DATA_COLLECTOR_ROLE_NAME"
],
"Effect": "Allow"
},
{
"Action": [
"organizations:List*",
"organizations:Describe*"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
מחליפים את מה שכתוב בשדות הבאים:
-
COLLECTOR_ROLE_NAME: השם של תפקיד איסוף נתוני ההגדרות שהעתקתם כשהגדרתם את Security Command Center (ברירת המחדל היאaws-collector-role) -
SCAN_SENSITIVE_DATA_COLLECTOR_ROLE_NAME: השם של תפקיד האוסף של Sensitive Data Protection שהעתקתם כשהגדרתם את Security Command Center (ברירת המחדל היאaws-sensitive-data-protection-role)
יצירת תפקיד AWS IAM ליחסי האמון בין AWS לבין Google Cloud
יוצרים תפקיד עם הרשאות מוגבלות שמגדיר יחסי אמון בין AWS לביןGoogle Cloud. התפקיד הזה משתמש במדיניות המוקצית שנוצרה בקטע יצירת מדיניות AWS IAM לתפקיד המוקצה.
פועלים לפי ההוראות שבמאמר יצירת תפקיד ל-OIDC בתיעוד של AWS.
כשיוצרים את התפקיד, מציינים את הפרטים הבאים:
סוג ישות מהימנה: בוחרים באפשרות זהות אינטרנט.
ספק זהויות: בוחרים באפשרות Google.
קהל: מזינים את מזהה סוכן השירות שהעתקתם כשהגדרתם את Security Command Center.
כדי לתת לתפקיד המואצל גישה לתפקידי האוסף, צריך לצרף את מדיניות ההרשאות לתפקיד. מחפשים את המדיניות שהוקצתה שנוצרה בקטע יצירת מדיניות AWS IAM לתפקיד שהוקצה ובוחרים אותה.
פרטי התפקיד: מזינים את השם של התפקיד שהוקצו לו הרשאות שהעתקתם כשהגדרתם את Security Command Center (שם ברירת המחדל הוא
aws-delegated-role).
יצירת מדיניות AWS IAM לאיסוף נתוני הגדרות של נכסים
כדי ליצור מדיניות AWS IAM לאיסוף נתוני הגדרות של נכסים (מדיניות של כלי איסוף), מבצעים את הפעולות הבאות:
פועלים לפי השלבים במאמר יצירת מדיניות במסמכי AWS, וחוזרים על השלבים האלה לפי הצורך לכל חשבון של כלי איסוף.
כשיוצרים את התפקיד, מציינים את הפרטים הבאים בשלב של ה-JSON:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ce:GetCostAndUsage", "dynamodb:DescribeTableReplicaAutoScaling", "identitystore:ListGroupMemberships", "identitystore:ListGroups", "identitystore:ListUsers", "lambda:GetFunction", "lambda:GetFunctionConcurrency", "logs:ListTagsForResource", "s3express:GetBucketPolicy", "s3express:ListAllMyDirectoryBuckets", "wafv2:GetIPSet" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "apigateway:GET" ], "Resource": [ "arn:aws:apigateway:*::/usageplans", "arn:aws:apigateway:*::/usageplans/*/keys", "arn:aws:apigateway:*::/vpclinks/*" ] } ] }
יצירת תפקיד AWS IAM לאיסוף נתוני הגדרות של נכסים בכל חשבון
יוצרים את תפקיד המאסף שמאפשר ל-Security Command Center לקבל נתוני תצורה של נכסים מ-AWS. התפקיד הזה משתמש במדיניות האיסוף שנוצרה בקטע יצירת מדיניות AWS IAM לאיסוף נתוני הגדרות נכסים.
פועלים לפי השלבים במאמר יצירת תפקיד בהתאמה אישית בחומרי העזר של AWS, וחוזרים על השלבים האלה לפי הצורך לכל חשבון של כלי איסוף.
במדיניות המותאמת אישית להרשאות שיתוף, מוסיפים את הדברים הבאים:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::DELEGATE_ACCOUNT_ID:role/DELEGATE_ACCOUNT_ROLE" }, "Action": "sts:AssumeRole" } ] }מחליפים את מה שכתוב בשדות הבאים:
-
DELEGATE_ACCOUNT_ID: מזהה החשבון ב-AWS של חשבון הנציג
DELEGATE_ACCOUNT_ROLE: שם התפקיד שהוקצו לו הרשאות שהעתקתם כשהגדרתם את Security Command Center.כדי לתת לתפקיד הזה של איסוף נתונים גישה לנתוני ההגדרה של נכסי AWS, צריך לצרף את מדיניות ההרשאות לתפקיד. מחפשים את מדיניות איסוף הנתונים המותאמת אישית שנוצרה בקטע יצירת מדיניות AWS IAM לאיסוף נתוני הגדרות נכסים ובוחרים אותה.
מחפשים ובוחרים את המדיניות המנוהלת הבאה:
- arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
- arn:aws:iam::aws:policy/SecurityAudit
בקטע פרטי התפקיד, מזינים את השם של תפקיד איסוף נתוני ההגדרה שהעתקתם כשהגדרתם את Security Command Center.
-
אם סימנתם את התיבה Grant permissions for Sensitive Data Protection discovery (הענקת הרשאות לגילוי נתונים רגישים) בקטע Configure Security Command Center (הגדרת Security Command Center), ממשיכים לקטע הבא.
אם לא סימנתם את תיבת הסימון Grant permissions for Sensitive Data Protection discovery, צריך להשלים את תהליך השילוב.
יצירת מדיניות AWS IAM עבור Sensitive Data Protection
צריך לבצע את השלבים האלה אם סימנתם את התיבה Grant permissions for Sensitive Data Protection discovery (מתן הרשאות לגילוי נתונים רגישים) בקטע Configure Security Command Center (הגדרת Security Command Center).
כדי ליצור מדיניות AWS IAM עבור Sensitive Data Protection (מדיניות של כלי איסוף), מבצעים את הפעולות הבאות:
פועלים לפי השלבים במאמר יצירת תפקיד בהתאמה אישית בחומרי העזר של AWS, וחוזרים על הפעולה לפי הצורך לכל חשבון איסוף.
כשיוצרים את התפקיד בהתאמה אישית, מציינים את הפרטים הבאים בשלב של ה-JSON:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:ListAllMyBuckets", "s3:GetBucketPolicyStatus", "s3:ListBucket", "s3:GetObject", "s3:GetObjectVersion", "s3:GetBucketPublicAccessBlock", "s3:GetBucketOwnershipControls", "s3:GetBucketTagging" ], "Resource": ["arn:aws:s3:::*"] }, { "Effect": "Allow", "Action": [ "iam:ListAttachedRolePolicies", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:ListRolePolicies", "iam:GetRolePolicy", "ce:GetCostAndUsage", "dynamodb:DescribeTableReplicaAutoScaling", "identitystore:ListGroupMemberships", "identitystore:ListGroups", "identitystore:ListUsers", "lambda:GetFunction", "lambda:GetFunctionConcurrency", "logs:ListTagsForResource", "s3express:GetBucketPolicy", "s3express:ListAllMyDirectoryBuckets", "wafv2:GetIPSet" ], "Resource": ["*"] }, { "Effect": "Allow", "Action": [ "s3express:CreateSession" ], "Resource": ["arn:aws:s3express:*:*:bucket/*"] } ] }
יצירת תפקיד AWS IAM להגנה על נתונים רגישים בכל חשבון
צריך לבצע את השלבים האלה אם סימנתם את תיבת הסימון Grant permissions for Sensitive Data Protection discovery (מתן הרשאות לגילוי נתונים רגישים) בקטע Configure the AWS connector (הגדרת המחבר של AWS).
יוצרים את תפקיד האוסף שמאפשר ל-Sensitive Data Protection ליצור פרופיל של התוכן במשאבי AWS. התפקיד הזה משתמש במדיניות האיסוף שנוצרה בשלב יצירת מדיניות AWS IAM ל-Sensitive Data Protection.
פועלים לפי השלבים במאמר יצירה של תפקיד לניהול זהויות וגישה באמצעות מדיניות אמון בהתאמה אישית (מסוף) בחומרי העזר של AWS, וחוזרים על השלבים לפי הצורך לכל חשבון של כלי האיסוף.
כשיוצרים את המדיניות, מציינים את הפרטים הבאים:
סוג ישות מהימנה: בוחרים באפשרות מדיניות מהימנות בהתאמה אישית.
במדיניות המותאמת אישית להרשאות שיתוף, מדביקים את הטקסט הבא:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::DELEGATE_ACCOUNT_ID:role/DELEGATE_ACCOUNT_ROLE" }, "Action": "sts:AssumeRole" } ] }מחליפים את מה שכתוב בשדות הבאים:
-
DELEGATE_ACCOUNT_ID: מזהה החשבון ב-AWS של חשבון הנציג -
DELEGATE_ACCOUNT_ROLE: שם התפקיד עם ההרשאות המוגבלות שהעתקתם כשהגדרתם את Security Command Center
-
כדי לתת לתפקיד הזה של איסוף נתונים גישה לתוכן של משאבי AWS, צריך לצרף את מדיניות ההרשאות לתפקיד. מחפשים את מדיניות איסוף הנתונים המותאמת אישית שנוצרה בשלב יצירת מדיניות AWS IAM להגנה על נתונים רגישים ובוחרים אותה.
כדי לראות את פרטי התפקיד, מזינים את שם התפקיד של Sensitive Data Protection שהעתקתם כשהגדרתם את Security Command Center.
מבצעים את השלבים שמפורטים בקטע השלמת תהליך השילוב.
השלמת ההגדרה של מחבר AWS
- חוזרים לדף Connect to AWS (קישור ל-AWS) ולוחצים על Continue (המשך).
ב Google Cloud מסוף, בדף Test connector, לוחצים על Test connector כדי לוודא ש-Security Command Center יכול להתחבר לסביבת AWS שלכם. אם החיבור מצליח, הבדיקה קובעת שלתפקיד המואצל יש את כל ההרשאות הנדרשות כדי לקבל את תפקידי האוסף. אם החיבור לא מצליח, אפשר לעיין במאמר פתרון בעיות של שגיאות בבדיקת החיבור.
לוחצים על Save.
התאמה אישית של הגדרת מחבר AWS
בקטע הזה מתוארות כמה דרכים להתאמה אישית של החיבור בין Security Command Center לבין AWS. האפשרויות האלה זמינות בקטע Advanced options (optional) בדף Add Amazon Web Services connector במסוף Google Cloud .
כברירת מחדל, Security Command Center מגלה באופן אוטומטי את חשבונות AWS בכל האזורים של AWS. החיבור משתמש בנקודת הקצה הגלובלית שמוגדרת כברירת מחדל עבור AWS Security Token Service ובשאילתות לשנייה (QPS) שמוגדרות כברירת מחדל עבור שירות AWS שאתם מנטרים. האפשרויות המתקדמות האלה מאפשרות לכם לשנות את הגדרות ברירת המחדל.
| אפשרות | תיאור |
|---|---|
| הוספה של חשבונות מחבר של AWS | בוחרים באפשרות הרצויה:
|
| החרגה של חשבונות מחבר AWS | אם בחרתם באפשרות הוספת חשבונות באופן אוטומטי בקטע הוספת חשבונות של מחבר AWS, צריך לספק רשימה של חשבונות AWS ש-Security Command Center לא צריך להשתמש בהם כדי למצוא משאבים. |
| הזנת חשבונות של מחבר AWS | אם בחרתם באפשרות הוספת חשבונות בנפרד בקטע הוספת חשבונות של מחבר AWS, צריך לספק רשימה של חשבונות AWS ש-Security Command Center יכול להשתמש בהם כדי למצוא משאבים. |
| בחירת אזורים לאיסוף נתונים | בוחרים אזור אחד או יותר ב-AWS שממנו Security Command Center יאסוף נתונים. כדי לאסוף נתונים מכל האזורים, משאירים את השדה AWS regions ריק. |
| מספר השאילתות המקסימלי לשנייה (QPS) לשירותי AWS | אפשר לשנות את מספר השאילתות לשנייה כדי לשלוט במגבלת המכסה של Security Command Center. מגדירים את הערך של שינוי ברירת המחדל כך שיהיה קטן מערך ברירת המחדל של השירות, וגדול מ-1 או שווה לו.
ערך ברירת המחדל הוא הערך המקסימלי. אם תשנו את ערך ה-QPS, יכול להיות ש-Security Command Center ייתקל בבעיות בשליפת הנתונים. לכן, לא מומלץ לשנות את הערך הזה. |
| נקודת קצה (endpoint) עבור AWS Security Token Service | אפשר לציין נקודת קצה ספציפית עבור AWS Security Token Service (לדוגמה, https://sts.us-east-2.amazonaws.com). אם משאירים את השדה AWS Security Token Service ריק, נעשה שימוש בנקודת הקצה הגלובלית שמוגדרת כברירת מחדל (https://sts.amazonaws.com). |
הענקת הרשאות למיון מידע אישי רגיש למחבר AWS קיים
כדי לבצע מיון מידע אישי רגיש בתוכן שלכם ב-AWS, אתם צריכים מחבר AWS עם הרשאות AWS IAM הנדרשות.
בקטע הזה מוסבר איך מעניקים את ההרשאות האלה למחבר AWS קיים. השלבים שצריך לבצע תלויים בשיטה שבה הגדרתם את סביבת AWS – באמצעות תבניות CloudFormation או באופן ידני.
עדכון מחבר קיים באמצעות תבניות CloudFormation
אם הגדרתם את סביבת AWS באמצעות תבניות CloudFormation, אתם צריכים לפעול לפי השלבים הבאים כדי להעניק הרשאות לגילוי נתונים רגישים למחבר AWS הקיים.
במסוף Google Cloud , עוברים אל הגדרות > הגדרות SCC.
בוחרים את הארגון שבו הפעלתם את Security Command Center Enterprise.
בוחרים באפשרות מחברים. נפתח הדף Configure connector (הגדרת המחבר).
במחבר AWS, לוחצים על אפשרויות נוספות > עריכה.
בקטע Review data types, בוחרים באפשרות Grant permissions for Sensitive Data Protection discovery.
לוחצים על Continue. נפתח הדף Connect to AWS (חיבור ל-AWS).
לוחצים על הורדת תבנית של תפקיד עם הרשאות ניהול. התבנית תרד למחשב.
לוחצים על הורדת תבנית של תפקיד לאיסוף נתונים. התבנית תרד למחשב.
לוחצים על Continue. ייפתח הדף Test connector (בדיקת מחבר). עדיין לא בודקים את המחבר.
במסוף CloudFormation, מעדכנים את תבנית ה-stack עבור התפקיד שהוקצו לו הרשאות:
- נכנסים למסוף של חשבון הנציג ב-AWS. מוודאים שאתם מחוברים לחשבון הנציג שמשמש להנפקת חשבונות AWS אחרים של כלי האיסוף.
- נכנסים למסוף AWS CloudFormation.
מחליפים את תבנית ה-Stack לתפקיד המוקצה בתבנית התפקיד המוקצה המעודכנת שהורדתם.
מידע נוסף זמין במאמר עדכון תבנית של מחסנית (מסוף) במסמכי העזרה של AWS.
מעדכנים את ערכת ה-stack לתפקיד של המאסף:
- באמצעות חשבון ניהול של AWS או כל חשבון חבר שרשום כאדמין עם הרשאות גישה, עוברים אל מסוף AWS CloudFormation.
מחליפים את תבנית ה-Stack Set לתפקיד המאסף בתבנית המעודכנת של תפקיד המאסף שהורדתם.
מידע נוסף מופיע במאמר עדכון של קבוצת ה-stack באמצעות מסוף AWS CloudFormation במסמכי העזרה של AWS.
אם אתם צריכים לאסוף נתונים מחשבון הניהול, אתם צריכים להיכנס לחשבון הניהול ולהחליף את התבנית במערך של כלי האיסוף בתבנית המעודכנת של תפקיד כלי האיסוף שהורדתם.
השלב הזה נדרש כי ערכות מחסניות של AWS CloudFormation לא יוצרות מופעי מחסניות בחשבונות ניהול. מידע נוסף זמין במאמר בנושא DeploymentTargets במסמכי התיעוד של AWS.
במסוף Google Cloud , בדף Test connector, לוחצים על Test connector. אם החיבור מצליח, הבדיקה קובעת שלתפקיד המוקצה יש את כל ההרשאות הנדרשות כדי לקבל את תפקידי האוסף. אם החיבור לא מצליח, אפשר להיעזר במדריך לפתרון שגיאות בבדיקת החיבור.
לוחצים על Save.
עדכון ידני של מחבר קיים
אם הגדרתם את חשבונות AWS באופן ידני כשנוצר מחבר AWS, צריך לבצע את השלבים הבאים כדי להעניק הרשאות לגילוי נתונים רגישים למחבר AWS הקיים.
פותחים את הכרטיסייה מחברים בדף הגדרות.
בוחרים את הארגון שבו הפעלתם את Security Command Center Enterprise.
במחבר AWS, לוחצים על אפשרויות נוספות > עריכה.
בקטע Review data types, בוחרים באפשרות Grant permissions for Sensitive Data Protection discovery.
לוחצים על Continue. נפתח הדף Connect to AWS (חיבור ל-AWS).
לוחצים על הגדרה ידנית של חשבונות AWS (מומלץ אם משתמשים בהגדרות מתקדמות או בשמות תפקידים מותאמים אישית).
מעתיקים את הערכים של השדות הבאים:
- השם של התפקיד שהוקצו לו הרשאות
- שם התפקיד של המאסף
- שם התפקיד של כלי האיסוף של Sensitive Data Protection
לוחצים על Continue. ייפתח הדף Test connector (בדיקת מחבר). עדיין לא בודקים את המחבר.
במסוף של חשבון הנציג ב-AWS, מעדכנים את מדיניות ה-IAM ב-AWS עבור התפקיד שהוקצה לשימוש ב-JSON הבא:
{ "Version": "2012-10-17", "Statement": [ { "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::*:role/COLLECTOR_ROLE_NAME", "arn:aws:iam::*:role/SCAN_SENSITIVE_DATA_COLLECTOR_ROLE_NAME" ], "Effect": "Allow" }, { "Action": [ "organizations:List*", "organizations:Describe*" ], "Resource": "*", "Effect": "Allow" } ] }מחליפים את מה שכתוב בשדות הבאים:
-
COLLECTOR_ROLE_NAME: השם של תפקיד איסוף נתוני התצורה שהעתקתם (ברירת המחדל היאaws-collector-role) -
SCAN_SENSITIVE_DATA_COLLECTOR_ROLE_NAME: השם של תפקיד האוסף של Sensitive Data Protection שהעתקתם (ברירת המחדל היאaws-sensitive-data-protection-role)
מידע נוסף זמין במאמר בנושא עריכת מדיניות בניהול הלקוח (מסוף) במסמכי AWS.
-
לכל חשבון של כלי האיסוף, מבצעים את הפעולות הבאות:
במסוף Google Cloud , בדף Test connector, לוחצים על Test connector. אם החיבור מצליח, הבדיקה קובעת שלתפקיד המוקצה יש את כל ההרשאות הנדרשות כדי לקבל את תפקידי האוסף. אם החיבור לא מצליח, אפשר להיעזר במדריך לפתרון שגיאות בבדיקת החיבור.
לוחצים על Save.
פתרון בעיות
בקטע הזה מפורטות כמה בעיות נפוצות שאתם עשויים להיתקל בהן כשאתם משלבים את Security Command Center עם AWS.
המשאבים כבר קיימים
השגיאה הזו מתרחשת בסביבת AWS כשמנסים ליצור את מדיניות AWS IAM ואת תפקידי AWS IAM, והתפקיד כבר קיים בחשבון AWS.
כדי לפתור את השגיאה, מבצעים את הפעולות הבאות:
- בודקים אם התפקיד או המדיניות שאתם יוצרים כבר קיימים ועומדים בדרישות שמפורטות במדריך הזה.
- אם צריך, משנים את שם התפקיד כדי למנוע התנגשויות.
הגורם הראשי במדיניות לא תקין
השגיאה הזו יכולה להתרחש בסביבת AWS כשיוצרים את תפקידי האוסף, אבל תפקיד הנציג עדיין לא קיים.
כדי לפתור את השגיאה, צריך לבצע את השלבים במאמר יצירת מדיניות AWS IAM לתפקיד המוקצה ולהמתין עד ליצירת התפקיד המוקצה לפני שממשיכים.
מגבלות ויסות נתונים ב-AWS
מערכת AWS מגבילה את מספר בקשות ה-API לכל חשבון AWS על בסיס כל חשבון או כל אזור. כדי לוודא שלא חורגים מהמגבלות האלה כש-Security Command Center אוסף נתוני הגדרות של נכסים מ-AWS, הוא אוסף את הנתונים בקצב קבוע של שאילתות לשנייה (QPS) לכל שירות AWS, כפי שמתואר במאמרי העזרה של ה-API של שירות AWS.
אם אתם נתקלים בהגבלת קצב הבקשות בסביבת AWS בגלל מספר הבקשות לשנייה שנצרך, אתם יכולים לפתור את הבעיה על ידי ביצוע הפעולות הבאות:
בדף ההגדרות של מחבר AWS, מגדירים QPS בהתאמה אישית לשירות AWS שחווה הגבלת קצב בקשות.
מגבילים את ההרשאות של תפקיד האוסף ב-AWS כדי שהנתונים מהשירות הספציפי הזה לא ייאספו יותר. טכניקת המיטיגציה הזו מונעת מסימולציות של נתיבי תקיפה לפעול בצורה תקינה ב-AWS.
ביטול כל ההרשאות ב-AWS מפסיק את תהליך איסוף הנתונים באופן מיידי. מחיקת המחבר של AWS לא מפסיקה מיד את תהליך איסוף הנתונים, אבל הוא לא יתחיל שוב אחרי שהוא יסתיים.
התוצאה מוחזרת עבור משאב AWS שנמחק
אחרי שמוחקים משאב ב-AWS, יכולות לעבור עד 40 שעות עד שהוא יוסר ממערכת מלאי הנכסים של Security Command Center. אם תבחרו לפתור ממצא על ידי מחיקת המשאב, יכול להיות שהממצא ידווח במהלך תקופת הזמן הזו, כי הנכס עדיין לא הוסר ממערכת מלאי הנכסים של Security Command Center.
פתרון שגיאות בבדיקת החיבור
השגיאות האלה יכולות להתרחש כשבודקים את החיבור בין Security Command Center לבין AWS.
AWS_FAILED_TO_ASSUME_DELEGATED_ROLE
החיבור לא תקין כי סוכן השירות Google Cloud לא יכול לקבל את התפקיד שהוקצה.
כדי לפתור את הבעיה, כדאי לבדוק את הדברים הבאים:
מוודאים שהתפקיד שהוקצו לו הרשאות קיימים. כדי ליצור אותו, אפשר לעיין במאמר בנושא יצירת תפקיד AWS IAM עבור יחסי האמון בין AWS לבין Google Cloud.
חסרה מדיניות מוטמעת של התפקיד שהוקצו לו הרשאות. בלי זה, סוכן השירות לא יכול לקבל את התפקיד. כדי לוודא שהמדיניות המוטמעת קיימת, אפשר לעיין במאמר יצירת תפקיד AWS IAM עבור יחסי ההרשאה בין AWS לבין Google Cloud.
אם פרטי השגיאה מכילים את ההודעה
InvalidIdentityToken: Incorrect token audience, this may be caused by a separate OIDC ספק זהויות foraccounts.google.comבסביבת AWS. כדי לפתור את השגיאה, צריך להסיר את ספק הזהויות של OIDC עבורaccounts.google.comבסביבת AWS לפי ההוראות במאמר יצירה וניהול של ספק OIDC.
AWS_FAILED_TO_CONNECT_TO_ORGNIZATIONS_SERVICE
החיבור לא תקין כי הוא לא יכול להתחבר לשירות AWS Organizations. הסטטוס הזה רלוונטי רק לחיבורים שבהם ההגדרה 'גילוי אוטומטי' מושבתת.
כדי לפתור את הבעיה, כדאי לבדוק את הדברים הבאים:
- כדי לוודא שההגדרה נכונה, בודקים שפעלתם לפי השלבים במאמר יצירת חשבונות AWS. מוודאים שההרשאות ב-AWS IAM לתפקיד שהוקצו לו הרשאות גישה הוגדרו בצורה נכונה.
- כדי לבדוק את ההגדרה של AWS Organization, אפשר לעיין במאמר פתרון בעיות ב-AWS Organizations.
- בודקים ביומנים של AWS CloudTrail אם יש שגיאות ספציפיות של דחיית גישה שקשורות לשירותי AWS Organizations. השלב הזה יכול לעזור לכם לזהות בדיוק את הפער בהרשאות.
AWS_FAILED_TO_LIST_ACCOUNTS
החיבור לא תקין כי הגילוי האוטומטי מופעל והתפקיד שהוקצה לא יכול לקבל את כל חשבונות AWS בארגונים.
השגיאה הזו מציינת שבמשאבים מסוימים חסרה המדיניות שמאפשרת את הפעולה organizations:ListAccounts בתפקיד שהוקצו לו הרשאות. כדי לפתור את השגיאה הזו, צריך לבדוק אילו משאבים חסרים. כדי לוודא את ההגדרות של המדיניות שהוקצתה, אפשר לעיין במאמר יצירת מדיניות AWS IAM לתפקיד שהוקצה.
מוודאים שיצרתם והגדרתם את חשבונות AWS כמו שמתואר בקטע יצירת חשבונות AWS.
AWS_ACTIVE_COLLECTOR_ACCOUNTS_NOT_FOUND
החיבור לא תקין כי לא נמצאו חשבונות של כלי איסוף נתונים ב-AWS עם הסטטוס ACTIVE.
אם בחרתם באפשרות הוספת חשבונות באופן אוטומטי בשדה הוספת חשבונות של מחבר AWS, לא נמצאו חשבונות AWS עם סטטוס ACTIVE, למעט אלה שצוינו בשדה החרגת חשבונות של מחבר AWS.
אם בחרתם באפשרות הוספת חשבונות בנפרד, בשדה הוספת חשבונות של מחבר AWS, בודקים שהסטטוס של החשבונות שציינתם הוא ACTIVE.
AWS_INVALID_COLLECTOR_ACCOUNTS
החיבור לא תקין כי יש חשבונות לא תקינים של אוספי נתונים. הודעת השגיאה כוללת מידע נוסף על הסיבות האפשריות, כולל:
AWS_FAILED_TO_ASSUME_COLLECTOR_ROLE
החשבון של הכלי לאיסוף נתונים לא תקין כי התפקיד שהוקצה לו לא יכול לקבל את התפקיד של הכלי בחשבון של הכלי.
כדי לפתור את השגיאה, כדאי לשקול את האפשרויות הבאות:
מוודאים שתפקיד המאסף קיים.
- כדי ליצור את תפקיד האיסוף של נתוני הגדרת הנכסים, אפשר לעיין במאמר בנושא יצירת תפקיד AWS IAM לאיסוף נתוני הגדרת נכסים בכל חשבון.
- כדי ליצור את תפקיד האיסוף עבור Sensitive Data Protection, אפשר לעיין במאמר יצירת תפקיד AWS IAM עבור Sensitive Data Protection בכל חשבון.
המדיניות שמאפשרת לתפקיד המוקצה לקבל את תפקיד האוסף חסרה. כדי לוודא שהמדיניות קיימת, אפשר לעיין במאמר בנושא יצירת מדיניות AWS IAM לתפקיד שהוקצו לו הרשאות.
AWS_COLLECTOR_ROLE_POLICY_MISSING_REQUIRED_PERMISSION
החיבור לא תקין כי חסרות במדיניות של כלי האיסוף חלק מהגדרות ההרשאות הנדרשות.
כדי לפתור את השגיאה הזו, כדאי לבדוק את הסיבות הבאות:
יכול להיות שחלק ממדיניות הניהול הנדרשת של AWS לא מצורפת לתפקיד של כלי האיסוף עבור נתוני הגדרת הנכסים. כדי לוודא שכללי המדיניות מצורפים, אפשר לעיין בשלב 6 במאמר בנושא יצירת תפקיד AWS IAM לאיסוף נתונים של הגדרות נכסים בכל חשבון.
יכול להיות שקיימת אחת מהבעיות הבאות שקשורות למדיניות איסוף:
- יכול להיות שמדיניות האיסוף לא קיימת.
- מדיניות האיסוף לא מצורפת לתפקיד של הכלי לאיסוף נתונים.
- מדיניות האיסוף לא כוללת את כל ההרשאות הנדרשות.
כדי לפתור בעיות שקשורות למדיניות איסוף, אפשר לעיין במאמרים הבאים:
המאמרים הבאים
- אם אתם מגדירים את Security Command Center Enterprise בפעם הראשונה, כדאי להגדיר תכונות נוספות באמצעות מדריך ההגדרה.
אפשר גם לבצע את הפעולות הבאות:
- הפעלה ושימוש ב-הערכת נקודות חולשה ב-AWS.
- ליצור ולנהל מצב אבטחה ב-AWS.
- יצירת סימולציות של נתיבי תקיפה למשאבי AWS.
- מיפוי התאימות של משאבי AWS לתקנים ולמדדים שונים.