SQL Change Guard, SQL Server, PostgreSQL ve Oracle üzerinde veritabanı değişikliklerini ve üretim verisine erişimi yöneten bir Database Operations Governance platformudur. Bu sayfa yalnızca üründe bugün uygulanmış güvenlik kontrollerini anlatır; yol haritasındaki maddeler ayrı bir başlıkta ve açıkça işaretlenmiştir. Kurumunuzun güvenlik ekibi bu sayfayı bir soru listesi olarak kullanabilir. SQL Change Guard is a Database Operations Governance platform that governs database changes and production data access across SQL Server, PostgreSQL and Oracle. This page describes only the security controls implemented in the product today; roadmap items are in a separate section and clearly marked. Your security team can use this page as a question list.
SQL Change Guard kurumun kendi ağında çalışır. Bulut hizmeti değildir. Yönetilen veritabanlarınıza giden bağlantılar sizin ağınızdan çıkmaz, betikleriniz ve sorgu sonuçlarınız hiçbir dış servise gönderilmez. Ürünün kendi kayıtları da sizin veritabanı sunucunuzda durur. Bu, güvenlik değerlendirmesinin en başında sorulması gereken soruyu baştan kapatır: veri kurumun dışına çıkmaz.SQL Change Guard runs inside your own network. It is not a cloud service. Connections to your managed databases never leave your network, and your scripts and query results are never sent to any external service. The product keeps its own records on your database server. This closes the first question in any security review: the data does not leave the organisation.
Dışarıya çıkan tek bağlantı. Ürünle gelen ayar dosyasında RFC 3161 zaman damgası açık gelir ve ücretsiz, herkese açık bir otoriteye işaret eder; böylece kurulum ilk gün uçtan uca çalışır. Bu çağrıda dışarıya giden tek şey bir SHA-256 özetidir; betik, sorgu sonucu ya da kayıt içeriği hiçbir koşulda gönderilmez. Üretimde bu adres kurumun kendi otoritesiyle değiştirilmeli ya da özellik tek ayarla kapatılmalıdır. Kapalıyken ürün hiçbir dış çağrı yapmaz.The one outbound connection. The configuration that ships with the product has RFC 3161 timestamping on, pointing at a free public authority, so an installation works end to end on day one. The only thing that call sends out is a SHA-256 digest; scripts, query results and record contents are never sent under any circumstances. In production the address should be repointed at the organisation's own authority, or the feature switched off with a single setting. With it off, the product makes no outbound call at all.
| KontrolControl | Bugünkü uygulamaHow it works today |
|---|---|
| Yerel hesap parolalarıLocal account passwords | BCrypt ile özetlenir. Parola hiçbir yerde geri çevrilebilir biçimde saklanmaz; veritabanına erişen bir kişi bile parolaları okuyamaz.Hashed with BCrypt. Passwords are never stored in a reversible form, so even someone with database access cannot read them. |
| Dizin entegrasyonuDirectory integration | LDAP ile kurumsal dizine bağlanabilir. Bu durumda parola doğrulaması dizinde yapılır ve üründe parola tutulmaz.Can bind to your corporate directory over LDAP. Password verification then happens in the directory and no password is held in the product. |
| Çok faktörlü doğrulamaMulti factor authentication | Zaman tabanlı tek kullanımlık kod desteklenir ve kurum genelinde açılır. Kaydolmak ayrıca zorunlu tutulabilir: bu ayar açıkken kaydolmamış kullanıcı giriş yapar ancak oturumu yalnız kurulum adımına yarar, başka hiçbir işlem çalışmaz. Kural sunucu tarafında uygulanır. Kaç kullanıcının kaydolduğu tanılama ekranında oran olarak görünür.Time based one time codes are supported and switched on for the organisation. Enrolment can also be made mandatory: with that setting on, a user who has not enrolled can sign in but the session is good for the setup step alone and nothing else runs. The rule is enforced on the server. How many users have enrolled is shown as a ratio on the diagnostics screen. |
| Oturum jetonlarıSession tokens | Kısa ömürlü erişim jetonu ve ayrı yenileme jetonu kullanılır. Yenileme jetonları iptal edilebilir; bir kullanıcının tüm oturumları anında sonlandırılabilir.A short lived access token with a separate refresh token. Refresh tokens can be revoked, so all sessions for a user can be ended immediately. |
| Deneme sınırlamasıAttempt limiting | Başarısız giriş denemeleri sayılır ve eşik aşıldığında hesap kilitlenir. Uygulama arayüzü ayrıca istek hızı sınırlaması uygular.Failed sign in attempts are counted and the account locks past a threshold. The application interface also applies request rate limiting. |
| Parola değiştirme zorunluluğuForced password change | Yönetici tarafından oluşturulan hesaplar ilk girişte parola değiştirmeye zorlanır; değiştirmeden hiçbir işlem yapılamaz.Accounts created by an administrator must change their password at first sign in and can do nothing else until they do. |
Bir kullanıcının yetkisi kaldırıldığında elindeki jeton geçerliliğini korusa bile işlem reddedilir. Yetki kontrolü yalnız jetonun içeriğine değil, isteğin geldiği anda veritabanındaki güncel duruma bakar. Bu ayrıntı önemlidir: birçok sistemde yetki değişikliği ancak kullanıcı yeniden giriş yaptığında etkili olur ve aradaki süre bir açıklıktır.When a user's permission is removed, the operation is refused even if their existing token is still valid. The check reads the current state in the database at the moment of the request rather than trusting what the token carries. This detail matters: in many systems a permission change only takes effect at the next sign in, and the interval between is an exposure.
Arayüzde bir düğmenin görünmemesi bir kontrol değildir. Her işlem, arayüzden bağımsız olarak sunucu tarafında yeniden yetkilendirilir.Hiding a button in the interface is not a control. Every operation is authorised again on the server, independently of the interface.
Yetkiler rolden değil izinden okunur. Roller izin demetleridir; bir kullanıcının ne yapabileceği, rol adına değil elindeki izinlere bakılarak belirlenir. Böylece kurum kendi rol yapısını kurabilir.Access is read from permissions rather than role names. Roles are bundles of permissions; what a user can do is decided by the permissions they hold, not by what their role is called. This lets an organisation build its own role structure.
Üç ayrı ayar vardır: talep sahibi kendi talebini onaylayabilir mi, onaylayan çalıştırabilir mi, çok adımlı onayda aynı kişi ikinci adımı kapatabilir mi. Üçü de kurum tercihine göre açılıp kapatılabilir; hiçbirini kapatılamaz diye tanıtmıyoruz.There are three separate settings: whether a requester may approve their own request, whether an approver may execute, and whether the same person may close a second step in a multi step approval. All three can be switched by the organisation, and we do not present any of them as unchangeable.
Kontrol, ayarın kendisinde değil değiştirilme biçimindedir. Bu üç ayar "kontrol ayarı" olarak sınıflandırılmıştır: değişmeleri sıradan bir ayar güncellemesi değil, kontrolün zayıflatılması olayıdır ve ikinci bir yetkilinin onayına düşer. Sınıflandırma listesi bilinçli olarak kodda durur, veritabanında değil; aksi halde biri önce kaydı listeden çıkarıp sonra korumayı onaysız kapatabilirdi.The control is not in the setting but in how it can be changed. These three are classified as control settings: changing them is not an ordinary settings update but an event of weakening a control, and it goes to a second authorised person for approval. That classification list deliberately lives in code rather than in the database; otherwise someone could first remove an entry from the list and then switch the protection off unapproved.
Ayarın talep anındaki hali talebe dondurulur, bu yüzden sonradan yapılan bir gevşetme geçmiş kararları etkilemez. Engellenen onay girişimi de ayrıca kaydedilir: kontrolün gerçekten çalıştığının kanıtı, ürettiği red kayıtlarıdır.The state of the setting at the time of the request is frozen onto that request, so a later relaxation does not affect past decisions. A blocked approval attempt is recorded as well: what proves a control actually operates is the refusals it produces.
Kontrolü zayıflatabilecek ayarlar tek kişiyle değiştirilemez. Değişiklik ayrı bir kayda alınır, canlı ayara dokunulmaz ve ancak ikinci bir yetkili onayladığında uygulanır.Settings that could weaken a control cannot be changed by one person. The change is held as a separate record, the live setting is untouched, and it is applied only when a second authorised person approves.
| NeWhat | YöntemMethod | Neden bu yöntemWhy this method |
|---|---|---|
| Kullanıcı parolalarıUser passwords | BCrypt | Geri çevrilmesi gerekmeyen veri şifrelenmez, özetlenir. Kasıtlı olarak yavaş bir algoritmadır; deneme yanılma saldırısını pahalı kılar.Data that never needs to be reversed is hashed rather than encrypted. The algorithm is deliberately slow, which makes brute force expensive. |
| Sunucu bağlantı parolalarıServer connection passwords | AES-256-GCM | Bu parolaların kullanılabilmesi için geri çözülmesi gerekir, bu yüzden şifrelenir. GCM kipi hem gizliliği hem bütünlüğü sağlar: şifreli metin kurcalanırsa çözme başarısız olur.These have to be decrypted to be used, so they are encrypted rather than hashed. GCM gives both confidentiality and integrity: if the ciphertext is tampered with, decryption fails. |
| Sorgu sonucu teslim paketiQuery result delivery package | AES-256-GCM | Üretimden çıkan veri şifreli paket olarak teslim edilir. Paket parolası e-postayla gönderilmez; talep sahibi portalde gerekçesiyle görüntüler.Data leaving production is delivered as an encrypted package. The package password is not emailed; the requester views it in the portal against a stated reason. |
| Denetim kaydı zinciriAudit record chain | HMAC-SHA256 | Her kayıt bir öncekinin özetini taşır ve zincir anahtarlı bir özetle imzalanır. Anahtar veritabanının dışında olduğu için, veritabanına tam yetkiyle erişen biri de zinciri yeniden hesaplayamaz.Each record carries the digest of the one before it and the chain is signed with a keyed digest. Because the key lives outside the database, even someone with full database access cannot recompute the chain. |
| Kanıt dosyası mührüEvidence file seal | SHA-256 | Dışa aktarılan kanıt paketinin içeriği tek bir özetle mühürlenir. Denetçi, eline geçen dosyanın üretildiği andaki hali olduğunu bağımsız olarak doğrulayabilir.The contents of an exported evidence package are sealed with a single digest. An auditor can independently verify that the file they hold is the file that was produced. |
| Kanıt paketi imzasıEvidence package signature | RSA 3072, SHA-256 | Paketin künyesi asimetrik olarak imzalanır ve doğrulama için gereken açık anahtar paketin içine konur. Doğrulayan tarafın özel anahtara ihtiyacı yoktur; bu yüzden denetçi kurumdan hiçbir sır istemeden imzayı kendi makinesinde kontrol edebilir. Adımlar ve komutlar.The package manifest is signed asymmetrically and the public key needed to check it travels inside the package. The verifier never needs the private key, so an auditor can check the signature on their own machine without asking the organisation for any secret. Steps and commands. |
Şifreleme anahtarları uygulama yapılandırmasında tutulur ve kurumun kendi anahtar yönetimi disiplinine tabidir. Anahtar kurum tarafından belirlenir; üründe gömülü bir anahtar yoktur. Anahtarı değiştirmeden önce mevcut şifreli değerlerin yeniden şifrelenmesi gerekir; bu, kurulum dokümanında ayrıca anlatılır.Encryption keys are held in the application configuration and fall under your own key management discipline. The key is set by you; there is no key embedded in the product. Existing encrypted values must be re encrypted before a key is rotated, and the installation document covers this separately.
Değişiklik tarafında ürün veri okumaz. Veri yalnızca üretim sorgu talebi akışında görülür ve o akışın tamamı kontrol altındadır.On the change side the product does not read data. Data is only seen in the production query request flow, and that flow is controlled end to end.
Kolon adı tek başına yeterli sayılmaz. İçerik de değerlendirilir ve kimlik numarası, kart numarası ve IBAN gibi alanlar biçim doğrulamasıyla teyit edilir. Böylece on bir haneli her sayı kimlik numarası sayılmaz, adı ipucu vermeyen bir kolon da gözden kaçmaz.A column name alone is not treated as sufficient. Content is assessed as well, and fields such as identity numbers, card numbers and IBANs are confirmed with checksum validation. Not every eleven digit number is treated as an identity number, and a column whose name gives nothing away is not missed.
Varsayılan maskelidir. Maskesiz veri isteniyorsa gerekçe yazılır ve ek onay gerekir. Kurum, sunucu bazında yalnızca maskeli teslime izin veren bir rejim uygulayabilir; bu rejimde maskesiz istek hiç açılmaz.Masked is the default. Unmasked data requires a written reason and an additional approval. An organisation can enforce a masked only regime per server, and under it an unmasked request cannot be raised at all.
Sonucun indirilmesi ayrı bir olaydır ve gerekçesiyle birlikte kaydedilir. "Veriye kim, ne zaman, neden ulaştı" sorusunun cevabı talebin kendisinde durur.Downloading the result is a separate event and is recorded with its reason. The answer to who reached the data, when and why sits on the request itself.
Denetim kaydına yazılan yük içinde parola ve benzeri alanlar maskelenir. Bir ayar değişikliğinin izi tutulurken değişen sırrın kendisi kayda geçmez.Password style fields are masked inside the payload written to the audit record. When a settings change is tracked, the secret that changed is not written into the trail.
Denetim izi üç bağımsız katmandan oluşur ve her katman farklı bir soruyu cevaplar. Uygulama olayları anahtarlı bir özet zinciriyle imzalanır. Bu kayıtların tam satır kopyası ayrı bir veritabanına yazılır, böylece asıl kayıt silinse bile kopya kalır. Veritabanı tarafındaki yazma işlemleri ise tetikleyicilerle ayrıca kaydedilir.The audit trail has three independent layers and each answers a different question. Application events are signed with a keyed digest chain. A full row copy of those records is written to a separate database, so the copy survives even if the original is deleted. Write operations on the database side are recorded separately by triggers.
Zincirin bütünlüğü ürün içinden doğrulanabilir. Bir kayıt silinir veya değiştirilirse doğrulama hangi noktada koptuğunu gösterir. Aynı doğrulama ayrı veritabanındaki kopya için de çalıştırılabilir.Chain integrity can be verified from inside the product. If a record is deleted or altered, verification shows exactly where the chain breaks. The same verification can be run against the copy in the separate database.
Bu üç katmanın ortak bir zayıflığı vardır: hepsi kurumun kendi sunucularında durur. Anahtarların tamamına sahip biri geçmişi baştan yazıp zinciri yeniden hesaplarsa, ürün içindeki doğrulama "sağlam" der. Bu boşluğu çapa kapatır. Ürün her gün, o anki son kaydın özetini içeren imzalı bir çapa üretir; kurum bu çapaları düzenli olarak denetçiye teslim eder. Denetçinin elindeki eski çapa artık kurumun erişemediği bir yerdedir ve bugünkü kayıtla karşılaştırılabilir. Ürün aynı karşılaştırmayı günlük olarak kendi de yapar ve sonucunu çapa paketinin imzalı künyesine yazar. Denetçinin bunu nasıl doğruladığı ayrı sayfada anlatılıyor.Those three layers share one weakness: all of them sit on the organisation's own servers. Someone holding every key could rewrite the past, recompute the chain, and the in product verification would report it as intact. The anchor closes that gap. Every day the product produces a signed anchor carrying the digest of the last record at that moment, and the organisation delivers those anchors to the auditor on a schedule. The old anchor in the auditor's hands is now somewhere the organisation cannot reach, and it can be compared against today's records. The product runs the same comparison daily itself and writes the outcome into the signed manifest of the anchor package. How an auditor verifies this is set out on a separate page.
Hiçbir yazılım, veritabanına tam yetkiyle erişen bir kişinin kayıt silmesini engelleyemez. İmzalı zincirin verdiği güvence silinmezlik değil, fark edilirliktir: silinen veya değiştirilen kayıt doğrulamada ortaya çıkar. Ayrı veritabanındaki kopya ve veritabanı tetikleyicileri bu güvenceyi güçlendirir, çünkü izi tamamen temizlemek için üç ayrı yerde eşzamanlı müdahale gerekir. Daha önce denetçiye teslim edilmiş bir çapa ise kurumun hiç erişemediği bir yerdedir; ürünün içinde yapılacak hiçbir müdahale onu geri alamaz. Bu sayfada bundan fazlasını vaat etmiyoruz.No software can stop someone with full database access from deleting records. What a signed chain gives is not immutability but detectability: a deleted or altered record surfaces during verification. The copy in a separate database and the database triggers strengthen that, because clearing the trail completely would require simultaneous action in three separate places. An anchor already delivered to the auditor is somewhere the organisation cannot reach at all, and no action inside the product can take it back. We do not promise more than this.
Denetim modelinin tamamı ve denetçiye teslim edilen kanıt paketi için denetim izi ve kanıt sayfasına bakabilirsiniz.The full audit model and the evidence package handed to an auditor are covered on the audit trail and evidence page.
Aşağıdakiler bugün üründe yoktur. Değerlendirmenizi bunlara göre yapmayın; sormanız gereken şeyleri sormanız için buraya yazıyoruz.The following are not in the product today. Do not base your evaluation on them; they are listed here so you know what to ask about.
Kendi kontrol listenizi getirin. Karşılığı olan maddeleri canlı gösterelim, olmayanları da açıkça söyleyelim.Bring your own control list. We will demonstrate the items that have an answer and say plainly which ones do not.
Demo talep edin →Request a demo →İlgili sayfalar: uyum ve kontrol eşlemesi, denetim izi ve kanıt, üretim veritabanı erişim kontrolü.Related pages: compliance and control mapping, audit trail and evidence, production database access control.