Säkerhetsöversikt för Azure Cognitive Search

Den här artikeln beskriver säkerhetsfunktionerna i Azure Cognitive Search som skyddar data och åtgärder.

Dataflöde (nätverkstrafikmönster)

En Cognitive tjänsten Search 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 ingångspunkter samt utgående trafik är en nödvändig bakgrund för att skydda dina utvecklings- och produktionsmiljöer.

Cognitive Search har tre grundläggande nätverkstrafikmönster:

  • Inkommande begäranden som görs av en 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 tjänst-till-tjänst-begäranden över det säkra Microsoft-stamnätverket

Inkommande trafik

Inkommande begäranden som riktar sig till en slutpunkt för söktjänsten kan karakteriseras som:

  • Skapa eller hantera index, indexerare, datakällor, kompetensuppsättningar och synonymkartor
  • Anropa körning av indexerare eller kompetensuppsättning
  • Läsa in eller köra frågor mot ett index

Du kan granska REST-API:erna för att förstå alla inkommande begäranden som hanteras av en söktjänst.

Som minst måste alla inkommande begäranden autentiseras:

  • Nyckelbaserad autentisering är standard. Inkommande begäranden som innehåller en giltig API-nyckel accepteras av söktjänsten som kommer från en betrodd part.
  • Du kan också använda Azure Active Directory och rollbaserad åtkomstkontroll för dataplansåtgärder (för närvarande i förhandsversion).

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 söktjänsten från det offentliga Internet.

Utgående trafik

Utgående begäranden från en söktjänst till andra program görs vanligtvis av indexerare för textbaserad indexering och vissa aspekter av AI-berikning. Utgående begäranden omfattar både läs- och skrivåtgärder.

Följande lista är en fullständig uppräkning av utgående begäranden som kan göras av en söktjänst. En sökning gör begäranden för egen räkning och för en indexerare eller anpassad färdighet:

  • Indexerare läser från externa datakällor.
  • Indexerare skriver till Azure Storage när de skapar kunskapslager, bevarar cachelagrade berikanden och bevarar felsökningssessioner.
  • Om du använder anpassade kunskaper ansluter anpassade färdigheter till en extern Azure-funktion eller -app för att köra extern kod som är värdbaserad utanför tjänsten. Begäran om extern bearbetning skickas under körningen av kompetensuppsättningen.
  • Om du använder kundhanterade nycklar ansluter tjänsten till en extern Azure-Key Vault för en kundhanterad nyckel som används för att kryptera och dekryptera känsliga data.

Utgående anslutningar kan göras med hjälp av en resurs anslutningssträng med fullständig åtkomst som innehåller en nyckel eller en databasinloggning, eller en Azure AD inloggning (en hanterad identitet) om du använder Azure Active Directory.

Om din Azure-resurs finns bakom en brandvägg måste du skapa regler som tar emot söktjänstbegäranden. För resurser som skyddas av Azure Private Link kan du skapa 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 Lagring och sökning 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. Använd i stället undantaget för betrodda tjänster som ett alternativ när båda tjänsterna finns i samma region.

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 Azure Active Directory, resursloggning som skickas till Azure Monitor och privata slutpunktsanslutningar som använder Azure Private Link.
  • Begäranden som görs till API:er för Cognitive Services för inbyggda kunskaper.
  • Begäranden till maskininlärningsmodeller som stöder semantisk sökning.

Nätverkssäkerhet

Nätverkssäkerhet skyddar resurser från obehörig åtkomst eller angrepp genom att tillämpa kontroller på nätverkstrafik. Azure Cognitive Search stöder nätverksfunktioner som kan vara din första försvarslinje 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 brandväggsregel för inkommande trafik 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.

exempel på arkitekturdiagram för ip-begränsad åtkomst

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 i ett intervall, som du vill bevilja åtkomst till din söktjänst.

Inkommande anslutning till en privat slutpunkt (nätverksisolering, ingen Internettrafik)

För strängare säkerhet kan du upprätta en privat slutpunkt för Azure Cognitive Search gör att en klient i ett virtuellt nätverk på ett säkert sätt kan komma åt data i ett sökindex över 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ätverkstrafik mellan klienten och söktjänsten passerar över det virtuella nätverket och en privat länk i Microsofts stamnätverk, vilket eliminerar exponering från det offentliga Internet. Ett virtuellt nätverk möjliggör säker kommunikation mellan resurser, med ditt lokala nätverk och med Internet.

exempelarkitekturdiagram för åtkomst till privat slutpunkt

Även om den här lösningen är den säkraste, är det en extra kostnad att använda ytterligare 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å prissättningssidan. Mer information om hur dessa komponenter fungerar tillsammans finns i den här videon. Täckningen av det privata slutpunktsalternativet börjar 5:48 in i videon. Anvisningar om hur du konfigurerar slutpunkten finns i Skapa en privat slutpunkt för Azure Cognitive Search.

Autentisering

När en begäran har godkänts måste den fortfarande genomgå autentisering och auktorisering som avgör om begäran är tillåten. Kognitiv sökning har stöd för två metoder:

  • 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 betrodd 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.

  • Azure AD autentisering (förhandsversion) upprättar anroparen (och inte begäran) som den autentiserade identiteten. En Azure-rolltilldelning avgör vilken åtgärd som tillåts.

Utgående begäranden som görs av en indexerare omfattas av de autentiseringsprotokoll som stöds av den externa tjänsten. En söktjänst kan göras till en betrodd tjänst i Azure och ansluta till andra tjänster med hjälp av ett system eller en användartilldelad hanterad identitet. Mer information finns i Konfigurera en indexerareanslutning till en datakälla med hjälp av en hanterad identitet.

Auktorisering

Cognitive Search tillhandahåller olika auktoriseringsmodeller för innehållshantering och tjänsthantering.

Auktorisering för innehållshantering

Om du använder nyckelbaserad autentisering tilldelas auktorisering för innehållsåtgärder via typen av API-nyckel för begäran:

  • Admin nyckel (tillåter läs- och skrivåtkomst för åtgärderna create-read-update-delete i söktjänsten) som skapas när tjänsten etableras

  • Frågenyckel (tillåter skrivskyddad åtkomst till dokumentsamlingen för ett index), skapas efter behov och är utformade för klientprogram som utfärdar frågor

I programkod anger du slutpunkten och en API-nyckel för att tillåta åtkomst till innehåll och alternativ. En slutpunkt kan vara själva tjänsten, indexsamlingen, ett specifikt index, en dokumentsamling eller ett visst dokument. När slutpunkten, åtgärden (till exempel en begäran om att skapa eller uppdatera) och behörighetsnivån (fullständiga eller skrivskyddade rättigheter baserat på nyckeln) är de säkerhetsformler som skyddar innehåll och åtgärder.

Om du använder Azure AD autentisering använder du rolltilldelningar i stället för API-nycklar för att fastställa vem och vad som kan läsa och skriva till din söktjänst.

Kontrollera åtkomst till index

I Azure Cognitive Search är ett enskilt index vanligtvis inte ett skyddsbart objekt. Som tidigare nämnts för nyckelbaserad autentisering innehåller åtkomst till ett index läs- eller skrivbehörigheter baserat på vilken API-nyckel du anger för begäran, tillsammans med kontexten för en åtgärd. Frågor är skrivskyddade åtgärder. I en frågebegäran finns det inget begrepp om att ansluta till index eller komma åt flera index samtidigt, så alla begäranden riktar sig per definition till ett enda index. Därför definierar konstruktionen av själva frågebegäran (en nyckel plus ett enda målindex) säkerhetsgränsen.

Men om du använder Azure-roller kan du ange behörigheter för enskilda index så länge det görs programmatiskt.

För nyckelbaserade autentiseringsscenarier är administratörs- och utvecklaråtkomst till index oberörd: båda behöver skrivåtkomst för att skapa, ta bort och uppdatera de objekt som hanteras av tjänsten. Alla som har en administratörsnyckel till din tjänst kan läsa, ändra eller ta bort ett 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 Cognitive Search har redundans i klustret för att säkerställa tillgänglighet, men den lagrar eller kör inte din egenutvecklade 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å omfattar sådana lösningar vanligtvis en mellannivå som kunder använder för att hantera indexisolering. Mer information om användningsfallet för flera klienter finns i Designmönster för SaaS-program med flera klienter och Azure Cognitive Search.

Kontrollera åtkomsten till dokument

Om du behöver detaljerad kontroll per användare över sökresultat kan du skapa säkerhetsfilter för dina frågor och returnera dokument som är associerade med en viss säkerhetsidentitet.

Begreppsmässigt likvärdigt med "säkerhet på radnivå" stöds inte auktorisering till innehåll i indexet internt med hjälp av fördefinierade roller eller rolltilldelningar som mappar till entiteter i Azure Active Directory. Användarbehörigheter för data i externa system, till exempel Azure Cosmos DB, överförs inte med dessa data eftersom de indexeras av Cognitive Search.

Lösningar som kräver "säkerhet på radnivå" omfattar att skapa ett fält i datakällan som representerar en säkerhetsgrupp eller användaridentitet och sedan använda filter i Kognitiv sökning för att selektivt trimma sökresultat av dokument och innehåll baserat på identiteter. I följande tabell beskrivs två metoder för att trimma sökresultat för obehörigt innehåll.

Metod Beskrivning
Säkerhetstrimning baserat på identitetsfilter Dokumenterar det grundläggande arbetsflödet för att implementera åtkomstkontroll för användaridentitet. Den omfattar att lägga till säkerhetsidentifierare i ett index och förklarar sedan filtrering mot det fältet för att trimma resultat av förbjudet innehåll.
Säkerhetstrimning baserat på Azure Active Directory-identiteter Den här artikeln går vidare med föregående artikel och innehåller steg för att hämta identiteter från Azure Active Directory (Azure AD), en av de kostnadsfria tjänsterna på Azure-molnplattformen.

Auktorisering för tjänsthantering

Service Management-åtgärder auktoriseras via rollbaserad åtkomstkontroll i Azure (Azure RBAC). Azure RBAC är ett auktoriseringssystem som bygger på Azure Resource Manager för etablering av Azure-resurser.

I Azure Cognitive Search används Resource Manager för att skapa eller ta bort tjänsten, hantera API-nycklar och skala tjänsten. 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 definieras för söktjänstadministration. Rolltilldelningarna kan göras med valfri metodik som stöds (portalen, PowerShell och så vidare) och respekteras i hela tjänsten. Rollerna Ägare och Deltagare kan utföra olika administrationsfunktioner. Du kan tilldela rollen Läsare till användare som bara visar viktig information.

Anteckning

Med azureomfattande 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örsrättigheter. Mer information finns i Låsa resurser för att förhindra oväntad borttagning.

Dataplacering

När du konfigurerar en söktjänst väljer du en plats eller region som avgör var kunddata lagras och bearbetas. Azure Cognitive Search lagrar inte kunddata utanför din angivna region 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 kunddata 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: berikningscache, felsökningssession, kunskapslager.

Undantag från åtaganden för datahemvist

Objektnamn lagras och bearbetas utanför den valda regionen eller platsen. 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. Dessa data visas i telemetriloggarna som används av Microsoft för att tillhandahålla support för tjänsten. Objektnamn innehåller namn på index, indexerare, datakällor, kompetensuppsättningar, containrar och nyckelvalvsarkiv.

Telemetriloggar bevaras 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 ett fel. I det här scenariot är dataåtkomst endast internt, utan åtkomst från tredje part.

  • Under supporten kan den här informationen användas för att ge förslag till kunden. Till exempel " Baserat på din användning av produkten, överväg att använda <feature name> eftersom det skulle fungera bättre."

  • Microsoft kan exponera ett objektnamn på instrumentpaneler som är synliga för kunden.

På begäran kan Microsoft förkorta kvarhållningsintervallet eller ta bort referenser till specifika objekt i telemetriloggarna. Kom ihåg att om du begär borttagning av data har Microsoft inte en fullständig historik över din tjänst, vilket kan hindra felsökning av objektet i fråga.

Om du vill ta bort referenser till specifika objekt eller ändra datakvarhållningsperioden skapar du ett supportärende för söktjänsten.

  1. I Probleminformation taggar du din begäran med hjälp av följande val:

    • Typ av problem: Teknisk
    • Problemtyp: Installation och konfiguration
    • Undergrupp av problem: Problem med tjänstens säkerhetskonfiguration
  2. När du kommer till Ytterligare information (den tredje fliken) beskriver du de objektnamn som du vill ta bort eller anger den kvarhållningsperiod som du behöver.

    Skärmbild av den första sidan i supportärendet med problem och problemtyper valda.

Dataskydd

På lagringslagret är datakryptering inbyggt för allt tjänsthanterat innehåll som sparats på disk, 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

I Azure Cognitive Search börjar krypteringen med anslutningar och överföringar. För söktjänster på det offentliga Internet lyssnar Azure Cognitive Search på HTTPS-port 443. Alla klient-till-tjänst-anslutningar använder TLS 1.2-kryptering. Tidigare versioner (1.0 eller 1.1) stöds inte.

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. Den 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 Cognitive Search.

CMK-stödet 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 skapats 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 Cognitive Search.

Säkerhetsadministration

Hantera API-nycklar

Att förlita dig på API-nyckelbaserad autentisering innebär att du bör ha en plan för att återskapa administratörsnyckeln med jämna mellanrum, enligt metodtips för Säkerhet i Azure. 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

Cognitive 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 plocka upp toppar i frågevolymer 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 Cognitive Search deltar i regelbundna revisioner 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 om 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 för 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 bristande efterlevnad.

För Azure Cognitive Search finns det för närvarande en inbyggd definition. Det är för resursloggning. Med den här inbyggda funktionen kan du tilldela en princip som identifierar alla söktjänster som saknar resursloggning och sedan aktiverar den. Mer information finns i Azure Policy Regelefterlevnadskontroller för Azure Cognitive Search.

Titta på den här videon

Titta på den här snabba videon för en översikt över säkerhetsarkitekturen och varje funktionskategori.

Se även