Neler Değişti ve Neden?What Changed and Why?

DoğrulukAccuracy

Saatler Artık Her Yerde Aynı Şeyi SöylüyorTimes Now Say the Same Thing Everywhere

Sorun: Bazı oluşturma tarihleri saat dilimi bilgisi taşımıyordu. Değer veritabanından çıktığı anda kendini anlatmadığı için onu okuyan taraf yerel saat sanıyor ve saat kayıyordu. Aynı sistemde bir ekranda doğru, başka bir belgede saatlerce farklı bir zaman görünebiliyordu.

Problem: Some creation dates carried no time zone information. Because the value did not describe itself once it left the database, the reader assumed local time and the clock drifted. The same system could show a correct time on one screen and a time hours apart in another document.

Çözüm: Zaman modeli tek kurala indirildi: an bildiren her değer evrensel saatte ve saat dilimi bilgisiyle saklanır, yereli yalnızca göz görür. Ekranda tarayıcınızın saati, sunucuda üretilen PDF, Excel ve e-postalarda ise kurulumun saat dilimi kullanılır ve belgenin üzerine yazılır. Tarih filtrelerinde seçtiğiniz gün sizin yerel gününüzdür, bitiş günü de dahildir. Kural artık dokümanla değil testle korunuyor: şemaya saat dilimi taşımayan bir tarih kolonu eklenirse test kırılıyor.

Solution: The time model was reduced to a single rule: every instant is stored in universal time with its time zone, and only the eye sees local time. Screens use your browser clock; PDF, Excel and e-mail produced on the server use the installation time zone and print it on the document. In date filters the day you pick is your local day and the end day is included. The rule is now protected by a test rather than a document: adding a date column without time zone information breaks the build.

DenetimAudit

Ayar Onaylarında Kim Ne YaptıWho Did What in Settings Approvals

Sorun: Dört göz kuralı açıkken bir ayarı bir kişi istiyor, başka biri onaylıyordu. Onay verildiğinde kaydın üzerine yalnızca onaylayanın adı yazıldığı için talep eden kişi kaydın üzerinde hiç görünmüyordu. Denetimde "bu ayarı kim değiştirdi" sorusunun cevabı eksik kalıyordu.

Problem: While the four eyes rule was on, one person requested a setting and another approved it. On approval only the approver name was written onto the record, so the requester never appeared on it. During an audit, the answer to "who changed this setting" stayed incomplete.

Çözüm: Dört göz kapsamındaki tüm ayar ekranlarına Son değişiklik sütunu eklendi. Üst satırda değişikliği isteyen kişi ve zamanı, altındaki rozette onaylayan görünür. Onay verildiğinde kayda artık talep edenin adı yazılır, onaylayanın adı ve IP adresi ise onay kaydında durur. Denetim izi iki ayrı satır üretir ve hiçbiri yanlış kişiyi göstermez. Ayrıca her ayar ekranında yenile düğmesi vardır: onayı başka bir kullanıcı verdiği için ekrandaki liste her an eskiyebilir.

Solution: A last change column was added to every settings screen inside the four eyes scope. The top line shows who requested the change and when, and the badge below shows the approver. On approval the requester name is now written onto the record, while the approver name and IP address stay on the approval entry. The audit trail produces two separate rows and neither points at the wrong person. Every settings screen also has a refresh button, because another user gives the approval and the list on screen can become stale at any moment.

DenetimAudit

Denetçi RolüThe Auditor Role

Sorun: Denetim ekibine sistemi izletmek için ya fazla yetki veriliyor ya da hiç erişim verilmiyordu. İkisi de yanlış: birincisi denetleyeni akışın parçası yapar, ikincisi denetimi ekran görüntüsüne mahkum eder.

Problem: To let an audit team observe the system, organizations either granted too much access or none at all. Both are wrong: the first makes the auditor part of the flow, the second reduces auditing to screenshots.

Çözüm: Denetçi ayrı bir roldür. Tüm talepleri görür, denetim kayıtlarını inceler, raporları kullanır, kanıt dosyası üretip indirir ve denetim izinin bütünlüğünü doğrular. Talep açamaz, onaylayamaz, çalıştıramaz, ayar yönetemez ve sorgu sonucu dosyasını indiremez. Son madde bilinçlidir: kanıt paketine sorgu sonucu verisi girmediği için denetçi kanıta ulaşır, üretim verisine ulaşmaz. Denetçi onay adımlarında onaylayan olarak seçilemez; denetleyen kişinin onaylayan konumuna geçmesi kontrolün kendisini ortadan kaldırırdı.

Solution: The auditor is a dedicated role. It sees every request, reviews audit records, uses reports, produces and downloads the evidence dossier and verifies the integrity of the audit trail. It cannot raise, approve or execute a request, manage settings, or download a query result file. That last point is deliberate: query result data never enters the evidence package, so the auditor reaches the evidence without reaching production data. The auditor also cannot be selected as an approver in a policy step, because someone who audits must not become someone who approves.

UyumlulukCompliance

Ayar Değişikliklerinde Dört Göz İlkesiFour Eyes Principle for Settings Changes

Sorun: Bir kontrolü zayıflatan ayar tek kişinin kararıyla değişebiliyordu ve değişiklik sıradan bir güncelleme gibi görünüyordu.

Problem: A setting that weakens a control could be changed by one person, and the change looked like an ordinary update.

Çözüm: Kurumsal bir parametre ile ayar ekranlarındaki değişiklikler onaya bağlanabilir. Onay bekleyen değişiklik ayrı bir kayıtta durur, gerçek ayar tablosuna dokunulmaz ve eski değer geçerli kalır. Onay verildiğinde değişiklik kullanıcı kaydetmiş gibi aynı yoldan uygulanır; lisans limiti, doğrulama ve eşzamanlılık kontrolleri o anda yeniden çalışır. Onay yetkisi ilgili ekranın kendi yetkisidir, yeni rol tanımlanmaz. Kimse kendi talebini onaylayamaz.

Solution: One organization wide parameter can put settings screen changes behind approval. The pending change is held separately, the real settings table stays untouched and the previous value remains in effect. On approval the change is applied through the very same path as a normal save, so licence limits, validation and concurrency checks all run at that moment. Approval authority is the screen's own permission, no new role is created, and nobody can approve their own request.

Kapsam: sunucu tanımları, kullanıcı kayıtları, rol yetki matrisi, onay politikaları, SQL standartları, kritik obje listesi, hassas kolon kataloğu, hassas veri desenleri, aday kolonlar, onaylı e-posta adresleri, bakım işleri ve kontrol parametreleri. Parametre ekranında hangi ayarın onaya düşeceği rozetle gösterilir ve kaydetmeden önce uyarı verilir.

Scope: server definitions, user records, the role permission matrix, approval policies, SQL standards, the critical object list, the sensitive column catalog, sensitive data patterns, candidate columns, approved recipient addresses, maintenance jobs and control parameters. On the parameters screen a badge shows which setting will require approval, and a warning appears before saving.

Veri KorumaData Protection

Hassas Veri Maskeleme v2Sensitive Data Masking v2

Sorun: Yalnızca içerik desenine bakan bir maskeleme, boş kalan veya beklenmedik biçimde yazılmış hassas kolonları kaçırıyordu. Kolona takma ad vererek kontrolden kaçmak da mümkündü.

Problem: Masking that only looked at content patterns missed sensitive columns that were empty or written in an unexpected format, and giving a column an alias could bypass the control.

Çözüm: İki dedektör birlikte çalışır. Birincisi 103 kayıtlık hassas kolon kataloğuyla kolon adını eşler; katalog kimlik, iletişim, kart, finans, sağlık, eğitim ve güvenlik başlıkları altında hazır gelir. İkincisi 16 desenle hücre içeriğini tarar. TC kimlik numarası, vergi numarası, kart numarası ve IBAN için sağlama algoritmaları çalıştığından yanlış pozitif azalır. Kolonun kaynağı talep kaydedilirken saklandığı için takma ad koruması çalıştırma anında da geçerlidir. Her kolonun maskelenip maskelenmediği gerekçesiyle kaydedilir.

Solution: Two detectors work together. The first matches column names against a 103 entry sensitive column catalog covering identity, contact, card, finance, health, education and security. The second scans cell content with 16 patterns. Checksum algorithms for national ID, tax ID, card number and IBAN reduce false positives. Because the source of each column is captured when the request is saved, alias protection holds at execution time too. Whether each column was masked is recorded together with the reason.

Veri KorumaData Protection

Sunucu Bazlı Maskeleme RejimiPer Server Masking Regime

Sorun: Test ortamında kolon adı kataloğu gereksiz uyarı üretiyor, production ile aynı sıkılık ekipleri kuralı komple kapatmaya itiyordu.

Problem: On test environments the column name catalog produced unnecessary noise, and applying production level strictness everywhere pushed teams towards turning the rule off completely.

Çözüm: Her sunucu Strict veya ContentOnly olarak işaretlenir. ContentOnly seçildiğinde kolon adı kataloğu devre dışı kalır ama içerik taraması sürer; yani sahte veri kullanan bir test ortamı rahatlar, gerçek kişisel veri kalmışsa yine maskelenir. Rejimi gevşetmek yazılı gerekçe ister, ekranda uyarı görünür ve muaf sunucular ayrı bir raporda listelenir.

Solution: Each server is marked Strict or ContentOnly. With ContentOnly the column name catalog is disabled while content scanning continues, so a test environment using synthetic data gets room to breathe and real personal data is still masked if it remains. Relaxing the regime requires a written justification, a warning is shown on screen and exempt servers are listed in a dedicated report.

DenetimAudit

Kanıt Dosyası (Evidence Dossier)Evidence Dossier

Sorun: Denetçiye kanıt sunmak, ekran görüntüsü toplayıp elle belge hazırlamak demekti.

Problem: Presenting evidence to an auditor meant collecting screenshots and assembling a document by hand.

Çözüm: Bir talebin tüm hikayesi tek pakette dışa aktarılır: okunabilir PDF özet, makine okunur JSON ve içerikle uyuşup uyuşmadığı doğrulanabilen manifest. Kanıt dosyasını üretmek ayrı bir yetkiye bağlıdır ve dışa aktarma işleminin kendisi de kayda geçer. Sorgu sonucu verisi pakete girmez; paket kanıttır, veri kopyası değildir.

Solution: The whole story of a request is exported in one package: a readable PDF summary, machine readable JSON and a manifest that can be checked against the contents. Producing the dossier requires its own permission and the export itself is recorded. Query result data never enters the package: it is evidence, not a copy of the data.

DenetimAudit

Kural Seti Anlık GörüntüsüRule Set Snapshot

Sorun: Kurallar zamanla değişiyordu ve altı ay önceki bir talebin hangi kurallara göre işlendiği kanıtlanamıyordu.

Problem: Rules changed over time and there was no way to prove which rules governed a request from six months ago.

Çözüm: Talep kaydedilirken o an geçerli olan kural seti tek bir denetim olayında dondurulur: sunucu ayarları, onay politikası, maskeleme rejimi, teslim ayarları, SQL standartları ve lisans durumu. Ayrıca kontrolü zayıflatan değişiklikler ayrı adlı olaylar üretir, böylece "kim gevşetti" sorusu da tek aramayla cevaplanır.

Solution: When a request is saved, the rule set in force at that moment is frozen in a single audit event: server settings, approval policy, masking regime, delivery settings, SQL standards and licence state. In addition, control weakening changes produce their own named events, so the question of who relaxed a control is answered with one search.

DenetimAudit

Denetim İzi DoğrulamaAudit Trail Verification

Sorun: Denetim kayıtlarının değiştirilmediğini söylemek kolaydı, kanıtlamak zordu.

Problem: Claiming that audit records were not altered was easy, proving it was not.

Çözüm: Kayıtlar hash zinciriyle mühürlenir ve ayrı bir kopyaya tam satır olarak yazılır. Doğrulama tek işlemle çalışır; zincirle veya kopyayla uyuşmayan satır listelenir. Böylece bütünlük iddiası çalıştırılabilir bir kontrole dayanır.

Solution: Records are sealed with a hash chain and written as complete rows to a separate copy. Verification runs in a single action and lists any row that does not match the chain or the copy, so the integrity claim rests on an executable check.

YönetişimGovernance

Sürüm Paketlerinde Kapsam NetliğiScope Clarity in Release Packages

Sorun: Sürüm paketi bir teslimat aracıdır; içine sorgu talebinin girmesi kapsam karışıklığı yaratırdı.

Problem: A release package is a delivery vehicle, and letting a query request into it blurred the scope.

Çözüm: Sürüm paketine yalnızca değişiklik talepleri eklenebilir. Sorgu talebi eklenmeye çalışıldığında işlem birden fazla katmanda engellenir ve gerekçe kullanıcıya açıkça gösterilir.

Solution: Only change requests can be added to a release package. Attempting to add a query request is blocked at more than one layer and the reason is shown clearly to the user.

RiskRisk

Risk Modeli: Bant YaklaşımıRisk Model: The Band Approach

Puan toplayan ve ortalayan model kaldırıldı. Karar artık en kötü duruma göre verilir: tetiklenen en yüksek seviye bandı belirler, iki küçük uyarı bir kritik bulguyu dengelemez. Sayısal skor bandın okunur yansımasıdır. Kararı hangi kuralın verdiği açıkça gösterilir ve aynı açıklama kanıt dosyasına da yazılır. Atlanamaz olarak işaretlenen bir kural tetiklendiğinde onay adımları atlanamaz.

The model that added and averaged points was removed. The decision now follows the worst case: the highest tier triggered sets the band, and two minor warnings never offset one critical finding. The numeric score is a readable projection of the band. The rule that determined the decision is shown explicitly and the same explanation is written into the evidence dossier. When a rule marked non skippable fires, approval steps cannot be skipped.

Oracle

Oracle ÇözümleyiciOracle Parser

Oracle tarafında kurallar artık cümle ağacı üzerinde değerlendiriliyor, metin arama ile değil. Böylece SQL Server tarafındaki rapor ve kural davranışıyla eşitlik sağlandı. Rollback üretiminde Oracle'ın DDL ifadelerinde örtülü commit ürettiği dikkate alınır.

On Oracle, rules are now evaluated on the statement tree rather than by text search, bringing rule and report behaviour to parity with SQL Server. Rollback generation takes into account that Oracle DDL statements produce an implicit commit.

GüvenlikSecurity

Sunucu Kimlik Bilgilerinin ŞifrelenmesiEncryption of Server Credentials

Hedef veritabanı sunucularının parolaları AES-256-GCM ile şifrelenerek saklanır. Şifreleme anahtarı yapılandırma dosyasından okunur ve veritabanında tutulmaz. Kullanıcı parolaları geri döndürülemez biçimde BCrypt ile, denetim kayıtları HMAC ile korunur.

Target database credentials are stored encrypted with AES-256-GCM. The encryption key is read from the configuration file and never kept in the database. User passwords are protected irreversibly with BCrypt and audit records with HMAC.

LisanslamaLicensing

Modüler Lisans SadeleştirmesiSimplified Modular Licensing

Lisans modeli sadeleştirildi. Kullanıcı sayısı sınırı kaldırıldı; ölçek yönetilen sunucu sayısı üzerinden ilerliyor. Sorgu yönetişimi, sandbox, rollback, planlı çalıştırma, sürüm paketleri ve yönetim raporları ayrı modüller olarak açılabiliyor. Kullanılabilir veritabanı tipleri de lisansla belirleniyor.

The licensing model was simplified. The user count limit was removed and scale is now based on the number of managed servers. Query governance, sandbox, rollback, scheduled execution, release packages and management reporting can be enabled as separate modules, and the available database types are also determined by the licence.