OneLake-suojaus SQL-analytiikan päätepisteille

OneLake-turvallisuuden myötä Microsoft Fabric laajentaa tapaa, jolla organisaatiot voivat hallita ja valvoa dataa access eri työkuormien välillä. Tämä tietoturvakehys antaa ylläpitäjille enemmän joustavuutta käyttöoikeuksien konfigurointiin. Järjestelmänvalvojat voivat valita keskitetyn hallinnan OneLaken kautta tai yksityiskohtaisen SQL-pohjaisen hallinnan SQL-analytiikan päätepisteessä.

Access-tilat SQL-analytiikan päätepisteessä

Kun käytetään SQL-analytiikkapäätepistettä, valittu access-tila määrää, miten tietoturvaa valvotaan. Fabric tukee kahta erillistä access-mallia, joista kumpikin tarjoaa erilaisia etuja operatiivisten ja vaatimustenmukaisuuden tarpeidesi mukaan:

  • Käyttäjän käyttäjätietotila: Valvoo suojausta OneLake-roolien ja -käytäntöjen avulla. Tässä tilassa SQL-analytiikan päätepiste välittää kirjautuneen käyttäjän identiteetin OneLakelle, ja lukukäyttö määräytyy kokonaan OneLaken määrittelemien turvallisuussääntöjen mukaan. SQL-tason käyttöoikeudet ei-data-objekteille (näkymät, tallennetut proseduurit, funktiot) ovat tuettuja, mikä takaa johdonmukaisen hallinnan työkalujen, kuten Power BI:n, notebookien ja lakehousen välillä.

  • Delegoitu käyttäjätietotila: Tarjoaa täyden hallinnan SQL:n kautta. Tässä tilassa SQL-analytiikan päätepiste muodostaa yhteyden OneLakeen käyttämällä työtilan tai kohteen omistajan käyttäjätietoja, ja suojausta säätelevät yksinomaan tietokannassa määritetyt SQL-käyttöoikeudet . Tämä malli tukee perinteisiä suojausmenetelmiä, kuten GRANT, REVOKE, mukautetut roolit, Row-Level Security ja Dynamic Data Masking.

Kukin tila tukee erilaisia hallintomalleja. Niiden vaikutusten ymmärtäminen on välttämätöntä, jotta voit valita oikean lähestymistavan Fabric-ympäristössäsi.

Tärkeää

SQL-analytiikkapäätepisteen käyttämiseen vaaditaan artefaktin käyttöoikeus. Yhdistääkseen ja kysyäkseen dataa SQL-analytiikkapäätepisteen kautta, käyttäjillä tulee olla lukuoikeus päätepisteeseen liittyvälle artefaktille. Jos käyttäjällä ei ole ohjaustason pääsyä artefaktiin (esimerkiksi työtilan roolien käyttöoikeus tai eksplisiittinen kohdeoikeus), yhteys SQL-analytiikkapäätepisteeseen hylätään, riippumatta mahdollisista SQL-oikeuksista, joita kyseiselle käyttäjälle voi olla.

Vertailu access-tilojen välillä

Seuraava taulukko vertaa, miten ja missä tietoturva asetetaan käyttäjän identiteettitilassa verrattuna delegoidun identiteettitilan muotoon, jaoteltuna objektityypin ja tiedonkäyttöpolitiikan mukaan:

Turvallisuuskohde Käyttäjän identiteettitila Delegoidun henkilöllisyyden tila
Taulukot Access on OneLake-turvallisuusroolien hallinnassa. GRANT / REVOKE SQL ei ole sallittu. Täysi hallinta SQL:n GRANT/REVOKEavulla.
Näkymät Käytä SQL GRANT/REVOKE :ää käyttöoikeuksien määrittämiseen. Käytä SQL GRANT/REVOKE :ää käyttöoikeuksien määrittämiseen.
Tallennetut menettelyt Käytä SQL GRANT EXECUTE :ää käyttöoikeuksien määrittämiseen. Käytä SQL GRANT EXECUTE :ää käyttöoikeuksien määrittämiseen.
Funktiot Käytä SQL GRANT EXECUTE :ää käyttöoikeuksien määrittämiseen. Käytä SQL GRANT EXECUTE :ää käyttöoikeuksien määrittämiseen.
Row-Level suojaus (RLS) Määritetty OneLake-käyttöliittymässä osana OneLaken käyttöoikeusrooleja. Määritelty SQL CREATE SECURITY POLICY:llä .
Column-Level Turvallisuus (CLS) Määritetty OneLake-käyttöliittymässä osana OneLaken käyttöoikeusrooleja. Määritelty SQL GRANT SELECT :llä ja sarakkeelistalla.
Dynaaminen tietojen peittäminen (DDM) Ei tueta OneLaken suojauksessa. Määritetty käyttämällä SQL:ää ALTER TABLE ja MASKED vaihtoehtoa.

Käyttäjän käyttäjätietotila OneLaken suojauksessa

Käyttäjäidentiteettitilassa SQL-analytiikan päätepiste käyttää läpivientitodennusmekanismia datan access valvomiseen. Kun käyttäjä muodostaa yhteyden SQL-analytiikan päätepisteeseen, hänen Entra ID -tunnus -identiteettinsä välitetään OneLakeen, joka suorittaa käyttöoikeuksien tarkistuksen. Kaikki taulujen lukutoiminnot arvioidaan OneLake Lakehousen turvallisuussääntöjen mukaisesti, ei SQL-tason GRANT tai REVOKE lauseiden avulla.

Tämän tilan avulla voit hallita suojausta keskitetysti ja varmistaa yhdenmukaisen täytäntöönpanon kaikissa Fabric-kokemuksissa, mukaan lukien Power BI, muistikirjat, lakehouse ja SQL-analytiikan päätepiste. Se on suunniteltu hallintomalleihin, joissa access tulisi määritellä OneLakessa ja kunnioittaa automaattisesti kaikkialla.

Käyttäjän identiteettitilassa:

  • Pöytä-access on täysin OneLake-turvallisuuden valvonnassa. GRANT / REVOKE SQL-lauseet taulukoissa jätetään huomiotta.

  • RLS (Row-Level Security), CLS (Column-Level Security) ja Object-Level Security on kaikki määritetty OneLake-kokemuksessa.

  • SQL-käyttöoikeudet sallitaan muille kuin tietoobjekteille, kuten näkymille, tallennetuille toimintosarjoille ja funktioille, mikä mahdollistaa joustavuuden mukautetun logiikan tai käyttäjälle suunnattujen tietojen aloituskohtien määrittämisessä.

  • Kirjoitustoimintoja ei tueta SQL-analytiikan päätepisteessä. Kaikkien kirjoitusten on tehtävä Lakehouse-sivun kautta Fabric-portaalissa, ja niitä ohjaavat työtilan roolit (Ylläpitäjä, Jäsen, Avustaja).

Tärkeää

Yksi-yhteen -identiteettikartoitus tuottajan ja kuluttajan (hub-and-spoke) välillä. Kun OneLake-turvakäytännöt siirretään tuottajalta (lähdealkio, jossa rooli määritellään) kuluttajalle (kohdekohde, joka käyttää dataa pikakuvakkeen kautta), tuottajan OneLake-turvallisuusrooleihin liitetyt identiteetit on määritettävä täsmälleen 1:1 kuluttajalle. Sama periaate – oli kyseessä käyttäjä tai ryhmä – on myönnettävä Fabric Read -lupa kuluttajaartefaktille kuin tuottajan turvallisuusroolissa mainittu. Sisäkkäistä tai tehokasta ryhmäjäsenyyttä ei ratkaista tämän rajan yli.

Esimerkiksi, jos tuottajan OneLake-turvallisuusrooli viittaa user123@microsoft.com, niin user123@microsoft.com (juuri tuo Object ID) on myös Fabric Read permission kuluttaja-lakehousessa. Samoin, jos tuottajarooli viittaa Group A:iin, Group A itsessään täytyy myöntää kuluttajalle Fabric lukulupa – luvan myöntäminen vain ryhmän A jäsenelle ei täytä vastaavuutta.

Lisätietoja käyttöoikeusmallista ja käyttäjän identiteettitilasta löytyy OneLake-tietoturvan tietojen käyttöoikeuksien hallintamallista .

Suojauksen synkronointi OneLaken ja SQL-analytiikan päätepisteen välillä

Käyttäjän käyttäjätietotilan kriittinen osa on suojauksen synkronointipalvelu. Tämä taustapalvelu valvoo OneLaken käyttöoikeusrooleihin tehtyjä muutoksia ja varmistaa, että muutokset näkyvät SQL-analytiikan päätepisteessä.

Suojauksen synkronointipalvelu vastaa seuraavista:

  • OneLake-roolien muutosten havaitseminen, mukaan lukien uudet roolit, päivitykset, käyttäjämääritykset ja taulukoiden muutokset.

  • OneLaken määrittämien käytäntöjen (RLS, CLS, OLS) kääntäminen vastaaviksi SQL-yhteensopiviksi tietokantaroolirakenteiksi.

  • Varmista, että pikakuvakeobjektit (muista lakehouseista hankitut taulukot) on validoitu oikein, jotta alkuperäisiä OneLaken suojausasetuksia noudatetaan, vaikka niitä käytettäisiin etänä.

Tämä synkronointi varmistaa, että OneLaken suojausmääritykset pysyvät hallitsevina, jolloin manuaalisia SQL-tason toimenpiteitä ei tarvita suojauskäyttäytymisen replikoimiseksi. Koska suojausta valvotaan keskitetysti:

  • Et voi määrittää rivitason suojausta, CLS:ää tai OLS:ää suoraan T-SQL:n avulla tässä tilassa.

  • Voit edelleen soveltaa SQL-oikeuksia näkymiin, funktioihin ja tallennettuihin proseduureihin käyttämällä GRANT lauseita EXECUTE .

Security sync retry backoff

Tietoturvasynkronointi sisältää uudelleenyrittämisen peruutusmekanismin, joka suojaa järjestelmän vakautta ja välttää tarpeetonta laskentakulutusta:

  • Jos toistuvia virheitä ilmenee OneLake-tietoturvarooleja sovellettaessa SQL-analytiikkapäätepisteeseen, järjestelmä voi tilapäisesti keskeyttää automaattiset synkronointiyritykset.

  • Synkronointi jatkuu automaattisesti, kun olemassa olevaa OneLake-turvaroolia muutetaan tai uusi luodaan.

Tietoturvasynkronointivirheet ja resoluutio

Skenaario Käyttäytyminen käyttäjätietotilassa Käyttäytyminen delegoidussa tilassa Korjaavat toimet Muistiinpanot
RLS-käytäntö viittaa poistettuun tai uudelleen nimettyyn sarakkeeseen Virhe: Rivitason turvallisuuspolitiikka viittaa sarakkeeseen, jota ei enää ole olemassa. Tietokanta siirtyy virhetilaan, kunnes käytäntö korjataan. Virhe: Virheellinen sarakkeen nimi <sarakkeen nimi> Päivitä tai poista yksi tai useampi rooli, jota ongelma koskee, tai palauta puuttuva sarake. Päivitys on tehtävä järvimajassa, jossa rooli luotiin.
CLS-käytäntö viittaa poistettuun tai uudelleen nimettyyn sarakkeeseen Virhe: Saraketason turvallisuuspolitiikka viittaa sarakkeeseen, jota ei enää ole olemassa. Tietokanta siirtyy virhetilaan, kunnes käytäntö korjataan. Virhe: Virheellinen sarakkeen nimi <sarakkeen nimi> Päivitä tai poista yksi tai useampi rooli, jota ongelma koskee, tai palauta puuttuva sarake. Päivitys on tehtävä järvimajassa, jossa rooli luotiin.
RLS/CLS-käytäntö viittaa poistettuun tai uudelleennimettyyn taulukkoon Virhe: Suojauskäytäntö viittaa taulukkoon, jota ei enää ole olemassa. Virhettä ei tullut esiin; Kysely epäonnistuu äänettömästi, jos taulukko puuttuu. Päivitä tai poista yksi tai useampi rooli, jota ongelma koskee, tai palauta puuttuva taulukko. Päivitys on tehtävä järvimajassa, jossa rooli luotiin.
DDM (Dynamic Data Masking) -käytäntö viittaa poistettuun tai uudelleen nimettyyn sarakkeeseen DDM:ää ei tueta OneLake-tietoturvasta; täytyy toteuttaa SQL:n kautta. Virhe: Virheellinen sarakkeen nimi <sarakkeen nimi> Päivitä tai poista yksi tai useampi DDM-sääntö, jota ongelma koskee, tai palauta puuttuva sarake. Päivitä DDM-käytäntö SQL-analytiikan päätepisteessä.
Järjestelmävirhe (odottamaton vika) Virhe: Tapahtui odottamaton järjestelmävirhe. Yritä uudelleen tai ota yhteyttä tukeen. Virhe: Sisäinen virhe on tapahtunut käytettäessä taulukon muutoksia SQL:ään. Yritä operaatio uudelleen; Jos ongelma jatkuu, ota yhteyttä Microsoft-tuki. –
Käyttäjällä ei ole artefaktin käyttöoikeutta Virhe: Käyttäjällä ei ole artefaktin käyttöoikeutta Virhe: Käyttäjällä ei ole artefaktin käyttöoikeutta Anna käyttäjälle objectID {objectID} lupa artefaktiin. Objektitunnuksen on vastattava tarkasti OneLake-käyttöoikeusroolin jäsentä ja Fabric-kohteen käyttöoikeuksia. Jos ryhmä lisätään roolijäsenyyteen, sille ryhmälle on annettava Fabric Read -lupa. Kyseisen ryhmän jäsenen lisäämistä kohteeseen ei lasketa suoraksi vastaavuudeksi.
Käyttäjäperiaatetta ei tueta Virhe: Käyttäjän päänimeä ei tueta. Virhe: Käyttäjän päänimeä ei tueta. Poista käyttäjä {username} roolista DefaultReader. Tämä virhe ilmenee, jos käyttäjä ei enää ole voimassa oleva Entra ID -tunnus (esimerkiksi käyttäjä on poistunut organisaatiosta tai poistettu). Poista heidät roolista virheen korjaamiseksi.

Pikakomentojen toiminta suojauksen synkronoinnin kanssa

OneLaken suojausta valvotaan totuuden lähteellä, joten suojauksen synkronointi poistaa käytöstä oikopolkuja sisältävien taulukoiden ja näkymien omistajuuden ketjuttamisen. Näin varmistetaan, että lähdejärjestelmän käyttöoikeudet arvioidaan ja niitä kunnioitetaan aina, myös toisesta tietokannasta tulevissa kyselyissä.

Tämän seurauksena:

  • Käyttäjillä tulee olla voimassa oleva access molemmat pikakuvakkeessa source (nykyinen Lakehouse- tai SQL-analytiikan päätepiste) jadestination jossa data fyysisesti sijaitsee.

  • Jos käyttäjällä ei ole oikeuksia kummallakaan puolella, kyselyt epäonnistuvat käyttöoikeusvirheen vuoksi.

  • Kun suunnittelet sovelluksia tai näkymiä, jotka viittaavat pikakuvakkeihin, varmista, että roolijakot on oikein konfiguroitu molemmissa pikakuvakeiden päissä .

Tämä suunnittelu säilyttää tietoturvan eheyden Lakehousen rajojen yli, mutta se tuo mukanaan tilanteita, joissa access-epäonnistumiset voivat tapahtua, jos Lakehousen roolit eivät ole linjassa.

Delegoitu tila OneLaken suojauksessa

Delegoidussa identiteettitilassa SQL-analytiikan päätepiste säilyttää taaksepäin yhteensopivuuden perinteisen SQL-tietoturvamallin kanssa. Turvallisuus määritellään ja valvotaan SQL-moottorikerroksessa, eikä OneLaken turvallisuusroolit ja käyttöoikeudet siirry taulukkotason pääsyyn. Kaikki suodatus ja käyttöoikeuksien hallinta—mukaan lukien pääsy skeemoihin ja tauluihin, Row-Level Security (RLS), Column-Level Security (CLS) ja Dynamic Data Masking (DDM)—on määriteltävä SQL-rakenteilla (GRANT/REVOKE, tietoturvakäytännöt jne.).

Koska OneLake-tietoturvarooleja loppukäyttäjälle ei valvota suoraan, OneLakessa määritellyt tietoturvasäännöt (esimerkiksi Sparkin tai muiden OneLake-moottoreiden valvomat säännöt) eivät päde, kun samaa dataa haetaan SQL-analytiikkapäätepisteen kautta. Valitse tämä tila, kun työkuorma perustuu SQL-natiivien turvallisuussemantiikkaan tai kun olemassa olevat T-SQL-työkalut vaativat täydellistä yhteensopivuutta.

Kun käyttäjä muodostaa yhteyden SQL-analytiikan päätepisteeseen ja lähettää kyselyn:

  • SQL validoi kyselyn SQL-kerroksessa määriteltyjen oikeuksien perusteella.

  • Jos kysely on valtuutettu, järjestelmä siirtyy access dataan, joka on tallennettu OneLake.

  • Tämä tietojen käyttö tapahtuu Lakehouse- tai SQL-analytiikan päätepisteen omistajan, eli tuotetilin, henkilöllisyyden, ei kirjautuneen käyttäjän avulla.

Kohteen omistaja on siis vastuussa siitä, että hänellä on riittävät oikeudet OneLakessa lukeakseen taustalla olevat tiedostot työkuorman puolesta. Mahdollinen epäkohdistus loppukäyttäjille myönnettyjen SQL-oikeuksien ja kohteen omistajan OneLake-käyttöoikeuksien välillä johtaa kyselyvirheisiin.

Tämä tila tukee olemassa olevia T-SQL-työkaluja ja käytäntöjä, joita DBA:t tai sovellukset käyttävät, ja tarjoaa täyden yhteensopivuuden SQL GRANT/REVOKE :lle kaikilla objektitasoilla sekä SQL-määritellylle RLS:lle, CLS:lle ja DDM:lle.

Pikakuvakeiden käyttäytyminen delegoidussa tilassa

Koska delegoitu tila yhdistyy OneLakeen esineen omistajan identiteetin kautta, pikakuvakkeet toimivat vain, kun omistajalla on rajoittamaton pääsy koko lähdetauluun. Jos lähdetaulussa on käytössä jokin OneLake-tason tietoturvasääntö—kuten Row-Level Security (RLS), Column-Level Security (CLS)—SQL-analytiikkapäätepiste estää pääsyn kyseiseen pikakuvakkeen.

Tämän seurauksena:

  • Pikakuvakkeet, jotka osoittavat lähdetauluihin ilman datatason tietoturvasääntöjä , toimivat normaalisti delegoidussa tilassa.

  • Oikokuvakkeet, jotka osoittavat lähdetauluihin, joissa on RLS tai CLS OneLake-turvallisuudessa tuottajalla , eivät ole käytettävissä SQL-analytiikan päätepisteen kautta delegoidussa tilassa, vaikka loppukäyttäjällä olisi SQL-oikeudet pikakuvakeobjektiin.

  • Jos haluat käyttää oikoteitä, joiden lähdekoodissa on OneLake-turvallisuuskäytännöt, käytä käyttäjäidentiteettitilaa kuluttajapäätepisteessä, jotta loppukäyttäjän identiteetti arvioidaan lähteen OneLake-turvallisuussääntöjen mukaan.

Kuinka muuttaa OneLake-access-tilaa

Pääsytila määrittää, miten datan käyttö todennetaan ja valvotaan, kun OneLakea haetaan SQL-analytiikkapäätepisteen kautta. Voit vaihtaa käyttäjätietotilan ja delegoidun käyttäjätietotilan välillä seuraavasti:

  1. Siirry Fabric-työtilaan ja avaa lakehouse. Oikeasta yläkulmasta vaihda lakehousesta SQL-analytiikkapäätepisteeseen.

  2. Ylhäältä navigoinnista siirry Security-välilehdelle ja valitse yksi seuraavista OneLake-käyttötavoista:

    • Käyttäjätiedot – Käyttää kirjautuneen käyttäjän käyttäjätietoja. Valvoo OneLake-rooleja.

    • Delegoitu identiteetti – Käyttää kohteen omistajan identiteettiä. Valvoo vain SQL-käyttöoikeuksia.

  3. Ponnahdusikkuna avautuu valintasi vahvistamiseksi. Vahvista muutos valitsemalla Kyllä .

Tärkeää

Turvallisuustilan vaihtaminen tekee SQL-analytiikan päätepisteistä tilapäisesti käyttökelvottomia koko työtilassa. Tämä toiminto peruuttaa kaikki käynnissä olevat ja jonoon asetetut kyselyt kaikissa SQL-analytiikan päätepisteissä kyseisessä työtilassa. Tilaa voi vaihtaa vain tarvittaessa, mieluiten muualla kuin työajalla, jotta käyttökatkot vältyvät.

Huomioitavaa tilojen välillä vaihdettaessa

Tärkeää

Käyttäjäidentiteetin ja delegoitujen tilojen välillä vaihtaminen (kumpaankin suuntaan) poistaa tällä hetkellä inline-metatietoobjektit, mukaan lukien taulukkoarvoiset funktiot (TVF:t) ja skalaarin arvoiset funktiot. Tämä käyttäytyminen vaikuttaa vain metatietomäärittelyihin; OneLaken taustalla oleva data ei ole muuttunut.

Siirtyminen käyttäjän identiteettitilaan

  • SQL RLS-, CLS- ja taulukkotason käyttöoikeudet ohitetaan.

  • OneLake-roolit on konfiguroitava käyttäjien ylläpitämään accessia.

  • Vain käyttäjät, joilla on Viewer-oikeudet tai jaettu vain luku -oikeus, ovat OneLake-turvallisuuden alaisia.

  • Olemassa olevat SQL-roolit poistetaan eikä niitä voi palauttaa.

Siirtyminen delegoidun henkilöllisyyden tilaan

  • OneLake-rooleja ja suojauskäytäntöjä ei enää käytetä.

  • SQL-roolit ja suojauskäytännöt aktivoituvat.

  • Esineen omistajalla täytyy olla voimassa oleva OneLake-access, muuten kaikki kyselyt voivat epäonnistua.

Huomautuksia

  • SQL-objektit eivät peri omistajuutta: Pikakuvakkeet toimivat tauluina SQL-analytiikan päätepisteessä, mutta poikkeavat tarkoituksellisesti tavallisesta SQL-omistajuuden ketjutuksesta yhtenäisen turvallisuustilanteen ylläpitämiseksi.

    • Ei-perintösääntö: Johdetut SQL-objektit (näkymät, tallennetut proseduurit tai funktiot) eivät peri oikeuksia objektin omistajalta.

    • Ajonaikainen validointi: Käyttöoikeudet tarkistetaan kutsujan identiteettiä vastaan suoritushetkellä, mikä varmistaa, että SQL-abstraktiot eivät voi kiertää OneLake-tason politiikkoja.

    • Turvallisuus suunnittelun mukaan: Turvallisuuspolitiikat pysyvät yhtenäisinä riippumatta siitä, käytetäänkö dataa SQL:n, Sparkin tai Power BI:n kautta.

  • Ohjaustason riippuvuus (tiukka identiteetin vastaavuus): OneLake-turvallisuus edellyttää, että tuottajan myöntämän pääsyn identiteetti on sama identiteetti, joka tunnistetaan kuluttajadatatasolla saavutettavuuden arvioinnissa. Järjestelmä vahvistaa tietyn päähenkilön, jolle on myönnetty pääsy lähteellä, eikä laajenna sisäkkäistä ryhmäjäsenyyttä tai päättele tehokasta pääsyä epäsuoran jäsenyyden kautta.

    • Kirjaimellinen pääosuma: Pääsy arvioidaan tuottajalle myönnetyn täsmällisen objekti-ID:n perusteella.

    • Ei sisäkkäistä tai tehokasta ratkaisua: Sisäkkäinen ryhmäjäsenyys tai epäsuora periytyminen ei ole riittävä toimeenpanon kannalta. Katso OneLake Securityn User Identity -tilassa oleva kutsu työskennellystä esimerkistä.

  • Käyttöoikeuksien arviointikäyttäytyminen: Käyttöoikeuksien arviointi vaihtelee taulutyypin mukaan nykyisen valvontamallin mukaan.

    • Pikakuvaketaulukot: Pääsy voidaan evätä, jos vaaditut valtuutusehdot eivät täytty. Tämä on rajoittava valvontaratkaisu, ei roolipohjainen DENY-ominaisuus OneLake-tietoturvassa.

    • Yleinen sääntö: Kun täytäntöönpano ei voi selkeästi validoida pääsyä, järjestelmä soveltaa kaikkein rajoittavinta lopputulosta.

  • Column-Level Turvallisuus (CLS) -suunnittelu: CLS ylläpitää tiukkaa sarakkeiden lupalistaa.

    • Sallitun sarakkeen uudelleennimeäminen tai poistaminen mitätöi turvallisuussäännön. Vaikka sääntö jatkuu järjestelmässä, se pysyy passiivisena – estäen kaiken pääsyn resurssiin – kunnes alkuperäinen sarakkeen nimitys palautetaan.

    • Synkronointisuojaus: Kun käytäntö on virheellinen, metatietojen synkronointi estetään suunnittelun mukaan, kunnes sääntö korjataan OneLake-turvapaneelissa.

    • Skeeman validointi: Sarakkeiden uudelleennimeäminen ilman tietoturvakäytäntöjen päivittämistä aiheuttaa käyttöliittymävirheitä, joissa kerrotaan, että saraketta "ei ole olemassa" ennen kuin konfiguraatio on synkronoitu.

  • Roolien leviäminen ja synkronointi (SLA):

    • OneLake-turvallisuussynkronointi: Kun OneLake-turvallisuusrooli muuttuu käyttäjätunnustilassa, päivitys ei ole välitön. Vaikka se on yleensä nopeaa, sen synkronointi SQL-analytiikan päätepisteen kanssa voi kestää jopa 5 minuuttia .

    • Automaattinen etuliite: OneLake-turvallisuusroolit siirtyvät SQL-analytiikkapäätepisteelle etuliitteen OLS_ kautta.

    • Synkronointiprioriteetti: Tietoturvan synkronointiprosessi päivittää roolien tilaa OLS_ säännöllisesti. Manuaalisia muutoksia näihin rooleihin ei tueta ja ne ylikirjoitetaan seuraavan synkronointisyklin aikana. Jos synkronointiin ei tapahdu muutoksia, suojaussynkronointi ei ohita manuaalisia muutoksia.

  • Varaston SQL-turvallisuus ja pikakuvakkeet: Turvallisuuspolitiikat, jotka on määritelty SQL-rakenteilla varastossa—kuten Row-Level Security (RLS), Column-Level Security (CLS) tai Object-Level Security (OLS)—toteutetaan vain varaston SQL-suorituskontekstissa (TDS-päätepiste).

Tärkeää

Kun Warehouse-dataa päästään käsiksi OneLake-pikanäppäimillä, näitä SQL-turvallisuussemantiikkaa ei käännetä OneLake-turvallisuuspolitiikoiksi. Tämän seurauksena käyttäjät, jotka käyttävät dataa pikanäppäimen kautta, voivat nähdä koko aineiston riippumatta lähdevaraston SQL-turvallisuuskäytännöistä.

Rajoitukset

  • Koskee vain lukijoita: OneLake-suojausta valvotaan ensisijaisesti käyttäjille, jotka käyttävät dataa Viewer-tason työtilan tai esineiden käytön kautta. Käyttäjät, joilla on laajempi työtilan rooli, kuten ylläpitäjä, jäsen tai osallistuja , säilyttävät korotetun pääsyn eivätkä ole OneLake-tietoturvan ensisijainen kohde.

    • Poikkeukset:

      • Pikakuvakeiden eston käyttäytyminen: Oikokuvakkeiden tauluissa valvonta voi edelleen estää pääsyn ylläpitäjiltä, jäseniltä tai osallistujilta tietyissä tapauksissa.

      • Tietoturvasynkronoinnin epäonnistumistapaukset: Jos tietoturvasynkronointi ei sovella turvallisuutta oikein tietyille tauluille tai rooleille, Admin-, Member- tai Contributor-rooleissa, jotka kuuluvat kyseisiin rooleihin, voivat myös kokea rajoitettua pääsyä.

      • RLS käyttäjäidentiteettitilassa: Kun Row-Level Security (RLS) on konfiguroitu käyttäjäidentiteettitilassa, määritellyt tietoturvasäännöt otetaan käyttöön kaikille käyttäjille, mukaan lukien ylläpitäjä-, jäsen- ja osallistujaroolit.

  • Skeeman näkyvyys objektimetatiedoissa: SQL-analytiikan päätepiste palauttaa aina kaikki skeeman nimet objektimetatiedoissa, riippumatta käyttäjän taulutason oikeuksista. Taulut, joihin käyttäjällä ei ole lupaa, suodatetaan pois eivätkä näy listauksessa.

    • Tämän seurauksena käyttäjät saattavat nähdä skeemoja, joissa ei ole näkyviä taulukoita objektinhallinnassa tai INFORMATION_SCHEMA/sys luettelokyselyissä.

  • Tietoturvan synkronointiriippuvuus: Käyttäjäidentiteettitilassa OneLake-turvallisuusroolit synkronoidaan SQL-analytiikan päätepisteen kanssa tietoturvasynkronointiprosessin kautta. Kunnes synkronointi on valmis, SQL voi väliaikaisesti arvioida pääsyä olemassa olevalla SQL-käyttöoikeustilalla. Kun synkronointi on valmis, SQL-päätepiste heijastaa OneLake-tietoturvakonfiguraatiota.

  • Pikakuvakeiden rajatietoisuus: SQL-analytiikan päätepiste voi aluksi arvioida pikakuvakkeiden tauluja standardien SQL-objektisemantiikan avulla. Tietoturvan synkronoinnin jälkeen OneLake-turvallisuuskäytännöt otetaan käyttöön varmistamaan, että pääsyn valvonta on linjassa artefaktien ja työtilan rajojen kanssa.

  • Ristiin-artefaktien pääsyn valvonta: Pääsy tauluihin, joita tukevat OneLake-pikakuvakkeet, jotka viittaavat muihin artefaktien tietoihin, valvotaan synkronoitujen OneLake-suojausrooleiden kautta. Kunnes synkronointi tapahtuu, SQL-valtuutus voi tilapäisesti heijastaa aiempaa käyttöoikeustilaa.

  • Omistajuuden muutokset pikakuvakkeiden tauluissa: Oikotepohjaiset taulut esitetään SQL-objekteina SQL-analytiikan päätepisteessä ja tukevat siksi standardeja SQL-omistusoperaatioita. Hallinnolliset komennot, kuten , ALTER AUTHORIZATION voivat vaihtaa oikotepohjaisen taulun omistajaa. Tietyissä tilanteissa tämä voi sallia omistajuuden ketjuttamisen, joka ohittaa OneLake-tietoturvakäytännöt ja antaa tahattoman pääsyn taustalla olevaan dataan. Kunnes lisävalvontamekanismeja otetaan käyttöön, ylläpitäjien tulisi välttää omistajuuden muuttamista oikotepohjaisilla tauluilla.

  • Kohteen validoinnin käyttökatko: Kun pikakuvake muuttuu (esim. uudelleennimeäminen tai URL-päivitys), tietokanta siirtyy hetkellisesti yksikäyttäjätilaan samalla kun järjestelmä vahvistaa uuden kohteen. Tänä aikana kyselyt estetään. Nämä toiminnot ovat tyypillisesti nopeita, mutta sisäisistä prosesseista riippuen niiden synkronointi voi kestää jopa 5 minuuttia.

    • Rakenteen pikakuvakkeiden luominen saattaa aiheuttaa tunnetun virheen, joka vaikuttaa vahvistukseen ja viivästyttää metatietojen synkronointia.

  • Delegoitu tila tokenien välimuisti: Delegoidussa tilassa SQL-analytiikkapäätepiste välimuistittaa tallennuskäyttötokenin, jota käytetään datan noutoon OneLakesta omistajan identiteetin puolesta. Jos omistajan oikeudet muuttuvat, aiemmin myönnetty token voi pysyä voimassa siihen asti, kunnes se vanhenee. Tämän seurauksena omistajan identiteettiin liittyvät käyttöoikeusmuutokset eivät välttämättä astu voimaan välittömästi ja voivat jatkua tokenin vanhenemiseen asti, tyypillisesti jopa 30–60 minuutin ajan.

  • OneLaken tietoturvan GRANT/DENY-käytäntöjen muutokset otetaan käyttöön välittömästi, eikä tallennustokenien välimuisti viivästy.

  • Aktiivisen kyselyn peruutus: Tietojen eheyden ja turvallisuuden ylläpitämiseksi aktiiviset kyselyt voidaan peruuttaa automaattisesti, jos pikakuvakekonfiguraatio muuttuu suorituksen aikana.

  • Row-Level Turvallisuusrajoitteet (RLS):

    • Julkisessa esikatselussa tuetaan vain yksittäisiä ilmaisutaulukoita. Dynaamisia RLS- ja monipöytä-RLS:ää ei ole saatavilla.

    • Suodatinlausekkeen sarakkeen poistaminen pysäyttää metatietojen synkronoinnin, kunnes RLS on korjattu OneLake-turvapaneelissa.

  • Roolien monimutkaisuus ja metatietojen synkronointi: Korkea monimutkaisuus turvallisuusrooleissa – erityisesti niissä, joissa on lukuisia risteyksiä ja yhdisteiden semantiikkaa RLS:n avulla – voi aiheuttaa tietoturvasynkronoinnin epäonnistumisen. Epäonnistunut tietoturvasynkronointi estää turvallisuuspolitiikkojen soveltamisen ja estää metatietojen synkronoinnin.

  • Skeema ja roolirajoitteet:

    • Uudelleennimetykset: OneLake-tietoturvaroolit ovat sidottu taulun nimeen. Taulukon uudelleennimeäminen rikkoo assosiaation, eikä käytännöt siirry automaattisesti. Tämä voi johtaa tahattomaan tietojen altistumiseen, kunnes käytäntöjä käytetään uudelleen.

    • Merkkirajoitukset: OneLake-turvaroolien nimet eivät saa ylittää 124 merkkiä; muuten roolien luonti tai synkronointi epäonnistuu SQL-analytiikan päätepisteessä.

    • OLS_ Roolimuutokset: Käyttäjän roolimuutoksia OLS_ ei tueta ja ne voivat aiheuttaa odottamattomia käyttäytymismalleja.

  • Tuettomat identiteetit: Sähköpostiin kytketyt turvaryhmät ja jakelulistat eivät tällä hetkellä ole tuettuja.

  • Lakehouse-omistajan vaatimukset:

    • Järvenrakennuksen omistajan tulee olla Admin-, Jäsen- tai Avustajan työtilan jäsen; muuten tietoturvaa ei sovelleta SQL-analytiikan päätepisteisiin.

    • Lakehousen omistaja ei voi olla palvelun päänimi, jotta suojauksen synkronointi toimii.

Liittyvä sisältö

  • Last updated on