توسعه‌ی سامانه‌های مبتنی بر مدل‌های زبانی فراتر از اتصال چند پرامپت ساده به API است. با قرار گرفتن این مدل‌ها در مسیر جریان داده‌های سازمانی، بردارهای نفوذ جدیدی متولد می‌شوند؛ از نشت ناخواسته‌ی کلیدهای دسترسی در ریپازیتوری‌های گیت گرفته تا انتقال ناآگاهانه‌ی داده‌های حساس و اطلاعات هویتی کاربران (PII) به سرورهای خارجی. اگر سازوکار درستی برای محافظت از کلیدها و داده‌ها نداشته باشید، هر کامیت اشتباه یا فراخوانی نسنجیده‌ی API می‌تواند به یک بحران امنیتی بدل شود.
در معماری‌های ابری نوین، گیت‌وی هوش مصنوعی (AI Gateway) به عنوان نقطه‌ی امن تماس عمل میکند. این گیت‌وی کلیدها را در زمان اجرا مستقیماً از والت‌های متمرکز دریافت کرده و با بازنشانی دوره‌ای (کمتر از 90 روز)، نیاز به دیپلوی مجدد سرویس‌ها را از بین می‌برد. همچنین با پیاده‌سازی گاردریل‌های ورودی و خروجی، ماسک کردن اطلاعات محرمانه با تکنیک‌های توکنسازی پایدار، و مسدودسازی ترافیک خروجی سرورها جز به دامنه‌های سفید، امنیت لایه‌به‌لایه به همراه لاگ‌های بازرسی تغییرناپذیر برقرار می‌شود.
در صورتی که به دلیل محدودیت‌های دسترسی یا عدم امکان پرداخت مستقیم ارزی از ارائه‌دهنده‌های واسط یا گیت‌وی‌های داخلی سازگار با API استفاده می‌کنید، تفکیک اطلاعات احراز هویت و پایش لاگ‌ها اهمیتی دوچندان می‌یابد. این درس دقیقاً مهارت‌های لازم برای ایمن‌سازی این زنجیره، جلوگیری از ضدالگوهای نگهداری رمز و پیاده‌سازی اصول امنیت زیرو-تراست را آموزش می‌دهد.
پراکندگی اطلاعات محرمانه (Secret sprawl) را با والت‌های متمرکز (HashiCorp Vault، AWS Secrets Manager، Azure Key Vault) از بین ببرید. هرگز اطلاعات احراز هویت را در فایلهای کانفیگ، فایلهای env داخل VCS یا فایلهای اکسل ذخیره نکنید. به‌جای کلیدهای ایستا از نقشهای IAM و برای CI/CD از OIDC استفاده کنید. الگوی گیت‌وی هوش مصنوعی (AI gateway) راهکار استاندارد سال 2026 است: برنامه‌ها ← گیت‌وی ← ارائه‌دهنده‌ی مدل؛ به‌طوری‌که گیت‌وی اطلاعات محرمانه را در زمان اجرا (Runtime) از والت می‌خواند. کلید را در والت بازنشانی (Rotate) کنید تا همه‌ی برنامه‌ها ظرف چند دقیقه آن را تحویل بگیرند؛ بدون نیاز به دیپلوی مجدد و بدون پیام‌های «کی کلید جدید رو داره؟» در اسلک. دورهی بازنشانی باید کمتر یا مساوی 90 روز باشد؛ در هر commit با TruffleHog، GitGuardian یا Gitleaks اسکن کنید. امنیت زیرو-تراست (Zero-trust): الزام MFA، SSO، کنترل دسترسی RBAC/ABAC، توکنهای کوتاه‌عمر و ارزیابی وضعیت امنیتی دستگاه (Device posture). پاک‌سازی داده‌های هویتی حساس (PII scrubbing) با بازشناسی موجودیت‌های نام‌دار (NER) اطلاعات PHI/PII را پیش از ارسال ماسک میکند؛ توکنسازی پایدار (روش Mesh) مقادیر حساس را به متغیرهای جایگزین ثابت نگاشت میکند تا مدل زبانی پیوندهای معنایی و ساختار کد را حفظ کند. خروج ترافیک شبکه (Network egress): استقرار سرویس‌های LLM در ساب‌نت اختصاصی VPC/VNet و تعریف لیست سفید (Whitelist) فقط برای دامنه‌هایی مثل
api.openai.comوapi.anthropic.comو مسدود کردن هرگونه ترافیک خروجی دیگر. حادثه‌ی امنیتی سال 2026: حمله‌ی زنجیره‌ی تامین به Vercel از طریق لو رفتن مدارک احراز هویت CI/CD که متغیرهای محیطی هزاران استقرار مشتریان را فاش کرد.
اهداف یادگیری
- نام بردن چهار ضدالگوی مدیریت اطلاعات محرمانه (فایلهای کانفیگ در VCS، متغیرهای محیطی هاردکدشده، فایلهای اکسل و کلیدهای ایستا) و جایگزین‌های آن‌ها.
- توضیح الگوی «دریافت کلید از والت توسط گیت‌وی هوش مصنوعی» به‌عنوان استاندارد محیط عملیاتی (پروداکشن) در سال 2026.
- پیاده‌سازی پاک‌ساز PII با توکنسازی پایدار (مقدار یکسان ← جایگزین یکسان) برای حفظ ساختار معنایی.
- مرور حادثه‌ی زنجیره‌ی تامین Vercel در سال 2026 و درس‌های آن درباره‌ی بهداشت امنیتی اطلاعات محرمانه در CI/CD.
صورت مسئله
یک کارآموز فایلی حاوی کلیدهای API را در قالب .env کامیت (commit) میکند. سریع آن را پاک میکند، اما کلیدها وارد تاریخچهی git شده‌اند؛ اسکنر GitGuardian مچش را می‌گیرد و فرایند بازنشانی شما به این خلاصه می‌شود: «پیام به تیم در اسلک، به‌روزرسانی 40 فایل کانفیگ و دیپلوی دوباره‌ی تمام سرویس‌ها.» 8 ساعت بعد، نیمی از سرویس‌ها بالا آمده‌اند و نیم دیگر هنوز منتظر پنجره‌ی مجاز دیپلوی هستند.
از طرفی، پرامپت‌های کاربران شامل مواردی مثل «کد ملی من 123-45-6789 است» می‌شود. پرامپت مستقیم به OpenAI می‌رود. شما توافق‌نامه‌ی BAA دارید، اما سیاست داخلی‌تان می‌گوید اطلاعات هویتی حساس (PII) باید پیش از ارسال ماسک شوند؛ کاری که نکرده‌اید.
در سناریویی دیگر، پاد LLM روی کلاستر EKS به کل اینترنت دسترسی دارد. نفوذگری داده‌ها را از طریق یک DNS lookup به دامنه‌ی تحت کنترل خودش خارج میکند و هیچ مانعی سر راهش نیست.
امنیت سرویس‌های مبتنی بر مدل‌های زبانی باید به هر سه بردار حمله پاسخ دهد و بتواند درستی‌اش را اثبات کند: کلیدهای متکی به والت، پاک‌سازی PII، فیلتر ترافیک خروجی شبکه و لاگ‌های بازرسی (Audit logs) به‌عنوان ردپای شواهد.
مفاهیم پایه
والت متمرکز + دریافت کلید با نقش IAM
والت: HashiCorp Vault، AWS Secrets Manager، Azure Key Vault یا GCP Secret Manager. تنها یک منبع حقیقت (Source of Truth).
نقش IAM: برنامه یا گیت‌وی با هویت IAM خود احراز هویت میکند، نه با یک کلید ایستا. والت کلید محرمانه را صرفاً به‌اندازه‌ی طول عمر توکن برمی‌گرداند.
الگوی گیت‌وی هوش مصنوعی: گیت‌وی در زمان پردازش درخواست، OPENAI_API_KEY را از والت بیرون می‌کشد. با بازنشانی کلید در والت، درخواست بعدی کلید جدید را می‌گیرد؛ بدون نیاز به هیچ دیپلوی مجددی.
دورهی بازنشانی کمتر یا مساوی 90 روز
برای تمام کلیدهای API، توکنهای ریشه‌ی والت و مدارک CI/CD. هر جا ممکن است بازنشانی را خودکار کنید؛ بازنشانی‌های دستی را هم دقیق لاگ بیندازید و پیگیری کنید.
اسکن اطلاعات محرمانه
- TruffleHog — بررسی regex و آنتروپی روی commitها.
- GitGuardian — ابزار تجاری با دقت بالا.
- Gitleaks — ابزار متن‌باز با قابلیت اجرا در CI.
روی تک‌تک commitها اسکن کنید و اگر کلید جدیدی پیدا شد، جلوی ادغام PR را بگیرید.
موضع امنیت زیرو-تراست
- الزام MFA برای همه‌ی حساب‌ها.
- ورود یکپارچه (SSO) با SAML یا OIDC.
- اعمال RBAC (نقش‌محور) یا ABAC (صفت‌محور) برای دسترسی‌های دقیق و دانه‌ریز.
- توکنهای کوتاه‌عمر (در حد چند ساعت، نه چند روز).
- ارزیابی وضعیت امنیتی دستگاه — فقط دستگاه‌های سازمانی با دیسک رمزنگاری‌شده اجازه دارند متصل شوند.
پاک‌سازی داده‌های PII / PHI
پیش از آنکه پرامپت از زیرساخت شما خارج شود:
- بازشناسی موجودیت‌های نام‌دار (با NER در spaCy، Presidio مایکروسافت یا ابزارهای تجاری).
- ماسک کردن موجودیت‌های پیداشده:
"My SSN is 123-45-6789"←"My SSN is [SSN_TOKEN_A3F]". - توکنسازی پایدار (روش Mesh): نگاشت هر مقدار یکسان به یک متغیر جایگزین یکسان تا مدل زبانی پیوندهای معنایی را حفظ کند.
- نگاشت معکوس اختیاری برای برگرداندن داده‌ها در پاسخ نهایی مدل.
فیلترهای ساده‌ی regex الگوهای متداول را پیدا میکنند و NER موارد پیچیده‌تر را پوشش می‌دهد. از ترکیب هر دو استفاده کنید.
گاردریل‌های ورودی و خروجی
ورودی: مسدودسازی جیل‌بریک‌های (Jailbreak) شناخته‌شده و موضوعات ممنوعه؛ محدودسازی نرخ درخواست (Rate-limit) به ازای هر کاربر.
خروجی: پاک‌سازی خروجی با regex برای جلوگیری از نشت اطلاعات محرمانه (الگوهای کلید API، الگوهای ایمیل در متن‌های امتناع مدل یا Refusal) و استفاده از دسته‌بندها برای کشف نقض سیاست‌ها.
لیست سفید خروج داده از شبکه
استقرار سرویس‌های LLM در یک ساب‌نت اختصاصی:
- لیست سفید: دامنه‌های
api.openai.com،api.anthropic.com، اندپوینت‌های پایگاه دادهی برداری و اندپوینت‌های والت. - بقیه‌ی موارد: قطع کامل ترافیک (Drop).
- هدایت ترافیک DNS صرفاً از طریق یک ریزالور با لیست مجاز (برای جلوگیری از نشت داده از طریق تونل‌زنی DNS).
لاگ بازرسی
لاگی تغییرناپذیر از هر فراخوانی مدل زبانی شامل:
- برچسب زمانی (Timestamp).
- کاربر / مستاجر (Tenant).
- هش پرامپت (نه خود متن خام، برای حفظ حریم خصوصی).
- مدل و نسخه‌ی آن.
- تعداد توکن‌ها.
- هزینه.
- هش پاسخ.
- هرگونه فعال‌شدن گاردریل‌ها (سازوکارهای ایمنی).
مدت‌زمان نگهداری لاگ‌ها باید مطابق الزامات قانونی باشد (برای SOC 2 برابر 1 سال، برای HIPAA برابر 6 سال).
حادثه‌ی Vercel در سال 2026
یک حمله‌ی زنجیره‌ی تامین: مدارک احراز هویت افشاشده در CI/CD به سرقت متغیرهای محیطی در هزاران استقرار مشتریان انجامید. درس اصلی: مدارک CI/CD هم‌سطح محیط عملیاتی هستند. آن‌ها را در والت ذخیره کنید، دامنه‌ی دسترسی‌شان (Scope) را محدود نگه دارید و پیوسته بازنشانی‌شان کنید.
اعدادی که باید به خاطر بسپارید
- دورهی بازنشانی: کمتر یا مساوی 90 روز.
- اسکن در تک‌تک commitها: TruffleHog / GitGuardian / Gitleaks.
- حادثه‌ی Vercel 2026: لو رفتن دسترسی‌های CI/CD ← سرقت متغیرهای محیطی هزاران مشتری.
- مدت نگهداری لاگ بازرسی: در الزامات SOC 2 برابر 1 سال، در الزامات HIPAA برابر 6 سال.
استفاده از ابزارهای واقعی
فایل code/main.py یک پاک‌ساز ساده‌ی PII را همراه با توکنسازی پایدار و لاگ بازرسیِ فقط‌افزودنی (Append-only) پیاده‌سازی میکند.
خروجی این درس
این درس سند outputs/skill-llm-security-plan.md را تولید میکند؛ سندی که با توجه به دامنه‌ی رگولاتوری و وضعیت فعلی سیستم، برنامه‌ی مهاجرت به والت، پاک‌ساز، خروجی شبکه و لاگ بازرسی را تدوین میکند.
تمرین‌ها
- اسکریپت
code/main.pyرا اجرا کنید. دو پرامپت حاوی یک شماره ملی یکسان بفرستید. بررسی کنید که هر دو متن، جایگزین یکسانی گرفته باشند. - سیاست خروج داده از شبکه (Egress policy) را برای استقرار vLLM روی EKS که قرار است OpenAI و Anthropic و Weaviate را صدا بزند، طراحی کنید.
- کلیدی را در تاریخچهی دو سال پیش git پیدا می‌کنید. اقدام درست چیست: بازنشانی کلید، پاک کردن تاریخچه، یا هر دو؟ دلیل خود را توضیح دهید.
- لاگ بازرسی شما روزانه 10 گیگابایت رشد میکند. لایه‌های نگهداری آن را طراحی کنید (داغ 30 روز، نیمه‌داغ 12 ماه، سرد 6 سال).
- استدلال کنید که آیا پیچیدگی «توکنسازی معکوس» (جایگزین کردن دوباره‌ی مقادیر واقعی در پاسخ مدل) ارزشش را دارد، یا بهتر است همان متغیرهای جایگزین در دید بمانند؟
اصطلاحات کلیدی
| اصطلاح | در گفت‌وگوهای عامیانه | معنای دقیق فنی |
|---|---|---|
| والت (Vault) | «انبار کلیدها» | سرویس متمرکز مدیریت اطلاعات احراز هویت |
| نقش IAM (IAM role) | «احراز هویت مبتنی بر هویت» | نقشی که برنامه می‌گیرد و در ازایش اعتبارات کوتاه‌عمر تحویل می‌گیرد |
| OIDC برای CI/CD | «توکنهای ابری» | حذف کلیدهای ایستا از CI و تشخیص هویت از طریق OIDC |
| TruffleHog / GitGuardian / Gitleaks | «اسکنرهای اطلاعات محرمانه» | ابزارهای تشخیص نشت کلید در زمان commit |
| RBAC / ABAC | «کنترل دسترسی» | نقش‌محور در برابر صفت‌محور |
| پاک‌سازی PII (PII scrubbing) | «ماسک کردن داده‌ها» | حذف یا توکنسازی موجودیت‌های حساس |
| توکنسازی پایدار (Consistent tokenization) | «جایگزین‌های ثابت» | نگاشت مقدار یکسان به توکنی یکسان در هر بار |
| روش Mesh (Mesh approach) | «توکنسازی مش» | الگوی توکنسازی با هدف حفظ پیوندهای معنایی |
| لیست سفید خروج داده (Egress whitelist) | «فهرست دسترسی‌های خروجی» | دسترسی‌پذیری انحصاری دامنه‌های مجاز |
| لاگ بازرسی (Audit log) | «تاریخچهی تغییرناپذیر» | ثبت سوابق به‌صورت فقط‌افزودنی جهت رعایت انطباق قانونی |