Obawy o administratorów baz danych

Jeżeli chcemy dobrze zabezpieczyć się przed działaniami administratorów należy audytować bazę danych nie w jej wnętrzu lecz z poziomu systemu operacyjnego. Wiadomo, że jak administrator bazy danych ma dostęp do danych audytowych to jest w stanie bardzo ładnie posprzątać po sobie i usunąć wszelkie wpisy o swojej działalności. Dlatego powinny być wyznaczone inne osoby (oficerowie bezpieczeństwa - tak to się ładnie nazywa) które pracę administratorów kontrolują. Z tego co się orientuję to są co najmniej dwa rozwiązania które realizują audyt właśnie w ten sposób, czyli jako proxy do bazy danych. [[http://www.quest.com/intrust-for-databases/]] [[http://www.active-base.com/activesecurity.html]]

@O@ - szyfrowanie częsciowe czy całości w tym przezroczyste dla odpowiednich aplikacji jest wbudowane w wiekszość baz danych jako standard. W ogóle, gdy robi sie obsługe np. bezpieczenstwa na etapie projektu i uwzględnia w odpowiedniej grupie modółów za to odpowiedzialnych i zapewni wstrzykiwanie reguł będące elementażem nie tylko dla poważniejszych aplikacji, tak iż reszta musi przez to przejść nawet bez powoływania się na te reguły (czyli znane policy injections), to mamy prostrze alikacje i wychodzi taniej, szybciej i duuużo bezpieczneiej, podobnie postępuje się z innymi sprawami, viadomo VS od MS. :)

Zgodnie z zasadą : Ufajcie i Kontrolujcie. Ale to nie jest w pełni profesjonalne podejście w stosunku do adminow i bazy. Sa juz dostepne technologie, ktore uniemozliwiaja adminowi ogladanie danych, gdyz są one zaszyfrowane, a nadawaniem uprawnienien do ogladania rzeczywistych wartosci zajmuje sie zupełnie ktoś inny. Tylko że trzeba to wdrozyć, a po co wydawac pieniedze na cos, czego nadzor nie wymaga.

w ubiegłych 2 latach, ok 95% problemów z włamaniami, kradzieżami, ujawnieniami, uszkodzeniami itp. było spowodowane przez źle napisane aplikacje (dane opublikowane z tego miesiąca) z tendencją rosnącą, przy czym do aplikacji starszych jest o niebo łatwiej się dobrać (na ogół) niż do współczesnych, pisanych zgodnie z aktualną metodologią, wiedzą i korzystających prawidłowo i kompleksowo ze współczesnych narzędzi i architektur. A gdzie jest wyraźnie łatwiej i sprawniej napisać (i co ważniejsze rozwijać) wystarczająco prawidłowe aplikacje jak na wymogi obecnych czasów: pod nowe dystra linuksa czy pod nowe Windows; w eclipse czy VS, w c++ javach i ruby, czy w C# z WPF WCF WF i LINQami? Sprawdzcie zanim wyskoczycie gdzie jest pies pogrzebany, bo systemy operacyjne są już w zasadzie wystarczające a ich wpływ (gdy zatrudnieni ludzie są rzetelni) jest minimalny wobec problemów z aplikacjami pisanymi w zbyt starym stylu w zbyt słabych językach i środowiskach deweloperskich - ponadto takie aplikacje są bardziej kosztowne gdy mają realizować to samo co te porawnie produkowane. W sumie koszt są na tyle wiesze (nawet wraz zlicencjami i sprzętem), że nie warto się pchać w gorsze choć tańsze gdy zamieża się deweloperką zarabiąc na firmę czy na swoje życie - oczywiśćie może zawsze być jakać nisza zupełnie odmienna - decyzja nalezy do takiego ryzykanta. :)

Jak widać główny problem jest w ludziach (a nie w systemach czy aplikacjach). Szczególnie gdy nie egzekwuje się od szefa administratorów profesjonalnego wypełniania obowiązków: bo ten niby szef nie ma autorytetu lub wiedzy lub umiejętności skutecznego przygotowania się i skutecznego rozmawiania w odpowiednim czasie z odpowiednimi ludźmi z zarządu. Terzeba zastąpić takich. Ponadto, w kilku ubiegłych latach, głównym źródłem (pomijając swoich ludzi w firmie) były aplikacje napisane w sposób niepoprawny (choć realizujące funkcjonalność biznesową) - wiadomo braki metodologi braki narzedzi i braki u liderów, szczególnie u szefa programistów natury podobnej do powyższej.