حالات الاستخدام للمسؤول المفوض لمؤسسات AWS

هذه الوظيفة الجديدة ليست مسؤولًا مفوضًا بنفس المعنى الذي تدعمه الخدمات الأخرى، حيث يتم تعيين حساب واحد كمسؤول يتمتع بإمكانيات كاملة على الخدمة. وبدلاً من ذلك، يعمل المسؤول المفوض لمؤسسات AWS كسياسة موارد مطبقة على المؤسسة، ويشار إليه بسياسة التفويض المستند إلى الموارد. يعد هذا أمرًا مهمًا لأنه يعني أنه يمكنك تطبيق كشوف متعددة يمنح كل منها إمكانية مختلفة لحساب مختلف أو مجموعة حسابات. على سبيل المثال، يمكنك منح حساب واحد القدرة على تعديل SCP المرفق بوحدة تنظيمية واحدة، وحساب آخر القدرة على تعديل SCP لوحدة تنظيمية مختلفة، وحساب آخر القدرة على إدارة سياسة النسخ الاحتياطي للوحدة التنظيمية الأولى. ويعني هذا أيضًا أنه يمكنك (ولكن لا ينبغي عليك) منح جميع الحسابات في مؤسستك جميع ميزات المنظمة المتاحة لتعديل SCPs الخاصة بهم والسياسات الأخرى.

حالات الاستخدام

إمكانية الرؤية في أسماء وعلامات الحسابات الأخرى في المؤسسة

غالبًا ما تواجه فرق الأمان صعوبة في تحديد ما إذا كان معرف الحساب المشار إليه يشير إلى حساب داخل مؤسستهم، وإذا كان الأمر كذلك، فما هو الغرض من استخدام هذا الحساب. يمكن أن تظهر معرفات الحساب غير المعروفة هذه في العديد من الأماكن: علاقة ثقة في سياسة حاوية S3، أو ARN مُشار إليه في سياسة IAM، أو في نتيجة تم إنشاؤها بواسطة GuardDuty. تعالج الفرق المختلفة هذه المشكلة بطرق مختلفة:

• الحفاظ على جداول البيانات التي تصف الحسابات عبر المؤسسة—هذا الأسلوب يدوي للغاية، لذلك لا تتم مزامنة جداول البيانات في كثير من الأحيان.

• إنشاء دور IAM في حساب AWS Organization Management الذي يجب افتراضه للوصول إلى organizations:ListAccounts واجهة برمجة التطبيقات.

• إنشاء خدمة تستخدم تقنية دور IAM أو يتم تشغيلها مباشرة في حساب إدارة المؤسسة.

يحل المسؤول المفوض لمؤسسات AWS مشكلة الرؤية هذه بشكل أكثر أناقة من أي من هذه الأساليب. يتيح لك منح الحساب القدرة على رؤية الحسابات الأخرى في المؤسسة والعلامات المطبقة عليها مباشرة عن طريق إنشاء سياسة تفويض المؤسسة كما يلي:

{ 
  "Version": "2012-10-17", 
  "Statement": [ 
    { 
      "Sid": "ListAccounts", 
      "Effect": "Allow", 
      "Principal": { 
        "AWS": "123456789012" 
      }, 
      "Action": [ 
        "organizations:ListAccounts", 
        "organizations:ListTagsForResource" 
      ], 
      "Resource": "*" 
    }
  ] 
} 

لاحظ أنه عندما يتصل حساب العضو aws organizations list-accounts ولا يحتاج إلى إصدار جديد من واجهة سطر الأوامر (CLI) ولا يمرر معرف المؤسسة، لأنه مرة أخرى، لا يمكنك تفويض هذه المكالمات إلى حساب خارج مؤسستك.

باستخدام هذه الإمكانية، إذا قمت بوضع علامة على جميع الحسابات في مؤسستك باستخدام مالك، مثل قناة Slack، فيمكنك الآن الاستجابة لتنبيه GuardDuty من خلال البحث عن “المالك” باستخدام aws organizations list-tags-for-resource --resource-id 222222222222 ونقل التنبيه تلقائيًا إلى قناة Slack الخاصة بهم.

إمكانية الوصول إلى SCPs المطبقة على حسابك

الشكوى الشائعة من المطورين عند نشر SCPs هي أنهم لا يعرفون ما هي SCPs التي تؤثر عليهم. ترغب بعض فرق الأمان في الحفاظ على سرية SCPs الخاصة بها لأنها تخشى إمكانية تجاوز سياساتها، أو أن هذه المعرفة قد تكون مفيدة للمهاجم الذي قام باختراق الحساب. ومع ذلك، لا تزال العديد من المؤسسات ترغب في هذه الرؤية، لذا يوضح ما يلي كيفية تفويض هذه القدرة إلى جميع الحسابات في المؤسسة:

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
      { 
        "Sid": "ViewEffectiveSCPs", 
        "Effect": "Allow", 
        "Principal": { 
          "AWS": "*" 
        }, 
        "Action": [ 
          "organizations:DescribePolicy", 
          "organizations:ListParents", 
          "organizations:ListPoliciesForTarget" 
        ], 
        "Resource": "*", 
        "Condition": { 
          "StringEquals": { 
            "aws:PrincipalOrgID": "o-xxxxxxxxx" 
          }, 
          "StringLikeIfExists": { 
            "organizations:PolicyType": "SERVICE_CONTROL_POLICY" 
          } 
        } 
      }
    ]
  } 

في هذا المثال، أضفت شرطًا يقيد المبادئ الأساسية التي يمكنها استدعاء هذا فقط لأولئك الموجودين داخل المؤسسة. هذا غير ضروري في الوقت الحالي حيث أنه يمكن منح هذه الامتيازات فقط لحسابات الأعضاء، ولكنه يجعلني غير مرتاح للحصول على Principal ل * بدون شرط، وهذا دليل مستقبلي على إمكانية التوسع في إمكانيات هذه الميزة.

يمكن كتابة برنامج نصي بسيط لطباعة SCPs المطبقة على الحساب باستخدام هذه الامتيازات:

#!/usr/bin/env python 
  
import boto3 
import json 

session = boto3.Session() 
sts = session.client("sts") 
org = session.client("organizations") 

# Get account id 
target = sts.get_caller_identity()['Account'] 

printed_policies = [] 

# Iterate up the org structure from the account, to any OUs, to the root 
while(True): 
    policies = org.list_policies_for_target(TargetId=target, Filter='SERVICE_CONTROL_POLICY').get('Policies', []) 
    for policy in policies: 
        policy_id = policy['Id'] 
        if policy_id not in printed_policies: 
            printed_policies.append(policy_id) 
            contents = org.describe_policy(PolicyId=policy_id) 
            print(json.dumps(contents['Policy'], indent=4)) 

    if target.startswith('r-'): 
        # We've reached the root, so exit 
        break 
    parents = org.list_parents(ChildId=target).get('Parents', []) 
    if len(parents) != 1: 
        # There should be only one parent. 
        raise Exception("Unexpected number of parents") 

    target = parents[0]['Id'] 

التحكم في SCP لوحدة تنظيمية

في الشركات الكبيرة التي لديها وحدات أعمال متعددة، قد تتواجد العديد من حسابات AWS في مؤسسة AWS واحدة، ولكن قد ترغب وحدات الأعمال المختلفة في التحكم في SCPs المطبقة على حسابات AWS الخاصة بها. أصبح من الممكن الآن تحقيق ذلك دون الحاجة إلى الوصول إلى حساب إدارة المؤسسة عبر دور IAM. البيان التالي، والذي يمكن إرفاقه بسياسة التفويض أعلاه، يمنح الحساب القدرة على تعديل SCP محدد:

{ 
  "Sid": "ModifySingleSCP", 
  "Effect": "Allow", 
  "Principal": { 
    "AWS": "123456789012" 
  }, 
  "Action": [ 
    "organizations:UpdatePolicy" 
  ], 
  "Resource": "arn:aws:organizations::111111111111:policy/o-exampleorgid/service_control_policy/p-examplepolicyid111", 
} 

انتبه إلى أنه إذا تم تطبيق SCP هذا على الوحدة التنظيمية التي يوجد بها هذا الحساب المفوض، فيمكن للحساب المفوض قفل نفسه. حساب إدارة المؤسسة، الذي كان الحساب الوحيد الذي يمكنه تعديل SCPs، لا يمكن أن يقفل نفسه أبدًا لأن SCPs لا تنطبق عليه.