검증된 접근과 복구 경로로 시작한 다음, 개별 관리, 테스트된 SSH 키, 제한적인 방화벽, 유지 관리되는 소프트웨어 및 독립적인 백업을 구성하십시오. 변경 사항을 점진적으로 적용하고 이전 세션을 닫기 전에 새 세션을 검증하십시오.
신뢰할 수 있는 시작점 설정
머신을 변경하기 전에 예상 운영 체제, 접근 방법 및 복구 경로를 확인하십시오. 예상치 못한 키를 조사 없이 수용하지 말고 운영자의 승인된 정보를 통해 SSH 호스트 신원을 검증하십시오. 임시 자격 증명을 비공개로 유지하고 의도된 프로세스를 통해 교체하십시오. 유지 관리를 담당하는 사람과 이 서비스에 실제로 사용 가능한 복구 옵션을 기록하십시오.
접근 변경을 수행하는 동안 작동하는 관리 세션을 열어 두십시오. 복사한 하드닝 레시피는 다른 배포판이나 계정 레이아웃을 가정할 경우 유일하게 사용 가능한 로그인을 제거할 수 있습니다. 한 번에 하나의 변경을 수행하고, 그 실질적인 결과를 확인하며, 되돌아갈 경로를 보존하십시오. 목표는 엄격해 보이지만 관리할 수 없는 구성이 아니라 안전하게 유지 관리할 수 있는 시스템입니다.
SSH 접근을 의도적으로 만들기
하나의 영구 루트 로그인을 공유하는 대신 적절한 권한을 가진 개별 관리 접근을 생성하십시오. 의도된 공개 키를 설치하고 테스트하며, 개인 키는 승인된 엔드포인트에 보관하십시오. Ubuntu OpenSSH 문서는 서버 구성 및 인증 선택 사항을 설명합니다. 하나의 설정을 편집했다고 해서 전체 서비스가 변경되었다고 가정하기 전에 포함된 파일을 포함하여 배포판의 실제 구성을 읽으십시오.
비밀번호 인증이나 권한 있는 로그인 규칙을 변경하기 전에 두 번째 세션을 통해 키 접근을 테스트하십시오. 새 계정이 필요한 관리를 수행할 수 있는지 확인하십시오. 이전 방법에 의존하는 자동화를 검토하고 그 접근을 의도적으로 교체하십시오. 키는 접근 자격 증명이므로 애플리케이션 디렉터리 내에 복사본을 남겨 두지 말고 비공개 저장 위치와 교체 프로세스를 사용하십시오.
전체 머신이 아닌 애플리케이션 노출
수신 대기 중인 서비스를 목록화하고 어떤 서비스가 공개되어야 하는지 식별하십시오. 웹 애플리케이션은 HTTP 및 HTTPS이 필요할 수 있지만, 해당 데이터베이스는 의도된 내부 경로를 통해서만 접근 가능하게 유지할 수 있습니다. Ubuntu는 UFW를 방화벽 구성 도구로 문서화하지만, 유용한 정책은 도구와 무관합니다. 필요한 트래픽을 허용하고 실용적인 경우 승인된 소스로 관리를 제한하십시오.
서비스에 호스트 수준 및 제공자 수준 제어가 모두 포함된 경우 둘 다 확인하십시오. 제한적인 규칙 집합을 활성화하기 전에 테스트된 관리 경로를 허용하고 다른 세션에서 접근을 검증하십시오. SSH를 다른 포트로 이동하는 것이 인증이나 패치를 대체한다고 가정하지 마십시오. 방화벽 규칙을 이해하기 쉽게 유지하여 향후 문제 해결이 모든 포트를 여는 우회 방법으로 이어지지 않도록 하십시오.
| 변경 | 적용 전 확인 | 이후 확인 |
|---|---|---|
| 새 SSH 키 | 올바른 계정 및 공개 키 | 두 번째 키 인증 세션 작동 |
| 제한된 방화벽 | 필수 서비스 및 복구 경로 | 공개 앱 작동; 의도하지 않은 포트 닫힘 |
| 소프트웨어 업데이트 | 백업 및 재시작 영향 | 서비스 재시작 및 애플리케이션 테스트 통과 |
| 서비스 권한 변경 | 필수 읽기 및 쓰기 경로 | 더 넓은 시스템 접근 없이 앱 작동 |
업데이트를 운영 프로세스로 계획
시스템과 애플리케이션 종속성을 유지 관리하십시오. Ubuntu의 자동 업데이트 지침은 무인 업그레이드, 허용된 출처 및 재시작 동작을 설명합니다. 타사 저장소는 머신에 추가되었다는 이유만으로 자동으로 포함되지 않습니다. 구성된 업데이트 프로세스가 실제로 포함하는 내용을 검토하고 별도로 설치된 애플리케이션에 자체 유지 관리 경로를 제공하십시오.
서비스 재시작 및 재부팅이 어떻게 처리될지 결정하십시오. 패키지 업데이트를 적용한다고 해서 항상 모든 실행 중인 프로세스가 새 코드를 사용하는 것은 아닙니다. 워크로드에 필요한 경우 유지 관리 기간을 사용하고 이후 간단한 애플리케이션 검사를 수행하십시오. 패키지에 수동 마이그레이션 단계가 필요한 경우 모든 업데이트를 무기한 비활성화하고 그로 인한 노출을 잊어버리는 대신 이를 문서화하십시오.
애플리케이션 접근 제한 및 복구 보호
서비스를 필요한 권한으로 실행하고 공개 콘텐츠를 비밀 및 배포 메타데이터와 분리하십시오. 웹 프로세스가 모든 시스템 설정을 다시 작성할 수 있어서는 안 됩니다. 환경 비밀을 공개적으로 제공되는 디렉터리 외부에 보관하고 의도적인 보호 정책 없이 로그, 지원 내보내기 또는 일반 백업에 포함하지 마십시오. 운영 목적이 없는 사용하지 않는 패키지와 서비스를 제거하십시오.
독립적인 백업을 유지하고 격리된 환경으로 애플리케이션 복원을 테스트하십시오. 침해된 애플리케이션이 모든 복구 복사본을 자동으로 삭제할 수 없도록 백업 자격 증명을 제한하십시오. 디스크 용량, 백업 경과 시간 및 서비스 장애를 모니터링하십시오. 로깅은 정의된 운영 질문에 답해야 하며 접근과 보존이 통제되어야 합니다. 민감한 요청의 무제한 복사본이 되어서는 안 됩니다.
검토 가능한 상태로 유지되는 첫 배포 순서
새 VPS의 경우 먼저 접근과 복구를 검증한 다음 관리 계정과 테스트된 키를 설정하십시오. 방화벽을 구성하고 업데이트를 적용하며 의도된 서비스 계정으로 애플리케이션을 배포하십시오. 다른 환경에서 공개 동작을 확인하고 비공개 파일을 검색할 수 없는지 확인하며 백업 복원을 수행하십시오. 각 결정과 접근 변경을 되돌리는 경로에 대한 메모를 유지하십시오.
Vector VPS, Pulse NVMe 및 선택된 전용 요금제는 SwissOctet 카탈로그에서 Linux 선택 사항을 제공합니다. 주문 전에 선택한 이미지와 유지 관리 작업의 분담을 확인하십시오. 어떤 Linux 이미지 이름도 하드닝, 업데이트 또는 백업이 이미 관리되고 있음을 증명하지 않습니다. 기준은 프로젝트가 변경됨에 따라 구성, 검증 및 지속적으로 유지 관리하는 제어 집합입니다.
실용 체크리스트.
- SSH 호스트 신원 및 복구 경로를 검증하십시오.
- 두 번째 세션에서 개별 키 접근을 테스트하십시오.
- 수신 대기 서비스 및 방화벽 규칙을 제한하십시오.
- 업데이트 범위 및 재시작 동작을 검토하십시오.
- 비밀을 공개 파일 및 서비스 권한과 분리하십시오.
- 독립적인 복구 복사본을 테스트하십시오.
중요한 세부 사항.
비밀번호 로그인을 즉시 비활성화해야 하나요?+
먼저 대체 키 접근과 복구 경로를 설정하고 테스트하십시오. 그런 다음 지원되는 구성에 따라 인증을 변경하십시오.
SSH 포트 변경이 하드닝을 대체하나요?+
아니요. 강력한 인증, 제한된 접근, 업데이트 또는 적절한 계정 권한을 대체하지 않습니다.
자동 업데이트가 모든 애플리케이션에 충분한가요?+
아니요. 허용된 저장소, 재시작 요구 사항 및 시스템 업데이트 프로세스 외부에 설치된 소프트웨어를 확인하십시오.
출처로 이동하세요.
이 참고 자료는 이 가이드의 기술 개념을 뒷받침합니다. 프로덕션 시스템을 변경하기 전에 최신 문서를 확인하세요.
- Ubuntu 서버: OpenSSH 서버 ubuntu.com
- Ubuntu 서버: 방화벽 ubuntu.com
- Ubuntu 서버: 자동 업데이트 ubuntu.com
SwissOctet의 편집 지침. 예시는 설명용입니다. 서비스 사양, 사용 가능한 옵션 및 계약 조건은 별도로 확인해야 합니다.