Καλημέρα,

Τις τελευταίες 2-3 μέρες απασχολεί το μυαλό μου (...σιγά μην καείς!) ο σχεδιασμός μιας βάσης δεδομένων πολλαπλών χρηστών. Η βάση θα στηθεί σε SQL Server Express, αλλά δεν είναι και πολύ σημαντικό αυτό γιατί με ενδιαφέρει περισσότερο η θεωρία γύρω από το όλο concept.

Ως νέος προγραμματιστής εχω ασχοληθεί (δεν είμαι και κανένας guru...) με το θέμα της ασφαλείας των βάσεων. Αυτό που έχω παρατηρήσει κατα κόρον είναι το εξής "σχεδιαστικό φαινόμενο". Ο χρήστης (μέσω της εκάστοτε εφαρμογής) κάνει login στη βάση ως administrator (τα στοιχεία του connection string) και η εφαρμογή ελέγχει έναν πίνακας που έχει δημιουργήσει ο προγραμματιστής και περιέχει usernames και passwords. Αν βρει τα στοιχεία του χρήστη εκεί προχωράει, αλλιώς δεν του επιτρέπει να συνεχίσει. Ούτε roles ούτε τίποτα. Δεν ξέρω, αλλά μου φαίνεται ότι αυτό το μοντέλο ασφαλείας είναι λίγο "προχειροδουλειά".

Μελέτησα λίγο το ζήτημα και "ανακάλυψα" την έννοια του Role (...χμμ). Από ότι καταλαβαίνω (διορθώστε αν κάνω λάθος) ο administrator δημιουργεί ένα κανούργιο login στη βάση (με SQL Authentication - username και password) και εντάσσει το λογαριασμό αυτό σε κάποιο Role, αναλόγως τα δικαιώματα που θέλει να δώσει στον εκάστοτε χρήστη.

Ωραία, καλά ως εδώ (?). Έστω οτι εγώ θέλω η εφαρμογή μου να είναι προσβάσιμη μέσω του διαδικτύου. Ας πούμε ότι σε κάποια φάση θα έχω 100 χρήστες με Usernames και Passwords που θα τους επιτρέπεται μόνο ένα SELECT σε ένα πίνακα. Εγώ τώρα τι κάνω. Φτιάχνω ένα Role που να δίνει δικαιώματα για το συγκεκριμένο SELECT και 100 login λογαρισμούς τους οποίους τους εντάσσω σε αυτό το Role. Και αν οι χρήστες γίνουν 1000. Θα έχω 1000 login λογαριασμούς?!

Δεν ξέρω αλλά αυτό μου ακούγεται κάπως περίεργο και είμαι σίγουρος πως κάτι δεν έχω καταλάβει καλά, ή κάτι μου ξεφεύγει.

Παρακαλώ, οποιοδήποτε σχόλια θα ήταν χρήσιμο.

DeClen wrote:

Μελέτησα λίγο το ζήτημα και "ανακάλυψα" την έννοια του Role (...χμμ). Από ότι καταλαβαίνω (διορθώστε αν κάνω λάθος) ο administrator δημιουργεί ένα κανούργιο login στη βάση (με SQL Authentication - username και password) και εντάσσει το λογαριασμό αυτό σε κάποιο Role, αναλόγως τα δικαιώματα που θέλει να δώσει στον εκάστοτε χρήστη. Ωραία, καλά ως εδώ (?). Έστω οτι εγώ θέλω η εφαρμογή μου να είναι προσβάσιμη μέσω του διαδικτύου. Ας πούμε ότι σε κάποια φάση θα έχω 100 χρήστες με Usernames και Passwords που θα τους επιτρέπεται μόνο ένα SELECT σε ένα πίνακα. Εγώ τώρα τι κάνω. Φτιάχνω ένα Role που να δίνει δικαιώματα για το συγκεκριμένο SELECT και 100 login λογαρισμούς τους οποίους τους εντάσσω σε αυτό το Role. Και αν οι χρήστες γίνουν 1000. Θα έχω 1000 login λογαριασμούς?!

εγώ το βλέπω ως εξής: ο επισκέπτης μέσω web είναι έτσι κι αλλιώς αναξιόπιστος. Πρέπει λοιπόν να φτιάξω ένα χρήστη στη βάση που να έχει τα δικαιώματα που χρειάζονται όλοι οι επισκέπτες μαζί και μόνο αυτά. Στο connection string βάζεις αυτόν το username της βάσης. Αν θες ένα φάκελο με σελίδες διαχείρισης βάζεις password και εκεί δηλώνεις άλλο connection string  με επιπλέον δικαιώματα.

Οι χρήστες μετά φτιάχνουν χρήστες της εφαρμογής (membership ή κάτι άλλο)

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

Η εφαρμογή σου βλέπει τη βάση μέσω του χρήστη που έχεις στο connection string (1 συνήθως), ασχέτως ποιος είναι ο χρήστης της εφαρμογής.

Aπό κει και πέρα, όποιος και να συνδεθεί θα εκτελέσει queries σαν να ήτανε ο χρήστης του connection string. Δεν χρειάζεται να βάλεις 100 λογαριασμούς στη βάση και να τοςυ δώσεις ρόλο. Το κάνεις μόνο για έναν.

---

Simple Photography

Παιδιά ξέρω ότι άλλο ο χρήστης της εφαρμογής και άλλος ο χρήστης της βάσης. Απλά θέλω να ξέρω το μέγιστο βαθμό που μπορούν να συσχετιστούν αυτοί οι δύο (sorry αν τα λέω λίγο μπερδεμένα, αλλά έχω μπερδευτεί...).

Να δώσω ένα παράδειγμα.

Έχουμε την βάση και την εφαρμογή. Φτιάχνουμε στην βάση ένα login με δικαιώματα "κάνε τα πάντα εκτός από DROP"

Η εφαρμογή ζητάει username και password για τον καθέ application user. Έχουμε το connection string βασιζόμενο στον database user που φτιάξαμε παραπάνω. Τα username και passwords των application users - ώστε να αποφανθεί η εφαρμογή για το αν ο Χ χρήστης πρέπει να προχωρήσει ή να φάει άκυρο - που είναι? Σε κάποιον πίνακα που φτιάξαμε στη βάση?

Ωραία έστω ότι είναι έτσι.

Εγώ θέλω ο application user THE_MIGHTY_USER να μπορεί να κάνει τα πάντα στη βάση (εννοείτε εκτός απο το drop αφού ούτως ή άλλως αυτό του το απαγορεύει το connection string). Θέλω όμως ο χρήστης TI_EINAI_DVD να μπορεί να βλέπει μόνο ένα view ενώ οι χρήστες KATI_XERW και EGW_XERW_PIO_POLLA να μπορεί να κάνει και update 2 πίνακες.

Πως ενεργούμε στην παραπάνω περίπτωση;

OK κατάλαβα τι λές.

Και πάλι θα είναι πιο χρήσιμο να φτιάξεις ρόλους και όχι χρήστες 1-1, μιας και συνήθως αντιμετωπίζεις τους χρήστες σαν σύνολα στην εφαρμογή. Πχ THE_MIGHTY_USER, KATI_XERW, EGW_XERW_PIO_POLLA,TI_EINAI_DVD και να φτιάξεις έναν χρήστη στη βάση για κάθε ρόλο.

Από κει και πέρα θα πρέπει να προσέξεις και πως το υλοποιείς αυτό γιατί ίσως έχεις προβλήματα σε επίπεδο session.

Αντιμετώπισα και γω κάτι παρόμοιο πρόσφατα σε .ΝΕΤ 2.0, όπου ανάλογα το χρήστη έπρεπε να αλλάζω connection string. Ρίξε μια ματιά εδώ

http://www.dotnetzone.gr/cs/forums/22864/ShowPost.aspx#22864

Aν χρησιμοποιείς παλιό καλό κώδικα, μπορείς να κάνεις την αλλαγή του connection string στην κλάση που φτιάχνεις το connection.

Τέλος, καλό θα είναι όπως είπε πιο πάνω και ο agmarios, καλό θα είναι να αντιμετωπίζεις κάθε χρήστη σαν επικίνδυνο, οπότε minimum access όπου μπορείς.

---

Simple Photography

Οντως δεν είναι χρήστες, είναι ρόλοι. Φαντάσου ένα "ζωντανό" "ανοιχτό" web σύστημα οπου π.χ. οι χρήστες εγγράφονται κατά βούληση. Τι κάνεις; Για κάθε νέο account φτιάχνεις ένα χρήστη στον SQL Server;

Η απάντηση είναι οχι. Ακόμα και αν δεν θέλεις να παίξεις με ρόλους, μια λύση είναι να δημιουργήσεις ΕΝΑ χρήστη στον SQL Server με ακριβώς τα προνόμια που θέλεις να έχουν ΟΛΟΙ οι web χρήστες σου και να τους κάνεις map όλους εκει πάνω.

Αν θέλεις να έχεις "ιδιαίτερους" χρήστες με περισσότερα προνόμια σε επίπεδο SQL Server (γιατι, ας μην ξεχνάμε, τα προνόμια μπορεί να εκχωρούνται και από την πλευρά της εφαρμογής και όχι αναγκαστικά της database), τότε χρησιμοποιείς έναν άλλο SQL χρήστη για αυτό το λόγο.

Σε παλαιότερη υλοποίηση ενός Web Portal σε ASP 3.0 (η φιλοσοφία όμως δεν αλλάζει), ειχα 2 χρήστες. Εναν με read-only access σε ορισμένους πίνακες (τυπικά, γίνονταν εκεί map όλοι οι χρήστες που έμπαιναν για να δουν το site) και έναν με read-write access (τυπικά, ο administrator η / και περιπτώσεις οπου ο χρήστης συμπλήρωνε μια φόρμα και γραφόταν κάτι στην database). Δυο SQL χρήστες, δυο connection strings, χρήση αναλόγως περίπτωσης. Αρχαία υλοποίηση, αλλά έτσι δουλεύει μέχρι σήμερα.

---

Σωτήρης Φιλιππίδης

DotSee Web Services

cap wrote:

Οντως δεν είναι χρήστες, είναι ρόλοι. Φαντάσου ένα "ζωντανό" "ανοιχτό" web σύστημα οπου π.χ. οι χρήστες εγγράφονται κατά βούληση. Τι κάνεις; Για κάθε νέο account φτιάχνεις ένα χρήστη στον SQL Server; Η απάντηση είναι οχι. Ακόμα και αν δεν θέλεις να παίξεις με ρόλους, μια λύση είναι να δημιουργήσεις ΕΝΑ χρήστη στον SQL Server με ακριβώς τα προνόμια που θέλεις να έχουν ΟΛΟΙ οι web χρήστες σου και να τους κάνεις map όλους εκει πάνω. Αν θέλεις να έχεις "ιδιαίτερους" χρήστες με περισσότερα προνόμια σε επίπεδο SQL Server (γιατι, ας μην ξεχνάμε, τα προνόμια μπορεί να εκχωρούνται και από την πλευρά της εφαρμογής και όχι αναγκαστικά της database), τότε χρησιμοποιείς έναν άλλο SQL χρήστη για αυτό το λόγο.

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

Καλημέρα, συμφωνώ απόλυτα με τον cap.

Σε γενικές γραμμές όταν χρειάζεται να υπάρχει ελεγχόμενη πρόσβαση, στις εφαρμογές που αναπτύσω, επιλέγω να φτιάξω ένα login με τα βασικά δικαιώματα. Ο έλεγχος ανήκει στον κώδικα, τι θα βλέπει/κάνει ο κάθε χρήστης της εφαρμογής. Όταν χρειάζεται ποιο σοβαρή δουλειά απλά κάνω relogin με administrative rights και την κάνω.

---

System crashed: Coffee_Cup.Content is null
Please assign coffee to Content and press any key to continue and any other key to cancel

Καλέας Κων/νος