서버를 보호하기 위한 강력한 보안 조치를 구축하는 방법

소개

클라우드 인프라를 작업할 때 가장 먼저 고려해야 할 사항은 애플리케이션이 완전히 작동하는지 확인하는 것입니다. 설정 및 배포 프로세스에서 중요한 부분 중 하나는 앱이나 시스템을 대중에게 제공하기 전에 효과적이고 철저하며 강력한 보안 조치를 구축하는 것입니다. 배포 후에 소급하여 보안 조치를 구현하는 대신, 인프라에 안전한 기본 구성이 구축되어 있는지 확인하는 것이 중요합니다.

이 튜토리얼은 이와 관련하여 도움을 줄 것입니다. 서버의 인프라를 설정하고 구성하는 동안 구현할 수 있는 몇 가지 실질적인 보안 조치를 강조합니다. 이것이 서버 보안 프로토콜의 완전한 목록은 아니지만, 유용한 시작점입니다. 환경과 애플리케이션의 구체적인 요구 사항을 파악하고 더 잘 이해하게 됨에 따라, 기본 구성을 보완할 수 있는 추가적인 보안 조치를 개발할 수 있습니다.

SSH (Secure Shell) 키

서버로 작업하는 동안 대부분의 시간은 터미널 세션에서 서버와의 SSH 연결을 통해 작업하는 데 소요됩니다. 보안 셸(SSH) 키는 비밀번호에 의존하는 로그인보다 서버에 더 안전한 로그인 방법을 제공합니다. 인증을 위해 SSH 키를 사용하면 두 개의 액세스 키가 준비됩니다. 첫 번째는 비밀(개인) 키이고 다른 하나는 공유 가능한 공개 키입니다.

먼저 SSH 키 인증을 구성해야 합니다. 이는 서버의 적절한 디렉토리에 SSH 공개 키를 배치함으로써 수행됩니다. 클라이언트가 처음에 서버에 연결할 때 개인 키를 소유하고 있다는 증명을 요구받게 됩니다. 이는 무작위 값을 생성하여 SSH 클라이언트로 전송함으로써 이루어집니다. 그러면 SSH 클라이언트는 응답을 암호화하는 데 개인 키를 사용합니다. 이 응답은 서버로 전송됩니다. 다음으로, 서버는 공개 키를 사용하여 클라이언트로부터 받은 메시지를 복호화합니다. 무작위 값이 서버에 의해 복호화되면 클라이언트가 개인 키를 가지고 있음을 나타냅니다. 이 경우 인증이 확인되고 비밀번호 없이 서버에 연결할 수 있습니다.

SSH 키로 보안 강화하기

비밀번호 인증이나 SSH를 통한 모든 인증은 완전히 암호화되지만, 악의적인 사용자가 서버 액세스를 시도할 수 있습니다. 특히 서버의 외부 공개 IP 주소를 알아낸 경우에 그렇습니다. 현대의 컴퓨팅 기술은 가능한 모든 키 조합을 시도하여 비밀번호 기반 로그인을 허용하므로, 악의적인 사용자들이 자주 시도합니다. 이러한 액세스 시도를 자동화하면, 체계적으로 다양한 조합을 시도하여 결국 올바른 비밀번호에 도달하는 것이 가능합니다.

SSH 암호화 인증을 활용하면 로그인을 위해 비밀번호를 활성화할 필요가 없습니다. SSH 키는 일반적으로 공격자가 시도해야 하는 엄청난 수의 조합 가능성을 포함하고 있습니다. 비트 수가 증가하면 암호화를 해독하는 데 필요한 다양한 조합의 가능성이 기하급수적으로 늘어납니다. 따라서 SSH 키 알고리즘의 가능한 모든 조합을 실행하는 것은 엄청난 시간이 소요됩니다. 결과적으로 악의적인 공격자에게 시간 낭비가 되는 일이 됩니다. 이것이 바로 SSH 암호화가 일반적으로 '해독 불가능'한 것으로 간주되는 이유입니다.

SSH 키 구현하기

원격 Linux 서버에 로그인할 때는 SSH 키를 사용해야 합니다. 로컬 머신 측에서 키를 생성하고 몇 분 안에 공개 키를 서버로 전송할 수 있습니다. 이 튜토리얼을 통해 다음에 대한 기본적인 개념을 얻을 수 있습니다: Ubuntu에서 SSH를 사용하여 원격 서버에 연결하는 방법. 또한 다음의 심층 Linux 서버에서 SSH 키 기반 인증을 사용하도록 구성하는 방법에 대한 튜토리얼.

전반적으로, root 사용자가 SSH를 통해 직접 로그인하는 것을 허용하지 않는 것은 일반적으로 활용되는 모범 사례이며, 대신 권한이 없는 사용자로 로그인하고 필요에 따라 권한을 에스컬레이션하기 위해 sudo와 같은 도구를 사용하는 것이 좋습니다. 이를 최소 권한의 원칙(접근 권한을 제한하는 방법)이라고 합니다. 권한이 없는 계정으로의 로그인이 SSH로 확인되면, 서버의 /etc/ssh/sshd_config에서 PermitRootLogin no 지시어를 설정하여 root 로그인을 비활성화할 수 있습니다. 그런 다음, SSH 프로세스 명령인 sudo systemctl restart sshd를 사용하여 서버를 재시작할 수 있습니다.

방화벽

네트워크에 대한 서비스 노출을 규제하는 소프트웨어(또는 하드웨어 장치)를 방화벽이라고 합니다. 최적으로 구성된 방화벽은 허용된 서비스만 공개적으로 이용 가능하고 특정 서버로 들어오고 나가는 것이 허용되도록 보장합니다.

서버에서 기본적으로 여러 서비스가 실행 중일 수 있으며, 이는 다음과 같은 그룹으로 분류할 수 있습니다:

• 내부 서비스: 이는 서버 자체에서 내부적으로만 액세스해야 합니다. 이를 통해 공개적으로 사용 가능한 인터넷 접속으로부터 서비스가 노출되는 것을 방지합니다(예: 로컬 연결을 통해서만 액세스할 수 있는 데이터베이스).
• 공용 서비스: 인터넷에서 누구나(종종 익명으로) 액세스할 수 있는 서비스입니다. 여기에는 방문자가 귀하의 사이트에 액세스할 수 있도록 허용하는 웹 서버가 포함됩니다.
• 사설 서비스: 독점적인 위치 세트의 승인된 계정만 이러한 서비스에 액세스할 수 있습니다(예: phpMyAdmin 데이터베이스 제어판).

공용 서비스는 인터넷에서 액세스할 수 있도록 열어둘 수 있는 반면, 사설 서비스는 액세스 매개변수(예: 연결 유형)에 따라 제한할 수 있으며, 내부 서비스는 인터넷 기반 액세스가 완전히 차단됩니다. 이러한 서비스에 대한 액세스와 허용되는 세분성은 모두 방화벽에 의해 제어됩니다. 사용하지 않는 포트는 일반적으로 액세스를 완전히 차단하도록 구성됩니다.

방화벽 사용을 통한 보안 강화

방화벽은 서버 보호의 기본입니다. 이는 애플리케이션이 트래픽을 처리하기 전에 서비스로의 연결 및 서비스로부터의 연결을 제한하는 역할을 합니다. 물론 서비스에 대한 추가 보안 기능을 구현하고 원하는 인터페이스로 제한할 수 있습니다.

올바르게 구성된 방화벽은 열어두기로 선택한 서비스만 제한하지 않습니다. 이를 통해 사용 가능한 소프트웨어가 훨씬 더 제한되므로 취약한 요소가 제한되고 결과적으로 공격을 받을 가능성이 줄어듭니다.

방화벽 구현

Linux 시스템에서 사용할 수 있는 방화벽은 많습니다. 이 중 일부는 상당히 복잡합니다. 하지만 일반적인 방화벽 설정은 서버의 초기 설정 시 또는 서버의 서비스 변경 사항이 구현될 때만 수행하면 됩니다. 이 작업은 몇 분 밖에 걸리지 않습니다. 다음은 방화벽을 설정하고 활성화하기 위해 고려해야 할 몇 가지 옵션입니다:

• CentOS의 경우, 당사의 CentOS 7에서 FirewallD로 방화벽 설정하기 가이드.
• 당사의 Iptables 가이드는 Iptables 방화벽 규칙을 나열하고 삭제하는 방법을 안내합니다.

가장 중요한 것은, 튜토리얼에 관계없이 새로 사용 가능한 서비스가 의도치 않게 인터넷에 노출되는 것을 방지하기 위해 선택한 방화벽이 서버의 알 수 없는 트래픽을 차단하는지 확인해야 한다는 점입니다. 액세스를 명시적으로 승인해야 하므로 서비스가 어떻게 액세스되고 실행되는지, 그리고 누구에게 액세스가 허용되는지 완전히 평가하도록 유도됩니다.

가상 사설 클라우드(VPC) 네트워크

귀하의 인프라’의 리소스는 VPC라고 알려진 사설 네트워크 내에서 작동해야 합니다. 이러한 네트워크는 다른 클라우드 기반 VPC 네트워크로부터의 액세스를 방지하므로 더 안전합니다. 따라서 네트워크의 인터페이스를 공용 인터넷에서 액세스할 수 없게 만듭니다.

VPC 네트워크를 통한 보안 강화

내부 통신에는 공용 네트워크보다 사설 네트워크가 더 바람직합니다. VPC를 사용하면 리소스 그룹을 특정 사설 네트워크로 격리할 수 있습니다. VPC 네트워크는 사설 연결을 통해서만 인터페이스하므로, 네트워크’ 트래픽이 공용 인터넷에 노출되는 것을 방지하여 정보가 가로채기나 노출에 취약해질 수 있는 위험을 막아줍니다. VPC 네트워크는 테넌트뿐만 아니라 실행 환경을 격리하는 데도 사용할 수 있습니다. 인터넷 게이트웨이를 공용 인터넷과 VPC 네트워크의 리소스 간의 단일 액세스 지점으로 설정할 수도 있습니다.

또한, 보안의 큰 부분은 시스템을 분석하고 모든 구성 요소를 능력이 닿는 한 안전하게 보호하는 것을 수반합니다. 서비스 감사를 통해 시스템’ 허용 프로토콜, 실행 중인 서비스, 통신에 사용되는 포트를 파악할 수 있습니다. 이 정보를 알면 구성과 관련하여 최선의 결정을 내리는 데 도움이 될 수 있습니다. 이러한 결정에는 방화벽 설정, 시스템 모니터링 및 알림, 공개적으로 액세스할 수 있어야 하는 서비스 등이 포함될 수 있습니다.

보안 강화를 위한 감사 활용

각 서비스는 외부 클라이언트를 처리하거나 내부적인 목적으로 활용될 수 있습니다. 의도와 상관없이 이러한 서비스는 모두 악의적인 사용자에게 취약점이 됩니다. 실행 중인 서비스의 수가 증가함에 따라 취약점 악용 가능성도 커집니다.

머신이 어떤 서비스를 실행하고 있는지 확실히 파악하고 나면 서비스 분석을 시작할 수 있습니다. 서비스 감사를 실행할 때 다음과 같은 질문을 던지는 것이 유익합니다:

• 특정 서비스가 활발히 실행 중이어야 합니까?
• 최적의 네트워크 인터페이스에서 실행되고 있습니까?
• 해당 서비스가 공용 또는 사설 네트워크 인터페이스에 가장 적합합니까?
• 이 서비스로의 정당한 트래픽을 허용하도록 방화벽 규칙이 올바르게 구성되어 있습니까?
• 내 방화벽 규칙으로 불법 트래픽이 차단됩니까?
• 보안 취약점에 대한 알림 시스템이 활성화되어 있습니까?

인프라에 새 서버를 추가할 때 위의 사항은 구성 프로세스의 표준 관행이어야 합니다. 서비스 감사의 추가적인 이점은 의도치 않게 변경된 구성을 식별할 수 있다는 것입니다.

서비스 감사 수행

실행 중인 서비스를 감사하려면 ss 명령을 사용하여 서버에서 활발히 사용되는 모든 UDP 및 TCP 포트를 나열하십시오. 다음은 프로그램 이름 PID와 함께 ss 명령을 사용하여 수신 대기 중인 TCP 및 UDP 포트를 확인하는 예입니다:

다음과 유사한 내용이 반환됩니다:

주로 Netid, Local Address:Port 및 Process 열에 집중해야 합니다:

• Local Address:Port 값이 0.0.0.0이면 서비스가 모든 IPv4 네트워크 인터페이스에서 모든 연결을 활발히 수락하고 있음을 의미합니다. 주소가 [::]이면 모든 IPv6 연결이 트래픽을 수락하고 있는 것입니다.
• 위의 예에서 Nginx와 SSH는 모두 두 네트워킹 스택(IPv4 및 IPv6)의 모든 공용 인터페이스에서 수신 대기 중입니다.

위의 예를 통해 SSH와 Nginx가 두 인터페이스 모두에서 수신 대기하도록 허용할지, 아니면 둘 중 하나에서만 허용할지 선택할 수 있습니다. 일반적으로 사용하지 않는 서비스는 실행되지 않도록 비활성화하는 것이 좋습니다. 예를 들어, 사이트가 IPv4를 통해서만 접속 가능해야 하는 경우, 노출을 제한하기 위해 IPv6 인터페이스를 끄는 것이 도움이 됩니다.

무인 업데이트로 최신 상태 유지하기

무인 업데이트는 서버를 안전하게 유지하는 데 필요한 노력의 수준을 낮추고 알려진 버그에 노출되는 시간을 줄이는 데 도움이 됩니다. 서버에서 업데이트를 실행하는 데 시간이 오래 걸릴수록 알려진 취약점에 노출되는 시간도 길어집니다. 무인 업데이트를 사용하면 수정 패키지가 제공되는 즉시 서버에 자동으로 설치되어 취약점 노출 시간을 제한할 수 있습니다.

서버 감사 외에도 무인 업데이트는 공격에 대한 노출을 크게 줄일 수 있습니다. 또한 서버 유지 관리에 소요되는 시간도 크게 줄여줍니다.

무인 업데이트가 활성화되는 방법

무인 업데이트는 이제 대부분의 서버 배포판에서 선택적 기능입니다. 예를 들어 Ubuntu에서는 관리자가 다음 명령을 실행할 수 있습니다:

무인 업데이트 구현에 대한 추가 정보는 다음을 참조하십시오: 여기의 자동 업데이트 섹션. Fedora의 경우, 지침은 여기에서 찾을 수 있습니다. 자동 업데이트는 시스템 패키지 관리 시스템을 통해 처음에 설치된 소프트웨어만 설치한다는 점에 유의하십시오. 웹 기반 애플리케이션과 같은 추가 애플리케이션은 수동으로 업데이트를 별도로 확인하거나 자동 업데이트를 위해 개별적으로 구성해야 합니다.

디렉토리 인덱스

디렉토리에 인덱스 파일이 없는 경우, 대부분의 서버는 기본적으로 디렉토리 인덱스를 표시하도록 구성되어 있습니다. 즉, 웹 서버에 'downloads'라는 디렉토리가 생성된 경우 해당 디렉토리를 탐색하는 모든 사람이 그 안의 모든 파일을 볼 수 있습니다. 이것이 항상 보안 위험은 아니지만, 권한이 없는 사람들에게 기밀 정보가 노출될 수 있습니다. 예를 들어, 웹 서버에 웹사이트 홈페이지 접속 자격 증명이 포함된 파일과 사이트 데이터베이스 백엔드에 대한 모든 구성이 포함된 파일이 있을 수 있습니다. 디렉토리 인덱스를 비활성화하지 않으면 해당 디렉토리를 탐색하는 모든 사람에게 이 파일들이 노출됩니다.

디렉토리 인덱스 비활성화를 통한 보안 강화

디렉토리 인덱스는 유용하지만, 의도치 않게 파일이 노출될 수 있습니다. 이러한 의도치 않은 노출 및 관련 위험을 완화하려면 서버의 디렉토리 인덱스를 기본적으로 비활성화해야 합니다. 방문자가 파일에 계속 액세스할 수는 있지만, 의도치 않은 데이터 조회에 노출되는 것은 크게 제한됩니다.

디렉토리 인덱스 비활성화

대부분의 경우 웹 서버 구성에 한 줄만 추가하면 디렉토리 인덱스를 비활성화할 수 있습니다.

• 다음 Apache Wiki에서 이러한 디렉토리 목록을 비활성화하는 단계를 따르십시오. Apache Directory 구성 블록에 Options -Indexes가 나열되어 있는지 확인하십시오.
• Nginx에서는 인덱스가 기본적으로 비활성화되어 있으므로 이와 관련하여 추가 조치가 필요하지 않습니다.

빈번한 백업

백업은 보안 조치는 아니지만, 시스템이 침해당했을 때 데이터와 전체 시스템을 보호하는 데 필수적입니다. 또한 시스템이 어떻게 공격을 받게 되었는지 분석하는 데 도움이 됩니다. 시스템이 랜섬웨어(시스템의 파일을 암호화하고 해커에게 돈을 지불해야만 복호화해 주는 바이러스 또는 악성코드 도구)의 공격을 받는 불행한 시나리오를 생각해 보십시오. 데이터 백업이 없다면 데이터에 다시 액세스하기 위해 돈을 지불하는 것 외에는 선택의 여지가 없습니다. 데이터를 안전하게 백업해 두면 침해된 시스템에 액세스할 필요 없이 데이터에 계속 액세스하고 복구할 수 있습니다.

빈번한 백업을 통한 보안 강화

빈번한 백업은 공격, 손상 또는 의도치 않은 손실(삭제)로 인한 정보를 복구하는 데 도움이 됩니다. 데이터 손실을 초래하는 부정적인 이벤트의 유형에 관계없이, 서버 데이터의 복사본을 보유함으로써 위험을 줄일 수 있습니다.

랜섬웨어 공격 외에도 빈번한 백업은 장기적인 시스템 공격에 대한 측정 가능한 조사에 도움이 될 수 있습니다. 데이터를 백업 형태로 안전하게 보관하지 않으면 공격의 근원과 어떤 데이터가 침해되었는지 파악하는 것이 어렵거나 불가능할 수 있습니다.

빈번한 백업 구현

시스템을 백업할 때 손상, 침해 또는 삭제된 데이터의 검증 가능한 복구를 복구 노력의 목표로 삼는 것이 가장 중요합니다. 가장 잘 표현하자면, 내일 서버가 사라졌을 때 다시 가동하고 실행하는 데 가장 적은 작업이 필요한 조치가 무엇인지 생각해 보십시오.

재해 복구 계획을 생각할 때 고려해야 할 몇 가지 다른 사항은 다음과 같습니다:

• 동적으로 변경되는 데이터로 작업하는 경우 백업을 더 자주 수행해야 할 가능성이 높습니다. 데이터 손실이 발생했을 때 마지막 백업이 너무 오래전 일이라면 오래된 데이터로 되돌아가야 할 수도 있습니다.
• 실제 백업 복구 프로세스에 대해 생각해 보세요. 이를 위해 새 서버를 추가해야 합니까, 아니면 기존 서버를 복구할 수 있습니까?
• 서버가 작동하지 않아도 감당할 수 있는 가장 긴 기간은 어느 정도입니까?
• 오프사이트 백업이 필수적인 솔루션입니까?

CloudSigma의 재해 복구(Disaster Recovery) 솔루션에 대해 자세히 알아보려면 다음 내용을 상세히 다룬 블로그 게시물을 확인해 보세요. 당사의 서비스형 재해 복구(Disaster-Recovery-as-a-Service)가 클라우드의 완벽한 동반자인 이유. 그리고 여기에서 다음에 대해 더 자세히 알아볼 수 있습니다. CloudSigma의 보안 & 비즈니스 연속성 기능. 또한 다음에 대한 자세한 가이드도 준비되어 있습니다. CloudSigma의 백업 기능을 쉽게 설정하는 방법.

사설 네트워킹 및 VPN

사설 네트워크는 특정 사용자나 서버만 액세스하고 사용할 수 있는 네트워크입니다. 원격 장치 간의 안전한 연결을 통해 마치 사설 네트워크에 있는 것처럼 작동할 수 있도록 하는 연결을 VPN(가상 사설망)이라고 합니다. 이는 사설 네트워크에서 연결을 보호하고 원격 서버를 연결할 수 있는 기능을 제공합니다.

사설 네트워크는 어떻게 보안을 강화합니까?

내부 통신을 위해 공용 네트워크와 사설 네트워크 중 하나를 선택해야 할 때, 항상 후자가 더 바람직한 옵션입니다. 하지만 데이터 센터 내의 다른 사용자도 여전히 동일한 네트워크에 액세스할 수 있다는 점을 명심해야 합니다. 즉, 서버 간의 통신이 안전하도록 보장하기 위해 추가적인 보안 조치를 여전히 적용해야 합니다.

기본적으로 VPN을 활용하는 것은 조직의 직원이 볼 수 있는 범위를 규정하는 접근 방식입니다. 통신은 완전히 안전하고 비공개로 유지됩니다. 애플리케이션 구성은 가상 인터페이스 트래픽이 VPN을 통과하도록 허용합니다. 이렇게 함으로써 인터넷을 통한 클라이언트 상호 작용을 목적으로 하는 서비스만 공용 네트워크에 노출되도록 허용됩니다.

VPN을 구현하는 것은 얼마나 어렵습니까?

사설 네트워크를 활용하는 것은 애플리케이션과 방화벽이 사설 네트워크를 사용하도록 구성하고 서버 생성 중에 VPN을 활성화하는 것만큼 데이터 센터에서 간단하게 수행할 수 있습니다. 다른 서버도 센터 전체 사설 네트워크와 동일한 네트워크 공간을 공유한다는 점을 기억하는 것이 중요합니다.

VPN의 초기 설정은 약간 더 복잡합니다. 하지만 이를 통해 추가되는 보안은 대부분의 사용 사례에서 그만한 가치가 있습니다. 네트워크의 각 서버에 구성 데이터와 공유 보안을 설치하고 구성해야 합니다. 다음에 대한 더 자세한 정보는 VPN의 작동 방식 및 Ubuntu에서 OpenVPN을 설정하는 방법 개요는 이 가이드를 참조하세요. 또한 다음 단계를 안내하는 이 튜토리얼을 따를 수도 있습니다. VPN 네트워크를 CloudSigma 인프라에 연결하는 단계.

SSL/TLS 암호화 및 공개 키 기반 구조(PKI)

개인을 식별하고 통신을 암호화하기 위한 인증서의 생성, 관리 및 검증을 공개 키 기반 구조(PKI)라고 합니다. 서로 다른 엔티티는 SSL 또는 TLS 인증서를 사용하여 서로를 인증할 수 있습니다. 그 후, 암호화된 통신을 설정하는 데에도 사용할 수 있습니다.

인증서가 보안을 강화하는 방법

서버에서 트래픽을 암호화하고 구성원 신원을 확인하려면 인증 기관(CA)을 설립하고 네트워크의 모든 인증서를 볼 수 있어야 합니다. 이는 해커가 서버를 사칭하여 트래픽을 다른 곳으로 리디렉션하는 '중간자(man-in-the-middle)' 공격을 방지하는 데 도움이 될 수 있습니다.

각 서버의 구성은 중앙 집중식 CA를 신뢰하도록 설정할 수 있습니다. 그러면 이후의 모든 인증서 서명을 암묵적으로 신뢰할 수 있습니다. If SSL/TLS encryption is supported by the protocols and apps your server uses, you can secure your system without the VPN tunnel overhead. 자세한 내용은 당사의 Nginx용 LetsEncrypt SSL 인증서 갱신을 자동화하는 방법에 대한 튜토리얼.

구현 난이도

인증 기관을 구성한 다음 나머지 PKI를 설정하는 데 많은 초기 노력이 필요할 수 있습니다. 또한 새로운 인증서를 생성, 폐기 또는 서명해야 할 때 추가적인 관리 노력이 필요합니다.

대부분의 인프라는 확장되어야 하므로, 본격적인 PKO를 구현하는 것이 가장 합리적인 접근 방식입니다. PKI가 추가 관리 비용을 감당할 가치가 있는 시점에 도달할 때까지는, VPN을 활용하여 시스템 구성 요소를 보호하는 것이 적절한 임시 방편이 될 수 있습니다.

시스템 침입 탐지 및 파일 감사 활용

파일 감사는 완전히 안전하고 양호한 상태의 시스템 파일 및 속성을 현재 시스템의 파일 및 속성과 비교하는 데 사용되는 프로세스입니다. 이는 승인되지 않은 시스템 변경 사항을 찾아내고 격리하는 좋은 방법입니다.

An IDS(침입 탐지 시스템)은 시스템의 무단 활동을 감시하는 모니터링 소프트웨어를 가리킵니다. 일반적으로 예기치 않은 시스템 변경 사항을 찾아내기 위해 파일 감사 방법을 사용합니다.

IDS/파일 감사를 통한 보안 강화

단순히 서비스 수준의 감사를 넘어 파일 수준의 감사를 수행하는 것은 시스템의 보안을 보장하는 데 필수적입니다. 이는 자동화된 IDS 프로세스에 의해 수행되거나 시스템 관리자가 주기적으로 수행할 수 있습니다.

파일 감사와 IDS는 시스템에 예기치 않은 변경이 발생하지 않았음을 확신할 수 있는 유일한 실제 프로세스입니다. 대부분의 침입자는 침입한 서버를 장기간 악용하기를 원하며, 이를 위해 자신의 행동을 숨길 수 있는 능력을 유지해야 합니다. 그들은 바이너리를 취약하거나 손상된 버전으로 교체할 수 있습니다. 시스템에서 변경된 모든 파일은 파일 시스템 감사를 통해 탐지됩니다. 이를 통해 시스템의 무결성이 손상되었는지 여부를 매우 신속하게 파악할 수 있어 안심할 수 있습니다.

구현 난이도

IDS 및 파일 감사의 구현은 매우 까다로운 프로세스가 될 수 있습니다. 시작할 때, 시스템의 기준선(baseline)을 생성하기 위해 제외할 경로를 정의하고 시스템에 적용된 비표준 변경 사항을 설정하도록 시스템을 구성해야 합니다.

업데이트를 실행하기 전에 절차상 시스템을 다시 확인해야 하므로 일상적인 작업도 더 번거로워집니다. 또한 시스템의 새로운 기준선의 일부로 소프트웨어 버전 변경 사항을 반영하기 위해 시스템 측정 기준선을 재생성하거나 재설정해야 합니다. 감사 보고서도 다른 위치로 이동해야 합니다. 그것은’ 침입자가 자신의 흔적을 감추어 숨어 있기 위해 감사 내용을 변경하는 것을 방지해야 하기 때문입니다.

이로 인해 시스템의 관리 부담이 확실히 증가하지만, 귀하가 모르는 사이에 파일이 변경되지 않도록 보장하는 유일하고 확실한 방법 중 하나입니다. 가장 대중적인 침입 탐지 및 파일 감사 시스템으로는 Aide 및 Tripwire.

격리된 환경

개별 구성 요소가 자체 전용 공간에서 실행되는 모든 방법을 격리된 실행 환경이라고 합니다.

이는 특정 애플리케이션 구성 요소가 자체 전용 서버에 수용되거나, 서비스가 chroot 환경(또는 컨테이너)에서 작동하도록 구성됨을 의미할 수 있습니다. 환경이 얼마나 격리되는지는 주로 인프라의 현실과 애플리케이션의 요구 사항에 따라 달라집니다.

격리된 환경을 통한 보안 강화

프로세스를 개별 환경으로 격리함으로써 보안 결함의 영향을 받을 수 있는 프로세스도 격리하게 됩니다. 구획과 격벽이 선박의 선체 파손을 방지하는 데 도움이 되는 것처럼, 시스템의 개별 부품과 구성 요소를 분리하면 침입자가 그중 하나에 액세스하더라도 서로 연결된 전체 네트워크 시스템에는 도달할 수 없습니다.

구현 난이도

애플리케이션을 격리하는 작업의 복잡성은 사용하기로 결정한 컨테이너화 유형에 따라 달라집니다. Docker는 격리를 보안 기능으로 간주하지 않습니다. 하지만 구성 요소가 서로 다른 컨테이너로 분할되면 격리를 훨씬 더 쉽게 달성할 수 있습니다. 다음 튜토리얼을 통해 당사 인프라에 Docker를 설치할 수 있습니다.

chroot 환경을 설정할 때도 어느 정도의 격리가 제공됩니다. 하지만 이러한 환경을 벗어나는 방법이 존재하기 때문에 이것이 완전히 뚫을 수 없는 방법은 아닙니다. 다양한 구성 요소를 위해 전용 머신을 사용하는 것이 일반적으로 격리를 달성하는 가장 좋고 간단한 방법입니다. 그러나 추가 머신이 필요하기 때문에 비용이 더 많이 듭니다.

마치며

제공된 전략은 시스템 보안을 강화하기 위해 취할 수 있는 몇 가지 조치에 불과합니다. 보안 기능을 구현하는 데 오래 기다릴수록 그 효과가 떨어진다는 점에 유의해야 합니다. 이를 염두에 두고 보안을 미루어서는 안 된다는 점을 확실히 하는 것이 중요합니다. 대신, 인프라 구축의 첫 번째 조치 중 하나로 구현되어야 합니다. 시스템이 기본 보호 조치로 충분히 안전해지면, 안전한 환경에서 기본적으로 실행된다는 점을 인지한 상태에서 서비스를 활성화하고 애플리케이션을 추가할 수 있습니다.

그러나 보안은 정체된 프로세스가 아니라 유동적인 프로세스입니다. 지속적으로 유지 관리하고 반복해야 합니다. 끊임없는 인식과 지속적인 경계의 자세로 접근해야 합니다. 시스템 변경에 수반되는 보안상의 영향이 무엇인지 항상 질문하십시오. 운영 환경과 기본 구성이 항상 보안을 최적화하고 충분히 방어적인 소프트웨어와 함께 작동하도록 하십시오.

즐거운 컴퓨팅 되세요!