رفتن به محتوای اصلی

امنیت

وضعیت امنیتی هما متا پلتفرم

این صفحه توضیح می‌دهد پلتفرم چگونه طراحی شده و در مواردی که ذکر شده، امروز چگونه پیاده‌سازی شده است. آگاهانه از ادعای هر گواهی‌نامه‌ای که به‌صورت مستقل صادر نشده باشد پرهیز می‌کند.

کنترل‌ها و رویه‌ها

مجوزدهی OAuth

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

  • درخواست مجوزدهی در سمت سرور ساخته می‌شود، بنابراین مجموعه مجوزهای درخواستی در مرورگر قابل دستکاری نیست.
  • هما هرگز فرم ورود متا را نمایش نمی‌دهد و هرگز رمز عبور یا کد دو‌مرحله‌ای متا را درخواست نمی‌کند.
  • انصراف در صفحه رضایت متا به این معناست که هیچ اتصالی ایجاد نمی‌شود.

مدیریت اسرار

اسرار اپلیکیشن تنها از پیکربندی سمت سرور خوانده می‌شوند. این مقادیر در مخزن کد ثبت نمی‌شوند و از طریق هیچ متغیر عمومی افشا نمی‌گردند.

  • پیکربندی قابل‌دسترس در سمت کلاینت محدود به مقادیری است که انتشار آن‌ها بی‌خطر است، مانند نشانی عمومی سایت.
  • کلید محرمانه اپلیکیشن متا، در صورت نیاز، تنها در مسیرهای کد سمت سرور خوانده می‌شود.
  • محیط‌ها از هم جدا هستند تا پیکربندی توسعه به ترافیک عملیاتی نرسد.

ذخیره‌سازی رمزنگاری‌شده توکن

توکن‌های دسترسی در سمت سرور و به‌صورت رمزنگاری‌شده نگهداری می‌شوند. توکن‌ها در نشانی‌ها، رشته پرسمان، بسته‌های سمت کلاینت، حافظه مرورگر یا لاگ‌های اپلیکیشن قرار نمی‌گیرند.

  • محتوای توکن محدود به سازمانی است که آن را مجاز کرده است.
  • انقضا پایش می‌شود تا توکن منقضی به‌جای شکست خاموش، به‌صورت درخواست اتصال مجدد نمایش داده شود.
  • لغو دسترسی و قطع اتصال به گونه‌ای طراحی شده‌اند که توانایی پلتفرم برای استفاده از توکن را از بین ببرند.

امنیت انتقال و کوکی‌ها

وب‌سایت عمومی و همه نقاط پایانی سرویس روی HTTPS ارائه می‌شوند. هدر HSTS در محیط عملیاتی ارسال می‌شود تا مرورگرها از کاهش امنیت اتصال جلوگیری کنند.

  • کوکی‌های نشست، در صورت استفاده، با نشانه‌های HttpOnly و Secure و مقدار مناسب SameSite تنظیم می‌شوند.
  • هدرهای پاسخ شامل محافظت از نوع محتوا، سیاست محافظه‌کارانه ارجاع‌دهنده و سیاست محدودکننده مجوزهای مرورگر است.
  • قرارگیری در قاب با دستور frame-ancestors محدود شده تا سطح مجوزدهی توسط اشخاص ثالث جای‌گذاری نشود.

محافظت CSRF و اعتبارسنجی state

هر درخواست مجوزدهی یک مقدار state یک‌بارمصرف متصل به نشست آغازکننده دارد. این مقدار پیش از تبادل هر کد مجوز، در زمان بازگشت اعتبارسنجی می‌شود.

  • مقدار state گم‌شده، ناشناس، تکراری یا منقضی موجب توقف ایمن فرایند می‌شود.
  • نشانی بازگشت در پیکربندی اپلیکیشن متا ثبت شده و از ورودی کاربر پذیرفته نمی‌شود.
  • اعتبارسنجی ناموفق یک صفحه خطای عمومی نمایش می‌دهد و جزئیات سرویس‌دهنده را به کاربر بازنمی‌گرداند.

بررسی امضای وب‌هوک

نقطه پایانی وب‌هوک با استفاده از یک verify token که در پیکربندی سرور نگهداری می‌شود به چالش تأیید متا پاسخ می‌دهد و امضای هر تحویل بعدی را بررسی می‌کند.

  • محتوای بدون امضا یا با امضای نامعتبر بدون پردازش رد می‌شود.
  • شناسه رویداد برای حذف تحویل‌های تکراری استفاده می‌شود تا پردازش تکرارناپذیر بماند.
  • پردازش به‌صورت صف‌بندی‌شده طراحی شده تا مصرف‌کننده کند موجب شکست تحویل نشود.

کمینه دسترسی

پلتفرم طراحی شده تا تنها مجوزهای مورد نیاز قابلیت‌های فعال‌شده هر سازمان را درخواست کند و در صورت غیرفعال شدن قابلیت، درخواست آن مجوز را متوقف کند.

  • مجموعه مجوزها در زمان مجوزدهی ثبت می‌شود تا انحراف قابل تشخیص باشد.
  • دارایی‌هایی که انتخاب نمی‌کنید هرگز در دامنه قرار نمی‌گیرند، حتی اگر مدیر آن‌ها باشید.
  • افزودن قابلیتی که به مجوز گسترده‌تری نیاز دارد، مجوزدهی جدید و صریح لازم دارد.

جداسازی سازمانی

اعتبارنامه‌ها، دارایی‌های متصل، رویدادها و سوابق حسابرسی محدود به سازمانی هستند که آن‌ها را ایجاد کرده است. دسترسی میان‌سازمانی از قابلیت‌های موردنظر این پلتفرم نیست.

لاگ‌های حسابرسی

رویدادهای مجوزدهی، اتصال مجدد، قطع اتصال و حذف داده ثبت می‌شوند تا تغییرات یک یکپارچه‌سازی بعداً قابل بررسی باشد.

  • سوابق حسابرسی به گونه‌ای طراحی شده‌اند که ثبت کنند چه کسی، روی چه دارایی و در چه زمانی اقدام کرده است.
  • متن پیام‌ها و محتوای توکن تا حد امکان از لاگ‌های حسابرسی و عیب‌یابی خارج نگه داشته می‌شوند.

لغو دسترسی و حذف داده

می‌توانید یکپارچه‌سازی را از هما CRM قطع کنید و به‌صورت مستقل، هما متا پلتفرم را از بخش یکپارچه‌سازی‌های کسب‌وکاری در تنظیمات حساب متا لغو کنید. هر یک از این دو اقدام دسترسی بیشتر را متوقف می‌کند.

حذف داده‌های ذخیره‌شده از طریق فرایند حذف داده‌های کاربر انجام می‌شود که یک شماره پیگیری صادر می‌کند و توضیح می‌دهد کدام سوابق ممکن است به دلایل قانونی یا امنیتی نگهداری شوند.

رویه‌های توسعه امن و وابستگی‌ها

  • تغییرات پیش از انتشار بازبینی می‌شوند و پیکربندی محیط توسعه از عملیاتی متفاوت است.
  • وابستگی‌ها به‌صورت منظم به‌روزرسانی می‌شوند و هشدارهای امنیتی در اولویت قرار می‌گیرند.
  • سطوح نمایش خطا به گونه‌ای طراحی شده‌اند که ردپای اجرا، اسرار، توکن‌ها یا پاسخ خام سرویس ثالث افشا نشود.
  • ورودی کاربران و محتوای وب‌هوک پیش از استفاده اعتبارسنجی می‌شود.

پاسخ به رخداد

اگر گمان می‌کنید آسیب‌پذیری یافته‌اید یا به رخدادی مرتبط با یک دارایی متصل مشکوک هستید، با نشانی امنیتی زیر و با جزئیات کافی برای بازتولید مسئله تماس بگیرید. لطفاً اعتبارنامه یا توکن فعال را در گزارش خود قرار ندهید.

تماس امنیتی

گزارش آسیب‌پذیری‌ها یا رخدادهای مشکوک باید مستقیماً به نشانی امنیتی ارسال شود، نه به پشتیبانی عمومی.

مستندات توسعه‌دهندگان را مرور کنید

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