Post

[AWS-Security] 4.5. IAM 권한 검토

Posted Updated
By haksuperman
views 13 min read
[AWS-Security] 4.5. IAM 권한 검토

1. IAM 권한 검토

  • 수동 검토의 필요성 : 조직에서 모범 사례(규칙)를 만들었다면 이를 적용해야 하지만, 패스워드 정책 등을 제외한 대부분의 모범 사례는 자동으로 시스템에 강제하기 어렵다.
  • 해결책 : IAM 구성이 우리가 정한 규칙(모범 사례)을 잘 따르고 있는지 확인하는 가장 확실한 방법은 수동으로 직접 검토하는 것이다.

2. IAM 리소스를 검토해야 하는 이유

수동 검토는 많은 시간과 노력이 필요하지만, 반드시 수행해야 한다.

  1. 측정 (보안 수준의 정량화)
    1. 조직에서 만든 모범 사례(기준표)를 바탕으로 현재 우리 시스템이 목표에 얼마나 근접했는지 평가하는 단계이다.
    2. 이를 통해 “우리 정책의 90%가 규정을 준수하고 있다”와 같은 수치를 도출할 수 있으며, 시간이 지남에 따라 보안 상태가 개선되고 있는지 추적할 수 있다.
  2. 시행 (실질적인 보안 강제)
    1. 훌륭한 모범 사례를 만들어 두어도, 실제로 시스템에 적용(시행)하지 않으면 아무런 보안 이점을 얻을 수 없다.
    2. 자동화할 수 없는 규칙들의 경우, 수동 검토를 통해 규정을 어긴(비준수) 리소스를 찾아내고 수정해야만 원하는 보안 수준을 달성할 수 있다.
  3. 주기적 재검토 (방치된 권한 청소)
    1. 클라우드 환경은 빠르게 변하지만, IAM 관리는 이를 따라가지 못해 안쓰는 역할이나 삭제된 리소스의 권한이 그대로 방치되는 등 부실해지는 경향이 있다.
    2. 주기적인 IAM 검토는 쓸데없이 남아있는 ‘오래된 권한’을 찾아내어 정리할 수 있는 기회이다.

AWS 로그 기록 서비스인 CloudTrail을 확인하면 쉽게 식별해 낼 수 있다.

3. 검토 유형

3.1. 기준선 설정 (Baselining Review)

  • 개념 : 구성이 ‘의도하고 필요한 것’과 ‘실제로 부여된 것’이 일치하는지 비교하는 방법이다.
  • 방법 : 사용자에게 ‘필요하다고 생각되는 모든 권한 목록’을 먼저 작성한 후, ‘실제로 연결된 모든 권한(인라인 정책, 관리형 정책, 수임 가능한 역할 등)’을 모두 수집하여 두 목록을 비교한다.
  • 장점 : 최소 권한 모범 사례를 확인하고, 더 이상 필요하지 않은 오래된 권한을 찾아 제거하는 데 유용하다.

[예시 시나리오]

  • EC2 접근 권한만 필요한 사용자에게 아래와 같은 정책이 부여되어 있다.
  • 해당 정책은 일부 EC2 접근과 MetadataBackupRole이라는 Role을 수임할 수 있는 기능을 허용한다. (해당 Role에 불필요한 권한이 있지 않은지 검사해야 함)
    1
2
3
4
5
6
7
8
9
10
11
12

      {
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": ["ec2:StartInstances", "ec2:TerminateInstances", "ec2:DescribeInstances"],
      "Resource": "*"
    }, {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/MetadataBackupRole"
    }]
  }


[확인 결과]

  • Role 세부 정책서 확인 시, 필요한 권한(EC2) 외의 불필요한 S3 권한이 부여되어 있다.
  • S3 역할 수임 권한을 제거하여 정책을 최신화한다.
  • MetadataBackupRole.json
    1
2
3
4
5
6
7
8

      {
      "Version": "2012-10-17",
      "Statement": [{
          "Effect": "Allow",
          "Action": ["s3:PutObject", "s3:DeleteObject", "s3:ListAllMyBuckets"],
          "Resource": "*"
      }]
  }


[최종 정책]

1
2
3
4
5
6
7
8

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["ec2:StartInstances", "ec2:TerminateInstances", "ec2:DescribeInstances"],
    "Resource": "*"
  }]
}

3.2. 전통적인 보안 검토 (Traditional Security Review)

  • 개념 : 모든 IAM 리소스를 조직의 ‘모범 사례(규칙)’에 대입하여 규정 준수 여부를 빠르게 평가하는 방법이다.
  • 방법 : 리소스의 구체적인 맥락(이 권한이 필요한지 등)을 따지지 않고, “와일드카드(*)가 있는가?”, “인라인 정책이 있는가?” 등 정해진 규칙 위반 여부만 찾아낸다.
  • 장점 : 모범 사례에 익숙한 보안 전문가가 수행하면, 일일이 코드를 뜯어보고 개발자와 대화해야 하는 ‘기준선 설정’ 보다 훨씬 빠르고 쉽게 비준수 항목을 식별할 수 있다.

[예시 시나리오]

  • 모범 사례
    • 정책에 와일드 카드(*) 사용 금지
    • 인라인 정책 사용 금지
    • 사용자는 AssumeRole을 제외한 다른 직접 권한 보유 금지
  • 대상 IAM 정책
    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

      {
    "_comment":"1. S3AccessPolicy라는 IAM 정책",
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:DeleteObject"],
      "Resource": "*" 
    }]
  }
	
  {
    "_comment":"2. 앨리스(Alice)라는 IAM 사용자에게 연결된 인라인 정책",
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::my_bucket/*"
    }]
  }
  • 추가 Role 정보 : S3AccessPolicy 관리형 정책이 연결되어 있고, 앨리스를 신뢰하는 S3AceessRole이라는 역할이 있다.

[비준수 항목]

  1. S3AccessPolicy는 리소스 블록에서 와일드카드(*)를 사용하고 있다.
  2. 앨리스(Alice) 사용자는 인라인 정책을 가지고 있다.
  3. 사용자(앨리스)에게 AssumeRole이 아닌 권한(s3:PutObject 등)이 직접 부여되어 있다.

3.3. 로그 기반 검토 (Log-based Review)

  • 개념
    • 접근 로그를 살펴보고 ‘부여된 권한’ 중 ‘실제로 사용된 권한’이 무엇인지 확인하는 방법이다.
    • 권한이 충분히 복잡하거나 기준선 검토를 할 시간이 없을 때 유용하다.
  • 도구 : AWS 계정에서 호출되는 거의 모든 작업을 기록하는 AWS CloudTrail 서비스를 활용한다. (기본적으로 지난 90일의 이벤트를 캡처)
  • 방법 : 콘솔의 Event history에서 검색하거나, AWS CLI 및 다운로드한 CSV 파일을 통해 특정 작업이 언제 마지막으로 쓰였는지 조회한다.

[CLI 및 로그 검색 예시]

1
2
3
4
5
6
7
8

# 특정 작업에 대한 이벤트를 반환하는 CloudTrail 조회 명령어
aws cloudtrail lookup-events \
	--lookup-attributes AttributeKey=EventName,AttributeValue=ListBuckets

# IAM 정책 문서 샘플 (CSV 파일에서 grep으로 검색)
grep "ListBuckets" event_history.csv
> 79ec17a0,"2019-01-01,10:30:00 AM",dylanshields,ListBuckets,us-east-1,192.168.1.1
> 79ec17a0,"2019-01-02,11:43:08 AM",dylanshields,ListBuckets,us-east-1,192.168.1.1

image

  • 결론 : 위 결과처럼 마지막 사용일이 아주 오래전이라면, 해당 권한은 더이상 필요하지 않은 것으로 판단하여 취소를 검토해야 한다.

이상적으로는 조직에서 IAM 구성의 모든 불안전한 요소를 파악하기 위해 세 가지 유형의 검토를 모두 사용하는 것이 좋다.

4. 검토 부담 경감 (리뷰 시간과 노력 줄이기)

  1. 권한 설정 방법 제한하기
    • 개념 : IAM 엔터티에 권한을 적용하는 방법은 매우 다양하다. 특정 방식으로만 제한하면 확인해야 할 곳이 줄어든다.
    • 예시 : 모범 사례로 ‘인라인 정책 사용 금지’해 두면, 사용자를 검토할 때 인라인 정책이 있는지 찾아볼 필요가 아예 없어진다.
  2. 내장된 기능(태그 및 설명) 활용하기
    • 태그(Tag) 활용 : 리소스를 한 번에 모두 검토하기 힘들 때, 리소스에 마지막으로 검토한 날짜를 태그로 지정하여 진척도를 추적할 수 있다.
      1
2

        # IAM 사용자에게 태그를 추가하는 AWS CLI 명령어
  aws iam tag-user \ --user-name Alice \ --tags Key=ReviewedOn,Value=2020-01-01
    • 설명(Description) 필드 활용 : 거의 모든 IAM 리소스에는 설명을 입력할 수 있다. 리소스의 용도나 사용자에 대한 정보를 미리 적어두면, 검토자가 필요한 권한의 맥락을 파악하는 데 걸리는 시간을 절약할 수 있다.
  3. 모범 사례 재고 (현실적인 타협)
    • 개념 : 만약 일이 너무 많아서 검토 자체를 제대로 시행하지 못하고 있다면, 그 모범 사례는 실질적으로 도움이 되지 않으므로 변경하거나 제거하는 것이 좋다.
    • 예시 (와일드 카드 금지의 딜레마)
      • 최소 권한 원칙을 위해 와일드 카드(*) 사용을 금지하면, 정책에 수많은 작업이 길게 나열되게 된다.
      • 검토자는 이 수많은 작업들이 실제로 필요한지 일일이 확인해야 한다.
      • 일이 너무 많아 검토가 불가능하다면, 모범 사례를 완화하여 dynamodb:*를 쓰는 것이 더 바람직할 수 있다.
    • 결론 : 보안(최소 권한)을 일부 포기하는 것이지만, 새로운 모범 사례를 만들 때는 항상 “검토 프로세스에 얼마나 많은 부담을 추가할 것인가”를 반드시 고려해야 한다.
  4. 자동화 도구 도입
    • 모든 모범 사례에 적용되지는 않지만, 도구를 사용하여 검토 작업의 부하를 줄일 수 있다.
    • AWS Config 규칙을 활성화하면 IAM 리소스가 업데이트될 때마다 해당 리소스를 확인하고, 설정한 보안 규정을 준수하지 않을 때 경고를 보내준다.
    • 오픈소스 : NCC Group의 ScourSuit 같은 도구를 사용할 수도 있다.
CLOUD, AWS
cloud aws public cloud
This post is licensed under CC BY 4.0 by the author.