> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/deployment/ko/self-hosted/inference-server/configuration/security.md). # 자체 호스팅 서버 보안 강화 기본적으로 자체 호스팅 Inference를 로컬로 유지하고, 누가 워크플로를 실행할 수 있는지 선택하며, 모델, 미디어 및 전송 제어를 구성합니다. 자체 호스팅 추론은 로컬 개발을 허용적으로 유지합니다. 사용자 정의 Python은 기본적으로 로컬에서 실행되며, 인증을 구성하지 않는 한 서버에 API 키가 필요하지 않습니다. CLI는 서버를 다음 주소에 게시합니다. `127.0.0.1` 기본적으로, 아래 예외를 제외하고는 그렇기 때문에 다른 머신은 해당 게시된 포트에 도달할 수 없습니다. 업그레이드 동작과 버전 범위는 다음을 참조하세요. [보안 구성 마이그레이션](/deployment/ko/self-hosted/inference-server/configuration/security-migration.md). ## 네트워크 액세스 제한 어떤 Workflow 기능을 사용할 수 있는지를 변경하기 전에 클라이언트가 서버에 어떻게 도달하는지 선택하세요.
실행 방법기본 네트워크 액세스구성
CPU 또는 GPU 호스트에서의 Inference CLI호스트 루프백, 127.0.0.1:9001다른 호스트 주소를 선택하려면 --bind-address 또는 -b를 사용하세요.
Jetson 이미지에서의 Inference CLI모든 호스트 인터페이스, 0.0.0.0:9001로컬 전용 액세스를 위해 --bind-address 127.0.0.1을 사용하세요.
macOS 및 Windows 데스크톱 번들127.0.0.1다른 인터페이스를 선택하려면 HOST를 명시적으로 설정하세요.
수동 Docker 또는 Compose포트 매핑에 따라 결정됨로컬 전용 액세스를 위해 127.0.0.1:9001:9001을 사용하세요.
--tunnel을 사용하는 Inference CLICLI는 터널이 연결할 수 있도록 0.0.0.0에 게시합니다.LAN과 터널 액세스 둘 다 검토하세요.
### CLI로 서버 시작 `inference server start` 포트 9001을 다음에 게시합니다. `127.0.0.1`, 따라서 이런 방식으로 시작된 서버는 시작한 머신의 프로세스에만 응답합니다. 이는 로컬 개발을 위한 올바른 기본값이며, 이 페이지의 허용적 기본값이 안전한 유일한 구성입니다. CLI는 루프백이 아닌 주소에 게시할 때 경고를 표시합니다. ```bash # 기본값: 이 머신에서만 접근 가능 inference server start # 의도적인 LAN 액세스: 이 호스트로 라우팅할 수 있는 모든 머신에서 접근 가능 - 먼저 보호하세요 inference server start --bind-address 0.0.0.0 --env-file inference.env ``` {% hint style="warning" %} **NVIDIA Jetson은 예외입니다.** Jetson 이미지는 다른 머신에서 거의 항상 제어되는 헤드리스 엣지 디바이스이므로 `inference server start` 다음에 게시합니다. `0.0.0.0` - 장치로 라우팅할 수 있는 모든 것에서 접근 가능하며, 연결된 Wi‑Fi 네트워크의 나머지 장치들도 포함됩니다. 아래 제어를 적용하거나, 다음으로 고정하세요. `inference server start --bind-address 127.0.0.1`. {% endhint %} ### 다음을 사용해 서버 시작 `docker run` 이미지가 이 선택을 대신해 줄 수는 없으므로 **명령줄에서 직접 선택해야 합니다**. `HOST` 인터페이스를 선택합니다 *내부* 컨테이너 안에서, 그리고 컨테이너는 자체 네트워크 네임스페이스를 가집니다. 다음이 포함된 이미지라면 `HOST=127.0.0.1` 컨테이너 자체의 루프백에 바인딩하게 되며, 게시된 포트는 이에 도달할 수 없습니다. 따라서 서버는 호스트에서도 접근할 수 없게 됩니다. 이것이 모든 이미지가 다음과 함께 제공되는 이유입니다. `HOST=0.0.0.0`. 브리지 네트워크 컨테이너 내부에서는 이 상태를 유지하고, 대신 포트 매핑의 호스트 쪽에서 제한을 두세요: ```bash # 이 머신에서만 접근 가능 docker run --rm -p 127.0.0.1:9001:9001 roboflow/roboflow-inference-server-cpu:latest # 이 호스트로 라우팅할 수 있는 모든 머신에서 접근 가능 - 먼저 보호하세요 docker run --rm -p 9001:9001 roboflow/roboflow-inference-server-cpu:latest ``` 두 경우는 다르게 동작합니다: * **`--network host`** (Linux)는 포트 매핑을 완전히 제거하므로 컨테이너가 호스트 인터페이스에 직접 바인딩합니다. 그 경우, `-e HOST=127.0.0.1` *은* 서버를 로컬로 유지하는 방법입니다. * **Kubernetes** 는 각 pod에 자체 네트워크 네임스페이스를 제공하므로 `HOST=0.0.0.0` 를 유지하고, 바인드 주소가 아니라 Service 유형과 NetworkPolicy로 노출을 제어하세요. {% hint style="warning" %} **`-p 9001:9001` 는 모든 인터페이스를 의미합니다.** 명시적인 주소가 없으면 Docker는 다음에 게시합니다. `0.0.0.0`, 호스트가 가진 모든 공용 IP를 포함하여. Linux에서는 Docker 자체의 전달 규칙이 먼저 평가된 다음 `ufw`/`firewalld` 규칙보다 대부분의 기본 설정에서 먼저 적용되므로, 별도로 구성한 호스트 방화벽이 이를 차단하지 못할 수 있습니다. 실제로 무엇이 수신 대기 중인지 다음으로 확인하세요. `docker port ` 또는 `ss -tlnp | grep 9001`. {% endhint %} {% hint style="info" %} 직접 Python 서버 실행, 호스트 네트워킹, 수동 Docker 게시에는 별도의 네트워크 구성이 필요하며, CLI 기본값은 그런 경로를 제한하지 않습니다. {% endhint %} 루프백 이외의 주소에 바인딩하면 신뢰할 수 없는 클라이언트가 서버에 도달할 수 있으며, 이 페이지에 설명된 기본값은 그런 상황을 위해 작성된 것이 아닙니다. 포트를 노출하기 전에 최소한 다음을 수행하세요: [원격 클라이언트를 허용하기 전에](#before-allowing-remote-clients) 먼저. ## 인증 강제 다음을 설정하세요 `WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENT` 허용된 Workspace 슬러그로 설정하여 추론, Workflow 및 통합 `/inference_pipelines/*` 요청에 API 키를 요구합니다. 클라이언트는 다음 형식으로 키를 보낼 수 있습니다. `Authorization: Bearer YOUR_API_KEY`, `api_key` 쿼리 파라미터 또는 지원되는 JSON 요청 본문으로 보낼 수 있으며, 서버는 Roboflow API를 통해 Workspace 멤버십을 검증합니다. 예를 들어, 다음을 `inference.env` CLI에 전달되는 파일에 넣으세요: ```dotenv WORKSPACES_WHITELISTED_FOR_LOCAL_DEPLOYMENT=your-workspace-url-slug ``` 다른 ID 시스템을 사용하거나 Roboflow API 연결 없이 인증이 필요하다면, 서버 앞에 인증된 프록시를 두고 클라이언트가 이를 우회하지 못하도록 하세요. ### 상태 및 가시성 Workspace 검사는 다음을 제외합니다. `/`, `/docs`, `/redoc`, `/info`, `/healthz`, `/readiness`, `/metrics`, `/openapi.json`정적 자산과 선택적 `/secure-gateway/health` 엔드포인트는 API 키 없이 사용할 수 있습니다. 이렇게 하면 상태 확인과 [원격 측정](/deployment/ko/self-hosted/inference-server/configuration/telemetry.md)을 유지할 수 있습니다. 출력이 민감하다면 네트워크 액세스를 제한하세요. TLS 클라이언트 인증서 요구 사항이 활성화된 경우에도 이 엔드포인트들에는 계속 적용됩니다. ## 신뢰할 수 있는 호출자에게만 Custom Python을 사용 가능하게 유지 `ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS=True` 와 `WORKFLOWS_CUSTOM_PYTHON_EXECUTION_MODE=local` 이 기본값으로 유지되므로, 로컬 사용자는 opt-in 없이 Custom Python을 실행할 수 있습니다. 해당 코드는 서버 프로세스 내에서 그 권한으로 실행됩니다. 인증은 누가 이를 제출할 수 있는지 제어하지만, 인증된 호출자를 샌드박스 처리하지는 않습니다. 로컬 Custom Python이 Workspace 인증 없이 활성화되면 서버는 보안 알림을 기록합니다. ### 필요하지 않을 때는 로컬 실행 비활성화 다음을 설정하세요 `ALLOW_CUSTOM_PYTHON_EXECUTION_IN_WORKFLOWS=False` 로 설정하여 로컬 Custom Python 실행을 거부하세요. Modal 실행은 별도의 모드이며 이 플래그로 비활성화되지 않습니다. 다음을 참조하세요. [Custom Blocks](https://docs.roboflow.com/workflows/blocks/custom-blocks) 및 [오프라인 마이그레이션 안내](/deployment/ko/self-hosted/inference-server/configuration/security-migration.md#offline-custom-python). ## 모델 액세스 보호 [모델 패키지 보안](/deployment/ko/self-hosted/inference-server/configuration/model-security.md) 는 Workspace 인증, 모델별 권한 부여, 그리고 실행 가능한 패키지를 로드할 권한을 구분합니다. 특히, 온라인 모델별 권한 부여는 로컬에서 패키지를 직접 로드하는 것과 결합할 수 없는데, 파일 시스템 경로에는 권한을 부여할 Roboflow 모델 ID가 없기 때문입니다. ## 비디오 워크로드 구성 [비디오 구성](/deployment/ko/self-hosted/inference-server/configuration/video-configuration.md) 는 관리형 파이프라인 프로세스 한도, 웜 워커, 서버 측 미디어 참조를 다룹니다. 프로세스 제한은 자원 사용을 제한할 뿐, 호출자를 인증하거나 그 코드를 격리하지는 않습니다. ## 네트워크 전송 보호 다음을 사용하세요 [HTTPS](/deployment/ko/self-hosted/inference-server/configuration/https.md) 호스트를 넘어서는 트래픽에는 서버 측 또는 인증된 TLS 프록시를 사용하세요. 발신 [Secure Gateway](/deployment/ko/self-hosted/enterprise/secure-gateway.md#connecting-inference-servers) 연결에는 서버의 수신 대기 주소와는 별도의 자체 TLS 구성이 있습니다. ## 이미지 가져오기 제한 호출자가 제공한 이미지 URL은 서버가 내부 서비스나 메타데이터 엔드포인트에 접속하게 만들 수 있습니다. [허용 입력 형식](/deployment/ko/self-hosted/inference-server/configuration/input-formats.md#sending-urls-to-inference-images) 는 URL 입력을 비활성화하는 방법, 목적지를 제한하는 방법, 그리고 애플리케이션에 필요한 형식을 유지하면서 리디렉션을 검증하는 방법을 설명합니다. 이러한 이미지 가져오기 제어는 다른 Workflow 통합이나 비디오 전송에 대한 네트워크 제한을 대체하지 않습니다. ## Webhook Sink 대상 제한 Webhook Sink는 Workflow 데이터를 사설 네트워크상의 서비스로 보낼 수 있습니다. 자체 호스팅 Inference는 기존 공장 및 LAN 웹훅이 계속 작동하도록 기본적으로 이러한 대상을 허용합니다. 다음을 설정하세요 `ALLOW_WEBHOOK_WORKFLOWS_SINK_TO_NON_GLOBAL_ADDRESSES=False` 호출자가 목적지를 선택할 수 있다고 신뢰할 수 없을 때 사용하세요. 이렇게 하면 루프백, 사설, 링크 로컬(클라우드 메타데이터 포함), CGNAT, 예약 및 멀티캐스트 주소가 거부됩니다. Webhook 요청은 호스트명을 한 번 해석한 다음 검증된 주소에 연결합니다. 어느 설정에서도 리디렉션과 HTTP(S) 프록시는 거부됩니다. ## 원격 클라이언트를 허용하기 전에 루프백 이외의 주소에 바인딩하면 신뢰할 수 없는 클라이언트가 서버에 도달할 수 있으며, 이 페이지의 허용적 기본값은 그런 상황을 위해 작성된 것이 아닙니다. 포트를 노출하기 전에 최소한 다음을 수행하세요: * 바인드 주소를 의도적으로 선택하세요: `inference server start` 없이 `--bind-address`, 또는 `-p 127.0.0.1:9001:9001` 을 사용 `docker run`하세요, 원격 클라이언트가 필요한 경우가 아니라면. * 알려진 클라이언트로만 액세스를 제한하세요: 사설 네트워크나 VPC에 머물고, 공개 IP 대신 VPN, SSH 터널 또는 서비스 메시를 통해 서버에 도달하며, 호스트 및 클라우드 방화벽 또는 보안 그룹을 사용해 포트 `9001` 를 필요한 특정 클라이언트에서만 허용하세요. * Workspace 인증 또는 프록시에서 자체 인증을 사용하세요. 그렇지 않으면 포트 `9001` 에 도달할 수 있는 누구나 귀하의 하드웨어와 Roboflow 계정의 할당량으로 모델과 Workflows를 실행할 수 있습니다. * 신뢰할 수 없는 네트워크를 지나는 트래픽에는 TLS를 구성하세요. * 서버의 권한으로 신뢰할 수 있는 호출자에게만 Custom Python과 실행 가능한 모델 패키지를 사용할 수 있게 유지하세요. 도달 가능한 서버에서 그대로 활성화해 두면, 로컬 Custom Python은 Workflow를 보낼 수 있는 누구에게나 원격 코드 실행이 됩니다. * URL 이미지 입력을 비활성화하거나, 다음에서 설명한 대로 대상 허용 목록과 리디렉션 검증으로 강화하세요. [허용 입력 형식](/deployment/ko/self-hosted/inference-server/configuration/input-formats.md#sending-urls-to-inference-images). * 다음을 설정하세요 `ALLOW_WEBHOOK_WORKFLOWS_SINK_TO_NON_GLOBAL_ADDRESSES=False` 호출자가 신뢰할 수 있는 사설 또는 로컬 서비스로 웹훅을 보내야 하는 경우가 아니라면. * 더 넓게 노출해야 한다면 서버 앞에 리버스 프록시(nginx, Traefik, Caddy 또는 클라우드 로드 밸런서)를 두세요. 그러면 TLS, 속도 제한, 액세스 로깅을 추가할 수 있는 단일 지점을 얻을 수 있습니다. * 상태 확인과 메트릭 수집기가 여전히 연결할 수 있는지 확인하세요. 인증과 TLS 없이 추론 포트를 직접 공개 인터넷에 노출하지 마세요. 다음을 사용하세요. [프로덕션 준비 체크리스트](/deployment/ko/production-checklist.md) 재시도, 용량 및 모니터링을 위해.