Wstęp

prawie 10 lat temu pisałem:

Często spo­ty­kam się z róż­ny­mi meto­da­mi uwzględ­nia­nia pra­wa w doku­men­ta­cji wyma­gań. Jakim wyma­ga­niem jest zgod­ność z obo­wią­zu­ją­cym pra­wem? I trud­niej­sze pyta­nie: czy zmia­na pra­wa to zmia­na wyma­gań? Inny aspekt pro­ble­mu to ana­li­za i defi­ni­cja (opis) tej zgod­no­ści z pra­wem. Spotkać moż­na się z meto­dą pole­ga­ją­cą na trak­to­wa­niu każ­de­go (mają­ce­go wpływ na sys­tem) para­gra­fu np. usta­wy jako wyma­ga­nia. Problem zgod­no­ści opro­gra­mo­wa­nia z pra­wem ma dwa aspekty. Zgodność opro­gra­mo­wa­nia z pra­wem pole­ga na tym, że ??opro­gra­mo­wa­nie nie może ogra­ni­czać sto­so­wa­nia pra­wa to jest nie może  wymu­szać swo­imi ogra­ni­cze­nia­mi dzia­łań nie­zgod­nych z prawem?. Ja oso­bi­ście reko­men­du­ję roz­cią­gnię­cie tej defi­ni­cji na ??ani nie powin­no pozwa­lać na łama­nie pra­wa?.  Tu jed­nak wie­lu uwa­ża, że ??zama­wiam narzę­dzie i uży­wam jak chcę, na swo­ja odpo­wie­dzial­ność?. Coś w tym jest, war­to jed­nak zosta­wić ??włącz­nik?.  (źr.: Prawo a wymagania … )

Dzisiaj czytam:

To administrator odpowiada za zabezpieczenia systemów, a więc także za to, że pracownik zdołał skopiować dane osobowe na zewnętrzny nośnik. […] W ocenie WSA w toku postępowania PUODO prawidłowo ustalił, iż w SGGW dopuszczono się licznych uchybień, w szczególności nie przeprowadzono właściwej analizy ryzyka i oceny zagrożeń już na etapie projektowania systemów (privacy by design) oraz nie wdrożono odpowiednich środków zapewniających bezpieczeństwo danych, w tym przed możliwością wyeksportowania danych z systemu na zewnątrz.(źr.: Odpowiedzialność administratora za naruszenie zasady privacy by design)

Rzecz w tym, że administrator, w rozumieniu prawa, to także podmiot zlecający powstanie oprogramowania, które go wspiera w realizacji jego obowiązków, a jednym z tych obowiązków jest egzekwowanie ustalonych zasad. Dzisiaj o tym, że zbieranie “podpisów pod oświadczeniami” to nie jest bezpieczeństwo.

Łańcuch odpowiedzialności

Wybrane fragmenty Uzasadnienia:

Prezes UODO zarzucając niewystarczającą ocenę zastosowanych środków technicznych i organizacyjnych obejmujących proces przetwarzania danych osobowych kandydatów na studia w S[?] kierował się zasadą wynikającą z art. 24 ust 1 rozporządzenia 2016/679 jaką jest kontrola administratora nad procesami przetwarzania danych osobowych.
[?]
Na administratorze ciąży zaś obowiązek zweryfikowania w organizacji obszarów przetwarzania danych osobowych i wdrożenia odpowiednich środków technicznych i organizacyjnych mających zapewnić ich bezpieczeństwo.
[?]
Dowody zgromadzone w sprawie pozwalają stwierdzić, że Uczelnia mimo świadomości istnienia w procesie przetwarzania danych osobowych kandydatów na studia, technicznej możliwości przetwarzania polegającego na eksportowaniu na zewnętrzny nośnik danych osobowych z systemu informatycznego z uwagi na funkcjonalność umożliwiającą niekontrolowany eksport szerokiego zakresu danych osobowych z systemu SOK i świadomości w tym zakresie Biura Spraw Studenckich, zignorowała to zagrożenie
[?]
Według art. 4 pkt 7 rozporządzenia RODO “administrator” oznacza osobę fizyczną lub prawną, organ publiczny, jednostkę lub inny podmiot, który samodzielnie lub wspólnie z innymi ustala cele i sposoby przetwarzania danych osobowych; jeżeli cele i sposoby takiego przetwarzania są określone w prawie Unii lub w prawie państwa członkowskiego, to również w prawie Unii lub w prawie państwa członkowskiego może zostać wyznaczony administrator lub mogą zostać określone konkretne kryteria jego wyznaczania.
[?]
Nie ulega zatem wątpliwości, że w rozpatrywanym przypadku administratorem danych osobowych była S[?], a nie jej pracownik, [?] A.G. W konsekwencji, wbrew zapatrywaniu skarżącej Uczelni, nie ponosi on odpowiedzialności administracyjnej za naruszenie przepisów rozporządzenia RODO.
[?]
Trzeba podkreślić, że z tego przepisu wynika domniemanie odpowiedzialności administratora za naruszenie tych zasad, jako że na nim spoczywa ciężar wykazania ich przestrzegania. Administrator danych powinien zatem przeprowadzić analizę ryzyka i ocenić, z jakimi zagrożeniami ma do czynienia.

(źr.: https://orzeczenia.nsa.gov.pl/doc/E2A2856241)

Innymi słowy tu

administrator (czyli instytucja) odpowiada za wady oprogramowania, a wadą jest więc to, że pozwala ono na postępowanie niezgodne z prawem, wewnętrznym regulaminem czy instrukcją itp.

“Privacy by Design”

“Prywatność wbudowana na etapie projektowania” i “Prywatność jako cecha domyślna” to często poruszane tematy związane z ochroną danych w systemach informatycznych. Zwracano na to uwagę już od lat 70-tych, a w latach 90-tych włączono do dyrektywy RL 95/46/EC o ochronie danych. Zgodnie z nią odpowiednie środki techniczne i organizacyjne muszą być podjęte już na etapie planowania i projektowania systemu przetwarzania danych w celu ochrony ich bezpieczeństwa. Oznacza to, że restrykcje (bezpieczeństwo) muszą być immanentną cechą systemu:

The term “Privacy by Design” means nothing more than “data protection through technology design”. Behind this is the thought that data protection in data processing procedures is best adhered to when it is already integrated in the technology when created [Termin “Privacy by Design” to nic innego jak “ochrona danych poprzez projektowanie technologii”. Kryje się za tym myśl, że ochrona danych w procedurach przetwarzania danych jest najlepiej przestrzegana, gdy jest ona wbudowana w mechanizm rozwiązania już na etapie jego projektowania]

().

Popatrzmy teraz na definicje kluczowego pojęcia w inżynierii wymagań:

potrzeba: funkcja, której brakuje do osiągnięcia celu lub wykonania działania (źr. zalecenia UZP)

Innymi słowy to potrzeby Zamawiającego są wymaganiem wobec rozwiązania. Tak więc zgodność oprogramowania z obowiązującym prawem to jego wymagana cecha (właściwość), a nie możliwa do użycia funkcjonalność. Rozporządzenie (RODO) nakazuje również, aby domyślnie (?by default?) mechanizmy ochrony danych, implementowane już w fazie projektowania, były domyślnie włączone.

Jedną z wymaganych więc funkcji oprogramowania powinno być egzekwowanie prawa, a nie tylko możliwość jego respektowania!

Cytowane wcześniej zalecenia KE jak i Orzeczenie jasno wskazuje, że Zamawiający, jako przyszły użytkownik, jest tą osobą (także prawną), która ponosi odpowiedzialność za skutki używania zamówionego oprogramowania. Popatrzmy na poniższy schemat:

Generalnie to Zamawiający zatrudnia (angażuje) Wykonawcę. Powoli, ale coraz częściej, zgodne z zaleceniami UZP, wydziela się także rolę Projektanta, zlecając mu opracowanie OPZ. Mechanizm zarządzania ryzykiem poprzez rozdzielanie ról z konfliktem interesu, dotyczy zresztą każdego podmiotu, prywatnego także. W Orzeczeniu czytamy wielokrotnie o analizie ryzyka, stanowiącej obowiązek Administratora czyli także Zamawiającego. Więc zlecając wykonanie (dostarczenie) oprogramowania, należy postawić takie wymagania, by rozwiązanie to (mechanizm jego działania) zapewniało także egzekwowanie określonych reguł (rozliczalność), a nie tylko umożliwiało ich respektowanie (czyli dawało alternatywę). Kto ma tego pilnować? Znakomita większość pracowników Administratora/Zamawiającego nie ma kompetencji Projektanta, Wykonawca zaś ma tu z zasady konflikt interesu. Pozostaje więc wydzielenie roli Projektanta i umieszczenie jej po stronie Zamawiającego.

Łańcuch odpowiedzialności kończy sie na Administratorze (Orzeczenie) co znaczy tyle że w jego interesie jest to, by wymaganie, o jakim tu piszemy, było spełnione i zagwarantowane już na etapie projektowania. Co ciekawe “pisanie wymagań” przez pracowników nie stanowi tu nie tylko żadnego zabezpieczenia, stanowi ryzyko, że będą budowali furtki pozwalające im na większą swobodę (patrz Orzeczenie i postępowanie pracownika, któremu skradziono komputer).

Dlatego specyfikacja wymagań [dla dewelopera] powinna być projektem, a nie listą potrzeb, bo ta jest dopiero materiałem dla projektanta.

Podsumowanie

Mamy XXI wiek i ogromny postęp w inżynierii oprogramowania i warto pamiętać, że

Programowanie nie polega już wyłącznie na pisaniu kodu, programowanie polega na projektowaniu.

Orzeczenie to stanowi moim zdaniem pozytywny precedens. Problem z niską jakością oprogramowania w tym obszarze, to skutki rynkowej “zasady”: Klient nasz Pan. Dostawcy oprogramowania, będący w znakomitej większości także jego projektantami, czują się całkowicie zwolnieni z odpowiedzialności za skutki jego użycia. Niedawno jeden dostawca wpisał mojemu klientowi, do wzoru umowy, zapis o wyłączeniu jego (dostawcy) odpowiedzialności z tytułu rękojmi (!). Tworzenie oprogramowania to umowa rezultatu, a ten powinien być precyzyjnie opisany na etapie zawierania umowy, nie jako detaliczna konstrukcja, ale jako realizowany mechanizm. Warto także pamiętać, że odpowiedzialność za uzyskany efekt spoczywa także na projektancie: projekt to zamówiony rezultat .

Z treści Orzeczenia wynika, że w zasadzie nic nie stoi na przeszkodzie, by zasadę “Privacy by Design” rozciągnąć na “Law by design”, czyli implementowanie w oprogramowaniu wszelkich restrykcji wynikających z prawa i obowiązku jego przestrzegania. Często jednak słyszę argument: “nikt nie kupi takiego oprogramowania”. Jeżeli to prawda, to o czym to świadczy? (np. mimo tego, że nie wolno sprzedać towaru, którego się nie posiada, pozwala na to większość systemów ERP).

Podkreślając tezy Orzeczenia, można wywieść ważny wniosek: oprogramowanie wdrożone w przedsiębiorstwie (czy odebrane od dostawcy) jest integralną częścią tego przedsiębiorstwa, i bardzo trudno będzie dowieść, że za szkody jakie ono wyrządzi odpowiada dostawca oprogramowania, jest to z zasady odpowiedzialność Zarządu. Dlatego bardzo ważne jest, by Zamawiający miał po swojej stronie kompetencje pozwalające nadzorować dostawcę. Całość coraz bardziej zbliża branżę IT do innych inżynierii, gdzie za szkody wyrządzone przez urządzenia odpowiada ich użytkownik – dysponent.

Warto także pamiętać, że podobnie wygląda security by design , czyli bezpieczeństwo jako efekt projektowanej architektury, a nie “podpisów pod oświadczeniami”.

Źródła