WEBVTT

00:00:00.000 --> 00:00:07.880
마이크로소프트 365, 코파일럿, AI, 에이저, 그리고 일의 미래를 만들어가는 사람들과 함께하는 10일간의 여정을 준비되셨나요?

00:00:08.300 --> 00:00:11.920
이번 1월, M365 컨이더 커진 규모로 돌아옵니다.

00:00:12.300 --> 00:00:18.680
전세계 MVP와 업계 전문가들이 선보이는 라이브 세션, 실무 데모, 실용적인 지식을 함께 확인하세요.

00:00:18.880 --> 00:00:21.340
뻔한 슬라이드나 끝없는 유행원은 없습니다.

00:00:21.720 --> 00:00:29.260
코파일럿 스튜디오, AI 에이전트, 패브릭, 보안, 거버넌스, 자동화 등 실질적인 과제들을 다룹니다.

00:00:29.260 --> 00:00:35.180
IT 전문가든, 개발자든, 비즈니스 리더든 여러분을 위한 맞춤형 세션이 준비되어 있습니다.

00:00:35.640 --> 00:00:40.140
10일 동안 다양한 기술을 탐구하고 글로벌 커뮤니티와 연결될 수 있습니다.

00:00:40.460 --> 00:00:44.600
라이브를 시청하고 실질적인 인사이트를 여러분의 조직에 적용해보세요.

00:00:44.880 --> 00:00:51.120
2027년 1월, 10일간의 여정, 하나의 마이크로소프트 커뮤니티, 지금 등록이 시작되었습니다.

00:00:51.860 --> 00:00:55.800
M365 CON.NET에 접속하여 오늘 바로 자리를 확보하세요.

00:00:55.800 --> 00:00:59.080
다시 한번 M365 CON.NET입니다.

00:00:59.260 --> 00:01:04.380
M365 CON.NET에서 지금 참여하시고 1월 라이브에서 만나요.

00:01:04.640 --> 00:01:09.060
M365 FM에서 전해드리는 마이크로소프트 지식 보따리, 또 다른 에피소드에 오신 것을 환영합니다.

00:01:09.260 --> 00:01:10.760
진행을 맡은 미르코 피로지입니다.

00:01:11.000 --> 00:01:14.460
오늘의 주제는 거의 모든 사람이 드러낸 바지만, 명확히 설명할 수 있는 사람은 드문 주제입니다.

00:01:14.600 --> 00:01:16.100
바로 에이저 프라이빗 링크입니다.

00:01:16.340 --> 00:01:19.480
스토리지 계정이나 SQL 데이터베이스를 설정할 때의 옵션을 본 적이 있으실 텐데,

00:01:19.920 --> 00:01:21.600
정확히 무슨 기능을 하며 정말 필요한 걸까요?

00:01:21.600 --> 00:01:23.920
대부분의 사람들이 잘못 알고 있는 점이 하나 있습니다.

00:01:24.140 --> 00:01:27.060
서비스가 에이저 내부에서 실행되니 자동으로 비공개 상태일 것이고,

00:01:27.480 --> 00:01:29.660
기본적으로 인터넷과 차단되어 있을 것이라 생각합니다.

00:01:29.860 --> 00:01:32.440
하지만 전혀 사실이 아니면 사실과는 거리가 멉니다.

00:01:32.640 --> 00:01:38.580
대부분의 에이저 패스 서비스, 스토리지, SQL, 키볼트는 기본적으로 퍼블릭 엔드포인트를 제공합니다.

00:01:38.580 --> 00:01:43.260
즉, 올바른 URL과 자격 증명만 있다면 인터넷상이 누구나 접근할 수 있다는 뜻입니다.

00:01:43.420 --> 00:01:44.720
이번 에피소드가 끝날 때쯤이면,

00:01:45.060 --> 00:01:46.960
프라이빗 링크가 무엇인지, 왜 필요한지,

00:01:47.300 --> 00:01:50.300
어떻게 트래픽을 퍼블릭 인터넷으로부터 격리하는지 이해하게 될 것입니다.

00:01:50.480 --> 00:01:52.640
간단한 비유를 들어 알기 쉽게 설명해드리겠습니다.

00:01:52.960 --> 00:01:54.420
마케팅 용어 나 전문 용어는 빼고,

00:01:54.740 --> 00:01:57.980
아주 평이하게 예전 방식인 모든 곳의 퍼블릭 엔드포인트부터 짚어보죠.

00:01:58.140 --> 00:01:59.580
우선 문제부터 시작해보겠습니다.

00:02:00.000 --> 00:02:04.600
프라이빗 링크가 나오기 전에는 모든 에이저 패스 서비스가 기본적으로 퍼블릭 엔드포인트를 가졌습니다.

00:02:04.600 --> 00:02:10.360
스토리지 계정을 만들면 에이저는 미스토리지크카운트.blob.coari.windows.net과 같은 주소를 제공합니다.

00:02:10.520 --> 00:02:12.620
이 URL은 퍼블릭 IP 주소로 연결됩니다.

00:02:12.800 --> 00:02:15.380
인터넷 연결이 가능한 사람이라면 누구나 접속을 시도할 수 있죠.

00:02:15.540 --> 00:02:19.120
자, 이제 여러분의 에이저 가상 네트워크 내부에서 가상 머신이 실행 중이라고 가정해봅시다.

00:02:19.280 --> 00:02:21.720
그 VM e-block 스토리지에서 파일을 읽어야 하는 상황입니다.

00:02:21.920 --> 00:02:24.140
트래픽이 에이저 내부에서만 머물 것이라고 생각하시겠죠?

00:02:24.300 --> 00:02:26.260
두 리소스 모두 같은 클라우드 안에 있으니까요.

00:02:26.380 --> 00:02:28.160
하지만 실제로는 그렇게 작동하지 않습니다.

00:02:28.160 --> 00:02:34.140
VM은 가상 네트워크를 벗어나 공용 인터넷을 거친 다음 다시 에이저로 돌아와야 해당 스토리지 계정에 도달할 수 있습니다.

00:02:34.380 --> 00:02:39.200
마치 사무실 건물의 한 방에 있는데 같은 건물 내 비품실에서 물건을 가져와야 하는 상황과 같습니다.

00:02:39.540 --> 00:02:43.840
그런데 복도를 따라 걷는 대신 밖으로 나가서 블록을 한 바퀴 돌아 다른 문으로 다시 들어와야 하는 셈이죠.

00:02:44.040 --> 00:02:46.520
말이 안 되는 상황이지만 실제로 그렇게 작동하고 있었습니다.

00:02:46.680 --> 00:02:47.880
이는 심각한 문제입니다.

00:02:48.080 --> 00:02:52.940
두 리소스 모두 마이크로소프트 위 데이터 센터 안에 있는데도 데이터는 공용 인터넷을 통해 이동합니다.

00:02:53.160 --> 00:02:56.620
트래픽이 암호화되어 있기는 하지만 여전히 개방된 인터넷에 노출되어 있습니다.

00:02:56.620 --> 00:03:00.060
사용자가 제어할 수 없는 라우터와 스위치를 거쳐 이동하게 됩니다.

00:03:00.260 --> 00:03:03.680
만약 누군가의 트래픽을 가로챈다면 전송하는 내용을 볼 수도 있습니다.

00:03:03.900 --> 00:03:05.340
여기에는 흔한 오해가 하나 있습니다.

00:03:05.660 --> 00:03:08.500
많은 사람이 내 구독에 있으니까 비공개겠지 라고 생각합니다.

00:03:08.720 --> 00:03:10.140
하지만 실제로는 그렇지 않습니다.

00:03:10.400 --> 00:03:13.340
구독은 청구 및 관리 경계일 뿐 네트워크 경계가 아니기 때문입니다.

00:03:13.520 --> 00:03:16.420
기본적으로 에이저 서비스는 인터넷에서 액세스할 수 있습니다.

00:03:16.660 --> 00:03:21.540
보안을 담당하는 것은 인증 및 권한 부여 계층, 기, 암호, 방화벽 규칙 뿐입니다.

00:03:21.760 --> 00:03:23.500
하지만 네트워크 경로 자체는 공용입니다.

00:03:23.500 --> 00:03:26.640
그래서 마이크로소프트는 이 문제를 보고 더 나은 방법이 있어야 한다 고 판단했습니다.

00:03:26.840 --> 00:03:28.140
그리고 그 방법을 만들어냈습니다.

00:03:28.280 --> 00:03:29.440
바로 프라이빗 링크입니다.

00:03:29.660 --> 00:03:32.860
해결책은 네트워크 인터페이스 카드로 작동하는 프라이빗 엔드포인트입니다.

00:03:33.060 --> 00:03:37.800
프라이빗 링크는 전체 서비스이지만 이해해야 할 핵심 요소는 프라이빗 엔드포인트입니다.

00:03:38.020 --> 00:03:43.900
이는 가상 네트워크 내에 위치하여 패스 서비스에 연결되는 가상 네트워크 인터페이스 카드, NIC입니다.

00:03:44.140 --> 00:03:45.540
작동 방식은 다음과 같습니다.

00:03:45.540 --> 00:03:53.500
스토리지 계정에 대한 프라이빗 엔드포인트를 만들면 에이저가 서브넷의 프라이빗 IP를 사용하여 가상 네트워크 내에 가상 NIC를 생성합니다.

00:03:53.700 --> 00:03:57.940
이 NIC는 백엔드에서 프라이빗 링크를 통해 스토리지 계정에 연결됩니다.

00:03:58.140 --> 00:04:05.440
따라서 VM위 관점에서는 스토리지 계정이 다른 리소스와 마찬가지로 프라이빗 IP를 가진 내 네트워크 안에 있는 것처럼 보입니다.

00:04:05.680 --> 00:04:13.820
VM위 스토리지 계정으로 트래픽을 보내면 NIC위 프라이빗 IP로 전달되어 공용이터넷이 아닌 마이크로소프트 백본 네트워크를 통해 이동합니다.

00:04:13.820 --> 00:04:16.660
에이저의 내부 인프라를 절대 벗어나지 않는 것이죠.

00:04:16.840 --> 00:04:19.080
사무실 건물의 안전한 복도를 떠올려 보세요.

00:04:19.360 --> 00:04:23.600
밖으로 나가서 건물을 돌아갈 필요 없이 복도를 따라 곧장 비품실로 들어가는 것입니다.

00:04:23.800 --> 00:04:25.540
우회할 필요 없는 직접 연결입니다.

00:04:25.760 --> 00:04:28.220
자, 이제 많은 사람이 놓치는 미묘한 차이점을 살펴보겠습니다.

00:04:28.560 --> 00:04:32.340
프라이빗 엔드포인트를 활성화한다고 해서 퍼블릭 엔드포인트가 자동으로 꺼지지는 않습니다.

00:04:32.540 --> 00:04:34.020
둘은 동시에 존재할 수 있습니다.

00:04:34.300 --> 00:04:39.740
프라이빗 엔드포인트를 만들어 더라도 퍼블릭 엔드포인트 설정을 그대로 두면 스토리지 계정은 여전히 인터넷에서 접근 가능합니다.

00:04:39.740 --> 00:04:43.240
완전히 차단하려면 퍼블릭 네트워크 액세스를 명시적으로 비활성화해야 합니다.

00:04:43.400 --> 00:04:45.940
많은 분들이 프라이빗 엔드포인트 생성만으로 충분하다고 생각합니다.

00:04:46.100 --> 00:04:46.840
그렇지 않습니다.

00:04:47.100 --> 00:04:49.500
에이저의 프라이빗 액세스만 허용하겠다고 직접 설정해야 합니다.

00:04:49.660 --> 00:04:51.400
이 기회에 다른 오해도 하나 풀어보죠.

00:04:51.560 --> 00:04:54.420
프라이빗 링크는 vpn이나 익스프레스 루트와는 다릅니다.

00:04:54.660 --> 00:04:57.560
이들은 서로 다른 문제를 해결하며 비교는 나중에 다루겠습니다.

00:04:57.940 --> 00:05:02.980
우선 프라이빗 링크는 전체 네트워크를 에이저에 연결하는 게 아니라 특정 서비스에 접근하는 것임을 알아두세요.

00:05:02.980 --> 00:05:07.740
이제 프라이빗 엔드포인트가 있고 vm 이 프라이빗 ip를 통해 스토리지 계정에 접근할 수 있게 되었습니다.

00:05:07.960 --> 00:05:10.540
하지만 vm은 어떻게 스토리지 계정을 실제로 찾을까요?

00:05:10.740 --> 00:05:13.200
예전에는 퍼블릭 url을 퍼블릭 ip로 확인했죠.

00:05:13.360 --> 00:05:14.940
이제는 프라이빗 ip가 필요합니다.

00:05:15.140 --> 00:05:16.140
어떻게 작동할까요?

00:05:16.320 --> 00:05:19.060
여기서 dns가 등장하며 다음에 살펴볼 내용입니다.

00:05:19.240 --> 00:05:21.940
dns는 이 모든 과정을 가능하게 하는 핵심 요소입니다.

00:05:22.160 --> 00:05:26.560
이제 프라이빗 엔드포인트가 있고 vm은 프라이빗 ip를 통해 스토리지 계정에 접근할 수 있습니다.

00:05:26.800 --> 00:05:29.660
그런데 vm은 해당 ip를 알지 못한다는 점이 중요합니다.

00:05:29.660 --> 00:05:31.800
vm은 스토리지 계정에 url만 알고 있습니다.

00:05:32.040 --> 00:05:33.660
예를 들면 마이 스토리지 어카운트 같은 거죠.

00:05:33.820 --> 00:05:35.520
블랍 바시오아리.windows.net입니다.

00:05:35.680 --> 00:05:37.140
이것이 연결할 때 사용하는 이름입니다.

00:05:37.320 --> 00:05:39.760
그렇다면 어떻게 퍼블릭 ip 대신 프라이빗 ip를 찾을까요?

00:05:39.960 --> 00:05:41.840
여기서 dns가 중요한 역할을 합니다.

00:05:42.060 --> 00:05:46.560
프라이빗 엔드포인트를 만들 때 프라이빗 dns 영역과 통합하도록 선택하면 권장하는 방법입니다.

00:05:46.960 --> 00:05:48.460
에이저가 자동으로 영역을 생성합니다.

00:05:48.640 --> 00:05:51.680
블랍 스토리지 계정의 경우 해당 영역 이름은 프라이빗 링크입니다.

00:05:51.880 --> 00:05:54.120
블랍 바시오아리.windows.net

00:05:54.120 --> 00:05:58.740
그 영역 내에 에이저는 스토리지 계정 이름을 엔드포인트의 프라이빗 ip로 맵핑하는 a 레코드를 추가합니다.

00:05:58.900 --> 00:06:00.280
이제 영리한 부분이 나옵니다.

00:06:00.480 --> 00:06:02.280
원래의 퍼블릭 url은 여전히 해석되지만

00:06:02.280 --> 00:06:07.260
직접 퍼블릭 ip를 반환하는 대신 프라이빗 영역을 가리키는 cnam이 레코드를 반환합니다.

00:06:07.440 --> 00:06:08.740
해석 과정은 다음과 같습니다.

00:06:09.080 --> 00:06:10.880
vm 이 스토리지 계정 url을 요청하면

00:06:10.880 --> 00:06:14.600
dns는 마이 스토리지 어카운트를 가리키는 cnam을 반환합니다.

00:06:14.600 --> 00:06:21.000
이것은 가상 네트워크에 연결된 프라이빗 dns 영역에 존재하는 프라이빗 링크 닷비에로 비점 cwari.windows.net입니다.

00:06:21.160 --> 00:06:23.140
dns가 이를 프라이빗 ip로 해석하고

00:06:23.140 --> 00:06:25.460
vm은 해당 프라이빗 ip에 연결하며

00:06:25.460 --> 00:06:27.500
트래픽은 공용 인터넷을 거치지 않습니다.

00:06:27.700 --> 00:06:29.840
사무실 건물의 안내데스크를 생각해보세요.

00:06:30.140 --> 00:06:33.840
누군가 들어와서 비품실을 물어봐도 안내원은 밖으로 내보내지 않습니다.

00:06:34.060 --> 00:06:36.320
건물 내부의 올바른 복도를 안내해줄 뿐이죠.

00:06:36.500 --> 00:06:38.740
프라이빗 dns 영역은 건물을 나가지 않고도

00:06:38.740 --> 00:06:40.900
트래픽을 올바른 위치로 안내하는 안내원과 같습니다.

00:06:41.220 --> 00:06:44.140
작동 방식은 가상 머신 vm 이 어디에 있는지에 따라 다릅니다.

00:06:44.340 --> 00:06:46.620
프라이빗 엔드포인트와 같은 가상 네트워크에 있다면

00:06:46.620 --> 00:06:49.500
프라이빗 dns 영역이 연결되어 자동으로 해결됩니다.

00:06:49.680 --> 00:06:51.000
피어링된 네트워크에 있는 경우

00:06:51.000 --> 00:06:53.100
해당 네트워크에도 영역을 연결해야 합니다.

00:06:53.300 --> 00:06:55.940
vpn이나 익스프레스 루트를 통한 온 프레미스 장비의 경우

00:06:55.940 --> 00:06:57.100
과정이 더 복잡해집니다.

00:06:57.260 --> 00:06:58.960
일반적으로 dns 전달자를 설정하거나

00:06:58.960 --> 00:07:00.880
에이저 dns 프라이빗 리졸버를 사용하여

00:07:00.880 --> 00:07:02.500
커리가 프라이빗 영역에 도달하도록 합니다.

00:07:02.500 --> 00:07:04.560
하지만 에이저 내부의 대부분 시나리오에서는

00:07:04.560 --> 00:07:06.540
기본적인 처리가 자동으로 이루어집니다.

00:07:06.680 --> 00:07:09.120
규모가 큰 환경에서는 dns가 복잡해질 수 있지만

00:07:09.120 --> 00:07:11.060
표준 사례인 프라이빗 엔드포인트와

00:07:11.060 --> 00:07:12.640
동일 가상 네트워크 내 vm의 경우

00:07:12.640 --> 00:07:13.980
에이저가 자동으로 처리합니다.

00:07:14.180 --> 00:07:16.040
사용자가 직접 건드릴 것은 아무것도 없습니다.

00:07:16.320 --> 00:07:18.280
실제 예시를 통해 어떻게 작동하는지 살펴보겠습니다.

00:07:18.620 --> 00:07:19.620
실제 환경 시연입니다.

00:07:19.840 --> 00:07:21.620
에이저 스토리지를 사용한 프라이빗 링크입니다.

00:07:21.780 --> 00:07:23.240
현실적인 상황으로 만들어 보겠습니다.

00:07:23.540 --> 00:07:24.660
에이저 가상 네트워크 내에서

00:07:24.660 --> 00:07:26.660
실행 중인 가상 머신이 있다고 가정해봅시다.

00:07:26.660 --> 00:07:28.940
이 vm은 에이저 블랍 스토리지 계정에서

00:07:28.940 --> 00:07:30.080
파일을 가져와야 합니다.

00:07:30.260 --> 00:07:31.140
흔한 설정이죠.

00:07:31.380 --> 00:07:33.640
사용자 업로드를 저장하는 앱이나 컨테이너에서

00:07:33.640 --> 00:07:35.500
데이터를 읽는 처리 작업이 그 예입니다.

00:07:35.700 --> 00:07:37.880
프라이빗 링크가 없으면 이런 일이 발생합니다.

00:07:38.080 --> 00:07:40.460
vm 이 스토리지 계정에 공용 URL을 조회하여

00:07:40.460 --> 00:07:41.940
공용 IP 주소를 가져옵니다.

00:07:42.140 --> 00:07:43.640
트래픽이 가상 네트워크를 떠나

00:07:43.640 --> 00:07:44.920
공용 인터넷을 거친 뒤

00:07:44.920 --> 00:07:47.400
다시 에이저로 들어와 스토리지 계정에 도달합니다.

00:07:47.660 --> 00:07:49.160
이 왕복 과정은 불필요합니다.

00:07:49.420 --> 00:07:51.060
두 리소스 모두 이미 에이저 내에 있지만

00:07:51.060 --> 00:07:53.700
데이터는 어쨌든 공용 인터넷을 경유하게 됩니다.

00:07:53.920 --> 00:07:54.960
프라이빗 링크를 사용하면

00:07:54.960 --> 00:07:56.820
스토리지 계정에 블랍 하위 리소스에 대한

00:07:56.820 --> 00:07:58.260
프라이빗 엔드포인트를 배포합니다.

00:07:58.500 --> 00:08:00.840
이것이 블랍 데이터를 처리하는 특정 부분입니다.

00:08:01.060 --> 00:08:03.260
에이저는 가상 네트워크 내에 프라이빗 IP를 가진

00:08:03.260 --> 00:08:04.500
가상 NIC를 생성하고

00:08:04.500 --> 00:08:06.200
프라이빗 DNS 영역을 설정하며

00:08:06.200 --> 00:08:08.960
앞서 설명한 DNS 해결 체인이 작동하기 시작합니다.

00:08:09.160 --> 00:08:10.320
이제 vm 이 동일한 URL인

00:08:10.320 --> 00:08:13.760
미스토리지크카운트.blog.cori.windows.net을 해결할 때

00:08:13.760 --> 00:08:15.800
공용 IP 대신 프라이빗 IP를 가져옵니다.

00:08:15.800 --> 00:08:18.640
트래픽은 vm에서 프라이빗 엔드포인트로 흐른 다음

00:08:18.640 --> 00:08:20.700
마이크로소프트 백본망을 통해

00:08:20.700 --> 00:08:22.300
스토리지 계정으로 전달됩니다.

00:08:22.500 --> 00:08:24.660
에이저 내부 네트워크를 절대 벗어나지 않습니다.

00:08:24.840 --> 00:08:25.960
핵심은 바로 이건입니다.

00:08:26.180 --> 00:08:27.700
애플리케이션은 변경되지 않습니다.

00:08:27.900 --> 00:08:28.880
연결 문자열을 수정하거나

00:08:28.880 --> 00:08:30.400
구성 파일을 업데이트할 필요가 없습니다.

00:08:30.680 --> 00:08:31.920
URL은 그대로 유지됩니다.

00:08:32.140 --> 00:08:34.720
달라지는 것은 오직 해당 URL이 해결되는 방식뿐입니다.

00:08:34.920 --> 00:08:36.340
앱의 관점에서는 여전히 동일한

00:08:36.340 --> 00:08:37.900
스토리지 계정에 연결되는 것이지만

00:08:37.900 --> 00:08:40.420
이면에서는 트래픽 경로가 완전히 달라집니다.

00:08:40.420 --> 00:08:41.900
완벽하게 보안을 강화하려면

00:08:41.900 --> 00:08:44.140
공용 엔드포인트를 완전히 비활성화 할 수도 있습니다.

00:08:44.320 --> 00:08:46.500
즉 스토리지 계정은 프라이빗 엔드포인트를 통해서만

00:08:46.500 --> 00:08:47.380
접근할 수 있게 됩니다.

00:08:47.580 --> 00:08:49.380
인터넷 노출이 전혀 없는 상태가 되는 것입니다.

00:08:49.580 --> 00:08:51.540
외부에서는 아무도 연결을 시도조차 할 수 없습니다.

00:08:51.780 --> 00:08:53.240
한 가지 더 알아두어야 할 점이 있습니다.

00:08:53.520 --> 00:08:55.420
스토리지 계정에는 여러 하위 리소스가 있습니다.

00:08:55.660 --> 00:08:57.860
블락뿐만 아니라 파일, 테이블, 큐도 있죠.

00:08:58.060 --> 00:09:00.280
각 리소스마다 고유한 프라이빗 엔드포인트를 가질 수 있습니다.

00:09:00.480 --> 00:09:03.140
블락 트래픽용 하나와 파일 트래픽용 하나를 따로 둘 수도 있습니다.

00:09:03.140 --> 00:09:06.320
또는 필요에 따라 이 모두를 포괄하는 단일 엔드포인트를 사용할 수도 있죠.

00:09:06.480 --> 00:09:09.420
이제 이것이 다른 에이저 연결 옵션과는 어떻게 다른지 궁금하실 겁니다.

00:09:09.620 --> 00:09:12.000
vpn, 익스프레스 루트, 서비스 엔드포인트 말이죠.

00:09:12.160 --> 00:09:13.180
모두 비슷하게 들립니다.

00:09:13.400 --> 00:09:14.580
깔끔하게 정리해보죠.

00:09:14.760 --> 00:09:18.020
프라이빗 링크 대 vpn, 대 익스프레스 루트, 대 서비스 엔드포인트.

00:09:18.200 --> 00:09:21.980
그렇다면 프라이빗 링크는 vpn, 익스프레스 루트, 서비스 엔드포인트와 비교해 어떤가요?

00:09:22.160 --> 00:09:23.480
모두 같은 일을 하는 것처럼 들리지만

00:09:23.480 --> 00:09:25.260
사실은 서로 다른 문제를 해결합니다.

00:09:25.460 --> 00:09:27.380
많은 경우 이들을 함께 사용하게 될 것입니다.

00:09:27.380 --> 00:09:31.460
vpn부터 시작해 보조, 가상사설망, vpn, 은온 프레미스 네트워크를

00:09:31.460 --> 00:09:33.160
퍼블릭 인터넷을 통해 에이저에 연결합니다.

00:09:33.320 --> 00:09:36.180
vr 사이트와 에이저 사이에 암호화된 터널을 생성합니다.

00:09:36.380 --> 00:09:39.580
트래픽은 암호화되지만 여전히 퍼블릭 인터넷을 통해 이동합니다.

00:09:39.800 --> 00:09:42.680
터널은 안전하지만 그 터널이 지나는 도로는 퍼블릭 상태입니다.

00:09:42.880 --> 00:09:45.740
프라이빗 링크는 vpn을 대체하는 것이 아니라 함께 작동합니다.

00:09:45.940 --> 00:09:48.160
vpn을 사용하여 사무실을 에이저에 연결한 다음

00:09:48.160 --> 00:09:51.660
해당 연결해서 프라이빗 링크로 스토리지 계정에 비공개로 액세스할 수 있습니다.

00:09:51.860 --> 00:09:53.300
익스프레스 루트는 다릅니다.

00:09:53.560 --> 00:09:56.540
데이터 센터에서 에이저까지 전용 사설 회선을 제공합니다.

00:09:56.760 --> 00:09:58.860
트래픽이 퍼블릭 인터넷을 전혀 거치지 않습니다.

00:09:59.100 --> 00:10:01.820
마치 마이크로소프트 네트워크로 바로 연결되는 전용 사설 도로를 가진 것과 같습니다.

00:10:02.100 --> 00:10:03.500
하지만 한 가지 주의할 점이 있습니다.

00:10:03.760 --> 00:10:06.820
익스프레스 루트만으로는 패스 서비스에 대한 비공개 액세스를 제공하지 않습니다.

00:10:07.040 --> 00:10:10.700
네트워크를 에이저에 연결해주지만 스토리지 계정은 여전히 퍼블릭 엔드포인트를 가집니다.

00:10:10.700 --> 00:10:15.000
해당 서비스에 진정한 비공개 액세스를 하려면 익스프레스 루트와 프라이빗 링크를 결합해야 합니다.

00:10:15.160 --> 00:10:17.080
서비스 엔드포인트는 이전 기술입니다.

00:10:17.300 --> 00:10:21.500
가상 네트워크의 트래픽만 에이저 서비스에 도달할 수 있도록 액세스를 제한할 수 있습니다.

00:10:21.740 --> 00:10:24.840
하지만 문제는 서비스가 여전히 퍼블릭 엔드포인트를 가진다는 점입니다.

00:10:25.020 --> 00:10:28.600
단지 이 vn의 뒤 트래픽만 허용하라는 방화벽 규칙을 추가하는 것뿐입니다.

00:10:28.820 --> 00:10:31.100
엔드포인트 자체는 여전히 인터넷에 노출되어 있습니다.

00:10:31.400 --> 00:10:35.340
프라이빗 링크가 더 안전한 이유는 엔드포인트가 실제 vn의 내부에 있고 프라이빗 IP를 가지기 때문입니다.

00:10:35.340 --> 00:10:37.500
공격할 대상인 퍼블릭 엔드포인트가 아예 존재하지 않습니다.

00:10:37.660 --> 00:10:39.000
이해하기 쉽게 비유를 들어보겠습니다.

00:10:39.320 --> 00:10:41.380
vpn은 공용도로 위에 만든 안전한 터널입니다.

00:10:41.600 --> 00:10:43.920
익스프레스 루트는 에이저로 바로 연결되는 사설도로입니다.

00:10:44.120 --> 00:10:46.800
서비스 엔드포인트는 공용 게이트에서 신분증을 확인하는 경비원입니다.

00:10:46.980 --> 00:10:49.060
프라이빗 링크는 건물 내부로 바로 통하는 복도와 같습니다.

00:10:49.380 --> 00:10:50.880
밖으로 나갈 필요가 전혀 없는 것이죠.

00:10:51.060 --> 00:10:52.700
자 그렇다면 무엇을 사용해야 할까요?

00:10:52.900 --> 00:10:53.840
상황에 따라 다릅니다.

00:10:54.100 --> 00:10:57.540
사무실을 에이저에 연결하려면 vpn이나 익스프레스 루트를 선택할 수 있습니다.

00:10:57.540 --> 00:11:01.200
패스 서비스에 비공개로 액세스하는 데는 프라이빗 링크가 가장 좋은 표준입니다.

00:11:01.320 --> 00:11:03.660
가장 강력한 보안을 원한다면 두 가지를 조합하세요.

00:11:03.880 --> 00:11:06.140
익스프레스 루트 로 트래픽을 에이저로 안전하게 가져온 다음

00:11:06.140 --> 00:11:08.700
프라이빗 링크로 서비스에 비공개로 액세스하는 방식입니다.

00:11:08.860 --> 00:11:11.680
하지만 프라이빗 링크는 마이크로소프트 서비스만을 위한 것이 아닙니다.

00:11:11.840 --> 00:11:13.420
자체 애플리케이션에도 사용할 수 있으며

00:11:13.420 --> 00:11:16.240
프라이빗 링크 서비스가 직접 비공개 엔드포인트를 호스팅합니다.

00:11:16.460 --> 00:11:18.000
많은 사람이 놓치는 점이 하나 있습니다.

00:11:18.300 --> 00:11:21.200
프라이빗 링크는 에이저 서비스를 이용하기 위해서만 존재하는 것이 아닙니다.

00:11:21.200 --> 00:11:24.020
자신의 애플리케이션을 외부로 공개하는 데에도 사용할 수 있습니다.

00:11:24.200 --> 00:11:26.540
그것이 바로 프라이빗 링크 서비스가 만들어진 이유입니다.

00:11:26.720 --> 00:11:28.220
세스 공급자라고 가정해보겠습니다.

00:11:28.600 --> 00:11:31.600
표준 로드 밸런서 뒤에 가상 머신에서 애플리케이션을 실행하고

00:11:31.600 --> 00:11:32.840
고객이 이에 액세스합니다.

00:11:33.080 --> 00:11:34.580
기존에는 인터넷에 모두 공개하거나

00:11:34.580 --> 00:11:36.520
고객 네트워크와 내 네트워크 사이에

00:11:36.520 --> 00:11:38.760
VPN을 설정하는 두 가지 옵션만 있었습니다.

00:11:38.920 --> 00:11:40.220
둘 다 큰 단점이 있습니다.

00:11:40.560 --> 00:11:42.440
인터넷 공개는 보안 위험을 초래하고

00:11:42.440 --> 00:11:44.900
VPN은 관리와 유지가 복잡합니다.

00:11:44.900 --> 00:11:47.380
프라이빗 링크 서비스는 이 문제를 해결합니다.

00:11:47.580 --> 00:11:49.840
서비스를 생성하고 표준 로드 밸런서에 연결하면

00:11:49.840 --> 00:11:53.180
고객은 자신의 가상 네트워크에 비공개 엔드포인트를 생성할 수 있습니다.

00:11:53.380 --> 00:11:55.760
그 엔드포인트는 귀하의 서비스에 직접 연결됩니다.

00:11:55.960 --> 00:11:58.900
피어링도 VPN도 필요 없으며 인터넷 노출은 전혀 없습니다.

00:11:59.200 --> 00:12:00.900
트래픽은 고객의 비공개 엔드포인트에서

00:12:00.900 --> 00:12:03.640
마이크로소프트 백본을 통해 귀하의 서비스로 바로 이동합니다.

00:12:03.840 --> 00:12:05.180
인터넷을 거치지 않습니다.

00:12:05.400 --> 00:12:09.340
귀하의 서비스는 마이 앱, 기드, 리잔, 에이저, 프라이빗 링크 서비스와 같은

00:12:09.340 --> 00:12:11.180
전세계에서 고유한 별칭을 갖게 됩니다.

00:12:11.180 --> 00:12:13.220
고객은 이 별칭을 사용하여 연결하며

00:12:13.220 --> 00:12:15.820
누가 이를 볼 수 있는지 완전히 제어할 수 있습니다.

00:12:16.040 --> 00:12:17.920
RBAC 역할을 통해 가시성을 제안하거나

00:12:17.920 --> 00:12:19.320
특정 구독으로 제안하거나

00:12:19.320 --> 00:12:22.000
별칭을 가진 누구나 연결을 요청하도록 허용할 수 있습니다.

00:12:22.200 --> 00:12:24.120
모든 연결 요청은 수동 쓰인을 거쳐야 함으로

00:12:24.120 --> 00:12:26.600
누가 연결하는지 항상 정확히 파악할 수 있습니다.

00:12:26.820 --> 00:12:28.860
세스 공급자에게는 엄청난 변화입니다.

00:12:29.080 --> 00:12:32.100
방화벽 규칙을 열거나 복잡한 VPN 설정을 관리하는 대신

00:12:32.100 --> 00:12:34.000
고객에게 별칭만 전달하면 됩니다.

00:12:34.280 --> 00:12:36.080
고객이 비공개 엔드포인트를 생성하고

00:12:36.080 --> 00:12:37.440
귀하가 승인하면 끝납니다.

00:12:37.660 --> 00:12:38.320
완료되었습니다.

00:12:38.320 --> 00:12:39.760
다만 한 가지 제안 사항으로

00:12:39.760 --> 00:12:41.520
프라이빗 링크 서비스는 베이직이 아닌

00:12:41.520 --> 00:12:43.100
표준 로드밸런서에서만 작동합니다.

00:12:43.220 --> 00:12:46.320
아직 베이직 로드밸런서를 사용 중이라면 먼저 업그레이드 해야 합니다.

00:12:46.480 --> 00:12:48.340
얻게 되는 보안과 간편함을 생각하면

00:12:48.340 --> 00:12:49.620
작은 대가일 뿐입니다.

00:12:49.800 --> 00:12:51.480
자, 모든 보안 기능은 훌륭해 보이지만

00:12:51.480 --> 00:12:54.260
실제 규정 준수 요건과 예산에는 어떤 의미가 있을까요?

00:12:54.440 --> 00:12:56.680
보안, 규정 준수 및 비용 고려 사항입니다.

00:12:56.900 --> 00:12:59.240
프라이빗 링크가 귀하의 규정 준수 요건과 비용 측면에서

00:12:59.240 --> 00:13:00.760
진정으로 의미하는 바를 살펴보겠습니다.

00:13:01.120 --> 00:13:02.320
먼저 보안 측면입니다.

00:13:02.540 --> 00:13:04.940
프라이빗 링크는 공용 엔드포인트를 완전히 제거하여

00:13:04.940 --> 00:13:06.040
공격 표면을 줄여줍니다.

00:13:06.260 --> 00:13:07.860
그것이 가장 핵심적인 이점입니다.

00:13:08.080 --> 00:13:10.080
인터넷 어디서든 접근 가능한 스토리지 계정이나

00:13:10.080 --> 00:13:11.260
SQL 데이터베이스 대신

00:13:11.260 --> 00:13:14.240
가상 네트워크 내부의 트래픽에만 응답하는 리소스를 갖게 됩니다.

00:13:14.240 --> 00:13:17.080
스캔할 공용 IP도, 탐색할 열린 포트도 없습니다.

00:13:17.360 --> 00:13:19.180
공격 표면이 획기적으로 줄어듭니다.

00:13:19.380 --> 00:13:21.380
충분히 주목받지 못하는 또 다른 이점이 있는데

00:13:21.380 --> 00:13:23.000
바로 데이터 유출 방지입니다.

00:13:23.180 --> 00:13:24.320
각 프라이빗 엔드포인트는

00:13:24.320 --> 00:13:26.700
전체 서비스나 구독 내 모든 스토리지 계정이 아닌

00:13:26.700 --> 00:13:29.300
특정 리소스 인스턴스 하나에만 랩핑됩니다.

00:13:29.500 --> 00:13:31.720
따라서 가상 네트워크 내의 워크로드가 침해당하더라도

00:13:31.720 --> 00:13:33.960
공격자는 해당 프라이빗 엔드포인트를 사용해

00:13:33.960 --> 00:13:35.560
다른 스토리지 계정에 접근할 수 없습니다.

00:13:35.800 --> 00:13:38.180
승인 한 단 하나의 리소스에만 묶이게 되는 것이죠.

00:13:38.180 --> 00:13:40.700
보안팀에게 이러한 격리 기능은 매우 중요합니다.

00:13:40.860 --> 00:13:43.620
규정 준수 측면에서 프라이빗 링크는 많은 요건을 충족합니다.

00:13:43.820 --> 00:13:46.480
HIPAA, GDPR, PCI와 같은 규정은

00:13:46.480 --> 00:13:48.220
종종 민감한 데이터가 공용 네트워크를 통해

00:13:48.220 --> 00:13:49.340
전송되지 않도록 요구합니다.

00:13:49.500 --> 00:13:52.000
프라이빗 링크는 이를 입증할 명확한 방법을 제공합니다.

00:13:52.180 --> 00:13:54.100
트래픽은 마이크로소프트 백본 막내에 머무르며

00:13:54.100 --> 00:13:55.940
감사 로그를 통해 여기 증거가 있습니다.

00:13:56.140 --> 00:13:56.860
라고 말할 수 있습니다.

00:13:57.040 --> 00:13:59.760
규제 산업의 경우 이것만으로도 투자를 정당화할 수 있습니다.

00:14:00.020 --> 00:14:01.400
이제 비용에 대해 이야기해보겠습니다.

00:14:01.800 --> 00:14:03.360
사람들이 여기서 많이 놀라기 때문입니다.

00:14:03.360 --> 00:14:05.040
프라이빗 링크는 무료가 아닙니다.

00:14:05.200 --> 00:14:07.140
각 프라이빗 엔드포인트에 대한 시간땅 요금과

00:14:07.140 --> 00:14:09.980
이를 통과하는 트래픽에 대한 데이터 처리 비용을 지불해야 합니다.

00:14:10.160 --> 00:14:13.180
사용량에 따라 방화벽 규칙이 적용된 공용 엔드포인트보다

00:14:13.180 --> 00:14:14.760
2에서 3배 더 비쌀 수 있습니다.

00:14:15.020 --> 00:14:17.400
엔드포인트가 많다면 이 비용은 빠르게 불어납니다.

00:14:17.620 --> 00:14:19.520
자 솔직한 의견을 말씀드리겠습니다.

00:14:19.800 --> 00:14:21.740
프라이빗 링크가 항상 정답은 아닙니다.

00:14:21.940 --> 00:14:24.320
민감한 데이터가 없는 개발 또는 테스트 환경이라면

00:14:24.320 --> 00:14:27.760
적절한 방화벽 규칙을 적용한 공용 엔드포인트로도 충분할 수 있습니다.

00:14:27.760 --> 00:14:30.680
인터넷에서 접근해야 하는 공용 웹사이트를 호스팅하는 경우

00:14:30.680 --> 00:14:32.480
프라이빗 링크는 도움이 되지 않습니다.

00:14:32.660 --> 00:14:35.820
하지만 금융, 위료, 정부 등 규제가 엄격한 산업의 운영 워크로드에서는

00:14:35.820 --> 00:14:37.620
프라이빗 링크가 필수인 경우가 많습니다.

00:14:37.780 --> 00:14:39.980
이는 안전하게 비즈니스를 운영하기 위한 비용입니다.

00:14:40.180 --> 00:14:42.820
이제 이를 구현하기 전에 주의해야 할 몇 가지 함정이 있습니다.

00:14:43.040 --> 00:14:44.300
구현 시 주의사항입니다.

00:14:44.520 --> 00:14:45.960
초보자 들이 놓치는 부분이죠.

00:14:46.180 --> 00:14:47.520
여러분의 수고를 덜어드리겠습니다.

00:14:47.820 --> 00:14:49.040
프라이빗 링크를 처음 설정할 때

00:14:49.040 --> 00:14:50.980
사람들이 가장 흔히 저지르는 실수를 알려드리겠습니다.

00:14:51.260 --> 00:14:53.040
첫째, 프라이빗 엔드포인트를 생성한 후에는

00:14:53.040 --> 00:14:54.840
반드시 공용 엔드포인트를 비활성화해야 합니다.

00:14:55.000 --> 00:14:56.260
이것이 가장 큰 함정입니다.

00:14:56.500 --> 00:14:58.140
많은 분들이 프라이빗 엔드포인트를 만들면

00:14:58.140 --> 00:15:00.200
그것으로 충분하다고 생각하지만 그렇지 않습니다.

00:15:00.380 --> 00:15:02.440
공용 엔드포인트는 기본적으로 활성 상태로 유지되므로

00:15:02.440 --> 00:15:04.520
트래픽이 여전히 인터넷을 통해 이동할 수 있습니다.

00:15:04.760 --> 00:15:06.040
네트워킹 설정으로 이동하여

00:15:06.040 --> 00:15:08.240
공용 네트워크 액세스를 명시적으로 꺼야 합니다.

00:15:08.440 --> 00:15:11.380
이 단계를 건너뛰면 사실상 아무것도 보완 조치한 것이 아닙니다.

00:15:11.560 --> 00:15:14.120
다음으로 온프레미스 클라이언트의 DNS 확인에는

00:15:14.120 --> 00:15:15.260
추가 설정이 필요합니다.

00:15:15.460 --> 00:15:18.760
VPN이나 익스프레스 루트를 통해 연결된 사무실 내 장비들은

00:15:18.760 --> 00:15:21.520
프라이빗 엔드포인트 IP를 자동으로 확인하지 못합니다.

00:15:21.720 --> 00:15:24.440
프라이빗 DNS 영역은 온프레미스 DNS 서버가 아닌

00:15:24.440 --> 00:15:26.760
에이저 가상 네트워크에 연결되어 있기 때문입니다.

00:15:26.960 --> 00:15:30.180
DNS 전달자를 설정하거나 에이저 DNS 프라이빗 리졸버를 사용하여

00:15:30.180 --> 00:15:32.240
해당 커리가 프라이빗 영역에 도달하도록 해야 합니다.

00:15:32.440 --> 00:15:34.520
많은 사용자가 이를 간과하여 온 프레미스 앱이

00:15:34.520 --> 00:15:36.040
연결되지 않는 이유를 궁금해합니다.

00:15:36.240 --> 00:15:37.740
또한 프라이빗 엔드포인트는

00:15:37.740 --> 00:15:39.520
리전 간에 자동으로 작동하지 않습니다.

00:15:39.740 --> 00:15:41.220
가상 네트워크가 서유럽에 있는데

00:15:41.220 --> 00:15:42.820
미국 동부의 스토리지 계정에 대한

00:15:42.820 --> 00:15:45.240
프라이빗 엔드포인트를 만들면 작동하지 않습니다.

00:15:45.400 --> 00:15:46.460
프라이빗 엔드포인트는

00:15:46.460 --> 00:15:48.520
가상 네트워크와 동일한 리전에 있어야 합니다.

00:15:48.720 --> 00:15:50.280
패스 서비스는 다른 리전에 있을 수 있지만

00:15:50.280 --> 00:15:52.780
엔드포인트 자체는 VNET의 리전과 일치해야 합니다.

00:15:52.940 --> 00:15:54.300
이에 맞춰 계획을 세우세요.

00:15:54.500 --> 00:15:55.400
한 가지 더 있습니다.

00:15:55.740 --> 00:15:56.740
네트워크 보안 그룹은

00:15:56.740 --> 00:15:58.860
프라이빗 엔드포인트 NIC에 영향을 줍니다.

00:15:59.080 --> 00:16:00.080
프라이빗 엔드포인트는

00:16:00.080 --> 00:16:01.780
서브넷의 가상 NIC를 생성합니다.

00:16:02.000 --> 00:16:03.920
해당 NIC는 서브넷의 다른 리소스와

00:16:03.920 --> 00:16:05.660
동일한 NSG 규칙에 적용을 받습니다.

00:16:05.660 --> 00:16:07.620
NIC 서브넷으로의 트래픽을 차단하면

00:16:07.620 --> 00:16:09.060
엔드포인트가 작동하지 않습니다.

00:16:09.240 --> 00:16:10.960
NSG 규칙이 허용하는지 확인하세요.