QueryProxy ve AWS IAM veritabanı kimlik doğrulaması
IAM veritabanı kimlik doğrulaması, bir RDS örneğine parola yerine kısa ömürlü bir token ile bağlanmanıza izin verir. Kimin bağlandığını çözer, ardından çalıştırdıkları ifadeleri incelenmeden bırakır.
Güncelleme:
Bir bakışta
| Konu | QueryProxy | AWS IAM veritabanı kimlik doğrulaması |
|---|---|---|
| Cevapladığı soru | "Bu ifade çalışabilir mi?" | "Bu kimliğin bağlanmasına izin var mı?" |
| Parolanın yerini ne alır | Şifreli bir kasa; geliştiriciler kimlik bilgisini hiç tutmaz | Çağıran için üretilen, 15 dakika geçerli bir kimlik doğrulama token'ı |
| Bağlantı açıldıktan sonra | Her ifade çalışmadan önce parse edilir ve onaylanır | Token "oturum kurulduktan sonra oturumu etkilemez" |
| İfade incelemesi | UPDATE ve DELETE için WHERE gerekir, SELECT'e LIMIT eklenir | Yok; veritabanı kullanıcının ne gönderdiyse onu alır |
| Onay | Bir DBA onaylar; web'den ya da Slack veya Teams'ten | Yok |
| Sonuç maskeleme | Kişisel veri sonuç yazılırken maskelenir | Yok |
| Veritabanı motorları | PostgreSQL, MySQL, MariaDB, SQL Server, SQLite | Atıf yapılan sayfaya göre Amazon RDS üzerinde MariaDB, MySQL ve PostgreSQL |
| Denetim izi | Her talebin, kararın ve çalıştırmanın değiştirilemez günlüğü | AWS, CloudWatch ve CloudTrail'in IAM kimlik doğrulamasını günlüğe almadığını belgeler |
IAM veritabanı kimlik doğrulaması ile QueryProxy rakip değildir. Biri kimin bağlandığını çözer; öbürü bağlandıktan sonra neyi çalıştırabileceğini.
AWS’in dokümantasyonu, IAM veritabanı kimlik doğrulamasının MariaDB, MySQL ve PostgreSQL ile çalıştığını söyler. Parola yerine bir kimlik doğrulama token’ı ile bağlanırsınız ve her token’ın ömrü 15 dakikadır. AWS şunu ekler: token “yalnızca kimlik doğrulama için kullanılır ve oturum kurulduktan sonra oturumu etkilemez.”
Bu son cümle sınırdır. Bağlantı açıldıktan sonra veritabanı belirli yetkileri olan bir kullanıcı görür. Bir onay görmez.
IAM kimlik doğrulaması neyi kapsamaz?
Geçerli bir token ile bağlanan bir mühendis yine de DELETE FROM orders
çalıştırabilir. İfadeyi okuyan, ikinci bir kişiye soran ya da sonuçtaki e-posta
sütununu gizleyen hiçbir bileşen yoktur. Bu,
veritabanı erişim denetimi nedir yazısının
savıdır: kimlik doğrulama erişim denetimi değildir.
QueryProxy eksik adımları kapsar; nasıl çalıştırılacağını hızlı başlangıç gösterir. İfade SQL korumalarına karşı parse edilir, bir DBA onu onay akışında onaylar ve sonuç saklanmadan önce maskelenir.
Belgelenmiş sınırlar neler?
AWS sayfası sınırlamaları sıralar. Bunların arasında: tüm global koşul bağlam
anahtarları desteklenmez; PostgreSQL için bir kullanıcıya rds_iam eklendiğinde
IAM kimlik doğrulaması paroladan önceliklidir; CloudWatch ve CloudTrail IAM kimlik
doğrulamasını günlüğe almaz; ve özellik örnekte 300 ile 1000 MiB arasında ek bellek
gerektirir. RDS on Outposts için desteklenmediğini de söyler.
QueryProxy’nin de sınırları var. Korumaları statiktir
ve elinden gelenin en iyisini yapar, yasak listesi doğası gereği eksiktir; yetki
DBA’in onayındadır. Veritabanı tarafında salt okunur çalıştırma v0.3.0 için
planlandığından üretim güvenliği rehberi ayrıca
SELECT-only bir bağlantı önerir.
Hangisine ihtiyacınız var?
Çoğu zaman ikisine de. IAM principal’ı olarak bağlanan uygulamalar token’lardan yararlanır ve QueryProxy, IAM token’ları kullanmak yerine veritabanı kimlik bilgisini kasasında tutar. Üretim verisine bakması gereken kişiler bir kuyruktan yararlanır; bugün parola paylaşıyorlarsa paylaşılan parola olmadan üretim veritabanı erişimi yazısına bakın. Bunlar farklı çağıranlardır ve aynı veritabanı ikisine de sahip olabilir.
AWS’in sayfası, özelliğin kullanılabilirliğinin motor sürümüne ve Region’a göre değiştiğini söyler; yapılandırmanız için o sayfaya bakın. Sayfa 2026-10-13 tarihinde okundu. Bir atlama sunucusu üzerindeki parolalar, farklı bir çözümü olan ilgili bir sorundur. Motora özgü notlar PostgreSQL ve MySQL ile MariaDB sayfalarında.
Bunun yerine AWS IAM veritabanı kimlik doğrulaması seçmeniz gereken durumlar
- Tek hedefiniz parolaların uygulama kodunda ya da yapılandırma dosyalarında yaşamasını önlemekse. IAM veritabanı kimlik doğrulaması bunu çalıştırılacak ek bir hizmet olmadan yerleşik olarak yapar.
- Veritabanlarınız RDS üzerindeyse ve çağıranlarınız EC2 örnekleri gibi IAM principal'ı olarak çalışan uygulamalarsa. AWS bunu uygun olduğu durum olarak belgeler ve bir insan onay kuyruğu yalnızca yolunuza çıkar.
- Rollere ve hesaplara bağlı IAM politikalarıyla AWS içinde erişim denetimi arıyorsanız. QueryProxy IAM okumaz.
Sık sorulanlar
- RDS IAM kimlik doğrulaması çalıştırılan SQL'i inceler mi?
- Hayır. AWS dokümantasyonu token'ın yalnızca kimlik doğrulama için kullanıldığını ve oturum kurulduktan sonra oturumu etkilemediğini söyler. Geçerli bir token ile bağlanan kullanıcı, veritabanı yetkilerinin izin verdiği her ifadeyi gönderebilir.
- IAM veritabanı kimlik doğrulamasını QueryProxy ile kullanabilir miyim?
- Doğrudan değil. QueryProxy'nin dokümantasyonu hedef kimlik bilgilerinin şifreli kasasında tutulduğunu anlatır, IAM token'larından söz etmez. Uygulamalarınız için IAM kimlik doğrulamasını, aynı veriye anlık erişime ihtiyaç duyan kişiler için QueryProxy'yi kullanın.
- IAM veritabanı kimlik doğrulamasının hangi sınırları var?
- AWS birkaç tane sıralar; tüm global koşul bağlam anahtarlarını desteklememesi, CloudWatch ve CloudTrail'in IAM kimlik doğrulamasını günlüğe almaması ve veritabanında 300 ile 1000 MiB arasında ek bellek gerektirmesi bunların arasında. Güvenmeden önce tam listeyi AWS sayfasında okuyun.
- IAM kimlik doğrulaması paylaşılan parolaları ortadan kaldırır mı?
- Onu kullanan kimlikler için evet, çünkü paylaşılacak bir parola kalmaz. Hâlâ anlık üretim erişimine ihtiyacı olan kişiler için başka bir yol gerekir; ortak bir parola dağıtmak ise QueryProxy'nin kaçınmak için var olduğu şeydir.