در دنیای پنهان امنیت ابری، گاهی اوقات باید چیزهایی را بشکنید تا آنها را تعمیر کنید. این دقیقاً همان چیزی است که وقتی زیرساخت AWS درجه سازمانی ما با یک دیوار تأیید اعتبار حیاتی برخورد کرد، اتفاق افتاد. مقصر؟ یک ارائه‌دهنده SAML قدیمی که کلیدهای KMS ما را گروگان نگه می‌داشت.
شرکتی که من در آن کار می کنم، نزدیک به یک دهه است که در آب های متلاطم AWS پیمایش کرده است. در طول سال‌ها، ما از حساب‌های کاربری AWS (یک پاس تقلبی امنیتی) به یک راه‌حل SSO شیک تغییر کرده‌ایم که بعداً با یک ارائه‌دهنده هویت جدید و راه‌حل SSO منتقل و ادغام شد. این سفر بدون چالش نبود، و تیم های مهندسی و امنیتی ما به طور خستگی ناپذیری برای حذف همه حساب های کاربری کار کردند – داستانی برای یک روز دیگر. با این حال، این هفته با یک معمای جدید روبرو شدیم: یک تیم متوجه شدند که نمی توانند از کلید KMS که برای برخی از سیستم های داده ما حیاتی است استفاده کنند.
علیرغم سکسکه، سیستم‌های ما به لطف نقشی که هنوز به آن دسترسی داشت، به زمزمه کردن ادامه دادند kms:GenerateDataKey، kms:Decrypt، و kms:Encrypt. هیچ داده ای از بین نرفت و ما می توانستیم از داده ها رمزگشایی و استفاده کنیم. با این حال، نقش فاقد مجوز برای به‌روزرسانی خط‌مشی کلیدی (kms:PutKeyPolicy)، به طور موثر ما را از انتساب نقش های دیگر به کلید باز می دارد.
برای شانس، نقش دیگری از راه حل SSO قبلی خود با مجوزهای کامل در کلید KMS پیدا کردیم. این افشاگری تنها پس از باز کردن یک بلیط پشتیبانی با AWS صورت گرفت. این نقش توسط AWS IAM Identity Center ایجاد شده است، و با این نکته همراه است که خط مشی اعتماد را نمی توان به روز کرد. نقش هویت AWS IAM دارای فرمت زیر است: arn:aws:iam::123456789012:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_profilename_somehexdigest و سیاست اعتماد به این صورت است:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:saml-provider/AWSSSO_somehexrandomnumbers_DO_NOT_DELETE"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}
اینجاست که جالب شد. ارائه‌دهنده SAML هنوز آنجا بود و به یک شبح دیجیتال اشاره می‌کرد – سروری که دیگر وجود نداشت. آیا می توانیم آن را به سرور دیگری که بتوانیم آن را کنترل کنیم به روز کنیم؟ و پاسخ این است که بله، ما می توانیم! ما با ایجاد یک ارائه‌دهنده SAML جدید، زیرساخت‌های خود را ربودیم. این دقیقاً همان تکنیکی است که توسط هکرهای کلاه سیاه برای دستیابی به دسترسی پایدار AWS در یک حساب استفاده می شود. شما فقط به یک نقش IAM و یک ارائه دهنده SAML نیاز دارید.
پس از یک فرو رفتن سریع در اعماق اینترنت، به طور تصادفی به برخی از راهنماهای ساده و گام به گام در مورد استفاده از Keycloak، یک راه حل منبع باز هویت و مدیریت دسترسی، رسیدیم. این ابزار که به صورت محلی اجرا می‌شود، به ارائه‌دهنده SAML تبدیل می‌شود که ما به شدت به آن نیاز داشتیم.
در این پست تمام مراحل لازم برای راه اندازی آن ارائه شده است. ما تصمیم گرفتیم که Keycloak را در داخل یک ظرف اجرا کنیم، و نیاز به نصب و پیکربندی گسترده را از بین بردیم.
docker run -p 8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.0.7 start-dev
برای ورود به AWS، به دو ویژگی SAML خاص نیاز دارید، و بسیار مهم است که ویژگی‌های اضافی را که AWS نمی‌تواند پردازش کند شامل نشود:
-
نام جلسه: این می تواند هر مقدار تصادفی باشد، مانند نام کاربری. نام ویژگی است
https://aws.amazon.com/SAML/Attributes/RoleSessionName -
نقش جلسه: لیستی از نقش هایی که کاربر می تواند به عهده بگیرد. نام ویژگی است
https://aws.amazon.com/SAML/Attributes/Role
نقش باید از این قالب پیروی کند:
arn:aws:iam:::role/,arn:aws:iam:::saml-provider/
هنگامی که Keycloak راه اندازی شد، مرحله بعدی به روز رسانی IAM Identity Provider برای استفاده از فایل فراداده تولید شده بود. نشانی اینترنتی صادرکننده جدید چیزی شبیه به این بود http://localhost:8080/realms/aws، و مکان سرویس SSO به روز شد http://localhost:8080/realms/aws/protocol/saml. اجرای داخل داکر در حالت توسعه به این معنی بود که SSL پیکربندی نشده بود، که برای مقداردهی اولیه جریان SAML قابل قبول بود.
با دسترسی http://localhost:8080/realms/aws/protocol/saml/clients/keycloak-sso و با احراز هویت با کاربری که قبلا ایجاد کرده بودیم، با فرض نقشی که دسترسی به آن را از دست داده بودیم، به طور یکپارچه به کنسول AWS هدایت شدیم. با دسترسی مجدد، به‌روزرسانی خط‌مشی کلید KMS، افزودن اصل جدید و حذف مراجع نقش قدیمی از خط‌مشی، کار ساده‌ای بود.
نکات کلیدی این تجربه:
- یک لیست مختصر از ارائه دهندگان هویت IAM، شامل تنها ارائه دهندگان SAML ضروری، نگهداری کنید.
- دسترسی به به روز رسانی و ایجاد ارائه دهندگان هویت جدید را محدود کنید.
- نظارت بر تغییرات ارائه دهندگان SAML.
این تیم بینش ارزشمندی از تجربه، درک تاکتیک‌هایی که هکرها به کار می‌گیرند و سادگی اجرای مانورهای خاص به دست آوردند. ما مشتاقیم فرصت های بیشتری را برای آزمایش اخلاقی سیستم های خود برای یادگیری عمیق تر بررسی کنیم.
