Säkerhetsöversikt för Azure Cognitive Search
I den här artikeln beskrivs säkerhetsfunktionerna i Azure Cognitive Search som skyddar data och åtgärder.
Nätverkstrafikmönster
En söktjänst finns i Azure och används vanligtvis via offentliga nätverksanslutningar. Att förstå tjänstens åtkomstmönster kan hjälpa dig att utforma en säkerhetsstrategi som effektivt avråder obehörig åtkomst till sökbart innehåll.
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 någon annanstans
- Interna tjänst-till-tjänst-begäranden via det säkra Microsoft-stamnätverket
Inkommande begäranden kan vara allt från att skapa objekt, läsa in data och köra frågor. För inkommande åtkomst till data och åtgärder kan du implementera en förlopp för säkerhetsåtgärder, från och med API-nycklar på begäran. Du kan sedan komplettera med regler för inkommande trafik i en IP-brandvägg eller skapa privata slutpunkter som fullständigt skyddar din tjänst från det offentliga Internet.
Utgående begäranden kan innehålla både läs- och skrivåtgärder. Den primära agenten för ett utgående anrop är en indexerare och kunskapsuppsättningar. För indexerare omfattar läsåtgärder dokumentknckning och datainmatning. En indexerare kan också skriva till Azure Storage när du skapar kunskapslager, bevarar cachelagrade berikanden och bevarar felsökningssessioner. Slutligen kan en kunskapsuppsättning även innehålla anpassade färdigheter som kör extern kod, till exempel i Azure Functions eller i en webbapp.
Interna begäranden omfattar tjänst-till-tjänst-anrop för uppgifter som diagnostisk loggning, kryptering, autentisering och auktorisering via Azure Active Directory, privata slutpunktsanslutningar och begäranden som görs till Cognitive Services för inbyggda kunskaper.
Nätverkssäkerhet
Inkommande säkerhetsfunktioner skyddar söktjänstens slutpunkt genom att öka säkerhetsnivåerna och komplexiteten. Cognitive Search använder nyckelbaserad autentisering, där alla begäranden kräver en API-nyckel för autentiserad åtkomst.
Du kan också implementera ytterligare kontrolllager genom att ange brandväggsregler som begränsar åtkomsten till specifika IP-adresser. För avancerat skydd kan du aktivera Azure Private Link att skydda tjänstslutpunkten från all Internettrafik.
Anslut över det offentliga Internet
Som standard nås en söktjänstslutpunkt via det offentliga molnet med nyckelbaserad autentisering för administratörs- eller frågeåtkomst till söktjänstens slutpunkt. Nycklar krävs. Att skicka en giltig nyckel betraktas som ett bevis på att begäran kommer från en betrodd entitet. Nyckelbaserad autentisering tas upp i nästa avsnitt. Utan API-nycklar får du 401- och 404-svar på begäran.
Anslut ip-brandväggar
Om du vill styra åtkomsten till din söktjänst ytterligare kan du skapa inkommande brandväggsregler som tillåter åtkomst till specifika IP-adresser eller ett intervall med IP-adresser. Alla klientanslutningar måste göras via en tillåten IP-adress, annars nekas anslutningen.
Du kan använda portalen för att konfigurera inkommande åtkomst.
Du kan också använda hanterings-REST API:er. Från och med API-version 2020-03-13 kan du med parametern IpRule 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.
Anslut till en privat slutpunkt (nätverksisolering, ingen Internettrafik)
Du kan upprätta en privat slutpunkt för Azure Cognitive Search tillåter en klient i ett virtuellt nätverk att på ett säkert sätt 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ä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 VNET 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 användningen av ytterligare tjänster en extra kostnad, så se till att du har en tydlig förståelse för fördelarna innan du dyker in. eller mer information om kostnader finns på prissättningssidan. Mer information om hur dessa komponenter fungerar tillsammans finns i videon överst i den här artikeln. Täckningen för alternativet för privat slutpunkt börjar 5:48 i videon. Anvisningar om hur du ställer in slutpunkten finns i Skapa en privat slutpunkt för Azure Cognitive Search.
Utgående anslutningar till externa tjänster
Indexerare och kunskapsuppsättningar är båda objekt som kan göra externa anslutningar. Du anger anslutningsinformation som en del av objektdefinitionen med någon av dessa metoder.
Autentiseringsuppgifter i anslutningssträngen
Hanterad identitet i anslutningssträngen
Du kan konfigurera en hanterad identitet för att söka efter en betrodd tjänst vid åtkomst till data från Azure Storage, Azure SQL, Cosmos DB eller andra Azure-datakällor. En hanterad identitet ersätter autentiseringsuppgifter eller åtkomstnycklar för anslutningen. Mer information om den här funktionen finns i Anslut till en datakälla med hjälp av en hanterad identitet.
Autentisering
För inkommande begäranden till söktjänsten är autentisering via en API-nyckel (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. Det finns också nytt stöd för att Azure Active Directory autentisering och rollbaserad auktorisering, för närvarande i förhandsversion.
Utgående begäranden som görs av en indexerare måste autentiseras av den externa tjänsten. Indexerarundertjänsten i Cognitive Search en betrodd tjänst i Azure, som ansluter till andra tjänster med hjälp av en hanterad identitet. Mer information finns i Konfigurera en indexeraranslutning till en datakälla med hjälp av en hanterad identitet.
Auktorisering
Cognitive Search olika auktoriseringsmodeller för innehållshantering och tjänsthantering.
Auktorisering för innehållshantering
Auktorisering till innehåll och åtgärder relaterade till innehåll är antingen skrivåtkomst, som via API-nyckeln som anges i begäran. API-nyckeln är en autentiseringsmekanism, men auktoriserar även åtkomst beroende på typen av API-nyckel.
Administratörsnyckel (tillåter läs- och skrivåtkomst för create-read-update-delete-åtgärder i söktjänsten) som skapas när tjänsten etableras
Frågenyckel (ger 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 specifikt dokument. När slutpunkten länkas samman utgör å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) den säkerhetsformel som skyddar innehåll och åtgärder.
Anteckning
Auktorisering för dataplansåtgärder med hjälp av rollbaserad åtkomstkontroll i Azure (RBAC) är nu i förhandsversion. Du kan använda den här förhandsversionen om du vill använda rolltilldelningar i stället för API-nycklar.
Kontrollera åtkomst till index
I Azure Cognitive Search är ett enskilt index inte ett skyddat objekt. I stället fastställs åtkomsten till ett index på tjänstlagret (läs- eller skrivåtkomst baserat på vilken API-nyckel du anger), tillsammans med kontexten för en åtgärd.
För skrivskyddad åtkomst kan du strukturera frågebegäranden för att ansluta med en frågenyckel ochinkludera det specifika index som används av din app. I en frågebegäran finns det inget begrepp för att koppla index eller komma åt flera index samtidigt, så alla begäranden riktar in sig på ett enda index per definition. Därför definierar själva bygget av frågebegäran (en nyckel plus ett enda målindex) säkerhetsgränsen.
Administratörs- och utvecklaråtkomst till index är o differentierade: båda behöver skrivåtkomst för att skapa, ta bort och uppdatera objekt som hanteras av tjänsten. Alla med en administratörsnyckel till din tjänst kan läsa, ändra eller ta bort alla index i samma tjänst. För att skydda mot oavsiktlig eller skadlig borttagning av index är din lokala källkodskontroll för kodtillgångar lösningen för att ångra en oönskad indexborttagning eller ändring. Azure Cognitive Search redundans i klustret för att säkerställa tillgängligheten, 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 med flera innehavare som kräver säkerhetsgränser på indexnivå innehåller sådana lösningar vanligtvis en mellannivå som kunder använder för att hantera indexisolering. Mer information om användningsfallet för flera entenant finns i Designmönster för SaaS-programmed flera Azure Cognitive Search .
Kontrollera åtkomst 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 behörighet till innehåll i indexet med fördefinierade roller eller rolltilldelningar som mappar till entiteter i Azure Active Directory. Användarbehörigheter för data i externa system, till exempel Cosmos DB, överför inte med dessa data som de indexeras av Cognitive Search.
Lösningar för 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 Cognitive Search för att selektivt trimma sökresultat för 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 | Description |
|---|---|
| Säkerhetstrimning baserat på identitetsfilter | Dokumenterar det grundläggande arbetsflödet för att implementera åtkomstkontroll för användaridentiteter. Den omfattar att lägga till säkerhetsidentifierare i ett index och sedan förklara filtrering mot fältet för att trimma resultatet av förbjudet innehåll. |
| Säkerhets trimning baserat på Azure Active Directory identiteter | Den här artikeln bygger vidare på 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 i Azure-molnplattformen. |
Auktorisering för Service Management
Service Management-åtgärder auktoriserats via rollbaserad åtkomstkontroll i Azure (Azure RBAC). Azure RBAC är ett auktoriseringssystem som bygger 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, PowerShelleller REST-API:ernaför hantering.
Tre grundläggande roller har definierats för administration av söktjänster. Rolltilldelningarna kan göras med valfri metod som stöds (portalen, PowerShell och så vidare) och används för hela tjänsten. Rollerna Ägare och Deltagare kan utföra en mängd olika administrationsfunktioner. Du kan tilldela rollen Läsare till användare som bara visar viktig information.
Anteckning
Med hjälp av mekanismer för hela Azure kan du låsa en prenumeration eller resurs för att förhindra oavsiktlig eller obehörig borttagning av söktjänsten av användare med administratörsrättigheter. Mer information finns i Låsa resurser för att förhindra oväntad borttagning.
Dataskydd
På lagringslagret är datakryptering inbyggt för allt tjänst hanterat innehåll som sparas på disk, inklusive index, synonymmappningar och definitionerna av indexerare, datakällor och kompetensuppsättningar. Du kan också lägga till kund hanterade nycklar (CMK) för kompletterande kryptering av indexerat innehåll. För tjänster som skapats efter 1 augusti 2020 utökas CMK-kryptering till data på temporära diskar för fullständig "dubbel kryptering" av indexerat innehåll.
Data under överföring
I Azure Cognitive Search börjar krypteringen med anslutningar och överföringar och omfattar även innehåll som lagras på disk. För söktjänster på det offentliga Internet 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.
Krypterade vilodata
För data som hanteras internt av söktjänsten beskrivs datakrypteringsmodellerna i följande tabell. Vissa funktioner, till exempel kunskapslager, inkrementell berikning och indexeringsbaserad indexering, läsning från eller skrivning till datastrukturer i andra Azure-tjänster. Dessa tjänster har egna nivåer av krypteringsstöd som är separata från Azure Cognitive Search.
| 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 24 januari 2018. | Innehåll (index och synonymmappningar) och definitioner (indexerare, datakällor, kunskapsuppsättningar) |
| kryptering på serversidan | kund hanterade nycklar | Azure Key Vault | Tillgängligt på fakturerbara nivåer i alla regioner för innehåll som skapats efter januari 2019. | Innehåll (index och synonymmappningar) på datadiskar |
| dubbel kryptering på serversidan | kund hanterade nycklar | Azure Key Vault | Tillgängligt på fakturerbara nivåer, i valda regioner, på söktjänster efter 1 augusti 2020. | Innehåll (index och synonymmappningar) på datadiskar och temporära diskar |
Tjänst hanterade nycklar
Tjänstbaserad kryptering är en microsoft-intern åtgärd som baseras på Azure Storage-tjänstkrypteringmed 256-bitars AES-kryptering. Den sker automatiskt vid all indexering, inklusive inkrementella uppdateringar av index som inte är helt krypterade (skapas före januari 2018).
Kund hanterade nycklar (CMK)
Kund hanterade nycklar kräver ytterligare en fakturerbar tjänst, Azure Key Vault, som kan finnas i en annan region, men under samma prenumeration, som Azure Cognitive Search. Om du aktiverar CMK-kryptering ökas indexstorleken och frågeprestandan försämras. Baserat på hittills använda observationer kan du förvänta dig en ökning på 30–60 % i frågetider, även om den faktiska prestandan varierar beroende på indexdefinitionen och typen av frågor. På grund av den här prestandapåverkan rekommenderar vi att du bara aktiverar den här funktionen på index som verkligen kräver det. Mer information finns i Konfigurera kund hanterade krypteringsnycklar i Azure Cognitive Search.
Dubbel kryptering
I Azure Cognitive Search är dubbel kryptering ett tillägg för CMK. Det tolkas som tvådelig kryptering (en gång med CMK och igen av tjänstbaserade nycklar) och omfattande i omfånget, som omfattar långsiktig lagring som skrivs till en datadisk och kortsiktig lagring som skrivs till temporära diskar. Dubbel kryptering implementeras i tjänster som skapas efter specifika datum. Mer information finns i Dubbel kryptering.
Säkerhetshantering
API-nycklar
Beroende av API-nyckelbaserad autentisering innebär att du bör ha en plan för att återskapa administratörsnyckeln med jämna mellanrum, enligt bästa praxis 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 diagnostikloggar
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å hur specifika åtgärder fungerar.
Med hjälp av aviseringar och loggningsinfrastrukturen i Azure kan du hämta upp toppar i frågevolymen eller andra åtgärder som avviker från förväntade arbetsbelastningar. Mer information om hur du ställer in loggar finns i Samla in och analysera loggdata och Övervaka frågebegäranden.
Certifieringar och efterlevnad
Azure Cognitive Search deltar i regelbundna granskningar och har certifierats mot ett antal globala, regionala och branschspecifika standarder för både det offentliga molnet och Azure Government. För den fullständiga listan laddar du Microsoft Azure whitepaper om efterlevnadserbjudanden från den officiella sidan Granskningsrapporter.
För efterlevnad kan du använda Azure Policy för att implementera de bästa metoderna för hög säkerhet i Azure Security Benchmark. Azure Security Benchmark är en samling säkerhetsrekommendationer som kodifieras 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 11 säkerhetskontroller, inklusive nätverkssäkerhet, loggningoch övervakning och dataskydd för att nämna några.
Azure Policy är en funktion som är inbyggd i Azure och som hjälper dig att hantera efterlevnad för flera standarder, inklusive standarder för Azure Security Benchmark. För välkända benchmarks innehåller Azure Policy inbyggda definitioner som tillhandahåller 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 diagnostisk loggning. Med den här inbyggda tjänsten kan du tilldela en princip som identifierar alla söktjänster som saknar diagnostisk loggning och sedan aktiverar den. Mer information finns i Azure Policy för regelefterlevnad 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.