누구나 한번쯤 AWS 를 검색 하고 무료 AWS 어카운트에 가입 - 지금 바로 AWS 에서 구축 시작 이라는 광고를 보셨을 것입니다.

우리는 AWS 프리티어 링크를 통해 쉽게 AWS 클라우드에 가입 하고 모든 권한을 행사 할 수 있는 ROOT 어카운트를 발급 받을 수 있습니다.

AWS 의 ROOT 어카운트로 할 수 있는 것은 놀랍게도 대한 민국이 운영 하고 있는 Data Center 와 같은 것을 사용자가 만들고 싶은 만큼 클라우드 환경에서 전 세계를 대상으로 생성 할 수 있습니다. 여기에는 네트워크 Infrastructure, Platform, Software, Function 과 같은 리소스(클라우드 구성 요소)를 서비스로 올릴 수 있으며 우리는 사용한 만큼만 요금을 지불 하면 됩니다.

데이터 센터

ROOT 어카운트 로 할 수 있는 이런 강력한 권한이 누군가에게 해킹 되었다고 가정 하면, 그 뒤에 어떤 일들이 일어나게 될 지 생각만 해도 아찔해 집니다.

실제로 액세스 키가 유출되어 해커가 컴퓨팅 인스턴스를 대량으로 만들어 코인 체굴이나 ML 학습을 하는 해킹 피해 사례는 간간히 일어 납니다.

Root 어카운트 보호

IAM 을 살펴보기 전에 이처럼 중요한 Root 어카운트이 해커에 의해 탈취되지 않도록 가장 최우선으로 다음과 같은 보호를 해야 합니다.

1. Root 어카운트 MFA 설정
2. Root 어카운트 Access Key 삭제
3. 사용자 추가를 통한 클라우드 관리

Root 어카운트 MFA 설정

AWS Cloud 를 로그인 하는 모든 어카운트에 대해 MFA 를 활성화 함으로써 좀 더 안전한 보호를 할 수 있습니다.
특히, Root 어카운트를 포함한 콘솔 로그인을 하는 사용자 어카운트는 필수적으로 설정 하는것이 좋습니다.

MFA 설정은 IAM 서비스의 대시보드 메뉴에서 ‘보안 상태’ 항목에서 설정 할 수 있습니다.

• Root 어카운트에서 MFA 를 사용하는 예시

• MFA 를 사용하는 이유
  ID / PW 는 영구적인 저장소에 값이 유지되어 관리 되므로 유출 되면 심각한 피해로 이어 집니다.
  반면, OTP 는 항상 변경되는 6 자리 코드를 난수로 생성하게 되어 누군가 알게 되더라도 인증 정보가 유효하지 않습니다.
  그러므로 ID + PW + OTP Token 으로 인증 정보를 관리 하면 보다 더 안정적인 어카운트을 관리 할 수 있습니다.

• 보안 자격 증명 - MFA 활성화

• 가상 MFA 디바이스 설정

• MFA 활성화 처리

QR-Code 는 MFA 가상 디바이스를 등록 하는 코드 입니다.
MFA 앱으로 실행 하고 해당 QR-Code 를 스캔하면 가상 디바이스를 등록 할 수 있는 6자리 숫자 토큰이 생성 됩니다.
처음 나온 6자리 숫자를 MFA 코드 1 항목에 입력하고, 그 다음에 나우는 6자리 숫자를 MFA 코드 2 에 입력 하면 MFA 가상 디바이스가 활성화 됩니다.

Root 어카운트 Access Key 삭제

IAM 서비스의 대시보드 메뉴에서 ‘보안 자격 증명’ 항목에서 액세스 키 관리를 할 수 있습니다.
Root 어카운트 에서 액세스 키를 생성 하지 않도록 유의 하고 혹시라도 생성 하였다면 사용 중인 리소스가 있는지 조치 후 안전하게 삭제 합니다.

사용자 추가를 통한 클라우드 관리

클라우드 운영 관리를 위해 별도의 사용자 어카운트을 추가 합니다. 역할 중심의 제한된 권한 (Policy) 을 설정 하고, 역할 셋(Role) 을 통해 그룹화하여 사용자 및 리소스에게 해당 역할을 달당 함으로써 보다 안전하게 클라우드를 액세스 할 수 있습니다.

사용자 어카운트 추가는 관리 콘솔을 통해 쉽게 생성 할 수 있습니다.

1. 사용자 아이디 입력

여기에서 사용자 아이디 및 액세스 유형을 선택 할 수 있습니다.

2. 사용자 권한 설정

사용자 권한은 3가지 유형으로 설정 할 수 있습니다.

• 사용자 그룹을 생성하고 권한셋을 설정한 다음 사용자를 해당 그룹에 추가 하는 방식

• 기존 사용자의 권한을 생성될 사용자에게 복사 하는 방식

• 필요한 권한을 선택하여 사용자에게 직접 추가하는 방식

3. 태깅 속성 추가

사용자 어카운트 관리를 모니터링하고 자동화 하기 위해 필요한 태그 속성을 추가 할 수 있습니다.

4. 사용자 만들기

입력한 정보를 기반으로 우측 하단의 사용자 만들기 버튼을 클릭하여 사용자를 생성 할 수 있습니다.

5. 사용자 추가

사용자가 생성 되면 정보 안내와 함께 로그인 링크와, 자동으로 생성된 AccessKey 를 확인 할 수 있습니다.

위와 같이 관리 콘솔에 로그인 하는 사용자를 생성한 경우 라면, 뱔급된 AccessKey 를 사용하지 않고 삭제 하는 것이 좋습니다.
AccessKey 의 사용은 별도의 프로그래밍 방식의 사용자 어카운트을 생성 하여 사용하는 것을 권고합니다.

IAM (Identity and Access Management)

IAM 은 AWS 클라우드 가입과 동시에 계정 보호 설정을 한 것 처럼 우리가 가장 먼저 이해 하고 구성 해야 할 중요한 서비스 입니다.

AWS Identity and Access Management(IAM)은 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 서비스로, 인증(Authenticated)된 사용자에게 인가(Authorized)된 액세스를 정책을 컨트롤 하는 서비스 입니다.

IAM 은 User, Group, Role, Policy 와 같은 리소스로 구성 되어 AWS 보안을 책임지고 있습니다. 각 리소스를 간단 하게 설명 하면 다음과 같습니다.

User

AWS 를 사용하는 사용자 또는 애플리케이션 입니다. User 는 리소스를 액세스 하기위한 자격 인증을 받는 주체 입니다.
User 는 Policy 나 Role 을 추가하여 리소에 대한 액세스가 가능 합니다.

Group

User 를 추가 하여 그룹으로 관리 할 수 있고 여기에 리소스 권한 셋을 설정 할 수 있습니다.

Role

Role 은 Policy 권한 셋을 설정 하고, 역할(Admin, Developer, Viewer 등 ) 로써 리소스에 대한 액세스를 할 수 있게 도와 줍니다.
Role 은 User 와 마찬가지로 리소스를 액세스 하기위한 자격 인증을 받는 주체 입니다.

참고로 Role 및 User 는 자격 인증을 보장하는 주체임과 동시에 Assume Role 을 통해 특정 Role 로 전환 할 수 있고 해당 Role 을 통해 리소스를 액세스 할 수 있습니다.

Policy

AWS EC2, S3, RDS 등 리소스에 대한 액세스 권한 장책을 설정 합니다.

Policy 유형은 다음과 같이 3가지 유형이 있습니다. 관리형 정책은 복잡한 액세스 규칙을 역할에 맞도록 잘 설계해 놓았으며 User 나 Role 이 쉽게 이용할 수 있도록 하였습니다.

• AWS 관리형 정책: AWS 에서 사전에 구성해 놓은 정책
• 고객 관리형 정책: AWS 클라우드를 이용하는 고객이 구성해 놓은 정책
• 인라인 정책 : 관리형 정책에서 부족한 개별 액세스를 컨트롤 할 때 유횽 합니다. 예를 들어 S3 조회 권한만 가능한 사용자가 S3 에 이미지만 업로드 할 수 있게 하려고 한다면 S3 put 권한을 인라인 정책으로 반영 할 수 있습니다.

IAM Policy 이해

AWS 의 보안 및 접근 제어를 잘 컨트롤 한다는 건 Policy 를 잘 설계하고 적용 하는 것 입니다.

IAM 정책 유형 중 자격 증명 기반(Identity-based) 정책 과 리소스 기반(Resource-based) 정책 두 가지를 살펴보겠습니다.

• 자격 증명 기반(Identity-based) 정책
  IAM 자격 증명을 받은 주체(User, Group, Role 이 로그인과 같은 인증 된)가 AWS 의 리소스를 대상으로 액세스를 할 수 있는 권한을 정의 합니다.
  예를 들어, 사용자 John 은 리소스 EC2 의 Creation 및 Termination 작업을 수행할 수 있는 액세스 권한을 Policy 로 정의 할 수 있습니다.
  자격 증명 기반(Identity-based) 정책 예제

• 리소스 기반(Resource-based) 정책
  EC2, S3 Bucket, RDS, Key Management Service 등 IAM 을 추가 할 수 있는 리소스가 메인이 되는 정책으로 해당 리소스가 누군가의 액세스를 허용할 지 말지를 정의 합니다. 예를 들어, S3 입장에서 객체 읽기 GetObject 액세스 권한을 111122223333 어카운트 에게만 허용 한다를 Policy 로 정의 할 수 있습니다.
  리소스 기반(Resource-based) 정책은 서비스를 제공하는 주체인 Resource 와 서비스를 이용하는 주체인 Principal 속성 두가지가 필수적으로 기술 됩니다.
  리소스 기반(Resource-based) 정책 예제

IAM Policy 구조

액세스 정책 구조의 주요 속성은 다음과 같습니다.

IAM Policy Statement 구조

UseCase 를 통한 Policy 이해

DynamoDB 를 사용하는 Use-Case 예시로 Policy 정책 수립을 살펴 봅시다.

위 아키텍처는

1. API Gateway 를 사용하는 애플리케이션이 Lambda 를 통해 DynamoDB 를 액세스 하는 흐름과,
2. Load Balancer 를 통해 EC2 에 구성된 애플리케이션이 DynamoDB 를 액세스 하는 흐름

두 가지로 DynamoDB 를 액세스 합니다.

Case 1 Super-User

모든 Resource 에 대해 모든 액세스 Policy 권한을 허용 하는 정책 입니다.
사실상 Super User 권한과 같은 정책으로 보안에 심각한 문제가 발생할 수 있습니다.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

Case 2 Full Access

모든 Resource 에 대해 dynamodb 에 한정된 모든 액세스 Policy 권한을 허용 하는 정책 입니다.
오퍼레이션(Action)은 DynamoDB 에 한정되어 있지만 모든 Resource 에 대해 DynamoDB 관련 모든 액세스 권한이 열려 있으므로 개선이 필요합니다.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["dynamodb:*"],
      "Resource": "*"
    }
  ]
}

Case 3 Limited Access

한정된 Resource 에 대해 한정된 액세스 Policy 권한을 허용 하는 정책 으로 DynamoDB 를 액세스 하는 예시 입니다.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem"
      ],
      "Resource":[
        "arn:aws:dynamodb:ap-northeast-2:111122223333:table/MyTable"
      ]
    }
  ]
}

Case 4 Advanced Limited Access with Condition

한정된 Resource 에 대해 한정된 액세스 Policy 권한을 허용 하는 정책에서 특정 조건을 만족하는 상황에서 DynamoDB 를 액세스 하는 예시 입니다.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem"
      ],
      "Resource":[
        "arn:aws:dynamodb:ap-northeast-2:111122223333:table/MyTable"
      ],
      "Condition": {
        "StringEquals": {
          "ec2:Name": "my-ec2"
        }
      }
    }
  ]
}

Condition 표현식 예시

"Condition": {

  # ARN 을 통한 Condition  
  "ArnLike": {
    "aws:SourceArn": "arn:aws:dynamodb:ap-northeast-2:111122223333"
  },
  
  # 리소스의 Tag 를 통한 Condition
  "StringEquals": {
    "ec2:Region": "ap-northeast-2"
  },
  
  # Source CICD 를 통한 Condition 예시
  "IpAddress": {
    "aws:SourceIp": "172.76.11.0/24"
  },
  
  # 리소스 속성에 의한 Condition 예시
  "ForAllValues:StringLike": {
    "dynamodb:LeadingKeys": [
      "guest*"
    ]
  }
 
},

Case 5 Advanced Limited Access with Principal

한정된 Resource 에 대해 한정된 액세스 Policy 권한을 허용 하는 정책에서 한정된 주체(Principal)에 대해서만 DynamoDB 를 액세스 하는 예시 입니다.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem"
      ],
      "Resource":[
        "arn:aws:dynamodb:ap-northeast-2:111122223333:table/MyTable"
      ],
      "Principal": { 
        "AWS": [
          "999999999999"
        ],
        "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be"
      }
    }
  ]
}

• Principal 표현식 예시

# AWS Account 기준으로 Principal(요청자) 접근 통제
"Principal": { 
  "AWS": [
    "999999999999"
    "arn:aws:iam::111122223333:root",
  ],
  "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be".
},

# AWS Role 기준으로 Principal(요청자) 접근 통제
"Principal": {
  "AWS": [
    "arn:aws:iam::444455556666:role/my-apple-role"
  ]
},
      
# 페더레이션 사용자 어카운트 기준으로 Principal(요청자) 접근 통제
"Principal": { 
  "AWS": "arn:aws:sts::111111111111:federated-user/symplesims" 
}

# AWS 서비스 기준으로 Principal(요청자) 접근 통제
"Principal": {
  "Service": [
    "ecs.amazonaws.com",
    "elasticloadbalancing.amazonaws.com"
 ]
},

Conclusion

1. AWS 클라우드 가입과 동시에 IAM 에서 Root 어카운트 보호 설정을 해야 합니다.
2. Root 가 아닌 별도의 사용자 계정을 생성 하여 클라우드를 이용 합니다.
3. 꼭 필요한 최소 권한 부여 원칙으로 IAM Policy 를 구성 합ㄴ다.

이 밖에도 다음과 같이 좀 더 체계적인 IAM 을 구성 및 관리 할 수 있습니다.

• 역할 기반의 사용자 그룹을 관리
• 액세스 권한을 Role 단위로 제한 하는 PassRole 을 구성
• IAM 거버넌스와 같이 조직화된 액세스 정책을 따르도록 SCP (Service Control Policy) 를 수립하여 조직 단위(Organization Unit)로 따르도록 설정
• AWS 계정과 AccessKey 의 사용 현황을 지속적으로 감사 및 모니터링
• 리소스 속성 기반으로 Policy 재 사용

References

• IAM이란 무엇입니까?
• AWS IAM 과 친해지기