Hardening - 일반 개념

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

다음 문서에서는 GitLab 인스턴스 강화의 기본 철학 중 일부를 요약합니다. GitLab을 참고하지만 많은 경우 사실상 모든 컴퓨터 시스템에 적용할 수 있습니다.

계층화된 보안

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

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

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

난독화된 보안 제거

난독화된 보안은 잠재적 공격자가 시스템, 서비스 또는 프로세스의 특정 세부 정보를 공격을 계획하기 위해 사용할 수 있다는 두려움 때문에 특정 요소에 대해 논의하지 않는 것을 의미합니다. 대신 시스템은 설정에 대한 세부 정보가 공개될 수 있으며 시스템은 여전히 가능한 한 안전하게 유지되어야 합니다. 사실, 공격자가 컴퓨터 시스템의 구성 세부 정보를 알아도 이로 인해 이점을 얻지 못해야 합니다. 난독화된 보안의 단점 중 하나는 관리자가 시스템이 실제보다 더 안전하다고 생각하는 오도를 일으킬 수 있다는 것입니다.

여기에는 일반적으로 서버의 기본 TCP 포트인 TCP 포트 22인 SSH 데몬 포트를 다른 포트(예: TCP 포트 2222)로 구성하는 경우가 있습니다. 이를 구성한 관리자는 시스템의 보안성이 향상된다고 생각할 수 있지만, 공격자가 모든 개방된 포트를 빠르게 찾아내어 SSH 서비스를 발견할 수 있기 때문에 실제로 이는 안전 상의 이점을 제거한다.

GitLab은 오픈 소스 시스템이며 모든 구성 옵션이 잘 문서화되어 공개 정보로 공유됩니다. 따라서 보안을 난독화를 통해 이루려는 아이디어는 GitLab의 핵심 가치인 투명성에 반합니다. 이러한 강화 권고 사항은 공개적으로 공유되어 보안을 난독화하는 것을 돕고자 합니다.

공격 표면 줄이기

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

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

외부 시스템

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