Säkerhetsöversikt för Azure AI Search
I den här artikeln beskrivs säkerhetsfunktionerna i Azure AI Search som skyddar data och åtgärder.
Dataflöde (nätverkstrafikmönster)
En Azure AI-usluga pretrage finns i Azure och används vanligtvis av klientprogram via offentliga nätverksanslutningar. Även om det mönstret är dominerande är det inte det enda trafikmönstret som du behöver bry dig om. Att förstå alla startpunkter samt utgående trafik är en nödvändig bakgrund för att skydda dina utvecklings- och produktionsmiljöer.
Azure AI Search har tre grundläggande nätverkstrafikmönster:
- Inkommande begäranden som görs av en användare eller klient till söktjänsten (det dominerande mönstret)
- Utgående begäranden som utfärdats av söktjänsten till andra tjänster i Azure och på andra platser
- Interna service-to-service-begäranden via det säkra Microsoft-stamnätverket
Inkommande trafik
Inkommande begäranden som riktar sig till en slutpunkt för söktjänsten inkluderar:
- Skapa, läsa, uppdatera eller ta bort index och andra objekt i söktjänsten
- Läsa in ett index med sökdokument
- Fråga ett index
- Utlösa indexerare eller kompetensuppsättningskörning
REST-API :erna beskriver alla inkommande begäranden som hanteras av en söktjänst.
Som minst måste alla inkommande begäranden autentiseras med något av följande alternativ:
- Nyckelbaserad autentisering (standard). Inkommande begäranden ger en giltig API-nyckel.
- Rollbaserad åtkomstkontroll. Auktorisering sker via Microsoft Entra-identiteter och rolltilldelningar i din söktjänst.
Dessutom kan du lägga till nätverkssäkerhetsfunktioner för att ytterligare begränsa åtkomsten till slutpunkten. Du kan skapa regler för inkommande trafik i en IP-brandvägg eller skapa privata slutpunkter som helt skyddar din söktjänst från det offentliga Internet.
Intern trafik
Interna begäranden skyddas och hanteras av Microsoft. Du kan inte konfigurera eller kontrollera dessa anslutningar. Om du låser nätverksåtkomsten krävs ingen åtgärd från din sida eftersom intern trafik inte kan konfigureras av kunden.
Intern trafik består av:
- Tjänst-till-tjänst-anrop för uppgifter som autentisering och auktorisering via Microsoft Entra-ID, resursloggning som skickas till Azure Monitor och privata slutpunktsanslutningar som använder Azure Private Link.
- Förfrågningar till API:er för Azure AI-tjänster för inbyggda kunskaper
- Begäranden som görs till maskininlärningsmodeller som stöder semantisk rangordning.
Utgående trafik
Utgående begäranden kan skyddas och hanteras av dig. Utgående begäranden kommer från en söktjänst till andra program. Dessa begäranden görs vanligtvis av indexerare för textbaserad indexering, anpassad kompetensbaserad AI-berikning och vektoriseringar vid frågetillfället. Utgående begäranden omfattar både läs- och skrivåtgärder.
Följande lista är en fullständig uppräkning av de utgående begäranden som du kan konfigurera säkra anslutningar för. En söktjänst gör begäranden för egen räkning och för en indexerare eller anpassad kompetens.
| Åtgärd | Scenario |
|---|---|
| Indexerare | Anslut till externa datakällor för att hämta data. Mer information finns i Indexer-åtkomst till innehåll som skyddas av Azure-nätverkssäkerhet. |
| Indexerare | Anslut till Azure Storage för att bevara kunskapslager, cachelagrade berikanden, felsökningssessioner. |
| Anpassade färdigheter | Anslut till Azure-funktioner, Azure-webbappar eller andra appar som kör extern kod som hanteras utanför tjänsten. Begäran om extern bearbetning skickas under körningen av kompetensuppsättningen. |
| Indexerare och integrerad vektorisering | Anslut till Azure OpenAI och en distribuerad inbäddningsmodell, eller så går den igenom en anpassad färdighet för att ansluta till en inbäddningsmodell som du tillhandahåller. Söktjänsten skickar text till inbäddningsmodeller för vektorisering under indexering. |
| Vektoriserare | Anslut till Azure OpenAI eller andra inbäddningsmodeller vid frågetillfället för att konvertera användartextsträngar till vektorer för vektorsökning. |
| Söktjänst | Anslut till Azure Key Vault för kundhanterade krypteringsnycklar som används för att kryptera och dekryptera känsliga data. |
Utgående anslutningar kan göras med hjälp av en resurs fullständiga åtkomst niska veze som innehåller en nyckel eller en databasinloggning eller en hanterad identitet om du använder Microsoft Entra-ID och rollbaserad åtkomst.
Om du vill nå Azure-resurser bakom en brandvägg skapar du inkommande regler för andra Azure-resurser som tar emot söktjänstbegäranden.
Om du vill nå Azure-resurser som skyddas av Azure Private Link skapar du en delad privat länk som en indexerare använder för att upprätta sin anslutning.
Undantag för sök- och lagringstjänster i samma region
Om Azure Storage och Azure AI Search finns i samma region dirigeras nätverkstrafiken via en privat IP-adress och sker via Microsofts stamnätverk. Eftersom privata IP-adresser används kan du inte konfigurera IP-brandväggar eller en privat slutpunkt för nätverkssäkerhet.
Konfigurera anslutningar i samma region med någon av följande metoder:
Nätverkssäkerhet
Nätverkssäkerhet skyddar resurser från obehörig åtkomst eller angrepp genom att tillämpa kontroller på nätverkstrafik. Azure AI Search stöder nätverksfunktioner som kan vara din frontlinje för skydd mot obehörig åtkomst.
Inkommande anslutning via IP-brandväggar
En söktjänst etableras med en offentlig slutpunkt som tillåter åtkomst med hjälp av en offentlig IP-adress. Om du vill begränsa vilken trafik som kommer via den offentliga slutpunkten skapar du en regel för inkommande brandvägg som tar emot begäranden från en specifik IP-adress eller ett intervall med IP-adresser. Alla klientanslutningar måste göras via en tillåten IP-adress eller så nekas anslutningen.
Du kan använda portalen för att konfigurera brandväggsåtkomst.
Du kan också använda REST-API:er för hantering. Från och med API-version 2020-03-13 med parametern IpRule kan du begränsa åtkomsten till din tjänst genom att identifiera IP-adresser, individuellt eller inom ett intervall, som du vill bevilja åtkomst till din söktjänst.
Inkommande anslutning till en privat slutpunkt (nätverksisolering, ingen Internettrafik)
För striktare säkerhet kan du upprätta en privat slutpunkt för Azure AI Search så att en klient i ett virtuellt nätverk på ett säkert sätt kan komma åt data i ett sökindex via en Private Link.
Den privata slutpunkten använder en IP-adress från det virtuella nätverkets adressutrymme för anslutningar till söktjänsten. Nätverkstrafiken mellan klienten och söktjänsten passerar över det virtuella nätverket och en privat länk i Microsofts stamnätverk, vilket eliminerar exponeringen från det offentliga Internet. Ett virtuellt nätverk möjliggör säker kommunikation mellan resurser, med ditt lokala nätverk och Internet.
Även om den här lösningen är den säkraste, är det en extra kostnad att använda fler tjänster, så se till att du har en tydlig förståelse för fördelarna innan du dyker in. Mer information om kostnader finns på prissidan. Mer information om hur dessa komponenter fungerar tillsammans finns i den här videon. Täckningen av det privata slutpunktsalternativet börjar kl. 5:48 in i videon. Anvisningar om hur du konfigurerar slutpunkten finns i Skapa en privat slutpunkt för Azure AI Search.
Autentisering
När en begäran har godkänts för söktjänsten måste den fortfarande genomgå autentisering och auktorisering som avgör om begäran är tillåten. Azure AI Search har stöd för två metoder:
Microsoft Entra-autentisering upprättar anroparen (och inte begäran) som den autentiserade identiteten. En Azure-rolltilldelning avgör auktorisering.
Nyckelbaserad autentisering utförs på begäran (inte den anropande appen eller användaren) via en API-nyckel, där nyckeln är en sträng som består av slumpmässigt genererade siffror och bokstäver som bevisar att begäran kommer från en tillförlitlig källa. Nycklar krävs för varje begäran. Att skicka en giltig nyckel anses vara ett bevis på att begäran kommer från en betrodd entitet.
Du kan använda båda autentiseringsmetoderna eller inaktivera en metod som du inte vill ska vara tillgänglig i söktjänsten.
Auktorisering
Azure AI Search tillhandahåller auktoriseringsmodeller för tjänsthantering och innehållshantering.
Auktorisera tjänsthantering
Resurshantering auktoriseras via rollbaserad åtkomstkontroll i din Microsoft Entra-klientorganisation.
I Azure AI Search används Resource Manager för att skapa eller ta bort tjänsten, hantera API-nycklar, skala tjänsten och konfigurera säkerhet. Därför avgör Azure-rolltilldelningar vem som kan utföra dessa uppgifter, oavsett om de använder portalen, PowerShell eller REST-API:erna för hantering.
Tre grundläggande roller (ägare, deltagare, läsare) gäller för söktjänstadministration. Rolltilldelningar kan göras med alla metoder som stöds (portalen, PowerShell och så vidare) och respekteras i hela tjänsten.
Kommentar
Med hjälp av Azure-omfattande mekanismer kan du låsa en prenumeration eller resurs för att förhindra oavsiktlig eller obehörig borttagning av din söktjänst av användare med administratörsbehörighet. Mer information finns i Låsa resurser för att förhindra oväntad borttagning.
Auktorisera åtkomst till innehåll
Innehållshantering refererar till de objekt som skapas och finns i en söktjänst.
För rollbaserad auktorisering använder du Azure-rolltilldelningar för att upprätta läs- och skrivåtkomst till åtgärder.
För nyckelbaserad auktorisering avgör en API-nyckel och en kvalificerad slutpunkt åtkomst. En slutpunkt kan vara själva tjänsten, indexsamlingen, ett specifikt index, en dokumentsamling eller ett specifikt dokument. När slutpunkten, åtgärden (till exempel en create-begäran) och typen av nyckel (administratör eller fråga) länkas samman, auktoriseras åtkomst till innehåll och åtgärder.
Begränsa åtkomsten till index
Med Hjälp av Azure-roller kan du ange behörigheter för enskilda index så länge det görs programmatiskt.
Med hjälp av nycklar kan alla som har en administratörsnyckel till din tjänst läsa, ändra eller ta bort alla index i samma tjänst. För skydd mot oavsiktlig eller skadlig borttagning av index är din interna källkodskontroll för kodtillgångar lösningen för att återställa en oönskad borttagning eller ändring av index. Azure AI Search har redundans i klustret för att säkerställa tillgänglighet, men den lagrar eller kör inte din egen kod som används för att skapa eller läsa in index.
För lösningar för flera innehavare som kräver säkerhetsgränser på indexnivå är det vanligt att hantera indexisolering på mellannivån i programkoden. Mer information om användningsfallet för flera klienter finns i Designmönster för SaaS-program med flera klienter och Azure AI Search.
Begränsa åtkomsten till dokument
Användarbehörigheter på dokumentnivå, även kallat säkerhet på radnivå, stöds inte internt i Azure AI Search. Om du importerar data från ett externt system som ger säkerhet på radnivå, till exempel Azure Cosmos DB, överförs inte dessa behörigheter med data eftersom de indexeras av Azure AI Search.
Om du behöver behörighet för innehåll i sökresultat finns det en teknik för att tillämpa filter som inkluderar eller exkluderar dokument baserat på användaridentitet. Den här lösningen lägger till ett strängfält i datakällan som representerar en grupp eller användaridentitet som du kan filtrera i ditt index. Mer information om det här mönstret finns i Säkerhetstrimning baserat på identitetsfilter.
Dataresidens
När du konfigurerar en söktjänst väljer du en region som avgör var kunddata lagras och bearbetas. Varje region finns inom ett geografiskt område (Geo) som ofta innehåller flera regioner (till exempel är Schweiz en geo som innehåller Schweiz, norra och Schweiz, västra). Azure AI Search kan replikera dina data till en annan region inom samma geo för hållbarhet och hög tillgänglighet. Tjänsten lagrar eller bearbetar inte kunddata utanför din angivna geo om du inte konfigurerar en funktion som är beroende av en annan Azure-resurs och den resursen etableras i en annan region.
För närvarande är Azure Storage den enda externa resurs som en söktjänst skriver till. Lagringskontot är ett som du anger, och det kan finnas i vilken region som helst. En söktjänst skriver till Azure Storage om du använder någon av följande funktioner:
Mer information om datahemvist finns i datahemvist i Azure.
Undantag från åtaganden för datahemvist
Objektnamn visas i telemetriloggarna som används av Microsoft för att ge support för tjänsten. Objektnamn lagras och bearbetas utanför den valda regionen eller platsen. Objektnamn omfattar namnen på index och indexfält, alias, indexerare, datakällor, kompetensuppsättningar, synonymkartor, resurser, containrar och nyckelvalvsarkiv. Kunder bör inte placera känsliga data i namnfält eller skapa program som är utformade för att lagra känsliga data i dessa fält.
Telemetriloggar behålls i ett och ett halvt år. Under den perioden kan Microsoft komma åt och referera till objektnamn under följande villkor:
Diagnostisera ett problem, förbättra en funktion eller åtgärda en bugg. I det här scenariot är dataåtkomst endast intern, utan åtkomst från tredje part.
Under supporten kan den här informationen användas för att snabbt lösa problem och eskalera produktteamet om det behövs
Dataskydd
På lagringslagret är datakryptering inbyggt för allt tjänsthanterat innehåll som sparats på disken, inklusive index, synonymkartor och definitioner av indexerare, datakällor och kompetensuppsättningar. Tjänsthanterad kryptering gäller både långsiktig datalagring och tillfällig datalagring.
Du kan också lägga till kundhanterade nycklar (CMK) för kompletterande kryptering av indexerat innehåll för dubbel kryptering av vilande data. För tjänster som skapats efter den 1 augusti 2020 utökas CMK-krypteringen till kortsiktiga data på tillfälliga diskar.
Data under överföring
För söktjänstanslutningar via offentligt Internet lyssnar Azure AI Search på HTTPS-port 443.
Azure AI Search stöder TLS 1.2 och 1.3 för kanalkryptering från klient till tjänst:
- TLS 1.3 är standardvärdet för nyare klientoperativsystem och versioner av .NET.
- TLS 1.2 är standard för äldre system, men du kan uttryckligen ange TLS 1.3 på en klientbegäran.
Tidigare versioner av TLS (1.0 eller 1.1) stöds inte.
Mer information finns i TLS-stöd i .NET Framework.
Vilande data
För data som hanteras internt av söktjänsten beskriver följande tabell datakrypteringsmodellerna. Vissa funktioner, till exempel kunskapslager, inkrementell berikning och indexeringsbaserad indexering, läsning från eller skrivning till datastrukturer i andra Azure-tjänster. Tjänster som är beroende av Azure Storage kan använda krypteringsfunktionerna i den tekniken.
| Modell | Nycklar | Krav | Begränsningar | Gäller för |
|---|---|---|---|---|
| kryptering på serversidan | Microsoft-hanterade nycklar | Ingen (inbyggd) | Ingen, tillgänglig på alla nivåer, i alla regioner, för innehåll som skapats efter den 24 januari 2018. | Innehåll (index och synonymkartor) och definitioner (indexerare, datakällor, kompetensuppsättningar), på datadiskar och temporära diskar |
| kryptering på serversidan | kundhanterade nycklar | Azure Key Vault | Tillgängligt på fakturerbara nivåer, i specifika regioner, för innehåll som skapats efter den 1 augusti 2020. | Innehåll (index och synonymkartor) på datadiskar |
| fullständig kryptering på serversidan | kundhanterade nycklar | Azure Key Vault | Tillgänglig på fakturerbara nivåer, i alla regioner, på söktjänster efter den 13 maj 2021. | Innehåll (index och synonymkartor) på datadiskar och temporära diskar |
Tjänsthanterade nycklar
Tjänsthanterad kryptering är en Microsoft-intern åtgärd som använder 256-bitars AES-kryptering. Det sker automatiskt vid all indexering, inklusive vid inkrementella uppdateringar av index som inte är helt krypterade (skapade före januari 2018).
Tjänsthanterad kryptering gäller för allt innehåll på långsiktig och kortsiktig lagring.
Kundhanterade nycklar (CMK)
Kundhanterade nycklar kräver en annan fakturerbar tjänst, Azure Key Vault, som kan finnas i en annan region, men under samma prenumeration, som Azure AI Search.
CMK-stöd distribuerades i två faser. Om du skapade söktjänsten under den första fasen begränsades CMK-krypteringen till långsiktig lagring och specifika regioner. Tjänster som skapas i den andra fasen, efter maj 2021, kan använda CMK-kryptering i valfri region. Som en del av den andra vågdistributionen är innehållet CMK-krypterat på både långsiktig och kortsiktig lagring. Mer information om CMK-stöd finns i fullständig dubbelkryptering.
Om du aktiverar CMK-kryptering ökar indexstorleken och försämrar frågeprestandan. Baserat på observationer hittills kan du förvänta dig att se en ökning med 30–60 procent i frågetider, även om den faktiska prestandan varierar beroende på indexdefinitionen och typerna av frågor. På grund av den negativa prestandapåverkan rekommenderar vi att du bara aktiverar den här funktionen på index som verkligen kräver den. Mer information finns i Konfigurera kundhanterade krypteringsnycklar i Azure AI Search.
Säkerhetsadministration
Hantera API-nycklar
Beroende av API-nyckelbaserad autentisering innebär det att du bör ha en plan för att återskapa administratörsnyckeln med jämna mellanrum, enligt metodtips för Azure-säkerhet. Det finns högst två administratörsnycklar per söktjänst. Mer information om hur du skyddar och hanterar API-nycklar finns i Skapa och hantera API-nycklar.
Aktivitets- och resursloggar
Azure AI Search loggar inte användaridentiteter så du kan inte referera till loggar för information om en specifik användare. Tjänsten loggar dock åtgärderna create-read-update-delete, som du kanske kan korrelera med andra loggar för att förstå agenturen för specifika åtgärder.
Med hjälp av aviseringar och loggningsinfrastrukturen i Azure kan du ta upp frågevolymtoppar eller andra åtgärder som avviker från förväntade arbetsbelastningar. Mer information om hur du konfigurerar loggar finns i Samla in och analysera loggdata och Övervaka frågebegäranden.
Certifieringar och efterlevnad
Azure AI Search deltar i regelbundna granskningar och har certifierats mot många globala, regionala och branschspecifika standarder för både det offentliga molnet och Azure Government. För den fullständiga listan laddar du ned white paper för Microsoft Azure Efterlevnadserbjudanden från den officiella sidan Granskningsrapporter.
För efterlevnad kan du använda Azure Policy för att implementera bästa praxis med hög säkerhet i Microsofts prestandamått för molnsäkerhet. Microsoft cloud security benchmark är en samling säkerhetsrekommendationer som kodifierats i säkerhetskontroller som mappar till viktiga åtgärder som du bör vidta för att minimera hot mot tjänster och data. Det finns för närvarande 12 säkerhetskontroller, inklusive nätverkssäkerhet, loggning och övervakning samt dataskydd.
Azure Policy är en funktion som är inbyggd i Azure och som hjälper dig att hantera efterlevnad för flera standarder, inklusive microsofts prestandamått för molnsäkerhet. För välkända riktmärken tillhandahåller Azure Policy inbyggda definitioner som ger både kriterier och ett åtgärdsbart svar som åtgärdar inkompatibilitet.
För Azure AI Search finns det för närvarande en inbyggd definition. Det är för resursloggning. Du kan tilldela en princip som identifierar söktjänster som saknar resursloggning och sedan aktivera den. Mer information finns i Kontroller för regelefterlevnad i Azure Policy för Azure AI Search.
Titta på den här videon
Titta på den här snabba videon för en översikt över säkerhetsarkitekturen och varje funktionskategori.