Hardening - 일반적인 개념

일반적인 강화 지침은 main hardening documentation에 기술되어 있습니다.

아래의 문서는 GitLab 인스턴스 강화를 위한 근본적인 철학 중 일부를 요약한 것입니다. GitLab을 참조하고 있지만, 대부분의 경우 모든 컴퓨터 시스템에 적용할 수 있습니다.

계층화된 보안

보안을 구현하는 두 가지 방법이 있다면 한 가지만 하는 것이 아니라 둘 다 구현해야 합니다. 예를 들어 계정 보안에 대한 빠른 예로는:

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

목록에서 하나나 두 가지 항목만 사용하는 대신 가능한 많은 항목을 사용하세요. 이러한 철학은 계정 보안 외에도 다른 영역에 적용될 수 있으며 가능한 모든 영역에 적용해야 합니다.

난독화를 통한 보안 제거

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

이것의 한 예는 표준이 아닌 TCP 포트에서 서비스를 실행하는 것입니다. 예를 들어 서버의 기본 SSH 데몬 포트는 TCP 포트 22이지만, SSH 데몬을 TCP 포트 2222와 같은 다른 포트로 구성할 수 있습니다. 이것을 구성한 관리자는 시스템의 보안성을 높인다고 생각할 수 있지만, 공격자가 시스템의 모든 오픈 포트를 탐지하기 위해 포트 스캔을 하는 것은 상당히 흔한 현상이며, SSH 서비스를 빠르게 발견할 수 있게 함으로써 잠재적인 보안 장점을 제거할 수 있습니다.

GitLab은 오픈 코어 시스템이며 모든 구성 옵션은 잘 문서화되어 있고 공개 정보입니다. 그러므로 난독화를 통한 보안 개념은 GitLab의 핵심 가치인 투명성에 반합니다. 이러한 강화 권고 사항은 공개되어 별도의 난독화된 보안을 제거하는 데 도움이 되도록 되어 있습니다.

공격 표면 감소

GitLab은 많은 구성 요소를 갖춘 대규모 시스템입니다. 일반적인 보안을 위한 일반적인 규칙으로는 사용하지 않는 시스템을 비활성화하는 것이 도움이 됩니다. 이것은 사용 가능한 “공격 표면”을 없애 공격자가 사용할 수 있는 가능성을 줄일 수 있습니다. 이는 시스템 자원을 증가시키는 추가적인 이점을 얻을 수도 있습니다.

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

외부 시스템

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