یونیوم مدیریت میکند
رمزنگاری سشن در پایگاهداده، انتشار کلید با scope و expiry، نگهداری امن سشن روی هر حساب متصل، تحویل وبهوک روی HTTPS، و زنجیره احراز هویت درخواست (توکن دسترسی شخصی یا کلید API با امضای هر درخواست).
دسترسی کمینه، جداسازی محیطها و مشاهدهپذیری
یونیوم رشته سشن هر credential را رمزنگاریشده در پایگاهداده نگه میدارد، کلیدهای API را با scope و expiry میسازد و وبهوکها را فقط روی HTTPS تحویل میدهد. اما خود توکن، endpoint مقصد و نحوه پردازش رویداد ورودی بر عهده شماست. این صفحه دقیقاً مرز بین آن دو را مشخص میکند.
چه چیزی روی دوش یونیوم است و چه چیزی روی دوش شما
یک API واحد به این معنا نیست که همهچیز را یک طرف مدیریت میکند. امنیت واقعی محصول از همافزایی کنترلهای سکو و پیکربندی مصرفکننده به دست میآید. مرز زیر را بهطور شفاف تعریف کردهایم تا بدانید کجا باید تمرکز کنید.
شما مدیریت میکنید
محل نگهداری توکن (secret manager نه Git نه frontend)، scope هر کلید، جدا کردن محیط dev و prod، امنسازی endpoint وبهوک مقصد، و فرایند rotation هنگام خروج نیرو از تیم.
مرز مشترک
پاسخ سریع ۲۰۰ به وبهوک، فراخوانی با کد کمینه، و لاگبرداری بدون ذخیره متن پیام یا راز در سیستمهای خودتان. خطای هر طرف در این مرز، با شناسه درخواست در لاگ قابل ردیابی است.
جریان داده: یونیوم چه میبیند و چه نگه میدارد
هر درخواست از یک توپولوژی مشخص عبور میکند. میخواهیم بدانید دقیقاً چه فیلدی ذخیره میشود، چرا، و چگونه میتوانید آن را در داشبورد یا با پشتیبانی ردیابی کنید.
وقتی پیامی از طریق یونیوم ارسال میشود، چند دسته داده پشت صحنه ثبت میشود. هیچکدام برای کارکرد سرویس اختیاری نیستند، اما محتوای هرکدام متفاوت است و سیاست نگهداریشان نیز همینطور.
رشته سشن هر حساب بهصورت رمزنگاریشده نگهداری میشود و فقط در زمان احراز هویت مجدد باز میشود. هر ارسال با شناسه API key و حساب مقصد ثبت میشود تا صورتحساب و دیباگ ممکن شود؛ فراخوانیهای خام API نیز برای عیبیابی نگهداری میشوند.
دادهی صورتحساب سابقهدار بهعنوان مرجع مالی نگهداری میشود؛ برای گزارشگیری همیشه محدوده زمانی مشخص کنید. دادهی فراخوانی خام قابل پاکسازی دورهای است.
- رشته سشن — رمزنگاریشده و متعلق به هر حساب متصل؛ هرگز در پاسخ API ظاهر نمیشود.
- سوابق ارسال — شناسه حساب، گیرنده، وضعیت، پاسخ و خطا. برای صورتحساب و عیبیابی.
- سوابق درخواست API — متد، مسیر، وضعیت پاسخ، آدرس درخواستدهنده و شناسهها. قابل پاکسازی دورهای.
- دسترسی — این دادهها در داشبورد و از طریق پشتیبانی قابل ردیابیاند؛ در صورت نیاز به پاکسازی، تماس بگیرید.
کنترلهای عملی برای یک اتصال امن
این موارد توصیههای اجرایی هستند و ادعای گواهی یا انطباق رسمی محسوب نمیشوند. هرکدام یک تصمیم ملموس در داشبورد یا در کد شماست، نه یک شعار کلی.
کمترین دسترسی
کلید هر سرویس را به حسابها و عملیات ضروری محدود کنید و دسترسی مدیر را برای کارهای روزمره استفاده نکنید. هر کلید فقط باید همان scope ای را داشته باشد که سرویس مصرفکننده واقعاً نیاز دارد.
جداسازی محیط
کلید، اتصال و endpoint آزمایش را از محیط عملیاتی جدا نگه دارید تا خطای توسعه به داده واقعی نرسد. یک اشتباه در dev نباید پیام واقعی به مشتری بفرستد.
حفاظت از رازها
توکن و کلید را در secret manager یا متغیر محیطی نگه دارید؛ هرگز آن را در جاوااسکریپت سمت کاربر یا Git قرار ندهید. جزئیات بیشتر در بخش بعد.
وبهوک مقاوم
HTTPS، اعتبارسنجی ورودی، idempotency، timeout کوتاه و صف پردازش را برای endpoint رویداد در نظر بگیرید. الگوی دقیق ۲۰۰-then-queue را پایینتر باز کردهایم.
حداقل نگهداری داده
فقط داده لازم را برای مدت لازم ذخیره کنید و محتوای پیام یا توکن را وارد لاگ عمومی نکنید. سوابق ارسال را با محدوده زمانی مشخص کوئری بزنید، نه بازیابی کامل جدول.
مشاهدهپذیری
شناسه درخواست و شناسههای حساب و کلید را در لاگ خودتان نگه دارید. هنگام خطای احراز هویت یا قطعی در تحویل درخواست، این سه شناسه تفاوت بین دیباگ یکساعته و حدسزدن بیپایان است.
مدیریت رازها: توکن کجاست و کجا نیست
بیشترین حوادث امنیتی در تجمیعکنندهها از یک اشتباه ساده میآید: توکن جایی مانده که نباید. سه قانون سخت را رعایت کنید و بیشتر ریسک پوشش داده میشود.
یک PAT یا API key یونیوم دقیقاً معادل رمز عبور حساب شماست؛ هر کسی که آن را داشته باشد میتواند از نوبت شما پیام بفرستد، credentialها را ببیند یا وبهوک را تغییر دهد. به همین دلیل محل ذخیره آن یک تصمیم معماری است، نه یک جزئیات پیکربندی.
قانون اول: توکن هرگز در frontend نباشد. اگر کد سمت کاربر شما آن را میبیند، هرکسی View Source بزند هم میبیند. قانون دوم: هرگز در Git نباشد؛ حتی در یک repo خصوصی، حتی در history. قانون سوم: در تیمهای چندنفره، rotation هنگام خروج نیرو یک فرایند الزامی است، نه یک best practice اختیاری.
ابزارهای پیشنهادی: Vault، Doppler، AWS Secrets Manager، یا حداقل فایل .env خارج از repo با .gitignore اجباری.
- متغیر محیطی روی سرور که فقط سرویس backend میخواند.
- Secret manager با rotation خودکار و audit log.
- کلید جدا برای هر محیط (dev/staging/prod) با scope متفاوت.
- هرگز در JavaScript سمت کاربر،
localStorageیا bundle فرانت. - هرگز در Git، حتی repo خصوصی یا کامنت کد.
- هرگز در query string URL یا در لاگ برنامه.
- هنگام خروج نیرو یا تغییر نقش، کلید را revoke کنید و دوباره بسازید.
وبهوک مقاوم: الگوی ۲۰۰-then-queue
بزرگترین منشأ پردازش دوگانه، تایماوت و از دست رفتن رویداد، یک endpoint وبهوک است که قبل از پاسخ، کار سنگین انجام میدهد. الگوی صحیح، پاسخ فوری و سپس پردازش در صف است.
۱. دریافت روی HTTPS
یونیوم وبهوک را فقط روی HTTPS تحویل میدهد. endpoint روی HTTP تنظیم نشود. اگر پلتفرم امضای درخواست میدهد، قبل از هر کاری آن را اعتبارسنجی کنید.
۲. idempotency با message_id
کلید idempotency را از message_id بسازید و در یک مجموعه (Redis یا DB) چک کنید. تلاش مجدد یونیوم نباید پیام را دو بار پردازش کند.
۳. پاسخ ۲۰۰ فوری
قبل از هر پردازش سنگین، 200 OK برگردانید. این تایماوت سمت یونیوم را برطرف میکند و retryهای ناخواسته را متوقف میکند.
۴. پردازش در صف
رویداد را در یک صف (PGMQ، Redis، Celery) بریزید و worker با timeout حدود ۱۰ ثانیه روی هر تلاش آن را پردازش کند. شکست، با backoff تلاش مجدد میکند.
اگر endpoint شما روی همهی پلتفرمها یک شکل رفتار نمیکند، طبیعی است: مثلاً تأیید امضای وبهوک فقط روی برخی پلتفرمها معنی دارد. این تفاوتها را در راهنمای توسعه دنبال کنید. اگر IP allowlist میخواهید، بازه خروجی یونیوم را از پشتیبانی بگیرید.
اشتباههای رایج که دامنه اثر را بزرگ میکند
هیچکدام از این موارد نادر نیستند؛ هرکدام حداقل یک حادثه واقعی در تجمیعکنندهها داشتهاند. خواندن این فهرست، ارزانترین دفاع شماست.
کلید مدیر برای کار روزمره
استفاده از یک کلید همهکاره برای همه سرویسها. leak در یکجا، کل سیستم را مختل میکند. به جای آن: کلید جدا per scope، per محیط.
وبهوک بدون idempotency
تلاش مجدد یونیوم، پیام را دوباره در CRM ثبت میکند. مشتری دو پیام تأیید سفارش میبیند. کلید idempotency از message_id.
لاگ کامل payload
ذخیره متن پیام یا media URL در سیستم لاگ خودتان، dataset حساس میسازد. فقط شناسهها را لاگ کنید: شناسه پیام، شناسه حساب و شناسه کلید.
پردازش همزمان طولانی
فراخوانی CRM یا DB سنگین قبل از پاسخ ۲۰۰، تایماوت میسازد و retry زنجیرهای راه میاندازد. الگوی ۲۰۰-then-queue را رعایت کنید.
توکن در Git
حتی در repo خصوصی. یک git log یا leak دستی کافی است. .env در .gitignore، یا بهتر: secret manager.
بدون rotation
همان کلید برای سالها. وقتی نیرو میرود یا لپتاپ گم میشود، نمیدانید کی دسترسی داشته. هر ۹۰ تا ۱۸۰ روز، یا هنگام خروج، rotate کنید.
پاسخ به رخداد امنیتی
اگر شکستید توکن شما لو رفته، یا رفتار مشکوکی در حساب میبینید، این پنج قدم را به ترتیب اجرا کنید. هدف اول، محدود کردن دامنه اثر است؛ ریشهیابی بعد از آن.
۱. ابطال کلید
در داشبورد، کلید مشکوک را فوراً revoke کنید. این کار جریان درخواست را متوقف میکند، حتی اگر ریشه را هنوز ندانید.
۲. بررسی سوابق ارسال
دامنه اثر را از سوابق ارسال با فیلتر شناسه کلید و شناسه حساب و محدوده زمانی مشخص کنید. کدام گیرندهها، چه پیامهایی، چه زمانی.
۳. تعویض وبهوک
اگر endpoint وبهوک در معرض بوده، URL یا secret امضا را عوض کنید و در داشبورد بهروزرسانی کنید. رویدادهای در حال پرواز را در صف نگه دارید.
۴. اطلاع به تحتتأثیرها
اگر پیام به مشتریان واقعی رفته، تیم محصول و در صورت لزوم گیرندهها را مطلع کنید. پنهانکردن، اعتماد بیشتری میشکند از خود حادثه.
۵. post-mortem
ریشه را بنویسید: کجا لو رفت، کدام کنترل جواب نداد، چه چیزی اضافه میشود (rotation خودکار؟ alert غیرعادی؟). بدون این قدم، حادثه تکرار میشود.
برای حوادثی که به زیرساخت یونیوم مربوط است (مثلاً قطعی در تحویل درخواست یا خطای سراسری احراز هویت)، اول صفحه وضعیت را ببینید؛ اغلب از قبل در حال رسیدگیایم.
یک مورد امنیتی پیدا کردهاید؟
جزئیات بازتولید و اثر احتمالی را خصوصی ارسال کنید؛ اطلاعات حساس را عمومی منتشر نکنید. هر گزارش مسئولانه را جدی میگیریم و در صورت تأیید، اعتبار میگذاریم.