제로 트러스트 애플리케이션 게시 구성
애플리케이션 게시는 프록시 클러스터로 접근 지점을 제공하고 요청을 구성된 대상으로 전달합니다. 클러스터, 게시 서비스, 대상 애플리케이션과 접근 제한은 각각 준비하고 검증해야 합니다. 서비스 생성이 프록시 온라인, DNS 확인, 인증서 사용 또는 대상 접근을 보장하지 않습니다.
준비
- 필요한 제로 트러스트 권한이 있는 최고 관리자 계정을 사용합니다. 조회, 생성, 수정과 삭제는 서로 다른 권한이 필요할 수 있습니다.
- 네트워크 및 애플리케이션 관리자와 접근 도메인, 프록시 배포, 대상 프로토콜과 포트, 인증서 및 허용 인원이나 네트워크를 확인합니다. 테스트 애플리케이션과 통제된 범위로 시작하고 조직의 변경 승인을 받습니다.
- 대상 유형에 따라 노드 또는 네트워크 리소스를 준비합니다. HTTP 비공개 서비스에 접근할 노드를 제한하려면 접근 제어에서 그룹을 만들거나 선택하고 상세의 「Add Endpoints」로 승인된 시험 노드를 추가해 확인합니다. 기존 그룹의 다른 참조도 확인합니다.
- 대상 경로에 필요한 접근 정책, 경로, 대상 방화벽과 반환 경로를 확인합니다. 그룹, 서비스 인증과 네트워크 정책은 역할이 다르며 하나를 저장해도 전체 접근이 검증되지는 않습니다.
프록시 클러스터 생성
- 제로 트러스트 애플리케이션 게시의 프록시 클러스터를 열고 「Create Proxy Cluster」를 선택합니다.
- 이름과 공개 도메인을 입력하고 저장합니다. 공개 도메인은 프록시 배포 설정과 일치해야 하며 도메인, DNS 및 인증서 계획을 담당자와 확인합니다.
- 화면에 따라 클러스터 토큰을 처리합니다. 생성 시 토큰은 한 번만 표시됩니다. 승인된 배포 담당자에게 안전한 경로로 전달하고 일반 문서, 채팅이나 티켓에 넣지 않습니다.
- 승인된 절차로 프록시 인스턴스를 배포하고 클러스터 페이지에서 온라인 인스턴스와 기능을 확인합니다. 온라인 인스턴스 보고를 기다리는 동안 비공개 서비스나 사용자 지정 포트 기능을 가정하지 않습니다. 클러스터 생성만으로 인스턴스가 온라인이 되지 않습니다.
게시 서비스와 대상 설정
- 게시 서비스를 열고 「Create Published Service」를 선택합니다. 서비스에서 클러스터, 이름, 게시 도메인과
HTTP,TCP,UDP,TLS프록시 모드를 선택하고 배포 요구와 도메인을 확인합니다. HTTP외 모드에서는 화면에 따라 포트 할당 방식과 수신 포트를 확인합니다. 사용자 지정 포트는 클러스터 보고 기능에 따라 달라지므로 방화벽과 충돌을 먼저 확인합니다.- 대상을 추가합니다. 유형은 「Endpoint」, 「Network Resource」, 「Proxy Host Direct」입니다. 엔드포인트나 리소스는 해당 개체도 선택하며 사용할 수 없으면 상태와 참조를 확인합니다.
- 대상 주소를 입력하고 실제 백엔드 프로토콜과 포트를 확인합니다.
HTTP는http://또는https://주소와 필요한 경로를 사용하고 다른 모드는 호스트와 포트를 입력합니다. 엔드포인트 또는 정확한 리소스를 참조할 때 선택 개체와 표시된 대상을 확인하고 예시 호스트 이름을 독립적인 권한으로 취급하지 않습니다. - 필요하면 대상을 더 추가하고 개체, 주소, 포트와 서비스를 각각 확인합니다. 화면 예시는 형식일 뿐 접근 가능성을 보장하지 않습니다.
HTTP 서비스의 각 대상 경로는
/로 시작해야 하며 같은 서비스 안에서 중복될 수 없습니다. 기본 경로/도 한 번만 사용할 수 있습니다. 여러 대상을 추가하기 전에/reports,/sales처럼 서로 다른 경로를 계획하고 각 전달 결과를 검증하십시오. 저장에 실패하면/가 중복되었는지 확인합니다.
Proxy Host Direct 보안 경계: 페이지에 따르면 프록시 호스트가 대상에 직접 접근하여 제로 트러스트 라우팅, 접근 제어와 로컬 네트워크 격리를 거치지 않습니다. 루프백, 링크 로컬, 멀티캐스트 주소는 대상이 될 수 없습니다. 프록시 접근 범위, 방화벽과 대상 보호를 별도로 평가하고 해당 제로 트러스트 제어가 이 경로를 제한한다고 가정하지 않습니다. 대상이 호스트 이름일 때 저장 성공이 프록시가 실제로 확인한 모든 주소에 연결할 수 있다는 뜻은 아닙니다. 확인된 주소가 루프백, 링크 로컬 또는 멀티캐스트 등 제한된 주소이면 해당 연결이 거부될 수 있습니다. 프록시 호스트 환경에서 이름 확인과 대상 도달 가능성을 확인하고 DNS 변경 후 다시 검증하십시오. 이름을 바꾸어 제한을 우회하지 마십시오.
HTTP 서비스 접근 방식
HTTP 인증 페이지의 방식은 서로 다릅니다. 대상 사용자와 보안 요구를 확인합니다.
- Zero Trust Network Only: 클러스터의 온라인 인스턴스, 비공개 프록시 모드와 비공개 서비스 지원을 확인합니다. 옵션을 켜고 준비한 접근 그룹을 하나 이상 선택합니다. 페이지는 연결되고 그룹에 일치하는 노드만 접근한다고 설명하지만 일치·비일치 노드를 모두 시험합니다.
- 그 외 방식: 「No Authentication」, PIN 또는 「Password」를 선택합니다. 생성하거나 PIN·비밀번호로 전환할 때 자격 증명을 입력하며 PIN은 여섯 자리 숫자입니다. 조직 요구에 따라 세션 유효기간을 설정하고 자격 증명을 안전하게 보관·전달합니다. 인증 없음을 선택하기 전에 노출과 위험을 평가하고 사용자 인증이 자동으로 적용된다고 가정하지 않습니다.
- 비공개 서비스의 그룹 선택과 비공개가 아닌 서비스의 PIN·비밀번호는 다른 방식입니다. 전환 후 옵션, 허용 대상과 실제 접근을 다시 확인합니다. 비
HTTP모드에는 이 인증 페이지가 표시되지 않으므로 동일한 보호를 자동으로 받는다고 가정하지 않습니다.
PIN 또는 비밀번호 인증을 선택하거나 전환하면 페이지가 로그인 세션 유효기간을 86400초(24시간)로 설정합니다. 입력 범위는 60604800초(1분7일)입니다. 이는 전환 시 초기값이며 기존 서비스의 현재 설정을 뜻하지 않습니다. 조직 요구에 따라 설정하고 저장하며 인증 방식을 변경한 후 자격 증명과 기간을 다시 확인합니다.
제한 설정과 검증
- 「Access Control」에서 필요에 따라 「Allowed CIDRs」와 「Blocked CIDRs」를 입력합니다. 고급 설정에서 대상 시간 제한, 전달 및 적용 옵션을 확인합니다. 단일 목록만으로 결과를 판단하지 말고 실제 배포에서 시험합니다.
- 대상 서비스의 인증서와 연결 요구를 확인합니다. 페이지는 통제된 내부망에서 확인할 수 없는 자체 서명 인증서에 대해 백엔드 TLS 검증을 건너뛰는 옵션을 제공합니다. 활성화 전 보안을 평가하며 기본 문제 해결 방식으로 삼지 않습니다.
- 저장 전 클러스터, 도메인, 대상, 인증, 그룹과 네트워크 제한을 검토합니다. 저장 후 목록에서 활성 상태와 실행 상태를 확인합니다. 프록시 대기, 터널 미설정 또는 인증서 관련 상태가 서비스 가용성을 뜻하지는 않습니다.
- 승인된 클라이언트에서 DNS, 포트, 인증서, 인증과 대상 앱을 시험하고 비인가 클라이언트에서 제한을 시험합니다. 비공개 접근은 그룹 일치·비일치 노드를 각각 사용합니다.
- 서비스 목록의 접근 로그와 감사 로그에서 서비스와 시간을 대조합니다. 로그는 기록된 단계의 단서이며 실제 접근과 보안 시험을 대체하지 않습니다.
CIDR 예시: 허용 목록이 비어 있지 않으면 출발지 주소가 하나 이상에 일치해야 하며 차단 목록에도 일치하면 거부됩니다. 허용 목록이 비어 있으면 해당 목록으로 출발지를 제한하지 않지만 차단 목록과 다른 통제는 적용될 수 있습니다. 예를 들어 10.20.0.0/16을 허용하고 10.20.5.0/24를 차단하면 10.20.4.10은 이 CIDR 검사를 통과하고 10.20.5.10은 차단 목록 때문에, 10.21.4.10은 허용 범위 밖이므로 거부됩니다. 주소는 예시입니다. 상위 프록시나 네트워크 주소 변환은 프록시가 인식하는 출발지에 영향을 줄 수 있으므로 배포 환경에서 확인하고 테스트합니다. CIDR 통과는 인증, 접근 그룹 또는 대상 서비스 등 다른 조건의 충족을 보장하지 않습니다.
인증 열 해석: HTTP 접근에서 인증 열의 성공 또는 실패 표시는 HTTP 응답 상태의 영향을 받을 수 있습니다. 401 또는 403은 실패로, 서비스 오류를 포함한 다른 상태는 성공으로 표시될 수 있습니다. TCP, UDP, TLS와 같은 비 HTTP 기록에서 실패가 표시되어도 사용자 인증 실패가 발생했다는 뜻은 아닙니다. 통제된 시험에서 서비스 인증 방식, 응답 코드, 접근 출발지와 대상 애플리케이션 로그를 함께 확인하고 이 열만으로 인증 성공·실패나 사용자 신원을 단정하지 마십시오. 영문 화면의 해당 표시는 Authentication, Success, Failed입니다.
변경 및 문제 해결
- 저장 불가: 클러스터, 이름, 도메인, 대상 개체와 주소 형식을 확인합니다. 비 HTTP는 수신 포트, 비공개 HTTP는 온라인 인스턴스, 기능 및 하나 이상의 그룹도 확인하고 PIN 요구를 따릅니다.
- 생성 후 접근 불가: 활성·실행 상태, 프록시, DNS, 포트, 방화벽, 인증서, 대상 서비스와 경로를 각각 확인합니다.
- 인증·접근 불일치: 비공개 모드 또는 인증, 그룹, 허용·차단 네트워크, 다른 정책과 대상 제어를 확인하고 허용·거부 대상을 모두 시험합니다.
- 수정·비활성화·삭제: 참조, 사용자와 업무 의존성을 확인하고 설정을 기록하여 승인 절차를 따릅니다. 변경 후 상태, 제한과 업무를 다시 확인하며 토큰과 자격 증명은 안전하게 처리합니다.
수정일