보안 장애는 먼저 “거부인가 허용인가, 어느 계층인가”를 가른다
보안 문제는 두 방향으로 나뉜다 — 정상 접근이 거부되거나, 막아야 할 접근이 허용되거나. 그리고 그것이 네트워크·인증·인가·앱 중 어느 계층에서 일어나는지에 따라 볼 곳이 완전히 다르다. 추측 대신 계층부터 특정한다.
계층 지도
- 네트워크 — 방화벽·보안그룹·NetworkPolicy. 연결 자체가 안 되면 여기.
- 인증(누구인가) — 인증서(x509/mTLS), 토큰 만료, 자격증명. 핸드셰이크·401.
- 인가(무엇을 할 수 있나) — RBAC, IAM 정책, sudoers. 인증은 됐는데 403.
- 앱 계층 — WAF, 입력 검증, 애플리케이션 정책.
거부: 로그에서 “실제 거부 사유”를 집는다
보안 거부는 감사 로그에 정확한 사유가 남는다 — 어느 규칙(rule id), 어느 정책, 어느 권한이 막았는지. 이걸 집지 않고 권한을 이것저것 열면, 문제는 안 풀리고 표면적만 넓어진다(가장 위험한 안티패턴).
ausearch -m avc -ts recent # SELinux 거부
kubectl auth can-i <verb> <resource> --as=<user> # RBAC 인가 확인허용(오탐/과다권한): 좁혀서 예외
WAF 오탐이든 과다한 권한이든, 해법은 “전체를 끄기”가 아니라 특정 대상에 한정한 예외/축소다. 최소 권한 원칙을 유지하면서 필요한 범위만 연다.
정리
방향(거부/허용) → 계층(네트워크/인증/인가/앱) → 로그에서 정확한 사유 → 좁혀서 조정. “보안이 막는다”를 “어느 규칙이 무엇을 막는다”로 바꾸는 순간 대부분 풀린다.
빠른 진단 체크리스트
- 거부인지 허용(오탐)인지 방향을 먼저 가른다
- 네트워크·인증·인가·앱 중 어느 계층인지 특정한다
- 연결 자체가 안 되면 방화벽·보안그룹·NetworkPolicy를 본다
- 핸드셰이크·401이면 인증서·토큰·자격증명을 본다
- 인증은 됐는데 403이면 RBAC·IAM·sudoers를 본다
- 감사 로그에서 실제 거부 규칙·정책을 특정한다
kubectl auth can-i·ausearch로 인가를 확인한다- 권한을 넓히기보다 최소 범위로 좁혀 예외한다