고용주가 요청한 경우 안전하지 않은 코드 작성을 수락해야합니까? [닫은]

고용주는 데이터베이스에 일반 텍스트로 암호를 저장 해야하는 기능을 구현하도록 요청했습니다 (또는 바이너리에 저장된 모호한 암호화 / 암호 해독 기능을 사용하는 것이 더 좋지만 안전하지 않음).

고객이이 기능을 사용할 때 보안 관련 사항을 인정한 경우 그러한 기능을 기꺼이 구현하겠다고 답했습니다.

이 문제를 동료들과 논의 할 때 누군가 소프트웨어 엔지니어로서 제품에 도입 된 보안 문제에 대해 개인적으로 (법적인 의미에서) 책임을 져야한다고 나에게 말했습니다. 계약서를 살펴 보았지만 비슷한 경우와 관련된 내용은 찾지 못했습니다.

법적 관점에서 이러한 기능을 구현하지 않아야합니까? 고객이 보안 문제를 알고 있었음에도 불구하고이 기능으로 인해 피해를 입은 경우 고용주가 법정에 데려 갈 수 있습니까?

편집 : 나는이 질문은 변호사로부터 확실하게 대답 할 수 있음을 이해합니다. 라이센스 문제에 대해서도 마찬가지입니다. 여기 사람들은 변호사와 상담 한 후에도 다른 관할권에 적용되는 것을 보증하지 않고 이해와 경험을 제공합니다. 그러나 여기서 라이센스는 주제로 명시 적으로 허용됩니다. 여기서 어떤 종류의 질문을 할 수 있습니까?를 참조 하십시오. . 다른 프로그래머들도 같은 문제를 겪었을 수도 있고, 다른 프로그래머들도 이전에이 상황에 직면했을 수도 있고, 변호사와 상담했을 수도 있습니다.

특히 계약서에서 보안 책임에 관한 어떤 것도 찾을 수 없기 때문에 동료가 잘못 안내됩니다. 그렇더라도 경영진으로부터 상충되는 명령을 받았습니다.

본인이 잠재적으로 소송을 제기 할 수있는 유일한 방법은 고의로 제품을 손상시키고 자신의 시한 폭탄, 이스터 에그 등을 만드는 것입니다.

대부분의 경우 회사는 소프트웨어를 소유하므로 이익을 누리게되지만 개별 개발자가 아니라 위험도 감수해야합니다.

개인적으로 경영진이이 보안 기능과 관련된 문제를 미리 파악하여 사전에 문서화하고 작업을 계속 수행하도록하겠습니다.

즉, yada-yada-yada 변호사와 상담하십시오.

어떤 일이 발생하든 : 방금 고용주의 지시를 따 랐음을 명확하게 보여주는 이메일이나 다른 증거없이 이러한 코드를 작성하지 마십시오.

법적인 관점에서 변호사와 상담하십시오. 나는 하나도 아니며, 어떤 사물을 설명하는 데 도움이 될 관할권이나 법률이 무엇인지 전혀 알지 못합니다. 그러나 어떠한 경우에도 변호사와 상담하십시오. 귀하는 개인, 직업 및 재정적 미래와 인터넷 Q & A 사이트를 신뢰하겠습니까?

일반적인 비즈니스 조언은 서면으로 예약을 받고 보안상의 문제를 서면으로 고용주가 직접 지시하도록하는 것입니다. 일이 남쪽으로 가고 팬을 때면 다시 떨어질 것입니다.

이 문제를 해결하는 또 다른 방법은 요구 사항을 자세히 살펴 보는 것입니다. 해결하려는 문제가 아니라 계획을 공유했습니다. 고양이를 스키닝하거나 암호 조회 요구 사항을 처리하는 방법은 여러 가지가 있습니다.

나는 걱정하지 않을 것입니다. 안전하지 않은 기능을 나중에 사용하거나 나중에 악용하기 위해 악의적으로 결정하는 것이 아닙니다. 회사는 이것을 원하고 누군가가 개발 시간과 사용자 기대치 간의 상충 관계가 평소와 같이 수용 가능하므로 결정해야한다고 결정했습니다. 컴백에 대해 정말로 걱정이되면 상사에게 이메일을 보내고 응답을 유지하십시오. 당신이 그 일을 마치면, 당신은 직원으로 커버됩니다.

때로는 이것이 수용 가능한 이유가 있습니다. 예를 들어, 평문 암호를 저장하는 매우 중요한 솔루션은 알고 있지만 나머지 시스템은 보안이 유지되므로 문제가되지 않습니다. 이 시스템은 예를 들어 별도의 네트워크에 있습니다. 이야기의 나머지 부분 (대부분의 회사에서 일반적인 상황)을 모르는 경우 다른 사람이 이것을 고려했을 것으로 합리적으로 기대할 수 있습니다. 마찬가지로, 당신이 당신의 상사로부터 그 이메일을 가지고 있다면, 그가하고있는 일을 그가 알고있을 것으로 기대할 수 있습니다.

덧붙여서 ... 이것은 (소비자로서) 내가 사용할 수있는 제품입니까? 그렇다면 .. 무엇이므로 피할 수 있습니까? :)

라이브 작업 중에 고객에게 해를 끼치 지 않는 많은 버그가 개발자에게 추가되어 동일한 자산을 얻는다는 것을 알고 있습니까? 우리는 그들이 의도적이라고 생각하지 않지만 여전히 우리의 구체적인 작업의 결과이며 여전히 마크에 미치지 않습니다. 따라서 여러분이 한 예는 개발자의 결정이 클라이언트에 영향을 미치는 격리 된 사례가 아닙니다.

여기 내가 제안하는 것이 있습니다 :

1. 우선, 다른 회사에 소프트웨어를 제공하는 회사가 바로 그 회사입니다. 개인에게는 직접적인 신용 (팀 내에서 박수를 보내거나 급여를 지불하는 것 이상) 및 저작물이 부여되지 않습니다. 따라서 이것이 우리 배달의 일부로 좋은 것은 아니지만 결정이 귀하의 것이 아닌 한 귀하는 범죄자 가 아닙니다.

2. 전문 프로그래머로서 README 파일 또는 관련 문서의 일부로 사물을 유지 관리하는 방법과 관련된 코드의 한계와 위험을 명확하게 나타냅니다. 요구 사항 문서가있는 경우 제안 된 시험 보고서 등이 그 한계를 분명히 언급해야합니다.

3. 진정한 의사 결정자가 책임을 지도록하기 위해, 나는 그러한 문서의 이메일로 자신의 생각을 확인하기 위해 상급자를 요구할 것입니다.

4. 위험을 정확하게 측정하십시오. 내 데이터 카드 소프트웨어는 비밀번호를 계획 텍스트 에 저장 하지만 중요하지 않습니다. 그러나 은행 암호를 저장하거나 데이터베이스 또는 서버에 액세스하는 경우에도 마찬가지입니다. 따라서 실제 위험에 따라 문제를 가능한 한 많이 높이려면 이관해야합니다.

고의로 위험한 방식으로 작업을 수행하지 않으면 요청한 작업을 수행하는 데 법적 단점이 거의 없습니다. 당신은 당신의 부채를 진술 할 고용 계약을 맺을 것이며, 당신은 기술에 관한 변호사와 상담 할 수 있습니다. 실제로 노출되면 일반 텍스트 암호에 대한 디자인 결정에 대한 서면 승인을 받으십시오.

이 기능이 최종 릴리스에서이 소프트웨어를 만들 때까지 어떤 소프트웨어인지 밝히지 않습니다. 나는 우리가 수용 가능한 방식으로 고객에게 정보를 제공 할 수 있기를 희망한다.

조금 더 걱정스러운 것은 '고객에게 알리는 것'에 대한 인용문입니다. 회사의 평판, 평판 등 (계약서에있는 조항)에 손해를 입히면 회사는 귀하를 고소 할 수 있으며, 참조 또는 다른 직업이 필요할 때 '휘파람'방어가 도움이되지 않을 수 있습니다.

보안 취약점의 영향에 대해 불만이 있다면 이력서를 정리하고 계속 진행하십시오.하지만 결정이 아니고 회사가 아닌 경우 왜 이것이 (법적으로) 당신에게 비난받을 수 있는지 알 수 없습니다 .

회사 는 귀하 를 고용 할 때 전문적인 배상 보험 형태를 취해야합니다. 이 해야 하는 경우에 모든 직원에 대한 적절한 법적 보호를 제공하는 것을 (예 : 암호화되지 않은 암호와 같은) 소프트웨어에서 발견되는 소프트웨어 또는 결함의 소프트웨어 또는 오용으로 잘못 가고.

직원으로서 당신은 그들이 요구하는 것을해야하는데, 어느 당사자도 법을 어 기지 않는 한 아무 문제가 없지만 회사가 원하는 것을하고 있다면 그것은 고객이 원하는 것을해야합니다. 의뢰인이 원하거나 요구 한 것이 아닌 것으로 밝혀졌으며, 그 사이에있는 전문 보상 보험은 귀하의 개인적 책임 / 책임으로부터 귀하를 보호해야합니다.

IANAL, 그러나 나는 당신의 자신의 변호사와 확인하는 것 외에도 회사 법률 팀과 함께 이것을 취할 것입니다.

추신 : 당신이 이것에 심각하게 놀라면 모든 관련 이메일을 전자 및 하드 카피로 가능하면 오프 사이트 어딘가에 저장하십시오.

새로운 직업을위한 시간. 이것을 구현하는 것을 잊어라. 움직일 시간이야 그들이 기꺼이 너무기만적이고 기만적이라면 버스 아래에 당신을 던지는 것을 두려워하지 않을 것입니다.

또한 사람들 소프트웨어의 보안 허점을 지적하는 많은 그룹 중 하나에 익명으로 연락 한 후에 두려워하지 마십시오. 이것은 일어나고있는 재앙입니다. 이것들을 저장할 확실한 이유는 없습니다. 상사가 당신에게 이유를 주었습니까? 사용자로 로그인 하시겠습니까? 비밀번호를보다 쉽게 ​​검색 할 수 있도록 하시겠습니까? 보다 안전하게 다룰 수있는 위의 답변 중 하나에 대한 답변을 얻지 못한 경우 계속 진행해야합니다. 떠날 때 이유를 말하지 않는 것이 가장 좋습니다.

프로그램에 대한 전체 액세스 권한이 비대칭 암호화를 사용하는 경우 복구 할 수없는 암호를 복구 가능한 형식으로 저장하기위한 지시 사항을 따를 수있는 방법

바이너리에 저장된 퍼블릭 키로 (항상 소금) 키를 암호화

암호가 일반 텍스트로 필요할 때 사람은 개인 키를 제공해야합니다.

개인적으로, 계약 또는 기타 정식 계약의 조항이없는 소프트웨어 엔지니어는 그들이 작업하는 제품의 보안 문제에 대해 법적 책임을지는 것에 대해 들어 본 적이 없습니다. 소프트웨어 엔지니어링의 법률 및 윤리에 관해 읽은 내용에서 시스템의 보안 요구 사항은 요구 사항 사양에 의해 결정되며 이는 법적, 산업 또는 회사 요구 사항을 나타냅니다. 시스템을 구축 할 때 보안 요구 사항을 충족하지 못하면 시스템이 지정된대로 구축되지 않았으므로 계약 조건을 완료하지 못한 것으로 간주됩니다. 특정 이벤트가 전개되는 방법은 엔지니어와 고용주, ​​고용주와 고객 간의 계약에 따라 다릅니다.

법은 또한 당신이해야 할 일을 말하지 않고 당신이 할 수 있거나 할 수없는 것을 말해줍니다. 어떤 산업 분야에 대해서는 언급하지 않지만 일부 유형에는 특정 유형의 데이터를 처리하는 방법에 대한 법률, 규정 및 규칙이 있습니다. 암호화 대상, 최소 암호화 수준, 액세스 관리 / 제어 요구 사항, 기타 등등. 해당 지역 (국가, 주)에 보안에 대한 규칙이없고 해당 산업에 보안에 대한 규칙이없고 소프트웨어 요구 사항에 보안 요구 사항이나 표준을 요구하지 않는 경우, 보안 요구 사항보다 윤리적 인 문제 일 수 있습니다. 법적인 사안.

소프트웨어 개발에서 윤리적 인 문제에 관해서는 소프트웨어 공학 윤리 및 전문가 실무 코드에 가입합니다 . 궁극적으로, 그것은 당신의 전화입니다. 그러나 암호를 일반 텍스트 또는 해독 가능한 형식으로 저장하는 것은 비 윤리적이라고 생각합니다.

프로젝트의 개발 프로세스를 따르십시오.이 기능이 요구 사항 문서에 작성된 경우이를 구현해야합니다.