Hardening - 일반적인 개념

일반 강화 가이드라인은 주요 강화 문서에 개요되어 있습니다.

다음 문서는 GitLab 인스턴스 강화의 기본 철학을 요약한 것입니다. GitLab을 언급하고 있지만 많은 경우 실제로 모든 컴퓨터 시스템에 적용할 수 있습니다.

계층화된 보안

보안을 구현하는 두 가지 방법이 있는 경우 한 가지만 사용하는 대신 두 가지 모두를 구현해야 합니다. 예를 들어 계정 보안을 보면:

  • 계정에 긴, 복잡하고 고유한 비밀번호 사용
  • 추가 보안을 위해 인증 프로세스에 두 번째 요소 구현
  • 하드웨어 토큰을 두 번째 요소로 사용
  • 인증 시도 실패로 인해 계정 잠금 (적어도 일정 시간 동안)
  • 특정 기간 동안 사용되지 않은 계정은 자동화하거나 정기적인 감사로 비활성화

디렉터리에서 한 두 가지 항목만 사용하는 대신 가능한 많은 항목을 사용하세요. 이러한 철학은 계정 보안 외에도 다른 영역에도 적용되어야 합니다.

난해성을 통한 보안 제거

난해성을 통한 보안은 잠재적인 공격자가 시스템, 서비스 또는 프로세스의 특정 요소에 대한 세부 정보를 공격에 활용할 수 있기 때문에 해당 요소를 논의하지 않는 것을 의미합니다. 대신, 시스템은 설정에 대한 세부 정보가 공개될 수 있고 시스템은 여전히 가능한 한 안전할 수 있도록 보호되어야 합니다. 본질적으로, 공격자가 컴퓨터 시스템의 구성 세부 정보를 알아도 그들에게 이점을 제공하지 않아야 합니다. 난해성을 통한 보안의 단점 중 하나는 시스템 관리자가 실제로 예상보다 시스템이 더 안전하다고 생각하여 잠재적인 잘못된 보안 감을 느낄 수 있다는 것입니다.

이를 예로 들면, 일반적으로 서버의 기본 SSH 데몬 포트는 TCP 포트 22이지만 SSH 데몬을 TCP 포트 2222와 같은 다른 포트에서 실행할 수 있습니다. 이렇게 구성한 관리자는 시스템의 보안을 강화한다고 생각할 수 있지만, 공격자가 시스템을 포트 스캔하여 모든 개방된 포트를 발견할 수 있으므로 SSH 서비스를 빠르게 찾아내어 잠재적인 보안 장점을 제거할 수 있습니다.

GitLab은 오픈코어 시스템이며 모든 구성 옵션은 잘 문서화되어 공개 정보입니다. 따라서 난해성을 통한 보안 개념은 GitLab의 핵심 가치인 투명성에 반합니다. 이러한 강화 권고 사항은 공개적으로 제공되어 난해성을 통한 보안을 제거하는 데 도움이 될 것입니다.

공격 표면 감소

GitLab은 많은 컴포넌트를 갖춘 대규모 시스템입니다. 일반적으로 보안을 위해 사용되지 않는 시스템을 비활성화하는 것이 도움이 됩니다. 이는 잠재적인 공격자가 공격에 사용할 수 있는 “공격 표면”을 없애는 데 도움이 됩니다. 이는 사용 가능한 시스템 자원을 늘리는 추가적인 이점을 가질 수도 있습니다.

예를 들어, 시스템에서 5분마다 입력을 확인하고 여러 하위 프로세스를 쿼리하는 프로세스가 있을 때, 해당 프로세스를 사용하지 않는다면 구성할 필요가 없으며 비활성화해야 합니다. 공격자가 이 프로세스를 사용하는 공격 벡터를 파악했다면, 조직에서 사용하지 않더라도 공격자가 이를 악용할 수 있습니다. 일반적인 규칙으로 사용하지 않는 서비스는 비활성화해야 합니다.

외부 시스템

보다 크지만 여전히 강화된 배포에서는 GitLab 배포에 필요한 부하 처리를 위해 여러 노드가 사용됩니다. 이러한 경우 방화벽 규칙에 대한 외부, 운영 체제 및 구성 옵션의 조합을 사용하세요. 제한 사항을 사용하는 옵션은 하위 시스템이 작동할 수 있도록 충분히 열어두어야 합니다. 네트워크 트래픽에 대해 가능한 경우 TLS 암호화를 사용하세요.