<aside>
CloudWave · W05 · 5/5 · 예상 읽기 7분
</aside>
마지막 날에는 “권한을 줄이는 것”과 “접근 경로를 줄이는 것”이 같은 문제인지 물었다. 둘은 서로 연결되지만 동일하지 않다. IAM은 누가 무엇을 할 수 있는지 정하고, VPN은 어떤 네트워크나 사용자가 어디까지 연결할 수 있는지를 정한다.
역할은 여러 주체가 필요한 순간에 맡을 수 있는 권한 경계다. 임시 자격 증명은 만료 시간이 있어 장기 키보다 회수와 노출 범위를 관리하기 쉽다. 실제 정책을 작성할 때는 필요한 action과 resource를 좁히고, 조건으로 요청 맥락을 제한한다. 자격 증명 기반 정책에는 주체가 정책을 사용하므로 Principal이 보이지 않을 수 있고, 리소스 기반 정책에는 접근을 허용할 Principal을 명시한다.
권한은 하나의 정책만으로 결정되지 않는다. 조직의 서비스 제어 정책, permission boundary, identity policy와 resource policy가 함께 제한을 만들 수 있다. Allow를 추가했는데도 호출이 거부된다면 명시적 Deny와 상위 경계를 먼저 확인한다. 공개 문서에는 계정 ID, ARN, 키, 내부 주소를 남기지 않는다.
CloudTrail은 API 활동 기록을 남겨 누가 어떤 작업을 요청했는지 추적하는 데 도움을 준다. Local과 Dev에서는 개발 속도를 고려하더라도 공유 자원 접근을 분리하고, QA와 Staging에서는 운영과 유사한 권한 흐름을 검증한다. Production은 승인, 세션 수명, 로그 보존, 비상 접근과 회수 절차를 별도로 둔다. AI 페이지에서 확인한 환경 구분은 이 권한·접근 맥락 안에서만 의미가 있다.
Site-to-Site VPN은 온프레미스 네트워크와 VPC처럼 네트워크 대 네트워크를 연결한다. 반면 Client VPN은 개별 사용자 단말이 인증을 거쳐 사설 자원에 접근하는 용도다. 둘 다 암호화된 터널을 사용하지만 대상과 라우팅 범위, 사용자 인증 방식이 다르다.
Transit Gateway는 여러 VPC와 네트워크 연결을 중앙에서 묶는 구조를 만들 수 있지만, 연결이 많아질수록 라우팅 테이블과 비용, 장애 범위를 함께 검토해야 한다. 실습에서 터널이 만들어졌다는 사실만으로 운영의 고가용성이나 보안 기준이 충족되는 것은 아니다.
배포 파이프라인은 역할을 통해 artifact를 읽고 대상 환경에 필요한 변경만 수행하게 한다. 운영 접근은 Client VPN 또는 승인된 경로로 제한하고, 네트워크 간 연결은 Site-to-Site VPN의 목적에 맞게 분리한다. 정책 변경 전후에는 감사 로그와 실패 시 복구 방법을 확인한다.
role은 권한을 자동으로 넓혀 주는 기능이 아니며, VPN은 IAM을 대체하지 않는다. Site-to-Site VPN을 사용자 원격 접속과 같은 말로 쓰면 라우팅과 감사 설계가 달라진다. 최소권한은 한 번 정하고 끝나는 값이 아니라 사용 패턴과 변경을 다시 검토하는 과정이다.
최소권한과 VPN은 각각 권한의 범위와 네트워크의 범위를 줄여 안전한 흐름을 만든다.