Чому програма не повинна використовувати обліковий запис sa

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

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

Мене змушують прийняти нову систему управління послугами, яка НЕ ​​БУДЕ працювати, якщо не використовує пароль sa. Я ніколи не встигав розібратися, чому під час встановлення оцінки, але команда сервера намагалася встановити її, щоб використовувати фіксовану роль, яку я створив, включаючи db_creater та інші дозволи, які я вважав, що це вимагатиме. що не вдалося. Тоді я дозволяю команді сервера встановити разом із акаунтом sa, але запустити під обліковим записом у ролі dbo для своєї бази даних, але це теж не вдалося. Нарічно я намагався змусити його працювати з обліковим записом у ролі sysadmin, але навіть це не вдалося, і не з корисними повідомленнями про помилки, які дали мені змогу вирішити, що відбувається, не витрачаючи більше часу, ніж у мене було в наявності. Він працюватиме лише з обліковим записом sa та паролем, збереженим у чистому тексті у конфігураційному файлі.

Коли я запитав це, і команда сервера поспілкувалася з продавцем, вони отримали тривожну відповідь: "У чому проблема?" а потім "добре ми можемо подивитися на скремтування пароля", скрембліруючи ffs

Я знаю, що є способи та засоби обмеження доступу до файлу, але, на мою думку, це лише ще одна слабкість у безпеці

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

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

Чи працюєте ви з клієнтами, які мають вимоги безпеки? Це гарне місце для початку. Якщо ми запустили додаток з доступом до рівня sa, або просто додаток, який не захистив належним чином свої облікові дані, навіть якщо не використовував приватний доступ (ми настійно віддаємо перевагу Windows Integrated, а не збереженому користувачеві / паролю, де це можливо), і ми підпадали під захист аудит, цей аудит провалиться, і ми ризикуємо втратити клієнтів та / або доведеться повернути гроші клієнтам нашої групи (банківські організації у випадку продукту, над яким я працюю в основному, інші частини групи займаються поліцією та охороною здоров'я влада тощо) безпека є частиною нашої пропозиції, яка відповідає визначенню. Ділові люди НЕ розуміють серйозність цієї потенційної загрози , навіть якщо вони зазвичай платять не більше , ніж на словах ІТ - рекомендації.

Навіть ігноруючи вимоги, що пред'являються клієнтом, якщо ви прагнете відповідати різним галузевим стандартам безпеки, знову-таки така автентифікація додатків зірве вас перед аудитом, оскільки це далеко не найкраща практика, як щось, що зазвичай вважається таким у списку "просто не слід робити". Поясніть своїм виробникам бізнес-рішень, що безпека є важливою частиною програми, а той факт, що цей постачальник, мабуть, не знає (або хоча б належним чином переймається) викликає у вас сумніви щодо того, що ще вони не здатні. мати справу з: знання найкращої практики безпеки БД - це (добре, що повинно бути) частиною їхньої роботи, і впроваджувати це не складно.

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

Жодна програма не повинна мати доступ до СА. (Якщо тільки її єдиною метою є якесь адміністрування баз даних.)

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

Жодна програма не є повністю захищеною. Більшість мають певну вразливість SQL або XSS. Якщо зловмисник змушений виконати заяву про свій вибір і має доступ до "SA", з вашими даними може трапитися багато речей, які можуть враз убити бізнес. (Особливо, якщо дані потрібно довіряти, оскільки вони використовуються правоохоронними органами.) Запитайте у власників акцій, що вони повинні робити, якщо хтось зміг навмисно змінити навіть один запис і ця інформація просочилася.

Тепер, за допомогою доступу SA, можна змінити не тільки базу даних програми, але й будь-яку іншу базу даних у системі. Тож запитайте своїх зацікавлених сторін, що вони роблять, якщо ви зробите копію ВСІХ ваших баз даних і надішлете її до газети. Тому що це може статися, якщо незадоволений працівник з'ясує, що існує ця дірка для безпеки.

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

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

Можна спробувати два рішення:

1. Перейменуйте SA (найкращий досвід безпеки у будь-якому випадку) та створіть новий обліковий запис під назвою "SA" з обмеженими правами. (Ніколи цього не пробував, але це має працювати)

2. Не встановлюйте програмне забезпечення. Ви як професіонал не можете нести відповідальність за цю дію, тому не слід її встановлювати. Для порівняння попросіть водопровідника провести газопровід безпосередньо через камін, а не навколо нього, щоб заощадити трубу / гроші. Ви можете сміятися з цього зображення, але я вважаю, що це відповідне порівняння - Це програмне забезпечення рано чи пізно, можливо, рано. І коли це станеться, це теж може знищити бізнес.

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

Я бачу дві атаки цього напрямку.

• Відповідність . Чи діють якісь обов'язкові критерії відповідності у вашому магазині? Уважно перегляньте його формулювання та перевірте, чи знайдете ви щось, що було б несумісне з вимогою програми. Якщо ви знайдете що-небудь, що перешкоджає saвикористанню додатком, у вас є захист від води, який захищений від кулі, оскільки ця програма спричинить відповідальність за ваш бізнес тощо.

• Доступ адміністратора користувача . Переконайтесь, що ви чітко представляєте випадок, що програма, яка вимагає saдоступу, фактично надає saдоступ усім корпоративним користувачам, які мають права адміністратора на робочих станціях, де встановлена ​​програма. Неможливо приховати saпароль від місцевих адміністраторів, де працює програма, це факт, і жодна кількість «скремблювання» не може цього запобігти. Не існує локального кореня довіри, до якого місцевий адміністратор не може отримати, якщо він хоче. Дайте зрозуміти, що наявність програми, яка вимагає привілею, saнадавати saпільги всім користувачам, які працюють із програмою. Поясніть, що це означає, що ефективно можуть робити користувачі:

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

Поясніть особам, які приймають рішення, що прийняття цієї програми означає довірити кожному працівнику, який має адміністратор, до робочих станцій, що керують програмою, усіма привілеями, згаданими вище. Постачальник спробує захистити свою позицію, застосувавши якусь чи іншу інформацію про "шифрування" saпароля програми. Це не затримує води. Не існує схеми шифрування, яка може протистояти атаці адміністратора. І уточнити, що кількість технічної майстерності, необхідної для пошуку локально "прихованого" пароля, абсолютно не має значення. Співробітники не збираються робити це самостійно, один з них запустить це в Google і відкриє простий у використанні сценарій, який це робить.

По-перше, збережений пароль простого тексту? Ви повинні голосувати за гаманець. Хто вважає, що це прийнятно, потрібно припинити свою діяльність.

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

Це принцип найменшої прихильності.

Щодо того, чому програмі потрібно використовувати обліковий запис sa, це питання, на яке PerfMon або Extended Events повинні відповісти. Створіть трасування PerfMon за допомогою шаблону T-SQL, можливо, відфільтрованого за назвою програми.

Ось ще один аргумент проти використання sa: Для використання облікового запису sa потрібна служба SQL Server у змішаному режимі аутентифікації. Тільки WIndows аутентифікація краще, тому що ми можемо використовувати всі захищені можливості Kerberos.

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

Якщо у вас є ця програма, я б запустив її в окремий екземпляр, у якому немає нічого іншого.

Можливо, ваш постачальник вимагає / вимагає "sa", тому що десь у своїй програмі вони використовують XP_CMDSHELL. (Не запускайте мене з приводу можливого збитку при необмеженому доступі до XP_CMDSHELL. Досить сказати, що це потенційно відкриває не лише ваші дані, але й хост-машини, і, можливо, все інше у вашій мережі для доступу до адміністратора).

Якщо є законна потреба, ви можете надати обмежений доступ через проксі-рахунок. Дивіться, наприклад, BOL: http://msdn.microsoft.com/en-us/library/ms175046.aspx

Жодна програма не потребує роботи облікового запису та пароля SA.

Однак я встановив продукт управління ІТ-сервісом, і під час процесу встановлення у вас є можливість надати облікові дані облікового запису SA, щоб інсталятор міг створити БД та приєднати обліковий запис до БД для використання програмного забезпечення. Дані облікового запису SA не зберігаються ніде в журналах програми чи інсталятора. Це програмне забезпечення також надає можливість використовувати попередньо створену базу даних під час встановлення.

Тож я би просто підтвердив, чи потрібен обліковий запис SA для встановлення або функціонування цього програмного забезпечення для управління послугами ІТ.

Якщо Встановлення: створіть тимчасовий обліковий запис 'sa' - зробіть установку - та видаліть обліковий запис.

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

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

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