Dlaczego nie ujawnić klucza podstawowego

W mojej edukacji powiedziano mi, że wadliwym pomysłem jest udostępnianie użytkownikowi rzeczywistych kluczy podstawowych (nie tylko kluczy DB, ale wszystkich głównych akcesorów).

Zawsze myślałem, że to problem z bezpieczeństwem (ponieważ osoba atakująca może próbować czytać rzeczy, które nie są ich własnością).

Teraz muszę sprawdzić, czy użytkownik może mimo to uzyskać dostęp, więc czy kryje się za tym inny powód?

Ponadto, ponieważ moi użytkownicy i tak muszą uzyskać dostęp do danych, muszę mieć gdzieś pomiędzy nimi klucz publiczny dla świata zewnętrznego. Teraz, gdy klucz publiczny ma takie same problemy jak klucz podstawowy, prawda?

W każdym razie pojawiła się prośba o przykład, dlaczego to zrobić, więc oto jeden. Należy pamiętać, że pytanie ma dotyczyć samej zasady, nie tylko jeśli ma zastosowanie w tym przykładzie. Odpowiedzi dotyczące innych sytuacji są wyraźnie mile widziane.

Aplikacja (internetowa, mobilna), która obsługuje aktywność, ma wiele interfejsów użytkownika i co najmniej jeden automatyczny interfejs API do komunikacji międzysystemowej (np. Dział księgowości chce wiedzieć, ile obciążyć klienta na podstawie tego, co zostało zrobione). Aplikacja ma wielu klientów, więc oddzielenie ich danych (logicznie dane są przechowywane w tej samej bazie danych) jest obowiązkowym elementem systemu. Każde żądanie zostanie sprawdzone pod kątem ważności bez względu na wszystko.

Aktywność jest bardzo szczegółowa, dlatego jest połączona w jakimś obiekcie kontenerowym, nazwijmy to „Zadaniem”.

Trzy przypadki użycia:

1. Użytkownik A chce wysłać użytkownika B do jakiegoś Zadania, więc wysyła mu link (HTTP), aby wykonać tam Aktywność.
2. Użytkownik B musi wyjść na zewnątrz budynku, aby otworzyć zadanie na swoim urządzeniu mobilnym.
3. Księgowość chce obciążyć klienta za zadanie, ale korzysta z zewnętrznego systemu księgowego, który automatycznie ładuje zadanie / działanie za pomocą kodu odnoszącego się do interfejsu API REST aplikacji

Każda z przypadków użycia wymaga (lub staje się łatwiejsza, jeśli) agenta, aby mieć adresowalny identyfikator dla zadania i działania.

Ponadto, ponieważ moi użytkownicy i tak muszą uzyskać dostęp do danych, muszę mieć gdzieś pomiędzy nimi klucz publiczny dla świata zewnętrznego.

Dokładnie. Weźmy bezpaństwowego HTTP, który w przeciwnym razie nie wiedziałby, jakiego zasobu powinien zażądać: ujawnia identyfikator pytania 218306w adresie URL. Być może zastanawiasz się, czy ujawniony identyfikator może być przewidywalny ?

Jedyne miejsca, w których usłyszałem negatywną odpowiedź, posłużyły się uzasadnieniem: „Ale mogą zmienić identyfikator w adresie URL!” . Użyli więc identyfikatorów GUID zamiast implementacji właściwej autoryzacji.

Mogę sobie wyobrazić jedną sytuację, w której nie chcesz, aby twoje identyfikatory były przewidywalne: pozyskiwanie zasobów. Jeśli masz witrynę publicznie udostępniającą pewne zasoby, w której inni mogą być zainteresowani, i hostujesz je w podobny sposób /images/n.jpglub /videos/n.mp4gdzie njest tylko rosnąca liczba, każdy, kto patrzy na ruch do i z Twojej witryny, może zebrać wszystkie twoje zasoby.

Tak więc, aby bezpośrednio odpowiedzieć na twoje pytanie: nie, nie jest źle „bezpośrednio” ujawniać identyfikatory, które mają znaczenie tylko dla twojego programu, zwykle jest to nawet wymagane, aby Twój program działał poprawnie.

Nie powinieneś go ujawniać, ponieważ ludzie, którzy go zobaczą, zaczną używać go jako „numeru konta”, którym NIE jest. Na przykład dla mojego konta bankowego wiem, jaki jest mój numer konta. Zapamiętałem go, używam go przez telefon z obsługą klienta, używam go do wypełniania formularzy dla innych banków w celu dokonywania przelewów, dokumentów prawnych, mojej usługi automatycznych płatności itp. Nie chcę to zmienić. Z drugiej strony, klucz podstawowy (dla mojego konta) nie wiem ani nie widzę.
System, który go przechowuje, zmienia się z biegiem lat z jednego systemu do drugiego, poprzez fuzje banków, modernizacje i wymiany systemów itp
. Klucze podstawowe mogą ulec zmianie w wyniku niektórych z tych przekształceń, więc jeśli nigdy nie zostały ujawnione, spisane lub zapamiętane przez każdego zwykłego użytkownika, który „
Klucze bez znaczenia biznesowego są często nazywane kluczami zastępczymi i często (choć nie zawsze) są używane jako klucze podstawowe.

przy okazji, dzieje się tak nawet wewnętrznie, gdy ludzie budują interfejsy i programy, które niewłaściwie używają i ujawniają klucze podstawowe i sprawiają, że stają się częścią takich systemów, zamiast robić tylko jedną rzecz - jednoznaczne wewnętrzne identyfikowanie rekordu bazy danych. Tak naprawdę nauczyłem się tego przez 6 lat pracy w systemie hurtowni danych w szpitalu.

Ponieważ klucze podstawowe są szczegółami implementacji.

W przypadku migracji baz danych klucze podstawowe mogą ulec zmianie z powodu kolejności wstawiania, usuwania starych rekordów ... z kilku różnych powodów. Jeśli przeprowadzasz migrację platform baz danych , możesz w ogóle nie mieć rzeczywistego klucza podstawowego. Ujawnienie PK powyżej warstwy dostępu do danych jest nieszczelną abstrakcją, z którą wiążą się wszystkie obawy związane z łączeniem.

To jest kombinacja odpowiedzi pozostałych (czyli tego, czego się nauczyłem). Jeśli masz ochotę głosować za tym, powinieneś przynajmniej głosować za jednym z nich, tak jak oni wykonali swoją pracę. Jeśli jesteś bardziej zainteresowany, przeczytaj pozostałe odpowiedzi.

Nie należy ujawniać klucza podstawowego bazy danych, ale zamiast tego należy użyć klucza zastępczego

1. Jeśli chcesz, aby użytkownicy mogli zapamiętać (przynajmniej trochę) lub rozpoznać identyfikator wpisu. ( Graystone28s Odpowiedź )
2. Jeśli chcesz planować z wyprzedzeniem i wziąć pod uwagę, że możesz zmienić systemy (bazy danych lub inne), które prawdopodobnie zmienią twoje PK. ( Odpowiedź Telastyns )
3. Jeśli chcesz zapewnić swoim użytkownikom spójny sposób uzyskiwania dostępu do danych, które nie ulegną zmianie, nawet jeśli Twoja firma zmieni właściciela, a dane zostaną przeniesione w tysiące do innego systemu. ( Odpowiedź Michaela Durranta )
4. Jeśli twoje PK jest przewidywalne (jak sekwencja), twój system może mieć problemy z pozyskiwaniem zasobów. ( Odpowiedź CodeCasters ) Ma to zastosowanie tylko wtedy, gdy twój system ma informacje, które warto zebrać i które są dostępne dla każdego lub przynajmniej dla kogoś, kto jest zainteresowany zbieraniem.

Uwaga: Utworzony klucz powinien być (w pewnym sensie ) zrozumiały dla człowieka ( odpowiedź Sqlvogels ).

Jeśli twój system nie potrzebuje 1. do 4., nie ma powodu, aby nie używać baz danych PK jako publicznego identyfikatora (kilka odpowiedzi). Również bezpieczeństwo nie jest tutaj problemem (kilka odpowiedzi).

Jednym z powodów, które znalazłem, był czas, kiedy użytkownicy końcowi żądali, aby ich identyfikator coś znaczył (na przykład posiadanie prefiksu lub wskaźnika roku, w którym został przyjęty). Zmiana PK jest trudna, ale surogat jest znacznie łatwiejszy.

Twój klucz podstawowy prawdopodobnie będzie czymś, o co chcesz zaindeksować bazę danych ze względów wydajnościowych, a z czasem z przyczyn technicznych możesz zmienić go na przykład z numeru na przewodnik ... po prostu nie wiesz, z jakich powodów nowe technologie lub wiedza może cię poprowadzić. Twój pk to techniczny element danych, klucz publiczny służy do konsumpcji przez użytkowników końcowych.

W przypadku większości aplikacji bardzo ważne jest, abyś udostępniał klucze użytkownikom. Aby skutecznie korzystać z systemu informatycznego, użytkownicy tego systemu będą zwykle potrzebowali sposobu na identyfikację zawartych w nim informacji i powiązanie tych informacji z czymś na świecie poza bazą danych. W kategoriach relacyjnych baz danych te identyfikatory są kluczami.

Jednym z często używanych wzorców projektowych jest stworzenie dodatkowego, czysto „technicznego” klucza dla tabel bazy danych jako sposobu abstrakcji. Na przykład, aby zapewnić stabilny (względnie niezmienny) klucz, w przypadku którego klucz alternatywny może ulec zmianie. Takie klucze techniczne zwykle nie są narażone na ryzyko dla użytkowników końcowych, ponieważ podważa to zamierzoną abstrakcję wymagań użytkownika. Nie ma to nic wspólnego z bezpieczeństwem.

Problem / nieporozumienie zawarte w twoim pytaniu wynika z niewłaściwego użycia terminu klucz podstawowy . Klucz podstawowy jest tylko jednym z kilku kluczy „kandydujących” (kilka możliwych identyfikatorów w tabeli bazy danych). Klucz podstawowy niekoniecznie wymaga zasadniczo innej właściwości niż jakikolwiek inny klucz, dlatego twierdzenia i zasady projektowania, które dotyczą konkretnie kluczy podstawowych, a nie innych kluczy, są zawsze podejrzane i często błędne.

Biorąc pod uwagę, że zwykle będziesz musiał ujawnić klucz użytkownikowi, jaki powinien być ten klucz? Staraj się, aby klucze były znane, proste i stabilne. Znajomość i prostota sprawiają, że klucze są łatwe do odczytania i zapamiętania oraz pomogą uniknąć błędów wprowadzania danych. Stabilność oznacza rzadkie kluczowe zmiany, co pomaga również uniknąć możliwości błędnej identyfikacji.

Wynika to z komentarza CodeCaster do odpowiedzi Greystone28. To przykład tego, co mówisz:

Udostępniam numer faktury, który ma znaczenie i może być zmieniany przez klienta, ale ujawniam też identyfikator faktury, którego mój kod używa do jednoznacznej identyfikacji faktury. Nie musisz (a częściej nie chcesz) pozwolić, aby klucz użytkownika był kluczem do przechowywania. To pytanie dotyczy tego drugiego.

Jaki cel w Twojej aplikacji ma wyświetlenie InvoiceID?

Przez ujawnienie, zakładam, że masz na myśli, że użytkownik może to zobaczyć. Udostępniaj go tylko wtedy, gdy użytkownik potrzebuje go do korzystania z Twojej aplikacji. Może być wykorzystany przez wsparcie techniczne lub niektóre czynności administracyjne. Pracowałem z kilkoma aplikacjami, które to robią. Ułatwia to wsparcie, gdy znam konkretny rekord.

Jest to zupełnie normalne, że istoty mają unikalny identyfikator, który jest wystawiony na świat zewnętrzny. W przypadku niektórych obiektów może być możliwe znalezienie identyfikatora, który faktycznie ma znaczenie (na przykład numer faktury), ale w przypadku innych takich identyfikatorów nie ma i dlatego należy je wygenerować.

Ze względu na spójność i czytelność uważam, że dobrą praktyką jest, aby wszystkie podmioty w systemie używały tego samego typu i nazwy dla swojego identyfikatora. Zwykle ten identyfikator byłby narażony ( <type> getId()) w jakiejś abstrakcyjnej klasie bazowej.

Z tego samego powodu każda usługa w systemie (na przykład usługa fakturowania) powinna zapewniać identyczne metody dostępu do podmiotów według ich identyfikatora. Zwykle ta metoda ( findById(<type> id)) byłaby dziedziczona z ogólnego interfejsu usługi lub klasy bazowej.

Ten identyfikator nie musi być kluczem podstawowym encji, ale może nim być. Jedyne, co trzeba zapewnić, to to, że strategia generowania klucza generuje racjonalnie unikalne identyfikatory (niekoniecznie uniwersalnie unikalne, ale przynajmniej w systemie).

Jeśli system zostanie później migrowany (duża, o ile mi wiadomo) do innej bazy danych, wówczas nie jest problemem użycie innej strategii (nie opartej na kluczach podstawowych) do tworzenia identyfikatorów, o ile strategia jest zgodna z oryginalną.

Jest tam klucz podstawowy, podobnie jak uchwyt do krotki (rekord, wiersz), do którego próbujesz uzyskać dostęp jako programista. Jest również używany w integralności referencyjnej (ograniczenia klucza obcego), i może ma też jeden lub więcej przypadków użycia.

Zasadniczo nie ma nic złego w udostępnianiu go użytkownikom, a nawet hakerom. Ponieważ nie znam ataku, który wykorzystuje na przykład klucz podstawowy.

Ale jeśli chodzi o bezpieczeństwo, mamy wiele zasad (które akceptujemy i nie zatwierdzamy) i musimy je przestrzegać:

1. Zasada przywileju najmu
2. Bezpieczeństwo dzięki niejasnościom

I kilka innych zasad. Mówią w istocie, że:

Jeśli nie musisz ujawniać swoich danych, dlaczego w ogóle miałbyś to robić?