시스템 구성 검증

규정 준수를 위해든 드리프트를 최소화하기 위해든 시간이 지남에 따라 서버 시스템 구성의 주요 측면을 모니터링하는 것은 항상 좋은 생각입니다. 불행히도 완전히 동일한 템플릿에서 배포된 가상 머신이라도 때때로 다르게 작동할 수 있습니다. 예, 이것은 IT이며 실제로 발생합니다. Murphy와 그의 법을 비난하십시오. 또한 지속적인 패치가 있고 항상 진화하는 라이브러리 버전이 있으며 시간이 지남에 따라 많은 수의 서버에서 일관성을 유지하는 것은 정말 어려운 일입니다.

이 상태를 달성하는 방법에 대한 두 가지 뚜렷한 철학이 있는 것 같습니다. 일부에서는 Chef , Puppet 또는 Salt 와 같은 구성 관리 도구를 사용하여 현재 설정을 주기적으로 덮어쓰고 시스템 구성을 초기 상태로 재설정하는 것이 가장 좋다고 생각합니다.

저는 개인적으로 이 행동이 위험하다고 생각합니다. 적절한 실사 없이 프로덕션 시스템의 구성을 자동으로 변경하는 것은 현명하지 않습니다. 저는 "감사 및 경고" 접근 방식을 훨씬 선호합니다. 각 구성 항목을 예상한 것과 비교하여 확인하고 불일치가 감지되면 경고를 표시하거나 티켓을 엽니다.

많은 연구 끝에 "빠르고 쉬운 서버 유효성 검사"를 위해 Goss 에 정착했습니다. Goss는 "빠르고 쉬움"이라는 약속에 정말 충실합니다. Linux, Windows 및 macOS용 자체 포함 바이너리를 다운로드하기만 하면 몇 가지 유효성 검사를 수행할 준비가 된 것입니다.

구문은 매우 간단하고 잘 문서화 되어 있으며 패키지 설치 여부, 활성화 및 실행 중인 서비스, 파일 내용 등과 같은 다양한 항목을 확인할 수 있습니다. 내가 찾은 유일한 부정적인 점은 의 역방향 논리였습니다. 필수 항목이 누락된 경우의 일부 오류 메시지. 그렇지 않으면 견고한 도구를 사용하는 것이 좋습니다.

모든 시스템이 갖추어야 할 기준선인 Goss 유효성 검사 규칙의 계층, 사이버 보안 규정 준수 계층의 기준선을 구축한 다음 서버 유형과 해당 기능 및 필수 매개변수를 기반으로 계층을 추가했습니다( Linux 매개변수 조정 참조). . 규칙은 각 서버에서 "라이브" GitHub 리포지토리에서 가져왔고 오류는 다른 GitHub 리포지토리에 문제로 기록되었습니다. 언젠가 전체 코드를 게시할 수 있습니다.