Wprowadzenie Bardzo często można w książkach i na blogach spotkać opisy wzorców architektonicznych, wzorców projektowych, dobrych praktyk. Jednak bardzo rzadko autorzy piszą o tym kiedy je stosować. Sam fakt, że jakiś wzorzec "rozwiązuje jakiś problem", co jest celem tworzenia i stosowania danego wzorca, nie mówi nic o tym jak często i kiedy dany problem się pojawia. Komputer może być częścią firmy, samochodu, lodówki, telewizora, może być platformą dla oprogramowania użytkowego albo dla gier komputerowych, ale te - użyte - staja sie częścią tego komputera (gramy na komputerze a nie na…
Wprowadzenie Jako ludzie komunikujemy się od początku swojego istnienia (generalnie byty ożywione się komunikują). W formie utrwalonej ta komunikacja ma miejsce od pierwszych rysunków na piasku czy naskalnych, a w formie sformalizowanej od początków wojska i państwowości (formalizm: przykładanie wagi do formy, źr. Encyklopedia PWN). Bezpieczeństwo i wiarygodność komunikacji od początku naszej egzystencji jest przedmiotem zainteresowania komunikujących się stron. Warto pamiętać, że komunikacja to także samo rejestrowanie i odtwarzanie danych (treści), więc nawet zapisanie (utrwalenie gdzieś) listy sprawunków by później użyć tej listy, np. po dotarciu do sklepu, to także…
Wstęp Od lat spotykam się w literaturze z zakresu zarządzania, z krytyką poczty elektronicznej jako narzędziem zarządzania czymkolwiek (patrz: Sabotaż...2013). Poczta elektroniczna (podobnie jak pakiety biurowe w ogóle) jest typowym przykładem maksymy: ułatwienie nie zawsze jest ulepszeniem. W kliencie poczty elektronicznej zarówno treść jak i sposób adresowania (co i do kogo, kopia, itp.) nie podlega żadnej standaryzacji ani restrykcji (poczta elektroniczna często służy do wyprowadzania danych z firmy). Jak dodać do tego fakt, że załączniki są niewidoczne w narzędziach do lokalnego wyszukiwania, że mamy na serwerach filtry antyspamowe których reguły…
Wprowadzenie Tematem numer jeden, niemalże w każdym moim projekcie, jest model biznesowy i tajemnica przedsiębiorstwa. Z perspektywy lat muszę powiedzieć, że to fobia wielu (jak nie większości) przedsiębiorców i nie tylko przedsiębiorców. Nie dlatego, że chcą coś chronić, ale dlatego co i jak chronią. Nie raz już pisałem, że firmy nie raz, najpierw podpisują z dostawcami rozwiązań i konsultantami umowy o poufności, a potem wyzbywają praw do swojego know-how na ich rzecz: W branży inżynierii oprogramowania dość powszechna jest sytuacja, gdy programista jest także projektantem, innymi słowy programista ma pełnię…
Tak więc bezpieczeństwo powinno być raczej elementem wymagań w postaci "oczekiwany efekt" a nie "jak je zapewnić". Nie rozumiem dlaczego tak wielu analityków i działy IT wzbraniają się przed uznaniem, że oprogramowanie powinno być dostępne na dowolnym urządzeniu mobilnym i że nie powinno pozwalać na..., i tu określone ograniczenia. Moim zdaniem bezpieczeństwo powinno być definiowane (wymagania) poprzez ryzyka, których chcemy uniknąć w określonym, biznesowo oczekiwanym (a nawet zastanym) środowisku, a nie poprzez narzucanie konkretnego sposobu i technologii, w szczególności przymusu korzystania z konkretnego sprzętu czy oprogramowania.
Korzystanie z własnego repozytorium daje ochronę bo: my nim administrujemy, w przeciwieństwie do sieci Internet, nie da się go "podsłuchiwać", i co najważniejsze: dokumenty są w sposób jednolity skatalogowane, wersjonowane itp. Jeżeli jedyne miejsce z dokumentami, ich wersjami itp, to nasze skrzynki pocztowe, to znaczy, że nikt nie ma wiarygodnej, kompletnej wiedzy o projekcie.
To częste zjawisko: zemsta. Nie ma tu znaczenia czy "słuszna" czy nie bo nie ma słusznej zemsty, jest tylko łamanie prawa. Czy jest na to lekarstwo? Hm... nie ma na zemstę, czy jest lekarstwo na kradzieże? Tak: nie mieć czego ukraść lub nie być od tego uzależnionym. Zapewne dla wielu z Państwa brzmi to kuriozalnie ale im bardziej jakiś biznes (model biznesowy) oparty jest na tajemnicy tym bardziej jest on ryzykowany zaś im więcej mamy tajemnic tym bardziej tracimy wolność.Jaki z tego wniosek? Należy albo nie mieć tajemnic albo mieć świadomość konsekwencji ich posiadania i być przygotowanym. W przeciwnym wypadku ryzykujemy potencjalny upadek firmy z powodu jednego obrażonego pracownika...Ale... projektując system można wielu rzeczom zapobiec systemowo i proceduralnie... np. kluczem ochrony przed takim ryzykiem jest coś, co pewnie wzbudzi u wielu nie małe emocje: żaden pracownik firmy nie powinien być twórcą oprogramowania w niej wykorzystywanego...
Ukazał się artykuł jak w tytule. Początkowo chciałem odnieść ambitnie do każdego punktu ale było by to przesadą.
(więcej…)
Diagram metody dostępu do danych - przykład
Co wiec się robi? Łamiąc zasady "podpinamy" program analityczny bezpośrednio do danych (linia przerywana program analityczny Baza Danych). Na wszelki wypadek, żeby nie wieszał się, dajemy mu największe możliwe uprawnienia (dobrze gdy tylko do odczytu) i z głowy. Efekt? Po kilku latach w dużych firmach nikt nie wie kto i do czego ma dostęp.
