Monosign denetim, raporlama ve sorun giderme
Neler değişti
Her içerik güncellemesi sürümlenir. Bir sürümü seçerek öncekiyle karşılaştırın.
Sürüm 3 → 4
Güncelleme5 ders güncellendi
İçerik güncellemesi. Kayıtlı öğrenciler bilgilendirildi.
Her ürün işlemi bir denetim satırı yazar. Reports → `Audit` bu satırları en yeniden eskiye listeler; nesne, işlemi yapan, denetim türü, uygulama ve zaman aralığı filtreleri vardır. Aynı liste, kullanıcı sayfasında `Audit` sekmesi olarak da görünür.
::shot aud-audit-list
### Sayfada neler yapabilirsiniz
- **`Details`** tek bir satırı verisiyle ve `Correlation Id` değeriyle açar; bu değer aynı isteğe ait satırları birbirine bağlar.
- **`Schedule`** bir denetim özeti postalar: seçtiğiniz türlerdeki denetim satırlarının listesi, anında, bir eşikte ya da zamana bağlı olarak gönderilir.
- Listenin **dosyaya dışa aktarımı yoktur**. Denetim satırları dosya olarak istendiğinde `Audit Events` veri kaynağı üzerinde bir Report Studio raporu oluşturun. Sonraki modül bunu anlatır.
### Destek rolü için izinler
Sayfayı açmak ve satırları okumak iki ayrı izindir. Sayfa rotası `System.Management.Report.Audit` ister. Liste `System.Management.User.AuditList` ister; v2026.10'dan itibaren tek bir satırdaki `Details` de aynı izni ister. v2026.09'a kadar oturum açmış her Management kullanıcısı bir satırı kimliğiyle açabiliyordu. Yükseltmeden sonra yalnızca tek satır okuyan özel bir destek rolü, `System.Management.User.AuditList` eklenene kadar HTTP 403 alır. Denetimleri listeleyen bir API aramayın: API tek bir satırı kimliğiyle okur ya da dış sistemler için satır yazar.
### Saklama
Denetim satırları, System → `Data Retention` altındaki `Audit` kuralı onları silene kadar kalır. Her kuralın `Enable` ve `Remove older than N days` alanları vardır. Silme kalıcıdır: önce arşivlenmez, sizin yerinize dışa aktarılmaz.
Bu yüzden iş sırasını müşteriyle kararlaştırın. Uyum ekibi kanıtı kuralın süresinden daha uzun saklamak zorundaysa önce dışa aktarımı kurun, örneğin `Audit Events` üzerinde zamanlanmış bir Report Studio raporu, kuralı ancak ondan sonra etkinleştirin.
::diagram aud-retention-order
> İpucu: Saklama süresini ve dışa aktarım zamanlamasını aynı devir belgesine yazın. Denetçi ikisini de soracaktır.
Atama listesi **bugün** kimin erişimi olduğunu gösterir. Oturumlar ve oturum açma denetimleri kimin **oturum açtığını** gösterir. Hiçbiri klasik denetim sorusunu yanıtlamaz: *geçmişteki belirli bir tarihte bu uygulamaya kimin erişimi vardı?* Bunun yeri Dashboard → `Timeline`, yani `Access Timeline` başlıklı sayfadır.
::diagram aud-three-questions
Zaman çizelgesi rollerin, izinlerin, grupların, uygulamaların ve kaynakların her verilişini ve geri alınışını, ayrıca profil değeri değişikliklerini olay olarak kaydeder. Her erişimin ne zaman başlayıp bittiğini bildiği için aynı veriyi birkaç görünümde sunar:
| Görünüm | Ne için |
| --- | --- |
| `Events` | Tarih aralığı, kullanıcı, kaynak, uygulama ya da olay türüne göre süzülmüş ham liste |
| `Timeline` | Verilişten geri alınışa kadar aralıklar olarak erişim |
| `Snapshot` | Tek bir andaki erişim durumu |
| `Compare` | İki tarih arasında eklenenler ve kaldırılanlar |
| `Unused` | Kimsenin oturum açmadığı uygulama erişimleri |
| `Pinned` | İnceleme notuyla sabitlediğiniz olaylar |
`Export CSV` o anki görünümü en çok 100.000 satır olacak şekilde dosyaya yazar.
::shot aud-access-timeline
### Denetçiye söylenecek sınırlar
- Sayfa v2026.07'de geldi. `Build history` olayları mevcut veriden yeniden kurar, böylece daha eski erişimler gösterilebilir; ancak yeniden kurulan satırlar ve v2026.09'dan önce yazılan olaylar işlemi yapan olarak `System` gösterir.
- **v2026.09'dan önce yapılan grup çıkarmaları kaydedilmedi ve yeniden kurulamaz.** `Build history` bunları geri getirmez. Aradığınız kanıt böyle bir çıkarmaysa bunu açıkça söyleyin ve denetim kaydı gibi başka bir kanıt arayın.
- `Unused` için yalnızca uygulama oturum açmaları sayılır. Rol ve izin kullanımı izlenmez.
- Hiçbir veri saklama kuralı zaman çizelgesi olaylarını silmez; yani bir boşluk asla temizlik sonucu değildir.
- Sayfayı açabilen herkes tenant'ın tamamını görür.
> İpucu: Belirli bir ana dair soruda önce o tarih için `Snapshot` açın, sonra o günden bugüne neyin değiştiğini göstermek için `Compare` kullanın.
Reports → `Report Studio` kendi raporlarınızı oluşturduğunuz yerdir. Bir rapor tek bir **veri kaynağını** okur: `Audit Events` gibi hazır kaynaklardan biri ya da müşterinin `Custom Data Sources` altında kurduğu bir veri kaynağı. SQL yazamazsınız ve raporlar genel API üzerinden sunulmaz.
::shot aud-report-studio
### İki tür rapor
- **`Report Builder`**: sütunları, filtreleri, gruplaması, toplamları ve sıralaması olan tek bir tablo; `Table`, `Bar`, `Line` ya da `Pie` olarak gösterilir.
- **`Composite Report`**: başlık, metin, tablo, grafik ve KPI özeti gibi bloklardan oluşan bir belge. Yönetim özeti için uygundur; örneğin MFA kapsamı ile riskli kullanıcılar yan yana.
Sistem şablonları çalıştırılmaya hazırdır ve düzenlenemez.
### Çalıştırma
Bir çalıştırma `CSV`, `Excel`, `PDF` ya da `HTML` üretir. Çalıştırmalar kuyruğa alınır ve arka planda işlenir; dosyalar `Report Studio` araç çubuğundaki `Run History` düğmesiyle açılan sayfada görünür. Tüm raporları yönetme izniniz yoksa yalnızca kendi çalıştırmalarınızı görürsünüz. Dosyalar süresiz tutulmaz: süresi dolanlar silinir.
### Kişisel veri varsayılan olarak maskelenir
Kişisel veri içeren sütunlar maskelenir. Oluşturucuda `Unmasked PII` anahtarı vardır ve raporla birlikte kaydedilir. Bu, her çalıştırmanın maskesiz olduğu anlamına gelmez:
- Bir çalıştırmanın maskesiz olup olmayacağına **çalıştırma kuyruğa alınırken, onu çalıştıran kişinin iznine göre** karar verilir.
- Maskesiz dışa aktarım izni olmayan kullanıcı için kayıtlı anahtar dikkate alınmaz ve çalıştırması maskeli olur.
- Her maskesiz çalıştırma `REPORT_EXPORT_UNMASKED` denetimini yazar.
Dolayısıyla aynı rapor yazarına tam adları, kıdemsiz bir analiste maskeli adları gösterebilir. Bu bir hata değil, beklenen davranıştır. İzni ihtiyacı olan birkaç kişiye verin ve bu denetim türünü gözden geçirin.
::diagram aud-unmasked-run
> İpucu: Raporu kişilerle değil rollerle paylaşın; rapor gerektirmiyorsa maskesiz izni bu rollere koymayın.
Her pazartesi aynı özeti isteyen bir yöneticinin Management'ta oturum açması gerekmemeli, kimse de raporu elle dışa aktarmamalı. Rapor zamanlaması bir Report Studio raporunu takvime göre çalıştırır ve sonucu teslim eder. Kenar menüde zamanlamalar için bir madde yoktur: raporu `Report Studio` içinde açıp `Schedule (admin)` seçin ya da araç çubuğundaki `More` → `Schedules` yolunu kullanın.
::shot aud-report-schedules
### Bir zamanlama neleri tutar
- **Yineleme**: günlük, haftalık ya da aylık, zamanlamanın kendi saat diliminde bir saatte. Ham cron ifadesi yoktur.
- **Biçim**: çalıştırma biçimlerinden biri, örneğin `PDF`.
- **Alıcılar**: sahibi ve ek adresler.
- **Teslim**: `Download link` ya da `Email attachment`.
- İsteğe bağlı olarak, çalıştırma tamamlanınca çağrılan bir **webhook**.
### Teslim biçimini seçmek
| Teslim | Alıcıya giden | Kimler için uygun |
| --- | --- | --- |
| `Download link` | Management oturumu gerektiren bir bağlantı | Hesabı ve çalıştırmaya hakkı olanlar |
| `Email attachment` | Toplamı 10 MB ya da daha azsa dosyalar postanın içinde, aksi hâlde bağlantılar | Posta kutusu olan herkes, hesabı olmayan dış denetçi dahil |
| Webhook | Üst veri ve kimlik doğrulamalı URL'ler, asla rapor verisi değil | Biten çalıştırmaya tepki veren sistemler |
Sık yapılan hata, yalnızca e-posta adresi olan bir alıcı için `Download link` seçmektir. O kişi oturum açamaz ve dosyayı hiç göremez. Zamanlamayı `Email attachment` olarak değiştirin ve raporu sınırın altında kalacak kadar küçük tutun.
### Abonelikler
Report Studio erişimi olan bir kullanıcı bir rapora kendisi için `Subscribe` da yapabilir. Abonelik her zaman bağlantı gönderir, her zaman maskelidir ve hesap gerektirir; bu yüzden dışarıdaki okuyuculara ulaşmanın yolu değildir.
### Bir zamanlama ne zaman durur
Zamanlama art arda 5 başarısızlıktan sonra, sahibi devre dışı bırakıldığında ya da rapor silindiğinde kendini duraklatır ve nedenini saklar. Biri pazartesi raporunun gelmediğini söylediğinde `More` → `Schedules` sayfasına bakın.
> İpucu: Zamanlamalara kalıcı bir sahip verin, örneğin bir servis yöneticisi; onları kuran danışmanı değil.
Bir hesabın ele geçirilmiş olabileceği durumda üç araç önemlidir: oturum listesi, parola ve kullanıcının o an ne yaptığını gösteren canlı görünüm. Her birinin, olaydan önce bilmeniz gereken bir davranışı vardır.
### Bir oturumu bulmak
Management → `Sessions`, `Active Sessions` listesini gösterir. Kullanıcı filtresi olmadan liste yalnızca **son 30 dakikada başlamış ya da güncellenmiş** oturumları gösterir. Hâlâ geçerli olup daha uzun süredir hareketsiz kalan bir oturum bu sayfada yoktur.
Aynı oturum kullanıcının kendi sayfasından görünür: Users → kullanıcı → `Sessions` → `Active`; çünkü bu yol kullanıcıya göre süzer. Oraya bakmadan bir kullanıcının oturumu olmadığı sonucuna varmayın. Oturumlar tek bir ortak tabloda durur; hangi veri merkezine bağlı olduğunuz fark etmez.
İki yerden de tek bir oturumu, bir kullanıcının bir uygulamadaki tüm oturumlarını ya da hepsini kapatabilirsiniz. Kapatma bir oturum kapatma denetimi yazar ve oturumun belirteçlerini iptal eder.
::shot aud-active-sessions
### Parola değişikliği oturumları sonlandırmaz
Yeni bir parola, ister kullanıcı değiştirsin, ister yönetici belirlesin, ister sıfırlamadan gelsin, önceden açılmış oturumları **sonlandırmaz**. Oturumlar süreleri dolana ya da biri onları sonlandırana kadar geçerli kalır.
Ele geçirilme şüphesinde ikisini de yapın: parolayı değiştirin **ve** kullanıcının oturumlarını sonlandırın. Yalnızca parolayı sıfırlarsanız denetim kaydı saldırganın oturumundan gelen hareketleri göstermeye devam edebilir.
::diagram aud-incident-steps
v2026.10'dan itibaren parola politikasında bununla ilgili iki anahtar vardır: `End Active Sessions When Locked After Failed Attempts` (varsayılan kapalı) ve `End Active Sessions When an Administrator Locks the Account` (varsayılan açık). Bunlar parola değişikliğiyle değil, kilitlemeyle ilgilidir.
### Live Tracking
Directory → Users → `Live Tracking` tek bir kullanıcı seçip o kullanıcının denetim olaylarını gerçek zamanlı izlemenizi sağlar. İki sınırı vardır:
- **Sayfa hiçbir şey saklamaz.** Yalnızca açıkken oluşan olayları gösterir. Geçmiş hareketler denetim kaydındadır.
- **Başka bir veri merkezinde oluşan olaylar hiç görünmez.** İki veri merkezli bir kurulumda, hiçbir şey olmadığı sonucuna varmadan önce kullanıcının hangisine ulaştığını öğrenin ve Management'ı orada açın.
> İpucu: Destek görüşmesinde önce izlemeyi başlatın, sonra kullanıcıdan işlemi tekrarlamasını isteyin.