WEBVTT 00:00.150 --> 00:01.770 -: Ağlarımızda popüler hale gelen 00:01.770 --> 00:03.540 en yeni sanallaştırma türü, konteynerleştirme 00:03.540 --> 00:05.790 olarak da bilinen konteyner tabanlı sanallaştırma 00:05.790 --> 00:07.980 olarak bilinir. 00:07.980 --> 00:10.290 Ancak bu tür sanallaştırma, son kullanıcı yerine 00:10.290 --> 00:12.780 sunuculara çok daha fazla odaklanmaktadır. 00:12.780 --> 00:14.460 Bu tür sanallaştırma ile işletim 00:14.460 --> 00:16.440 sistemi çekirdeği birden fazla sanal makine 00:16.440 --> 00:19.440 arasında paylaşılır, ancak her sanal makine için kullanıcı 00:19.440 --> 00:22.740 alanı benzersiz bir şekilde oluşturulur ve yönetilir. 00:22.740 --> 00:25.020 Konteynerleştirme, bir uygulama için yalıtılmış 00:25.020 --> 00:27.900 bir yürütme ortamı sağlamak üzere bir ana bilgisayar işletim 00:27.900 --> 00:31.230 sistemi tarafından uygulanan bir sanallaştırma türüdür. 00:31.230 --> 00:33.390 Konteynerleştirme, işletim sistemi düzeyinde 00:33.390 --> 00:35.370 kaynak segmentasyonunu ve ayrımını zorunlu 00:35.370 --> 00:38.280 kıldığı için oldukça güvenli kabul edilir. 00:38.280 --> 00:40.290 Artık konteynırlaştırma Linux sunucularında 00:40.290 --> 00:42.210 yaygın olarak kullanılıyor ve bu konteynır 00:42.210 --> 00:43.950 tabanlı sanallaştırmanın bazı örnekleri 00:43.950 --> 00:46.980 arasında Docker, Parallels Virtuozzo ve OpenVZ projesi gibi 00:46.980 --> 00:48.960 şeyler yer alıyor. 00:48.960 --> 00:51.870 Şimdi, konteynerizasyon gerçekten neye benziyor? 00:51.870 --> 00:53.610 Bir donanım parçanız ve bu donanımın 00:53.610 --> 00:56.460 üzerinde, genellikle Linux olan bir Ana İşletim Sisteminiz 00:56.460 --> 00:59.430 ve ardından bir konteyner yöneticiniz var. 00:59.430 --> 01:02.820 Kubernetes, Docker ya da bunun gibi bir şey. 01:02.820 --> 01:05.100 Şimdi bu konteyner yöneticisi, farklı uygulamalar 01:05.100 --> 01:08.070 içeren farklı konteynerler oluşturmak için kullanılacak. 01:08.070 --> 01:10.290 Bu durumda, üç konteynerim var. 01:10.290 --> 01:12.000 Ana işletim sisteminin çekirdeğine 01:12.000 --> 01:14.340 dayanan ilk ortamım var, bu örnekte kullanılan 01:14.340 --> 01:16.170 bir Linux sistemi. 01:16.170 --> 01:18.720 Ve böylece Linnux çalıştıran bir konteynerimiz var 01:18.720 --> 01:20.700 ve orada bazı uygulamalar içeriyor. 01:20.700 --> 01:23.130 Şimdi konteyner iki de aynı şeyi yapabilir ve 01:23.130 --> 01:25.290 konteyner üç de aynı şeyi yapabilir. 01:25.290 --> 01:27.210 Her üç konteyner de aynı ana bilgisayar işletim 01:27.210 --> 01:28.980 sistemi dosyalarını paylaştığından. 01:28.980 --> 01:30.750 Bu, sanal makineler kullanarak saf 01:30.750 --> 01:33.690 sanallaştırma yapmaktan çok daha az kaynak gerektirir. 01:33.690 --> 01:35.730 Sanallaştırma hakkında konuştuğumuz gibi. 01:35.730 --> 01:38.340 Bunun yerine ayrı sanal makineler kullanırsak, her birinin 01:38.340 --> 01:40.860 kendi işletim sistemi kopyasına ihtiyacı olacaktır. 01:40.860 --> 01:43.740 Ve bu her biri için 8 ila 10 gigabayt olabilir. 01:43.740 --> 01:45.000 Ancak konteynerler sayesinde 01:45.000 --> 01:47.280 hepimiz aynı işletim sistemini paylaşabiliriz. 01:47.280 --> 01:50.250 Dolayısıyla konteynerleştirme çok daha az depolama tabanı kullanır 01:50.250 --> 01:52.260 ve çok daha az işlem gücü gerektirir. 01:52.260 --> 01:55.050 Bu, operasyonel açıdan konteyner gibi bir şey kullanmanın 01:55.050 --> 01:56.970 gerçek faydasıdır. 01:56.970 --> 01:59.970 Çünkü bu konteynerler mantıksal olarak izole edilmiştir. 01:59.970 --> 02:02.100 Aslında birbirleriyle bağlantı kuramazlar. 02:02.100 --> 02:04.080 Eğer iki konteynerin konuşmasını istiyorsam, aslında 02:04.080 --> 02:06.480 onları sanal bir ağ üzerinden bağlamam ve konuşmalarını sağlamak 02:06.480 --> 02:07.890 için doğru yönlendirme ve anahtarlamayı 02:07.890 --> 02:09.330 yapmam gerekir. 02:09.330 --> 02:11.970 Varsayılan olarak, birbirleriyle konuşmalarının hiçbir 02:11.970 --> 02:14.310 yolu yoktur ve bu güvenlik açısından harika bir şeydir 02:14.310 --> 02:16.410 çünkü bu segmentasyona sahibiz. 02:16.410 --> 02:18.810 Şimdi, konteynırlarla uğraşmak söz konusu olduğunda 02:18.810 --> 02:20.010 büyük uyarınız. 02:20.010 --> 02:22.890 Bir saldırgan, örneğin az önce bahsettiğim Linux işletim 02:22.890 --> 02:24.990 sisteminin altındaki ana işletim sistemini 02:24.990 --> 02:27.960 tehlikeye atarsa, tahmin edin ne olur? 02:27.960 --> 02:30.810 Bu saldırı artık verilerindeki tüm konteynerlere erişebiliyor, 02:30.810 --> 02:33.270 çünkü bu tek işletim sistemi barındırılan tüm konteynerler 02:33.270 --> 02:35.790 tarafından kullanılıyor. 02:35.790 --> 02:37.440 Bu, konteyner kullandığınızda karşılaştığınız 02:37.440 --> 02:38.820 en büyük güvenlik açıklarından biridir. 02:38.820 --> 02:40.470 Şu anda 50 farklı sunucuyu çalıştıran bir 02:40.470 --> 02:42.240 konteyner sistemine sahip olabilirim. 02:42.240 --> 02:43.980 Ve bunların her biri konteynerizasyon kullanarak 02:43.980 --> 02:46.230 farklı sunucular ve hizmetler çalıştırıyor. 02:46.230 --> 02:49.050 Ancak bir kişi Linux işletim sistemi altındaki 02:49.050 --> 02:52.020 o tek sunucuya erişebilirse, artık barındırılan 02:52.020 --> 02:55.290 50 sunucunun tamamına ve tüm verilerine erişebilir. 02:55.290 --> 02:57.480 Dikkate alınması gereken bir başka risk de konteynerlerinizin 02:57.480 --> 03:00.390 ve diğer sanal makinelerinizin gerçekte nasıl barındırılacağıdır. 03:00.390 --> 03:03.210 Sanallaştırma ve bulut bilişime güvenmeye başladığımızda, 03:03.210 --> 03:05.040 verilerimizin başka bir kuruluşun verileriyle 03:05.040 --> 03:07.680 aynı fiziksel sunucuda barındırılabileceğini kabul etmek 03:07.680 --> 03:09.660 çok önemli hale gelir. 03:09.660 --> 03:12.120 Bunu yaparak, sistemlerimizin güvenliğine 03:12.120 --> 03:13.920 bazı açıklar getiriyoruz. 03:13.920 --> 03:16.950 İlk olarak, fiziksel sunucu diğer kuruluşlardan birinin 03:16.950 --> 03:18.960 yaptığı bir şey nedeniyle çökerse, 03:18.960 --> 03:19.880 aslında aynı sunucudaki 03:19.880 --> 03:22.500 tüm kuruluşları etkileyebilir. 03:22.500 --> 03:24.960 Benzer şekilde, bir kuruluş sanal ortamlarının 03:24.960 --> 03:26.760 güvenliğini sağlamıyorsa, bu fiziksel 03:26.760 --> 03:28.740 sunucuda barındırılıyorlarsa, bir 03:28.740 --> 03:31.470 saldırganın bunu aynı sunucuda barındırılan diğer 03:31.470 --> 03:33.900 tüm kuruluşların zararına kullanması olasılığı 03:33.900 --> 03:35.880 vardır. 03:35.880 --> 03:38.220 Tıpkı ağlarımızı bir başkasının ağına bağlarken ortaya 03:38.220 --> 03:40.170 çıkan endişeler gibi, birden fazla kuruluşun 03:40.170 --> 03:42.210 verilerini aynı fiziksel sunucuda barındırırken 03:42.210 --> 03:44.010 de endişeler vardır. 03:44.010 --> 03:46.530 Bu sunucularda barındırılan sanal makinelere kullanıcı 03:46.530 --> 03:48.780 erişimini düzgün bir şekilde yapılandırmak, yönetmek 03:48.780 --> 03:50.820 ve denetlemek bizim için önemlidir. 03:50.820 --> 03:53.850 Ayrıca, sanal makinelerimizin en son yamalara, antivirüs, 03:53.850 --> 03:56.580 animwire ve erişim kontrolüne sahip olduğundan 03:56.580 --> 03:58.410 emin olmak istiyoruz. 03:58.410 --> 03:59.760 Fiziksel sunucu kaynaklarının 03:59.760 --> 04:02.490 yetersiz kalması riskini en aza indirmek için sanal 04:02.490 --> 04:04.920 makinelerimizi uygun yük devretme, yedeklilik 04:04.920 --> 04:08.280 ve esneklikle kurmak her zaman iyi bir fikirdir. 04:08.280 --> 04:09.810 Ağ performansını ve fiziksel 04:09.810 --> 04:11.610 sunucu kaynaklarını izleyerek, 04:11.610 --> 04:13.500 yükü tek bir makineye güvenmek yerine 04:13.500 --> 04:17.370 birkaç fiziksel makine arasında dengeleyebilmeliyiz. 04:17.370 --> 04:19.290 Bir saldırgan tarafından istismar edilebilecek 04:19.290 --> 04:21.330 bir başka güvenlik açığı da tüm sanal makinelerimizde 04:21.330 --> 04:24.420 aynı tür hipervizör kullanmamızdır. 04:24.420 --> 04:27.180 Örneğin, kuruluşumuz yalnızca VMware'in ESXi 04:27.180 --> 04:29.700 hipervizörüne güveniyorsa ve bu hipervizör 04:29.700 --> 04:32.280 için yeni bir açık yaratılırsa, bir saldırgan 04:32.280 --> 04:35.790 bunu tüm sistemlerimize karşı kullanabilir. 04:35.790 --> 04:38.400 Dolayısıyla, sunucularımızdan birinde başarılı olursa, muhtemelen 04:38.400 --> 04:40.830 diğer sunucularımızda da deneyeceklerdir. 04:40.830 --> 04:43.260 Ve eğer tüm sunucularımız aynı platformu, 04:43.260 --> 04:46.410 bu durumda VMware'in ESXi'sini kullanıyorsa, bu güvenlik 04:46.410 --> 04:49.350 açığı tüm kuruluşumuzda istismar edilebilir. 04:49.350 --> 04:51.420 Bununla birlikte, birden fazla hipervizör 04:51.420 --> 04:53.700 platformu kullanırsak, destek maliyetlerimiz 04:53.700 --> 04:57.360 ve eğitim gereksinimlerimiz de artacaktır. 04:57.360 --> 05:00.090 Bu nedenle çoğu kuruluş tek bir platform kullanmayı tercih 05:00.090 --> 05:02.610 ediyor, ancak bunu yaptıklarında en azından ölçülü 05:02.610 --> 05:04.800 bir risk kararı vermiş oluyorlar. 05:04.800 --> 05:07.290 Bu riski azaltmak için kuruluş uygun yapılandırmaları 05:07.290 --> 05:09.690 kullanmalı, hipervizörün her zaman yamalı ve güncel 05:09.690 --> 05:11.520 kalmasını ve yalnızca güvenli bir yönetim 05:11.520 --> 05:14.280 arayüzü üzerinden erişilebilir olmasını sağlamalı ve erişim 05:14.280 --> 05:16.830 kontrolünü sıkı bir şekilde kontrol etmelidir. 05:16.830 --> 05:19.230 Bunlar, sistemlerinizi sanallaştırıp şirket içi veya 05:19.230 --> 05:21.570 bulut tabanlı bir çözüme taşıyıp taşımayacağınızı 05:21.570 --> 05:23.880 belirlemeye başlarken göz önünde bulundurmanız gereken 05:23.880 --> 05:25.410 şeylerden bazılarıdır. 05:25.410 --> 05:27.540 İlk olarak, sanallaştırma yapacak mısınız? 05:27.540 --> 05:30.360 Eğer öyleyse, geleneksel sanal makineleri mi kullanacaksınız yoksa 05:30.360 --> 05:32.430 konteynerleştirmeyi mi kullanacaksınız? 05:32.430 --> 05:34.410 Burada riske karşı ödül nedir? 05:34.410 --> 05:35.970 Yapmanız gereken dengeleyici bir hareket var. 05:35.970 --> 05:37.230 Bu bir iş kararıdır ve aynı 05:37.230 --> 05:39.780 zamanda bir siber güvenlik kararıdır. 05:39.780 --> 05:41.460 Dolayısıyla, bunları ölçmeniz ve 05:41.460 --> 05:44.100 kuruluşunuz ve belirli kullanım durumları için en iyi 05:44.100 --> 05:45.723 olanı seçmeniz gerekecektir.