WEBVTT 00:00.150 --> 00:01.770 -: Najnowszym typem wirtualizacji, 00:01.770 --> 00:03.540 który staje się popularny w naszych sieciach, 00:03.540 --> 00:05.790 jest wirtualizacja oparta na kontenerach, znana 00:05.790 --> 00:07.980 również jako konteneryzacja. 00:07.980 --> 00:10.290 Ten typ wirtualizacji jest jednak znacznie bardziej skoncentrowany 00:10.290 --> 00:12.780 na serwerach niż na użytkowniku końcowym. 00:12.780 --> 00:14.460 W przypadku tego typu wirtualizacji jądro 00:14.460 --> 00:16.440 systemu operacyjnego jest współdzielone przez 00:16.440 --> 00:19.440 wiele maszyn wirtualnych, ale przestrzeń użytkownika dla każdej maszyny 00:19.440 --> 00:22.740 wirtualnej jest tworzona i zarządzana w unikalny sposób. 00:22.740 --> 00:25.020 Konteneryzacja to rodzaj wirtualizacji stosowany 00:25.020 --> 00:27.900 przez system operacyjny hosta w celu zapewnienia izolowanego 00:27.900 --> 00:31.230 środowiska wykonawczego dla aplikacji. 00:31.230 --> 00:33.390 Konteneryzacja jest uważana za dość bezpieczną, 00:33.390 --> 00:35.370 ponieważ wymusza segmentację i separację 00:35.370 --> 00:38.280 zasobów na poziomie systemu operacyjnego. 00:38.280 --> 00:40.290 Obecnie konteneryzacja jest powszechnie 00:40.290 --> 00:42.210 stosowana w serwerach Linux, a niektóre 00:42.210 --> 00:43.950 przykłady wirtualizacji opartej 00:43.950 --> 00:46.980 na kontenerach obejmują takie rzeczy jak Docker, Parallels 00:46.980 --> 00:48.960 Virtuozzo i projekt OpenVZ. 00:48.960 --> 00:51.870 Jak naprawdę wygląda konteneryzacja? 00:51.870 --> 00:53.610 Cóż, masz kawałek sprzętu, a następnie 00:53.610 --> 00:56.460 na tym sprzęcie masz system operacyjny hosta, zwykle 00:56.460 --> 00:59.430 Linux, a następnie masz menedżera kontenerów. 00:59.430 --> 01:02.820 Coś takiego jak Kubernetes, Docker lub coś podobnego. 01:02.820 --> 01:05.100 Teraz ten menedżer kontenerów będzie używany do tworzenia 01:05.100 --> 01:08.070 różnych kontenerów zawierających różne aplikacje. 01:08.070 --> 01:10.290 W tym przypadku mam trzy pojemniki. 01:10.290 --> 01:12.000 Mam pierwsze środowisko, które jest oparte 01:12.000 --> 01:14.340 na jądrze systemu operacyjnego hosta, w tym przykładzie 01:14.340 --> 01:16.170 używanego systemu Linux. 01:16.170 --> 01:18.720 Mamy więc kontener z systemem Linnux, który 01:18.720 --> 01:20.700 zawiera kilka aplikacji. 01:20.700 --> 01:23.130 Teraz pojemnik drugi może zrobić to samo, a 01:23.130 --> 01:25.290 pojemnik trzeci może zrobić to samo. 01:25.290 --> 01:27.210 Ponieważ wszystkie trzy kontenery współdzielą 01:27.210 --> 01:28.980 te same pliki systemu operacyjnego hosta. 01:28.980 --> 01:30.750 Zajmuje to znacznie mniej zasobów niż 01:30.750 --> 01:33.690 czysta wirtualizacja przy użyciu maszyn wirtualnych. 01:33.690 --> 01:35.730 Podobnie jak w przypadku wirtualizacji. 01:35.730 --> 01:38.340 Jeśli zamiast tego użylibyśmy pojedynczych maszyn wirtualnych, każda 01:38.340 --> 01:40.860 z nich potrzebowałaby własnej kopii systemu operacyjnego. 01:40.860 --> 01:43.740 Może to być od 8 do 10 gigabajtów na każdy z nich. 01:43.740 --> 01:45.000 Ale dzięki kontenerom wszyscy 01:45.000 --> 01:47.280 możemy współdzielić ten sam system operacyjny. 01:47.280 --> 01:50.250 Konteneryzacja wykorzystuje więc znacznie mniej pamięci masowej 01:50.250 --> 01:52.260 i wymaga znacznie mniej mocy obliczeniowej. 01:52.260 --> 01:55.050 Jest to prawdziwa zaleta korzystania z czegoś takiego jak 01:55.050 --> 01:56.970 kontener z perspektywy operacyjnej. 01:56.970 --> 01:59.970 Teraz, ponieważ te kontenery są logicznie odizolowane. 01:59.970 --> 02:02.100 W rzeczywistości nie mogą one ze sobą współpracować. 02:02.100 --> 02:04.080 Jeśli chcę, aby dwa kontenery ze sobą rozmawiały, 02:04.080 --> 02:06.480 muszę połączyć je za pośrednictwem sieci wirtualnej i wykonać 02:06.480 --> 02:07.890 odpowiedni routing i przełączanie, 02:07.890 --> 02:09.330 aby umożliwić im rozmowę. 02:09.330 --> 02:11.970 Domyślnie nie mają one możliwości komunikowania się ze 02:11.970 --> 02:14.310 sobą i jest to świetna rzecz z punktu widzenia bezpieczeństwa, 02:14.310 --> 02:16.410 ponieważ mamy tę segmentację. 02:16.410 --> 02:18.810 Oto najważniejsze ostrzeżenie, jeśli chodzi 02:18.810 --> 02:20.010 o kontenery. 02:20.010 --> 02:22.890 Jeśli atakujący włamie się do systemu operacyjnego hosta, 02:22.890 --> 02:24.990 na przykład systemu operacyjnego Linux, 02:24.990 --> 02:27.960 o którym właśnie mówiłem, zgadnij, co się stanie? 02:27.960 --> 02:30.810 Cóż, ten atak ma teraz dostęp do wszystkich kontenerów w swoich 02:30.810 --> 02:33.270 danych, ponieważ ten jeden system operacyjny jest 02:33.270 --> 02:35.790 używany przez wszystkie hostowane kontenery. 02:35.790 --> 02:37.440 Jest to jedna z największych luk w zabezpieczeniach 02:37.440 --> 02:38.820 podczas korzystania z kontenerów. 02:38.820 --> 02:40.470 Mogę mieć system kontenerowy, który obsługuje 02:40.470 --> 02:42.240 obecnie 50 różnych serwerów. 02:42.240 --> 02:43.980 Na każdym z nich działają różne serwery 02:43.980 --> 02:46.230 i usługi wykorzystujące konteneryzację. 02:46.230 --> 02:49.050 Ale jeśli ktoś jest w stanie dostać się do tego jednego serwera 02:49.050 --> 02:52.020 pod tym systemem operacyjnym Linux, ma teraz dostęp do wszystkich 02:52.020 --> 02:55.290 50 hostowanych serwerów i wszystkich ich danych. 02:55.290 --> 02:57.480 Kolejnym ryzykiem, które należy wziąć pod uwagę, 02:57.480 --> 03:00.390 jest sposób hostowania kontenerów i innych maszyn wirtualnych. 03:00.390 --> 03:03.210 Gdy zaczynamy polegać na wirtualizacji i przetwarzaniu w chmurze, 03:03.210 --> 03:05.040 bardzo ważne staje się rozpoznanie, że 03:05.040 --> 03:07.680 nasze dane mogą być hostowane na tym samym serwerze fizycznym, 03:07.680 --> 03:09.660 co dane innej organizacji. 03:09.660 --> 03:12.120 W ten sposób wprowadzamy pewne luki w zabezpieczeniach 03:12.120 --> 03:13.920 naszych systemów. 03:13.920 --> 03:16.950 Po pierwsze, jeśli serwer fizyczny ulegnie awarii z powodu działań 03:16.950 --> 03:18.960 jednej z innych organizacji, może to faktycznie 03:18.960 --> 03:19.880 wpłynąć na wszystkie 03:19.880 --> 03:22.500 organizacje na tym samym serwerze. 03:22.500 --> 03:24.960 Podobnie, jeśli jedna organizacja nie utrzymuje bezpieczeństwa 03:24.960 --> 03:26.760 swoich środowisk wirtualnych, są one 03:26.760 --> 03:28.740 hostowane na tym fizycznym serwerze, istnieje 03:28.740 --> 03:31.470 możliwość, że atakujący może to wykorzystać ze szkodą dla 03:31.470 --> 03:33.900 wszystkich innych organizacji hostowanych na tym 03:33.900 --> 03:35.880 samym serwerze. 03:35.880 --> 03:38.220 Podobnie jak istnieją obawy związane z łączeniem naszych 03:38.220 --> 03:40.170 sieci z sieciami innych firm, istnieją również obawy 03:40.170 --> 03:42.210 związane z przechowywaniem danych wielu organizacji 03:42.210 --> 03:44.010 na tym samym serwerze fizycznym. 03:44.010 --> 03:46.530 Ważne jest dla nas prawidłowe skonfigurowanie, zarządzanie 03:46.530 --> 03:48.780 i audytowanie dostępu użytkowników do maszyn wirtualnych 03:48.780 --> 03:50.820 hostowanych na tych serwerach. 03:50.820 --> 03:53.850 Ponadto chcemy mieć pewność, że nasze maszyny wirtualne mają 03:53.850 --> 03:56.580 zainstalowane najnowsze łatki, programy antywirusowe, 03:56.580 --> 03:58.410 animwire i kontrolę dostępu. 03:58.410 --> 03:59.760 Aby zminimalizować ryzyko przeciążenia 03:59.760 --> 04:02.490 zasobów serwerów fizycznych, zawsze dobrym pomysłem jest skonfigurowanie 04:02.490 --> 04:04.920 naszych maszyn wirtualnych z odpowiednim przełączaniem 04:04.920 --> 04:08.280 awaryjnym, redundancją i elastycznością. 04:08.280 --> 04:09.810 Monitorując wydajność sieci 04:09.810 --> 04:11.610 i zasoby serwerów fizycznych, powinniśmy 04:11.610 --> 04:13.500 być w stanie zrównoważyć obciążenie 04:13.500 --> 04:15.570 na kilku maszynach fizycznych, zamiast 04:15.570 --> 04:17.370 polegać tylko na jednej. 04:17.370 --> 04:19.290 Inną luką, która może zostać wykorzystana 04:19.290 --> 04:21.330 przez atakującego, jest użycie tego samego typu 04:21.330 --> 04:24.420 hypervisora na wszystkich naszych maszynach wirtualnych. 04:24.420 --> 04:27.180 Na przykład, jeśli nasza organizacja polega wyłącznie 04:27.180 --> 04:29.700 na hiperwizorze ESXi firmy VMware i zostanie stworzony 04:29.700 --> 04:32.280 nowy exploit dla tego hiperwizora, atakujący może 04:32.280 --> 04:35.790 użyć go przeciwko wszystkim naszym systemom. 04:35.790 --> 04:38.400 Tak więc, jeśli odniesie sukces na jednym z naszych serwerów, prawdopodobnie 04:38.400 --> 04:40.830 wypróbują go na pozostałych naszych serwerach. 04:40.830 --> 04:43.260 A jeśli wszystkie nasze serwery używają tej samej 04:43.260 --> 04:46.410 platformy, w tym przypadku ESXi firmy VMware, ta luka może zostać 04:46.410 --> 04:49.350 wykorzystana w całej naszej organizacji. 04:49.350 --> 04:51.420 Wyzwanie z tym związane polega jednak na tym, 04:51.420 --> 04:53.700 że ponownie, jeśli korzystamy z wielu platform hypervisor, 04:53.700 --> 04:55.620 nasze koszty wsparcia i wymagania szkoleniowe 04:55.620 --> 04:57.360 również wzrosną. 04:57.360 --> 05:00.090 Z tego powodu większość organizacji decyduje się na korzystanie 05:00.090 --> 05:02.610 z jednej platformy, ale przynajmniej podejmują 05:02.610 --> 05:04.800 decyzję o wyważonym ryzyku. 05:04.800 --> 05:07.290 Aby ograniczyć to ryzyko, organizacja powinna stosować 05:07.290 --> 05:09.690 odpowiednie konfiguracje, upewnić się, że hypervisor 05:09.690 --> 05:11.520 jest zawsze załatany i aktualny oraz dostępny 05:11.520 --> 05:14.280 tylko za pośrednictwem bezpiecznego interfejsu zarządzania, 05:14.280 --> 05:16.830 a także ściśle kontrolować dostęp. 05:16.830 --> 05:19.230 Są to niektóre z rzeczy, które należy wziąć pod uwagę, gdy 05:19.230 --> 05:21.570 zaczynasz zastanawiać się, czy zamierzasz zwirtualizować 05:21.570 --> 05:23.880 swoje systemy i przenieść je do rozwiązania lokalnego 05:23.880 --> 05:25.410 lub opartego na chmurze. 05:25.410 --> 05:27.540 Po pierwsze, czy zamierzasz wirtualizować? 05:27.540 --> 05:30.360 Jeśli tak, to czy zamierzasz korzystać z tradycyjnych maszyn 05:30.360 --> 05:32.430 wirtualnych, czy też z konteneryzacji? 05:32.430 --> 05:34.410 Jaki jest stosunek ryzyka do zysku? 05:34.410 --> 05:35.970 Trzeba zachować równowagę. 05:35.970 --> 05:37.230 Jest to decyzja biznesowa, 05:37.230 --> 05:39.780 a także decyzja dotycząca cyberbezpieczeństwa. 05:39.780 --> 05:41.460 Będziesz więc musiał zmierzyć te rzeczy 05:41.460 --> 05:44.100 i zdecydować, co najlepiej wybrać dla swojej organizacji i jej 05:44.100 --> 05:45.723 konkretnych przypadków użycia.