Her talep için bir denetim dosyası üretilir: kim istedi, hangi kural geçerliydi, kim onayladı, ne çalıştı, hangi istisnalar oluştu. Bu sayfa kaydın nasıl korunduğunu, denetçiye ne teslim edildiğini ve dosyanın ürün olmadan nasıl doğrulandığını anlatır.
Kısaca
Doğrulamanın neye dayandığını bilmeden adımlar anlamsız kalır. Katmanlar ayrı ayrı şöyle çalışır.
| Katman | Ne yapar | Kime karşı |
|---|---|---|
| Defter tablosu | Denetim kayıtları SQL Server 2022'nin append-only ledger tablosunda durur. Veritabanı motoru kayıt değiştirmeyi ve silmeyi herkes için reddeder. Kayıtlar tek bir yordamla yazılır ve olay zamanını o yordam verir. | Kaydı sonradan değiştirmek ya da silmek isteyen herkes, veritabanı yöneticisi dahil |
| İmzalı defter özeti | Defter özeti varsayılan olarak saatte bir alınır. Özeti API üretir; imza anahtarı tanımlıysa kurumun RSA anahtarıyla imzalar ve dış depo klasörü tanımlıysa kurumun değiştirilemez deposuna dosya olarak yazar (ledger-digest-...json ve .sig). Klasör tanımlı değilse dış dosya yazılmaz. Worker yalnız turu başlatır ve imza anahtarına erişmez. | Veritabanı dosyasını doğrudan değiştiren ya da eski bir yedeğe dönen biri. Özet daha önce dışarı yazıldığı için fark doğrulamada görünür |
| Kanıt yazma sınırı | Ürün, kanıt tablosunda tetikleyici olmadığını, yazma yordamının yayımlanan sürümle aynı olduğunu ve kanıt şemasında beklenmeyen nesne olmadığını varsayılan olarak 15 dakikada bir denetler. Sınır bozulursa değişiklik işlemlerini durdurur. | Yazma yolunu değiştirerek sahte ya da eksik kayıt yazdırmak isteyen biri |
| İmzalı paketler | İmza anahtarı tanımlı kurulumda denetçiye giden her paket, içindeki dosyaların SHA-256 listesiyle birlikte imzalanır. | Teslim edildikten sonra dosyayı değiştiren biri |
Denetim genellikle şöyle ilerler: denetçi rastgele bir değişiklik seçer ve o değişikliğin hikâyesini ister. Kim istedi, hangi kurala göre onaylandı, kim çalıştırdı, betik o gün ne idi.
Bu sorunun cevabı tek bir dosya olarak dışa aktarılır. İçinde künye, görevler ayrılığı ve o gün geçerli kurallar, zaman çizelgesi, onay kanıtı, betiğin parmak izi, risk dökümü, izole deneme sonucu, çalıştırma sonucu, ITSM kontrolleri, kararı verenlerin oturum bilgisi, sorgu teslim bilgisi, istisnalar ve ham denetim kaydı bulunur.
Dosyadaki bilgilerin bir kısmı ürünün normal tablolarından okunur. Dosya üretilirken bu bilgilerin her biri defterdeki haliyle alan alan karşılaştırılır ve sonuç dosyada ayrı bir bölüm olarak yazar: PASS, MISMATCH, MISSING, UNEXPECTED ya da INTEGRITY_FAILURE. Ayrıca her olayın zamanı defterdeki commit zamanıyla, yazan kimlik de ürünün kendi hesaplarıyla karşılaştırılır. Uyuşmayan bir şey varsa dosyanın en üstündeki hüküm kırmızıdır. Bu hüküm ürünün kendi değerlendirmesidir; bağımsız doğrulama denetçinin elindedir.
Dosyanın kendi mührü vardır ve bu mühür denetim kaydına da yazılır. Dosyanın üretimden sonra değiştirilip değiştirilmediği bu iki değerin karşılaştırılmasıyla anlaşılır.
Teslim edilen şey tek bir zip dosyasıdır. İçinde verinin yanında bir künye dosyası ve bir doğrulama betiği, imza anahtarı tanımlı kurulumda ayrıca o künyenin RSA imzası ve imzayı doğrulayan açık anahtar bulunur. Denetçi bu doğrulamayı ürüne hiç bağlanmadan, kendi makinesinde yapabilir: kanıt paketi nasıl doğrulanır.
İki kural. Sorgu talebinde sonucun kendisi dosyaya girmez; yalnız kime teslim edildiği ve hangi kolonun maskesiz onaylandığı yazılır, aksi halde dosya yeni bir sızıntı kanalı olurdu. İkincisi, dosyanın dışa aktarılması da bir olaydır ve denetim kaydına yazılır.
Örnek, bir test kurulumunda baştan sona çalıştırılmış bir değişiklik talebinden (bir talep sahibi, iki onaylayan, ayrı bir çalıştıran) üretilmiştir ve değiştirilmemiştir; deneme anahtarıyla imzalıdır. Paketin tamamını (zip) indirip içindeki Verify.ps1 ile kendiniz doğrulayabilirsiniz.
Bir talep kaydedilirken, onu etkileyen kural seti ve etkin ayarlar tek bir denetim olayında dondurulur. Altı ay sonra kurallar değişmiş olsa bile talebin hangi kurallara göre değerlendirildiği okunabilir.
Bir kuralı kapatmak veya derecesini düşürmek, kural güncellemesi olayıyla (SqlStandard.Update) eski ve yeni değeri birlikte denetim kaydına yazılır ve SIEM'e kontrol değişikliği olarak, ciddiyet eşiğinden bağımsız gider. Ayrı bir olay adı yalnız uygulama yapılandırmasının gevşetilmesinde (App.ControlRelaxed) ve sunucu kontrol alanlarının gevşetilmesinde (örneğin Server.MaskingRelaxed) kullanılır. Böylece "denetimden önce hangi kontroller gevşetildi" sorusu cevaplanabilir.
Dört göz açıldığında ayar ekranlarındaki değişiklik canlı kayda hemen yazılmaz; kurum bunu bütün ayarlar ya da yalnız kontrol ayarları için açar, kurulum varsayılanında kapalıdır. Bekleyen bir kayıt olarak durur ve başka bir kullanıcının onayını bekler. Kişi kendi ayar değişikliği talebini hiçbir ayarda onaylayamaz.
Talep sahibinin kendi talebini çalıştırması gibi durumlar dosyada istisna olarak görünür. Yönetişimin ölçüsü ihlalin hiç olmaması değil, olduğunda görünmesidir.
Üç ayrı paket üretilir çünkü üç ayrı soruya cevap verirler. Ambalajları aynıdır: denetçi tek bir yordam öğrenir. Defter özeti dosyaları paket değildir; kurumun değiştirilemez deposundan ayrıca alınır.
| Paket | Hangi soruyu cevaplar | Veri dosyaları |
|---|---|---|
| Denetim dosyası SQLChangeGuard-Evidence |
Örneklediğiniz tek bir talebin baştan sona hikâyesi: kim istedi, hangi kurala göre onaylandı, kim çalıştırdı, betik o gün ne idi. Dosya üretilirken tablodan okunan her bilgi defterdeki haliyle alan alan karşılaştırılır ve sonuç dosyaya yazılır. | Dossier.json Dossier.pdf |
| Dönem paketi SQLChangeGuard-PeriodPackage |
"Bütün talepleri gördüm mü?" Dönemin talepleri iki ayrı kaynaktan (talep tablosu ve denetim kaydı) toplanıp satır satır uzlaştırılır. Kontrol sağlığı olayları ve dönemde yapılan dışa aktarmalar da pakettedir. | Population.json ControlHealth.json Exports.json |
| Kayıt paketi SQLChangeGuard-AuditRecords |
Seçtiğiniz kayıt numarası aralığındaki ham denetim satırları, kendi aracınızda incelemek için. Paket teslim anındaki içeriği imzayla sabitler; kayıtların sonradan değişmediğini paket değil defter gösterir. | Package.json |
Her dışa aktarma da bir olaydır. Paket üretildiğinde denetim kaydına bir olay yazılır ve olayın numarası Manifest.json içinde durur. Ürünün Kanıt Doğrula ekranı bu numarayla ve paketin özetiyle, elinizdeki paketin gerçekten bu kurulumdan o anda çıkıp çıkmadığını söyler. Bu bir kolaylıktır; bağımsız doğrulama aşağıdaki adımlardır.
| Dosya | Ne işe yarar |
|---|---|
| Veri dosyaları | Yukarıdaki tabloda paket başına yazılanlar. Düz metin JSON, gözle de okunur. Denetim dosyasında ayrıca okunabilir PDF bulunur. |
| Manifest.json | Paketin künyesi: kurulum kimliği, ürün sürümü, kapsam ve paketteki her dosyanın SHA-256 özeti. Paketten bir dosya çıkarıldığında bunu yakalayan şey listenin kendisidir. |
| Manifest.sig | Manifest.json baytlarının RSA imzası. İmza teslim edilen baytların üzerindedir, yeniden hesaplanmış bir kopyanın değil. |
| PublicKey.pem | Manifesti imzalayan anahtarın açık kısmı. Tek başına güven vermez: parmak izi kurumun paket dışında yayımladığı değerle karşılaştırılmalıdır. |
| Verify.ps1 | Dosya özetlerini, imzayı ve onay zincirini (kayıt, onay ve çalıştırma olaylarının aynı içerik parmak izini taşıdığını) sizin yerinize kontrol eden betik. Windows PowerShell 5.1 ile çalışır, ek kurulum istemez. Betiğin özeti de manifeste yazılıdır, yani değiştirilmiş bir sürüm yakalanır. Kolaylıktır, kanıt değildir. |
İmza parametreleri: RSA, SHA-256, PKCS#1 v1.5, PEM anahtar. Anahtar uzunluğu olarak 3072 bit önerilir; daha kısa bir anahtarla imza yine atılır ama ürün günlüğe uyarı yazar. İmza, kurulumda bir imza anahtarı tanımlanınca açılır; kod varsayılanı kapalıdır. İmzasız pakette Verify.ps1 dosya özetlerini yine denetler ama sonuca UNSIGNED yazar ve paketin kaynağı kanıtlanmış olmaz. Production olarak tanımlı sunucuda imza kapalıyken çalıştırma başlamaz. Zaman damgası açıksa denetim dosyasına ayrıca Manifest.tsr eklenir.
Adımlar birbirinin yerine geçmez. Birinin geçmesi diğerini geçmiş saymaz.
Açık anahtarın parmak izi hesaplanır ve kurumun paketlerin dışında yayımladığı değerle karşılaştırılır. Bu adım atlanırsa imza kontrolü hiçbir şey kanıtlamaz: paketin içine kendi anahtarını koyan biri de imzayı geçirir.
Cevapladığı soru: imzayı atan anahtar, kurumun ilan ettiği anahtar mı?
Manifest.sig, PublicKey.pem ile doğrulanır; sonra her dosyanın SHA-256 özeti yeniden hesaplanıp manifestteki listeyle karşılaştırılır. İkisi de geçerse paket, ilgili özel anahtarı tutan kurulumdan çıkmıştır ve o günden beri tek bayt değişmemiştir.
Cevapladığı soru: elimdeki dosyalar, kurumun imzaladığı dosyalar mı?
Değiştirilemez depodan aldığınız her ledger-digest dosyasının .sig imzası aynı açık anahtarla doğrulanır. Özet dosyasının içindeki değer veritabanı motorunun ürettiği özettir: veritabanı adı, blok numarası, özet ve son commit zamanı.
Cevapladığı soru: doğrulamada kullanacağım tanık, o saatte kurumdan çıkmış tanık mı?
İlk üç adım ambalajı ve tanığı doğrular. Dördüncüsü kayıtların kendisine bakar: veritabanı yedeği kurumun kendi ortamındaki bir test sunucusuna geri yüklenir ve SQL Server'ın kendi yordamı sys.sp_verify_database_ledger, değiştirilemez depodaki özetlerle çalıştırılır. Yedek kurumdan çıkmaz; denetçi komutu kendisi çalıştırır ya da çalıştırılmasını izler. Yordam salt okumadır; kopya, üretim sunucusuna yük bindirmemek için önerilir.
Cevapladığı soru: kayıtlar, özet dışarı yazıldığından beri yeniden yazılmış olabilir mi?
Geri yüklenen kopya kurumun ortamında durur; denetçi orada, kurumun canlı sistemine dokunmadan sorgu çalıştırır. Kurum denetçiye kopya için yalnız okuma yetkisi olan bir hesap açar ya da komutlar denetçinin gözetiminde çalıştırılır. Aşağıdaki kontrollerin hepsi o kopyada yapılır.
Dönemin son özet dosyasındaki digest değeri olduğu gibi kopyalanır ve sys.sp_verify_database_ledger yordamına verilir. Son özet kendisine kadar olan bütün blokları doğrular; daha önceki özetler de virgülle eklenebilir. Beklenen sonuç, doğrulamanın N numaralı bloğa kadar başarılı olduğunu söyleyen mesajdır. Hata, kopyadaki kayıtların dışarı yazılmış özetle uyuşmadığı anlamına gelir ve ilk uyuşmayan blok mesajda yazar.
Bu kontrolün gücü, özetin kayıtlardan önce ve kurumun veritabanı yöneticisinin silemeyeceği bir yere yazılmış olmasından gelir. Değiştirilemez depo kurumun sağladığı bir depodur (saklama kilitli bir nesne deposu ya da WORM paylaşımı); ürün bu kilidi kendisi sağlamaz.
Veritabanı dönem içinde geri yüklendiyse dönem paketinin kontrol sağlığı dosyasında Ledger.RestoreDetected ya da Ledger.ForkDetected olayı görünür. Bu durumda geri yükleme öncesi ve sonrası ayrı özet setleriyle ayrı ayrı doğrulanır ve kurumdan geri yüklemenin kaydı istenir.
Defter, her kaydı yazan veritabanı kimliğini ve commit zamanını kendisi tutar ve bu bilgi de defterle korunur. Örneklenen talebin olayları bu bilgiyle birleştirilir: yazan sütununda yalnız ürünün API ve Worker hesapları görünmelidir. Başka bir hesap, yazma yordamını atlayan doğrudan bir yazma demektir.
Olay zamanı yazma yordamında verildiği ve olay işle aynı transaction'da commit edildiği için commit zamanı olay zamanından önce olamaz ve kısa süre sonra gelir. Aradaki farkın büyük olması, geriye tarihli bir yazmanın işaretidir.
Dönem paketindeki her talep satırı bir uzlaşma sonucu taşır: Match (iki kaynak aynı şeyi söylüyor), NotInAuditTrail (talep tabloda var, oluşturma olayı kayıtta yok), NotInTable (olay var, talep satırı yok), StatusMismatch (son durumlar farklı) ya da InProgress (paket alınırken çalışıyordu). Aynı sayımı kopyada iki basit sorguyla kendiniz yapabilirsiniz.
Paket komutları zip açıldıktan sonra klasörün içinde çalışır; ürüne bağlanmaz, ağa çıkmaz. SQL komutları kurumun ortamındaki geri yüklenmiş kopyada çalışır.
Betik kanıtın parçası değildir. Verify.ps1 doğruladığı paketin içinden çıkar. Bağımsızlık isteyen denetçi, komutları en az bir kez kendi eliyle çalıştırmalıdır. Bütün adımlar, beklenen sonuçlarıyla birlikte Denetçi Kiti belgesinde yazılıdır; belge talep üzerine verilir.
Bu kalemler istendiğinde doğrulamanın tamamı yapılabilir.
Bu ayrım sektörde tamper evident ile tamper proof arasındaki farktır. Hiçbir koşulda değiştirilemeyen bir kayıt vaat etmiyoruz; değiştirildiğinde görünen bir kayıt üretiyoruz. İkincisi doğrulanabilir, birincisi yalnızca iddia edilebilir.
İmza, paketin kimden çıktığını gösterir; ne zaman çıktığını değil. Paketin tarihini kurum kendi sunucusunun saatinden yazar.
Bunun için denetim dosyasında RFC 3161 zaman damgası desteklenir. Açıldığında manifestin özeti dış bir zaman damgası sunucusuna gönderilir ve dönen yanıt Manifest.tsr olarak pakete konur. Böylece dosyanın o anda var olduğunu kurum değil, üçüncü bir taraf söyler.
Dışarıya çıkan tek şey özettir. Kaydın kendisi zaman damgası sunucusuna gönderilmez. Özellik kapatıldığında hiçbir ağ çağrısı yapılmaz ve ürün internet olmadan çalışmaya devam eder.
Kod varsayılanı kapalıdır, ancak ürünle gelen ayar dosyasında özellik açık gelir ve ücretsiz, herkese açık bir otoriteye işaret eder; böylece kurulumun ilk gününde uçtan uca çalıştığı görülebilir. Üretimde bu adresin kurumun kendi anlaşmalı ya da kurum içi otoritesiyle değiştirilmesi gerekir: açık bir hizmet kurumsal taahhüt vermez.
Sunucuya ulaşılamazsa iş durmaz, dosya damgasız üretilir ve eksiklik gizlenmez: Manifest.tsr konmaz ve günlüğe uyarı yazılır. Denetçi o pakette tarihin kurumun kendi beyanı olduğunu görür. Kayıtların sonradan değişmediğini ise zaman damgası değil defter gösterir.
| Grup | Hangi soruyu cevaplar |
|---|---|
| Change Governance | Hangi talep açıldı, ne kadar bekledi, kim onayladı, ne çalıştı, ne reddedildi. |
| Object & Structure | Hangi nesneye kim dokundu, hangi nesne ne sıklıkta değişti, nerede çakışma var. |
| Access & Authorization | Kim hesap açtı, kim yetki değiştirdi, ayrıcalıklı hesaplar ne yaptı. |
| Data & Privacy | Üretim verisine kim erişti, hangi kolon maskelendi, veriyi doğrudan değiştiren talepler hangileri. |
| Configuration & Compliance | Hangi ayar değişti, hangi kontrol istisnası oluştu, onay izi nasıl ilerledi. |
Raporların bir kısmı belirli rollerle sınırlıdır ve bu sınır sunucuda uygulanır; diğerleri rapor görme iznine sahip herkese açıktır. Rapor çıktıları İngilizcedir.
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.
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, çerçevelerin veritabanı katmanından istediği kanıtın büyük kısmını karşılar.
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 öne çıkan kontrollerdir.
| Kontrol | Beklenti | Üretilen kayıt |
|---|---|---|
| 8.2 Ayrıcalıklı erişim hakları |
Yükseltilmiş yetkiler sınırlı, tahsisli ve izlenebilir olmalı; kullanımı gözden geçirilmeli. | Yetki değişikliği kayıtları, izin bazlı yetkilendirme tablosu, yetkili işlemlerin talep kaydına bağlanması ve rol atama denetim kaydı. |
| 8.15 Kayıt tutma |
Faaliyet kayıtları üretilmeli, saklanmalı, korunmalı ve gözden geçirilmeli. | SQL Server ledger tablosunda, veritabanı motorunun güncelleme ve silmeyi reddettiği denetim kaydı, varsayılan olarak saatte bir alınan ve imza anahtarı ile dış depo klasörü tanımlı kurulumda imzalanıp kurumun değiştirilemez deposuna yazılan defter özeti ve Defter Durumu ekranı. Kaydın korunduğunu denetçi kendisi de doğrulayabilir: imzalı paketler ve kurumun ortamında geri yüklenmiş bir kopyada SQL Server ledger doğrulaması (nasıl). |
| 8.32 Değişiklik yönetimi |
Bilgi işleme tesislerindeki değişiklikler kontrollü bir prosedüre tabi olmalı. | Talep, kural değerlendirmesi, risk bandı, onay zinciri, çalıştırma kaydı ve metin özeti karşılaştırması; reddedilen talepler dahil. |
| 8.33 Test bilgisi |
Test verisi dikkatle seçilmeli, korunmalı ve kontrol edilmeli. | Ü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. |
Ayrıntı için: ISO 27001 ve veritabanı: dört kontrolün karşılığı.
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.
| Beklenti | Üretilen kayıt |
|---|---|
| BAI06 Değişiklikler kaydedilir, sınıflandırılır, etki ve riski değerlendirilir, yetkilendirilir, planlanır. | 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 aynı kural setinde her zaman aynı sonucu alır ve denetçiye tekrar üretilebilirlik gösterilebilir. |
| BAI06.03 Durumu izleyen ve raporlayan bir sistem bulunur; reddedilen değişiklikler de belgelenir. | 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. |
| 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). | Acil kayıt gerekçesiyle açılır, olay numarası kurum ayarıyla zorunlu tutulabilir 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. |
| ITIL 4 değişiklik yetkilisi bir kişi, ekip veya otomatik mekanizma olabilir; yetki riske göre dağıtılmalıdır. | Onay politikaları risk bandına göre tanımlanabilir: düşük bant tek onayla ya da önceden yetkilendirmeyle, yüksek bant çok kişili onay ve gerekçeyle geçecek şekilde kurulur. Kurul yalnız gerçekten değerlendirme gerektiren işi görür. |
| MEA İç kontrolün ve dış gerekliliklere uyumun sürekli izlenmesi. | Kontrol istisnaları panoda gün içinde görülür; otuz dört hazır rapor beş grupta düzenli çalıştırılabilir. Kanıtın yılda bir kez elle toplanması gerekmez. |
Ayrıntı için: COBIT BAI06 ve ITIL 4: veritabanı katmanındaki beş kopma noktası.
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.
| İlke | Üretilen kayıt |
|---|---|
| İşleme faaliyetinin kaydı | Üretimden veri çeken her talep: kim istedi, hangi gerekçeyle, hangi sunucudan, hangi kolonlar, sonucu kim indirdi ve neden. |
| Veri minimizasyonu | Hassas kolonlar varsayılan olarak maskelenir. Maskesiz erişim ayrı bir karardır, gerekçe ve ek onay gerektirir; kurum maskesiz kolon isteğini kurum genelinde kapatabilir. |
| Veri güvenliği tedbirleri | Sonuç şifreli paketle teslim edilir, paket parolası e-postayla gönderilmez, erişim izleri yalnız ekleme yapılabilen denetim kaydında tutulur. Ayrıntı: güvenlik mimarisi. |
| Veri işleyenle müşterek sorumluluk | 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. |
Ayrıntı için: KVKK denetimine veritabanı tarafında hazırlık ve test ortamında gerçek veri.
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 kanıtı tek bir dosya olarak alınır.
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. Paylaşılan hesap istisna olmalı ve gerekçesi yazılı olmalıdır. Bağlantının paylaşılan bir hesapla kurulduğu yerde, işlemi başlatan kişinin ayrıca kaydedilmesi atıfı korur; standardın benzersiz kimlik beklentisinin yerine geçmez, onu tamamlar.
Örnek denetim dosyasını kendi bilgisayarınızda doğrulayın ya da kendi kontrol listenizi birlikte üzerinden geçelim.