Чому погана практика дозволяти всім використовувати вхід sa?

Навіть Microsoft заважає використовувати режим аутентифікації SQL Server , але наші програми цього вимагають.

Я читав, що найкраща практика забороняти користувачам користуватися saвходом безпосередньо, замість цього використовувати автентифікацію Windows і дозволяти цим обліковим записам (або групам облікових записів) привілеїв системного адміністратора.

• Хіба це не те саме? Які переваги / недоліки?
• Як найкраща практика підвищує безпеку моїх примірників SQL Server?
• Чи це стосується лише виробничих примірників, або для наших внутрішніх розробок?

У вас тут є кілька різних запитань, тому я вибиваю їх окремо:

"Я читав, що найкраща практика забороняти користувачам використовувати вхід sa безпосередньо, а не використовувати автентифікацію Windows"

Тут ви змішуєте дві речі: концепцію SA та концепцію автентифікації SQL та автентифікації Windows.

Аутентифікація SQL - це список імен користувачів та паролів, які зберігаються у кожному SQL-сервері. Те, що він зберігається в SQL, є першою проблемою. Якщо вам потрібно змінити пароль для входу, ви повинні змінити його на кожному сервері (або підтримувати різні паролі на різних серверах). За допомогою автентифікації Windows ви можете центрально відключити вхід, змінити паролі, встановити політику тощо.

Якщо ви вирішили використовувати автентифікацію SQL, то SA - це лише один логін для автентифікації SQL. Це ім'я адміністратора за замовчуванням, як і адміністратор в системі автентифікації Windows. Він має локальні наддержави в одному екземплярі, але не глобальні наддержави в усіх випадках.

"... і дозволяти цим обліковим записам (або групам облікових записів) привілеїв системного адміністратора."

Який би метод аутентифікації ви не вибрали, в ідеалі ви хочете дотримуватися принципу найменшої пільги: надання людям мінімальних прав, які вони потребують, щоб виконати свою роботу, і не більше.

Не думайте про них як про реєстрацію - це люди, які можуть вас звільнити. Якщо вони випадково відкинуть базу даних або відключать ваші завдання резервного копіювання, вони не звільняться, оскільки за замовчуванням SQL не відстежує, хто що робив. Ти будеш звільнений, бо це станеться, і ти не зможеш сказати, хто це зробив.

"Як найкраща практика підвищує безпеку моїх екземплярів SQL Server?"

Ви хочете зробити дві речі:

1. Не дозволяйте людям зламати сервер
2. Коли вони зламають сервер, зможете точно визначити, хто це зробив

Перший з них здійснюється за принципом найменшої привілеї: надавати людям лише ті необхідні їм дозволи, і нічого більше.

Другий - це даючи кожній особі свій власний логін, не дозволяючи спільним входам (наприклад, дозволяти всім використовувати одне і те ж ім’я користувача / пароль), а в ідеалі - перевіряти входи. Ви, мабуть, не зробите цю останню частину одразу, тому що це наче болісно, ​​але давайте поставимо деталі на перше місце, щоб ви могли додати аудит пізніше, коли хтось скине базу даних, і ваш начальник захоче знати, чому.

Я знаю, що ви думаєте: "Але ми кодуємо програми, і для цього потрібен логін". Так, дайте програмі власний логін, і розробники повинні знати цей пароль, але цей логін повинен бути настільки позбавлений дозволів, що ніхто з розумом не захоче ним користуватися. Наприклад, може знадобитися лише в ролях db_datareader та db_datawriter, нічого іншого. Таким чином він може вставляти, оновлювати, видаляти та вибирати дані, але не обов'язково змінювати схеми, додавати індекси, змінювати збережені процедури тощо.

"Це стосується лише виробничих примірників, або ж для наших внутрішніх розробок?"

Я думаю, це так само стосується випадків розвитку, тому що я зазвичай переживаю, щоб люди ламали речі. Люди просто люблять ламати сервери в розвитку. І звичайно, коли настав час скласти список змін для переходу на виробництво, мені потрібно знати, чи дійсно конкретний індекс є життєво важливим для додатка, чи якийсь кістковий голова просто запустив радника з налаштування бази даних і сказав йому застосувати всі зміни . Належний дозвіл дозволяє зменшити біль.

Насправді, якщо ви читаєте цю довідку: Розділ обов'язків на SQL Server

Він скаже вам, що НІхто не повинен використовувати привілеї sysadmin у своєму акаунті. Щоденному доступу до облікового запису повинен бути наданий мінімальний доступ, а не явні права системи sysadmin. Враховуючи їх, СЕРВЕР КОНТРОЛУ насправді близький до того, що є sysadmin, а потім дозволяє вам все-таки ЗАБЕЗПЕЧИТИ / ОТМЕНИТИ доступ там, де їм це не потрібно. Надання дозволу на права sysadmin для когось стає проблемою, якщо від вас вимагається відповідати будь-яким стандартам ІТ-відповідності. Більшість стандартів вимагають мінімального використання ролі sysadmin.

Я вимикаю і перейменую обліковий запис "sa", як і ви з вбудованим обліковим записом адміністратора в ОС. Використовувати лише в надзвичайних ситуаціях.

Зазвичай розробникам надається повний доступ до їх середовища розробки. Потім, коли їх програма буде перенесена на екземпляр перед виробництвом, їх доступ повинен бути мінімальним або жодним; так, як це було б у виробництві. Це ідеальний світ. Якщо ви все ще не в цьому, а ваші розробники мають більші привілеї, ніж вам потрібно, я б перевірив їхню акаунт. Я захоплював би все, і все, що вони роблять. Тож якщо ви хочете щось не так, коли вони були на вашому виробничому сервері, ви можете повернутися назад і дізнатися, що саме вони зробили.

Якщо ви підпадаєте під дію зовнішнього регуляторного контролю або стандартів (SOX, PCI тощо), то ви

• не вдасться до аудиту
• не справляються з вашими щомісячними чеками PCI

Розробники повинні мати db_owner на мережевому SQL Server лише для розробки.

Якщо ваші сервери SQL є всіма в мережі зі стандартною збіркою (тобто тим же обліковим записом служби), то один в одному надає права на них усім.

Якщо обліковий запис служби локальний адміністратор, то ваші розробники також мають повний контроль над серверами.

Зборів немає.

sa = sysadmin

Увійти за допомогою sa дає користувачеві можливість виконувати всі наступні дії: - скидати та створювати бази даних - змінювати об’єкти в базі даних - скидати та створювати входи в систему - змінювати паролі - видаляти всі дані

Надання привілеїв для системи Windows sysadmin здійснює те саме.

Список продовжується, але це повинно дати вам кілька вагомих причин, щоб НІКОЛИ НІКОЛИ не дозволяти не адміністратору використовувати sa.

Вам слід створити вікно або обліковий запис SQL з мінімальними привілеями, необхідними для роботи програм. (тобто вхід, доступ до збережених процедур та переглядів)

Найкраща практика - це ввести якийсь надійний пароль і забути його.

Зараз у мене на увазі два варіанти, чому не слід мати слабкий обліковий запис SA. Якщо у вас слабкий / порожній пароль для SA, одна зла людина (перекладіть це на «доброзичливий колега») може:

• увімкніть системну процедуру xp_cmdshell і, користуючись привілеями облікового запису сервісу Sql Server, нанесіть шкоду вашому локальному вікні (створіть / видаліть файли ..). Наявність низької безпеки для SA фактично не говорить про налаштування екземпляра, але може означати, що користувач послуги може дотримуватися поганих практик (наприклад, бути адміністратором :-));

• увімкніть пошту у вашому випадку і перемотайте невеликий розважальний сценарій зі спамом (це, швидше за все, спричинить вам проблеми або з Інтернет-провайдером, або з вашими колегами. Залежно від того, куди відправляються листи ;-));

Я не зазначатиму очевидних фактів, що це може скидати бази даних, логіни ... і т.д.

• Хіба це не те саме? Які переваги / недоліки?

• Не обов’язково: наприклад - для екземпляра SQL Server від вашого ноутбука різниця між автентифікацією Windows і автентифікацією SQL означає, що теоретично зовнішній зловмисник може використовувати лише обліковий запис SQL, оскільки автентифікацію Windows не можна використовувати за межами власного домену рахунок. Користувач може сканувати ноутбуки сусідів з торгового центру, де ви п'єте свою каву, і може побачити, що у вас встановлений і запущений екземпляр SQL, і він може спробувати безкоштовно повеселитися. Це не так, що це може траплятися часто ... але це можливість :-).

• Як найкраща практика підвищує безпеку моїх примірників SQL Server?

• Як кожна найкраща практика в цьому світі робить свою роботу .. зменшує шанси на можливий зворотний бік (наприклад: найкраща практика займатися фізичними вправами знизить шанси на те, що ти схожий на мене .. кушетка картоплі), що може статися інакше.

• Чи це стосується лише виробничих примірників, або для наших внутрішніх розробок?

• Скажімо, що я б запропонував впровадити найкращі практики безпеки (протестовані та модифіковані відповідно до потреб вашого середовища) хоча б у виробництві. Але якщо ви також використовуєте виробничі дані (чутливі ... і т.д.), це є яскравим свідченням того, що ви також повинні змінити свою практику розвитку.

Вирішуючи ваше останнє запитання, ми використовуємо облікові записи SA у всіх наших базах даних про розробку (з таким паролем "sa"!)

Однак важливо зазначити, що ми не зберігаємо дані та не генеруємо дані. Наші бази даних використовуються виключно для зберігання даних для додатків C / C ++. Ці бази даних розробки містять суто тестові дані і часто створюються, видаляються, змінюються тощо. \

Крім того, настільки ж критично, всі бази даних про розробку встановлюються на розроблювальних машинах. (Принаймні одна копія на кожного розробника!) Тож якщо хтось заблукає всю установку, вони зіпсували лише себе, і ніхто більше.

Якщо мова йде про середовище, де ви хочете переконатися, що ваша база даних, таблиці та дані насправді є безпечними та безпечними, то вам потрібен приємний, надійний пароль SA. Якщо ви залишите це слабким, то будь-хто і всі мають повний доступ до ваших даних і можуть повністю знищити вашу базу даних.

Для зв'язки розробників зі своїми копіями бази даних , яка містить чисто тестові дані, я до сих пір ще повинен знайти твердий аргумент для підтримки сильного рахунку SA.

Будь-який поставлений параметр безпеки системного сервера SQL Server повинен бути змінений. Рекомендується не використовувати змішаний режим (вмикає і автентифікацію Windows, і SQL Server) для аутентифікації. Натомість переключіться лише на автентифікацію Windows - це буде застосовувати політику пароля Windows - перевірка тривалості пароля, тривалості життя та історії. Особливістю політики щодо пароля Windows, яка відрізняє її від автентифікації на SQL Server, є блокування входу - після ряду послідовних невдалих спроб входу вхід стає заблокованим та непридатним для подальшого використання

З іншого боку, аутентифікація SQL Server не забезпечує жодних методів виявлення спроб атаки грубої сили, і що ще гірше, SQL Server навіть оптимізований для обробки великої кількості спроб швидкого входу. Отже, якщо автентифікація SQL Server є обов'язковою для певної системи SQL Server, рекомендується відключити вхід в SA