RDP مشتری را عوض می‌کند: چرا پایگاه داده میزبان دیگری می‌بیند

قانون VPN شما پایگاه داده را رد می‌کند و تیکت به عنوان خرابی فایروال بسته می‌شود، در حالی که همان کاربر یک دسکتاپ منتشرشده باز می‌کند و بدون مشکل از آن پایگاه داده پرس‌وجو می‌کند. هر دو گزاره درست‌اند. دسکتاپ مشتری دیگری است، با نشانی خودش روی بخشی که قواعد از قبل به آن اعتماد دارند و با هویت خودش وقتی به جلو وصل می‌شود. آنچه شبیه قاعده‌ای متناقض به نظر می‌رسد معمولاً درخواست دومی است که کسی آن را در بازبینی نگذاشته است.

درخواست دوم نشانی مشتری خودش را دارد

وقتی برنامه‌ای داخل نشست اتصالی به پایگاه داده باز می‌کند، دست‌دادن TCP در میزبان نشست آغاز می‌شود. نشانی مبدأ آن به شبکه همان میزبان تعلق دارد، پس هر مسیریاب و فایروال پایگاه داده در مسیر، بخش دسکتاپ را ارزیابی می‌کند نه مخزن تونلی را که لپ‌تاپ شما از آن آمده است. نشانی VPN هرگز در آن جریان دیده نمی‌شود. به همین دلیل قاعده رد مبتنی بر مبدأ می‌تواند هم‌زمان درست و بی‌ربط باشد.

مبدأ را از داخل نشست بخوانید نه از لپ‌تاپ، سپس مسیر بعدی را از همان جا بیازمایید. دو پاسخ باید درباره اینکه کدام میزبان درخواست را می‌فرستد هم‌نظر باشند.

whoami
ipconfig /all
Test-NetConnection db01.corp.internal -Port 5432

آنچه نشست گزارش می‌کند را با نشانی‌ای که پایگاه داده برای همان زمان ثبت کرده مقایسه کنید. وقتی گزارش کارساز به جای مخزن تونل، زیرشبکه دسکتاپ را نشان می‌دهد، پرسش از اینکه آیا قاعده اعمال شد خارج می‌شود و به این تبدیل می‌شود که کدام میزبان درخواست را فرستاده است. این تحقیقی دیگر با صاحب دیگری است.

هویت هم همراه با نشانی‌دهی تغییر می‌کند

اتصال بعدی معمولاً با توکن نشست، یک اعتبارنامه ذخیره‌شده یا حساب سرویس برنامه احراز هویت می‌شود و منبع هر کدام را که گرفته ثبت می‌کند. بنابراین ردپای حسابرسی که حساب سرویس را روی پایگاه داده نشان می‌دهد ثابت نمی‌کند انسانی پرس‌وجو را اجرا کرده است. آن انسان را هم مشخص نمی‌کند. فقط گزارش نشست خود دسکتاپ آن دو رکورد را به هم می‌پیوندد.

مجوزدهی دو بار رخ می‌دهد و تصمیم دوم با ورودی‌های متفاوت گرفته می‌شود. اولی به کاربری مشخص امکان ورود به دسکتاپ می‌دهد و دومی هر کاری را که توکن آن کاربر یا حساب برنامه می‌تواند با منبع بکند. گروهی از میز خدمت که اجازه باز کردن دسکتاپ دارد به‌طور خودکار گروهی نیست که اجازه خواندن جدول مشتریان را دارد.

پیش از نوشتن یادداشت دسترسی به توکن و مسیر واگذاری نگاه کنید. هر دو از داخل نشست دیده می‌شوند و آن تنها جایی است که پاسخ حدس نیست.

whoami /groups
klist
query session

اگر برنامه از حساب سرویس استفاده می‌کند، حقوق همان حساب است که در ادامه اهمیت دارد. چرخش آن اعتبارنامه به بازبینی دسترسی تعلق دارد نه به تأملی عملیاتی پس از آن.

چرا مسیر مستقیم هنوز و به‌درستی بسته است

قاعده رد فقط به این دلیل نادرست نیست که مقصد از راه دیگری در دسترس است. بخش‌بندی به تفکیک مبدأ ارزیابی می‌شود و دسکتاپ روی بخشی است که مدت‌ها پیش از آنکه کسی آن را راهی به پایگاه داده بداند مجاز شده بود. چیزی سیاست را دور نزده است. سیاست فقط دو مبدأ متفاوت با دو نتیجه متفاوت را توصیف می‌کند.

چیزی که بازبینی باید پاسخ دهد این است که هر نشست مجاز روی آن میزبان چه چیزی می‌تواند آغاز کند. مرورگرهایی با نشست‌های ذخیره‌شده، درایوهای نگاشته‌شده، عاملانی که اعتبارنامه نگه می‌دارند و سرویس‌های شنونده محلی همه دسترس دسکتاپ را گسترش می‌دهند و هیچ‌کدام در تیکتی که ورود را داده نیامده‌اند. همان فهرست سطح واقعی مجوز است.

آن را از داخل یک نشست آزمایشی برشمارید نه از یک صفحه‌گسترده. چند فرمان بیشتر سطح را پوشش می‌دهد.

Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess
net use
Get-ChildItem Env: | Where-Object Name -match 'PROXY|DATABASE|API'

مرز را آگاهانه انتخاب کنید

سه شکل به کارهای متفاوت می‌خورند و انتخاب باید از کار پیروی کند نه از ابزاری که تصادفاً وجود دارد. برنامه منتشرشده یک برنامه با مجوزهای خودش را آشکار می‌کند، دسکتاپ کامل هر کاری را که نمایه کاربر می‌تواند بکند آشکار می‌کند و حساب پایگاه داده تنگ با محدودیت مبدأ یک منبع را بدون هیچ دسکتاپی آشکار می‌کند. تنگ‌ترین شکلی که هنوز کار را تمام می‌کند همان است که باید مستند شود. هر چیز گسترده‌تر دلیلی می‌خواهد که کنارش نوشته شود.

برای یک گزارش، برنامه منتشرشده یا حساب محدود مجوزی کوچک‌تر از یک دسکتاپ عمومی است. برای نگهداری‌ای که واقعاً چند ابزار می‌خواهد، دسکتاپ می‌تواند درست باشد، اما آنگاه تأیید کل میزبان را توصیف می‌کند نه یک برنامه را. از صاحب منبع بپرسید به کدام‌یک از این‌ها پاسخ مثبت می‌دهد.

جابه‌جایی داده کلید جداگانه‌ای است. تخته‌گیره، تغییرمسیر درایو و بارگیری‌ها می‌توانند داده شرکت را به مشتری ببرند و اجرای برنامه از راه دور به‌خودی‌خود داده را دور نگه نمی‌دارد.

هر دو تأیید و مسیر حذف را بررسی کنید

دو تأیید به سابقه تعلق دارد: حق رسیدن و باز کردن دسکتاپ و حق استفاده از منابع از داخل آن. برای هرکدام صاحبی نام ببرید و دومی را برای هر کس که منبع را بازبینی می‌کند دیدنی نگه دارید. همان ورودی دوم است که حسابرس درباره آن می‌پرسد، چون دسترس را توصیف می‌کند نه ورود را. هر دو را پیش از تأیید تغییر بنویسید نه پس از نخستین رخداد.

سپس حذف را بیازمایید، چون نشست قطع‌شده می‌تواند از دلیلش عمر بیشتری بکند. جدول نشست‌ها سریع‌ترین جا برای دیدن چیزی است که هنوز در حال اجراست.

query session
query user
qwinsta /server:rdsh01.corp.internal

قطع کردن مشتری نشست دور را در حال اجرا می‌گذارد و اتصال‌های شبکه و اعتبارنامه‌های نهان‌شده آن می‌توانند تا پایان آن نشست قابل استفاده بمانند. خارج شوید یا نشست را صریحاً پایان دهید و تأیید کنید که شمارنده بعدی پس از آن جلو نمی‌رود. آزمون حذفی که فقط در لپ‌تاپ را می‌بندد چیزی را ثابت نمی‌کند. همان آزمون را یک بار با حساب غیرفعال و یک بار با برداشتن اجازه دسکتاپ انجام دهید و سپس ثبت کنید منبع در هر حالت چه چیزی را لاگ کرد.