Megosztás a következőn keresztül:

Mindig titkosított biztonságos enklávékkal

A következőkre vonatkozik: SQL Server 2019 (15.x) és újabb verziók Windows Azure SQL Database-en

Az Always Encrypted biztonságos enklávékkal bővíti az Always Encrypted bizalmas számítási képességeit azáltal, hogy lehetővé teszi a helyszíni titkosítást és a gazdagabb bizalmas lekérdezéseket. Az Always Encrypted biztonságos enklávékkal az SQL Server 2019 (15.x) és újabb verzióiban, valamint az Azure SQL Database-ben érhető el.

Az Azure SQL Database-ben 2015-ben és az SQL Server 2016-ban (13.x) bevezetett Always Encrypted védi a bizalmas adatok bizalmasságát a kártevőktől és a magas jogosultságú jogosulatlan felhasználóktól: adatbázis-rendszergazdáktól (DBA-k), számítógép-rendszergazdáktól, felhőgazdák, vagy bárki más, aki jogos hozzáféréssel a kiszolgálópéldányokhoz, hardverekhez stb., de nem férhet hozzá a tényleges adatok egy részéhez vagy egészéhez.

A cikkben ismertetett fejlesztések nélkül az Always Encrypted az adatokat úgy védi, hogy titkosítja azokat az ügyféloldalon, és soha nem teszi lehetővé, hogy az adatok vagy a megfelelő titkosítási kulcsok egyszerű szövegként jelenjenek meg az adatbázismotorban. Ennek eredményeképpen az adatbázis titkosított oszlopainak funkciói szigorúan korlátozottak. A titkosított adatokon az adatbázismotor csak egyenlőségi összehasonlításokat hajthat végre (csak determinisztikus titkosítási). Az adatbázison belül nem támogatott minden más művelet, beleértve a titkosítási műveleteket (kezdeti adattitkosítás vagy kulcsforgatás) és a gazdagabb lekérdezéseket (például a mintaegyezést). A felhasználóknak át kell helyezniük az adataikat az adatbázison kívülre, hogy ezeket a műveleteket az ügyféloldalon hajthassák végre.

Az Always Encrypted biztonságos enklávékkal kezeli ezeket a korlátozásokat azáltal, hogy lehetővé teszi az egyszerű szöveges adatok bizonyos számításait egy biztonságos enklávéban a kiszolgálóoldalon. A biztonságos enklávé a memória védett régiója az adatbázismotor folyamatán belül. A biztonságos enklávé átlátszatlan dobozként jelenik meg az adatbázismotor többi része és az üzemeltető gép egyéb folyamatai számára. Az enklávéban kívülről nem lehet adatokat vagy kódot megtekinteni, még hibakeresővel sem. Ezek a tulajdonságok teszik a biztonságos enklávét egy megbízható végrehajtási környezetet, amely biztonságosan hozzáférhet a titkosítási kulcsokhoz és a bizalmas adatokhoz egyszerű szövegként, anélkül, hogy veszélyeztetné az adatok bizalmasságát.

Az Always Encrypted biztonságos enklávékat használ az alábbi ábrán látható módon:

Az Always Encrypted adatfolyamának diagramja.

Egy alkalmazás által küldött Transact-SQL utasítás elemzésekor az adatbázismotor megállapítja, hogy az utasítás tartalmaz-e olyan műveleteket titkosított adatokon, amelyek megkövetelik a biztonságos enklávé használatát. Ilyen állítások esetén:

  • Az ügyfélillesztő elküldi a műveletekhez szükséges oszloptitkosítási kulcsokat a biztonságos enklávénak (egy biztonságos csatornán keresztül), és elküldi az utasítást a végrehajtáshoz.

  • Az utasítás feldolgozásakor az adatbázismotor titkosítási műveleteket vagy számításokat delegál a titkosított oszlopokon a biztonságos enklávéba. Szükség esetén az enklávé visszafejti az adatokat, és egyszerű szöveges számításokat végez.

Az utasításfeldolgozás során az adatok és az oszloptitkosítási kulcsok nem jelennek meg egyszerű szövegben az adatbázismotorban a biztonságos enklávén kívül.

Támogatott ügyfélillesztők

Az Always Encrypted biztonságos enklávékkal való használatához az alkalmazásnak olyan ügyfélillesztőt kell használnia, amely támogatja a funkciót. Konfigurálja az alkalmazást és az ügyfélillesztőt az enklávészámítások és az enklávéigazolás engedélyezéséhez (lásd az alábbi Biztonságos enklávé igazolás szakaszt). További részletekért, beleértve a támogatott ügyfélillesztők listáját, lásd: Alkalmazások fejlesztése Always Encryptedhasználatával.

Támogatott enklávétechnológiák

Az Always Encrypted a következő enklávé technológiákat (vagy enklávétípusokat) támogatja:

Az adatbázishoz elérhető enklávé típusa az azt futtató SQL-terméktől (Azure SQL Database vs. SQL Server) és (az Azure SQL Database esetében) az adatbázis konfigurációjától függ.

  • Az SQL Server 2019 -ben (15.x) és újabb verziókban az Always Encrypted támogatja a VBS-enklávékat. (Az Intel SGX-enklávék nem támogatottak.)

  • Az Azure SQL Database-ben az adatbázisok intel SGX-enklávét vagy VBS-enklávét használhatnak, attól függően, hogy az adatbázis milyen hardveren van konfigurálva a futtatásra:

    Jegyzet

    A VBS-enklávék jelenleg minden Azure SQL Database-régióban elérhetők, kivéve: Jio India Central.

Az egyes enklávétípusok által biztosított szintvédelemről a Biztonsági szempontok című szakaszban olvashat.

Biztonságos enklávéigazolás

Az enklávéigazolás egy részletes védelmi mechanizmus, amely segít észlelni az enklávé kódjának vagy környezetének rosszindulatú rendszergazdák általi illetéktelen módosításával járó támadásokat.

Az enklávé-igazolás lehetővé teszi, hogy az ügyfélalkalmazás megbízhatóságot létesítsen az adatbázis biztonságos enklávéjával, amelyhez az alkalmazás csatlakozik, mielőtt az alkalmazás bizalmas adatok feldolgozásához használja az enklávét. Az igazolási munkafolyamat ellenőrzi, hogy az enklávé valódi VBS vagy Intel SGX enklávé-e, és hogy a benne futó kód az Always Encrypted eredetileg a Microsoft által aláírt enklávékönyvtára. Az igazolás során az alkalmazáson belüli ügyfélillesztő és az adatbázismotor is kommunikál egy külső igazolási szolgáltatással egy ügyfél által megadott végpont használatával.

Az Always Encrypted a két igazolási szolgáltatás egyikét használhatja:

Az Always Encrypted biztonságos enklávékkal való engedélyezéséhez be kell állítania egy igazolási protokollt az alkalmazás ügyfélillesztőjének konfigurációjában. Az igazolási protokoll értéke határozza meg, hogy 1) az ügyfélalkalmazás használni fogja-e az igazolást, és ha igen, 2) megadja a használni kívánt igazolási szolgáltatás típusát. Az alábbi táblázat az érvényes SQL-termék és enklávé típusú kombinációk támogatott igazolási protokolljait rögzíti:

Termék üzemeltetése Enklávé típusa Támogatott igazolási protokollok
SQL Server 2019 (15.x) és újabb verziók VBS-enklávék HGS, Nincs igazolás
Azure SQL Database SGX-enklávék (DC-sorozatú adatbázisok) Microsoft Azure-igazolás
Azure SQL Database VBS-enklávék Nincs igazolás

Néhány fontos szempont, amit fel kell hívni:

  • A VBS-enklávék igazolása az SQL Server 2019-ben (15.x) és újabb verzióiban HGS-t igényel. A VBS-enklávékat igazolás nélkül is használhatja (a legújabb ügyfélillesztőkre van szükség).
  • Az Azure SQL Database-ben az Intel SGX-enklávék (DC-sorozatú adatbázisokban) esetében az igazolás kötelező, és Microsoft Azure-igazolást igényel.
  • Az Azure SQL Database VBS-enklávéi nem támogatják az igazolást.

További információ:

Terminológia

Enklávé-kompatibilis kulcsok

A biztonságos enklávékkal ellátott Always Encrypted bevezeti az enklávé-kompatibilis kulcsok fogalmát:

  • Enklávé-kompatibilis oszlop főkulcsa – olyan oszlop master kulcs, amely az adatbázis ENCLAVE_COMPUTATIONS kulcs metaadat-objektumában megadott master tulajdonsággal rendelkezik. A kulcs metaadat-objektumának master oszlopnak tartalmaznia kell a metaadat-tulajdonságok érvényes aláírását is. További információért lásd: CREATE COLUMN MASTER KEY (Transact-SQL)
  • Enklávé-kompatibilis oszloptitkosítási kulcs – olyan oszloptitkosítási kulcs, amely enklávé-kompatibilis oszloptitkosítási master kulccsal van titkosítva. A biztonságos enklávén belüli számításokhoz csak enklávé-kompatibilis oszloptitkosítási kulcsok használhatók.

További információért tekintse meg: Az Always Encrypted kulcsainak kezelése biztonságos enklávékkal.

Enklávé-kompatibilis oszlopok

Az enklávé-engedélyezett oszlop egy enklávé-engedélyezett oszloptitkosítási kulccsal titkosított adatbázisoszlop.

Bizalmas számítási képességek enklávéval ellátott oszlopokhoz

A biztonságos enklávékkal rendelkező Always Encrypted két fő előnye a helyszíni titkosítás és a gazdag bizalmas lekérdezések.

Helyszíni titkosítás

A helyszíni titkosítás lehetővé teszi a titkosítási műveleteket az adatbázisoszlopokon a biztonságos enklávéban anélkül, hogy az adatokat az adatbázison kívülre helyezne. A helyszíni titkosítás javítja a titkosítási műveletek teljesítményét és megbízhatóságát. A ALTER TABLE (Transact-SQL) utasítással helyben történő titkosítást végezhet.

A helyben támogatott titkosítási műveletek a következők:

  • Egyszerű szöveges oszlop titkosítása enklávé-kompatibilis oszloptitkosítási kulccsal.
  • Titkosított enklávé-kompatibilis oszlop újratitkosítása a következőre:
    • Oszloptitkosítási kulcs elforgatása – az oszlop újratitkosítása új enklávé-kompatibilis oszloptitkosítási kulccsal.
    • Módosítsa például az enklávé-kompatibilis oszlopok titkosítási típusát determinisztikusról randomizáltra.
  • Enklávéval kompatibilis oszlopban tárolt adatok visszafejtése (az oszlop egyszerű szöveges oszlopmá alakítása).

A helyszíni titkosítás determinisztikus és véletlenszerű titkosítással is engedélyezett, mindaddig, amíg a titkosítási műveletben részt vevő oszloptitkosítási kulcsok enklávé-kompatibilisek.

Bizalmas lekérdezések

Jegyzet

Az SQL Server 2022 (16.x) további támogatást nyújt a titkosított oszlopok JOIN, GROUP BY és ORDER BY műveletekkel rendelkező bizalmas lekérdezéseihez.

A bizalmas lekérdezések DML-lekérdezések,, amelyek a biztonságos enklávéban végrehajtott enklávé-kompatibilis oszlopokon végzett műveleteket foglalják magukban.

A biztonságos enklávékban támogatott műveletek a következők:

Művelet Azure SQL Database SQL Server 2022 (16.x) SQL Server 2019 (15.x)
összehasonlító operátorok Támogatott Támogatott Támogatott
KÖZÖTT (Transact-SQL) Támogatott Támogatott Támogatott
IN (Transact-SQL) Támogatott Támogatott Támogatott
MINT (Transact-SQL) Támogatott Támogatott Támogatott
DISTINCT Támogatott Támogatott Támogatott
Csatlakozik Támogatott Támogatott Csak a beágyazott hurokillesztések támogatottak
SELECT - ORDER BY Klauszula (Transact-SQL) Támogatott Támogatott Nem támogatott
SELECT – GROUP BY- Transact-SQL Támogatott Támogatott Nem támogatott

Jegyzet

A fenti műveletek biztonságos enklávékban véletlenszerű titkosítást igényelnek. A determinisztikus titkosítás nem támogatott. Az egyenlőségi összehasonlítás továbbra is elérhető marad a determinisztikus titkosítást használó oszlopok esetében.

Az adatbázis kompatibilitási szintjét az SQL Server 2022 (160) vagy újabb verzióra kell állítani.

Az Azure SQL Database-ben és SQL Server 2022-ben (16.x) a karakterlánc oszlop enklávéit használó bizalmas lekérdezések (char, nchar) megkövetelik, hogy az oszlop bináris kódpont (_BIN2) rendezési sorrendet vagy UTF-8 rendezési sorrendet () használjon. Az SQL Server 2019-ben (15.x) a_BIN2 rendezés szükséges.

További információért lásd: Transact-SQL utasítások futtatása biztonságos enklávékkal.

Indexek enklávé-kompatibilis oszlopokon

Az enklávé-kompatibilis oszlopokon véletlenszerű titkosítással nem fürtözött indexeket hozhat létre annak érdekében, hogy a bizalmas DML-lekérdezések gyorsabban hajtsák végre a biztonságos enklávé használatával.

Annak érdekében, hogy egy véletlenszerű titkosítással titkosított oszlop indexe ne szivárogjon ki bizalmas adatokból, az index adatstruktúrájának (B-fa) kulcsértékeit a rendszer titkosítja és rendezi az egyszerű szöveges értékek alapján. A egyszerű szöveges érték szerinti rendezés az enklávéban lévő lekérdezések feldolgozásához is hasznos. Amikor az adatbázismotor lekérdezés-végrehajtója egy indexet használ egy titkosított oszlopon az enklávén belüli számításokhoz, az indexben megkeresi az oszlopban tárolt bizonyos értékeket. Az egyes keresések több összehasonlítást is tartalmazhatnak. A lekérdezés-végrehajtó minden összehasonlítást delegál az enklávéhoz, amely visszafejti az oszlopban tárolt értéket és az összehasonlítandó titkosított indexkulcs-értéket, elvégzi az összehasonlítást egyszerű szövegen, és visszaadja a végrehajtóval való összehasonlítás eredményét.

Az indexek véletlenszerű titkosítást használó és nem enklávé-kompatibilis oszlopokon történő létrehozása nem támogatott.

A determinisztikus titkosítást használó oszlop indexe titkosító szöveg (nem egyszerű szöveg) alapján van rendezve, függetlenül attól, hogy az oszlop enklávé-kompatibilis-e vagy sem.

További információért lásd: Indexek létrehozása és használata oszlopokon az Always Encrypted funkcióval, biztonságos enklávékat használva. Az adatbázismotor indexelésének működésével kapcsolatos általános információkért tekintse meg a „Fürtözött és nemfürtözött indexek ismertetése” című cikket.

Adatbázis-helyreállítás

Ha egy SQL Server-példány meghibásodik, előfordulhat, hogy az adatbázisai olyan állapotban maradnak, amelyben az adatfájlok tartalmazhatnak néhány módosítást a hiányos tranzakciókból. A példány indításakor egy adatbázis-helyreállításinevű folyamatot futtat, amely magában foglalja a tranzakciónaplóban található összes hiányos tranzakció visszaállítását annak érdekében, hogy az adatbázis sértetlensége megmaradjon. Ha egy hiányos tranzakció módosította az indexet, ezeket a módosításokat is vissza kell vonni. Előfordulhat például, hogy az index néhány kulcsértékét el kell távolítani vagy újra be kell adni.

Fontos

A Microsoft határozottan javasolja gyorsított adatbázis-helyreállítás (ADR) engedélyezését az adatbázis számára, , mielőtt létrehozzák az első indexet egy véletlenszerű titkosítással titkosított enklávé-kompatibilis oszlopon. Az ADR alapértelmezés szerint engedélyezve van az Azure SQL Database-ben és a felügyelt Azure SQL-példányban. Az ADR alapértelmezés szerint elérhető, de nem engedélyezett az SQL Server 2019 -ben (15.x) és újabb verzióiban.

A hagyományos adatbázis-helyreállítási folyamat (amely a ARIES helyreállítási modellt követi) az index módosításának visszavonásához az adatbázismotornak várnia kell, amíg egy alkalmazás megadja az oszlop oszloptitkosítási kulcsát az enklávénak, ami hosszú időt vehet igénybe. A gyorsított adatbázis-helyreállítás (ADR) jelentősen csökkenti a késleltetni kívánt visszavonási műveletek számát, mivel az oszloptitkosítási kulcs nem érhető el a gyorsítótárban az enklávéban. Következésképpen jelentősen növeli az adatbázisok rendelkezésre állását azáltal, hogy minimalizálja az új tranzakciók blokkolásának esélyét. Ha az ADR engedélyezve van, az adatbázismotornak továbbra is szüksége lehet egy oszloptitkosítási kulcsra a régi adatverziók törléséhez, de ezt háttérfeladatként végzi, amely nem befolyásolja az adatbázis vagy a felhasználói tranzakciók rendelkezésre állását. A hibanaplóban hibaüzenetek jelenhetnek meg, amelyek azt jelzik, hogy egy hiányzó oszloptitkosítási kulcs miatt meghiúsult a törlési művelet.

Biztonsági szempontok

A következő biztonsági szempontok a biztonságos enklávékkal rendelkező Always Encryptedre vonatkoznak.

  • A VBS-enklávék segítenek megvédeni az adatokat a virtuális gépen belüli támadásoktól. Azonban nem nyújtanak védelmet a gazdagépről származó kiemelt rendszerfiókokat használó támadások ellen. Az Intel SGX-enklávék védik az adatokat a vendég operációs rendszerből és a gazdagép operációs rendszeréből származó támadásoktól.
  • Az enklávé igazolás használata akkor ajánlott, ha az elérhető a környezet számára, és ha aggódik az adatoknak az adatbázist üzemeltető géphez való operációsrendszer-szintű rendszergazdai hozzáféréssel rendelkező felhasználók támadásaival szembeni védelmével szemben. Ha igazolást használ, győződjön meg arról, hogy az igazolási szolgáltatást és annak konfigurációját megbízható rendszergazda kezeli. Emellett mindkét támogatott igazolási szolgáltatás különböző szabályzatokat és igazolási módokat kínál, amelyek közül néhány minimálisan ellenőrzi az enklávét és a környezetét, és tesztelésre és fejlesztésre van kialakítva. Szigorúan kövesse az attestációs szolgáltatásra vonatkozó irányelveket, hogy biztosan az éles telepítésekhez ajánlott konfigurációkat és szabályzatokat használja.
  • Ha egy oszlopot véletlenszerű titkosítással, enklávéval kompatibilis oszloptitkosítási kulccsal titkosít, az az oszlopban tárolt adatok sorrendjének kiszivárgását eredményezheti, mivel az ilyen oszlopok támogatják a tartomány-összehasonlításokat. Ha például egy alkalmazottak fizetését tartalmazó titkosított oszlop indexet tartalmaz, a rosszindulatú DBA megvizsgálhatja az indexet, hogy megtalálja a maximális titkosított fizetést, és azonosítsa a maximális fizetéssel rendelkező személyt (feltéve, hogy a személy neve nincs titkosítva).
  • Ha az Always Encrypted használatával védi a bizalmas adatokat a dbA-k jogosulatlan hozzáférésétől, ne ossza meg az oszlop master kulcsokat vagy az oszloptitkosítási kulcsokat a ADATBÁZIS-okkal. A DBA anélkül kezelheti a titkosított oszlopok indexeit, hogy közvetlenül hozzáférne a kulcsokhoz az enklávéban található oszloptitkosítási kulcsok gyorsítótárával.

Az üzletmenet-folytonosság, a vészhelyreállítás és az adatmigrálás szempontjai

Ha magas rendelkezésre állású vagy vészhelyreállítási megoldást konfigurál egy adatbázishoz az Always Encrypted használatával biztonságos enklávékkal, győződjön meg arról, hogy minden adatbázis-replika használhat biztonságos enklávét. Ha egy enklávé elérhető az elsődleges replikához, de a másodlagos replikához nem, a feladatátvétel után minden olyan utasítás meghiúsul, amely az Always Encrypted funkcióját biztonságos enklávékkal próbálja használni.

Ha biztonságos enklávékkal másol vagy migrál egy adatbázist az Always Encrypted használatával, győződjön meg arról, hogy a célkörnyezet mindig támogatja az enklávékat. Ellenkező esetben az enklávékat használó utasítások nem működnek a másolaton vagy az áttelepített adatbázisban.

Az alábbi szempontokat érdemes szem előtt tartania:

  • SQL Server

    • Az Always On rendelkezésre állási csoportkonfigurálásakor győződjön meg arról, hogy a rendelkezésre állási csoportban adatbázist üzemeltető minden SQL Server-példány támogatja az Always Encryptedt biztonságos enklávékkal, és konfigurálta az enklávét és az igazolást.
    • Ha olyan adatbázis biztonsági mentési fájljából állítja vissza a visszaállítást, amely az Always Encrypted funkcióit használja biztonságos enklávékkal egy olyan SQL Server-példányon, amelyen nincs konfigurálva az enklávé, a visszaállítási művelet sikeres lesz, és minden olyan funkció elérhető lesz, amely nem támaszkodik az enklávéra. Az enklávé funkciót használó későbbi utasítások azonban sikertelenek lesznek, és a véletlenszerű titkosítást használó enklávé-kompatibilis oszlopok indexei érvénytelenek lesznek. Ugyanez vonatkozik arra az esetre is, ha az Always Encrypted használatával olyan biztonságos enklávékkal rendelkező adatbázist csatol a példányhoz, amelyen nincs konfigurálva az enklávé.
    • Ha az adatbázis véletlenszerű titkosítással tartalmaz indexeket az enklávé-kompatibilis oszlopokon, az adatbázis biztonsági mentésének létrehozása előtt mindenképpen engedélyezze gyorsított adatbázis-helyreállítást (ADR) az adatbázisban. Az ADR biztosítja, hogy az adatbázis, beleértve az indexeket is, azonnal elérhető legyen az adatbázis visszaállítása után. További információ: Database Recovery.

  • Azure SQL-adatbázis

    • Az aktív georeplikációs konfigurálásakor győződjön meg arról, hogy egy másodlagos adatbázis támogatja a biztonságos enklávékat, ha az elsődleges adatbázis igen.

Az SQL Serverben és az Azure SQL Database-ben, amikor bacpac-fájllal migrálja az adatbázist, a bacpac-fájl létrehozása előtt meg kell győződnie arról, hogy törli az enklávé-kompatibilis oszlopokhoz tartozó összes indexet, amelyeket véletlenszerű titkosítással használtak.

Ismert korlátozások

A biztonságos enklávékat használó Always Encrypted kezeli az Always Encrypted néhány korlátozását azáltal, hogy támogatja a helyben történő titkosítást és az indexekkel rendelkező, gazdagabb bizalmas lekérdezéseket, ahogy azt a Az enklávéval kompatibilis oszlopok bizalmas számítási képességeimagyarázzák.

A Korlátozások listán szereplő Always Encrypted minden egyéb korlátozása a biztonságos enklávékkal rendelkező Always Encryptedre is vonatkozik.

A következő korlátozások a biztonságos enklávékkal rendelkező Always Encryptedre vonatkoznak:

  • A fürtözött indexek nem hozhatók létre enklávé-kompatibilis oszlopokon véletlenszerű titkosítással.
  • A véletlenszerű titkosítást használó enklávé-kompatibilis oszlopok nem lehetnek elsődleges kulcsoszlopok, és nem hivatkozhatók idegen kulcsokra vagy egyedi kulcskorlátozásokra.
  • Az SQL Server 2019 -ben (15.x) (ez a korlátozás nem vonatkozik az Azure SQL Database-re vagy az SQL Server 2022-re (16.x)) csak a beágyazott hurokcsatlakozások (indexek használatával, ha vannak) támogatottak az enklávé-kompatibilis oszlopokon véletlenszerű titkosítással. A különböző termékek közötti egyéb különbségekről további információt Bizalmas lekérdezésekcímű témakörben talál.
  • A helyszíni titkosítási műveletek nem kombinálhatók az oszlop metaadatainak más módosításával, kivéve az ugyanabban a kódlapon belüli rendezést és a nullitást. Nem lehet például titkosítani, újratitkosítani vagy visszafejteni egy oszlopot, és egyetlen ALTER TABLE/ALTER COLUMN Transact-SQL utasításban módosítani az oszlop adattípusát. Két külön utasítást alkalmazzon.
  • Nem támogatott az enklávé-kompatibilis kulcsok használata a memóriabeli táblák oszlopaihoz.
  • A számított oszlopokat meghatározó kifejezések nem végezhetnek számításokat az enklávéval kompatibilis oszlopokon véletlenszerű titkosítással (még akkor sem, ha a számítások a Bizalmas lekérdezésektámogatott műveletek közé tartoznak).
  • A feloldó karakterek nem támogatottak a LIKE operátor paramétereiben az enklávéval kompatibilis oszlopokban véletlenszerű titkosítás használatával.
  • A LIKE operátorral vagy összehasonlító operátorral rendelkező lekérdezések, amelyek lekérdezési paraméterrel rendelkeznek az alábbi adattípusok egyikével (amelyek titkosítás után nagy objektumokká válnak) figyelmen kívül hagyják az indexeket, és táblavizsgálatokat végeznek.
    • nchar[n] és nvarchar[n], ha n nagyobb, mint 3967.
    • char[n], varchar[n], binary[n], varbinary[n], ha n nagyobb, mint 7935.
  • Az enklávéval kompatibilis oszlop master kulcsok tárolására csak a Windows Tanúsítványtároló és az Azure Key Vault támogatott kulcstárolói használhatók.
  • VBS enklávé-kompatibilis adatbázis visszaállításakor elengedhetetlen a VBS enklávébeállítás ismételt konfigurálása.

Kapcsolódó tartalom

  • Last updated on