إحدى الطرق الشائعة للسماح لحلول SaaS التابعة لجهات خارجية بالوصول إلى حسابات AWS هي عبر عمليات تكامل OpenID Connect (OIDC). تتطلب عمليات التكامل هذه شروطًا محددة في سياسة الثقة الخاصة بـ AWS IAM، وإذا لم تكن هذه الشروط موجودة، فقد تسمح للجهات الفاعلة غير المرغوب فيها بالوصول إلى حساب AWS. لقد حدد الباحثون ونشروا معلومات حول أربعة من أخطاء تكامل البائعين التي يمكن أن يرتكبها العملاء. يجمع منشور المدونة هذا تلك الأمثلة المحددة في مناقشة المشكلة العامة ويوسع النطاق ليشمل جميع البائعين الذين لديهم وثائق عامة حول هذا التكامل.
في عام 2023، حددت مجموعات متعددة من الباحثين (1، 2، 3، 4) أن بعض الشركات لم تقم بتضمين شرط “فرعي” في سياسة الثقة في دور IAM الخاصة بها والتي سمحت لأي مستخدم GitHub بإنشاء إجراء GitHub الذي يمكن أن يتولى دور IAM للضحية. فيما يلي مثال لسياسة ثقة الدور الصحيحة التي تتضمن الشرط الفرعي المطلوب:
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:sub": "repo:GithubOrg/GitHubRepo:ref:refs/heads/GitHubBranch",
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}إذا كان الشرط “الفرعي” في السياسة أعلاه مفقودًا، وكان المهاجم على علم بدور IAM الذي كان مفقودًا، فيمكن للمهاجم إنشاء إجراء GitHub في مستودع GitHub الخاص به والذي يمكن أن يتولى دور IAM هذا. يقيد الشرط “الفرعي” من يمكنه تولي هذا الدور بإجراءات GitHub القادمة من مستودع وفرع محددين فقط.
تم تنفيذ بعض الأشياء بواسطة AWS مما أدى في الغالب إلى القضاء على هذه المشكلة. قد تكون هناك بعض التكوينات القديمة التي لا تزال تعاني من هذه المشكلة، ولكن لم يعد بإمكانك إنشاء سياسة ثقة دور IAM التي تثق في إجراءات GitHub ولا تحتوي على الشرط “الفرعي” الضروري في السياسة. لقد كتبت عن مشاركتي في هذا سابقًا: قصة نجاح لمجتمع الأمان في التخفيف من التكوين الخاطئ.
بعد اكتشاف هذه المشكلة عند التكامل مع GitHub Actions، وجد أن نفس المفهوم يؤثر أيضًا على عمليات التكامل مع Terraform Cloud وMicrosoft Defender وGitlab. تكمن المشكلة العامة في أنه إذا لم يتضمن العميل شروطًا معينة تقيد من يمكنه الوصول إلى دور AWS IAM، فيمكن للمهاجم التسجيل للحصول على حساب باستخدام إحدى هذه الخدمات والوصول إلى دور AWS IAM الخاص بالعميل.
بدلاً من الاستمرار في هذه الدورة من التعرف على موفري OIDC الجدد والأخطاء التي يمكن ارتكابها معهم كل بضعة أشهر، قررنا النظر في جميع عمليات تكامل الموفر التي يمكن إجراؤها مع AWS عبر OIDC. لقد قمنا بذلك بناءً على الوثائق العامة التي تمكنا من العثور عليها، لتحديد الحالة الحرجة المطلوبة. لقد وجدنا أكثر من عشرين موردًا يقدمون عمليات تكامل OIDC مع AWS وقمنا بمراجعة وثائقهم.
قد تعتقد في البداية أنك تحتاج فقط إلى التأكد من وجود شرط “فرعي” في جميع عمليات تكامل OIDC، ولكن مشكلة Microsoft Defender مثيرة للاهتمام لأن الشرط المطلوب لتجنب هذه المشكلة موجود على قيمة “sts:RoleSessionName” كما هو موثق هنا. وبالمثل، يستخدم المورد المسمى DoIT “aws:RequestTag/DoitEnvironment” بدلاً من “sub” كما هو موثق هنا.
تستخدم بعض عمليات تكامل الموردين فقط “aud”، ولا تستخدم شرطًا “فرعيًا” أو أي شرط آخر. على سبيل المثال، صياغة صناديق الرمل (موثقة هنا) والنقل الفوري (موثقة هنا). يذكر بعض البائعين قيمة “aud”، ولكنها نفس القيمة لجميع العملاء، وبالتالي لا يبدو أن هناك حاجة إليها، مثل GitHub (وغيرها الكثير) الذي يستخدم قيمة “aud” في “sts.amazonaws.com”. توثق عمليات تكامل الموردين الأخرى فقط الحاجة إلى شرط “فرعي”، مثل Gitlab (docs) وBitbucket (docs).
تحتوي العديد من عمليات التكامل هذه على قيم خاصة بالعميل في عناوين URL لموفر OIDC (الجزء الموجود في العنصر “الموحد” من سياسة json) أو قيم الجمهور (الجزء الموجود في العنصر “aud”)، أو كليهما، مما يقيد الوصول إلى عميل معين، لذلك قد تكون هناك أجزاء متعددة تتجاوز الشرط “الفرعي” المهم. في تلك الحالات، قد لا يشكل عدم وجود شرط “فرعي” خطرًا كبيرًا لأن المهاجم سيحتاج إلى الوصول الأولي إلى العميل لاحتمال إساءة استخدام هذا بشكل أكبر. تنطوي هذه المواقف على مخاطر أقل، ولكن لا يزال ينبغي استخدام شروط إضافية عند توفرها.
يجب أن تكون حذرًا جدًا عند النظر إلى هذه القيم. في بعض الأحيان تبدو وكأنها قيم عشوائية قد تفترض أنها فريدة لعميلك، لكنها ليست كذلك! على سبيل المثال، في تكامل Microsoft Defender، يستخدم كل عميل عنوان URL لموفر OIDC الخاص بـ sts.windows.net/33e01921-4d64-4f8c-a055-5bdaffd5e33d/ وقيمة الجمهور api://1462b192-27f7-4cb9-8523-0f4ecb54b47e. وبالمثل، يستخدم env0 قيمة “aud” لـ hoMiq9PdkRh9LUvVpH4wIErWg50VSG1b لجميع العملاء (موثقة هنا).
يتم تشغيل بعض عمليات تكامل الموردين من المجالات المملوكة للعملاء، مما قد يجعل من الصعب تحديد ماهية التكامل. قد يقوم بعض عملاء AWS أيضًا بإنشاء موفري OIDC داخليين خاصين بهم، لذلك ليس من الممكن الحصول على قائمة شاملة لماهية كل تكامل بائع محتمل. أخيرًا، ليس لدى بعض مقدمي الخدمة أي وثائق عامة لفهم ما إذا كانت هناك شروط إضافية موصى بها بشكل أفضل.
في بعض الأحيان لا يكون شرط “aud” مفيدًا جدًا (على سبيل المثال مع Github Actions يكون دائمًا “sts.amazonaws.com”)، ولكن القاعدة العامة هي أنه يجب عليك التأكد من أن لديك شرط “aud” وشرط “sub” لجميع عمليات تكامل OIDC الخاصة بك، والتحقيق في الوثائق إذا لم يكن الأمر كذلك. وقد يحتاجون إلى شرط واحد فقط، أو قد يحتاجون إلى شرط آخر غير الشرط “الفرعي”.
يحتوي AWS Access Analyzer على فحوصات السياسة التالية المتعلقة بتكامل OIDC والتي تتضمن:
بالنسبة للموردين المختلفين الذين يقدمون عمليات تكامل OIDC مع AWS، قمنا بإنشاء اكتشافات للبحث عن عمليات التكامل تلك التي كانت تفتقد الشروط المطلوبة.
يعرض الجدول التالي عددًا من الموردين الذين نعرفهم، مع الوثائق العامة، والشروط الموصى بها في عمليات تكامل OIDC. يتم توفير هذا لإظهار التباين في هذه التكاملات. يرجى الرجوع إلى وثائق البائع أو دعمهم للتأكيد والتوجيه الرسمي.
تشير A ✅ إلى أن القيمة موصى بها (وهي فريدة لكل عميل)، بينما تشير ❌ إلى أن الوثائق لا تحتوي على توصية لهذا العنصر. سلسلة في aud عمود مثل “sts.amazonaws.com” يشير إلى أن نفس قيمة السلسلة موصى بها لجميع العملاء، بدلاً من كونها قيمة خاصة بالعميل. أما “الآخر؟” يذكر العمود العناصر الشرطية الأخرى الموصى بها.
لدى AWS أربعة موفري هوية مدمجين. هذه لها متطلبات حالة فريدة على النحو التالي (موثقة هنا):
-
cognito-identity.amazonaws.com: الشروط “aud” و”amr” و”sub” و”oaud”.
-
www.amazon.com: الشروط “app_id” و”sub” و”user_id”.
-
graph.facebook.com: الشروط “app_id” و”id”.
-
account.google.com: الشروط “aud” و”sub” و”oaud”.
ومن الشائع أيضًا رؤية موفري هوية OIDC المرتبطين بـ EKS، كما هو موثق هنا. يجب أن تحتوي هذه الشروط على شروط “aud” و”sub”. يتم دائمًا ضبط شرط “aud” للتحقق من القيمة “sts.amazonaws.com”. لقد رأينا أن هذا يتم تجاهله بشكل شائع، وعلى الرغم من أننا لا نعرف وجود مخاوف أمنية عند ترك هذا الأمر لهذا التكامل، فإننا نعتقد أنه من الأفضل التوافق مع وثائق هذه الخدمة واستخدام التحقق من الحالة لها.
حتى لو كان التكامل يتمتع بالشروط اللازمة، فقد لا يكون الشرط صحيحًا كما ينبغي. على سبيل المثال، مع إجراءات GitHub، سيتضمن الشرط “الفرعي” مؤسسة GitHub والمستودع والفرع، لذلك يمكن لأي شخص استخدام StringLike في الشرط “الفرعي” للسماح بأي ريبو وفرع في المؤسسة، والتي قد تكون أكثر انفتاحًا مما ينبغي.
وبالذهاب في الاتجاه الآخر ليكون أكثر أمانًا، فإن بعض البائعين، مثل Bitbucket وBuildkite، يذهبون إلى أبعد من ذلك من خلال التوصية أيضًا بأن يقوم العملاء بتقييد الوصول إلى مجموعة من عناوين IP المصدر (موثقة هنا وهنا).
تُعد عمليات تكامل AWS OIDC طريقة آمنة لمنح الوصول إلى حساب AWS، ولكن أحيانًا يخطئ العملاء في تكوينها. تحتوي العديد من عمليات التكامل هذه على خطوات يدوية خاصة لإضافة شروط إضافية إلى السياسات التي قد يفتقدها العملاء، مما يؤدي إلى عمليات تكامل غير آمنة. يجب عليك التأكد من أن جميع عمليات تكامل OIDC الخاصة بك تحتوي على كل من “aud” و”sub”، والتحقق من أي استثناءات نظرًا لوجود بائعين يعملون بشكل مختلف.
