اگر امروز یک محصول را بهتنهایی عرضه میکنید، احتمالاً در مواجهه با درخواست گزارش SOC 2 از سوی مشتریان سازمانی به دیوار برخورد کردهاید. تصور کنید بدون داشتن یک تیم امنیتی کامل، بتوانید سختگیرانهترین استانداردهای سازمانی را پاس کنید؛ این دقیقاً همان چیزی است که یک حسابرس سابق Deloitte ممکن ساخته است. در تاریخ ۴ اوت ۲۰۲۶، این متخصص نقشهای جامع را به اشتراک گذاشت تا نشان دهد چگونه افراد میتوانند کنترلهای پیچیده سازمانی را بدون نیاز به یک تیم امنیتی کامل برآورده کنند.
به نقل از راهنمایی که در وبسایت dev.to منتشر شد، کلید موفقیت در ترجمه زبان «شرکتهای بزرگ» به واقعیت «شرکتهای تکنفره» است. نویسنده این مطلب با تکیه بر پنج سال تجربه در شرکت Deloitte و بازرسی SOC 2 برای بیش از ۳۰ شرکت فناوری در سراسر آمریکا و کانادا، از جمله نامهای بزرگی چون LinkedIn، Affirm و Ripple، استراتژیهای عملیاتی برای این گذار را ترسیم کرده است.
زیرساختهای مدرن، فضای انطباق با استانداردها را بهطور بنیادی تغییر دادهاند. در گذشته، داشتن تنها یک نفر در تیم به این معنا بود که شما بهندرت در میز مذاکره برای قراردادهای بزرگ سازمانی حضور مییافتید. اما امروز، عاملهای هوش مصنوعی (AI Agents) — مثل دستیارهای دیجیتالی که میتوانند کارهایی را بهصورت مستقل انجام دهند و تصمیم بگیرند — بخش بزرگی از توسعه و عملیات را مدیریت کرده و سرعت پیشروی را به سطح تیمهای ۲۰ نفره رساندهاند. این تحول باعث ایجاد شکافی شده است که در آن کنترلهای سنتی بازرسی — که پیشفرض آنها وجود چندین بازبین انسانی است — دیگر کاربردی ندارند. این تغییر در حالی رخ میدهد که آمارها نشان میدهد بنیانگذاران تکنفره ۳۶.۳٪ از استارتاپهای جدید در نیمه اول سال ۲۰۲۵ را تشکیل دادهاند، در حالی که این رقم در سال ۲۰۱۹ تنها ۲۳.۷٪ بود. در یک بستر گستردهتر، حدود ۸۲٪ از کسبوکارهای ایالات متحده هیچ کارمندی ندارند.
بازتعریف مدیریت تغییر
همانطور که در تحلیلهای قبلی ما درباره امنیت مدلهای بازمتن اشاره کردیم، اتکای زیاد به اتوماسیون بدون نظارت، ریسکهای جدیدی ایجاد میکند. در اینجا بحث بر سر بازتعریف «مدیریت تغییر» است. راهنماییهای سنتی ایجاب میکنند که هر تغییر در کد توسط مهندس دوم بررسی شود. بنیانگذار تکنفره چنین کسی را ندارد؛ اما وقتی یک عامل هوش مصنوعی تغییری ایجاد میکند و بنیانگذار آن را تایید میکند، یک «سند بررسی» ایجاد میشود. اگرچه این روش تفکیک کامل وظایف (Separation of Duties) نیست — چون عامل تحت اعتبار بنیانگذار عمل میکند و بازرس شما و عامل را به عنوان یک واحد یا «اصالت» واحد میبیند — اما بهعنوان یک «کنترل جبرانی» (Compensating Control) پذیرفته میشود. این روش یک بررسی واقعی را فراهم میکند که ردی از خود بهجا میگذارد، که این حتی از وضعیتی که یک توسعهدهنده تکنفره کدهای دستنویس خود را مستقیماً ادغام (Merge) میکرد، بسیار بهتر است.
برای متقاعد کردن بازرس، شما باید اطمینان حاصل کنید که مسیر حرکت کد از مرحله ثبت (Commit) تا محیط تولید (Production) محدود و ثبتشده باشد. بازرس بهطور خاص روی تنظیمات حفاظت از شاخه (Branch Protection) شما تمرکز خواهد کرد. این موارد شامل است:
- فعالسازی حفاظت از شاخه (Branch Protection) در شاخه پیشفرض (Default Branch).
- تعریف بررسیهای وضعیت (Status Checks) که باید پیش از ادغام حتماً سبز شوند.
- اجرای آزمونهای خودکار (Automated Tests) که بهصورت مستقل اجرا شوند.
- نگهداری تاریخچه استقرار (Deploy History) که توسط سیستم تولید شده باشد و نه بهصورت دستی تایپ شده باشد.
یک بررسی حیاتی برای بنیانگذاران این است که تعیین کنند آیا عامل آنها دسترسی Push به مخزن کد (Repo) دارد و آیا میتواند به شاخه پیشفرض دسترسی پیدا کند یا خیر. این محدودیت فنی برای بازرسها بسیار مهمتر از این است که بنیانگذار لزوماً خروجی مدل را خوانده است یا نه.
مدیریت شعاع تخریب
به دلیل سرعت بالای عاملهای هوش مصنوعی در اجرای تغییرات، ریسک یک دستور اشتباه بسیار بیشتر از تایپ دستی انسان است. «شعاع تخریب» (Blast Radius) یک دستور غلط در اینجا گستردهتر از زمانی است که یک انسان تکتک دستورات را تایپ میکرد. برای جبران فقدان نظارت انسانی، شما به سیستمهای تشخیص خودکار نیاز دارید که بدون دخالت شما فعال شده و هشدار دهند.
کنترلهای جبرانی برای تفکیک وظایف
از آنجایی که شما نمیتوانید نقش «مالک» و «اپراتور» را تفکیک کنید، سوال این است که چه چیزی یک تغییر بد را پس از وقوع شکار میکند. معیار اصلی در اینجا «کاهش ریسک» است، نه «شمارش سرها». بررسی یک حساب توسط یک نفر، اگر بهصورت کتبی ثبت و تاریخدار شود، یک بررسی معتبر است. بنیانگذاران باید این موارد را پیاده کنند:
- ارسال اعلانهای استقرار (Deploy Notifications) در مکانی که تاریخچه را حفظ میکند.
- فعالسازی و نگهداری لاگهای بازرسی ابری (Cloud Audit Logs) بهصورت فعال.
- هشدارهای لحظهای برای اتفاقات پرریسک: مانند ایجاد یک کاربر IAM جدید، باز شدن یک گروه امنیتی (Security Group) برای کل دنیا، یا دسترسی به پایگاه داده تولید خارج از پنجرههای استقرار استاندارد.
- انجام بازرسیهای دورهای توسط خود شخص (Self-review) که طبق برنامه زمانی انجام و بهصورت کتبی مستند شود.
شکاف بازرسی دسترسی
اکثر سیستمهای تکنفره، هویتهای غیرانسانی بیشتری نسبت به انسان دارند. عاملها، سرورهای MCP (Model Context Protocol) و خطوط CI/CD همگی دارای توکن و کلید هستند و هر یک یک «اصالت» (Principal) با دسترسی دائمی به سیستمهای شما محسوب میشوند. چون این هویتها در حین توسعه و عرضه محصول یکی-یکی اضافه میشوند، بهندرت بازرسی میشوند.
مستندسازی هویتهای غیرانسانی
کنترل در اینجا عبارت است از یک بازرسی کتبی، که توسط بنیانگذار طبق یک برنامه زمانی انجام میشود، نام تمام هویتهای موجود را ذکر میکند و تایید میکند که آنها باید وجود داشته باشند. شاید یادداشت نوشتن برای خودتان مضحک به نظر برسد، اما ۱۵ دقیقه در هر فصل، مرز بین یک کنترل صوری و کنترلی است که به آن باور دارید. این بازرسی باید صراحتاً موارد زیر را فهرست کند:
- تمام حسابهای دارای دسترسی به محیط Production.
- تمام توکنهای удержи شده توسط عاملها و ابزارهای CI و منابع خاصی که هر یک میتوانند به آنها دسترسی داشته باشند.
- تمام ابزارهای SaaS که با دادههای مشتری در تماس هستند.
- یک تاییدیه مبنی بر اینکه هر یک از اینها هنوز به دسترسی فعلی خود نیاز دارند.
این مستندات، شواهدی را فراهم میکند که ثابت کند سیستمهای SSO با MFA و کلیدهای سختافزاری یا مدیریتکنندههای رمز عبور واقعاً در حال کار هستند.
انطباق تامینکنندگان و منابع انسانی
بسیاری از بنیانگذاران، ارائهدهندگان مدل (Model Providers) را بهعنوان «تأمینکننده» (Vendor) فراموش میکنند. اگر دادههای مشتری به یک ارائهدهنده مدل زبانی بزرگ (LLM) میرسد، آن ارائهدهنده در محدوده (Scope) بازرسی قرار میگیرد. شما باید گزارشهای SOC 2 آنها را دقیقاً همانطور که برای AWS یا Google Cloud جمع میکنید، دریافت کنید؛ بازرسان به اینها «سازمانهای خدمات فرعی» (Subservice Organizations) میگویند. شما AWS را بازرسی نمیکنید، بلکه گزارش آنها را جمعآوری کرده و ذکر میکنید که کدام بخشهای امنیتی شما به آنها وابسته است.
در مورد بررسی پیشینه (Background Check)، اگر جمعیت کارکنان صفر باشد، این مورد بهعنوان «جمعیت خالی» ثبت میشود و نه شکست در کنترل. یک عامل، کارمند نیست و بررسی پیشینه نمیشود، بلکه تحت «کنترل دسترسی» مدیریت میگردد. مستندسازی این موضوع تنها چند دقیقه زمان میبرد. پیچیدگی تنها زمانی شروع میشود که اولین پیمانکار استخدام شود، که در این صورت موارد زیر لازم است:
- یک قرارداد امضا شده.
- مراحل مستند برای اعطای دسترسی.
- مراحل مستند برای حذف دسترسی پس از پایان کار.
اولویت شواهد بر اسکرینشاتها
رایجترین نقطه شکست در بازرسیها، خودِ کنترل نیست، بلکه «شواهد» (Evidence) است. اسکرینشاتها snapshotهای لحظهای هستند که بازرسان اغلب آنها را ناکافی میدانند. اسکرینشاتی که سه هفته پیش گرفته شده، تصویری از لحظهای است که گذشته و تمام شده است. هدف باید انتقال از اسکرینشات به «خروجیهای سیستمی» (System Exports) باشد که وضعیت واقعی کنترل را نمایندگی میکنند.
عاملهای هوش مصنوعی برای این کار بهطور منحصر بهفردی مناسب هستند. چون آنها پیشاپیش به فضای ابری، ارائهدهنده هویت و مخزن کد دسترسی دارند، میتوانند وضعیت فعلی سیستم را استخراج کنند. این کار جایگزین کارهایی است که پیشتر یک ماه از زمان مهندسی را میبلعید. با این حال، بنیانگذار باید مطمئن شود عامل میداند چه چیزی «مدرک» محسوب میشود. عاملی که رها شود، ممکن است سیاستی را ارائه دهد که هیچکس رعایت نمیکند، یا تنظیماتی که کنترل را ثابت نمیکند، یا لاگی که بازه زمانی اشتباهی را پوشش میدهد.
پیادهسازی استراتژیک و استانداردها
توصیه میشود بنیانگذاران با بازرسی Type I شروع کنند، که تست میکند آیا کنترلها در یک نقطه زمانی خاص بهدرستی طراحی شدهاند یا خیر. این روش سریعتر است، پنجره مشاهده (Observation Window) ندارد و اغلب توسط خریداران سازمانی پذیرفته میشود، در حالی که برای بازرسی Type II — که اثربخشی عملیاتی را در بازه ۳ تا ۱۲ ماه میسنجد — آماده میشوید.
از نظر رگولاتوری، معیارهای خدمات مورد اعتماد (TSC) در سطح هر معیار ارزیابی میشوند. «نقاط تمرکز» (Points of Focus) صرفاً راهنمای توصیفی هستند، نه الزامات سخت و تغییرناپذیر. راهنمای AICPA به سازمانهای کوچکتر و با پیچیدگی کمتر اجازه میدهد تا معیارهای انطباق را از طریق نظارت فعال مالک بهجای ساختارهای رسمی شرکتی پاس کنند. با این حال، طبق استاندارد AT-C 205، «پرسوجو» (Inquiry) بهتنهایی هرگز کافی نیست و بازرس حتماً باید مستندات را مشاهده، بازرسی یا بازتولید کند.
برنامه عملیاتی برای این هفته
برای ایجاد یک محدوده «فقط امنیتی» (Security-only scope) — که تنها دسته اجباری است — بنیانگذاران باید موارد زیر را پیاده کنند:
- فعالسازی Branch Protection در شاخه پیشفرض، همراه با بررسیهای الزامی و غیرفعال کردن Force-push.
- تهیه فهرستی جامع از تمام توکنهای удержи شده توسط عاملها، سرورهای MCP و ابزارهای CI، شامل محدوده دسترسی آنها.
- فعالسازی MFA در تمام حسابها و استفاده از SSO در هر کجا که در دسترس باشد.
- فعالسازی لاگهای بازرسی ابری و نگهداری آنها فراتر از بازه زمانی مورد نیاز بازرسی.
- ارسال اعلانهای استقرار به سیستمی که تاریخچه را حفظ میکند.
- انجام یک بازرسی دسترسی تاریخدار که هم انسانها و هم هویتهای غیرانسانی را پوشش دهد.
- جمعآوری گزارشهای SOC 2 بهروز از تمام تامینکنندگان حیاتی، از جمله ارائهدهنده مدل AI.
این گذار نشاندهنده حرکت به سمت امنیتی «مدرک-محور» است که در آن عامل نه فقط کارگر، بلکه دستیار اصلی بازرس است. با اتوماتیک کردن جمعآوری دادههای وضعیت فعلی، بار مهندسی بهشدت کاهش مییابد. اما مدیریت این هویتهای غیرانسانی در مقیاس بزرگتر، چالشهای پیچیدهتری دارد که در تحلیلهای آینده بررسی خواهیم کرد.
گفتگو