Netskope Private Access란 무엇입니까?

이 가이드에서는 Netskope Private Access의 특징과 기능을 간략하게 설명합니다.

영향을 받는 제품:

Netskope

영향을 받는 버전:

릴리스 70+

해당 사항 없음

Netskope Private Access는 다음을 수행하는 최신 원격 액세스 서비스입니다.

퍼블릭 클라우드(예: Amazon Web Services, Azure, Google Cloud Platform)와 데이터 센터 모두에서 여러 네트워크의 애플리케이션에 액세스할 수 있도록 팬아웃합니다.
측면 이동으로 네트워크에 액세스하는 대신 제로 트러스트 애플리케이션 레벨 액세스를 제공합니다.
전 세계적으로 확장 가능한 클라우드 서비스로 제공됩니다.

Netskope Private Access는 Service Publishing이라고 하는 기능을 통해 이러한 이점을 제공합니다. Service Publishing은 엔터프라이즈의 네트워크 엣지 대신 Netskope 클라우드 플랫폼에서 그리고 Netskope 클라우드 플랫폼을 통해 엔터프라이즈 애플리케이션을 사용할 수 있도록 합니다.

Netskope 클라우드 플랫폼은 엔터프라이즈 애플리케이션에 액세스하는 인터넷상의 위치입니다. 어떤 의미에서는 DMZ(Demilitarized Zone)의 액세스 구성 요소를 표면화합니다. 이러한 방식으로 원격 액세스를 표면화하는 것은 기존 VPN(Virtual Private Network)과 프록시 기반 원격 액세스 방식에 비해 몇 가지 이점이 있습니다. Service Publishing의 전반적인 아키텍처와 Delivery-as-a-Service 모델은 IT 트렌드와 일치합니다. 여기에는 IaaS(Infrastructure as a Service), 하이브리드 IT 및 데이터 센터, 퍼블릭 클라우드, SaaS(Software as a Service)에서 엔터프라이즈 애플리케이션을 분산적으로 제공하는 기능이 포함됩니다.

Netskope Private Access는 SaaS 및 웹에 안전하게 액세스하기 위해 Netskope의 플랫폼을 확장합니다. 여기에는 데이터 센터와 퍼블릭 클라우드 내에서 엔터프라이즈의 방화벽 뒤에 있는 전용 애플리케이션에 대한 안전한 액세스가 포함됩니다.

다음은 Netskope Private Access에 대한 일반적인 질문입니다.

참고: 일부 질문은 답변이 복잡하고 길어서 다른 페이지로 연결될 수 있습니다.

VMware 환경에 게시자를 배포하기 위한 요구 사항은 무엇입니까?

Netskope Private Access 시스템 요구 사항은 배포 환경에 따라 다릅니다. 자세한 내용은 다음을 참조하십시오. Netskope Private Access 게시자에 대한 시스템 요구 사항을 참조하십시오.

Netskope Private Access가 올바르게 작동하려면 어떤 포트가 필요합니까?

구성 요소	URL	포트	참고
클라이언트	gateway.npa.goskope.com 2020년 2월 이전: gateway.newedge.io	TCP 443(HTTPS)
게시자	stitcher.npa.goskope.com 2020년 2월 이전: stitcher.newedge.io	TCP 443(HTTPS) UDP 53(DNS)	로컬 네트워크 DNS 서버가 내부에 있는 경우 DNS를 아웃바운드로 설정할 필요가 없습니다.
클라이언트 및 게시자	ns[TENANTID]. [MP-NAME].npa.goskope.com 2020년 2월 이전: ns-[TENANTID].newedge.io	TCP 443(HTTPS)	이 작업은 등록 중에 한 번만 필요합니다. URL 예: ns-1234.us-sv5.npa.goskope.com [MP-NAME] 변수: us-sv5 (SV5) us-sjc1 (SJC1) de-fr4 (FR4) nl-am2 (AM2)

참고:

[TENANTID] = 사용자 환경에 고유한 테넌트 ID
[MP-NAME] = Netskope 관리 평면 위치
[TENANTID] 또는 [MP-NAME]을 식별하는 데 도움이 필요한 경우 Netskope에 대한 지원을 받는 방법을 참조하십시오.
기본 포트는 사용자 환경의 포트와 다를 수 있습니다.

내 애플리케이션을 사용해야만 작동되는 TCP 및 UDP 포트를 알 수 없습니다. 어떻게 해야 합니까?

애플리케이션 및 서비스에 사용자를 연결하려면 일부 위치의 Netskope UI 내에서 Netskope Private Access 관리자가 전용 앱 정책을 구성해야 합니다. 다음은 알려진 애플리케이션 및 서비스 유형에 대한 구성 옵션 및 세부 정보입니다.

애플리케이션	프로토콜 및 포트	요소
웹 트래픽	TCP: 80, 443(맞춤형 포트: 8080 등) UDP: 80, 443	Google Chrome은 일부 웹 애플리케이션에 QUIC 프로토콜(UDP 기반 HTTP/S)을 사용합니다. TCP와 UDP 모두에 대해 웹 검색 포트를 복제하면 성능이 향상될 수 있습니다.
SSH	TCP: 22
원격 데스크탑(RDP)	TCP: 3389 UDP: 3389	일부 Windows RDP(Remote Desktop Protocol) 클라이언트 앱(예: 최신 Windows 10 버전)은 UDP: 3389를 사용하여 원격 데스크탑을 연결하는 것을 선호합니다.
Windows SQL Server	TCP: 1433, 1434 UDP: 1434	Windows SQL Server의 기본 포트는 1433이지만 사용자 환경에서 맞춤 구성할 수 있습니다. 자세한 내용은 SQL Server 액세스를 허용하도록 Windows 방화벽 구성(https://docs.microsoft.com/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access?view=sql-server-2017 )을 참조하십시오.
MySQL	TCP: 3300-3306, 33060 TCP: 33062(관리자 특정 접속의 경우)	일반적인 MySQL 연결을 사용하는 경우 포트 3306만 필요하지만 일부 사용자는 추가 MySQL 기능 포트를 사용할 수 있습니다. Netskope는 MySQL 데이터베이스 전용 앱 포트 범위를 사용할 것을 권장합니다. MySQL은 연결 테스트를 잠재적인 공격으로 탐지하므로 Netskope Private Access 게시자의 연결을 차단합니다. 포트 구성의 범위를 사용하면 Netskope Private Access 게시자가 범위의 첫 번째 포트에서만 연결성 검사를 수행합니다. 이렇게 하면 MySQL에서 이 트래픽을 볼 수 없으며 포트 블록이 발생하지 않습니다. 자세한 내용은 MySQL 포트 참조 테이블(https://dev.mysql.com/doc/mysql-port-reference/en/mysql-ports-reference-tables.html )을 참조하십시오.

참고: 기본 포트는 사용자 환경의 포트와 다를 수 있습니다.

Netskope Private Access에서 위에 나열된 일반적인 프로토콜 및 포트가 아닌 프로토콜 및 포트를 터널링할 수 있습니까?

예. Netskope Private Access에서는 해당 목록에 없는 앱을 터널링할 수 있습니다. Netskope Private Access는 TCP 및 UDP 프로토콜과 모든 관련 포트를 지원합니다. 단, 한가지 눈에 띄는 예외가 있습니다. Netskope는 대부분의 DNS 트래픽을 터널링하지 않지만, 포트 53을 통한 DNS 서비스(SRV) 조회를 터널링하는 기능을 지원합니다. 이는 LDAP, Kerberos 등과 관련된 다양한 Windows Active Directory 환경에서 사용되는 서비스 검색에 필요합니다.

참고: 경우에 따라 VoIP와 같은 애플리케이션에 문제가 있을 수 있습니다. 터널링보다는 구성으로 인해 발생합니다. 예를 들어 연결을 설정할 때 동적 포트 할당을 수행하는 애플리케이션이 문제가 될 수 있습니다. 이는 애플리케이션 서비스 종료 시까지 어떤 포트를 설정할지 관리자가 미리 알 수 없기 때문입니다. 따라서 어떤 포트를 지정할지 알 수 없습니다.

전용 앱 및 서비스를 사용할 수 있는지 여부를 확인하기 위해 게시자가 사용하는 서비스 및 폴링 간격은 무엇입니까?

폴링 간격은 약 1분입니다.

Netskope Private Access 게시자는 전용 앱에 구성된 포트에 연결하여 전용 앱에 연결할 수 있는지 여부를 확인하려고 합니다.

고려해야 할 중요한 요소:

게시자는 호스트 이름(예: jira.globex.io)과 포트(예: 8080)를 통해 전용 앱을 정의하는 경우 가장 효과적으로 작동합니다.
여러 개의 포트 또는 포트 범위를 사용하여 앱을 지정하는 경우 게시자는 목록 또는 범위의 첫 번째 포트를 사용하여 가용성을 확인합니다.
게시자는 와일드카드(*.globex.io) 또는 CIDR 블록(10.0.1.0/24)을 사용하여 정의된 전용 앱에 대한 연결을 확인할 수 없습니다. 포트 범위가 정의된 앱(3305-3306)의 연결도 확인하지 않습니다.

초기 배포 중에 게시자 등록 토큰이 손상되면 어떻게 됩니까? 게시자에서 로컬로 다시 설정할 수 있습니까?

등록에 실패한 경우(예: 등록 코드를 입력하는 중에 숫자가 누락되었기 때문) 게시자에 SSH를 실행하고 새 등록 토큰을 제공합니다.

등록에 성공했지만 다른 토큰을 사용하여 게시자를 등록하기로 결정한 경우 이 작업은 지원되지 않으며 권장되지 않습니다. 이 시나리오에서는 게시자를 다시 설치합니다.

Netskope Private Access에서 ICMP를 터널링할 수 있습니까?

아니요. Netskope Private Access에서는 ICMP가 아니라 TCP와 UDP만 터널링합니다. Netskope Private Access에 대해 ping 또는 traceroute 명령을 실행하여 네트워크 연결을 테스트할 수 없습니다.

Netskope Private Access는 전용 앱에서 클라이언트로 설정된 연결 터널링을 지원합니까?

아니요. Netskope Private Access에서는 전용 앱에서 클라이언트까지 연결을 설정하는 프로토콜을 지원하지 않습니다. 예를 들어, FTP 활성 모드는 지원되지 않습니다.

게시자 연결을 프록시 설정 또는 TLS 종료할 수 있습니까?

아니요. 게시자는 특정 인증서에 대한 등록 프로세스와 서버측 인증서 인증을 위해 SSL을 고정합니다.

이 경우 TLS 연결을 종료하는 프록시가 있으면 대상이 허용 목록에 있거나 우회(*.newedge.io)되어야 합니다.

전용 앱 허용 목록의 경우 Netskope Private Access에서 전용 앱 수준에 표시되는 IP 주소는 무엇입니까? 범위가 있습니까?

전용 앱 호스트에 연결되는 게시자의 IP 주소에서 시작되는 연결이 표시됩니다. 범위는 없습니다. 전용 앱 호스트에 연결하는 데 사용되는 게시자 수에 따라 각 IP 주소를 허용 목록에 등록해야 합니다.

Amazon Web Services 게시자에 SSH를 실행하려면 어떻게 해야 합니까?

Amazon Web Services에 배포하는 경우 AMI(Amazon Machine Image)에 게시자를 프로비저닝하는 동안 이미 가지고 있는 KeyPair.pem(또는 새로 생성한 KeyPair.pem)을 할당합니다.

SSH 클라이언트에서 ssh -i [KEYPAIR.PEM] centos@[PUBLISHER]를 입력한 다음 <Enter> 키를 누릅니다.

참고:

[KEYPAIR.PEM] = KeyPair.pem 파일의 경로
[PUBLISHER] = 게시자의 외부 IP 주소
게시자의 기본 사용자 이름은 다음과 같습니다.
- centos
Amazon Web Service AMI의 기본 사용자 이름은 다음과 같습니다.
- ec2-user

SSH를 사용하여 게시자에 연결하면 대화형 CLI(Command-Line Interface) 메뉴로 이동합니다. 추가 문제 해결을 위해 옵션 3을 선택하여 정상 UNIX CLI로 이동할 수 있습니다. 자세한 내용은 게시자 뒤에 있는 전용 앱/서비스에 대한 접근성 문제를 해결하는 좋은 방법은 무엇입니까?를 참조하십시오.