JEA Güvenliğiyle İlgili Dikkat Edilmesi Gerekenler

JEA, makinelerinizdeki kalıcı yönetici sayısını azaltarak güvenlik duruşunuzu geliştirmenize yardımcı olur. JEA, kullanıcıların sistemi yönetmesi için yeni bir giriş noktası oluşturmak üzere bir PowerShell oturum yapılandırması kullanır. Yönetim görevlerini gerçekleştirmek için makineye erişimi yükseltilmiş ancak sınırsız olmayan kullanıcılara JEA uç noktasına erişim verilebilir. JEA, bu kullanıcıların tam yönetici erişimi olmadan yönetim komutlarını çalıştırmasına izin verdiğinden, bu kullanıcıları yüksek ayrıcalıklı güvenlik gruplarından kaldırabilirsiniz.

Farklı Çalıştır hesabı

Her JEA uç noktasının, bağlanan kullanıcının eylemlerinin yürütüldiği belirlenmiş bir farklı çalıştır hesabı vardır. Bu hesap oturum yapılandırma dosyasında yapılandırılabilir ve seçtiğiniz hesabın uç noktanızın güvenliği üzerinde önemli bir etkisi vardır.

Sanal hesaplar, farklı çalıştır hesabını yapılandırmanın önerilen yoludur. Sanal hesaplar, bağlanan kullanıcının JEA oturumu süresince kullanması için oluşturulan tek seferlik geçici yerel hesaplardır. Oturumları sonlandırılır sonlandırılmaz sanal hesap yok edilir ve artık kullanılamaz. Bağlanan kullanıcı sanal hesabın kimlik bilgilerini bilmiyor. Sanal hesap, Uzak Masaüstü veya kısıtlanmamış bir PowerShell uç noktası gibi diğer yollarla sisteme erişmek için kullanılamaz.

Varsayılan olarak, sanal hesaplar makinedeki yerel Yönetici istrators grubunun üyeleridir. Bu üyelik, onlara sistemdeki her şeyi yönetme hakları verir, ancak ağdaki kaynakları yönetme hakları yoktur. Kullanıcı JEA oturumundan diğer makinelere bağlandığında, kullanıcı bağlamı sanal hesabın değil yerel bilgisayar hesabının bağlamıdır.

Yerel Yönetici istrators grubu olmadığından etki alanı denetleyicileri özel bir durum oluşturur. Bunun yerine, sanal hesaplar Etki Alanı Yönetici aittir ve etki alanı denetleyicisindeki dizin hizmetlerini yönetebilir. Etki alanı kimliği, JEA oturumunun örneğinin oluşturulduğu etki alanı denetleyicisinde kullanılmak üzere kısıtlanmıştır. Herhangi bir ağ erişimi bunun yerine etki alanı denetleyicisi bilgisayar nesnesinden geliyor gibi görünür.

Her iki durumda da, özellikle görev yerel veya etki alanı yöneticisi ayrıcalıkları olmadan gerçekleştirilebiliyorsa, sanal hesabı belirli güvenlik gruplarına atayabilirsiniz. Yöneticileriniz için tanımlanmış bir güvenlik grubunuz zaten varsa, sanal hesap üyeliğini bu gruba verin. Sanal hesaplar için grup üyeliği, iş istasyonu ve üye sunuculardaki yerel güvenlik gruplarıyla sınırlıdır. Etki alanı denetleyicilerinde, sanal hesapların etki alanı güvenlik gruplarının üyesi olması gerekir. Sanal hesap bir veya daha fazla güvenlik grubuna eklendikten sonra, artık varsayılan gruplara (yerel veya etki alanı yöneticileri) ait değildir.

Aşağıdaki tabloda, sanal hesaplar için olası yapılandırma seçenekleri ve sonuçta elde edilen izinler özetlenmiştir:

Bilgisayar türü	Sanal hesap grubu yapılandırması	Yerel kullanıcı bağlamı	Ağ kullanıcı bağlamı
Etki alanı denetleyicisi	Varsayılan	Etki alanı kullanıcısı, üyesi <DOMAIN>\Domain Admins	Bilgisayar hesabı
Etki alanı denetleyicisi	Etki alanı grupları A ve B	Etki alanı kullanıcısı, üyesi <DOMAIN>\A. <DOMAIN>\B	Bilgisayar hesabı
Üye sunucu veya iş istasyonu	Varsayılan	Yerel kullanıcı, üyesi BUILTIN\Administrators	Bilgisayar hesabı
Üye sunucu veya iş istasyonu	Yerel gruplar C ve D	Yerel kullanıcı, ve üyesi <COMPUTER>\C<COMPUTER>\D	Bilgisayar hesabı

Güvenlik denetimi ve Uygulama olay günlüklerine baktığınızda, her JEA kullanıcı oturumlarının benzersiz bir sanal hesabı olduğunu görürsünüz. Bu benzersiz hesap, JEA uç noktasındaki kullanıcı eylemlerini komutu çalıştıran özgün kullanıcıya geri izlemenize yardımcı olur. Sanal hesap adları biçimine WinRM Virtual Users\WinRM_VA_<ACCOUNTNUMBER>_<DOMAIN>_<sAMAccountName> uyar Örneğin Contoso etki alanındaki Alice kullanıcısı jea uç noktasındaki bir hizmeti yeniden başlatırsa, herhangi bir hizmet denetim yöneticisi olayıyla ilişkilendirilmiş kullanıcı adı olacaktırWinRM Virtual Users\WinRM_VA_1_contoso_alice.

Grup tarafından yönetilen hizmet hesapları (gMSA'lar), üye sunucunun JEA oturumunda ağ kaynaklarına erişmesi gerektiğinde yararlıdır. Örneğin, farklı bir makinede barındırılan REST API hizmetine erişimi denetlemek için jea uç noktası kullanıldığında. REST API'leri çağırmak için işlevler yazmak kolaydır, ancak API ile kimlik doğrulaması yapmak için bir ağ kimliğine ihtiyacınız vardır. Grup tarafından yönetilen bir hizmet hesabı kullanmak, ikinci atlamanın hangi bilgisayarların hesabı kullanabileceği üzerinde denetim sahibi olmasını sağlar. gMSA'nın güvenlik grubu (yerel veya etki alanı) üyelikleri, gMSA hesabı için geçerli izinleri tanımlamıştı.

Bir JEA uç noktası gMSA kullanacak şekilde yapılandırıldığında, tüm JEA kullanıcılarının eylemleri aynı gMSA'dan geliyor gibi görünür. Eylemleri belirli bir kullanıcıya geri izlemenin tek yolu, PowerShell oturum transkriptinde çalıştırılacak komut kümesini belirlemektir.

Geçiş kimlik bilgileri , farklı çalıştır hesabı belirtmediğinizde kullanılır. PowerShell, uzak sunucuda komut çalıştırmak için bağlanan kullanıcının kimlik bilgilerini kullanır. Geçiş kimlik bilgilerini kullanmak için, bağlanan kullanıcıya ayrıcalıklı yönetim gruplarına doğrudan erişim vermelisiniz. Bu yapılandırma JEA için ÖNERILMEZ. Bağlanan kullanıcının yönetici ayrıcalıkları zaten varsa, JEA'yı atlayabilir ve diğer erişim yöntemlerini kullanarak sistemi yönetebilir.

Standart farklı çalıştır hesapları , PowerShell oturumunun tamamının çalıştığı herhangi bir kullanıcı hesabını belirtmenize olanak tanır. Sabit farklı çalıştır hesapları (parametresiyle -RunAsCredential ) kullanan oturum yapılandırmaları JEA'ya duyarlı değildir. Rol tanımları artık beklendiği gibi çalışmaz. Uç noktaya erişim yetkisi olan her kullanıcıya aynı rol atanır.

Eylemleri belirli kullanıcılara geri izlemek zor olduğundan ve kullanıcıları rollere eşleme desteği olmadığından JEA uç noktasında RunAsCredential kullanmamalısınız.

WinRM Uç Noktası ACL'si

Normal PowerShell uzaktan iletişim uç noktaları gibi her JEA uç noktasının, JEA uç noktasıyla kimlerin kimlik doğrulaması yapabileceklerini denetleyen ayrı bir erişim denetimi listesi (ACL) vardır. Yanlış yapılandırılmışsa, güvenilen kullanıcılar JEA uç noktasına erişemeyebilir ve güvenilmeyen kullanıcıların erişimi olabilir. WinRM ACL,kullanıcıların JEA rollerine eşlemini etkilemez. Eşleme, uç noktayı kaydetmek için kullanılan oturum yapılandırma dosyasındaki RoleDefinitions alanı tarafından denetlenmektedir.

Varsayılan olarak, bir JEA uç noktasının birden çok rol özelliği olduğunda, WinRM ACL eşlenen tüm kullanıcılara erişime izin verecek şekilde yapılandırılır. Örneğin, aşağıdaki komutlar kullanılarak yapılandırılan bir JEA oturumu ve CONTOSO\JEA_Lev2için CONTOSO\JEA_Lev1 tam erişim verir.

$roles = @{ 'CONTOSO\JEA_Lev1' = 'Lev1Role'; 'CONTOSO\JEA_Lev2' = 'Lev2Role' }
New-PSSessionConfigurationFile -Path '.\jea.pssc' -SessionType RestrictedRemoteServer -RoleDefinitions $roles -RunAsVirtualAccount
Register-PSSessionConfiguration -Path '.\jea.pssc' -Name 'MyJEAEndpoint'

Get-PSSessionConfiguration cmdlet'iyle kullanıcı izinlerini denetleyebilirsiniz.

Get-PSSessionConfiguration -Name 'MyJEAEndpoint' | Select-Object Permission

Permission
----------
CONTOSO\JEA_Lev1 AccessAllowed
CONTOSO\JEA_Lev2 AccessAllowed

Erişimi olan kullanıcıları değiştirmek için etkileşimli bir istem için veya Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> izinleri güncelleştirmek için komutunu çalıştırınSet-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI. Kullanıcıların JEA uç noktasına erişmek için en azından Invoke haklarına sahip olması gerekir.

Tanımlı bir rolü erişimi olan her kullanıcıyla eşlemeyen bir JEA uç noktası oluşturmak mümkündür. Bu kullanıcılar bir JEA oturumu başlatabilir, ancak yalnızca varsayılan cmdlet'lere erişebilir. bir JEA uç noktasındaki kullanıcı izinlerini çalıştırarak Get-PSSessionCapabilitydenetleyebilirsiniz. Daha fazla bilgi için bkz . JEA'da Denetim ve Raporlama.

En az ayrıcalık rolleri

JEA rollerini tasarlarken, arka planda çalışan sanal ve grup tarafından yönetilen hizmet hesaplarının yerel makineye sınırsız erişimi olabileceğini unutmayın. JEA rol özellikleri, bu ayrıcalıklı bağlamda çalıştırılacak komutları ve uygulamaları sınırlamaya yardımcı olur. Yanlış tasarlanmış roller, kullanıcının JEA sınırlarının dışına çıkmasına veya hassas bilgilere erişmesine izin veren tehlikeli komutlara izin verebilir.

Örneğin, aşağıdaki rol özelliği girişini göz önünde bulundurun:

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\*-Process'
}

Bu rol özelliği, kullanıcıların Microsoft.PowerShell.Management modülündeki İşlem adıyla herhangi bir PowerShell cmdlet'ini çalıştırmasına olanak tanır. Kullanıcıların sistemde hangi uygulamaların çalıştığını görmek ve Stop-Process yanıt vermeyen uygulamaları sonlandırmak gibi Get-Process cmdlet'lere erişmesi gerekebilir. Ancak bu giriş, tam yönetici izinlerine sahip rastgele bir program başlatmak için kullanılabilen öğesine de izin verir Start-Process. Programın sistemde yerel olarak yüklenmesi gerekmez. Bağlı bir kullanıcı, kullanıcıya yerel yönetici ayrıcalıkları veren, kötü amaçlı yazılım çalıştıran ve daha fazlasını sağlayan bir dosya paylaşımından bir program başlatabilir.

Aynı rol özelliğinin daha güvenli bir sürümü şöyle görünür:

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\Get-Process',
                     'Microsoft.PowerShell.Management\Stop-Process'
}

Rol özelliklerinde joker karakter kullanmaktan kaçının. Bir kullanıcının erişebileceği komutları görmek için etkin kullanıcı izinlerini düzenli olarak denetleyebileceğinizden emin olun. Daha fazla bilgi için JEA'da Denetim ve Raporlama makalesinin Geçerli hakları denetleme bölümüne bakın.

En iyi yöntem önerileri

JEA uç noktalarınızın güvenliğini sağlamak için en iyi yöntem önerileri aşağıdadır:

PowerShell sağlayıcılarının kullanımını ve özelliklerini sınırlama

Yapılandırılmış oturumunuzda güvenlik açıkları oluşturmadığınızdan emin olmak için izin verilen sağlayıcıların nasıl kullanıldığını gözden geçirin.

Uyarı

FileSystem sağlayıcısına izin verme. Kullanıcılar dosya sisteminin herhangi bir bölümüne yazabiliyorsa güvenliği tamamen atlamak mümkündür.

Sertifika sağlayıcısına izin verme. Sağlayıcı etkinleştirildiğinde, kullanıcı depolanan özel anahtarlara erişim elde edebilir.

Yeni çalışma alanları oluşturabilen komutlara izin verme.

Uyarı

Cmdlet'ler *-Job kısıtlama olmadan yeni çalışma alanları oluşturabilir.

Cmdlet'e Trace-Command izin verme.

Uyarı

komutunu kullanmak Trace-Command , tüm izleme komutlarını oturuma getirir.

Kısıtlanmış komutlar için kendi proxy uygulamalarınızı oluşturmayın.

PowerShell,kısıtlı komut senaryoları için bir ara sunucu komutları kümesine sahiptir. Bu ara sunucu komutları, giriş parametrelerinin oturumun güvenliğini tehlikeye atmamasını sağlar. Aşağıdaki komutlarda proxy'ler kısıtlanmıştır:

• Exit-PSSession
• Get-Command
• Get-FormatData
• Get-Help
• Measure-Object
• Out-Default
• Select-Object

Bu komutların kendi uygulamasını oluşturursanız, istemeden kullanıcıların JEA proxy komutları tarafından yasaklanan kodu çalıştırmasına izin verirseniz.

JEA, yöneticilere karşı koruma yapmaz

JEA'nın temel ilkelerinden biri, yönetici olmayanların bazı yönetim görevlerini gerçekleştirmesine izin vermesidir. JEA, zaten yönetici ayrıcalıklarına sahip kullanıcılara karşı koruma yapmaz. Etki Alanı Yönetici, yerel Yönetici istrators veya diğer yüksek ayrıcalıklı gruplara ait kullanıcılar JEA'nın korumalarını başka yollarla atlatabilir. Örneğin RDP ile oturum açabilir, uzak MMC konsollarını kullanabilir veya kısıtlanmamış PowerShell uç noktalarına bağlanabilirler. Ayrıca, bir sistemdeki yerel yönetici daha fazla kullanıcı eklemek için JEA yapılandırmalarını değiştirebilir veya bir kullanıcının JEA oturumunda yapabileceklerinin kapsamını genişletmek için bir rol özelliğini değiştirebilir. Sisteme ayrıcalıklı erişim kazanmanın başka yolları olup olmadığını görmek için JEA kullanıcılarınızın genişletilmiş izinlerini değerlendirmeniz önemlidir.

JEA'yı düzenli günlük bakım için kullanmanın yanı sıra, tam zamanında ayrıcalıklı erişim yönetim sistemine sahip olmak yaygın bir durum. Bu sistemler, atanan kullanıcıların geçici olarak yerel yönetici olmasına ancak bu izinlerin kullanımını belgeleyen bir iş akışını tamamladıktan sonra izin verir.