CoreOS Kümenizi TLS/SSL ve Güvenlik Duvarı Kuralları ile Güvenli Hale Getirme

CoreOS Kümenizi TLS/SSL ve Güvenlik Duvarı Kuralları ile Güvenli Hale Getirme

Giriş

Günümüzün hızla değişen dijital dünyasında, konteyner tabanlı uygulamaların ve mikroservis mimarilerinin benimsenmesi, işletmeler için çeviklik ve ölçeklenebilirlik sağlamaktadır. Bu dönüşümün öncülerinden biri olan CoreOS (şimdi Fedora CoreOS olarak evrimleşmiş olsa da, temel güvenlik prensipleri geçerliliğini korumaktadır), konteyner iş yükleri için tasarlanmış minimalist, otomatik güncellenen ve güvenliğe odaklanmış bir işletim sistemidir. Ancak, CoreOS veya herhangi bir konteyner kümesinin potansiyel güvenlik risklerine karşı korunması, dağıtımın başarısı için kritik öneme sahiptir. Güvenlik ihlalleri, veri kaybına, hizmet kesintilerine ve itibar zedelenmelerine yol açabilir. Bu teknik makale, CoreOS kümelerinizi iki temel mekanizma olan TLS/SSL şifrelemesi ve sağlam güvenlik duvarı kuralları kullanarak nasıl güvenli hale getireceğinizi ayrıntılı olarak ele alacaktır. Amacımız, hem iletişim güvenliğini sağlamak hem de yetkisiz erişimi engellemek için kapsamlı bir rehber sunmaktır.

CoreOS/Fedora CoreOS’u Anlamak

CoreOS, Google’ın Chrome OS’undan ilham alan, konteynerleştirilmiş iş yükleri için optimize edilmiş, Linux tabanlı bir işletim sistemidir. Temel felsefesi, minimalizm, otomatik güncellemeler ve güvenliktir. Immutable (değişmez) dosya sistemi sayesinde, sistemin temel bileşenleri üretim sırasında değiştirilemez, bu da kötü amaçlı yazılımların kalıcı olmasını zorlaştırır. Fedora CoreOS ise bu mirasın devamıdır ve Kubernetes gibi orkestrasyon araçlarıyla derin entegrasyon sunar.

CoreOS’un güvenlik modeli, geleneksel sunucu işletim sistemlerinden farklıdır. Uygulamalar konteynerler içinde izole edilirken, işletim sisteminin kendisi de sıkı bir şekilde kontrol edilir. Bu, güvenlik stratejilerini oluştururken hem işletim sistemi seviyesinde hem de konteyner orkestrasyon seviyesinde düşünmeyi gerektirir. Güvenlik, yalnızca bir eklenti değil, tasarımın ayrılmaz bir parçası olmalıdır.

Konteyner Orkestrasyonunda Güvenliğin Önemi

Konteyner orkestrasyonu, dağıtık sistemlerin karmaşıklığını yönetirken aynı zamanda yeni güvenlik zorlukları da beraberinde getirir. Bir CoreOS kümesinde, her bir düğüm (node) üzerinde çalışan birden fazla konteyner, birbirleriyle ve dış dünya ile iletişim kurar. Bu iletişim kanallarının ve erişim noktalarının güvence altına alınması hayati önem taşır. Potansiyel güvenlik açıkları şunları içerebilir:
* Host İşletim Sistemi Zafiyetleri: Temel işletim sistemindeki güvenlik açıkları, tüm kümenin tehlikeye girmesine neden olabilir.
* Konteyner İmaj Zafiyetleri: Güvenilmeyen veya güncel olmayan imajlar, bilinen güvenlik açıklarını içerebilir.
* Runtime Zafiyetleri: Konteyner çalışma zamanı (runtime) motorundaki (örneğin, containerd, CRI-O) zafiyetler.
* Ağ Zafiyetleri: Yetkisiz ağ erişimi, dinleme (eavesdropping) veya hizmet reddi (DoS) saldırıları.
* API Zafiyetleri: Kubernetes API sunucusuna yetkisiz erişim, kümenin kontrolünün ele geçirilmesine yol açabilir.

Bu riskleri azaltmak için çok katmanlı bir güvenlik yaklaşımı benimsemek şarttır. TLS/SSL ve güvenlik duvarı kuralları, bu katmanlı yaklaşımın temelini oluşturur.

TLS/SSL ile İletişim Güvenliği

TLS (Transport Layer Security) ve selefi SSL (Secure Sockets Layer), internet üzerinden güvenli iletişim sağlamak için kullanılan kriptografik protokollerdir. CoreOS kümesi gibi dağıtık sistemlerde, düğümler arası ve istemci-sunucu arasındaki tüm iletişim kanallarının şifrelenmesi ve kimlik doğrulaması kritik öneme sahiptir.

TLS/SSL Nedir?

TLS/SSL, üç temel güvenlik hizmeti sunar:
* Şifreleme: İletilen verilerin yetkisiz kişiler tarafından okunmasını engeller.
* Kimlik Doğrulama: İletişimin her iki tarafının da iddia ettikleri taraf olduğunu doğrular. Bu, genellikle dijital sertifikalar aracılığıyla yapılır.
* Veri Bütünlüğü: İletilen verilerin aktarım sırasında değiştirilmediğini garanti eder.

Bu özellikler, bir saldırganın ağ trafiğini dinlemesini, verileri değiştirmesini veya sahte bir bileşen olarak davranmasını engeller.

CoreOS Kümeleri İçin TLS/SSL Neden Önemli?

Bir CoreOS kümesinde, özellikle Kubernetes gibi bir orkestrasyon aracı kullanılıyorsa, birçok bileşen birbiriyle iletişim kurar:
* Kubernetes API Sunucusu: Tüm küme yönetiminin merkezi noktasıdır. kubectl gibi istemciler ve diğer kontrol düzlemi bileşenleri bu sunucuyla iletişim kurar. Bu iletişimin şifrelenmesi ve kimlik doğrulaması zorunludur.
* etcd: Kubernetes’in tüm küme verilerini depoladığı dağıtık anahtar-değer deposudur. etcd sunucuları arasındaki ve etcd ile API sunucusu arasındaki iletişimin güvenliği, kümenin durumunun bütünlüğü için hayati öneme sahiptir.
* Kubelet: Her worker düğümünde çalışan aracıdır. API sunucusuyla iletişim kurar ve konteynerleri yönetir. Kubelet’in API sunucusuna ve API sunucusunun Kubelet’e güvenli bir şekilde bağlanması gerekir.
* Kontrol Düzlemi Bileşenleri: Kube-scheduler, Kube-controller-manager gibi bileşenler de API sunucusuyla iletişim kurar.
* Düğümler Arası İletişim: Pod’lar arası iletişim, hizmet ağı (service network) trafiği gibi.

Bu bileşenler arasındaki tüm iletişimin TLS/SSL ile güvence altına alınması, Man-in-the-Middle (MITM) saldırılarını ve veri sızıntılarını önler.

TLS/SSL Uygulama Adımları

CoreOS kümenizde TLS/SSL’i etkinleştirmek için genellikle bir Sertifika Yetkilisi (CA) oluşturmanız ve ardından bu CA tarafından imzalanmış sunucu ve istemci sertifikalarını dağıtmanız gerekir.

Sertifika Yetkilisi (CA) Oluşturma

Kümenizin kendi özel Sertifika Yetkilisi’ne sahip olması, tüm iç bileşenler için güvenilir bir kök oluşturur. Bu, genellikle kendi kendine imzalı (self-signed) bir CA olacaktır. openssl veya cfssl gibi araçlar kullanılabilir.
1. CA Anahtarı ve Sertifikası Oluşturma:

openssl genrsa -out ca.key 2048
    openssl req -x509 -new -nodes -key ca.key -days 3650 -out ca.crt -subj "/CN=KUBERNETES-CA"

Burada ca.key özel anahtarınız, ca.crt ise genel sertifikanızdır. CN (Common Name) sertifikanın ne için olduğunu belirtir.

Sunucu Sertifikaları Oluşturma

Kubernetes API Sunucusu, etcd sunucuları ve Kubelet gibi her sunucu bileşeni için bir sertifika oluşturulmalıdır.
1. API Sunucusu İçin Sertifika:
API sunucusu sertifikası, kümenin tüm IP adreslerini, DNS adlarını ve hizmet IP’lerini içermelidir (Subject Alternative Names – SANs).
* Anahtar Oluşturma:

openssl genrsa -out apiserver.key 2048

* Sertifika İmzalama İsteği (CSR) Oluşturma:
apiserver.csr için bir yapılandırma dosyası (örneğin apiserver.cnf) oluşturulur. Bu dosyada [alt_names] bölümünde tüm IP adresleri ve DNS adları belirtilmelidir.

[req]
        req_extensions = v3_req
        distinguished_name = req_distinguished_name
        [req_distinguished_name]
        [v3_req]
        keyUsage = critical, digitalSignature, keyEncipherment
        extendedKeyUsage = serverAuth
        subjectAltName = @alt_names
        [alt_names]
        DNS.1 = kubernetes
        DNS.2 = kubernetes.default
        DNS.3 = kubernetes.default.svc
        DNS.4 = kubernetes.default.svc.cluster.local
        IP.1 = 10.96.0.1          # Kubernetes hizmet IP'si
        IP.2 = 192.168.1.100     # API Sunucusu düğüm IP'si
        IP.3 = 127.0.0.1

Ardından CSR oluşturulur:

openssl req -new -key apiserver.key -out apiserver.csr -subj "/CN=kube-apiserver" -config apiserver.cnf

* CA ile İmzalama:

openssl x509 -req -in apiserver.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out apiserver.crt -days 3650 -extensions v3_req -extfile apiserver.cnf

2. etcd Sunucuları İçin Sertifikalar: Her etcd düğümü için benzer adımlar izlenir. SANs, etcd düğümlerinin IP adreslerini içermelidir.
3. Kubelet Sertifikaları: Her worker düğümündeki Kubelet için sertifika oluşturulur. Kubelet’in CN değeri genellikle system:node: formatında olur.

İstemci Sertifikaları Oluşturma

kubectl gibi yönetim araçları, kube-proxy, kube-controller-manager ve kube-scheduler gibi diğer kontrol düzlemi bileşenleri için de istemci sertifikaları gereklidir.
* Admin Kullanıcısı İçin Sertifika:

openssl genrsa -out admin.key 2048
    openssl req -new -key admin.key -out admin.csr -subj "/CN=admin/O=system:masters"
    openssl x509 -req -in admin.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out admin.crt -days 3650

/O=system:masters ifadesi, bu kullanıcının Kubernetes’te süper yönetici yetkilerine sahip olmasını sağlar.
* Diğer bileşenler için de benzer adımlar izlenir, ancak CN ve O değerleri ilgili bileşenin kimliğini yansıtmalıdır (örn. CN=system:kube-proxy).

Sertifikaları Dağıtma ve Yapılandırma

Oluşturulan sertifikalar ve anahtarlar, CoreOS düğümlerine ve Kubernetes bileşenlerine dağıtılmalıdır.
* CoreOS Düğümleri: Sertifikalar, Ignition dosyaları veya systemd birimleri aracılığıyla /etc/kubernetes/pki/ gibi uygun bir dizine kopyalanabilir.
* Kubernetes Bileşenleri: Her bileşenin (API Sunucusu, etcd, Kubelet vb.) yapılandırma dosyaları (genellikle YAML dosyaları), kullanacağı sertifika, anahtar ve CA sertifikasının yollarını belirtecek şekilde güncellenmelidir. Örneğin, Kubernetes API sunucusu için --tls-cert-file, --tls-private-key-file, --client-ca-file parametreleri kullanılır.
* Kubeconfig Dosyaları: kubectl gibi istemciler için, CA sertifikasını, istemci sertifikasını ve anahtarını içeren kubeconfig dosyaları oluşturulmalıdır.

TLS Şifrelemesini Doğrulama

Tüm yapılandırmalar tamamlandıktan sonra, TLS’in düzgün çalıştığını doğrulamak önemlidir.
* kubectl cluster-info dump komutu, küme bileşenlerinin dinlediği portları ve sertifika bilgilerini gösterebilir.
* curl -k https://:6443 komutunu kullanarak API sunucusuna bağlanmayı deneyin. -k (insecure) bayrağı olmadan, istemcinin CA sertifikasına güvenmesi gerekir.
* Logları kontrol edin. Bileşenlerin TLS ile ilgili hatalar vermediğinden emin olun.

Güvenlik Duvarı Kuralları ile Ağ Güvenliği

Güvenlik duvarı (firewall) kuralları, CoreOS kümenizi yetkisiz ağ erişimine karşı korumanın ilk ve en temel savunma hattıdır. Gelen ve giden ağ trafiğini kontrol ederek, yalnızca izin verilen iletişime olanak tanır ve kötü niyetli veya gereksiz bağlantıları engeller.

Güvenlik Duvarı Neden Önemli?

* Erişim Kontrolü: Küme düğümlerine veya konteynerlere yetkisiz erişimi önler.
* Saldırı Yüzeyini Azaltma: Yalnızca gerekli portları açarak potansiyel saldırı vektörlerini sınırlar.
* İzolasyon: Küme bileşenlerini veya farklı ağ segmentlerini birbirinden izole eder.
* Minimum Ayrıcalık İlkesi: Yalnızca belirli kaynakların belirli hizmetlere erişmesine izin verir.

CoreOS’ta Güvenlik Duvarı Yönetimi

Fedora CoreOS, varsayılan olarak firewalld hizmetini kullanır. firewalld, dinamik bir güvenlik duvarı yönetim aracıdır ve bölgeler (zones) kavramını kullanarak farklı ağ arabirimleri için farklı güvenlik seviyeleri tanımlamanıza olanak tanır. Alternatif olarak, iptables veya nftables de kullanılabilir, ancak firewalld daha yüksek seviyeli ve kullanımı kolay bir arayüz sunar.

Kalıcı Güvenlik Duvarı Kuralları

CoreOS’un immutable yapısı nedeniyle, güvenlik duvarı kurallarının kalıcı olması için firewalld yapılandırma dosyalarını doğrudan düzenlemek veya Ignition dosyaları aracılığıyla kuralları dağıtmak en iyi yaklaşımdır.
* Ignition ile Kurallar: İlk önyükleme sırasında güvenlik duvarı kurallarını uygulamak için Ignition dosyaları kullanılabilir. Bu, sistemin ilk kez başlatıldığında tamamen güvenli olmasını sağlar.
* Systemd Birimleri: firewalld hizmetini yapılandırmak için systemd birimleri kullanılabilir. Örneğin, bir firewalld hizmeti için ek yapılandırma sağlamak veya belirli portları açan komutları bir ExecStartPost betiği olarak çalıştırmak.

Gerekli Bağlantı Noktaları ve Protokoller

Bir Kubernetes kümesinde, çeşitli bileşenler arasında iletişim için belirli portların açık olması gerekir. Bu portlar, kümenizin dağıtımına ve kullandığınız CNI (Container Network Interface) eklentisine göre değişiklik gösterebilir. Aşağıda tipik bir Kubernetes kümesi için temel portlar listelenmiştir:

Kubernetes Kontrol Düzlemi (Master Düğümleri) İçin:

* TCP 6443 (veya 443): Kubernetes API Sunucusu. kubectl ve diğer bileşenler buraya bağlanır.
* TCP 2379-2380: etcd sunucuları arası iletişim ve etcd istemci portları.
* TCP 10250: Kubelet API. API sunucusu, Kubelet ile iletişim kurmak için kullanır.
* TCP 10257: Kube-controller-manager.
* TCP 10259: Kube-scheduler.
* TCP 22: SSH erişimi (sadece yönetim için, kısıtlı IP’lerden).

Worker Düğümleri İçin:

* TCP 10250: Kubelet API.
* TCP 10255: Kubelet’in salt okunur API’si (genellikle kapatılır).
* TCP 30000-32767: NodePort hizmetleri için varsayılan aralık.
* UDP (çeşitli portlar): CNI eklentisine bağlı olarak (örneğin, Flannel için UDP 8472, Calico için TCP 4789).
* TCP 22: SSH erişimi (sadece yönetim için, kısıtlı IP’lerden).

Genel Kurallar:

* Düğümler Arası İletişim: Tüm düğümlerin birbirleriyle Pod ağı üzerinden iletişim kurması gerekir. Bu, CNI eklentinizin gerektirdiği portları içerir.
* Harici Erişim: Yalnızca gerçekten gerekli olan hizmetler (örneğin, Ingress Controller veya Load Balancer tarafından sunulan uygulamalar) dışarıdan erişilebilir olmalıdır.

Güvenlik Duvarı Kuralı Uygulama Örnekleri (firewalld)

firewalld kullanarak kuralları tanımlamak için firewall-cmd komutu kullanılır. Kalıcı olması için --permanent bayrağını eklemeyi ve ardından firewall-cmd --reload komutuyla değişiklikleri yüklemeyi unutmayın.

1. Varsayılan Olarak Tümünü Reddet (Deny-All):
En güvenli yaklaşım, varsayılan olarak tüm gelen bağlantıları reddetmek ve yalnızca belirli portları veya hizmetleri beyaz listeye almaktır.

firewall-cmd --zone=public --set-target=DROP --permanent

2. SSH Erişimi Açma (Yalnızca Belirli IP’lerden):

firewall-cmd --zone=public --add-source=192.168.1.0/24 --add-service=ssh --permanent
    # Veya belirli bir port için:
    firewall-cmd --zone=public --add-source=192.168.1.0/24 --add-port=22/tcp --permanent

3. Kubernetes API Sunucusu Portunu Açma (Master Düğümde):

firewall-cmd --zone=public --add-port=6443/tcp --permanent

4. etcd Portlarını Açma (Master Düğümlerinde):
etcd portları genellikle yalnızca diğer etcd düğümleri ve Kubernetes API sunucusu tarafından erişilebilir olmalıdır.

# etcd istemci portu (API sunucusu için)
    firewall-cmd --zone=public --add-source= --add-port=2379/tcp --permanent
    # etcd peer portu (diğer etcd düğümleri için)
    firewall-cmd --zone=public --add-source= --add-port=2380/tcp --permanent

5. Kubelet Portunu Açma (Tüm Düğümlerde):
API sunucusunun Kubelet’e erişmesi için.

firewall-cmd --zone=public --add-source= --add-port=10250/tcp --permanent

6. CNI Eklentisi Portlarını Açma (Tüm Düğümlerde):
Örneğin, Flannel için:

firewall-cmd --zone=public --add-port=8472/udp --permanent

7. Değişiklikleri Yükleme:

firewall-cmd --reload

En İyi Güvenlik Duvarı Uygulamaları

* Minimum Ayrıcalık İlkesi: Yalnızca kesinlikle gerekli olan portları ve protokolleri açın. “Her şeyi aç” yaklaşımından kaçının.
* IP Beyaz Listeleme (Whitelisting): Mümkün olduğunda, erişime izin verilen kaynak IP adreslerini veya IP aralıklarını belirtin. Bu, saldırı yüzeyini önemli ölçüde azaltır.
* Ağ Segmentasyonu: Küme içindeki farklı bileşenleri (kontrol düzlemi, worker düğümleri, etcd) farklı ağ segmentlerine ayırın ve bu segmentler arasında sıkı güvenlik duvarı kuralları uygulayın.
* Loglama ve İzleme: Güvenlik duvarı reddetme olaylarını loglayın ve bu logları merkezi bir sistemde izleyin. Anormal aktiviteyi tespit etmek için bu loglar çok değerlidir.
* Düzenli İnceleme: Güvenlik duvarı kurallarınızı düzenli olarak gözden geçirin ve küme mimarisi veya uygulama gereksinimleri değiştikçe güncelleyin.
* DDoS Koruması: Dışarıdan gelen trafiği dengeleyen ve DDoS saldırılarını hafifleten bir yük dengeleyici veya CDN kullanmayı düşünün.

Diğer Güvenlik Katmanları ve En İyi Uygulamalar

TLS/SSL ve güvenlik duvarı kuralları temel güvenlik katmanları olsa da, kapsamlı bir CoreOS küme güvenliği stratejisi daha fazla katmanı içermelidir.

Kimlik Doğrulama ve Yetkilendirme

* RBAC (Role-Based Access Control): Kubernetes’te kullanıcıların ve hizmet hesaplarının küme kaynaklarına erişimini en ince ayrıntısına kadar kontrol etmek için RBAC kullanın. Minimum ayrıcalık ilkesini uygulayın.
* OIDC/LDAP Entegrasyonu: Kurumsal kimlik sağlayıcılarınızla Kubernetes’i entegre ederek merkezi kimlik yönetimi sağlayın.

Runtime Güvenliği

* Pod Security Standards (PSS): Pod’ların güvenlik bağlamlarını (security contexts) ve diğer güvenlik ayarlarını zorunlu kılmak için PSS’yi kullanın.
* Seccomp, AppArmor, SELinux: Konteynerlerin sistem çağrılarını kısıtlayarak veya dosya sistemi erişimini kontrol ederek kernel düzeyinde güvenlik sağlayın.
* Güvenlik Bağlamları: Konteynerlerin root olarak çalışmasını engelleyin, okuma-yazma dosya sistemlerini kısıtlayın ve ayrıcalıklı (privileged) konteyner kullanımından kaçının.

İmaj Güvenliği

* Güvenilir Kaynaklar: Konteyner imajlarını yalnızca güvenilir ve doğrulanmış kaynaklardan (örn. kendi özel kayıt defteriniz) çekin.
* İmaj Tarama: Konteyner imajlarını bilinen güvenlik açıkları için tarayın ve dağıtımdan önce bu açıkları giderin.
* Azaltılmış Boyutlu İmajlar: “Distroless” veya minimal taban imajları kullanarak saldırı yüzeyini azaltın.

Güncelleme ve Yama Yönetimi

* Otomatik CoreOS Güncellemeleri: CoreOS’un otomatik güncelleme mekanizmasını etkinleştirin ve yönetin. Bu, işletim sistemi düzeyindeki güvenlik açıklarının hızla kapatılmasını sağlar.
* Kubernetes Versiyon Güncellemeleri: Kubernetes’i düzenli olarak en son kararlı sürüme güncelleyin. Yeni sürümler genellikle güvenlik yamaları ve iyileştirmeler içerir.

Loglama ve İzleme

* Merkezi Log Yönetimi: Küme loglarını (Kubernetes denetim logları, konteyner logları, sistem logları) merkezi bir log yönetim sistemine (örn. ELK Stack, Grafana Loki) gönderin.
* İzleme ve Uyarı: Küme metriklerini ve güvenlik olaylarını izleyin. Anormal davranışlar veya güvenlik ihlalleri durumunda otomatik uyarılar yapılandırın.

Veri Şifreleme

* Disk Şifrelemesi: Düğümlerdeki hassas verileri depolayan diskleri (örn. etcd verileri) LUKS gibi araçlarla şifreleyin.
* Kubernetes Secret Şifrelemesi: Kubernetes Secret’ları, etcd’de şifrelenmiş olarak saklanmalıdır. Bu, API sunucusu etcd’ye veri yazarken şifreleme anahtarları kullanarak hassas verilerin okunmasını engeller.

Sonuç

CoreOS (veya Fedora CoreOS) kümelerini güvenli hale getirmek, sürekli dikkat ve çok katmanlı bir yaklaşım gerektiren karmaşık ancak zorunlu bir süreçtir. TLS/SSL şifrelemesi, küme bileşenleri arasındaki iletişimin gizliliğini, bütünlüğünü ve kimlik doğrulamasını sağlarken, sağlam güvenlik duvarı kuralları yetkisiz ağ erişimine karşı ilk savunma hattını oluşturur. Bu iki mekanizma, kümenizin temel güvenlik duruşunun temel taşlarıdır.

Ancak, yalnızca TLS/SSL ve güvenlik duvarı kurallarıyla yetinmek yeterli değildir. Kapsamlı bir güvenlik stratejisi; RBAC ile yetkilendirme, runtime güvenliği, imaj tarama, düzenli güncellemeler, merkezi loglama ve veri şifrelemesi gibi diğer güvenlik katmanlarını da içermelidir. Her bir katman, potansiyel bir saldırganın kümenize sızmasını daha da zorlaştırır.

Unutmayın ki güvenlik, tek seferlik bir işlem değil, sürekli bir süreçtir. Küme mimarisi geliştikçe, yeni zafiyetler ortaya çıktıkça ve tehdit ortamı değiştikçe güvenlik stratejilerinizi düzenli olarak gözden geçirmeli, test etmeli ve güncellemelisiniz. Bu makalede sunulan yönergeleri uygulayarak, CoreOS kümenizin güvenliğini önemli ölçüde artırabilir ve kritik iş yüklerinizi potansiyel tehditlere karşı koruyabilirsiniz. Güvenli bir küme, hem operasyonel verimlilik hem de iş sürekliliği için temel bir ön koşuldur.