보안 강화 - 일반 개념

일반 보안 강화 지침은 주요 보안 강화 문서에 요약되어 있습니다.

다음 문서는 GitLab 인스턴스 보안 강화를 위한 기본 철학 중 일부를 요약합니다. GitLab을 언급하지만, 많은 경우 이러한 원칙은 모든 컴퓨터 시스템에 적용될 수 있습니다.

계층화된 보안

보안을 구현하는 방법이 두 가지 이상 있다면, 하나만 사용하는 것보다 두 가지 모두 구현해야 합니다. 간단한 예는 계정 보안입니다:

  • 계정에 대해 길고 복잡하며 고유한 비밀번호를 사용하세요.
  • 추가 보안을 위해 인증 프로세스에 제2의 요소를 구현하세요.
  • 제2의 요소로 하드웨어 토큰을 사용하세요.
  • 인증 시도가 실패할 경우 계정을 잠그세요(최소 고정 시간 동안).
  • 특정 시간 프레임 동안 사용되지 않은 계정은 비활성화되어야 하며, 이는 자동화 또는 정기 감사로 시행해야 합니다.

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

불확실성을 통한 보안 제거

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

이의 한 예는 비표준 TCP 포트에서 서비스를 실행하는 것입니다. 예를 들어, 서버의 기본 SSH 데몬 포트는 TCP 포트 22이지만, SSH 데몬을 TCP 포트 2222와 같은 다른 포트에서 실행하도록 구성할 수 있습니다. 이를 설정한 관리자는 시스템의 보안이 강화되었다고 생각할 수 있지만, 공격자가 시스템을 포트 스캔하여 모든 열린 포트를 발견하고 SSH 서비스를 빠르게 식별할 수 있도록 하는 것은 매우 일반적입니다. 이는 인식되는 보안 이점을 없애는 결과를 초래합니다.

GitLab은 오픈코어 시스템이며 모든 구성 옵션이 잘 문서화되어 있고 공개 정보이므로 불확실성을 통한 보안의 개념은 GitLab의 핵심 가치인 투명성과 반대됩니다. 이러한 보안 강화 권장 사항은 불확실성을 통한 보안을 제거하는 데 도움이 되도록 공개될 의도로 작성되었습니다.

공격 표면 축소

GitLab은 많은 구성 요소를 가진 대규모 시스템입니다. 보안에 대한 일반적인 규칙으로는 사용하지 않는 시스템을 비활성화하는 것이 도움이 됩니다. 이는 잠재적인 공격자가 사용할 수 있는 “공격 표면”을 제거합니다. 이로 인해 사용 가능한 시스템 리소스가 증가할 수도 있습니다.

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

외부 시스템

더 크지만 여전히 강화된 배포에서는 여러 노드를 사용하여 GitLab 배포가 요구하는 부하를 처리합니다. 이러한 경우 방화벽 규칙에 대한 외부, 운영 체제 및 구성 옵션의 조합을 사용하세요. 제한을 사용하는 모든 옵션은 서브시스템이 기능할 수 있을 만큼만 열어두어야 합니다. 네트워크 트래픽에 TLS 암호화를 사용하는 것이 바람직합니다.