Чи повинен я прийняти писати незахищений код, якщо мій роботодавець вимагає від мене цього зробити? [зачинено]

Мій роботодавець попросив мене реалізувати функцію, яка вимагатиме зберігання паролів у чистому тексті в базі даних (або за допомогою незрозумілої функції шифрування / розшифровки, що зберігається у двійковій системі, що трохи краще, але й небезпечно).

Я відповів, що готовий реалізувати таку функцію, за умови, що клієнти визнають наслідки для безпеки під час її використання.

Обговорюючи цю проблему з колегами, хтось сказав мені, що ми, як програмний інженер, особисто відповідаємо (в юридичному розумінні) за проблеми безпеки, які ми впроваджуємо в нашій продукції. Я переглянув свій контракт, але не знайшов нічого, пов’язаного з подібною справою.

Чи потрібно з юридичної точки зору відмовитись від реалізації такої функції? Чи правда, що мій роботодавець міг би взяти мене до суду, якщо клієнт зазнає шкоди через цю особливість, навіть якщо він також знав про проблеми безпеки?

EDIT: Я розумію, що на це питання можна відповісти надійно лише з юриста. Те саме стосується питань ліцензування: люди тут дають своє розуміння та свій досвід, іноді після консультації з юристом, без жодних гарантій, що це застосовується в іншій юрисдикції. Але ліцензування тут чітко прийнято як тему, див. Які питання тут можна задати? . Я вважаю, що в інших програмістів може виникнути те саме питання, і інші, можливо, раніше стикалися з цією ситуацією, і, можливо, порадилися з юристом.

Ваш колега помилково керується тим, що ви не могли знайти нічого, що стосується відповідальності з безпеки в договорі. Навіть якщо це було, ви просто отримали суперечливе розпорядження від керівництва.

Я думаю, що єдиний раз, коли ви піддаєте себе потенційним судовим процесом, це якщо свідомо пошкодити виріб самостійно, створити власну бомбу з тимчасовим часом, писанку тощо.

У більшості випадків компанія володіє програмним забезпеченням, тому вони отримують задоволення від прибутку, але це також означає, що вони також можуть взяти на себе ризики, а не окремого розробника.

Особисто я би переконався, що керівництво обізнане про проблеми з цією функцією безпеки, щоб воно було задокументоване заздалегідь, і просто продовжувати виконувати свою роботу.

Коли це сказано, проконсультуйтеся з юристом, yada-yada-yada.

Що б не трапилося: ніколи не пишіть такий код, не маючи електронного листа чи інших доказів, що чітко показують, що ви просто виконували вказівки свого роботодавця.

З юридичної точки зору проконсультуйтеся з юристом. Я не один, і ми не маємо жодного поняття, яка юрисдикція чи закони ви живете, за якими могли б пояснити деякі речі. Але в будь-якому випадку проконсультуйтеся з юристом, чи довіряєте ви інтернет-запитанням з питань особистого, професійного та фінансового майбутнього.

Загальна ділова порада - переконайтеся, що ви оформили свої застереження в письмовій формі, а пряме розпорядження роботодавця продовжувати, враховуючи проблеми безпеки у письмовій формі. Якщо все-таки піде на південь і вдарить по вентилятору, вам доведеться впасти.

Іншим способом цього було б заглибитись у вимоги - ви поділилися планом, а не проблемою, яку ви вирішуєте. Існує більше, ніж один спосіб зібрати кішку або вирішити вимоги щодо пошуку пароля.

Я б не хвилювався з цього приводу - це не так, як ви зловмисно вирішуєте себе вносити небезпечну функцію та експлуатувати її пізніше, або просто вкладаєте її, тому що ви недбалі. Компанія хоче цього, хтось вирішив, що компроміс між часом розробки та очікуванням користувачів є прийнятним (як зазвичай), і тому вам слід продовжувати це. Якщо ви насправді переживаєте будь-які зворотні результати, надішліть своєму начальникові повідомлення електронною поштою та збережіть відповідь. Після того, як ви зробите це, як працівник, вас охоплюють.

Іноді є причини, чому це прийнятно - наприклад, я знаю деякі критично важливі рішення, які зберігають паролі простого тексту, але решта системи захищена, щоб це не стало проблемою. Наприклад, ця система знаходиться в окремій мережі. Якщо ви не знаєте іншої частини історії (поширена ситуація в більшості компаній), то ви можете з розумом очікувати, що хтось інший це врахував. Точно так само, якщо у вас є електронний лист від вашого начальника, ви можете сподіватися, що він знає, що робить.

До речі ... це продукт, який я (як споживач) можу використовувати? Якщо так .. що це, то я можу цього уникнути? :)

Чи усвідомлюємо ми, що розробники додають численні помилки, що завдає шкоди клієнтам під час операцій наживо на однаково великий актив. Ми не вважаємо, що вони є навмисними, але це все-таки є результатом нашої конкретної роботи і все ще не до кінця. Таким чином, зроблений вами приклад - це не окремий випадок, коли рішення розробника (або більш високі версії) впливають на клієнта.

Ось що я пропоную:

1. По-перше, у будь-якому разі - саме компанія постачає програмне забезпечення іншій компанії. Фізичній особі не надається прямий кредит (крім оплесків всередині команди та максимум зарплат) та право власності на роботу. Отже, поки це не є хорошою справою в нашій доставці, але ви тут не злочинець - до тих пір, поки рішення не буде вашим.

2. Як професійний програміст - ви чітко вказуєте обмеження коду та небезпеки, пов'язані з тим, як підтримувати речі як частину файлу README або відповідної документації. Якщо є документ із вимогами - пропонований звіт про випробування тощо повинен чітко вказувати обмеження.

3. Для того, щоб відповідати справжньому особі, яка приймає рішення, я б просив вищих підтвердити своє мислення в електронній пошті будь-яких таких документів.

4. Правильно зважте ризик. Програмне забезпечення моєї картки даних зберігає пароль у тексті плану, але це не важливо. Але те ж саме не прийнятно, якщо я зберігаю пароль банку або якщо це доступ до бази даних або сервера. Отже, виходячи з реального ризику, ви повинні максимально підняти питання до вище.

Якщо ви не виконуєте свою роботу умисно згубно, є мало правових недоліків у виконанні завдань, які вас вимагають. У вас буде трудовий договір, в якому будуть вказані ваші зобов’язання, ви можете проконсультуватися з юристом з технічних питань. Отримайте письмове схвалення дизайнерського рішення щодо простих текстів паролів, якщо ви дійсно відчуваєте себе відкритим.

Я не розкриватиму, яке саме програмне забезпечення є, поки не буду впевнений, що ця функція робить це в остаточному випуску. Я все ще маю надію, що нам вдасться повідомити клієнтів таким чином, як я вважаю це прийнятним.

Трохи більше хвилює ваша цитата про "інформування клієнтів". Якщо ви завдасте шкоди вашим компаніям, що стоять, репутація тощо (положення про яке буде укладено у вашому контракті), то ваша компанія може подати до вас в суд - і захист, який подає виклик, може не допомогти вам, коли вам потрібна довідка чи інша робота.

Якщо ви незадоволені наслідками дірок у безпеці, тоді почистіть своє резюме та продовжуйте роботу, але якщо це було не ваше рішення, і це не ваша компанія, я не можу зрозуміти, чому це було б «звинувачено» (юридично) на вас .

Ваша компанія повинна була скористатися формою страхування професійного відшкодування, коли вони працювали на вас. Це має забезпечити адекватний правовий захист для всіх його працівників у разі чого з програмним забезпеченням не трапиться, або зловживання програмним забезпеченням або виявлені недоліки в програмному забезпеченні (наприклад, незашифровані паролі).

Як працівник, ви повинні робити те, що вони просять, і вони повинні робити те, що хоче клієнт, доки жодна зі сторін не порушує закон, проблем немає, але якщо ви робите те, що хоче компанія, і тоді це виявляється, що це не те, що бажав / вимагав клієнт, тоді це між ними, і страхування професійного відшкодування повинно покривати вас від будь-якої особистої вини / відповідальності.

IANAL, але я б вирішив це з юридичною командою компаній, на додачу до перевірки у своїх юристів.

PS, якщо вас це серйозно сполохало, збережіть усі відповідні електронні листи в електронній та паперовій копії десь за межами сайту.

Час нової роботи. Забудьте реалізувати це. Пора рухатися. Якщо вони бажають бути настільки кавалерними і обманливими з цим, вони також не бояться кинути вас під автобус.

Крім того, не лякайтеся, коли ви пішли на анонімний зв’язок з однією з багатьох груп, які вказують на безпеку в програмному забезпеченні людей. Це катастрофа, яка чекає, що трапиться. Немає абсолютно ніяких надійних причин зберігати їх. Ваш начальник дав вам причину? Вони хочуть увійти як користувачі? Чи хочуть вони спростити отримання паролів? Якщо ви не отримаєте відповідь на одне з вищезазначених, що можете звертатися більш безпечно, тоді саме час рухатися далі. Коли ви виходите, краще було б не сказати їм, чому.

що ви можете зробити, щоб дотримуватися вказівок щодо збереження паролів у відновлюваному форматі, але все ще неможливо отримати, якщо ви маєте повний доступ до програми, використовуючи асиметричне шифрування

ви шифруєте (солений як завжди) ключ відкритим ключем, що зберігається у двійковому файлі

і коли потрібні паролі в простому тексті, людині потрібно надати приватний ключ, який інакше зберігається подалі від сервера

Особисто я ніколи не чув, щоб інженер-програміст без застереження в договорі чи іншому офіційному договорі не мав юридичної відповідальності за проблеми безпеки в продуктах, над якими вони працюють. З того, що я читав про закони та етику в інженерії програмного забезпечення, вимоги безпеки для системи диктуються специфікацією вимог, яка також стосується будь-яких юридичних, галузевих чи корпоративних вимог. При побудові системи невиконання вимог безпеки трактується як невиконання умов договору, оскільки система не була побудована як зазначено. Те, як розгортаються конкретні події, залежить від договорів між інженером та роботодавцем та роботодавцем та замовником.

Закони також не говорять про те, що ти повинен робити, але що ти можеш / не можеш робити. Ви не згадуєте, в якій галузі ви перебуваєте, але в деяких є закони, положення та правила щодо обробки конкретних типів даних - що потрібно зашифрувати, мінімальні рівні шифрування, вимоги щодо управління / контролю доступу, і так далі. Якщо у вашій місцевості (країні, штаті) немає правил щодо безпеки, у вашій галузі немає правил щодо безпеки, а вимоги до програмного забезпечення не викликають вимог або стандартів безпеки, це може бути скоріше етичним питанням, ніж юридичне питання.

Що стосується етичних питань у розробці програмного забезпечення, я підписуюся на Кодекс етики та професійної практики програмного забезпечення . Зрештою, це ваш дзвінок. Однак я вважаю, що зберігання паролів у простому тексті чи у форматі, який можна розшифрувати, неетично.

Просто відповідайте процесу розробки вашого проекту: якщо ця функція записана в документі з вимогами, ви повинні її реалізувати.