Tämä kysymys huomauttaa, että ”Näytä palvelimen tila” -oikeus vaaditaan useille DMV: lle (dynaamiset hallintanäkymät), mutta en löydä mitään sinusta tehdä eikä halua myöntää lupaa.

Nyt ymmärrän tietysti ”vähiten käyttöoikeuksia” ja miksi et halua myöntää sitä kenellekään, mutta en löydä ohjeita siitä, kuinka arvioida, PITÄISikö sen myöntää vai ei. .

Joten, kysymykseni: Mitkä ovat käyttäjän ”View Server State” -käyttöluvan myöntämisen turvallisuus- ja suorituskykyvaikutukset. Mitä he voivat tehdä, että heidän ei pitäisi sallia tehdä …

Päivitä : yksi merkitys on, että käyttäjä voi käyttää DMV: itä kyselyjen tarkasteluun. Jos kyselyt tai kyselyparametrit voivat sisältää luottamuksellisia tietoja, joita käyttäjä ei muuten pystyisi näkemään, VIEW SERVER STATE -asetuksen antaminen antaisi heille mahdollisuuden tehdä niin (eli dob = tai ssn =).

Vastaa

Ei ole mitään merkittäviä suorituskykyongelmia, joita voin ajatella myöntääni tämän luvan. Turvallisuuden näkökulmasta sinulla on riski antaa käyttäjän nähdä, mitä sinä useimmat tiedot heikoista paikoistasi, joten esimerkiksi pahantahtoinen käyttäjä voi tarkastella yleisimpiä odotustilastojasi, mikä voi auttaa heitä kohdentamaan palvelimesi vastaisen DoS-hyökkäyksen.

Onko tämä mahdollista? Ehdottomasti. Onko tämä todennäköisesti? Minun on pakko sanoa Ei, mutta muista, että arvioidaan, että 90 prosenttia yrityksiin kohdistuvista hyökkäyksistä tapahtuu sisäisiltä hyökkääjiltä.

Vastaa

Järjestelmänvalvojana katsot näiden tietojen olevan verkkotunnuksessasi (suorituskyky / hakemistokäyttö / jne.), mutta kehitykseen voi olla pakottavia syitä organisaatio haluaa nämä tiedot suurelle vanhalle järjestelmälle, jota he tukevat – tunnistamalla zombi-taulukot, joita esimerkiksi vain ylläpitoprosessit koskettavat.

Loppujen lopuksi kysymys on aina ”onnesta ja anteliaisuudesta”. koska pyyntö siitä, onko jokin tietty pyyntö perusteltu, on loppujen lopuksi pehmeä valinta eikä terävä kaava. Parhaiden käytäntöjen käyttäminen kontekstia tarkastelematta on sinänsä melko ikävää anti-mallia ja todellisuus on, että monet lähestyvät kantaansa lähtökohtana ”puhu kädelle”.

Vastaus

Suorituskykyyn liittyvistä seikoista en ole tietoinen mistään tälle tai muulle luvalle.

Mitä tulee:

Mitä he voivat tehdä, mitä heidän ei ehkä pitäisi sallia tehdä

Yksinkertaisesti sanottuna he näkevät asioita että ehkä heidän ei pitäisi nähdä. Ja älä ajattele tätä vain SQL Serverin kanssa. Tämä erityinen käyttöoikeus koskee myös DMV: itä, kuten sys.dm_os_sys_info ja muutamia muita, jotka antavat käsityksen. isäntäkone (laitteisto, palvelut jne.). Et aina tiedä, mitä tietoja voidaan käyttää sinua vastaan. Ja vaikka olisitkin kunnossa sen kanssa, että joku näkee kaiken tämän luvan salliman, joskus DMV: t lisätään Service Packs / kumulatiivisiin päivityksiin, joten ehkä uusi tieto paljastuu, josta et ole tietoinen.

En löydä ohjeita siitä, kuinka arvioida, pitäisikö sen myöntää vai ei.

Koska mainitsit jo ihmisille tarvittavien vähimmäisoikeuksien antamisen, tämä oikeasti on: tarvitseeko joku tätä lupaa ad hoc -käyttöön? Tarkoitus, tarvitseeko joku joustavuutta keksimään omia kyselyjään? Toimiiko yhden tai useamman tallennetun menettelyn ja / tai monilausekeisen TVF: n luominen? Jos näin on, sinun ei tarvitse myöntää käyttöoikeuksia kenellekään käyttäjälle (joka on sitten vapaa kaikelle, mitä tämän lupa sallii), ja annat sen sijaan käyttöoikeudet koodille (joka tekee vain sen, mitä se on koodattu). Moduulin allekirjoittaminen on tämä, jolla saavutat tämän. Yleinen käsite on:

  1. Suorita halutut toiminnot luomalla tallennetut menettelyt ja / tai monilausekeiset TVF: t.
  2. Myönnä näille moduuleille EXECUTE kenelle tahansa käyttäjälle ja / tai rooleille, jotka näiden toimintojen on suoritettava
  3. Luo varmenne
  4. Allekirjoita moduulit kyseisellä varmenteella (käyttämällä ADD SIGNATURE)
  5. Kopioi varmenne [master] -tietokantaan (ts. luo varmenne [master] käyttämällä julkista avainta moduulien allekirjoittamiseen käytetyn varmenteen.
  6. Luo sisäänkirjautuminen varmenteesta, joka on kopioitu osoitteeseen [master]
  7. Myönnä mikä tahansa ilmentymä- tason permissio ns ovat välttämättömiä kyseiselle varmenteeseen perustuvalle kirjautumiselle (joka voi sisältää sen lisäämisen ilmentymän tason rooleihin).

Joitakin esimerkkejä:

Vastaa

Se on turvallisuusongelma. Et voi koskaan mennä pieleen, jos noudatat vähiten etuoikeutettua periaatetta . Toisin sanoen, jos todentava päämies ei tarvitse ”erityistä lupaa , niin älä” Älä anna sitä heille. Annatko tietoa ovesi lukkojen tyypistä muille ihmisille, joiden ei tarvitse tietää sitä talostasi? Toivon, ettei. He eivät luultavasti tekisi mitään, mutta se ei silti ole varovainen.

Jos perustamme dataperiaatteet onneen ja anteliaisuuteen, olisimme suuremmissa vaikeuksissa melko usein. Suojaus on näkökohta, johon sinun pitäisi myöntää vain, kun voit puolustaa syitä, joiden takia annoit. Annat vain jollekin enemmän tietoa kuin heidän tarvitsee tietää . Älä tee sitä. Palvelimen tila on edelleen herkkä.

Kommentit

  • Kuka sanoo antavansa sen tarpeettomasti? OP voi joutua myöntämään joku voi tutkia tiettyä ongelmaa (esim. tarkastella sys.dm_db_missing_index_details) ja he haluavat tietää, mitä riskejä siihen liittyy.
  • Luulen ' m puuttuu merkki tästä kysymyksestä, en näe ' kysymyksessä mitään, mikä viittaa luvan välttämättömyyteen.
  • @ThomasStringer: kysymys ei ole ' t tarpeesta , se ' s noin riski . Rahamääräisesti sanottuna saatat tietää, mihin lisäriskeihin tämä altistaisi palvelimesi, ja pystyt siis sanomaan ei sentille ja kyllä miljoonalle dollarille. id = ”1d96fe8bcf”>

t, mutta haluan.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *