Showing posts with label cloud. Show all posts
Showing posts with label cloud. Show all posts

Monday, June 5, 2017

AWS EC2 인스턴스에서 Host 기반 침입탐지시스템(IDS) 모니터링 하기 (원제: How to Monitor Host-Based Intrusion Detection System Alerts on Amazon EC2 Instances)

 AWS 리소스를 보호하기 위해서 저희는 예방 및 탐지 컨트롤을 포함하는 계층화 된 접근 방식을 권하고 있습니다. 예를 들어 Amazon EC2 인스턴스에 대해 호스트 기반 컨트롤을 통합하면 액세스를 제한하고 시스템 동작 및 액세스 패턴에 대한 적절한 수준의 가시성을 제공 할 수 있습니다. 이러한 컨트롤을 위해서는 호스트의 네트워크 트래픽, 로그 파일 및 파일 액세스를 모니터링하고 분석하는 호스트 기반 침입 탐지 시스템 (HIDS)이 필요합니다. HIDS는 일반적으로 경고, 자동 치료 솔루션을 통합하여 사용자 환경의 공격, 허가되지 않은 활동 또는 의심스러운 활동 및 일반적인 오류를 탐지하고 해결합니다.
 이 포스팅에서는 Amazon CloudWatch Logs를 사용하여 OSSEC (Open Source Security) HIDS에서 알림을 수집하고 집계하는 방법을 소개합니다. CloudWatch Logs 구독을 사용하여 Amazon Elasticsearch Service (이하 Amazon ES)에 alert을 전달해 분석하고 이것을 오픈 소스 도구인 Kibana로 시각화 합니다.
이 솔루션의 가시성을 위해 대부분의 배포 과정을 처리할 CloudFormation 템플릿도 제공할 것입니다. 이 솔루션을 통해 사용자는 EC2 인스턴스 플릿 전체에 대해 향상된 가시성과 통찰력을 확보할 수 있으며 보안성 개선에 도움을 받을 수 있습니다. 예를 들어, 특정 호스트가 EC2 인스턴스를 스캐닝해 OSSEC 경고를 트리거하는 경우 VPC 네트워크 접근통제 리스트(Access Control List) 또는 AWS WAF 규칙을 구현하여 해당 소스 개별 IP 주소 또는 전체 CIDR 블록을 차단할 수 있습니다.

솔루션 개요

다음 다이어그램은 지금부터 소개할 솔루션에 대한 개요를 보여줍니다.
솔루션은 다음과 같이 동작합니다:
  1. 대상 EC2 인스턴스에서 OSSEC HIDS는 alert을 생성하고 그것을 CloudWatch 로그 에이전트가 캡처합니다. HIDS는 로그 분석, 무결성 검사, Windows 레지스트리 모니터링, 루트킷 탐지, 실시간 경고 및 능동적 대응을 수행합니다. 자세한 내용은 OSSEC 시작하기를 참조하세요.
  2. CloudWatch 로그 그룹은 alert을 이벤트로써 수신합니다.
  3. CloudWatch 로그 구독은 대상 로그 그룹에 적용되어 AWS Lambda를 통해 Amazon ES로 이벤트를 전달합니다.
  4. Amazon ES는 기록된 alert 데이터를 로드합니다.
  5. Kibana는 alert을 실시간에 가깝게 시각화합니다. Amazon ES는 모든 Amazon ES 도메인에서 기본설정된 Kibana를 제공합니다.

배포 고려사항

 이 포스팅에서는, alert이 각 시스템에서 로컬로 생성되고 수집되는 Linux 머신에서 OSSEC HIDS을 구성합니다. 솔루션은 배포하려는 리전의 Amazon ES 및 Lambda에 영향을 받을 수 있으며 리전별 AWS 서비스에 대한 최신 정보는 리전 목록에서 확인할 수 있습니다. 또한, EC2 인스턴스가 필요한 구성 요소를 올바르게 제공 할 수 있도록 Amazon VPC (Virtual Private Cloud) 서브넷에서 인터넷 액세스 및 DNS 검색이 정상적으로 작동하는지 미리 확인해야합니다.
 배포 프로세스를 간소화하기 위한 테스트환경을 AWS CloudFormation 템플릿으로 만들어 두었습니다. 이 템플릿을 사용하면 테스트 환경 스택을 기존 Amazon VPC 서브넷에 자동으로 프로비저닝 할 수 있습니다. 이 경우, CloudFormation을 사용하여이 솔루션의 핵심 구성 요소를 프로비저닝 한 다음, alert 분석을 위한 Kibana 설정을 하면 됩니다. 이 솔루션의 소스 코드는 GitHub에서 내려받을 수 있습니다.
제공된 CloudFormation 템플릿은 선택된 리전에서 다음과 같은 단계를 수행합니다:
  1. CloudWatch의 로그에 액세스 할 수 있는 IAM(Identity and Access Management) 역할을 부여한 두 개의 Amazon Linux 인스턴스 생성. (참고 : 샘플 HIDS 경고 데이터를 얻기 위해 두 개의 EC2 인스턴스가 시뮬레이션 된 HIDS 경고를 로컬로 생성하도록 구성됩니다.)
  2. OSSEC, CloudWatch 로그 에이전트 및 테스트 환경에 사용되는 추가 패키지를 설치하고 구성합니다.
  3. 대상 HIDS Amazon ES 도메인을 만듭니다.
  4. 대상 HIDS CloudWatch 로그 그룹을 만듭니다.
  5. Amazon ES에 HIDS alert을 보내기 위해 Lambda 함수 및 CloudWatch Logs 구독을 만듭니다.
CloudFormation 스택이 배포되고 나면 Amazon ES 도메인의 Kibana 인스턴스에 액세스하여 아래에서 소개할 테스트 환경 설정을 마무리 할 수 있습니다.
 이 포스팅에서 다루는 범위를 조금 벗어난 이야기입니다만, OSSEC을 기존 EC2 환경에 배포 할 경우에는 모니터링 할 로그 파일, 무결성 검사할 디렉터리 및 활성 응답 등 원하는 구성을 직접 결정해야 하며 이후 시스템 환경을 최적화하고 테스트, 튜닝 등이 뒤따라야 합니다. OSSEC 문서에는 이러한 과정에서 참조할 많은 정보들이 있습니다. 또한 이벤트의 중앙처리 및 CloudWatch에의 전송을 담당할 에이전트 혹은 별도의 OSSEC 매니저를 이용하는 형식의 배포 또한 선택가능하나 이 경우에는 추가적인 서버 구성 요소와 에이전트와 관리자 간의 네트워크 통신이 필요합니다. Windows Server의 경우는 OSSEC이 지원하는 운영체제이지만 에이전트 기반 설치만 가능하므로 OSSEC 매니저를 이용해야 합니다. OSSEC 아키텍처 및 배포 옵션에 대한 추가적인 정보를 확인하기 위해서는 OSSEC 아키텍처 페이지에서 확인할 수 있습니다.

솔루션 배포

솔루션의 배포 단계는 다음과 같습니다:
  1. CloudFormation 스택 실행
  2. Kibana 색인 패턴 구성 및 alert 탐색 시작
  3. Kibana HIDS 대시 보드 구성 및 alert 시각화

1. CloudFormation 스택 실행

 자동 프로비저닝을 위해 CloudFormation 템플릿으로 테스트 환경을 시작합니다. 이를 위해 대상 VPC와 서브넷 (인터넷 액세스 필요)등 몇 가지 매개 변수를 입력해야합니다. 배포대상 서브넷이 인터넷 게이트웨이를 사용하는 경우 AssignPublicIP 매개 변수를 true로 설정하십시오. 대상 서브넷이 NAT 게이트웨이를 사용하는 경우 AssignPublicIP의 기본 설정(false)으로 두면 됩니다.
 먼저, 동일 리전의 S3 버킷에 Lambda 함수 배포 패키지를 준비해야합니다. 이를위해 압축 된 배포 패키지를 다운로드하여 버킷에 업로드하십시오. S3에 개체를 업로드하는 방법에 대한 자세한 내용은 Amazon S3에 개체 업로드를 참조할 수 있습니다.
또한 스택을 만든 후 환경에 액세스하고 인스턴스와 연결할 신뢰할 수있는 IP 주소 또는 CIDR 블록을  설정하고, 인스턴스와 묶일 EC2 키 쌍을 선택해야합니다. EC2 Key Pair 생성에 대한 자세한 내용은 Amazon EC2를 사용하여 Key Pair 만들기를 참조하십시오. 신뢰할 수있는 IP 주소 또는 CIDR 블록은 Kibana 액세스를 위해 자동으로 Amazon ES 엑세스 정책에 반영됩니다. 모든 IPv4 주소로부터 인스턴스에 액세스를 허용하는 0.0.0.0/0을 사용하기보다 특정 IP 주소 또는 CIDR 범위를 사용하는 것이 안전합니다. 인스턴스에 대한 인바운드 트래픽 권한 부여에 대한 자세한 내용은 Linux 인스턴스에 대한 인바운드 트래픽 인증을 참조하십시오.
입력한 매개 변수 (자세한 내용은 다음 스크린 샷과 표 참조)를 확인한 후 CloudFormation 스택을 생성합니다.
파라미터설명
1. HIDSInstanceSize테스트 서버에 사용할 EC2 인스턴스 사이즈
2. ESInstanceSizeAmazon ES 인스턴스 사이즈
3. MyKeyPair인스턴스 접속을 위한 공개/비밀 Key Pair 
4. MyS3Bucket압축 된 배포 패키지가 업로드된 동일 리전 S3 버킷
5. MyS3Key압축 된 배포 패키지가 업로드된 동일 리전 S3버킷의 Key
6. VPCId솔루션을 배포할 Amazon VPC
7. SubnetId
선택한 VPC 내에서 아웃바운드 연결을 사용하는 서브넷 ID
(인터넷 연결 필요)
8. AssignPublicIP서브넷이 인터넷게이트웨이를 통해 인터넷에 연결하도록 설정되어 있을 경우에는 true, NAT 게이트웨이를 통하도록 설정되어 있을 경우에는 false
9. MyTrustedNetworkEC2 인스턴스와 Amazon ES 엔트포인트로의 화이트리스트 엑세스를 허용할 신뢰할 수 있는 IP 혹은 CIDR 블록 
CloudFormation 스택 생성 마무리:
  1. 적절한 파라미터 입력 후 Next
  2. Options 페이지에서 default 설정 선택 후 Next
  3. Review 페이지에서 설정값들이 제대로 입력되었는지 확인 후 I acknowledge that AWS CloudFormation might create IAM resources 체크박스를 선택하고 Create. (스택 생성에 약 10분 소요)
스택이 생성되면 CloudFormation의 Outputs 탭에서 HIDSESKibanaURL을 확인한 후에 다음 섹션에서 설명할 Kibana 구성 넘어가십시오.

2. Kibana 색인 패턴 구성 및 alert 탐색 시작

이 섹션에서는 Kibana의 초기 설정을 수행합니다. CloudFormation의 스Outputs (이전 섹션 참조)에 제공된 HIDSESKibanaURL으로 접속하면 Amazon ES 인스턴스에 프로비저닝 된 Kibana 페이지로 이동합니다. CloudFormation 매개 변수로 입력한 IP는 Amazon ES 액세스 정책에 자동으로 반영이 되어 있습니다. 만약 다음과 같은 오류가 발생한다면 Amazon ES 액세스 정책이 올바른지 확인해야합니다.
{"Message":"User: anonymous is not authorized to perform: es:ESHttpGet on resource: hids-alerts"}
Amazon ES 도메인에 대한 액세스 보안에 대한 추가 정보는 Amazon Elasticsearch 서비스 도메인에 대한 액세스를 제어하는 방법을 참조하십시오.
OSSEC HIDS 경고가 이제 Amazon ES로 넘겨집니다. Kibana를 사용하여 대화식으로 alert 데이터를 분석하기위해서는, Amazon ES에서 분석할 데이터를 식별할 수 있도록 색인 패턴을 구성해야합니다. Kibana 문서에서 색인 패턴에 대한 추가 정보를 찾을 수 있습니다.
Index name or pattern 상자에 cwl-2017. *을 입력합니다. 색인 패턴은 람다 함수 내에서 cwl-YYYY.MM.DD로 생성되므로 와일드 카드 문자를 사용하여 2017의 데이터를 매칭할 수 있습니다. Time-field name 드롭 다운 메뉴에서는 @timestamp를 선택하하고 Create를 클릭합니다.
Kibana에서 이제 Discover 창이 선택가능해지고 alert이 채워지는 것을 볼 수 있습니다. alert 갱신 빈도를 설정하려면 오른쪽 상단에서 원하는 시간 범위 (예 : Last 15 minutes)를 선택하십시오.
 Auto-refresh을 선택하고 5 seconds 등 적절한 인터벌을 선택합니다.
Kibana는 이제 매 5초마다 자동 갱신 되도록 구성되었을 것입니다. 다음 스크린샷과 같이 카운트그래프와 함께 alert이 업데이트됩니다.
EC2 인스턴스는 CloudFormation에 의해 자동으로 구성된 두 다음과 같은 시뮬레이션이 동작하며 여러 alert을 표시합니다:
  • Successful sudo to ROOT executed – Linux의 sudo 명령어가 성공적으로 실행됨.
  • Web server 400 error code – 서버가 클라이언트 에러로 인해 요청을 진행하지 못함 (조작된 요청, 큰 사이즈, 유효하지 않은 요청 메시지 프레임 등)
  • SSH insecure connection attempt (scan) – SSH listener로 유효하지 않은 커넥션 시도
  • Login session opened – 시스템에서 로그인 세션이 열림
  • Login session closed – 시스템에서 로그인 세션이 닫힘
  • New Yum package installed – 시스템에 패키지가 설치됨
  • Yum package deleted – 시스템에서 패키지가 삭제됨
다음 스크린 샷으로 몇 가지 alert 필드들을 자세히 살펴 보겠습니다.
위 스크린 샷의 필드들은 다음과 같은 내용을 담고 있습니다:
  1. @log_group – CloudWatch 로그 그룹
  2. @log_stream – The CloudWatch 로그 스트임 이름 (인스턴스ID)
  3. @message – OSSEC의 원본 alerts.json에서의 JSON 페이로드
  4. @owner – alert이 발생한 AWS 계정 ID
  5. @timestamp – Lambda 함수에 의해 정의된 타임스탬프
  6. full_log – 로그 원본 파일
  7. location – 로그 원본의 경로와 파일이름
  8. rule.comment – OSSEC 룰에 대한 간략한 설명
  9. rule.level – 0~16으로 나뉜 OSSEC 룰 분류 (Rules Classification 페이지 참조)
  10. rule.sidid – OSSEC 룰 ID
  11. srcip – alert을 트리거한 IP 주소. 테스트시뮬레이션이 진행된 이 경우에는 서버의 로컬 IP가 표시됨
Kibana 쿼리 바에 검색 조건을 입력하면 HIDS 경고 데이터를 대화식으로 탐색 할 수 있습니다. 예를 들어, 다음 쿼리를 이용해 소스 IP가 10.10.10.10 이고 ID가 i-0e427a8594852eca2인 EC2인스턴스의 레벨 6 alert을 볼 수 있습니다.
“rule.level: 6 AND @log_stream: "i-0e427a8594852eca2" AND srcip: 10.10.10.10”
간단한 텍스트, Lucene 쿼리 구문 또는 전체 JSON 기반 Elasticsearch Query DSL에 이르기까지 다양한 방법을 사용할 수 있습니다. Elasticsearch 문서는 데이터 검색에 대한 추가 정보를 제공하고 있습니다.

3. Kibana HIDS 대시보드 구성 및 alert 시각화

시간 경과에 따른 alert의 추세 및 패턴 분석에는 차트 및 그래프가 유용할 수 있습니다. Kibana 인스턴스로 바로 import할 수 있는 대시보드 템플릿을 구성해 공유해두었습니다.
인스턴스에 샘플 HIDS 대시보드 템플릿 추가:
  1. 템플릿을 로컬에 저장하고 Kibana 네비게이션 창에서 Management 선택
  2. 차례대로 Saved ObjectsImport, 로컬에 저장한 샘플 HIDS 대시보드 템플릿을 선택합니다..
  3. HIDS Alerts 대시보드 항목의 오른쪽에있는 눈 모양 아이콘을 선택하십시오. 이 버튼을 누르면 추가한 대시보드 템플릿으로 이동할 것입니다.
Kibana 대시보드 템플릿으로 이동하면, 다음 스크린 샷과 같이 HIDS 대시보드가 표시됩니다. 이 HIDS 샘플 대시보드는 시간별 alert, 상위 20 개 alert 유형, 규칙 수준 분석, 상위 10 개 규칙 소스 ID 및 상위 10 개 소스 IP 등을 표시합니다.
다음 두개의 스크린샷과 같이 필터링 할 alert 유형을 선택해 alert 데이터를 더 자세히 탐색할 수 있습니다.
You can see more details about the alerts based on criteria such as source IP address or time range. For more information about using Kibana to visualize alert data, see the Kibana User Guide.
소스 IP 주소 또는 시간 범위와 같은 기준에 따라 자세한 내용들을 출력합니다. Kibana를 사용한 데이터 시각화의 자세한 내용은 Kibana User Guide를 참조하십시오.

요약

이 포스팅에서는 CloudWatch 로그를 이용해 OSSEC HIDS에서 alert을 수집하고 CloudWatch와 Kibana, 그리고 Amazon ES을 사용해 분석 및 시각화하는 방법을 설명했습니다. 이 솔루션은 AWS 환경에서 심층 방어 보안 전략의 일환으로 EC2 플릿의 보안 모니터링 개선에 일조합니다.
이 솔루션을 통해 EC2 플릿에 대한 공격이나 이상 행동 및 오류 추세를 탐지 할 수 있으며 시스템 재조정 작업의 우선 순위 지정이나 VPC 보안 그룹 규칙, VPC 네트워크 ACL 또는 AWS WAF 규칙과 같은 추가 제어 결정에 참고할 수 있을 것입니다.
이 게시물에 대한 의견이 있으시면 아래에 커맨트를 달아주시기 바랍니다. 이 솔루션 구현에 대한 질문 혹은 의견은 CloudWatch 또는 Amazon ES 포럼에서 새 스레드를 시작하십시오. 이 솔루션의 소스 코드는 GitHub에서 내려받을 수 있습니다. OSSEC 특정한 지원이 필요한 경우에는OSSEC Support Options을 참조하십시오.
– Cameron




번역된 컨텐츠입니다.

AWS Security Blog. by Cameron Worrell, How to Monitor Host-Based Intrusion Detection System Alerts on Amazon EC2 Instances. https://aws.amazon.com/blogs/security/how-to-monitor-host-based-intrusion-detection-system-alerts-on-amazon-ec2-instances/


Translated article.

AWS Security Blog. by Cameron Worrell, How to Monitor Host-Based Intrusion Detection System Alerts on Amazon EC2 Instances. https://aws.amazon.com/blogs/security/how-to-monitor-host-based-intrusion-detection-system-alerts-on-amazon-ec2-instances/

Thursday, May 4, 2017

Azure 클라우드 네트워킹 (원제: Networking to and within the Azure Cloud)

Azure 클라우드에서의 네트워킹



 하이브리드 네트워킹을 어떻게 정의해야 것인가. '가상네트워크로의 연결'이라는 맥락에서 정의한다면 이는 ExpressRoute 프라이빗 피어링이나 VPN 연결 같이 프레미스 자원과 하나 이상의 가상네트워크(VNet)들의 연결이라 있다.   모든 것들은 작동하고 있으며 우리는 이것들을 어떻게 사용하는지 알고 있지만, 이것들은 클라우드 안에서 대체 어떻게 움직이는 것일까. 여기에는 Azure 내장된 가지 이상의 방식이 작동한다.   포스팅을 통해 그것들을 간략하게나마 설명하고자 한다.
  • 하이브리드 네트워킹 연결 옵션
  • 클라우드 내부 연결 옵션
  • 옵션 종합


하이브리드 네트워킹 연결 옵션


기본적으로 4 가지 옵션이 있다.
  • 인터넷 연결
  • 사이트 연결 VPN (Point-to-site VPN)
  • 사이트 연결 VPN (Site-to-Site VPN)
  • ExpressRoute
인터넷 연결
 이름 그대로, 인터넷 연결은 가상 네트워크 내부에 위치한 다른 퍼블릭 엔트포인트를 노출시킴으로써 여러분의 워크로드를 인터넷을 통해 접근가능하도록 준다. 이를 위해 인터넷에 연결되어있는 부하분산장치 이용하거나 아니면 단순하게 VM NIC ipconfig 오브젝트에 퍼블릭 IP 할당함으로써 목적을 달성할 있다이를통해 인터넷상의 모든 것이 해당 가상 컴퓨터에 도달 가능해지며 호스트의 방화벽, 네트워크 보안 그룹(NSG) 사용자 정의 경로 통해 해당 가상 컴퓨터에 연결할 있다. 결론적으로 옵션을 이용해 인터넷을 통한 애플리케이션 공개가 가능하다.

사이트 연결 VPN 혹은 사이트 연결 VPN
  둘은 같은 범주에 속한다. VNet VPN 게이트웨이로 워크스테이션에서 직접 VPN 클라이언트를 이용해 사이트로 연결하거나 온프레미스 VPN 디바이스 Site-to-Site VPN 종말장치 기능을 이용해 연결하며, 이를통해 온프레미스 장치들이 VNet 내부의 자원들로 접근 가능해진다. 아래에서 클라우드 내부에서의 연결에 대해 다시 다룰 것이다.

ExpressRoute
  연결은 ExressRoute 기술 개요 자세히 설명되어 있다. 사이트 VPN 옵션과 마찬가지로 ExpressRoute 사용하면 하나 이상의 VNet 퍼져 있을 있는 리소스에도 연결할 있다. SKU 따라 하나 이상 이하의 VNet 연결을 허용하며 프리미엄 애드온 이용시 대역폭에 따라 최대 100 까지 연결 가능하다. 내용 또한 아래의 클라우드 내부 연결 옵션에 다시 설명하겠다.

Background


 클라우드 내부의 네트워킹에 대해 자세히 알아보기 전에VNet 개념 VNet 이상으로 구성하는 이유에 대해 이해가 필요하다
 VNet 개념을 설명한 문서 따르면, 이는 '사용자의 니즈에 맞게 Azure 내에 만들어진 고립된 네트워크' 요약할 있다예를 들어, 가상 머신을 프레미스에서 Azure 이동하기 시작한다면 작업이 필요할 것이다. 당신이 IP 주소 공간을 선택하므로 클라우드로 이전하기 전에 IP 주소 할당을 계획하는 것이 중요하다. Azure 당신 회사의 데이터센터를 확장한다면 당신은 IP CIDR 블록 혹은 클래스리스 도메인 라우팅 등에 대해서 고려해야 것이다.
 이제 VNet 무엇인지 조금 이해했다. 그럼 여러개의 VNets 도움이 되는 것일까? 기업은 서로 분리해두어야 필요가 있는 여러 비즈니스 라인을 보유하고 있는 경우가 있기 때문이다. 이것은 다른 비즈니스 단위로 인보이스를 발행하거나 서로 다른 가상 네트워크 관련 요소들 (네트워크 보안 그룹, 사용자정의 경로 ) 각각 관리해야 하는 이슈 등이 관련되어 있다.

클라우드 내부 연결 옵션
 비즈니스 라인들 간의 데이터 교환 혹은 가상 네트워크 IP 연결 시에 Azure 3 가지 네이티브 옵션을 제공한다.
방법들이 갖는 기능과 효과를 비교해 보자.


VPN 통한 VNet-to-VNet

 VPN 통해 2 개의 VNets 서로 연결되어 있는 경우 가상 네트워크의 라우팅 테이블은 다음 그림과 같다.
 2 개의 VNet 만으로도 흥미롭지만, 스케일을 키워보자.


 VNet4 VNet5 라우트 테이블은 VNet3 도달하는 경로를 나타낸다. 하지만 VNet4 VNet5 접근할 없는데, 이를 해결할 가지 방법이 있다.
  가지 방법을 사용하면 3 개의 VNet 모두가 서로에게 접근할 있다. 당연히 이는 많은 수의 VNet 구성하는 경우에도 확장가능하다.


ExpressRoute 통한 VNet-to-VNet

 하나 이상의 VNet 동일한 ExpressRoute 서킷에 연결 재미있는 부작용을 초래한다. 예를 들어 동일한 ExpressRoute 서킷에 연결된 2 개의 VNets 있는 경우의 라우팅 테이블은 다음과 같다.


 흥미롭게도 VNets MSEE (Microsoft Enterprise Edge) 라우터를 벗어나지 않고 서로 통신할 있는데, 이는 서로간의 통신을 위해 Microsoft 백본 떠날 필요가 없다는 것을 의미한다. 이것이 중요한가. 이는 VNets 통신시 추가적인 요금부과가 없도록 준다. 요컨대, ExpressRoute Premium 서킷 사용할 경우 동일한 지역 또는 글로벌 범위에서 VNets간에 통신하는 것이 가능하다. , 전세계의 Microsoft 백본을 사용하여 여러 VNets 함께 연결할 있으며, 이렇게 동일한 ExpressRoute 서킷에 연결된 VNet-to-VNet 트래픽은 요금이 부과되지 않는다. 아래 그림은 동일한 ExpressRoute 서킷에 연결된 3개의 VNet 보여준다


 위의 그림에서 VNet 서브넷의 Effective Route Table 나타나는 여러 경로를 있다.


가상 네트워크 피어링을 이용한 VNet-to-VNet

 복수 VNet 연결을 위한 마지막 선택지는 단일 Azure 리전 내에서 사용 가능한 가상 네트워크 피어링이다. 2 개의 VNet 피어링 배열은 VNet 본질적으로 1 개의 가상 네트워크 것처럼 작동하지만 NSG 라우트 테이블을 사용하여 통신을 제어 있다


 이를 허브와 스포크 형태의 토폴로지로 표현하면 다음과 같다.


 피어링은 VNet 넘어 전파되지 않으므로 HR VNet Marketing VNet 직접 대화 없지만 HR, 마케팅 엔지니어링의 VNet 모두 도메인 컨트롤러, 모니터링 시스템, 방화벽 또는 기타 Network Virtual Appliance (NVA) 등과 같은 공유 리소스를 포함하는 허브 VNet 대화 있다
 그러나 VPN 경우와 같이 VNet 서로 통신 있어야 한다면 다음과 같은 토폴로지를 참고할 있다.  명확한 이해를 위해 완전히 메쉬되지 않은 형태의 토폴로지를 준비했다. ( 경우 HR VNet Engineering VNet 직접 대화 없다). 이것으로부터 아이디어를 얻을 있을 것이다.


 VNet 피어링을 사용할 공유 가능할 있는 중요한 리소스 하나는 게이트웨이(VPN ExpressRoute 모두)이다

  방식을 이용해 각각의 스포크 VNet ExpressRoute 또는 VPN 게이트웨이를 배포하지 않고도 허브 VNet으로 보안 스탬프 게이트웨이 액세스를 중앙 집중화 있다.

옵션 종합 정리

 이러한 여러 방법과 옵션들은 개별적으로 충분히 흥미롭지만 함께 결합되어 강력한 기능을 제공한다.

게이트웨이 공유를 이용한 VNet 전파

 아래의 토폴로지는 간단한 허브 스포크 토폴로지를 보여준다. VNet 피어링 자체에서 전파가 불가능하더라도 게이트웨이(VPN ExpressRoute) 통해 중계 라우팅이 가능하다. VNet 피어링과 게이트웨이 공유를 사용하며 Express Route 사용하는 예는 다음과 같다.

게이트웨이 공유를 이용한 VNet 전파, 2 리전의 1  ExpressRoute 서킷

 하나 이상의 Azure 리전(VNet 피어링은 단일 리전에 만들어진다.) 결합하기 위해서는 다음과 같은 토폴로지를 사용할 있다

 위의 이미지에서 서부 미국 동부 미국 모든 VNet SKU 따라 1, 2, 혹은 10Gbps 속도로 Microsoft 백본 네트워크 내에서 서로 통신한다. 미국 동부 리전을 향하는 패킷은 미국 서부 리전과 시카고 사이에서 물리적으로 라우팅 된다는 점을 주목하자. 이는 시카고가 리전 사이에 위치하기 때문이다.

게이트웨이 공유를 통한 VNet 전파, 2 리전의 2 ExpressRoute 서킷

 시카고보다 ExpressRoute 대한 연결이 필요한 곳인 경우 혹은 단일 ExpressRoute로는 탄력성이 부족할 경우 다음과 같은 토폴로지를 만들 있다.

 프레미스들이 미국 서부 동부에 위치할 경우 프레미스 연결이 나은 지연 시간을 가질 있다. 또한, 동서부 각각에 위치한 VNet 간에 패킷이 전달될 있는 2 개의 ExpressRoute 있다. 이러한 리전들은 서킷 위치와 가깝기 때문에 조금의 레이턴시가 추가되어도 문제가 되지 않는다. 게다가 이러한 구조는 별개의 위치에서 별개의 ExpressRoute 회로를 사용하기 때문에 높은 가용성을 보장한다.

게이트웨이 공유를 통한 VNet 전파, 3 리전의 3 ExpressRoute 서킷

  모델은 많은 서킷과 많은 리전으로 확장 수도 있으며 Azure Networking 툴박스를 사용하여 만들 있는 토폴로지에 대한 이해를 돕기에도 적절하다.

 최적의 라우팅을 위해서는 로컬 서킷이 중요하다. 이에 대해 ExpressRoute 라우팅 최적화 관련된 글을 참고하는 것이 좋다. 글에서는 서부에서 출발해 북유럽을 향하는 패킷이 도쿄의 ExpressRoute 서킷을 통과하지 않도록 설정하는  가상네트워크 최적의 라우팅 설정에 대해 서술하고 있다. 연결에 대해 가중치를 부여함으로써 이러한 목적달성이 가능하다.

BGP 활성화된 VPN 게이트웨이의 공유와 VPN 전파 라우팅을 통한 VNet 전파

 아래의 토폴로지는 BGP 라우팅을 사용하는 VPN 전송의 다른 재미있는 사례를 보여준다. 자세한 내용은 Azure VPN 게이트웨이 BGP 개요에서 확인 가능하다.

  그림에서는 프록시와 같은 매커니즘 없이 Azure 백본을 효과적으로 사용함으로써 개의 시설을 연결하고 있는데 서부 온프레미스 환경에 위치한 사용자가 VPN 통해 북유럽 VNet 연결된 VPN 사용자에 접근할 있도록 작동한다.











번역된 컨텐츠입니다.

Microsoft Azure. by Olivier Martin, Global Black Belt - Azure Networking. https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud/, https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud-part-2/, https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud-part-3/

Translated article.

Microsoft Azure. by Olivier Martin, Global Black Belt - Azure Networking. https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud/, https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud-part-2/, https://azure.microsoft.com/en-us/blog/networking-to-and-within-the-azure-cloud-part