--- title: "مقررات تبادل داده‌ها با اعتماد صفر برای قراردادهای SaaS چند ابری" --- # مقررات تبادل داده‌ها با اعتماد صفر برای قراردادهای SaaS چند ابری پذیرش سریع **نرم‌افزار به عنوان سرویس** (SaaS) در چندین ابر عمومی، اکوسیستم داده‌ای پیچیده‌ای را ایجاد کرده است که در آن اطلاعات به‌طور مرتب از بین مرزهای ارائه‌دهندگان، مناطق و محیط‌های مشتری عبور می‌کند. مدل‌های امنیتی سنتی مبتنی بر مرز دیگر کافی نیستند، زیرا فرض می‌کنند شبکه داخلی قابل اعتماد و بیرون آن نامطمئن است. در مقابل، **اعتماد صفر** (ZT) *هر* اتصالی را به‌عنوان ممکن است خصمانه در نظر می‌گیرد و نیاز به تأیید مستمر، دسترسی با حداقل امتیاز و رمزنگاری جامع دارد. گنجاندن مفاهیم ZT مستقیماً در قراردادهای SaaS به‌عنوان یک نیاز غیرقابل مذاکره برای سازمان‌هایی که باید داده‌های حساس را حفاظت کرده و همزمان به تعهدات نظارتی مانند **قانون عمومی حفاظت از داده** (GDPR) و استانداردهای صنعتی نظیر **ISO/IEC 27001** پایبند باشند، شناخته می‌شود. ## چرا اعتماد صفر باید قراردادی باشد وقتی یک ارائه‌دهنده SaaS در یک محیط **چند ابر** (MC) عمل می‌کند — با بهره‌گیری از Amazon Web Services، Microsoft Azure، Google Cloud Platform یا ابرهای منطقه‌ای ویژه — مسیر داده به‌طور چشمگیری گسترش می‌یابد. هر گره جدید سطوح حمله، حوزه‌های قضایی انطباق و سیاست‌های حاکمیتی متفاوتی را به‌وجود می‌آورد. با تدوین کنترل‌های ZT در قرارداد، هر دو طرف یک پایه قانونی مشترک و قابل اجرا دریافت می‌کنند که: 1. **مسئولیت‌های مربوط به رمزنگاری، احراز هویت و نظارت** را در تمام ابرها روشن می‌سازد. 2. **ابهام مربوط به اقامت داده (DR) و انتقالات فرامرزی** را که منبع شایع اختلافات GDPR و CCPA هستند، کاهش می‌دهد. 3. **قابلیت حسابرسی** را از طریق گزارش‌دهی اجباری لاگ‌های دسترسی، حوادث امنیتی و گواهی‌های انطباق فراهم می‌کند. بدون بندهای واضح ZT، سازمان‌ها خطر تکیه بر وعده‌های امنیتی ضمنی را دارند که ممکن است در طول یک تحقیقات نفوذ یا ممیزی نظارتی پابرجا نباشد. ## اجزای اصلی یک بند تبادل داده با اعتماد صفر یک بند ZT قوی باید پنج حوزهٔ به‌هم‌پیوسته را پوشش دهد: هویت، وضعیت دستگاه، تقسیم‌بندی شبکه، رمزنگاری و تأیید مستمر. بخش‌های زیر هر حوزه را شرح می‌دهند و زبان قراردادی پیشنهادی را ارائه می‌کنند که می‌تواند به هر توافق‌نامهٔ SaaS اعمال شود. ### مدیریت هویت و دسترسی (IAM) قرارداد باید الزام کند که ارائه‌دهنده **احراز هویت قوی و فدرال** برای تمام کاربران، سرویس‌ها و APIها پیاده‌سازی کند؛ ترجیحاً با استفاده از **SAML 2.0**، **OpenID Connect** یا **OAuth 2.0**. دسترسی باید بر پایهٔ **حداقل امتیاز** باشد و کنترل‌های دسترسی مبتنی بر نقش یا ویژگی حداقل هر سه ماه یکبار بازبینی شوند. *نمونهٔ متن*: “The Provider shall enforce multi‑factor authentication for all administrative and data‑access accounts and shall implement role‑based access controls that restrict permissions to the minimum necessary for each function. Access rights shall be reviewed and re‑certified every 90 days.” ### وضعیت دستگاه و اطمینان نقطهٔ انتهایی حتی در مدل صرفاً ابری، نقاط انتهایی — مانند راننده‌های CI/CD، عوامل مانیتورینگ یا دروازه‌های مدیریت‌شده توسط مشتری — باید به معیارهای امنیتی برسند. قرارداد باید ارائه‌دهنده را ملزم به حفظ ارزیابی **ماژول پلتفرم مورد اعتماد** (TPM) به‌روز و الزام به **بررسی‌های صحت زمان‌اجرایی** قبل از اجازهٔ دریافت داده کند. *نمونهٔ متن*: “All endpoints that interface with the Provider’s data ingestion APIs shall pass continuous integrity verification based on approved device posture standards, including up‑ ## موارد مرتبط - - - - -