חיבור ל-AWS לצורך איסוף נתונים של הגדרות ומשאבים

אפשר לקשר את מהדורת 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 לצורך זיהוי איומים.

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

הגדרות של AWS ו-Security Command Center.

סקירה כללית של שלבי ההגדרה

אחרי שמבצעים את השלבים בקטע לפני שמתחילים, פועלים לפי השלבים בכל קטע כדי לקשר את מהדורת Enterprise של Security Command Center לסביבת Amazon Web Services ‏ (AWS):

  1. הגדרת המחבר של AWS
  2. מגדירים את סביבת AWS באחת מהשיטות הבאות:
    • באופן אוטומטי באמצעות תבניות CloudFormation
    • באופן ידני על ידי הזנת חשבונות AWS
  3. השלמת תהליך השילוב של מחבר AWS

לפני שמתחילים

צריך להשלים את המשימות האלה לפני שממשיכים למשימות הנותרות בדף הזה.

הגדרת הרשאות ב Google Cloud

כדי לקבל את ההרשאות שדרושות לשימוש במחבר AWS, צריך לבקש מהאדמין להקצות לכם ב-IAM את התפקיד בעלים של נכס ב-Cloud (roles/cloudasset.owner). להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

יצירת חשבונות AWS

ודאו שיש לכם את משאבי AWS הבאים:

הגדרת המחבר של AWS

  1. פותחים את הכרטיסייה מחברים בדף הגדרות.

    כניסה לדף Connectors

  2. בוחרים את הארגון שבו הפעלתם את Security Command Center Enterprise.

  3. בוחרים באפשרות מחברים > הוספת מחבר > Amazon Web Services.

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

  5. כדי לאפשר ל-Sensitive Data Protection ליצור פרופיל של נתוני AWS, צריך להשאיר את האפשרות Grant permissions for Sensitive Data Protection discovery מסומנת. האפשרות הזו מוסיפה הרשאות של AWS Identity and Access Management ‏ (IAM) בתבנית CloudFormation לתפקיד של כלי האיסוף.

    הרשאות AWS IAM שניתנות באמצעות האפשרות הזו

    • s3:GetBucketLocation
    • s3:ListAllMyBuckets
    • s3:GetBucketPolicyStatus
    • s3:ListBucket
    • s3:GetObject
    • s3:GetObjectVersion
    • s3:GetBucketPublicAccessBlock
    • s3:GetBucketOwnershipControls
    • s3:GetBucketTagging
    • 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:CreateSession
    • s3express:GetBucketPolicy
    • s3express:ListAllMyDirectoryBuckets
    • wafv2:GetIPSet
  6. אופציונלי: בודקים ועורכים את האפשרויות המתקדמות. אפשרויות נוספות מפורטות במאמר התאמה אישית של הגדרות מחבר AWS.

  7. לוחצים על Continue. נפתח הדף Connect to AWS (חיבור ל-AWS).

  8. צריך לבחור אחת מהאפשרויות האלה:

    • משתמשים בתבניות 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:

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

    חשוב לזכור:

    • אם שיניתם את שם התפקיד של התפקיד שהוקצו לו הרשאות, של תפקיד המאסף או של התפקיד Sensitive Data Protection, צריך לעדכן את הפרמטרים בהתאם. הפרמטרים שאתם מזינים צריכים להיות זהים לאלה שמופיעים בדף Connect to AWS במסוף Google Cloud .
    • ממתינים ליצירת ה-stack. אם מתרחשת שגיאה, אפשר להיעזר בקטע פתרון בעיות. מידע נוסף זמין במאמר בנושא יצירת מחסנית במסוף AWS CloudFormation במסמכי התיעוד של AWS.
  3. יוצרים מחסנית שמקצה את תפקידי האוסף. מידע נוסף על התהליך הזה זמין במאמר יצירת 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.

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

    השלב הזה נדרש כי ערכות מחסניות של AWS CloudFormation לא יוצרות מופעי מחסניות בחשבונות ניהול. מידע נוסף זמין במאמר בנושא DeploymentTargets במסמכי התיעוד של AWS.

מבצעים את השלבים שמפורטים בקטע השלמת תהליך השילוב.

הגדרה ידנית של חשבונות AWS

אם אתם לא יכולים להשתמש בתבניות CloudFormation (לדוגמה, אם אתם משתמשים בשמות תפקידים שונים או מבצעים התאמה אישית של השילוב), אתם יכולים ליצור באופן ידני את מדיניות AWS IAM ואת תפקידי AWS IAM הנדרשים.

בודקים את הקטעים הבאים וממלאים אותם לפי הסדר:

  1. יצירת מדיניות AWS IAM לתפקיד המוקצה
  2. יצירת תפקיד AWS IAM ליחסי האמון בין AWS לבין Google Cloud
  3. יצירת מדיניות AWS IAM לאיסוף נתוני הגדרות של נכסים
  4. יצירת תפקיד AWS IAM לאיסוף נתוני תצורה של נכסים בכל חשבון
  5. יצירת מדיניות 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

  1. חוזרים לדף Connect to AWS (קישור ל-AWS) ולוחצים על Continue (המשך).
  2. ב Google Cloud מסוף, בדף Test connector, לוחצים על Test connector כדי לוודא ש-Security Command Center יכול להתחבר לסביבת AWS שלכם. אם החיבור מצליח, הבדיקה קובעת שלתפקיד המואצל יש את כל ההרשאות הנדרשות כדי לקבל את תפקידי האוסף. אם החיבור לא מצליח, אפשר לעיין במאמר פתרון בעיות של שגיאות בבדיקת החיבור.

  3. לוחצים על 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

בוחרים באפשרות הרצויה:

  • הוספת חשבונות באופן אוטומטי (מומלץ): בוחרים באפשרות הזו כדי לאפשר ל-Security Command Center לגלות את חשבונות 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 הקיים.

  1. במסוף Google Cloud , עוברים אל הגדרות > הגדרות SCC.

    כניסה לדף Settings

  2. בוחרים את הארגון שבו הפעלתם את Security Command Center Enterprise.

  3. בוחרים באפשרות מחברים. נפתח הדף Configure connector (הגדרת המחבר).

  4. במחבר AWS, לוחצים על אפשרויות נוספות > עריכה.

  5. בקטע Review data types, בוחרים באפשרות Grant permissions for Sensitive Data Protection discovery.

  6. לוחצים על Continue. נפתח הדף Connect to AWS (חיבור ל-AWS).

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

  8. לוחצים על הורדת תבנית של תפקיד לאיסוף נתונים. התבנית תרד למחשב.

  9. לוחצים על Continue. ייפתח הדף Test connector (בדיקת מחבר). עדיין לא בודקים את המחבר.

  10. במסוף CloudFormation, מעדכנים את תבנית ה-stack עבור התפקיד שהוקצו לו הרשאות:

    1. נכנסים למסוף של חשבון הנציג ב-AWS. מוודאים שאתם מחוברים לחשבון הנציג שמשמש להנפקת חשבונות AWS אחרים של כלי האיסוף.
    2. נכנסים למסוף AWS CloudFormation.
    3. מחליפים את תבנית ה-Stack לתפקיד המוקצה בתבנית התפקיד המוקצה המעודכנת שהורדתם.

      מידע נוסף זמין במאמר עדכון תבנית של מחסנית (מסוף) במסמכי העזרה של AWS.

  11. מעדכנים את ערכת ה-stack לתפקיד של המאסף:

    1. באמצעות חשבון ניהול של AWS או כל חשבון חבר שרשום כאדמין עם הרשאות גישה, עוברים אל מסוף AWS CloudFormation.
    2. מחליפים את תבנית ה-Stack Set לתפקיד המאסף בתבנית המעודכנת של תפקיד המאסף שהורדתם.

      מידע נוסף מופיע במאמר עדכון של קבוצת ה-stack באמצעות מסוף AWS CloudFormation במסמכי העזרה של AWS.

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

    השלב הזה נדרש כי ערכות מחסניות של AWS CloudFormation לא יוצרות מופעי מחסניות בחשבונות ניהול. מידע נוסף זמין במאמר בנושא DeploymentTargets במסמכי התיעוד של AWS.

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

  14. לוחצים על Save.

עדכון ידני של מחבר קיים

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

  1. פותחים את הכרטיסייה מחברים בדף הגדרות.

    כניסה לדף Connectors

  2. בוחרים את הארגון שבו הפעלתם את Security Command Center Enterprise.

  3. במחבר AWS, לוחצים על אפשרויות נוספות > עריכה.

  4. בקטע Review data types, בוחרים באפשרות Grant permissions for Sensitive Data Protection discovery.

  5. לוחצים על Continue. נפתח הדף Connect to AWS (חיבור ל-AWS).

  6. לוחצים על הגדרה ידנית של חשבונות AWS (מומלץ אם משתמשים בהגדרות מתקדמות או בשמות תפקידים מותאמים אישית).

  7. מעתיקים את הערכים של השדות הבאים:

    • השם של התפקיד שהוקצו לו הרשאות
    • שם התפקיד של המאסף
    • שם התפקיד של כלי האיסוף של Sensitive Data Protection
  8. לוחצים על Continue. ייפתח הדף Test connector (בדיקת מחבר). עדיין לא בודקים את המחבר.

  9. במסוף של חשבון הנציג ב-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.

  10. לכל חשבון של כלי האיסוף, מבצעים את הפעולות הבאות:

    1. יוצרים את מדיניות AWS IAM עבור Sensitive Data Protection.

    2. יוצרים את תפקיד AWS IAM עבור Sensitive Data Protection בכל חשבון.

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

  12. לוחצים על 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_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_COLLECTOR_ROLE_POLICY_MISSING_REQUIRED_PERMISSION

החיבור לא תקין כי חסרות במדיניות של כלי האיסוף חלק מהגדרות ההרשאות הנדרשות.

כדי לפתור את השגיאה הזו, כדאי לבדוק את הסיבות הבאות:

המאמרים הבאים