08 - Λογαριασμοί και Δικαιώματα σε Database Server

Βάσεις Δεδομένων Ι - 08

Λογαριασμοί & Δικαιώματα (σε έναν database server)

Φώτης Κόκκορας (MSc/PhD) Τμήμα Μηχανικών Πληροφορικής ΤΕ ΤΕΙ Θεσσαλίας

Φ. Κόκκορας / Τμήμα Μηχανικών Πληροφορικής - ΤΕΙ Θεσσαλίας - 2 - Βάσεις Δεδομένων Ι

Βασικές Έννοιες

Κάθε RDBMS (Relational Database Management System) παρέχει

ένα σύστημα διαχείρισης χρηστών (ή αλλιώς λογαριασμών/accounts)

μέσω του οποίου δίνει πρόσβαση στις υπηρεσίες που παρέχει.

Η έννοια του λογαριασμού/account επιτρέπει να δίνεται διαβαθμισμένη πρόσβαση

στο σύστημα, δεδομένου ότι ο καθένας θα πρέπει να έχει το επίπεδο πρόσβασης που

χρειάζεται για τις δουλειές που έχει να κάνει – τίποτα περισσότερο, τίποτα λιγότερο.

Κατά την εγκατάσταση του MySQL server, υπάρχει ο χρήστης/λογαριασμός root που

προορίζεται για τη διαχείριση του MySQL server, καθώς του επιτρέπεται να κάνει τα πάντα!

Αρχικά και για ευκολία, ο λογαριασμός root δεν περιέχει password. Προφανώς πρέπει να

ορίσετε password αν το περιβάλλον σας απαιτεί στοιχειώδη ασφάλεια.

Άρα μέσω ενός λογαριασμού που ορίζουμε στον database server, οι χρήστες μπορούν

να χρησιμοποιήσουν τον database server. Ποιοι είναι όμως αυτοί οι "χρήστες";

φυσικοί χρήστες: άνθρωποι που συνδέονται στον server είτε απευθείας ή μέσω κάποιας

γραφικής διεπαφής που παίζει το ρόλο μεσάζοντα (όπως πχ το Workbench, το FlySpeed, κτλ)

χρήστες-εφαρμογές: μια εφαρμογή (πχ. μια desktop εφαρμογή σε C# ή ένα site σε PHP) που

πρέπει να "μιλήσει" με μια database, πρέπει να το κάνει μέσω κάποιου database account.

Συνήθως μια εφαρμογή με πολλούς χρήστες υλοποιεί δικό της σύστημα διαχείρισης

χρηστών. Η ίδια όμως η εφαρμογή "μιλάει" με την ΒΔ μέσω ενός database account.


Τυπική Αρχιτεκτονική Web Εφαρμογής με ΒΔ

Έστω μια τυπική web εφαρμογή γραμμένη σε γλώσσα PHP, που χρησιμοποιεί βάση

δεδομένων (ΒΔ). Τα επιμέρους συστήματά της είναι:

web server (π.χ. Apache, Microsoft IIS, κτλ): αποκλειστική δουλειά του είναι να δέχεται http

κλίσεις για σελίδες από κάποιον client (πχ. browser) και να επιστρέφει σε αυτόν τις σελίδες

application server (π.χ. ASP, PHP, Tomcat, κτλ): αποκλειστική δουλεία του είναι να

ετοιμάζει τις δυναμικές σελίδες (αυτές που παράγονται ως αποτέλεσμα εκτέλεσης κάποιου

κώδικα σε μια γλώσσα προγραμματισμού) που ο web server δεν είναι σε θέση να κάνει, δηλ.

η PHP: χειρίζεται τις σελίδες τύπου PHP (γραμμένες σε γλώσσα PHP)

η ASP: χειρίζεται τις σελίδες τύπου ASP (γραμμένες σε γλώσσα ASP)

ο Tomcat: χειρίζεται τις σελίδες JSP (γραμμένες σε Java για ιστοσελίδες)

Αν η web εφαρμογή περιλαμβάνει database, τότε ο application server είναι

αυτός που αλληλεπιδρά με την database μέσω κατάλληλης προγραμματιστικής διεπαφής

πχ. η PHP έχει την βιβλιοθήκη PDO που παρέχει κατάλληλες εντολές για επικοινωνία της PHP

με κάποιον database server.

database server (π.χ. MySQL, MS SQL Server, Oracle, κτλ): παρέχει την τυπική

λειτουργικότητα ενός database server στον application server.

Όλοι οι παραπάνω "servers" είναι ΕΦΑΡΜΟΓΕΣ που τρέχουν σε ένα (ή περισσότε-

ρα, αν υπάρχουν θέματα επιδόσεων) υπολογιστικά συστήματα (hardware servers).


Σχηματική Απεικόνιση

Δείτε σχηματικά την τυπική οργάνωση μια web εφαρμογής με database:

web server και application server συνήθως "τρέχουν" στον ίδιο Η/Υ

ο database server μπορεί να τρέχει

είτε στον ίδιο Η/Υ με τον web server (όπως απεικονίζει το πράσινο πλαίσιο)

όταν δεν υπάρχουν θέματα επιδόσεων

ή σε διαφορετικό Η/Υ (όπως απεικονίζουν τα ροζ πλαίσια)

για λόγους επιδόσεων

για λόγους ασφάλειας (o database server μπορεί να βρίσκεται σε διαφορετικό χώρο)

ή σε πολλούς διαφορετικούς H/Y (οπότε λέμε ότι η database είναι στημένη σε cluster)

κύρια εξαιτίας υψηλών απαιτήσεων απόδοσης

Ο web client (αριστερά) δεν έρχεται σε άμεση επαφή με την database!

client internet web server database

server

application

server

H/Y #1 H/Y #2

H/Y #1


Web Εφαρμογές & Χρήστες τους

Έστω μια δημοφιλής web εφαρμογή, το facebook. Απλοποιώντας λίγο

την πραγματικότητα, θεωρείστε ότι κάθε χρήστης του facebook διατηρεί

τα δεδομένα του στην database του facebook. Δεν είναι πρακτικό να υπάρχει για κάθε χρήστη ένας λογαριασμός

(account) στον database server του facebook.

Πέρα από το τεράστιο πλήθος λογαριασμών (για ~1 δις χρήστες) που θα επιβαρύνει τον

server τρομακτικά, υπάρχει και ζήτημα ασφάλειας – ποιο εύκολα παραβιάζεται ένα κτήριο

με 1 δις πόρτες από ένα κτήριο με ...μόνο μία πόρτα!

Άρα πώς γίνεται και υπάρχουν τόσοι διακριτοί χρήστες στο facebook;

το facebook έχει υλοποιημένο δικό του σύστημα διαχείρισης χρηστών – το διατηρεί σε

κάποιους πίνακες στην database του

ο χρήστης κάνει διαπίστευση (login) στην εφαρμογή (το facebook), όχι στον database server

το facebook (η εφαρμογή) είναι αυτό που κάνει διαπίστευση στον database server

Άρα όλοι οι ~1δις χρήστες του facebook εξυπηρετούνται ως προς την database από

έναν και μοναδικό database user – τον database user μέσω του οποίου η εφαρμογή

facebook "μιλάει" με τον database server.


SQL Εντολές Διαχείρισης Λογαριασμών (1/2)

Θα δούμε τις βασικές εντολές της SQL για διαχείριση χρηστών και δικαιωμάτων.

εντολές για δημιουργία/διαγραφή/μεταβολή λογαριασμών (accounts)

εντολές για ορισμό ή κατάργηση δικαιωμάτων (rights)

δηλ. τι θα επιτρέπεται να κάνει κάθε "χρήστης" που συνδέεται στον db server μέσω ενός account

Βασικό: για να λειτουργήσουν οι σχετικές εντολές θα πρέπει να τις υποβάλει

κάποιος που έχει τα σχετικά δικαιώματα – συνήθως αυτός ο χρήστης είναι ο root.

Δημιουργία Database User (λογαριασμού/account) CREATE USER 'someUser'@'someDomain' IDENTIFIED BY 'mypass';

someuser το επιθυμητό username

mypass το επιθυμητό password

someDomain το domain από το οποίο επιτρέπεται να γίνει η σύνδεση

βάζοντας 'localhost' ο συνδεόμενος πρέπει να είναι στον ίδιο H/Y με τον database server

βάζοντας '%' o συνδεόμενος μπορεί να βρίσκεται οπουδήποτε στον κόσμο

βάζοντας '%.teilar.gr' o συνδεόμενος πρέπει να βρίσκεται σε PC του TEI Λάρισας, κ.ο.κ.

π.χ. rigel.teilar.gr, somePC.teilar.gr, κτλ.

το IDENTIFIED BY είναι προαιρετικό – το password μπορεί να οριστεί και με ειδική

εντολή (βλ. παρακάτω).


SQL Εντολές Διαχείρισης Λογαριασμών (2/2)

Διαγραφή Database User (λογαριασμού/account) DROP USER 'someUser'@'someDomain';

Σε MySQL, τυχόν αντικείμενα (πίνακες, κτλ) που έχει φτιάξει

ο χρήστης, ΔΕΝ διαγράφονται όταν διαγράφουμε τον χρήστη.

Αλλαγή Στοιχείων σε Database User (λογαριασμό) RENAME USER 'oldUsername'@'oldDomain' TO 'newUsername'@'newDomain';

Αλλαγή password σε Λογαριασμό SET PASSWORD FOR 'someUser'@'someDomain' = PASSWORD('newPassword');

newPassword είναι το νέο password

Απονομή Δικαιωμάτων σε Λογαριασμό

Γενική δομή εντολής: GRANT <δικαιώματα> ON <αντικείμενα> TO <λογαριασμός>

<δικαιώματα>: ένα ή περισσότερα δικαιώματα χωρισμένα με κόμμα

για πλήρη λίστα σε MySQL δείτε: http://dev.mysql.com/doc/refman/5.6/en/privileges-provided.html

<αντικείμενα>: ολόκληρη database, πίνακες, γνωρίσματα, όψεις, συναρτήσεις, κτλ

<λογαριασμός>: ο λογαριασμός στον οποίο δίνονται τα δικαιώματα (πρέπει να υπάρχει)

παραδείγματα στη συνέχεια

Αφαίρεση Δικαιωμάτων από Λογαριασμό (οι 3 παράμετροι όπως πριν)

Γενική δομή εντολής: REVOKE <δικαιώματα> ON <αντικείμενα> FROM <λογαριασμός>

http://dev.mysql.com/doc/refman/5.6/en/privileges-provided.html


Παραδείγματα Ανάθεσης Δικαιωμάτων

Παρακάτω, το ΔΛ σημαίνει "δοθέντας λογαριασμός" και εννοεί τον database account για τον οποίο γίνεται η εκάστοτε δουλειά ανάθεσης.

GRANT SELECT, INSERT ON *.* TO 'someuser'@'somehost';

Δώσε στον ΔΛ δικαιώματα για SELECT και INSERT για όλους τους πίνακες όλων των ΒΔ

GRANT SELECT (col1), INSERT (col1, col2) ON mydb.mytbl TO 'someuser'@'somehost';

Δώσε στον ΔΛ δικαιώματα για SELECT στη στήλη col1 και INSERT στις στήλες col2 και col3, για τον πίνακα

mytbl της database mydb

GRANT ALL ON db1.* TO 'jeffrey'@'localhost';

Δώσε στον ΔΛ όλα τα δικαιώματα (εκτός του GRANT) για όλους τους πίνακες της database mydb

GRANT ALL ON db2.invoice TO 'jeffrey'@'%.company.com';

Δώσε στον ΔΛ όλα τα δικαιώματα (εκτός του GRANT) για τον πίνακα invoice της database db2.

GRANT USAGE ON *.* TO 'jeffrey'@'localhost' WITH MAX_QUERIES_PER_HOUR 90;

Δώσε στον ΔΛ τα δικαιώματα USAGE για όλα τα αντικείμενα με όριο υποβολής 90 ερωτημάτων ανά ώρα

Ένα παράδειγμα αφαίρεσης δικαιωμάτων

REVOKE INSERT ON *.* FROM 'jeffrey'@'localhost';

Αφαίρεσε από τον δοθέντα λογαριασμό το δικαίωμα INSERT για όλα τα αντικείμενα.


Δικαιώματα & Workbench

Στο Workbench φτιάχνετε χρήστες και να ορίζετε δικαιώματα με 2 τρόπους:

με εντολές SQL σε ένα παράθυρο δημιουργίας ερωτημάτων

θα πρέπει να έχετε συνδεθεί με ένα connection συνδεδεμένο με λογαριασμό επαρκών

δικαιωμάτων (πχ με ένα connection φτιαγμένο πάνω στον χρήστη root)

μέσω του γραφικού περιβάλλοντος διαχείρισης (βλ. και επόμενο slide)

Σύντομη Περιγραφή Επόμενου Slide

1. Πρόσβαση στην ενότητα Χρήστες & Δικαιώματα

2. Προσθήκη Λογαριασμού

3. Εισαγωγή βασικών στοιχείων λογαριασμού (username, password και domain πρόσβασης)

4. Apply – εφαρμογή ρυθμίσεων

5. Προκαθορισμένοι ρόλοι διαχείρισης για ανάθεση σε λογαριασμό

6. Επιπλέον ρυθμίσεις για όρια χρήσης (π.χ. ερωτήματα ανά ώρα, κτλ)

7. Διαγραφή επιλεγμένου χρήστη/λογαριασμού

8. Καρτέλα ορισμού δικαιωμάτων (την χρησιμοποιούμε αφότου δημιουργήσουμε τον χρήστη –

είναι η σημαντικότερη περιοχή ρυθμίσεων – θα τη δούμε στο μεθεπόμενο slide)


Workbench – Διαχείριση Λογαριασμών


Workbench – Ορισμός Δικαιωμάτων

1. επιλογή λογαριασμού

2. προσθήκη αντικειμένων

(databases) στα οποία θα δώσουμε

δικαιώματα – συνήθως επιλέγουμε

μια database από τις υπάρχουσες

στον database server που έχουμε

συνδεθεί

3. δικαιώματα χρήσης δεδομένων

4. δικαιώματα τροποποίησης σε

database schema

5. επιπλέον δικαιώματα

σημαντικό το GRANT OPTION - είναι

το δικαίωμα να μεταβιβάζεις τα

δικαιώματα που έχεις σε τρίτους

Προσοχή στα εξής:

από που μπορεί να συνδεθεί κανείς;

σε ποια database έχει πρόσβαση;

σε ποια στοιχεία της (πίνακες, κτλ) και με τι δικαιώματα;


Επιθεώρηση Δικαιωμάτων (τα screenshots του slide είναι από Workbench v.5.x)

Μπορούμε να επιθεωρήσουμε τα δικαιώματα κάποιου λογαριασμού με την εντολή: SHOW GRANTS FOR <λογαριασμός>

Παράδειγμα: για την κατάσταση

δικαιωμάτων που απεικονίζεται

δεξιά...

...η εντολή:

SHOW GRANTS FOR 'beerUser';

δίνει το ακόλουθο αποτέλεσμα:

Προσέξτε τις επισημασμένες με

βελάκια αντιστοιχίες μεταξύ

γραφικού περιβάλλοντος (πάνω)

και εντολής GRANT (αριστερά)


Παράδειγμα Προσδιορισμού Δικαιωμάτων

Έστω το ακόλουθο υποθετικό SQL ερώτημα:

INSERT INTO Beers(name) SELECT DISTINCT beer FROM Sells

WHERE NOT EXISTS (SELECT name FROM Beers);

το ερώτημα υποτίθεται καταχωρεί στον πίνακα Beers, τις μπύρες που υπάρχουν δηλωμένες

στον Sells ότι πωλούνται, χωρίς όμως να είναι καταχωρημένες στον Beers

δεν έχει νόημα να το δοκιμάσετε στην myBeersDB καθώς οι κανόνες ακεραιότητας

δεδομένων που υπάρχουν σε αυτή δεν θα επιτρέψουν την εκτέλεσή του

δεν μπορεί να υπάρχει τέτοια καταχώριση στον Sells διότι το beer είναι foreign key

δεν μπορεί να καταχωρηθεί μπύρα στον Beers με τιμή NULL στο γνώρισμα manf

Τι δικαιώματα απαιτούνται για να εκτελεστεί αυτό το ερώτημα;

χρειάζονται δικαιώματα SELECT στους πίνακες Sells και Beers

χρειάζονται δικαιώματα INSERT στον πίνακα Beers ή στο γνώρισμα Beers.name

Η ανάθεση δικαιωμάτων πάνω σε συγκεκριμένα γνωρίσματα σχέσεων, κάνει ορατά

μόνο τα συγκεκριμένα γνωρίσματα. Για παράδειγμα, με τα δικαιώματα: GRANT SELECT (bar, beer) ON Sells TO 'beerUser';

ο χρήστης beerUser δεν μπορεί να εκτελέσει το ερώτημα:

SELECT * FROM mybeersdb.sells; //Error 1142: SELECT command denied to user 'beerUser'


Όψεις (Views) και Δικαιώματα (Rights)

Οι όψεις (βλ. slides 06*) αποτελούν ένα σημαντικό εργαλείο για έλεγχο πρόσβασης.

Έστω μια σχέση υπαλλήλων Employees(name,address,salary) στην οποία θέλουμε

να δώσουμε πρόσβαση SELECT αλλά όχι και στο πεδίο salary. Υπάρχουν δύο λύσεις:

A. Παροχή επιλεκτικής πρόσβασης μόνο στα γνωρίσματα που θέλουμε: GRANT SELECT (name, address) ON Employees TO 'someUser';

B. Δημιουργία μια όψης πάνω στα συγκεκριμένα γνωρίσματα:

CREATE VIEW SafeEmployees AS SELECT name, address FROM Employees;

και παροχή δικαιωμάτων SELECT σε αυτή την όψη

GRANT SELECT ON SafeEmployees TO 'someUser';

Για το παράδειγμα, η περίπτωση Α είναι προτιμότερη καθώς η ενημέρωση των

όψεων (λύση Β) κοστίζει υπολογιστικά.

Αυτό δεν αποκλείει όμως την ύπαρξη άλλων περιπτώσεων όπου η δημιουργία όψης

να αποτελεί καλύτερη λύση!


Μεταβίβαση Δικαιωμάτων (Βασικές Έννοιες)

Ένας χρήστης έχει πλήρη δικαιώματα στα αντικείμενα που

ο ίδιος δημιουργεί. Μπορεί αν θέλει να δώσει σε άλλους

χρήστες/λογαριασμούς, δικαιώματα πάνω στα δικά του αντικείμενα!

Σε ακόμη πιο προχωρημένο σενάριο, ένας χρήστης μπορεί να δώσει δικαιώματα σε

αντικείμενα σε άλλον χρήστη και παράλληλα να του δώσει και το δικαίωμα να

μεταβιβάσει τα δικαιώματα που του παραχωρεί!

Το δικαίωμα μεταβίβασης δίνεται με την έκφραση: WITH GRANT OPTION

Παράδειγμα: GRANT UPDATE ON Sells TO sally WITH GRANT OPTION;

Δίνεται δηλαδή στο λογαριασμό sally το δικαίωμα να ενημερώνει τον πίνακα Sells και αυτό

το δικαίωμα είναι μεταβιβάσιμο (η sally μπορεί να το μεταβιβάσει σε άλλον χρήστη/

λογαριασμό)

Σημείωση:Η sally μπορεί επίσης να μεταβιβάσει οποιοδήποτε υποσύνολο δικαιωμάτων που

της έχει παραχωρηθεί. Με βάση το παράδειγμα, μπορεί να παραχωρήσει σε τρίτο λογαριασμό

το δικαίωμα π.χ. να μπορεί να κάνει update ΜΟΝΟ το γνώρισμα price του Sells.


Κατάργηση Μεταβίβασης Δικαιωμάτων

Η κατάργηση (REVOKE) ενός δικαιώματος που έχουμε δώσει σε κάποιον,

δεν συνεπάγεται απαραίτητα την πλήρη αφαίρεση του δικαιώματος

από αυτόν καθώς μπορεί να το έχει και από άλλη πηγή!

Στις εντολές REVOKE μπορούμε να προσθέσουμε τα ακόλουθα:

CASCADE: εκτός από τον αποδέκτη της εντολής REVOKE, τα δικαιώματα τα χάνουν και όσοι

άλλοι τα παρέλαβαν από αυτόν μέσω του μηχανισμού μεταβίβασης δικαιωμάτων, και

μάλιστα σε όσο βάθος και να έγινε αυτό.

Παράδειγμα: REVOKE UPDATE ON Sells FROM sally CASCADE;

RESTRICT: αν το δικαίωμα έχει μεταβιβαστεί από τον αποδέκτη της εντολής REVOKE τότε η

εντολή αποτυγχάνει ως ένδειξη σε αυτόν που δίνει την εντολή ότι πρέπει να "κυνηγήσει" το

δικαίωμα με άλλο τρόπο.


Διαγράμματα Δικαιωμάτων (1/3)

Η μεταβιβάσεις δικαιωμάτων είναι μια αρκετά πολύπλοκη και σύνθετη έννοια.

Ένα μέσο για πιο εποπτική παρακολούθηση των δικαιωμάτων είναι τα διαγράμματα

δικαιωμάτων (grant diagrams – βλ. επόμενα slides).

Ερμηνεία Συμβόλων:

Κόμβοι: χρήστες/δικαιώματα (Προαιρετικά: δικαίωμα μεταβίβασης, ιδιοκτήτης αντικειμένου)

Ακμές XY: o κόμβος Χ έδωσε δικαίωμα (έκανε GRANT) στον Υ

* : υπάρχει δυνατότητα μεταβίβασης (WITH GRANT OPTION)

** : σήμανση owner (ιδιοκτήτη)

Παραδείγματα Συμβολισμών:

AP** : o A είναι owner του P (σημείο εκκίνησης του P) άρα μπορεί και να το μεταβιβάσει

BP* : ο B έχει το P με δικαίωμα μεταβίβασης

CP : ο C έχει το P χωρίς δικαίωμα μεταβίβασης

Αν ο λογαριασμός Α δίνει κάποιο υπο-δικαίωμα Q του P (π.χ. επιτρέπει UPDATE στο

γνώρισμα a μιας σχέσης R, ενώ το P επιτρέπει UPDATE στην R) τότε η ακμή πηγαίνει

σε ένα νέο κόμβο BQ (ή BQ* αν είναι WITH GRANT OPTION)



Παράδειγμα #1

AP** BP* CP*

CP

Ο A μεταβιβάζει το P στον B με δικαίωμα μεταβίβασης (P*).

Ο Α είναι κάτοχος (**) του αντικειμένου στο οποίο το P

είναι κάποιο δικαίωμα.

Ο Α μεταβιβάζει το P στον C (χωρίς δικαίωμα

μεταβίβασης).

Ο B μεταβιβάζει το P στον C με δικαίωμα μεταβίβασης (P*).



Παράδειγμα #2

AP** BP* CP*

CP

O A εκτελεί: REVOKE P FROM B CASCADE;

O Β και ο C (λόγω CASCADE) χάνουν το δικαίωμα P

O C εξακολουθεί να έχει το P (χωρίς δικαίωμα μεταβίβασης

όμως) λόγω της απευθείας ανάθεσης από τον Α

Ακόμη κι αν ο C είχε μεταβιβάσει το P στον B, ο B θα

το έχανε λόγω του CASCADE

08 - Λογαριασμοί και Δικαιώματα σε Database Server

Education

Transcript of 08 - Λογαριασμοί και Δικαιώματα σε Database Server