Beveiligingsoverzicht voor Azure Cognitive Search

In dit artikel worden de beveiligingsfuncties in Azure Cognitive Search die gegevens en bewerkingen beveiligen.

Netwerkverkeerspatronen

Een zoekservice wordt gehost in Azure en wordt doorgaans gebruikt via openbare netwerkverbindingen. Inzicht in de toegangspatronen van de service kan u helpen bij het ontwerpen van een beveiligingsstrategie die onbevoegde toegang tot doorzoekbare inhoud effectief afveiligt.

Cognitive Search heeft drie basispatronen voor netwerkverkeer:

• Binnenkomende aanvragen van een client naar de zoekservice (het overheersende patroon)
• Uitgaande aanvragen die door de zoekservice worden uitgegeven naar andere services in Azure en elders
• Interne service-naar-service-aanvragen via het beveiligde Microsoft-backbonenetwerk

Binnenkomende aanvragen variëren van het maken van objecten, het laden van gegevens en het uitvoeren van query's. Voor binnenkomende toegang tot gegevens en bewerkingen kunt u een voortgang van beveiligings maatregelen implementeren, te beginnen met API-sleutels voor de aanvraag. U kunt vervolgens aanvullen met regels voor inkomend verkeer in een IP-firewall of privé-eindpunten maken die uw service volledig afschermen van het openbare internet.

Uitgaande aanvragen kunnen zowel lees- als schrijfbewerkingen bevatten. De primaire agent van een uitgaande aanroep is een indexer en samenstellende vaardighedensets. Leesbewerkingen voor indexeringen zijn onder andere het kraken van documenten en het opnemen van gegevens. Een indexer kan ook schrijven naar Azure Storage bij het maken van kennisopslag, het persistent maken van verrijkingen in de cache en het persistent maken van foutopsporingssessies. Ten slotte kan een vaardighedenset ook aangepaste vaardigheden bevatten die externe code uitvoeren, bijvoorbeeld in Azure Functions of in een web-app.

Interne aanvragen omvatten service-naar-service-aanroepen voor taken zoals diagnostische logboekregistratie, versleuteling, verificatie en autorisatie via Azure Active Directory, privé-eindpuntverbindingen en aanvragen aan Cognitive Services voor ingebouwde vaardigheden.

Netwerkbeveiliging

Inkomende beveiligingsfuncties beschermen het eindpunt van de zoekservice door toenemende beveiligings- en complexiteitsniveaus. Cognitive Search maakt gebruik van verificatie op basis van sleutels, waarbij voor alle aanvragen een API-sleutelis vereist voor geverifieerde toegang.

U kunt eventueel extra beheerlagen implementeren door firewallregels in te stellen die de toegang tot specifieke IP-adressen beperken. Voor geavanceerde beveiliging kunt u inschakelen Azure Private Link service-eindpunt af te schermen van al het internetverkeer.

Verbinding maken via het openbare internet

Een service-eindpunt voor zoeken is standaard toegankelijk via de openbare cloud, met behulp van verificatie op basis van sleutels voor beheerders- of querytoegang tot het eindpunt van de zoekservice. Sleutels zijn vereist. Het indienen van een geldige sleutel wordt beschouwd als bewijs dat de aanvraag afkomstig is van een vertrouwde entiteit. Verificatie op basis van sleutels wordt behandeld in de volgende sectie. Zonder API-sleutels krijgt u 401- en 404-antwoorden op de aanvraag.

Verbinding maken IP-firewalls

Als u de toegang tot uw zoekservice verder wilt beheren, kunt u inkomende firewallregels maken die toegang tot een specifiek IP-adres of een bereik van IP-adressen toestaan. Alle clientverbindingen moeten worden gemaakt via een toegestaan IP-adres of de verbinding wordt geweigerd.

U kunt de portal gebruiken om binnenkomende toegang te configureren.

U kunt ook de REST API's voor beheer gebruiken. Vanaf API-versie 2020-03-13 kunt u met de parameter IpRule de toegang tot uw service beperken door IP-adressen afzonderlijk of in een bereik te identificeren die u toegang wilt verlenen tot uw zoekservice.

Verbinding maken naar een privé-eindpunt (netwerkisolatie, geen internetverkeer)

U kunt een privé-eindpunt tot stand Azure Cognitive Search een client in een virtueel netwerk veilig toegang kan krijgen tot gegevens in een zoekindex via een Private Link.

Het privé-eindpunt gebruikt een IP-adres uit de adresruimte van het virtuele netwerk voor verbindingen met uw zoekservice. Netwerkverkeer tussen de client en de zoekservice gaat via het virtuele netwerk en een privékoppeling op het backbone-netwerk van Microsoft, waardoor de blootstelling van het openbare internet wordt voorkomen. Een VNET biedt veilige communicatie tussen resources, met uw on-premises netwerk en internet.

Hoewel deze oplossing het veiligst is, zijn extra services een extra kostenpost. Zorg er dus voor dat u een duidelijk beeld hebt van de voordelen voordat u verder gaat. zie de pagina met prijzen voor meer informatie over kosten. Bekijk de video bovenaan dit artikel voor meer informatie over hoe deze onderdelen samenwerken. Dekking van de optie privé-eindpunt begint om 5:48 in de video. Zie Een privé-eindpunt maken voor een Azure Cognitive Search voor instructies over het instellen van Azure Cognitive Search.

Uitgaande verbindingen met externe services

Indexeren en vaardighedensets zijn beide objecten die externe verbindingen kunnen maken. U geeft verbindingsgegevens op als onderdeel van de objectdefinitie, met behulp van een van deze mechanismen.

• Referenties in de connection string

• Beheerde identiteit in de connection string

  U kunt een beheerde identiteit instellen om een vertrouwde service te doorzoeken bij het openen van gegevens uit Azure Storage, Azure SQL, Cosmos DB of andere Azure-gegevensbronnen. Een beheerde identiteit is een vervanging voor referenties of toegangssleutels voor de verbinding. Zie Een Verbinding maken met behulp van een beheerde identiteit voor meer informatie over deze mogelijkheid.

Verificatie

Voor binnenkomende aanvragen naar de zoekservice is verificatie via een API-sleutel (een tekenreeks die bestaat uit willekeurig gegenereerde cijfers en letters) die aantoont dat de aanvraag afkomstig is van een betrouwbare bron. Er is ook nieuwe ondersteuning voor Azure Active Directory verificatie en op rollen gebaseerde autorisatie, momenteel in preview.

Uitgaande aanvragen van een indexer zijn onderworpen aan verificatie door de externe service. De indexeringssubservice in Cognitive Search kan een vertrouwde service worden gemaakt in Azure en verbinding maken met andere services met behulp van een beheerde identiteit. Zie Een indexeringsverbindinginstellen met een gegevensbron met behulp van een beheerde identiteit voor meer informatie.

Autorisatie

Cognitive Search verschillende autorisatiemodellen voor inhoudsbeheer en servicebeheer.

Autorisatie voor inhoudsbeheer

Autorisatie voor inhoud en bewerkingen met betrekking tot inhoud is schrijftoegang, zoals wordt verleend via de API-sleutel die is opgegeven in de aanvraag. De API-sleutel is een verificatiemechanisme, maar autorisatie van toegang, afhankelijk van het type API-sleutel.

• Beheersleutel (staat lees-schrijftoegang toe voor create-read-update-delete-bewerkingen in de zoekservice), gemaakt wanneer de service wordt ingericht

• Querysleutel (biedt alleen-lezentoegang tot de documentenverzameling van een index), die naar behoefte is gemaakt en die is ontworpen voor clienttoepassingen die query's uitvoeren

In toepassingscode geeft u het eindpunt en een API-sleutel op om toegang tot inhoud en opties toe te staan. Een eindpunt kan de service zelf, de indexverzameling, een specifieke index, een documentenverzameling of een specifiek document zijn. Wanneer het eindpunt, de bewerking (bijvoorbeeld een aanvraag voor maken of bijwerken) en het machtigingsniveau (volledige of alleen-lezenrechten op basis van de sleutel) aan elkaar zijn toegevoegd, vormen het eindpunt, de bewerking (bijvoorbeeld een aanvraag voor maken of bijwerken) de beveiligingsformule die inhoud en bewerkingen beveiligt.

Toegang tot indexen beheren

In Azure Cognitive Search is een afzonderlijke index geen beekbaar object. In plaats daarvan wordt de toegang tot een index bepaald op de servicelaag (lees- of schrijftoegang op basis van de API-sleutel die u levert), samen met de context van een bewerking.

Voor alleen-lezentoegang kunt u queryaanvragen structureren om verbinding te maken met behulp van een querysleutelen de specifieke index opnemen die door uw app wordt gebruikt. In een queryaanvraag is er geen concept van het samenvoegen van indexen of het openen van meerdere indexen tegelijk, zodat alle aanvragen per definitie gericht zijn op één index. Als zodanig definieert de constructie van de queryaanvraag zelf (een sleutel plus één doelindex) de beveiligingsgrens.

Beheerders- en ontwikkelaarstoegang tot indexen is niet gedifferentieerd: beide hebben schrijftoegang nodig om objecten te maken, te verwijderen en bij te werken die door de service worden beheerd. Iedereen met een beheerderssleutel voor uw service kan elke index in dezelfde service lezen, wijzigen of verwijderen. Ter bescherming tegen onbedoelde of kwaadwillende verwijdering van indexen is uw in-house broncodebeheer voor code-assets de oplossing voor het omkeren van een ongewenste indexverificatie of -wijziging. Azure Cognitive Search heeft een failover binnen het cluster om beschikbaarheid te garanderen, maar uw eigen code die wordt gebruikt voor het maken of laden van indexen, wordt niet opgeslagen of uitgevoerd.

Voor oplossingen voor multitenancy waarvoor beveiligingsgrenzen op indexniveau zijn vereist, bevatten dergelijke oplossingen doorgaans een middelste laag, die klanten gebruiken om indexisolatie af te handelen. Zie Ontwerppatronen voor SaaS-toepassingen voor meerderetenant en Azure Cognitive Search voor meer informatie over de multitenant-use-case.

Toegang tot documenten beheren

Als u gedetailleerde controle per gebruiker over zoekresultaten nodig hebt, kunt u beveiligingsfilters bouwen voor uw query's en documenten retourneren die zijn gekoppeld aan een bepaalde beveiligingsidentiteit.

Conceptueel gezien gelijk aan 'beveiliging op rijniveau', wordt autorisatie voor inhoud in de index niet standaard ondersteund met behulp van vooraf gedefinieerde rollen of roltoewijzingen die zijn Azure Active Directory. Gebruikersmachtigingen voor gegevens in externe systemen, zoals Cosmos DB, worden niet met die gegevens overdragen omdat ze worden geïndexeerd door Cognitive Search.

Tijdelijke oplossingen waarvoor 'beveiliging op rijniveau' is vereist, zijn onder andere het maken van een veld in de gegevensbron dat een beveiligingsgroep of gebruikersidentiteit vertegenwoordigt, en vervolgens filters gebruiken in Cognitive Search om selectief zoekresultaten van documenten en inhoud op basis van identiteiten in te korten. In de volgende tabel worden twee methoden beschreven voor het inkorten van zoekresultaten van niet-geautoriseerde inhoud.

Autorisatie voor servicebeheer

ServiceBeheerbewerkingen worden geautoriseerd via op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC). Azure RBAC is een autorisatiesysteem dat is Azure Resource Manager voor het inrichten van Azure-resources.

In Azure Cognitive Search wordt Resource Manager gebruikt om de service te maken of verwijderen, API-sleutels te beheren en de service te schalen. Als zodanig bepalen Azure-roltoewijzingen wie deze taken kan uitvoeren, ongeacht of ze de portal, PowerShellof de MANAGEMENT REST API's gebruiken.

Er zijn drie basisrollen gedefinieerd voor het beheer van de zoekservice. De roltoewijzingen kunnen worden gemaakt met behulp van elke ondersteunde methodologie (portal, PowerShell, enzovoort) en worden voor de hele service gebruikt. De rollen Eigenaar en Inzender kunnen diverse beheerfuncties uitvoeren. U kunt de rol Lezer toewijzen aan gebruikers die alleen essentiële informatie bekijken.

Gegevensbeveiliging

Op de opslaglaag is gegevensversleuteling ingebouwd voor alle door de service beheerde inhoud die op schijf is opgeslagen, inclusief indexen, synoniemenkaarten en de definities van indexeringen, gegevensbronnen en vaardighedensets. U kunt eventueel door de klant beheerde sleutels (CMK) toevoegen voor aanvullende versleuteling van geïndexeerde inhoud. Voor services die zijn gemaakt na 1 augustus 2020, wordt CMK-versleuteling uitgebreid naar gegevens op tijdelijke schijven, voor volledige 'dubbele versleuteling' van geïndexeerde inhoud.

Actieve gegevens

In Azure Cognitive Search begint versleuteling met verbindingen en verzendingen en wordt versleuteling uitgebreid naar inhoud die op schijf is opgeslagen. Voor zoekservices op het openbare internet luistert Azure Cognitive Search https-poort 443. Alle client-naar-service-verbindingen gebruiken TLS 1.2-versleuteling. Eerdere versies (1.0 of 1.1) worden niet ondersteund.

Versleutelde data-at-rest

In de volgende tabel worden de gegevensversleutelingsmodellen beschreven voor gegevens die intern worden verwerkt door de zoekservice. Sommige functies, zoals kennisopslag, incrementele verrijking en indexering op basis van indexering, lezen van of schrijven naar gegevensstructuren in andere Azure-services. Deze services hebben hun eigen versleutelingsniveaus die los staan van Azure Cognitive Search.

Door service beheerde sleutels

Door de service beheerde versleuteling is een interne bewerking van Microsoft, op basis van Azure Storage Service Encryption,met behulp van 256-bits AES-versleuteling. Dit gebeurt automatisch bij alle indexeringen, met inbegrip van incrementele updates voor indexen die niet volledig zijn versleuteld (gemaakt vóór januari 2018).

Door de klant beheerde sleutels (CMK)

Door de klant beheerde sleutels vereisen een extra factureerbare service, Azure Key Vault, die zich in een andere regio, maar onder hetzelfde abonnement, kan Azure Cognitive Search. Als u CMK-versleuteling inschakelen, neemt de indexgrootte toe en nemen de queryprestaties af. Op basis van waarnemingen tot nu toe kunt u een toename van 30%-60% verwachten in querytijden, hoewel de werkelijke prestaties variëren afhankelijk van de indexdefinitie en typen query's. Vanwege deze invloed op de prestaties raden we u aan deze functie alleen in teschakelen voor indexen waarvoor deze functie echt nodig is. Zie Door de klant beheerde versleutelingssleutels configureren in Azure Cognitive Search.

Dubbele versleuteling

In Azure Cognitive Search is dubbele versleuteling een uitbreiding van CMK. Het wordt begrepen als tweevoudige versleuteling (eenmaal door CMK en opnieuw door door de service beheerde sleutels) en uitgebreid in omvang, met langetermijnopslag die naar een gegevensschijf wordt geschreven en kortetermijnopslag die naar tijdelijke schijven wordt geschreven. Dubbele versleuteling wordt geïmplementeerd in services die zijn gemaakt na specifieke datums. Zie Dubbele versleuteling voor meer informatie.

Beveiligingsbeheer

API-sleutels

Afhankelijk zijn van verificatie op basis van API-sleutels betekent dat u een plan moet hebben om de beheersleutel regelmatig opnieuw te laten regenereren volgens de best practices voor Azure-beveiliging. Er zijn maximaal twee beheersleutels per zoekservice. Zie API-sleutels maken en beheren voor meer informatie over het beveiligen en beheren van API-sleutels.

Diagnostische en activiteitslogboeken

Cognitive Search registreert geen gebruikersidentiteiten, zodat u niet kunt verwijzen naar logboeken 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 de instantie 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 verwachte workloads. Zie Logboekgegevens verzamelen en analyseren en Queryaanvragen controleren voor meer informatie over het instellen van logboeken.

Certificering en compliance

Azure Cognitive Search wordt regelmatig gecontroleerd en is gecertificeerd volgens een aantal wereldwijde, regionale en branchespecifieke standaarden voor zowel de openbare cloud als de Azure Government. Download voor de volledige lijst het whitepaper Microsoft Azure Compliance Offerings (Nalevingsaanbiedingen) op de officiële pagina Auditrapporten.

Voor naleving kunt u Azure Policy de best practices voor hoge beveiliging van Azure Security Benchmark implementeren. Azure Security Benchmark is een verzameling beveiligingsaanbevelingen, gecodificeerd in beveiligingscontroles die zijn toe te staan aan de belangrijkste acties die u moet ondernemen om bedreigingen voor services en gegevens te beperken. Er zijn momenteel 11 beveiligingscontroles, waaronder netwerkbeveiliging, logboekregistratieen bewaking, en gegevensbeveiliging om er een paar te noemen.

Azure Policy is een functie die is ingebouwd in Azure waarmee u de naleving voor meerdere standaarden kunt beheren, waaronder die van Azure Security Benchmark. Voor bekende benchmarks biedt Azure Policy ingebouwde definities die zowel criteria als een actie-antwoord bieden dat niet-naleving aanpakt.

Voor Azure Cognitive Search is er momenteel één ingebouwde definitie. Dit is voor diagnostische logboekregistratie. Met deze ingebouwde kunt u een beleid toewijzen dat elke zoekservice identificeert die diagnostische logboekregistratie ontbreekt, en dit vervolgens inschakelen. Zie Besturingselementen voor naleving Azure Policy regelgeving voor meer Azure Cognitive Search.

Deze video bekijken

Bekijk deze video in snel tempo voor een overzicht van de beveiligingsarchitectuur en elke functiecategorie.

Zie ook

• Basisbeginselen van Azure Security
• Azure-beveiliging
• Microsoft Defender for Cloud