چگونه تأییدهای دسترسی VPN را بدون تاریخچه مرور ثبت کنیم
هویت، تأییدکننده و تاریخ انقضا را نگه دارید و فهرست مقاصد را کنار بگذارید. سه شرط تعیین میکند چه مقدار از تصمیم دسترسی را واقعاً باید در پرونده داشته باشید.
دو تیم یک سند را میخواهند و منظورشان از آن متفاوت است. بازبین میخواهد ثابت شود که شخصی مشخص تا تاریخی یک نقش را تأیید کرده است، در حالی که تیم شبکه یک گزارش دیوار آتش پر از مقاصد دارد و گمان میکند که کافی است. کافی نیست، و همین باعث میشود پوشههای تأیید پر از نام میزبان شوند و باز هم در نخستین پرسش حسابرسی شکست بخورند. آنچه واقعاً لازم دارید کم است و هیچکدام از آنها ثبت این را که کسی کجا مرور کرده است نمیطلبد.
حجم پرونده از سه شرط پیروی میکند: اینکه تأیید بهازای هر شخص داده میشود یا هر نقش، اینکه آیا حق دسترسی میتواند از رابطه کاری آن شخص بیشتر بماند، و اینکه آیا قرارداد یا چارچوبی بازبینی دسترسی را بهعنوان شاهد الزامی نام میبرد.
از پرسش بازبین شروع کنید، نه از اتصال
پرسشی را بنویسید که حسابرس آن را بلند میپرسد، پیش از آنکه حتی یک فیلد انتخاب کنید. چه کسی دسترسی این هویت را تأیید کرد، به چه چیزی، میان کدام تاریخها، و چه کسی باید آن را در پایان برمیداشت. هر فیلد فرم باید بخشی از این جمله را پاسخ دهد، و هر چیزی که چنین نمیکند موجودیای است که همین حالا تعهد محافظت از آن را پذیرفتهاید.
این آزمون بیشتر آنچه را که از روی عادت افزوده میشود حذف میکند. فهرست مقاصد، پرسشهای DNS، نمودارهای استفاده از برنامه و تصاویر یک نشست زنده همه رفتار را توصیف میکنند. رفتار همان تأیید نیست، و گردآوری آن پرونده را به طبقه حساسیت بسیار بالاتری منتقل میکند که خلاف هدفی است که با آن شروع کردید.
سه شرط تعیین میکند چه مقدار نگه دارید
تأییدهای شخصمحور به هویت و تاریخ پایان نیاز دارند. تأییدهای نقشمحور به نقش، دامنهای که میدهد و مالک جمعیت نیاز دارند، زیرا فهرست کردن چهل نفر در یک ردیف چهل پرونده برای نگهداری و چهل فرصت برای از دست دادن یک ترک خدمت ایجاد میکند. جایی که حق دسترسی میتواند از رابطه کاری بیشتر بماند، مالک حذف و آهنگ بازبینی بیفزایید، چون تاریخ انقضا در یک صفحهگسترده بهندرت کسی را به اقدام وامیدارد.
| Condition | Add to the record | Leave out |
|---|---|---|
| Approved per person | Identity, approver, expiry | Device telemetry |
| Approved per role | Role, scope, population owner | Per-user destinations |
| Outlives employment | Removal owner, review date | Session transcripts |
| Named in a contract | The cited artifact and its revision | A second, friendlier copy |
وقتی چارچوبی بازبینی دسترسی را شاهد الزامی مینامد، همان سندی را نگه دارید که فرایند بازبینی از پیش به آن استناد میکند. ساختن نسخهای موازی برای تیم VPN همان راهی است که دو نسخه از یک تأیید درباره تاریخ پایان با هم اختلاف پیدا میکنند.
فیلدهایی که تصمیم را حمل میکنند
مجموعه کارآمد کوتاه است: هویت تأییدشده، درخواستکننده، تأییدکننده، دامنه نقش یا منبع، دلیل در یک خط، بازه اعتبار، مالک بازبینی یا حذف، و اشارهای به تیکتی که درخواست در آن بحث شده است. به دستگاه یا اعتبارنامه با شناسهای غیرمحرمانه مانند برچسب دارایی یا موضوع گواهی ارجاع دهید، هرگز با کلید خصوصی یا گذرواژهای که استفاده شده است.
نتیجه را حتی بدون مقاصد، داده شخصی بدانید. پروندهای که میگوید این کارمند نامبرده شش ماه دسترسی مدیریتی به بخش مالی داشته است، بهخودیخود حساس است، پس مشخص کنید چه کسی میتواند پوشه را بخواند و برای هدف اداری مدت نگهداری تعیین کنید، نه اینکه پرونده را ناشناس بنامید.
داده مرور از کجا به پرونده تأیید نشت میکند
سه نشت بیشتر آن را توضیح میدهد. تیکت میز پشتیبانی تصویری از پنجره اتصال کارخواه دارد، کسی برای زمینه یک خروجی SIEM میچسباند، یا گزارش موجودی به تأیید پیوند میخورد چون آن زمان پیوند دادن آسان بود. هر پیوست رفتاری به پروندهای میافزاید که تنها به یک تصمیم نیاز داشت. وقتی تصویر وارد شد، بازبین میپرسد کاربر به چه چیزی میرسید، و پرونده باید دوباره طبقهبندی شود.
هر جا ابزار اجازه میدهد پیوستها را با اشاره جایگزین کنید. اگر سیاست بر پیوست پافشاری میکند، متن تصمیم و رشته درخواست را بخواهید، نه ضبط نشست را، و پیش از ذخیره پرونده بقیه را حذف کنید. پیام خود تأییدکننده معمولاً بهترین شاهد و کمترین افشاکننده است.
دامنه را بدون رد پا بررسی کنید
سیاست دروازه همان چیزی است که تأیید را به دسترسی تبدیل میکند، پس مستقیم آن را بیازمایید. با حسابی درون دامنه تأییدشده وارد شوید و به منبعی مجاز برسید، سپس مقصدی بیرون از دامنه را امتحان کنید و رد شدن را تأیید کنید، با همان کارخواه و روشی که سیاست انتظار دارد، نه با زبانه مرورگر روی همان میزبان.
پایش دسترسپذیری و تشخیص رخداد میتوانند دیدبانی خود را زیر مدت نگهداری و فهرست دسترسی خودشان نگه دارند. جدا نگه داشتن این دو هدف همان چیزی است که به شما اجازه میدهد بدون تحویل رد پای مرور به بازبین پاسخ دهید و تشخیص را وقتی چیزی واقعاً خراب میشود سودمند نگه میدارد.
پیش از بازبینی بعدی چه چیزی را بررسی کنید
تأیید کنید که فرم به جمله حسابرس پاسخ میدهد و نه بیشتر. بررسی کنید هر ردیف تأییدکننده، بازه و مالک حذف داشته باشد. سپس فهرست دسترسی خود پوشه را ببینید و بپرسید آیا از پایگاه کاربران VPN کوچکتر است.
آخرین گام همان است که مردم از آن میگذرند. یک تأیید منقضی بردارید و آن را تا ارائهدهنده هویت دنبال کنید تا ببینید حساب واقعاً غیرفعال شده است یا نه. اگر هویت هنوز فعال است، پرونده درست بوده و فرایند نه.