Geliştiricilere SELECTüretim veritabanlarını sorgulama ( / salt okunur) izni verilmelidir mi? Çalıştığım önceki yer, geliştirme ekibinin db_datareaderrolü vardı ; Çalıştığım yerde geliştirme ekibi üretim örneğine bile bağlanamıyor.

Test örneklerinden biri, haftada bir kez üretim yedeklemesinden geri yüklenen bir üretim kopyasıdır, bu nedenle geliştiricilerin verileri görmesiyle ilgili herhangi bir sorun yoktur.

Geliştiricilerin üretimi sorgulamasına izin vermemek için hangi iyi nedenler vardır (yalnızca hassas verileri okumalarına erişmelerini isteme dışında)?

Geliştiricinin herhangi bir destek sorumluluğu olup olmadığına gerçekten bağlıdır. Üçüncü hat desteği için kanca kullanıyorlarsa, bunun için büyük olasılıkla üretim veritabanına bakmaları gerekecektir.

Genelde, orada yapmak gerçekten gerekli olmadıkça, üretim sunucusunda bir şey yapmak kötü bir fikirdir.

Çoğu geliştirme amacıyla, üretim veritabanının aynaları veya anlık görüntüleri yeterli ve muhtemelen canlı üretim veritabanından daha iyi olacaktır. Entegrasyon içeren bir şey yapıyorsanız, içlerinde ne olduğunu kontrol edebileceğiniz kararlı veritabanı ortamları isteyeceksiniz. Uzlaşmayı içeren herhangi bir şeyin zaman içinde kontrollü bir noktaya bakabilmesi de gerekir.

Sorun şu ki, üretim aynası ortamlarınız veya geliştiricileriniz için üretim verilerinin bir kopyasını koymak için herhangi bir yönteminiz yoksa, bu biraz farklı bir sorudur. Bu durumda geliştiricileriniz gerçekten en az bir ayna ortamına ihtiyaç duyar. Veride sorunun ne olduğunu göremiyorsanız, sorunu gidermek biraz zor olacaktır.

Hayır.

Geliştiriciler olmamalıdır aşağıdaki nedenlerden dolayı üretim veritabanı sistemlerine erişim hakkına sahip:

1. Kullanılabilirlik ve Performans : Bir veritabanında salt okunur haklara sahip olmak zararsız değildir . Kötü yazılmış bir sorgu şunları yapabilir:

   1. Diğer kritik süreçleri engelleyerek tabloları kilitleyin.
   2. Veri önbelleğinizi çöpe atın, diğer işlemleri diskten verileri yeniden okumaya zorlayın.
   3. Depolama katmanınızı vergilendirerek depolamayı paylaşan diğer hizmetleri de etkileyin.

2. Güvenlik : Üretim veritabanınız aşağıdakiler gibi hassas bilgiler içerebilir:

   • şifre hash
   • Fatura bilgileri
   • diğer kişisel olarak tanımlanabilir bilgiler

   Sadece bu bilgilere kesinlikle erişmesi gerekenler bu bilgiye sahip olmalıdır. İyi organize olmuş bir şirkette geliştiriciler bu insanlar arasında değildir. Ayrıca, geliştiricileri bu verilerle üretim sistemlerine erişebiliyorsa, şirketiniz PCI ve SOX uyumluluğunu alamaz.

   Bunun nedenleri açıktır. Geliştiricinin geliştirme çalışması, yayınlanmadan önce birçok elden geçer. Kötü amaçlı bir geliştiricinin doğrudan üretim erişimine sahip olması üretim verilerinizi çalmaktan veya canlı veritabanınızı dizlerinize sokmaktan ne alıkoyuyor?

   “Ama bu DBA'lar için de geçerli! Bunu yapabilirler!” Kesinlikle. Sorumlu olarak mümkün olduğu kadar az sayıda kullanıcı istiyorsunuz.

Evet.

Geliştiriciler gereken üretim sistemlerine erişimi vardır.

Şirketimde üretim veritabanlarıyla ilgilenen dört ekibimiz var. Onlar:

1. Veritabanları için şema ve kod tasarlayan ve yazan geliştiriciler . Üretimdeki veritabanlarına erişimi yok. Yine de bazen Yöneticilerle veya Destek görevlileriyle birlikte oturur ve canlı bir şeye bakmalarına yardımcı olurlar.
2. Yöneticiler , monitör dağıtmak ve üretimde veritabanlarını yönetmek.
3. Destek insanlar zamana duyarlı üretim problemlerini araştırmak ve düzeltmeleri gelişebilir böylece geliştiricilere geri bildirim sağlamak.
4. İş Zekası , üretim veritabanlarından düzenli olarak bu veritabanlarının kopyalarını tazeleyen kopyalarını veya dikkatlice yazılmış ve kalite kontrol özütlerini kullanarak (genellikle Yöneticiler tarafından tasarlanan) veri toplayan insanlar .

Bu diğer gruplarda bazı eksiklikleriniz olduğunda, geliştiricilerinize üretim erişimi sağlamanız uygundur.

Örneğin:

• Destek ekibiniz yok. Zamana duyarlı bu üretim sorununda hata ayıklamak için nereye bakacağını kim bilecek? Geliştiricileriniz. Onlara " bardağı kır " erişimi verin.
• BI ekibiniz yok. Yöneticileriniz raporlarla veya özlerle ilgili bir şey yapmaz veya istemezler. İcralarınızın her sabah gördüğü raporda kim sorun giderecek? Geliştiricileriniz. Onlara bu raporları ve ekstreleri ayıklamak için sınırlı erişim izni verin.
• Yönetici ekibiniz yok. Çok küçük veya yeni bir şirketdesiniz, bu yüzden "kazayla DBA" ya merhaba deyin. Geliştiricileriniz yöneticileriniz olarak ikiye katlanır ve bu nedenle üretime tam erişim gerekir.

Performans BÜYÜK bir sebep olurdu.

Sadece verileri değiştiremedikleri için sunucuyu etkileyemeyecekleri anlamına gelmez. Kötü yazılmış bir sorgu, üretim ortamını dizlerine getirebilir ve potansiyel olarak başka sorunlara neden olabilir (tempdb taşmaları gibi):

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

Bu felaket için bir reçete. Bunun, sırasıyla sipariş verilen bir kartezyen ürün olduğuna dikkat edin, bu, tempDB'de sıralanacağı anlamına gelir.

İlke "en az ayrıcalık" ve "bilmesi gereken" dir: geliştiriciler bu testi geçiyor mu?
Özellikle de Denetçiler veya Sarbannes-Oxley çalmaya geldiğinde.

O zaman benim bir sonraki varsayım: geliştiriciler aptaldır. Öyleyse 3. hat desteği için söylemeye ihtiyaçları varsa , o zaman kimin ihtiyacı var? Web maymunları, genellikle desteklemeleri bekleniyorsa, veri tabanı türlerinden başka bir şey yapmazlar.

Öyleyse, erişime kalıcı olarak ihtiyaç var mı? Bir SQL girişi kullanarak veya oturumu kapatmayı gerektiren alternatif bir Windows hesabı kullanarak "cam kırma" erişimine sahip olabilirler. Bizim durumumuzda, veri sahibi (umarım bazı teknoloji meraklısı iş kişi) ve onaylaması için BT yöneticisi oldu.

Ben var geliştiriciler karşı test ya da üretim sorgu çalıştırabilmek ve görülen aşağı çekmek , çünkü cehalet. Bunu söylemek gerekirse, geliştiriciler eylemlerinin sorumluluğunu üstlenmeli: eğer bir sunucuyu yıkarlarsa buna göre acı çekmelidirler. Bir olaydan sonra birisini düşürdüm ...

Bunlar elbette oldukça makul bir boyutta bir dükkan kabul ediyor. Daha fazla şapka halkı, sahip olabileceğiniz görevlerin daha az ayrılmasını sağlar

Ayrıca, geliştiricilerin son verilerle ilgili sorguları çalıştırabilecekleri bir ortam var mı? Son mağazamda, prod, bunu sağlamak için her gece bir test sunucusuna geri yüklendi.

Bence cevabım, BT’de olduğu gibi “bağlı” dır.

Çok sayıda hassas şirket ve müşteri bilgisine sahip büyük bir ERP veritabanı? Muhtemelen hayır (hem güvenlik hem de performans nedeniyle).

Donut ve pizza fonlarına katkıları izleyen Access ön uçlu, 5 MB'lık bir veritabanı mı? En azından salt okunur erişim için çok fazla fark yaratmayacaksınız.

Kabul edilirse, ilk örnek ikinciden çok daha yaygındır, ancak bunlar, bu tür politika kararlarını almaktan sorumlu olup olmadığınızı bilmeniz gereken farklardır. Ancak, kapak tarafında, 5 MB'lik bir donut ve pizza fonu veritabanının 50 GB'lik parça numaraları / müşteri-kredi-kart-numaraları / kiminle-bildiğini- ne kadar hızlı bir şekilde kaplayabildiği şaşırtıcı. izin verirseniz başka bir veritabanı.

Her zamanki 24/7 OLTP ortamında, normal geliştiricilerin üretimde bulunmasına izin verilmemelidir. Dönem! Zaman zaman özel bir sebep belirlenirse, istek üzerine izin verilebilir. Ama her zamanki gibi hayır.

Bunun için birçok sebep gördüm:

• SELECT * aşağıdakilere giden büyük bir tablodan:

  • performans sorunları (kartezyen ürünler);
  • Sonunda siteyi dizlerine taşıyan sorunları engellemek;
  • çoğaltmayı bir askıya alan zincir engelleme;
  • TempDB sürücüsünü dolduran büyük veri setini sipariş etmek. Tam delilik neden oldu :-)!
  • o gece üretimden sorumlu DBA için yüksek tansiyon;

• hassas verilerin okunması (bir geliştirici, kredi kartı bilgisine erişim olmamalıdır.

Eminim daha da fazla sebep vardır.

• Güvenlik: Geliştiricilere sağladıklarında sterilize edilmiş hassas bilgiler olabilir.
• Paranoya: Bazıları sadece seçili erişim ile veriyi karıştırabileceğini düşünebilir.
• Performans: Bir sorgunun gerçekleştirilmesi için bazı kaynaklar gerekir ve geliştiricilerinizin kod yazarken mükemmel olduklarını söyleyemezsiniz.

Dikkate alınması gereken birkaç madde

• Veriler duyarlı mı?
• Programcılar çekirdek güvenilir bir ekibin parçası mı yoksa bazı offshore ekibin bir parçası mı?
• Performansı etkilemek için araştırılmakta olan verilerin boyutu nedir?
• Projenin ölçeği veya uygulanan dolar nedir?
• Çalışma süresi ne kadar kritik?

Küçük dolarlar daha az işlem gerektirir, daha hızlı bir gelişim akışı gerektirir.

Daha büyük dolarlar daha fazla süreç gerektirir, daha katı geliştirme uygulamaları standartları gerektirir.

Uygulamalarınızı yaptığınız şeye uyarlayın.

Çok büyük bir şirket için geliştirici olarak çalışıyorum. Her türlü desteği yapacak geliştiricilerin (temel olarak hepsi) ilgili üretim veritabanlarına erişimi vardır. Ben sadece belirli bir ekip için konuşabilirim ama neden size söyleyecektir biz erişimi vardır.

1. Günlük işlemlerimizi takip etmek için gerçek zamanlı erişime ihtiyacımız var. (Bir gösterge panomuz olmasına rağmen, her şeyi derinlemesine izleyebilmemiz gerekir. Bu özelliğin gösterge panomuzda olması güzel olsa da, bunun pratik olmadığını gördük.)
2. Herhangi bir üretim hatasını araştırmak için gerçek zamanlı erişime ihtiyacımız var, çünkü gecikmelerin çok büyük bir etkisi olabilir. (Buradaki başarısızlıklarımızı tartışmayacağım. Her türlü gelirler)
3. İş kullanıcıları için sık sık özel raporlar yapmamız gerekir ve bu bilgilerin güncel olması gerekir. (dba bunu yapacak vaktimiz yok ve onları bekleyecek vaktimiz yok. İdeal değil, elbette.)
4. DDL / DML dağıtımlarının / yamalarının üretimini doğrulamamız gerekiyor. (DBA'lar onları dağıtıyor, ancak yalnızca nasıl yapılandırılması gerektiğini biliyoruz. Veri tabanı yapımız hakkında DBA'lardan daha fazla şey biliyoruz. Burada tuhaf olabiliriz, ancak veri tabanı çok karmaşık çünkü işimiz çok karmaşık.)

Performans bir endişedir. Geliştiricilerin yavaşlamalara neden olduğu durumlarımız var. Bununla birlikte, bunlar izole edilmiş örneklerdir ve SQL'imiz o kadar performanslıdır ki geliştiricilerin sorgularının etkisini anlamadığı nadirdir.

Bu sorunun sorulması için kişinin şu anda erişiminin olmadığı varsayılmalıdır. Bir kuruluşun yazılımı geliştiriyorsa ve bu bir müşteri sorununu gidermek için ise ve müşteri veritabanının bir kopyasını veriyorsa, o zaman 'evet'. Aksi takdirde, geliştiricileri üretimden uzak tutmayı savunur ve araştırma ihtiyaçları için alternatif alternatifler yaratırdım. Diş macunu tüpün dışına çıktığında, tekrar yerine koymak zordur.

Haklı çıkarma yükünün, erişim isteyenlerin üzerinde olması gerektiğine katılıyorum. Genelde danıştığım ortamlarda, küçük bir ortam olan üretim sistemlerine erişebildim ve destek kişisiydim. Desteğe destek verdiğim yedekleme işlemlerine, vb. (Özel bir destek geliştirici aracılığıyla) üretim verilerine dolaylı erişime sahip oldum.

Önemli olan şudur: Her şeyin sorunsuz çalışmasını sağlamak için kancadayken bu erişime ihtiyacınız var ve finans elemanının çalışmayan bir şey hakkındaki sorusuna cevap vermelisiniz. Bu durumda her zaman günlük verilerden bile çalışamazsınız. Diğer taraftan, erişim ne kadar fazla olursa, o kadar kötü olur. Genelde bir danışman olarak, gerekmedikçe bu tür bir erişimden kaçınma eğilimindeyim. Finansal veri tabanları üzerinde çalıştığım için, istediğim son şey kendi faturalarımı girmekle suçlanmak: - D.

Diğer taraftan, erişime ihtiyacınız yoksa buna sahip olmamalısınız. Hassas veri argümanını gerçekten almıyorum, çünkü geliştirici muhtemelen bunun doğru şekilde yapıldığından emin olmak için kancaya takılıyor (ve bir hata raporu geldiğinde neyin saklandığına bakmadan bunu doğrulamak çok zor). Geliştiricinin uygulamasının depoladığı verilere bakması için geliştiriciye güvenemiyorsanız, uygulamayı yazmak için geliştiriciyi işe almamalısınız. Geliştiricinin verileri engellemesinin ve e-postayla göndermesinin çok fazla yolu vardır ve bundan asla emin olamazsınız. MAC kontrolleri burada yardımcı olur, ancak uygulanması oldukça karmaşıktır.

Yanımdaki büyük mesele yazma erişimiyle ilgili. Bir geliştiricinin erişimi yoksa, bir servet sahibi ise, geliştiricinin yazma erişimi yoktur. Kitapların bütünlüğünü doğrulamak istiyorsanız, olabildiğince az kişiye yazma erişimini korumak istiyorsunuz. Denetim izleri, geliştiricilerin erişimi yoksa, doğrulamak çok daha kolaydır. Geliştirici okuma erişimine sahipse, her zaman yazma erişimi sağlayabilecek bir ayrıcalık escallation eki olup olmadığına ilişkin bazı sorularınız olur (belki de saklı prosedürde SQL enjeksiyonu?). Hazırlama ortamlarına erişimim olduğunda, genellikle müşteri faturalandırma bilgilerine tam olarak erişebiliyordum. Gerçi çalışan bir hazırlık ortamı varsa, genellikle aktif soracaktır değil zorunlu olmadıkça üretim erişmesini.

Yani bu elbette mükemmel değil. Bir geliştirici hala kolayca tespit edilemeyecek olan uygulamaya, arka kapılar inşa edebilir, ancak bu yaklaşım, bana bu kaygı duyduğunu düşündüğü günden itibaren bir günden itibaren mevcut olduğu gerçeği göz önüne alındığında makul bir yaklaşımdır.

Bu yardımcı olur umarım.

Düzenleme: Sadece çalıştığım daha geniş ortamlarda, finans sistemi için genellikle birkaç günden birkaç aya kadar değişen tam yedekleme verilerine erişebildiğimi de ekledim. Bu benim işim için her zaman yeterince iyi olmuştur ve kırıldığı tek zaman, finans adamlarının daha yeni verilerle test edebilme yeteneklerine ihtiyaç duymalarıydı.

Erişime sahip olmamak, geliştiricileri ve diğerlerini yanlışlıkla verileri bozmamaktan veya görüntülemekten korumak için iyi bir şeydir. Bu aynı zamanda şirketleri kanunları ihlal etmekten korur (örn. Hipaa ihlalleri ve gizlilik endişeleri)

Bir geliştirici, üretim ortamına asla gerçekten ihtiyaç duymaz, eğer zor bir böceğin yeniden üretilememesi durumunda, geliştiricilerin bakış açısından daha kolaydır.

Ancak bir geliştirici mini dökümlere veya günlük dosyalarına koyabilir ve hatayı yeniden oluşturmak için PDB sembol dosyalarını kullanabilir.

Verilerin bir test ortamına getirilmesi gerekirse, fazladan iş yaratabilecek verileri temizlemek için bir tür işlem için tipiktir.

Üretim dediğiniz alanda kullanılan veritabanı yazılımına bağlı olarak, geliştiricinin veritabanına erişmesi için yeni bir lisans gerekebilir;

Şirketiniz size üretim hatalarını ayıklamak ya da araştırmak için araçlar sağlamazsa, bunun nedeni, üretim verilerine erişiminizin olmamasıdır.

Veri, çoğu uygulamanın en değerli parçasıdır!

Performans nedenlerden biri olabilir.

Geliştirici sorguları, genellikle uygun şekilde ayarlanıncaya kadar aşırı kilitleme veya kaynak kullanımına neden olarak yetersiz olabilir.

Bir üretim sistemi, geliştiricilerin deney yapması için uygun bir yer değildir.

Bu, DBA'ya ve geliştiriciye ne kadar güvende olduğuna bağlıdır. Genellikle geliştiricilere, üretim veritabanlarına sorgu (okuma) ayrıcalıkları verilir. Genel bir kural olarak, geliştiriciler gerekir sadece deneme / dev veritabanları ile çalışır.

Buradaki zorluk, çoğu yazılım uygulamasının veri odaklı olmasıdır. Bu nedenle, uygulamadaki bir sorunu gidermeye çalıştığınızda, gerçekten onu çalıştıran verileri görmeniz gerekir. Bu yüzden geliştiricilerin gerçekten bir çeşit erişime ihtiyacı var.

SQL oturum açma bilgilerini yalnızca tablolara salt okunur erişim vermek için kullanmak harika. ANCAK, 20 üyeli bir sorgu oluşturmalarını veya milyonlarca kayıt içeren bir tablodan SELECT * yapmalarını önleyen nedir? Bu sorgular yanlışlıkla veritabanınızın ve deponuzun performansını düşürebilir.

Şirketim Stackify bunu çözmek için akıllıca bir yol buldu. Geliştiriciler sorguyu yazılımımız üzerinden çalıştırabilir ve sorgunun sadece bir SELECT ifadesi olduğundan ve sorgunun tahmini maliyetinin düşük olduğundan ve sadece birkaç kayıt alacağından emin olmak için sorgu planını kullanırız. Bu şekilde çok fazla zarar veremezler. Ayrıca yaptıkları tüm sorguları da denetliyoruz.

Bu sağladığımız şeylerden sadece bir tanesi. DevOps destek çözümlerimiz hakkında daha fazla bilgi edinmek için http://www.Stackify.com adresinden bize göz atın .

Evet. Bazı durumlarda, geliştiricilerin sorgulama üretim verilerine bazı düzeylerde erişmesi dahil, bazı kullanıcı alt gruplarına izin vermek mantıklıdır. Ancak, uygun sınırlamalar iki nedenden ötürü yerinde olmalıdır. İlk olarak, bir DBA olarak, tüm kullanıcıların ihtiyaç duyduğu hizmet seviyesini güvence altına almak için elinizden gelenin en iyisini yapmanız gerekir. Ayrıca, toplu silme veya iş kuralları ihlalleri gibi kasıtsız kötü sorguları da önlemek istiyorsunuz. Uygun güvenlik kontrollerinin yerinde olması gerektiğini söylemeden geçmelidir.

Geçici sorgulara doğrudan veritabanı tablolarına izin vermeme nedeniniz ne olursa olsun, sorguların görüntüleme ve saklı yordamları görüntülemesine izin vermek için yapılmış bir durum olabilir. Veritabanı izinlerini kullanarak, SELECT sorgularını doğrudan tabloları engelleyebilir ve hatta belirli bir kullanıcının erişebileceği görünümleri ve saklı yordamları sınırlayabilirsiniz. Bu yöntem yalnızca kullanıcı tabanınıza esneklik sağlamakla kalmaz, aynı zamanda doğru uygulandığında veri bütünlüğünü ve güvenilirliğini de korur.

Şirketimizde, üretim hizmetlerinin güvenmediği salt okunur üretim veritabanlarının kölelerini kullanıyoruz. Geliştiricilere, üretim verilerine erişim için bunlara erişim sağlıyoruz. Hassas veriler varsa (Müşteri Bilgisi, ödeme bilgisi, vb.) Bu tabloların çoğaltılmasını kısıtlıyor ve bağımlı sunucuda örnek bir veri tablosu tutuyoruz.

Hayır asla!!

Bu yüzden geliştirme / Test / UAT sunucularımız var. Üretimden elde edilen veriler test ortamına kopyalanabilir ve geliştiriciler testlerine devam edebilir. Bazı sorgular bir Üretim ortamı için de çok zararlı olabilir. Yükü artırır ve en yoğun zamanda tüm performansı düşürebilir.

İhtiyaç duydukları her bilgi, istediklerini (Seç) çalıştırabilecek ve sonuçları gönderebilecek DBA'dan geçmelidir. Çevremizde böyle yaparız.

Neden herkesin geliştiricilerin aptal olduğunu ve hiçbir şey bilmediğini varsaydığından emin değilim. Dağıldıkları ve “üretimde” olmaması gereken tonlarca farklı rol örneği alıyorum. DBA'lar, Sys Yöneticileri, Ağ Yöneticileri, Geliştiriciler, vb.

Hiç kimse (dev, dba, sa) normal ağ girişi olan herhangi bir ortamda herhangi bir sunucuya veya veritabanına erişemez. Hepsinde, kullanılması gereken belirli "admin" hesapları var. Evet, tipik olarak dba ve sa daha sık kullanıyorlar, ancak hafifçe basmaları gerekiyor. Herkes tarafından yandım.

Bu nedenle, iyi bir günde hiçbir BT rolünün erişime ihtiyacı yoktur. Bununla birlikte, sh! T, fanı vurur, tüm eller güvertede ve sorunu çözecek doğru insanlara ihtiyacımız var. Bu genellikle uygulamayı bilen ve dba ve sa'yı belirli noktalara yönlendiren geliştirici tarafından yönlendirilir. Bu sadece gereksiz gecikme veya talep etme ve onaylamadır.

Ek olarak, onay hiçbir şekilde herhangi bir tür denetim tarafından takip edilmez, bu nedenle onay hiçbir şey ifade etmez.