უსაფრთხოება გადამწყვეტია მონაცემთა ბაზის ადმინისტრატორებს, რომლებიც ცდილობენ დაიცვან თავიანთი გიგაბაიტები სასიცოცხლო ბიზნეს მონაცემებისგან, რომლებიც არასანქცირებული გარეგნებისა და ინსაიდერების თვალწარმტაცი თვალსაზრისით ცდილობენ თავიანთ უფლებამოსილებას გადააჭარბონ. ყველა სარელეო მონაცემთა ბაზების მართვის სისტემები უზრუნველყოფს გარკვეულ შიდა უსაფრთხოების მექანიზმებს, რომლებიც მიზნად ისახავს ამ საფრთხეების მინიმიზაციას. ისინი მერყეობს მარტივი პაროლის დაცვისგან, რომელსაც Microsoft Access- ი სთავაზობს კომპლექსური მომხმარებელი / როლის სტრუქტურას, რომელიც მხარს უჭერს მოწინავე ურთიერთდაკავშირებულ მონაცემთა ბაზებს, როგორიცაა Oracle და Microsoft SQL Server. ეს სტატია ყურადღებას უთმობს უსაფრთხოების მექანიზმებს, რომლებიც საერთოა ყველა მონაცემთა ბაზაში, რომლებიც ახორციელებენ სტრუქტურირებული შეკითხვის ენა (ან SQL ). ჩვენ ერთად ვივლით მონაცემთა დაშვების კონტროლის განმტკიცებას და თქვენი მონაცემების უსაფრთხოების უზრუნველყოფას.
მომხმარებელი
სერვერზე დაფუძნებული მონაცემთა ბაზები ყველა მხარს უჭერს მომხმარებლის კონცეფციას, რომელიც გამოიყენება კომპიუტერული ოპერაციული სისტემებით. თუ თქვენ იცნობთ მომხმარებლის / ჯგუფის იერარქიას იცნობს Microsoft Windows NT და Windows 2000- ს, თქვენ ნახავთ, რომ SQL Server და Oracle- ის მხარდაჭერით მომხმარებლის / როლის დაჯგუფებები ძალიან ჰგავს.
რეკომენდირებულია, რომ თქვენ შექმენით ინდივიდუალური მონაცემთა ბაზის მომხმარებლის ანგარიშები თითოეულ ადამიანს, რომელიც იქნება ხელმისაწვდომი თქვენს მონაცემთა ბაზაში. ეს ტექნიკურად შესაძლებელია გაიზიაროთ ანგარიშები წევრებს შორის ან უბრალოდ გამოიყენოთ ერთი მომხმარებლის ანგარიში თითოეული ტიპის მომხმარებელი, რომელიც საჭიროებს თქვენი მონაცემთა ბაზის, მაგრამ მე კატეგორიულად დაუკარგავს ეს პრაქტიკა ორი მიზეზის გამო. პირველ რიგში, ის აღმოფხვრის ინდივიდუალურ ანგარიშვალდებულებას - თუ მომხმარებელი თქვენს მონაცემთა ბაზაში ცვლილებებს იძლევა (მოდით თქვათ, რომ $ 5,000 გაიზარდოს), თქვენ ვერ დააბრუნებთ კონკრეტულ პირს აუდიტის ჟურნალების გამოყენებით. გარდა ამისა, თუ კონკრეტული მომხმარებელი ტოვებს თქვენს ორგანიზაციას და გსურთ მისი წვდომის მონაცემთა ბაზის ამოღება, თქვენ იძულებულნი გახდებიან შეცვალოთ პაროლი, რომელიც ყველა მომხმარებელს დაეყრდნობა.
მომხმარებლის ანგარიშების შექმნის მეთოდები განსხვავდება პლატფორმისგან პლატფორმისგან და თქვენ უნდა მიმართოთ თქვენს DBMS- ის სპეციფიკურ დოკუმენტაციას ზუსტი პროცედურისთვის. Microsoft SQL Server მომხმარებლებს უნდა გამოიძიონ გამოყენების sp_adduser შენახული პროცედურა. Oracle მონაცემთა ბაზის ადმინისტრატორები იხილავთ CREATE USER ბრძანებას. თქვენ ასევე დაგვჭირდება ალტერნატიული ავტორიზაციის სქემების გამოკვლევა. მაგალითად, Microsoft SQL Server მხარს უჭერს გამოყენების Windows NT ინტეგრირებული უსაფრთხოება. ამ სქემის მიხედვით, მომხმარებლებს Windows NT- ის ანგარიშების მონაცემთა ბაზაში იდენტიფიცირებულია და არ არის საჭირო მონაცემთა ბაზის ხელმისაწვდომობის დამატებითი მომხმარებლის ID და პაროლი. ეს მიდგომა მონაცემთა ბაზის ადმინისტრატორებს შორის ძალიან პოპულარულია, რადგან ის ანგარიშის მართვის ტვირთი ქსელის ადმინისტრირების პერსონალს გადააქვს და უზრუნველყოფს საბოლოო მომხმარებლისთვის ერთჯერადი ნიშნით.
როლები
თუ თქვენ ხართ გარემოში მცირე რაოდენობის მომხმარებლებთან, თქვენ ალბათ იპოვით, რომ მომხმარებლის ანგარიშების შექმნა და მათთვის მინიჭებული ნებართვების მინიჭება საკმარისია თქვენს საჭიროებებზე. თუმცა, თუ თქვენ გაქვთ დიდი რაოდენობით მომხმარებელი, თქვენ სავარაუდოდ overwhelmed მიერ ტვირთი შენარჩუნების ანგარიშები და სათანადო უფლებები. ამ ტვირტის განმუხტვის მიზნით, რელატიური მონაცემთა ბაზები მხარს უჭერენ როლების როლს. მონაცემთა ბაზის როლები ფუნქციონირებს Windows NT ჯგუფების მსგავსად. მომხმარებლის ანგარიშებს ენიჭება როლი (ებ) და ნებართვები შემდეგ ენიჭება როლს მთლიანად ვიდრე ინდივიდუალური მომხმარებლის ანგარიშები. მაგალითად, ჩვენ შეგვიძლია შევქმნათ DBA როლი და შემდეგ დაამატეთ ჩვენი ადმინისტრაციული პერსონალის მომხმარებლის ანგარიშები ამ როლს. მას შემდეგ, რაც ჩვენ გავაკეთეთ, ჩვენ შეგვიძლია მინიჭებული კონკრეტული ნებართვა ყველა დღევანდელი (და მომავალი) ადმინისტრატორები უბრალოდ მინიჭება ნებართვა როლი. კიდევ ერთხელ, როლების შექმნის პროცედურები მერყეობს პლატფორმისგან. MS SQL Server ადმინისტრატორები უნდა გამოიძიონ sp_addrole შენახული პროცედურა, ხოლო Oracle DBAs უნდა გამოიყენოს CREATE ROLE სინტაქსი.
ნებართვების მინიჭება
ახლა, როდესაც ჩვენ დაამატეთ მომხმარებლები ჩვენს მონაცემთა ბაზას, დროა უსაფრთხოების გაძლიერება დაიწყოთ ნებართვების დამატებაში. ჩვენი პირველი ნაბიჯი იქნება ჩვენი მომხმარებლებისათვის შესაბამისი მონაცემთა ბაზის ნებართვა. ჩვენ ამას დავასრულებთ SQL GRANT- ის განცხადების გამოყენებით.
აქ არის განცხადების სინტაქსი:
GRANT <ნებართვები>
[On
]
<მომხმარებელი / როლი>
[GRANT OPTION]
ახლა, მოდით შევხედოთ ამ განცხადების ხაზის მიხედვით. პირველი ხაზი, GRANT , საშუალებას გვაძლევს მიუთითოთ კონკრეტული ცხრილის ნებართვა, რომელსაც ჩვენ ვთავაზობთ. ეს შეიძლება იყოს მაგიდის დონის ნებართვა (როგორიცაა SELECT, INSERT, UPDATE და DELETE) ან მონაცემთა ბაზის ნებართვა (როგორიცაა CREATE TABLE, ALTER DATABASE და GRANT). ერთზე მეტი ნებართვა შეიძლება მიენიჭოთ მხოლოდ ერთი GRANT- ის განცხადებაში, მაგრამ ცხრილის დონის ნებართვა და მონაცემთა ბაზის დონის ნებართვა არ შეიძლება გაერთიანდეს ერთ განცხადებაში.
მეორე ხაზი, ON
, გამოიყენება ცხრილი დონის ნებართვებისთვის განკუთვნილი მაგიდისთვის. ეს ხაზი არ არის გამოტოვებული, თუ ჩვენ მონაცემთა ბაზის დონის ნებართვას ვაძლევთ. მესამე ხაზი განსაზღვრავს მომხმარებლის ან როლს, რომელიც ნებართვას ანიჭებს.
საბოლოოდ, მეოთხე ხაზი, GRANT OPTION, არის სურვილისამებრ. თუ ეს ხაზი შედის განცხადებაში, მომხმარებელი დაზარალებულს ასევე უფლებას აძლევს სხვა მომხმარებლისთვის ამგვარი ნებართვების მინიჭებას. გაითვალისწინეთ, რომ GRANT OPTION- თან არ შეიძლება მითითებული, როდესაც ნებართვა ენიჭება როლს.
მაგალითები
მოდით შევხედოთ რამდენიმე მაგალითს. ჩვენს პირველ სცენარში, ცოტა ხნის წინ დაქირავებული 42 მონაცემთა შესვლის ოპერატორთა ჯგუფი, რომლებიც დაემატა და შეინარჩუნებენ მომხმარებელთა ჩანაწერებს. მათ უნდა შეეძლოთ მომხმარებელთა მაგიდაზე ინფორმაციის ხელმისაწვდომობა, შეცვალონ ეს ინფორმაცია და დაამატეთ ახალი ჩანაწერები მაგიდასთან. მათ არ უნდა შეეძლოთ მთლიანად წაშალოთ მონაცემთა ბაზის ჩანაწერი. პირველ რიგში, ჩვენ უნდა შევქმნათ მომხმარებლის ანგარიშები თითოეული ოპერატორისთვის და შემდეგ ყველა მათგანს ახალი როლი, დაამატეთ DataEntry. შემდეგი, ჩვენ უნდა გამოვიყენოთ შემდეგი SQL განაცხადი მისცეს მათ შესაბამისი ნებართვები:
GRANT SELECT, INSERT, განახლება
კლიენტებზე
მონაცემთა დამონტაჟება
და ეს ყველაფერი არის ეს! ახლა მოდი დავაკვლევთ იმ შემთხვევას, სადაც ჩვენ მონაცემთა ბაზის დონის ნებართვას ვაძლევთ. ჩვენ გვინდა დავუშვათ DBA- ის როლი ჩვენს მონაცემთა ბაზაში ახალი ცხრილის დასამატებლად. გარდა ამისა, ჩვენ გვინდა, რომ მათ შეძლონ სხვა წევრების ნებართვა გასცეს. აქ არის SQL განაცხადი:
GRANT შექმნა TABLE
DBA- სთვის
GRANT OPTION- თან ერთად
გაითვალისწინეთ, რომ ჩვენ შევიტანეთ GRANT OPTION ხაზი, რათა უზრუნველყოს, რომ ჩვენი DBA- ები ამ ნებართვას სხვა წევრებს მიანიჭოთ.
ნებართვების წაშლა
მას შემდეგ, რაც ჩვენ ნებართვა მივიღეთ, ის ხშირად დასტურდება, რათა მოგვიანებით გაუქმდეს ისინი. საბედნიეროდ, SQL გვაწვდის REVOKE ბრძანებას ამოიღონ ადრე გაცემული ნებართვები. აქ არის სინტაქსი:
REVOKE [GRANT OPTION] <ნებართვები>
FROM <მომხმარებელი / როლი>
თქვენ შეამჩნევთ, რომ ამ ბრძანების სინტაქსი გრანტის ბრძანების მსგავსია. ერთადერთი განსხვავება ისაა, რომ GRANT- სთან ერთად მითითებულია REVOKE ბრძანების ხაზი, ვიდრე ბრძანების ბოლოს. მაგალითად, მოდი წარმოვიდგინოთ, რომ გვინდა მარიამის მიერ მანამდე მიღებული ნებართვა გაუქმდეს მომხმარებელთა მონაცემთა ბაზის ჩანაწერების ამოღებაზე. ჩვენ ვიყენებთ შემდეგ ბრძანებას:
REVOKE DELETE
კლიენტებზე
მერიდან
და ეს ყველაფერი არის ეს! არსებობს კიდევ ერთი დამატებითი მექანიზმი, რომელიც მხარს უჭერს Microsoft SQL Server- ს, რაც აღსანიშნავია - DENY ბრძანება. ეს ბრძანება შეიძლება გამოყენებულ იქნას მომხმარებელზე ნებართვის უგულებელყოფის შესახებ, რომ მათ შეიძლება სხვაგვარად ჰქონდეთ მიმდინარე ან მომავალი როლის გაწევრიანება. აქ არის სინტაქსი:
დენი <ნებართვები>
<მომხმარებელი / როლი
მაგალითები
დავუბრუნდეთ ჩვენს წინა მაგალითს, წარმოვიდგინოთ, რომ მერი იყო მენეჯერების როლის წევრი, რომელსაც ასევე ჰქონდა მომხმარებელთა მაგიდაზე წვდომა. წინა REVOKE განცხადება არ იქნება საკმარისი იმისათვის, რომ უარყოს მისი ხელმისაწვდომობა მაგიდაზე. იგი ამოიღებს მის მიერ გაცემული ნებართვის მინიჭებას GRANT- ის მეშვეობით, რომელიც მიზნად ისახავს მის ანგარიშზე, მაგრამ გავლენას არ მოახდენს მენეჯერების როლში მის წევრობაზე მიღებული ნებართვა. თუმცა, თუ ჩვენ ვიყენებთ DENY- ის განცხადებას, მისი ნებართვის მემკვიდრეობა დაბლოკავს. აი ბრძანება:
დენი დელეტი
კლიენტებზე
მარიამ
DENY ბრძანება არსებითად ქმნის "ნეგატიურ ნებართვას" მონაცემთა ბაზის დაშვების კონტროლში. თუ ჩვენ მოგვიანებით გადაწყვეტთ, რომ მერი ნებართვას მოეთხოვოს მომხმარებელთა მაგიდასთან მწკრივების ამოღება, ჩვენ არ შეგვიძლია უბრალოდ გამოიყენოთ GRANT ბრძანება. ეს ბრძანება დაუყოვნებლივ გადალახავდა არსებულ DENY- ს. ამის ნაცვლად, თავიდანვე გამოვიყენეთ REVOKE- ის ბრძანება, რომელიც უარყოფით ნებართვას მოხსნის შემდეგნაირად გადანაწილდა:
REVOKE DELETE
კლიენტებზე
მერიდან
თქვენ შეამჩნევთ, რომ ეს ბრძანება ზუსტად იგივეა, რაც გამოყენებულია დადებითი ნებართვის წაშლა. გახსოვდეთ, რომ DENY და GRANT ბრძანებებს ორივე სამსახურში მოქმედებენ * mdash, ორივე შექმნის ნებართვა (დადებითი ან უარყოფითი) ბაზაში დაშვების კონტროლის მექანიზმი. REVOKE ბრძანება ხსნის ყველა დადებით და უარყოფით ნებართვას მითითებულ მომხმარებელს. მას შემდეგ, რაც ეს ბრძანება გაცემულია, მერი შეძლებს მაგიდისგან მწკრივების წაშლა, თუ ის არის როლი, რომელსაც აქვს ნებართვა. გარდა ამისა, GRANT ბრძანება შეიძლება გაიცეს უზრუნველყოს წაშლა ნებართვა პირდაპირ მის ანგარიშზე.
ამ სტატიის მთელი პერიოდის მანძილზე ისწავლეთ სტანდარტული შეკითხვის ენაზე მხარდაჭერილი დაშვების კონტროლის მექანიზმების შესახებ. ეს შესავალი უნდა მოგაწოდოთ კარგი ამოსავალი წერტილიდან, მაგრამ მე მოგიწოდებთ თქვენს DBMS დოკუმენტაციის მითითებას თქვენი სისტემის მიერ გაძლიერებული უსაფრთხოების ზომების გაცნობა. თქვენ ნახავთ, რომ ბევრი მონაცემთა ბაზის მხარდაჭერა უფრო მოწინავე დაშვების კონტროლის მექანიზმები, როგორიცაა მინიჭების ნებართვების კონკრეტული სვეტების.