<aside>
☁️ 클라우드웨이브 · W07 · 5/5 · 예상 읽기 7분
</aside>
보안은 마지막에 방화벽 하나를 추가하는 작업이 아니었다. 클라우드에서는 제공자가 책임지는 기반과 사용자가 책임지는 데이터·권한·구성의 경계를 먼저 이해해야 한다. 그 위에 기밀성, 무결성, 가용성이라는 CIA 목표를 놓고, 예방·탐지·대응을 연결해야 운영 가능한 보안이 된다.
서비스 유형에 따라 제공자와 사용자의 책임 범위는 달라진다. 사용자는 데이터 분류, 계정과 권한, 네트워크 노출, 애플리케이션 취약점, 로그 보존을 스스로 확인해야 한다. 장기 자격증명을 여러 곳에 복사하기보다 역할 기반의 임시 자격증명을 사용하면 노출 범위와 회수 시간을 줄일 수 있다.
최소 권한은 단순히 권한 항목 수를 줄이는 것이 아니다. 누가, 어떤 작업을, 어떤 리소스에, 어떤 조건에서 수행하는지 좁히는 원칙이다. 명시적 거부는 허용보다 우선하므로, 정책을 추가할 때 허용 목록만 보지 말고 상위 경계와 거부 조건도 함께 검토한다.
{
"Statement": [
{
"Effect": "Allow",
"Action": ["<REQUIRED_ACTION>"],
"Resource": "<RESOURCE_PLACEHOLDER>"
}
]
}
위 예시는 구조를 설명하기 위한 비실행 예시다. 실제 정책에는 업무에 필요한 최소 작업만 넣고, 광범위한 전체 권한이나 무제한 리소스 지정은 피한다. 권한 사용 내역을 검토하고 사용하지 않는 권한을 주기적으로 줄이는 절차도 필요하다.
CloudTrail과 같은 감사 로그는 누가 언제 어떤 API 활동을 했는지 확인하는 기반이다. 로그 자체의 무결성, 접근 권한, 보존 기간, 중앙 수집과 알림 연결을 설계해야 한다. 로그를 남기는 것과 조사 가능한 것은 다르므로, 정상 기준선과 중요한 변경 이벤트를 정의해 검색 시간을 줄인다.
보안 그룹은 보통 리소스 가까이에서 상태를 고려한 트래픽 규칙을 적용하고, 네트워크 ACL은 서브넷 경계에서 더 넓은 흐름을 제어한다. 둘은 대체 관계가 아니라 서로 다른 계층의 방어선이다. 허용 규칙을 열 때는 방향, 포트, 출발지 범위와 사용 목적을 함께 기록한다.
WAF는 웹 요청을 검사해 알려진 공격 패턴, 비정상 요청, 봇 활동을 규칙으로 완화하는 계층이다. 애플리케이션 인증과 입력 검증을 대신하지는 않으며, 정상 사용자를 막는 오탐을 관찰하면서 단계적으로 조정해야 한다. DDoS 방어도 WAF 하나로 끝나지 않고 엣지 보호, 용량 계획, 캐시와 레이트 리밋, 공급자 방어 기능을 함께 검토한다.
flowchart TD
E[이벤트 탐지] --> Q[영향 범위 확인]
Q --> C[접근 차단 또는 권한 회수]
C --> R[서비스 복구와 검증]
R --> L[로그 보존과 회고]
L --> I[통제 개선]
사고 대응은 탐지 시점에 처음 설계하면 늦다. 연락 체계, 승인된 차단 조치, 증거 보존, 복구 확인, 사후 권한 재검토를 미리 연습한다. 구체적인 사건 식별자나 비밀 값을 문서에 남기지 않고, 재현 가능한 일반 절차와 안전한 예시만 보관한다.
정기적으로 IAM 권한과 사용하지 않는 자격증명을 검토하고, 감사 로그가 예상 저장소에 도착하는지 확인한다. 네트워크 규칙은 변경 이유와 만료 시점을 함께 기록한다. WAF 규칙은 차단 수와 오탐을 대시보드로 보고, 사고 훈련에서 실제 담당자가 필요한 로그를 찾을 수 있는지 검증한다.