Konfigurera kundhanterade nycklar för Azure AI-sökning krypterade data

Om du aktiverar kundhanterade nycklar (CMK) läggs ytterligare säkerhet ovanpå standardkrypteringen i vila när du använder Microsoft hanterade nycklar. När du aktiverar CMK kontrollerar du de krypteringsnycklar som används för att skydda dina data, inklusive möjligheten att:

• Rotera nycklar enligt ett kunddefinierat schema
• Inaktivera eller återkalla nycklar för att blockera åtkomst till krypterat innehåll (cachelagrade nycklar kan sparas i upp till 60 minuter)
• Granska nyckelanvändning via Azure Key Vault loggning

Azure AI-sökning använder din CMK som nyckelkrypteringsnyckel (KEK) för att kryptera och dekryptera de datakrypteringsnycklar som skyddar ditt innehåll. Den använder inte CMK för att kryptera eller dekryptera innehåll direkt.

Du kan skapa, lagra och hantera nycklar med hjälp av:

• Azure Key Vault

• Azure Key Vault Managed HSM (Maskinvarusäkerhetsmodul). En Azure Key Vault Managed HSM är en FIPS 140-2 Level 3-validerad HSM. Om du vill migrera från Azure Key Vault till HSM rotera dina nycklar och välj Hanterad HSM för lagring.

• Azure Key Vault Managed HSM extern nyckelhantering (EKM). Till skillnad från nycklar som lagras i Managed HSM finns externa nycklar kvar i ett kundhanterat HSM utanför Microsofts infrastruktur. Hanterade HSM dirigerar wrap- och unwrap-operationer till den HSM:n via en EKM-proxy.

Den här artikeln beskriver hur du konfigurerar CMK för ytterligare skydd av dina krypterade data i Azure AI-sökning.

Förutsättningar

• Azure AI-sökning på en fakturerbar nivå (Basic eller högre, i alla regioner).

• Azure Key Vault och ett nyckelvalv med soft-delete och purge protection aktiverat. Eller Azure Key Vault Managed HSM, inklusive extern nyckelhantering. Den här resursen kan finnas i valfri prenumeration och i en annan klientorganisation. Dessa instruktioner förutsätter en enda hyresgäst. Mer information om konfiguration mellan klientorganisationer finns i Konfigurera kundhanterade nycklar mellan olika klientorganisationer.

• För extern nyckelhantering krävs en hanterad HSM med EKM aktiverat i din prenumeration, en fungerande EKM-proxy och en RSA-nyckel i din externa HSM. Information om konfigurationskrav finns i Skapa din första externa nyckel med hjälp av Azure CLI.

• Om du planerar att konfigurera CMK på tjänstnivå ska du använda Search Management REST API-version 2026-03-01-preview eller senare. Om du vill kontrollera om ett objekt ärver en nyckel på tjänstnivå använder du API-version 2026-05-01-preview eller senare för dataplanets API.

• Möjlighet att konfigurera behörigheter för nyckelåtkomst och tilldela roller. Om du vill skapa nycklar använder du Key Vault Crypto Officer i Azure Key Vault eller Managed HSM Crypto User i Azure Key Vault Managed HSM.

  Om du vill tilldela Azure Key Vault-roller måste du vara Ägare, Administratör för användaråtkomst, Administratör för rollbaserad åtkomstkontroll eller ha tilldelats en anpassad roll med behörigheten Microsoft.Authorization/roleAssignments/write. Hanterad HSM-nyckelåtkomst kräver separata lokala RBAC-rolltilldelningsbehörigheter.

Konfigurera CMK för Azure AI-sökning objekt

Objekt med krypterade data som kan konfigureras med en kundhanterad nyckel (CMK) innehåller index, synonymlistor, indexerare, datakällor, vektoriserare och kompetensuppsättningar. Kryptering är beräkningsmässigt dyrt att dekryptera så endast känsligt innehåll krypteras.

Krypteringen utförs över:

• Allt innehåll i index och synonymlistor.

• Känsligt innehåll i indexerare, datakällor, kompetensuppsättningar och vektoriserare. Känsligt innehåll innehåller anslutningssträngar, beskrivningar, identiteter, nycklar och användarindata. Kompetensuppsättningar kan till exempel innehålla nycklar för anslutna tjänster, och vissa färdigheter tar emot användarinmatning, till exempel anpassade entiteter. I båda fallen krypteras nycklar och användarindata. Alla referenser till externa resurser, till exempel Azure datakällor eller Azure OpenAI-modeller, krypteras också.

Att lägga till en kundhanterad nyckel till ett objekt måste ske när objektet har skapats nyligen. Det är viktigt att tänka på:

• Du kan inte retroaktivt lägga till CMK i ett befintligt objekt. Om du vill lägga till en kundhanterad nyckel till ett befintligt objekt måste du ta bort och återskapa objektet med kryptering aktiverat.

• När CMK har konfigurerats sker kryptering varje gång tjänsten skriver data, inklusive både vilande data (långsiktig lagring) eller tillfälliga cachelagrade data (kortsiktig lagring). För objekt som datakällor, indexerare och kompetensuppsättningar krypteras objektdefinitionen. För index krypteras de indexerade dokumenten (inte bara indexschemat).

• Även om du inte kan lägga till kryptering i ett befintligt objekt kan du ändra alla delar av ett objekts krypteringsdefinition, inklusive att växla till ett annat nyckelvalv eller HSM-lagring, så länge resursen finns i samma klientorganisation.

• Kryptering med en CMK kan inte ångras. Du kan rotera nycklar och ändra CMK-konfiguration, men indexkryptering varar under indexets livslängd. Efter kryptering med CMK är ett index endast tillgängligt om söktjänsten har åtkomst till nyckeln. Om du återkallar åtkomsten till nyckeln genom att ta bort eller ändra rolltilldelningen är indexet oanvändbart och tjänsten kan inte skalas förrän indexet har tagits bort eller åtkomsten till nyckeln har återställts. Om du tar bort eller roterar nycklar cachelagras den senaste nyckeln i upp till 60 minuter.

• Om du behöver CMK i söktjänsten anger du en tillämpningspolicy.

• CMK-tillämpning med hjälp av Azure-policyer och CMK-konfiguration på servicenivå (som fortfarande är i förhandsversion) är oberoende inställningar. Du kan använda antingen eller båda, beroende på dina behov. Cmk-konfiguration på tjänstnivå tillämpar en standardnyckel på nya objekt, medan Azure Policy tvingande säkerställer att alla objekt uppfyller dina krypteringskrav. Om du aktiverar en CMK-tvingande princip utan en nyckel på tjänstnivå måste alla CMK-aktiverade objekt ange sin egen krypteringsnyckel när de skapas. Begäranden om att skapa objekt som utelämnar CMK-konfiguration misslyckas.

Aktivera cmk på tjänstnivå för nya objekt som standard (förhandsversion)

Från och med förhandsversionen 2026-03-01 kan du konfigurera en kundhanterad nyckel på tjänstnivå på själva Azure AI-sökning-tjänsten. Med den här funktionen kan du konfigurera nyckeln en gång och tillämpa den på alla nyligen skapade objekt som standard. Det skyddet skyddar känsliga data i söktjänsten med en nyckel som du styr, utan att du behöver ange nyckelinformation varje gång du skapar ett objekt. I api-versionen 2026-05-01-preview för dataplanet och senare hjälper egenskapen isServiceLevelKey på encryptionKey dig att avgöra om ett objekt ärver nyckeln på tjänstnivå eller använder en explicit objektnivånyckel.

Att aktivera CMK på tjänstnivå innebär:

• Alla ny objekt som skapats på din Azure AI-sökning-tjänst använder automatiskt kundhanterad nyckel på tjänstnivå som standard, så du behöver inte längre uttryckligen ange information om krypteringsnyckeln varje gång du skapar ett objekt.

• Den här funktionen är valfri och du kan fortsätta att konfigurera CMK per objekt. Du kan också åsidosätta nyckeln på tjänstnivå för enskilda objekt och rotera nyckeln på tjänstnivå oberoende av varandra, så att du kan använda olika nycklar för olika objekt efter behov.

Du kan åsidosätta den här standardnyckeln genom att ange en ny nyckel för det objekt som du skapar. Den nyckel på objektnivå som du anger åsidosätter standardnyckeln på tjänstnivå för objektet.

Välj mellan cmk på tjänstnivå och objektnivå

Använd cmk på tjänstnivå som standard för att tillämpa en enda nyckel på alla objekt. Du konfigurerar nyckeln en gång och nya objekt ärver det skyddet automatiskt.

Använd CMK på objektnivå för arbetsbelastningar som kräver en oberoende nyckellivscykel. Befintliga CMK-konfigurationer på objektnivå fortsätter att fungera utan ändringar. Cmk på servicenivå förenklar nyckelhantering men ersätter inte cmk på objektnivå.

Ett vanligt företagsmönster är att konfigurera en tjänstnivånyckel för de flesta objekt (indexerare, indexerare, datakällor, kompetensuppsättningar, vektoriserare och synonymkartor). Arbetsbelastningar med striktare efterlevnadskrav kan konfigurera en nyckel på objektnivå för att hantera åtkomst, rotation och återkallning oberoende av varandra.

Steg 1: Skapa en krypteringsnyckel

Skapa en nyckel i Azure Key Vault eller Azure Key Vault Managed HSM eller registrera en extern nyckelreferens i Managed HSM. Azure AI-sökning kryptering stöder RSA-nycklar i storlekarna 2048, 3072 och 4096. Dessa krav gäller även för externa nycklar. Mer information om nyckeltyper som stöds finns i Om nycklar.

Vi rekommenderar att du läser de här tipsen innan du börjar.

Nyckeln måste tillåta åtgärderna Packa in nyckel och Packa upp nyckel. Azure AI-sökning kräver inte Kryptera- eller Dekryptera-åtgärder på CMK:t.

Steg 2: Skapa en säkerhetsprincipal

Skapa ett säkerhetsobjekt som söktjänsten använder för åtkomst till krypteringsnyckeln. Du kan använda en hanterad identitets- och rolltilldelning, eller så kan du registrera ett program och låta söktjänsten ange program-ID:t på begäranden.

Använd en hanterad identitet och roller. Du kan använda antingen en systemhanterad identitet eller användarhanterad identitet. Med en hanterad identitet kan din söktjänst autentisera via Microsoft Entra ID, utan att lagra autentiseringsuppgifter (ApplicationID eller ApplicationSecret) i kod. Livscykeln för den här typen av hanterad identitet är kopplad till livscykeln för din söktjänst, som bara kan ha en systemtilldelad hanterad identitet. Mer information om hur hanterade identiteter fungerar finns i Vad är hanterade identiteter för Azure resurser.

Steg 3: Bevilja behörigheter

Ge söktjänstens säkerhetsobjekt dessa lägsta behörigheter för nyckelåtkomst: Hämta (läsa nyckelmetadata), Wrap Key och Unwrap Key. Dessa behörigheter gäller för Azure Key Vault, Managed HSM och externa nycklar som refereras i Managed HSM.

Följande roller ger dessa nyckeldatabehörigheter utan att bevilja behörigheter för Encrypt, Decrypt eller nyckelhantering:

Rollbaserad åtkomstkontroll rekommenderas över åtkomstprincipens behörighetsmodell. Om du vill ha mer information eller migreringssteg börjar du med Azure rollbaserad åtkomstkontroll (Azure RBAC) jämfört med åtkomstprinciper (äldre).

Om du använder en äldre Key Vault-åtkomstprincip beviljar du endast Get, Wrap Key och Unwrap Key till säkerhetsidentiteten.

För Azure Key Vault använder du följande steg för att tilldela rollen till din söktjänsts hanterade identitet:

1. Gå till nyckelvalvet i Azure-portalen.

2. Välj Åtkomstkontroll (IAM) och välj Lägg till rolltilldelning.

3. Välj Key Vault Crypto Service Encryption User.

4. Välj hanterade identiteter, välj medlemmar och välj sedan söktjänstens hanterade identitet. Om du testar lokalt tilldelar du även den här rollen till dig själv.

5. Välj Granska + Tilldela.

Vänta några minuter tills rolltilldelningen tas i drift.

För Hanterad HSM, inklusive referenser till externa nycklar, tilldelar du Managed HSM Crypto Service Encryption User via managed HSM local RBAC. Du kan begränsa tilldelningen till /keys/<key-name> för att endast bevilja åtkomst till CMK och dess versioner. Instruktioner för rolltilldelning finns i Åtkomstkontroll för Managed HSM.

Key Vault brandvägg och åtkomst till virtuella nätverk för CMK

Azure AI-sökning måste kunna komma åt krypteringsnyckeln i Azure Key Vault.

Om nyckelvalvet använder en brandvägg eller begränsningar för virtuella nätverk konfigurerar du något av följande alternativ:

• Tillåt åtkomst från valda nätverk som innehåller din söktjänst.
• Aktivera Tillåt betrodda Microsoft-tjänster för att kringgå brandväggen.

När förbikoppling av betrodda tjänster är aktiverat kan Azure AI-sökning komma åt nyckeln som en betrodd tjänst med hjälp av hanterad identitet, även när åtkomsten till det offentliga nätverket är begränsad.

Om brandväggen blockerar åtkomst och förbikoppling av betrodda tjänster inte är aktiverat kan Azure AI-sökning inte hämta nyckeln och CMK-beroende åtgärder misslyckas.

Steg 4: Lägg till krypteringsnyckel information till Azure AI-sökning-objekt

När du skapar ett krypterat objekt anger du nyckelvalvets URI, nyckelnamn och nyckelversion. Om du använder ett Microsoft Entra ID program för autentisering anger du även program-ID och hemlighet.

För externa nycklar ställer du in de befintliga CMK-egenskaperna till Managed HSM-slutpunkten (keyVaultUri), nyckelreferensnamnet (keyVaultKeyName) och versionen (keyVaultKeyVersion). Använd inte EKM-proxy-URL:en eller den externa nyckelidentifieraren. Konfigurera externa nycklar via Azure AI-sökning REST-API:er, inte portalen.

Om du vill lägga till en kundhanterad nyckel i ett sökobjekt kan det här vara ett index, indexerare, datakälla, kompetensuppsättning, vektoriserare eller synonymkarta. Du kan konfigurera nyckeln på tjänstnivå eller objektnivå.

Tjänstnivå: Genom att konfigurera en kundhanterad nyckel på tjänstnivå tillämpas den nyckeln som standard på alla nyligen skapade sökobjekt. Det gäller inte för befintliga sökobjekt.

Objektnivå: Du kan också definiera en ny, unik nyckel på objektnivå när du skapar ett nytt sökobjekt. Den här nyckeldefinitionen på objektnivå åsidosätter standardnyckeln på tjänstnivå.

Om du vill konfigurera CMK för ett objekt använder du Azure-portalen, Search Service REST API:er eller en Azure SDKs.

Konfigurera CMK på tjänstnivå (förhandsversion)

Om du vill aktivera CMK-konfiguration på tjänstnivå använder du REST API:et för sökhantering eller ett Azure SDKs paket som har uppdaterats för att stödja REST API-version 2026-03-01 eller senare. Den Azure portalen har ännu inte stöd för den här funktionen. När du aktiverar CMK på tjänstnivå lägger du inte till kryptering i befintliga objekt, men du tillämpar samma nyckel som standard på alla nyligen skapade objekt i tjänsten om du inte anger en annan objektnivånyckel för att åsidosätta standardvärdet på tjänstnivå.

PATCH https://management.azure.com/subscriptions/{{subscription-id}}/resourceGroups/{{resource-group}}/providers/Microsoft.Search/searchServices/{{search-service}}?api-version=2026-03-01-preview
Authorization: Bearer {{token}}
Content-Type: application/json

{
  "encryptionWithCmk": {
    "serviceLevelEncryptionKey": {
      "keyVaultUri": "<YOUR-KEY-VAULT-URI>",
      "keyVaultKeyName": "<YOUR-ENCRYPTION-KEY-NAME>",
      "keyVaultKeyVersion": "<YOUR-ENCRYPTION-KEY-VERSION>"
    }
  }
}

{
  "encryptionWithCmk": {
    "serviceLevelEncryptionKey": {
      "keyVaultUri": "<YOUR-KEY-VAULT-URI>",
      "keyVaultKeyName": "<YOUR-ENCRYPTION-KEY-NAME>",
      "keyVaultKeyVersion": "<YOUR-ENCRYPTION-KEY-VERSION>",
      "identity": {
        "@odata.type": "#Microsoft.Azure.Search.DataUserAssignedIdentity",
        "userAssignedIdentity": "/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<your-managed-identity-name>"
      }
    }
  }
}

{
  "encryptionWithCmk": {
    "serviceLevelEncryptionKey": {
          "keyVaultUri": "<YOUR-KEY-VAULT-URI>",
          "keyVaultKeyName": "<YOUR-ENCRYPTION-KEY-NAME>",
          "keyVaultKeyVersion": "<YOUR-ENCRYPTION-KEY-VERSION>",
          "accessCredentials": {
                  "applicationId": "<YOUR-APPLICATION-ID>",
                  "applicationSecret": "<YOUR-APPLICATION-SECRET>"
      }       
    }
  }
}

Kontrollera om ett sökobjekt ärver CMK på tjänstenivå

Om du vill kontrollera om ett sökobjekt använder en kundhanterad nyckel som konfigurerats på tjänstnivå som standard eller en unik kundhanterad nyckel som konfigurerats på objektnivå kontrollerar du det ärvda krypteringstillståndet isServiceLevelKey med hjälp av egenskapen .

GET https://{{search-service}}.search.windows.net/indexes/{{index-name}}?api-version=2026-08-01-preview
api-key: {{admin-api-key}}

{
  "name": "hotels-cmk",
  "fields": [
    {
      "name": "id",
      "type": "Edm.String",
      "key": true,
      "searchable": false,
      "retrievable": true
    }
  ],
  "encryptionKey": {
    "keyVaultUri": "<YOUR-KEY-VAULT-URI>",
    "keyVaultKeyName": "<YOUR-ENCRYPTION-KEY-NAME>",
    "keyVaultKeyVersion": "<YOUR-ENCRYPTION-KEY-VERSION>",
    "isServiceLevelKey": true
  }
}

PUT https://{{search-service}}.search.windows.net/indexes/{{index-name}}?api-version=2026-08-01-preview
api-key: {{admin-api-key}}
Content-Type: application/json

{
  "name": "regulated-index",
  "fields": [
    {
      "name": "id",
      "type": "Edm.String",
      "key": true,
      "searchable": false,
      "retrievable": true
    }
  ],
  "encryptionKey": {
    "keyVaultUri": "<YOUR-KEY-VAULT-URI>",
    "keyVaultKeyName": "<YOUR-ENCRYPTION-KEY-NAME>",
    "keyVaultKeyVersion": "<YOUR-ENCRYPTION-KEY-VERSION>",
    "isServiceLevelKey": false
  }
}

PUT https://{{search-service}}.search.windows.net/indexes/{{index-name}}?api-version=2026-08-01-preview
api-key: {{admin-api-key}}
Content-Type: application/json

{
  "name": "regulated-index",
  "fields": [
    {
      "name": "id",
      "type": "Edm.String",
      "key": true,
      "searchable": false,
      "retrievable": true
    }
  ],
  "encryptionKey": {
    "isServiceLevelKey": true,
    "keyVaultUri": "<SERVICE-LEVEL-KEY-VAULT-URI>",
    "keyVaultKeyName": "<SERVICE-LEVEL-KEY-NAME>",
    "keyVaultKeyVersion": "<SERVICE-LEVEL-KEY-VERSION>"
  }
}

Steg 5: Testa kryptering

Kontrollera att krypteringen fungerar genom att återkalla krypteringsnyckeln, fråga indexet (det bör vara oanvändbart) och sedan återställa krypteringsnyckeln.

För nycklar som lagras i Azure Key Vault använder du Azure-portalen för det här testet. Se till att du har en rolltilldelning som ger läsbehörighet till nyckeln.

1. På sidan Azure Key Vault väljer du Objects>Keys.

2. Välj den nyckel som du skapade och välj sedan Ta bort.

3. På sidan Azure AI-sökning väljer du Search management>Indexes.

4. Välj ditt index och använd Sökutforskaren för att köra en fråga. Du förväntas få ett felmeddelande.

5. Gå tillbaka till sidan Azure Key Vault Objects>Keys.

6. Välj Hantera borttagna nycklar.

7. Välj din nyckel och välj sedan Återställ.

8. Gå tillbaka till ditt index i Azure AI-sökning och kör frågan igen. Du kan se sökresultat. Om du inte ser några omedelbara resultat väntar du en minut och försöker igen.

Konfigurera en princip för att framtvinga CMK-efterlevnad

Azure principer bidrar till att upprätthålla organisationens standarder och utvärdera efterlevnad i stor skala. Azure AI-sökning har två valfria inbyggda principer relaterade till CMK. Dessa principer gäller för nya och befintliga söktjänster.

Tilldela en princip

1. I Azure-portalen navigerar du till en inbyggd princip och väljer sedan Assign.

   • AuditIfExists

   • Förneka

   Här är ett exempel på principen AuditIfExists i Azure-portalen:

   

2. Ange principomfånget genom att välja prenumerationen och resursgruppen. Exkludera söktjänster som principen inte ska gälla för.

3. Acceptera eller ändra standardvärdena. Välj Granska + skapa och klicka sedan på Skapa.

Aktivera CMK-policyns genomdrivande

När du tilldelar en princip till en resursgrupp i din prenumeration börjar den gälla omedelbart. Granskningsprinciper flaggar icke-kompatibla resurser, men Neka principer förhindrar skapande och uppdatering av icke-kompatibla söktjänster. I det här avsnittet beskrivs hur du skapar en kompatibel söktjänst eller uppdaterar en tjänst för att göra den kompatibel. För att göra objekt kompatibla, börja vid steg ett i den här artikeln.

Skapa en kompatibel söktjänst

För nya söktjänster skapar du dem med SearchEncryptionWithCmk inställt på Enabled.

Varken Azure-portalen eller kommandoradsverktygen (Azure CLI och Azure PowerShell) tillhandahåller den här egenskapen internt, men du kan använda Hantera REST API för att etablera en söktjänst med en CMK-principdefinition.

### Create a search service (provide an existing resource group)
@resource-group = my-rg
@search-service-name = my-search
PUT https://management.azure.com/subscriptions/{{subscriptionId}}/resourceGroups/{{resource-group}}/providers/Microsoft.Search/searchServices/{{search-service-name}}?api-version=2025-05-01 HTTP/1.1
     Content-type: application/json
     Authorization: Bearer {{token}}

    {
        "location": "North Central US",
        "sku": {
            "name": "basic"
        },
        "properties": {
            "replicaCount": 1,
            "partitionCount": 1,
            "hostingMode": "default",
            "encryptionWithCmk": {
                "enforcement": "Enabled"
        }
      }
    }

Uppdatera en befintlig söktjänst

För befintliga söktjänster som nu inte är kompatibla korrigerar du dem med hjälp av Services – Update API eller kommandot Azure CLI az resource update. Genom att korrigera tjänsterna återställs möjligheten att uppdatera söktjänstens egenskaper.

PATCH https://management.azure.com/subscriptions/<your-subscription-Id>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Search/searchServices/<your-search-service-name>?api-version=2025-05-01

{
  "properties": {
      "encryptionWithCmk": {
          "enforcement": "Enabled"
      }
  }
}

az resource update --name SEARCH-SERVICE-PLACEHOLDER --resource-group RESOURCE-GROUP-PLACEHOLDER --resource-type searchServices --namespace Microsoft.Search --set properties.encryptionWithCmk.enforcement=Enabled

"encryptionWithCmk": {
      "encryptionComplianceStatus": "NonCompliant",
      "enforcement": "Enabled"
    }
...

Rotera eller uppdatera krypteringsnycklar

Använd följande instruktioner för att rotera nycklar eller migrera från Azure Key Vault till maskinvarusäkerhetsmodulen (HSM).

För nyckelrotation använder du funktionerna autorotation i Azure Key Vault. Om du använder autorotation utelämnar du nyckelversionen i objektdefinitioner. Den senaste nyckeln används i stället för en specifik version.

När du ändrar en nyckel eller dess version uppdaterar du alla objekt som använder nyckeln för att använda de nya värdena innan du tar bort de gamla värdena. Annars blir objektet oanvändbart eftersom det inte kan dekrypteras.

Om du har konfigurerat CMK på tjänstnivå gäller rotation av tjänstnivånyckeln för nyligen skapade objekt framöver. Objekt som redan ärvt den tidigare nyckeln på tjänstnivå hämtar automatiskt den nya nyckeln, så du behöver inte uppdatera dem. Men om du har några objekt som har konfigurerats med en nyckel på objektnivå som du också vill rotera, måste du uppdatera objekten så att de använder den nya nyckeln.

Nycklar cachelagras i 60 minuter. Kom ihåg detta när du testar och roterar nycklar.

1. Fastställ nyckeln som används av en index- eller synonymkarta.

2. Skapa en ny nyckel i nyckelvalvet, men lämna den ursprungliga nyckeln tillgänglig. I det här steget kan du växla från nyckelvalv till HSM.

3. Uppdatera encryptionKey-egenskaperna på en index- eller synonymkarta för att använda de nya värdena. Endast objekt som ursprungligen skapades med den här egenskapen kan uppdateras för att använda ett annat värde.

4. Inaktivera eller ta bort den tidigare nyckeln i nyckelvalvet. Övervaka åtkomsten till nyckeln för att kontrollera att den nya nyckeln används.

Av prestandaskäl cachelagrar söktjänsten nyckeln i upp till flera timmar. Om du inaktiverar eller tar bort nyckeln utan att ange en ny, fortsätter frågorna att fungera tillfälligt tills cacheminnet upphör att gälla. Men när söktjänsten inte längre kan dekryptera innehåll får du följande meddelande: "Access forbidden. The query key used might have been revoked - please retry."

Key Vault-råd

• Om du inte har Azure Key Vault kan du läsa den här snabbstarten om du vill veta mer om grundläggande uppgifter: Set och hämta en hemlighet från Azure Key Vault med hjälp av PowerShell.

• Använd så många nyckelvalv som du behöver. Hanterade nycklar kan finnas i olika nyckelvalv. En söktjänst kan ha flera krypterade objekt, var och en krypterad med en annan kundhanterad krypteringsnyckel, lagrad i olika nyckelvalv.

• Använd samma Azure klient så att du kan hämta din hanterade nyckel via rolltilldelningar och genom att ansluta via ett system eller en användarhanterad identitet. Mer information om hur du skapar en klient finns i Konfigurera en ny klient.

• Om din Azure Key Vault skyddas med en brandvägg måste du aktivera Tillåt betrodda Microsoft-tjänster för att kringgå brandväggen så att Azure AI-sökning kan komma åt nyckeln.

• Aktivera rensningsskydd och mjuk borttagning i ett nyckelvalv. På grund av krypteringens natur med kundhanterade nycklar kan ingen hämta dina data om din Azure Key Vault nyckel tas bort. För att förhindra dataförlust som orsakas av oavsiktliga Key Vault nyckelborttagningar måste skydd mot mjuk borttagning och rensning aktiveras på key vault. Mjuk borttagning är aktiverat som standard, så du får bara problem om du inaktiverar det avsiktligt. Rensningsskydd är inte aktiverat som standard, men det krävs för kryptering med en CMK i Azure AI-sökning.

• Aktivera loggning på nyckelvalvet så att du kan övervaka nyckelanvändningen.

• Aktivera autorotering av nycklar eller följ strikta procedurer under rutinmässig rotation av nyckelvalvsnycklar och programhemligheter och registrering. Uppdatera alltid allt krypterat innehåll för att använda nya hemligheter och nycklar innan du tar bort de gamla. Om du missar det här steget kan innehållet inte dekrypteras.

Arbeta med krypterat innehåll

Med hjälp av CMK kan du märka svarstider för både indexering och frågor på grund av det extra krypterings-/dekrypteringsarbetet. Azure AI-sökning loggar inte krypteringsaktiviteten, men du kan övervaka nyckelåtkomst via nyckelvalvsloggning.

Vi rekommenderar att du aktiverar loggning som en del av key vault-konfigurationen.

1. Skapa en log analytics-arbetsyta.

2. Lägg till en diagnostikinställning i nyckelvalvet som använder arbetsytan för datakvarhållning.

3. Välj granskning eller allLogs för kategorin, ge diagnostikinställningen ett namn och spara den.

FAQs

Kan jag ändra ett sökobjekt mellan en kundhanterad nyckel som definierats på tjänstnivå och en kundhanterad nyckel som definierats på objektnivå?

• Yes. När du konfigurerar CMK på tjänstnivå använder varje nytt sökobjekt den nyckeln som standard. Om du konfigurerar en annan nyckel i objektnivådefinitionen prioriteras nyckeln på objektnivå framför nyckeln på tjänstnivå. Om du tar bort nyckeldefinitionen på objektnivå återgår sökobjektet som standard till den kundhanterade nyckel som definierats på tjänstnivå.

Nästa steg

Om du inte känner till Azure säkerhetsarkitektur läser du dokumentationen Azure Security och i synnerhet den här artikeln: