우리는 대규모의 Red Hat 7/8 시스템을 보유하고 있습니다. 우리는 모든 시스템이 CIS를 준수하는지 확인해야 한다는 요구 사항이 있습니다.
요구 사항 중 하나는 감사 로그를 자동으로 순환하지 않는 것입니다. 즉, 다음을 구성합니다.
max_log_file_action = keep_logs
그러나 이 설정은 로그가 저장되는 파티션을 채웁니다. 위 설정을 구성하고 싶지만 rotate그렇게 하면 시스템이 비준수 상태가 됩니다.
업계의 다른 사람들이 감사 로그를 순환하는 데 사용하는 메커니즘을 찾으려고 노력하고 있습니다.
건배
답변1
보안 통제는 예 또는 아니오로 결정되는 것이 아닙니다. 감사 이벤트가 손실되지 않도록 하기 위해 얼마나 극단적인 조치를 취할 수 있는지 비판적으로 생각해 보십시오. 대체 컨트롤에 대해 창의력을 발휘해 보세요.
CIS는 이제 문의 양식 뒤에 구현 체크리스트를 추가한 것으로 보입니다. 에서 오래된 사본을 찾았습니다.CIS_Red_Hat_Enterprise_Linux_7_Benchmark_v2.2.0.pdf구현 세부 사항을 논의합니다. 용어와 번호 매기기는 변경될 수 있지만 추론은 대부분 시대를 초월합니다.
4.1.1.3 감사 로그가 자동으로 삭제되지 않는지 확인(점수 지정) 프로필 적용 범위:
- 레벨 2 - 서버
- 레벨 2 - 워크스테이션
설명: max_log_file_action 설정은 최대 파일 크기에 도달한 감사 로그 파일을 처리하는 방법을 결정합니다. keep_logs 값은 로그를 회전하지만 이전 로그는 삭제하지 않습니다.
근거: 보안 수준이 높은 상황에서는 긴 감사 기록을 유지하는 것의 이점이 감사 기록을 저장하는 데 드는 비용을 초과합니다.
감사: 다음 명령을 실행하고 출력이 일치하는지 확인합니다.
# grep max_log_file_action /etc/audit/auditd.conf max_log_file_action = keep_logs해결: /etc/audit/auditd.conf에서 다음 매개변수를 설정하십시오.
max_log_file_action = keep_logsCIS 통제: 6.3 감사 로깅 시스템이 손실되지 않도록 보장(예: 순환/보관)
로그를 저장하는 모든 시스템에는 정기적으로 생성되는 로그를 위한 적절한 저장 공간이 있는지 확인하여 로그 회전 간격 사이에 로그 파일이 가득 차지 않도록 하십시오. 로그는 정기적으로 보관하고 디지털 서명해야 합니다.
이론적 근거는 높은 수준의 보안 환경에 대해 설명합니다. 레벨 2, 내가 매핑한다고 가정구현 그룹 2새로운 용어로. 이는 이벤트 손실을 전혀 감당할 수 없는 상황, 규정 준수 환경 또는 기타 위험으로 인해 큰 영향을 미치는 상황을 위한 것입니다.
안전한 방법은 로그 파일 보관 프로세스가 오래된 파일을 백업한 후에만 삭제하도록 하는 것입니다. 물론 호스트에서 로그 파일을 삭제할 수 있습니다. 하지만 보관에 실패하더라도 로그 순환으로 인해 파일이 조기에 삭제되지 않도록 주의하세요.
아카이브 저장소의 경우 감사 로그를 변경하거나 삭제하지 마십시오. 파일에 서명하여 무결성을 확인하세요. 객체 스토리지 계정에서 편집 및 삭제 권한을 제거합니다. 테이프 미디어에 냉장 보관하는 것을 고려해보세요.
일부 상황에서는 이 체크리스트도 권장됩니다 admin_space_left_action = halt. 예, 이는 로그할 수 없는 경우 감사 시스템이 호스트를 종료한다는 의미입니다. 서비스 수준 목표로 인해 이것이 겁이 난다면 이 수준의 편집증이 귀하의 환경에 적합한지 재검토해야 할 수도 있습니다.
또한 중앙 집중식 감사 로깅 시스템을 구현합니다. 저장 용량이 큰 시스템에서 이벤트를 전달하거나 수집합니다. 보안, 쿼리, 유지가 더 쉬워졌습니다.
어느 것이 더 나은 보안을 제공합니까? 6개월 동안 쿼리할 준비가 된 데이터와 몇 년 동안 백업한 데이터가 있는 중앙 데이터베이스, 아니면 누군가 체크리스트가 파일 삭제를 금지한다고 생각했기 때문에 항상 스토리지가 부족한 호스트 집합이 있습니까?