Безпека баз даних MS SQL в хмару Azure

Як ми пообіцяли у статті "міграція на-премії SQL Server в Azure SQL", ця стаття розповість про налаштування безпеки для служби бази даних в Azure. Ця послуга має багато функцій безпеки, які можна використовувати в різних сценаріях розгортання MS SQL.

Зміст:

• 1. SQL Server
• 2. Налаштування мережі для Azure SQL
• 3. Аутентифікація Azure AD в SQL
• чотири. Azure RBAC
• п’ять. Завжди зашифровано в Azure SQL
• 6. Маскування даних у Azure SQL

1. SQL Server

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

Окрім цих вимог до пароля, рекомендується дотримуватися наступних класичних рекомендацій:

• Пароль не повинен бути словом із словника, сленгу, діалекту, жаргону;
• Пароль не повинен містити особисту інформацію (дата народження, ім'я, телефон тощо.Е).
• Пароль не повинен збігатися з іменем веб -програми, якщо сервер баз даних використовується для застосування.
• Пароль не повинен відповідати сайту URL -адреси або імені домену
• Рекомендується перевірити, чи ваш пароль включений у список популярних паролів. Список таких паролів легко знайти в Інтернеті.

2. Налаштування мережі для Azure SQL

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

Ви можете ввімкнути захисника Azure для SQL. Це платний варіант, який включає оцінку вразливості та захисту від загроз.

Налаштування Brand Mower у розділі Брандмауер та віртуальні мережі можна змінити після створення віртуального сервера SQL.

Як ми бачимо, є правило, яке дозволяє трафік із клієнтської IP -адреси. Це публічна IP -адреса, призначена клієнту. Змінюючи цю адресу, ви більше не зможете підключитися до SQL Server. Коли неодноразово підключається за допомогою студії управління Microsoft SQL Server, з’явиться запит на створення нового з'єднання:

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

Публічна кінцева точка дозволяє підключитися до хмарного SQL -сервера з Інтернету. Існує кілька сценаріїв для підключення SQL -сервера до загальнодоступної кінцевої точки:

• Контрольована копія повинна інтегруватися з пропозиціями "Платформа як послуга" (PAAS) лише для кількох клієнтів.
• Вам потрібна більш висока ємність обміну даними, ніж це можливо при використанні VPN.
• Політика компанії забороняє PAAS всередині корпоративних мереж.

Для захисту SQL -сервера в цих сценаріях рекомендується шифрувати трафік SQL та обмежити з'єднання з Інтернету за допомогою брандмауерів.

Детальніше про захист мережевого з'єднання описано в документації Microsoft: https: // docs.Microsoft.Com/ru-rur/azure/azure-sql/керований-ininstance/public-endpoint-overview

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

Кожна кінцева точка послуги для віртуальної мережі може використовуватися лише в одній регіоні Azure. Кінцева точка не підтримує прийом з'єднань з підмережі в інших регіонах.

Для шифрування даних між клієнтською програмою та Microsoft Azure використовується протокол TLS. Тепер MS Azure використовує три версії протоколу TLS: 1.0, 1.1 і 1.2. Для публічних кінцевих точок використовується версія TLS 1.2, але все ще підтримуються старі версії, щоб забезпечити зворотну сумісність зі старими веб -додатками. Ви можете прочитати більше про налаштування протоколу TLS у документації Microsoft: https: // docs.Microsoft.Com/ru-ruu/azure/зберігання/загальна/транспорту-шар-безпечна-конфігура-мінімум-версія?Вкладки = портал

На відміну від PREM SQL Server, зашифроване з'єднання TLS завжди використовується для підключення до бази даних Azure SQL.

3. Аутентифікація Azure AD в SQL

Створюючи Azure SQL, ми отримали один обліковий запис, що включає вхід та пароль. Для управління доступом до бази даних рекомендується використовувати Azure AD.

Для цього перейдіть до бази даних, яку ми налаштуємо та виберемо Адміністратор Active Directory.

Після того, як ми призначили адміністратора, ви можете ввести з цим обліковим записом за допомогою Microsoft SQL Server Management Studio:

SSMS дозволяє підключитися до бази даних Azure за допомогою сучасної автентифікації та Azure MFA.

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

Крім того, працюючи з базами даних, рекомендується призначати права не для окремих користувачів, а групам.

Додайте роль db_datareader до групи test_gp у базі даних APPDB . Ця роль дозволяє читати дані з бази даних APPDB. Для цього ви повинні дотримуватися наступного запиту в базі даних APPDB:

Створити користувача "[email protected] "від зовнішнього постачальника;
Exec sp_addrolemember 'db_datareader', '[email protected] 'з default_schem = [dbo];

Від зовнішнього постачальника вказує на те, що Azure AD - це наша послуга каталогу.

чотири. Azure RBAC

Azure RBAC (контроль доступу на основі ролі) дозволяє контролювати доступ на основі ролей. Ця послуга є системою авторизації на основі менеджера Azuresource, яка забезпечує детальне управління доступом до ресурсів Azure.

Метод управління доступом до ресурсів за допомогою Azure RBAC, як випливає з назви, він складається з призначення ролей. Роль складається з трьох елементів: директора безпеки, визначення ролі (визначення ролі) та обсягу (сфера).

• Суб'єкт безпеки - Це об’єкт, який надає користувачеві, групу, директор служби або керовану особу, вимагаючи доступу до ресурсів Azure. Ви можете призначити роль будь -якому з цих предметів.

  

• Визначення ролі - Це набір дозволів. Зазвичай визначення ролі просто називається роль. Роль визначає дії, які можуть бути виконані, наприклад, читання, запису або усунення.

  
  

• Область дії - Це набір ресурсів у Azure, до якого застосовується доступ. При призначенні ролі ви можете додатково обмежити дозволені дії.

  

  Наступний крок створить керовану ідентичність. Для цього ми вмикаємо систему, призначену для ідентичності.

  

  Щоб підключитися до бази даних, нам потрібен обліковий запис користувача в базі даних. Створіть автономного користувача, це може зробити лише адміністратор у групі GRP-SQLADMIN. Автономний користувач повинен мати те саме ім’я, що і додаток. Створіть автономний користувач для програми MY-APP:

  Створити користувача [My-App] від зовнішнього постачальника;
Змінити роль DB_Datareader Додати член [My-App];
Змінити роль db_datawriter додати члена [my-app];

  Наступним кроком є ​​встановлення драйвера Microsoft.Дані.Sqlclient v. 3.0.0.

  Цей драйвер отримує маркер від AAD, додає його до SQL -з'єднання та обробляє кешування та оновлення жетонів.

  Коли програма підключена до бази даних Azure SQL за допомогою аутентифікації AAD, ключове слово аутентифікації та Active Directory або Active Directory за замовчуванням слід вказати в базі даних. Ми будемо використовувати аутентифікацію AD за замовчуванням, тоді лінія з'єднання для підключення бази даних матиме форму:

  Сервер = мій SQL-сервер.База даних.Вікна.NET, 1433; база даних = MY-BASE; аутентифікація = Active Directory за замовчуванням

  Детальніше про підключення програми ви можете прочитати за допомогою контрольованої ідентифікації в документації Microsoft:

  https: // docs.Microsoft.Com/en-sure/app-service/tutorial-connect-msi-sql-дата даних?Вкладки = WindowsClient%2cdotnet

  п’ять. Завжди зашифровано в Azure SQL

  Використовуючи завжди зашифровану функцію, можна зашифрувати кілька стовпців, розташованих в одній або в різних таблицях, а також зашифровувати певний стовпець. Завжди зашифрована опція дозволяє зашифрувати не лише зберігати дані, але й передавати дані. Клієнтська програма також повинна підтримувати шифрування.

  Існує два типи шифрування:

  • Детерміноване шифрування - Для будь -якого текстового значення генерується те саме зашифроване значення. Це менш безпечно. Але це дозволяє шукати, асоціації за рівністю, групуванням та індексацією зашифрованими стовпцями.
  • Рандомізоване шифрування - Безпечне шифрування. Але це не дозволяє пошуку, групування та індексації зашифрованими стовпцями.

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

  • Майстер клавіші стовпців - Цей ключ повинен бути збережений у зовнішньому сховищі (або в сертифікаті Windows або у сховищі ключа Azure).
  • Ключ шифрування стовпців - Цей ключ генерується з головного ключа стовпців і використовується для шифрування будь -яких стовпців.

  Тепер користувач, який хоче використовувати завжди зашифровану функцію, повинен встановити необхідні дозволи на клавіші (створити, отримувати, перелічити, підписуйте, перевірити, Wrapkey, Unl Parapkey).

  Ми шифруємо стовпчик електронної пошти в базі даних APPDB, таблиці Saleslt.Замовник. Ці дані повинні бути зашифровані за допомогою ключа шифрування. Ці клавіші повинні зберігатися в азурному ключовому сховищі. Користувач, який виконує це шифрування (DemusRC), повинен мати дозвіл на виконання цієї операції.

  

  Тепер перейдемо до таблиці Saleslt.Клієнт і виберіть стовпець, який ми будемо шифрувати.

  

  У відкритому майстрі ми виберемо стовпець, тип шифрування та ключ.

  

  

  Тепер стовпець, що містить клієнтів електронної пошти, буде зашифровано:

  

  Завжди зашифрована таблиця клавіш містить клавіші шифрування: головні клавіші стовпців та клавіші шифрування стовпців.

  

  6. Маскування даних у Azure SQL

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

  Існує кілька типів маскування даних:

  • Правило маскування кредитної картки - Використовується для маскування стовпців, що містять дані кредитної картки. Показані лише останні 4 цифри.
  • Електронна пошта - Показані лише перші 4 символи електронних адрес. Всі доменні імена замінені XXX.Com
  • Спеціальний текст - Маски будь -якого тексту. Ви можете вирішити самостійно, які символи поля повинні бути замасковані.
  • Випадкове число - Ви можете генерувати випадковий набір польових номерів.

  Перейдимо до розділу безпеки сервера бази даних і виберемо там Динамічне маскування даних:

  

  Ви можете вибрати стовпець, який сервер бази даних рекомендує замаскувати та визначити маску для нього. Ми замаскуємо колонку з клієнтами електронної пошти.

  

  Функція маскування використовується лише для неконвілізованих користувачів системи. Адміністратори Дивіться значні дані.

  

  Безпека SQL Server - дуже важлива тема, яка відрізняється глибиною та різноманітністю. У цій статті ми не враховували всіх аспектів безпеки хмарного сервера SQL, але запалили основні та досить важливі моменти.
  Автор статті Олег Астахов, За підтримки телеграми каналу Azure Ru Community https: // t.Я/azurerumunity