ISO 27001 Nedir? Bilgi Güvenliği Yönetim Sistemi

ISO 27001, bir kuruluşun bilgi varlıklarını nasıl koruduğunu tanımlayan uluslararası bir yönetim sistemi standardıdır. Adında "güvenlik" geçse de aslında bir firewall kuralı veya bir antivirüs ürünü değildir; kuruluşun bilgiyi hangi risklere karşı, hangi önceliklerle, kimin sorumluluğunda ve hangi kanıtlarla koruduğunu belgeleyen bir çerçevedir. Standardın kalbindeki kavram BGYS'dir, yani Bilgi Güvenliği Yönetim Sistemi (İngilizcesiyle ISMS). Buradaki "sistem" kelimesi kritik: tek bir ürün ya da tek bir denetimden geçmek değil, sürekli işleyen bir yönetim döngüsü kastediliyor.

Bu yazıda ISO 27001'i bir sistem yöneticisinin müşteriye anlatacağı sadelikte ele alacağız. Kapsamı nasıl belirlersiniz, risk değerlendirmesi neye benzer, Ek A kontrollerini nasıl seçersiniz, PUKÖ (Planla-Uygula-Kontrol Et-Önlem Al) döngüsü günlük operasyona nasıl oturur ve iç denetimden belgelendirmeye giden yol nasıl işler, hepsine değineceğiz. Amacımız size "belge asmak" değil, gerçekten işleyen bir güvenlik kültürü kurmanın mantığını göstermek. Teknik tarafı somutlaştırmak için yer yer örnek yapılandırmalar da paylaşacağız.

ISO 27001 Neden Tek Seferlik Bir Proje Değildir#

Birçok firma ISO 27001'i "bir kere alınır, duvara asılır" diye düşünür. Gerçek bunun tersidir. Sertifika üç yıl geçerlidir ama bu süre içinde her yıl gözetim denetimi yapılır ve üçüncü yılın sonunda yeniden belgelendirme gelir. Denetçi sizden sertifikayı ilk aldığınız günün kanıtlarını değil, geçen 12 ayda sistemin gerçekten çalıştığına dair kayıtları ister: risk değerlendirmesini güncellediniz mi, uyumsuzlukları kapattınız mı, yönetim gözden geçirmesini yaptınız mı, çalışan farkındalık eğitimlerini kaydettiniz mi.

Bu yüzden ISO 27001'i bir "durum" değil, bir "süreç" olarak düşünmek gerekir. Yeni bir sunucu devreye aldığınızda, yeni bir tedarikçiyle çalışmaya başladığınızda ya da bir güvenlik olayı yaşandığında sistemin bunu yakalaması ve kendini güncellemesi beklenir. Standardın metnindeki "sürekli iyileştirme" ifadesi işte tam olarak bunu anlatır. Altyapı tarafında bunu desteklemek için düzenli yedekleme ve sunucu yönetimi gibi operasyonel süreçlerin de sistematik olması gerekir.

Bir başka yaygın yanılgı, ISO 27001'in yalnızca büyük şirketlere hitap ettiğidir. Standart ölçekten bağımsızdır; 5 kişilik bir yazılım ekibi de, 5000 çalışanlı bir banka da aynı çerçeveyi uygular. Fark, kapsamın ve kontrollerin ölçeğindedir. Küçük ekipler için avantaj, bürokrasinin az olması ve kararların hızlı verilmesidir.

Kapsam Belirleme (Scope) — Neyi Koruyoruz#

Her şey kapsamla başlar. Kapsam, BGYS'nin sınırlarını çizer: hangi lokasyonlar, hangi departmanlar, hangi sistemler ve hangi bilgi varlıkları dahil? Kapsamı çok geniş tutarsanız yönetemeyecek kadar iş çıkar; çok dar tutarsanız denetçi "asıl riskli kısmı dışarıda bırakmışsınız" der. İyi bir kapsam, kuruluşun gerçekten kritik olan bilgisini içerir.

Kapsamı belirlerken önce bilgi varlıklarını envanterlersiniz. Bu envanter genellikle bir tablo halinde tutulur:

Her varlığın bir sahibi olması şarttır; sahipsiz varlık, kimsenin korumadığı varlıktır. Kapsam dokümanında ayrıca kapsam dışında bıraktığınız şeyleri de gerekçesiyle yazarsınız. Örneğin fiziksel bir arşiv odanız yoksa "fiziksel arşiv güvenliği kapsam dışıdır" demeniz gayet meşrudur. Barındırma altyapınız için web hosting veya VDS sunucu hizmetlerinizi de varlık envanterine dahil etmeniz, o katmandaki sorumlulukların netleşmesini sağlar.

Risk Değerlendirmesi ve İşleme#

ISO 27001'in motoru risk değerlendirmesidir. Fikir basit: her varlığa yönelik tehditleri ve zayıflıkları belirler, gerçekleşme olasılığı ile etkisini çarparak bir risk skoru çıkarırsınız. Yüksek skorlu riskler önce ele alınır. Bu, güvenlik bütçenizi duygusal kararlarla değil, ölçülebilir önceliklerle harcamanızı sağlar.

Basit bir risk skorlama yaklaşımı şöyle görünür:

Risk Skoru = Olasılık (1-5) x Etki (1-5)

Örnek:
Tehdit: Web uygulamasına SQL injection
Varlık: Müşteri veritabanı
Olasılık: 4 (kod güncel değil, WAF yok)
Etki: 5 (kişisel veri sızıntısı, KVKK cezası)
Skor: 20 -> Kabul edilemez, işleme alınacak

Bir riski değerlendirdikten sonra dört seçeneğiniz vardır: azaltmak (kontrol uygulamak), transfer etmek (sigorta ya da tedarikçiye devretmek), kaçınmak (o faaliyeti bırakmak) veya kabul etmek (skor düşükse üstlenmek). Yukarıdaki örnekte skoru 20 olan bir riski azaltmak için bir WAF katmanı devreye alıp uygulama kodunu parametreli sorgulara geçirmek mantıklı olur. Benzer şekilde brute force riskini azaltmak için sunucu tarafında oturum açma denemelerini sınırlamak tipik bir kontroldür:

# Nginx: giriş sayfasına istek hız sınırı
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location /giris {
    limit_req zone=login burst=3 nodelay;
    proxy_pass http://app_backend;
}

Risk işleme kararlarının tümü bir Risk İşleme Planı içinde toplanır. Bu plan, hangi riskin nasıl ele alınacağını, kimin sorumlu olduğunu ve hedef tarihi içerir. Denetçinin ilk bakacağı belgelerden biri budur, çünkü kuruluşun güvenliğe bakışının fotoğrafını verir.

Ek A Kontrollerinin Seçimi ve SoA#

Risklerinizi belirledikten sonra onları azaltacak kontrolleri seçersiniz. ISO 27001'in Ek A'sı (2022 revizyonuyla birlikte 93 kontrol, dört tema altında: örgütsel, insan, fiziksel, teknolojik) bir kontrol kataloğudur. Buradan seçim yaparken her kontrolü "uyguluyor muyuz, uygulamıyorsak neden" diye kayda geçirirsiniz. Bu kayda SoA denir, yani Uygulanabilirlik Bildirgesi (Statement of Applicability).

SoA, ISO 27001'in belki de en önemli tek belgesidir. Kısaca şuna benzer:

Dikkat edin, bir kontrolü "uygulamıyoruz" demek yasak değildir; gerekçesi mantıklıysa denetçi kabul eder. Örneğin sunucularınızı kendi ofisinizde değil bir veri merkezinde barındırıyorsanız, fiziksel güvenliğin bir kısmı barındırma sağlayıcısının sorumluluğundadır. Bu noktada sunucu güvenliği temelleri yazımızdaki teknik sertleştirme adımları, A.8 grubundaki teknolojik kontrollerin çoğunu doğrudan karşılamanıza yardımcı olur.

Bir kriptografi kontrolünü kanıtlamak için sunucu yapılandırmanızı göstermeniz yeterli olabilir:

# TLS 1.2 altını reddet, güçlü şifre paketleri
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
add_header Strict-Transport-Security "max-age=63072000" always;

Geçerli bir sertifika ile HTTPS'i zorunlu kılmak için ihtiyaç duyduğunuz SSL sertifikası da bu kanıt zincirinin bir parçasıdır.

PUKÖ Döngüsü — Sürekli İyileştirme#

ISO 27001, klasik PUKÖ (Planla, Uygula, Kontrol Et, Önlem Al) döngüsü üzerine kuruludur. Bu döngü, sistemin neden asla "bitmediğini" açıklar:

• Planla: Kapsamı belirle, riskleri değerlendir, politikaları ve hedefleri yaz.
• Uygula: Seçilen kontrolleri hayata geçir, çalışanları eğit, prosedürleri işlet.
• Kontrol Et: İç denetim yap, metrikleri ölç, olayları kaydet, kontrollerin çalışıp çalışmadığını izle.
• Önlem Al: Bulunan uyumsuzlukları düzelt, riskleri yeniden puanla, sistemi iyileştir.

Bu döngü bir çember gibi döner; "Önlem Al" adımının çıktısı yeni bir "Planla" girdisi olur. Örneğin bir gözetim denetiminde "yedeklerin geri yükleme testi yapılmıyor" bulgusu çıkarsa, bunu bir düzeltici faaliyet olarak açar, geri yükleme prosedürünü yazar ve bir sonraki denetime kadar en az bir başarılı test kaydı üretirsiniz. Somut bir yedek doğrulama örneği:

#!/usr/bin/env bash
# Aylık yedek geri yükleme testi (kanıt için loglanır)
set -euo pipefail
DUMP="/backups/db-$(date +%F).sql.gz"
gunzip -c "$DUMP" | mysql -u restore_test test_restore_db
ROWS=$(mysql -N -u restore_test -e "SELECT COUNT(*) FROM test_restore_db.orders;")
echo "$(date -Is) restore OK, orders=$ROWS" >> /var/log/restore-test.log

Bu log dosyası denetçiye "kontrol sadece kağıt üzerinde değil, gerçekten çalışıyor" demenin en somut yoludur. ISO 27001'de kanıt her şeydir; yapmış olmak yetmez, yaptığınızı gösterebilmeniz gerekir.

İç Denetim ve Yönetim Gözden Geçirmesi#

Belgelendirme denetiminden önce kuruluşun kendi kendini denetlemesi zorunludur. İç denetim, sistemin standarda ve kendi prosedürlerinize uygun çalışıp çalışmadığını bağımsız bir gözle kontrol eder. İç denetçi, denetlediği alanda çalışan kişi olamaz; tarafsızlık şarttır. Küçük firmalarda bu genellikle dışarıdan bir danışmanla ya da çapraz denetimle çözülür.

İç denetim bulguları üç kategoriye ayrılır: majör uyumsuzluk (sistemi ciddi biçimde zayıflatan eksik), minör uyumsuzluk (küçük sapma) ve iyileştirme fırsatı (öneri). Her uyumsuzluk için kök neden analizi yapılır ve bir düzeltici faaliyet açılır. Bulguları takip etmek için basit bir kayıt yeterlidir:

CREATE TABLE ic_denetim_bulgulari (
    id           INT AUTO_INCREMENT PRIMARY KEY,
    tarih        DATE NOT NULL,
    kontrol_ref  VARCHAR(16),       -- Ornek: A.8.13
    siniflandirma ENUM('major','minor','oneri'),
    aciklama     TEXT,
    sorumlu      VARCHAR(80),
    hedef_tarih  DATE,
    durum        ENUM('acik','kapali') DEFAULT 'acik'
);

Yönetim gözden geçirmesi ise üst yönetimin sisteme sahip çıktığını gösteren toplantıdır. Standart, yönetimin belirli girdileri (denetim sonuçları, olay kayıtları, risk değişiklikleri, önceki toplantı kararlarının durumu) değerlendirmesini ve kararlar (kaynak ayırma, hedef güncelleme) üretmesini ister. Bu toplantının tutanağı da bir kanıttır. Üst yönetimin desteği olmadan BGYS kağıt üzerinde kalır; denetçiler bunun canlı olup olmadığını yönetim tutanaklarından anlar.

Belgelendirme Süreci — Aşama 1 ve Aşama 2#

Sistemi kurup en az birkaç ay işlettikten sonra akredite bir belgelendirme kuruluşuyla anlaşırsınız. Denetim iki aşamalıdır:

Aşama 1 (doküman incelemesi): Denetçi belgelerinizi inceler; kapsam, risk değerlendirmesi, SoA, politikalar ve prosedürler yerinde mi diye bakar. Bu aşama bir "hazırlık kontrolü" gibidir; büyük eksikler burada yakalanır ve Aşama 2'ye geçmeden düzeltmeniz istenir.

Aşama 2 (uygulama denetimi): Denetçi sahaya iner; kontrollerin gerçekten çalıştığına dair kanıt toplar. Log dosyaları, ekran görüntüleri, mülakatlar, geri yükleme testleri, erişim listeleri... hepsi masaya gelir. Buradaki majör uyumsuzluklar sertifikayı geciktirir; minörler için genellikle bir düzeltme planı sunmanız yeterlidir.

Aşama 2'yi geçerseniz sertifika düzenlenir ve üç yıl geçerli olur. Ama daha önce dediğimiz gibi, her yıl gözetim denetimi ve üçüncü yılda yeniden belgelendirme vardır. Aşağıdaki tablo tipik takvimi özetler:

Belgelendirme öncesi hazırlıkta erişim yönetimi kritik bir başlıktır. Zayıf parolalar ve MFA eksikliği, denetimde en sık çıkan bulgulardandır. Bu konuda güçlü parola politikası yazımızdaki ilkeleri uygulamak, A.5.17 ve A.8.5 kontrollerini rahatça karşılamanızı sağlar. Alan adı ve DNS yönetiminizin tek elden ve kayıtlı olması için alan adı hizmetlerinizi de envanterinizde tutmanız faydalı olur.

Teknik Kontrolleri Uygularken Pratik Örnekler#

ISO 27001 teknoloji-bağımsızdır; hangi ürünü kullandığınızı söylemez, sadece "riski yönet" der. Yine de teknik kontrolleri somut hâle getirmek, hem operasyonu güçlendirir hem de denetimde işinizi kolaylaştırır. Örneğin bir güvenlik olayına müdahale politikanızı basit bir yapılandırma dosyasıyla destekleyebilirsiniz:

# olay-mudahale.yaml — basit sınıflandırma
seviyeler:
  kritik:
    ornek: "Veri sızıntısı, fidye yazılımı"
    ilk_mudahale_dk: 30
    bildirim: ["CTO", "hukuk", "KVKK"]
  yuksek:
    ornek: "Yetkisiz erisim denemesi basarili"
    ilk_mudahale_dk: 60
    bildirim: ["sistem-yoneticisi", "CTO"]
  dusuk:
    ornek: "Tekil basarisiz oturum denemesi"
    ilk_mudahale_dk: 480
    bildirim: ["sistem-yoneticisi"]

Loglama ve izleme kontrolleri (A.8.15, A.8.16) için sunucuda merkezi log toplama ve zaman senkronizasyonu gibi temel ayarları netleştirmek gerekir:

; rsyslog / auditd için tipik saklama politikası
[log_retention]
guvenlik_loglari = 365   ; gün
uygulama_loglari = 90
zaman_kaynagi   = ntp.pool.org
saat_dilimi     = Europe/Istanbul

DNS tarafında, alan adı ele geçirmelerine karşı kayıt bütünlüğünü göstermek için CAA kaydı gibi basit ama etkili kontroller ekleyebilirsiniz:

; Yalnızca yetkili CA'nın sertifika basmasına izin ver
ornek.com.   IN CAA 0 issue "letsencrypt.org"
ornek.com.   IN CAA 0 iodef "mailto:[email protected]"

Bu tür somut yapılandırmalar, SoA'daki "Evet, uygulanıyor" ifadelerinin arkasını doldurur. Platform tarafında yönetilen barındırma, otomatik yedek ve güncel altyapı sunan bir sağlayıcıyla çalışmak, teknik kontrollerin bir kısmını hazır olarak devralmanızı sağlar; örneğin WordPress hosting veya reseller hosting paketlerinde güncelleme ve yedekleme süreçleri büyük ölçüde otomatiktir. DDoS gibi erişilebilirlik risklerini azaltmak için DDoS koruma katmanı da erişilebilirlik hedeflerinizi destekler.

Sıkça Sorulan Sorular#

ISO 27001 belgesi almak zorunlu mu?#

Yasal olarak çoğu sektörde zorunlu değildir, ancak ticari olarak giderek daha fazla talep edilmektedir. Kamu ihalelerinde, büyük kurumsal müşterilerle çalışırken ve finans ya da sağlık gibi hassas veri işleyen alanlarda ISO 27001 sertifikası çoğu zaman ön koşuldur. Zorunlu olmasa bile, sisteminizi kurma disiplini tek başına güvenlik olgunluğunuzu belirgin biçimde artırır.

ISO 27001 ile KVKK aynı şey mi?#

Hayır, ama birbirini güçlü biçimde tamamlarlar. KVKK bir yasadır ve kişisel verilerin korunmasına dair hukuki yükümlülükler getirir; ISO 27001 ise tüm bilgi varlıklarını kapsayan gönüllü bir yönetim standardıdır. ISO 27001 sistemini kurduğunuzda, kişisel verilere yönelik risk değerlendirmesi ve kontrolleri de bu çerçevenin içine oturur; böylece KVKK uyumu için sağlam bir zemin elde edersiniz. Yine de ISO 27001 belgesine sahip olmak, KVKK'ya tam uyduğunuz anlamına otomatik olarak gelmez.

Küçük bir şirket ISO 27001 alabilir mi?#

Kesinlikle alabilir. Standart ölçekten bağımsızdır ve kontrollerin derinliği kuruluşun büyüklüğüne göre ayarlanır. Beş kişilik bir yazılım ekibi, karmaşık bir bürokrasi kurmadan, birkaç net politika ve düzenli kayıtlarla sistemi işletebilir. Aslında küçük ekiplerde kararlar hızlı verildiği için sistemi canlı tutmak çoğu zaman daha kolaydır; asıl zorluk, kaynak kısıtı nedeniyle rollerin ayrılması ve iç denetimin tarafsızlığını sağlamaktır.

Belgelendirme süreci ne kadar sürer?#

Sıfırdan başlayan bir kuruluş için tipik süre altı ay ile bir yıl arasındadır. Bu sürenin çoğu belgeyi yazmak değil, sistemi gerçekten işletip kanıt biriktirmek için geçer; çünkü denetçi en az birkaç aylık kayıt görmek ister. Zaten bir güvenlik kültürüne ve dokümantasyona sahip firmalarda bu süre üç dört aya kadar inebilir. Aceleye getirilip kanıtsız çıkılan denetimler ise genellikle uyumsuzlukla geri döner.

Sertifikayı aldıktan sonra ne olur?#

Sertifika üç yıl geçerlidir ancak bu süre boyunca sistemin canlı kalması gerekir. Her yıl bir gözetim denetimi yapılır ve üçüncü yılın sonunda tüm sistem yeniden değerlendirilerek belge yenilenir. Bu arada risk değerlendirmenizi güncel tutmanız, olayları kaydetmeniz, iç denetim ve yönetim gözden geçirmelerini düzenli yapmanız beklenir. Kısacası sertifika bir bitiş çizgisi değil, sürekli işleyen bir döngünün resmi tescilidir.

Kapanış#

ISO 27001, özünde "bilgiyi ciddiye alan bir kuruluş nasıl davranır" sorusunun sistematik cevabıdır. Kapsamı belirlemek, riskleri ölçmek, doğru kontrolleri seçmek ve PUKÖ döngüsüyle sistemi canlı tutmak; bunların hepsi tek seferlik bir görev değil, kurum kültürünün parçası hâline gelmesi gereken alışkanlıklardır. Belgeyi almak önemlidir ama asıl kazanç, süreç boyunca kurduğunuz güvenlik disiplinidir.

Bu disiplinin teknik ayaklarını sağlam bir altyapı üzerine kurmak istiyorsanız Clou.TR yanınızda. Güncel ve yönetilen web hosting, performanslı VDS ve sanal sunucu seçenekleri, otomatik yedekleme, SSL sertifikası ve WAF katmanlarıyla ISO 27001 kontrollerinizin teknik tarafını kolayca karşılayabilirsiniz. Ek olarak sunucu yönetimi hizmetimizle güncelleme, izleme ve sertleştirme yükünü ekibinizden alabilir; güvenli bir temel üzerine yönetim sisteminizi rahatça inşa edebilirsiniz. Bilgi güvenliğine giden yolda ilk teknik adımı bugün atın.