Ваш VPN сам по собі не робить Cosmos DB приватною
VPN підключає ноутбук до мережі, а не всередину бази даних. Подивіться, що мають робити приватна кінцева точка, зона DNS, режим підключення та доступ до облікового запису.
Ви підключаєте ноутбук до VNet через VPN, відкриваєте URL облікового запису Cosmos DB, і запит усе одно виходить через публічний інтернет. Тунель виконав свою роботу. Чого він не зробив — не створив приватну кінцеву точку, не опублікував приватний запис DNS і не вимкнув публічний доступ, бо це три окремі зміни облікового запису, а не властивості вашого мережевого з'єднання. У цьому прикладі використовуються Azure Cosmos DB для NoSQL, приватна кінцева точка у VNet і ноутбук, підключений до цієї VNet через VPN, і адреса застосунку залишається незмінною.
Міф: перебування у VPN робить базу даних приватною
Перебування у VNet означає лише те, що ваші пакети можуть досягати приватних адрес у цій VNet. Це нічого не каже про те, де розв'язується ім'я облікового запису, і нічого не каже про те, чи обліковий запис досі приймає публічний трафік.
Приватна кінцева точка — це окремий ресурс із власною адресою, власним кроком затвердження та власною DNS-розводкою. Доки її немає і вона не затверджена, ім'я розв'язується в публічну кінцеву точку, і ваш трафік іде туди незалежно від тунелю.
Що насправді змушує ім'я розв'язуватися приватно
Збережіть звичайну кінцеву точку облікового запису з SDK, щось на кшталт https://ACCOUNT.documents.azure.com. Приватний DNS має розв'язувати це ім'я через ланцюжок Private Link у приватні адреси кінцевої точки. Не замінюйте її числовим URL і не вимикайте перевірки сертифікатів, бо це міняє проблему DNS на проблему безпеки.
| Example choice | Value |
|---|---|
| Cosmos API | NoSQL |
| Private endpoint subresource | Sql |
| Private DNS zone | privatelink.documents.azure.com |
| SDK connection mode | Gateway |
Ці значення специфічні для API NoSQL. Інші API Cosmos не є взаємозамінними записами в тому самому прикладі, а копіювання імені дочірнього ресурсу з іншого API створює кінцеву точку, яка ніколи не розв'язується.
Створіть і затвердіть кінцеву точку через авторизований робочий процес Azure, потім використайте її інтеграцію з групою приватних зон DNS. Ноутбуку потрібен розв'язувач, який може відповідати за цю зону, безпосередньо або через затверджене пересилання, і маршрут VPN-клієнта до кожної відповідної адреси кінцевої точки.
Приватна кінцева точка може мати більше однієї адреси, включно з глобальними та регіональними записами. Підтримуйте інтеграцію DNS, коли змінюються регіони облікового запису, замість того щоб закріплювати одну адресу у файлі hosts, і пам'ятайте, що відповідь незв'язаного публічного розв'язувача нічого не доводить про приватний шлях. Якщо ви пересилаєте DNS через концентратор, переконайтеся, що пересилач відповідає, перш ніж налагоджувати клієнт. Застарілий пересилач повертає публічну відповідь, яка виглядає точно як відсутня кінцева точка.
Режим Gateway і режим Direct не є взаємозамінними
Режим Gateway надсилає запити до служби через HTTPS на TCP 443. Тому для нього працює політика брандмауера лише для 443, і тому цей приклад обирає його навмисно.
Режим Direct через Private Link має інші вимоги до підключення, зокрема ширший діапазон портів TCP, який перелічує документація облікового запису. Політику, написану для режиму Gateway, не можна мовчки повторно використовувати для клієнта в режимі Direct, інакше SDK підключиться і потім зависне на першій операції з даними.
Виберіть один режим, запишіть його разом з обліковим записом і приведіть мережеву політику у відповідність до нього. Команди, які перемикають режими під час усунення неполадок, зазвичай отримують набір правил брандмауера, що не задовольняє жоден із них.
Вимкнення публічного доступу — окремий перемикач
Якщо обліковий запис має бути лише приватним, вимкніть публічний мережевий доступ через підтримуване налаштування облікового запису й перевірте результат. Не вважайте наявність приватної кінцевої точки повним рішенням про доступ, бо обліковий запис із приватною кінцевою точкою та ввімкненим публічним доступом усе ще відповідає в інтернеті.
Перевірте ззовні VPN, а також зсередини. Запит із мережі, яка має бути виключена, — це тест, що доводить, що налаштування набуло чинності, і саме цей тест пропускають більшість вікон змін.
Досяжність — не дозвіл
Дозволена операція SDK з ноутбука у VPN — це приймальний тест, зі звичайним URL облікового запису та передбачуваною ідентичністю. Досяжність через VPN не дає прав на дані Cosmos; рівень даних перевіряє власні ролі або ключі.
Потім виконайте відмови: інша ідентичність і мережевий шлях, який більше не повинен досягати облікового запису. Якщо хоч одна з них вдасться, межа, яку ви задокументували, — не та межа, яку ви побудували.
Запишіть чотири факти після завершення: приватні адреси кінцевої точки, зону DNS, яка відповідає за ім'я облікового запису, режим підключення з його вимогами до портів і чи вимкнено публічний доступ. Ці чотири пояснюють налаштування наступній людині, і кожен із них може відмовити незалежно.