Käytä Microsoft SQL Server -palvelinta turvallisesti Power Appsin avulla
On olemassa eri tapoja muodostaa yhteyden ja todentaa SQL Serveriin Power Appsin avulla. Tässä artikkelissa kerrotaan käsitteistä, jotka auttavat valitsemaan SQL Server -palvelimen yhteystavan sovelluksen vaatimuksia vastaavan suojausnäkökulman avulla.
Tärkeä
Suojatut implisiittiset yhteydet -toiminto julkaistiin tammikuussa 2024. Microsoft kannustaa kaikkia sovelluksia, jotka käyttävät tällä hetkellä implisiittistä yhteyttä, turvaamaan implisiittiset yhteydet ja kumoamaan yhteydet, jotka on jaettu loppukäyttäjien kanssa.
Eksplisiittisten, implisiittisten ja suojattujen implisiittisten yhteyksien välinen ero
Yhteys SQL Serveriin luodaan aina, kun luot sovelluksen käyttäen Power Appsia, joka muodostaa yhteyden SQL Serveriin. Kun tällaiset sovellukset julkaistaan ja jaetaan muiden kanssa, sekä sovellus että yhteys otetaan käyttöön kyseisille käyttäjille. Toisin sanoen sekä sovellus että yhteys—molemmat näkyvät käyttäjille, joiden kanssa sovellukset on jaettu.
Näissä yhteyksissä käytettävä todennustapa voi olla eksplisiittinen tai implisiittinen. Voimme myös sanoa, että tällainen yhteys on jaettu eksplisiittisesti tai implisiittisesti.
- Eksplisiittisesti jaettu yhteys tarkoittaa, että sovelluksen loppukäyttäjän on todennettava SQL Serveriin omilla eksplisiittisillä tunnistetiedoillaan. Yleensä tämä todentaminen tapahtuu taustalla osana Microsoft Entra- tai Windows-todentamista. Käyttäjä ei edes huomaa, milloin todennus tapahtuu.
- Implisiittisesti jaettu yhteys tarkoittaa sitä, että käyttäjä käyttää implisiittisesti sen tilin tunnistetietoja, jolla sovelluksen valmistaja on yhdistänyt ja todentanut tietolähteen kohteeseen sovelluksen luonnin aikana. Käyttäjän tunnistetietoja ei käytetä todentamiseen. Aina kun loppukäyttäjä suorittaa sovelluksen, hän käyttää tunnistetietoja, joilla tekijä loi sovelluksen.
- Suojattu implisiittisesti jaettu yhteys viittaa skenarioon, jossa sovelluksen käyttäjä käyttää implisiittisesti sen tilin tunnistetietoja, jolla sovelluksen valmistaja on yhdistänyt ja todentanut tietolähteen kohteeseen sovelluksen luonnin aikana. Tämä tarkoittaa sitä, että loppukäyttäjän omia tunnistetietoja ei käytetä todentamisen yhteydessä. Sen sijaan, kun loppukäyttäjä suorittaa sovelluksen, hän käyttää tunnistetietoja, joilla tekijä loi sovelluksen. On tärkeää huomata, että loppukäyttäjällä ei ole suoraa yhteyttä, ja sovellus sallii vain rajoitettujen toimintojen ja taulukoiden käytön.
Seuraavia neljää yhteystodennustyyppiä voidaan käyttää SQL Server for Power Appsissa:
| Todennustyyppi | Power Apps -yhteystapa |
|---|---|
| Microsoft Entra Integrated | Eksplisiittinen |
| SQL Server -todentaminen | Implisiittinen/ suojattu implisiittinen |
| Windows-todentaminen | Implisiittinen/ suojattu implisiittinen |
| Windows-todentaminen (ei jaettu) | Eksplisiittinen |
Implisiittisen yhteyden jakamisen riskit
Kaikki uudet sovellukset käyttävät automaattisesti uusia suojattuja implisiittisiä yhteyksiä. Koska kuitenkin vanhempia implisiittisiä yhteyksiä käyttävissä sovelluksissa sekä sovellus että sen yhteydet on otettu käyttöön loppukäyttäjille, loppukäyttäjät voivat siis luoda uusia sovelluksia yhteyksien perusteella.
Kun tekijä käyttää suojattuja implisiittisiä yhteyksiä, yhteys ei ole jaettu eikä kukaan loppukäyttäjä saa yhteysobjektia. Näin loppukäyttäjän tekijä ei voi käyttää yhteyttä uudelleen uuden sovelluksen luomiseen. Sovellus toimii sen sijaan välityspalvelimen yhteydessä, joka on tietoinen sovelluksesta ja on yhteydessä vain tiettyyn sovellukseen. Välityspalvelimen yhteys sallii rajoitetut toiminnot (luoda, lukea, päivittää, poistaa) ja käyttää sovelluksen julkaisun yhteydessä määritettyjä tiettyjä taulukoita. Tämän vuoksi käyttäjälle myönnetään vain valtuutetut toiminnot ja käyttöoikeudet.
Vanhan tyylin yksinkertainen implisiittinen yhteys jakaa yhteysobjektin käyttäjälle. Oletetaan esimerkiksi, että loit sovelluksen, joka suodattaa pois tiedot, joita et halua käyttäjien näkevän. Suodatetut tiedot ovat kuitenkin tietokannassa. Olet kuitenkin riippuvainen määritetystä suodattimesta, jotta käyttäjät eivät näe tiettyjä tietoja.
Jälleen, vanhan tyylisillä yksinkertaisilla implisiittisillä yhteyksillä, kun olet ottanut ovelluksen käyttöön, käyttäjät voivat käyttää sovelluksesi kanssa käyttöön otettua yhteyttä luoduissa uusissa sovelluksissa. Uudet sovellukset näkevät sovelluksessa suodatetut tiedot. Uusien suojattujen implisiittisten yhteyksien käyttö on tärkeää.
Tärkeä
Kun vanhempi implisiittisesti jaettu yhteys on otettu käyttöön loppukäyttäjille, jakamasi sovelluksen (kuten suodattimien tai vain luku -käytön) rajoitukset eivät enää kelpaa uusille sovellusten käyttäjille. Käyttäjät saavat kaikki todentamisen sallimat oikeudet osana implisiittisesti jaettua yhteyttä. Kun siis muunnat sovelluksen käyttämään suojattuja implisiittistä yhteyttä, sinun on myös kumottava sovelluksesi kanssa jakamasi yhteydet. Järjestelmänvalvojat voivat saada raportin sovelluksista, joissa on implisiittisesti jaettuja yhteyksiä COE-työkaluilla.
Asiakas- ja palvelinsuojaus
Tietojen suojaukseen suodattamalla tai suojaamalla muita asiakaspuolen toimintoja ei voi luottaa. Sovellusten, jotka edellyttävät tietojen suojattua suodatusta, on varmistettava, että sekä käyttäjän tunniste että suodatus tapahtuu palvelimessa.
Käytä palveluita, esimerkiksi Microsoft Entra ID:tä sen sijaan, että luotat sovellusten sisällä suodattimiin, kun kyseessä on käyttäjän identiteetti ja turvallisuus. Tämä määritys varmistaa, että palvelinpuolen suodattimet toimivat odotetusti.
Seuraavissa kuvissa kerrotaan, miten sovellusten suojausmallit eroavat asiakaspuolen ja palvelinpuolen suojausmalleista.
Asiakasohjelman suojaussovelluksen mallissa [1] käyttäjä todentaa vain sovelluksen asiakaspuolella. Tämän jälkeen [2] sovellus pyytää tietoja palvelusta, ja [3] palvelu palauttaa tiedot yksinomaan tietopyynnön perusteella.
Palvelinpuolen suojausmallissa [1] käyttäjä todentaa palvelun ensimmäisen kerran niin, että käyttäjä on palvelun tiedossa. Kun [2] sitten sovelluksesta soitetaan, palvelu [3] suodattaa tiedot tarkoituksenmukaisesti nykyisen käyttäjän tunnetun tunnistetietojen perusteella ja [4] palauttaa tiedot.
Yllä kuvatut osaston implisiittiset jakamisskenaariot yhdistettynä näihin kahteen kaavaan. Käyttäjän täytyy kirjautua Power Apps -palveluun Microsoft Entra -tunnistetiedoilla. Tämä toimintatapa on palvelimen suojaussovelluksen malli. Käyttäjä on tunnettu palvelussa Microsoft Entra -tunnistetietojen käyttämisestä. Niinpä sovellus on rajoitettu käyttäjiin, joille Power Apps on muodollisesti jakanut sovelluksen.
Implisiittinen jaettu yhteys SQL Serveriin on kuitenkin asiakkaan suojaussovellusmalli. SQL Server tietää vain, että käytössä on tietty käyttäjänimi ja salasana. Mikä tahansa asiakaspuolen suodatus voidaan ohittaa uudella sovelluksella käyttämällä samaa käyttäjänimeä ja salasanaa.
Jos haluat suodattaa tietoja turvallisesti palvelinpuolella, käytä SQL Serverin sisäisiä suojausominaisuuksia, kuten rivitason suojausta riveille, ja estä tiettyjen objektien (kuten sarakkeiden) käyttöoikeudet tietyille käyttäjille. Tämä lähestymistapa käyttää Microsoft Entra -käyttäjätunnusta palvelimen tietojen suodattamiseen.
Jotkin aiemmin luoduista yrityspalveluista ovat käyttäneet tapaa, jossa käyttäjätiedot tallennetaan liiketoimintatietojen kerrokseen samalla tavalla kuin Microsoft Dataverse. Tässä tapauksessa liiketoimintataso saattaa käyttää SQL Serverin rivitason suojausta ja estää toimintoja suoraan. Jos näin ei ole, suojaus on usein otettu käyttöön tallennettujen toimintosyistä tai näkymien avulla.
Liiketoimintataso (palvelinpuolella) käyttää tunnettua Microsoft Entra -käyttäjäidentiteettiä käynnistääkseen tallennetun toimintosarjan SQL Server -pääsarjana ja suodattaa tiedot. Power Apps ei kuitenkaan muodosta tällä hetkellä yhteyttä tallennettuihin toimintoihin. Liiketoimintataso voi myös käynnistää näkymän, joka käyttää Microsoft Entra -tunnistetietoja SQL Server -päätasona. Muodosta tällöin yhteys Power Appsilla näkymiin niin, että tiedot suodatetaan palvelinpuolella. Vain näkymien altistaminen käyttäjille saattaa vaatia Power Automate -työnkulkuja päivityksiä varten.