Шість рішень, які варто записати в договір доступу з хмари до бекенду

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

Вирішіть операції до конектора

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

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

Вирішіть ідентичність робочого навантаження і призначте їй власника

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

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

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

Вирішіть мережевий обсяг, знаючи, що це не дозвіл

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

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

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

Вирішіть обробку даних і розподіл відповідальності

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

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

Вирішіть відмову, видалення і те, як ви це приймете

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

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

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