حساب sa و سرویس‌هایی که sysadmin شده‌اند: ممیزی نیم‌ساعته

تقریباً هر سروری که برای اولین بار رویش می‌نشینم، دست‌کم یکی از این‌ها را دارد: لاگین sa فعال با گذرواژه‌ای که چند نفر می‌دانند، یا یک اپلیکیشن که با حساب sysadmin وصل می‌شود، یا هر دو.

این مقاله یک ممیزی کوتاه است که می‌توانید همین امروز انجام دهید، به‌علاوهٔ راه امن اصلاح — چون بی‌احتیاطی در این کار می‌تواند سرویس را بخواباند.

ممیزی: چهار کوئری

۱. چه کسانی sysadmin هستند؟

SELECT p.name, p.type_desc, p.is_disabled, p.create_date, p.modify_date
FROM   sys.server_role_members m
JOIN   sys.server_principals  r ON r.principal_id = m.role_principal_id
JOIN   sys.server_principals  p ON p.principal_id = m.member_principal_id
WHERE  r.name = N'sysadmin'
ORDER  BY p.name;

برای هر سطر یک سؤال: این چیست و چرا به این سطح نیاز دارد؟ حساب‌های سرویس اپلیکیشن، تقریباً هرگز نیاز ندارند.

۲. وضعیت sa

SELECT name, is_disabled, create_date, modify_date,
       LOGINPROPERTY(name, 'PasswordLastSetTime') AS pwd_set,
       LOGINPROPERTY(name, 'IsExpired')           AS expired,
       is_policy_checked
FROM   sys.sql_logins
WHERE  principal_id = 1;

اگر is_disabled = 0 و گذرواژه سال‌هاست عوض نشده، این نقطهٔ ضعف شمارهٔ یک شماست. هر ابزار حملهٔ خودکاری اول همین نام را امتحان می‌کند.

۳. لاگین‌هایی که هرگز استفاده نشده‌اند

SELECT name, type_desc, create_date, is_disabled
FROM   sys.server_principals
WHERE  type IN ('S','U','G')
  AND  name NOT LIKE '##%'
  AND  name NOT LIKE 'NT %'
ORDER  BY create_date;

حساب‌های قدیمی که برای پروژه‌ای ساخته شده‌اند و مانده‌اند. هر کدام یک در است.

۴. چه چیزی روشن است که نباید باشد؟

SELECT name, value_in_use
FROM   sys.configurations
WHERE  name IN (N'xp_cmdshell', N'Ole Automation Procedures',
                N'Ad Hoc Distributed Queries', N'remote admin connections');

xp_cmdshell روشن یعنی هر تزریق SQL می‌تواند به اجرای فرمان روی ویندوز تبدیل شود. اگر روشن است، اول بفهمید چه چیزی از آن استفاده می‌کند — معمولاً یک جاب قدیمی — و جایگزینش کنید.

اصلاح، بی خواباندن سرویس

وسوسهٔ طبیعی این است که همین حالا sysadmin را از حساب اپلیکیشن بردارید. نکنید — ممکن است جایی به آن وابسته باشد و شما وسط روز کاری سرویس را بخوابانید.

مسیر امن:

1. اول ببینید واقعاً چه مجوزهایی استفاده می‌شود. یک Extended Event یا Audit ساده روی مجوزهای ردشده بگذارید و چند روز جمع کنید.
2. حساب تازه‌ای با مجوزهای دقیق بسازید و اپلیکیشن را در محیط آزمایشی با آن اجرا کنید.
3. در پنجرهٔ کم‌باری سوئیچ کنید و حساب قدیمی را نگه دارید (غیرفعال، نه حذف) تا مطمئن شوید.
4. بعد از چند هفته حساب قدیمی را حذف کنید.

برای sa ساده‌تر است: غیرفعالش کنید، ولی اول مطمئن شوید دست‌کم یک حساب ادمین دیگر دارید که کار می‌کند — و آن را همین حالا امتحان کنید، نه فرض کنید.

ALTER LOGIN [sa] DISABLE;

یک قاعدهٔ ساده که خیلی نقض می‌شود

گذرواژه هرگز نباید به‌عنوان آرگومان خط فرمان داده شود. در تاریخچهٔ شل می‌ماند، و در فهرست فرآیندها برای هر کاربر دیگری روی همان ماشین دیدنی است:

sqlcmd -S localhost -U app_user -P 'MyPassword123'   -- نه

به‌جایش از احراز ویندوزی استفاده کنید، یا گذرواژه را در متغیر محیطی بگذارید و از همان‌جا بخوانید. در محصول خودمان، دیتابیس فقط نام متغیر محیطی را ذخیره می‌کند نه مقدارش؛ و جایی که مقدار باید ذخیره شود، رمزشده است با کلیدی که در دیتابیس نیست. خاصیتش این است که یک نسخهٔ دزدیده‌شده از دیتابیس — از بکاپ یا از فایل mdf — بی آن کلید بی‌ارزش است.

و بکاپ‌ها

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

دسترسی به پوشهٔ بکاپ را همان‌قدر جدی بگیرید که دسترسی به خود دیتابیس را — و اگر داده حساس است، بکاپ را رمزنگاری کنید و کلید را جای دیگری نگه دارید.