Seks beslutninger, der skal stå i en adgangskontrakt fra cloud til backend

Tag en rapporteringstjeneste i en cloudkonto, der har brug for godkendte resuméer fra et kundes internt system. En VPN eller en godkendt applikationsforbindelse beskytter vejen og afgør intet andet. Den afgør ikke, om rapporteringsarbejdsbyrden må læse urelaterede poster, ændre backenden eller beholde det, den hentede. Skriv adgangsaftalen i termer af operationer og data, før du vælger connectoren, for connectoren er den billigste del at ændre senere og den letteste at få forkert først.

Beslut operationerne før connectoren

Den første beslutning er, hvad arbejdsbyrden må gøre, navngivet som operationer og ikke som et netværksområde. I rapporteringstilfældet kan et smalt rapporterings-API opfylde behovet uden at give databaseadministration til en cloudarbejdsbyrde.

Adskil de data, rapporten har brug for, fra data, der blot tilfældigvis er tilgængelige. Skriv de tilladte operationer som endpoints og verber i samme dokument som identitetsbeslutningen. Den forskel er forskellen mellem en integration, der overlever en revision, og en, der skal forklares igen hvert år, og den bilægger diskussioner senere uden endnu et møde.

Beslut arbejdsbyrdens identitet, og giv den en ejer

Uovervågede jobs kan ikke svare på en prompt, og derfor griber teams efter en persons brede konto og glemmer den så. Brug en servicekonto eller en maskinlegitimationsoplysning, som backenden faktisk accepterer, og registrér, hvem der ejer den, hvor den opbevares, og hvordan den roteres.

Tre betingelser bør vippe beslutningen mod en dedikeret identitet: jobbet kører uden et menneske til stede, legitimationsoplysningen overlever en enkelt udrulning, og mere end én person skal vide, at den findes. Hvis alle tre er sande, er en delt menneskelig konto ikke en genvej, det er en permanent undtagelse, som ingen kan tilbagekalde rent.

Foretræk en legitimationsoplysning, som platformen kan udstede og rotere for arbejdsbyrden, fx et arbejdsbyrde-identitetstoken, som backenden validerer, frem for en statisk hemmelighed klistret ind i konfigurationen. Statiske hemmeligheder i applikationsindstillinger er grunden til, at rotationer bliver til afbrydelser.

Beslut netværksomfanget, vel vidende at det ikke er tilladelse

Angiv, hvilken side der starter forbindelsen, den understøttede transport og de involverede endpoints. Hold peer-identitetskontroller tændt, og lad urelaterede backend-destinationer være uopnåelige i stedet for blot ikke annoncerede.

En smal tunnelrute er et nyttigt omfang, men den kan ikke erstatte autorisation på operationsniveau. Backenden skal håndhæve kontrakten gennem sine egne kontroller, for netværket bærer villigt enhver anmodning, der når en opnåelig port. Kontrollér backendens egne roller og tildelinger i stedet for rutetabellen. En rute, der når serveren, efterlader stadig beslutningen hos serveren, og det er der, kontrakten enten håndhæves eller ignoreres.

Spejlbilledet er også sandt: en gyldig servicelegitimationsoplysning retfærdiggør ikke at udsende en lytter til enhver kilde. Begge kontroller er nødvendige, og ingen erstatter den anden.

Beslut datahåndteringen og ansvarsfordelingen

Registrér, hvad der forlader kundens miljø, hvor applikationen behandler det, og de faktiske forhold for lagring, backup, adgang og opbevaring. Opbevaring er den del, der opdages sent, normalt når nogen spørger, om kopien fra sidste kvartal stadig findes i en bucket, som ingen dokumenterede.

Hold parterne adskilt. Applikationsoperatøren, softwareleverandøren og infrastrukturværten kan bære forskellige ansvar, og servicemodellen afgør, hvem der er hvem. Læs den faktiske aftale i stedet for at antage, at alle tre har identisk adgang, eller slet ingen.

Beslut fejl, fjernelse og hvordan du accepterer det

Tildel ansvar for fejltilfældene, før de sker. Når connectoren går i stykker, eller en identitet mistænkes for at være kompromitteret, bør svaret ikke være en improviseret ubegrænset netværksundtagelse, der overlever hændelsen.

Fjernelse fortjener samme præcision som opsætning. Definer, hvordan autorisation tilbagekaldes, hvordan aktiv adgang slutter inden for produktets understøttede adfærd, og hvad der sker med opbevarede kopier, når forholdet slutter.

Acceptér integrationen med repræsentative tilladte operationer og de afvisninger, kontrakten kræver, alt under den tilsigtede arbejdsbyrdeidentitet. Bekræft anmodningsvejen og de faktisk leverede data, og afprøv derefter udskiftning af legitimationsoplysninger og fjernelse i virkeligheden. En forbundet tunnel beviser, at der findes en vej; kontrakten er det, der giver den vej en grænse.