SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama
SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama

Tüm Rehberler

ISO 27001 sertifikasyonu, organizasyonunuzun bilgi güvenliğini sistematik biçimde yönettiğini kanıtlar. Web sitesi ve web uygulaması işleten ekipler için bir denetimden başarıyla geçmek, bir politika belgesinden çok daha fazlasını gerektirir: kanıtlanabilir ve tekrarlanabilir teknik kontroller şarttır. Bu rehber, geliştiricileri, güvenlik mühendislerini ve teknik yöneticileri, web varlıklarını ISO 27001 hazırlığına taşımak için atmaları gereken somut adımlarla yönlendirmekte; her eylemi standardın Ek A kontrolleriyle eşleştirmekte ve denetçilerin beklediği kanıt izini oluşturmaktadır.

01

Web Varlıklarınızı Envantere Alın (Ek A 5.9 – Varlık Yönetimi)

ISO 27001, tüm bilgi varlıklarının eksiksiz ve doğru bir envanterini zorunlu kılar. Web sistemleri için bu; diğer kontroller uygulanmadan önce her uygulamanın, API uç noktasının, alt alanın ve destekleyici hizmetin listelenmesi anlamına gelir. Eksik envanter, hem denetçilerin hem de saldırganların tespit edeceği yönetilemeyen bir saldırı yüzeyi yaratır.

  • Organizasyonunuzun sahip olduğu veya işlettiği tüm alan adlarını ve alt alanları (hazırlık, geliştirme ve iş ortağı yönetimindeki varlıklar dahil) listeleyin.
  • Her web uygulamasının amacını, sahibini, veri sınıflandırmasını ve teknoloji yığınını (dil, framework, CMS, sunucu) belgeleyin.
  • Web varlıklarınız tarafından kullanılan tüm harici API'leri, SaaS entegrasyonlarını ve üçüncü taraf betikleri kaydedin.
  • Her web varlığı için sorumlu bir varlık sahibi atayın — ISO 27001, sahipliğin açık olmasını şart koşar.
  • Envanteri sürüm kontrollü bir konumda (CMDB, wiki veya değişiklik geçmişi olan elektronik tablo gibi) saklayın ve en az altı ayda bir gözden geçirme döngüsü oluşturun.
  • Resmi kayıtlarınızda yer almayan gölge BT alt alanlarını keşfetmek için DNS numaralandırma tekniklerini ve sertifika şeffaflık günlüklerini kullanın. Sensagraph, harici saldırı yüzeyinizi sürekli izler ve daha önce bilinmeyen alt alanları ortaya çıkarabilir.
02

Web Odaklı Risk Değerlendirmesi Yapın (Madde 6.1)

Risk değerlendirmesi, her ISO 27001 BGYS'nin özüdür. Web varlıkları için gerçekçi tehditleri belirlemeniz, mevcut kontrolleri değerlendirmeniz ve hangi artık risklerin kabul edilebilir olduğuna karar vermeniz gerekir. Denetçiler, metodolojinizi titizlik ve tutarlılık açısından yakından inceleyecektir.

  • Bir risk değerlendirme metodolojisi seçin ve belgeleyin (varlık tabanlı veya senaryo tabanlı gibi); tüm web varlıklarına tutarlı biçimde uygulayın.
  • Web uygulamalarıyla ilgili tehdit senaryolarını belirleyin: enjeksiyon saldırıları, kimlik doğrulama atlatma, veri sızdırma, DDoS, tedarik zinciri güvenlik ihlali ve yanlış yapılandırma.
  • Her riski olasılık ve iş etkisine göre derecelendirerek risk puanı üretin. Tutarlı bir ölçek kullanın (örn. 1–5 × 1–5 matrisi).
  • Mevcut kontrolleri her riske eşleyin ve kontroller uygulandıktan sonraki artık riski hesaplayın.
  • Kabul edilemez artık riskler için azaltma, kabul, devretme veya önleme seçeneklerini, sorumlu sahipleri ve hedef tarihleri belirten resmi bir Risk İşleme Planı (RTP) oluşturun.
  • SSL/TLS sertifikaları, yönetici panelleri, kimlik doğrulama mekanizmaları ve kullanıcı veri depoları gibi web'e özgü varlıkları risk kaydına ekleyin.
  • Risk değerlendirmesini en az yılda bir ve web altyapısında önemli bir değişiklik sonrasında gözden geçirip güncelleyin.
03

Güvenli İletişimi – TLS'i Zorunlu Kılın (Ek A 8.24)

Kullanıcılar ile web uygulamalarınız arasındaki tüm veri iletimi şifrelenmiş olmalıdır. Zayıf TLS yapılandırmaları — eski protokol sürümleri, zayıf şifre takımları, süresi dolmuş sertifikalar veya eksik HSTS — en sık dile getirilen denetim bulgularındandır ve gizlilik ile bütünlük açısından doğrudan risk oluşturur.

  • Tüm HTTP trafiğini kalıcı (301) yönlendirme ile HTTPS'e yönlendirin — hiçbir içeriği düz HTTP üzerinden sunmayın.
  • Tüm web sunucularında TLS 1.0 ve TLS 1.1'i devre dışı bırakın; yalnızca TLS 1.2 ve TLS 1.3'ü destekleyin.
  • SSLv3 ile dışa aktarım sınıfı ve NULL şifre takımlarını devre dışı bırakın. ECDHE anahtar değişimini ve AES-GCM şifrelerini tercih edin.
  • Tüm TLS sertifikalarının geçerli, güvenilir bir CA tarafından verilmiş ve 30 gün içinde süresi dolmayacak olduğundan emin olun. Let's Encrypt veya PKI çözümünüzle yenilemeyi otomatikleştirin.
  • HSTS'i en az 31.536.000 saniyelik max-age değeriyle etkinleştirin; includeSubDomains ekleyin ve kararlı hale geldikten sonra HSTS ön yükleme listesine gönderin.
  • Etkin sertifika iptal denetimi sağlamak için web sunucunuzda OCSP zımbalama özelliğini etkinleştirin.
  • TLS yapılandırmanızı bilinen zayıflıklara (BEAST, POODLE, ROBOT, DROWN, Heartbleed) karşı test edin ve sonuçları kanıt olarak belgeleyin. Sensagraph, TLS protokol sürümlerini, şifre takımlarını ve sertifika geçerliliğini otomatik olarak kontrol eder.
04

Erişim Denetimi ve Kimlik Doğrulama Uygulayın (Ek A 8.2, 8.5, 8.6)

ISO 27001 Ek A'nın kimlik ve erişim yönetimine ilişkin kontrolleri, web uygulama kimlik doğrulamasına doğrudan uygulanır. Zayıf veya tutarsız erişim denetimi, web uygulamalarındaki veri ihlallerinin tutarlı biçimde en başta gelen nedenidir.

  • Tüm yönetim arayüzlerinde, CMS arka uçlarında, barındırma kontrol panellerinde ve hassas veri işleyen her uygulamada çok faktörlü kimlik doğrulamayı (MFA) zorunlu kılın.
  • En az ayrıcalık ilkesini uygulayın: her kullanıcı rolü yalnızca işlevini yerine getirmek için gereken minimum izinlere sahip olmalıdır. Rol tanımlarını resmi olarak belgeleyin.
  • Üretime geçmeden önce web sunucuları, CMS'ler, veritabanları ve yönetim konsollarındaki tüm varsayılan kimlik bilgilerini kaldırın veya devre dışı bırakın.
  • Kaba kuvvet saldırılarını azaltmak için yapılandırılabilir sayıda (genellikle 5–10) başarısız giriş denemesinin ardından hesap kilitleme veya kademeli gecikme uygulayın.
  • Güvenli oturum yönetimi uygulayın: kriptografik olarak rastgele oturum belirteçleri kullanın; Secure, HttpOnly ve SameSite=Strict (veya Lax) çerez bayraklarını ayarlayın; hareketsizlik sonrasında oturum zaman aşımını zorunlu kılın.
  • Resmi bir erişim inceleme süreci oluşturun — tüm web uygulama kullanıcı hesaplarını en az altı ayda bir gözden geçirip onaylayın; ayrılan personelin erişimini derhal iptal edin.
  • Tüm kimlik doğrulama olaylarını (başarılı ve başarısız girişler, parola değişiklikleri, MFA olayları) kaydedin ve günlük saklama politikanızda tanımlanan süre boyunca saklayın.
05

HTTP Güvenlik Başlıklarını Sertleştirin (Ek A 8.9 – Yapılandırma Yönetimi)

HTTP yanıt başlıkları, düşük maliyetli ve yüksek etkili bir güvenlik kontrolüdür. Eksik veya yanlış yapılandırılmış başlıklar, kullanıcıları tıklama korsanlığı, siteler arası betik çalıştırma, MIME-sniffing saldırıları ve bilgi sızıntısı risklerine maruz bırakır. Denetçiler ve sızma testçileri bu başlıkları rutin olarak kontrol eder.

  • Content-Security-Policy (CSP): Güvenilir içerik kaynakları için açık bir izin listesi tanımlayın. Bozulmaları önlemek için önce report-only politikasıyla başlayın, ardından uygulayın. Mümkün olduğunda unsafe-inline ve unsafe-eval kullanmaktan kaçının.
  • X-Frame-Options: Tıklama korsanlığını önlemek için DENY veya SAMEORIGIN olarak ayarlayın (ya da CSP'nin frame-ancestors yönergesini kullanın).
  • X-Content-Type-Options: MIME türü algılamasını önlemek için nosniff olarak ayarlayın.
  • Referrer-Policy: Yönlendiren bilgisinin sızmasını sınırlamak için strict-origin-when-cross-origin veya daha kısıtlayıcı bir değer ayarlayın.
  • Permissions-Policy: Uygulamanızın kullanmadığı tarayıcı özelliklerine (kamera, mikrofon, coğrafi konum) erişimi kısıtlayın.
  • Bilgi ifşasını sınırlamak için Server, X-Powered-By ve X-AspNet-Version gibi sunucuyu tanımlayan başlıkları kaldırın veya gizleyin.
  • Başlık yapılandırmasını otomatik taramayla doğrulayın ve sonuçları kontrol kanıtı olarak belgeleyin. Sensagraph, her taramada tüm önemli HTTP güvenlik başlıklarını kontrol eder.
06

OWASP İlk 10 Güvenlik Açıklarını Ele Alın (Ek A 8.25, 8.28)

ISO 27001 Ek A 8.28 (Güvenli Kodlama), yazılım geliştirmenin güvenli kodlama ilkelerini takip etmesini şart koşar. OWASP İlk 10, kritik web uygulama riskleri için fiili referanstır ve bu kontrolle doğrudan örtüşür. Denetçiniz, bu risklerin sistematik olarak ele alındığına dair kanıt bekleyecektir.

  • Enjeksiyon (SQLi, komut enjeksiyonu, LDAP enjeksiyonu): Parametreli sorgular ve hazır ifadeler kullanın. Kullanıcı girdisini asla sorgulara veya kabuk komutlarına birleştirmeyin. Tüm girdileri sunucu tarafında doğrulayın ve sanitize edin.
  • Kırık Erişim Kontrolü: Her sunucu tarafı işlemde yetkilendirme denetimlerini zorunlu kılın. Varsayılan olarak erişimi reddedin; yalnızca kullanıcı arayüzünde işlevleri gizlemeye güvenmeyin.
  • Kriptografik Hatalar: Hassas veri içeren tüm alanları (parolalar, KVK, ödeme verileri) belirleyin ve modern algoritmalarla (AES-256, parolalar için bcrypt/Argon2) beklemedeyken şifrelendiğinden emin olun.
  • Siteler Arası Betik Çalıştırma (XSS): Tüm çıktıları doğru bağlamda (HTML, JavaScript, URL) kodlayın. Otomatik kaçış etkin olan şablon motorları kullanın. Katı bir CSP uygulayın.
  • Güvenlik Yanlış Yapılandırması: Dizin listelemeyi devre dışı bırakın, örnek dosyaları ve varsayılan sayfaları kaldırın, gereksiz HTTP yöntemlerini (PUT, DELETE, TRACE) devre dışı bırakın ve tüm yazılımları güncel tutun.
  • Savunmasız ve Güncel Olmayan Bileşenler: Tüm bağımlılıklar için bir yazılım malzeme listesi (SBOM) oluşturun ve CVE'leri izleyin. Savunmasız kütüphaneleri derhal güncelleyin veya değiştirin.
  • Güvensiz Serileştirme Kaldırma: Güvenilmeyen kaynaklardan gelen verilerin serileştirmesini mümkün olduğunda önleyin; kaçınılmazsa serileştirilmiş nesneleri doğrulayın ve imzalayın.
  • OWASP İlk 10 testlerini kod incelemesi, SAST ve DAST aracılığıyla yazılım geliştirme yaşam döngünüze dahil edin. Bulgular ve düzeltmeler Ek A 8.25 ve 8.28 için kanıt olarak belgelendirin.
07

Sürekli Güvenlik Açığı Yönetimi Oluşturun (Ek A 8.8)

ISO 27001 Ek A 8.8, teknik güvenlik açıklarının zamanında tespit edilip yönetilmesini şart koşar. Web varlıkları için bu; düzenli otomatik taramalar yapmak ve bulguları önceliklendirmek, sıralamak ve düzeltmek için resmi bir süreç sürdürmek anlamına gelir.

  • Kapsam dahilindeki tüm web uygulamalarında otomatik web güvenlik açığı taramalarını en az aylık olarak ve her önemli sürüm veya altyapı değişikliğinin ardından çalıştırın.
  • Her bulguyu keşif tarihi, önem derecesi (Kritik/Yüksek/Orta/Düşük), etkilenen varlık, düzeltme sorumlusu, hedef düzeltme tarihi ve kapanış tarihi ile kaydeden bir güvenlik açığı kaydı tutun.
  • Önem derecesine göre düzeltme SLA'ları tanımlayın — yaygın bir temel: Kritik ≤ 24 saat, Yüksek ≤ 7 gün, Orta ≤ 30 gün, Düşük ≤ 90 gün. Bu SLA'ları belgeleyin ve uygulayın.
  • Web sistemlerinize yönelik nitelikli bir üçüncü taraf tarafından yılda en az bir sızma testi gerçekleştirin ve raporu BGYS kanıt paketinize ekleyin.
  • Web yığınınızdaki her teknoloji (web sunucusu, uygulama çerçevesi, CMS, eklentiler, kütüphaneler) için CVE beslemelerine ve güvenlik bültenlerine abone olun.
  • Düzeltme ilerlemesini takip edin ve güvenlik açığı metriklerini (önem derecesine göre açık güvenlik açıkları, ortalama düzeltme süresi) en az üç ayda bir yönetime raporlayın. Sensagraph sürekli otomatik tarama sağlar ve doğrudan ISO 27001 kanıtı olarak saklanabilecek tarama raporları üretir.
08

Günlük Kaydı, İzleme ve Uyarı Uygulayın (Ek A 8.15, 8.16)

ISO 27001, olayların kaydedilmesini ve günlüklerin güvenlik olaylarını tespit edip araştırmak amacıyla incelenmesini şart koşar. Web uygulamaları için bu; anlamlı güvenlik olaylarını yakalamak, günlük bütünlüğünü korumak ve anormallikler için uyarı mekanizmaları oluşturmak anlamına gelir.

  • Web sunucusu erişim günlüklerini, hata günlüklerini, uygulama güvenlik olay günlüklerini ve kimlik doğrulama günlüklerini bir SIEM veya günlük yönetim platformunda etkinleştirin ve merkezileştirin.
  • En azından şu olayları kaydedin: tüm kimlik doğrulama girişimleri (başarılı ve başarısız), ayrıcalık yükseltmeleri, yönetimsel işlemler, giriş doğrulama hataları ve toplu hata yanıtları (4xx, 5xx).
  • Günlük girişlerinin şunları içerdiğinden emin olun: zaman damgası (UTC), kaynak IP, kullanıcı/oturum tanımlayıcısı, gerçekleştirilen işlem ve sonuç.
  • Günlük bütünlüğünü koruyun: güvenliği ihlal edilmiş bir web sunucusu tarafından kurcalanamayacak şekilde günlükleri salt okunur veya uzak bir sisteme gönderin.
  • Veri saklama politikanız ve geçerli düzenlemelerle uyumlu günlük saklama süreleri tanımlayın ve belgeleyin (genellikle 90 gün çevrimiçi, 12 ay arşivlenmiş).
  • Şu durumlar için otomatik uyarılar yapılandırın: tekrarlanan kimlik doğrulama hataları (olası kaba kuvvet), 5xx hatalarında ani artışlar, olağandışı coğrafi erişim kalıpları ve istek günlüklerindeki bilinen saldırı imzaları (SQLi, XSS kalıpları).
  • Düzenli günlük incelemeleri yapın — yüksek riskli sistemler için en az haftalık manuel inceleme, kritik olaylar için neredeyse gerçek zamanlı otomatik uyarı.
09

Üçüncü Taraf ve Tedarik Zinciri Riskini Yönetin (Ek A 5.19, 5.20, 8.30)

Modern web uygulamaları üçüncü taraf bileşenlere — CDN'lere, JavaScript kütüphanelerine, ödeme işlemcilerine, analitik betiklerine ve SaaS API'lerine — büyük ölçüde dayanır. Her entegrasyon olası bir saldırı vektörüdür. ISO 27001 Ek A 5.19 ve 5.20, tedarikçi ilişkilerinin yönetilmesini ve mutabık kalınan güvenlik gereksinimlerinin izlenmesini zorunlu kılar.

  • Her web uygulaması tarafından kullanılan tüm üçüncü taraf kütüphaneleri, CDN kaynaklarını ve harici API'leri sürüm numaraları ve her bağımlılığın amacı ile birlikte listeleyin.
  • Harici barındırılan tüm betiklere ve stil dosyalarına Alt Kaynak Bütünlüğü (SRI) karmaları ekleyerek tarayıcının kurcalanmış kaynakları engellemesini sağlayın.
  • Kritik SaaS sağlayıcılarının güvenlik durumunu inceleyin: onboarding öncesinde SOC 2 / ISO 27001 sertifikalarını, ihlal geçmişlerini ve güvenlik iletişim bilgilerini kontrol edin.
  • Kullanıcı verilerinizi işleyen veya erişebilen tedarikçilerle yapılan sözleşmelere ve hizmet anlaşmalarına güvenlik gereksinimlerini ekleyin (veri işleme sözleşmeleri, sızma testi hakları, ihlal bildirim süreleri gibi).
  • CI/CD pipeline'ınıza entegre edilmiş bir yazılım bileşimi analizi (SCA) aracı kullanarak üçüncü taraf bileşenleri bilinen CVE'ler açısından izleyin.
  • Güvenliği ihlal edilmiş bir üçüncü taraf bileşeninin acil olarak kaldırılması veya değiştirilmesi için bir süreç tanımlayın; geri alma prosedürlerini ve kullanıcı iletişim şablonlarını hazırlayın.
  • Web sistemlerinize üçüncü taraf erişimini en az yılda bir denetleyin — artık erişim gerektirmeyen tedarikçilerin token'larını, API anahtarlarını ve kimlik bilgilerini iptal edin.
10

DNS ve Alan Adı Yapılandırmanızı Güvence Altına Alın (Ek A 8.9)

DNS, web varlığınız için kritik altyapıdır. DNS ele geçirme, alt alan adı devralma ve alan adınız üzerinden e-posta sahteciliği; ISO 27001 denetçilerinin yapılandırma yönetimi kontrolleriyle azaltılmasını beklediği gerçekçi tehditlerdir.

  • DNS yanıtlarını kriptografik olarak doğrulamak ve önbellek zehirlenmesi saldırılarına karşı koruma sağlamak için alan adınızda DNSSEC'i etkinleştirin.
  • E-posta gönderen tüm alan adları için SPF, DKIM ve DMARC kayıtlarını yapılandırın — alan adı sahteciliğini önlemek için güven oluştuktan sonra DMARC politikasını p=quarantine veya p=reject olarak ayarlayın.
  • Tüm DNS kayıtlarını denetleyin ve alt alan adı devralmasını önlemek için kullanım dışı kalmış veya üçüncü taraf hizmetlere işaret eden atıl CNAME, A ve AAAA kayıtlarını kaldırın.
  • DNS bölge yönetimini MFA korumalı hesaplar kullanan az sayıda isimli yöneticiye kısıtlayın. DNS sağlayıcınızda denetim günlüğü kaydını etkinleştirin.
  • DNS sağlayıcınızın uyarıları veya harici bir izleme hizmeti aracılığıyla beklenmedik DNS değişikliklerini izleyin.
  • Alan adı kayıt kuruluşu hesabınızı yetkisiz transferlere karşı kilitleyin (kayıt kuruluşu kilidi / transfer kilidi) ve MFA destekleyen bir kayıt kuruluşu kullanın.
11

Web Olayları İçin Olay Müdahale Kapasitesi Oluşturun (Ek A 5.24, 5.26)

ISO 27001, tanımlanmış bir olay yönetimi süreci gerektirir. Web sistemleri için bu; ekibinizin hızlı yanıt verebilmesi ve düzenleyici ile denetim amaçları için eylemleri belgeleyebilmesi amacıyla gerçekçi web'e özgü olaylar için bir oyun kitabına sahip olmak anlamına gelir.

  • Web uygulamalarınız bağlamında bir güvenlik olayının ne oluşturduğunu tanımlayın (onaylı ihlal, web sitesi tahrifi, eşik üzerinde DDoS, veri sızdırma, kimlik bilgisi doldurma kampanyası gibi).
  • En olası web olay türleri için çalışma kitapları yazın ve güncel tutun: web uygulaması güvenlik ihlali, DDoS, yanlış yapılandırma nedeniyle kazara veri ifşası ve üçüncü taraf tedarik zinciri ihlali.
  • Rolleri atayın: Olay Komutanı, Teknik Lider, İletişim Lideri ve Hukuk/Uyumluluk İrtibatı. Tüm ilgililerin eğitildiğinden ve sorumluluklarını bildiğinden emin olun.
  • Birincil sistemlerin güvenliğinin ihlal edilebileceği durumlarda kullanmak üzere güvenli bir bant dışı iletişim kanalı (özel bir Signal grubu veya telefon zinciri gibi) oluşturun.
  • Olay müdahale planını, gerçekçi bir web saldırısı senaryosunu kapsayan yılda en az bir masa başı tatbikatıyla test edin. Tatbikatı ve çıkarılan dersleri belgeleyin.
  • Her güvenlik olayını kaydeden bir olay günlüğü tutun: tarih/saat, açıklama, önem derecesi, alınan önlemler, çözüm ve kök neden. Bu günlük, temel ISO 27001 kanıtıdır.
  • İhlal bildirim yükümlülüklerinizi (GDPR Madde 33, sektöre özgü düzenlemeler) tanımlayın ve bildirim zaman çizelgelerini olay çalışma kitaplarınıza dahil edin.
12

Politikaları Belgeleyin ve Denetim Kanıtlarını Derleyin (Madde 7.5)

ISO 27001, ne yaptığınızı kanıtlamak kadar yapmakla da ilgilidir. Denetçiler her kontrol için belgesel kanıt talep edecektir. Yıl boyunca iyi belgeleme alışkanlıkları geliştirmek, denetim öncesinde son dakika telaşını önler.

  • Üst yönetim tarafından onaylanmış, yılda bir kez gözden geçirilen ve tüm ilgili personele erişilebilen bir Bilgi Güvenliği Politikası oluşturun ve güncel tutun.
  • Kabul Edilebilir Kullanım Politikası, Erişim Denetimi Politikası, Güvenlik Açığı Yönetimi Politikası ve Olay Müdahale Politikası oluşturun ve güncel tutun — her biri bu rehberdeki web'e özgü kontrollere atıfta bulunmalıdır.
  • Tüm tarama raporlarını, sızma testi sonuçlarını, risk değerlendirmelerini, risk işleme planlarını ve denetim günlüklerini merkezi, erişim kontrollü bir kanıt deposunda saklayın.
  • Her güvenlik taramasının, incelemesinin ve testinin tarihini, kapsamını ve sonucunu kaydedin. Tamamlanan incelemeleri sorumlu sahibin adıyla onaylayın.
  • Her Ek A kontrolünü web ortamınızla açıkça eşleştiren ve herhangi bir hariç tutmayı gerekçelendiren bir Uygulanabilirlik Beyanı (SoA) hazırlayın ve güncel tutun.
  • Dış denetiminizden önce web güvenlik kontrollerinin iç denetimini en az yılda bir gerçekleştirin. Bulguları, düzeltici eylemleri ve kapanış tarihlerini belgeleyin.
  • Liderlik onayı için web varlıklarınızın güvenlik durumunu özetleyen (güvenlik açığı eğilimleri, olay sayıları, SLA uyumu) bir yönetim gözden geçirme paketi hazırlayın — Madde 9.3 için zorunlu kanıt.

Sıkça sorulan sorular

En doğrudan uygulanabilir kontroller şunlardır: A 5.9 (Varlık Yönetimi), A 8.2 ve A 8.5 (Erişim Denetimi ve Kimlik Doğrulama), A 8.8 (Güvenlik Açığı Yönetimi), A 8.9 (Yapılandırma Yönetimi), A 8.15 ve A 8.16 (Günlük Kaydı ve İzleme), A 8.24 (Kriptografi / TLS), A 8.25 ve A 8.28 (Güvenli Geliştirme ve Kodlama), A 5.19 ve A 5.20 (Tedarikçi İlişkileri). Risk değerlendirmesine ilişkin Madde 6.1 tüm bu kontroller için geçerlidir.

ISO 27001, sızma testini açıkça zorunlu kılmaz; ancak Ek A 8.8 (Teknik Güvenlik Açığı Yönetimi) ve 8.29 (Geliştirmede Güvenlik Testi), web sistemleri için bunu kuvvetle ima eder. Çoğu belgelendirme kuruluşu ve deneyimli denetçi, güvenlik açıklarının aktif olarak tespit edilip yönetildiğinin kanıtı olarak kapsam dahilindeki web varlıklarına yönelik yılda en az bir sızma testi görmek ister.

ISO 27001 belirli bir tarama sıklığı öngörmez; ancak web varlıkları için en iyi uygulama, sürekli veya en az aylık otomatik tarama ile her önemli kod sürümü veya altyapı değişikliğinin ardından tarama yapmaktır. Güvenlik açığı yönetimi politikanız sıklığı tanımlamalı ve tarama raporları kanıt olarak saklanmalıdır.

Evet. Bulutta barındırılan web uygulamaları tam kapsamdadır. Bulut sağlayıcınızla paylaşılan sorumluluk sınırlarını (sağlayıcının kontrol ettiklerine karşı sizin kontrol ettikleriniz) belgelendirmeniz, bulut ortamını varlık envanterinize ve risk değerlendirmenize eklemeniz ve yönettiğiniz yığının bölümlerine ilgili tüm Ek A kontrollerini uygulamanız gerekir. Kanıt paketiniz için bulut sağlayıcınızın ISO 27001 veya SOC 2 belgelendirme belgelerini edinin.

Uygulanabilirlik Beyanı (Madde 6.1.3), tüm ISO 27001 Ek A kontrollerini listeleyen, her birinin BGYS'nize uygulanıp uygulanmadığını belirten, hariç tutmaları gerekçelendiren ve dahil edilen kontrollerin nasıl uygulandığına atıfta bulunan zorunlu bir belgedir. Web güvenliği için SoA'da TLS, erişim denetimi, güvenlik açığı yönetimi ve güvenli kodlama gibi kontrolleri web varlıklarınızla açıkça eşleştirmeniz gerekir.

ISO 27001, yönetim ve süreç odaklı bir yönetim sistemi standardıdır; OWASP, web uygulaması güvenlik açıkları için spesifik teknik rehberlik sağlar; PCI-DSS ise ödeme kartı verileri için açıklayıcı bir uyumluluk standardıdır. Bu çerçeveler birbirini tamamlar. OWASP İlk 10 azaltımlarını uygulamak, ISO 27001 Ek A 8.28 (Güvenli Kodlama) için somut teknik kanıt sağlar. Kart verisi de işliyorsanız PCI-DSS kontrolleri, ISO 27001 gereksinimleriyle büyük ölçüde örtüşür ve bazı alanlarda bu gereksinimlerin ötesine geçer.