정보보안 직무를 준비하다 클라우드 보안까지 관심을 넓힌 취업 준비생의 프로젝트를 점검하다 보면 방화벽, 취약점 진단, 악성코드, 로그 분석 같은 기본 보안 개념은 알고 있는데 클라우드 환경에서 무엇이 달라지는지 설명하는 단계에서 막히는 경우가 있습니다. AWS나 Azure에서 서버를 만들어본 경험은 있지만 IAM 정책을 왜 따로 설계해야 하는지, 보안그룹과 네트워크 ACL은 어떤 차이가 있는지, CloudTrail이나 Activity Log 같은 감사 로그를 사고 대응에서 어떻게 활용하는지까지 연결하지 못하는 식입니다. 반대로 클라우드 서비스 사용 경험은 많은데 보안 관점이 약한 경우도 있습니다. EC2나 가상머신을 만들고 VPC를 구성했지만 관리자 권한을 넓게 부여해 두거나, 인터넷에 공개할 필요가 없는 자원까지 외부 접근이 가능하게 설정하거나, 장애가 발생했을 때 어떤 계정이 언제 설정을 변경했는지 확인할 로그를 준비하지 않은 경우입니다. 이 상태에서는 클라우드 인프라를 사용할 수는 있지만 클라우드 환경을 보안 기준으로 운영했다고 보기는 어렵습니다. 클라우드 보안이 일반 정보보안과 가장 크게 달라지는 지점 중 하나는 책임의 경계입니다.
온프레미스에서는 서버와 네트워크, 운영체제, 물리 장비까지 조직이 직접 관리하는 영역이 넓지만 클라우드에서는 IaaS, PaaS, SaaS에 따라 클라우드 사업자와 사용자의 책임 범위가 달라집니다. Microsoft의 공유 책임 모델에서도 데이터와 계정, 접근관리는 서비스 유형과 관계없이 고객이 계속 책임져야 하는 영역으로 설명합니다. 이 때문에 클라우드 보안 직무에서는 기존의 취약점과 방화벽 지식만으로 준비하기 어렵습니다. 누가 어떤 리소스에 접근할 수 있는지를 IAM으로 설계하고, 어떤 네트워크 경로를 허용할지 가상 네트워크 정책으로 통제하며, 실제로 누가 언제 어떤 설정을 변경했는지를 감사 로그에서 확인할 수 있어야 합니다. 클라우드 보안 준비의 핵심은 새로운 보안 제품을 많이 아는 것이 아니라, 계정과 네트워크, 로그를 하나의 운영 통제 구조로 연결하는 것입니다.
이번 글에서는 클라우드 보안 직무가 일반 정보보안과 다른 준비 포인트를 IAM, 네트워크, 로그 세 가지 기준으로 나누어 정리하겠습니다.
IAM은 사용자 계정 관리에서 클라우드 전체 권한 구조를 설계하는 영역으로 확장됩니다
- 클라우드 보안에서는 계정 수보다 누가 무엇을 할 수 있는지가 더 중요합니다
온프레미스 환경에서도 계정과 권한 관리는 중요합니다. 하지만 클라우드에서는 콘솔 로그인뿐 아니라 API 호출과 CLI, 애플리케이션과 서비스 계정, 임시 자격증명까지 다양한 방식으로 리소스를 제어할 수 있기 때문에 권한 구조를 더 세밀하게 봐야 합니다.
IAM 실습에서는 다음 내용을 연결해서 볼 수 있습니다.
- 일반 사용자와 관리자 역할을 분리합니다.
- 사람 계정과 애플리케이션용 역할을 구분합니다.
- 필요한 작업에 맞게 권한 범위를 제한합니다.
- 장기간 사용하는 고정 자격증명 사용을 줄입니다.
- 중요한 작업에는 추가 인증이나 조건을 적용합니다.
- 더 이상 필요하지 않은 권한을 제거합니다.
AWS도 IAM의 핵심 권장사항으로 최소권한을 제시하며 특정 작업에 필요한 권한만 부여하고 불필요한 권한을 줄이는 방향을 안내하고 있습니다. 예를 들어 개발자가 파일을 읽기만 하면 되는 상황에서 저장소 전체 삭제 권한까지 가지고 있다면 정상적인 업무에는 문제가 없어 보여도 계정이 잘못 사용되었을 때 영향 범위가 커질 수 있습니다. 따라서 IAM 프로젝트에서는 사용자를 만들었다는 사실보다 업무 역할에 따라 권한을 어떻게 줄이고 분리했는지가 더 중요합니다.
- 일반 계정관리와 IAM은 권한을 적용하는 단위에서 차이가 있습니다
기존 시스템에서는 사용자 계정과 서버 접근 권한을 중심으로 계정관리를 경험하는 경우가 많습니다. 클라우드 IAM에서는 특정 서비스와 리소스, 작업, 조건까지 조합해 권한을 설계할 수 있습니다.
- 사용자 중심의 권한: 특정 사람이 어떤 서비스에 접근할 수 있는지를 정의합니다.
- 역할 중심의 권한: 개발자와 운영자, 감사 담당자처럼 업무 역할별 권한을 구성합니다.
- 리소스 중심의 권한: 특정 저장소나 프로젝트, 계정 안의 일부 리소스에만 접근하도록 제한합니다.
- 작업 중심의 권한: 조회와 생성, 변경, 삭제 가운데 필요한 행동만 허용합니다.
- 조건 중심의 권한: 특정 네트워크나 인증조건, 태그 등에 따라 접근 여부를 다르게 설정할 수 있습니다.
이런 구조를 이해하면 IAM 정책을 단순히 JSON 문법을 작성하는 과제로 보지 않게 됩니다. 중요한 것은 누가 어떤 상황에서 어느 자원에 어떤 행동까지 할 수 있어야 하는지를 먼저 정의한 뒤 정책으로 변환하는 것입니다.
- IAM 프로젝트에는 과도한 권한을 발견하고 줄이는 과정이 포함되면 좋습니다
IAM을 공부할 때 처음부터 완벽한 최소권한 정책을 만드는 것은 쉽지 않습니다. 오히려 넓은 권한으로 기능을 확인한 뒤 실제 사용한 권한과 불필요한 권한을 비교하면서 줄여가는 과정도 좋은 실습이 될 수 있습니다.
프로젝트에서는 다음 경험을 남길 수 있습니다.
- 최초 역할에 부여된 권한 범위를 기록합니다.
- 실제 업무에서 사용한 서비스와 작업을 확인합니다.
- 사용하지 않은 관리 권한을 구분합니다.
- 조회와 변경 권한을 별도로 나눕니다.
- 권한을 줄인 뒤 필요한 업무가 계속 동작하는지 확인합니다.
- 거부된 요청이 발생하면 필요한 권한인지 다시 판단합니다.
이런 방식으로 진행하면 IAM 사용자와 Role 생성이라는 단순 실습에서 벗어나 과도한 권한을 분석하고 필요한 수준으로 줄인 보안 운영 경험으로 설명할 수 있습니다.
- IAM 사고는 로그인 실패보다 정상 자격증명을 이용한 잘못된 행동으로 나타날 수 있습니다
클라우드 보안에서는 비밀번호를 틀린 공격만 탐지하면 충분하지 않습니다. 정상적인 계정이나 역할이 탈취되거나 과도한 권한을 가진 계정이 오용되면 정상 인증 이후에도 위험한 작업이 수행될 수 있기 때문입니다.
- 정상 로그인 상태: 사용자가 올바른 인증을 거쳐 클라우드에 접근합니다.
- 권한 오용 상태: 정상 계정이지만 평소 사용하지 않던 리소스를 조회하거나 변경합니다.
- 권한 상승 상태: 기존 역할보다 더 강한 권한을 얻는 변경이 발생합니다.
- 자격증명 노출 상태: 외부에 유출된 키나 토큰으로 정상 API 호출이 이루어질 수 있습니다.
- 사후 추적 상태: 누가 어떤 역할로 어느 API를 호출했는지를 로그에서 다시 확인합니다.
이 때문에 IAM은 인증 기술 하나로 끝나는 영역이 아닙니다. 권한 설계 → 사용 감시 → 이상 행동 확인 → 권한 재조정까지 이어져야 실제 클라우드 보안 운영과 가까워집니다.
네트워크는 물리 방화벽 중심에서 가상 네트워크와 리소스 단위 통제로 확장됩니다
- 클라우드 네트워크 보안에서는 인터넷 공개 여부부터 명확하게 구분해야 합니다
정보보안을 공부하면서 방화벽 정책과 포트 차단을 익혔다면 클라우드에서도 기본 원리는 크게 다르지 않습니다. 다만 클라우드에서는 VPC와 서브넷, 보안그룹, 네트워크 ACL 등 논리적인 네트워크 요소를 직접 구성하기 때문에 자원이 어디에 위치하고 어떤 경로로 연결되는지를 함께 이해해야 합니다.
네트워크 보안 실습에서는 다음 내용을 확인할 수 있습니다.
- 인터넷에 공개해야 하는 자원과 내부 자원을 구분합니다.
- 퍼블릭과 프라이빗 서브넷의 역할을 이해합니다.
- 필요한 서비스 포트만 허용합니다.
- 관리용 접근과 사용자 트래픽을 구분합니다.
- 리소스 사이의 통신 범위를 제한합니다.
- 실제 트래픽이 의도한 경로로 이동하는지 확인합니다.
AWS의 VPC 보안 가이드에서도 EC2 수준에서는 보안그룹을 활용하고, 서브넷 수준에서는 네트워크 ACL을 사용할 수 있으며 인터넷 직접 접근이 필요하지 않은 인스턴스는 프라이빗 서브넷에 두는 방식을 권장합니다. 따라서 클라우드 네트워크 보안에서는 방화벽 제품을 아는 것보다 어떤 리소스가 왜 외부에 노출되어야 하고 어느 구간까지 통신해야 하는지를 설명할 수 있어야 합니다.
- 기존 방화벽과 클라우드 네트워크 통제는 적용되는 위치와 관리 방식에서 차이가 있습니다
온프레미스 네트워크에서는 경계 방화벽을 중심으로 내부와 외부를 나누는 방식에 익숙할 수 있습니다. 클라우드에서는 하나의 경계만 보는 것이 아니라 워크로드와 서브넷, 서비스마다 여러 층의 정책을 적용할 수 있습니다.
- 보안그룹 중심 통제: 특정 인스턴스나 리소스에 필요한 인바운드·아웃바운드 통신을 허용합니다.
- 네트워크 ACL 중심 통제: 서브넷 수준에서 네트워크 트래픽을 추가로 허용하거나 차단합니다.
- 라우팅 중심 통제: 트래픽이 어떤 게이트웨이나 네트워크를 거쳐 이동하는지 결정합니다.
- 프라이빗 연결 중심 통제: 인터넷을 거치지 않고 특정 서비스나 네트워크와 연결하도록 구성할 수 있습니다.
- 네트워크 로그 중심 통제: 실제 허용·거부된 트래픽 흐름을 기록해 정책과 비교합니다.
AWS 문서에서도 보안그룹은 상태 저장 방식의 리소스 수준 통제에 활용되고 네트워크 ACL은 서브넷 수준의 추가적인 방어 계층으로 사용할 수 있다고 설명합니다. 이 구조를 이해하면 클라우드 네트워크 보안을 단순히 22번 포트를 막는다는 수준에서 벗어나 여러 통제 계층을 어떤 목적으로 배치할지 설계하는 문제로 볼 수 있습니다.
- 네트워크 실습에는 잘못된 공개 설정을 찾아 수정하는 과정이 포함되면 좋습니다
처음부터 완벽한 보안 구성을 만드는 프로젝트도 의미가 있지만 잘못된 설정을 직접 발견하고 수정하는 과정은 사고 대응 관점을 보여주기 좋습니다. 안전한 개인 실습 환경에서 의도적으로 범위를 제한해 잘못된 공개 설정을 확인할 수 있습니다.
프로젝트에서는 다음 내용을 남길 수 있습니다.
- 외부에 공개된 자원을 목록으로 정리합니다.
- 실제 서비스에 필요한 공개 범위를 확인합니다.
- 과도하게 열린 포트와 접근 대상을 찾습니다.
- 불필요한 공개 주소나 경로를 제거합니다.
- 정책 변경 이후 정상 서비스가 유지되는지 확인합니다.
- 변경 전후 네트워크 흐름을 로그로 비교합니다.
예를 들어 관리용 서버가 모든 인터넷 주소에서 접근 가능하도록 설정되어 있다면 단순히 규칙을 삭제하는 것으로 끝낼 필요는 없습니다. 어떤 관리자가 어디에서 접속해야 하는지와 대체할 접근 방식이 무엇인지까지 확인해야 운영에 필요한 접근을 유지하면서 노출 범위를 줄일 수 있습니다. 이 과정이 포함되면 네트워크 보안 경험도 설정 → 문제 발견 → 위험 판단 → 정책 수정 → 정상 기능 재검증이라는 흐름으로 발전합니다.
- 클라우드 네트워크 보안은 경계 밖과 안을 단순하게 나누는 방식에서 벗어날 필요가 있습니다
클라우드 환경에서는 인터넷에서 들어오는 공격만 생각하면 내부 서비스 사이의 과도한 통신을 놓칠 수 있습니다. 하나의 워크로드가 침해되었을 때 다른 시스템으로 이동할 수 있는 경로를 제한하는 것도 중요한 보안 설계가 될 수 있습니다.
- 인터넷 경계 중심: 외부 사용자가 접근해야 하는 서비스와 포트를 제한합니다.
- 워크로드 간 통신 중심: 애플리케이션과 데이터베이스 사이에 필요한 통신만 허용합니다.
- 관리 네트워크 중심: 운영자 접근 경로를 일반 사용자 트래픽과 구분합니다.
- 하이브리드 연결 중심: VPN이나 전용 연결로 들어오는 온프레미스 네트워크의 접근 범위를 제한합니다.
- 변경 검증 중심: 정책 변경 이후 예상하지 않은 새로운 통신 경로가 생기지 않았는지 확인합니다.
따라서 클라우드 네트워크 보안 프로젝트에서는 외부 방화벽 규칙 하나보다 서비스 구성요소 사이의 관계와 필요한 통신 범위를 먼저 그려보는 경험이 중요합니다.
로그는 서버 이벤트 확인에서 클라우드 전체의 계정·리소스 변경을 추적하는 영역으로 확장됩니다
- 클라우드 보안에서는 시스템 로그와 함께 관리 행위 로그를 볼 수 있어야 합니다
일반 보안 실습에서는 Linux 인증 로그나 웹서버 로그, 방화벽 로그부터 분석하는 경우가 많습니다. 클라우드에서는 여기에 누가 리소스를 생성했고 어떤 정책을 변경했으며 어떤 API를 호출했는지를 기록하는 관리 활동 로그가 매우 중요해집니다.
로그 분석에서는 다음 내용을 연결해서 볼 수 있습니다.
- 누가 작업을 수행했는지 확인합니다.
- 어떤 역할이나 자격증명이 사용되었는지 살펴봅니다.
- 어느 서비스와 리소스에 작업이 수행되었는지 구분합니다.
- 작업이 언제 어디에서 발생했는지 확인합니다.
- 정상적인 변경인지 승인되지 않은 행동인지 판단합니다.
- 관련된 네트워크와 애플리케이션 로그를 함께 비교합니다.
AWS CloudTrail은 IAM 사용자나 역할, AWS 서비스 등이 수행한 계정 활동을 기록하며 요청 주체와 서비스, 수행한 작업 등을 이벤트에서 확인할 수 있습니다. Azure Activity Log 역시 가상머신 생성이나 접근정책 변경과 같은 control plane 작업을 기록합니다. 이 때문에 클라우드 사고 분석에서는 서버 로그만 보는 것이 아니라 관리 콘솔과 API에서 어떤 변경이 이루어졌는지를 함께 추적해야 합니다.
- 운영 로그와 감사 로그는 확인하려는 질문에서 차이가 있습니다
클라우드에는 여러 종류의 로그가 있기 때문에 로그를 수집한다는 한 문장으로 끝내면 실제 분석 목적이 모호해질 수 있습니다. 먼저 어떤 질문에 답하기 위한 로그인지 구분하는 것이 좋습니다.
- 애플리케이션 로그: 서비스 내부에서 어떤 요청과 오류가 발생했는지 확인합니다.
- 시스템 로그: 운영체제와 프로세스가 어떤 상태였는지 확인합니다.
- 네트워크 로그: 어느 IP와 리소스 사이에서 트래픽이 발생했는지 확인합니다.
- 감사 로그: 어떤 사용자나 역할이 리소스와 정책을 변경했는지 확인합니다.
- 보안 탐지 로그: 여러 이벤트를 종합해 의심스러운 활동과 경고를 확인합니다.
Google Cloud Audit Logs도 관리 작업과 리소스 접근 등을 기록하며 누가 무엇을 어디에서 언제 수행했는가를 확인하는 용도로 설명하고 있습니다. 이 구분이 있으면 로그 수집 자체보다 사고 상황에서 어떤 로그를 먼저 보고 어떤 정보를 연결해야 하는지를 설명할 수 있습니다.
- 로그 프로젝트에는 정상 상태와 이상 상태를 비교하는 경험이 포함되면 좋습니다
클라우드 감사 로그는 JSON 구조와 필드가 많아 처음 보면 단순히 검색 방법을 익히는 데 그치기 쉽습니다. 하지만 실제 보안 분석에서는 정상적인 운영 행동을 먼저 알아야 이상 행동을 찾기 쉽습니다.
프로젝트에서는 다음 내용을 확인할 수 있습니다.
- 정상적인 로그인과 리소스 변경 이벤트를 기록합니다.
- 관리자 권한 변경 시 어떤 이벤트가 남는지 확인합니다.
- 리소스 삭제나 네트워크 정책 변경 로그를 살펴봅니다.
- 평소 사용하지 않는 계정이나 위치의 활동을 비교합니다.
- 이벤트 시간순으로 관련 로그를 연결합니다.
- 설정 복구 이후 추가적인 이상 행동이 없는지 다시 확인합니다.
예를 들어 보안그룹에서 특정 포트가 갑자기 외부에 공개된 상황이라면 현재 설정만 확인해서는 누가 언제 변경했는지 알기 어렵습니다. 감사 로그에서 변경 주체와 시간, API 작업을 확인하고 네트워크 로그와 연결하면 사건의 흐름을 더 구체적으로 재구성할 수 있습니다. 이런 경험은 단순 로그 검색에서 벗어나 설정 변경과 보안 영향을 연결해 분석한 사고 대응 경험으로 설명할 수 있습니다.
- 클라우드 로그는 사고 이후 확인하는 자료뿐 아니라 실시간 보안 통제에도 활용할 수 있습니다
로그를 사고가 발생한 뒤 조사하는 자료로만 생각하면 운영 단계에서 활용할 수 있는 범위를 놓칠 수 있습니다. 중요한 권한 변경이나 리소스 공개, 반복되는 인증 실패처럼 즉시 확인해야 하는 이벤트에는 알림과 탐지 기준을 연결할 수 있습니다.
- 사후 조사 중심: 이미 발생한 사고의 변경 이력과 사용자 행동을 시간순으로 확인합니다.
- 탐지 중심: 특정 위험 이벤트가 발생했을 때 빠르게 알림을 받도록 기준을 설정합니다.
- 감사 중심: 관리자와 서비스 계정의 활동을 정기적으로 확인합니다.
- 컴플라이언스 중심: 중요한 변경과 접근 기록이 필요한 기간 동안 보존되고 있는지 확인합니다.
- 개선 중심: 사고 이후 같은 패턴을 더 빨리 탐지할 수 있도록 규칙을 추가합니다.
Azure Activity Log는 리소스 관리 작업을 감사하는 것뿐 아니라 이벤트가 발생할 때 알림을 만들 수 있도록 지원하고 있으며, AWS CloudTrail 이벤트도 계정과 API 활동을 기반으로 후속 분석과 대응에 활용할 수 있습니다. 따라서 로그 준비는 SIEM 화면을 많이 보는 것보다 어떤 이벤트를 위험하게 볼 것인지와 탐지 이후 어떻게 확인할지를 설계하는 방향으로 연결하면 좋습니다.
- conclusion
클라우드 보안 직무를 준비할 때 가장 먼저 피해야 할 것은 일반 정보보안에서 공부한 내용에 AWS나 Azure 서비스 이름만 추가하면 된다고 생각하는 것입니다. 네트워크와 접근통제, 로그 분석이라는 기본 보안 원리는 그대로 중요하지만 클라우드에서는 리소스가 API와 코드로 빠르게 만들어지고 변경되며, 여러 서비스가 각기 다른 권한과 네트워크 정책을 사용할 수 있기 때문에 보안 통제의 단위와 속도가 달라집니다. 또한 클라우드 사업자가 데이터센터와 물리 인프라를 관리한다고 해서 모든 보안을 대신 책임지는 것도 아닙니다. 공유 책임 모델에서 볼 수 있듯이 데이터와 계정, 접근권한과 사용자가 직접 설정하는 클라우드 구성은 여전히 조직이 관리해야 합니다. IaaS와 PaaS, SaaS에 따라 책임 범위는 달라질 수 있기 때문에 어떤 영역을 직접 보호해야 하는지부터 구분해야 합니다. IAM에서는 단순 사용자 생성보다 역할과 최소권한, 서비스 계정과 임시 권한을 이해해야 합니다. 누가 어떤 자원에서 어떤 작업까지 수행할 수 있는지 구조적으로 설계하고, 실제 사용하지 않는 권한을 발견해 줄이는 경험이 중요합니다. 네트워크에서는 외부와 내부라는 하나의 경계만 보는 방식보다 VPC와 서브넷, 리소스 간 통신 관계를 함께 확인해야 합니다. 서비스가 필요한 통신은 유지하면서 불필요한 접근 경로를 줄이고, 정책 변경 이후 실제 트래픽이 의도한 구조로 흐르는지 확인해야 합니다. 로그에서는 운영체제나 애플리케이션 로그뿐 아니라 클라우드 리소스의 관리 활동을 추적할 수 있어야 합니다. 어떤 계정이 어느 시점에 정책과 리소스를 변경했는지와 그 변경이 네트워크나 데이터 접근에 어떤 영향을 만들었는지를 연결하면 사고 대응 경험도 더 구체적으로 만들 수 있습니다.
최종적으로 확인할 항목은 다음과 같습니다.
- 클라우드 공유 책임 모델에서 사용자가 관리할 영역을 구분할 수 있는지 확인합니다.
- IAM 사용자와 역할, 정책의 관계를 설명할 수 있는지 살펴봅니다.
- 최소권한을 적용하고 과도한 권한을 줄여본 경험이 있는지 확인합니다.
- VPC와 서브넷, 보안그룹의 관계를 이해하고 있는지 점검합니다.
- 필요한 통신과 불필요한 공개를 구분할 수 있는지 살펴봅니다.
- 감사 로그에서 사용자와 API, 리소스 변경 이력을 추적할 수 있는지 확인합니다.
클라우드 보안 직무 준비 흐름은 다음과 같이 연결할 수 있습니다.
- 정보보안 기초 → Linux와 네트워크 → 클라우드 공유 책임 이해 → VPC와 서브넷 구성 → IAM 사용자·역할 이해 → 최소권한 정책 설계 → 보안그룹과 네트워크 ACL → 프라이빗·퍼블릭 자원 구분 → 감사 로그 활성화 → 권한 변경 이벤트 분석 → 네트워크 흐름 로그 확인 → 잘못된 설정 탐지 → 안전한 수정 → 정상 서비스 재검증 → 탐지 기준과 알림 구성 → 프로젝트 문서화 → 포트폴리오와 면접 연결
결국 클라우드 보안 직무가 일반 정보보안과 다른 핵심은 완전히 새로운 보안 원리를 사용하는 데 있지 않습니다. IAM에서는 사용자와 서비스의 권한을 세밀하게 통제하고, 네트워크에서는 가상화된 리소스 사이의 접근 경계를 설계하며, 로그에서는 API와 관리 활동까지 포함해 누가 무엇을 변경했는지를 추적해야 합니다. 이 세 영역이 하나의 프로젝트 안에서 연결되어 있다면 단순히 클라우드 보안 서비스를 사용해 본 경험을 넘어, 실제 클라우드 환경에서 접근권한과 네트워크, 변경 이력을 함께 통제할 수 있는 보안 운영 역량을 포트폴리오와 면접에서 더 구체적으로 보여줄 수 있습니다.