AWS مؤخرًا مطلق سراحه RCPs (سياسات التحكم في الموارد) وهي سياسة الموارد المكافئة لـ SCPs (سياسات التحكم في الخدمة). يتيح لك ذلك وضع قيود عبر مؤسسة AWS بأكملها بشأن من يمكنه الوصول إلى مواردك (أو كيف)، حتى عندما يكون هؤلاء المديرون خارج مؤسستك. على سبيل المثال، يمكنك القول أنه لا يمكن لأي شخص خارج مؤسستك الوصول إلى حاويات S3 الخاصة بك، لذلك حتى لو قام شخص ما في مؤسستك بوضع سياسة حاوية S3 التي يجب أن تجعلها عامة، فلن تكون عامة في الواقع. سنناقش في هذا المنشور بعض حالات الاستخدام وكيف يمكنك نشرها بأمان.
إذا كنت معتادًا بالفعل على SCPs، فإن RCPs هي ببساطة شكل مختلف من ذلك. لديهم حدود للطول، تمامًا مثل SCPs. إنهم لا يمنحون أي امتيازات، ولكنهم يحددون القيود فقط، تمامًا مثل SCPs. لديهم قيود مختلفة على العناصر التي يمكن استخدامها مقابل بناء جملة IAM الكامل، تمامًا مثل SCPs. ويمكن تطبيقها على مؤسسة AWS بأكملها، أو الوحدات التنظيمية، أو الحسابات الفردية، تمامًا مثل SCPs.
هناك مشكلتان عامتان تتعلقان بسياسات الموارد على AWS والتي يمكن لـ RCPs المساعدة في حلها.
-
السيطرة على تقاسم الموارد: لم تكن هناك طريقة لمنح شخص ما القدرة على تعديل سياسة الموارد، ولكن لا تسمح له بمشاركة المورد على نطاق واسع جدًا. على سبيل المثال، قد ترغب في السماح لشخص ما بأن يتمكن من مشاركة الموارد بين حسابين مختلفين ينتميان إلى شركتك، ولكن دون جعل هذا المورد عامًا. هذا ممكن الآن. مع حاويات S3، أضافت AWS خدمة S3 Public Block Access والتي يمكن استخدامها لمنع شخص ما من جعل حاوية S3 في متناول الجميع، لكن هذا لم يمنعهم من مشاركتها مع حساب خارجي واحد غير معروف، ولم يساعد ذلك في أنواع الموارد الأخرى.
-
معايير السياسة عبر الموارد: هناك بعض البيانات التي كان الناس يتمنون لو كانت جميع سياسات الموارد لديهم، ولكن لم تكن هناك طريقة لفرض ذلك. على سبيل المثال، قد ترغب في طلب الوصول إلى جميع حاويات S3 عبر TLS 1.3 (تتم مناقشة سياسة مماثلة هنا). في السابق، كنت بحاجة إلى إضافة بيان إلى كل حاوية S3 لمنع الوصول إلى أي شيء أقل، ولكن الآن يمكنك إنشاء RCP واحد يتم تطبيقه عبر مؤسستك بأكملها.
بشكل عام، حتى الآن لم تتمكن من فرض التفويضات عبر شركتك بشأن سياسات الموارد. وقد حاولت بعض الشركات استخدام العلاج التلقائي لهذه المشكلة، ولكن عروض RCP تقدم فوائد أكثر من ذلك وغيره من الحلول، حيث لا توجد فرصة لإساءة الاستخدام المحتملة.
محيط البيانات
إحدى حالات الاستخدام المهمة لـ RCPs هي الإعداد محيطات البيانات. لا تضيف RCPs أي إمكانات لا يمكن أن تمتلكها بالفعل إستراتيجية محيط البيانات الحالية، ولكنها تجعل الأمر أسهل وأفضل لضمان تغطية الإستراتيجية. في السابق، كنت بحاجة إلى التأكد من أن كل سياسة موارد تحتوي على بيانات معينة، ولكن الآن يمكنك تعيين تلك البيانات عبر RCPs.
خدمات أمازون ويب أمثلة على سياسات محيط البيانات تم تحديث المستودع ليشمل نماذج السياسات. يوصى بشدة بمراجعة نماذج السياسات هناك. سأناقش اثنين من القدرات.
منع الحسابات غير المعروفة من تولي أدوار IAM
تحتوي إحدى العبارات الواردة في مثال سياسات محيط البيانات على معرف البيان EnforceOrgIdentities. يحتوي هذا على وظائف مفيدة جدًا للتأكد من أن حساباتك الخاصة، أو الموردين المعروفين فقط، هم الذين يمكنهم تولي أدوار IAM في حساباتك. فيما يلي نسخة مبسطة من السياسة تتضمن هذه الوظيفة فقط:
{
"Effect": "Deny",
"Principal": "*",
"Action": "sts:AssumeRole",
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:PrincipalOrgID": "<my-org-id>",
"aws:PrincipalAccount": [
"<third-party-account-a>",
"<third-party-account-b>"
]
},
"BoolIfExists": {
"aws:PrincipalIsAWSService": "false"
}
}
} وهذا يضمن أن أدوار IAM في حساباتك لا يمكن أن يتولىها إلا مدير داخل مؤسستك، أو موردو الطرف الثالث الذين قد ترغب في الموافقة عليهم. لذلك، حتى إذا قام شخص ما بإنشاء دور IAM بسياسة تجعله قابلاً للافتراض بشكل عام، فسيكون الوصول إليه مقصورًا فقط من الحسابات التي تثق بها. وهذا مفيد جدًا لأنه يمنع مشكلتين شائعتين:
-
يمنع أي شخص من السماح لبائع غير متوقع بالوصول إلى حسابه.
-
يمنع أي شخص من السماح لشكل من أشكال تكنولوجيا المعلومات الظلية بالوصول إلى حسابه. يمكن أن يكون هذا حساب AWS شخصيًا يستخدمونه للاختبار وقرروا السماح لهم بالوصول إلى بيئة AWS للإنتاج، أو حساب AWS مع حالة استخدام تجاري أكثر شرعية، ولكن تم إعداده بواسطة شخص ما خارج المؤسسة.
يمنع البيان الكامل في مستودع محيط البيانات العديد من أنواع الوصول الأخرى التي تتجاوز مجرد sts:AssumeRole كما أظهرت، ولكن بالضرورة أكثر تعقيدا نتيجة لذلك.
تقييد الوصول إلى OIDC
بيان آخر مفيد جدًا من مستودع محيط البيانات هو فرض المستأجرينOIDTrusted. باستخدام هذا، يمكنك تحديد نوع وصول OIDC المسموح به إلى بيئتك، وهي طريقة أخرى يمكن للموردين أو الأدوات التي تستخدمها الوصول إلى بيئتك. في سابقة مدونة، ناقشنا التكوين الخاطئ الذي لم يعد ممكنًا حيث يمكن لأي شخص ترك ملف sub شرط في سياسة الثقة في دور IAM الخاصة بهم عند إعداد تكامل OIDC مع GitHub Actions. من المفترض أن يتم استخدام هذا الشرط لتقييد الوصول إلى مؤسسة GitHub ومستودع وفرع محدد، ولكن لا يزال بإمكان شخص ما استخدام التحقق الشرطي الذي يطابق أي مؤسسة ومستودع وفرع GitHub، باستخدام StringLike وقيمة “*”.
تضمن العبارات التالية أولاً أنه يمكن استخدام إجراءات GitHub فقط كموفر OIDC. يمكنك إضافة المزيد من مقدمي الخدمة إلى هذا البيان حسب الحاجة. البيان التالي يقيد الوصول إلى GitHub Action من مؤسسة GitHub فقط octo-org (سوف تحتاج إلى استبدال هذا). حتى إذا لم يقم شخص ما بتكوين سياسة الثقة في دور IAM بشكل صحيح، فسيتم تقليل خطر الاستغلال عن طريق القيام بذلك. يمكن إجراء عمليات RCP مماثلة للعديد من عمليات تكامل OIDC الأخرى.
{
"Sid": "EnforceTrustedOIDCProviders",
"Effect": "Deny",
"Principal": "*",
"Action": "sts:AssumeRoleWithWebIdentity",
"Resource": "*",
"Condition": {
"Null": {
"token.actions.githubusercontent.com:sub": "true"
}
}
},
{
"Sid": "EnforceGitHubOrgAccess",
"Effect": "Deny",
"Principal": "*",
"Action": "sts:AssumeRoleWithWebIdentity",
"Resource": "*",
"Condition": {
"StringNotLikeIfExists": {
"token.actions.githubusercontent.com:sub": "repo:octo-org/*"
},
"Null": {
"token.actions.githubusercontent.com:sub": "false"
}
}
} يحتوي مستودع محيط البيانات من AWS على عدد قليل من حالات الاستخدام الأخرى لـ RCPs التي يجب مراجعتها، إلى جانب التمهيدي لهذا الدليل.
منع الإجراءات غير المرغوب فيها عند تنفيذها بواسطة حسابات خارجية
أحد الأمور المزعجة مع SCPs هو أنها لا تنطبق على المديرين خارج مؤسستك، ولكن RCPs تنطبق، لذلك يحاول الأشخاص أحيانًا استخدام SCPs لمنع الأشياء التي يمكن التحايل عليها باستخدام حساب خارجي.
على سبيل المثال، إذا كان لدينا حاوية S3 مهمة، فقد نرغب في منع أي شخص من حذف الكائنات الموجودة فيها. يمكنك استخدام S3 Object Lock، ولكن تخيل أن شخصًا ما يستخدم SCP في مؤسسته لمنع ذلك s3:DeleteObject و s3:PutBucketLifecycleConfiguration. قد يكون لديهم شعور زائف بالأمان مع هذا لأنه إذا حصل المهاجم على وصول المسؤول إلى حساب AWS الذي يحتوي على حاوية S3، فيمكنه تعيين سياسة الحاوية لمنحها s3:* إلى حساب يملكه مهاجم. وبعد ذلك، من الحساب المملوك للمهاجم، يمكنهم حذف الكائنات الموجودة في المجموعة، لأن SCP لن يؤثر عليها.
باستخدام RCPs، يمكنك التأكد من أنه لا يمكن لأي شخص، ولا حتى في حساب خارج المؤسسة، حذف الكائنات الموجودة في المجموعة. علاوة على ذلك، يمكنك التأكد من عدم إمكانية مشاركة المجموعة خارج المؤسسة في المقام الأول.
يجب أن يتم نشر RCPs تمامًا مثل SCPs. لا تحتوي RCPs، مثل SCPs، على وضع “التشغيل التجريبي” أو “التدقيق” لتتمكن من معرفة ما قد يتعطل قبل تنفيذ السياسة، لذا يجب عليك مراجعة أنماط الوصول الحالية. على سبيل المثال، إذا كنت تخطط لمنع الوصول العام إلى حاويات S3، فيجب عليك التأكد من عدم وجود حاويات S3 التي يجب أن تكون عامة.
أحد الأساليب المفيدة هو مراجعة Access Analyzer لفهم الموارد العامة حاليًا أو المشتركة خارجيًا. هذا مشاركة مدونة من AWS يصف كيفية استخدام Access Analyzer لمراجعة الوصول إلى مجموعات S3، ولكن Access Analyzer الآن يدعم 15 خدمة. ومع ذلك، تدعم RCPs 5 خدمات فقط حاليًا (s3، وsts، وsqs، وsecretsmanager، وkms)، ولكن يتم تغطيتها جميعًا بواسطة Access Analyzer.
يمكن أن يخبرك Access Analyzer بالمبادئ الخارجية التي تم منحها حق الوصول إلى الموارد، ولكن ليس كيف يُسمح لهم بالوصول إليها، لذا اعتمادًا على RCP الذي ترغب في تنفيذه، قد تحتاج إلى مزيد من التحقيق. قد تساعد أحداث CloudTrail هنا، ولكن انتبه إلى أن CloudTrail لا يسجل أحداث البيانات بشكل افتراضي.
بالإضافة إلى مراجعة السجلات قبل نشر RCP، يجب عليك أيضًا مراجعتها بعد ذلك لمعرفة ما قد يكون معطلاً. يجب أن تعرف نوع الوصول الذي يجب أن يعمل، وما الذي يجب منعه، حتى تعرف كيف تبدو أحداث الخطأ هذه وللتأكد من أن RCP يمنع نوع الوصول الذي تتوقعه.
يمكن تطبيق RCPs على الحسابات الفردية أو الوحدات التنظيمية أو المؤسسات بأكملها، تمامًا مثل SCPs. كما هو الحال مع عمليات نشر SCP، يجب عليك اختبار RCP بشكل كامل في حساب Sandbox، وإجراء نشر متجدد حيث تقوم بترقية RCP من تطبيقه على حساب Sandbox الفردي هذا، إلى بيئات التطوير، ثم البيئات المرحلية، ثم بيئات الإنتاج، وقد ترغب في تطبيقه فقط على مجموعات من بيئات الإنتاج في المرة الواحدة.
الغرض من إجراء النشر بهذه الطريقة هو محاولة اكتشاف أي مشكلات قبل أن تتسبب في انقطاع الإنتاج، والحد من نصف قطر الانفجار لانقطاع الإنتاج المحتمل. إن تطبيق RCP على حساب الإنتاج يشبه تمامًا أي تغيير آخر في الإنتاج.
شيء واحد يجب أن تكون على دراية به مع RCPs – وهو أمر واضح، ولكنني أخشى أن يزعج شخصًا ما في النهاية – هو أنه إذا كان RCP هو حمايتك الوحيدة ضد مشكلة ما، فإن إزالة أو تعديل RCP هذا قد يؤدي إلى حادث أمني.
على سبيل المثال، إذا أخطأ شخص ما في تكوين دور IAM باستخدام سياسة ثقة جعلته قابلاً للافتراض بشكل علني، ولكنه كان محميًا بواسطة RCP الذي يقيد الوصول إلى الحسابات في المؤسسة فقط، فإن إزالة RCP هذا ستسمح للمهاجم بتولي هذا الدور. قد يحدث هذا إذا تم تعديل RCP أو إزالته، أو إذا تم نقل حساب AWS الذي كان محميًا إلى وحدة تنظيمية أخرى أو مؤسسة AWS أخرى بالكامل. لن ينتقل RCP مع الحساب، لذلك تحتاج إلى التأكد من مواصلة تطبيق RCP أينما يذهب، أو تحتاج إلى نسخ حماية RCP في سياسات الموارد الخاصة بالموارد داخل الحساب الذي تتم حمايته.
شيء آخر يجب أن تكون على دراية به هو أنه مثل SCPs، عندما يمنع RCP إجراءً ما، في الاختبار الذي أجريته، تكون رسالة الخطأ مجرد رسالة عامة AccessDeniedولا يشير إلى أن RCP منع نجاح الإجراء. سيؤدي هذا إلى جعل استكشاف الأخطاء وإصلاحها أمرًا صعبًا بالنسبة للمهندسين الذين ليسوا على دراية بـ RCPs التي يتم تطبيقها على الحسابات التي يعملون فيها.
تعد RCPs إضافة مفيدة للغاية لضمان تطبيق حواجز الحماية على جميع الموارد في مؤسسة AWS. ومع ذلك، كما هو الحال مع SCPs، يجب اختبار نشرها جيدًا وعدم نشرها عبر المؤسسة مرة واحدة، وإلا فإنك ستخاطر بتعطل الأشياء.
