Бяспека мае першараднае значэнне для адміністратараў база дадзеных , якія імкнуцца абараніць свае гігабайты жыццёва важных бізнес - дадзеных ад старонніх вачэй старонніх старонніх і інсайдэраў , якія спрабуюць перавышаюць свае паўнамоцтвы. Усе рэляцыйныя сістэмы кіравання базамі дадзеных забяспечваюць якое - то ўнутраныя механізмы бяспекі , прызначаных для мінімізацыі гэтых пагроз. Яны вар'іруюцца ад простай абароны паролем , прапанаваных Microsoft Access да складанай структуры карыстальнік / ролю пры падтрымцы перадавых рэляцыйных баз дадзеных , такіх як Oracle і Microsoft SQL Server. У дадзеным артыкуле разглядаюцца механізмы бяспекі , агульныя для ўсіх баз дадзеных , якія рэалізуюць Structured Query Language (або SQL ). Разам мы будзем ісці праз працэс узмацнення кантролю доступу да дадзеных і забеспячэння бяспекі вашых дадзеных.
карыстальнікаў
баз дадзеных Серверныя ўсе падтрымліваюць канцэпцыю карыстальніка аналагічную той, якая выкарыстоўваецца ў кампутарных аперацыйных сістэмах. Калі вы знаёмыя з іерархіяй карыстальнікаў / груп знойдзена ў Microsoft Windows NT і Windows 2000, вы ўбачыце, што карыстальнік / ролю групоўкі, якія падтрымліваюцца SQL Server і Oracle вельмі падобныя.
Настойліва рэкамендуецца ствараць асобныя уліковыя запісы карыстальнікаў базы дадзеных для кожнага чалавека, які будзе доступ да базы дадзеных. Гэта тэхнічна магчыма падзяліць рахункі паміж карыстальнікамі або проста выкарыстоўваць адзін уліковы запіс карыстальніка для кожнага тыпу карыстальнікаў, якім неабходны доступ да базы дадзеных, але я моцна перашкаджаць гэтую практыку па дзвюх прычынах. Па-першае, гэта ліквідуе індывідуальную адказнасць: калі карыстальнік ўносіць змены ў базе дадзеных (скажам, даючы сабе павышэнне $ 5000), то вы не зможаце прасачыць яго назад да канкрэтнага чалавека праз выкарыстанне часопісаў аўдыту. Акрамя таго, калі канкрэтны карыстальнік пакідае арганізацыю, і вы хочаце, каб выдаліць яго ці яе доступ з базы дадзеных, вы будзеце вымушаныя змяніць пароль, усе карыстальнікі належаць на.
Метады стварэння уліковых запісаў карыстальнікаў змяняюцца ад платформы да платформе, і вы павінны пракансультавацца з СКБД канкрэтнай дакументацыі для дакладнай працэдуры. карыстальнікам Microsoft SQL Server варта вывучыць выкарыстанне захоўваемай працэдуры sp_adduser. адміністратары баз дадзеных Oracle будзе знайсці CREATE USER Каманда карысная. Вы таксама можаце даследаваць альтэрнатыўныя схемы аўтэнтыфікацыі. Напрыклад, Microsoft SQL Server падтрымлівае выкарыстанне Windows NT Integrated Security. Згодна з гэтай схеме, карыстальнікі ідэнтыфікуюцца ў базу дадзеных з дапамогай іх уліковых запісаў карыстальнікаў Windows NT і не патрабуецца, каб увесці дадатковы ідэнтыфікатар карыстальніка і пароль для доступу да базы дадзеных. Такі падыход з'яўляецца надзвычай папулярным сярод адміністратараў база дадзеных, паколькі яна перакладае цяжар кіравання лікам для супрацоўнікаў сеткавага адміністравання і забяспечвае лёгкасць адзінага ўваходу для канчатковага карыстальніка.
ролі
Калі вы знаходзіцеся ў асяроддзі з невялікім лікам карыстальнікаў, вы, верагодна, выявіце, што стварэнне уліковых запісаў карыстальнікаў і прызначэнне правоў непасрэдна да іх дастаткова для вашых патрэб. Тым не менш, калі ў вас ёсць вялікая колькасць карыстальнікаў, вы, хутчэй за ўсё, будзеце перагружаныя цяжарам вядзення рахункаў і адпаведных дазволаў. Каб палегчыць гэты цяжар, рэляцыйныя базы дадзеных падтрымліваюць паняцце роляў. Ролі базы дадзеных функцыянуюць аналагічна групам Windows NT. Уліковыя запісы карыстальнікаў прызначаюцца ролі (ёй) і дазволу затым прызначаюцца на ролю ў цэлым, а не асобныя уліковыя запісы карыстальнікаў. Напрыклад, мы маглі б стварыць DBA ролю, а затым дадаць уліковыя запісы карыстальнікаў нашага адміністрацыйнага персаналу на гэтую ролю. Пасля таго, як мы зрабілі гэта, мы можам прызначыць пэўны дазвол для ўсіх прысутных (і будучых) адміністратараў, проста прысвоіўшы дазволу на ролі. Зноў жа, працэдуры стварэння роляў залежыць ад платформы. Адміністратары MS SQL Server варта вывучыць зберажоную працэдуру sp_addrole у той час як Абд Oracle варта выкарыстоўваць сінтаксіс CREATE ROLE.
прадастаўленне дазволаў
Цяпер, калі мы дадалі карыстальнікаў у нашу базу дадзеных, прыйшоў час пачаць ўмацаванне бяспекі шляхам дадання дазволаў. Наш першы крок будзе прадастаўляць адпаведныя дазволу базы дадзеных для нашых карыстальнікаў. Мы будзем выконваць гэта з дапамогай заявы SQL GRANT.
Вось сінтаксіс аператара:
GRANT <дазвол>
[ВКЛ <табліца>]
TO <карыстальнік / ролю>
[WITH GRANT OPTION]
Зараз давайце зірнем на гэтую заяву лініі парадкова. Першы радок, GRANT <дазвол>, дазваляе паказаць канкрэтныя дазволу табліцы мы ўлічваем. Яны могуць быць альбо дазволу табліцы ўзроўню (напрыклад, SELECT, INSERT, UPDATE і DELETE) або дазволу базы дадзеных (напрыклад, CREATE TABLE, ALTER DATABASE і GRANT). Больш дазвол можа быць прадастаўлена ў адным аператары GRANT, але дазволу табліцы ўзроўню і дазвол на ўзровень базы дадзеных не могуць быць аб'яднаны ў адным заяве.
Другая лінія, ON <табліца>, выкарыстоўваецца для ўказанні здзіўленай табліцы дазволаў ўзроўню табліцы. Гэтая лінія апускаецца, калі мы выдача дазволаў на ўзровень базы дадзеных. Трэці радок паказвае карыстальніка ці ролі, якія выдаюцца дазволу.
І, нарэшце, чацвёртая радок, WITH GRANT OPTION, не з'яўляецца абавязковым. Калі гэты радок уключаецца ў справаздачу, карыстальнік ўплывае таксама дазволена прадастаўляць гэтыя ж дазволу іншым карыстальнікам. Звярніце ўвагу, што опцыя WITH GRANT OPTION не можа быць паказана, калі дазволу прызначаюцца ролі.
прыкладаў
Давайце разгледзім некалькі прыкладаў. У нашым першым сцэнары мы нядаўна нанялі групу з 42 аператараў ўводу дадзеных, якія будуць дадаваць і падтрыманне запісаў аб кліентах. Яны павінны быць у стане атрымаць доступ да інфармацыі ў табліцы Customers, змяняць гэтую інфармацыю і дадаваць новыя запісы ў табліцу. Яны не павінны быць у стане цалкам выдаліць запіс з базы дадзеных. Па-першае, мы павінны стварыць уліковыя запісы для кожнага аператара, а затым дадайце іх у новую ролю, ВаЬаЕпЬгу. Далей, мы павінны выкарыстоўваць наступны SQL заяву, каб даць ім адпаведныя правы доступу:
GRANT SELECT, INSERT, UPDATE
Па жаданні кліентаў
Да DataEntry
І гэта ўсё, што ёсць да гэтага! Зараз давайце разгледзім выпадак, калі мы прысвойваем правы доступу на ўзроўні базы дадзеных. Мы хочам, каб члены ролі DBA, каб дадаць новыя табліцы ў нашу базу дадзеных. Акрамя таго, мы хочам, каб мець магчымасць даць іншым карыстальнікам дазвол зрабіць тое ж самае. Вось SQL заяву:
GRANT CREATE TABLE
Да DBA
WITH GRANT OPTION
Звярніце ўвагу, што мы ўключылі OPTION лінію WITH GRANT, каб гарантаваць, што нашы адміністратары баз дадзеных могуць прызначыць такі дазвол іншым карыстальнікам.
выдаленне дазволаў
Пасля таго, як мы прадастаўлены дазволу, часта аказваецца неабходным адмяніць іх на больш позні тэрмін. На шчасце, SQL дае нам каманду REVOKE для выдалення раней прадастаўленых дазволаў. Вось сінтаксіс:
REVOKE [GRANT OPTION FOR] <дазволу>
ON <табліца>
FROM <карыстальнік / ролю>
Вы заўважыце, што сінтаксіс гэтай каманды аналагічна камандзе GRANT. Адзінае адрозненне складаецца ў тым, што WITH GRANT OPTION указана ў камандным радку REVOKE, а не ў канцы каманды. У якасці прыкладу, давайце прадставім, што мы хочам адмяніць раней прадастаўленае дазвол Марыі, каб выдаліць запісы з базы дадзеных Customers. Мы будзем выкарыстоўваць наступную каманду:
КЕУОКЕ DELETE
Па жаданні кліентаў
АД Марыі
І гэта ўсё, што ёсць да гэтага! Там адзін дадатковы механізм падтрымліваецца Microsoft SQL Server, які варта адзначыць, каманду DENY. Гэтая каманда можа быць выкарыстана, каб відавочна забараніць дазвол для карыстальніка, што яны, магчыма, інакш праз бягучае або будучыню сяброўства ў ролі. Вось сінтаксіс:
Забаранілі <дазволу>
ON <табліца>
TO <карыстальнік / ролю
прыкладаў
Вяртаючыся да нашага папярэдняга прыкладу, давайце прадставім, што Марыя была таксама членам ролі менеджэраў, якія таксама мелі доступ да табліцы Customers. Папярэднюю заяву КЕУКА не будзе дастаткова, каб забараніць ёй доступ да стала. Гэта ліквідавала б дазвол, прадастаўленае ёй праз GRANT заяву таргетавання яе уліковы запіс карыстальніка, але не ўплывае на правы доступу, назапашаных падчас яе сяброўства ў ролі менеджэраў. Аднак, калі мы выкарыстоўваем DENY заяву ён будзе блакаваць яе спадчыну дазволу. Вось каманда:
Забаранілі DELETE
Па жаданні кліентаў
Марыі
Каманда адмаўляў па сутнасці стварае «адмоўнае дазвол» у кантролі доступу да баз дадзеных. Калі пазней мы вырашылі даць Мэры дазволу на выдаленне радкоў з табліцы Customers, мы не можам проста выкарыстоўваць каманду GRANT. Гэтая каманда будзе неадкладна адменена існуе забарона. Замест гэтага мы будзем выкарыстоўваць каманду REVOKE, каб выдаліць адмоўны элемент дазволу наступным чынам:
КЕУОКЕ DELETE
Па жаданні кліентаў
АД Марыі
Вы заўважыце, што гэтая каманда сапраўды гэтак жа, як тая, якая выкарыстоўваецца для выдалення станоўчага дазволу. Памятаеце, што адмаўляюць і GRANT каманды абодва працуе аналагічным чынам * mdash; абодва яны ствараюць дазвол (станоўчае ці адмоўнае) у механізме кіравання доступам да базы дадзеных. Каманда REVOKE выдаляе ўсе станоўчыя і адмоўныя дазволу для названага карыстальніка. Пасля таго, як гэтая каманда была выдадзена, Мэры будзе мець магчымасць выдаляць радкі з табліцы, калі яна з'яўляецца членам ролі, якая валодае такім дазволам. Акрамя таго, каманда GRANT можа быць выдадзена для прадастаўлення Выдаліць дазволу непасрэдна на яе рахунак.
На працягу гэтага артыкула, вы даведаліся шмат пра механізмы кантролю доступу, якія падтрымліваюцца Standard Query Language. Гэта ўвядзенне павінна забяспечыць вас з добрай адпраўной кропкай, але я заклікаю вас спасылацца на дакументацыю СКБД, каб даведацца ўзмоцненыя меры бяспекі, якія падтрымліваюцца вашай сістэмай. Вы выявіце , што многія базы дадзеных падтрымліваюць больш прасунутыя механізмы кантролю доступу, такія як прадастаўленне дазволу на пэўных слупках.