Yazılım kalitesinin yapı taşlarıPillars of software quality

Başarılı bir bulut uygulaması bu beş yapı taşına yazılım kalitesinin odaklanır: Ölçeklenebilirlik, kullanılabilirlik, dayanıklılık, yönetim ve güvenlik.A successful cloud application will focus on these five pillars of software quality: Scalability, availability, resiliency, management, and security.

Yapı TaşıPillar AçıklamaDescription
ÖlçeklenebilirlikScalability Sistemin artan yükü idare edebilme özelliği.The ability of a system to handle increased load.
KullanılabilirlikAvailability Sistemin iş görür ve çalışır olduğu sürenin oranı.The proportion of time that a system is functional and working.
DayanıklılıkResiliency Sistemin hatalardan kurtularak çalışmaya devam edebilme özelliği.The ability of a system to recover from failures and continue to function.
YönetimManagement Sistemi üretimde çalışır durumda tutan operasyon süreçleri.Operations processes that keep a system running in production.
GüvenlikSecurity Uygulama ve verilerin tehditlere karşı korunması.Protecting applications and data from threats.

ÖlçeklenebilirlikScalability

Ölçeklenebilirlik, sistemin artan yükü idare edebilme özelliğidir.Scalability is the ability of a system to handle increased load. Bir uygulamayı ölçeklendirmenin başlıca iki yolu vardır.There are two main ways that an application can scale. Dikey ölçeklendirme (ölçeği artırma), bir kaynağın kapasitesini artırmak (örneğin, daha büyük bir VM boyutu kullanarak) anlamına gelir.Vertical scaling (scaling up) means increasing the capacity of a resource, for example by using a larger VM size. Yatay ölçeklendirme (ölçeği genişletme), bir kaynağın yeni örneklerini eklemek (örneğin, VM'ler veya veritabanı çoğaltmaları) anlamına gelir.Horizontal scaling (scaling out) is adding new instances of a resource, such as VMs or database replicas.

Yatay ölçeklendirmenin dikey ölçeklendirmeye göre önemli avantajları vardır:Horizontal scaling has significant advantages over vertical scaling:

  • Gerçek bulut ölçeği.True cloud scale. Uygulamalar, yüzlerce hatta binlerce düğümde çalıştırılacak şekilde tasarlanabilir. Böylece tek bir düğümde mümkün olmayan ölçeklere ulaşılabilir.Applications can be designed to run on hundreds or even thousands of nodes, reaching scales that are not possible on a single node.
  • Yatay ölçek esnektir.Horizontal scale is elastic. Yük artarsa yeni örnekler ekleyebilir veya sakin dönemlerde örnekleri kaldırabilirsiniz.You can add more instances if load increases, or remove them during quieter periods.
  • Ölçeği genişletme, belirli bir zamanlamaya göre veya yükteki değişikliklere yanıt vermek için otomatik olarak tetiklenebilir.Scaling out can be triggered automatically, either on a schedule or in response to changes in load.
  • Ölçeğin genişletilmesi, ölçeğin artırılmasından daha ucuza gelebilir.Scaling out may be cheaper than scaling up. Birçok küçük VM çalıştırmanın maliyeti, tek bir büyük VM çalıştırmaya göre daha düşük olabilir.Running several small VMs can cost less than a single large VM.
  • Yatay ölçeklendirme, yedeklilik ekleyerek dayanıklılığı da artırabilir.Horizontal scaling can also improve resiliency, by adding redundancy. Bir örnek kullanılamaz hale gelse de uygulama çalışmaya devam eder.If an instance goes down, the application keeps running.

Dikey ölçeklendirmenin bir avantajı, uygulamada hiçbir değişikliğe gerek kalmadan yapılabilmesidir.An advantage of vertical scaling is that you can do it without making any changes to the application. Ancak belirli bir noktada üst sınıra ulaşırsınız ve ölçeği daha fazla artıramazsınız.But at some point you'll hit a limit, where you can't scale any up any more. Bu noktadan sonra yapılacak ölçeklendirme işlemleri yatay olmak zorundadır.At that point, any further scaling must be horizontal.

Yatay ölçek, sistemin bir parçası olarak tasarlanmalıdır.Horizontal scale must be designed into the system. Örneğin, VM'leri bir yük dengeleyicinin arkasına yerleştirerek ölçeklerini genişletebilirsiniz.For example, you can scale out VMs by placing them behind a load balancer. Ancak havuzdaki her bir VM’nin tüm istemci isteklerini işleyebilmesi gerekir. Bu nedenle, uygulama durum bilgisiz olmalı veya durumu harici olarak (örneğin, dağıtılmış bir önbellekte) depolamalıdır.But each VM in the pool must be able to handle any client request, so the application must be stateless or store state externally (say, in a distributed cache). Yatay ölçeklendirme ve otomatik ölçeklendirme özellikleri yönetilen PaaS hizmetlerinde genellikle yerleşiktir.Managed PaaS services often have horizontal scaling and auto-scaling built in. PaaS hizmetlerinin kolayca ölçeklenebilmesi bu hizmetleri kullanmanın başlıca avantajlarındandır.The ease of scaling these services is a major advantage of using PaaS services.

Ancak yalnızca daha fazla örnek eklenmesi, uygulamanın ölçekleneceği anlamına gelmez.Just adding more instances doesn't mean an application will scale, however. Bu işlemin tek sonucu performans sorununu başka bir noktaya göndermek olabilir.It might simply push the bottleneck somewhere else. Örneğin, bir Web ön ucu daha fazla istemci isteği işlemek üzere ölçeklendirilirse veritabanında kilit çekişmeleri tetiklenebilir.For example, if you scale a web front-end to handle more client requests, that might trigger lock contentions in the database. Böyle bir durumda, veritabanına daha fazla aktarım hızı için iyimser eşzamanlılık veya veri bölümleme gibi ek önlemleri göz önüne almanız gerekir.You would then need to consider additional measures, such as optimistic concurrency or data partitioning, to enable more throughput to the database.

Bu olası performans sorunlarını bulmak için her zaman performans ve yük testleri gerçekleştirin.Always conduct performance and load testing to find these potential bottlenecks. Sistemin durum bilgisi olan kısımları (veritabanları gibi) performans sorunlarının en yaygın nedenidir ve yatay olarak ölçeklendirilmek üzere dikkatli bir şekilde tasarlanmaları gerekir.The stateful parts of a system, such as databases, are the most common cause of bottlenecks, and require careful design to scale horizontally. Bir performans sorununun giderilmesi başka noktalarda performans sorunlarına yol açabilir.Resolving one bottleneck may reveal other bottlenecks elsewhere.

Tasarımınızı ölçeklenebilirlik açısından gözden geçirmek için Ölçeklenebilirlik denetim listesini kullanın.Use the Scalability checklist to review your design from a scalability standpoint.

Ölçeklenebilirlik kılavuzuScalability guidance

KullanılabilirlikAvailability

Kullanılabilirlik, sistemin iş görür ve çalışır olduğu sürenin oranıdır.Availability is the proportion of time that the system is functional and working. Genellikle çalışma süresinin yüzdesi olarak ölçülür.It is usually measured as a percentage of uptime. Uygulama hataları, altyapı sorunları ve sistem yükü, kullanılabilirliği azaltabilecek faktörlerdir.Application errors, infrastructure problems, and system load can all reduce availability.

Bir bulut uygulamasının beklenen kullanılabilirliği ve kullanılabilirliğin nasıl ölçüleceğini açıkça tanımlayan bir hizmet düzeyi hedefi (SLO) olması gerekir.A cloud application should have a service level objective (SLO) that clearly defines the expected availability, and how the availability is measured. Kullanılabilirliği tanımlarken kritik yola bakın.When defining availability, look at the critical path. Web ön ucu istemci isteklerine hizmet sunuyor olabilir, ancak ön uç veritabanına bağlanamadığı için her işlem başarısız oluyorsa uygulama, kullanıcılar için kullanılabilir değildir.The web front-end might be able to service client requests, but if every transaction fails because it can't connect to the database, the application is not available to users.

Kullanılabilirlik genellikle "9’lar" cinsinden belirtilir. Örneğin, "dört 9" %99,99 çalışma süresi anlamına gelir.Availability is often described in terms of "9s" — for example, "four 9s" means 99.99% uptime. Aşağıdaki tabloda, farklı kullanılabilirlik düzeyleri için olası toplu kapalı kalma süreleri gösterilmektedir.The following table shows the potential cumulative downtime at different availability levels.

% Çalışma süresi% Uptime Haftalık kapalı kalma süresiDowntime per week Aylık kapalı kalma süresiDowntime per month Yıllık kapalı kalma süresiDowntime per year
%9999% 1,68 saat1.68 hours 7,2 saat7.2 hours 3,65 gün3.65 days
%99,999.9% 10 dakika10 minutes 43,2 dakika43.2 minutes 8,76 saat8.76 hours
%99,9599.95% 5 dakika5 minutes 21,6 dakika21.6 minutes 4,38 saat4.38 hours
%99,9999.99% 1 dakika1 minute 4,32 dakika4.32 minutes 52,56 dakika52.56 minutes
%99,99999.999% 6 saniye6 seconds 26 saniye26 seconds 5,26 dakika5.26 minutes

%99 çalışma süresinin haftada neredeyse 2 saatlik hizmet kesintisine yol açtığına dikkat edin.Notice that 99% uptime could translate to an almost 2-hour service outage per week. Uygulamaların birçoğu, özellikle de tüketiciye yönelik uygulamalar için böyle bir SLO kabul edilebilir değildir.For many applications, especially consumer-facing applications, that is not an acceptable SLO. Öte yandan, beş 9 (%99,999) yılda en fazla 5 dakika kapalı kalma süresine yol açar.On the other hand, five 9s (99.999%) means no more than 5 minutes of downtime in a year. Bir kesintinin bu kadar hızlı algılanması bile hiç kolay değildir, böyle kısa sürelerde sorunun da giderilmesi oldukça zor olacaktır.It's challenging enough just detecting an outage that quickly, let alone resolving the issue. Çok yüksek kullanılabilirlik değerleri (%99,99 veya üzeri) yakalamak için hatalardan kurtarma konusunda el ile müdahalelere güvenemezsiniz.To get very high availability (99.99% or higher), you can't rely on manual intervention to recover from failures. Uygulamanın kendi kendini tanılayıp sorunlarını giderebilmesi gerekir. Dayanıklılık bu noktada büyük önem kazanır.The application must be self-diagnosing and self-healing, which is where resiliency becomes crucial.

Azure’daki Hizmet Düzeyi Sözleşmesi (SLA), Microsoft’un çalışma süresi ve bağlantı hakkındaki taahhütlerini belirtir.In Azure, the Service Level Agreement (SLA) describes Microsoft's commitments for uptime and connectivity. Belirli bir hizmet için SLA %99,95 ise hizmetin zamanın %99,95’inde kullanılabilir durumda olmasını bekleyebilirsiniz.If the SLA for a particular service is 99.95%, it means you should expect the service to be available 99.95% of the time.

Uygulamalar genellikle birden çok hizmete bağımlıdır.Applications often depend on multiple services. Genel olarak, herhangi bir hizmetin kapalı kalması olasılığı diğerlerinden bağımsızdır.In general, the probability of either service having downtime is independent. Örneğin, uygulamanızın her birinin SLA’sı %99,9 olan iki hizmete bağımlı olduğunu varsayalım.For example, suppose your application depends on two services, each with a 99.9% SLA. Her iki hizmet için bileşik SLA, %99,9 × %99,9 ≈ %99,8 olur. Yani bu SLA, hizmetlerin kendi SLA değerlerinden biraz daha düşüktür.The composite SLA for both services is 99.9% × 99.9% ≈ 99.8%, or slightly less than each service by itself.

Tasarımınızı kullanılabilirlik açısından gözden geçirmek için Kullanılabilirlik denetim listesini kullanın.Use the Availability checklist to review your design from an availability standpoint.

Kullanılabilirlik kılavuzuAvailability guidance

DayanıklılıkResiliency

Dayanıklılık, sistemin hatalardan kurtularak çalışmaya devam edebilme özelliğidir.Resiliency is the ability of the system to recover from failures and continue to function. Dayanıklılığın hedefi, bir hatanın ardından uygulamayı tam çalışır duruma geri döndürmektir.The goal of resiliency is to return the application to a fully functioning state after a failure occurs. Dayanıklılık, kullanılabilirlik ile yakından ilişkilidir.Resiliency is closely related to availability.

Geleneksel uygulama geliştirme sürecinde hatalar arasındaki ortalama süreyi (MTBF) azaltmak üzerinde odaklanılmıştır.In traditional application development, there has been a focus on reducing mean time between failures (MTBF). Sistemin başarısız olmasını engellemek için çalışılıyordu.Effort was spent trying to prevent the system from failing. Çeşitli faktörler nedeniyle bulut bilgi işlem için farklı bir bakış açısı gereklidir:In cloud computing, a different mindset is required, due to several factors:

  • Dağıtılmış sistemler karmaşıktır, bir noktadaki bir hata zincirleme olarak tüm sisteme yayılabilir.Distributed systems are complex, and a failure at one point can potentially cascade throughout the system.
  • Bulut ortamlarının maliyetleri ticari donanım kullanımı ile düşük tutulur. Bu nedenle, ara sıra donanım hatası yaşanacaktır.Costs for cloud environments are kept low through the use of commodity hardware, so occasional hardware failures must be expected.
  • Uygulamalar genellikle dış hizmetlere bağımlıdır. Bu hizmetler, geçici olarak kullanılamaz hale gelebilir veya yüksek hacimli kullanıcıları kısıtlayabilir.Applications often depend on external services, which may become temporarily unavailable or throttle high-volume users.
  • Günümüzde kullanıcılar uygulamaların hiç çevrimdışı kalmadan 7/24 kullanılabilir olmasını beklemektedir.Today's users expect an application to be available 24/7 without ever going offline.

Tüm bu faktörler nedeniyle bulut uygulamaları, ara sıra hatalar yaşanacağı beklentisiyle ve bu hatalardan kurtulacak şekilde tasarlanmalıdır.All of these factors mean that cloud applications must be designed to expect occasional failures and recover from them. Azure platformunda yerleşik halde bulunan birçok dayanıklılık özelliği vardır.Azure has many resiliency features already built into the platform. Örneğin:For example:

  • Azure Depolama, SQL Veritabanı ve Cosmos DB hizmetlerinin hepsinde bir bölge içinde ve bölgeler arasında veri çoğaltma özelliği yerleşiktir.Azure Storage, SQL Database, and Cosmos DB all provide built-in data replication, both within a region and across regions.
  • Azure Yönetilen Diskler, donanım hatalarının etkilerini sınırlamak için otomatik olarak farklı depolama ölçek birimlerine yerleştirilir.Azure Managed Disks are automatically placed in different storage scale units, to limit the effects of hardware failures.
  • Bir kullanılabilirlik kümesindeki VM’ler çeşitli hata etki alanlarına dağıtılır.VMs in an availability set are spread across several fault domains. Hata etki alanı, ortak bir güç kaynağı ve ağ anahtarını paylaşan bir VM grubudur.A fault domain is a group of VMs that share a common power source and network switch. VM’lerin çeşitli hata etki alanlarına dağıtılması, fiziksel donanım hatalarının, ağ kesintilerinin veya güç kesintilerinin etkisini sınırlar.Spreading VMs across fault domains limits the impact of physical hardware failures, network outages, or power interruptions.

Bu, uygulamanıza dayanıklılık oluşturmak yine belirtti.That said, you still need to build resiliency into your application. Dayanıklılık stratejileri mimarinin tüm düzeylerinde uygulanabilir.Resiliency strategies can be applied at all levels of the architecture. Bazı risk azaltma işlemleri taktiksel bir yapıdadır. Örneğin, geçici bir ağ hatasından sonra uzak çağrı yeniden denenir.Some mitigations are more tactical in nature — for example, retrying a remote call after a transient network failure. Bazı risk azaltma işlemleri de daha stratejiktir. Örneğin, uygulama tüm yükünü ikincil bir bölgeye devreder.Other mitigations are more strategic, such as failing over the entire application to a secondary region. Taktiksel risk azaltma işlemleri büyük bir fark yaratabilir.Tactical mitigations can make a big difference. Tüm bir bölgenin kesinti yaşaması nadirdir, ancak ağ tıkanıklığı gibi geçici sorunlar daha yaygındır. Bu nedenle ilk önce bunları hedefleyin.While it's rare for an entire region to experience a disruption, transient problems such as network congestion are more common — so target these first. Doğru izleme ve tanılama özelliklerine sahip olunması da hataları algılamak ve hata gerçekleştiğinde kök nedenlerini bulmak için önemlidir.Having the right monitoring and diagnostics is also important, both to detect failures when they happen, and to find the root causes.

Bir uygulamayı dayanıklı olacak şekilde tasarlarken kullanılabilirlik gereksinimlerinizi anlamanız şarttır.When designing an application to be resilient, you must understand your availability requirements. Kabul edilebilir kapalı kalma süresi ne kadardır?How much downtime is acceptable? Bunun yanıtı kısmen maliyete bağlıdır.This is partly a function of cost. Olası bir kapalı kalma süresinin işletmenize maliyeti ne olacaktır?How much will potential downtime cost your business? Uygulamanın yüksek kullanılabilirliğe sahip olması için ne kadar yatırım yapmalısınız?How much should you invest in making the application highly available?

Tasarımınızı dayanıklılık açısından gözden geçirmek için Dayanıklılık denetim listesini kullanın.Use the Resiliency checklist to review your design from a resiliency standpoint.

Dayanıklılık kılavuzuResiliency guidance

Yönetim ve DevOpsManagement and DevOps

Bu yapı taşı, uygulamayı üretimde çalışır durumda tutan operasyon süreçlerini kapsar.This pillar covers the operations processes that keep an application running in production.

Dağıtımlar, güvenilir ve öngörülebilir olmalıdır.Deployments must be reliable and predictable. İnsan hatası olasılığını azaltmak için otomatik hale getirilmelidir.They should be automated to reduce the chance of human error. Yeni özelliklerin ve hata düzeltmelerinin yayımlanmasını yavaşlatmaması için dağıtımın hızlı ve rutin bir süreç olması gerekir.They should be a fast and routine process, so they don't slow down the release of new features or bug fixes. Aynı derecede önemli bir başka konu da bir güncelleştirmede sorunlar varsa hızlı bir şekilde geri alma ya da ileri sarmanın mümkün olmasıdır.Equally important, you must be able to quickly roll back or roll forward if an update has problems.

İzleme ve tanılama çok önemlidir.Monitoring and diagnostics are crucial. Bulut uygulamaları, altyapının veya bazı durumlarda işletim sisteminin üzerinde tam denetim sahibi olmadığınız uzak bir veri merkezinde çalıştırılır.Cloud applications run in a remote datacenter where you do not have full control of the infrastructure or, in some cases, the operating system. Büyük bir uygulamada sorun gidermek veya günlük dosyalarını gözden geçirmek için VM'lerde oturum açılması pratik değildir.In a large application, it's not practical to log into VMs to troubleshoot an issue or sift through log files. PaaS hizmetleriyle çalışıldığında oturum açılabilecek adanmış bir VM bile olmayabilir.With PaaS services, there may not even be a dedicated VM to log into. İzleme ve tanılama, sistem hakkında verdikleri bilgilerle hataların ne zaman ve nerede oluştuğunu bilmenizi sağlar.Monitoring and diagnostics give insight into the system, so that you know when and where failures occur. Tüm sistemlerin gözlemlenebilir olması gerekir.All systems must be observable. Tüm sistemlerdeki olayları ilişkilendirmenize olanak sağlayan genel ve tutarlı bir günlüğe kaydetme şeması kullanın.Use a common and consistent logging schema that lets you correlate events across systems.

İzleme ve tanılama süreci bir grup ayrı aşamadan oluşur:The monitoring and diagnostics process has several distinct phases:

  • İzleme.Instrumentation. Ham veri, uygulama günlükleri oluşturma, web sunucusu günlükleri, Azure platformu ve diğer kaynakları yerleşik tanılama.Generating the raw data, from application logs, web server logs, diagnostics built into the Azure platform, and other sources.
  • Toplama ve depolama.Collection and storage. Verileri tek bir yerde birleştirme.Consolidating the data into one place.
  • Analiz ve tanılama.Analysis and diagnosis. Sorunları giderme ve genel sistem durumuna bakma.To troubleshoot issues and see the overall health.
  • Görselleştirme ve uyarılar.Visualization and alerts. Telemetri verilerini kullanarak eğilimleri saptama veya operasyon ekibine uyarılar verme.Using telemetry data to spot trends or alert the operations team.

Tasarımınızı yönetim ve DevOps açısından gözden geçirmek için DevOps denetim listesini kullanın.Use the DevOps checklist to review your design from a management and DevOps standpoint.

Yönetim ve DevOps kılavuzuManagement and DevOps guidance

GüvenlikSecurity

Tasarım ve uygulamadan dağıtım ve işletime kadar uygulamanın tüm yaşam döngüsü boyunca güvenlik hakkında düşünmeniz gerekir.You must think about security throughout the entire lifecycle of an application, from design and implementation to deployment and operations. Azure platformu, ağa yetkisiz erişim ve DDoS saldırıları gibi birçok tehdide karşı koruma sağlar.The Azure platform provides protections against a variety of threats, such as network intrusion and DDoS attacks. Ancak yine de uygulamanıza ve DevOps süreçlerinize güvenlik özellikleri eklemeniz gerekir.But you still need to build security into your application and into your DevOps processes.

Göz önüne almanız gereken bazı geniş kapsamlı güvenlik konuları aşağıda sunulmaktadır.Here are some broad security areas to consider.

Kimlik yönetimiIdentity management

Kullanıcıların kimlik doğrulama ve yetkilendirme işlemleri için Azure Active Directory’yi (Azure AD) kullanabilirsiniz.Consider using Azure Active Directory (Azure AD) to authenticate and authorize users. Azure AD, tam olarak yönetilen bir kimlik ve erişim yönetimi hizmetidir.Azure AD is a fully managed identity and access management service. Azure AD ile tamamen Azure üzerinde var olan etki alanları oluşturabilir veya şirket içi Active Directory kimlikleriniz ile tümleştirebilirsiniz.You can use it to create domains that exist purely on Azure, or integrate with your on-premises Active Directory identities. Azure AD ayrıca Office365, Dynamics CRM Online ve çok sayıda üçüncü taraf SaaS uygulaması ile tümleştirilebilir.Azure AD also integrates with Office365, Dynamics CRM Online, and many third-party SaaS applications. Azure Active Directory B2C, tüketiciye yönelik uygulamalar için kullanıcıların sosyal ağ hesaplarıyla (Facebook, Google veya LinkedIn gibi) kimlik doğrulamasına ya da Azure AD tarafından yönetilen yeni bir kullanıcı hesabı oluşturmasına olanak tanır.For consumer-facing applications, Azure Active Directory B2C lets users authenticate with their existing social accounts (such as Facebook, Google, or LinkedIn), or create a new user account that is managed by Azure AD.

Şirket içi bir Active Directory ortamını bir Azure ağı ile tümleştirmek istiyorsanız gereksinimlerinize bağlı olarak çeşitli yaklaşımlar mümkündür.If you want to integrate an on-premises Active Directory environment with an Azure network, several approaches are possible, depending on your requirements. Daha fazla bilgi için Kimlik Yönetimi başvuru mimarilerimize göz atın.For more information, see our Identity Management reference architectures.

Altyapınızı korumaProtecting your infrastructure

Dağıttığınız Azure kaynaklarına erişimi denetleyin.Control access to the Azure resources that you deploy. Her Azure aboneliğinin bir Azure AD kiracısıyla güven ilişkisi vardır.Every Azure subscription has a trust relationship with an Azure AD tenant. Kuruluşunuzdaki kullanıcılara Azure kaynaklarına yönelik doğru izinleri vermek için Rol Tabanlı Erişim Denetimi’ni (RBAC) kullanın.Use Role-Based Access Control (RBAC) to grant users within your organization the correct permissions to Azure resources. Kullanıcılara veya gruplara belirli bir kapsama sahip RBAC rolleri atayarak erişim izni verin.Grant access by assigning RBAC role to users or groups at a certain scope. Bu kapsam abonelik, kaynak grubu veya tek bir kaynak olabilir.The scope can be a subscription, a resource group, or a single resource. Altyapıda yapılan tüm değişiklikleri denetleyin.Audit all changes to infrastructure.

Uygulama güvenliğiApplication security

Genel olarak, uygulama geliştirme sürecine ilişkin en iyi güvenlik uygulamaları bulutta da geçerlidir.In general, the security best practices for application development still apply in the cloud. Bu en iyi uygulamalar arasında her yerde SSL’yi kullanma, CSRF ve XSS saldırılarına karşı koruma, SQL ekleme saldırılarını önleme sayılabilir.These include things like using SSL everywhere, protecting against CSRF and XSS attacks, preventing SQL injection attacks, and so on.

Bulut uygulamaları çoğu zaman erişim anahtarları olan yönetilen hizmetler kullanır.Cloud applications often use managed services that have access keys. Bu anahtarları asla kaynak denetimine teslim etmeyin.Never check these into source control. Uygulama gizli dizilerini Azure Key Vault’ta depolamanız iyi bir fikir olabilir.Consider storing application secrets in Azure Key Vault.

Veri egemenliği ve şifrelemeData sovereignty and encryption

Azure’ın yüksek kullanılabilirliğe sahip hizmetlerinden yararlanırken verilerinizin doğru jeopolitik bölgede kaldığından emin olun.Make sure that your data remains in the correct geopolitical zone when using Azure's highly available. Azure'ın coğrafi olarak çoğaltılan depolama hizmeti aynı jeopolitik bölgede eşleştirilmiş bölge kavramını kullanır.Azure's geo-replicated storage uses the concept of a paired region in the same geopolitical region.

Şifreleme anahtarları ve gizli dizilerini korumak için Key Vault’u kullanın.Use Key Vault to safeguard cryptographic keys and secrets. Key Vault sayesinde anahtarları ve gizli dizileri donanım güvenlik modülleri (HSM) tarafından korunan anahtarlar kullanarak şifreleyebilirsiniz.By using Key Vault, you can encrypt keys and secrets by using keys that are protected by hardware security modules (HSMs). Azure Depolama, Azure SQL Veritabanı, Azure SQL Veri Ambarı ve Cosmos DB dahil birçok Azure depolama ve veritabanı hizmeti bekleyen verilerin şifrelenmesini destekler.Many Azure storage and DB services support data encryption at rest, including Azure Storage, Azure SQL Database, Azure SQL Data Warehouse, and Cosmos DB.

Güvenlik kaynaklarıSecurity resources