Azure İşlevleri güvenliğini sağlama

Birçok şekilde, sunucusuz işlevlerin güvenli geliştirme, dağıtım ve çalışma planlaması, web tabanlı veya bulutta barındırılan tüm uygulamalarla aynıdır. Azure Uygulaması Hizmeti, işlev uygulamalarınız için barındırma altyapısı sağlar. Bu makalede işlev kodunuzu çalıştırmaya yönelik güvenlik stratejileri ve App Service'in işlevlerinizin güvenliğini sağlamanıza nasıl yardımcı olabileceği açıklanır.

App Service'in Azure VM'leri, depolama, ağ bağlantıları, web çerçeveleri, yönetim ve tümleştirme özellikleri gibi platform bileşenleri etkin bir şekilde güvenlik altına alınmış ve sağlamlaştırılmıştır. App Service, şundan emin olmak için sürekli olarak güçlü uyumluluk denetimlerini gerçekleştirir:

Azure'da altyapı ve platform güvenliği hakkında daha fazla bilgi için bkz . Azure Güven Merkezi.

Microsoft bulut güvenliği karşılaştırmasını izleyen bir dizi güvenlik önerisi için bkz. Azure İşlevleri için Azure Güvenlik Temeli.

Güvenli işlem

Bu bölüm, işlev uygulamanızı mümkün olduğunca güvenli bir şekilde yapılandırma ve çalıştırma konusunda size yol gösterir.

Bulut için Defender

Bulut için Defender, portaldaki işlev uygulamanızla tümleşir. Yapılandırmayla ilgili olası güvenlik açıklarının ücretsiz olarak hızlı bir değerlendirmesini sağlar. Ayrılmış bir planda çalışan işlev uygulamaları ek ücret karşılığında Bulut için Defender gelişmiş güvenlik özelliklerini de kullanabilir. Daha fazla bilgi edinmek için bkz. Azure Uygulaması Hizmeti web uygulamalarınızı ve API'lerinizi koruma.

Günlüğe kaydetme ve izleme

Saldırıları algılamanın bir yolu etkinlik izleme ve günlüğe kaydetme analizidir. İşlevler, işlev uygulamanızın günlük, performans ve hata verilerini toplamak için Uygulama Analizler ile tümleşir. Uygulama Analizler performans anomalilerini otomatik olarak algılar ve sorunları tanılamanıza ve işlevlerinizin nasıl kullanıldığını anlamanıza yardımcı olacak güçlü analiz araçları içerir. Daha fazla bilgi edinmek için bkz. İzleme Azure İşlevleri.

İşlevler, daha kolay analiz için işlev uygulama günlüklerini sistem olaylarıyla birleştirmenizi sağlamak için Azure İzleyici Günlükleri ile de tümleştirilir. Tanılama ayarlarını kullanarak işlevlerinize yönelik platform günlüklerinin ve ölçümlerinin akış dışarı aktarmasını istediğiniz hedefe (logs Analytics çalışma alanı gibi) yapılandırabilirsiniz. Daha fazla bilgi edinmek için bkz. Azure İzleyici Günlükleriyle Azure İşlevleri izleme.

Kurumsal düzeyde tehdit algılama ve yanıt otomasyonu için günlüklerinizi ve olaylarınızı bir Logs Analytics çalışma alanına akışla aktarabilirsiniz. Daha sonra Microsoft Sentinel'i bu çalışma alanına bağlayabilirsiniz. Daha fazla bilgi edinmek için bkz . Microsoft Sentinel nedir?

Gözlemlenebilirlik hakkında daha fazla güvenlik önerisi için bkz. Azure İşlevleri için Azure güvenlik temeli.

HTTPS gerektir

varsayılan olarak, istemciler hem HTTP hem de HTTPS kullanarak işlev uç noktalarına bağlanabilir. HTTPS, hem şifrelenmiş hem de kimliği doğrulanmış güvenli bir bağlantı sağlamak için SSL/TLS protokolunu kullandığından HTTP'yi HTTP'lere yeniden yönlendirmeniz gerekir. Nasıl yapılacağını öğrenmek için bkz . HTTPS'yi zorunlu kılma.

HTTPS'ye ihtiyacınız olduğunda en son TLS sürümünü de zorunlu kullanmalısınız. Nasıl yapılacağını öğrenmek için bkz . TLS sürümlerini zorunlu kılma.

Daha fazla bilgi için bkz . Güvenli bağlantılar (TLS).

İşlev erişim anahtarları

İşlevler, geliştirme sırasında HTTP işlev uç noktalarınıza erişmenizi zorlaştırmak için anahtarları kullanmanıza olanak tanır. HTTP ile tetiklenen bir işlevdeki HTTP erişim düzeyi olarak anonymousayarlanmadığı sürece, istekler isteğe bir API erişim anahtarı içermelidir.

Anahtarlar varsayılan bir güvenlik mekanizması sağlarken, üretimde bir HTTP uç noktasının güvenliğini sağlamak için diğer seçenekleri göz önünde bulundurmak isteyebilirsiniz. Örneğin, ortak uygulamalarda paylaşılan gizli dizi dağıtmak iyi bir uygulama değildir. İşleviniz bir genel istemciden çağrılırsa, başka bir güvenlik mekanizması uygulamayı düşünebilirsiniz. Daha fazla bilgi edinmek için bkz . Üretimde HTTP uç noktasının güvenliğini sağlama.

İşlev anahtarı değerlerinizi yenilediğinizde, güncelleştirilmiş anahtar değerlerini işlevinizi çağıran tüm istemcilere el ile yeniden dağıtmanız gerekir.

Yetkilendirme kapsamları (işlev düzeyi)

İşlev düzeyi anahtarları için iki erişim kapsamı vardır:

  • İşlev: Bu anahtarlar yalnızca tanımlandığı belirli işlevler için geçerlidir. API anahtarı olarak kullanıldığında, bunlar yalnızca bu işleve erişime izin verir.

  • Konak: Konak kapsamına sahip anahtarlar, işlev uygulamasındaki tüm işlevlere erişmek için kullanılabilir. API anahtarı olarak kullanıldığında, bunlar işlev uygulamasındaki herhangi bir işleve erişime izin verir.

Her anahtar başvuru için adlandırılır ve işlev ve konak düzeyinde bir varsayılan anahtar ("varsayılan" olarak adlandırılır) vardır. İşlev tuşları konak anahtarlara göre önceliklidir. aynı adla iki anahtar tanımlandığında, işlev anahtarı her zaman kullanılır.

Ana anahtar (yönetici düzeyi)

Her işlev uygulamasının adlı _masteryönetici düzeyinde bir ana bilgisayar anahtarı da vardır. Ana anahtar, uygulamadaki tüm işlevlere konak düzeyinde erişim sağlamanın yanı sıra çalışma zamanı REST API'lerine yönetici erişimi de sağlar. Bu anahtar iptal edilemiyor. bir erişim düzeyi adminayarladığınızda, istekler ana anahtarı kullanmalıdır; diğer tüm anahtarlar erişim hatasına neden olur.

Dikkat

İşlev uygulamanızda ana anahtar tarafından verilen yükseltilmiş izinler nedeniyle, bu anahtarı üçüncü taraflarla paylaşmamanız veya yerel istemci uygulamalarında dağıtmamanız gerekir. Yönetici erişim düzeyini seçerken dikkatli olun.

Sistem anahtarı

Belirli uzantılar, web kancası uç noktalarına erişmek için sistem tarafından yönetilen bir anahtar gerektirebilir. Sistem anahtarları, dahili bileşenler tarafından çağrılan uzantıya özgü işlev uç noktaları için tasarlanmıştır. Örneğin, Event Grid tetikleyicisi , tetikleyici uç noktasını çağırırken aboneliğin bir sistem anahtarı kullanmasını gerektirir. Dayanıklı İşlevler çağırmak için sistem anahtarlarını da kullanırDayanıklı Görev uzantısı API'leri.

Sistem anahtarlarının kapsamı uzantı tarafından belirlenir, ancak genellikle işlev uygulamasının tamamı için geçerlidir. Sistem anahtarları yalnızca belirli uzantılar tarafından oluşturulabilir ve değerlerini açıkça ayarlayamazsınız. Diğer anahtarlar gibi portaldan veya anahtar API'lerini kullanarak anahtar için yeni bir değer oluşturabilirsiniz.

Anahtar karşılaştırması

Aşağıdaki tabloda, çeşitli erişim anahtarları için kullanılanlar karşılaştırır:

Eylem Kapsam Geçerli tuşlar
İşlev yürütme Belirli işlev İşlev
İşlev yürütme Herhangi bir işlev İşlev veya konak
Yönetici uç noktasını çağırma İşlev uygulaması Ana bilgisayar (yalnızca ana bilgisayar)
Dayanıklı Görev uzantısı API'lerini çağırma İşlev uygulaması1 Sistem2
Uzantıya özgü web kancasını çağırma (iç) İşlev uygulaması1 sistem2

1Uzantı tarafından belirlenen kapsam.
2Uzantıya göre ayarlanan belirli adlar.

Erişim anahtarları hakkında daha fazla bilgi edinmek için HTTP tetikleyici bağlama makalesine bakın.

Gizli dizi depoları

Varsayılan olarak, anahtarlar ayar tarafından sağlanan hesaptaki bir Blob depolama kapsayıcısında AzureWebJobsStorage depolanır. Bu davranışı geçersiz kılmak ve anahtarları farklı bir konumda depolamak için AzureWebJobsSecret Depolama Type ayarını kullanabilirsiniz.

Konum Değer Açıklama
İkinci depolama hesabı blob Anahtarları AzureWebJobsSecretStorageSas'taki SAS URL'sini temel alarak farklı bir depolama hesabının Blob depolamasında depolar.
Dosya sistemi files Anahtarlar, İşlevler v1.x'te varsayılan olan dosya sisteminde kalıcı hale getirilir.
Azure Key Vault keyvault AzureWebJobsSecretStorageKeyVaultUri'de ayarlanan anahtar kasası anahtarları depolamak için kullanılır.
Kubernetes Gizli Dizileri kubernetes AzureWebJobsKubernetesSecretName içindeki kaynak kümesi, anahtarları depolamak için kullanılır. Yalnızca, Kubernetes'te İşlevler çalışma zamanı çalıştırılırken desteklenir. Azure Functions Core Tools, Kubernetes'e dağıtılırken, değerleri otomatik olarak oluşturur.

Anahtar depolama için Key Vault kullanırken, ihtiyacınız olan uygulama ayarları, yönetilen kimlik türüne bağlıdır. İşlevler çalışma zamanı sürüm 3.x, yalnızca sistem tarafından atanan yönetilen kimlikleri destekler.

Ayar adı Sistem tarafından atanan Kullanıcı tarafından atanan Uygulama kaydı
AzureWebJobsSecret Depolama KeyVaultUri
AzureWebJobsSecret Depolama KeyVaultClientId X
AzureWebJobsSecret Depolama KeyVaultClientSecret X X
AzureWebJobsSecret Depolama KeyVaultTenantId X X

Kimlik doğrulaması/yetkilendirme

İşlev anahtarları istenmeyen erişim için biraz azaltma sağlasa da işlev uç noktalarınızı gerçekten güvenli hale getirmenin tek yolu işlevlerinize erişen istemcilerin pozitif kimlik doğrulamasını uygulamaktır. Daha sonra kimlik temelinde yetkilendirme kararları alabilirsiniz.

App Service Kimlik Doğrulamasını/Yetkilendirmesini Etkinleştirme

App Service platformu, istemcilerin kimliğini doğrulamak için Microsoft Entra Id ve birkaç üçüncü taraf kimlik sağlayıcısı kullanmanıza olanak tanır. İşlevleriniz için özel yetkilendirme kuralları uygulamak için bu stratejiyi kullanabilir ve işlev kodunuzdan kullanıcı bilgileriyle çalışabilirsiniz. Daha fazla bilgi edinmek için bkz. Azure Uygulaması Hizmetinde kimlik doğrulaması ve yetkilendirme ve İstemci kimlikleriyle çalışma.

İsteklerin kimliğini doğrulamak için Azure API Management'ı (APIM) kullanma

APIM, gelen istekler için çeşitli API güvenlik seçenekleri sağlar. Daha fazla bilgi edinmek için bkz . API Management kimlik doğrulama ilkeleri. APIM'yi kullandığınızda işlev uygulamanızı yalnızca APIM örneğinizin IP adresinden gelen istekleri kabul etmek üzere yapılandırabilirsiniz. Daha fazla bilgi edinmek için bkz . IP adresi kısıtlamaları.

İzinler

Tüm uygulama veya hizmetlerde olduğu gibi, amaç işlev uygulamanızı mümkün olan en düşük izinlerle çalıştırmaktır.

Kullanıcı yönetimi izinleri

İşlevler, yerleşik Azure rol tabanlı erişim denetimini (Azure RBAC) destekler. İşlevler tarafından desteklenen Azure rolleri Katkıda Bulunan, Sahip ve Okuyucu'dur.

İzinler işlev uygulaması düzeyinde etkilidir. Uygulama düzeyindeki görevlerin çoğunu gerçekleştirmek için Katkıda Bulunan rolü gereklidir. Uygulama Analizler günlük verilerini görüntüleyebilmek için İzleme Okuyucusu izniyle birlikte Katkıda Bulunan rolüne de ihtiyacınız vardır. Bir işlev uygulamasını yalnızca Sahip rolü silebilir.

İşlevleri ayrıcalığına göre düzenleme

uygulama ayarlarında depolanan Bağlan ion dizeleri ve diğer kimlik bilgileri, işlev uygulamasındaki tüm işlevlere ilişkili kaynakta aynı izin kümesini verir. Bu kimlik bilgilerini kullanmayan işlevleri ayrı bir işlev uygulamasına taşıyarak belirli kimlik bilgilerine erişimi olan işlev sayısını en aza indirmeyi göz önünde bulundurun. Farklı işlev uygulamalarındaki işlevler arasında veri geçirmek için her zaman işlev zinciri gibi teknikleri kullanabilirsiniz.

Yönetilen kimlikler

Microsoft Entra Id'den yönetilen kimlik, uygulamanızın Azure Key Vault gibi diğer Microsoft Entra korumalı kaynaklara kolayca erişmesini sağlar. Kimlik Azure platformu tarafından yönetilir ve herhangi bir gizli dizi sağlamanızı veya döndürmenizi gerektirmez. Microsoft Entra Id'deki yönetilen kimlikler hakkında daha fazla bilgi için bkz . Azure kaynakları için yönetilen kimlikler.

Uygulamanız için iki tür kimlik verilebilir:

  • Sistem tarafından atanan bir kimlik uygulamanıza bağlıdır ve uygulamanız silinirse silinir. Bir uygulama sistem tarafından atanan yalnızca bir kimliğe sahip olabilir.
  • Kullanıcı tarafından atanan kimlik ise uygulamanıza atanabilen tek başına bir Azure kaynağıdır. Bir uygulama için kullanıcı tarafından atanan birden çok kimlik olabilir.

Bazı tetikleyicilerden ve bağlamalardan gelen bağlantılar için gizli diziler yerine yönetilen kimlikler kullanılabilir. Bkz. Kimlik tabanlı bağlantılar.

Daha fazla bilgi için bkz. App Service ve Azure İşlevleri için yönetilen kimlikleri kullanma.

CORS erişimini kısıtlama

Çıkış noktaları arası kaynak paylaşımı (CORS), başka bir etki alanında çalışan web uygulamalarının HTTP tetikleyici uç noktalarınıza istekte bulunmalarına izin vermenin bir yoludur. App Service, HTTP isteklerinde gerekli CORS üst bilgilerini teslim etme konusunda yerleşik destek sağlar. CORS kuralları bir işlev uygulaması düzeyinde tanımlanır.

Tüm sitelerin uç noktanıza erişmesine izin veren bir joker karakter kullanmak cazip olsa da, bu durum siteler arası betik saldırılarını önlemeye yardımcı olan CORS'nin amacını alt eder. Bunun yerine, uç noktanıza erişmesi gereken her web uygulamasının etki alanı için ayrı bir CORS girdisi ekleyin.

Gizli dizileri yönetme

Kodunuzu çalıştırması gereken çeşitli hizmetlere ve kaynaklara bağlanabilmek için işlev uygulamalarının bağlantı dizesi ve hizmet anahtarları gibi gizli dizilere erişebilmesi gerekir. Bu bölümde, işlevlerinizin gerektirdiği gizli dizilerin nasıl depolandığı açıklanmaktadır.

Gizli dizileri hiçbir zaman işlev kodunuzda depolamayın.

Uygulama ayarları

Varsayılan olarak, işlev uygulamanız tarafından kullanılan bağlantı dizesi ve gizli dizileri ve bağlamaları uygulama ayarları olarak depolarsınız. Bu, bu kimlik bilgilerini hem işlev kodunuz hem de işlev tarafından kullanılan çeşitli bağlamalar için kullanılabilir hale getirir. Uygulama ayarı (anahtar) adı, gizli dizi olan gerçek değeri almak için kullanılır.

Örneğin, her işlev uygulaması çalışma zamanı tarafından kullanılan ilişkili bir depolama hesabı gerektirir. Varsayılan olarak, bu depolama hesabına bağlantı adlı AzureWebJobsStoragebir uygulama ayarında depolanır.

Uygulama ayarları ve bağlantı dizesi Azure'da şifrelenmiş olarak depolanır. Şifreleri yalnızca uygulama başlatıldığında uygulamanızın işlem belleğine eklenmeden önce çözülür. Şifreleme anahtarları düzenli olarak döndürülür. Bunun yerine gizli dizilerinizin güvenli depolama alanını yönetmeyi tercih ediyorsanız, uygulama ayarı bunun yerine Azure Key Vault'a başvuru olmalıdır.

Ayrıca, yerel bilgisayarınızda işlev geliştirirken ayarları varsayılan olarak local.settings.json dosyasında şifreleyebilirsiniz. Daha fazla bilgi için bkz . Yerel ayarlar dosyasını şifreleme.

Key Vault başvuruları

Uygulama ayarları çoğu işlev için yeterli olsa da, aynı gizli dizileri birden çok hizmette paylaşmak isteyebilirsiniz. Bu durumda, gizli dizilerin yedekli depolanması daha olası güvenlik açıklarına neden olur. Daha güvenli bir yaklaşım, merkezi bir gizli depolama hizmetine yöneliktir ve gizli diziler yerine bu hizmete yönelik başvuruları kullanır.

Azure Key Vault , erişim ilkeleri ve denetim geçmişi üzerinde tam denetime sahip merkezi gizli dizi yönetimi sağlayan bir hizmettir. Uygulama ayarlarınızda bir bağlantı dizesi veya anahtar yerine Key Vault başvurusu kullanabilirsiniz. Daha fazla bilgi edinmek için bkz. App Service ve Azure İşlevleri için Key Vault başvurularını kullanma.

Kimlik tabanlı bağlantılar

Kimlikler, bazı kaynaklara bağlanmak için gizli diziler yerine kullanılabilir. Bu, gizli dizi yönetimi gerektirmeme avantajına sahiptir ve daha ayrıntılı erişim denetimi ve denetimi sağlar.

Microsoft Entra kimlik doğrulamasını destekleyen Azure hizmetlerine bağlantı oluşturan kod yazarken gizli dizi veya bağlantı dizesi yerine kimlik kullanmayı seçebilirsiniz. Her iki bağlantı yönteminin ayrıntıları her hizmetin belgelerinde ele alınmıştır.

Bazı Azure İşlevleri tetikleyici ve bağlama uzantıları kimlik tabanlı bağlantı kullanılarak yapılandırılabilir. Bugün bu, Azure Blob ve Azure Kuyruk uzantılarını içerir. Bu uzantıları kimlik kullanacak şekilde yapılandırma hakkında bilgi için bkz. Azure İşlevleri kimlik tabanlı bağlantıları kullanma.

Kullanım kotalarını ayarlama

Tüketim planında çalışan işlevlerde kullanım kotası ayarlamayı göz önünde bulundurun. İşlev uygulamanızdaki işlevlerin toplam toplam yürütmesi için günlük GB saniye sınırı ayarladığınızda, sınıra ulaşıldığında yürütme durdurulur. Bu, işlevlerinizi yürüten kötü amaçlı kodlara karşı azaltmaya yardımcı olabilir. İşlevlerinizin tüketimini tahmin etmeyi öğrenmek için bkz . Tüketim planı maliyetlerini tahmin etme.

Veri doğrulaması

İşlevleriniz tarafından kullanılan tetikleyiciler ve bağlamalar ek veri doğrulaması sağlamaz. Kodunuz bir tetikleyiciden veya giriş bağlamasından alınan tüm verileri doğrulamalıdır. Yukarı akış hizmetinin güvenliği aşılırsa, işlevlerinizde doğrulanmamış girişlerin akmasını istemezsiniz. Örneğin, işleviniz bir Azure Depolama kuyruğundaki verileri ilişkisel veritabanında depolarsa, SQL ekleme saldırılarını önlemek için verileri doğrulamanız ve komutlarınızı parametreleştirmeniz gerekir.

İşlevinize gelen verilerin zaten doğrulandığını veya temizlendiğini varsaymayın. Çıkış bağlamalarına yazılan verilerin geçerli olduğunu doğrulamak da iyi bir fikirdir.

Hataları işleme

Temel görünse de, işlevlerinizde iyi bir hata işleme yazmanız önemlidir. İşlenmeyen hatalar konağa kabarır ve çalışma zamanı tarafından işlenir. Farklı bağlamalar hataların işlenmesini farklı şekilde işler. Daha fazla bilgi edinmek için bkz. Azure İşlevleri hata işleme.

Uzaktan hata ayıklamayı devre dışı bırakma

İşlevlerinizde etkin bir şekilde hata ayıkladığınız durumlar dışında uzaktan hata ayıklamanın devre dışı bırakıldığından emin olun. Uzaktan hata ayıklamayı portaldaki işlev uygulamanızın Yapılandırması'nın Genel Ayarlar sekmesinde devre dışı bırakabilirsiniz.

CORS erişimini kısıtlama

Azure İşlevleri çıkış noktaları arası kaynak paylaşımını (CORS) destekler. CORS, portalda ve Azure CLI aracılığıyla yapılandırılır. CORS izin verilen çıkış noktaları listesi, işlev uygulaması düzeyinde geçerlidir. CORS etkinleştirildiğinde yanıtlar üst bilgiyi içerir Access-Control-Allow-Origin . Daha fazla bilgi için bkz. Çıkış noktaları arası kaynak paylaşma.

İzin verilen çıkış noktaları listenizde joker karakterler kullanmayın. Bunun yerine, istekleri almayı beklediğiniz belirli etki alanlarını listeleyin.

Şifrelenmiş verileri depolama

Azure Depolama bekleyen bir depolama hesabındaki tüm verileri şifreler. Daha fazla bilgi için Bekleyen veriler için Azure Depolama şifrelemesi başlıklı makaleye bakın.

Varsayılan olarak, veriler Microsoft tarafından yönetilen anahtarlarla şifrelenir. Şifreleme anahtarları üzerinde ek denetim için blob ve dosya verilerinin şifrelenmesini sağlamak için müşteri tarafından yönetilen anahtarlar sağlayabilirsiniz. Depolama hesabına erişebilmek için bu anahtarların İşlevler için Azure Key Vault'ta bulunması gerekir. Daha fazla bilgi edinmek için bkz . Müşteri tarafından yönetilen anahtarları kullanarak bekleyenleri şifreleme.

İşlev uygulaması genellikle ek kaynaklara bağlıdır, bu nedenle uygulamanın güvenliğini sağlamanın bir parçası bu dış kaynakların güvenliğini sağlamaktır. İşlev uygulamalarının çoğu en azından Uygulama Analizler ve Azure Depolama bağımlılığı içerir. Bu kaynakların güvenliğini sağlama yönergeleri için Azure İzleyici için Azure güvenlik temeline ve Depolama için Azure güvenlik temeline bakın.

Önemli

Depolama hesabı, bazen uygulama kodunun kendisi de dahil olmak üzere önemli uygulama verilerini depolamak için kullanılır. Diğer uygulama ve kullanıcılardan depolama hesabına erişimi sınırlamanız gerekir.

Ayrıca, uygulama mantığınızın bağlı olduğu tüm kaynak türleri için hem tetikleyiciler hem de bağlamalar olarak ve işlev kodunuzla ilgili yönergelere başvurmalısınız.

Güvenli dağıtım

Tümleştirme aracı Azure İşlevleri, yerel işlev proje kodunu Azure'da yayımlamayı kolaylaştırır. Azure İşlevleri topolojisi için güvenlik dikkate alınırken dağıtımın nasıl çalıştığını anlamak önemlidir.

Dağıtım kimlik bilgileri

App Service dağıtımları için bir dizi dağıtım kimlik bilgisi gerekir. Bu dağıtım kimlik bilgileri, işlev uygulaması dağıtımlarınızın güvenliğini sağlamak için kullanılır. Dağıtım kimlik bilgileri App Service platformu tarafından yönetilir ve bekleme sırasında şifrelenir.

İki tür dağıtım kimlik bilgisi vardır:

  • Kullanıcı düzeyinde kimlik bilgileri: Azure hesabının tamamı için bir kimlik bilgileri kümesi. Azure hesabının erişim iznine sahip olduğu herhangi bir uygulamada, herhangi bir abonelikte App Service'e dağıtmak için kullanılabilir. Bu, portal GUI'sinde (uygulamanın kaynak sayfasının Genel Bakış ve Özellikler gibi) ortaya çıkarılmış varsayılan kümesidir. Kullanıcıya Rol Tabanlı Erişim Denetimi (RBAC) veya ortak yönetici izinleri aracılığıyla uygulama erişimi verildiğinde, erişim iptal edilene kadar bu kullanıcı kendi kullanıcı düzeyi kimlik bilgilerini kullanabilir. Bu kimlik bilgilerini diğer Azure kullanıcılarıyla paylaşmayın.

  • Uygulama düzeyinde kimlik bilgileri: Her uygulama için bir kimlik bilgileri kümesi. Yalnızca bu uygulamaya dağıtmak için kullanılabilir. Her uygulamanın kimlik bilgileri, uygulama oluşturma sırasında otomatik olarak oluşturulur. Bunlar el ile yapılandırılamaz, ancak her zaman sıfırlanabilir. Bir kullanıcıya (RBAC) aracılığıyla uygulama düzeyinde kimlik bilgilerine erişim verebilmesi için, bu kullanıcının uygulamada katkıda bulunan veya daha yüksek olması gerekir (Web Sitesi Katkıda Bulunanı yerleşik rolü dahil). Okuyucuların yayımlamasına izin verilmez ve bu kimlik bilgilerine erişemez.

Şu anda Key Vault dağıtım kimlik bilgileri için desteklenmemektedir. Dağıtım kimlik bilgilerini yönetme hakkında daha fazla bilgi edinmek için bkz. Azure Uygulaması Hizmeti için dağıtım kimlik bilgilerini yapılandırma.

FTP'yi devre dışı bırakma

Varsayılan olarak, her işlev uygulamasının bir FTP uç noktası etkindir. FTP uç noktasına dağıtım kimlik bilgileri kullanılarak erişilir.

İşlev kodunuzu dağıtmak için FTP önerilmez. FTP dağıtımları el ile gerçekleştirilir ve tetikleyicileri eşitlemenizi gerektirir. Daha fazla bilgi için bkz . FTP dağıtımı.

FTP kullanmayı planlamıyorsanız portalda devre dışı bırakmanız gerekir. FTP kullanmayı seçerseniz, FTPS'yi zorunlu kılmanız gerekir.

Scm uç noktasının güvenliğini sağlama

Her işlev uygulamasının, dağıtımlar ve diğer App Service site uzantıları için Gelişmiş Araçlar (Kudu) hizmeti tarafından kullanılan karşılık gelen scm bir hizmet uç noktası vardır. İşlev uygulamasının scm uç noktası her zaman biçiminde https://<FUNCTION_APP_NAME.scm.azurewebsites.net>bir URL'dir. İşlevlerinizin güvenliğini sağlamak için ağ yalıtımı kullandığınızda, bu uç noktayı da hesaba katmanız gerekir.

Ayrı bir scm uç noktasına sahip olarak, bir sanal ağda yalıtılmış veya çalışan işlev uygulaması için dağıtımları ve diğer gelişmiş araçlar işlevlerini denetleyebilirsiniz. Scm uç noktası hem temel kimlik doğrulamasını (dağıtım kimlik bilgilerini kullanarak) hem de Azure portalı kimlik bilgilerinizle çoklu oturum açmayı destekler. Daha fazla bilgi edinmek için bkz . Kudu hizmetine erişme.

Sürekli güvenlik doğrulaması

Geliştirme sürecinin her adımında güvenliğin dikkate alınması gerektiğinden, sürekli dağıtım ortamında güvenlik doğrulamaları uygulamak da mantıklıdır. Buna bazen DevSecOps adı verilir. Dağıtım işlem hattınız için Azure DevOps'un kullanılması doğrulamayı dağıtım işlemiyle tümleştirmenize olanak tanır. Daha fazla bilgi için bkz . CI/CD işlem hattınıza sürekli güvenlik doğrulaması eklemeyi öğrenin.

Ağ güvenliği

İşlev uygulamanıza ağ erişimini kısıtlamak, işlev uç noktalarınıza kimlerin erişebileceğini denetlemenize olanak tanır. İşlevler, işlevlerinizin İnternet'e yönlendirilebilir adresleri kullanmadan kaynaklara erişmesini sağlamak veya bir işlev uç noktasına İnternet erişimini kısıtlamak için App Service altyapısını kullanır. Bu ağ seçenekleri hakkında daha fazla bilgi edinmek için bkz. Azure İşlevleri ağ seçenekleri.

Erişim kısıtlamalarını ayarlama

Erişim kısıtlamaları, uygulamanıza gelen trafiği denetlemek için izin verme/reddetme kuralları listeleri tanımlamanıza olanak tanır. Kurallar öncelik sırasına göre değerlendirilir. Tanımlı kural yoksa uygulamanız herhangi bir adresten gelen trafiği kabul eder. Daha fazla bilgi edinmek için bkz. hizmet erişim kısıtlamaları Azure Uygulaması.

Depolama hesabının güvenliğini sağlama

İşlev uygulaması oluştururken Blob, Kuyruk ve Tablo depolamayı destekleyen genel amaçlı bir Azure Depolama hesabı oluşturmanız veya bu hesaba bağlanmanız gerekir. Bu depolama hesabını, hizmet uç noktaları veya özel uç noktalarla güvenliği sağlanan bir hesapla değiştirebilirsiniz. Daha fazla bilgi için bkz. Depolama hesabınızı bir sanal ağ ile kısıtlama.

Özel site erişimi

Azure Özel Uç Nokta, Azure Özel Bağlantı destekli bir hizmete özel ve güvenli bir şekilde bağlanmanızı sağlayan ağ arabirimidir. Özel Uç Nokta, sanal ağınızdaki bir özel IP adresini kullanır ve bu sayede hizmeti sanal ağınıza getirir.

Premium ve App Service planlarında barındırılan işlevleriniz için Özel Uç Nokta kullanabilirsiniz.

Özel Uç Noktalara çağrı yapmak istiyorsanız, DNS aramalarınızın özel uç noktaya çözümlenmesinden emin olmanız gerekir. Bu davranışı aşağıdaki yollardan biriyle zorunlu kılabilirsiniz:

  • Azure DNS özel bölgeleriyle tümleştirme. Sanal ağınızda özel bir DNS sunucusu olmadığında bu işlem otomatik olarak yapılır.
  • Uygulamanız tarafından kullanılan DNS sunucusunda özel uç noktayı yönetin. Bunu yapmak için özel uç nokta adresini bilmeniz ve ardından A kaydı kullanarak ulaşmaya çalıştığınız uç noktayı bu adrese işaret etmeniz gerekir.
  • Kendi DNS sunucunuzu Azure DNS özel bölgelerine iletecek şekilde yapılandırın.

Daha fazla bilgi edinmek için bkz . Web Apps için Özel Uç Noktaları kullanma.

İşlev uygulamanızı yalıtarak dağıtma

Azure Uygulaması Hizmet Ortamı (ASE), işlevlerinizin çalıştırıldığı özel bir barındırma ortamı sağlar. ASE, tüm gelen isteklerin kimliğini doğrulamak için kullanabileceğiniz tek bir ön uç ağ geçidi yapılandırmanızı sağlar. Daha fazla bilgi için bkz. App Service Ortamı için Web Uygulaması Güvenlik Duvarı (WAF) yapılandırma.

Ağ geçidi hizmeti kullanma

Azure Uygulaması lication Gateway ve Azure Front Door gibi ağ geçidi hizmetleri bir Web Uygulaması Güvenlik Duvarı (WAF) ayarlamanıza olanak sağlar. WAF kuralları, algılanan saldırıları izlemek veya engellemek için kullanılır ve bu da işlevleriniz için ek bir koruma katmanı sağlar. WAF ayarlamak için işlev uygulamanızın ASE'de çalışıyor olması veya Özel Uç Noktalar (önizleme) kullanıyor olması gerekir. Daha fazla bilgi edinmek için bkz . Özel Uç Noktaları Kullanma.

Sonraki adımlar