Inventar integrationsidentiteten, før du roterer den
En tjenestekonto eller API-legitimationsoplysninger repræsenterer en ikke-interaktiv adgangssti, ikke blot en streng gemt i en hemmelig manager. Inden du skriver en rotationsprocedure, skal du identificere integrationsejeren, den tilladte lejer, de tilladte operationer, hver forbruger og den forretningsmæssige arbejdsgang, der afhænger af den. En ny legitimation med det forkerte omfang kan øge eksponeringen, selvom selve rotationen gennemføres uden afbrydelse. Kravene bør derfor adressere adgangsgrænser og livscyklus sammen.
Denne artikel foreslår krav til integrering af godkendelsesplatforme. Det hævder ikke, at EmailAuth understøtter tjenestekonti, API-nøgler med omfang, overlappende legitimationsoplysninger eller nogen særlig integration af hemmelig styring. Ingen legitimationsoplysninger blev oprettet, vist, transmitteret, tilbagekaldt eller testet. Azures identitetsvejledning til flere lejere understøtter adskillelse af identitet fra ressourceautorisation og rettigheder; den faktiske platform skal dokumentere sin egen understøttede ikke-interaktive adgangsmodel.
Definer den mindste påtænkte myndighed
Opret en integrationsbeholdningsrække, der indeholder tjenesteidentiteten, forretningsformålet, lejerbinding, ressourceomfang, tilladte operationer, ejer, implementeringsplaceringer og legitimationsoplysninger. Gem kun en reference til et godkendt hemmeligt sted, ikke legitimationsværdien. Skeln skrivebeskyttet rapportering fra eksport, konfigurationsskrivning, brugeradministration og faktureringsoperationer. En bred administrativ legitimation bør ikke behandles som nødvendig, blot fordi det var praktisk under en indledende integration.
Kræv, at platformen forklarer, hvordan den autentificerede identitet er bundet til en lejer, og hvordan hver operation kontrollerer denne grænse. En lejerparameter i en URL- eller anmodningstekst er ikke autorisation i sig selv. En legitimation, der bruges til en kunde, må ikke opnå en anden kundes omfang ved at ændre en identifikator. Disse er foreslåede acceptkriterier; ingen live-tjeneste blev undersøgt, og der udledes ingen aktuel produktkapacitet ud fra kravet.
Adskil udskiftning af legitimationsoplysninger fra adgangsredesign
En rutinemæssig rotation bør normalt bevare den godkendte myndighed, mens det hemmelige materiale erstattes. Hvis migreringen også ændrer roller, lejeromfang eller ressourceadgang, skal du eksplicit gennemgå disse ændringer. Ellers kan en procedure beskrevet som vedligeholdelse skjule en adgangsudvidelse. Registrer det gamle og påtænkte nye omfang ved hjælp af ikke-hemmelige identifikatorer, og sammenlign dem før enhver autoriseret cutover.
Vælg den understøttede legitimationstype baseret på den aktuelle platformsdokumentation og organisationspolitik. En tjenestekonto, API-nøgle, certifikat eller arbejdsbelastningsidentitet kan have forskellige egenskaber for udstedelse, udløb og tilbagekaldelse. Antag ikke, at enhver integration tilbyder kortvarige legitimationsoplysninger, eller at en hemmelig administrator automatisk ændrer legitimationsoplysningerne hos måltjenesten. Målsystemet og hver forbruger skal koordineres efter deres faktiske evner.
Omfang overlappende rotation til systemer, der understøtter det
Microsofts dual-credential rotation tutorial demonstrerer et specifikt Azure Storage og Key Vault-mønster ved hjælp af to legitimationsoplysninger. Det forklarer en mekanisme til alternerende legitimationsoplysninger, mens lagret hemmeligt materiale opdateres. Det er bevis for det dokumenterede Azure-scenarie, ikke bevis på, at en vilkårlig godkendelsesplatform understøtter to samtidigt gyldige API-nøgler eller den samme rotationssekvens.
Når overlapning understøttes, bør den foreslåede plan identificere erstatningslegitimationsreferencen, forbrugerne, der skal migreres, beviset for, at hver forbruger bruger erstatningen, og det tidspunkt, hvor det gamle legitimationsoplysninger tilbagekaldes. Overlapning kan reducere afbrydelser, men det efterlader også midlertidigt mere end én brugbar legitimation. Afgrænsede dens varighed gennem en godkendt plan i stedet for at lade den gamle legitimation være aktiv på ubestemt tid. Hvis overlapning ikke understøttes, skal du dokumentere den forventede afbrydelse og autoriserede gendannelsessti i stedet for at love en problemfri cutover.
Bekræft migreringen, før du tilbagekalder den gamle sti
Definer beviser, der viser vellykket brug af erstatningen uden at afsløre den. Afhængigt af den faktiske udbyder kan dette omfatte ikke-hemmelige legitimationsoplysninger i godkendte logfiler, integrationssundhedsobservationer eller understøttede revisionsbegivenheder. En vellykket anmodning fra én medarbejder beviser ikke, at alle planlagte job, baggrundsarbejdere eller katastrofe-gendannelsesmiljøer er migreret. Lageret skal tage højde for hver forbruger eller eksplicit dokumentere dækningsgabet.
Tilbagekaldelse er et separat trin med sit eget resultatbevis. Fjernelse af en hemmelighed fra en applikations konfiguration beviser ikke, at måltjenesten har ugyldiggjort den. Omvendt kan tilbagekaldelse ved målet, før alle forbrugere migrerer, afbryde nødvendige arbejdsgange. Den autoriserede responder bør verificere den gamle stis disposition gennem understøttet dokumentation i et godkendt miljø. Dette udkast udfører ikke en anmodning ved at bruge enten en gammel eller en ny legitimationsoplysninger.
Planlæg fejl og genopretning uden blindt at genoprette eksponeringen
Definer stopbetingelser før ændringen: uventet lejeromfang, manglende revisionsbevis, ufuldstændig forbrugerbeholdning eller fejl efter migrering kan kræve, at cutover sættes på pause. Gendannelse bør skelne en rutinemæssig implementeringsfejl fra mistanke om kompromittering af legitimationsoplysninger. Genbrug af en kendt kompromitteret hemmelighed som en bekvem rollback kan genindføre selve eksponeringen, der er indeholdt. Kræv en sikkerhedsbeslutning i stedet for at behandle alle tidligere legitimationsoplysninger som sikkert gendannelsesmateriale.
Hold planen fri for hemmelige værdier. Logfiler og skærmbilleder bør ikke afsløre autorisationsoverskrifter, tokens eller komplette forbindelsesstrenge. Hvis følsomt materiale ved et uheld blotlægges, skal du lede det gennem organisationens hændelsesproces; kopier det ikke til en bredere fejlfindingskanal. Rotationsbeviser bør vise, hvem der har godkendt handlingen, hvilken ikke-hemmelig identitet, der er ændret, hvilke forbrugere der blev kontrolleret, og hvad måltjenesten rapporterer om tilbagekaldelse.
Et arbejdsark for godkendelse af legitimations-livscyklus
Opret et arbejdsark med integrationsidentitet, lejer, tilladte handlinger, hemmelig reference, forbrugerliste, aktuel legitimationsidentifikator, hvor sikker, erstatningsstrategi, godkendelsesejer, migreringstjek og tilbagekaldelsestjek. Medtag den understøttede overlapningsmodel og det maksimale planlagte overlapningsvindue som en intern beslutning, ikke en opfundet udbydergaranti. Registrer den faktiske udbyderversion eller dokumentationsdato, der er brugt til at designe sekvensen.
Vedhæft en adgangsmatrix, der dækker tilladte og nægtede læsninger, eksporter, skrivninger og livscyklusoperationer på tværs af mindst to syntetiske lejer-armaturer. Rotationen må ikke ændre disse grænser ved et uheld. Inkluder en kontrol efter rotation af, at den tilsigtede adgang stadig fungerer, og at forbudt adgang forbliver nægtet. Disse er foreslåede defensive tests, ikke udførte resultater eller tilladelse til at undersøge en produktionslejer. Hold alle originale operationelle beviser markeret åbne, indtil en autoriseret kørsel beholder den.
Fiktiv diagnose: en overset planlagt arbejdstager
En fiktiv rapporteringsintegration har en interaktiv arbejder og et natligt sammenlægningsjob. Teamet opdaterer den interaktive medarbejder til en erstatningslegitimationsoplysninger og ser vellykkede anmodninger. Det er ved at tilbagekalde den gamle legitimation, da lagergennemgangen afslører, at det planlagte job lyder på en separat hemmelig reference. Det vellykkede interaktive tjek dækkede ikke den natlige forbruger.
Det foreslåede svar er at opdatere migrationsplanen, indhente enhver nødvendig godkendelse og verificere begge forbrugere, før tilbagekaldelsen gennemføres. Hvis den gamle legitimationsoplysninger var mistænkt for kompromitteret, kan hændelsens ejer vælge øjeblikkelig indeslutning med en kontrolleret tjenesteafbrydelse i stedet. Ingen reel legitimation, arbejder eller fejl var involveret i dette fiktive eksempel. Dens formål er at skelne fuldstændig forbrugerdækning fra én vellykket anmodning.
Kræv platformsbeviset før offentliggørelse
Et nyttigt integrationskrav navngiver understøttede legitimationstyper, omfang, lejerbinding, udstedelsesbemyndigelse, overlapningsadfærd, udløb, tilbagekaldelse og revisionsbevis. Det bør angive begrænsninger klart i stedet for at oversætte en generel cloud-tutorial til et EmailAuth -funktionskrav. Kildeselvstudiets demonstrationsindstillinger er ikke universelle rotationsintervaller eller organisationspolitik.
Kataloget kræver en adgangsmatrix og negative tests for læsning, eksport, skrivning og brugerlivscyklusændringer på tværs af lejere. Disse tests forbliver uudførte. Gennemgang af menneskelig specialist, kildeanvendelighed, produktionsruter, tilgængelighed og ejerfrigivelse forbliver også åbne. Dette udkast leverer en foreslået operationel model og fiktiv øvelse, ikke legitimationsoplysninger, adgangsbevillinger eller bevis for en gennemført rotation.