[AWS-Security] 2.1. IAM 기초

Posted Jan 24, 2026 Updated Mar 5, 2026

By haksuperman

views 29 min read

1. 사용자 (IAM User)

1.1. 인증과 권한 부여

IAM 솔루션의 핵심 사항은 인증(Authentication)과 권한 부여(Authorization)이다.

인증(Authentication)은 사용자가 ‘내가 누구인지 증명하는 것’을 의미한다.
ex) 우리 회사 직원이 맞는지 확인
권한 부여(Authorization)는 사용자가 ‘특정 작업을 수행할 수 있는지 확인하는 것’을 의미한다.
ex) 서버실 출입 권한이 있는지 확인

1.2. AWS와 관리자의 역할

IAM에서 사용자는 IAM 사용자 또는 다른 IAM 엔터티로 인증된다. IAM은 사용자에게 적용된 IAM Policy에 따라 AWS에서 작업을 수행할 권한을 사용자에게 부여한다.

인증 : AWS에서 실제 ID 증명을 처리하지만, 사용자가 ID를 정의하고 실제로 인증하는 데 사용되는 자격증명을 배포한다.
ex) 우리 회사 직원이 맞는지 확인은 AWS가 해주지만, 최초 사원증(ID/Password)을 만들고 나누어 주는건 관리자의 몫이다.
권한 부여 : AWS에서 실제 ID 증명을 처리하지만, IAM Policy를 통해 권한을 정의한다.
ex) 서버실 출입 권한이 있는지 확인은 AWS가 해주지만, 출입 규칙표(Policy)는 관리자가 미리 작성해 두어야 한다.

1.3. 자격 증명 유형

사용자가 가질 수 있는 자격 증명에는 아래 두 가지가 있다.

비밀번호 (Password) : AWS Management Console 접속 시에만 사용, 프로그래밍 접근 방식 사용 불가
액세스 키 (Access key) : Access key ID와 Secret access key를 함께 사용해 SDK 또는 CLI를 통해 프로그래밍 방식으로 AWS 작업을 호출한다. (최대 2개)

프로그래밍 방식(SDK/CLI)과 AWS Management Console 방식 모두 필요한 경우, 위 자격 증명 두가지를 모두 가질 수 있다.

1.4. Alice와 Bob 생성

Alice : 프로그래밍 방식(SDK/CLI)의 접근 허용
Bob : AWS Management Console 접근 허용
각 User는 부여된 방식으로 로그인까지만 가능 (이외 권한 x)

  
## IAM User 'Alice' 생성
aws iam create-user --user-name Alice

## AWS CLI 또는 SDK를 사용하여 'Alice' User로 인증하는 데 사용되는 Access key 쌍 생성
aws iam create-access-key --user-name Alice
   
## Access key 쌍이 반환됨 
## For example
# Response: { "AccessKey": {
#   "UserName": "Alice",
#   ...
#   "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY",
#   "AccessKeyId": "AKIAIOSFODNN7EXAMPLE"
# }}


## IAM User 'Bob' 생성
aws iam create-user --user-name Bob

## AWS Management Console을 통해 로그인할 수 있는 패스워드(B0bsPassword) 생성
## 최초 로그인 시 재설정 필요
aws iam create-login-profile --user-name Bob --password B0bsPassword \
    --password-reset-required

2. ID 정책 (Identity based policy)

2.1. Policy 유형

신원 기반 정책 (ID 정책, Identity based policy) : 사람 또는 애플리케이션에 서비스와 리소스를 사용할 수 있는 권한을 부여하는 데 사용된다.
리소스 기반 정책 (Resource based policy) : 특정 리소스에 접근할 수 있는 사람 또는 애플리케이션을 추가로 제한하는 데 자주 사용된다.

여기서는 신원 기반 정책 (Identity based policy)만 다루고, 리소스 기반 정책(Resource based policy)는 이후에 다룸

2.2. Policy 기본 구조

정책을 설명하는 JSON 문서를 정책 문서(Policy document)라고 한다.
각 정책 문서에는 정책 문서에서 허용하는 권한을 정의하는 정책 선언문(statement) 목록이 있다.

  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "dynamodb:ListTables",
      "Resource": "*"
    }
  ]
}

Effect, Action, Resource의 기본 구성 요소를 가지고 있다.

2.2.1. Effect 블록

기본 원칙
- 모든 선언문에 필요한 필수 구성 요소이다.
- Effect의 값은 허용(Allow) 또는 거부(Deny)가 올 수 있으며, 이는 권한을 부여할지/차단할지 결정한다.
Allow (허용)
- 기본적으로 화이트리스트 기반으로 동작(지정되지 않은 모든 권한은 거부)한다. (암묵적 거부)
- 일반적으로 Effect에는 허용(Allow)을 명시하여 허용할 작업을 명시한다.
Deny (거부)
- Allow 권한을 무력화할 때 사용한다.
- 암묵적 거부로 인해 이미 Deny이지만, 명시적 허용(Allow)을 차단하기 위해 사용한다.
- 명시적 거부(Deny)는 명시적 허용(Allow)보다 우선시 한다.

AWS에서의 Effect 우선순위 명시적 거부 (Explicit Deny) > 명시적 허용 (Explicit Allow) > 기본(명시되지 않음)

EC2 인스턴스의 Terminate를 명시적으로 거부 -> 추후 어떠한 정책이 추가 부여되어도 모든 리소스(“*“)에 대해 “ec2:TerminateInstance”에 대한 동작은 모두 거부

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

2.2.2. Action 블록

Action 블록은 구체적으로 어떤 행동을 허용하거나 거부할지 지정하는 문자열 또는 문자열 목록이다. (동사에 해당)

기본 구조
- AWS에서 모든 작업은 서비스명:메서드 형식을 따른다. (어디서:무엇을)
- ec2:StartInstance : EC2 서비스에서 인스턴스를 시작
- s3:CreateBucket : S3 서비스에서 버킷을 생성
대소문자를 구분하지 않는 경우도 있지만, 일반적으로 서비스명은 소문자(s3, ec2), 행동은 대문자로 시작(CreateBucekt, TerminateInstance)하여 표기한다.
와일드카드(*)
- 일반적으로 모든 작업을 나열하기 힘들 때, 모든을 뜻하는 의미로 사용된다.
- Example)
  1. Action: * : 모든 AWS 서비스의 모든 작업을 의미
  2. Action: s3:* : S3 서비스의 모든 작업을 의미
  3. Action: ec2:List* : EC2 서비스에서 List로 시작하는 모든 작업을 의미

2.2.3. Resource 블록

아마존 리소스 네임 (ARN, Amazon Resource Name)
AWS의 모든 리소스에는 전세계적으로 고유한 ID가 있으며, 이는 해당 리소스를 식별하는 데 사용된다.
EC2 인스턴스의 arn은 ‘arn:aws:ec2:us-east1:123456789012:instance/i-abc123’과 같이 표기된다.
문자열(string) ‘arn’
모든 ARN은 이 식별자로 시작한다.
파티션(partition)
모든 표준 AWS 리전의 파티션은 ‘aws’이다.
다른 파티션은 각각 중국 리전은 ‘aws-cn’, 미국 GovCloud 리전은 ‘aws-us-gov’이다.
서비스 단축명(service short name)
AWS CLI에서 사용되는 것과 동일한 이름이다.
ex. Amazon S3의 경우 ‘s3’ / AWS Identity and Access Management의 경우 ‘iam’ 이다.
리전(region)
리소스가 동작하는 지역의 코드다.
IAM 사용자와 같은 글로벌 리소스의 경우 리전이 비어 있다.
계정(account) ID
리소스를 소유한 계정의 12자리 ID이다
S3 버킷과 같이 모든 계정에서 고유한 이름을 적용하는 경우 계정 ID는 비어 있다.
리소스 식별자(resource identifier)
리소스에 따라 다양한 형식을 취한다.
EC2 인스턴스 리소스 식별자는 ‘instnace/i-abc123’처럼 보이지만, S3 버킷의 경우 리소스 식별자는 버킷 이름이다.

Resource 블록은 이 선언문이 적용되어야 하는 ARN으로 지정된 리소스를 나타내는 문자열 또는 문자열 목록이다.

  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::my-bucket-name/*"
    }
  ]
}

이 정책은 S3 서비스의 모든 메서드를 사용할 수 있는 권한 ("s3:*")을 부여하지만, 이는 지정된 S3 버킷의 객체("arn:aws:s3:::my-bucket-name/*")에 대해서만 허용한다.
예를 들어, S3 Bucket에 파일을 쓰는 S3 메서드인 PutObject를 호출할 수 있는 권한을 해당 객체에 부여하지만, 다른 S3 Bucket에서 PutObject를 호출하는 것은 허용하지 않는 것이다.

리소스가 명확하지 않은 몇 가지 특별한 경우가 있다.

리스트 작업
- 리스트 작업은 특정 리소스에 국한되지 않음 (ex. ListTables, S3의 ListAllMyBucket)
- 이러한 유형인 작업의 경우, Resource 블록은 일반적으로 ‘*‘로 지정
작업 생성
- 리소스를 생성하기 전에는 생성하려는 리소스의 ARN을 아직 모름
- Resource 블록에 ‘*‘을 사용하는 것 외에 대안이 거의 없음

2.2.4. Condition 블록

Condition 블록을 사용하면 정책 선언문이 적용되는 시기에 대한 추가 제한을 적용할 수 있다.

  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "IpAddress" : {
          "aws:SourceIp" : "17.5.6.7"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "DateGreaterThan" : {
          "aws:CurrentTime" : "2020-01-01T12:00:00Z"
        }
      }
    }
  ]
}

SourceIp가 17.5.6.7인 경우, 모든 리소스에 s3:PutObject 작업 허용
CurrentTime이 2020-01-01 자정 이후 전체 리소스에 S3:PubObject 작업 허용

2.2.5. NotAction 및 NotResource 블록

NotAction 및 NotResource 블록을 사용하면 선언문에 적용되지 않는 작업 또는 리소스를 지정할 수 있다.
해당 블록의 경우, 많은 혼란의 원인이 될 수 있다.

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

위 정책의 경우, ec2:TerminateInstances를 제외한 모든 EC2 작업을 부여한다고 생각할 수 있다.
하지만, 이는 EC2 뿐만 아니라 모든 서비스의 모든 리소스에 대한 전체 접근 권한이 부여받을 수 있다.

이러한 블록은 매우 드물게 사용되거나, 아예 사용하지 않는 것이 바람직하다. (보안 구성을 덜 혼란스럽게 하는 것이 낫다.)

2.3. 정책 사용

일반적으로 권한을 부여하려면 ID 정책을 IAM 엔터티에 연결해야 한다. ID 정책을 사용자(또는 다른 엔터티)에 연결하는 방법은 두 가지가 있다.

인라인 정책
관리형 정책

3. 리소스 정책 (Resource policy)

ID 정책을 사용할 경우, 허용되는 작업(Action)과 적용되는 리소스(Resource)가 명시된다. ID 정책은 정책이 적용되는 사용자를 명시하지 않으며, 정책이 연결된 사용자에 따라 결정된다.

3.1. Resource 블록의 필요성

리소스 정책은 S3 Bucket과 SNS Topic과 같은 리소스 자체에 직접 연결되는 정책이다.
따라서, 리소스 정책에서 Resource 블록이 항상 필요한 것은 아니다.

신뢰 정책(Trust Policy) 같은 경우, 정책이 붙은 리소스가 명확하므로 Resource 블록이 필요하지 않다.
반면 S3 bucket에 대한 리소스 정책에는 여전히 필요하다. S3 bucket 자체를 지정하는 것인지, 그 안의 객체 파일을 지정하는 것인지에 대한 구분이 필요하다.

3.2. Principal 블록

Principal 블록은 리소스에 접근할 수 있는 보안 주체 엔터티 목록이다. (누가 이러한 작업을 수행할 수 있는가?)

포함 : IAM User, AWS Account, AWS Service, Federated User
미포함 : IAM Group, Instance Profile

Principal 블록에 나열된 보안 주체 엔터티는 리소스의 ‘신뢰할 수 있는 엔터티’ 또는 ‘신뢰할 수 있는 보안 주체’라고 부른다.

3.3. 리소스 정책 예시

Alice IAM User가 my-sample-bucket/*에서 s3:PubObject 작업을 호출할 수 있음
-> Alice 유저가 my-sample-bucket/*에 대한 ID 정책이 없어도 아래 리소스 정책을 통해 해당 작업이 가능함

  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/Alice"
      },
      "Resource": "arn:aws:s3:::my-sample-bucket/*"
    }
  ]
}

3.4. 명시적 거부의 우선순위 규칙

기본 규칙
- AWS의 기본 상태는 ‘모두 거부’이다.
- 권한을 부여하려면 ID 정책(사용자에 연결) 혹은 리소스 정책(리소스에 연결) 중 최소 한 곳에서 허용(Allow) 되어야 한다.
절대 원칙
- AWS는 항상 거부(Deny) 정책을 우선으로 한다.
- 아무리 많은 정책에서 허용(Allow)하더라도, 거부(Deny) 정책이 하나라도 있으면 최종 결과는 거부(Deny)이다.
권한 검사 순서
- 명시적 거부 (Explicit Deny) : Yes (여기서 바로 차단, 끝)-> No
- 명시적 허용 (Explicit Allow) : Yes (통과) -> No (암묵적 거부)

거부 권한이 명시된 것은 그 누가 허락해도 절대 불가능 하다.

3.5. 적용 가능 리소스

일반적으로 S3 bucekt, KMS key, IAM role, Lambda 함수와 같은 리소스에 적용 가능하다. (모든 리소스에 적용 가능한 것은 아님)

리소스 정책을 적용할 수 있는 대표적인 리소스는 아래와 같다.

Elastic Container Registry (ECR)
Elastic File System (EFS)
Key Management Service (KMS)
CloudWatch Logs
AWS Lambda
Simple Storage Service (S3)
Secrets Manager
Database Migration Service
API Gateway
Simple Notification Service (SNS)
Simple Email Service
Virtual Private Cloud (VPC)
AWS Elasticsearch
Simple Queue Service (SQS)
Identity and Access Management (IAM)
IoT

4. 그룹 (IAM Group)

IAM Group은 기본적으로 여러 사용자에게 부여할 수 있는 권한 모음으로, 많은 사용자가 공유하는 대규모 권한 집합을 쉽게 관리할 수 있다.

여러 관리형 정책이 그룹에 연결되며, 그룹의 구성원은 연결된 정책의 모든 권한이 부여된다.

4.1. 그룹 사용 vs 미사용

10명의 개발자에게 각각 세 가지 다른 정책을 부여하는 경우를 가정하여 그룹을 사용한 경우와 사용하지 않은 경우를 비교한다.

그룹 미사용
- 개발자 한 명 한 명에게 정책 3개를 일일이 연결
- 총 30번의 API 호출 필요 (10명 * 정책 3개)
그룹 사용
- 그룹 생성 -> 그룹에 개발자 10명 포함 -> 그룹에 정책 3개 연결
- 총 14번의 API 호출 필요 (그룹 생성 1 + 멤버 추가 10 + 정책 연결 3) ```bash # IAM Group 생성 aws iam create-group
  –group-name Developers
# Develper 그룹 내 Alice 유저 추가 aws iam add-user-to-group
–group-name Developer
–user-name Alice
# DynamoDB 테이블 쿼리를 허용하는 정책 생성 aws iam create-policy
–policy-name SampleGroupPolicy
–policy-document file://Listing_02_11_policy.json
# 생성한 정책을 Developer 그룹에 연결 $ aws iam attach-group-policy
–group-name Developers
–policy-arn arn:aws:iam::123456789012:policy/SampleGroupPolicy ```

4.2. 관리의 유연성

그룹을 사용하는 경우, 신규 입사자, 정책 변경 등 여러 작업에 대해 효율적으로 대처할 수 있다.

경로(Path) 사용 단순 그룹을 넘어, Path 매개변수를 통해 그룹을 체계적으로 정리하는 것도 가능하다.
Developer 대신 /DivisionA/ProductB/Developer 가능
네임스페이스 역할로, 이름의 충돌을 방지하고 소속 구분 가능
ListGroups 명령 사용 시, /DivisionA로 시작하는 그룹만 필터링 가능

정책을 사용자에게 직접 적용하는 것보다 그룹 및 역할에만 적용하는 것이 좋다.
User 수가 증가함에 따라 권한을 훨씬 쉽게 관리할 수 있다. (권한 관리의 복잡성을 줄이는 것은 잘못된 구성 문제가 발생하는 것을 방지함)

5. 역할 (IAM Role)

AWS 리소스에 접근할 수 있는 권한을 가진다는 점에서 IAM User와 비슷하다.

하지만 IAM Role은 고정된 패스워드나 액세스 키가 없으며, 역할을 맡을 (Assume) 때만 임시 자격 증명(토큰)이 발급된다.
(IAM User는 고정된 패스워드나 액세스 키를 가짐 (장기적인 자격 증명))

5.1. 역할의 수명주기

역할 수임 (Assume Role)
- AWS STS(Security Token Service)에 “나 이 역할 쓸래”라는 요청(AssumeRole)
자격증명 가져오기
- AWS는 임시 자격 증명(액세스 키, 비밀 키, 세션 토큰)을 발급 (CLI나 SDK는 이 임시 키를 사용하도록 설정)
작업 호출
- 임시 키를 통해 AWS 서비스(S3, EC2 등) 이용
만료 (Expiration)
- 최소 15분 ~ 12시간까지만 사용 가능
- 만료 시 자동 삭제
다시 시작하기
- 시간이 지나 만료 시 다시 재발급 필요

5.2. 역할 예시

신뢰 정책(Trust Policy) 설정 - Alice를 신뢰할 수 있는 보안 주체로 새 역할을 생성한다.
권한 정책 생성 - 새 역할에 부여할 사용 권한이 포함된 관리형 정책을 생성한다.
권한 정책 연결 - 관리형 정책을 새 역할에 연결한다.
Alice 권한 설정 - 새 역할에 대한 STS AssumeRole 접근을 허용하는 ID 정책을 Alice에 추가한다.

5.2.1. 신뢰 정책 설정

CreateRole IAM 작업을 통해 새 역할을 생성할 수 있다.
RoleName과 AssumeRolePolicyDocument라는 필수 매개 변수가 있다.
(AssumeRolePolicyDocument는 역할을 사용할 수 있는 사용자를 결정)

  
# Assume role을 가진 새 IAM Role 생성
aws iam create-role \
    --role-name SampleRole \
    --assume-role-policy-document file://resourcepolicy.json

resourcepolicy.json

Effect : 허용 / Action : sts:AssumeRule / Principal : Alice 유저

  
  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Principal": {
          "AWS": "arn:aws:iam::123456789012:user/Alice"
        }
      }
    ]
  }

IAM User(Alice)가 IAM Role을 요청할 수 있는 권한이 부여된 것이다. 이제 IAM Role이 있으므로, 관리형 정책을 생성하고 연결해 IAM Role에 권한을 부여할 수 있다.

5.2.2. 권한 정책 생성 및 연결

policy.json

ec2:TerminateInstance 권한을 허용하는 정책 문서 생성 (실제 Policy 생성 x)

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

위 policy.json 문서를 통해 관리형 정책 생성

  
# The following command creates a new managed policy using the policy document
aws iam create-policy \
  --policy-name SampleRolePolicy \
  --policy-document file://policy.json

IAM Role에 생성한 관리형 정책 연결

  
# This command attaches the newly created managed policy to an IAM Role.
aws iam attach-role-policy \
  --role-name SampleRole \
  --policy-arn arn:aws:iam::123456789012:policy/SampleRolePolicy

5.2.3. Alice 권한 설정

Assume Role을 허용하는 정책

  
{
"Version": "2012-10-17",
"Statement": [
  {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::123456789012:role/SampleRole"
  }
]
}

ID 정책(관리형 정책)을 생성

  
aws iam create-policy \
  --policy-name AssumeSampleRolePolicy \
  --policy-document file://Listing_02_14.json

생성한 ID 정책을 Alice 사용자에게 연결

  
aws iam attach-user-policy \
  --user-name Alice \
  --policy-arn arn:aws:iam::123456789012:policy/AssumeSampleRolePolicy

5.3. 임시 자격 증명 발급 (AssumeRole 작업 호출)

위 단계에서 부여한 권한을 통해 Alice 사용자는 STS 서비스에서 AssumeRole 작업을 호출하여 Role을 사용할 수 있다.

duration-seconds : 역할을 사용할 수 있는 시간(초)
(최소 15분, 기본 1시간)

  
  aws sts assume-role \
      --role-arn arn:aws:iam::123456789012:role/SampleRole \
      --role-session-name my-sample-role-session \
      --duration-seconds 900

  # Expected Response Structure
  # {
  #    "AssumedRoleUser": {
  #        "AssumedRoleId": "...",
  #        "Arn": "..."
  #    },
  #    "Credentials": {
  #        "SecretAccessKey": "...",
  #        "SessionToken": "...",
  #        "Expiration": "2020-01-01T12:00:00Z",
  #        "AccessKeyId": ".."
  #    }
  # }

5.4. 임시 자격 증명 사용

위 명령어를 수행하면 AWS는 JSON 형태의 데이터를 반환한다.
여기서 “Credentials”(자격 증명) 부분 중 액세스 키(AccessKeyId), 패스워드(SecretAccessKey), 임시 출입 토큰(SessionToken)을 통해 해당 Role의 권한을 이용한다.

  
export AWS_ACCESS_KEY_ID={INSERT_ACCESS_KEY_ID}
export AWS_SECRET_ACCESS_KEY={INSERT_SECRET_ACCESS_KEY}
export AWS_SESSION_TOKEN={INSERT_SESSION_TOKEN}

aws ec2 terminate-instances \
    --instance-ids {INSERT_INSTANCE_ID}

위 세 가지 항목을 자격증명으로 사용하는 한, 지정된 기간(15분) 동안 Role에 명시된 권한(인스턴스 삭제)을 활용할 수 있다. 해당 기간이 지나 만료(Expiration)되면, 발급 받은 임시 자격 증명(3가지)는 무효된다.

5.5. IAM Role을 필수적으로 사용해야 하는 이유

실수 방지 및 사고 예방
- 모든 EC2 인스턴스를 삭제하는 스크립트 수행 시, 테스트 계정과 운영 계정의 자격 증명을 헷갈릴 위험이 있다.
- IAM Role을 통해 자격 증명을 부여한 경우, 위 AssumeRole 작업이 필요하므로 단순 실수에서 알아차릴 가능성이 있다.
보안 사고 시 피해 최소화
- 자격 증명이 유출되었을 때 위험도 최소화
- 일반 사용자 키의 경우 수동으로 바꿀 때까지 사용 가능
- 임시 역할 키의 경우 수명이 짧아 금방 만료되어 사용 불가
확장성 및 연동성
- AWS의 다른 서비스(EC2, Lambda 등)나 외부 시스템과 권한을 연동할 때, 아이디를 하나하나 생성하는 것보다 IAM Role을 이용하는 것이 훨씬 관리가 쉽고 유연하다.

CLOUD, AWS

This post is licensed under CC BY 4.0 by the author.