Ez a kérdés rámutat, hogy a “Szerverállapot megtekintése” engedély szükséges a különböző DMV-khez (dinamikus felügyeleti nézetek), de nem találok semmit arról, hogy ki és nem akarja megadni az engedélyt.
Most már természetesen megértem a “legkevesebb engedélyt”, és miért nem akarod senkinek megadni, de nem találok útmutatást arra vonatkozóan, hogy miként kell értékelni, hogy KELL-e megadni vagy sem. .
Tehát, a kérdésem: Milyen biztonsági és teljesítményi következményekkel jár a felhasználó „View Server State” engedély megadása. Mit tehetnek, amit talán nem szabad megengedni nekik …
Frissítés : az egyik következmény az, hogy a felhasználó a DMV-ket használhatja a lekérdezések megtekintésére. Ha a lekérdezések vagy a lekérdezési paraméterek tartalmazhatnak olyan bizalmas információkat, amelyeket a felhasználó egyébként nem láthatna, akkor a VIEW SERVER STATE engedélyezése lehetővé tenné számukra (azaz dob = vagy ssn =).
Válasz
Nincsenek olyan jelentős teljesítményproblémák, amelyekre gondolni tudnék az engedély megadásakor. Biztonsági szempontból fennáll annak a kockázata, hogy a felhasználó láthatja, mit a legtöbb részlet a gyenge pontjairól, így például egy rosszindulatú felhasználó megtekintheti a leggyakoribb várakozási statisztikákat, amelyek segíthetnek a szerver elleni DoS-támadás célzásában.
Ez lehetséges? Határozottan. valószínűleg? Kénytelen vagyok nemet mondani, de ne feledje, hogy becslések szerint a vállalatok elleni támadások 90 százaléka belső támadóktól származik.
Válasz
Rendszergazdaként úgy tekintené ezeket az információkat, mint amelyek a tartományában vannak (teljesítmény / indexhasználat / stb.), de vannak kényszerítő okok, amelyek Az operációs szervezet ezt az információt egy nagy örökölt rendszerhez szeretné, amelyet támogatnak – azonosítva azokat a zombi táblákat, amelyekhez például csak a karbantartási folyamatok vonatkoznak.
Végül mindig a “szerencse és a nagylelkűség” kérdése. mivel az a felkérés, hogy egy adott kérés indokolt-e, végeredményben nem megfelelő választás, nem pedig éles képlet. A bevált gyakorlati minták használata a kontextus vizsgálata nélkül is elég csúnya antiminta, a valóság pedig az, hogy sokan úgy közelítik meg álláspontjukat, hogy kiindulópontként “kézhez beszélnek”.
Válasz
A teljesítményre vonatkozó következményekkel kapcsolatban nincs tudomásom erről vagy más engedélyekről.
Ami:
Mit tehetnek, amit talán nem szabad megengedniük
Egyszerűen fogalmazva, látnak dolgokat hogy talán nem kellene látniuk. És ezt ne csak az SQL Server-re gondoljuk. Ez a külön engedély olyan DMV-kre is vonatkozik, mint például sys.dm_os_sys_info és jó néhány más, amely betekintést nyújt a a gazdagép (hardver, szolgáltatások stb.). Nem mindig tudja, milyen információk használhatók fel ön ellen. És még ha jól is érzed magad valakivel, aki mindent lát, amit ez az engedély megenged, néha DMV-k kerülnek a szervizcsomagokba / kumulatív frissítésekbe, és így talán egy új információ kerül nyilvánosságra, amiről nincs tudomásod.
Nem találok útmutatást arra vonatkozóan, hogy miként értékelhető, hogy KELL-e megadni vagy sem.
Mivel már említetted az emberek számára a szükséges minimális engedélyek megadását, ez valójában az következik: kell-e valakire ez az engedély eseti használathoz? Jelentése: Szüksége van valakinek arra a rugalmasságra, hogy saját kérdéseivel előálljon? Működne egy vagy több tárolt eljárás és / vagy több állítással rendelkező TVF létrehozása? Ha igen, akkor nem kell engedélyeket megadnia egyetlen felhasználónak (akinek ezután szabad minden, amit az engedély megenged), ehelyett a kód hoz kell engedélyt adnia. (amely csak azt csinálja, amire van kódolva). Ezt a modul aláírás segítségével valósíthatja meg. Az általános koncepció:
- A kívánt művelet (ek) végrehajtásához hozza létre a tárolt eljárás (oka) t és / vagy több állítást tartalmazó TVF-eket.
- Adja meg
EXECUTEezeket a modulokat bármilyen felhasználónak és / vagy szerepkörnek meg kell adnia ezeket a műveleteket - Tanúsítvány létrehozása
- Az adott tanúsítvány használatával írja alá a modul (oka) t (
ADD SIGNATURE) - Másolja a tanúsítványt a
[master]adatbázisba (azaz hozzon létre egy tanúsítványt a[master]fájlban a nyilvános kulcs használatával a modul (ok) aláírásához használt tanúsítványból. - Hozzon létre bejelentkezést a
[master] - másolt tanúsítványból. szintű permissio n szükségesek ahhoz a tanúsítvány alapú bejelentkezéshez (amely magában foglalhatja a példány szintű szerepkörökhöz való hozzáadást is).
Néhány példa:
Válasz
Ez biztonsági probléma. Soha nem hibázhat, ha követed a legkevésbé kiváltságos alapelvet . Más szavakkal, ha egy hitelesítő megbízónak “nincs szüksége külön engedélyre, akkor ne” Nem adsz nekik információt arról, hogy milyen típusú zárak vannak az ajtódon másoknak, akiknek ezt nem kell tudniuk a házadról? Remélem, hogy nem. Valószínűleg nem csinálnának semmit, de ez még mindig nem körültekintő.
Ha az adatok alapelveit a szerencse és a nagylelkűség alapján vesszük alapul, akkor sokkal nagyobb bajban lennénk. A biztonság olyan szempont, ahol csak akkor szabad megadnia, ha megvédheti, miért adta meg. Egyszerűen több információt ad valakinek, mint amennyit tudnia kell . Ne csináld. A szerver állapota továbbra is érzékeny.
Megjegyzések
t, de szeretném.
sys.dm_db_missing_index_detailst), és tudni akarja, hogy pontosan mi a kockázata ennek.