Bir üretim veritabanına yanlışlıkla girmeyi nasıl önleyebilirim?


31

Kısa süre önce, bir geliştiriciyi yanlışlıkla bir aşamalı kopyaya geri yüklemesi gereken bir veritabanını prodüksiyona geri yüklemeyi denedim. Db adlarının benzer olduğu göz önüne alındığında kolay, yani, MüşteriAdı_Staging - MüşteriAdı_Üretim.

İdeal olarak, bunları tamamen ayrı kutular üzerinde bulundururdum, ancak bu maliyet engelleyicidir ve kullanıcı yanlış kutuya bağlanırsa kesinlikle aynı şeyin olmasını engellemez.

Bu bir güvenlik problemi değil, kendi başına - hazırlama veritabanında çalışan doğru kullanıcıydı ve üretim veritabanında yapılacak işler varsa, o da olacaktır. Bu endişeleri ayırmak için bir dağıtım görevlisi olmasını isterdim, ancak takım bunun için yeterince büyük değil.

Bunun nasıl önleneceği ile ilgili uygulama, yapılandırma ve kontroller hakkında bazı tavsiyeler almayı çok isterim.


25
Geliştiriciler üretim veritabanlarına veya tercihen herhangi bir erişime yazma erişimine sahip olmamalıdır .
Michael Hampton

12
@ MichaelHampton - Ben ve o. Ben de bir geliştiriciyim. Sen ne önerirsin?
Chris B. Behrens,

10
Her rol için ayrı kullanıcı hesapları (dev vs ops / DBA). Ve bol miktarda dikkatli olun.
Michael Hampton

2
Üretim ortamınızı ayrı bir kutuya almanızı şiddetle tavsiye ederim. Aksi takdirde, sahneleme ve üretim kaynakları - disk, cpu vb. - paylaşmak zorundadır.
Thorbjørn Ravn Andersen

1
Sadece bu veritabanlarına ayrı kullanıcı / şifreler var.
neutrinus

Yanıtlar:


32

Bu, sık sık yaptığınız bir şeyse, otomatikleştirin. İkiniz de geliştiriciniz olduğunuz için, bazı kodları yazmak evinizde olmalı. :) Cidden olsa ... otomatikleştirerek, gibi şeyler yapabilirsiniz:

  • Doğru sunucuya geri yüklediğinizi doğrulayın (örn. Dev -> prod geri yüklemesi yok)
  • Bunun doğru "tip" veritabanı olduğunu doğrulayın (sizin durumunuzda "evreleme" ve "üretim")
  • Msdb'deki yedekleme tablolarına bakarak hangi yedeklemelerin otomatik olarak geri yükleneceğini belirleyin.

Et cetera. Sadece hayal gücünle sınırlısın.


1
Bu ilginç bir fikir ... zaten db restorasyonlarını yöneten bir kodumuz var (otomatik testler için). Sadece evreye işaret edenlerin arasına bir soyutlama katmanı koyabilirdik, böylece üretime dönmek tamamen farklı bir süreçti ...
Chris B. Behrens

11
Şimdi portallarla düşünüyorsun. :)
Ben Thul

4
Üretimi etkileyen otomatik işler için, örneğin hazırlama eşdeğerine bakma ihtimalini azaltmak için kullanıcının "üretim" kelimesini yazmasını gerektiren manuel bir adım eklemeyi seviyorum.
Joe Lee-Moyet

2
Hiç kimsenin varsayılan olarak üretime erişimi olmamalıdır diye reddettim. Bir ürün şifresi almak için özel bir işlem yapmanız gerekir. Uygunsuz ama gerçekten asgari.
Oliver

1
@BenThul Prod erişimi için farklı bir hesap eklemek ve bunu bir adım daha uygunsuz hale getirmek hala benim için doğru çözüm. İşin gereği DEV'nin 2 dakikadan tasarruf etmesini sağlamak değil, mükemmel bir şekilde bir prod hesabına taşınabilen DB'yi geri yüklemek.
15'de OliverS

32

Sorudaki varsayıma katılmıyorum - bu güvenliktir - ama aynı zamanda otomasyonun günü kendi kendine kurtaracağı konusunda hemfikirim. Sorunla başlayacağım:

Sen mümkün olmamalıdır yanlışlıkla yapmak üretime şey!

Buna yanlışlıkla otomatik şeyler yapmak da dahildir.

Sistem güvenliğini "kimin ne yapmasına izin verilir" gibi kavramlarla karıştırıyorsunuz. Geliştirme hesaplarınız yalnızca kopyalarına, sürüm kontrol sunucusuna ve dev veritabanına yazabilmelidir. Üretimi okuyabilir / yazabilirlerse, müşteri verilerini çalmak için saldırıya uğrayabilirler veya istismar edilebilirler veya (gösterdiğiniz gibi) müşteri verilerini kaybetmek için yanlış şekilde kullanılabilirler.

İş akışınızı düzenleyerek başlamanız gerekir.

  • Geliştirici hesaplarınız kendi kopyalarına, sürüm kontrollerine yazabilmeli ve belki de sürüm kontrolünden bir test ortamına çekebilmelidir.

  • Yedekleme kullanıcıları yalnızca üretimden okuyabilir ve yedekleme mağazanıza yazabilir (ki bunlar uygun bir şekilde korunmalıdır).

  • Üretim üzerine başka bir okuma / yazma yapmak, özel ve uygunsuz kimlik doğrulaması gerektirmelidir . İçeri giremezsiniz veya giriş yaptığınızı unutmamalısınız. Fiziksel erişim kontrolü burada faydalıdır. Akıllı kartlar, hesap "flip" anahtarları, aynı anda çift anahtar erişim.

    Üretime erişmek, her gün yapmanız gereken bir şey olmamalıdır. İşin çoğu, dikkatli bir incelemeden sonra test platformunuzda ve mesai dışı dağıtımların yapımında olmalıdır. Biraz rahatsızlık sizi öldürmez.

Otomasyon çözümün bir parçasıdır .

Tam geri dönüşün (VCS'ye yükleme, kapsama alanı denetleme, test sunucusuna çekme, otomatik testler yapma, yeniden doğrulama, yedekleme oluşturma, VCS'den çekme) uzun bir süreç olduğu gerçeğine kör değilim.

Budur Ben'in Yanıt başına, nerede otomasyon kutu yardımı. Belirli görevleri yerine getirmeyi çok daha kolay hale getiren birçok farklı betik dili vardır. Sadece aptalca şeyler yapmayı çok kolay yapmadığından emin ol. Doğrulama adımlarınız yine de açıklanmalı (ve tehlikeliyse) düşünmeden yapılması uygun ve zor olmalıdır .

Ancak yalnız , otomasyon yararsızdan daha kötü. Daha az düşünce ile daha büyük hatalar yapmanıza yardımcı olacaktır.

Her boyutta takım için uygundur.

Takımının büyüklüğünü işaret ettiğini fark ettim. Ben bir erkeğim ve kendimi bunun içine soktum, çünkü yalnızca bir kişinin kaza geçirmesi gerekiyor. Tepegöz var ama buna değer. Daha güvenli ve çok daha güvenli bir geliştirme ve üretim ortamı ile son buluyorsunuz.


2
Ayrıca yapmak istediğim bir şey, kullanıcı başına iki adlandırılmış hesap kullanmak. Bunlardan biri normal kullanıcı girişi, işlem, günden güne çalışma, vb. İçin kullanılırken, ikinci hesap (genellikle + veya alt çizgi gibi bir tür sonek ile) kullanıcının ihtiyaç duyduğu her şeyi yapma ve geliştirme hakkına sahiptir. Bu şekilde, kullanıcı dev'in aksine prod'a itmek için aktif bir karar vermelidir. Bu yukarıda açıklanan mermi 3'e benzer, ancak değeri göstermek için önemli ek altyapı veya masraf gerektirmez.
user24313

3
Ürün hesabınızda eşya bakımı dışında bir şey yapma alışkanlığı edinmekten kaçınmak da önemlidir. Bu amaçla, prod'un kaynak kodunu göremediğinden, IDE başlatamadığından vs. emin olun.
Eric Lloyd

Bu eş zamanlı dönüş çift anahtarlı sözleşmelerden birini nereden edinebilirim ve USB ile birlikte geliyor mu?
Lilienthal,

Başka kudreti yardım tamamen otomatik hale evreleme ve dev (bir veya iki tıklama) prosedürleri, ancak o şey değil tamamen üretim dağıtımları otomasyonu. Üretime yönelik herhangi bir şey yapmak için ancak diğer ortamlara değil, manuel olarak kutuya uzaktan kumanda etmek zorunda olmanız, önerdiğiniz gibi kolaylık açısından önemli bir farktır. (Hala dahil olan tüm adımları yazabilir ve bu betiği tüm ortamlarda kullanabilirsiniz; demek istediğim, üretim için bahsedilen komut dosyalarının çalıştırılmasını el ile başlatmanız gerektiğidir.) Tabii ki, kimlik doğrulama türüne ek olarak yapılabilir. önerdiğiniz prosedürler.
jpmc26

1
@Lilienthal Yüksek güvenlikli tiyatro için bir metafordu, ancak her geliştiriciye ucuz bir şekilde takılan USB çubukları taklit edebilir ve ardından tehlikeli şeyleri çalıştırırken otomasyonunuzu seri numaralarından en az iki tanesini kontrol ettirebilirsiniz. Daha büyük ekiplerde, kimin üretime müdahale ettiğini görmek için giriş yapın ve her şey ters gittiğinde doğru kişileri sorumlu tutun.
Oli

12

İş arkadaşlarımdan birinin buna ilginç bir yaklaşımı var. Üretim için yaptığı terminal renk şeması titizdir . Gri ve pembe ve okunması zor olan, teorik olarak yazdığı her şeyi yazmayı hedeflediğinden emin olması gerekiyordu.

Kilometreniz değişebilir ... ve muhtemelen tek başına kurşun geçirmez olmadığını söylemek zorunda değilim. :)


2
Ayrıca, üretim sunucularına terminaller / db bağlantılarında büyük bir kırmızı arka plan rengini ve PC'lerde yönetici hesabı için parlak kırmızı duvar kağıtlarını kullanıyorum ...
Falco

Evet, bunu düşünüyordum. İtfaiye üretimini kırmızı yapın ...
Chris B. Behrens

Renk kodlaması yardımcı olur. Aynı IDE'deki gibi.
Thorbjørn Ravn Andersen

1

Geliştiriciler, üretim veritabanındaki şifreyi bilmemelidir. Prod şifresi rastgele ve unutulmaz olmalıdır - klavyenin karıştırılması ( Z^kC83N*(#$Hx) gibi bir şey . Dev şifreniz $YourDog'sNameya correct horse battery stapleda her neyse olabilir.

Elbette, müşterinin uygulamasının konfigürasyon dosyasına bakarak, özellikle küçük bir takımsanız, şifrenin ne olduğunu öğrenebilirsiniz. Ürün şifresinin olması gereken tek yer orası. Bu, prod parolasını almak için kasıtlı bir çaba göstermeniz gerektiğini garanti eder.

(Her zamanki gibi, üretim veritabanınız için anında yedeklemeniz gerekir. Örneğin, MySQL ile ikili günlükleri artımlı yedeklemeler olarak arşivleyin. PostgreSQL için önceden yazılan günlükleri arşivleyin. her türlü felaket, kendi kendine bulaşan veya başka türlü.


Buna tam olarak katılıyorum, çünkü herhangi bir gerçekçi büyük ortamda, geliştiricilerin / yöneticilerin üretim veritabanına erişmeleri gereken oldukça düzenli durumlar vardır. Kusursuz bir sisteme sahip kusursuz bir dünyada kesinlikle böyle bir şey olmamalı, ancak çoğu sistemde bazı kritik üretim verilerini elle düzeltmeniz gerektiğini biliyorum ... Bu yüzden Oli ile birlikteyim, üretim oturum açma işlemi elverişsiz, ancak uygulanabilir olmalı
Falco

1
@Falco Yine de önerdiğim şey bu. Uygunsuz ama uygulanabilir.
200’de

Yaklaşımınızla ilgili sorun yalnızca, bir acil durum varsa ve üretim azalırsa, zaman önemlidir. Yani devlerin şifreyi nerede bulacağını bilmeli ve hızlı bir şekilde alabilmelidir. Etrafında sormaları gerekiyorsa, depoda arama yapın ve dosyaları yapılandırın ve değerli zamanınızı kaybettiğinizi deneyin = para. Bu yüzden, şifrenin herkesin nereye bakacağını bildiği bir yerde olmasını tercih ederim, ama yine de uygunsuz, ama gerektiğinde hızlı
Falco

2
@Falco Prod ortamları dev ortamlarını yakından yansıtması gerektiğinden, konfigürasyon dosyası, dev makinelerinde olduğu gibi prod sunucusunda benzer bir yerde olacaktır. Herhangi bir yetkili geliştirici nereye bakacağını bilmeli ve nereye bakacaklarını bilmiyorsa, o zaman bu gecikmeyi istersiniz - tam olarak soruda belirtilen türün zarar görmesini önlemek için.
200’de

Şifreleri bilmemek kazaları engellemez. Aksine, yalnızca bir kez parola aramasını sağlamak için motivasyon yaratır ve bundan sonra geliştirici bash geçmişini kullanmaya başlayabilir veya hatta veritabanına bağlanmak için bir takma ad oluşturabilir. Ve sonra, kazaların olması daha olasıdır.
k0pernikus

0

Kısa cevap RBAC - rol tabanlı erişim kontrolü.

Tüm ortamlar için izinlerinizin farklı olması gerekir - UAC gibi şeyler gibi can sıkıcı olduğu için onlara ihtiyacınız var: özellikle PROD ortamları için.

Orada asla bakmaksızın kuruluş / takımdır ne kadar küçük - Devs Prod doğrudan erişim olması için bir sebep. "Dev" iniz aynı zamanda "Stage" ve "Prod" şapkalarını da takabilir, ancak farklı ortamları vurmak için farklı kimlik bilgilerine ve işlemlerine sahip olması gerekir.

Can sıkıcı mı? Kesinlikle. Ancak bu, ortamlarınızı etkilemekten kaçınmanıza yardımcı oluyor mu? Kesinlikle.


0

Hızlı ve basit bir çözüm: biri yalnızca geliştirme veritabanına erişimi olan normal geliştirme çalışmanız için ve gerçekte üretim veritabanında çalışmak için farklı bir hesap olan iki farklı kullanıcı hesabı kullanın. Bu şekilde, üretimde herhangi bir değişiklik yapmadan önce kullandığınız hesabı aktif olarak değiştirmeniz gerekecektir ; bu, yanlışlıkla hataları önlemek için yeterli olacaktır.

İki web siteniz veya iki sunucunuz veya iki tüm ortamınız varsa, aynı yaklaşım kullanılabilir: geliştirme için bir kullanıcı hesabı üretime erişimi olmayan (veya en azından yazma erişimi yok ), üretim sistemi üzerinde çalışmak için başka bir kullanıcı hesabı ( s).


Bu, rutin işler için standart bir yönetici olmayan hesaba (e-posta okumak, webde gezinmek, bilet izlemek, dosyalama zaman çizelgeleri, belge yazmak, vb.) Ve gerçekten çalışırken kullanılabilecek farklı bir tam yönetici hesabı olan bir sysadmin ile aynı yaklaşımdır. sunucularda ve / veya Active Directory'de.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.