Sześć decyzji do zapisania w umowie dostępu z chmury do backendu

Weźmy usługę raportową na koncie chmurowym, która potrzebuje zatwierdzonych podsumowań z wewnętrznego systemu klienta. VPN lub uwierzytelnione połączenie aplikacji chroni ścieżkę i nie rozstrzyga niczego więcej. Nie rozstrzyga, czy obciążenie raportowe może czytać niepowiązane rekordy, zmieniać backend ani zachowywać tego, co pobrało. Zapisz umowę dostępu w kategoriach operacji i danych, zanim wybierzesz łącznik, bo łącznik jest najtańszą częścią do późniejszej zmiany i najłatwiejszą do pierwszego błędu.

Rozstrzygnij operacje przed łącznikiem

Pierwsza decyzja dotyczy tego, co obciążenie może robić, nazwanego operacjami, a nie zakresem sieci. W przypadku raportowania wąskie API raportowe może zaspokoić potrzebę bez przyznawania administracji bazą danych obciążeniu chmurowemu.

Oddziel dane potrzebne raportowi od danych, które są tylko przypadkowo osiągalne. Zapisz dozwolone operacje jako punkty końcowe i czasowniki w tym samym dokumencie co decyzja o tożsamości. Ta różnica to różnica między integracją, która przechodzi audyt, a taką, którą trzeba co roku wyjaśniać od nowa, i rozstrzyga spory później bez kolejnego spotkania.

Rozstrzygnij tożsamość obciążenia i daj jej właściciela

Zadania bez nadzoru nie mogą odpowiedzieć na monit, dlatego zespoły sięgają po szerokie konto osoby, a potem o nim zapominają. Używaj konta usługi lub poświadczenia maszyny, które backend naprawdę akceptuje, i zapisz, kto je posiada, gdzie jest przechowywane i jak jest rotowane.

Trzy warunki powinny przechylić decyzję ku dedykowanej tożsamości: zadanie działa bez obecności człowieka, poświadczenie przeżywa jedno wdrożenie i więcej niż jedna osoba musi wiedzieć, że istnieje. Jeśli wszystkie trzy są prawdziwe, wspólne konto ludzkie nie jest skrótem, lecz trwałym wyjątkiem, którego nikt nie może czysto odwołać.

Preferuj poświadczenie, które platforma może wydać i rotować dla obciążenia, na przykład token tożsamości obciążenia walidowany przez backend, zamiast statycznego sekretu wklejonego w konfigurację. Statyczne sekrety w ustawieniach aplikacji są powodem, dla którego rotacje stają się awariami.

Rozstrzygnij zakres sieci, wiedząc, że to nie uprawnienie

Określ, która strona inicjuje połączenie, obsługiwany transport i zaangażowane punkty końcowe. Utrzymuj włączone kontrole tożsamości partnera i pozostaw niepowiązane cele backendu nieosiągalne, a nie tylko nieogłoszone.

Wąska trasa tunelu to użyteczny zakres, ale nie zastąpi autoryzacji na poziomie operacji. Backend musi egzekwować umowę własnymi kontrolami, bo sieć chętnie przeniesie każde żądanie, które dotrze do osiągalnego portu. Sprawdzaj własne role i uprawnienia backendu, a nie tablicę routingu. Trasa, która dociera do serwera, nadal zostawia decyzję serwerowi i tam umowa jest albo egzekwowana, albo ignorowana.

Odwrotność też jest prawdziwa: ważne poświadczenie usługi nie uzasadnia publikowania nasłuchu do każdego źródła. Potrzebne są obie kontrole i żadna nie zastępuje drugiej.

Rozstrzygnij obsługę danych i podział odpowiedzialności

Zapisz, co opuszcza środowisko klienta, gdzie aplikacja to przetwarza, oraz rzeczywiste ustalenia dotyczące przechowywania, kopii zapasowych, dostępu i retencji. Retencja to część odkrywana późno, zwykle gdy ktoś pyta, czy kopia z poprzedniego kwartału wciąż istnieje w zasobniku, którego nikt nie udokumentował.

Trzymaj strony rozdzielone. Operator aplikacji, dostawca oprogramowania i gospodarz infrastruktury mogą ponosić różne odpowiedzialności, a model usługi decyduje, kto jest kim. Przeczytaj rzeczywistą umowę, zamiast zakładać, że wszystkie trzy mają identyczny dostęp albo żaden.

Rozstrzygnij awarię, usunięcie i sposób odbioru

Przydziel odpowiedzialność za przypadki awarii, zanim się zdarzą. Gdy łącznik się psuje lub zachodzi podejrzenie naruszenia tożsamości, reakcja nie powinna być doraźnym nieograniczonym wyjątkiem sieciowym, który przeżyje incydent.

Usunięcie zasługuje na taką samą precyzję jak konfiguracja. Zdefiniuj, jak autoryzacja jest odwoływana, jak aktywny dostęp kończy się w ramach obsługiwanego zachowania produktu i co dzieje się z zachowanymi kopiami, gdy relacja się kończy.

Przyjmij integrację z reprezentatywnymi dozwolonymi operacjami i odmowami wymaganymi przez umowę, wszystko pod zamierzoną tożsamością obciążenia. Potwierdź ścieżkę żądania i faktycznie dostarczone dane, a następnie naprawdę przećwicz wymianę poświadczeń i usunięcie. Połączony tunel dowodzi, że ścieżka istnieje; umowa jest tym, co daje tej ścieżce granicę.