PCI-DSS 3.2.1 için AKS tarafından düzenlenen kümenin mimarisi (Bölüm 2 / 9)

Bu makalede, Ödeme Kartı Endüstri Veri Güvenliği Standardı (PCI-DSS 3.2.1) ile uyumlu bir iş yükü çalıştıran bir Azure Kubernetes Service (AKS) kümesi için başvuru mimarisi açıklanmaktadır. Bu mimari, PCI-DSS 3.2.1 iş yüküne değil altyapıya odaklanmıştır.

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

Öneriler ve örnekler bu eşlik eden başvuru uygulamasından ayıklanır:

GitHub: Düzenlenmiş İş Yükleri için Azure Kubernetes Service (AKS) Temel Kümesi, düzenlenen altyapıyı gösterir. Bu uygulama bir mikro hizmet uygulaması sağlar. Altyapıyı deneyimlemenize yardımcı olmak, ağ ve güvenlik denetimlerini göstermek için de dahildir. Uygulama gerçek bir PCI DSS iş yükünü temsil etmez veya uygulamaz.

Bu mimarinin bir Visio dosyasını indirin.

Bu ağ mimarisi bir merkez-uç topolojisi temel alır. Merkez sanal ağı çıkış trafiğini denetlemek için güvenlik duvarını, şirket içi ağlardan gelen ağ geçidi trafiğini ve SRE (site güvenilirlik mühendisi) küme erişimi için üçüncü bir ağı içerir. İki uç sanal ağı vardır. Bir uç, kart tutucu ortamının (CDE) bir bileşeni olan AKS kümesini içerir ve PCI DSS iş yükünü barındırıyor. Diğer uç, ortama kontrollü SRE erişimi için kullanılan sanal makine görüntüleri oluşturur.

Bileşenler

Bu mimaride kullanılan ana bileşenler aşağıdadır. Bu hizmetler hakkında bilginiz yoksa ürün bağlantıları için İlgili Azure hizmetleri belgelerine bakın.

Azure Güvenlik Duvarı

Güvenlik duvarı örneği giden ağ trafiğinin güvenliğini sağlar. Bu güvenlik katmanı olmadan akış, hassas şirket verilerini silerek kötü amaçlı bir üçüncü taraf hizmetiyle iletişim kurabilir.

Azure Bastion

Temel mimari, Azure Bastion için bir alt ağ sağladı, ancak kaynağı sağlamadı. Bu mimari alt ağa Azure Bastion ekler ve bir atlama kutusuna güvenli erişim sağlar.

Azure Görüntü Oluşturucusu

Ayrı bir sanal ağda sağlanan bu ağ, temel güvenlik ve yapılandırma ile VM görüntüleri oluşturur. Bu mimaride Azure CLI, ve Flux CLI kubectlgibi yönetim araçları önceden yüklenmiş olarak güvenli düğüm görüntüleri derlenecek şekilde özelleştirilir.

Atlama kutusu örnekleri için Azure Sanal Makine Ölçek Kümeleri

Uç ağının atlama kutusu için ek işlem vardır. Bu ölçek kümesinin, aks kümesinde gerektiğinde gibi kubectlaraçları çalıştırmak için yönetilen erişim noktası olması amaçlanmıştır.

Tümleşik Web Uygulaması Güvenlik Duvarı (WAF) ile Azure Uygulaması Lication Gateway

Azure Uygulaması Lication Gateway yük dengeleri Katman 7'dedir. WAF, yaygın web trafiği saldırılarından gelen trafiğin güvenliğini sağlar. Örneğin kullanıcı isteklerini alan bir genel ön uç IP yapılandırması vardır.

Azure Kubernetes Service (AKS)

Kart sahibi veri ortamının (CDE) önemli bir parçası olan barındırma altyapısı. AKS kümesi özel küme olarak dağıtılır. Bu nedenle Kubernetes API sunucusu genel İnternet'e sunulmaz ve API sunucusuna yönelik trafik özel ağınızla sınırlıdır.

ACR Görevleri

Kapsayıcı görüntülerini oluşturmanın ve bakımının otomatik bir yolunu sağlar.

Azure Key Vault

Sertifikalar ve şifreleme anahtarları gibi küme işlemleri için gereken gizli dizileri depolar ve yönetir.

Küme yapılandırması

Temel mimarideki bazı önemli değişiklikler şunlardır:

Düğüm havuzu segmentasyonu

Bu mimaride kümenin iki kullanıcı düğümü havuzu ve bir sistem düğümü havuzu vardır. Düğüm havuzları için işlem seçimi temel mimaridekiyle aynı kalır. Temel mimariden farklı olarak, her düğüm havuzu, işlem katmanları arasında ek bir ağ yalıtımı sınırı sağlamak için ayrılmış bir alt ağda bulunur.

PCI-DSS 3.2.1, pci iş yükünün işlemler ve bağlantı açısından diğer iş yüklerinden yalıt olmasını gerektirir.

• Kapsam içi: PCI iş yükü, bulunduğu ortam ve işlemler.

• Kapsam dışı: Hizmetleri paylaşabilen ancak kapsam içi bileşenlerden yalıtılmış olan diğer iş yükleri.

Temel strateji, gerekli ayırma düzeyini sağlamaktır. Tercih edilen yol, kapsam içi ve kapsam dışı bileşenleri ayrı kümelere dağıtmaktır. Birden çok küme kullanmanın dezavantajı, eklenen altyapı için daha yüksek maliyetler ve bakım ek yüküdür. Bu uygulama, basitlik için paylaşılan bir kümedeki tüm bileşenleri birlikte bulur. Tek kümeli modeli izlemeyi seçerseniz, sıkı bir küme içi segmentasyon stratejisi kullanın. Ayrımı nasıl sürdürmeyi seçerseniz seçin, çözümünüz geliştikçe bazı kapsam dışı bileşenlerin kapsam dışı hale gelebileceğini unutmayın.

Başvuru uygulamasında, bir mikro hizmet uygulamasını tek bir kümeye dağıtarak paylaşılan küme yaklaşımını gösteriyoruz. Kapsam içi ve kapsam dışı iş yükleri iki ayrı kullanıcı düğümü havuzunda segmentlere ayrılır. Uygulamanın iki hizmet kümesi vardır; Bir kümenin kapsam içi podları vardır ve diğeri kapsam dışıdır. Her iki küme de iki kullanıcı düğümü havuzuna yayılır. Kubernetes taint'leri kullanılarak kapsam içi ve kapsam dışı podlar ayrı düğümlere dağıtılır ve hiçbir zaman bir düğüm VM'sini veya ağ IP alanını paylaşmaz.

Giriş denetleyicisi

Temel mimaride giriş denetimi için Traefik kullanılmıştır. Bu başvuru mimarisinde bunun yerine Nginx kullanıyoruz. Bu değişiklik, iş yüklerinizin gereksinimlerine göre bu bileşenin değiştirilebileceğini gösterir.

Özel Kubernetes API sunucusu

Temel mimari AKS kümesini genel modda dağıttı. Bu, AKS tarafından yönetilen Kubernetes API sunucusuyla tüm iletişimin genel İnternet üzerinden olduğu anlamına gelir. PCI-DSS 3.2.1 tüm sistem bileşenlerinin genel kullanıma açık olmasını yasakladığı için bu mimaride bu kabul edilemez. Bu düzenlemeye tabi mimaride, küme özel küme olarak dağıtılır. Kubernetes API sunucusuna yönelik ağ trafiği özel ağınızla sınırlıdır. API sunucusu, kümenin ağındaki özel bir uç nokta aracılığıyla kullanıma sunulur. Güvenlik, ağ güvenlik gruplarının ve diğer yerleşik özelliklerin kullanımıyla daha da gelişmiştir. Bunlar Ağ yapılandırması bölümünde açıklanmıştır.

Pod güvenliği

İş yükünüzün güvenlik gereksinimlerini açıklarken kapsayıcılarınız için ilgili securityContext ayarları kullanın. Bu, ,runAsGrouprunAsUser / ve gibi fsGrouptemel ayarları içerir ve false olarak ayarlanır allowPrivilegeEscalation (gerekli değilse). Linux özelliklerini tanımlama ve kaldırma ve SELinux seçeneklerinizi içinde seLinuxOptionstanımlama konusunda net olun.

Dağıtım bildirimlerinizde resimleri etiketlerine başvurmaktan kaçının. Bunun yerine gerçek görüntü kimliğini kullanın. Bu şekilde, kapsayıcı tarama sonuçlarını kümenizde çalışan gerçek içerikle güvenilir bir şekilde eşleyebilirsiniz. İzin verilen normal ifadeye görüntü kimliği desenini eklemek üzere görüntü adı için Azure İlkesi uygulayabilirsiniz. Dockerfile FROM yönergesini kullanırken de bu yönergeleri izleyin.

Ağ yapılandırması

Merkez-uçların tümü, her biri kendi özel adres alanında bulunan ayrı sanal ağlara dağıtılır. Varsayılan olarak, iki sanal ağ arasında trafiğe izin verilmez. Ağ içinde, alt ağlar oluşturularak segmentlere ayırma uygulanır.

Çeşitli Azure hizmet ve özelliklerinin ve yerel Kubernetes yapılarının birleşimi, gerekli denetim düzeyini sağlar. Bu mimaride kullanılan bazı seçenekler aşağıdadır.

Ağ güvenlik grupları (NSG) aracılığıyla alt ağ güvenliği

Kümenin içindeki ve çıkışındaki akışı denetleyebilen birkaç NSG vardır. Burada bazı örnekler verilmiştir:

• Küme düğümü havuzları ayrılmış alt ağlara yerleştirilir. Her alt ağ için düğüm VM'lerine SSH erişimini engelleyen ve sanal ağdan gelen trafiğe izin veren NSG'ler vardır. Düğüm havuzlarından gelen trafik sanal ağ ile sınırlıdır.

• İnternet'ten gelen tüm trafik Azure Uygulaması lication Gateway tarafından kesiliyor. Örneğin, NSG kuralları aşağıdakilerden emin olun:

  • Yalnızca HTTPS trafiğine izin verilir.
  • Hizmet etiketleri kullanılarak Azure denetim düzleminden gelen trafiğe izin verilir. Daha fazla bilgi için bkz . Birkaç kaynak IP'ye erişime izin verme.

• Azure Container Registry aracılarına sahip alt ağlarda NSG'ler yalnızca gerekli giden trafiğe izin verir. Örneğin Azure Key Vault, Microsoft Entra ID, Azure İzleyici ve kapsayıcı kayıt defterinin konuşması gereken diğer hizmetlere trafiğe izin verilir.

• Atlama kutusuna sahip alt ağ yönetim işlemlerine yöneliktir. Atlama kutusu alt ağındaki NSG kuralı yalnızca merkezdeki Azure Bastion'dan SSH erişimine ve sınırlı giden bağlantılara izin verir. Atlama kutuları evrensel İnternet erişimine sahip değildir ve hem alt ağ NSG'sinde hem de Azure Güvenlik Duvarı denetlenmektedir.

İş yükleriniz, sistem güvenlik aracılarınız ve diğer bileşenler dağıtılırken, izin verilmesi gereken trafik türünü tanımlamaya yardımcı olan daha fazla NSG kuralı ekleyin. Trafik bu alt ağ sınırlardan geçmemelidir. Her düğüm havuzu kendi alt ağından oluştuğundan, trafik desenlerini gözlemleyin ve daha belirli kurallar uygulayın.

Ağ ilkeleriyle poddan poda güvenlik

Bu mimari, Microsoft'un "sıfır güven" ilkelerini mümkün olduğunca uygulamaya çalışır.

Kavram olarak sıfır güven ağları örnekleri, ve a0005-o kullanıcı tarafından sağlanan ad alanları içinde uygulamada a0005-i gösterilmiştir. Her iş yükü ad alanında kısıtlayıcı bir NetworkPolicy uygulanmalıdır. İlke tanımları, bu ad alanında çalışan podlara bağlıdır. Hazır olma, canlılık ve başlangıç yoklamalarını hesapladığınızdan emin olun ve Log Analytics aracısı tarafından toplanan ölçümlere izin verin. İzin verilen kapsayıcı bağlantı noktaları için tutarlı bir NetworkPolicy ve Azure İlkesi sağlayabilmeniz için iş yükleriniz genelindeki bağlantı noktalarını standartlaştırmayı göz önünde bulundurun.

Bazı durumlarda bu, küme içindeki iletişim için pratik değildir. Kullanıcı tarafından sağlanan tüm ad alanları sıfır güven ağı kullanamaz (örneğin, cluster-baseline-settings bir tane kullanamaz).

TLS şifrelemesi

Temel mimari, kümedeki giriş denetleyicisine kadar TLS ile şifrelenmiş trafik sağlar, ancak poddan poda iletişim nettir. Bu mimaride TLS, Sertifika Yetkilisi (CA) doğrulamasıyla podlar arası trafiğe genişletir. Bu TLS, iletişime izin vermeden önce mTLS bağlantılarını ve doğrulamayı zorlayan bir hizmet ağı tarafından sağlanır.

Uygulama mTLS kullanır. mTLS desteği hizmet ağıyla veya hizmet ağı olmadan uygulanabilir. Mesh kullanıyorsanız, bunun seçtiğiniz sertifika verenle uyumlu olduğundan emin olun. Bu uygulama Open Service Mesh kullanır.

Bu uygulamadaki giriş denetleyicisi, giriş kaynağı belirli bir sertifika içermediğinde varsayılan trafiği işlemek için joker sertifika kullanır. Bu kabul edilebilir olabilir, ancak kuruluş ilkeniz joker karakter sertifikalarının kullanılmasına izin vermiyorsa giriş denetleyicinizi joker karakter sertifikası kullanmayacak şekilde ayarlamanız gerekebilir.

Azure Key Vault ağ kısıtlamaları

Tüm gizli diziler, anahtarlar ve sertifikalar Azure Key Vault'ta depolanır. Key Vault, döndürme gibi sertifika yönetimi görevlerini işler. Key Vault ile iletişim Azure Özel Bağlantı bitti. Key Vault ile ilişkili DNS kaydı, İnternet'ten çözümlenememeleri için özel bir DNS bölgesindedir. Bu, güvenliği iyileştirse de bazı kısıtlamalar vardır.

Azure Uygulaması lication Gateway, Özel Bağlantı ile kullanıma sunulan Key Vault örneklerinden HTTP dinleyicisi için TLS sertifikalarının kaynağını belirlemeyi desteklemez. Bu nedenle, uygulama Key Vault'ı karma modelde dağıtır. Yine de onu destekleyen bağlantılar için Özel Bağlantı kullanır, ancak Application Gateway tümleştirmesi için genel erişime de izin verir. Bu karma yaklaşım dağıtımınız için uygun değilse, sertifika yönetimi işlemini Application Gateway'e taşıyın. Bu işlem yönetim yükü ekler, ancak ardından Key Vault örneği tamamen yalıtılır. Bilgi için bkz:

• Azure Uygulaması Lication Gateway ve Key Vault tümleştirmesi
• Azure CLI kullanarak TLS sonlandırması ile bir uygulama ağ geçidi oluşturun.

DDoS koruması

Genel IP adreslerine sahip sanal ağlarınız varsa Azure DDoS Ağ Koruması'nı etkinleştirin. Bu başvuru mimarisinde Application Gateway içeren alt ağın bir genel IP adresi eklenmiştir, bu nedenle DDoS koruması kapsamındadır.

Azure DDoS Ağ Koruması, altyapıyı ve iş yükünü toplu sahte isteklere karşı korur. Bu tür istekler hizmet kesintisine neden olabilir veya başka bir eşzamanlı saldırıyı maskeleyebilir. Azure DDoS Ağ Koruması önemli bir maliyetle gelir ve genellikle birçok IP adresine yayılan birçok iş yükünde amorti edilir. İş yüklerinizin kapsamını koordine etmek için ağ ekibinizle birlikte çalışın.

Kimlik ve erişim yönetimi

Rolleri tanımlayın ve rolün gereksinimlerine göre erişim denetimi ayarlayın. Rolleri, kapsamı dar kapsamlı kubernetes eylemleriyle eşleyin. Birden çok işleve yayılan rollerden kaçının. Birden çok rol bir kişi tarafından doldurulmuşsa, bu kişiye eşdeğer iş işlevleriyle ilgili tüm rolleri atayın. Bu nedenle, bir kişi hem kümeden hem de iş yükünden doğrudan sorumlu olsa bile, kubernetes'inizi ClusterRoleayrı bireyler varmış gibi oluşturun. Ardından bu tek tek tek tüm ilgili rolleri atayın.

Özellikle kümenizle SRE/Ops etkileşimleri gibi yüksek etkili hesaplar için ayakta erişimi en aza indirin. AKS denetim düzlemi hem Microsoft Entra ID Privileged Access Management (PAM) tam zamanında (JIT) hem de oluşturduğunuz kurallara bağlı olarak ayrıcalıklı erişim için gerekli kimlik doğrulaması doğrulamasının ek katmanlarını sağlayan Koşullu Erişim İlkeleri'ni destekler.

Koşullu erişimi yapılandırmak için PowerShell kullanma hakkında daha fazla ayrıntı için bkz . New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy ve Remove-MgIdentityConditionalAccessPolicy.

Disk şifrelemesi

Bekleyen veriler için şifreleme tasarlarken depolama disklerini, AKS aracı düğümü VM'lerini, diğer VM'leri ve geçici ve işletim sistemi disklerini göz önünde bulundurun.

Depolama diskleri

Azure Depolama diskleri varsayılan olarak Microsoft tarafından yönetilen anahtarlarla şifrelenir. Kısa ömürlü olmayan işletim sistemi diskleri kullanıyorsanız veya veri diskleri ekliyorsanız, şifreleme anahtarları üzerinde denetim için müşteri tarafından yönetilen anahtarlar kullanmanızı öneririz. Depolama katmanının dışında şifreleyin ve yalnızca şifrelenmiş verileri depolama ortamına yazın. Ayrıca anahtarların hiçbir zaman depolama katmanına bitişik olmadığından emin olun. Daha fazla bilgi için bkz . Azure diskleriyle kendi anahtarlarınızı getirme (BYOK).

Azure Bastion ön atlama kutuları gibi kümeyle etkileşim kurabilecek diğer tüm diskler için KAG kullanmayı göz önünde bulundurun. KAG'yi seçerseniz, bu özellik tüm SKU'larda veya bölgelerde desteklenmediğinden VM'ler ve bölgesel kullanılabilirlik için SKU seçimi sınırlı olacaktır.

VM konakları

Konakta şifreleme özelliğini etkinleştirmenizi öneririz. Bu işlem VM ana bilgisayarını ve herhangi bir geçici işletim sistemini veya bir VM ana bilgisayarında önbelleğe alınan veri disklerini şifreler. Konak tabanlı şifreleme için VM desteği hakkında daha fazla bilgi edinin.

Bu özellik, Konak Tabanlı Şifreleme özelliği aracılığıyla AKS aracı düğümlerinizin VM ana bilgisayarında depolanan verilere genişletilir. BYOK'a benzer şekilde, bu özellik VM SKU'nuzu ve bölge seçimlerinizi sınırlayabilir.

Bu özellikleri Azure İlkesi aracılığıyla zorunlu kılabilirsiniz.

Küme yedeklemeleri (durum ve kaynaklar)

İş yükünüz küme içi depolama gerektiriyorsa, yedekleme ve kurtarma için sağlam ve güvenli bir işleme sahip olun. Herhangi bir PersistentVolumeClaimyedekleme ve kurtarma için Azure Backup (Azure Diskler ve Azure Dosyalar için) gibi hizmetleri göz önünde bulundurun. Yedekleme sistemi yerel Kubernetes kaynaklarını destekliyorsa bunun avantajları vardır. Kritik sistem kurtarma teknikleri için yedekleme sistemiyle kümeyi iyi bilinen bir duruma mutabık hale getiren birincil yönteminizi tamamlayabilirsiniz. Örneğin, zaman içinde Kubernetes kaynak düzeyinde kayma algılama ve katalog sistem durumu değişikliklerini kataloglama konusunda yardımcı olabilir.

Yedekleme işlemlerinin, verilerin kümeden mi geldiği yoksa küme dışında mı olduğu fark etmeksizin yedeklemedeki verileri sınıflandırması gerekir. Veriler PCI DSS 3.2.1 kapsamındaysa, uyumluluk sınırlarınızı kümenin dışında olacak yedeklemenin yaşam döngüsünü ve hedefini içerecek şekilde genişletin. Yedeklemeler bir saldırı vektöru olabilir. Yedeklemenizi tasarlarken coğrafi kısıtlamaları, bekleyen şifrelemeyi, erişim denetimlerini, rolleri ve sorumlulukları, denetimi, yaşam süresini ve kurcalamayı önlemeyi göz önünde bulundurun.

Küme içi yedekleme sistemlerinin işlemleri sırasında yüksek ayrıcalıklarla çalıştırılması beklenir. Bir yedekleme aracısını kümenize getirme riskini ve avantajını değerlendirin. Aracı özelliği kümedeki başka bir yönetim çözümüyle çakışıyor mu? Saldırı yüzeyini genişletmeden bu görevi gerçekleştirmek için ihtiyacınız olan en düşük araç kümesi nedir?

Azure İlkesi dikkat edilmesi gerekenler

Genellikle uygulanan Azure ilkeleri iş yükü tarafından ayarlanmış ayarlara sahip değildir. Uygulamada, yerleşik ilke girişimlerinden biri olan Linux tabanlı iş yükleri girişimi için Kubernetes küme pod güvenliği kısıtlanmış standartlarını uyguluyoruz. Bu girişim ayarların ayarlanmasına izin vermez. Bu girişimi dışarı aktarmayı ve kendi iş yükünüz için değerlerini özelleştirmeyi göz önünde bulundurun. Tüm Ağ Geçidi Denetleyicisi deny Azure ilkelerini bir özel girişime, tüm audit Azure ilkelerini ise başka bir girişime dahil edebilirsiniz. Bunun yapılması, blok eylemlerini yalnızca bilgi ilkelerine göre kategorilere ayırır.

Daha fazla görünürlük için denetim ilkelerinize ve gatekeeper-system ad alanlarını ilkelere eklemeyi kube-system göz önünde bulundurun. Bu ad alanlarını reddetme ilkelerine dahil etmek, desteklenmeyen bir yapılandırma nedeniyle küme hatasına neden olabilir.

Bazı Azure İlkesi uyarıları ayarlayarak veri şifrelemeyi zorunlu kılabilirsiniz. Örneğin, KAG'yi, küme kaynağında olmayan diskEncryptionSetID kümeleri algılayan bir uyarıyla zorlayabilirsiniz. Başka bir ilke, üzerinde agentPoolProfilesKonak Tabanlı Şifreleme'nin etkinleştirilip etkinleştirilmediğini algılayabilir. Başvuru uygulaması kümede disk kullanmaz ve işletim sistemi diski kısa ömürlüdür. Bu örnek ilkelerin her ikisi de güvenlik özelliğinin anımsatıcısı olarak kullanılır. İlkeler auditolarak blockdeğil olarak ayarlanır.

Görüntüleri yönetme

İş yükleriniz için dağıtımsız temel görüntüler kullanın. Bu görüntülerle, kabuklar ve paket yöneticileri gibi ek görüntüler kaldırıldığından güvenlik yüzeyi alanı en aza indirilir. Bir avantaj, CVE isabet oranlarını düşürür.

Azure Container Registry, Open Container Initiative (OCI) Görüntü Biçimi Belirtimini karşılayan görüntüleri destekler. Bu, imzaları doğrulamayı destekleyen bir erişim denetleyicisiyle birleştiğinde, yalnızca özel anahtarlarınızla imzaladığınız görüntüleri çalıştırdığınızdan emin olabilirsiniz. Bu süreçleri tümleştirmeye yönelik SSE Connaisseur veya IBM Portieris gibi açık kaynaklı çözümler vardır.

Kapsayıcı görüntülerini ve diğer OCI yapıtlarını, kuruluşun fikri mülkiyetini içerdiğinden koruyun. Müşteri tarafından yönetilen anahtarları kullanın ve kayıt defterlerinizin içeriğini şifreleyin. Varsayılan olarak, bekleyen veriler hizmet tarafından yönetilen anahtarlarla şifrelenir, ancak bazen yasal uyumluluk standartlarını karşılamak için müşteri tarafından yönetilen anahtarlar gerekir. Anahtarı Azure Key Vault gibi yönetilen bir anahtar deposunda depolayın. Anahtarı oluşturup sahip olduğunuz için, döndürme ve yönetim de dahil olmak üzere anahtar yaşam döngüsüyle ilgili işlemlerde siz sorumlu olursunuz. Daha fazla bilgi için bkz . Müşteri tarafından yönetilen anahtar kullanarak kayıt defterini şifreleme.

Kubernetes API Sunucusu işletimsel erişimi

Atlama kutularını temel alan bir işlem işlemi oluşturmadan kümede yürütülen komutları sınırlayabilirsiniz. IAM geçitli bir BT otomasyon platformunu kullanıyorsanız, eylemlerin türünü denetlemek ve denetlemek için önceden tanımlanmış eylemleri kullanın.

Derleme aracıları

derleme işlemleri tehdit vektörleri olabileceğinden, işlem hattı aracıları düzenlenmiş küme için kapsam dışında olmalıdır. Örneğin, derleme işlemleri genellikle test edilmemiş ve güvenilmeyen bileşenlerle çalışır.

Kubernetes'in elastik derleme aracısı altyapısı olarak kullanılması yaygın olsa da, bu işlemi düzenlenen iş yükü çalışma zamanı sınırı içinde çalıştırmayın. Derleme aracılarınızın kümeye doğrudan erişimi olmamalıdır. Örneğin, kapsayıcı görüntülerini, helm grafiklerini vb. göndermek için yalnızca derleme aracılarına Azure Container Registry'ye ağ erişimi verin. Ardından GitOps aracılığıyla dağıtın. Yaygın bir uygulama olarak derleme ve yayın iş akışlarının Kubernetes Küme API'nize (veya düğümlerine) doğrudan erişimi olmamalıdır.

İzleme işlemleri

Küme içi etkinlikler

içinde çalışan kube-system küme omsagent içi podlar Log Analytics koleksiyon aracısıdır. Telemetri toplar, kapsayıcı stdout ve stderr günlükleri kazır ve Prometheus ölçümlerini toplar. ConfigMap dosyasını güncelleştirerek container-azm-ms-agentconfig.yaml koleksiyon ayarlarını ayarlayabilirsiniz. Bu başvuru uygulamasında, günlüğe kaydetme tüm iş yükleriniz arasında kube-system etkinleştirilir. Varsayılan olarak, kube-system günlük kaydı dışında tutulur. Günlükleri gözden geçirirken maliyet hedeflerini, SRE verimliliğini ve uyumluluk gereksinimlerini dengelemek için günlük toplama işlemini ayarladığınızdan emin olun.

Güvenlik izleme

Güvenlik önerilerini görüntülemek ve düzeltmek ve kapsayıcı kaynaklarınızdaki güvenlik uyarılarını görüntülemek için Bulut için Microsoft Defender Kapsayıcılar için Defender'ı kullanın. Microsoft Defender planlarını, kart sahibi veri ortamının çeşitli bileşenlerine uygulandığından etkinleştirin.

Verileri verimli bir şekilde gözden geçirebilmeniz, analiz edebilmeniz ve sorgulayabilmeniz için günlükleri tümleştirin. Azure çeşitli seçenekler sunar. AKS tanılama günlüklerini açıp Azure İzleyici'nin parçası olan bir Log Analytics çalışma alanına gönderebilirsiniz. Bir diğer seçenek de verileri Microsoft Sentinel gibi güvenlik bilgileri ve olay yönetimi (SIEM) çözümleriyle tümleştirmektir.

Standart gereği tüm Log Analytics çalışma alanları 90 günlük saklama süresine ayarlanır. Uzun süreli depolama için sürekli dışarı aktarmayı ayarlamayı göz önünde bulundurun. Hassas bilgileri günlük verilerinde depolamayın ve arşivlenmiş günlük verilerine erişimin son günlük verileriyle aynı erişim denetim düzeylerine tabi olduğundan emin olun.

Tam bir bakış açısı için bkz. kurumsal ekleme kılavuzu Bulut için Microsoft Defender. Bu kılavuz kayıt, SIEM çözümlerinize veri dışarı aktarma, uyarılara yanıt verme ve iş akışı otomasyonu oluşturma konularını ele alır.

İlgili Azure Hizmetleri

Bu mimarinin bazı önemli bileşenlerinin özellik belgelerinin bağlantıları aşağıdadır.

• Azure Kubernetes Service (AKS)
• Azure Güvenlik Duvarı
• Azure Bastion
• Azure Görüntü Oluşturucusu
• Azure Sanal Makine Ölçek Kümeleri
• Tümleşik Web Uygulaması Güvenlik Duvarı (WAF) ile Azure Uygulaması Lication Gateway
• Azure Container Registry görevleri
• Azure Key Vault

Sonraki adımlar

Kart sahibi verilerini korumak için bir güvenlik duvarı yapılandırması yükleyin ve koruyun. Sistem parolaları ve diğer güvenlik parametreleri için satıcı tarafından sağlanan varsayılan değerleri kullanmayın.