Çerçeveler bir kontrolün işlediğinin gösterilmesini ister. SQL Change Guard, veritabanı değişikliklerini ve üretim verisine erişimi yöneten bir Database Operations Governance platformudur ve bu kaydı işin kendisinden üretir. Aşağıdaki tablolar, her beklentinin karşılığında hangi kaydın çıktığını gösterir; denetime hazırlanan ekipler bunu doğrudan kontrol listesi olarak kullanabilir. Frameworks ask you to demonstrate that a control operates. SQL Change Guard is a Database Operations Governance platform that governs database changes and production data access, and it produces that record out of the work itself. The tables below show which record answers each expectation, and teams preparing for an audit can use them directly as a checklist.
SQL Change Guard herhangi bir standarda göre sertifikalandırılmış değildir ve olduğunu iddia etmiyoruz. Uyum, kurumun kendi kapsamı, politikaları ve denetimiyle sağlanır. Bir yazılımın yapabileceği tek şey, çerçevelerin istediği kontrollerin işlediğini gösteren kaydı üretmektir. Bu sayfa yalnız bunu anlatır: hangi beklentiye karşılık hangi kayıt çıkar.SQL Change Guard is not certified against any standard and we do not claim it is. Compliance comes from your own scope, policies and audit. The only thing software can do is produce the record that shows a control operates. That is all this page describes: which record answers which expectation.
ISO, COBIT, ITIL ve yerel düzenlemeler farklı diller kullanır ama veritabanı katmanında hepsi aynı dört soruya gelir. Kurumların çoğu her çerçeve için ayrı hazırlık yapar; oysa bu dört sorunun cevabı bir kez üretildiğinde hepsine birden yeter.ISO, COBIT, ITIL and local regulation use different vocabularies, but at the database layer they all arrive at the same four questions. Most organisations prepare separately for each framework, when producing the answer to these four once serves all of them.
Sertifikanız varsa bile veritabanı katmanının kapsamda olması ayrıca gösterilmesi gereken bir şeydir. Aşağıdaki dört kontrol veritabanı tarafında en sık bulgu üreten kontrollerdir.Even with a certificate, the database layer being in scope is something you have to demonstrate separately. The four controls below are the ones that most often produce findings at the database layer.
| KontrolControl | BeklentiExpectation | Üretilen kayıtRecord produced |
|---|---|---|
| 8.2 Ayrıcalıklı erişim haklarıPrivileged access rights |
Yükseltilmiş yetkiler sınırlı, tahsisli ve izlenebilir olmalı; kullanımı gözden geçirilmeli.Elevated permissions must be limited, allocated and monitored, and their use reviewed. | Yetki değişikliği kayıtları, izin bazlı yetkilendirme tablosu, yetkili işlemlerin talep kaydına bağlanması ve rol atama denetim izi.Permission change records, the permission based access table, privileged operations tied to a request record and the audit trail of role assignments. |
| 8.15 Kayıt tutmaLogging |
Faaliyet kayıtları üretilmeli, saklanmalı, korunmalı ve gözden geçirilmeli.Activity records must be produced, retained, protected and reviewed. | Anahtarlı özet zinciriyle imzalanmış denetim izi, ayrı veritabanındaki tam satır kopyası ve zincir doğrulama sonucu. Kaydın korunduğu, denetçinin kendi makinesinde de gösterilebilir: imzalı kanıt paketi ve daha önce teslim edilmiş çapayla karşılaştırma (nasıl).An audit trail signed with a keyed digest chain, a full row copy in a separate database and the chain verification result. That the record is protected can also be demonstrated on the auditor's own machine: a signed evidence package and a comparison against an anchor delivered earlier (how). |
| 8.32 Değişiklik yönetimiChange management |
Bilgi işleme tesislerindeki değişiklikler kontrollü bir prosedüre tabi olmalı.Changes to information processing facilities must follow a controlled procedure. | Talep, kural değerlendirmesi, risk bandı, onay zinciri, çalıştırma kaydı ve metin özeti karşılaştırması; reddedilen talepler dahil.The request, the rule assessment, the risk band, the approval chain, the execution record and the digest comparison, including rejected requests. |
| 8.33 Test bilgisiTest information |
Test verisi dikkatle seçilmeli, korunmalı ve kontrol edilmeli.Test information must be selected with care, protected and controlled. | Üretimden veri çıkışının talep kaydı, maskeleme kararı ve indirme gerekçesi. Sınır: ürün, ortamlar arası toplu veri kopyalamayı yönetmez; yalnız kişilerin üretimden veri almasını kayda bağlar.The request record for data leaving production, the masking decision and the download reason. Limit: the product does not govern bulk copying between environments; it records people taking data out of production. |
Ayrıntı için: ISO 27001 ve veritabanı: dört kontrolün karşılığı.In depth: ISO 27001 and the database: what four controls mean.
Her iki çerçeve de teknoloji bağımsız yazıldığı için veritabanını ayrıca ele almaz. Beklenti kapsamdadır ama süreç genellikle uygulama sürümü örneği üzerinden tasarlanmıştır; kopma buradan başlar.Both frameworks are written to be technology neutral, so neither addresses the database separately. The expectation covers it, but the process was usually designed around an application release, and that is where the break starts.
| BeklentiExpectation | Üretilen kayıtRecord produced |
|---|---|
| BAI06 Değişiklikler kaydedilir, sınıflandırılır, etki ve riski değerlendirilir, yetkilendirilir, planlanır.BAI06 Changes are logged, categorised, assessed for impact and risk, authorised and planned. | Her talepte kural tabanlı risk bandı ve tetiklenen bulguların listesi. Değerlendirme insan yargısı değil yazılı kural olduğu için aynı betik her zaman aynı sonucu alır ve denetçiye tekrar üretilebilirlik gösterilebilir.A rule based risk band on every request with the list of findings that fired. Because the assessment is written rules rather than human judgement, the same script always gets the same result and reproducibility can be demonstrated. |
| BAI06.03 Durumu izleyen ve raporlayan bir sistem bulunur; reddedilen değişiklikler de belgelenir.BAI06.03 A system tracks and reports status, and rejected changes are documented as well. | Red kararı talebin kendi geçmişine gerekçesiyle yazılır ve raporlarda görünür. Bu, kurumların en sık eksik bıraktığı kanıttır: yalnız onayların göründüğü bir kayıt, kontrolün eleme yaptığını göstermez.A rejection is written into the request's own history with its reason and appears in reports. This is the evidence organisations most often lack: a record showing only approvals does not demonstrate that the control filters anything. |
| Acil değişiklikler kontrollü bir yoldan geçer ve sonradan uygun biçimde değerlendirildiği doğrulanır (COBIT); uygulama sonrası inceleme yapılır (ITIL).Emergency changes follow a controlled route and are verified afterwards as appropriately assessed (COBIT); a post implementation review is carried out (ITIL). | Acil kayıt olay numarasıyla açılır, gerekçesi yazılır ve sonradan değerlendirme borcu açık listede kalır. Böylece acil kanalın kısayola dönüşüp dönüşmediği bir sayıyla görünür.An emergency record is opened with an incident number and a stated reason, and the post hoc review stays on an open list until closed. Whether the emergency route has become a shortcut becomes visible as a number. |
| ITIL 4 değişiklik yetkilisi bir kişi, ekip veya otomatik mekanizma olabilir; yetki riske göre dağıtılmalıdır.An ITIL 4 change authority can be a person, a team or an automated mechanism, and authority should be distributed by risk. | Onay politikaları risk bandına göre tanımlanır: düşük bant tek onayla veya önceden yetkilendirmeyle geçer, yüksek bant çok kişili onay ve gerekçe ister. Kurul yalnız gerçekten değerlendirme gerektiren işi görür.Approval policies are defined per risk band: a low band passes with one approval or pre authorisation, a high band requires multiple approvals and a stated reason. The board sees only work that genuinely needs assessment. |
| MEA İç kontrolün ve dış gerekliliklere uyumun sürekli izlenmesi.MEA Continuous monitoring of internal control and of compliance with external requirements. | Kontrol istisnaları panoda gün içinde görülür; otuz bir hazır rapor beş grupta düzenli çalıştırılabilir. Kanıtın yılda bir kez elle toplanması gerekmez.Control exceptions are visible on the dashboard during the day and thirty one built in reports across five groups can be run on a schedule. Evidence does not have to be assembled by hand once a year. |
Ayrıntı için: COBIT BAI06 ve ITIL 4: veritabanı katmanındaki beş kopma noktası.In depth: COBIT BAI06 and ITIL 4: five break points at the database layer.
Veritabanı tarafında kişisel veri riski değişiklikte değil, okumada yoğunlaşır. Değişiklik yönetimi olgun olan kurumlarda bile üretimden veri çekme tarafı çoğu zaman yönetilmez.At the database layer, personal data risk concentrates in reads rather than changes. Even in organisations with mature change management, extracting data from production usually goes ungoverned.
| İlkePrinciple | Üretilen kayıtRecord produced |
|---|---|
| İşleme faaliyetinin kaydıRecord of the processing activity | Üretimden veri çeken her talep: kim istedi, hangi gerekçeyle, hangi sunucudan, hangi kolonlar, sonucu kim indirdi ve neden.Every request that pulls data from production: who asked, on what stated basis, from which server, which columns, who downloaded the result and why. |
| Veri minimizasyonuData minimisation | Hassas kolonlar varsayılan olarak maskelenir. Maskesiz erişim ayrı bir karardır, gerekçe ve ek onay gerektirir; kurum sunucu bazında yalnız maskeli teslim rejimi uygulayabilir.Sensitive columns are masked by default. Unmasked access is a separate decision requiring a reason and an extra approval, and a masked only regime can be enforced per server. |
| Veri güvenliği tedbirleriData security measures | Sonuç şifreli paketle teslim edilir, paket parolası e-postayla gönderilmez, erişim izleri denetim iziyle imzalanır. Ayrıntı: güvenlik mimarisi.The result is delivered as an encrypted package, the package password is not emailed, and access traces are signed into the audit trail. Detail: security architecture. |
| Veri işleyenle müşterek sorumlulukJoint responsibility with a processor | Tedarikçi ve danışmanlara kalıcı sunucu parolası vermek yerine talep akışı üzerinden çalıştırma. Kimin ne yaptığı kurum tarafında kayıtlı kalır.Vendors and consultants work through the request flow rather than holding a standing server password. What each of them did stays recorded on your side. |
Ayrıntı için: KVKK denetimine veritabanı tarafında hazırlık ve test ortamında gerçek veri.In depth: preparing the database side for a data protection audit and real data in test environments.
Denetimde takılınan yer kayıt tutulmaması değil, tutulan kaydın soruyu cevaplamamasıdır. Dört soru ve dört kanıt kalemi (talep, değerlendirme, onay, çalıştırma) tek bir dosyada birleştiğinde örneklem incelemesi dakikalar sürer.What stalls an audit is not missing records but records that do not answer the question. When the four questions and four kinds of evidence (request, assessment, approval, execution) come together in one file, sample review takes minutes.
Yönetici ve tedarikçi hesapları dahil her hesabın izlenebilirlik için benzersiz kimliği olması beklenir. Veritabanı katmanında bu beklenti sık ihlal edilir, çünkü işlemler paylaşılan servis hesapları üzerinden görünür. Çözüm hesapları bölmek değil, bağlantı kimliği ile işlem kimliğini ayırmaktır.Every account, including administrative and vendor accounts, is expected to carry a unique ID for traceability. At the database layer this is often breached because operations appear under shared service accounts. The answer is not splitting accounts but separating connection identity from action identity.
Paylaşılan hesapların atıf sorunuThe attribution problem of shared accounts
Bir talebin kanıt dosyası tek bir paket olarak dışa aktarılır. İçinde okunabilir bir özet belgesi, makinece işlenebilir veri ve paketi mühürleyen bir özet bulunur. Denetçi paketi bağımsız olarak doğrulayabilir; dosyanın üretildiği andaki hali olduğunu ürün olmadan da gösterebilir.The evidence file for a request is exported as one package. It contains a readable summary document, machine processable data and a digest that seals the package. An auditor can verify it independently and show that the file is as it was produced, without needing the product.
Kanıt dışa aktarmanın kendisi de ayrı bir yetkiye tabidir ve denetim izine yazılır: kanıtı kimin, ne zaman, hangi talep için aldığı kayıtlıdır.Exporting evidence is itself a separate permission and is written to the audit trail: who took the evidence, when and for which request is recorded.
Denetimin en zor sorusu geçmiş bir kararın o günkü kurala göre değerlendirilmesidir. Kural seti talep açıldığı anda kaydın içine dondurulur. Politikalar sonradan değiştiğinde geçmiş karar hala kendi bağlamında okunur ve haksız yere hatalı görünmez.The hardest question in an audit is judging a past decision against the rule of that day. The rule set is frozen into the record at the moment the request is opened. When policies change later, the past decision is still read in its own context rather than looking wrong through no fault of its own.
Geçen denetimde size sorulan soruları getirin; her biri için kanıtın nereden çıktığını canlı gösterelim.Bring the questions you were asked in your last audit; we will show live where the evidence for each one comes from.
Demo talep edin →Request a demo →İlgili sayfalar: güvenlik mimarisi, denetim izi ve kanıt, Database Operations Governance nedir.Related pages: security architecture, audit trail and evidence, what Database Operations Governance is.