Hat döntés, amelyet érdemes beleírni a felhő és a backend közötti hozzáférési szerződésbe

Vegyünk egy felhőfiókban futó jelentéskészítő szolgáltatást, amelynek jóváhagyott összefoglalókra van szüksége egy ügyfél belső rendszeréből. Egy VPN vagy hitelesített alkalmazáskapcsolat védi az útvonalat, és semmi mást nem dönt el. Nem dönti el, hogy a jelentéskészítő munkaterhelés olvashat-e nem kapcsolódó rekordokat, módosíthatja-e a backendet, vagy megtarthatja-e, amit lekért. Írjuk meg a hozzáférési megállapodást műveletek és adatok szerint, mielőtt kiválasztjuk az összekötőt, mert az összekötő a legolcsóbb később módosítható rész, és a legkönnyebben elsőre elrontható.

Döntsük el a műveleteket az összekötő előtt

Az első döntés az, hogy mit tehet a munkaterhelés, műveletekként megnevezve, nem hálózati tartományként. A jelentés esetében egy szűk jelentés-API kielégítheti az igényt anélkül, hogy adatbázis-adminisztrációt adna egy felhő-munkaterhelésnek.

Válasszuk külön a jelentéshez szükséges adatokat azoktól az adatoktól, amelyek csak véletlenül elérhetők. Írjuk le az engedélyezett műveleteket végpontokként és igékként ugyanabban a dokumentumban, mint az identitásdöntést. Ez a különbség a vizsgálatot túlélő integráció és az évente újra elmagyarázandó integráció között, és később újabb megbeszélés nélkül rendezi a vitákat.

Döntsük el a munkaterhelés identitását, és adjunk neki gazdát

A felügyelet nélküli feladatok nem tudnak válaszolni egy kérésre, ezért a csapatok egy személy széles fiókjához nyúlnak, majd elfelejtik. Használjunk olyan szolgáltatásfiókot vagy gépi hitelesítő adatot, amelyet a backend valóban elfogad, és jegyezzük fel, ki birtokolja, hol tárolják és hogyan cserélik.

Három feltételnek kellene a döntést dedikált identitás felé billentenie: a feladat ember jelenléte nélkül fut, a hitelesítő adat túlél egyetlen telepítést, és egynél több embernek kell tudnia a létezéséről. Ha mindhárom igaz, a megosztott emberi fiók nem rövidítés, hanem állandó kivétel, amelyet senki nem tud tisztán visszavonni.

Előnyben részesítsük azt a hitelesítő adatot, amelyet a platform ki tud adni és cserélni tud a munkaterhelés számára, például a backend által ellenőrzött munkaterhelés-identitás tokent, a konfigurációba ragasztott statikus titokkal szemben. Az alkalmazásbeállításokban lévő statikus titkok az oka annak, hogy a cserék kiesésekké válnak.

Döntsük el a hálózati hatókört, tudva, hogy az nem engedély

Határozzuk meg, melyik fél kezdeményezi a kapcsolatot, a támogatott átvitelt és az érintett végpontokat. Tartsuk bekapcsolva a partneridentitás-ellenőrzéseket, és hagyjuk a nem kapcsolódó backend célokat elérhetetlennek, ne csak be nem jelentettnek.

A szűk alagútútvonal hasznos hatókör, de nem helyettesítheti a műveletszintű engedélyezést. A backendnek a saját ellenőrzésein keresztül kell érvényesítenie a szerződést, mert a hálózat készségesen továbbít minden kérést, amely elérhető portra ér. A backend saját szerepköreit és jogosultságait vizsgáljuk, ne az útvonaltáblát. Az az útvonal, amely eléri a szervert, továbbra is a szervernél hagyja a döntést, és ott vagy érvényesül a szerződés, vagy figyelmen kívül marad.

A tükörkép is igaz: egy érvényes szolgáltatáshitelesítő adat nem indokolja, hogy minden forráshoz hallgatót publikáljunk. Mindkét ellenőrzés szükséges, és egyik sem helyettesíti a másikat.

Döntsük el az adatkezelést és a felelősség megosztását

Jegyezzük fel, mi hagyja el az ügyfél környezetét, hol dolgozza fel az alkalmazás, és a tényleges tárolási, biztonsági mentési, hozzáférési és megőrzési megoldásokat. A megőrzés az a rész, amely későn derül ki, általában amikor valaki megkérdezi, hogy az előző negyedévi másolat létezik-e még egy olyan tárolóban, amelyet senki nem dokumentált.

Tartsuk külön a feleket. Az alkalmazás üzemeltetője, a szoftverszállító és az infrastruktúra-gazda különböző felelősségeket viselhet, és a szolgáltatási modell határozza meg, ki kicsoda. Olvassuk el a tényleges megállapodást, ahelyett hogy feltételeznénk, hogy mindhármuknak azonos a hozzáférése, vagy épp semmi.

Döntsük el a hibát, az eltávolítást és azt, hogyan fogadjuk el

Osszuk ki a felelősséget a hibás esetekért, mielőtt megtörténnek. Amikor az összekötő elromlik, vagy egy identitásról kompromittálódás gyanúja merül fel, a válasz ne improvizált korlátlan hálózati kivétel legyen, amely túléli az incidenst.

Az eltávolítás ugyanolyan pontosságot érdemel, mint a beállítás. Határozzuk meg, hogyan vonják vissza az engedélyezést, hogyan ér véget az aktív hozzáférés a termék támogatott viselkedése szerint, és mi történik a megőrzött másolatokkal, amikor a kapcsolat véget ér.

Fogadjuk el az integrációt reprezentatív engedélyezett műveletekkel és a szerződés által megkövetelt elutasításokkal, mindezt a tervezett munkaterhelés-identitás alatt. Erősítsük meg a kérés útvonalát és a ténylegesen átadott adatokat, majd próbáljuk ki valóban a hitelesítő adatok cseréjét és az eltávolítást. Egy csatlakoztatott alagút bizonyítja, hogy létezik útvonal; a szerződés az, ami korlátot ad ennek az útvonalnak.