Diferenciace přístupových práv v síti, sdílený diskový prostor v lokální síti. Diferenciace přístupových práv a autentizace uživatelů

Ve své praxi vývoje webu jsem se velmi často setkával se situacemi, kdy si zákazníci stanovili konkrétní cíl, a to oddělení částí admin panelu ohledně přístupnosti pro určité uživatele. Zároveň byl vývoj tohoto modulu prováděn v kontextu rozšiřitelného systému, tedy s nefixním počtem modulů, ke kterým je organizován přístup, a tedy neomezeným počtem uživatelů systému.

No po svém toto téma poměrně těžký a vyžaduje určitý čas na analýzu a formulaci problému.

V kontextu tohoto článku se budeme vyvíjet v kontextu nějakého abstraktu informační systém, s vlastní infrastrukturou a architekturou, přičemž tento systém poskytuje uživateli možnost rozšiřovat funkcionalitu, tedy instalovat nové moduly a podle toho k nim nastavovat přístupová práva tomu či onomu uživateli registrovanému jako správce systému.

Pojďme nejprve probrat architekturu modulárního systému na pseudosystému dle našeho výběru.

Všechny moduly jsou prezentovány jako přílohy připojené k hlavnímu dokumentu (index souboru). Požadavek modulu pochází z řetězce dotazu QUERY_STRING a název plug-in programu je předán jako argument act. V určitém bodě indexu souboru je tento parametr načten a zpracován. Poté, pokud má uživatel dostatečná práva pro přístup k modulu v kontextu čtení, je zkontrolována existence modulu uvedeného v řetězci dotazu, a pokud existuje, je připojen k indexovému souboru.

Nezmínil jsem se jen o „kontextu čtení“, protože náš systém předpokládá existenci dvou kontextů pro práci se systémem, a to čtení a psaní. Čtení zároveň předpokládá přímý přístup do modulu a do těch jeho částí, které nevyžadují změny datové struktury v databázi. Pod záznamem má přímo provádět změny informací uložených v databázi.

Pro implementaci tohoto mechanismu zkontrolujeme hodnotu řetězcová proměnná požadavek `do`, který je zpracován v samotném modulu a nese informaci o tom, do které části modulu je potřeba uživateli udělit přístup.

Hodnota do bude pevná, tato proměnná bude mít následující hodnoty:

• main - hlavní část modulu (dostupná v kontextu čtení)
• config - sekce konfigurace modulu (dostupná v kontextu položky)
• vytvořit - provést některé akce pro přidání informací do databáze (dostupné v kontextu záznamu)
• smazat - přístup do sekce, která poskytuje možnost smazat některé informace v kontextu tohoto modulu (dostupné v kontextu záznamu)
• editovat - přístup k editaci informací v kontextu modulu (dostupné v kontextu záznamu)

Obecně lze tento seznam navýšit, přičemž vše závisí pouze na rozsahu projektu a jeho potřebách na funkčnost.

Nyní přímo o modulech. Kromě fyzické existence určitého modulu v kontextu souborového systému projektu musí být modul také přidán do speciální databázové tabulky, která bude obsahovat informace o všech existujících modulech v systému. Přidávání a změna údajů této tabulky se obvykle provádí přímo v kontextu modulů, tedy při jejich instalaci do systému. To už je ale prohloubení principů pohledu na rozšiřitelné systémy, o kterých si povíme někdy jindy, a proto se omezíme na ruční aktualizace a přidávání dat o modulech.

Záznam o systémovém modulu tedy bude obsahovat tyto informace: anglický identifikátor názvu modulu, který bude shodný s hodnotou proměnné prostředí GET - act (modul bude proti němu přímo požadován), ruský modul identifikátor, který bude použit v seznamu modulů.

Kromě modulů budeme mít ještě dvě tabulky, a to tabulku, která bude ukládat data týkající se profilů přístupových práv a tabulku s informacemi přímo o uživatelích.

Tabulka bezpečnostního profilu se bude skládat pouze ze tří polí - identifikátor profilu (číselná hodnota identifikátoru záznamu), identifikátor textového modulu (určený pro uživatele) a také speciálně vytvořený textový štítek obsahující informace o právech uživatele v kontextu každého z modulů.

No, podívejme se na tuto speciální strukturu. Bude to: [ module_indefier: + \: + \;] *

To znamená, že existuje seznam dvojic: název modulu ":" oprávnění ke čtení "," oprávnění k zápisu ";". V tomto případě je tento štítek aktualizován v době změn v přístupových právech uživatele do systému. Pokud se v systému objeví informace o modulu, který není součástí tohoto štítku, stačí provést editaci a data se automaticky uloží.

Nyní nám zbývá zvážit strukturu pouze jedné databázové tabulky a můžeme se pustit do implementace algoritmické části, konkrétně tabulky s informacemi o uživatelích systému, protože přidělování přístupových práv je naším hlavním úkolem.

Nebudu k tomu dodávat nic navíc, ale pouze to, co bude použito v kontextu tématu tohoto článku. Tabulka uživatelů bude obsahovat následující pole: ID uživatele (číselné počítadlo), přihlašovací jméno, heslo (hash původního hesla), bezpečnostní profil uživatele (ID skupiny uživatelů, relativní k právům v systému) a je to. Zdá se mi, že tyto informace jsou pro nás k realizaci úkolu dostačující a já již poskytuji možnost udělat si všechny ostatní doplňky sami.

Takže jsme diskutovali o struktuře a doufám, že každý už má nějakou představu o tom, jak implementujeme úkol stanovený v tématu článku. Nyní uvedu pomocný SQL kód výše popsaných tabulek, po kterém okamžitě přistoupím k implementaci algoritmu pro kontrolu uživatelských přístupových práv a také k vytváření a změně přístupových profilů. Po každém jednotlivém modulu podrobně probereme případné dotazy čtenářů.

tabulka "modulů":

CREATE TABLE `modules` (`id` bigint(20) NOT NULL auto_increment, `indefier` text collate utf8_unicode_ci NOT NULL, `title` text collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`FAID`)) AUTO_INCREMENT1My=M CHARSET=utf8 COLLATE=utf8_unicode_ci;

Tabulka `secure_groups`:

CREATE TABLE `secure_groups` (`id` bigint(20) NOT NULL auto_increment, `title` text collate utf8_unicode_ci NOT NULL, `perms` text collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`ID`)) ENG CHARSET=utf8 COLLATE=utf8_unicode_ci ;

Tabulka „uživatelé“.

CREATE TABLE `users` (`id` bigint(20) NOT NULL auto_increment, `login` text collate utf8_unicode_ci NOT NULL, `passwd` text collate utf8_unicode_ci NOT NULL, `groupId` int(1) NOT PRIMARY default "NULL" NOT PRIMARY KEY (`id`)) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ;

temp=pole(); $this->temp["_result"]=0; $this->temp["_uid"]=explode("::",$_COOKIE["site_hash"]); $this->temp["_uid"]=$this->temp["_uid"]; $this->temp["_gid"]=$this->getUserSecurityAccess($this->temp["_uid"]); $this->temp["_conn_id"]=mysql_connect("host","user","passwd"); mysql_select_db("databáze"); $this->temp["_q1"]=mysql_query("SELECT perms" ."FROM `secure_groups`" ."WHERE id=".$this->temp["_gid"]); $this->temp["_access_stamp"]=mysql_fetch_assoc($this->temp["_q1"]); $this->temp["_access_stamp"]=$this->temp["_access_stamp"]["perms"]; $this->temp["_access_stamp"]=explode(";",$this->temp["_access_stamp"]); $this->temp["_access_stamp"]=array_slice($this->temp["_access_stamp"],0,-1); foreach($this->temp["_access_stamp"] jako $this->temp["v"])( $this->temp["_mod_access"]=explode(":",$this->temp["v "]); $this->temp["_mod_indefier"]=$this->temp["_mod_access"]; if($this->temp["_mod_indefier"]==$module)( $this->temp[ "_perms"]=explode(",",$this->temp["_mod_access"]); switch($act)( case "r": $this->temp["_result"]=($this-> temp["_perms"]==1)?1:0; přerušení; velikost písmen "w": $this->temp["_result"]=($this->temp["_perms"]==1)?1 :0; break; ) break; ) ) mysql_close($conn_id); return $this->temp["_vysledek"]; )) ?>

Tato třída implementuje funkce navržené k implementaci výše popsané algoritmické úlohy. Nyní probereme každou funkci zvlášť.

funkce secure::getUserId().

Pomocí této funkce máme na mysli, že při autorizaci uživatele v systému v proměnná prostředí$_COOKIE byl nastaven na proměnnou `site_hash`, která se skládá z ID uživatele v systému a hashe pro ověření jeho pravosti v systému. Funkce jednoduše odstraní hodnotu identifikátoru a vrátí jeho hodnotu jako výstup.

function secure::getUserSecurityAccess($id)

U východu danou funkci vrátí ID bezpečnostního profilu aktuálního uživatele v systému.

secure::checkUserPermission($module,$act)).

Do databáze je položen dotaz týkající se práv uživatele provádět akce čtení/zápisu v kontextu modulu předaného jako parametr.

Zbývá pouze popsat postup vytváření proměnné v prostředí $_COOKIE a téma článku lze považovat za vyřešené.

Postup autorizace bude vypadat jako zadání osobních údajů uživatele (přihlašovací jméno a heslo). speciální formulář, po jehož odeslání budou údaje přenášené uživatelem zpracovány podle metody funkce checkAuthData(), a pokud jsou údaje správné, budou údaje uživatele uloženy ve formě záznamového cookie po dobu uživatelská sada nebo při absenci dané hodnoty pro výchozí období.

Ke kontrole pravosti dat uložených v proměnné prostředí $_COOKIE použijeme funkci EatCookie(), která ověří data a vrátí booleovský výsledek ověření (true - false).

Neposkytuji formulář k odeslání, protože to není součástí teorie programování, pouze specifikuji identifikátory polí.

• `ulogin` - přihlášení uživatele
• `upasswd` - uživatelské heslo
• `stime` - čas relace nastavený uživatelem (od 1 do 5 hodin)
• `auth` - název tlačítka pro odeslání

Tady je to obecně všechno. Nezbývá než zkoušet, experimentovat, dělat chyby a hledat řešení, které nechám zcela na vás.

Doufám, že se brzy setkáme a pro ty, kteří na mě mají dotaz ohledně článku, a nejen to - napište [e-mail chráněný], na obou [e-mail chráněný]

S pozdravem Karpenko Kirill, vedoucí IT oddělení Ústavu průmyslové a průmyslové výroby.

V rozlehlém Rusku mnoho firem a malých podniků nemá vlastní zaměstnance. správce systému trvale nebo čas od času. Firma roste a jedna sdílená složka na síti, kde si každý může dělat, co chce, dříve nebo později nestačí. Vyžaduje řízení přístupu pro různé uživatele nebo skupiny uživatelů na platformě MS Windows. Linuxoidi a zkušení admini prosím nečtěte článek.

Většina nejlepší možnost- najměte si zkušeného administrátora a popřemýšlejte o koupi serveru. Zkušený administrátor na místě rozhodne, zda vychovat čs Windows Server S Aktivní adresář nebo použít něco ze světa Linuxu.

Ale tento článek je napsán pro ty, kteří se rozhodli prozatím trpět sami, bez použití moderny softwarová řešení. Pokusím se alespoň vysvětlit, jak správně provést diferenciaci práv.

Než začneme, rád bych rozebral několik bodů:

• Jakýkoli operační systém „rozpoznává“ a „rozlišuje“ skutečných lidí prostřednictvím jejich účtů. Mělo by to být takto: jedna osoba = jeden účet.
• Článek popisuje situaci, že firma nemá vlastního správce a např. není zakoupen MS Windows Server. Jakýkoli běžný MS Windows současně obsluhuje po síti maximálně 10 lidí pro WinXP a 20 lidí pro Win7. To dělá Microsoft záměrně, aby klientská Windows neběžela přes silnici. Windows servery a nezruinovali jste podnikání Microsoftu. Zapamatujte si číslo 10-20 a až bude mít vaše společnost více než 10-20 lidí, budete muset přemýšlet o koupi MS Windows Serveru nebo někoho požádat, aby vám zřídil bezplatný Linux Samba server, který taková omezení nemá.
• Vzhledem k tomu, že nemáte kompetentního administrátora, bude se za něj vydávat váš běžný počítač s klientským MS Windows souborový server. Budete nuceni na něm duplikovat uživatelské účty z jiných počítačů, abyste získali přístup ke sdíleným souborům. Jinými slovy, pokud existuje účetní Olya s účtem olya v PC1, pak na tomto "serveru" (dále jen WinServer) musíte vytvořit účet olya se stejným heslem jako na PC1.
• Lidé přicházejí a odcházejí. Fluktuace zaměstnanců je všude a pokud vy, ten chudák, který není admin a je přidělen (nucený) podporovat IT záležitosti společnosti, pak tu pro vás máme pár rad. Vytvářejte účty, které nejsou vázány na jednotlivce. Vytvořte pro manažery - manažer1, manažer2. Pro účetní - buh1, buh2. Nebo něco podobného. Odešel ten člověk? Jiný se neurazí, když použije manager1. Souhlasím, je to lepší než používat účet olya pro Semyon, protože je rozbitý nebo není nikdo, kdo by to předělal a vše funguje 100 let.
• Zapomeňte na slova jako: "vytvořit heslo pro složku." Ty časy, kdy bylo zdrojům vnuceno heslo, jsou dávno pryč. Změnila se filozofie práce s různými zdroji. Nyní se uživatel přihlásí do svého systému pomocí účtu (identifikace), potvrdí se heslem (autentizace) a je mu udělen přístup ke všem povoleným zdrojům. Přihlásili jste se jednou a získali přístup ke všemu - to je to, co si musíte zapamatovat.
• Následující akce je vhodné provádět z vestavěného účtu Administrator nebo z prvního účtu v systému, který je standardně zařazen do skupiny Administrators.

Vaření.

V Průzkumníku odeberte zjednodušený přístup k věcem, které potřebujeme.

• MS Windows XP. Nabídka Nástroje - Možnosti složky - Zobrazit. zrušte zaškrtnutí Použijte Průvodce sdílením
• MS Windows 7. Stiskněte Alt. Nabídka Nástroje - Možnosti složky - Zobrazit. zrušte zaškrtnutí Používejte jednoduché obecný přístup do souborů.

Vytvořte si na svém počítači s WinServerem složku, do které bude uloženo vaše bohatství ve formě souborů objednávek, smluv a tak dále. Pro mě to bude jako příklad C:\access\. Složka musí být vytvořena na oddílu NTFS.

Přístup k síti.

Na tuto fázi potřebovat zpřístupnit přes síť(sdílet - sdílet) složku pro ostatní uživatele, aby s ní mohli pracovat na svých počítačích tohoto lokální síť.

A to nejdůležitější! Sdílejte složku s plným oprávněním pro všechny! Ano ano! Slyšel jsi dobře. Ale co kontrola přístupu?

Umožňujeme každému připojit se ke složce přes lokální síť, ALE omezíme přístup pomocí zabezpečení uloženého v souboru systém NTFS kde se nachází náš adresář.

• MS Windows XP. Na požadovanou složku(C:\dostup\) klikněte pravým tlačítkem a tam Vlastnosti. Přístupová karta - Plný přístup.
• MS Windows 7. Na požadovanou složku (C:\dostup\) klikněte pravým tlačítkem myši a tam Vlastnosti. Záložka Přístup – Pokročilá nastavení. Dejte klíště Sdílej tuto složku. Vyplňte poznámku. Stiskneme Povolení. Skupina Everyone musí mít síťová práva Plný přístup.

Uživatelé a skupiny zabezpečení.

Musíte vytvořit potřebné uživatelské účty. Připomínám, že pokud na vaší četné osobní počítače se používají různé uživatelské účty, musí být všechny vytvořeny na vašem "serveru" a se stejnými hesly. Tomu se lze vyhnout pouze v případě, že máte kompetentního správce a počítače v Active Directory. Ne? Poté si pečlivě vytvořte účty.

• MS Windows XP.
  Místní uživatelé a skupiny – uživatelé. Nabídka Akce - Nový uživatel.
• MS Windows 7. Ovládací panely - Nástroje pro správu - Správa počítače.
  Místní uživatelé a skupiny – uživatelé. Nabídka Akce - Vytvořit uživatele.

Teď je řada na tom nejdůležitějším – na skupinách! Skupiny umožňují zahrnout uživatelské účty a zjednodušit manipulaci s udělováním práv a řízením přístupu.

O něco později bude vysvětleno "udělování práv" na adresáře a soubory, ale prozatím je hlavní pochopit jednu myšlenku. Práva ke složkám nebo souborům budou udělena skupinám, které lze obrazně přirovnat ke kontejnerům. A skupiny již „převedou“ práva k účtům v nich obsaženým. To znamená, že musíte přemýšlet na úrovni skupin, a ne na úrovni jednotlivých účtů.

• MS Windows XP. Ovládací panely - Nástroje pro správu - Správa počítače.
  
• MS Windows 7. Ovládací panely - Nástroje pro správu - Správa počítače.
  Místní uživatelé a skupiny - Skupiny. Nabídka Akce - Vytvořit skupinu.

Musí být zahrnuto v požadované skupiny požadované účty. Například ve skupině Účetní klikněte pravým tlačítkem a tam Přidat do skupiny nebo Vlastnosti a tam tlačítko Přidat. V terénu Zadejte názvy objektů, které chcete vybrat zadejte název požadovaného účtu a klikněte Zkontrolujte jména. Pokud je vše v pořádku, pak se účet změní na tvar JMÉNO SERVERU\účet. Na obrázku výše byl účet buh3 přetypován na WINSERVER\buh3.

Jsou tedy vytvořeny potřebné skupiny a uživatelské účty jsou zahrnuty do potřebných skupin. Ale před fází přidělování práv složkám a souborům pomocí skupin bych rád probral několik bodů.

Má cenu se trápit se skupinou, když bude mít jeden účet? Myslím, že to stojí za to! Skupina poskytuje flexibilitu a manévrovatelnost. Zítra budete muset dát jiné osobě B stejná práva jako určitá osoba s jeho účtem A. Stačí přidat účet B do skupiny, kde A již existuje a je to!

Mnohem snazší, když jsou oprávnění udělena spíše skupinám než jednotlivcům. Musíte pouze manipulovat se skupinami a zahrnout do nich potřebné účty.

Přístupová práva.

Následující akce je vhodné provádět z vestavěného účtu Administrator nebo z prvního účtu v systému, který je standardně zařazen do skupiny Administrators.

Dostali jsme se tedy do fáze, kdy se kouzlo vymezování přístupových práv pro různé skupiny odehrává přímo a jejich prostřednictvím k uživatelům (přesněji k jejich účtům).

Máme tedy adresář na C:\dostup\, který jsme již zpřístupnili všem zaměstnancům po síti. Uvnitř adresáře C:\dostup\ si pro příklad vytvoříme složky Smlouvy, Objednávky, Účetnictví pro MC. Předpokládejme, že existuje úkol:

• složka Smlouvy musí být pro účetní pouze ke čtení. Číst a psát pro skupinu manažerů.
• složka Accounting Center musí být k dispozici, aby ji účetní mohli číst a zapisovat. Skupina Manažeři nemá přístup.
• složka Objednávky by měla být pouze pro čtení pro účetní a manažery.

Ve složce Dohoda klikněte pravým tlačítkem myši a tam Vlastnosti - záložka Zabezpečení. Vidíme, že některé skupiny a uživatelé k němu již mají přístup. Tato práva byla zděděna od nadřazeného dostup\, který zase byl zděděn od svého nadřízeného C:

Přerušíme toto dědění práv a postoupíme naše práva na Wishlist.

Klepněte na tlačítko Upřesnit - karta Oprávnění - tlačítko Změnit oprávnění.

Nejprve přerušíme dědění práv po rodiči. Zrušte zaškrtnutí Přidejte oprávnění zděděná od nadřazených objektů. Budeme upozorněni, že se na něj nebudou vztahovat rodičovská oprávnění tento objekt(PROTI tento případ toto je složka smlouvy). Volba: Zrušit nebo Odebrat nebo Přidat. Klikněte na Přidat a práva od rodiče zůstanou naším dědictvím, ale rodičovská práva se na nás již nebudou vztahovat. Jinými slovy, pokud se v budoucnu změní přístupová práva nadřazené složky (složka dostup), nebude to mít vliv na podřízenou složku Smlouvy. Upozornění v terénu Zděděno od náklady nedědil. To je to spojení rodič – dítě roztržený.

Nyní opatrně odstraníme nadbytečná práva a odejdeme Plný přístup pro administrátory a systém. Vezměme si postupně každého Ověřeno A prostě Uživatelé a smažte jej tlačítkem Smazat.

Přidat tlačítko v tomto okně Extra možnosti bezpečnostní je určen pro zkušené administrátory, kteří budou schopni nastavit speciální, speciální oprávnění. Článek je zaměřen na znalosti zkušeného uživatele.

Zaškrtneme políčko Nahraďte všechna oprávnění podřízeného objektu oprávněními zděděnými od tohoto objektu a klepněte na OK. Vracíme se a znovu Ok, abychom se vrátili prostý pohled Vlastnosti.

Toto okno vám usnadní dosažení toho, co chcete. Tlačítko Upravit vyvolá okno „Oprávnění skupiny“.

Klepněte na tlačítko Přidat. V novém okně napište Účetní a klikněte na "Zkontrolovat jména" - OK. Standardně je přístup "čtení" poskytnut ve zjednodušené formě. Zaškrtávací políčka ve sloupci Povolit jsou automaticky nastavena na "Číst a provádět", "Zobrazit obsah složky", "Číst". Jsme s tím spokojeni a klikneme na OK.

Nyní, v souladu s našimi podmínkami, musíme udělit oprávnění ke čtení a zápisu pro skupinu Managers. Pokud jsme v okně Vlastnosti, tak opět Změnit - Přidat - jednotka ve Správcích - Kontrola jmen. Přidejte zaškrtávací políčka Upravit a Zápis ve sloupci Povolit.

Nyní musíme vše zkontrolovat!

Následujte myšlenku. Nařídili jsme, aby složka smlouvy nedědila po svém rodiči dostup. Objednané podřízené složky a soubory ve složce Dohoda, aby z ní zdědily práva.

Na složku Dohody jsme uvalili následující přístupová práva: skupina Účetní by měla pouze číst soubory a otevírat složky uvnitř a skupina Manažeři by měla vytvářet, upravovat soubory a vytvářet složky.

Pokud je tedy soubor dokumentu vytvořen v adresáři smlouvy, bude mít oprávnění od svého rodiče. Uživatelé s vlastními účty budou k těmto souborům a adresářům přistupovat prostřednictvím svých skupin.

Přejděte do složky Smlouvy a vytvořte testovací soubor contract1.txt

Klikněte na něj pravým tlačítkem a tam Vlastnosti - karta Zabezpečení - Upřesnit - karta Platná oprávnění.

Klikněte na Vybrat a napište účet libovolného účetního, například buh1. Jasně vidíme, že buh1 dostal oprávnění od své skupiny Účetní, kteří mají oprávnění ke čtení nadřazené složky Smlouvy, která „propaguje“ svá oprávnění na své podřízené objekty.

Vyzkoušíme manager2 a jasně vidíme, že manažer má přístup pro čtení a zápis, protože je zahrnut ve skupině Manažeři, která dává tato práva pro tuto složku.

Úplně stejným způsobem, analogicky se složkou Dohoda, jsou přístupová práva uložena pro další složky podle vašich zadání.

Výsledek.

• Použijte oddíly NTFS.
• Při vymezování přístupu ke složkám (a souborům) pak manipulujte se skupinami.
• Vytvořte účty pro každého uživatele. 1 osoba = 1 účet.
• Přidejte účty do skupin. Účet může být členem různých skupin současně. Pokud je účet ve více než jedné skupině a kterákoli skupina něco povoluje, bude tento účet povolen.
• Sloupec Odepřít (zákaz práv) má přednost před Povolit. Pokud je účet ve více skupinách a jedna skupina něco zakáže a jiná to povolí, účet bude zablokován.
• Odeberte účet ze skupiny, pokud chcete zrušit přístup, který tato skupina poskytuje.
• Přemýšlejte o najmutí admina a neurážejte ho penězi.

Ptejte se v komentářích a ptejte se, opravte.

Záběry ukazují speciální případ, kdy potřebujete pouze zakázat přístup ke složce s využitím skutečnosti, že pravidla odepření mají přednost před povolovacími pravidly.

Řízení přístupu.

Automatizovaný systém, v závislosti na jeho složitosti a prováděných úkolech, může být umístěn v jedné, dvou, třech atd. místnostech, patrech, budovách. Vzhledem k rozdílu ve funkčních povinnostech a práci s různé dokumenty je nutné zajistit diferenciaci přístupu uživatelů k jejich pracovištím, vybavení a informacím. To je zajištěno umístěním uživatelských pracovišť do samostatných místností, uzavřených různými druhy zámků vstupní dveře s nainstalovanými senzory EZS nebo použitím speciálních automatický systémřízení vstupu do areálu pomocí žetonů nebo karet s individuálním kódem jeho majitele, zaznamenaným v jeho paměti.

Kontrola přístupu v automatizovaný systém spočívá v rozdělení informací, které v něm kolují, na části a v organizaci přístupu úředníků k nim v souladu s jejich funkčními povinnostmi a pravomocemi. Úkolem takové diferenciace přístupu k informacím je snížit počet úředníků, kteří s nimi nejsou při výkonu funkce spřízněni, tzn. ochrana informací před narušitelem z řad legitimních uživatelů.

Hlavním úkolem řízení a diferenciace přístupu (CCRD) je blokování neoprávněného, ​​kontrola a rozlišování oprávněného přístupu k informacím, které mají být chráněny. Zároveň by mělo být vymezení přístupu k informacím a softwaru pro jejich zpracování provedeno v souladu s funkčními povinnostmi a pravomocemi úředníků uživatelů, pracovníků údržby a vedoucích práce.

Základním principem konstrukce SCRD je, že jsou povoleny a prováděny pouze takové přístupy k informacím, které obsahují příslušné znaky povolených pravomocí. Pro tyto účely se provádí identifikace a autentizace uživatelů, zařízení apod., dělení informací a funkce jejich zpracování v souladu se stanovenými požadavky na řízení přístupu, instalace a zadávání uživatelských práv.

Rozdělení informací a funkce jejich zpracování se obvykle provádí podle následujících kritérií:

V pořadí podle důležitosti;

Podle stupně utajení;

Funkcemi prováděnými uživateli, zařízeními;

Podle názvu dokumentů;

Podle typů dokumentů;

Podle typu dat;

Podle názvů svazků, souborů, polí, záznamů;

Podle uživatelského jména;

Funkcemi zpracování informací: čtení, zápis, provádění;

Podle denní doby.

Vzhledem k tomu, že přístup je prováděn z různých technických prostředků, je možné zahájit delimitaci vymezením přístupu k technické prostředky jejich umístěním do samostatných místností. Všechny přípravné funkce pro údržbu zařízení, opravy, prevenci, restart software a další by měly být technicky a organizačně odděleny od hlavních úkolů systému. Komplex automatizačních nástrojů a organizace jeho údržby by měly být postaveny takto:

Údržbu IS za provozu by měl provádět speciální technický personál bez přístupu k chráněným informacím;

Funkce zabezpečení informací by měla provádět speciální jednotka v organizaci, která vlastní IP, počítačová síť nebo ACS;

Organizace uživatelského přístupu do paměti IS by měla poskytovat možnost rozlišit přístup k informacím v ní uloženým s dostatečnou mírou podrobnosti a v souladu se stanovenými úrovněmi oprávnění uživatele;

Evidence a dokumentace technologických a provozní informace by měly být odděleny.

Jako osobní identifikátory pro implementaci diferenciace je rozšířené používání kódů hesel, které jsou uloženy v paměti uživatele a IS. Abychom pomohli uživateli v systémech se zvýšenými požadavky, velké hodnoty kódů hesel se zaznamenávají na speciální média - elektronické klíče, tokeny, čipové karty atd.

Zásadní možnost rozlišování mezi zadané parametry by měl zajistit projekt IS. A konkrétní rozlišení v provozu IS stanoví spotřebitel a do systému jej zanese jeho útvar odpovědný za informační bezpečnost.

Pro tyto účely se při návrhu výpočetních nástrojů pro budování IS provádí:

Rozvoj operační systém se schopností implementovat řízení přístupu k informacím uloženým v paměti počítače, PC, serveru;

Izolace přístupových oblastí;

Rozdělení databáze do skupin;

Řídicí postupy pro uvedené funkce.

Vývoj a realizace funkčních úkolů pro vymezení a řízení přístupu k zařízení a informacím jak v rámci tohoto IS, tak i ACS (sítě) jako celku;

Vývoj hardwarových prostředků pro identifikaci a autentizaci uživatelů;

Rozvoj softwarové nástroje kontrola a řízení kontroly přístupu;

Vypracování samostatné provozní dokumentace pro prostředky identifikace, autentizace, diferenciace a řízení přístupu.

Volba konkrétních znaků řízení přístupu a jejich kombinací se provádí v souladu s podmínky zadání při navrhování softwaru pro automatizovaný systém.

Informace, které mají být chráněny, musí být umístěny v nepřekrývajících se oblastech paměti. Každá z těchto oblastí obsahuje sbírku informační objekty, z nichž každá podléhá ochraně. Ochrana v tomto případě spočívá ve skutečnosti, že přístup k informační objekt jediným bezpečným vchodem. Funkce "ochrany" zahrnuje identifikaci uživatele jménem (nebo podmíněným číslem) a kódem předloženého hesla. Pokud je výsledek kontroly kladný, je mu umožněn přístup k informacím v souladu s pravomocemi, které mu byly přiděleny. Tyto procedury se provádějí pokaždé, když uživatel přistupuje: požadavek, vydávání příkazů atd. Abyste heslo nezadávali pokaždé, je vhodné si předložené heslo uložit na speciální fyzická média(klíč, mapa), která je před vchodem do výpočetní systém musí být uživatelem vložen do speciální zásuvky AWP. Navíc, jakmile je nosič hesla odstraněn ze slotu, přihlášení je okamžitě zablokováno.

Pokud požadavky na informační bezpečnost pro konkrétní systém umožňují použití ručního zadání hesla, je nutné se ujistit, že heslo prezentované při opakovaných přístupech v procesu práce s informacemi je v paměti této pracovní stanice. Ukládání v centrálním počítači je povoleno pouze v případě, že je propojeno s podmíněným číslem této pracovní stanice, tzn. všechna následující volání v centrálním počítači by měla být přijata ke zpracování pouze s podmíněným číslem pracovní stanice, ze které byl předložen uložený kód hesla. Na konci práce vyloučit možnost neoprávněného přístupu ze strany externí uživatelé z pracovní stanice je nutné zadat příslušný příkaz, kterým se dříve předložené a uložené heslo vymaže. Na pracovní stanici uživatele by se měla zobrazit zpráva o faktu smazání. Pro kontrolu poslední operace je vhodné zopakovat jeden z předchozích přístupů bez hesla a ověřit to negativní reakcí počítačového systému.

EndProcedure

EndIf;

Funkce WiredAuthority (vpravo)

Žádost = Nová žádost;

Query.Text = "VYBRAT

| ValuesAdditionalRightValue

Selection.Next();

Návrat Selection.Value;

vrátit false;

EndIf;

EndFunctions

Postup OnOpen()

EndProcedure

K dnešnímu dni, na ruský trh vede automatizace účetnictví aplikovaná řešení vyvinutý na základě platformy vyvinuté ruskou společností "1C". Podle sociologických studií zveřejněných na internetu v Rusku a zemích SNS používá 90 % organizací tyto systémy k automatizaci účetnictví. Tyto systémy také nemají obdoby pro plnou automatizaci účetnictví podle RAS. Od účetnictví a daňové hlášení, zpracovávány a ukládány v takových systémech je důvěrná informace jakákoli organizace, pak musí být tyto informace chráněny na správné úrovni. Kromě účetnictví bylo prostřednictvím těchto systémů automatizováno mnoho oblastí účetnictví (například personální účetnictví a mzdy, provozní a manažerské účetnictví, účetnictví vztahů se zákazníky atd.).

V této práci chci popsat způsoby a prostředky ochrany informací v databázích vybudovaných na bázi systémů 1C Enterprise.

V v současné době Aktivně se používají 3 verze 1C, konkrétně verze 7.7, 8.1 a 8.2. Verze 7.7 je již zastaralá a zastaralá a nevidím žádný praktický důvod považovat tento systém za příklad. Protože se verze 8.2 začala oficiálně prodávat poměrně nedávno, rozhodl jsem se pro verzi „1C Enterprise 8.1“. Jako příklad dříve vyvinutý vzdělávací systém k automatizaci úkolů provozní a účetní a mzdové agendy.

Protože systém funguje v lokální síti organizace, nebo na místní počítač, pak ochrana tohoto systému před možnými vnějšími útoky spočívá na správci sítě. V tomto příkladu popíšu především mechanismus omezení přístupu k informacím konkrétních zaměstnanců organizace.

Tento systém umožňuje nákup zboží na sklad a jeho prodej, přičemž je možné kupujícímu poskytnout některé služby. Při provádění nákupních a prodejních transakcí systém automaticky shromažďuje údaje o účetním a provozním účetnictví. Také pro realizaci účetních úkonů je možné zadávat ruční operace, tzn. zadávání korespondence účtů s uvedením potřebných rozměrů, množství a částek na odpovídajících účtech. Pro úlohu výpočtu mezd je v systému implementována možnost zadávání mezd, bonusů, cestovních náhrad a absencí.

Pro přístup k objektům musíte nastavit následující práva:

Vytvořit administrátorská práva pro plný přístup na všechna data.

Pro vedoucího organizace udělte práva k sestavám a práva k prohlížení všech dokumentů.

Poskytnout účetním zaměstnancům právo přístupu k účetním dokladům a výkazům.

Pro zaměstnance provozního oddělení udělte práva na vytváření příchozích a odchozích dokumentů, přičemž každý zaměstnanec může vytvářet a prohlížet dokumenty pouze pro protistranu, ke které je jako odpovědný.

Pro zaměstnance personálního oddělení otevřít přístup pouze k objektům nezbytným pro mzdovou agendu.

Všem zaměstnancům kromě vedení zakázat tisk nezaúčtovaných dokumentů.

Všem uživatelům nastavte příslušná práva a uveďte identifikaci pomocí hesla nebo operačního systému.

Řízení přístupu prostřednictvím rolí.

Mechanismus rolí umožňuje nastavit práva pro čtení, prohlížení, změnu, mazání, držení atd. pro každý konfigurační objekt. Konfigurační objekty jsou adresáře (úložiště informace o pozadí, například nomenklatura, protistrany atd.), dokumenty (navržené tak, aby odrážely obchodní transakce, například faktura, mzdy atd.) a registry, které shromažďují jakékoli informace. Obrázek 1 ukazuje část hlavních objektů uvažovaných v tomto příkladu.

Obrázek 1. Hlavní konfigurační objekty.

V systému můžete vytvořit neomezený počet rolí, v každé roli můžete nastavit práva pro jeden objekt a každému uživateli můžete nastavit několik rolí. Při přiřazení více rolí jednomu uživateli jsou jeho práva nastavena na základě následujícího pravidla: Akce je dostupná, pokud je povolena alespoň v jedné roli, a akce není dostupná, pokud je zakázána ve všech rolích. Tu či onu roli můžete udělit pouze vizuálně a pouze ve fázi konfigurace. Za běhu nelze měnit role.

Obrázek 2 poskytuje příklad založení plná práva pro správce systému.

Obrázek 2. Nastavení všech práv pro roli.

Pro ostatní uživatele je třeba nainstalovat potřebná práva, to je znázorněno na obrázku 3.

Obrázek 3. Příklad nastavení práv pro konkrétního uživatele.

Vymezení práv na úrovni záznamu.

Pro odlišení přístupu k záznamům v tabulkách je nutný mechanismus diferenciace práv na úrovni záznamů informační základna, podle určitých kritérií. Například přístup pouze k těm záznamům v adresáři protistran, za které odpovídá aktuální uživatel. Na obrázku 4 je například zobrazen text programu, který omezuje přístup uživatele k evidenci seznamu dokladů došlé faktury.

Obrázek 4. Příklad řízení přístupu na úrovni záznamu.

Uživatel je identifikován pomocí parametru relace „Aktuální interpret“, informace o uživatelích jsou uloženy v adresáři „Zaměstnanci“. Parametr relace "Aktuální exekutor" je nastaven, když se program spustí s následujícím textem programu:

Postup spuštění systému()

SessionParameters.CurrentExecutor= Directories.Employees.FindByCode(Username());

EndProcedure

Řízení přístupu softwarové metody.

Kromě mechanismu rolí může program konfigurovat přístup k datům zápisem procedur a funkcí v jazyce zabudovaném do 1C Enterprise. Příkladem je schopnost systému otevřít formulář ( vizuální prvek se kterým uživatel pracuje) je možné pouze prohlížet, pokud jsou splněny určité podmínky, například:

Pokud SessionParameters.CurrentUser =

Directories.Employees.FindBy Name(“Ivanov”) Pak

ThisForm.ViewOnly = True;

EndIf;

Více složitý příklad slouží jako mechanismus, který umožňuje v režimu provádění programu udělit uživateli potřebná práva, například povolení nebo zákaz tisku nezaúčtovaných dokumentů. Pro implementaci tohoto úkolu byl vytvořen výčet, který ukládá seznam dalších práv a tabulka (Registr informací), která ukládá hodnoty dalších práv. Ve společném modulu byl vytvořen následující postup, který získává hodnotu práva pro aktuálního uživatele:

Funkce WiredAuthority (vpravo)

Žádost = Nová žádost;

Query.Text = "VYBRAT

| ValuesAdditionalRightValue

| RegisterInformation.ValuesAdditionalPermissions AS ValuesAdditionalPermissions

| ValuesAdditionalRight.Employee = &Zaměstnanec

| And ValuesAdditionalRight.Right = &Right";

Query.SetParameter("Zaměstnanec",

SessionParameters.CurrentExecutor);

Request.SetParameter("Right", Right);

Výsledek = Request.Run();

If Not Result.Empty() Then

Selection = Result.Select();

Selection.Next();

Návrat Selection.Value;

vrátit false;

EndIf;

EndFunctions

Na formuláři dokladu Faktura je tlačítko "Tisk" odpovědné za vytvoření tištěného formuláře tento dokument. Při otevření tohoto dokumentu pomocí následujícího textu programu nastavíme dostupnost tohoto tlačítka pro uživatele:

Postup OnOpen()

ElementsForm.BasicActionsForms.Buttons.Print.

Dostupnost = ProvAccessRights (Výčty.

Dodatečná práva.Tisk nezveřejněných dokumentů);

EndProcedure

Přidělování rolí a prostředků identifikace uživatelů.

Uživatelé, kteří mohou s programem pracovat, jsou vytvořeni v režimu konfigurace úlohy, nebo může být uživatel vytvořen programově. Obrázek 5 ukazuje příklad vytvoření uživatele a přiřazení příslušných práv k němu.

Obrázek 5. Seznam uživatelů, rolí a prostředků identifikace.

V této práci byl uvažován celkem jednoduchý příklad účetní úlohy a jednoduchý příklad nastavení uživatelských práv v této úloze. Ale uvedený příklad umožňuje vizuálně ilustrovat možnosti systému z hlediska oddělení práv, což je v mnoha organizacích velmi důležité, a poskytuje každému zaměstnanci přístup pouze k těm informacím, které potřebuje.

Dodatek obsahuje snímky obrazovky programu za běhu, které ilustrují provedená nastavení.

Gabets A.P., Goncharov D.I. 1C:Podnik 8.1. Jednoduché příklady rozvoj. - M .: LLC "1C-Publishing"; Petrohrad: Piter, 2008. - 383 s.: ill. + CD-ROM.

1C:Podnik 8.2. Příručka pro vývojáře. Část 1. - M .: CJSC "1C", 2009 - 638 s.: ill.

Radčenko M.G. 1C:Podnik 8.1. Praktický průvodce vývojář. Příklady a typické techniky. M.: 1C-Publishing LLC, 2008. 874 s.: ill.

Belousov P.S. Metodické materiály školícího kurzu "Konfigurace platformy" 1C:Enterprise 8.1 ". - M .: CJSC "1C", 2007 - 272 s.: nemoc.

Příklad neoprávněného pokusu o přihlášení.

Příklad řízení přístupu omezením prostřednictvím rolí, obrázek ukazuje pokus o otevření adresáře, pro který uživatel nemá práva ke čtení.

Příklad vymezování práv na úrovni záznamu.

Příklad implementace softwaru nepřístupnost tlačítka "Tisk" v dokumentu "Faktura".

Po provedení identifikace a autentizace je nutné zřídit oprávnění (soubor práv) subjektu pro následnou kontrolu oprávněného použití výpočetních prostředků dostupných v AS. Takový proces se nazývá diferenciace (logické řízení) přístupu.

Oprávnění subjektu je obvykle reprezentováno: seznamem zdrojů dostupných uživateli a právy pro přístup ke každému zdroji ze seznamu. Výpočetní zdroje mohou být programy, informace, logická zařízení, velikost paměti, čas procesoru, priorita atd.

Obvykle se rozlišují následující metody řízení přístupu:

Rozlišení přístupu podle seznamů;

Použití autorizační matrice;

Řízení přístupu heslem.

Při vymezování přístupu seznamy jsou nastaveny následující korespondence:

Každý uživatel – seznam zdrojů a přístupová práva k nim popř

Každý zdroj má seznam uživatelů a jejich přístupová práva k tomuto zdroji.

Seznamy umožňují nastavit oprávnění až na uživatele. Zde je snadné přidat oprávnění nebo explicitně zakázat přístup. Seznamy se používají ve většině operačních systémů a DBMS.

Použití matice oprávnění předpokládá použití matice přístupu (tabulky oprávnění). V zadané matici (viz tabulka 2.7) jsou řádky identifikátory subjektů s přístupem do AS a sloupce jsou objekty (informační zdroje) AS. Každý prvek matice může obsahovat název a velikost poskytovaného zdroje, přístupová práva (čtení, zápis atd.), odkaz na jiný informační struktura, určení přístupových práv, odkaz na program, který řídí přístupová práva atp.

Tabulka 2.7

Fragment autorizační matrice

c - vytvořit, d - odstranit, r - přečíst, w - zapsat, e - provést.

Tato metoda poskytuje jednotnější a pohodlnější přístup, protože všechny informace o oprávněních jsou uloženy v jediné tabulce a nikoli ve formě heterogenních seznamů. Nevýhodou matice je její možná těžkopádnost a ne zcela optimální využití zdrojů (většina buněk je prázdná).

Rozlišení přístupu podle úrovní utajení a kategorií spočívá v tom, že prostředky AS jsou rozděleny podle úrovní nebo kategorií utajení.

Při rozlišení podle stupně utajení se rozlišuje několik stupňů, například: obecný přístup, důvěrné, tajné, přísně tajné. Oprávnění každého uživatele jsou nastavena v souladu s maximální úrovní soukromí, do které je povolen. Uživatel má přístup ke všem údajům, které mají stupeň (laťku) utajení ne vyšší než on.

Při kategorizaci se nastavuje a řídí pořadí kategorie odpovídající uživateli. V souladu s tím jsou všechny prostředky AS rozloženy podle úrovně důležitosti a určité úrovni odpovídá určitá úroveň personálu (jako například: manažer, správce, uživatel).

Rozlišení hesel samozřejmě představuje použití metod pro přístup subjektů k objektům pomocí hesla. Používají se všechny metody ochrana heslem. Je zřejmé, že neustálé používání hesel vytváří nepříjemnosti pro uživatele a časové prodlevy. Proto se tyto metody používají ve výjimečných situacích.

V praxi se většinou kombinují různé metodyŘízení přístupu. Například první tři metody zlepšují ochranu heslem.

Na konci pododdílu poznamenáváme, že řídící dokumenty mohou regulovat dva typy (principy) řízení přístupu:

Diskrétní kontrola přístupu;

Povinná kontrola přístupu.

Diskrétní řízení přístupu je omezení přístupu mezi pojmenovanými subjekty a pojmenovanými objekty. Subjekt s konkrétním přístupovým právem může toto právo převést na jakýkoli jiný subjekt. Tento pohled je organizován na základě metod vymezování seznamy nebo pomocí matice.

Povinná kontrola přístupu upravuje rozlišování přístupu subjektů k objektům na základě informací obsažených v objektech, vyznačujících se označením důvěrnosti, a úředního povolení (připuštění) subjektů k přístupu k informacím tohoto stupně utajení. Jinak, pro implementaci povinného řízení přístupu, je každému subjektu a každému objektu přiřazen klasifikační štítek odrážející jejich místo v odpovídající hierarchii. Pomocí těchto štítků musí být předmětům a objektům přiřazeny stupně utajení, což jsou kombinace hierarchického stupně utajení a hierarchických kategorií. Tyto štítky by měly sloužit jako základ pro nařízený princip řízení přístupu. Je zřejmé, že metody úrovně utajení a řízení přístupu ke kategoriím jsou příklady povinného řízení přístupu.