WEBVTT

00:00:00.000 --> 00:00:11.610
[음악].

00:00:11.610 --> 00:00:13.680
안녕, 모두, 내 이름
콜린 머피입니다.

00:00:13.680 --> 00:00:16.065
저는 제품 마케팅 담당자입니다.
마이크로소프트의 매니저,

00:00:16.065 --> 00:00:17.865
그리고 저는 로히트와 함께 이곳에 있습니다.

00:00:17.865 --> 00:00:20.730
연결에 대해 논의
Azure SQL 데이터베이스에 대한 정보입니다.

00:00:20.730 --> 00:00:24.200
그래서 오신 것을 환영합니다, 로히트. 그래서
당신은 단지 우리에게 말하는 마음

00:00:24.200 --> 00:00:28.700
단지 방법의 기본 개념
Azure SQL 데이터베이스에 연결?

00:00:28.700 --> 00:00:31.250
>> 물론입니다. 안녕하세요
모두 들, 내 이름은 로히트입니다.

00:00:31.250 --> 00:00:34.300
프로그램 관리자입니다.
SQL 데이터베이스 팀을 구성할 수 있습니다.

00:00:34.300 --> 00:00:37.790
오늘, 우리는 콜린과 함께
시작하고 당신을 데려 갈 거야

00:00:37.790 --> 00:00:41.120
연결 방법을 통해
Azure SQL 데이터베이스에

00:00:41.120 --> 00:00:43.375
그래서, 시작하자.

00:00:43.375 --> 00:00:45.525
그래서 첫 번째 질문.

00:00:45.525 --> 00:00:48.905
조금 이해합시다
우리의 건축에 대해 우리 보다 전에

00:00:48.905 --> 00:00:52.370
어떻게 의 핵심에 가서
연결을 설정합니다.

00:00:52.370 --> 00:00:55.265
고객으로서,
당신은 알아야 할 필요가 있다

00:00:55.265 --> 00:00:58.080
우리는 의 무리를 가지고
SQL 게이트웨이는

00:00:58.080 --> 00:00:59.895
우리의 프론트 엔드 기계를 촬영

00:00:59.895 --> 00:01:02.060
연결 을 통해 들어오는
인터넷

00:01:02.060 --> 00:01:06.825
온-프레미스에서 연결
또는 Azure 외부에서

00:01:06.825 --> 00:01:08.710
>> 이것들은 단지 일부일 뿐입니다.
과거의 봉사에 대한

00:01:08.710 --> 00:01:10.470
당신은 무모한 경우 그냥 볼 수 있습니다.

00:01:10.470 --> 00:01:13.510
>> 예. 그럼 우리는 무리가
백 엔드 머신의

00:01:13.510 --> 00:01:20.195
실제 SQL 데이터베이스는
호스팅되고 데이터가 그곳에 있습니다.

00:01:20.195 --> 00:01:21.610
>> 좋아.

00:01:21.710 --> 00:01:27.450
>> 연결하려고 합니다.
myserver.database.windows.net,

00:01:27.450 --> 00:01:31.435
즉, 일반적인 형식입니다
모든 데이터베이스 서버에 대해

00:01:31.435 --> 00:01:34.045
일반적으로
이에 대한 NsLookup,

00:01:34.045 --> 00:01:36.370
로 인해 해결됩니다.
이 공용 IP 주소입니다.

00:01:36.370 --> 00:01:38.680
104.42 IP는

00:01:38.680 --> 00:01:40.870
공용 IP 주소가

00:01:40.870 --> 00:01:43.615
연결 될 것 이다
포트 1433에,

00:01:43.615 --> 00:01:46.055
우리가 있는 곳입니다.
연결에 대한 청취.

00:01:46.055 --> 00:01:48.885
연결할 때

00:01:48.885 --> 00:01:52.380
공통된 것들은
일어나는, 우리는 기본적으로,

00:01:52.380 --> 00:01:55.395
SQL 게이트웨이전달
연결,

00:01:55.395 --> 00:01:57.770
그래서 당신은 끈적 끈적한
연결

00:01:57.770 --> 00:02:00.545
게이트웨이 및 연결
백 엔드 노드에 있습니다.

00:02:00.545 --> 00:02:03.425
이를 프록시라고 합니다.
연결 정책입니다.

00:02:03.425 --> 00:02:05.570
그래서 모든 게이트웨이가 하고 있는 일은

00:02:05.570 --> 00:02:09.110
중간에 있는 매뉴얼
백 엔드에 연결합니다.

00:02:09.110 --> 00:02:10.670
>> 그건 좋은 데요
우리는 결코 노출되지 않습니다.

00:02:10.670 --> 00:02:13.130
SQL 노드의 실제 IP입니다.

00:02:13.130 --> 00:02:15.140
>> 나는 그것을 얻었다. 그래서 당신은 방법

00:02:15.140 --> 00:02:17.330
연결 시 연결
Azure 외부에서 볼 수 있습니다.

00:02:17.330 --> 00:02:20.090
지금, 당신은 연결 할 때
Azure 내부에서,

00:02:20.090 --> 00:02:23.915
VM에서 말, 우리는 약간 할
연결하는 다른 방법.

00:02:23.915 --> 00:02:27.170
그래서 우리는
SQL 게이트웨이를 통해

00:02:27.170 --> 00:02:32.540
실제 위치
백 엔드의 SQL 데이터베이스입니다.

00:02:32.540 --> 00:02:35.810
이 13.93 주소를 볼 수 있습니다.

00:02:35.810 --> 00:02:37.535
개인 IP 주소입니다.

00:02:37.535 --> 00:02:40.930
그것은 사용자가 뭔가 아니다
직접 연결할 수 있습니다.

00:02:40.930 --> 00:02:42.815
같은, 그들은 모른다
이 IP 주소에 대해

00:02:42.815 --> 00:02:43.325
>> 좋아.

00:02:43.325 --> 00:02:46.385
그런 다음 더 무작위로 지정하려면

00:02:46.385 --> 00:02:52.250
11,000-11,999 포트 범위가 있습니다.

00:02:52.250 --> 00:02:53.575
>> 좋아.

00:02:53.575 --> 00:02:58.885
>> 그래서 SQL이
해당 범위 내에 있는 모든 범위내에 있습니다.

00:02:58.885 --> 00:03:02.010
즉,
이 호출됩니다 발생

00:03:02.010 --> 00:03:06.560
리디렉션 방법 또는 리디렉션
는 연결 정책입니다.

00:03:06.560 --> 00:03:08.615
그러나 해당 노드로 리디렉션됩니다.

00:03:08.615 --> 00:03:11.345
그래서 당신은 직접 연결
SQL 데이터베이스에,

00:03:11.345 --> 00:03:13.400
게이트웨이가 들어오지 않습니다.

00:03:13.400 --> 00:03:17.040
다시 한 번 그림
해당 연결의.

00:03:17.090 --> 00:03:18.525
>> 좋아.

00:03:18.525 --> 00:03:20.900
>> 이것이 기본 아키텍처입니다.

00:03:20.900 --> 00:03:23.210
연결하는 방법을 이해합니다.

00:03:23.210 --> 00:03:24.920
자, 내가 당신을 데려 갈 수 있습니다
무슨 일이 일어나는지 통해

00:03:24.920 --> 00:03:27.410
연결이 실제로
게이트웨이로 이동합니다.

00:03:27.410 --> 00:03:28.345
>> 좋아.

00:03:28.345 --> 00:03:32.235
이것은 매우, 아주 기본적인
높은 수준의 물건, 특별한 아무것도,

00:03:32.235 --> 00:03:36.520
그리고 이것은 오랜 세월 동안 주변에 있었습니다.

00:03:36.520 --> 00:03:40.375
그래서 당신은 클라이언트를 가지고 있고 당신은
게이트웨이 머신이 있고,

00:03:40.375 --> 00:03:43.350
제일 먼저
3방향 악수,

00:03:43.350 --> 00:03:47.835
표준 PCP 물건, [들리지]
서버에 통신할 수 있습니다.

00:03:47.835 --> 00:03:50.720
흥미로운 것, 무엇
다음에 일어나는 것은 당신이

00:03:50.720 --> 00:03:53.090
프리로그인 패키지
클라이언트가 보내는

00:03:53.090 --> 00:03:55.840
여기에 흥미로운 기능은,

00:03:55.840 --> 00:03:57.900
우리는 당신이 원하는,

00:03:57.900 --> 00:04:00.820
모범 사례로 암호화를 사용하여

00:04:00.820 --> 00:04:03.425
퍼팅에 의해 설정되는

00:04:03.425 --> 00:04:07.490
암호화는 연결에서 true와 같습니다.
응용 프로그램의 문자열.

00:04:07.490 --> 00:04:10.640
다른 부분은 우리가 당신을 원하는
모범 사례로 할 수 있습니다.

00:04:10.640 --> 00:04:13.415
는 트러스트 서버 인증서입니다.
false와 같습니다.

00:04:13.415 --> 00:04:16.940
따라서 클라이언트가

00:04:16.940 --> 00:04:21.890
인증서를
게이트웨이 노드에서 가져옵니다.

00:04:21.890 --> 00:04:23.580
그래서, 당신은 하지 않습니다.

00:04:23.580 --> 00:04:28.215
스푸핑 또는 스푸핑의 경우
중간에 있는 인간 공격.

00:04:28.215 --> 00:04:30.105
>> 좋아, 그건 완벽한 의미가 있습니다.

00:04:30.105 --> 00:04:32.670
따라서 이러한 모범 사례와

00:04:32.670 --> 00:04:34.860
모든 개발자 연결
SQL을 찾을 수 있습니다.

00:04:34.860 --> 00:04:37.285
이 우리의 문서 페이지에
또는 장소 어디?

00:04:37.285 --> 00:04:40.080
>> 그렇습니다. 사실, 우리는
한 걸음 더 나아가보세요.

00:04:40.080 --> 00:04:42.300
포털에 가서

00:04:42.300 --> 00:04:44.960
SQL 데이터베이스를 보고
연결 문자열에서

00:04:44.960 --> 00:04:46.550
이 것들은 거기에 넣어.

00:04:46.550 --> 00:04:47.735
>> 이 모든 것이 기본값인가요?

00:04:47.735 --> 00:04:49.340
>> 예. 그래서 당신은 그들을 넣어

00:04:49.340 --> 00:04:51.320
이 있는지 확인하기 위해
보호됩니다.

00:04:51.320 --> 00:04:52.075
>> 좋아.

00:04:52.075 --> 00:04:53.940
>> 그리고 나서,

00:04:53.940 --> 00:04:55.110
사전 기록과 응답,

00:04:55.110 --> 00:04:57.600
즉, 다시 부분입니다
TDS 프로토콜의

00:04:57.600 --> 00:05:00.410
그리고 당신은
이 TLS 핸드셰이크는

00:05:00.410 --> 00:05:02.690
점점 의 긴 바람 길

00:05:02.690 --> 00:05:04.820
사이의 보안 채널
클라이언트와 서버를

00:05:04.820 --> 00:05:05.320
>> 좋아.

00:05:05.320 --> 00:05:07.220
그래서 본질적으로,
이 프로세스의 끝,

00:05:07.220 --> 00:05:09.680
당신은 에서 안전
프로토콜 관점,

00:05:09.680 --> 00:05:14.500
그런 다음 시작됩니다.
실제 로그인 패킷은

00:05:14.500 --> 00:05:16.020
당신은 그것을 볼 수 있습니다

00:05:16.020 --> 00:05:18.200
로그인 판매 패킷 경우

00:05:18.200 --> 00:05:20.270
당신은 충격을 통해 할 것
또는 그런 식으로 뭔가.

00:05:20.270 --> 00:05:23.330
그런 다음 사용 중인 내용에 따라

00:05:23.330 --> 00:05:26.720
연결하는 경우
근시에서 우리를,

00:05:26.720 --> 00:05:29.215
당신은 단지 얻을 것이다
다시 승인을 합니다.

00:05:29.215 --> 00:05:31.985
그렇지 않으면, 당신은 무엇을 얻을 수 있습니다
리디렉션 토큰으로 호출,

00:05:31.985 --> 00:05:33.485
말하는 멋진 방법입니다,

00:05:33.485 --> 00:05:35.000
우리는 당신에게 개인 IP를 말할 것이다

00:05:35.000 --> 00:05:36.895
현재 주소
연결할 수 있습니다.

00:05:36.895 --> 00:05:39.290
>> 와우, 핸드셰이킹이 많다
[들리지 않음]으로 거꾸로 가고 있습니다.

00:05:39.290 --> 00:05:39.980
>> 예.

00:05:39.980 --> 00:05:41.690
>> 긴 과정인가요?

00:05:41.690 --> 00:05:44.075
>> 아니요, 밀리초의 문제입니다.

00:05:44.075 --> 00:05:45.170
>> 오 괜찮아.

00:05:45.170 --> 00:05:48.530
>> 그래, 우리는 그것을 빨리 유지
심지어 우리는 그것을 안전하게 유지합니다.

00:05:48.530 --> 00:05:50.870
>> 좋아, 괜찮아.
빠르고 안전합니다.

00:05:50.870 --> 00:05:52.720
>> 그렇습니다. 그래서 다음,

00:05:52.720 --> 00:05:55.100
이제 우리는 에 대해 알고
아키텍처와 우리는 알고

00:05:55.100 --> 00:05:58.460
연결의 기본 사항에 대해,

00:05:58.460 --> 00:06:00.395
연결할 수 있는 사람에 대해 이야기해 봅시다.

00:06:00.395 --> 00:06:03.055
그래서 당신은 넣어
에 대한 몇 가지 컨트롤,

00:06:03.055 --> 00:06:05.570
실제로 누가 걸러브를 합니까?

00:06:05.570 --> 00:06:08.345
연결할 수 있습니다.
Azure SQL 데이터베이스.

00:06:08.345 --> 00:06:11.075
그래서 이것은, 그리고 나는
데모에서 이를 보여 줄 수 있습니다.

00:06:11.075 --> 00:06:16.055
이것은 기본적으로 방화벽입니다.
Azure 포털의 블레이드 폴더입니다.

00:06:16.055 --> 00:06:17.900
그래서 가장 먼저 눈에 띄는 것은 여기에서 확인할 수 있습니다.

00:06:17.900 --> 00:06:19.430
이 섹션은 맨 위로 말합니다.

00:06:19.430 --> 00:06:22.550
액세스 허용
Azure 서비스(켜기 또는 끄기)입니다.

00:06:22.550 --> 00:06:25.340
그래서 이것은 매우 광범위한 범주입니다.

00:06:25.340 --> 00:06:26.855
권한의
당신은 여기에주고있다.

00:06:26.855 --> 00:06:28.420
그것은 기본적으로 말하고있다,

00:06:28.420 --> 00:06:32.065
다른 서버는
Azure 내에서 실행,

00:06:32.065 --> 00:06:35.915
웹 앱처럼 말하기
또는 다른 Azure VM,

00:06:35.915 --> 00:06:40.815
그것은 에 연결할 수 있습니다
SQL 데이터베이스 서버 여부?

00:06:40.815 --> 00:06:42.420
>> Azure의 어느 곳에서나?

00:06:42.420 --> 00:06:42.545
>> 예.

00:06:42.545 --> 00:06:46.245
>> 지역에 의해 설정되었습니까?
또는 영역 또는 데이터 센터?

00:06:46.245 --> 00:06:47.205
>> 그것은 중요하지 않습니다.

00:06:47.205 --> 00:06:47.940
>> 그것은 중요하지 않습니다.

00:06:47.940 --> 00:06:49.910
>> 기본적으로 이것이 하는 일은

00:06:49.910 --> 00:06:52.060
실행 중일 때
Azure의 서비스,

00:06:52.060 --> 00:06:57.605
각 지역 또는 데이터 센터는
고정 IP 주소 집합입니다.

00:06:57.605 --> 00:07:00.710
그래서 우리는 기본적으로, 이것은 규칙입니다

00:07:00.710 --> 00:07:03.560
뭐든 말하는 거야
아이디어에서 나에게 오는.

00:07:03.560 --> 00:07:03.935
>> Azure 내부에서.

00:07:03.935 --> 00:07:04.205
>> 그렇습니다.

00:07:04.205 --> 00:07:05.165
신뢰할 수 있는 데이터 센터입니다.

00:07:05.165 --> 00:07:05.675
>> 예.

00:07:05.675 --> 00:07:07.460
>> 그래서 내가 받아들일거야? 잡았어.

00:07:07.460 --> 00:07:10.100
이제 사람들은 물론
에 대한 예약이

00:07:10.100 --> 00:07:12.875
이 때문에
좀 더 넓은 범위,

00:07:12.875 --> 00:07:15.215
그러나 일부 시나리오에서는

00:07:15.215 --> 00:07:16.280
당신은이 작업을 수행해야합니다.

00:07:16.280 --> 00:07:18.785
예를 들어 웹 앱이 한 가지 예입니다.

00:07:18.785 --> 00:07:21.620
그러나 점차적으로, 우리는
오퍼링을 내놓는다.

00:07:21.620 --> 00:07:25.295
어디에 넣을 수 있는지
이 오프에 와서.

00:07:25.295 --> 00:07:27.650
내가 보여줄게
다른 방법으로

00:07:27.650 --> 00:07:29.285
>> 나는 할 거야
서비스 유형 구매

00:07:29.285 --> 00:07:30.845
또는 같은 것
웹 응용 프로그램 또는 뭔가?

00:07:30.845 --> 00:07:31.465
>> 예.

00:07:31.465 --> 00:07:32.985
>> 그런 다음 명확히 하기 위해,

00:07:32.985 --> 00:07:36.120
Azure에서 서비스를 말하면

00:07:36.120 --> 00:07:38.160
그것은 당신의 자신의 안에
물론 설명.

00:07:38.160 --> 00:07:38.925
>> 예.

00:07:38.925 --> 00:07:41.115
>> 사람들을 위해 그것을 명확히 하기 위해서입니다.

00:07:41.115 --> 00:07:44.420
>> 그렇습니다. 그래서 제어의 다음 단계

00:07:44.420 --> 00:07:47.525
우리가 제공하는 것은 무엇입니까?
IP 기반 방화벽.

00:07:47.525 --> 00:07:55.080
따라서 일반적으로
프로비전 Azure SQL Database 서버,

00:07:55.080 --> 00:07:58.080
기본 목록은 다음과 같습니다.

00:07:58.080 --> 00:08:01.430
그래서 아무도에 의해 그것에 연결할 수 없습니다.

00:08:01.430 --> 00:08:04.820
IP 주소를 사용하는 경우가 아니라면
이 목록에 있습니다.

00:08:04.820 --> 00:08:05.580
>> 당신을 얻었다.

00:08:05.580 --> 00:08:07.305
>> 그래서 첫 번째 일
해야 할 일은,

00:08:07.305 --> 00:08:09.195
포털로 이동하면

00:08:09.195 --> 00:08:12.125
그것은 당신에게 IP 주소를 표시합니다
당신이 오고 있어.

00:08:12.125 --> 00:08:14.690
그래서 만약 내가 내 집 IP에서 오고 있어,

00:08:14.690 --> 00:08:17.945
그것이 표시 될 곳이다.
이 클라이언트 IP 주소 섹션,

00:08:17.945 --> 00:08:20.810
그리고 나는 그것을 화이트리스트해야
내가 할 수 있도록하기 위해

00:08:20.810 --> 00:08:23.755
를 사용하여 연결하려면
예를 들어 관리 스튜디오.

00:08:23.755 --> 00:08:25.210
>> 좋아. 예쁜 표준 물건,

00:08:25.210 --> 00:08:26.840
우리는 기본적으로 모든 것을 했습니다.

00:08:26.840 --> 00:08:27.485
정확히 말입니다.

00:08:27.485 --> 00:08:28.450
>> 좋아.

00:08:28.450 --> 00:08:30.890
이제 우리는
세 번째 흥미로운 방법

00:08:30.890 --> 00:08:33.845
호출되는 연결
VNet 방화벽 규칙입니다.

00:08:33.845 --> 00:08:35.785
그건 꽤 많이 말하는,

00:08:35.785 --> 00:08:37.985
모든 Azure VM 허용

00:08:37.985 --> 00:08:41.390
연결하는 VNet 내부
내 SQL 데이터베이스에.

00:08:41.390 --> 00:08:44.030
지금, 상황이있을 수 있습니다
이것이 유용한 경우,

00:08:44.030 --> 00:08:46.370
레거시 앱이 있다고 가정해 보시면 됩니다.
또는 앱, 말,

00:08:46.370 --> 00:08:47.900
실행 중인 서비스 보고

00:08:47.900 --> 00:08:51.060
VM을 원할 수 있습니다.
SQL 데이터베이스에 연결,

00:08:51.060 --> 00:08:53.555
이것은 세분화된 방법입니다.
그렇게 할 수 있도록

00:08:53.555 --> 00:08:56.270
특정 VM 집합만

00:08:56.270 --> 00:08:58.970
하위 그물 내에 있습니다.
SQL 데이터베이스에 연결합니다.

00:08:58.970 --> 00:08:59.405
>> 좋아.

00:08:59.405 --> 00:09:01.565
이것들은
세 가지 방법

00:09:01.565 --> 00:09:04.095
누가 연결하는지 제어
오늘 SQL 데이터베이스에.

00:09:04.095 --> 00:09:05.570
>> 그렇습니다. 나는 볼 수 있습니다
지금까지 다양 한에서

00:09:05.570 --> 00:09:07.430
레거시 응용 프로그램을 이동하여

00:09:07.430 --> 00:09:07.940
>> 물론입니다.

00:09:07.940 --> 00:09:10.595
>> VM을 실행했습니다.
모두 하나의 VNet 내에 있습니다.

00:09:10.595 --> 00:09:12.140
>> 예. 그래서 다음,

00:09:12.140 --> 00:09:14.105
나는 당신을 통해 데려 갈 것이다
각 자의 세부 사항.

00:09:14.105 --> 00:09:18.215
그렇다면
IP 기반 방화벽이 작동합니다.

00:09:18.215 --> 00:09:23.655
그래서 우리가 서버를 가지고 있다고 가정
데이터베이스 DB1과 DB2의 몇 가지,

00:09:23.655 --> 00:09:26.220
여기에 들어오는 연결입니다.

00:09:26.220 --> 00:09:30.080
물론, 들어오는 연결
프록시 또는 리디렉션이 될 수 있습니다.

00:09:30.080 --> 00:09:31.535
이 점은 중요하지 않습니다.

00:09:31.535 --> 00:09:34.100
가정은 당신이 얻었다
게이트웨이를 지나면

00:09:34.100 --> 00:09:36.740
실제로 오고 있다
SQL 엔진 수준입니다.

00:09:36.740 --> 00:09:39.050
우리가 가장 먼저 하는 일은
우리가 할 거야

00:09:39.050 --> 00:09:41.630
를 확인하려면
데이터베이스 수준 방화벽입니다.

00:09:41.630 --> 00:09:43.010
그래서 이것은 에 저장됩니다

00:09:43.010 --> 00:09:47.215
마스터 데이터베이스와
sys.database_firewall_rules.

00:09:47.215 --> 00:09:49.590
그것은 DMV, 그리고 모든 포함

00:09:49.590 --> 00:09:52.160
는 IP 주소의 범위입니다.
허용됩니다.

00:09:52.160 --> 00:09:55.100
그래서 만약 당신이 여기,
그런 다음 기본적으로

00:09:55.100 --> 00:09:58.100
당신은 우리의 데이터베이스 범위를 얻을
에 대한 액세스

00:09:58.100 --> 00:10:01.790
어느 데이터베이스
연결하려는 경우

00:10:01.790 --> 00:10:05.390
그렇지 않은 경우
데이터베이스 수준 방화벽 규칙,

00:10:05.390 --> 00:10:08.735
다음 검사가 발생합니다.
서버 수준에 있습니다.

00:10:08.735 --> 00:10:11.180
약간
다른 DMV라는

00:10:11.180 --> 00:10:15.440
sys.firewall_rules 그리고 그것은
마스터 데이터베이스에서 다시.

00:10:15.440 --> 00:10:17.420
여기에 액세스 권한이 있는 경우

00:10:17.420 --> 00:10:19.160
다음 물론 당신은에서 액세스 할 수 있습니다

00:10:19.160 --> 00:10:21.965
서버 수준은
연결되면

00:10:21.965 --> 00:10:24.635
관리에서 할 수 있습니다.
스튜디오 드롭다운,

00:10:24.635 --> 00:10:26.725
DB1과 DB2를 모두 선택합니다.

00:10:26.725 --> 00:10:29.635
>> 좋아. 그래서 만약 내가
다음을 사용하여 구성

00:10:29.635 --> 00:10:33.395
구성할 SSMS
내 Azure SQL 데이터베이스입니다.

00:10:33.395 --> 00:10:37.680
나는 그 방화벽을 말하는 경우
서버 수준에서 규칙,

00:10:37.680 --> 00:10:39.810
그것은 단지 나에게 줄 수
모든 것에 액세스할 수 있습니다.

00:10:39.810 --> 00:10:41.130
>> 그것을 얻었다.

00:10:41.130 --> 00:10:45.165
그래서 우리는 아마 가야한다
개발 테스트는 있지만 모범 사례는 아닙니다.

00:10:45.165 --> 00:10:48.180
>> 예. 저것은
좋은 질문, 콜린,

00:10:48.180 --> 00:10:53.075
왜냐하면 그 중 하나는
왜 우리는이 두 가지 수준이 있습니까?

00:10:53.075 --> 00:10:55.560
생산에서,

00:10:55.560 --> 00:10:59.045
당신이 무엇을 사용하려는 경우
포함된 사용자로 호출됩니다.

00:10:59.045 --> 00:11:01.595
가장 좋은 방법은

00:11:01.595 --> 00:11:06.515
포함된 사용자만
포함된 사용자를 DB1에 설정합니다.

00:11:06.515 --> 00:11:11.340
포함 된 사용자의 전체 아이디어
DB2에 액세스할 수 없습니다.

00:11:11.410 --> 00:11:14.780
와 함께
데이터베이스 방화벽 규칙,

00:11:14.780 --> 00:11:20.555
IP 주소를 제한할 수도 있습니다.
사용자가 로그인할 수 있는 위치에서

00:11:20.555 --> 00:11:23.180
그래서 본질적으로,
데이터베이스 수준 방화벽

00:11:23.180 --> 00:11:25.010
는 깊이 데이터에 유용한 기능입니다.

00:11:25.010 --> 00:11:30.515
범위를 관리합니다.
나쁜 사람들이 에서 연결할 수 있습니다.

00:11:30.515 --> 00:11:31.980
>> 좋아.

00:11:32.260 --> 00:11:35.450
그래서 다시, 그냥 여기에 저를 도와주세요.

00:11:35.450 --> 00:11:37.430
당신은 꽤 몇 가지 세부 사항을 확장 할 수 있습니다.

00:11:37.430 --> 00:11:42.650
그래서 방화벽에 이러한 규칙
SQL 서버 내부에 있으며

00:11:42.650 --> 00:11:44.750
분명히 우리가 무슨 일을했는지
이전에 덮여 있었다

00:11:44.750 --> 00:11:48.215
에 대한 방화벽 규칙
네트워크 내의 네트워크입니다.

00:11:48.215 --> 00:11:50.630
>> 그렇습니다. 그래서 그들은
두 가지 개념.

00:11:50.630 --> 00:11:52.220
그래서 이전 슬라이드에서 나는 보여 주었다

00:11:52.220 --> 00:11:54.155
IP 주소가 있는 경우
기반 방화벽을 기반으로 합니다.

00:11:54.155 --> 00:11:58.820
이것이 바로 이 것입니다.
그들이 있는 곳

00:11:58.820 --> 00:12:03.995
저장되는 마스터의 내부에
SQL Server 내의 데이터베이스를 제공합니다.

00:12:03.995 --> 00:12:07.050
포털을 통해 노출됩니다.

00:12:07.870 --> 00:12:11.660
물론 만나지 못하면
다음 기준 중 어느 것이든

00:12:11.660 --> 00:12:15.870
연결이 거부됩니다.
이것은 우리가 말한 것입니다.

00:12:16.090 --> 00:12:18.350
이제 살펴 보겠습니다.

00:12:18.350 --> 00:12:21.875
여기에 새로운 흥미로운 부분
VNet 방화벽 규칙입니다.

00:12:21.875 --> 00:12:25.235
그래서 내가 설정하자
당신을위한 시나리오.

00:12:25.235 --> 00:12:27.830
그래서 당신이 가정 하자
가상 머신

00:12:27.830 --> 00:12:32.135
레거시 앱을 실행
iOS 또는 무엇이든에.

00:12:32.135 --> 00:12:37.100
가상 머신은 일반적으로
당신은 호출 된 것을 설정할 수 있습니다

00:12:37.100 --> 00:12:42.260
공용 IP 주소로
14.11을 해결하는 것입니다.

00:12:42.260 --> 00:12:45.200
또한
개인 IP 주소는

00:12:45.200 --> 00:12:48.305
특정 서브넷에서 나옵니다.

00:12:48.305 --> 00:12:51.020
따라서 모범 사례
항상

00:12:51.020 --> 00:12:53.600
개인 IP는
서브넷에서 나오는,

00:12:53.600 --> 00:12:55.490
네트워크 세분화에 도움이 됩니다.

00:12:55.490 --> 00:12:57.920
이것이 바로 네트워킹입니다.
모범 사례.

00:12:57.920 --> 00:13:00.305
그러나 나는 그것이 어떻게 도움이되는지 보여 줄 것이다.

00:13:00.305 --> 00:13:02.990
>> 당신은 일반적으로 항상
그 일을 설정하거나 얻을

00:13:02.990 --> 00:13:05.270
네트워크 IT 프로가

00:13:05.270 --> 00:13:07.865
당신이 에 가기 전에 최대
다른 생산.

00:13:07.865 --> 00:13:10.625
당신은 확인하려는
당신은 충분한 IP를 얻었다.

00:13:10.625 --> 00:13:11.930
>> 네, 절대적으로 그렇습니다.

00:13:11.930 --> 00:13:13.985
그것은 좋은 점
당신이 기지나는 것을

00:13:13.985 --> 00:13:16.985
우리는 확실히 원하는
여기서 의무의 분리,

00:13:16.985 --> 00:13:20.390
그것은 항상 계획하는 것이 좋다
네트워크를 미리 연결합니다.

00:13:20.390 --> 00:13:22.790
그래서 당신은 밖으로 실행되지 않습니다
IP 주소와

00:13:22.790 --> 00:13:26.495
그럼 당신은 확실히하지 않습니다
DBM 엉망을 원한다

00:13:26.495 --> 00:13:32.030
이러한 설정및
크기가 잘못되었거나

00:13:32.030 --> 00:13:37.850
이들 각각은 쉽게
여기에 물건을 놓칠 수 있습니다.

00:13:37.850 --> 00:13:40.280
>> 예, 그리고 일단 당신이
이러한 범위를 설정하고

00:13:40.280 --> 00:13:42.995
사물 설치 시작
뒤로 갈 수 없습니다.

00:13:42.995 --> 00:13:47.000
>> 그것을 얻었다. 그래서 있다
기본 설정.

00:13:47.000 --> 00:13:50.930
나는 VM을 가지고, 그것은 대중이
IP 주소 및 개인 IP 주소.

00:13:50.930 --> 00:13:54.020
그래서 내가 당신을 통해 데려 갈 수 있습니다
옵션 번호 하나 방법입니다

00:13:54.020 --> 00:13:57.350
SQL 데이터베이스에 연결합니까?
대중을 이용하는 경우,

00:13:57.350 --> 00:14:01.190
우리는 일반적으로 이것을 호출합니다.
SNATTED IP 주소입니다.

00:14:01.190 --> 00:14:04.130
옵션 번호 1은

00:14:04.130 --> 00:14:06.980
VM 측과 우리는 무엇을 정의 할 수 있습니다

00:14:06.980 --> 00:14:09.230
NSG 규칙으로 호출되는

00:14:09.230 --> 00:14:12.455
기본적으로 내가 갈거야 말한다
을 사용하여 아웃바운드 트래픽을 허용합니다.

00:14:12.455 --> 00:14:14.630
>> NSG, 네트워크 보안 그룹?

00:14:14.630 --> 00:14:17.170
>> 네트워크 보안 그룹
에 있는 경우

00:14:17.170 --> 00:14:21.120
가상 머신의 VM을 참조하십시오.

00:14:21.120 --> 00:14:24.305
그것은 당신이 정의 할 수 있습니다
인바운드 및 아웃바운드 규칙.

00:14:24.305 --> 00:14:28.865
그래서 여기에 아웃 바운드를 정의합니다
규칙을 사용하여 SQL 데이터베이스에 연결합니다.

00:14:28.865 --> 00:14:31.880
우리가 그렇게 할 방법
우리가 해야 할 말이 있을까요?

00:14:31.880 --> 00:14:35.225
1433에 연결하기 때문에
그건 내 이슬입니다.

00:14:35.225 --> 00:14:37.460
처음에 기억하십시오.
연결해야 합니다.

00:14:37.460 --> 00:14:40.565
게이트웨이는
포트 1433에 투자.

00:14:40.565 --> 00:14:43.700
그런 다음 11,000을 통해

00:14:43.700 --> 00:14:48.170
11,999 범위 이기 때문에 나는
리디렉션을 사용할 것입니다.

00:14:48.170 --> 00:14:50.990
그런 다음 TCP가 내 프로토콜입니다.

00:14:50.990 --> 00:14:54.425
내 IP가 40.112 주소를 해결합니다.

00:14:54.425 --> 00:14:57.815
오른쪽에 있는 길
가장 흥미로운 작품.

00:14:57.815 --> 00:15:01.355
나는이 가상 머신을 하자 말하고있어

00:15:01.355 --> 00:15:04.415
SQL의 모든 것에 연결합니다. 웨스투스.

00:15:04.415 --> 00:15:08.615
그래서 다시 다른 네트워킹입니다
개념이 서비스 태그라고 합니다.

00:15:08.615 --> 00:15:12.935
그래서 그 게 무슨 뜻인지 내가 원하는
을 클릭하고 SQL 데이터베이스에 연결합니다.

00:15:12.935 --> 00:15:15.410
내 데이터베이스가 WestUS에 있다는 것을 알고 있습니다.

00:15:15.410 --> 00:15:19.715
그냥 화이트리스트를 허용
서부 지역으로의 트래픽.

00:15:19.715 --> 00:15:21.125
>> 아주 좋은 것입니다.

00:15:21.125 --> 00:15:24.455
그래서 당신은 단지 할 수
나 또는 또는로 사용

00:15:24.455 --> 00:15:29.795
단지 도움이 되는 용도
그냥 대기 시간과 트래픽.

00:15:29.795 --> 00:15:32.390
>> 네, 내 말은
결론은 이쪽

00:15:32.390 --> 00:15:36.620
을 활성화하는 방법입니다.
네트워크 측에서 연결됩니다.

00:15:36.620 --> 00:15:38.450
그래서 일반적으로
네트워크 관리자가

00:15:38.450 --> 00:15:41.540
이것은 단지
관리가 용이합니다.

00:15:41.540 --> 00:15:42.770
당신이 말할 때 때문에 그들을 위해

00:15:42.770 --> 00:15:46.940
Sql. WestUS 당신은 할 필요가 없습니다
개별 IP 주소를 화이트리스트로 지정합니다.

00:15:46.940 --> 00:15:49.610
그래서 그것은 당신이 할 수 있습니다
에 있는 모든 것에 연결

00:15:49.610 --> 00:15:53.180
모든 SQL 데이터베이스는
서미국 지역에서.

00:15:53.180 --> 00:15:55.850
이제 이것은 또한 발생

00:15:55.850 --> 00:15:57.845
추가 오버헤드
의미에서

00:15:57.845 --> 00:15:59.990
작업이 완료되면
네트워크 설정,

00:15:59.990 --> 00:16:02.000
당신은 에 와서해야
SQL 데이터베이스 측

00:16:02.000 --> 00:16:04.655
다시 한번 우리의
IP 주소 방화벽.

00:16:04.655 --> 00:16:06.845
따라서 여기에 IP 주소를 추가해야합니다.

00:16:06.845 --> 00:16:08.975
그래서 이것은 두 단계 의 과정입니다.

00:16:08.975 --> 00:16:12.230
이 것의 단점은 하나

00:16:12.230 --> 00:16:15.440
IP 주소를 관리해야 합니다.

00:16:15.440 --> 00:16:19.520
예를 들어, 언제 든 지
공용 IP 주소를 연결합니다.

00:16:19.520 --> 00:16:22.280
VM은 즉시
이 연결은

00:16:22.280 --> 00:16:25.400
SQL이 손상되지 않기 때문에
해당 IP 주소를 인식합니다.

00:16:25.400 --> 00:16:27.200
[들리지 않는] 것은 아니기 때문입니다.

00:16:27.200 --> 00:16:30.740
>> 예. 다른 것은
이것에 대해

00:16:30.740 --> 00:16:33.140
일부 고객은 다음 좋아하지 않을 수 있습니다

00:16:33.140 --> 00:16:36.155
서비스 태그는 여전히
꽤 넓은 오픈.

00:16:36.155 --> 00:16:37.805
그것은 내가 에 연결할 수 있습니다 말한다

00:16:37.805 --> 00:16:41.840
모든 SQL 데이터베이스는
서부 지역.

00:16:41.840 --> 00:16:44.090
그러나 물론, 개선이 있다

00:16:44.090 --> 00:16:46.130
네트워크 측에 오고
이를 통해

00:16:46.130 --> 00:16:48.575
특정 리소스로 제한

00:16:48.575 --> 00:16:51.035
하지만 그
현재 진행 중입니다.

00:16:51.035 --> 00:16:52.820
그러나 이것은 우리가 가지고있는 것입니다.

00:16:52.820 --> 00:16:58.775
이제 방향을 뒤집어 봅시다.
우리가 여기에 오고있다.

00:16:58.775 --> 00:17:02.720
당신은 우리가에서 설정하는 방법을 보았다
SQL DB에 대한 VM 측입니다.

00:17:02.720 --> 00:17:05.240
Vnet 방화벽 규칙은
설정한 것

00:17:05.240 --> 00:17:07.400
무도회 는 SQL 데이터베이스 측처럼

00:17:07.400 --> 00:17:11.330
이 말은 내가에서 연결할 수 있도록

00:17:11.330 --> 00:17:17.135
내 SQL 데이터베이스는
특정 서브넷입니다.

00:17:17.135 --> 00:17:21.005
그래서 그것의 아름다움
필요하지 않습니다.

00:17:21.005 --> 00:17:25.280
모든 IP 주소를 화이트리스트로 추가
또는 그런 일을.

00:17:25.280 --> 00:17:28.460
당신이 말하는 것은
사이의 패스 열기

00:17:28.460 --> 00:17:29.960
SQL 데이터베이스와

00:17:29.960 --> 00:17:33.620
특정 서브넷을 통해
개인 IP 주소를 사용할 수 있습니다.

00:17:33.620 --> 00:17:36.485
그래서 심지어
추가 혜택은

00:17:36.485 --> 00:17:42.455
모든 것이 진행되고 있습니다.
Azure 백본 네트워크를 현명하게 합니다.

00:17:42.455 --> 00:17:43.970
>> 정말 멋지군요.

00:17:43.970 --> 00:17:50.750
이것의 다른 장점은
화이트리스팅이 필요하지 않으며 예,

00:17:50.750 --> 00:17:52.625
그건 꽤 많이.

00:17:52.625 --> 00:17:56.420
>> 멋지다. 그래서 그것을 주셔서 감사합니다.

00:17:56.420 --> 00:17:58.160
그건 정말 좋은 설명

00:17:58.160 --> 00:18:01.220
연결
Azure SQL 데이터베이스.

00:18:01.220 --> 00:18:03.780
다른 몇 가지 빠른 질문,

00:18:03.790 --> 00:18:06.680
그것은 단지 Azure용입니다.
모든 것과 같은 SQL 데이터베이스

00:18:06.680 --> 00:18:08.780
그들은 다른
배포 옵션을 제공합니다.

00:18:08.780 --> 00:18:11.855
나는 우리가 하나의 탄성을 가지고 있다고 생각
목표는 인스턴스를 관리했다.

00:18:11.855 --> 00:18:12.290
>> 물론입니다.

00:18:12.290 --> 00:18:15.360
>> 그들 모두를 위한 것이이것입니까?
당신이 설명 한 옵션에 영향을?

00:18:15.360 --> 00:18:18.530
>> 그래서 우리가 이야기 할 때
Azure SQL 데이터베이스는 현재

00:18:18.530 --> 00:18:23.180
단일
SQL 데이터베이스, 탄력적 풀,

00:18:23.180 --> 00:18:26.779
데이터 웨어하우스 및
심지어 오픈 소스 데이터베이스,

00:18:26.779 --> 00:18:30.200
우리는 공통의 제어를 공유
즉,

00:18:30.200 --> 00:18:34.640
SQL 게이트웨이를 말합니다.
해당 구성 요소가 일반적임을 보았습니다.

00:18:34.640 --> 00:18:37.820
따라서 이 연결은

00:18:37.820 --> 00:18:39.410
아래 우리의 모든 오퍼링

00:18:39.410 --> 00:18:41.525
Azure SQL 데이터베이스 우산입니다.

00:18:41.525 --> 00:18:44.690
>> 정말 환상적입니다. 고마워요

00:18:44.690 --> 00:18:47.600
대단히 모든 사람에 대 한
튜닝 과 우리에게 제공

00:18:47.600 --> 00:18:50.210
당신이 좋아하는 경우에 같은
이러한 유형의 콘텐츠

00:18:50.210 --> 00:18:53.300
그리고 저희에게 가입하고 우리는 할 게요
나중에 보자. 감사합니다.

00:18:53.300 --> 00:19:06.000
[음악]