클라우드 보안 기초 :: IAM과 보안그룹

클라우드 보안 기초 :: IAM과 보안그룹

IAM(Identity and Access Management):  클라우드 환경에서 “누가 무엇에 접근할 수 있고, 어떤 작업을 할 수 있는지”를 관리하는 인증·인가 체계
전통적인 온프레미스 서버의 계정/권한 관리(계정과 권한 관리 노트에서 다룬 GRANT/REVOKE 개념)를 클라우드 규모에 맞게 확장한 것

왜 클라우드에서 특히 중요한가
온프레미스 서버는 물리적으로 접근이 제한되지만, 클라우드는 인터넷 어디서든 콘솔이나 API로 접근 가능
계정 하나만 뚫려도 서버, 스토리지, 네트워크, DB를 포함한 인프라 전체가 위험해질 수 있음
그래서 “이 계정이 정확히 무엇까지 할 수 있는지”를 세밀하게 통제하는 게 클라우드 보안의 출발점

기본 구성 요소

1. 사용자(User): 실제 로그인해서 콘솔이나 API를 사용하는 개별 계정
사람일 수도 있고, 자동화 스크립트가 API 호출을 위해 쓰는 계정일 수도 있음

2. 그룹(Group): 여러 사용자를 하나로 묶어서 동일한 권한을 한꺼번에 부여하는 단위
예: “개발팀” 그룹에 속한 사용자 전원에게 같은 정책을 한 번에 적용

3. 역할(Role): 특정 작업을 수행할 때만 임시로 부여하는 권한 묶음
사람뿐 아니라 서버나 서비스에도 부여 가능(예: 웹서버가 스토리지에 접근해야 할 때, 그 서버에 역할을 부여)
평소에는 권한이 없다가 필요한 순간에만 그 역할로 전환해서 작업하는 방식이라 상시 고정 권한보다 안전함

4. 정책(Policy)
“이 리소스에 이런 행동을 허용 또는 거부한다”를 정의한 문서, 보통 JSON 형식으로 작성
예: “스토리지 버킷 A에 대해 읽기만 허용, 쓰기·삭제는 거부”처럼 구체적으로 명시

5. 최소 권한 원칙(Least Privilege)
사용자나 역할에게 업무 수행에 꼭 필요한 권한만 부여하고, 그 이상은 주지 않는 원칙
시스템 보안 노트에서 이미 다룬 원칙이 클라우드 계정 관리에도 동일하게 적용되는 것
루트(관리자) 계정을 일상 업무에 그대로 쓰는 건 가장 흔하면서도 위험한 실수 — 루트 계정이 뚫리면 그 즉시 인프라 전체가 공격자 손에 넘어감
그래서 실무에서는 루트 계정은 최초 설정이나 비상시에만 쓰고, 평소에는 필요한 권한만 가진 별도 계정으로 작업하는 게 기본 수칙

6. 권한 검토와 정기 감사
시간이 지나면서 필요 없어진 권한이 계정에 그대로 남아있는 경우가 많음(권한 크리프, Permission Creep)
정기적으로 각 계정이 실제로 어떤 권한을 갖고 있는지 점검해서, 안 쓰는 권한은 회수하는 게 중요
이건 SQL 실습에서 다뤘던 SHOW GRANTS로 계정 권한을 주기적으로 점검하는 것과 같은 맥락

보안그룹(Security Group):  클라우드에서 가상서버(인스턴스) 단위로 적용하는 방화벽
어떤 IP, 어떤 포트, 어떤 프로토콜의 트래픽을 허용하거나 차단할지 규칙으로 정의

동작 원리: iptables의 방화 filtering 개념과 동일 — 허용 규칙과 차단 규칙으로 트래픽을 통제
차이점은 iptables는 서버 안에서 직접 명령어로 설정하지만, 보안그룹은 클라우드 콘솔이나 API를 통해 그 서버 바깥(네트워크 경계)에서 관리한다는 점
그래서 보안그룹은 서버 자체가 뚫리기 전에 트래픽을 걸러내는 한 겹 더 앞선 방어선 역할을 함

기본 구성
1. 인바운드(Inbound) 규칙: 외부에서 이 서버로 들어오는 트래픽을 통제
2. 아웃바운드(Outbound) 규칙: 이 서버에서 외부로 나가는 트래픽을 통제
각 규칙은 프로토콜(TCP/UDP), 포트 범위, 허용할 출발지(또는 목적지) IP 대역으로 구성됨

기본 원칙: 화이트리스트 방식
기본값은 전부 차단, 필요한 트래픽만 명시적으로 허용
이 원칙은 iptables의 기본 정책을 DROP으로 설정하고 필요한 것만 ACCEPT하던 방식과 완전히 동일한 사고방식

주의사항
1. 0.0.0.0/0에 관리 포트를 열어두는 것
SSH(22번), 원격 데스크톱(3389번) 같은 관리용 포트를 모든 IP(0.0.0.0/0)에 허용해두는 경우
이렇게 하면 전 세계 어디서든 그 포트로 접속을 시도할 수 있게 되어, 브루트포스 노트에서 다룬 무차별 대입 공격의 표적이 되기 쉬움
올바른 설정은 본인이나 회사의 특정 공인 IP 대역만 허용하는 것

2. DB 포트를 외부에 그대로 노출하는 것
MySQL(3306번), PostgreSQL(5432번) 같은 DB 포트를 인터넷에 직접 열어두는 경우
DB는 원칙적으로 외부에 노출될 필요가 없고, 같은 네트워크 안의 웹서버 등에서만 접근 가능하게 제한해야 함 — VLAN/네트워크 분리 노트에서 다룬 “웹서버망에서 DB망으로는 필요한 포트만 허용” 원칙이 클라우드에서는 보안그룹으로 구현됨

━━━━━━━━━━━━━━━━━━

IAM과 보안그룹의 관계 정리

IAM은 “누가 이 클라우드 콘솔·API에서 무엇을 할 수 있는가”를 통제하는 계층
보안그룹은 “네트워크상에서 어떤 트래픽이 이 서버에 도달할 수 있는가”를 통제하는 계층
두 계층은 서로 다른 지점을 지키기 때문에, 하나만 잘 설정해서는 부족함 — IAM이 아무리 견고해도 보안그룹이 모든 IP에 SSH를 열어두면 공격자가 직접 로그인 시도를 무한정 할 수 있고, 반대로 보안그룹이 완벽해도 IAM 계정이 뚫리면 콘솔을 통해 우회 접근이 가능해짐