У овом ћемо чланку погледати сигурносне алате СКЛ Сервер и најбоље праксе за подешавање и осигурање ове ДБМС..
Садржај:
- Аутентификација на СКЛ Серверу
- Ауторизација у СКЛ Серверу
- Улоге у апликацијама
- Филтрирање података на СКЛ Серверу
- Шеме на СКЛ Серверу
- Шифрирање података помоћу СКЛ сервера
- Кориштење групних сервисних налога за СКЛ Сервер
- Процена рањивости СКЛ Сервер-а путем ССМС-а
- Активности ревизије у СКЛ Серверу
- Најбоље праксе опште сигурности СКЛ Сервер-а
Прво, сетимо се основних безбедносних концепата СКЛ Сервера. МССКЛ контролише приступ објектима путем аутентификација и ауторизација.
- Аутентификација - Ово је поступак пријављивања на СКЛ Сервер када корисник преда своје податке серверу. Аутентификација идентификује корисника који има аутентичност;
- Пријава - ово је поступак утврђивања којим заштићеним објектима корисник може приступити и које су операције дозвољене за те ресурсе.
Многи објекти СКЛ Сервер имају своја дозвола која се могу наслиједити од надређеног објекта. Дозволе се могу доделити поједином кориснику, групи или улози.
Аутентификација на СКЛ Серверу
СКЛ Сервер налог се може поделити на 2 дела: Име за пријаву и Корисник.
- Име за пријаву - Ово је глобална пријава за целу инстанцу СКЛ Сервера. Са њом пролазите кроз поступак аутентификације;
- Корисник - ово је члан базе података повезан са одређеним именом за пријаву.
На пример, може бити пријава вашег сервера домен \ корисничко име, а корисник у бази података која је повезана с овом пријавом може се позвати домаин_датабасеУсер. Скоро увек се име и корисник у бази података подударају у имену, али морате имати на уму да се могу разликовати и да имају различита имена.
СКЛ Сервер подржава 2 режима аутентификација:
- Провера идентитета Виндовс (Виндовс Аутхентицатион) - провера идентитета врши се коришћењем Виндовс сигурности. Корисници који су већ аутентификовани у Виндовс-у и имају права на СКЛ Сервер не морају да дају додатне акредитиве.
- Мешовита аутентификација (Мешовита провјера аутентичности) - у овом режиму је поред Виндовс аутентификације подржана и аутентификација самог СКЛ сервера путем пријаве и лозинке.
Мицрософт препоручује коришћење Виндовс провере идентитета, ако је могуће. За аутентификацију путем логин-а и лозинке, подаци (логин и лозинка) се преносе преко мреже, иако у шифрираном облику. Са Виндовс аутентификацијом, низ шифрованих порука се преноси путем мреже у коју корисничка лозинка није укључена..
Али неке апликације, посебно оне старије, не подржавају Виндовс аутентификацију, па приликом постављања начина за аутентификацију вреди размотрити које ће се апликације повезати на сервер.
СКЛ Сервер подржава три типа Име за пријаву (имена за пријаву):
- Локални налог Корисник или налог за Виндовс домен/ поуздан домен.
- Виндовс Гроуп. Омогућавање приступа локалној Виндовс групи или групи из АД домена. Омогућава вам да омогућите приступ свим корисницима који су чланови групе.
- Пријава на СКЛ Сервер (Аутентификација СКЛ Сервера). СКЛ Сервер складишти хасх корисничко име и лозинку у базу података мајсторе, користећи интерне методе провјере идентитета за провјеру пријаве.
СКЛ Сервер се аутоматски интегрише са Ацтиве Дирецтори-ом. Ако желите да дистрибуирате права на доменски налог, потребно је да користите НетБиос име домена и пријаву на налог. На пример, корисничко име у домени.лоцал ће бити „домена \ корисничко име“.
Ауторизација у СКЛ Серверу
За ауторизацију СКЛ Сервер користи заштиту засновану на улози која вам омогућава да доделите дозволе Виндовс улози или групи / домени, а не појединачним корисницима. СКЛ Сервер има уграђене улоге сервера и базе података које имају унапред дефинисани скуп дозвола.
Постоје 3 нивоа сигурности у СКЛ Серверу, они могу бити представљени као хијерархија од највишег до најнижег:
- Ниво сервера - на овом нивоу можете да дистрибуирате права на базе података, рачуне, улоге сервера и групе расположивости;
- Ниво базе података укључују шеме, кориснике база података, улоге базе података и каталоге у целом тексту;
- Ниво круга укључују објекте као што су табеле, прикази, функције и похрањене процедуре.
Уграђене улоге сервера
| Улога | Опис |
| сисадмин | Члан улоге има пуна права на све ресурсе СКЛ Сервера. |
| серверадмин | Чланови улоге могу да промене конфигурациона подешавања на нивоу сервера и искључе сервер. |
| сецуритиадмин | Учесници у улози управљају подацима и њиховим својствима. Они могу доделити ГРАНТ, ДЕНИ и РЕВОКЕ права приступа на нивоу сервера и на нивоу базе података, ако имају приступ њему. сецуритиадмин се не разликује много од улоге сисадмин-а, јер чланови ове улоге могу потенцијално добити приступ свим ресурсима СКЛ Сервер-а. |
| процессадмин | Учесници улоге могу прекинути процесе који се изводе у СКЛ Серверу. |
| сетупадмин | Чланови улоге могу додавати и уклањати повезане сервере користећи ТСКЛ. |
| булкадмин | Чланови улоге могу покренути БУЛК ИНСЕРТ операције. |
| дискадмин | Чланови улоге могу да управљају резервним уређајима. У пракси се та улога практично не примењује.. |
| дбцреатор | Чланови улоге могу да креирају, мењају, бришу и враћају базе података. |
| јавни | Свака пријава на СКЛ Сервер је у овој улози. Чланство у јавности не може да се промени. Када корисник нема дозволу за објект којем приступа, корисник насљеђује дозволе јавне улоге за овај објект. |
Шема улога СКЛ сервера:
У пракси, употреба улога сервера није нарочито уобичајена, јер често кориснику треба јединствени скуп дозвола. Изузетак може бити улога сисадмин за администраторе система и улога јавности.
Уграђене улоге базе података
| Улога | Опис |
| дб_овнер | Учесници улоге могу извршити све кораке за конфигурирање и одржавање базе података, укључујући брисање. |
| дб_сецуритиадмин | Чланови улоге могу да промене чланство у другим улогама. Чланови ове групе могу потенцијално повећати своја права на дб_овнер, тако да бисте требали узети у обзир да је ова улога једнака дб_овнер. |
| дб_аццессадмин | Чланови улоге могу да контролишу приступ бази података за постојеће пријаве на серверу. |
| дб_бацкупоператор | Чланови улоге могу сигурносно копирати базу података. |
| дб_ддладмин | Чланови улоге могу извршавати било коју ДДЛ наредбу у бази података. |
| дб_датавритер | Чланови улоге могу да креирају / модификују / бришу податке у свим корисничким таблицама у бази података. |
| дб_датареадер | Чланови улоге могу читати податке из свих корисничких таблица. |
| дб_денидатавритер | |
| дб_денидатареадер | Чланови улоге забранили су приступ табелама корисничких база података. |
Такође је вредно издвојити посебне улоге у МСдб бази података.
| дб_ссисадмин дб_ссисоператор дб_ссислтдусер | Чланови ових улога могу да администрирају и користе ССИС (СКЛ Сервер Интегратион Сервицес). |
| дц_админ дц_оператор дц_проки | Припадници ових улога могу да администрирају и користе сакупљач података.. |
| ПолициАдминистраторРоле | Чланови ове улоге имају пуни приступ политикама СКЛ Сервера. |
| СерверГроупАдминистраторРоле СерверГроупРеадерРоле | Чланови ових улога имају потпуни приступ регистрованим групама сервера.. |
| СКЛАгентУсерРоле СКЛАгентРеадерРоле СКЛАгентОператорРоле | Чланови ових улога имају потпуни приступ пословима агента СКЛ Сервер. |
Шема за улоге уграђене базе података у СКЛ Серверу:
Улоге у апликацијама
Улога апликације је објект базе података (исти као и редовна улога базе података) који омогућава провјеру аутентичности лозинке да промијени сигурносни контекст у бази података. За разлику од улога базе података, улоге апликација су подразумевано неактивне и активирају се када апликација изврши сп_сетаппроле и унесе одговарајућу лозинку.
За разлику од редовних улога, апликације се готово никада не користе. Као изнимка, њихова се примјена може наћи у вишеслојним апликацијама..
Филтрирање података на СКЛ Серверу
Филтрирање података у СКЛ Серверу путем похрањених процедура / погледа / функција може се приписати имплементацији принципа најмање привилегија, јер не пружате приступ свим подацима у табели, већ само неким од њих.
На пример, кориснику можете одобрити само СЕЛЕЦТ права из погледа и спречити директан приступ табелама које се користе у приказу. На тај начин ћете обезбедити приступ само делу података из табеле постављањем филтера где у приказу.
Филтрирање података путем нивоа сигурности
Сигурност нивоа реда или Сигурност на нивоу реда (РЛС) омогућава филтрирање података таблице за различите кориснике по прилагођеном филтру. То се врши путем ПОЛИТИКЕ СИГУРНОСТИ у Т-СКЛ-у
На овом снимку политике је конфигурисано на начин да корисник Салес1 ће видети редове табеле у којој је вредност ступца Салес корисничко име (Салес1), а корисник Манагер ће видети све редове.
Шеме на СКЛ Серверу
Неки објекти СКЛ Сервер (табеле, процедуре, прикази, функције) имају шему. Шеме се могу сматрати контејнерима за различите објекте (или простор имена, ако сте упознати са програмирањем).
На пример, ако корисник има право да бира из неке шеме, тада корисник може да бира и из свих објеката ове шеме. Односно, објекти који припадају шеми наслеђују његове дозволе. Када корисници креирају објекте у дијаграму, објекти припадају власнику дијаграма, а не кориснику. Корисници не наслеђују дозволе од шеме. И.е. корисници са заданом дбо шемом немају одобрења одобрена за ову схему - морају бити изричито наведена.
Главна разлика између шема и улога је та што се дозволе за схему могу додијелити улогама. На пример, улога тестова може имати дозволе за одабир из схеме1 и дозволе за избор / ажурирање на схеми2. Објект може припадати само једној шеми, али неколико улога може имати права на њега.
Уграђени кругови
СКЛ Сервер има уграђене системске шеме:
- дбо
- гост
- сис
- ИНФОРМАТИОН_СЦХЕМА
Дбо схема је задана схема за нове базе података, а корисник дбо је власник дбо схеме. Нови корисници у бази података подразумевано имају дбо схему као задану схему. Остале уграђене шеме потребне су за системске објекте СКЛ Сервер..
Шифрирање података помоћу СКЛ сервера
СКЛ Сервер може шифровати податке, процедуре и везе са сервером. Шифрирање је могуће помоћу цертификата, асиметричног или симетричног кључа. СКЛ Сервер користи хијерархијски модел шифрирања, то јест, сваки слој хијерархије шифрира слој испод њега. Подржани су сви добро познати и популарни алгоритми за шифровање. За имплементацију алгоритама за шифровање користи се Виндовс Црипто АПИ..
Најчешћи типови шифрирања су ТДЕ (Транспарентно шифровање података) и Увек шифровано.
Транспарентно шифровање података
Транспарентно шифровање података или Транспарентно шифровање података шифрира целу базу података. Ако је украден физички медиј или .мдф / .лдф датотека, нападач неће моћи приступити информацијама у бази података.
Графикон, који представља цео процес
Основно шифровање базе података путем Т-СКЛ-а:
УСЕ мастер;
ГО
ЦРЕАТЕ МАСТЕР КЕИ ЕНЦРИПТИОН БИ ПАССВОРД = 'лозинка';
иди
ЦРЕАТЕ ЦЕРТИФИЦАТЕ СерверЦерт С СУБЈЕЦТ = 'ДЕК сертификат';
иди
УСЕ АдвентуреВоркс2012;
ГО
УСТВАРИТЕ КЉУЧ ЕНЦРИПЦИЈЕ БАЗЕ ПОДАТАКА
СА АЛГОРИТЕМ = АЕС_128
УКЉУЧИВАЊЕ ОД сервера сертификатом СерверЦерт;
ГО
АЛТЕР ДАТАБАСЕ АдвентуреВоркс2012
УКЉУЧИТЕ УКЉУЧИВАЊЕ;
ГО
Увек шифрован
Ова технологија омогућава вам чување шифрованих података у СКЛ Серверу без преношења кључева за шифровање на сам СКЛ Сервер. Увек шифрован, попут ТДЕ, шифрира податке у бази података, али не на нивоу базе података, већ на нивоу колоне.
За шифровање Алваис Енцриптед користи 2 тастера:
- Шифра за шифровање у колони (ЦЕК)
- Главни кључ колоне (ЦМК)
Сви процеси шифрирања и дешифровања података одвијају се на клијенту, само шифрована вредност кључа за шифровање (ЦЕК) се чува у бази података.
Увек шифрован такође вам омогућава да ограничите приступ подацима чак и за ДБА, пружајући вам прилику да не бринете да ће администратор добити приступ подацима који не би требало да буду.
Када се користи шифрирање СКЛ сервера?
Шифрирање података једна је од важних мера безбедности, али шифровање може бити захтевно за ресурсе сервера и понекад може бити сувишно..
Ако корисници приступе подацима путем јавне мреже, можда ће бити потребна шифрирање за осигурање сигурности, али ако се подаци преносе преко сигурне интранета или ВПН-а, нема потребе за шифрирањем података. Такођер је вриједно размотрити могућност шифрирања података ако постоји пријетња крађе физичких медија с базама података.
Имплементација шифрирања требало би бити добро планирана: морате узети у обзир додатно оптерећење на послужитељу, могу ли апликације које раде са вашим сервером имплементирати подршку за ову врсту шифрирања са њихове стране и многе друге нијансе..
Кориштење групних сервисних налога за СКЛ Сервер
Групни рачуни за услуге управљања или гМСА - Ово је посебан налог којим аутоматски управља Ацтиве Дирецтори. гМСА је еволуција МСА технологије јер МСА није било могуће користити у кластер сценаријима.
гМСА елиминише потребу за ручном променом лозинки за налог. Када подешавате гМСА, назначујете на којим серверима ће се гМСА налог покренути, колико често ће Ацтиве Дирецтори мењати лозинку и ко има право на преглед лозинке. На серверима на којима ће бити инсталиран гМСА, не морате да наведете лозинку приликом навођења одговарајућег гМСА налога.
Имајте на уму да верзија Виндовс сервера за рад са гМСА мора бити најмање 2012.
Процена рањивости СКЛ Сервер-а путем ССМС-а
СКЛ Сервер Манагемент Студио има значајку процене рањивости за базу података..
Изаберите базу података -> Задаци -> Процена рањивости -> Скенирање рањивости.
Скенер ће проценити базу података према популарним грешкама у безбедносној конфигурацији и дати одговарајуће препоруке..
Свакако треба проћи кроз овај скенер база података. Може открити скривене проблеме који нису видљиви на први поглед..
Активности ревизије у СКЛ Серверу
СКЛ Сервер пружа могућност ревизије било које корисничке активности у инстанци сервера.
Ово је веома моћан алат који вам омогућава да у потпуности контролишете акције својих корисника / програмера..
Размотрите основно подешавање ревизије:
У ССМС-у, на картици Сигурност -> Ревизије, направите нову ревизију.
Затим за ревизију морате креирати Спецификацију ревизије која ће назначити догађаје који ће се надзирати.
Након што креирате и активирате ревизију, у дневнику ревизије можете видети догађаје који су евидентирани поступком ревизије..
Најбоље праксе опште сигурности СКЛ Сервер-а
Увек следите принцип најмање привилегије. Укључујући конфигурисање налога услуге СКЛ Сервер помоћу гМСА. Никада не користите налог домена са привилегијама администратора домена..
Начело најмање привилегија
Када правите нове кориснике, препоручује се коришћење принципа ЛУА (Кориснички рачун са најмање повластицама или Рачун са најмање права) Овај принцип је важан део сигурности сервера и података..
Корисницима са административним правима препоручује се издавање дозвола само за оне операције које ће им бити потребне. Уграђене улоге сервера требало би користити само када се њихов скуп дозвола подудара са задацима корисника..
Давање улога, а не корисницима
Када постоји много корисника, управљање њиховим дозволама постаје теже, а такође је и теже спречити грешке у давању права.
Препоручује се да дозволе дате улогама и додате кориснике на улоге. На овај начин ћете постићи већу транспарентност, јер ће сви корисници одређене улоге имати иста права. Додавање или уклањање корисника из улоге је лакше од поновног креирања појединачних скупова дозвола за поједине кориснике. Улоге се могу угнијездити, али то се не препоручује, због мање транспарентности и потенцијалне деградације перформанси (ако има превише угнијежђених улога).
Корисничким правима на схему можете одобрити. У овом случају, корисници ће одмах моћи да раде са новоствореним објектима у овој шеми, за разлику од улога, при креирању новог објекта улоге ће му требати доделити права на њега.
