마지막 액세스 정보 사용 예제 시나리오
마지막 액세스 정보 사용 예제 시나리오
마지막 액세스 정보를 사용해 IAM 엔티티나 AWS Organizations 엔티티에 부여하는 권한에 대한 결정을 내릴 수 있어요. 자세한 내용은 마지막 액세스 정보를 사용한 AWS 권한 정제를 참고하세요.
출처: 문서
본문
참고
IAM이나 AWS Organizations에서 엔티티나 정책의 액세스 정보를 보기 전에 데이터의 보고 기간, 보고된 엔티티, 평가된 정책 유형을 이해하고 있어야 해요. 자세한 내용은 마지막 액세스 정보에 대해 알아야 할 사항을 참고하세요.
회사에 적합한 접근성과 최소 권한의 균형을 잡는 것은 관리자의 몫이에요.
IAM 그룹 권한을 줄이는 데 정보 사용하기
마지막 액세스 정보를 사용해 IAM 그룹 권한을 사용자가 필요로 하는 서비스만 포함하도록 줄일 수 있어요. 이 방법은 서비스 수준에서 최소 권한을 부여하는 중요한 단계예요.
예를 들어 Paulo Santos는 Example Corp의 AWS 사용자 권한을 정의하는 담당 관리자예요. 이 회사는 막 AWS를 사용하기 시작했고, 소프트웨어 개발 팀은 아직 어떤 AWS 서비스를 사용할지 정하지 못했어요. Paulo는 팀에게 필요한 서비스에만 액세스 권한을 주고 싶지만 아직 정의되지 않았으므로 임시로 power-user 권한을 줘요. 그런 다음 마지막 액세스 정보로 그룹의 권한을 줄여요.
Paulo는 다음 JSON 텍스트로 ExampleDevelopment라는 관리형 정책을 만들어요. 그리고 Development라는 그룹에 연결하고 모든 개발자를 그룹에 추가해요.
참고
Paulo의 power user들은 일부 서비스·기능을 사용하려면
iam:CreateServiceLinkedRole권한이 필요할 수 있어요. 이 권한을 추가하면 사용자가 어떤 서비스 연결 역할이든 만들 수 있다는 점을 Paulo는 이해해요. 자신의 power user를 위해 이 위험을 감수해요.
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "FullAccessToAllServicesExceptPeopleManagement",
"Effect": "Allow",
"NotAction": [
"iam:*",
"organizations:*"
],
"Resource": "*"
},
{
"Sid": "RequiredIamAndOrgsActions",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization"
],
"Resource": "*"
}
]
}
Paulo는 AWS Management Console로 Development 그룹의 마지막 액세스 정보를 보기 전에 90일을 기다리기로 해요. 그룹 멤버가 액세스한 서비스 목록을 확인해요. 사용자들이 지난주 안에 다섯 서비스(AWS CloudTrail, Amazon CloudWatch Logs, Amazon EC2, AWS KMS, Amazon S3)에 액세스했다는 것을 알게 돼요. 처음 AWS를 평가할 당시 몇몇 다른 서비스에도 액세스했지만 그 이후로는 사용하지 않았어요.
Paulo는 정책 권한을 그 다섯 서비스와 필수 IAM·AWS Organizations 작업만 포함하도록 줄이기로 해요. 다음 JSON 텍스트로 ExampleDevelopment 정책을 편집해요.
참고
Paulo의 power user들은
iam:CreateServiceLinkedRole권한이 필요할 수 있어요. 이 권한을 추가하면 사용자가 어떤 서비스 연결 역할이든 만들 수 있습니다.
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "FullAccessToListedServices",
"Effect": "Allow",
"Action": [
"s3:*",
"kms:*",
"cloudtrail:*",
"logs:*",
"ec2:*"
],
"Resource": "*"
},
{
"Sid": "RequiredIamAndOrgsActions",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization"
],
"Resource": "*"
}
]
}
권한을 더 줄이려면 Paulo는 AWS CloudTrail Event history 에서 계정의 이벤트를 볼 수 있어요. 거기서 개발자에게 필요한 작업·리소스만 포함하도록 정책 권한을 줄이는 데 사용할 수 있는 상세 이벤트 정보를 볼 수 있어요.
IAM 사용자 권한을 줄이는 데 정보 사용하기
마지막 액세스 정보를 사용해 개별 IAM 사용자의 권한을 줄일 수 있어요.
예를 들어 Martha Rivera는 회사 사람들이 과도한 AWS 권한을 갖지 않도록 책임지는 IT 관리자예요. 주기적 보안 점검의 일환으로 모든 IAM 사용자의 권한을 검토해요. 그중 한 사용자는 이전에 보안 엔지니어 역할을 했던 애플리케이션 개발자 Nikhil Jayashankar예요. 업무 요구사항이 바뀌어 Nikhil은 app-dev 그룹과 security-team 그룹 둘 다의 멤버예요. 새 직무의 app-dev 그룹은 Amazon EC2, Amazon EBS, Auto Scaling, Amazon S3, Route 53, Elastic Transcoder를 포함한 여러 서비스에 권한을 부여해요. 옛 직무의 security-team 그룹은 IAM과 CloudTrail에 권한을 부여해요.
관리자로서 Martha는 IAM 콘솔에 로그인해 Users 를 선택하고 nikhilj 이름을 선택한 뒤 Last Accessed 탭을 선택해요.
Martha는 Last Accessed 열을 검토하고 Nikhil이 최근 IAM, CloudTrail, Route 53, Amazon Elastic Transcoder 및 여러 AWS 서비스에 액세스하지 않았다는 걸 발견해요. Nikhil은 Amazon S3에 액세스했어요. Martha는 서비스 목록에서 S3를 선택하고 Nikhil이 지난 2주 안에 Amazon S3 List 작업 몇 가지를 수행했음을 알게 돼요. 회사 내에서 Martha는 Nikhil이 더 이상 내부 보안 팀 멤버가 아니므로 IAM과 CloudTrail에 액세스할 업무상 필요가 없음을 확인해요.
Martha는 이제 서비스·작업 마지막 액세스 정보를 바탕으로 조치할 준비가 됐어요. 하지만 이전 예의 그룹과 달리 nikhilj 같은 IAM 사용자는 여러 정책의 적용을 받고 여러 그룹의 멤버일 수 있어요. Martha는 nikhilj나 다른 그룹 멤버의 액세스를 실수로 방해하지 않도록 주의하며 진행해야 해요. Nikhil이 어떤 액세스를 가져야 하는지 배우는 것 외에도 어떻게 이 권한을 받고 있는지 판단해야 해요.
Martha는 Permissions 탭을 선택해 nikhilj에 직접 연결된 정책과 그룹에서 연결된 정책을 봐요. 각 정책을 펼쳐 정책 요약을 보고 어떤 정책이 Nikhil이 사용하지 않는 서비스에 액세스를 허용하는지 알아내요.
- IAM —
IAMFullAccessAWS 관리형 정책이nikhilj에 직접 연결되고security-team그룹에 연결돼 있어요. - CloudTrail —
AWSCloudTrailReadOnlyAccessAWS 관리형 정책이security-team그룹에 연결돼 있어요. - Route 53 —
App-Dev-Route53고객 관리형 정책이app-dev그룹에 연결돼 있어요. - Elastic Transcoder —
App-Dev-ElasticTranscoder고객 관리형 정책이app-dev그룹에 연결돼 있어요.
Martha는 nikhilj에 직접 연결된 IAMFullAccess AWS 관리형 정책을 제거하기로 해요. 그리고 Nikhil의 security-team 그룹 멤버십도 제거해요. 이 두 조치로 IAM과 CloudTrail에 대한 불필요한 액세스가 제거돼요.
Nikhil의 Route 53과 Elastic Transcoder 접근 권한은 app-dev 그룹이 부여해요. Nikhil이 그 서비스를 사용하지 않더라도 다른 멤버는 사용할 수 있어요. Martha는 app-dev 그룹의 마지막 액세스 정보를 검토하고 여러 멤버가 최근 Route 53과 Amazon S3에 액세스했음을 알아요. 하지만 지난 1년간 그룹 멤버 중 Elastic Transcoder에 액세스한 사람은 없어요. 그래서 그룹에서 App-Dev-ElasticTranscoder 고객 관리형 정책을 제거해요.
Martha는 그다음 App-Dev-ElasticTranscoder 고객 관리형 정책의 마지막 액세스 정보를 검토해요. 정책이 다른 IAM 아이덴티티에 연결되지 않았음을 알게 돼요. 회사 내에서 정책이 향후 필요하지 않을지 조사한 뒤 정책을 삭제해요.
IAM 리소스 삭제 전에 정보 사용하기
IAM 리소스를 삭제하기 전에 마지막 액세스 정보를 사용해 누군가 마지막으로 리소스를 사용한 이후 일정 시간이 지났는지 확인할 수 있어요. 이는 사용자, 그룹, 역할, 정책에 적용돼요.
- IAM 사용자 — IAM 사용자 제거 또는 비활성화
- 그룹 — IAM 그룹 삭제
- 역할 — 역할 또는 인스턴스 프로파일 삭제
- 정책 — IAM 정책 삭제 (아이덴티티에서 정책 분리도 수반)
IAM 정책 편집 전에 정보 사용하기
해당 리소스에 영향을 주는 정책을 편집하기 전에 IAM 아이덴티티(사용자, 그룹, 역할)나 IAM 정책의 마지막 액세스 정보를 검토할 수 있어요. 사용 중인 누군가의 액세스를 제거하고 싶지 않기 때문에 중요해요.
예를 들어 Arnav Desai는 Example Corp의 개발자이자 AWS 관리자예요. 팀이 AWS를 사용하기 시작했을 때 모든 개발자에게 IAM과 AWS Organizations를 제외한 모든 서비스에 대한 전체 액세스를 허용하는 power-user 액세스를 줬어요. 최소 권한 부여를 향한 첫 단계로 Arnav는 AWS CLI를 사용해 계정의 관리형 정책을 검토하려 해요.
이를 위해 Arnav는 먼저 아이덴티티에 연결된 계정의 고객 관리형 권한 정책을 다음 명령으로 나열해요.
aws iam list-policies --scope Local --only-attached --policy-usage-filter PermissionsPolicy
응답에서 각 정책의 ARN을 확보해요. Arnav는 각 정책의 마지막 액세스 정보 보고서를 다음 명령으로 생성해요.
aws iam generate-service-last-accessed-details --arn arn:aws:iam::123456789012:policy/ExamplePolicy1
그 응답에서 JobId 필드로 생성된 보고서의 ID를 확보해요. Arnav는 JobStatus 필드가 COMPLETED 또는 FAILED 값을 반환할 때까지 다음 명령을 폴링해요. 작업이 실패하면 오류를 확보해요.
aws iam get-service-last-accessed-details --job-id 98a765b4-3cde-2101-2345-example678f9
작업 상태가 COMPLETED 가 되면 Arnav는 JSON 형식의 ServicesLastAccessed 배열 내용을 파싱해요.
"ServicesLastAccessed": [
{
"TotalAuthenticatedEntities": 1,
"LastAuthenticated": 2018-11-01T21:24:33.222Z,
"ServiceNamespace": "dynamodb",
"LastAuthenticatedEntity": "arn:aws:iam::123456789012:user/IAMExampleUser",
"ServiceName": "Amazon DynamoDB"
},
{
"TotalAuthenticatedEntities": 0,
"ServiceNamespace": "ec2",
"ServiceName": "Amazon EC2"
},
{
"TotalAuthenticatedEntities": 3,
"LastAuthenticated": 2018-08-25T15:29:51.156Z,
"ServiceNamespace": "s3",
"LastAuthenticatedEntity": "arn:aws:iam::123456789012:role/IAMExampleRole",
"ServiceName": "Amazon S3"
}
]
이 정보로 Arnav는 ExamplePolicy1 정책이 Amazon DynamoDB, Amazon S3, Amazon EC2 세 서비스에 대한 액세스를 허용함을 알아요. IAMExampleUser라는 IAM 사용자가 11월 1일에 마지막으로 DynamoDB에 액세스하려 했고, 누군가 IAMExampleRole 역할을 사용해 8월 25일에 Amazon S3에 액세스하려 했어요. 지난 1년 안에 Amazon S3에 액세스하려 한 엔티티가 두 개 더 있어요. 하지만 지난 1년간 아무도 Amazon EC2에 액세스하려 하지 않았어요.
즉 Arnav는 정책에서 Amazon EC2 작업을 안전하게 제거할 수 있어요. Arnav는 정책의 현재 JSON 문서를 검토하려 해요. 먼저 다음 명령으로 정책의 버전 번호를 알아내야 해요.
aws iam list-policy-versions --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1
응답에서 Versions 배열로 현재 기본 버전 번호를 확보해요. 그다음 그 버전 번호(v2)를 사용해 다음 명령으로 JSON 정책 문서를 요청해요.
aws iam get-policy-version --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 --version-id v2
Arnav는 PolicyVersion 배열의 Document 필드에 반환된 JSON 정책 문서를 저장해요. 정책 문서 내에서 ec2 네임스페이스의 작업을 검색해요. 정책에 다른 네임스페이스의 작업이 남아 있지 않다면 영향을 받는 아이덴티티(사용자, 그룹, 역할)에서 정책을 분리하고 정책을 삭제해요. 이 경우 정책은 Amazon DynamoDB와 Amazon S3 서비스를 포함해요. 그래서 Arnav는 문서에서 Amazon EC2 작업을 제거하고 변경 사항을 저장해요. 그런 다음 문서의 새 버전으로 정책을 업데이트하고 그 버전을 기본 정책 버전으로 설정하기 위해 다음 명령을 사용해요.
aws iam create-policy-version --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 --policy-document file://UpdatedPolicy.json --set-as-default
ExamplePolicy1 정책은 이제 불필요한 Amazon EC2 서비스에 대한 액세스가 제거되도록 업데이트됐어요.
기타 IAM 시나리오
IAM 리소스(사용자, 그룹, 역할, 정책)가 마지막으로 서비스에 액세스하려 한 시기에 대한 정보는 다음 작업을 수행할 때 도움이 돼요.
- 정책 — 권한을 제거하기 위해 기존 고객 관리형 또는 인라인 정책 편집
- 정책 — 인라인 정책을 관리형 정책으로 변환한 뒤 삭제
- 정책 — 기존 정책에 명시적 거부(explicit deny) 추가
- 정책 — 아이덴티티(사용자, 그룹, 역할)에서 관리형 정책 분리
- 엔티티 — 엔티티(사용자나 역할)가 가질 수 있는 최대 권한을 통제하는 권한 경계 설정
- 그룹 — 그룹에서 사용자 제거
조직 단위(OU) 권한을 정제하는 데 정보 사용하기
마지막 액세스 정보를 사용해 AWS Organizations의 조직 단위(OU) 권한을 정제할 수 있어요.
예를 들어 John Stiles는 AWS Organizations 관리자예요. 회사 AWS 계정의 사람들이 과도한 권한을 갖지 않도록 책임져요. 주기적 보안 감사의 일환으로 조직의 권한을 검토해요. 그의 Development OU는 새 AWS 서비스를 테스트하는 데 자주 쓰이는 계정을 포함해요. John은 180일 넘게 액세스되지 않은 서비스에 대한 보고서를 주기적으로 검토하기로 해요. 그런 다음 OU 멤버가 그 서비스에 액세스할 권한을 제거해요.
John은 관리 계정 자격 증명으로 IAM 콘솔에 로그인해요. IAM 콘솔에서 Development OU의 AWS Organizations 데이터를 찾아요. Service access report 표를 검토하고 선호 기간인 180일을 넘게 액세스되지 않은 AWS 서비스 두 개를 봐요. 개발 팀이 Amazon Lex와 AWS Database Migration Service에 액세스할 권한을 추가했던 것을 기억해요. John은 개발 팀에 연락해 이 서비스들을 더 이상 테스트할 업무상 필요가 없음을 확인해요.
John은 이제 마지막 액세스 정보를 바탕으로 조치할 준비가 됐어요. Edit in AWS Organizations 를 선택하고 SCP가 여러 엔티티에 연결돼 있다는 안내를 받아요. Continue 를 선택해요. AWS Organizations에서 SCP가 연결된 AWS Organizations 엔티티를 알기 위해 대상을 검토해요. 모든 엔티티가 Development OU 안에 있어요.
John은 NewServiceTest SCP에서 Amazon Lex와 AWS Database Migration Service 작업에 대한 액세스를 거부하기로 해요. 이 조치는 서비스에 대한 불필요한 액세스를 제거해요.