تحویل دسترسی آزمون امنیتی: دامنه، حساب‌ها و لغو
آزمونگری که اعتبارنامهٔ VPN می‌خواهد به تحویلی با دامنهٔ مشخص نیاز دارد، نه یک ورود یدکی. مجوز را از دروازه بگذرانید، هدف‌ها را نام ببرید، حساب‌ها را صادر کنید و سپس لغو کنید.
آزمونگر آدرس دروازه، جزئیات DNS داخلی و اعتبارنامهٔ VPN می‌خواهد و درخواست با موضوع «دسترسی لازم است» برای شما ارسال می‌شود. خود درخواست به شما نمی‌گوید که این یک ارزیابی داخلی است، آزمون یک برنامهٔ دارای احراز هویت، یا کاری روی یک وب‌سایت عمومی که کسی دامنه را اشتباه فهمیده است. تحویل را به‌صورت زنجیره‌ای با یک دروازه در هر مرحله اجرا کنید و در نخستین دروازه‌ای که باز نمی‌شود بایستید. این کار درخواستی مبهم را به چیزی تبدیل می‌کند که می‌توانید مجاز کنید، تحویل دهید و بعداً لغو کنید.
با مجوز شروع کنید، نه با اعتبارنامه‌ها
پیش از آنکه هیچ نشانی از صندوق ورودی شما خارج شود، مشخص کنید هدف‌ها متعلق به چه کسی است و چه کسی اجازهٔ تأیید آزمون روی آن‌ها را دارد. آزمونگر را از طریق مخاطب قرارداد که سازمان شما از قبل استفاده می‌کند بررسی کنید، نه از طریق کسی که ایمیل را ارسال کرده است. رابطهٔ مشتری اجازهٔ آزمون همهٔ سامانه‌هایی که از یک حساب در دسترس‌اند نیست و سفارش خرید سند دامنه نیست.
هدف تأییدشده را در یک جمله بنویسید و آن را کنار تحویل نگه دارید. «احراز هویت پرتال مشتری را ارزیابی کنید» و «شبکهٔ داخلی را ارزیابی کنید» به بسته‌های کاملاً متفاوتی می‌رسند و تفاوت باید پیش از تأمین روشن شود، نه پس از رسیدن یک یافته. این جمله چیزی هم به شما می‌دهد که وقتی درخواست در میانهٔ کار بزرگ می‌شود به آن اشاره کنید.
اگر ارائه‌دهندهٔ میزبانی یا طرف سوم دیگری در مسیر است، الزامات آن‌ها بر راحتی شما مقدم است. آزمون زیرساخت شخص دیگر بدون اجازهٔ او مسئله‌ای جدا از آزمون برنامه‌ای است که روی آن اجرا می‌شود.
دیدگاه و هدف‌ها را نام ببرید
دیدگاه پرسشی است که ارزیابی می‌کوشد به آن پاسخ دهد و بستهٔ دسترسی را بیش از هر ابزاری که آزمونگر قصد استفاده از آن را دارد تعیین می‌کند. آزمون عمومی بدون احراز هویت به یک URL و یک بازهٔ زمانی نیاز دارد. آزمون دارای احراز هویت به حساب‌های اختصاصی برای نقش‌های مشخص در دامنه نیاز دارد و ارزیابی داخلی به یک نقطهٔ ورود تعریف‌شده با بازه‌های هدف صریح نیاز دارد.
| Viewpoint | What you hand over | What it does not authorize |
|---|---|---|
| Public website | Approved URL, TLS hostname, testing window | Internal network entry, adjacent hosts |
| Authenticated app | URL plus per-role test accounts | Other tenants, admin consoles outside scope |
| Private staging | Named private path and test accounts | Production systems behind the same gateway |
| Internal network | Entry point and written target ranges | Anything outside those ranges, including the gateway itself |
اینکه تونل از کجا وارد می‌شود همان واقعیتِ این نیست که کدام برنامه پشت آن است و قطعاً اجازهٔ کاوش در نقطهٔ ورود را نمی‌دهد. این را صریح در تحویل بگویید، چون جملهٔ «تو به من دسترسی به آن زیرشبکه دادی» به‌سرعت می‌رسد وقتی یافته‌ای مورد مناقشه باشد. فهرست مکتوب هدف‌ها تنها چیزی است که بعداً آن را حل می‌کند.
نام میزبان TLS را همراه URL بدهید. نشانی IP خالی آزمونگر را مجبور به حدس زدن نام می‌کند و نام حدس‌زده‌شده خطاهای گواهی تولید می‌کند که به‌جای خطای تحویل، به‌عنوان یافته گزارش می‌شوند.
هویت‌های اختصاصی با تاریخ انقضا صادر کنید
حساب‌هایی تأمین کنید که فقط برای این کار وجود دارند؛ ورود روزمرهٔ یک کارمند را قرض ندهید. دسترس‌پذیری شبکه و مجوزهای برنامه را بر اساس وظایف توافق‌شده تنظیم کنید، ثبت احراز هویت را از مسیری پشتیبانی‌شده ترتیب دهید و تاریخ انقضا را همراه با شخصی نام‌برده که مسئول لغو است پیوست کنید. اعتبارنامه‌ها را از کانال امن توافق‌شده و جدا از سند دامنه که دست‌به‌دست می‌شود تحویل دهید.
sudo useradd -m -e 2026-12-31 tester01 sudo passwd -S tester01 id tester01 lastlog -u tester01
ثبت کنید چه کسی چه چیزی و چه زمانی دریافت کرد. این سابقه تفاوت میان تحویلی کنترل‌شده و گذرواژهٔ مشترکی است که هیچ‌کس نمی‌تواند ردیابی کند و نخستین چیزی است که پس از یک حادثه پرسیده می‌شود. آن را کنار سند دامنه نگه دارید نه در رشتهٔ گفتگو، و کانال تحویل را کنار گیرنده بنویسید. یک خط با برچسب زمانی هر بار از یادآوری ذهنی بهتر است.
فیلد انقضا تور ایمنی است، نه برنامه. کسی باید در پایان مسیر شبکه و نقش برنامه را هم بردارد، چون ورود منقضی روی شبکه‌ای که هنوز در دسترس است دسترسی لغوشده نیست.
پیش از باز شدن بازه اثبات کنید که تحویل کار می‌کند
نخستین پرش آزمونگر را خودتان و از نزدیک‌ترین موقعیت ممکن به او اجرا کنید. نام را تفکیک کنید، هویت گواهی را بررسی کنید و تأیید کنید که مسیر به نشانی مقصود می‌رسد نه به نشانی همسایه.
dig +short app.example.com openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null> 2>/dev/null | openssl x509 -noout -subject -dates ip route get 10.60.0.25
اگر مسیر به هدفی نمی‌رسد، بایستید و تحویل را هم‌تراز کنید، نه اینکه بگذارید آزمونگر مسیر جایگزینی کشف کند. دسترس‌پذیری بداهه همان راهی است که یک ارزیابی بی‌صدا از دامنه‌اش فراتر می‌رود و تقریباً هرگز بعداً مستند نمی‌شود.
مخاطب عملیاتی، ساعت‌های مجاز، اقدام‌های مستثنا و شرایط توقف را همراه اعتبارنامه‌ها بفرستید. آزمونگری که در 02:00 به هیچ‌کس دسترسی ندارد تصمیمی می‌گیرد که شما مجاز نکرده‌اید و آن تصمیم در گزارش طوری توصیف می‌شود که گویی در دامنه بوده است.
NIST SP 800-115 ارزیابی فنی را آزمون برنامه‌ریزی‌شده و سپس تحلیل و کاهش تعریف می‌کند، و این تحویل همان قالب را دنبال می‌کند. دروازه‌های بالا انتخاب‌های طراحی تحریریه برای یک مهندس پشتیبانی است، نه فهرست بازبینی نقل‌شده از آن انتشار.
کار را با برداشتن دسترسی ببندید
لغو را به ترتیب معکوس تأمین انجام دهید: نقش‌های برنامه، سپس دسترسی شبکه و سپس خود هویت. هر مرحله را تأیید کنید نه اینکه فرض کنید کنسول همان کاری را کرد که دکمه وعده داده بود. حساب را پیش از کشتن نشست‌هایش قفل کنید، وگرنه نشست به‌سادگی از مسیر قدیمی دوباره احراز هویت می‌شود. سپس اتصال‌های برقرارشده را یک بار دیگر بررسی کنید پیش از آنکه آن را بسته اعلام کنید.
sudo passwd -l tester01 sudo pkill -u tester01 ss -tn state established '( sport = :443 )'
هر دادهٔ آزمون نگه‌داشته‌شده را تسویه کنید و سپس رفع نقص را از طریق فرایند گزارش‌دهی که در آغاز توافق کردید پیگیری کنید. گزارش باید محیط، سطح دسترسی، دامنه و محدودیت‌ها را ذکر کند، چون یافته‌های یک ارزیابی را ثبت می‌کند و بیانیهٔ دائمی دربارهٔ امن بودن سایت نیست.
سابقهٔ لغو را همراه سابقهٔ تحویل نگه دارید. وقتی کار بعدی آغاز می‌شود، می‌خواهید بدانید دفعهٔ قبل دقیقاً چه چیزی برداشته شد و چه کسی آن را تأیید کرد، نه اینکه تصویر را از حافظه بازسازی کنید.