--- canonical: https://koalavps.com/ko/guides-vps-hardening-first-hour-opsec/ language: ko generated: 2026-10-21T13:33:06.195Z --- [홈](https://koalavps.com/ko/) / [탐색](https://koalavps.com/ko/resources/) / KoalaVPS 필드 노트 KoalaVPS 필드 노트 # 첫 한 시간: 더 작은 공격 표면. 신중한 첫 세션은 잠금 없이 접근, 업데이트, 복구를 확립합니다. [VPS 찾기](https://koalavps.com/ko/vps/) ## 이 문서에서 [액세스 확인 및 보존](https://koalavps.com/ko/guides-vps-hardening-first-hour-opsec/#section-1)[패치하고 노출을 줄이세요](https://koalavps.com/ko/guides-vps-hardening-first-hour-opsec/#section-2)[사용자와 비밀 분리](https://koalavps.com/ko/guides-vps-hardening-first-hour-opsec/#section-3)[작동하는 복구 경로를 남겨두세요](https://koalavps.com/ko/guides-vps-hardening-first-hour-opsec/#section-4)[세션을 닫기 전에 확인하세요](https://koalavps.com/ko/guides-vps-hardening-first-hour-opsec/#section-5)[첫날 확인 목록](https://koalavps.com/ko/guides-vps-hardening-first-hour-opsec/#section-6)[액세스 변경을 되돌릴 수 있는 순서로 진행](https://koalavps.com/ko/guides-vps-hardening-first-hour-opsec/#section-7)[호스트 외부에서 방화벽을 입증하세요](https://koalavps.com/ko/guides-vps-hardening-first-hour-opsec/#section-8)[지식 베이스](https://koalavps.com/ko/resources/) ## 액세스 확인 및 보존 신뢰할 수 있는 채널을 통해 서버 신원을 확인하고 SSH 공개 키를 추가하세요. 이름이 지정된 관리자 사용자를 생성하세요. 새 세션을 테스트하는 동안 원래 세션을 열어 두고 인증을 변경하기 전에 복구 방법을 기록하세요. ## 패치하고 노출을 줄이세요 지원되는 보안 업데이트를 설치하고 필요하면 재부팅하세요. 수신 대기 중인 서비스를 검토하고 방화벽에서 필요한 포트만 허용하세요(IPv6 포함). 사용하지 않는 데몬을 제거하고, 설정을 쉽게 하려는 이유만으로 데이터베이스를 공개적으로 열지 마세요. ## 사용자와 비밀 분리 애플리케이션을 자체 계정으로 실행하세요. 비공개 구성을 공개 웹 디렉터리 밖에 두고 버전 관리에서 제외하세요. 좁은 데이터베이스 권한을 사용하고 운영 환경과 실험 환경에 별도 자격 증명을 사용하세요. ## 작동하는 복구 경로를 남겨두세요 로그 로테이션, 디스크 알림 및 별도 백업을 설정하세요. 한 번 재부팅하여 애플리케이션이 올바르게 시작되는지 확인하세요. 변경 사항을 기록하여 깨끗한 이미지에서 구성을 재구축할 수 있도록 하세요. ## 세션을 닫기 전에 확인하세요 새 계정으로 두 번째 연결을 열고, 관리자 권한 상승을 확인하고, 다른 클라이언트에서 방화벽을 테스트하세요. 재부팅 후 서비스가 복구되는지 확인하세요. 잘못된 네트워크 규칙 때문에 임기응변 복구가 필요하지 않도록 제공업체 복구 경로를 문서화해 두세요. ## 첫날 확인 목록 열린 소켓, 최근 인증 이벤트, 업데이트 상태, 백업 경과 시간 및 디스크 사용량을 확인하세요. 비공개 구성 및 버전 관리 메타데이터를 HTTP을(를) 통해 가져올 수 없는지 확인하세요. 실제 워크로드를 지원하는 최소한의 설치 도구 집합을 사용하세요. ``` ss -lntup df -h free -h systemctl --failed ``` ## 액세스 변경을 되돌릴 수 있는 순서로 진행 먼저 콘솔 또는 구조 경로를 확인하고 신뢰할 수 있는 제공업체 채널을 통해 SSH 호스트 키를 검증하세요. 지정된 관리자의 공개 키를 설치한 다음 두 번째 연결을 열어 권한 상승을 테스트하세요. 서비스를 다시 로드하기 전에 SSH 구성 구문을 검증하세요. 의도한 SSH 경로가 허용된 후에만 방화벽 변경을 적용하세요. 필요한 2차 인증 흐름을 포함하여 새 세션에서 대체 수단이 작동한 후에 기존 인증 방법을 비활성화하세요. - 적용 중인 구성과 포함된 스니펫을 검사하세요. 한 파일의 설정이 최종 정책이 아닐 수 있습니다. - 키 기반 로그인 설계를 검토할 때 비밀번호 인증과 키보드 대화형 정책을 모두 확인하세요. - 기본값이 아닌 SSH 포트는 백그라운드 노이즈를 줄일 수 있지만 검증된 키, 접근 제한 또는 업데이트를 대체하지는 않습니다. - 배포판에 맞는 서비스 이름과 재로드 절차를 사용하세요. 새 정책이 검증될 때까지 원래 세션을 유지하세요. ``` # Validate before applying a changed SSH configuration. sudo /usr/sbin/sshd -t # Read effective settings; adapt user, host and client address to the test. sudo /usr/sbin/sshd -T -C user=admin,host=server.example,addr=198.51.100.10 ``` 공식 문서: [OpenSSH: 서버 구성 매뉴얼](https://man.openbsd.org/sshd_config) ## 호스트 외부에서 방화벽을 입증하세요 제공업체 네트워크 방화벽과 게스트 방화벽을 별도의 제어로 검토하세요. 다른 승인된 머신에서 IPv4 및 IPv6을 통해 의도한 서비스를 테스트하세요. 로컬 연결은 프로세스가 수신 중이라는 것만 증명합니다. 모든 ICMP 패킷을 무작정 거부하지 마세요. 정상적인 네트워크 운영에도 적절한 제어 트래픽이 필요합니다. 애플리케이션 노출이 방화벽 프런트 엔드가 적용했다고 생각한 정책과 일치하지 않을 수 있으므로 컨테이너가 게시한 포트를 실제 규칙과 대조하여 확인하세요. - SSH이(가) 실패하면 키를 반복해서 변경하기 전에 소스 주소 제한, 수신 인터페이스 및 제공업체 방화벽을 점검하세요. - HTTPS가 실패하면 DNS, 프로세스 리스너, 로컬/프록시 방화벽 순으로 확인하세요. - 첫 프로덕션 데이터셋 이전에 업데이트 상태, 정상 재부팅, 디스크 경고 및 독립적으로 복원 가능한 백업을 확인하세요. - 문서화된 시간대를 설정하고 시간 동기화를 확인하세요. 워크로드의 메모리 및 보존 요구를 확인하지 않고 임의의 스왑이나 로깅 설정을 추가하지 마세요. 공식 문서: [Ubuntu 서버: 방화벽 관리](https://ubuntu.com/server/docs/how-to/security/firewalls/) 계속 탐색하기 ## 계속 읽기. [가이드 ### 깨끗한 이미지에서 유용한 서버까지. 합리적인 초기 설정은 향후 유지 관리를 덜 부담스럽게 만듭니다. 결정 사항을 기록하고 현재 세션을 닫기 전에 각 접근 변경 사항을 테스트하세요.…](https://koalavps.com/ko/first-server/)[가이드 ### 머신을 직접 소유하세요. 보안은 지속적인 일상입니다. 노출 표면을 줄이고, 권한을 제한하고, 신중하게 패치하며, 복구가 가능하도록 만드세요.…](https://koalavps.com/ko/server-security/)[가이드 ### 백업은 복구될 때 의미가 있습니다. 재생성할 수 없는 데이터와 서비스가 손실을 감당할 수 있는 시간을 기준으로 백업을 설계하세요. 성공적인 업로드는 시작에 불과합니다.…](https://koalavps.com/ko/backups/) 인프라를 구성하세요 ## 직접 통제하세요. 원하는 방식으로 배포하세요. 신원 서류 없음. 전체 관리자 액세스. 암호화폐 기반 결제. [구성을 선택하세요](https://koalavps.com/ko/vps/)