سلسله مراتب حساب ها و کاربران فرعی

(بخش: عملیات و مدیریت)

1) وظایف و اصول

سلسله مراتب حسابها تعریف می کند که چگونه سازمان ها و افراد به منابع پلتفرم دسترسی پیدا می کنند و چگونه حقوق، سهمیه ها، بودجه ها و مسئولیت ها توزیع می شوند.

• تفکیک نگرانی ها: ما منعکس کننده ساختار کسب و کار در درخت نهاد و حقوق در سیاست ها هستیم.
• حداقل امتیاز: پیش فرض - حداقل نقش، ارتقاء موقت از طریق JIT.
• Composability: نقش ها/سهمیه ها/محدودیت ها به ارث برده و لغو می شوند.
• سیاست به عنوان کد: سیاست های دسترسی، سهمیه، صدور صورت حساب - مصنوعات نسخه.
• حسابرسی - هر عمل به یک موضوع، زمینه و امضا مرتبط است.

2) مدل مرجع سلسله مراتب

Tenant
├─ Account - legally/operationally significant unit
│ ├─ Sub-account - Product/Region/Team/Project
│ │ ├─ Spaces/Projects/Environments: prod/stage/dev
│ │ └─ Roles and Groups (RBAC/ABAC) for People and Services
│ └─ Shares (limits, budgets, keys, integrations)
└─ Marketplace/Integrations/Affiliates (Outer Loops)

• مستاجر: صاحب قراردادها، صورتحساب سطح بالا، سیاست های جهانی و SSO ها.
• حساب: منطقه جدا شده از مسئولیت (نام تجاری/کشور/کد شرکت) ؛ بودجه/محدودیت های خود
• حساب فرعی: واحد کار (محصول/جریان/فرمان) ؛ کلیدها، سهمیه ها، نقش ها و حسابرسی شما.

3) مدل های مجوز

RBAC: роли مالک/مدیر/اپراتور/بیننده/صدور صورت حساب/انطباق.
ABAC: атрибуты «منطقه»، «مستاجر»، «حساب»، «محیط زیست»، «ریسک _ نمره»، «وضعیت _ دستگاه».
ReBAC: «مالکیت/مشارکت/بررسی» روابط برای پروژه ها و اسرار.

تمرین: ترکیبی - RBAC به عنوان یک پایه قابل خواندن، ABAC برای محدودیت های زمینه (منطقه/زمان/دستگاه)، ReBAC برای مالکیت منابع.

4) نمایندگی و ارث

Delegation down: Tenant-admin نقش مدیر حساب، همان - نگهدارنده زیر حساب را می دهد.
لغو: سهمیه ها/محدودیت ها/سیاست ها می تواند درخت را تشدید کند.
مرزهای اعتماد: PII/Finance - فقط در سطح حساب «مناطق اعتماد» ؛ حساب فرعی نشانهها/مجموعهها را میبیند.
Break-glass: دسترسی اضطراری با TTL کوتاه، هشدار خودکار و پس از مرگ.

5) سهمیه، بودجه، صورتحساب

سهمیه: درخواست/ثانیه، حوادث/روز، خروج، ذخیره سازی، کلید/webhooks.
بودجه: کلاه ماهانه و هشدار (80/90/100٪)، خودکار throttling/تعلیق.

صورتحساب: فاکتورها در سطح مستاجر/حساب ؛ بخش حساب های فرعی و مراکز هزینه

قیمت گذاری انتقال: هزینه های داخلی بین BU/مناطق.
استفاده منصفانه: محدودیت های عمومی، محدودیت های نرخ، حفاظت در برابر «انفجار».

6) هویت و SSO/SCIM

SSO (SAML/OIDC): ورود متمرکز در سطح مستاجر.
SCIM: ایجاد خودکار/غیر فعال کردن کاربران/گروه ها و اتصال به نقش ها.
JML (Joiner/Mover/Leaver): صدور خودکار نقش های شروع، تجدید نظر در ترجمه، یادآوری فوری پس از اخراج.
MFA/FIDO2: اجباری برای مدیران، امور مالی و دسترسی به PII.
وضعیت دستگاه: تحمل وضعیت دستگاه (رمزگذاری، EDR).

7) حساب های خدمات و کلید

حساب خدمات در هر زیر حساب + محیط زیست، هیچ اسرار مشترک.
هویت حجم کار: نشانه های کوتاه مدت، اتصال به پایین/عملکرد.
KMS/Vault: چرخش مخفی، دسترسی به نقش، امضاهای DSSE.
صفحات وب: امضاهای HMAC/EdDSA، «nonce + timestamp»، پنجره TTL.

8) مدل داده (ساده شده)

"tenant" {شناسه، نام، sso، billing_profile، سیاست ها] "

'account' {شناسه، tenant_id، منطقه، legal_entity، سهمیه {}، بودجه {}، risk_tier}'

'sub _ account' '{id, account_id, product, environment, keys [], webhooks [], limits {}'

'role' '{id, scope: tenant' account 'sub _ account, permissions []}'

'عضویت' {موضوع _ شناسه، role_id، scope_ref، TTL، توجیه} '

'policy' {type: rbac 'abac' sod 'quota', version, rules, signature} '

'audit _ event' {چه کسی، چه، کجا، چه زمانی، trace_id، امضا} '

'quota _ usage' '{scope _ ref, metric, window, used, cap}'

9) قراردادهای API

• 'POST/tenants/{ id }/accounts' - ایجاد حساب (سیاست/سهمیه/صدور صورت حساب).
• 'POST/accounts/{ id }/sub-accounts' - یک حساب فرعی ایجاد کنید (کلیدها، وبوکها).
• 'PUT/roles/{ id}' - سیاست نقش ؛ ' POST/اعضا - یک نقش را تعیین کنید.
• 'POST/دسترسی/بالا بردن' - افزایش JIT با TTL و توجیه.
• 'GET/quota/use' - usage/cap; ' POST/quota/override '.

• GET/حسابرسی/حوادث ؟ محدوده =... '- سیاهههای مربوط امضا شده است.
• 'GET/وضعیت/دسترسی' - نقش اقدام/TTL/کلید.
• Вебхуки: 'QuotaCapReached', 'RoleExpiring', 'KeyRotationDue', 'تغییر سیاست'.

10) RACI (مناطق کلیدی)

11) معیارها و SLO

TTG (Time-to-Grant): میانگین دسترسی استاندارد ≤ 4 ساعت

پوشش JIT: ≥ 80٪ از معاملات ممتاز از طریق نقش های موقت.
تخلفات SoD: 0 в prod; TTR حذف ≤ 24 ساعت.
دسترسی یتیم: سهم حقوق «فراموش شده» ≤ 0. 1%.
دقت سهمیه بندی: تطابق اقلام تعهدی/استفاده ≥ 99. 99%.
کامل بودن حسابرسی: 100٪ فعالیت امضا/دریافت بحرانی.

12) داشبورد

دسترسی به سلامت: نقش فعال توسط سطح، انقضای TTL، نقض SoD.
FinOps: استفاده سهمیه بندی، پیش بینی بودجه، ناهنجاری های خروج/محاسبه.
امنیت: چرخش کلید، شکست MFA/SSO، میزان خطر گروه ها.
انطباق: وضعیت جواز مجدد، سیاهههای مربوط به ممیزی، نقض سیاست.
عملیات: درخواست دسترسی MTTR، TTFI برای دستورات جدید.

13) محدودیت داده ها و حریم خصوصی

دامنه های داده: PII/Finance - فقط سطح حساب ؛ زیر حساب - aggregates/tokens.
منطقه ای بودن: محلی سازی داده ها و کلیدها در هر منطقه (مناطق اعتماد).

درخواست PII: فقط از طریق تایید jabs ؛ نشانه گذاری و ماسک کردن

14) خطرات و ضد الگوهای

Flat-model: همه - «مدیران →» حوادث و نشت.

اسرار مشترک: غیرقابل اطمینان بودن و عدم امکان بررسی

No SoD: یک نفر پرداخت ها/محدودیت ها را ایجاد و تصویب می کند.
محیط های unposted: کلید های dev در prod ؛ تست مخلوط کردن و داده های واقعی.
نقش «بی نهایت»: بدون TTL/جواز مجدد → تجمع خطر.
سهمیه های ضعیف: یک حساب فرعی ظرفیت همه را «می خورد».

15) کتاب های حادثه

سازش کلید حساب فرعی: لغو فوری، چرخش وابستگی ها، محاسبه مجدد سهمیه ها، حسابرسی 7-30 روز گذشته.
بیش از سهمیه: خودکار کنترل/مکث، اطلاع از مالک، کلاه بودجه موقت.
نقض SoD: مسدود کردن عملیات، حذف موقت نقش، تحقیق و اصلاح سیاست.
جایگزینی webhooks: ممنوعیت دریافت بدون امضا/خارج از TTL، کلید مجدد، آشتی وضعیت و نقطه پایانی.

16) ماندگاری و چرخه عمر

1. راه اندازی مستاجر: SSO/SCIM، مشخصات صورتحساب، سیاست های جهانی.

2. ایجاد حساب - مناطق، سهمیه ها، بودجه ها، مناطق داده، نقش های پایه

3. زیر حساب: کلید/webhooks، نقش تیم، ادغام.
4. JML/جواز مجدد: بررسی سه ماهه از حقوق، خودکار حذف «خواب».
5. EOL: بایگانی، یادآوری کلیدی، انتقال مالکیت، بسته شدن صورتحساب.

17) چک لیست پیاده سازی

• آشتی مستاجر → حساب → درخت زیر حساب و ارث قوانین.
• توصیف نقش (RBAC) و سیاست های زمینه (ABAC)، ماتریس SoD.
• شروع SSO/SCIM، فرآیندهای JML و افزایش JIT.
• قوانین سهمیه/بودجه/کلاه و هشدار را وارد کنید.
• استقرار KMS/طاق، چرخش، و اسرار به اشتراک گذاشته شده است.
• شامل سیاست ها به عنوان کد، نسخه های امضا شده و سیاهههای مربوط به WORM.
• پیکربندی API های مدیریت/webhooks، نقاط پایانی وضعیت و حسابرسی.
• ساخت داشبورد دسترسی/FinOps/امنیت/انطباق.
• رفتار GameDay: نشت کلیدی، طوفان سهمیه بندی، شکست IdP، نقض SoD.
• به طور منظم نقش ها را مجددا تأیید کنید و محدودیت ها را بررسی کنید.

18) سوالات متداول

مرز بین حساب و حساب فرعی را کجا نگه داریم ؟

که در آن امور مالی/انطباق/نظارتی (حساب) تغییر, و زیر حساب - در مورد تیم/محصول/محیط زیست.

آیا امکان «چسباندن» سهمیه های چندین حساب فرعی وجود دارد ؟

بله، از طریق استخر و اولویت ها، اما با ظرفیت «سوزاندن» فیوز.

چگونه به سرعت دسترسی موقت را صادر کنیم ؟

برنامه JIT با MFA و TTL، autologation و پس از مرگ برای جلسات ممتاز.

آیا من نیاز به کلید های مختلف در روز چهارشنبه ؟

مورد نیاز: حساب های سرویس جداگانه/کلید برای توسعه/مرحله/prod با جداسازی شبکه ها و حقوق.

سلسله مراتب حساب ها و زیر کاربران یک چارچوب مدیریت است: یک ساختار قابل خواندن از اشخاص، سیاست های ارثی، سهمیه های سختگیرانه و صورتحساب، هویت های امن و حسابرسی قابل اثبات. با اجرای RBAC/ABAC/ReBAC، JIT/SoD و ترکیبی از سیاست به عنوان کد، شما می توانید هزینه های سریع، هزینه های قابل پیش بینی و امنیت پایدار را در هنگام مقیاس محصول، تیم و منطقه به دست آورید.