[AWS] AWS Solution Architect Part.2 핵심 인프라 및 보안

zooy·2025년 9월 5일
SAAawscloud자격증

cloud

목록 보기
18/19

안녕하세요,
지난 포스팅 글에 이어서 Part.2 핵심 인프라 및 보안에 대해 정리해보겠습니다.
지난 Solution Architect Associate Part.1 에서는 AWS의 기본 원칙과 비즈니스 가치, 글로벌 인프라 그리고 Well-Architected 프레임워크에 대해 살펴보았습니다.

오늘은 이를 채워나갈 가장 중요한 IAM(Identity and Access Management)과 VPC(Virtual Private Cloud)에 대해 살펴보겠습니다.

'누가(Who)' 접근할 수 있는지를 정의하는 IAM과,
'어디서(Where)' 활동할 수 있는지를 정의하는 VPC는
모든 AWS 아키텍처의 보안과 구조를 결정하는 뼈대와도 같습니다.
이 두 가지를 완벽하게 이해해야 비로소 견고하고 안전한 클라우드 환경을 구축할 수 있습니다.

5. Identity and Access Management(IAM)

AWS 환경의 보안은 누가, 무엇을, 어떻게 할 수 있는가를 제어하는 것에서 시작됩니다. AWS Identity and Access Management 이하 IAM은 바로 이 질문에 답을 주는 서비스로, AWS 리소스에 대한 액세스를 안전하게 제어하는 핵심적인 역할을 합니다. IAM은 추가 비용 없이 제공되며, 모든 AWS 계정의 보안을 위한 가장 기본적인 첫걸음입니다.

IAM은 네 가지 핵심 구성 요소로 이루어져 있습니다.

1. 사용자(User)

: AWS와 상호작용하는 사람 또는 애플리케이션입니다.
각 사용자는 고유한 자격 증명(콘솔용 비밀번호, API용 액세스 키)을 가집니다.
처음 생성된 사용자는 아무 권한이 없는 '백지' 상태입니다.

2. 사용자 그룹(Group)

: 사용자들의 컬렉션입니다. 개별 사용자에게 권한을 하나씩 부여하는 대신, '개발자', 'DB 관리자'와 같은 직무별 그룹을 만들고 그룹에 권한을 할당하는 것이 모범 사례입니다.

3. 역할(Role)

: 역할은 매우 중요한 개념입니다. 사용자나 그룹과 달리 영구적인 자격 증명을 갖지 않고, 필요할 때 임시 자격 증명을 발급받아 특정 작업을 수행하는 IAM 엔터티입니다. EC2인스턴스가 S3버킷에 접근해야할 때 처럼, AWS 서비스에 권한을 부여하거나 다른 계정에 접근 권한을 위임할 때 사용됩니다. 코드에 액세스 키를 하드코딩하는 위험을 제거하는 최고의 보안 매커니즘입니다.

4. 정책(Policy)

: 권한 그 자체를 정의하는 JSON형식의 문서입니다.
"S3버킷에서 객체를 읽는 것을 허용(Allow)" 또는 "EC2 인스턴스를 삭제하는 것을 거부(Deny)"와 같은 규칙을 명시합니다.

가장 중요한 규칙: 루트 사용자(Root User)를 잠그세요!

AWS 계정을 처음 생성하면 모든 권한을 가진 루트 사용자가 생성됩니다. 이 계정은 계정 폐쇄나 결제 정보 변경처럼 극히 제한적인 작업에만 사용해야 하며, 일상적인 작업에는 절대 사용해서는 안됩니다. 보안 모범 사례는 다음과 같습니다.

  1. 루트 사용자에 다단계 인증(MFA)을 즉시 활성화합니다.
  2. 관리자 권한을 가진 IAM 사용자를 별도로 생성합니다.
  3. 앞으로는 생성한 IAM 사용자로만 로그인하여 모든 관리 작업을 수행합니다.

6. IAM 심층 분석: 접근 제어 마스터

IAM의 진정한 강력함은 정책(Policy)을 통해 접근 권한을 세밀하게 제어하는 능력에서 나옵니다.

IAM 정책(Policy) JSON 구조

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ReadAccessFromSpecificIP",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::my-example-bucket",
                "arn:aws:s3:::my-example-bucket/*"
            ],
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "203.0.113.0/24"
                }
            }
        }
    ]
}

모든 정책은 위와 같은 JSON 구조를 가집니다.

  • Effect: Allow(허용) or Deny(거부)를 지정합니다.
  • Action: 허용하거나 거부할 서비스 작업을 지정합니다.
  • Resource: 작업이 적용될 AWS 리소스.
    ARN(Amazon Resource Name)으로 고유하게 식별됩니다.
  • Condition(선택): 정책이 적용되기 위한 특정 조건을 지정하는 강력한 요소입니다.

Condition을 활용한 동적 제어

Condition 블록을 사용하면 특정 상황에서만 권한이 유효하도록 제한할 수 있습니다.

  • 특정 IP 주소에서만 접근 허용: 회사 내부 네트워크에서만 중요 리소스에 접근하도록 강제합니다.
  • 다단계 인증(MFA) 강제: 민감한 작업을 수행하기 전, 사용자가 MFA로 인증했는지 확인합니다.

가장 강력한 규칙: 명시적 거부의 우선순위

IAM 정책 평가 로직에서 가장 중요한 원칙 중 하나는 명시적 거부(Deny)가 항상 허용(Allow)보다 우선이라는 것입니다. 어떤 정책에서 특정 작업을 허용하더라도, 단 하나의 정책이라도 동일 작업을 명시적으로 거부하면 해당 작업은 최종적으로 거부됩니다.

7. 고급 IAM: AWS Organizations를 통한 다중 계정 전략

비즈니스가 성장하면 부서별, 환경별(개발/프로덕션)로 AWS 계정을 분리하는 것이 보안과 비용 관리 측면에서 유리합니다. AWS Organizations는 이렇게 분산된 다중 계정을 중앙에서 통합 관리하는 서비스입니다.

서비스 제어 정책(Service Control Policies, SCP): 중앙 통제 가드레일
SCP는 AWS Organizations의 가장 강력한 기능으로, 조직 전체 또는 특정 부서에 대한 최대 허용 권한의 가드레일을 설정합니다.

  • 작동 방식: SCP는 권한을 부여하지 않습니다. 오직 조직 내 IAM 사용자들이 사용할 수 있는 서비스와 작업의 최대 범위를 제한할 뿐입니다.
  • 우선순위: 권한이 최종적으로 부여되려면 SCP와 IAM 정책 모두에서 허용되어야 합니다. SCP가 허용하지 않는 작업은 IAM 사용자가 아무리 강력한 권한을 가져도 절대 수행할 수 없습니다.

8. Virtual Private Cloud(VPC)

VPC는 사용자의 AWS 계정 전용으로 논리적으로 완벽하게 격리된 가상 네트워크 공간입니다. 클라우드 안에 나만의 데이터 센터를 구축하는 것과 같습니다. IP 주소 범위, 서브넷, 라우팅, 게이트웨이 등 모든 것을 직접 제어할 수 있습니다

VPC의 첫걸음: CIDR과 서브넷

  • CIDR (Classless Inter-Domain Routing)
    : VPC를 생성할 때 가장 먼저 10.0.0.0/16과 같이 VPC가 사용할 사설 IP 주소 범위를 지정합니다. /16은 65,536개의 IP 주소를 의미하며, 미래 확장성을 위해 충분히 크게 잡는 것이 좋습니다.
  • 서브넷 (Subnet)
    : 큰 IP 주소 범위를 더 작은 논리적 단위로 나눈 것입니다.
    EC2 인스턴스와 같은 리소스는 항상 특정 서브넷 안에 생성됩니다.
    중요한 점은, 하나의 서브넷은 하나의 가용 영역(AZ)에만 존재할 수 있다는 것입니다. 이는 고가용성 아키텍처의 핵심입니다.

9. VPC 아키텍처: 서브넷, 라우팅, 게이트웨이

VPC의 기능은 여러 구성 요소의 상호작용으로 완성됩니다.

  • 라우팅 테이블 (Route Table): 서브넷에서 발생하는 네트워크 트래픽이 어디로 가야 할지를 결정하는 규칙(경로)의 집합입니다.

  • 퍼블릭 서브넷 vs 프라이빗 서브넷

    • 퍼블릭 서브넷(Public Subnet): 라우팅 테이블에 인터넷 게이트웨이(IGW)로 향하는 경로가 있는 서브넷입니다. 외부 인터넷과 직접 통신이 가능하며, 주로 웹 서버를 배치합니다.

    • 프라이빗 서브넷(Private Subnet): 인터넷 게이트웨이로 향하는 경로가 없는 서브넷입니다. 외부에서 직접 접근할 수 없어 보안성이 높으며, 데이터베이스나 내부 애플리케이션을 배치합니다.

  • NAT 게이트웨이(NAT Gateway): 프라이빗 서브넷의 리소스가 외부 인터넷으로 나가는(아웃바운드) 통신은 필요하지만, 외부에서 안으로 들어오는(인바운드) 연결은 차단하고 싶을 때 사용합니다.
    예를 들어, 프라이빗 DB서버가 OS 업데이트를 위해 외부 리포지토리에 접근해야할 때 필요합니다. NAT 게이트웨이는 반드시 퍼블릭 서브넷에 위치해야 합니다!

10. VPC 보안: 보안 그룹과 네트워크 ACL을 통한 심층 방어

VPC는 '심층 방어' 전략을 구현할 수 있도록 두 종류의 가상 방화벽을 제공합니다.

이번 Part.2에서는 AWS 아키텍처의 보안과 네트워킹 근간을 이루는 IAM과 VPC를 깊게 다루어 보았습니다. 이 개념들을 확실히 다져야 앞으로 배울 컴퓨팅, 스토리지, 데이터베이스 서비스를 안전하고 효율적으로 구성할 수 있을 것입니다.

다음 Part.3 포스팅에서는 컴퓨팅 서비스에 대해 자세히 알아보겠습니다.
궁금한 점이 있다면 댓글로 남겨주세요!

오늘도 하고픈걸 향해 떠나는
zooy였습니다 :)
감사합니다!

profile
zooy
하고픈걸 향해서
이전 포스트

[AWS] Solution Architect Associate Part.1

다음 포스트

[AWS] AWS Solution Architect Associate (SAA-C03) 핵심 정리

0개의 댓글