Czy kiedykolwiek dobrą praktyką jest używanie odrębnego konta bazy danych dla każdego użytkownika aplikacji?

Aplikacje, do których jestem przyzwyczajony, są oparte na serwerze i używają jednego konta bazy danych dla wielu użytkowników, a kod aplikacji kontroluje, co użytkownik może zrobić, lub dla jednego użytkownika.

Czy są jakieś udane złożone aplikacje biznesowe, w których każda osoba potrzebuje własnego konta bazy danych, a serwer bazy danych polega na egzekwowaniu zasad polityki dotyczących tego, co każdy użytkownik powinien mieć prawo, a co nie?

Myślę o aplikacjach, w których wiele osób przyczynia się do informacji w jednej bazie danych i może uzyskiwać dostęp do informacji przechowywanych przez inne osoby - np. Współpracowników w organizacji, którzy wszyscy potrzebują dostępu do danych klientów.

Czy jest też nazwa tego typu konfiguracji?

Jeśli potrzebujesz naprawdę ścisłej kontroli egzekwowanej na poziomie danych. Na przykład obszerny audyt. Kontrola nie jest zbyt dobra, jeśli kilku użytkowników korzysta z tego samego konta. Jeśli masz użytkowników, którzy potrzebują bezpośredniego dostępu do bazy danych.

Jeśli bezpieczeństwo jest tak ścisłe, zazwyczaj nawet nie ujawniasz bezpośrednio bazy danych. Masz usługę, a klient musi uzyskać dane z usługi.

W aplikacji internetowej baza danych (np. Port 1433) zazwyczaj nie jest narażona bezpośrednio, więc masz pewien poziom bezpieczeństwa. Nawet jeśli aplikacja internetowa uzyskuje bezpośredni dostęp do bazy danych, użytkownicy nadal nie mają bezpośredniego dostępu do bazy danych.

Jeśli login i hasło znajdują się w aplikacji klienckiej, można je zhakować. Jeśli domena może korzystać ze zintegrowanych zabezpieczeń.

W bazie danych możesz mieć całkiem niezłą kontrolę. Ale kontrola na poziomie wiersza to trochę pracy. Baza danych nie jest dobrym narzędziem do reguł biznesowych. Reguły biznesowe i szczegółowe zabezpieczenia są zwykle egzekwowane na poziomie aplikacji.

Możesz mieć tryb mieszany, w którym administratorzy korzystają z niektórych procedur przechowywanych i chcesz śledzić, który administrator. I możesz przyznać dostęp tylko do odczytu użytkownikom, którzy generują raport bezpośrednio.

Wyzwanie polega na tym, że dostępem do bazy danych zarządza abstrakcja. Zamiast użytkowników łączących się jak oni, w zasadzie przyjmują tożsamość jakiejś uogólnionej roli aplikacji. Nie tylko tracisz widoczność poszczególnych połączeń, ale także tracisz szczegółowość definiowania różnych rodzajów dostępu dla wszystkich indywidualnych użytkowników.

Głównym powodem zastosowania tego podejścia jest prostota. Wiele aplikacji zaprojektowano tak, aby użytkownik aplikacji nie miał wiedzy o bazie danych. Naprawdę tego nie potrzebują, zwłaszcza jeśli aplikacja zarządza własnym bezpieczeństwem wewnętrznym. Większość indywidualnych użytkowników nigdy nie łączy się bezpośrednio z bazą danych, więc zdefiniowanie dla nich jawnego loginu nie jest konieczne.

Jedynym momentem, w którym powinieneś rozważyć umożliwienie bazie danych zarządzania bezpieczeństwem, jest to, że masz użytkowników, którzy będą się łączyć bezpośrednio z bazą danych. Oznacza to, że omijają twoją aplikację i nie mogą już same egzekwować bezpieczeństwa. Zaletą jest to, że możesz bardziej szczegółowo określić swoje bezpieczeństwo. Wadą jest wyższy koszt zarządzania użytkownikami i ich uprawnieniami.

Jeśli czujesz potrzebę tego rodzaju dostępu, chcesz użyć kontroli dostępu opartej na rolach . Należy zdefiniować role na podstawie tego, jakie uprawnienia są potrzebne w bazie danych, a następnie pogrupować poszczególnych użytkowników w ramach tych ról. Zapewnia to lepszą kontrolę i kontrolę nad modelem bezpieczeństwa, który może szybko wymknąć się spod kontroli podczas zarządzania bezpośrednim dostępem.

Istnieje hybrydowe podejście do tego. Jeśli chcesz, aby twoje zabezpieczenia były częściowo modyfikowane przez bazę danych, możesz utworzyć wielu użytkowników aplikacji, z których każdy jest zdefiniowany według ich roli, i wyraźnie przyznać dostęp tym użytkownikom na podstawie roli, którą pełnią. Oznacza to, że możesz wykorzystać silnik bazy danych do niektórych modeli bezpieczeństwa, ale nadal musisz mieć pewne zarządzanie w aplikacji. Zwiększa złożoność modelu użytkownika aplikacji, ale zapewnia większą szczegółowość różnych używanych loginów.

Powinieneś zacząć egzekwować bezpieczeństwo na najbardziej szczegółowym poziomie tak szybko, jak to możliwe. Role pomagają w tym względzie - zapewnianie ludziom dostępu do wielu stolików jednocześnie nie jest koszmarem.

Jedno konto dla wszystkich jest doskonałym źródłem pytań tutaj i gdzie indziej - „rekord x został usunięty, jak mogę dowiedzieć się, kto to zrobił?” - odpowiedź brzmi: nie możesz - bez indywidualnych kont i audytu .

Przez „audytowanie” rozumiem, że chociaż bardzo dobrze jest mieć konto dla wszystkich, nie oznacza to, że masz prawdziwe bezpieczeństwo. Jeśli, powiedzmy, rekord w tabeli HR zostanie usunięty, wszystko, co możesz powiedzieć, to że ktoś z dostępem do tabeli HR to zrobił - to x liczba osób.

Potrzebujesz w systemie wyzwalaczy, które rejestrują działania, aby móc wyśledzić indywidualny poziom, który wykonał akcję X (chyba że masz RDBMS, taki jak Oracle, gdzie można to zrobić automatycznie).

W każdym razie zawsze powinieneś możliwie jak najszybciej uszczegółowić swoje bezpieczeństwo - dać ludziom dostęp do tabel tylko na podstawie „potrzeby wiedzieć”. I zawsze dołączaj sygnatury czasowe akcji do tabel - ludzie często podają swoje identyfikatory innym osobom - jeśli możesz powiedzieć: „Jimmy, byłeś jedyny w biurze o 17:49 ...” - znowu, to nie ironia, tylko kolejna strzała w kołczanie.

Może jeśli dałeś nam swój RDBMS, możesz uzyskać porady bardziej szczegółowe / odpowiednie dla twojej sytuacji?

Tak to jest. Łączenie się z bazą danych z aplikacji jako pojedynczy potężny użytkownik stanowi naruszenie zasady najmniejszych uprawnień . Jest to główna przyczyna większości ataków typu SQL Injection.

Zwykle dzieje się tak z powodu niewiedzy, ze względu na prostotę, a czasem ze względu na wydajność.

Bazy danych są często długotrwałe i używane przez wiele aplikacji jednocześnie i z czasem. Możesz oszczędzać zasoby, centralizując kontrolę dostępu w bazie danych zamiast w wielu aplikacjach.

Chcesz wybrać serwer db, który obsługuje Row Security, Column Security oraz Personifikacja / Proxy Authentication (który obsługuje prawdziwych użytkowników db + pule połączeń)

Byłoby to również bezpieczniejsze dla aplikacji opartych na „wtyczkach”, takich jak Wordpress, gdzie trudno jest uniknąć wstrzyknięć SQL z powodu niewykwalifikowanych autorów wtyczek. Każda wtyczka otrzymuje login db, zamiast aplikacji jako całości.