Czy powinienem wyraźnie DENY UPDATE do kolumn, które nie powinny być aktualizowane?

Jestem przyzwyczajony do pracy w bardzo bezpiecznych środowiskach, więc projektuję swoje uprawnienia w bardzo drobnym stopniu. Jedną rzeczą, którą zwykle robię, jest jawne DENYużytkownicy możliwości UPDATEkolumn, które nigdy nie powinny być aktualizowane.

Na przykład:

create table dbo.something (
    created_by varchar(50) not null,
    created_on datetimeoffset not null
);

Te dwie kolumny nigdy nie powinny być zmieniane po ustawieniu wartości. Dlatego wyraźnie bym DENYim UPDATEpozwolił.

Niedawno podczas spotkania zespołu programista podniósł kwestię, że logika zapewniająca, że ​​pola nigdy nie będą aktualizowane, powinna znajdować się w warstwie aplikacji, a nie w warstwie bazy danych na wypadek, gdyby „z jakiegoś powodu musieli zaktualizować wartości”. Dla mnie to brzmi jak typowa mentalność deweloperów (wiem, kiedyś byłem taki!)

Jestem starszym architektem w mojej firmie i zawsze działałem zgodnie z zasadą minimalnej liczby uprawnień wymaganych do uruchomienia aplikacji. Wszystkie uprawnienia są regularnie kontrolowane.

Jaka jest najlepsza praktyka w tym scenariuszu?

Argument nie ma sensu. Zawsze chcę, aby elementy sterujące i ograniczenia były jak najbliżej danych. Umieszczenie go w warstwie aplikacji oznacza, że ​​wpływa tylko na osoby korzystające z warstwy aplikacji, a także zakłada, że kod będzie wolny od błędów, a bezpieczeństwo wokół tych ścieżek kodu będzie kuloodporne. To są duże założenia.

Jeśli absolutnie trzeba je zaktualizować, może to zrobić osoba, na którą jawnie DENYnie ma wpływu, lub osoba ta może zostać tymczasowo przeniesiona do roli, która nie ma wpływu, lub DENYmoże zostać tymczasowo usunięta. Są to rzeczy łatwe dla ciebie, jako DBA, do skonfigurowania audytu. W aplikacji? Nie tak bardzo.

Całkowicie zgadzam się z @Aaron w technicznym aspekcie tego.

Poza tym powiedziałbym, jeśli chodzi o najlepsze praktyki:

1. Biorąc pod uwagę, że zadaniem / odpowiedzialnością DBA jest ochrona danych, domyślnym podejściem powinno być zrobienie tego, tak jak DBA uważa za stosowne, i wymaga solidnego uzasadnienia biznesowego do dokonania zmiany. Hipotetyczny-przyszły-potencjał-nieco-możliwy-pod warunkiem-pewnych-warunków-że-będzie-burza mózgów-później-i-potwierdzony-po-tym-ale-może-zmieniony-później-lub-może-nigdy -prawdopodobnie zdarzył się powód (tj. „z jakiegoś powodu”) wydaje się nieco lekceważący z uzasadnienia, szczególnie gdy temat zmienia standard / praktykę firmy.

2. Nigdy nie ufaj nikomu, kto chce wprowadzić zmiany w czymś, co nigdy nie powinno się zmienić ;-), (tym bardziej, jeśli nawet nie wie, dlaczego chce).

3. Poinformuj programistę, że może dodać taką logikę do kodu aplikacji, aby zapobiec tym aktualizacjom. Ale także, że nie zamierzasz usunąć DENY. Jeśli / kiedy dzień kiedykolwiek nadejdzie (i tomoże nieprawdopodobnie nie), że ktoś napotka błąd podczas próby aktualizacji jednej z tych kolumn, wtedy możesz porozmawiać o tym, czy usuniesz tę DENY, co będzie wymagało rzeczywistego, solidnego uzasadnienia, dlaczego ktoś aktualizuje tę wartość w pierwsze miejsce.

   Chodzi o to, że ludzie powinni spędzać czas na prawdziwym uzasadnieniu biznesowym. Czas jest bardzo poszukiwany, ale brakuje go, więc ty (i wszyscy inni) masz ważniejsze rzeczy do zrobienia niż zmiana systemu w oparciu o czyjąś opinię. Zawsze będzie wiele opinii (spacje kontra tabulatory, ktoś?) I możesz spędzić lata zmieniając to w tę iz powrotem, jeśli ten programista odejdzie i zostanie zastąpiony przez osobę, która zdecydowanie sprzeciwia się możliwości aktualizowania tych pól. Jeśli żaden klient nie prosi o to (lub coś, co tego wymaga) i nie ma wymiernej korzyści (nawet opóźnionej korzyści, takiej jak spłacenie długu technicznego, co jest trudne do wykazania ROI, ale jest bardzo opłacalne, biorąc pod uwagę, że szanse na to, że spędzony czas nie przyniesie rzeczywistych oszczędności kosztów w dłuższej perspektywie, są niewielkie). następnie zamknij żądanie lub umieść je w zaległościach o niskim priorytecie, nawet w przypadkach, w których idealizm mówi, że należy je zmienić (nie jest to jeden z tych przypadków, ale wspomniany dla tych, którzy myślą, że tak jest). Idealizm doskonale nadaje się do rozmów, ale firmy nie mogą płacić czynszu, mediów, pracowników, podatków itp. Za pomocą ideałów.

4. @ jpmc26 ma rację co do potrzeby komunikacji, ale nie do końca poprawna w kwestii tego, co należy przekazać. Tak, powinieneś słuchać tego, o co proszą inni, i starać się zrozumieć ich rozumowanie, w tym zadawanie pytań, jeśli jesteś niejasny.

   JEDNAK baza danych nie jest podporządkowana aplikacji, a specjaliści ds. Baz danych (administratorzy, inżynierowie, jakakolwiek nazwa Twojej firmy) nie są podporządkowani programistom (jak wydaje się to sugerować w tej odpowiedzi). Nie pracujesz dla programistów, pracujesz dla firmy, tak samo jak oni. To wysiłek zespołu i nie powinieneś błagać o wybaczenie za wykonywanie swojej pracy. To powiedziawszy, nasze typy komputerów nie są (ogólnie) znane z naszych umiejętności komunikacji międzyludzkiej, więc naprawdę musisz upewnić się, że inni cię rozumieją , jakie jest twoje rozumowanie, jakie są twoje obowiązki, ORAZ jak te rzeczy faktycznie działają .

   Włożyłem tę ostatnią część, ponieważ istnieje wysoki stopień nieporozumień, dezinformacji i braku wiedzy (nawet niektóre tutaj na tej stronie). Na przykład wydaje się, że istnieje pogląd, że wszystkie reguły są regułami biznesowymi. Musimy wyjaśnić, że istnieje różnica między regułami danych a regułami biznesowymi (@Aaron nazwał to „ograniczeniem przepływu pracy a ograniczeniem danych” w komentarzu do pytania) i że chociaż większość danych naturalnie należy do aplikacji, niektóre dane faktycznie należy do modelu danych. Jeśli DBA dyktuje programistom ograniczenia danych aplikacji . Jeśli naruszenie reguły biznesowej związanej z danymi aplikacji może spowodować szkodę, a aplikacja nie jest w 100% jedynym sposobem będą być ograniczane? Oczywiście nie. Naszym zadaniem jest oferowanie w górę, jak dane aplikacji puszkę w celu manipulowania danymi, być może ograniczenie sprawdzania może naprawdę pomóc (i nie są trudne do zmiany lub usunięcia).

   ALE, wychodząc z drugiej strony, programiści nie powinni dyktować sposobu przetwarzania danych modelu danych (tj. Metadanych). Obejmuje to pola kontroli (takie jak created_on/created_by kolumny) i kolumny PK / FK (te wartości powinny być znane tylko wewnętrznie, a nie podawane klientom). Te dane nie są tym, co aplikacja przechowuje o klientach (nawet jeśli aplikacja może zobaczyć wartości, a nawet ich użyć, na przykład z identyfikatorami), to jest to, co model danych przechowuje o danych aplikacji.

   Dlatego sensowne jest stosowanie reguł danych do ochrony danych modelu danych. A to nie oznacza, że ​​masz zamiar zacząć dodawać ograniczenia lub ograniczenia danych aplikacji. ALE trudno będzie poprowadzić rozmowę do przodu w naprawdę produktywny sposób, jeśli to rozróżnienie nie zostanie zrozumiane.

Więc:

1. Tak, podoba mi się pomysł wyrażenia DENYw kolumnach audytu i zaproponowałem to samo w miejscach, w których pracowałem w przeszłości.

2. Anegdotycznie miałem bardzo podobną rozmowę z głównym deweloperem (bardzo dobrym), może w 2000 roku, kiedy zacząłem dodawać klucze obce. Twierdził (dość szczerze), że był to niepotrzebny nadmierny poziom inżynierii / idealizmu (coś w tym rodzaju, minęło 17 lat od tej rozmowy) i nie był wart hitu. Był całkiem jasny, że usuwanie powiązanych danych powinno odbywać się w warstwie aplikacji. (tak, dodałem FK, ponieważ to on nie miał zamiaru wyczyścić osieroconych danych, które jego kod nieuchronnie stworzyłby)

   Wiele lat później przeprosił za ten argument ;-)

Jest to prawdopodobnie problem XY. Deweloper prawdopodobnie nie jest szczególnie zainteresowany blokowaniem aktualizacji do naprawdę stałej dziedziny, takiej jak created_on. Ten konkretny przykład jest niezwykle skromnym ograniczeniem.

Deweloper prawdopodobnie obawia się, że zespół DBA (który obejmuje Ciebie) zamierza dodać tak wiele lub tak złożone ograniczenia, że ​​zacznie utrudniać ich efektywną pracę, lub że gdy powstanie coś niezwykłego lub coś się zmieni, zespół DBA będzie opierać się zmianom i utrudniać zespołowi programistów poczynienie postępów. Jest to względnie uzasadniony problem. Biurokracje i utrata zdolności do wprowadzania niezbędnych zmian są prawdziwymi zdarzeniami, a kodowanie zbyt wielu lub złożonych ograniczeń może mieć negatywny wpływ na wydajność i zdolność reagowania na zmiany wymagań.

Deweloper może nawet nie zdawać sobie sprawy, że taka jest natura ich obaw. Prawdopodobnie są przyzwyczajeni do swobodnego panowania nad bazą danych, a rezygnacja z tego poziomu wolności jest trudna, szczególnie jeśli wiesz, że nigdy jej nie wykorzystałeś. Ich obawy związane z utratą zdolności do robienia tego, czego potrzebują, mogą być niejasne i źle zdefiniowane.

Jest więc kilka rzeczy, które należy zrobić, aby złagodzić te obawy:

1. Komunikuj się intensywnie z programistami. Upewnij się, że rozumiesz potrzeby funkcji, które próbują zbudować, i upewnij się, że reagujesz na nadchodzące zmiany. Posłuchaj, co mają do powiedzenia, i ciężko pracuj, aby znaleźć rozwiązanie, które równoważy ich obawy z twoim. Bądź skłonny zginać się, gdy mają uzasadnione potrzeby. Upewnij się, że wiedzą, że jesteś sojusznikiem w tworzeniu oprogramowania.
2. Zachowaj ostrożność przy nakładaniu ograniczeń. Ograniczenia, nawet te mające na celu zapewnienie integralności i bezpieczeństwa, mogą utrudnić dostosowanie się do zmian lub radzenie sobie z nieprzewidzianymi okolicznościami. Zrozum więc, że każde dodane ograniczenie wiąże się z takim samym prawdopodobieństwem, jak koszty, które mogą zaoszczędzić (z wyjątkiem klucza podstawowego i kluczy obcych, które praktycznie nie mają wad). Bądź pewien, że nałożone ograniczenia są naprawdę potrzebne lub korzystne.
3. Nie widzę żadnego znaku, że to robisz, ale chcę wspomnieć o tym innym czytelnikom: nie wyświetlaj danych ani bazy danych jako odpowiedzialności twojego lub twojego zespołu. Dane są atutem całej firmy. Bez systemu do przechowywania (bazy danych) i skryptów, narzędzi lub aplikacji do tworzenia, aktualizowania i pobierania danych dane są bezwartościowe. Ponieważ wszyscy muszą korzystać z tego zasobu, za dane odpowiadają wszyscy. Sama baza danych to tylko jedna część pozyskiwania wartości z danych.

Masz sprzeczne oświadczenia

• Kolumny, których nigdy nie należy aktualizować
• Z jakiegoś powodu muszą zaktualizować wartości

Czy tak naprawdę to ty decydujesz o pierwszym?

Dajesz najmniejszy przywilej, aby aplikacja działała bez dowodu, że aplikacja nigdy nie będzie musiała aktualizować wartości.

Kto jest odpowiedzialny za integralność danych?

Czy dzięki ograniczeniom SQL możesz zagwarantować integralność danych? Nie, nie możesz, ponieważ często istnieją reguły biznesowe wykraczające poza możliwości bazy danych.

VendorID nigdy nie powinien się zmieniać, ale co, jeśli dwóch dostawców się połączy. Nigdy nie mów nigdy.

Jeśli zespół aplikacji zanieczyści dane i powie, że potrzebuje tego uprawnienia, to na nich spoczywa. Jeśli zespoły aplikacji działają dla Ciebie, możesz dyktować.

Odpowiednie pytanie brzmi: czy aplikacja kiedykolwiek zaktualizuje dane.