En export skapar en annan behörighetsgräns
En delad analysdestination kan kombinera data från flera kunder samtidigt som den kräver att varje kunds information förblir isolerad. Källapplikationens användarkontroller överförs inte automatiskt till en fil, lagertabell, instrumentpanel eller schemalagd rapport. Ett exportkrav måste därför omfatta val av källa, transformation, destinationsåtkomst, nedströmsanvändning och radering. En korrekt autentiserad exportarbetare kan fortfarande avslöja fel hyresgästs data om något av dessa beslut är fel.
Azures identitetsvägledning för multitenant separerar autentisering, auktorisering och rättigheter och diskuterar hyresgästspecifika federationsrisker. Det stöder att ställa exakta frågor om hyresgästbindning, men det fastställer inte att EmailAuth implementerar någon särskild exportkontroll. Detta manuskript föreslår krav och fixturbaserad verifiering. Ingen export genererades, kunddata åtkoms, destinationsbehörighet beviljades eller analyssystem konfigurerats.
Bind källvalet till den auktoriserade hyresgästen
Dokumentera exportbegäraren, autentiserad tjänst eller användaridentitet, tillåten hyresgästuppsättning, begärda resurser och godkänt affärssyfte. Källan måste bestämma auktoriserad omfattning från en pålitlig relation, inte bara acceptera en kundidentifierare som tillhandahålls av den som ringer. En begäranparameter kan identifiera den önskade hyresgästen utan att bevisa att den som ringer kan komma åt den. Auktorisationsbeslutet bör omfatta varje resurs som ingår i utdata, inklusive relaterade poster som sammanfogats under bearbetningen.
Ange hur ansökan hanterar en begärande som tillhör mer än en hyresgäst. Att välja en hyresgäst i ett användargränssnitt bör inte tyst bli en obegränsad export över flera kunder. Registrera om exporten är en hyresgäst, ett explicit auktoriserat administrativt jobb med flera hyresgäster eller en aggregerad datauppsättning med en separat godkänd omfattning. Dessa är föreslagna kategorier för kravdokumentet, inte påståenden om att en viss plattform exponerar dem.
Bevara hyresgästens sammanhang genom transformationer
En hyresgästgräns kan gå förlorad efter en initialt korrekt fråga. En koppling kan använda en domänsträng som inte är unik över den avsedda historiska modellen, ett cachat resultat kan utelämna klientkontext eller en senare aggregering kan kombinera rader utanför det godkända omfånget. Kraven bör ange hur hyresgästens identitet följer med varje post genom utvinning, transformation och produktion. Lita inte på målmappens namn som den enda isoleringsmekanismen.
Använd stabila interna identifierare där det stöds och behåll deras mappningshärkomst. Ett visningsnamn, e-postadress eller domänetikett kan ändras och bör inte antas vara en globalt unik kundnyckel. Om aggregering av flera hyresgäster uttryckligen är tillåten, definiera den tillåtna grupperingen, bibehållna dimensioner och avslöjanderisken. Att ta bort en synlig kundkolumn anonymiserar inte nödvändigtvis data; sällsynta kombinationer och detaljer kan fortfarande avslöja enskilda organisationer eller arbetsflöden.
Behandla destinationsåtkomst som ett separat beslut
Registrera destinationssystemet, lagringsplatsen, tillåtna läsare, administratörer, tjänstidentiteter, lagringspolicy och eventuell vidaredelning. En privat källapplikation kan inte kompensera för en export som placeras i en brett tillgänglig analysarbetsyta. Tillgång till destinationen bör matcha det godkända syftet och dataomfattningen. Anta inte att en delad instrumentpanels filter på radnivå också skyddar nedladdningsbar underliggande data eller alla alternativa frågegränssnitt.
Kräv att destinationsägaren beskriver de faktiska tillsynskontrollerna och negativa tester som stöds. Dessa kan skilja sig åt mellan filer, databaser och analysprodukter. Manuskriptet uppfinner inte en universell säkerhetsfunktion på radnivå eller hävdar att en kontrollpanel på instrumentpanelen skyddar alla exportformat. Ett publicerbart implementeringsexempel måste identifiera den verkliga destinationen, dess nuvarande konfiguration och bevis som visar att obehöriga läsare inte kan komma åt en annan hyresgästs register.
Minimera och redigera med diagnostiskt värde i åtanke
Definiera de minsta fält som behövs för analysändamålet. Autentiseringsrapportering kan innehålla domäner, sändningsinfrastruktur, meddelanderelaterade identifierare och operativt sammanhang som kunder betraktar som konfidentiella. Ta bort onödiga personliga eller känsliga fält innan du delar, samtidigt som du behåller de dimensioner som behövs för att förklara måttet. En redaktionsplan ska dokumentera vilka samband som förblir synliga och vilka tolkningar som inte längre är möjliga efter redigering.
Använd syntetiska fixturer för acceptanstesterna som föreslås här. Syntetisk data bör kunna särskiljas av hyresgästen och inkludera avsiktliga kantfall som liknande visningsnamn, delade leverantörsetiketter och historisk domänomtilldelning. Kopiera inte produktionsrader till ett test bara för att namnen senare kommer att döljas. En redigerad produktion är ett bevis på ett transformationsresultat, inte ett bevis på att varje framtida export kommer att förbli inom räckvidden.
Ett kalkylblad för exportgräns
Skapa ett kalkylblad med begärandeidentitet, källhyresgästbindning, auktoriserad resursuppsättning, fråga eller jobbversion, fältlista, omvandlingsregler, destination, tillåtna läsare och retentionsägare. Lägg till bevisreferenser för varje gräns istället för en enda "export säker" kryssruta. Registrera godkännandet för alla datauppsättningar med flera hyresgäster separat från godkännandet för vanlig hyresgästrapportering. Den avsedda publiken och syftet bör förbli synliga under hela skivan.
Verifieringssektionen bör identifiera fixturhyresgästerna, förväntade valda rader, exkluderade rader, redaktionsförväntningar och destinationsåtkomsttester. Inkludera ett fall där en uppringare tillhandahåller en annan hyresgästs identifierare och ett fall där en destinationsläsare försöker en otillåten borrning eller nedladdning. Dessa är föreslagna tester som endast körs med auktorisation i en kontrollerad miljö. Ingen förfrågan mellan klienter eller destinationsåtkomst utfördes under detta arbete.
Fiktiv diagnos: en korrekt fråga och en bred arbetsyta
Ett fiktivt team exporterar en kunds autentiseringssammanfattning med hjälp av rätt källfilter. Resultatet placeras sedan i en delad analysarbetsyta vars tittare inkluderar personal som tilldelats andra kunder. Källfrågan är korrekt, men destinationsåtkomsten matchar inte den avsedda målgruppen. Teamet kan inte förklara exporten säker genom att bara visa källfiltret.
Den föreslagna granskningen spårar båda gränserna och ber destinationsägaren att verifiera åtkomsten med hjälp av syntetiska fixturer. Den kontrollerar också om underliggande nedladdningar och schemalagd distribution följer samma begränsningar som den synliga instrumentpanelen. Det här scenariot är fiktivt, inte ett observerat avslöjande eller ett påstående om en namngiven analystjänst. Ingen riktig kunddata exporterades eller delades. Lärdomen är att källans korrekthet och destinationssekretess är oberoende acceptanskriterier.
Täck livscykelförändringar och repeterbara jobb
Schemalagda exporter kräver ett aktuellt auktorisationsbeslut, inte bara det godkännande som fanns när jobbet skapades. En kund kan lämna, en anställd kan byta roll eller en målgrupp kan expandera. Definiera hur dessa ändringar påverkar jobbet och hur inaktuell åtkomst upptäcks. RFC 7643 beskriver användaradministrativ status samtidigt som den lämnar dess definitiva betydelse till tjänsteleverantören; en livscykeluppdatering bör inte antas återkalla varje schemalagd export- eller destinationsbehörighet automatiskt.
Registrera vem som äger periodisk granskning och vad som utlöser en omedelbar omprövning. Inkludera ändringar av klientmappning, frågelogik, destinationsbehörigheter och redaktionsregler. Bevara jobbversioner och bevis så att en senare granskare kan rekonstruera vad som valdes ut och vem som kunde ta emot det. Lova inte att ett enda negativt test bevisar isolering under varje framtida konfiguration.
Släpp endast med bevis från flera hyresgäster
Katalogen kräver fixturer med flera hyresgäster som verifierar val av källa, destinationsåtkomst och redigerad utdata. Det beviset förblir öppet. Detta utkast tillhandahåller det föreslagna kalkylbladet och det fiktiva exemplet, inte testfixturer, exporterade filer eller åtkomstresultat. Det gör inga anspråk på att EmailAuth eller en destinationsprodukt redan implementerar dessa krav.
Granskning av mänskliga specialister, källans tillämplighet, produktionsvägar, visuell tillgänglighet och ägarfrigivning förblir också öppna. En publicerbar implementering behöver auktoriserade syntetiska fixturer, bibehållna utdata, dokumenterade käll- och destinationskonfigurationer och faktiska negativa resultat. Det resulterande beviset bör visa hela vägen från godkänd omfattning till tillåten publik utan att samla in riktiga hyresgästhemligheter eller avslöja kunddata.