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 10 → 11

Güncelleme

İki yeni ders: kurulumu müşteriyle planlamak (kurulum aracı komutları, kurulum kodu ya da çevrimdışı paket, PoC ya da production, müşterinin hazırladıkları) ile gruplar, oturum açma politikaları ve harici kimlik sağlayıcılar. Bilgi kontrolüne üç yeni soru eklendi. Yeni derslere diyagramlar eklendi.

2 ders güncellendisüre

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

Süre 23 dakikadan 24 dakikaya değişti.

Kurulumu müşteriyle planlamak

Kurulum günü, sorular bir hafta önce sorulmuşsa iyi geçer. Bu ders, kimse sunucuya dokunmadan önce bir iş ortağının müşteriyle birlikte üzerinden geçtiği kontrol listesidir. ### Kurulum aracı nedir `monofor` tek bir Linux ikili dosyasıdır. Müşterinin sunucusunu hazırlar ve Monosign'ı, doğrulanmış tek bir YAML dosyasından Docker Swarm stack'leri olarak dağıtır. Dört komutu vardır: | Komut | Ne yapar | | --- | --- | | `monofor check` | Sunucuyu ve çevresini denetler. Hiçbir şeyi değiştirmez. | | `monofor install` | Monosign'ı dağıtır. | | `monofor status` | Kurulumun sağlık durumunu gösterir. Yalnızca okur. | | `monofor cert install` | Zaten kurulmuş bir sisteme sertifikayı ve anahtarını yükler. | Önce `check` komutunu çalıştırın ve bildirdiklerini düzeltin. Sunucunun hazır olduğunu söylediğinde `install` komutunu çalıştırın. ### Başlamanın iki yolu - **Kurulum koduyla.** v2026.10'dan beri olağan başlangıç budur: `monofor install --code <CODE>`. Kod Monofor'daki muhatabınızdan gelir ve o kurulumun ayarlarını taşır. `monofor check --code <CODE>`, kodu harcamadan sunucuyu sınar. - **Çevrimdışı paketle.** İnternet erişimi olmayan, yalıtılmış bir ağdaki sunucu için: `monofor install --offline`. Nasıl başladığınızın veritabanıyla ilgisi yoktur. Onu deploy type belirler. ### PoC mi, production mı | `deployType` | Veritabanı | Ne için kullanılır | | --- | --- | --- | | `poc` | Kurulum aracının kendisinin çalıştırdığı bir PostgreSQL konteyneri | Denemeler ve lablar | | `production` | Harici bir PostgreSQL ya da Microsoft SQL Server veritabanı. Kurulum aracı veritabanı konteyneri çalıştırmaz. | Gerçek müşteriler | ### Müşterinin hazırlaması gerekenler Kurulum aracı şu üç şeyi denetler ama kendisi yapmaz: - Monosign host adları için **DNS kayıtları**. - Kullanıcılar, sunucu ve veritabanı arasındaki **güvenlik duvarı portları**. - Production kurulumunun **harici veritabanı**: oluşturulmuş, boş ve sunucudan erişilebilir. Araç ayrıca yalnızca Monosign'ı dağıtır. Müşteri üçünü birden satın almış olsa bile Monopam ve Monosync ayrı kurulur. ::diagram msgs-install-plan ### Örnek bir plan Bir iş ortağı bir hastaneye Monosign kuruyor. Sunucunun internet erişimi yok ve hastanenin veritabanı ekibi Microsoft SQL Server işletiyor. İş ortağının bir hafta önceden gönderdiği plan: 1. Deploy type `production`; veritabanı ekibinin hazırladığı boş bir SQL Server veritabanıyla. 2. Host adları için ağ ekibinden istenen DNS kayıtları. 3. Sunucuya kopyalanan çevrimdışı paket. 4. Sunucunun hazır olduğunu bildirene kadar `monofor check --offline`, ardından `monofor install --offline`. > İpucu: DNS adlarının, portların ve veritabanı gereksinimlerinin listesini müşteriye kurulum gününden epey önce gönderin. Kurulum aracı eksik bir DNS kaydını ya da yerinde olmayan bir veritabanını düzeltemez; yalnızca size söyleyebilir.

Gruplar, oturum açma politikaları ve harici kimlik sağlayıcılar

İlk uygulama çalıştıktan hemen sonra, neredeyse her ilk projede üç soru gündeme gelir: kim hangi gruba ait, bir oturum açma ne zaman daha fazla kanıt istemeli ve insanlar başka bir yerde zaten sahip oldukları hesapla oturum açabilir mi? ### Gruplar ve bir uygulamayı kimin aldığı Gruplar Directory → `Groups` altındadır. Üyeler iki yoldan biriyle eklenir: - **Elle**: kullanıcının `Groups` sekmesinde `Assign New Group` ile. - **Kuralla**: Workflows → `Automation` altında, `Department` eşittir `Sales` gibi bir koşulu ve `Assign group(s)` eylemi olan bir kuralla. Kural sonradan işe alınanları da kapsar. `Remove access if rule no longer matches` açıkken, biri başka bir departmana geçtiğinde grubu geri alır. Bir grup kendi kendini doldurmaz: hiçbir grup türü kendi üyelik koşulunu taşımaz. Müşteri "Sales'teki herkesin olduğu bir grup" istediğinde yanıt, bir grup ve bir Automation kuralıdır. İnsanları bir gruba koymak onlara bir uygulamayı da açmaz. Bir uygulamayı açan şey **atamadır**: uygulamanın `Assignments` sekmesinde `Assign a User` ya da bir Automation kuralında `Assign application(s)` eylemi. | Müşteri şunu söyler | Siz şunu yapılandırırsınız | | --- | --- | | "Sales'teki herkes bu gruba ait" | `Assign group(s)` içeren bir Automation kuralı | | "Sales'teki herkes CRM'i alır" | `Assign application(s)` içeren bir Automation kuralı | | "Bu üç kişi yeni uygulamayı deneyecek" | Uygulamada `Assign a User` | ### Daha fazla kanıtı yalnızca gereken kişilerden istemek Security → `Policies` altındaki `Authentication` türünde bir politikanın iki parçası vardır. `Scope`, politikanın kime uygulanacağını söyler: kullanıcıyla ilgili koşullardan kurulan bir kuraldır, örneğin bir gruba üyelik. `Actions` sekmesindeki akış ise oturum açmanın ne içermesi gerektiğini söyler, örneğin paroladan sonra ikinci bir faktör. Daha fazlasını yalnızca bir koşul eşleştiğinde istemek **koşullu erişim** demektir ve Monosign'da bunu burada yapılandırırsınız. Her politikanın ayrıca 1 ile 10 arasında bir `Priority` değeri, isteğe bağlı `Start Date` ve `End Date` alanları ve bir `Enabled` anahtarı vardır; böylece bir politikayı bugün hazırlayıp gelecek pazartesi yürürlüğe girmesini sağlayabilirsiniz. Örnek: bir müşteri ikinci faktörü tüm şirketten önce finans ekibi için istiyor. Tek bir `Authentication` politikası oluşturur, kapsamını `Finance` grubuyla sınırlar ve akışına ikinci faktör adımı eklersiniz. Diğer herkes eskisi gibi oturum açar. Yaygınlaştırmayı sonradan genişletmek, politikayı yeniden kurmak değil, kapsamı genişletmek demektir. ::diagram msgs-policy-scope ### Başka bir yerdeki hesapla oturum açmak Identity → `Providers` altında, Monosign'ın oturum açma için güvendiği **harici kimlik sağlayıcıları** tanımlarsınız. Bir müşterinin çalışanları zaten Microsoft Entra ile oturum açıyorsa Entra böyle bir sağlayıcı olur: kullanıcı Entra'ya gönderilir, orada oturum açar ve Monosign'a doğrulanmış olarak döner. Sağlayıcılar SAML 2.0, OpenID Connect ya da WS-Federation üzerinden bağlanır; Microsoft Entra, Google ve Okta gibi yaygın olanlar için şablonlar vardır. Yönlendirme kuralları kimin nereye gönderileceğini belirler; örneğin e-posta adresi iş ortağının alan adıyla biten herkes. Dönüşte Monosign kişiyi mevcut bir kullanıcıyla eşleştirir. Henüz var olmayan bir kullanıcı, yalnızca o sağlayıcı için just-in-time provisioning açıksa oluşturulur. İki yönü birbirine karıştırmayın: | Durum | Kimlik sağlayıcı kim | | --- | --- | | CRM, Monosign kefil olduğu için insanları içeri alıyor | Monosign | | Monosign, Entra kefil olduğu için insanları içeri alıyor | Entra; Monosign ise güvenen taraftır | > İpucu: Herkesi etkileyen bir politikayı etkinleştirmeden önce bir yönetici hesabını kapsamının dışında tutun; böylece politikadaki bir hata tüm yöneticileri dışarıda bırakamaz.