Geliştiricilere ait hassas verileri koruma

Her iki kullanan bir kuruluş uygulaması çalışırken MySQL ve MongoDB veri depolarıyla. Geliştirme ekibim , uygulama bültenleri, bakım vb. İşlemleri gerçekleştirmek için makineye SSH erişimi var .

Kullanıcılar, uygulamada geliştiricilerin biraz fırtınaya neden olan bu verilere dolaylı olarak erişebilmeleri için son derece hassas verileri depolamaya başladıklarında, şirkette bir risk yarattım. erişilebilir.

Bana göre bu mümkün görünmüyor çünkü uygulama veritabanına erişebiliyorsa, makineye ve uygulama kaynağına erişimi olan bir geliştirici her zaman verilere erişebilecek.

Güvenlik, bir projenin sonunda el sallayabileceğiniz sihirli bir değnek değildir, 1. günden itibaren dikkate alınması ve inşa edilmesi gerekir. Cıvata değildir, yinelemeli ve gözden geçirilmiş bir dizi çözümün tutarlı bir şekilde uygulanmasıdır. Tüm sistemin bir parçası olarak düzenli olarak, en zayıf halka kadar güçlüdür.

Dururken, iyi bir ilk adım olan bir güvenlik endişesini işaretlediniz. Şimdi asgari olarak tanımlamanız gerekir: -

• Hangi verileri korumaya çalışıyorsunuz?
• Bu verileri kimden korumaya çalışıyorsunuz?
• Kim aslında neye (ve ne zaman) erişmeye ihtiyaç duyar?
• Bu verilerin tehlikeye atılmasının yasal / finansal / ticari etkisi nedir?
• Verilere erişimi olan bir kişi / grup için yasal / finansal / işletme ihtiyacı nedir?
• Önceden bir iş gereksinimi olmadığında, "güvenli ol, güvende kal" stratejisine karar vermek isteyen işletme hangi bütçeye sahip?
• Sistem verilere hangi erişime ihtiyaç duyar?
• Bu süreç ve bu uygulamanın dayandığı sistemler nelerdir?
• Bu ortamları güvenceye almak için ne yapılır?
• Bunu uygulamaktan ve tüm süreci gözden geçirmekten kim sorumlu olacak?

Bunları ayrıntılı olarak tanıyana kadar gerçekten çalışacak bir şeyiniz yok. Bu bilgi, bu tehditlere hangi hafifletmeleri uygulayabileceğinizi (ve uygulayamayacağınızı) ve nedenini tanımlayacaktır.

Yapılacak en iyi şey, gerekli deneyime sahip olmadığınızı ve bu deneyimle yeni birini getirmenin en iyisi olabileceğini kabul etmek olabilir. Bütçenin olmadığı cevabını çok sık duyuyorum - eğer gerçekten önemli olduğu düşünülürse, bütçe bulunacaktır.

Haklısın. Bir uygulama, kullanıcılara her seferinde ek bilgi vermeden şirket makinelerinde depolanan içeriğe erişebiliyorsa , servis sağlayıcısının programcıları, bakımcıları, sistem yöneticileri vb. Bu içeriğe erişebilir. Bu temelde kaçınılmazdır ve büyük bir güvensizlik kaynağıdır (Edward Snowden bir sysadmin'di ve "Çok Gizli" nin üzerinde özel ayrıcalıklara sahipti, çünkü sadece onlara verilmenin bir yolu yoktu.)

Bundan kaçınmanın tek yolu, kullanıcının bunu hiçbir zaman şirket makinelerine vermeyecek bilgiler sağlamasıdır. Bu çok sıkıcı ve hataya açıktır, çünkü hiç kimse güvenli bir erişim engeli oluşturmak için yeterli bilgiyi hatırlayamaz, ve bu nedenle insanlar kimlik bilgilerini elektronik olarak bir yerde depolamaya başlayacaklar ve bu da yeni saldırı hedefi olacaktır (ve muhtemelen sürdürdüğünüzden daha zayıf bir hedef). Ancak, “Çalışanlarımız fiziksel olarak kullanıcılarımızın içeriğine erişme yeteneğine sahip değiller” ifadesini doğru bir şekilde söylemek istiyorsanız, tek yol budur.

(Ayrıca böyle bir iş modelinin politik olarak savunulamaz hale geldiğini de unutmayın. İşletmeler tam olarak bunu yapmaya çalıştıkları için güvenlik hizmetleri tarafından kullanılmaya zorlandılar. Gizlilik güvencesi vermenin işletme değerine sahip olduğunu, ancak daha fazlasına sahip olamayacağını anlıyorum. işinde kalmanın temel amacı yerine işletme değeri.)

Oldukça haklısın; Bazı geliştiricilerin, yalnızca üretim sorunlarını tanılamak için Live verilerine erişmeleri gerekir. Yapabileceğiniz en iyi şey, ilgili kişilerin sayısını azaltarak olası hasarı sınırlamaktır.

With great power comes great ... opportunity to really, *really* foul things up. 

Pek çok geliştirici bu sorumluluğu ve başkalarını istemeyecek, sadece onu tutmak için "hazır" olmayacak ve bu yüzden olmamalıdır.

Soru: Geliştirme ekibiniz neden Canlı sürümler yayınlıyor ?
Bir Yayın Yönetimi "ekibine" ihtiyacınız var (bu sadece ekibinizin bir altkümesi, artı "Go / No-Go" gibi bir günlük "karar" almak için İş Temsilciliği olsa bile) öneririm. Bu, geliştiricilerin herhangi bir şeye Live dokunmaları için "gereksinimin" çoğunu ortadan kaldıracaktır .

Geliştiriciler ve şirket arasında herhangi bir gizlilik / gizlilik sözleşmeniz var mı? Ağır elli, ama biraz haklı olabilir.

Sorun, geliştiricilerinizin sistemlere erişebilmesi. Hata ayıklama için üretim verilerine ihtiyaçları varsa, o zaman onlara tüm bu hassas bilgilerin kaldırıldığı bir veritabanı dökümü verin. Ardından geliştiriciler bu çöplükle çalışabilir.

Yeni bir sürümün dağıtılması herhangi bir geliştirici içermemelidir - bu tamamen yönetici bir görev, hatta daha da iyisi - tam otomatik bir görevdir. Ayrıca iki çok farklı görev olmaktan çıkmanın ve dağıtmanın farkında olun. İşleminiz bunun farkında değilse, buna göre değiştirin.

Güvenlik # 1 numaralı kural: Birinin bilgiye erişimi varsa, o bilgilere erişebilir

Bu totoloji can sıkıcı, ama doğru. Bir bireye erişim verirseniz, verilere erişebilirler. Kullanıcılar için, bu genellikle erişim kontrolü anlamına gelir, ancak geliştiriciler için ... iyi ... onlar erişim kontrolünü yazmak zorunda olanlar.

Bu sizin için önemli bir sorunsa (ve olduğu gibi geliyorsa), yazılımınıza güvenlik sağlamayı düşünün. Yaygın bir desen, güvenli yazılımı katmanlarda tasarlamaktır. En alt katmanında, güvenilir bir geliştirme ekibi erişim kontrolünün en çıplaklığını yöneten bir yazılım tasarlar. Bu yazılım mümkün olduğunca çok kişi tarafından onaylanır ve doğrulanır. Bu kodu tasarlayan herkes her şeye erişebilir, bu yüzden güven çok önemlidir.

Bundan sonra, geliştiriciler bu çekirdek katmanın üstüne daha esnek bir erişim kontrolü kurabilir. Bu kodun hala V & Vd olması gerekir, ancak çok katı değil çünkü gerekli olanları kapsayacak şekilde her zaman çekirdek katmana güvenebilirsiniz.

Desen dışa doğru uzanır.

Gerçekten de, bu sistemleri tasarlama sanatının zor kısmı, her katmanı nasıl inşa edeceğimizdir, böylece geliştiricilerin hala şirketinize beklediğiniz güvenliği sağlarken gelişmeye ve hata ayıklamaya devam edebilmeleri için. Özellikle, hata ayıklamanın , düşündüğünüzden daha fazla imtiyaz gerektirdiğini kabul etmeniz gerekecek ve bunu kilitlemeye çalışmak çok sinirli geliştiricilere yol açacaktır.

Bir yan çözüm olarak, geliştiricilerin tüm güvenlik mekanizmalarını söküp ciddi hata ayıklama yapabilecekleri test amaçlı "güvenli" veritabanları oluşturmayı düşünün.

Sonunda, hem sizin hem de geliştiricilerin güvenliğin temel prensiplerini anlamaları gerekir: Tüm güvenlik, güvenlik ve kullanılabilirlik arasındaki dengedir. Sen gerekir bir şirket olarak kendi denge. Sistem tamamen güvenli olmayacak ve tamamen kullanılamayacak. Bu denge muhtemelen, şirketiniz büyüdükçe ve / veya geliştiricilerin talepleri değiştikçe de değişecektir. Bu gerçeğe açıksanız, bunu ele alabilirsiniz.

Ayrı bir veritabanı konuşlandırması da kullanan uygulamanın iki dağıtımını ayarlayın. Biri üretim dağıtımı, diğeri test dağıtımı.

Test dağıtımı yalnızca test verisine sahip olmalıdır. Bu, ya bu amaç için yaratılmış olan fantezi verileri ya da geliştiricilerin verinin arkasındaki gerçek insanları ve varlıkları bulmasını engellemek için anonimleştirilmiş olan üretim verilerinin bir kopyası olabilir.

İki finans firmasında, geliştiriciler üretim makinelerine erişemedi. Üretim makinelerini değiştirmek için yapılan tüm talepler bir onaylama sürecinden geçmek, bir senaryo ile ve yöneticiler tarafından onaylandı. Dev-ops ekibi asıl konuşlandırmayı tamamladı. Bu ekibin sadece çalışanlar olduğunu varsayıyorum ve geçmiş kontrollerini geçtim. Ayrıca geliştirici bilgilerine sahip olmadılar, bu yüzden isterlerse meraklı olamazlardı. Buna ek olarak, ortam değişkenlerinde depolanan gizli bir anahtarı kullanarak tüm veritabanı girişlerini şifreleyeceksiniz. Veritabanları halka açık olsa bile, kimse onu okuyamazdı. Bu anahtar daha fazla şifre korumalı (PBKDF) olabilir, böylece sadece bir yönetici kilidi açabilir. Sisteminiz açılışta yönetici şifresi gerektirebilir (veya dev-op'lara veya dev-ops yöneticisine devredilmiş olabilir). Temel olarak strateji, bilgiyi dağıtmaktır; bu nedenle, kritik bir gerekli bilgi kütlesi bir kişide yoktur ve kontrol ve dengeler vardır. Coca-Cola formülünü böyle koruyor. Dürüst olmak gerekirse, bu cevapların bazıları sonuçsuz.

MongoDB sınırlı güvenlik kontrollerine sahiptir ve güvenli bir ortama bağlıdır. Belirli bir ip ve bağlantı noktasına (ve 2.2'den beri ssl'ye) bağlanma ve kaba bir kimlik doğrulama, sunduğu şeydir. MYSQL GRANT o ON db.t TO ekler ... İstirahat halindeki veriler şifrelenmez ve ssl varsayılan olarak kullanılmaz. Bir çit yarat. Geliştiricilerin uygulama ile ilgili günlük dosyalarına salt okunur erişimi, hata ayıklama için yeterli olmalıdır. Uygulama yaşam döngüsünü otomatikleştirin.

Ansible, birkaç tennant çevre ortamındaki standart işlemleri (dağıtma, yükseltme, geri yükleme) yaparken, ana bilgisayarlar, portlar ve kimlik bilgileri gibi hassas ortam değişkenlerini saklamak için farklı şifreli kasalar kullanmamıza yardımcı oldu. Her kasanın yalnızca farklı görevlerle şifresi çözülebilirse ve yalnızca oturum açmış işlemler için yalnızca bir ana bilgisayardaki şifresi çözülebilirse, denetlenebilirlik kabul edilebilir güvenlik sağlar. SSH verirseniz, anahtar kurcalamayı önlemek için selinux kullanın, yönetim için ldap / kerberos kimlik doğrulaması olan bir bastion ana bilgisayarı kullanın ve sudo'yu akıllıca kullanın.