기본 VPC

각 AWS 계정에는 즉시 사용 가능하도록 미리 구성된 기본 VPC가 포함되어 있습니다. 기본 VPC를 사용하면 블로그나 간단한 웹 사이트 등을 빠르게 시작할 수 있으며 퍼블릭 인스턴스도 쉽게 시작할 수 있습니다.

기본 VPC는 /16의 CIDR를 가지고 있고 기본 서브넷은 /20의 CIDR를 가지고 있습니다. 

탄력적 IP(EIP)

탄력적 IP 주소는 동적 클라우드 컴퓨팅을 위해 설계된 정적 퍼블릭 IPv4 주소입니다. 계정의 어떤 VPC에 대해서든 탄력적 IP 주소를 인스턴스 또는 네트워크 인터페이스와 연결할 수 있습니다. 탄력적 IP 주소를 사용하면 주소를 VPC의 다른 인스턴스에 신속하게 다시 매핑하여 인스턴스의 장애를 마스킹할 수 있습니다.

예를 들어 인스턴스의 퍼블릭 IP는 중지 후 다시 켜지면 다른 퍼블릭 IP가 지정됩니다. 때문에 이와 연결된 정보를 변경해야 하는 번거로움이 있습니다. 이럴 때 EIP를 적용해 재시작하더라도 동일한 IP가 적용되도록 해줄 수 있습니다.

하나의 인스턴스에서 다른 인스턴스로 EIP를 이전할 수 있습니다. EIP 주소는 VPC의 인터넷 게이트웨이를 통해 액세스 할 수 있습니다. VPC와 네트워크 간에 VPN 연결을 설정한 경우 VPN 트래픽은 인터넷 게이트웨이가 아닌 가상 프라이빗 게이트웨이를 통과하기 때문에 EIP  주소를 액세스 할 수 없습니다.

EIP는 5개로 제한됩니다. 이를 절약하기 위해 NAT 디바이스를 사용할 수 있습니다. 인스턴스 장애 발생 시 주소를 다른 인스턴스로 다시 매핑할 수 있도록 주로 탄력적 IP 주소를 사용하는 것이 좋습니다. 그 외의 ㅁ ㅗ든 노드 간 통신에는 도메인 이름 시스템(DNS) 호스트 이름을 사용합니다.

고유 IP 주소 가져오기(BYOIP)를 만들 수 있지만 여기에는 상당한 추가 구성이 필요합니다.

탄력적 네트워크 인터페이스

탄력적 네트워크 인터페이스는 VPC 에서 가상 네트워크 카드를 나타내는 논리적 네트워킹 구성 요소입니다.

EC2에서는 네트워크 인터페이스를 생성하여 인스턴스에 연결할 수 있으며 인스턴스에서 해당 인터페이스를 분리한 후 다른 인스턴스에 연결할 수도 있습니다. 새 인스턴스로 이동하면 네트워크 인터페이스의 퍼블릭 및 EIP 주소, 프라이빗 IP 및 EIP 주소, MAC 주소가 유지됩니다. 네트워크 인터페이스의 속성은 이를 따릅니다.

네트워크 인터페이스를 인스턴스 간에 이동하면 네트워크 트래픽이 새 인스턴스로 리디렉션 됩니다. VPC의 각 인스턴스에는 프라이머리 네트워크 인터페이스가 있습니다.

각 인스턴스에는 VPC의 IP 주소 범위에서 프라이빗 IP 주소가 할당됩니다. 프라이머리 네트워크 인터페이스는 인스턴스에서 분리할 수 없습니다. 추가 네트워크 인터페이스를 생성하여 연결할 수 있습니다. 다음 태스크를 수행하려는 경우 인스턴스 하나에 여러 네트워크 인터페이스를 연결하면 유용합니다.

• 관리 네트워크 생성
• VPC에서 네트워크 및 보안 어플라이언스 사용
• 워크로드 또는 역할이 서로 다른 서브넷에 있는 이중 홈 인스턴스 생성
• 저비용 고가용송 솔루션 생송

특정 서브넷의 네트워크 인터페이스를 같은 VPC 내 다른 서브넷의 인스턴스에 연결할 수 있습니다. 단, 이경우 두 네트워크 인터페이스와 인스턴스가 같은 가용 영역에 있어야 합니다. 이 제한으로 인해 다른 가용 영역으로 트래픽을 리디렉션 하려는 재해 복구(DR) 시나리오에서는 네트워크 인터페이스 사용 가능 범위가 제한됩니다.

NAT 게이트웨이를 통한 Network Address Translation(NAT)

NAT에서는 메시지의 특정 IP 주소가 다른 주소에 매핑됩니다. 사용되는 IP 주소 보호를 위해 NAT를 사용합니다. NAT에서는 프라이빗 IP 주소가 퍼블릭 IP 주소에 매핑되므로 NAT를 사용하면 프라이빗 IP 주소의 인터넷연결을 허용할 수 있습니다. 라우터 등의 단일 디바이스를 인터넷(퍼블릭 네트워크)과 로컬 네트워크(프라이 빗네트워크) 간의 에이전트로 사용할 수 있습니다.

NAT 게이트웨이를 통해 VPC의 인스턴스와 인터넷 간에 통신을 할 수 있습니다. NAT 게이트웨이는 기본적으로 수평적으로 확장되고 중복되며 가용성이 높습니다. NAT 게이트웨이는 서브넷 라우팅 테이블에서 인터넷 라우팅 가능한 트래픽에 대한 대상을 제공합니다.

• 프라이빗 서브넷의 인스턴스는 인터넷 또는 다른 AWS 서비스로의 아웃 바운드트래픽을 시작할 수 있습니다.
• AWS가 관리하는 NAT 게이트웨이 사용 시에는 프라이 빗인스턴스가 인터넷에서 전송되는인바운드 트래픽을 수신할 수 없습니다.

NAT 게이트웨이는 퍼블릭 서브넷과 프라이빗 서브넷에 모두 배치할 수 있습니다. NAT 게이트웨이를 더 많이 제어해야 하는 경우 EC2 인스턴스에 NAT 게이트웨이를 설치하여 NAT 인스턴스를 생성할 수 있습니다. 또한 CIDR 범위가 겹치더라도 프라이빗 NAT 게이트웨이를 사용하여 네트워크 간 통신을 원활하게 진행할 수 있습니다.

인터넷에 프라이빗 서브넷 연결

프라이빗 서브넷 인스턴스와 인터넷 또는 기타 AWS 서비스 간의 단방향 연결에 NAT 게이트웨이를 사용할 수 있습니다. 이러한 유형의 연결에서는 외부 트래픽이 프라이빗 인스턴스와 연결될 수 없습니다.

• 프라이빗 서브넷용 라우팅 테이블은 모든 IPv4 인터넷 트래픽을 NAT 게이트웨이로 전송합니다.
• NAT 게이트웨이는 프라입시 서브넷에서 전송되는 트래픽용 소스 IP 주소로 탄력적 IP 주소를 사용합니다.
• 퍼블릭 서브넷용 라우팅 테이블은 몯느 인터넷 트래픽을 인터넷 게이트웨이로 전송합니다. IPv6에서는 지원하지 않는 기능입니다.

여러 가용 영역에서 VPC 배포

여러 가용 영역에 VPC를 배포하면 생성되는 아키텍처에서는 데이터 보안을 유지하면서 트래픽을 분사하는 방식으로 고가용성이 보장됩니다. 가용 영역 하나의 작동이 중단되면 다른 가용 영역으로 장애 조치할 수 있습니다.

이 구조를 통해 인스턴스에 접근은 가능하지만 인스턴스의 IP를 알 수는 없습니다. 이와 같이 인스턴스나 DB같은 중요 서비스들은 프라이빗 존에 배치하고 외부에서 접근만 가능하도록 아키텍처를 구성하는 것이 바람직합니다. 로드 벨런서에 대해서는 차후에 자세히 알아보도록 하겠습니다.

AWS VPC(Virtual Private Cloud)

Amazon VPC는 클라우드의 네트워크 환경입니다. 이를 통해 사용자가 정의한 가상 네트워크 안에서 AWS 리소스를 시작할 수 있습니다. VPC는 AWS 리전 중 하나에 배포되며, 해당 리전 내의 어떤 가용 영역에서나 리소스를 호스트할 수 있습니다.

VPC는 다음과 같은 사용자 환경과 해당 리소스의 격리에 대한 제어 기능을 제공합니다. VPC로 다음과 같은 작업을 수행할 수 있습니다.

• 원하는 IP 주소 범위 선택
• 서브넷 생성
• 라우팅 테이블과 네트워크 게이트웨이 구성

VPC 상세 내용

서브넷

서브넷은 VPC 내의 IP 범위입니다. 지정된 서브넷으로 AWS 리소스를 시작할 수 있습니다. 인터넷에 연결되어야 하는 리소스에는 퍼블릭 서브넷을 사용하고, 인터넷에 연결되지 않는 시소스에는 프라이빗 서브넷을 사용해야 합니다. 서브넷은 하나의 가용 영역 안에 포함됩니다.

각 서브넷  CIDR 블록에서 처음 4개와 마지막 IP 주소는 사용할 수 없습니다. 이에 대한 내용은 이전 포스팅에서 확인할 수 있습니다.

퍼블릭 서브넷(Public Subnet)

퍼블릭 서브넷 구성에는 양방향(초대됨/초대되지 않음)으로 트래픽 흐름을 허용합니다. 자동 아웃바운드 라우팅은 적용되지 않으므로 서브넷은 퍼블릭으로 구성해야 합니다.

퍼블릭 서브넷에 필요한 항목은 다음과 같습니다.

• 인터넷 게이트웨이(IG, Internet Gateway): VPC의 리소스와 인터넷 간 통신을 허용합니다.
• 라우팅 테이블(Route Table): 네트워크 트래픽이 전달되는 위치를 결정하는 데 사용되는 규칙(경로) 집합을 포함합니다. 인터넷 게이트웨이로 트래픽을 전송할 수 있습니다.
• 퍼블릭 IP 주소: 인터넷에 액세스 할 수 있는 주소입니다. 퍼블릭 IP 주소 사용 시에는 프라이빗 IP 주소를 모호화할 수 있습니다.

모호화는 어떤 것을 흐리게 하거나, 불명확하게 만드는 것을 말합니다. 퍼블릭 IP 주소를 사용하면 프라이빗 IP 주소를 모호화할 수 있습니다. 즉, 퍼블릭 IP 주소로 프라이빗 IP 주소에 접근할 수 있지만, 프라이빗 IP 주소를 직접 알 수는 없습니다.

프라이빗 서브넷(Private Subnet)

프라이빗 서브넷은 인터넷 간접적으로 액세스를 허용합니다. 트래픽은 프라이빗 네트워크 내에 유지됩니다. EC2(Elastic Compute Cloud) 인스턴스의 네트워크 인터페이스에 새 IP 주소를 수동을 ㅗ배정하는 경우가 아니면 해당 EC2 인스턴스에 배정된 프라이빗 IP 주소는 변경되지 않습니다.

웹 티어 인스턴스는 퍼블릭 서브넷에 배치할 수 있습니다. 하지만 퍼블릭 서브넷에 배치된 로드 밸런서를 기반으로 프라이빗 서브넷 내에 웹 티어 인스턴스를 배치하는 것이 좋습니다. 즉, 서비스는 모두 프라이빗 공간에서 작동시키고 다른 수단을 사용해 연결해주는 것입니다.

인터넷 게이트웨이(Internet Gateway)

인터넷 게이트웨이(이하 IG)는 수평적으로 확장되고 중복적인 고가용성 VPC 구성 요소로, VPC 내 인스턴스와 인터넷 간 통신을 허용합니다. 따라서 네트워크 트래픽에 가용성 위험이나 대역폭 제약이 발생하지 않습니다.

* 수평적 확장?
IG의 용량을 늘리기 위해 IG의 수를 늘리는 것을 말합니다. IG가 수평적으로 확장되기 때문에, VPC의 트래픽이 증가하더라도 IG의 용량을 쉽게 늘릴 수 있습니다.

* 고가용성?
IG가 장애가 발생하더라도 계속 작동할 수 있도록 IG를 여러 개로 복제하는 것을 말합니다. IG가 고가용성을 갖추고 있기 때문에, IG 중 하나가 장애가 발생하더라도 다른 IG가 계속 작동하여 VPC의 가용성을 유지할 수 있습니다.

IG는 다음 2 가지 목적을 위해 사용됩니다.

1. 인터넷 라우팅 가능 트래픽용(인터넷으로 향하는 트래픽)으로 라우팅 테이블에서 대상 제공합니다.

서브넷은 기본적으로 아웃바운드 트래픽을 허용하지 않습니다. VPC는 라우팅 테이블을 사용하여 트래픽을 라우팅할 위치를 결정합니다. VPC가 인터넷 트래픽을 라우팅하도록 허용하려면 인터넷 게이트웨이를 대상 또는 대상 위치로 지정하여 라우팅 테이블에 아웃바운드 경로를 생성합니다.

2.  NAT를 수행하여 네트워크 IP 주소 보호

인터넷에 연결하는 네트워크의 리소스는 두 가지 종류의 IP 주소를 사용해야 합니다.

• 프라이빗 IP: 프라이빗 네트워크 내의 통신에는 프라이빗 IP를 사용합니다. 이러한 주소는 인터넷을 통해 연결할 수 없습니다.
• 퍼블릭 IP:  VPC의 리소스와 인터넷 간의 통ㅅ니에는 퍼블릭 IP 주소를 사용합니다. 퍼블릭 IP 주소는 인터넷을 통해 연결할 수 있습니다.

NAT?
NAT는 Network Address Translation의 약자로, 네트워크 주소 변환을 의미합니다. NAT는 하나의 공인 IP 주소를 여러 개의 사설 IP 주소로 변환하여 사용하는 기술입니다.

인터넷 게이트웨이는 퍼블릭 IP 주소와 프라이빗 IP 주소를 매핑하여 NAT를 수행합니다. 

라우팅 테이블

라우팅 테이블은 VPC가 네트워크 트래픽이 전달되는 위치를 결정하는 데 사용되는 규칙 세트(경로)를 포함합니다. VPC를 생성하면, 자동으로 기본 라우팅 테이블이 생성됩니다. 처음에는 기본 라우팅 테이블에 단일 경로만 포함돼 있습니다. 이 로컬 경로는 VPC 내의 모든 리소스에 대해 통신을 허용합니다. 라우팅 테이블의 로컬 경로는 수정할 수 없습니다. VPC에서 인스턴스를 시작할 때마다 로컬 경로는 그 인스턴스를 자동으로 포함합니다. VPC에 대한 사용자 지정 라우팅 테이블을 추가로 생성할 수 있습니다.

VPC 내의 각 서브넷은 라우팅 테이블과 연결되어야 합니다. 서브넷을 특정 라우팅 테이블과 명시적으로 연결하지 않는 경우, 서브넷은 암시적으로 기본 라우팅 테이블과 연결되어 이를 사용합니다. 서브넷은 한 번에 하나의 라우팅 테이블에만 연결할 수 있지만, 여러 서브넷을 같은 라우팅 테이블에 연결할 수 있습니다. 각 서브넷에 대한 사용자 지정 라우팅 테이블을 사용하여 대상 위치에 대해 세부적인 라우팅을 허용합니다.

상세한 내용

IP 주소

IP 주소는 네트워크 내의 리소스 로케이션에 대한 정보를 포함합니다. 주소의 한 부분은 네트워크를 식별하고 다른 부분은 호스트를 식별합니다.

예시 - 172.50(네트워크 식별).2.15(호스트 로케이션 식별)

IP 주소에는 IPv4와 IPv6가 있습니다.

• IPv4
  32비트의 주소 체계를 사용합니다. 8개의 비트(옥텟) 집합을 4개를 사용합니다.
  [Ex_10.10.10.10]
  
  
• IPv6
  IPv4의 개수가 부족해 개발된 주소입니다. 128비트 주소 체계를 사용합니다. 16진수 숫자 4개로 구성된 8개의 그룹으로 사용합니다. 보통 자동으로 부여해 사용합니다.
  [Ex_50b2:6400:0000:0000:0000:6c3a:b17d:0:10a9  =  50b2:6400::6c3a:b17d:0:10a9]

CIDR(Classless Inter-Domain Routing)

CIDR 표기법에 따라 네트워크나 서브넷의 IP 주소 범위를 정의합니다. 이 범위를 CIDR 브록이라고 합니다.AWS VPC 구성 요소를 사용하여네트워크를 구축할 때 VPC와 서브넷용 CIDR 블록을 지정합니다. 네트워크의 리소스를 지원하기에 충분한 IP 주소를 할당해야 합니다. VPC에는 최대 CIDR 블록이 있을 수 있으며 CIDR 블록의 주소 범위는 중복될 수 없습니다.

CIDR 블록에서는 숫자와 점을 사용하는 표기법으로 네트워크를 식별합니다. 그리고 슬래시 표기법으로 서브넷 마스크를 지정합니다. 서브넷 마스크는 IP 주소에서 네트워크 식별 전용 부분과 호스트 IP 주소용으로 사용 가능한 부분을 정의합니다. 예를 들어 IPv4 주소에서는 32 비트가 옥텟 4개로 분할됩니다. 서브넷 마스크가 /16인 경우 첫 16비트(2옥텟)가 네트워크 식별용으로 예약되고 나머지 16비트가 호스트 식별에 사용됩니다.

블로그 초창기에 작성했던 IP 주소에 관한 포스팅 있으니 참고하면 더 도움이 될 것입니다.

CIDR에 따른 총 IP 개수는 어떻게 계산 할 수 있을까요? [2^(32-CIDR)]로 계산하면 간단하게 알 수 있습니다.

하지만 이렇게 부여된 IP를 모두 사용할 수 있는 것은 아닙니다. 다음과 같은 이유로 기본적으로 3개가 예약됩니다.

• IP의 처음 주소 : 네트워크 주소
• IP의 마지막 주소 : 네트워크 브로드캐스트 주소
• 게이트 웨이 주소(선택)

AWS에서는 다음과 같은 이유로 처음 4개와 마지막 주소, 총 5가지가 미리 예약됩니다.

• XX.XX.0.0: 네트워크 주소
• XX.XX.0.1: VPC 라우터용
• XX.XX.0.2: AWS에서 예약(DNS 서버의 IP 주소는 항상 VPC 네트워크 범위의 기본 IP 주소에 2를 더한 값입니다.)
• XX.XX.0.3: 차후 사용을 위해 AWS에서 예약
• XX.XX.0.255: 네트워크 브로드캐스트 주소(VPC에서는 브로드캐스트가 지원되지 않아 이 주소를 예약할 수 있습니다.)

Amazon VPC에서는 IPv4, IPv6를 둘 다 지원하고, CIDR 블록 크기 제한이 존재합니다. 기본적으로 IPv4를 포함해야 합니다. 즉, IPv4와 IPv6를 함께 사용해 이중 스택 VPC와 연결할 수 있지만, IPv6만 사용할 수는 없습니다. 또한 CIDR는 IPv4에서는 /28~/16 사이로 지정할 수 있고, IPv6에서는 /64로 고정됩니다.

tip. 보안에 관해 이야기할 때 보안 시스탬을 이야기 하기보다 약한 부분을 어떻게 보안을 강화했는지 이야기합니다. 보안 시스템의 테크니컬한 부분은 시스템의 능력이지 엔지니어의 능력이라고 보기 어렵습니다. 따라서 애플리케이션에서 보안이 약한 부분을 어떤 방향으로 개선했다는 방향으로 이야기 하는것이 바람직합니다.

심층 방어

심층 방어는 다중 보안 계층을 만드는 데 중점을 둔 전략입니다.

다중 보안 제어를 포함하는 심층 방어 접근 방식을 모든 계층에 적용합니다.예를 들어 네트워크 엣지,  VPC, 로드 밸런싱과 모든 인스턴스, 컴퓨팅 서비스, 운영체제, 애플리케이션, 코드에 심층 방어를 적용해야 합니다. 애플리케이션 보안 또한 인스턴스 보안 못지않게 중요하기 때문입니다.

위 예시에서 여러 사용자가 S3 버킷의 문서를 액세스를 시도합니다. 각 사용자가  AWS에 액세스하기 위해 수임하는 사용자 또는 역할에 자격 증명 기반 정책이 배정되어야 합니다. 해당 정책이 배정되면 리소스 기반 정책 계층이 차례로 적용됩니다. 사용자는 이러한 방식으로 태스크에 필요한 문서를 액세스할 수 있습니다.

자세한 설명

IAM 권한 경계

AWS에서는 IAM의 권한 경계를 지원합니다. 권한 경계는 관리형 정책을 고려하여 자격 증명 기반 정책이  IAM 엔터티에 부여할 수 있는 최대 권한을 설정하는 고급 기능입니다. 권한 경계는 필터 역할을 합니다.

엔터티의 권한 경계에 따라 엔터티는 자격 증명 기반 정책 기반 정책 및 관련 권한 경계 모두에서 모두 허용하는 작업만 수행하도록 허용합니다.

위에서 볼 수 있듯이 권한 경계를 사용하면 IAM 엔터티의 액세스 권한을 보다 세밀하게 제어할 수 있습니다. 위 그림을 예를 들어, IAM 엔터티에 특정 리소스에 대한 액세스 권한을 부여하는 정책이 있다고 가정합니다. 이 정책은 IAM 엔터티가 해당 리소스에 대한 모든 작업을 수행할 수 있도록 허용합니다. 그러나 권한 경계를 사용하여 IAM 엔터티가 해당 리소스에 대한 특정 작업을 수행하는 것을 허용하지 않을 수 있습니다.

이 기능은 특정 리소스에 대한 액세스 권한을 부여하되 특정 작업, 시간, 위치를 제한해 좀 더 새밀한 권한 조정을 위해 사용됩니다.

자세한 내용

다중 계정

조직에서 AWS 사용 범위가 확대되면 다음과 같은 이유로  다중 계정 구조를 생성해야 할 수 있습니다. (보통 조직의 크기가 커지면 커질수록 다중 계정 사용은 필수화 된다고 합니다.)

• 분류 및 검색을 위해 리소스를 그룹화
• 논리적 경계를 통해 보안 태세를 개선
• 무단 액세스가 발생할 경우 잠재적 영향을 제한
• 다양한 환경에 대한 사용자 액세스를 간편하게 관리

AWS Organuzations

상황 1. 미사용

IAM 정책은 단일 계정의 개별 보안 주체에만 적용됩니다. 또한, 제한을 적용하는 정책은 각 계정 내에서 관리를 해야합니다. 때문에 청구서 또한 여러개를 생성해야 합니다. 소규모에서는 상관이 없을 수 있으나 조직이 점점 커진다면 관리가 점점 힘들어질 것입니다.

상황 2. 사용

Organizations를 통해 계정을 조직 단위(OU)로 그룹화하여 계층 구조를 생성합니다. 서비스 제어 정책(SCP)를 통해 OU에 속한 모든 계정의 최대 권한을 제어합니다. 이런 구조를 통해 다음과 같은 이점을 얻을 수 있습니다.

• 모든 AWS 계정을 중앙에서 관리
• 모든 구성원 계정의 요금 통합 결제
• 예산, 보안 또는 규정 준수 요구 충족을 위해 계정을 계층적으로 그룹화
• 각 계정이 액세스할 수 있는 API 작업과 AWS 서비스를 중앙에서 제어 가능
• 조직 계정 내 리소스의 자동 백업을 구성 가능
• IAM 통합 및 지원
• 다른 AWS 서비스와 통합
• 전 세계에서 액세스 가능
• 최종적으로 일관된 데이터 복제
• 무료

자세한 설명

SCP

SCP는 조직의 권한을 관라히는 데 사용할 수 있는 조직 정책 유형입니다. SCP의 특징은 다음과 같습니다.

• 조직의 모든 계정에 사용 가능한 최대 권한을 중앙에서 제어합니다.
• 계정이 조직의 액세스 제어 지침을 준수하도록 보장하는 데 도움이 됩니다.
• 모든 기능이 활성화된 조직에서만 사용할 수 있습니다.

만약 조직이 통합 과금 기능만 지원한다면 SCP를 사용할 수 없습니다.

Organizations 엔터티(root, OU, 계정)에 SCP를 연결하면 가드레일이 정의됩니다. SCP는 해당 계정의 IAM 사용자와 역할이 수행할 수 있는 작업에 대한 제한을 설정합니다. 권한을 부여하려면 조직 계정 내의 리소스나 IAM 사용자에게 리소스 기반 정책 또는 자격 증명 기반 정책을 연결해야 합니다. IAM 사용자나 역할이 속한 계정이 조직의 멤버라면  SCP는 해당 사용자나 역할의 유효 권한을 제한합니다.

IAM 정책과 SCP의 상호 작용 방식

위에서 볼 수 있듯이 두 정책 유형에서 모두 명시적으로 허용되어야 액세스가 가능해집니다. 반대로 한쪽에서만 허용된 S3와 IAM 작업은 허용되지 않습니다.

SCP 자세한 내용

정책을 통한 계층형 방어

보안 주체는 콘솔, AWS API 또는 AWS CLI를 사용하려고 할 때 AWS에 요청을 보냅니다. AWS에서는 여러 리소스를 구성하여 요청 권한을 허용할지 아니면 거부할지를 결정할 수 있습니다.

 IAM 엔터티(사용자 or 역할)는 권한 경계에 따라 자격 증명 기반 정책과 권한 경계에서 모두 허용하는 작업만 수행할 수 있습니다. 이 방식을 사용하는 경우 해당 엔터티에 대해 지나치게 높은 수준의 권한이 필요한 작업을 허용하는 IAM 자격 증명 기반 정책 생성을 방지하는 계층이 추가됩니다.

이 또한 최소 권한 원칙을 준수하기 위한 방법입니다. 보안 파트는 여기서 마무리 되었습니다. AWS 아키택트에서 강조되는 부분이 제일 앞에 왔다고 하는데 AWS에서 보안 부분을 정말 중요시 하는 것 같습니다. 특히 최소 권한을 통한 보안이 과장 조금 보태서 페이지마다 나올 정도입니다.

다음은 AWS 네트워킹에 대해 다루겠습니다.

보안 정책 범주

정책은 자격 증명이나 리소스에 연결되어 해당 권한을 정의합니다. AWS는 사용자와 같은 보안 주체가 요청할 때 이런 정책을 평가합니다.

IAM 권한 경계 및 AWS Organizations 서비스 제어 정책(SCP)을 활용하여 계정에서 수행하는 작업에 대한 최대 권한을 설정할 수 있습니다. IAM 자격 증명 기반 정책과 리소스 기반 정책은 계정에서 수행하는 작업을 허용하거나 거부할 권한을 부여합니다.

AWS에서 사용 가능한 정책은 다음과 같으며 사용 빈도 순으로 나열되어 있습니다.

1. 자격 증명 기반 정책
   IAM 자격 증명에 관리형 정책과 인라인 정책을 연결합니다. 이러한 자격 증명에는 사용자, 사용자가 속한 그룹 및 역할이 포함됩니다.
   
   
2. 리소스 기반 정책
   리소스에 인라인 정책을 연결합니다. 리소스 기반 정책의 가장 일반적인 예는 S3 버킷 정책 및  IAM 역할 신뢰 정책입니다.
   
   
3. AWS Organizations SCP
   Organizations SCP를 사용해 조직 또는 조직 단위(OU)의 계정 구성원에 대한 최대 권한을 정의합니다.
   
   
4. IAM 권한 경계
   AWS에서는 IAM 엔터티의 권한 경계를 지원합니다. IAM 권한 경계를 사용하여 IAM 엔터티가 수행할 수 있는 최대 권한을 설정합니다.

자격 증명 기반 정책

자격 증명 기반 정책은 다음 항목을 제어하는 JSON 권한 정책 문서입니다.

• IAM 자격 증명(사용자, 사용자 그룹 및 역할)dl tngodgkf tn dLTsms wkrdjq
• IAM 자격 증명이 이러한 작업을 수행할 수 있는 리소스
• IAM 자격 증명이 이러한 작업을 수행할 수 있는 조건

자격 증명 기반 정책 유형

• 관리형 정책
  AWS 계정의 여러 사용자, 그룹 및 역할에 연결할 수 있는 독립 실행형 자격 증명 기반 정책으로, 두 가지 유형의 관리형 정책이 있습니다.
  1. AWS 관리형 정책
     AWS에서 생성하고 관리하는 관리형 정책입니다. 특정 서비스 액세스 또는 작업 기능에 대한 권한을 제공하도록 구축되었습니다.
  2. 고객 관리형 정책
     고객이 AWs 계정에서 생성하고 관리하는 관리형 정책입니다. 고객 관리형 정책은 AWs 관리형 정책보다 더 정밀하게 정책을 제어합니다.
• 인라인 정책
  단일 사용자, 그룹 또는 역할에 직접 추가하는 정책입니다. 인라인 정책은 정책과 엔터티 간에 엄격한 일대일 관계를 유지합니다. 즉, 자격 증명을 삭제하면 인라인도 삭제됩니다.
  
  인라인 정책은 사용자가 생성하여 IAM 그룹, 사용자 또는 역할에 직접 포함하는 정책입니다. 인라인 정책은 다른 자격 증명에 재사용하거나 해당 정책이 존재하는 자격 증명 외부에서 관리할 수 없습니다.

고객 관리형 정책 자세한 내용(IAM 보안 모범 사례)

자격 증명 기반 정책 예제

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AttachVolume",
                "ec2:DetachVolume"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:volume/*",
                "arn:aws:ec2:*:*:instance/*"
            ],
            "Condition": {
                "ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
            }
        }
    ]
}

• Version
  정책을 처리하는 데 사용할 언어 구문 규칙을 지정합니다. 사용 가능한 모든 정책 기능을 사용하려면 정책 버전에 위와 같이 2012-10-17 값을 삽입해줍니다.
• Effect
  Allow 또는 Deny를 사용해 정책이 액세스를 허용할지 거부할지를 지정해줄 수 있습니다.
• Action(또는 NotAction)
  정책이 허용하거나 거부하는 작업 목록을 포함합니다.
• Resource(또는 NotResource)
  작업이 적용되는 리소스 목록을 지정해야 합니다.
• Condition(또는 NotCondition)
  정책이 권한을 부여하는 상황을 지정합니다.

예를들어 IAM 사용자에게 예제 정책 스테이트먼트를 연결할 수 있습니다. 그러면 조컨 충족 시 해당 사용자가 계정에서 EC2 인스턴스를 중지 및 시작할 수 있습니다. 여기서 IAM 사용자가 제어할 수 있는 EC2 인스턴스에는 키가 Owner이며 값은 IAM 사용자 이름과 같은 태그가 있어야 합니다.

• 와일드 카드(*)
  와일드카드는 여러 리소스나 작업에 정책 요소를 적용하는 데 사용됩니다. 이 정책은 모든 계정 번호의 리소스, 그리고 모든 리소스 ID의 리전에 적용됩니다. 그러므로 AWs 계정 ID를 추가하여 정책을 다시 작성하지 않고도 여러 계정에 정책을 재사용할 수 있습니다.

리소스 기반 정책

리소스 기반 정책은 S3 버킷 등의 리소스에 연결되는 JSON 정책 문서입니다. 이러한 정책은 해당 리소스에서 특정 작업을 수행할 수 있는 권한을 보안 주체에 부여하고 이러한 권한이 적용되는 조건읠 정의합니다. 리소스 기반 정책은 인라인 정책이며, 관리형 리소스 기반 정책은 없습니다.

이러한 정책들은 기존 AWS 정책을 사용할 수도 있고, 자신에게 맞게 자체적으로 생성할 수도 있습니다.

리소스 기반 정책 예시

{
   "Version":"2012-10-17",
   "Statement":[
     {
       "Sid":"PolicyForAllowUploadWithACL",
       "Effect":"Allow",
       "Principal":{"AWS":"111122223333"},
       "Action":"s3:PutObject",
       "Resource":"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
       "Condition": {
         "StringEquals": {"s3:x-amz-acl":"bucket-owner-full-control"}
       }
     }
   ]
}

리소스 기반 정책은 S3 버킷이나 AWS Lambda 함수 등의 단일 리소스에 연결됩니다. 리소스 기반 정책 사용 시에는 리소스에 액세스할 수 있는 사용자와 해당 사용자가 리소스에 대해 수행할 수 있는 작업을 선택합니다.

리소스 기반 정책을 생성하는 경우에는 Principal를 정의해줘야 합니다. 즉, 액세스를 허용하거나 거부할 계정, 사용자, 역할 또는 페더레이션 사용자를 지정하는 것입니다. 이전에 사용자나 역할에 연결할 IAM 권한 정책을 생성했을 때에는 이 요소를 포함하지 않았었습니다. 그 이유는 해당 사용자나 역할이 암시적으로 보안 주체로 적용되기 때문입니다.

또 다른 점은 리소스 기반 정책에서 Resource 요소는 선택 사항입니다. 이 요소를 포함하지 않으면 작업이 적용되는 리소스가 정책이 연결된 리소스입니다.

위 예제에서 Principal은 AWS 계정의 고유 번호입니다. 여기서 리소스는 DOC-EXAMPLE-BUCKET에 있는 모든 객체를 지정해 주었습니다. 이 버킷 정책을 적용하면 특정 AWS 계정이 버킷 폴더에 객체를 업로드할 수 있습니다.

명시적 허용과 명시적 거부

IAM 정책에는 명시적 허용문이나 명시적 거부문 중 하나가 포함되거나 두 문장이 모두 포함됩니다.

1. 명시적 허용 - 명시적 허용은 IAM 사용자, 그룹, 역할이 리소스 집합을 대상으로 나열된 작업을 수행할 권한을 부여하는 것입니다.
   
   
2. 명시적 거부 - 명시적 거부는 IAM 사용자, 그룹, 역할이 리소스 집합을 대상으로 나열된 작업 수행을 시도하면 해당 작업을 중지합니다.

IAM 정책 평가 로직

계정용 IAM 정책을 작성할 때는 AWs 평가 로직을 파악하는 것이 중요합니다. 그래야 사용자와 앱에 필요한 액세스 권한만 제공할 수 있습니다.(최소 권한 원칙)

AWS는 요청 컨텍스트에 해당되는 모든 정책을 평가합니다. 단일 계정 내에서 정책에 사용 가능한 AWS 평가 관련 요약 내용은 다음과 같습니다.

• 기본적으로 모든 요청은 암시적으로 거부됩니다. 단, 모든 액세스를 보유한 AWS 계정 루트 사용자는 예외입니다.
• 자격 증명 기반 정책이나 리소스 기반 정책의 명시적 허용은 이러한 기본값을 재정의 합니다.
• 모든 정책의 명시적 거부는 모든 허용을 재정의합니다. 따라서 안전 조치로 활용하기 좋습니다.

"모든 정책의 명시적 거부는 모든 허용을 재정의합니다"라는 문장은 다음과 같은 예시로 설명할 수 있습니다. 사용자에게 리소스에 대한 액세스를 허용하는 정책이 하나 있고, 사용자에게 리소스에 대한 액세스를 거부하는 정책이 하나 있으면 사용자는 리소스에 액세스할 수 없습니다. 명시적인 거부는 모든 허용을 재정의하기 때문입니다. 즉, 명시적 거부가 명시적 허용보다 우선순위가 높다는 뜻입니다.

자격 증명 기반 정책 및 리소스 기반 정책의 자세한 내용

IAM 사용자 그룹

IAM 사용자 그룹은 이름에서 알 수 있듯이 사용자들을 모아 놓은 그룹입니다. 기존에 사용자에게 권한을 주기 위해 계정에 각각 지정해줘야 합니다. 하지만 수백 수천 명의 사용자가 존재한다면 어떨까요?

좀 더 손쉬운 관리를 위해 그룹에 권한을 지정해주고 사용자를 그룹에 넣으면 해당 사용자는 그룹의 권한을 사용할 수 있게 제작된 서비스입니다.

자세한 내용

IAM 역할

IAM 역할은 임시 AWS 자격 증명에서 제공하는 서비스입니다. 여러 직원과 애플리케이션이 같은 역할을 사용할 수 있기 때문에 관리가 용이합니다. 역할 사용에는 요금이 따로 발생하지 않습니다. IAM 역할은 AssumeRole API를 통해 전달이 되는데 이는 역할 수임 부분에서 자세하게 알아보겠습니다.

예를 들어 위 그림과 같이 DevOps 팀에서 분석을 위한 앱을 사용해야 한다고 가정해봅시다. 분석앱을 사용하기 위해서는 해당 권한이 있어야 합니다. 이 때 직접 권한을 부여하는 것이 아닌 임시로 IAM 역할을 만들어 담당자에게 부여해주는 것입니다. 이렇게 IAM 사용자 그룹에 권한을 주지 않고 담당자에게만 분석앱을 활용할 수 있는 권한을 부여할 수 있게 됩니다.

IAM 역할을 사용하는 방법의 예는 다음과 같습니다.

1. 교차 계정 액세스 - 다른 팀의 사용자가 해당 팀의 권한이 필요할 때
2. 임시 계정 액세스 - 계약자에게 해당 팀의 권한을 임시로 줘야할 때
3. 최소 권한 - 사용자가 IAM 역할을 사용해 원하는 작업을 요구할 수 있습니다.
4. 감사 - 관리자가 IAM 역할을 사용한 사람을 추적할 수 있습니다.
5. AWS 서비스 액세스 - Amazon Lex에서 Amazon Polly를 사용해 봇의 음성 응답을 합성할 수 있습니다.
6. Amazon EC2용 IAM 역할 - Amazon EC2에서 실행되는 애플리케이션이 사용하고자 하는 서비스를 액세스할 수 있습니다.
7. SAML 페더레이션 - 관리자가 외부 IdP에 저장된 자격 증명에 IAM을 사용할 수 있습니다.

역할 수임(Assuming a role, 수임=임무나 위임을 받다)

IAM 사용자, AWS 서비스 또는 페더레이션 사용자와 같은 신뢰할 수 있는 엔터티를 사용하여 역할을 수임합니다.

IAM 사용자는 AWS 관리 콘솔 또는 AWS CLI에서 역할을 수임하고 이 작업은 AssumeRole API를 사용합니다. AWS 서비스도 같은 API 호출을 통해 AWS 계정의 역할을 수임할 수 있습니다. 페더레이션 사용자는 AssumeRoleWithSAML 또는 AssumeRoleWithWebIdentity API 호출을 사용합니다.

API 호출은 AWS STS(AWS Security Token Service)에 대해 수행됩니다. AWS STS는 IAM 또는 페더레이션 사용자에게 제한된 권한의 임시 작격 증명을 제공하는 웹 서비스입니다. 이 서비스는 액세스 키 ID, 비밀 액세스 키 및 보안 토큰으로 구성된 임시 보안 자격 증명 집합을 반환합니다. 이러한 자격 증명을 사용하여 AWS 리소스에 액세스합니다. AssumeRole API는 일반적으로 교차 계정 액세스 또는 페더레이션에사용됩니다.

STS 자세한 내용

IAM 정책 배정

IAM에서 모든 IAM 정책 유형(관리형 정책 및 인라인 정책)을 생성하고 관리할 수 있는 도구를 제공합니다. IAM 자격 증명(사용자, 그룹, 역할)에 권한을 추가하려면 정책을 생성하고 정책 유효성을 검사한 다음 정책을 자격 증명에 연결합니다. 자격 증명 하나에 여러 정책을 연결할 수 있고 각 정책은 여러 권한을 포함할 수 있습니다.

보통 AWS 리소스에 대한 액세스 권한이 없는 사용자, 애플리케이션 또는 서비스에 액세스 권한을 위임할 때 역할을 사용합니다.