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 8 → 9

Güncelleme

Onay tasarımı üzerine yeni modül: onayın nerede yapılandırıldığı, pencerenin ve onaylayan sayısının nasıl işlediği, tedarikçiler, harici kullanıcılar ve betik çalıştırmaları için onaylar. Modülde artık diyagramlar ve sonunda önce neye bakılacağını gösteren bir liste var.

2 ders güncellendisüre

İçerik güncellemesi. Kayıtlı öğrenciler bilgilendirildi.

Süre 20 dakikadan 21 dakikaya değişti.

Onay nerede yapılandırılır ve pencere nasıl hesaplanır

"Buna bir onay koyun" demek Monopam'de üç farklı ayar anlamına gelebilir. Farklı yerlerde dururlar ve farklı davranırlar; bu yüzden tasarımın ilk adımı hangisine ihtiyacınız olduğunu adlandırmaktır. | Şundan önce onay istiyorsunuz | Yapılandırılacak yer | Talep edenin aldığı pencere | | --- | --- | --- | | Biri bir kaynağa bağlanmadan önce | Kaynağın ayarlarındaki `Advanced` sekmesinde, onaylayanlarıyla birlikte `Approvement` | Düz bağlantı talebi şu andan itibaren sabit 8 saat alır ve bu süre kaynakta değiştirilemez. ~~Bağlantı penceresindeki~~Farklı bir pencere, bağlantı penceresindeki `Scheduled` seçeneği üzerinden istenir; seçenek yalnızca kaynak onay gerektirdiğinde ~~görünen~~görünür. Talep bu durumda `Scheduled Connection` ~~seçeneği talep edenin bunun yerine seçtiği bir pencereyi istemesini sağlar~~türündedir ve ayrıntısında `Requested Access Period` gösterilir | | Biri korumalı bir vault alanını görüntülemeden önce | Vault Access Policy iş akışında `Required` olarak ayarlanan onay | Talebin istediği süre | | Belirli bir kabuk komutu çalışmadan önce | Davranışı `Requires Approval` olan bir ayrıcalıklı komut kuralı | Tam olarak o komut satırının 60 dakika içinde tek bir çalıştırması | ::diagram pam-approval-places Tek bir sunucuda onaylı iki saate ihtiyacı olan bir yüklenici, bu nedenle `Approvement` açık bir kaynak ve o iki saat için bir `Scheduled` talebi demektir. Pencere kapandığında erişim kendiliğinden biter. Kimsenin kaldırmayı hatırlaması gerekmez. ### Geç onay pencereye ne yapar Politika onayının bir süre türü vardır. Onaylayan, talep edenin umduğundan yavaş kaldığında ne olacağını bu belirler. | Tür | Kural | 14:00 ile 16:00 için talep, 15:15'te onay | | --- | --- | --- | | `OnRequest` | Pencere onay anına kayar ve uzunluğunu korur | 15:15 ile 17:15 | | `OnSchedule` | Pencere talep edenin koyduğu yerde kalır | 15:15 ile 16:00. Gecikme kaybedilir | Zamanın kendisi önemliyse, örneğin iş birimiyle kararlaştırılmış bir değişiklik penceresinde `OnSchedule` kullanın. Kişinin yalnızca belirli bir çalışma süresine ihtiyacı varsa `OnRequest` kullanın. ### Kaç onaylayan Bir Approval öğesi onaylayanları adlandırır ve kaçının gerektiğini söyler. | Ayar | Anlamı | | --- | --- | | `RequireAll` | Adı geçen her onaylayan onaylamalıdır | | `MinimumApprovalCount` | Adı geçenlerden herhangi N kişi yeterlidir | | `RequireBySelf` | Talep eden onaylayan olarak eklenir ve gereken sayı bir artar | `MinimumApprovalCount` 3 iken altı kişinin adlandırılması, altıdan herhangi üçü demektir. `RequireBySelf` eklerseniz talep dört onay ister: talep edenin kendi onayı ve üç kişi daha. `RequireBySelf`, bağımsız onaylayan sayısını azaltmanın yolu olarak değil, bilinçli bir "bunu istediğimi onaylıyorum" adımı olarak yararlıdır. Onaylayan adlandırmayan talep kaybolmaz. `No approver` rozetini gösterir ve bir süper yönetici karar verebilir. Yine de bu rozeti düzeltilecek bir yapılandırma hatası sayın. ### Komut için Deny mi onay mı? Her iki davranış da komut satırını kabuğa ulaşmadan durdurur. Komutun herhangi bir zaman meşru olup olmadığını sorarak seçin. - Aracılı oturumdan asla meşru değil: `Deny`. - Meşru ama nadir ve yüksek etkili, örneğin bir üretim veritabanı ana bilgisayarını yeniden başlatmak: `Requires Approval`. Her çalıştırmaya ikinci bir kişi tanıklık eder. - Rutin: hiçbiri. Her onay bir onaylayanın dikkatine mal olur ve günde elli kez sorulan onaylayanlar okumayı bırakır. ### Sürekli ayrıcalığı gerçekte ne azaltır Kayıt ve rotasyon değerlidir ama onlarla erişim yine her zaman vardır. Ayrıcalık ancak varsayılan olarak yokken "sürekli" olmaktan çıkar: penceresi kapandığında kendiliğinden biten bir izin ya da her seferinde kişi ile sır arasında duran bir onay adımı. Sürekli ayrıcalığı hangi kontrollerin azalttığı sorulduğunda adlandırılacak iki tür bunlardır. > İpucu: talep eden, onaylanan pencerenin istediğinden kısa olduğundan yakınıyorsa her şeyden önce süre türüne bakın. `OnSchedule` ile geç gelen onay, tasarım gereği pencereden yer.

Tedarikçiler, harici kullanıcılar ve betik çalıştırmaları için onaylar

Tam zamanında erişim değerini en çok üçüncü taraflarda gösterir. Bir bakım tedarikçisinden gelen yüklenici Deniz'i, erişiminin tüm ömrü boyunca izleyelim. ::diagram pam-vendor-access ### 1. Davetin kendisi bir taleptir Bir süper yönetici `Invite External User` kullanır. Bu bir hesap oluşturmaz. Bir onay talebi oluşturur. - Onaylayanlar, **talep eden dışındaki** süper yöneticilerdir. Yalnızca tek bir süper yönetici varsa o kişi kendi talebini onaylar. - E-posta adresi başına bir açık davet olabilir. İlki beklerken aynı adrese ikinci davet reddedilir. - Onaydan sonra Deniz bir kayıt e-postası alır ve bitiş tarihi olan bir harici kullanıcı olur. Onaylanmış davet `Requests` üzerinden geri alınamaz, çünkü e-posta çoktan gitmiştir. Onay hataysa erişimi hesabın yaşadığı yerde bitirin: `Users` sayfasında `Deactivate` ya da sürenin dolmasını bekleyin. ### 2. Süre sonu ve `Extend Access` Erişim süresi bittiğinde hesap devre dışı kalır. `Extend Access` yeni bir bitiş tarihi verir ve **süre dolduğu için** devre dışı kalmış hesabı yeniden etkinleştirir. Bir yöneticinin bilerek devre dışı bıraktığı ve süresi dolmamış hesabı yeniden etkinleştirmez. Yeni tarih, bilinçli bir kararı asla geçersiz kılmaz. ### 3. Tedarikçinin korkulukları Deniz'in hesabı bir tedarikçi kuruluşuna aittir ve tedarikçi, tüm kullanıcılarına uygulanan ayarlar taşır. | Tedarikçi ayarı | Etki | Dikkat | | --- | --- | --- | | `Require approval for every connection (JIT)` | Tedarikçi kullanıcılarının her bağlantısı, her kaynakta onay ister | Kendi onay akışı olmayan kaynakta talep her süper yöneticiye gönderilir. Bunu beklediklerinden emin olun | | `Allowed Sites` | Tedarikçi kullanıcıları yalnızca seçilen sitelerdeki kaynaklara bağlanabilir | Sitesi olmayan kaynak **dışarıda** sayılır. Kullanıcı geçerli bir politikayla bile "This resource's site is not allowed for your vendor organization." görür | İkinci durumun çözümü tedarikçiyi gevşetmek değil, kaynağı doğru siteye atamaktır. Politika, kullanıcının neye ulaşabileceğine karar verir. `Allowed Sites` ise oturum oluşturulurken ve bağlanırken yeniden yapılan ayrı bir denetimdir. ### 4. Çok sayıda sunucuda betikler Script Library'de isteğe bağlı iki kapı vardır. **Yayın onayı**, bir betiğin yeni sürümünün çalışabilmesi için önce bir onaylayana ihtiyaç duyması demektir. **Çalıştırma onayı**, bir çalıştırma talebinin onaylayan gerektirmesi demektir. Tek bir çalıştırma talebi birçok kaynağı hedefleyebilir ve sunucu başına değil, tüm toplu iş için bir kez onaylanır. Bu yüzden onaylayanlar hedef listesini betik kadar dikkatle okumalıdır. ### 5. Erişim onaylanandan erken bittiğinde Bir kullanıcı onaylı bir iznin bitiş zamanından önce çalışmayı bıraktığını bildirirse iki olağan neden vardır. | Denetim | Anlamı | | --- | --- | | Talebin durumu `Cancelled` | Biri izni iptal etmiştir | | İzin veritabanı sorguları içindir ve talep iptal edilmemiştir | Böyle bir izin kullanım sınırı taşıyabilir. Kullanılan sayıyı sınırla karşılaştırın: izin verilen çalıştırmalar tükendiğinde saat dolmasa da izin biter | ### Tedarikçi kullanıcısı bağlanamıyorsa önce neye bakılır 1. Hesap etkin mi? Süresi dolan hesap devre dışı kalır ve `Extend Access` onu geri getirir. Bilerek devre dışı bırakılan hesap devre dışı kalır. 2. Kaynak, tedarikçinin `Allowed Sites` listesindeki sitelerden birinde mi? Sitesi olmayan kaynak dışarıda sayılır. 3. Bekleyen bir talep var mı? `Require approval for every connection (JIT)` ile her bağlantı onay gerektirir; kendi onay akışı olmayan kaynakta talep süper yöneticileri bekler.