Yapay zeka uygulama oluşturucuları için PostgreSQL veritabanı erişimi

Bir yapay zeka uygulama oluşturucusu mevcut bir PostgreSQL veritabanına şemasının sahibi olmadan bağlanabilir, ancak bu sınırı PostgreSQL içinde gerçekten kurmanız gerekir. «Üretimi değiştirme» diyen bir istem denetim değildir. Ayrı bir rol, işlem varsayılanları, açık geçiş incelemesi ve şema kontrolleri denetimdir.

Güvenli model, veritabanı işini üç şeride ayırır. Keşif, meta verileri okur ve izin verilen verilerden örnekler alır. Uygulama yalnızca ihtiyaç duyduğu tablolardan okur, onlara yazar ve gereken işlemleri yapar. Şema değişikliği, bir kişi tam SQL'i onayladıktan sonra ayrı bir geçiş kimliğiyle çalışır. Ekiplerin bu şeritleri tek bir kullanışlı sahip kimlik bilgisinde birleştirdiğini, sonra bir aracının makul görünen bir sütun adını canlı bir tabloyu yeniden tasarlama izni saydığını gördüm. Kolaylık bir öğleden sonra sürdü, temizliği çok daha uzun sürdü.

Keşif, tasarımı gereği salt okunur olmalı

Keşif bağlantısının izin verilen şemayı anlamaya yetecek erişimi olmalı, onu iyileştirmeye yetecek erişimi olmamalı. Veritabanı veya rol oluşturamayan, satır güvenliğini atlatamayan ve geniş bir gruptan beklenmedik izinler devralmayan bir oturum açma rolü oluşturun. PostgreSQL yeni rolleri bu yetkiler olmadan başlatır, ancak açık bildirimler niyeti incelenebilir kılar.

CREATE ROLE app_discovery
  LOGIN
  NOSUPERUSER
  NOCREATEDB
  NOCREATEROLE
  NOINHERIT
  NOBYPASSRLS
  CONNECTION LIMIT 3
  PASSWORD 'replace-through-secret-manager';

ALTER ROLE app_discovery SET default_transaction_read_only = on;
GRANT CONNECT ON DATABASE customer_portal TO app_discovery;
GRANT USAGE ON SCHEMA app TO app_discovery;
GRANT SELECT ON ALL TABLES IN SCHEMA app TO app_discovery;

default_transaction_read_only, varsayılanı koruyan oturumlardaki sıradan yazmaları engeller. Yararlı bir ek güvenlik katmanıdır, tek başına yeterli değildir. İstemci işlem ayarını değiştirse bile rolü sınırlı tutan şey INSERT, UPDATE, DELETE, TRUNCATE, CREATE ve sahiplik izninin olmamasıdır. Role bir uygulama sahibi grubunun üyeliğini vermeyin ve onu bir şemanın sahibi yapmayın.

Oluşturucu bağlanmadan önce mevcut izinler incelenmelidir. Aşağıdaki sorgu tablo izni başına bir satır üretir; böylece inceleyen kişi SELECT dışındaki her şeyi görebilir:

SELECT table_schema, table_name, privilege_type
FROM information_schema.role_table_grants
WHERE grantee = 'app_discovery'
ORDER BY table_schema, table_name, privilege_type;

Sağlıklı bir sonuç app | invoices | SELECT biçimindedir. Boş sonuç, keşfin gerekli bir tabloyu göremediği anlamına gelebilir; UPDATE ile biten satır rolün gereğinden güçlü olduğunu gösterir. Ayrıca has_schema_privilege ile şema izinlerini, has_database_privilege ile veritabanı izinlerini kontrol edin. Tablo izinleri, rolün başka bir yerde nesne oluşturup oluşturamayacağını göstermez.

Üretim anlık görüntüsünü sahip kimlik bilgisi paylaşmak için bahane olarak kullanmayın. Bir kopya yine müşteri verisi içerebilir; sahip yetkisi olan bir aracı onu sonraki karşılaştırmaları işe yaramaz kılacak kadar değiştirebilir. Her ortamda keşif için özel bir kimlik verin.

Katalog incelemesi izin listesi içinde kalmalı

Oluşturucu yalnızca onaylı şemaları keşfetmeli ve PostgreSQL'in gerçekte bildirdiği bilgileri kaydetmelidir. information_schema, tablolar, sütunlar, kısıtlamalar ve izinler için taşınabilir görünümler sunar. pg_catalog, dizinler, türler, üretilmiş ifadeler ve satır güvenliği gibi PostgreSQL ayrıntılarını açığa çıkarır. Her ikisi de bir LLM'in tipik bir müşteri tablosuna dair belleğinden daha iyi kaynaktır.

app ve reporting gibi bir izin listesiyle başlayın. pg_catalog, information_schema, geçici şemaları, eklenti şemalarını ve listelenmemiş her kiracı şemasını uygulama hedefi olarak reddedin. Sorgu veritabanı, rol ve SQL düzeylerinde filtrelemelidir; yalnızca istem düzeyindeki izin listesi sonraki bir sohbette kaybolabilir.

SELECT
  c.table_schema,
  c.table_name,
  c.ordinal_position,
  c.column_name,
  c.data_type,
  c.is_nullable,
  c.column_default
FROM information_schema.columns AS c
WHERE c.table_schema IN ('app', 'reporting')
ORDER BY c.table_schema, c.table_name, c.ordinal_position;

Sonucu, alma zamanı ve veritabanı kimliğiyle birlikte bir şema anlık görüntüsü olarak saklayın. Anlık görüntü, üreticinin ne gördüğünün kanıtıdır. Kalıcı gerçek değildir. PostgreSQL keşif ile kod üretimi arasında değişebilir; bu nedenle dağıtımdan önce güncel bir parmak izini karşılaştırın. Pratik bir parmak izi, sıralanmış tablo, sütun, tür, null olabilirlik, varsayılan, kısıtlama ve dizin açıklamalarını karmalayabilir. Parmak izi farklıysa hangi değişikliğin zararsız olduğunu tahmin etmek yerine durun ve yeniden keşfedin.

Satır örnekleme ayrı bir izin kararıdır. Sütun meta verileri nadiren kişisel veri içerir, satır örnekleri ise çoğu zaman içerir. Kod üretiminde sıfır satır örneklemeyi tercih edin. Örnek gerekliyse sırları ve doğrudan tanımlayıcıları kaldıran veya maskeleyen bir görünüm açığa çıkarın, ardından yalnızca o görünüm için SELECT verin. LIMIT 10, hassas bir sorguyu güvenli yapmaz; yalnızca sızıntıyı küçültür.

Arama yolu da aynı özeni hak eder. Onu onaylı şema ve pg_catalog ile ayarlayın, üretilen tablo adlarını tam niteleyin ve PostgreSQL'in önce çözdüğü nesneye asla güvenmeyin. Bir saldırgan veya dikkatsiz geçiş, yazılabilir şemada aynı adlı bir nesne oluşturabilir. app.orders gibi tam nitelikli adlar bu belirsizliği kaldırır.

Çalışma zamanı rolü gerçek kullanıcı işlemlerine uymalı

Keşif ve çalışma zamanı farklı işlerdir. Çalışma zamanı uygulamasının sipariş eklemesi, taslağı güncellemesi veya özenle tasarlanmış bir işlevi çağırması gerekebilir, ancak bu keşfedilmiş şemanın tamamında geniş yazma erişimini haklı çıkarmaz. Kullanıcı işlemlerinden bir izin matrisi oluşturun, sonra her işlemi mümkün olan en küçük PostgreSQL iznine çevirin.

Örneğin bir fatura görüntüleyici app.invoices ve app.invoice_lines için SELECT iznine ihtiyaç duyabilir; not özelliği ise app.invoice_notes için SELECT ve INSERT ister. Muhtemelen faturaları DELETE etmesine, parola sıfırlama kayıtlarına erişmesine veya şema oluşturmasına gerek yoktur. Dizi kullanımını yalnızca ekleme gerçekten o diziye dayanıyorsa verin. PostgreSQL dizileri ayrı nesneler sayar; sahip hesabıyla test eden üreticiler buna sıkça şaşırır.

Görünümler ve işlevler yüzeyi daha da daraltabilir. Bir görünüm, iç alanları gizlerken onaylı sütunları açığa çıkarabilir. SECURITY DEFINER işlevi, sıradan izinlerin ifade edemediği tek bir denetimli işlemi yapabilir; ancak sabit bir search_path, sıkı girdi kontrolleri ve gereksiz yetkisi olmayan bir sahip gerektirir. Böyle bir işlevi izin modelinin etrafından dolaşan kestirme yol değil, ayrıcalıklı kod olarak ele alın.

Satır düzeyi güvenlik, paylaşılan tablo içinde bir veri sınırı ekler. Tablo izinlerinin yerini almaz. PostgreSQL önce rolün işlemi yapıp yapamayacağını denetler, ardından etkin ve uygulanabilir olduğunda satır güvenliği politikalarını uygular. Tam çalışma zamanı rolüyle test edin; tablo sahipleri ve BYPASSRLS rolleri politikaları aşabilir. Geçiş sahibinin altında yapılan bir test, son kullanıcının ne görebileceği hakkında neredeyse hiçbir şey kanıtlamaz.

Sırları istemlerden, üretilen kaynak koddan, tarayıcı paketlerinden, derleme günlüklerinden ve ekran görüntülerinden uzak tutun. Çalışma zamanı kimlik bilgisini barındırma ortamının gizli bilgi deposuna koyun ve yalnızca sunucu sürecine aktarın. Mobil ve tarayıcı uygulamaları PostgreSQL parolasını gizli tutamaz; bu yüzden doğrudan bağlanmak yerine bir sunucu API'sini çağırmalıdır. Keşif, çalışma zamanı ve geçiş kimlik bilgilerini bağımsız döndürün; bir şeritteki sızıntı diğer ikisini açmamalıdır.

Geçiş yetkisi ayrı bir onay yoluna aittir

Bir uygulama oluşturucusu geçiş önerebilir, ancak bunları keşif veya çalışma zamanı oturumuyla çalıştırmamalıdır. Geçiş işi için ayrı bir rol verin ya da yerleşik dağıtım sisteminin bu rolü tek bir onaylı iş için üstlenmesini sağlayın. Kimlik bilgisini sıradan sohbet ve önizleme oturumlarında erişilemez tutun.

Onay; tam SQL'i, hedef veritabanı kimliğini, hazırlıkta kullanılan şema parmak izini ve beklenen kilit veya yeniden yazma davranışını kapsamalıdır. «Müşteri durumu ekle» gibi doğal dildeki bir cümleyi onaylamak çok fazla alan bırakır. Çalıştırılabilir değişiklik, null kabul eden metin sütunu ekleyebilir, büyük bir tabloyu yeniden kurabilir, enum uydurabilir veya mevcut her satırı güncelleyebilir. Bunlar farklı hata biçimleri olan farklı işlemlerdir.

Kısa bir geçiş paketi kullanıyorum:

1. Değişikliğin nedeni ve onu gerektiren uygulama sürümü.
2. Tam ileri SQL ve dürüstçe mümkünse tam geri alma SQL'i.
3. Komutların etkileyebileceği nesneler, izinler ve satırlar.
4. Ön kontrol sorguları, beklenen sonuçlar ve güncel şema parmak izi.
5. Kilit zaman aşımı, ifade zaman aşımı, yedek veya anlık görüntü başvurusu ve sürüm sahibi.

Geri alma betiği her zaman geri dönüş değildir. Yeni eklenen sütunu silmek katalog değişikliğini tersine çevirebilir, ancak sürümden sonra o sütuna yazılan veriyi de yok eder. PostgreSQL'in işlemsel DDL'si birçok katalog işleminde yardımcı olur, ancak bir işlem harici yan etkileri veya sonraki bir komutun sildiği veriyi geri getiremez. DOWN ifadesini sihirli bir sözcük saymak yerine, yıkıcı geri almaları açıkça etiketleyin.

lock_timeout ayarlayın; böylece geçiş, yoğun bir işlemin arkasında bekleyip yeni işleri engellemek yerine başarısız olur. statement_timeout değerini incelenmiş işleme göre belirleyin. Ön kontrol sorgularını değişiklik penceresi içinde tekrar çalıştırın. Tablo boyutu, çakışan nesneler, null sayıları veya şema parmak izi onaylı varsayımlardan farklıysa iptal edin. Aracı üretime karşı doğaçlama yeni bir geçiş yazmak yerine uyumsuzluk raporu döndürmelidir.

Üretilen testler geçti diye bir geçişi asla otomatik onaylamayın. Testler genellikle küçük, temiz şemada çalışır; kilit kuyruklarını, eski null değerleri, sıra dışı kısıtlamaları, eklentileri ve hâlâ trafik alan uygulama sürümlerini kaçırır. Onay, kişinin üretilen niyeti canlı sistemle bağdaştırdığı noktadır.

Bağlantı havuzu güvenlik hesabını değiştirir

Havuz, veritabanı oturumlarını yeniden kullanır; bu nedenle oturum durumu onu oluşturan isteğin ötesinde yaşayabilir. Bir istek SET search_path çalıştırır, rol değiştirir, geçici nesne oluşturur veya zaman aşımını kapatırsa sonraki kullanıcı sonucu devralabilir. Uygulama ya değişebilir oturum durumundan kaçınmalı ya da bağlantı havuza dönerken onu güvenilir biçimde sıfırlamalıdır.

İşlem havuzu sınırı daha sıkı yapar. İstemci her işlemden sonra farklı bir sunucu oturumu alabilir; bu durum oturum hazırlıklı ifadeleri, geçici tablolar, danışma kilitleri ve oturum düzeyi ayarları hakkındaki varsayımları bozar. Oluşturucular genellikle doğrudan bağlantıda çalışan, havuzun arkasında ise bu farkı modellemedikleri için bozulan kod üretir. Havuzun oturum mu işlem modu mu kullandığına karar verin, sonra bu modu üretime ve testlere ekleyin.

Dağıtımdan önce bağlantı bütçesi yapın. Veritabanının izin verdiği bağlantılarla başlayın; yönetim, geçişler, izleme ve diğer hizmetler için kapasite ayırın, sonra kalanı uygulama örnekleri arasında bölün. On örneğin her biri yirmi bağlantı açarsa trafik sakin olsa bile PostgreSQL iki yüz olası oturum görür. Kuyruk içeren ihtiyatlı küçük bir havuz, veritabanı reddedene kadar bağlantıları çoğaltmaktan genellikle daha güvenlidir.

Sunucu tarafı zaman aşımlarını güvenlik desteği olarak kullanın: statement_timeout uzun ifadeleri sınırlar, lock_timeout kilit beklemelerini sınırlar, idle_in_transaction_session_timeout ise hiçbir şey yapmadan işlemi açık tutan oturumları kaldırır. Her üretilen istemcinin bunları hatırlamasına güvenmek yerine değerleri her rol için ayarlayın. Bunları gerçek rol altında ve gerçek havuz üzerinden SHOW ile doğrulayın.

Sağlık kontrolleri ucuz olmalıdır. SELECT 1 bir gidiş dönüşü doğrular, ancak uygulamanın onaylı tabloya erişebildiğini veya arama yolunun doğru olduğunu doğrulamaz. Hazır olma kontrolü, çalışma zamanı rolüyle küçük ve kararlı bir görünümü sorgulayabilir. Geçişleri uygulama başlangıcının dışında tutun; aynı anda şemayı değiştirmeye yarışan örnekler, bu tasarımın kaldırmayı amaçladığı bağımlılığı tam olarak yaratır.

Uydurulmuş sütunlar sorgu çalışmadan başarısız olmalı

LLM'ler makul tanımlayıcılar uydurur. Bir istem müşterinin görünen adından söz ediyorsa üretilen kod, veritabanı given_name ve family_name sakladığı hâlde customers.display_name alanına erişmeye çalışabilir. Veritabanı bu sorguyu reddeder; bu yanlış alanı sessizce okumaktan iyidir, ancak üretim hatası yine de kötü bir şema doğrulama yöntemidir.

Onaylı katalog anlık görüntüsünden türlenmiş bir şema yapıtı üretin ve onu sorgu kurulumunun tek kaynağı yapın. Bu yapıt içinde olmayan tablo veya sütun üretim hatasına yol açmalıdır. Görev açıkça geçiş şeridine girmedikçe modelin hatayı geçiş ekleyerek onarmasına izin vermeyin. Eksik tanımlayıcı güncel olmayan keşif, yazım hatası, yanlış ortam ya da gerçek bir ürün gereksinimi anlamına gelebilir. Her biri farklı yanıt gerektirir.

Statik kontroller SQL'i ayrıştırmalı ve her ilişkiyi, her sütunu anlık görüntüye göre çözümlemelidir. Sonra ifadeleri geçici bir veritabanına veya yazamayan bir işleme karşı hazırlayın. PostgreSQL ayrıştırıcısı, başarılı iş verisi gerektirmeden bilinmeyen sütunları, belirsiz başvuruları, işleç türü hatalarını ve birçok kötü dönüşümü yakalar. İzinler ve satır politikalarının devreye girmesi için entegrasyon testlerini çalışma zamanı rolüyle çalıştırın.

Hata raporu, kişinin karar vermesine yetecek ayrıntı taşımalıdır. SQL konumunu, çözümlenmeyen tanımlayıcıyı, yakın geçerli tanımlayıcıları, anlık görüntü parmak izini ve hedef veritabanı kimliğini ekleyin. Öneriler yararlıdır, ancak otomatik bulanık eşleştirme tehlikelidir. Adlar yakın görünüyor diye billing_address_id alanını shipping_address_id ile değiştirmek, yanlış iş anlamına sahip geçerli SQL üretebilir.

Dinamik filtreler ve sıralamalar için genel API adlarını kapalı bir tam nitelikli SQL ifadeleri kümesine eşleyin. Bir modelin sağladığı tanımlayıcıyı, değer parametresi üzerinden bile olsa SQL'e asla yapıştırmayın. Parametreler değerleri korur, tablo veya sütun adlarını değil. Kullanıcılar sıralama alanı seçebiliyorsa created değerini app.orders.created_at gibi bilinen bir ifadeye çevirin; bilinmeyen her belirteci reddedin.

Şema kayması sürümü durdurmalı, yaratıcı uzlaştırmayı tetiklememelidir. Anlık görüntüyü yeniden üretin, farkı gösterin ve testleri tekrarlayın. Bu gecikme gereksiz titizlik gibi görünebilir, ancak veritabanını yalnızca bir sohbet dökümünde anlayan kodu dağıtmaktan daha ucuzdur.

Yıkıcı SQL, ret politikası ve kanıt gerektirir

Bir oluşturucu, herhangi biri çalıştırmadan önce SQL'i sınıflandırmalıdır. DROP, TRUNCATE, incelenmiş yüklem olmadan geniş DELETE veya UPDATE, sahiplik değişiklikleri, izin yükseltme, eklenti değişiklikleri ve onaylı şemaların dışını hedefleyen komutları engelleyin. ALTER TABLE işlemini otomatik olarak güvenli değil, inceleme gerektirir olarak ele alın. Sütun türü değişikliği veya yeni bir null kabul etmeme kısıtlaması veriyi tarayabilir, yeniden yazabilir ve önemli kilitler tutabilir.

Metin eşleştirme tek başına zayıftır; SQL'de yorumlar, tırnaklı tanımlayıcılar, işlevler ve yan etkileri ifade etmenin birçok yolu bulunur. İfadeleri PostgreSQL'i bilen bir ayrıştırıcıyla ayrıştırın, sözdizimi ağaçlarını inceleyin ve yasak işlemleri reddetmek için veritabanı rolüne de güvenin. Sınıflandırıcı incelemeyi iyileştirir; izinler sınırı uygular. Hiçbiri tek başına tüm yükü taşımamalıdır.

Bir geçiş gerçek tablo biçimlerine veya veri dağılımlarına bağlıysa, yakın tarihli ve doğru korunan anlık görüntüden geri yüklenmiş bir hazırlık veritabanı kullanın. Tam geçiş paketini orada uygulayın, süreyi ve kilit gözlemlerini yakalayın, çalışma zamanı kimlik bilgileriyle uygulama testlerini çalıştırın, sonra ortamı kaldırın. Hazırlık ile üretim arasında SQL'i sessizce düzenlemeyin. Her düzenleme, yeni parmak izi ve onay gerektiren yeni bir yapıt oluşturur.

Günlükler, sırları veya hassas satırları kaydetmeden öneriyi yürütmeye bağlamalıdır. Değiştirilemez geçiş yapıtını kimin onayladığını, özetini, hedef kimliği, başlangıç ve bitiş durumunu ve PostgreSQL hata ayrıntılarını kaydedin. Üretilen farkı ve ön kontrol sonuçlarını saklayın. Aracı sohbeti yararlı bağlamdır, ancak kullanıcılar dallanabildiği, yeniden deneyebildiği ve yönergeleri farklı sözlerle ifade edebildiği için denetim kaydı değildir.

Anlık görüntüler ve geri alma kontrolleri kurtarma süresini azaltır, ancak yıkıcı SQL'i kabul edilebilir yapmaz. Anlık görüntü tüm veritabanını daha eski bir noktaya döndürebilir; oysa gerçek ihtiyaç silinmiş tek bir sütun olabilir ve geri yükleme, anlık görüntüden sonra yapılmış meşru yazmaları yok edebilir. Kurtarmayı ayrı test edin ve kimlerin çalıştırabileceğini belgelendirin.

Köklü bir veritabanına dokunan bir uygulama için Koder.ai kullandığımda, dışa aktarılan kaynak kodu ve önerilen veritabanı sınırını inceleyene kadar işi planlama modunda tutarım; anlık görüntüler ve geri alma, bu incelemeyi atlama izni değil, kurtarma denetimleridir. Aynı kural her oluşturucu için geçerlidir: ürün kolaylığı, veritabanı uygulamasının arkasında kalmalıdır.

Şema değişiklikleri karışık uygulama sürümlerine dayanmalı

Bir geçiş, sürüm penceresi sırasında hem eski uygulama hem de yeni uygulama çalışabiliyorsa güvenlidir. Üretim nadiren tek anda bir sürümden diğerine geçer. Yeni örnekler başlarken istekler eski örneklere ulaşabilir, kuyruktaki işler eski yükler taşıyabilir ve geri alma dünkü kodu bugünkü şemaya karşı yeniden çalıştırabilir. Yalnızca son kodu son şemaya karşı doğrulayan uygulama oluşturucusu bu örtüşmeyi kaçırır.

Önce eklemeli değişiklikleri tercih edin. Null kabul eden bir sütun, yeni tablo veya eski yolu kaldırmadan bir dizin ekleyin. Her iki gösterimi de okuyabilen ve gerektiğinde yeni gösterime yazan kodu dağıtın. Mevcut satırları ayrı olarak incelenmiş bir işle geri doldurun, hataları ve gecikmeyi izleyin, sonra yeni alanı yetkili kaynak yapın. Çalışan hiçbir kodun eski sütunu veya kısıtlamayı kullanmadığını kanıtlayan verilerden sonra, onu sonraki sürümde kaldırın.

Bu sıra tek bir ALTER TABLE ifadesi üretmekten uzun sürer, ancak hataları yalıtır. Yeni kod kaldırmadan önce yanlış davranırsa eski yol hâlâ vardır. Geri doldurma geride kalırsa uygulama sürümünü rehin almadan duraklayabilir. Dağıtım geri alınırsa eski uygulama veritabanını hâlâ tanır. Ek sürüm, geri alma sırasında önceki ikilinin geçişin çoktan sildiği sütunu sorguladığını fark etmekten daha ucuzdur.

PostgreSQL adı hemen değiştirdiği için yeniden adlandırmalar özel dikkat ister. Bir üretici, yeni ad daha anlaşılır göründüğü için customer_ref adını customer_id yapmayı önerebilir. Eski örnekler geçiş tamamlanır tamamlanmaz başarısız olur. customer_id ekleyin, iki alanı uygulama kodunda veya dar kapsamda incelenmiş tetikleyicide eşzamanlı tutun, okuyucuları taşıyın ve eski yazıcılar ortadan kalktıktan sonra customer_ref alanını kaldırın. Geçici çoğaltma, kaldırma koşulu olan görünür bir borçtur; anlık yeniden adlandırma ise görünmez sürüm bağımlılığıdır.

Varsayılanlar ve null kabul etmeme kısıtlamaları da işi gizleyebilir. SET NOT NULL onaylamadan önce mevcut null değerleri sayın ve etkin her yazıcının değer sağladığını kanıtlayın. Büyük veya yoğun tablolarda PostgreSQL sürümünün kısıtlamayı nasıl doğruladığını ve hangi kilitleri aldığını inceleyin. Oluşturucu, temsilî trafik içermeyen şemadan bunları çıkarmak yerine ön koşulları bildirmelidir.

Veri geri doldurmaları sınırsız bir şema işleminin içinde yapılmamalıdır. Satırları onaylı bir işçi aracılığıyla ölçülü partiler hâlinde güncelleyin, ilerlemeyi kararlı imleçle kaydedin ve yeniden denemeleri idempotent yapın. Yeniden deneme, iki kez uygulandığında PostgreSQL ikinci sorguyu kabul ettiği için değil, amaçlanan durumu ürettiği için idempotenttir. Türetilmiş değerlerde, sonraki kod bunları farklı hesaplayabilirse türetme sürümünü kaydedin.

Sürüm paketi dört uyumluluk noktasını adlandırmalıdır:

1. Geçişten önce çalışmasına izin verilen en eski uygulama sürümü.
2. Eski ve yeni sürümlerin kabul ettiği şema durumu.
3. Yıkıcı temizlik sürümüne izin veren sinyal.
4. Yeni kod veri değiştirdikten sonra geri alınırsa kurtarma yolu.

Üretilen sorgular bu geçişlerde SELECT * kullanmamalıdır. Sütun eklemek, eski SQL ayrıştırılmaya devam etse bile tarama maliyetini, sonuç çözümlemeyi, konumsal eşlemeyi ve veri açığa çıkışını değiştirebilir. Tam nitelikli sütunları açıkça listeleyin ve çözücüleri aynı şema anlık görüntüsünden üretin. Bu, kaynak incelemesinde hangi verinin veritabanı sınırını geçtiğini de açıkça gösterir.

Hazır geçiş araçları genellikle uygulanmış sürümü bir tabloda izler, ancak sürüm numarası tek başına uyumluluğu kanıtlamaz. Tam SQL yapıtının özetini kaydedin; aynı dostça ada sahip iki dosya farklı komutlar içerebilir. Yürütücü, önceden kaydedilmiş sürümün özeti farklıysa reddetmelidir. Gerekli bir öncül eksikse sonraki geçişi de reddetmelidir.

Her uygulama örneğinin başlangıçta geçiş çalıştırmasına izin vermeyin. Geçiş aracı danışma kilidi kullansa bile başlangıç artık ayrıcalıklı kimlik bilgisine ve sağlık kontrolleri zaman aşımına uğramadan şema işinin bitmesine bağlıdır. Geçiş yürütmesini tek bir sürüm işine koyun, kaydedilmiş sonucunu bekleyin ve çalışma zamanı örneklerini şemayı değiştiremeyen bir kimlikle başlatın. Sürüm sistemi bu aşamaları ayıramıyorsa uygulamaya sahip yetkileri vermeden önce sürüm sistemini düzeltin.

Yalnızca hedefi değil, şu zaman çizelgesini test edin: eski şemada eski kod, genişletilmiş şemada eski kod, genişletilmiş şemada yeni kod ve yeni yazmalardan sonra geri alınmış kod. Temizlik daha sonra kendi testini alır. Bu matris, sözdizimsel olarak geçerli ama işlemsel olarak geri döndürülmesi imkânsız değişiklikleri yakalar.

Sınırı olumsuz testlerle kanıtlayın

Yasak işlemler testte başarısız olmadıkça güvenlik tasarımı tamamlanmış sayılmaz. Keşif rolüyle bağlanın ve ekleme, tablo oluşturma, SET TRANSACTION READ WRITE deneyin. Çalışma zamanı rolüyle bağlanın; izin verilmemiş tabloya erişmeyi, satır güvenliğiyle korunan kiracılar arası okumayı ve şema değişikliğini deneyin. Beklenen sonuç bir PostgreSQL izin hatasıdır, aracının günlüğündeki vaat değil.

Olumlu testleri de çalıştırın. Keşif, izin verilen her katalog girdisini okumaya devam etmelidir. Çalışma zamanı, havuz üzerinden onaylanmış her kullanıcı işlemini yapmalıdır. Geçiş yürütmesi yalnızca onay yolu üzerinden çalışmalıdır. Ürünün normal işini engelleyen sınır, bir olay sırasında birinin onu sahip kimlik bilgisiyle değiştirmesine davetiye çıkarır.

Uygulama kaynak kodunun yanında küçük bir erişim sözleşmesi tutun. Veritabanını, izin verilen şemaları, keşif kapsamını, çalışma zamanı işlemlerini, havuz modunu, zaman aşımı politikasını, geçiş onaylayanlarını, şema parmak izi yöntemini ve yasak ifadeleri adlandırmalıdır. Sürekli kontrollerde gerçek izinleri bu sözleşmeyle karşılaştırın. PostgreSQL izin kayması, hiç kimse uygulama kodunu değiştirmese bile yapılandırma kaymasıdır.

Rol değişikliklerinden, yeni tablolardan, geri yüklenmiş veritabanlarından, havuz yükseltmelerinden ve barındırma değişikliklerinden sonra yeniden kontrol edin. Varsayılan izinler gelecek nesneler için önemlidir: SELECT ON ALL TABLES vermek mevcut tabloları kapsar, daha sonra oluşturulan tabloları kapsamaz. Yeni nesnelerin incelemeye kadar görünmez mi kalacağına, yoksa dar yapılandırılmış varsayılan izinlerle mi ekleneceğine karar verin. Açık izin, yeni tabloyu erişim konuşmasına zorladığı için varsayılan olarak görünmez olmasını tercih ederim.

İptali de test planına ekleyin. Keşif kimlik bilgisini devre dışı bırakın ve çalışma zamanı trafiğinin sürdüğünü doğrulayın; çalışma zamanını devre dışı bırakın ve geçiş araçlarının sessizce daha güçlü kimliğini kullanmadığını doğrulayın. Ardından bağlantılar etkinken her sırrı döndürün ve havuzun eski oturumları amaçlanan süre içinde kapatıp kapatmadığını gözlemleyin. Parola değişikliği, zaten kimlik doğrulamış oturumları sonlandırmaz; bu nedenle döndürme prosedürlerinde açık bir havuz yenileme veya PostgreSQL oturum sonlandırma politikası gerekir.

Bu testlerde hata iletilerini istemeden bilgi açığa çıkarma açısından inceleyin. PostgreSQL hataları ilişki adlarını, SQL parçalarını, kısıtlama adlarını ve verilen değerleri içerebilir. Ayrıntılı hataları sınırlı sunucu günlüklerine gönderin, istemcilere sabit bir genel hata döndürün ve üretimdeki hata akışının tamamını asla bir aracı sohbetine geri beslemeyin. Oluşturucunun kodu düzeltmek için ifade konumuna ve temizlenmiş veritabanı yanıtına ihtiyacı vardır; müşteri değerlerine değil.

Son bir test, şaşırtıcı sayıda güvenli olmayan entegrasyonu yakalar: geçiş kimlik bilgisini tamamen kaldırın ve uygulama test paketini çalıştırın. Normal başlangıç, sağlık kontrolleri, önizlemeler veya istek işleme başarısız olursa şema sahipliği çalışma zamanı yoluna sızmıştır. Oluşturucuyu üretime bağlamadan önce bu bağımlılığı düzeltin. Bir yapay zeka uygulama oluşturucusu sahibi olmadığı veritabanıyla çalışabilir, ancak üretilen kod düzenlemeyi unutursa PostgreSQL hayır diyebilmelidir.