NinjaOne ile uyumlu Policy oluşturmak çok kolaydır ve uç noktaları kolay ve verimli bir şekilde yönetmenize olanak tanır. Bu kılavuzda, NinjaOne konsolunda Policylerin nasıl çalıştığına dair gerçek dünyadan örneklerle temel policy kavramlarını ele alacağız.
NinjaOne’daki Policyler nelerdir?
Policyler NinjaOne’ın merkezi cihaz yönetimi ve otomasyon motorudur. Belirlediğiniz policyler NinjaOne’un cihazlarınızı nasıl yöneteceğini belirleyecektir.
Bir policy neleri içerir?
Policyler NinjaOne’a uç noktalarınızın günlük olarak nasıl yönetilmesini istediğinizi söylüyorsunuz. Ninja, policyler sağladığı eylemleri ilgili tüm cihazlarda sürekli olarak otomatik olarak yürütür. policyler uç nokta izleme kurallarını, otomasyon kurallarını, ayrıntılı yama yönetimi seçeneklerini, güvenlik çözümü tercihlerini ve veri yedekleme ve saklamayı içerir.
NinjaOne Policyleri nasıl farklı şekilde ele alıyor?
NinjaOne ile, size her cihazın nasıl yönetildiğine dair daha fazla görünürlük ve anlayış sağlayan basit bir “cihaz başına bir policy” kuralı kullanıyoruz. Diğer çözümlerde, tek bir uç noktaya uygulanan birden fazla policyler olabilir, bu da yönetimi daha zor ve kafa karıştırıcı hale getirebilir. Bu tek policy yöntemini kullanarak daha sezgisel ve verimli bir deneyim elde edersiniz.
Policy Devri
Ninja, cihazların daha standart ve verimli yönetimine olanak tanıyan policy devralma adı verilen bir kavramı içerir. Oluşturulduktan sonra, yeni bir policy (alt), iki policyi birbirine bağlayan başka bir policy (üst) devralmak üzere atanabilir; böylece ana policye yapılan herhangi bir değişiklik, alt policye yansıtılır. Bu ilişki süreklidir ve tek yönlüdür; özelleştirme ihtiyaçlarınızı standardizasyon ve verimli yönetimle dengelemenize olanak tanır. Aşağıdakiler Ninja’da tanımlı policy durumları olmasa da policyler şu şekilde kategorize edilebilir:
• Bağımsız policyler; ebeveyn veya çocuk policy.
• Kök policyler, üst policyler olmayan en üst düzey policylerdir. Bu policyler, altlarında bulunan tüm policyler için genel kuralları tanımlar. Çalışmalarınızın çoğu kök seviyesinde yapılacaktır. Yeni özelliklerinizi ayarladıktan sonra, hepsini kapatacak ve ardından bu kuralları üst veya alt düzeyde açacak veya geçersiz kılacaksınız. Kök policyler her koşulu, zamanlanmış komut dosyasını, yama yönetimi policylerini, yedekleme planını vb. içerecektir. Birden fazla cihaz grubu için geçerli olan veya kurulumu karmaşık olan her şey genellikle kök policy düzeyinde yer alacaktır.
• Ana policyler, farklı policyler düzeyleri arasındaki kararları koordine eden orta düzey policylerdir. Üst policyler kullanarak, üst düzeyde oluşturulan özellikleri etkinleştirebilir veya devre dışı bırakabilirsiniz. Orta yönetim olarak, bu policyler sadece alt düzeyde ek verimlilik sağlamak için vardır.
• Alt policyler cihaza özgü özellikleri etkinleştirir. Tek bir istemciye veya cihaz grubuna özel olan, belirli kimlik bilgileri gerektiren veya yalnızca küçük bir rutin grubu için geçerli olan herhangi bir şey genellikle alt policyler düzeyinde yer alacaktır.
Bu policyler nasıl etkileşime giriyor?
Solda NinjaOne’da bir dizi policyler nasıl görünebileceğinin bir örneği var. Her cihazın birden fazla, basitleştirilmiş operasyon yerine tek bir policy altında yaşadığını unutmayın. policyler arasındaki etkileşimler söz konusu olduğunda aşağıdakiler geçerlidir:
• Bir ana veya kök policy yapılan herhangi bir değişiklik aşağıdakilere kadar inecektir: aşağıda listelenen chield policyler
• Alt policyler, üst policylerde alınan kararları geçersiz kılabilir veya ek özellikler ekleyebilir
• Alt policyler değişiklik yaptığınızda üst policyler değişmez
• Kalıtım, Kök’ten Alt’a kadar birden fazla seviyeye kadar birikebilir
Hiyerarşiler Policy oluşturmayı nasıl etkiler?
policylerinizi oluştururken, altında bir alt policy oluşturmadan önce üst policy oluşturulması gerektiğine dikkat etmeniz önemlidir. Herhangi bir yeni policy oluşturduğunuzda, daha sonra üst policy olacak başka bir ilkeye atama seçeneğiniz vardır. Bir policy oluşturup daha sonra bunu devralınan bir policy olarak atayamazsınız. Bir üst policye atamak isterseniz, bunu yayınlamadan önce yapmanız gerekir. Yayınladıktan sonra, yeni bir üst öğeye atama olanağınız olmayacaktır. policyleri kopyalama seçeneğiniz vardır, ancak bu kesinlikle bir kopyadır ve kopyalanan orijinal policy tarafından değiştirilen herhangi bir özelliği devralmaz.
Policy Hiyerarşileri
Artık policylerin yönetiminden neler bekleyebileceğinize dair bir temel düzey oluşturduğumuza göre, kullanım örneklerini ve faydalarını karşılaştırmak için üç farklı politika yapısına göz atalım:
Siloed Policyler
Silolanmış policyler, Ninja’da cihaz yönetimi için nadiren en iyi seçimdir; çünkü her policy birbiriyle ilgisizdir ve konsolidasyon veya policyler arası verimlilik yoktur. Her cihaz rolü için bir ana policye sahip olmanın hemen hemen her zaman elde edilecek bazı verimlilikleri vardır. Bu aynı zamanda, yama programlarında veya yedekleme kurallarında yapılan değişiklikler gibi yapılması gereken tüm iş akışı güncellemelerinin, kapsamlı bir ana policy avantajından yararlanmak yerine ilgili tüm policyler arasında manuel olarak kopyalanması gerektiği anlamına gelir. Bu tür bir yapı çok basit ortamlarda işe yarayabilir ancak Ninja’ya daha fazla cihaz eklemeye başladıkça ölçek verimliliğinden yoksun kalır. Silolanmış policyler aşağıdaki durumlarda etkili olabilir:
• Bir rol içindeki tüm cihazlarınız aynı şekilde yönetilir cihazlar / cihaz grupları arasında değişiklik olmadan
• Her cihaz grubu o kadar farklı yönetiliyor ki, işi bir ana policyler birleştirmenin verimlilik açısından hiçbir faydası yoktur.
Global Parent
Küresel ana yapılar, silolanmış policylerden bir üst düzeydir; policy çalışmaları, her bir cihaz kümesini izole edilmiş alt policyler aracılığıyla yönetmek yerine küresel ana düzeyde birleştirilir. Bu hala oldukça düz bir hiyerarşidir ancak size biraz daha derinlik ve yönetilebilirlik sağlar. Bu yapı, esneklik ve standardizasyondan yararlanan ortamlar için en iyisidir. Ebeveyn ve alt yapıdan yararlanarak daha fazla verimlilik elde edebilirsiniz. Üst düzeyde yapılan çalışmalar otomatik olarak alt policylere kopyalanacaktır. Global ana policylerin mümkün olduğunca fazla çalışma yapmalı, ardından alt policy düzeyinde özelleştirmeler ve ayarlamalar yapmalısınız. Örneğin iş istasyonu yönetimi genellikle izleme, görev otomasyonu, AV ve yedekleme perspektifinden kolayca standartlaştırılır ve en yaygın olanı yama programlarındaki farklılıklardır. Bu, olgun müşterilerde gördüğümüz en yaygın politika yapısıdır ve çoğu durum için uygundur.
Çok Katmanlı
Çok katmanlı kurulumlar, üçü arasında en karmaşık yapı olacak ve kök, üst ve alt düzey policyler daha fazla karmaşıklık katacaktır. Bu yapı, karmaşık ancak oldukça yapılandırılmış ortamlarda inanılmaz derecede etkili olabilir, ancak aynı zamanda uygun şekilde kontrol edilmediği takdirde karmaşık ve yönetilmesi zor hale gelebilir. Birden fazla miras katmanına sahip olmak, cihaz yönetimi, cihaz gruplarına göre özelleştirme ve geniş ölçekte kişiselleştirme için temel bir standarda olanak tanır. Genel olarak, hedeflerinize ulaşmak için yapılandırmaları her zaman policy ağacında mümkün olduğunca yükseğe taşımak ve mümkün olduğunca az sayıda politikayla birleştirmek istersiniz. Bu policy yapısı en yaygın olarak birçok sunucuyu farklı amaçlarla yönettiğiniz sunucu yönetimi için veya istemciler arasında standartlaştırma yapmak isteyen MSP’ler için kullanılır.
Gerçek Dünya Örneği
Ninja platformuna daha fazla cihaz eklemeye başladığınızda, tek bir uyumlu platformda her yapı türünden yararlanan organizasyon yapınız şu şekilde görünebilir:
Politika Yönetim Stratejileri
policy yönetiminde ilerlerken ve policy yapınızı oluştururken veya güncellerken göz önünde bulundurmanız gereken birkaç husus vardır:
1. Önce planlayın, sonra oluşturun policylerinizi oluşturmadan veya güncellemeden önce, hiyerarşilerin işlevine karar verin. Her zaman büyüme için plan yapabileceğinizi ancak şimdilik sadece ihtiyaç duyulan katmanları kullanabileceğinizi unutmayın. Sorulması gereken sorular:
– Cihaza yönelik politikalar müşteri başına mı? Bağlı şirket başına mı? İşlevsel grup başına mı?
– Çok seviyeli bir hiyerarşiye ihtiyacınız var mı?
– Çok seviyeli bir yapı kullanıyorsanız, orta seviye policyler neye karşılık geliyor?
2. Konsolidasyon anahtardır Şimdi kök policyler yatırım yapma zamanı. Planlama aşamasında ne kadar çok iş yaparsanız, ileride o kadar az iş yapmanız gerekecektir. Genel olarak uygulanabilir değilse, genel üst düzeydeki özellikleri varsayılan olarak her zaman devre dışı bırakabilirsiniz. İşlevselliği etkinleştirmek için orta düzey veya cihaza yönelik policyleri kullanın ve yalnızca üst ve alt düzeylerde gerekli olanları etkinleştirin.
3. Mevcut policyleriniz varsa, mevcut policy grupları arasındaki farklılaşmaya gerçekten ihtiyacınız olup olmadığını düşünün. Bireysel yönetim yerine tek bir policyde birleştirmeye başlayın. Belirli cihazların istisnalara ihtiyacı varsa, bu istisnaları geçersiz kılmalar yerine policyler yapın. Yapınızdaki geçersiz kılmaların ve bağımsız policylerin sayısını en aza indirin, çünkü bu istisnalar genellikle ileride daha fazla baş ağrısına yol açacaktır
4. NinjaOne geriye dönük olarak bir üst policy atamanıza izin vermediğinden, ekstra bir üst policye sahip olmak asla zarar vermez.
