Przejdź do głównej zawartości

Problem bezpieczeństwa w architekturze SOA

Problem bezpieczeństwa był przedmiotem żywej dyskusji na Golden Line na moim wątku.
Wypracowałem sobie dzięki temu pewne stanowisko, które jest jej dorobkiem.

Oto ono.

1) Dostęp do danych
W tych wdrożeniach, z którymi mieliśmy do czynienia, dostęp do odpowiednich danych ZAWSZE był warunkiem koniecznym sporządzenia raportu. 

Czy może ktoś się spotkał z sytuacją, że raport się sporządza bez dostępu do danych? Ja nie.

Co najwyżej trzeba odczytywać dane z WYDRUKU.
Znam przypadek, że pewien łebski analityk (Polak, notabene) napisał program odczytujący EKRAN monitora. Bardzo sprytny. 
Udzielono mu uprawnienia do patrzenia w ekran i on z tego skorzystał.

Zrobił furorę w pewnej wielkiej europejskiej firmie samochodowej, wykorzystującej renomowany system. Na literę S. Polski oddział tej firmy został uznany za najbardziej zaawansowany we wdrożeniu owego systemu S.

To była architektura pre - SOA :)

Dlatego radzę - zamiast hejtować - MYŚLEC. Hejtowaniem na bzdurnych w waszym mniemaniu wątkach dotyczących architektury analiz, nie zrobicie kariery.
(To była uwaga do dyskutantów na moim wątku na GL. Tutaj marzę o jakiejkolwiek dyskusji. Bezskutecznie :) )

Podsumowując:
Jeśli sporządzenie raportu wymaga dostępu do danych na poziomie faktów a nie ich agregacji, to bez tego dostępu - raportu nie da się stworzyć.
To jest rzeczywista implikacja.

Dostęp do danych źródłowych nie jest naszym kaprysem, tylko biznesową potrzebą.

2) Możliwość ustawiania konkretnych uprawnień 

Możliwości nadawania uprawnień do konkretnych poziomów agregacji, z agregacją zerową włącznie 
oraz
interface w jakim będą nadawane (pewnie jednak nie skoroszyt Excela :) 
a także
decyzja ile i jakie role systemu będą odpowiedzialne za ich nadawanie....

powinny być ustalone na etapie projektu produktu - systemu informatycznego wspierającego analizę biznesową. Oczywiście mającego architekturę SOA.

3) Nadanie uprawnień 
to sprawa, którą należy rozstrzygać na etapie projektu wdrożenia systemu, a weryfikowane podczas jego eksploatacji.

Komentarze

Popularne posty z tego bloga

Referencje dla architektury i podejścia SOA

Od 2012 roku prowadziłem na swoim blogu akcję promowania architektury i podejścia SOA, której koncepcję opublikowaliśmy we trzech , współtwórcą tej architektury, Wojciechem Gardzińskim oraz Jakubem Rumińskim(zbieżność nazwisk nie całkiem przypadkowa, ale chyba nie przynosząca mi wstydu), analitykiem i konsultantem międzynarodowych korporacji, który ją weryfikował i uwiarygadniał z punktu widzenia realiów światowego biznesu.

Teraz czas na innego rodzaju uwiarygodnienie.

Architektura i podejście SOA nie jest tylko nową, oryginalną koncepcją.
Jest produktem komercyjnym, posiadającym pierwsze, ale poważne i sprawdzone na przestrzeni co najmniej dwóch lat, referencje biznesowe w dużej instytucji publicznej.
Podaję jednak referencje z trzech kolejnych lat.
Wyłania się z nich w sposób dla nieco zaskakujący, konsekwentna linia rozwojowa podejścia SOA.
To właściwie logiczne: Wzięła się nie z "nagłego olśnienia".
Wyłoniła się, jako logiczny (i nieubłagany) skutek naszych doświadczeń, …

Codd'a 12 zasad zarządzania bazą danych dla OLAPu

(Codd's paper)
Jako glossa do nieudanej ale burzliwej "dyskusji" o tym, czym jest OLAP i czy tabela przestawna i OLAP to inne bajki, zamieszczam podstawowy tekst tego Ojca Założyciela dzisiejszej technologii bazodanowej Edgara Franka "Teda" Codd'a.
W tekście wytłuszczam te fragmenty, które bezpośrednio odnoszą się do przedmiotu sporu. W komentarzach (kursywą) wyjaśniam, jakie wypowiedzi mojego adwersarza i moje mają tu zastosowanie. Dyskusja ta ma charakter nieco abstrakcyjny, ale dla genezy dzisiejszych "problemów z analizą biznesową", ma fundamentalne znaczenie. Moim skromnym zdaniem. Tłumaczenie zasad z angielskiego tekstu - własne.
Zaczynam: W 1985 Edgar F. Codd napisał artykuł, określający zasady dla Systemów Zarządzania Relacyjnymi Bazami Danych (RDBMS systemów zarządzania), które zrewolucjonizowały branżę IT.
Pamiętam, jak czytałem jeszcze wcześniejsze teksty Codda, wówczas pracownika IBM, w materiałach szkoleniowych tej firmy, jeszcze nie z…

Technologia OLAP dla analityków (4)

Architektura analizy z Excelem w roli głównej Praktyka Dzisiaj Jaka jest teraz, dzisiaj rola Excela w analizie - to wie dobrze każdy analityk, mający szczęście współpracować z jakimś systemem bi – aj. Opisałem to tutaj.  A także jeszcze gdzieś, w formie rozwiniętej, pasjonującej historyjki. Prosto z życia. Tam.
Najpierw musi coś zrobić w swoim bi-aju. A potem? 1)Potem – dostęp tylko w interface’ie (kontrolce) tabeli przestawnej bi – aja. Własnej kontrolce bi - aja. (…). 2)Jak analityk koniecznie chce, to może zawsze użyć innej kontrolki - „Excel”. (czyli „Export do Excela” przyp KR, żeby pewien czytelnik zrozumiał, że Excel nie jest wprawdzie kontrolką, ale istnieją kontrolki „Excel” :) ) (…). Wówczas analityk otrzyma w Excelu piękną tabelkę prostokątną, z nagłówkami, której postać wynika z tego, jak obsłużył „kontrolkę” TP w (…) bi-aju. 3)Jak wejdziemy w szczegóły, to się okaże, że musi jeszcze wykonać mnóstwo czynności, które równają się ciągnięciu wózka inwalidzkiego po błocie. Ale …