Oracle DBA'mın root erişimine ihtiyacı var mı?

Oracle DBA Meslektaşım üretim sunucularımızda root erişimi istiyor . Sunucuyu ve diğer görevleri yeniden başlatmak
gibi bazı işlemleri gerçekleştirmesi gerektiğini savunuyor .

Onunla aynı fikirde değilim çünkü ona bir Oracle kullanıcısı / grubu ve Oracle kullanıcısının ait olduğu bir dba grubu oluşturdum. Her şey sorunsuz çalışıyor ve DBA'nın şu anda root erişimi yok.
Ayrıca, altyapı etkileşimlerinin yanlış anlaşılmasıyla ilgili her türlü sorunu önlemek için, zamanlanmış sunucu yeniden başlatma gibi tüm yönetim görevlerinin uygun yönetici (bizim durumumuzdaki Sistem yöneticisi) tarafından yapılması gerektiğini düşünüyorum.

Hem sistem yöneticilerinden hem de Oracle DBA'lardan girdi almak istiyorum - Oracle DBA'nın bir üretim ortamında kök erişimine sahip olması için iyi bir neden var mı?

İş arkadaşımın gerçekten bu erişim seviyesine ihtiyacı varsa, bunu sağlayacağım, ancak güvenlik ve sistem bütünlüğü endişeleri nedeniyle bunu yapmaktan korkuyorum.

Artılarını / eksilerini değil, bu durumla nasıl başa çıkmam gerektiğini tavsiye ediyorum.

• Oracle'ı sunuculara kimler yükler?
  DBA ise, root erişimine ihtiyaçları vardır. Eğer sysadmin ise, DBA yapmaz.

• Veritabanı sunucusu kapalı olduğunda gece geç saatte kim çağrılır?
  Sistem yöneticilerinin 7/24 kullanılabilir olmasını sağlayamıyorsanız, DBA'ya root erişimi vermek isteyebilirsiniz.

DBA'nız zaten düzenli bir kullanıcı olarak kabuk erişimine sahipse (bazı komutlarla veya komutlar olmadan sudo üzerinden çalışabilir; kroma ile veya kroksuz) sunucu ile uğraşmak için yeterli olduğunu unutmayın (hesabını çalan kötü bir adam bomba patlayabilir , spam gönderme ulimit aşmak, veritabanını bırakın, ...).

Tüm bu nedenlerden dolayı, ideal bir dünyada DBA'ların kök erişimine sahip olmaması gerektiğini düşünüyorum ; ancak gerçek dünyada, en azından her zaman acil durumlarda bunu elde edebilmelidirler.

Genel olarak - ve DBA'lara özgü rootolmayan - geçerli bir gerekçe göstermeksizin erişim isteyen herkes :

1. Ne yaptığını bilmeyen biri.
2. Kibirli ve işbirliksiz.
3. Yukarıdakilerin ikisi de.

Şimdi, ihtiyaç duydukları gerçek nedenler olabilir root görevlerini yerine getirmek için erişime , ancak yine neden ve yazılı olarak açıklayamazlarsa, onlarla ilgilenmem. Sunucularla ilgilenen profesyoneller sınırları anlar ve saygı duyar. Başını belaya sokacak sıcak atışlar, kuralların onlar dışındaki herkes için geçerli olduğuna inanır.

Böyle insanlar ile uğraşmak zorunda kaldım durumlarda, ben ortaya çıkan sorunları ele almak için onlarla sunucu üzerinde olabilir böylece zaman önceden planlanan ısrar etti. Ve bu gerçekten işe yaradı.

Pratik olmayan başka bir alternatif, söz konusu sunucunun tam bir klonunu oluşturmak ve bunlara rooterişmelerini sağlamaktır. Parolayı elbette kendilerine özgü bir şekilde değiştirdiğinizden emin olun. İzole bir geliştirme kutusunu havaya uçurmalarına izin verin.

Ancak genel olarak, bu adamın yaratabileceği bir karmaşayı temizlemek için gece geç saatlerde çağrılacak olan sizseniz, rooterişim için battaniye talebine hayır demeye hakkınız vardır .

Teorik olarak DBA'lar root privs olmadan çalışabilir, ancak her iki taraf için PITA'dır. Erişilebilecek komut listesini tanımlamak neredeyse imkansızdır sudo.

Aşağıdaki durumlarda DBA'lara kök ayrıcalıkları verin:

• sadece sunucuyu yeniden başlatmak için gecenin ortasında uyanmak istemiyorsun
• hızlı ve sorunsuz olay yönetimi istiyorsunuz
• sunucunuz yalnızca DB sunucusu için ayrılmışsa

DBA'lar genellikle aşağıdakiler için kök ayrıcalıklara ihtiyaç duyar: çekirdek parametreleri ayarlamaları (sysctl), depolama manipülasyonu, sorun araştırması.

Doğru denetleme, kesin olarak tanımlanmış güvenlik kurallarından daha iyi çalışma koşulları sağlar. Denetleme uyguladıysanız, neden bir şey yaptığını / değiştirdiğini her zaman sorabilirsiniz. Denetiminiz yoksa, yine de güvenliğiniz yoktur.

REDAKTE

Bu, bağımsız Oracle (kümelenmemiş yüklemeler) ile ilgili ortak Oracle gereksinimlerinin bir listesidir

• Çekirdek parametreleri

  • Bellekle ilgili (büyük / büyük sayfa yapılandırması, paylaşılan RAM (ipcs), değiştirilemez (kilitli) RAM)
  • ilgili ağlar (pencere boyutu gönderme / alma, TCP tutma)
  • depolamayla ilgili (açık dosya sayısı, zaman uyumsuz ES)

  Yaklaşık 15-20 sysctl parametresi olabilir. Her biri için Oracle önerilen bir değer veya denklem sağlar. Bazı parametreler için önerilen denklem zaman içinde değişebilir (aync io) veya bazı durumlarda Oracle aynı parametre için birden fazla denklem sağladı.

• Depolama: Linux udev kuralları önyükleme kalıcı cihaz adlarını garanti etmez. Bu nedenle Oracle, çekirdek sürücüsü ve araçları (AsmLib) sağladı. Bunlar, fiziksel bölümleri kök olarak "etiketlemenize" olanak tanır ve veritabanı depolamasını yönetirken bu etiketleri görebilirsiniz
• Sorun araştırması:
  • Daha fazla dosya tanıtıcısı açamadığı için veritabanı çöktüğünde, tek çözüm çekirdek sınırını artırmak, 'sysctl -p' yürütmek ve sonra DB'yi başlatmaktır.
  • Ayrıca fiziksel RAM'in çok parçalanmış olduğunu ve veritabanının büyük sayfalar ayıramadığını bulduğunuzda, tek seçenek sunucuyu yeniden başlatmaktır.
  • (DCD) - ölü bağlantı algılama. Örneğin AIX netstat üzerinde PID yazdırmaz. TCP bağlantısını PID ile eşleştirmenin tek yolu çekirdek hata ayıklayıcıdır.
  • bakış (HP-UX'te zirveye benzer bir şey) için root privs gerekir
  • çeşitli Veritas seviyesi araştırmaları
  • ve daha birçoğu

Sorun çözülene kadar ne kadar zaman harcayacağınıza karar vermek size kalmıştır. Sadece güçlü rol ayrımının çok pahalı olabileceğini belirtmek istedim. Yani "güvenliği" artırmak yerine risk ve tehlikeleri azaltmaya odaklanın. Hangisi aynı değil. Ttysnoop veya shell spy gibi araçlar tüm ssh oturumunu "kaydetmenize" izin verir, böylece yadsınamazlık verir. Bu sudo'dan daha iyi hizmet edebilir.

Ben bir Oracle DBA'yım ve cevabım normalde DBA'nın root erişimine ihtiyacı yok. Ama bir RAC DBA? kesinlikle CRS, ev tutma ve her şeyi yönetmek için kök erişimine ihtiyacı var.

Bu soru, sistemlerin çok daha basit olduğu ve İşletim Sistemi ve Veritabanı süreçlerinin ayrı ayrı tanımlandığı ve tanımlanabildiği bir zamandan kaynaklanmaktadır. Sistem Yönetimi ve Veritabanı Yönetimi görev ve sorumlulukları çok farklıydı. Günümüzün BT ortamları ve özellikle günümüzün Veritabanı Sunucuları ile bu görevler ve sorumluluklar, çoğunlukla değil, üst üste gelme eğilimindedir. Sistem Yöneticisi “kök” erişimini “risk yönetimi” ile ilgili olarak kısıtlamak için gereken özeni gösterir.

Günümüzün RAC Veritabanı Sistemlerimizde ortaya çıkan sorunlar için “yüksek kullanılabilirlik” ve “derhal iyileştirme” talepleri ile Sistem yöneticileri ve Veritabanı Yöneticileri, işlevsel ekiplerine birlikte ekip halinde hizmet vermektedir. Her iki tarafın da RAC Veritabanı Sunucularını çevrimiçi olarak% 100'e yakın tutmak gibi bir çıkarı olduğu için “güven” ile ilgili herhangi bir endişe olmamalıdır. Unutmayın, DBA zaten bir Veritabanı Yöneticisi olarak kabuk erişimine sahiptir (sudo üzerinden çalıştırabildiği bazı komutlarla veya komutlar olmadan; kroma ile veya kroksuz olarak), bu yüzden açıkça DBA “güvenilir” bir ajandır. Yani, asıl soru şu olmalıdır: “Oracle DBA'nın neden erişime ihtiyacı yok?”

Günümüzün DBA'sı, bir Veritabanı Sunucusunun bir Oracle Real Application Cluster (RAC) üyesi olduğu ve RAC Veritabanı (ları) ndaki paylaşılan depolama alanını sunmak için Oracle Automatic Storage Management (ASMLIB) kullanan veritabanı sunucusu için ek sorumluluklar üstlenmiştir. RAC ve ASM'nin DBA tarafından yönetilmesi, halihazırda aşırı çalışan Sistem Yöneticisini rahatlatır ve bu da STS Grubuna / Ekibine memnuniyetle katkıda bulunmalıdır.

Ve ibre5043'ün belirttiği gibi, "... güçlü rol ayrımı çok pahalı olabilir bazı durumlarda. Bu yüzden" güvenlik "risk ve tehlikeleri azaltmaya odaklanmak yerine. Bu aynı değil. Ttysnoop veya shell spy gibi araçlar size izin verir tüm ssh oturumunu "kaydetmek" için, bu yüzden yadsınamazlık veriyorlar. Bu sudo'dan daha iyi hizmet edebilir. " Ayrıca, SSA'ları kimin izlediğini sormalısınız.

Sunucular CRS, RAC veya Oracle Restart gibi Oracle Grid Altyapı yazılımını kullanıyorsa, kritik veritabanı hizmetlerinin birçoğu kök olarak çalışır ve kritik veritabanı yapılandırma dosyalarının birçoğu root'a aittir. Yazılımın doğal bir tasarım özelliğidir. Bu politikalarınızın ihlali durumunda, politikaların revize edilmesi gerekir.

DBA, bu özellikleri yönetmek için root erişimi gerektirir. Teorik olarak, Sudo'ya girmesini beklediği komutların bir listesini isteyebilirsin, ancak cevap çok uzun bir liste olacak. DBA'nın düzenli olarak kullanabileceği tüm ikili dosyaların listesi için $ GRID_HOME / bin dosyasına göz atmanız yeterlidir. Eğer yama çalışmaları yapıyorlarsa (olması gerektiği gibi) liste daha da uzayabilir.

Benzer bir soru daha gönderdim. Aslında bir sistem yöneticisinin kök ayrıcalığını vermek istememesinin nedeni, bence sorumluluk ve hesap verebilirliktir.

Ama eğer sebep buysa, DBA aynı zamanda tek ve tek sistem yöneticisi olmalıdır. Ve nedeni basit. Hesap verebilirlik ve sorumluluğun ayrılmasına ihtiyaç duyulursa, sistem yöneticisi DAİMA DBA da olabilir. Oracle hesabını taklit edebilir, veritabanına SYSDBA olarak girebilir ve SYS veya SYSTEM şifresine gerek kalmadan her şeyi yapabilir.

Benim görüşüme göre, sistem yöneticilerinin ve DBA'ların hesaplanabilme ve sorumluluk nedeniyle ayrılmasına ihtiyaç duyulursa, tek mantıklı neden, sunucunun sysadmin tarafından değil, DBA tarafından yönetilmesi gerektiğidir. Sunucu ve veritabanı, bir takım sistem yönetimi bilgisine de sahip olması gereken DBA'nın sorumluluğunda olmalıdır.

Sunucu, veritabanını barındırmaktan daha fazlası için kullanılıyorsa ve bu ayrı bir sorumluluk ve hesap verebilirlik ihtiyacı varsa, bu sorun demektir. Ancak sunucu sadece veritabanını barındırmak için kullanılıyorsa, o zaman DBA'nın da ihtiyaç duyacağı sayısız vakayı dikkate alarak kök ayrıcalığına sahip olmaması için hiçbir neden göremiyorum.

Şahsen ben soruyu tam tersine soruyorum. Neden sysadmin, özel bir veritabanı sunucusunda kök ayrıcalığına sahip olmalı? Aslında, uzmanlık alanı DBA'nınkinden (kök ayrıcalığı ile) çok daha az durumda gerekecektir.

Oracle grid kurulumu ve yama için root erişimi gereklidir. Etrafında bir yol yok. Bu tür ihtiyaçlar için bir DBA'ya geçici kök erişimi vermenin bir yolu olsaydı, bu ideal olurdu.