Шест решения, които да впишете в договор за достъп от облака към бекенда

Вземете услуга за отчети в облачен акаунт, която се нуждае от одобрени обобщения от вътрешна система на клиент. VPN или удостоверена връзка на приложение защитава пътя и не решава нищо друго. Тя не решава дали работното натоварване за отчети може да чете несвързани записи, да променя бекенда или да запазва това, което е изтеглило. Напишете споразумението за достъп по отношение на операции и данни, преди да изберете конектора, защото конекторът е най-евтината част за промяна по-късно и най-лесната за първа грешка.

Решете операциите преди конектора

Първото решение е какво е разрешено да прави работното натоварване, назовано като операции, а не като мрежов диапазон. За случая с отчетите тесен API за отчети може да задоволи нуждата, без да дава администриране на база данни на облачно работно натоварване.

Отделете данните, от които отчетът се нуждае, от данните, които просто са достъпни. Запишете разрешените операции като крайни точки и глаголи в същия документ като решението за идентичност. Това разграничение е разликата между интеграция, която преминава одит, и такава, която трябва да се обяснява всяка година, и то решава спорове по-късно без още една среща.

Решете идентичността на работното натоварване и ѝ дайте собственик

Задачите без надзор не могат да отговорят на подкана, затова екипите посягат към широкия акаунт на човек и после го забравят. Използвайте сервизен акаунт или машинни идентификационни данни, които бекендът действително приема, и запишете кой ги притежава, къде се съхраняват и как се сменят.

Три условия трябва да насочат решението към отделна идентичност: задачата работи без човек наблизо, идентификационните данни живеят по-дълго от едно внедряване и повече от един човек трябва да знае, че съществуват. Ако и трите са верни, споделеният човешки акаунт не е прекият път, а постоянно изключение, което никой не може да отмени чисто.

Предпочитайте идентификационни данни, които платформата може да издаде и смени за работното натоварване, например токен за идентичност на работно натоварване, който бекендът валидира, пред статична тайна, поставена в конфигурацията. Статичните тайни в настройките на приложението са причината смените да се превръщат в прекъсвания.

Решете мрежовия обхват, знаейки, че той не е разрешение

Уточнете коя страна започва връзката, поддържания транспорт и участващите крайни точки. Дръжте проверките за идентичност на партньора включени и оставете несвързаните дестинации на бекенда недостъпни, а не просто необявени.

Тесният маршрут на тунела е полезен обхват, но не може да замени оторизацията на ниво операция. Бекендът трябва да наложи договора чрез собствените си контроли, защото мрежата с готовност ще пренесе всяка заявка, която достигне до достижим порт. Проверявайте собствените роли и права на бекенда, а не таблицата с маршрути. Маршрутът, който достига до сървъра, все още оставя решението на сървъра и точно там договорът или се налага, или се пренебрегва.

Обратното също е вярно: валидните идентификационни данни за услуга не оправдават публикуването на слушател към всеки източник. Нужни са и двете контроли и нито една не замества другата.

Решете обработката на данни и разделението на отговорности

Запишете какво напуска средата на клиента, къде приложението го обработва и реалните условия за съхранение, архивиране, достъп и задържане. Задържането е частта, която се открива късно, обикновено когато някой попита дали копието от миналото тримесечие още съществува в кофа, която никой не е документирал.

Дръжте страните отделни. Операторът на приложението, доставчикът на софтуер и домакинът на инфраструктурата могат да носят различни отговорности и моделът на услугата определя кой кой е. Четете действителното споразумение, вместо да предполагате, че и трите имат еднакъв достъп или никакъв.

Решете отказа, премахването и как ще го приемете

Възложете отговорност за случаите на отказ преди да се случат. Когато конекторът се счупи или има съмнение за компрометирана идентичност, реакцията не бива да бъде импровизирано неограничено мрежово изключение, което надживява инцидента.

Премахването заслужава същата точност като настройването. Определете как се отменя оторизацията, как активният достъп приключва в рамките на поддържаното поведение на продукта и какво се случва със запазените копия, когато връзката приключи.

Приемете интеграцията с представителни разрешени операции и отказите, които договорът изисква, всичко под предвидената идентичност на работното натоварване. Потвърдете пътя на заявката и действително доставените данни, после наистина изпробвайте смяна на идентификационните данни и премахване. Свързаният тунел доказва, че път съществува; договорът е това, което дава на този път граница.