auditd 규칙 파일에 문장이 있어도 그 규칙이 현재 커널에 적재됐다는 뜻은 아닙니다. Oracle Linux의 감사 도구 흐름에서는 rules.d 조각이 병합되어 audit.rules가 되고, auditctl이 실행 중 규칙 상태와 상호작용합니다. 파일, 병합 결과, 현재 상태를 서로 다른 증거로 비교해야 합니다.
규칙이 보인다고 실제 이벤트가 빠짐없이 기록됐다고 단정할 수도 없습니다. 규칙 조건, 감사 서비스 상태, 저장 공간과 검색 필터를 각각 확인하세요. 아래 내용은 가상 학습 예시이며 어떤 감사 규칙도 실제 시스템에 적재하지 않습니다.
규칙은 저장된 설정과 실행 상태가 따로 있습니다
Linux Audit는 커널 쪽에서 사건을 감지하고 auditd가 기록을 저장하는 구조입니다. 규칙 파일은 어떤 사건을 수집할지 정하는 입력이지만, 파일을 편집했다고 실행 중인 커널 규칙이 자동으로 바뀌는 것은 아닙니다. Oracle Linux 안내는 rules.d의 구성 파일을 병합해 audit.rules를 만들고, 서비스 시작 과정에서 규칙을 읽어 적재하는 흐름을 설명합니다. 별도로 auditctl은 현재 커널 audit 상태를 조회하거나 규칙을 다룹니다.
가상 점검 표에서 규칙이 멈춘 단계를 찾습니다
| 증거 위치 | 관찰 예시 | 다음 질문 |
|---|---|---|
| /etc/audit/rules.d/20-app.rules | key=app-change 규칙이 있음 | 이 파일이 로드 대상이고 문법이 유효한가? |
| /etc/audit/audit.rules | 해당 규칙이 없음 | 조각 병합 또는 배포 단계가 빠졌나? |
| auditctl -l로 읽은 커널 상태 | 해당 규칙이 없음 | 현재 실행 중 규칙에 실제 적재됐나? |
| ausearch 결과 | 키 app-change가 없음 | 규칙 조건·시간·키·로그 저장 범위를 맞게 조회했나? |
첫째 파일에 규칙이 있어도 둘째 파일에 합쳐지지 않았다면 병합 설정이나 파일 확장자를 확인할 수 있습니다. 둘째 파일에는 있는데 커널 상태에는 없다면 실행 중 서비스의 적재 여부를 별도로 조사합니다. 세 단계가 모두 맞는데도 검색 결과가 없다면 이벤트가 규칙 조건과 일치했는지, 검색 시간이 맞는지, key 필터를 정확히 썼는지 따져야 합니다. 각 관찰은 원인을 좁힐 뿐 단독으로 전체 수집 성공을 증명하지 않습니다.
읽기 전용 확인과 규칙 변경을 구별합니다
- 승인된 변경 티켓과 규칙의 목적·대상을 먼저 읽습니다.
rules.d파일명과 문법, 포함 경로를 검토합니다.- 배포판이 생성하는
audit.rules를 원본 조각과 비교합니다. - 커널의 현재 규칙 목록과 감사 subsystem 상태를 확인합니다.
- 테스트 이벤트가 규칙 조건에 해당하는지, 로그 검색 키·시간 범위를 확인합니다.
- 수집 실패나 backlog·저장 용량 문제는 별도 증거로 남깁니다.
이 절차는 파일 열람과 승인된 상태 조회를 말합니다. auditctl -a, augenrules --load처럼 실행 중 정책을 바꾸는 작업은 여기서 수행하거나 권하지 않습니다. 감사 정책 변경은 기록량, 성능, 로그 저장 공간과 장애 대응에 영향을 줄 수 있으므로 담당자의 검토 및 변경 승인이 필요합니다.
적재된 규칙과 실제 이벤트 기록은 마지막으로도 다릅니다
커널 규칙 목록에 항목이 있다는 것은 현재 상태에서 그 규칙이 보인다는 증거입니다. 그러나 해당 시간대에 이벤트가 발생했는지, syscall과 경로 조건이 맞는지, audit daemon이 기록을 저장했는지, 로그가 보존됐는지까지 보장하지는 않습니다. Oracle Linux 공식 문서는 auditd 기록에 이벤트 종류·시각·사용자 ID·성공 여부가 들어갈 수 있다고 설명합니다. 따라서 질문이 ‘규칙이 적재됐나’인지 ‘이 사건이 기록됐나’인지 먼저 고르고, 그에 맞는 증거를 각각 수집하세요.
파일에 규칙 한 줄이 있으면 끝났다고 답하지 않습니다
흔한 실수는 rules.d에 줄이 있다는 이유로 수집이 정상이라고 결론 내리는 것입니다. 반대 방향으로 로그 한 건이 없다는 이유만으로 규칙이 적재되지 않았다고 확정하는 것도 위험합니다. 그 이벤트가 조건에 맞지 않았거나, 검색 키가 다르거나, 조회 기간이 잘못됐을 수 있습니다. 상태 파일과 검색 결과를 동일한 ‘감사 로그’로 뭉치지 말고, 각 증거가 무엇을 입증하는지 적어야 합니다.
규칙 파일·커널·로그를 세 칸으로 가리고 회상합니다
복습 표를 만들 때 ‘저장된 규칙’, ‘현재 적재된 규칙’, ‘실제 수집된 이벤트’를 세 열로 두세요. rules.d 한 줄은 첫 열, auditctl 상태는 둘째 열, ausearch에서 확인한 사건은 셋째 열의 근거입니다. 가상 예시에서 첫 열만 채워져 있다면 규칙 등록은 확인했어도 적재와 수집은 아직 UNKNOWN입니다. 답안에서 이 경계를 밝히면 관찰 사실을 넘어서 성공을 추론하지 않게 됩니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
가상 규칙이 rules.d 파일에 있지만 audit.rules와 현재 auditctl -l 결과에는 없습니다. 로그 검색에 이벤트가 없다는 사실만으로 어떤 결론을 낼 수 있나요?
정답과 해설 확인
규칙 원본 파일에는 있으나 병합 결과와 현재 커널 적재는 확인되지 않았습니다. 이벤트 기록 여부도 별도 증거가 필요합니다.원본 규칙, 생성된 규칙 파일, 현재 kernel 규칙 목록, 수집 로그는 서로 다른 단계의 증거입니다. 로그 검색 결과가 비어 있는 것만으로 규칙 미적재의 원인을 확정할 수 없습니다.