Excel до SQL Server партнера без довіри домену

Книзі Excel, яка відкриває таблицю на SQL Server іншої організації, потрібні три речі, які зазвичай обговорюють як одну: ідентифікатор, який сервер приймає, транспорт, який клієнт перевіряє, і мережевий шлях, який дозволяють обидві сторони. Довіра домену — один зі способів задовольнити перше, і найширший. TLS задовольняє друге і нічого не говорить про перше. Шлях задовольняє третє і сам по собі нічого не захищає.

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

Три рішення, які приховує питання

Ідентифікатор — це те, ким база даних вас вважає: обліковий запис Windows із довіреного домену, вхід SQL із власним паролем або ідентифікатор на основі сертифіката. Транспорт — це чи сеанс шифрується і чи клієнт перевіряє ланцюжок сертифікатів сервера. Шлях — це те, як пакети доходять до прослуховувача, яким може бути VPN, приватне з’єднання або публічна кінцева точка з правилами брандмауера. Кожне живе в іншому місці, і кожне може зазнати збою самостійно.

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

Ідентифікатор без довіри лісу

Навмисно підготовлений обліковий запис у цільовому середовищі може задовольнити вужчу вимогу без жодної довіри, за умови що робочий процес клієнта може його використати. Автентифікація SQL — інша поширена відповідь, коли політика дозволяє: вхід має власний життєвий цикл облікових даних, не приєднується до доменів і не створює вбудовану автентифікацію Windows. Ідентифікатор на основі сертифіката або токена — третій варіант на нових платформах. Що б ви не обрали, надавайте лише ті права в базі, які книзі справді потрібні.

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

Шифрувати так, але довіряти сертифікату?

З ODBC Driver 18 Encrypt=Yes;TrustServerCertificate=No вимагає шифрованого сеансу, сертифікат якого справді перевіряється. Рядок підключення тоді має називати сервер, який покриває сертифікат, а клієнт має довіряти його ланцюжку. Driver 18 також типово шифрує, на відміну від попередніх версій, тож старий рядок підключення тепер може узгоджувати TLS, не кажучи про це. Явні налаштування роблять задуману політику видимою на всіх машинах, що важливо, коли кілька людей супроводжують одну книгу.

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

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

Мережевий шлях — не захист

Приватний прослуховувач, доступний через VPN, зменшує вплив, і VPN має нести правильні маршрути призначення та повернення, щоб це працювало. Робочий тунель не усуває потреби в автентифікації або перевірці сертифіката, а TLS не обмежує, які віддалені системи можуть спробувати з’єднання. Це три окремі спостереження: рукостискання TLS, вхід через VPN і авторизований запит. Лише третє доводить, що книга прочитала дані, які їй дозволено читати.

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

Перевіряйте звичайним робочим процесом Excel: прийнятий ідентифікатор, чинні права та узгоджене шифрування, кожне через власне подання сеансу сервера.