ჩვენ ვაშენებთ როლებზე დაფუძნებულ წვდომის კონტროლის მოდელს. ნაწილი პირველი, მოსამზადებელი

ამჟამად ვმუშაობ პროგრამული უზრუნველყოფის გამყიდველში, კონკრეტულად წვდომის კონტროლის გადაწყვეტილებებზე. და ჩემი გამოცდილება "წარსული ცხოვრებიდან" დაკავშირებულია მომხმარებლის მხარესთან - დიდ ფინანსურ ორგანიზაციასთან. მაშინ ინფორმაციული უსაფრთხოების დეპარტამენტში ჩვენი წვდომის კონტროლის ჯგუფი IdM-ში დიდი კომპეტენციებით ვერ დაიკვეხნიდა. ჩვენ ბევრი რამ ვისწავლეთ ამ პროცესში, ჩვენ მოგვიწია ბევრი მუწუკის დარტყმა იმისათვის, რომ აგვეშენებინა სამუშაო მექანიზმი მომხმარებლის უფლებების მართვის საინფორმაციო სისტემებში კომპანიაში.

ჩემი ძნელად მიღებული მომხმარებლის გამოცდილება გამყიდველის ცოდნასთან და კომპეტენციებთან ერთად, მინდა გაგიზიაროთ არსებითად ნაბიჯ-ნაბიჯ ინსტრუქციები: როგორ შევქმნათ როლებზე დაფუძნებული წვდომის კონტროლის მოდელი დიდ კომპანიაში და რას მისცემს ეს შედეგად . ჩემი ინსტრუქციები შედგება ორი ნაწილისგან: პირველი ემზადება მოდელის ასაგებად, მეორე რეალურად აშენებს. აქ არის პირველი ნაწილი, მოსამზადებელი ნაწილი.

NB მისაბაძი მოდელის შექმნა, სამწუხაროდ, შედეგი კი არა, პროცესია. უფრო სწორად, კომპანიაში დაშვების კონტროლის ეკოსისტემის შექმნის პროცესის ნაწილიც კი. ასე რომ, მოემზადეთ თამაშისთვის დიდი ხნით.

ჯერ განვსაზღვროთ - რა არის როლებზე დაფუძნებული წვდომის კონტროლი? დავუშვათ, რომ თქვენ გაქვთ დიდი ბანკი ათობით, ან თუნდაც ასობით ათასი თანამშრომლით (ობიექტებით), რომელთაგან თითოეულს აქვს ათობით წვდომის უფლება ასობით შიდა ბანკის საინფორმაციო სისტემაზე (ობიექტზე). ახლა გაამრავლეთ ობიექტების რაოდენობა საგნების რაოდენობაზე - ეს არის კავშირების მინიმალური რაოდენობა, რომელიც ჯერ უნდა შექმნათ და შემდეგ გააკონტროლოთ. მართლა შესაძლებელია ამის ხელით გაკეთება? რა თქმა უნდა არა - ამ პრობლემის გადასაჭრელად შეიქმნა როლები.

როლი არის ნებართვების ნაკრები, რომელიც მომხმარებელს ან მომხმარებელთა ჯგუფს სჭირდება გარკვეული სამუშაო ამოცანების შესასრულებლად. თითოეულ თანამშრომელს შეიძლება ჰქონდეს ერთი ან მეტი როლი და თითოეული როლი შეიძლება შეიცავდეს ერთიდან ბევრ ნებართვას, რომელიც დაშვებულია მომხმარებლისთვის ამ როლის ფარგლებში. როლები შეიძლება იყოს მიბმული თანამშრომლების კონკრეტულ თანამდებობებზე, განყოფილებებზე ან ფუნქციურ ამოცანებზე.

როლები, როგორც წესი, იქმნება თითოეული საინფორმაციო სისტემაში ინდივიდუალური თანამშრომლის ავტორიზაციის საფუძველზე. შემდეგ გლობალური ბიზნეს როლები ყალიბდება თითოეული სისტემის როლებიდან. მაგალითად, ბიზნეს როლი „საკრედიტო მენეჯერი“ მოიცავს რამდენიმე ცალკეულ როლს საინფორმაციო სისტემებში, რომლებიც გამოიყენება ბანკის კლიენტთა ოფისში. მაგალითად, ისეთებში, როგორიცაა ძირითადი ავტომატიზირებული საბანკო სისტემა, ნაღდი ფულის მოდული, ელექტრონული დოკუმენტების მართვის სისტემა, სერვის მენეჯერი და სხვა. ბიზნეს როლები, როგორც წესი, დაკავშირებულია ორგანიზაციულ სტრუქტურასთან - სხვა სიტყვებით რომ ვთქვათ, კომპანიის განყოფილებებისა და მათში პოზიციების სიმრავლესთან. ასე იქმნება გლობალური როლების მატრიცა (მაგალითს ვაძლევ ქვემოთ მოცემულ ცხრილში).

აღსანიშნავია, რომ უბრალოდ შეუძლებელია 100% მისაბაძი მოდელის შექმნა, კომერციულ სტრუქტურაში თითოეული თანამდებობის თანამშრომლებისთვის ყველა საჭირო უფლების უზრუნველყოფით. დიახ, ეს არ არის საჭირო. მისაბაძი მაგალითი ხომ არ შეიძლება იყოს სტატიკური, რადგან ის მუდმივად ცვალებად გარემოზეა დამოკიდებული. და კომპანიის ბიზნეს საქმიანობის ცვლილებებიდან, რაც, შესაბამისად, გავლენას ახდენს ორგანიზაციულ სტრუქტურასა და ფუნქციონალურ ცვლილებებზე. და რესურსების სრული უზრუნველსაყოფად და სამუშაოს აღწერილობების შეუსრულებლობისგან და უსაფრთხოების ხარჯზე მოგების სურვილიდან და მრავალი სხვა ფაქტორიდან. აქედან გამომდინარე, აუცილებელია მისაბაძი მოდელის შექმნა, რომელსაც შეუძლია დაფაროს მომხმარებლის საჭიროებების 80%-მდე საჭირო ძირითადი უფლებები თანამდებობაზე მინიჭებისას. და მათ შეუძლიათ, საჭიროების შემთხვევაში, მოითხოვონ დარჩენილი 20% მოგვიანებით ცალკეულ განაცხადებზე.

რა თქმა უნდა, შეიძლება იკითხოთ: „არ არსებობს 100% მისაბაძი მაგალითი? აბა, რატომ, ასე ხდება, მაგალითად, არაკომერციულ სტრუქტურებში, რომლებიც არ ექვემდებარება ხშირ ცვლილებებს - ზოგიერთ კვლევით ინსტიტუტში. ან უსაფრთხოების მაღალი დონის მქონე სამხედრო-სამრეწველო კომპლექსის ორგანიზაციებში, სადაც უსაფრთხოება პირველ ადგილზეა. ეს ხდება კომერციულ სტრუქტურაში, მაგრამ ცალკე განყოფილების ფარგლებში, რომლის მუშაობა საკმაოდ სტატიკური და პროგნოზირებადი პროცესია.

როლებზე დაფუძნებული მენეჯმენტის მთავარი უპირატესობა არის უფლებების გაცემის გამარტივება, რადგან როლების რაოდენობა საგრძნობლად ნაკლებია, ვიდრე საინფორმაციო სისტემის მომხმარებელთა რაოდენობა. და ეს მართალია ნებისმიერი ინდუსტრიისთვის.

ავიღოთ საცალო კომპანია: მასში დასაქმებულია ათასობით გამყიდველი, მაგრამ მათ აქვთ იგივე უფლებები სისტემა N-ში და მათთვის მხოლოდ ერთი როლი შეიქმნება. როდესაც ახალი გამყიდველი მოდის კომპანიაში, მას ავტომატურად ენიჭება საჭირო როლი სისტემაში, რომელსაც უკვე აქვს ყველა საჭირო უფლებამოსილება. ასევე, ერთი დაწკაპუნებით შეგიძლიათ ერთდროულად შეცვალოთ უფლებები ათასობით გამყიდველისთვის, მაგალითად, დაამატოთ ანგარიშის გენერირების ახალი ვარიანტი. არ არის საჭირო ათასი ოპერაციის გაკეთება, თითოეულ ანგარიშზე ახალი უფლების მიბმა - უბრალოდ დაამატეთ ეს პარამეტრი როლს და ის ერთდროულად გამოჩნდება ყველა გამყიდველისთვის.

როლებზე დაფუძნებული მენეჯმენტის კიდევ ერთი უპირატესობა არის შეუთავსებელი ავტორიზაციის გაცემის აღმოფხვრა. ანუ, დასაქმებულს, რომელსაც აქვს გარკვეული როლი სისტემაში, არ შეიძლება ერთდროულად ჰქონდეს სხვა როლი, რომლის უფლებები არ უნდა იყოს შერწყმული პირველში არსებულ უფლებებთან. თვალსაჩინო მაგალითია ფინანსური ტრანზაქციის შეტანისა და კონტროლის ფუნქციების გაერთიანების აკრძალვა.

ყველას, ვისაც აინტერესებს, როგორ გაჩნდა როლებზე დაფუძნებული წვდომის კონტროლი, შეუძლია
ისტორიაში ჩაძირვა
თუ ისტორიას გადავხედავთ, IT საზოგადოება პირველად ფიქრობდა წვდომის კონტროლის მეთოდებზე ჯერ კიდევ XX საუკუნის 70-იან წლებში. მიუხედავად იმისა, რომ აპლიკაციები მაშინ საკმაოდ მარტივი იყო, ისევე როგორც ახლა, ყველას ნამდვილად სურდა მათზე წვდომის მოხერხებულად მართვა. მიანიჭეთ, შეცვალეთ და აკონტროლეთ მომხმარებლის უფლებები - მხოლოდ იმისთვის, რომ გაადვილდეთ იმის გაგება, თუ რა წვდომა აქვს თითოეულ მათგანს. მაგრამ იმ დროს არ არსებობდა საერთო სტანდარტები, მუშავდებოდა პირველი დაშვების კონტროლის სისტემები და თითოეული კომპანია ეფუძნებოდა საკუთარ იდეებსა და წესებს.

ახლა ცნობილია წვდომის კონტროლის მრავალი განსხვავებული მოდელი, მაგრამ ისინი მაშინვე არ გამოჩნდა. მოდით ვისაუბროთ მათზე, ვინც მნიშვნელოვანი წვლილი შეიტანა ამ სფეროს განვითარებაში.

პირველი და ალბათ უმარტივესი მოდელია დისკრეციული (შერჩევითი) წვდომის კონტროლი (DAC - დისკრეციული წვდომის კონტროლი). ეს მოდელი გულისხმობს უფლებების გაზიარებას წვდომის პროცესში ყველა მონაწილის მიერ. თითოეულ მომხმარებელს აქვს წვდომა კონკრეტულ ობიექტებზე ან ოპერაციებზე. არსებითად, აქ უფლებათა სუბიექტთა ერთობლიობა შეესაბამება ობიექტთა ერთობლიობას. აღმოჩნდა, რომ ეს მოდელი იყო ზედმეტად მოქნილი და ძალიან რთული შესანარჩუნებლად: წვდომის სიები საბოლოოდ ხდება უზარმაზარი და ძნელად კონტროლირებადი.

მეორე მოდელი არის სავალდებულო წვდომის კონტროლი (MAC - სავალდებულო წვდომის კონტროლი). ამ მოდელის მიხედვით, თითოეული მომხმარებელი იღებს წვდომას ობიექტზე მონაცემთა კონფიდენციალურობის კონკრეტულ დონეზე გაცემული წვდომის შესაბამისად. შესაბამისად, ობიექტები უნდა იყოს კლასიფიცირებული მათი კონფიდენციალურობის დონის მიხედვით. პირველი მოქნილი მოდელისგან განსხვავებით, ეს, პირიქით, ძალიან მკაცრი და შემზღუდველი აღმოჩნდა. მისი გამოყენება არ არის გამართლებული, როდესაც კომპანიას აქვს ბევრი განსხვავებული საინფორმაციო რესურსი: იმისათვის, რომ განასხვავოთ წვდომა სხვადასხვა რესურსებზე, მოგიწევთ მრავალი კატეგორიის დანერგვა, რომლებიც ერთმანეთს არ ემთხვევა.

ამ ორი მეთოდის აშკარა არასრულყოფილების გამო, IT საზოგადოებამ განაგრძო მოდელების შემუშავება, რომლებიც უფრო მოქნილი და ამავე დროს მეტ-ნაკლებად უნივერსალურია სხვადასხვა ტიპის ორგანიზაციული წვდომის კონტროლის პოლიტიკის მხარდასაჭერად. და მერე გამოჩნდა მესამე როლზე დაფუძნებული წვდომის კონტროლის მოდელი! ეს მიდგომა ყველაზე პერსპექტიულია, რადგან ის მოითხოვს არა მხოლოდ მომხმარებლის ვინაობის ავტორიზაციას, არამედ მის ოპერაციულ ფუნქციებს სისტემებში.

პირველი ნათლად აღწერილი მისაბაძი სტრუქტურა შემოგვთავაზეს ამერიკელმა მეცნიერებმა დევიდ ფერაილომ და რიჩარდ კუნმა აშშ-ს სტანდარტებისა და ტექნოლოგიების ეროვნული ინსტიტუტიდან 1992 წელს. შემდეგ პირველად გამოჩნდა ტერმინი RBAC (როლზე დაფუძნებული წვდომის კონტროლი). ძირითადი კომპონენტების ეს კვლევები და აღწერილობები, ისევე როგორც მათი ურთიერთობები, საფუძვლად დაედო INCITS 359-2012 სტანდარტს, რომელიც დღემდე მოქმედებს, დამტკიცებული საინფორმაციო ტექნოლოგიების სტანდარტების საერთაშორისო კომიტეტის (INCITS) მიერ.

სტანდარტი განსაზღვრავს როლს, როგორც „სამუშაო ფუნქციას ორგანიზაციის კონტექსტში, რომელსაც აქვს გარკვეული ასოცირებული სემანტიკა როლზე მინიჭებული მომხმარებლის უფლებამოსილებასა და პასუხისმგებლობასთან დაკავშირებით“. დოკუმენტი ადგენს RBAC-ის ძირითად ელემენტებს - მომხმარებლებს, სესიებს, როლებს, ნებართვებს, ოპერაციებს და ობიექტებს, ასევე მათ შორის ურთიერთობებსა და ურთიერთკავშირებს.

სტანდარტი ითვალისწინებს მინიმალურ საჭირო სტრუქტურას მისაბაძი მოდელის შესაქმნელად - უფლებების როლებში გაერთიანება და შემდეგ ამ როლების მეშვეობით მომხმარებლებისთვის წვდომის მინიჭება. ასახულია ობიექტებიდან და ოპერაციებიდან როლების შედგენის მექანიზმები, აღწერილია როლების იერარქია და უფლებამოსილებების მემკვიდრეობა. ყოველივე ამის შემდეგ, ნებისმიერ კომპანიაში არის როლები, რომლებიც აერთიანებს ძირითად უფლებამოსილებებს, რომლებიც აუცილებელია კომპანიის ყველა თანამშრომლისთვის. ეს შეიძლება იყოს წვდომა ელფოსტაზე, EDMS-ზე, კორპორატიულ პორტალზე და ა.შ. ეს ნებართვები შეიძლება შევიდეს ერთ ზოგად როლში, სახელწოდებით „თანამშრომლი“, და არ იქნება საჭირო ყველა ძირითადი უფლებების განმეორებით ჩამოთვლა უმაღლესი დონის თითოეულ როლში. საკმარისია უბრალოდ მიუთითოთ "თანამშრომლის" როლისთვის დამახასიათებელი მემკვიდრეობა.

მოგვიანებით, სტანდარტს დაემატა ახალი წვდომის ატრიბუტები, რომლებიც დაკავშირებულია მუდმივად ცვალებად გარემოსთან. დამატებულია სტატიკური და დინამიური შეზღუდვების დანერგვის შესაძლებლობა. სტატიკური გულისხმობს როლების შერწყმის შეუძლებლობას (ზემოხსენებული ოპერაციების იგივე შეყვანა და კონტროლი). დინამიური შეზღუდვები შეიძლება განისაზღვროს პარამეტრების შეცვლით, მაგალითად, დროის (სამუშაო/არასამუშაო საათები ან დღეები), მდებარეობა (ოფისი/სახლი) და ა.შ.

ცალკე აღნიშვნა ღირს ატრიბუტზე დაფუძნებული წვდომის კონტროლი (ABAC - ატრიბუტზე დაფუძნებული წვდომის კონტროლი). მიდგომა ეფუძნება წვდომის მინიჭებას ატრიბუტების გაზიარების წესების გამოყენებით. ეს მოდელი შეიძლება გამოყენებულ იქნას ცალკე, მაგრამ საკმაოდ ხშირად ის აქტიურად ავსებს კლასიკურ მისაბაძ მოდელს: გარკვეულ როლს შეიძლება დაემატოს მომხმარებლების ატრიბუტები, რესურსები და მოწყობილობები, ასევე დრო ან მდებარეობა. ეს საშუალებას გაძლევთ გამოიყენოთ ნაკლები როლები, შემოიღოთ დამატებითი შეზღუდვები და გახადოთ წვდომა რაც შეიძლება მინიმალური და, შესაბამისად, გააუმჯობესოთ უსაფრთხოება.

მაგალითად, ბუღალტერს შეიძლება მიეცეს წვდომა ანგარიშებზე, თუ ის მუშაობს გარკვეულ რეგიონში. შემდეგ სპეციალისტის მდებარეობა შედარდება გარკვეულ საცნობარო მნიშვნელობასთან. ან თქვენ შეგიძლიათ მისცეთ წვდომა ანგარიშებზე მხოლოდ იმ შემთხვევაში, თუ მომხმარებელი შედის სისტემაში დაშვებულთა სიაში შეტანილი მოწყობილობიდან. კარგი დამატებაა მისაბაძი მაგალითისთვის, მაგრამ იშვიათად გამოიყენება დამოუკიდებლად, ნებართვების ან შეზღუდვების მრავალი წესისა და ცხრილის შექმნის საჭიროების გამო.

ნება მომეცით მოგცეთ ABAC-ის გამოყენების მაგალითი ჩემი „წარსული ცხოვრებიდან“. ჩვენს ბანკს რამდენიმე ფილიალი ჰქონდა. ამ ფილიალებში კლიენტთა ოფისების თანამშრომლები ასრულებდნენ ზუსტად იგივე ოპერაციებს, მაგრამ უწევდათ მთავარ სისტემაში მუშაობა მხოლოდ თავიანთ რეგიონში არსებული ანგარიშებით. პირველი, ჩვენ დავიწყეთ ცალკეული როლების შექმნა თითოეული რეგიონისთვის - და იყო ამდენი ასეთი როლი განმეორებითი ფუნქციონირებით, მაგრამ სხვადასხვა ანგარიშებზე წვდომით! შემდეგ, მომხმარებლისთვის მდებარეობის ატრიბუტის გამოყენებით და მისი განსახილველად ანგარიშების კონკრეტულ დიაპაზონთან ასოცირებით, ჩვენ მნიშვნელოვნად შევამცირეთ როლების რაოდენობა სისტემაში. შედეგად, როლები დარჩა მხოლოდ ერთი ფილიალისთვის, რომელიც გაიმეორა ბანკის ყველა სხვა ტერიტორიულ განყოფილებაში შესაბამის პოზიციებზე.

ახლა მოდით ვისაუბროთ აუცილებელ მოსამზადებელ ნაბიჯებზე, რომელთა გარეშეც უბრალოდ შეუძლებელია სამუშაო მისაბაძი მოდელის აგება.

ნაბიჯი 1. შექმენით ფუნქციური მოდელი

თქვენ უნდა დაიწყოთ ფუნქციური მოდელის შექმნით - უმაღლესი დონის დოკუმენტი, რომელიც დეტალურად აღწერს თითოეული განყოფილების და თითოეული პოზიციის ფუნქციონირებას. როგორც წესი, მასში ინფორმაცია შედის სხვადასხვა დოკუმენტებიდან: სამუშაოს აღწერილობები და დებულებები ცალკეული ერთეულებისთვის - განყოფილებები, განყოფილებები, განყოფილებები. ფუნქციონალური მოდელი შეთანხმებული უნდა იყოს ყველა დაინტერესებულ დეპარტამენტთან (ბიზნესი, შიდა კონტროლი, დაცვა) და დამტკიცდეს კომპანიის მენეჯმენტის მიერ. რისთვის არის ეს დოკუმენტი? ისე, რომ მისაბაძ მოდელს შეუძლია მიმართოს მას. მაგალითად, თქვენ აპირებთ თანამშრომლების არსებულ უფლებებზე დაფუძნებული მისაბაძი მოდელის შექმნას - სისტემიდან გადმოტვირთვას და „საერთო მნიშვნელამდე დაყვანილს“. შემდეგ, სისტემის ბიზნეს მფლობელთან მიღებულ როლებზე შეთანხმებისას, შეგიძლიათ მიუთითოთ ფუნქციური მოდელის კონკრეტული პუნქტი, რის საფუძველზეც ესა თუ ის უფლება შედის როლში.

ნაბიჯი 2. ვამოწმებთ IT სისტემებს და ვადგენთ პრიორიტეტების გეგმას

მეორე ეტაპზე, თქვენ უნდა ჩაატაროთ IT სისტემების აუდიტი, რათა გაიგოთ, როგორ არის ორგანიზებული მათზე წვდომა. მაგალითად, ჩემი ფინანსური კომპანია რამდენიმე ასეულ საინფორმაციო სისტემას მართავდა. ყველა სისტემას გააჩნდა როლებზე დაფუძნებული მენეჯმენტის საფუძვლები, უმეტესობას ჰქონდა გარკვეული როლები, მაგრამ ძირითადად ქაღალდზე ან სისტემის დირექტორიაში - ისინი დიდი ხანია მოძველებული იყო და მათზე წვდომა მინიჭებული იყო მომხმარებლის რეალური მოთხოვნების საფუძველზე. ბუნებრივია, უბრალოდ შეუძლებელია მისაბაძი მოდელის შექმნა ერთდროულად რამდენიმე ასეულ სისტემაში, საიდანღაც უნდა დაიწყო. ჩვენ ჩავატარეთ წვდომის კონტროლის პროცესის სიღრმისეული ანალიზი მისი სიმწიფის დონის დასადგენად. ანალიზის პროცესში შემუშავდა საინფორმაციო სისტემების პრიორიტეტულობის კრიტერიუმები - კრიტიკულობა, მზადყოფნა, დეკომისიაციის გეგმები და ა.შ. მათი დახმარებით ჩვენ შევადგინეთ ამ სისტემების როლური მოდელების შემუშავება/განახლება. და შემდეგ ჩვენ ჩავრთეთ როლური მოდელები Identity Management-ის გადაწყვეტასთან ინტეგრაციის გეგმაში წვდომის კონტროლის ავტომატიზაციისთვის.

როგორ განვსაზღვროთ სისტემის კრიტიკულობა? უპასუხეთ საკუთარ თავს შემდეგ კითხვებს:

• არის თუ არა სისტემა დაკავშირებული იმ ოპერაციულ პროცესებთან, რომლებზეც დამოკიდებულია კომპანიის ძირითადი საქმიანობა?
• იმოქმედებს თუ არა სისტემის დარღვევა კომპანიის აქტივების მთლიანობაზე?
• რა არის სისტემის მაქსიმალური დასაშვები დრო, რომლის მიღწევაც შეუძლებელია აქტივობის აღდგენა შეფერხების შემდეგ?
• შეიძლება თუ არა სისტემაში ინფორმაციის მთლიანობის დარღვევამ გამოიწვიოს შეუქცევადი შედეგები, როგორც ფინანსური, ასევე რეპუტაცია?
• კრიტიკულობა თაღლითობის მიმართ. ფუნქციონირების არსებობამ, თუ სათანადოდ არ არის კონტროლირებადი, შეიძლება გამოიწვიოს შიდა/გარე თაღლითური ქმედებები;
• როგორია ამ სისტემების სამართლებრივი მოთხოვნები და შიდა წესები და პროცედურები? დაწესდება თუ არა ჯარიმები მარეგულირებლების მხრიდან შეუსრულებლობისთვის?

ჩვენს ფინანსურ კომპანიაში ასეთი აუდიტი ჩავატარეთ. მენეჯმენტმა შეიმუშავა ხელმისაწვდომობის უფლებების მიმოხილვის აუდიტის პროცედურა, რათა შეხედოს არსებულ მომხმარებლებს და უფლებებს პირველ რიგში იმ საინფორმაციო სისტემებში, რომლებიც ყველაზე პრიორიტეტულ სიაში იყვნენ. ამ პროცესის მფლობელად დაინიშნა უსაფრთხოების დეპარტამენტი. მაგრამ კომპანიაში წვდომის უფლებების სრული სურათის მისაღებად საჭირო იყო პროცესში IT და ბიზნესის განყოფილებების ჩართვა. აქ კი დაიწყო კამათი, გაუგებრობები და ხანდახან დივერსიაც: არავის სურს, თავი დააღწიოს ამჟამინდელ მოვალეობებს და ჩაერთოს ზოგიერთ, ერთი შეხედვით, გაუგებარ საქმიანობაში.

NB მსხვილი კომპანიები, რომლებსაც აქვთ განვითარებული IT პროცესები, ალბათ იცნობენ IT აუდიტის პროცედურას - IT general controls (ITGC), რომელიც საშუალებას გაძლევთ იდენტიფიციროთ ხარვეზები IT პროცესებში და დაამყაროთ კონტროლი, რათა გააუმჯობესოთ პროცესები საუკეთესო პრაქტიკის შესაბამისად (ITIL, COBIT, IT. მმართველობა და ა.შ.) ასეთი აუდიტი საშუალებას აძლევს IT-სა და ბიზნესს უკეთ გაიგონ ერთმანეთი და განავითარონ ერთობლივი განვითარების სტრატეგია, გააანალიზონ რისკები, გააუმჯობესონ ხარჯები და განავითარონ უფრო ეფექტური მიდგომები მუშაობისთვის.



აუდიტის ერთ-ერთი სფეროა საინფორმაციო სისტემებზე ლოგიკური და ფიზიკური წვდომის პარამეტრების განსაზღვრა. მიღებული მონაცემები ჩვენ ავიღეთ საფუძვლად შემდგომი გამოყენებისთვის მისაბაძი მოდელის შესაქმნელად. ამ აუდიტის შედეგად ჩვენ გვქონდა IT სისტემების რეესტრი, რომელშიც განისაზღვრა მათი ტექნიკური პარამეტრები და იყო აღწერილობები. გარდა ამისა, თითოეული სისტემისთვის იდენტიფიცირებული იყო მფლობელი იმ ბიზნეს მიმართულებიდან, რომლის ინტერესებშიც ის მოქმედებდა: სწორედ ის იყო პასუხისმგებელი იმ ბიზნეს პროცესებზე, რომლებსაც ეს სისტემა ემსახურებოდა. ასევე დაინიშნა IT სერვისის მენეჯერი, რომელიც პასუხისმგებელია კონკრეტული IS-ისთვის ბიზნეს საჭიროებების ტექნიკურ შესრულებაზე. დაფიქსირდა კომპანიისთვის ყველაზე კრიტიკული სისტემები და მათი ტექნიკური პარამეტრები, ექსპლუატაციაში გაშვების და ექსპლუატაციის ვადები და ა.შ. ეს პარამეტრები ძალიან დაეხმარა მისაბაძი მოდელის შესაქმნელად მომზადების პროცესს.

ნაბიჯი 3 შექმენით მეთოდოლოგია

ნებისმიერი ბიზნესის წარმატების გასაღები სწორი მეთოდია. ამიტომ, როგორც მისაბაძი მოდელის შესაქმნელად, ასევე აუდიტის ჩასატარებლად, ჩვენ უნდა შევქმნათ მეთოდოლოგია, რომელშიც აღვწერთ ურთიერთქმედებას დეპარტამენტებს შორის, დავადგინოთ პასუხისმგებლობა კომპანიის დებულებებში და ა.შ.
პირველ რიგში, თქვენ უნდა შეისწავლოთ ყველა არსებული დოკუმენტი, რომელიც ადგენს წვდომისა და უფლებების მინიჭების პროცედურას. კარგი თვალსაზრისით, პროცესები უნდა იყოს დოკუმენტირებული რამდენიმე დონეზე:

• ზოგადი კორპორატიული მოთხოვნები;
• მოთხოვნები ინფორმაციული უსაფრთხოების სფეროებისთვის (დამოკიდებულია ორგანიზაციის საქმიანობის სფეროებიდან);
• მოთხოვნები ტექნოლოგიური პროცესებისთვის (ინსტრუქციები, წვდომის მატრიცები, გაიდლაინები, კონფიგურაციის მოთხოვნები).

ჩვენს საფინანსო კომპანიაში აღმოვაჩინეთ ბევრი მოძველებული დოკუმენტი, რომელიც უნდა შემოგვეტანა ახალი მიმდინარე პროცესების შესაბამისად.

მენეჯმენტის ბრძანებით შეიქმნა სამუშაო ჯგუფი, რომელშიც შედიოდნენ უსაფრთხოების, IT, ბიზნესისა და შიდა კონტროლის წარმომადგენლები. ბრძანებაში გამოიკვეთა ჯგუფის შექმნის მიზნები, საქმიანობის მიმართულება, არსებობის პერიოდი და პასუხისმგებლები თითოეული მხრიდან. გარდა ამისა, ჩვენ შევიმუშავეთ აუდიტის მეთოდოლოგია და მისაბაძი მოდელის შექმნის პროცედურა: მათზე შეთანხმებული იყო სფეროს ყველა პასუხისმგებელი წარმომადგენელი და დამტკიცდა კომპანიის მენეჯმენტის მიერ.

სამუშაოების განხორციელების პროცედურის, ვადების, პასუხისმგებლობების და ა.შ. - გარანტია, რომ სანუკვარი მიზნისკენ მიმავალ გზაზე, რომელიც თავიდან ყველასთვის აშკარა არ არის, არავის გაუჩნდება კითხვები "რატომ ვაკეთებთ ამას, რატომ გვჭირდება და ა. და არ იქნება შესაძლებლობა "გადახტა" ან პროცესის შენელება.

ნაბიჯი 4. დააფიქსირეთ არსებული წვდომის კონტროლის მოდელის პარამეტრები

ჩვენ ვამზადებთ ე.წ „სისტემურ პასპორტს“ დაშვების კონტროლის კუთხით. არსებითად, ეს არის კითხვარი კონკრეტულ საინფორმაციო სისტემაზე, რომელიც აღრიცხავს მასზე წვდომის კონტროლის ყველა ალგორითმს. კომპანიები, რომლებმაც უკვე დანერგეს IdM-ის კლასის გადაწყვეტილებები, ალბათ კარგად იცნობენ ასეთ კითხვარს, რადგან სწორედ აქედან იწყება სისტემების კვლევა.

სისტემისა და მფლობელების შესახებ გარკვეული პარამეტრი შემოვიდა კითხვარში IT რეესტრიდან (იხ. ნაბიჯი 2, აუდიტი), მაგრამ ასევე დაემატა ახალი:

• როგორ იმართება ანგარიშები (პირდაპირ მონაცემთა ბაზაში ან პროგრამული ინტერფეისების მეშვეობით);
• როგორ შედიან მომხმარებლები სისტემაში (ცალკე ანგარიშის გამოყენებით ან AD ანგარიშის გამოყენებით, LDAP და ა.შ.);
• სისტემაში წვდომის რა დონეებია გამოყენებული (აპლიკაციის დონე, სისტემის დონე, ქსელის ფაილური რესურსების სისტემური გამოყენება);
• სერვერების აღწერა და პარამეტრები, რომლებზეც მუშაობს სისტემა;
• რა ანგარიშის მართვის ოპერაციებია მხარდაჭერილი (დაბლოკვა, სახელის გადარქმევა და ა.შ.);
• რა ალგორითმები ან წესები გამოიყენება სისტემის მომხმარებლის იდენტიფიკატორის გენერირებისთვის;
• რა ატრიბუტი შეიძლება გამოყენებულ იქნას პერსონალის სისტემაში თანამშრომლის ჩანაწერთან კავშირის დასამყარებლად (სრული სახელი, პერსონალის ნომერი და ა.შ.);
• ანგარიშის ყველა შესაძლო ატრიბუტი და მათი შევსების წესი;
• რა წვდომის უფლებები არსებობს სისტემაში (როლები, ჯგუფები, ატომური უფლებები და ა.შ., არის თუ არა ბუდობრივი თუ იერარქიული უფლებები);
• წვდომის უფლებების გაყოფის მექანიზმები (პოზიციის, განყოფილების, ფუნქციონირების და ა.შ.);
• აქვს თუ არა სისტემას უფლებების სეგრეგაციის წესები (SOD – მოვალეობების სეგრეგაცია) და როგორ მუშაობს ისინი;
• როგორ მუშავდება სისტემაში არყოფნის, გადაცემის, გათავისუფლების, თანამშრომლის მონაცემების განახლება და ა.შ.

ეს სია შეიძლება გაგრძელდეს, სადაც დეტალურად არის აღწერილი სხვადასხვა პარამეტრები და სხვა ობიექტები, რომლებიც მონაწილეობენ წვდომის კონტროლის პროცესში.

ნაბიჯი 5. შექმენით ბიზნესზე ორიენტირებული ნებართვების აღწერა

კიდევ ერთი დოკუმენტი, რომელიც დაგვჭირდება მისაბაძი მოდელის შექმნისას, არის საცნობარო წიგნი ყველა შესაძლო უფლებამოსილების (უფლების) შესახებ, რომელიც შეიძლება მიენიჭოს მომხმარებლებს საინფორმაციო სისტემაში, ბიზნეს ფუნქციის დეტალური აღწერილობით, რომელიც დგას მის უკან. ხშირად, სისტემაში ავტორიტეტები დაშიფრულია გარკვეული სახელებით, რომლებიც შედგება ასოებისა და ციფრებისგან და ბიზნესის თანამშრომლები ვერ ხვდებიან რა იმალება ამ სიმბოლოების მიღმა. მერე მიდიან IT სერვისში, იქ... ასევე ვერ პასუხობენ კითხვაზე, მაგალითად, იშვიათად გამოყენებული უფლებების შესახებ. შემდეგ უნდა ჩატარდეს დამატებითი ტესტირება.

კარგია, თუ უკვე არსებობს ბიზნესის აღწერა ან თუნდაც ამ უფლებების გაერთიანება ჯგუფებად და როლებად. ზოგიერთი აპლიკაციისთვის საუკეთესო პრაქტიკაა ასეთი მითითების შექმნა განვითარების ეტაპზე. მაგრამ ეს ხშირად არ ხდება, ამიტომ ჩვენ კვლავ მივდივართ IT დეპარტამენტში, რათა შევაგროვოთ ინფორმაცია ყველა შესაძლო უფლებების შესახებ და აღვწეროთ ისინი. ჩვენი სახელმძღვანელო საბოლოოდ შეიცავს შემდეგს:

• ორგანოს დასახელება, მათ შორის ობიექტი, რომელზეც ვრცელდება დაშვების უფლება;
• ქმედება, რომელიც ნებადართულია ობიექტთან (ნახვა, შეცვლა და ა.შ., შეზღუდვის შესაძლებლობა, მაგალითად, ტერიტორიული საფუძველზე ან კლიენტთა ჯგუფის მიხედვით);
• ავტორიზაციის კოდი (სისტემის ფუნქციის/მოთხოვნის კოდი და დასახელება, რომელიც შეიძლება შესრულდეს ავტორიზაციის გამოყენებით);
• უფლებამოსილების აღწერა (IS-ში მოქმედებების დეტალური აღწერა უფლებამოსილების გამოყენებისას და მათი შედეგები პროცესზე;
• ნებართვის სტატუსი: „აქტიური“ (თუ ნებართვა მინიჭებულია მინიმუმ ერთი მომხმარებლისთვის) ან „არააქტიური“ (თუ ნებართვა არ არის გამოყენებული).

ნაბიჯი 6 ჩვენ ჩამოვტვირთავთ მონაცემებს მომხმარებლებისა და უფლებების შესახებ სისტემებიდან და ვადარებთ მათ პერსონალის წყაროს

მომზადების ბოლო ეტაპზე, თქვენ უნდა ჩამოტვირთოთ მონაცემები საინფორმაციო სისტემებიდან ყველა მომხმარებლის შესახებ და იმ უფლებების შესახებ, რომლებიც მათ ამჟამად აქვთ. აქ ორი შესაძლო სცენარია. პირველი: უსაფრთხოების განყოფილებას აქვს პირდაპირი წვდომა სისტემაში და აქვს შესაბამისი ანგარიშების ჩამოტვირთვის საშუალება, რაც ხშირად არ ხდება, მაგრამ ძალიან მოსახერხებელია. მეორე: ჩვენ ვუგზავნით თხოვნას IT-ს, რომ მიიღოთ მოხსენებები საჭირო ფორმატში. გამოცდილება გვიჩვენებს, რომ IT–თან შეთანხმება და საჭირო მონაცემების პირველად მოპოვება შეუძლებელია. საჭიროა რამდენიმე მიდგომის გაკეთება, სანამ ინფორმაცია არ მიიღება სასურველი ფორმით და ფორმატით.

რა მონაცემები უნდა ჩამოტვირთოთ:

• Ანგარიშის სახელი
• თანამშრომლის სრული სახელი, რომელსაც იგი ენიჭება
• სტატუსი (აქტიური ან დაბლოკილი)
• ანგარიშის შექმნის თარიღი
• ბოლო გამოყენების თარიღი
• ხელმისაწვდომი უფლებების/ჯგუფების/როლების სია

ასე რომ, ჩვენ მივიღეთ ჩამოტვირთვები სისტემიდან ყველა მომხმარებელთან და ყველა უფლება, რაც მათ მიენიჭა. და ისინი დაუყოვნებლივ აყენებენ ყველა დაბლოკილ ანგარიშს, რადგან როლური მოდელის შექმნაზე მუშაობა განხორციელდება მხოლოდ აქტიური მომხმარებლებისთვის.

შემდეგ, თუ თქვენს კომპანიას არ აქვს გათავისუფლებული თანამშრომლების წვდომის დაბლოკვის ავტომატური საშუალებები (ეს ხშირად ხდება) ან აქვს პაჩვორკის ავტომატიზაცია, რომელიც ყოველთვის არ მუშაობს სწორად, თქვენ უნდა დაადგინოთ ყველა „მკვდარი სული“. საუბარია იმ თანამშრომლების ანგარიშებზე, რომლებიც უკვე გათავისუფლებულია, რომელთა უფლებები რატომღაც არ არის დაბლოკილი - საჭიროა მათი დაბლოკვა. ამისათვის ჩვენ შევადარებთ ატვირთულ მონაცემებს პერსონალის წყაროსთან. პერსონალის გადმოტვირთვა ასევე წინასწარ უნდა იქნას მიღებული პერსონალის მონაცემთა ბაზის შემნახველი განყოფილებიდან.

ცალკე, აუცილებელია გამოვყოთ ანგარიშები, რომელთა მფლობელები არ იქნა ნაპოვნი პერსონალის მონაცემთა ბაზაში, არ არის მინიჭებული ვინმესთვის - ანუ უპატრონო. ამ სიის გამოყენებით დაგვჭირდება ბოლო გამოყენების თარიღი: თუ ის საკმაოდ ბოლოა, მაინც მოგვიწევს მფლობელების ძებნა. ეს შეიძლება მოიცავდეს გარე კონტრაქტორების ანგარიშებს ან მომსახურების ანგარიშებს, რომლებიც არ არის მინიჭებული ვინმესთვის, მაგრამ დაკავშირებულია ნებისმიერ პროცესთან. იმის გასარკვევად, თუ ვის ეკუთვნის ეს ანგარიშები, შეგიძლიათ გაუგზავნოთ წერილები ყველა დეპარტამენტს, რომ სთხოვოთ პასუხის გაცემა. როდესაც მფლობელები იპოვიან, მათ შესახებ მონაცემებს სისტემაში შევიყვანთ: ამ გზით ყველა აქტიური ანგარიში იდენტიფიცირებულია, დანარჩენი კი იბლოკება.

როგორც კი ჩვენი ატვირთვები გაიწმინდება არასაჭირო ჩანაწერებისგან და დარჩება მხოლოდ აქტიური ანგარიშები, ჩვენ შეგვიძლია დავიწყოთ მისაბაძი მაგალითის შექმნა კონკრეტული საინფორმაციო სისტემისთვის. მაგრამ ამის შესახებ შემდეგ სტატიაში მოგიყვებით.

ავტორი: ლუდმილა სევასტიანოვა, სარეკლამო მენეჯერი Solar inRights

წყარო: www.habr.com