강화 - 일반적인 개념

일반 강화 지침은 주요 강화 문서에 개요로 설명되어 있습니다.

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

계층화된 보안

보안을 구현하는 두 가지 방법이 있다면 하나만이 아닌 둘 다 구현해야 합니다. 빠른 예로 계정 보안을 들 수 있습니다.

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

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

난독화된 안전하지 않은 보안 방법 제거

난독화된 안전하지 않은 보안 방법은 시스템, 서비스 또는 프로세스의 특정 요소에 대해 논의하지 않는 것을 의미합니다. 이것은 잠재적인 공격자가 해당 세부정보를 사용하여 공격을 계획할까봐 두려워하는 것입니다. 대신, 시스템은 구성 세부 정보가 공개되어도 여전히 가능한 최고의 수준으로 안전하게 되도록 보안되어야 합니다. 본질적으로, 공격자가 컴퓨터 시스템의 구성 세부 정보에 대해 배우더라도 이로 인해 이점을 얻을 수 없어야 합니다. 난독화된 안전하지 않은 보안의 단점 중 하나는 시스템 관리자가 시스템이 실제보다 더 안전하다고 생각하여 잠재적인 오진 보안 감각을 가질 수 있다는 것입니다.

이를 보여주는 예로 서비스를 표준 TCP 포트가 아닌 기타 TCP 포트에서 실행하는 것이 있습니다. 예를 들어 서버의 기본 SSH 데몬 포트는 TCP 포트 22입니다. 그러나 SSH 데몬을 TCP 포트 2222와 같은 다른 포트로 구성할 수 있습니다. 이것을 구성한 관리자는 시스템의 보안이 더 높아졌다고 생각할 수 있지만, 공격자가 시스템을 포트 스캔하여 모든 열린 포트를 발견할 수 있기 때문에, SSH 서비스를 빠르게 찾아내어 인식된 보안 장점을 없애버릴 수 있습니다.

GitLab은 오픈코어 시스템이며 모든 구성 옵션은 잘 문서화되어 공개 정보입니다. 따라서, 난독화된 안전하지 않은 보안 사상은 GitLab의 핵심 가치인 투명성에 반합니다. 이러한 강화 권장 사항은 공개되어 잠재적인 보안 방법을 없애기 위해 의도되었습니다.

공격 표면 감소

GitLab은 많은 구성 요소를 갖춘 대규모 시스템입니다. 일반적인 보안을 위한 일반적인 규칙은 사용되지 않는 시스템을 비활성화하는 것입니다. 이는 잠재적인 공격자가 사용할 수 있는 “공격 표면”을 제거합니다. 이는 시스템 리소스를 늘릴 수 있는 추가적인 이점도 초래할 수 있습니다.

예를 들어 시스템에서 5분마다 실행되어 입력 대기열을 확인하고 여러 하위 프로세스를 쿼리하는 프로세스가 있습니다. 해당 프로세스를 사용하지 않는다면 구성할 필요가 없으며 비활성화해야 합니다. 공격자가 이 프로세스를 사용하는 공격 벡터를 알게 되어도 조직에서 사용하지 않는 경우에도 공격을 시도할 수 있습니다. 일반적인 규칙으로 사용되지 않는 서비스를 모두 비활성화해야 합니다.

외부 시스템

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