Bir PCI-DSS 3.2.1 için AKS temel kümesinin erişim yönetimi (Bölüm 6/9)

---

Gereksinim 8,1

Tüm sistem bileşenlerinde tüketici olmayan kullanıcılar ve yöneticiler için uygun Kullanıcı tanımlama yönetimini aşağıdaki gibi belirtin ve uygulayın:

• 8.1.1, sistem bileşenlerine veya cardş verilerine erişim izni vermeden önce tüm kullanıcılara benzersiz bir KIMLIK atayın.
• 8.1.2 sürümlü denetim ekleme, silme ve Kullanıcı kimliklerini, kimlik bilgilerini ve diğer tanımlayıcı nesneleri değiştirme.
• 8.1.3, tüm sonlandırılan kullanıcılar için erişimi hemen iptal eder.
• 8.1.4 90 gün içinde etkin olmayan kullanıcı hesaplarını kaldırın/devre dışı bırakın.
• 8.1.5 aşağıdaki gibi, üçüncü taraflar tarafından uzaktan erişim aracılığıyla sistem bileşenlerine erişmek, desteklemek veya sürdürmek için kullanılan kimlikleri yönetin:
  • Yalnızca gereken süre boyunca etkindir ve kullanımda olmadığında devre dışı bırakılır.
  • Kullanımda olduğunda izlenir.
• 8.1.6 altı denemeden sonra kullanıcı KIMLIĞINI kilitleyerek yinelenen erişim girişimlerini sınırlayın.
• 8.1.7 kilitleme süresini en az 30 dakika veya bir yönetici kullanıcı KIMLIĞINI etkinleştirene kadar ayarlayın.
• 8.1.8 15 dakikadan uzun bir süre boşta kalırsa, kullanıcının Terminal veya oturumu yeniden etkinleştirmesi için yeniden kimlik doğrulaması yapmasını isteyin.

Sizin Sorumluluklarınız

Bu gereksinimin genel hususları aşağıda verilmiştir:

UYGULAMA HEDEFI: 8.1.1, 8.1.2 SÜRÜMLÜ, 8.1.3

CDE 'in işlevsel farklı parçaları için kimlikleri paylaşmayın veya yeniden kullanmayın. Örneğin, veri veya küme kaynaklarına erişmek için bir ekip hesabı kullanmayın. Kimlik belgelerinin, paylaşılan hesapları kullanmayan gibi açık olduğundan emin olun.

Bu kimlik sorumlusunu Azure 'da yönetilen kimlik atamalarına genişletin. Azure kaynakları arasında Kullanıcı tarafından yönetilen kimlikleri paylaşmayın. Her bir Azure kaynağına kendi yönetilen kimliğini atayın. Benzer şekilde, AKS kümesinde Azure AD Pod kimliği 'ni kullanırken, iş yükünüzün içindeki her bileşenin kapsamda geniş bir kimlik kullanmak yerine kendi kimliğini aldığından emin olun. Ön üretim ve üretimde aynı yönetilen kimliği hiçbir şekilde kullanmayın.

Azure Kubernetes Service (AKS) için erişim ve kimlik seçenekleri

UYGULAMA HEDEFI: 8.1.2 SÜRÜMLÜ, 8.1.3, 8.1.4

Kimlik deposu olarak Azure AD 'yi kullanın. Küme ve tüm Azure kaynakları Azure AD kullandığından, Azure AD erişimini devre dışı bırakmak veya iptal etmek tüm kaynaklara otomatik olarak uygulanır. Doğrudan Azure AD tarafından desteklenmeyen bileşenler varsa, erişimi kaldırmak için bir işleminiz olduğundan emin olun. Örneğin, bir sıçrama kutusuna erişim için SSH kimlik bilgileri, Kullanıcı artık geçerli değilse açık kaldırma gerektirebilir.

UYGULAMA HEDEFI: 8.1.5

Satıcılar, iş ortakları, Konuk Kullanıcı olarak üçüncü taraf hesaplarını barındırmak için tasarlanan Azure AD işletmeden işletmeye (B2B) yararlanın. Şirket verilerini korumak için Koşullu ilkeleri kullanarak uygun erişim düzeyini verin. Bu hesapların en düşük izinlerle ve zorunlu süre sonu tarihlerine sahip olması gerekir. daha fazla bilgi için bkz. Azure Active Directory B2B 'de konuk kullanıcı erişimi nedir?.

Kuruluşunuz, açık ve belgelenmiş bir satıcı düzenine ve benzer erişime sahip olmalıdır.

UYGULAMA HEDEFI: 8.1.6, 8.1.7, 8.1.8

Sizin Sorumluluklarınız

Azure AD, başarısız oturum açma denemelerinde kullanıcıları kilitlemek için bir akıllı kilit kapatma özelliği sağlar. Locmayı uygulamak için önerilen yol, Azure AD koşullu erişim ilkeleridir.

Benzer özellikleri destekleyen, ancak Azure AD ile desteklenmeyen bileşenler için kilitlemeyi uygulayın (örneğin, bir sıçrama kutusu gibi SSH özellikli makineler). Bu, kilitlenmelerini engellemek veya yavaş erişim denemesi kötüye kullanımı için etkinleştirilmesini sağlar.

AKS düğümleri düzenli olarak erişilecek şekilde tasarlanmamıştır. Küme düğümlerine doğrudan SSH veya uzak masaüstü 'Nü engelleyin. SSH erişimi, yalnızca gelişmiş sorun giderme çabalarının bir parçası olarak göz önünde bulundurulmalıdır. Erişim, belirli bir olayın tamamlanmasından sonra yakından izlenmeli ve hemen geri döndürülüyor. Bunu yaparsanız, herhangi bir düğüm düzeyindeki değişikliğin, kümenizin destek dışı olmasına neden olduğunu unutmayın.

Gereksinim 8,2

Benzersiz bir KIMLIK atamaya ek olarak, tüm kullanıcıların kimliğini doğrulamak için aşağıdaki yöntemlerden en az birini kullanarak tüm sistem bileşenlerinde tüketici olmayan kullanıcılar ve yöneticiler için uygun Kullanıcı kimlik doğrulama yönetimine emin olun: parola veya parola gibi bildiğiniz bir şey, bir belirteç cihazı veya akıllı kart gibi bir şey, sizin kullandığınız bir şey, Örneğin, Biyometri.

• 8.2.1 güçlü şifreleme kullanarak tüm sistem bileşenlerinde iletim ve depolama sırasında tüm kimlik doğrulama kimlik bilgilerini (parolalar/ifadeler gibi) okunamaz şekilde işle.
• 8.2.2 herhangi bir kimlik doğrulama kimlik bilgisini değiştirmeden önce Kullanıcı kimliğini doğrula — Örneğin, parola sıfırlama, yeni belirteçleri sağlama veya yeni anahtarlar oluşturma.
• 8.2.3 parolaları/tümceleri aşağıdaki gibi olmalıdır:
  • En az yedi karakter uzunluğunda olması gerekir.
  • Hem sayısal hem de alfabetik karakterler içerir.
• 8.2.4 Kullanıcı parolalarını/parolayı her 90 günde bir en az bir kez değiştirin.
• 8.2.5, bir bireyin kullandığı son dört parola/tümcecikle aynı olan yeni bir parola/tümcecik göndermesine izin vermez.
• 8.2.6 ilk kez kullanılmak üzere parola/tümcecik ayarlama ve her kullanıcı için benzersiz bir değere sıfırlama ve ilk kullandıktan hemen sonra değiştirme.

Sizin Sorumluluklarınız

Kümeniz Için Azure AD 'de koşullu erişim ilkeleriayarlayın. Bu, Kubernetes denetim düzlemi 'ne erişim kısıtlamalarını da getirir.

Önceki gereksinimler kümesinden bazıları otomatik olarak Azure AD tarafından işlenir. İşte bazı örnekler:

• Parola güvenliği

  Azure AD, güçlü parolaların kullanımını zorlayan özellikler sağlar. Örneğin, genel yasaklanmış parola listesine ait zayıf parolalar engellenir. Bu yeterli koruma değildir. Kuruluşa özgü bir Ban listesi oluşturmak için Azure AD parola koruması özelliğini eklemeyi göz önünde bulundurun. Varsayılan olarak bir parola ilkesi uygulanır. Bazı ilkeler değiştirilemez ve önceki gereksinimler kümesinden bazılarını kapsamaz. Bu, parola süre sonu ve izin verilen karakterleri içerir. Tüm liste için bkz. Azure AD parola ilkeleri. Kullanıcı riskini temel alan, sızdırılan Kullanıcı adı ve parola çiftlerini algılayan özellikler gibi koşullu erişim ilkeleriyle zorlanabilecek gelişmiş özellikleri kullanmayı göz önünde bulundurun. Daha fazla bilgi için bkz. koşullu erişim: Kullanıcı risk tabanlı koşullu erişim.

  Not

  Parolasız seçenekleri göz önünde bulundurmanız önemle tavsiye ederiz. Daha fazla bilgi için bkz. Azure Active Directory bir passwordless kimlik doğrulama dağıtımı planlayın.

• Kullanıcı kimliği doğrulama

  Kimlik doğrulama isteğinin istekte bulunan kimlik tarafından verildiğini algılamak için oturum açma riski koşullu erişim ilkesini uygulayabilirsiniz. İstek, tehdit zekası kaynaklarıyla onaylanır. Bunlar parola spreyi ve IP adresi anormalilerini içerir. Daha fazla bilgi için bkz. koşullu erişim: oturum açma risk tabanlı koşullu erişim.

SSH ile ilgili geçiş kutularına erişim gibi Azure AD kullanmayan bileşenlere sahip olabilirsiniz. Bu gibi durumlarda, en az RSA 2048 anahtar boyutuyla ortak anahtar şifrelemesi kullanın. Her zaman bir parola belirtin. Bilinen onaylanmış ortak anahtarları izleyen bir doğrulama işlemine sahiptir. Ortak anahtar erişimi kullanan sistemler Internet 'e açık değildir. Bunun yerine, özel anahtar sızıntısının etkisini azaltmak için Azure savunma gibi bir aracı aracılığıyla tüm SSH erişimine izin verilmelidir. Doğrudan parola erişimini devre dışı bırakın ve alternatif bir passwordless çözümü kullanın.

Gereksinim 8,3

Multi-Factor Authentication kullanarak her bir konsol dışı yönetim erişiminin ve tüm uzaktan erişimin CDE 'e erişmesini sağlayın. Unutmayın: Multi-Factor Authentication, kimlik doğrulaması için en az iki kimlik doğrulama yönteminden (bkz. kimlik doğrulama yöntemlerinin açıklamaları için gereksinim 8,2) kullanılmasını gerektirir. Bir faktörü iki kez kullanmak (örneğin, iki ayrı parola kullanmak) çok faktörlü kimlik doğrulaması olarak kabul edilmez.

Sizin Sorumluluklarınız

Özel olarak yönetim hesaplarında çok faktörlü kimlik doğrulamasını zorlamak için koşullu erişim ilkelerini kullanın. Bu ilkeler, çeşitli yerleşik rollerde önerilir. Bu ilkeleri, yüksek ayrıcalıkla Kubernetes rollerine eşlenmiş Azure AD gruplarına uygulayın.

Bu ilke ek ilkelerle daha da sağlamlaştırılmış olabilir. İşte bazı örnekler:

• Kimlik doğrulamasını, Azure AD kiracınız tarafından yönetilen cihazlara kısıtlayabilirsiniz.
• Erişim, küme ağı dışındaki bir ağdan kaynaklanıyorsa, çok faktörlü kimlik doğrulamasını zorunlu kılabilirsiniz.

Daha fazla bilgi için bkz.

• Koşullu erişim: Yöneticiler için MFA gerektir
• Nasıl yapılır: koşullu erişimle Cloud App erişimi için yönetilen cihazlar gerektirme
• Nasıl yapılır: koşullu erişimi olan güvenilmeyen ağlardan erişim için MFA gerektirme

Gereksinim 8,4

Aşağıdakiler dahil olmak üzere tüm kullanıcılara kimlik doğrulama yordamlarını ve ilkelerini belgeleyin ve iletişim kurun:

• Güçlü kimlik doğrulama kimlik bilgilerini Seçme Kılavuzu
• Kullanıcıların kimlik doğrulama kimlik bilgilerini nasıl koruduğumuzu gösteren kılavuz
• Yönergeler önceden kullanılan parolaları yeniden kullanma
• Parolaların şüphesi varsa parola değiştirme yönergeleri.

Sizin Sorumluluklarınız

Zorlanan ilkelerle ilgili belgelerde saklayın. Kimlik ekleme eğitiminin bir parçası olarak, varlıkları koruma hakkında parola sıfırlama yordamlarına ve kurumsal en iyi uygulamalara yönelik rehberlik sağlar.

Gereksinim 8,5

Grup, paylaşılan veya genel kimlikleri, parolaları veya diğer kimlik doğrulama yöntemlerini aşağıdaki gibi kullanmayın:

• Genel Kullanıcı kimlikleri devre dışı bırakıldı veya kaldırıldı.
• Sistem Yönetimi ve diğer kritik işlevler için paylaşılan kullanıcı kimlikleri yok.
• Paylaşılan ve genel kullanıcı kimlikleri, herhangi bir sistem bileşenini yönetmek için kullanılmaz.

Sizin Sorumluluklarınız

Kümenin veya yığınların işlevsel parçaları için kimlikleri paylaşmayın veya yeniden kullanmayın. Örneğin, veri veya küme kaynaklarına erişmek için bir ekip hesabı kullanmayın. Kimlik belgelerinin, paylaşılan hesapları kullanmayan gibi açık olduğundan emin olun.

CDE içindeki kök kullanıcıları devre dışı bırakın. Kullanıcıların, CDE içindeki kümelere yerleşik erişimi kullanabilmesi için Kubernetes yerel hesaplarının kullanımını devre dışı bırakın --admin .

Gereksinim 8,6

Diğer kimlik doğrulama mekanizmalarının kullanıldığı yerlerde (örneğin, fiziksel veya mantıksal güvenlik belirteçleri, akıllı kartlar, sertifikalar, vb.), bu mekanizmaların kullanılması aşağıdaki gibi atanmalıdır:

• Kimlik doğrulama mekanizmalarının tek bir hesaba atanması ve birden çok hesap arasında paylaşılmaması gerekir.
• Yalnızca amaçlanan hesabın erişim kazanmak için bu mekanizmayı kullanmasını sağlamak için fiziksel ve/veya mantıksal denetimlerin yerinde olması gerekir.

Sizin Sorumluluklarınız

Her Kullanıcı kimliği için CDE öğesine tüm erişimin sağlandığından emin olun ve bu, herhangi bir fiziksel veya sanal belirtece genişletilir. Bu, CDE ağına VPN erişimi içerir ve bu kimlik doğrulama akışının bir parçası olarak, kurumsal Noktadan siteye erişimi (varsa) Kullanıcı başına sertifikaları kullanır.

Gereksinim 8,7

Kart sahibi verileri içeren herhangi bir veritabanına erişim (uygulamalar, Yöneticiler ve diğer tüm kullanıcılar tarafından erişim dahil) aşağıdaki gibi kısıtlanmıştır:

• Tüm Kullanıcı erişimi, veritabanlarında Kullanıcı sorguları ve Kullanıcı eylemleri, programlama yöntemlerine göre yapılır.
• Yalnızca veritabanı yöneticilerinin veritabanlarına doğrudan erişme veya veritabanını sorgulama yeteneği vardır.
• Veritabanı uygulamaları için uygulama kimlikleri yalnızca uygulamalar tarafından kullanılabilir (ve ayrı kullanıcılara veya uygulama dışı işlemlere göre değil).

Sizin Sorumluluklarınız

Rollere ve sorumluluklara göre erişim sağlayın. Kullanıcılar kimliklerini kullanabilir, ancak erişimin en düşük izinlerle sınırlı olması gerekir. Kişiler hiçbir şekilde uygulama kimliği kullanmamalıdır ve veritabanı erişim kimliklerinin hiçbir şekilde paylaşılmaması gerekir.

Mümkünse, yönetilen kimlik aracılığıyla uygulamalardan veritabanına erişin. Aksi takdirde, bağlantı dizeleri ve kimlik bilgileriyle pozlamayı sınırlayın. Kubernetes gizli dizilerini kullanarak, onları kolayca keşfettikleri yerlerde, Pod tanımı gibi hassas bilgileri saklayın. Başka bir yöntem de Azure Key Vault gibi yönetilen bir mağazadan ve içindeki gizli dizileri depolamak ve yüklemek için kullanılır. Bir AKS kümesinde etkinleştirilmiş Yönetilen kimlikler sayesinde, erişim sağlamak için Key Vault karşı kendi kimlik doğrulaması yapması gerekir.

Gereksinim 8,8

Kimlik ve kimlik doğrulama için güvenlik ilkelerinin ve işletimsel yordamların, kullanımda ve etkilenen tüm taraflar tarafından bilindiğinden emin olun.

Sizin Sorumluluklarınız

Süreçler ve ilkeler hakkında kapsamlı belgeleri korumanız önemlidir. Zorlanan ilkelerle ilgili belgelerde saklayın. Kimlik ekleme eğitiminin bir parçası olarak, varlıkları koruma hakkında parola sıfırlama yordamlarına ve kurumsal en iyi uygulamalara yönelik rehberlik sağlar. Çalışan kullanıcıların, güvenlik güvenlerini desteklemek için eğitime, bilgilendirme ve incentivized olması gerekir. Bu, özellikle bir ilke perspektifinden onay sürecinin parçası olan kişiler için önemlidir.

Gereksinim 9

Cardş verilerine fiziksel erişimi kısıtla

Sizin Sorumluluklarınız

Bu mimari ve uygulama, şirket içi kaynaklara veya veri merkezlerine fiziksel erişim için denetimler sağlamak üzere tasarlanmamıştır. Dikkat edilmesi için, resmi PCI-DSS 3.2.1 Standard 'daki kılavuza bakın.

Teknik denetimleri uygulamaya yönelik bazı öneriler aşağıda verilmiştir:

• Erişimi en aza indirmek için, CDE içindeki atma kutuları gibi herhangi bir yönetim konsolu erişiminde oturum zaman aşımlarını ayarlayın.

• Azure portal gibi erişim noktalarından Azure erişim belirteçlerinde TTL 'yi en aza indirmek için koşullu erişim ilkelerini ayarlayın. Daha fazla bilgi için şu makalelere bakın:

  • Erişim Denetimi ile kimlik doğrulama oturum yönetimini yapılandırma
  • yapılandırılabilir belirteç yaşam süreleri-Microsoft kimlik platformu

• Bulutta barındırılan CDE için, fiziksel erişimi ve donanımı yönetmeye yönelik herhangi bir sorumluluk yoktur. Kurumsal ağ fiziksel ve mantıksal denetimlerine güvenin.

• CHD yedeklemelerin şirket içi hedeflere verilmesini en aza indirir. Azure 'da barındırılan çözümleri kullanarak yedeklemelere fiziksel erişimi sınırlayın.

• Şirket içi yedeklemeleri en aza indirin. Bu gerekliyse, şirket içi hedefin denetim kapsamında olacağını unutmayın.

Sonraki adımlar

Ağ kaynaklarına ve kart sahibi verilere erişimi izleyin ve izleyin. Güvenlik sistemlerini ve süreçlerini düzenli olarak test edin.

Bu makalede, bir Azure Kubernetes hizmeti (AKS) kümesine yönelik olarak, ödeme kartı sektör verileri güvenlik standardı (PCI-DSS 3.2.1) doğrultusunda yapılandırılan noktalar açıklanmaktadır.

Bu makale, bir serinin bir parçasıdır. Tanıtımıokuyun.

Kubernetes, Kubernetes API 'SI için izinleri yöneten yerel rol tabanlı erişim denetimine (RBAC) sahiptir. Kubernetes kaynakları üzerinde belirli izinlere veya eylemlere sahip çeşitli yerleşik roller vardır. Azure Kubernetes hizmeti (AKS), ayrıntılı denetim için bu yerleşik rolleri ve özel rolleri destekler. Bu eylemler, Kubernetes RBAC aracılığıyla bir kullanıcıya yetkilendirilir (veya reddedilebilir).

Bu mimari ve uygulama, şirket içi kaynaklara veya veri merkezlerine fiziksel erişim için denetimler sağlamak üzere tasarlanmamıştır. Azure 'da, Azure 'da veya veri merkezinizdeki platformunuzun aksine, fiziksel erişimin kısıtlanması, genellikle Azure veri merkezi güvenliği aracılığıyla daha önce işlenmesidir. Fiziksel donanımın yönetiminde kuruluş için herhangi bir sorumluluk yoktur.

Güçlü erişim denetimi ölçüleri uygulama

Gereksinim 7— iş gereksinimine göre kart sahibi verilerine erişimi kısıtlayın

AKS özelliği desteği

aks, kimlik sağlayıcısı olarak Azure Active Directory (Azure AD) ile tamamen tümleşiktir.

Kubernetes için ayrı kullanıcı kimliklerini ve kimlik bilgilerini yönetmeniz gerekmez. Kubernetes RBAC için Azure AD kullanıcıları ekleyebilirsiniz. Bu tümleştirme, Azure AD kullanıcılarına rol atamaları yapmayı olanaklı kılar. Azure AD RBAC, yerleşik roller olarak Görüntüleyici, yazıcı, hizmet yöneticisi, Küme Yöneticisi gibi rol tanımlarını destekler. Ayrıca daha ayrıntılı denetim için özel roller de oluşturabilirsiniz.

Varsayılan olarak, Azure RBAC hepsini reddeder ve bu nedenle izinler verilmeden kaynağa erişilemez. AKS, SSH erişimini AKS çalışan düğümleriyle sınırlar ve podlardaki iş yüklerine erişimi kontrol etmek için AKS ağ ilkesi kullanır.

Daha fazla bilgi için bkz. Kubernetes Yetkilendirmesi için Azure RBAC kullanma ve kümenizin güvenliğini Azure İlkesi.

Sizin Sorumluluklarınız

Gereksinim	Sorumluluk
Gereksinim 7.1	Sistem bileşenlerine ve kart sahibi verilerine erişimi yalnızca işi böyle erişim gerektiren bireylerle sınırla.
Gereksinim 7.2	Bir kullanıcının bilmek zorunda olduğu bilgilere göre erişimi kısıtlayan ve özel olarak izin verilmediği sürece "hepsini reddet" olarak ayarlanmış sistem bileşenleri için bir erişim denetimi sistemi ayarlayın.
Gereksinim 7.3	Kart sahibi verilerine erişimi kısıtlamaya yönelik güvenlik ilkelerinin ve operasyonel yordamların belgelenmiş, kullanımda ve etkilenen tüm taraflar tarafından bilindiğiden emin olun.

Gereksinim 8—Sistem bileşenlerine erişimi tanımlama ve kimlik doğrulaması

AKS özellik desteği

AKS ve Azure AD tümleştirmesi nedeniyle erişim yönetimi, tanımlayıcı nesneleri yönetimi ve diğerleri gibi kimlik yönetimi ve yetkilendirme özellikleri kullanılabilir. Daha fazla bilgi için bkz. AKS tarafından yönetilen Azure Active Directory tümleştirmesi.

Sizin Sorumluluklarınız

Gereksinim	Sorumluluk
Gereksinim 8.1	Tüm sistem bileşenleri üzerinde tüketici olmayan kullanıcılar ve yöneticiler için uygun kullanıcı tanımlama yönetimi sağlamak üzere ilkeleri ve yordamları aşağıdaki gibi tanımlayın ve gerçekleştirin:
Gereksinim 8.2	Benzersiz bir kimlik atamaya ek olarak, tüm kullanıcıların kimliğini doğrulamak için aşağıdaki yöntemlerden en az birini kullanarak tüm sistem bileşenlerinde tüketici olmayan kullanıcılar ve yöneticiler için uygun kullanıcı kimlik doğrulaması yönetimine sahip olduğundan emin olursunuz:
Gereksinim 8.3	Çok faktörlü kimlik doğrulamasını kullanarak tek tek tüm konsol dışı yönetim erişimini ve CDE'ye tüm uzaktan erişimin güvenliğini sağlama.
Gereksinim 8.4	Kimlik doğrulama yordamlarını ve ilkelerini ve yordamlarını belgele ve tüm kullanıcılara ilet:
Gereksinim 8.5	Grup, paylaşılan veya genel kimlikler, parolalar veya diğer kimlik doğrulama yöntemlerini aşağıdaki gibi kullanmayın:
Gereksinim 8.6	Diğer kimlik doğrulama mekanizmaları (örneğin, fiziksel veya mantıksal güvenlik belirteçleri, akıllı kartlar, sertifikalar vb.) kullanılırsa, bu mekanizmaların kullanımı aşağıdaki gibi atanabilir:
Gereksinim 8.7	Kart sahibi verileri içeren herhangi bir veritabanına (uygulamalar, yöneticiler ve diğer tüm kullanıcılar tarafından erişim dahil) tüm erişim aşağıdaki gibi kısıtlanır:
Gereksinim 8.8	Tanımlama ve kimlik doğrulaması için güvenlik ilkelerinin ve işlem yordamlarının belgelenmiş, kullanımda ve etkilenen tüm taraflar tarafından bilindiğiden emin olun.

Gereksinim 9—Kart sahibi verilerine fiziksel erişimi kısıtlama

Gereksinim 7.1

Sistem bileşenlerine ve kart sahibi verilerine erişimi yalnızca işi böyle erişim gerektiren bireylerle sınırla.

Sizin Sorumluluklarınız

Dikkat edilmesi gereken bazı noktalar:

• Uygulamanıza kuruluşun gereksinimleri ve kimlik yönetimiyle ilgili uyumluluk gereksinimlerinin uygun olduğundan emin olun.
• Özellikle kritik etki hesapları için bekleme izinlerini en aza indirme.
• En az ayrıcalıklı erişim ilkesini izleyin. Görevi tamamlamak için yeterli erişim sağlama.

Gereksinim 7.1.1

Her rol için erişim ihtiyaçlarını tanımlayın, örneğin:

• Her rolün iş işlevi için erişmesi gereken sistem bileşenleri ve veri kaynakları
• Gerekli ayrıcalık düzeyi (örneğin, kullanıcı, yönetici vb.) kaynaklara erişmek için.

Sizin Sorumluluklarınız

Kapsam içinde bileşenler ve bunların Azure kaynaklarıyla etkileşimleri için gereken görevlere ve sorumluluklara göre rolleri tanımlayın. Geniş kategorilerle başlayabilirsiniz, örneğin:

• Azure yönetim gruplarına, aboneliklere veya kaynak gruplarına göre kapsam
• Azure İlkesi iş yükü veya abonelik için abonelik
• Kapsayıcı işlemleri
• Gizli dizi yönetimi
• Derleme ve dağıtım işlem hatları

Bu alanlardaki rollerin ve sorumlulukların tanımı ekip yapınız ile ilişkilendirilebilir ancak iş yükünün gereksinimine odaklanın. Örneğin güvenliği, yalıtımı, dağıtımı ve gözlemlenebilirliği korumak kimin sorumluluğundadır? İşte bazı örnekler:

• Uygulama güvenliği, Kubernetes RBAC, ağ ilkeleri, Azure ilkeleri ve diğer hizmetlerle iletişim hakkında kararlar.
• Güvenlik duvarı, Azure Güvenlik Duvarı güvenlik duvarı (WAF), ağ güvenlik grupları (NSG) ve DNS yapılandırmasının yapılandırması ve bakımı.
• Sunucu güvenliğini, düzeltme eki uygulama, yapılandırma ve uç nokta güvenliğini izleme ve düzeltme.
• Azure kaynaklarını yönetmek için RBAC, Bulut için Microsoft Defender, Yönetici koruma stratejisi ve Azure İlkesi için yön ayarlayın.
• Olay izleme ve yanıt ekibi. Güvenlik bilgileri ve olay yönetimi (SIEM) veya Bulut için Microsoft Defender'daki güvenlik olaylarını araştırın ve düzeltme.

Ardından iş yükü ve altyapıyla ilgili olarak rol için hangi erişim düzeyinin gerekli olduğunu belirleyerek tanımı resmileştirin. Burada, açıklayıcı amaçlara yönelik basit bir tanım vemektedir.

Rol	Sorumluluklar	Erişim düzeyleri
Uygulama sahipleri	İş sonuçlarıyla uyumlu özellikleri tanımlama ve önceliklerini belirleme. Özelliklerin iş yükünün uyumluluk scopingini nasıl etkilemektedir ve müşteri veri koruma ile sahipliğini iş hedefleriyle dengeler.	Uygulama tarafından yayılan günlüklere ve ölçümlere okuma erişimi. İş yüküne veya kümeye erişmek için izinlere ihtiyaçları yok.
Uygulama geliştiricileri	Uygulamayı geliştirin. Tüm uygulama kodu; uyumluluk, uygunluk ve sürüm yönetimi süreçleri için eğitim ve kalite geçitlerine tabi olur. Derleme işlem hatlarını yönetebilir, ancak genellikle dağıtım işlem hatlarını yönetmez.	İş yükü kapsamındaki Kubernetes ad alanlarına ve Azure kaynaklarına okuma erişimi. Sistemin herhangi bir durumunu dağıtmak veya değiştirmek için yazma erişimi yok.
Uygulama işleçleri (veya SRE)	Kod tabanı, gözlemlenebilirlik ve işlemler hakkında derin bir anlayışa sahip olur. Canlı site triyalesi yapma ve sorun giderme. Uygulama geliştiricilerinin yanı sıra uygulamanın kullanılabilirliğini, ölçeklenebilirliğini ve performansını geliştirin. "Son kilometre" dağıtım işlem hattını yönetin ve derleme işlem hatlarının yönetimine yardımcı olun.	İlgili Kubernetes ad alanlarını ve Azure kaynaklarını içeren uygulama kapsamında yüksek ayrıcalıklı. Büyük olasılıkla Kubernetes kümesi bölümlerine erişimi vardır.
Altyapı sahipleri	Bağlantısı ve bileşenlerin işlevselliği de dahil olmak üzere uygun maliyetli bir mimari tasarlar. Kapsam bulut ve şirket içi hizmetleri içerebilir. Özelliklere veri saklama, iş sürekliliği özellikleri ve diğer özelliklere karar verin.	Platform günlüklerine ve maliyet merkezi verilerine erişim. Küme içinde erişim gerekmez.
Altyapı işleçleri (veya SRE)	Küme ve bağımlı hizmetlerle ilgili işlemler. İş yükünün dağıtılacağı küme için işlem hattını derleme, dağıtma ve önyükleme. Hedef düğüm havuzlarını, beklenen boyutlandırma ve ölçeklendirme gereksinimlerini ayarlayın. Kapsayıcı barındırma altyapısının ve bağımlı hizmetlerin durumunu izleme.	İş yükü ad alanlarına okuma erişimi. Küme için yüksek ayrıcalıklı erişim.
İlke, güvenlik sahipleri	Güvenlik veya mevzuat uyumluluğu uzmanlığına sahip olmak. Şirket çalışanlarının, varlıklarının ve şirketin müşterilerinin güvenlik ve mevzuat uyumluluğunu koruyan ilkeler tanımlayın. İlkenin her aşamada uygulandığını ve denetlenebilir olduğundan emin olmak için diğer tüm rollerle çalışır.	İş yüküne ve kümeye okuma erişimi. Ayrıca günlük ve denetim verilerine de erişim.
Ağ işleçleri	Kuruluş genelindeki sanal ağ ve alt ağların ayırması. Azure Güvenlik Duvarı, WAF, NSG'ler ve DNS yapılandırmasının yapılandırması ve bakımı.	Ağ katmanında yüksek ayrıcalıklı. Küme içinde yazma izni yok.

Gereksinim 7.1.2

Ayrıcalıklı kullanıcı kimliklerine erişimi iş sorumluluklarını gerçekleştirmek için gereken en az ayrıcalıkla kısıtla.

Sizin Sorumluluklarınız

İş işlevlerine bağlı olarak, kesintiye neden olmadan erişimi en aza indirmeye çabalayın. Aşağıda bazı en iyi uygulamalar verilmiştir:

• Kimliğin bir görevi tamamlamak için yeterli erişimi olması gerekir.
• Özellikle kapsam içinde bileşenlere erişimi olan kritik öneme sahip kimliklerde, bekleme izinlerini en aza indirme.
• Mümkün olduğunca ek kısıtlamalar ekleyin. Bunun bir yolu, erişim ölçütlerine göre koşullu erişim sağlamaktır.
• Okuma erişimi için bile aboneliklerinize erişimi olan kullanıcı ve grupları düzenli olarak gözden geçirme ve denetleme. Dış kimlikleri davet etmekten kaçının.

Gereksinim 7.1.3

Tek tek personelin iş sınıflandırması ve işlevine göre erişim atama.

Sizin Sorumluluklarınız

Kişinin açıkça atanan iş görevlerine göre izinleri belirleme. Sistem veya çalışanın çalışma zamanları gibi parametrelerden kaçının. Tek bir kullanıcıya veya gruba erişim hakları verme.

Aşağıda bazı örnekler verilmiştir.

İş sınıflandırması	Rol
Ürün sahibi, iş yükünün kapsamını tanımlar ve özellikleri öncelik sırasına göre tanımlar. Müşteri veri korumasını ve sahipliğini iş hedefleriyle dengeler. Raporlara, maliyet merkezine veya Azure panolarına erişmesi gerekir. Küme içinde veya küme düzeyinde izinler için erişim gerekmez.	Uygulama sahipleri
Yazılım mühendisi uygulama kodunu tasarlar, geliştirir ve kapsayıcılı hale gelir. Azure'da tanımlı kapsamlar (Application Analizler gibi) ve iş yükü ad alanları içinde yer alan okuma izinlerine sahip bir grup. Bu kapsamlar ve izinler üretim öncesi ortamlar ile üretim ortamları arasında farklı olabilir.	Uygulama geliştiricisi
Site güvenilirlik mühendisi canlı site değerlendirmesi yapar, işlem hatlarını yönetir ve uygulama altyapısını ayarlar. Ayrılmış ad alanları içinde tam denetime sahip A grubu. Bekleme izinleri gerekli değildir. İş yükü üzerinde günlük işlemler için B Grubu. Ayrılmış ad alanları içinde bekleme izinlerine sahip olabilir, ancak yüksek ayrıcalıklı değildir.	Uygulama işleçleri
Küme operatörü, platforma güvenilir ve güvenli bir AKS kümesi tasarlar ve dağıtır. Küme sürelerini korumakla sorumludur. Ayrılmış ad alanları içinde tam denetime sahip A grubu. Bekleme izinleri gerekli değildir. İş yükü üzerinde günlük işlemler için B Grubu. Ayrılmış ad alanları içinde bekleme izinlerine sahip olabilir, ancak yüksek ayrıcalıklı değildir.	Altyapı işleçleri
Ağ mühendisi kuruluş genelindeki sanal ağ ve alt ağları, şirket içi ağı bulut bağlantısına ve ağ güvenliğine ayırır.	Altyapı işleçleri

Gereksinim 7.1.4

Gerekli ayrıcalıkları belirten yetkili taraflar tarafından belgelenmiş onay gerektir.

Sizin Sorumluluklarınız

Ayrıcalıkların ilk ataması da dahil olmak üzere rol ve izin değişikliklerinin onaylanması için geçitli bir işleme sahip olun. Bu onayların belgelenmiş ve inceleme için kullanılabilir olduğundan emin olmak.

Gereksinim 7.2

Bir kullanıcının bilmek zorunda olduğu bilgilere göre erişimi kısıtlayan ve özel olarak izin verilmediği sürece "hepsini reddet" olarak ayarlanmış sistem bileşenleri için bir erişim denetimi sistemi ayarlayın.

Sizin Sorumluluklarınız

Gereksinim 7.1'itakip ettikten sonra, kuruluş ve iş yükü için geçerli olan rolleri ve sorumlulukları değerlendirin. Mimaride kapsam içinde olan tüm bileşenlerin kısıtlı erişimi olması gerekir. Buna iş yükünü, veri depolama alanını, ağ erişimini ve kart tutucu verileri (CHD) işlemeye katılan diğer tüm hizmetleri çalıştıran AKS düğümleri dahildir.

Rollere ve sorumluluklara bağlı olarak, altyapının rol tabanlı erişim denetimine (RBAC) roller attayın. Bu mekanizma şöyle olabilir:

• Kubernetes RBAC, Kubernetes API sunucusu aracılığıyla ortaya çıkan Kubernetesdenetim düzlemi erişimini kontrol eden yerel bir Kubernetes yetkilendirme modelidir. Bu izin kümesi, API sunucusuyla neler yapalarını tanımlar. Örneğin, bir kullanıcıya pod oluşturma ve hatta podları listele iznini reddedebilirsiniz.
• Azure RBAC, Azure denetim düzlemi erişimini kontrol eden Azure AD tabanlı bir yetkilendirme modelidir. Bu, Azure AD kiracınız ile Azure aboneliğinizin bir ilişkilendirmesidir. Azure RBAC ile ağlar, AKS kümesi ve yönetilen kimlikler gibi Azure kaynakları oluşturma izinleri veebilirsiniz.

Küme işleçlerine (altyapı operatörü rolüyle eşlenmiş) izinler vermenin gerekli olduğunu varsayalım. Altyapı operatörü sorumlulukları atanan tüm kişiler bir Azure AD Grubuna aittir. 7.1.1'de olduğu gibi, bu rol kümede en yüksek ayrıcalığı gerektirir. Kubernetes,bu gereksinimleri karşılar gibi yerleşik RBAC cluster-admin rollerine sahiptir. Rol bağlamaları oluşturarak altyapı operatörü için Azure AD Grubunu cluster-admin 'a bağlamanız gerekir. İki yaklaşım vardır. Yerleşik rolleri seçebilirsiniz. Veya yerleşik roller gereksinimlerinizi karşılamıyorsa (örneğin, aşırı izinli olabilir), bağlamalar için özel roller oluşturun.

Başvuru uygulaması, yerel Kubernetes RBAC kullanarak önceki örneği gösteriyor. Aynı ilişkilendirme Azure RBAC ile de gerçek olabilir. Daha fazla bilgi için bkz. Kubernetesrol tabanlı erişim denetimi kullanarak küme kaynaklarına erişimi denetleme ve Azure Active Directory kimliklerini Azure Kubernetes Service.

İzin kapsamını küme düzeyinde veya ad alanı düzeyinde seçebilirsiniz. Uygulama işleçleri gibi kapsamlı sorumlulukları olan roller için, izinler iş yükü için ad alanı düzeyinde atanır.

Ayrıca, rollerin görevlerini gerçekleştirebileri için Azure RBAC izinleri de gerekir. Örneğin, küme operatörünün portal üzerinden Azure İzleyici olması gerekir. Bu nedenle altyapı operatörü rolünün uygun RBAC ataması olması gerekir.

Kişiler ve rolleri dışında, küme içindeki Azure kaynakları ve hatta podlar yönetilen kimliklere sahip olur. Bu kimliklerin Azure RBAC aracılığıyla bir dizi izine ihtiyacı vardır ve bunların kapsamı beklenen görevlere göre sıkı bir şekilde belirlenebilir. Örneğin, Azure Application Gateway gizli dizileri (TLS sertifikaları) almak için izinlere sahip Azure Key Vault. Gizli dizileri değiştirme izinleri olması gerekir.

Aşağıda bazı en iyi uygulamalar verilmiştir:

• Her rol ve atanan izinler hakkında titiz belgelere sahip olun. Hangi izinlerin JIT olduğu ve hangilerin var olduğu konusunda net bir ayrım gözetin.

• Atama değişiklikleri veya rol tanımları gibi değişiklikler için rolleri izleyin. Değişikliklerin arkasında bir görünürlük elde etmek beklenseler bile değişiklikler üzerinde uyarılar oluşturun.

Gereksinim 7.2.1

Tüm sistem bileşenlerinin kapsamı

Sizin Sorumluluklarınız

Erişim denetimi ölçümlerini sürdürmek için bazı en iyi uygulamalar şunlardır:

• Bekleyen erişimi yok. Tam ZAMANıNDA ad grup üyeliğikullanmayı düşünün. Bu özellik Azure AD Privileged Identity Management gerektirir.

• Kümeniz Için Azure AD 'de koşullu erişim ilkeleriayarlayın. Bu, Kubernetes denetim düzlemi 'ne erişim kısıtlamalarını da getirir. Koşullu erişim ilkeleriyle, çok faktörlü kimlik doğrulaması gerektirebilir, kimlik doğrulamasını Azure AD kiracınız tarafından yönetilen cihazlara kısıtlayabilir veya tipik olmayan oturum açma girişimlerini engelleyebilirsiniz. Bu ilkeleri, yüksek ayrıcalıkla Kubernetes rollerine eşlenmiş Azure AD gruplarına uygulayın.

  Not

  Hem JıT hem de koşullu erişim teknolojisi seçimleri Azure AD Premium gerektirir.

• Küme düğümlerine SSH erişimini ideal olarak devre dışı bırakır. Bu başvuru, bu amaçla SSH bağlantısı ayrıntılarını oluşturmaz.

• Geçiş kutuları gibi ek işlem, yetkili kullanıcılar tarafından erişilmelidir. Tüm takım için kullanılabilir genel oturumlar oluşturmayın.

Gereksinim 7.2.2

İş sınıflandırması ve işlevine göre bireyler için ayrıcalıkların atanması.

Sizin Sorumluluklarınız

7.1.3 temelinde, küme işlemlerine dahil edilen birçok rol olacaktır. Standart Azure Kaynak rollerinin ötesinde, erişim kapsamını ve işlem işlemini tanımlamanız gerekir.

Örneğin, küme işletmeni rolünü göz önünde bulundurun. Küme önceliklendirme etkinlikleri için açıkça tanımlanmış bir PlayBook olmalıdır. İş yükü ekibinin erişimi ne kadar farklıdır? Kuruluşunuza bağlı olarak, aynı olabilir. Göz önünde bulundurulması gereken bazı noktaları şunlardır:

• Kümeye nasıl erişmeleri gerekir?
• Erişim için hangi kaynaklara izin veriliyor?
• Kümede sahip olmaları gereken izinler nelerdir?
• Bu izinler ne zaman atanır?

Tanımların iş yükü operatörü ve küme operatörü içindeki idare belgelerinde, ilkede ve eğitim malzemelerde belgelendiğinden emin olun.

Gereksinim 7.2.3

Varsayılan "Reddet-tümü" ayarı.

Sizin Sorumluluklarınız

Yapılandırmayı başlattığınızda, sıfır güvenle ilke ile başlayın. Gerektiğinde özel durumlar oluşturun ve bunları ayrıntılı olarak belgeleyin.

• Kubernetes RBAC, varsayılan olarak Tümünü Reddet ' i uygular. Tümünü Reddet ayarını tersine sağlayan, yüksek oranda izin veren küme rolü bağlamaları eklenerek geçersiz kılınmayın.

• Azure RBAC, varsayılan olarak Tümünü Reddet ' i de uygular. Tümünü Reddet ayarını tersine alan RBAC atamaları ekleyerek geçersiz kılınmayın.

• Tüm Azure Hizmetleri, Azure Key Vault ve Azure Container Registry, varsayılan olarak tüm izin kümesini reddetmeye sahiptir.

• Bir sıçrama kutusu gibi herhangi bir yönetim erişim noktası, ilk yapılandırmadaki tüm erişimi reddetmelidir. Tüm yükseltilmiş izinler açıkça Reddet kuralına açıkça tanımlanmalıdır.

Gereksinim 7,3

Cardş verilerine erişimi kısıtlamak için güvenlik ilkelerinin ve işlem yordamlarının, kullanımda ve etkilenen tüm taraflar tarafından bilindiğinden emin olun.

Sizin Sorumluluklarınız

Süreçler ve ilkeler hakkında kapsamlı belgeleri korumanız önemlidir. Bu, Azure ve Kubernetes RBAC ilkelerini ve kurumsal idare ilkelerini içerir. Çalışan kullanıcıların, güvenlik güvenlerini desteklemek için eğitime, bilgilendirme ve incentivized olması gerekir. Bu, özellikle bir ilke perspektifinden onay sürecinin parçası olan kişiler için önemlidir.