İşverenim yapmamı isterse güvensiz kod yazmayı kabul etmeli miyim? [kapalı]

İşverenim, şifreleri bir veritabanında açık metin olarak saklamayı gerektiren bir özellik (benden biraz daha iyi, aynı zamanda güvensiz olan bir ikili dosyada saklanan gizli bir şifreleme / şifre çözme işlevini kullanma) istememi istedi.

Müşterilerin, kullandıkları zaman güvenlik etkilerini kabul etmesi koşuluyla, böyle bir özelliği uygulamaya istekli olduğumu söyledim.

Bu problemi meslektaşlarınızla tartışırken, birileri bana yazılım mühendisi olarak ürünlerimizde ortaya koyduğumuz güvenlik problemlerinden kişisel olarak sorumlu olduğumuzu söyledi. Sözleşmeme baktım ancak benzer bir dava ile ilgili hiçbir şey bulamadım.

Yasal açıdan, böyle bir özelliği uygulamayı reddetmeli miyim? Bir müşteri bu özellik nedeniyle hasar görürse, güvenlik endişelerinden haberdar olsa bile işverenimin beni mahkemeye götürebileceği doğru mu?

EDIT: Bu sorunun ancak bir avukattan güvenilir bir şekilde cevaplanabileceğini biliyorum. Aynısı, soruları lisanslamak için de geçerlidir: Buradaki insanlar, bazen bir avukata danıştıktan sonra, başka bir yargı alanında uygulanacağını garanti etmeden anlayış ve tecrübelerini verirler. Ancak lisanslama burada açıkça bir konu olarak kabul edilir, bkz. Burada ne tür sorular sorabilirim? . Diğer programcıların da aynı sorunu yaşayabileceğini ve diğerlerinin daha önce bu duruma karşı karşıya geldiğini ve bunun için bir avukata danışabileceğini düşünüyorum.

Meslektaşınız, özellikle sözleşmenizde güvenlik sorumluluğu konusunda bir şey bulamadığınız için yanlış yönlendiriliyor. Olsa bile, yönetimden çelişen bir sipariş aldınız.

Kendini potansiyel davaya maruz bırakmanın tek zamanı, bilerek kendine zarar verirsen, kendi saatli bombanı, paskalya yumurtasını vb. Yaratmandır.

Çoğu durumda, şirket yazılıma sahip olur, bu yüzden kârın tadını çıkarırlar, ancak bireysel geliştirici yerine riskleri de üstlenirler.

Şahsen, yönetimin bu güvenlik özelliği ile ilgili sorunların farkında olduğundan emin olurdum, böylece önceden belgelenirdi ve işimi yapmaya devam ediyordum.

Olduğu söyleniyor, bir avukata danışın, yada-yada-yada.

Ne olursa olsun: İşvereninizin talimatlarını henüz uyguladığınızı açıkça gösteren bir e-posta veya başka bir kanıt olmadan asla böyle bir kod yazmayın.

Yasal açıdan, bir avukata danışın. Ben bir değilim, ne yaşadığınızı veya bazı şeyleri açıklamaya yardımcı olabilecek yasaların ne olduğuna dair hiçbir fikrimiz yok. Ancak her durumda bir avukata danışın, kişisel, profesyonel ve finansal geleceğinizle birlikte bir Internet soru-cevap sitesine güvenir misiniz?

Genel iş önerileri, güvenlik endişelerini yazılı olarak bildirmek için rezervasyonlarınızı yazılı olarak almanızı ve işvereninizin doğrudan siparişini almanızı sağlar. İşler güneye gider ve fana vurursa, tekrar düşmek zorunda kalırsın.

Bunun bir başka yolu da gereksinimlere daha derinlemesine bakmak olacaktır - çözdüğünüz sorunu değil, planı paylaştınız. Bir kediyi kaplamanın veya şifre arama gereksinimlerini ele almanın birden fazla yolu vardır.

Endişelenmeyeceğim - güvensiz bir özelliği kullanmak ve daha sonra kendinizden yararlanmak için ya da sadece ihmal ettiğiniz için onu yerleştirmek için kötü niyetli bir şekilde karar vermenize benzemiyor. Şirket bunu istiyor, birisi geliştirme süresi ile kullanıcı beklentileri arasındaki değiş tokuşun kabul edilebilir olduğuna karar verdi (her zamanki gibi) ve bu yüzden buna devam etmeniz gerekiyor. Geri dönüşler konusunda gerçekten endişeleniyorsanız, patronunuza bir e-posta gönderin ve yanıtınızı saklayın. Bunu bir kez yaptıysanız, bir çalışan olarak, haklısınız.

Bazen bunun kabul edilebilir olmasının nedenleri olabilir - örneğin, düz metin şifrelerini saklayan çok önemli bazı kritik çözümleri biliyorum, ancak sistemin geri kalanı güvenli hale gelsin diye güvence altına aldım. Bu sistem örneğin ayrı bir ağda. Hikayenin geri kalanını bilmiyorsanız (çoğu şirkette ortak bir durum), başka birinin bunu düşündüğünü makul bir şekilde bekleyebilirsiniz. Benzer şekilde, patronunuzdan bu e-postayı alırsanız, ne yaptığını bilmesini bekleyebilirsiniz.

Bu arada ... bu (tüketici olarak) kullanabileceğim bir ürün mü? Öyleyse .. nedir, yani kaçınabildim mi? :)

Canlı operasyonlar sırasında müşterilere zarar veren geliştiriciler tarafından eşit derecede büyük bir varlığa birçok böcek eklendiğinin farkında mıyız. Onların kasıtlı olduğunu düşünmüyoruz, ancak bu hala somut işlerimizin bir sonucudur ve hala işarete göre değil. Dolayısıyla, yaptığınız örnek, geliştiricinin (veya daha yüksek kararların) kararlarının müşteriyi etkilediği, izole edilmiş bir durum değildir.

İşte önerdiğim şey:

1. Öncelikle, elbette - yazılımı diğer şirkete teslim eden şirkettir. Bireye doğrudan kredi (takım içinde alkış ve maaş çekimi dışında) ve işin mülkiyeti verilmez. Yani bu, teslimatımızın bir parçası olarak iyi bir şey olmasa da, burada suçlu değilsiniz - karar size ait olmadığı sürece.

2. Profesyonel bir programcı olarak, README dosyasının veya ilgili belgelerin bir parçası olarak işlerin nasıl yapıldığına ilişkin kod ve tehlikelerin sınırlarını açıkça belirtirsiniz. Bir gereklilik belgesi varsa - önerilen test raporu vb. Sınırlamaları açıkça belirtmelidir.

3. Doğru karar vericiyi sorumlu tutmak için, bu tür belgelerin e-postalarındaki düşüncelerini teyit etmelerini rica ederim.

4. Riski doğru tartın. Veri kartı yazılımım şifreyi plan metninde saklıyor ancak bu önemli değil. Ancak, banka şifresini saklıyorsam veya veritabanına veya sunucusuna erişiyorsam, bu kabul edilemez. Bu yüzden gerçek riske dayanarak, sorunu olabildiğince arttırmak için arttırmalısınız.

İşinizi kasıtlı olarak zedeleyen bir şekilde yerine getirmediğiniz sürece, sizden istenen görevleri yapmanın çok az yasal yönü vardır. Yükümlülüğünüzü belirten bir iş sözleşmeniz olacak, teknik konular hakkında bir avukata danışabilirsiniz. Kendini gerçekten ifşa ediyorsan, düz metin şifrelerindeki tasarım kararının yazılı onayını al.

Bu özelliğin son sürümde bunu yaptığından emin olana kadar hangi yazılımı kullandığını açıklamayacağım. Hala müşterileri kabul edilebilecek şekilde bilgilendirmeyi umduğumuzu umuyorum.

Biraz daha endişelenmek, 'müşterileri bilgilendirmek' konusundaki teklifinizdir. Şirketlerinizin ayakta durması, itibarı vs.

Güvenlik deliklerinin sonuçlarından memnun değilseniz, özgeçmişinizi tazeleyin ve devam edin, ancak kararınız ve şirketiniz değilse, bunun neden “yasal olarak” sizi suçladığını göremiyorum. .

Şirketiniz , sizi çalıştırırken bir tür profesyonel tazminat sigortası yaptırmış olmalı . Bu gerektiğini durumunda tüm çalışanlarına yeterli yasal koruma sağlamak şey (örneğin şifresiz parolalar gibi) yazılımında bulunan varlık yazılım veya kusurları yazılım veya kötüye ile yanlış gidiyor.

Bir çalışan olarak sizden istediklerini yapmalısınız ve müşterinin istediğini yapması gerekiyordu, hiçbir taraf yasaları ihlal ettiği sürece, sorun yok, ancak şirketin istediğini yaparsanız, o zaman müşterinin istediği / istediği gibi olmadığı, aralarında olduğu ve profesyonel tazminat sigortasının sizi herhangi bir kişisel suçlama / sorumluluktan karşılaması gerektiği tespit edilmiştir.

IANAL, ancak bunu kendi avukatlarınızla kontrol etmenin yanı sıra şirketlerin hukuk ekibiyle de hallederim.

PS, bundan ciddi olarak korktuysanız, ilgili tüm e-postaları mümkünse elektronik ortamda basılı ve elektronik ortamda basılı bir yere kaydedin.

Yeni bir iş zamanı. Bunu uygulamayı unut. Hareket zamanı. Bu konuda çok cesaretli ve aldatıcı olmaya istekli olurlarsa, sizi otobüsün altına atmaktan da korkmazlar.

Ayrıca, isimsiz olarak, insanların yazılımlarındaki güvenlik açıklarına işaret eden birçok gruptan birine başvurduğunuzda korkmayın. Bu gerçekleşmeyi bekleyen bir felaket. Bunları saklamak için kesinlikle hiçbir sebep yoktur. Patronun sana bir sebep verdi mi? Kullanıcılar olarak giriş yapmak istiyorlar mı? Şifreleri almayı kolaylaştırmak mı istiyorlar? Yukarıdakilerden birine daha güvenli bir şekilde hitap edebileceğiniz bir cevap alamazsanız, devam etme zamanı. Gittiğinde, onlara nedenini söylememek en iyisi olur.

Programa tam erişime sahipseniz, asimetrik şifreleme kullanıyorsanız, şifrelerin geri alınabilir bir formatta saklanması için yönergeleri takip etmek için ne yapabilirsiniz?

(her zamanki gibi tuzlanmış) anahtarını ikili dosyada kayıtlı ortak anahtarla şifreliyorsanız

ve şifreler düz metin olarak gerektiğinde, bir insan aksi halde sunucudan uzak tutulan özel anahtarı sağlamaya ihtiyaç duyar

Şahsen, üzerinde çalıştıkları ürünlerdeki güvenlik sorunlarından yasal olarak sorumlu tutulduğumu, sözleşmedeki ya da diğer resmi sözleşmelere uymayan bir yazılım mühendisini hiç duymadım. Yazılım mühendisliğindeki yasalar ve etik hakkında okuduklarımdan, bir sistemin güvenlik gereksinimleri, aynı zamanda herhangi bir yasal, endüstri veya kurumsal gereksinime de atıfta bulunan gereksinim spesifikasyonuna göre belirlenir. Bir sistem oluştururken, güvenlik gerekliliklerini yerine getirmeme, sistem belirtilen şekilde inşa edilmediğinden sözleşme şartlarının yerine getirilmemesi olarak değerlendirilir. Özel olayların nasıl ortaya çıkacağı, mühendis ile işveren ve işveren ve müşteri arasındaki sözleşmelere bağlıdır.

Yasalar ayrıca size ne yapmanız gerektiğini değil neler yapabileceğinizi / yapamayacağınızı da söylemez. Hangi sektörde olduğunuzdan bahsetmiyorsunuz, ancak bazılarında belirli veri türleriyle nasıl başa çıkılacağına ilişkin yasalar, düzenlemeler ve kurallar var - şifrelenecek olanlar, minimum şifreleme düzeyleri, erişimi yönetme / kontrol etme gereklilikleri, ve diğerleri. Bölgenizde (ülke, eyalet) güvenlikle ilgili kurallar yoksa, endüstrinizde güvenlikle ilgili kurallar yoktur ve yazılım gereksinimleri güvenlik gereksinimlerini veya standartlarını gerektirmiyorsa, bu bir etik sorundan daha fazlası olabilir. yasal mesele.

Yazılım geliştirmede etik meseleler söz konusu olduğunda, Yazılım Mühendisliği Etik ve Mesleki Uygulama Kuralları'na abone oluyorum . Sonunda, bu senin çağrın. Ancak, şifreleri düz metin veya şifresi çözülebilen bir biçimde saklamanın etik dışı olduğunu düşünüyorum.

Projenizin gelişim sürecine uymanız yeterli: eğer bu özellik gereksinim belgesinde yazılmışsa, onu uygulayacaksınız.