Информация об изменениях в платформе и прикладных решениях на нашем официальном телеграм канале. Подписывайтесь!

Сістэма бяспекі платформы Гедымін

Праграмовае абсталяваньне кшталту Гедыміна мусіць мець уласную сістэму бяспекі, каб прадухіліць несанкцыяваны доступ да дадзеных, альбо функцыяў сістэмы.

З пункту гледжаньня распрацоўшчыка, сістэма бяспекі Гедыміна падзяляецца на тры часткі:

  1. аўтарызацыя карыстальніка і падключэньне да базы дадзеных;
  2. размежаваньне доступу да дадзеных;
  3. размежаваньне доступу да функцыяў сістэмы.

СІСТЭМА БЯСПЕКІ INTERBASE

Перш чым паглыбіцца ў архітэктуру сістэмы бяспекі Гедыміна трэба разгледзіць стандартныя сродкі аўтарызаціі карыстальнікаў і размежаваньня правоў доступу, закладзеныя ў сэрвер баз дадзеных Interbase/Firebird. Яны адпавядаюць стандарту SQL92 і мы ня маем на мэце паўтараць тут дакументацыю па SQL цалкам. Сціслага агляду будзе больш чым дастаткова.

Аўтарызацыя карыстальніка

Для таго, каб пасылаць на сэрвер запыты і атрымоўваць выніковыя дадзеныя неабходна ўсталяваць падключэньне да сэрверу. Для гэтага з кліентскага дастасаваньня неабходна выклікаць адпаведную функцыю, перадаўшы ў яе імя карыстальніка, пароль і, не абавязкова, ролю. Толькі зарэгістраваныя на сэрверы карыстальнікі могуць атрымаць доступ да базы дадзеных. Пры гэтым, сьпіс карыстальнікаў захоўваецца на сэрверы ў асобнай базе і не з’яўляецца часткай кліентскай базы дадзеных. З аднаго боку гэта дазваляе группе карыстальнікаў карыстацца некалькімі базамі дадзеных, фізічна размешчаных на адным сэрвере, без настройкі сьпісу карыстальнікаў для кожнай базы па-асобку, з другога ж — такая арганізацыя захоўваньня дадзеных аб карыстальніках патрабуе дадатковых намаганьняў пры пераносе базы з аднаго сэрвера на іншы.

Карыстальнік SYSDBA

Адразу пасля ўсталяваньня сэрверу Interbase, на ім існуе толькі адзін уліковы запіс для сістэмнага адміністратара базы дадзеных (лагін: SYSDBA) з паролем masterkey. Гэты ўліковы запіс з’яўляецца зарэзерваваным і мае найбольшыя паўнамоцтвы. Карыстальнік SYSDBA мае доступ да ўсіх аб’ектаў базы дадзеных, а, таксама, да сэрвісных функцыяў сэрверу: архівіраваньню базы дадзеных, праверкі яе цэласнасці і г.д. Зайшоўшы пад SYSDBA можна ствараць, мадыфікаваць і выдаляць уліковыя запісы іншых карыстальнікаў.

Улічваючы вышэйазначаныя акалічнасці важна адразу пасля ўстаноўкі сэрверу Interbase змяніць пароль для сістэмнага адміністратара .

Размежаваньне доступу

Адразу пасля стварэньня табліцы, ўяўленьня альбо працэдуры толькі стваральнік, альбо SYSDBA мае да яе доступ. Калі неабходна адкрыць доступ да гэтага аб’екта іншым карыстальнікам трэба выканаць каманду GRANT указаўшы аб’ект, карыстальніка, альбо ролю і неабходны тып доступу.

На табліцу можна даць доступ на прагляд, мадыфікацыю і выдаленьне дадзеных. Пры гэтым доступ можа распаўсюджвацца як на усе, так і толькі на пэўную частку калёнак.

Для працэдуры можна задаць сьпіс карыстальнікаў альбо роляў, якія будуць мець права на яе запуск.

Асобна можна даць доступ працэдурам, альбо трыгерам да пэўнай табліцы. Гэта дазваляе будаваць досыць складаныя схэмы бяспекі, калі карыстальнік мае доступ да працэдуры, якая ў сваю чаргу мае доступ да канкрэтнай табліцы, да якой карыстальнік не мае прамога доступу.

Ролі Interbase

Каб атрымаць доступ да аб’ектаў базы дадзеных, усе карыстальнікі, акрамя SYSDBA, мусяць атрымаць грант ад адміністратара, альбо іншага карыстальніка сэрверу, які мае на гэты права. Паколькі, аб’ектаў у рэальнай базе можа быць некалькі тысячаў і нават болей, простая аперацыя дабаўленьня новага карыстальніка ў сістэму можа заняць шмат часу. Да таго ж, прысваіваючы грант на кожную табліцу, працэдуру, альбо ўяўленьне легка памыліцца і даць карыстальніку доступ да дадзеных, да якіх ён ня мусіць мець доступу, ці наадварот — ня даць доступу да патрэбных дадзеных.

Каб спрасціць размежаваньне праваў доступу, ў стандарт SQL былі ўведзеныя ролі. У адрозненьне ад уліковых запісаў карыстальнікаў сэрверу, ролі захоўваюцца не на сэрверы, а непасрэдна ў прыкладной базе. Ствараючы базу, распрацоўшчык назначае пэўным ролям права на пэўныя аб’екты. Далей, пры эксплюатацыі базы дадзеных, пры стварэньні на сэрверы новага карыстальніка, каб даць яму доступ да аб’ектаў базы дадзеных дастаткова даць доступ да адной, ці некалькіх роляў, якія, у сваю чаргу, маюць доступ да гэных аб’ектаў базы. Пры усталяваньні падключэньня да сэрверу з выкарыстаньнем роляў неабходна ўказаць імя карыстальніка, пароль і ролю. Пры гэтым адзін і той жа карыстальнік можа падключацца да сэрвера пад рознымі ролямі і ў залежнасці ад апошняй яму будуць даступны тыя, ці іншыя аб’екты базы.

Абмежаваньні на дліну імя і паролю

Хаця, пры стварэньні карыстальніка можна ўказаць імя і пароль даўжынёй да 32 сімвалаў значнымі з іх з’яўляюцца толькі першыя 8. Напрыклад, паролі: my_password і my_passw123 будуць успрымацца сэрверам як ідэнтычныя.

СІСТЭМА БЯСПЕКІ GEDEMIN

Ня гледзячы на тое, што сэрвер Interbase дазваляе размежаваць доступ да асобных табліцаў і працэдураў, весьці сьпіс карыстальнікаў і, нават, упарадкоўваць іх у группы (праз выкарыстаньне роляў), гэтых сэрвісаў яўна не дастаткова для задавальненьня патрабаваньняў да сістэмы бяспекі праекту Gedemin.

Па-першае, Interbase не дазваляе выкарыстоўваць беларускія літары ў імёнах карыстальнікаў і паролях. Па-другое, мы маем неабходнасць у больш дэталёвым кіраваньні ўліковымі запісамі карыстальнікаў. Напрыклад, часова адключыць карыстальніка без выдаленьня яго з сэрверу, абмежаваць працоўны час карыстальніка і г.д. Па-трэцяе, размежаваньня доступу на ўзроўне табліцаў і калёнак нам недастаткова. Нам патрэбна магчымасць забараніць пэўным карыстальнікам доступ да пэўных запісаў табліцы. Пры гэтым забаронен можа быць як прагляд запісу, так і яго мадыфікацыя, альбо выдаленьне. Па-чацвертае, у Gedemin’е можна назначаць правы карыстальнікам не толькі на дадзеныя, але і на аперацыі (напрыклад, друкаваньне, альбо зьмена правоў на запіс).

Улічваючы вышэйзгаданыя магчымасці сэрверу Interbase і патрабаваньні да праекту Gedemin мы стварылі наступную сістэму бяспекі.

Карыстальнікі і группы

Для кожнага карыстальніка сістэмы ствараецца ўліковы запіс, яму прысвайваецца імя (лагін) і пароль, а таксама настрайваюцца параметры: працоўны час (уваход па-за межамі працоўнага часу забаронены), ці мае пароль тэрмін дзеяння, калі так, тады ўводзіцца дата да якой дзейнічае пароль, ці можа карыстальнік самастойна змяніць свой пароль. Уліковы запіс (акаўнт) можна заблакаваць, каб часова забараніць карыстальніку ўваход у сістэму, а таксама ўказаць ці будуць дзеянні карыстальніка рэгістравацца ў журнале.

Кожны ўліковы запіс мусіць быць звязаны з запісам у даведніку кантактаў (фізічных асобаў). Гэтую сувязь мы выкарыстоўваем каб зафіксаваць стваральніка і апошняга мадыфікатара дакумента (альбо іншага запісу ў базе, для якога мы адсочваем гісторыю змяненьняў). Дадзеныя могуць накаплівацца шмат гадоў, і чалавек, які ствараў запіс, можа ўжо пакінуць арганізацыю. З-за патрабаваньняў бяспекі ягоны ўліковы запіс павінен быць выдалены, але запіс у даведніку кантактаў захаваецца і, адпаведна, захаваецца інфармацыя аб стваральніку і мадыфікатару таго, ці іншага дакумента.

Кожны карыстальнік павінен уваходзіць у адну ці некалькі групаў. З-за патрабаваньняў да прадукцыйнасці сістэмы мы стварылі сваю арыгінальную сістэму размежаваньня правоў доступу да розных запісаў у адной табліцы. Яна аснована на дэскрыптарах бяспекі — цэлалікавых палях, якіх можа быць да трох: кожнае для размежаваньня доступу на узроўні прагляду дадзеных, іх змяненьня і выдаленьня. Імёны палёў мусяць быць: AVIEW для дэскрыптару бяспекі прагляду запісу, ACHAG — зьмяненьня, AFULL — выдаленьня. Як мы ўжо адзначылі вышэй у табліцы можа быць нуль, адно, два, альбо тры дэскрыптара бяспекі.

Дэскрыптар бяспекі — гэта 32-х бітавая маска, кожны біт якой паказвае ці ёсць у адпаведнай группы карыстальнікаў права на дадзены тып доступу. Напрыклад, калі ў табліцы ёсць дэскрыптар AVIEW і для пэўнага запісу ён мае значэньне 147 дзес.= 10010011 дв., тады гэта азначае, што першая, другая, пятая і восьмая группы карыстальнікаў маюць права на прагляд дадзенага запісу. Кожны запіс можа мець свой набор группаў, якія могуць яго праглядваць, змяняць, ці выдаляць.

Выкарыстаньне такой схемы накладвае на нас пэўныя абмежаваньні. Па-першае, нельга прысвоіць правы асобнаму карыстальніку, а толькі группе. Па другое, агульнае колькасць групаў абмежавана і раўна колькасці бітаў у цэлым — 32.

Андрэй Кірэеў