Czy powinienem zaakceptować napisanie niezabezpieczonego kodu, jeśli mój pracodawca mnie o to poprosi? [Zamknięte]

Mój pracodawca poprosił mnie o wdrożenie funkcji, która wymagałaby przechowywania haseł w postaci czystego tekstu w bazie danych (lub za pomocą niejasnej funkcji szyfrowania / deszyfrowania przechowywanej w pliku binarnym, co jest nieco lepsze, ale także niepewne).

Odpowiedziałem, że jestem gotów wdrożyć taką funkcję, pod warunkiem, że klienci będą świadomi konsekwencji bezpieczeństwa podczas jej używania.

Omawiając ten problem z kolegami, ktoś powiedział mi, że jako inżynier oprogramowania ponosimy osobistą odpowiedzialność (w sensie prawnym) za problemy bezpieczeństwa, które wprowadzamy w naszych produktach. Przejrzałem swoją umowę, ale nie znalazłem nic związanego z podobną sprawą.

Czy z prawnego punktu widzenia powinienem odmówić wdrożenia takiej funkcji? Czy to prawda, że ​​mój pracodawca może skierować mnie do sądu, jeśli klient odniesie szkodę z powodu tej funkcji, nawet jeśli był również świadomy obaw dotyczących bezpieczeństwa?

EDYCJA: Rozumiem, że na to pytanie można odpowiedzieć tylko w sposób wiarygodny od prawnika. To samo dotyczy pytań licencyjnych: ludzie tutaj wyrażają swoje zrozumienie i swoje doświadczenie, czasami po konsultacji z prawnikiem, bez gwarancji, że dotyczy to innej jurysdykcji. Ale licencje są tutaj wyraźnie akceptowane jako temat. Zobacz, jakie pytania mogę tutaj zadać? . Wierzę, że inni programiści mogą mieć ten sam problem, a inni mogli już wcześniej mieć do czynienia z tą sytuacją i mogli skonsultować się z prawnikiem.

Twój kolega jest wprowadzony w błąd, tym bardziej, że w umowie nie znalazłeś nic na temat odpowiedzialności za bezpieczeństwo. Nawet jeśli tak, dostałeś sprzeczne zamówienie od kierownictwa.

Wydaje mi się, że jedynym potencjalnym sporem może być przypadkowe uszkodzenie produktu, stworzenie własnej bomby zegarowej, pisanki itp.

W większości przypadków firma jest właścicielem oprogramowania, więc mogą cieszyć się zyskami, ale oznacza to również, że mogą podjąć ryzyko, a nie indywidualny programista.

Osobiście upewniłem się, że kierownictwo zdaje sobie sprawę z problemów związanych z tą funkcją bezpieczeństwa, aby zostało to wcześniej udokumentowane i po prostu kontynuuję swoją pracę.

To powiedziawszy, skonsultuj się z prawnikiem, yada-yada-yada.

Cokolwiek się stanie: Nigdy nie pisz takiego kodu bez wiadomości e-mail lub innych dowodów jasno wskazujących, że postępujesz zgodnie z instrukcjami pracodawcy.

Z prawnego punktu widzenia skonsultuj się z prawnikiem. Nie jestem jednym z nich, ani nie mamy pojęcia, jaką jurysdykcję lub przepisy obowiązują w danym kraju, co mogłoby pomóc w wyjaśnieniu niektórych rzeczy. Ale w każdym razie skonsultuj się z prawnikiem, czy zaufasz stronie z pytaniami i odpowiedziami w sprawach osobistych, zawodowych i finansowych.

Ogólna rada biznesowa zapewnia, że ​​rezerwacje zostaną zapisane na piśmie, a bezpośrednie zlecenie pracodawcy jest kontynuowane, biorąc pod uwagę obawy dotyczące bezpieczeństwa na piśmie. Jeśli coś pójdzie na południe i uderzysz w wentylator, będziesz musiał na nim polegać.

Innym sposobem może być głębsze spojrzenie na wymagania - podzieliłeś się planem, a nie problemem, który rozwiązujesz. Istnieje więcej niż jeden sposób na skórowanie kota lub spełnienie wymagań wyszukiwania hasła.

Nie martwiłbym się tym - nie chodzi o to, że złośliwie decydujesz się na włączenie niepewnej funkcji i wykorzystanie jej później, lub po prostu włóż ją, ponieważ jesteś zaniedbany. Firma tego chce, ktoś zdecydował, że kompromis między czasem programowania a oczekiwaniami użytkowników jest akceptowalny (jak zwykle), więc powinieneś zacząć z tym. Jeśli naprawdę martwisz się o powrót, wyślij swojemu szefowi wiadomość e-mail i zachowaj odpowiedź. Gdy to zrobisz, jako pracownik jesteś objęty ubezpieczeniem.

Czasami istnieją powody, dla których jest to do przyjęcia - na przykład znam niektóre bardzo krytyczne dla firmy rozwiązania, które przechowują hasła w postaci zwykłego tekstu, ale reszta systemu jest zabezpieczona, aby nie stanowiło to problemu. Ten system jest na przykład w osobnej sieci. Jeśli nie znasz reszty historii (częsta sytuacja w większości firm), możesz oczekiwać, że ktoś to rozważył. Podobnie, jeśli masz ten e-mail od swojego szefa, możesz oczekiwać, że on wie, co robi.

Nawiasem mówiąc ... czy to produkt, z którego (konsumenta) mogę skorzystać? Jeśli tak ... co to jest, abym mógł tego uniknąć? :)

Czy zdajemy sobie sprawę, że programiści dodają wiele błędów, które szkodzą klientom podczas operacji na żywo, co jest równie dużym atutem. Nie uważamy, że są one zamierzone, ale wciąż jest to wynikiem naszej konkretnej pracy i wciąż nie jest na dobre. Tak więc podany przez ciebie przykład nie jest odosobnionym przypadkiem, w którym decyzje dewelopera (lub wyższej wersji) wpływają na klienta.

Oto, co sugeruję:

1. Po pierwsze, na pewno - to firma dostarcza oprogramowanie drugiej firmie. Osoba nie otrzymuje bezpośredniego uznania (poza oklaskami w zespole i co najwyżej wypłaty) i własności dzieła. Chociaż nie jest to dobra rzecz w ramach naszej dostawy, ale nie jesteś tutaj przestępcą - o ile decyzja nie należy do ciebie.

2. Jako profesjonalny programista - wyraźnie wskażesz ograniczenia kodu i niebezpieczeństwa związane z utrzymywaniem rzeczy w ramach pliku README lub związanej z nim dokumentacji. Jeśli istnieje dokument wymagań - sugerowany raport z testu itp. Powinien wyraźnie określać ograniczenia.

3. W celu pociągnięcia do odpowiedzialności prawdziwego decydenta - poprosiłbym wyższego szczebla o potwierdzenie swoich myśli w e-mailu o wszelkich takich dokumentach.

4. Prawidłowo zważ ryzyko. Moje oprogramowanie karty danych przechowuje hasło w tekście planu, ale to nie jest ważne. Ale to samo jest niedopuszczalne, jeśli przechowuję hasło banku lub jeśli jest to dostęp do bazy danych lub serwera. Opierając się na realnym ryzyku, musisz eskalować problem, aby awansował jak najwyżej.

O ile nie wykonasz swojej pracy w sposób umyślnie niszczący, wykonanie zadań, o które cię poprosiłeś, nie ma prawnego negatywnego wpływu. Będziesz mieć umowę o pracę, która określi twoje zobowiązania, możesz skonsultować się z prawnikiem w sprawie szczegółów technicznych. Jeśli naprawdę czujesz się narażony, uzyskaj pisemną zgodę na decyzję dotyczącą hasła jawnego tekstu.

Nie ujawnię, które to oprogramowanie, dopóki nie upewnię się, że ta funkcja znajdzie się w końcowej wersji. Nadal mam nadzieję, że uda nam się poinformować klientów w sposób, który uznam za akceptowalny.

Nieco bardziej niepokojący jest Twój cytat o „informowaniu klientów”. Jeśli zaszkodzisz pozycji, reputacji itp. Twojej firmy (klauzula, która będzie zawarta w umowie), wówczas Twoja firma może cię pozwać - a obrona „informatora” może ci nie pomóc, gdy potrzebujesz referencji lub innej pracy.

Jeśli nie jesteś zadowolony z konsekwencji dziur w zabezpieczeniach, popraw swoje CV i przejdź dalej, ale jeśli to nie była twoja decyzja i to nie twoja firma, nie rozumiem, dlaczego można by to za ciebie „obwinić” (zgodnie z prawem) .

Twoja firma powinna była wykupić formę ubezpieczenia od odpowiedzialności cywilnej z tytułu zatrudnienia. To powinno zapewnić odpowiednią ochronę prawną dla wszystkich swoich pracowników w razie niczego nie tak z oprogramowaniem lub nadużycia oprogramowania lub usterek znaleziono w oprogramowaniu (np niezaszyfrowanych haseł).

Jako pracownik powinniście robić to, o co proszą i powinni robić to, co chce klient, dopóki żadna ze stron nie złamie prawa, nie ma problemu, ale jeśli zrobicie to, czego chce firma, a potem okaże się, że nie jest to, czego chciał / wymagał klient, to jest to między nimi, a ubezpieczenie od odpowiedzialności zawodowej powinno obejmować cię od osobistej winy / odpowiedzialności.

IANAL, ale porozmawiam o tym z zespołem prawnym firmy, oprócz konsultacji z własnymi prawnikami.

PS, jeśli poważnie Cię to przeraża, jeśli to możliwe, zapisz wszystkie odpowiednie e-maile w formie elektronicznej i papierowej w innym miejscu.

Czas na nową pracę. Zapomnij o wdrożeniu tego. Czas się ruszyć. Jeśli zechcą być tak nonszalanccy i kłamliwi, nie będą się bali wrzucać cię pod autobus.

Ponadto, nie bój się, gdy raz odwiedzisz anonimowy kontakt z jedną z wielu grup, które wskazują luki w zabezpieczeniach w oprogramowaniu ludzi. To katastrofa, która czeka. Nie ma absolutnie żadnego uzasadnionego powodu, aby je przechowywać. Czy twój szef dał ci powód? Czy chcą się zalogować jako użytkownicy? Czy chcą ułatwić wyszukiwanie haseł? Jeśli nie uzyskasz odpowiedzi na jedną z powyższych odpowiedzi, którą możesz rozwiązać w bardziej bezpieczny sposób, nadszedł czas, aby przejść dalej. Kiedy odejdziesz, najlepiej nie mówić im, dlaczego.

co możesz zrobić, aby postępować zgodnie ze wskazówkami, aby przechowywać hasła w formacie do odzyskania, ale nadal nie można ich odzyskać, jeśli masz pełny dostęp do programu przy użyciu szyfrowania asymetrycznego

szyfrujesz (solony jak zawsze) klucz za pomocą klucza publicznego zapisanego w pliku binarnym

a gdy hasła są potrzebne w postaci zwykłego tekstu, człowiek musi podać klucz prywatny, który w innym przypadku byłby bezpieczny z dala od serwera

Osobiście nigdy nie słyszałem o inżynierze oprogramowania, bez klauzuli w umowie lub innej formalnej umowie, ponoszącej prawną odpowiedzialność za problemy związane z bezpieczeństwem produktów, nad którymi pracują. Z tego, co przeczytałem na temat praw i etyki w inżynierii oprogramowania, wymagania bezpieczeństwa dla systemu są podyktowane specyfikacją wymagań, która również odnosi się do wszelkich wymagań prawnych, branżowych lub korporacyjnych. Podczas budowy systemu niespełnienie wymagań bezpieczeństwa jest traktowane jako niedotrzymanie warunków umowy, ponieważ system nie został zbudowany zgodnie z opisem. To, jak przebiegną określone wydarzenia, zależy od umów między inżynierem a pracodawcą a pracodawcą i klientem.

Przepisy także nie mówią ci, co powinieneś robić, ale co możesz / nie możesz zrobić. Nie wspominasz o branży, w której się znajdujesz, ale niektóre mają przepisy ustawowe, wykonawcze i reguły dotyczące obsługi określonych rodzajów danych - co musi być szyfrowane, minimalne poziomy szyfrowania, wymagania dotyczące zarządzania / kontroli dostępu, i tak dalej. Jeśli twój obszar (kraj, stan) nie ma reguł dotyczących bezpieczeństwa, twoja branża nie ma reguł dotyczących bezpieczeństwa, a wymagania dotyczące oprogramowania nie określają wymagań ani standardów bezpieczeństwa, może to być bardziej problem etyczny niż kwestia prawna.

Jeśli chodzi o kwestie etyczne w tworzeniu oprogramowania, zgadzam się z Kodeksem etyki i praktyk zawodowych inżynierii oprogramowania . Ostatecznie to twój telefon. Uważam jednak, że przechowywanie haseł w postaci zwykłego tekstu lub w formacie, który można odszyfrować, jest nieetyczne.

Po prostu dostosuj się do procesu opracowywania swojego projektu: jeśli ta funkcja jest zapisana w dokumencie wymagań, musisz ją wdrożyć.