Del via

Microsoft Fabric-sikkerhedsscenarie fra ende til anden

  • Artikel

Sikkerhed er et vigtigt aspekt af enhver dataanalyseløsning, især når den omfatter følsomme eller fortrolige data. Derfor leverer Microsoft Fabric et omfattende sæt sikkerhedsfunktioner, der gør det muligt for dig at beskytte dine data under inaktive og under overførsel samt styre adgang og tilladelser for dine brugere og programmer.

I denne artikel får du mere at vide om Fabric-sikkerhedsbegreber og -funktioner, der med sikkerhed kan hjælpe dig med at bygge din egen analyseløsning med Fabric.

Baggrund

I denne artikel præsenteres et scenarie, hvor du er datatekniker og arbejder for en sundhedsorganisation i USA. Organisationen indsamler og analyserer patientdata, der stammer fra forskellige systemer, herunder elektroniske sundhedsjournaler, laboratorieresultater, forsikringskrav og bærbare enheder.

Du planlægger at bygge et lakehouse ved hjælp af medaljonsarkitekturen i Fabric, som består af tre lag: bronze, sølv og guld.

  • Bronzelaget gemmer rådata, når de modtages fra datakilderne.
  • Silver-laget anvender kontrol og transformationer af datakvaliteten for at forberede dataene til analyse.
  • Guldlaget indeholder aggregerede og forbedrede data til rapportering og visualisering.

Mens nogle datakilder er placeret på dit lokale netværk, er andre bag firewalls og kræver sikker, godkendt adgang. Der er også nogle datakilder, der administreres i Azure, f.eks. Azure SQL Database og Azure Storage. Du skal oprette forbindelse til disse Azure-datakilder på en måde, der ikke viser data på det offentlige internet.

Du har besluttet at bruge Fabric, fordi det sikkert kan indtage, gemme, behandle og analysere dine data i cloudmiljøet. Det er vigtigt, at den gør det, samtidig med at den overholder reglerne i din branche og organisationens politikker.

Da Fabric er SaaS (Software as a Service), behøver du ikke at klargøre individuelle ressourcer, f.eks. lager- eller beregningsressourcer. Du skal bare bruge en Fabric-kapacitet.

Du skal konfigurere krav til dataadgang. Du skal specifikt sikre, at det kun er dig og dine meddatateknikere, der har adgang til dataene i lakehouseets bronze- og sølvlag. Disse lag er stedet, hvor du planlægger at udføre datarensning, validering, transformation og berigelse. Du skal også begrænse adgangen til dataene i guldlaget. Kun autoriserede brugere, herunder dataanalytikere og forretningsbrugere, bør have adgang til guldlaget. De kræver denne adgang for at bruge dataene til forskellige analyseformål, f.eks. rapportering, maskinel indlæring og forudsigende analyser. Dataadgangen skal begrænses yderligere af brugerens rolle og afdeling.

Opret forbindelse til Fabric (indgående beskyttelse)

Du konfigurerer først indgående beskyttelse, som handler om, hvordan du og andre brugere logger på og har adgang til Fabric.

Da Fabric er udrullet til en Microsoft Entra-lejer, håndteres godkendelse og godkendelse af Microsoft Entra. Du logger på med en Microsoft Entra-organisationskonto (arbejds- eller skolekonto). Derefter skal du overveje, hvordan andre brugere opretter forbindelse til Fabric.

Microsoft Entra-lejeren er en sikkerhedsgrænse for identiteter, der er under it-afdelingens kontrol. Inden for denne sikkerhedsgrænse udføres administrationen af Microsoft Entra-objekter (f.eks. brugerkonti) og konfigurationen af indstillinger for hele lejeren af it-administratorer. På samme måde som med alle SaaS-tjenester isolerer Fabric logisk lejere. Andre lejere kan aldrig få adgang til data og ressourcer i din lejer, medmindre du udtrykkeligt giver dem tilladelse til at gøre det.

Her er, hvad der sker, når en bruger logger på Fabric.

Diagram, der viser en repræsentation på højt niveau af Fabric-sikkerhedsarkitekturen. Elementerne i diagrammet er beskrevet i følgende tabel.

Punkt Beskrivelse
Brugeren åbner en browser (eller et klientprogram) og logger på Fabric-portalen.
Brugeren omdirigeres straks til Microsoft Entra ID, og vedkommende skal godkendes. Godkendelse bekræfter, at det er den korrekte person, der logger på.
Når godkendelsen er fuldført, modtager webfrontend brugerens anmodning og leverer frontendindhold (HTML og CSS) fra den nærmeste placering. Anmodningen distribueres også til metadataplatformen og backendkapacitetsplatformen.
Metadataplatformen, der er placeret i din lejers hjemmeområde, gemmer din lejers metadata, f.eks. arbejdsområder og adgangskontrolelementer. Denne platform sikrer, at brugeren er autoriseret til at få adgang til de relevante arbejdsområder og Fabric-elementer.
Back end-kapacitetsplatformen udfører beregningshandlinger og gemmer dine data. Det er placeret i kapacitetsområdet. Når et arbejdsområde er tildelt Til Fabric-kapacitet, gemmes og behandles alle data, der er placeret i arbejdsområdet, herunder datasøen OneLake, i kapacitetsområdet.

Metadataplatformen og back end-kapacitetsplatformen kører hver især i sikre virtuelle netværk. Disse netværk fremviser en række sikre slutpunkter på internettet, så de kan modtage anmodninger fra brugere og andre tjenester. Bortset fra disse slutpunkter er tjenester beskyttet af regler for netværkssikkerhed, der blokerer adgang fra det offentlige internet.

Når brugerne logger på Fabric, kan du gennemtvinge andre beskyttelseslag. På den måde vil din lejer kun være tilgængelig for visse brugere , og når andre betingelser, f.eks. netværksplacering og enhedsoverholdelse, er opfyldt. Dette beskyttelseslag kaldes indgående beskyttelse.

I dette scenarie er du ansvarlig for følsomme patientoplysninger i Fabric. Din organisation har derfor givet tilladelse til, at alle brugere, der har adgang til Fabric, skal udføre multifaktorgodkendelse (MFA), og at de skal være på virksomhedens netværk – det er ikke nok blot at sikre brugeridentitet.

Din organisation giver også brugerne fleksibilitet ved at give dem mulighed for at arbejde overalt og bruge deres personlige enheder. Da Microsoft Intune understøtter BYOD (bring-your-own-device), tilmelder du godkendte brugerenheder i Intune.

Derudover skal du sikre dig, at disse enheder overholder organisationens politikker. Disse politikker kræver specifikt, at enheder kun kan oprette forbindelse, når de har det nyeste operativsystem installeret, og de nyeste sikkerhedsrettelser. Du konfigurerer disse sikkerhedskrav ved hjælp af Betinget adgang til Microsoft Entra.

Betinget adgang giver dig flere måder at sikre din lejer på. Du kan:

Hvis du har brug for at låse hele din Fabric-lejer, kan du bruge et virtuelt netværk og blokere offentlig internetadgang. Adgang til Fabric er derefter kun tilladt inde fra det sikre virtuelle netværk. Dette krav konfigureres ved at aktivere private links på lejerniveau for Fabric. Det sikrer, at alle Fabric-slutpunkter omsættes til en privat IP-adresse i dit virtuelle netværk, herunder adgang til alle dine Power BI-rapporter. Aktivering af private slutpunkter påvirker mange Fabric-elementer, så du bør læse denne artikel grundigt, før du aktiverer dem.

Sikker adgang til data uden for Fabric (udgående beskyttelse)

Derefter skal du konfigurere udgående beskyttelse, som handler om sikker adgang til data bag firewalls eller private slutpunkter.

Din organisation har nogle datakilder, der er placeret på dit lokale netværk. Da disse datakilder ligger bag firewalls, kræver Fabric sikker adgang. Hvis du vil gøre det muligt for Fabric at oprette sikker forbindelse til din datakilde i det lokale miljø, skal du installere en datagateway i det lokale miljø.

Gatewayen kan bruges af Data Factory-dataflow ogdatapipelines til at indtage, forberede og transformere dataene i det lokale miljø og derefter indlæse dem i OneLake med en kopiaktivitet. Data Factory understøtter et omfattende sæt connectors , der giver dig mulighed for at oprette forbindelse til mere end 100 forskellige datalagre.

Derefter opretter du dataflow med Power Query, hvilket giver en intuitiv oplevelse med en grænseflade med lav kode. Du kan bruge den til at indtage data fra dine datakilder og transformere dem ved hjælp af en af de mere end 300 datatransformationer. Du opretter og organiserer derefter en kompleks etl-proces (extract, transformér og load) med datapipelines. Du ETL-processer kan opdatere dataflow og udføre mange forskellige opgaver i stor skala og behandle petabytes af data.

I dette scenarie har du allerede flere ETL-processer. Først har du nogle pipelines i Azure Data Factory (ADF). I øjeblikket henter disse pipelines dine data i det lokale miljø og indlæser dem i en data lake i Azure Storage ved hjælp af den selv hostede integrationskørsel. For det andet har du en dataindtagelsesstruktur i Azure Databricks , der er skrevet i Spark.

Nu, hvor du bruger Fabric, skal du blot omdirigere outputdestinationen for ADF-pipelinerne for at bruge lakehouse-connectoren. Og i forbindelse med indtagelsesstrukturen i Azure Databricks kan du bruge OneLake-API'erne , der understøtter ABFS-driveren (Azure Blog Filesystem), til at integrere OneLake med Azure Databricks. (Du kan også bruge den samme metode til at integrere OneLake med Azure Synapse Analytics ved hjælp af Apache Spark.)

Du har også nogle datakilder, der findes i Azure SQL Database. Du skal oprette forbindelse til disse datakilder ved hjælp af private slutpunkter. I dette tilfælde beslutter du at konfigurere en VNet-datagateway (virtuelt netværk) og bruge dataflows til sikkert at oprette forbindelse til dine Azure-data og indlæse dem i Fabric. Med VNet-datagateways behøver du ikke at klargøre og administrere infrastrukturen (som du skal gøre for datagatewayen i det lokale miljø). Det skyldes, at Fabric opretter objektbeholderne sikkert og dynamisk i dit Azure Virtual Network.

Hvis du udvikler eller migrerer din struktur for dataindtagelse i Spark, kan du oprette forbindelse til datakilder i Azure sikkert og privat fra Fabric-notesbøger og -job ved hjælp af administrerede private slutpunkter. Administrerede private slutpunkter kan oprettes i dine Fabric-arbejdsområder for at oprette forbindelse til datakilder i Azure, der har blokeret offentlig internetadgang. De understøtter private slutpunkter, f.eks. Azure SQL Database og Azure Storage. Administrerede private slutpunkter klargøres og administreres i et administreret VNet , der er dedikeret til et Fabric-arbejdsområde. I modsætning til dine typiske Azure Virtual Networks findes administrerede VNets og administrerede private slutpunkter ikke i Azure-portal. Det skyldes, at de administreres fuldt ud af Fabric, og du finder dem i indstillingerne for dit arbejdsområde.

Da du allerede har en masse data, der er gemt i ADLS-konti (Azure Data Lake Storage) Gen2 , skal du nu kun forbinde Fabric-arbejdsbelastninger, f.eks. Spark og Power BI, med dem. Takket være OneLake ADLS-genveje kan du også nemt oprette forbindelse til dine eksisterende data fra enhver Fabric-oplevelse, f.eks. dataintegrationspipelines, notesbøger til datakonstruktion og Power BI-rapporter.

Fabric-arbejdsområder, der har et arbejdsområdeidentitet , kan få sikker adgang til ADLS Gen2-lagerkonti, også selvom du har deaktiveret det offentlige netværk. Det er gjort muligt af adgang til arbejdsområder, der er tillid til. Det gør det muligt for Fabric at oprette sikker forbindelse til lagerkontiene ved hjælp af et Microsoft-backbone-netværk. Det betyder, at kommunikation ikke bruger det offentlige internet, hvilket giver dig mulighed for at deaktivere offentlig netværksadgang til lagerkontoen, men stadig tillade, at visse Fabric-arbejdsområder opretter forbindelse til dem.

Overholdelse af angivne standarder

Du vil bruge Fabric til sikkert at indtage, gemme, behandle og analysere dine data i cloudmiljøet, samtidig med at du overholder reglerne i din branche og organisationens politikker.

Fabric er en del af Microsoft Azure Core Services og er underlagt vilkårene for Microsoft Online Services og Microsoft Enterprise Privacy Statement. Selvom certificeringer typisk finder sted efter en produktlancering (generelt tilgængelig eller offentligt tilgængelig), integrerer Microsoft bedste praksis for overholdelse fra starten og i hele udviklingslivscyklussen. Denne proaktive tilgang sikrer et stærkt fundament for fremtidige certificeringer, selvom de følger etablerede revisionscyklusser. På en mere enkel måde prioriterer vi overholdelse af angivne standarder fra starten, selv når den formelle certificering kommer senere.

Fabric overholder mange branchestandarder som ISO 27001, 27017, 27018 og 27701. Fabric er også HIPAA-kompatibel , hvilket er afgørende for beskyttelse af personlige oplysninger og sikkerhed i sundhedssektoren. Du kan se Appendiks A og B i Microsoft Azure Compliance Offerings for at få en detaljeret indsigt i, hvilke cloudtjenester der er omfattet af certificeringerne. Du kan også få adgang til overvågningsdokumentationen fra STP (Service Trust Portal).

Overholdelse er et delt ansvar. Cloududbydere og deres kunder påtager sig et delt ansvar for at overholde love og bestemmelser for at sikre, at de hver især gør deres del. Når du overvejer og evaluerer offentlige cloudtjenester, er det vigtigt at forstå modellen med delt ansvar, og hvilke sikkerhedsopgaver cloududbyderen håndterer, og hvilke opgaver du håndterer.

Datahåndtering

Da du har at gøre med følsomme patientoplysninger, skal du sikre dig, at alle dine data er tilstrækkeligt beskyttet både i hvile og under overførsel.

Inaktiv kryptering giver databeskyttelse for lagrede data (inaktiv). Angreb på inaktive data omfatter forsøg på at få fysisk adgang til den hardware, som dataene er gemt på, og derefter kompromittere dataene på den pågældende hardware. Inaktiv kryptering er designet til at forhindre en hacker i at få adgang til de ukrypterede data ved at sikre, at dataene krypteres, når de er på disken. Kryptering som inaktiv er en obligatorisk foranstaltning, der kræves for at overholde nogle af branchestandarderne og -reglerne, f.eks. HIPAA (International Organization for Standardization) og Health Insurance Portability and Accountability Act (HIPAA).

Alle Fabric-datalagre krypteres inaktivt ved hjælp af Microsoft-administrerede nøgler, hvilket giver beskyttelse af kundedata samt systemdata og metadata. Data bevares aldrig til permanent lagring i ukrypteret tilstand. Med Microsoft-administrerede nøgler kan du drage fordel af krypteringen af dine inaktive data uden risiko for eller omkostninger ved en brugerdefineret løsning til administration af nøgler.

Data krypteres også under overførsel. Al indgående trafik til Fabric-slutpunkter fra klientsystemerne gennemtvinger mindst TLS (Transport Layer Security) 1.2. Den forhandler også TLS 1.3, når det er muligt. TLS giver stærk godkendelse, beskyttelse af personlige oplysninger for meddelelser og integritet (muliggør registrering af ændring af meddelelser, opfangelse og forfalskning), interoperabilitet, algoritmefleksibilitet og nem udrulning og brug.

Ud over kryptering dirigerer netværkstrafik mellem Microsoft-tjenester altid det globale Microsoft-netværk, som er et af de største backbone-netværk i verden.

Cmkryptering (Customer-Managed Key) og Microsoft Fabric

Kundeadministrerede nøgler (CMK) giver dig mulighed for at kryptere inaktive data ved hjælp af dine egne nøgler. Microsoft Fabric krypterer som standard inaktive data ved hjælp af platformadministrerede nøgler. I denne model er Microsoft ansvarlig for alle aspekter af nøgleadministration, og data-at-rest på OneLake krypteres ved hjælp af sine nøgler. Fra et overholdelsesperspektiv kan kunderne have et krav om at bruge CMK til at kryptere inaktive data. I CMK-modellen påtager kunden sig fuld kontrol over nøglen og bruger deres nøgle(er) til at kryptere inaktive data.

Diagram, der viser en repræsentation på højt niveau af brugen af CMK ved hjælp af Fabric OneLake-genveje.

Hvis du har et krav om at bruge CMK til at kryptere inaktive data, anbefaler vi, at du bruger cloudlagertjenester (ADLS Gen2, AWS S3, GCS) med CMK-kryptering aktiveret og adgang til data fra Microsoft Fabric ved hjælp af OneLake-genveje. I dette mønster forbliver dine data placeret på en cloudlagertjeneste eller en ekstern lagerløsning, hvor kryptering af inaktive data ved hjælp af CMK er aktiveret, og du kan udføre lokale læsehandlinger fra Fabric, mens du forbliver kompatibel. Når der er oprettet en genvej i Fabric, kan andre Fabric-oplevelser få adgang til dataene.

Der er nogle overvejelser i forbindelse med brugen af dette mønster:

  • Brug det mønster, der er beskrevet her, til data, der har krav om kryptering ved hjælp af CMK. Data, der ikke har dette krav, kan krypteres inaktivt ved hjælp af platformadministrerede nøgler, og disse data kan gemmes lokalt på Microsoft Fabric OneLake.
  • Fabric Lakehouse - og KQL-databasen er de to arbejdsbelastninger i Microsoft Fabric, som understøtter oprettelse af genveje. I dette mønster, hvor data fortsat er placeret på en ekstern lagertjeneste, hvor CMK er aktiveret, kan du bruge genveje i Lakehouses- og KQL-databaser til at hente dine data ind i Microsoft Fabric til analyse, men data gemmes fysisk uden for OneLake, hvor CMK-kryptering er aktiveret.
  • ADLS Gen2-genvej understøtter skrivning og brug af denne genvejstype, du kan også skrive data tilbage til lagertjenesten, og den krypteres inaktivt ved hjælp af CMK. Når du bruger CMK med ADLS Gen2, gælder følgende overvejelser for Azure Key Vault (AKV) og Azure Storage .
  • Hvis du bruger en tredjepartslagerløsning, som er AWS S3-kompatibel (Cloudflare, Qumolo Core med offentligt slutpunkt, Offentlig MinIO og Dell ECS med offentligt slutpunkt), og den har CMK aktiveret, kan det mønster, der beskrives her i dette dokument, udvides til at omfatte disse tredjepartslagerløsninger. Ved hjælp af amazon S3-kompatibel genvej kan du hente data ind i Fabric ved hjælp af en genvej fra disse løsninger. Som med cloudbaserede lagertjenester kan du gemme dataene på eksternt lager med CMK-kryptering og udføre læsehandlinger på stedet.
  • AWS S3 understøtter inaktiv kryptering ved hjælp af kundeadministrerede nøgler. Fabric kan udføre læsninger på stedet på S3-buckets ved hjælp af S3-genvej, men skrivehandlinger, der bruger en genvej til AWS S3, understøttes ikke.
  • Google Cloud Storage understøtter datakryptering ved hjælp af kundeadministrerede nøgler. Fabric kan udføre læsninger på stedet på GCS; Skrivehandlinger, der bruger en genvej til GCS, understøttes dog ikke.
  • Aktivér overvågning for Microsoft Fabric for at holde styr på aktiviteter.
  • I Microsoft Fabric understøtter Power BI kundeadministrerede nøgler med Medbring dine egne krypteringsnøgler til Power BI.
  • Deaktiver funktionen til cachelagring af genveje for S3-, GCS- og S3-kompatible genveje. da de cachelagrede data bevares på OneLake.

Dataopbevaring

Når du arbejder med patientdata, har din organisation af hensyn til overholdelse af angivne standarder givet mandat til, at dataene aldrig må forlade den USA geografiske grænse. Din organisations primære aktiviteter finder sted i New York og dit hovedkontor i Seattle. Mens du konfigurerer Power BI, har din organisation valgt området Det østlige USA som lejerens hjemmeområde. Til dine handlinger har du oprettet en Fabric-kapacitet i området Det vestlige USA, som er tættere på dine datakilder. Da OneLake er tilgængelig over hele verden, er du bekymret for, om du kan opfylde din organisations politikker for dataopbevaring, mens du bruger Fabric.

I Fabric lærer du, at du kan oprette Multi-Geo-kapaciteter, som er kapaciteter, der er placeret i andre geografiske områder (geos) end din lejers lokale område. Du tildeler dine Fabric-arbejdsområder til disse kapaciteter. I dette tilfælde er beregning og lager (herunder OneLake og erfaringsspecifikt lager) for alle elementer i arbejdsområdet placeret i det multi-geo-område, mens dine lejermetadata forbliver i hjemmeområdet. Dine data gemmes og behandles kun i disse to geografiske områder, hvilket sikrer, at din organisations krav til dataopbevaring er opfyldt.

Adgangskontrol

Du skal sikre, at det kun er dig og dine meddatateknikere, der har fuld adgang til dataene i lakehouseets bronze- og sølvlag. Disse lag giver dig mulighed for at udføre datarensning, validering, transformation og berigelse. Du skal begrænse adgangen til dataene i guldlaget til kun godkendte brugere, f.eks. dataanalytikere og virksomhedsbrugere, som kan bruge dataene til forskellige analyseformål, f.eks. rapportering og analyse.

Fabric indeholder en fleksibel tilladelsesmodel , der giver dig mulighed for at styre adgangen til elementer og data i dine arbejdsområder. Et arbejdsområde er et logiske objekt, der kan sikres, til gruppering af elementer i Fabric. Du kan bruge arbejdsområderoller til at styre adgangen til elementer i arbejdsområderne. De fire grundlæggende roller i et arbejdsområde er:

  • Administrator: Kan få vist, redigere, dele og administrere alt indhold i arbejdsområdet, herunder administrere tilladelser.
  • Medlem: Kan få vist, redigere og dele alt indhold i arbejdsområdet.
  • Bidragyder: Kan få vist og redigere alt indhold i arbejdsområdet.
  • Fremviser: Kan få vist alt indhold i arbejdsområdet, men kan ikke ændre det.

I dette scenarie opretter du tre arbejdsområder, ét for hvert medaljonslag (bronze, sølv og guld). Da du har oprettet arbejdsområdet, tildeles du automatisk rollen Administrator .

Du føjer derefter en sikkerhedsgruppe til rollen Bidragyder for disse tre arbejdsområder. Da sikkerhedsgruppen omfatter dine kollegers teknikere som medlemmer, kan de oprette og redigere Fabric-elementer i disse arbejdsområder – men de kan ikke dele nogen elementer med andre. De kan heller ikke give andre brugere adgang.

I arbejdsområderne med bronze og sølv opretter du og dine kolleger Fabric-elementer til at indtage data, gemme dataene og behandle dataene. Stofelementer består af et lakehouse, pipelines og notesbøger. I guldarbejdsområdet opretter du to lakehouses, flere pipelines og notesbøger og en Semantisk Direct Lake-model, som leverer hurtig ydeevne for forespørgsler for data, der er gemt i et af lakehouses.

Du skal derefter overveje, hvordan dataanalytikere og virksomhedsbrugere kan få adgang til de data, de har adgang til. De kan især kun få adgang til data, der er relevante for deres rolle og afdeling.

Det første lakehouse indeholder de faktiske data og gennemtvinger ikke datatilladelser i sql-analyseslutpunktet. Det andet lakehouse indeholder genveje til det første lakehouse, og det gennemtvinger detaljerede datatilladelser i sql analytics-slutpunktet. Den semantiske model opretter forbindelse til det første lakehouse. Hvis du vil gennemtvinge relevante datatilladelser for brugerne (så de kun kan få adgang til data, der er relevante for deres rolle og afdeling), deler du ikke det første lakehouse med brugerne. I stedet deler du kun den semantiske Direct Lake-model og det andet lakehouse, der gennemtvinger datatilladelser i sql-analyseslutpunktet.

Du konfigurerer den semantiske model til at bruge en fast identitet og implementerer derefter sikkerhed på rækkeniveau (RLS) i den semantiske model for at gennemtvinge modelregler for at styre, hvilke data brugerne kan få adgang til. Du deler derefter kun den semantiske model med dataanalytikere og virksomhedsbrugere, fordi de ikke skal have adgang til de andre elementer i arbejdsområdet, f.eks. pipelines og notesbøger. Endelig giver du tilladelsen Opret for den semantiske model, så brugerne kan oprette Power BI-rapporter. På den måde bliver den semantiske model en delt semantisk model og en kilde til deres Power BI-rapporter.

Dine dataanalytikere skal have adgang til det andet lakehouse i guldarbejdsområdet. De opretter forbindelse til SQL Analytics-slutpunktet for det pågældende lakehouse for at skrive SQL-forespørgsler og udføre analyser. Så du deler dette lakehouse med dem og giver kun adgang til objekter, de har brug for (f.eks. tabeller, rækker og kolonner med maskeringsregler) i lakehouse SQL Analytics-slutpunktet ved hjælp af SQL-sikkerhedsmodellen. Dataanalytikere kan nu kun få adgang til data, der er relevante for deres rolle og afdeling, og de kan ikke få adgang til de andre elementer i arbejdsområdet, f.eks. pipelines og notesbøger.

Almindelige sikkerhedsscenarier

I følgende tabel vises almindelige sikkerhedsscenarier og de værktøjer, du kan bruge til at udføre dem.

Scenarie Funktioner Retning
Jeg er ETL-udvikler , og jeg vil indlæse store mængder data til Fabric i stor skala fra flere kildesystemer og tabeller. Kildedataene er i det lokale miljø (eller et andet cloudmiljø) og ligger bag firewalls og/eller Azure-datakilder med private slutpunkter. Brug datagateway i det lokale miljø med datapipelines (kopiaktivitet). Udgående
Jeg er superbruger, og jeg vil indlæse data til Fabric fra kildesystemer, som jeg har adgang til. Da jeg ikke er udvikler, skal jeg transformere dataene ved hjælp af en grænseflade med lav kode. Kildedataene er i det lokale miljø (eller et andet cloudmiljø) og ligger bag firewalls. Brug datagateway i det lokale miljø med Dataflow Gen 2. Udgående
Jeg er superbruger , og jeg vil indlæse data i Fabric fra kildesystemer, som jeg har adgang til. Kildedataene ligger i Azure bag private slutpunkter, og jeg vil ikke installere og vedligeholde infrastrukturen for datagatewayen i det lokale miljø. Brug en VNet-datagateway med Dataflow Gen 2. Udgående
Jeg er udvikler og kan skrive dataindtagelseskode ved hjælp af Spark-notesbøger. Jeg vil indlæse data i Fabric fra kildesystemer, som jeg har adgang til. Kildedataene ligger i Azure bag private slutpunkter, og jeg vil ikke installere og vedligeholde infrastrukturen for datagatewayen i det lokale miljø. Brug Fabric-notesbøger med private Azure-slutpunkter. Udgående
Jeg har mange eksisterende pipelines i Azure Data Factory- (ADF) og Synapse-pipelines, der opretter forbindelse til mine datakilder og indlæser data i Azure. Jeg vil nu ændre disse pipelines for at indlæse data i Fabric. Brug Lakehouse-connectoren i eksisterende pipelines. Udgående
Jeg har udviklet en dataindtagelsesramme i Spark, der opretter sikker forbindelse til mine datakilder og indlæser dem i Azure. Jeg kører den på Azure Databricks og/eller Synapse Spark. Jeg vil fortsætte med at bruge Azure Databricks og/eller Synapse Spark til at indlæse data i Fabric. Brug OneLake og ADLS Gen2 API (Azure Blob Filesystem-driveren) Udgående
Jeg vil sikre mig, at mine Fabric-slutpunkter er beskyttet mod det offentlige internet. Som SaaS-tjeneste er Fabric-backend allerede beskyttet mod det offentlige internet. Hvis du vil have mere beskyttelse, skal du bruge Microsoft Entra-politikker for betinget adgang for Fabric og/eller aktivere private links på lejerniveau for Fabric og blokere offentlig internetadgang. Indgående
Jeg vil gerne sikre, at Fabric kun kan tilgås fra mit firmanetværk og/eller fra enheder, der overholder angivne standarder. Brug microsoft Entra-politikker for betinget adgang til Fabric. Indgående
Jeg vil sikre, at alle, der tilgår Fabric, skal udføre multifaktorgodkendelse. Brug microsoft Entra-politikker for betinget adgang til Fabric. Indgående
Jeg ønsker at låse hele min Fabric lejer fra det offentlige internet og tillade adgang kun fra mit virtuelle netværk. Aktivér private links på lejerniveau for Fabric, og bloker offentlig internetadgang. Indgående

Relateret indhold

Du kan få flere oplysninger om Fabric security i følgende ressourcer.