Beveiligingsoverzicht voor Azure AI Search
In dit artikel worden de beveiligingsfuncties in Azure AI Search beschreven waarmee gegevens en bewerkingen worden beschermd.
Gegevensstroom (netwerkverkeerspatronen)
Een Azure AI-Search-service wordt gehost in Azure en wordt doorgaans geopend door clienttoepassingen via openbare netwerkverbindingen. Hoewel dit patroon overheersend is, is dit niet het enige verkeerspatroon waar u om moet zorgen. Inzicht in alle toegangspunten en uitgaand verkeer is nodig om uw ontwikkel- en productieomgevingen te beveiligen.
Azure AI Search heeft drie basispatronen voor netwerkverkeer:
- Binnenkomende aanvragen van een gebruiker of client naar de zoekservice (het overheersende patroon)
- Uitgaande aanvragen die door de zoekservice zijn uitgegeven aan andere services in Azure en elders
- Interne service-naar-service-aanvragen via het beveiligde Microsoft backbone-netwerk
Binnenkomend verkeer
Binnenkomende aanvragen die zijn gericht op een zoekservice-eindpunt zijn onder andere:
- Indexen en andere objecten in de zoekservice maken, lezen, bijwerken of verwijderen
- Een index laden met zoekdocumenten
- Een query op uitvoeren op een index
- Uitvoering van indexeerfunctie of vaardighedenset activeren
De REST API's beschrijven het volledige bereik van binnenkomende aanvragen die worden verwerkt door een zoekservice.
Alle binnenkomende aanvragen moeten minimaal worden geverifieerd met behulp van een van deze opties:
- Verificatie op basis van sleutels (standaard). Binnenkomende aanvragen bieden een geldige API-sleutel.
- Op rollen gebaseerd toegangsbeheer. Autorisatie vindt plaats via Microsoft Entra-identiteiten en roltoewijzingen in uw zoekservice.
Daarnaast kunt u netwerkbeveiligingsfuncties toevoegen om de toegang tot het eindpunt verder te beperken. U kunt binnenkomende regels maken in een IP-firewall of privé-eindpunten maken die uw zoekservice volledig afschermen van het openbare internet.
Intern verkeer
Interne aanvragen worden beveiligd en beheerd door Microsoft. U kunt deze verbindingen niet configureren of beheren. Als u netwerktoegang vergrendelt, is er geen actie voor uw onderdeel vereist omdat intern verkeer niet door de klant kan worden geconfigureerd.
Intern verkeer bestaat uit:
- Service-naar-service-aanroepen voor taken zoals verificatie en autorisatie via Microsoft Entra-id, resourcelogboeken die worden verzonden naar Azure Monitor en privé-eindpuntverbindingen die gebruikmaken van Azure Private Link.
- Aanvragen voor API's van Azure AI-services voor ingebouwde vaardigheden
- Aanvragen voor de machine learning-modellen die ondersteuning bieden voor semantische classificatie.
Uitgaand verkeer
Uitgaande aanvragen kunnen door u worden beveiligd en beheerd. Uitgaande aanvragen zijn afkomstig van een zoekservice naar andere toepassingen. Deze aanvragen worden doorgaans gedaan door indexeerfuncties voor indexering op basis van tekst, aangepaste AI-verrijking op basis van vaardigheden en vectorisaties tijdens query's. Uitgaande aanvragen omvatten zowel lees- als schrijfbewerkingen.
De volgende lijst is een volledige opsomming van de uitgaande aanvragen waarvoor u beveiligde verbindingen kunt configureren. Een zoekservice doet aanvragen namens zichzelf en namens een indexeerfunctie of aangepaste vaardigheid.
| Operation | Scenario |
|---|---|
| Indexeerfuncties | Maak verbinding met externe gegevensbronnen om gegevens op te halen. Zie Indexeertoegang tot inhoud die wordt beveiligd door Azure-netwerkbeveiliging voor meer informatie. |
| Indexeerfuncties | Maak verbinding met Azure Storage om kennisarchieven, verrijkingen in de cache, foutopsporingssessies te behouden. |
| Aangepaste vaardigheden | Maak verbinding met Azure Functions, Azure-web-apps of andere apps waarop externe code wordt uitgevoerd die buiten de service wordt gehost. De aanvraag voor externe verwerking wordt verzonden tijdens de uitvoering van de vaardighedenset. |
| Indexeerfuncties en geïntegreerde vectorisatie | Maak verbinding met Azure OpenAI en een geïmplementeerd insluitingsmodel of door een aangepaste vaardigheid om verbinding te maken met een insluitmodel dat u opgeeft. De zoekservice verzendt tekst naar het insluiten van modellen voor vectorisatie tijdens het indexeren. |
| Vectorizers | Maak verbinding met Azure OpenAI of andere insluitmodellen tijdens de query om teksttekenreeksen van gebruikers te converteren naar vectoren voor vectorzoekopdrachten. |
| Zoekservice | Maak verbinding met Azure Key Vault voor door de klant beheerde versleutelingssleutels die worden gebruikt voor het versleutelen en ontsleutelen van gevoelige gegevens. |
Uitgaande verbindingen kunnen worden gemaakt met behulp van de volledige toegang van een resource verbindingsreeks die een sleutel of een databaseaanmelding bevat, of een beheerde identiteit als u Microsoft Entra ID en op rollen gebaseerde toegang gebruikt.
Als u Azure-resources achter een firewall wilt bereiken, maakt u binnenkomende regels voor andere Azure-resources die zoekserviceaanvragen toelaten.
Als u Azure-resources wilt bereiken die worden beveiligd door Azure Private Link, maakt u een gedeelde privékoppeling die een indexeerfunctie gebruikt om verbinding te maken.
Uitzondering voor zoek- en opslagservices in dezelfde regio
Als Azure Storage en Azure AI Search zich in dezelfde regio bevinden, wordt netwerkverkeer gerouteerd via een privé-IP-adres en vindt plaats via het Microsoft-backbonenetwerk. Omdat privé-IP-adressen worden gebruikt, kunt u geen IP-firewalls of een privé-eindpunt configureren voor netwerkbeveiliging.
Configureer verbindingen met dezelfde regio met behulp van een van de volgende methoden:
Netwerkbeveiliging
Netwerkbeveiliging beschermt resources tegen onbevoegde toegang of aanvallen door besturingselementen toe te passen op netwerkverkeer. Azure AI Search biedt ondersteuning voor netwerkfuncties die uw frontline van verdediging kunnen zijn tegen onbevoegde toegang.
Binnenkomende verbinding via IP-firewalls
Een zoekservice wordt ingericht met een openbaar eindpunt dat toegang toestaat met behulp van een openbaar IP-adres. Als u wilt beperken welk verkeer via het openbare eindpunt wordt geleverd, maakt u een binnenkomende firewallregel waarmee aanvragen van een specifiek IP-adres of een bereik van IP-adressen worden toegegeven. Alle clientverbindingen moeten worden gemaakt via een toegestaan IP-adres of de verbinding wordt geweigerd.
U kunt de portal gebruiken om firewalltoegang te configureren.
U kunt ook de REST API's voor beheer gebruiken. Vanaf API-versie 2020-03-13, met de parameter IpRule, kunt u de toegang tot uw service beperken door IP-adressen te identificeren, afzonderlijk of in een bereik, die u toegang wilt verlenen tot uw zoekservice.
Binnenkomende verbinding met een privé-eindpunt (netwerkisolatie, geen internetverkeer)
Voor strengere beveiliging kunt u een privé-eindpunt instellen voor Azure AI Search, zodat een client in een virtueel netwerk veilig toegang heeft tot gegevens in een zoekindex via een Private Link.
Het privé-eindpunt maakt gebruik van een IP-adres uit de adresruimte van het virtuele netwerk voor verbindingen met uw zoekservice. Netwerkverkeer tussen de client en de zoekservice loopt via het virtuele netwerk en een privékoppeling in het Microsoft backbone-netwerk, waardoor blootstelling van het openbare internet wordt geëlimineerd. Een virtueel netwerk biedt veilige communicatie tussen resources, met uw on-premises netwerk en internet.
Hoewel deze oplossing het veiligst is, is het gebruik van meer services extra kosten, dus zorg ervoor dat u een duidelijk inzicht hebt in de voordelen voordat u induikt. Zie de pagina met prijzen voor meer informatie over kosten. Bekijk deze video voor meer informatie over hoe deze onderdelen samenwerken. De dekking van de optie privé-eindpunt begint om 5:48 in de video. Zie Een privé-eindpunt maken voor Azure AI Search voor instructies over het instellen van het eindpunt.
Verificatie
Zodra een aanvraag is toegelaten tot de zoekservice, moet deze nog steeds verificatie en autorisatie ondergaan die bepaalt of de aanvraag is toegestaan. Azure AI Search ondersteunt twee benaderingen:
Microsoft Entra-verificatie brengt de aanroeper (en niet de aanvraag) tot stand als de geverifieerde identiteit. Een Azure-roltoewijzing bepaalt autorisatie.
Verificatie op basis van sleutels wordt uitgevoerd op de aanvraag (niet de aanroepende app of gebruiker) via een API-sleutel, waarbij de sleutel een tekenreeks is die bestaat uit willekeurig gegenereerde cijfers en letters die bewijzen dat de aanvraag afkomstig is van een betrouwbare bron. Sleutels zijn vereist voor elke aanvraag. Het indienen van een geldige sleutel wordt beschouwd als bewijs dat de aanvraag afkomstig is van een vertrouwde entiteit.
U kunt beide verificatiemethoden gebruiken of een methode uitschakelen die u niet beschikbaar wilt maken in uw zoekservice.
Autorisatie
Azure AI Search biedt autorisatiemodellen voor servicebeheer en inhoudsbeheer.
Servicebeheer autoriseren
Resourcebeheer is geautoriseerd via op rollen gebaseerd toegangsbeheer in uw Microsoft Entra-tenant.
In Azure AI Search wordt Resource Manager gebruikt om de service te maken of te verwijderen, API-sleutels te beheren, de service te schalen en beveiliging te configureren. Als zodanig bepalen Azure-roltoewijzingen wie deze taken kan uitvoeren, ongeacht of ze de portal, PowerShell of de REST API's voor beheer gebruiken.
Drie basisrollen (Eigenaar, Inzender, Lezer) zijn van toepassing op zoekservicebeheer. Roltoewijzingen kunnen worden gemaakt met behulp van elke ondersteunde methodologie (portal, PowerShell, enzovoort) en worden gehonoreerd voor de hele service.
Notitie
Met behulp van azure-brede mechanismen kunt u een abonnement of resource vergrendelen om onbedoeld of niet-geautoriseerd verwijderen van uw zoekservice door gebruikers met beheerdersrechten te voorkomen. Zie Resources vergrendelen om onverwachte verwijdering te voorkomen voor meer informatie.
Toegang tot inhoud autoriseren
Inhoudsbeheer verwijst naar de objecten die zijn gemaakt en gehost op een zoekservice.
Voor autorisatie op basis van rollen gebruikt u Azure-roltoewijzingen om lees-schrijftoegang tot bewerkingen tot stand te brengen.
Voor autorisatie op basis van sleutels bepalen een API-sleutel en een gekwalificeerd eindpunt de toegang. Een eindpunt kan de service zelf zijn, de indexenverzameling, een specifieke index, een documentenverzameling of een specifiek document. Wanneer het eindpunt is gekoppeld, autoriseren de bewerking (bijvoorbeeld een aanvraag maken) en het type sleutel (beheerder of query) toegang tot inhoud en bewerkingen.
Toegang tot indexen beperken
Met behulp van Azure-rollen kunt u machtigingen instellen voor afzonderlijke indexen zolang deze programmatisch worden uitgevoerd.
Als u sleutels gebruikt, kan iedereen met een beheerderssleutel voor uw service indexen lezen, wijzigen of verwijderen in dezelfde service. Ter bescherming tegen onbedoelde of schadelijke verwijdering van indexen is uw interne broncodebeheer voor codeassets de oplossing voor het omkeren van ongewenste indexverwijdering of -wijziging. Azure AI Search heeft failover binnen het cluster om de beschikbaarheid te garanderen, maar slaat uw eigen code die wordt gebruikt om indexen te maken of te laden, niet op of voert deze uit.
Voor multitenancy-oplossingen die beveiligingsgrenzen op indexniveau vereisen, is het gebruikelijk om indexisolatie in de middelste laag in uw toepassingscode af te handelen. Zie Ontwerppatronen voor SaaS-toepassingen met meerdere tenants en Azure AI Search voor meer informatie over de use-case voor meerdere tenants.
Toegang tot documenten beperken
Gebruikersmachtigingen op documentniveau, ook wel beveiliging op rijniveau genoemd, worden niet systeemeigen ondersteund in Azure AI Search. Als u gegevens importeert uit een extern systeem dat beveiliging op rijniveau biedt, zoals Azure Cosmos DB, worden deze machtigingen niet overgedragen met de gegevens omdat deze worden geïndexeerd door Azure AI Search.
Als u machtigingen nodig hebt voor toegang via inhoud in zoekresultaten, is er een techniek voor het toepassen van filters die documenten opnemen of uitsluiten op basis van gebruikersidentiteit. Met deze tijdelijke oplossing wordt een tekenreeksveld toegevoegd in de gegevensbron die een groep of gebruikersidentiteit vertegenwoordigt, die u filterbaar kunt maken in uw index. Zie Beveiligingsbeperkingen op basis van identiteitsfilters voor meer informatie over dit patroon.
Gegevensresidentie
Wanneer u een zoekservice instelt, kiest u een regio die bepaalt waar klantgegevens worden opgeslagen en verwerkt. Elke regio bestaat binnen een geografische regio (Geo) die vaak meerdere regio's bevat (bijvoorbeeld Zwitserland is een geografische regio die Zwitserland - noord en Zwitserland - west bevat). Azure AI Search kan uw gegevens repliceren naar een andere regio binnen dezelfde geografische regio voor duurzaamheid en hoge beschikbaarheid. De service slaat geen klantgegevens op buiten de opgegeven geografische locatie of verwerkt deze, tenzij u een functie configureert die afhankelijk is van een andere Azure-resource en die resource is ingericht in een andere regio.
Momenteel is Azure Storage de enige externe resource waarnaar een zoekservice schrijft. Het opslagaccount is een account dat u opgeeft en kan zich in elke regio bevinden. Een zoekservice schrijft naar Azure Storage als u een van de volgende functies gebruikt:
Zie gegevenslocatie in Azure voor meer informatie over gegevenslocatie.
Uitzonderingen op toezeggingen voor gegevenslocatie
Objectnamen worden weergegeven in de telemetrielogboeken die door Microsoft worden gebruikt om ondersteuning voor de service te bieden. Objectnamen worden opgeslagen en verwerkt buiten uw geselecteerde regio of locatie. Objectnamen omvatten de namen van indexen en indexvelden, aliassen, indexeerfuncties, gegevensbronnen, vaardighedensets, synoniemenkaarten, resources, containers en sleutelkluisopslag. Klanten mogen geen gevoelige gegevens in naamvelden plaatsen of toepassingen maken die zijn ontworpen voor het opslaan van gevoelige gegevens in deze velden.
Telemetrielogboeken worden gedurende anderhalf jaar bewaard. Gedurende die periode kan Microsoft onder de volgende voorwaarden toegang krijgen tot objectnamen en ernaar verwijzen:
Een probleem vaststellen, een functie verbeteren of een fout oplossen. In dit scenario is gegevenstoegang alleen intern, zonder toegang van derden.
Tijdens de ondersteuning kan deze informatie worden gebruikt om snel oplossingen te bieden voor problemen en het productteam indien nodig te escaleren
Gegevensbescherming
Op de opslaglaag is gegevensversleuteling ingebouwd voor alle door de service beheerde inhoud die is opgeslagen op schijf, inclusief indexen, synoniemenkaarten en de definities van indexeerfuncties, gegevensbronnen en vaardighedensets. Door de service beheerde versleuteling is van toepassing op zowel langetermijnopslag als tijdelijke gegevensopslag.
U kunt desgewenst door de klant beheerde sleutels (CMK) toevoegen voor aanvullende versleuteling van geïndexeerde inhoud voor dubbele versleuteling van data-at-rest. Voor services die na 1 augustus 2020 zijn gemaakt, wordt CMK-versleuteling uitgebreid tot kortetermijngegevens op tijdelijke schijven.
Actieve gegevens
Voor zoekserviceverbindingen via het openbare internet luistert Azure AI Search op HTTPS-poort 443.
Azure AI Search ondersteunt TLS 1.2 en 1.3 voor client-naar-service-kanaalversleuteling:
- TLS 1.3 is de standaardinstelling voor nieuwere clientbesturingssystemen en -versies van .NET.
- TLS 1.2 is de standaardinstelling voor oudere systemen, maar u kunt TLS 1.3 expliciet instellen op een clientaanvraag.
Eerdere versies van TLS (1.0 of 1.1) worden niet ondersteund.
Zie TLS-ondersteuning in .NET Framework voor meer informatie.
Inactieve gegevens
Voor gegevens die intern worden verwerkt door de zoekservice, worden in de volgende tabel de gegevensversleutelingsmodellen beschreven. Sommige functies, zoals kennisarchief, incrementele verrijking en indexering op basis van indexeerfuncties, lezen van of schrijven naar gegevensstructuren in andere Azure-services. Services met een afhankelijkheid van Azure Storage kunnen gebruikmaken van de versleutelingsfuncties van die technologie.
| Modelleren | Sleutels | Vereisten | Beperkingen | Van toepassing op |
|---|---|---|---|---|
| versleuteling aan serverzijde | Door Microsoft beheerde sleutels | Geen (ingebouwd) | Geen, beschikbaar voor alle lagen, in alle regio's, voor inhoud die is gemaakt na 24 januari 2018. | Inhoud (indexen en synoniemenkaarten) en definities (indexeerfuncties, gegevensbronnen, vaardighedensets), op gegevensschijven en tijdelijke schijven |
| versleuteling aan serverzijde | door de klant beheerde sleutels | Azure Key Vault | Beschikbaar voor factureerbare lagen, in specifieke regio's, voor inhoud die is gemaakt na 1 augustus 2020. | Inhoud (indexen en synoniemenkaarten) op gegevensschijven |
| volledige versleuteling aan serverzijde | door de klant beheerde sleutels | Azure Key Vault | Beschikbaar voor factureerbare lagen, in alle regio's, voor zoekservices na 13 mei 2021. | Inhoud (indexen en synoniemenkaarten) op gegevensschijven en tijdelijke schijven |
Door de service beheerde sleutels
Door de service beheerde versleuteling is een interne bewerking van Microsoft die gebruikmaakt van 256-bits AES-versleuteling. Het gebeurt automatisch bij alle indexeringen, inclusief incrementele updates voor indexen die niet volledig zijn versleuteld (gemaakt vóór januari 2018).
Door de service beheerde versleuteling is van toepassing op alle inhoud op langetermijn- en kortetermijnopslag.
Door de klant beheerde sleutels (CMK)
Door de klant beheerde sleutels vereisen een andere factureerbare service, Azure Key Vault, die zich in een andere regio kan bevinden, maar onder hetzelfde abonnement, als Azure AI Search.
CMK-ondersteuning is in twee fasen geïmplementeerd. Als u uw zoekservice tijdens de eerste fase hebt gemaakt, is CMK-versleuteling beperkt tot langetermijnopslag en specifieke regio's. Services die in de tweede fase zijn gemaakt, kunnen na mei 2021 CMK-versleuteling in elke regio gebruiken. Als onderdeel van de tweede golf-implementatie is inhoud cmk versleuteld op zowel langetermijn- als kortetermijnopslag. Zie volledige dubbele versleuteling voor meer informatie over CMK-ondersteuning.
Door CMK-versleuteling in te schakelen, worden de indexgrootte vergroot en worden de queryprestaties verminderd. Op basis van waarnemingen tot heden kunt u verwachten dat er een toename van 30-60 procent in querytijden is, hoewel de werkelijke prestaties variëren, afhankelijk van de indexdefinitie en typen query's. Vanwege de negatieve invloed op de prestaties raden we u aan deze functie alleen in te schakelen voor indexen waarvoor deze echt nodig is. Zie Door de klant beheerde versleutelingssleutels configureren in Azure AI Search voor meer informatie.
Beveiligingsbeheer
API-sleutels beheren
Afhankelijk van verificatie op basis van API-sleutels betekent dat u een plan moet hebben voor het opnieuw genereren van de beheersleutel met regelmatige tussenpozen, volgens aanbevolen procedures voor Azure-beveiliging. Er zijn maximaal twee beheerderssleutels per zoekservice. Zie API-sleutels maken en beheren voor meer informatie over het beveiligen en beheren van API-sleutels.
Activiteiten- en resourcelogboeken
Azure AI Search registreert geen gebruikersidentiteiten, zodat u geen logboeken kunt raadplegen voor informatie over een specifieke gebruiker. De service registreert echter create-read-update-delete-bewerkingen, die u mogelijk kunt correleren met andere logboeken om inzicht te krijgen in het agentschap van specifieke acties.
Met behulp van waarschuwingen en de infrastructuur voor logboekregistratie in Azure kunt u pieken in queryvolumes of andere acties ophalen die afwijken van de verwachte workloads. Zie Logboekgegevens verzamelen en analyseren en queryaanvragen bewaken voor meer informatie over het instellen van logboeken.
Certificering en compliance
Azure AI Search neemt deel aan regelmatige audits en is gecertificeerd op basis van veel wereldwijde, regionale en branchespecifieke standaarden voor zowel de openbare cloud als Azure Government. Download voor de volledige lijst het technische document microsoft Azure-nalevingsaanbiedingen op de officiële pagina met auditrapporten.
Voor naleving kunt u Azure Policy gebruiken om de best practices voor hoge beveiliging van de Microsoft-cloudbeveiligingsbenchmark te implementeren. De Microsoft-cloudbeveiligingsbenchmark is een verzameling beveiligingsaanbevelingen die zijn gecodificeerd in beveiligingscontroles die worden toegewezen aan belangrijke acties die u moet ondernemen om bedreigingen voor services en gegevens te beperken. Er zijn momenteel 12 beveiligingscontroles, waaronder netwerkbeveiliging, logboekregistratie en bewaking en gegevensbescherming.
Azure Policy is een mogelijkheid die is ingebouwd in Azure waarmee u naleving voor meerdere standaarden kunt beheren, waaronder die van microsoft-cloudbeveiligingsbenchmark. Voor bekende benchmarks biedt Azure Policy ingebouwde definities die zowel criteria als een uitvoerbaar antwoord bieden dat betrekking heeft op niet-naleving.
Voor Azure AI Search is er momenteel één ingebouwde definitie. Dit is bedoeld voor resourcelogboekregistratie. U kunt een beleid toewijzen waarmee zoekservices worden geïdentificeerd waarvoor logboekregistratie van resources ontbreekt en schakelt u dit vervolgens in. Zie De besturingselementen voor naleving van Azure Policy-regelgeving voor Azure AI Search voor meer informatie.
Bekijk deze video
Bekijk deze snelle video voor een overzicht van de beveiligingsarchitectuur en elke functiecategorie.