계정·권한·로그와 모니터링
운영 계정·특권권한의 생명주기와 로그·메트릭·추적정보를 이용한 모니터링·경보를 학습한다.
1. 운영 계정의 종류
| 계정 | 용도 | 주의 |
|---|---|---|
| 개인 사용자 | 사람의 일상 업무 | 공유 금지, 소유자 명확 |
| 관리자·특권 | 시스템 설정·운영 | 일반 계정과 분리, MFA·감사 |
| 서비스 계정 | 애플리케이션·배치 실행 | 대화형 로그인 제한, 키 회전 |
| 비상 계정 | 장애·복구 시 사용 | 봉인·시간 제한·사후 검토 |
| 외부 인력 | 위탁·유지보수 | 기간·접속경로·작업범위 제한 |
사용자 계정
└─ 필요할 때 승인된 sudo
└─ 관리자 작업
└─ 명령·결과 감사
일상적으로 root로 로그인하기보다 개인 식별이 가능한 계정과 통제된 권한 상승을 사용한다.
2. 계정 생명주기
요청 → 본인·업무 확인 → 승인 → 계정 생성
→ 역할 기반 권한 부여 → 사용·감사
→ 정기 검토 → 변경·휴면 → 비활성화·삭제
점검 항목:
- 퇴직·이동·휴직 계정
- 장기 미사용 계정
- 비밀번호·키 만료와 회전
- 소유자가 없는 서비스 계정
- 공유계정
- 만료일 없는 외부 계정
- 중복 관리자 권한
3. sudo와 특권 통제
sudo는 승인된 사용자가 특정 명령을 높은 권한으로 실행하게 한다.
sudo systemctl restart app.service
sudo -l
좋은 정책:
- 사용자별 계정
- 필요한 명령만 허용
- 전체 셸 허용 최소화
- 명령·시간·대상 기록
- 비상권한 만료
- 운영·개발 직무분리
sudo ALL=(ALL) ALL처럼 과도한 권한은 최소권한 원칙에 맞지 않을 수 있다.
4. 로그의 목적
로그는 문제 해결뿐 아니라 감사, 보안 탐지, 성능 분석, 업무 대사에 사용된다.
애플리케이션 로그 ─┐
시스템 로그 ├─► 수집·전송 ─► 중앙 저장 ─► 검색·분석·경보
보안 로그 ┤
네트워크 로그 ┘
좋은 로그는 다음 정보를 포함한다.
- 시간과 시간대
- 요청·추적 ID
- 사용자 또는 서비스 신원
- 대상 자원과 동작
- 결과·오류 코드
- 처리시간
- 출처 시스템·버전
비밀번호, 인증토큰, 개인식별정보 원문, 비밀키는 기록하지 않는다.
5. 로그 수준
| 수준 | 일반적인 의미 |
|---|---|
| TRACE | 매우 상세한 흐름 |
| DEBUG | 개발·진단용 상세 정보 |
| INFO | 정상 주요 이벤트 |
| WARN | 즉시 실패는 아니나 주의 필요 |
| ERROR | 요청·기능 실패 |
| FATAL | 서비스 지속이 어려운 치명 상황 |
운영 환경에서 DEBUG를 무제한 사용하면 용량·성능·민감정보 노출 문제가 생길 수 있다.
6. 로그 순환과 보존
app.log
├─ 크기·시간 조건 충족
▼
app.log.1 → 압축 → 보존기간 경과 → 삭제
고려사항:
- 파일 크기와 보존기간
- 압축
- 중앙 전송 성공 여부
- 디스크 고갈 방지
- 법·업무·보안 요구
- 무결성·접근권한
- 검색 가능한 인덱스 기간
애플리케이션이 삭제된 파일 핸들을 계속 잡고 있으면 파일은 보이지 않아도 공간이 반환되지 않을 수 있다.
7. 메트릭
메트릭은 시간에 따라 수집하는 수치형 지표이다.
- CPU·메모리·디스크·네트워크
- 요청량
- 응답시간
- 오류율
- 큐 길이
- 커넥션풀 사용률
- GC 시간
- 업무 성공·실패 건수
대표 서비스 지표를 RED로 정리할 수 있다.
Rate : 요청량
Errors : 오류율
Duration: 처리시간
자원 관점에서는 사용률·포화도·오류를 함께 본다.
8. 분산 추적
하나의 사용자 요청이 여러 서비스를 거칠 때 trace ID와 span ID로 호출 관계를 연결한다.
Trace T-100
├─ API Gateway span: 120ms
├─ Order Service span: 90ms
│ ├─ DB span: 30ms
│ └─ Payment API span: 50ms
└─ Response
로그는 이벤트의 상세, 메트릭은 전체 경향, 트레이스는 분산 요청 경로를 보여준다.
9. 경보 설계
좋은 경보는 사람이 조치할 수 있고 실제 사용자 영향과 연결된다.
지표 수집
↓
임계값·이상 탐지
↓
지속시간·재확인
↓
중복 억제·연관 경보 묶기
↓
담당자 통지
↓
Runbook에 따른 조치
나쁜 경보:
- 순간적인 작은 변동마다 울림
- 원인 지표만 있고 사용자 영향이 없음
- 담당자·조치 방법이 없음
- 복구 후 자동 해제되지 않음
- 같은 장애가 수백 건으로 중복 통지됨
10. 시간 동기화
시스템 시간이 다르면 로그 순서, 인증서 검증, 티켓 인증, 분산 추적, 장애 분석이 왜곡된다.
공통 시간원
├─ 서버 A 12:00:01
├─ 서버 B 12:00:01
└─ DB 12:00:01
시간대와 UTC 변환 규칙을 일관되게 사용하고 시간 동기화 상태를 감시한다.
11. 운영 점검 명령 예시
who
last
id appuser
getent passwd appuser
sudo -l -U appuser
journalctl -p err --since today
tail -F /var/log/app/app.log
ss -lntp
명령 결과만 모으지 말고 기준값·최근 변경·사용자 영향과 연결한다.
12. 계정 통제와 JIT 운영
개인 계정 로그인 → MFA → 승인 요청 → 임시 관리자 역할
→ 명령·세션 기록 → 만료 시 자동 회수
공유 root 계정 직접 사용보다 개인 식별, 최소 명령 허용, 세션 기록이 감사 가능성을 높인다. 서비스 계정은 사람이 로그인하지 못하게 하고 소유자·용도·만료·비밀 회전·호출 원천을 관리한다.
13. 로그 파이프라인과 상관분석
Application/System/Audit Log
→ 수집 agent → buffer/queue → 중앙 저장·정규화
→ 검색·규칙·상관분석 → 경보·티켓 → 보존·파기
로그에는 timestamp, host/service, environment, severity, event type, actor, target, request/trace ID, result를 구조화한다. 비밀번호·access token·주민번호 같은 비밀·민감정보는 기록하지 않거나 마스킹한다.
14. RED·USE와 지표 계산
- RED: Rate, Errors, Duration — 서비스 요청 관점
- USE: Utilization, Saturation, Errors — 자원 관점
오류율 = 오류 요청 / 전체 요청 × 100
경보 정밀도 = 실제 장애 경보 / 전체 경보 × 100
1시간에 20,000건 중 300건이 실패하면 오류율은 1.5%다. 평균 지연만 보면 tail latency를 놓칠 수 있으므로 p95·p99를 본다.
15. SLO burn-rate 경보
99.9% 성공률 SLO의 오류예산은 0.1%다. 관측 구간 오류율이 1%이면 단순 burn rate는 1% / 0.1% = 10이다. 짧은 구간과 긴 구간을 함께 쓰면 빠른 탐지와 일시적 잡음 억제를 균형화할 수 있다.
16. 시간·추적 연계
분산 시스템의 시계가 어긋나면 인증서·토큰 만료와 로그 순서 분석이 잘못될 수 있다. NTP 상태, timezone, monotonic clock 사용 여부를 구분한다. trace ID는 서비스 간 요청을 연결하고 span ID는 개별 작업을 구분한다.
확인 문제
- 20,000건 중 300건 실패의 오류율은?
- 99.9% SLO에서 관측 오류율 1%의 burn rate는?
- metric label에 사용자 ID를 넣기 위험한 이유는?
- trace ID와 span ID의 차이는?
- 공유 root보다 개인계정+sudo가 나은 이유는?