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

Bu makalede, Ödeme Kartı Sektörü 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çıklanmıştır. Bu mimari, PCI-DSS 3.2.1 iş yüküne değil altyapıya odaklanmaktadır.

Bu makale, bir serinin bir parçasıdır. Giriş makalelerini okuyun.

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

GitHub: Azure Kubernetes Service (AKS) Temel Kümesi, düzenlenen altyapıyı gösterir. Bu uygulama bir mikro hizmet uygulaması sağlar. Altyapıyı deneyimlerken ağ ve güvenlik denetimlerini gösterirken size yardımcı olmak için dahil edilir. Uygulama, gerçek bir iş yükünü temsil PCI DSS uygulamaz.

Bu ağ mimarisi, merkez-bağlı-bağlı topolojiyi temel almaktadır. Merkez sanal ağı çıkış trafiğini, şirket içi ağlardan gelen ağ geçidi trafiğini ve SRE kümesi erişimi için üçüncü bir ağı denetlemeye uygun güvenlik duvarını içerir. İki ağlı sanal ağ vardır. Bir bağlı bileşen, kart tutucu ortamının (CDE) bir bileşeni olan AKS kümesi içerir ve iş yükünün PCI DSS barındırmaktadır. Diğer bağlı sunucu, ortama denetimli SRE erişimi için kullanılan sanal makine görüntüleri derlemek için kullanılır.

Bileşenler

Bu mimaride kullanılan ana bileşenler aşağıdaki gibidir. Bu hizmetler hakkında bilginiz yoksa, ürün belgelerinin bağlantıları için İlgili Azure hizmetleri'ne 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 silen kötü amaçlı bir üçüncü taraf hizmetiyle iletişim kurabilir.

Azure Bastion

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

Azure Görüntü Oluşturucusu

Ayrı bir sanal ağ içinde sağlandı. Temel güvenlik ve yapılandırma ile VM görüntüleri oluşturur. Bu mimaride, Azure CLI, ve Flux CLI gibi yönetim araçlarıyla önceden yüklenmiş güvenli düğüm kubectl görüntüleri oluşturmak için özelleştirilebilir.

Sıçrama kutusu örnekleri için Azure Sanal Makine Ölçek Kümeleri

Bağlı ağın atlama kutusu için ek işlem vardır. Bu ölçek kümesi, gerektiğinde AKS kümesine karşı araçları çalıştırmak için yönetilen erişim noktası olarak kubectl tasarlanmıştır.

Azure Application Gateway Web Uygulaması Güvenlik Duvarı (WAF) ile çalışma

Azure Application Gateway 7. Katman'da yük dengelemeleri. WAF, gelen trafiği yaygın web trafiği saldırılarından korur. Örnekte 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 açık değildir ve API sunucusuna gelen trafik özel ağınız ile sınırlıdır.

ACR Görevleri

Kapsayıcı görüntülerinin otomatik bir şekilde inşa ve bakımının gerçekleştirilmiş 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 mimaride yapılan bazı önemli değişiklikler:

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 aynı kalır. 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şlem ve bağlantı açısından diğer iş yüklerinden yalıt gerektirir.

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

• Kapsam dışında: Hizmetleri paylaşsa da kapsam içinde 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çinde ve kapsam dışında bileşenleri ayrı kümelere dağıtmaktır. Alt taraf, eklenen altyapı ve bakım ek yükü için maliyetlerin artmasıdır. Bu uygulama, kolaylık sağlamak için paylaşılan kümede yer alan tüm bileşenleri birlikte bulunduracak. Bu modeli izlemeyi seçerseniz, sıkı bir küme içinde 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ışında bileşenlerin kapsam içinde olabileceğinin farkında olma.

Başvuru uygulamasında ikinci yaklaşım, tek bir kümeye dağıtılan bir mikro hizmet uygulamasıyla gösterildi. Kapsam içinde ve kapsam dışında iş yükleri iki ayrı kullanıcı düğümü havuzu halinde kesimli olarak kesimlidir. Uygulamada iki hizmet kümesi vardır; Kümelerden biri kapsam içinde podlara, diğeri ise kapsam dışındadır. Her iki küme de iki kullanıcı düğümü havuzu arasında yayılır. Kubernetes düğümlerinin kullanımıyla, kapsam içinde ve kapsam dışında podlar ayrı düğümlere dağıtılır ve hiçbir zaman bir düğüm VM'sini veya ağ IP'sini paylaşmaz.

Giriş denetleyicisi

Küme içindeki Kubernetes giriş denetleyicisi NGINX olarak değiştirildi. Temel mimaride Traefik kullanılmıştır. Bu değişiklik, bu bileşenin iş yüklerinin gereksinimlerine göre değiştirildiğini gösterir.

Özel Kubernetes API sunucusu

Temel mimari AKS kümesi genel modda dağıtıldı. 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 herhangi bir sistem bileşenine genel olarak açıklanması yasak olduğundan bu mimaride bu kabul edilebilir değildir. Düzenlenen bu mimaride, küme özel küme olarak dağıtılır. Kubernetes API sunucusuna gelen ağ trafiği özel ağınız ile sınırlıdır. API sunucusu, kümenin ağının özel bir uç noktası aracılığıyla açığa çıkar. Güvenlik, ağ güvenlik gruplarının ve diğer yerleşik özelliklerin kullanımıyla daha da geliştirildi. Bunlar Ağ yapılandırması altında açıklanmıştır.

Pod güvenliği

İş yüklerinin güvenlik ihtiyaçlarını açıklarken kapsayıcılar için securityContext ilgili ayarları kullanın. Buna , ve ayarı false fsGrouprunAsUser / runAsGroup (gerekli olmadığı sürece) allowPrivilegeEscalation gibi temel ayarlar dahildir. Linux özelliklerini tanımlayarak kaldırmayı ve içinde SELinux seçeneklerinizi tanımlamayı net bir şekilde açık seLinuxOptions kullanın.

Dağıtım bildirimleriniz içinde görüntülere etiketleriyle 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ümeniz içinde çalışan gerçek içerikle güvenilir bir şekilde eşlersiniz. İzin verilen normal ifadeye Azure İlkesi kimliği desenini eklemek için görüntü adını kullanarak bunu zorabilirsiniz. Dockerfile yönergesi kullanırken de bu kılavuzu FROM izleyin.

Ağ yapılandırması

Merkez-spoke'ların hepsi ayrı sanal ağlarda dağıtılır ve her biri kendi özel adres alanlarına dağıtılır. Varsayılan olarak, iki sanal ağ arasında trafiğe izin verilmez. Ağ içinde, kesimleme alt ağlar oluşturarak uygulanır.

Çeşitli Azure hizmetleri ve özellikleri ve yerel Kubernetes yapılarının bir birleşimi gerekli denetim düzeyini sağlar. Bu mimaride kullanılan bazı seçenekler aşağıda verilmiştir.

Ağ güvenlik grupları (NSG 'ler) ile alt ağ güvenliği

Kümenin içinde ve dışında akışı denetleyen birkaç NSG vardır. İşte bazı örnekler:

• 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ğla kısıtlıdır.

• İnternet 'ten gelen tüm trafik Azure Application Gateway tarafından ele geçirilebilir. Örneğin, NSG kuralları şunları unutmayın:

  • İçinde yalnızca HTTPS trafiğine izin verilir.
  • Azure denetim düzleminin trafiğine izin verilir. Daha fazla bilgi için bkz. birkaç kaynak IP 'ye erişime Izin verme.

• Azure Container Registry aracıları olan alt ağlarda, NSG 'ler yalnızca gerekli giden trafiğe izin verir. örneğin, trafiğin Azure Key Vault, Azure Active Directory, Azure izleyici ve kapsayıcı kayıt defterinin konuştuğu diğer hizmetlere erişmesine izin verilir.

• Sıçrama kutusuyla alt ağ yönetim işlemlerine yöneliktir. NSG kuralı yalnızca Hub 'daki Azure üzerinden SSH erişimine ve sınırlı giden bağlantılara izin verir. Geçiş kutuları, evrensel internet erişimine sahip değildir ve hem alt ağ NSG hem de Azure Güvenlik Duvarı 'nda denetlenir.

İş yükleriniz, sistem güvenlik aracılarınız ve diğer bileşenler dağıtıldığında, izin verilmesi gereken trafik türünü tanımlamaya yardımcı olan daha fazla NSG kuralı ekleyin. Trafik, bu alt ağ sınırlarının dışına geçememelidir. Her düğüm havuzu kendi alt ağında bulunduğundan, trafik desenlerini gözlemleyin ve daha özel kurallar uygulayın.

Ağ ilkeleriyle Pod-Pod güvenliği

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

Bir kavram olarak sıfır güveni olan ağların örnekleri, içindeki uygulamada a0005-i ve a0005-o Kullanıcı tarafından sağlanmış ad alanlarında gösterilmiştir. Tüm iş yükü ad alanlarında kısıtlayıcı NetworkPolicy uygulanmış olmalıdır. İlke tanımları, bu ad alanlarında çalışan yığınlara bağlı olacaktır. Hazır olma, belirsizlik ve başlangıç araştırmaları ve ayrıca Log Analytics Aracısı tarafından toplanan ölçümler için de kesinti için hesap yaptığınızdan emin olun. İzin verilen kapsayıcı bağlantı noktaları için tutarlı bir NetworkPolicy ve Azure Ilkesi sağlayabilmeniz için iş yüklerinizde bağlantı noktalarında standartlaştırın.

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

TLS şifreleme

Taban çizgisi mimarisi, kümedeki giriş denetleyicisine kadar TLS şifreli trafik sağlar, ancak Pod 'den Pod 'e iletişim açık olur. Bu mimaride, TLS, sertifika yetkilisi (CA) doğrulaması ile pods 'den Pod 'a kadar trafiğe genişletilir. 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ğı ile veya olmayan bir şekilde uygulanabilir. Bir ağ kullanıyorsanız, tercih ettiğiniz sertifika verenle uyumlu olduğundan emin olun. Bu uygulama açık hizmet ağıkullanır.

Bu uygulamadaki giriş denetleyicisi, bir giriş kaynağı belirli bir sertifika içermiyorsa varsayılan trafiği işlemek için joker bir sertifika kullanır. Bu kabul edilebilir olabilir, ancak kuruluş ilkeniz joker karakter sertifikaları kullanmaya izin vermezse, giriş denetleyicinizi joker bir sertifika kullanmadan ayarlamanız gerekebilir.

Azure Key Vault ağ kısıtlamaları

Tüm gizlilikler, anahtarlar ve sertifikalar Azure Key Vault depolanır. Key Vault, döndürme gibi sertifika yönetimi görevlerini işler. Key Vault ile iletişim Azure özel bağlantısı üzerinden yapılır. Key Vault ilişkili DNS kaydı, internet 'ten çözümlenememesi için özel bir DNS bölgesidir. Bu, güvenliği iyileştirirken bazı kısıtlamalar vardır.

Azure Application Gateway, özel bağlantıyla birlikte sunulan Key Vault örneklerden HTTP dinleyicisi için TLS sertifikalarının kaynağını desteklemez. Bu nedenle, uygulama karma modelde Key Vault dağıtır. Hala onu destekleyen bağlantılar için özel bağlantı kullanır, ancak Application Gateway tümleştirme 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 taşıyın. Bu, yönetim ek yükü ekleyecek, ancak Key Vault örnek tamamen yalıtılacaktır. Daha fazla bilgi için, bkz:

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

DDoS koruması

Ortak IP ile Application Gateway içeren bir alt ağa sahip sanal ağlar için Azure DDoS koruma standardı 'nı etkinleştirin. Bunun yapılması, altyapı ve iş yükünü yığın sahte isteklerden korur. Bu tür istekler hizmet kesintilerine neden olabilir veya başka bir eşzamanlı saldırı maskeleyebilir. Azure DDoS önemli bir maliyetle gelir ve genellikle birçok IP adresini kapsayan çok sayıda iş yüküne göre yapılır. İş yükünüzün kapsamını koordine etmek için ağ ekibinizle birlikte çalışın.

Kimlik erişim yönetimi

Rolleri tanımlayın ve erişim ilkelerini rolün gereksinimlerine göre ayarlayın. Rolleri, pratik olarak en dar olacak şekilde, Kubernetes eylemlerine eşleyin. Birden çok işlevi kapsayan rollerden kaçının. Birden çok rol bir kişi tarafından doldurulduysa, bu kişiye eşdeğer iş işlevleriyle ilgili tüm rolleri atayın. Bu nedenle, bir kişi doğrudan hem küme hem de iş yüküyle sorumlu olsa da, Kubernetes 'i ClusterRoles ayrı bireyler gibi bir şekilde oluşturun. Ardından bu tek bireyi ilgili tüm rolleri atayın.

Özellikle, kümenizle ilgili SRE/Ops etkileşimleri gibi yüksek etkili hesaplar için, özellikle de oluşan erişimi en aza indirin. AKS denetim düzlemi hem Azure AD Privileged Access Management (Pam) tam zamanında (JIT)destekler. Koşullu erişim ilkeleri , oluşturduğunuz kurallara göre ayrıcalıklı erişim için gerekli kimlik doğrulama doğrulamasının ek katmanlarını sağlayabilir.

Koşullu erişimi yapılandırmak üzere PowerShell kullanma hakkında daha fazla bilgi için bkz. Azure AD koşullu erişim.

Disk şifrelemesi

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

Depolama diskler

varsayılan olarak, Azure Depolama diskleri, Microsoft tarafından yönetilen anahtarlarla rest 'te şifrelenir. Kısa ömürlü işletim sistemi diskleri kullanıyorsanız veya veri diskleri eklerseniz, ş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 şifreli verileri depolama ortamına yazar. Ayrıca, anahtarların depolama katmanına hiçbir şekilde bitişik olmadığından emin olun.

daha fazla bilgi için bkz. Azure diskleriyle kendi anahtarlarınızı Bing (byok).

Azure onay kutuları gibi, kümeyle etkileşime girebilen diğer diskler için BYOK kullanmayı düşünün. BYOK ' u 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ırlandırılacaktır.

VM Konakları

Konakta şifreleme özelliğini etkinleştirmenizi öneririz. Bu, VM konağını ve tüm geçici işletim sistemlerini veya bir VM konağında önbelleğe alınmış veri disklerini şifreler. Konak tabanlı şifreleme Için VM desteğihakkında daha fazla bilgi edinin.

Bu özellik, ana bilgisayar tabanlı şifreleme özelliği aracılığıyla aks Aracısı DÜĞÜMLERINIZIN VM konağında depolanan verilere genişletilir. BYOK ile benzer şekilde, bu özellik VM SKU ve bölge seçimlerinizi sınırlayabilir.

Bu özellikleri Azure Ilkesi 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şlem yapın. Her birinin yedeklenmesi ve kurtarılması için Azure Backup (Azure diskleri ve Azure dosyaları için) gibi hizmetleri göz önünde bulundurun PersistantVolumeClaim . Yedekleme sistemi yerel Kubernetes kaynaklarını destekliyorsa bunun avantajları vardır. Kümeyi bilinen bir durumla uzlaştıran birincil yönteminizi, kritik sistem kurtarma teknikleri için yedekleme sistemiyle tamamabilirsiniz. Örneğin, Kubernetes kaynak düzeyinde zaman içinde sistem durumu değişikliklerini kataloglama ve kayma algılamada yardımcı olabilir.

Yedekleme işlemlerinin küme içindeki veya kümenin içindeki veya dışında yer alan verileri sınıflandırması gerekir. Veriler 3.2.1 PCI DSS kapsamında ise, kümenin dışında olacak yedeklemenin yaşam döngüsünü ve hedefini içerecek şekilde uyumluluk sınırlarınızı genişletin. Yedeklemeler bir saldırı vektörü olabilir. Yedeklemenizi tasarlarken coğrafi kısıtlamaları, beklemede şifrelemeyi, erişim denetimlerini, rol ve sorumlulukları, denetim, yaşam süresi ve kurcalama önlemeyi göz önünde bulundurabilirsiniz.

Küme içinde yedekleme sistemlerinin işlemleri sırasında yüksek ayrıcalıklarla çalışması beklenir. Kümenize yedekleme aracısı getirme riskini ve avantajını değerlendirin. Aracı özelliği kümede 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 minimum araç kümesi nedir?

Azure İlkesi önemli noktalar

Uygulanan Azure ilkeleri genellikle iş yükü tarafından ayarlanmış ayarlara sahip değildir. Uygulamada, Ayarların ayarlamasına izin vermeksizin Linux tabanlı iş yükleri girişimi için Kubernetes küme pod güvenliği kısıtlanmış standartlarını uyguluyoruz. Bu girişimi dışarı aktarmayı ve bu girişimin değerlerini iş yükünüz için özelleştirmeyi göz önünde bulundurarak. Tüm Gatekeeper Azure ilkelerini tek bir özel girişime ve tüm Azure ilkelerini deny başka bir audit girişime dahil edin. Bunu yapmak, blok eylemlerini yalnızca bilgi ilkelerine göre kategorilere ayırıyor.

Ek görünürlük için kube-systemgatekeeper-system denetim ilkelerinize ve ad kube-system dahil etmek düşünün. Bu ad alanlarını reddetme ilkelerine dahil etmek, desteklenmeyen bir yapılandırma nedeniyle küme hatasına neden olabilir.

Veri şifrelemeyi zorlamak için bazı uyarılarda Azure İlkesi kullanabilirsiniz. Örneğin, küme kaynağında yer alan kümeleri algılayan bir uyarı ile diskEncryptionSetID BYOK'u zorunlu hale ebilirsiniz. Başka bir ilke, üzerinde şifrelemenin Host-Based olduğunu agentPoolProfiles algılanabilir. Başvuru uygulaması kümedeki hiçbir 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 yer alıyor. İlkeler olarak audit ayarlanır, olarak block ayarlanmaz.

Görüntüleri yönetme

İş yükleriniz için dağıtım olmayan temel görüntüleri kullanın. Bu görüntülerle, kabuklar ve paket yöneticileri gibi ek görüntüler kaldırıldığı için güvenlik yüzeyi alanı simge durumuna küçültülmüş olur. Bir avantaj, CVE isabet oranlarının azaltılmasıdır.

Azure Container Registry, Open Container Initiative (OCI) Görüntü Biçimi Belirtimi'neuygun görüntüleri destekler. Bu, imzaları doğrulamayı destekleyen bir erişim denetleyicisiyle birlikte, yalnızca özel anahtarlarınızı imzalayan görüntüleri çalıştırmanızı sağlar. Bu işlemleri tümleştiren SSE Connaisseur veya IBM Portieris gibi açık kaynak çözümler vardır.

Kapsayıcı görüntülerini ve diğer OCI yapıtlarını, kuruluşun fikri mülkiyeti içerdiği için koruyun. Müşteri tarafından yönetilen anahtarları kullanın ve kayıt defterlerinin içeriğini şifreler. Varsayılan olarak, veriler hizmet tarafından yönetilen anahtarlarla istirahat sırasında şifrelenir, ancak bazen mevzuat uyumluluğu standartlarını karşılamak için müşteri tarafından yönetilen anahtarlar gereklidir. Anahtarı, anahtar gibi yönetilen bir anahtar Azure Key Vault. Anahtarı siz oluştur ve ona sahip olduğundan, döndürme ve yönetim de dahil olmak üzere anahtar yaşam döngüsüyle ilgili işlemlerden sorumlu oluruz. Daha fazla bilgi için bkz. Müşteri tarafından yönetilen anahtar kullanarak kayıt defterini şifreleme.

Kubernetes API Server işletimsel erişimi

Atlama kutularına dayalı bir işlem oluşturmadan kümeye karşı yürütülen komutları sınırlandırabilirsiniz. IAM geçitli bir IT otomasyon platformumuz varsa, eylem türünü denetleme ve denetleme için önceden tanımlanmış eylemleri kullanın.

Derleme aracıları

Derleme işlemleri tehdit vektörleri olduğundan işlem hattı aracıları, düzenlenen kümenin kapsamı dışında olmalıdır. Kubernetes'i esnek derleme aracısı altyapısı olarak kullanmak yaygın bir durumsa da, bu işlemi düzenlenen iş yükü çalışma zamanı sınırları içinde çalıştırmayın. Derleme aracılarının kümeye doğrudan erişimi olmaması gerekir. Örneğin, kapsayıcı görüntülerini, helm grafiklerini ve Azure Container Registry için yalnızca derleme aracılarına ağ erişimi verme. Ardından GitOps aracılığıyla dağıtın. Yaygın bir uygulama olarak, derleme ve yayın iş akışlarını Kubernetes Küme API'nize (veya düğümlerine) doğrudan erişime sahip olmaması gerekir.

İzleme işlemleri

Küme içinde etkinlikler

içinde çalışan küme omsagent içinde podlar kube-system Log Analytics toplama aracısıdır. Telemetri verileri toplar, kapsayıcıyı ve stdout günlükleri stderr kazır ve Prometheus ölçümlerini toplar. ConfigMap dosyasını güncelleştirerek koleksiyon container-azm-ms-agentconfig.yaml ayarlarını değiştirebilirsiniz. Bu başvuru uygulamasında günlük kaydı ve tüm iş kube-system yükleriniz genelinde etkinleştirilir. Varsayılan olarak, kube-system günlüğe kaydetmenin dışındadır. Günlükleri gözden geçirerek maliyet hedeflerini, SRE verimliliğini ve uyumluluk ihtiyaçlarını dengelemek için günlük toplama işlemini ayarlayarak emin olursanız.

Güvenliği izleme

Güvenlik önerilerini görüntülemek ve düzeltmek için Bulut için Microsoft Defender'ı kullanın. Ayrıca kaynaklarınıza güvenlik uyarılarını da görüntüebilirsiniz. Kart sahibi veri ortamının çeşitli bileşenleri için geçerli olan Microsoft Defender planlarını etkinleştirin.

Verileri verimli bir şekilde gözden geçirmek, analiz etmek ve sorgulamak için günlükleri tümleştirin. Azure çeşitli teknoloji seçenekleri sağlar. Log Analytics Azure İzleyici günlük yazmak için Azure İzleyici kullanabilirsiniz. Bir diğer seçenek de verileri Microsoft Sentinel gibi güvenlik bilgileri ve olay yönetimi (SIEM) çözümleriyle tümleştirebilirsiniz.

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

Eksiksiz bir perspektif için bkz. Bulut için Microsoft Defender Enterprise Ekleme Kılavuzu. Bu kılavuz kaydı, SIEM çözümlerinize veri dışarı aktarmayı, uyarılara yanıt vermeyi ve iş akışı otomasyonu oluşturmayı adresler.

İlgili Azure hizmetleri

Bu mimarinin bazı temel bileşenlerinin özellik belgelerinin bağlantıları burada velanmıştır.

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

Sonraki

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ılanları kullanma.