Amazon Virtual Private Cloud (VPC)
VPC는 아마존 리소스를 논리적으로 분리하여 관리할 수 있는 가상의 격리된 네트워크다. VPC에는 서브넷이 존재하는데, 원하는 목적에 따라 AWS 리소스를 Public 서브넷과 Private 서브넷에 위치시켜 외부에서 오는 접근을 통제할 수 있다.
서브넷
서브넷은 IP 주소의 범위를 뜻한다. VPC에서 서브넷은 리소스를 그룹화하는 데 사용되는 별개의 영역으로 볼 수 있다. 보안 또는 운영 요구 사항에 따라 리소스를 그룹화할 수 있는 VPC 내의 한 섹션이다.
| 퍼블릭 서브넷 | 프라이빗 서브넷 |
|---|---|
| 온라인 상점의 웹 사이트와 같이 누구나 액세스할 수 있어야 하는 리소스를 포함 | 고객의 개인 정보 및 주문 내역이 포함된 데이터베이스와 같이 프라이빗 네트워크를 통해서만 액세스할 수 있는 리소스를 포함 |
VPC 내에서 서브넷은 서로 통신할 수 있다. 예를 들어 퍼블릭 서브넷에 있는 Amazon EC2 인스턴스가 프라이빗 서브넷에 있는 데이터베이스와 통신하는 애플리케이션이 있을 수 있다.
인터넷 게이트웨이
공개 인터넷 트래픽이 VCP를 출입하도록 허용하려면 인터넷 게이트웨이 즉 IGW를 VPC에 연결해야 한다. 인터넷 게이트웨이는 공개된 출입구와 같다. 인터넷 게이트웨이가 없다면 그 누구도 VPC 안에 있는 리소스에 접근할 수 없다.
가상 프라이빗 게이트웨이
외부에 공개할 수 없는 리소스만 있는 VPC의 경우 인터넷 게이트웨이를 연결하면 안 된다. 승인된 네트워크에서 오는 트래픽만 허용해야 하는 프라이빗 게이트웨이가 필요하다. 이러한 비공개 출입구를 가상 프라이빗 게이트웨이라고 한다.
가상 프라이빗 게이트웨이는 보호된 인터넷 트래픽이 VPC로 들어오도록 허용하는 구성 요소다. 승인된 트래픽의 접근을 허용하고는 있지만, 다른 일반 트래픽과 동일한 대역폭을 공유하고 있기 때문에 속도 저하가 발생할 수 있다.
AWS Direct Connect
데이터 센터와 VPC 간에 비공개 전용 연결을 설정하는 서비스이다. 위에서 가상 프라이빗 게이트웨이를 사용하더라도 보호되고 있는 트래픽이 일반 트래픽과 동일한 대역폭을 공유하고 있어 속도 저하 문제가 있다고 언급했다.
하지만 AWS Direct Connect을 사용하면 승인된 트래픽만 다닐 수 있는 전용 연결을 만들 수 있다. 때문에 네트워크 비용을 절감하고 네트워크를 통과할 수 있는 대역폭을 늘리는 데 도움이 된다.
VPC의 네트워크 트래픽
고객이 AWS 클라우드에서 호스팅되는 애플리케이션에 데이터를 요청하면 이 요청은 패킷으로 전송된다. 패킷은 인터넷 게이트웨이를 통해 VPC로 들어간다. 이후 패킷이 서브넷으로 들어가거나 서브넷에서 나오려면 권한을 확인해야 한다. 서브넷의 패킷 권한을 확인하는 VPC 구성 요소를 네트워크 액세스 제어 목록(ACL)이라고 한다.
네트워크 ACL
네트워크 ACL은 서브넷 수준에서 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽이다.
네트워크 ACL을 공항에 빗대어 설명하면 쉽게 이해할 수 있다. 출입국을 하려는 여행자를 패킷, 출입국 심사 직원을 네트워크 ACL라고 하자.
출입국 심사 직원은 여행자가 출입국할 때 여행자의 신원 정보를 확인한다. 여행자가 승인 목록에 있으면 심사를 통과할 수 있다. 그러나 승인 목록에 없거나 금지 목록에 명시된 여행자는 출입국을 거절당한다.
이처럼 서브넷 경계를 오가는 패킷은 모두 네트워크 ACL의 검사를 받는다.
각 AWS 계정에는 기본 네트워크 ACL이 포함된다. VPC를 구성할 때 계정의 기본 네트워크 ACL을 사용하거나 사용자 지정 네트워크 ACL을 생성할 수 있다.
계정의 기본 네트워크 ACL은 기본적으로 모든 인바운드 및 아웃바운드 트래픽을 허용하지만 사용자가 자체 규칙을 추가하여 수정할 수 있다. 사용자 지정 네트워크 ACL은 사용자가 허용할 트래픽을 지정하는 규칙을 추가할 때까지 모든 인바운드 및 아웃바운드 트래픽을 거부한다.
Stateless Packet 필터링
네트워크 ACL은 Stateless Packet 필터링을 수행한다. 즉, 이전에 네트워크 ACL에 의해 서브넷 경계를 통과한 것을 기억하지 못 하기 때문에 서브넷 경계를 지나는 모든 패킷을 확인한다.
앞서 예로 든 다른 국가에 입국하려는 여행자를 상기해보자. 이는 Amazon EC2 인스턴스에서 인터넷으로 요청을 전송하는 것과 비슷하다.
해당 요청에 대한 패킷 응답이 서브넷으로 반환될 때 네트워크 ACL은 이전 요청을 기억하지 못한다. 네트워크 ACL은 규칙 목록에 따라 패킷 응답을 확인하여 허용 또는 거부 여부를 결정한다.
패킷이 서브넷에 들어간 후에는 서브넷 내의 리소스에 대한 권한이 평가되어야 하지만 네트워크 ACL은 리소스 레벨의 권한 평가까지는 해주지 않는다.
따라서 인스턴스 수준의 네트워크 보안도 필요한데, 패킷에서 Amazon EC2 인스턴스에 대한 권한을 확인하는 VPC 구성 요소가 바로 보안 그룹이다.
보안 그룹
보안 그룹은 Amazon EC2 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽이다.
기본적으로 보안 그룹은 모든 인바운드 트래픽을 거부하고 모든 아웃바운드 트래픽을 허용한다.
따라서 인스턴스가 프론트엔드 인스턴스나 인터넷에 보내는 메시지 같은 외부 트래픽을 수신하게 해야 할 때는 사용자 지정 규칙을 추가하여 특정 유형의 트래픽을 수락하도록 보안 그룹을 수정해야 한다.
네트워크 ACL이 여권 심사를 한다고 보면 보안 그룹은 건물의 문지기에 해당한다. 이 경우 건물은 EC2 인스턴스로 볼 수 있다. 문지기는 목록을 참조하여 건물에 들어올 수 있는 사람인지 확인하지만 사람이 나갈 때는 목록을 확인하지 않는다.
동일한 VPC 내에 여러 Amazon EC2 인스턴스가 있는 경우 동일한 보안 그룹에 연결하거나 각 인스턴스마다 서로 다른 보안 그룹을 사용할 수도 있다.
Stateful Packet 필터링
보안 그룹은 Stateful Packet 필터링을 수행한다. 즉, 들어오는 패킷에 대한 이전 결정을 기억한다.
Amazon EC2 인스턴스에서 인터넷으로 요청을 전송하는 것과 동일한 예를 생각해보자.
해당 요청에 대한 패킷 응답이 인스턴스로 반환될 때 보안 그룹이 이전 요청을 기억하기 때문에 보안 그룹은 인바운드 보안 그룹 규칙에 관계없이 응답이 진행하도록 허용한다.
보안 그룹 VS 네트워크 ACL
보안 그룹과 네트워크 ACL 간의 결정적인 차이는 상태 저장 유무이다. 즉 보안 그룹은 출입이 허용된 사람을 기억하는 반면 네트워크 ACL은 상태 비저장이기에 아무것도 기억하지 않는다. 따라서 네트워크 ACL은 상황과 무관하게 서브넷 경계를 지나는 모든 패킷을 확인하게 된다.
| 보안 그룹 | 네트워크 ACL |
|---|---|
| 인스턴스 레벨에서 운영 | 서브넷 레벨에서 운영 |
| 인스턴스와 연결된 경우에만 인스턴스에 적용 | 연결된 서브넷에서 배포된 모든 인스턴스에 적용(보안 그룹 규칙이 지나치게 허용적일 경우 추가 보안 계층 제공) |
| 허용 규칙만 지원 | 허용 및 거부 규칙 지원 |
| 트래픽 허용 여부를 결정하기 전에 모든 규칙을 평가 | 트래픽 허용 여부를 결정할 때 가장 낮은 번호의 규칙부터 순서대로 규칙을 평가 |
| 상태 저장: 규칙에 관계없이 반환 트래픽이 허용됨 | 상태 비저장: 반환 트래픽이 규칙에 따라 명시적으로 허용되어야 함 |
네트워크 ACL과 보안 그룹을 모두 사용하면 VPC에서 트래픽에 대한 사용자 지정 규칙을 구성할 수 있다.
패킷 통신 예시
A 서브넷에 있는 인스턴스 A와 B 서브넷에 있는 인스턴스 B 사이를 왕복하는 패킷에 대한 시나리오
패킷을 인스턴스 A에서 다른 서브넷에 있는 인스턴스 B로 보내보자.
인스턴스 A가 패킷을 보내면 패킷은 가장 먼저 인스턴스 A의 보안 그룹 경계에 도달하게 된다. 기본적으로 모든 아웃바운드 트래픽은 보안 그룹에서 허용되기 때문에 패킷은 인스턴스 A의 보안 그룹을 지나치게 된다.
이제 서브넷 경계를 벗어나야 한다. 이를 위해선 네트워크 ACL을 통과해야 한다. 네트워크 ACL은 통과할 수 있는 것과 없는 것에 관한 자체 목록이 있기 때문에 보안 그룹에서 허용한 항목에 대해 신경 쓰지 않는다.
네트워크 ACL을 통과한다면 원래 서브넷을 나와 패킷이 인스턴스 B가 있는 대상 서브넷으로 이동하게 된다. 이 대상 서브넷에서도 마찬가지로 네트워크 ACL을 검사를 진행한다. 패킷이 해당 서브넷의 승인 목록에 있다면 네트워크 ACL을 통해 서브넷에 들어갈 수 있다.
서브넷을 통과하게 되면 이제 인스턴스 B에 접근해야 한다. 모든 EC2 인스턴스에는 자체 보안 그룹이 있기 때문에 이 인스턴스에 들어가려면 해당 패킷이 승인 목록에 있는지 확인해야 한다. 승인 목록에 있다면 패킷이 대상 인스턴스에 도달하게 된다.
거래가 완료되면 이제 원래 있던 곳으로 돌아가야 하는데, 이를 반환 트래픽 패턴이라고 한다. 이때 서로 다른 엔진의 상태 저장과 상태 비저장 특성을 확인할 수 있다.
패킷이 돌아가는 중에도 여전히 각 체크포인트에서 패킷을 평가해야 하기 때문이다.
보안 그룹은 기본적으로 모든 반환 트래픽을 허용하기 때문에 다른 검사를 하지 않는다. 하지만 네트워크 ACL은 상태를 기억하지 않기 때문에 패킷이 이곳에 들어왔다는 사실을 신경 쓰지 않는다. 따라서 경계를 지나려면 패킷 반송 주소가 승인 목록에 있어야 한다. 이어서 원래 서브넷의 경계에 도달해서도 네트워크 ACL의 검사를 거쳐야 한다.
이를 통해 상태 비저장 제어란 곧 목록을 항상 확인해야 한다는 것을 의미한다는 걸 알 수 있다.
패킷이 서브넷 수준인 네트워크 ACL을 통과하고 나면 인스턴스 A의 보안 그룹을 거쳐야 한다. 하지만 보안 그룹은 상태를 저장하기 때문에 과거에 지나갔던 패킷을 알아본다. 따라서 허용 대상인지 확인할 필요가 없다. 패킷은 승인 목록을 검사하지 않고 인스턴스 A로 무사히 돌아왔다.
IAM을 이용한 보안
사용자가 사용자 이름 및 암호, MFA, 액세스 키 등을 통해 AWS에 로그인하는 과정을 인증(Authentication)이라고 한다. 하지만 인증에 성공했다고 해서 리소스를 마음대로 관리할 수 있는 것은 아니다. 리소스를 생성, 수정, 삭제하는 작업은 AWS Management Console, CLI 또는 API 호출을 통해 수행되며 이러한 작업은 IAM 정책(Policy)에 의해 제어된다. 만약 사용자에게 해당 작업을 수행할 수 있는 권한이 IAM 정책에 명시되어 있지 않다면, 해당 사용자는 리소스에 대한 작업이 거부된다.
인증과 권한 부여의 차이점을 이해하면 AWS에서 수행하는 작업의 성능과 보안을 개선할 수 있다.
User Group Role 정의 자격 증명이 영구적인 작업자(사람 / 기계) User 모음 자격 증명이 일시적인 작업자(사람 / 기계) 특징 사용자는 여러 그룹에 속할 수 있다. 그룹은 여러 사용자를 포함할 수 있다. IAM에서 Role은 권한이 아니라 인증 방법이다. 권한은 모든 경우에 IAM 정책(Policy)라는 별개의 객체에서 발생한다.
AWS Identity and Access Management(IAM)
IAM은 회사의 고유한 운영 및 보안 요구 사항에 따라 액세스 권한을 구성할 수 있는 유연성을 제공한다. 이 작업을 수행하기 위해 다음과 같은 IAM 기능을 조합하여 사용할 수 있다.
- IAM 사용자, 그룹 및 역할
- IAM 정책
- 다중 인증(MFA)
AWS 계정 루트 사용자
AWS 계정을 처음 만들면 루트 사용자라고 하는 자격 증명으로 시작한다.
루트 사용자는 AWS 계정을 만들 때 사용한 이메일 주소 및 암호로 로그인하여 액세스한다. 이 사용자는 계정의 모든 AWS 서비스 및 리소스에 대한 전체 액세스 권한을 가진다.
💡 모범 사례:
일상 작업에는 루트 사용자를 사용하면 안 된다.
대신 루트 사용자를 사용하여 첫 번째 IAM 사용자를 생성하고 이 사용자에게 다른 사용자를 생성할 수 있는 권한을 할당한다. 다른 IAM 사용자를 생성하거나 AWS 전체에서 일상 작업을 수행할 때는 해당 IAM 자격 증명에 액세스해야 한다.
루트 사용자만 사용할 수 있는 제한된 종류의 작업을 수행해야 하는 경우에만 루트 사용자를 사용해라. 이러한 작업에는 루트 사용자 이메일 주소 변경, AWS Support 플랜 변경 등이 있다.
IAM 사용자
IAM 사용자는 사용자가 AWS에서 생성하는 자격 증명이다. IAM 사용자는 AWS 서비스 및 리소스와 상호 작용하는 사람 또는 애플리케이션을 나타낸다. 이 사용자는 이름과 자격 증명으로 구성된다.
기본적으로 AWS에서 새 IAM 사용자를 생성하면 해당 사용자와 연결된 권한이 없다. IAM 사용자가 AWS에서 Amazon EC2 인스턴스 시작, Amazon S3 버킷 생성 등 특정 작업을 수행할 수 있도록 허용하려면 IAM 사용자에게 필요한 권한을 부여해야 한다.
💡 모범 사례:
AWS에 액세스해야 하는 각 사용자마다 개별 IAM 사용자를 생성하는 것이 좋다.
동일한 수준의 액세스가 필요한 직원이 여러 명이라도 각 직원마다 개별 IAM 사용자를 생성해야 한다. 그러면 각 IAM 사용자가 고유한 보안 자격 증명 집합을 갖도록 허용하여 보안을 강화할 수 있다.
IAM 정책
IAM 정책은 AWS 서비스 및 리소스에 대한 권한을 허용하거나 거부하는 문서다.
IAM 정책을 사용하면 사용자가 리소스에 액세스할 수 있는 수준을 사용자 지정할 수 있다. 예를 들어 사용자가 AWS 계정 내의 모든 Amazon S3 버킷에 액세스하거나 특정 버킷에만 액세스하도록 허용할 수 있다.
💡 모범 사례:
권한을 부여할 때 최소 권한 보안 원칙을 따라야 한다.
이 원칙을 따르면 사용자 또는 역할이 해당 작업을 수행하는 데 필요한 것보다 많은 권한을 갖는 것을 방지할 수 있다.
예를 들어 직원이 특정 버킷에만 액세스해야 하는 경우 이 직원에게 AWS 계정의 모든 버킷에 액세스할 수 있는 권한을 부여하는 대신 IAM 정책에서 해당 버킷을 지정한다.
예: IAM 정책
다음은 IAM 정책이 작동하는 방식의 예다. 커피숍 점주가 새로 채용한 계산원을 위해 IAM 사용자를 생성해야 한다고 가정해 보자. 이 계산원은 ID가 AWSDOC-EXAMPLE-BUCKET인 Amazon S3 버킷에 저장된 영수증에만 액세스하면 된다.
이 예제의 IAM 정책은 ID가 AWSDOC-EXAMPLE-BUCKET인 S3 버킷의 특정 작업을 허용하는 정책이다.
점주가 계산원의 IAM 사용자에 이 정책을 연결하면 해당 계산원은 AWSDOC-EXAMPLE-BUCKET 버킷의 모든 객체를 볼 수 있다.
계산원이 AWS에서 다른 서비스에 액세스하여 다른 작업을 수행할 수 있도록 허용하려면 점주는 추가 정책을 연결하여 위와 같은 서비스 및 작업을 지정해야 한다.
만약 커피숍에서 계산원을 몇 명 더 채용한다고 하면 점주는 개별 IAM 사용자 각각에 권한을 할당하는 대신 사용자를 IAM 그룹에 배치하게 된다.
IAM 그룹
IAM 그룹은 IAM 사용자의 모음이다. 그룹에 IAM 정책을 할당하면 해당 그룹의 모든 사용자에게 정책에 지정된 권한이 부여된다.
다음은 커피숍에서 이 정책 할당이 작동하는 방식의 예입이다.
점주는 계산원마다 권한을 할당하는 대신 '계산원' IAM 그룹을 생성할 수 있다. 그런 다음 이 그룹에 IAM 사용자를 추가하고 그룹 수준에서 권한을 연결할 수 있다.
그룹 수준에서 IAM 정책을 할당하면 직원이 직무를 전환하는 경우 권한을 손쉽게 조정할 수 있다. 예를 들어 계산원이 인벤토리 담당자가 되는 경우 커피숍 점주는 해당 계산원을 '계산원' IAM 그룹에서 제거하고 '인벤토리 전문가' IAM 그룹에 추가할 것이다. 그러면 각 직원이 현재 역할에 필요한 권한만 갖게 된다.
커피숍 직원이 영구적인 직무 전환 없이 여러 워크스테이션을 순환하는 경우에는 IAM 역할을 통해 필요한 액세스 권한을 얻을 수 있다.
IAM 역할
IAM 역할은 임시로 권한에 액세스하기 위해 수임할 수 있는 자격 증명이다.
IAM 사용자, 애플리케이션 또는 서비스가 IAM 역할을 수임하려면 먼저 해당 역할로 전환할 수 있는 권한을 부여받아야 한다. IAM 역할을 수임한다는 것은 이전 역할에 지정된 모든 이전 권한을 포기하고 새 역할에 지정된 권한을 수임하는 것이다.
예를 들어 커피숍에서 한 직원이 하루 종일 여러 워크스테이션을 순환한다고 가정하자. 커피숍의 인력 상황에 따라 이 직원은 금전 등록기 작업, 인벤토리 시스템 업데이트, 온라인 주문 처리 등 여러 가지 직무를 수행할 수 있다.
직원이 다른 직무로 전환해야 할 경우 한 워크스테이션에 대한 액세스 권한을 포기하고 다음 워크스테이션에 액세스해야 한다. 이 직원은 여러 워크스테이션 사이를 쉽게 전환할 수 있지만 단일 워크스테이션에만 액세스할 수 있다.
이처럼 IAM 역할은 서비스 또는 리소스에 대한 액세스 권한을 장기적이 아니라 일시적으로 부여해야 하는 상황에서 사용한다.
Reference
