WEBVTT

00:00.150 --> 00:01.770
... 네트워크에서 인기

00:01.770 --> 00:03.540
있는 새로운 유형의 가상화는

00:03.540 --> 00:05.790
컨테이너 기반 가상화라고 합니다

00:05.790 --> 00:07.980
컨테이너화라고도 하죠

00:07.980 --> 00:10.290
그러나 이러한 유형의 가상화는 최종 사용자보다는

00:10.290 --> 00:12.780
서버에 훨씬 더 중점을 둡니다.

00:12.780 --> 00:14.460
이러한 유형의 가상화를 사용하면

00:14.460 --> 00:16.440
운영 체제 커널이 여러 가상 머신에서

00:16.440 --> 00:19.440
공유되지만 각 가상 머신의 사용자 공간은 고유하게

00:19.440 --> 00:22.740
생성되고 관리됩니다.

00:22.740 --> 00:25.020
컨테이너화는 호스트 운영 체제에

00:25.020 --> 00:27.900
의해 적용되는 가상화의 유형으로 응용 프로그램을

00:27.900 --> 00:31.230
위해 격리 실행 환경을 프로비전합니다

00:31.230 --> 00:33.390
컨테이너화는

00:33.390 --> 00:38.280
네 안 그러면

00:38.280 --> 00:40.290
네 이제 컨테이너화는 일반적으로

00:40.290 --> 00:42.210
Linux 서버와 함께 사용됩니다

00:42.210 --> 00:43.950
이 컨테이너 기반 가상화의

00:43.950 --> 00:46.980
몇 가지 예로는 Docker나 평행 , 평행 오픈VZ

00:46.980 --> 00:48.960
프로젝트

00:48.960 --> 00:51.870
이제 컨테이너화는 실제로 어떤 모습일까요?

00:51.870 --> 00:53.610
글쎄요, 하드웨어가 있고 그

00:53.610 --> 00:56.460
하드웨어 위에 호스트 OS(일반적으로 Linux)가

00:56.460 --> 00:59.430
있고 컨테이너 관리자가 있습니다.

00:59.430 --> 01:02.820
쿠베르네티스나 도커 같은 이름이었어요

01:02.820 --> 01:05.100
이제 이 컨테이너 관리자를 사용하여 다양한 애플리케이션을

01:05.100 --> 01:08.070
포함하는 다양한 컨테이너를 만들겠습니다.

01:08.070 --> 01:10.290
이 경우에는 세 개의 컨테이너가 있습니다.

01:10.290 --> 01:12.000
첫 번째 환경이 있습니다 호스트 os의

01:12.000 --> 01:14.340
커널에 기반하고 있는 것입니다 이 예제에서는 사용되고

01:14.340 --> 01:16.170
있는 Linux 시스템입니다

01:16.170 --> 01:18.720
컨테이너 1이 Linnux를 실행하고 있고 몇

01:18.720 --> 01:20.700
가지 응용 프로그램을 갖고 있어요

01:20.700 --> 01:23.130
2번 컨테이너도 똑같이 할 수 있고 3번

01:23.130 --> 01:25.290
컨테이너도 똑같이 할 수 있어요

01:25.290 --> 01:27.210
세 개의 컨테이너 모두 동일한 호스트 운영 체제

01:27.210 --> 01:28.980
파일을 공유하고 있기 때문입니다.

01:28.980 --> 01:30.750
가상 컴퓨터를 이용한 퓨어

01:30.750 --> 01:33.690
가상화보다 리소스가 훨씬 적게 들죠

01:33.690 --> 01:35.730
가상화에 대해 이야기한 것처럼 말이죠.

01:35.730 --> 01:38.340
대신 개별 가상 컴퓨터를 사용한다면 각각은

01:38.340 --> 01:40.860
각각의 운영 체제 복사본이 필요합니다

01:40.860 --> 01:43.740
그리고 이는 각각 8~10gb가 될 수 있습니다.

01:43.740 --> 01:45.000
하지만 컨테이너는

01:45.000 --> 01:47.280
같은 운영 체제를 공유할 수 있어요

01:47.280 --> 01:50.250
컨테이너화는 저장소 베이스를 훨씬 덜 사용하고 프로세싱

01:50.250 --> 01:52.260
파워도 훨씬 덜 차지합니다

01:52.260 --> 01:55.050
이게 바로 컨테이너를 사용하는

01:55.050 --> 01:56.970
진짜 장점입니다

01:56.970 --> 01:59.970
이제 이러한 컨테이너는 논리적으로 격리되어 있기 때문입니다.

01:59.970 --> 02:02.100
서로 호환이 안 돼요

02:02.100 --> 02:04.080
네 컨테이너 두 개를 이야기 하고 싶다면 가상 네트워크를

02:04.080 --> 02:06.480
통해 연결해야 합니다. 그리고 라우팅과 스위칭을 제대로

02:06.480 --> 02:07.890
해야 합니다. 이 두 개가 이야기 할

02:07.890 --> 02:09.330
수 있습니다.

02:09.330 --> 02:11.970
네 기본적으로 서로 대화할 방법이 없습니다

02:11.970 --> 02:14.310
보안 관점에서 이건 훌륭한 점입니다

02:14.310 --> 02:16.410
세분화가 가능하니까요 ?

02:16.410 --> 02:18.810
컨테이너를 다룰 때 주의할

02:18.810 --> 02:20.010
점이 있어요

02:20.010 --> 02:22.890
네 만약 공격자가 호스트 OS를 타협한다면,

02:22.890 --> 02:24.990
예를 들어 제가 방금 얘기하던 Linux

02:24.990 --> 02:27.960
운영 체제요 무슨 일이 일어날까요?

02:27.960 --> 02:30.810
이제 이 공격은 호스팅되는 모든 컨테이너에서 하나의

02:30.810 --> 02:33.270
운영 체제를 사용하기 때문에 데이터의 모든

02:33.270 --> 02:35.790
컨테이너에 액세스할 수 있습니다.

02:35.790 --> 02:37.440
컨테이너를 사용할 때 가장

02:37.440 --> 02:38.820
취약한 것 중 하나예요

02:38.820 --> 02:40.470
50개의 서버가 동작하는 컨테이너

02:40.470 --> 02:42.240
시스템을 가질 수도 있어요

02:42.240 --> 02:43.980
그리고 이들 각각은 컨테이너화를 사용하여

02:43.980 --> 02:46.230
서로 다른 서버와 서비스를 실행하고 있습니다.

02:46.230 --> 02:49.050
하지만 Linux 운영 체제 하의 한 서버에

02:49.050 --> 02:52.020
접근할 수 있다면 호스트 서버 50개 모두와

02:52.020 --> 02:55.290
그 모든 데이터에 엑세스 권한을 갖게 됩니다

02:55.290 --> 02:57.480
고려할 또 다른 위험은 컨테이너와 다른

02:57.480 --> 03:00.390
가상 컴퓨터가 어떻게 호스트될 것인가 하는 겁니다

03:00.390 --> 03:03.210
우리가 가상화와 클라우드 컴퓨팅에 의존하기 시작하면

03:03.210 --> 03:05.040
데이터가 다른 조직의 데이터와 같은

03:05.040 --> 03:07.680
물리적 서버에 호스팅되어 있다는 것을 인식하는

03:07.680 --> 03:09.660
것이 매우 중요해집니다

03:09.660 --> 03:12.120
그렇게 하면 시스템 보안에 몇 가지 취약점이

03:12.120 --> 03:13.920
발생하게 됩니다.

03:13.920 --> 03:16.950
첫 번째 다른 조직이 하던 작업 때문에 물리적

03:16.950 --> 03:18.960
서버가 중단되면 같은 서버에

03:18.960 --> 03:19.880
있는 모든 조직에

03:19.880 --> 03:22.500
영향을 미칠 수 있습니다

03:22.500 --> 03:24.960
마찬가지로, 한 조직이 가상 환경의 보안을

03:24.960 --> 03:26.760
유지하지 않고 해당 물리적 ​​서버에서

03:26.760 --> 03:28.740
호스팅되는 경우 공격자가 이를

03:28.740 --> 03:31.470
활용하여 동일한 서버에서 호스팅되는 다른

03:31.470 --> 03:35.880
모든 조직에 해를 끼칠 가능성이 있습니다.

03:35.880 --> 03:38.220
네트워크를 다른 네트워크와 연결할 때

03:38.220 --> 03:40.170
우려되는 게 있는 것처럼요 같은 물리적

03:40.170 --> 03:42.210
서버에서 여러 조직의 데이터를 호스팅할

03:42.210 --> 03:44.010
때도 우려되죠

03:44.010 --> 03:46.530
네 서버에 호스트되고 있는 가상 머신에 대한

03:46.530 --> 03:48.780
사용자 엑세스를 적절히 구성, 관리,

03:48.780 --> 03:50.820
감사하는 것은 중요합니다

03:50.820 --> 03:53.850
네 또한 가상 컴퓨터에 최신 패치, 바이러스

03:53.850 --> 03:56.580
백신 인미와이어, 액세스 제어가 제대로인지

03:56.580 --> 03:58.410
확인해야 합니다

03:58.410 --> 03:59.760
물리적 서버 리소스가

03:59.760 --> 04:02.490
과부하되는 위험을 최소화하려면 적절한

04:02.490 --> 04:04.920
장애 조치, 중복성 및 탄력성을 갖춘

04:04.920 --> 04:08.280
가상 머신을 설정하는 것이 항상 좋습니다.

04:08.280 --> 04:09.810
네트워크 성능과 물리적 서버

04:09.810 --> 04:11.610
리소스를 모니터링함으로써 여러

04:11.610 --> 04:13.500
물리적 컴퓨터에 걸쳐 부하 분산을

04:13.500 --> 04:15.570
할 수 있게 됩니다 하나의 물리적 컴퓨터에

04:15.570 --> 04:17.370
의존하는 대신에요 ?

04:17.370 --> 04:19.290
공격자가 이용할 수 있는 또 다른

04:19.290 --> 04:21.330
취약점은 모든 가상 컴퓨터에 걸쳐

04:21.330 --> 04:24.420
같은 유형의 하이퍼바이저를 사용할 때입니다

04:24.420 --> 04:27.180
예를 들어, 우리 조직이 VMware의 ESXi

04:27.180 --> 04:29.700
하이퍼바이저에만 의존하고 해당 하이퍼바이저에

04:29.700 --> 04:32.280
대한 새로운 공격이 생성된다면 공격자는 이를

04:32.280 --> 04:35.790
우리 시스템 전체에 사용할 수 있습니다.

04:35.790 --> 04:38.400
따라서 우리 서버 중 하나에서 성공하면 나머지

04:38.400 --> 04:40.830
서버에서도 시도할 가능성이 높습니다.

04:40.830 --> 04:43.260
모든 서버가 같은 플랫폼을 사용한다면,

04:43.260 --> 04:46.410
이 경우엔 VMware ESXi죠 이 취약점은

04:46.410 --> 04:49.350
조직 전체에 걸쳐 활용될 수 있습니다

04:49.350 --> 04:51.420
네 여기서 문제는 다시 말씀드리지만

04:51.420 --> 04:53.700
다중 하이퍼바이저 플랫폼을 사용할

04:53.700 --> 04:55.620
경우 지원 비용과 훈련 요구 사항도

04:55.620 --> 04:57.360
증가합니다 ???

04:57.360 --> 05:00.090
이런 이유로 대부분의 기업이 단일 플랫폼을

05:00.090 --> 05:02.610
사용하기로 선택합니다 하지만 적어도 그렇게

05:02.610 --> 05:04.800
할 때 측정된 위험 결정을 하죠

05:04.800 --> 05:07.290
위험 요소를 줄이기 위해 조직은 적절한 환경

05:07.290 --> 05:09.690
설정을 활용해야 합니다 하이퍼바이저가

05:09.690 --> 05:11.520
항상 최신 패치 상태로 보안 관리

05:11.520 --> 05:14.280
인터페이스를 통해 접근 가능하고 밀접한 액세스

05:14.280 --> 05:16.830
제어를 통해야만 합니다

05:16.830 --> 05:19.230
자 이것들은 여러분의 시스템을 가상화하고

05:19.230 --> 05:21.570
온-프레미스나 클라우드 기반 솔루션으로

05:21.570 --> 05:25.410
옮길 때 고려해야 할 것들입니다.

05:25.410 --> 05:27.540
먼저 가상화하실 건가요?

05:27.540 --> 05:30.360
그렇다면 기존 가상 머신을 사용할 예정입니까, 아니면

05:30.360 --> 05:32.430
컨테이너화를 사용할 예정입니까?

05:32.430 --> 05:34.410
위험과 보상이 뭐가 다르죠?

05:34.410 --> 05:35.970
당신이해야 할 균형 잡힌 행동이 있습니다.

05:35.970 --> 05:37.230
이는 비즈니스 결정이자

05:37.230 --> 05:39.780
사이버 보안 결정이기도 합니다.

05:39.780 --> 05:41.460
그래서 여러분은 이런 것들을 측정하고

05:41.460 --> 05:44.100
여러분의 조직과 특정 유스 케이스에 어떤 것을 선택하는

05:44.100 --> 05:45.723
게 최선인지 결정해야 합니다