Tipik kullanıcılara tanınmak için makul ayrıcalıklar nelerdir? [kapalı]

MySQL tarafından sağlanan ayrıcalıkların listesini biraz ezici buluyorum . Kimin hangi ayrıcalıklara sahip olması gerektiğinden emin değilim. Zihnimde durumum için üç tipik kullanıcı var:

1. root
2. developer
3. application

rootkendini açıklayıcıdır. İçin developerkullanıcının ihtiyaçlarını kolayca bu ayrıcalık setine Bu kullanıcıya ayarlıyorum başlayanlar için vb kendisine herhangi bir veritabanı, yapmak ayarlamaları erişmek mümkün:

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

applicationdaha sınırlı bir kümeye sahiptir. Sadece belirli bir veritabanını değiştirmekle sınırlı olmalıdır.

Makul bir ayrıcalık seti vereceğinden emin değilim. Bir geliştirici ve uygulama vermek için makul ayrıcalıklar nelerdir ve neden?

Tipik bir kullanıcı:

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

İlk dördü oldukça açıktır - ancak yalnızca "okuyan" kullanıcıları da ayarlayabilirsiniz SELECT.

CREATE TEMPORARYaynı zamanda kullanışlı ve genellikle zararsızdır: geçici tablolar, sorguları optimize etmeye, daha küçük ve daha hızlı parçalara ayırmaya yardımcı olabilir. Bunlar, yürütme bağlantısıyla sınırlıdır ve kapatıldığında otomatik olarak kesilir.

EXECUTEsistem türünüze bağlıdır. Depolanmış rutinleriniz var mı? Kullanıcılarınızın bunlara erişmesini ister misiniz? SECURITY=DEFINER/INVOKERSaklanan yordamların tanımını da bildiğinizden emin olun .

Her durumda, yukarıdakilerin tümünü belirli şemalara uyguladığınızdan emin olun . Kullanmaktan kaçının :

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_host';

yukarıdakiler de mysqlsistem tablolarında ayrıcalık tanıdığından, herhangi bir kullanıcının yeni hesaplar oluşturmasına veya kendi ayrıcalık kümelerini yükseltmesine etkili bir şekilde izin verir. Bunun yerine şunları yapın:

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_host';

Herhangi bir gerçek ölçekli sistemde (yani kişisel bir projede değil), bu kullanıcı türleri ortama göre değişir, bu yüzden o kadar basit değildir.

Tüm ortamlarda uygulama ihtiyaç duyduğu ve daha fazlasına sahip olmamalıdır (genellikle bu "tüm tablolarda seç / ekle / güncelle" ve "tüm prosedürlerde yürüt" şeklindedir. Farklı görevler için ayrı uygulama kullanıcılarına sahip olabileceğiniz daha büyük sistemler için ( Örneğin, bir uygulama sansür verilerini beslemekten ve diğeri rapor oluşturmaktan sorumludur), ayrıcalıklarını en az ihtiyaç duydukları şekilde ayırmalısınız (rapor eden kullanıcının muhtemelen gerek duymadığı ve yazma hakları). Eğer varsa ortamlar: Test ortamındaki her şey DB sa(MSSQL eşdeğeri root) olarak erişiyordu çünkü test çalıştı Live olarak tanıtıldığında kod düştü gördüm .İdeal olarak, bir uygulama kullanıcısının genellikle şemanızı değiştirmesine izin veren ayrıcalıkları olmamalıdır (CREATE,, DROP...) - bunun istisnaları vardır, ancak bunlar çok azdır.

rootiyi root,. Üretimde bu yalnızca DBA'nızdır ve nadiren kullanılmalıdır - sadece sistem bakımı (DB tasarımına yükseltme) ve izleme için. Büyük bir sistem için, özellikle hesap verebilirlik amacıyla bireylerin yakın kontrolünü sağlamanız gereken düzenlenmiş ortamlarda, tek bir rootkullanıcıya hiç izin vermeyebilir ve ayrıcalıkları daha küçük rulolara ayırmayı deneyemeyebilirsiniz (ne kadar ileri gidebileceğinizi bilmiyorum bu mysql ile, ancak MSSQL, Oracle ve benzeri oldukça ince taneli olabilir).

Geliştirici kullanıcıları için: Canlı ortamlarınıza erişimleri olmamalıdır. Uygulama kullanıcılarının hakları etkileyen şemasına sahip olmamalarının nedenlerinden biri de budur: bir geliştirici hesabına erişimi olan biri bu şekilde kilitlenmelerini atlatabilir. Test ortamlarında da genellikle erişimleri yoktur: KG için yamalar gönderir ve KG için DBA (muhtemelen bir rootkullanıcı kullanarak ) güncellemeleri test ortamına uygular (aslında bu genellikle büyük kuruluşlarda otomatiktir, bu nedenle KG DBA aslında her döngü için test ortamının yeniden oluşturulmasını kontrol eden bir dizi komut dizisidir). Geliştirme ortamlarında, özellikle geliştiricilerin çalışan hizmetin kendi yerel kopyaları varsa, bu kullanıcıların denemek için elbette her şeye tam erişimi olmalıdır.

Yukarıdakilerin tümü genel notlardır: Herhangi bir spesifik öneri yapmak için uygulamalarınız ve çalıştıkları ortamlar hakkında daha fazla bilgi sahibi olmamız gerekir. Hedef ortam bazen düşündüğünüzden daha önemlidir: iş ortamınıza bağlı olarak müşterileriniz size teşhis amacıyla gerçek verilere erişim izni vermiş olsa bile, geliştirme aşamasında bile kullanıcılarınızın hakları oldukça doğrudan yasal düzenlemeler olarak belirlenebilir.